🎼

AIオーケストレーションの開発フローを整理したら、最後のボトルネックは人間だった

に公開
AI
Git
Claude
AIエージェント
Codex
idea

最近、AIオーケストレーションについての記事や公式資料を読む機会が増えました。

中心となるAIが仕事を分解し、専門のエージェントへ割り振る。複数のエージェントを並列に動かし、その結果を集約する。設計、実装、テスト、レビューに、それぞれ別の役割を持たせる。

個々の機能として読めば理解できます。しかし、それらが実際の開発でどのようにつながるのかは、少しイメージしにくいところがありました。

そこで、以前触れた開発環境での経験を思い出しながら、公開されているAIオーケストレーションの考え方と照らし合わせて、開発フロー全体を整理してみました。

要件を実装可能な単位へ分ける。
複数のGitリポジトリを同じ基点から動かす。
チケットごとにworktreeを作り、AIを並列に作業させる。
設計と実装で異なるAIを使い分ける。
セキュリティやドメイン知識の観点から、別のAIが実装を確認する。
PRやMRを作り、人間のレビュー指摘を再びAIへ戻す。
レビュー後に確定した変更を設計書へ反映する。
作業中に得られた知見を、次回以降に使うSkillsへ蓄積する。

こうして並べてみると、AIがコードを書くことよりも、前後の工程をどう接続するかの方が重要に見えてきます。

そして、最後まで運用してみると、少し皮肉な結論になりました。

技術的に一番難しかったのは、モデルの性能でも、複数リポジトリの管理でもありませんでした。

人間にAIを使ってもらうことでした。

全体像

AIオーケストレーションの全体構成

今回整理した構成では、中央にオーケストレーション用のコントローラープロジェクトがあります。

このプロジェクトは業務システム本体ではありません。フロントエンド、バックエンド、サーバー上で動く処理など、別々のGitリポジトリを管理し、変更依頼に応じて必要な作業を割り振るための制御基盤です。

大きな流れは次のようになります。

変更依頼
   ↓
オーケストレーション・コントローラー
   ↓
要件と作業をスライス
   ↓
対象リポジトリと担当AIを決定
   ↓
設計・実装・テスト・専門レビュー
   ↓
PR／MRと人間向けレビュー資料を作成
   ↓
人間レビュー
   ↓
指摘を取り込んで再修正
   ↓
確定した変更を設計書へ反映
   ↓
再利用できる知見をSkillsへ追加

単に複数のAIを起動するのではなく、誰に何を任せ、どの成果物を次の工程へ渡すのかを制御します。

Anthropicは、中央のエージェントが作業を分解し、複数のワーカーへ割り当てて結果を統合する構成を、Orchestrator-Workersパターンとして紹介しています。GitHub Copilot SDKにも、専門化したサブエージェントへ処理を委譲する仕組みがあります。

実際に触れた環境と同じ製品ではありませんが、中心となるコントローラーが作業を分解し、専門エージェントへ委譲する考え方は近いものです。

最初に要件を「スライス」する

変更依頼は、そのまま実装AIへ渡されるわけではありません。

最初に、要件や変更内容を、実装・確認・テストが可能な単位へ分解します。ここでは、この役割をスライサーAIと呼びます。

スライサーAIが整理するのは、例えば次の内容です。

項目 内容
対象リポジトリ フロントエンド、バックエンド、サーバー処理など
作業単位 個別に実装・確認できる機能単位
依存関係 先に必要な変更、同時に変更すべき箇所
受け入れ条件 何ができれば完了なのか
制約 変更してはいけない範囲、後方互換性
テスト観点 正常系、異常系、権限、再実行など 
要件
  ↓
スライサーAI
  ├─ 対象リポジトリ
  ├─ 作業単位
  ├─ 依存関係
  ├─ 受け入れ条件
  └─ テスト観点
       ↓
   設計・実装・テストへ

ここは全体の中でも特に重要です。

最初のスライスを間違えると、その後のAIが担当範囲内で正しく作業しても、システム全体では変更が不足します。

例えば、フロントエンドとバックエンドだけの変更と判断したものの、実際にはサーバー側のデータ形式にも影響していた場合です。それぞれのAIが自分の担当を正しく終えても、結合した時に問題が起きます。

AIの人数を増やすことよりも、AIへ渡す仕事をどう切るかの方が難しいのかもしれません。

複数のGitリポジトリを同じ基点から動かす

対象になっていたのは、一つのGitリポジトリだけではありませんでした。

フロントエンド、バックエンド、サーバー側の処理などが、それぞれ別のリポジトリになっています。

オーケストレーターは、各リポジトリの基準ブランチを取得し、同じリリースタグや対応する基準点から作業を始めます。

そのうえで、チケットや変更単位ごとにGit worktreeを作成します。

Frontend Repository
  ├─ worktree / Ticket-A
  ├─ worktree / Ticket-B
  └─ worktree / Ticket-C

Backend Repository
  ├─ worktree / Ticket-A
  ├─ worktree / Ticket-B
  └─ worktree / Ticket-C

Server Repository
  ├─ worktree / Ticket-A
  ├─ worktree / Ticket-B
  └─ worktree / Ticket-C

Git worktreeを使うと、一つのリポジトリに複数の作業ディレクトリを関連付け、異なるブランチを同時に扱えます。

チケット同士で変更対象が重なっていても、作業ディレクトリが分かれているため、実装途中の変更が混ざりません。

AIを並列に動かす場合、担当を分けるだけでは足りません。作業場所まで分ける必要があります。

一方で、複数リポジトリの変更は、Git上で完全に一つのトランザクションとしてマージできるわけではありません。

そのため、実運用では次の情報も管理する必要があります。

  • 各リポジトリの対応するPR／MR
  • マージ順序
  • デプロイ順序
  • 旧版と新版を混在させられるか
  • 後方互換性
  • ロールバック方法
  • 各リポジトリの対応コミット

例えば、変更単位に共通IDを付けておくと追跡しやすくなります。

Change Set: CHG-2026-0042

Frontend: PR #125 / commit abc123
Backend:  MR #842 / commit def456
Server:   PR #98  / commit ghi789
Design:   revision 7

設計と実装でAIを使い分ける

すべての工程を同じAIへ任せる構成ではありませんでした。

例えば、要件整理や設計はClaude系、実装はCodex系、実装後のセキュリティやドメイン観点の確認は再びClaude系というように、役割ごとにモデルを使い分けます。

ここで重要なのは、「Claudeは設計に強く、Codexは実装に強い」と固定的に断定することではありません。

作る役と確認する役を意図的に分けることです。

設計AI
  ↓
実装AI
  ↓
別のレビューAI

同じAIが設計し、実装し、自分の実装をレビューすると、実装時に置いた前提をレビュー時にも引き継ぎやすくなります。

設計を誤解していた場合、自分の誤解を前提として「問題ない」と判断する可能性があります。

別モデルや別コンテキストに分けても、完全に独立した確認になるわけではありません。両方が同じ曖昧な設計書を読めば、同じ誤解をすることもあります。

それでも、生成担当と評価担当を分けることには意味があります。

実装後は、複数の専門AIが並列に確認する

実装が終わると、一つのレビューAIだけが確認するのではありません。

複数の専門的な観点を持つAIが並列に動きます。

役割 確認する内容
セキュリティレビューAI 脆弱性、認証、認可、入力値、秘密情報
ドメインレビューAI 業務ルール、既存仕様、プロジェクト固有の制約
品質レビューAI 可読性、保守性、重複、設計方針
テストレビューAI テスト不足、異常系、境界値、横展開 
                 ┌─ セキュリティレビューAI
実装コード・差分 ├─ ドメインレビューAI
                 ├─ 品質レビューAI
                 └─ テストレビューAI
                           ↓
                     結果を集約

ただし、AIレビューだけで正しさを保証できるわけではありません。

次のような決定論的な確認も必要です。

  • コンパイルと型チェック
  • Lintと静的解析
  • ユニットテスト
  • 結合テスト
  • API契約テスト
  • セキュリティスキャン
  • DBマイグレーション検証
  • リポジトリ横断のE2Eテスト
  • 実行ログや画面の証跡

AIは意味や意図を確認し、テストや解析ツールは事実を確認する。この分担が重要です。

テスト仕様書まで流れの中で作られる

実装やユニットテストだけでなく、結合テストやE2Eテストの仕様書も作成されます。

テストAIは、スライサーが整理した作業単位、受け入れ条件、テスト観点を入力として、人間が確認するためのテスト仕様書を作ります。

ただし、自動生成されたテスト仕様書が、そのまま現場のリスクを十分に拾えるとは限りません。

正常系や単純な入力チェックは作れていても、実際の業務で問題になりやすい壊れ方が不足することがあります。

例えば、次のような観点です。

  • 権限が異なる場合
  • 同じ処理を二重に実行した場合
  • 途中で画面を閉じた場合
  • 失敗後に再実行した場合
  • 既存データと衝突した場合
  • コピーされた実装の片方だけが変更された場合
  • 別リポジトリとのバージョンがずれた場合

AIがテスト仕様書を作れることと、現場のリスクを十分に把握できることは別です。

この部分は、まだ人間が条件として返す必要があります。

PR／MRと一緒に、人間向けのレビュー資料も作る

各リポジトリの修正が終わると、コミットが作成され、PRまたはMRが提出されます。

その際、コード差分を人間に読ませるだけではありません。

コミットや差分から、人間向けのレビュー資料も作られます。

  • 何を変更したか
  • なぜ変更したか
  • どのファイルや機能へ影響するか
  • どのテストを実行したか
  • どこを重点的にレビューしてほしいか
  • 未確認事項は何か

この役割は、実装を検査するレビューAIとは別です。

専門レビューAIは、実装に問題がないかを確認します。レビュー資料生成AIは、人間が変更内容を理解して判断できる状態を作ります。

ただし、AIが作ったレビュー資料もAIの解釈です。

資料が整っているからといって、コードが正しいとは限りません。レビュー資料は証拠の代わりではなく、コード差分、テスト結果、ログ、設計書へたどるための索引として使う必要があります。

人間のレビュー指摘をAIが取り込む

PR／MRに人間がレビューコメントを書くと、その指摘をAIへ戻して再修正できます。

AIは対象のコメントとコード差分を読み、必要な修正を行い、テストを再実行して、PR／MRを更新します。

判断できない場合には、勝手に決めず、人間へ質問します。

人間レビュー
    ↓
レビュー指摘をAIが取得
    ↓
AIだけで判断できるか
  ├─ 判断できる → 修正・再テスト
  └─ 判断できない → 人間へ質問
                          ↓
                     修正・再テスト
                          ↓
                     PR／MRを更新

ここで気づいたのは、レビューコメントの書き方も変わるということです。

人間同士なら、

ここは共通化してください

という短い指摘でも、過去の経緯やチーム内の暗黙知から意図が伝わる場合があります。

AIは、その意図を別の方向へ補うことがあります。

AIに修正させるレビューでは、少なくとも次の内容が必要でした。

問題:
何が問題なのか。

理由:
なぜ変更する必要があるのか。

期待する修正:
どのような状態にしたいのか。

変更してはいけない範囲:
互換性や既存仕様などの制約。

完了条件:
どのテストや結果をもって完了とするか。

AIがレビュー指摘を自動処理するようになるほど、人間は「問題がある」と伝えるだけでは足りなくなります。

修正の意図や完了条件を、以前より明確に言語化する必要があります。

レビューで確定した内容が設計書へ戻る

さらに特徴的だったのは、レビューによってコードが変更された後、その内容が設計書にも反映されることです。

一般的な開発では、流れが一方向になりがちです。

要件
  ↓
設計
  ↓
実装
  ↓
レビューと修正

コードが修正されても、設計書は人間が別途更新しなければなりません。

更新が忘れられると、設計書と実際のコードが少しずつ離れていきます。

この構成では、最後に逆向きの流れがあります。

要件
  ↓
設計
  ↓
実装
  ↓
AIレビュー
  ↓
人間レビュー
  ↓
修正・テスト
  ↓
確定した変更
  ↓
設計書を更新

設計書が実装前に一度作られて終わるのではなく、レビューで確定した変更へ追従します。

ただし、コードを常に正として設計書へ反映するのは危険です。

誤った実装まで正式な仕様になってしまう可能性があります。

そのため、実装と設計が異なった時には、次の判断が必要です。

設計と実装が異なる
       ↓
設計変更として合意されたか
  ├─ Yes → 設計書を更新
  └─ No  → 実装を設計へ戻す

設計書の更新には、コード差分だけでなく、元の要件、レビューコメント、人間の回答、受け入れ条件、テスト結果まで使う必要があります。

作業中の知見をSkillsへ戻す

作業を続けていると、プロジェクト固有のルールが見つかります。

例えば、次のようなものです。

  • 変更箇所と似た処理への横展開確認を行う
  • コピーされた実装でも、実体が別なら個別にテストを書く
  • APIを変更する場合は後方互換性を確認する
  • 権限違い、再実行、途中離脱をテスト観点に含める
  • レビュー資料には変更理由と確認結果を書く

これらを毎回レビューで指摘するのではなく、オーケストレーター側のSkillsへ追加します。

特徴的なのは、AIが勝手にSkillsを増やすのではなく、

この内容をSkillへ追加しますか

と人間へ確認することです。

作業・レビュー
    ↓
再利用できそうな知見をAIが抽出
    ↓
Skillsへの追加を提案
    ↓
人間が内容・適用範囲・例外を確認
    ↓
Skillsへ登録
    ↓
次回の設計・実装・レビューで利用

これは、モデルそのものが再学習しているわけではありません。

チームの判断を、再利用可能な指示、スクリプト、チェック項目として蓄積している状態です。

このループが回ると、システムは少しずつ現場向けに育っていきます。

一方で、ルールを追加し続ければよいわけではありません。古くなったルール、重複したルール、特定のケースにしか使えないルールを整理する必要があります。

Skillには、一行の命令だけでなく、次の情報を持たせた方が安全です。

ルール:
実体が独立しているコピー実装には個別のテストを追加する。

理由:
片方の修正や障害が、もう片方のテストでは検出できないため。

適用対象:
独立して実行される処理、サービス、コンポーネント。

適用除外:
単純な定数、表示文言、実行経路を持たない複製。

確認方法:
各実体を個別に失敗させても、対応するテストが検出すること。

この構成で問題になりそうなところ

全体としてよくできた構成ですが、問題がないわけではありません。

スライスの誤りが全工程へ広がる

最上流で対象リポジトリや依存関係を見落とすと、その後の設計、実装、テストも誤った前提で進みます。

複数リポジトリの変更は同時にマージできない

マージ順序、デプロイ順序、後方互換性、ロールバック方法を管理する必要があります。

誤実装が設計書へ反映される可能性がある

設計同期の前に、設計変更として合意された内容なのかを判断するゲートが必要です。

複数のレビューAIが矛盾する

セキュリティ、業務要件、互換性、保守性の指摘が衝突することがあります。優先順位と人間へのエスカレーションが必要です。

Skillsが増えすぎる

ルールが重複、矛盾、陳腐化するため、追加だけでなく整理や廃止も必要です。

AIレビューだけでは正しさを証明できない

テスト、静的解析、ログ、人間の確認は残ります。

AIオーケストレーションは、AIへ全部任せる仕組みではありません。

どの判断をAIへ移し、どの判断を人間に残すかを管理する仕組みなのだと思います。

最後のボトルネックは、人間にAIを使ってもらうことだった

ここまでの仕組みを見ると、運用上の最大の問題は、複数リポジトリの管理やAIの精度にあるように思えます。

しかし、現場で一番大きな壁になったのは、AIを使いたくない人がいることでした。

AIそのものに嫌悪感や不安があると、仕組みの入口に立ってもらえません。

この開発フローは、人間を排除するものではありません。

人間が要件を補い、レビューの意図を書き、AIが判断できない内容を決め、見つかった知見をSkillsへ戻すことで成り立っています。

人間が参加しなければ、仕組みも育ちません。

それでも、次のような理由からAIを使いたくないと感じる人はいます。

  • AIの出力を信用できない
  • 最終的な責任だけ人間に残るのが不安
  • AI向けに詳しいレビューを書くのが面倒
  • 自分の仕事や経験を否定されたように感じる
  • コードや情報をAIへ渡すことが心配
  • 新しい作業方法を覚える余裕がない

これは単に、新しい技術を嫌っているという話ではありません。

AIオーケストレーションの導入は、ツールを一つ追加するだけではなく、要件の書き方、レビューの仕方、責任の分け方、開発の進め方を変えることだからです。

それでも、少し皮肉だと思いました。

AIによって人間の仕事がなくなるという話をよく聞きます。

ところが実際の現場では、AIが人間を置き換えることより先に、人間にAIを使ってもらえないことで、AIを前提にした開発フローが止まることがあります。

技術としては、要件から設計、実装、レビュー、設計書更新までつながり始めています。

最後に残るのは、AIの性能だけではありません。

人間がその仕組みを信用し、自分の仕事の一部として受け入れられるかどうかです。

AIを使えば人間が不要になるのではありません。

人間が参加しなければ、AIを使った仕組みも完成しない。

AIオーケストレーションを整理してみて、一番難しいと感じたのは、そこでした。

参考資料

（2026年8月1日確認）

Discussion