この記事は、Google Cloud Next ’26 のセッションレポートです。

セッション情報

  • セッション名: Develop and integrate AI agents with Google Workspace
  • 登壇者:
    • Pierrick Voulet 氏(DevRel Engineer, Google Workspace)
    • Janardhan Santharam 氏(CIO, Tata Consultancy Services)
    • Joanny Jolas 氏(Director of Product, AI & Search, LumApps)

先に30秒でまとめ

  • 発表されたもの: Google Workspace を AI エージェントから扱うための全体像。ノーコード(Workspace Studio)、ローコード(Apps Script)、プロコード(API・MCP server・A2A)の3レイヤで、誰でもエージェントを作って Workspace に繋げられるようになる。
  • 何が変わったか:
    • Workspace のデータ、操作、画面が、エージェントから扱えるようになった
    • BigQuery、Bigtable、Cloud Run、Agent Search に MCP server エンドポイントが用意された
    • 大企業の内部で、エージェントが実際に業務を回す段階の事例が出てきた
  • 具体的に何が嬉しいか: 例えば TCS では、Agent Designer を使って社員自身が4週間で6,850個以上のエージェントを生み出しました。
  • 一番強い主張: モデルの賢さではなく、自社のデータと文脈こそが勝負を分ける。
  • 印象的だった事例: TCS の Agentic selling。役割別のエージェントをオーケストレーターが束ねて、営業プロセス全体をエージェントが回しています。

Workspace を AIエージェント基盤として使う

エージェントが動くには、データを参照し、操作を実行し、人や他のシステムと接点を持つ必要があります。Workspace はその全部を持っているので、エージェント基盤としてそのまま使えます。

3つの素材 — Data / Actions / Interfaces

Workspace を AI エージェントから扱うときに使う部品は、データ・アクション・インターフェースの3つに分かれます。

データは、課題、メッセージ、ファイルなど、Workspace の各サービスに溜まっているもの全般です。アクションは、ステータスを変える、イベントを作る、調査を依頼するなど、エージェントが実際に手を動かす操作です。インターフェースは、画面、プログラムからアクセスする経路、ユーザ自身、と複数の接点があります。

エージェントを設計するときは、この3つを分けて考えると見通しがよくなります。

3つの開発レイヤ

誰が作るか、で開発の入口が3つに分かれます。

レイヤ ツール 想定する作り手
ノーコード Workspace Studio 全ユーザ
ローコード Apps Script パワーユーザ
プロコード API + MCP server + A2A プロ開発者

土台には Gemini Enterprise Agent Platform と GCP のサービスがあり、Workspace 側からは Gemini extensions、Smart chips、Add-ons、Chat apps を通じて、ユーザが “Human in the loop” としてエージェントとやり取りできます。出口には Marketplace があり、作ったエージェントを配布できます。

MCP server エンドポイント

開発者が自分のエージェントから Google Cloud のサービスを呼び出すための MCP エンドポイントは、すでにいくつか公開されています。BigQuery、Bigtable、Cloud Run、Agent Search(Discovery Engine)などです。

セッション時点で示されたスライドでは、Workspace に MCP server は用意されていない、と説明されていました(対応表には「N/A」と記載)。Workspace に繋ぐときは API、Apps Script、Workspace Studio のいずれかを使う、という前提です。一方、Next ’26 期間中の別の発表では、Gmail / Drive / Calendar / Chat / People それぞれに対応する Workspace MCP server も公開されています。プロコードから Workspace を扱う選択肢が、API・Apps Script・Workspace Studio に加えて MCP server まで広がりました。

5つのペルソナ

Workspace × AI エージェントには、5つのペルソナがあります。

User は、Gmail からでも Gemini Enterprise からでも、どこからでもエージェントを呼び出して使う人です。

Builder は、ビジュアルなデザイナーでエージェントを組み立てる人です。モデルとコネクターを選び、ナレッジを与えて、フローを定義する作業をコードを書かずに進められます。

Developer は、フレームワークやツールを使ってエージェントを開発するエンジニアです。ADK や Gemini CLI、Antigravity といった開発ツールを組み合わせ、API や MCP server エンドポイントを呼び出して作り込みます。

Service provider は、自社で作ったエージェントを Google Cloud Marketplace で配布する事業者です。

Administrator は、組織にエージェントを展開し、設定して回していく担当者です。データストアの接続、エージェントギャラリーの有効化、モデル選択の制御などを管理します。

ここから先は、自社内で展開する側と SaaS として乗せる側、ふたつの事例に入ります。

大企業内部で AIエージェントを浸透させた事例

ここからが TCS(Tata Consultancy Services)が社内で進めている AI 変革プログラム、tcsAI の話です。インド発の大手 IT サービス企業で、売上約300億ドル、社員数58万4千人。うち15万人が Workspace を、3万人が Gemini Enterprise を使っています。

自社の AI 変革を「3つのミッション」に分けて展開しているのが特徴で、個人を助ける、チームを助ける、事業全体をエージェント化する、と段階的に進めています。

Mission 1: 個人を助ける

最初のミッションは、全社員一人ひとりが個人の AI を持てるようにすることです。Gemini Chat、Deep Research、NotebookLM を全社員に配布し、4,500人の早期利用者から45日で3万人の AI 実践者に拡大しました。

ヘルスケア領域の営業担当は、Deep Research のおかげで顧客との10分のミーティングが45分の議論やワークショップに変わった、と語っていました。

成果としては、500人以上の AI チャンピオン、94%のユーザジャーニー完了率、70%以上の週次リテンション、年換算で12万8千時間の節約効果が出ています。

Mission 2: チームを助ける

ふたつめのミッションは、社員自身がエージェントを作ってチーム内で共有できるようにすることです。Agent Designer を使って各自がペルソナや役割に応じたエージェントを作り、それをチーム全体で使い回します。最初の4週間で6,850個以上のエージェントが生まれました。

実際に作られたエージェントには、営業の伴走役(Sales co-worker)、ソリューション品質とコンプライアンスの検証役、競合の監視役、プログラム計画の組み立て役などがあります。効果として、個人の効率が2倍、チームの成果が3倍に伸びています。

Workspace、M365 / SharePoint / OneDrive、Web 検索といった幅広いコネクターを束ねており、60万人規模での導入は、相互運用ソリューションとしては最大級です。

Mission 3: 事業全体に広げる

みっつめのミッションは、ツールとしての AI から、業務の中に組み込まれた AI への移行です。

ここでは3つの方向が示されました。

  • コンテキストが王様(Context is king): モデルではなく、自社のデータと文脈が勝負を分けます。
  • アプリは会話に移る(Apps move to conversations): エンタープライズのコネクターやアクションが Gemini との対話の中に出てきます。
  • 事業と IT の境界は溶ける(Boundaries between Business and IT dissolve): 業務側がエージェントを作り、IT がプラットフォームを管理する形に変わります。

事業全体をエージェント化する取り組みの第一歩として進んでいるのが、営業プロセス全体をエージェントに任せる試みです。TCS はこれを「エージェントによる営業」(Agentic selling)と呼んでいます。

中心に オーケストレーター がいて、継続的に学習しながら全体を指揮します。その周りに、見込み発掘(Prospecting)、提案作成(Solutioning)、競合対応(Competing)、交渉(Negotiating)という4つの役割があり、それぞれに3〜4個の専門エージェントが配置されます。

人間がやっていた工程との対比は次の通りです。

工程 従来 エージェント化後
リサーチ 3〜4日 AI による先回りインサイト 30分以内
意思決定者の特定 2〜3日 深い人物プロファイリング 30分以内
提案書の作成 2週間以上 文脈に応じた PoV 2時間以内
ピッチの作成 1週間 解決策と物語の組み立て 数時間

工程の長さが日単位・週単位から、時間単位・分単位に変わっています。

結果として、パイプラインの約25%が AI の影響を受け、勝率は1500bps 改善、応答時間は50%短縮、ディール期間は15〜20%短縮しています。

4つの教訓

自社展開を通じての学びは4つあります。

  1. 賢さよりコンテキストが効く(Context beats intelligence): 勝負を分けるのは、どのモデルを使うかではなく、自社のデータと文脈です。
  2. 責任ある AI は最初から組み込む(Upfront responsible AI): ガバナンスは事後に貼り付けるのではなく、最初から仕組みに織り込みます。アクセス制御、Model Armor、ログ、各種フィルタ、レッドチームまでを最初の段階で並べて考えます。
  3. AI がプロダクト運営モデルを強化する(AI reinforces product operating model): IT と事業がプロダクトと成果をともに所有する形になり、どちらかが待つ動きがなくなります。
  4. 社内の証拠が市場の物語になる(Internal proof = Market story): 自社のために作ったエージェントが、そのまま顧客への提案の証拠になります。

SaaS として Workspace に乗せる事例

3社目に登場したのが LumApps。フランス・リヨン発の、社員向け社内ポータル SaaS です。

2,200社以上の顧客、社員数650人以上、11拠点・8カ国に展開し、LumApps AI Employee Hub で繋がっている社員数は700万人以上に達しています。

解こうとした問題

問題意識はシンプルです。ツールを増やしても、生産性は上がりません。

調査の数字も引かれていました。1社あたり平均112アプリ。62%の企業が現場の社員に届けるために4〜6種類のアプリを使っています(Forrester, 2022)。36%の社員が必要な情報にうまくアクセスできずに困っており(Forrester, 2022)、毎日2時間がアプリ間の切替や情報検索で消えています(Gartner Digital Worker Survey, 2024)。

LumApps はこの「断片化のコスト」を一箇所に集約することで解こうとしています。

LumApps AI プラットフォームの構成

LumApps の AI プラットフォームは、Google の Gemini Enterprise Agent Platform を内側に組み込みつつ、その周りに Agent firewall、Agent router、Agent monitoring などを独自に積み上げています。

外側には認証ゲートウェイがあり、Atlassian、Salesforce、Looker、Box、Drive などのコネクターから企業内のツール群と接続します。LLM 推論や出力の整合性は Agent Platform 側に寄せ、社内データの権限制御や監視は LumApps 側で持ちます。

すべてをゼロから作るのではなく、Google のサービスは最大限使った上で、SaaS として必要な独自レイヤだけを上に重ねています。

3つのデモ

エージェントが現場でどう使われるかを、デモ3つで見せていました。

ひとつめは、散らばった社内文書から正しい答えを引き出す デモです。本部の指示文書が複数の競合バージョンに散らばっている問題に対して、RAG と Agent Platform に組み込まれたコネクター(Native Agent Platform Connector)を組み合わせ、Drive のデータをリアルタイムに参照して、統一されたチャット画面から「正しい一次情報」を引き当てます。

ふたつめは、本社の指示文書から店舗向けの配信記事を自動生成する デモです。100店舗以上に向けて手作業で記事を作るのは時間もかかればミスも出ます。AI エージェントが「文書を読む」から「記事を書く」「配信先を絞る」までのワークフローを自動化します。裏側では Gemini が処理を回し、画像生成には Nano Banana が使われます。

みっつめは、モバイルプッシュで現場に直接届ける デモです。店舗スタッフはメールを開かないので、重要な指示が読まれずに落ちてしまいます。LumApps はメール経由ではなく、Firebase Cloud Messaging や APNS を使い、店員のモバイル端末に直接プッシュ通知で届けます。要約付きでひと目で読める形にして、必須タスクとして表示します。

次に来るもの

今後の方向性は3つあります。

  • 音声インターフェース: 手が塞がっている現場のために、音声から構造化された意図への変換と、リアルタイム翻訳を視野に入れています。Gemini-TTS や Chirp 3 Multimodal Live API が候補に挙がっています。
  • 自律エージェント: 静的なワークフローではなく、プラットフォーム上の活動を見ながら自分で判断して動くエージェントです。BigQuery と PubSub の活用が検討されています。
  • エージェント配布のランチパッド構想: エージェントの運用に必要なシステム、ガバナンス、ナレッジを一箇所に集める発想で、MCP と A2A での標準化を進め、Gemini Enterprise エコシステムへの統合を深めていく方向です。

おわりに

このセッションで繰り返し出てきたのが「コンテキストが効く」という言葉でした。TCS は4つの教訓の筆頭にこれを挙げていましたし、Agentic selling のオーケストレーターも、社内のデータや文脈をもとに各エージェントを動かしていく作りでした。LumApps のデモでも、RAG と Drive コネクターを組み合わせて社内の一次情報に届かせる、という設計が見えました。

実装している身としては、本当にその通りだなと思います。新しいモデルが出ると試したくなりますが、現場で本当に差を生むのは、社内データをどう繋ぐか、どう権限を管理するか、どう一次情報まで辿り着かせるか、のほうです。エージェント開発の難所は、モデル選びから自社のデータ整備に移ってきている、というのが正直な実感です。

そう考えると見えてくるのが、社員一人ひとりやチームのまわりに小さなエージェントが行き渡っていく、という未来の姿でした。TCS の6,850個、LumApps が業務ごとに作っていく姿、どちらも「全社で1つの大きな AI」ではなく、現場の業務単位でエージェントが分担している方向に向かっています。大きな構想を一気に展開するより、業務に近いところで小さく動かして、ガバナンス層がそれを見渡す形のほうが、現実的にうまく回りそうです。「次はどんなエージェントを作ろうか」と、つい考え始めたくなる、わくわくするセッションでした！