本記事は、Kiroween 2026 の公式ページ「 Kiroween 2026 」（Devpost、英語）と「 Official Rules 」の内容を、2026 年 10 月 31 日時点の情報で日本語にまとめたものです。参加条件や日程の正式な内容は英語の公式ページに従います。各節の原文は、下の表のページで読めます。 この記事の節 原文（英語） 誰が参加できるか Official Rules の「3. Eligibility」 日程 Schedule 、Official Rules の「1. Dates and Timing」 何を作るか、提出するもの Overview の「Requirements」、Official Rules の「4. How To Enter」 賞 Overview の「Prizes」、Official Rules の「8. Prizes」 審査 Overview の「Judging Criteria」、Official Rules の「6. Judges & Criteria」 始めるまでの準備 Resources 、 FAQ Kiro が毎年ハロウィンの時期に開いているハッカソン Kiroween が、今年も始まりました。作品づくりと提出の受付は日本時間 2026 年 10 月 31 日（土）午前 1 時に始まっていて、締め切りは日本時間 12 月 5 日（土）午前 7 時です。オンラインで参加でき、賞金の総額は 10 万ドルです。10 月 31 日の時点で 2,882 人が参加登録しています。 昨年の Kiroween では、数千人の開発者が Kiro を使い、廃れた技術をよみがえらせたり、意外な技術を組み合わせたりした作品を作りました（昨年の告知は「 これが Kiroween です 」）。今年は Kiro IDE、Kiro CLI、Kiro Web に加えて、Kiro Crew も使えます。 誰が参加できるか 居住地で成年に達している個人、3 人までのチーム、法人や団体が参加できます。参加できない国・地域の一覧に日本は含まれていません。個人として参加しながら、別のチームに加わることもできます。 Kiro の一部の機能や AI モデルは地域によって使えないことがあり、自分の地域で使えるかどうかは参加者の責任で確かめることになっています。 日程 公式ページの時刻は米国太平洋時間です。米国の夏時間が 11 月 1 日に終わるため、日本との時差は 10 月中が 16 時間、11 月以降が 17 時間です。 項目 米国太平洋時間 日本時間 参加登録の開始 2026 年 10 月 13 日 8:30 2026 年 10 月 14 日 0:30 作品づくりと提出の開始 10 月 30 日 9:00 10 月 31 日 1:00 Devpost Build Session 11 月 11 日 10:00 11 月 12 日 3:00 無料の Kiro クレジットの申請締め切り 12 月 1 日 12:00 12 月 2 日 5:00 登録と提出の締め切り 12 月 4 日 14:00 12 月 5 日 7:00 審査期間 12 月 16 日 13:00〜2027 年 1 月 29 日 13:00 12 月 17 日 6:00〜2027 年 1 月 30 日 6:00 結果発表 2027 年 2 月 3 日 9:00 ごろ 2027 年 2 月 4 日 2:00 ごろ 締め切りの延長はなく、締め切り後の提出は受け付けられません。 何を作るか Kiro（IDE、CLI、Web、Kiro Crew のどれか、または組み合わせ）を使って動くソフトウェアを作り、次の 4 つのカテゴリーから 1 つを選んで提出します。カテゴリーは昨年と同じで、1 つの作品が入れるカテゴリーは 1 つだけです。 Resurrection（復活）：お気に入りの廃れた技術をよみがえらせます。古くなった技術を今の技術で作り直すか、これからの課題を解くものにします。 Frankenstein（フランケンシュタイン）：ふつうは組み合わせない技術をつなぎ合わせて 1 つのアプリにし、思いがけない力を引き出します。 Skeleton Crew（スケルトンクルー）：分かりやすさを保てるほど小さく、いろいろな用途に使えるほど柔軟なコードの骨組み（テンプレート）を作ります。その骨組みから作った 2 つの別々のアプリで、使い道の広さを示します。 Costume Contest（コスチュームコンテスト）：どんなアプリでも構いませんが、作り込まれた、忘れられないほど不気味なユーザーインターフェースを見せます。不気味なデザインは、アプリの機能を引き立てるものにします。 作品は提出期間（米国時間 10 月 30 日〜12 月 4 日）に新しく作ったものに限ります。10 月 30 日より前に作り始めたものは、Kiroween 2025 の作品も含めて対象外です。フレームワーク、ライブラリ、スターターテンプレートは使えますが、それ以外に以前からあったコードを取り込んだ場合は申告します。Kiro の使い方が足りないと審査員が判断した作品は、失格になることがあります。 提出するもの GitHub の公開リポジトリの URL。GitLab と Bitbucket は使えません。作品を動かすのに必要なソースコード、素材、手順をすべて入れ、リポジトリの画面の About 欄に表示されるようにオープンソースライセンスのファイルを置きます。ルートには、スペック、フック、ステアリングを使ったことを示す /.kiro ディレクトリを置き、 .gitignore に入れないようにします（入れると失格になることがあります）。Skeleton Crew では、2 つのアプリを別々のフォルダーに置きます。 動いているアプリの URL。ログインが必要なら、審査員向けの認証情報と手順を提出フォームに書きます。この欄は公開されず、審査員だけが見ます。 機能を説明する文章。 デモ動画。3 分未満にし（審査員は 3 分を超えた部分を見るとは限りません）、作った端末の上で作品が動く様子を映して、YouTube に公開します。許可を得ていない第三者の商標や、著作権のある音楽などは入れません。 Kiro をどう使ったかの説明。Kiro をどれだけうまく使って作ったかが、審査員に分かるように書きます。 5 つ目の説明に書く内容として、公式ページは次の例を挙げています。 Kiro IDE、CLI、Web、Crew のうち何を使ったか。複数使ったなら、どう違ったか カスタムエージェントを作ったか、使ったか。どの Kiro で試し、作業にどう効いたか エージェントフック でどの作業を自動化し、開発の進め方がどう良くなったか スペック駆動開発 で、Kiro に実装させるスペックをどう組み立てたか。バイブコーディングと比べてどうだったか ステアリング で Kiro の応答をどう良くしたか。いちばん効いたやり方は何か MCP で Kiro の機能を広げたことが、作品づくりにどう役立ったか。MCP がなければ難しかったことは何か プロパティベーステスト（PBT） で、ユニットテストでは見逃したかもしれない問題が見つかったか。どの要件に PBT を使ったか Kiro powers のどれを使ったか。powers がなければ使わなかった外部のツールや連携はあったか 提出物は英語で用意します。英語以外で作った場合は、デモ動画、説明文、テスト手順を含め、提出物すべての英訳を付けます。 賞 賞金の総額は 10 万ドルです。1 つの作品が受け取れるのは、総合賞かカテゴリー賞のどちらか 1 つです。ボーナス賞は、条件を満たせばいくつでも受け取れます。 賞 賞品 数 総合 1 位 30,000 ドル 1 総合 2 位 20,000 ドル 1 総合 3 位 10,000 ドル 1 Best Resurrection、Best Frankenstein、Best Skeleton Crew、Best Costume Contest（カテゴリー賞） 各 5,000 ドル 各 1 ボーナス賞は次のとおりです。応募するボーナス賞は提出フォームで選びます。 賞 賞品 数 条件と選び方 Best Startup Project 10,000 ドル 1 スタートアップの創業者であること。LinkedIn のプロフィールとスタートアップの Web サイトを提出します。 Best Ghost of Kiroween Past 2,000 ドル 1 Kiroween 2025 に参加登録していたこと。昨年の記録と照らし合わせて確かめられます。作品は今年新しく作ったものに限ります。 Best Kiro Crew App 1,000 ドル 1 今回作った Kiro Crew のアプリの GitHub リポジトリと、機能の説明を提出します。アプリのリポジトリを付けた作品のうち点数の上位 50 件から、Kiro チームが役立ち度と技術の新しさで選びます。 Best Student Project（4 つのカテゴリーごと） 各 1,500 ドルと Kiro Pro Max 1 年分 各 1 チーム全員が学生であること。全員分の LinkedIn のプロフィール、学生用のメールアドレス、学年と学位、学校名を提出します。在学の証明を求められることがあります。 Best Demo 1,000 ドル 1 手続きは要りません。総合点で上位 10% に入った作品のうち、審査の観点 Presentation の点数がいちばん高い作品が選ばれます。 Bonus Blog Prize 2,000 Kiro クレジット 100 提出期間中に、Kiro と作品についての記事を外部のブログサービスで公開します。Kiroween 2026 のために書いた記事であることを本文に明記します。記事の URL を提出し、条件を満たした作品のうち点数の上位 100 件が選ばれます。 Social Blitz Prize Kiro Pro+ 3 か月分 5 提出期間中に、先頭に #KiroweenHackathon26 を付けて SNS に投稿し、Kiro のいちばん好きなところと、それで開発の進め方がどう変わったかを書きます。投稿の URL を提出します。Kiro チームが、自分の言葉で書いているか、Kiro についての気づきがあるか、画像や動画の質を見て 5 件を選びます。 Kiro Crew のアプリは、Crew の中で動き、ダッシュボードの画面、エージェント、スキル、MCP サーバー、定期実行の処理などを追加できるものです。作り方は Kiro のドキュメントの「 Apps 」に、Kiro Crew そのものは「 Kiro Crew の紹介 」にまとまっています。 審査 審査は 2 段階です。1 段階目では、テーマに合っているか、Kiro を使っているかを合否で判定します。通った作品は 2 段階目で、次の 5 つの観点からそれぞれ 10 点満点で採点されます（配点は各 20%）。 観点 見られること Potential Impact 実在する利用者の実際の課題を解くと、説得力をもって示せているか。デモで見せた内容がその課題に応えているか。役に立ち、分かりやすく、誰でも使えるか。実際に使われそうか Technological Implementation Kiro をどれだけ深く、うまく使ったか。AI を使った開発の進め方を考えて決めたか。Kiro のいろいろな機能を効果的に使い、試行錯誤しているか Design 技術の試作で終わらず、まとまった製品として体験できるか。デザインが分かりやすく、作り込まれ、意図をもって作られているか Innovation/Idea 発想が独創的で、既存のものと違うか。珍しい技術や公開データセットなどを独自に組み合わせているか Presentation 動画で作品が最初から最後まで動く様子を示せているか。何の課題を、誰のために、なぜ解くのかが伝わるか。分かりやすく、記憶に残るか 昨年からの主な違い 対象の Kiro として Kiro Crew が追加、Kiro Crew のアプリを対象にした Best Kiro Crew App ができました。 審査の観点が、昨年の Potential Value、Implementation、Quality and Design の 3 つから 5 つになりました。Innovation/Idea と Presentation が別の観点になり、動画とピッチの出来も全体の 20% として採点されます。 Best Ghost of Kiroween Past、Best Student Project、Best Demo が新しくでき、昨年の Most Creative と Influencer Judges’ Choice はなくなりました。 Bonus Blog Prize は昨年の 100 ドル × 50 件から 2,000 Kiro クレジット × 100 件に、Social Blitz Prize は 100 ドル × 5 件から Kiro Pro+ 3 か月分 × 5 件に変わりました。 リポジトリは GitHub の公開リポジトリに限られました。 始めるまでの準備 公式ページ の「Join hackathon」から参加登録します。無料の Devpost アカウントが必要です。 Official Rules を、作り始める前に読みます。 無料の Kiro クレジット 4,000 を申請します。申請は Resources タブにあるフォームから、米国時間 12 月 1 日 12:00（日本時間 12 月 2 日 5:00）までです。Kiro のアカウントと Kiro のユーザー ID（AWS アカウントで使っている場合は AWS アカウント ID）が要ります。クレジットのコードは審査のうえ 48 営業時間以内に届きます。コードは米国時間 12 月 4 日までに引き換え、引き換えたクレジットは米国時間 12 月 31 日 23:59（日本時間 2027 年 1 月 1 日 16:59）に失効します。もらえるのは参加者 1 人につき 1 回で、追加はありません。 Kiro の Discord の #kiroween-hackathon チャンネルで、Kiro チーム、Kiro アンバサダー、ほかの参加者に質問できます。米国時間の隔週月曜 9:30（日本時間では火曜 2:30）には、Kiro チームのオフィスアワーもあります。 米国時間 11 月 11 日 10:00（日本時間 11 月 12 日 3:00）の Devpost Build Session では、Kiro での始め方が紹介されます。10 月 31 日の時点では、申し込みの受付はまだ始まっていません。 チームで出る場合は、Participants タブで仲間を探せます。チームは 3 人までで、代表者 1 人がチームとして提出します。 提出フォームの「Enter a Submission」は早めに開いて、下書きをこまめに保存します。締め切り後は提出内容を編集できません。 作品の発想に迷ったら、 Kiroween 2025 の作品ギャラリー で昨年の作品を見られます。登録と提出は Kiroween 2026 の公式ページ から行い、締め切りは日本時間 12 月 5 日（土）午前 7 時です。 著者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

本投稿は、2026年 10 月 16 日に公開された、 Know Before You Go: your re:Invent 2026 guide to managing cloud and AI spend を翻訳したものです。 世界が AI を大規模に取り入れつつある今、IT 支出を管理する皆さんは新たな難題に直面しています。これまでの クラウド財務管理 (CFM) の時代では、IT とファイナンスのリーダーにクラウドと財務の両方の言葉を理解できることが求められていましたが、AI の時代にはトークン（この言葉をご存知でしょうか？）をはじめとする新たな用語やコストの切り口が加わります。総所有コスト (TCO) をようやく把握できたと思った矢先に、それは AI の総コスト (TCA) へと広がりました。この新しい環境では、投資を正当化するために組織が必要とするコストの追跡可能性とコントロールを実現できるよう、 コスト管理のあり方を見直すことが求められます。 今年の re:Invent では、AI コスト管理の最新のフレームワーク、ソリューション、そして実際の成功事例をしっかりおさえていただけるよう、素晴らしいセッションを数多く用意しました。これらのセッションは、トークノミクスといった概念を理解し、AI コスト管理で一歩先を行くための助けになります。各トラックを横断して、30 を超えるクラウド財務管理と AI コスト管理に関するセッションが揃っています。本ブログ記事では、そのうち 9 つを取り上げ、会期中に AWS の FinOps のエキスパートや同じ課題を持つ仲間に会える場所をご紹介します。 3 つのテーマ セッションの詳細に入る前に、さまざまなセッションを通して織り込まれている 3 つのテーマを紹介します。 AI コストに対するネイティブな可視性とコントロール (FinOps for AI) : AI の採用が加速する中で、財務面のコントロールを失うことなくスケールできるよう、AI支出を詳細に把握できるようにしたいと考えています。 FinOps の基礎を極める : きめ細かなコスト配分、より精度の高い予測、そしてカスタムベネフィットの共有により、すべての支出が可視化され、計画され、意図を持って共有される状態を実現します。 AI for FinOps : AI を FinOps チームのために働かせることで、ビジネス上の重要なタスクに集中し、既存のクラウド支出と新たに生じるAIコストの双方の管理にかける時間を減らせます。 最新情報のキャッチアップ (ブレイクアウトセッション) COP209: Manage Cloud Costs and AI Spend with AWS Cost Management 12月1日(火) | 14:30〜15:30 PST | MGM Grand | Level 3 | Premier 318 毎年恒例の新機能発表ブレイクアウトセッションです。AI がチームのクラウドコスト管理をより効果的にする方法 (「AI for FinOps」) と、AI 自体のコストを管理する方法 (「FinOps for AI」) を取り上げます。AVIV Group が登壇し、（彼らの）実体験から得られた学びを共有します。 スピーカー: Bowen Wang (Principal PM Outbound, AWS)、Matt Berk (Principal TAM, AWS)、 Jordi Espasa (FinOps Director, AVIV Group) COP201: Accelerating Cost Optimization on AWS 12月3日(木) | 8:30〜9:30 PST | Venetian | Level 2 | Ballroom F | Content Hub コスト最適化の機会を持続的に発見して実行し、成果を測定し、削減額を組織全体に分配する方法を学びます。 スピーカー: Jimmy Yang (Principal PM, AWS)、Mary Nachimov (Sr. Technical PM, AWS) ハンズオンで学ぶ (Codeトーク、ワークショップ、Builders’セッション) Codeトーク COP403: Optimize AI Apps on Amazon Bedrock for Cost, Latency, and Control 11月30日(月) | 11:30〜12:30 PST | Wynn/Encore | Upper Convention Promenade | Cristal 2 リピート開催: 12月2日(水) | 8:30〜9:30 PST | Wynn/Encore | Upper Convention Promenade | Cristal 2 本番環境の AI アプリケーション向けの高度な最適化手法 (プロンプトエンジニアリング、モデル選定、コンテキストウィンドウ管理など) を扱うライブコーディングセッションです。それぞれの設計判断がコストに与える直接的な影響を、 AWS Billing and Cost Management 上で確認します。 スピーカー : Andy Brown (Sr. Manager, FinOps, AWS)、Steph Gooch (Principal Tech Advocate, AWS) ワークショップ COP324: AI-Powered FinOps: Cloud Cost Optimization in Practice 11月30日(月) | 8:30〜10:30 PST | Wynn/Encore | Upper Convention Promenade | Cristal 7 リピート開催: 12月2日(水) | 15:30〜17:30 PST | MGM Grand | Level 1 | Grand 124 AI を活用したコスト最適化により、FinOps を運用上の規律として定着させます。最適化の自動化、ライトサイジング、AI/MLおよびコンテナワークロードのコスト配分、マルチクラウドレポーティング、AI による支出分析をハンズオンで体験します。*ノート PC が必要です。 スピーカー : Rupesh Lunia (Principal PM, AWS)、Enrico Bonaccorsi (Principal TAM, AWS) Builders’セッション COP311: FinOps for AI: Cost Allocation Strategies for Amazon Bedrock 12月2日(水) | 16:30〜17:30 PST | Wynn/Encore | Convention Promenade | Latour 7 リピート開催: 12月3日(木) | 10:30〜11:30 PST | Wynn/Encore | Convention Promenade | Latour 7 Amazon Bedrock 向けの最新のコスト管理機能をハンズオンで体験します。API 呼び出しにタグを付けてきめ細かくコストを紐付け、予算を設定して AI 支出を制御し、発生するコストをその都度追跡します。さらに、CUR 2.0 の新しい製品メタデータをクエリし、100 万トークンあたりのコストの推移を CUDOS で可視化します。 スピーカー: Yuriy Prykhodko (Principal Technologist, AWS)、Judith Lehner (Principal TAM, AWS)、Brenno Passanha (Sr. TAM, AWS)、Ariel Fu (Sr. PM-Tech, AWS)、Eric Christensen (Sr. TAM, AWS) COP312: Embed FinOps into Your CI/CD Pipelines 11月30日(月) | 13:30〜14:30 PST | Caesars Forum | Level 1 | Forum 120 | Content Hub リピート開催: 12月3日(木) | 10:30〜11:30 PST | Caesars Forum | Level 1 | Forum 120 | Content Hub 実際に動作するコスト見積もりゲートを CI/CD パイプラインに直接組み込みます。プルリクエストの時点でインフラコストへの影響を評価し、デプロイ前に支出のしきい値を強制します。*ノート PC が必要です。 スピーカー : Fredrik Tunvall (Sr. PM, AWS)、Jenny Shen (SA, AWS)、Travis James (Sr. Optimization SA, AWS)、Hicham Lahlal (Sr. Cloud FinOps Architect, AWS)、Shubho Laga (Sr. TAM, EMEA) エキスパートや仲間と学ぶ (チョークトークとライトニングトーク) チョークトーク COP328: Building a Cost Governance Framework That Scales 12月2日(水) | 16:30〜17:30 PST | MGM Grand | Level 1 | Boulevard 165 リピート開催: 12月3日(木) | 13:00〜14:00 PST | MGM Grand | Level 3 | Premier 311 コストデータの整理、予算のガードレール設定、支出の配分、組織全体での可視性の確立について、AWS FinOps Agent を取り上げながら、インタラクティブなディスカッションとホワイトボードを使ったアプローチで進めます。現在抱えている FinOps の課題をお持ちください。 スピーカー : Adam Richter (Sr. Optimization SA, AWS)、Jason Wu (Sr. Technical PM, AWS) COP329: Automate Savings with AWS Billing and Cost Management Services 12月2日(水) | 16:30〜17:30 PST | MGM Grand | Level 3 | Room 353 リピート開催: 12月3日(木) | 12:00〜13:00 PST | Wynn/Encore | Convention Promenade | La Tache 2 コミットメントの購入やライトサイジングによる最適化をビジネス目標に整合させるアプローチと、継続的なコスト最適化の取り組みに自動化を組み込む方法について議論します。 スピーカー : Savanna Jensen (Sr. Cloud FinOps Architect, AWS)、Haritha Chitalia (Cloud FinOps Architect, AWS) ライトニングトーク COP348: Monitor and Optimize Costs for Amazon Bedrock 11月30日(月) | 17:30〜18:30 PST | Venetian | Level 2 | Hall B | Expo | Global Impact Theatre Amazon Bedrock のコスト監視と最適化に役立つ実践的なヒントを、短時間で押さえるセッションです。軽めながら、re:Invent の1週間を始めるうえで欠かせない内容です。 スピーカー : Adam Richter (Sr. Optimization SA, AWS) 今年復活: CFM キオスクへお立ち寄りください re:Invent 2026 では、CFM 専用キオスクが帰ってきます。1 年のブランクを経て、ふらっと立ち寄って質問したり、製品のライブデモ ( AWS FinOps Agent やその他の新機能を含む)を見たり、CFM のプロダクトマネージャーやエキスパートと直接話したりできる場として、会期中ずっとオープンします。ご自身のコストに関する課題をお持ちいただき、私たちのチームと一緒に解決策を探しましょう。予約は不要です。お気軽にお立ち寄りください。 キオスク担当 : Larry Im (Sr. SA, AWS)、Koushik Das (Sr. TAM, AWS)、Sean Falconer (Sr. SA, AWS)。CFM のプロダクトマネージャーや現場のエキスパートも、ご質問に備えて待機しています。 FinOps コミュニティとつながる FinOps Foundation は、今年は Tokenomics Foundation および FOCUS チームも加わり、re:Inventでコミュニティイベントを開催するという恒例の取り組みを継続します。今年は 12 月 1 日(火)、Rock House にて午前から昼にかけてのプログラムが予定されています。朝の基調講演のウォッチパーティーで一日を始め、ネットワーキングランチで FinOps 仲間と交流しましょう。お申し込みは こちら から。 ご都合がつかない場合もご心配なく。FinOps Foundation のチームは火曜の夕方近くに AWS CFM チームとともにキオスクに参加し、FOCUS、トークノミクス、そして FinOps コミュニティのより広範な取り組みについて引き続き会話できる場を設けます。 計画のTips 早めに登録してください – セッションには定員があり、人気のあるものはすぐに埋まります 会場間の移動のために、セッションの間にバッファ時間を確保してください – ラスベガスのホテル間の距離は、見た目以上に離れていることがあります。 セッションのレベルを考慮して計画を立ててください – セッション ID で判断できます。例えば、COP209 は 200 レベルのセッション、COP403 は 400 レベルのセッションです。 リピート開催を確認してください – 今年はいくつかのセッションが 2 回実施されるため、第一希望が重複した場合でももう一度チャンスがあります。 水曜の午後は注意してください – COP311、COP328、COP329 はすべて同じ時刻に始まり、COP324 のリピート開催はその 3 つすべてと重なります。複数参加したい場合は、木曜のリピート開催を利用してください。 スケジュール一覧 日時 セッション 場所 11月30日(月) 8:30-10:30AM COP324 ワークショップ: AI-Powered FinOps Wynn/Encore, Cristal 7 11:30 AM–12:30 PM COP403 Codeトーク: Optimize AI Apps on Bedrock Wynn/Encore, Cristal 2 1:30–2:30 PM COP312 Builders’セッション: FinOps in CI/CD Caesars Forum, Forum 120 5:30–6:30 PM COP348 ライトニングトーク: Bedrock Cost Monitoring Venetian, Expo Hall, Global Impact Theatre 12月1日(火) Morning to midday FinOps Foundation コミュニティイベント Rockhouse 2:30–3:30 PM COP209 ブレイクアウト: Manage cloud and AI Spend MGM Grand, Premier 318 4:30-6PM FinOps Foundation がキオスクでAWS CFM チームに合流 CFM kiosk, Expo Hall 12月2日(水) 8:30–9:30 AM COP403 Codeトーク (リピート) Wynn/Encore, Cristal 2 3:30–5:30 PM COP324 ワークショップ (リピート) MGM Grand, Grand 124 4:30–5:30 PM COP311 Builders’セッション: Bedrock Cost Allocation Wynn/Encore, Latour 7 4:30–5:30 PM COP328 チョークトーク: Cost Governance Framework MGM Grand, Boulevard 165 4:30–5:30 PM COP329 チョークトーク: Automate Savings MGM Grand, Room 353 12月3日(木) 8:30–9:30 AM COP201 ブレイクアウト: Accelerating Cost Optimization Venetian, Ballroom F 10:30–11:30 AM COP311 Builders’セッション (リピート) Wynn/Encore, Latour 7 10:30–11:30 AM COP312 Builders’セッション (リピート) Caesars Forum, Forum 120 12:00–1:00 PM COP329 チョークトーク (リピート) Wynn/Encore, La Tache 2 1:00–2:00 PM COP328 チョークトーク (リピート) MGM Grand, Premier 311 この記事に記載されているセッションの日時と場所は、セッションの人気度と会場の収容人数に基づいてスケジュールを最適化し続けているため、変更される可能性があります。登録済みのセッションに関する最新情報については、 re:Invent のセッションカタログ を定期的にご確認ください。 re:Invent 2026 でお会いできることを楽しみにしています！ Bowen Wang Bowenは、AWS請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウド財務管理を最適化する方法をより良く理解できるよう支援することに注力しています。以前のキャリアでは、テクノロジースタートアップの中国市場参入を支援していました。 本記事の翻訳はテクニカルアカウントマネージャーの 鍛治田 が担当しました。

G-gen の杉村です。Google Cloud の Agent Platform において、Agent Runtime と Agent Gateway を使用して自己署名証明書が適用されたプライベート API エンドポイントにアクセスするためのアーキテクチャと構築手順について解説します。 はじめに 当記事の背景と目的 前提とする環境と情報 アーキテクチャと通信フロー 全体アーキテクチャ 通信と TLS 検証の流れ 設計・設定のポイント 自己署名証明書の X.509 要件 TrustConfig の定義 Agent Connectivity Template での TLS 統合 Cloud DNS プライベートゾーンと DNS Peering Terraform によるインフラ構築 自己署名証明書と TrustConfig ネットワーク関連リソースと Agent Gateway IAP 認可ポリシー（AuthzPolicy）の設定 Cloud DNS と IAM 権限の設定 API サーバー（Nginx）の設定 エージェント実装 ADK エージェントの定義 Agent Runtime へのデプロイスクリプト 動作検証 踏み台 VM からの直接導通確認 エージェントからのプライベート API 呼び出し Agent Gateway のログ確認 VPC フローログの確認 リソース削除時の依存関係 証明書の更新・追加 証明書を直接登録する場合 プライベートルート CA を登録する場合 はじめに 当記事の背景と目的 エンタープライズの Google Cloud 環境で AI エージェントを運用する場合、以下のようなサービスが使用されます。 サービス名 概要 当社解説記事 Agent Runtime フルマネージドの AI エージェント稼働基盤 Gemini Enterprise Agent PlatformのAgent Runtimeを徹底解説 Agent Gateway AI エージェントから外部への通信を制御する機能 Agent Gatewayを徹底解説！ Agent Registry AI エージェントや MCP サーバー、API エンドポイントを登録し、カタログ化するフルマネージドサービス Agent Registryを徹底解説！ AI エージェントをフルマネージド基盤である Agent Runtime で稼働させ、AI エージェントへの Ingress / Egress 通信を Agent Gateway で制御することで、小さい運用負荷でセキュアに AI エージェントを運用できます。 エンタープライズ環境では、エージェントがアクセスする対象はパブリックな Web API だけとは限りません。VPC ネットワーク内やオンプレミス、他のパブリッククラウド基盤等にホストされた、社内 MCP サーバーやデータベース連携用 API など、プライベートなエンドポイントと通信させる要件が発生します。 Agent Runtime で稼働する AI エージェントから、VPC ネットワークやそれに接続されたネットワーク上のリソースへプライベートにアクセスする手段として、Private Service Connect（以下、 PSC ）インターフェースが提供されています。これを使用することで、Agent Runtime 上の AI エージェントから、企業内のプライベートな API エンドポイントへの接続が可能です。 また、Agent Gateway を使うと、エージェントは許可された通信先にしか通信できなくなります。これにより、悪意のある API エンドポイントに企業データを送信するなどのリスクを未然に防止できます。Agent Gateway でエージェントの通信を統制する場合、許可する接続先の API エンドポイントは Agent Registry に登録する必要があります。なお登録する API エンドポイントは HTTPS プロトコルを受けつける必要があります。非暗号化の HTTP プロトコルのエンドポイントは、登録できない仕様です。 開発環境や社内閉域網内のプライベート API サーバーでは、パブリック CA（認証局）が発行した証明書ではなく、 自己署名証明書 （いわゆるオレオレ証明書）や組織内部のプライベート CA で発行された証明書が使用されているケースが多く見られます。Agent Gateway は、 デフォルトではパブリックな認証局のみを信頼 するため、自己署名証明書への通信では TLS ハンドシェイク時に証明書検証エラーが発生し、通信が遮断されてしまいます。 当記事では、Certificate Manager の TrustConfig を適切に設定し、Agent Gateway で自己署名証明書を正しく信頼・検証してプライベート API に接続するための構成と、Terraform によるインフラ定義・ADK エージェントの実装手順を解説します。 参考 : Route Agent Runtime traffic through Agent Gateway 参考 : Troubleshoot Agent Gateway connectivity - Self-signed or private CA destinations fail to connect 前提とする環境と情報 当記事で扱う内容は、2026年10月現在の Google Cloud 公式ドキュメントおよび Terraform Provider 仕様に基づいています。 当記事で取り上げる主な Google Cloud サービスおよびコンポーネントは以下の通りです。 Agent Runtime Agent Gateway Certificate Manager（TrustConfig） Cloud DNS Agent Development Kit（ADK 2.0） アーキテクチャと通信フロー 全体アーキテクチャ 当記事では、以下のような環境を構築して、Agent Gateway で自己署名証明書を使用した HTTPS エンドポイントに接続する構成を検証します。 Agent Gateway を経由したプライベート API 接続構成図 各コンポーネントの役割は以下の通りです。 コンポーネント 役割・機能 エージェント (Agent Runtime) ADK で開発した AI エージェント。Agent Gateway 経由で内部 API の呼び出しツールを実行 Agent Gateway エージェントからの送信トラフィック（Egress）を集約・制御するゲートウェイ TrustConfig (Certificate Manager) 自己署名証明書を信頼アンカー（Trust Anchor）として登録し、Agent Gateway による TLS 検証を成功させるための証明書設定 PSC Network Attachment Agent Gateway が顧客 VPC ネットワークへ Egress 通信を行うための PSC 接続ポイント Private Zone (Cloud DNS) VPC 内部の名前解決を行うゾーン。Agent Gateway との DNS Peering により、ホスト名（ api-server ）の IP 解決を可能にする API Server パブリック IP アドレスを持たない Compute Engine VM。自己署名証明書を用いた HTTPS API を提供 通信と TLS 検証の流れ エージェントが内部 API を呼び出す際の通信ステップは以下の通りです。 1. エージェントによるツール実行 AI エージェントがツールを使用してエンドポイント https://api-server/api に対して HTTPS リクエストを発行します。 2. Agent Gateway による Egress トラフィックの集約 エージェントからの送信トラフィックは、Agent Runtime にバインドされた Agent Gateway に集約されます。エージェント側で VPC 接続用の Network Attachment を個別に意識・指定する必要はなく、Agent Gateway をバインドするだけで VPC へのプライベートアクセスが可能です。 3. DNS Peering による内部名前解決 Agent Gateway は、Agent Connectivity Template に設定された DNS Peering 設定に基づき、VPC の Cloud DNS プライベートゾーン（ api-server. ）を参照して内部 IP アドレス（例: 10.146.0.59 ）を解決します。 4. PSC Network Attachment による VPC への Egress 転送 Agent Gateway は、解決された内部 IP に向けて、Agent Connectivity Template に紐付けられた PSC Network Attachment を経由して VPC ネットワークへの Egress 通信を確立します。 5. 認可ポリシー（AuthzPolicy）の評価 Agent Gateway にバインドされた IAP AuthzPolicy による認可チェック（当検証環境では監査ログ出力用の DRY_RUN モード）が行われます。 6. TrustConfig による TLS 証明書検証 Agent Gateway は対象サーバーとの間で TLS ハンドシェイクを開始します。サーバーから提示された自己署名証明書は、Certificate Manager の TrustConfig に登録された信頼アンカー（Trust Anchor）と照合されます。アンカーと一致すると、証明書チェーンの検証が正常にパスします。 7. レスポンス返却 リクエストが API サーバーに転送されます。API サーバーからのレスポンス（HTTP 200）は Agent Gateway を通じてエージェントに返却されます。 設計・設定のポイント 自己署名証明書の X.509 要件 Certificate Manager の TrustConfig と呼ばれる設定では、証明書を信頼させるために、ルート CA を登録したり、オプションで中間証明書や個別の証明書を登録できます。 ルート CA を登録せずに個別の末端証明書を許可リストに登録することもできます。この方法はシンプルですが、証明書の有効期限切れに伴う再作成のたび、あるいは接続先サーバーが増えるたびに、Google Cloud 側の TrustConfig を都度更新・再デプロイする必要があります。 当記事では、運用の拡張性および将来的なプライベート CA 運用（後述）への移行を見据え、自己署名証明書側に CA 属性（ CA:TRUE ）を付与して trust_anchors に登録するアプローチを採用します。 TrustConfig の信頼アンカー（Trust Anchor）として自己署名証明書を登録する場合、その証明書が X.509 の仕様上、CA としての属性を持っている必要があります。通常の末端サーバー証明書をそのまま TrustConfig のアンカーに登録しても、CA 制約を満たしていない場合は検証に失敗します。そのため、自己署名証明書を生成する際は以下の拡張属性を付与します。 設定項目 値 Basic Constraints CA:TRUE （認証局であることを示すフラグ） Key Usage Certificate Sign （ cert_signing ）、 Digital Signature 、 Key Encipherment Subject Alternative Name (SAN) 接続先ホスト名（ api-server ）および内部 IP アドレス TrustConfig の定義 Certificate Manager の TrustConfig リソースはもともと、mTLS や Egress 通信時の TLS 検証において、Google Cloud のマネージドプロキシが信頼すべき証明書のルート CA や中間証明書、個別の証明書等を定義するリソースです。 参考 : Core components of Certificate Manager - Trust configs 当記事の実装例では構成をシンプルにするため、前述のとおり API サーバー自身が発行した自己署名証明書を、CA の性質も持たせたうえで直接登録します。 自前のプライベートルート CA 証明書を Trust Anchors に登録し、API サーバーにはその CA が署名した証明書を配置する、といった実践的な運用については、当記事末尾に後述します。 Agent Connectivity Template での TLS 統合 Agent Gateway にネットワーク関連設定を適用するための設定テンプレートである Agent Connectivity Template において、Egress 通信時の TLS 設定を定義します。 設定時の重要なパラメータは以下の2点です。 パラメータ名 値 trust_config 作成した Certificate Manager TrustConfig の完全なリソース ID を指定 additional_roots "PUBLICLY_TRUSTED_ROOTS" を指定。これにより、TrustConfig で定義したカスタム証明書に加えて、パブリックに信頼された一般的なルート証明書（Google Trust Services や Let's Encrypt 等）も引き続き信頼される 参考 : Set up VPC connectivity for Agent Gateway Cloud DNS プライベートゾーンと DNS Peering TLS 通信において、クライアントおよび Agent Gateway は、接続先ホスト名とサーバー証明書の Subject Alternative Name（SAN）が一致しているかを検証します。そのため、IP アドレスを直接指定するのではなく、ドメイン名（ホスト名）での接続が、原則として必須となります。 Agent Gateway から VPC 内部のホスト名を解決するためには、以下の設定が必要です。 VPC ネットワークに紐付けた Cloud DNS プライベートゾーン（例: api-server. ）を作成し、A レコードを登録 Agent Connectivity Template の dns_peering_config で対象ドメインとターゲット VPC ネットワークを指定 Agent Gateway のマネージドサービスアカウントに対して、プロジェクトレベルで DNS ピア（ roles/dns.peer ）ロールを付与 Terraform によるインフラ構築 自己署名証明書と TrustConfig 当記事では、Terraform を中心として各種設定とインフラ構築を行います。サンプルコードでは data.google_project など、事前に定義されていることが前提の値もあるため、実際の開発の際はこれらを随時、補足してください。当記事では中心的な要素のみを紹介します。 以下のコードでは、Terraform の tls プロバイダを使用して証明書を生成し、 google_certificate_manager_trust_config で信頼設定を行います。 # 1. 秘密鍵の生成 resource "tls_private_key" "api_server" { algorithm = "RSA" rsa_bits = 2048 } # 2. X.509 CA 制約を付与した自己署名証明書の生成 resource "tls_self_signed_cert" "api_server" { private_key_pem = tls_private_key.api_server.private_key_pem subject { common_name = "api-server" organization = "Internal API" } # 1年間有効 validity_period_hours = 8760 # TrustConfig の信頼アンカーとするため CA フラグを付与 is_ca_certificate = true allowed_uses = [ "key_encipherment" , "digital_signature" , "server_auth" , "cert_signing" , ] dns_names = [ "api-server" ] ip_addresses = [ var.api_server_internal_ip ] } # 3. Certificate Manager TrustConfig への登録 resource "google_certificate_manager_trust_config" "internal_api" { provider = google-beta name = "internal-api-trust-config" location = var.region description = "Trust config for internal API server self-signed certificate" trust_stores { trust_anchors { pem_certificate = tls_self_signed_cert.api_server.cert_pem } } } 参考 : Terraform - tls_private_key 参考 : Terraform - tls_self_signed_cert 参考 : Terraform - google_certificate_manager_trust_config ネットワーク関連リソースと Agent Gateway 次のコードでは、Network Attachment、DNS Peering、および TrustConfig を束ねる接続テンプレートを作成し、Agent Gateway に適用しています。 # 1. PSC Network Attachment resource "google_compute_network_attachment" "agent_attachment" { name = "agent-runtime-attachment" region = var.region subnetworks = [ "projects/$ { var.project_id } /regions/$ { var.region } /subnetworks/$ { var.subnetwork_name } " ] connection_preference = "ACCEPT_AUTOMATIC" } # 2. Agent Connectivity Template resource "google_network_services_agent_connectivity_template" "default" { provider = google-beta agent_connectivity_template_id = "agent-connectivity-template" location = var.region access_path = "AGENT_TO_ANYWHERE" egress_network_config { network_attachment = google_compute_network_attachment.agent_attachment.id vpc_egress = "PRIVATE_RANGES_ONLY" # VPC 内の Cloud DNS ゾーンに対する Peering dns_peering_config { domains = [ "api-server." ] target_network = "projects/$ { var.project_id } /global/networks/$ { var.network_name } " } # 自己署名証明書の TrustConfig バインド tls_config { trust_config = google_certificate_manager_trust_config.internal_api.id additional_roots = "PUBLICLY_TRUSTED_ROOTS" } } } # 3. Agent Gateway (Egress Mode) resource "google_network_services_agent_gateway" "egress" { provider = google-beta name = "test-gw-egress" location = var.region description = "Agent Gateway with VPC egress connectivity" agent_connectivity_template = "projects/$ { data.google_project.current.number } /locations/$ { var.region } /agentConnectivityTemplates/$ { google_network_services_agent_connectivity_template.default.agent_connectivity_template_id } " google_managed { governed_access_path = "AGENT_TO_ANYWHERE" } registries = [ "//agentregistry.googleapis.com/projects/$ { var.project_id } /locations/$ { var.region } " ] } 参考 : Terraform - google_compute_network_attachment 参考 : Terraform - google_network_services_agent_connectivity_template 参考 : Terraform - google_network_services_gateway IAP 認可ポリシー（AuthzPolicy）の設定 Agent Gateway を経由するトラフィックに対して、Identity-Aware Proxy（IAP）と連携した認可や監査ログ出力を適用するため、 AuthzExtension および AuthzPolicy を定義して Agent Gateway に紐付けます。 参考 : Delegate authorization with Service Extensions 今回は構築初期の疎通検証を円滑に行うため、IAP の強制モード（ iamEnforcementMode ）を DRY_RUN （ドライラン）に設定しています。これにより、認可ポリシーによる意図しない通信拒否を防ぎつつ、Cloud Logging で認可判定ログを監視することができます。 # 1. IAP 連携用 AuthzExtension (DRY_RUN モード) resource "google_network_services_authz_extension" "iap_extension" { provider = google-beta name = "test-gw-egress-iap-authzextension" location = var.region service = "iap.googleapis.com" timeout = "10s" fail_open = true metadata = { iapPolicyVersion = "V2" iamEnforcementMode = "DRY_RUN" } } # 2. Agent Gateway に紐付ける AuthzPolicy resource "google_network_security_authz_policy" "iap_authz_policy" { provider = google-beta name = "test-gw-egress-iap-authzpolicy" location = var.region description = "AuthzPolicy binding IAP extension to Agent Gateway" policy_profile = "REQUEST_AUTHZ" action = "CUSTOM" target { resources = [ "projects/$ { data.google_project.current.number } /locations/$ { var.region } /agentGateways/$ { google_network_services_agent_gateway.egress.name } " ] } custom_provider { authz_extension { resources = [ google_network_services_authz_extension.iap_extension.id ] } } } 参考 : Terraform - google_network_services_authz_extension 参考 : Terraform - google_network_security_authz_policy 実際のアクセス制御を開始する際は、 iamEnforcementMode の行を削除して本番適用に切り替え、エージェントのサービスアカウントに対して必要な IAP ロールを付与してください。 なお、当記事では疎通確認を優先してドライランモードで検証しているため、API エンドポイントを Agent Registry へ登録する作業は省略しています。実際には、宛先のエンドポイント URL を Agent Registry に登録してください。 参考 : Route Agent Runtime traffic through Agent Gateway Cloud DNS と IAM 権限の設定 ホスト名 api-server の名前解決用ゾーンと、Agent Gateway が DNS Peering を行うための権限を設定します。 # 1. Cloud DNS プライベートゾーン resource "google_dns_managed_zone" "internal_api" { name = "api-server-private-zone" dns_name = "api-server." description = "Private DNS zone for internal API server" visibility = "private" private_visibility_config { networks { network_url = "projects/$ { var.project_id } /global/networks/$ { var.network_name } " } } } # 2. A レコードの登録 resource "google_dns_record_set" "api_server_a" { name = "api-server." managed_zone = google_dns_managed_zone.internal_api.name type = "A" ttl = 300 rrdatas = [ var.api_server_internal_ip ] } # 3. Agent Gateway サービスアカウントへの DNS ピアリング権限付与 resource "google_project_iam_member" "agent_gateway_dns_peer" { project = var.project_id role = "roles/dns.peer" member = "serviceAccount:service-$ { data.google_project.current.number } @gcp-sa-agentgateway.iam.gserviceaccount.com" } resource "google_project_iam_member" "dep_dns_peer" { project = var.project_id role = "roles/dns.peer" member = "serviceAccount:service-$ { data.google_project.current.number } @gcp-sa-dep.iam.gserviceaccount.com" } 参考 : Terraform - google_dns_managed_zone 参考 : Terraform - google_dns_record_set 参考 : Terraform - IAM policy for projects 参考 : TerraformでGoogle CloudのIAMを管理する際の注意点 - G-gen Tech Blog API サーバー（Nginx）の設定 検証用のプライベート VM（Compute Engine）のスタートアップスクリプトで、Terraform で生成した証明書を配置し、Nginx を HTTPS で構成します。なお、以下に掲載したスクリプトは Terraform 内に記述する想定なので、Terraform の変数を参照しています。 #!/bin/bash set -e apt-get update apt-get install -y nginx # 証明書および秘密鍵の配置 mkdir -p /etc/nginx/ssl cat << 'CERT' > /etc/nginx/ssl/server.crt ${tls_self_signed_cert.api_server.cert_pem} CERT cat << 'KEY' > /etc/nginx/ssl/server.key ${tls_private_key.api_server.private_key_pem} KEY chmod 600 /etc/nginx/ssl/server.key chmod 644 /etc/nginx/ssl/server.crt # Nginx 設定 (HTTPS 443 で /api を提供) cat << 'CONFIG_EOF' > /etc/nginx/conf.d/api.conf server { listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_protocols TLSv1.2 TLSv1.3; location /api { default_type text/plain; return 200 'Hello, world\n'; } } CONFIG_EOF rm -f /etc/nginx/sites-enabled/default systemctl restart nginx エージェント実装 ADK エージェントの定義 Google が提供する AI エージェント開発フレームワークである Agent Development Kit（ADK）の Python 版を使用して、内部 API を呼び出すエージェントを記述します。 参考 : Agent Development Kit 今回のエージェントは検証用なので、単純に API エンドポイントを呼び出して結果をユーザーに返すものとしています。エージェント内のツール fetch_internal_api では、 requests ライブラリを使用して https://api-server/api を呼び出します。 """ADK Agent Definition for PSC Interface Private API Connection.""" import os import requests import urllib3 from google.adk.agents import Agent from google.adk.models import Gemini from vertexai import agent_engines # 自己署名証明書に伴う InsecureRequestWarning の警告を抑止 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) def fetch_internal_api ( target_url: str = "https://api-server/api" , ) -> dict : """内部プライベート API エンドポイントからデータを取得するツール。""" try : # ホスト名 api-server 宛てにリクエスト # Agent Gateway 側で TrustConfig による TLS 検証が実施される response = requests.get(target_url, verify= False , timeout= 10 ) return { "success" : True , "status_code" : response.status_code, "content" : response.text.strip(), "target_url" : target_url, } except Exception as exc: return { "success" : False , "error_type" : type (exc).__name__, "error_message" : str (exc), "target_url" : target_url, } root_agent = Agent( model=Gemini( model=os.environ.get( "GEMINI_MODEL" , "gemini-3.5-flash-lite" ), client_kwargs={ "vertexai" : True , "location" : "global" }, ), name= "psc_internal_api_agent" , description= "内部プライベート API と通信可能なアシスタントエージェント。" , instruction=( "You are a helpful assistant deployed in Google Cloud Agent Runtime. " "You have access to an internal API endpoint (https://api-server/api) hosted within a private VPC network. " "When asked to call the internal API or check the endpoint, " "always use the `fetch_internal_api` tool to query the API. " "Present the tool's result clearly to the user." ), tools=[fetch_internal_api], ) # Agent Runtime デプロイ用の AdkApp ラッパー app = agent_engines.AdkApp(agent=root_agent) Agent Runtime へのデプロイスクリプト 作成したエージェントを Agent Runtime にデプロイします。この際、 agent_gateway_config に構築済みの Agent Gateway リソース名を指定するのがポイントです。 import agentplatform from vertexai import types from agents.agent import app client = agentplatform.Client(project=project_id, location=location) agent_gateway_resource = ( f "projects/{project_id}/locations/{location}/agentGateways/{agent_gateway_name}" ) config = { "display_name" : "psc-internal-api-agent" , "description" : "Agent Runtime querying internal API via Agent Gateway" , "identity_type" : types.IdentityType.AGENT_IDENTITY, "requirements" : [ "google-cloud-aiplatform[agent_engines,adk]" , "google-adk>=2.8.0" , "cloudpickle" , "pydantic" , "requests" , "urllib3" , ], "extra_packages" : [ "agents" ], "staging_bucket" : f "gs://{staging_bucket}" , "agent_framework" : "google-adk" , # Agent Gateway のバインド設定 "agent_gateway_config" : { "agent_to_anywhere_config" : { "agent_gateway" : agent_gateway_resource, } }, "env_vars" : { "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES" : "False" , }, } remote_agent = client.agent_engines.create( agent=app, config=config, ) 動作検証 踏み台 VM からの直接導通確認 まず、インフラ側の動作確認として、同じ VPC 内に配置した踏み台（Bastion）VM から Cloud IAP 経由で SSH 接続し、内部 API サーバーへの直接導通を確認します。 # 踏み台 VM に SSH 接続 gcloud compute ssh bastion --tunnel-through-iap --zone = asia-northeast1-a --project = my-project # 踏み台 VM 内で内部 API を実行 curl -k https://api-server/api 今回、呼び出しの対象とする API は単純な文字列を返すサンプルなので、実行結果として以下のようにレスポンスが返却されます。 Hello, world エージェントからのプライベート API 呼び出し 次に、Agent Runtime 上にデプロイされたエージェントを Python スクリプトから呼び出し、エージェントが内部 API からデータを取得できるかをテストします。 import agentplatform client = agentplatform.Client(project=project_id, location=location) remote_agent = client.agent_engines.get(name=agent_resource_name) # エージェントへの問い合わせ response = remote_agent.query( input ={ "message" : "内部 API のエンドポイント https://api-server/api にアクセスして結果を教えてください。" } ) print (response) 実行時の出力例は以下の通りです。 [Tool Invocation]: fetch_internal_api with args: {'target_url': 'https://api-server/api'} [Tool Result]: fetch_internal_api -> {'success': True, 'status_code': 200, 'content': 'Hello, world', 'target_url': 'https://api-server/api'} [Agent Response (psc_internal_api_agent)]: 内部 API エンドポイント `https://api-server/api` へのリクエスト結果は以下の通りです： - **HTTP ステータスコード:** 200 - **レスポンスボディ:** Hello, world 上記のように、Agent Gateway が TrustConfig を参照して自己署名証明書を適切に検証し、名前解決から HTTPS 通信までを正常に中継できていることが確認できます。 Agent Gateway のログ確認 このとき、Cloud Logging にはドライランモードで稼働している Agent Gateway によってアクセスを拒否する旨のログが出力されます。 当検証では、Agent Gateway をドライランモードにしているので、 jsonPayload.authzPolicyInfo.result の値が ALLOWED になっています。ドライランモードを解除してトラフィックが拒否されると、この値は DENIED となり、ステータスコードは403となります。API エンドポイントを Agent Registry に登録し、許可対象として Agent Gateway のポリシーで正しく指定すれば、通信は許可されます。 { " httpRequest ": { " latency ": " 0.088799s ", " protocol ": " HTTP/1.1 ", " remoteIp ": " 7.0.2.2:1025 ", " requestMethod ": " GET ", " requestSize ": " 144 ", " requestUrl ": " http://api-server/api ", " responseSize ": " 137 ", " serverIp ": " 10.146.0.59:443 ", " status ": 200 , " userAgent ": " python-requests/2.34.2 " } , " insertId ": " 1a4531xe21i1e ", " jsonPayload ": { " @type ": " type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry ", " agentGatewayInfo ": { " agentRegistryResource ": " projects/1234567890/locations/asia-northeast1/endpoints/agentregistry-00000000-0000-0000-3d7e-aaad1d2c01cc " } , " authzPolicyInfo ": { " policies ": [ { " name ": " projects/229318387257/locations/asia-northeast1/authzPolicies/test-gw-egress-iap-authzpolicy ", " result ": " ALLOWED " } ] , " result ": " ALLOWED " } , " enforcedGatewaySecurityPolicy ": { " hostname ": " api-server ", " matchedRules ": [ { " action ": " ALLOWED ", " name ": " default_denied " } ] , " requestWasTlsIntercepted ": true , " serverNameIndication ": " api-server " } , " mtls ": { " clientCertChainVerified ": " false ", " clientCertError ": " client_cert_validation_not_performed ", " clientCertPresent ": " true ", " clientCertSha256Fingerprint ": " 7U0xSLEA7zzT60Fh+vjiT1kfsReCEnGQKcEYKM/jwtY ", " clientCertValidEndTime ": " 1970-01-01T00:00:00Z ", " clientCertValidStartTime ": " 1970-01-01T00:00:00Z " } , " tlsSniHostname ": " api-server " } , " logName ": " projects/my-project/logs/networkservices.googleapis.com%2Fgateway_requests ", " receiveTimestamp ": " 2026-10-07T00:39:00.168806796Z ", " resource ": { " labels ": { " gateway_name ": " test-gw-egress ", " gateway_type ": " SECURE_WEB_GATEWAY ", " location ": " asia-northeast1 ", " network_name ": " projects/g306208825b1c5693p-tp/global/networks/uk1-25feb-2-vpc4 ", " resource_container ": " 1234567890 " } , " type ": " networkservices.googleapis.com/Gateway " } , " severity ": " INFO ", " timestamp ": " 2026-10-07T00:38:56.195008Z " } 参考 : Monitor traffic through Agent Gateway VPC フローログの確認 当記事の目的（自己署名証明書の API エンドポイントとの疎通）とは直接的には関係ありませんが、VPC フローログを確認し、AI エージェントが API エンドポイントにアクセスする際の接続元 IP アドレスを確認してみます。 API をホストする VM 側から見て、エージェントの接続元 IP アドレス（ jsonPayload.connection.src_ip ）は 10.146.15.193 のように RFC 1918 範囲（いわゆるプライベート IP アドレス）になっています。これは、Network Attachment リソースに割り当てられた IP アドレスです。なお、Network Attachment 作成時にこの IP アドレスを指定することはできず、指定したサブネットの中から自動的に割り当てられます。 参考 : ネットワーク アタッチメントについて 参考 : Set up Agent Gateway with VPC connectivity { " insertId ": " oqx8oafifan84 ", " jsonPayload ": { " reporter ": " DEST ", " end_time ": " 2026-10-08T01:26:11.570219768Z ", " packets_sent ": " 16 ", " dest_instance ": { " vm_name ": " api-server ", " zone ": " asia-northeast1-a ", " region ": " asia-northeast1 ", " project_id ": " my-project " } , " connection ": { " src_ip ": " 10.146.15.193 ", " protocol ": 6 , " src_port ": 46682 , " dest_port ": 443 , " dest_ip ": " 10.146.0.59 " } , " src_psc_interface ": { " producer ": { " zone ": " asia-northeast1-a ", " region ": " asia-northeast1 ", " project_id ": " g306208825b1c5693p-tp " } , " network_attachment ": { " project_id ": " my-project ", " name ": " agent-runtime-attachment ", " region ": " asia-northeast1 " } } , " bytes_sent ": " 0 ", " network_service ": { " dscp ": 32 } , " src_vpc ": { " subnetwork_name ": " default ", " project_id ": " my-project ", " vpc_name ": " default ", " subnetwork_region ": " asia-northeast1 " } , " dest_vpc ": { " project_id ": " my-project ", " subnetwork_region ": " asia-northeast1 ", " subnetwork_name ": " default ", " vpc_name ": " default " } , " src_google_service ": { " type ": " VPC_HOSTED_SERVICE ", " service_name ": " networkservices.googleapis.com ", " connectivity ": " PRIVATE_SERVICE_CONNECT_INTERFACE " } , " start_time ": " 2026-10-08T01:26:11.561092161Z " } , " resource ": { " type ": " gce_subnetwork ", " labels ": { " location ": " asia-northeast1 ", " subnetwork_id ": " 7843426217831826765 ", " project_id ": " my-project ", " subnetwork_name ": " default " } } , " timestamp ": " 2026-10-08T01:26:18.442041438Z ", " logName ": " projects/my-project/logs/compute.googleapis.com%2Fvpc_flows ", " receiveTimestamp ": " 2026-10-08T01:26:18.442041438Z " } リソース削除時の依存関係 当アーキテクチャのインフラを破棄（ terraform destroy など）する際、 リソースの削除順序 に注意が必要です。 Agent Runtime が Agent Gateway を参照している状態で Agent Gateway を削除しようとすると、以下のエラーが発生して削除が失敗します。 Error: Resource is already being used これは、Agent Platform 側のマネージドランタイムが Gateway リソースへの参照ポインタを保持しているためです。そのため、環境をクリーンアップする際は、 先に Agent Runtime のエージェントを削除 してから Terraform のリソース破棄を実行してください。 証明書の更新・追加 証明書を直接登録する場合 当記事の実装例のように、API サーバーの自己署名証明書を直接 TrustConfig の trust_anchors に登録している場合、証明書の更新（秘密鍵や証明書の再作成）に伴い、信頼アンカーの内容を更新する必要があります。 Certificate Manager の TrustConfig では、 trust_anchors に複数の証明書を同時に登録できます。証明書の期限切れによる通信断を防ぐため、以下のローテーション手順を推奨します。 新しい秘密鍵と自己署名証明書（新証明書）を発行する。 Terraform の TrustConfig 定義に新証明書を追加し、旧証明書と新証明書の両方が登録された状態を適用する。 API サーバー（Nginx）の証明書を新証明書に差し替えてリロードする。 すべてのトラフィックが新証明書で正常に疎通することを確認した後、TrustConfig から旧証明書を削除する。 プライベートルート CA を登録する場合 前述の方法では、証明書を新しく発行する度に信頼アンカーの更新が必要となります。証明書の更新頻度が高い環境や、複数のプライベート API サーバーを運用する環境では、自前の プライベートルート CA （認証局）を作成して TrustConfig に登録しておくことで、運用負荷を下げることができます。 有効期間の長い（数年単位など）プライベートルート CA 証明書を TrustConfig の trust_anchors に登録し、各 API サーバーにはそのルート CA が署名したサーバー証明書を配置します。 この構成を採用する最大のメリットは、サーバー証明書の更新時に Google Cloud 側の TrustConfig や Agent Gateway を変更する必要がない点です。API サーバー側で新しい証明書を発行・差し替えてリロードするだけで更新が完了します。また、将来的に別の内部 API サーバーが追加された場合でも、同じルート CA で署名すれば TrustConfig 側の設定変更なしで接続できます。 この構成におけるサーバー証明書の更新手順は以下の通りです。 ルート CA の秘密鍵を使用し、新しい有効期限を持つサーバー証明書を発行する API サーバー（Nginx）に配置されているサーバー証明書を差し替えてリロードする ルート CA 自体の有効期限が切れない限り、Google Cloud 側の TrustConfig を変更・再デプロイする必要はありません。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it