コーディングエージェントに同じリポジトリで2つ目の質問を投げると、たいてい最初とほぼ同じことをやり出す。ディレクトリ構成をlsで舐め、設定ファイルの場所を探し、どのモジュールが認証を握っているのかを推理し直す。人間なら一度触ったコードベースの見取り図は頭に残るのに、エージェントは毎回ゼロから街を歩き回る。この「毎回の再探索」で消えていく反復回数とトークンを、小さな常駐メモに畳み込もうというのがPEEKだ。
MITとStanfordのZhuohan Gu、Qizheng Zhang、Omar Khattab、Samuel Maddenが5月19日にarXivへ出した提案で、コードはpeek-aiとしてApache-2.0で公開されている。8月に入って実運用のコーディングエージェント界隈で言及が増えてきた。
🗺️ 覚えるのは中身ではなく「どこに何があるか」
PEEKの中心にあるのはコンテキストマップと呼ぶ小さな成果物だ。エージェントのシステムプロンプトの中に常駐する、サイズが固定された一枚のメモだと思えばいい。ここに書き込むのは文書やコードの中身そのものではない。「この文脈に何が含まれ、どう整理され、どのエンティティ・定数・スキーマが過去に役立ったか」という、いわば土地勘のほうだ。
この区別が肝で、既存手法との差もここに出る。RAG(検索拡張生成、質問のたびに外部データから関連断片を引いてくる方式)や会話履歴を要約するメモリは、素材そのものや要約を持ち回る。PEEKが持つのは素材ではなく素材への地図なので、検索と競合せず補完する関係になる。エージェントは「どこを見ればいいか」を先に知った状態で探索に入れる。
もう一つの比較対象が、直前のSOTAだったプロンプト学習フレームワークACEだ。ACEがタスクレベルの戦略(こう解けばうまくいく、という手順の学習)を蓄えるのに対し、PEEKが狙うのは外部文脈そのものの状態を追いかけることだと論文は位置づけている。著者ブログにある例がわかりやすい。5万件超のユーザーフィードバックを繰り返し問い合わせる分析担当が、機能要望の傾向や頻出クレーム、どの製品領域が絡むかといった知見をキャッシュしておけば、新しい質問のたびに全部を読み直さずに済む。
🧭 3つのモジュールが固定トークンの地図を保守する
面白いのは、この地図を人手でメンテするのではなく、プログラム可能なキャッシュポリシーが自動で更新する設計になっている点だ。役割の違う3つのモジュールが順に働く。
- Distiller — エージェントの実行トラジェクトリ(推論の道筋)を読み、転用できる知識を抜き出す。同時に既存のマップ項目を helpful / harmful / neutral / stale の4種にタグ付けする
- Cartographer — その出力を ADD・DELETE・REPLACE という構造化された編集に変換する。ここで重複を排し、タスク固有の細部がキャッシュに漏れ込むのを防ぐ
- Evictor — 固定のトークン予算を守る。スコアの低い項目から捨て、同点なら古いものを落とす
私が一番効いていると思うのはCartographerとEvictorの組だ。エージェントのメモリは放っておくと際限なく膨らみ、直近のタスク固有ノイズで汚れていく。PEEKは「常時この予算に収める」という上限を先に決め、その中で優先順位を強制する。無制限に育つ記憶ではなく、有限の予算が捨てる判断を迫る構造になっている。マップが定数サイズでプロンプトに常駐するということは、プロンプトキャッシュとも相性が良いはずで、この点はコスト面で地味に効く。
📊 ACE比で反復93〜145回減、コストは最大5.8分の1
数字はACEを基準に取られている。論文はベースライン全体に対して6.3〜34.0%の精度改善を報告し、内訳としては長文脈の推論・集約を測るOOLONGと、文脈学習を測るCL-benchで検証している。
| ベンチマーク | 指標 | ACEに対する結果 |
|---|---|---|
| OOLONG(長文脈の推論・集約) | 精度 | +7.8〜+15.0% |
| 反復回数 | 93〜145回少ない | |
| コスト | 1.7〜5.8分の1 | |
| CL-bench(文脈学習) | 解答率 | +6.0% |
| ルーブリック精度 | +9.9% | |
| コスト | 1.4分の1 |
反復回数がこれだけ減るのは、エージェントが同じ発見を繰り返さなくなるという主張と筋が通っている。精度もコストも同時に良くなっているのは、無駄な往復そのものが精度を削っていた裏返しだと読める。効果はGPT-5.5、Qwen3-Coder、そして実運用のコーディングエージェントであるOpenAI Codexにまたがって出たと報告されており、特定モデル頼みの結果ではなさそうだ。
pip install peek-ai で試す
使い方は、キャッシュポリシーを一つ作り、質問を回すループの中でマップをシステムプロンプトに差し込み、実行後に更新をかけるだけだ。READMEのクイックスタートはこうなっている。
pip install peek-ai[openai] # OpenAI互換エンドポイントを使う場合
from peek import CachePolicy
from peek.llm.openai_client import OpenAIClient
client = OpenAIClient(model="gpt-5-mini-2025-08-07")
policy = CachePolicy(client=client, token_budget=1024, evolve_steps=10)
for question in stream_of_questions:
system_prompt = f"{base_instructions}\n\nContext Map:\n{policy.current_map_text}"
trajectory = my_agent.run(system_prompt, question, long_external_context)
policy.update(trajectory=trajectory, question=question)
policy.save("maps/my-corpus.peek.json")
token_budget=1024がEvictorの守る上限、evolve_stepsがマップを更新する間隔にあたる。policy.current_map_textをプロンプトに挟み、実行後にpolicy.updateでトラジェクトリを食わせる。マップはsaveでJSONに落ちるので、同じコーパスやリポジトリに対して土地勘を持ち越せる。peek-ai[anthropic]やpeek-ai[gemini]のエクストラも用意されている。
引っかかるとすればCartographerの精度だ。タスク固有の情報を弾いて転用可能な知見だけを残す、という選別が甘いと、地図はいずれ前回の質問の残り香で濁る。ここが崩れたときにどう劣化するのか、どんな文脈が「汚染」として混じりやすいのかは、自分の題材で回して確かめたい部分になる。とはいえ、「エージェントがなぜ毎回リポジトリを探索し直すのか」という、コーディングエージェントを日常的に使う人なら必ず踏む苛立ちに、定数サイズのプロンプト常駐キャッシュという具体的な形で答えを出してきたのは筋がいい。メモリを無限に伸ばす方向ではなく、有限の予算で捨てる方向に賭けたところが、この提案のいちばんの見どころだと思う。
出典: PEEK: Context Map as an Orientation Cache for Long-Context LLM Agents (arXiv:2605.19932) / 著者ブログ Give Your Agent an Orientation Cache / コード github.com/zhuohangu/peek
※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。