The VMs Powering Mobile Agents（Instinct、Claude Code）：AIエージェント実装の詰まりどころ

description: モバイルエージェントを動かすVM基盤として注目されるInstinctとClaude Codeの実装構造を整理します。tool use・MCPとの接続、レイテンシ・権限管理・fallbackの設計上の論点を具体的に解説します。

meta description: AIエージェント構築の現場で話題のInstinct・Claude Codeによるモバイルエージェント向けVM基盤を解説。tool use・MCP連携、権限管理、fallback設計など実装上の判断材料をまとめます。

---

何が出たのか

2026年9月上旬時点で、Hacker NewsおよびRedditのr/MachineLearningで活発に議論されているのが、モバイルエージェント（スマートフォンやタブレット上でUIを自律操作するAIエージェント）を動かすためのVM（仮想マシン）基盤の設計についてです。

具体的には2つのアプローチが注目を集めています。ひとつはInstinctと呼ばれるモバイルエージェント向けのVM実行環境で、Androidエミュレータ上でエージェントがアプリを操作するセッションを隔離・管理する仕組みを提供します。もうひとつはClaude Codeがエージェントのコード実行サンドボックスとして活用しているコンテナ型VM構成で、こちらはデスクトップ・サーバー環境でのコード生成・実行ループに特化しています。

両者に共通するのは「エージェントが外部環境を操作する際に、どのVM層でセッションを管理し、権限を制御し、失敗を検知するか」という設計上の問いです。この問いに対する実装上の答えが、2026年9月時点のコミュニティで具体的に語られ始めています。

---

技術的に面白い点

セッション隔離とステート管理

Instinctが採用しているのは、エージェントのタスク単位でAndroid VMスナップショットを切り替えるアプローチです。タスク開始時にクリーンなスナップショットから起動し、タスク完了またはエラー時にそのスナップショットを破棄します。これにより、あるタスクで生じた副作用（ログイン状態の変化、キャッシュの汚染など）が次のタスクに引き継がれません。

従来のモバイルエージェント研究では、エミュレータを1インスタンス起動したまま複数タスクを連続実行するケースが多く、タスク間のステート汚染がベンチマーク結果を歪める要因として指摘されてきました。Instinctのスナップショット方式はこの問題に対する実装上の回答です。

Claude Codeのサンドボックス構成

Claude Codeが使用するコード実行環境は、コンテナ（Dockerベース）をVM的に扱う構成です。エージェントがコードを生成し、そのコードをサンドボックス内で実行し、標準出力・エラー出力をツール呼び出しの結果としてLLMに返すループが基本構造です。

注目点は、このサンドボックスがtool use（LLMがツールを呼び出す仕組み）の実行レイヤーとして機能している点です。Claude APIのtool use仕様では、ツールの実行結果をユーザーターンとしてモデルに返す必要があります。Claude Codeはこのループをサンドボックス内で自動化しており、開発者が手動でtool_resultを組み立てる手間を省いています。

MCPとの接続

MCP（Model Context Protocol）は、LLMとツール群を標準化されたインターフェースで接続するためのプロトコルです。InstinctもClaude Codeも、MCPサーバーとしてツールを公開する構成を取れるよう設計されています。

具体的には、モバイルUI操作（タップ、スクロール、テキスト入力）をMCPツールとして定義し、エージェントのLLMがそれを呼び出す形です。MCPを挟むことで、エージェントのLLMを別モデルに差し替えても、ツール定義を変更せずに済む構成が取れます。

---

既存の流れとの違い

WebAgentやAppAgentとの比較

モバイルエージェントの先行研究としてはAppAgent（2023年）やMobileAgent（2024年）が知られています。これらはスクリーンショットをLLMに渡してUI要素を特定し、ADB（Android Debug Bridge）コマンドで操作するパイプラインが主流でした。

Instinctが異なるのは、VM管理をエージェントフレームワークの外側に切り出している点です。AppAgentやMobileAgentではエミュレータの起動・終了・リセットはスクリプトで手動管理するケースが多く、長時間の自律実行には向いていませんでした。Instinctはこの管理層を明示的なインフラコンポーネントとして扱い、複数エージェントの並列実行やタスクキューの管理を可能にしています。

LangChain・LangGraphとの位置づけ

LangChainやLangGraphはエージェントの「思考ループ」（どのツールをどの順番で呼ぶか）を記述するフレームワークです。一方、InstinctやClaude Codeのサンドボックスは「ツールが実際に動く環境」を提供します。両者は競合ではなく、LangGraphでエージェントのフローを定義しつつ、実行環境としてInstinctのVMを使う構成が現実的です。

ただし、LangGraphのtool nodeとInstinctのVM APIをどう接続するかは現時点で標準化されておらず、グルーコード（つなぎのコード）が必要になります。MCPを共通インターフェースとして使うことで、このグルーコードを削減できる可能性があります。

---

エージェント実装で詰まりやすい点

レイテンシの積み上がり

モバイルエージェントのタスク実行は、スクリーンショット取得→LLM推論→操作コマンド送信→画面反映待機のループを繰り返します。1ループあたりのレイテンシが2〜5秒程度であっても、10ステップのタスクでは20〜50秒かかります。

VMのスナップショット復元にも時間がかかります。Instinctのコミュニティ報告では、スナップショット復元に3〜8秒程度かかるケースが報告されており、タスク開始のオーバーヘッドとして計上する必要があります。並列実行でスループットを上げる設計が現実的ですが、VMインスタンスのリソース消費（RAM・CPU）も比例して増えます。

権限とセキュリティの境界

モバイルエージェントがアプリを操作する際、そのアプリが持つ権限（カメラ、連絡先、位置情報など）をエージェントが間接的に行使できる状態になります。これはエージェントの意図しない操作が実データに触れるリスクを意味します。

Instinctのスナップショット隔離はステート汚染を防ぎますが、タスク実行中の操作そのものを制限する機能ではありません。実装側で「エージェントが操作してよいアプリ・画面の範囲」をホワイトリストとして定義し、それ以外の操作をインターセプト（途中で検知・遮断）する層を別途設ける必要があります。

fallbackとエラー検知

エージェントが「操作したつもりだが画面が変わっていない」状態を検知するのは意外に難しい問題です。スクリーンショットの差分比較で変化を検出する方法が一般的ですが、アニメーション中やローディング中のスクリーンショットを取得すると誤検知が発生します。

Claude Codeのサンドボックスでは、コマンドの終了コードと標準エラー出力を組み合わせてエラーを判定できますが、モバイルUI操作では「操作が受け付けられたかどうか」を確認する標準的なAPIがありません。タイムアウト＋リトライの設計と、リトライ上限に達した際のfallback（人間への引き継ぎ、タスクの中断など）を明示的に実装する必要があります。

ログと観測可能性

エージェントが何をしたかを後から追跡するためのログ設計は、実運用で必ず問題になります。スクリーンショットのシーケンス、LLMへの入出力、tool callの内容、VM操作コマンドをすべて紐付けて保存する仕組みが必要です。

ストレージコストも無視できません。スクリーンショット1枚が100〜300KB程度とすると、100ステップのタスクで10〜30MBになります。解像度の削減、差分のみ保存、一定期間後の自動削除などのポリシーを最初から設計に組み込んでおくことを推奨します。

---

Spectralの見解

1. 技術的な読み

InstinctとClaude Codeが示しているのは、「エージェントの思考ループ」と「エージェントが動く環境」を分離して設計するという方向性です。この分離は、エージェントフレームワークが成熟するにつれて標準的なアーキテクチャパターンになると見ています。MCPがツールの標準インターフェースとして普及しつつある現状を踏まえると、VM層もMCPサーバーとして抽象化される流れは自然です。ただし、2026年9月時点ではInstinctのVM管理APIとMCPの接続は実装者が自前で行う必要があり、プロダクション投入には相応の工数が必要です。

2. PoCで確認すべき点

• レイテンシの実測自社のユースケースで許容できるタスク完了時間を先に定義し、VM起動・スナップショット復元・LLM推論の各レイテンシを実測して合計が収まるかを確認してください。
• 権限スコープの定義エージェントに操作させるアプリと画面の範囲を事前に列挙し、それ以外の操作が発生した場合の検知・遮断が実装できるかを検証してください。
• fallbackの動作確認エージェントがループから抜け出せなくなるケース（無限リトライ、誤検知による誤操作）を意図的に再現し、fallbackが正しく発動するかをPoC段階で確認してください。

3. 業務・プロダクト実装に移す時のリスク

モバイルエージェントを業務システムに組み込む際の主なリスクは3点です。第一に、操作対象アプリのUI変更によるエージェントの動作不全です。アプリのアップデートでUI構造が変わると、エージェントが正しい要素を特定できなくなります。定期的な動作確認と、UI変更を検知した際の自動アラートが必要です。第二に、エージェントの誤操作による実データへの影響です。本番環境への投入前に、サンドボックス環境での十分な検証と、操作ログの監査体制を整えることが前提になります。第三に、VM基盤のコストスケールです。並列実行数が増えるとインフラコストが線形に増加するため、タスクのスループット要件とコスト上限を事前に試算しておくことを推奨します。

---

まとめ

InstinctとClaude Codeが示すVM基盤の設計は、モバイルエージェントをプロダクションで動かすための実装上の論点を具体化しています。スナップショットによるセッション隔離、tool useとMCPを介したツール接続、サンドボックス内でのコード実行ループという各要素は、それぞれ既存のエージェントフレームワークが曖昧にしてきた部分を補う役割を持っています。

実装で詰まりやすいのは、レイテンシの積み上がり、権限境界の定義、fallback設計、ログの観測可能性という4点です。これらはアーキテクチャの初期段階で設計に組み込まないと、後から修正するコストが大きくなります。

PoC段階では「エージェントが動く」ことよりも「エージェントが失敗したときに何が起きるか」を先に検証する順序が、実運用への移行を早めます。

---

Spectralでは、AIエージェントの実装設計・PoC支援・プロダクション移行の技術支援を行っています。モバイルエージェントやコード実行エージェントの導入を検討している場合は、お気軽にご相談ください。

関連論点として FlowEvo Self-Evolving Agents through the: AIエージェント実装の詰まりどころ もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。