JCBのマルチテナント基盤の信頼性を支える「構成分析AIエージェント」

本稿はJCB Advent Calendar 2025の12月1日の記事です。

PF チームの平松です。

GKE をベースに構築した JDEP の運用を始めて5年目に突入し、とうとう生成 AI でJDEPについて聞くと、候補の一つとして「クレジットカード大手のJCBが構築・運用しているシステム開発プラットフォームの名称です。IT業界やエンジニア界隈ではこちらの意味で使われることが多く、有名な事例です。」と返してくれるようになりました。

本記事では、今年いくつかのイベントにて紹介した GKE の安定稼働を支える「構成分析 AI エージェント」について、その開発経緯と中身についてご紹介したいと思います。

GKE の安定稼働に関する課題

JDEP は複数の事業部の複数のサービスが共同で利用するマルチテナント環境となっています。それゆえ、各チームがアプリケーションリリースを自律的に行う、SRE やセキュリティチームが共通機能を拡充する、そしてインフラとしての GKE クラスタのメンテナンスやパッチ適用が自動/手動で行われるなど、毎日、さまざまな理由で絶え間なく環境が変化しています。

PF チームの重要なミッションは、この変動性の高い環境で GKE のクラスタを安定的に運用し続けることです。

リリースチャンネル導入による新たなトレードオフ

安定運用における最大の関心事の一つが、GKE の「アップグレード」です。 GKE は、アップグレードをサポートするリリースチャンネルやメンテナンスの時間枠などの機能を提供しています。

JDEP では、昨年の記事で記載したように、セキュリティ強化のために各クラスタをリリースチャンネルに登録し、メンテナンス除外ポリシーと組み合わせた運用戦略を採用しています。

これにより、メンテナンス除外をきめ細かく制御できる柔軟性を得ましたが、新たなトレードオフも発生しました。

静的リリース (リリースチャネル導入前) :
Staging 環境と Prod 環境の GKE バージョンをパッチレベルで完全に一致させることが可能。
リリースチャンネル導入後:
利用可能なバージョンのリストがほぼ毎週更新されるため、アップグレードの際に、Staging と Prod のバージョンにパッチレベルで若干の差異が発生。

リリースチャンネルを導入した結果、静的リリース利用当時のステージングにおける品質保証の土台であった「Stage と Prod の環境間で GKE バージョンが完全一致していること」という前提が必ずしも満たせなくなる、という課題に直面しました。

事前調査が困難なコントロールプレーンのパッチアップグレード

GKE のパッチアップグレードには、Kubernetes のパッチと GKE のパッチの2種類が含まれており、自動で発生します。このコントロールプレーンのパッチアップグレードは、Google 側の VPC に展開されるコンポーネントだけでなく、ユーザの VPC に展開されるシステムコンポーネント（Netd、Kube-dns、gke-metadata-server など）にも影響を及ぼします。これらのアップデートは、アプリケーションの信頼性に影響を与える可能性があります。

JDEP ではこれまで自動アップデートへの対応として、パッチアップグレードのログイベントを検知してチャットに通知する仕組みを整備していました。アップグレードに起因する障害の発生に気付きやすくなるといった恩恵はありましたが、その原因を特定するためにはエンジニアが都度必要な情報を収集し、アップグレードでクラスタにどのような変更が行われたのかを分析する必要がありました。

信頼性確保の壁

多数のサービスを抱える JDEP の安定稼働を担う PF チームにとって、手動・自動にかかわらずアップグレードによる構成変更がアプリケーションに及ぼす影響の把握は重要なミッションでした。アップグレードによって環境の「何がどう変わったのか」「それによってアプリケーションにどのような影響が懸念されるか」といった問いに答えられるよう備えることは、すなわちインシデント発生時の原因や影響を素早く特定することにつながるからです。しかし、GKE のアップグレードの影響を把握するためには、JDEP の場合、大別して以下２点の難しさがありました。

情報の非公開性:
マイナーバージョンと異なり、GKE パッチアップグレードに含まれる変更の詳細は、事前に公開されません。
変化の速さ:
GKE リリースチャンネルがほぼ毎週更新されるため、アップグレード先のバージョンを事前に特定し、十分な時間をかけて調査することが困難です。自動アップグレードは1〜2週間おきに発生するため、人手による詳細な調査時間を確保できません。

課題に対する工数の算出

そこで我々は、「アップグレード前後のシステムコンポーネントの構成情報を比較・分析すれば、変更内容と潜在リスクを概ね把握できるのではないか」という仮説を立てました。しかし、この構成差分分析をマニュアルで行うには、以下のような高い壁がありました。

データ量の多さ:
調査対象データは3,600万字超（30MB超）にも及びます。
ノイズの多さ:
単純な Diff ツールでは役に立たないほど、価値のない差分が大量に含まれます。
高度な専門知識:
アプリケーションへの影響を判断するには、Kubernetes の専門知識が必須です。
時間的な制約:
アップグレード直後にインシデントが発生する可能性があるため、即時対応が求められます。

これらの難しさから、マニュアルでの分析作業は年間で3,000時間以上かかるという試算になり、現実的な運用が不可能であることが判明しました。

解決策：AIエージェント「Cluster Change Detector (CCD)」の開発

ここの課題を解決するにあたり、大量の情報から本質的な変更のみを短時間で抽出・要約するための手段として生成 AI に着目しました。そして、環境の変化を検知し、自律的にタスクを完遂する「AI エージェント」を開発しました。これが「Cluster Change Detector（CCD）」です。

CCD は、GKEコントロールプレーンのアップグレードを契機に、生成 AI (Gemini) を用いて構成変更を分析・要約し、即座にレポーティングする仕組みです。着想から1.5ヶ月でリリースを達成し、2024年から本番環境を含む全環境で稼働しています。

アーキテクチャ：イベント駆動とサーバレス

CCD は、不定期に発生するGKEアップグレードイベントに即時対応できるよう、イベント駆動とサーバレスなアーキテクチャを採用しています。

イベント駆動:
GKE プロジェクトでアップグレードが発生すると、Eventarc・Pub/Sub を通じてイベントが発火し、AI エージェントのプロジェクトに通知されます。この通知を元に、Cloud Run および Workflows で構成された AI エージェントのアプリケーションが稼働します。
サーバレス:
GKE のアップグレード待機中にかかるコストをほぼゼロに抑えながら、イベント発生時に即座に起動し、必要な作業を自律的に立案・実行します。

AI エージェントの頭脳：4つの協調モジュール

CCD の中核をなすのは、それぞれ独立した役割を持つ4つの AI モジュールです。これらが協調動作することで、レポート生成という複雑なタスクを完遂します。

モジュール名	役割
Extractor	アップグレード前後の Kubernetes オブジェクトの構成情報から、重要な変更差分のみを抽出し、リスクを分析します。
Summarizer	Extractor が抽出した個々の変更差分の集合から、構成変更の全体像を要約し、最終レポートを作成します。
Augmentor	Extractor や Summarizer の生成精度を高めるために、分析対象に応じて補完情報を提供します。必要に応じて外部情報も参照します。
Evaluator	成果物（レポート）の品質を、設計されたモデルベース指標で自動評価します。

これらのモジュールは、Vertex AI 上で利用可能なGeminiをベースに実装されています。作業の目的や複雑度に応じて、モデルや Temperature などのパラメータを細かく使い分けることで、全体としての品質と効率を最適化しています。

開発の工夫：品質と効率を高める3つのイノベーション

CCD の開発において、特に工夫した点は以下の3点です。

1. プロンプトの構造化と自動生成

Gemini の性能を最大限に引き出すため、プロンプトは単なる指示ではなく、「構造化されたプロンプトレシピ」として設計されています。これには、指示、制約条件、出力例、評価観点などが含まれます。

情報収集:
Extractor は、プロンプトレシピに加え、分析対象データや Augmentor からの追加情報を収集します。
タスク分割:
一回の生成の目的がシンプルになるよう、品質優先でタスク分割を行いながらプロンプトを自動生成します。大規模な分析では、通常100〜150程度の小さなプロンプトに分割されます。

2. 公開情報のサーベイ機能によるリスク分析の高度化

Extractor が Kubernetes オブジェクトの差分情報だけでは具体的なリスクを特定できない場合、Augmentor がそのギャップを埋めます。

Vertex AI Search の活用:
Augmentor は、システムコンポーネントに組み込まれたオープンソースプロダクト（例：Fluentbit）などの情報を、Vertex AI Search を用いてインターネットから収集します。
具体的なリスク特定:
例えば、Fluentbit のコンテナイメージが v.X から v.Y に更新された際、単なる差分比較では「ログ収集に影響があるかも」程度の情報しか得られません。しかし、Augmentor が Fluentbit の Changelog や関連 Issue をサーベイレポートとして生成し、リスク分析の見解を上書きすることで、「v.X から v.Y で特定の機能が非推奨になったため、ログ転送に影響する可能性がある」「メモリアロケーションが改善されたため、メモリ使用率が変化する可能性がある」といった具体的なリスクを特定できるようになります。

3. モデルベース指標による自動評価と継続的な改善

生成 AI の成果物の品質を客観的に追跡するため、CCD では「モデルベース指標」による自動評価を導入しています。

6つの評価指標:
CCD のレポートに求められる観点として、「正確性」「具体性」「技術的深さ」「影響範囲」「実用性」「簡潔性」の6つの指標を設定。Evaluator がこれらの指標でスコアを毎回算出します。
継続的なトークン最適化:
この定量評価を活用し、開発チームは品質を維持しながら入力トークンを継続的に削減する改善を繰り返しました。
- プロトタイプ（v0.1）では、1回の分析に900万トークン以上が必要でした。
- 評価とリファクタリングを繰り返した結果、現在は約5万トークン（プロトタイプ比約0.6%）という必要最小限の入力で、同等以上の精度のレポートを出力できるようになりました。
- この改善プロセスにおいて、Gemini のロングコンテキスト性能が、初期段階で大量のデータからコンセプトの検証を容易にし、素早い立ち上げと継続的な改善を可能にする大きな強みとなりました。

導入成果と AI 活用の未来

この CCD 本番導入により、JDEP の運用は劇的に改善されました。

工数圧縮率96.1%:
人間のエキスパートが同じ作業を行った場合と比較し、工数圧縮率96.1%を達成。通年で2,800時間超の稼働時間を捻出できる見込みです。
障害対応の高速化:
障害訓練 (Gameday) において CCD を活用した結果、従来の半分以下の作業手順で、障害の被疑箇所を特定できるようになりました。
新たなインサイトの獲得:
AI ならではの視点による GKE の理解を深める10件以上の新しいインサイトがチームにもたらされました。

このように、現在 CCD は単なる自動化ツールではなく、「チームの一員としてプラットフォームの運用の一端を担う」AI エージェントとして機能しています。

さらに、CCD の基本構造（構成情報の抽出・分析・要約）を応用し、GKE 以外の技術領域にも同様の AI エージェントの展開を進めています。一例として、Cloud Service Mesh のアップグレードによって発生する構成変更のリスク分析を行う AI 運用ツールを、CCD を応用してごく短期間で開発し、リリースしています。

今後、レポーティング機能の精度・スピードアップに努めるとともに、更なる応用についても検討を進めているところとなります。