Kubernetesクラスタを自然言語で操作するAIツールを検討しているインフラエンジニア、SREの方に向けた内容です。ChatGPTのような対話形式でkubectlコマンドを実行できるツールが増えていますが、そこには見落としやすいリスクがあります。
対話型のAIツールは「会話を続けて目的を達成する」ことに最適化されています。たとえばkubectl-ai（Googleが公開する自然言語kubectl操作ツール）に「apiのレプリカ数を3に増やして」と伝えると、モデルが状況を見ながら複数回コマンドを提案し、対話の中でクラスタの状態を変えていきます。
この仕組みの問題は、何が実行されたかを後から追いにくい点です。ターミナルのスクロールバック（過去の出力履歴）にはモデルの説明文とコマンドが混在します。CI（継続的インテグレーション、コード変更を自動検証する仕組み）に組み込もうとすると、テキストをスクレイピング（文字列を解析して情報を抜き出す処理）する羽目になり、構造化されたゲート（承認の関門）として扱えません。
なぜ起きるか：チャットREPLの設計思想
この問題の根っこは、多くのAI運用ツールがREPL（Read-Eval-Print Loop、対話的にコマンドを実行する仕組み）として設計されている点にあります。REPLはターン制の対話を前提にしており、「動くまで会話を続ける」ことがゴールになります。
この設計だと、ツール呼び出し（LLMがkubectlなどの外部コマンドを実行する処理）そのものが製品の中心になります。裏を返せば、実行前に人間やCIが立ち止まって確認するための「成果物」が存在しません。
プラットフォームチームが「AIが何かを適用した」という状況を信頼しにくいのは自然な反応です。運用現場が信頼してきたのは、diffやPull Request、Admission Policy（クラスタへの変更を検証・制御する仕組み）、変更チケットのような、レビュー可能な形式だからです。モデルの発話ログはこの「型」に馴染みません。
この構造上の違いを整理すると、対話型ツールは「セッションを続けて目的達成」を優先し、変更ゲート型ツールは「1つのプランを出して承認か拒否」を優先します。どちらが正しいという話ではなく、対話的にkubectlを触りたいのか、パイプラインに組み込める変更として扱いたいのかで選ぶべきツールが変わります。
自分のプロジェクトが該当するか確認する
現在使っている、あるいは導入検討中のAI運用ツールが「対話ログ依存型」か「構造化プラン型」かは、いくつかの観点で切り分けられます。
- 出力形式の確認: ツールの実行結果がJSON等の構造化データで得られるか、テキストの会話ログしか残らないか
- 承認フローの有無: 実行前にplan-only（計画だけ提示して適用しない）モードがあるか、デフォルトでコマンドが即実行されるか
- リスク分類の有無: 破壊的な操作（例: 全リソース削除に相当する操作）を事前にhard deny（強制拒否）する仕組みがあるか
- CI連携のしやすさ: 実行結果をパイプラインの条件分岐に使える形（JSONのkeyで判定できる等）で取得できるか
該当するツールを使っている場合、まず公式ドキュメントで「dry-run」「plan」「approve」といったキーワードで検索し、実行前に確認できるモードがあるかを見てください。存在しなければ、そのツールは対話ログに依存した設計である可能性が高いです。
対策の手順
対話ログ依存の落とし穴を避けるための具体的な手順を示します。
1. plan-onlyモードの動作を確認する
構造化プラン型を志向するツールの一例として、kprompt（Kubernetes向けの自然言語運用ツール）があります。実際の挙動を確認してみます。
kprompt "scale api to 3" -n stagingこのコマンドは即座にクラスタを変更するのではなく、実行計画（Plan）とリスクレベルを提示し、y/Nの確認を挟みます。ここでnと答えれば何も実行されずに中断します。
2. 機械可読な出力でCIに組み込む
人間の確認だけでなく、CIのゲートとしても同じ情報を使えるかを確認します。
kprompt "scale api to 3" -n staging -o json | \
jq '{intent:.plan.intent, risk:.risk, denied:.risk.denied}'このようにintent（意図）、risk（リスク評価）、denied（拒否フラグ）が構造化データとして取れれば、パイプライン内で「riskがhighなら承認者を追加で要求する」といった条件分岐を組めます。
3. 破壊的操作の拒否ルールを把握する
全削除に相当するような「wipe-class」の操作について、有用な適用経路が用意される前に強制拒否される設計になっているかを確認します。運用ルールとして、どのコマンドパターンがhard denyの対象かをドキュメントで洗い出しておくと安心です。
4. 既存ツールとの役割分担を整理する
K8sGPT（クラスタ診断特化ツール）はscan→explainの診断フローに強く、Kagent（クラスタ内で動くエージェントフレームワーク）は複数エージェントの協調に強みがあります。自社の用途が「診断」なのか「変更の実行」なのかを切り分け、変更を伴う操作にはプラン提示型のツールを充てる、という使い分けが現実的です。
導入前に確認すること
Kubernetesを自然言語で操作するAIツールは、対話の快適さだけで選ぶと運用フェーズで痛い目を見ます。
- 実行前にplan-onlyで止まるモードがあるか、公式ドキュメントの「dry-run」「approve」の記述を確認する
- 出力がJSONなどの構造化形式で得られ、CIのゲート条件として使えるか試す
- 破壊的操作に対するhard denyルールの有無と対象範囲を洗い出す
- 診断特化ツールと変更実行ツールを混同せず、用途に応じて使い分ける
まずは手元の環境で-o json相当のオプションがあるか、--dry-runやplanコマンドが用意されているかをドキュメントで探すところから始めてみてください。