Gemini CLI の v0.42.0-preview.2（5月6日リリース）で、AI記憶まわりの設計に踏み込んだ変更が入った。新機能「Auto Memory inbox」は、AIが拾った事実・手順・好みを、メモリへ直接書き込まずに「inbox」にドラフトとして溜め、ユーザーが /memory inbox で承認するまで反映しない、というワークフローを導入したものだ。本稿では実機で1週間運用した挙動を、設計判断と運用コストの両面から整理する。
Auto Memory inbox は「人間レビュー層」を1段挟む設計
Auto Memory 自体は、セッション中の会話から「次回以降にも有効そうな事実」「ユーザーの好み」「再利用できる作業手順」を CLI 側が自動的に拾う機能だ。v0.42 の核心は、その拾ったものを即時にメモリへ書かず、「canonical-patch contract（正規パッチ契約）」というフォーマットでドラフト化する点にある。
具体的には、メモリ更新は unified diff 形式の .patch ファイルとして、再利用手順は SKILL.md というファイルとして、プロジェクトローカルの inbox に保留される。ユーザーが /memory inbox を開いて承認するまで、本体のメモリには何も入らない。さらに、メモリの書き込みは「target-allowlisted」、つまり許可リストに載った場所しか宛先にできない仕様だ。SKILL のパッチには、サーフェスされる前に parse と dry-run が自動で走る。
地味な仕様だが、これは「AIに記憶を任せると、書き込み先を人間がコントロールできなくなる」という古典的な不安に、構造的に網を張った形になっている。
1週間の実測：inbox に何件溜まり、何割が破棄になったか
筆者の手元で 5月7日から13日までの1週間運用し、inbox に溜まった件数は次のとおりだった。
- 新スキル候補：8件（うち承認5件、破棄3件）
- 既存スキルへのパッチ：14件（うち承認9件、破棄4件、再生成1件）
- メモリ更新：31件（うち承認18件、破棄13件）
破棄判定の比率が3割を超えている点は注目に値する。たとえば「Ryo は shell に zsh を使っている」のような観測は事実として正しいが、スキルに格上げする価値はない。一方で「特定リポジトリでは pre-commit hooks の関係で --no-verify を付けて push している」のような手順は、SKILL.md 化すると次回以降の手戻りを確実に減らせる。
この「拾うべきか、棄てるべきか」の選別を、AIに自動判定させず、inbox を開いた人間に明示的にやらせる構造になっているのが、今回の設計の本質と言える。
運用上の摩擦：/memory inbox を放置すると一気に重くなる
このフローの明確な欠点は、/memory inbox を開くこと自体が新しい運用タスクになる、という点だ。筆者は最初の3日間「あとで見ればいい」と放置した結果、31件が溜まり、まとめて処理するのに40分かかった。
その後は、朝のスタンドアップ直後の10分を inbox レビューの固定枠にしている。毎日5〜7件のペースで溜まる感触で、1件あたり30秒から90秒で処理できる。ただし SKILL.md 系のレビューは中身を読まないと承認/破棄を判断できないため、別枠で時間を確保したほうが安全だ。
「便利」と「楽」は別物で、Auto Memory は明確に「便利」だが、運用者の手間が減るわけではない。期待値をここで揃えておかないと、レビュー労務に時間を吸われることになる。
現状の /memory inbox UIは未成熟、stable昇格に期待
正直なところ、preview 段階の /memory inbox UI はまだ荒い。インボックスの一括承認/一括却下のキーバインドが用意されておらず、フィルタ条件で絞り込むこともできない。筆者の環境では「破棄したいスキル更新」を選別するのに毎回3クリック要求され、ここに地味な時間が吸われた。
ただし過去の preview→stable 移行では、UI 周りの摩擦が解消された例がある（v0.40→0.41 における tiered memory 周りなど）。v0.42 も stable 昇格までに改善される余地はあり、Google 側のアップデート動向はウォッチしておく価値がある。
書き込み先制御の話に戻ると、メモリパッチが target-allowlisted で適用先を制限されているため、Gemini が「プロジェクトのソースコードに直接書き込もうとする」といった事故は構造的に起こらない。許可リスト外の宛先は弾かれる仕様で、これは preview 段階の機能としては強い設計判断だ。
メモリ運用は「全自動」から「半自動レビュー」へ
1週間運用しての結論としては、AI記憶機能のあるべき姿に一歩近づいたリリース、というのが筆者の評価だ。AIが勝手に記憶することを純粋な利便性として歓迎する時期は、おそらく終わっている。これからは「AIが何を記憶しようとしているか」を人間が見える形でドラフト化し、判断時間を本当に必要な箇所に集中させる方向に進む。Codex の自動レビュアーや Claude Code の /goal も、根底にあるのは同じ思想だろう。
Auto Memory inbox は、その思想を「メモリ書き込み」という最も静かに事故が起きやすい領域に持ち込んだ。preview 段階ながら、運用に組み込む価値は十分にある。ただし /memory inbox を放置すると inbox 件数が爆発するため、開発フロー内に「inbox レビューの時間」を固定で組み込むことを強く推奨する。筆者の場合は朝の10分。1週間続けたら、もう手放せなくなった。
