こんにちは、デジタルマーケティング事業に携わっている神崎です。 本記事では、Google Cloud の BigQuery で、Data Engineering Agent とともに BigQuery パイプラインを作成する方法について紹介します。 本記事の目次は、下記のとおりです。 はじめに BigQuery パイプラインを作成する おわりに はじめに Data Engineering Agent は、「データ エージェント ファミリー」と呼ばれる Google Cloud の AI エージェント群のうちのひとつで、データの ETL にかかわるタスクを支援します。 ※出典：生成 AI が拓…

G-gen の min です。BigQuery でデータ分析情報を生成する機能 データ分析情報 （Data insights）について解説します。 データ分析情報とは 概要 2つの分析レベル 分析情報を生成するモード 事前準備 必要な API の有効化 必要な IAM ロール テーブル分析情報 提供される機能 クエリの生成 説明の生成 生成言語の制御 生成手順 生成した分析情報の保存 データセット分析情報 提供される機能 データセットの説明 リレーションシップグラフ リレーションシップテーブル クエリの推奨 生成手順 制限事項 料金 データ分析情報とは 概要 データ分析情報 （ Data insights ）とは、BigQuery に統合された AI アシスタントである Gemini in BigQuery の機能の一つです。 BigQuery に蓄積されたデータを使用して分析を始める際、初めて見るテーブルにどのようなデータが入っているのか、他のテーブルとどのような関係があるのかを理解するには、通常、試しに SQL を書いてデータを抽出したり、設計書を読み解くなどの手間がかかります。 データ分析情報を使用すると、AI がテーブルやカラムの名前などの付帯情報（メタデータ）を読み取り、テーブルの概要を説明するテキストや、データ分析に役立つ SQL クエリを自動生成します。これにより、SQL に不慣れな非エンジニアの方や、初めてそのデータに触れるアナリストであっても、スムーズにデータ探索を開始できます。 参考 : BigQuery でデータ分析情報を生成する 2つの分析レベル データ分析情報には、分析の範囲に応じて以下の2つの機能が提供されています。それぞれの詳細については後述します。 機能名 分析対象 主な提供内容 テーブル分析情報 （table insights） 単一のテーブル データ内容や品質の分析、要約文の生成、データ抽出用 SQL クエリの提案 データセット分析情報 （datasets insights） 単一のデータセット 複数テーブル間の関係性の推論、テーブル結合を伴う SQL クエリの提案 後者のデータセット分析情報については、2026年4月現在、Preview 段階です。 分析情報を生成するモード BigQuery では、分析情報を生成する際に以下の2つのモードが用意されています。 モード 説明 用途 生成して公開 （Generate and publish） AI が生成したデータの説明や SQL クエリの提案を、Google Cloud のデータ辞書サービスである Dataplex Universal Catalog に保存します。権限を持つ他のメンバーと知識を共有できるほか、保存された説明を後から手動で編集することも可能です。 会社全体でデータの説明などのドキュメントを共有し、継続的に知識を蓄積・再利用したい場合。 公開せずに生成 （Generate without publish） その場限りの分析情報をすぐに作成します。生成された情報は、共有のデータ辞書には保存（公開）されません。 共有のデータ辞書に不要な情報を増やさず、一時的なデータ確認やお試しでの分析を素早く行いたい場合。 前者の生成して公開（Generate and publish）については、2026年4月現在、Preview 段階です。 Dataplex Universal Catalog については、以下の記事を参照してください。 blog.g-gen.co.jp 事前準備 必要な API の有効化 データ分析情報を使用するプロジェクトでは、事前に以下の API を有効化しておく必要があります。 BigQuery API Dataplex API Gemini for Google Cloud API 必要な IAM ロール コンソール画面からデータ分析情報を生成し、その結果を閲覧するためには、作業するユーザーの Google アカウントに対して以下の IAM ロールが付与されている必要があります。 データ分析情報の機能は内部的に Dataplex というデータ管理サービスの機能を使用しているため、BigQuery だけでなく Dataplex の権限も必要となる点に注意してください。 「BigQuery データ閲覧者（ roles/bigquery.dataViewer ）」または「BigQuery データ編集者（ roles/bigquery.dataEditor ）」 「Dataplex DataScan 編集者（ roles/dataplex.dataScanEditor ）」または「Dataplex DataScan 管理者（ roles/dataplex.dataScanAdmin ）」 参考 : BigQuery でデータ分析情報を生成する - 必要なロール テーブル分析情報 提供される機能 テーブル分析情報は、単一の BigQuery テーブルに含まれるデータの内容や品質、傾向を理解するための機能です。対象のテーブルに対して分析情報を生成すると、AI が以下のような情報を提供します。 クエリの生成 データ内のパターン、異常値、外れ値などを検出するための自然言語の質問と、それに対応する SQL クエリを提案します。 説明の生成 テーブル全体および各カラムに対する説明文を自動生成します。対象のテーブルに対して データ プロファイル スキャン （データの傾向や統計情報を抽出する機能）が実行されている場合、その結果も加味してより正確な説明が生成されます。 データ プロファイル スキャンについては、以下の公式ドキュメントを参照してください。 参考 : データをプロファイリングする 生成言語の制御 テーブルとカラムの説明を特定の言語で生成するように、Gemini に指示できます。 言語を指定するには、分析情報を生成する前に、テーブルの既存の説明文に「日本語で説明をして」といった短い指示を追記します。対象テーブルの「詳細」タブを開き、「詳細を編集」をクリックして指示文を追記および保存します。 詳細タブの画面 説明編集の画面 サポートされている言語の一覧については、以下を参照してください。 参考 : 言語サポート - Gemini 生成手順 Google Cloud コンソール画面から、テーブル分析情報を公開せずに生成する手順は以下のとおりです。 Google Cloud コンソールを開き、BigQuery Studio の画面に移動します。 画面左側の「エクスプローラ」ペインで、対象のプロジェクト名、データセット名の順に選択し、分析したいテーブルをクリックします。 画面右側にテーブルの詳細情報が表示されるため、上部のタブメニューから「分析情報」タブを選択します。 分析情報タブの画面 画面内の「公開せずに生成」ボタンをクリックします。 分析情報の生成には数分程度かかる場合があります。生成が完了すると、AI によって提案されたテーブルの概要や、データを分析するためのサンプル SQL クエリなどが同じ画面に表示されます。表示された SQL はそのまま実行したり、要件にあわせて書き換えて保存できます。 生成した分析情報の保存 Gemini in BigQuery は、データ分析情報を生成するときに、テーブルとカラムの説明を自動的に生成します。必要に応じてこれらの説明を編集し、BigQuery のスキーマや詳細情報として手動で保存できます。 テーブルで分析する内容を記述した詳細なテーブルの説明は、Gemini in BigQuery でより関連性の高い分析情報を生成するのに役立ちます。保存された説明は、自分や他のメンバーが参照できるだけでなく、今後の分析情報を生成するためにも使用されます。 説明文を保存する手順は以下のとおりです。 対象テーブルの画面で「分析情報」タブを開きます。 分析情報を生成後の分析情報タブの画面 画面内の「テーブルの説明」セクションにある「列の説明を表示」をクリックします。説明のプレビュー画面が表示されます。 説明のプレビュー画面 テーブル自体の説明を保存したい場合は、「詳細に保存」をクリックします。「提案された説明をコピー」をクリックして入力欄に内容を反映させたのち、「Save to details」をクリックします。 詳細に保存の画面 カラムの説明を追加・保存したい場合は、2. のプレビュー画面にて「列の説明」セクションにある「スキーマに保存」をクリックします。現在のスキーマとの変更内容の差分を確認し、問題がなければ「保存」をクリックします。 現在のスキーマの確認画面 データセット分析情報 提供される機能 データセット分析情報は、単一のデータセット内に存在する複数のテーブル間の関係性を把握するための機能です。当機能は 2026年4月現在、Preview 公開されています。 テーブル同士をどのように結合すれば意味のあるデータが抽出できるかを AI が推論し、以下の情報を提供します。 データセットの説明 データセット全体の概要を AI が要約して提供します。 リレーションシップグラフ データセット内のテーブル間の関係性を示す図を表示します。線にカーソルを合わせると、どのカラムをキーにして結合できるかといった詳細を確認できます。 リレーションシップテーブル テーブル間の関係性を表形式で一覧表示します。関係性の根拠として、明示的なシステム上の制約（外部キーなど）、過去のクエリの実行履歴に基づく使用状況、またはテーブル名やカラム名からの AI による推論が含まれます。 クエリの推奨 複数のテーブルを結合してデータを抽出するための、実践的な SQL クエリのサンプルを提供します。 生成手順 Google Cloud コンソール画面から、データセット分析情報を公開せずに生成する手順は以下のとおりです。 Google Cloud コンソールを開き、BigQuery Studio の画面に移動します。 画面左側の「エクスプローラ」ペインで、対象のプロジェクト名のツリーを選択し、分析したいデータセットをクリックします。 画面右側にデータセットの詳細情報が表示されるため、上部のタブメニューから「分析情報」タブを選択します。 分析情報タブの画面 画面内の「公開せずに生成」ボタンをクリックします。 分析情報の生成には数分程度かかる場合があります。生成が完了すると、AI によって提案されたデータセットの概要やリレーションシップグラフなどが同じ画面に表示されます。 例：Relationships の図 例：リレーションテーブル 制限事項 データ分析情報を使用する際の主な制限事項は以下のとおりです。 サポートされるテーブルは、BigQuery ネイティブのテーブル、BigLake テーブル、外部テーブル、ビュー カラムレベルのアクセス制御が設定されているテーブルに対して分析情報を生成するには、実行ユーザーが対象テーブルのすべてのカラムに対する読み取り権限を持っている必要がある テーブル分析情報において、AI が説明文を自動生成できるのは 1 テーブルあたり最大 350 カラムまで 新たにデータセット分析情報を生成すると、対象データセットに対する以前の分析情報は上書きされる マルチクラウド環境に保存されている、他クラウドのデータは対象外 参考 : BigQuery でデータ分析情報を生成する - 制限事項 料金 データ分析情報の機能自体に対する追加料金は発生しません。 データ分析情報は、Google Cloud プロジェクトにおいて、以下のいずれかの BigQuery 料金体系を適用している場合に使用できます。 オンデマンド Enterprise エディション Enterprise Plus エディション プロジェクトに BigQuery Editions の Standard エディションが適用されている場合は、データ分析情報を使用できないので注意してください。 また、生成された SQL クエリを BigQuery で実行した際には、通常の BigQuery のコンピューティング料金（データスキャンに対する課金など）が発生します。 参考 : Gemini for Google Cloud の料金 - Gemini in BigQuery の料金の概要 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の奥田です。当記事は、2026年3月19日に開催された Agentic AI Summit 2026 Spring で筆者と弊社の今野が登壇したセッション「Gemini Enterprise と ADK で実現する業務特化型エージェント開発の最前線 — ユーザー認証連携における Google Workspace 操作の実装方法と事例を公開」のレポートです。 セッションの概要 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク OAuth 2.0 によるユーザー認証連携 デモ : 議事録カレンダー登録エージェント デモの概要 Google Workspace への応用 なぜ ADK を選んだのか コードの実装 構成図とソースコードのディレクトリ構成 エージェントの定義 認証トークンの取得とカレンダー API の呼び出し 開発中に遭遇した落とし穴 ADK の State オブジェクト LiteLLM のセキュリティに関する注意 Gemini Enterprise へのデプロイ 参考リンク セッションの概要 当セッションでは、AI エージェントが Google Workspace のサービスを操作する際に不可欠な ユーザー認証連携 をテーマに、実装方法と事例を紹介しました。 セッション前半では、AI エージェントにおける認証の重要性を具体的なシナリオで解説し、議事録から Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。後半では、 Gemini Enterprise 、 Agent Development Kit （以下、 ADK ）、 Agent Engine を組み合わせたアーキテクチャと、 OAuth 2.0 連携の実装ステップを紹介しました。 参考 : Gemini Enterprise 参考 : Agent Development Kit（ADK） 参考 : Agent Engine 参考 : OAuth 2.0 Agentic AI Summit 2026 Spring での実績は以下のとおりです。 合計 オンライン オフライン CSAT G-gen セッション 741 名 556 名 185 名 3.9 なぜ AI エージェントにユーザー認証が必要なのか サービスアカウントのリスク AI エージェントを業務で利用する場合、「エージェントが誰として外部サービスにアクセスするのか」が重要な設計課題です。 たとえば、社員 A さんが AI エージェントに「来週の火曜日に会議を入れて」と依頼したとします。エージェントは A さんの代わりに Google Calendar を操作する必要があります。このとき、システム共通のサービスアカウントに権限を一括付与して動かすと、エージェントは A さんだけでなく B さんや他の組織の C さんのカレンダーにもアクセスできてしまいます。 技術的には動作しますが、業務での利用には適しません。AI エージェントは人間と違い、バックグラウンドで大量のデータに触れることができます。だからこそ「誰として動いているのか」を明確に設計することが不可欠です。 OAuth 2.0 によるユーザー認証連携 この課題の解決策が OAuth 2.0 を使ったユーザー認証連携です。 仕組みはシンプルです。ユーザーが一度ログインして権限を許可すると、エージェントはそのユーザーのアクセストークンを使って API を呼び出します。エージェントはそのユーザーの権限の範囲内でしか動作しません。 A さんの AI エージェントが行った操作は「A さんが自分の権限で実行した」という記録です。コンプライアンスの観点でも重要なポイントです。 デモ : 議事録カレンダー登録エージェント デモの概要 セッションでは、議事録や ToDo メモからタスクを抽出し、Google Calendar にイベントを自動登録するエージェントのライブデモを行いました。 デモの流れは以下のとおりです。 Gemini Enterprise 上でエージェントを起動し、OAuth 認証を完了する 直近のカレンダー予定を確認する 日時とタイトルを入力してイベントを追加する 約 6,300 文字の架空の議事録（ポータルサイトプロジェクト）をエージェントに渡す エージェントが議事録から 9 個の ToDo を抽出し、カレンダーに一括登録する 不要なプライベートの予定を削除する デモで約 6,300 文字の議事録を使用したのは、 Gemini の従来の強みである大規模コンテキストウィンドウを利用するため です。長文の議事録であっても分割せずに一度で処理できることを示す狙いがありました。 エージェントは 9 個のタスクを抽出しましたが、そのうち 2 つは会議のアイスブレイク時に話題に上がったプライベートな内容（入学式の話）でした。エージェントがこれらを業務タスクと同列に扱ってカレンダーに登録しました。 デモ後半では「プライベートの予定を削除」と入力するだけで、エージェントが自律的に予定の性質を判断し、該当するイベントのみを削除しました。これは、エージェントが文脈を理解し、カレンダーの内容を自律的に評価した実践的な事例です。 このエージェントの導入効果として、 議事録 1 件あたりのカレンダー登録作業を手動10分から自動で1分程度に短縮 できます。タスクの抜け漏れを防ぐ実用的なエージェントです。 Google Workspace への応用 今回のデモでは Google Calendar を題材にしましたが、同じ OAuth 2.0 連携の仕組みを使うことで、Google Workspace の各サービスにも応用できます。 Gmail では、エージェントがユーザー本人としてメールボックスに下書きを作成したり、宛先・件名・本文を含むメールを送信できます。たとえばミーティングの議事録をまとめて関係者にフォローアップメールを自動送信するといった使い方が可能です。 Google ドキュメント や Google スライド では、箇条書きや構成案を渡すだけでドキュメントやスライドの雛型を作成できます。ユーザーはブラッシュアップやクリエイティブな作業に集中できます。 Google ドライブ では、ユーザー自身がアクセス権を持つファイルだけを検索できるため、他者のファイルに触れるリスクがありません。社内ドキュメントをナレッジベースとして RAG 構成と組み合わせる使い方が効果的です。 共通するポイントは、すべての操作がユーザー本人の権限の範囲内で動作することです。 なぜ ADK を選んだのか エージェント開発のフレームワークには LangChain や CrewAI など複数の選択肢があります。今回 ADK を採用した理由は大きく2つです。 1つ目は、 Google Cloud のエコシステムで完結させたかった ことです。フロントエンドの Gemini Enterprise、実行基盤の Agent Engine、そして開発フレームワークの ADK をすべて Google Cloud のサービスで統一することで、認証トークンの受け渡しやデプロイがマネージドサービス間でシームレスに連携します。前述のとおり、 tool_context.state を通じた OAuth トークンの自動受け渡しは、この統一されたエコシステムがあってこそ実現できる仕組みです。 2つ目は、 ADK と OAuth 2.0 を組み合わせた実装事例がまだ少なかった ことです。ADK 自体の利用例は増えていますが、Gemini Enterprise の OAuth 連携と組み合わせて Google Workspace を操作するパターンは、2026年4月現在でも公開事例が限られています。今回のセッションとデモを通じて、この実装パターンを広く共有したいという意図がありました。 コードの実装 構成図とソースコードのディレクトリ構成 構成図は以下です。 ソースコードは GitHub で公開しています。 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report リポジトリのディレクトリ構成は以下です。 . ├── __init__.py ├── agent.py # エージェント定義 ├── tools.py # ツール関数（Calendar API 操作） ├── config.py # 設定値の管理 ├── requirements.txt # 依存パッケージ ├── .env_example # 環境変数のサンプル ├── .gitignore └── README.md エージェントの定義 以下は ADK でエージェントを定義する agent.py の全体です。49 行でエージェントの定義が完結しています。 # agent.py from google.adk.agents.llm_agent import Agent from . import tools from google.adk.models.lite_llm import LiteLlm root_agent = Agent( name= "calendar_agent" , model=LiteLlm( "vertex_ai/gemini-3-flash-preview" , vertex_location= "global" ), description= "議事録を解析して Google Calendar にイベントを登録するエージェント" , instruction= """あなたは議事録からTodoを抽出して Google Calendar に登録するアシスタントです。 以下の手順で作業してください。 1. ユーザーから議事録を受け取る。 - ファイルパスが渡された場合は read_todo_file ツールでファイルを読み込む。 2. テキスト内容を解析し、議事録からTodoとそれに関係する情報を抽出する: - 日付・時刻（今年は2026年。月/日 の形式なら 2026年として解釈する） - イベントタイトル - 説明（あれば） - 終日イベントかどうか 3. 抽出した各イベントについて create_calendar_event ツールを呼び出して登録する。 - 日時は ISO 8601 形式にする（例: 2026-02-20T14:00:00） - 終日イベントの場合は日付のみ（例: 2026-03-01）、end_datetime は翌日にする - 時間の指定がない場合は終日イベントとして扱う - 終了時刻の指定がない場合は開始から1時間後を終了時刻とする - タイムゾーンは Asia/Tokyo 4. Todo テキストに参加者（メールアドレス）の記載があれば attendees に指定する。 ユーザーが参加者を指定した場合は、そのメールアドレスを追加する。 5. 登録結果をユーザーに報告する。 注意事項: - すべての日時は日本時間 (JST, Asia/Tokyo) を基準とする。 時刻の指定がある場合は日本時間として解釈すること。 - テキストは自由形式。「2/20 14:00 美容院」のようなフォーマットもあれば、 文章形式の場合もある。柔軟に解析すること。 - 日付が曖昧な場合は確認を求める。 """ , tools=[ tools.read_todo_file, tools.create_calendar_event, tools.list_calendar_events, tools.update_calendar_event, tools.delete_calendar_event, ], ) Agent クラスの model に LiteLlm で gemini-3-flash-preview （2026年4月現在）を指定しています。 instruction にはシステムプロンプトとして議事録の解析手順を記述し、 tools に呼び出し可能なツール関数を登録しています。 ADK では LiteLlm を使うことで Gemini 以外のモデル（Claude、GPT など）にも切り替えられます。 参考 : ADK LiteLLm ドキュメント 認証トークンの取得とカレンダー API の呼び出し 今回の構成で最も注目すべきポイントは、Gemini Enterprise・ADK・Agent Engine の3つのサービスが連携してユーザーの認証トークンをシームレスに受け渡す仕組みです。 通常、OAuth 2.0 を使ったアプリケーション開発では、トークンの取得・保存・リフレッシュ・有効期限の管理といった複雑な認証フローを開発者自身が実装する必要があります。しかし、Google Cloud のエコシステムではこの課題が解消されています。ユーザーが Gemini Enterprise 上で OAuth 認証を完了すると、取得されたアクセストークンは Agent Engine のセッションに自動で保存されます。ADK のツール関数では、引数として渡される ToolContext の state からそのトークンをわずか1行で取得できます。 この「Gemini Enterprise（認証 UI）→ Agent Engine（トークン管理）→ ADK（トークン利用）」という一連の流れが、Google Cloud のマネージドサービス間で自動的に実現される点が、このエコシステムの大きなメリットです。 以下の get_calendar_service 関数がその実装の核心です。 from google.oauth2.credentials import Credentials from googleapiclient.discovery import build from google.adk.tools import ToolContext def get_calendar_service (tool_context: ToolContext): """ Agent Engine 環境で Google Calendar サービスを認証・生成します。 """ # 1. 環境変数から管理画面で設定した ID を取得 auth_id = os.getenv( "AUTH_ID" ) # 2. トークンの取得を試みる access_token = tool_context.state.get(auth_id) if not access_token: access_token = tool_context.state.get( "authentication" ) # 3. トークンが見つからない場合 if not access_token: raise ValueError ( "認証トークンが取得できませんでした。" "チャット画面で Google ログインを完了させているか確認してください。" ) # 4. 取得したトークンでカレンダーサービスを構築 creds = Credentials(token=access_token) return build( "calendar" , "v3" , credentials=creds) ポイントは tool_context.state.get(auth_id) のわずか1行です。この1行の背後では、以下の処理が Google Cloud のマネージドサービスによって自動的に行われています。 Gemini Enterprise がユーザーに OAuth 同意画面を表示し、認可コードを取得する Agent Engine が認可コードをアクセストークンに交換し、セッションの state に保存する ADK のツール関数が ToolContext 経由でそのトークンを取得する 開発者が実装するのは tool_context.state.get(auth_id) でトークンを取り出し、 Credentials に渡す部分だけです。トークンの取得フロー、リフレッシュ、有効期限の管理はすべてマネージドサービス側が担います。 認証フローの実装が、Google Cloud のマネージドサービス連携により数行のコードに集約されています。 以下は、メインのツール関数である create_calendar_event です。 def create_calendar_event ( summary: str , start_datetime: str , end_datetime: str , tool_context: ToolContext, description: str = "" , timezone: str = "Asia/Tokyo" , attendees: list [ str ] | None = None , ) -> dict : """Google Calendar にイベントを作成する。""" service = get_calendar_service(tool_context) s_dt = start_datetime.strip() e_dt = end_datetime.strip() # 終日イベントかどうかの判定 is_all_day = ( "T" not in s_dt) and ( ":" not in s_dt) if is_all_day: s_dt = s_dt.replace( "/" , "-" ) e_dt = e_dt.replace( "/" , "-" ) event_body = { "summary" : summary, "description" : description, "start" : { "date" : s_dt}, "end" : { "date" : e_dt}, } else : if " " in s_dt: s_dt = s_dt.replace( " " , "T" ) if " " in e_dt: e_dt = e_dt.replace( " " , "T" ) event_body = { "summary" : summary, "description" : description, "start" : { "dateTime" : s_dt, "timeZone" : timezone}, "end" : { "dateTime" : e_dt, "timeZone" : timezone}, } if attendees: event_body[ "attendees" ] = [{ "email" : email} for email in attendees] event = service.events().insert(calendarId= "primary" , body=event_body).execute() return { "status" : "success" , "event_id" : event[ "id" ], "summary" : event[ "summary" ], "html_link" : event[ "htmlLink" ], } get_calendar_service(tool_context) を呼び出すことで、ログイン中のユーザーの権限で Google Calendar API を操作しています。終日イベントと時間指定イベントを date と dateTime で区別し、 attendees パラメータで参加者の追加にも対応しています。 開発中に遭遇した落とし穴 ADK の State オブジェクト 開発中、認証トークンの中身を確認しようとした際に以下のエラーに遭遇しました。 # やりたかったこと：state の中身を一覧表示したい print (tool_context.state.keys()) 上記の様に入力すると、以下の結果になります。 AttributeError: 'State' object has no attribute 'keys' ADK の State オブジェクトは、標準の Python 辞書（ dict ）ではなく、Python の MutableMapping プロトコルにも準拠していません。辞書のように値の取得や代入はできますが、 .keys() や .items() といった標準的なメソッドは持っていません。これはバグではなく、会話状態の差分追跡を確実に行うための意図的な設計です。 注意すべき点として、ADK には以下2つの state が存在します。 session.state tool_context.state （ context.state ） session.state は標準の Python 辞書（ dict ）であるため .keys() や .items() が通常どおり使えます。 一方、ツール関数の引数として渡される tool_context.state は前述の State オブジェクトであり、これらのメソッドは使えません。 session.state.keys() は正常に動作するのに tool_context.state.keys() ではエラーになるため、両者を混同するとデバッグ時に混乱を招きます。 ツール関数内では tool_context.state を使うため、 .get() メソッドで安全に値を取り出す必要があります。 # 正しい方法：.get() で安全に取得 access_token = tool_context.state.get(auth_id) 操作は .get() や直接代入（ tool_context.state[key] = value ）に留めることが推奨されます。ADK を使ったエージェント開発を始める方は、この仕様を事前に把握しておくとデバッグ時間を節約できます。 参考 : Context - Agent Development Kit (ADK) LiteLLM のセキュリティに関する注意 LiteLLM v1.82.7 / v1.82.8 は、サプライチェーン攻撃（TeamPCP）により侵害されました（2026年3月24日）。本デモの GitHub リポジトリのサンプルコードでは v1.83.0（攻撃後の正規リリース、2026年3月31日公開）にピン留めしています。 詳細は以下を参照してください。 参考 : LiteLLM 公式セキュリティアップデート 参考 : GitHub Issue #24518（タイムライン） Gemini Enterprise へのデプロイ 作成したエージェントを Agent Engine にデプロイした後、Gemini Enterprise のコンソールからエージェントを追加できます。画面からの操作のみでデプロイが完了します。 ユーザーごと、またはグループごとにエージェントの利用権限を管理することも可能です。組織全体への安全な展開が実現できます。 参考リンク 参考 : Agentic AI Summit 2026 Spring 参考 : 登壇資料 参考 : G-gen-Tech-Blog/agentic-ai-summit-2026-spring-session-report（ソースコード） 以下の動画でセッションの実演をご覧いただけます。 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh