これは GLOBIS Advent Calendar 2025 3日目の記事です。
はじめに
私の所属する SRE チームは、AWS Organizations や EKS を活用し、複数プロダクトに対する横断的なインフラ基盤を提供しています。本記事では、生成 AI を活用して Platform Engineering を加速させるために必要な「コンテキスト」の整備について、現在取り組んでいる内容と今後の展望を共有します。
グロービスの Platform Engineering
我々が提供するプラットフォームは "Make platform easy, keep platform simple." をバリューとして掲げています。
「Easy」と「Simple」は似て非なる概念ですが、エンジニアリングの世界ではしばし対立する概念だと考えられてしまうことがあります。Clojure 作者の Rich Hickey によると、両者はトレードオフではなく、それぞれ「Hard」と「Complex」が対になる別軸の概念です。
我々にとっては、「Easy」はプラットフォームのユーザー（開発者）に向けた指針であり、「Simple」はプラットフォームの内部構造に向けた指針です。
しかし現実には、開発者にとって認知負荷の低い「Easy」な状態を追求するあまり、プラットフォーム側が過剰な抽象化や独自ツールを作り込み、システム内部を「Complex」にしてしまうというアンチパターンに陥る危険があります。我々は「Easy」を提供しつつも、内部的には疎結合で堅牢な状態「Simple」を維持したいという葛藤を常に抱えてきました。
そんな中、生成 AI の登場は、この「Simple」を保ったまま「Easy」を提供する」ための新しいアプローチを提示しています。本記事では、生成 AI がもたらすパラダイムシフトと、それを活かすために必要な「コンテキスト」の整備について考察します。
生成 AI がもたらした「Easy」のパラダイムシフト
生成 AI の登場により、プラットフォーム側で重厚な抽象化（ラッパーやカスタムツール）を用意しなくても、生のインターフェースのままで「Easy」が実現されつつあります。AI そのものが抽象化レイヤーとなることで、学習コストの高い技術スタックも、誰もが触れるようになってきているのです。
IaC (Terraform) の変化
これまで、Terraform のベストプラクティスとして、Module による共通化やカプセル化が定石とされてきました。しかし、Module 設計の難易度の高さやメンテナンスコストの大きさから、実際には避けられることも少なくありませんでした。
一方、生成 AI にボイラープレートを渡せば、高精度な Terraform 定義が生成できる今、Module による強い抽象化の優位性が一つ消えつつあります。必要最小限の抽象化にとどめて、「Simple」な定義のままでも開発者にとっての「Easy」は十分実現できるようになってきています。
Kubernetes の変化
kubectl コマンドやマニフェストの学習コストは高く、開発者にとって「Easy」ではありません。そのため、専用の GUI やラッパー CLI を開発するアプローチを取られることがありました。
しかし、先日発表された EKS MCP サーバーのような自然言語によるインターフェースの登場により、独自ツールなしでも誰もが触れられる可能性が開かれています。プラットフォーム側は「Simple」な Kubernetes の標準機能を公開したまま、開発者には「Easy」を提供できるのです。
ドキュメントとゴールデンパスの変化
メンテナンスコストの高い静的なドキュメントの代わりに、AI が既存コードから動的に解説・ナビゲートすることが可能になりつつあります。システム構成図さえも、drawio ファイルや画像を直接生成できるようになっています。
これらの変化は、生成 AI が開発者にとってのゴールデンパスとなり、プラットフォームを「Simple」に保ったまま開発者体験を「Easy」にするという我々の理想に近づいたことを意味しています。
AI には答えられない「Why」の壁
一方で、まだまだ課題はあります。
現在、AI にコーディング規約や設計ルールをプロンプトで与えることは一般的になっています。しかし、それらはあくまで 現在あるべき姿（How） を示しているに過ぎません。
例えば、次のような質問に AI は答えられるでしょうか？
- 「なぜ ECS ではなく EKS を選定しているのか？」
- 「なぜこの一般的なベストプラクティスを、あえて採用していないのか？」
- 「過去にどのような議論があって、この設計に至ったのか？」
こういった 過去の意思決定プロセスや文脈（Why） までは、既存のコードベースやプロンプトだけだと AI には理解できません。文脈を知らない AI は、一般論としての正解は出せても、組織独自のコンテキストを踏まえた回答を導き出せないのです。
これは、Platform Engineering において致命的な問題となり得ます。なぜなら、組織のプラットフォームは、その組織固有の制約や経緯の上に成り立っているからです。
ラストワンマイルとしての「ADR」
この足りないピースを埋めるのが、 組織の意思決定の履歴である ADR (Architecture Decision Record) ではないかと考えています。
ADR の役割の再定義
ADR は従来、人間が読むための記録として位置づけられてきました。しかし、生成 AI 時代においては、AI に「組織独自の文脈と判断基準」をインストールするための重要なデータソースとしての役割が加わります。
目指す姿
「現在のルール（How）」と「過去の ADR（Why）」 が揃って初めて、AI は組織固有の文脈を理解した上で、コードの生成や設計の提案を行えるようになります。
例えば、以下のような場面で AI が組織の文脈を踏まえた行動を取れると理想的です。
- 新しいプロダクトの IaC を書く際、過去の ADR から EKS を選定した理由（パフォーマンス要件や運用コスト）を理解し、同様の要件であれば自動的に EKS を前提としたコードを生成する
- 一般的なベストプラクティスを提案する前に、過去の ADR で組織の制約から不採用とした経緯があれば、それを避けて代替案を提示する
- Pull Request のレビュー時に、組織独自の設計判断基準とガードレールに基づいて、単なるコーディング規約だけでなくアーキテクチャレベルでの指摘ができる
AI に「コンテキスト」をどう渡すか
現在の取り組みと、今後の展望を紹介します。
現状（As-Is）
1. Markdown 形式に移行
以前は Notion や GitHub Discussions を使っていましたが、専用の GitHub リポジトリに切り出し、AI フレンドリーな Markdown 形式で ADR を残す運用に移行しました。
2. 横展開と普及活動
ADR リポジトリを Submodule としてインフラ系のリポジトリに横展開し、どこからでも生成 AI が参照できるようにしています。ただ自動的に参照されるような仕組みは構築できていないため、そこは今後の課題です。
今後の展望（To-Be）
1. 入力の自動化
ゼロから書くのはハードルが高いため、Slack/Zoom での議論や Pull Request の要約から、AI が ADR のドラフトを生成するフローを構築できると良さそうです。既に各ツールにおける要約機能は揃い始めているので、これらをどのようにシームレスに統合していくかが課題となります。
2. 品質の担保
AI に文脈を正しく理解させるためには、ADR 自体の品質がより重要になります。そのため、テクニカルライティングのケイパビリティを組織でどう獲得していくかが課題です。それ自体も AI の力を借りつつ運用プロセスを整えていくのが重要だと考えています。
おわりに
プラットフォームの認知負荷を最小化する取り組みは、単に便利なツールを作ることだけでなく、「組織のコンテキストを整備し、AI に正しく解釈させること」 へと拡張していくのではないでしょうか。
生成 AI は、プラットフォームを「Simple」に保ったまま開発者に「Easy」を提供する可能性を示してくれました。そして、その可能性を最大限に活かすために、ADR を使って組織固有の文脈を AI に伝える仕組み が重要になるのではないかと考え、これから検証していきたいと考えています。
宣伝
グロービスの SRE チームでは、生成 AI のためのコンテキスト整備以外にも、各種ガードレールの構築や開発組織へのイネーブリングなど、生成 AI 時代の SRE/Platform Engineering に関する取り組みを積極的に進めています。
もし興味を持っていただけたら、以下のリンクから SRE チームの取り組みについてご覧いただけると嬉しいです。
Discussion