MCPでローカル作業履歴をAIエージェントに渡すには
MCPを使ってClaude Code、Codex、Cursorへ調査履歴や作業履歴を渡す考え方を整理します。Stack Overflow、GitHub Issue、公式ドキュメントを読んだ流れまで含めるユースケースです。
MCPは記憶の出口になる
MCPは、Claude Code、Codex、Cursor、Claude Desktopのような対応クライアントから、外部の作業メモリを読めるようにする出口になります。Contextbergでは、PC上の作業履歴、ブラウザ履歴、エージェント会話履歴をローカルに保持し、必要な範囲だけをMCP経由で渡します。
AIエージェント向けのメモリを作るとき、最も重要なのは保存形式よりも出口です。どれだけ良い記憶を作っても、Claude Desktop、Claude Code、Cursor、Codexから読めなければ、実作業では使いにくいままです。
Contextbergでは、記憶をアプリ内に閉じず、MCPで外に出すことを前提にしています。エージェントごとに専用連携を作るのではなく、MCPクライアントが読める共通の入口を用意します。
ローカルHTTPサーバーとMCPプロキシ
アプリ本体はローカルHTTPサーバーを立てます。そこに薄いMCPプロキシを重ねることで、MCPクライアントからContextbergの記憶を読めるようにします。
この構成にした理由は、デスクトップアプリ本体とMCPサーバー側の配布を分けやすいからです。アプリはローカルDBやスクリーンショット、ブラウザ履歴を安全に扱い、MCPプロキシはエージェントとのプロトコル境界に集中できます。
提供するツール
代表的なツールは、直近のActivityを返すget_activity、指定日の記憶を返すget_daily_memory、週次のまとめを返すget_weekly_memory、エージェント会話履歴を横断検索するget_agent_history、長期メモリを読むread_ltm、長期メモリへ追記するupdate_ltmです。
短期の復帰にはget_activity、日次の振り返りにはget_daily_memory、恒常的な前提の注入にはread_ltmを使う、という役割分担にしています。
生ログをそのまま出さない
MCPで読めるからといって、生のスクリーンショットやキーストロークを常に丸ごと渡す設計にはしていません。必要な粒度に整えたActivityやReportを返すことで、エージェントが扱いやすい文脈にします。
ただし、作業の根拠が必要な場面では、ブラウザ履歴やエージェント会話履歴も含めて参照できるようにします。『何をしたか』だけでなく『なぜその判断に至ったか』を取り戻すためです。
接続の摩擦を下げる
MCPは便利ですが、設定ファイルの編集でつまずくユーザーもいます。Contextbergでは、Claude Desktop向けに設定ブロックを自動追記するボタンを用意しています。
理想は、ユーザーがプロトコルを意識しなくても、エージェントが自然に作業文脈を読める状態です。MCPはそのための見えない配管として扱いたいと考えています。
調査履歴を渡すと何が変わるか
調査履歴を渡す価値は、URLを保存すること自体ではありません。どの順番で何を読み、どの情報を根拠に実装方針を変えたかを、エージェントが辿れることです。
| 場面 | 渡したい文脈 | エージェントに期待する動き |
|---|---|---|
| 公式docを読んだ後 | 読んだページ、該当API、バージョン、制約 | 仕様に沿って実装案を絞る |
| GitHub Issueを追った後 | 関連Issue、未解決か解決済みか、回避策 | 既知のバグや罠を避ける |
| Stack Overflowを読んだ後 | 採用した回答、捨てた回答、その理由 | 古い回答や危ないワークアラウンドを見分ける |
| ログを見た後 | エラー発生時刻、直前の操作、再現条件 | 原因候補を優先順位づける |
| 複数案で迷った後 | 比較した案、捨てた案、判断基準 | 同じ議論を繰り返さず次の実装へ進む |
調査後に聞くプロンプト
直近2時間で読んでいた公式doc、GitHub Issue、Stack Overflowを整理して。
そのうえで、今の実装方針に関係する根拠と、無視してよさそうな情報を分けて。
最後に、この方針で実装する場合のリスクを3つ挙げて。この質問は、調査履歴を単なるブックマークではなく、実装判断の材料に変えるためのものです。Contextbergではbrowser historyを単独の機能として見せるだけでなく、ActivityやDaily Reportの中で作業文脈として扱う方が自然です。