Claude Code × LLM-as-a-Judgeで作る、自己改善するプラットフォームエンジニアリング基盤
生成AIを前提とした開発現場では、コード生成の仕組みそのものよりも、それを支える「ハーネス層」の設計と継続的な改善サイクルが品質を左右します。本記事では、スキャフォールド運用の限界から見えてきた戦略転換と、LLM-as-a-JudgeとClaude Codeを組み合わせた自己改善ループの仕組みについて解説します。
プラットフォームエンジニアリングが直面する4つの課題
プラットフォームエンジニアリングチームが目指すのは、開発者が自律的かつ迅速、安全に価値を届けられる共通基盤を用意することです。その実現に向けて、現場では次の4つの課題が顕在化していました。
- 認知負荷の増大：開発者が把握すべき情報・ツールが増え続けている
- 技術の属人化：ノウハウが個人に閉じてしまい、組織として再利用できない
- ツールの乱立による分散：似た用途のツールが増え、判断コストが上がる
- 開発スピード格差の拡大：チーム・個人によって生産性の差が広がっていく
これらは生成AI導入以前から存在した課題ですが、AIによるコード生成が当たり前になったことで、むしろ顕在化するスピードが上がっているという実感があります。
スキャフォールド運用の限界
課題への初手として取り組みやすいのが、テンプレートやひな形からコードを生成する「スキャフォールド」による自動化です。導入初期の立ち上がりを速くする効果は確かにあります。
ただし、長期的に運用してみると、生成されたコードへのパッチ当てやテストの工数がプロジェクトごとに積み上がり、案件ごとに個別の技術的負債として蓄積していくという問題が見えてきました。スキャフォールドは「最初の一歩」を速くする道具であって、継続的な品質改善の仕組みそのものではない、というのが率直な学びです。
戦略転換：画面の統一からデータ層・ハーネス層への注力へ
AIが開発の中心的なアクターになる時代において、これまでのような「ポータル画面への機能統合」というアプローチは、開発者の実際のニーズと噛み合わなくなってきています。開発者はポータルを見にいくのではなく、Claude Codeのようなエージェントと対話しながら作業を進めるからです。
そこで方針を転換し、画面（ビューアー）を統一することよりも、データ層と、AIエージェントの振る舞いを規定するハーネス層を継続的に進化させることに注力しています。ハーネス層とは、エージェントに与えるスキル・ルール・評価基準など、AIの出力品質を左右する土台部分を指します。
オブザーバビリティの確保：Claude Code × OpenTelemetry × Databricks
ハーネス層を「進化させる」ためには、まず現状を正確に観測できる必要があります。品質とパフォーマンスを継続的に監視するため、Claude CodeとOpenTelemetryを使って稼働データを取得し、Databricksに送信して可視化する仕組みを構築しています。これにより、異常検知や継続的な改善につなげることができます。
自己改善ループの仕組み
観測したデータをもとに、ハーネス層（スキル）を自動で改善していくループを用意しています。
LLM-as-a-Judgeによる評価とIssueの自動作成
LLM-as-a-Judgeの手法でスキルの出力を評価・スコアリングし、問題が見つかった場合は自動でGitHub Issueを作成します。Issue化された内容は、Claude CodeのGitHub Actionsによって自動的に修正が適用される場合もあります。
人間のレビューを挟んだ修正・再配布
自動修正がそのまま反映されるわけではなく、人間によるレビューを経てから修正・再配布する運用にしています。AIによる評価と人間の判断を組み合わせることで、品質を担保しながら改善サイクルを回しています。
週2回のディスカッションで拾う「人にしか気づけない」課題
自動化だけでは拾いきれない、開発者が現場で直面する新しい課題もあります。そのために週2回・30分のディスカッションの場を設けており、そこで得られた知見をもとに修正方針を決定し、スキルの再配布に反映しています。自動化と人によるディスカッションを両輪で回すことが、改善ループを機能させるポイントです。
評価指標（ルーブリック）そのものも進化させる
この改善ループを運用してみて見えてきたのは、改善ループの質は、結局のところ評価指標（ルーブリック）の質に依存するということです。スキルの中身だけを更新していても、評価する物差しが古いままでは改善の精度は頭打ちになります。
そのため、スキルの更新サイクルとあわせて評価指標自体もバージョン管理し、適切にアップデートする運用にしています。ジャッジ役のAIの精度を上げるには、ジャッジさせる基準そのものを育てていく必要がある、というのが実務上の気づきです。
今後の展望：エンジニアから全社へ
現状はエンジニア向けの開発基盤としての活用が中心ですが、今後はClaude Platformなどを活用し、エンジニアに限らず非エンジニアに対してもAIを活用した業務スキルを提供していく準備を進めています。開発の現場で培った「評価→改善→再配布」のループを、より広い業務領域のAI活用にも応用していく方針です。
まとめ
- スキャフォールドは初期速度には効くが、長期的には案件ごとの技術的負債になりやすい
- 画面統合ではなく、データ層とハーネス層への継続的な投資に舵を切った
- Claude Code＋OpenTelemetry＋Databricksでオブザーバビリティを確保
- LLM-as-a-Judgeによる自動評価とGitHub Issue化、人によるレビューを組み合わせた改善ループを運用
- 自動化だけでなく、週2回のディスカッションという「人が拾う」仕組みも両立させている
- 改善ループの精度は評価指標（ルーブリック）自体の質に依存するため、ルーブリックも継続的にアップデートしている
こうした「ハーネス層」を軸にした自己改善型のプラットフォームエンジニアリングは、社内で継続的に取り組みを進めています。AIDD（AI駆動開発）やプラットフォームエンジニアリングの基盤づくりでお困りの際は、お気軽にKDDIアイレットへご相談ください。 ※本記事でのハーネス層やプラットフォーム構成は2026年7月時点のものになります。