AIエージェントを前提としたプラットフォーム エンジニアリング：GKEで作るAgent-Ready Golden Path

こちらは「Google Cloud Next Tokyo」登壇資料です。
AI エージェントを前提としたプラットフォームエンジニアリングについて、Context Engineering・Connection・Guardrail の3本柱で、GKE 上に Agent-Ready な Golden Path を構築する取り組みをご紹介します。

Transcript

1. AI エージェントを前提としたプ ラットフォーム エンジニアリン グ: GKE で作るAgent-Ready Golden Path Proprietary
2. 杉田 寿憲 株式会社 LegalOn Technologies Director of Platform Engineering Google Cloud Next Tokyo Proprietary
3. 伊藤 理人 株式会社 LegalOn Technologies Senior SRE Google Cloud Next Tokyo ※画像の置換方法 グレーボックスを選択し、 右ク リックで「画像を置換」 を選択 し、配置したい画像に差し替え てください。本テキストは削除し てください。 Proprietary
4. 小市 貴大 株式会社 LegalOn Technologies Senior Engineering Manager Google Cloud Next Tokyo Proprietary
5. 01 02 03 04 Google Cloud Next Tokyo Introduction Context Engineering Connection Guardrail Proprietary
6. 01. Introduction Google Cloud Next Tokyo Proprietary
7. About LegalOn Technologies LegalOn Technologiesは、AI 分野における高度な技術力と法律・契約の専門知識を兼ね備えた Professional AI for Legal のグ ローバル リーディング カンパニーです。設立当初から、AI を活用したリーガル AI サービスの開発に注力し、大規模言語モデル （LLM）や AI エージェントなど最先端の AI 技術を製品開発に取り入れ、多様な企業課題に応えるソリューションでお客様のビジネ スを支援します。 会社名 ～Our Purpose～ すべてのプロフェッショナルに、 驚きと感動を。 設立 2017年4月21日 従業員数 632名（役員含む／ 2026年4月時点） 所在地 〒150-6219 東京都渋谷区桜丘町 1-1 渋谷サクラステージ SHIBUYAタワー19F 資本金 Google Cloud Next Tokyo 株式会社LegalOn Technologies 201.5億円（資本準備金等含） Proprietary
8. 法務 AI のグローバル リーダー Google Cloud Next Tokyo 8,500+ 600人+ 30 人+ グローバルでの有償顧客数 * 従業員数 全拠点合計 弁護士資格保有者数 日本、NY州、CA 州、ドイツの資格者を含む 1,000+ 200人+ 上場企業の導入社数 ※全上場企業社数 3,800 社 開発チーム人数 約 286 億円 ゴールドマン・サックス、ソフトバン クなどが出資。全調達ラウンド累 計 *2026年3月末時点。当社およびグループ各社が提供する Professional AIの有償導入社数 Proprietary
9. LegalOn Technologies/ On Technologies が提供する Professional AI 群と 対応ドメイン
10. 全社アプリケーション プラットフォーム「Akupara（アクパーラ）」 What is Akupara ? LegalOn Technologies でプロダクト開発を行うにあたり、プロダクト ライフサイクルを自律的に回すための社内開発者向けプロダクト チームが認知負荷低くソフトウェア開発 Mission and Vision of Akupara 開発者にゴールデンパスと堅牢なインフラを提供し、創造的な開発に集中できるようにする
11. Akupara の基本方針 ドキュメント サポート Production readiness Check トレーニング オフィスアワー サービス カタログ 課題の投稿・投票 Interface 「LegalOn」 開発者 XXX 開発者 YYY 開発者 Proto 生成コード管理 言語毎のテンプレート 言語毎のライブラリ Build CI テンプレート Playwright Job デプロイ時自動実行 負荷試験基盤 Test GitOps デプロイ DB マイグレーション 単発 Job の実行 Feature flag Deploy モニタリング ダッシュボード SLO ベースのアラート エラー発生時のログ、 メトリクス、トレース連携 脆弱性管理 暫定的権限昇格 Operate Platform Infrastructure Kubernetes 管理 DB 管理 FinOps セキュリティ認証対応 各種法令準拠 サービス メッシュ Web Application Firewall CDN
12. プロダクト インフラ Sensitive Con g Secret Manager Internal Cloud Armor Cloud Service Mesh Gateway Cloud Load Balancing Cloud DNS Event Processing Systems Pub/Sub Container Infra Google Kubernetes Engine (GKE)/Kubernetes Database AlloyDB External SaaS User Contents Cloud Storage
13. 開発インフラ GKE Project push image GKE(JP app) GKE(US app) GKE(EU app) GKE(SG app) App repo sync observe fetch manifest Infra repo GKE(DevOps) notify
14. Akupara を取り巻く環境の変化 これまで これから 開発者（人間） 実装主体としての AI エージェント 人がゴールデンパスに沿ってコードを書き、ビ AI エージェントがコードを書き、検証し、デプロイま ルド・テスト・デプロイの各工程を操作しながら SDLC を回す。 プラットフォームを利用する開発者の変化 → で進める。人間は意図を伝え、レビューする側へ。 — AI エージェントを利用する開発者と、実装主体としての AI エージェント。その両方が Akupara のユーザーになる。 Google Cloud Next Tokyo Proprietary
15. 直面している課題 コンテキストの過不足 フィードバックが遅い 安全性・監査性が不足 設計思想・規約・実行環境の文 脈が、エージェントに適切な量 で届かない。足りなければ品質 が揺らぎ、多すぎればノイズに なる。 実装は速くなる一方、検証・デ プロイ・リリースの待ち時間が 開発全体を律速する。 多層の品質ゲートで、安全性と 監査性を担保する。 Google Cloud Next Tokyo Proprietary
16. AI エージェント時代のプラットフォームを つくるための 3 本柱 Context Engineering Connection Guardrail 静的・動的コンテキストを分類 し、適切な量を適時エージェント に供給する。 ローカルと実行環境をつなぎ、 フィードバック ループを高速化 する。 多層の品質ゲートで、安全性と 監査性を担保する。 Google Cloud Next Tokyo Proprietary
17. 02. Context Engineering Google Cloud Next Tokyo Proprietary
18. AI エージェントの進化 AI エージェントは「コード生成器」から 「設計・開発・運用を横断する協働者」へ AI エージェントの性能差はモデルではなく、 与えられたコンテキストとハーネスの差で決まる Google Cloud Next Tokyo Proprietary
19. コンテキスト エンジニアリング 「エージェントが何を、いつ、どう見るか」の設計 モデルは「十分なコンテキスト」さえあれば大半のタスクで十分な品質に達する – 今後は「より良いコンテキスト」を投資の中心に — AI 自動化の重要な基盤 認知負荷理論との接続 – 人間も LLM も、関連情報を一貫した構造で提示すると推論効率が上がる – context window 内の位置・密度・関連性で取り出し精度が変わり、無関係情報はノイズ Google Cloud Next Tokyo Proprietary
20. SDLC を貫くコンテキスト供給 設計 運用 宣言的プロダクト プロビジョニング Google Cloud / Datadog / GitHub MCP 約 50 本のプラットフォーム ガイドラインの Skill 化 各種調査用 Skill を準備 開発 Skill でアプリ ↔ インフラの対応関係をコンテキストとして注入 独自のナレッジグラフを作成し依存関係を構造化 各種開発フロー・手順を Skill 化 Google Cloud Next Tokyo Proprietary
21. ナレッジグラフ：構造化されたコンテキスト 課題：ドキュメントだけでは依存関係や影響範囲を正確に把握できない ドキュメント上でざっくり各マイクロ サービスの関係だったりが書かれているが、 Terraform や Kubernetes の一個一個のリソースの細かい変更が相互にどう影響を与えるか、全体にどう いった影響があるかがそれだけでは分からない Google Cloud Next Tokyo Proprietary
22. ナレッジグラフ：構造化されたコンテキスト 解決策 ・Terraform HCL と Kubernetes/Kustomize をナレッジグラフへ変換し MCP server 化 ・Skill によってアプリとインフラの分割されたリポジトリの情報を動的に補完 Terraform と Kubernetes のそれぞれの変更が全体にどう影響を与えるのか可視化され、影響範囲の特 定が可能になった Google Cloud Next Tokyo Proprietary
23. グラフの出力例 Terraform Kubernetes + identity module.hoge xxx_kit secret Outputs k8s overlay: dev base + workload + datadog ServiceAccount secrets-manager ServiceAccount server output.deployment_names output.secret_api_key module.fuga Google Cloud Next Tokyo output.endpoint Proprietary
24. ナレッジグラフ：構造化されたコンテキスト 依存関係にあるかが可視化され、作業の品質が向上 リポジトリを全探索しなくて済むようになり、トークンも節約 レビュータスクのベンチマークで約25 %の消費量節約 Google Cloud Next Tokyo Proprietary
25. 既存のドキュメントの Skill 化 課題：設計方針・規約にしたがって作業をしてくれない アプリケーション プラットフォームでは様々な設計方針や規約を定めているが、それにしたがってくれ ない ・命名規則 ・どういう場合にどの設計パターンを用いるか など AI エージェントがその時々で一貫性のない作業をし、設計方針や規約に従っていない Google Cloud Next Tokyo PR が量産 Proprietary
26. 既存のドキュメントの Skill 化 解決策 ・Notion に書き溜めていたガイドラインを Skills の reference として活用、エージェント が読む/実行 するコンテキストへ ・Skill はレビュー観点ごとのガイドラインド キュメントへの入口・ルーター �� 約 50 本のガイドラインの ドキュメント Google Cloud Next Tokyo 各種 Skill Proprietary
27. 既存のドキュメントの Skill 化 ガイドラインにしたがって作業を実行し、品質が向上、手戻りの削減 「guideline + 構造化レビュー」の組み合わせで PR のレビューを自動化 ガイドラインや Skill の変更があるときも CI でリグレッション テスト実施し、レビュー SKill の品質を継続的に 担保 approved 61% blocking 14% review-only 25% PR レビューの工数が激減：アプリケーション インフラのリポジトリでは 1 日 ~ 300 程度の数 の PR が出ているが、半分以上を人間がレビューしなくて良くなった Google Cloud Next Tokyo Proprietary
28. Issue Tracker as State Machine 課題：Skill の限界 複雑な作業を 1 つ Skill で実行するのは難しい - context window の圧縮により作業の精度が低下 セッションが終われば状態は消えるため、context window と会話の寿命が上限となり、タスクの引き継ぎも人間が 制御する必要がある PR 間の依存順序 / CI・apply・レビューの長い待ち / 承認ゲート / 失敗からの再開を人間が制御 1 つの Skill に色々な作業が詰め込まれたり、Skill の数も多くなると品質担保が難しい 実業務における複雑なワークフローをエージェントに移譲しようとしても、 エージェントのセッションの管理が必要になり、ボトルネックとなる Google Cloud Next Tokyo Proprietary
29. Issue Tracker as State Machine 解決策 Workflow Engine の構築 ・issue を context packet 兼 state machine として扱う ・issue state = workflow の状態、blocker の関係の表現 = 依存グラフ ToDo In Progress In Progress In Review Pending Rework 状態遷移 Google Cloud Next Tokyo In Review Done Done Issue A: ToDo blocked Issue B: Done Issue C: In Progress 依存グラフ Proprietary
30. Issue Tracker as State Machine 実行ループ： output → state 遷移 → controller が次の issue を選択 controller issue intent / labels / state 選択 select / route / gate / transition Output executor Job 実行 出力 PR / Document など state 更新 Google Cloud Next Tokyo Proprietary
31. Issue Tracker as State Machine Issue Tracking System を state machine として ワークフローを構築 人の介入をより少なく AI エージェントが複雑な作業を正確に実行に Google Cloud Next Tokyo Proprietary
32. Task Execution Platform 課題：AI エージェントに安全にタスクを実行させたい 人の管理を減らしてタスクを安心して移譲するためには以下のようなポイントが懸念 ・AI エージェントを通じて API KEY などが窃取されてしまわないか ・AI エージェントが機微情報をインターネットに漏らさないか など Google Cloud Next Tokyo Proprietary
33. Task Execution Platform コンテキストを供給する「器」 — agent runtime / sandbox / hooks を GKE 上の実行基盤として束ねる サンドボックスと権限 – ファイルシステム書込・ネットワーク到達先を制限 – AI 用アカウントは read-only 既定、書き込みは目的別 / 期限付き – Workload Identity / IAM / VPC Service Controls で実行環境側からもガード Google Cloud Next Tokyo Proprietary
34. Task Execution Platform 解決策 AI エージェントが安全にタスクを実行可能な基盤を整備 GKE Cluster 短命クレデンシャル発行 Credential broker Issue Tracking System 1 issue = 1 job として実行 通信 通信先の 制限 External Services Egress proxy controller API KEY も集約 Executor Job Network Policy Google Cloud Next Tokyo Proprietary
35. Task Execution Platform Issue Tracking System を state machine として扱い、 GKE を用いた Task Execution Platform を中心として Workflow Engine を構築 GKE 上で権限・通信先・クレデンシャル / シークレットを制御 ・ファイル システム書込・ネットワーク到達先を制限 ・エージェントに直接 API KEY などは持たせず短命クレデンシャルを発行やproxy に集約 人のエージェント管理の手間削減と安全にタスクを移譲可能に Google Cloud Next Tokyo Proprietary
36. まとめ 自分たちの知識を構造化し、 AIエージェントが正確に判断・作業 できるコンテキストとして与える Issue TrackerをState Machineとして扱い、複雑なワークフローを継続 的 に実行できるようにする 権限や通信を制御した実行基盤を整え、 AIエージェントへ安心してタスクを移 譲できる土台をつくる Google Cloud Next Tokyo Proprietary
37. 03. Connection Google Cloud Next Tokyo Proprietary
38. 顕在化する SDLC のボトルネック リリース速度の壁 検証の忠実度 フィードバックの後ろ倒し コンテキストが十分に与えられ た環境において AI で実装は速 くなるが、検証・デプロイ・リリー スが遅いと全体は速くならな い。 ローカル環境だけでは identity、network、 dependency、data、runtime の挙動を確認しきれない。 PR をマージしてデプロイ後に初 めて見つかる問題が手戻りを 生む。 Google Cloud Next Tokyo Proprietary
39. Google Cloud Next Tokyo Proprietary
40. SDLC と Inner Loop / Outer Loop Inner Loop Outer Loop PR をつくるまで — PR から運用まで — チーム × 実行環境 ローカル × AI エージェント コーディング → 実行・確認 → 修正 Pull Request CI → プレビュー検証 → デプロイ → 運用 施策: mirrord — ローカル プロセスを実行環 施策: Signadot / プレビュー環境 — マージ前に本番相当 境へ接続 の検証 SDLC を PR の前後で分類し、それぞれに施策を検討する。 Google Cloud Next Tokyo Proprietary
41. Inner loop 改善: ローカル接続型の mirrord LOCAL ENVIRONMENT Control REMOTE KUBERNETES CLUSTER mirrord CLI /IDE Extension Node / Pod Namespace Local Process Target Pod (Running App) (Your App) Intercepts Syscalls LD_PRELOAD / DYLD_INSERT_LIBRARIES Mirroring Traffic (Copy) Stealing Traffic (Redirect) Ephemeral Container Secure Tunnel (port-forward) mirrord-layer Forwarded Network / File Requests Incoming Cluster Traffic mirrord-agent (Hook / Proxy) (Proxy / Sniffer) External Services / Cluster DBs Outgoing Traffic (Proxy) Target Pod's Environment / Filesystem File / Env Access Google Cloud Next Tokyo Proprietary
42. Outer loop 改善: プレビュー環境型の Signadot Preview Environments Commit & Push pr-123-env GitHub Create PR Request Preview Env Trigger CI Deploy & Orchestrate Microservices Database Ingress Base Baseline + PR Changes pr-124-env Microservices feat/new-feature Developer Pull Request Database Ingress Base Baseline + PR Changes GitHub Actions pr-125-env Signadot Microservices Comment URL on PR Return URL Database Ingress Base Baseline + PR Changes pr-126-env Preview URL: https://pr-123.preview.example.com Microservices Database Ingress Base Baseline + PR Changes Google Cloud Next Tokyo Access & Verify Proprietary
43. ローカル / プレビュー環境型の使い分け ⽐較項⽬ ローカル接続型 プレビュー環境型 主な用途 個人のコーディング、 デバッグ デザインチェック、QA テスト、 E2E テスト、デモ SDLC Inner Loop Outer Loop フィードバック 即時（数十秒） 遅い（数分） 主要技術 mirrord Signadot GKE コスト 低（既存 Pod 利用） 中（部分的複製） Google Cloud Next Tokyo Proprietary
44. まとめ 実装が速くなっても、検証・デプロイが遅けれ ば全体は速くならない ローカルには実行環境の文脈をつなぎ、 PR 前に 本番相当の検証を前倒しするのが効果的 フィードバックは数十秒単位で、 AI にも人間に も読みやすい形で返す Google Cloud Next Tokyo Proprietary
45. 04. Guardrail Google Cloud Next Tokyo Proprietary
46. 「任せる」ためのガードレール設計 Continuous Quality Gate Execution Boundary 本番投入前 テストケース通りに動き、既存機能を 壊していないか 本番投入後 越えてはいけない境界を固定し、証 跡から問題を検知・是正する Google Cloud Next Tokyo Proprietary
47. Continuous Quality Gate 課題: AI の実装速度に QA プロセスが追いつかない AI 活用のボトルネックは、生成速度から品質判断へ移っている しかし、テストプロセスにおける AI 活用は標準化されていない 1 2 3 仕様理解が属人化 成果物品質がばらつく 知見が再利用されない PRD / Feature Spec / 画面仕様か ら、何をテストすべきかの抽出が人 の経験に寄る プロンプトや入力資料の差で、テス ト計画・分析・設計の粒度や質が安 定しない 過去の指摘や固有観点が、次に引 き継がれない Google Cloud Next Tokyo Proprietary
48. Continuous Quality Gate QA Toolkit: 仕様を一連の成果物に変える Agent Skills により、テストプロセスを QA および開発者が迷わない流れにする Test Plan Test Analysis Test Design Test Cases テストの目的・スコープ の整理 標準機能テストやセキュ リティ、 LegalOn 固有観 点を突き合わせた因子 水準表の作成 条件の特徴に応じた適 切なテスト技法の選定や 選択理由を残す Test design から機能ご との Markdown 形式の テストケースを作成 Google Cloud Next Tokyo Proprietary
49. Continuous Quality Gate 利用例: Test Analysis（ 出力イメージの抜粋） 1 Test Plan 目的・スコープの整理 2 Test Analysis 因子水準表の作成 3 Test Design テスト技法の選定 4 Test Cases テストケースの作成 Google Cloud Next Tokyo Proprietary
50. 次の問い : 本番投入後、どこまで任せられるか Continuous Quality Gate Execution Boundary • 仕様から確認観点を作る • QA プロセスと成果物を見える化 • 人はリリース判断に集中する • 通信先/権限を限定する • 必要な時だけ権限を広げる • 証跡を残す Google Cloud Next Tokyo Proprietary
51. Execution Boundary クラウド ネイティブ環境における多層型境界線防御 GKE Cluster Datastore Cloud Service Mesh Istio ingress gateway Cloud Load Balancing micro services IAM Cloud Armor VPC Service Controls SSL Policy & Network-level Encryption Google Cloud Next Tokyo Cloud Storage WAF mTLS & Authorization Policy & NetworkPolicy AlloyDB Access Control & Network perimeter Proprietary
52. Execution Boundary 課題: 常時権限のままでは、 AI 時代の運用速度に合わない 〜Zero Touch Productionが「理想」から「必須」へ〜 AI / 人間が同じ production 環境へ関わるほど、常時権限と例外運用はリスクとボトルネックになる 1 2 3 権限が広すぎる 承認が詰まりやすい 例外が属人化する 強い権限が残り続け、操作主体 （人間 + AI ）が増えるほどリスクが 指数関数的に増える 都度人がプロセスに介入すること で作業のボトルネックになる 「緊急時は人が直接入って直す」と いう暗黙知（例外運用）から脱却で きない Google Cloud Next Tokyo Proprietary
53. Execution Boundary JIT Access: 必要な権限だけを、必要な時間だけ付与する IAM 書き込み 利用者 Backstage IAM Conditions JIT Access API Kubernetes 申請・承認 Developer / SRE 申請 UI 権限セットの カタログ提供 リクエスト 許可済み 権限セットの検証 RBAC 作成 Temp RoleBinding CRD RoleBinding Google Cloud Next Tokyo Proprietary
54. Execution Boundary 証跡を、対応すべきアクションに変える Backstage SOURCES JIT 証跡ログ 権限付与の操作ログ ソースコード /インフラ設定 (IaC) DETECT ACTION 脆弱性検出・優先度付け 修正 PR 作成支援 証跡とコードを集約し、潜在する 修正方針を PR として提案 脆弱性リスクを自動 人によりマージ判断 検出・優先度付け GitHub Google Cloud Next Tokyo Proprietary
55. まとめ ボトルネックは生成速度から品質判断へ。 仕様理解・分析・設計を Agent Skills で標準化 し、人はリリース判断に集中する。 最小権限を必要な時だけ付与し、期限切れで自動 失効。リスクをアクションにつなげ、人は必要な対応 の判断に集中する。 Google Cloud Next Tokyo Proprietary
56. Conclusion Google Cloud Next Tokyo Proprietary
57. まとめ Context Engineering Connection Guardrail 知識を構造化し、エージェント が判断できるコンテキストへ 実行環境につなぎ、検証と フィードバックを前倒し 品質判断・権限管理・証跡活用 を仕組み化する Google Cloud Next Tokyo Proprietary
58. Thank you Proprietary