【クラウドネイティブ会議】膨大なTerraform / Kubernetes管理やレビュー、問い合わせ対応をAIで効率化するマイクロサービス運用改善の実践

LegalOn Technologiesは、法務領域を中心にAIを活用したプロダクトを提供するグローバルリーガルAIカンパニーであり、2026年4月時点で220個のマイクロサービスをGKE上で運用している。本セッションでは、同社SREの石垣雅基氏と和田明久氏が、膨大なTerraform/Kubernetes manifest管理、レビュー、問い合わせ対応、Production Readiness CheckにAIエージェントを組み込み、運用負荷を減らしていった実践を紹介した。

220個のマイクロサービスが生む、SRE運用負荷の現実

LegalOn Technologiesは「法とテクノロジーの力で、安心して前進できる社会を創る」を目的に掲げる企業である。顧客数はグローバルで8500社を突破し、従業員数は639人、開発チーム人数は200人に上る。提供プロダクトも、LegalOn、GOVERNON、CXOn、DealOn、WorkOnなどへ広がっている。

そのプロダクト群を支える基盤は、マルチリージョン・マルチプロダクト向けのGKE Clusterで構成されている。スライドではJP、US、EUなどのGKE Cluster上にPlatform、LegalOn、DealOn、WorkOnなどといった領域ごとのマイクロサービスが並ぶ構成が示された。

この規模になると、SREの負荷は単純な運用作業だけでも大きくなる。Platformによって抽象化されているものの、Terraform Moduleをアップデートする場合、220個の全マイクロサービスへ適用する必要がある。また、インフラ規模の拡大に伴って開発者からの問い合わせも増える一方、SREチームの人数が同じ速度で増えるわけではない。

220個のマイクロサービスを管理するためのTerraform、k8s manifest

LegalOn Technologiesの石垣雅基氏は、SREが抱える苦悩として「膨大なメンテナンス工数」と「スケールしない運用負荷」を挙げた。「インフラ規模が大きくなると、問い合わせも非常に多くなります。正直しんどいところですが、そういったしんどさを解消してくれるのが、近年急成長しているAIエージェントです」と語った。

HPAからKEDAへの大規模移行を、AIエージェントで進める

最初の事例は、全マイクロサービスを対象としたKubernetesのHPA（Horizontal Pod Autoscaler）からKEDAへの移行である。対象は680のHPA manifest、134＋50のservices/platform folders、Sandbox/Liveの2環境に及んだ。AIエージェントを使わなければ、サービスごと、環境ごとにブランチ作成、変更適用、PR作成を人手で繰り返す必要があった。

事例：全マイクロサービスのHPA→KEDA移行

HPAからKEDAへ移行した理由は3つある。1つ目はゼロスケールである。Sandboxを夜間や休日に止められれば、コスト削減につながる。2つ目は多様なscalerを利用できることだ。Pub/Sub、Cron、Datadogなど、柔軟なスケーリング手段を選べる。そして3つ目がScaledObjectという共通インターフェースを得られることだ。後続施策の入り口となり、中央管理もしやすくなる。

ただしKEDAへの移行は単純なインストールでは終わらない。既存のHPAと、KEDAが内部的に生成するHPAの競合、External Metrics APIの切り替えなどを考慮する必要がある。そのため同社では、移行を複数フェーズに分け、安全側に倒して進めた。特にフェーズ2～4では、マニフェスト更新やフラグ更新といった単純作業にAIを活用した。

具体的には、人間が変換ルールの素案を書き、仕様書にあたるspec.mdを作成する。そのspec.mdをもとにAIがツールを実装し、最終的に人間がレビューする。こうしたループでツールを作り、適用していった。

さらにタスク管理ツールのLinearとCodexを連携させた。親Issueに共通のRunbookを記述し、子Issueに対象サービス名を持たせる。子IssueにCodexのエージェントをアサインすることで、PR作成まで進める形である。このとき、Codex側のenvironment IDを明示することも重要だった。実行環境を固定しないと、意図しない環境でエージェントが動く可能性があるためだ。

一方で新たな課題も見えた。大量のPRが並列でマージされると、後段のCIやArgoCD側の処理が追いつかない。和田明久氏は、AIエージェントを使う場合でも、後段システムのスループットを考慮する必要があると説明した。AIは作業を高速化できるが、システム全体の処理能力まで無限に増やすわけではない。

レビューと問い合わせ対応を、AIが扱える業務へ変える

続いて紹介されたのが、AIによるレビューの自動化である。同社では1日に約200件のPRが作成され、そのうち約50％がPlatform Teamのレビュー対象になっていた。Platform Teamのレビューでは、各チームの変更がガイドラインに沿っているかを確認する必要がある。

このレビューをAIに任せるため、同社ではNotionに蓄積されたガイドラインを活用した。Notion Databaseからactiveなドキュメントを抽出し、Markdown形式に変換してリポジトリにコミットする。これにより、AIエージェントがレビュー時に参照できる状態を作った。

Part2背景：ガイドラインとAIエージェントコンテキストのギャップ

ポイントは、単にドキュメントを渡すだけではない。レビュー対象のPRに対して、AIエージェントがどのガイドラインを参照すべきかを判断できるようにすることである。その結果、ガイドラインに明記された内容に基づく指摘はAIで自動化できるようになった。

ただしすべてをAIに任せればよいという話ではない。AIが指摘できない部分は、ドキュメント化されていない暗黙知である可能性がある。つまり人間のレビューは、ガイドラインに沿っているかを確認する作業から、暗黙知を発見し、明文化する作業へと重心が移る。「AIが指摘できなかったものは、Platform Teamの中にある暗黙知かもしれません。そこを見つけてドキュメント化していくことで、次回以降はAIがレビューできるようになります」と和田氏は説明した。

問い合わせ対応にもAIを組み込んでいる。SREチームには、requestチャンネルを通じて、入社・退社時のアカウント作成・削除、脆弱性診断のためのGateway穴あけ、CI上でのterraform apply失敗、ArgoCDのSync停止、DB Schema Migration Jobの失敗など、定型的な問い合わせが寄せられる。

まず同社では、入社・退社時のアカウント処理を自動化できるかを試した。Linear Asksを使い、Slack上で「/asks」を実行するとフォームが立ち上がる。依頼者が必要な情報を入力するとLinearのIssueが作成され、自動でAI Agentがアサインされる。エージェントは必要な変更を行い、権限付与などのPRを作成する。

もっとも、この問い合わせ自動化はまだ道半ばである。スライド上でも現時点では「まだ一つの定型問い合わせを自動化したに過ぎない」とされている。今後はrequestチャンネルに来る問い合わせを整理し、定型化できるものを抽出する。そしてLinear Asks Templateを構築し、AIエージェントへのタスク実行に必要な情報をInputして定義していく方針である。

PRCの項目を整理し、Evidence確認をAIに任せる

最後の事例は、Production Readiness Check（PRC）のEvidence確認である。これは新しいシステムが本番環境にリリースされる前に、信頼性、回復力、運用性、スケーラビリティが一般的な基準を満たしていることを体系的に検証し、保証するプロセスだ。

石垣氏は、PRCについて「リリース可否を判断するゲートではなく、開発チームとSREチームが協力して、システムの品質を本番環境で求められるレベルに引き上げるための建設的なプロセス」と説明した。新しいプロダクトをリリースするときだけでなく、その後に重要な機能をリリースする際にも行われる。

Production Readiness Check（PRC）

一方で、PRCは負荷の高いプロセスでもある。開発者はEvidenceを集める必要があり、SREはその妥当性をチェックしなければならないからだ。同社のPRCには多くの項目があり、確認は非常に骨の折れる作業だった。

そこでまずは項目そのものを整理した。Open Policy Agent（OPA）で機械的にチェックできる項目を自動化し、22項目を削減。さらに標準コンポーネントごとに項目を整理することで、必要十分なチェックに近づけた。AIに任せる前にまずタスクを整理し、AIが扱いやすい形へ変えることが重要だったのである。

次にAIエージェントがチェックしやすいようにPRC項目のフォーマットを決めた。詳細、確認すべき観点、Evidenceの貼り付け先を明確にし、AIがその内容を読んで「できていること」「できていないこと」を判断しやすい形にした。実際にClaudeに確認させると、Evidenceをもとにチェック結果を整理できたという。

この取り組みから見えたのは、AIをただ投入するだけでは効果が出ないという点である。AIに任せる領域を見定め、明確な手順で済むものはツール化し、非決定論的な判断や確認にAIを使う。さらに、コーディング規約やTerraform Moduleの使い方など、社内のナレッジを文書化し、AIが利用しやすい形にしておく必要がある。

最後に石垣氏は、AI活用の学びとしてこう語った。「AIに任せる領域を見定めることが大事です。そして社内ナレッジを整理すればするほどAIは優秀な同僚となってくれます」。