context-pod

Event Pod

エージェントのコンテキスト。人間との認識合わせ。

エージェントは世界モデルを自律的に構築します。すべてのセッションを通じて観察し、学習し、確信度を更新します。人間はいつでも参加して、監査、修正、自然言語での共同作業ができます。チャットだけで十分です。

• MCP エンドポイント：https://context.nervousmachine.com/mcp
• ドキュメント全文：https://context.nervousmachine.com/docs
• ランディングページ：https://context.nervousmachine.com
• Substack：https://nervousmachine.substack.com
• 研究：https://www.techrxiv.org

エージェントは自律的に構築します。人間は自然に認識を合わせます。

すべてのレーンが同じポッド構造に書き込みます。コーディングエージェント、ワークフローエージェント、個人用チャットエージェントは、コンテキストを共有することも、それぞれ独自に維持することもできます。いずれの場合も、Chat レーンがすべてのエージェントにとっての認識合わせインターフェースになります。1つの会話で、どのエージェントが学習したことでも監査し、ずれた内容を修正し、エージェントだけでは観察できないことを追加できます。ほとんどの人は1つのレーンから始めます。ポッドは追加するにつれて自然に連携します。

---

目次

• クイックスタート
• Chat -- 認識合わせインターフェース
• エージェントの世界モデル
• コーディングとリポジトリのコンテキスト
• タスクとワークフローの自動化
• マルチエージェントとポッド間連携
• デバイスとエコシステム
• 完全なリファレンス

---

クイックスタート

サインアップ（30秒）

まだ認証情報がない場合は、次を実行してください。

curl -X POST https://context.nervousmachine.com/signup \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "HUMAN_FIRST_NAME",
    "last_name":  "HUMAN_LAST_NAME",
    "email":      "HUMAN_EMAIL",
    "use_case":   "DESCRIBE_WHAT_YOU_ARE_BUILDING"
  }'

認証情報付きのアクティベーション URL が返されます。クリックして確認してください。プロビジョニングはすぐに完了します。認証情報は直ちにメールで届きます。

MCP 設定に追加する

{
  "mcpServers": {
    "event-pod": {
      "url": "https://context.nervousmachine.com/mcp",
      "transport": "sse"
    }
  }
}

対応環境：Claude Desktop、Claude Code、Cursor、Cline、Gemini CLI、および MCP 互換クライアント全般。ローカルプロセスは不要です。リモートサーバーです。

システムプロンプトに追加する

これが統合に必要なすべてです。コピーして、USER_ID を置き換えれば完了です。あとはエージェントがライフサイクル全体を処理します。

You have access to Event Pod tools for persistent context.
User ID: YOUR_USER_ID

SESSION START:
Call get_pod_summary before responding to any task.
If the user describes their task, also call get_relevant_context
with that task as the query.

DURING THE SESSION:
- When the user corrects you: immediately call record_observation
  then apply_learning on the relevant event.
- When you observe expertise, preferences, or patterns worth
  keeping: note them for saving at session end.
- Once per session at a natural pause: call get_curiosity_triggers
  with max_triggers=2. Work one probe naturally into conversation.

SESSION END -- before the conversation closes:
1. Call save_event for each new signal observed this session.
   Start all certainty values at 0.3.
2. Call update_session with interactions=1.
   Call this exactly once -- never mid-session.

3つのルール

1. 確信度は常に 0.3 から始めてください。 裏付けが得られたら確信度を高めます。
2. record_observation -> apply_learning。 必ずこの順序で実行してください。
3. update_session は正確に1回だけ実行してください。 シャットダウン時に実行します。セッション中には実行しないでください。

統合を検証する

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "tools/call",
    "params": {
      "name": "get_pod_summary",
      "arguments": { "user_id": "YOUR_USER_ID" }
    }
  }'

ポッドの概要が返ってくれば、統合は完了です。

---

Chat -- 認識合わせインターフェース

Chat は、レーンにかかわらず、人間があらゆるエージェントと認識を合わせるためのものです。コーディングエージェントが誤った制約を学習した場合も、ワークフローポッドの承認経路が古くなった場合も、デバイスが理解できない何かを検知した場合も、Chat を使えば、ツールなしで自然言語によりすべてを修正できます。

エージェントが行うこと： コンテキストを自律的に構築します。コーディングエージェント、ワークフローエージェント、デバイスエージェントが、すべてのセッションを通じてポッドを構築します。

あなたが行うこと： 4つのプロンプトで認識を合わせます。概要を取得し、好奇心を確認し、保存し、更新します。これが手動で行うすべてです。それ以外は自動です。

チャットでの動作についての率直な説明。 Claude はポッドを確認すべきだと自動的に認識するわけではありません。確認するよう指示する必要があります。以下の4つのプロンプトを使う手間は、得られるものに比べればわずかです。他のレーンを使う開発者は、これらをワークフローに組み込むため、意識する必要がありません。チャットでは、自分で指示します。セッションの習慣になれば、合計で約10秒です。

60秒で接続する

Event Pod はリモート MCP サーバーです。AI クライアントの連携設定画面から一度追加するだけです。ターミナルも設定ファイルも必要ありません。

1. Claude.ai で設定を開く -- プロフィールアイコン（左下）をクリックし、次に Settings -> Integrations を選択します。
2. Event Pod を追加する -- Add Integration をクリックして、次を貼り付けます。

https://context.nervousmachine.com/mcp

3. チャットを開始してポッドを作成する -- 新しい会話を開きます。短い ID を選びます。名を使うのがおすすめです。以下の作成プロンプトから1つを使います。

4つのプロンプトの習慣

手動で行うのはこれだけです。4つのプロンプト、約10秒の手間で、ポッドが知っていることをすべて引き出せます。

#	タイミング	伝えること
1	初めてのセッション	この会話／ドキュメント／データから、[name] というポッドを作成してください
2	毎回のセッション開始時	[name] のポッドの概要を取得してください
3	セッション中の確認	私の好奇心を刺激するきっかけは何ですか？
4	終了前	今回のセッションで学んだことをポッドに反映してください

それ以外のすべて――学習、確信度の追跡、矛盾の検出、ナレッジグラフ――は、これらの呼び出しの中で行われます。

ポッドを作成する

これは一度だけ行います。最初に与えるコンテキストが豊富であるほど、早く役立つようになります。

ドキュメントから作成する

履歴書、プロジェクト概要、自己紹介、またはナレッジのダンプをアップロードします。Claude がそこから手がかりを抽出してポッドに取り込みます。初日から役立つポッドを作る最も早い方法です。

ユーザー ID を 'heidi' としてポッドを作成し、このドキュメントをもとに情報を取り込んでください。見つかった専門知識、好み、関心事、進行中のプロジェクトを抽出してください。

会話から作成する

これまで話し合った内容をもとに、'heidi' というポッドを作成し、私について学んだことを保存してください。

最初から作成する

まだポッドがありません。ユーザー ID を 'heidi' として作成してください。情報を取り込むために、自分についてお話しします。

メモを貼り付けて作成する

'heidi' というポッドを作成し、次のメモをもとに情報を取り込んでください：[自己紹介、スキル一覧、プロジェクトの説明、または思いつくままに書いた内容を貼り付けてください。どんなものでも使えます]。

たっぷり情報を取り込んでください。 ポッドはすべての情報の確信度が低い状態で始まります。これは意図的なもので、素早く更新されるということです。ただし、最初の情報が豊富であるほど、収束も早まります。仕事についての段落、いくつかの好み、進行中のプロジェクトが1つあれば、最初の本格的なセッションで違いを実感できます。

ポッドを視覚化する

ポッドを作成または読み込んだ後、Claude に図を描くよう頼んでください。export_cluster_diagram ツールはナレッジグラフを Mermaid 図として描画します。クラスター、つながり、既知の情報の構造を一目で確認できます。テキストの概要では見えにくいずれを見つける最も早い方法です。

ポッド全体の図：

ポッドの図を見せてください。すべてがどのようにつながっているか確認したいです。

トピックを中心にした表示：

Python の専門知識を中心にしたポッドの図を見せてください。何がつながっていますか？

更新後：

たった今ポッドを更新しました。追加された内容を確認できるよう、更新後の図を見せてください。

この図は、整合性を確認するための表示です。誤ったつながり、含めるべきでないノード、明らかな欠落など、すべてが図に表れます。何かがおかしいと感じたら、そのまま伝えてください。その修正が手がかりとなり、クラスター全体の精度が高まります。

ポッドの概要を取得する

毎回のセッション開始時に使います。軽量な処理で、ポッド全体を読み込むことなく、最も重要な手がかりとその補足情報、新しさを取得します。セッションの流れを妨げないほど高速です。

heidi のポッドの概要を取得してください。

タスクに合わせて始める場合は、次のようにします。

[タスクの説明] に取り組みます。始める前に、ポッド（heidi）から関連するコンテキストを取得してください。

概要と全体の読み込み。 通常はポッドの概要を使うのが適切です。高速で、対象が絞られており、Claude に必要な情報を渡せます。すべてを確認する深い監査を行う場合や、何かおかしいと感じる場合に限り、「ポッド全体を読み込んで」と頼んでください。

好奇心のきっかけ

好奇心のきっかけとは、ポッド自身についてまだわかっていないことです。不確かな情報や古くなった情報、まだ検証されていない情報が手がかりになります。定期的に確認することで、ポッドは時間とともにより賢くなります。すべてに答える必要はありません。セッションごとに一つか二つ答えるだけでも、大きな積み重ねになります。

好奇心のきっかけは何ですか？ 私について、ポッドが最も知りたがっていることは何ですか？

ポッドをまたいだ好奇心：

個人用、コーディング用、ワークフロー用、デバイス用など複数のポッドがある場合は、1回のチャットセッションでそれらすべての好奇心を確認できます。これはチャットインターフェースが実現する最も強力な機能の一つで、個々のエージェントが単独で行うことはできません。

ポッド heidi、heidi-coding、heidi-workflow の要約を取得してください。それから、3つすべてに共通する主な好奇心のきっかけ、つまり最も不確かなことや未解決のことを教えてください。

個人用ポッド（heidi）とコーディング用ポッド（heidi-coding）を比較してください。一方が知っていて、もう一方と共有すると役立つことはありますか？

ポッドを更新する

ポッドがすでに読み込まれていれば、Claudeは話題に上がったことを自然に更新することがよくあります。毎回指示する必要はありません。ただし、それだけに頼らないでください。セッションを終える前に簡単なプロンプトを送れば、情報の抜けを防げます。

セッションのまとめ：

終了する前に、今回のセッションで新たに学んだ私に関する情報をポッドに更新してください。

特定の情報を保存する：

私がエンジニア5人のチームを率いていて、主にGoを使っていることをポッドに保存してください。

間違った情報を修正する：

ポッドには簡潔な回答が好みだと書かれていますが、もう違います。今は例を交えた詳しい説明を希望します。修正してください。

セッションのまとめを省略しないでください。 セッション中に得たコンテキストは、明示的に保存しない限り保持されません。まとめのプロンプトにかかる時間は5秒です。省略すると、チャットを閉じたときにセッションで得た情報が失われます。

チャットであらゆるエージェントの認識を合わせる

チャットは個人的なコンテキストのためだけのものではありません。実行するすべてのエージェントに対する修正レイヤーでもあります。エージェントは自律的に構築されます。ずれた部分は、自然な言葉で修正できます。

分野	認識を合わせる内容	プロンプトの例
コーディング	誤ったアーキテクチャ上の制約、古くなった技術スタック、採用しなかったアプローチ	「コーディング用ポッドはgRPCを使っていると思っていますが、6か月前にやめました。修正してください。」
ワークフロー	古くなった承認経路、非推奨の連携機能、変更されたポリシー	「Stripeのバックアップは非推奨になりました。ワークフロー用ポッドから削除してください。」
マルチエージェント	エージェント間の認識のずれ、引き継ぎの抜け、相反する世界モデル	「調査エージェントと修正エージェントで、JWTのアプローチに関する見解が異なります。両方を示して、解決を手伝ってください。」
デバイス	原因不明の異常、センサーのオフセット、意図と優先度の設定	「15日の気温上昇は、計画的な加熱テストによるものでした。デバイス用ポッドに原因を記録してください。」

FAQ

Claude がポッドを自動的に読み込まないのはなぜですか？

MCP ツールは Claude から利用できますが、指示されない限り、どのツールを呼び出せばよいかはわかりません。セッション開始時のポッドの自動読み込みは、今後のロードマップに含まれています。現時点では、「pull my pod summary for [name]」がきっかけになります。2 秒で済み、すぐに習慣になります。

完全な読み込みではなく、要約なのはなぜですか？

get_pod_summary は高速で、Claude が調整に必要なシグナルを読み込みます。完全なポッドには、確度の低いシグナル、生のメタデータ、グラフ全体など、すべてが含まれます。通常のセッションですべてが必要になることはほとんどありません。通常は要約を使い、監査には完全な読み込みを使ってください。

無料の Claude.ai プランでも使えますか？

はい。MCP 統合はすべての Claude.ai プランで利用できます。

同じポッドを Gemini や Cursor でも使えますか？

はい。Event Pod はモデルに依存しません。MCP 対応クライアントであれば、どれでも同じポッドに接続できます。コンテキストは Claude だけに限定されず、どこでも引き継がれます。

Claude の組み込みメモリとはどう違いますか？

Claude のメモリは会話の断片を保存します。Event Pod は確度スコア、意味的なつながり、好奇心に基づく学習を備えた構造化モデルを構築し、使用するあらゆるツールやモデルで機能します。これは単なるストレージではなく、時間とともに精度が高まるモデルです。

---

エージェントのワールドモデル

エージェントは、自身の脳の主な作成者です。あなたは編集者です。このセクションでは、中心となる概念と、Event Pod の 2 つの使い方を説明します。エージェントが自らコンテキストを構築する自律モードと、保存する内容を正確に定義する制御モードです。

自律モード： エージェントが自らの脳を構築します。システムプロンプトは 1 つです。何を観察し、保存し、関連付けるかはエージェントが判断します。必要に応じて、人間がチャットで調整します。

制御モード： 保存する内容をあなたが定義します。ツールを明示的に呼び出します。イベント、関係性、リソースを正確に指定します。自動化よりも精度が必要な場合に使用します。

概要

エージェントの各セッションは、永続的なコンテキストを与えない限り、ゼロから始まります。Event Pod は永続化レイヤーです。エージェントが学習した内容を構造化モデルとして保持し、各シグナルへの確信度を確度スコアで示します。

Event Pod は、エージェントが HTTP 経由で接続する MCP サーバーです。エージェントは save_event、apply_learning、get_pod_summary などのツールを呼び出し、Event Pod が永続化を処理します。ポッドはエージェントのコンテキストウィンドウ内ではなくサーバー上にあるため、セッション、モデル、ツールをまたいで保持されます。すべてのポッドには、エージェント（ツール呼び出し経由）と人間（チャット経由）の 2 者が同時に接続します。Claude、Gemini、Cursor、カスタムエージェントなど、MCP 対応クライアントであればどれでも同じポッドに接続できます。

重要なポイントは、エージェントの脳をあなたが作成する必要はないということです。 適切なシステムプロンプトがあれば、エージェントは関連する内容を観察して保存し、自らナレッジグラフを構築します。人間の役割は調整です。エージェントが学習した内容を監査し、ずれを修正し、エージェントには観察できないコンテキストを追加します。

1 つのエージェントに複数のレーン。 レーンは、構築するコンテキストの種類を表すものであり、別々のシステムではありません。実際のコーディングエージェントは、コードベースの知識にはコーディングレーン、デプロイのパターンにはワークフローレーン、ユーザーの好みにはチャットレーンを利用します。すべてのシグナルが 1 つのポッドに集まり、get_relevant_context を通じてまとめて取得できます。自由に組み合わせてください。

2 つのモード

	自律モード	制御モード
セットアップ	システムプロンプトのスニペットを追加するだけ	ライフサイクルフックに明示的なツール呼び出しを組み込む
保存する内容を決める人	エージェント	あなた
最適な用途	ほとんどの用途。自然に学習させる	特定のイベント、関係性、または精度が必要な場合
人間の役割	チャットで調整する。監査、修正、拡張	スキーマを設計し、チャットで調整する
必要なコード	不要。システムプロンプトのみ	必要。Python／JS／curl

ほとんどのエージェントは自律モードから始め、成熟するにつれて、価値の高い特定のシグナルを制御モードで保存する機能を追加します。どちらか一方を選ぶ必要はありません。併用できます。

自律モード

これをシステムプロンプトに追加してください。あとはエージェントが処理します。セッション開始時のコンテキストの読み込み、セッション中のシグナルの観察、好奇心を促すきっかけの提示、終了時に学習内容を永続化します。

## Event Pod -- Context Instructions

You have access to Event Pod tools for persistent context.
User ID: {USER_ID}

SESSION START:
Call get_pod_summary before responding to any task.
If the user describes their task, also call get_relevant_context
with that task as the query.

DURING THE SESSION:
- When the user corrects you: immediately call record_observation
  then apply_learning on the relevant event.
- When you observe expertise, preferences, or patterns worth
  remembering: note them for saving at session end.
- Once per session at a natural pause: call get_curiosity_triggers
  with max_triggers=2. Weave one probe naturally into conversation --
  don't list them as questions.

SESSION END -- before the conversation closes:
1. Call save_event for each new signal observed this session.
   Start all certainty values at 0.3.
2. Call update_session with interactions=1.
   Call this exactly once -- never mid-session.

IMPORTANT:
- You decide what's worth saving. Not every mention -- sustained
  patterns, explicit corrections, and clear preferences only.
- The human can audit and correct anything via chat at any time.

ほとんどのユースケースでは、これだけで十分です。エージェントはセッションをもとに独自のモデルを構築します。人間はチャットを通じて調整します。追加のコードなしで、ポッドは時間とともに成長します。

制御モード

特定のイベントを定義したい場合、シグナル間に明示的な関係を構築したい場合、またはリソースをコンテキストに紐付けたい場合は、制御された保存を使用してください。制御モードと自律モードは組み合わせて利用できます。正確に追跡したいシグナルについて、システムプロンプトに明示的な保存処理を追加してください。

特定のイベントを保存する：

await call_pod("save_event", {
    "user_id": "heidi",
    "key": "python",
    "signal_type": "competence",
    "value": 0.85,
    "certainty": 0.3,       # always start low
    "gloss": "Strong Python -- corrects examples, uses advanced patterns",
    "validation_type": "logic",
    "meta": { "observed_via": "code_review" }
})

2つのイベントを意味的に関連付ける：

await call_pod("link_events", {
    "user_id": "heidi",
    "source_key": "python",
    "source_signal_type": "competence",
    "target_key": "data-science",
    "target_signal_type": "competence",
    "relationship": "ENABLES",
    "note": "Python expertise enables data science work"
})

リソースをイベントに添付する：

await call_pod("link_resource", {
    "user_id": "heidi",
    "key": "python",
    "signal_type": "competence",
    "resource_type": "project",
    "resource": {
        "name": "acme/backend",
        "project_id": "acme/backend",
        "note": "Primary Python codebase"
    }
})

ライフサイクルフック（制御モード）

システムプロンプトに依存せず、明示的なコードを組み込む場合は、次の4つの関数でライフサイクル全体をカバーできます。それぞれ、そのまま使える Python コードです。call_pod を、MCP クライアントのツール呼び出しメソッドに置き換えてください。

Init -- セッション開始時

async def agent_init(user_id: str, task: str = None):
    summary = await call_pod("get_pod_summary", {
        "user_id": user_id,
        "include_glosses": True,
        "include_freshness": True
    })
    context = None
    if task:
        context = await call_pod("get_relevant_context", {
            "user_id": user_id,
            "query": task,
            "max_results": 10,
            "include_resources": True
        })
    return summary, context

Observe -- セッション中のシグナル

async def agent_observe(user_id, session_id, key, signal_type,
                        observation_type, direction, raw_content, error_magnitude):
    # Always: record first, then apply
    await call_pod("record_observation", {
        "user_id": user_id, "session_id": session_id,
        "key": key, "event_signal_type": signal_type,
        "signal_type": observation_type,
        "signal_data": { "direction": direction, "raw_content": raw_content }
    })
    await call_pod("apply_learning", {
        "user_id": user_id, "key": key, "signal_type": signal_type,
        "error_direction": direction, "error_magnitude": error_magnitude
    })

誤差の大きさの目安：

発生したこと	大きさ	方向
独立した裏付け	0.05--0.1	増加
同じ情報源による繰り返し	0.02--0.05	増加
具体性の向上	0.1--0.15	増加
時間的な確認	~0.1	増加
ユーザーによる否定または訂正	0.2--0.4	減少

Curiosity -- 定期的な探索

async def agent_curiosity(user_id: str, max_triggers: int = 3):
    return await call_pod("get_curiosity_triggers", {
        "user_id": user_id,
        "max_triggers": max_triggers,
        "include_probes": True
    })
    # Use triggers[n].suggested_probes as conversation starters
    # Rephrase naturally -- never read them verbatim

Shutdown -- セッション終了時

async def agent_shutdown(user_id: str, new_events: list):
    for event in new_events:
        await call_pod("save_event", {
            "user_id": user_id,
            "key": event["key"],
            "signal_type": event["signal_type"],
            "value": event["value"],
            "certainty": event.get("certainty", 0.3),
            "gloss": event.get("gloss", ""),
            "meta": event.get("meta", {})
        })
    # Exactly once -- never mid-session
    await call_pod("update_session", {
        "user_id": user_id, "interactions": 1
    })

シグナルの種類

種類	追跡する内容	キーの例
competence	スキルまたは知識レベル	python, distributed-systems
preference	コミュニケーションまたは作業のスタイル	verbosity, code-before-explanation
claim	追跡対象の命題または信念	microservices-preferred
entity	名前のある人物、組織、またはツール	tool-terraform, company-acme
event	インシデント、マイルストーン、意思決定	auth-refactor-completed
metric	測定可能な数値	api-latency-p99
pattern	繰り返し現れる行動または傾向	prefers-examples-over-theory
state	現在の状況または段階	project-alpha-status

確実性と学習

すべてのイベントには、0から1までのcertaintyスコアがあります。システムは不確かな点には柔軟に、確かな点には安定的に対応します。学習率は自動的に調整されます。方向と大きさを設定すれば、学習率はシステムが処理します。

範囲	意味	挙動
0.0 -- 0.3	低 -- 新しい、または裏付けが弱い	速く更新され、修正を受け入れやすい
0.3 -- 0.6	中 -- 確信を構築中	中程度の更新率
0.6 -- 0.8	高 -- 十分な裏付けがある	ノイズに影響されにくい
0.8 -- 1.0	非常に高い -- 定着している	強い矛盾がある場合にのみ変化する

**新しいイベントは必ず0.3から始めてください。**確実性を手動で高く設定しないでください。裏付けを積み重ねて高めましょう。

人間との調整

エージェントは観察できる情報を構築します。人間は、エージェントが観察できない組織的な背景、意図、セッション外で行われた意思決定を補います。チャットインターフェースは、どちらのモードでも調整のためのレイヤーです。人間側でコードを書く必要はありません。

**人間との調整を促すエージェントを設計してください。**好奇心を促すきっかけを、自然な会話として提示します。セッション終了時に保存した内容を示します。人間が視覚的に不一致を見つけられるよう、Mermaid の図を定期的に提示します。人間が早く訂正するほど、確実性は真実に早く収束します。

コーディングとリポジトリのコンテキスト

コーディングエージェントは、スタック、チームの規約、失敗パターン、アーキテクチャ上の決定を自ら把握します。すでに却下した案を再び提案することはありません。制約が存在する理由も理解しています。失敗を、その原因となったアーキテクチャ上の決定と結び付けます。

自律型： エージェントがコードベースのマップを構築します。セッションごとにスタック、規約、失敗、制約を観察します。事前にスキーマを定義する必要はありません。

制御型： 価値の高いシグナルを定義します。明示的なリポジトリのコンテキスト、失敗パターンへのリンク、添付したドキュメントや ADR を使用します。精度が重要な場合に適しています。

概要

永続的なコンテキストを持たないコーディングエージェントは、セッションのたびに同じことを調べ直します。スタックについて質問し、解決策の選択肢を一括して排除する制約を見落とし、チームが 6 か月前に試して断念したアプローチを提案します。Event Pod は、エージェントが時間をかけてコードベースのモデルを蓄積できるようにすることで、この問題を解決します。

主な作成者はエージェントです。事前に定義した合成スキーマではなく、実際のセッションから重要な点を観察します。人間の開発者もチャットを通じて関与し、エージェントが観察できない組織内のコンテキストを追加します。Slack での決定、契約上の制約、あるライブラリが禁止された理由などです。

自律モード — コーディングシステムプロンプト

コーディングエージェントのシステムプロンプトにこれを追加します。Claude Code、Cursor、Cline、または MCP 対応の IDE エージェントで使用できます。エージェントはセッションから独自のコードベースモデルを構築します。何かにずれが生じたら、チャットを通じて調整します。

## Event Pod -- Coding Context

You have access to Event Pod tools. User ID: {USER_ID}

SESSION START:
1. Call get_pod_summary for this user.
2. Call get_repo_context for repo: {REPO_NAME}.
3. If a specific task is described, call get_relevant_context
   with that task as the query.

DURING THE SESSION -- observe and save:
- Stack, languages, frameworks encountered -> competence events
- Architectural rules and constraints -> claim events
- Approaches that failed or were rejected -> event signals
  (always include WHY in the gloss and a revisit_when in meta)
- Recurring failure patterns -> pattern events
- Team conventions and process rules -> preference events
- Current work in progress -> state events

When the user corrects your understanding of the codebase:
immediately call record_observation then apply_learning.

SESSION END:
1. Save all new signals observed (save_event for each).
2. Update repo context if stack or constraints changed
   (save_repo_context).
3. Call update_session with interactions=1 -- exactly once.

エージェントは、何を保存する価値があるかを判断します。言及された内容をすべて保存するのではなく、継続的なパターン、明示的な制約、確認済みの失敗だけを保存します。これは意図的なものです。ノイズの多い Pod は、不完全な Pod よりも調整が難しくなります。

制御モード

エージェントが知っていることを明示的に定義したい場合は、制御型の保存を使用します。新しいエージェントへの初期情報の登録、セッション内で決定されなかった内容の記録、シグナル間の正確な関係の構築などに利用できます。自律モードと組み合わせて使用できます。

リポジトリのコンテキスト

save_repo_context は、同じリポジトリでのすべてのセッションを通じて保持されるコードベースのメタデータを保存します。これはコード自体に関する共有知識であり、ユーザーレベルのシグナルとは別のものです。

リポジトリのコンテキストを明示的に登録する：

await call_pod("save_repo_context", {
    "user_id": user_id,
    "repo_name": "acme/backend",
    "metadata": {
        "stack": ["Go 1.22", "PostgreSQL 15", "Redis", "Temporal"],
        "architecture": "Modular monolith, domain-driven",
        "constraints": [
            "No ORM -- raw SQL only",
            "No global state",
            "All DB calls use context cancellation"
        ],
        "test_strategy": "Table-driven unit tests, integration tests in /testdata",
        "deploy": "GitHub Actions -> staging -> manual prod promotion",
        "conventions": [
            "Conventional commits",
            "PR review required before merge",
            "No force-push to main"
        ]
    }
})

セッション開始時に読み込む：

repo = await call_pod("get_repo_context", {
    "user_id": user_id,
    "repo_name": "acme/backend"
})

失敗の記憶

却下されたアプローチは、コーディングエージェントが記憶しておくべき最も価値のある情報であり、ステートレスなエージェントが次のセッションで真っ先に再提案するものです。数か月後にも役立つよう、十分なコンテキストを添えて保存してください。

await call_pod("save_event", {
    "user_id": user_id,
    "key": "grpc-streaming-rejected",
    "signal_type": "event",
    "value": 1.0,
    "certainty": 0.9,
    "gloss": "Tried gRPC streaming for real-time updates. Reverted: complexity too high for current team size. REST + polling is sufficient at current scale.",
    "meta": {
        "decided_by": "team",
        "date": "2025-11",
        "revisit_when": "team > 10 engineers OR > 10k concurrent users"
    }
})

必ず revisit_when を含めてください。 「それは試しました」を「それは試しました。再び試す価値があるのは、こういう場合です」に変えられます。状況が変化すると、エージェントがこうした情報を先回りして提示できます。

失敗と制約のリンク

制御モードの真価は、シグナルを意味的に結び付けることにあります。制約につながった失敗パターン。決定を可能にした制約。こうしたリンクによって、エージェントはルールの内容だけでなく、そのルールが存在する理由も説明できます。

失敗パターンを、その原因となった制約に結び付ける：

# Save the failure pattern
await call_pod("save_event", {
    "user_id": user_id,
    "key": "connection-pool-exhaustion",
    "signal_type": "pattern",
    "value": 0.9,
    "certainty": 0.85,
    "gloss": "Pool exhaustion under load -- seen 3x in prod. Always traced to unbounded concurrent queries."
})

# Save the architectural constraint it produced
await call_pod("save_event", {
    "user_id": user_id,
    "key": "max-db-connections-constraint",
    "signal_type": "claim",
    "value": 1.0,
    "certainty": 0.95,
    "gloss": "Hard cap: 20 DB connections per service instance. Non-negotiable.",
    "meta": { "set_by": "ops", "date": "2025-08" }
})

# Link them -- failure ENABLES constraint (caused it to exist)
await call_pod("link_events", {
    "user_id": user_id,
    "source_key": "connection-pool-exhaustion",
    "source_signal_type": "pattern",
    "target_key": "max-db-connections-constraint",
    "target_signal_type": "claim",
    "relationship": "ENABLES",
    "note": "Pool exhaustion incidents caused this constraint to be imposed"
})

ADR または設計ドキュメントを制約に添付する：

await call_pod("link_resource", {
    "user_id": user_id,
    "key": "max-db-connections-constraint",
    "signal_type": "claim",
    "resource_type": "url",
    "resource": {
        "name": "ADR-012: DB connection limits",
        "url": "https://github.com/acme/backend/blob/main/docs/adr/012-db-connections.md",
        "note": "Full decision record with context and alternatives considered"
    }
})

リンクされたリソースは自動的に提示されます。 エージェントが DB 接続に関連する項目について get_relevant_context を呼び出すと、ADR へのリンクも一緒に表示されます。エージェントは、その決定記録の存在を知らされなくても引用できます。

人間によるアラインメント -- コーディング

エージェントはコードを観察できますが、組織の知識を持っているのはエンジニアです。Slack での決定、2 四半期前のホワイトボードセッションで却下されたアプローチ、特定のライブラリがコードベースで禁止された理由――こうした情報は、セッションだけでは観察できません。開発者はチャットを通じてこの情報を追加します。

エージェントには見えないコンテキストを追加する：

昨年、GraphQL を採用しないと決めたことをコーディングポッドに保存してください。チームは、現在の規模では柔軟性よりも N+1 問題のデメリットが大きいと判断しました。これを acme/backend リポジトリのコンテキストに追加してください。

コードベースのマップを監査する：

acme/backend のアーキテクチャについて、私のポッドは何を把握していますか？追跡している制約を見せてください。

ナレッジグラフを確認する：

DB 接続の制約を中心としたコーディングポッドの図を見せてください。それと何がつながっていますか？

情報のずれを修正する：

私のポッドには Conventional Commits を使っているとありますが、6 か月前に自由形式のメッセージに戻しました。更新してください。

---

タスクとワークフローの自動化

運用環境を把握しているワークフローエージェントなら、ステートレスなエージェントには扱えないタスクを処理できます。どのツールが何に接続しているか、どこで問題が起きるか、どのような承認が必要か。エージェントは実行のたびにこのモデルを構築し、人間は自分だけが提供できる組織のコンテキストを追加します。

自律型： エージェントが環境をマッピングします。実行のたびに、統合、障害モード、パターンを学習します。運用モデルは自動的に構築されます。

制御型： 制約を設定します。承認フロー、権限、サービスマップなどです。精度と監査可能性が重要な場合に使用します。

概要

ワークフローエージェントはコンテキストの喪失によって時間を無駄にします。どの統合が現在有効か、前回何が壊れたか、どの手順に承認が必要かを再発見することになるためです。Event Pod は、リセットされずに蓄積される永続的な運用モデルをワークフローエージェントに提供します。エージェントは実行を通じてモデルを構築し、オペレーターは初日から適用する必要がある制約を設定します。

自律モード -- ワークフローシステムプロンプト

## Event Pod -- Workflow Context

You have access to Event Pod tools. User ID: {USER_ID}

SESSION START:
1. Call get_pod_summary for this user.
2. Call get_service_context to check integration status.
3. Call get_agent_context for agent_id: {AGENT_ID},
   context_type: task_history to review recent runs.

DURING RUNS -- observe and save:
- New tool or service integrations -> entity events
  (include auth type, permissions, and any write restrictions)
- Approval requirements discovered -> claim events
  (include threshold, approver, and SLA in meta)
- Recurring failures or edge cases -> pattern events
  (include workaround and first-seen in meta)
- Current service health issues -> save_service_context

AFTER EACH RUN:
1. Call save_agent_context with context_type: task_history.
   Include what completed, what failed, and why.
2. Save any new patterns or constraints discovered.
3. Call update_session with interactions=1 -- exactly once.

承認フローは、正しく設定することが最も重要です。 実行中にエージェントが承認要件を見つけた場合は、シャットダウンまで待たず、すぐに保存する必要があります。次回の実行では、最初からその要件が守られます。

制御モード

最初の実行前に制御された保存を使って運用モデルを設定し、エージェントが手探りで制約を発見するのではなく、既知の制約を把握した状態で開始できるようにします。

ツールの統合

統合マップを明示的に設定する：

await call_pod("save_event", {
    "user_id": user_id,
    "key": "salesforce-crm",
    "signal_type": "entity",
    "value": 1.0,
    "certainty": 0.95,
    "gloss": "Salesforce connected via OAuth. Agent is read-only. All writes require human approval.",
    "meta": {
        "auth_type": "oauth",
        "agent_permissions": "read",
        "write_approval_required": True,
        "approver": "ops-lead",
        "approval_sla_hours": 4
    }
})

承認フロー

承認要件は、エージェントが必ず守らなければならない絶対的なルールです。エージェントが違反して発見する必要がないよう、明示的に設定してください。

承認ルールを設定する：

await call_pod("save_event", {
    "user_id": user_id,
    "key": "payment-approval-required",
    "signal_type": "claim",
    "value": 1.0,
    "certainty": 0.99,  # high -- this is a hard rule
    "gloss": "Any payment over $500 requires finance approval. Under $500 is autonomous.",
    "meta": {
        "threshold_usd": 500,
        "approver": "[email protected]",
        "sla_hours": 4,
        "escalation": "[email protected] if no response in 4h"
    }
})

承認フローを統合に関連付ける：

await call_pod("link_events", {
    "user_id": user_id,
    "source_key": "payment-approval-required",
    "source_signal_type": "claim",
    "target_key": "salesforce-crm",
    "target_signal_type": "entity",
    "relationship": "PART_OF",
    "note": "Payment approval rule governs all Salesforce write operations"
})

サービスのコンテキスト

ワークフローが依存するサービスの健全性を追跡します。エージェントはセッション開始時にこれを確認し、依存先の状態が低下している場合は手順をスキップしたり、別の経路に切り替えたりできます。

await call_pod("save_service_context", {
    "user_id": user_id,
    "service_name": "payment-gateway",
    "status_data": {
        "status": "degraded",
        "last_checked": "2025-11-15T14:32:00Z",
        "known_issues": ["High latency on EU endpoints"],
        "fallback": "stripe-backup"
    }
})

タスク履歴

各実行で何を行い、何を決定し、何に遭遇したかを保存します。次回の実行では、失敗やその理由も含め、これまでの経緯をすべて把握した状態で作業を再開できます。

await call_pod("save_agent_context", {
    "user_id": user_id,
    "agent_id": "invoice-workflow",
    "context_type": "task_history",
    "data": {
        "task": "Process November invoices",
        "completed": 47,
        "failed": 3,
        "failure_reason": "Vendor ID mismatch on EU invoices (legacy pre-2023 format)",
        "flagged_for_review": ["INV-2041", "INV-2089"],
        "duration_minutes": 12
    }
})

失敗パターン

実行で繰り返し発生する形で失敗した場合は、そのパターンを保存します。エージェントはそれを予測できるようになり、前提条件の確認、代替手段の選択、問題が波及する前の人間への報告が可能になります。

await call_pod("save_event", {
    "user_id": user_id,
    "key": "eu-invoice-vendor-mismatch",
    "signal_type": "pattern",
    "value": 0.8,
    "certainty": 0.75,
    "gloss": "EU invoices with pre-2023 vendor ID format fail matching. Route to manual review.",
    "meta": {
        "first_seen": "2025-09",
        "frequency": "~5% of EU invoices",
        "workaround": "manual-review queue",
        "fix_status": "backlog -- vendor migration Q1 2026"
    }
})

人間による調整 -- ワークフロー

運用上のコンテキストは人々の頭の中にあります。半年前の承認経路、苦い経験から学んだベンダー特有の事情、契約による統合上の制約などです。エージェントは、遭遇した内容を構築します。オペレーターは、エージェントが観察できない情報を追加します。

文書化されていない制約を追加する：

すべての新しいベンダー契約は、統合を本番稼働させる前に法務チームが確認する必要があることを、私のワークフローポッドに保存してください。どこにも書かれていませんが、常に必要な手順です。

古くなった状態を更新する：

Stripe のバックアップ統合は先月廃止されました。サービスコンテキストから削除し、支払いのフォールバックを更新してください。

エージェントが把握している内容を監査する：

私のワークフローポッドは請求書の処理について何を把握していますか？どのような障害パターンを追跡していますか？承認経路の制約を表示してください。

---

マルチエージェントとポッド間連携

複数のエージェントがそれぞれ独自の世界モデルを構築します。ポッドを使えば、すべてをまとめる中央オーケストレーターがなくてもエージェント同士が連携できます。また、エージェント同士で合意できないことを人間が解決する方法がチャットです。

エージェントが行うこと： 独立して構築します。各エージェントは独自のモデルを蓄積します。引き継ぎによってコンテキストを引き継ぎます。相違点は自然に明らかになります。

人間が行うこと： 相違点を解決します。エージェント同士の意見が分かれたとき、人間がチャットで判断します。解決内容はすべてのエージェントに配信されます。全員がその恩恵を受けます。

概要

マルチエージェントシステムでは、引き継ぎの際にコンテキストが失われます。エージェント A が詳細な調査を行っても、エージェント B は何も知らない状態で作業を始めます。プロジェクト開始から 3 週間後に新しいエージェントが加わると、最初から説明を受けなければなりません。Event Pod はその両方を解決します。エージェントはポッドに書き込み、ポッドから読み取ります。また、新しいエージェントには、先行するエージェントたちが解決した知識を引き継がせることができます。

ほとんどのケースは、次の 3 つの連携パターンで対応できます。

• 引き継ぎ -- 次のエージェントに構造化されたコンテキストを残す
• 比較 -- 2 つのエージェントのモデルが異なる部分を明らかにし、人間が解決する
• 新しいエージェントのシード -- 既存のエージェントが解決したコンテキストを使って新しいエージェントを初期化する

自律モード -- マルチエージェントシステムプロンプト

各エージェントは、固有の agent_id を持つ独自のシステムプロンプトを実行します。エージェントは独立して構築し、引き継ぎ情報を残し、名前空間を分けて保持するため、どのエージェントが何に貢献したかを常に追跡できます。

## Event Pod -- Multi-Agent Context

You have access to Event Pod tools.
User ID: {USER_ID}
Your agent ID: {AGENT_ID}

SESSION START:
1. Call get_pod_summary for this user.
2. Call get_agent_context for your agent_id to load your
   own task history.
3. Check for handoffs from other agents:
   call get_agent_context for any upstream agent_ids
   with context_type: task_history.

DURING THE SESSION:
- Save what you learn as events on the shared pod.
- When you make a significant decision, call save_agent_context
  with context_type: decision so other agents can trace it.
- If you encounter something that contradicts another agent's
  saved context, note it -- don't silently overwrite it.
  Flag it for human review.

SESSION END:
1. Save a handoff via save_agent_context, context_type: task_history.
   Include: what you did, what you found, what you'd recommend next,
   and what you're handing off to.
2. Save any new events observed.
3. Call update_session with interactions=1 -- exactly once.

制御モード

引き継ぎ、比較、シードなど、精度が最も重要となる場面では、制御された保存を使用します。

エージェントの引き継ぎ

あるエージェントがフェーズを完了し、別のエージェントが作業を引き継ぐとき、引き継ぎ情報は構造化して保存されます。次のエージェントは作業を始める前にそれを読み取るため、再説明もコンテキストの喪失もありません。

エージェント A -- 引き継ぎ情報を保存する：

await call_pod("save_agent_context", {
    "user_id": user_id,
    "agent_id": "research-agent",
    "context_type": "task_history",
    "data": {
        "task": "Security audit -- auth module",
        "status": "complete",
        "findings": [
            "JWT secret hardcoded in config.go:42",
            "No rate limiting on /login",
            "Session tokens don't expire"
        ],
        "severity_order": ["JWT secret", "session expiry", "rate limiting"],
        "files_examined": ["auth/", "middleware/auth.go"],
        "handed_off_to": "fix-agent",
        "recommended_first": "JWT secret -- highest severity, easiest fix"
    }
})

エージェント B -- セッション開始時に引き継ぎ情報を読む：

handoff = await call_pod("get_agent_context", {
    "user_id": user_id,
    "agent_id": "research-agent",  # read from the agent that handed off
    "context_type": "task_history"
})

比較と相違点

2 つのエージェントが同じ環境について別々のモデルを構築するとき、compare_pods を使うと、両者が合意している点、相違している点、一方だけが把握している内容がわかります。相違点は、人間による判断が必要であることを示すシグナルです。

comparison = await call_pod("compare_pods", {
    "pod_a": "research-agent-pod",
    "pod_b": "fix-agent-pod",
    "signal_type": "claim"  # focus on architectural claims
})

# comparison.agreements   -- shared keys, similar values (agents agree)
# comparison.divergences  -- shared keys, different values (needs resolution)
# comparison.gaps         -- keys unique to each pod (knowledge gaps)

相違点はエラーではありません。 2 つのエージェントの意見が分かれた場合、それは人間による判断が必要だということです。UI に相違点を表示し、ユーザーがチャットで解決できるようにしてから、その解決内容を配信します。1 回の人間による判断から、すべてのエージェントが恩恵を受けます。

解決内容を配信する

人間がチャットで相違点を解決したら、採用されたコンテキストを影響を受けるすべてのエージェントに配信します。すべてのエージェントが修正済みのモデルを受け取るため、どのエージェントもそれを再発見する必要はありません。

agent_pods = ["research-agent-pod", "fix-agent-pod", "review-agent-pod"]

for pod_id in agent_pods:
    await call_pod("save_event", {
        "user_id": pod_id,
        "key": "connection-pooling-policy",
        "signal_type": "claim",
        "value": 1.0,
        "certainty": 0.95,  # high -- human confirmed
        "gloss": "Use connection pooling in all new services. Human-confirmed 2025-11.",
        "meta": {
            "resolved_by": "human",
            "date": "2025-11-15",
            "supersedes": "prior divergence between research and fix agents"
        }
    })

新しいエージェントのシード

既存のプロジェクトに新しいエージェントが加わる場合、通常はゼロから作業を始めることになり、何週間分ものコンテキストが失われます。その代わりに、先行するエージェントたちが解決した知識を使ってシードします。新しいエージェントは、最初から賢くスタートできます。

# 1. Create the new pod
await call_pod("create_pod", {
    "user_id": "devops-agent-pod",
    "name": "DevOps Agent",
    "pod_type": "intelligence"
})

# 2. Load resolved context from existing agents
research_history = await call_pod("get_agent_context", {
    "user_id": "research-agent-pod",
    "context_type": "task_history"
})
decisions = await call_pod("get_agent_context", {
    "user_id": "fix-agent-pod",
    "context_type": "decision"
})

# 3. Seed the new pod with resolved knowledge
for decision in decisions["decisions"]:
    await call_pod("save_event", {
        "user_id": "devops-agent-pod",
        "key": decision["key"],
        "signal_type": "claim",
        "value": decision["value"],
        "certainty": 0.7,  # inherit with moderate certainty -- let it validate
        "gloss": f"Inherited from prior agents: {decision['gloss']}"
    })

中程度の確信度で継承する。 継承した知識は 0.95 ではなく、約 0.7 に設定します。新しいエージェントは受け取った内容を検証する必要があります。継承したコンテキストを絶対的な真実として扱わせないでください。独自の観察を通じて、高い確信度を獲得させます。

人間によるアライメント -- マルチエージェント

マルチエージェントシステムでは、意見の相違は避けられません。異なる方法でトレーニングされ、環境の異なる部分を観察し、異なるモデル上で動作するエージェントは、それぞれ異なる世界モデルを構築します。人間の役割は、それらを調整することです。そのすべてを担うインターフェースがチャットです。

1つのセッションでエージェント間のコンテキストを取り込む：

3つのエージェントポッド、research-agent-pod、fix-agent-pod、devops-agent-pod の要約を取得してください。デプロイ戦略について、それぞれ何を把握していますか？どこで意見が食い違っていますか？

意見の相違を解決する：

research エージェントと fix エージェントは、コネクションプーリングを使うべきかどうかで意見が分かれています。research エージェントが正しいです。確認済みの決定内容と、人間が解決したことを記録して、3つすべてのポッドを更新してください。

エージェントの意思決定の経緯を監査する：

fix エージェントが行い、保存した決定をすべて表示してください。DevOps エージェントに引き継ぐ前に、その推論を確認したいです。

すべてのエージェントの好奇心を確認する：

3つすべてのエージェントポッドで、好奇心を最も強く刺激するものは何ですか？システム全体として、まだ何がわかっていませんか？

人間の1つの決定が、すべてのエージェントに役立ちます。 チャットで意見の相違を解決したら、その内容を共有してください。1回の会話で提供した組織の知識は、それを必要とするすべてのエージェントに広がります。これがアライメントループによる相乗効果です。

---

デバイスとエコシステム

ハードウェアに組み込まれたエージェントは、タスクを実行するだけではありません。物理環境の因果モデルを構築します。センサーは信号であり、状態は蓄積され、パターンが現れます。そして人間は、いつでも平易な言葉で、デバイスが学習した内容を監査、修正、拡張できます。

デバイスエージェントが行うこと： 環境を学習します。センサーの読み取り値を信号として取り込み、状態モデルを構築し、パターンを検出して、異常を自律的に通知します。

人間が行うこと： コンテキストと意図を伝えます。読み取り値が異常だった理由、状態変化の意味、デバイスが優先すべきことを伝えます。いつでもチャットするだけです。

この分野の構想は今後に向けたものです。 コアツールは現在利用できます。デバイス上での完全なデプロイ構想――組み込みハードウェア上でローカルに動作し、ポッドをエッジと同期するエージェント――は、現在開発中です。この構想を念頭に置いて構築してください。

概要

従来の IoT アーキテクチャでは、データをクラウドに送信し、判断をデバイスに返します。永続的な世界モデルを持つエージェントは、この仕組みを変えます。インテリジェンスはデバイス上にあり、モデルはローカルで蓄積され、人間はダッシュボードを照会したり SQL を記述したりせずに、自然言語でやり取りできます。

センサーの読み取り値はすべて、潜在的な信号です。状態変化はすべてイベントです。繰り返される動作はすべてパターンです。Event Pod は、デバイスエージェントが時間の経過とともに知識を蓄積し、確信度を高めながら活用するための基盤を提供します。

デバイスモデル

デバイスポッドは、デバイスが動作する物理環境をモデル化します。デバイスが何を測定するかだけでなく、その測定値が何を意味するかも扱います。

内容	信号の種類	例
センサーの基準値	metric	周囲温度の正常範囲：18--24 C
現在のデバイス状態	state	HVAC：冷房／アイドル／障害
繰り返される動作	pattern	平日の午前9時に、温度が2 C上昇する
環境に関する主張	claim	西向きの窓が開いていると、B室の空気質が悪化する
インシデントと異常	event	2025-11-03 に電力スパイクが発生、原因：不明
接続されたデバイス	entity	Sensor-node-4、gateway-main、thermostat-A

信号としてのセンサー

各センサーの読み取り値は、metric イベントとして保存できます。時間の経過とともに、ポッドは各センサーの統計的な基準値を構築し、その基準値からの逸脱自体が意味のある信号になります。

await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "ambient-temperature",
    "signal_type": "metric",
    "value": 0.74,  # normalized: 0=min, 1=max of expected range
    "certainty": 0.9,  # sensor is reliable
    "gloss": "22.1 C -- within normal range",
    "validation_type": "direct",  # sensor is ground truth
    "meta": {
        "raw_value": 22.1,
        "unit": "celsius",
        "sensor_id": "temp-sensor-4",
        "timestamp": "2025-11-15T09:00:00Z"
    }
})

センサー値を0--1に正規化します。 センサーの想定範囲を [0, 1] に対応付けます。通常18--24 Cを示す温度センサーの場合、22 Cは約0.67に対応します。これにより、ポッドは異なる種類のセンサーの信号を共通の尺度で比較できます。

状態とパターン

現在の状態：

state イベントを使用して、デバイスまたはシステムが現在どのようなモードまたは状態にあるかを追跡します。遷移が発生したらこれらを更新します。ポッドには、状態の変化の履歴が時間とともに蓄積されます。

await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "hvac-state",
    "signal_type": "state",
    "value": 0.8,  # 0=off, 0.5=idle, 1=active/fault
    "certainty": 0.95,
    "gloss": "HVAC: cooling mode, running normally",
    "meta": { "mode": "cooling", "set_point": 21 }
})

パターン：

エージェントが、複数の観察を通じて確認された繰り返しの動作を検出したら、それを pattern イベントとして保存します。パターンによって、エージェントは事前に予測し、先回りして行動できます。

await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "morning-temp-spike",
    "signal_type": "pattern",
    "value": 0.75,  # strength of pattern
    "certainty": 0.65,  # still building confidence
    "gloss": "Temperature rises ~2 C on weekday mornings around 9am. Likely occupancy-driven.",
    "meta": {
        "observed_n": 12,
        "hypothesis": "office occupancy",
        "suggested_action": "Pre-cool to 20 C by 8:45am on weekdays"
    }
})

異常検知

センサーの読み取り値が確立されたベースラインから大きく逸脱した場合、原因不明として確信度の低い event として保存し、好奇心トリガーを通じて人間による確認を促します。

# Sensor read 31 C -- well outside normal 18--24 C range
await call_tool("save_event", {
    "user_id": "device-pod-floor2",
    "key": "temp-anomaly-2025-11-15",
    "signal_type": "event",
    "value": 1.0,
    "certainty": 0.2,  # cause uncertain -- needs human input
    "gloss": "Temperature spike to 31 C at 14:22 UTC. No known cause. HVAC was in cooling mode.",
    "meta": {
        "raw_value": 31.0,
        "expected_range": [18, 24],
        "hvac_state": "cooling",
        "flagged_for_review": True
    }
})

人間との調整――デバイス

デバイスは物理的な現実を観察しますが、センサーでは把握できない意図、背景、因果関係を提供するのは人間です。なぜ窓が開いたままだったのでしょうか。この急上昇はテストだったのでしょうか、それとも故障でしょうか。優先事項が衝突した場合、デバイスは何を優先すべきでしょうか。

異常の説明：

15日のあの気温上昇は、Room Bで私たちが熱テストを実施したためです。ポッドを更新して原因を記録し、想定内としてマークしてください。

環境の背景情報の追加：

西向きのセンサーは、午後の日差しが当たると常に1～2 C高く表示されることを、2階のポッドに保存してください。これは構造上の特性であり、異常ではありません。

デバイスの意図の設定：

平日の午前8時から午後6時までは、2階のエージェントが温度の快適さより空気の質を優先するようにしてください。これを設定として保存してください。

エコシステムの背景情報

デバイスは単独で動作するわけではありません。link_events を使用して、デバイスのエコシステム全体にわたる関連シグナルを結び付けます。たとえば、温度異常と電力の急上昇、状態の変化と既知のパターンを関連付けます。

await call_tool("link_events", {
    "user_id": "device-pod-floor2",
    "source_key": "temp-anomaly-2025-11-15",
    "source_signal_type": "event",
    "target_key": "power-spike-2025-11-15",
    "target_signal_type": "event",
    "relationship": "RELATED_TO",
    "note": "Both anomalies occurred within 2 minutes. Possible causal link."
})

デバイスレーンで使用するシグナルの種類

シグナル	使用例
metric	センサーの読み取り値、環境測定値
state	デバイスのモード、稼働状況、フェーズ
pattern	繰り返しの動作、環境サイクル
event	異常、インシデント、状態遷移
claim	環境のルール、構造上の制約
entity	センサー、ゲートウェイ、接続されたデバイス
preference	デバイスの優先事項、人間が設定した意図

---

リファレンス全文

ツール一覧、シグナルの種類、データモデル、統合に関する完全なリファレンスです。すべてのレーンで共通です。

シグナルの種類

すべてのイベントには、そのイベントが表す知識の種類を分類する signal_type があります。8種類で、あらゆる範囲をカバーします。

種類	表す内容	値の意味	レーン
competence	ドメインにおけるスキルまたは知識のレベル	0 = 初心者、1 = エキスパート	Chat、Agent、Coding
preference	コミュニケーションまたは行動の設定	0 = 低／オフ、1 = 高／オン	Chat、Agent、Coding、Devices
claim	追跡対象の命題または信念	0 = 偽／否定、1 = 真／肯定	Agent、Coding、Workflow、Multi-agent
entity	名前付きエンティティ――人物、組織、ツール、デバイス	0 = 非アクティブ、1 = アクティブ／関連あり	すべてのレーン
event	インシデント、マイルストーン、決定、異常	0 = 軽微、1 = 重大	Coding、Workflow、Devices
metric	測定可能な量	想定範囲内で0～1に正規化	Coding、Workflow、Devices
pattern	繰り返しの動作または傾向	0 = 弱い、1 = 強いパターン	Chat、Coding、Workflow、Devices
state	現在の状態または稼働フェーズ	コンテキストに依存（glossに記載）	Workflow、Multi-agent、Devices

確信度と学習

すべてのイベントには、0 から 1 までのcertaintyスコアが付与されます。これは、このシグナルについてモデルが把握している内容にどの程度の確信を持っているかを表します。

確信度の範囲	意味	動作
0.0 -- 0.3	低 — 新しい、または裏付けが弱い	素早く更新し、見直しに柔軟に対応します
0.3 -- 0.6	中 — 確信を深めている段階	中程度の速さで更新します
0.6 -- 0.8	高 — 十分な裏付けがある	ノイズに影響されにくく、強いシグナルがあれば更新します
0.8 -- 1.0	非常に高 — 確固として確立されている	非常に安定しており、大きな矛盾がある場合にのみ変化します

新しい観察は 0.3 から開始し、時間をかけて学習によって精度を高めていきます。システムは把握できていない部分では柔軟に、確信のある部分では安定しており、学習率は現在の確信度に応じて自動的に調整されます。

検証タイプ

タイプ	使用する状況
direct	センサーまたはデータソースが客観的な正解値を提供する場合（予測値と実際の値を比較して誤差を計算します）
logic	外部センサーがない場合 — 誤差の大きさは、裏付け、矛盾、具体性に基づいて判断します

誤差の大きさの目安（apply_learning用）

シグナルタイプ	大きさ	方向
独立した裏付け	0.05 -- 0.1	増加
同一ソースでの繰り返し	0.02 -- 0.05	増加
具体性の向上	0.1 -- 0.15	増加
時間経過による確認	~0.1	増加
矛盾	0.2 -- 0.4	減少

読み取りツール

ツール	目的	主なパラメーター
get_pod_summary	用語解説と鮮度情報を含む、主要なシグナルの簡潔で読みやすい概要	user_id、include_glosses、include_freshness
get_pod	すべてのイベントを含むポッドの全状態	user_id、include_vectors、include_curiosity
get_events	すべてのイベントを取得します。必要に応じてsignal_typeで絞り込めます	user_id、signal_type、validation_type
get_relevant_context	タスクに最も関連するイベント — 一致度と確信度に基づいてスコア付け	user_id、query、max_results
query_pod	すべてのイベントを対象にした自然言語での質問	user_id、query
get_low_certainty	確信度のしきい値を下回るイベント — 検証候補として最適	user_id、threshold
get_curiosity_triggers	検証が必要なイベント、古くなったイベント、または観察が不足しているイベント	user_id、max_triggers、include_probes
get_gap_analysis	調査の優先度順に並べた、価値が高く確信度の低いシグナル	user_id、max_gaps
get_convergence_report	前回のレポート以降の新しいイベント、確信度の変化、古くなったシグナル	user_id、since_days

書き込みツール

ツール	目的	主なパラメーター
create_pod	ユーザーまたはエンティティの新しいポッドを初期化します	user_id、name、pod_type
save_event	イベントを保存または更新します	user_id、key、signal_type、value、certainty、gloss、meta
record_observation	生の行動シグナル（修正、エンゲージメントなど）を記録します	user_id、session_id、signal_type、signal_data
apply_learning	観察に基づいてイベントの値と確信度を更新します	user_id、key、signal_type、error_direction、error_magnitude
update_session	セッション数とインタラクション数を増やします — 終了時に1回呼び出します	user_id、interactions
delete_event	キーを指定して特定のイベントを削除します	user_id、key、signal_type
delete_pod	ポッドとすべてのデータを完全に削除します — 元に戻せません	user_id、confirm: true

グラフツール

ツール	目的	主なパラメーター
link_events	2 つのイベント間に意味的な関係を作成します	user_id、source_key、target_key、relationship、note
get_event_cluster	イベントからリンクをたどって幅優先探索（BFS）を行います	user_id、key、signal_type、max_depth
suggest_links	キーワードの重複に基づいて関係を自動提案します	user_id、min_overlap
detect_contradictions	確実性の高いイベント間の矛盾を明らかにします	user_id、certainty_threshold
suggest_synthesis	統合できる確実性の高いイベントを見つけます	user_id、min_certainty、min_overlap
export_cluster_diagram	イベントの関係を Mermaid 図として出力します	user_id、center_event、include_all
export_argument_outline	リンクされたイベントから階層型の Markdown アウトラインを作成します	user_id、topic、include_evidence
get_argument_chain	主張やトピックの論理的な依存関係をたどります	user_id、topic、max_depth

拡張コンテキストツール

ツール	目的
save_agent_context / get_agent_context	エージェントごとのタスク履歴、決定、エラーを保存・取得します（agent_id 単位）
save_repo_context / get_repo_context	リポジトリごとに名前空間を分けて、セッション間でコードベースのメタデータを保存・取得します
save_service_context / get_service_context	外部サービスの健全性とステータスのデータを保存・取得します
save_life_context / get_life_context	ユーザーが共有した生活パターン（健康、目標、日課、スケジュール）を保存・取得します
link_resource / get_resources / unlink_resource	イベントに関連付けられたファイル、URL、プロジェクトを紐付け・取得・解除します
add_source	インテリジェンスパイプラインのポッド用に、信頼性スコア付きのデータソースを登録します
export_pod	ポッドの全データを JSON としてエクスポートします（GDPR 第 20 条）
compare_pods	2 つのポッド間のイベントを比較します――一致点、相違点、欠落点
get_learning_rate	イベントの確実性に基づいて、現在の学習率を表示します

関係の種類

関係	意味	例
BUILDS_ON	A は B を基盤としています	react BUILDS_ON javascript
ENABLES	A によって B が可能になります	python ENABLES data-science
RELATED_TO	テーマ上のつながり	hiking RELATED_TO photography
CONTRADICTS	A は B と矛盾します	minimalism CONTRADICTS feature-creep
PART_OF	A は B のサブセットです	flask PART_OF python-web
EVOLVES_FROM	A は B から発展しました	microservices EVOLVES_FROM monolith
SUPERSEDES	A は B に取って代わります	v2-api SUPERSEDES v1-api

イベントスキーマ

すべてのイベントは、シグナルの種類にかかわらず共通のスキーマを共有します。

{
  "user_id":          "string",          // pod identifier -- required
  "key":              "string",          // signal key -- required
  "signal_type":      "competence|preference|claim|entity|event|metric|pattern|state",
  "value":            0.0-1.0,           // signal strength -- required
  "certainty":        0.0-1.0,           // model confidence -- default 0.3
  "gloss":            "string",          // human-readable interpretation
  "validation_type":  "direct|logic",    // how error signals are produced
  "meta":             {},                // arbitrary structured metadata
  "source_id":        "string",          // source identifier (intelligence pods)
  "source_type":      "api|sensor|document|..."
}

MCP 設定

Event Pod はリモート MCP サーバーです。クライアントのコネクター UI または設定ファイルから追加してください。

claude_desktop_config.json / .cursor/mcp.json:

{
  "mcpServers": {
    "event-pod": {
      "url": "https://context.nervousmachine.com/mcp",
      "transport": "sse"
    }
  }
}

Event Pod はリモート MCP サーバーのため、ほとんどのクライアントでは設定ファイルを直接編集せずに、UI から追加できます。クライアントの「Add Integration」または「MCP Connectors」セクションを確認してください。

curl の例

ポッドを作成する：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"create_pod","arguments":{"user_id":"alice","name":"Alice"}}}'

イベントを保存する：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"save_event","arguments":{"user_id":"alice","key":"python","signal_type":"competence","value":0.8,"certainty":0.3,"gloss":"Strong Python developer"}}}'

ポッドの概要を取得する：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"get_pod_summary","arguments":{"user_id":"alice","include_glosses":true}}}'

学習を適用する：

curl -X POST https://context.nervousmachine.com/mcp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"tools/call","params":{"name":"apply_learning","arguments":{"user_id":"alice","key":"python","signal_type":"competence","error_direction":"increase","error_magnitude":0.1}}}'

プライバシーとデータに関する権利

Event Pod は生データではなく、学習した抽象表現を保存します。ポッドに含まれるのは、やり取りからモデルが学習した内容であり、会話の記録やファイル、明示的に保存したもの以外の個人情報は含まれません。

権利	ツール	備考
データをエクスポートする	export_pod	ポッド全体を JSON 形式で返します。GDPR 第 20 条に準拠しています。
データを削除する	delete_pod	完全かつ取り消し不能です。confirm: true が必要です。GDPR 第 17 条に準拠しています。
保存内容を確認する	get_pod_summary、get_events	いつでもすべてのイベントと確信度スコアを完全に確認できます。
保存された知識を訂正する	save_event、apply_learning、delete_event	どのイベントも、自然言語で更新、訂正、削除できます。

保存するのはベクトルであり、会話の記録ではありません。 Python が得意で、率直なフィードバックを好むことを覚えている同僚のようなものだと考えてください。会話の記録を持っているのではなく、あなたのことを知っているだけです。ポッドが保存するのも同じです。

---

Event Pod by Nervous Machine -- エージェント向けに構築。私たちはみんな、想定外のケースです。