はじめに はじめまして！慶應義塾大学環境情報学部3年の上野 大和です！2026年の4月の1ヶ月間、C ...

はじめに デジタルテクノロジー戦略本部 AI戦略室 AIソリューション部 データサイエンス1課のN.Rです。 2026年4月22日から24日にかけてラスベガスで開催された  Google Cloud Next '26  に参加してきました！ 本記事では、今年のNext で注目を集めたテーマのひとつである 「Gemini Enterprise Agent Platform」  について紹介します。 Google Cloud Next '26 ってどんなイベント？ Google Cloud Next は、Google Cloud が主催する年次テックカンファレンスです。世界中のエンジニアや企業関係者が集まり、クラウドの最新動向や新しいプロダクト・技術が発表される一大イベントとして知られています。 イベントの幕開けを飾る Keynote では、Google のリーダー陣による重要な発表や大規模なデモが行われ、会場は大盛り上がりでした！ 今年は 2026年4月22日〜24日 の3日間、ラスベガスの Mandalay Bay Convention Center で開催され、 今年のテーマは 「The Agentic Era（エージェント時代）」。AI が「会話するツール」から「自律的に行動するエージェント」へと進化したことを象徴するイベント でした。 3日間のプログラム構成 各自聞きたい講演を事前に予約して、いろんな情報収集することができます。 Next は単なる講演イベントではなく、多様な形式のプログラムで構成されています。 プログラム 概要 Keynote イベントの方向性を決める基調講演です。CEO Thomas Kurian 氏による Opening Keynote と、エンジニア向けの Developer Keynote を含む計3本が行われました。新プロダクトの発表や大規模デモが披露される、まさにイベントの「顔」です。 Spotlight 特定テーマを深掘りする中規模セッションになります！ Breakout Session AI・データ・セキュリティ・インフラなど幅広いテーマをカバーし、Q&A で登壇者に直接質問もできます。 Workshop ハンズオン形式の実践型セッションです。Googler やパートナー企業の開発者から直接指導を受けながら手を動かせます。人気なので、予約が取れないです！ Discussion 少人数のラウンドテーブル形式です。参加者同士で特定テーマについて議論する感じです。 Solution Talk あらかじめ設定された課題に対して Googler が解決策を順を追って解説するセッション。実践的なアーキテクチャの参考になります。 Lightning Talk Developer Theater で行われる約20分の短時間デモ。最新トピックをサクッとキャッチアップできます。 Expo スポンサー・パートナー企業が出展する展示エリアです。最新プロダクトのライブデモを体験したり、エキスパートに直接相談できます。 Keynote はオンラインでもライブ配信されますが、Workshop で Googler に直接質問したり、Expo で最新デモに触れたり、Discussion で他の参加者と議論できるのは 現地参加ならではです。 私は、Workshopに一番参加したかったのですが、予約がとれず、Keynote、Spotlight 、Breakout Sessionをメインに参加してました！ 今回は、Keynoteで発表された、 Gemini Enterprise Agent Platformについて紹介します！ Gemini Enterprise Agent Platform とは 従来の  Vertex AI  から名称変更され、エージェント開発者向けの統合支援プラットフォームとして生まれ変わりました。 まさか名称変更されるとは、気に入っていたので少し寂しかったです。。。 Agent Platform は以下の  4つの柱  で構成されています。 柱 役割 主なサービス Build エージェントの開発 ADK / Agent Studio / MCP Scale エージェントの実行・スケール Agent Runtime Govern 認証・アクセス制御 Agent Registry / Agent Gateway Optimize 監視・可観測性 Agent Observability 開発から運用まで、エージェントのライフサイクル全体をカバーする構成です。 Vertex AIの時は、MLモデルも扱う感じでしたが、一気にエージェントのツールに振り切った印象を受けました！ エージェント開発の選択肢 — ADK と Agent Studio エージェントの開発手法は  コードベース  と  ローコード  の2種類が用意されています。 Agent Studio（ローコード） Agent Platform 上の UI で開発できるローコードツールです。 自然言語で入力するだけでエージェントを開発 できるようになりました！ 作成したエージェントのコードも見れるので、コードを書く人にとってもありがたい仕様になっております。 現在プレビュー版で、機能が後日追加な部分がありますが、これからの機能追加に期待です！ Agent Development Kit（コードベース） Python・Java・Go・TypeScript の  4言語  に対応し、詳細なカスタマイズが可能な開発キットです。 本格的にAIエージェントを開発するなら、ADK ** の方が優れています。 今回、 ADK 2.0** がベータ版でリリースされました。2.0からグラフベースのエージェント設計ができるようになり、条件分岐などに対応可能になりました。現場でエージェントを扱うためには必要な構造です！ エージェントの実行基盤 — Agent Runtime エージェントの実行環境は  3種類  用意されています。 実行環境 特徴 適用シーン Agent Runtime エージェント特化のマネージド環境。最大3,000エージェント同時実行、最大7日間の長期実行、Memory Bank標準搭載 本番運用・大規模デプロイ Cloud Run コンテナベースの汎用実行環境 カスタムランタイムでの柔軟なデプロイ GKE Kubernetes基盤。GPU対応やカスタムネットワーク構成が可能 大規模オーケストレーション 中でも  Agent Runtime  は、最大3,000エージェント同時実行、最大7日間の長期実行と、長時間稼働もできる環境になっており、現場でエージェントを稼働させるための環境といった印象を受けました！ また、セッション管理・Memory Bank等のメモリ系も標準搭載されている点はすごく驚きました。エージェント専用のDBとかを別で作らなくていいのは、手間が省けますね。 Memory Bank — エージェントの長期記憶 個人的に、今回のイベントで  最も注目した機能  が Memory Bank です。 セッション機能との違い セッション機能と何が違うのかというと、用途も少し違いますが、 セッションが短期記憶とMemoryBankが長期記憶のイメージでした！ 比較項目 セッション機能 Memory Bank 記憶の範囲 単一セッション内の会話のみ セッション横断で永続的に保持 保持期間 セッション終了時に消失 長期的に保持・蓄積 主な用途 会話中の文脈維持 ユーザーの好み・ビジネスルールの学習 デモで見た活用例 Next の会場では、 服のレコメンドエージェント  のデモが印象的でした。 ユーザーの好みの色や嫌いな色を Memory Bank に保存することで、次回以降は何も説明しなくても、好みが反映されたレコメンドが自動で生成されていました。 これは  パーソナライズ AI エージェント  実現の鍵になる機能だと感じます。 Govern & Optimize — エージェントの統合管理 エージェントを本番運用するうえで欠かせない、 セキュリティ・ガバナンス・可観測性を統合した管理基盤も発表されました。 機能 特徴 ステータス Agent Registry エージェント・MCPサーバー・ツールの統合カタログ Preview Agent Gateway トラフィックや権限、アクセス制御 Preview Agent Observability エージェントの挙動の可視化・追跡 Preview 認証・登録・通信制御からパフォーマンス監視まで、包括的な運用管理が実現できる構成になっています。 エージェントの本番運用となると、運用構成や、監視の仕組みが重要になってくるので、ここら辺の機能については、社内でも知見を深めていきたいですね！ まとめ 今年の Google Cloud Next は「AIエージェントを現場へ」というメッセージが 全体を貫いており、開発・実行・管理の各層で具体的なツールが揃ってきた印象です。 特に印象的だったのが、Memory Bank によるパーソナライズの可能性です。 デモでは、ユーザーの好みをエージェントが継続的に記憶し、次回以降の提案に自然に反映する様子が紹介されていました。単発の会話にとどまらず、パーソナライズした提案ができるような仕組みは、興味が湧きました！ 一方で、こうしたエージェントを実際のプロダクトとして運用していくためには、開発だけでなく運用面の設計が重要になります。エージェントが業務の中核に入り込んでいくほど、これらの運用基盤の重要性はさらに高まっていきます。だからこそ、単に新しい機能として捉えるのではなく、実運用を見据えた技術として理解を深めていく必要があると感じました。 今後は、こうした運用構成や監視の仕組みについても社内で知見を蓄積しながら、どのように自社サービスへ適用できるかを具体的に検討していきたいと考えています！ 来年行く人へ 講演を聞くのも楽しいですが、手を動かすのも楽しいと思うので、ぜひWorkshopに参加して欲しいです。また、講演を予約せずに、Expoを見て回り、今回発表された機能を間近で見れるブースがあり、社員に近い距離で質問できるのでこれもイベントの楽しみ方の選択肢の一つだなと思いました！ ぜひ、来年のイベント参加の参考にしてください。 初めてラスベガスに訪れたのですが、やはり印象的なのが華やかな街並みでした！ 今回の滞在中に訪れた有名な「ベラージオ」では、噴水ショーを見ることができました。 昼間はカンファレンスで最先端のテクノロジーに触れ、夜はこうしたエンターテインメントを体験できるのも、ラスベガス開催ならではの魅力だと感じました！ 最後までお読みいただき、ありがとうございました！

はじめに Q. 日々、テレビでながれる、国会における国会議員と大臣の議論。霞が関では多くの国家公務員が夜遅くまで働いていますが、国会での議論に先立って、どのような業務が行われているかご存知でしょうか？ A. 様々ありますが、その主な業務の一つが、国会において想定される質問と、それに対する回答案や関連情報をまとめた資料（想定問答）を作成することです。 国会答弁は、国民及び国民の代表である国会議員に対して、政府の政策や方針、予算について国会で説明し、行政の透明性と説明責任を果たすためのものです。その質を支えるのが、国会答弁の想定問答作成業務であり、正確性や首尾一貫性などが厳しく求められる重要度の高い業務となっています。それゆえに職員の負担も大きく、 昨今の公務員の働き方改革や生成 AI 技術の急速な発展も相まって、本業務のさらなる高度化・効率化への期待が高まっています。AWS はとある省庁のシステム担当部局と、この想定問答の作成・審査業務における、 AI を活用した高度化・効率化の可能性を検討してきました。本稿では、AWS の公共部門のアカウントチームおよびプロトタイピングチームが伴走し、省庁が組織内に持つ過去の想定問答ファイルを横断検索しながら、AI による想定問答のドラフトの生成や、人の手による修正を含む審査プロセスを支援する AI アプリケーションを構築した取り組みをご紹介します。 プロトタイピングチームについて AWS パブリックセクタープロトタイピングチームは、公共・教育・医療・NPO などの分野のお客様が抱える課題の解決を無償で支援・加速するチームです。プロトタイピングという名前の通り、お客様の「実現したいこと」を、実際に動作するプロトタイプとして形にし、お客様に（技術）提供することで課題解決のご支援を行っています。 背景と課題 国会答弁のための想定問答を作成する際には、過去に作成した想定問答ファイルや国会会議録を、限られた時間の中で正確に参照する必要があります。しかし、参照すべき文書や資料の候補は大量にあり、検索対象も複数あることなどから、極めて限られた時間の中で、必要な情報に素早くたどり着くこと自体、容易ではないケースが多々あります。 補足：国会対応業務の流れ 国会対応における行政職員の作業の概要は以下の通りです（あくまで概略であり、実際の業務とは異なる場合があります）。 質問内容の聞き取り ：次の委員会で質問することが予定されている国会議員やその秘書の方から、質問内容やその趣旨・背景について、事前に聞き取ります。 答弁案の初稿作成 ：質問の対象となっている施策や領域の担当部局の行政職員が、現在の政府方針や現行法令、そのときどきの経済・社会情勢や過去の答弁等の関連情報を踏まえ、答弁案の初稿を作成します。 関係部局との調整 ：答弁案の初稿に対して、関連する部局と調整を行います。質問や回答案が他の省庁に関係する場合は、他の省庁とも調整を行い、内容を精査します。 答弁審査 ：担当部局が作成した答弁案について、過去の説明や他の部局が担当している施策、当日など直前に決まった政府方針などを踏まえているかどうか、質問に対する応答として正しく成立しているか、国民目線で適切な答弁案となっているかといった総合的な観点から、一言一句、審査が行われます。 レクチャー ：答弁者への完成した原稿を、答弁者である大臣などに説明し、国会での議論に備えます。 今回のプロトタイプで注目したのは、このうち 答弁作成 と 答弁審査 の工程です。AI によって答弁案の作成を効率化したいという期待がある一方で、そもそも実際に役に立つ AI 支援ツールの作成は実現可能なのか。ユーザーである国家公務員の期待に応える水準の機能を提供できるのか。こうした問いを本格的な導入の前に見極めたい——それが今回のプロトタイピングプログラムの出発点です。 なお、本取り組みは答弁の最終的な判断や回答案の表現を AI に委ねるものではなく、あくまで人間の判断を中心に据えた上、関連する文書の検索やドラフトの準備など機械的に処理できる部分を AI に担わせることで、職員がより本質的な検討に集中できる環境を目指すものです。 なぜ AWS のプロトタイピングプログラム支援だったのか AWS のプロトタイピングプログラムは、公共のお客様のアイデアをプロトタイプに落とし込み、技術的な実現可能性を短期間で検証するための無償の支援プログラムです。アイデアを机上の議論にとどめず、現場の業務に近い形で動かし、使用者のフィードバックを得ながら評価したいという職員の方々のニーズに対し、Amazon Bedrock をはじめとするマネージドな AI サービス群と AWS アカウントチーム、そしてプロトタイピングチームの伴走により、最小限のリードタイムで検証サイクルを回せる本プログラムが最も適していると判断し、支援を開始しました。 プロトタイピングの進め方 一般的にプロトタイピングプログラムは１～３ヶ月程度で行いますが、本件では本番環境での導入を目指し約半年にわたって担当部局の方々と反復改善を重ね、画面の使い勝手から検索精度、運用面を含めた部分まで、利用者の声を起点に作り込みました。その結果、設定変更を含めた５回のメジャーバージョンと１１回のマイナーバージョンを経て、本番運用を前提とした水準のプロトタイプとなりました。 進め方は、以下のサイクルを高頻度で回す共創型のアプローチです。 ヒアリングした要件を元に機能を開発。 担当部局の方々に実際にデプロイして使っていただき、フィードバックを収集する。 フィードバックを要件や設計に落とし込み、機能として実装する。 ２に戻る。２で必要であれば、デプロイ支援、トラブルシューティング、バグ修正を行う。 サイクル完了後は、AWS 社内でセキュリティレビューを行い品質を保った状態のソースコード一式および「Path to Production（本番環境への移行ガイド）」を含むプロトタイプアセットをお客様にハンドオーバーします。 作成したプロトタイプについて 作成したプロトタイプ（DietSearch）は、想定問答における答弁案の初稿ドラフト案の生成と、その修正プロセスにおける審査を支援する AI アプリケーションです。組織が持つ過去の想定問答ファイルを検索し、文脈に即して初稿ドラフト案を作成し、その際に参照した過去の想定問答を、その類似度や関連性に応じてソートして表示することで審査を支援します。主な機能について、より詳しくは以下のとおりです。 文書のナレッジベース化 ：組織が保有する過去の想定問答ファイルをセキュアな環境にアップロードすると、関連するメタデータを生成・付与することができ、検索可能なナレッジベースを構築できます。 メタデータの生成部分のカスタマイズ機能 ：ユーザーが事前に定義したルールがシステム内で自動的に適用され、各文書に対してリッチで文脈豊かなメタデータが生成されます。（このメタデータにより、検索時の関連度合いや検索精度が飛躍的に向上します。）ルールの定義は UI 上で完全にカスタマイズ可能で、組み込みの AI アシスタントのサポートによりルールロジックの改善や拡張が容易に行えます。 例１：文書のファイルパスから年月、日時の情報をメタデータとして抽出 例２：文書情報やプロパティから構造化された洞察を導出 ドラフト生成 ：入力された質問に対して、LLM による検索でヒットした文書をコンテキストとして参照し、 AI が答弁の初稿ドラフト案を作成します。ドラフトの各パラグラフには参照した過去の想定問答ファイルが紐づくため、過去の答弁案での記載を確認しながら加筆・修正できます。 過去の想定問答ファイルの横断検索（ハイブリッド検索） ：修正後の答弁案に対して、改めて過去の類似する内容を含む想定問答ファイルを検索できます。過去答弁の検索には、ベクトル検索と全文検索を組み合わせたハイブリッド検索を採用。リランキングと日本語処理を組み合わせて、高い精度の検索を実現しています。 答弁案審査支援 ：作成・修正された答弁案に対して、過去の想定問答との類似性を検証し、関連性の高い箇所をハイライト表示します。レビュー者は過去の類似のケースでどのように説明していたかを示す文書を並べて確認しながら、効率的にチェックできます。 国会会議録検索システムとの連携 ：公開されている 国会会議録検索システム API と連携し、議事録を取得することで、検索結果として表示された組織内の過去の想定問答について、対応する日付の該当委員会において、実際にどのような発言があったか、あるいはなかったかを確認できるようになっています(LLM によってマッチしているかを段落ごとで判別しハイライトし可視化）。 また、利用者のフィードバックを起点に使いやすさと運用性にもこだわりました。検索結果と答弁案を左右に並べて比較できる UI、議事録原文のプレビュー、検索条件のフィルタリング、作業状況の他ユーザーへの共有、ロールベースのアクセス制御（既存の認証システムとの連携）、少ない操作でのファイルアップロードと同期を実現する機能などを備えています。 アプリイメージ図 アーキテクチャと採用サービス DietSearch は AWS のサーバーレス構成を基本とし、運用負荷やコストを抑えながらスケールできるよう設計しています。 フロントエンド配信 ：Amazon CloudFront + Amazon S3、AWS WAF による保護 認証・認可 ：Amazon Cognito (Identity Pool) によるロールベースアクセス制御(管理者／一般利用者) Amazon Cognito (User Pool) と Azure Entra ID との SAML 連携による認証部分の繋ぎ込みも行い、現場の既存の認証システムでのアプリの使用を可能にしました。 API ：AWS Lambda (Function URL, TypeScript・Hono を利用） 検索・生成 ：Amazon Bedrock Knowledge Bases を基盤とし、埋め込みモデルに Amazon Titan Text Embeddings V2、推論モデルに Claude 等を選択可能、セーフガードに Amazon Bedrock Guardrails を採用 ベクトルストア ：Amazon Aurora Serverless v2 (PostgreSQL + pgvector) または Amazon OpenSearch Serverless を要件に応じて選択可能 データ管理 ：Amazon S3 (文書データソース)、Amazon DynamoDB (データ管理) セキュリティ・運用 ：AWS KMS による暗号化、Amazon CloudWatch によるモニタリング インフラはすべて IaC ( SST / Pulumi ) で管理し、セキュリティやコンプライアンスの観点からPulumi Policy Pack によるインフラ検証をデプロイ前のチェックに組み込んでいます。以下に DietSearch のシステム構成図を示します。 アーキテクチャ図 お客様の評価と今後の展望 担当部局の方々から以下のコメントを頂戴しております。 担当部局管理職より 本プロジェクトは、数か月という短期間で、構想段階からプロトタイプのリリースまでを進めることができた貴重な取組となりました。 初期的な要望に合わせて作成いただいたアプリケーションを、実際にユーザーとなり得る職員が試用し、その過程で判明した追加要望や課題を短いサイクルで設計や機能改善に反映いただけたことで、効率的にプロトタイプをブラッシュアップしていくプロセスを実践できました。 また、デプロイ作業や非機能要件に関する検討、課題対応の過程においても、AWSプロトタイピングチームから緊密なコミュニケーションをいただけたことは、アプリケーションの構成や運用方法に加え、インフラ環境に対する理解を深めることにもつながりました。 本プロジェクトを通じて、他の分野も含む今後のシステム開発の進め方について、多くの示唆が得られたと考えています。 担当部局職員より 本システムの構築にあたっては、AWS社との間で何度もフィードバックを重ねる機会を得ることができ、その結果、当組織の業務実態に即した、非常に使い勝手の良いアプリケーションを実現することができました。 一般に、官公庁におけるシステム構築ではウォーターフォール型の開発が主流であり、完成後に想定と異なる操作性となるケースも少なくありません。これに対し、本取組においてはアジャイル型の開発手法を採用したことで、利用者のニーズを反映した改善を随時行うことが可能となり、結果として業務効率化に大きく寄与するアプリケーションを構築するに至りました。 実際に組織内に部分的に展開したところ、「作成される初稿ドラフトの質が想像よりも高かった」「ファイルを自分で開いて確認する手間や国会議事録検索システムを検索する手間が減り、作業が早くなる」など、好評をいただいております。 当該省庁では、2026 年の秋から本格導入を目指し、準備を進めています。あわせて、本ソリューションは中央省庁にとどまらず、他の省庁や地方自治体での展開可能性も期待されています。AWS は引き続き、パートナーとともに本番運用に向けた支援を継続してまいります。 まとめ 「まず動かして確かめる」というプロトタイピングのアプローチは、 AI のように実際に動かしてみなければ効果を判断しにくい領域で、本格導入の判断材料を得るために特に有効です。AWS のパブリックセクター プロトタイピングチームは、公共のお客様のアイデアを短期間で形にし、次の意思決定を後押しします。同様の検討をされている方は、ぜひお近くの AWS 担当者にご相談、または次のメールアドレスにご連絡ください。 aws-jpps-prototyping@amazon.com 著者について Shota Kishimoto – Associate Prototyping Solutions Architect, AWS (プロトタイプチーム） Jorge Lanzarotti – Sr. Prototyping Solutions Architect, AWS (プロトタイプチーム） Hiromichi Miyawaki – Account Executive, Central Government, AWS (アカウントチーム） Naoki Miyaguchi – Solutions Architect, Central Government, AWS (アカウントチーム）