自己改善するPhone Agentに必要なスキル版管理・テスト・ロールバック

自己改善するPhone Agentは何を変えるのか

自己改善するPhone Agentとは、何を自分で改善するエージェントなのでしょうか。実行したタスクの結果、途中の判断、失敗地点、利用者の修正を証拠として集め、計画方法、実行を支える仕組み、再利用スキルを段階的に更新できるPhone Agentです。

ここでいう自己改善は、利用者が設定したAIモデルの重みをPhone Agentが再訓練したり、書き換えたりすることではありません。選択されたモデルは、FoneClawのエージェントワークフロー内で言語理解、推論、計画を担当します。FoneClawは、その計画を対応するAndroid操作へ移すための実行規則、検証、スキル、失敗回復を改善対象にします。

この違いを理解するには、モデル、harness、スキル、Android実行を分けると分かりやすくなります。

agent harnessとは、モデルを実用的なエージェントとして動かす周辺構成の総称です。モデルへ渡す指示、利用可能なツール、ツールを呼ぶ条件、実行順序、結果の検証規則、失敗したときの再試行や手動切り替えが含まれます。モデルを変更しなくても、この構成を改善すればタスクの成功率や回復力を高められます。

再利用スキルは、harnessの中で特定の仕事を扱う単位です。例えば「未処理の項目を確認して下書きを準備する」というスキルなら、開始条件、検索対象、変更可能な値、重要操作の確認、完了判定を持ちます。画面録画などからスキルを作る段階は、見せて教えるPhone Agent：画面録画、再利用スキル、Androidの安全性で詳しく解説しています。

モデル自体の訓練も、harness改善とは別の工程です。スマホAgent向けモデルの学習方法については、PhoneBuddy-4BとスマホAgent訓練：Mock-App RLがAndroid Agentに重要な理由で扱っています。本記事の焦点は、すでに動いているPhone Agentが、実行結果を使って周辺構成とスキルを安全に改善する方法です。

実行履歴から改善案を検証するSelf-Harness

モデルを再訓練せずに、エージェントの性能を改善できるのでしょうか。Self-Harness研究論文は、固定したベースモデルを使いながら、実行を支えるharnessを改善する三段階の方法を提案しています。

第一段階は、実行履歴から弱点を探すことです。単に失敗回数を数えるのではなく、どの判断で誤ったか、どのツール呼び出しが不適切だったか、検証が不足したか、回復手順が働かなかったかを調べます。成功した履歴も比較対象にし、失敗に共通する条件を見つけます。

第二段階では、見つけた弱点に対する範囲の限定された改善案を作ります。すべてのプロンプトやツール構成を一度に変えるのではなく、問題へ直接関係する規則、ツール説明、検証条件、回復処理を小さく変更します。変更範囲を絞れば、改善の効果と副作用を追いやすくなります。

第三段階は、改善案を採用する前の検証です。変更後に元の失敗が解消したかだけでなく、これまで成功していたタスクを壊していないかを調べます。新しい問題が発生した場合は採用せず、改善案を修正するか、元の版へ戻します。

Self-Harnessの著者は、Terminal-Bench-2.0において、三つの固定ベースモデルで未使用の評価タスクに対する成功率が向上したと報告しています。改善対象はモデルの重みではなくharnessです。この結果は、周辺構成の改善が有効になり得ることを示す研究報告であり、あらゆるPhone AgentやAndroidアプリで同じ向上幅が得られるという意味ではありません。

Salesforceによる自己改善エージェントの解説も、エージェントが経験から改善する方向と、評価・管理の必要性を扱っています。実運用では、改善案を作る能力だけでなく、どの証拠を信頼し、誰が承認し、どの版を配信するかが製品品質を決めます。

FoneClawの自己改善とモデル設定型アーキテクチャ

FoneClawは自己改善するPhone Agentなのでしょうか。はい。FoneClawは自己改善するPhone Agentであり、対応するAndroidタスクの実行結果と失敗履歴を使って、計画方法、harnessの動作、再利用スキルを管理された工程で改善できます。

利用者はFoneClawへ対応モデルを設定できます。設定モデルがFoneClawのエージェントワークフロー内で依頼を理解し、条件を整理し、手順を計画します。FoneClawは、その計画を対応するAndroid操作へ移し、現在の状態と結果を利用者が確認できる形で進めます。

自己改善の証拠になるのは、最終的な成功・失敗だけではありません。どの画面から始まったか、どの対象を選んだか、何回再試行したか、どの権限で止まったか、利用者がどこを修正したか、対象アプリで結果が確認できたかを見ます。これらをまとめることで、モデルの推論、スキル定義、Android操作、アプリ状態のどこに改善点があるかを分けられます。

例えば、あるスキルが同名の項目を誤って選んだ場合、改善案は「最初の候補を常に選ぶ」規則を削除し、追加の識別情報を確認する処理を加えることかもしれません。別の画面で要素が見つからない場合は、待機時間、再読込、画面の再確認、利用者への質問を回復手順として比較します。

FoneClawの改善は、Android権限や利用者確認を取り除く方向ではなく、必要な地点をより明確にする方向で進めます。スキルに新しいアプリやデータ種別が必要になる場合は、権限差分として確認します。送信、削除、注文、設定変更などの結果が重い操作は、変更後のスキルでも利用者確認を保ちます。

各改善には版を付けます。どの履歴を根拠に、何を変更し、必要な権限がどう変わり、どのテストに合格したかを記録します。問題が見つかった場合は、直前の安定版へ戻せます。スキルの権限設計を詳しく知りたい場合は、AIエージェントのスキル安全性：スマホ権限は実行時に確認すべき理由が参考になります。

設定モデルは理解と計画を担い、FoneClawは対応するAndroid操作と改善ライフサイクルを管理します。この分担により、モデルを選べる柔軟性と、端末操作を版管理・テスト・承認できる運用を両立します。

改善案を安全に配信する九つの工程

実行履歴から良い改善案が見つかったら、すぐ本番へ反映してよいのでしょうか。自己改善するPhone Agentでは、提案の生成より、その変更を安全に検証して配信し、必要なら戻せることが重要です。FoneClawでは、改善を次の工程へ分けて扱います。

1. 証拠を集める：成功・失敗履歴、画面状態、ツール結果、利用者の修正、完了証拠を集める。

2. 原因を切り分ける：計画、スキル、アプリ状態、権限、通信、操作対象のどこで問題が起きたかを確認する。

3. 最小の変更を提案する：問題へ直接関係する規則、ツール説明、検証、回復手順だけを変更する。

4. 回帰テストを行う：元の失敗例、既存の成功例、異なる画面・言語・データ状態で試す。

5. 権限差分を確認する：追加されるアプリ、データ、Android権限、重要操作を変更前と比較する。

6. 承認する：変更内容、テスト結果、権限差分、回復方法を確認して採用を決める。

7. 新しい版を作る：スキルとharnessへ版番号を付け、変更理由と互換性を記録する。

8. 段階的に配信する：試行範囲を限定し、読み取りや下書きなど戻しやすい操作から確認する。

9. 監視して戻す：成功率、確認回数、再試行、停止、失敗を監視し、問題があれば安定版へ戻す。

最初の証拠集めでは、一件の失敗だけを見て原因を決めません。同じ条件で再現するか、成功例との違いは何か、アプリ更新や通信遅延が関係していないかを確認します。再現しない失敗は、変更を加える前に観測方法を改善します。

回帰テストには、正常な経路だけでなく例外も含めます。対象がゼロ、一件、複数ある場合、ログアウト中、権限未設定、読み込み中、画面サイズが異なる場合を試します。送信や削除のような操作は試行モードで確定直前に止め、対象と入力値を検証します。

権限差分では、新しい版が以前より広いアクセスを要求していないかを確認します。対象アプリが増える、連絡先や位置情報が必要になる、書き込み操作が追加される場合は、機能改善とは別に承認します。サンドボックスとAndroid権限の役割は、AI Agent サンドボックスとスマホ権限：安全なAgentにも確認が必要な理由で整理しています。

版管理には、スキル本文だけでなく、使用するプロンプト、ツール定義、検証規則、必要権限、対応アプリ、確認地点、回復手順を含めます。どの構成で実行されたかを追跡できれば、障害時に問題の版を特定し、安定版へ戻せます。

段階配信では、すべての端末へ同時に適用せず、限定されたタスクや環境から始めます。読み取り、候補作成、下書きのように結果を戻しやすい操作で確認し、その後に利用者確認を伴う書き込み操作へ広げます。

自己改善が失敗する典型的なパターン

テストに合格した改善でも、実際のAndroid環境で問題になるのはなぜでしょうか。原因の誤認、一つの事例への過剰適合、アプリ画面の変化、言語差、権限の拡大など、改善工程そのものに失敗の形があります。

2026年7月のPhantom Guardrails研究論文は、改善を行う最適化システムが実在しない失敗を作り出し、それを抑えるための不要なガードレールを追加する可能性を示しています。表面上は「問題が再発しなくなった」ように見えても、もともと問題が存在しなければ、追加規則は複雑さと副作用を増やします。

この教訓から、失敗を抑えられたかだけで変更を採用する方法は不十分だと分かります。元の失敗が実際の履歴に存在するか、同じ条件で再現するか、追加した規則が無関係なタスクを妨げないかを確認します。

アプリの画面変更はPhone Agent特有の問題です。座標や特定ラベルだけに依存すると、アプリ更新、端末サイズ、表示倍率で失敗します。改善後のスキルは、対象の役割、画面の見出し、操作後の状態など、複数の手掛かりを使って検証します。

同じベンチマークを繰り返すだけでも不十分です。変更がテスト項目を覚えたような振る舞いになれば、未知の画面やデータで性能が下がる可能性があります。固定した基準テストに加え、未使用の条件、最近変更されたアプリ画面、異なる言語、実際の端末状態を評価へ取り入れます。

権限の変化は成功率だけでは評価できません。新しい版がより多くのアプリやデータへアクセスすることで成功したなら、その改善には追加の責任が伴います。必要性を説明できない権限は追加せず、代替手順や利用者入力を検討します。

Android実環境へ出す前の評価チェックリスト

自己改善したPhone Agentの変更を、本物のAndroidタスクへ適用してよいかはどう判断すればよいのでしょうか。改善率だけでなく、証拠、権限、確認、結果、回復を一つのチェックリストで確認します。

ロールバックでは、スキルファイルを前の版へ戻すだけでは足りません。変更後の版が作成した下書き、設定、予定などが端末へ残っている場合があります。どの操作まで完了したかを確認し、未確定、確定済み、取り消し可能な結果を分けます。

新しい版を停止した後は、直前の安定版へ戻し、同じタスクを重複実行しないよう現在のアプリ状態を読み直します。必要であれば、利用者が手動で結果を確認し、残りの操作だけを続けます。これがphone agent rollbackを実用的な回復手段にします。

操作履歴と版を関連付けることも重要です。どのモデル設定、スキル版、harness版、権限で実行されたかを追跡できれば、問題の範囲を特定できます。版、権限、履歴の関係については、AIエージェントのID・権限・監査ログ：スマホエージェントに必要な安全基盤が参考になります。

自己改善するPhone Agentの成熟度は、どれだけ頻繁に自分を変えられるかでは決まりません。実行結果から正しい問題を見つけ、小さく改善し、幅広くテストし、権限を確認し、承認された版を段階的に配信し、必要なら確実に戻せることが重要です。

FoneClawはこのライフサイクルを通じて、設定モデルの理解・計画と、対応するAndroid操作の間を継続的に改善します。見える結果、Androidとアプリの権限、重要操作の利用者確認、実用的な手動経路を維持しながら、Phone Agentの計画、harness、再利用スキルを育てます。