自分専用 Context Engine の作り方 — MCPで全AIに同じ"自分"を渡す

毎回同じ自己紹介をAIにしているのを、やめたかった

Claude / ChatGPT / Gemini / Claude Code を行き来していると、毎回似たような前置きを打っていることに気付きます。 「自分は saka2jp、PeopleX所属でAI面接プロダクトに関わっている。技術ブログを書いていて、応答は日本語・結論先出しで、Prisma upsertは禁止…」。 AI別にプロフィールを書き直し、ChatGPTで決めた方針がClaudeで失われ、Claude Codeのセッションを跨ぐと「今何のプロジェクトに取り組んでるか」を毎回最初から説明する。 この「文脈の再説明コスト」と「AI間の文脈分断」は、生産性のボトルネックである以前に、たぶん5年後の自分への裏切りなんですよね（積み上がるはずだったデジタル資産が、各プラットフォームの会話履歴に閉じ込められて散逸する）。

そこで連休を使って、AIプラットフォーム非依存な"自分専用Context Engine" を ~/context-engine/ に建てました。 ゴールは1つ — あらゆるAIが同じMCPサーバーを叩き、同じ「自分像」と「現在の状況」と「過去の学び」にアクセスできる状態を作る。 この記事ではその設計と実装、運用してみての学びをまとめます。

設計が満たすべき4条件

作る前に「これを満たさないと意味がない」という条件を4つ言語化しました。実装の途中で迷ったらこの4条件に戻る、というアンカーです。

どれも「言われてみればそう」ですが、特に2つ目（ローカルAIによる整理）と4つ目（プレーンテキストSSoT）は、SaaS型メモリサービスを採用すると同時に放棄せざるを得ない条件です。ここで 「自前で組む」 以外の解が消えました。

「文脈」を3層に解体する

最初に書いた設計書では「context」「文脈」「メモリ」「プロフィール」が3つの異なる意味で混在していました。grilling sessionで自分の語彙を炙り出した結果、 取り出され方が違うなら、層を分けるべき という結論に到達。最終的に以下の3層に明示分離しました。

このレイヤリングが効くのは、 同じ「自分に関する情報」でも、AIに渡すロジックがまったく違う からです。 「あなたは誰？」には Identity を全部渡す。「今何やってる？」には Project State の active 上位を返す。「Mem0のベンチマーク覚えてる？」には Knowledge を意味類似で検索する。 ここを1つのテーブル/コレクションに混ぜると、結局AI側で「全部読んでから関係するやつだけ使って」という地獄になります。

3-Vault × 3層マトリクス

3層に 3-Vault スコープ境界（personal / work / public）を直交させます。 漏洩経路を物理ディレクトリで分けつつ、Identity だけは「投影」で全scopeに到達させる構造です。

flowchart LR
    subgraph Canonical[personal/identity/canonical.md]
      C1[★ 唯一のIdentity SSoT<br/>visibilityで投影先を制御]
    end
    subgraph Personal[vault/personal/]
      P1[projects/]
      P2[knowledge/]
      P3[inbox/]
    end
    subgraph Work[vault/work/]
      W1[projects/]
      W2[knowledge/]
      W3[people/]
    end
    subgraph Public[vault/public/]
      U1[projects/]
      U2[knowledge/]
      U3[identity/_profile.md<br/>※投影出力 / SSoTではない]
    end
    C1 -- projection --> P1
    C1 -- projection --> W1
    C1 -- projection --> U3
    style C1 fill:#1e293b,stroke:#3b82f6,color:#ededed

Vault分離の境界は、リポジトリではなく MCPサーバーのscope強制 で担保します。 CWDから自動推定（~/peoplex/* → work、~/saka2jp/saka2blog → public、それ以外の ~/saka2jp/* → personal）し、外部からのBearer Tokenは事前にscopeが紐付いているため、 設定ミスで越境することが構造的に起こり得ない ようになっています。

Conversation Bookend — 会話の両端で読み書きする

Context Engine の中身ができても、「人間が忘れずに参照・更新する」運用は破綻します。 そこで 会話の両端でContext Engineと往復する パターンを採用しました。Claude Code なら hooks で完全自動化できます。

sequenceDiagram
    participant U as ユーザー
    participant CC as Claude Code
    participant CE as Context Engine MCP
    participant OL as Ollama (local)
    U->>CC: セッション開始
    CC->>CE: [READ] query_self(cwd, scope=auto)
    CE-->>CC: identityCard / currentProjects / relevantKnowledge
    CC->>U: 文脈注入済みで応答開始
    Note over U,CC: 通常の対話
    U->>CC: セッション終了 (Stop)
    CC->>OL: トランスクリプトを渡す
    OL-->>CC: 5カテゴリ抽出 (JSON)
    loop 各 insight
      CC->>CE: [WRITE] save_insight(category, content, confidence)
    end
    CE-->>CC: 振り分け完了 (vault配下に保存)

Claude Code の ~/.claude/settings.json はこんな具合:

{
  "hooks": {
    "SessionStart": [{
      "command": "context-engine-cli inject-context",
      "description": "CWD / 直近編集ファイル / git log から3層文脈を自動注入"
    }],
    "Stop": [{
      "command": "context-engine-cli save-from-transcript",
      "description": "Ollamaに渡し、5カテゴリ抽出 → save_insight"
    }]
  }
}

これで「人間が忘れる」リスクが消えます。Claude.ai / ChatGPT は hooks 相当が無いので、Custom Instructions に「会話開始時に必ず query_self を呼ぶこと」を書き、Bearer Token認証付きのCloudflare TunnelでMCPに繋ぎます。 Gemini はMCP未対応なので、Bookend READ は諦めて月次のGoogle TakeoutでWRITE側だけ救済する、という割り切りにしました。

Hybrid Retrieval — BM25 × Vector × RRF

Knowledge層の検索が貧弱だと、上の構造はすべて無駄になります。 「Prisma upsert禁止」をキーワード検索で当てるのと、「上司との関わり」を意味類似で「砂田さんノート」に当てるのを、 1つのクエリで両立 する必要がありました。

チャンキング単位は H2ヘッダ境界 固定。frontmatterは除外し、embedding入力は passage: {docTitle} > {heading}\n{body} という形に正規化します（E5系モデルの推奨形式）。 FTS5 と vec0 仮想テーブルで 同じ rowid を共有 させているのが地味に効いていて、joinが1回で済むのでRRFの統合コストがほぼゼロです。

日本語の形態素解析は 意図的に入れていません。MeCabやSudachiを導入するとモデル配布のサイズが2倍になり、コンテナビルドも遅くなる。代わりに、 助詞・敬称（さん / について / は / を / が / の 等）でBM25クエリを軽量分割してOR検索 + Vectorの意味マッチで補完、という構成にしました。実測で十分なリコールが出ています。

# CLI から直接叩いた例（Hybridのスコアとランク表示込み）
$ pnpm query "上司との関わり" --scope=work

=== relevantKnowledge (2) ===
- [0.0328] (bm25 #N/A, vec #1) vault/work people — 砂田 滋弘 > マネジメント観
  /Users/jumpeisakatsu/context-engine/vault/work/people/砂田-滋弘.md
- [0.0312] (bm25 #2, vec #5) vault/work knowledge/value — 上司からのフィードバック...

searchMs: 14ms

ベンチマーク（M3 Pro 36GB）— 456 chunks（vault + saka2blog + zenn-contents込み）の初回index構築は約60秒、Embedder warmup後の検索latencyは warm 8〜18ms。 目標として置いた「query_self全体 100ms以内」は十分達成できています。

5カテゴリ Insight ルーティング

WRITE側の難しさは「LLMが自由作文すると、結局ノイズと幻覚が蓄積される」点にあります。 Bookend WRITE では Ollamaに固定5カテゴリの抽出だけを許可し、保存先・保存後のtypeも完全に決め打ちにしました。

もう1つ重要なのが confidence 2値（raw / validated）。Ollamaに「明言された確定情報なら validated、文脈推測・伝聞は raw」と指示します。

これにより週末レビューの対象は raw のみ に絞られ、量が manageable になります。 raw → validated 昇格は人間レビュー必須、AI単独では不可。当初設計では raw / validated / inferred の3値でしたが、運用区別が薄かったので2値に簡素化しました。「推論」「伝聞」は raw + tags: [他者情報] で表現します。

クロスAI接続 — 同じMCPを4種類のクライアントから叩く

最終的に以下の構成で4種類のAIから同じContext Engineに到達できるようになりました。

Cloudflare Tunnel経由のエンドポイントは Bearer Token必須で、 クライアント別にトークンを発行 しています（claude-web, chatgpt-gpt など）。 これで監査ログがクライアント単位で取れるし、片方のトークンが漏れても他方を生かしたままrotateできる。 ChatGPT向けには OpenAPI 3.1 spec を /openapi.json で配信し、Custom GPT の Actions タブから取り込むだけで query_self / save_insight が呼べる状態にしました。

7週間でここまでやった

あえて踏まなかった選択

この手のプロジェクトは「全部やれそう」に見えて泥沼にハマるので、 スコープ外 をドキュメントに明示しています。

• X (Twitter) の取り込み — 凍結リスク + 本人意向で不採用
• Mac全体のローカルファイル取り込み — 範囲過大、当面 saka2blog と zenn-contents の2リポに限定
• Apple Notes / Mail / Calendar / Messages / ブラウザ履歴 — プライバシー境界と運用負荷
• Screenpipe / Pieces のような継続記録系 — 当面不採用、将来再検討
• 純Vector検索のみ — キーワード弱、固有名詞のリコールが落ちる
• OpenAI Embeddings API — API課金 + 機密データ送信、ローカル実行（multilingual-e5-small）で代替
• Notion / Obsidian Sync を SSoT にする案 — プロプライエタリ依存、5年後の乗換可能性が落ちる

理解度チェッククイズ