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

辻田 美咲 Sansan 株式会社 技術本部 Platform Engineering Unit Application Platform グループ プロダクトマネジャー Google Cloud Next Tokyo Proprietary 

今日話すこと Google Cloud Next Tokyo 01 基盤 矛盾 02 Orbit と 何か / なぜ作ったか 03 新たな壁 04 解決策 Orbit AI Agent 05 数字で語る改善効果 06 これから 07 3 つ テイクアウェイ Platform Engineering Proprietary 

01. 基盤 Google Cloud Next Tokyo 矛盾 Proprietary 

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

本日 結論（先に言います） Platform Engineering 本質 "複雑さ 吸収 " 。 しかし、そ 複雑さ自体も育つ。 AI エージェント ー こ 主張を、 Orbit Google Cloud Next Tokyo そ 矛盾を解く新しい武器だ。 ” 実践と数字で証明していきます。 Proprietary 

02. 背景 Orbit と 何か / なぜ作っ たか Google Cloud Next Tokyo Proprietary 

Orbit と ー 内部開発者プラットフォーム 組織が本質的な課題（プロダクト開発）に取り組む時間を最大化するために構築した、内部開発者 プラットフォーム。GKE Autopilot を中核に、運用 定型作業を「ゴールデンパス」として統合提供 する。 GKE Autopilot CI / CD 中核技術。 Node 運用 設定ファイル マネージドに任せる。 CI、デプロイ パイプラインを標準提供 監視 / Observability セキュリティ / NW モニタリング ダッシュボード・OTel Collector を標準提供 ポリシー準拠 Google Cloud Next Tokyo ガードレールと公開経路 標準化 Proprietary 

散発する課題を、標準化で解決してきた BEFORE ー 散発していた課題 AFTER ー Orbit が提供した価値 ● ● ● ● ● ● 各チームが都度インフラを独自構築 Terraform と実環境 乖離 品質・セキュリティ・安定性が属人化 監視ダッシュボード 管理崩壊 セキュリティ・コスト意識 希薄化 ● ● ● ● Google Cloud Next Tokyo Helm テンプレートで周辺を標準化、ブー トストラップが容易に インフラ構築コストを削減、プロジェクト固 有設定に集中 自動適用されるガードレール 監視ダッシュボード（Workload / LB / OTel / コスト）を標準提供 Self-hosted runner・負荷試験環境も提 供 Proprietary 

プロダクトとして、フィードバックループを回す Orbit を「プロダクト」として捉え、ユーザー 声を聞き、分析・改善する。 四半期に 1 度 月に 1 度 満足度アンケート＋ユー ザーインタビュー。 MAU・Namespace・App lication 数を定量分析 オフィスアワー。気軽に質 問・フィードバックできる 場を常設 HEART Happiness , Engagement , Adoption , Retention , Task success で体験を可視化 Google Cloud Next Tokyo Proprietary 

03. 新たな壁 解決した ずが、新たな 壁が生まれた Google Cloud Next Tokyo Proprietary 

ユーザー インタビューで見えた、新たな壁 開発チーム視点 Platform チーム視点 ● ● ● ● 新規利用まで 認知負荷が高い トラブルシュート時に k8s 知識が必要 になる Cloud Run で できる に Orbit で で きないことがある（同時実行制御・scale to 0 など） Google Cloud Next Tokyo ● ● ドキュメントに書いてあることを質問される ことが多い 特定ユースケースに特化した機能をリク エストされる Cloud Run と機能を比較され、「Cloud Run 方が楽」と言われる Proprietary 

何をやり、何をやらないかを RICE で決める 判断軸 : RICE スコア ● ● ● ● ● Reach — 影響チーム規模（5 人以下 〜 20 人以上） Impact — チーム人数 × ユーザー数 × プ ロダクト成長度 Confidence — 確信度 Effort — 工数 熱心なユーザー 声 優先度を上乗せ Google Cloud Next Tokyo 「やらない」と決めた例 ステートフルなサービス 個別性が高く、抽象化が逆に制約に。権限管理・データ 保持ポリシーなどプロダクト固有 制約が基盤に波及 し管理コストが増大するため。 Cloud Run 模倣をすること 技術的に 可能だが、メンテコストが高く長期投資 妥 当性に欠ける。 Proprietary 

04. 解決策 Orbit AI Agent Google Cloud Next Tokyo Proprietary 

24 / 365 で稼働する、 Orbit パート 認知負荷 ドメイン エキス 正体 「学ぶこと・聞くこと・覚えること」 多さ。それを AI エージェントが肩代わりする ドキュメント検索 : 必要な情報にすぐたどり着ける FAQ 対応 : AI なら気軽に聞ける オンボーディング作業 代行 : 覚えなくていい手順 Google Cloud Next Tokyo AI に任せる Proprietary 

マルチ エージェント構成 🛠 Onboarding Agent — 作業代行 🤖 Orbit Coordinator 親エージェント ユーザー 意図を判断しタスク振 り分け Git 操作・PR 作成 / Workflow 実行 📚 Docs Search Agent — 知識検索・ 回答 Gemini Enterprise でドキュメント検索＋回答生 成 Google Cloud Next Tokyo Proprietary 

アーキテクチャ GKE Autopilot Cluster Frontend CopilotKit Orbit Coordinator Parent Agent Onboarding Sub Agent Docs Search Sub Agent Docs GitHub Actions Google Cloud Next Tokyo Proprietary 

ガードレール設計 ー 自律実行と安全性 両立 AI Agent k8s マニフェスト生成 Terraform 編集 PR 作成 変更 すべて PR に エージェントに与える権限 • • • ファイル編集 GitHub Actions Workflow 実行 PR を出すところまで 自律実行 Google Cloud Next Tokyo 人間レビュー・承認 レビューする 人間 GitOps / CD マージで自動反映 与えない権限 • • Google Cloud / Argo CD 直接更新 しない 稼働中クラスターへ 変更 人間がレビュー・承 認 Proprietary 

ドキュメント グラウンディング 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 

実際 動き エージェントへ 質問、回答 Google Cloud Next Tokyo Proprietary 

実際 PR 動き 作成 Google Cloud Next Tokyo Proprietary 

05. 成果 数字で語る改善効果 Google Cloud Next Tokyo Proprietary 

オンボーディング時間 短縮と、利用 広がり 2 日以内 9 チーム 40 名 オンボーディング時間 利用チーム数 アクティブ ユーザー数 -50% 前年比 4 倍 前年比 3 倍 開発者 声 「人間よりも気軽に質問ができて、ドキュメントを探す手間が省けた」 「データ エンジニアでも簡単にアプリをデプロイできた」 Google Cloud Next Tokyo Proprietary 

開発生産性 : デプロイ頻度 ↑・リードタイム ↓ 2025/5/25 ~ 31 vs 2026/5/25 ~ 31（Orbit 利用リポジトリ平均） 週間削減工数 = 約 117 時間（1 PR あたり 5.1h 短縮 × 23 回、1 人あたり 2.9 時間） Google Cloud Next Tokyo Proprietary 

サポート負荷 削減と、高い満足度 - 26 % 100 % 75 % 問い合わせ件数 (前 3 ヶ月比) 「サポート体制 充実 していますか？」 NPS 推奨者率 肯定回答 AI とオフィスアワー 両輪でナレッジ共有を定常化 Google Cloud Next Tokyo Proprietary 

06. これから Platform Engineering Google Cloud Next Tokyo Proprietary 

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

次 ステップ ー 全社 「Agent 基盤」 AI ナレッジを集約する AI に「こういうも がほしい」を言語化できれ ソフトウェアを作れる時代。 で 、乱立するインフラ 運用・セキュリティ・監査・組織最適化 ？ 類似エージェント・評価 重複開発を削減し、他チーム 知見を再利用 有用なエージェント・ MCP サーバー・ Skill を組織で共有（個別構築・利用可否判断が 不要に） コンテキスト 共有、ツールへ アクセス統制 監査・証跡対応 Google Cloud Next Tokyo 一元化 Proprietary 

3つ テイクアウェイ 1. ユーザー 声を聞き、分析する 2. なにをやらないかを決める 3. 長期にスケールし続けられる領域に投資する Google Cloud Next Tokyo Proprietary 

Platform Engineering 本質 "複雑さ 吸収 " 。 しかし、そ 複雑さ自体も育つ。 AI エージェント Google Cloud Next Tokyo そ 矛盾を解く新しい武器だ。 ” Proprietary 

Orbit ビジョン ステートメント（要点） 目指す世界 すべて 開発者が運用 複雑さから解放され、自信とスピードをもってアプリ開発に没 頭できる。運用 責任と知識が一元化され、統制・監視・セキュリティ・監査が全チームに自動適用さ れることで、Sansan が長期にスケールし続けられる。 方針 ① TVP（Thinnest Viable Platform）で共通課題を一箇所に集約し、Namespace 内で完結する ゴールデンパスを提供。 ② 既存クラウドを再発明せず、組織知・ドメイン知識という自分たちにしか築 けない差別化領域へ投資。 4 つ 価値 高品質（k8s ベスト プラクティス内蔵）／ セキュア（ポリシー準拠ガードレール・監査一元 化）／ 安定性（可観測性・自動復旧）／ 頼れる伴走（Agent・ナレッジ・Platformチーム）。 Google Cloud Next Tokyo Proprietary 

Ask the Speaker にぜひお越しください（会場は 4F） Proprietary セッションに関する質問にスピーカーが直接お答えします！ Room Room Room Room 9 8 6 7 Ask the Speaker 出入口 Google Cloud Next Tokyo Thank you 出入口 032 

Thank you Proprietary