# Portability: UNIVERSAL
# Last validated: 2026-05-17
# Next review: 2027-05-17
# リソース: [マルチ LLM プロトコル、ブリッジ、Swarm システム、クロード コード ドキュメント]

LLM 通信 -- すべてのメソッドの概要
================================================

現在: 2026-02-17
コンテキスト: LLM インスタンス (Claude、Gemini、Ollama) はどのように相互作用できるか
         そして外の世界と通信するのか？既知のものすべてのカタログ
         さまざまなシナリオへの適合性に従って評価されたメソッド。

21 の通信形式
========================

注: 15 の一般的なメソッド (1 ～ 15) + 6 つの BACH 固有のメソッド (16 ～ 21)。
汎用メソッドは任意の LLM システムに転送できます。
BACH 固有のものは BACH 独自のインフラストラクチャを使用します。

1。ファイルを残す (ファイルをドロップ)
-----------------------------------
   方法: LLM がファイルを書き込み、他の LLM が後でそれを読み取る
   方向: 単方向 (ライター -> リーダー)
   レイテンシー: 高 (リーダーは積極的に確認する必要があります)
   例: エージェントが result.txt を書き込み、次のエージェントがそれを読み取ります
   長所: 可能な限り単純な方法であり、インフラストラクチャは必要ありません。
   弱点: 通知メカニズムがない、タイミングの問題
   BACH: 多くのワークフローにおける基本的な方法

2. MEMORY.md (共有ファイル)
----------------------------------------
   方法: すべての LLM パートナーが同じ MEMORY.md の読み取り/書き込みを行う
   方向: 双方向 (すべての読み取りと書き込み)
   レイテンシー: セッションベース (変更は次のセッションから有効になります)
   例: クロードが教訓を書き、ジェミニが次のセッションでそれを読む
   強度: セッション開始時に自動的に挿入 (クロード コード)
   弱点: 200 行制限、リアルタイム性なし、手動で維持
   BACH: 現在、パートナーごとに 1 つ。 SQ043 は共有メモリ DB

3 を計画しています。共通メモリ (データベース)
---------------------------------------
   方法: 全員が書き込み/読み取りを行う中央 DB (bach.db)
   方向: 双方向、マルチパーティ
   レイテンシ: 即時 (セッション内の DB アクセスの場合)
   例: エージェントがファクトを保存し、他のエージェントがファクトをクエリする
   強み: 構造化、検索可能、重み付け、永続的
   弱点: DB アクセス ハンドラーが必要ですが、自動的には挿入されません。
   BACH: bach.db の事実、教訓、context_triggers (890 以上のエントリ)

4.通信としてのインジェクター
---------------------------------
   方法: システムリマインダーがメッセージストリームに挿入されます。
   方向: システム -> LLM (単方向)
   待ち時間: 即時 (次のメッセージ時)
   例: フックは、hook_Additional_context 経由でメッセージを挿入します。
   バリエーション:
     a) クロードコードインジェクター（52種類、制御不可）
     b) BACHインジェクター（5種類、LLM制御可能）
     c) フックベース (UserPromptSubmit は「受信箱」ファイルを読み取ります)
   強み: 積極的な検索を行わずにコンテキスト内に表示されます。
   弱点: CC インジェクターはユーザー/LLM によって制御できない
   BACH: ContextInjector、SessionInjector、PartnerInjector、
               HealthInjector、DonationInjector
   claude-code-injections.txt、injectors.txt

5 も参照してください。スティメルジ / マルゲーターの地図
--------------------------------------
   方法: エージェントはマーカー ファイル (フェロモン) を残します。
               他のエージェントはマーカーを読み取り、行動を適応させます
   方向: 間接双方向 (環境経由)
   レイテンシ: インスタント (ファイル システム)
   例: ボットは .visited.log を書き込み、他のボットは訪問エリアを回避します
   マーカー: .done、.in_progress、.visited.log、.counter、.flag
   長所: 直接的なコミュニケーションは必要なく、適切に拡張できる
   短所: マーカーが読み取られる保証はない、蒸発が必要
   BACH: data/swarm/map/、maintenance_swarm.py、marauders_map.py
   関連項目: trampelpfadanalyse.md (第 2 章: Swarm メソッド)

6。ハンドオフ ファイル (明示的なハンドオフ)
------------------------------------------
   方法: インスタンス間の構造化された転送ドキュメント
   方向: 単方向 (先行 -> 後続)
   レイテンシ: 即時 (後続処理が開始される前にファイルが書き込まれます)
   例: Marble Run: タスク、ステータス、結果、フィードバックを含む handoff.md
   長所: 完全なコンテキストの転送、構造化された、わかりやすい
   弱点: シリアルチェーンのみ、パラレル通信には対応していません。
   BACH: tools/llmauto/state/handoff.md (マーブル ラン パイプライン)

7.ブリッジ / コネクター (外部チャンネル)
------------------------------------------
方法: BACH が外部サービス経由でメッセージを送受信する
   方向: 双方向 (BACH <-> 人間/その他のシステム)
   遅延: 秒 (サービスによって異なります)
   例: ユーザーが電報メッセージを書き込み、BACH が応答
   チャネル: Telegram (ベータ)、Discord (ベータ)、HomeAssistant (ベータ)、
               Signal (予定)、WhatsApp (予定)
   強み: LLM 対 LLM だけでなく、現実世界とのコミュニケーション
   弱点: 外部 API に依存し、一部はスクレイピングベース
   BACH: コネクタ/、ハブ/connector.py、ブリッジ システム
   参照:bridge.txt、connectors.txt

8。クロード コード チーム モード
---------------------------
   方法: Claude Code CLI に組み込まれたチーム調整
   方向: 双方向 (リーダー <-> チームメイト)
   レイテンシー: 即時 (セッション内のメッセージキュー)
   例: チームリーダーが研究者にタスクを送信し、結果を取得
   機能: SendMessage、TaskList、TaskCreate、TaskUpdate、Broadcast
   強み: 人間本来の、よく統合された、並行作業
   弱点: クロード コード セッション内のみ、オーパスとソネットの組み合わせは不可
   BACH: 直接統合されていません (BACH ではなくクロード コード機能)

9。通信としての GIT
--------------------------
   メソッド: インスタンス間のメッセージとしてコミット + コミットメッセージ
   方向: 双方向 (プッシュ/プル)
   レイテンシ: 分 (コミット + プッシュ + プル)
   例: ワーカーが変更をコミットし、レビュー担当者が git diff + メッセージを読み取る
   長所: バージョン管理され、わかりやすい、標準ツール
   弱点: 小さなメッセージのオーバーヘッド、リポジトリが必要
   BACH: 系統的には使用されていませんが、使用される可能性はあります (SQ020 バージョン管理)

10。チャネルとしての DB テーブル
---------------------------
    方法: エージェントが共有 DB テーブルに書き込み、他のエージェントが読み取り
    方向: 双方向、マルチパーティ
    レイテンシー: 即時 (DB アクセスのセッション内)
    例: エージェントがメッセージ テーブルにメッセージを書き込み、受信者がポーリングする
    強み: 構造化、永続的、検索可能、既存
    弱点: ポーリングが必要 (プッシュなし)、ハンドラーが必要
    BACH: bach.db にはインフラストラクチャがありますが、明示的なメッセージ システムはありません

11。フック (イベントベースのインジェクション)
--------------------------------------
    方法: イベント時にシェルコマンドが実行され、結果が挿入されます。
    方向: 外部 -> LLM (フック呼び出しごとに一方向)
    待ち時間: 即時 (ユーザー プロンプトまたはツール呼び出しごと)
    例: UserPromptSubmit フックは「受信箱」ファイルを読み取り、コンテンツを挿入します
    フックの種類: PreToolUse、PostToolUse、SessionStart、UserPromptSubmit など。
    長所: ソースパッチを使用しないインスタンス間メッセージングの最も簡単な方法
    弱点: イベントのみ (オンデマンドではない)、フック設定が必要
    BACH: クロード コード統合の推奨アプローチ
    関連項目: claude-code-injections.txt (「メッセージング システム」セクション)

12。仲介としての MCP サーバー
-------------------------------
    方法: 複数の LLM インスタンスが使用する共有 MCP サーバー
    方向: 双方向 (すべてのインスタンスが同じサーバーにアクセスします)
    レイテンシー: 即時 (ツール呼び出し)
    例: すべての Claude インスタンスの共有サービスとしての ellmos-codecommander-mcp
    強み: 標準化 (MCP プロトコル)、ツールベース、拡張可能
    弱点: サーバーが実行されている必要があり、プッシュ メカニズムがない
    BACH: ellmos-codecommander-mcp (14 ツール)、ellmos-filecommander-mcp (38 ツール)

13。プロセス チェーン (シグナルとして .bat)
----------------------------------------
    方法: 1 つのプロセスがバッチ ファイル経由で次のプロセスを開始する
    方向: 単方向 (先行 -> 後続)
    レイテンシー: 即時 (プロセスの開始)
    例: Marble-Run: Opus Worker が終了し、.bat が Sonnet Reviewer を起動します
    強み: 決定的、インフラストラクチャなし、BS ネイティブ
    弱点: シリアル チェーンのみ、フィードバック チャネルなし (ハンドオフ ファイルが必要)
    BACH: tools/llmauto/ (llmauto-CLI) (マーブル ラン システム)

14.共有ファイル システム (ファイル ウォッチャー)
--------------------------------------
    方法: エージェントが共有ディレクトリの変更を監視する
    方向: 双方向 (すべて書き込み/読み取り可能)
    レイテンシー: 秒 (ウォッチャーのポーリング間隔)
    例: エージェントが new_task.json を書き込み、ウォッチャーが検出して応答する
    Starke: シンプルで特別なインフラストラクチャは不要
    弱点: ポーリングベース、競合状態の可能性、OneDrive 同期の問題
    BACH: 基本的には可能ですが、体系的には実装されていません

15。 STDOUT/STDIN 配管
-------------------------
方法: 1 つのプロセスの出力が次のプロセスの入力になる
    方向: 一方向 (プロデューサー -> コンシューマー)
    レイテンシー: インスタント (パイプ)
    例: クロード --print "X を分析" |クロード --print "レート: $(cat -)"
    長所: Unix 哲学、最小限のオーバーヘッド、ファイル システム不要
    弱点: テキストのみ、構造化されたコンテキストなし、永続性なし
    BACH: 使用されません (クロード コードは --print をサポートしますが、stdin パイプはサポートしません)

BACH 固有の通信形式 (16-21)
===============================================

16。 MULTI-LLM プロトコル V3 (プレゼンス + ロック)
-------------------------------------------------
    方法: プレゼンス ファイル + ロック ファイル + ファイル システムでのハンドシェイク
    方向: 双方向、マルチパーティ
    レイテンシ: 秒 (ハートビートは 30 秒ごと、タイムアウトは 120 秒)
    例: クロードは、.gemini_presence を介して Gemini がオンラインであることを認識します。
    機能: プレゼンス、ロック、ハンドシェイク、ハートビート、エージェント検出
    既知: クロード、ジェミニ、副操縦士、オラマ、パープレクシティ、ミストラルウォッチャー
    強み: 中央機関を持たない調整、競合状態でも安全
    弱点: ファイル システム ベース (DB より遅い)、古い存在の可能性がある
    BACH: Hub/multi_llm_protocol.py (V3)、CLI: bach llm present/check/lock

17. PARTNER-PRESENCE DB（スタンプカード）
----------------------------------------
    メソッド: SQLite テーブル Partner_presence と Clock_in/out/heartbeat
    方向: 双方向 (全員がログイン/ログアウト)
    レイテンシー: 即時 (DB クエリ)
    例: bach llm status -> 誰がオンラインで何をしているかを示します
    機能:クロックイン()、クロックアウト()、ハートビート()、get_online_partners()
    長所: ファイルよりも信頼性が高く、状態が永続的である
    弱点: DB アクセスが必要ですが、ファイル システムとの互換性はありません
    BACH: Hub/multi_llm_protocol.py (PartnerPresenceDB クラス)

18.メッセージ システム (受信ボックス/送信ボックス)
--------------------------------------
    方法: 送信者、受信者、本文、ステータスを含む DB ベースのメッセージング
    方向: 双方向、指向性 (受信機によって決定)
    レイテンシ: 即時 (クエリ時) またはポーリング (10 秒ごとの監視モード)
    例: bach msg send gemini 「この画像を分析してください」
    機能: 送信、読み取り、監視 (ポーリング)、Ping、読み取り確認 (--ack)
    ステータス: 未読、既読、アーカイブ済み
    長所: 構造化、永続的、検索可能、開封確認
    弱点: プルベース (プッシュなし)、アクティブなポーリングが必要
    BACH: Hub/messages.py、DB テーブル:messages

19.通知システム (マルチチャネルプッシュ)
--------------------------------------------------
    方法: 外部チャネル経由で通知を送信する
    方向: 単方向 (BACH -> 外部)
    遅延: 秒
    チャネル: Discord (Webhook)、Telegram (Bot API)、Slack (Webhook)、
                電子メール (SMTP/SSL)、シグナル (直接)、汎用 Webhook
    例: bach 通知「タスク完了」の電報を送信
    強み: マルチチャンネル、設定可能
    弱点：発信のみ（通知による受信は不可）
    BACH: Hub/notify.py、CLI: Bach Notice setup/send/test/list

20。キュー プロセッサとスマート ルーター
------------------------------------
    方法: コネクタ メッセージの信頼性の高いルーティング
    方向: 双方向 (コネクタ <-> BACH 内部)
    レイテンシー: 秒 (ポーリング間隔: Telegram 15 秒、Discord 60 秒)
    機能：リトライ/バックオフ（5段階：30秒～480秒）、サーキットブレーカー（5エラー）
    スマート: メッセージからコマンドを解析します (「/task add test」)
    長所: 信頼性、自己修復性、コマンド認識
    弱点: 複雑、デーモンの実行が必要
    BACH: Hub/_services/connector/queue_processor.py、smart_router.py

21。 GEMINI 委任プロトコル
--------------------------------
    方法: タスク ファイルは gemini/inbox/ にあり、結果は gemini/outbox/ になります。
    方向: 双方向 (クロード -> ジェミニとその逆)
    遅延: 数分から数時間 (手動または Google ドライブ同期経由)
    トリガー: キーワード、トークンバジェット、ドキュメントの長さ、明示的
    例: クロードが研究タスクを作成し、ジェミニがそれを処理し、結果を返します。
    強み: Gemini の強みを活用する (大きなドキュメント、画像)
    弱点: 手動転送が必要 (または Google ドライブ同期)
    BACH: skill/workflows/gemini-delegation.md

比較表
=================

方法 |方向 |レイテンシ |永続性 |スケーリング |複雑さ
  ----------|----------|----------|---------------|---------------|---------------
  GENERIC (任意の LLM システムに転送可能):
  1 ドロップファイル |大学 |高 |はい |良い |最小限
  2 メモリー.md |ビ |セッション |はい |限定 |低い
  3 共有DB |マルチ |すぐに|はい |とても良い |手段
  4 インジェクター |大学 |すぐに|いいえ |限定 |手段
  5 スティグマジー |間接的 |すぐに|はい (TTL) |とても良い |手段
  6 ハンドオフ ファイル |大学 |すぐに|はい |シリアル |低い
  7 ブリッジ/コネクタ |ビ |秒 |はい |良い |高
  8 チームモード |ビ |すぐに|セッション |パラレル |手段
  9 ギット |ビ |分 |はい |良い |手段
  10 DB テーブル |マルチ |すぐに|はい |とても良い |手段
  11 フック |大学 |イベント |いいえ |限定 |低い
  12 MCP サーバー |ビ |すぐに|変数 |良い |高
  13 プロセスチェーン |大学 |すぐに|いいえ |シリアル |低い
  14 ファイルウォッチャー |ビ |秒 |はい |良い |手段
  15 標準出力の配管 |大学 |すぐに|いいえ |シリアル |最小限

  BACH-SPECIFIC (BACH インフラストラクチャを使用):
  16 マルチLLMプロット。   |マルチ | 30代 |はい |良い |手段
  17 パートナーの存在 |マルチ |すぐに|はい |良い |手段
  18 メッセージ システム   |ビ |すぐに|はい |良い |手段
  19 通知（プッシュ） |大学 |秒 |はい |マルチチャンネル  |手段
  20 キュー/ルーター |ビ |秒 |はい |良い |高
  21 ジェミニ代表団 |ビ |分 |はい |限定 |低

使用状況別の推奨事項
==================================

  使用例 |推奨される方法
  ----------------------------------|-------------------------------------
  Swarm (多数の並列エージェント) | 5(スティグマジー)+3(DB)+14(ウォッチャー)
  シリアル パイプライン (マーブル ラン) | 6 (ハンドオフ) + 13 (プロセスチェーン)
  チームワーク (2 ～ 5 人のエージェント) | 8 (チームモード) または 10 (DB テーブル)
  長期的な知識の伝達 | 2(MEMORY.md)+3(DB)
  リアルタイム通知 | 4 (インジェクター) + 11 (フック)
  外部世界とのコミュニケーション | 7 (ブリッジ/コネクタ)
  非同期コラボレーション | 1 (ファイルをドロップ) + 9 (git)
  ツールベースの統合 | 12 (MCP サーバー)

BACH 固有のアーキテクチャ
==============================

BACH の強みは、いくつかの方法の組み合わせです。
- 外の世界への橋(7)
- 中央知識ストレージとしての DB (3+10)
- プロアクティブなコンテキスト強化のためのインジェクター (4)
- スティグマジー (5) 群れ作戦用
- マーブル ラン パイプラインのハンドオフ (6) + プロセス チェーン (13)

対照的に、クロード コードはシナリオごとに 1 つのメソッドに制限されています。
チーム モード (8) またはインジェクター (4)、組み合わせることはできません。

BACH は 15 のメソッドすべてを同時に使用でき、動的に切り替えることができます --
これは、LLM 中心のシステムのアーキテクチャ上の利点です。

関連項目
===========
  Bridge.txt ブリッジ/コネクタ システム
  Connectors.txt コネクタの種類の詳細
  injectors.txt BACH インジェクター システム
  claude-code-injections.txt クロード コードのインジェクションの構造
  multi-llm.txt マルチLLMプロトコル
  schwarm.txt Swarm オペレーション (存在する場合)
