みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今週のトップニュースは AWS Agent Registry と Claude Mythos の Amazon Bedrock 上での Gated Research Preview でしょう。AWS の CISO である Amy が、AWSのセキュリティアプローチがどのように Anthropic のようなパートナーとお客様のイノベーションを加速しているのかを解説しているブログも今週号で取り上げていますので、ぜひご一読ください。 また今週  4 月 15 日には「 AI-DLC 体験勉強会 」が開催されます。AWS Summit Japan 2026 では AI-DLC のハッカソンも予定されているので、ぜひこれを機にキャッチアップしてみてはいかがでしょうか？ それでは、4 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 大豊建設株式会社様、生成 AI アシスタント「大豊 AI」で業務の様々な場面を効率化 大豊建設様は、土木・建築工事を中心とした総合建設会社です。社内の情報へのアクセスのしにくさ、文書作成の負担、中堅社員不足による知識共有の難しさといった課題を抱えていました。そこで、AWS を基盤として生成 AI を活用した「大豊 AI」を構築し、フリートーク、社内規程検索、ファイルチャット、全文検索、ユースケース別検索などの機能を社内に展開しました。2025 年 6 月の全社展開から約 8 ヶ月で 307 名の社員が利用し、累計 32,709 回以上の利用回数を記録しています。規程検索だけでも約 250 時間の業務時間削減を実現しました。今後は、施工計画書の作成支援や社内資料作成支援といった、Amazon Bedrock AgentCore のエージェント技術を活用した業務効率化も目指しています。 AWS生成AI国内事例ブログ: 丸紅グループが描く生成AI活用の全貌 〜内製開発・AIエージェント活用で変わる総合商社の姿〜 丸紅グループの生成 AI 活用の続編記事です。 前回 紹介した社内生成 AI プラットフォーム「Marubeni Chatbot」は登録ユーザー数が 7,500 人以上から 10,000 人以上へと拡大しました。今回は、Amazon Bedrock AgentCore を活用した AI エージェント機能の搭載、競合分析システムの構築、水道管路 AI 劣化予測診断サービス（分析作業を約 99% 削減）、そして AI DLC Unicorn Gym の開催という 4 つの新たな取り組みを紹介しています。丸紅グループが生成 AI をどのように業務や開発の現場に根付かせてきたか、ぜひご覧ください。 ブログ記事「 AI を活用した大規模なセキュリティ防御の構築 — 脅威が出現する前に 」を公開 AWS CISO の Amy のブログの翻訳です。Anthropic が発表した Project Glasswing と、これまでで最も高度な AI モデルである Claude Mythos Preview について紹介しています。Claude Mythos Preview はサイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクで高いパフォーマンスを発揮する新しいモデルクラスです。AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos Preview をすでに適用しており、セキュリティの検出結果を洗い出す際に従来のモデルよりも高い生産性を発揮しています。 ブログ記事「 AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 」を公開 AWS Security Agent は、自律型ペネトレーションテストを提供するフロンティアエージェントです。手動のペネトレーションテストの数分の一のコストで、24 時間 365 日稼働します。SAST、DAST、ペネトレーションテストの機能を単一のコンテキスト認識型エージェントに統合し、マルチクラウドに対応しています。HENNGE 様は「一般的なテスト期間を 90% 以上短縮できます」と述べています。 ブログ記事「 AWS DevOps Agent によるエージェンティック AI を活用した自律的インシデント対応 」を公開 AWS DevOps Agent は、Amazon Bedrock AgentCore 上に構築された常に利用可能な運用チームメンバー Agent です。インシデントの解決とプロアクティブな予防を行い、AWS、マルチクラウド、オンプレミス環境にわたる SRE タスクを処理します。本記事では、URL 短縮サービスの例を通じて、DevOps Agent を次世代の完全な運用チームメンバーたらしめる 6 つの主要な能力「6 つの C」を解説しています。 ブログ記事「 Amazon Bedrock Guardrails では、一元化された制御と管理により、クロスアカウント保護がサポートされています 」を公開 Amazon Bedrock Guardrails でクロスアカウントセーフガードが一般提供されました。組織の管理アカウント内でガードレールを指定し、すべてのメンバーエンティティ全体で自動的に実施できるようになりました。個々のアカウントやアプリケーションを監視する管理上の負担を大幅に軽減しながら、企業の責任ある AI 要件の一貫した遵守をサポートします。 ブログ記事「 コパイロットからコワーカーへ – AAAI : エージェント研究と実用化のギャップ 」を公開 AAAI 2026 のパネルディスカッションで、Microsoft、Mistral、シンガポール国立大学、LinkedIn、AWS の研究者と実務者が、コーディングエージェントを本番環境に投入する際の課題について議論しました。研究は能力の最適化に注力する一方、本番環境では信頼性、コスト、レイテンシー、信頼、組織への適合性を同時に最適化する必要があるという議論が展開されています。今後の研究の方向性についても言及されており、エージェント開発に携わる方にとって示唆に富む内容です。 ブログ記事「 Kiro Students プランのご紹介 」を公開 AI コーディングツール Kiro の学生向けプランが発表されました。対象の大学生は、月 1,000 クレジット付きの Kiro を 1 年間無料で利用できます。まず 11 の大学からスタートし、今後さらに多くの大学への拡大を予定しています。 ブログ記事「 Kiro スタートアップクレジットプログラムが復活します 」を公開 アーリーステージから Series A までのスタートアップを対象に、最大 1 年分の Kiro Pro+ を無料で申請できるプログラムが復活しました。チーム規模に応じて 3 つのティア（最大 2、10、30 ユーザー）が用意されています。 ブログ記事「 Kiro CLI の新しいデザイン 」を公開 Kiro CLI の刷新された UX が実験的モードとして公開されました。ライブ統合ステータス、常時表示の入力エリア、スラッシュコマンドと @ コンテキスト、コンテキストオーバーレイなどの新機能が追加されています。 kiro-cli --tui  で試すことができます。 ブログ記事「 Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：新規ベクトルデータの投入が不安定、または失敗する場合 」を公開 ブログ記事「 Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：検索レイテンシの増加が問題になっている場合 」を公開 Amazon OpenSearch Service の FAISS エンジンを使用したベクトル検索のトラブルシューティングに関する 2 本の記事が公開されました。RAG などでベクトル検索を活用している方にとって、データ投入の不安定さや検索レイテンシの増加に対する原因調査と対処法の考え方が体系的にまとめられています。 サービスアップデート Amazon Bedrock で Claude Mythos Preview が限定リサーチプレビューとして利用可能に Anthropic のこれまでで最も高度な AI モデルである Claude Mythos Preview が、Amazon Bedrock で限定リサーチプレビューとして利用可能になりました。Claude Mythos Preview は、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクにおいて最先端の能力を持つ根本的に新しいモデルクラスです。Project Glasswing の一環として、インターネットの重要インフラ企業やオープンソースのメンテナーが優先的にアクセスできます。現在、米国東部（バージニア北部）リージョンで利用可能です。 AWS Agent Registry が集中型エージェント検出・ガバナンスのためにプレビュー提供開始 Amazon Bedrock AgentCore を通じて利用可能な AWS Agent Registry がプレビューで提供開始されました。組織内のエージェント、ツール、スキル、MCP サーバー、カスタムリソースのプライベートなカタログおよび検出レイヤーです。セマンティック検索とキーワード検索の両方に対応し、承認ワークフローや AWS CloudTrail による監査証跡も提供します。米国西部（オレゴン）、アジアパシフィック（東京）を含む 5 リージョンで利用可能です。 Amazon Bedrock AgentCore Browser に OS レベルの操作機能を追加 Amazon Bedrock AgentCore Browser に、Chrome DevTools Protocol (CDP) だけでは対応できないブラウザワークフローの自動化を可能にする OS レベルの操作機能が追加されました。マウス操作、キーボード操作、フルデスクトップスクリーンショットなどが利用可能です。AI エージェント開発者やテスト自動化エンジニアにとって有用なアップデートです。アジアパシフィック（東京）を含む 14 リージョンで利用可能です。 Amazon Bedrock が IAM ユーザーおよびロールによるコスト配分をサポート Amazon Bedrock が、IAM ユーザーおよび IAM ロールによるコスト配分を AWS Cost and Usage Report 2.0 (CUR 2.0) と Cost Explorer でサポートするようになりました。IAM ユーザーやロールにチーム、プロジェクト、コストセンターなどのタグを付与し、コスト配分タグとして有効化することで、Bedrock のモデル推論コストをユーザー、チーム、プロジェクト、アプリケーション別に把握できるようになります。Bedrock が利用可能なすべての商用リージョンで利用可能です。 AWS Cost Explorer が Amazon Q を活用した自然言語クエリ機能を提供開始 AWS Cost Explorer に Amazon Q Developer の生成 AI 機能が統合され、自然言語でコストと使用状況データについて質問できるようになりました。「今月の上位支出サービスを表示して」といった質問に対して、Amazon Q が詳細なインサイトを提供すると同時に、Cost Explorer が対応するビジュアライゼーションを自動更新します。すべての商用 AWS リージョンで追加料金なしで利用可能です。 SageMaker HyperPod が分散トレーニングワークロード向けギャングスケジューリングをサポート Amazon SageMaker HyperPod のタスクガバナンスにギャングスケジューリングが追加されました。分散トレーニングジョブに必要なすべての Pod が準備完了してからトレーニングを開始することで、部分的なジョブ実行による無駄なコンピューティングやデッドロックを防止します。アジアパシフィック（東京）を含む複数のリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

はじめに タイトルの問いに対して、結論から言うとベクトル検索が完全に不要になった、ということはないです。一方、「各文書を分割→ベクトル化→並列に配置して検索」のような従来RAGのアーキテクチャだと対応できないユースケースは多々あります。 本記事では、従来のベクトル型RAGの特徴を振り返り、技術的課題を再認識するとともに、最新のRAGアーキテクチャの利点を踏まえて、これらとベクトル検索をいかに共存させるかを再検討します。 RAG（Retrieval-Augmented Generation） RAGの定義 そもそもRAGとは、外部にあるデータを抽出し、ユーザーの入力と合わせてL

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