マルチエージェントハーネスの概念

マルチエージェントハーネスのコア概念を学びます。エージェント、スキル、PMオーケストレーション、3ティア戦略、PM Gateway、ディスパッチフロー、引き継ぎコントラクト — この章でハーネスの骨格のすべてを理解します。

エージェントとは

エージェントの定義

エージェントとは、特定の役割を与えられ、定められた行動指針に従ってタスクを実行するAIアシスタントです。一般的なチャットボットとは異なり、エージェントは固有の名前・役割・行動ルールを持ち、ファイルの読み書きやツールの使用を許可されます。

第1章で例えたように、エージェントは会社の従業員のようなものです。PMはチームリーダーであり、スペシャリストエージェントは各部署の専門家です。企画担当エージェント、デザイン担当エージェント、コーディング担当エージェントがそれぞれの持ち場を果たせば、プロジェクト全体が効率よく進みます。

エージェントの構成要素

各エージェントは4つのコア要素で構成されます。この4つが揃って1つのエージェントを定義します。

具体的には次のとおりです。

ハーネス内のエージェントタイプ

co-deckハーネスは、プレゼンテーションパイプラインの各段階ごとに責任を持つ複数のスペシャリストエージェントを定義しています。

エージェントファイルの例

以下は、エージェント定義ファイルがどのようなものかを示す簡略化した例です。実際のファイルにははるかに多くの詳細が含まれますが、この例で全体のイメージをつかめます。

# agents/research.md
---
name: research
tier: medium
phases: 1
role: >
  ウェブ資料を収集し、ストーリーライン設計のための
  research_notes.mdを作成します。
dispatch_triggers:
  - "トピックを調査して"
  - "資料を収集して"
  - "リサーチノートを書いて"
---
## Instructions
- 韓国語と英語の資料を両方検索します。
- 調査結果をresearch_notes.mdに書きます。
- URL、重要な事実、ソースの信頼性メモを含めます。
- スライドコンテンツは作りません — それはstorylineエージェントの役目です。

このファイルが、エージェントが何をするのか（role）、いつディスパッチされるのか（dispatch_triggers）、何をしてはいけないのか（Instructionsの禁止ルール）を明確に定義している点に注目してください。この明確さこそが、マルチエージェント協調を安定して機能させる核心です。

スキルとは

スキルの定義

スキルとは、エージェントが実行できる再利用可能なワークフローです。エージェントが「誰」であるなら、スキルはそのエージェントが「何をするか」を定義します。1つのスキルは複数のステップからなる作業手順であり、特定のトリガーによって自動的に有効化されます。

わかりやすく言えば、エージェントが料理人ならスキルは料理のレシピです。料理人（エージェント）は複数のレシピ（スキル）を持っており、注文が入ると（トリガー）該当するレシピに沿って料理を準備します。

スキルの構成要素

各スキルは次の4つの要素で構成されます。

スキル vs エージェント

エージェントとスキルは混同されがちですが、明確な違いがあります。

スキルの階層構造

co-deckでは、スキルは3つの場所で定義でき、それぞれ優先順位が異なります。

PMオーケストレーション

PM（Project Manager）エージェントの役割

PMエージェントはマルチエージェントハーネスの中心であり単一窓口（Single Point of Entry）です。ユーザーはPMにだけ直接リクエストを行い、PMがリクエストを分析して適切なスペシャリストエージェントを選び、作業を割り当てます。

PMの核心的な役割を段階ごとに整理すると次のとおりです。

PMオーケストレーションフロー図

PMは直接実行しない

PMの最も重要な特徴は、ファイルを直接書いたりコードを実行したりしないことです。PMはオーケストレーター（指揮者）としてスペシャリストエージェントに作業を指示するだけで、自ら成果物を作りません。

このルールが重要な理由は次のとおりです。

• 責任所在の明確化 — 成果物に問題があれば、その分野のスペシャリストエージェントが修正します。PMが直接作ったファイルなら「PMが直すべきか、スペシャリストが直すべきか」で混乱が生じます。
• 専門性の保証 — 各分野はスペシャリストエージェントが最もよく知っています。PMがデザインファイルを直接作れば、専門性が落ちるおそれがあります。
• ガバナンスの分離 — 調整（管理）と実行（作業）を分けると、システムはより安定して動きます。人間の組織でも管理者と実務者の役割が分かれているのと同じ原理です。

品質ゲート

パイプラインの特定の地点で、PMは作業を一時停止し、レビューのため成果物を提示します。こうしたチェックポイントをゲートと呼びます。ゲートには2種類あります。

• 必須ゲート — 明示的に承認するまでパイプラインは進めません。ゲート2（コンテンツ準備完了後）とゲート5（サンプルPDF生成後）は必須です。
• 任意ゲート — PMがサマリーを見せた後、自動的に続行します。ゲート1.5（ソース検証）、ゲート3（デザイン仕様）、そしてゲート4（HTMLドラフト）は任意です。

3ティア戦略

なぜ複数のAIモデルが必要なのか？

AIモデルは性能が高いほどコストも高くなります。複雑な設計作業に最上位モデルを使えば良い結果が得られますが、簡単なファイル検索やスクリプト実行にも最上位モデルを使うのは非効率です。

このコストと性能のバランスを取るため、ハーネスはAIモデルを3つの階層（ティア）に分けて割り当てます。会社にプリンシパルエンジニア、シニア、ジュニアがいるように、タスクの複雑さに応じて適切なモデルを選ぶのです。

3つのティア

3ティア比較表

核心ルール

上の比較表と合わせて、3ティア戦略で覚えておくべき核心ルールは次のとおりです。

• ティアは下げられても上げられることはない。PMは単純な作業のコストを節約するため、より低いティアのモデルを割り当てられますが、エージェントに定義された基本ティアより高いモデルを割り当てることはできません。下げたティアで作業が失敗した場合は、再試行時に必ずエージェントの基本ティアを復元します。
• オーケストレーターは常にHighティアを使う。PMはどのエージェントをディスパッチするか、どんな順序で実行するかといった最も重要な決定を下すため、常に最高レベルの推論で動作します。
• レビューアーは独立していなければならない。作業を遂行したエージェントがその成果物をレビューすることはありません。この分離は専任のQAチームを置くのと同じ原理で、実質的な品質管理を保証します。

PM Gateway

PM Gatewayの定義

PM Gatewayとは、すべてのスペシャリストエージェントがPMを通じてのみ呼び出されるよう強制するルールです。ユーザーはPMにだけリクエストし、PMが適切なスペシャリストエージェントを選んで作業を委任します。スペシャリストエージェント（例：research、design）への直接リクエストは許されません。

このルールは「なぜ」必要なのでしょうか？　3つの核心的理由があります。

• 統制（Control） — すべてのリクエストがPMを経由すれば、作業全体の流れを一箇所で管理できます。複数のスペシャリストエージェントが同じファイルを同時に修正したり、衝突する作業を行ったりするのを防ぎます。
• 一貫性（Consistency） — PMがリクエストの優先順位を決め、適切な順序でエージェントを配置します。これによりプロジェクト全体が一貫した流れを保ちます。
• 品質（Quality） — 各段階でPMが成果物をレビューし、次の段階へ進むか修正を求めるかを判断します。これにより最終成果物の品質が保証されます。

なぜゲートウェイなのか？

すべての社員が自由にCEOのもとへ行って指示を出せる会社を想像してください。大きな混乱が生じるでしょう。ハーネスでも同じです。ユーザーがdesignやresearchのようなスペシャリストエージェントを直接呼び出せてしまうと、PMはワークフローを計画し、順序を決め、品質をレビューする能力を失います。ゲートウェイはまさにこれを防ぐために存在します。

ゲートウェイの動作方式

PM Gatewayは4重の防御線で強制されます。多層防御（defense in depth）が互いを補完します。

すぐ次のセクションで、この4段階の強制層をダイアグラムで確認できます。

4段階強制レイヤー

PM Gatewayは4つの水準で強制されます。このうちどれか1つでも違反されれば、スペシャリストエージェントは実行されません。

PMの直接実行範囲

PM自身にも、直接実行できる作業に関する制限があります。

ディスパッチフロー

ディスパッチとは？

ディスパッチ（Dispatch）とは、PMがスペシャリストエージェントに作業を割り当てる過程を意味します。ユーザーのリクエストが入ると、PMはリクエストの性質を分析（トリアージ）し、適切なスペシャリストエージェントを選んで作業を指示します。

並列ディスパッチ vs 順次ディスパッチ

ディスパッチには2つのモードがあります。作業の性質に応じて適切なモードが選ばれます。

ディスパッチフロー図

ディスパッチの意思決定フロー

PMがリクエストを受けた後、どの方式でディスパッチするかを決める過程は次のとおりです。

引き継ぎコントラクト

引き継ぎとは？

引き継ぎ（Handoff）とは、エージェント間で作業結果を受け渡す方式を意味します。マルチエージェントハーネスでは、あるエージェントが完了させた成果物が次のエージェントの入力として使われます。このとき「どの形式で」「どのパスに」「どの品質基準を満たして」引き渡すかをあらかじめ定義しておく必要があります。この取り決めを引き継ぎコントラクト（Handoff Contract）と呼びます。

引き継ぎコントラクトの3要素

引き継ぎコントラクトは3つのコア要素で構成されます。

引き継ぎの例：research → storyline

co-deckで最も代表的な引き継ぎは、researchエージェントからstorylineエージェントへの引き渡しです。

ダイアグラムが示すように、researchエージェントが research_notes.md という形で出力すれば、storylineエージェントが同じファイルを入力として受け取り、自身の作業を行います。このとき research_notes.md のパス・ファイル名・内部構造（マークダウン形式、セクション構成など）が引き継ぎコントラクトによってあらかじめ定義されていなければなりません。

引き継ぎコントラクトが重要な理由

• 誤りの防止 — ファイル名が間違っていたりパスが誤っていたりすると、次のエージェントが入力を見つけられず、パイプライン全体が止まります。引き継ぎコントラクトがあれば、こうしたミスを防げます。
• 独立性の保証 — エージェント間の依存関係が明確になると、各エージェントを独立に開発・テストできます。「入力がAなら出力はB」という約束だけ守ればよいので、内部実装は自由に変更できます。
• 交換可能性 — 引き継ぎコントラクトさえ守れば、特定のエージェントを別のエージェントに置き換えられます。たとえばresearchエージェントをもっと性能の高いバージョンに変えても、出力形式が同じならstorylineエージェントは一切変更せずにそのまま動きます。

ハーネスアーキテクチャ全体図

この章で説明したすべての概念を1枚の図にまとめてみましょう。以下はco-deckハーネスの全体的なアーキテクチャを表すダイアグラムです。