Google Antigravity SDKのローカルモデル、エージェントをオフライン化する一方でハードウェアが境界線に

GoogleはAntigravity SDKにローカルモデルを追加し、開発者がAPIキーやインターネット接続なしでエージェント型ワークフローを実行できるようにした。

最初の最適化済みルートは、Gemma 4 26B A4BとGoogle AI EdgeのLiteRTランタイムを組み合わせる。Googleは少なくとも24 GBのVRAMまたはユファイドメモリを推奨している。この要件により、ローカル実行という期待とは裏腹に、完全な体験は多くの一般的なノートPCの手の届かないものとなる。

このリリースは重要な境界を移す。開発者は、すべてのプロンプト、ソースファイル、ツール結果をホスト型モデルへ送る必要がなくなる。一方で、クラウドエージェントは導入の容易さ、より大きなモデル容量、より少ないハードウェア制約を引き続き提供する。

したがってGoogleは、クラウド専用のエージェントモデルを捨てることなく、それに挑戦している。Google自身のデモでは、Geminiのクラウドプランナーと複数のローカルGemmaワーカーを併用している。より重要なのはクラウドの全面置換ではなく、エージェントの各部分をどこで実行するかを制御できることだ。

Antigravity SDKのローカルモデルがエージェントループをデバイス上へ移す

Googleはエージェントのモデル呼び出し、ツールループ、作業コンテキストを、開発者が管理するハードウェアへ移した。

Googleは2026年9月23日にローカルモデル対応を発表した。同社によると、Antigravity SDKは現在、複数のモデルと実行オプションにわたるローカルワークフローをサポートしている。

このSDKはPythonを通じて、Google Antigravityのエージェント機能を提供する。これらの機能には、モデルとの対話、ツール、ポリシー、ワークスペース、フック、サブエージェントが含まれる。

開発者はこれまで、こうしたワークフローをリモート推論と結び付けてきた。新しい構成では、同じマシンに保存・実行されるモデルチェックポイントに対してエージェントを動作させられる。

Googleのローカルモデルリリースでは、最初の最適化済みモデルとしてGemma 4 26B A4Bが取り上げられている。LiteRTは、デバイスで利用可能なアクセラレーションハードウェアを通じて推論を処理する。

サポートされるパスでは、エージェントを.litertlmチェックポイントへ向けるLiteRTAgentConfigを使用する。SDKはループバックサーバーを起動する。これはローカルマシンのネットワークインターフェース経由でのみ利用できるサービスを意味する。

このローカルサービスは、Antigravityエージェントとモデルランタイムの間に位置する。これにより、広範なエージェントフレームワークは公開モデルエンドポイントを呼び出すことなく、チェックポイントと通信できる。

Googleによれば、得られるワークフローはAPIキーもインターネット接続もなしに実行できる。これは、選択したファイルを単にローカルへ保存する製品とは意味のある違いだ。

完全なオフライン実行であれば、モデル入力、生成トークン、ツールとのやり取りをデバイス内にとどめられる。もっとも、実際のプライバシー上の結果は、開発者が有効化するツールや統合に依然として左右される。

Web検索サービスを呼び出すエージェントは完全なオフラインではない。リモートデータベース、分析システム、ホスト型Model Context Protocolサーバーに接続するエージェントも同様だ。

SDKはLocalOpenAIAgentConfigを通じ、外部のローカルサーバーもサポートする。このルートは、開発者のマシンまたはプライベートネットワーク上でOpenAI互換APIを公開するソフトウェアに接続する。

Googleは例としてOllama、LM Studio、vLLMを挙げている。この互換性は重要だ。ローカルAIの利用者はすでに、これらのサーバーを中心にモデルと自動化を編成しているためである。

2つのルートは異なるニーズに応える。LiteRTはGoogleのランタイムを中心に最適化されたGoogle管理のパスを提供し、互換サーバーはチームにモデルホスティングのより大きな制御を与える。

Googleのローカル実行ガイドは両方の構成を文書化している。また、Apple Silicon Metal、Nvidia CUDA、そして自動検出されるアクセラレータバックエンドへの対応も確認している。

これはエディター内の単なるモデルセレクターではない。SDKにより、開発者はローカル推論を自らのスクリプト、サービス、評価システム、専門的なエージェントワークフローに組み込める。

このプログラマビリティが、記事の中心的な緊張関係を生む。推論をデバイスへ移すことで制御性は向上するが、インフラの責任もGoogleからユーザーへ移る。

オフラインエージェントがクラウド専用ワークフローに圧力をかける

このリリースは、データの局所性を製品上の制約ではなくアーキテクチャ上の選択肢にすることで、クラウド専用のエージェントプラットフォームに圧力をかける。

クラウド推論は、ほとんどのコーディングエージェントにとって依然として標準的な選択肢だ。ワークステーションクラスのGPUや長時間のモデルダウンロードを必要とせず、大規模モデルへすぐにアクセスできる。

その利便性には、利用料以外のコストもある。ソースコード、プロンプト、取得した文書、ツール出力は、リモート処理環境に入らなければならない。

プロバイダーのポリシーは、保持や学習利用を制限できる。エンタープライズ契約では、より強力な制御を追加できる。それでも、一部の組織は機密資料を承認済みのマシンやネットワークの外へ送ることができない。

最も明確な例は、エアギャップ化された開発環境だ。規制対象、機密指定、または商業上機微な情報を扱うため、これらのシステムには意図的に直接のインターネットアクセスがない。

クラウド専用のエージェントは、この環境では通常どおり動作できない。オフラインのAntigravityエージェントは、モデルとソフトウェア依存関係が承認済みの移送プロセスを通じて導入される限り、動作できる。

同じ利点は、未発表製品、セキュリティレポート、法務文書、独自アルゴリズムを扱う開発者にも当てはまる。ローカル実行は、彼らのコンテキストを受け取るシステムの数を減らす。

サービス可用性も変わる。ローカルワークフローは、モデルプロバイダーの障害、クォータ変更、エンドポイント廃止によって停止しない。

この独立性は、長時間実行されるタスクで重要になり得る。リポジトリを監査するエージェントは、ファイルの読み取り、変更の計画、テストの実行、エラーのレビューを行いながら、多数のモデルターンを実行する場合がある。

レイテンシーの挙動も異なる。ローカル推論は広域ネットワークの遅延を回避するが、トークン生成は完全に利用可能なハードウェアとランタイム最適化に依存する。

十分な装備を備えたワークステーションは、予測可能な応答時間を提供できる。最低推奨メモリに近いマシンでは、特に同時実行ワークロードの下で、はるかに遅い体験になる可能性がある。

クラウドプラットフォームには明確な利点が残る。より大きなモデル、弾力的な容量、集中監視、管理された更新を、ローカルメモリを消費せずに提供できる。

また、異なるコンピューターを使用する従業員間でパフォーマンスを標準化できる。ローカルファーストのアプローチでは、デバイス仕様が導入計画の一部となる。

したがって、このリリースはローカルAIとクラウドAIの単純な対決を確立するものではない。これらの実行環境の間に有意義な選択肢を提供しないプラットフォームに圧力をかけるものだ。

戦略的な優位性は、機密性、複雑性、利用可能な計算資源に応じて作業を振り分けられるフレームワークにある。GoogleのSDKは現在、このより広範なパターンをサポートしている。

企業にとって、判断はより細かくなる。チームは要求の厳しい計画作業にホスト型モデルを確保しつつ、反復的なファイル分析を管理下のハードウェアにとどめられる。

個人開発者も別の形の選択肢を得る。すべてのタスクをリモート認証や利用上限に結び付けたくない場合でも、エージェントワークフローを使い続けられる。

制約となるのは、適切なハードウェアへのアクセスだ。Googleは、注目されているGemmaチェックポイントに少なくとも24 GBのVRAMまたはユニファイドメモリを推奨している。

多くの主流コンピューターはこのしきい値を下回る。技術的には満たすマシンでも、オペレーティングシステム、エディター、ブラウザー、ビルドツールとそのメモリを共有しなければならない場合がある。

クラウド専用プロバイダーは、管理型推論が依然としてより利用しやすいルートだと合理的に主張できる。ローカルエージェントは自律性を高めるが、コンピューティングコストをなくすわけではない。

そのため、圧力が最も強いのは、セキュリティ意識が高く技術的に成熟したチームだ。こうした購入者は、セットアップ作業やハードウェア要件を受け入れてでも、ローカル制御を重視できる。

LiteRTとGemma 4がオフラインワークフローの仕組みを説明する

この仕組みは、疎なGemmaモデル、ローカル推論ランタイム、そして制御ループを近くに置けるエージェントフレームワークに依存している。

Gemma 4 26B A4Bは、Mixture-of-Expertsアーキテクチャを採用する。この設計では、すべてのパラメーターを有効化するのではなく、各トークンをモデルの一部だけに通す。

Googleは、このモデルについて総パラメーター数を252億、アクティブパラメーター数を38億としている。A4Bというラベルは、推論中に約40億のパラメーターがアクティブになることを指す。

この違いはローカル実行において重要だ。このモデルは、各トークンで252億すべてのパラメーターに対する密な計算を必要とせず、より大きなパラメータープールを利用できる。

ただし、チェックポイントがストレージやメモリ上で40億パラメーター分しか占めないという意味ではない。ルーティングのため、エキスパート全体の集合は利用可能な状態に保たれなければならない。

Googleによると、LiteRT形式のチェックポイントのダウンロードサイズは約16.8 GBだ。推奨される24 GBのメモリは、推論状態やその他のプロセスのための追加容量を残す。

Gemma 4モデルカードには、26B A4Bモデルのコンテキストウィンドウが最大256,000トークンと記載されている。また、テキストと画像の入力をサポートする。

大きな公称コンテキストウィンドウは、すべてのローカルマシンで快適に使えることを保証するものではない。実際のワークロードでは、より長いコンテキストほどメモリ要件と処理時間が増える。

Gemma 4にはネイティブの関数呼び出しも含まれる。関数呼び出しにより、モデルはファイルの読み取りや開発者定義ツールの呼び出しといった構造化されたアクションを要求できる。

この能力はエージェントに不可欠だ。従来のチャットボットは応答を生成するだけだが、エージェントは推論、アクション、観察、修正された判断を交互に行う。

Antigravityは周辺の制御システムを提供する。ワークスペース、利用可能なツール、実行ポリシー、ローカルモデルとの通信を管理する。

LiteRTは推論レイヤーを提供する。Googleは、サポート対象のハードウェアバックエンドにわたるオンデバイス機械学習のためにこのランタイムを設計した。

LiteRTモデルガイドでは、スマートフォンからコンシューマー向けGPU、ワークステーションに至るデバイスを想定したGemmaバリアントが説明されている。ハードウェアの対象は、このファミリー内でも大きく異なる。

Antigravity統合では、開発者はSDKとlitert-lmパッケージをインストールする。その後、モデルをLiteRTのチェックポイント形式へインポートする。

エージェントは構成を通じてモデルパスを受け取る。プログラムの開始時、SDKはローカルモデルサービスを作成し、生成されたトークンをアプリケーションへストリーミングで返す。

このアーキテクチャにより、統合は比較的なじみ深いものに保たれる。開発者は、推論サーバーとツールループを個別に構築するのではなく、引き続きエージェントをインスタンス化してタスクを送る。

代替となるOpenAI互換構成は、モデルの選択肢を広げる。チームはAntigravityを、既存のOllama、LM Studio、またはvLLMのデプロイメントへ向けられる。

OpenAI互換インターフェースは、一般的なリクエストとレスポンスの形式を標準化する。基盤となるモデルがOpenAI製であることを意味するわけではない。

この区別により、Antigravityは複数の推論スタックの上に位置付けられる。選択するローカルサーバーやモデルが変わっても、エージェントフレームワークは安定して維持できる。

互換性はランタイムレイヤーでのロックインも減らす。すでに内部サーバーでvLLMを使用しているチームは、すべてのワークフローでLiteRTを採用する必要がない。

それでもLiteRTが特に注目されるのは、Googleが最初のGemma 4パスを同ランタイム中心に最適化したためだ。この組み合わせによりGoogleは、モデル形式と実行ランタイムの両方を制御できる。

このアーキテクチャは、完全なローカル運用だけに対応するものではありません。クラウドモデルが作業を計画し、ローカルエージェントが範囲を限定したタスクを実行するハイブリッド型のオーケストレーションも可能です。

このハイブリッドという選択肢こそ、Googleのタイミングを最も明確に説明します。ローカルモデルは、最も強力なホスト型プランナーを置き換えることなく、有用なコーディング作業を担えるまでに進化しています。

Googleのハイブリッドデモが示す本当の戦略

Google自身の例は、ローカルエージェントが実行部隊となり、クラウドモデルが計画役を維持する方向性を示しています。

同社は、クラウドアーキテクトとしてGemini 3.8 Flashを使うArchitect-Builderパターンを実演しました。ローカルのGemma 4 26Bインスタンスがビルダーとして機能します。

このデモでは、auth.py、billing.py、database.pyという3つの脆弱なPythonモジュールをシステムに割り当てました。ローカルワーカーがデバイス上で監査とパッチ適用を行いました。

クラウドプランナーは、より広範なプロセスを調整します。この分担により、より大きなホスト型モデルによるオーケストレーションへのアクセスを維持しつつ、リポジトリ作業の多くをローカルに留められます。

これは、単一のローカルチェックポイントがあらゆるクラウドモデルに匹敵できると主張するよりも、はるかに信頼できる設計です。エージェントタスクの各段階では、精度、プライバシー、計算能力に求められる条件が異なります。

計画には、多様なコンテキストをまたぐ、より強力な推論が役立つことが多いです。反復的な調査、編集、検証は、より小さなワーカーに分散できます。

このモデルは従来のコンピューティングアーキテクチャに似ています。集中型システムがジョブをスケジューリングし、特化したマシンが関連データの近くでタスクを実行します。

ソフトウェアチームにとって実用的なハイブリッドワークフローは、ホスト型モデルが移行作業を分解するところから始められます。ローカルエージェントはその後、個別のモジュールを調査して編集案を提示できます。

機微な詳細を最小化した後、最終レビューをクラウドプランナーに戻すこともできます。あるいは、人間が追加のリモート呼び出しなしにローカル出力をレビューすることも可能です。

プライバシー上の利点は、この境界に依存します。クラウドプランナーが完全なソースファイルを受け取る場合、ローカルビルダーはリモートへのデータ露出を防げません。

開発者は、どのコンテキストが境界を越えるのか、どの要約を共有するのか、どのツールが外部サービスにアクセスできるのかを決めなければなりません。SDKがこうしたポリシー判断を自動的に行うことはできません。

Googleのポリシーシステムは、開発者が制限を適用する場を提供します。ただし、寛容なサンプル設定を、レビューなしに本番環境のデフォルトにしてはなりません。

同社の基本例では、ローカルエージェントが現在のディレクトリ内のファイルを調査します。より高度な例では、エージェントが監視ツールを作成し、コマンドを実行できます。

こうした機能はエージェントを有用にする一方で、リスクも高めます。誤った、あるいは操作されたモデルは、ファイルを変更したり、プロセスを起動したり、接続済みツールを通じて情報を露出させたりする可能性があります。

ローカル推論によってエージェントが無害になるわけではありません。変わるのはモデル計算が行われる場所であり、生成されたアクションに監督が必要かどうかではありません。

ハイブリッド実行は運用上の複雑さももたらします。チームはリモート呼び出しとローカルランタイムの両方を監視し、境界をまたぐ障害を理解する必要があります。

クラウドプランナーは欠陥のあるタスク分解を生成する可能性があります。ローカルビルダーはその計画を一貫して実行し、1つの誤りを複数のファイルへ広げかねません。

並行処理も別の制約を生みます。複数のGemma 4インスタンスを実行すると、単一の推奨構成が提供する以上のメモリが必要になる可能性があります。

GoogleはAntigravity統合について、独立したワークロード別ベンチマークを公開していません。したがって、この発表が示すのは利用可能性であり、普遍的な性能ではありません。

それでもデモは明確な製品の方向性を示しています。Googleは、より広範なエージェントシステムにおける補完的なワーカーとしてローカルモデルを位置付けています。

この戦略は、他のエージェントフレームワークにも同様のルーティングへの対応を迫ります。顧客は、クラウド専用の回答を受け入れる前に、タスクをローカルに留められるかどうかをますます問うようになるでしょう。

また、Googleは両市場にまたがる手段を得ます。Geminiサービスは高度なオーケストレーションで重要性を保ち、GemmaとLiteRTはプライバシー重視またはコストに敏感な実行をカバーします。

24 GBの推奨は最初の現実的なチェックポイント

オフライン運用はリモートエンドポイントへの依存をなくしますが、その代わりにハードウェア、保守、モデル品質という制約をもたらします。

GoogleはGemma 4 26B A4Bについて、少なくとも24 GBのVRAMまたはユニファイドメモリを持つマシンを推奨しています。この表現は推奨であり、普遍的な保証ではありません。

VRAMは、ディスクリートGPUで使われる専用グラフィックスメモリです。ユニファイドメモリは、Apple Silicon Macなどのシステムでプロセッサとグラフィックスハードウェアが共有するメモリプールです。

これらの構成は、高負荷時に異なる挙動を示します。ディスクリートGPUは高い推論スループットを提供できる一方、ユニファイドメモリはCPUとグラフィックスのタスク間で柔軟性を提供できます。

重要なのは公称総容量よりも利用可能な容量です。コンテナ、ブラウザ、ビルド、複数のエージェントを動かす24 GBマシンには、ほとんど余裕が残らない場合があります。

16.8 GBのチェックポイントダウンロードも、デプロイの負担になります。組織は、そのアーティファクトを承認済みのマシン全体に配布、検証、更新、保存しなければなりません。

モデルの来歴は運用上の懸念事項になります。チームは、チェックポイントの出所、変換方法、ライセンスが想定用途を許可しているかを確認すべきです。

Googleのドキュメントによれば、Gemma 4にはApache 2.0ライセンスが適用されます。外部のファインチューニング済みモデルや変換済みチェックポイントには、別個の条件やセキュリティ上の疑問が生じる可能性があります。

モデル品質には、より大きな不確実性があります。GoogleはGemma 4について、コーディングやエージェント指向の評価を含むベンチマーク結果を公開しています。

これらのベンチマークは、定義されたテスト条件下における基盤モデルを説明するものです。開発者のリポジトリ上で、Antigravityが長時間かつツール駆動のタスクをどれほど確実に完遂するかを証明するものではありません。

エージェントの信頼性では、ステップをまたいでエラーが複合します。小さな誤解が、ファイル選択、コマンド実行、テスト解釈、最終パッチに影響する可能性があります。

ローカルモデルには、最新のホスト型改善が反映されないこともあります。クラウドプロバイダーは推論システムを中央で更新できますが、ローカルデプロイでは意図的なアップグレードと回帰テストが必要です。

チームはその安定性を好むかもしれません。固定されたチェックポイントは、より制御された環境を提供し、リモートモデル更新後の予期しない挙動の変化を避けられます。

しかし、固定されていることは決定論的であることを意味しません。サンプリング設定、ツール結果、ワークスペースの状態、並行処理は、依然として結果を変え得ます。

セキュリティチームはローカルサーバーも精査する必要があります。ループバックアドレスは露出を抑えますが、不適切な設定によってポートが開放されたり、過度に広いファイルシステムアクセス権が与えられたりする可能性があります。

OpenAI互換サーバーにも同様の精査が必要です。vLLM serving documentationは、ローカルまたはプライベートなエンドポイントが一般的なモデルAPIをどのように模倣できるかを示しています。

互換性はポータビリティを改善しますが、意味のある違いを隠すこともあります。モデルごとに、ツール呼び出しの形式、コンテキスト処理、安全性の挙動、構造化出力への対応は異なります。

したがって開発者は、プロンプト応答だけでなく、エージェントループ全体をテストすべきです。良いコードを書くモデルでも、ツールを確実に選択することには苦労する場合があります。

Googleのハードウェア推奨は、当面の対象者を絞り込みます。大容量メモリのNvidia GPUを備えたワークステーションと、より高性能なApple Siliconシステムが自然な出発点です。

より小さなGemmaモデルは利用範囲を広げられますが、Googleの発表は最適化されたワークフローの中心に26B A4Bチェックポイントを据えています。これが最も強いローンチ時の主張を支えるバージョンです。

「ローカルで動作する」と「自分のマシンで十分に動作する」の間の隔たりは、依然として解消されていません。性能はハードウェア、コンテキストサイズ、ツール使用量、タスクの複雑さによって変わります。

オフラインのAntigravityエージェントが、包括的なソフトウェアエンジニアリングタスク全般で主要なホスト型システムに匹敵するという証拠も、まだありません。Googleはそのような広範な主張をしていません。

責任ある解釈はより限定的です。Antigravityは現在、文書化されたセットアップと相当なメモリ推奨のもとで、有意義なエージェントワークフローをローカルに実行できます。

性能の同等性が実現する前でも、この機能は重要です。これまでリモート推論が許可されなかった、あるいは望ましくなかった場面で、チームにデプロイ可能な選択肢を与えます。

ローカルエージェントがデフォルトになるかを示す3つのシグナル

次の試金石は、ローカル実行がプライバシー重視の実験や大容量メモリを備えた開発者ワークステーションを超えて、日常的なものになるかどうかです。

最初のシグナルは、より幅広いモデルとハードウェアへの対応です。開発者には、24 GBの推奨を下回るマシン向けの実用的な選択肢が必要です。

より小さなGemmaバリアントによって、オフラインエージェントをさらに多くのノートPCで利用可能にできます。追加の最適化済みチェックポイントにより、チームは能力と速度、メモリ使用量をトレードオフすることも可能になります。

対応だけでは十分ではありません。GoogleはApple Silicon、Nvidia GPU、その他の対応アクセラレータ全体で、明確な性能データを公開しなければなりません。

有用な測定値には、生成速度、最初のトークンまでの時間、ピークメモリ使用量、エンドツーエンドのタスク完了率が含まれます。エージェントベンチマークは、ツールと複数ステップにわたる復旧も対象にすべきです。

これらの結果が一般的なハードウェア上で許容可能な性能を示せば、ローカルルートは専門家向け機能以上のものになります。弱い結果であれば、クラウド推論がデフォルトであるという見方を強めるでしょう。

2つ目のシグナルは、本番デプロイからの証拠です。初期デモはソフトウェアが動作することを証明しますが、日常的な信頼性は明らかにしません。

チームは、ローカルエージェントが大規模リポジトリ、長時間セッション、並行ワーカー、再現可能な評価スイートをどのように処理するかを報告する必要があります。

セキュリティ重視の導入には特に注意が必要です。エアギャップ環境の組織には、ワークフローが内部統制を満たすなら、より遅い性能を受け入れる強い理由があります。

開発者からのフィードバックは実務上の摩擦も明らかにします。インストールの失敗、チェックポイント変換の問題、熱的制約、ツール呼び出しエラーは、アーキテクチャ上の利点を上回り得ます。

3つ目のシグナルは、競合他社の対応です。他のエージェントフレームワークもすでにローカルモデルサーバーに接続していますが、統合の深さには大きな差があります。

重要な比較は、製品がOllamaを選択肢として挙げているかどうかではありません。ローカルモデルが、同じツール、ポリシー、ワークスペース、オーケストレーション機能を使用できるかどうかです。

競合他社は、より強力なローカルルーティング、エンタープライズ向けホスト型推論、またはリモートモデルとオンデバイスモデルの自動選択で応じる可能性があります。

迅速な対応は、実行場所が購買基準になりつつあるというGoogleの根底にある判断を支持するでしょう。対応が限定的なら、需要が愛好家の間に集中していることを示唆します。

Googleのハイブリッドパターンも精査に値します。実用的なバランスを提供できますが、それは開発者がどの情報がクラウドプランナーに届くかを検証できる場合に限られます。

明確なログ、ポリシー制御、追跡可能なルーティングは、モデル対応と同じくらい重要になります。企業には、宣言された境界がすべてのエージェントターンで強制されているという証拠が必要です。

このリリースは、より規律あるタスク設計も促すべきです。開発者は、1つのシステムがプロジェクト全体を自律的に管理することを期待するのではなく、制約された作業のためにローカルエージェントを確保できます。

例としては、非公開文書の分類、範囲が限定されたモジュールのレビュー、テストの生成、ローカル技術メモの要約などがあります。いずれのタスクにも測定可能な入力と出力があります。

このアプローチは、機微なコンテキストをユーザーの近くに維持する、より広範なAI workflowに適しています。重要なアクションは引き続き人間のレビューが統制します。

Antigravity SDKのローカルモデルにより、オフラインでのエージェント実行は、非公式な回避策ではなく、Googleが文書化したワークフローになりました。このローンチは品質やアクセス性に関する疑問を解決するものではありません。

ただし、開発者がエージェントプラットフォームに求められることは変わります。クラウドアクセスは、もはや自動化の避けられない代償である必要はありません。

最も有益な次のステップは、具体的なテストです。範囲を限定した非公開のタスクを1つ選び、メモリ使用量と完了品質を記録したうえで、ローカル実行とホステッド実行を比較してください。

ローカルエージェントは、ハードウェア投資を正当化できるだけの作業を完了しながら、重要なコンテキストを保持できるのでしょうか。その答えによって、Googleが標準的なアーキテクチャを生み出したのか、それとも価値ある例外を提示したのかが決まります。