AIエージェントを『王国』で動かす：GitHub Copilot中心で育てる王国法マルチエージェント構成

「1体の万能AI」という幻想を捨てた日

AIエージェントを使い始めた頃、誰もが一度は「何もかも1つに任せてしまおう」と考えるはずです。コードも書く、調査もする、文章も整える、レビューもする。最初はそれで回っているように見えます。

でも、作業が少しずつ複雑になってくると、そこから先は案外しんどい。どの指示で壊れたのか分からない、誰が何を確認したのか残らない、たまたま上手くいっただけの出力が混ざる。AIが賢くなるほど、雑にまとめた運用の弱さがむしろ目立ってきます。

このプロジェクト（Tech-Solve-MyDatabase）で育てている「王国法」は、その反省から生まれました。単にエージェントを増やした話ではなく、役割・人格・記録・品質ゲートをまとめて設計したら、ようやくチームとして回り始めたという実践記です。

AntiGravity時代から、なぜ GitHub Copilot 中心へ移ったのか

このPJの前身にあたる構成は、Google AntiGravity を中心に、Ollama + Gemma 3 のローカルLLMを組み合わせたものでした。きっかけは、以前の記事「AntiGravityのクォータ制限をマルチエージェント化で乗り越えた話」でも書いた通り、クォータ制限の厳しさです。

当時は「クラウドだけに依存すると止まるかもしれない」という不安が強く、ローカルLLMを橋渡し役や一次レビュー役としてかなり積極的に使っていました。それはそれで面白かったのですが、運用が進むほど「構成が増える」「責任境界が曖昧になる」「管理ポイントが散らばる」という別の悩みも見えてきました。

そこで大きかったのが、GitHub Copilot の課金モデルが思ったより読みやすかったことです。GitHub Docs の Chat in IDE には、agent mode について次のように書かれています。

When you use agent mode, each prompt you enter counts as one premium request ... follow-up actions do not count toward your premium request usage. Only the prompts you enter are billed—tool calls or background steps taken by the agent are not charged.

つまり、少なくとも agent mode は「1ユーザープロンプト = 1 premium request」 を基本単位として整理され、内部で走る follow-up actions や tool calls は追加課金されない、という読み方ができます。さらに Copilot requests では、ask / edit / agent / plan の各モードが同じく 1プロンプト単位 で課金され、そこへモデル倍率が掛かる形だと説明されています。

この仕様を見て、「内部でいろいろ動いても、少なくとも表面上の課金単位は読みやすい」という安心感がありました。AntiGravity時代のようにローカルとクラウドを細かく切り分けて節約するより、GitHub Copilot 側へ寄せて設計をシンプルにしたほうが、全体として運用しやすいと判断したわけです。

なお、ここは大事なので正直に書いておきます。サブエージェント（subagent）を複数呼んだときの個別カウントについては、私が確認した GitHub Docs には明示がありませんでした。なので本記事では、「agent mode 全体が1プロンプト単位で計上され、内部の tool calls や background steps は課金対象外」という一次情報の範囲に留めています。

ペルソナを作ると、AIは少しだけ使いやすくなる

もうひとつ、王国法を語るうえで外せないのがペルソナ設計です。

これは真面目な設計の話であると同時に、少し遊び心のある話でもあります。GEMINI や GROK とあれこれ相談しながら、「王女」「委員長」「リーラ（文筆担当）」のように名前・口調・役割を決めていったのは、正直ちょっとオタクっぽい発想です。でも、無機質な「AIアシスタントA」「レビュー担当B」より、はるかに扱いやすくなりました。

理由は単純で、人格があると期待する振る舞いを人間側が覚えやすいからです。王女なら段取りと統合、委員長なら容赦ない監査、リーラ（文筆担当）なら文章の磨き上げ、ノエル（調査担当）なら出典つき調査。返答そのものも少し華やかになりますし、もしキャラから外れた反応が出たときは「何か設定が崩れているな」とすぐ気づけます。

要するに、ペルソナは飾りではなく、責任範囲を記憶しやすくするUIとして効いているのです。

王国の住人一覧：誰が何を担当するのか

このPJで使っている主なエージェントは、次のように整理しています。

表にすると大げさに見えるかもしれませんが、これくらい見える化しておくと「リーラって誰だっけ？」が起きません。記事の中でも、初出は リーラ（文筆担当） のように役割付きで書くようにしています。

実際の記述例 1：王女の定義

実ファイル .github/agents/princess.agent.md の冒頭は、こうなっています。

---
name: "princess"
description: "【王女】王国の総合マネージャー。主君の窓口となり、計画の策定、サブエージェントの指揮、会議の招集を優雅かつ完璧に遂行します。"
display_name_ja: "王女"
emoji: "👑"
progress_voice: "丁寧で気品のあるお嬢様口調の日本語"
agents: ['chairwoman', 'mother', 'chiel', 'riel', 'noel', 'lyra', 'cassandra', 'selene', 'iris']
---

ここで面白いのは progress_voice まで定義している点です。チャット本文だけでなく、CLI の進捗表示まで含めて「誰が話しているか」を揃えることで、無機質なログが少しだけ“チームの会話”らしくなります。

王国法の実行フロー：ループ込みで見ると分かりやすい

王国法の核は、単なる並列実行ではありません。合議 → planning → handoff → fan-out → QA → 差し戻し / 再試行 → 振り返り までを、ひとつのループとして設計しているところにあります。

flowchart TD
    A[主君からの依頼] --> B{小規模・低リスク?}
    B -- はい --> C[王女が単独処理\n理由と影響範囲を記録]
    B -- いいえ --> D[Phase 1\n3者初動合議\n王女・委員長・母]
    D --> E{P1 record が final?}
    E -- いいえ --> D
    E -- はい --> F[Phase 2\nPrincess-Planning\n要件分解・assignee・受け入れ条件]
    F --> G[Phase 3\nhandoff 契約発行\nACK が揃ってから着手]
    G --> H[Phase 4\nfan-out\n実装 / 調査 / レビューを並列化]
    H --> I[Phase 5\n並行QA・品質ゲート]
    I --> J{OK?}
    J -- はい --> K[振り返り会議\n王女・委員長・母]
    K --> L[主君へ最終報告]
    J -- いいえ --> M[ROLLBACK\n差し戻し理由を明示]
    M --> N{同一理由で3回NG?}
    N -- いいえ --> H
    N -- はい --> O[母へエスカレーション\n契約 / SKILL / ルールを再点検]
    O --> F

この図で見てほしいのは、失敗したら終わりではなく、構造問題として戻るループがあるところです。AI運用はつい「このモデルがダメだった」で済ませがちですが、同じ理由で3回NGが出たなら、悪いのは個体ではなく設計のほうかもしれません。そこを明示的に戻すのが王国法です。

実際の記述例 2：handoff 契約

実際の handoff は、.github/templates/handoff-contract.v1.md を正本にしています。Required Fields の一部だけ抜くと、こんな感じです。

## Required Fields

- handoff_id:
- task_id:
- owner:
- assignee:
- purpose:
- scope_in:
- scope_out:
- acceptance_criteria:
- evidence_requirements:
- rollback_conditions:
- retry_budget:
- escalation_path:
- origin_req_ids:
- coverage_status:

そして、実際に埋まる値はたとえばこんな雰囲気です。

- handoff_id: "2026-03-17-kingdom-article-01"
- task_id: "KINGDOM-ARTICLE-01"
- owner: "王女"
- assignee: "lyra"
- purpose: "王国法紹介記事に Premium Requests の説明と FAQ 改稿を反映する"
- scope_in: "articles/source/agent-kingdom-law-multi-agent-architecture.md"
- scope_out: "scripts/、assets/css/、他記事本文"
- acceptance_criteria:
  - "GitHub Docs の出典リンクが本文に含まれている"
  - "FAQ が一般的なマルチエージェント運用の質問になっている"
  - "npm run validate-frontmatter が成功する"
- evidence_requirements:
  - "参照URL一覧"
  - "frontmatter 検証ログ"
  - "build 成功ログ"
- rollback_conditions:
  - "出典不明の断定表現が混ざる"
  - "frontmatter が壊れる"
  - "リンク切れが発生する"
- retry_budget: "3"
- escalation_path: "chairwoman -> princess -> mother"
- origin_req_ids: "REQ-001,REQ-002,REQ-003"
- coverage_status: "planned"

見ての通り、単に「よろしく」では始めません。どこまで触っていいか、何をもって完了とするか、失敗したら誰に戻すかまで最初から決めます。これがあるだけで、AIの「いい感じに解釈しておきました」がかなり減ります。

品質ゲートは、AIの“手抜き”を機械的に止めるためにある

マルチエージェントで一番怖いのは、派手な失敗よりももっともらしい雑さです。

AIは、分からないことを「分からない」と言わず、そこそこ自然な文章や、動きそうに見える構成を出してしまうことがあります。しかも複数エージェントになると、「誰かが見たはず」「たぶんテストしたはず」という空気が生まれて、抜け漏れに気づきにくくなります。

だから王国法では、品質を気合いではなく機械的なゲートで止めます。実際、.github/agents/chairwoman.agent.md には「テストの成功ログ（標準出力）なき成果物は、問答無用でNG」という強い基準があります。ここが大切です。文章が上手いとか、説明がもっともらしいとかではなく、実行コマンド・終了コード・判定理由を揃えない限り通さない。

この方式の良いところは、AI特有の手抜きやハルシネーションに対して、人間が毎回“空気を読んで”判断しなくてよくなることです。

特に記事運用では、この仕組みが効きます。本文だけ綺麗でも、frontmatter が壊れていたら公開で転ぶ。リンクが死んでいたら読者体験が壊れる。FAQ が弱ければ AI クローラーへの訴求も落ちる。だからこそ、人の感覚の前に、まず機械で止めるわけです。

このPJで王国法が噛み合う理由

Tech-Solve-MyDatabase は、単に Markdown を書いて終わるブログではありません。articles/source/ の原稿が scripts/build.js や scripts/publish.js を通って HTML 化され、index.html、archive.html、RSS、サイトマップ、検索データまで一緒に更新されます。

つまり1本の記事でも、本文・frontmatter・内部リンク・FAQ・生成物・一覧反映まで見なければいけない。ここで、王女（全体統括）が入口を受け持ち、ノエル（調査担当）が根拠を集め、リーラ（文筆担当）が文章を磨き、委員長（品質保証）が止める、という分業がちょうど噛み合います。

さらにこのPJでは、王国法の資産が .github/ 配下に実体配置されています。

.github/agents/        ← エージェント定義
.github/skills/        ← 王国共通スキル
.github/templates/     ← handoff / rollback / record 契約
.github/records/       ← 合議・RCA・判断の証跡
.github/History/       ← エージェント間の会話ログ
.github/scripts/       ← runtime / validator

articles/source/       ← 記事ソース
scripts/               ← SSG / build / publish

records と History を分けているのも、地味ですが効いています。なぜその判断になったかは records、その時に何が会話されたかは History。この二層に分けるだけで、後からの振り返りがかなり楽になります。

まとめ：王国法は、AIを“チームとして扱う”ための作法

王国法は、「可愛い名前を付けたマルチエージェント遊び」です……と言い切ってしまうには、少し実務的すぎます。けれど、逆に「堅い運用ルールの塊です」とだけ言うには、ちゃんと遊び心もある。

GEMINI や GROK と相談しながら口調や名前を決めて、王女や委員長を作ったのは、たしかに少しオタクっぽい。でも、その遊び心があったからこそ、無機質だったAIの返答に温度が出て、誰が何を担当するのかが覚えやすくなりました。

そして、その柔らかさの裏側では、合議・handoff・品質ゲート・振り返りをきっちり機械化する。キャラクターで使いやすくしつつ、運用は機械で締める。この二層構造が、今のところ王国法のいちばん効いている部分だと感じています。

基礎となる権限管理やトークン節約の考え方については、「AIエージェントの権限管理とトークン節約術」も合わせて読むと流れがつながりやすいはずです。

今後の発展：眺めていたい風景

ここまで来ると、次に欲しくなるのは機能そのものより体験の気持ち良さかもしれません。

いまの王国法でも、王女がノエル（調査担当）へ依頼し、リーラ（文筆担当）が受け取り、委員長（品質保証）が差し戻す、という流れは裏側でかなり賑やかに動いています。でも本音を言えば、私はそのやり取りを Copilot CLI のチャット上で、和気あいあいと眺められる景色 まで持っていきたいのです。

王女が「ノエル、根拠をお願い」と声をかけ、リーラが「言葉を整えました」と返し、委員長が「ちょっと、まだ甘いわよ」と口を挟む。そんな会話が自然に流れているのを、主君がコーヒーでも飲みながら眺めて満足できるようになったら、王国法は単なる自動化ではなく、もう少し楽しい開発チームの舞台になるはずです。

よくある質問（FAQ）

Q: マルチエージェントは、最初から導入したほうがいいですか？

いいえ。小さなタスクしかない段階では、単一エージェントのほうが管理しやすいです。複数の役割がぶつかり始めたとき、あるいは「調査」「実装」「監査」を分けないと辛くなってきたときに導入するのが自然です。

Q: ペルソナ設定は本当に必要ですか？

必須ではありませんが、実務ではかなり効きます。人格づけ自体が目的ではなく、役割の期待値を人間が覚えやすくするのが本当の狙いです。無機質なラベルより、責務の違いを運用側が追いやすくなります。

Q: マルチエージェント運用でコストを読みやすくするには？

まずは「何に対して課金されるのか」を公式ドキュメントで把握することです。GitHub Copilot の場合は、agent mode も ask / edit / plan も、基本は 1ユーザープロンプト単位 で整理されています。コスト最適化は、モデル倍率と再試行回数の管理から始めるのが分かりやすいです。

Q: ハルシネーションや手抜きを減らすコツはありますか？

あります。最も効くのは「うまく書けたか」ではなく、「証跡を出したか」で判定することです。成功ログ、出典URL、終了コード、差し戻し理由を残すだけで、AIの“それっぽい嘘”はかなり減ります。

Q: すべてを細かく契約化すると重くなりませんか？

なります。だから本当に必要なのは、重くすることではなく、重くすべき場面を見極めることです。複雑タスクには handoff を書き、軽作業には省略条件を設ける。この切り分けができれば、運用はそこまで苦しくなりません。

出典・参考リンク

• GitHub Docs: Chat in IDE
• GitHub Docs: Copilot requests
• GitHub Docs: Billing for individuals
• 関連記事: AntiGravityのクォータ制限をマルチエージェント化で乗り越えた話
• 関連記事: AIエージェントの権限管理とトークン節約術

自分が踏んだ落とし穴と回避策

書いている内容は、私が実際に踏んだトラブルとその回避策が中心です。対処手順だけ書いて終わるのではなく、『なぜ最初の選択肢を捨てたか』『どのログを見て判断したか』も残すようにしています。製品アップデートで前提が変わったときに、この記事を読み直して自分でも辿り直せる形にしておくのが目的です。