Devtron Intelligence解説｜K8sのSRE向けAIエージェントは何を読み何を触らないか

Kubernetesの運用にAIエージェントを入れる話が増えていますが、実務で最初に問われるのは精度よりも権限です。そのエージェントはクラスタの何を読み、何を書き換えられるのか。OSSのKubernetesデリバリー／運用プラットフォームである Devtron がSRE向けAIエージェントを追加したという報道を起点に、公式リポジトリ・公式ドキュメント・Helmチャートの実物を読んで、この問いに数字で答えます。

本記事はDevtron本体の全機能紹介ではなく、AIエージェントがKubernetes運用のどこに、どんな権限で入るのかに絞ります。基盤となる自動化ツール全体の地図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方を参照してください。

検証環境と検証日は以下の通りです。本記事の数値はすべてこの時点の実測です。

・検証日：2026-08-04（JST）
・参照した一次ソース：devtron-labs/devtron（GitHub API）、devtron-labs/chartsのcharts/ai-agent（git clone）、devtron-labs/devtron-documentation（git clone）、quay.io/devtronのタグ一覧（Quay API）
・解析方法：Helmテンプレートの静的解析（ClusterRoleのルール・リソース・動詞を機械集計）およびGitHubコード検索

Devtron Intelligenceとは——SRE向けAIエージェントの正体

まず土台となるDevtron本体の実測値です。GitHub APIで2026-08-04時点の値を取得しました。

本体は活発に開発が続くK8sダッシュボード／デリバリー基盤です。ここに乗るAI機能が Devtron Intelligence で、公式ドキュメントでは「AI Agent」と併記されています。ドキュメントの定義はこうです。ワークロードを解析してトラブルシュートを速め、利用者が選んだLLMを使って理解しやすい示唆を出す——つまり 自動修復ではなく、調査の補助 として位置づけられています。

重要なのは、この機能がDevtron本体のバイナリに内蔵されているのではなく、独立したHelmチャートとしてクラスタに配置される点です。チャートはOSSのdevtron-labs/chartsリポジトリ（Apache-2.0）のcharts/ai-agentにあり、誰でも中身を読めます。本記事の検証はこの実物に基づいています。

Devtron側でAIが顔を出す場所は、公式ドキュメントによれば以下の画面です。いずれも「Explain」ボタンとして提供され、AIが状況を説明する形式に統一されています。

・Pod Errors：Resource Browser → Workloads → Pod でのエラー説明
・Pod Last Restart Snapshot：再起動直前のスナップショットに対する説明
・Event Errors：クラスタイベントのエラー解説
・App Details - Application Status：アプリのステータスドロワーでの説明
・App Details - K8s Resources：アプリ配下のワークロードに対する説明

この「Explain」の呼び出し側は、実はOSSのフロントエンドリポジトリで読めます。devtron-labs/dashboardをコード検索するとExplainWithAIがAppStatusCard.tsx・ResourceBrowser.service.tsx・AppDetails.component.tsx・EventsTable.tsxなど複数のコンポーネントに現れ、機能フラグFEATURE_AI_INTEGRATION_ENABLEがsrc/index.tsxと.envに定義されています。UI側の結線はプレスリリースではなく実コードで確認できる、ということです。

なお公式ドキュメントの見出しには Enterpriseバッジ が付き、価格ページへリンクしています。一方で価格ページのFreemium（無料）プランの説明は「all enterprise-grade features」を含むとしつつ、1クラスタ・10ユーザー・コミュニティサポートという上限を明記しています。二つの公式ページで表現が食い違っているため、本記事ではどちらかが正しいと断定しません。無料枠で使えるかは導入前にDevtronへ直接確認するのが確実です。

実測：AIエージェントに与えられた権限は「読むだけ」だった

ここが本記事の核心です。charts/ai-agent/templates/ai-agent-service-account.yamlは、エージェント用のServiceAccount・ClusterRole・ClusterRoleBindingを定義します。このClusterRoleを機械的に解析した結果が次の通りです。

・ルール数：16
・参照できるリソース種：51
・出現する動詞：get / list / watch の3つのみ
・create / update / patch / delete / deletecollection / *：0件
・secrets：含まれない
・pods/exec：含まれない

対象となるAPIグループは""（core）、apps、batch、extensions、networking.k8s.io、autoscaling、policy、rbac.authorization.k8s.io、storage.k8s.io、metrics.k8s.io、events.k8s.io、apiregistration.k8s.io、そしてmonitoring.coreos.com（Prometheus Operator系CRD）に及びます。ノード・Pod・ログ・イベント・HPA・Ingress・NetworkPolicy・PVC、さらにPrometheusのServiceMonitorやPrometheusRuleまで読める一方で、そのどれ一つも書き換えられないという構成です。

面白いのはdeployments/scale・replicasets/scale・replicationcontrollers/scaleというスケール用サブリソースが列挙されている点です。名前だけ見ると「AIがレプリカ数を変えられるのでは」と読めますが、これらに付与された動詞もget/list/watchのみでした。現在のレプリカ数を読むことはできても、変更はできません。

ただし「既定では」という条件が付く

正確を期すために、広げる余地も明記します。values.yamlには次の設定項目があり、運用者が権限を追加・変更できる設計になっています。

・customClusterRoleRules: []——ここに任意のルールを追記すると、上記16ルールの先頭に連結される。書き込み動詞を足すことも技術的には可能
・customServiceAccountName: ""——エージェントが使うServiceAccountを別のものに差し替えられる
・createServiceAccount: true——falseにするとClusterRole／Binding自体が生成されない

つまり正しい要約は「このAIエージェントはクラスタを変更できない」ではなく、「既定の権限は読み取り専用で、明示的に広げる経路が用意されている」です。導入レビューでは、customClusterRoleRulesが空のままかどうかが実質的なチェックポイントになります。

自分のクラスタで確認するコマンド

権限は他人の記事を信じる対象ではなく、自分の環境で確かめられるものです。エージェントをデプロイした後、そのServiceAccountになりすまして権限一覧を引けば、上記が事実かどうかは数秒で判定できます。

# 1) エージェントのServiceAccountが持つ権限を全列挙する
#    <ns> はチャートを入れたnamespace、<release> はHelmリリース名
kubectl auth can-i --list \
  --as=system:serviceaccount:<ns>:<release>-ai-agent-service-account

# 2) 書き込み系が本当に無いかを個別に確認する（no と返れば読み取り専用）
for verb in create update patch delete; do
  printf "%-8s " "$verb"
  kubectl auth can-i $verb deployments \
    --as=system:serviceaccount:<ns>:<release>-ai-agent-service-account
done

# 3) 付与されたClusterRoleの実物を読む
kubectl get clusterrole <release>-ai-agent-cluster-role -o yaml

1つめのコマンドでdeployments [get list watch]のように動詞が並べば、そのクラスタでの実効権限が確定します。2つめでnoが4回返れば、書き込み経路が無いことの直接的な確認になります。チャートを改変して導入した場合はここに差が出るので、受け入れ時の検収項目として実行する価値があります。

導入手順：ai-agentチャートのデプロイとLLMの持ち込み

公式ドキュメントの手順は7ステップですが、要点は「APIキーをSecretにする」「チャートを入れる」「Devtron本体に居場所を教える」の3つです。

まずLLMのAPIキーをSecretとして作ります。公式手順ではブラウザでbase64エンコードする方法も案内されていますが、kubectlで直接作る方がエンコード手順を省けます。

# LLMのAPIキーをSecretとして作成する（namespaceはチャートの導入先に合わせる）
kubectl create secret generic ai-secret \
  --namespace=my-namespace \
  --from-literal=OpenAiKey='<your-openai-key>'
# 他プロバイダを使う場合のキー名:
#   GoogleKey / azureOpenAiKey / AnthropicKey
#   awsAccessKeyId, awsSecretAccessKey （AWS Bedrock）

次にChart Storeからai-agentチャートを選び、values.yamlのadditionalEnvVarsでモデルとキーの参照を指定します。チャートは「調査したいワークロードがあるクラスタ」に入れる点、そして1クラスタにつき1エージェントという制約が公式に明記されています。

# values.yaml — OpenAIを使う場合の設定例
additionalEnvVars:
  - name: MODEL
    value: gpt-4o-mini          # gpt-4o / gpt-4 なども指定可
  - name: OPENAI_API_KEY
    valueFrom:
      secretKeyRef:
        key: OpenAiKey          # 上で作ったSecretのキー名
        name: ai-secret
  - name: CLUSTER_NAME
    value: document-nonprod     # 対象クラスタ名（任意）

モデル指定の書式には特徴があります。Geminiはgemini/gemini-2.0-flash、Bedrockはbedrock/anthropic.claude-3-5-sonnet-20240620-v1:0、Azureはazure/<DEPLOYMENT_NAME>と、プロバイダ名をスラッシュ区切りの接頭辞にする方式です。これは複数プロバイダを1つのインターフェースで扱うルーティング層で広く使われる記法で、エージェント側が汎用のLLM抽象化を挟んでいることを示唆します。

デプロイ後は、生成されたServiceのエンドポイントをDevtron本体のConfigMapに登録します。devtron-cmにCLUSTER_CHAT_CONFIGとしてクラスタIDとサービス名・namespace・ポートの対応を書き、dashboard-cmにFEATURE_AI_INTEGRATION_ENABLE: "true"を入れ、devtronとdashboardのDeploymentを再起動する——という流れです。機能フラグで明示的に有効化する設計なので、入れただけでは有効にならない点は運用上の安心材料になります。

チャートのDeployment定義からは、エージェントの実行形態も読み取れます。コンテナはquay.io/devtron/ai-agentイメージをpython3 -u server.pyで起動し、replicasは1、メモリ上限は1024Mi、CPU requestは100mです。ALLOWED_TOOLSETSの既定値はkubernetes/core,internetで、外部ネットワークへ出るツールセットが既定で有効になっています。閉域運用のクラスタではここを絞る検討が要ります。

AI Recommendations：AIが書いたRunbookを人間が承認するまで

ここまでが「調査を助けるAI」の話でした。報道で語られた「Runbookの自動実行」は、実は別モジュールの AI Recommendations に対応します。公式ドキュメントによれば、こちらが扱うのは主にコスト最適化とリソースのライトサイジングです。過剰にプロビジョニングされたクラスタや、20%の使用率で動き続けるワークロードを見つけて是正する、という目的が明記されています。

構成は2モジュールです。Notifications が最適化の示唆を提示し、Runbooks がYAMLで書かれた是正手順を定義します。そして両者の間に人間が入ります。

公式ドキュメントの記述はこうです。AIが最適化の機会を検出すると、対応するRunbookを自動生成する。そのRunbookはNotificationsから自動リンクされる。そして superadminがrecommendationをApproveした時点で、紐づいたRunbookがトリガーされ是正が実行される。裏を返せば、承認が無ければ実行されません。

Notifications画面にはAI Thought Process（AIが提案に至るまでの分析過程）とActivity Trail（AIと承認者それぞれの操作履歴）が表示されると記載されています。承認の可否を判断する材料として、AIの推論経路を人間に見せる設計です。加えて、完了後にRevert Changeで是正を巻き戻せること、監査ログがユーザー・モジュール・アクション種別でフィルタできることも明記されています。

Runbookの実体はYAMLで、apiVersion: devtron.ai/v1 / kind: Runbookという独自リソース形式です。spec.stepsに手順を並べ、各ステップはaction（実行する定義済みアクション）とtype（kubectl-get・kubectl-patch・devtron-app-patch・helm-chart-patchなど）、parameters、onFailure（失敗時の遷移先）を持ちます。公式ドキュメントが挙げる例は「Deploymentのマニフェスト取得」「ワークロードのCPU/メモリ要求と上限の更新」「Devtron管理アプリの設定更新」「Helm chart valuesの更新」で、いずれもリソース量の調整に寄っています。

つまり実行される操作はAIがその場で考えた任意のコマンドではなく、型付けされた定義済みアクションの組み合わせです。承認の対象がYAMLとして事前に読める形になっていることが、この設計の要点といえます。

イベント起点の自動化は、そもそもAIではない

もう一段掘ると、OSSのdevtronリポジトリにはSQLマイグレーションscripts/sql/248_auto_remediation.up.sqlがあり、k8s_event_watcherとauto_remediation_triggerという2つのテーブルを作成しています。k8s_event_watcherはfilter_expression・gvks・selected_actions・selectorsを持ち、auto_remediation_triggerはtypeにDEVTRON_JOBというコメントが付いています。

これは 「イベントが条件式に一致したらジョブを起動する」というルールベースの自動化 であり、LLMは関与しません。公式ドキュメントでもResource Watcherとして別に説明されています。「Kubernetesの障害対応が自動化される」という話を聞いたとき、それがAIの判断なのか決定論的なルール一致なのかは、実装上まったく別物です。Devtronは両方を持っており、自動実行されるのはルールベースの側です。

報道の表現と、公開物で確認できたことの差

出発点となった報道（cloudnativenow.com、2025-11-10付）は、DevtronがSREワークフローを自動化するAIエージェントを追加したと伝え、SREが「承認済みRunbookを自動実行するAIエージェントに頼って、自律的に耐障害性を維持する」ことを可能にすると記述しています。同記事はCEOのRanjan Parthasarathy氏のコメントを引き、v2.0でのKubeVirt対応・FinOps・GPUサポートにも触れています。記事は同時に「AIエージェントの出力を検証する人間のSREは当然まだ必要」とも述べています。

一次ソースと突き合わせると、報道が誤りというより 粒度が粗い ことが分かります。「AIエージェントが自動化する」という一文の中に、権限の異なる3つの層が畳み込まれているためです。

エンジニアとして押さえておきたいのは、「AIエージェントが運用を自動化する」という表現が、実装レベルでは権限設計の話に還元されるということです。Devtronの答えは明快で、AIには読む権限と提案する権限を与え、変更する権限は人間の承認の向こう側に置いています。

Devtronのai-agentは何をベースにしているのか

チャートの設定項目には、既存OSSとの共通点が見て取れます。values.yamlのpostProcessingPromptの既定値はbuiltin://generic_post_processing.jinja2という文字列で、allowedToolsets・CUSTOM_TOOLSET_LOCATIONといった環境変数と組み合わされています。

このgeneric_post_processing.jinja2という文字列をGitHub全体でコード検索すると、ヒットは11件でした。そのうちDevtron関連を除く全件が、K8sトラブルシュート用のOSSエージェント HolmesGPT（HolmesGPT/holmesgpt、Apache-2.0、2,996 star、Python）とその派生・フォークです。holmes/core/tool_calling_llm.pyにも同じ文字列が現れます。toolsetという概念、jinja2によるプロンプト後処理、プロバイダ接頭辞つきのモデル指定という組み合わせも一致します。

ただし本記事では 「HolmesGPTベースである」とは断定しません。エージェント本体はquay.io/devtron/ai-agentというコンテナイメージで配布されており、その中身のソースは公開されていないためです。確認できたのは「設定インターフェースがHolmesGPTのものと一致する」ところまでで、内部実装の同一性は未検証です。読者が自環境で確かめるなら、イメージを取得してpip listでパッケージ構成を見るのが最短の裏取りになります。

なお、K8s運用の可視化という同じ土俵にはOSSの選択肢が複数あります。役割の違いを整理すると次の通りです。

Devtron IntelligenceのClusterRoleがmonitoring.coreos.comのCRD（Prometheus・ServiceMonitor・PrometheusRule等）まで読める設計になっているのは、Prometheus系の監視基盤が既にある環境を前提にしているためと考えられます。監視データを人間が読む導線と、AIが読んで説明する導線は競合せず補完関係にあります。

導入前に確認したい制約と注意点

最後に、公開物から読み取れる制約を挙げます。断定できない部分は断定していません。

公開チャートとイメージの更新が止まっている。 charts/ai-agentのGit履歴は3コミットすべてが2025-06-04で、以降の変更がありません。quay.io/devtron/ai-agentの公開タグも0.0.1と0.0.2の2つのみで、いずれも同じ2025-06-04付でした。さらにvalues.yamlはimage: ai-agent:0.0.1を指しており、レジストリに存在する0.0.2ではありません。これらは公開されている範囲での観測であり、Enterprise契約者向けに別経路で更新版が提供されている可能性は否定できません。公開物だけを見て「これが製品の現状だ」と判断するのは避けるべきですが、検証に使えるのは公開物だけである点も事実です。

LLMへ送られる内容の確認が必要。 エージェントはPodログ・イベント・マニフェストを読んで外部LLMへ渡します。ClusterRoleにsecretsは含まれませんが、Podログや環境変数、ConfigMapの中に機密情報が混ざっていれば、それはLLMプロバイダへ送られ得ます。configmapsは参照可能なリソースに含まれています。既定でinternetツールセットが有効な点も含め、送信内容のポリシーは導入前に整理しておく領域です。

用途を追えない設定項目がある。 values.yamlにはenableAccountsCreate: trueという項目が既定で有効になっていますが、この値はチャート内のどのテンプレートからも参照されていません。つまり非公開のコンテナイメージ側で解釈される設定であり、何を「作成」する機能なのかは公開物からは確認できません。名前から権限に関わる挙動を推測することはできますが、本記事では推測を事実として書きません。導入前にDevtronへ確認すべき項目として挙げておきます。

エージェントは単一レプリカ。 Deploymentのreplicasは1、メモリ上限1024Miです。可用性が要る用途なら設計の見直しが要ります。

適用ライセンス階層の表記が公式ページ間で一致しない。 前述の通り、ドキュメントのEnterpriseバッジと価格ページのFreemium説明で表現が異なります。商用利用の可否は公式に確認してください。

AIエージェントに「何をさせないか」を設計する観点は、Kubernetesに限った話ではありません。実行環境そのものを隔離してエージェントを安全に動かすアプローチについては、CubeSandbox解説：60ms起動MicroVMでAIエージェントを安全実行するTencentの設計思想が対照的な設計例になります。権限で縛るか、環境で縛るか——目的は同じでも手段が異なります。

コスト面の是正という観点では、デプロイ前にクラウド費用を可視化するInfracost活用ガイドのアプローチと、Devtronの「稼働後の実測から縮小提案を出す」アプローチを組み合わせると、事前と事後の両側から押さえられます。

まとめ

DevtronのSRE向けAIエージェントは実在します。press releaseだけの構想ではなく、公式ドキュメント・OSSのHelmチャート・OSSフロントエンドのコードという3つの一次ソースで裏が取れました。

そのうえで、実装が示す答えは報道の見出しより保守的です。診断を担うDevtron Intelligenceの既定権限は16ルール・51リソースすべてがget/list/watchで、書き込み系の動詞は1つもありません。変更を伴うAI Recommendationsも、AIの役割はRunbook YAMLの生成と差分の提示までで、実行はsuperadminの承認を経ます。そして真に自動で走るResource WatcherはLLMを使わないルールベースの仕組みです。

AIエージェントをKubernetes運用に入れるとき、評価すべきはモデルの賢さではなく、そのエージェントに紐づくClusterRoleです。 そしてそれは、kubectl auth can-i --list一行で自分の目で確かめられます。導入を検討するなら、まずこのコマンドを検収項目に加えることをおすすめします。

参照ソース

・devtron-labs/devtron — Devtron本体のGitHubリポジトリ（star数・ライセンス・リリース情報の実測元）
・Devtron公式ドキュメント: Using Devtron Intelligence — AIエージェントの設定手順・対応LLM・Explain対象画面
・devtron-labs/charts: charts/ai-agent — ClusterRole・Deployment・values.yamlの実物（権限解析の一次データ）
・Devtron公式ドキュメント: AI Recommendations — Notifications／Runbooksの承認フローと監査ログ
・Devtron公式ドキュメント: Runbooks — Runbook YAMLのスキーマと定義済みアクション例
・HolmesGPT/holmesgpt — 設定インターフェースの比較対象としたOSSのK8s調査エージェント
・Devtron adds AI agents to SRE platform for Kubernetes environments — cloudnativenow.com（2025-11-10）本記事の出発点となった報道