はじめに：「複数のAIに聞く」という行為の非効率は、設計の欠如だ
ChatGPT、Claude、Geminiを業務で使い分けているビジネスパーソンは増えました。 それぞれの応答特性が異なるからです。 問題は、この「使い分け」が手動の往復作業になっている点にあります。コピーして、貼り付けて、読み比べて、また別のウィンドウへ。これは知的作業ではなく、プロセスの欠如です。
1. 実装手段よりも設計構造
マルチLLMの活用を考えるとき、実装手段の選択肢は複数あります。
API直接呼び出し、LangGraphを用いたマルチエージェント基盤、ローカルDifyでの並列クエリと差分抽出、あるいは各サービスのインターフェースを通じた運用。前稿で触れた通り、これらの構成はいずれも経験しており、それぞれの設計上の課題も把握しています。
しかし本稿で論じたいのは実装手段の選定ではありません。どの手段を使うにしても共通して残る問い「複数のAIの出力をどういう構造で統合し、判断に使うか」の方が、実務的にはるかに重要です。
「技術的にできる」と「それが最適な設計か」は別の問いです。手段の巧みさではなく、判断構造の設計にこそ本質があります。
2. 実装：Refiner → Broadcast → Integrator の三層構造
開発したAI Broadcasterは、以下の三層構造で動作します。
最初に聞きたいことをざっくり入れます。
第一層：Refiner入力クエリを「そのAIが最も処理しやすい形式」に整形します。選択した各AIに合わせたプロンプトを生成します（複数選択時は個別に作成後、統合して最終プロンプトを出力します）。
第二層：Broadcast 整形されたプロンプトを元に、選択した各AIに対して同じ質問を投入し、回答を取得します。
第三層：Integrator各AIの回答を統合します。回答の共通点や差分を踏まえたうえで、最終的な統合見解を生成する設計です。統合を担当するAIも選択可能です。ここではデモ用に3つのAIに統合を行わせました。
各回答を並べ、どこが一致しどこが分かれているか、複数AIに聞くことで単一AIでは見つけられなかった観点の補強、そして最終的に最善と考える回答をそれぞれが提示します。
最終的には複数の統合結果が手元に残りますので、どれを採用するか、あるいはどこが一致していてどこが割れているかを見ながら判断するだけです。
3. 設計で最も時間がかかった問い
実装の技術的な問題より、設計思想の問題に時間を要しました。
「どこまでをシステム側が決め、どこからを人間の判断に委ねるか」という問いです。
最初の設計ではRefinerの処理方針を統一しようとしました。しかし試行の結果、各AIのRefiner出力に個性を残した方が、最終的な回答の多様性と質が上がることがわかりました。「プロンプトを最良化する」という目的だけを共通化し、アプローチはAIの判断に委ねる構造が機能しました。
これは組織の意思決定設計と同型の問題です。メンバー全員に同一の思考フレームを強制すると多様性が失われ、集合知の質が下がります。AIの合議設計でも同じことが起きます。
4. マルチLLM合議が示すガバナンスの含意
単一モデルへの依存は、単一障害点の設計と同じリスク構造を持ちます。判断の多様性、相互検証、統合プロセスの透明性——これらはシステムの信頼性設計における基本要件であり、AIガバナンスの文脈でも同様です。
ISO/IEC 42001やNIST AI RMFが求める「AIの出力に対する適切な理解と管理」を実装レベルで実現するには、どのモデルがどの判断を行い、その根拠はどこにあるかを追跡できる構造が必要です。複数LLMの合議設計は、その構造を自然に担保する一つのアプローチになりえます。
また、合議によってハルシネーションリスクの低下やバイアスの軽減も見込まれます。
AIの意思決定品質は、個々のモデルの性能だけでは決まりません。合議の設計によって変わります。これはシステム設計の問題であり、同時にガバナンスの問題でもあります。
本記事は2026年3月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。