K8s基盤をAIと共に開発している話

はじめに

こんにちは。基盤本部プラットフォーム部・共通基盤グループのkaikaiです。
最近なぜか指が痛くClaude Codeのvoice機能に入門してみたのですが、うまく喋ることができず、イライラして結局タイピングに戻り、指が痛くなってしまいます。
ということで？今回は現在我々が取り組んでいるKubernetes基盤(以下K8s基盤)の構築にAIを活用している、というお話をします。
基盤構築にAIを使ってガンガン開発すること自体はどこもやっていると思いますが、あまり記事を見たことがなかったため我々の取り組みを共有しようと思います。
この記事では

我々がK8s基盤構築でAIをどのように利用しているのか
AIを使って良かったこと
課題やそのアプローチ

に触れていきます。

そもそもK8s基盤構築プロジェクトについて

今回のメインではないのですが、前提としてK8s基盤構築プロジェクトについて簡単に話させてください。
詳しい話は以下のリンクを確認していただけますと幸いです。

本基盤の背景や概要:https://techblog.hacomono.jp/entry/2025/10/14/110000
本基盤に関する具体技術の紹介: https://findy-tools.io/products/aws-eks/208/840
本基盤で利用しているCrossplaneやその利用についての紹介: https://speakerdeck.com/hacomono/platform-engineering-with-crossplane-resource-abstraction-simplified

また、本基盤で利用しているCrossplaneというツールについて5/15日にクラウドネイティブ会議にて発表予定ですのでよろしければぜひお越しください！！

誕生背景

マルチプロダクト戦略を遂行していくために、インフラ構築のボトルネックを解消しつつ、プロダクトが増えても運用負荷を抑えられる仕組みが必要だったため、共通基盤の構築を開始

コンセプト

さまざまなK8sエコシステムを利用し、ガードレールが敷かれているSelf-service提供を狙っている
アプリ開発者はK8sやAWSに詳しくない想定で基盤を構築
コスト効率や要件達成を考慮してOSSのエコシステムを多く利用して基盤を構築

開発・運用体制

1.2~1.5人稼働
AIはClaude Codeをメインで利用
K8sつよつよエンジニアは不在

どこでどのようにAIを使っているか

以下のようにほぼ全ての作業にAIを使っています。また、アプリ開発者に対してAgent Skills(以下Skills)も提供しており、アプリ開発者のみでインフラ構築ができるような整備をしています。

開発作業
- manifest,helm values,terraformなどのIaC
- GitHub Actionsのworkflow
- Policy整備(Rego)
- CLIなどのツール(Go言語)
- 基盤の振る舞いテスト
- PRレビュー
- などなど
トラブルシュート
アプリ開発者へのSkills提供

AIを使って新しい基盤機能を開発する流れは以下のような流れです。

ADRを記述してチーム内で合意をとる
開発環境を構築
ADRを元にAIに実装させて開発環境にデプロイする
振る舞いテストの実施
K8sのAPIやAWSのAPIをAIに実行してもらい、トラブルシューティングや実装漏れの検知。場合によっては実際のOSSをCloneして読ませる。
実装者およびレビュアーが変更内容をレビュー
マージ

K8sの豊富なAPIがAIと相性が良く、実装でミスあってもAIが自動でミスを見つけてくれることが多いです。またK8sの可搬性の高さも魅力的で、AIがある程度安全に暴れられる開発環境を簡単に作成できます。
また、どうしても不具合が治らないときは実際のOSSのIssueを検索させたり、コードをCloneしてAIに読ませたりすることで、コードレベルで実際に起きていることを説明してもらい、納得した上で開発に反映させています。
一方、私個人の話ですが、ドキュメントなどの文章作成では以下の理由からあまり積極的にAIを使っていません。

ドキュメントには微妙なニュアンスや暗黙的なコンテキストを記述することが多く、それらを事細かにAIに指示するぐらいであれば自分で書いたほうが早いと感じているから
ドキュメントを使った説明を行う際に、自分で書いてない文章を説明するのが難しく感じるから
AIの文章がやや冗長になりがちだから

AIを使っていて良いこと

1. 開発速度の向上

第一に当たり前ですがPRを出すところまでは爆速になっています。コードを書くのはもちろん、不具合の修正やデバッグ、デプロイまでAIが自動でやってくれます。IaCのプロパティに対してAIはよくミスをしますが、ミスしたこと自体をAIが調べてくれるので、そこまで大きな問題になってないです。
具体的にはこちらで述べた通り、開発環境のK8s 権限をAIに渡して実行してもらったり、オブザーバビリティツールとAIを接続することで、調査や調整を自動でさせています。

2. OSSエコシステムの挙動把握

AIにコードを読ませることで、なぜうまくいかないか？逆になぜそのプロパティで問題ないのかをドキュメントやコードレベルで教えてくれます。全く理解できない現象が生じても、論よりコードという感じで納得感が強いです。
加えてAIとのやり取りで人間がエコシステムの動作に詳しくなり、得られた知識が運用で役に立ちます。
AIが発見した不具合で最近印象に残っているものとして、Lokiのバグがありました。すでに他の人がissueおよびPRを上げてはいたのですが、AIがコードベースを分析しissue作成者と同じ回答を導き出せていました。Lokiほど巨大なコードベースであっても正確に原理を見つけてくれることが多いと感じています。

この作業ができるのはコードが公開されているOSSの利点だと感じました。

3. CIやツールの量産

CIやちょっとしたツールなどが簡単に整備できるのもとても良いと感じます。
「あったら良いがMustではない実装」は後に追いやられがちでしたが、今ではサクッとAIが作成してくれるため、どんどんツールを作成させています。このおかげで、AIと人間が早期にミスに気づきやすくなっている(またはミスがないことを確認できる)ため、ツールによってさらに開発が安定・爆速になっています。
例えば我々はArgoCDのApplicationリソースをパースして、デプロイ対象のHelm chartをすべて展開し、ブランチ間/環境間のdiffを出力するツールを開発しました。これにより「コードを変えた結果、実際のリソース差分がどうなるか」をレビュー時に簡単に確認できるようになりました。
以下はHelmのバージョンアップに関するRenovateのPRでどのような変更が起きるのかをツールが示してくれています。

4. アプリ開発者への支援

アプリ開発者に対してもAIは役に立っています。
Skillsによってアプリ開発者がインフラを構築できたり、整備しているドキュメントをAIが参照して基盤に対する質問を回答してくれます。たまにくる問い合わせに関しても「AIに聞いたら問い合わせが必要だったから」というものが多く、問い合わせ内容も妥当なことがほとんどです。

AIの返答を見るに、ADRなどのドキュメントを返答の材料にしており、ADRやその他ドキュメントを整備しているのがよく働いているようです。以下は我々が提供しているCR(カスタムリソース)の思想について聞いてみたのですが、ADRを参考にしていることがわかります。内容もバッチリあっていました。

現在の課題

良いことばかり書きましたが、まだ難しいと感じていることはたくさんあります。

1. レビューの難しさ

K8sのような宣言的に記述するモデルは1行1行の影響力が大きく、裏側で実際に何が起きているのか、問題はないのかをレビューすることが大変なことがあります。レビューにもAIを導入していますが、AIを100％信頼しても問題ない仕組みができておらず、重要なコードはレビューワーが責任を持ってレビューするようにしています。
また、レビューをすることで、基盤を運用していくための知識を蓄えることも目的の一つになっているため、重要なコードをレビューなしでマージするのは現状難しいです。

2. アプリ開発者の心理的ハードル

基盤への理解なしでアプリ開発者だけがインフラ構築を行うハードルが高いという課題も感じております。前のセクションではアプリ開発者だけでインフラ構築が可能と述べたのですが、これは利用に慣れて、基盤に対してある程度の理解を持った人に限られている印象です。初めて利用する方は基盤の特性やK8s,GitOpsなどの技術に戸惑ったり、誤った利用をしたり、そもそもよくわからないので放置をするといったことが見受けられています。AIがなんでも答えてくれるとはいえ、ハルシネーションに対する疑念や、慣れない単語・技術に対しては心理的なハードルが高くなってしまうのも頷けます。

3. 運用体制

レビューの難しさで述べた通り、レビューなしで進めるのが難しい上に、運用体制が2人のため、他業務の忙しさによってはレビューが溜まってしまうことも多々あります。また、基盤開発の業務に圧迫され開発者の心理的ハードルを下げるための活動を積極的に行えていません。

課題へのアプローチ

現在抱えている課題に対してはいくつかのアプローチを実施、検討しています。

1. レビュールールの整備

以下2つのルールを整備したことで、PRがマージされる速度が上がりました。
実装内容や勤務時間が違うことなど様々な要因もあるのですが、Gitの実測値ベースだと3〜4倍ほど機能追加のマージ数が上がっています。
1-1. レビュー必須/不要で分ける
まず、レビューを行うコードと行わないコードで分けることにしました。K8s/AWSリソースに対する機能追加や修正などをステージングや本番環境に実施する場合はレビューを必須としていますが、それ以外のCIやツールの改善、開発環境への変更などはCIが通ればレビューなしで変更できるようにしています。これにより、細かい改善やツール作成などを迅速にできるようにしています。
エコシステムのアップデートに関しても、関係のある破壊的変更がなく、開発環境で振る舞いテストが通ればマージというルールにしたことで、少ないレビュー工数済むようにしています。
1-2. レビュー行数のルール化と同期レビューの実施
コード変更を300行以内に抑えることを基本として、それ以上の場合は同期レビューを行うことにしました。これによりPR数は多くなりますが、レビュー者の1つのPRにかかる認知負荷と心理的ハードルを下げ、レビューが溜まりにくくしています。
また、意味的に分割しずらい300行以上のPRは、設定変更による影響を同期で共有・質問することで、PRのマージを早めつつ、運用体制の強化も行えています。

2. アプリ開発者自身で開発環境へデプロイ可能に

仕組み自体はレビュールールの整備で述べた仕組みと同じですが、担当アプリに対する変更かつ開発環境であれば承認なしでマージ可能にしました。これによりアプリ開発の速度に加え、基盤への慣れを早くすることを狙っています。
また、開発環境に限りコンテナイメージのlatestタグ運用を許可し、Deploymentのrestartのみで新イメージの検証を可能にし、さらに検証速度を上げています。正直ImageUploader等もっと良い方法があるかもしれないですが、サクッと導入できたためこのような方法を採用しています。

3. 運用体制の強化を検討

さらなるレビュー高速化やアプリ開発者への支援を達成するには基盤自体の機能改善に加え、運営体制をより固めるため、新しいメンバーの獲得が必要であるという結論に至りました。社内・社外問わずにどうにか運用体制の補充を目指して採用なども行う予定です。
さらなる機能改善と開発者への支援を強化していきたいです。
　私たちの取り込みにご興味がありましたら、ぜひ応募お待ちしております！

まとめ

最後まで読んでいただきありがとうございます。
K8s基盤の構築・運用では、実装だけでなく検証やトラブルシュート、アプリ開発者への支援まで含めてAIを広く活用しています。その結果、少人数でも改善のループを速く回しやすくなりました。
一方で、宣言的なIaCは1行の影響が大きさやレビューを通した運用知見の強化などを考慮すると、レビューを完全に無くすことは現状難しいです。また、アプリ開発者が基盤に慣れるまでの支援も一定必要であることがわかってきました。今後も安全性を落とさずに速度を上げるための運用設計を工夫しつつ、AI活用の仕組みも継続的に改善していく予定です。
もっと良い方法がある！うちではこういう使い方をしている！などがあればぜひ教えてください。

📖関連記事