はじめに
こんにちは。基幹システム本部 基幹開発部 商品管理ブロックの田中秀明です。
Claude CodeやCodexの利用が広がるほど、各人の使い方、プロンプト、レビュー観点、AIへ任せる範囲がばらつき始めました。AIを高度に使いこなせる人は開発の進め方そのものを変えられる一方で、これから使い始める人にとっては「どの工程で、どこまでAIに任せればよいのか」が分かりにくい状態になっています。
ZOZOでは2025年7月に、1人あたり月額200ドルを基準として、Claude Codeをはじめとする開発AIエージェントを全エンジニアに導入することを発表しました。
利用可能なツールはClaude Code、Codex、Devin、Cursorなど多岐にわたっており、Claude Codeは数百名規模で利用されています。選択肢が増えること自体は前進ですが、組織として見ると、使い方が個人に閉じるほど開発プロセスの再現性は個人差に依存しやすくなります。
そこで基幹システム本部では、Claude CodeとCodexを組み合わせ、設計から実装、レビュー、必要に応じた画面確認までを支援する仕組みを作りました。この仕組みを/dev-initと/dev-resumeという2つの標準コマンドに集約しています。本記事では、この2コマンドの設計思想を紹介します。あわせて、内部でのClaude CodeとCodexの連携方法や、標準化によって変えようとしていることも説明します。
本記事で扱う内容は次の3点です。
- AIの本質から逆算した「AIに任せる工程」と「人間が判断する工程」の線引き
/dev-initと/dev-resumeの2コマンドに集約した理由- Claude Code × Codexの批判的対話による設計・実装レビューの仕組み
目次
- はじめに
- 目次
- 問題は「AIを使っていないこと」ではなく「使い方が個人に閉じていること」
- AIに任せる工程を、AIの本質から決める
- なぜ2コマンドなのか
- なぜ自前の標準コマンドなのか
- なぜClaude Code × Codexでレビューするのか
- 全体アーキテクチャ
- /dev-init：AIが迷わない初期状態を作る
- /dev-resume：AIが文脈を失わずに作業を続ける
- Codexレビューの中身
- Playwright MCPで画面確認まで接続する
- セットアップ
- 標準化によって何が変わるか
- 残課題と今後
- まとめ
問題は「AIを使っていないこと」ではなく「使い方が個人に閉じていること」
開発AIツールの導入初期は、まず個人が試して便利な使い方を見つけていく段階があります。これは自然な流れであり、実際にAIを使いこなすメンバーは、調査、設計、実装、レビュー観点の整理など多くの工程で生産性を高めています。
一方で、個人の工夫が増えるほど、組織としては別の問題が見えてきました。
ある人はJiraの内容を貼り付けて設計書を生成させる。別の人は差分だけを見せてレビューさせる。さらに別の人は、仕様の曖昧さをAIに洗い出させる。どれも有効な使い方です。しかし、プロンプト、判断基準、AIへ渡す情報、レビュー時に見る観点が人によって異なると、設計書、進捗管理、検証観点がバラバラの形式で蓄積されていきます。
この状態では、AI活用が進んでいるように見えても、組織全体の最低水準は上がりにくくなります。先端ユーザーの成果は伸びますが、その知見が再利用可能な形で残らないためです。
ZOZOでは、AI活用の状態を個人と組織の両面から捉えるために、All ZOZO AI Readiness Score、通称AZARSという指標も定義しています。AZARSでは、個人がAIをどの程度業務に組み込めているかだけでなく、組織として「AIを前提とした業務プロセスを仕組みに落とし込めているか」も見ます。求められるのは、AI活用が得意な人の存在に加えて、誰でも同じ入口から一定水準のAI駆動開発を始められる状態です。
この標準化で避けたかったのは、AIに「任せすぎる」ことと「任せなさすぎる」ことです。
任せすぎると、AIの出力を検証しないまま設計や実装が進み、要件の読み違いや品質低下につながります。一方で任せなさすぎると、調査、設計書化、タスク分解、レビュー観点の抽出のような、AIで短縮できる工程を人が手作業で続けることになります。この2つの間に、組織として再現可能な線を引く必要がありました。
ここから先は、その線を「2コマンドの形」にどう落とし込んだのかを、設計判断の順に紹介します。
AIに任せる工程を、AIの本質から決める
AI駆動開発を標準化するうえで、最初に決めるべきことは「何をAIに任せるか」です。
現在のモデル性能だけを基準にすると、判断はすぐに古くなります。モデルやツールは短い周期で変わるため、「今このモデルならできる」「今このツールでは難しい」という視点だけで線を引いても、標準プロセスとして長く使い続けるのは難しくなります。
そこで、AIの仕組みからAIの本質的性質を「入力に対して、学習データと文脈からもっとも確からしい出力を返す変換機」であると捉えました。AIの出力品質は、入力の具体性、正解の一意性、学習データ上のパターンの豊富さに強く依存します。逆に言えば、入力と出力の対応関係が明確で、似たパターンが学習データに多くあるタスクほど、AIは安定して高い品質を出しやすくなります。
この性質は、情報の変換方向で整理できます。
具体から抽象への変換は、複数の事例から共通項やパターンを抽出する作業です。たとえば障害報告から課題パターンを見つける、コード差分からレビュー観点を抽出する、仕様書から不足や矛盾を検出する作業はここに含まれます。AIの仕組みが力を発揮しやすい領域です。
同一レベルの変換は、ある形式の情報を別の形式に整形する作業です。Jiraチケットから設計書を作る、設計書から実装タスクを作る、Git diffからレビューコメントを作る作業がこれにあたります。入力と出力の対応が比較的明確であれば、AIに寄せやすい領域です。
一方で、抽象から具体への変換は注意が必要です。要求を整理して企画を立てる、複数の実現案からどれを選ぶか決める、限られた期間で何を優先するか判断する、といった作業がこれにあたります。ここでは入力にない情報を補い、組織事情、事業インパクト、リスク、顧客価値を踏まえて決める必要があります。AIは選択肢の列挙や論点整理を支援できますが、最終判断を標準コマンドに閉じ込めるにはリスクが高い領域です。
この整理から、次の方針にしました。
- 同一レベル変換はAIに任せる。Jiraから設計書、設計書から進捗管理表、仕様から実装、差分からレビューを作る
- 具体から抽象はAIに任せる。矛盾検出、レビュー観点抽出、影響範囲の整理に使う
- 抽象から具体は人間が主導する。企画、要求整理、優先順位、最終責任は人間が持つ
つまり今回の2コマンドは、事業や要求の最終判断をAIに置き換えるものではありません。事業側から提供された企画や仕様の判断は人間が行うことを前提に、確定した仕様を正確に設計・実装・検証へつなげる領域を標準化するものです。
なぜ2コマンドなのか
標準化するとき、最初に迷うのはコマンドの粒度です。
工程ごとに細かく分ければ、調査、設計、タスク分解、実装、レビュー、テストといった各機能の責務は明確になります。しかし、入口が増えるほど利用者は「今どのコマンドを使うべきか」を判断しなければなりません。組織の最低水準として全員に使ってもらうには、最初の一歩が重くなります。
逆に、完全に1コマンドにする案もあります。利用者の認知コストは最小になりますが、開発初回だけは問題があります。設計書や進捗管理表がまだ存在しないため、AIが現在位置を特定する材料を持てません。初回は、以後のAI作業が参照する状態そのものを作る必要があります。
このため、初回作成と再開の2つに分けました。
/dev-init：Jira情報から、設計書、詳細設計兼・進捗管理表、必要に応じてテストパターンを作る/dev-resume：進捗管理表を読み、Gitの状態も見ながら、現在位置を特定して作業を再開する
| 選択肢 | 内容 | 長所 | 短所 | 判断 |
|---|---|---|---|---|
| 工程別に細かく分ける | 調査・設計・実装・レビューを別コマンドにする | 機能ごとの責務が明確 | 入口が増え、初心者のファーストステップが重い | 不採用 |
| 完全に1コマンド化する | 初回も再開もすべて1コマンド | 利用者の認知コストは最小 | 初回は設計書・進捗管理表がなく、AIが現在位置を特定しにくい | 不採用 |
| 初回作成と再開に分ける | 初回/dev-init、以後/dev-resume |
初回だけ不足情報を補い、以後は状態から再開できる | コマンドが2つになる | 採用 |
ここで重要なのは、2コマンドが「工程ごとに分ける」設計思想ではないことです。むしろ入口はできるだけ少なくしたいと考えています。/dev-init が存在する理由は、Git管理できる設計書・進捗管理表がまだ出力されていない初回だけ、AIが現在位置を特定できないからです。
進捗管理表が一度生成された後は、/dev-resumeがそのファイルを読み、現在のタスク、未着手タスク、ブロッカー、関連ファイル、Git diffを照合して次のアクションを提示できます。技術的に必要な初回だけを/dev-initとして分離し、それ以降は/dev-resumeに寄せます。このバランスが、利用者の学習コストとAIの技術的制約の接点でした。
なぜ自前の標準コマンドなのか
AI開発支援のツールやフレームワークは次々に登場しています。汎用的な開発オーケストレーションツールを使う選択肢もあります。
それでも、基幹システム本部ではZOZOの開発工程に合わせた標準コマンドを用意しました。理由は、汎用性と最適化がトレードオフだからです。
汎用ツールは幅広い用途に対応できます。一方で、ZOZOのJira、Confluence、既存コード調査、設計書の粒度、進捗管理、レビュー観点、フロントエンド確認までを、日々の開発導線に深く埋め込むには限界があります。
各チームが自由にワークフローを作る方法もあります。現場ごとの自由度は高くなりますが、属人化が進み、組織全体の最低水準は上がりにくくなります。
そこで、利用者に見えるUIは/dev-initと/dev-resumeの2つに固定し、内部のプロンプトやSkills、連携ツールを継続的に更新する形にしました。世の中のAIツールやモデルが変わっても、利用者は毎回新しい操作体系を覚える必要がありません。標準コマンドの中身を改善すれば、組織全体のAI駆動開発をまとめてアップデートできます。この標準コマンドは、先端的な使い方を止めるためのものではありません。できる人は標準以上の使い方ができます。一方で、標準コマンドがあることで、組織としての最低水準を引き上げられます。先端ユーザーの知見を標準コマンドへフィードバックし、中身を改善し続けることが重要です。
なぜClaude Code × Codexでレビューするのか
/dev-initと/dev-resumeではClaude Codeでベースラインを作成した後、Codexでレビューする仕組みを採用しています。
Claude Codeだけでも、設計書生成、実装、レビューはできます。それで十分な場面もあります。
ただし、品質を重視する場面で単一モデルに依存しすぎると、リスクがあります。モデルには得意不得意があり、提供側の性能調整の影響も受けます。また、同じモデルにセルフレビューさせる方法は実装しやすいものの、観点の独立性は強くありません。
そこでClaude CodeとCodexを別の役割で組み合わせました。
| 方式 | 長所 | 短所 | 採用判断 |
|---|---|---|---|
| Claude Codeのみ | 構成が単純で実行コストが低い | 単一モデルの見落としや性能調整の影響を受けやすい | 通常モードとして残す |
| Claude Code × Codex | 異なるモデルの観点を突き合わせられる | コストと時間が増える | 品質重視モードとして採用 |
Claude Codeは、全体のオーケストレーション、設計書生成、採否判断、修正実行を担当します。Codexは、リポジトリ内のコードを独自に調査したうえで、設計や実装を批判的にレビューします。
狙いは、片方のAIが出した答えを別のAIが独立した観点で疑うことです。
AIによるレビューの批判的対話は、次の3ラウンドを最小単位にしています。
- Codexがリポジトリを独自調査し、設計や実装を批判的にレビューする
- Claude CodeがCodexの指摘を精査し、採用、却下、保留を判断する
- CodexがClaude Codeの却下判断や残存リスクを再批判する
レビュー回数を固定しているわけではありません。難しい変更では追加のサイクルが必要になり、軽い変更では早く収束します。自動実行では各レビューポイントにつき最大3サイクルまで実行し、同一の指摘内容が2サイクル連続で解消しない場合は対話型に切り替える設計です。これにより、難易度に応じてレビューの深さを変えつつ、無限に回り続けることを避けています。
全体アーキテクチャ
全体の流れは、Jira起票から始まります。
開発者はまず/dev-initを実行し、Jiraチケットの内容を渡します。Claude Codeはチケットの背景、受入条件、関連情報を解析し、サブエージェントを使ってコードベースやConfluenceを並列調査します。その結果をもとに、Confluence設計書、ローカルMarkdownの詳細設計を兼ねた進捗管理表、必要に応じてテストパターンを生成します。
その後の開発では/dev-resumeを使います。進捗管理表を読み、現在の進捗、未着手タスク、進行中タスク、関連ファイル、git status、git diffをもとに再開ポイントを提示します。実装後はCodexでレビューし、フロントエンド関連の変更でPlaywright MCPが利用できる場合は画面確認まで接続します。
役割分担は次のように整理できます。
- Claude Code：オーケストレーター、設計書生成、進捗管理表の生成、コード実装、採否判断、修正実行
- Codex：独自調査に基づく批判的レビュー、再批判、残存リスクの指摘
- サブエージェント：コードベース調査、関連ファイル検索、既存実装パターン調査、タスク分解、テストパターン生成
- Playwright MCP：フロントエンド変更時のDOM、コンソール、ネットワーク確認
/dev-init：AIが迷わない初期状態を作る
/dev-initは、開発開始時に使うコマンドです。
/dev-init <JiraチケットまたはURLをコピー＆ペースト>
最初にJira情報を解析し、チケットID、タイトル、優先度、説明、受入条件、関連チケットを整理します。その後、作成対象を選びます。Confluence設計書と進捗管理表の両方を作る、Confluence設計書のみ作る、進捗管理表のみ作る、という選択ができます。
重要なのは、設計書を書く前にコードベースを調査する点です。Jiraの内容だけから設計書を作ると、文章としては整っていても、既存コードと整合しない可能性があります。そこで/dev-initでは、複数のサブエージェントを使って次の調査を並列に実行します。
- コードベース構造分析
- 関連ファイル検索
- 既存実装パターン調査
- Confluence関連ドキュメント検索
調査結果は、設計書と進捗管理表に反映されます。使用フレームワーク、レイヤー構成、主要コンポーネント、類似実装、関連ファイル、テスト方針、実装時の注意点を、以後の作業で参照できる形にします。
進捗管理表は、単なるタスク一覧ではありません。作業を中断しても、そのファイルだけを読めば再開できる詳細さを目指しています。チケットの背景、受入条件、タスク一覧、対象ファイル、実装詳細、テスト観点、未解決課題、作業ログを持たせます。
実際に使っている進捗管理表テンプレートは次のとおりです。
# {チケットID}: {タイトル}
## 基本情報
| 項目 | 内容 |
|------|------|
| Jiraチケット | {JiraチケットURL} |
| 設計書 | {Confluence設計書URL} |
| テストパターン | {テストパターンファイルパス} |
| ブランチ | feature/{チケットID} |
| 担当者 | {担当者名} |
| 開始日 | {今日の日付} |
| 目標完了日 | {目標日} |
| 最終更新 | {最終更新日時} |
---
## 要件サマリー
### 背景・目的
{Jiraの説明から抽出した背景・目的を簡潔に記載}
### 受入条件
- [ ] {受入条件1}
- [ ] {受入条件2}
- [ ] {受入条件3}
### スコープ
- **対象**: {実装対象}
- **対象外**: {対象外範囲}
---
## コードベース調査結果
### 関連ファイル一覧
#### 直接修正対象ファイル
| ファイルパス | 役割 | 修正内容 |
|-------------|------|----------|
| `{パス1}` | {役割1} | {修正概要1} |
#### 参照・影響範囲ファイル
| ファイルパス | 役割 | 影響内容 |
|-------------|------|----------|
| `{パス3}` | {役割3} | {影響概要3} |
### 既存コード構造
#### クラス・インターフェース構成
```
{パッケージ構成}
├── {クラス名1}.java // {概要}
└── {インターフェース名}.java // {概要}
```
### 類似実装の参考箇所
| 参考ファイル | 行番号 | 参考内容 |
|-------------|--------|----------|
| `{ファイルパス}` | L{開始}-L{終了} | {参考になるポイント} |
---
## 詳細タスク一覧
### フェーズ1: 準備・設計確認
| # | タスク | 状態 | 対象ファイル | 実装詳細 |
|---|--------|------|-------------|----------|
| 1.1 | {タスク名} | ⬜ | `{ファイルパス}` | {具体的な実装内容} |
### フェーズ2: 実装
| # | タスク | 状態 | 対象ファイル | 実装詳細 |
|---|--------|------|-------------|----------|
| 2.1 | {タスク名} | ⬜ | `{ファイルパス}` | {具体的な実装内容} |
### フェーズ3: テスト
| # | タスク | 状態 | 対象ファイル | テスト観点 |
|---|--------|------|-------------|-----------|
| 3.1 | 単体テスト作成 | ⬜ | `{テストファイルパス}` | {テスト観点} |
### フェーズ4: レビュー・完了
| # | タスク | 状態 | 備考 |
|---|--------|------|------|
| 4.1 | セルフレビュー | ⬜ | チェックリスト確認 |
| 4.2 | PR作成 | ⬜ | |
| 4.3 | コードレビュー対応 | ⬜ | |
| 4.4 | マージ・完了 | ⬜ | |
### ステータス凡例
- ⬜ 未着手
- 🔄 進行中
- ✅ 完了
- ⏸️ 保留
- ❌ キャンセル
---
## テストパターン進捗サマリー
> ※ テストパターンファイル: {テストパターンファイルパス}
### テスト実施状況
| 分類 | 総数 | Pass | Fail | 未実施 | 実施率 |
|------|------|------|------|--------|--------|
| 正常系 | {n} | 0 | 0 | {n} | 0% |
| 異常系 | {n} | 0 | 0 | {n} | 0% |
| 境界値 | {n} | 0 | 0 | {n} | 0% |
| 回帰 | {n} | 0 | 0 | {n} | 0% |
| **合計** | **{N}** | **0** | **0** | **{N}** | **0%** |
---
## 総合進捗
| 項目 | 完了 | 総数 | 進捗率 |
|------|------|------|--------|
| 実装タスク | 0 | {タスク総数} | 0% |
| テストパターン | 0 | {テスト総数} | 0% |
| **総合** | **0** | **{合計}** | **0%** |
---
## 作業ログ
### {今日の日付}
#### 実施内容
- [ ] 詳細設計兼進捗管理表作成
- [ ] 設計書作成完了
#### 進捗サマリー
- **完了タスク**: 0/{総タスク数}
- **進行中タスク**: 0
- **ブロッカー**: なし
---
## 関連リンク
### プロジェクト関連
- **設計書**: {Confluence設計書URL}
- **Jira**: {JiraチケットURL}
- **テストパターン**: {テストパターンファイルパス}
- **PR**: （作成後に追記）
---
## メモ・課題
### 未解決課題
| # | 課題 | 優先度 | 期限 | 担当 |
|---|------|--------|------|------|
| 1 | {課題内容} | {高/中/低} | {期限} | {担当} |
### 決定事項
| 日付 | 決定事項 | 決定者 |
|------|----------|--------|
| {日付} | {決定内容} | {決定者} |
---
## 作業再開ガイド
### 現在の状態
- **最終作業タスク**: {タスク番号と名前}
- **作業中断理由**: {理由}
- **次のアクション**: {具体的なアクション}
### 再開時の確認事項
1. {確認事項1}
2. {確認事項2}
3. {確認事項3}
### コンテキスト復元用コマンド
```bash
# ブランチ切り替え
git checkout feature/{チケットID}
# 最新化
git pull origin feature/{チケットID}
```
Codexレビューモードを選択した場合は、設計フェーズで3つのレビューポイントを通します。
- 設計書レビュー: 設計品質、要件カバレッジ、コードベースとの整合性
- タスク分解レビュー: タスク粒度、依存関係、受入条件カバレッジ
- 実装方針レビュー: 実装方針、既存コードとの整合性、リスクと実行順序
実際の流れは次のようになります。
Step 0: Codex CLI セットアップ・認証確認 Step 1: Jira情報の解析 Step 2: 作成対象の選択 Step 3: 並列コードベース・Confluence調査 Step 4: 設計書プレビュー Step 5: Codex設計書レビュー Step 6: 並列タスク分解による進捗管理表の生成 Step 7: Codexタスク分解レビュー Step 8: Codex実装方針レビュー Step 9: 並列テストパターン生成 Step 10: 完了
この時点でレビューを挟む理由は、修正コストを下げるためです。実装後に問題を見つけるより、設計とタスク分解の時点でズレを潰すほうが低コストです。特にAIが生成したタスク分解は、一見もっともらしくても、既存コードの実態からズレることがあります。Codexに独自調査させることで、Claude Codeが作った計画を別視点から疑わせます。
/dev-resume：AIが文脈を失わずに作業を続ける
/dev-resumeは、開発中や中断後に作業を再開するためのコマンドです。
/dev-resume ./docs/progress/PROGRESS-TICKET-123.md
# 引数なしの場合は進捗管理表を自動検索
/dev-resume
引数で進捗管理表を指定した場合はそのファイルを読みます。指定がない場合は、カレントディレクトリ、.claude/progress/、docs/などからPROGRESS-*.mdや進捗管理表らしいMarkdownを探します。
進捗管理表からは、基本情報、要件サマリー、タスク一覧、関連ファイル、作業再開ガイド、未解決課題を抽出します。そのうえで、完了タスク数、進行中タスク、未着手タスク、ブロッカーの有無を計算します。
さらに、サブエージェントを使って現在の作業状態を自動検出します。git statusで未コミット変更を確認し、git diffで変更内容を見て、進捗管理表のタスクと照合します。これにより、前回の会話が消えていても、AIが現在位置を取り戻せます。
/dev-resumeのアクションメニューでは、次の操作を選べます。
1. 並列開発モードを開始する 2. 次のタスクを開始する 3. 特定のタスクを選択して開始する 4. 進行中のタスクを完了にする 5. タスクのステータスを変更する 6. 作業ログを追記する 7. 課題・ブロッカーを記録する 8. 終了する
中でも重要なのが、並列開発モードです。未着手タスクの依存関係を分析し、同じファイルを編集しないタスク、依存関係のないタスク、実装とテストを同時進行できるタスクを見つけます。そのうえで、複数のサブエージェントに分けて同時実装します。
並列実行後は結果を統合し、ファイル競合、import整合性、型定義の整合性を確認します。Codexレビューモードを選んだ場合は、その差分をCodexとの批判的対話にかけます。
/dev-resumeの本質は、AIに作業を継続させるための文脈を、会話ではなくファイルに持たせることです。会話履歴に依存すると、中断や翌日再開、別メンバーへの引き継ぎで文脈が失われます。進捗管理表をGit管理できる形式で残すことで、AIと人間が同じ状態を参照できます。
Codexレビューの中身
Codexレビューでは、単にgit diffを渡して「レビューして」と依頼するだけではありません。進捗管理表から、対象タスクの背景、目的、受入条件、実装詳細、設計上の制約を抽出し、差分と一緒に渡します。
レビュー観点は大きく2つです。
1つ目はコード品質です。バグ、回帰、設計不備、セキュリティ、テスト不足を確認します。
2つ目は仕様準拠です。実装が受入条件を満たしているか、要件サマリーの目的と整合しているか、過剰実装になっていないかを確認します。
目的: git差分に対して、コード品質と仕様準拠の2つの観点からレビューする コード品質: - バグ - 回帰 - 設計不備 - セキュリティ - テスト不足 仕様準拠: - 受入条件を満たしているか - 要件サマリーの目的と整合しているか - 実装詳細の方針に沿っているか - 過剰実装がないか
Codexの指摘に対して、Claude Codeは必ず採否を判断します。採用、却下、保留のいずれかを決め、理由を記録します。Codexの指摘が正しければ修正します。誤指摘や過剰な指摘であれば、なぜ採用しないのかを説明します。
その後、Codexに再批判させます。前回の主要指摘、Claude Codeの採否判断、修正後の差分を渡し、指摘が解消されたか、却下判断が妥当か、新しい問題がないかを確認します。
また、Codexへ送るdiffやプロンプトには、APIキー、パスワード、トークンなどの秘密情報が含まれていないか確認する制約を入れています。AI連携を標準化するほど、品質だけでなくセキュリティ上の運用ルールもコマンドに組み込む必要があります。
この設計で重要なのは、Claude CodeとCodexが「最終判断者」ではないことです。Codexは批判者として独自の観点を出し、Claude Codeは実装者として採否を判断して修正します。最終的に自動モードで収束しない場合は、人間の判断に戻します。
Playwright MCPで画面確認まで接続する
フロントエンド変更では、コードレビューだけでは不十分です。実際の画面でDOMが崩れていないか、コンソールエラーが出ていないか、ネットワークエラーが起きていないかを見る必要があります。
/dev-resumeでは、Playwright MCPが設定されており、修正対象にフロントエンド関連ファイルが含まれる場合、確認対象URLの手がかりを探します。手がかりがある場合に、画面を自動確認します。
確認内容は次のとおりです。
- DOM構造の確認
- コンソールエラーの検出
- ネットワークエラーの検出
- 問題検出時の自動修正
問題を検出した場合は、自動修正を最大2回まで試行します。Playwright MCPが未設定の場合は、そのステップを自動でスキップし、フローを止めません。
標準コマンドとして使うには、「環境が整っている場合は自動で確認し、整っていない場合はスキップして作業を継続する」というフォールバックが必要です。
セットアップ
実装はGitHubのリポジトリで管理して、以下の方法で利用できるようにしています。
- 既にリポジトリを利用している場合は
git pullで/dev-initと/dev-resumeが利用可能になる - 利用していない場合はClaude Codeの
/plugin (marketplace)からmarketplace URLを追加してインストールする
標準化によって何が変わるか
/dev-initと/dev-resumeの標準化によって変わることは大きく4つあります。
1つ目は、初動コストの低下です。利用者は、開発開始時は/dev-init、再開時は/dev-resumeだけ覚えればよくなります。工程ごとの細かいコマンドを覚える必要はありません。
2つ目は、設計書と進捗管理表の品質の均一化です。コードベース調査、関連ファイル、既存実装パターン、受入条件、テスト観点が一定のフォーマットで残ります。これにより、AIへの依頼も、人間同士のレビューも、同じ材料をもとに進められます。
3つ目は、AI活用判断の可視化です。人間が選択する箇所、AIに調査させる箇所、Codexレビューを挟む箇所、画面確認する箇所が、コマンドの流れとして現れます。これは教育装置としても機能します。
4つ目は、標準コマンドの中身を更新し続けられることです。AIツールやモデルは変化が速く、今日の最適解が数か月後も最適とは限りません。利用者のUIを2コマンドに保ったまま、内部のプロンプト、Skills、レビュー観点、MCP連携を更新すれば、組織全体を新しいAI駆動開発へ追従させやすくなります。
標準コマンドは、効率化ツールであると同時に、教育装置でもあります。AI活用に慣れていない人でも、/dev-initを使うと、Jira情報の整理、受入条件の確認、コードベース調査、設計書作成、タスク分解、テストパターン作成という流れを体験します。/dev-resumeを使うと、進捗管理表の読み込み、Git差分との照合、次のアクション選択、レビュー、画面確認という流れを体験します。
つまり、コマンドを使うこと自体が「開発時に何を確認すべきか」を可視化します。最初はコマンドに沿って進めるだけでも、繰り返すうちに、AIに任せやすい工程、人間が判断すべき工程、レビューで見るべき観点が分かるようになります。
Step 1: 2コマンドを使える │ ツールが判断ポイントを可視化する ▼ Step 2: コマンドが問いかける項目から、開発時に必要な判断観点を理解する │ 繰り返し使ううちに、AIに任せるべき箇所と人が判断すべき箇所の感覚が育つ ▼ Step 3: フレームワークなしでも適切なAI利用判断ができる
効果が出やすいのは、Jiraに要件や受入条件がある程度まとまっており、既存コードの調査範囲も推測できるタスクです。たとえば、既存機能の改修、入力チェックの追加、APIや画面の一部変更、既存パターンに沿った実装などは、AIの得意な同一レベル変換に寄せやすい領域です。
逆に、効果が出にくいのは、要求そのものが曖昧な段階です。誰の何の課題を解くのか、何を優先するのか、どのリスクを受け入れるのか。このような点が未定の状態では、AIへ渡す前に人間側で論点を整理する必要があります。
残課題と今後
標準化によって多くの課題を解決できましたが、引き続き取り組むべき課題も残っています。
まず、Codex連携にはコストと時間がかかります。Claude Code単独で進めるよりも、Codexによる独自調査、批判、Claude Codeによる採否判断、再批判まで行うためです。重要な機能やリスクの高い変更では有効ですが、すべてのタスクで常に使うべきとは限りません。
次に、自動実行の限界があります。最大3サイクルまで回しても同一の指摘内容が残る場合、人間の判断に戻す必要があります。これは失敗ではなく、標準コマンドが越えてはいけない境界です。AIが収束できない論点を人間に戻すことも、品質担保の一部です。
また、Playwright MCPによる画面確認は、環境整備に依存します。確認対象URLの手がかり、認証、テストデータ、安定した環境がなければ、自動確認は十分に機能しません。AI駆動開発の前提として、開発環境や検証環境を整える必要があります。
効果測定も今後の課題です。標準コマンドを作るだけでは、組織としての改善は証明できません。設計書の作成時間、実装着手までのリードタイム、レビュー指摘の質、利用回数、チームごとの利用状況、手戻り件数などを継続的に見ていく必要があります。
最後に、AIに任せない領域は固定ではありません。私は、現時点では、企画、要求整理、優先順位、顧客価値の判断は人間が主導すべきだと考えています。ただし、AIの性能向上や学習技術の変化により、境界は動きます。標準コマンドの設計も、その変化に合わせて見直し続ける必要があります。
今後は、/dev-initと/dev-resumeを使った実績を蓄積し、効果測定と改善サイクルを回していきます。
また、開発工程だけでなく、要求定義や企画整理を補助するコマンドへの応用も検討しています。ただし、上流工程は抽象から具体への変換が増えるため、開発工程と同じようにAIへ任せるわけにはいきません。AIが得意なフォーマット統一、網羅性チェック、矛盾検出と、人間が判断すべき優先順位や顧客価値を切り分ける必要があります。
AI駆動開発は、特定のツールを導入すれば完了するものではありません。ツール、プロンプト、レビュー、環境、効果測定、教育を含めて、開発プロセスとして運用し続ける必要があります。
まとめ
AI活用が広がるほど、個人ごとのプロンプトやワークフローは増えていきます。そのままでは、高度に使いこなす人と、どこに使えばよいか分からない人の差が開きます。
基幹システム本部では、この属人化に対する答えを、開発開始時の/dev-initと開発再開時の/dev-resumeという2つの入口に集約しました。/dev-initはAIが迷わない初期状態を作り、/dev-resumeは文脈を失わずに作業を続けるためのコマンドです。
設計思想としては、AIの本質を確率的な予測変換機と捉え、同一レベル変換と具体から抽象のタスクを中心にAIへ任せました。一方で、企画、要求整理、優先順位、最終責任のような抽象から具体への判断は、人間が主導する領域として残しています。
品質を重視する場面では、Claude CodeとCodexの批判的対話を組み込みました。Claude Codeが設計・実装を進め、Codexが独自調査に基づいて批判し、Claude Codeが採否を判断し、Codexが再批判します。これにより、単一モデルに依存しないレビュー観点を取り入れています。
2コマンドという安定したUIを維持しながら、中身のプロンプト、Skills、レビュー観点、MCP連携を更新し続けます。これが、AI駆動開発を個人技から組織標準へ移すための現実的なアプローチだと考えています。
AIの進化に合わせて、人間とAIの境界は変わります。だからこそ、固定された手順ではなく、更新し続けられる標準として運用していくことが重要です。今後も、AIを前提にした開発プロセスを磨き、設計からテストまでの品質と速度を組織として引き上げていきます。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
