Claude Code / Codex / Cursor をつなぐ、AIエージェントのためのローカルメモリアプリ
Contextbergを作った背景、5つの記録シグナル、MCP連携、3種類のメモリ、プライバシー設計、Windowsネイティブにした理由をまとめます。

Contextbergとは
Contextbergは、Windows上で動くAIエージェント向けのローカルメモリアプリです。Microsoft Storeで配布しており、PCのバックグラウンドで静かに動作します。
スクリーンショット、ブラウザ履歴、キーストローク、アプリ・ウィンドウ利用状況、AIエージェントとの会話履歴という5つのシグナルを記録し、そこから作業メモリを生成します。
生成されたメモリはMCP経由でClaude Code、Codex、Cursor、GitHub Copilot、OpenClaw、LM StudioなどのMCP対応エージェントに渡せます。金曜日にデバッグ途中でPCを閉じ、月曜日に開いたとき、エージェントが前回の続きから理解できる状態を目指しています。
なぜ作ったのか
最近の開発では、複数のAIエージェントを並行して使うことが増えました。設計相談はClaude Code、レビューや差分確認はCodex、編集支援はCursor、ターミナルではGitHub Copilot、というように役割が分かれます。
問題は、それぞれのエージェントがお互いの会話を見ていないことです。さらに、意思決定の多くはエージェントを開く前に起きています。Stack Overflowを読む、GitHub Issuesを眺める、別アプリにメモを書く、VS Codeでしばらく考える。そうした前段の思考は、チャット履歴には残りません。
結果として、毎回セッションの最初に自分の状況を説明し直すことになります。月曜の夜に30分調べて方針を決めても、火曜の朝にClaude Codeを開くと、その調査も決定も見えていません。ここを解決したくてContextbergを作りました。
既存ツールで足りなかったこと
似た方向のツールはいくつか試しました。ただ、オープンソースのものはローカルビルドが必要だったり、簡単に使えるものはSaaS課金が前提だったり、常駐プロセスが重かったりしました。
また、AIネイティブというよりチャット履歴ビューアに近いものも多く、蓄積した記憶を他のエージェントへ流す出口が弱いと感じました。MCPやエクスポート経路がないと、記憶はアプリ内に閉じ込められます。
そしてWindows対応が薄いことも大きな問題でした。Windows開発者や企業PCのユーザーにも、エージェントに作業記憶を渡す体験を届けるには、ビルド不要、サインアップだけ、軽量、MCP前提のWindowsネイティブアプリが必要だと判断しました。
5つの記録シグナル
Contextbergの設計の出発点は、エージェント会話履歴だけでは作業メモリとして足りない、という判断でした。チャットログには最終的な判断は残りますが、そこに至るまでに読んだページ、見ていた画面、触っていたファイル、詰まっていた時間は残りません。
そこで、Contextbergはアプリ・ウィンドウ利用状況、ブラウザ履歴、スクリーンショット、キーストローク、エージェント会話履歴の5種類を1つのタイムラインに統合します。
アプリ利用状況は、どのプロセスやウィンドウにどれだけ滞在したかを記録します。ブラウザ履歴はChromeとEdgeのHistory SQLiteからURLとタイトルを取り込みます。スクリーンショットはアクティブウィンドウをPNGとして残します。キーストロークはアプリごとの入力履歴として保存します。エージェント会話履歴はClaude Code、Codex、Cursor、ターミナルなどのやり取りを取り込みます。
重要なのは、これらを単独で見るのではなく、まとめて扱うことです。会話履歴だけなら何を決めたかは分かります。ブラウザ、画面、入力、アプリ利用まで含めると、なぜその判断になったのかまで推測できるようになります。
RecordタブとMemoryタブ
バックグラウンドで記録し、MCPで渡すだけでは不十分です。ユーザーは何が記録されているのかを見られなければ、安心して使えません。
Recordタブでは、フォアグラウンドアプリの切り替え、直近のスクリーンショット、取り込まれたブラウザ履歴、日次の利用グラフを確認できます。記録されていることを隠すのではなく、見える形にすることで、不安を信頼に変える設計にしています。
Memoryタブでは、短期メモリと長期メモリを確認できます。LTMは手動編集も可能です。AIが誤って推測した内容を削除したり、自分の好みや作業方針を追記したりできます。Hourly Reportからチャットに入り、特定の判断を深掘りすることもできます。
3種類のメモリ
Contextbergには、Activity、Hourly Report、Long-Term Memoryの3種類のメモリがあります。これは低レイヤーから高レイヤーへ単純に圧縮していくパイプラインではなく、用途の違うメモリを並列に持つ設計です。
Activityは15分ごとに更新される、直近の作業を把握するためのメモリです。何をしていたかを素早く戻す用途に向いています。
Hourly Reportは1時間単位の自然言語サマリーです。午前中に何をしたか、一日のレビューで何を見るべきか、といった用途に向いています。
Long-Term Memoryは1日単位で更新される、継続的に残すべき情報です。役割、好み、進行中のプロジェクト、よく使うツール、作業パターンなどを保持し、エージェントに事前注入する文脈として使います。
各メモリは、スクリーンショット、キーストローク、エージェント会話、ブラウザ履歴、アプリ利用を束ねてLLMに渡すことで生成されます。たとえば、VS Codeで特定ファイルを触り、EdgeでGitHub IssueとStack Overflowを読み、Claude Codeで方針を決め、最後にgit commitした、という一連の流れが1つの作業文脈になります。
プライバシー設計
Contextbergは、画面、ブラウザ履歴、キーストローク、アプリ利用、会話履歴を広く扱います。入力を狭めればプライバシー上は安心に見えますが、メモリとしての価値は直接落ちます。
そのため、現在の設計では線引きを別の場所に置いています。デバイス上では広く記録し、クラウド側には保持しない。これがContextbergの基本方針です。
ローカルにはスクリーンショット、キーストロークログ、ブラウザ履歴キャッシュ、アプリ利用ログ、エージェント会話履歴、DPAPIで暗号化した認証トークンを保存します。ブラウザのフォーム入力、Cookie、タブ本文そのものは読みません。
AI生成にクラウドモデルを使う場合、ローカル記録から整形したプロンプトがBFF Lambda経由でVertex AI Geminiに送られます。そこにはスクリーンショット画像、キーストローク、ブラウザ履歴、アプリ利用、会話履歴が含まれます。ただし、クラウド側に長期保存はしません。生成されたテキストだけがクライアントへ戻り、ローカルに保存されます。
クラウドを完全に避けたい場合は、LM Studioに切り替えられます。OpenAI互換エンドポイントを設定すれば、Hourly ReportやLTM生成もローカルLLMで完結します。
記録したくないものを除外する
記録したくない情報については、複数の粒度で除外できます。パスワードマネージャー、銀行アプリ、特定のメッセージアプリなどをアプリ単位で除外できます。
ウィンドウタイトルやURLパターンによる除外、時間帯による除外、スクリーンショットだけ無効化、キーストロークだけ無効化といったシグナル単位の設定も用意しています。今すぐ止めたいときはRecord pauseボタンで即座に停止できます。
除外されたものはActivity層に入りません。つまり、Hourly Report、LTM、MCPレスポンスにも流れません。ただし、現時点では除外設定はユーザーが事前に指定する必要があります。パスワードマネージャーや銀行アプリの自動検出、スクリーンショット内PIIのマスキング、録画中バナーの強化は今後のロードマップです。
Windowsネイティブにした理由
常時起動で画面、ブラウザ、キーボードを扱うアプリでは、メモリとCPU使用率が重要です。Contextbergでは、アイドル時メモリ120から180MB、アクティブ時およそ250MB、アイドルCPU 1%未満、MSIXサイズ約100MBを目安にしています。
ElectronやTauriではなくWPFを選んだ理由は3つあります。まず、Electron常駐アプリは起動直後から300から500MB程度になりやすく、200MB未満のラインを守りにくいこと。次に、キーボードフック、フォアグラウンドウィンドウ取得、スクリーンキャプチャ、DPAPI、MSIXパッケージIDなど、Win32 APIへの直接アクセスが多いこと。最後に、Microsoft Store配布を前提にしたとき、WPF + .NET 8 + Windows App SDKが最も素直だったことです。
トレードオフとしてmacOSやLinuxは別コードベースになります。それでも、最初のユーザーにとっては、重いクロスプラットフォームアプリより、軽いWindows専用アプリの方が価値が高いと判断しました。
MCPでエージェントにつなぐ
ContextbergはWPFプロセス内でローカルHTTPサーバーを動かし、その前段に薄いMCPプロキシを置いています。Claude DesktopやCursorなどのMCPクライアントには、contextberg用のMCPサーバー設定を追加します。アプリ内のConnect Claude Desktopボタンでは、この設定ブロックを自動で追記できます。
公開するツールには、直近N時間のActivityを返すget_activity、指定日のDaily Reportを返すget_daily_memory、週次レポートを返すget_weekly_memory、Claude CodeやCursorやCodexの横断会話を返すget_agent_history、LTM全文を読むread_ltm、LTMセクションへ差分を追記するupdate_ltmがあります。
たとえばClaude Desktopで『金曜にやっていたauth refactorはどこまで進んだ?』と聞くと、エージェントは会話履歴だけでなく、ブラウザ履歴やHourly Reportも参照できます。Stack Overflowを読んでいたことは会話履歴には残っていませんが、Contextbergには残っています。ここが会話履歴だけのツールとの違いです。
FreeとLiteの境界
Contextbergでは、MCP、3層メモリ、LM Studioによる完全ローカル運用をFreeに含めています。エージェントに記憶を渡すという中核体験を課金壁の向こうに置くと、個人開発者や学生が価値を体験できません。
Liteは、クラウドGeminiの利用枠拡張、プレミアムモデル、長期保持などを必要とするユーザー向けです。まずFreeで価値を感じてもらい、より大きなクラウドAI枠や保持期間が必要になったらLiteを選べる設計にしています。
誰のためのものか
Contextbergは、Claude Code、Codex、Cursor、GitHub Copilotを日常的に使う開発者に向いています。複数のエージェントを使い分けるほど、記憶の断絶は痛くなります。
また、毎朝『どこまでやっていたっけ』を説明し直すことに疲れている人、セッションをまたいで素早く復帰したい人、クラウドにデータを出さずにAIの恩恵を受けたい人にも向いています。
一方で、画面、ブラウザ履歴、キーストロークをローカルであっても記録すること自体に抵抗がある人には向きません。Contextbergの価値は、意図的に広いシグナルを扱うところにあります。
これから
今後はmacOSとLinux対応、Hermesモデル連携、スキルコマンドの自動生成、Skills管理ビューなどを進めていく予定です。
Contextbergの目標は、Claude Code、Codex、Cursorなど複数のエージェントが、あなたの過去の作業文脈を共有できるようにすることです。エージェント会話履歴だけでは足りないので、画面、ブラウザ、キーボード、アプリ利用も含めて、Windowsネイティブのローカルメモリアプリとしてまとめました。
Microsoft Store、Product Hunt、公式サイトで公開しています。質問、批判、アイデアがあれば、Xの@screenest_aiまで送ってください。