G-gen の高宮です。当記事は、Google Cloud Next '25 Tokyo の1日目に行われた スポンサーセッション「 Google Cloud + GitLab で作る最高のソフトウェア開発環境の作り方 」 のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 GitLab合同会社の概要 なぜ開発環境は整備すべきか 迅速に開発環境を展開 人とAIによるレビューで品質の向上 セキュリティスキャンの必須化と脆弱性への対応 快適な開発環境の構築例 開発環境の構成 チームワークを健康に保てるレビュー環境 DevSecOpsのアーキテクチャ 関連記事 セッションの概要 本セッションでは、 GitLab合同会社の小松原つかさ氏から GitLab と Cloud WorkStations を使用した快適なソフトウェア開発環境が紹介されました。 GitLab合同会社の概要 GitLab合同会社は、開発ライフサイクル全体を単一のアプリケーションで提供するDevOpsプラットフォーム GitLab の日本法人です。 GitLab は2年連続で『2024 Gartner® Magic Quadrant™ for DevOps Platforms』においてリーダーの1社として評価され、さらに「実行能力」と「ビジョンの完全性」で最上位の評価を獲得しています。 また、Google Cloud パートナー アワードの「2025 テクノロジー パートナー オブ ザ イヤー - アプリケーション開発 - DevOps」を受賞しています。 参考： GitLab named a Leader in the Gartner® Magic Quadrant™ 参考： GitLabのパートナープロフィール なぜ開発環境は整備すべきか 以下の3つの観点で開発環境を整備する必要があり、これらを満たすことで、 品質とアジリティ の向上が期待できると発表されました。 迅速に開発環境を展開 ソフトウェア開発において各開発者がローカルPCに開発環境を構築して開発をすることが多いです。その際、手順書に沿って環境を構築するケースでは、開発者のスキルによっては、独力では環境構築が完結しない場合があります。 また、複数の開発を同一の端末で行っている場合、ツールのバージョンを誤ってアップ・ダウングレードする場合があります。 環境構築がうまくいかない場合や、ツールのバージョン差異が発生した場合、開発者本人だけではなく、他の開発者の時間も奪われてしまうので、 迅速に展開可能な開発環境 の整備は重要です。 人とAIによるレビューで品質の向上 ソフトウェア開発において生成AIの利用に伴い、成果物が完成する速度は飛躍的に向上しています。そうした状況の中では、レビュワーには日々大量のレビュー依頼があり、パンクしている状況で、レビューが形骸化することがあります。また、レビューの指摘内容によっては、チームワークが悪化する可能性もあります。 このような課題に対処するために、人だけでなく、 AIも活用する ことで 高速に必ずレビューを実施できる環境 を構築することが重要です。また、コードだけでなく 実際に動作する環境 でのレビューを実施できる環境の構築も品質向上のためには必要です。 セキュリティスキャンの必須化と脆弱性への対応 セキュリティスキャンとは、アプリケーションのソースコードや実行環境を自動的に分析し、潜在的な脆弱性を検出するプロセスです。脆弱性は、攻撃者にとって格好の侵入経路となり、脆弱性を放置することは、不正アクセス、データ漏洩、サービス停止などのサイバー攻撃を招く大きなリスクとなります。セキュリティインシデントが発生すると、企業のブランドイメージや顧客からの信頼は大きく損なわれる可能性があります。また、訴訟や多額の賠償金など、法的なリスクや経済的な損失を伴う可能性があります。 このようなリスクを未然に防ぐためにも、 セキュリティスキャンジョブをスキップできない環境 と、進化する 生成AIでのコーディング支援 を使用して、脆弱性に適切に対応し修正することが重要です。 快適な開発環境の構築例 開発環境の構成 本セッションでは、快適な開発環境として、 Cloud WorkStations と GitLab を使用した構成が紹介されました。 Cloud WorkStations クラウド上で動作するフルマネージドの仮想開発環境を提供するサービスです。開発者は、ローカルPCに複雑な開発環境を構築することなく、ブラウザやローカルのIDE（統合開発環境）から、セキュアで一貫性のある開発環境にアクセスできます。 参考： Cloud Workstations の概要 Cloud WorkStations を使用し、環境をイメージ化し展開することで、全開発者で迅速に同一のセキュアな環境で開発を行うことが可能です。 また Cloud WorkStations については、以下の当社記事で詳しく解説しています。 blog.g-gen.co.jp GitLabは、Gitリポジトリ管理、CI/CD、セキュリティ、プロジェクト管理など、ソフトウェア開発のライフサイクル全体をカバーする統合DevSecOpsプラットフォームです。 GitLab を使用することでソースコード管理だけでなく、ビルド、テストとセキュリティスキャンの実施、実際に動作する環境へのデプロイも行うことが可能です。また、開発における工程管理もソースコードと連動させて行うことができます。 参考： GitLab チームワークを健康に保てるレビュー環境 チームワークを健康に保てるレビューのために、 GitLab Duo のコードレビュー機能を使用します。マージリクエストで Duo をアサインし、レビューを実施します。AI がレビューすることで、以下のメリットがあります。 必ずレビューが実施される 開発者が指摘の内容を受け入れやすい また、事前に Duo にコードレビューの観点を指示することで、人がレビューする時と近いレベルでレビューが可能になります。そうすることで、人は要件が網羅されているかなど、本質的な部分の確認に注力することが可能です。 参考： GitLab Duo 参考： Have GitLab Duo review your code DevSecOpsのアーキテクチャ 下図に示すアーキテクチャで、DevSecOps を実現します。 GKE でのアーキテクチャ Cloud Run でのアーキテクチャ ソースコードのビルド時にSAST（Static Application Security Testing）、Google Cloud へのアプリデプロイ後にDAST （Dynamic Application Security Testing）を行うことで、開発の早期の段階で脆弱性を検出し、対処することが可能です。 GitLab では、公式 CI/CD テンプレートが提供されており、特別な設定をすることなくセキュリティスキャンを有効にできます。 参考： Static Application Security Testing (SAST) 参考： Dynamic Application Security Testing (DAST) このようにして検出した脆弱性に対して、 GitLab Duo などの AI を活用し修正を行うことで、形骸化を回避し、確実に脆弱性に対処する環境を構築することができます。 関連記事 blog.g-gen.co.jp 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。

Google Cloud Next Tokyo '25 の「Next Tokyo イベントアンバサダー」に選出いただきました G-gen の堂原です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われた ブレイクアウトセッション「 もう手放せない！Gemini の NotebookLM、Deep Research、Canvas で思考を加速 」 のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 思考を変革する、新しい情報活用ワークフロー 概要 Deep Research NotebookLM Canvas AbemaTV のユースケースご紹介 概要 文章作成 調査業務 社内データ活用 関連記事 セッションの概要 本セッションでは、 Google の AI ツールである Deep Research 、 NotebookLM 及び Canvas の活用方法と、株式会社 AbemaTV 社での実際の活用例について紹介されました。 思考を変革する、新しい情報活用ワークフロー 概要 前半パートでは、Google Cloud 社の服部氏より、Deep Research、NotebookLM 及び Canvas を活用した新しい情報活用ワークフローが紹介されました。 業務において情報を活用するための大きなフローである 情報の収集 集約・整理・分析 アウトプット それぞれのフェーズにおける、Deep Research、NotebookLM、Canvas の有用性が紹介されました。 Deep Research Deep Research は、以下のような情報収集における必要なフローを数分で完結させることができます。 Deep Research は与えられたプロンプトをただ文字通りに検索するのではなく、その目的を理解し、調査を複数のステップに落とし込みます。そして最大 100 種類のウェブサイトを自動的に検索し、得られたデータを統合し、整合性が取れるように適宜修正します。調査結果は最終的に引用元へのリンクを含んだレポートとして出力されます。 NotebookLM NotebookLM では、議事録等といった社内データや Deep Research が出力したレポートなどの情報の集約・整理・分析をすることができます。 NotebookLM は Google Docs や Google Slide、YouTube、PDF 等といった複数のデータ形式に対応しています。また、全ての回答には適切な引用元へのリンクが付いているため、ハルシネーションが起きにくいです。更に、音声としての出力も可能という特徴も持っています。 Canvas Canvas は与えられた情報の整理を行いアウトプットとします。文章としてのアウトプットはもちろん、HTML・CSV・JavaScript によるページを作成することも可能です。 AbemaTV のユースケースご紹介 概要 後半パートでは、AbemaTV 社の上田氏より、AbemaTV 社における Google の生成 AI ツールの具体的な活用例が紹介されました。 AbemaTV 社では、文章作成や調査業務、社内データ活用といった業務において Gemini が活用されています。 文章作成 文章作成においては、メールや議事録、企画の提案資料などといった様々な文章作成を Gemini が支援しています。Gemini は資料のたたき台を瞬時に作成し、メール作成や要約・議事録作成を大幅に効率化します。また企画創案のアイデア出しも支援してくれます。 具体例として、Gmail でのメール作成支援や Gem をプレゼンテーション作成アドバイザーとして活用しているケースが紹介されました。 Gmail でのメール作成支援 Gem による、プレゼンテーション作成アドバイザー 調査業務 調査業務においては Deep Research が活用されています。市場調査や競合分析を Gemini が代行し、膨大な情報からレポートの作成を行ってくれます。 社内データ活用 社内データ活用においては NotebookLM が用いられています。 具体例として、社員の自己紹介スライドをデータソースとしたオンボーディング用 NotebookLM や、文章化されたデザインポリシーに関する FAQ システムとして NotebookLM を活用するケースが紹介されました。 オンボーディング NotebookLM デザインポリシー NotebookLM 関連記事 blog.g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の奥田です。当記事は、Google Cloud Next '25 Tokyo の1日目に行われたブレイクアウトセッション「 生成AI活用を進めるゴルフダイジェスト・オンライン（GDO）が Google Cloud で実現したい未来 」のレポートです。 他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 GDO 社の概要 データ活用による課題 1.データカオスの発生 2. データの民主化 3. 生成 AI の活用 Looker での解決 セマンティックレイヤー Explore Assistant Dashboard Summarization GDO 社による生成 AI 活用の取り組み 『GDO 店員さん AI』 カスタマーパーソナライズDB 関連記事 セッションの概要 本セッションでは、ゴルフダイジェスト・オンライン社（以下、GDO社）のデータに関する課題と、その解決策としての Looker が紹介されました。 GDO 社の概要 GDO 社は「ゴルフで世界をつなぐ」をミッションにゴルフに関する以下のサービスを展開しています。 ゴルフメディア ゴルフ用品販売 ゴルフレッスン ゴルフ場予約 ゴルフ練習場事業 スコア管理 また、2024年には生成 AI を活用した PoC（概念実証）を開始しました。 データ活用による課題 GDO 社は、データ活用において以下３点の課題があると発表しました。 1.データカオスの発生 データ抽出には SQL の知識が必須であったため担当者が限定され、ビジネスユーザーへのデータ提供が滞るボトルネックが生じていました。この状況を解消するため各部署が個別の BI ツールや基幹システムを導入した結果、かえってツールが乱立してしまい、部署をまたいでデータを分析する際には都度データ定義のすり合わせが必要になる、といった課題がありました。 2. データの民主化 SQL の知識が必要なデータ抽出が、社内でのデータ活用の属人化を招いていました。この課題に対し、自然言語で誰もがデータにアクセスできる「データの民主化」を推進する必要がありました。その解決策として Gemini in Looker の機能である 会話型分析（Conversational Analytics） の導入により、自然言語でのデータ集計・検索・可視化を目指すとしています。 参考 : Conversational Analytics in Looker 3. 生成 AI の活用 GDO 社では生成 AI を組み込んだサービスを2024年からラボ型開発組織で実装し、エンドユーザーに向けてテストを始めており、以下の取り組みが紹介されました。 対話型予約 AI ゴルフ場予約サービスに導入し、主にゴルフ初心者のユーザーに向けてゴルフ場を選ぶためのアドバイスをするチャットボットを使用しました。 チャットボットは商品マスタと口コミを学習しており、パーソナルな提案を実現しました。 Looker での解決 セッションの後半では、Google Cloud よりこれらの課題に対する Looker を用いた解決策が紹介されました。 セマンティックレイヤー セマンティックレイヤー を用いることで、部署毎に異なっていたデータの定義を統一できることが紹介されました。セマンティックレイヤーは、元となるデータをビジネスユーザーやAIが理解できる言葉に変換する層のことで、Looker では LookML という言語を用いて構築します。 参考 : Looker のモデリング 参考 : GoogleのBIツール、LookerとLooker Studioを比較してみた - G-gen Tech Blog このセマンティックレイヤーによって信頼性が担保されたデータ基盤が、ビジネス成果に繋がります。 Looker 上のデータを元にターゲットの選定やマーケティング施策の立案ができますが、そのためには信頼できるデータ基盤が不可欠です。本セッションでは、信頼できるAI 基盤の構築には、まず信頼できるデータ基盤が必要であることが強調されました。 生成 AI が情報を分析する上でもセマンティックレイヤーは重要です。セマンティックレイヤーで定義を明確にすることで、生成 AI からのレスポンスのエラーを 最大で3分の2削減できる と発表しました。 Explore Assistant データの活用が進むほど、社内特有の用語や要望に答える必要があります。 そのための解決策としてオープンソースの Explore Assistant が紹介されました。 Explore Assistant については、以下の記事で詳しく解説しています。 blog.g-gen.co.jp Dashboard Summarization また、ダッシュボードの要約が必要な際に活用できる、オープンソースの Dashboard Summarization も紹介されました。 Dashboard Summarization については、以下の記事で詳しく解説しています。 blog.g-gen.co.jp GDO 社による生成 AI 活用の取り組み 『GDO 店員さん AI』 前述の対話型予約 AI の様な、 顧客がゴルフを楽しむための全ての体験をサポートする AI を導入することを目指します。 カスタマーパーソナライズDB 顧客の属性 や ゴルフのプレー履歴 といった情報だけでなく、 ライフスタイル や 閲覧メディア などの個人情報も一括管理するデータベースを構築し、広告の強化や購買促進に繋げることを目指します。 GDO 社は、製品情報や顧客情報管理をさらに強化するため、 今後も Looker を活用していきたい と述べました。 関連記事 blog.g-gen.co.jp Risa (記事一覧) クラウドソリューション部クラウドデベロッパー課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資格保有。日々修行中です！ Follow @risa_hochiminh

G-gen の杉村です。当記事では、Google Cloud Next Tokyo '25 の、1日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next Tokyo '25 イベント概要 キーノートの概要 AI エージェント メディア生成 AI Agent Development Kit（ADK） Google Agentspace 株式会社 MIXI の事例 株式会社メルカリの事例 クリエイティブエージェント AI 関連の補償 Google Workspace with Gemini 株式会社博報堂の事例 札幌市の事例 関連記事 Google Cloud Next Tokyo '25 イベント概要 Google Cloud の旗艦イベントである Google Cloud Next の東京版である Google Cloud Next Tokyo '25 は、2025年8月5日(火)と6日(水)の2日間で開催されます。本年は、東京ビッグサイトで開催されました。 東京ビッグサイト ゆりかもめ「東京ビッグサイト」駅構内 Expo エリア（開場前） 初日のキーノート（基調講演）では、Google が最も強調したい内容が発表されます。本投稿では、Google Cloud Next Tokyo '25 の第1日目のキーノート（基調講演）で行われた発表の概要をお伝えします。 G-gen Tech Blog では、Google Cloud Next Tokyo '25 に関連する記事を随時発信します。 blog.g-gen.co.jp キーノートの概要 Google Cloud Next の開幕を飾る初日のキーノート（基調講演）では、Google Cloud の AI や AI エージェントに関連する顧客事例が紹介されました。 今回のキーノートでは、技術的な新発表はほとんどなく、事例紹介が中心でした。ただし、以下は今回の講演で初めて発表された情報であると思われます。 Gemini 2.5 Flash に東京リージョンエンドポイントが登場予定 Google Agentspace が日本リージョンに対応予定 Generative AI Leader 試験が日本語に対応 当講演では、Vertex AI、Vertex AI Search、Gemini、Veo などの AI モデル、Google Agentspace などの既存の AI 系プロダクトの紹介が改めて行われ、またそれらを活用した事例が、MIXI、メルカリ、博報堂、そして札幌市の登壇者により発表されました。 キーノート会場 AI エージェント 最初に登場したのは、Google Cloud Japan の代表、平手智行氏です。 2025年が「AI エージェント元年」と呼ばれていることに言及し、AI エージェントが分断された情報を繋いだり、エンドツーエンドの業務自動化、またスキル・人材不足を解消するためのキーとなることを強調しました。 Google Cloud において、Vertex AI が、AI 開発のインフラからアプリケーションまでを一気通貫でサポートするプラットフォームであることを改めて強調し、また Google Distrbuted Cloud が、セキュリティ・統制やレイテンシの非常に厳しい要件にも対応できることを紹介しました。 Google Cloud Japan 代表 平手智行氏 メディア生成 AI Google の Cloud AI 担当 VP & GM のサウラブ ティワリ氏が登壇し、Imagen（画像）、Veo（動画）、Chirp（音声）、Lyria（音楽）など、メディア系の生成 AI モデルについて紹介しました。 参考 : Google Cloud Next '25 速報レポート - キーノート（1日目） - G-gen Tech Blog - マルチモーダルな AI モデル Google Cloud AI 担当 VP & GM サウラブ ティワリ氏 Veo 3 と Veo 3 Fast は2025年7月に GA された Agent Development Kit（ADK） Agent Development Kit （ADK）は、Google が開発した AI エージェント開発用のフレームワークです。2025年8月現在では、Python 用と Java 用が公開されています。 デジタル庁、日本テレビおよびメルカリが、ADK を使って AI エージェント実装を行っていることが紹介されました。 当社 G-gen でも、Google Cloud Next Tokyo '25 の初日と同日に、AI エージェントを使った独自サービスを公開しています。 参考 : 株式会社G-gen、新サービス G-gen Tech Suite を提供開始 参考 : ナレッジ検索・回答AIエージェントG-gen Tech AgentをADKで開発した事例 Agent Development Kit（ADK）や Agent Engine デジタル庁による ADK の利用 日本テレビとメルカリによる ADK の利用 Google Agentspace Google Agentspace は、Google が提供する AI エージェントプラットフォームです。複数データソースへの横断検索と、AI によるタスク実行が可能です。 Google の鈴木かの子氏および蓮池拓哉氏が、架空のエレベーター管理会社を題材に、Google Agentspace が自律的に呼び出すエージェントを判断して呼び出し、エレベーターの保守のためのワークフローを実行していく様子をデモしました。 Agentspace のデモ ユーザーが Google Agentspace に自然言語で指示すると、複数エージェントが呼び出され、故障予知、優先順位付け、整備担当者をマッチング、ServiceNow にタスクをアサイン、Chatで自動通知などが行われました。1つの指示で、複数のタスクが実行されました。 Google Agentspace は2025年7月31日に一般公開（GA）され、このキーノートでは、日本リージョンへの対応が発表されました。従来の Global リージョンの利用でも使用感としては問題ありませんでしたが、日本リージョンを選択することで、データの所在に関する規制要件などにも対応することができます。 参考 : Google Agentspaceを徹底解説！ - G-gen Tech Blog AI エージェントのメリット 株式会社 MIXI の事例 株式会社 MIXI 代表取締役社長の木村弘毅氏が登壇し、同社における Google Agentspace の事例を紹介しました。 株式会社 MIXI 代表取締役社長 木村弘毅氏 管理業務の自動化によりクリエイティブな業務に時間を使える 単にお金を稼ぐための「ライスワーク」から「ライフワーク」へ 同社は日本で初めて Google Agentspace を導入し、業務利用しています。AI エージェントの活用が進み、セキュリティやコンプライアンスへの対応も課題となった中で、Google Agentspace のカバー範囲が目的に合致したといいます。 AI エージェント統合の基盤として Agentspace を採用 同氏は、コラボ企画案を生成する様子をデモしました。過去のコラボ案件に関する情報を集約し、マーケ効果を可視化、それに基づいて新しいアイデアの提案が行われ、イメージ画像も生成されました。 Agentspace による画像生成 株式会社メルカリの事例 続いて株式会社メルカリの執行役員 CTO、木村 俊也氏が登壇しました。 株式会社メルカリ 執行役員 CTO 木村 俊也氏 同社はカスタマーエージェントとして Customer Engagement Suite with Google AI を利用した事例を紹介しました。カスタマーサポート領域に AI を適用することで、顧客による問題の自己解決を24時間サポートできるようになりました。 また、従来はコストのかかった、日本語以外の多言語対応も、AI により容易になりました。 Customer Engagement Suite with Google AI による顧客対応 AI が解決できなかった問題は人間にエスカレーションされる クリエイティブエージェント Google のカスタマーソリューションズエンジニアである大場勇太氏は、Google が開発したという Scenario Builder を紹介しました。 Scenario Builder これは、Gemini、Veo、Imagen などを組み合わせたソリューションです。新しい広告施策の検討ワークフローを AI によって自動化し、企画案や動画広告の絵コンテ、動画のプロトタイプまでを生成する様子がデモで紹介されました。 このような仕組みにより生成された動画を本格的な撮影のためのたたき台にできるほか、動画の出来によってはそのまま利用することもできます。 複数案をスプレッドシート上で確認 AI 関連の補償 Google の AI に関する補償として「トレーニングデータ補償」「生成出力補償」が紹介されました。 AI 関連補償 これは、著作権に関連する法的リスクについて Google が責任を負うことを示した以下の発表について示したものです。 参考 : 運命の共有: 生成 AI についての補償によるお客様の保護 Google Workspace with Gemini Google Workspace には Gemini が組み込まれており、追加のコストなしで Gemini の強力な AI 機能が利用できます。 また Web 会議ツール Google Meet では AI によるリアルタイム翻訳が実装されており、日本語は未対応ですが、同時通訳のように異なる言語間で翻訳が行われます。 Google Cloud Japan の佐瀬郁恵氏と佐藤芳樹氏が登壇し、様々なユースケースを紹介しました。 Deep Research NotebookLM スプレッドシートの AI 関数 Google Workspace Flows ではメール受信をトリガにタスクを自動化できる Deep Research によるレポート作成、スプレッドシートの AI 関数、また今後より広く公開が予定されている Google Workspace Flows によるワークフローの自動化などが、業務を効率化させます。 なお以下の当社記事では、Google Workspace に組み込みの生成 AI 機能のユースケースについて紹介しています。 参考 : 生成AI「Gemini」をクラウドインテグレーター社員が活用した事例 - G-gen Tech Blog 株式会社博報堂の事例 株式会社博報堂の代表取締役社長、名倉健司氏は、同社における AI 活用事例を紹介しました。 株式会社博報堂 代表取締役社長 名倉健司氏 同氏は、AI は正解を出すために使うものという「従来の AI 観」を脱却し、AI は「別解を生み出すパートナー」であるという新しい AI 観への転換が必要だと説きます。 従来の AI 観には問題があった 新しい AI 観では「別解を生み出すパートナー」とみなす AI 逆メンター制度 同社は Gemini と NotebookLM を全社導入しました。また、マルチクラウドの活用を推進しています。同社では役員が率先して AI を活用し、その知見を動画などで社内発信することで社員への浸透を図っています。社内で AI 活用のナレッジが自律分散的に生まれ、そのナレッジが社内に共有される仕組みを実現しています。 役員が率先して知見を配信 AI 利用率が向上 社内知見の蓄積と共有 NotebookLM の活用 社内に AI エバンジェリストを養成し、有効なプロンプトを社内で共有する。また、役員がそれらを積極的に推進する。このような施策により、同社では AI 活用が推進されています。 札幌市の事例 札幌市のデジタル戦略推進局 情報システム部長の小澤秀弘氏が登壇し、札幌市役所が実現した全庁への Google Workspace 導入の事例を紹介しました。自治体への Google Workspace 導入は近年増加しており、札幌市の導入事例は特に象徴的だったと言えます。 札幌市 デジタル戦略推進局 情報システム部長 小澤秀弘氏 札幌市役所は、ライセンスコストの増大（グループウェア）や情報共有の欠如、資料管理の破綻（メールの往復、バージョン違いファイルの存在）などを課題として抱えていました。その中で、職員の働き方を変えることを目的に Google Workspace を導入し、16,000人のユーザーへの展開を成功させました。既存ツールとの併用を辞めて、原則的に Google Workspace へ完全移行することをゴールとしています。 従来のグループウェアは組織ベース Google Workspace はプロジェクトベース 同氏は、Google Workspace の導入により「組織の壁が溶けた」と表現します。部門ベースだった情報共有とチーム形成は、仕事（プロジェクト）ベースになりました。また Google ドキュメントや Google Meet により「会議が変わった」としています。会議の動画や議事メモは NotebookLM に読み込ませ、議論のパターンやアイデアの発見に活かしています。これにより、会議の回数と1回あたりの時間が短縮されたといいます。 会議が変わった 札幌市役所が内側から変わり始める 関連記事 Google Cloud Next Tokyo '25 の関連記事は、以下の記事一覧をご参照ください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。 Agent Development Kit （ADK）を使い、社内外のドキュメントやナレッジを検索して、技術的な質問に回答する AI エージェントを開発した事例を紹介します。 はじめに 開発したもの 利用可能ユーザー 動作 アーキテクチャ マルチエージェント なぜ AI エージェントなのか インフラ構成 Developer Knowledge MCP Server Agent Search バッチ処理 ADK 関連記事 はじめに 開発したもの 当記事では、G-gen のサービスとして提供されている G-gen Tech Agent の開発事例を紹介します。G-gen Tech Agent は、Google Cloud や Google Workspace に関する技術的な質問に回答するチャットツールです。バックエンドでは AI エージェントが稼働しており、以下のような情報ソースから情報を取得して、その結果を要約して回答を生成します。 Google Cloud 公式ガイド（ https://cloud.google.com/ ） Google Workspace 管理者ヘルプ（ https://support.google.com/ ） G-gen Tech Blog（ https://blog.g-gen.co.jp/ ） G-gen の技術サポート窓口 G-gen Tech Agent の画面 ユーザーが自然言語による質問を行うと、AI エージェントはこれらのソースに対して、Google Cloud の Agent Search （旧称 Vertex AI Search）という仕組みを使ったり、Developer Knowledge MCP Server を使って、ナレッジの検索を行います。 参考 : Agent Searchを徹底解説！ - G-gen Tech Blog 参考 : Developer Knowledge APIをMCPサーバー経由で使ってみた Agent Search の検索結果を、生成 AI モデル Gemini が解釈・要約を行い、ユーザーに対する回答を生成します。 参考 : 全Geminiプロダクトを徹底解説！ - G-gen Tech Blog 公式ドキュメントに加え、G-gen の技術ブログや過去のサポートナレッジに基づいて生成が行われるため、高い精度が期待できます。 G-gen Tech Agent では、上記の「Agent Search や MCP Server による複数データソースへの検索」「その結果を要約して最終回答を作成する」という一連の流れを、 Agent Development Kit （ADK）というフレームワークを使って実装しました。 利用可能ユーザー G-gen Tech Agent は、G-gen の Google Cloud / Google Workspace 請求代行サービスの付帯サービスとして顧客に提供されています。「Google Cloud と Google Workspace の両方で請求代行サービスを契約している」などの提供条件があります。 G-gen Tech Agent は、G-gen 独自の AI ソリューションである G-gen Tech Suite の一部として提供されています。G-gen Tech Suite には G-gen Tech Agent の他に、Google Cloud と Google Workspace の最新技術アップデート情報に関する解説を日本語で閲覧できる G-gen Tech Update という Web サービスも付帯しています。 利用条件など、詳細は営業担当者にお問い合わせください。 参考 : 株式会社G-gen、新サービス G-gen Tech Suite を提供開始 参考 : Google Cloud 請求代行 - 株式会社G-gen 参考 : Google Workspace 請求代行 - 株式会社G-gen 請求代行サービスに無料付帯する G-gen Tech Suite 動作 G-gen Tech Agent は、以下のように動作します。 URL にアクセスすると、Google アカウントでの認証画面が表示されます。認証が完了されると、以下のような画面が表示されます。 G-gen Tech Agent の画面 質問を画面下部のテキストボックスに入力し、送信します。マークダウン形式での入力に対応しており、AI に正しく質問内容を伝えるのに役立ちます。 バックエンドでは複数のデータソースに検索を行い、またそれらを要約するため、回答には30秒ほどかかる場合があります。 エージェントが思考中 回答が生成されました。AI エージェントには、前の会話を引き継いで続けて質問することもできます。また、公式ドキュメントや関連ブログ記事リンクなども表示されます。 生成された回答 関連リンクも表示される 以下のようなユースケースが想定されます。 「Google ドライブで共有ドライブ間でファイルを移動すると、共有リンクは変わってしまいますか？」のような技術的な仕様に関する質問 「Vertex AI で Gemini API を呼び出していますが、 429 RESOURCE_EXHAUSTED というエラーが頻発します。どうしたらいいですか？」といったトラブルシューティング 「BigQuery を学ぶのに役立つコンテンツを教えてください。」など学習目的の質問 なお過去の会話履歴（セッション）は保存され、いつでも呼び出すことができます。この会話履歴は、自分以外の利用者には閲覧されません。ただ、会話履歴をまたいだ情報の参照はされません。つまり、この AI エージェントは過去のセッションでの会話を踏まえた情報の提供や考察などは行いません。 過去の会話履歴は保存される アーキテクチャ マルチエージェント G-gen Tech Agent は、 マルチエージェント構成 です。マルチエージェント構成では、複数の AI エージェントが協働してタスクを遂行します。以下は、エージェント構成を示したものです。 G-gen Tech Agent のマルチエージェント構成 ユーザーが質問を行うとまず、ルートエージェント（root = 根）と呼ばれるエージェントが起動します。このエージェントは SequentialAgent と呼ばれる ADK の Class を用いて構成されています。 SequentialAgent は、複数のエージェントをシーケンシャルに（直列に）実行するものです。このエージェント自体は思考を行わず、単に複数エージェントを直列に実行するワークフローを構成するために存在します。 参考 : ADKのSequential agentsを使って実装するマルチエージェント SequentialAgent の指示に基づき、はじめにデータソース検索エージェントが起動します。このエージェントは ParallelAgent で実装されています。 ParallelAgent も、SequentialAgent と同様に、思考を行わず、複数のエージェントをパラレルに（並列で）実行するためのワークフロー制御を行うエージェントです。この ParallelAgent から呼び出されて、2つのエージェントが同時に起動します。公式ドキュメント検索エージェントと、G-gen ナレッジ検索エージェントです。 これらの検索エージェントは、Tools（エージェントが目的を達成するために使うプログラム群）として Developer Knowledge MCP Server や Agent Search を用いて、Google の公式ドキュメントや G-gen のナレッジに対して検索を行います。パラレルに実行している理由は、回答までの時間を短縮するためです。 これらの検索ツールに対して検索を行う際、エージェントはユーザーからの質問を適切な検索クエリに変換して検索を実行します。この検索クエリ生成には、LLM の特性である 自然言語の解釈が必須 です。ユーザーからの質問をそのまま検索にかけたのでは、適切な検索結果は得られません。データソースに応じて、技術要素をスペース区切りの単語で検索したり、あるいは技術的な要素だけを抽出した自然な質問文に変換して、Developer Knowledge MCP Server や Agent Search に対して検索または質問を実行します。 なお、G-gen ナレッジ検索エージェントは補助的な情報源として、Google 検索グラウンディングを有効化した Gemini による生成も用います。G-gen のナレッジだけを基にするのではなく、一般的なインターネット情報を追加の情報源とできるように、いわばサードオピニオンとして追加しています。 Agent Search から検索結果が得られると、最後に最終回答作成エージェントが起動します。生成 AI モデル Gemini を用いて、前のエージェントが見つけ出した検索結果を統合・要約して、質問者の意図に沿う回答を生成します。 なぜ AI エージェントなのか 当システムを実装するにあたり、単純な RAG 構成等ではなく、ADK を使った AI マルチエージェントという実装を選択した理由として、以下が挙げられます。 AI エージェントおよび ADK の実証実験としての意義 複数のデータソースへの検索を統合して要約するというワークフロー的な処理の性質 前者については、当社が Google Cloud 専業インテグレーターであり、今後顧客に AI エージェントの実装を提案するにあたっての実証実験的な意義がありました。ただし、これはシステムの技術選定における本筋ではありません。 後者のほうが重要です。従来型の RAG では、例えば Gemini における実装であれば、API エンドポイントへ生成リクエストを送信するときに Tools として Google 検索ツールを渡し、グラウンディングを指示します。また Agent Search であれば、あるデータソースをグラウンディング先として指定した Agent Search アプリに対して answer メソッドで回答の生成を指示します。 参考 : Grounding with Google Search 参考 : Get answers and follow-ups これらの生成方法だと、「単一の生成リクエストで1つまたは複数のデータソースに対するグラウンディングを行う」ということはできても、「あるデータソースを根拠とした生成リクエスト A と、別のデータソースを根拠とした生成リクエスト B を統合して、複数の根拠や視点に基づいて結果を生成する」といったことはできません。実際に Agent Search の Blended Search（複数のデータソースに対してグラウンディングを行う機能）を使って Google Cloud の技術に関する質問に回答させたところ、関連度が高いと判断された一部のデータソースに基づいて回答が生成されてしまい、AI エージェント構成とした場合よりも精度が低いものとなりました。 G-gen Tech Agent のユースケースでは、AI エージェントが複数の生成結果を統合することにより精度が高まったため、単純な RAG 構成よりも適切と判断されました。 インフラ構成 G-gen Tech Agent は Web サービスであり、ホストするためにサーバーが必要です。G-gen Tech Agent は、サーバーレスなプラットフォームである Cloud Run にホストされています。 AI エージェントのホスト先として、Google Cloud では他に Gemini Enterprise Agent Platform のプロダクト群の1つである Agent Runtime が挙げられます。今回は、フロントエンドとバックエンドを単一のプラットフォームにホストできること、また類似の社内ツールが以前 Cloud Run で実装されていたことなどから、Cloud Run を採用しました。 参考 : Agent Development Kitでエージェントを開発してAgent Engineにデプロイしてみた インフラ構成図は、以下のとおりです。 インフラ構成図 すべての要素はサーバーレスで実装されています。利用した Google Cloud サービスは以下のとおりです。 Cloud Run（フロントエンド・バックエンド） Vertex AI（生成 AI モデル Gemini の API） Developer Knowledge MCP Server（Google 公式ドキュメントの検索） Agent Search（データソースに対する検索） Agent Platform Sessions（会話履歴の保存） Developer Knowledge MCP Server 当システムでは、Developer Knowledge MCP Server を使って、Google Cloud や Google Workspace の公式ドキュメントに対する検索を行っています。 Developer Knowledge MCP Server とは、Google 公式ドキュメントを検索するための Developer Knowledge API を MCP 経由で利用するための、Google Cloud の公式リモート MCP サーバーです。詳細は以下の記事を参照してください。 blog.g-gen.co.jp Agent Search 当システムでは、Agent Search を使ってデータソースに対する検索を行っています。 G-gen が保有する Web サイトである G-gen Tech Blog に対しては、高度なインデックス登録（Advanced index）が有効化できます。これを行うことで、ウェブサイトに対して単なる単語検索ではなく、自然言語でクエリすると自然言語によって回答が返ってくる answer メソッド が利用可能になります。 参考 : 高度な機能について - ウェブサイトの高度なインデックス登録 参考 : Agent Searchを徹底解説！ - G-gen Tech Blog - Web データストア また、過去サポートケースに基づいた FAQ に対しても、Agent Search の answer メソッドを使っています。データストアは BigQuery に格納された構造化データです。 バッチ処理 G-gen の過去サポートケースについては、過去の顧客とのやりとりを直接的に検索させているわけではありません。日次のバッチ処理で顧客とのやりとりの情報を要約して FAQ 化し、BigQuery に格納したうえで、Agent Search のデータストア化しています。 また FAQ には純粋な技術的な情報のみが含まれており、顧客固有の情報や機密情報、個人情報が入りこまないよう、検知と処理、人間の目によるチェックを行っています。さらに、バッチ処理時やフロントエンド側のシステムプロンプトでも、そういった情報が回答に入りこまないように LLM に指示されており、この対策は信頼度が絶対といえないまでも多層的な対策の一環を担っています。 過去のサポートケースを FAQ 化するための日次のバッチ処理でも、Gemini モデルが使われています。 バッチ処理構成図 ADK 関連記事 以下は、最近の ADK に関する関連記事です。開発にあたり、参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2025年7月のイチオシ Google Cloud（旧称 GCP）アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに 組織のポリシーの Policy Simulator が Preview -> GA Cloud SQL for MySQL/PostgreSQL で書き込みエンドポイントが GA Google Workspace の Gemini 関連の監査ログが強化 Gemini サイドパネルで、Gems が利用可能に Cloud Storage でバケット IP フィルタリングが Preview → GA Vertex AI Search で文字列の完全一致検索が可能に Google Meet のライブストリーミングで参加者がチャット送信可能に Google Drive Events API が Preview 公開 BigQuery でデフォルトの SQL が LegacySQL → GoogleSQL に変更 Vertex AI Agent Engine で Memory Bank が登場（Preview） Gmail に 「サブスクリプションを管理」画面が登場 SCC に Notebook Security Scanner が登場（Preview） Gemini アプリでVeo 3 による動画生成が可能に（一部ユーザーのみ） Vertex AI Search の回答生成モデルで Gemini 2.5 Flash が利用可能 SharePoint から Google ドライブへの移行ツールが Beta → GA Google Cloud Marketplace の自社データ販売機能が Preview → GA Google カレンダーのアポイント予約をメールに直接組み込めるように AppSheet Enterprise Plus エディションで AI Tasks が Preview -> GA Looker Studio レポートで Short query optimized mode が利用可能に BigQueryのパイプ構文が拡張 IAM 編集画面で Gemini による最小権限ロールの提案（Preview） Gemini 2.5 Flash-Lite が Preview → GA（一般公開） Google Maps グラウンディングが米国以外でも利用可能に（Preview） Looker で BigQuery への Optional job creation mode が使われるように Looker Studio レポートに Description（説明欄）が追加できるように Cloud Monitoring の1機能として Cost Explorer が Preview 公開 Code Interpreter が Looker と Looker Studio Pro で 試験運用版 →Preview Vertex AI と Model Armor が統合 (Preview) Gemini for Google Cloud API が BigQuery プロジェクトで自動で有効化 Gemini Notebook に「動画概要」機能が登場 はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 組織のポリシーの Policy Simulator が Preview -> GA Test organization policy changes with Policy Simulator (2025-07-01) 組織のポリシーの Policy Simulator が Preview -> GA。 組織ポリシーの影響を事前にシミュレーションできる。「マネージド制約」や「カスタム制約」 のみで利用可能。通常の従来型の制約では利用できないので注意。 Cloud SQL for MySQL/PostgreSQL で書き込みエンドポイントが GA Cloud SQL for PostgreSQL release notes - July 01, 2025 (2025-07-01) Cloud SQL for MySQL/PostgreSQL で書き込みエンドポイントが Preview → GA。 Enterprise Plus Edition でのみ利用可。プライマリインスタンスのプライベート IP を指す DNS 名。インスタンスがフェイルオーバーしてもアプリ側で向き先を変える必要がない。 Google Workspace の Gemini 関連の監査ログが強化 Access Gemini Audit logs using the Reporting API, the security and audit investigation tools (2025-07-01) Google Workspace の Gemini 関連の監査ログが強化。 Drive、Gmail、Docs 上の Gemini アクションを記録。Security Investigation Tool で閲覧可能なほか、Reporting API で取得可能。 Gemini サイドパネルで、Gems が利用可能に Gems are now available in the side panel of Google Workspace apps (2025-07-02) Gemini サイドパネルで、Gems が利用可能になる。 Gems は事前にカスタムプロンプトを登録しておける機能。これまで Gemini アプリだけで使えたが、今後は Google Drive、Docs、Sheets、Slides、Gmail でも使えるようになる。順次ロールアウト。 Cloud Storage でバケット IP フィルタリングが Preview → GA Bucket IP filtering (2025-07-02) Cloud Storage でバケット IP フィルタリングが Preview → GA。 バケット単位で接続元 IP アドレスや接続元 VPC ネットワークを制限できる。BigQuery へのロードなどの機能が使用できなくなることに注意が必要。 Vertex AI Search で文字列の完全一致検索が可能に AI Applications release notes - July 02, 2025 (2025-07-02) Vertex AI Search で文字列の完全一致検索が可能に。 検索時に文字列をダブルクォーテーション（ " ）で囲うと、文字列完全一致での検索が可能になる。固有名詞や厳密な検索が必要なときに使える。 Google Meet のライブストリーミングで参加者がチャット送信可能に Live stream viewers can now send chat messages, plus additional host controls (2025-07-02) Google Meet のライブストリーミングで参加者がチャット送信可能になった。 管理設定で閲覧者が「チャット送信」「チャット閲覧」できるかどうかを設定できる（デフォルトはいずれも許可）。 Google Drive Events API が Preview 公開 Google Drive Events API now available in Developer Public Preview (2025-07-07) Google Drive Events API が Preview 公開。 Google ドライブのファイル変更通知を Pub/Sub で受け取る等が可能に。従来も notification channel 作成は可能だったが、今回発表の新 API は Google Workspace Events API と統合されており、イベント形式が CloudEvent 形式になっている。より Pub/Sub、Cloud Run 等と統合がしやすくなった。 BigQuery でデフォルトの SQL が LegacySQL → GoogleSQL に変更 BigQuery release notes - July 08, 2025 (2025-07-08) BigQuery で CLI/API のデフォルト SQL が LegacySQL → GoogleSQL に変更（2025-08-01から）。 古くから CLI/API で LegacySQL を実行している場合、引き続き LegacySQL を使うには明示的に設定が必要。管理者には以前からメールで通知されていた。G-gen からもお知らせメールを配信済み。 Vertex AI Agent Engine で Memory Bank が登場（Preview） Vertex AI Agent Engine Memory Bank overview (2025-07-08) Vertex AI Agent Engine で Memory Bank が登場（Preview）。 ユーザーと AI エージェントの会話を長期的に保管するストレージ。長期記憶のために DB を外部に作成する必要がなくなる。 短期記憶 → Session 管理 長期記憶 → Memory Bank Gmail に 「サブスクリプションを管理」画面が登場 Manage email subscriptions from a single location in Gmail (2025-07-08) Gmail で、メルマガ登録等のサブスクリプションを「サブスクリプションを管理」の1画面でまとめて管理（購読解除）できるようになる。順次ロールアウトされまもなく Web、iOS、Android アプリで使用可能になる。 SCC に Notebook Security Scanner が登場（Preview） Notebook Security Scanner (2025-07-11) Security Command Center の Premium/Enterprise ティアに Notebook Security Scanner が登場（Preview）。 Colab Enterprise ノートブック内で使われている Python パッケージを24時間ごとにスキャンして脆弱性を検知。現在は US と EU の一部リージョンのみ対応。 Gemini アプリでVeo 3 による動画生成が可能に（一部ユーザーのみ） Google Workspace Updates Weekly Recap - July 11, 2025 (2025-07-11) 一部の Google Workspace ユーザー（for select Workspace customers）の Gemini アプリで Veo 3 による動画生成が可能になった。 音声付きの8秒間の動画を、1日3回生成できる。写真から動画生成も可能。 Vertex AI Search の回答生成モデルで Gemini 2.5 Flash が利用可能 AI Applications release notes - June 26, 2025 (2025-06-26) Vertex AI Search の回答生成時のモデルに、Gemini 2.5 Flash が選択できるようになった。 これまでの最新は Gemini 2.0 Flash。コンテキストを意識した回答の生成で精度が向上する見込み。 SharePoint から Google ドライブへの移行ツールが Beta → GA Now Generally Available: Migrate files from Microsoft SharePoint Online to Google Drive (2025-07-14) SharePoint から Google ドライブへの移行ツールが Beta → 一般提供（GA）。 Workspace 管理画面組み込みのツール。ドキュメントライブラリ、フォルダ、ファイル、権限を移行可能。新規追加・更新されたファイルの差分転送も可能。 Google Cloud Marketplace の自社データ販売機能が Preview → GA Commercialize listings on Google Cloud Marketplace (2025-07-15) BigQuery sharing（旧 Analytics Hub）を使い Google Cloud Marketplace で自社データを販売する機能が Preview → GA。 自社保有データの収益化が容易になる。ただし規約上、まだ日本国内企業が対象になっていないため、日本企業はまだ利用できない。 Google カレンダーのアポイント予約をメールに直接組み込めるように Link your Google Calendar booking pages when composing emails in Gmail (2025-07-15) Google カレンダーのアポイント予約（apointment booking）を Gmail のメールに直接組み込めるように。順次ロールアウト。 AppSheet Enterprise Plus エディションで AI Tasks が Preview -> GA Now generally available: extract and categorize data in AppSheet with the power of Gemini (2025-07-16) AppSheet の Enterprise Plus エディションで使える AI Tasks が Preview -> GA（一般提供）。 Gemini が、写真や PDF からのデータ抽出や分類を Automation 内で自動的に行う。つまり、ノーコードで生成 AI アプリが簡単に作れる。 Looker Studio レポートで Short query optimized mode が利用可能に Looker Studio release notes - July 17, 2025 (2025-07-17) Looker Studio レポート（BigQuery データソース）で Short query optimized mode（Optional job creation mode）がサポート。 小規模クエリが高速化する可能性あり。データソースが「閲覧者の認証情報」を使っているなど特定条件でのみ適用される。 BigQuery の Optional job creation mode（オプションのジョブ作成モード）については以下も参照。 blog.g-gen.co.jp BigQueryのパイプ構文が拡張 BigQuery release notes - July 17, 2025 (2025-07-17) BigQueryのパイプ構文が拡張。以下の構文が利用可能になった。 WITH 使い回せるテーブル表現を定義 named windows ウインドウ関数と似ており結果の各行で共通して表示する集計を定義 DISTINCT 一意にレコードを抽出 IAM 編集画面で Gemini による最小権限ロールの提案（Preview） Get predefined role suggestions with Gemini assistance (2025-07-21) IAM 権限編集画面で Gemini による最小権限ロールの提案が使用可能になった（Preview）。 自然言語による質問で適切なロールを提案。ただしコンソールの言語を英語版にしないと使えない。 Gemini 2.5 Flash-Lite が Preview → GA（一般公開） Gemini 2.5 Flash-Lite (2025-07-22) Gemini 2.5 Flash-Lite が Preview → GA（一般公開）。 Gemini 2.5 Flash より軽量・高速・安価なモデル。バッチ推論にも対応。Vertex AI と Google AI Studio の両方で GA 版が利用可能。 Google Maps グラウンディングが米国以外でも利用可能に（Preview） Grounding with Google Maps in Vertex AI (2025-07-23) Gemini の Google Maps を使ったグラウンディングが米国以外でも利用可能に（Preview）。 これまで米国ユーザーのみプレビュー可能だった。Vertex AI 経由の Gemini 呼び出しで使える。 Looker で BigQuery への Optional job creation mode が使われるように Looker release notes - July 24, 2025 (2025-07-24) Looker Studio に続いて Looker でも、BigQuery に対する Optional job creation mode（ Short query optimized mode）が使われるようになった。 小規模クエリがより短時間で返る可能性がある。 BigQuery の Optional job creation mode（オプションのジョブ作成モード）については以下も参照。 blog.g-gen.co.jp Looker Studio レポートに Description（説明欄）が追加できるように Looker Studio release notes - July 24, 2025 (2025-07-24) Looker Studio レポートに Description（説明欄）が追加できるようになった。 テキストで説明を付記できる。レポート検索時にも検索対象になる。 Cloud Monitoring の1機能として Cost Explorer が Preview 公開 Optimize costs with the Cost Explorer (2025-07-24) Cloud Monitoring の1機能として Cost Explorer が Preview 公開。 対応プロダクト（主に Compute 系）のコストを分析してダッシュボード表示してくれる。 Code Interpreter が Looker と Looker Studio Pro で 試験運用版 →Preview Conversational Analytics Code Interpreter (2025-07-25) 試験運用版だった Code Interpreter in Conversational Analytics が Looker と Looker Studio Pro で Preview 公開され全ユーザー利用可能になった。 データソースに対する、より高度な分析が自然言語で可能になる。 通常の Conversational Analytics => 自然言語を SQL に変換 Code Interpreter in Conversational Analytics => 自然言語を Python に変換 Vertex AI と Model Armor が統合 (Preview) Model Armor integration with Vertex AI (2025-07-29) Vertex AI と Model Armor が統合（Preview）。 最小限のソースコード変更で、Gemini へのリクエストとそのレスポンスを検査できる。プレビュー期間中は無料。 現時点で us-central1、us-east4、us-west1、europe-west4 の API エンドポイントにのみ対応している。 Model Armor と、上記の使い方については以下の記事に追記した。 blog.g-gen.co.jp Gemini for Google Cloud API が BigQuery プロジェクトで自動で有効化 BigQuery release notes - July 30, 2025 (2025-07-30) Gemini for Google Cloud API が BigQuery 使用中のプロジェクトで自動的に有効化される。 数ヶ月前から Google より管理者へ一斉通知があった通り。Gemini in BigQuery の SQL 生成・補完やデータキャンバスなどが無料で使用可能。 Gemini Notebook に「動画概要」機能が登場 Introducing Video Overviews and upgrades to the Studio panel in NotebookLM (2025-07-30) Gemini Notebook に「動画概要」機能が登場。 データソースに基づいて、解説動画を生成する。現在の対応言語は英語のみだが、今後は拡張予定。 2025 年 8 月 4 日の週に 100% ロールアウト完了予定。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の min です。データポータル（英名 Data Studio、旧称 Looker Studio）の機能である 計算フィールド について、その概要から具体的な使い方、トラブルシューティングを解説します。 計算フィールドとは 計算フィールドの種類 計算フィールドの作成方法 データソースの計算フィールドを作成する レポート固有の計算フィールドを作成する 関数 関数とは CASE 文の使い方 トラブルシューティング 構文エラー データ型の不一致 集計エラー 計算フィールドとは データポータルにおける 計算フィールド とは、データソースに元々存在するフィールドを基に、関数や数式を用いて新しいディメンションや指標を作成する機能です。 例えば、データソースに「売上」と「費用」の指標がある場合、これらを使って 売上 - 費用 という数式で「利益」という新しい指標を作成できます。また、「姓」と「名」のディメンションを結合して「氏名」という新しいディメンションを作成することも可能です。 このように、計算フィールドを利用することで、元のデータを加工したり、複数のフィールドを組み合わせたりして、レポートで表現したい形にデータを整形できます。可視化の幅を広げるために非常に重要な機能です。 参考 : 計算フィールドについて 計算フィールドの種類 計算フィールドには、作成する場所によって2つの種類があります。それぞれの特徴を理解し、用途に応じて使い分けることが大切です。 種類 説明 メリット デメリット データソースの計算フィールド データソースの編集画面で作成するフィールド。 そのデータソースを使用する全てのレポートで再利用できる。一貫性が保たれる。 作成・編集にはデータソースの編集者の権限が必要。 レポート固有の計算フィールド レポート内の特定のグラフ（表やスコアカードなど）に対して作成するフィールド。 レポートの編集者の権限があれば作成できる。特定のグラフでのみ使用する一時的な計算に便利。 他のグラフやレポートで再利用できない。同じ計算を複数のグラフで使う場合は都度作成が必要。 基本的には、複数のレポートやグラフで汎用的に使用するフィールドは データソースの計算フィールド として作成し、特定のグラフでのみ一時的に必要な計算は レポート固有の計算フィールド として作成するとよいでしょう。 計算フィールドの作成方法 データソースの計算フィールドを作成する データポータルのレポート編集画面で、メニューから「リソース」>「追加済みのデータソースの管理」を選択します。 計算フィールドを追加したいデータソースの「編集」をクリックします。 データソースのフィールド一覧画面の右上にある「フィールドを追加」>「計算フィールドを追加」をクリックします。 フィールドエディタが開きます。「フィールド名」を入力し、「計算式」の欄に数式を入力します。 右下の「保存」をクリックして完了です。作成したフィールドは、このデータソースを使用する全てのレポートで利用できます。 レポート固有の計算フィールドを作成する レポート編集画面で、計算フィールドを追加したいグラフ（表、スコアカードなど）を選択します。 画面右側のプロパティパネルで、「ディメンション」または「指標」セクションの下部にある「 ディメンションを追加 」または「 指標を追加 」をクリックします。 表示されたメニューから「 計算フィールドを追加 」を選択します。 フィールドエディタが開きます。「表示名」を入力し、「数式」の欄に数式を入力します。 データ型を選択し、「適用」をクリックします。作成したフィールドは、選択したグラフでのみ利用できます。 参考 : グラフ固有の計算フィールドの制約 関数 関数とは 計算フィールドでは、単純な四則演算（ + , - , * , / ）だけでなく、 関数 を利用することでより高度なデータ操作ができます。 関数はカテゴリごとに分類されています。以下に代表的な関数を紹介します。 カテゴリ 代表的な関数 説明 集計 SUM , AVG , COUNT , COUNT_DISTINCT 指標の合計、平均、個数、ユニークな値の個数を計算する。 算術 POWER , ROUND べき乗や四捨五入などの算術計算を行う。 日付 TODAY , YEAR , DATE_DIFF , DATETIME_TRUNC 今日の日付の取得、年から年の抽出、日付の差分計算、日付の切り捨てなどを行う。 テキスト CONCAT , LENGTH , LOWER , UPPER , SUBSTR , REGEXP_MATCH 文字列の結合、長さの取得、大文字・小文字変換、部分文字列の抽出、正規表現による一致判定などを行う。 条件分岐 CASE , IF 条件に応じて返す値を変更する。 全ての関数の一覧は、以下の公式ドキュメントを参照してください。 参考 : 関数リスト CASE 文の使い方 特に使用頻度が高いのが、条件分岐を行う CASE 文です。 CASE 文を使うと、フィールドの値に応じて新しい値を割り当てることができます。 構文は以下の通りです。 CASE WHEN 条件 1 THEN 結果 1 WHEN 条件 2 THEN 結果 2 ELSE その他の結果 END 例えば、「国コード」フィールド（ JP , US など）を基に「国名」フィールド（ 日本 , アメリカ など）を作成する場合は、以下のように記述します。 CASE WHEN Country_Code = " JP " THEN " 日本 " WHEN Country_Code = " US " THEN " アメリカ " WHEN Country_Code = " KR " THEN " 韓国 " ELSE " その他 " END また、正規表現関数と組み合わせることで、より柔軟な条件設定が可能です。 CASE WHEN REGEXP_MATCH(店舗名, " .*駅前.* " ) THEN " 駅前店舗 " WHEN REGEXP_MATCH(店舗名, " .*SC.* " ) THEN " SC内店舗 " ELSE " その他の店舗 " END トラブルシューティング 計算フィールドの作成時によく発生するエラーとその対処法を解説します。 構文エラー 関数名のスペルが間違っている 、 括弧が閉じていない といった単純な文法ミスです。 計算フィールドのエディタは、エラーがある箇所を赤くハイライトしてエラーメッセージを表示してくれます。メッセージをよく読み、数式を修正してください。 データ型の不一致 テキスト型のフィールドと数値型のフィールドを足し算しようとする など、異なるデータ型のフィールド間で不適切な演算を行うとエラーになります。 この場合、 CAST 関数を使ってデータ型を明示的に変換する必要があります。例えば、テキストとして保存されている数値を数値型に変換するには CAST(フィールド名 AS NUMBER) のように記述します。 集計エラー 「集計指標と非集計ディメンションを混在させることはできません」というエラーは、計算フィールドの作成時に頻繁に発生するエラーの一つです。 これは、 集計済みの値 と 未集計の値 を一つの数式内で混ぜて使おうとしたときに発生します。データポータルの指標は、グラフに表示される際に行単位のデータが SUM や AVG などで 集計 されてから表示されます。 例えば、以下のような店舗ごとの商品単価データがあるとします。 店舗名 商品名 単価 渋谷店 商品A 1,000 新宿店 商品A 1,200 池袋店 商品A 900 このデータを使って「渋谷店の単価が、全店舗の単価の合計に占める割合」を計算したいとします。 ここで、以下のような誤った数式を入力したとします。 // 誤った例 ( CASE WHEN 店舗名 = " 渋谷店 " THEN 単価 ELSE 0 END ) / SUM (単価) この数式がエラーになる原因は、分子と分母で値の集計レベルが異なるためです。 分母の SUM(単価) は 集計済みの値 です。これは、表全体の単価を合計した 1000 + 1200 + 900 = 3100 という単一の数値を返します。 一方、分子の (CASE WHEN 店舗名 = "渋谷店" THEN 単価 ELSE 0 END) は 未集計の値 です。この部分は行ごとに評価されるため、結果は 1000, 0, 0 という複数の数値の集まりになります。 この数式は、「行ごとの複数の値（ 1000, 0, 0 ）を、全体で一つしかない値 3100 で割る」という計算を意味します。データポータルはどの値を割れば良いか判断できないため、エラーを返します。 このエラーを解決するには、分子も分母と同じように集計済みの値にする必要があります。 // 正しい例 SUM ( CASE WHEN 店舗名 = " 渋谷店 " THEN 単価 ELSE 0 END ) / SUM (単価) この数式では、分子と分母の両方が集計済みの単一の値になるため、計算できます。 分子は SUM(CASE ...) によって SUM(1000, 0, 0) が計算され、 1000 という単一の値になります。 分母は SUM(単価) によって 3100 という単一の値になります。 1000 / 3100 という明確な計算となり、正しく割合が返されます。 どのタイミングで集計が必要かを理解することが、このエラーを回避する鍵となります。 参考 : 計算フィールドのトラブルシューティング 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の杉村です。人間からの自然言語での質問に基づいて BigQuery にクエリを実行する AI エージェントを、 Agent Development Kit （ADK）で開発する方法を紹介します。 概要 Agent Development Kit（ADK）とは BigQuery ツールセット 実装 ソースコード エージェント定義と非同期実行 BigQuery ツールの定義 BigQuery を使うエージェントの定義 動作確認 最終回答 エージェントとツールの挙動 精度確認 質問のしかたを変える 複雑な質問 会話型分析（参考情報） 概要 Agent Development Kit（ADK）とは Agent Development Kit （ADK）は、AI エージェントの開発、デプロイ、評価を効率化するために Google が開発したオープンソースのフレームワークです。2025年7月現在、Python および Java 向けのライブラリとして公開されています。 ADK を利用することで、AI エージェントを容易に開発できます。また、ADK に組み込みの Built-in tools を使うことで、最小限のコーディングでエージェントに様々なタスクを行わせることができます。当記事では、Built-in tools の1つである BigQuery ツールセットを使って、人間からの自然言語での質問に応じて BigQuery テーブルにクエリを行うエージェントを開発する方法を紹介します。 参考 : Agent Development Kit 参考 : Built-in tools BigQuery ツールセット BigQuery ツールセット は、ADK の組み込みツールセットです。最小限のコーディングで、AI エージェントがユーザーの質問に応じたクエリを自動的に生成し、結果を得て、それに応じた回答を生成します。このツールセットには、以下のようなツールが含まれています。 ツール名 説明 list_dataset_ids プロジェクト内の BigQuery データセットをリストアップする get_dataset_info BigQuery データセットの情報を取得する list_table_ids BigQuery データセット内のテーブル ID をリストアップする get_table_info BigQuery テーブルのメタデータ（スキーマや Description）を取得する execute_sql BigQuery にクエリ（SQL）を実行する 参考 : Built-in tools - BigQuery 上記のツールを使うことで、エージェントは BigQuery に対する一通りの操作が可能です。これらのツールを使うことにより、以下のようなユーザーの質問に対して、AI エージェントが自律的に情報を取得することができます。 「BigQuery テーブル `〇〇.〇〇.〇〇` から xxx を取得して xxx のように集計して」 「BigQuery データセット `〇〇.〇〇` から xxx の情報を探し出して」 「プロジェクト 〇〇 の BigQuery から xxx の情報を取得して教えてください」 実装 ソースコード サンプルとして以下のソースコードを用意しました。 import asyncio import logging from google.adk.agents import LlmAgent from google.adk.runners import Runner from google.adk.sessions import InMemorySessionService from google.adk.tools.bigquery import BigQueryCredentialsConfig from google.adk.tools.bigquery import BigQueryToolset from google.adk.tools.bigquery.config import BigQueryToolConfig from google.adk.tools.bigquery.config import WriteMode from google.genai import types import google.auth # 書き込みオペレーションが実行されるのを防ぐ tool_config = BigQueryToolConfig(write_mode=WriteMode.BLOCKED) # BigQuery への認証（Application Default Credentials） application_default_credentials, _ = google.auth.default() credentials_config = BigQueryCredentialsConfig( credentials=application_default_credentials ) # BigQuery ツールセットを定義 bigquery_toolset = BigQueryToolset( credentials_config=credentials_config, bigquery_tool_config=tool_config ) # BigQuery のジョブ実行プロジェクト ID（課金先） PROJECT_ID= "my-project" # BigQuery を使うエージェント bigquery_agent = LlmAgent( model= "gemini-2.5-flash" , name= "bigquery_agent" , instruction=f """ あなたは BigQuery のデータ分析をするエージェントです。 tools である `bigquery_toolset` を使って SQL を実行し、データを取得・分析してユーザーからの質問に回答を生成します。 BigQuery ジョブはプロジェクト ID `{PROJECT_ID}` で実行します。 """ , tools=[bigquery_toolset], ) # runner の定義 APP_NAME = "My Agent App" SESSION_SERVICE = InMemorySessionService() RUNNER = Runner( agent=bigquery_agent, app_name=APP_NAME, session_service=SESSION_SERVICE, ) async def stream_agent_events (query: str , user_id: str , session_id: str ): ''' # 概要 エージェントを実行します。 # 引数 query (str): エージェントに投げかけるクエリ（プロンプト） user_id (str): ユーザー ID session_id (str): セッション ID ''' # 既存セッションがなければ新規作成 session = await SESSION_SERVICE.get_session(app_name=APP_NAME, user_id=user_id, session_id=session_id) if not session: await SESSION_SERVICE.create_session(app_name=APP_NAME, user_id=user_id, session_id=session_id) # ユーザークエリを所定の形式で格納 content = types.Content(role= 'user' , parts=[types.Part(text=query)]) # エージェントの実行 async for event in RUNNER.run_async(user_id=user_id, session_id=session_id, new_message=content): parts = event.content.parts message = event.content.parts[ 0 ].text if message: yield (f "--- Message: {message}" ) return async def main (): """ エージェントを実行し、ストリーミングされたメッセージを出力するメイン関数 """ user_id= "test_user" session_id= "test_session" query= "BigQuery テーブル `bigquery-public-data.samples.shakespeare` から、シェイクスピア作品で頻出の単語のトップ10を教えてください。" # async for を使って非同期ジェネレータを処理 async for message in stream_agent_events(query=query, user_id=user_id, session_id=session_id): print (message) # ロギングを設定 logging.basicConfig( level=logging.DEBUG, format = '%(asctime)s - %(levelname)s - %(name)s - %(message)s' ) # スクリプトのエントリーポイント if __name__ == "__main__" : asyncio.run(main()) エージェント定義と非同期実行 エージェントの定義（ LlmAgent() ）やそれに対する非同期実行（ run_async() 等）については、以下の記事を参照してください。 blog.g-gen.co.jp BigQuery ツールの定義 当サンプルコードでは、ADK の組み込みツールである BigQuery ツールを以下のように定義しています。 # 書き込みオペレーションが実行されるのを防ぐ tool_config = BigQueryToolConfig(write_mode=WriteMode.BLOCKED) # BigQuery への認証（Application Default Credentials） application_default_credentials, _ = google.auth.default() credentials_config = BigQueryCredentialsConfig( credentials=application_default_credentials ) # BigQuery ツールセットを定義 bigquery_toolset = BigQueryToolset( credentials_config=credentials_config, bigquery_tool_config=tool_config ) tool_config で BigQueryToolConfig(write_mode=WriteMode.BLOCKED) とすることで、BigQuery に誤って書き込みオペレーションが実行されてしまうことを防ぎます。 認証については、 google.auth.default() により、Application Default Credentials を取得しています。これは、実行環境が Cloud Run や Vertex AI Agent Engine であれば環境にアタッチされたサービスアカウントを参照し、ローカルの実行環境であれば gcloud auth application-default login で設定された Google アカウントの認証情報等を参照します。 参考 : gcloud auth loginとgcloud auth application-default loginの違いとは？ - G-gen Tech Blog また BigQueryToolset() により、書き込みブロックの設定や認証情報を指定して、BigQuery ツールを定義します。 BigQuery を使うエージェントの定義 ツールとして BigQuery を使うエージェントの定義は、以下のようになっています。 # BigQuery のジョブ実行プロジェクト ID（課金先） PROJECT_ID= "my-project" # BigQuery を使うエージェント bigquery_agent = LlmAgent( model= "gemini-2.5-flash" , name= "bigquery_agent" , instruction=f """ あなたは BigQuery のデータ分析をするエージェントです。 tools である `bigquery_toolset` を使って SQL を実行し、データを取得・分析してユーザーからの質問に回答を生成します。 BigQuery ジョブはプロジェクト ID `{PROJECT_ID}` で実行します。 """ , tools=[bigquery_toolset], ) ここでは定義した bigquery_toolset を tools として指定するだけで、エージェントが BigQuery ツールセットを使用するようになります。また instruction にて、「BigQuery ジョブはプロジェクト ID `{PROJECT_ID}` で実行します。」と指示しています（Python の f-strings により {PROJECT_ID} は実際のプロジェクト ID に置き換わります）。 検証時は、この指示を入れない場合だと、ユーザーのプロンプトで BigQuery データセット bigquery-public-data.samples.shakespeare からデータを取ってきてください のように指定されたとき、エージェントはパブリックデータセットのプロジェクトに対してジョブを実行しようとしてしまい、権限不足でクエリが失敗しました。 なお検証では、認証時に google.auth.default(quota_project_id=PROJECT_ID) のようにクォータプロジェクト（課金先プロジェクト）を指定しても、同様の挙動でした。 BigQuery のジョブ実行権限についての解説は、以下の記事も参考にしてください。 blog.g-gen.co.jp 動作確認 最終回答 上記のソースコードを実行した結果、以下のような最終回答が得られました。 クエリ BigQuery テーブル bigquery-public-data.samples.shakespeare から、シェイクスピア作品で頻出の単語のトップ10を教えてください。 最終回答 --- Message: はい、BigQuery テーブル `bigquery-public-data.samples.shakespeare` から、シェイクスピア作品で頻出の単語トップ10は以下の通りです。 1. the: 25568回 2. I: 21028回 3. and: 19649回 4. to: 17361回 5. of: 16438回 6. a: 13409回 7. you: 12527回 8. my: 11291回 9. in: 10589回 エージェントとツールの挙動 ロギング設定（ログレベルが DEBUG）により、エージェントがツールを使う挙動が標準出力に出力されます。この出力を確認することで、エージェントがどのように思考し、ツールを使用したのかを確認できます。出力の一部を抜粋すると、以下のとおりでした。 Function calls: name: list_table_ids, args: { 'project_id' : 'bigquery-public-data' , 'dataset_id' : 'samples' } Function calls: name: get_table_info, args: { 'table_id' : 'shakespeare' , 'dataset_id' : 'samples' , 'project_id' : 'bigquery-public-data' } Function calls: name: execute_sql, args: { 'project_id' : my-project, 'query' : 'SELECT word, SUM(word_count) AS total_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY word ORDER BY total_count DESC LIMIT 10' } Contents: { "parts" :[{ "text" : "BigQuery テーブル `bigquery-public-data.samples.shakespeare` から、シェイクスピア作品で頻出の単語のトップ10を教えてください。" }], "role" : "user" } { "parts" :[{ "function_call" :{ "args" :{ "project_id" : "bigquery-public-data" , "dataset_id" : "samples" }, "name" : "list_table_ids" }}], "role" : "model" } { "parts" :[{ "function_response" :{ "name" : "list_table_ids" , "response" :{ "result" :[ "github_nested" , "github_timeline" , "gsod" , "natality" , "shakespeare" , "trigrams" , "wikipedia" ]}}}], "role" : "user" } { "parts" :[{ "function_call" :{ "args" :{ "table_id" : "shakespeare" , "dataset_id" : "samples" , "project_id" : "bigquery-public-data" }, "name" : "get_table_info" }}], "role" : "model" } { "parts" :[{ "function_response" :{ "name" : "get_table_info" , "response" :{ "kind" : "bigquery#table" , "etag" : "BeoZAW5rQH2EllmuKl2a2A==" , "id" : "bigquery-public-data:samples.shakespeare" , "selfLink" : "https://bigquery.googleapis.com/bigquery/v2/projects/bigquery-public-data/datasets/samples/tables/shakespeare" , "tableReference" :{ "projectId" : "bigquery-public-data" , "datasetId" : "samples" , "tableId" : "shakespeare" }, "schema" :{ "fields" :[{ "name" : "word" , "type" : "STRING" , "mode" : "REQUIRED" , "description" : "A single unique word (where whitespace is the delimiter) extracted from a corpus." },{ "name" : "word_count" , "type" : "INTEGER" , "mode" : "REQUIRED" , "description" : "The number of times this word appears in this corpus." },{ "name" : "corpus" , "type" : "STRING" , "mode" : "REQUIRED" , "description" : "The work from which this word was extracted." },{ "name" : "corpus_date" , "type" : "INTEGER" , "mode" : "REQUIRED" , "description" : "The year in which this corpus was published." }]}, "numBytes" : "6432064" , "numLongTermBytes" : "6432064" , "numRows" : "164656" , "creationTime" : "1457975805856" , "lastModifiedTime" : "1457975805856" , "type" : "TABLE" , "location" : "US" , "numTimeTravelPhysicalBytes" : "0" , "numTotalLogicalBytes" : "6432064" , "numActiveLogicalBytes" : "0" , "numLongTermLogicalBytes" : "6432064" , "numTotalPhysicalBytes" : "485656" , "numActivePhysicalBytes" : "0" , "numLongTermPhysicalBytes" : "485656" , "numCurrentPhysicalBytes" : "485656" }}}], "role" : "user" } { "parts" :[{ "function_call" :{ "args" :{ "project_id" : "my-project" , "query" : "SELECT word, SUM(word_count) AS total_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY word ORDER BY total_count DESC LIMIT 10" }, "name" : "execute_sql" }}], "role" : "model" } { "parts" :[{ "function_response" :{ "name" : "execute_sql" , "response" :{ "status" : "SUCCESS" , "rows" :[{ "word" : "the" , "total_count" : 25568 },{ "word" : "I" , "total_count" : 21028 },{ "word" : "and" , "total_count" : 19649 },{ "word" : "to" , "total_count" : 17361 },{ "word" : "of" , "total_count" : 16438 },{ "word" : "a" , "total_count" : 13409 },{ "word" : "you" , "total_count" : 12527 },{ "word" : "my" , "total_count" : 11291 },{ "word" : "in" , "total_count" : 10589 },{ "word" : "is" , "total_count" : 8735 }]}}}], "role" : "user" } 出力を見ると、ツールセットに含まれる list_table_ids 、 get_table_info 、 execute_sql が順に実行されています。エージェントはまずテーブルの存在確認を行い、次にテーブルのスキーマを取得して構造を理解しました。このとき、テーブルやカラムのメタデータ（ description ）も取得していることがわかります。最後に SELECT 文を実行し、データを取得し、それを解釈して回答を生成したことがわかります。 このような挙動からも、AI エージェントがテーブル構造を適切に理解してクエリを実行するには、メタデータ管理が重要であることがわかります。 参考 : メダリオンアーキテクチャ2.0とGoogle CloudのAIエージェント活用 - G-gen Tech Blog 精度確認 エージェントが生成したクエリを確認し、また念の為、エージェントが実行したクエリを手作業でも実行してみます。 質問内容に対して、エージェントの実行したクエリは適切であり、実行結果とも整合性が取れていることがわかります。 クエリ SELECT word, SUM (word_count) AS total_count FROM `bigquery- public -data.samples.shakespeare` GROUP BY word ORDER BY total_count DESC LIMIT 10 実行結果 word total_count the 25568 I 21028 and 19649 to 17361 of 16438 a 13409 you 12527 my 11291 in 10589 is 8735 質問のしかたを変える エージェントが自律的に判断して BigQuery の様々なタスクを実行できることを確認するため、以下のようなクエリも実行してみます。 BigQuery データセット bigquery-public-data.samples から、シェイクスピア作品で頻出の単語のトップ10を教えてください。 先程はテーブル ID を指定しましたが、今回はデータセット ID のみを指定しています。結果は、エージェントが適切にデータセット内からテーブルをリストアップし、適切なテーブルを見つけ出してクエリを実行しました。 最終回答 シェイクスピア作品で最も頻出する単語トップ10は以下の通りです。 1. the: 25568 2. I: 21028 3. and: 19649 4. to: 17361 5. of: 16438 6. a: 13409 7. you: 12527 8. my: 11291 9. in: 10589 10. is: 8735 これらの単語は、シェイクスピアの作品で最も多く使用されています。 エージェントの処理 Function calls: name: list_table_ids, args: {'project_id': 'bigquery-public-data', 'dataset_id': 'samples'} Function calls: name: get_table_info, args: {'dataset_id': 'samples', 'table_id': 'shakespeare', 'project_id': 'bigquery-public-data'} Function calls: name: execute_sql, args: {'project_id': my-project, 'query': 'SELECT word, SUM(word_count) AS total_word_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY word ORDER BY total_word_count DESC LIMIT 10'} さらに、以下のようなクエリでも想定どおりの結果が返りました。 BigQuery プロジェクト bigquery-public-data から、シェイクスピア作品で頻出の単語のトップ10を教えてください。 この場合は、 list_dataset_ids → list_table_ids → get_table_info → execute_sql と順番にツールを使って処理が実行され、適切なテーブルにたどり着きました。 複雑な質問 AI エージェントは、以下のような少し複雑な質問にも対応できます。処理結果を見ると、必要な分、複数回のクエリを発行し、それを最後に LLM がまとめていることがわかります。このような質問にエージェントが回答できれば、より実践的なユースケースにも対応できる可能性が出てきます。 クエリ 米国で生まれた子供に多い名前の傾向を、2000年と2020年で比較してください。どのような違いがありますか？ BigQuery テーブル bigquery-public-data.usa_names.usa_1910_current からデータを取得してください。 最終回答 2000年と2020年の米国における人気のある名前の傾向を比較すると、以下の点が挙げられます。 **2000年の人気上位の名前:** * **男の子:** Jacob, Michael, Matthew, Joshua, Christopher, Nicholas, Andrew, Joseph, Daniel, Tyler * **女の子:** Emily, Hannah, Madison, Ashley, Sarah, Alexis, Samantha, Jessica, Elizabeth, Taylor **2020年の人気上位の名前:** * **男の子:** Liam, Noah, Oliver, Elijah, William, James, Benjamin, Lucas, Henry, Alexander * **女の子:** Olivia, Emma, Ava, Charlotte, Sophia, Amelia, Isabella, Mia, Evelyn, Harper **主な違い:** * **名前のトレンドの変化:** 2000年と2020年の上位10位の名前には、ほとんど重複がありません。これは、わずか20年の間に名前の流行が大きく変化したことを示しています。 * **新しい名前の台頭:** 2020年には、「Liam」「Noah」「Olivia」「Ava」など、2000年には上位に入っていなかった新しい名前が人気を集めていることがわかります。 * **伝統的な名前の継続的な人気:** 「William」や「James」、「Elizabeth」など、比較的時間に左右されない伝統的な名前も依然として一定の人気を保っていることが伺えますが、上位を占めるのはより現代的な名前になっています。 この比較から、米国における子どもの名前の傾向は、社会や文化の変化を反映して、20年間で大きく移り変わっていることが明確にわかります。 処理の経緯 （一部のみ抜粋） Function calls: name: get_table_info, args: {'dataset_id': 'usa_names', 'project_id': 'bigquery-public-data', 'table_id': 'usa_1910_current'} 2025 - 07 - 29 09: 22 : 58 , 336 - DEBUG - google_adk.google.adk.models.google_llm - LLM Response: ----------------------------------------------------------- Text: 2000 年と 2020 年の米国で生まれた子供に多い名前の傾向を比較するため、`bigquery-public-data.usa_names.usa_1910_current` テーブルからデータを取得します。 まず、 2000 年の男女別人気上位 10 の名前を抽出します。 ----------------------------------------------------------- Function calls: name: execute_sql, args: { 'project_id' : my-project, 'query' : " \n SELECT \n name, \n SUM(number) as total_occurrences \n FROM \n `bigquery-public-data.usa_names.usa_1910_current` \n WHERE \n year = 2000 AND gender = 'M' \n GROUP BY \n name \n ORDER BY \n total_occurrences DESC \n LIMIT 10; \n " } 2025 - 07 - 29 09: 23 : 04 , 532 - DEBUG - google_adk.google.adk.models.google_llm - LLM Response: ----------------------------------------------------------- Text: 次に、 2020 年の男女別人気上位 10 の名前を抽出します。 ----------------------------------------------------------- Function calls: name: execute_sql, args: { 'project_id' : my-project, 'query' : " \n SELECT \n name, \n SUM(number) as total_occurrences \n FROM \n `bigquery-public-data.usa_names.usa_1910_current` \n WHERE \n year = 2020 AND gender = 'M' \n GROUP BY \n name \n ORDER BY \n total_occurrences DESC \n LIMIT 10; \n " } 会話型分析（参考情報） ADK とは関係のない参考情報ですが、BigQuery のデータに対して自然言語によるクエリや分析を行いたい場合、 Looker や Looker Studio Pro に搭載の Conversational Analytics （会話型分析）も有用な選択肢です。 この機能では、自然言語、かつチャット形式で Looker や Looker Studio の画面から問いを投げかけるだけで、AI が BigQuery 等のデータソースに対してクエリを発行し、分析や可視化が可能です。 参考 : Looker の会話分析 参考 : Looker Studio の会話分析 Looker Studio Pro の会話型分析 Looker や Looker Studio Pro については、以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の三浦です。当記事では、特定の GitHub リポジトリの内容を Gemini アプリに解説させる方法を紹介します。 概要 当機能について Gemini アプリとは 前提条件 検証手順 検証 リポジトリとディレクトリ構成 main.py error/error.py パブリックリポジトリのインポート コード理解と改善の確認 プライベートリポジトリのフォルダインポート デバッグとコード生成の確認 概要 当機能について Gemini アプリでは、GitHub のパブリックリポジトリまたはプライベートリポジトリをインポートして、その内容に関する質問や依頼ができます。 この機能は、ソースコードの理解の支援や改善案の提案、コード生成、エラー解析といった用途に利用できます。 詳細は以下の公式ドキュメントをご参照ください。 参考 : GitHub リポジトリをインポートして Gemini ウェブアプリでそれについて質問する Gemini アプリとは Gemini アプリ は、Google が提供する生成 AI チャットアプリケーションです。プログラミング、ドキュメント作成、質問応答など多用途に対応しています。 Google アカウントを持っていれば、ウェブブラウザで gemini.google.com にアクセスしたり、モバイルデバイス向けアプリをダウンロードすることで利用できます。 詳細は以下の公式ドキュメントや記事をご参照ください。 参考 : Gemini ウェブアプリを利用する 参考 : 全Geminiプロダクトを徹底解説！ - G-gen Tech Blog - Gemini アプリ 前提条件 当機能は、以下の特定の Google Workspace エディションまたはアドオンでのみ利用できます。 Business Standard / Plus Enterprise Standard / Plus Gemini Education Education Premium 詳細は以下をご参照ください。 参考 : Upload code folders or import your GitHub repositories directly into the Gemini app 検証手順 検証手順は次のとおりです。 項番 内容 説明 1 パブリックリポジトリをインポートし、コード理解と改善を試行 GitHub リポジトリをインポートし、コードベースの理解や改善提案を Gemini に依頼します。 2 プライベートリポジトリのフォルダをインポートし、デバッグやコード生成を試行 フォルダをアップロードし、生成・デバッグ用途での使い方を確認します。 検証 リポジトリとディレクトリ構成 本検証に使用したリポジトリの構成は以下のとおりです。 # パブリックリポジトリ . ├── README.md └── main.py 　 # プライベートリポジトリ . ├── README.md └── error └── error.py main.py シンプルな Flask アプリを使用しています。ブラウザに "Hello, World!" を返すだけの最小構成です。 from flask import Flask 　 app = Flask(__name__) 　 @ app.route ( "/" ) def hello (): return "Hello, World!" 　 if __name__ == "__main__" : app.run() error/error.py 意図的に ZeroDivisionError を引き起こすテストコードです。Gemini アプリでのデバッグ用に使用します。 from flask import Flask 　 app = Flask(__name__) 　 @ app.route ( "/" ) def home (): return 1 / 0 　 if __name__ == "__main__" : app.run(debug= True ) 　 パブリックリポジトリのインポート Gemini アプリ（ https://gemini.google.com ）へアクセスします。 [+（ファイルの追加）] > [コードをインポート] を選択します。 コードをインポートを選択 GitHub リポジトリの URL を入力し、「インポート」を選択します。 インポートの実施 内容を確認し、「接続」を選択します。 GitHub との接続を実施 接続が完了すると、接続した GitHub のリポジトリ情報が表示されます。 インポート確認 コード理解と改善の確認 まずは以下のプロンプトで、リポジトリのコード全体について説明を求めてみます。 このリポジトリのコードについて教えてください リポジトリのコード解説 次に以下のプロンプトで、アプリのセキュリティ改善の提案を依頼してみます。 この Web アプリに対して、セキュリティ上のリスクがあれば指摘し、改善案を提示してください リポジトリのコード改善 プライベートリポジトリのフォルダインポート Gemini アプリの新しいチャットから、再度 [+（ファイルの追加）] > [コードをインポート] を選択します。 [フォルダをアップロード] から、 error フォルダを選択します。 フォルダをアップロード 注意内容を確認し、[アップロード] を選択します。 アップロードを選択 アップロードしたフォルダが表示されていることを確認します。 アップロード確認 デバッグとコード生成の確認 以下のプロンプトで、エラーが出る原因と改善方法を確認します。 このアプリの実行時にエラーが出る理由を教えてください。また、修正方法も教えてください。 原因と改善方法の提示 次に以下のプロンプトで、認証機能を追加するコードを生成できるか確認します。 このアプリに対して、ユーザー名とパスワードでログインできる認証機能を追加したいです。必要なコードを生成して教えてください。 機能追加のためのコード生成 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

Cloud Run のサイドカー機能と MailHog を利用し、アプリケーションからのメールを捕捉するダミーの SMTP サーバー環境を構築する方法を紹介します。 はじめに やりたいこと 実現方法 サイドカー機能とは 構成 ソースコード デプロイ 動作確認 はじめに やりたいこと Cloud Run services を使い、メール送信機能があるアプリケーションを開発しているケースを考えます。本番環境のアプリケーションでは SMTP サーバーを利用してメールを送信していますが、開発環境のアプリケーションではメールが外部に送信されないようにしたい場合があります。 当記事では、上記のようなケースにおいて、アプリケーションのコードは極力変更せずに、開発環境のみメールを MailHog で構築したダミー SMTP サーバーで受け取るようにします。 MailHog は、MIT ライセンスのもと配布されているオープンソースソフトウェアです。 参考 : GitHub - mailhog/MailHog 参考 : GitHub - mailhog/MailHog/LICENSE.md 実現方法 当記事では、前述の要件を Cloud Run の サイドカー （Sidecar）機能を利用して実現します。 アプリケーションコンテナのデプロイ時に、MailHog のコンテナをサイドカーとして同時にデプロイします。これにより、2つのコンテナは同一の Cloud Run サービスインスタンス内で起動し、 localhost を通じて通信できます。 アプリケーション側では、接続先 SMTP サーバーのホスト名を localhost に、ポートを MailHog が待機するポート（デフォルトで 1025 ）に設定するだけで、メール送信の向き先を MailHog に変更できます。 サイドカー機能とは サイドカー とは、1つの Cloud Run サービスに、複数のコンテナをデプロイできる機能です。 メインのリクエストを処理するコンテナ（Ingress コンテナ）と、それを補助するサイドカーコンテナを組み合わせて使用します。サイドカーのユースケースとして、ログ転送エージェントや、サービスメッシュのプロキシ、そして今回のような補助的なサービスが挙げられます。 サイドカーとしてデプロイされたコンテナは、Ingress コンテナと同じネットワーク名前空間を共有するため、 localhost を使用して相互に通信できます。ただし、外部からの HTTP リクエストは Ingress コンテナのみが受信し、サイドカーコンテナのポートが直接外部に公開されることはありません。 参考 : Cloud Run へのコンテナ イメージのデプロイ - サービスに複数のコンテナをデプロイする（サイドカー） 構成 外部からのリクエストは、ポート 8080 で待機する FastAPI アプリケーションコンテナ（Ingress コンテナ）が受け取ります。 アプリケーションがメールを送信する際は、環境変数で指定された localhost:1025 に接続します。そこでは MailHog コンテナが SMTP サーバーとして待機しており、送信されたメールを捕捉します。 ソースコード まず、メール送信機能を持つ FastAPI アプリケーションを用意します。 重要な点は、SMTP サーバーの接続情報を環境変数（ SMTP_HOST 、 SMTP_PORT など）から読み込むように実装することです。これにより、コンテナイメージを再ビルドすることなく、デプロイ時の設定だけで接続先を切り替えられます。 Dockerfile FROM python:3.13-bookworm COPY --from = ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ WORKDIR /app ADD . /app RUN uv sync --locked EXPOSE 8080 CMD [" /app/.venv/bin/fastapi " , " run " , " main.py " , " --host " , " 0.0.0.0 " , " --port " , " 8080 "] main.py from email.message import EmailMessage import smtplib import os from fastapi import FastAPI, HTTPException, Request, Response from pydantic import BaseModel, EmailStr app = FastAPI() # 環境変数からSMTPサーバーの接続情報を取得 SMTP_HOST = os.environ.get( "SMTP_HOST" ) SMTP_PORT = int (os.environ.get( "SMTP_PORT" , 587 )) SMTP_USER = os.environ.get( "SMTP_USER" ) SMTP_PASS = os.environ.get( "SMTP_PASS" ) class EmailModel (BaseModel): from_: EmailStr to: EmailStr subject: str body: str @ app.get ( "/" ) def root (): return { "message" : "ok" } @ app.post ( "/sendmail" ) def sendmail (email: EmailModel): if SMTP_HOST is None : raise HTTPException( status_code= 500 , detail= "SMTP_HOST environment variable is not set" ) # MailHogは認証不要なため、USER/PASSの有無で処理を分岐 if SMTP_USER and SMTP_PASS: server = smtplib.SMTP_SSL(SMTP_HOST, port=SMTP_PORT) server.set_debuglevel( 1 ) server.login(user=SMTP_USER, password=SMTP_PASS) else : server = smtplib.SMTP(SMTP_HOST, port=SMTP_PORT) server.set_debuglevel( 1 ) msg = EmailMessage() msg[ "Subject" ] = email.subject msg[ "From" ] = email.from_ msg[ "To" ] = email.to msg.set_content(email.body) server.send_message(msg) server.close() return { "ok" : True } pyproject.toml [project] name = "etude-mailhog" version = "0.1.0" description = "" readme = "README.md" requires-python = ">=3.13" dependencies = [ "fastapi[standard]>=0.115.12" , ] デプロイ gcloud コマンドで、アプリケーションと MailHog を Cloud Run にデプロイします。 まず、アプリケーションのコンテナイメージを Artifact Registry などにプッシュします。 # Cloud BuildでコンテナイメージをビルドしてArtifact Registryにプッシュ # (事前に gcloud artifacts repositories create ... でリポジトリ作成が必要) gcloud builds submit --tag asia-northeast1-docker.pkg.dev/ $( gcloud config get-value project ) /smtp-mocker/app:1. 0 次に、Cloud Run にサービスをデプロイします。 --container フラグを2つ指定することで、サイドカー構成を定義します。 gcloud run deploy mail-service \ --region asia-northeast1 \ --allow-unauthenticated \ --container " app " \ --image " asia-northeast1-docker.pkg.dev/ $( gcloud config get-value project ) /smtp-mocker/app:1.0 " \ --port 8080 \ --set-env-vars " SMTP_HOST=localhost,SMTP_PORT=1025 " \ --container " mailhog " \ --image " mailhog/mailhog " このコマンドの主要なフラグは以下の通りです。 フラグ 説明 --container "app" Ingress コンテナとなるアプリケーションを定義します。このフラグに続く --port 8080 で待ち受けポートを指定し、 --set-env-vars で SMTP の接続先を localhost:1025 に設定します。 --container "mailhog" サイドカーとなる MailHog コンテナを定義します。Docker Hub の公式イメージ mailhog/mailhog を指定します。 参考 : Docker Hub - mailhog/mailhog 動作確認 デプロイが完了したら、 curl コマンドでアプリケーションの /sendmail エンドポイントを呼び出し、テストメールを送信します。 # Cloud RunサービスのエンドポイントURLを取得 SERVICE_URL = $( gcloud run services describe mail-service --region asia-northeast1 --format ' value(status.url) ' ) # テストメールを送信 curl -X POST " ${SERVICE_URL} /sendmail " \ -H " Content-Type: application/json " \ -d ' { "from_": "from@example.com", "to": "to@example.com", "subject": "Test from Cloud Run", "body": "This is a test mail with a sidecar." } ' このように Cloud Run のサイドカー機能と環境変数を利用することで、アプリケーションコードを変更することなく、環境に応じた柔軟なシステム構成を実現できます。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の山崎です。 当記事では、Cloud Run jobs を使用して Google Drive の差分を検知し、差分ファイルを Cloud Storage にアップロードする方法を解説します。 システム構成 前提知識 環境構築 API の有効化 サービスアカウントの構築 Cloud Run jobs 用サービスアカウントの作成 Cloud Scheduler 用サービスアカウントの作成 Cloud Storage の構築 ページトークン格納用バケットの作成 アップロードファイル格納用バケットの作成 Cloud Run jobs の構築 Artifact Registry の作成 アプリケーションの準備 環境変数の設定 コンテナイメージのビルド Cloud Run jobs のデプロイ Cloud Scheduler の構築 動作確認 Google Drive のフォルダに対して Cloud Run jobs 用サービスアカウントに参照権限を付与 Cloud Run jobs を実行し、現在のページトークンを取得 Google Drive のフォルダに対してファイルを配置し、Cloud Run jobs を実行 補足 : Google Drive Events API システム構成 今回構築したシステム構成は、以下のとおりです。 構成図 Cloud Scheduler を使って定期的に Cloud Run jobs を起動します。 起動した Cloud Run jobs は、以下の流れで前回処理を行った以降に発生した Google Drive の差分を検知し、その差分のファイルを Cloud Storage にアップロードします。 ページトークン取得 差分ファイル情報取得 ファイルアップロード ページトークン更新 ページトークン は、Google Drive API で変更を追跡する際の起点となる識別子です。 このトークンを保存・更新することで、前回処理を実行した時点からの差分のみを効率的に取得できます。 参考 : 変更を取得する 前提知識 今回使用する Google Cloud サービスの詳細は、以下の記事をご参照ください。 Cloud Storage blog.g-gen.co.jp Cloud Run jobs blog.g-gen.co.jp Cloud Scheduler blog.g-gen.co.jp 環境構築 以下の順序で環境を構築しました。 API の有効化 サービスアカウントの構築 Cloud Storage の構築 Cloud Run jobs の構築 Cloud Scheduler の構築 API の有効化 Google Cloud プロジェクトで、今回の構成に必要な Google Cloud サービスの API を有効化します。 gcloud services enable \ artifactregistry.googleapis.com \ cloudbuild.googleapis.com \ run.googleapis.com \ cloudscheduler.googleapis.com \ drive.googleapis.com サービスアカウントの構築 Cloud Run jobs、Cloud Scheduler 用のサービスアカウントを作成します。 Cloud Run jobs 用サービスアカウントの作成 Google Cloud コンソールのサービスアカウント画面で、[サービスアカウントを作成] を選択します。 任意のサービスアカウント名を入力し、[作成して続行] を選択します。 作成したサービスアカウントに「Storage オブジェクト管理者（ roles/storage.objectAdmin ）」「ログ書き込み（ roles/logging.logWriter ）」の権限を付与して[完了]を選択します。 Cloud Scheduler 用サービスアカウントの作成 再度[サービスアカウントを作成] を選択し、任意のサービスアカウント名の入力を行い、[作成して続行] を選択します。 作成したサービスアカウントに「Cloud Run ジョブ エグゼキュータ（ roles/run.jobsExecutor ）」の権限を付与して[完了]を選択します。 Cloud Storage の構築 ページトークン格納用、アップロードファイル格納用のバケットを作成します。 ページトークン格納用バケットの作成 Google Cloud コンソールのバケット画面で、[作成] を選択します。 グローバルに一意の名前を入力し、[続行] を選択します。 データの保存場所を選択し、[作成] を選択します。 「このバケットに対する公開アクセス禁止を適用する」にチェックがついていることを確認し、[確認] を選択します。 アップロードファイル格納用バケットの作成 再度バケット画面で、[作成] を選択し、グローバルに一意の名前を入力してアップロードファイル格納用バケットを作成します。（設定内容はページトークン格納用バケットと同様） Cloud Run jobs の構築 Artifact Registry の作成、アプリケーションの準備、環境変数の設定、コンテナイメージのビルド、Cloud Run jobs のデプロイを行います。 Artifact Registry の作成 Google Cloud コンソールのリポジトリ画面で、[リポジトリの作成] を選択します。 任意のリポジトリ名とリージョンを指定し、[作成] を選択します。 アプリケーションの準備 今回開発する Python アプリケーションのディレクトリ構成は以下のとおりです。 drive-to-gcs-demo-app |-- requirements.txt |-- Dockerfile |-- main.py requirements.txt google-api-python-client google-auth google-cloud-storage google-cloud-logging Dockerfile FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY main.py . CMD [ " python ", " main.py " ] main.py import base64 import binascii import io import os import sys import google.auth import google.cloud.logging import logging from googleapiclient.discovery import build from googleapiclient.errors import HttpError from googleapiclient.http import MediaIoBaseDownload from google.cloud import storage from google.api_core import exceptions # --- 環境変数から設定を読み込み --- # アップロード先のGCSバケット名 UPLOAD_BUCKET_NAME = os.environ.get( 'UPLOAD_BUCKET_NAME' ) # pageTokenを保存するためのGCSバケット名（UPLOAD_BUCKET_NAMEと同じでも可） START_BUCKET_NAME = os.environ.get( 'START_BUCKET_NAME' ) # ログの出力レベル LOG_LEVEL = int (os.environ.get( 'LOG_LEVEL' )) # ログレベル debug=10 / info=20 / warning=30 # pageTokenを保存するファイル名 PAGE_TOKEN_FILE = 'drive_page_token.txt' # Cloud Logging クライアントを初期化し、ロギングを設定 client = google.cloud.logging.Client() client.setup_logging() # 標準の logger を取得し、ログレベルを設定 logger = logging.getLogger() logger.setLevel(LOG_LEVEL) # Google Drive APIのスコープ（読み取り専用） DRIVE_SCOPES = [ 'https://www.googleapis.com/auth/drive.readonly' ] def get_drive_service (): """ 実行環境のデフォルト認証情報を取得する """ credentials, _ = google.auth.default(scopes=DRIVE_SCOPES) return build( 'drive' , 'v3' , credentials=credentials) def read_page_token_from_gcs (storage_client: storage.Client) -> str | None : """GCSから前回のpageTokenを読み込む""" try : bucket = storage_client.bucket(START_BUCKET_NAME) blob = bucket.blob(PAGE_TOKEN_FILE) return blob.download_as_text() except exceptions.NotFound: # ファイルが存在しない場合は初回実行とみなし、Noneを返す logger.info(f "'{PAGE_TOKEN_FILE}' not found in GCS. Assuming first run." ) return None except Exception as e: logger.critical( f "CRITICAL: Failed to read page token from GCS due to an unexpected error. " f "This will cause the job to fail. Error: {e}" ) raise def write_page_token_to_gcs (storage_client: storage.Client, token: str ): """次回の実行のために新しいpageTokenをGCSに保存する""" try : bucket = storage_client.bucket(START_BUCKET_NAME) blob = bucket.blob(PAGE_TOKEN_FILE) blob.upload_from_string(token) logger.info(f "Successfully saved new page token to GCS: {token}" ) except Exception as e: logger.critical(f "CRITICAL: Failed to save new page token to GCS. {e}" ) # ここで失敗すると次回実行時に変更が重複する可能性があるため、エラーを明示 raise def stream_drive_file_to_gcs (drive_service, storage_client, drive_file_id, drive_file_name, bucket_name): """ 特定のファイルをDriveからGCSへ、一時ファイルを使わずに直接ストリーミングコピーする """ # GCSのオブジェクトパスとして、Driveのファイル名をそのまま使用する object_path = drive_file_name logger.info(f "--- Starting copy for '{drive_file_name}' ({drive_file_id}) to gs://{bucket_name}/{object_path} ---" ) try : # 1. Google Driveからファイルのメタデータを取得 (サイズ、MIMEタイプ、チェックサム) file_metadata = drive_service.files().get( fileId=drive_file_id, supportsTeamDrives= True , fields= 'size, mimeType, md5Checksum' ).execute() total_size = int (file_metadata.get( 'size' , 0 )) content_type = file_metadata.get( 'mimeType' , 'application/octet-stream' ) source_md5_checksum = file_metadata.get( 'md5Checksum' ) if not source_md5_checksum: logger.warning(f "Warning: MD5 checksum not available for '{drive_file_name}'. Skipping verification." ) # 2. GCSのアップロードストリームを開く bucket = storage_client.bucket(bucket_name) destination_blob = bucket.blob(object_path) with destination_blob.open( 'wb' , content_type=content_type) as gcs_stream: # 3. Driveのダウンローダーを初期化し、GCSストリームに直接接続 request = drive_service.files().get_media(fileId=drive_file_id) downloader = MediaIoBaseDownload(fd=gcs_stream, request=request, chunksize= 10 * 1024 * 1024 ) # 4. ダウンロード（＝アップロード）を開始 done = False while not done: status, done = downloader.next_chunk(num_retries= 3 ) if status: logger.info(f " Copy in progress: {int(status.progress() * 100)}%" ) logger.info( " Streaming finished." ) # 5. 整合性チェック (MD5チェックサムが取得できている場合のみ) if source_md5_checksum: destination_blob.reload() # GCSから最新のメタデータを取得 gcs_md5_b64 = destination_blob.md5_hash gcs_md5_hex = binascii.hexlify(base64.b64decode(gcs_md5_b64)).decode( 'utf-8' ) if source_md5_checksum == gcs_md5_hex: logger.info(f " Success! MD5 checksums match for '{drive_file_name}'." ) else : logger.error(f " ERROR: MD5 CHECKSUM MISMATCH for '{drive_file_name}'!" ) raise logger.info(f "--- Successfully copied '{drive_file_name}' ---" ) return True except HttpError as e: # 特にダウンロード権限がない(403)やファイルが見つからない(404)などの場合に発生 logger.error(f "ERROR: An HTTP error occurred while copying '{drive_file_name}': {e}" ) raise except Exception as e: logger.error(f "ERROR: An unexpected error occurred while copying '{drive_file_name}': {e}" ) raise def main (): """ Google Driveの変更を検知してGCSにファイルを同期するメインの処理 """ if not UPLOAD_BUCKET_NAME or not START_BUCKET_NAME or not LOG_LEVEL: logger.error( "Error: Environment variables 'UPLOAD_BUCKET_NAME' and 'START_BUCKET_NAME' and 'LOG_LEVEL' must be set." ) raise ValueError ( "Required environment variables are not set." ) drive_service = get_drive_service() storage_client = storage.Client() # 処理対象と対象外のファイル名を記録するためのリストを初期化 processed_files = [] skipped_files = [] page_token = read_page_token_from_gcs(storage_client) if page_token is None : # 初回実行時は、全ての変更を検知するための最初のトークンを取得する response = drive_service.changes().getStartPageToken().execute() page_token = response.get( 'startPageToken' ) logger.info(f "First run detected. Starting with token: {page_token}" ) logger.info(f "Processing changes starting from page token: {page_token}" ) while page_token is not None : response = drive_service.changes().list( pageToken=page_token, spaces= 'drive' , includeItemsFromAllDrives= True , supportsAllDrives= True , fields= 'nextPageToken, newStartPageToken, changes(fileId, file(id, name, trashed, mimeType))' ).execute() # 取得した差分情報の出力（debug） logger.debug(f "response info: {response}" ) for change in response.get( 'changes' , []): drive_file_id = change.get( 'fileId' ) drive_file_info = change.get( 'file' ) # ファイルが存在し、ゴミ箱になく、かつMIMEタイプが'application/pdf'である場合のみ処理を続行 if drive_file_info and not drive_file_info.get( 'trashed' ) and drive_file_info.get( 'mimeType' ) == 'application/pdf' : drive_file_name = drive_file_info.get( 'name' ) logger.info(f " \n PDF change detected, will process: '{drive_file_name}' (ID: {drive_file_id})" ) # 処理対象リストにファイル名を追加 processed_files.append(drive_file_name) # ストリーミングコピー関数を呼び出す stream_drive_file_to_gcs( drive_service=drive_service, storage_client=storage_client, drive_file_id=drive_file_id, drive_file_name=drive_file_name, bucket_name=UPLOAD_BUCKET_NAME ) else : # 処理対象外のファイルとして記録 if drive_file_info: file_name_to_skip = drive_file_info.get( 'name' , drive_file_id) skipped_files.append(file_name_to_skip) # スキップ理由をログに記録 reason = "" if drive_file_info.get( 'trashed' ): reason = "it is in trash" elif drive_file_info.get( 'mimeType' ) == 'application/vnd.google-apps.folder' : reason = "it is a folder" else : reason = f "its MIME type is not PDF ('{drive_file_info.get('mimeType')}')" logger.info(f "Skipping '{file_name_to_skip}' because {reason}." ) else : # ファイル情報自体がない場合 logger.info(f "Skipping change for file ID {drive_file_id} because file information could not be retrieved." ) # 次のページのトークンがあればループを継続、なければ終了 if 'nextPageToken' in response: page_token = response.get( 'nextPageToken' ) else : # ループ終了。次回の実行のために新しいStartPageTokenを保存 new_start_page_token = response.get( 'newStartPageToken' ) write_page_token_to_gcs(storage_client, new_start_page_token) logger.info( " \n Finished processing all changes." ) page_token = None # すべての処理ループが終わった後で、最終的な結果をINFOレベルでロギング logger.info( "--- Execution Summary ---" ) summary_processed = f "処理対象ファイル：{', '.join(processed_files)}" if processed_files else "処理対象ファイル：なし" summary_skipped = f "処理対象外ファイル：{', '.join(skipped_files)}" if skipped_files else "処理対象外ファイル：なし" logger.info(summary_processed) logger.info(summary_skipped) if __name__ == "__main__" : logger.info( "Cloud Run Job started." ) try : main() logger.info( "Cloud Run Job finished successfully." ) except Exception as e: logger.critical(f "Job failed with a critical error: {e}" , exc_info= True ) sys.exit( 1 ) finally : if 'client' in locals () and client: client.close() 環境変数の設定 以降の手順で繰り返し使用する Google Cloud プロジェクト ID やリージョンなどの情報を環境変数に設定します。 ご自身の環境に合わせて、以下のコマンドで環境変数を設定してください。 # Google Cloud プロジェクト ID export PROJECT_ID = " your-project-id " # プロジェクトのデフォルトリージョン export LOCATION = " asia-northeast1 " # Artifact Registry の名前 export REPO = " my-repo " # Image の名前 export IMAGE = " my-image " # Cloud Run jobs の名前 export JOB_NAME = " my-job " # Cloud Run jobs 用サービスアカウントの名前 export SERVICE_ACCOUNT_NAME = " cloud-run-jobs-sa " # アップロードファイル格納用のバケットの名前 export UPLOAD_BUCKET = " upload-drive-pdf " # ページトークン格納用のバケットの名前 export START_BUCKET = " pagetoken " コンテナイメージのビルド Dockerfile が存在するディレクトリで、以下の gcloud コマンドを実行します。 gcloud builds submit --tag ${LOCATION} -docker.pkg.dev/ ${PROJECT_ID} / ${REPO} / ${IMAGE} :latest Cloud Run jobs のデプロイ 作成したコンテナイメージを使用して、Cloud Run jobs をデプロイします。 gcloud run jobs deploy ${JOB_NAME} \ --image ${LOCATION} -docker.pkg.dev/ ${PROJECT_ID} / ${REPO} / ${IMAGE} :latest \ --region = ${LOCATION} \ --service-account =" ${SERVICE_ACCOUNT_NAME} @ $PROJECT_ID .iam.gserviceaccount.com " \ --set-env-vars =" UPLOAD_BUCKET_NAME= ${UPLOAD_BUCKET} " \ --set-env-vars =" START_BUCKET_NAME= ${START_BUCKET} " \ --set-env-vars =" LOG_LEVEL=20 " \ --tasks = 1 \ --max-retries = 3 \ --task-timeout = 1440m Cloud Scheduler の構築 Google Cloud コンソールのジョブ画面で、作成した Cloud Run jobs を選択します。 ジョブの詳細画面で、[トリガー]を選択し、[スケジューラトリガーを追加]を選択します。 任意の名前、リージョン、頻度、タイムゾーンを指定し、[続行] を選択します。 サービスアカウントに Cloud Scheduler 用サービスアカウントを設定し、[作成] を選択します。 動作確認 以下の順番で動作確認を行います。 Google Drive のフォルダに対して Cloud Run jobs 用サービスアカウントに参照権限を付与 Cloud Run jobs を実行し、現在のページトークンを取得 Google Drive のフォルダに対してファイルを配置し、Cloud Run jobs を実行 Google Drive のフォルダに対して Cloud Run jobs 用サービスアカウントに参照権限を付与 差分検知を行う Google Drive のフォルダ上で、共有アイコンを選択します。 Cloud Run jobs 用サービスアカウントに閲覧者権限を付与し、[共有]を選択します。 Cloud Run jobs を実行し、現在のページトークンを取得 今回は動作確認のため、Cloud Schduler による時刻起動は行わず、Google Cloud コンソールのジョブの詳細画面で、[実行] を選択します。 ページトークン格納用バケットにページトークンを保持するテキストファイルが配置されています。 Google Drive のフォルダに対してファイルを配置し、Cloud Run jobs を実行 差分検知を行う Google Drive のフォルダ上に PDF ファイルを配置します。 再度、Google Cloud コンソールのジョブの詳細画面で、[実行] を選択します。 アップロードファイル格納用のバケットに、Google Drive のフォルダに配置した PDF ファイルが配置されています。 補足 : Google Drive Events API 2025年7月7日に Google Drive Events API が Preview 公開されました。 Google ドライブのファイル変更通知を CloudEvent 仕様に従ってフォーマットされた Pub/Sub メッセージで受け取ることが可能 となるため、より活用の幅が広がることが期待されます。 参考 : Google ドライブのイベントを操作する 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の杉村です。 Agent Development Kit （ADK）は、Google Cloud が提供する、AI エージェント開発のためのフレームワークです。当記事では、ADK の中核をなす LLM Agent と Workflow Agents 、および Tools を解説します。 概要 Agent Development Kit（ADK）とは ADK のコンポーネント LLM Agent 概要 実装例 ソースコードの実行 Runner と非同期処理 Workflow Agents 概要 実装例 実行結果 詳細のロギング Tools 概要 関数の記述 要約のスキップ 概要 Agent Development Kit（ADK）とは Agent Development Kit（ADK） は、AI エージェントの開発、デプロイ、評価を効率化するために Google が開発したオープンソースのフレームワークです。2025年7月現在、Python および Java 向けのライブラリとして公開されています。 ADK を利用することで、開発者は通常のソフトウェア開発と同じような感覚で、モジュール化された再利用可能なコンポーネントを組み合わせて AI エージェントを開発できます。ADK は Google の生成 AI モデル Gemini や Vertex AI などのエコシステムに最適化されていますが、特定のモデルやデプロイ環境に依存しない設計思想を持っており、高い柔軟性と拡張性を備えています。 参考 : Agent Development Kit ADK のコンポーネント ADK でアプリを開発する際、以下のようなコンポーネントを記述します。 Agents タスクを実行する主体。LLM の推論能力を活用して自律的に動作する LLM Agent と、事前に定義された手順に従って動作する Workflow Agent がある。 Tools エージェントがタスクをこなすために利用するプログラム等。外部 API の呼び出しや計算、データベース検索など、特定の処理を行う。 参考 : Agents 参考 : Tools LLM Agent 概要 LLM Agent は、LLM の持つ推論能力を利用して、タスクを達成するために思考したり、どの Tool をどの順番で、どのようなパラメータで呼び出すかなどを自律的に判断するエージェントです。 ADK では基本的に、この LLM Agent を組み合わせて AI エージェントアプリケーションを開発しますので、最も基本的なコンポーネントであるといえます。 参考 : LLM Agent 実装例 LLM Agent を定義する際は、主に以下の要素を指定します。 属性 説明 instruction エージェントの役割、振る舞い、タスクの進め方などを自然言語で記述した指示書 model 使用するモデル（gemini-2.5-flash など） tools エージェントが利用可能なツール（道具）。Python の関数や他のエージェントなど 以下は、都市ごとの現在時刻を返す簡単な Tool を持つ LLM Agent の Python サンプルコードです。このエージェントに「東京の天気は？」と質問すると、LLM は get_weather ツールを city="東京" という引数で呼び出すべきだと判断（Reasoning）し、実行します。そして、Tool から返された「晴れです。」という結果（Observation）を元に、最終的な回答を生成します。 import asyncio import datetime from google.adk.agents import LlmAgent from google.adk.runners import Runner from google.adk.sessions import InMemorySessionService from google.genai import types def get_time (city: str ): ''' # 概要 指定された都市の現在時刻を取得します。 # 引数 city (str): 対象の都市名 (Tokyo / Los Angels / London) ''' print (f "--- Tool: get_weather (city: {city}) ---" ) if "Tokyo" in city: tz = datetime.timezone(datetime.timedelta(hours= 9 )) elif "Los Angels" in city: tz = datetime.timezone(datetime.timedelta(hours=- 7 )) elif "London" in city: tz = datetime.timezone(datetime.timedelta(hours= 0 )) else : tz = None if tz: now = datetime.datetime.now(tz) else : now = None message = { "city" : city, "datetime" : now } return message # LLM Agentの定義 time_agent = LlmAgent( model= "gemini-2.5-flash" , name= "time_agent" , instruction= """ あなたは時刻案内をするエージェントです。 ユーザーから尋ねられた都市の現在時刻を答えてください。 利用可能なツールを使って情報を取得し、最終的な回答を生成してください。 """ , tools=[get_time] ) # runner の定義 APP_NAME = "My Agent App" SESSION_SERVICE = InMemorySessionService() RUNNER = Runner( agent=time_agent, app_name=APP_NAME, session_service=SESSION_SERVICE, ) async def stream_agent_events (query: str , user_id: str , session_id: str ): ''' # 概要 エージェントを実行します。 # 引数 query (str): エージェントに投げかけるクエリ（プロンプト） user_id (str): ユーザー ID session_id (str): セッション ID ''' # 既存セッションがなければ新規作成 session = await SESSION_SERVICE.get_session(app_name=APP_NAME, user_id=user_id, session_id=session_id) if not session: await SESSION_SERVICE.create_session(app_name=APP_NAME, user_id=user_id, session_id=session_id) # ユーザークエリを所定の形式で格納 content = types.Content(role= 'user' , parts=[types.Part(text=query)]) # エージェントの実行 async for event in RUNNER.run_async(user_id=user_id, session_id=session_id, new_message=content): parts = event.content.parts message = event.content.parts[ 0 ].text if message: yield (f "--- Message: {message}" ) return async def main (): """ エージェントを実行し、ストリーミングされたメッセージを出力するメイン関数 """ user_id= "test_user" session_id= "test_session" query= "東京の現在時刻は？" # async for を使って非同期ジェネレータを処理 async for message in stream_agent_events(query=query, user_id=user_id, session_id=session_id): print (message) # スクリプトのエントリーポイント if __name__ == "__main__" : asyncio.run(main()) ソースコードの実行 ADK で記述したエージェントは、以下で紹介されているように、ADK に組み込まれた動作テスト用 Web UI を使って動作確認することができます。 参考 : Quickstart 参考 : ADKのSequential agentsを使って実装するマルチエージェント - G-gen Tech Blog ADK のテスト用 Web UI あるいは、以下の記事のように Vertex AI Agent Engine にデプロイして、リモートから呼び出して実行することもできます。 参考 : Agent Development Kitでエージェントを開発してAgent Engineにデプロイしてみた - G-gen Tech Blog しかし今回の記事では、Cloud Run などにホストされたアプリケーションに組み込むことを想定して、異なる方法で実行します。 まずは、前述のソースコードを main.py として保存します。 実行環境には、 pip install google-adk で ADK をインストールします。必要に応じて venv を用意してください。 さらに、以下のようなコマンドを実行して、環境変数を定義します。これらの環境変数は、ADK が Gemini モデルを呼び出す先の API エンドポイントを決めるのに必要です。 .env ファイルなどに書き込んでおき、実行前に source .env コマンドを実行する方法で変数を定義しても構いません。実際の動作環境では、Cloud Run service のリビジョンに環境変数で定義する想定です。 export GOOGLE_GENAI_USE_VERTEXAI = " TRUE " export GOOGLE_CLOUD_PROJECT = " my-project " export GOOGLE_CLOUD_LOCATION = " global " 上記を実施したうえで main.py を実行すると、以下のように出力されます。 $ python main.py --- Tool: get_weather ( city: Tokyo ) --- --- Message: 東京の現在時刻は 2025 年 7 月 21 日 9 時 36 分です。 Runner と非同期処理 前述のソースコードの関数 stream_agent_events は、 asyncio.run によって非同期実行されています。 asyncio は Python の標準ライブラリであり、並行処理を実現するための機能です。 参考 : Runtime 参考 : Build Your First Intelligent Agent Team: A Progressive Weather Bot with ADK Runner は、エージェントを動かすためのエンジンです。run_async でプロンプトを渡して実行すると、イベントを順次返します。このソースコードでは非同期関数 stream_agent_events の中で Runner を実行しており、エージェントにより生成された結果は yield によって順次、呼び出し元に返されて print されます。 これにより、複数のエージェントによって長い処理が行われる場合でも、処理の進行状況をユーザーに知らせることができます。 Workflow Agents 概要 Workflow Agents は、あらかじめ定義された順番でサブエージェント（子エージェント）を呼び出すためのエージェントです。Workflow Agents の動作は決定論的、つまり事前に定義したとおりに動くものであり、必ず指定した順番でサブエージェントが実行されます。モデルの指定も存在しません。 参考 : Workflow Agents Workflow Agents には以下の種類があります。 名称 説明 Sequential Agents サブエージェントを指定した順番で順次実行 Parallel Agents サブエージェントを並列で実行 Loop Agents サブエージェントを指定した順番で順次実行。指定条件が満たされるまで繰り返す Workflow Agents は、その制御性の高さから以下のようなユースケースに適しています。 顧客からの問い合わせを定型的なプロセスで処理する 例: 内容判断 → チケット起票 → 担当者割り当て 決まった手順で行われるデータ処理やバッチ処理の自動化 ビジネスプロセスオートメーション（BPA） 実装例 サブエージェントを順次実行する Sequential Agents の実装例を以下に示します。 import asyncio import datetime import logging from google.adk.agents import LlmAgent, SequentialAgent from google.adk.runners import Runner from google.adk.sessions import InMemorySessionService from google.adk.tools import google_search from google.genai import types def get_time (city: str ): ''' # 概要 指定された都市の現在時刻を取得します。 # 引数 city (str): 対象の都市名 (Tokyo / Los Angels / London) ''' print (f "--- Tool: get_weather (city: {city}) ---" ) if "Tokyo" in city: tz = datetime.timezone(datetime.timedelta(hours= 9 )) elif "Los Angels" in city: tz = datetime.timezone(datetime.timedelta(hours=- 7 )) elif "London" in city: tz = datetime.timezone(datetime.timedelta(hours= 0 )) else : tz = None if tz: now = datetime.datetime.now(tz) else : now = None message = { "city" : city, "datetime" : now } return message # 時刻案内エージェント time_agent = LlmAgent( model= "gemini-2.5-flash" , name= "time_agent" , instruction= """ あなたは時刻案内をするエージェントです。 tools を使ってユーザーが住んでいる都市の現在時刻を取得します。 """ , tools=[get_time], output_key = "city_and_datetime" ) # 雑学エージェント trivia_agent = LlmAgent( model= "gemini-2.5-flash" , name= "time_agent" , instruction= """ # 役割 あなたは雑学を披露するエージェントです。 ユーザーが住んでいる国にとって、今日がなんの日か（その国の祝日、記念日など）を調べて回答します。 どうしても特別な日でないときは、最も近い祝日や記念日などを返してください。 # ユーザーが住んでいる国と日付 {city_and_datetime} """ , tools=[google_search] ) # シーケンシャルエージェント root_agent = SequentialAgent( name= "root_agent" , sub_agents=[time_agent, trivia_agent], description= "本日日付を取得し、次にその日に関する雑学を披露する" , ) # runner の定義 APP_NAME = "My Agent App" SESSION_SERVICE = InMemorySessionService() RUNNER = Runner( agent=root_agent, app_name=APP_NAME, session_service=SESSION_SERVICE, ) async def stream_agent_events (query: str , user_id: str , session_id: str ): ''' # 概要 エージェントを実行します。 # 引数 query (str): エージェントに投げかけるクエリ（プロンプト） user_id (str): ユーザー ID session_id (str): セッション ID ''' # 既存セッションがなければ新規作成 session = await SESSION_SERVICE.get_session(app_name=APP_NAME, user_id=user_id, session_id=session_id) if not session: await SESSION_SERVICE.create_session(app_name=APP_NAME, user_id=user_id, session_id=session_id) # ユーザークエリを所定の形式で格納 content = types.Content(role= 'user' , parts=[types.Part(text=query)]) # エージェントの実行 async for event in RUNNER.run_async(user_id=user_id, session_id=session_id, new_message=content): parts = event.content.parts message = event.content.parts[ 0 ].text if message: yield (f "--- Message: {message}" ) return async def main (): """ エージェントを実行し、ストリーミングされたメッセージを出力するメイン関数 """ user_id= "test_user" session_id= "test_session" query= "私は東京在住です。" # async for を使って非同期ジェネレータを処理 async for message in stream_agent_events(query=query, user_id=user_id, session_id=session_id): print (message) # # ロギングを設定（必要に応じてコメントを外す） # logging.basicConfig( # level=logging.DEBUG, # format='%(asctime)s - %(levelname)s - %(name)s - %(message)s' # ) # スクリプトのエントリーポイント if __name__ == "__main__" : asyncio.run(main()) 実行結果 出力は以下のようになります。 $ python sequential.py --- Tool: get_weather ( city: Tokyo ) --- --- Message: 現在の時刻は、 2025 年 7 月 21 日 9 時 40 分です。 --- Message: 東京にお住まいのあなたにとって、 2025 年 7 月 21 日は「海の日」です。 海の日とは、海の恩恵に感謝し、海洋国家である日本の繁栄を願う国民の祝日です。 毎年 7 月の第 3 月曜日と定められており、 2025 年は 7 月 21 日がこれに当たります。 世界で唯一、「海の日」を国民の祝日としているのは日本だけです。 time_agent と trivia_agent の情報の受け渡しに使われている output_key については、以下の記事も参照してください。 参考 : ADKのSequential agentsを使って実装するマルチエージェント - G-gen Tech Blog 詳細のロギング 前述のソースコード内でコメントアウトしているロギング設定の行から # を削除してコメントでなくすると、ADK の処理の詳細が標準出力に出力されます。エージェントがどのような順番で呼び出され、またどのようなプロンプトで呼び出されたのかがわかるため、デバッグやチューニングのときに役立ちます。 以下は、一部を省略していますが、詳細なロギング出力の結果です。 2025-07-21 01:11:24,627 - DEBUG - asyncio - Using selector: EpollSelector 2025-07-21 01:11:24,926 - INFO - google_adk.google.adk.models.google_llm - Sending out request, model: gemini-2.5-flash, backend: GoogleLLMVariant.VERTEX_AI, stream: False 2025-07-21 01:11:24,926 - INFO - google_adk.google.adk.models.google_llm - LLM Request: ----------------------------------------------------------- System Instruction: あなたは時刻案内をするエージェントです。 tools を使ってユーザーが住んでいる都市の現在時刻を取得します。 You are an agent. Your internal name is "time_agent". ----------------------------------------------------------- Contents: {"parts":[{"text":"私は東京在住です。"}],"role":"user"} ----------------------------------------------------------- Functions: get_time: {'city': {'type': <Type.STRING: 'STRING'>}} ----------------------------------------------------------- 〜〜〜〜〜（略）〜〜〜〜〜 --- Tool: get_weather (city: Tokyo) --- 2025-07-21 01:11:27,100 - INFO - google_adk.google.adk.models.google_llm - Sending out request, model: gemini-2.5-flash, backend: GoogleLLMVariant.VERTEX_AI, stream: False 2025-07-21 01:11:27,101 - INFO - google_adk.google.adk.models.google_llm - LLM Request: ----------------------------------------------------------- System Instruction: あなたは時刻案内をするエージェントです。 tools を使ってユーザーが住んでいる都市の現在時刻を取得します。 You are an agent. Your internal name is "time_agent". ----------------------------------------------------------- Contents: {"parts":[{"text":"私は東京在住です。"}],"role":"user"} {"parts":[{"function_call":{"args":{"city":"Tokyo"},"name":"get_time"}}],"role":"model"} {"parts":[{"function_response":{"name":"get_time","response":{"city":"Tokyo","datetime":"2025-07-21T10:11:26.994246+09:00"}}}],"role":"user"} ----------------------------------------------------------- Functions: get_time: {'city': {'type': <Type.STRING: 'STRING'>}} ----------------------------------------------------------- 〜〜〜〜〜（略）〜〜〜〜〜 LLM Request: ----------------------------------------------------------- System Instruction: # 役割 あなたは雑学を披露するエージェントです。 ユーザーが住んでいる国にとって、今日がなんの日か（その国の祝日、記念日など）を調べて回答します。 どうしても特別な日でないときは、最も近い祝日や記念日などを返してください。 # ユーザーが住んでいる国と日付 東京の現在時刻は2025-07-21T10:11:26.994246+09:00です。 You are an agent. Your internal name is "time_agent". ----------------------------------------------------------- Contents: {"parts":[{"text":"私は東京在住です。"}],"role":"user"} {"parts":[{"function_call":{"args":{"city":"Tokyo"},"name":"get_time"}}],"role":"model"} {"parts":[{"function_response":{"name":"get_time","response":{"city":"Tokyo","datetime":"2025-07-21T10:11:26.994246+09:00"}}}],"role":"user"} {"parts":[{"text":"東京の現在時刻は2025-07-21T10:11:26.994246+09:00です。"}],"role":"model"} {"parts":[{"text":"Continue processing previous requests as instructed. Exit or provide a summary if no more outputs are needed."}],"role":"user"} ----------------------------------------------------------- Functions: ----------------------------------------------------------- シーケンシャルにエージェントが呼び出されており、またシステムインストラクションに指定した output_key である {city_and_datetime} が正しく反映されていることもわかります。 Tools 概要 Tools は、LLM Agent が道具として使うプログラムです。Tools には以下のような種類があります。 名称 説明 Function tools コーディングされた関数を実行する。外部処理を呼び出したり、計算処理を行わせる等。また Agent-as-a-Tool ではエージェントから他のエージェントを tool として呼び出し可能。 Build-in tools ADK に組み込みの Tool。Google 検索実行ツール、コード生成・実行ツール、Vertex AI Search での検索実行ツール、BigQuery ツールなど。例えば自然言語の指示に基づいて BigQuery へクエリするといった処理を、コードを書くことなく実現できる。 Third party tools CrewAI や LangChain などで定義された Tools を実行。 Google Cloud tools Apigee API Hub、Application Integration、MCP Toolbox for Database などを呼び出し。 MCP tools エージェントから MCP server を呼び出し。 LLM Agent は Tools を呼び出すかどうか、またどういったパラメータで呼び出すかを自律的に判断し、実行します。これにより、ADK アプリケーションは LLM が持つ能力を超えて、さまざまなタスクを行うことができます。 参考 : Tools 関数の記述 LLM が適切に Tools を呼び出すためには、例えば Function tools においては、適切な方法で関数を記述することが重要です。 参考 : Function tools - Best Practices わかりやすい関数名、引数名、Tool 名 LLM が適切に判断して Tools を呼び出すためには、関数名や引数名、Tool 名などを、LLM が理解しやすい 明確でわかりやすい名称 にする必要があります。一般的すぎる名称は避け、例えばその関数が何をするものなのか明確になるよう、 動詞_目的語() のような名称とします。 Docstring を記述する 関数の Docstring （関数の説明）を適切に記載することが重要です。LLM はこれらを読み取り、Tools を呼び出すべきかどうか、またどのような引数を与えるべきかを判断します。 引数はシンプルに Tools の関数の引数は少なめに、シンプルにします。複雑すぎると、LLM が関数を適切に使用できません。また、データ型もカスタムのものより str や int などシンプルなものが望ましいです。 戻り値は辞書型 Tools の実行結果を LLM が適切に使用できるよう、 戻り値のフォーマット も重要です。Python においては辞書型（dictionary）、Java においては Map 型で返すのが理想的です。 要約のスキップ 先程の2つのサンプルソースコードでは、簡単な Function tools を使って現在時刻を取得しました。 通常、Function tools 等が実行されると、tool の実行結果は LLM に渡され、LLM はそれを解釈して最終回答を生成します。しかし、例えば tool の実行結果をそのままユーザーに返したい場合や、あるいは処理時間短縮のために tool の実行結果を LLM に解釈させずに次のエージェントに渡したいケースもあります。 その場合、 要約をスキップ させることで、LLM による解釈をスキップして tool の実行結果をそのまま LLM Agent の最終回答とさせることができます。 先程の Sequential agents のサンプルコードの tool 関数定義を、以下のように修正します。変更点は、ToolContext を import した点と、関数の引数に tool_context: ToolContext を追加した点、また tool_context.actions.skip_summarization = True を追加した点です。 # 〜〜〜〜〜（略）〜〜〜〜〜 from google.adk.tools import google_search, ToolContext # 〜〜〜〜〜（略）〜〜〜〜〜 def get_time (city: str , tool_context: ToolContext): ''' # 概要 指定された都市の現在時刻を取得します。 # 引数 city (str): 対象の都市名 (Tokyo / Los Angels / London) ''' # ツールの結果は要約されずそのままアウトプットとして扱われる tool_context.actions.skip_summarization = True print (f "--- Tool: get_weather (city: {city}) ---" ) if "Tokyo" in city: tz = datetime.timezone(datetime.timedelta(hours= 9 )) elif "Los Angels" in city: tz = datetime.timezone(datetime.timedelta(hours=- 7 )) elif "London" in city: tz = datetime.timezone(datetime.timedelta(hours= 0 )) else : tz = None if tz: now = datetime.datetime.now(tz) else : now = None message = { "city" : city, "datetime" : now } return message これにより、関数が return した結果は LLM によって解釈されず、そのまま time_agent の最終回答として、次のエージェントに渡されます。 しかしこのとき、ロギングを詳細に出力していると、次に実行されたエージェント trivia_agent のシステムインストラクションで、output_key が反映されていないことに気が付きます。詳細ログは以下のようになりました。 ----------------------------------------------------------- System Instruction: # 役割 あなたは雑学を披露するエージェントです。 ユーザーが住んでいる国にとって、今日がなんの日か（その国の祝日、記念日など）を調べて回答します。 どうしても特別な日でないときは、最も近い祝日や記念日などを返してください。 # ユーザーが住んでいる国と日付 You are an agent. Your internal name is "time_agent". ----------------------------------------------------------- # ユーザーが住んでいる国と日付 の下には、本来 {city_and_datetime} があるため、tool が返した辞書型のデータ（ city と datetime ）が入っているべきです。しかし、要約をスキップした場合は、output_key が次のエージェントに渡されません。これは、output_key に値が代入されるのは LLM による最終回答生成後であるためであると考えられます。要約をスキップした場合は output_key に値が入りません。 しかしこのような状況でも、エージェント trivia_agent は以下のような回答を生成しました。 東京にお住まいのあなたにとって、2025年7月21日は「海の日」です。海の日とは、「海の恩恵に感謝するとともに、海洋国日本の繁栄を願う日」として制定された国民の祝日です。 この日は毎年7月の第3月曜日と定められており、2025年は7月21日がこれに当たります。 また、海の日以外にも、7月21日には「日本三景の日」、「神前結婚記念日」、「自然公園の日」、「烏骨鶏の日」といった様々な記念日があります。 これは、LLM Agent は output_key で情報を渡されなくても、これまで実行された LLM Agent や Tools の実行結果をコンテキストとして保持しており、そのコンテキストに基づいて生成を行っているためであると考えられます。詳細ロギングを確認すると、trivia_agent の実行時に以下のようなログが出力されていました。 2025-07-21 01:35:40,257 - INFO - google_adk.google.adk.models.google_llm - LLM Request: ----------------------------------------------------------- System Instruction: # 役割 あなたは雑学を披露するエージェントです。 ユーザーが住んでいる国にとって、今日がなんの日か（その国の祝日、記念日など）を調べて回答します。 どうしても特別な日でないときは、最も近い祝日や記念日などを返してください。 # ユーザーが住んでいる国と日付 You are an agent. Your internal name is "time_agent". ----------------------------------------------------------- Contents: {"parts":[{"text":"私は東京在住です。"}],"role":"user"} {"parts":[{"function_call":{"args":{"city":"Tokyo"},"name":"get_time"}}],"role":"model"} {"parts":[{"function_response":{"name":"get_time","response":{"city":"Tokyo","datetime":"2025-07-21T10:35:40.174769+09:00"}}}],"role":"user"} ----------------------------------------------------------- Functions: ----------------------------------------------------------- Contents: のブロックの中にある function_response という行が、関数の実行結果です。 # ユーザーが住んでいる国と日付 の直下にあるべき output_key は空文字列になっているものの、Contents として含まれている情報を LLM Agent がコンテキストとして使って生成を行っていることがわかります。output_key を使ったほうが、より複雑なプロンプトで役割やタスク、背景、フォーマットを指定する際に効果的であると考えられますが、output_key を使わなくても、ある程度の精度で他のエージェントや tools の出力結果がコンテキストとして使われることがわかります。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの山田です。BigQueryの保存済みクエリ機能を使うと、クエリエディタで記述した SQL を保存して他のユーザーと共有することができます。SQL をプロジェクトにアップロードしようとした際に [プロジェクトにアップロードする] > [SQL クエリ] のメニューがグレーアウトして選択できない事象が起きました。この事象の原因と対処法を解説します。 事象 原因 対処法 概要 Dataform API の有効化 IAM ロールが正しく設定されていること クエリの移行 事象 BigQuery のコンソール画面でクエリエディタを開き、SQL クエリをプロジェクトにアップロードしようとしたところ、以下の図のように [プロジェクトにアップロードする] > [SQL クエリ] のメニューがグレーアウトし、選択できない状態でした。 原因 原因は、BigQuery の保存済みクエリの仕様変更にあります。 従来の保存済みクエリは、 Dataform を基盤とした新しい保存済みクエリへ移行される予定です。これは、2025年2月と6月に Google Cloud から「Transition from classic saved queries to new saved queries」という件名のメールで案内されています。この新しい保存済みクエリを利用するには、対象プロジェクトで Dataform API を有効化し、ユーザーに適切な IAM 権限 を付与する必要があります。 今回の事象は、この Dataform API が有効になっていなかったために発生しました。 2025年6月現在、2025年3月に予定されていた移行は延期されており、サポート終了時期は公開されていません。2025年末までに新たな情報が更新される予定です。 参考 : 保存済みクエリの概要 - 従来の保存したクエリ 対処法 概要 新しい保存済みクエリを使用するには以下の条件を満たしている必要があります。 Dataform API の有効化 IAM ロールが正しく設定されていること Dataform API の有効化 SQL クエリをアップロードしたいプロジェクトで Dataform API が有効になっていることを確認します。Google Cloud コンソールで [API とサービス] > [ライブラリ] へ移動し、「Dataform API」を検索して有効化してください。 参考 : Dataform で SQL ワークフローを作成して実行する - 始める前に IAM ロールが正しく設定されていること 新しい保存済みクエリの閲覧や編集には、適切な IAM ロールが必要です。クエリは Dataform のリソースとして保存されるため、Dataform 関連の権限が付与されているか確認してください。 BigQuery の新しい保存済みクエリを操作するには、操作者アカウントがプロジェクトに対して以下の IAM ロールを持っている必要があります。 操作内容 必要なIAMロール（いずれか一つ） クエリの作成 BigQuery ジョブユーザー（ roles/bigquery.jobUser ） コード作成者 ( roles/dataform.codeCreator ） クエリの編集 BigQuery ジョブユーザー（ roles/bigquery.jobUser ） コード編集者（ roles/dataform.codeEditor ） クエリの表示 BigQuery ジョブユーザー（ roles/bigquery.jobUser ） コード閲覧者（ roles/dataform.codeViewer ） 参考 : 保存済みクエリを作成する - 必要な権限 クエリの移行 従来の保存済みクエリは、以下の公式ドキュメントを参考に、新しい保存済みクエリに移行することができます。2025年6月現在では、従来の保存済みクエリの廃止時期は未定ですが、早めの移行が推奨されます。 参考 : 保存済みクエリを管理する - 従来の保存済みクエリを移行する 山田 剛史 (記事一覧) クラウドソリューション部 クラウドサポート課 2025年6月にG-genに入社。IT基盤領域やグループウェアが得意。Google Workspace や Google Cloud を日々勉強中。

G-genの福井です。Cloud Storage バケットへのアクセスを送信元 IP アドレスに基づいて制御する IP フィルタリング機能の概要と設定方法、そして VPC Service Controls との違いについて解説します。 はじめに Cloud Storage の IP フィルタリングとは 機能の概要 ユースケース VPC Service Controls との違い 機能比較 使い分けのポイント 制限事項 設定方法 前提条件 必要な権限 IP フィルタリング設定用 JSON バケット作成時にフィルタリング設定 既存バケットにフィルタリング設定 フィルタリング ルールを取得 フィルタリング ルールを無効化 IPフィルタリングのバイパス設定 概要 ユースケース 設定方法 運用の注意点 はじめに Cloud Storage は、高い耐久性とスケーラビリティを持つオブジェクトストレージサービスであり、その用途は多岐にわたります。様々なネットワーク環境からアクセスが可能であるため、意図しないリクエストを防ぐためのアクセス制御が重要です。 Google Cloud は IAM や VPC Service Controls といった多様なセキュリティ機能を提供しています。その中でも、送信元のパブリック IP アドレスに基づいてアクセスをシンプルに制御したい、という要件に応えるのが当記事で解説する IP アドレスフィルタリング機能 です。 当記事では、IP アドレスフィルタリング機能の概要から、類似機能である VPC Service Controls との違い、使用上の注意点、そして具体的な設定手順までを解説します。 Cloud Storage の IP フィルタリングとは 機能の概要 Cloud Storage の IP フィルタリングは、バケットへのアクセスを 送信元の IP アドレスに基づいて制御する 機能です。 この機能を有効にすると、許可設定した IP アドレスからのリクエストのみが許可されます。許可設定していない IP アドレスからのリクエストは、ステータスコード 403 Forbidden で拒否されます。 このフィルタリングは、バケット単位で設定し、そのバケット内の全オブジェクトに適用されます。制御できるアクセス元は以下の通りです。 アクセス元の種類 説明 パブリック IP インターネット経由でのアクセスを、送信元のグローバル IP アドレスで制御します。 VPC ネットワーク VPC ネットワーク内からのアクセスを、その VPC ネットワークで予約された IP アドレスで制御します。 この機能の重要な点は、Cloud Storage の認証システムの前に評価されることです。つまり、たとえ有効な認証情報を持っていたとしても、許可されていない IP アドレスからのリクエストはバケットに到達する前にブロックされます。 参考 : IP アドレス フィルタリングの概要 ユースケース この機能は、特定のネットワーク環境からのアクセスのみに制限したい場合に有効です。 ユースケース 説明 特定の拠点からのアクセス制限 本社や支社のオフィス、あるいは特定のデータセンターの固定 IP アドレスからのみ、バケットへのアクセスを許可したい場合に使用します。 特定のアプリケーション環境からのアクセス制限 Google Cloud の VPC ネットワーク内で稼働するアプリケーションからのアクセスのみに限定したい場合に使用します。これにより、意図しない他のリソースからのアクセスをネットワークレベルで防ぐことができます。 多層的なセキュリティの実現 IAM による認証・認可に加え、ネットワークレベルでのアクセス制御を組み合わせることで、認証情報が万が一漏洩した際の情報流出リスクを低減し、より強固なセキュリティを実現します。 VPC Service Controls との違い Cloud Storage へのアクセスをネットワークレベルで制御する機能として、IP アドレスフィルタリングの他に VPC Service Controls があります。両者は似ているようで、その目的と機能は大きく異なります。 機能比較 特徴 IP アドレスフィルタリング VPC Service Controls 目的 送信元 IP に基づくシンプルなアクセス制御 サービス境界（Perimeter）を作成し、境界の外から中へのアクセスを防いだり、逆に境界の中から外へのデータ流出等を防ぐ 適用範囲 Cloud Storage のバケット単位 単一または複数のプロジェクトをサービス境界に含めることが可能。組織レベルでのデータガバナンスを実現する 主な制御要素 送信元のパブリック IP または VPC 送信元のネットワークロケーション（VPC, オンプレミス）、ID、デバイスなど、複数のコンテキスト 設定の複雑さ シンプル 。許可したい IP のリストを定義するのみ 高度 。サービス境界、アクセスレベル、ブリッジなどの設計が必要 使い分けのポイント どちらの機能を選択するかは、セキュリティ要件によって決まります。 セキュリティ要件 推奨される機能 「特定のオフィスの固定 IP からのみアクセスさせたい」など、要件が シンプル な場合 IP アドレスフィルタリング IP アドレスだけでなく、ユーザー ID やデバイス情報なども含めた 多角的なアクセス制御 が必要な場合 VPC Service Controls Cloud Storage だけでなく、BigQuery など他のサービスも含めて、組織として データ持ち出しを厳密に防ぎたい 場合 VPC Service Controls 基本的には、特定の IP アドレスからのアクセスをシンプルに制限したい場合は IP アドレスフィルタリングを、より広範で強力なデータ保護境界を構築したい場合は VPC Service Controls を選択します。 blog.g-gen.co.jp 制限事項 IP アドレスフィルタリング機能には、使用する上で制限があります。 制限事項 内容 許可される IP CIDR ブロックの最大数 パブリックネットワークと VPC ネットワークを合わせて、最大 200 個の IP CIDR ブロックを指定できます。 許可される VPC ネットワークの最大数 最大 25 個 の VPC ネットワークを指定できます。 リージョンエンドポイントのサポート リージョンエンドポイントは、Private Service Connect を使用する場合にのみサポートされます。 一部 Google Cloud サービスとの連携 BigQuery のように、データのインポート/エクスポートで Cloud Storage を使用するサービスからのアクセスが制限されます。サービスの中断を避けるため、これらのサービスがアクセスするバケットでは IP フィルタリングの使用は推奨されません。 App Engine からのアプリケーション App Engine アプリケーションが Cloud Storage のデータにアクセスする場合は、VPC を介して使用することが推奨されます。 Cloud Shell のサポート Cloud Shell からのアクセスはサポートされていません。 参考 : 制限事項 設定方法 ここからは、実際に IP アドレスフィルタリング機能を設定する手順を解説します。 2025年7月現在、Google Cloud コンソールからの設定には対応していません。 当記事では gcloud コマンドを使った手順を紹介します。 前提条件 IP フィルタリングの設定には、Google Cloud CLI バージョン 526.0.0 以降が必要です。古いバージョンの CLI を使用して、IP フィルタリングの設定を行うと、以下のエラーが発生します。 Found invalid JSON/YAML for the IP filter rule. エラーが発生した場合は、以下のコマンドでバージョンを確認し、必要に応じて更新してください。 # バージョン確認 gcloud version | head -n 1 # バージョン更新 gcloud components update --version = 526 . 0 . 0 必要な権限 IP アドレスフィルタリングの設定には、以下のIAM権限が必要です。 操作 権限 IP フィルタリング ルールを使用してバケットを作成 storage.buckets.create storage.buckets.setIpFilter バケットの IP フィルタリング ルールを更新 storage.buckets.update storage.buckets.setIpFilter バケットの IP フィルタリング ルールを取得 storage.buckets.get storage.buckets.getIpFilter バケット IP フィルタリングを無効 storage.buckets.update storage.buckets.setIpFilter これらの権限を取得する最も簡単な方法は、対象プロジェクトまたはバケットに対して ストレージ管理者 （ roles/storage.admin ）のロールを付与することです。この事前定義ロールには、上記の権限が含まれています。また、これらの権限を持つカスタムロールを個別に作成することも可能です。 IP フィルタリング設定用 JSON IP フィルタリングの設定は、バケットの新規作成時、または既存のバケットに対して行います。いずれのシナリオでも、設定内容を記述した JSON ファイルをコマンドで読み込ませて設定します。 特定のパブリック IP 範囲 指定したパブリック IPv4 アドレス範囲からのアクセスを許可し、VPC からのアクセスをブロックする設定です。 { " mode ": " Enabled ", " publicNetworkSource ": { " allowedIpCidrRanges ": [ " 192.0.2.0/24 " ] } , " allowCrossOrgVpcs ": false , " allowAllServiceAgentAccess ": false } 特定の VPC ネットワーク範囲 指定した VPC の IPv4 アドレスからのアクセスを許可し、パブリック IP からのアクセスをブロックする設定です。 { " mode ": " Enabled ", " vpcNetworkSources ": [ { " network ": " projects/[PROJECT_ID]/global/networks/[NETWORK_NAME] ", " allowedIpCidrRanges ": [ " 192.0.2.0/24 " ] } , ] , " allowCrossOrgVpcs ": false , " allowAllServiceAgentAccess ": false } 設定項目の解説 項目 説明 mode フィルタリングのモードを指定します。 Enabled : IP フィルタリングを有効にし、設定されたルールに基づいてリクエストを評価します。 Disabled : フィルタリングを無効にし、すべてのリクエストを許可します（ルールは保持されます）。 publicNetworkSource パブリック IP アドレスからのアクセスに関するルールを定義するオブジェクトです。 allowedIpCidrRanges バケットへのアクセスを許可するパブリックな IPv4 または IPv6 の CIDR 範囲のリストです。（例: ["192.0.2.0/24", "2001:db8::/32"] ） vpcNetworkSources VPC ネットワークからのアクセスに関するルールを定義するオブジェクトのリストです。 network VPC ネットワークの名前です。 PROJECT_ID は、VPC ネットワークが存在するプロジェクト ID NETWORK_NAME は、バケットへのアクセスを許可する VPC ネットワークの名前 allowCrossOrgVpcs 組織（Organization）をまたいだ VPC ネットワークからのアクセスを許可するかどうかを指定します。 true : 組織をまたいだアクセスを許可します。 false : バケットと同じ組織内の VPC に限定します。（デフォルト） allowAllServiceAgentAccess Google Cloud のサービスエージェントからのアクセスを、IP フィルタリングの設定に関わらずすべて許可するかどうかを指定します。 true : 他の Google Cloud サービスがサービスエージェントを使ってバケットにアクセスすることを許可します。 false : 許可しません。 参考 : Create a bucket with IP filtering rules - Bucket IP filtering configurations バケット作成時にフィルタリング設定 gcloud alpha storage buckets create gs:// [ BUCKET_NAME ] --ip-filter-file =[ IP_FILTER_CONFIG_FILE ] BUCKET_NAME には新規に作成するバケット名、 IP_FILTER_CONFIG_FILE にはIPフィルタリング設定用JSONのファイルパスを指定します。 参考 : IP フィルタリング ルールのあるバケットを作成する 既存バケットにフィルタリング設定 gcloud alpha storage buckets update gs:// [ BUCKET_NAME ] --ip-filter-file =[ IP_FILTER_CONFIG_FILE ] BUCKET_NAME には IP フィルタリングを設定するバケット名、 IP_FILTER_CONFIG_FILE にはIPフィルタリング設定用JSONのファイルパスを指定します。 参考 : 既存のバケットで IP フィルタリング ルールを作成または更新する フィルタリング ルールを取得 gcloud alpha storage buckets describe gs:// [ BUCKET_NAME ] --format =" default(ip_filter_config) " BUCKET_NAME には IP フィルタリングを取得するバケット名を指定します。 参考 : バケット IP フィルタリング ルールを取得する フィルタリング ルールを無効化 gcloud alpha storage buckets update gs:// [ BUCKET_NAME ] --clear-ip-filter BUCKET_NAME には IP フィルタリングを無効にするバケット名を指定します。 参考 : バケット IP フィルタリング ルールを無効にする IPフィルタリングのバイパス設定 概要 Cloud Storage の IP アドレスフィルタリングにおいて バイパス設定 を行うと、特定の IAM プリンシパル（ユーザー、サービスアカウントなど）は、 送信元 IP アドレスに関わらず 、バケットの作成、削除、構成に関する IP フィルタリング制限の対象から除外されます。 ユースケース ユースケース 説明 バケット ロックアウト IP フィルタリングの設定を誤って追加し、バケットにアクセスできなくなった場合 予期しない IP 変更 ネットワークの変更により IP アドレスが予期せず変更され、ロックアウトされた場合 設定方法 IAM 権限 storage.buckets.exemptFromIpFilter をプリンシパルに付与します。この権限はカスタムロールを使用して権限を付与します。 カスタムロールの作成 gcloud iam roles create ip_filter_bypasser \ --project =[ PROJECT_ID ] \ --title =" Custom IP Filter Bypasser " \ --description =" Cloud Storage IPフィルタリングをバイパスする " \ --permissions = storage.buckets.exemptFromIpFilter PROJECT_ID には、Google Cloud プロジェクト ID を指定します。 IAM ポリシーへのバインディング 作成したカスタムロールを対象のプリンシパル（この例ではユーザーアカウント）に付与します。 gcloud projects add-iam-policy-binding [ PROJECT_ID ] \ --member =" user:[USER_EMAIL] " \ --role =" projects/[PROJECT_ID]/roles/ip_filter_bypasser " PROJECT_ID には、Google Cloud プロジェクト ID、 USER_EMAIL には、カスタムロールを付与するユーザーのメールアドレスを指定します。 運用の注意点 storage.buckets.exemptFromIpFilter 権限は非常に強力です。この権限を持つプリンシパルの認証情報が漏洩した場合、IP フィルタリングによる保護が無効化されてしまいます。 使用にあたっては 最小権限の原則 を遵守し、本当に必要なプリンシパルにのみ、必要最小限の期間だけ付与するようにしてください。恒久的な権限としてではなく、 Privileged Access Manager（PAM） を使用して、期間限定で付与する運用が理想的です。 参考 : IP フィルタリング ルールをバイパスする 参考 : Privileged Access Manager（PAM）を解説！ 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

G-genの杉村です。当記事では、Google Workspace の便利なTipsを10個ご紹介します。これらの Tips を活用して、作業効率の向上に役立ててください。 Gemini サイドパネルを使う 進化した Gemini アプリを使いこなす ドキュメントは自動で版管理される ファイルが格納されている Google ドライブのフォルダへ瞬時に移動 「候補」でファイル移動を効率化 最短で共有リンクをコピー ドキュメントの任意の場所へのリンク Google ドキュメントにコードブロックを挿入 コネクテッドシートで BigQuery データを可視化 Looker Studio でリアルタイムにデータを可視化 Gemini サイドパネルを使う Google Workspace に統合された Gemini for Google Workspace の サイドパネル は、様々な業務をサポートする強力なアシスタントです。 Gemini サイドパネルを開くには、Google ドライブの操作画面や、Google ドキュメント、スプレッドシートなどの操作画面の右上にある 星型のマーク をクリックします。サイドパネルの下部分のテキストボックスに、Gemini への指示を入力します。 Gemini サイドパネルの開き方 例えば、Gmail で受信した英語の長文メールや、Google ドライブに保存された英語の契約書や利用規約の PDF（テキストデータとして認識可能な場合）の内容を把握したい場合、Gemini サイドパネルに「この内容を日本語で要約して」と指示するだけで、素早く概要を掴むことができます。 他にも、文章の作成支援、アイデアのブレインストーミング、情報検索など、多岐にわたるタスクをサイドパネルから直接実行できます。 英語の規約や契約書を日本語で要約 参考 : サイドパネルを使用して Gemini と共同作業を行う 進化した Gemini アプリを使いこなす スタンドアロンの Gemini アプリ （Web 版およびモバイルアプリ版）も非常に強力です。特に、最新モデルである Gemini 2.5 Pro や Gemini 2.5 Flash の登場により、日本語の処理能力が大幅に向上しました。 Google Workspace ユーザーであれば、誰でも Gemini アプリを利用できます（管理者によって禁止されている場合を除く）。 https://gemini.google.com にアクセスしてください。 Gemini アプリは以下のようなタスクで活用できます。 タスク 概要 文章作成 メール、ブログ記事、レポートなどの下書き作成 データ整備 表記揺れのあるデータの整備や突合（名寄せ、顧客リストのクレンジングなど） コーディング支援 コード生成、デバッグ、解説 文章レビュー 作成した文章が特定の基準（丁寧な言葉遣い、社内レビュー基準など）を満たしているかの確認 Google Workspace との連携 Google ドキュメントやスライドを読み込ませ、作業をさせる Gems（カスタム指示）の活用 特定の役割やタスクに特化した指示を保存し、再利用 Deep Research 複雑なトピックに関する情報を複数のソースから収集・分析し、詳細なレポートを生成 Canvas 作成させた文章を校正しながら再生成を繰り返す。文章作成やコーディングに便利。HTML/CSS/JavaScript のプレビューも可能 スケジュール実行 メールの要約、To Do リストのまとめなど定期的なアクションを実行してユーザーに通知する 日常的な情報収集から専門的な作業まで、Gemini アプリは幅広いシーンで生産性向上に貢献します。 参考 : Gemini アプリ ヘルプ Gemini による翻訳 スピーカーノートを Gemini アプリに生成させる Gemini アプリでウェブアプリを開発（Canvas 機能） また、Gemini アプリで使える Gems も強力です。あらかじめ「カスタム指示」として、Gemini の振る舞いや出力フォーマットを指示するプロンプトを登録して再利用できるので、繰り返し行う指示がある場合に、何度もプロンプトを入力する必要がなくなります。 blog.g-gen.co.jp Gems の編集画面 ドキュメントは自動で版管理される Google ドキュメント、スプレッドシート、スライドなどのドキュメントは、 自動で版管理 されます。 メニューから「ファイル > 変更履歴 > 変更履歴を表示」を選択することで、いつ・誰が・どの部分を変更したか、履歴を確認できます。過去の版から情報をコピー＆ペーストしたり、ある版にファイルを巻き戻すこともできます。 これを使えば、ファイルを複製して過去の版を残しておく必要がありません。ファイル名に日付を付ける必要もありません。以下のようなファイルサーバーの状態とは無縁になります。 XXプロジェクト_説明資料.pptx XXプロジェクト_説明資料（最新）.pptx XXプロジェクト_説明資料_20220602.pptx XXプロジェクト_説明資料_old.pptx XXプロジェクト_説明資料_old2.pptx 過去の履歴を確認 いつ、誰が、どのように変更したかがハイライト表示 参考 : ファイルの変更内容を確認する ファイルが格納されている Google ドライブのフォルダへ瞬時に移動 Google ドキュメントやスプレッドシート、スライドなどのファイル（以下、Google ドライブファイル）を開いているとき、「このファイルはどのフォルダに保存したかな？」と探した経験はないでしょうか。 画面左上のファイル名の右側にある フォルダアイコン をクリックして開くポップアップウインドウから、そのファイルが格納されているGoogle ドライブのフォルダへ簡単に移動できます。 ファイルが格納されているフォルダを開く方法 なお、Google ドライブの設計思想として、フォルダ構造を作ったディレクトリ型のファイル整理ではなく、検索によりファイルを見つけ出すことに重きが置かれています。Google ドライブの検索機能は非常に優れており、あいまいなキーワードでも検索にヒットします。しかし、フォルダ構成を正しく整理しておくことは、依然としてスムーズなコラボレーションのために重要です。 「候補」でファイル移動を効率化 Google ドライブでファイルを別のフォルダに移動する際、移動先のフォルダを探す手間を省く方法があります。 ファイルを移動しようとすると、「候補」として最近アクセスしたフォルダや、ファイルの内容に関連性の高いフォルダが表示されます。そのため、 あらかじめ移動先のフォルダを一度開いておく と、そのフォルダが「候補」の上位に表示されやすくなり、スムーズにファイルを移動できます。 ファイルを意図したフォルダに素早く移動 最短で共有リンクをコピー Google ドライブファイルの共有リンクを取得する際、画面右上の「共有」ボタンをクリックしてから「リンクをコピー」を選択するのが一般的です。 しかし、もっと手早くリンクをコピーする方法があります。「共有」ボタンの すぐ右にある下向きの三角アイコン をクリックし、表示されたメニューから「 リンクをコピー 」を選択します。これにより、ステップ数を減らして迅速に共有リンクを取得できます。 2回のクリックで共有リンクをコピー ドキュメントの任意の場所へのリンク Google ドキュメント 長文の Google ドキュメントや議事録を作成する際、構造を分かりやすくするために目次は不可欠です。 Google ドキュメントでは、テキストのスタイルを「見出し1」「見出し2」などに設定するだけで、画面左側に自動的に アウトライン （目次）が表示されます。このアウトラインをクリックすることで、ドキュメント内の該当箇所にすぐにジャンプできます。 アウトラインが表示されていない場合は、画面左上の目次アイコンをクリックするか、「表示」メニューから「タブと概要のサイドバーを開く」を選択してください。 設定した見出しに応じて、目次が表示される これは、定例会議など繰り返される会議の議事メモなどにも便利です。毎回、 議事メモを同じファイルに追記 していき、日付を見出しに設定しておけば、任意の日付の議事メモに瞬時にジャンプできます。 なお、テキストのスタイルを「見出し1」「見出し2」などに設定するショートカットも便利です。例えば、「見出し1」を設定する一般的なショートカットは Ctrl + Alt + 1 （Windows、Chromebook）または Command + Option + 1 （Mac）です。「見出し2」であれば、最後の数字を2に変えることで適用できます。これらのショートカットを指が覚えるまで意識的に使用することで、ドキュメントの構成を整える作業がスムーズになり、コンテンツ作成に集中できます。 参考 : ドキュメントにタイトル、見出し、概要を追加する また、この見出しをクリックしてジャンプした状態で ブラウザの URL 欄に表示される URL は、その見出しへの 直接のリンク となります。ドキュメントを人に共有する際は、このリンクを使用することができます。Google ドキュメントに複数タブを作っている場合、開いたタブの URL も同様に、そのタブへの直接のリンクとなります。この挙動は、 Google スプレッドシートや Google スライドなどでも同様 です。 ブックマーク 見出しを作らずにドキュメントの任意の場所にリンクを貼りたい場合、ブックマーク機能も便利です。メニュー「挿入」>「ブックマーク」をクリックすると、任意の場所にブックマークを挿入することができます。このブックマークから得られるリンクにアクセスすると、始めからその場所にスクロール済みの状態でウインドウが開きます。 ブックマークを挿入 ブックマークからリンク取得 Google スライド Google スライドでも、任意のスライドを開いた状態で、ブラウザの URL 欄から得られるリンクを他人に共有すれば、はじめからそのスライドが開いた状態でウインドウが開きます。 特定スライドへのリンク Google スプレッドシート スプレッドシートでは、特定のセルを右クリックして表示されるプルダウンメニューから「セルでの他の操作項目を表示」>「このセルへのリンクを取得」を選択することで、特定セルへのリンクが取得できます。このリンクを開くと、特定セルにカーソルがあった状態でウインドウが開きます。 このセルへのリンクを取得 Google ドキュメントにコードブロックを挿入 技術的なドキュメントを作成する際、ソースコードを色分けして表示したいケースがあります。Google ドキュメントでは、簡単に コードブロック を挿入できます。 コードブロックを挿入するには、以下の手順で行います。 「挿入」メニューを開きます。 「ビルディング ブロック」にカーソルを合わせます。 「コードブロック」を選択します。 表示されたコードブロック内にコードを記述または貼り付けて、言語を選択します。 ソースコードなどをハイライト表示 コネクテッドシートで BigQuery データを可視化 コネクテッドシート は、Google スプレッドシートから直接 BigQuery のデータにアクセスし、分析や操作を行える機能です。 BigQuery のデータを Excel で扱うには、一度 CSV などでエクスポートしてからシートにインポートする手間があります。しかしコネクテッドシートを利用すれば、Google スプレッドシート上で数万行といった大規模なデータセットを直接参照し、ピボットテーブルやグラフ作成、関数を利用した計算などが可能です。 データアナリストやマーケターなど、大量のデータを扱うユーザーにとって、データ活用のハードルを大きく下げる機能です。 参考 : コネクテッド シートを使用して BigQuery のデータを分析、可視化する 参考 : Google スプレッドシートで BigQuery のデータを使用する 以下の記事では、コネクテッドシートを駆使して、ブログサイトのアクセス数分析を行っている G-gen の事例を紹介しています。 blog.g-gen.co.jp Looker Studio でリアルタイムにデータを可視化 Looker Studio は、様々なデータソースに接続し、インタラクティブなダッシュボードやレポートを無料で作成できるビジネスインテリジェンスツールです。 Google アナリティクス、Google 広告、BigQuery、Google スプレッドシートなど、多くのGoogleサービスはもちろん、外部のデータベースやCSVファイルなど、多様なデータソースに対応しています。 ドラッグ＆ドロップの簡単な操作でグラフや表を作成でき、リアルタイムでデータが更新されるダッシュボードを関係者と容易に共有できます。コネクテッドシートで BigQuery のデータをスプレッドシートに取り込み、それを Looker Studio で可視化するといった連携も強力です。 参考 : Looker Studio の概要 参考 : Looker Studio ヘルプセンター Looker Studio レポート（Google が公開するサンプル） 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の中川です。Google Workspace の管理者向け機能である メールログ検索 について、基本的な使い方からトラブルシューティングでの活用方法までを解説します。 メールログ検索とは 保持期間 使用方法 メールログ検索でできること 配信状況と配信後の状態の確認 メッセージ ID での正確な追跡 適用されたルールの特定 トラブルシューティングでの利用 ケース1 : ログに記録が存在しない ケース2 : 外部への送信が拒否された メールログ検索とは メールログ検索 （Email Log Search、ELS）は、Google Workspace の管理者が、組織で送受信されるメールの配信状況を追跡・監査するためのツールです。Google のサーバーを通過した全てのメールについて、「いつ」「誰から誰に」「正常に配信されたか」「どのようなルールが適用されたか」といった詳細な記録を確認できます。 ユーザーから「メールが届かない」「送ったメールが相手に届いていないようだ」といった問い合わせがあった際に、このメールログ検索を用いると、管理者は客観的なデータに基づいた迅速な原因調査ができます。 参考 : メールログ検索を使用してメールを検索する 保持期間 メールログ検索のデータ保持期間は 30 日間です。30 日を超えてデータを保持したい場合は、定期的にエクスポートし、Google スプレッドシートや CSV ファイルとして保存する必要があります。 参考 : データの保持期間とタイムラグ 参考 : メールログ検索の結果を理解する - ELS の結果を書き出す 使用方法 メールログ検索は、Google Workspace の管理コンソールから使用します。 左側のメニューから [レポート] > [メールログ検索] を選択します。 検索画面では、定義済み検索とカスタム検索の2つの方法が利用できます。 定義済み検索では、「今日のすべてのメール」など、あらかじめ用意された条件で簡単に検索できます。 カスタム検索では、期間を指定し、送信者や受信者のメールアドレス、件名、送信元 IP アドレスなど、より詳細な条件で絞り込むことができます。 「今日のすべてのメール」の検索結果 参考 : メールログ検索を使用してメールを検索する メールログ検索でできること 配信状況と配信後の状態の確認 検索結果から特定のメールを選択すると、そのメールのステータスや詳細な処理内容を確認できます。「配信済み」となっていてもユーザーがメールを見つけられない場合、配信後のメッセージの詳細を確認するのが有効です。 検索結果で対象のメールを選択し、「受信者の詳細」セクションを開くと配信ステップを確認できます。 「配信後のメッセージの詳細」では以下のような詳細な内容を確認できます。 受信トレイ、迷惑メール、ゴミ箱など、メールが現在どのフォルダにあるか どのラベルが付与されたか 既読か未読かなど 参考 : メールログ検索の結果を理解する 参考 : メールログ検索の配信ステータスの定義 メッセージ ID での正確な追跡 確実に特定のメールを調査したい場合は、 メッセージ ID を使った検索が最も効果的です。メッセージ ID は、メール1通1通に割り当てられる世界的に一意の識別子で、メールのヘッダー情報に含まれています。 ユーザーから調査依頼を受ける際に、対象メールのヘッダー情報（ Message-ID フィールド）を提供してもらうことで、他の類似メールと混同することなく、目的のログをピンポイントで特定できます。 逆に、ユーザーから「メールが見つからない」という問い合わせを受けた際には、管理者がメールログ検索でメッセージ ID を取得し、ユーザーに提供することも有効です。 ユーザーは取得したメッセージ ID を Gmail の検索ボックスで rfc822msgid:<メッセージID> という形式の検索演算子を使うことで、目的のメールを正確に見つけ出せます。 参考 : メールログ検索を使用してメールを検索する 参考 : Gmail で検索を絞り込む 適用されたルールの特定 メールが意図せず迷惑メールに分類されたり、特定のユーザーに転送されたりした場合、どの設定が影響したのかを特定する必要があります。 メールログの詳細画面では、そのメールに適用されたGmailのポリシーやルーティング設定が一覧で表示されます。例えば、「コンテンツコンプライアンス」や「ルーティング」といった管理者が設定したルールがどのように評価・適用されたかを確認でき、設定不備の発見に役立ちます。 トラブルシューティングでの利用 ケース1 : ログに記録が存在しない ユーザーから「メールが届かない」と申告があり、メールログ検索で検索しても該当するログが一切見つからないことがあります。 これは、そのメールが Google のメールサーバーに到達していないことを意味します。つまり、問題の原因は Google Workspace 側ではなく、その手前の送信者側の環境にある可能性が極めて高いです。この場合、調査すべきは送信者側のメールサーバーの設定や送信ログです。 ケース2 : 外部への送信が拒否された メールログに「受信者ドメインのサーバーによって拒否されました」と記録された場合、相手方のサーバーが受信を拒否したことを示します。 原因は、相手側の IP アドレスブロックや迷惑メールフィルタ設定などが考えられます。また、自社の送信ドメイン認証（ SPF 、 DKIM 、 DMARC ）の不備が原因で「なりすましメール」と判定されている可能性もあります。 まずは自社の SPF・DKIM・DMARC 設定を Google が提供する Google Admin Toolbox などのツールを使って確認し、問題がない場合、ログ情報を添えて相手先のシステム管理者に調査を依頼するのが有効です。 参考 : Google Admin Toolbox (Check MX) 参考 : メールログ検索を使用したメール配信に関する問題のトラブルシューティング 送信ドメイン認証については、以下の記事もご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 中川 涼介 (記事一覧) クラウドソリューション部 クラウドサポート課 2024年11月、G-genに入社。Google Cloudを日々勉強中。 最近は怪談の動画にハマってます。

G-genの福井です。Cloud Monitoring の SLO モニタリングの設定手順を紹介します。 はじめに SLO 設定の前提 Service の作成 SLO の作成 可用性 SLO の設定 レイテンシ SLO の設定 エラーバジェットのアラート設定 アラート設定の必要性 エラーバジェットのアラートの種類 アラートポリシーの作成手順 ダッシュボードの確認 はじめに 本記事では、Google Cloud の Cloud Monitoring を利用し、サービスの品質を定量的に管理するための SLO モニタリングを設定する手順を解説します。 サービス運用では、「システムの現在の状態は健全か」「ユーザーに快適な体験を提供できているか」という問いに、データに基づいて客観的に答えることが求められます。Google が提唱する SRE （Site Reliability Engineering）のプラクティスでは、これらの問いに答える判断基準として SLO （Service Level Objective）を用います。 SLO モニタリングは、「感覚的な運用」から脱却し、観測した数値に基づいてサービス品質の管理や改善活動の意思決定を行うための仕組みです。 具体的な設定手順に入る前に、SLO を理解する上で不可欠な3つの基本用語を解説します。 用語 概要 具体例 SLI（Service Level Indicator） サービスの健康状態を定量的に測る指標。良いサービスを定義する「物差し」の役割を果たす ・可用性（リクエストの成功率） ・レイテンシ（リクエストの応答時間） SLO（Service Level Objective） SLI で計測した値が達成すべき具体的な目標値。この目標の遵守状況が、サービスの信頼性を判断する基準となる ・月間の可用性が 99.9% であること ・リクエストの 95% が 500ms 以内に応答されること エラーバジェット（Error Budget） SLOで定めた目標を100%から引いた残り、つまり「使い切っても良いエラーの許容量」です。この予算内で新機能のリリースを行い、枯渇しそうなら品質改善に注力するなど、開発速度と信頼性のバランスを取るために利用される ・SLO が 99.9% の場合、0.1% がエラーバジェットになる ・この 0.1% の範囲内での品質低下は許容される SLO 設定の前提 今回の手順解説では、Google Cloud 上で稼働する、ごく一般的な Web アプリケーションを例に、設定手順を解説します。 今回の構成と利用するサービスは以下の通りです。 項目 内容 モニタリング対象サービス Cloud Run で稼働する Web アプリケーション アクセス経路 Cloud Run のサービス URL をインターネットに公開 モニタリングツール Cloud Monitoring SLO を設定する上での最も重要な前提条件は、 対象のサービスがすでに稼働しており、Cloud Monitoring 上で指標（メトリクス）が収集されていること です。 SLI / SLO は既存のメトリクスに基づいて定義されるため、まだデプロイされていないサービスや、全くトラフィックがないサービスに対して設定することはできません。本記事でも、すでに Cloud Run にアプリケーションがデプロイされ、サービス URL を通じてトラフィックが発生している状態から手順を開始します。 Service の作成 SLO モニタリングを開始するには、まずモニタリング対象となる「Service」を Cloud Monitoring に登録します。 ここでの「Service」とは、Cloud Run や GKE、特定の VM 群といった、アプリケーションやマイクロサービスの論理的な単位を指します。 Google Cloud コンソールの Cloud Monitoring 画面で、[検出] > [SLO] > [サービスを定義] を選択します。 サービスを定義を選択 モニタリング対象のサービスを一覧から選択し、[送信]を選択します。 サービスを定義 参考: サービスを定義する SLO の作成 作成した Service の信頼性を評価するための具体的な目標、SLO（Service Level Objective）を設定します。 今回は、代表的な SLO として「可用性」と「レイテンシ」の2種類を設定する手順を解説します。 可用性 SLO の設定 可用性は、サービスがリクエストに対して正常に応答しているかどうかを示す指標であり、最も基本的な SLO の一つです。ここでは「リクエスト総数のうち、正常なリクエストが占める割合」を目標として設定します。 Google Cloud コンソールの Cloud Monitoring 画面で、[検出] > [SLO] > 作成した Service を選択します。 作成したサービスを選択 [+ SLO を作成] を選択します。 SLO を作成を選択 SLI の設定 指標の選択に 可用性 、リクエスト ベースまたはウインドウ ベースの選択に リクエスト ベース を選択し、[続行] を選択します。 SLI の設定 [続行] を選択します。 SLI の詳細を定義する SLO の設定 直近30日間において、リクエストの99.9%が5xxエラー以外で応答されること を目標として定義するため、以下のように設定します。 期間の種類である「連続」は、現在から過去に遡った一定期間を評価対象とするため、継続的なサービスレベルの評価に適しています。設定後、[続行] を選択します。 項目 選択値 期間の種類 連続 期間の長さ 30 目標 99.9 SLO の設定 [SLO を作成] を選択します。 SLO を作成 参考: SLO の作成 レイテンシ SLO の設定 ユーザーの体感品質に直結するもう一つの重要な指標、レイテンシ（応答時間）に関する SLO を設定します。 ここでは「全リクエストのうち、一定時間内に応答が完了したリクエストの割合」を目標として定義します。 手順は可用性 SLO の設定とほぼ同じです。Service ダッシュボードの [+ SLO を作成] ボタンから開始します。 SLI の設定 指標の選択に レイテンシ 、リクエスト ベースまたはウインドウ ベースの選択に リクエスト ベース を選択し、[続行] を選択します。 SLI の設定 正常と判断する応答時間の上限値を設定します。 レイテンシのしきい値に 500 を入力し、[続行] を選択します。 SLI の詳細を定義する SLO の設定 直近30日間において、リクエストの95%が500ms以内に応答されること を目標として定義するため、以下を選択し、[続行] を選択します。 項目 選択値 期間の種類 連続 期間の長さ 30 目標 95 SLO の設定 [SLO を作成] を選択します。 SLO を作成 エラーバジェットのアラート設定 アラート設定の必要性 SLO を設定しただけでは、サービス品質の低下が自動的に通知されるわけではありません。そのため、エラーバジェットが危険な水準まで消費される前に通知を受け取る仕組みとして、アラートの設定は不可欠です。 Cloud Monitoring の SLO モニタリングでは、 エラーバジェットの消費速度（バーンレート） に基づいてアラートを発行することが推奨されています。 バーンレートとは、エラーバジェットを消費していくペースを指します。例えば、「この1時間のエラー発生ペースが続くと、SLO期間（30日間）で許容されるエラーバジェットを10日で使い切ってしまう」といった状況を検知するのがバーンレートアラートです。これにより、一時的なエラーの急増に過剰反応することなく、持続的かつ重大な品質低下を早期に警告できます。 エラーバジェットのアラートの種類 バーンレートに基づくアラートは、その緊急性に応じて、一般的に「高速バーン」と「低速バーン」の2種類を設定することが推奨されます。 アラートの種類 目的 推奨される設定（目安） 高速バーン 重大なレート変化の即時検知 サービスの致命的な障害など、エラーバジェットを急激に消費する事態を直ちに検知します。 ・バーンレートしきい値： 10 （30日間のSLO期間の場合、3日でバジェットを消費するペース） ・ルックバック期間： 1時間 ・用途：緊急対応（夜間・休日呼び出しなど） 低速バーン 長期的な品質低下の検知 緊急ではないが、このままでは期間終了までに目標を達成できない、緩やかな品質低下を検知します。 ・バーンレートしきい値： 2 （30日間のSLO期間の場合、15日でバジェットを消費するペース） ・ルックバック期間： 24時間 ・用途：計画的な日中対応（チケット発行など） このように複数のアラートを組み合わせることで、様々なパターンの品質低下に対応できます。 参考: エラー バジェットのアラートの種類 アラートポリシーの作成手順 アラートを設定したい SLO の行にある [アラートの起動アイコン] を選択します。 SLO アラートを作成を選択 ルックバック期間に 60 、バーンレートのしきい値に 10 を入力し、[次へ]を選択します。 SLO のアラート条件の設定 通知チャンネルの作成から行う場合は、通知チャンネルを選択し、[Manage Notification Channels] を選択します。 Manage Notification Channels を選択 Email 行の [Add New] を選択します。 Email Add New を選択 Email Address に 通知先のメールアドレス 、Display Name に 通知チャンネルの表示名 を入力し、[Save] を選択します。 通知チャンネルを作成 通知チャンネルに 作成した通知チャンネル を選択し、[次へ] を選択します。 通知チャンネルの選択 [Save] を選択します。 SLO のバーンレートに関するアラート ポリシーの作成 参考: アラート ポリシーの作成 ダッシュボードの確認 Service の定義、SLO の設定、アラートポリシーの作成が完了すると、SLO モニタリングの運用フェーズに入ります。その中心となるのが、各 Service ごとに自動で生成される専用のダッシュボードです。 このダッシュボードには、サービスの信頼性に関する様々な情報が集約されており、日々の健全性確認や問題発生時の状況把握に役立ちます。 今回は、アクセスすると 5xx エラー となる Cloud Run サービスに対して、SLO モニタリングの設定を追加しています。 モニタリングの設定を行った後、Cloud Run サービスに複数回アクセスした状態のダッシュボードです。 SLO ダッシュボード SLO アラートの設定で通知されたメールです。 SLO アラートで通知されたメール 参考: サービス ダッシュボードの使用 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

全国の G-gen ファンのみなさま、はじめまして。Cisco Systems のセキュリティ SE の稲澤です。今回、G-gen の Google Workspace 検証環境を使い、当社の Cisco Duo との連携テストを行う機会を得たため、内容を記事にまとめました。 当記事は、Cisco Systems と G-gen の共同企画で執筆されました。 はじめに Cisco Duo とは Duo と Google Workspace の連携 検証1. Google Directory-Sync 検証2. Duo Directory ＆ 完全なパスワードレス認証 検証3. Duo Outbound SCIM Cisco Duo と Google の連携強化 はじめに Cisco Duo とは Cisco Duo は、多要素認証、ユーザの信頼性評価、デバイス信頼性評価により、あらゆるアプリケーションへの安全なアクセスをシームレスに、かつ最小の認証回数で実現するアイデンティティセキュリティソリューションです。 参考 : ユーザにセキュアなアクセスを提供 | Duo Security Duo を MFA 用ソリューションと捉えている方も多いかもしれません。しかし近年では、多様な IdP や HR システムと連携して ID の振る舞いを監視し、ID に関連したリスクの可視化と脅威の検出、およびそれら対応が可能な ITDR （Identity Threat Detection and Response）機能が実装されたり、2025年6月5日には Cisco Duo IAM が新たに発表され、Duo をプライマリの認証ソースとしてセキュアな ID 管理・アクセス管理を実現する、セキュリティファーストな IAM ソリューションに進化しています。 参考 : シスコ、アイデンティティ セキュリティを再定義する「Duo IAM」を発表 Cisco Duo Duo と Google Workspace の連携 近年、主な認証基盤として Google Workspace を使ったり、あるいは他の IdP と併用して利用するユースケースが増えています。 2025年6月5日に発表された Cisco Duo の新機能の中で、Google Workspace との連携が強化されたため、Cisco Systems と G-gen で協力して動作検証を行いました。 検証1. Google Directory-Sync Google Directory-Sync は、Google Workspace から Cisco Duo に対して、ユーザ、グループ、その他属性情報を自動同期できる新機能です。 IdP でのプライマリ認証に成功すると、ユーザ ID 情報が Duo に送信されます。Duo 内にこのユーザ ID とマッチする ID が存在すれば、Duo からエンドユーザに対して MFA リクエストが行われます。そのため、Google Workspace から Duo へのユーザ同期は必須です。 今回の検証では、Google Workspace のディレクトリに存在する以下のグループとユーザを同期の対象としました。 グループ : gws-group1 ユーザ : gwsuser1@ina.g-gen-trial.com 、 gwsuser2@ina.g-gen-trial.com （いずれのユーザも gws-group1 に所属） 1. Add External Directory Duo ダッシュボードから External Directories に移動して Add External Directory から Google を選択します。 2. Add new connection Add new connectionにチェックをして、 Continue をクリックします。 3. 承諾 Google のログインページに移動するため、管理者権限でログインします。Duo Directory Sync がアクセスする情報・権限一覧が表示されるため、すべてをチェックして承諾をクリックします。 5. その他の設定 その他、必要に応じて設定（今回はデフォルトのまま）して Save をクリックし、設定を保存します。その後、 Sync Now ボタンをクリックして同期を開始します。 上記のように、簡単な設定で同期が完了しました。 検証2. Duo Directory ＆ 完全なパスワードレス認証 続いて、今回の目玉機能である Duo Directory の検証です。Duo Directory は、Duo が保持するユーザ ID にパスワードを付与し、Duo をプライマリ認証ソースとして利用することができる機能です。 検証 1. で Google Workspace から取得した ID を Duo でパスワードレス化して、Google Workspace にログイン可能かを検証します。ポイントは、認証ソースを Google ではなく Duo としている点です。Google へのログインであれば、認証ソースはそのまま Google で良いのではないかと考える方もいるかもしれませんが、Google Workspace を SP とし、かつ IdP も Duo により Google Workspace と SAML 連携してしまうと認証ループが発生してしまい、認証が成功しません。 これを回避するために Google Workspace アプリへのログオンのみ、Duo Directory を使って Duo でプライマリ認証とセカンダリ認証（MFA）を実施させます。 1. Enrollment Policy の作成 エンドユーザに、Duo での MFA デバイス登録の際にパスワードをセットさせるよう、 Enrollment Policy を作成します。はじめに、MFA の認証方式を設定します。ここではパスキー認証のみ許可し、パスワードレス認証を行わせるようにします。次に、Duo でのパスワード作成要求にチェックを入れます。 2. Enrollment Policy を使うグループの設定 作成した Enrollment Policy を使用するグループを指定します。ここでは、検証 1. で Google Workspace から同期した gws-group1 をセットします。 3. プライマリ認証ソースの設定 続いて、プライマリ認証ソースを Duo に設定します。Duo には SSO Routing Rules という機能があり、ドメインや宛先アプリケーションなどを条件として複数の IdP 認証ソースに振り分けが可能です。今回はデフォルトの認証ソースとして Duo をセットします。 4. MFA デバイス登録 次に、エンドユーザの MFA デバイス登録を実施します。ユーザ gwsuser1@ina.g-gen-trial.com をクリックして、 Generate an enrollment code をクリックし、テンポラリの登録コードを生成してテキストに保存します。 5. Enrollポータルの操作 Enrollポータルにアクセスします。 Get started をクリックすると、ユーザのデバイス登録が始まります。まず該当のユーザ ID と、先ほどコピーしたコードを入力します。続いてパスワードを作成し（パスワードレス認証となるため、ここで設定したパスワードは実際のアクセスには利用されません）、デバイスの追加で Windows Hello の登録を行います。これで、ユーザの事前のセットアップは完了です。 6. SP 設定 最後に、Google Workspace を SP として Duo と連携させます。この手順は少し長いため、ここでは省略します。以下の公式ガイドの通り設定してください。 参考 : Duo Single Sign-On for Google Workspace (Google G Suite) | Duo Security 7. 動作確認 実際に Google Workspace にログインしてみます。以下の図の通りパスワード不要で、シームレスに Google Workspace にログインすることができました。 検証3. Duo Outbound SCIM 新機能 Duo Outbound SCIM により、Duo が保有するユーザ、グループ、その他属性情報を、他のアプリケーションに SCIM 経由で渡す（プロビジョニングする）ことができるようになりました。 今回は、検証 1. で Google Workspace から Duo に取り込んだユーザ・グループ情報を、Cisco の SSE（Security Service Edge）ソリューションである Secure Access にプロビジョニングする検証を行いました。 1. トークンの取得 まずは Secure Access で Directories の設定を行い、連携に必要なトークンおよび URL 情報を取得します。 2. 認証関連設定 続いて Duo ダッシュボードにログインして、Applications から Generic SAML Service Provider -Single Sign-On を選択して Provisioning タブから、以下のように認証設定、属性マッピング設定、同期するグループを指定します。 なお現在は Seure Access アプリケーションが Duo に組み込まれており、Generic SAMLではなく、Secure Access アプリケーションを利用して設定することもできます。 設定後にすぐに同期が開始され、Secure Access 上に Duo から取得したユーザ、グループ情報がプロビジョニングされていることが確認できました。今回は当社の製品で試しましたが、もちろん Amazon Web Services（AWS）や Microsoft 365、Zoom、SAP、Workday など、様々なアプリケーションに対して簡単にプロビジョニングを設定できます。 Cisco Duo と Google の連携強化 Cisco Duo では、Google との連携機能が強化され、Google Workspace をご利用中のお客様にとってこれまで以上に使いやすくなりました。 Google 単体との連携はもちろんのこと、複数の IdP 環境を持つ複雑なユースケース（企業の統合・合併、離脱など）においても、Duo をハブとして、Duo で統一したセキュリティポリシーを適用することができます。また、定期メンテナンスや新規プロジェクト用途（社員用の IdP との分離）などでも、Duo Directory を利用できます。「かゆいところに手が届く」柔軟さが Duo 特長です。 上記のような課題がある場合、今すぐ Cisco Duo の 無料トライアル を検討してください。 signup.duo.com 稲澤　敏 シスコシステムズ合同会社 セキュリティ事業　Solutions Engineer -Cybersecurity セキュリティ製品全般のプリセールス活動に従事し、セキュリティアーキテクトの立場から、パートナー、お客様への技術的な支援を行っている。

G-gen の堂原です。本記事では、 Vertex AI SDK と Google Gen AI SDK のコードを比較しながら、 Gemini の基本的な機能を Google Gen AI SDK で呼び出す方法を紹介します。 はじめに セットアップ Vertex AI SDK Google Gen AI SDK テキスト生成 Vertex AI SDK Google Gen AI SDK チャット形式 Vertex AI SDK Google Gen AI SDK マルチモーダル Vertex AI SDK Google Gen AI SDK グラウンディング Vertex AI SDK Google Gen AI SDK はじめに 2025年7月現在、Vertex AI の生成 AI を利用するための SDK として、 Vertex AI SDK と Google Gen AI SDK が存在しています。 一方、2025年6月24日付のリリースノートで、 Vertex AI SDK の生成 AI モジュールが非推奨となること が発表されました。 また、 2026年6月24日に本モジュールは利用できなくなります 。 これに伴い、Vertex AI SDK から Google Gen AI SDK への移行が必要となります。 参考 : Vertex AI release notes  |  Google Cloud 参考 : Vertex AI SDK migration guide  |  Generative AI on Vertex AI  |  Google Cloud セットアップ Vertex AI SDK Vertex AI SDK では、google-cloud-aiplatform ライブラリをインストールし、 vertexai.init() で初期化を行います。その後、 generative_models.GenerativeModel() で利用するモデルの設定をします。 ※ 本記事では、サンプルコードは Google Cloud の Colab Enterprise 上で動作を確認しています。 # ライブラリのインストール !pip install -U -q "google-cloud-aiplatform" import vertexai from vertexai import generative_models GOOGLE_CLOUD_PROJECT = "{Google CloudのプロジェクトID}" GOOGLE_CLOUD_LOCATION = "global" # Vertex AIの初期設定 vertexai.init(project=GOOGLE_CLOUD_PROJECT, location=GOOGLE_CLOUD_LOCATION) # モデル設定 model = generative_models.GenerativeModel( "gemini-2.5-flash" , system_instruction=[ "お嬢様っぽく喋ってください" ] ) Google Gen AI SDK Google Gen AI SDK では、google-genai ライブラリをインストールし、 genai.Client() でクライアントを初期化します。 Google Gen AI SDK では、モデルやシステムインストラクションは、実際にリクエストを送信する際に指定します。 # ライブラリのインストール !pip install -U -q "google-genai" from google import genai from google.genai import types GOOGLE_CLOUD_PROJECT = "{Google CloudのプロジェクトID}" GOOGLE_CLOUD_LOCATION = "global" # クライアント初期化 client = genai.Client( vertexai= True , project=GOOGLE_CLOUD_PROJECT, location=GOOGLE_CLOUD_LOCATION ) Google Gen AI SDK は Gemini Developer API 経由で Gemini を利用することもできるため、クライアントの初期化の際に、Vertex AI を使うことを明記する必要があります。 また、環境変数を用いてクライアントを初期化することも可能です。 %env GOOGLE_GENAI_USE_VERTEXAI=true %env GOOGLE_CLOUD_PROJECT= "{Google CloudのプロジェクトID}" %env GOOGLE_CLOUD_LOCATION= "global" client = genai.Client() 環境変数が設定されていない、または引数が不足している場合は、以下のような ValueError が発生します。 ValueError: Missing key inputs argument! To use the Google AI API, provide (`api_key`) arguments. To use the Google Cloud API, provide (`vertexai`, `project` & `location`) arguments. また、Google Gen AI SDK は、デフォルトでプレビュー機能が利用可能なベータ版のエンドポイントを使用します。安定版のエンドポイントを明示的に使用したい場合は、クライアントの初期化時に http_options を指定します。 GOOGLE_CLOUD_PROJECT = "{Google CloudのプロジェクトID}" GOOGLE_CLOUD_LOCATION = "global" client = genai.Client( vertexai= True , project=GOOGLE_CLOUD_PROJECT, location=GOOGLE_CLOUD_LOCATION, http_options=types.HttpOptions(api_version= "v1" ) ) 参考 : Google Gen AI SDK documentation テキスト生成 Vertex AI SDK Vertex AI SDK では、 model.generate_content() メソッドを使用します。出力設定は generation_config で、セーフティフィルタの設定は safety_settings で指定します。 response = model.generate_content( contents= "日本で一番長い川はなんですか？" , generation_config=generative_models.GenerationConfig( temperature= 0 , max_output_tokens= 1024 ), safety_settings={ generative_models.HarmCategory.HARM_CATEGORY_HATE_SPEECH: generative_models.HarmBlockThreshold.BLOCK_ONLY_HIGH, generative_models.HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: generative_models.HarmBlockThreshold.BLOCK_ONLY_HIGH, generative_models.HarmCategory.HARM_CATEGORY_HARASSMENT: generative_models.HarmBlockThreshold.BLOCK_ONLY_HIGH, generative_models.HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: generative_models.HarmBlockThreshold.BLOCK_ONLY_HIGH } ) Google Gen AI SDK Google Gen AI SDK では、 client.models.generate_content() メソッドを使用します。モデルはここで指定します。また、システムインストラクション、出力設定、セーフティフィルタ設定などを、 config パラメータにまとめて types.GenerateContentConfig として渡します。 response = client.models.generate_content( model= "gemini-2.5-flash" , contents= "日本で一番長い川はなんですか？" , config=types.GenerateContentConfig( system_instruction= "お嬢様っぽく喋ってください" , temperature= 0 , max_output_tokens= 1024 , safety_settings=[ types.SafetySetting( category=types.HarmCategory.HARM_CATEGORY_HATE_SPEECH, threshold=types.HarmBlockThreshold.BLOCK_ONLY_HIGH ), types.SafetySetting( category=types.HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, threshold=types.HarmBlockThreshold.BLOCK_ONLY_HIGH ), types.SafetySetting( category=types.HarmCategory.HARM_CATEGORY_HARASSMENT, threshold=types.HarmBlockThreshold.BLOCK_ONLY_HIGH ), types.SafetySetting( category=types.HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, threshold=types.HarmBlockThreshold.BLOCK_ONLY_HIGH ) ] ) ) 参考 : Safety settings  |  Gemini API  |  Google AI for Developers チャット形式 Vertex AI SDK Gemini ではマルチターンでの会話を行うこともできます。 Vertex AI SDK では、 model.start_chat() でチャットセッションを開始し、 chat.send_message() で対話を進めます。また、会話履歴は chat.history で確認できます。 chat = model.start_chat() # 一回目の会話 chat.send_message( "しりとりをしましょう。まず私から、「りんご」" ).text """ 返答 > あら、しりとりでございますのね！ とても風流な遊びですわね。 > わたくしも喜んでご一緒させていただきますわ。 > > 「りんご」様の「ご」でございますもの…そうですね、わたくしからは**「ごちそう」**といたしましょう。 > > 「う」で終わりますわ。 > > さあ、次はあなた様の番でございますわよ？ どのようなお言葉が飛び出しますかしら。うふふ。 """ # 二回目の会話 chat.send_message( "「うなぎ」" ).text """ 返答 > あら、うなぎでございますのね！ 香ばしい良い香りがしてまいりそうでございますわね。 \n\n では、わたくしからは「ぎ」で始まります**「ぎんいろ」**といたしましょう。 \n\n 「ろ」でございますわね。 \n\n さあ、次はどんな素敵な言葉が紡がれるのでございますかしら。楽しみでございますわ。うふふ。 """ Google Gen AI SDK Google Gen AI SDK では、 client.chats.create() でチャットセッションを開始します。この際、モデルやシステムインストラクションを指定します。対話は chat.send_message() で行い、会話履歴は chat.get_history() メソッドで取得します。 chat = client.chats.create( model= "gemini-2.5-flash" , config=types.GenerateContentConfig( system_instruction= "お嬢様っぽく喋ってください" ) ) # 一回目の会話 chat.send_message( "しりとりをしましょう。まず私から、「りんご」" ).text """ 返答 > まあ、わたくしと遊んでくださるとは、光栄でございますわね！ \n 「りんご」でございますわね。承知いたしましたわ。 \n\n では、わたくしからは……そうですね。 \n 「**ごきげんよう**」でございますわ。 \n\n 『う』で終わりましたから、どうぞ、お続けになってくださいましね。おほほ！ """ # 二回目の会話 chat.send_message( "「うなぎ」" ).text """ 返答 > まあ、今度は「うなぎ」でいらっしゃいましたのね！ \u3000 お上手でございますわ！ \n\n では、わたくしからは……そうですね。 \n 「**ギター**」でございますわ。 \n\n 『た』で終わりましたから、どうぞ、お続けになってくださいましね。おほほ！ """ また、 client.chats.create() の history パラメータに会話履歴を渡すことで、特定の文脈を引き継いだ状態でチャットを開始できます。 # 事前の会話内容設定 history = [ types.UserContent( parts=[ types.Part(text= "しりとりをしましょう。まず私から、「りんご」" ) ] ), types.Content( parts=[ types.Part(text= "わたくしからは「ごきげんよう」でございますわ。" ) ], role= "model" ) ] chat = client.chats.create( model= "gemini-2.5-flash" , config=types.GenerateContentConfig( system_instruction= "お嬢様っぽく喋ってください" ), history=history ) chat.send_message( "「うなぎ」" ).text マルチモーダル Vertex AI SDK Vertex AI SDK では、Cloud Storage に存在するファイルを入力に含める場合、 generative_models.Part.from_uri() を使用します。 # Cloud Storageにあらかじめ格納した画像を指定 image_part = generative_models.Part.from_uri( "gs://test-bucket/test.png" , mime_type= "image/png" ) response = model.generate_content( contents=[ "何が写っていますか？" , image_part], generation_config=generative_models.GenerationConfig( temperature= 0 , max_output_tokens= 1024 ) ) Google Gen AI SDK Google Gen AI SDK では、Cloud Storage に存在するファイルを入力に含める場合、 types.Part.from_uri() を使用します。 response = client.models.generate_content( model= "gemini-2.5-flash" , contents=[ "何が写っていますか？" , types.Part.from_uri( # Cloud Storageにあらかじめ格納した画像を指定 file_uri= "gs://test-bucket/test.png" , mime_type= "image/png" ) ], config=types.GenerateContentConfig( system_instruction= "お嬢様っぽく喋ってください" , temperature= 0 , max_output_tokens= 1024 ) ) グラウンディング Vertex AI SDK Vertex AI SDK について、移行ガイドでは generative_models.Tool.from_google_search_retrieval を使用する方法が案内されていますが、Gemini 2.0 以降でこの方法はサポートされておらず、以下のようなエラーが発生します。 BadRequest: 400 POST https://aiplatform.googleapis.com/v1/projects/xxx/locations/global/publishers/google/models/gemini-2.0-flash:generateContent?%24alt=json%3Benum-encoding%3Dint: Unable to submit request because google_search_retrieval is not supported; please use google_search field instead. Learn more: https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/gemini Google Gen AI SDK Google Gen AI SDK では、 tools パラメータに types.Tool(google_search=types.GoogleSearch()) を指定することで Grounding を有効にできます。 response = client.models.generate_content( model= "gemini-2.5-flash" , contents= "今年の「海の日」は何日ですか？" , config=types.GenerateContentConfig( system_instruction= "お嬢様っぽく喋ってください" , temperature= 0 , max_output_tokens= 1024 , tools=[types.Tool(google_search=types.GoogleSearch())] ), ) 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-genの杉村です。BigQuery テーブルのデータをスキャンして、AI がテーブルのメタデータ（テーブルとカラムの説明）を自動生成する メタデータ自動生成 機能を解説します。 はじめに メタデータの自動生成 テーブルのメタデータとは 仕様 分析情報からのメタデータ自動生成 料金 制限事項 手順 データ分析情報の生成 生成された説明を確認 テーブルへの保存 結果 日本語での生成 はじめに メタデータの自動生成 BigQuery には、テーブルのデータをスキャンして、AI がテーブルのメタデータ（テーブルとカラムの説明）を自動生成する メタデータ自動生成 機能があります。 この機能を用いることで、テーブルやカラムに人間が1つ1つ手作業でメタデータを付記する労力が改善されます。 なお2025年11月現在、当機能では追加の手順を行うことにより、日本語でのメタデータ生成が可能です。また2025年11月現在、当機能は API 経由での生成には対応していません。複数のテーブルに対して、API リクエストや SDK 経由で生成を実行する機能改善が期待されます。 参考 : Generate data insights in BigQuery - Generate table and column descriptions テーブルのメタデータとは データ分析基盤において、 メタデータ は非常に重要です。メタデータは可視化や分析のために必要なデータを人間が検索するために必要なほか、AI エージェントが自律的にデータを探し出したり、解釈するためにも利用されます。 メタデータが無いと、データが必要になったときに、過去の設計書を掘り起こしたり、システムの担当者に聞いて回ったり、あるいは Google Cloud の管理コンソールでプロジェクトを1つ1つ開き、BigQuery のテーブルや Cloud Storage のファイルをしらみつぶしに探したりといった、非常に手間のかかる作業が発生します。 BigQuery においては、テーブルやそのテーブルが持つ各カラム（列）に 説明 （Description）を追記することが可能です。この説明は ビジネスメタデータ として機能し、組織のメンバーが必要なデータを見つけ出すために役立ちます。BigQuery テーブルやカラムの説明は、 Dataplex Universal Catalog （旧称 Dataplex Catalog）に自動的に登録され、 データカタログ として利用することができます。 Dataplex Universal Catalog（旧称 Dataplex Catalog）については、以下の記事も参照してください。 blog.g-gen.co.jp 仕様 分析情報からのメタデータ自動生成 BigQuery のメタデータ自動生成は、 データ分析情報 （Data insights）機能の一部です。データ分析情報は Gemini in BigQuery の一部であり、生成 AI モデル Gemini を使ってテーブルの分析情報を得るための SQL クエリなどを生成する機能です。 プロジェクトで Dataplex API、BigQuery API、Gemini for Google Cloud API を有効化して、テーブルに対して分析情報の生成を指示するだけで、生成を行うことができます。 参考 : BigQuery でデータ分析情報を生成する 生成された分析クエリ このデータ分析情報の生成を指示すると、 メタデータ（説明）の自動生成 も同時に行われます。生成された説明は、テーブルに適用する前に目視で確認し、修正してから適用することができます。 生成された説明（Description） 料金 メタデータの自動生成は Gemini in BigQuery の一部であることから、Gemini in BigQuery の料金体系が適用されます。 2025年11月現在、メタデータの自動生成は 無料 で利用することができます。ただし、BigQuery Standard Edition を使っている場合は利用できません。デフォルト設定であるオンデマンド課金モードでは、利用可能です。 参考 : Gemini for Google Cloud pricing - Gemini in BigQuery Pricing Overview ただし、メタデータの生成を始めとする Gemini in BigQuery の利用回数には、1日あたりの制限（クォータ）があります。上限はスロットやスキャン量に応じて動的に決まります。詳細は以下を参照してください。 参考 : Quotas and limits - Quotas for Gemini in BigQuery 制限事項 当機能の制限事項は、以下のとおりです。 デフォルトでは 英語 の説明が生成される（日本語での生成手順は後述） BigQuery コンソール（BigQuery Studio）上からの操作のみ Geo 型、JSON 型の列には非対応 1テーブルにつき最大350カラムまで説明を生成可能 手順 データ分析情報の生成 まずは、テーブルのデータ分析情報（Data insights）を生成します。今回は、パブリックデータセット bigquery-public-data.samples.github_nested を自分のプロジェクトに複製して、このテーブルを対象とします。 BigQuery コンソール（BigQuery Studio）で対象テーブルを表示して、「分析情報」タブを選択します。 「分析情報」タブ プロジェクトで必要な API が有効化されていない場合、ここには API の有効化を促す表示がされます。表示に従い、API を有効化してください。 API を有効化されると、青いボタン「Generate insights for free」（無料で分析情報を生成）が表示されます。これをクリックします。 生成された説明を確認 数分後、生成された分析情報が表示されます。下部には分析のための SQL クエリが表示されています。 分析情報の生成結果 上部に表示されている「テーブルの説明」ブロックの中にあるリンク「列の説明を表示」をクリックすると、自動生成されたテーブルの説明とカラムの説明が表示されます。 生成された説明（Description） テーブルへの保存 「テーブルの説明」の下部にある「詳細に保存」をクリックすると、テーブルの説明を保存前に編集できます。任意の文章に編集したあと、「Save」ボタンを押下すると、テーブルに説明が保存されます。 テーブルの説明 「列の説明」の下部にある「スキーマに保存」を押下すると、同様に列の説明を編集できます。任意の文章に編集したあと、「保存」ボタンを押下すると、テーブルのカラムに説明が保存されます。 列の説明 結果 上記の手順では、パブリックデータセット bigquery-public-data.samples.github_nested を複製してメタデータ生成の対象にしました。同テーブルの仕様は、以下のとおりです。 スキーマ 列名 型 repository RECORD actor_attributes RECORD created_at STRING public BOOLEAN actor STRING payload RECORD url STRING type STRING 規模 項目 値 行数 2,541,639 合計論理バイト 1.58 GB 合計物理バイト数 471.78 MB 上記の表では省略していますが、RECORD 型の列の中には、多くのネストされた列があります。 このテーブルに対しては、以下のようなテーブルの説明が自動的に生成されました。 This table stores events from the GitHub platform. It captures actions performed by users, such as creating pull requests, commenting on commits, or pushing code. The table provides details about the actor performing the action, the type of event, and related data. It allows for analysis of activity trends, user contributions, and repository changes within the GitHub ecosystem. Gemini による日本語訳は、以下のとおりです。 このテーブルには、GitHubプラットフォームで発生したイベントが保存されています。ユーザーによるプルリクエストの作成、コミットへのコメント、コードのプッシュといったアクションを捉えます。テーブルには、アクションを実行したユーザー（アクター）、イベントの種類、関連データなどの詳細が含まれており、GitHubエコシステムにおける活動の傾向、ユーザーのコントリビューション、リポジトリの変更履歴などを分析できます。 この説明は概ね、データの内容を表しているといえます。 また、列の説明も概ね正しいものでした。なお、ネストされた列の説明もすべて生成されていました。 ネストされた列も説明が生成された 日本語での生成 BigQuery のメタデータの自動生成機能は、日本語を含む他言語に対応しています。ただし、デフォルトの出力は英語であり、他の言語で出力するには、 事前に テーブルの説明（Description）に「Generate table and column descriptions in Japanese.」のように プロンプトを埋め込んでおいてから 、データ分析情報（Data insights）の生成を実行する必要があります。 参考 : Generate data insights in BigQuery - Control generation language 以下のように、テーブルの説明（Description）に、日本語で説明を生成するように指示するプロンプトを事前に記述しておきます。 テーブルの説明（Description）にプロンプトを記述 その後、データ分析情報（Data insights）を生成します。既に実行済みの場合は、以下のボタンで再度、生成を指示できます。 データ分析情報（Data insights）を再度生成 以下のように、説明が日本語で生成されました。 日本語で生成された説明（Description） 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it