Agent Roundtable：ローカルなマルチエージェント専門家ラウンドテーブルシステムを構築する

最近、私は agent_roundtable というマルチエージェントチャットプロジェクトを構築した。

発想はシンプルだ。テーマを与えると、システムが異なる方向性の「専門家エージェント」を順番に発言させ、司会役が追跡質問・接続・要約を行い、最後に全体の議論を Markdown レポートとして保存する。

これは単なるチャットボットではない。ローカルのエージェントワークフローとして、役割を設定し、モデルを設定し、ローカル知識ベースを接続し、議論のプロセスをドキュメントとして蓄積するものだ。

私はこれを「専門家ラウンドテーブルツール」と捉えている。つまり、1 つのモデルで全質問に一度に答えさせるのではなく、同じテーマを異なる視点のエージェントに分解して議論させる、という設計だ。

一、なぜこのプロジェクトを作ったのか

以前からずっと考えていた。実用的な AI Agent システムとは、いったいどうあるべきなのか。

単一エージェント（Single Agent）は扱いやすい。プロンプトを投げれば質問に回答し、ツールを呼び出し、要約を作ることができる。これで多くのことは可能だ。しかし問題が複雑になると、単一エージェントの限界は明確になる。

• 複数の視点を混在させやすい。
• 複数の専門的な役割を安定して演じるのが難しい。
• 回答が「総合エッセイ」のようになりやすく、実際の討論にはなりにくい。
• 「マクロ経済視点」「投資視点」「AI 技術視点」「哲学的視点」「歴史戦略視点」を明確に分けにくい。

だから、私はマルチエージェントのラウンドテーブルを作りたかった。

1 つのテーマを複数の専門家に分担して議論させる。 マクロ経済の専門家は制度とサイクルを見て、投資専門家はキャッシュフローとリスクを見て、AI 専門家は技術の進化を見て、哲学専門家は概念と価値判断を見て、歴史戦略専門家は長期構造を見て議論する。

こうすると、出力は「1 つのモデルの回答」から、構造化された議論へと変わる。

二、今このプロジェクトでできること

agent_roundtable は現在、ローカルで実行する Python プロジェクトとして、CLI とローカル Web UI の 2 方式に対応している。

主な機能は以下の通り。

• CLI またはローカル Streamlit UI からマルチエージェントラウンドテーブルを起動できる。
• 各エージェントごとに provider、モデル、API キーの環境変数名を個別に設定できる。
• API キーは .env のみで管理し、JSON/YAML/ログ/レポートには書き込まない。
• メインの専門家エージェントは各自のローカル長文資料を読み取り、RAG で関連情報を検索できる。
• 実行結果は自動的に logs/ に保存され、Markdown レポートが生成される。
• レポートには各発言で使われた provider と model を明記する。
• API キーがなくても --mock を使って、全体フローを先に通すことができる。

現在、2 つの内蔵ラウンドテーブルがある。

ここは特に強調しておきたいが、persona_inspired は「本人の代替」ではなく「スタイルのインスピレーション」だ。本人を装うものではなく、本人の見解を保証するものでもない。回答を組み立てるための思考スタイルの借用として使う。

三、Agent への私の理解

今「Agent」という言葉は流行っているが、抽象的に語りすぎると理解しづらくなる。

私の理解では、Agent は「会話できるモデル」ではなく、目的に沿ってタスクを実行するシステム単位だ。通常、次のような要素で構成される。

• 役割または目標。
• 一連のプロンプトと行動制約。
• 呼び出し可能なツール群。
• 更新可能な状態。
• 必要に応じた記憶、知識ベース、ワークフロー制御。

普通のチャットは「1 問いかけ、1 回答する」。 それに対し Agent は「1 つの目的を達成するために、次に何をすべきかを自分で判断する」。

Tool Use を加えると、検索、ファイル、データベース、コード実行などのツールを呼び出せる。 RAG を加えると、先に資料を調べてから回答する。 ワークフローを加えれば、複数の Agent が一定の順序で協調できる。

これが agent_roundtable を作る理由だ。プロンプトだけに留まらず、役割・知識・モデル呼び出し・実行フローをプログラムとして実装したかった。 エージェント基礎から ReAct パラダイム、記憶と RAG の入門まで興味があるなら、 『Hello-Agents：AI Agent をゼロから構築するためのオープンソースチュートリアル』 を参照してほしい。

四、なぜ一つのスーパー Agent ではなくマルチ Agent なのか

スーパー Agent でも複雑な問題に答えることはできる。しかし私はマルチ Agent の形を好む。

理由はシンプルだ。現実の複雑な判断は、本来ひとつの声音だけで完結しない。

例えば「AI が投資と雇用に与える長期的影響」を議論する場合、少なくとも次の視点に分解できる。

1 つのモデルに全部を一度に答えさせても、これらのポイントは網羅されるかもしれないが、本当に視点が分かれる構造にはなりにくい。

マルチ Agent の利点は、各エージェントが独自のロールカード、知識範囲、話し方、盲点を持つことだ。議論時に異なる方向から切り込み、司会がそれらをつなぐ。

これは単に長いプロンプトを書くより堅牢で、拡張もしやすい。

五、RAG の役割

RAG は、分かりやすく言えば「持ち込み試験」である。

通常の LLM は既存のパラメータ知識に依存して回答する。 一方 RAG は、回答生成の前に外部知識ベースから関連資料を検索し、得られた情報をモデル参照に回す。

agent_roundtable では、ローカル長文資料を knowledge/ ディレクトリに置いている。各専門家ごとに対応する知識フォルダを割り当てられる。

knowledge/macro_economist/
knowledge/investing_master/
knowledge/ai_researcher/
knowledge/philosophy_expert/
knowledge/history_strategist/

その後、コマンドでインデックスを作る。

python -m rag.ingest --expert-name macro_economist --embedding-provider keyword

現時点では keyword 検索を優先している。追加の API キーを必要とせず、ローカルテストや入門に向いているからだ。将来的により強力な意味検索が必要になったら、embedding モデルを追加で接続する予定だ。

この設計は私にとって重要だ。

専門家エージェントに、モデル自身の「印象」だけで答えさせたくない。 事前に用意した書籍・論文・長文資料を読み込ませ、それを知識背景として使えるようにしたい。

こうすることで、Agent は単なるロールプレイのプロンプトではなく、ローカル知識を持つ専門家システムの原型になる。

六、プロジェクト構成

大まかな構成は次の通り。

agent_roundtable/
├── main.py
├── ui/
│   └── app.py
├── src/
│   ├── graph.py
│   ├── agents.py
│   ├── llm.py
│   ├── model_catalog.py
│   ├── agent_llm_config.py
│   ├── loader.py
│   ├── logger.py
│   ├── prompts.py
│   └── state.py
├── agents/
│   ├── domain_experts/
│   └── persona_inspired/
├── councils/
├── configs/
│   └── agent_llms.json
├── knowledge/
├── rag/
├── vector_db/chroma/
├── logs/
├── tests/
├── requirements.txt
└── .env.example

主要ディレクトリの役割は以下。

私はこの分離方針が好きだ。 ロールはロール、モデル設定はモデル設定、知識ベースは知識ベース、実行ログは実行ログとして分ける。混在させない。

七、Agent のロールカード設計

このプロジェクトでは、各エージェントが独自の YAML ロールカードを持つ。

一般的に1枚の Agent ロールカードには以下が含まれる。

• 名前。
• 役割。
• 世界観。
• 話し方。
• 強み。
• 弱み。
• 対応する RAG 知識ディレクトリ。
• エージェントタイプ。

たとえば、エネルギー専門家は次のように設計できる。

name: "Energy Expert"
role: "エネルギー・産業政策の専門家"
worldview: "エネルギー供給・インフラ・地政学・技術代替の観点から問題を分析する"
speaking_style: "明確で慎重。まず制約を示し、次に判断を述べる"
strengths:
  - "エネルギー需給分析"
  - "産業連関の分解"
weaknesses:
  - "金融市場の短期変動を過小評価しがち"
catchphrases:
  - "まずエネルギー制約を見ろ"
rag_expert_name: "energy_expert"
agent_type: "domain_expert"
profile:
  focus:
    - "エネルギー安全保障"
    - "電力システム"
    - "石油・ガスと再生可能エネルギー"

重要なのは「人間のような設定小説」を書くことではなく、分析の境界を固定することだ。

良い専門家エージェントとは、自分が得意なことを知っているだけでなく、何を見落としがちなかも理解しているものだ。 でないと、最後は全員が同じ声音に収束してしまう。

八、モデル設定を別管理にした理由

各エージェントで使うモデルは configs/agent_llms.json に独立して置いている。

これは役割とモデルを切り離すためだ。

ロールカードは「このエージェントは誰か」を記述するだけ。JSON 設定は「このエージェントがどの provider、どのモデル、どの API キー環境変数を使うか」を記述するだけ。

例：

{
  "agents": {
    "macro_economist": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-super-120b-a12b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    },
    "ai_researcher": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-ultra-550b-a55b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    }
  }
}

ここで api_key_env が API キー本体ではないことに注意。あくまで .env のどの変数を参照するかを示すものにすぎない。

実際の API キーを JSON、YAML、README、ログ、スクリーンショットに書くべきではない。これは重要だ。

九、ローカル UI の意味

このプロジェクトではローカル Streamlit UI を追加した。

これは美しい商用製品を作るためではなく、設定を直感的に扱うためだ。

UI でできることは次の通り。

• ラウンドテーブルの選択。
• 各エージェントの provider の設定。
• 各エージェントのモデル設定。
• 各エージェントの .env API キー選択。
• configs/agent_llms.json への設定保存。
• テーマ入力後、実際の LLM を直接実行。
• 実行進捗、現在ステージ、最新イベントの確認。
• 最終要約と対話履歴のプレビュー。

この UI は実務的に非常に役立つ。

マルチ Agent システムが拡張されると、設定ファイルの手編集はだんだん面倒になる。UI は複雑である必要はないが、少なくともモデルとラウンドテーブルを素早く切り替え、異なる組み合わせを試せることが重要だ。

十、MCP と Tool Use：今後の接続可能性

agent_roundtable の現時点の主眼は、ローカルのマルチ Agent ラウンドテーブル、RAG、レポート生成だ。MCP はまだ中核実装ではないが、自然な次のステップである。

MCP は Model Context Protocol の略で、AI アプリが外部ツールやデータソースに接続するためのオープンプロトコルと理解できる。モデルとツール、データベース、ファイルシステム、業務システムの接続方法を標準化することを目指す。

RAG が主に「先に調べてから回答する」を解決するのに対し、MCP は「Agent が外部ツールを標準的に接続し、アクションを実行する」を解決する。

したがって、この記事では agent_roundtable をすでに MCP 完全導入済みとしては扱わない。より正確には、まずローカルでマルチ Agent ワークフローを成立させ、将来の MCP と Tool Use 導入のためのインターフェース余地を残している。

このプロジェクトの将来としては次の MCP 能力が考えられる。

• ファイルシステム MCP を接続し、エージェントがローカル資料を標準的に読み込めるようにする。
• 検索 MCP を接続し、一部のエージェントがネットワークで検証できるようにする。
• データベース MCP を接続し、金融・マクロのエージェントが構造化データを照会できるようにする。
• GitHub MCP を接続し、技術エージェントがリポジトリ・Issue・コードを分析できるようにする。
• カレンダー、メール、タスクシステムに接続し、ラウンドテーブルの結果を次のアクションに落とし込めるようにする。

ただし、いまの段階で MCP を一気に複雑化させるつもりはない。

まずはローカル RAG、ロール設定、モデル呼び出し、レポート生成という主軸を確実に動かすことを優先する。主軸が安定したら、MCP をツール層として追加する。

十一、ReAct と LangGraph の関係

ReAct は古典的な Agent アイデアで、言語モデルを推論と行動の間で交互に進める設計。 言い換えれば、モデルが直接答えるだけでなく、考えながら、ツールを呼び、結果に応じて次の一手を決めるものだ。

LangGraph はよりワークフロー編成寄りだ。 Agent のプロセスをグラフとしてモデリングする。ノードはエージェント、ツール、判断ロジック、要約器であり、エッジがフローの流れを表す。

マルチ Agent ラウンドテーブルはこの図式で理解しやすい。

flowchart TD
    A["司会が質問を提示"] --> B["専門家が順に発言"]
    B --> C["司会が小結"]
    C --> D["次ラウンドの追跡質問"]
    D --> B
    C --> E["最終要約"]

これは単純な連結呼び出しではなく、状態・順序・役割分担を持つワークフローだ。

現在の私の設計もこの方向を踏襲している。先にラウンドテーブルの流れを作り、次に各エージェント発言、最後に要約とログ化を行う。 将来さらに強化するなら、次のような条件分岐を追加できる。

• あるエージェントが証拠不足を検出したら、検索をトリガーする。
• 2 人のエージェント見解が衝突したら、司会が追跡質問する。
• あるラウンドの議論品質が低い場合、自動で反論ラウンドを追加する。
• 最終レポート生成前に、事実検証エージェントを追加する。

ここに、Agent ワークフローの本当の面白さがある。

十二、オープンソース化での注意点

このプロジェクトにはローカル知識ベース、API キー、実行ログが含まれるため、公開時は特に注意が必要だ。

.gitignore ではデフォルトで次の種類を除外している。

• .env：実 API キー。
• knowledge/**/*.md：ローカルの書籍・論文・長文資料。
• logs/**：実行レポート。
• vector_db/chroma/**：ローカルベクトルインデックス。
• __pycache__/、.pytest_cache/ などの一時ファイル。

GitHub にコミットしてよいのは通常、

• コード。
• README。
• agents/*.yaml。
• councils/*.yaml。
• configs/agent_llms.json。
• knowledge/README.md。
• .gitkeep のプレースホルダファイル。

特に knowledge/ は慎重に扱う必要がある。

著作権のある書籍、論文全文、プライベート資料、有料コンテンツが含まれる場合は公開リポジトリへ上げるべきではない。 オープンソースとして公開できるのは、構成と使い方のデモに必要な範囲に留めるべきだ。

十三、このプロジェクトが私にとっての意味

私にとって agent_roundtable は単なるおもちゃではない。

これまで別々に磨いてきた複数の方向性を一つにまとめたものだ。

• AI Agent。
• マルチエージェント協調。
• RAG 知識ベース。
• Tool Use。
• ローカルワークフロー。
• モデル設定管理。
• Markdown レポート生成。
• 実用使用を想定した UI。

また、拡張性も高い。

将来は、マクロ経済、投資、AI、歴史、哲学、占術、プログラミングなど、テーマごとに別々の専門家システムを構築できる。各専門家が独自の資料庫、ロールカード、モデル設定を持ち、ユーザーはテーマを入力するだけで同一テーマについて異なる専門家に議論してもらえる。

これは、ただいくつかのプロンプトを書くより、はるかにシステムらしい。

このプロジェクトは現在、Python で完全実装され、研究・実験フェーズ寄りだ。将来ユーザー向け製品化するなら言語選定が別の論点になる。その点は、 『AI Agent における言語選択：Python、TypeScript、次世代のプロダクトエンジニアリング』 で述べた。

私はますます、将来の多くの AI アプリケーションは「1 つのチャット窓で全部解決」ではなく、複数の役割・ツール・知識ベース・ワークフローの組み合わせになると感じている。

agent_roundtable はこの方向への私の実践の一つだ。

よくある質問

agent_roundtable とは？

ローカルで動作するマルチエージェント専門家ラウンドテーブルプロジェクトだ。 テーマを与えると、システムが異なる方向の専門家エージェントを順番に発言させ、司会が追跡質問・接続・要約を行い、最後に全体の議論を Markdown レポートとして保存する。CLI とローカル Streamlit UI の 2 方式に対応し、各エージェントで provider、モデル、API キー環境変数を個別設定できる。

なぜ単一のスーパー Agent ではなくマルチ Agent なのか？

現実の複雑判断は、1 つの声音で完結しない。 マルチ Agent の利点は、各エージェントが独自のロールカード・知識範囲・話し方・盲点を持ち、議論時に異なる方向から切り込み、司会がそれらをつなげる点にある。 これは 1 つの超長プロンプトを書くより安定し、拡張もしやすい。

API キーがなくても実行できるか？

できる。--mock モードを使えば、API キーなしで全体フローを先に通せる。RAG 検索もデフォルトでまず keyword 方式を優先するため、追加の embedding API キーを必要とせず、ローカルテストと入門に向いている。

このプロジェクトは MCP に接続済みか？

まだ接続していない。agent_roundtable の現在の重点は、ローカルマルチ Agent ラウンドテーブル、RAG、レポート生成であり、MCP と Tool Use は自然な次のステップにあたる。プロジェクトは将来の接続のためのインターフェース余地を残しているが、まだ中核実装ではない。

オープンソース化する際の API キーや機密データ漏えい防止は？

実 API キーは .env のみに置き、設定ファイルには api_key_env の変数名のみを書き、キーそのものは記載しない。.gitignore でデフォルト除外しているのは .env、knowledge/ 配下のローカル資料、logs/ の実行レポート、vector_db/chroma/ のベクトルインデックスであり、公開リポジトリに含めるのはコード、README、ロールカード、configs/agent_llms.json、プレースホルダファイルのみだ。

参考情報源

• Random-Walk2026/agent_roundtable GitHub リポジトリ
• Model Context Protocol 公式ドキュメント
• Anthropic：Introducing the Model Context Protocol
• LangGraph 公式ページ
• LangGraph：Multi-Agent Workflows
• ReAct: Synergizing Reasoning and Acting in Language Models
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks