検索から予約や実行へ。Googleがアプリ連携の入口を一本化

連携の開発と運用を一か所へ

Googleは2026年10月28日、SearchとGemini向けの連携アプリを管理する「Connected Apps Platform」のプレビューを発表した。開発者はMCPなどを用いて連携を実装し、Google Connected Consoleから登録、テスト、審査申請を進める。公開後はトラフィックや遅延、エラー率を確認できるとしている。参加する開発者や市場は段階的に広げる方針で、日本の全事業者がすぐ利用できるという発表ではない。

Webの役割が広がる

編集部の見方では、この動きはWebの役割を考え直す材料になる。検索結果からサイトに移動して操作してもらう流れに加え、利用者が対話を続けたまま店舗やサービスの機能を使う接点が増えうるからだ。ページに説明が載っていることと、外部のAIが安全に予約枠を調べたり見積もりを取得したりできることは、設計上は別の課題である。

まず公開する機能を決める

企業が最初に決めたいのは、どの機能を連携に出すかだ。たとえば空き状況の検索と予約確定、商品の比較と購入、見積もりの作成と契約には、それぞれ異なるリスクがある。まず読み取り中心の機能を候補にして、入力条件、返却データ、エラー時の説明を整理すると進めやすい。失敗時に人へ戻れる導線も、後付けではなく初期設計に含めておきたい。

実行の品質を監視する

運用では、呼び出し回数だけでなく「利用者が目的を達成したか」を見たい。連携の応答が速くても、古い在庫を返したり、同じ予約を重複して作ったりすれば体験は悪化する。テスト環境で代表的な成功例と失敗例を揃え、本人確認、実行前の確認、キャンセル方法を点検することが必要だ。AIとの接続を増やすほど、権限やログを管理する責任も増える。

問い合わせの窓口を決める

事業上の窓口も必要になる。利用者から「頼んだ内容と違う」と言われたとき、連携先と自社のどちらが確認し、どの記録を照合するのか。技術的に接続できることと、日常的にサービスとして支えられることを分けて検討するのがよい。

小さな用途から準備

現時点で実務担当者ができる準備は、自社サービスの機能一覧と責任範囲を整理することだ。連携できるという理由だけで、重要な操作まで一度に開放する必要はない。ユーザーが何を頼み、どの条件で実行され、何をもって完了とするかを明文化する。提供地域や参加条件を公式資料で確認しながら、小さな用途から試す姿勢が、今後の対話型サービスに備える現実的な一歩になる。