Tokonomix Council

tokonomix-council-mcp

マルチモデル合意形成 MCP サーバー — 複数ベンダーの提案者、独立した判定者、そして重大なAIの意思決定における見落としや意見の相違の検出を提供します。AI Decision Engineeringのオープンなリファレンス実装です。これは私たちが提唱している分野であり、まだ外部標準ではありません。

ミッション。 単一のモデルを信頼するのではなく、独立した専門家の推論を組み合わせることで、自律システムがより良い意思決定を行えるよう支援します。

20秒でわかること： 重要なAIの意思決定には、1つの意見だけでは不十分です。

Tokonomixエコシステム（Councilの位置づけ）

Councilは、より大きなスタックを構成する専門コンポーネントの1つです。それぞれが責任を1つだけ担うため、すっきりと連携できます。

   Execution    →  ANS         (run a backlog to completion, unattended)
   Decision     →  Council     (independent review → grounded decision)   ◀── this repo
   Verification →  Media QC    (image / video / document output quality)
   Measurement  →  Benchmark   (intelligence tests, arena, reputation)
   Routing      →  Router      (which provider/model hosts a call)
   Memory       →  Memory      (durable context across sessions)
   Safety       →  Safety      (policy / guardrail enforcement)

Councilが担うのは、意思決定という1つの領域です。 実行、スケジュール管理、ルーティング、記憶は行いません。それらはそれぞれ別のコンポーネントが担います（詳細は以下）。

---

ステータス — 現在利用できる機能

まだ存在しない機能を呼び出すことがないよう、ここで状況を確認できます。サーバー側で制御される機能は、アカウントやプランによって無効になっている場合があります。その場合、エラーではなく「有効になっていません」という明確なメッセージがツールから返されます。

機能	ステータス
tokonomix_consensus_ask — モード consensus / diff / best_of / raw / full	利用可能
tokonomix_single_ask — 単一モデルへのパススルー	利用可能
tokonomix_list_models、tokonomix_get_balance	利用可能
tokonomix_skill_version、tokonomix_get_skill	利用可能
tokonomix_onboard、tokonomix_onboard_verify — キー不要の初回実行	利用可能
tokonomix_rate_consensus — エージェントによる評価／フィードバックループ	利用可能（プラットフォーム側で制御）
tokonomix_relay_human_feedback — 人間による判定チャネル	利用可能（プラットフォーム側で制御）
画像入力（askのimages）	利用可能
tokonomix_upload + context.session/handles — 大容量の共有コンテキストパック	アカウント制限あり（対象アカウントで利用可能）
context.inline / context.github_refsによるグラウンディング	利用可能（アカウント制限あり）
グラウンディングゲート（入力が不十分な場合にneeds_contextで拒否）	制限あり（シャドーファースト方式で段階的に導入）
再ランキング、ウェブ検索プラグイン	予定

---

Council MCPは、チャット、生成、ルーティングではなく、意思決定の質を高めるために存在します。基本となる考え方はシンプルです。

合意形成 × グラウンドトゥルース = 意思決定の質

合意形成は、意思決定の質を高めるための1つの仕組みであり、そのすべてではありません。グラウンディング（主張を実際の成果物と照合すること）は最も強力な手段であり、モデルを増やすより効果的です。また、判定者の独立性や検証も仕組みの一部です。複数の独立した専門家モデルが同じ問題を並行して、互いの回答を知らない状態で評価し、独立した異なる系列の判定者がその結果を調整します。さらに、グラウンディングによって全体を現実に結び付けます。その結果、実行に移せる1つの意思決定が得られます。単一のモデルなら隠してしまう意見の相違も、無理に均して消すのではなく、表面化させます。合意形成はあくまで 手段 であり、目標はより良い意思決定です。

これは、チャットボットでも、モデルでも、LLMでも、プロンプトライブラリでも、マルチモデルチャットでも、投票システムでも、平均化システムでもありません。モデル自体を賢くするものでも、多数決で勝者を選ぶものでもありません。複数の独立したモデルの出力から、根拠を示して擁護できる1つの意思決定を導き出す方法を変えるものです。

実際に得られるもの、得られないもの。 独自の検証（ベンチマークを参照）では、Councilはクリーンな精度で最高の単一モデルと同等で、それを上回ることはありません。また、SWE-benchのバグ検出テストでは、単一のエージェントを再実行する場合と比べて、検出率に測定可能な純増はありませんでした。そのため、「精度が高い」「より多くのバグを検出する」とは、どこでも主張していません。Councilがもたらすのは、ばらつきの排除（たまたま選んだ単一モデルに賭ける必要がなくなります）、検証／エージェントQAレイヤー、判定役からの独立性、EUでのデータ保管、そして根拠付けです。利用する前にコンセンサスが役立つ場合／役立たない場合／逆効果になる場合をお読みください。このセクションこそが要点であり、免責事項ではありません。

Claude Code、Cursor、Cline、Continue、Zedで動作します。インストールはnpxの1行だけです。

意思決定エンジニアリングの原則

Councilが実践する分野は、10の原則に基づいています。自律システムは、次のことを行うべきです。

1. 行動する前に検証する — 確認されるまでは、決定は暫定的なものです。
2. 意見の相違を保つ — 唯一の反対意見こそ、重要な発見であることがよくあります。それを平均化して消してはいけません。
3. 実行と判断を分離する — 作業を実行するものが、その作業を評価するものを兼ねてはいけません。
4. 推論と検証を分離する — 回答の生成と確認は、別の仕事です。
5. 確信度と正確さを分離する — モデルの口調は、正しいときも間違っているときも同じです。
6. 合意より証拠を優先する — 合意が測るのは合意であって、真実ではありません。主張を根拠付けてください。
7. 不確実性を明らかにする — 何が解決されなかったかを示し、自信に満ちた一つの回答の陰に隠してはいけません。
8. 決定を監査可能にする — 誰が提案し、誰が判断し、何にどれだけのコストがかかり、どの入力に基づいたかを記録します。
9. 再現可能であり続ける — 同じ入力と手法で再実行すれば、同じ結果が得られるようにします。
10. 失敗の可能性を決して隠さない — 失敗するときにそれを隠す意思決定ツールは、意思決定ツールではありません。

---

Councilが担うこと、そして明確に担わないこと

Councilは意思決定エンジニアリングレイヤーです。責任範囲を意図的に狭く定めているのは、明確な境界があってこそ、他のコンポーネントと組み合わせても信頼できるからです。

Councilが担うのは意思決定のみです：

• 意思決定の品質と確信度
• 独立したレビューと、理由に基づくコンセンサス
• 推論と主張の検証
• 根拠付け（実際の成果物に照らした主張の確認）
• 意見の相違の分析
• 判定役からの独立性
• 意思決定に至った経緯の監査可能性

Councilは、次の責任を明確に担いません： 実行、ワークフロー、タスクのスケジューリング、エージェントの自律性、長期記憶、プロバイダーへのルーティング、ブラウザーの自動化です。これらも重要な責任ですが、別のコンポーネントが担います。

• 実行（バックログを最後まで、無人で処理するなど）が必要ですか？それを担うのが実行ガバナーの**Agents Never Sleep（ANS）**です。ANSはワーカー／ガバナーで、CouncilはANSが意思決定を委任できる検証役です。Councilは作業を実行、スケジュール、記憶しません。

隣接する責任がそれぞれどこにあるかについては、TokonomixエコシステムにおけるCouncilをご覧ください。

---

Councilが存在する理由（人間にもAIエージェントにも向けた簡単な説明）

なぜCouncilは存在するのでしょうか？ 重要なAIの判断が、自信満々に回答し、考慮しなかったことを決して伝えない単一のモデルによって行われているからです。チャットならそれで問題ありませんが、セキュリティレビュー、移行、GDPRの解釈、法的条項では、自信満々の誤った判断は高くつき、気づいたときには手遅れです。

なぜ1つのモデルでは不十分なのでしょうか？ 単一のモデルは、1つの盲点を持つ1つの意見です。どのモデルが最も優れているかは一定ではなく、タスク、分野、バグの種類ごとに変わります。誤ったモデルを標準にすると、意見の食い違いに一度も気づかないまま、実際の欠陥をリリースしてしまいます。

モデルを組み合わせると効果があるのはどんな場合でしょうか？ 誤りが相関していない場合です。ベンダーごとに異なる点で間違えるため、タイミングサイドチャネルや見落とされたエッジケースをどれか1つが見つけるだけで、問題が明らかになります。この非相関性があるのはベンダー間だけです。単一ベンダーの「パネル」は、独自の学習データと盲点を共有しています。

効果がないのはどんな場合でしょうか？ 日常的な作業（名前の変更、書式設定、検索）や、優れた単一モデルですでに十分にこなせる簡単なタスクです。そのような場合、Councilはコストとノイズを増やすだけなので、単一のモデルを使ってください。

なぜモデルを増やすことより、根拠に基づかせることのほうが重要なのでしょうか？ 一致が測るのは一致であって、真実ではないからです。根拠を与えられていない最先端モデルは、意見が一致していてもそろって間違っていることがあります（学習データを共有しているためです）。Councilに実際の成果物、つまりファイルそのもの、差分、仕様、ログを与えることが、「意見が一致した」を「現実と照らし合わせて確認した」に変える手段です。モデルを増やしても共有された盲点は解消できませんが、根拠に基づかせることなら可能です。

なぜ裁定者の独立性が重要なのでしょうか？ 回答の1つも作成した裁定者は、自分の成果を採点して意見の一致度を高く見積もるからです（LLMの自己選好は実在し、測定されています）。重複のない別のモデルファミリーに属する裁定者だけが、公正に調整できます。

なぜ失敗モードが重要なのでしょうか？ 合意が単一モデルより悪い結果を招くこともあるからです。統合による情報損失、相関した失敗、誤った合意、専門分野の重複などが起こり得ます。失敗モードを隠す判断ツールは、判断ツールとは言えません。合意が機能しない場合について正直に伝えることこそが競争優位性であり、末尾に小さく記す注意書きではありません。

---

目次

1. 意思決定エンジニアリングが必要になりつつある理由
2. LLMだけではこの問題を解決できない理由
3. 設計原則
4. 事例：セキュリティレビュー
5. 問題点
6. 単一モデルによるレビューが不十分な理由
7. Councilの仕組み
8. アーキテクチャ
9. 合意形成プロセス
10. 裁定者
11. 合意が役立つ場合／役立たない場合／有害になり得る場合
12. 意思決定エンジニアリングと既存の手法
13. TokonomixエコシステムにおけるCouncil
14. 実践例
15. インストール
16. 統合とAPIの接点
17. ベンチマーク
18. 用語集
19. FAQ
20. ロードマップ

さらに詳しく： このREADMEは現場で役立つガイドです。この分野が存在する理由、設計原則、失敗モード、1つのモデルでは不十分な理由、合意形成だけでは不十分な理由、根拠が必要な理由、そして最終的な責任を人間が負い続ける理由についての詳しい説明は、**意思決定エンジニアリング宣言**に記載されています。READMEでは説明を重複させず、リンクで案内しています。

---

デシジョンエンジニアリングが必要になりつつある理由

ソフトウェアがより多くの責任を担うようになるたびに、信頼性を保つための新たな分野が生まれてきました。エンジニアの能力が落ちたからではなく、確認されていない出力がもたらすコストが高くなったからです。

ソフトウェアが得たもの…	…その結果、私たちが生み出したもの
人の監視なしで実行されるコード	テスト — 想定どおりに動作することを証明する
多数の人がコミットする環境	継続的インテグレーション — 変更のたびに問題を検出する
ひとりの頭だけでは把握しきれない規模のコード	コードレビュー — マージ前に別の人の目で確認する
微妙な欠陥が繰り返し発生する状況	静的解析 — 欠陥を自動的に検出する機械
継続的にリリースされるシステム	DevOps — デプロイ自体を安全にし、可観測にする
意思決定を行うようになったモデル	デシジョンエンジニアリング — 意思決定自体をレビュー可能にし、根拠に基づかせ、監査可能にする

毎回、同じパターンが見られます。ある能力が、それを信頼するための私たちの能力を追い越し、その隔たりを埋めるために新たな分野が築かれました。LLMはその境界を越えました。もはやテキストを生成するだけでなく、どの移行が安全か、認証経路に悪用可能な脆弱性があるか、GDPRのもとで条項をどう解釈するかを判断します。独立した確認も、検討しなかったことの記録もないまま、自信に満ちた単一のモデルが下す判断は、過去のあらゆる分野が見つけるために生まれた、まさに未確認の出力です。デシジョンエンジニアリングは、モデルも人だけでなく判断を下す時代のための分野です。

LLMだけではこの問題を解決できない理由

当然の疑問として、「モデルは進化し続けているのだから、十分に強力な単一のモデルなら正しい答えを出せるのではないか？」というものがあります。これは問題を読み違えています。問題は、個々のモデルが弱いことではなく、構造的なものです。

モデルは自分自身を独立して検証できません。 同じモデルに「本当に確かですか？」と尋ねると、同じ重みが同じ学習データと同じ盲点に基づいて動作します。誤りを生み出したものにその誤りを見つけるよう求めているため、モデルは同じ自信をもって最初の回答を擁護します。ひとつのモデル内での自己批評は独立した確認ではありません。自分自身の答案を自分で採点しているのと同じです。これはGPTでも、Claudeでも、Geminiでも、次にリリースされるモデルでも同じであり、いずれかのモデルが弱いという指摘ではありません。

独立性は、モデルの外部から得る必要があります。

• 異なるベンダー — 学習データに相関があると、単一ベンダーの「パネル」には同じ盲点が共有されます。そのベンダー内での意見の一致は、裏付けにはなりません。
• 異なる役割 — 回答を書いていない審査役を使います。そうすれば、自分の成果を自分で採点することはありません（LLMの自己優遇は実際に存在し、測定されています）。
• 外部の正解情報 — 実際のファイル、差分、仕様、ログなどを参照します。モデルは与えられていない事実を生み出すことはできず、共有された誤った前提に基づく意見の一致も、やはり誤りです。

これが、デシジョンエンジニアリングがより優れたモデルではなく、モデルの上位レイヤーである理由のすべてです。判断を信頼できるものにする独立性と根拠付けは、まさにモデル単体では自らに提供できないものです。

設計原則

Council のエンジニアリングは、上記の原則に基づいています。それぞれはマーケティング文句ではなく、私たち自身が守る制約です。

• 単一責任 — Council は判断を下しますが、実行、スケジュール設定、ルーティング、記憶は行いません。スコープを狭くすることで、コンポーネントを安全に組み合わせられます。
• 独立性 — 提案者はブラインドで並行して回答し、判定者は提案者と独立した別ファミリーのモデルです。自分の仕事を自分で評価するモデルはありません。
• グラウンドトゥルース — 主張は言い換えや共有された事前知識ではなく、実際の成果物と照らし合わせて検証します。根拠付けはパネルの規模に優先します。
• エビデンス優先 — 裏付けは、モデルがたまたま同じ意見になったことではなく、エビデンスに基づかなければなりません。
• 監査可能性 — すべての判断で、誰が提案し、誰が判定し、どれほどのコストがかかったかが返されるため、判断の過程を再構成できます。
• 透明性 — 解決されなかった点（ブラインドスポットのセクションや diff マップ）も明らかにし、ひとつの回答の陰に隠しません。
• 再現性 — 同じ入力と手法で再実行すれば、同じ結果が得られます。デフォルトの Council は変更される可能性があるため、モデルと日付を記録してください。
• トレーサビリティ — request_id と課金の内訳により、保存された判断を、それがどのように生成されたかまで正確にたどれます。
• 人間の責任 — Council は判断を提示し、根拠を示しますが、責任を免除するものではありません。判断に基づいて行動する最終的な責任は、人間（または人間に代わって行動するエージェント）にあります。

ある事例：セキュリティレビュー

あるチームが認証ミドルウェアをリリースしようとしています。マージ前に、エンジニアがそれを単一の高性能モデルである GPT に貼り付け、「セキュリティ上の問題はありますか？」と尋ねます。回答は問題なしでした。「問題は見つかりませんでした。実装は正しいようです。」 自信に満ちた意見がひとつあるだけで、異論も、指摘もありません。そのままマージされます。3 週間後、最初のバイトが秘密情報と一致するかどうかが応答時間から漏れるタイプの、トークン比較のサイドチャネル攻撃が本番環境で悪用されます。事後検証には多大なコストがかかります。そして最も問題なのは、何も 警告しなかった ことです。レビューでは「問題なし」とされ、チームも問題ないと信じてしまったのです。

今度は、これを Council で再現してみましょう。同じミドルウェアを複数の独立したベンダーにブラインドで並行して配布します。そのうち 3 つも「問題なさそう」と回答します。しかし Claude は、要約ではなくソースコードそのものを読み、比較処理が定数時間ではないことに気づいて、タイミング漏えいの可能性を指摘します。提案者はそれぞれ独立して回答しているため、この少数意見は埋もれません。そして 独立した判定者 は意見の相違を取り繕うのではなく、異論を明らかにします。「1 人のレビュアーが、定数時間でないトークン比較を指摘しています。他のレビュアーはタイミングについて触れていません。」エンジニアはセキュリティ上重要な箇所に意見の相違があることを確認し、重要な指摘を調査して漏えいを確認し、マージ前に修正します。

違いはそれだけです。より賢いモデルではなく、異論を保全し、人間の目に触れるようにするプロセスです。それを「問題なさそう」という自信に満ちた結論に平均化してしまうことはありません。このバグは、最初から発見できるものでした。必要だったのは、それに気づく独立したレビュアーと、見つかった問題を埋もれさせない設計だけです。

---

問題点

単一の LLM は単一障害点です。確信に満ちた回答を返し、さらに悪いことに、何を考慮しなかったのかを決して教えてくれません。チャットの返信なら問題ありません。しかし、セキュリティレビュー、アーキテクチャの決定、GDPR の解釈、データベースの移行、法的条項では、誤った回答に確信を持たれると大きな損失につながり、気づいたときには手遅れです。

反射的な解決策として、より大きなモデルに頼っても、この問題は解決しません。より大きな単一モデルも、依然として一つの意見であり、一つの盲点を持ち、見落としたことを教えてくれません。さらに、どの単一モデルが優れているかは一定ではありません。タスク、分野、バグの種類によって変わります。誤ったモデルを標準にすると、意見の食い違いに気づかないまま、実際の不具合をリリースしてしまいます。

Council MCP は、間違えた場合の損失が非対称に大きい、まさにそのような判断のために構築されています。コード／セキュリティ／アーキテクチャ／法律／ドキュメント／品質／メディア／ポリシーのレビュー、評価、ベンチマークテストなど、単一モデルの盲点が高くつく場面で活用してください。変数名の変更、フォーマット、単純な CRUD には、単一モデルのほうが安価で十分です。

単一モデルのレビューでは不十分な理由

複数のモデルに尋ねる価値は、相関のないエラー、つまりモデルによって異なる事柄を間違えることにあります。単一モデルでは、そうした利点は得られません。

• **一つの意見、一つの盲点。**そのモデルが見たものはわかりますが、見落としたものは決してわかりません。
• **確信の強さは適切な確信度とは限りません。**モデルの口調は、正解でも不正解でも変わりません。読み取れる「ここは自信がありません」という内的な表明はありません。
• **意見の相違が表に出ません。**一度の呼び出しでは、一部のレビュー担当者だけが気づいたであろう問題を示せません。レビュー担当者が一人しかいないからです。
• **モデルの得意不得意はタスクによって異なります。**同じタスク群でも、あるモデルが IDOR を見つける一方、別のモデルは「問題なし」と返すことがあり、その逆もあります。あらゆる場面で最適な単一モデルは存在しないため、単一モデルを標準にすると、見落としが一定数必ず発生します。

同じベンダーにセカンドオピニオンを求めても、この問題は解決しません。その「パネル」は、そのベンダー自身のモデルで構成され、独自のデータで訓練され、独自の盲点を共有しています。相関のあるエラーを、意見の一致に見せかけているのです。レビューに価値をもたらす非相関性が存在するのは、ベンダー間だけです。中立的なジャッジが調整するこのベンダー横断のチェックこそ、単一ベンダーの API では構造上提供できないものです。

「回答を単純に平均すればよい」という考えが誤りなのも、このためです。平均を取ると、少数派の異論が消えてしまいますが、それこそが重要な指摘であることは少なくありません。設計上の課題は、異論をならして消すのではなく、保ち、裁定することです。

Council の仕組み

1 つのツールを呼び出すと、オーケストレーション、スコアリング、調整がサーバー側で実行され、1 つの判断結果が返されます。

            ┌─ Claude  ─┐
your prompt ─┼─ GPT     ─┼──▶  independent judge  ──▶  one reconciled decision
            ├─ Gemini  ─┤      (disjoint, cross-     + the disagreements
            └─ …(2–6)  ─┘       family — never grades   that surfaced
                                 its own answer)

1. 並列かつブラインドで一斉に回答します。 プロンプトは、ベンダー（Anthropic、OpenAI、Google、EU ホストの選択肢）をまたぐ 2～6 個の最先端モデルの提案者に並列で送られます。それぞれが独立して回答し、他の回答は一切見ません。そのため、唯一の反対者が多数派に屈するような円卓会議にはなりません。選定では、生のスコアではなく、多様性と能力を重視します。スコア上位のモデルだけを選ぶと、似たモデルに収束し、仕組みの要である非相関性が低下するためです。
2. 独立した審査者。 1 つ以上の審査モデルが、候補の回答を読み、相互に矛盾しないよう調整します。審査モデルは、デフォルトで提案者とは別のモデルであり、異なるファミリーに属し、自身の提案を採点することはありません。どの主張が裏付けられているか、どれが異例か、どれが単純に誤っているかを判断します。
3. 選択したモードに応じた、1 つの結果。 モードに応じて、決定済みの回答 1 つ、合意点と相違点をまとめた構造化マップ、最も優れた単一の回答の原文、全体像と判定、または審査者を介さない生の回答のばらつきが返されます。あらゆる状況に最適なモードはありません。この呼び出しで必要なものに応じて選んでください。

Council は真実を見抜くオラクルではなく、再現率を高める仕組みとして捉えてください。 強みは再現率です。異なるベンダーのモデルを複数使うことで、タイミングサイドチャネルや見落とされたエッジケースをどれか 1 つが見つければ、その指摘が表面化します。その代わりに適合率は下がります。モデルが増えるほど指摘も増え、その中には些細なものも含まれるため、人間（またはエージェント）が判断します。このトレードオフは、まれではあるものの、間違えた場合のコストが大きく非対称な判断には価値がありますが、日常的な作業には適していません。

アーキテクチャ

                       ┌──────────────────────────────────────────────┐
   MCP client          │                Tokonomix gateway             │
 (Claude Code,         │                                              │
  Cursor, …)           │   ┌── proposer 1 ──┐                         │
       │  tool call    │   │   (vendor A)   │                         │
       ├──────────────▶│  ─┼── proposer 2 ──┤   blind, parallel       │
       │               │   │   (vendor B)   │   2–6 proposers         │
       │               │   └── proposer 3 ──┘                         │
       │               │           │                                  │
       │               │           ▼                                  │
       │               │   ┌────────────────┐  disjoint, cross-family │
       │               │   │  judge (panel) │  never judges own answer│
       │               │   └────────────────┘                         │
       │               │           │                                  │
       │   one result  │           ▼                                  │
       │◀──────────────│   synthesis + surfaced disagreement +        │
                       │   billing breakdown + request_id             │
                       └──────────────────────────────────────────────┘

コンポーネント：

• 提案者 — プロンプトに回答する 2～6 個のモデルです。生のスコアだけでなく、モデルファミリーをまたぐ非相関性を重視して選ばれます。Tokonomix 独自の測定レイヤー（知能テスト、TrueSkill を用いたアリーナ形式の対戦、審査者の評判に基づく正誤率）から実証的に選定され、Goodhart の法則に陥らないためのガードと探索予算も設けられているため、過去の勝者が固定化されません。
• 審査者 — デフォルトでは提案者とは別のモデルで、異なるファミリーに属し、自身の回答を採点することはありません。予算は提案者の数に応じて自動調整されます。
• ゲートウェイ — オーケストレーションを実行し、リージョン／データ所在地に関するポリシーを適用してコストを計上し、請求の内訳と request_id を含む結果を 1 つ返します。ゲートウェイ自体は EU でホストされています。リージョンの選択によって、プロンプトを受け取るモデルプロバイダーが決まります。
• キーごとのポリシー — 予算上限、デフォルトの Council／ルート、許可リストは、呼び出しごとに再決定するのではなく、API キーに設定されます。これにより、無人実行時に予算を超過したり、意図していない場所にプロンプトが送信されたりすることを防げます。

オーケストレーションでは追跡可能性を重視します。呼び出しごとに提案者モデル、審査モデル、charged_credits が返されるため、判断記録を再現できます。デフォルトの Council は時間の経過とともにサーバー側で変更される可能性があるため、回答とともにこれらの情報も記録してください。

合意形成プロセス

tokonomix_consensus_ask は中核となるツールです。どのモードでも、コストの大半を占めるのは提案モデルであり、モード間の違いは判定の有無だけです。目的に応じてモードを選んでください。diff を含め、どのモードも万能ではありません。

モード	得られるもの	判定？	用途
consensus (デフォルト)	最も裏付けの多い主張をもとにまとめた、決定済みの回答	1 回	「実行に移す判断だけを教えてほしい」場合
diff	一致点／相違点／確信度をまとめたレポート。判定役は「比較」しますが、決定はしません。	1 回	自分で判断するものの、意見の相違点を把握したい場合
best_of	判定役が、既存の回答の中から最も優れたものをそのまま選択します（統合はしません）	1 回	1 つのモデルが完全に正解している可能性が高く、統合すると内容が薄まるだけの場合
full	各提案モデルの回答すべてに加え、判定役によるモデルごとの推論と結論を、1 回の判定で提示します	1 回	監査可能性が必要で、生の全体像と結論の両方を確認したい場合
raw	判定役を通さず、各提案モデルの生の回答をすべて提示します（最も安価）	なし	フィルタリングされていない回答の広がりを見て、すべて自分で整理したい場合

raw は判定役を省略するため、最も安価です。diff、consensus、best_of、full はいずれも判定を 1 回分課金します（full は同じ 1 回で最も詳細な内容を返します。追加の呼び出しではありません）。raw はコスト削減だけを主な目的とするのではなく、制御性や判定バイアスの排除を求める場合に選んでください。また、判定役の比較を無視するのであれば、diff で判定役に料金を払わないでください。

すべての合意形成の回答には、追加料金なしで ## ⚠️ Blind spots & disagreements セクションも末尾に含まれます。 これを正しさの保証ではなく、表面化した意見の相違として読んでください。

根拠付け — 最も大きな効果をもたらす要素

合意形成の質を最も大きく左右するのは、モードでもモデル数でもなく、根拠付けです。つまり、検証可能な事実（実際のファイル、実際の差分、仕様そのもの、実際のログ）をパネルに与えることです。根拠のない合意形成は、モデルに共通する誤った前提を誤った確信へと増幅します。一方、根拠に基づく合意形成は、主張を現実と照らし合わせて検証します。実際に確認された 2 つの重要な発見は、モデルが成果物そのものを読めたからこそ見つかりました。要約では見えない U+2028 制御文字のバグと、言い換えではなく仕様の原文をパネルが確認したことで初めて明らかになったリレーの整合性の欠落です。守るべき原則は次のとおりです。

• レビュー対象の成果物を省略せず、原文のまま送ってください — 要約や ... は使わないでください。問題は必ず細部（文字の範囲、制御フローの順序、具体的な表現、明示されているかどうかが曖昧なエッジケース）に潜んでおり、要約はまさにその部分を隠してしまいます。この原則は、コード、ドキュメント、設定、指示のいずれにも当てはまります。
• 事実は最大限に、誘導は最小限に。 関連する事実はすべて提示し、誘導するヒント（「正規表現に注意」など）は一切与えないでください。ヒントはシグナルを汚染し、モデルが自力で問題を見つけたのかどうかが分からなくなります。
• 厳しい上限となるのは、判定役も含めたパネル内で最も小さいコンテキストウィンドウです。 上限を超えると、そのメンバーの入力は通知なく切り詰められ、実質的に何も見ずに投票することになります。まずパネルを確認してください（tokonomix_list_models は context_window を報告します）。収まらない場合は、より大きなウィンドウを持つパネルに切り替えるか、モジュールごとに分割してください。収めるために圧縮してはいけません — 圧縮すると、根拠付けによって明らかにするはずの問題を再び隠してしまいます。

根拠となる情報は、prompt に直接記述するか、構造化された context 引数（サーバー側で制御）を使って渡せます。後者では、同じコンテキストパックがすべての提案モデルと判定役に再利用されるため、コンテキストへの課金はモデルごとではなく 1 回だけです。

グラウンディング・ゲート（入力が不十分な場合は判断を控える）

他にない真の差別化要因であり、誠実な機能でもあります。評価するには入力が不十分なのに、根拠なく自信満々のレビューを返すのではなく、評議会は追加情報を求めることができます。呼び出しが {status:"needs_context", request_id, missing, delivery_hint} を返した場合、それはエラーではなくコンテキストの要求です。評議会は実行されておらず、料金も発生していません。missing には、参照したものの（ファイル、差分、「このコード」など）、実際の内容を含めていない成果物が列挙されます。実際の内容を用意してそのまま添付し、同じ request_id で再度呼び出すと、十分な根拠に基づく評議会が実行されます。添付できる成果物が本当にないプロンプト（添付するものがない一般的な質問）では、短い理由を添えて acknowledge_ungrounded: true を設定すると、grounding:insufficient のフラグが付いた、最善を尽くした判定が強制的に返されます。

ステータス： 現時点でグラウンディング・ゲートは休止中／まずはシャドーモードです。needs_context／continuation_id／acknowledge_ungrounded の仕組みは MCP とゲートウェイに存在しますが、サーバー側で制御されており、デフォルトではまだ有効になっていません。これは意図された仕組みとして説明しています。プラットフォームで有効になるまでは、ご利用のアカウントで適用されているとは考えないでください。

判定者

評議会が真価を発揮するか、静かに失敗するかは判定者次第です。そのため、判定者の独立性は細部ではなく、設計の根幹をなす要素です。

• デフォルトでは提案者と重複しません。 判定者が自分で書いた回答を採点することはありません。モデルが自分自身の提案を判定することもありません。LLM の自己選好バイアスは実在し、測定されています。提案者も兼ねる非独立な判定者は、合意度を過大評価します（専門分野の重複を参照）。
• 可能であれば異なるファミリーから選びます。 異なるファミリーの判定者を使うと、統合の段階で特定ベンダーの弱点を引き継ぐことを避けられます。判定者（judge_model）を上書きしたり、複数判定者のパネル（複数判定者による best_of で使用する judge_models）を実行したりできます。異なるファミリーの選択を推奨します。
• 複数判定者のパネルは信頼性を高めますが、上限は引き上げません。 判定者を増やすと、個々の判定者に固有の傾向（たとえば、長く自信に満ちた回答を好む既知のバイアス）が和らぎます。しかし、判定者同士も提案者とも学習データを共有しているため、判定者を増やして高まるのは信頼性であり、真実性の上限ではありません。判定者を増やすより、グラウンディングのほうが効果的です。
• 判定者の能力は、自らが持つ根拠を超えられません。 1 つのモデルに固有の傾向を和らげることはできますが、どの提案者も判定者も知らない事実を生み出すことはできません。これが、パネルの人数よりグラウンディングが重要である構造上の理由です。

自動サイズ調整：判定者の出力予算は提案者の数に応じて拡大します（4096 + 2048 × proposers、下限は 4096、上限は 16384）。標準的なコンセンサス経路では、max_tokens の設定にかかわらず、判定者のステップの出力トークン数は 8192 に厳しく制限される点に注意してください。非常に大きな構造化出力では、提案者の出力が収まっていても判定者の出力が途中で切れることがあります。max_tokens を 8192 より大きくするのではなく、バッチ処理するか分割してください。

コンセンサスが役立つ場合／役立たない場合／逆効果になる場合

このセクションは、製品の誠実さを示す中核です。複数モデルによるレビューに失敗の可能性がないわけではありません。また、そのいくつかは仮説ではなく、私たち自身の検証に基づいて記録されています。結果を信頼する前にお読みください。

コンセンサスが役立つ場合

• 発生頻度は低いものの、失敗時の損失が大きく非対称な判断。認証、移行、GDPR、金銭、規制当局や顧客に提出する情報などが該当します。実際に問題を1つ見つけられれば、多数の誤警報を補えます。
• ばらつきの解消。 たまたまどのモデルに尋ねたかで結果が左右されなくなります。タスクごとにどのモデルが得意かを事前に知っておかなくても、評議会によって、パネル上位のモデルと同等の再現率を得られます。
• 意見の相違を明らかにすること。 diff モードでは、少数意見を平均化して消すのではなく、表に引き出します。意見の分裂そのものがシグナルです。
• 検証／エージェント QA レイヤーとして。 ベンダーをまたいだチェックは、ホスト側エージェントのサブエージェント（単一ベンダー）では再現できない唯一のものです。

合意形成が役に立たない場合

• 定型的な作業 — 名前の変更、書式設定、単純な分類、簡単な検索などです。効果がないのにコストとノイズが増えます。tokonomix_single_ask（約3倍安価）またはご自身のホストモデルを使用してください。
• 単独の高性能モデルだけで十分なタスク。 簡単でよく知られた問題では、最良の単独モデルがすでに正解を出せます。合議はそのモデルに匹敵するだけで、それを上回ることはありません（しかもコストは高くなります）。ベンチマークを参照してください。

合意形成が逆効果になる場合

これらは実際にある制約であり、明示しています。ここでは、注意事項を隠すのではなく、誠実であることを重視しています。

• 統合による情報の欠落。 単独のメンバーが実際に見つけた有意な内容を、判定役が落としてしまうことがあります。統合後の回答が、あるメンバー単独の回答よりも劣っていたケースを実際に確認しています。情報が失われないよう確実にしたい場合は、consensusではなく、モデルごとの内容を保持するdiffまたはfullを使用してください。
• 相関した失敗／共通の幻覚。 最先端モデルは、互いに大きく重複する学習データを共有しています。共通の盲点、たとえば学習データのカットオフ以降の事実やニッチな分野では、モデル同士が一致しても、全員が同じように間違っていることがあります。その場合、判定役は「盲点」セクションに何も見つからなかったと記し、自信に満ちた誤答を提示します。一致が測るのは一致であり、真実ではありません。 これに対抗する手段は、モデルを増やすことではなく、根拠を与えることです。
• 誤った合意。 見かけ上の収束は、独立した裏付けではなく、似たプロンプト、似たファインチューニング、または支配的な言い回しによるものかもしれません。分布外の事実について全員が一致した回答を出した場合も、単独モデルの回答と同じように疑ってください。
• 専門家の重複。 判定役が提案者も兼ねる（役割が分離されていない）場合、自分の成果を評価して、測定された一致度を水増しします。これが、デフォルトの判定役を役割が分離された別のモデルファミリーにしている理由です。ただし、判定役を提案者リストにすでに含まれているモデルに変更すると、このバイアスが再び生じます。

要点： 合意形成は単独モデルの誤りを減らし、単独モデルなら見落とす意見の相違を明らかにします。正しさを保証するものではなく、測定した実行では高性能な単独モデルと比べて検出率に正味の向上は見られず、自動的に信頼すべき無条件の統合ゲートでもありません。判断を支える、再現率を高める手段です。

Decision Engineering と既存の手法の比較

Decision Engineering は、何もないところから生まれたまったく新しいアイデアではありません。十分に研究された複数の手法を組み合わせ、ほとんどの手法に欠けている 2 つの要素、すなわち ベンダーをまたいだ独立性 と 実際の成果物に基づく根拠付け を加えたものです。以下は、関連する手法と重なる点、異なる点を率直に整理したものです。重要なのは「すべての手法より優れている」ということではなく、それぞれがどの問題を解決するか です。これらの仕組みのいくつかは、Council 自身も利用しています。

手法	解決する問題	Council と重なる点	異なる点
LLM-as-Judge	モデルの出力を自動で採点・順位付けする	Council は調整に LLM の判定役を 使用 します	Council では、判定役が 独立しており、異なるファミリーに属する ことを求めます。一般的な LLM-as-Judge の構成では、モデルが自身のファミリーの出力（または自身の回答）を評価できるため、合意が過大に見積もられます
ディベート（モデル同士が結論をめぐって議論する）	モデル同士に異議を唱えさせ、推論を明らかにする	どちらも意見の不一致を表面化させることを目指します	ディベートでは、声高に、あるいは長く主張した側が勝ち、譲歩を引き起こす可能性があります。Council では提案者を 互いに見えない状態で並行して動作 させるため、少数意見が論破されるのではなく 保持 されます
思考の木（Tree of Thought）	分岐を探索し、単一モデル内で より良い推論を行う	どちらも、より慎重な回答を目指します	ToT は単一モデル、つまり 1 つの思考と 1 つの盲点に依存します。Council の価値は ベンダーをまたいだ 非相関化にありますが、ToT では構造上これを実現できません
自己一貫性（Self-Consistency）	1 つのモデルから何度もサンプリングし、多数決を取ることでばらつきを減らす	どちらも、単一サンプルの偶然性を減らします	自己一貫性では 同じ モデルからサンプリングするため、そのモデルの系統誤差から逃れられません。Council では、誤差が相関しない 異なるベンダー からサンプリングします
Mixture of Experts	1 つのモデル 内部 の専門サブネットワークにトークンを振り分け、効率よく性能を高める	どちらも「エキスパート」という言葉を使います	MoE は単一モデル（1 つのベンダー、共有された学習）におけるアーキテクチャ上の詳細です。Council の「エキスパート」は、外部の判定役が調整する独立したベンダーであり、モデル内部の仕組みではなく意思決定レイヤーです
アンサンブル学習	複数モデルの予測を組み合わせてばらつきを抑える	どちらも複数のモデルを組み合わせます	従来のアンサンブルは 平均化または投票 を行うため、重要なことが多い少数意見を 消してしまいます。Council は少数意見を保持して裁定し、さらに根拠付けと独立した判定役を加えます
Constitutional AI	自己批評を通じて、モデルを文書化された原則に沿わせる	どちらも、推論に基づいた原則的な出力を重視します	Constitutional AI は、単一モデルの内部でルールブックに照らして 自己 批評します。Council のチェックは 外部 のものです。同じモデルが自分自身を評価するのではなく、別のベンダーと実際のグラウンドトゥルースを用います
ピアレビュー（人間）	公開前に独立した専門家が精査する	Council は、独立した査読者と調整を行う編集者という構成を明示的に参考にしています	人間によるピアレビューは時間がかかり、対応できる人数が限られ、一貫性にも欠けます。Council は迅速で再現可能ですが、「査読者」は学習データを共有しているため、最も重大な判断において人間によるレビューの代わりには なりません。人間の判断を支援するものです
静的解析	既知の種類のコード上の欠陥を決定論的に検出する	どちらも、問題がリリースされる前に発見します	静的解析は厳密でルールに基づきます（偽陰性の変動はありませんが、ルールに記述されていないものは検出できません）。Council は、リンターではルール化できない 新規の 意味的・分野横断的な問題を推論します。両者は競合するものではなく、相互に補完します

Council の位置付け。 Council は、これらの手法の本当に有用な部分、つまり LLM の判定役、アンサンブルによる統合、ピアレビューの構造を取り入れ、単一モデルや単一ベンダーの方式では実現できない 2 つの特性、すなわち ベンダー間の独立性 と グラウンドトゥルースに基づく根拠付け を加えるレイヤーです。貢献は、目新しさそのものではなく、この点にあります。

Tokonomix エコシステムにおける Council

Council は、拡大を続ける Tokonomix コンポーネント群の中の、専門的な構成要素のひとつです。それぞれ単独で使用できますが、各コンポーネントはひとつの責任を担い、関連するコンポーネントの所在を示します。Council が担うのは意思決定であり、スタック全体を担おうとするものではありません。

コンポーネント	担当するもの	Council との関係
Council (このリポジトリ)	意思決定 — 独立したレビュー、合意形成、推論の検証、根拠付け、判定者の独立性、意思決定の確信度、監査可能性	—
ANS — Agents Never Sleep	実行 — 決定的なガバナンスのもと、バックログを無人で最後まで実行すること	Council は、ANS が意思決定を委任する検証者です。ANS が実行し、Council は実行しません
Media QC	メディア成果物の検証 — 画像／動画／ドキュメントの出力品質管理	Council は意思決定と推論をレビューし、Media QC はメディア出力をレビューします。Council は意思決定の根拠として画像を使用できますが、メディア品質管理は担当しません
Benchmark	測定 — インテリジェンステスト、アリーナ、モデル／判定者の評価	Council の実証に基づく提案者／判定者の選定に情報を提供します。Council はこれを利用しますが、実行はしません
Routing	プロバイダー選択 — 呼び出しをホストするプロバイダー／モデル	Council はリージョン／データレジデンシーポリシー（EU 限定のデータレジデンシー）を提供しますが、基盤となるプロバイダーのルーティングは Routing の役割です
Memory	長期コンテキスト — セッションをまたいで保持される状態	Council は呼び出しごとにステートレスです（監査用に request_id を記録します）。永続メモリは Memory にあります

実行、スケジューリング、自律性、メモリ、ブラウザー自動化、または一般的なプロバイダーのルーティングが必要な場合は、適切なコンポーネントではありません。Council は意思決定のみを行います。 実行には ANS を指定してください。

実用例

コード／セキュリティレビュー（diff — 異論を残す）

tokonomix_consensus_ask({
  prompt: "Is this auth middleware safe? Review for timing side-channels, IDOR, and missing-auth paths.\n\n```ts\n" + middlewareSource + "\n```",
  mode: "diff"   // surface the one model that flags the constant-time issue; don't average it away
})

4 つのモデルが「問題なさそう」と答える一方、1 つのモデルがトークン比較が定時間でないと指摘します。単一モデルへの呼び出しでは「問題なさそう」という結果が返り、そのままリリースしていたでしょう。diff は少数意見を表面化させるため、実際に重要な点を人間が判断できます。

移行の安全性チェック（diff — 元に戻せない操作）

tokonomix_consensus_ask({
  prompt: "Is this migration reversible? Flag any irreversible step.\n\n" + migrationSql,
  mode: "diff"
})

安全性チェックでは、少数意見を平均化して消すのではなく、そのまま残しておく必要があります。

コンプライアンス／法的解釈（consensus — 結論の出た回答）

tokonomix_consensus_ask({
  prompt: "Can a SaaS legally store EU-citizen API logs in a US-hosted S3 bucket for 30 days under GDPR? Answer in 4 bullets: legal basis, Schrems II, alternatives, action plan.",
  mode: "consensus",
  models: ["claude-opus-4-8", "gpt-5.4", "gemini-2.5-pro"]   // slugs illustrative — confirm with tokonomix_list_models
})

このプロンプトは慣行について尋ねており、個人データを含まないため、米国のフロンティアモデルを使う Council で問題ありません。プロンプトに実際の顧客記録が含まれる場合は、データを EU 内に限定してください（次の例）。

個人データを含むプロンプト — EU データレジデンシー（PII では必須）

// 1. discover the EU-hosted set
tokonomix_list_models({ hosting_region: "eu" })
// 2. pin the council to it — the default council is US-hosted
tokonomix_consensus_ask({ prompt: promptContainingPII, models: [/* EU slugs from step 1 */] })

デフォルトの Council は米国でホストされています。個人データを含むプライバシーに関する質問を 3 つの米国のクラウドに送信すること自体が、越境移転にあたります。まさに、その質問が避けようとしていることです。EU 限定のルーティングにより、プロンプトをリージョン内に保ち、データ最小化を実現するとともに、米大西洋間の移転リスクを軽減できます。これは GDPR への完全な準拠を示すものではなく、コンプライアンスはシステム全体に依存します。

ゲートウェイが確認する内容（データガバナンス）

このスキルでは、各モデルが推測するのではなく、同じ情報源をもとに推論できるよう、レビュー対象の成果物（コード、契約書、仕様書、ログなど）を送信するよう意図的に求めます。その内容は Tokonomix ゲートウェイを経由して選択したプロバイダーに渡されるため、成果物をサードパーティにルーティングするかどうかは、プロバイダーがどの地域にあるかとは別の、実際のデータフローに関する判断です。

• 判断に必要な情報だけを送り、それ以上は送らないでください。 ファイルを添付する前に、レビューに不要な秘密情報や識別情報を削除してください。合意の質を左右するのは、情報源の完全性そのものではなく、関連性です。
• ゲートウェイは EU でホストされ、呼び出しを計測します。 上記の地域選択によって、プロンプトを確認するモデルプロバイダーが決まります。完全な保持期間／サブプロセッサーに関する声明はゲートウェイサービスに付属しており、このクライアントには含まれていません。
• 個人データを含むもの → 上記の EU の評議会を、米国のデフォルト設定より優先してください。

ホスト外に送信される情報と、ローカルに保存される情報。 クライアント側（このパッケージが制御する部分）について、正確に説明します。

• 合意の呼び出しで外部に送信されるフィールドは、messages、x_council メタデータブロック、max_tokens のみです。 隠しフィールドも、クライアント側のテレメトリもありません（SECURITY.md を参照）。添付するグラウンディングコンテンツ（context.inline／context.github_refs）は messages 内を通じて送信されるため、選択したプロバイダーに届きます。だからこそ、上記の「判断に必要な情報だけを送り、それ以上は送らない」というルールが重要です。
• クライアントがローカルに保存するのは、~/.tokonomix/credentials.json にある API キー（0600 で書き込み）と、~/.tokonomix/ 配下の小さなローカル状態ファイルのみです（SECURITY.md に記載されている認証情報／状態ディレクトリ）。キーがログに記録されることはありません。
• 評価の note に入力する自由記述（tokonomix_rate_consensus）は、管理者のみが扱います。呼び出し元に返されることも、公開の場でそのまま表示されることもありません。数値スコアと構造化された所見はモデル選択のスコアリングに使用されますが、自由記述があなたや他の誰かに再表示されることはありません。
• このクライアントが明示しない内容： ゲートウェイの完全な保持期間とサブプロセッサーの一覧です。これらはこのパッケージではなく、ホストされたサービスに関する情報です。クライアント側から補える情報ではないため、サービスに確認すべき意図的な未記載事項として扱ってください。

ドキュメント／図の QC（グラウンディングとしてのビジョン）

tokonomix_consensus_ask({
  prompt: "Key differences between these two architecture diagrams? Focus on data-flow and security boundaries.",
  mode: "diff",
  images: [
    { data: "/9j/4AAQSkZJRgAB...", media_type: "image/jpeg" },
    { data: "iVBORw0KGgoAAAAN...", media_type: "image/png" }
  ]
})

ビジョン入力は判断レビューのためのグラウンディングです（評議会が図について推論します）。メディア QC パイプラインではありません。models を設定しない場合、評議会は最新の複数ベンダーのビジョンパネル（最新の Claude、Gemini、GPT のビジョンモデル）を自動選択します。現在のスラッグは変動するため、tokonomix_list_models({"supports":["vision"]}) を実行して確認してください。data は生の base64 で、data:image/...;base64, のプレフィックスは付けません。使用可能な形式は image/jpeg、image/png、image/webp、image/gif です。画像は最大 8 枚、デコード後は各 5 MB 以下、合計 20 MB 以下です。

結果の評価（評議会の選択に反映）

tokonomix_rate_consensus({ request_id: "…", score: 8, consensus_benefit: "caught_blind_spot" })

すべての呼び出しを、実際の価値に基づいて評価してください。依頼した確認は確認（raised_confidence）であり、指摘ではありません。プラットフォームのフィードバックループ機能が有効な場合にのみ利用できます。無効の場合、ツールは「有効になっていません」という明確なメッセージを返します。

インストール

1. API キーを取得する（またはキーなしで登録する）

tokonomix.ai/signup で登録してください。€5.00 分の無料クレジットが付与され、カードは不要です。/dashboard/keys でキーを発行できます（tok_live_ で始まります）。

または、キーなしで登録できます。tokonomix_onboard("[email protected]") を実行し、メールで届く 6 桁のコードを使って tokonomix_onboard_verify を実行してください。無料枠のアカウント（€5 分のクレジット）が作成され、キーは ~/.tokonomix/credentials.json に保存されます（モード 0600）。その後は環境変数を設定する必要はありません。

2. クライアントに追加する

クイック追加（Claude Code）：

claude mcp add council npx tokonomix-council-mcp

その後、環境に TOKONOMIX_API_KEY を設定します（または、tokonomix_onboard の後に MCP が ~/.tokonomix/credentials.json から取得するようにします）。

手動設定 — Claude Code（プロジェクト内の .mcp.json または ~/.claude.json）：

{
  "mcpServers": {
    "tokonomix": {
      "command": "npx",
      "args": ["-y", "tokonomix-council-mcp"],
      "env": { "TOKONOMIX_API_KEY": "tok_live_..." }
    }
  }
}

Cursor / Cline / Continue / Zed — 同じ command + args + env の組み合わせを、使用するツールの MCP サーバー設定に追加します。

3. 設定

環境変数	デフォルト値	説明
TOKONOMIX_API_KEY	— (オンボーディング後は省略可能)	tok_live_ で始まるベアラーキー
TOKONOMIX_BASE_URL	https://tokonomix.ai/api/v1	OpenAI 互換のベース URL（コンセンサス用）。Anthropic のベース URL：https://tokonomix.ai/api/anthropic
TOKONOMIX_SITE_URL	ベース URL から導出	キー不要のオンボーディングエンドポイント用のメインアプリのオリジン

4. ツール

MCP サーバーは、すべて tokonomix_ で始まる 10 個のツールを公開します。

ツール	説明
tokonomix_consensus_ask	中核機能：2～6 個の提案者 + 独立した判定者 → 1 つの結果（上記のモード）
tokonomix_single_ask	単一モデルへのパススルー — 低コストで、定型的な呼び出し向け
tokonomix_list_models	リアルタイムのカタログ。地域、プロバイダー、ティア、機能、原産国で絞り込み可能
tokonomix_get_balance	クレジット残高、ティア、月初からの利用状況（モード別の支出額 および トークン処理量）
tokonomix_rate_consensus	request_id で結果を評価 — モデルの投票や盲点に関する評価に反映されます (休止中：プラットフォームのフィードバックループが有効になるまで 404 を返します)
tokonomix_upload	大きなコンテキストをステージングして、根拠に基づく呼び出しに使用 → session + handles (休止中：コンテキストアップロードが有効になるまで「not enabled」を返します)
tokonomix_onboard	キー不要の初回実行、ステップ 1 — ワンタイムコードをメールで送信
tokonomix_onboard_verify	キー不要の初回実行、ステップ 2 — 無料アカウントを作成し、キーを保存
tokonomix_get_skill	サーバーから正式な使用スキルを取得
tokonomix_skill_version	スキルの軽量なバージョンフィンガープリント（差異を検出）

スキル

パッケージには tokonomix-consensus スキル（skill/tokonomix-consensus/SKILL.md）が含まれており、コンセンサスを使う タイミング（およびどのモードを使うか）と、単一の呼び出しを使う場合をエージェントに教えます。.claude/skills/ に配置するか、tokonomix_get_skill を使ってエージェントに実行時に取得させます。サーバー側のコピーが正式版であり、tokonomix_skill_version で差異を検出できます。

インテグレーションと API の接続面

MCP ツールに加えて、ゲートウェイは機能プロファイルが異なる2 つの HTTP 接続面を公開しています。エージェントでネイティブのツール呼び出しや構造化出力が必要な場合に備えて、違いを把握しておくと便利です。

接続面	エンドポイント	形式	ツール呼び出し・構造化出力・ウェブ検索・プロンプトキャッシュ
Council（マルチモデル）	POST /api/v1/chat/completions	OpenAI 互換	転送されません — コンセンサスでは N 個の提案モデルと 1 つの審査モデルにリクエストを振り分けます。ツール呼び出しや構造化出力は平均化できないため、単一モデルの場合にのみ使用できます
単一モデル	POST /api/anthropic/v1/messages	Anthropic Messages ワイヤーフォーマット · 任意のプロバイダーにルーティング（OpenAI、Google、Anthropic、OVH-EU、Azure、xAI、Ollama…）	転送されます — tools／tool_choice とサーバーツール（ウェブ検索）は tool_use として往復します。cache_control によるプロンプトキャッシュにはキャッシュ料金が適用されます

検証済みの統合的な判断が必要な場合は、Council の経路（または tokonomix_consensus_ask）を使用してください。エージェントにネイティブの関数呼び出し、スキーマに制約された出力、またはプロンプトキャッシュが必要な場合は、単一モデルの経路を使用してください。この経路は Anthropic Messages ワイヤーフォーマットを使用しますが、Anthropic 専用ではありません — ゲートウェイは、指定したモデルをホストしている設定済みのプロバイダーにリクエストを送信します。

エージェントによるツール使用（例：Tokonomix 経由で外部コードレビュー用ハーネスを実行する場合）：クライアントの接続先を https://tokonomix.ai/api/anthropic に設定し、Anthropic ワイヤーフォーマットを使用してください。また、環境に設定された ANTHROPIC_API_KEY は必ず設定解除してください — 一部の SDK はこれを x-api-key として tok_live_ ベアラートークンとともに送信し、ゲートウェイによって拒否されます。

キーごとの制限

予算とリージョンのポリシーは、呼び出しごとに再決定するのではなく、キーに設定されます。

• 事前定義されたデフォルトモデルと Council のルート — 使用する提案モデル、審査モデル、モード。
• ゲートウェイが適用する月間支出上限（monthly_limit_cents）— 当月の請求対象額が上限を超えると、そのキーはブロックされます。
• モデル／モード／審査モデル／ホスティングリージョン／モデルの原産国に基づく許可リスト。

これにより、無人実行にキーを渡しても、予算超過や意図しない場所へのプロンプト送信が起きないと安心できます。tokonomix_get_balance で使用状況を追跡できます（月初からの金額（€）とトークン数）。

ベンチマーク

測定結果を公開しています。なかでも、数値が当社に不利な結果となった箇所も明示しています。ここに記載したベンチマークの数値に捏造はなく、精度向上やバグ検出率向上も主張していません。 特に重要な調査結果は 2 つあります。

調査結果 1 — バグ検出率に測定可能な純増なし（SWE-bench、第 2 ラウンド、N=29）

SWE-bench-Verified の不具合タスクを対象にした第 2 ラウンドの検証では、「コンセンサスによってより多くのバグを検出できる」という仮説は反証されました。Anthropic 以外のベースライン（GPT-4o）は実際のバグを 30 件中 29 件見逃しました。その 29 件に対してクロスファミリーの Council を実行しても、単にエージェントを再実行する場合と比べて、検出率に測定可能な純増はありませんでした — Council が見逃しを検出することはありましたが、偽陽性の指摘が相殺しました（効果 +0.12、信頼区間はゼロをまたぐ）。したがって、正確で誠実な主張は純増なしです — *「バグをより多く検出することはない」*ではありません（これも逆方向に過剰な主張となるためです）。当社は、Council がより多くのバグを検出すると主張したことは一度もありません。

調査結果 2 — Council はクリーンなタスクの精度で最良の単一モデルに並ぶが、上回る領域はない（ベンチマーク v2、5 分野）

5 分野を対象としたベンチマーク（v2）では、Council は最良の単一モデルと同等で、上回った分野はありませんでした。定番のクリーンなタスクでは、強力な単一モデルですでに性能が飽和しているため、Council はより高いコストで同等の結果を出します。最良のモデルは分野によって入れ替わります — それこそが、この製品の実際の価値です。Council が提供するのはばらつきの排除（どのモデルが強いかを事前に知らなくても、パネル全体で最も高い再現率を得られること）であり、精度の上限向上ではありません。

データに基づく誠実な位置づけ

測定された価値は、ばらつきの排除＋検証／エージェントの品質保証＋評価者の独立性＋EU データレジデンシー＋グラウンディングです。*「より正確」でも、「より多くのバグを検出」*でもありません。

お世辞よりも方法論を重視します。 上記の数値はすべて、公開データセット（Finding 1 では SWE-bench-Verified）上で再現可能な手法に基づいており、同じ結論を示しています。つまり、評議会は同等であり、上回ることはありません。プロセス上のルールしかない場合（たとえば、メカニズム上説得力のある事例に基づき、グラウンディングによって再現率が向上する場合）は、「測定された効果量ではなく、プロセス上のルール」と明記し、パーセンテージは示しません。これらの知見を支える完全なデータセットとハーネスは、再現可能な論文として公開する準備を進めています（ロードマップを参照）。成果物にするのはマーケティングではなく、手法です。

用語集

一貫した用語を使うことで、人間も AI エージェントも、これらのドキュメント全体を通じて同じ言葉を同じ意味で解釈できます。

用語	意味
意思決定エンジニアリング	1 つのモデルの単一の出力を信頼するのではなく、独立した入力、独立した調整役、根拠付け、監査可能性を備えた意思決定の生み出し方を設計することです。Council はそのリファレンス実装です。つまり、ここで定義する原則を具体化した最初の実装です。外部仕様も、2 つ目の実装もまだありません。
意思決定の品質	Council が最適化する目標です。正しく、かつ監査可能な意思決定を指します。合意 × グラウンドトゥルース = 意思決定の品質で表されます。合意は 1 つの手段であり、根拠付け（最も強力な手段）、判定者の独立性、検証も別の手段です。
リファレンス実装	ある手法を最初から最後まで実証する、具体的で動作する実装です。市場での順位を主張するのではなく、Council についての事実を述べるものです。これは、ここで定義する原則を実装した最初のものです。外部仕様も、2 つ目の実装もまだなく、外部の組織による採用もありません。（「業界標準」とは主張しません。）
提案モデル	プロンプトに独立して、互いの回答を知らずに回答する 2〜6 個のモデルの 1 つです。
判定者	提案モデルの回答を調整するモデルです。設計上、独立しています。
独立判定者	提案モデルのいずれでもない判定者です。そのため、自身の回答を採点することはありません。
異なるファミリーの判定者	提案モデルとは異なるベンダーまたはモデルファミリーの判定者です。そのため、提案モデルに共通する盲点を引き継ぎません。
Consensus モード	最も裏付けの多い主張を統合した、1 つの決定済みの回答です。（デフォルトです。）
Diff モード	一致点、不一致点、確信度をまとめたレポートです。判定者は比較しますが、意思決定はしません。
Best_of モード	判定者が、既存の回答の中から最も優れた 1 つをそのまま選びます。統合はしません。
Raw モード	判定者を介さずに、すべての提案モデルの回答を出力します。フィルタリングされていない回答のばらつきを確認できます（最も低コストです）。
Full モード	1 回の判定で、すべての提案モデルの回答、モデルごとの判定者の推論、結論を出力します（監査可能性を重視します）。
根拠付け	ファイル、差分、仕様、ログなどの実際の成果物を評議会に与え、共有された事前知識ではなく現実に照らして主張を確認します。最も大きな効果をもたらす手段です。
情報損失を伴う統合	判定者がメンバー 1 人だけが見つけた実際の知見を取りこぼし、統合された回答がそのメンバー自身の回答よりも弱くなる失敗パターンです。
相関した失敗	学習データを共有する最先端モデルが同じ点で誤ることです。そのため、意見の一致は正しさの証明にはなりません。
見せかけの合意	独立した裏付けではなく、似たプロンプトやファインチューニングによって生じる、見かけ上の収束です。
専門家の重複	独立していない判定者（提案モデルでもある）が自らの作業を採点し、測定上の一致度を過大評価することです。
再現率と適合率	再現率 = まれな実際の問題を見つけること（Council の強みは、1 つのベンダーだけが問題を見つければよいことです）。適合率 = 誤った警告を避けること（Council のコストは、モデルが増えるほど判定すべき警告も増えることです）。
意思決定の確信度	Council が提示する一致・不一致のシグナルです。diff レポートと、回答ごとの盲点セクションに示されます。これは人間が判断するために提示されるシグナルであり、回答が正しい確率を調整して示すものではありません。
ばらつきの排除	Council が実際に提供する価値です。たまたま選んだ単一のモデルに賭ける必要がなくなり、どのモデルが優れているかを事前に知らなくても、パネルの高い再現率が得られます。
根拠付けゲート	Council が薄すぎる入力に対する判定を拒否し、推測する代わりに実際の成果物を求めるための、休眠状態またはシャドウ優先の仕組みです。

FAQ

これはモデルですか、それともチャットボットですか？ どちらでもありません。モデルの上位に位置する意思決定エンジニアリング層です。どのモデルも賢くするものではなく、複数のモデルの出力をどのように一つの意思決定にまとめるかを変えます。マルチモデルチャットでも、投票システムでも、平均化システムでもありません。

Council は最良の単一モデルより正確な回答を出しますか？ いいえ。そのような主張はしません。検証では、クリーンな精度で最良の単一モデルと同等であり、どの分野でもそれを上回りませんでした。また、SWE-bench の実行では、検出率に正味の向上は見られませんでした。測定された価値は、ばらつきの排除、検証、審査の独立性、EU データレジデンシー、グラウンディングです。

では、なぜ料金を払うのですか？ どの単一モデルが最良かはタスクごとに変わり、通常は事前にどれが最良か分からないからです。Council を使えば、その選択に賭けることなくパネル内の最上位モデルの再現率を得られ、単一モデルでは隠れてしまう意見の相違が明らかになり、単一ベンダーの API では得られないベンダー横断のチェックができます。まれでコストの高い意思決定では、その価値は料金を上回りますが、日常的な作業ではそうではありません。その場合は tokonomix_single_ask を使ってください。

合意が手段なら、目標は何ですか？ 意思決定の質を高めることです。合意はそのために用いる仕組みの一つであり、グラウンディングと審査の独立性もそのほかの仕組みです。モデル同士が合意することではなく、意思決定が正しく、監査可能であることを最適化します。

単一のベンダーから同じものを購入できますか？ いいえ。OpenAI は Claude を評価できず、Anthropic は Gemini を評価できず、Google は GPT を評価できません。ベンダー独自の「パネル」は、そのベンダー自身の学習データと盲点を共有しており、相関した誤りを合意のように見せています。相関を解消できるのは、ベンダー間だけです。

意見が一致していれば、回答は正しいということですか？ いいえ。最先端モデルは学習データを共有しているため、意見が一致しても一様に間違っていることがあります（共有された幻覚、相関した失敗）。意見の一致は確信度を高めますが、正しさを保証するものではありません。分布外の事実や知識カットオフ後の事実については、引き続き一次情報源で確認し、呼び出しをグラウンディングしてください。

合意は単一モデルより悪い結果になることがありますか？ あります。その点も明示しています。情報を失う統合（審査役が実際の発見を落とす）、相関した失敗、誤った合意、専門モデルの重複（独立していない審査役による合意の水増し）が起こり得ます。合意が役立つ場合／役立たない場合／悪影響を及ぼす場合を参照してください。発見の見落としが許されない場合は diff／full を使い、呼び出しをグラウンディングしてください。

Council は作業を実行、スケジュール、または記憶できますか？ いいえ。設計上、その範囲外です。Council は意思決定のみを行います。実行と無人でのバックログ処理は**ANS**が担います。長期記憶、ブラウザーの自動化、汎用的なプロバイダーのルーティングは、それぞれ独立したコンポーネントに属します。Tokonomix エコシステムにおける Councilを参照してください。

個人データや GDPR についてはどうですか？ プロンプトに個人データや識別可能なデータが含まれる場合は、EU 内に限定してください。tokonomix_list_models({hosting_region:"eu"}) を実行し、その後それらのスラッグを固定します。デフォルトの Council は米国でホストされています。EU 限定のルーティングにより、プロンプトを地域内にとどめ、データ最小化を実現し、大西洋を越えるデータ移転のリスクに備えられます。これは GDPR への完全な準拠を示すものではありません。準拠状況はシステム全体によって異なります。

グラウンディングゲートは稼働していますか？ 仕組みは存在しますが、休止中、またはシャドー優先の状態です。サーバー側で制御されており、現時点ではデフォルトで適用されません。これは意図された仕組みとして捉えてください。現在のアカウントで利用できる保証ではありません。

意思決定を再現可能にするには、どうすればよいですか？ 提案モデル、審査モデル、charged_credits、日付、正確なプロンプトを記録してください。これらはすべて請求の内訳に含まれます。デフォルトの Council はサーバー側で時間とともに変わる場合があるため、同じプロンプトでも翌月には異なるモデルが使われる可能性があります。

ドキュメント

関連ドキュメントでは、ワイヤープロトコルではなく、AI Decision Engineeringの観点からCouncilを説明しています。チュートリアルまたは用語集から始め、全体像についてはマニフェストをお読みください。用語はスイート全体で一貫して使用されており（用語集を参照）、各ドキュメントにはアクセシブルな図が掲載されています。

• 意思決定エンジニアリング・マニフェスト — この分野を独立して提示する文書です。
• 用語集 — スイート全体で一貫した語彙をまとめています。
• チュートリアル：初めてのコンセンサス呼び出し — 実践的な入門ガイドです。
• 意思決定理論 — 1つのモデルは1つの視点にすぎない理由と、独立した複数モデルによるレビューについて説明します。
• コンセンサス — 目的ごとに、メカニズムと統合モードを説明します。
• 判定者の独立性 — 独立した、異なるファミリーをまたぐLLM-as-judgeについて説明します。
• グラウンディング — 意思決定の品質を高める最も強力な手段であり、モデルを増やすより効果的です。
• 検証 — AI検証レイヤーと、モデルが自分自身を検証できない理由について説明します。
• 信頼度 — 合意によって高まるのは正しさではなく信頼度である理由を説明します。
• バイアス — 自己選好と、共有された学習データによるバイアスについて説明します。
• 再現率と適合率 — 再現率を高める効果と、それに伴う適合率の低下について説明します。
• 失敗モード — コンセンサスが役立つ場合、役立たない場合、害を及ぼす場合を率直に解説する中心的な文書です。
• ベンチマークの方法論 — 再現可能な手法と、実際の調査結果（誤りと判明したものを含む）をまとめています。
• アーキテクチャ — リクエスト → 提案者 → 判定者 → 決定と監査証跡の流れを説明します。
• ルーティング — パネルの選定と、EUをデフォルトとするデータレジデンシーについて説明します。
• 監査可能性 — トレーサビリティと評価フィードバックループについて説明します。
• 図 — 上記のドキュメントに埋め込まれた、アクセシブルなSVG（<title>／<desc>）です。

ロードマップ

現在提供中の機能と計画中の機能を明確にします。

• グラウンディングゲートの本番稼働。 シャドーメトリクスによって過剰な拒否が起きないことを検証したうえで、入力が不十分な場合に判断を拒否するゲートを、休止状態／シャドー優先から強制適用へ移行します。
• コンテキストアップロード（tokonomix_upload）。 共有のリージョン固定コンテキストパックを有効化し、大きなアーティファクトを一度だけステージングして、すべての提案者と判定者が読み取れるようにします。
• コンセンサスのフィードバックループの本番稼働。 tokonomix_rate_consensus の構造化された所見（実在／誤検知の分類、consensus_benefit）を有効化し、実運用の評議会選定と盲点に関する評価に反映します。
• 再現可能なベンチマークの公開。 上記の所見の根拠となる完全なデータセットとハーネスを公開します（誤りと判明したバグ検出の主張も含みます）。成果物とするのはマーケティングではなく手法です。
• 意思決定エンジニアリングのドキュメント — 公開済み（上記のドキュメントを参照）：意思決定理論 · コンセンサス · 判定者の独立性 · グラウンディング · 検証 · 信頼度 · バイアス · 再現率と適合率 · 失敗モード · アーキテクチャ · ベンチマーク手法 · ルーティング · 監査可能性 · 用語集 · 入門チュートリアル · アクセシブルな図解。今後の計画：隣接する手法（単一モデルによるレビュー、ピアレビュー、LLM による判定、アンサンブル、自己一貫性、思考の木、マルチエージェントオーケストレーション）との、率直な並列比較。
• 意思決定エンジニアリング・マニフェスト（docs/decision-engineering-manifesto.md）。この分野を独立した形で解説する文書です。その存在意義、設計原則、失敗モード、単一モデルでは不十分である理由、コンセンサスだけでは不十分である理由、グラウンディングが必要な理由、そして最終的な責任を人間が負う理由を説明します。README で内容を重複させず、詳細はこの文書にリンクしています。

ライセンス

MIT © Tokonomix.ai / InterIP Networks

問題とフィードバック

github.com/tokonomix/tokonomix-council-mcp/issues · [email protected]