Metaが3億ドルで買収したManus、LangChainと共にエージェント開発の核心原則を明かす

Metaによる3億ドルのManus買収は大きな話題を呼んだが、本当に注目すべきはManusがLangChainとの共同発表で明かした内容だ。実際に動くAIエージェントを構築するための本質的な原則が語られ、スタートアップにありがちな失敗と、成果を出す戦略との明確な境界線が示された。

コンテキスト腐敗というパラドックス

エージェントにはツールが必要だ。ツールが増えればできることも増える。しかし落とし穴がある。使うツールが増えるほどコンテキストは膨張し、パフォーマンスはそれに比例して低下する。

Manusはこれを**コンテキスト腐敗（Context Rot）**と呼んでいる。エージェント開発の核心にあるパラドックスだ。エージェントを強くするものが、同時にエージェントを愚かにする。

解決策はコンテキストエンジニアリング - 次のステップに必要な情報だけをモデルに見せ、それ以外は一切見せないことだ。

Manusが提示した6つの具体的テクニックを紹介する。

• Offload（退避） - トークン量の多いデータはコンテキストに保持せず、ファイルシステムに移す
• Reduce（削減） - 古くなった情報を積極的に除去する
• Compact（圧縮） - 復元可能なデータを可逆的に圧縮する（例：ファイル内容は削除してパスだけ残す）
• Summarize（要約） - 情報を不可逆的に圧縮する。ただし必ず構造化されたスキーマを通す
• Retrieve（検索取得） - 検索を通じて必要なときに必要な情報を提供する
• Isolate（分離） - 独自のコンテキストを持つサブエージェントを使う

ここでの核心的な洞察は、コンテキスト管理は「あれば嬉しい最適化」ではないということだ。エージェントがスケールするか、自重で崩壊するかを決定づけるコアアーキテクチャの設計判断そのものである。

プロダクト・マーケット・フィット前にファインチューニングするな

Manusが指摘した、スタートアップに最もありがちな失敗。それは、プロダクト・マーケット・フィットを見つける前に専用モデルを構築してしまうことだ。

理屈はシンプルだ。汎用モデルと強力なコンテキストエンジニアリングの組み合わせのほうが、はるかに速いイテレーションサイクルを回せる。早期にファインチューニングすると、まだ検証されていないユーザー行動の仮説にロックインされてしまう。

より鋭い指摘はこうだ。モデルの改善速度が、プロダクトイノベーション速度の上限を決める。ファインチューニングはそのサイクルを遅くする。コンテキストエンジニアリングは速いまま維持する。

ファインチューニングは、プロダクトが機能することを証明してからにすべきだ。それ以前の段階では、最もコストの高い時期尚早な最適化でしかない。

マルチエージェントパターン：2つの明確なアプローチ

Manusは、2つの基本的なマルチエージェントパターンを示した。それぞれ異なるタイプの作業に適している。

Communicatingパターン - サブエージェントは白紙の状態から始まる。メインエージェントが焦点を絞ったリクエストを送り、サブエージェントがそれを独立して処理し、結果を返す。コード検索やデータ取得のような、コンテキストが少なく並列化可能なタスクに最適だ。

Shared Memoryパターン - サブエージェントは会話履歴の全体を共有するが、それぞれ異なるプロンプトとツールセットで動作する。各ステップが前のステップの結果に依存するような、深いリサーチなどの複雑で相互依存性の高いタスクに最適だ。

どちらを選ぶかは機能の問題ではない。コンテキスト要件の問題だ。サブタスクが自己完結しているならCommunicating、全体像が必要ならShared Memory。この選択を間違えると、不要なコンテキストにトークンを浪費するか、必要な情報をエージェントに与えないかのどちらかになる。

ツール過多を防ぐ3層アクションスペース

ツールが多すぎるとモデルは混乱する。Manusの回答は、任意の時点でモデルに見せるものを制限するレイヤー構造だ。

Atomic Layer（原子層） - 10から20のコア機能。read、write、shell、browserなど。常に利用可能で、モデルが直接使用する。

Sandbox Utilities（サンドボックスユーティリティ） - コンバーター、リンター、フォーマッターなどのプリインストール済みCLIツール。専用ツールとしてではなく、シェル経由でモデルが呼び出す。

Packages and APIs（パッケージとAPI） - 事前認証済みのAPIキーを持つPythonスクリプト。APIの全表面をモデルに露出させることなく、外部サービスとのやり取りを処理する。

このレイヤー構造により、モデルの判断空間は管理可能な範囲に保たれる。200個のツールから選ぶ代わりに、15個のコアアクションから選択し、それ以外はシェル経由で実行する。結果として、ツール選択の精度が向上し、混乱やハルシネーションによる誤ったツール呼び出しが減少する。

評価指標を根本から見直す

GAIAのような公開ベンチマークは、実際のユーザー嗜好を反映していない。Manusの立場は明確だ。ゴールドスタンダードは、完了したセッションに対するユーザー評価（1から5のスコア）である。

3つの評価原則が示された。

1. Q&Aテストより実行テスト - エージェントが実際にサンドボックス内でタスクを完了できるかどうか。タスクについて質問に答えられるかどうかより、それが重要だ。
2. 主観的品質には人間のレビューが必要 - 視覚的な仕上がり、トーン、全体的な一貫性は自動採点できない。人の目で確認する必要がある。
3. ベンチマークスコアは必要条件だが十分条件ではない - 基本的な能力を証明するには役立つ。だが、プロダクトが優れていることの証明にはならない。

本質的な教訓

過剰な複雑さこそが敵だ。

最大のパフォーマンス改善は、複雑さを足すことではなく、取り除くことから生まれる。モデルの仕事を難しくするのではなく、シンプルにするのだ。

これこそが、MetaがManusに3億ドルを支払った理由だろう。派手な機能ではなく、本質に徹した設計哲学。不要なものを剥ぎ取り、コンテキストを徹底的に管理し、モデルが自身の状態に溺れるのではなくタスクに集中できるシステムを構築すること。

本番環境で機能するエージェントは、最も多くの機能を持つものではない。一つひとつの機能を確実に活かしきるものだ。