2026年10月更新。前回投稿記事は古典的な黒板モデルの紹介でした。初版の誤り（階層の説明、CA/NAとFA/Cの表）も合わせて訂正しました。
前回投稿記事
結論
- LLMマルチエージェントの協調方式は、メッセージパッシング型（オーケストレータが指示を配る） と 黒板型（共有状態を介して間接協調する） の2系統に整理できる。
- エージェント数が増え、オーケストレータが各エージェントの能力を把握しきれなくなる規模では、黒板型が優位になる。
- コーディングエージェントにおける「リポジトリ + タスクリスト + 成果物ファイル」は、すでに黒板として機能している。黒板モデルは新規導入するものではなく、すでに使っているものを自覚的に設計し直す対象として見ている。
黒板モデル（Blackboard Model）とは
複数の知識源（Knowledge Source、以下KS）が、共有データ構造（黒板）だけを介して協調し、問題を解くアーキテクチャ。KS同士は直接通信しない。
起源は1970年代の音声理解システム Hearsay-II（CMU）。その後 BB1（Hayes-Roth）で「制御そのものも黒板上の問題として解く」という制御黒板の考え方が加わった。
3つの構成要素
| 構成要素 | 役割 | LLMエージェントでの対応物 |
|---|---|---|
| 黒板 | 仮説・部分解・要求を保持する共有状態 | 共有ファイル、タスクリスト、状態ストア、スレッド |
| 知識源（KS） | 黒板の状態を条件に起動し、黒板を書き換える専門家 | サブエージェント、Agent Skill、決定論バリデータ |
| 制御（Control） | 次にどのKSを動かすかを決める | オーケストレータLLM、イベントトリガ、エージェント自身の挙手 |
本質は「機会主義的制御」
黒板モデルの核心は共有メモリではなく、実行順序を事前に固定しない点にある。黒板の現在の状態を見て、その時点で最も貢献できるKSが動く（opportunistic problem solving）。
固定ワークフロー（DAG）との違いはここにある。
| 観点 | 固定ワークフロー | 黒板モデル |
|---|---|---|
| 実行順序 | 設計時に決定 | 実行時に黒板の状態から決定 |
| KSの追加 | フロー定義の改修が必要 | KSを足すだけ（他のKSは無改修） |
| 向く問題 | 解法が既知 | 解法が未知、探索的 |
| 弱点 | 想定外の入力に弱い | 収束保証がない、コストが読みにくい |
現実世界に例えると
初版では「専門家チームと中央掲示板」に例えた。より正確な例えは 事件捜査本部のホワイトボード である。
- 鑑識、聞き込み、通信解析の担当者は、互いに逐一連絡を取らない。
- 各自がホワイトボードを見て、自分の専門で埋められる空白を見つけたら動く。
- 誰が次に動くかは、捜査の進展（ボードの状態）で変わる。事前の工程表はない。
- 捜査主任（制御）は、ボードを見て「今はどの線を優先するか」だけを決める。
黒板の階層（初版の訂正）
初版では階層を「戦略・タスク管理・問題解決・データ収集」という組織の階層として説明したが、これは不正確だった。黒板の階層は 解の抽象度の階層 である。
Hearsay-II では、音声信号から文までの仮説が抽象度別に並ぶ。
| レベル | Hearsay-II（音声理解） | ソフトウェア開発に写像した例 |
|---|---|---|
| 最上位 | 文・句 | 要件・受け入れ基準 |
| 上位 | 単語列 | 設計判断・インターフェース定義 |
| 中位 | 単語・音節 | 実装・テストケース |
| 下位 | 音素・セグメント | 実行ログ・テスト結果・静的解析結果 |
KSはレベル間を双方向に橋渡しする。
- ボトムアップ：下位の証拠から上位の仮説を立てる（テスト失敗 → 設計の誤りを仮説化）
- トップダウン：上位の仮説から下位への期待を生成する（要件 → 満たすべきテストケースを予測）
「組織の階層」と「解の抽象度の階層」を混同すると、黒板モデルは単なる階層型オーケストレーションに退化する。
LLM時代の黒板モデル
研究動向
LbMAS（Han & Zhang, 2025）
黒板アーキテクチャをLLMマルチエージェントに持ち込んだ実装。エージェントは黒板だけを介して通信し、黒板が各エージェントのメモリモジュールを代替する。制御ユニットもLLMで、黒板の内容を見て次に動かすエージェントを選び、黒板上で合意に達するまで繰り返す。常識推論・数学系データセットで、静的／動的な既存マルチエージェントと同等以上の平均性能を、より少ないトークン消費で達成した。
データサイエンス向け黒板システム（Salemi et al., 2025）
中央エージェントが黒板に「要求」を掲示し、各サブエージェントは自分が貢献できるかを自律的に判断して応答する。タスクの割り当てが存在しない点がmaster-slave型との決定的な違い。master-slave型は、中央コントローラが各サブエージェントの能力を正確に知っている前提に依存するが、大規模環境ではその前提が崩れる。最良ベースライン比で13〜57%の相対改善（エンドツーエンドのタスク成功率）を報告している。
AgentsCAD（2026）
黒板パターンを採用し、LLMを呼ばないルールベースの検出段を「決定論的な床」として組み込んだ。推論モデルと検証モデルを互いの存在を知らせずに差し替え可能にしている。
2系統の比較
| 観点 | メッセージパッシング型 （オーケストレータ／master-slave） |
黒板型 |
|---|---|---|
| 協調の媒体 | エージェント間メッセージ | 共有状態 |
| タスク割り当て | オーケストレータが指名 | エージェントが挙手、または制御が黒板を見て選択 |
| オーケストレータに必要な知識 | 全エージェントの能力 | 不要（黒板の読み書き規約のみ） |
| コンテキスト | 伝言のたびに要約・欠落が発生 | 一次情報が黒板に残る |
| エージェント追加コスト | オーケストレータのプロンプト改修 | 追加するだけ |
| 弱点 | オーケストレータがボトルネック | 黒板の肥大化、書き込み競合、収束判定 |
すでに使っている黒板
コーディングエージェントの実運用は、明示的に名乗らないまま黒板化している。
| 実装 | 黒板に相当するもの | 制御 |
|---|---|---|
| コーディングエージェント + サブエージェント | リポジトリ、計画ファイル、TODOリスト | 親エージェント |
| エージェントチーム（複数セッション並走） | 共有タスクリスト、作業ツリー | 各エージェントがタスクを自己取得 |
| グラフ型フレームワーク | 共有State オブジェクト | グラフ定義（固定寄り） |
| Agent Skills のパイプライン | 段ごとの成果物ファイル（JSON/YAML/Markdown） | workflow定義 + バリデータの終了コード |
ファイルシステムは、永続性・差分管理（git）・人間可読性を最初から備えた黒板である。専用の黒板ミドルウェアを作る前に、ファイルとスキーマで足りないかをまず検討すべきである。
決定論バリデータは最強のKSである
古典的な黒板モデルでは、KSはすべて「不確かな仮説を出す専門家」だった。LLM時代の設計で最も効くのは、LLMではないKSを混ぜることである。
- LLMのKS：仮説を生成する（不確実、創造的）
- 決定論KS：黒板上の成果物をスキーマ・ルールで検証し、合否と指摘を書き戻す（確実、非創造的）
黒板モデルの弱点である「収束保証がない」は、決定論KSが 「これ以上進んではいけない状態」と「完了状態」を機械的に宣言することで補える。LLMのKS同士が合意したことをもって完了とする設計（合意ベース収束）は、全員が同じ誤りに同意するリスクを持つ。完了判定はLLMの合意ではなくバリデータの exit 0 に置く。
人間も「承認という書き込みを行うKS」として同じ黒板に参加させると、Human-in-the-loop が特別扱いの例外処理ではなく通常のKSになる。
問題領域の分類：CA/NA と FA/C（初版の訂正）
Lesser & Corkill（1981）による定義は以下。
| 項目 | CA/NA Completely Accurate, Nearly Autonomous |
FA/C Functionally Accurate, Cooperative |
|---|---|---|
| 各ノードが持つ情報 | 局所処理に必要な情報は完全かつ正確 | 不完全・不整合・誤りを含みうる |
| 中間結果 | 常に正しい | 暫定的。誤った仮説を含む |
| 最終結果 | 正確 | 機能的に十分な精度（許容範囲内） |
| ノード間の関係 | ほぼ自律。必要な情報は明示的に要求して取得 | 協調が必須。暫定結果を交換し相互に制約して収束 |
| 通信 | 完全な情報を得るための同期・要求応答 | 暫定結果の非同期な交換 |
| 誤りへの態度 | 誤りは排除すべき例外 | 誤りは前提。問題解決の過程で吸収する |
| 典型例 | 分散データベース、分散トランザクション | 分散センサ網による状況解釈、音声理解 |
LLMエージェントは生まれつき FA/C である
LLMの出力は常に「誤りを含みうる暫定的な仮説」である。したがって LLMマルチエージェントは、定義上 FA/C システムである。
ここから設計上の帰結が出る。
- 個々のエージェントを正確にしようとする努力（CA/NA的発想）は費用対効果が悪い。 プロンプトを磨いて単体精度を99%にするより、誤った中間結果が黒板上で他のKSに潰される構造を作るほうが堅牢になる。
- 「エージェント間の出力が矛盾した」は障害ではなく、正常な中間状態である。 矛盾を検出して黒板に書くKSを用意する。
- CA/NA が必要な箇所は LLM に担わせない。 DB更新、課金、デプロイなど誤りが許されない操作は、決定論的なコードと人間承認に切り出す。
実装アーキテクチャ例（AWS）
初版では実行スケジューラに Step Functions を置いた。これは実行順序を固定するため、機会主義的制御という黒板モデルの本質と相性が悪い。黒板の変更イベントで KS を起動する構成に改める。
設計上の要点。
- 起動条件はKS側が宣言する。 「レベルXにステータスYのエントリが現れたら起動」という条件を各KSが持ち、制御はマッチングだけを行う。KS追加時に制御を改修しない。
- 書き込みは追記型にする。 上書きではなく、仮説エントリを追加し、信頼度と根拠エントリへの参照を持たせる。誰がどの証拠から何を導いたかが追跡可能になる。
- 書き込み競合は楽観ロックで処理する。 バージョン番号付きの条件付き書き込みを使い、失敗したKSは最新状態を読み直して再判断する。
- 黒板全体をプロンプトに入れない。 LbMAS のように黒板全体を毎回渡す方式は小規模でしか成立しない。KSごとに「読むレベル」と「読むエントリ種別」を絞るビューを定義する。
- 停止条件を3つ持つ。 決定論KSによる完了宣言、ラウンド数・トークン予算の上限、一定ラウンド黒板に変化がないことの検出。
黒板エントリのスキーマ例
{
"entry_id": "hyp-0042",
"level": "design",
"type": "hypothesis",
"status": "open",
"content": "注文APIは在庫引当を同期呼び出しではなくイベント経由にすべき",
"confidence": 0.7,
"author": "ks-architect",
"supports": ["ev-0017", "ev-0023"],
"contradicts": ["hyp-0031"],
"version": 3
}
supports と contradicts を持たせると、黒板は単なる共有メモではなく 論証グラフ になる。矛盾の検出、根拠が崩れた仮説の連鎖的な無効化を、LLMを使わずグラフ探索で実行できる。
黒板モデルを選ぶ基準
| 状況 | 推奨 |
|---|---|
| 解法が既知で、手順が固定できる | 固定ワークフロー。黒板は過剰 |
| エージェントが3つ以下で役割が明確 | オーケストレータ型で十分 |
| エージェントが多く、オーケストレータが全員の能力を把握できない | 黒板型 |
| 解法が未知で、どの専門性が効くか実行するまで分からない | 黒板型 |
| 監査・説明責任が要求される | 黒板型（追記型 + 根拠参照で証跡が残る） |
| 専門家（KS）を継続的に追加していく | 黒板型 |