常駐しても邪魔にならないWindows作業メモリを作る
Slack、Teams、VS Code、Dockerと並べて使う前提で、常駐アプリのメモリ使用量とWindowsネイティブ実装をどう考えたかをまとめます。
常駐アプリは軽くないと使われない
Contextbergは、画面、ブラウザ履歴、キーボード入力、アプリ利用をバックグラウンドで扱う常駐アプリです。常駐する以上、機能以前に軽さが重要です。
Slack、Teams、Edge、VS Code、Docker Desktopが起動しているPCで、さらに500MB以上使うアプリを入れてもらうのは現実的ではありません。特に企業PCでは、メモリ8GBや16GBの環境もまだ多いです。
目標にしたライン
Contextbergでは、アイドル時メモリ120から180MB、アクティブ時およそ250MB、アイドルCPU 1%未満、MSIXサイズ約100MBを目安にしています。
この数字は、単にベンチマークとしてきれいだからではありません。ユーザーが『入れておいても邪魔にならない』と感じるための実用ラインです。
ElectronではなくWPFを選んだ理由
ElectronはUI開発の速度では魅力的ですが、常駐アプリとしてChromiumプロセスを抱える時点で、メモリの下限が上がりやすくなります。
Contextbergでは、キーボードフック、フォアグラウンドウィンドウ取得、スクリーンキャプチャ、DPAPI、MSIXパッケージ識別など、Windows APIに近い処理が多くあります。WPF + .NETであれば、このあたりを素直に扱えます。
Microsoft Store配布を前提にしたときも、WPF + .NET 8 + Windows App SDKの組み合わせは摩擦が少ないです。
クロスプラットフォームを後回しにした理由
macOSやLinuxもいずれ対応したいです。ただ、最初から全OS対応を狙って重くなるより、まずWindowsで軽く安定して動くことを優先しました。
エージェントを使う開発者の中にはWindowsユーザーも多く、既存のメモリ系ツールではmacOS前提のものも目立ちます。Windows開発者を置いていかないことは、Contextbergの重要なテーマです。
軽さは信頼の一部
常駐アプリは、使っていない時間の印象で評価されます。必要なときに便利でも、普段からファンを回し、メモリを食い、作業を邪魔するならアンインストールされます。
エージェントメモリは毎日使うインフラに近い存在です。だからこそ、派手な機能だけでなく、普段は静かに動くことを設計上の価値として扱っています。