機能解説 01: オーケストレーションエンジン

最初の依頼から検証済みパッチまで

Agent Argo は、単一のモデルができるだけ長く一つのタスクに取り組むという構成ではありません。ソフトウェア開発の作業を、追跡可能なステップへと変換するシステムです。すなわち、計画し、分割し、処理し、検証し、修正し、それから初めて適用に向けて提示するという流れです。

本記事をもって連載 「機能解説」 が始まります。この連載は、Agent Argo の中核となる仕組みを理解できるようにするものです。マーケティング上の約束事ではなく、実際の運用に沿って説明します。最初はオーケストレーションエンジンです。要求を制御された作業プロセスへと変えるその手順を扱います。

1. 開始前: 品質・コスト・自律性を定める

Argo がタスクを処理する前に、二つの決定が重要です。これらは意図的に切り離されています。

1. Argo はコストと成果の品質の間でどう权衡（バランス）をとるべきか？
2. Argo はプロジェクト内でどれだけ自律的に行動してよいか？

これにより、典型的な目標の対立を防ぎます。丁寧な実行だからといって、自動的に書き込み権限が大きくなるわけではありません。また、自律的な実行だからといって、自動的に高価なモデルを選ぶわけでもありません。

コストと品質の三つの段階

モデルルーターは、分かりやすい三つのモードを持ちます。これらは、価格とモデル階層が選択にどれほど強く反映されるかを変えます。必要なスキルは常に中心に据えられます。

段階	ルーターモード	適しているもの
節約	economy	ルーチン作業、抽出、明確に範囲が限定された変更。コストの比重が強い。
バランス	balanced	多くの実行における標準: スキルの適合性、コスト、品質階層が均衡を保つ。
本格的	expert	アーキテクチャ、調査、複雑な分析、高度なレビュー。モデル階層の比重が明らかに強く、コストは弱い。

迅速＆安価、バランス、念入り という運用プロファイルは、このルーターモードを他の決定と束ねたものです。たとえば、共同思考を観察のみにするか実際に実行するか、検証を必須にするか、失敗時に Argo がより強くエスカレーションしてよいか、などです。

自律性の三つの段階

自律性は、Argo が何を正しいと考えているかではなく、それに対していつ人間が必要になるかを規定します。

段階	挙動
安全	Argo は分析し計画する。変更は検査のために留め置かれ、書き込みやリスクのある操作の前には確認を求める。
バランス	通常の変更は分離された作業状態で生み出せる。削除、コマンド、ダウンロード、ネットワークアクセス、保護されたパスの場合は Argo は引き続き確認を求める。
完全自律	実行は通常の確認なしで進む。ただし、厳格なセキュリティ・ポリシー・予算の境界は引き続き適用される。

コード上では、これらの規則は readonly、confirm_write、auto_write、bypass としてより正確に実装されています。三つの段階はこれらを操作しやすくするものです。しかし、プロジェクトポリシーは常に最終的な権限を持ちます。たとえばクラウドプロバイダーを除外したり、ローカルモデルのみを許可したり、ネットワークアクセスを遮断したり、コマンドを制限したり、シークレットを保護したり、コスト上限を設けたりできます。

2. CEO層が依頼を計画へと変える

ユーザーはまず目標を普通の言葉で記述します。Argo の CEO 層は、限定されたプロジェクト概要、利用可能なモデルカタログ、関連するプロジェクト情報を受け取ります。不明点があればまず確認したり、あるいは計画を生成したりできます。

計画には単なる To-do リストだけが含まれるわけではありません。各タスクには役割、説明、依存関係、必要な能力（たとえば coding、planning、qa_review、context_comprehension）が与えられます。難しいタスクにはより高い難易度が記されることもあります。CEO 層はここでモデルを硬直的に指定するのではなく、作業を記述し、ルーターが後でタスクごとに適切なモデルを決定します。

こうして計画は、人間が読める形での取り組みに関する合意事項として残り、実行は適応的に保たれます。

3. 計画はタスクグラフへと変わる

計画の承認後、Argo はタスクをタスクグラフへと変換します。あるノードは、その依存関係が正常に完了するまで実行を開始できません。独立したタスクは並行して実行できます。

スケジューラは、準備完了したノードを追跡可能な便益ヒューリスティクスで並べます。すなわち、期待品質からコスト・時間・リスクのペナルティを引いたものです。あるノードがクリティカルパス上にあれば、同着の場合に優先されます。なぜならそれが実行全体の所要時間を決めるからです。

不確実性やリスクが高い場合、Argo は処理前に共同思考モードを選択できます。複数の視点がアプローチを練り、互いに批判し、ワーカーへの根拠のある作業方針を提供します。これが単に記録されるだけか実際に実行されるかは、実行前に選ばれた運用プロファイルが決定します。

4. 各タスクの前に: 適切な文脈、適切な能力、適切なモデル

ワーカーが開始する前に、Argo は役割とタスクに合わせた文脈を構築します。そこには関連ファイル、依存結果、および（有効化されていれば）コンパクトなメモリパッケージと適したスキル手引きが含まれます。Argo はプロジェクト全体の知識を無条件にプロンプトへ入れることはありません。メモリとスキルは、関連性・出所・鮮度・コスト・セキュリティ状態に基づいて選択されます。

次にモデルルーターがモデルを選びます。まず、到達不能、十分なコンテキスト窓がない、割り当てを使い切った、あるいは有効なポリシーに違反する候補は除外されます。残ったモデルについて、Argo は四つの要素を評価します。

• 能力適合: 必要なスキルに対して各モデルがどれほど良く評価されているか。複数スキルの場合は平均値を見る。
• コスト: リクエストの費用、あるいはコストルーティング有効時はおそらく成功する結果の費用か。
• モデル階層: 難易度が高く、セキュリティ上重要な、アーキテクチャやレビューのタスクではフラグシップ階層を優先してよい。
• 実績値: 十分な実際の結果が蓄まると、あるモデル・スキル組み合わせの直近の成功率と反復率が反映される。

コスト計算のために Argo は Expected Cost of Success（成功の期待コスト） を使えます。直接の価格、期待される再試行、検証の手間、考えられる手戻り、そしてわずかな遅延ペナルティです。したがって、個々の呼び出しが安くても、頻繁に失敗したり手戻りを引き起こしたりするなら、自動的に最も安い解決にはなりません。

明示的なモデル推奨は、利用可能であり、ポリシーで許可され、コンテキストに対して十分な大きさがある場合にのみ受け入れられます。CEO 層の計画・委任・文脈理解には、これら三つの能力のために特に選ばれた強力なモデルが用いられます。

5. ワーカーは小さく検証可能なステップでタスクを処理する

ワーカーは単一の回答で動くわけではありません。限られた ReAct ループを通ります。

1. モデルが構造化されたアクションを提案する――たとえばファイルの読み取り、検索、テスト実行、変更の書き込みなど。
2. エグゼキューターが権限、パス、コマンドリスク、有効ポリシーを検査する。
3. Argo は許可されたアクションのみを実行する。
4. 結果、差分、エラーメッセージが観察としてモデルへ戻る。
5. これをもとにワーカーは次のステップを修正するか、タスクを完了する。

これにより、たとえばエージェントは該当コードをまず読み、次に変更を加え、テストを実行し、その結果を次の判断に組み込めます。全体の流れは実行ログに見える形で残ります。

出力自体も検査されます。モデルが無効なアクション JSON を返した場合、Argo は限られた修復ループを要求できます。厳格モードでは、恒常的に誤った出力は、不明なテキストをアクションとして解釈するのではなく、制御されて拒否されます。

6. エラー時: 盲目的な繰り返しではなく的確に修正

失敗したタスクがすべて実行の失敗を意味するわけではありません。オーケストレーションエンジンはエラーの原因を区別し、制御されて対応します。

• 一時的なエラーは、固定された境界内で再試行できる。
• 厳格な検証結果は、その具体的な指摘を次の試行への指示として提供する。
• カスケードが有効なら、次の試行は前の試行の知見を引き継ぎ、ゼロから始めない。
• 失敗後、Argo はより強いモデルを優先してよい。
• 予算を使い果たした場合、高価な盲目的試行は開始されない。ノードは文書化された部分結果で終わるか、可視的にエスカレーションされる。

ノード戦略は最終的に、タスクをスキップできるか、制御されて失敗とするか、ユーザー判断が必要かを決定します。依存タスクには、確定した部分結果のみが渡されます。これにより、局所的なエラーが残りの計画へと静かに広がることはありません。

7. 実装後: レビュー、検証、そして可能な追加サイクル

計画されたタスクが処理されたら、Argo は統合された状態を複数の視点から検査します。

• QAエージェント はファイルを読み、テストコマンドを実行できる。
• アーキテクチャエージェント は構造を読み取りで検査し、意図的に書き込み権限を持たない。
• 決定論的検証器は、テスト、型検査、リントを客観的オラクルとして実行できる。
• モデルベースと決定論的の所見は、総合判定へと統合される。

QA、アーキテクチャ、または必須の検証器が問題を見つけた場合、Argo は所見を該当タスクへ割り当てます。これらのタスクのみが具体的なフィードバックとともに再処理されます。その後、再びレビューと検証が続きます。コンセンサスモードがなければこのループは限られています。明示的に選ばれたコンセンサスモードでは、ユーザーが停止するか検査者が合意するまで続きます。

観察モードの検証器は所見を記録するだけでブロックしません。必須モードでは、厳格な所見が結果を成功とみなすことを防げます。こうして、追跡可能性を失うことなく運用プロファイルごとに厳格さを選べます。

8. 状態が検査されて初めて: 文書化とCEO要約

完了した作業・検査サイクルの後、文書化エージェントが変更を記録できます。その後、CEO 層がユーザー向けの要約を作成します。何が完了したか？何が未解決か？どの検査が走ったか？どのファイルや決定が影響を受けたか？

結果はチャットの文章以上のものです。実行は、計画、モデル選択、コスト、アクション、検証判定、ユーザー割り込み、後のパッチ決定のための共通識別子を持ちます。これにより、Argo がどう結果に至ったかを追跡できます。

9. 最後に実際のワークスペースについては人間が決定する

標準では、Argo は分離されたワークツリーで動きます。変更はそこにパッチとしてあり、実際のプロジェクトに静かに入るわけではありません。自律性段階により、その後に次の三つのうちのいずれかが起きます。

• パッチは、採用・部分適用・編集・破棄のために留め置かれる。
• 成功したパッチは自動的に適用される。
• 途中で変更されたファイルとの衝突時、Argo は可視的に停止する。他者の変更を上書きしない。

失敗した実行は自動的に適用されません。非常に自律的な設定でもポリシーを無効にするわけではありません。シークレット保護、コマンド規則、プロバイダー境界、予算上限、必要なヒューマンゲートは引き続き有効です。

オーケストレーションエンジンが果たす役割

オーケストレーションエンジンは、次にどのモデルが応答するかだけを決めるものではありません。ユーザーの意図、設定、計画、並列化、モデル選択、ツール利用、エラー修正、品質保証、安全な適用を、一貫した流れへと結びつけます。

基準は「できるだけ多くのエージェント」ではありません。追加の作業は、それが正当な場合にのみ生じます。難しいアーキテクチャ判断のためのより強いモデル、不確実時の第二の思考経路、検証指摘後の的確なリトライ、リスクある影響前の人間の承認、などです。

これで方針は定まりました。