Geminiがアプリ作成を担う中、GoogleがAI Studioモバイルアプリを中止

Googleは、AndroidとiOS向けに独立したAI Studioアプリを計画していたにもかかわらず、わずか2カ月前に発表した製品をGeminiに統合しようとしている。9to5GoogleのGoogleに関する報道によると、これらのモバイルアプリは中止された。Googleは現在、アプリ作成機能をGeminiそのものに組み込み、最終的にはモバイルとデスクトップの両方に向けたソフトウェアを対象にする計画だ。

これは単なるGoogleの実験的プロジェクトの中止ではない。同社がI/O 2026で示した、スマートフォンからアプリを構築する専用の場としてのAI Studioモバイルという構想を覆すものだ。Googleはむしろ、アプリ生成は利用者がすでに使っているアシスタントの中にあるべきだと考えているようだ。

この決定は、独立した開発環境と、統合された会話型環境を対比させる。AI Studioは引き続きウェブで利用できるが、Geminiの月間ユーザー数は9億人を超える。作成機能をこのより大きな製品に組み込めば、アプリ構築は特別な目的地ではなく、会話のありふれた一部になる可能性がある。

9to5GoogleのGoogleに関する報道が伝える変更点

Googleが中止したのは独立したモバイル向けコンテナであり、日常的なデバイスからソフトウェア作成を可能にするという大きな取り組みではない。

5月19日のGoogle I/Oで、同社はAndroidとiOS向けの専用AI Studioアプリへの事前登録を利用者に案内した。計画されていた体験は、スマートフォン上で完全なBuild modeを提供するというものだった。Build modeは、アプリケーションの生成とプレビューを行うAI Studioのプロンプトベース環境である。

Googleは、デスクから離れた場所でアイデアを捉えることから始まるワークフローを説明していた。利用者はその後、コードを反復改善し、ビルドをプレビューし、ギャラリープロジェクトをリミックスし、ライブデプロイを共有できる。同じ作業を後からデスクトップで継続することも可能だった。

同社の当初のモバイルアプリ計画は、携帯性を最大の利点として位置づけていた。スマートフォンは、別の場所で生成されたアプリを表示するだけでなく、コンパクトな開発環境になるはずだった。

iOSの掲載情報では7月のリリース予定日まで示され、AndroidユーザーはGoogle Playから事前登録できた。しかし、当初示された形で、どちらのバージョンも一般公開には至っていない。

7月31日のアプリ中止に関する報道によると、Googleはこの戦略を変更した。同社は専用のAI Studioモバイルクライアントから距離を置き、Gemini内でのアプリ作成に注力している。

Googleの公表内容は、利用者がいずれ通常のGeminiとの会話を通じてモバイルおよびデスクトップアプリケーションを作成できるようになることを示している。旅行について話し合ったり、仕事を整理したり、実務上の問題を解決したりする中で、アイデアが生まれるかもしれない。Geminiはそのニーズをインタラクティブなソフトウェアへ変えられる可能性がある。

この表現は、異なる対話モデルを示しているため重要だ。AI Studioでは、利用者はアプリのアイデアを持って開発環境に入る必要がある。一方Geminiは、利用者がすでに目標を説明している最中に、ソフトウェアの機会を見つけられる可能性がある。

この違いにより、入口が変わる。利用者は始める前に、アプリケーションが答えだと判断する必要がなくなる。Geminiは根本的なタスクを理解した後に、インターフェースを提案または生成できるかもしれない。

Googleは、この機能の詳細なリリース予定を公表していない。また、どのプラットフォーム、アカウント種別、国に最初に提供されるかも定義していない。中止は具体的な事実である一方、代替策はまだ将来の製品方針にとどまる。

AI Studioそのものが終了するわけではない。ウェブ製品は引き続き、アプリ生成、モデル実験、デプロイ、ネイティブAndroid開発をサポートしている。中止されたのは、計画されていた独立型モバイルクライアントだ。

この境界は重要である。一部ではこの決定をGoogleがAI Studioを終了させるものとして表現しているが、利用可能な証拠はその結論を支持していない。Googleが変えているのは、消費者向けの作成体験が存在する場所だ。

したがって、9to5GoogleのGoogleに関する記事には、後退と拡張の両方が含まれている。約束されていた2つのモバイルアプリはなくなった。しかし、その根底にある野心は現在、デスクトップアプリケーションと、はるかに大きなGeminiの利用者層にまで広がっている。

この方針転換は中心的な疑問を生む。汎用アシスタントは本格的なアプリ作成に十分な制御を提供できるのか。それとも統合によって、AI Studioを有用にしていた明快さが失われるのか。

Googleは専用ビルダーをGeminiのリーチと引き換えにする

中止されたアプリによって明確な行き先の一つは失われるが、Googleは何億人もの既存ユーザーの前にアプリ生成を置く機会を得る。

Googleは5月、Geminiが230カ国以上、70以上の言語で月間9億人超のユーザーに利用されていると述べた。その1年前、同社は4億人のユーザーを報告していた。これらの数値はGoogleによるもので、独立した監査は受けていない。

この留保を考慮しても、規模の差は大きい。AI Studioは、開発者、技術的なクリエイター、Geminiモデルを積極的に試す人々を対象としている。Geminiアプリは、開発者向けツールを一度も訪れないかもしれない、より幅広い層に届く。

GoogleのGeminiアプリのアップデートも、統合が同社の現在の戦略に合致する理由を示している。同社はGeminiを、質問応答型チャットボットにとどめるのではなく、汎用的なアクションレイヤーへ変えようとしている。

I/OでGoogleは、利用者の指示に基づいてバックグラウンドタスクを実行するエージェント、Gemini Sparkを発表した。また、ファイル生成、接続サービス、プロアクティブな支援も拡張した。アプリ作成は、会話を実行可能な成果物へ変えるため、この方向性に合致する。

たとえば、製品ローンチを計画するプロジェクトマネージャーを考えてみよう。会話の中で、ステータスダッシュボード、リスクトラッカー、フィードバック整理ツールの必要性が見えてくるかもしれない。Geminiは、利用者に独立した開発製品を開かせることなく、そのインターフェースを生成できる可能性がある。

教師は、各回答の後に内容が変化する教室向けクイズを求めるかもしれない。営業マネージャーは、共有シートに接続されたモバイル入力フォームを依頼できる。旅行者は、旅程についての会話をオフラインのチェックリストに変えられるだろう。

Googleが統合機能を提供するまで、これらの例は仮説にとどまる。それでも、会話の文脈が重要である理由を示している。Geminiは、アプリケーションを生成する前に、利用者の目的、制約、ファイル、好みの出力をすでに把握している可能性がある。

専用のAI Studioアプリは、より少ない文脈から始まる。プロジェクト履歴にはアクセスできても、利用者は現実世界の問題を開発リクエストへ翻訳する必要がある。Geminiはその翻訳の手順を取り除ける可能性がある。

ここでGoogleのWorkspace統合も戦略的に有用になる。AI Studioはすでに、Sheets、Drive、ドキュメントと連携するアプリケーションを構築できる。これらの接続により、生成されたソフトウェアは人々が仕事で使う情報を扱えるようになる。

同社の開発者向けハイライトは、AI Studioをより広い連鎖の中に位置づけていた。利用者はAI Studioでプロトタイプを作成し、プロジェクトをAntigravityへエクスポートして、デプロイへ向けて作業を続けられる。

Geminiはその同じ連鎖の最初の段階になり得る。意図を捉え、初期体験を生成する。プロジェクトの要求が高まれば、AI StudioまたはAntigravityがより深い制御を提供できる。

この構造は、置き換えというよりファネルに近い。Geminiは大きな利用者層にアプリ作成を届ける。AI Studioはブラウザベースの構築を担い、Antigravityはより大規模な開発とエージェントのオーケストレーションを支える。

課題は、明快な引き継ぎを保つことだ。生成されたアプリケーションは、認証、データベース、権限、請求、外部サービスを備えるにつれて保守が難しくなる。利用者には、コード、設定、テスト、デプロイ記録へのアクセスが必要となる。

Googleは、Geminiのプロジェクトがこれらのプロフェッショナル向け環境へどのように移行するのか説明していない。会話の文脈、生成ファイル、シークレット、デプロイ設定が引き継がれるかについても明らかにしていない。

同社はすでに、文脈を付加した状態でAI StudioのプロジェクトをAntigravityへエクスポートすることをサポートしている。Geminiから同等の橋渡しがあれば、統合戦略の信頼性は増すだろう。それがなければ、生成アプリは一時的なデモに終わるおそれがある。

Googleにとって、リーチを重視する論拠はなお強力だ。独立したモバイル利用者層を構築するには、インストール、オンボーディング、継続的な利用が必要になる。Geminiはすでにそうした関係を持ち、Android、iOS、ウェブ、デスクトップに存在している。

利用者にとっても、統合は製品の混乱を減らす。GoogleはGemini、AI Studio、Android Studio、Firebase、Antigravity、複数のクラウド開発サービスを提供している。別のモバイルアプリが加われば、理解すべき新たな境界が増えていたはずだ。

それでも、リーチは採用を保証しない。人々はソフトウェアとは無関係の多くのタスクのためにGeminiを開く。Googleは通常の会話を妨げたり、不要なインターフェースを生み出したりせずに、アプリ生成を見つけやすくしなければならない。

9to5GoogleのGoogleに関する報道は、流通に関する賭けを捉えている。Googleは、最大のアシスタント内にアプリ作成を出現させるため、焦点を絞った製品を犠牲にしている。この取引の成否は、利用者数だけでなく実行力にかかっている。

本当の方針転換は、アプリのアイデアが始まる場所にある

Googleは当初、意図的な構築を中心にモバイルAI Studioを設計していたが、Geminiの構想は会話の中で生じるニーズから始まる。

以前のコンセプトは、よく知られた開発の流れに従っていた。人はアイデアを持ち、AI Studioを開き、アプリケーションを説明し、出力を確認して、デプロイを共有する。スマートフォンはデバイスを変えるだけで、基本的なワークフローは変えなかった。

新しいコンセプトは、ワークフローそのものを変える。利用者はソフトウェアを依頼するのではなく、問題について話すことから始めるかもしれない。Geminiは、インタラクティブなアプリケーションが有用な応答だと判断できる可能性がある。

これが本記事における最大の方針転換だ。Googleは「ビルダーを開く」から「適切なときにアシスタントに構築させる」へ移行している。これは主導権を利用者からモデル側へ移す。

このアプローチは、会話型AI製品全体ですでに現れ始めている機能の上に成り立つ。アシスタントは、文書、スプレッドシート、グラフ、インタラクティブな可視化、小規模なコードベースの成果物を作成できる。アプリケーションは、この出力モデルをより大きく拡張したものだ。

Googleは4月、Geminiにダウンロード可能なファイル生成を追加した。利用者はチャットを離れることなく、文書、スプレッドシート、PDF、その他の形式を要求できる。同社は現在、ソフトウェアも会話が生み出せるもう一つの成果物として位置づけている。

アプリケーションは状態と振る舞いを持つため、ファイルとは異なる。ユーザー入力を受け取り、外部サービスを呼び出し、情報を保存し、時間とともに変化する場合がある。これにより生成の有用性は高まるが、失敗の機会も増える。

Google AI Studioはすでに、インターフェース、サーバーロジック、接続されたデータサービスを組み合わせる、プロンプトベースのフルスタックアプリケーションをサポートしている。現在のBuild modeガイドは、Geminiの機能、デプロイ、サーバー側でのシークレット処理を軸にアプリ生成を説明している。

ウェブツールは、目に見える開発コントロールを提供する。利用者はコードを確認し、プロンプトを調整し、動作をテストし、サービスを接続し、デプロイを管理できる。これらのコントロールは、会話とソフトウェアエンジニアリングの間に心理的な境界を作る。

Geminiの会話型インターフェースは、意図的に技術色を抑えている。それは親しみやすさにつながる一方で、重要な判断を隠す可能性もある。生成されたアプリケーションにも、権限、データルール、エラー処理、セキュリティ境界が必要だ。

Googleは、その複雑さをどこまでチャット上に出すべきか判断しなければならない。設定が多すぎれば、Geminiは統合開発環境のように感じられる。少なすぎれば、ユーザーは生成されたアプリケーションが何をするのか判断できなくなる。

モバイルとデスクトップの生成は、さらに別の層を加える。GoogleはAI Studioで、KotlinとAndroidのモダンなUIフレームワークであるJetpack Composeを用いたネイティブAndroidアプリの作成を実演した。ユーザーはブラウザベースのエミュレーターでコードをプレビューし、ビルドを内部テストトラックへ送信できる。

デスクトップ開発については、定義がより曖昧だ。Googleは、Geminiを通じて対応する予定のオペレーティングシステム、アプリケーションフレームワーク、パッケージ形式、配布方法を明らかにしていない。

「デスクトップアプリ」は、WindowsやmacOS向けにインストールできるソフトウェアを意味する可能性がある。より大きな画面向けに最適化されたWebアプリケーションを指す可能性もある。これらは実質的に異なる約束であり、Googleはこの用語を定義する必要がある。

iOSへの道筋も同様に不透明だ。AI Studioが発表したネイティブ開発支援はAndroidに焦点を当てていた。Googleは、ネイティブiPhoneアプリケーションを生成する同等のSwiftベースのワークフローを発表していない。

iOSクライアントを中止しても、iOS開発支援が自動的に生まれるわけではない。そのクライアントは、人々がiPhoneでAI Studioを利用できるようにするものだった。必ずしもネイティブiOSソフトウェアを生成するものではない。

この区別は、見出しでは簡単に消えてしまう。GoogleはGeminiが将来的にモバイルアプリケーションを作成すると述べているが、出力形式は依然として明示されていない。モバイル対応のWebアプリは、ストアで配布できるネイティブアプリケーションと同じではない。

Googleの計画の最も強い形は、会話を通じてニーズを把握し、動作するインターフェースを作り、ユーザーに出力先を選ばせるものだ。その後、デプロイ前にコードとテストツールを提示する。

より弱い形では、Gemini内でしか動作しない使い捨てのインタラクティブカードが作られる。そうした体験もユーザーの役には立つかもしれないが、独立したモバイルまたはデスクトップソフトウェアに対する一般的な期待には応えない。

製品の境界が、誰がプレッシャーを受けるかを決める。プロンプトベースのビルダーは、専用ワークスペース、再利用可能なプロジェクト、ホスティング、デプロイを提供することで競争している。Geminiの会話型出力が編集可能で移植可能なままであれば、Googleは彼らに挑戦できる。

従来の開発環境は別種の圧力に直面する。Googleは、単一のプロンプトでプロフェッショナルなエンジニアリングを置き換えようとしているわけではない。多くのユーザーがすでに自分の要望を説明している場所へ、初期プロトタイピングを移そうとしている。

開発者は、コーディングツールを一度も開いたことのない同僚から、部分的に生成されたプロジェクトをより多く受け取るようになるかもしれない。それは発見を加速させる一方、保守作業を生む可能性もある。生成コードは、機密情報を扱ったり実際の顧客に提供したりする前に、依然としてレビューが必要だ。

チームは、会話型プロトタイプを完成品ではなく要件定義の成果物として扱うことで備えられる。プロンプト、期待される動作、テストケース、ソース資料を保存すべきだ。検索可能なエンジニアリング文書のセットがあれば、その引き継ぎを容易にできる。

Googleの賭けは、アプリ作成が、誰かが自分でソフトウェア開発をしていると認識する前に始まるというものだ。Geminiはすでにその初期段階を占めている。AI Studioはそうではない。

Geminiのアプリ作成には依然として制御の問題がある

統合戦略は摩擦を減らすが、Geminiがテスト、セキュリティ、移植性、長期保守をどのように扱うのかをGoogleは示していない。

最初の不確実性は製品定義に関するものだ。Googleは完成済みの機能ではなく、将来の方向性を説明している。Gemini内でのモバイルおよびデスクトップ生成について、公開された提供開始日、対応プラットフォーム一覧、詳細なデモはない。

この隔たりは重要だ。スタンドアロンアプリは事前登録を受け付けるだけの具体性があった。Googleは機能を発表し、インターフェースを示し、デバイスをまたぐワークフローを説明した。現在の代替案は、運用面の詳細がより少ない。

2つ目の不確実性はユーザーの制御に関するものだ。会話は意図を集めるのには適しているが、構造化されたプロジェクト管理の代替としては不十分だ。アプリケーションには、バージョン履歴、ファイル、依存関係、環境変数、デプロイ設定、再現可能なテストが必要となる。

ユーザーは、Geminiがいつアプリケーションを提案しているのかも理解する必要がある。複雑な質問ごとに自動でインターフェースを生成すれば、煩雑になる。明示的な依頼を待てば、会話から自然にアプリが生まれるという約束が弱まる。

Googleは明確な同意の段階を設ける必要がある。Geminiはアプリケーションを提案し、アクセスする内容を説明し、生成の承認をユーザーに求められる。そうすれば、会話を通じた発見を保ちながら、ユーザーの制御を維持できる。

権限にも同様の扱いが必要だ。スプレッドシートに接続したダッシュボードには、ローカル計算機とは異なるアクセスが必要になる。メールを送信したり顧客情報を保存したりするアプリケーションは、インタラクティブなグラフよりも大きなリスクを伴う。

GoogleのFirebaseドキュメントはすでに、Gemini APIキーをクライアントコードに含めないよう開発者に警告している。また、接続されたサービスに対してセキュリティルールとアプリケーションチェックを推奨している。Geminiがプロジェクトを生成したというだけで、こうした安全策が不要になるわけではない。

生成されたアプリケーションには、安全でないデフォルト設定、信頼性の低いロジック、既知の脆弱性を持つ依存関係が含まれる可能性がある。洗練されたインターフェースは、そのアプリケーションが安全であることを示すものではない。Geminiが説得力のあるプレビューを作成するため、ユーザーは品質を過大評価するかもしれない。

したがって、9to5GoogleのGoogleに関する記事を、Geminiがソフトウェアチームを置き換えられる証拠として読むべきではない。Googleが発表したのは、配布とインターフェースの戦略だ。モバイルとデスクトップのプラットフォームをまたぐ、信頼できるエンドツーエンド開発を実証したわけではない。

移植性も別のリスクをもたらす。ユーザーは、生成コードをエクスポートできるか、別の場所にデプロイできるか、Geminiなしで開発を続けられるかを知る必要がある。会話の内部に閉じ込められたプロジェクトは、長期的な作業における価値が限られる。

AI Studioは現在、コード中心のワークフローと、他のGoogle開発ツールへの接続を提供している。これにより、プロトタイプから保守されるプロジェクトへ進む道筋が生まれる。Geminiにも、AI Studio、Antigravity、Android Studio、または他の標準環境への同じくらい明確な出口が必要だ。

プラットフォームをまたぐと、テストもより複雑になる。デスクトップアプリケーションはWindowsとmacOSで異なる挙動を示す可能性がある。モバイルアプリケーションでは、画面サイズ、権限、バックグラウンド動作、バッテリー使用量、ストアポリシーを考慮しなければならない。

GoogleはAndroidとGoogle Playを管理しており、直接的なテストおよび配布ルートを持つ。一方で、Appleの開発環境やApp Storeの審査プロセスは管理していない。クロスプラットフォームに関する主張には、レスポンシブなインターフェースの生成以上の証拠が必要となる。

同社のI/Oデモは、Androidにとって有用な基準を示した。AI StudioはKotlinコードを生成し、ブラウザのエミュレーターで実行し、Android Debug Bridge経由で接続し、内部テストトラックに公開できた。ユーザーが出力をデプロイ可能なソフトウェアとして扱う前に、Geminiはこれらの制御機能に並ぶべきだ。

上級ユーザーにとっては、見つけやすさの問題もある。AI Studioは、実験向けに設計された環境でモデル、プロンプト、ツール、コードを分けている。Geminiのよりシンプルなインターフェースは、モデル選択を見えにくくしたり、そうしたユーザーが必要とする設定オプションを取り除いたりする可能性がある。

統合が機能するのは、Googleが異なる制御レベルを維持する場合に限られる。カジュアルなユーザーは自動生成されたミニアプリを受け入れられる。開発者は、実装を調べ、動作方法を変更できなければならない。

ユーザーの反応には、すでに両方の側面が表れている。AI Studioはモバイルブラウザで利用できるため、スタンドアロンアプリは不要だと考える人もいる。一方で、作成機能をGeminiへ統合すると、AI Studioのより深い制御にアクセスしにくくなると懸念する人もいる。

代替案が提供されるまで、どちらの見方も決着しない。この中止は、現在のアプリの乱立を減らす。一方で、GoogleがGeminiで同等の体験を提供することを示す前に、約束された体験を取り除くことにもなる。

Googleの製品史は、理解できる懐疑を加える。同社は重複するサービスをしばしば統合するが、ユーザーはその移行中にワークフローを失うことがある。事前登録の中止は、実際に動くソフトウェアなしに将来の約束を評価することをより難しくする。

慎重な読み方は限定的だ。Googleは、会話型アプリ作成の方がスタンドアロンのAI Studioモバイルクライアントより戦略的価値が高いと考えている。この判断がビルダーに利益をもたらすかは、エクスポート、テスト、プラットフォーム対応、信頼性に左右される。

Google、開発者、競合他社が次に証明すべきこと

Googleがアプリ作成へのより良い経路を見つけたのか、それとも代替製品の準備前に製品を中止しただけなのかを示すシグナルは3つある。

最初のシグナルは、動作するGeminiアプリ生成プレビューだ。Googleは、完全な会話が編集可能なアプリケーションになる様子を示す必要がある。デモには、生成された挙動、権限、テスト、エクスポート経路を含めるべきだ。

基本的なインタラクティブカードでは、より大きな主張が弱まる。コンテキストを保ったままAI StudioまたはAntigravityへ移行できるプロジェクトであれば、Googleの統合戦略を裏付けるだろう。

2つ目のシグナルは、正確なプラットフォーム定義だ。Googleはモバイルアプリとデスクトップアプリが何を意味するのか説明しなければならない。開発者は、Geminiがネイティブコード、クロスプラットフォームパッケージ、プログレッシブWebアプリ、あるいはGemini内に閉じた体験のどれを生成するのかを知る必要がある。

ネイティブAndroid対応は、Googleがすでに発表した能力を基盤にできる。ネイティブiOS、Windows、macOS向けの出力には、新しいツールチェーンと配布ワークフローが必要になる。それぞれのターゲットは異なる技術要件とポリシー要件を生む。

3つ目のシグナルは、競合するビルダーがどう反応するかだ。プロンプトからアプリを作成することに特化したサービスは、予測可能な編集、デプロイ、統合、コード所有権を強調できる。また、Googleの増え続ける製品群よりも、クロスプラットフォーム対応を理解しやすくできる。

競合が自然言語プロトタイプから保守されるコードへの引き継ぎを改善すれば、Googleの配布上の優位性が市場を決めない可能性がある。より明確な制御を提供するなら、ユーザーは追加のアプリケーションを受け入れることが多い。

GoogleはAI Studioの継続的な役割も明確にする必要がある。Webツールを稼働させ続けるだけでは不十分だ。同社は、どの作業がGeminiで始まり、どの作業がAI Studioへ移り、どの作業がAntigravityまたはAndroid Studioに属するのかを説明すべきだ。

その地図は、カジュアルな作成者とプロフェッショナルなチームの双方に役立つ。それがなければ、製品群は同じ問いに対する複数の重複した答えのように感じられる。

開発者にとって、短期的な対応は実務的であるべきだ。未リリースのGemini機能を中心にワークフローを作り直してはならない。AI Studioの現在のWebツールがプロジェクトのニーズを満たすなら、引き続き利用すべきだ。

同時に、エンジニアリングの外で始まるプロジェクトには注意を払うべきだ。同僚が、日常的なGemini会話の中で生成したプロトタイプを持ち込むようになるかもしれない。チームは、そうした成果物をどのようにレビュー、テスト、セキュリティ評価、所有権のプロセスへ組み込むかを決めるべきだ。

エンタープライズの購入担当者は、デモの速さではなくガバナンスに焦点を当てるべきだ。生成されたアプリケーションがどのデータにアクセスしたか、どのコードがデプロイされたか、各権限を誰が承認したかを示す記録が必要となる。

ナレッジワーカーは、Geminiが依頼されずにアプリケーションを提案する頻度に注目すべきだ。有用な提案は、繰り返しの作業を小さく個人向けのツールに変えられる。質の低い提案は、会話をたどりにくくする可能性がある。

中心にある競争は、専用ビルダーと統合アシスタントの対決であり続ける。AI Studioは意図、構造、可視化された制御を提供する。Geminiはコンテキスト、配布、開始時の低い障壁を提供する。

Googleは、統合アシスタントを主要な消費者向け経路として選択した。ただし、プロトタイプが重要になった後に求められる制御を、この経路で維持できることはまだ示していない。

これは、取りやめになったアプリ群を、プロダクト戦略を読み解くうえで異例なほど示唆に富む判断にしている。Googleがモバイルでの開発を断念したのは、スマートフォンが不向きだったからではない。独立した開発先を用意するよりも、Gemini内に開発機能を組み込む方が価値が高いと判断したのだ。

今後数カ月で、この判断が妥当だったかどうかが明らかになるはずだ。Geminiの詳細なプレビューが示されれば、その判断を後押しする。一方で、曖昧なデモ、限定的なエクスポート機能、あるいは対応プラットフォームに関する沈黙が続けば、その説得力は弱まるだろう。

9to5GoogleのGoogleに関する報道は、発表済み製品の一つが終わりを迎えたことを示すが、Googleのモバイル開発への野心の終焉を意味するものではない。むしろGeminiには、重要な選択肢を見えにくくすることなく、会話、コード、デプロイをつなぐという、より大きな責任が課されることになる。

ユーザーはいま何をすべきだろうか。利用可能なツールで開発を続けつつ、Geminiの今後のアプリ作成機能は、洗練されたプレビューではなくエクスポートされたコードで評価すべきだ。会話が終わった後も、プロジェクトが編集可能で、テスト可能で、移植可能な状態に保たれるかを確認してほしい。開発者はまた、生成されたソフトウェアを実データへ接続する前に、明確な権限の境界を求めるべきだ。Googleがこれらを実現できれば、独立アプリの中止は焦点を絞った統合として映るだろう。実現できなければ、この判断は、より大きな約束を掲げながら性急に後退したものと見なされることになる。