数か月前、Manus は Context Engineering について書いたブログを公開した。
https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

すべてのコンテキストをエージェントのメッセージ履歴に積む必要はない。だから**コンテキストのオフロード（offloading）**が要る。

LangChain 側の知見

コンテキストをファイルシステムへ卸す

よくあるのはファイルシステムの利用だ。例：ツールの返り値が重い——全文をディスクに書き、エージェントの推論に必要な最小限の要約だけ会話に戻す。細部が要るときだけオンデマンドで読む。こうすればウェブ検索のようにトークンが爆発する結果が、ウィンドウを永遠に占有しない。

コンテキストの圧縮

要約や圧縮で負荷を下げる。ツール出力の要約は自然な一手だ。古いツール呼び出しとその出力を削る（Claude などの SDK でもますます一般的）。Cognition などのエージェントアプリも、エージェントの引き継ぎで要約により「承認／ハンドオフ」する話をしている。

オンデマンドでコンテキストを取り戻す

Claude Code はほぼファイルシステムと簡単な検索ツール（特に glob／grep）だけに頼る。インデックス＋意味検索でも、純粋なファイルシステム検索でも、十分効く。

コンテキストの分離

マルチエージェントでは特に重要。各サブエージェントが独自のコンテキストウィンドウを持ち、関心の分離しやすい。

コンテキストのキャッシュ

LangChain の open deep research：
https://github.com/langchain-ai/open_deep_research

三段階：研究スコープの確定 → マルチエージェントで研究 → 最後に一括ライティング。オフロードを使う：まず研究 brief で計画を定義し、外部に保存しておき、brief を主コンテキストにずっと載せない（後から他の情報に薄まる）。brief は独立保存し、グラフ状態やファイルシステムから取り戻せる——研究を大きく回したあと、必要に応じてメッセージリスト末尾へ再投入し、執筆段階に使う。研究フェーズ内部では、reduction 要約でサーフ系ツールの大量観察を圧縮し、サブエージェント間の context isolation で隔離する——一つのプロジェクトに複数の手法をまとめた形だ。

Manus 側の知見

早すぎる専用モデル化は避け、スタートアップはできるだけ長く汎用モデル＋コンテキスト工学に寄せるべきだ、という立場。

コンテキスト圧縮：Compaction と Summarization

Manus では、各ツール呼び出しと結果に完全版とコンパクト版がある。コンパクト版は、ファイルシステムや外部環境から再構築できる情報を落とす。例：ファイル書き込みツールの返り値に path と content がある。ディスクに書いたあとは、コンパクト版では長大な content を捨て path だけ残せる——エージェントが十分賢ければ必要時にファイルを読めばよく、情報は失われていない。単に外部化しただけだ。この可逆性が重要。エージェントは過去の行動と観察を連鎖的に参照し、十歩先でどの行動が急に効いてくるか分からない。

Compaction だけでは限界があり、コンテキストは依然として上限に当たる。そこで従来の summarization と組み合わせるが、非常に慎重に——例：要約の前に重要段落をファイルへオフロードする。攻めた場合は要約前のコンテキスト全体をテキスト／ログにダンプし、後から復元可能にする。glob／grep でログを辿るだけの人もいる。モデルが十分賢ければ「要約の前」のコンテキストまで取り戻せる。

要点：compaction は可逆、summarization は不可逆。どちらも長さは縮むが、振る舞いはまったく違う。

両立にはコンテキスト長の閾値の追跡が要る。モデルのハード上限は 1M トークンに届いても、だいたい 200k 付近から「context rot」（繰り返し、遅さ、品質低下）が始まる。評価で腐る手前の閾値（よく 128k–200k 付近）を見つけ、近づいたら負荷を下げ、先に compaction、次に summarization。Compaction も履歴全体である必要はない——最も古い 50% のツール呼び出しだけ compact し、新しい方は完全版のままにして、モデルが「正しいツールの使い方」をまねできるようにする。さもなくと、最悪、モデルがフィールド欠損の compact 形式を吐くようになり、逆に壊れる。Compaction 後は実際にどれだけ空いたかを確認し、数ラウンドで効果が小さいなら summarization。Summarization は常に完全データを使い、compact 版は使わない。直近のツール呼び出し／結果のいくつかは要約せず完全版のまま残し、「今どこまでやったか」をモデルに知らせ、トーンのドリフトを防ぐ。

コンテキスト分離：通信と共有メモリ

Cognition のブログの注意：マルチエージェント間の情報同期は悪夢になりうる。マルチプロセス／マルチスレッドの協調は古典的に難題で、Go コミュニティの格言を借りるなら「共有メモリで通信するな。通信によってメモリを共有せよ」。
https://chatgpt.com/share/68f4f8c3-baac-8004-9cf7-421375260909

エージェントに常にそのまま当てはまるわけではないが、二つのパターンを示す。「メモリ」を「コンテキスト」に置き換えると、**「通信による」**のは古典的なサブエージェント：親が指示を送り、子のコンテキストはほぼそのタスクだけ——短く明確で、最終結果だけ欲しい仕事向け（コードベースの一片を探すなど）。親は子の探索過程より結果だけ欲しい。Claude Code の task tool はよくこう使う。

「共有メモリ／共有コンテキスト」は、子が前の完全なコンテキスト（全ツール履歴）を見られるが、system prompt と行動空間は別、という形。最終レポートのための深い調査では、中間の検索やメモが多く、メモをファイルに書いて子が全部読むより、子に直接コンテキストを共有した方が遅延とトークンを節約できる場合がある。代償は各サブエージェントの prefill が大きく入力トークンが高くなり、system／行動空間が違うとKV キャッシュを共有できずフル料金になること。

コンテキストオフロード：階層化された行動空間

オフロードは作業コンテキストを外部ファイルへ、とよく言う。システムが大きくなり特に MCP を繋ぐとツール定義そのものがコンテキストを食い、ツールが多いと「context confusion」になり、モデルが誤ったツールや存在しないツールを呼ぶ。よくあるのはタスクに応じたツール記述の動的 RAG だが、ツール定義は文脈の前寄りにあり、KV が何度もリセットされる。履歴にはもう無いツールへの呼び出しが残り、モデルを迷わせる。

Manus は階層化された行動空間を試している：モデルが三つの抽象レベルから選ぶ——(1) 関数呼び出し (2) サンドボックス内のユーティリティ (3) パッケージと API。

第一層の関数呼び出し：スキーマは安全（制約付きデコード）だが、ツールが多いと混乱しキャッシュも壊れる。Manus は固定数の原子関数：ファイル読み書き、シェル実行、ファイル／ネット検索、ブラウザ操作など。境界が明確で複雑なワークフローを組み立てられる。残りの能力は第二層のサンドボックスツールへ。各セッションはフル Linux VM で、シェルからプリインストール済みツール（変換、音声認識、コマンドライン経由の MCP——MCP ツールを関数空間に詰め込まず CLI で処理）を呼べる。新能力はユーティリティ追加で足せ、モデルの呼び出し空間を変えなくてよい。大きな出力はファイルへ書くかページングし、grep／cat／less で処理。代償はフロントエンドとの低遅延往復では可視化のチェーンが長くなること。

第三層のパッケージと API：Python でプリ承認 API やカスタムパッケージ（サブスクに API キー込み）を書く。大量メモリ計算が要るが生データを全部モデルに入れたくないタスク向け——例：一年分の株価をスクリプトで集計し要約だけ返す。コードと API を組み合わせ、一ステップに多くの呼び出しを連ねる（Code Act 論文に近い）。欠点は関数呼び出しほどスキーマが安全でなく制約デコードが難しいこと。Manus の方針：コンパイラ／インタプリタの実行時に任せられるものはコード。そうでなければサンドボックスツールか関数呼び出し。モデルから見れば三層とも統一された関数インタフェースで、UI が単純でキャッシュに効き、関数同士が直交する——例：サンドボックスツールもシェル関数経由、第三者 API はファイルに書いてシェル実行、など。

五つの軸をつなぎ、過剰設計を避ける

Offload、reduce、retrieve、isolate、cache は独立ではない：offload＋retrieve が reduction を効かせる。安定した retrieve が isolation を安全にする。isolation は連絡を遅くし reduction の頻度を変える。isolation と reduction はキャッシュ効率と出力品質にも効く。コンテキスト工学は複数目標のあいだのバランスの科学であり芸術だ。

最後の一文は一見矛盾するが：コンテキストの過剰工学は避けよ。Manus 公開から六、七か月で、最大の飛躍はしばしば、より凝ったコンテキスト層や検索テクニックを足すことではなく、単純化し、不要な細工を削り、モデルをもう少し信頼することだった。アーキテクチャを簡素化するたび、システムは速く、安定し、賢くなる——コンテキスト工学の目的はモデルの仕事を簡単にすることであって、難しくすることではない。一つだけ持ち帰るなら：足場を少なく、問題を多く理解せよ（build less and understand more）。

Q&A（要旨訳。原文の意図に合わせる）

シェルツールとサンドボックス

問：LLM はどのシェルツールがあり、どう呼ぶかをどう知る？多層サンドボックスはどう設計？
答：システムプロンプトにプリインストール CLI のディレクトリを書き、よく使うツールはコンパクトに列挙。使い方は教えず名前だけ。--help を安全に使える旨を書く（フォーマットは統一）。

インデックス対ファイルシステム検索

問：ベクトル DB、オンザフライで索引？
答：絶対の正解はない。Manus のサンドボックスセッションはたいてい新規で素早い対話が要り、索引をその場で建てる時間がない。Claude Code の grep／glob に近い。長期記憶や企業ナレッジなら外部ベクトル索引がまだ要る場合も。情報規模とコードベース／サンドボックスが長期かどうかによる。

セッション横断の記憶

問：Claude の CLAUDE.md のようなセッション横断の永続化？
答：Manus には knowledge があり、明示的記憶に近い。「今後ずっと覚えて」と言うとポップアップで採用確認。より自動的な方法も探索中——例：可視化での中日韓フォントの修正が繰り返されるような集合的フィードバックを、パラメータ更新なしのオンライン改善に使う。

モデル進化に合わせたアーキ更新

問：モデルが強くなったら足場を外す。どのくらいの頻度で見直す？
答：モデルは良くなるだけでなく振る舞いも変わる。ベンダーと密に連携。内部評価の一つ：エージェントアーキを固定したまま強弱モデルを切り替える——強モデルで伸び大きければアーキはより「未来向き」。Manus は三月公開から十月まで大きな改版を約五回。一、二か月ごとに振り返り、オープンソースや初期クローズドモデルで事前研究もする。

データ保存形式

問：Markdown、プレーンテキスト、ログ？
答：行指向を優先し、grep や行範囲読みをしやすくする。Markdown はモデルがリスト記号を使いすぎることがある。

要約のプロンプト

問：summarization は不可逆。どうプロンプトする？
答：凝ったプロンプトはいろいろ試したが、シンプルで効くのは完全自由形式にしないこと。複数フィールドのスキーマで表を埋めさせる（どのファイルを変えたか、ユーザーの目的、どこまで進んだか等）。出力が安定し、反復しやすい。

検索結果の compaction

問：検索ツールが重い。情報を残しつつ履歴を抑えるには？
答：複雑な多段検索は sub-agent／agent as tool で、外からは一つの「高度な検索」関数に見せ、内部は固定出力スキーマのワークフロー。単純検索はまず完全結果を渡し compaction に頼る。モデルに中間の洞察をファイルへ書かせ、早すぎる compact で失わないようにする。

エージェント間通信と MapReduce

問：agent as tool は効くが、エージェント間は情報をどう渡す？
答：Manus の Wide Research は内部的に agentic MapReduce：親子エージェントが同一サンドボックスファイルシステムを共有し、パスで引数を渡す。難所は多路出力のマージ。親は先に出力スキーマを定義し、子は制約デコード付きの submit_result で返す。スキーマ付きの「表」を生成するイメージ。

モデル選択とオープンソース

問：オープンソース、微調整？KV cache？
答：現状オープンソースは使っていない。品質だけでなくコストの理由も。エージェントは入力が出力より遥かに大きく、分散 KV cache が重要。大手クラウドの基盤の方が割に合うことも。Anthropic だけでなく、コードは Claude、マルチモーダルは Gemini、複雑推理は OpenAI など、タスクやサブタスク単位でルーティングも可能。

ツール数と階層行動空間（再掲）

問：ツールが多すぎる？
答：モデル次第だが、経験上一度に 30 を超えるツールは避ける（おおまかな目安）。汎用エージェントの原子関数は絞る。Manus はだいたい十個台の原子関数で、残りはサンドボックス側。ツール定義テーブルを動的に丸ごと引っ張るのは避ける。

プランニングと todo.md

問：to-do ツール？
答：初期は to-do.md パターンで、ラウンドを浪費した（ときに三分の一が todo 更新）。今はより構造化された planner（根底も agent as tool）。最新版は todo.md に依存しない。使っても動くがトークンはかさむ。

マルチエージェントの役割分担

問：プランナー、ナレッジ管理？
答：Manus はマルチエージェントだが**「デザイナー／プログラマー／マネージャー」といった人間組織の硬い分割はしない**——それは人間のコンテキスト限界から来る分業が多い。Manus のサブエージェントは少ない：大きな実行器、プランニング、knowledge 管理、データ API 登録など。追加は慎重。ナレッジエージェントは会話を見て、長期記憶に入れるべきか決める。

サンドボックスの安全

問：ネット接続サンドボックスのガードレール？
答：少なくとも機密がサンドボックス外に出ないこと。外向きトラフィックは検査。ブラウザはログイン状態やページ注入など複雑で、企業の能力境界とコンピュータ利用モデルのベンダーとの協業に関わる。敏感な操作は手動確認が多い。ガードが良くなれば人手を減らす。

評価

問：正式な eval はまだ意味がある？
答：初期は Gaia など公開ベンチを使ったが、ユーザー嗜好と大きくズレた。今は三種：(1) セッション終了ごとのユーザー 1–5 星（最重要）；(2) 検証可能な答えの自動テスト＋実行寄りの自前セット；(3) 大量のインターンがサイト生成や可視化など「趣味」のタスクを評価——報酬モデルで美しさを判定するのは難しい。

RL と検証可能な報酬

問：自前 harness での RL との比較？
答：長年 post-training／RL だが、MCP を支えると行動空間が固定でなく安定報酬と均衡 rollout を設計しづらく、ほぼ自前基盤になる。コミュニティモデル企業がその部分を担う。無パラメータのパーソナライズ／オンライン学習（集合的フィードバックなど）に関心。Claude Code と同名ツールを再利用するか：意図的に同名にしない。post-training データの内部ツールと混同し、パラメータ不一致で誤誘導するのを避ける。

コードエージェント：純スクリプトと混合

問：コードエージェントは毎ステップスクリプト生成してサンドボックス実行？Manus はツール直叩きとサンドボックスが混在？
答：重要——Manus をコードだけにしようとしたが、コード経路は制約デコードが効きにくく制御しづらい。コードは大量データをランタイムメモリで処理し結果だけ返す等に向く。関数呼び出し／サンドボックスツールと併用すべき。

Claude Code と「同名ツール」

問：Anthropic が Claude Code ツールで RL している。自社 harness で同名同記述なら似た能力が「解放」される？
答：意図的に同名を避ける。自前関数のパラメータと要件が違い、post-training で見た内部ツールと現在実装を混同させたくない。