Googleは2026年10月28日、SearchとGemini向けのアプリを一か所で構築・管理するConnected Apps Platformのプレビューを発表しました。アプリを「つなげるか」だけでなく、どの画面へ出し、何を実行させ、どう監視するかを決めるニュースです。
連携は一つでも、公開先は分けて考える
公式発表では、開発者はクラウドホスト型MCPサーバーまたはAndroid MCPを使い、Google Connected Consoleで登録・テスト・申請します。そのうえで、Search、Gemini、または両方のどこに公開するかを選びます。Googleは公開後のトラフィック、遅延、エラー率も追跡できると説明しています。
つまり今回の変化は、アプリをAIへ接続する手段が増えたことだけではありません。同じ連携でも、ユーザーが出会う場所と、運用チームが見る指標を分けて設計できる点にあります。
先に決めるのは「何とつなぐか」より操作の境界
仮の場面として、自社サービスの予約や問い合わせをGeminiから扱いたいプロダクト担当者を考えます。最初から両方の面へ広げるのではなく、SearchかGeminiの片方で、参照だけにするのか、予約変更まで許すのかを切り分けます。入力データの範囲、ユーザーが確認する場面、失敗時に人へ戻す条件も同じ表に置きます。
これはGoogleの導入実績ではなく、発表された公開先の選択と監視機能を業務設計へ当てはめた提案です。連携できることと、安全に業務を任せられることは同じではありません。
プレビュー段階で比較するものを一つに絞る
Connected Apps Platformは段階的にアクセスを広げるプレビューです。企業が今決めるべきなのは、すぐ全面展開することではなく、代表的な一つの場面で公開先と操作範囲を固定し、トラフィック・遅延・エラー率が何を示すかを確認することです。
公開先を増やす前に、どのデータを参照し、どの操作を許し、どの指標が悪化したら人の確認へ戻すかを決める。AI連携の第一歩は、接続数を増やすことではなく、公開範囲と監視の境界を選ぶことです。
Google「Build and manage Connected Apps in one place」 https://blog.google/innovation-and-ai/technology/developers-tools/connected-apps-one-place/