AIエージェントの能力ルーティング：AutoAttach、Suggest、FallbackでAndroid操作を選ぶ実践ガイド

Androidの依頼を能力候補へ変える

AIエージェントの能力ルーティングとは、ユーザーの依頼を読んで、今使うべき能力候補を選び、実行前の正しい状態へ渡す仕組みです。たとえばユーザーがAndroid上で「この画面の内容を見て、あとで確認するメモにして」と頼んだとします。この依頼には、現在画面の文脈、画面読み取り、要約、メモ作成、保存前確認、失敗時の戻り道が含まれます。エージェントは最初から全Tool、全Skill、全Pluginを会話に読み込むのではなく、この依頼に関係する候補を絞ります。

候補は一つとは限りません。画面の内容を添付する能力、メモを作るTool、既存のWorkflow、ユーザーが以前作ったSkill、関連Pluginが候補になります。ここでのランキングは「近そうな名前」だけでは決めません。現在画面が必要か、既に有効な能力か、依存関係が満たされているか、権限が必要か、影響のある操作か、結果をユーザーに見せられるかを見ます。

重要なのは、意味的に合っていることと、実行してよいことを分ける点です。「メモ作成」に近い能力が見つかっても、それだけで保存を実行してよいわけではありません。能力ルーティングは、候補を見つけ、必要な文脈を添付し、ユーザーに選択肢を出し、対応外ならFallbackへ進むための段階です。実際のAndroid操作には、権限、承認、実行、結果確認が続きます。

Tool、Plugin、Skill、Workflow、Shortcutの一般的な違いを先に整理したい場合は、FoneClawのTool、Plugin、Skill、Workflow、Shortcutの違い：Androidエージェントの能力レイヤーを選ぶ実用ガイドが役に立ちます。本記事では用語集ではなく、一つのAndroid依頼が候補選択から実行前の状態へ進む仕組みに絞ります。

AutoAttach、Suggest、Fallbackを使い分ける

能力候補が見つかった後、ルーターはAutoAttach、Suggest、Fallbackのどれで進むかを決めます。この三つは似ていますが、役割ははっきり違います。AutoAttachは、高い信頼度で必要だと判断できる文脈や能力メタデータを自動的に添付する経路です。Suggestは、複数候補や影響のある選択をユーザーに見せ、選ばせる経路です。Fallbackは、一致が弱い、能力がない、依存関係が古い、権限が足りない、対象が曖昧なときに安全に続ける経路です。

先ほどの「この画面の内容を見て、あとで確認するメモにして」という依頼なら、現在画面の添付はAutoAttachに近い候補です。ただし、ユーザーが画面内容を使う操作を明示した場合に限ります。メモ作成先が複数ある場合や、既存のWorkflowと新規メモToolのどちらを使うか迷う場合はSuggestが自然です。画面が読めない、メモ権限がない、対応するToolが無効になっている場合はFallbackで止め、何が足りないかを説明します。

AutoAttachとSuggestの違いは、実行の有無ではなく、ユーザー選択の必要性です。AutoAttachは、低リスクで明らかに必要な文脈を補うために使います。Suggestは、候補選択そのものをユーザーに見せるために使います。どちらも承認の代わりではありません。能力ルーティングの段階で「この候補がよさそう」と分かっても、Android上の影響ある操作には別の確認が必要です。

この設計は、GitHub CopilotのAgent finderに関する告知にも通じる発想です。関連リソースをその場で見つけて順位づけることは有用ですが、発見されたからといって自動的にインストールや実行が行われるわけではありません。FoneClawでも、発見、候補提示、アクティベーション、承認、実行を分けて扱います。

発見、添付、アクティベーション、承認、実行を分ける

能力ルーティングで最も危険な混同は、「見つかった」「添付された」「有効になった」「承認された」「実行された」を同じ状態として扱うことです。実際には、これらは別の状態です。発見は、候補が存在することを知る段階です。添付は、モデルが判断できるように文脈や能力説明を会話へ渡す段階です。アクティベーションは、PluginやSkillなどを使える状態にする段階です。承認は、特定の操作をユーザーが許可する段階です。実行は、Android上で実際にToolを動かし、結果を確認する段階です。

1. 発見：依頼と文脈から候補能力を探します。
2. 添付：必要な文脈や候補説明だけをモデルに渡します。
3. インストール：未導入のPluginや外部能力が必要な場合、別の導入手順として扱います。
4. アクティベーション：依存関係や信頼条件を満たした能力を有効にします。
5. 承認：影響のあるAndroid操作の前に、内容と理由を見せます。
6. 実行：対応済みToolやWorkflowを実行します。
7. 結果確認：画面や状態を見て、完了、失敗、復旧を分けます。

Google DevelopersのAgent Pluginsに関する説明では、Agent SkillsやMCP serversをパッケージ化するための仕様が紹介されています。こうしたパッケージングの流れは、能力を配布しやすくします。ただし、パッケージが見つかること、metadataが整っていること、インストールされること、信頼されること、実行が承認されることは別です。

FoneClawの製品設計でも、この状態分離を大切にしています。Pluginが候補に上がっても、即座に導入したり実行したりしません。Skillを学習する場合も、プレビューと確認を通じて、まず無効なdraftとして保存する流れを使います。Android上の実行はさらに別で、権限、承認、結果確認を必要とします。

レジストリ発見や信頼判断の深い話は、Agentic Resource Discoveryとは：ai-catalog.json、検証、スマホ操作の認可を分けて考えるで扱っています。本ページでは、見つかった能力をAndroidの依頼にどう結びつけるかに集中します。

manifest、依存関係、文脈メタデータ、信頼度を安全に使う

能力ルーターが安定して動くには、入力が必要です。代表的なのはmanifest、依存関係、文脈メタデータ、信頼度です。manifestは、能力の名前、対象、できること、必要な権限、実行条件を伝えます。依存関係は、その能力を使う前に必要なPlugin、設定、アカウント、端末権限を示します。文脈メタデータは、現在画面、アプリ、ユーザーの依頼、直前のタスク状態、添付された内容を整理します。

ただし、metadataは信頼の代わりになりません。manifestに「メモ作成」と書いてあっても、その能力が現在の端末で使えるか、依存関係が満たされているか、ユーザーが承認したかは別です。ルーターは、候補の意味的な近さだけでなく、利用可能性と状態を見ます。依存関係が未解決ならSuggestまたはFallbackへ進みます。部分的に壊れた能力を有効にしないためには、atomic capability snapshotsの考え方が有効です。更新に失敗した場合は、中途半端な能力セットではなく、最後に受け入れられた状態を保ちます。

信頼度も慎重に扱います。高い信頼度はAutoAttachの根拠になりますが、実行許可にはなりません。中程度の信頼度はSuggestに向きます。低い信頼度や対象の曖昧さがある場合は、Fallbackで質問や代替手順を返します。たとえば「これを送って」という依頼だけでは、送信先、内容、アプリ、確認画面が不足します。候補を無理に選ぶより、足りない情報を聞き返すほうが安全です。

Skillが権限や端末状態とどう関係するかを深く見たい場合は、AIエージェントのスキル安全性：スマホ権限は実行時に確認すべき理由で、能力とAndroid権限を分けて考える理由を説明しています。能力ルーティングは、便利さだけでなく、実行時の境界を見失わないための設計です。

能力がない、古い、拒否された、曖昧なときの復旧

能力ルーティングは成功時だけでなく、失敗時の動きで品質が決まります。候補が見つからない、依存関係が古い、Pluginが無効、Skillがdraftのまま、Android権限が拒否されている、対象アプリが未インストール、候補が複数あって曖昧。こうした状態は、スマホAIエージェントでは普通に起きます。ここで無限に再試行したり、別の能力へ黙ってすり替えたりすると、ユーザーは何が起きているか分からなくなります。

候補がない場合は、できる範囲を返します。「メモ作成はできますが、指定された外部アプリへの保存は対応していません」のように、対応済み操作と未対応操作を分けます。依存関係が古い場合は、能力セットの更新、Plugin activation review、または最後に受け入れられた能力セットへの維持を使います。権限が拒否されている場合は、モデル再試行ではなく、権限回復の案内が必要です。

対象が曖昧な場合は、Suggestで候補を見せます。連絡先が複数ある、似たアプリがある、保存先が複数ある、WorkflowとToolの両方で実行できる、といった場面です。ここで信頼度だけで自動決定すると、誤送信や誤保存につながります。確認すべき場面では、候補、理由、影響、次に起きることを見せます。

復旧と承認UIは密接に関係します。候補の信頼度や失敗理由をどう見せるかは、ユーザーの判断を助けます。詳しい表示設計は、AIエージェント承認UI設計：提案、信頼度、理由、タスク状態をスマホでどう見せるかで扱っています。能力ルーティングの目的は、成功時に速く進めることだけではありません。失敗時に、止まった理由と次の選択肢を分かる形で返すことです。

FoneClawで能力ルーティングを安全に適用する

FoneClawでは、Android phone-agent runtimeとして、ユーザーの依頼を100+ built-in tools、Skills、Workflows、reviewed Pluginsの候補へ整理します。私たちが重視しているのは、候補選択を便利にしながら、実行の承認を省かないことです。AutoAttach、Suggest、Fallbackは、モデルが正しい判断をしやすくするためのルーティング基盤であり、Toolを自動実行する仕組みではありません。

先ほどの依頼をFoneClawで考えると、まず現在画面の利用が必要かを見ます。ユーザーが画面内容をもとに依頼している場合、AutoAttachは現在画面の文脈を添付する候補になります。次に、メモ作成Tool、既存Workflow、関連Skillが候補になります。候補が一つで低リスクなら、そのまま実行準備へ進みます。複数の保存先や手順がある場合はSuggestで選択肢を見せます。対応能力がない場合や権限が足りない場合はFallbackで止め、できる範囲と必要な手順を説明します。

Pluginについては、候補に出ることと使えることを分けています。Plugin activationはreviewを通じて扱い、依存関係や能力スナップショットを確認します。Skill学習では、プレビューと確認を通じて、まず無効なdraftとして保存します。これにより、ユーザーが知らないうちに新しい能力が実行経路へ入ることを避けます。

実行段階では、FoneClawが対応済みAndroid操作、権限、承認、停止、結果確認、権限回復を管理します。モデルは依頼を理解し、計画を作ります。FoneClawは、Android上で何を開くか、どのToolを使うか、どこでユーザーに見せて止まるかを扱います。送信、発信、削除、共有、設定変更のような影響がある操作では、能力ルーティングで候補が高信頼になっても、承認を迂回しません。

この設計は、すべてのアプリを万能に制御するという約束ではありません。現在対応しているAndroid能力を正しく選び、未対応や不確実な場面ではFallbackを返し、ユーザーが見える形で判断できる体験を作るためのものです。私たちはFoneClawを通じて、Androidエージェントのツール選択を、便利さと制御の両方が成立する形へ進めています。

能力ルーターを設計・検証する7つの確認

能力ルーターを評価するときは、正解率だけでは足りません。候補を当てる力、誤った添付を避ける力、一致しない場面で止まる力、依存関係を扱う力、承認境界を守る力、結果を確認する力、復旧を示す力を見ます。特にfalse positiveとno-matchのテストは欠かせません。便利そうな能力を誤って添付するより、足りない情報を聞き返すほうが安全な場面があります。

1. 依頼から候補能力を3件以内に絞れるかを確認します。
2. 現在画面が不要な依頼でAutoAttachしすぎないかを確認します。
3. 複数候補がある場面でSuggestを出せるかを確認します。
4. 候補がない場面でFallbackを返し、無理に実行しないかを確認します。
5. PluginやSkillの依存関係が未解決のまま有効化しないかを確認します。
6. 承認が必要なAndroid操作を、候補一致だけで実行しないかを確認します。
7. 失敗後に、モデル再試行、権限回復、代替手順、ユーザー確認を分けられるかを確認します。

実用テストは、一つのリクエストに成功ケースと失敗ケースを用意すると分かりやすくなります。「この画面からメモを作る」は、画面あり、画面なし、メモ権限なし、候補Workflowあり、候補なしのように分けて試します。能力ルーティングは、速く候補を選ぶ技術であると同時に、実行してはいけない状態を正しく止める技術です。