調査履歴ごとAIエージェントに渡して実装相談する

AIエージェント向けのメモリを作るとき、最も重要なのは保存形式よりも出口です。どれだけ良い記憶を作っても、Claude Desktop、Claude Code、Cursor、Codexから読めなければ、実作業では使いにくいままです。

Contextbergでは、記憶をアプリ内に閉じず、MCPで外に出すことを前提にしています。エージェントごとに専用連携を作るのではなく、MCPクライアントが読める共通の入口を用意します。

アプリ本体はWindows上のWPFプロセスとして動き、ローカルHTTPサーバーを立てます。そこに薄いMCPプロキシを重ねることで、MCPクライアントからContextbergの記憶を読めるようにします。

この構成にした理由は、WPFアプリ側の実装と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はそのための見えない配管として扱いたいと考えています。