manusの上下文工程って何がすごい？AI Agent時代に乗り遅れないための実践メモ

「manus 上下文 工程」と検索している人の多くは、Manusが公開した「Context Engineering for AI Agents」の内容を読みたい、または中国語圏で語られている“上下文工程”を日本語で理解したい人だと思います。上下文工程は、日本語では主にコンテキストエンジニアリングと訳せる考え方で、AI Agentに「何を覚えさせ、何を見せ、何を外に逃がすか」を設計する技術です。

この記事では、Manus公式記事、関連解説、Anthropicのコンテキストエンジニアリング論をもとに、KVキャッシュ、ツール設計、ファイルシステム記憶、todo.md、エラー保持、few-shotの落とし穴、Cursor的な開発Agentへの応用まで整理します。専門用語はなるべくかみ砕き、AI Agentを作る人だけでなく、AIツールを使いこなしたい人にもわかるようにまとめます。

この記事のポイント
✅ manus 上下文 工程の意味と、なぜAI Agentで重要なのかがわかる
✅ Manusが重視するKVキャッシュ、ファイルシステム、エラー保持の考え方がわかる
✅ 大模型上下文工程、Agent 上下文 工程、Cursor 上下文 工程との関係が整理できる
✅ AI Agent設計でやりがちな失敗と、実務で使いやすい改善策が見える

manus 上下文 工程の核心

1. manus 上下文 工程とはAI Agentの作業記憶を設計する考え方である
2. 大模型上下文工程ではプロンプトよりも「何を文脈に入れるか」が重要になる
3. Agent 上下文 工程では長い作業ループを壊さない設計が成果を左右する
4. KVキャッシュを意識するとAI Agentの速度とコストを下げやすい
5. ツールは削除せずマスクするほうが文脈の安定性を保ちやすい
6. ファイルシステムを文脈として使うと長文脈の限界を避けやすい

manus 上下文 工程とはAI Agentの作業記憶を設計する考え方である

「manus 上下文 工程」の“上下文”は、中国語でコンテキストを意味します。つまり、manus 上下文 工程とは、ManusがAI Agentを作る中で重視しているコンテキストエンジニアリングのことです。ざっくり言えば、AIに渡す情報の入れ方、残し方、消し方、外部に逃がす方法を設計する技術です。

従来よく語られてきたのは「プロンプトエンジニアリング」でした。これは、AIに対してどんな指示文を書くかを工夫する考え方です。一方で、上下文工程はもう少し広い概念です。指示文だけでなく、ツール一覧、過去の会話、検索結果、ファイル、エラー履歴、作業計画など、AIが次の一手を判断するために見る情報全体を扱います。

Manus公式記事では、AI Agentはユーザーの依頼を受けたあと、ツールを呼び出し、その結果を観察し、また次の行動を選ぶ、というループで動くと説明されています。このループが長くなるほど、AIに渡される文脈は増えていきます。ここで整理せずに全部を詰め込むと、AIは遅くなり、費用も増え、判断もぶれやすくなります。

🧭 用語の整理

用語	意味	この記事での見方
上下文	コンテキスト、文脈	AIが判断時に参照する情報全体
工程	エンジニアリング、設計	文脈をどう作り、維持するか
AI Agent	AIが自律的にツールを使う仕組み	Manusの中心テーマ
プロンプト	AIへの指示文	上下文の一部にすぎない
コンテキストウィンドウ	AIが一度に読める範囲	有限で、使い方に工夫が必要

ここで重要なのは、上下文工程は「長いプロンプトを書けばよい」という話ではない点です。むしろ、長すぎる文脈はAIの注意力を奪う可能性があります。Anthropicの記事でも、文脈は有限な資源であり、入れる情報を選ぶ必要があると説明されています。

Manusが面白いのは、この問題を単なる理論ではなく、実際のAI Agent運用の中で整理している点です。公式記事では、Manusの典型的なタスクは多くのツール呼び出しを伴うとされ、1回の会話で何十回もAIが判断する前提になっています。つまり、1回の返答だけをうまく作る技術では足りません。

📌 manus 上下文 工程を一言でいうと

観点	説明
目的	AI Agentが長い作業でも迷子にならないようにする
対象	指示、ツール、履歴、検索結果、ファイル、エラー、計画
効果	速度、コスト、精度、復旧力の改善につながりやすい
注意点	情報を増やせばよいわけではない
実務感	AIを“賢くする”より、AIが賢く動ける環境を作る考え方

---

大事なのは、上下文工程がAI Agentの「作業環境づくり」だということです。人間でも、机の上が資料だらけだと必要な情報を探しにくくなります。逆に、何も置いていなければ作業できません。AIも同じで、必要な情報を必要な形で置くことが重要になります。

Manusの文脈でいえば、AIを特別な専用モデルとして一から訓練するのではなく、進化し続ける既存の大規模モデルをうまく使う方向を選んだ、という点も重要です。モデル自体を毎回作り直すより、文脈の設計を改善するほうが、短いサイクルで改善しやすいという考え方です。

この視点は、ChatGPT、Claude、Cursor、各種AI Agentを使う人にも役立ちます。AIがミスをしたとき、単に「もっと賢いモデルを使う」だけでなく、AIに見せている情報の質が悪くないかを疑うべきだからです。

大模型上下文工程ではプロンプトよりも「何を文脈に入れるか」が重要になる

「大模型上下文工程」という検索意図では、大規模言語モデル、つまりLLMに対して、どのように文脈を設計すればよいのかを知りたい人が多いはずです。ここで最初に押さえたいのは、プロンプトは重要ですが、AI Agentではそれだけでは不十分だという点です。

大規模モデルは、入力された文章をもとに次の出力を作ります。単発の質問であれば、プロンプトの書き方だけでもかなり改善できます。しかしAI Agentの場合、途中で検索し、コードを実行し、ファイルを読み、失敗し、再試行し、結果をまとめるような流れになります。つまり、判断材料がどんどん増えます。

Anthropicは、コンテキストエンジニアリングを「推論時に渡す情報を管理する技術」として説明しています。これは、プロンプト本文だけでなく、ツール、MCP、外部データ、会話履歴なども含みます。Manusの記事も同じ方向で、特にAI Agentでは文脈が作業ごとに増え続けるため、管理しないと性能が落ちやすいとしています。

🧠 プロンプトエンジニアリングと上下文工程の違い

比較項目	プロンプトエンジニアリング	上下文工程
主な対象	指示文の書き方	AIに渡す情報全体
向いている場面	単発回答、分類、生成	長い作業、AI Agent、ツール利用
改善ポイント	表現、順序、例示	記憶、履歴、ツール、外部保存、圧縮
失敗例	指示が曖昧	文脈が多すぎる、古い情報が残る
ゴール	よい回答を出す	よい行動を続ける

大模型上下文工程で問題になるのは、LLMの文脈窓が大きくなっても、無限ではないことです。128Kトークン以上の長い文脈を扱えるモデルもありますが、長く入れれば入れるほど良いわけではありません。Manus公式記事では、長い入力はコストが高く、モデル性能がある長さを超えると下がりやすいと説明されています。

この考え方はかなり現実的です。たとえば、AIに100ページ分の資料を全部渡したとしても、AIが常にすべてを均等に理解してくれるとは限りません。人間でも長い資料を渡されたら、重要な箇所を見落とすことがあります。AIにも似たような問題があり、Anthropicの記事では「attention budget」という考え方で説明されています。

📊 大模型上下文工程で起きやすい問題

問題	起きる理由	対策の方向
文脈が長すぎる	検索結果やツール結果を全部入れる	要約、参照化、外部保存
古い情報が邪魔になる	以前の作業ログが残り続ける	stale情報の圧縮
重要情報が埋もれる	真ん中の情報が見落とされやすい	重要目標を末尾に再掲
コストが増える	入力トークンが増え続ける	KVキャッシュ、短い表現
行動がぶれる	似た例をまねし続ける	変化、多様性、明確な状態管理

---

大模型上下文工程のポイントは、AIに「全部読ませる」のではなく、次の判断に必要な情報を最小限かつ高品質にすることです。これは、資料整理に近い考え方です。必要な資料は参照できる場所に置き、いま判断に必要な要点だけを手元に置く。Manusはこの考え方をAI Agentの構造に落とし込んでいます。

ただし、「短ければ良い」とも言い切れません。必要な前提を削りすぎると、AIは誤った判断をしやすくなります。したがって、上下文工程は単なる削減ではなく、残す情報、外に逃がす情報、あとで取り戻せる情報を分ける設計だと考えるとわかりやすいです。

特にAgent開発では、プロンプトの改善だけに時間を使うよりも、ツール結果の形式、保存先、再取得方法、エラーの残し方まで見直すほうが、効果が出る場合があるかもしれません。これは提供されたManus関連情報から見ても、かなり重要な示唆です。

Agent 上下文 工程では長い作業ループを壊さない設計が成果を左右する

「Agent 上下文 工程」で知るべきことは、AI Agentが普通のチャットボットとは違う動き方をする点です。チャットボットは質問に答えることが中心ですが、AI Agentはツールを使い、作業し、結果を見て、次の行動を選びます。この繰り返しが長くなるほど、文脈設計が重要になります。

Manus公式記事では、典型的なAgentは、ユーザー入力を受け取り、ツールを使い、観察結果を得て、それを文脈に追加し、また次の行動を選ぶと説明されています。この一連の流れは、見た目以上に文脈を膨らませます。検索結果、ブラウザ操作、コード実行、ファイルの中身などが積み上がるからです。

ここで何も工夫しないと、AIは過去の情報に引っ張られたり、目的を忘れたり、同じ失敗を繰り返したりします。Manusが「todo.md」を作る、エラーを文脈に残す、ファイルシステムを使うといった工夫をしているのは、長い作業ループを安定させるためです。

🛠️ AI Agentの基本ループ

ステップ	内容	文脈に増えるもの
1	ユーザーが依頼する	目的、条件、制約
2	AIが次の行動を選ぶ	推論、ツール選択
3	ツールを実行する	検索結果、ファイル結果、エラー
4	結果を観察する	成功/失敗の証拠
5	次の行動を選ぶ	新しい判断材料
6	完了まで繰り返す	長い履歴

Agent 上下文 工程では、「いまAIが何を見て判断しているか」を常に意識する必要があります。たとえば、最初の依頼内容が文脈の奥に埋もれてしまうと、AIは途中から別の目的に向かってしまう場合があります。Manusが目標をtodo.mdに書き直すのは、こうした問題への対策です。

また、ツール結果をすべて文脈に残すと、情報量が増えすぎます。しかし消しすぎると、あとで必要になったときに復元できません。そこでManusは、古いツール結果をコンパクト化し、必要ならファイルから再取得できるようにする方向を取っています。これは「捨てる」のではなく「参照に変える」考え方です。

📌 Agent 上下文 工程で重要な判断軸

判断軸	悪い例	よい方向
目的管理	最初の依頼が埋もれる	todoや計画で再掲する
ツール結果	全部を文脈に貼る	古い結果は参照化する
エラー	すぐ消す	再発防止の証拠として残す
ツール一覧	毎回増減させる	できるだけ安定させる
長期記憶	すべて会話に残す	ファイルや外部記憶に逃がす

---

Agentの文脈設計で難しいのは、正解が固定されていないことです。短い作業なら全部入れても問題ないかもしれません。しかし、数十分から数時間に及ぶ作業では、全部入れる方法は限界に近づきます。逆に、削りすぎると過去の根拠が消えます。

Lance Martin氏の解説では、Manusはコンテキスト削減、コンテキスト分離、コンテキストの外部化という3つの方向を使っていると整理されています。これはかなり実務的な整理です。要するに、減らす、分ける、外に置く、という3つです。

Agent 上下文 工程を理解するうえでは、AIを「答えを出す箱」ではなく、作業し続ける担当者のように見るとわかりやすくなります。担当者が作業を続けるには、机、メモ、ファイル棚、作業履歴、失敗ログが必要です。Manusの工夫は、それらをAI向けに作り直したものだといえます。

KVキャッシュを意識するとAI Agentの速度とコストを下げやすい

Manus公式記事で特に強調されているのが、KVキャッシュ命中率です。KVキャッシュとは、すごく簡単に言うと、AIがすでに読んだ文脈の一部を再利用する仕組みです。同じ前半部分を毎回読み直す必要が減るため、速度やコストに影響します。

AI Agentでは、出力より入力のほうが圧倒的に長くなりがちです。Manus公式記事では、Manusの平均的な入力と出力のトークン比率は約100対1とされています。つまり、AI Agentは「短く答える」よりも、「長い文脈を読んで少し行動する」場面が多いということです。

このとき、文脈の前半が毎回少しでも変わると、キャッシュが効きにくくなる可能性があります。たとえば、システムプロンプトの冒頭に秒単位の現在時刻を入れると、毎回違う文字列になります。Manusは、こうした小さな違いがキャッシュ効率を下げると説明しています。

⚡ KVキャッシュで意識したいこと

ポイント	理由	実務での例
プロンプト前半を安定させる	同じ前置きほど再利用しやすい	秒単位の時刻を冒頭に入れない
文脈を追記型にする	過去部分を変えるとキャッシュが崩れやすい	ログを編集せず追加する
JSON順序を安定させる	キー順の違いも差分になりうる	決定的なシリアライズを使う
キャッシュ断点を設ける	手動指定が必要な環境もある	system prompt後に区切る
セッションIDを使う	同じ作業を同じ処理系に寄せやすい	分散環境でルーティングする

Manusの記事では、Claude Sonnetの例として、キャッシュ済み入力トークンと未キャッシュ入力トークンで価格差があることにも触れています。具体的な価格は時期や提供条件で変わる可能性がありますが、少なくとも記事執筆時点の説明では、キャッシュ効率がコストに大きく効くという主張です。

ここから学べるのは、AI Agentの最適化はモデル選びだけではないということです。高性能なモデルを使っても、毎回違う巨大な文脈を投げていれば、遅く高くなりやすいです。反対に、文脈の前半を安定させ、作業ログを追記型にし、外部保存を使えば、同じモデルでも効率が変わるかもしれません。

💰 キャッシュを壊しやすい設計と改善案

キャッシュを壊しやすい設計	なぜ問題か	改善案
冒頭に現在時刻を毎回入れる	先頭近くが毎回変わる	時刻は必要な場所だけに置く
過去ログを途中で書き換える	以降の文脈が別物になる	append-onlyで残す
JSONのキー順が不安定	同じ意味でも文字列が変わる	stable sortする
ツール定義を頻繁に増減する	前半のツール領域が変わる	マスクや状態管理を使う
長文結果を毎回全文投入する	入力が重くなる	ファイル保存と参照化

---

KVキャッシュは専門的に聞こえますが、実務上の考え方はシンプルです。毎回変えなくてよい部分は変えない。これだけでもかなり重要です。AI Agentを作るとき、つい「今の状態を全部きれいに再生成して渡す」設計にしたくなりますが、それがキャッシュ効率を落とす場合があります。

また、キャッシュを意識すると、ツール定義の扱いにも影響します。ツールの追加や削除を頻繁に行うと、文脈の前半が変わりやすくなります。Manusが「Mask, Don’t Remove」と言っているのは、まさにこの問題とつながっています。

AI Agentを運用するなら、精度だけでなく、速度と費用も無視できません。特に大量のユーザーが使うサービスでは、KVキャッシュ命中率が事業上の重要指標になる可能性があります。Manusがこれを「生産段階のAI Agentで重要な指標」と見る理由は、かなり納得しやすいです。

ツールは削除せずマスクするほうが文脈の安定性を保ちやすい

Manusの上下文工程で印象的なのが、Mask, Don’t Removeという考え方です。これは、AI Agentに使わせるツールを途中で消したり追加したりするのではなく、必要に応じて使えるツールを制限する、という設計です。

AI Agentができることを増やすと、ツールの数も増えます。ブラウザ、検索、ファイル操作、シェル、コード実行、MCPツールなどを足していくと、行動空間が一気に広がります。行動空間とは、AIが次に選べる選択肢のことです。選択肢が多すぎると、人間でも迷います。AIも同じように、間違ったツールを選びやすくなります。

そこで一見よさそうなのが、必要なときだけツールを読み込む方法です。しかしManus公式記事では、ツール定義を途中で追加・削除すると、KVキャッシュが壊れやすく、過去の行動履歴との整合性も崩れやすいと説明されています。過去に使ったツールが、現在の文脈では定義されていないと、AIが混乱する可能性があります。

🧰 ツール管理の考え方

方法	メリット	デメリット
全ツールを常に見せる	実装が単純	選択肢が多すぎて迷いやすい
必要なツールだけ動的に追加	文脈上は軽く見える	キャッシュや履歴整合性が崩れやすい
ツールを削除せずマスク	定義を安定させやすい	制約設計が必要
ツール名にprefixを付ける	グループ制御しやすい	命名ルールが必要
少数の汎用ツールに寄せる	迷いにくい	ツール内での設計が重要

Manusは、ツールを消すのではなく、状態に応じて選べるツールを制限する方向を取っています。たとえば、ユーザーから新しい入力が来た直後は、いきなりツールを実行するのではなく、まず返答する必要があるかもしれません。その場合、ツール呼び出しを抑制するような制約をかけます。

また、Manusではツール名に一貫したprefixを付ける工夫も紹介されています。たとえば、ブラウザ関連はbrowser_、シェル関連はshell_のようにすることで、特定の状態では特定グループのツールだけを選びやすくできます。これは、ツールの数が増えるほど効いてくる設計です。

🎛️ マスク設計が効きやすい場面

場面	起きがちな問題	マスクの使い道
ユーザー入力直後	勝手にツール実行する	まず返信を強制する
ブラウザ調査中	シェルなど不要な操作を選ぶ	browser系に限定する
ファイル整理中	関係ない外部操作をする	filesystem系に寄せる
投稿前確認	外部API送信してしまう	送信系を禁止する
エラー復旧時	同じ失敗ツールを繰り返す	一時的に別手段へ寄せる

---

この設計は、AI Agentを「自由に何でもできる存在」として扱うのではなく、状況ごとに適切な行動空間へ誘導する考え方です。自由度を上げれば上げるほど賢くなる、とは限りません。むしろ、必要な自由だけ残すほうが、安定する場合があります。

ただし、マスクしすぎるとAIの能力を狭めてしまう可能性もあります。Manusの考え方は、ツールを物理的に削除するよりは、定義を保ったまま選択を制御するというものです。これは、キャッシュ効率と履歴整合性を両立しやすい折衷案だといえます。

AI Agent開発では、ツール追加を機能拡張だと考えがちです。しかし、ツールが増えるほどAgentは迷いやすくなるかもしれません。したがって、今後のAgent設計では、「何を使えるようにするか」だけでなく、いつ使えないようにするかも重要になるはずです。

ファイルシステムを文脈として使うと長文脈の限界を避けやすい

Manusの上下文工程で最も実用的な発想のひとつが、ファイルシステムを文脈として使うという考え方です。これは、AIにすべての情報を会話文脈として渡すのではなく、必要な情報をファイルに保存し、必要なときに読み出す設計です。

AIのコンテキストウィンドウは大きくなっていますが、無限ではありません。しかも、長くなればなるほどコストが増え、AIの注意も散りやすくなる可能性があります。Manus公式記事では、ウェブページやPDFのような非構造データは観察結果が巨大になりやすいと説明されています。

そこで、全文をずっと会話文脈に残すのではなく、ファイルパスやURLなどの参照を残す方法が有効になります。必要になれば、AIがそのファイルやURLを再度読みます。つまり、情報を消すのではなく、取り戻せる形で外に置くわけです。

📁 ファイルシステムを文脈にするメリット

メリット	内容
容量に余裕がある	会話文脈より多くの情報を保存しやすい
永続化しやすい	作業途中の記録を残せる
再取得できる	必要なときに読み直せる
構造化できる	フォルダやファイル名で意味を持たせられる
AIが操作できる	読む、書く、検索する、更新する動きができる

この発想は、人間の作業にも似ています。人間はすべてを頭の中に入れて作業するわけではありません。メモを取り、フォルダに資料を入れ、必要なときに検索します。AI Agentも同じように、外部記憶を持つことで、長い作業を安定させやすくなります。

Lance Martin氏の解説でも、Manusはツール結果のフル版をサンドボックスに保存し、文脈にはコンパクトな参照を残すと整理されています。古くなったツール結果は、全文ではなくファイルパスなどに置き換える。これにより、文脈を減らしながら、必要なら復元できます。

🗂️ 全文保持と参照保持の比較

方式	よい点	注意点
全文を文脈に残す	AIがすぐ読める	長くなり、コスト増、注意散漫になりやすい
要約だけ残す	短くできる	細部が失われる
ファイル参照を残す	復元しやすい	再読込の手間がある
URLを残す	Web情報を再取得できる	ページ変更や削除の可能性がある
構造化メモを残す	意味を保ちやすい	書き方の設計が必要

---

重要なのは、Manusが「不可逆な圧縮」を避けようとしている点です。要約は便利ですが、要約した瞬間に細部が消えることがあります。あとでその細部が重要になっても、元情報がなければ戻れません。だから、URLやファイルパスを残すことが大切になります。

もちろん、ファイルシステムを使えばすべて解決するわけではありません。ファイル名が雑だと、AIがどれを読めばよいかわからなくなります。フォルダ構造が乱れていれば、人間と同じように迷います。そのため、ファイルシステムを文脈にするには、名前、場所、更新ルールも設計対象になります。

CursorやClaude Codeのような開発支援Agentにも、この考え方はかなり関係します。コードベース全体を一度に読み込ませるのではなく、必要なファイルを検索し、関連箇所だけ読み、必要に応じてメモを残す。この流れは、まさに上下文工程の実践例といえます。

manus 上下文 工程の実践知

1. todo.mdのように目標を復唱するとAI Agentの注意を戻しやすい
2. エラーを消さずに残すと同じ失敗を避ける材料になりやすい
3. Few-shotは便利だが同じ型を見せすぎるとAgentの行動が固まりやすい
4. Cursor 上下文 工程ではコード全体より必要箇所を探す設計が重要になる
5. サブエージェントは役割分担より文脈分離のために使うと考えやすい
6. モデル選びは性能だけでなくキャッシュ効率と作業内容で考えるべきである
7. 総括：manus 上下文 工程のまとめ

todo.mdのように目標を復唱するとAI Agentの注意を戻しやすい

Manusの公式記事でわかりやすい工夫として出てくるのが、複雑なタスクでtodo.mdを作り、作業が進むたびに更新する動きです。これは単なる作業メモではなく、AI Agentの注意を目的に戻すための仕組みとして説明されています。

AI Agentは長い作業をしていると、最初の目的を忘れたり、途中で得た情報に引っ張られたりすることがあります。人間でも長い調査をしていると、最初に何を調べていたのか曖昧になることがあります。AIにも似たような問題があるため、目標を定期的に見える場所へ戻す必要があります。

Manusは、todoリストを更新することで、目標や進捗を文脈の末尾近くに置き直します。LLMは直近の文脈に影響を受けやすい傾向があるため、作業目的を最近の情報として再提示することは、目標のずれを減らす助けになります。

📝 todo.mdが果たす役割

役割	内容
目的の再掲	最初の依頼を忘れにくくする
進捗管理	完了/未完了を明確にする
注意の誘導	直近文脈に重要事項を戻す
作業の分解	大きなタスクを小さくする
復旧の補助	中断後に再開しやすくする

ただし、todo.mdにもコストがあります。Lance Martin氏の解説では、Manusは当初todo.mdを使っていたものの、かなりの行動がtodo更新に使われたため、専用のplanner agentに移行したと紹介されています。これは重要な補足です。todo更新は有効ですが、更新しすぎると作業そのものを圧迫します。

したがって、todo.mdの考え方は「毎回細かく更新すればよい」ではありません。重要なのは、AIが迷子にならない頻度で、目的と次の作業を見える場所に戻すことです。人間の進捗メモと同じで、過剰に細かいと逆に作業が遅くなります。

✅ todo.mdを使うなら意識したい運用

運用	ねらい
大きな目的を1行で残す	作業の方向を固定する
次にやることを3〜5個に絞る	選択肢を増やしすぎない
完了した項目を短く残す	進捗と重複防止に使う
長文ログを書きすぎない	todo自体を重くしない
必要なら別ファイルに詳細を逃がす	文脈を軽く保つ

---

この発想は、AIツールを使う側にも応用できます。たとえば、長い依頼をする場合、途中で「現在の目的は○○、完了条件は○○、次は○○を確認」と短く再提示すると、AIの回答が安定することがあります。これはManusのtodo.md的な使い方に近いです。

一方で、AIに何度も同じ目標を長文で貼り直すと、文脈が重くなります。必要なのは、短く、明確で、更新された目標です。長い背景説明はファイルや参照に置き、今見るべき目標だけを手元に置くと考えるとよいでしょう。

Manus 上下文 工程の本質は、AIの注意をただ信じるのではなく、注意が向く場所を設計することにあります。todo.mdは、そのわかりやすい実装例です。

エラーを消さずに残すと同じ失敗を避ける材料になりやすい

AI Agentの設計で意外に重要なのが、エラーを消さないことです。Manus公式記事では、Agentは失敗するものであり、失敗はループの一部だと説明されています。これはかなり現実的な見方です。

AI Agentは、ツールを間違って使うことがあります。外部サービスがエラーを返すこともあります。コード実行で例外が出ることもあります。ここでエラーをすぐ隠したり、履歴から消したりすると、AIはなぜ失敗したのかを見られません。その結果、同じ失敗を繰り返す可能性があります。

Manusは、失敗した行動と、その結果としての観察やスタックトレースを文脈に残すことで、AIが内部的に次の行動を調整しやすくなると説明しています。これは、AIにとって失敗ログが「次は同じ道を避けるための証拠」になるという考え方です。

⚠️ エラーを残す意味

エラー情報	AIにとっての意味
失敗したコマンド	その手段がうまくいかなかった証拠
エラーメッセージ	原因の手がかり
スタックトレース	失敗箇所の特定材料
外部APIの応答	制約や拒否理由の確認
再試行履歴	同じ方法を避ける判断材料

これは人間の仕事でも同じです。失敗ログを残しておけば、次に同じ問題が起きたときに原因を探しやすくなります。反対に、失敗の痕跡を毎回きれいに消してしまうと、同じ問題を何度も調べ直すことになります。

ただし、すべてのエラーを永遠に全文で残す必要はありません。長いスタックトレースや巨大なログは、文脈を圧迫します。実務では、エラーの要点を文脈に残し、詳細ログはファイルに保存する形が扱いやすいかもしれません。

🧯 エラー保持の設計例

残す場所	残す内容	向いている用途
直近文脈	短いエラー要約	次の一手の判断
ファイル	フルログ、スタックトレース	詳細調査
todo/進捗メモ	対応済み/未対応	作業管理
状態管理	失敗回数、禁止手段	再試行制御
最終レポート	原因と対策	人間への共有

---

エラーを隠さない設計は、AI Agentの復旧力に関係します。タスク成功率だけを見ると、失敗を見えないようにする設計のほうがきれいに見えるかもしれません。しかし、長い作業では、失敗から回復できるかどうかが重要です。

Manus公式記事でも、エラー回復は真のAgent的なふるまいを示す指標のひとつだとされています。これは、成功したときだけ賢く見えるAIではなく、失敗したあとに立て直せるAIが重要だという意味です。

AI Agentを作る側は、エラーを「消すべき汚れ」と見るより、次の判断に使える材料と見るほうがよさそうです。ただし、個人情報や機密情報を含むエラーは扱いに注意が必要です。一般的には、必要な証拠だけ残し、不要な機密情報はマスクする設計が望ましいでしょう。

Few-shotは便利だが同じ型を見せすぎるとAgentの行動が固まりやすい

Few-shot promptingは、AIにいくつかの例を見せてから回答させる方法です。これは多くの場面で有効です。しかしManus公式記事では、Agentシステムではfew-shotが逆効果になることもあると指摘されています。

理由は、AIが文脈内のパターンをまねしやすいからです。たとえば、同じような行動と観察のペアが何度も続いていると、AIはそれを「今後も続けるべき型」と見なす可能性があります。最初は正しかった型でも、状況が変われば不適切になることがあります。

Manusの記事では、20件の履歴書レビューのような反復作業で、Agentがリズムにはまり、似た行動を繰り返しやすくなる例が紹介されています。これは非常にわかりやすい問題です。AIは一貫性を出そうとする一方で、必要な差分を見落とすことがあります。

🔁 Few-shotが効く場面と危ない場面

場面	効きやすさ	注意点
出力形式をそろえる	高い	形式に引っ張られすぎることがある
分類基準を教える	高い	例が偏ると判断も偏る
反復レビュー	中	同じ評価を繰り返しやすい
ツール操作の例示	中	古い操作をまねることがある
状況が変わる作業	低〜中	過去例が邪魔になることがある

Manusの対策は、行動や観察に少しだけ構造的な変化を入れることです。異なるシリアライズ形式、別表現、順序やフォーマットの小さなゆらぎなどを入れることで、AIが単一パターンに固まりすぎるのを避ける狙いです。

これは、「ランダムにぐちゃぐちゃにする」という意味ではありません。むしろ、制御された範囲で多様性を持たせるという考え方です。AIにとって、均一すぎる文脈は強すぎる暗黙の指示になりえます。

🎨 文脈に多様性を持たせる工夫

工夫	目的
例の種類を増やす	1つの型への過剰適応を避ける
成功例と注意例を混ぜる	判断の幅を持たせる
表現を少し変える	文章パターンの固定を避ける
順序を固定しすぎない	位置バイアスを弱める
判断理由を含める	表面形式ではなく基準を学ばせる

---

この話は、AIに指示を出すユーザーにも関係します。たとえば、同じ形式の例を大量に貼ると、AIはその形式に強く引っ張られます。フォーマットを守らせたい場合は便利ですが、柔軟な判断が必要な場面では逆効果になる可能性があります。

Agentの場合はさらに複雑です。単なる回答ではなく、行動そのものが過去パターンに引っ張られるからです。検索、クリック、ファイル読み込み、評価、要約などが同じリズムになり、状況に応じた判断が弱くなるかもしれません。

Few-shotは強力ですが、万能ではありません。Manus 上下文 工程の視点では、few-shotは「よい例を見せる技術」であると同時に、文脈内に強い行動パターンを作ってしまう技術でもあります。そのため、使いすぎには注意が必要です。

Cursor 上下文 工程ではコード全体より必要箇所を探す設計が重要になる

「Cursor 上下文 工程」と検索する人は、AIコーディングツールにおけるコンテキスト管理を知りたいのだと思います。Cursorそのものの詳細仕様は提供データ内では限定的ですが、ManusやClaude Codeに関する情報から、一般的な開発Agentの文脈設計はかなり推測できます。

コード開発では、プロジェクト全体をAIに読ませたくなります。しかし、コードベースが大きい場合、全ファイルを文脈に入れるのは現実的ではありません。Anthropicの記事では、Claude Codeがglobやgrepのような基本的な検索手段を使い、必要な情報をjust-in-timeで取り込む考え方が紹介されています。

この考え方はCursor的な開発体験にも近いはずです。AIがコード全体を丸暗記するのではなく、ファイル名、ディレクトリ構造、検索結果、関連箇所を手がかりに、必要な情報を段階的に読む。これが開発における上下文工程の基本になります。

💻 開発Agentにおける文脈の種類

文脈	例	入れ方の考え方
依頼内容	バグ修正、機能追加	常に見える場所に置く
関連ファイル	対象コード、テスト	必要箇所だけ読む
プロジェクトルール	README、CLAUDE.md等	最初に確認する
エラー	テスト失敗、ログ	消さずに要点を残す
差分	変更したコード	最終確認に使う

Cursor 上下文 工程で重要なのは、コードの全文ではなく、関連するコードを見つける能力です。AIにとって、ファイル名やフォルダ構造は重要なヒントになります。tests/にあるファイルとsrc/にあるファイルでは、同じ名前でも意味が変わります。

また、開発Agentでは、エラー保持も非常に重要です。テストが失敗したとき、そのログを消してしまうと、AIはなぜ失敗したのかわかりません。逆に、失敗ログを短く残し、該当テストやコードを読み直せば、修正の方向を選びやすくなります。

🧪 Cursor的な開発AIで避けたい文脈設計

避けたい設計	起きやすい問題	改善の方向
全ファイルを一括投入	文脈が膨らみすぎる	検索して関連箇所だけ読む
エラーを毎回リセット	同じ失敗を繰り返す	失敗ログを残す
目的を書かずに修正開始	余計な変更が増える	目的と完了条件を明示
ツールを増やしすぎる	操作選択がぶれる	基本ツールを中心にする
古いルールを放置	実装とドキュメントがずれる	実態とルールを照合する

---

Manusの「ファイルシステムを文脈にする」という発想は、開発Agentでは特に自然です。コードは最初からファイルシステム上にあります。AIは必要なファイルを探し、読み、編集し、テストし、結果を見て次の修正をします。この流れ自体が上下文工程です。

ただし、開発Agentにすべて任せる場合でも、最初の目的設定は重要です。「何を直すのか」「どこまで触ってよいのか」「テストは何を通すのか」を明確にすることで、AIが無関係なリファクタへ走るリスクを下げられます。

Cursor 上下文 工程を一言でまとめるなら、コードを全部見せるより、探し方と保持の仕方を設計することです。AIが必要な情報へたどり着けるようにし、失敗から学べるようにし、目的を見失わないようにする。それが実用上のポイントになります。

サブエージェントは役割分担より文脈分離のために使うと考えやすい

Manus関連の解説で興味深いのは、サブエージェントを「人間のような役割分担」としてではなく、文脈分離の手段として見ている点です。これは、AI Agent設計でかなり重要な視点です。

人間の組織では、デザイナー、エンジニア、プロジェクトマネージャーのように役割で分けます。しかしAIの場合、人間と同じ認知制約を持つとは限りません。Lance Martin氏の解説では、Manusのマルチエージェント設計の主目的は、役割の擬人化ではなく、コンテキストの分離だと整理されています。

長い作業では、ひとつのAgentにすべての履歴を持たせると文脈が重くなります。そこで、特定の小タスクを別のAgentに渡し、そのAgentは独自の文脈で作業します。親Agentは必要な結果だけ受け取る。これにより、メイン文脈を軽く保てます。

👥 サブエージェントの使い方

使い方	目的	注意点
小タスクを任せる	メイン文脈を汚さない	指示を明確にする
調査だけ分離する	大量情報を別窓で処理	結果形式を決める
実行だけ任せる	作業ログを分ける	共有ファイルの整合性に注意
レビューを任せる	別視点を得る	同じ情報を見せすぎない
長時間処理を分ける	文脈肥大を避ける	戻り値を要約する

Manusでは、plannerがタスクを割り当て、executor sub-agentが作業するような設計が紹介されています。単純なタスクでは、親Agentが指示だけ渡して、結果だけ受け取れば十分です。一方、複雑なタスクでは、共有ファイルやフル文脈を渡す必要がある場合もあります。

ここで難しいのが、文脈共有の粒度です。渡す情報が少なすぎると、サブエージェントは判断できません。渡しすぎると、文脈分離の意味が薄れます。したがって、タスクの種類に応じて、指示だけ渡すのか、関連ファイルを渡すのか、フル文脈を共有するのかを選ぶ必要があります。

📦 文脈共有の粒度

粒度	向いているタスク	例
指示だけ	独立した小作業	1ページ要約、特定ファイル確認
指示＋参照	少し背景が必要	関連資料を読んで比較
共有ファイル	成果物を共同で扱う	レポート作成、コード編集
フル文脈	複雑な判断が必要	長期計画、広範囲調査
結果スキーマ指定	親Agentが整理したい	JSONや表で返す

---

サブエージェントは便利ですが、増やせば良いわけではありません。Agentが増えると、結果の統合、文脈共有、ファイル競合、判断責任の整理が必要になります。人間のチームでも、人数が増えれば調整コストが増えるのと似ています。

Manusの実践から学べるのは、サブエージェントを擬人化しすぎないことです。「リサーチャー」「編集者」「監督」のように名前を付けること自体は便利ですが、本質はそこではありません。何の文脈を分け、何を返させるかが重要です。

AI Agent設計では、サブエージェントは文脈の部屋を分ける仕組みとして考えると理解しやすくなります。メインAgentの机の上を散らかさないために、別室で調査や処理を行い、必要な要点だけ戻す。これが上下文工程におけるサブエージェントの価値です。

モデル選びは性能だけでなくキャッシュ効率と作業内容で考えるべきである

AI Agentを作るとき、つい「どのモデルが一番賢いか」に注目しがちです。しかしManus関連の情報を見ると、モデル選びは性能だけでなく、作業内容、コスト、キャッシュ効率、マルチモーダル適性などで考える必要があるとわかります。

Lance Martin氏の解説では、Manusは単一モデルに固定するのではなく、タスクレベルでモデルを使い分けると紹介されています。たとえば、コーディング、マルチモーダル、数学・推論などで向いたモデルを選ぶという考え方です。具体的な最適モデルは時期によって変わるため、ここでは一般論として捉えるのがよいでしょう。

また、KVキャッシュ効率もモデル選びに関係します。オープンソースモデルを自前で動かせば安いように見える場合もありますが、分散KVキャッシュや運用負荷まで考えると、フロンティアモデルのほうが実用上安くなるケースもあるかもしれません。これはタスク量やインフラ構成次第です。

🤖 モデル選びで見るべき軸

軸	見るポイント
推論性能	複雑な判断に耐えられるか
コーディング性能	コード修正やテスト理解が得意か
マルチモーダル	画像、PDF、画面理解が必要か
キャッシュ対応	長いAgentループで効率が出るか
コスト	入力、出力、キャッシュ価格のバランス
レイテンシ	ユーザー体験に耐える速度か
運用性	監視、ログ、障害対応がしやすいか

Manus公式記事の根底には、モデルの進化を前提にした設計思想があります。モデルが進化するなら、Agent側の構造を固定しすぎると、かえって新しいモデルの能力を邪魔する可能性があります。これは「Bitter Lesson」とも関係する考え方として、Lance Martin氏の解説でも触れられています。

つまり、現在のモデルの弱点を補うために複雑な仕組みを作り込みすぎると、将来の強いモデルではその仕組みが足かせになるかもしれません。一般的には、必要な構造は入れつつ、モデルが賢くなったときに外せる余地を残す設計が扱いやすいです。

📈 モデル進化を前提にしたAgent設計

設計方針	理由
まずシンプルに作る	後で改善しやすい
評価を用意する	強いモデルで伸びるか確認できる
過剰なルールを避ける	モデル能力を邪魔しにくい
文脈管理を明示する	問題箇所を切り分けやすい
モデルごとに比較する	ハーネスの限界を見つけやすい

---

ここでいうハーネスとは、AI Agentを動かす周辺の仕組みです。プロンプト、ツール、状態管理、メモリ、評価、ログなどを含むと考えるとよいでしょう。モデルが強くなっても成果が伸びない場合、モデルではなくハーネスがAIの能力を制限している可能性があります。

そのため、AI Agentを作るなら、モデルを変えたときの性能変化を見ることが大切です。強いモデルにしても改善しないなら、文脈設計、ツール設計、評価方法が詰まっているかもしれません。これはManusの上下文工程から得られる実務的な教訓です。

モデル選びは「一番高性能なものを選ぶ」ではなく、作業に合うモデルを、文脈設計とセットで選ぶことが重要です。AI Agentでは入力文脈が非常に長くなりやすいため、キャッシュ効率やツール利用の安定性も、モデル性能と同じくらい大事になる場合があります。

総括：manus 上下文 工程のまとめ

最後に記事のポイントをまとめます。

1. manus 上下文 工程とは、AI Agentに渡す文脈全体を設計する考え方である。
2. 上下文は中国語でコンテキストを意味し、日本語ではコンテキストエンジニアリングに近い概念である。
3. プロンプトエンジニアリングは指示文が中心だが、上下文工程はツール、履歴、ファイル、エラー、計画まで含む。
4. AI Agentはツール利用と観察を繰り返すため、文脈が長くなりやすい。
5. 文脈が長すぎると、コスト増、速度低下、注意散漫が起きやすい。
6. ManusはKVキャッシュ命中率を重視し、プロンプト前半の安定性や追記型文脈を重んじている。
7. ツールは途中で削除するより、定義を安定させたままマスクする設計が有効である。
8. ファイルシステムを外部記憶として使うと、情報を消さずに文脈を軽くしやすい。
9. todo.mdのような目標の復唱は、AI Agentの注意を目的へ戻す手段である。
10. エラーを消さずに残すことは、同じ失敗を避けるための証拠になる。
11. Few-shotは便利だが、同じ型を見せすぎるとAgentの行動が固定化しやすい。
12. Cursor 上下文 工程では、コード全体を入れるより必要箇所を探して読む設計が重要である。
13. サブエージェントは擬人的な役割分担より、文脈分離のために使うと考えやすい。
14. モデル選びは性能だけでなく、キャッシュ効率、作業内容、運用コストとセットで考えるべきである。
15. Manusの実践から見ると、AI Agentの品質はモデルの賢さだけでなく、文脈の作り方で大きく変わる可能性がある。

記事作成にあたり参考にさせて頂いたサイト

• https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
• http://rlancemartin.github.io/2025/10/15/manus/
• https://manus.im/zh-tw/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
• https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
• https://zhuanlan.zhihu.com/p/1929699640745394675
• https://medium.com/@peakji/context-engineering-for-ai-agents-lessons-from-building-manus-71883f0a67f2
• https://zhuanlan.zhihu.com/p/1929909827557109948
• https://x.com/dotey/status/1947084839221370921
• https://mp.weixin.qq.com/s/syRB9sHRvN7ZGqSFdRG9Iw

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。