はじめに
2026年7月30日、東京ビッグサイトで開催された「Google Cloud Next Tokyo」のDay 1に参加してきました。
今年のイベントでは、AIエージェントをはじめとする「Agentic AI」や、Geminiを活用した企業向けソリューションが大きく取り上げられていました。
会場のExpoエリアでは、Google Cloudの最新技術だけでなく、国内外の企業による具体的な導入事例やデモも数多く展示されていました。公式案内でも、最新のAgentic AIとクラウドを体験できる場としてExpoが紹介されています。
この記事では、次の内容を中心に、現地で感じたことをまとめます。
- Agentic AIを中心としたExpoエリアの様子
- エンタープライズでAIエージェントを実装する際のアーキテクチャ
- Google Cloudの全資格保持者として受け取った認定バッジ
- 今後、自分で検証してみたいこと
本記事は、Google Cloud Next Tokyoに参加した筆者個人の感想と技術的な考察です。Google Cloudの公式見解を示すものではありません。
Agentic AIとクラウドが交差するExpoエリア
今回のGoogle Cloud Next Tokyoで特に印象に残ったのは、単なる生成AIの活用にとどまらず、AIがツールやデータを利用しながら処理を進める「Agentic AI」の展示やセッションです。
Expoエリアでは、Google Cloudやスポンサー企業のブースを通じて、AIエージェント、データ分析、セキュリティ、Google Workspaceなど、さまざまな領域の活用事例が紹介されていました。
多くの参加者が足を止め、説明員の方に質問したり、デモを見たりしている姿が印象的でした。
私自身、普段から次のようなGoogle Cloudサービスに触れています。
- Vertex AI
- Cloud Run
- Identity-Aware Proxy（IAP）
- Secret Manager
- Cloud Key Management Service（Cloud KMS）
今回の展示を通じて、これらのサービスがAIエージェントの基盤としてどのように組み合わされ、エンタープライズ環境で安全に運用されるのか、より具体的にイメージできるようになりました。
AIモデルを動かすだけではなく、開発、デプロイ、認証・認可、監視、運用まで含めたライフサイクル全体をどのように設計するか。
アーキテクトの視点では、そこが非常に興味深いポイントでした。
考察：Vertex AIとCloud Runで構成するAgentic AI
展示やセッションを通じて、特に思考を刺激されたのが、AIエージェントを本番環境へどのように展開するかというアーキテクチャの観点です。
私は先日、LangGraphとOllamaを利用し、Human-in-the-loopを含むブログ執筆・レビュー用のマルチエージェントシステムをローカル環境で構築しました。
この経験を踏まえてGoogle Cloudのサービスへマッピングすると、Vertex AIとCloud Runの組み合わせは、エンタープライズ向けAgentic AIを実装する際の有力な選択肢になりそうだと感じました。
全体構成のイメージ
ユーザー
│
▼
IAP
社内ユーザー向けの認証・アクセス制御
│
▼
Cloud Run
フロントエンド／API
│
▼
Vertex AI Agent Engine
エージェントの実行・管理
│
▼
Gemini
推論・計画・ツール選択
│
├──▶ Cloud Run上のツールAPI
├──▶ 社内システム
├──▶ データベース
└──▶ 外部API
周辺サービス
├── IAM／サービスアカウント：サービス間の認証・認可
├── Secret Manager：APIキーやパスワードの管理
├── Cloud KMS：暗号鍵やCMEKの管理
└── Eventarc／Cloud Tasks：イベント駆動・非同期処理
これは今回のイベントで公式に提示された唯一の構成という意味ではなく、私が展示内容と自身の開発経験から考えた構成例です。
1. エージェントの中核：Vertex AI Agent Engine
エージェントの実行・管理基盤としては、Vertex AI Agent Engineが重要な役割を担います。
Vertex AI Agent Builderは、本番環境でAIエージェントを構築、スケーリング、管理するためのプロダクト群として提供されています。
Geminiを利用した推論に加えて、エージェントには次のような役割を持たせられます。
- ユーザーから依頼された内容の理解
- タスクの分解
- 実行手順の計画
- 呼び出すツールの選択
- ツールの実行結果を踏まえた次の判断
- 最終的な回答の生成
ローカル環境でLangGraphなどを使って構築したワークフローを、Google Cloud上のマネージドな基盤と組み合わせていくイメージです。
すべてをマネージドサービスに寄せるのか、オーケストレーションの一部を独自実装するのかは、システムの要件によって変わりそうです。
2. ツールの実行環境：Cloud Run
AIエージェントが呼び出すツールや独自APIの実行環境として、Cloud Runは非常に使いやすいサービスです。
たとえば、次のような処理をそれぞれコンテナ化してCloud Runへ配置できます。
- 社内データを検索するAPI
- 外部サービスと連携するAPI
- ドキュメントを生成する処理
- データを検証・変換する処理
- LangGraphなどで実装した独自ワークフロー
- AIエージェントから呼び出す業務ロジック
Cloud Runは、イベント駆動のサービスやコンテナ化したジョブを実行でき、負荷に応じてゼロから自動的にスケールさせることもできます。
ただし、非同期処理をCloud Runだけで完結させるのではなく、要件に応じて次のサービスを組み合わせる必要があります。
- Eventarc：Google Cloud上で発生したイベントを処理する
- Cloud Tasks：非同期タスクの実行、再試行、流量制御を行う
- Pub/Sub：サービス間を疎結合にしてメッセージを連携する
- Cloud Run Jobs：バッチ処理や完了まで実行する処理を動かす
AIエージェントの処理時間やトラフィックは予測しにくいため、同期処理と非同期処理を適切に分けることが重要になりそうです。
3. 認証・認可：IAP、IAM、サービスアカウント
Agentic AIでは、AIが自律的にツールを呼び出すため、「誰が何を実行できるか」を従来以上に厳密に管理する必要があります。
社内ユーザーが利用するWebアプリケーションであれば、IAPを利用して、認証済み・認可済みのユーザーだけがアクセスできるようにする構成が考えられます。
IAPは、Cloud Runなどで動作するアプリケーションへのアクセスを、ユーザーのIDに基づいて制御するサービスです。
一方、AIエージェントからCloud Run上のツールAPIを呼び出すようなサービス間通信では、IAMとサービスアカウントを利用します。
それぞれのエージェントやツールに専用のサービスアカウントを割り当て、必要最小限の権限だけを付与することが重要です。
たとえば、「ドキュメントを検索するエージェント」に、データの削除権限まで与える必要はありません。
AIエージェントだから特別なセキュリティ対策を行うというよりも、従来のクラウドネイティブなベストプラクティスを、より厳密に適用する必要があると感じました。
4. 機密情報と暗号鍵：Secret ManagerとCloud KMS
外部APIのAPIキー、パスワード、証明書などを管理する場合は、Secret Managerを利用します。
Secret Managerは、APIキー、ユーザー名、パスワード、証明書などの機密情報を保存・管理するためのサービスです。
一方、Cloud KMSは、データの暗号化に使用する暗号鍵を作成・管理し、暗号化や復号などの暗号処理を行うためのサービスです。
役割を整理すると、次のようになります。
| サービス | 主な用途 |
|---|---|
| Secret Manager | APIキー、パスワード、証明書などの機密情報 |
| Cloud KMS | 暗号鍵の作成・管理、暗号化・復号、CMEK |
| IAM | ユーザーやサービスアカウントの権限管理 |
| IAP | 人が利用するWebアプリケーションへのアクセス制御 |
AIエージェントが利用する権限や機密情報をまとめて共有するのではなく、エージェントやツールごとに分離することが重要です。
「最も賢いAI」より「安全に運用できるAI」
今回の展示を見て改めて感じたのは、エンタープライズでAgentic AIを活用する場合、モデルの性能だけではシステムが成立しないということです。
実際の業務で利用するためには、少なくとも次のような仕組みが必要になります。
- 認証・認可
- 最小権限の設計
- ツール呼び出しの制限
- 実行履歴の記録
- モニタリング
- エラー時の再試行
- コスト管理
- Human-in-the-loop
- 誤操作を止めるためのガードレール
特にAIエージェントがデータ更新や外部システムの操作を行う場合、すべてを完全に自律化するのではなく、人による確認をどこに残すかが重要になります。
「最も賢いAIを使うこと」だけでなく、「安全に止められること」や「後から行動を確認できること」が、エンタープライズでは大きな価値になると感じました。
認定資格者ラウンジエリアでの特別な体験
今回、個人的なハイライトの一つとなったのが、認定資格者ラウンジへの訪問です。
私はこれまで継続してGoogle Cloudの資格取得に取り組み、対象となるすべての認定資格を取得しています。
今回は会場で、全資格保持者を示す特別な認定バッジを受け取ることができました。
これまで地道に続けてきた学習や資格取得が、このように目に見える形になると、やはりモチベーションが上がります。
会場で同じバッジを付けている方やエキスパートの方々と、
「どの試験が一番難しかったか」
「今後、どの分野を学んでいくか」
といった話ができたことも、オフラインイベントならではの体験でした。
オンラインで技術情報を収集するだけでは得られない、人とのつながりもイベントの大きな魅力だと思います。
まとめ
Google Cloud Next Tokyo '26 Day 1では、AIが単に質問へ回答する段階から、ツールやデータを利用しながら業務を進める段階へ移りつつあることを実感しました。
特に印象に残ったのは、次の点です。
- Agentic AIが具体的な業務やサービスへ組み込まれ始めている
- AIエージェントの本番運用では、モデル以外の基盤が重要になる
- Vertex AIとCloud Runは、Agentic AIを実装するうえで有力な組み合わせになる
- IAP、IAM、サービスアカウントを使ったアクセス制御が欠かせない
- Secret ManagerとCloud KMSを用途に応じて使い分ける必要がある
- 完全自律化だけでなく、Human-in-the-loopや監査性が重要になる
今回得た知見については、自分でも実際に手を動かして検証していきたいと考えています。
まずは、先日構築したLangGraphとOllamaによるブログ執筆AIエージェントをベースに、次のような構成を試してみたいです。
- Geminiを利用した推論処理
- Vertex AI Agent Engineへのエージェント展開
- Cloud RunへのツールAPIの配置
- Secret Managerを利用した機密情報の管理
- IAMとサービスアカウントによる最小権限化
- Human-in-the-loopを含む承認フロー
- Cloud LoggingやCloud Monitoringによる可観測性の確保
検証結果については、改めてQiitaやZennで技術記事としてアウトプットしていく予定です。
Day 2に参加される皆さんも、ぜひ現地で最新のGoogle CloudとAgentic AIを体験してみてください。