AIエージェントはスマホとサーバーでどう変わるか

三つの場所を別々に決める

エージェントの制御プログラムは入力を読み、モデルに問い合わせ、ツールを呼び出し、結果を保存します。このプログラムをスマホアプリで動かしながら、モデルの推論をAPIプロバイダーに依頼できます。記録の保存場所はさらに別です。日記がスマホにあることだけでは、推論の場所は分かりません。ツール操作の実行場所も別の境界です。スマホの制御プログラムはローカルファイルを編集することも、遠隔のカレンダーAPIを呼ぶこともできます。

「ローカルモデル」も、どの機器にとってローカルなのかが重要です。ノートPCのOllamaサーバーが選んだモデルを実際にローカルで動かしている場合、推論はそのPCで行われます。スマホからその接続先へつなぐだけでは、スマホ内推論とも、クラウドへの転送がないとも分かりません。以下では制御プログラムとツールの実行場所を比べます。保存、制御、推論の三層が一緒に移るとは限りません。

バックグラウンド実行にはプラットフォームの条件がある

iOSでは、任意のループを常駐サービスにはできません。バックグラウンドで使える実行時間はシステムが管理します。iOSとiPadOS 26のBGContinuedProcessingTaskは、利用者が明示的に始めた処理を、進捗表示、キャンセル、期限切れへの対応とともに継続する仕組みです。アプリを離れたあとに完了できる仕事は広がりますが、無人のタスクをいつでも開始できる許可ではありません。

Androidは、通常の非同期処理、永続的なタスク、フォアグラウンドサービスを区別します。WorkManagerは永続的なタスクを扱い、フォアグラウンドサービスには利用者への可視性や起動条件の制約があります。一部のサービス種別にはOSとターゲットのバージョンに応じた時間制限もあります。関数をasyncにするだけでは、こうした実行権限は得られません。

サーバーなら、制御プログラムはスマホアプリのライフサイクルから独立できます。それでも、動くホスト、スケジューラーやキュー、有効な認証情報、障害処理、監視は必要です。マネージドクラウドも、自宅で稼働させ続けるPCもこの役割を担えますが、運用の責任は異なります。

Apple：バックグラウンド実行と継続処理 · Android：バックグラウンド処理 · Android：サービスのタイムアウト

タスクの保存と操作の再開は同じではない

ツールがカレンダーの予定を作成したとします。作成には成功したものの、エージェントが成功を記録する前に応答が失われました。再試行すると、同じ予定がもう一つできるかもしれません。制御プログラムをサーバーへ移しても、この曖昧さは残ります。

確実に復旧するには、永続的なタスク状態に加えて、その外側で起きる操作への対処が必要です。APIが対応していれば、同じ操作識別子を使って再試行だと認識させられます。対応していないなら、実際に何が起きたか確認してから次を決める必要があります。AWSの冪等APIに関する記事は、呼び出し側が渡すリクエスト識別子の意味を説明しています。

キューが未完了のタスクを覚えていても、タスクの処理関数は最初から動き直す場合があります。モデル呼び出しやツール操作の途中から再開するには、追加の状態管理とツールごとの保証が要ります。「中断から復旧できる」を「すべての操作が必ず一度だけ実行される」に置き換えてはいけません。

AWS Builders’ Library：安全な再試行と冪等API

違いは画面にも表れる

短い振り返りなら、スマホ側の制御プログラムは選択したローカルの記録を読み、考えが新鮮なうちに追加で質問できます。ただし、ほかのすべてのアプリを自動で読めるわけではなく、権限や利用可能なインターフェースに制約されます。未同期の最新メモをサーバーのエージェントに渡すには、明確な経路が必要です。サーバーにブラウザーやコマンドラインツールを用意しても、それだけでスマホにしかない情報へアクセスできるわけではありません。

後日、旅行プランを調べる段階になれば、遠隔実行は「終わったころに戻る」体験を支えられます。結果はスマホの再接続を待てます。それでもアプリは、調査中、接続待ち、一時停止、失敗、回答待ちを意味のある状態として示す必要があります。処理が止まっても回り続けるスピナーは、そのタスクについて最も大事な事実を隠してしまいます。

制御がローカルだからといって、回答が速いとは限りません。両方が同じ遠隔モデルを呼ぶなら、推論や通信が待ち時間の大半を占める可能性があります。端末内推論では計算をスマホへ移す代わりに、その機器のメモリ、電力、発熱の制約を受けます。オフラインで記録できることと、遠隔モデルを必要とする処理までオフラインで完了できることも別です。

プライバシーと費用は処理の経路で考える

スマホ側で関連する数段落を選べば、記録全体を実行サーバーへ複製せずに済む場合があります。ただし、選ばれた文章はモデルへのリクエストとして端末を離れる可能性があります。サーバー側も権限を絞り、保存期間を制限できます。どちらも、記録、プロンプト、ツールの出力、ログ、バックアップの行き先を追うべきです。ループの実行場所だけでは判断できません。

モデルの選択も独立した判断です。接続先の選択は処理境界の選択ですが、どのプロバイダーも非公開処理やオフライン動作を保証するという意味ではありません。ワーカーをホストすれば計算・保守費用が加わり、スマホ実行では端末の資源を使い、API費用が発生することもあります。仕事の内容と測定なしに、常に安い、常に効率的とは言えません。

モデル接続を選ぶ · Memexの記録の保存場所

Memexのソースから確認できること

今回確認したリビジョンのMemexには、状態、実行の所有権、古い実行状態からの復旧、設定可能な再試行を備えた永続ローカルタスクキューがあります。バックグラウンドの調整処理がタスクとアプリのライフサイクルをつなぎます。AndroidにはWorkManagerでキューを処理する経路があり、iOSのブリッジには処理タスクと、進捗・期限切れに対応するiOS 26の継続処理経路があります。

バックグラウンドワーカーは一時停止も記録し、次の試行を手配できます。これらは中断を管理する仕組みです。無停止の実行、すべての内部ステップからの正確な再開、外部操作の重複を完全に防ぐことを証明するものではありません。ソース確認はインストール済み端末での試験ではなく、個々の公開ビルドへの対応は別途確認が必要です。

オープンソースなので、この境界を調べ、変更する余地があります。Memexの出発点は個人の記録と、その近くで動く設定可能なワークフローです。たまに生まれる個人の用事を、すべて常駐サーバーの仕事にする必要はありません。

Memexのタスクキューと復旧 · Androidのキューのスケジュール · iOSのバックグラウンドブリッジ · バックグラウンドワーカーと一時停止

未来の構成案：仕事を渡し、経緯を残す

将来は原本をスマホに残し、範囲を限定した調査を別のホストへ渡す構成が考えられます。旅行なら、選んだ日付、予算、関連する希望を送り、サーバーが出典付きの候補を返します。すべての日記を恒久的に持たせる必要はありません。

引き継ぎには、ジョブ識別子、入力時点のスナップショット、許可するツール、費用上限、次の工程の責任主体が必要です。実行中に希望を「静かな旅」から「友人との旅」に変えたらどうでしょう。戻った候補は以前の希望を使ったと示し、修正するか確認すべきで、新しい計画を黙って上書きすべきではありません。

キャンセルも、追加の調査を止めることと、済んだ操作を取り消すことを分ける必要があります。下書きは確認してから使えますが、予約には別の承認境界と重複リクエストの識別が必要です。これは設計案であり、Memexで提供済みのスマホからサーバーへの委任機能ではありません。端末内モデルが進化してもOSのライフサイクル規則はなくならず、サーバーの計算力が増えても欠けた個人の文脈は埋まりません。

まず、何を残しておきたいか

長い仕事が後に続かなくても、音声メモは残す価値があります。多くの日常では、記録し、少し話し、あとで読み返せることが役に立ちます。その経路をスマホの近くに置くのは、材料が入ってくる方法にも合っています。

散歩から数か月後、旅行調査の出発点はすでにそこにあります。何を望んでいたかが、自分の言葉で、日付と後の修正とともに残っています。長く動けるワーカーが時折の調査を引き受け、日々の記録が、その仕事のよりどころになります。

個人AIは日々の暮らしから始まる · 範囲を絞った週次レビューを試す