AI駆動開発の進め方｜7ステージのロードマップ【2026年10月版】

7つのステージは、1から順に積み上がります。いまの位置から1段ずつ上がるのが近道です。

1. 1対話で聞くブラウザのチャットに、コードを貼って相談する
2. 2エディタに統合するIDEの拡張機能で、書く動作の中にAIが入る
3. 3仕様駆動に切り替える入力を会話からファイル（仕様のMarkdown）へ
4. 4知識をリポジトリに入れるCLAUDE.md・Skills・サブエージェント定義を資産にする
5. 5出力を機械的に制約するHooks・テスト・CI・権限で「お願い」を「仕組み」に
6. 6役割別に並列で走らせるサブエージェント・Agent Teams・git worktree で分担する
7. 7環境を改善し続けるエージェントの苦戦を環境のシグナルとして扱い、評価セットで回す

開発プロセスの軸と並行して、MCP・権限・コストといった実行基盤と、AIオーケストレーションやFDEといった人の役割も整えていく必要があります。この記事では、その2つの軸もあわせて扱います。

確認環境・確認日：Claude Code 公式ドキュメント（Memory・Skills・Hooks・Sub-agents・Agent Teams・Worktrees・Costs・Model config）、Claude API の料金ページ、AWS の発表（2026年10月10日確認）。

7ステージの早見表

まず、自分たちの現在地を測る5つの質問

読み進める前に、いまのチームに当てはまるものを選んでみると、どのステージを読めばよいかが分かります（クリックで印が付きます）。

• Q1AIへの入力は、会話ではなく「仕様のファイル」になっているはい → ステージ3以上。会話のままなら、ステージ2以下
• Q2コーディング規約は、口頭ではなくリポジトリの中（CLAUDE.mdなど）にあるはい → ステージ4
• Q3規約違反は、人が見つけるのではなく CI やフックが落とすはい → ステージ5
• Q4エージェントは1つではなく役割別に分かれ、作業空間も分離できているはい → ステージ6
• Q5エージェントが失敗したとき、プロンプトではなく環境（設計・命名・ドキュメント）を直しているはい → ステージ7の入り口

印が付いた一番大きな番号が、いまの現在地です。 次に読むのは、その1つ上のステージです。

ステージ1：「対話で聞く」

技術構成：ブラウザのチャットだけを使い、コードはコピー＆ペーストで往復します。

課題：コンテキストが毎回リセットされ、前提を質問のたびに説明し直すことになります。貼り付けられる量にも限りがあり、複数ファイルにまたがる変更は扱いにくい段階です。

ステージ2：「エディタに統合する」

技術構成：IDEの拡張機能（GitHub Copilot、Claude Code の IDE 連携など）が、開いているファイルの文脈をもとに補完や生成を行います。

変化：コピペの往復がなくなり、「書く」動作の中にAIが入ります。

課題：生成の単位が「いま書いている場所」に閉じているため、設計判断は人に残ります。大きな変更ほど人の作業量は減りません。速くなった分、差分の確認が追いつきにくく、要件にない処理が混ざっても動いてしまうため気づきにくい、という面もあります。

ステージ3：「仕様駆動に切り替える」

ここが最初の質的な転換点です。

技術構成：仕様をMarkdownで書き、それをAIへの唯一の入力にします。ファイルに落とす内容は次のとおりです。

• API一覧と、リクエスト・レスポンスの型
• バリデーションルール
• エラーハンドリングの方針
• 状態遷移と、異常系の扱い

実装は1機能ずつ縦に切って依頼し、差分は必ず人が確認します。要件・設計・タスクの3層を仕様ファイルとして持つ仕様駆動型のIDE（AWS の Kiro など）も登場し、このステージは道具の面でも一般的になりました。

効果の理由：会話は流れますが、ファイルは残ります。会話で決めた前提はターンが進むほど薄れますが、ファイルに固定すれば、何度依頼しても同じ前提から始められます。仕様を書き出す過程で、決めきれていない箇所が見えるのも大きな効果です。実装後に気づくより、ずっと安上がりです。

課題：仕様は書けても、コーディング規約や設計制約は口頭で伝えたままになりがちです。担当者が変わると、出力の質も変わります。

ステージ4：「知識をリポジトリに入れる」

技術構成：プロジェクトの前提を、リポジトリの中のファイルとして持ちます。対象は次のとおりです。

• 命名規則
• アーキテクチャ上の制約（レイヤー間の依存方向など）
• コードレビューで毎回指摘する観点
• 過去に踏んだバグのパターンと原因
• ドメイン固有の用語集
• テストの書き方と配置ルール

置き場所は、Claude Code なら CLAUDE.md、複数のコーディングエージェントで共有するなら AGENTS.md などの共通規格のファイルです。Git に置けば、チーム全員のAIが同じ定義を読みます。

CLAUDE.md と AGENTS.md を両方置くときの注意

Claude Code は AGENTS.md を直接読めます（v2.1.277 以降）。ただし公式ドキュメントでは、CLAUDE.md がある場合は既定で CLAUDE.md だけが読まれるとされています。

両方を使うなら、CLAUDE.md の中で AGENTS.md を読み込ませるのが確実です。

# CLAUDE.md
@AGENTS.md

## Claude Code 固有の指示
- テストは `pnpm test:unit` で実行する

/config の「Project instructions」を claude-md-and-agents-md にすると、両方を読む設定にもできます。

書き方で、守られやすさが変わる

公式ドキュメントが勧めている書き方は次のとおりです。

知識の持ち方の進化：Skills

2026年に入って、知識の持ち方がもう一段進みました。Skill（SKILL.md）です。前提を並べるだけでなく、「レビューの観点」「設計→実装→単体テストの手順」のような手順そのものを、必要なときだけAIが読み込む形で持てます。Claude Code では、以前のカスタムスラッシュコマンド（.claude/commands/）が Skills に統合されました。Agent Toolkit for AWS も、AWS向けの Skills と Rules を同梱しています。

役割別のサブエージェント定義（.claude/agents/）も、Git で共有する知識の一種です。

変化：出力のばらつきが減ります。担当者によって出来が変わる問題が起きにくくなり、新しいメンバーも同じ前提でAIを使えます。

課題：公式ドキュメントにあるとおり、CLAUDE.md は強制される設定ではなく、AIが読んで従おうとするコンテキストです。書いてあっても守られないことがあります。

ステージ5：「出力を、機械的に制約する」

技術構成：AIの出力を、確率ではなく仕組みで縛ります。

• カスタムリンターで、プロジェクト固有の禁止パターンを検出する
• アーキテクチャテストで、レイヤー違反をテストとして失敗させる
• コミット前のフックで、規約違反を機械的に弾く
• CI にレビュー用エージェントを組み込み、PR に自動で指摘を付ける
• Claude Code の Hooks で、ツール実行前に危険な操作をその場で止める

発想の違い：ステージ4は「守ってほしいことをお願いする」段階、ステージ5は「守らなければ通らない仕組みを作る」段階です。「ビジネスロジックをコントローラに書かない」は文章だけでは破られることがありますが、依存方向を検証するテストにすれば、破った時点で CI が失敗します。

Hooks の具体例：保護したいファイルの編集を止める

Claude Code の Hooks は、ツールの実行前（PreToolUse）などに任意のスクリプトを走らせます。スクリプトが終了コード 2 で終わると、その操作はブロックされ、標準エラー出力の内容が理由としてAIに伝わります。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# .claude/hooks/protect-files.sh
# 標準入力の JSON から、編集しようとしているファイルのパスを取り出す
FILE=$(jq -r '.tool_input.file_path // empty')

case "$FILE" in
  *.env|*package-lock.json|*/.git/*)
    echo "保護対象のファイルです: $FILE。編集ではなく、必要な変更を提案してください。" >&2
    exit 2   # ブロック。標準エラーの内容が AI に伝わる
    ;;
esac
exit 0

ブロックの理由がAIに伝わるため、AIは別の方法を考え直します。応用として、読み取り専用のクエリしか通さないDB用のエージェントのような使い方もできます。お願いではなく、仕組みで縛れます。

3つの層の使い分け

2026年9月22日に発表された Claude Opus 5.5 では、すべてのアクションを実行前に審査する分類器、セキュリティチームが監査できるオープンソースのサンドボックス、マージ前に脆弱性を捕まえるコードレビューがセットになったと紹介されています。制約の機械化は、モデル側の標準装備になりつつあります。

理由：AIは指示を確率的に解釈します。決定的なチェックと組み合わせるのが合理的です。曖昧な部分はAIに、判定できる部分はコードに任せる、という役割分担です。

ステージ6：「役割別のエージェントを、並列で走らせる（AIオーケストレーション）」

技術構成：1つの機能開発を、複数のエージェントに分担させます。たとえば、バックエンド担当、フロントエンド担当、テスト担当、レビュー担当です。

中心となる考え方は AIオーケストレーションです。タスクを分解し、エージェントに割り振り、成果物を統合して検証すること。指揮者が演奏をひとつの作品にまとめるイメージです。

オーケストレーションの3つの型

どの型でも、人の仕事は「分解」「境界の設計」「統合時の検証」に集まります。まず人が指揮する型で統合の感覚をつかみ、任せられる部分から親エージェントやチームに渡していく順番がおすすめです。

2026年時点のエージェントの道具：サブエージェントと Agent Teams

公式ドキュメントが勧めている始め方は、3〜5人程度のチームから、まずはコードを書かない調査やレビューで試し、同じファイルを複数のメンバーに編集させない、の3点です。チームメイトは Sonnet にすると、コストと能力のバランスが取りやすいともされています。

作業空間の分離

並列化で欠かせないのが作業空間の分離です。git worktree で、各エージェントに独立した作業ディレクトリを与えます。

# 人が指揮する型：ブランチごとに worktree を切って、別のターミナルで Claude Code を起動する
git worktree add ../feature-api feature/api
git worktree add ../feature-front feature/front

Claude Code には、worktree を作ってそのまま起動するオプションもあります。

claude --worktree feature-auth
# → .claude/worktrees/feature-auth/ に worktree を作り、ブランチ worktree-feature-auth で起動する

サブエージェント定義に isolation: worktree と書くと、そのサブエージェントは毎回専用の worktree で作業します。同じリポジトリを共有しつつ、互いの変更で壊し合わない状態になります。

---
name: refactorer
description: 複数ファイルにまたがる機械的なリファクタリングを行う
isolation: worktree
---
指示されたリファクタリングを対象ファイルすべてに適用し、テストを実行して結果を報告する。

Opus 5.5 の発表では、1つのセッションが十数のセッションを指揮し、40本の積み重なった PR を数日がかりでリベースした例が紹介されています。

ステージ5とのつながり：品質の関門

Agent Teams には、タスクが完了扱いになる直前に動くフック（TaskCompleted）があります。テストが通っていなければ、終了コード 2 で完了を止めて差し戻せます。並列化が進むほど、ステージ5の仕組みが効いてきます。

人の役割の変化：オーケストレーターへ

書く人から、まとめる人（オーケストレーター）へ役割が移ります。求められる力は3つです。

腕の見せどころは分解の粒度です。境界が曖昧なまま並列化すると、同じ箇所を別々に直して衝突しやすくなります。インターフェースを先に固めてから分けることが要点です。

ステージ7：「環境そのものを、改善し続ける」

ここで発想が一段変わります。エージェントが苦戦する箇所は、環境に改善の余地があるシグナルとして扱います。プロンプトを工夫するだけでなく、人間にとっても分かりにくい設計になっていないかを見直します。命名が曖昧、依存が絡み合っている、ドキュメントが実態と離れている、などです。

技術構成：不整合を定期的に検出する仕組みを置きます。

• ドキュメントと実装のズレを検知する
• 使われていない定義や、更新されていないルールを洗い出す
• エージェントが失敗した箇所を記録し、環境改善の対象にする

そして評価用データセットを持ち、プロンプト・構成・モデルを変えたときに品質が保たれているかを、感覚ではなく回帰テストとして検証します。

評価セットの例

合格条件は、「テストが通る」「特定の文字列を含まない」のように、できるだけ自動で判定できる形にします。最初は10件でも意味があります。 モデルの更新が続いた2026年は、評価セットがあるチームほど新しいモデルへ安心して乗り換えられました。

ここまで来ると、AI駆動開発は「AIにコードを書かせる取り組み」ではなく、「AIが安全かつ継続的に成果を出せるよう、開発プロセスとチームの働き方を再設計する取り組み」だと言えます。

もうひとつの軸：何を接続し、どこで走らせるか（実行基盤）

開発プロセスの軸とは別に、エージェントの実行基盤という軸があります。段階というより、並行して整えるものです。

3つの軸の関係は次のとおりです。7ステージを上がりながら、実行基盤と人の役割も並行して整えます。

flowchart TD
    P[開発プロセス<br>7ステージ] --> G[AIが安定して<br>成果を出す開発]
    I[実行基盤<br>MCP・権限] --> G
    H[人の役割<br>FDE] --> G

接続層：MCP で社内システムをつなぐ

MCP（Model Context Protocol）は、AIエージェントに外部のツールやデータを接続する規格です。2026年に入り、主要クラウドが公式の MCP サーバーを公開しました。

• AWS MCP Server：2026年5月6日に一般提供を開始。1つのツールで任意の AWS API を呼び出せるマネージドサーバーで、IAM のガードレール・CloudWatch メトリクス・CloudTrail ログで統制できます。6月5日にはクロスアカウント／クロスロールのアクセスに対応し、1セッション内で複数のアカウントと IAM ロールをまたいで作業できるようになりました
• Terraform MCP Server：6月11日に一般提供。AIが Terraform Registry と直接やり取りし、モジュール検索・最新バージョンの確認・推奨設定の参照を IDE の中で完結できます

2026年10月2日の発表で、AWS MCP Server の対応リージョンに東京（ap-northeast-1）を含む6リージョンが追加され、計8リージョンになりました。 以前は米国東部（バージニア北部）と欧州（フランクフルト）の2つだけだったため、データの所在に制約がある案件でも使いやすくなっています。

権限層：ここが本命かもしれない

AWS MCP Server の大きな意義は、性能面より「MCP 経由のリクエストかどうか」を IAM ポリシーで判定できるようになった点です。「人は変更操作ができるが、MCP サーバー経由は読み取り専用に限る」といった制御を、IAM ポリシーや SCP で書けます。CloudTrail で監査もできます。

これはステージ5「出力の機械的制約」のインフラ版です。お願いではなく、権限で止めます。順番は、IAM と SCP のガバナンス基盤、エージェント経由の課金上限を整えてから、接続を広げるです。MCP サーバー自体に追加料金はかかりませんが、エージェントが作ったリソースの課金は通常どおり発生するため、上限の設計は欠かせません。

MCP ならではのセキュリティの視点

接続先が増えるほど、1つのエージェントが次の3つを同時に持ちやすくなります。

1. 秘密情報へのアクセス
2. 信頼できない内容（Webページ、メールなど）の読み込み
3. 外部への送信

この3つがそろうと、読み込んだ内容に仕込まれた指示（プロンプトインジェクション）によって、情報が外へ持ち出されるおそれがあります。1つのエージェントに3つを同時に持たせず、接続する MCP を役割ごとに分けるのが対策です。

コスト層：トークンとクラウド課金の両方

AWS MCP Server のスクリプト実行機能は、「リソース一覧の取得 → 絞り込み → 個別 API の呼び出し」のような多段処理を、サンドボックス内の Python で一括処理できます。往復が減るため、トークン消費も減ります。

トークン面では、同じ前提（CLAUDE.md・仕様・ツール定義）を毎回読み直す作業にプロンプトキャッシュが効きます。2026年10月時点の Claude API の料金では、キャッシュの読み取り単価は入力単価の 20分の1です。

effort（思考の深さ）を作業ごとに変えることも同じ考え方です。Agent Teams はメンバーごとにトークンを使うため、並列化の効果とコストのバランスを見る必要があります。AI駆動開発のコストは、トークンとクラウド利用料の両方で見ます。

環境層：IaC で作業場そのものを作る

手動で作った環境の IaC 化も、MCP 経由で大きく楽になりました。既存リソースの情報を取得させ、terraform import や cdk import 用のコードを生成させる。1つずつ手で確認していた作業が、指示1回で終わるという報告もあります。

発展形は、エージェントごとに使い捨ての環境を払い出す構成です。ステージ6の worktree による作業空間の分離を、クラウド環境の単位へ広げるものです。

シャドー MCP という新しい論点

社員が個人的に外部の MCP サーバーを接続してしまう問題です。企業データが、把握されていない経路を通るおそれがあります。Cloudflare は2026年8月、「組織が承認していないサーバーへの接続」をシャドー MCP と定義し、プロトコルのヘッダーで MCP 通信を検出する仕組みと、社内の MCP を一元管理するポータルを含む構成を公開しました。

「誰が、どの MCP を、どのデータに接続しているか」を把握する必要がある、シャドー IT の再来と捉えると分かりやすいです。使ってよい MCP の一覧を用意し、申請の流れを決めておくのが対策です。

人の軸：FDE という役割

7ステージは開発の仕組みの話でしたが、もう一つの注目点は人の役割です。FDE（Forward Deployed Engineer）を取り上げます。

定義：顧客のプロジェクトに入り込み、業務を理解したうえでAIを組み込み、成果が出るところまで責任を持つエンジニア。起源は Palantir で、2026年には OpenAI や Anthropic も専門チームを持ち、AI業界で最も求められる職種の一つとして報じられています。日本ではまだ定義が定まっていない言葉なので、この記事では上の意味で使います。

FDE と、従来の開発の役割の違い

7ステージと FDE の関係

FDE は、ステージ3〜7を顧客のプロジェクトで立ち上げて定着させる人と位置づけられます。

• 顧客の業務を聞き取り、仕様としてファイルに落とす（ステージ3）
• 規約や用語を、CLAUDE.md や Skills としてリポジトリに入れる（ステージ4）
• 守るべきことを、フック・テスト・権限で仕組み化する（ステージ5・権限層）
• 作業を分解し、AIオーケストレーションで進める（ステージ6）
• うまくいかなかった箇所を記録し、評価セットで改善を回す（ステージ7）

AI駆動開発の仕組みは、作っただけでは成果になりません。顧客の業務の中で使われ続けて初めて価値になります。その「最後の距離」を埋めるのが FDE です。

SI・SES のエンジニアにとっての意味

顧客のプロジェクトに参画し、業務を理解しながら作る。これは SI・SES のエンジニアが日々取り組んでいる仕事そのものです。AI駆動開発の技術とオーケストレーションの力を身につけることで、その経験がそのまま FDE の力になっていきます。キャリアを考えるうえで、前向きな変化と捉えています。

進み方について、ひとつだけ

よくある質問

Q. 小さいチームでも、マルチエージェントは意味がありますか。 A. 人数とは別の話です。一人でも、役割を分けたエージェントを並列で走らせられます。人手が少ないほど効く面もあります。サブエージェントから始め、相談が必要な仕事で Agent Teams を試す順序がおすすめです。

Q. AIオーケストレーションは、何から練習すればいいですか。 A. 2つの作業を git worktree で分けて並行させるのがおすすめです。自分で統合すると、どこで衝突するか、何を先に決めておくべきかが体感できます。

Q. CLAUDE.md・Skills・Hooks は、どう使い分けますか。 A. 毎回知っておいてほしい事実は CLAUDE.md、特定の作業の手順は Skills、必ず守らせたいことは Hooks（や設定）です。CLAUDE.md に書いても守られないなら、Hooks へ移すサインです。

Q. 強いモデルが出たら、ステージを飛ばせますか。 A. 飛ばさないほうがうまくいきます。強いモデルほど任せる量が増えるため、ステージ5（制約）と7（評価）の重要性はむしろ上がります。モデル側に審査の仕組みが入ってきたのも、そのためと考えられます。

Q. アーキテクチャテストとは、具体的に何を書きますか。 A. レイヤー間の依存方向を検証するテストです。「domain 層は infrastructure 層を import していない」といった条件をテストコードとして書きます。Java なら ArchUnit、TypeScript なら dependency-cruiser などが使えます。

Q. 評価用データセットは、どう作りますか。 A. 過去に実際に起きた課題と合格条件を組にして貯めていくのが現実的です。最初は10件でも意味があります。

Q. FDE になるには、何が必要ですか。 A. 設計・実装・テストの基本に加え、顧客の業務を理解する力と、ステージ3〜7の仕組みを立ち上げる力です。顧客のプロジェクトで業務を学んだ経験は、大きな強みになります。

Q. 経験が浅くても、この流れに入れますか。 A. 入れます。ただし順番が大事で、まず自分の手で設計・実装・テストを回すところから始めます。自分で経験があるから、AIの出力の良し悪しを判断できるようになります。

まとめ

• AI駆動開発は、対話 → エディタ統合 → 仕様駆動 → 知識の資産化 → 制約の機械化 → 並列化 → 環境の改善、の7ステージで進む
• 進む順番は 3 → 4 → 5 → 6。特に5（仕組みで守る）を固めてから6（並列化）へ
• CLAUDE.md はお願い、Hooks と設定は仕組み。必ず守らせたいことは仕組みにする
• Agent Teams は実験的機能。まずはサブエージェントと worktree による分離から
• ステージ6の中心は AIオーケストレーション。人・親エージェント・チームの3つの型を使い分ける
• 実行基盤は、権限とコストを先に整えてから、MCP での接続を広げる。AWS MCP Server は東京リージョンにも対応した
• 評価セットを持つと、新しいモデルに安心して乗り換えられる
• 仕組みを顧客の業務に定着させる役割が FDE。SI・SES の経験がそのまま活きる

上位のステージほど、コードを書く速さより、問題をAIが実装できる形に分解する力と、出力を検証する力が効いてきます。設計とレビューが本丸になった、ということです。

参考・出典

確認日はいずれも 2026年10月10日です。

• Claude Code 公式ドキュメント「How Claude remembers your project（CLAUDE.md・AGENTS.md・rules）」：https://code.claude.com/docs/en/memory
• Claude Code 公式ドキュメント「Skills」：https://code.claude.com/docs/en/skills
• Claude Code 公式ドキュメント「Hooks reference」：https://code.claude.com/docs/en/hooks
• Claude Code 公式ドキュメント「Custom subagents」：https://code.claude.com/docs/en/sub-agents
• Claude Code 公式ドキュメント「Orchestrate teams of Claude Code sessions（Agent Teams）」：https://code.claude.com/docs/en/agent-teams
• Claude Code 公式ドキュメント「Run parallel sessions with worktrees」：https://code.claude.com/docs/en/worktrees
• Claude Code 公式ドキュメント「Manage costs effectively」：https://code.claude.com/docs/en/costs
• Claude API「Pricing」：https://platform.claude.com/docs/en/about-claude/pricing
• AWS「AWS MCP Server の一般提供を開始」（2026年5月6日）：https://aws.amazon.com/jp/about-aws/whats-new/2026/05/aws-mcp-server/
• クラスメソッド DevelopersIO「AWS MCP Server が東京リージョンをサポートしたので試してみた」（2026年10月3日）：https://dev.classmethod.jp/articles/aws-mcp-server-tokyo-region/
• Cloudflare Blog「How Cloudflare detects MCP traffic and helps secure it」（2026年8月14日）：https://blog.cloudflare.com/mcp-security-updates/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。