Claude CodeやCodexを使うと、設計書の粒度・レビューの厳しさ・どこまで任せるかが人によって変わってしまう。ZOZOの基幹システム本部は、この属人化に対して`/dev-init`（初期状態構築）と`/dev-resume`（作業再開）という2つの標準コマンドに集約する設計で応えた。AIに何を任せ、どこで人間が判断するかの線引きを読み解く。
ZOZOが示した「AIに任せる工程を情報変換の方向から逆算する」考え方と、/dev-init・/dev-resumeという2コマンド設計の中身。さらに、このブログ自身のClaude＋Codex二人体制運用と突き合わせて見えた共通点・違いまで。
複数人がClaude CodeやCodexのようなAIエージェントを使い始めると、必ずぶつかる壁がある。各自のプロンプトやワークフローが分散し、組織として再現可能な最低水準が上がっていかないという問題だ。ZOZOのTech Blogが公開した記事は、これに正面から取り組んだ実装レポートだった。
一人で使っている個人開発者にも、実は同じ問題は起きる。今日は丁寧に設計レビューをさせたのに、明日は面倒になって省略する——「同じ自分」の中でも運用がブレる。この記事はチーム開発の話だが、読み替えれば「未来の自分」と「今日の自分」の使い方を揃えるための設計として読める。
ZOZOの記事の核心は、「AIに何を任せるか」を勘や慣習で決めるのではなく、AIというものの仕組みそのものから逆算していた点にある。AIを「入力に対し、学習データと文脈から最も確からしい出力を返す変換機」と定義し、工程を情報変換の方向性で3種類に分類する。
Jiraのチケットから設計書を起こす、設計書から実装タスクへ分解する、コード差分からレビューコメントを生成する。情報の抽象度がほぼ変わらない変換は、AIの得意領域として真っ先に任せられる。
矛盾の検出、レビュー観点の抽出、影響範囲の整理。散らばった具体情報から共通点やリスクを拾い上げる作業も、AIが力を発揮しやすい領域として位置づけられている。
企画、要求整理、優先順位判断、最終責任。何もない所から「これをやる」と決める工程は、AIが最も苦手とする方向の変換として、人間側に残す設計にしている。
ここが核心。「AIに任せすぎると検証不足になり、任せなさすぎるとAIで短縮できる工程を人が手作業で続けることになる」——ZOZOの記事はこの両側のリスクを指摘したうえで、組織として再現可能な境界線を、感覚ではなく変換の方向性から引くというアプローチを取った。
コマンドの粒度には3つの選択肢があった。工程ごとに細かく分ける（責務は明確だが初心者の最初の一歩が重い）、完全に1コマンドへまとめる（認知コストは最小だが、初回は設計書も進捗管理表もなくAIが現在地を見失う）、そして初回と再開に分ける——ZOZOが選んだのはこの3つ目だった。
/dev-init（初期状態構築）は、Jiraのチケット情報からConfluenceの設計書と進捗管理表を生成する。複数のサブエージェントが並列でコードベースの構造・関連ファイル・既存の実装パターンを調査し、設計書レビュー・タスク分解レビュー・実装方針レビューという最大3つのレビューポイントを通す。
進捗管理表のテンプレートは、単なるタスク一覧ではない。「作業を中断しても、そのファイルだけを読めば再開できる詳細さ」を目指し、背景・受入条件・タスク・対象ファイル・実装詳細・テスト観点・未解決課題・作業ログまでを含む。
/dev-resume（作業再開）は、この進捗管理表を読み込み、完了タスク数・進行中タスク・未着手タスク・ブロッカーを自動検出する。さらにgit statusとgit diffで実際の作業状態を確認し、進捗管理表と照合して現在地を取り戻す。依存関係のないタスクは並列開発モードで同時に進められる。
# 発想の骨格（ZOZOの記事から抽出）
/dev-init = Jiraチケット → 設計書 + 進捗管理表 を新規生成
/dev-resume = 進捗管理表 + git status/diff → 現在地を再構築して継続
# 本質は「会話ではなくファイルに文脈を持たせる」こと会話履歴に文脈を依存させると、セッションが途切れた瞬間にすべて失われる。進捗管理表をGit管理できるファイルとして残すことで、AIと人間が同じ状態を参照できる——この一点が、2コマンド設計を機能させている土台だ。
ZOZOはさらに、単一モデルへの依存を避けるためにClaude CodeとCodexを別の役割で組み合わせている。Claude Codeがオーケストレーション・設計書生成・採否判断・修正実行を担い、Codexがリポジトリの独自調査に基づく批判的レビュー・再批判・残存リスクの指摘を担う、という分業だ。
自動実行では各レビューポイントにつき最大3サイクルまで回し、同一の指摘が2サイクル連続で解消しなければ人間を交えた対話型に切り替える設計になっている。「AIに何回まで自走させ、どこから人間を呼ぶか」という上限を、あらかじめ数値で決めている点が具体的だ。
このブログを含むポートフォリオ自体も、ClaudeとCodexを二人体制で運用している。読み比べると、ZOZOの設計と共通する部分と、規模の違いで単純化している部分がはっきり見えた。
ZOZOの進捗管理表と、このポートフォリオの_dashboard\journal.mdは、役割がほぼ同じだ。どちらも「作業を中断しても、そのファイルだけを読めば再開できる」ことを目指して設計されている。会話ログに頼らないという一点は、規模に関係なく効く原則らしい。
ZOZOは初回と再開を/dev-init／/dev-resumeという2つの明示的なコマンドに固定した。このポートフォリオはjournal.mdへの追記という、コマンド化されていない運用ルールで同じ役割を果たしている。人数が少ないうちはルールの明文化で足りるが、関わる人（エージェント）が増えるほど、ZOZOのようにコマンドという「固定インターフェース」へ寄せる必要が出てくるはずだ。
ZOZOは「最大3サイクル」という数値の上限を持つ批判的レビューの往復を仕組み化している。こちらの検品文化は「ログを信じずgrepと本番HTTPで確認する」という人間側のチェック手順が中心で、AI同士の批判的往復までは組み込んでいない。次に検討する余地がある部分だ。