トーク

◻︎セッション概要（500文字以内）
Vertex AI Search はエンタープライズな検索システムを手軽に導入できる一方で、マネージドな機能を多く備えており、その実力を最大限に引き出すためにはアーキテクチャの理解と適切なチューニングが不可欠です。
この Vertex AI Search を深く理解することは、自作の RAG システムの精度向上だけでなく、Gemini Enterprise の横断検索をより使いこなすためのヒントにも繋がります。
本セッションでは、Vertex AI Search の基本機能から最新アップデートまでを網羅し、Gemini Enterprise を含め実運用でつまずきがちな精度向上に対するアプローチと、それを乗り越えるための実践的なノウハウを共有します。
私自身、Gemini Enterprise や Vertex AI Search の導入と精度改善に取り組み、検索精度やセキュリティの閲覧権限管理で多くの試行錯誤を繰り返してきました。その中でえられた知見もお伝えします。

◻︎想定オーディエンス・得られる学び（500文字以内）

• 社内の情報を効率よく検索できるシステムを構築したい方
• Vertex AI Search を一度は触ったものの、より高度なカスタマイズやチューニング方法を知りたい開発者
• Google Cloud で検索システムの構築を検討しているアーキテクト
• RAG アプリケーションの精度向上に悩んでいるエンジニア

得られる学び

• 自身のユースケースに最適な Vertex AI Search のインデックス設定、データ設計手法を理解できる。
• 回答精度を一段階引き上げるための具体的なチューニング手法を習得する。
• Vertex AI Search を使った検証を効率よく回すための方法の一つを学べる。
• Gemini Enterprise がどの様に検索をしているのかが理解できる。

◻︎セッション詳細（1000文字程度）
企業内に眠る膨大なドキュメントやデータを、いかにしてビジネスの競争力に変えるか。
Google Cloud の Vertex AI Search は、この普遍的な課題を解決するため、迅速かつセキュアなエンタープライズ検索基盤を構築できる強力なマネージドサービスです。
しかし、「手軽に始められる」がゆえにデフォルト設定のままで運用し、「期待した検索精度が出ない」「社内の専門用語をうまく解釈できない」「PDFの複雑なレイアウトを読み取れない」といった、
いわゆる "AIの幻滅期" とも呼べる課題に直面するケースは少なくありません。
この"幻滅期"を乗り越える鍵こそ、検索エンジンの深い理解になります。例えば、社内システムの横断検索を担う Gemini Enterprise の強力な検索機能は、この Vertex AI Search の技術を基盤として構築されています。
だからこそ、Vertex AI Search のアーキテクチャとチューニングの勘所を学ぶことは、自作RAGシステムの精度向上だけでなく、Gemini Enterprise のデータストア検索の挙動を理解し、より効果的に使いこなすための最短ルートとなるのです。
本セッションでは、Vertex AI Search の基本から応用まで、実践的なノウハウを網羅的に解説します。
まず、検索の土台となるインデキシング戦略として、非構造化データ（PDF/HTML/Office文書）と構造化データの使い分け、メタデータ活用の振り方、そして精度を左右する前処理の勘所を深掘りします。
次に、エンタープライズ利用で避けては通れないセキュリティと実運用に焦点を当てます。
特に試行錯誤した Workforce Identity Federation と連携した動的な閲覧権限管理の実装パターンやソレを使わずに実施する閲覧権限管理のパターン、鮮度を保つためのデータ更新パイプライン設計、
さらに Security Command Center と連携した機微データのフィルタリング手法について、失敗談も交えながら共有します。
このセッションを聴き終えたとき、"AIの幻滅期"を乗り越え、自信を持って Vertex AI Search の導入と精度改善を進めるための、明確な次の一歩が見えているはずです。

◻︎セッション概要（500文字以内）
本セッションは、「セキュリティ in the AI Agent Era」と題し、AI Agentの飛躍的な進化とそれに伴うセキュリティリスクを解説したものです。 2025年は、Googleによる「Gemini 3」や開発環境「Antigravity」の発表など、AIが単なる補助（Co-pilot）から自律的な「相棒（Partner）」へと変貌を遂げたパラダイムシフトの年と位置づけています。一方で、AI Agent特有の「自律ループ処理」や「ツール使用」は、従来のセキュリティ境界を突破する新たな脅威を生み出しました。 セッションでは、間接的プロンプトインジェクションや権限昇格などの具体的リスクを詳説し、多層防御やHuman In The Loop（HITL）といった対策を提示します。さらに2026年の課題として「シャドーエージェント」への対応や、ISO42001(AIMS)等のガバナンス構築の必要性を提言しています。

◻︎想定オーディエンス・得られる学び（500文字以内）
想定オーディエンス
• Google Cloudを利用してAI開発・運用を行うエンジニア
• 組織内のAI導入におけるセキュリティリスクを懸念するIT管理者・セキュリティ担当者
• AI Agentの最新トレンドとガバナンス戦略に関心がある経営層・リーダー
得られる学び
• AI Agentの仕組みと進化: 従来のチャットボットと異なり、目的達成のために自律的に計画・行動・修正を行うエージェントのアーキテクチャ（認知・思考・行動ループ）を理解できます。
• 最新のセキュリティ脅威: ユーザーに悪意がなくても被害に遭う「間接的プロンプトインジェクション」や、エージェントがユーザーの権限を超越する「混乱した代理人（Confused Deputy）」問題など、自律型AI特有のリスクシナリオを学べます。
• 実践的な防御策と未来の課題: エージェントの暴走を防ぐためのHuman In The Loop (HITL) やOn-Behalf-Of (OBO) 認証といった具体的な技術対策に加え、従業員が勝手に強力なエージェントを使用する「シャドーエージェント」問題など、2026年に向けた組織的な課題と対策指針が得られます。

◻︎セッション詳細（1000文字程度）

1. 2025年の振り返り：AI Agentへのパラダイムシフト 2025年はAI Agentにおいて飛躍的な進化があった年です。Googleからは、思考プロセスを経て回答する「Thinking Mode」や、エージェント開発基盤「Vertex AI Agent Engine」、そして年末には「Gemini 3」やAIエディタ「Antigravity」がリリースされました。 これによりAIは、指示待ちの「副操縦士（Co-pilot）」から、抽象的なゴールを与えれば自律的にツールを使い、試行錯誤（ループ処理）を繰り返して完遂する「相棒（Partner）」や「優秀な新入社員」へと役割を変えました。
2. AI Agent特有の新たなリスク この自律性は、従来の決定論的なソフトウェアとは異なる新たな攻撃面を生み出しています。
   • 間接的プロンプトインジェクション: 攻撃者がWebサイトやメールに不可視の命令を埋め込み、エージェントがそれを読み込むことで、ユーザーの意図しない動作（情報の外部送信など）を強制させられます。
   • 権限の不一致（混乱した代理人）: エージェントが高い権限（管理者権限など）を持っている場合、一般ユーザーがエージェントを介して本来アクセス権のない人事データ等にアクセスできてしまうリスクです。
   • メモリポイズニング: エージェントの長期記憶（Vector DB等）に悪意ある情報を潜伏させ、将来的にその情報を参照したタイミングで攻撃が発動する、いわば時限爆弾のような攻撃です。
   • IDEsaster: 自律型エージェントを搭載したIDEにおいて、リポジトリのREADMEを開くだけで設定が書き換えられるなどの脆弱性も確認されています。
3. リスク対策：多層防御アーキテクチャ これらのリスクに対し、以下の対策が推奨されています。
   • HITL (Human In The Loop): 重要な操作（決済、本番環境への変更など）の直前には、必ず人間の承認プロセスを挟み、AIの完全な独走を防ぎます。
   • OBO認証とJITアクセス: エージェント独自の権限ではなく、依頼したユーザーの権限代理（On-Behalf-Of）として振る舞わせ、かつその権限を一時的（Just-In-Time）なものに制限します。
   • サンドボックス化: コード実行などの危険なタスクは、コンテナやWebAssemblyなどの隔離環境で行い、システムへの影響を遮断します。
4. 2026年の予測： 最後に、重要なポイントに対する2026年の予測として、いくつか紹介します。「権限管理の課題」では、権限管理の複雑化と管理の難しさを。「シャドーエージェント」は従業員が企業の承認を得ずに強力な自律型エージェントを導入・運用してしまう問題について触れます。 現在、組織の63%がAIポリシーを欠いているとされ、ISO 42001 などの国際認証を活用し、開発から運用までのライフサイクル全体でリスクを管理するガバナンス体制の構築が急務とされています。
   AI Agentは発展をもたらす一方で破壊のリスクも孕んでおり、技術とガバナンスの両輪で立ち向かう必要があります。

◻︎セッション概要（500文字以内）
Google Developer Group (GDG) Tokyo は、Cloud、AI、Web、モバイルなど、Google の多様なテクノロジーに興味がある人が集い、学びを深めるコミュニティです。皆さんは イベントに参加することで学びを得ていると思いますが、私たち GDG Tokyo の運営チームもイベントの企画・運営を通して Google Cloud を学んでいます。

昨年は Vertex AI、ADK、BigQuery などの最新トピックを扱いました。ただ学び方をお伝えするだけではなく、この機会に、「運営で得た学び」をコミュニティ運営の力にするため、「コミュニティ運営への Google Cloud の活用」に挑戦を始めます。具体的には、Cloud Run や ADK を用い、Discord や Google Drive に蓄積されたデータを活用して定型タスクの効率化や、TODO 管理の課題解決を目指します。コミュニティ運営の視点で Google Cloud をどう学び、次なる企画へ繋げているかをお伝えします。

◻︎想定オーディエンス・得られる学び（500文字以内）
⚪︎ 想定オーディエンス

• コミュニティ運営や身近な業務の効率化に興味があるエンジニア
• Cloud Run を用いたサーバーレスな自動化や、 ADK 活用の第一歩を踏み出したい方

⚪︎ 得られる学び

• コミュニティ運営を通した技術の学び方
• 課題を分解し、Google Cloudの各サービスへマッピングするプランニングの思考法

◻︎セッション詳細（1000文字程度）
Google Developer Group (GDG) Tokyo は、Cloud、AI、Web、モバイルなど、Google の多様なテクノロジーに興味がある人が集い、学びを深めるコミュニティです。皆さんは イベントに参加することで学びを得ていると思いますが、私たち GDG Tokyo の運営チームも皆さん同様 Google Cloud のエキスパートではないため、イベントを運営することで多くの学びを得ています。

昨年の GDG Tokyo のイベントでは、Vertex AI・ADK・BigQuery などのトピックを扱ってきました。本発表では、運営してきたイベントでの学びをご紹介しつつ、私たちの「運営で得た学びをコミュニティ運営の力にする」取り組みを学びの実践例としてご紹介します。

現在の GDG Tokyo のイベント運営には 2 つ課題があります。1つ目はスタッフのリソースの配分です。イベント運営には定型的なタスクと、そのイベント特有なタスクに別れます。後者のタスクがイベントの盛り上がりに直結するため、そこにスタッフのリソースをどれだけ割けるかが重要ですが、定型的タスクに時間を取られているという課題があります。2つ目の課題として、TODO 管理があります。運営関係者がイベントごとに変わるため、人数制限のある TODO 管理アプリを導入することは難しく、タスクの割当て・進行状況の管理が効果的にできていません。GDG Tokyo は、Discord 上でのチャットをベースとしながら、それ以外の情報をGoogle Drive 上で管理しています。今回の挑戦ではこの蓄積されたデータを、Google Cloud に連携させ、 Cloud Run・ADK などで調理することで、課題解決に取り組みます。

私たちがイベント運営でどのように Google Cloud を学んでいるか、そしてその学びが次のイベントにどのように生かされているのか、皆さんにお伝えできればと思います。

◻︎セッション概要（500文字以内）
Googleが提供している分散DBのSpanner。このセッションではSpannerはどのように分散しているのか。分散すると嬉しいこと辛いことについて話します。

◻︎想定オーディエンス・得られる学び（500文字以内）

• なんらかのRDBMSは使ったことがある人
• 分散DBをなんとなく使っている人

◻︎セッション詳細（1000文字程度）
Googleが提供している分散DBのSpanner。このセッションではSpannerはどのように分散しているのか。分散すると嬉しいこと辛いことについて話します。
分散DBはスケーラビリティが高く、たくさんのリクエストを処理することができるという印象を持っている人が多いかと思いますが、実際には魔法のようになんでもスケールさせてくれるわけではなく、とても現実的な実装で動いています。
そして分散DBのポテンシャルを引き出すにはアプリケーション側の設計が非常に重要になります。
分散と集中をどのようにバランスを取ればSpannerの力を最大限引き出せるのか、中を一緒に想像してみましょう。

◻︎セッション概要（500文字以内）
ファインディ株式会社では複数のプロダクトを展開し、横断的に集まるエンジニア行動データを企業価値の源泉としています。この構造を支えるため、Google Cloud 上にデータ基盤を整備してきました。従来は、事業部単位のELT パイプラインを独立したプロジェクトで構築し、横断的に必要なもののみ中央集権プロジェクトに集めて分析していました。

しかし、第四次AIブームに伴う事業数拡大により、プロジェクト増加に伴う運用・保守コストが顕著になりました。そこで、プラットフォームエンジニアリングの考え方を取り入れたリアーキテクチャを実施しました。

本セッションでは、Google Cloud の各種サービスを活用し、スケール可能なデータ基盤へ移行した際の設計上の判断・開発運用で得た知見を具体的に紹介します。

◻︎想定オーディエンス・得られる学び（500文字以内）
本セッションの題材は、Google Cloudを用いたデータメッシュアーキテクチャによるデータ基盤のリアーキテクチャです。そのため、データ活用の推進者やプラットフォームエンジニアを対象としています。

特に、新規プロジェクトの追加が負担にならない基盤作りやプラットフォーム利用者にとって使いやすい基盤作りがしたい方にとって学びのある内容です。

また、BigQuery・Cloud Run・Datastream・Looker など、Google Cloudを利用したデータ基盤を作る上で主要なサービスを扱います。これらの利用を検討中の方にとって、実践的な判断材料となるでしょう。

◻︎セッション詳細（1000文字程度）
ファインディ株式会社は、IT エンジニア向けに複数のプロダクトを展開し、そこから得られる行動データを横断的に活用することで価値を生み出す事業モデルを採用しています。そのため、創業から10年近くたった今でも新規事業が複数誕生しています。このような新規事業が誕生しやすい環境において、我々のデータ基盤は増加するプロダクトに合わせてスケール可能な構造が求められていました。

従来の運用は、事業部ごとに独自のELTパイプラインを構築する方式で、短期的なスピードには優れている方法でした。しかし、プロダクト数の増加とともにプロジェクト管理の煩雑さが浮き彫りになっていきました。Google CloudのプロジェクトやGitHubリポジトリは増え続け、独自の構造や設定が生まれたことで、メンテナンス負荷や属人化が深刻化していきました。

これらの課題を背景に、プラットフォームエンジニアリングの観点から基盤そのものを再設計し、運用とデリバリーの双方を改善する取り組みを進めました。

まず、dbtの実行環境を統合し、10近くに分散していたデータセットを2つに集約。また、dbtの実行環境をDockerイメージとしてArtifact Registryに登録し、GitHubのReusable WorkflowとCloud Runを組み合わせて安定したランタイムを提供しました。

EL処理については、Datastream・DuckDBへ移行し、リアルタイム性と保守性を両立。また、ポリレポで分断されていた構成をモノレポに整理することで、管理性を大きく向上させました。

さらに、分析基盤の中核となるBIをLooker StudioからLookerに移行しました。これにより、分析環境の構築・更新をコード化しつつ、利用者へのアカウント発行も効率的かつ安全に行える仕組みを確立しています。

これらの取り組みにより、事業の数が増えても、データエンジニアへの負担が増えないデータプラットフォームになりました。また、事業追加時の初期構築作業が簡単になり、新規事業におけるデータ活用までのリードタイムが大きく短縮しました。

本セッションでは、このアーキテクチャ刷新の背後にある設計原則や技術選定時の思考、開発運用を通じた知見をお話しします。

◻︎セッション概要（500文字以内）

株式会社LegalOn Technologiesでは、事業の急拡大に伴い、50以上のマイクロサービスを含むシステムを「単一リージョン・単一プロダクト」から「マルチリージョン・マルチプロダクト」構成へ移行する大規模なリアーキテクチャを敢行しました。 本セッションでは、開発者の認知負荷を最小限に抑えながらこの複雑な要件を満たすために構築したアプリケーションプラットフォームの全貌を解説します。Google Kubernetes Engine (GKE) や Cloud Service Mesh を活用した基盤設計、Terraformモジュールと独自ツールによるクラウドやKuberentesリソースの抽象化、Google Cloudとシームレスに連携するOSSを活用したCI/CDの拡張、そしてSecurity Command Centerを用いたガバナンスまで、Google Cloudの機能をフル活用したプラットフォームエンジニアリングの実践知を、技術的な意思決定の背景と共に共有します。

◻︎想定オーディエンス・得られる学び（500文字以内）

想定オーディエンス

• 急拡大するマイクロサービスアーキテクチャの運用・設計に携わるSRE、プラットフォームエンジニア
• GKEの大規模運用や、マルチプロダクト・マルチリージョン設計に関心のあるテックリード
• Terraformや自作ツールを用いた開発者体験の向上に取り組んでいる方

得られる学び

• 大規模GKE設計の勘所: 運用用・プロダクト横断用・国別用など、リソースの「統合と分離」をどう設計し、Cloud Service Meshでどう繋ぐかのリファレンスアーキテクチャ。
• プラットフォームエンジニアリングの実装: 開発者が意識せずにGoogle Cloudのリソースを扱えるようにするための、Terraformモジュール（Starter-kit, AlloyDB-kit）設計と、Manifest自動生成ツール（k8s-gen）の開発運用およびソフトウェア開発ライフサイクル（SDLC）全体の継続的な改善事例。

◻︎セッション詳細（1000文字程度）

本セッションでは、グローバル・マルチプロダクト展開という複雑な要件に対し、Google CloudとOSSエコシステムを組み合わせてどのように「開発者が本来の業務に集中できるプラットフォーム」を構築したか、そのアーキテクチャと進化の過程を深掘りします。

1. マルチリージョン・マルチプロダクトを支える基盤アーキテクチャ
   数千のリソース規模になるシステムにおいて、管理コストを爆発させずに拡張性を担保するための設計思想を解説します。

• 統合と分離の戦略: GKEクラスタの役割定義（基盤用、プロダクト用、国別用）と、Cloud Service Meshによる透過的なマイクロサービス間通信の実現。
• 階層設計: Google Cloud Folder/Project構成からNetwork Policyに至るまで、マルチテナント環境におけるセキュリティとガバナンスの確保。

2. インフラの「抽象化」によるゴールデンパスの提供
   複雑なインフラを開発者から隠蔽し、セキュアな構成をデフォルトで提供するための仕組みを紹介します。

• 独自ツールとTerraform Module: 各マイクロサービスに共通で必要なリソース（Google Cloud Project、IAM、GARリポジトリ、Argo CD Application、サービスアカウント、AlloyDB、Kubernetes Namespace等）をセットで払い出すTerraformモジュール群や、組織のポリシーやベストプラクティスに準拠したKubernetes Manifestを自動生成するツール（k8s-gen）の開発・運用。

3. SDLCの改善：デプロイ自動化とInner Loopの高速化
   プラットフォームの提供価値を「インフラ構築」から「日々の開発体験の向上」へ広げるための最新の取り組みについてお話しします。

• Argo CDによるマルチ環境デプロイ: dev、qa、prd stageといった多層的な環境かつマルチリージョン・マルチプロダクトへのデプロイを、Google Cloudと連携させながらArgo CD Image UpdaterやManifest更新ツールを組み合わせていかに省力化・自動化しているか。
• フィードバックループの迅速化: ローカルのコードをGKEクラスタ内で即座に動作確認できるMirrordの導入検証や、Argo CD PR Generatorを活用したPull Requestごとのプレビュー環境の払い出しなど、開発者がPRを作成する前後のリードタイムを極小化するための挑戦と学び。

◻︎セッション概要（500文字以内）
BigQueryはどうやって出来ているのか？
そんなもの知らなくても使えます。
なので、趣味で読んでる論文など読み漁ったものをまとめて、ただただドヤ顔で話すだけです。

◻︎想定オーディエンス・得られる学び（500文字以内）
BigQueryの裏側に興味のある人
得られる学びは人類にはまだ早いということが理解できます
オンプレでも出来るっしょ？という人を絶望させることが出来ます

◻︎セッション詳細（1000文字程度）
BigQueryがどのような構成で出来ているのかを解説します。
実はBigQuery専用の何かはほんの一部で、実際にはGoogleの根幹のテクノロジーの寄せ集めで出来ており、それがないと全く成り立ちません。
では、その根幹のテクノロジーってなんなのか？Google検索からGmailやYoutube、最近話題のGeminiまで、それらはどのようなインフラの上で動いているのかを解説します。
これを知ったところでBigQueryの利活用にはなんの役にも立ちません。
ただ、知っておくと今後のクラウドや生成AIは何を使っていけばいいのか？という選択を迫られた際に低レイヤー層と未来の判断材料になるかもしれません（しらんけど）

◻︎セッション概要（500文字以内）
Gemini Enterprise Agent Designer は Agent を low-code でオーケストレーションできるサービスです。しかしなぜこんなにも賢い Agent を組み合わせる必要があるのでしょうか。その背後には Google の研究開発チームのさまざまなマルチステップエージェントの研究開発事例があります。2025 年 12 月の NeurIPS 2025 で発表された論文を紐解くと、それらのマルチステップエージェントの間には共通の設計パターンが見えてきます。
この発表では、Google のマルチステップエージェントの論文を紹介します。また、それらから見えてくるマルチステップエージェントの設計パターンについて述べます。最後に、マルチステップエージェントを自動的に構築する取り組みである、H-Swarms について述べます。
このマルチステップエージェントを自動的に構築する技術は、Gemini Enterprise の Agent Designer に搭載される見込みです。

◻︎想定オーディエンス・得られる学び（500文字以内）

想定オーディエンス

• エージェントから最高のパフォーマンスを引き出したい Powered User
• 現実の複雑な課題に挑むマルチステップエージェントの開発者
• Google の最新の研究開発を知りたい技術オタク

得られる学び

• マルチステップエージェントの設計指針
• 将来的に実装されるマルチステップエージェントの自動構築機能の仕組み

◻︎セッション詳細（1000文字程度）

NeurIPS 2025 の Google のマルチステップエージェントに関する Tutorial をベースとして、ここで触れられた論文の概要や、アルゴリズムの解説をします。マルチステップエージェントの自動構築アルゴリズム H-Swarm をゴールとして、次のアウトラインで発表する予定です。

アウトライン

• マルチステップ AI エージェントに至るまで (導入)
  • LLM as a Chatbot: 賢く役に立たない隣人
  • AI Agent: AI の "手" の実装という発明
  • MCP: ツールの拡張を容易にするプロトコル
  • コンテテキスト崩壊
  • A2A: コンテキストのドメイン分割による専門家ネットワーク
• マルチステップエージェントの例
  • MLE-STAR: Machine Learning Engineering Agent via Search and Targeted Refinement
  • MLE-STAR-PRO: Automating Machine Learning Engineering
  • DS-STAR: A State-of-the-art versatile data science agent
  • PlanGen: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving
• マルチステップエージェントの自動構築
  • 典型的なパターン
  • すべてを一度にやらず、ドメインごとに分割して専門家を用意
  • 評価車を用意して、イテレーションを構築
  • 十分に良くなるまで構造的に議論させる
  • Automated Multi-Agent Design
  • 自動構築アルゴリズム H-Swarm
• 今後の展開
  • H-Swarm は Gemini Enterprise Agent Designer に搭載予定
  • 自動構築されるマルチステップエージェントの力を手にする日も近い

Disclaimer

• 内容は時間をみながら変更するかもしれません

◻︎セッション概要（500文字以内）
昨今の攻撃手法の激化や、OSS 依存関係に潜むリスクにより、アプリケーションそのものだけでなく、開発からデプロイに至るソフトウェアサプライチェーン全体の保護が必要となっています。

本セッションでは、Google Cloud のマネージドサービスを組み合わせ、コードのコミットから本番運用までを一貫して保護する DevSecOps の実践的なアーキテクチャを解説します。Cloud Build のプライベートプールによる隔離されたビルド、SBOM とビルドの来歴による透明性の確保、そして Binary Authorization を用いたポリシーベースのデプロイ制御まで、一連のパイプライン構築手法を具体的な例を交えて紹介します。

◻︎想定オーディエンス・得られる学び（500文字以内）
想定オーディエンス
　・ Google Cloud を利用しているアプリケーション開発者、DevOps エンジニア
　・ コンテナセキュリティの強化や CI/CD パイプラインの設計を担当する SRE、プラットフォームエンジニア
　・ 自社サービスのセキュリティ要件定義や運用設計に関わるエンジニア

得られる学び
　・ セキュアなビルド環境: Cloud Build プライベートプールや IAM を活用し、安全な CI 環境を構築する方法。
　・ サプライチェーンの可視化: ビルドの来歴と SBOM の生成により、ソフトウェアの依存関係と正当性を証明する SLSA 対応の手法。
　・ デプロイパイプラインの制御: 脆弱性スキャンによるイメージの脆弱性管理、Binary Authorization を用いて信頼できないコンテナのデプロイをブロックする仕組み。
　・ ランタイムセキュリティ: Container Threat Detection を用いた、脅威検知の運用。

◻︎セッション詳細（1000文字程度）
昨今、Next.js などの主要フレームワークに見つかった脆弱性や、ビルドパイプラインを狙った攻撃事例は、開発者に対して「コードを書く」以外のセキュリティ対策を強く求めています。本セッションでは、Google Cloud のネイティブ機能をフル活用し、開発スピードを損なうことなく、強固な DevSecOps パイプラインを構築する具体的なステップを解説します。

1. Cloud Build によるセキュアなビルド環境の構築
   攻撃者によるビルド環境への侵入や、認証情報の漏洩を防ぐため、CI/CD の基盤を堅牢化します。
   　・ プライベートプールの活用: パブリックなインターネットから隔離された VPC ネットワーク内でビルドを実行し、ソースコードやビルドアーティファクトへの不正アクセスを防ぐアーキテクチャを紹介します。
   　・ IAM による権限管理: ビルドプロセスに必要な権限のみを付与する最小権限の原則の実装について解説します。

2. ソフトウェアサプライチェーンの透明性確保（SBOM / ビルドの来歴）
   「誰が、いつ、どのソースコードからビルドしたのか」を証明し、含まれるライブラリを把握します。
   　・ ビルドの来歴の生成: ビルド時に自動的に署名付きの来歴情報を生成し、改ざん検知やトレーサビリティを担保する方法を説明します。
   　・ SBOM の活用: アプリケーションの依存関係リスト（SBOM）を生成・管理し、脆弱性が発見された際に即座に影響範囲を特定できる体制を作ります。

3. 脆弱性検出とデプロイ制御（Binary Authorization）
   作成されたコンテナイメージが、セキュリティ基準を満たしているかをチェックします。
   　・ コンテナ脆弱性スキャン: Artifact Registry 等と連携した自動スキャンの仕組みと、開発フローへの組み込みについて触れます。
   　・ Binary Authorization による強制: 「脆弱性が無いこと」「ビルドの来歴が正しいこと」などのポリシーを満たさない限り、GKE や Cloud Run へのデプロイをブロックする設定を行い、人為的なミスやポリシー違反のリリースを防ぎます。

4. 実行環境における脅威検知（Container Threat Detection）
   デプロイ後の対策として、実行中のコンテナに対する脅威への備えを解説します。
   　・ Security Command Center の活用: Container Threat Detection を有効化し、クリプトマイニングや不審なバイナリ実行など、本番環境での異常な挙動を検知・対応するフローを紹介します。

これらの一連のフローを統合し、開発者が意識せずとも Google Cloud 上でセキュアなアプリケーションを提供できるプラットフォームとしての全体像を提示します。