Upgrade to Pro — share decks privately, control downloads, hide ads and more …

認知負荷をGemini で溶かす — GKE 基盤「Orbit」における AI エージェントの実践

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

認知負荷をGemini で溶かす — GKE 基盤「Orbit」における AI エージェントの実践

■ イベント
Google Cloud Next Tokyo
https://www.googlecloudevents.com/next-tokyo/

■登壇概要
タイトル:認知負荷をGemini で溶かす — GKE 基盤「Orbit」における AI エージェントの実践
登壇者:技術本部 Platform Engineering Unit Application Platform グループ プロダクトマネジャー 辻田 美咲

■ 技術本部 採用情報
https://media.sansan-engineering.com

Avatar for SansanTech

SansanTech PRO

August 03, 2026

More Decks by SansanTech

Other Decks in Technology

Transcript

  1. 辻田 美咲 Sansan 株式会社 技術本部 Platform Engineering Unit Application Platform

    グループ プロダクトマネジャー Google Cloud Next Tokyo Proprietary
  2. 今日話すこと Google Cloud Next Tokyo 01 基盤 矛盾 02 Orbit

    と 何か / なぜ作ったか 03 新たな壁 04 解決策 Orbit AI Agent 05 数字で語る改善効果 06 これから 07 3 つ テイクアウェイ Platform Engineering Proprietary
  3. 複雑さを隠した に、なぜ新たな壁が生まれた か? Platform Engineering 本質 ところが … 複雑さ 吸収

    抽象化が、新たな認知負荷を生んだ インフラ・CI/CD・監視・セキュリティを 「ゴールデンパス」として抽象化し、 開発者をプロダクト開発に集中させる。 「基盤を高度にするほど、学ぶことが増える」 という、Platform Engineering が抱える矛盾。 「ど ツールをいつ使う Google Cloud Next Tokyo か分かりづらい」「基盤 学習コストがかかる」 Proprietary
  4. 本日 結論(先に言います) Platform Engineering 本質 "複雑さ 吸収 " 。 しかし、そ

    複雑さ自体も育つ。 AI エージェント ー こ 主張を、 Orbit Google Cloud Next Tokyo そ 矛盾を解く新しい武器だ。 ” 実践と数字で証明していきます。 Proprietary
  5. Orbit と ー 内部開発者プラットフォーム 組織が本質的な課題(プロダクト開発)に取り組む時間を最大化するために構築した、内部開発者 プラットフォーム。GKE Autopilot を中核に、運用 定型作業を「ゴールデンパス」として統合提供 する。

    GKE Autopilot CI / CD 中核技術。 Node 運用 設定ファイル マネージドに任せる。 CI、デプロイ パイプラインを標準提供 監視 / Observability セキュリティ / NW モニタリング ダッシュボード・OTel Collector を標準提供 ポリシー準拠 Google Cloud Next Tokyo ガードレールと公開経路 標準化 Proprietary
  6. 散発する課題を、標準化で解決してきた BEFORE ー 散発していた課題 AFTER ー Orbit が提供した価値 • •

    • • • • 各チームが都度インフラを独自構築 Terraform と実環境 乖離 品質・セキュリティ・安定性が属人化 監視ダッシュボード 管理崩壊 セキュリティ・コスト意識 希薄化 • • • • Google Cloud Next Tokyo Helm テンプレートで周辺を標準化、ブー トストラップが容易に インフラ構築コストを削減、プロジェクト固 有設定に集中 自動適用されるガードレール 監視ダッシュボード(Workload / LB / OTel / コスト)を標準提供 Self-hosted runner・負荷試験環境も提 供 Proprietary
  7. プロダクトとして、フィードバックループを回す Orbit を「プロダクト」として捉え、ユーザー 声を聞き、分析・改善する。 四半期に 1 度 月に 1 度

    満足度アンケート+ユー ザーインタビュー。 MAU・Namespace・App lication 数を定量分析 オフィスアワー。気軽に質 問・フィードバックできる 場を常設 HEART Happiness , Engagement , Adoption , Retention , Task success で体験を可視化 Google Cloud Next Tokyo Proprietary
  8. ユーザー インタビューで見えた、新たな壁 開発チーム視点 Platform チーム視点 • • • • 新規利用まで

    認知負荷が高い トラブルシュート時に k8s 知識が必要 になる Cloud Run で できる に Orbit で で きないことがある(同時実行制御・scale to 0 など) Google Cloud Next Tokyo • • ドキュメントに書いてあることを質問される ことが多い 特定ユースケースに特化した機能をリク エストされる Cloud Run と機能を比較され、「Cloud Run 方が楽」と言われる Proprietary
  9. 何をやり、何をやらないかを RICE で決める 判断軸 : RICE スコア • • •

    • • Reach — 影響チーム規模(5 人以下 〜 20 人以上) Impact — チーム人数 × ユーザー数 × プ ロダクト成長度 Confidence — 確信度 Effort — 工数 熱心なユーザー 声 優先度を上乗せ Google Cloud Next Tokyo 「やらない」と決めた例 ステートフルなサービス 個別性が高く、抽象化が逆に制約に。権限管理・データ 保持ポリシーなどプロダクト固有 制約が基盤に波及 し管理コストが増大するため。 Cloud Run 模倣をすること 技術的に 可能だが、メンテコストが高く長期投資 妥 当性に欠ける。 Proprietary
  10. 24 / 365 で稼働する、 Orbit パート 認知負荷 ドメイン エキス 正体

    「学ぶこと・聞くこと・覚えること」 多さ。それを AI エージェントが肩代わりする ドキュメント検索 : 必要な情報にすぐたどり着ける FAQ 対応 : AI なら気軽に聞ける オンボーディング作業 代行 : 覚えなくていい手順 Google Cloud Next Tokyo AI に任せる Proprietary
  11. マルチ エージェント構成 🛠 Onboarding Agent — 作業代行 🤖 Orbit Coordinator

    親エージェント ユーザー 意図を判断しタスク振 り分け Git 操作・PR 作成 / Workflow 実行 📚 Docs Search Agent — 知識検索・ 回答 Gemini Enterprise でドキュメント検索+回答生 成 Google Cloud Next Tokyo Proprietary
  12. アーキテクチャ GKE Autopilot Cluster Frontend CopilotKit Orbit Coordinator Parent Agent

    Onboarding Sub Agent Docs Search Sub Agent Docs GitHub Actions Google Cloud Next Tokyo Proprietary
  13. ガードレール設計 ー 自律実行と安全性 両立 AI Agent k8s マニフェスト生成 Terraform 編集

    PR 作成 変更 すべて PR に エージェントに与える権限 • • • ファイル編集 GitHub Actions Workflow 実行 PR を出すところまで 自律実行 Google Cloud Next Tokyo 人間レビュー・承認 レビューする 人間 GitOps / CD マージで自動反映 与えない権限 • • Google Cloud / Argo CD 直接更新 しない 稼働中クラスターへ 変更 人間がレビュー・承 認 Proprietary
  14. ドキュメント グラウンディング 1 2 3 4 1 Git リポジトリ パイプライン

    AI Agent ドキュメントを GitHub で管理 ドキュメント更新時に Cloud Storage へ自動アップ ロード Cloud Storage → Gemini Gemini Enterprise に同期 根拠付き ( grounded ) で ユーザーに回答 AI エージェント ドキュメント 根拠に基づいて回答する。 複雑な部分 隠蔽し、k8s 知識が要る場面 Platform チームがサポート。 Google Cloud Next Tokyo Proprietary
  15. オンボーディング時間 短縮と、利用 広がり 2 日以内 9 チーム 40 名 オンボーディング時間

    利用チーム数 アクティブ ユーザー数 -50% 前年比 4 倍 前年比 3 倍 開発者 声 「人間よりも気軽に質問ができて、ドキュメントを探す手間が省けた」 「データ エンジニアでも簡単にアプリをデプロイできた」 Google Cloud Next Tokyo Proprietary
  16. 開発生産性 : デプロイ頻度 ↑・リードタイム ↓ 2025/5/25 ~ 31 vs 2026/5/25

    ~ 31(Orbit 利用リポジトリ平均) 週間削減工数 = 約 117 時間(1 PR あたり 5.1h 短縮 × 23 回、1 人あたり 2.9 時間) Google Cloud Next Tokyo Proprietary
  17. サポート負荷 削減と、高い満足度 - 26 % 100 % 75 % 問い合わせ件数

    (前 3 ヶ月比) 「サポート体制 充実 していますか?」 NPS 推奨者率 肯定回答 AI とオフィスアワー 両輪でナレッジ共有を定常化 Google Cloud Next Tokyo Proprietary
  18. Cloud Run と Orbit (GKE) ー 使い分け Cloud Run —

    個別最適化 • • • • 高度に抽象化されたマネージドサービス LB 不要で URL 発行、IAP 認証、強力な 同時実行制御、scale to 0 インフラを意識せずコード開発に集中でき る 各チームが個別実装する場合、チーム数 が増えるほど管理コスト増大 Google Cloud Next Tokyo 結論 Orbit (GKE) — 組織全体 化 • • • • • 最適 標準化と柔軟性・拡張性を両立 可観測性・セキュリティ・監査/証跡を標準化し て提供 組織知・ドメイン知識を全体で共有できる 同一稼働時間における GKE 金銭コスト優 位性 利用チーム数が増えるほどコスト・運用面で 全体最適が効く Proprietary
  19. 次 ステップ ー 全社 「Agent 基盤」 AI ナレッジを集約する AI に「こういうも

    がほしい」を言語化できれ ソフトウェアを作れる時代。 で 、乱立するインフラ 運用・セキュリティ・監査・組織最適化 ? 類似エージェント・評価 重複開発を削減し、他チーム 知見を再利用 有用なエージェント・ MCP サーバー・ Skill を組織で共有(個別構築・利用可否判断が 不要に) コンテキスト 共有、ツールへ アクセス統制 監査・証跡対応 Google Cloud Next Tokyo 一元化 Proprietary
  20. Platform Engineering 本質 "複雑さ 吸収 " 。 しかし、そ 複雑さ自体も育つ。 AI

    エージェント Google Cloud Next Tokyo そ 矛盾を解く新しい武器だ。 ” Proprietary
  21. Orbit ビジョン ステートメント(要点) 目指す世界 すべて 開発者が運用 複雑さから解放され、自信とスピードをもってアプリ開発に没 頭できる。運用 責任と知識が一元化され、統制・監視・セキュリティ・監査が全チームに自動適用さ れることで、Sansan

    が長期にスケールし続けられる。 方針 ① TVP(Thinnest Viable Platform)で共通課題を一箇所に集約し、Namespace 内で完結する ゴールデンパスを提供。 ② 既存クラウドを再発明せず、組織知・ドメイン知識という自分たちにしか築 けない差別化領域へ投資。 4 つ 価値 高品質(k8s ベスト プラクティス内蔵)/ セキュア(ポリシー準拠ガードレール・監査一元 化)/ 安定性(可観測性・自動復旧)/ 頼れる伴走(Agent・ナレッジ・Platformチーム)。 Google Cloud Next Tokyo Proprietary