プロポーザル

◻︎セッション概要（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手法のメリット、デメリットを語りたいと思います

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