この記事は、著者がありがちな診断とは注意深く区別する診断から始まる。ZOZO での問題は、エンジニアが AI を使えていないことではなく、各人のプロンプト、レビュー基準、どこまで委任するかの感覚がばらばらになっていたことだった。上級者は働き方を変えつつあった一方、新しく加わった人はどの段階で、どこまでエージェントに作業を任せればよいか判断できなかった。そのため、組織の天井が上がっても床は元のままだった。著者が掲げる狙いは、委任しすぎること（検証されていない出力によって要件の読み違いが設計に持ち込まれる）と、委任が少なすぎること（調査、設計の文書化、タスク分解、レビュー観点の抽出が手作業のまま残る）の両方を避けることである。
部門が行き着いた答えは、段階ごとに 1 つずつではなく、2 つのコマンドである。段階ごとに分割すれば各コマンドの責務は明確になるが、どれを使うべきかをユーザーが判断しなければならなくなる。すべてを 1 つのコマンドにまとめると、チケットの初回実行で破綻する。エージェントが自分の位置を把握するための設計ドキュメントや進捗表がまだ存在しないからである。そこで /dev-init はその初期状態を作るためだけに存在する。Jira チケットを解析し、サブエージェントを派遣してコードベースと Confluence を並列に調査させ、Confluence の設計ドキュメントと、詳細設計を兼ねるローカルの Markdown の進捗表を出力する。/dev-resume はそれ以降のすべてを担い、進捗表を読んで git status と git diff と突き合わせ、どこから再開するかを提案する。
両者の根底には、何を委任するかについての議論と、それをどう確認するかについての議論がある。委任についての議論は、モデルを、入力・学習データ・コンテキストを前提として最も確からしい出力を返す変換器とみなし、作業を、ある時点のモデルに何ができるかではなく、情報変換の方向によって分類するものである。確認についての議論は、単一のモデルが自身の出力をレビューしても視点の独立性は弱いというものであり、そのため品質が重要な実行では、記事が説明する 批判的対話レビュー のループで、設計と差分を Codex に回す。
要点
- 初期の AI 導入における失敗のパターンとして述べられているのは、使わないことではなく、個人ごとのばらつきである。プロンプト、判断基準、エージェントに渡す情報、レビュー基準がすべて異なるため、設計ドキュメント、進捗管理、検証基準が一貫しない形式で蓄積し、知識が再利用可能なものにならない。
- 何を委任するかは、現在のモデルの性能ではなく情報変換の方向から決められる。その根拠として、能力に基づく線引きはモデルが変わるにつれて古くなることが挙げられている。具体から抽象への作業（障害報告から問題のパターンを抽出する、差分からレビュー観点を抽出する、仕様から抜けや矛盾を抽出する）と、同じレベルでの変換（Jira チケットから設計ドキュメントへ、設計ドキュメントからタスクリストへ、差分からレビューコメントへ）はエージェントに任される。抽象から具体への作業（要件を計画に落とし込む、実装の選択肢から選ぶ、締め切りの下で優先順位を付ける）は、最終的な責任を負う人間に残される。
- 2 コマンドへの分割は、設計原則ではなく技術的な制約への妥協として示されている。著者は、入口はできるだけ少なくすることを意図しており、
/dev-initが存在するのは、Git で管理される進捗表が出力されるまではエージェントが自分の位置を把握できないからにすぎないと述べている。 - 進捗表は、それだけで再開できるほど意図的に詳細に作られており、チケットの背景、受け入れ基準、タスクリスト、対象ファイル、実装の詳細、テスト基準、未解決の課題、作業ログを含む。著者の主張は、継続のためのコンテキストは会話履歴ではなくファイルに置くべきだというものである。会話履歴は、中断、一晩の休止、他のメンバーへの引き継ぎによって失われるからである。
- 汎用のオーケストレーションツールを採用するのではなく部門専用のコマンドを作ることは、汎用性と適合性のトレードオフとして論じられている。汎用ツールの限界として挙げられるのは、ZOZO の Jira、Confluence、設計ドキュメントの粒度、進捗管理、フロントエンドの検証を日々の開発の経路に組み込むことである。ユーザーから見える部分は 2 つのコマンドに保ちつつ、その背後にあるプロンプト、Skills、連携は更新されていく。
- フロントエンドの変更は Playwright MCP に回され、DOM、コンソールエラー、ネットワークエラーのチェックが行われ、自動修復は最大 2 回まで試みられる。Playwright MCP が設定されていない場合、そのステップはフローを止めずにスキップされる。著者はこれを、組織の標準として使うものには必須の要件だとしている。
- Codex に送るプロンプトと差分は、API キー、パスワード、トークンといったシークレットが含まれていないかチェックするよう制約されている。著者の結論は、ベンダーをまたぐ AI 連携を標準化するということは、品質のルールだけでなく、セキュリティの運用ルールもコマンドに組み込むことを意味する、というものである。
- 著者は標準コマンドを、効率化の手段であると同時に教育的な手段としても提示している。コマンドを実行することで、プロセスがどのような判断を必要とするかが明らかになり、繰り返し使ううちに、どの段階を委任すべきかの感覚が身につき、やがてフレームワークなしでもそれが働くようになると期待されている。
- 報告されている限界は次のとおりである。Codex との組み合わせは Claude Code を単独で使うよりも時間と費用がかかり、すべてのタスクに使う価値はないこと。サイクルの上限を超えても未解決の指摘は人間に戻さなければならず、著者はこれを失敗ではなく標準コマンドが越えてはならない境界と位置づけていること。Playwright による検証は、URL のヒント、認証、テストデータ、安定した環境が揃っていることに依存すること。そして効果測定（設計の文書化にかかる時間、実装までのリードタイム、レビューの質、手戻りの回数）がまだ済んでいないことである。これらは 1 つの部門での導入についての著者自身の報告であり、測定された結果ではない。
背景
この記事は、エージェントの利用を個人に任せるのではなく組織として標準化する事例についての、この wiki の他の一次報告と並ぶものであり、よくある代替案の 1 つに明確に反対する立場をとっている。すなわち、各チームに独自のワークフローを作らせることであり、著者は、それは現場の自律性を高めるものの組織の床には手をつけないままにすると論じている。構造的に最も近いのは、モデルをまたいだレビューを支持する議論である。これは N バージョンプログラミング を魅力的なものにしているのと同じ推論を、生成ではなく批判に適用したものであり、クローズドループ AI レビュー がプルリクエストの両側に AI がいる状況を記述するという観察的な意味とは異なる。
著者は、ここで引かれた境界が固定されたものではないと明言している。計画、要件の具体化、優先順位付け、顧客価値の判断は、人間が主導すべきものについての著者自身の現時点での見解として述べられており、モデルの能力によってその線が動き、標準コマンドの設計もそれに合わせて見直さなければならなくなると予想されている。上流の要件定義の作業への拡張も検討中とされているが、上流の作業はより抽象から具体への性質が強く、そのため同じ条件では委任できないという注意が付されている。