GKEを中心としたマルチプロダクト・マルチリージョン対応アプリケーションプラットフォームの継続的改善 / continuous improvement of GKE based application platform

Google Cloud Community Tech Surge 2026の登壇資料です。
https://2026.gcts.jp/
https://2026.gcts.jp/#timetable?session=session-B-1530

Transcript

1. GKEを中⼼としたマルチプロダクト‧マルチリージョン 対応アプリケーションプラットフォームの継続的改善 Toshinori Sugita • 2026年2⽉26⽇ 株式会社LegalOn Technologies
2. 登壇者プロフィール 杉⽥ 寿憲 (すぎた としのり) @toshi0607 株式会社LegalOn Technologies Staff Platform Engineer Application Platform Tech lead
3. Our Purpose 法とテクノロジーの力で、 安心して前進できる社会を創る。 LegalOn Technologiesは、AI分野における⾼度な技術⼒と法律‧契約の専⾨知識を兼ね備えたグローバルリーガルAIカン パニーです。設⽴当初から、AIを活⽤したリーガルAIサービスの開発に注⼒し、⼤規模⾔語モデル（LLM）やAIエージェン トなど最先端のAI技術を製品開発に取り⼊れ、多様な企業課題に応えるソリューションでお客様のビジネスを⽀援しま す。 会社名 株式会社LegalOn Technologies 設⽴ 2017年4⽉21⽇ 従業員数 636名（役員含む∕2026年1⽉時点） 所在地 〒150-6219 東京都渋⾕区桜丘町1-1        渋⾕サクラステージSHIBUYAタワー19F 資本⾦ 201.5億円（資本準備⾦等含）
4. 法務AIのグローバルリーダー 8,000+ 顧客数グローバル8,000社を突破 600人 従業員数 7拠点合計 （東京‧⼤阪‧福岡‧名古屋‧サンフラン シスコ‧ロンドン‧ミュンヘン） 20人 弁護⼠資格保有者数 ⽇本、NY州、CA州、ドイツの資格者を含む 1000+ 国内導⼊上場企業数 （国内上場企業数: 3,900+社） 200人 開発チーム⼈数 286億円 ゴールドマン‧サックス、ソフト バンクなどが出資。全調達ラウン ド累計
5. 法務・契約領域で幅広く最先端の リーガルAIソリューションを提供 法務・契約業務支援 経営支援 世界⽔準の法務 AIで法務業務⽀ 援 様々なコンテン ツでAIリーガル リサーチ⽀援 オンライン法務 学習⽀援サービ ス 契約学習メディ アとコミュニ ティを提供 AIコーポレート ガバナンスプ ラットフォーム 組織の規範運⽤ をAIで⾃動化す るAIカウンセル
7. アプリケーションプラットフォーム の継続的改善
8. 全社アプリケーションプラットフォーム「 Akupara（アクパーラ）」 What is Akupara ? LegalOn Technologiesでプロダクト開発を⾏うにあたり、プロダクトチームが認知負荷低くソフトウェ アライフサイクルを⾃律的に回すための社内開発者向けプロダクト Mission and Vision of Akupara 開発者にゴールデンパスと堅牢なインフラを提供し、創造的な開発に集中できるようにする
9. Akuparaの基本方針 Interface Build Test Deploy Operate Platform Infrastructure Proto 生成コード管理 言語毎のテンプレート 言語毎のライブラリ CI テンプレート Playwright Job デプロイ時自動実行 負荷試験基盤 ドキュメント サポート Production readiness Check GitOps デプロイ DB マイグレーション 単発Jobの実行 Feature flag モニタリングダッシュボード SLO ベースのアラート エラー発生時のログ、 メトリクス、トレース連携 脆弱性管理 暫定的権限昇格 Kubernetes 管理 DB 管理 FinOps セキュリティ認証対応 各種法令準拠 サービスメッシュ Web Application Firewall CDN トレーニング オフィスアワー サービスカタログ 課題の投稿・投票 「LegalOn」 開発者 XXX 開発者 YYY 開発者
10. Akupara進化の全体像
11. Phase 1: プラットフォームの立 ち上げ 〜「LegalOn」開発を支えるプラットフォーム構築〜
12. 一からの構築 Phase 1の課題 既存プロダクトの移⾏ではなく、新設計‧新技術スタックで50+マイク ロサービスを開発 開発期間の短さ 3〜4年かけた既存プロダクトの機能＋新機能を1年でリリース 同時多発的な開発 製品機能チーム‧共通基盤チームが並⾏して開発を進める必要がある
13. Phase 1のアプローチ
14. Phase 1のアーキテクチャ • 共通のGKEクラスタ • 個別のProject • レイヤーアーキテクチャ Gateway Cloud Load Balancing Functional Service Fundamental Service A Functional Service Functional Service Fundamental Service B Data Service C GKE Pub/Sub Project A Pub/Sub Secret Manager Project B
15. サービステンプレート アプリケーションリポジトリで 50サービスがアプリケーションを初期化する アプリケーションテンプレート 共通ライブラリ 開発ツール サービス⽤GitHub Actions workflow 初期化⽤スクリプト
16. サービステンプレート • $ go run tools/service-new/main.go -n SERVICE_NAME -l LANGUAGE • Kubernetes上で動作するgRPCサーバー⽤の アプリケーションテンプレートを開発 • リンター、DBコンテナ、Pub/Subエミュ レータ、DBスキーママイグレーションな ど、ローカル開発に必要なツール⼀式を同梱 • ⾔語毎に最低限必要なCIをComposite Actionで標準利⽤でき、サービス固有で必要 なCIはサービスオーナーが追加 .github/ actions go-test go-lint go-build-and-push workflows service-a.test-and-lint.yml service-a.build-and-push.yml service-a.xxx.yml (固有CI) services/ service-a Application
17. CI/CD App repo Infra repo Namesapce loc-ns-file-prd Namesapce loc-ns-billing-prd … Namespace xxx-ns-svc-a-prd Namespace xxx-ns-svc-b-prd … GKE (Application) Namesapce loc-ns-file-prd Namesapce loc-ns-billing-prd … GKE (DevOps) push image fetch manifest sync observe GKE Project notify
18. デプロイの段階的移行 Dev QA Prd PRマージ + Image Updater PRマージ + Image Updater PRマージ + Image Updater Gitタグ打ち + GitOps Gitタグ打ち + GitOps Gitタグ打ち + GitOps PRマージ + Image Updater 開発中 QAテスト本格化 1st リリース
19. Phase 2: USリージョン展開 〜マルチプロダクト・マルチリージョンへの進化〜
20. マイクロサービスの負荷 Phase 2の課題 JPだけで50のマイクロサービスが、USリリースで倍に。インフラ ＋CI/CDの両⾯で対応が必要 マルチプロダクト・リージョン 単⼀プロダクト‧単⼀リージョン設計からの脱却。拡張性を担保する 再設計が必要 レギュレーション準拠 SOC2 Type 2維持、US先⾏サービスのセキュリティ要件を全体で満た す必要がある
21. Phase 2のアプローチ : プラットフォームの再設計
22. 全コンポーネントの洗い出しと依存関係の整理
23. リソース階層 Organization Projects Organization Security LegalOn JP Other PF Akupara Live Lab Sandbox Platform US Platform Services Other Prd Folders Prjs Prjs JP US Prjs Prjs Prjs JP US Prjs Prjs Prjs
24. プロジェクト命名規則 区分 規約 例 ⼀般的なService [product]-[service]-[region]-[stage] abc-review-us-qa01 プロダクト⽤ Platform コンポーネント [product]-[service]-[region]-[stage] abc-api-gw-prd 地域ごとの Platform コンポーネント akp-[service]-[region]-[env] akp-gke-jp-live 地域横断の Platform コンポーネント akp-[service]-[env] akp-argocd-sdbx
25. プロダクトインフラ Cloud DNS Database AlloyDB Container Infra GKE/Kubernetes Cloud Armor Cloud Service Mesh User Contents Cloud Storage Gateway Cloud Load Balancing Event Processing Pub/Sub Internal Systems Externa l SaaS Sensitive Con g Secret Manager
26. 開発インフラ App repo Infra repo push image fetch manifest sync observe GKE Project notify GKE(JP app) GKE(US app) GKE(DevOps)
27. テナントリソースの抽象化 : Starter-kit
28. Kubernetes manifestの生成: k8s-gen
29. アプリケーションプラットフォームと開発者 Service Infra Kubernetes, Service Mesh, etc. SRE & Platform Service Tenant K8s Namespace, Service Account, GCP project, Pub/Sub, etc. Service Workload K8s Deployment, k8s Service, K8s HPA, K8s PDB, etc. プロダクトチーム Starter-kit Terraform k8s-gen Kustomize Layer & components Developer Interface
30. セキュリティ : セーフティネットの再構築 特定 防御 検知 対応 復旧 Security Command Center Enterprise Google SecOps ‧プロアクティブなリスク管理 (CNAPP) ‧脆弱性、設定ミス、潜在的な攻撃経路を可視化 ‧セキュリティ イベントの統合的な監視 ‧セキュリティ オペレーションの⾃動化と効率化
31. Phase 3: 開発ライフサイクル上 のボトルネック解消 〜Inner/Outer Loop改善によるフィードバック高速化〜
32. Platform as a Product
33. ソフトウェア開発ライフサイクル（ SDLC）課題整理
34. デプロイ・リリースが面倒 Phase 3の課題 ⼯程が多く、マルチリージョン×マルチステージの組み合わせで運⽤ 負荷が⾼い フィードバックループが遅い PRマージ後にしか実環境での動作検証ができず、⼿戻りコストが⾼い PRマージ時の品質が不十分 ローカル環境ではマイクロサービス間の結合テストやDB検証が困難 で、デプロイ時に⾃他チームへの影響確認コミュニケーションが発⽣
35. SDLC改善: Inner loopとOuter loop
36. Inner loop改善: ローカル接続型の Mirrord
37. Outer loop改善: プレビュー環境型の Signadot
38. ローカル接続型とプレビュー環境型の使い分け ⽐較項⽬ ローカル接続型 プレビュー環境型 主な⽤途 個⼈のコーディング‧デバッグ デザインチェック、QAテス ト、E2Eテスト、デモ SDLC Inner Loop Outer Loop フィードバック 即時（数⼗秒） 遅い（数分） 主要技術 Mirrord Signadot GKEコスト 低（既存Pod利⽤） 中（部分的複製）
39. これから: AIエージェント時代の プラットフォーム 〜AgentOps as Platform Engineering〜
40. プラットフォームを利用する開発者の変化
41. コンテキストの不足／過多 直面している課題 品質がコンテキスト管理に左右される⼀⽅、コンテキストウィンドウ は飽和しやすく、指⽰逸脱や品質低下につながる フィードバックが遅い ローカルと運⽤環境が分離しているため、デプロイ後にしか得られな い検証が多く、outer loopが⽀配的ボトルネックになる 安全性・監査性が不足 ⾃律動作には、意図しない変更や情報漏洩を原理的に防ぐガードレー ルと、証跡の標準化が必要
42. コンテキストエンジニアリング
43. ローカル環境と運用環境の接続
44. ローカル・運用環境の保護
45. まとめ
46. まとめ
47. 参考情報
48. ご清聴ありがとうございました