Ambient Context: LLMのメモリのためのローカル・テキストベース・アクティビティ・ロギング

Ambient Contextは、大規模言語モデル（LLM）の長期的なメモリとして機能させるために、ユーザーのデジタル活動の永続的な記録を作成するように設計されたmacOSアプリケーションです。スクリーンショットやビデオに依存する従来の活動トラッカーとは異なり、Ambient ContextはmacOSのアクセシビリティ・ツリーを使用して、フォーカスされたウィンドウからテキストを直接抽出し、データをローカルのMarkdownファイルとして保存します。

ローカル・ファースト・アーキテクチャとプライバシー

Ambient Contextは、機密性の高いユーザーデータがマシンから決して離れないように、厳格なローカル・ファーストのプライバシーモデルに基づいて動作します。このアプリケーションは、アカウントを必要とせず、サーバーを使用せず、バンドルされたモデルやテレメトリも含まれていません。

主なプライバシー保護機能には以下が含まれます：

Focused Window Only: アプリは現在フォーカスされているウィンドウのみを読み取ります。バックグラウンド、最小化、または画面外のウィンドウは無視し、画面がロックされているときは動作を停止します。
Automatic Redaction: パスワードマネージャーやプライベートブラウジング・ウィンドウはキャプチャから除外されます。アクセシビリティ・レベルでセキュア・インプット・フィールドはスキップされ、アプリはディスクに書き込む前に、認証情報、APIキー、およびクレジットカード番号を消去します。
User-Owned Data: すべての記録は、ユーザーが選択したフォルダ内のプレーンなMarkdownファイルとして保存されるため、grep検索、手動での削除、または移行が容易です。

アクセシビリティAPIを介した技術的実装

スクリーンショットに対する光学文字認識（OCR）を使用するのではなく、Ambient ContextはmacOSのアクセシビリティAPIを活用して、数秒ごとにフォーカスされたウィンドウのテキストを読み取ります。このアプローチは、ストレージのオーバーヘッドを最小限に抑え、画像ベースのキャプチャに関連するプライバシーのリスクを回避します。

互換性と制限事項

アクセシビリティ・ツリーに依存しているため、その効果はアプリケーションによって異なります：

Chromium and Electron Apps: Chrome、Slack、VS Code、およびObsidianのようなアプリケーションは、リクエストされたときにのみアクセシビリティ・ツリーを構築します。これにより、初期キャプチャが「薄い」状態になり、数秒かけて情報を補完することがあります。また、Chromeはキャプチャ中にわずかなウィンドウ・リサイズ・アニメーションを示すことがあります。
Terminals: KittyやAlacrittyのようなGPUレンダリングされたターミナルは、このAPIを介してテキストをほとんど、あるいは全く提供しません。Terminal.appやiTerm2のような標準的なツールは完全にサポートされています。
System Requirements: このアプリはApple Silicon上のmacOS 14+を必要とします。

LLMに最適化されたデータ形式

キャプチャされたデータは、AIエージェント（Claude Codeなど）が過去の作業について質問に答えたり、ステータス・レポートを自動化したりするために、取り込むことが特別に構造化されています。

各日は、以下の特性を持つ単一のMarkdownファイルとして記録されます：

Timeline Structure: ブロック見出しは、時間、アプリケーション、およびドキュメント・タイトルによってその日の活動を整理します（例：## 09:41–10:05 · Chrome · Tauri tray documentation）。
Deduplication: 本文の行は、どれほど頻繁に表示されていても、1日につき1回のみ書き込まれます。これにより、ファイルがLLMのコンテキスト・ウィンドウに対して大きくなりすぎるのを防ぎます。
Contextual Metadata: 各ブロックはドキュメントのパスまたはURLを記録するため、エージェントが断片ではなく元のソースを参照できるようにします。
Agent Guidance: キャプチャ・フォルダには、データ形式を説明するAGENTS.mdファイルが含まれており、ディレクトリを読み取る任意のLLMがそれを参照できます。

コミュニティの視点とトレードオフ

開発者の間での議論によれば、アクセシビリティAPIのアプローチは軽量である一方、「データの欠落」という課題に直面しています。

"The accessibility tree works for a lot of things but the more I worked on it the more stuff I found needed pixels."

一部のユーザーは、多くのアプリケーションがアクセシビリティ用に「正しく接続（wired up right）」されていないことを指摘しており、高精度なキャプチャを実現するために特定のアプリ用のカスタム・プロファイルが必要になる場合があります。他のユーザーは、git commits、Slackメッセージ、およびメールといった、構造化されたデジタル・フットプリントを統合することが、特定のワークフローにおいてスクリーン・スクレイピングのより信頼できる代替手段になり得ると提案しています。