プロポーザル

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

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

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

◻︎セッション概要（500文字以内）
Cloud Run好きですか？僕は大好きです。僕以上に多くの方々がそう感じているのでは無いでしょうか。

しかし、簡単に動く状態から一歩進むと、ビジネスやサービスのコアとして利用するには、基本的なアーキテクチャや実装パターンの「検証」が不可欠と考えています。
本セッションでは、弊社が内製する「問い合わせ窓口・チャットプロダクト」の開発運用経験から得られた、Cloud Run活用の「検証結果」と「基本の型」を共有します。
Webの標準を多く実装するフレームワーク「Hono」を相棒に、現場で検証・導入を重ねたからこそ話せる実装の勘所を解説できればと思います！

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

• Cloud Runを使っているが、より本格的なビジネス活用（リアルタイム、大容量通信など）に踏み込みたい方
• 「動いているけれど、これがベストプラクティスなのか？」とアーキテクチャに不安を感じている方（僕自身正しいかわからないですが、ヒント等は共有できると思っています）

◻︎セッション詳細（1000文字程度）
Google Cloud、主にCloud Runを活用した、問い合わせ管理プロダクトや、チャットサービスを内製化しています。
Cloud Runがとても簡易ですが、利用するまえに、実際にビジネス要件を満たすサービスを構築する過程で、私たちは多くの技術的な壁に直面し、一つ一つ検証を行ってきました。

• ビジネス要件（チャット、ファイル転送）を満たすための、Cloud Run × Honoの実装パターンと検証結果
• 32MB制限の突破やWebSocketのタイムアウト対策など、実運用で直面する課題への具体的な解決策
• AIエージェント連携（MCP）を見据えた、次世代Webアプリケーションの構成案
• etc...

ドキュメントを読み進め検証したらしっくりくる内容だと考えていますが、経験値からこれらを解決するために実施したことを共有できればと思います。

◻︎セッション概要（500文字以内）
Cloud Runは開発者にとって手軽な反面、実運用ではIAM、VPCコネクタ、Ingress設定など、インフラ管理で設定する項目がたくさんあります。ここで頻発するのがこれらはTerraformで管理すべきか、アプリのコードで管理すべきかという論争です。

全てをTerraformで管理すればインフラチームの負荷が増えデプロイ速度は低下し、逆にアプリチームに全権限を渡せばセキュリティをはじめとしたリスクが高まります。

本セッションでは、このトレードオフを解消するために、リソースの変更頻度とリスクに基づいた境界線設計を考察します。Terraformは変わらないベースラインの管理に特化し、Cloud Runの構成はガードレールを設けた上でアプリチームに権限を委譲するアーキテクチャについて、具体的な構成例とCI/CDパイプラインの実装パターンを交えて解説します。

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

• Cloud Runの採用を検討中、または運用における権限設計に悩むSRE、プラットフォームエンジニア
• インフラ側のTerraform反映待ちを解消し、デプロイ頻度を向上させたいテックリード

【得られる学び】

• インフラとアプリの適切な責任分界点の定義方法
• Cloud Runにおけるデプロイパイプラインの設計原則
• アプリチームに裁量を渡しつつ、誤った設定を防ぐガードレールの技術的実装

◻︎セッション詳細（1000文字程度）
※時間によっては内容が変化します。

1. Cloud Run運用の管理主体問題

アプリケーションのデプロイは迅速にできることが望ましいですが、それを取り巻くGoogle Cloudのリソース(IAM、Network)は堅牢であるべきです。
Cloud Run Service自体はインフラリソースでもあるため、Terraformで管理することができます。しかし完全にTerraformで管理すると環境変数の追加などもインフラチーム経由で変更を行わなくてはならず、アプリチームのリリース速度を殺してしまうケースが見受けられます。逆にアプリチームがGUIから設定を変更するとIaCとのドリフトが発生するケースが発生します。

2. インフラプロビジョニングとアプリケーションのデプロイの分離

この問題を解決するには、ツールありきではなくリソースの性質で管理を分けるアプローチが有効です。
インフラリソースとアプリケーションのデプロイの分離について説明します。
CI/CDと合わせてCloud Runのデプロイ方法について分類します。
インフラとアプリの責任分解点について考察して、適切なところを探っていきます。

3. ガードレールによる安全な委譲

単にアプリチームに権限を渡すだけでは野良運用になります。そこで、インフラチームの役割を作業代行からガードレールの設計へとシフトさせる方法を話します。

• 事前検証（CIチェック）： アプリリポジトリ内のデプロイ設定に対し、危険な設定が含まれていないかをデプロイ前に自動テストする仕組み。
• 最小権限の原則： デプロイを実行するService Accountには必要最低限の権限のみをTerraformで付与し、ネットワーク設定などの破壊的変更を物理的に防ぐ設計。

4. まとめ

Terraformですべて管理するという運用から脱却しアプリの自律性を高めることは、結果としてインフラチームの運用負荷を下げることに繋がります。互いに不幸にならないための、現代的なCloud Runデプロイパイプラインの形を考察します。

◻︎セッション概要（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 上でセキュアなアプリケーションを提供できるプラットフォームとしての全体像を提示します。

◻︎セッション概要（500文字以内）
動画コンテンツの爆発的な増加に伴い、「何が映っているか」を抽出するだけでなく、「特定のシーンをいかに高度に検索するか」というニーズが急増しています。本セッションでは、Google Cloud が提供する動画解析・検索ソリューションを網羅的に解説します。

具体的には、長年の実績がある Video Intelligence API、大規模なメディア管理と画像・テキストによる横断検索を実現する Vision Warehouse、そしてマルチモーダル LLM Gemini と Vertex AI Search を組み合わせた動画 RAG アーキテクチャを紹介します。

生成AIの進化により、従来のモデルでは困難だった「動画の文脈理解」や「自然言語による詳細なシーン特定」がどのように容易になったのか、デモを交えて解き明かします。各サービスのアーキテクチャやコスト、精度、ユースケースを徹底比較し、ビジネス課題に最適なサービス選定の指針を提示します。

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

動画データを活用した新規ビジネスや業務効率化を検討しているエンジニア、PM

大量の映像アーカイブから特定のシーンを効率的に検索したいメディア・放送業界の方

Google Cloud の Vision AI / Generative AI 関連サービスの使い分けを知りたい技術選定者

【得られる学び】

Google Cloud 動画ソリューションの全容: Video Intelligence, Vision Warehouse, Gemini の役割と最新機能。

高度な検索手法の理解: テキストだけでなく、画像を用いた「類似シーン検索」の実装アプローチ。

動画 RAG の構築パターン: Gemini で抽出した高度なメタデータを Vertex AI Search で検索可能にする構成。

最適な技術選定基準: コスト、リアルタイム性、解析の深さに応じた、各サービスの具体的な使い分け基準。

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

1. 動画解析のパラダイムシフト
   これまでの動画解析は、物体検知やショット変更検知といった「タグ付け」が中心でした。しかし、Gemini に代表されるマルチモーダルモデルの登場により、数時間に及ぶ動画の文脈を理解し、複雑な質問に答えることが可能になりました。本セッションの冒頭では、この技術進化が動画検索にもたらす変化を整理します。

2. 主要サービスの徹底解説と比較
   Google Cloud で動画を扱う際の 3 つの主要アプローチについて、深く掘り下げます。

Video Intelligence API: ラベル検知、ロゴ検知、不適切コンテンツのフィルタリングなど、定義済みのタスクを低コストかつ高速に処理する「従来型 AI」の強みを解説します。

Vision Warehouse (Vertex AI Vision): ペタバイト級の映像資産を管理し、「テキスト」や「参照画像」を用いて動画内を検索できる強力な機能を詳解します。特に、類似画像から該当する動画シーンを見つけ出すセマンティック検索の仕組みに触れます。

Gemini + Vertex AI Search (動画 RAG): Geminiの長尺コンテキストウィンドウを活用し、動画の内容を詳細に構造化（JSON化）した上で、Vertex AI Search で検索可能にする構成を紹介します。

3. サービス比較マトリクス
   プロジェクトの要件に応じてどのサービスを選ぶべきか、以下の比較の軸等を用いて解説します。
   サービス：Video Intelligence、Vision Warehouse、Gemini + Vertex AI Search

比較の軸
・主な用途
・検索手段
・解析の方法と深さ
・実装難易度

◻︎セッション概要（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文字以内）
Agent Engineを使って、ユーザーとの関係性を覚えていて、場面に応じた画像も出せる対話アプリを作ります。題材は恋愛シミュレーション。Memory Bankで長期記憶、Sessionsで会話文脈を管理し、Gemini 3 Pro Imageでシーンに応じたキャラクター画像を生成します。セッションでは、記憶をどう設計するか、画像生成をどう組み込むか、実際に作りながら得た知見を共有します。

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

• 想定オーディエンス
  • Agent Engineを触ってみたいが、まだ手を動かしていない人
  • Memory BankやSessionsの具体的な使い方を知りたい人
  • LLMと画像生成を組み合わせたアプリに興味がある人

前提知識としては、PythonでのAPI呼び出し経験があれば十分です。Agent EngineやADKの事前知識は不要です。

• 得られる学び
  • Agent Engineの記憶機構（Sessions / Memory Bank）の役割と使い分け
  • LLMから構造化データを抽出する設計パターン
  • 画像生成を対話アプリに組み込む際の考え方

◻︎セッション詳細（1000文字程度）
本セッションでは、Vertex AI Agent Engineを使ってステートフルな対話アプリを構築する過程で得た知見を共有します。題材として恋愛シミュレーションを採用しますが、ここで扱う技術課題は対話型AIアプリ全般に応用可能です。
まず、記憶の設計について話します。Agent EngineにはSessionsとMemory Bankという2つの記憶機構があります。Sessionsは直近の会話文脈を保持する短期記憶、Memory Bankはセッションをまたいで情報を保持する長期記憶です。恋愛シミュレーションでは、直近の会話の流れはSessionsで、親密度や過去の重要な選択はMemory Bankで管理します。何を短期に入れ、何を長期に入れるかの判断基準を具体例とともに紹介します。
次に、LLMからの構造化出力について話します。キャラクターの応答からセリフと情景描写を分離し、さらに感情やシーン情報をJSON形式で抽出しています。これにより、画像生成のトリガー判定やUI表示の制御が可能になります。
画像生成との連携では、Gemini 3 Pro Imageを使います。毎回画像を生成するのではなく、感情やシーンが変化したときだけトリガーする設計にしています。
デモでは実際に動くアプリを見せながら、これらの仕組みがどう連携しているかを示します。

◻︎セッション概要（500文字以内）
AWSやAzureの豊富な経験を持つエンジニアがGoogle Cloudを始める際、機能のマッピングはできても、Google Cloud独自の設計思想（IAM、インフラ、セキュリティなど）の違いに戸惑うことがあります。本セッションは、3大クラウドのプロである登壇者が、その経験と知見を体系化し、AWS/Azureの「常識」をGoogle Cloudの「流儀」へと切り替えるための実践的なマスター講座を提供します。
単なるサービス名対比ではなく、Google Cloudの核である階層型リソース、グローバルネットワーク、フルマネージドの哲学を深く掘り下げます。既存のスキルを最大限に活かし、最短でGoogle Cloudの設計・運用をマスターし、TCO削減や開発速度向上といった成果を出すためのナレッジを提供します。

◻︎想定オーディエンス・得られる学び（500文字以内）
想定オーディエンス
・AWSまたはAzureでシステム設計・運用経験があり、Google Cloudの導入・学習を主導するエンジニア、アーキテクト。
・マルチクラウド環境での技術選定や標準化を担当するCTO、Tech Lead、EMなどの技術リーダー層。
・Google Cloudのメリットを引き出すための設計思想を学びたい技術者。

得られる学び
・他社クラウドと比較したGoogle Cloudの設計思想：AWS/Azureの知識をGoogle Cloudの「流儀」にスムーズに接続するためのノウハウを獲得。特にIAMの管理単位やネットワークの考え方、セキュリティといった基盤技術の根本的な違いをマスターできます。
・Google Cloudの特徴を抑えた選定基準：Google Cloudの思想や特徴が具体的にどう運用コストや効率に結びつくかを理解し、サービス選定の判断基準を確立できます。

◻︎セッション詳細（1000文字程度）
AWSやAzureで深い経験を積んだエンジニアがGoogle Cloudに触れる際、最大の障壁となるのは「設計思想の違い」です。クラウドベンダー間のサービスのマッピングだけでは、Google Cloudが持つ真のポテンシャルを引き出すことはできません。本セッションでは、3大クラウドすべての資格を持ち、マルチクラウドセキュリティを専門とする登壇者が、AWSやAzureを引き合いに出しながら、Google Cloudの流儀を最短でマスターするための実践的ナレッジを伝授します。

まず議論の出発点となるのは、リソース管理と権限設計の根本的な違いです。AWSのアカウント単位の管理やAzureのサブスクリプション構造に対し、Google Cloudは「組織・フォルダ・プロジェクト」という厳格な階層構造を採ります。権限の「継承」という概念や、サービスアカウントを起点とした柔軟な認証基盤の設計手法など、AWS/Azureとの違いを示しながら、Google流のガバナンスを理解するためのポイントを整理します。

次に、ネットワーク設計の転換点について深掘りします。リージョンごとにVPCを構築し、ピアリングやTransit Gatewayで接続する手法に対し、Google Cloudは「グローバルVPC」を標榜しています。世界中のリージョンを跨いで単一のネットワークとして機能するこの特性を、いかにシンプルで低遅延なアーキテクチャに落とし込むか。「共有VPC」による管理と利用の分離など、実務で即座に役立つ構成パターンを提示します。

そして、Cloud RunやBigQueryに代表される「NoOps（運用負荷の最小化）」の哲学が、いかに開発スピードとTCOの最適化に直結するかを具体的に示します。

注意点として、本セッションはAWSやAzureをに対してGoogle Cloudの優位性を説くものでは決してなく、あくまでAWSやAzureの経験者がGoogle Cloudを学ぶきっかけ、そして、Google Cloudの経験者がほかクラウドについて知ってもらうことを目的としています。

本セッションを通じて、既存のスキルをGoogle Cloudの「流儀」へとスムーズに変換し、マルチクラウド時代に求められる「真のアーキテクト」としての視座を手に入れることができればと思います。

◻︎セッション概要（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文字以内）
「データはBigQueryにあるが、定義が曖昧でAIが誤答する」。
これはAIエージェント時代の致命的なリスクです。
人間は文脈で補完できますが、AIには厳密な意味（Semantics）の定義が不可欠です。

本セッションでは、BigQueryを計算エンジン、Lookerを意味の定義層、Vertex AIを推論エンジンとして統合するアーキテクチャを解説します。
単なるText-to-SQLではなく、Model Context Protocol (MCP) や Conversational Analytics API を活用し、AIがビジネスロジックに基づいて自律的かつ安全にデータを取得するデータ基盤の構築論。
ガバナンスとパフォーマンス（キャッシュ/コスト）の実装詳細まで、エンジニアリング視点で解説します。

◻︎想定オーディエンス・得られる学び（500文字以内）
【想定オーディエンス】
・生成AI (RAG/Agent) のハルシネーションや数字の不整合に悩むアーキテクト
・BigQuery上のデータをAIエージェントに安全に供給したいデータエンジニア
・Looker / LookML のモダンな活用法（MCP等）を知りたいTech Lead

【得られる学び】
・AIの「嘘」を防ぐための、LookMLによるセマンティックレイヤ（意味定義層）の設計思想
・Model Context Protocol (MCP) や Conversational Analytics API を用いた接続実装パターン
・BigQueryのコスト爆発を防ぐキャッシュ戦略とAggregate Awareness（集計認識）
・ガバナンスをコードで担保する基盤構築

◻︎セッション詳細（1000文字程度）
■ The Context：AIエージェントは「曖昧さ」に耐えられない
2026年に向けたデータ戦略の主役は「人間のアナリスト」から「自律型AIエージェント」へ移行します。
しかし、多くの組織でKPIの定義はBIツールの計算フィールドや個人のクエリに分散しており、これがAIのハルシネーションを引き起こす根本原因となっています。
本セッションでは、「ダッシュボード」ではなく、AIのための「信頼できるコンテキスト供給源」としてセマンティックレイヤを再定義します。

■ The Architecture：BigQuery × Looker × Vertex AI Google Cloudエコシステムにおける、役割を純化した3層アーキテクチャを解説します。

・Compute (BigQuery): ロジックを持たず、高速な実行エンジンに徹する。
・Semantics (Looker/LookML): ビジネスロジック、結合ルール、指標定義を一元管理し、API経由で提供する。
・Reasoning (Vertex AI): 定義された指標（Tool）を使って推論し、アクションを行う。

■ The Implementation (Deep Dive)：MCPとAPIによる接続
概念論だけでなく、具体的な実装パターンに踏み込みます。

Model Context Protocol (MCP) の衝撃: 2024-25年のトレンドであるMCP ServerとしてのLooker活用。
ClaudeやGeminiなどのLLMから、標準化されたプロトコルでセマンティックモデルに接続し、安全に社内データを取得する仕組み。

Conversational Analytics API & Agent Builder: Vertex AI Agent Builderにおいて、Lookerを「Tool」として登録し、自然言語から正確な指標（Metrics）を引き出すための実装フロー。Text-to-SQLの危険性を回避し、検証済みのロジックのみを実行させる設計。

■ The Reality：泥臭いエンジニアリングの壁 AIエージェントの実運用で直面する課題への解を共有します。

パフォーマンスとコスト: AIは人間よりも頻繁にクエリを投げる。
BigQueryの意図しない高額課金を防ぎ、数秒以内のレスポンスを返すための「Aggregate Awareness（集計認識機能）」とキャッシュ戦略。

ガバナンスの強制: プロンプトインジェクションへの対策。
AI経由のアクセスであっても、行レベルセキュリティ（RLS）を強制し、ユーザー権限に応じたデータのみを返す仕組み。

■ Conclusion
「意味」を持たないデータ基盤は、AI時代において負債となります。
LookMLで組織の「横串」を通し、データを真にアクション可能な資産へと変えるためのエンジニアリング手法をお伝えします。

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

本セッションでは、NotebookLM Enterprise APIを活用し、組織のナレッジ管理を効率化する「ノートブック管理の自動化」について解説します。NotebookLMは強力な調査・作成ツールですが、元ファイルが更新されてもノートブック内のソースは自動同期されず、手作業によるメンテナンスが運用上の課題です。
そこで本セッションでは、Googleドライブ上の特定フォルダとNotebookLMを同期させるアーキテクチャを紹介します。具体的には、Google Workspace Events API（デベロッパープレビュー）を利用してファイル操作イベントを検知し、Cloud Pub/SubとPythonスクリプトを介して、ノートブックの新規作成やソースの追加・更新を自動実行する仕組みです。

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

想定オーディエンス

• 社内ドキュメントの散在やナレッジ管理のコストに課題を感じている方
• Google Cloud でのイベント駆動アーキテクチャの実装詳細を知りたいエンジニア
• NotebookLM を Web UI だけでなく API レベルでハックし、業務システムに組み込みたい開発者

得られる学び

• Google Workspace Events APIとNotebookLM Enterprise APIを連携させ、Googleドライブ上のファイル操作をトリガーにノートブックを自動更新する具体的なアーキテクチャ

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

1. 導入
   本セッションでは、NotebookLM Enterprise APIでノートブック管理を自動化する、エンタープライズ環境での運用に耐えうるアーキテクチャについて解説します。
   またNotebookLMの運用においていは、「ソースデータの鮮度維持」が最大のボトルネックとなります。「誰がファイルをアップロードするのか？」「元ファイルが更新された後、ソース更新を誰が行うか？」この問いに対する我々の回答は、徹底的な「自動化」です。
   　
2. アーキテクチャ解説
   API で NotebookLM を「システム」にする Google Drive 上のドキュメント変更をリアルタイムに検知し、NotebookLM に反映させるイベント駆動パイプラインの全貌を公開します。
   • イベント検知：Google Workspace Events API を利用し、特定のフォルダやファイルの変更（追加・更新・削除）を低遅延でフックします 。
   • 流量制御とバッファリング：ドキュメント更新の都度イベントが発生するため、イベントごとにNotebookLMのソース更新を行うことは非効率であるため、Pub/Subを挟んで処理をキューイング・平準化する設計パターンを紹介します 。
   • 実行基盤：Cloud Run 上で動作する Controller が、API を通じてソースの Re-sync を実行します。
     　
3. 技術的な深掘りポイント「理論上動く」だけでなく、エンタープライズ環境での運用に耐えうる構成にフォーカス
   • エラーハンドリングの実際: 同期処理が失敗した場合のリトライ戦略と、それでも処理できなかったイベントを Dead Letter Queue (DLQ) に退避させ、検知・復旧させる運用の仕組み 。
     　
4. まとめ
   ドキュメントが「生き返る」未来。利用者はただドキュメントを書くだけ。裏側で API が走り、NotebookLM が賢くなる。「ドキュメント管理」という枯れた課題に対し、最新の Google Cloud 技術を組み合わせることで、どのように組織の生産性を変えられるか。その可能性と「Google Cloud への愛」を語ります。

◻︎セッション概要（500文字以内）
サーバーレス環境で大量イベント処理や高頻度バッチを運用する際、
「Cloud RUn functions が詰まる」「メモリ不足で処理が落ちる」「同時実行が制御できずコストが増加する」といった課題は多くの現場で発生しています。
本セッションでは、Google WorkflowsとCloud Run functions と Cloud Tasks を組み合わせてキュー駆動の並列処理基盤を構築し、
スループット向上とメモリ最適化を同時に実現した具体的なアーキテクチャと改善プロセスを紹介します。

Cloud Tasks のディスパッチ制御、Cloud Run のメモリ・CPU設定、コンカレンシーの考え方、ワーカーデザイン、リトライ戦略、可観測性の設計など、
実運用ならではの知見を詳細に共有します。
諦めていたユースケースでもサーバーレスでもまだやりようはある！と運用改善のヒントを求める方に役立つ内容です。

◻︎想定オーディエンス・得られる学び（500文字以内）
想定オーディエンス
・Cloud Run / Cloud Functions を用いて ETL・イベント処理を運用するエンジニア
・高スループットなサーバーレス基盤を構築したいアーキテクト
・キュー駆動の分散処理に興味がある開発者
・Google Cloud 上で安定性・コスト最適化を両立したい技術リーダー

得られる学び
・Cloud Tasks を中心とした“キュー駆動アーキテクチャ”の設計パターン
・Cloud Run のメモリ配分・CPU設定・コンカレンシーの最適化方法
・詰まり・過負荷・急増するイベントに対処する並列実行の考え方
・大量処理で失敗しやすいポイントと、それを避ける設定・監視手法
・サーバーレス環境で高スループットと安定性を両立させる実践知

◻︎セッション詳細（1000文字程度）
本セッションでは、Cloud Run functions と Cloud Tasks を組み合わせた「高スループットかつ安定性の高いサーバーレス処理基盤」をどのように設計し、どのように改善し、どのように運用しているかを具体的に解説します。

まず、従来の Cloud Run functions 単体運用で発生していた課題を整理します。具体的には「同時実行制御が困難」「メモリ不足による処理失敗」「突発的なイベント増加に対するスケール追従の遅延」「エラー発生時の再処理が複雑」など、現場で実際に起きた問題を提示します。
次に、それらを解決するためのアーキテクチャとして Cloud Tasks を導入し、イベントをキューに積んで非同期分散処理させる構成を紹介します。Cloud Tasks のレート制限・ディスパッチ設定・キュー分割戦略を活用し、業務に応じた「スレッド数」を柔軟に設計する方法を実例を交えて解説します。

さらに Cloud Run 側では、メモリ・CPU・timeout・コンカレンシーの適切な設定を検証しながら最適化しました。特にメモリ配分の見直しにより、処理安定性の向上とコスト削減を両立させたプロセスは多くの現場で応用できます。また、ワーカー設計、エラー／リトライポリシー、idempotency の考慮、ログ・メトリクスを中心とした可観測性の組み込みなど、実運用で不可欠な要素も整理して紹介します。
最後に、今回のアーキテクチャが ETL・スクレイピング・Webhook 処理などさまざまなユースケースに適用できる汎用性の高さを示し、他プロジェクトにも展開可能な設計原則としてまとめます。

◻︎セッション概要（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文字以内）

近年、本番環境はもちろん、ローカルの開発環境に対しても安全性と再現性を重視する傾向があります。
特に破壊性のあるAIツールやエージェントを利用すると、機密情報の扱いや万が一の環境再構築が悩ましいです。
開発チームの開発環境の統一化や、新しいチームメンバーのオンボーディングなど、個人だけでなく組織が抱えている悩みもあります。

本セッションでは、その悩みに答えるCloud Workstationsを紹介し、安全性・再現性を重視した開発環境の構築方法を共有します。
他製品との比較、基本的な環境の作り方、注意すべきな落とし穴をカバーします。
最後に公式ドキュメントにない、よりシンプルなCloud Workstationsへの接続方法を紹介します。

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

• 想定オーディエンス

  開発環境をより安全にしたい方
  開発環境の再構築を自動化させたい方
  組織レベルでオンボーディングをよりシンプルにしたい方

• 得られる学び

  Cloud Workstationsの特徴、他製品との比較の判断材料
  Cloud Workstationsを用いた環境の構築方法
  注意すべきな落とし穴、ローカルの開発環境との違い
  Cloud Workstationsにワンクリックでの接続方法

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

株式会社スリーシェイクのフルスタックエンジニアとして、主にクライアントワークを行なっていてるため、安全性と再現性を徹底する必要があります。
破壊性の持つ技術を導入すると、機密情報は漏洩されないか、開発環境は破壊しないか、どんな環境でもうまくいくか...といった悩みがあります。
ローカルの開発環境ではなかなか解消できない悩みですし、AIエージェントなど導入するとさらに悩みが増えます...

そこで、Cloud Workstationsを導入しました。セキュリティと再現性を重視し構築されており、日々の開発がより楽になりました。
本セッションでは、以下について解説します。
Cloud Workstationsとは何か、なぜ使用するのか
Cloud Workstationsでの開発環境の構築方法
ブラウザまたはローカルのIDEからCloud Workstationsに接続する方法
さらに公式ドキュメントに載っていない、ローカルのIDEからワンステップでCloud Workstationsを起動する方法も紹介します。

「機密情報の漏洩を防げたい」「安全に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文字以内）
ファインディ株式会社では複数のプロダクトを展開し、横断的に集まるエンジニア行動データを企業価値の源泉としています。この構造を支えるため、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文字以内）
ClaudeなどのAPIで提供していないカスタムモデルをCloud Run GPUに公開する際、大量のアセットをコンテナイメージにCOPYしていませんか？数GB単位の巨大なイメージが出来上がり、デプロイ時間の増大やコンテナレジストリコストの無駄を招いています。

このトークでは、コンテナイメージの最小化に関するアーキテクチャーについて説明します

◻︎想定オーディエンス・得られる学び（500文字以内）
開発者
デプロイ時間の高速化、初期ロードの高速化手法、Cloud Runのsidecar機能を使ったアセットデータ連携フロー

◻︎セッション詳細（1000文字程度）
Cloud Run には初期起動時にCloud Storageからコピーしてvolumeに保存したり、FUSEでCloud Storageにマウントすることができます。2手法のメリット、デメリットを語りたいと思います

ビルド時間の短縮、イメージの軽量化、再デプロイなしでアセットの更新が可能になります。