AIエージェントのオーケストレーションに関する取り組みを紹介します。

ソフトウェアファクトリーのためのオーケストレーション

AI活用のスタイルは、人が介入する度合いによって、下記のように4つの段階に分けられます。下の段階ほど人の介入が少ないです。

  1. ChatGPTなどのチャットボットをブラウザから利用する
  2. Claude CodeやCodexなどのAIエージェントとバイブコーディングを行う
  3. 人間が親チケットと子チケット（GitHub Issue）を作成し、人間が各チケットをAIエージェントに割り振る
  4. 人間は親チケットだけを作成し、タスクの分解と割り振りはオーケストレーター役のAIエージェントが行う（これがオーケストレーション）

これは優劣を表すものでなく、自動化の度合いで分類しているにすぎません。ただ、現在構築中のソフトウェアファクトリーでは、できる限り人間の介入を減らして開発の効率と速度を上げようというアプローチをとりますから、畢竟オーケストレーションを選択することになります。

オーケストレーションのOverview

オーケストレーションの流れは次のようになっています。

粒度の大きな親IssueをユーザーまたはAIが作成する。
        │
        ▼
オーケストレーターが親Issueを子Issueにブレイクダウン。ワーカー（サブエージェント）に実行させる。
   ├─ 子Issue A ── ワーカー（サブエージェント）A ── PR A
   ├─ 子Issue B ── ワーカー B ── PR B
   └─ 子Issue C ── ワーカー C ── PR C
        │
        ▼
各作業結果を統合・検証
        │
        ▼
全て終了後、親Issueのクローズ

下記が主なオーケストレーターの仕事になります。

  • ユーザーとの直接窓口
  • タスクのブレイクダウン
  • タスクごとの依存関係の整理
  • タスクの割り振り
  • 各サブエージェントの管理（指示出しと報告の受領、そして中断したサブエージェントの再開）

この作業はスキルとして実装しています。AIがIssueをユーザーから割り振られたらそのスキルが発動し、規定通りに作業をすすめるわけです。言い方を変えると、オーケストレーションはスキル一つで実行可能なのです。これ自体はさほど難しくありません。

ただし、なにも工夫せずオーケストレーションだけ行うと、このような問題が起きます。

  • 後から追えない: どのように作業したのかわからないまま現物だけわたされます。自分で後で確認しようとした際にこれはかなり困ります。
  • 作業結果が安定しない: AIに作業の多くを委譲する -> 人が介入しないため途中で止めたりチェックしたりする機会が減る -> 作られる成果物もその品質も激しくばらつく という流れで、結果が安定しません
  • サブエージェントが途中で止まる: ハーネスの記述に疑問がある等の理由でサブエージェントが停止することがあります。そのたびに人が介入せざるを得なくなります。正当な理由で止まるならいいのですが、些細なことや読み違いでも止まるため厄介です。

本番で利用できるようにするため、こういった問題をどう軽減あるいは解決するかが課題となります。

オーケストレーションを本番で活用するためにやっている工夫

当社では下記のような取り組みをしています。

GitHub Issueを経由した作業指示

ユーザーからオーケストレーター（全体を指揮するエージェント）への指示も、オーケストレーターからワーカー（実際に作業を行うサブエージェント）への指示も、原則としてGitHub Issueを通して行います。

通常のプロセスを進めるだけで指示の内容がIssueに残るため、手間暇の削減と記録漏れ防止になっています。作業のやり直しも依頼しやすくなります。

一方、オーケストレーターがワーカーに直接プロンプトを与える方法もありますが、こちらは手軽なものの運用中に追跡調査がしづらいため、実務では採用しづらいと感じています。

致命的な事象以外での途中停止の回避

ワーカーが質問や必要なファイルの用意を依頼するために途中で停止することがあります。 こういう場合は、できる限りオーケストレーターが対応し、ワーカーに再実行させるようにしています。この作業を人間が行っていると効率が大きく下がるため、事実上必須の仕組みです。

ただし、オーケストレーターでも解決できない事象があります。例えばCognitoなどAWSのリソースが構築されていない場合がこれにあたります。当社はAWS本番環境の操作権限をAIに与えていないため、いくらオーケストレーターでもこれは解決できません。こういった本当に人間の介入が必要になるケースでは素直に停止させています。

ハーネスの整備

ハーネスの整備はAI駆動開発における品質保証の基本です。AIに任せる範囲が広いオーケストレーションでは、その重要度がさらに大きくなります。

コーディング標準、作業ワークフロー、そのワークフローで使うテストツール、CI/CDの整備など、やることは多岐に渡ります。

また日々の運用を通してこれらは継続的に改善しています。

ワーカーが保持するコンテキストの最小化

ハーネスを整備すると今度はコンテキストが肥大化しがちになります。そこで、ワーカーが読む必要のあるコンテキストがなるべく少なく済むようにします。

ポイントは関心領域を分離することです。例えばAPI用のGoコードを書かせる場合、Golang用のAGENTS.md、Skills、コーディング標準などだけ読むようにし、TypeScriptやウェブデザインなどの別領域のコンテキストにはそもそも触れさせません。

結果として、各ワーカーは特定の領域のコンテキストだけを保持する専用エージェントのように動作します。

トークンコストの節約と回答品質の向上を狙った工夫です。

成果物を基準にした進行

プロセスではなく成果物を基準にした進行を取り入れています。前段のプロセスがうまく動かなかった場合に異常に気が付きやすくなるためです。

これをやらないと、たとえばユーザーシナリオを作る -> E2Eテストを作るというワークフローがあるとして、ユーザーシナリオが実際にはうまく作られなかったのにE2Eテストだけ先に作ってしまってーー何の根拠もなしに作ったでっち上げになりますーー、やりなおしになる、といったことが起こります。

そこで次の作業へ進むために必要な成果物がそろっていることをプロセス開始の条件に組み込んでいます。ただし全てのプロセスではないです。

小さな作業には簡易版で対応

これはちょっとしたTIPSです。

README.mdを数行直す程度の作業にまで正規のワークフローでオーケストレーションを行うのは非効率です。

そのため、小規模な作業には簡易手順の利用を認めています。

整備が大変だが、それでもオーケストレーションは便利

オーケストレーションを実際に利用しようとすると、品質保証等様々な課題の解決を迫られるようになります。本番環境で運用する場合は品質保証が厳しく問われるため、ホビーユースやR&Dと同じようにはいかないのです。むしろオーケストレーションの構築作業はそちらが本体と言っても差し支えないくらいです。

しかし、その苦労に見合うだけのメリットがオーケストレーションには存在します。かつてなら自分でブレイクダウンや割り振りまで行わねばならなかったであろう大きな粒度のIssueを、AIエージェントに任せられるようになったことで、当社でも開発速度が従来と比較にならないほど向上しました。

まだオーケストレーションを試していない方は、ぜひこの機会に試してみて頂きたいと思います。