はじめに こんにちは。基幹システム本部 基幹開発部 商品管理ブロックの田中秀明です。 Claude CodeやCodexの利用が広がるほど、各人の使い方、プロンプト、レビュー観点、AIへ任せる範囲がばらつき始めました。AIを高度に使いこなせる人は開発の進め方そのものを変えられる一方で、これから使い始める人にとっては「どの工程で、どこまでAIに任せればよいのか」が分かりにくい状態になっています。 ZOZOでは2025年7月に、1人あたり月額200ドルを基準として、Claude Codeをはじめとする開発AIエージェントを全エンジニアに導入することを発表しました。 corp.zozo.com 利用可能なツールは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に任せやすい変換パターンと人間が判断する領域 具体から抽象への変換は、複数の事例から共通項やパターンを抽出する作業です。たとえば障害報告から課題パターンを見つける、コード差分からレビュー観点を抽出する、仕様書から不足や矛盾を検出する作業はここに含まれます。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の却下判断や残存リスクを再批判する Claude CodeとCodexによる批判的対話レビュー レビュー回数を固定しているわけではありません。難しい変更では追加のサイクルが必要になり、軽い変更では早く収束します。自動実行では各レビューポイントにつき最大3サイクルまで実行し、同一の指摘内容が2サイクル連続で解消しない場合は対話型に切り替える設計です。これにより、難易度に応じてレビューの深さを変えつつ、無限に回り続けることを避けています。 全体アーキテクチャ 全体の流れは、Jira起票から始まります。 開発者はまず /dev-init を実行し、Jiraチケットの内容を渡します。Claude Codeはチケットの背景、受入条件、関連情報を解析し、サブエージェントを使ってコードベースやConfluenceを並列調査します。その結果をもとに、Confluence設計書、ローカルMarkdownの詳細設計を兼ねた進捗管理表、必要に応じてテストパターンを生成します。 その後の開発では /dev-resume を使います。進捗管理表を読み、現在の進捗、未着手タスク、進行中タスク、関連ファイル、 git status 、 git diff をもとに再開ポイントを提示します。実装後はCodexでレビューし、フロントエンド関連の変更でPlaywright MCPが利用できる場合は画面確認まで接続します。 Jiraからdev-init、dev-resume、レビュー、画面確認までの全体フロー 役割分担は次のように整理できます。 Claude Code：オーケストレーター、設計書生成、進捗管理表の生成、コード実装、採否判断、修正実行 Codex：独自調査に基づく批判的レビュー、再批判、残存リスクの指摘 サブエージェント：コードベース調査、関連ファイル検索、既存実装パターン調査、タスク分解、テストパターン生成 Playwright MCP：フロントエンド変更時のDOM、コンソール、ネットワーク確認 /dev-init ：AIが迷わない初期状態を作る /dev-init は、開発開始時に使うコマンドです。 /dev-init < JiraチケットまたはURLをコピー＆ペースト > 最初にJira情報を解析し、チケットID、タイトル、優先度、説明、受入条件、関連チケットを整理します。その後、作成対象を選びます。Confluence設計書と進捗管理表の両方を作る、Confluence設計書のみ作る、進捗管理表のみ作る、という選択ができます。 重要なのは、設計書を書く前にコードベースを調査する点です。Jiraの内容だけから設計書を作ると、文章としては整っていても、既存コードと整合しない可能性があります。そこで /dev-init では、複数のサブエージェントを使って次の調査を並列に実行します。 code.claude.com コードベース構造分析 関連ファイル検索 既存実装パターン調査 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が現在位置を取り戻せます。 進捗管理表とGit差分から再開アクションを提示する流れ /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レビューの最大3サイクルと対話型切り替え また、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駆動開発へ追従させやすくなります。 2コマンドの安定した入口と内部更新の関係 標準コマンドは、効率化ツールであると同時に、教育装置でもあります。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の性能向上や学習技術の変化により、境界は動きます。標準コマンドの設計も、その変化に合わせて見直し続ける必要があります。 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では、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 hrmos.co corp.zozo.com

インフラ勉強会とは インフラ勉強会は、コミュニケーションツール「Discord」のサーバ上に作られた、オンラインの勉強会コミュニティです。Discordアカウントとインターネットがあれば、どこからでも・誰でも（※1）無料 […]

はじめに 給与計算オプションの開発で最初に困ったこと なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか まず、初心者向けの課題図書を選んだ MVP開発に必要な知識に絞って、学習コンテンツを作った 仕様説明では、「なぜその機能が必要なのか」まで説明した リリースまで進めるうえで大事だったこと 1. 自分だけが詳しい状態にしない 2. 開発部・事業部が必要な知識を持てるようにする 3. すべてを学ぶのではなく、今回必要な範囲に絞る 4. 仕様の背景や目的まで伝える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 2026年4月に、楽楽勤怠から給与計算オプションをリリースしました。 www.rakus.co.jp 給与計算オプションの開発で難しかったことの一つが、給与計算というドメインの理解でした。 私は前職で給与計算システムの開発経験があり、一定のドメイン知識を持っていました。 一方で、今回の開発では、自分以外の開発部・事業部メンバーの多くが、給与計算の知識をほとんど持っていない状態からのスタートでした。 給与計算は、勤怠データや賃金規定、各種手当、控除、割増計算、端数処理など、さまざまな要素が絡み合う複雑なドメインです。 しかも、最終的に扱うのは「給与」です。 「だいたい合っていそう」では済まされません。 PdM/POである自分だけが理解していればよい、というものではありませんでした。 開発部が仕様の背景を理解して設計・実装できること。 事業部がリリースに向けた説明やマニュアル作成を進められること。 そのためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。 給与計算オプションは、2025年7月に開発を開始し、2026年4月にリリースしました。 この期間でリリースまで進められた理由の一つは、早い段階から開発部・事業部のドメイン知識を底上げし、関係者が自分の役割の中で判断しやすい状態を作れたことだと思っています。 この記事では、給与計算を知らないメンバーと給与計算オプションをリリースするために、どのようにドメイン知識を身につけてもらったのかを書いていきます。 給与計算オプションの開発で最初に困ったこと 給与計算オプションの開発で最初にぶつかった壁は、給与計算というドメインそのものの難しさです。 給与計算は、単に勤怠時間を集計して金額を出せば終わり、というものではありません。 会社ごとの賃金規定に基づいて、基本給、各種手当、控除、割増賃金、端数処理などを組み合わせて計算します。 さらに、会社によってルールや運用が異なります。 ある会社では当たり前の計算方法が、別の会社ではまったく違う。 そんなことも普通に起こります。 つまり、給与計算オプションを作るには、画面や機能の仕様を理解するだけでは足りません。 その裏側にある業務や、 「なぜその計算が必要なのか」 まで理解する必要があります。 私は前職で給与計算システムの開発経験があったため、ある程度の前提知識を持っていました。 しかし、自分以外の開発部・事業部メンバーは、給与計算の知識がほとんどない状態です。 このまま開発を進めると、何が起きるか。 開発部からは、こんな確認が出てきます。 この項目はなぜ必要なのか この計算ルールはどの業務に使われるのか この仕様で、どこまでのケースに対応できるのか こうした質問に答えること自体は、PdM/POの大事な役割です。 ただ、すべての確認や判断が自分に集まる状態になると、開発のスピードが落ちてしまいます。 さらに、リリースに向けた説明やマニュアル作成を進めるときにも、毎回自分が説明しないと前に進まない状態になってしまいます。 ここで最初に考えたのは、 「自分がもっと詳しく説明できるようにしよう」 ではありませんでした。 それよりも、 みんなが自分の役割に必要な範囲で、給与計算を理解できる状態を作らないといけない ということでした。 給与計算オプションをリリースまで進めるためには、自分だけが詳しい状態から抜け出す必要がありました。 なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか 最初は、開発部のメンバーに給与計算の知識を身につけてもらうことが重要だと考えていました。 開発部が仕様の背景を理解していないと、設計や実装の判断が難しくなります。 例えば、以下のような判断です。 ある計算ルールをどう表現するか どこまで設定で変更できるようにするか どのような条件でエラーを返すべきか こうした判断は、仕様書に書かれている内容だけでは決めきれません。 給与計算の業務背景を理解しているからこそ、判断できることがあります。 ただ、開発を進める中で気づきました。 「あれ、これは開発部だけの話じゃないぞ・・・？」 今回の開発では、事業部もリリースに向けて重要な役割を担っていました。 例えば、マニュアル作成です。 操作手順だけを書けばよいなら、画面を見ればある程度進められるかもしれません。 でも実際には、それだけでは足りません。 なぜこの設定が必要なのか この項目を設定すると、どの計算に影響するのか お客様はどの場面でこの機能を使うのか こうした背景がわからないと、マニュアルの説明も薄くなってしまいます。 お客様にリリース内容を説明する場合も同じです。 今回の給与計算オプションで何ができるのか。 どのような業務を支援する機能なのか。 どこまでが対象で、どこから先は対象外なのか。 これらを説明するには、事業部側にも給与計算の基本的な理解が必要でした。 つまり、給与計算オプションをリリースするには、開発部だけでなく事業部にもドメイン知識が必要だったのです。 開発部が実装を進める。 事業部がお客様に向けた説明やマニュアルを準備する。 そして、リリースに向けてそれぞれの立場で判断していく。 その流れを止めないためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。 まず、初心者向けの課題図書を選んだ 最初に取り組んだのは、初心者向けの課題図書を選ぶことです。 給与計算について学べる本はたくさんあります。 ただ、実際に探してみるとけっこう大変でした。 専門的すぎる本もあります。 法律や制度の説明が中心の本もあります。 実務担当者向けに、かなり細かい手続きまで書かれている本もあります。 もちろん、どれも重要な知識です。 ただ、今回の目的は、開発部・事業部のメンバーを給与計算の専門家にすることではありません。 必要だったのは、給与計算の基本的な考え方を理解し、仕様やリリース内容を理解できるようになることです。 そこで、本屋や図書館に行き、実際に本を手に取って選びました。 このとき見ていたポイントは、主に次のようなものです。 給与計算の全体像がつかみやすいか 初心者でも読み進めやすいか 専門用語が多すぎないか 実務の流れをイメージしやすいか 開発部・事業部のどちらが読んでも役立ちそうか いくつか本を見比べながら、「最初に読むならこれがよさそうだな」という本を選びました。 ここは、思った以上に大事な工程でした。 最初に触れる情報が難しすぎると、 「給与計算ってよくわからない」「自分には関係なさそう」 と感じてしまいます。 逆に、最初の一冊で全体像がつかめると、その後の仕様説明や議論がかなり進めやすくなります。 選んだ本は、開発部・事業部共通の課題図書として指定し、事前に読んでもらいました。 ただ、いきなり課題図書を読んでもらうだけでは、少しハードルが高いとも感じていました。 給与計算をまったく知らない状態だと、本を読み始めても、最初の用語や業務の流れでつまずく可能性があります。 そこで、超初心者向けに 給与計算の超概略資料 も作成しました。 この資料では、細かい制度や計算方法には踏み込みすぎず、まずは以下のような全体像をつかめるようにしました。 給与計算とは何をする業務なのか 勤怠情報と給与計算がどうつながるのか 支給、控除、割増といった基本的な考え方 賃金規定が給与計算にどう関係するのか まずは概略資料でざっくり全体像をつかむ。 そのうえで課題図書を読む。 この流れにすることで、学習のハードルを下げることを意識しました。 課題図書を共通にしたのは、全員に同じレベルの知識を求めたかったからではありません。 まずは、 「給与計算ってこういうものなんだ」 という感覚を持ってもらいたかったからです。 例えば、「賃金規定」「割増賃金」「控除」「支給項目」といった言葉を聞いたときに、まったくイメージが湧かない状態と、なんとなくでも意味がわかる状態では、その後の理解度が大きく変わります。 まずは、給与計算の世界に入るための入口を作る。 課題図書と超概略資料には、そんな役割を持たせていました。 MVP開発に必要な知識に絞って、学習コンテンツを作った 課題図書を読んでもらうことで、給与計算の基本的な考え方に触れてもらうことはできました。 ただ、 一度読んだだけで身につくものでもありません。 給与計算の範囲はとても広いです。 全部をちゃんと学ぼうとすると、本当に終わりが見えません。 一方で、開発は前に進めなければなりません。 全員が給与計算のすべてを理解するまで待っていたら、開発速度が落ちてしまいます。 そこで考えたのが、 今回のMVP開発に本当に必要な知識を、まず最初に身につけてもらう ということでした。 必要だったのは、給与計算のすべてを理解してもらうことではありません。 給与計算オプションのMVP開発に必要な知識 仕様を理解し、判断するために必要な知識 リリースに向けた説明やマニュアル作成に必要な知識 この範囲に絞って、学習コンテンツを作成しました。 ここで大事にした狙いは、主に2つあります。 1つ目は、 本当に必要な知識から先に身につけてもらうこと です。 給与計算の知識をすべて網羅しようとすると、どうしても時間がかかります。 もちろん深い理解は大事ですが、今回まず必要だったのは、開発やリリース準備を進めるための最低限の理解でした。 そのため、MVP開発に関係する内容を中心に整理し、優先的に学べるようにしました。 2つ目は、 本を読むだけではなく、別の形で復習できるようにすること です。 本を読んだだけだと、どうしても理解が曖昧なまま残る部分があります。 一度読んで「わかった気がする」と思っても、仕様説明や実際の議論の場になると、うまく結びつかないこともあります。 そこで、読むだけではなく、聞いたり、確認したりできる形にすることで、理解度を高められるようにしました。 この学習コンテンツ作成に活用したのが、Google NotebookLMです。 具体的には、自分で整理した内容や、業務上扱える情報をもとに、音声解説や理解度確認テストの作成に活用しました。 Google NotebookLMを使ってよかったのは、知識を 「読むもの」だけでなく、「聞けるもの」「確認できるもの」 に変えられたことです。 音声解説では、給与計算の基本的な考え方や、今回の給与計算オプションで扱う範囲について、初心者でも理解しやすいように説明をチューニングしました。 理解度確認テストでは、ただ読んだり聞いたりするだけではなく、自分がどこまで理解できているかを確認できるようにしました。 ここで特に気をつけたのは、説明の粒度です。 給与計算に詳しい人向けなら、専門用語を使えば短く説明できます。 でも、今回の対象は給与計算をほとんど知らないメンバーです。 いきなり専門用語から入ると、そこで止まってしまいます。 そのため、 なぜその考え方が必要なのか どんな業務に関係するのか 今回の仕様ではどこに関わるのか という流れで理解できるようにしました。 また、あえて説明しすぎないことも意識しました。 給与計算のすべてを詰め込むと、情報量が多すぎて、かえって大事なことが見えにくくなります。 今回は、MVP開発に必要な知識に絞る。 その範囲ではしっかり理解できるようにする。 この割り切りが、かなり重要だったと思います。 「給与計算を全部学ぶ」のではなく、「今回の開発を前に進めるために必要な知識を身につける」。 この目的をはっきりさせたことで、学習コンテンツの方向性も定まりました。 仕様説明では、「なぜその機能が必要なのか」まで説明した ドメイン知識を身につけてもらう取り組みと並行して、仕様説明のやり方も変えました。 給与計算オプションの仕様は、画面や機能だけを見るとかなり複雑です。 入力項目も多く、設定する内容も多岐にわたります。 そのため、「この画面ではこの項目を設定します」という説明だけでは、なかなか理解しきれません。 むしろ大事なのは、その先です。 なぜこの画面が必要なのか なぜこの設定項目が必要なのか この機能は、どの給与計算業務を支えるものなのか MVPではどこまで対応し、どこから先は対象外にするのか ここまで説明して、ようやく仕様が立体的に見えてきます。 例えば、ある設定項目を説明するときも、単に「ここに値を入力します」とは言いません。 この項目は、こういう賃金規定を表現するために必要です この設定によって、この計算結果が変わります 今回のMVPでは、まずこの範囲に対応します というように、業務上の意味や判断の背景をセットで伝えるようにしました。 すると、少しずつ会話の質が変わっていきました。 単なる仕様確認だけではなく、 このケースも考慮したほうがよさそう この表現だと、お客様には伝わりにくいかも ここはMVPでは割り切ってもよさそう といった会話が出るようになってきました。 これは、とても大きな変化でした。 自分が一方的に説明し続けるのではなく、開発部・事業部がそれぞれの視点で考え、判断しようとしてくれる。 その状態に近づいていったことで、開発もリリース準備も進めやすくなりました。 仕様を伝えるだけでは足りません。 特に複雑なドメインでは、 「なぜその仕様なのか」 まで伝えることが大事だと改めて感じました。 リリースまで進めるうえで大事だったこと 今回の開発を振り返ると、リリースまで進めるうえで大事だったことは、大きく4つあります。 1. 自分だけが詳しい状態にしない PdM/POがドメイン知識を持っていることは重要です。 ただ、それだけでは開発は進みません。 特に給与計算のような複雑なドメインでは、開発部・事業部がそれぞれの役割の中で判断できる状態を作る必要があります。 2. 開発部・事業部が必要な知識を持てるようにする 開発部には、仕様の背景を理解したうえで設計・実装するための知識が必要です。 事業部には、顧客説明やマニュアル作成を進めるための知識が必要です。 役割は違っても、リリースに向かううえで必要な知識は重なります。 3. すべてを学ぶのではなく、今回必要な範囲に絞る 給与計算の知識は本当に広いです。 全部理解してから進めようとすると、かなり時間がかかります。 だからこそ、今回のMVP開発に必要な知識に絞りました。 概略資料で全体像をつかみ、課題図書で基本を押さえ、学習コンテンツで今回必要な知識を補う。 この進め方は、現実的で効果的だったと思います。 4. 仕様の背景や目的まで伝える 仕様書や画面だけでは、なぜその機能が必要なのかまでは伝わりにくいです。 その機能がどの業務課題を解決するのか。 なぜその項目が必要なのか。 どこまでをMVPで扱うのか。 こうした背景や目的を説明することで、関係者が自分の役割の中で判断しやすくなります。 振り返ると、今回の開発では「仕様を作ること」だけでなく、 「理解できる状態を作ること」 にかなり時間を使いました。 最初は遠回りに見えるかもしれません。 でも、複雑なドメインでは、この遠回りが結果的に近道になることがあります。 関係者が理解し、自分の役割で判断できるようになると、開発やリリース準備が止まりにくくなるからです。 まとめ 給与計算オプションの開発では、給与計算という複雑なドメインに向き合う必要がありました。 今回あらためて感じたのは、複雑な業務ドメインのプロダクト開発では、PdM/POが詳しいだけでは不十分だということです。 開発部が仕様の背景を理解して設計・実装できること。 事業部がリリースに向けた説明やマニュアル作成を進められること。 そのためには、それぞれの役割に必要な範囲で、ドメイン知識を身につけてもらう必要があります。 課題図書、超概略資料、学習コンテンツ、Google NotebookLMを使った音声解説や理解度確認テストなど、やったことはいくつかあります。 ただ、一番大事だったのは、 自分の中にある知識を、関係者が理解しやすい形に変えて届けること だったと思います。 2025年7月に開発を開始し、2026年4月にリリースまで進められた背景には、こうした取り組みによって、開発部・事業部がそれぞれの役割で動きやすくなったことがありました。 何を作るかを考えることと同じくらい、誰がどこまで理解している状態を作るかも大事。 今回の開発を通じて、そんなことを強く感じました。