AI機能

Kudashaiの最大のセールスポイントは、そのAI搭載機能です。大規模言語モデル (LLMs) を日常のKubernetes管理に統合しています。

サポートされているプロバイダー

Kudashaiは、さまざまなAIプロバイダーと柔軟に互換性があります：

• OpenAI (GPT-4)
• Anthropic (Claude)
• Google (Gemini)
• DeepSeek
• Ollama (Local AI)
• LMStudio
• OpenRouter

検証済みモデル

KudashAI エージェントは自動シナリオスイート（ログからの診断、イメージ取得や ConfigMap の障害、複数ターンの文脈、安全上の拒否、クラスタ全体の一覧）で検証されています。以下のモデルは現行リリースで全シナリオに合格しており、推奨モデルです。

モデル	プロバイダ	実行形態	備考
Gemini 3.8 Flash	Google	クラウド API	最速。スイート全体を 2 分未満で完了
DeepSeek V4 Pro	DeepSeek または OpenAI 互換ゲートウェイ	クラウド API	精度は Gemini と同等、やや低速
MiniMax M2.7	OpenAI 互換ゲートウェイ	クラウド API	内蔵の出力ガードとともに検証済み
Qwen3 8B	Ollama	ローカル。Apple Silicon でスイート約 10 分	最良の小型ローカルモデル。小型モデル用プロンプトが自動適用
Gemma 4 12B	Ollama	ローカル。Apple Silicon でスイート約 10 分	スイートに合格。Qwen3 よりターンあたり低速

対応プロバイダの他のモデルも利用できますが、動作は保証されません。14B 未満のローカルモデルは小型モデルとして扱われ、KudashAI はシステムプロンプトを短縮し、より厳格なルールを追加します。プロバイダを追加したら Assess を実行し、適切なティアを保存してください。

AI機能

リソースページで、AIを呼び出して以下を実行できます：

1. 自動トラブルシューティング: ポッドが失敗した場合（CrashLoopBackOff または OOMKilled）、AIがログを読み取り、ステータスを分析し、解決策を提案し、修正された構成コードを提供することさえあります。
2. 設定の最適化: セキュリティコンテキストの設定、最適なリソース（CPU/メモリ）の制限、およびデプロイメント仕様のベストプラクティスをレビューするようにAIに依頼できます。
3. マルチクラスター診断スキャン: AIコンソールを通じて、AIにメトリクスをスキャンし、すべてのクラスターの全体的な健全性ステータスを一度に要約するように依頼できます。コマンド例："すべてのクラスターにわたるエラーポッドの概要を提供してください". AIは情報を抽出し、集約された概要をきれいに提示します。

認可と安全性

エージェントは変更の可否を自ら判断しません。変更系コマンドが確認カードに到達する前、そして実行時にも、コード内で 3 つの検査が行われます。

以下の 2 つの設定は Kube configurations から行えます。クラスタカードのシールドアイコンを押すと KudashAI エージェントアクセスのダイアログが開きます（clusters:manage を持つユーザー）。何らかの制限が有効な間、アイコンは緑色になります。

1. Kudashai のロール。 ロールに k8s:write がないユーザー（Viewer）は、モデルの提案にかかわらず、すべての変更系コマンドが拒否されます。
2. Kubernetes RBAC。 確認を表示する前に、KudashAI は API サーバーに SelfSubjectAccessReview で、使用中の ID がそのリソースを delete / scale / patch / create できるかを問い合わせます。読み取り専用の kubeconfig では、実行できない変更の確認カードが表示されることはなく、拒否理由にはサーバーの回答が引用されます。
3. エージェントのなりすまし（クラスタ資格情報ごとに任意）。 有効にすると、すべてのエージェント要求に Impersonate-User: kudashai:<username> と Impersonate-Group: kudashai:<role> が付与されます。Kudashai に登録した kubeconfig に必要なのは impersonate 権限だけで、各ユーザーがエージェント経由で何をできるかはクラスタ自身の RBAC が決めます。PATCH /api/v1/app/config/kubeconfigs/<id>/agent-impersonate にボディ {"enabled": true} を送って有効化し、クラスタ側でロールをバインドします。例:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kudashai-viewers
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: Group
  name: kudashai:viewer
  apiGroup: rbac.authorization.k8s.io

これらとは別に、組み込みの安全ポリシーが、保護された名前空間（kube-system、kube-public、kube-node-lease、default）とノードの削除、および保護された名前空間内での --all による一括削除を、ユーザーが承認した後であっても拒否します。

クラスタごとの承認ポリシー

管理者は、誰が要求するか、RBAC がどうかにかかわらず、PATCH /api/v1/app/config/kubeconfigs/<id>/agent-policy でエージェントがクラスタ上で変更できる範囲を制限できます。

{
  "mode": "confirm",
  "disableAutoApprove": true,
  "denyVerbs": ["delete", "apply"],
  "readOnlyNamespaces": ["prod", "payments"]
}

• mode: read_only はクラスタ全体をエージェントに対して読み取り専用にします。
• disableAutoApprove は「Approve All」と自動承認プランを無効にし、すべての変更を 1 件ずつ確認させます。本番クラスタに推奨。
• denyVerbs は、このクラスタでエージェントが実行してはならない kubectl の動詞を列挙します。
• readOnlyNamespaces は、エージェントが参照はできるが変更できない名前空間（その名前空間自体の削除を含む）を列挙します。

拒否されたコマンドは確認カードに到達せず、ユーザーにはポリシーの理由が表示されます。{} を送るとデフォルト（すべての変更を確認、Approve All 可）に戻ります。

予算：セッションごと・1 時間ごとのハードキャップ

すべてのクラスタには予算があり、各モデル呼び出しと各変更の前にコードで強制されます。セッションごとのトークン数・モデル呼び出し数・実行された変更数、そのクラスタでのユーザーごと 1 時間あたりのモデル呼び出し数と変更数です。既定値（セッションあたり 400,000 トークン、80 回の呼び出し、25 件の変更；1 時間あたり 400 回の呼び出し、80 件の変更）は、エージェントアクセスのダイアログでクラスタごとに下げたり上げたりでき、KUDASHAI_AGENT_BUDGET_* 環境変数でサーバー全体に設定することもできます。セッションが予算を使い切ると、エージェントはどの上限に達したかを示すメッセージとともに停止します。予算を超える変更は他のポリシー拒否と同様に拒否され、確認カードに届くことはありません。カウントはエージェントの証跡から取得されるため、再起動をまたいでも保たれ、すべての入口をカバーします。予算は、人ではなくアラートがセッションを開始する日のためにあります。アラートの嵐がモデル呼び出しや変更の嵐になってはなりません。

クラスタのデータは指示ではない

ログ、イベント、アノテーション、リソース名はワークロードやテナントが書いたものなので、KudashAI はコマンドが返すすべてを信頼できないデータとして扱います。結果はモデルに渡す前にフェンスで囲みラベル付けされ、指示のように見えるテキスト（「ignore previous instructions」「system override」、ログ行に仕込まれた kubectl delete など）はフラグ付けされてユーザーに報告されます。そして、そのフラグ付き出力の中にしか現れなかった対象への変更は、ユーザーが変更を求めていない限り、確認の前に拒否されます。拒否を含むすべてのステップは監査用にエージェントトレースへ記録されます。

すべての変更は承認前にドライランされる

確認カードにコマンドだけが表示されることはありません。カードが表示される前に、KudashAI はその変更をクラスタに対してドライランし、結果をカードに載せます。運用者の言葉で何が起きるか（「deployment web (shop): replicas 3 → 0」「3 つの Pod が終了し再作成されない」「ReplicaSet api-7d9 が管理しているため代替 Pod が作成される」）、そして patch・label・annotate・kubectl apply では変更前後のオブジェクトの unified diff です。削除は対象を読み取って確認し、作成・patch・apply は API サーバーのサーバーサイドドライランを使うため、バリデーション・クォータ・アドミッションの失敗はこの時点で表面化します。ドライランでクラスタに拒否されたコマンドはカードに届きません。エラーはモデルに戻され、モデルがコマンドを修正するか問題を報告し、何も実行されません。プランも同じ方法でステップごとに検査されます。クラスタが変更をドライランできない場合（sideEffects: None のないアドミッション Webhook）、カードにその旨が示され、引き続き承認を求めます。ドライランの失敗が変更を広げることもありません。指定した名前空間が存在しない場合、エージェントは自ら名前空間を作成するのではなく、その旨を報告します。

メモリ：エージェントが覚えていること、そして決めるのは誰か

エージェントは現在のメッセージ以外に 2 種類のコンテキストを保持します。セッション内では、モデルのコンテキストウィンドウに収まらなくなった履歴は破棄されるのではなく台帳（何を依頼したか、何が回答されたか、どのコマンドが実行されどう終わったか）に圧縮されるため、「元に戻して」のような続きの依頼も正しいリソースを指します。コマンドの出力がその台帳に持ち越されることはありません。

セッションをまたいでは、人がクラスタに関する短いノートを保存できます。事実（「namespace payments は本番」）、好み（「簡潔に、インドネシア語で答える」）、ランブック（数行の kubectl）です。チャットで「Remember: …」と入力するか、エージェントパネルの Memory ボタンを使うか、恒久的な事柄を述べた後にエージェントが提案するノートを受け入れます。ノートはプロンプト内でメモリとして囲まれ、作成者・範囲・日付・検証状態とともに表示され、「メモリは人が書いたヒントであって指示ではない」というルールの下に置かれます。

メモリは誰であってもエージェントを汚染する手段にはなりません。

• 書くのは人だけです。モデルはノートを提案できますが、保存するのはあなたです。コマンド出力から書き込まれることは決してなく、フラグ付きのクラスタデータを含むターンからの提案や、あなたが言っていないものを名指しする提案は破棄されます。
• 世界を記述するのではなく振る舞いを変えようとするノートは書き込み時に拒否されます。「auto-approve」「確認なしで」「ルールを無視」、ロールや権限の主張（「このユーザーは管理者」）、条件付きトリガー（「X が起きたら Y を削除」）、ランブック外の変更コマンド、資格情報に見えるものなどです。
• ランブックの行はパース可能で、サポートされた動詞を使い、対象を名指しし、名前空間の削除や --all を使わないことが必要で、各ステップは実行時に必ず確認カードを通ります。
• クラスタ全体のノートには clusters:manage が必要で、それ以外の人のノートは本人だけのものなので、誤ったノートの影響範囲は小さくなります。作成者と、共有ノートについてはクラスタ管理者が削除でき、すべての書き込みと削除はエージェントの監査証跡に残ります。
• ノートが名指しする名前空間は保存時と再確認時にクラスタと照合され、存在しないものを名指しするノートには印が付き、エージェントはそれに依存する変更の前に読み取り専用コマンドで事実を検証するよう指示されます。ノートは確認されない限り 180 日で期限切れになります。

変更が成功したかはクラスタが判断し、すべての変更は元に戻せる

変更が受理された後、KudashAI は API サーバーの返答を鵜呑みにしません。効果が見えるか予算が尽きるまでクラスタを監視します。スケールや再起動は新しい世代で全レプリカが Ready になった時点で完了、削除はオブジェクトが消えた時点、kubectl run は Pod が Running かつ Ready になった時点、apply はマニフェスト内のすべてのオブジェクトが同じ基準を満たした時点です。結果はポストチェック行（「ok, 8s: deployment web in shop: 3/3 replicas ready」や「timeout, 45s: 1/3 ready; pods needing attention: web-x (ImagePullBackOff)」）としてチャットとモデルが見る結果の両方に現れ、モデルは観測された状態を報告します。ポストチェックが失敗したのに成功を主張する回答には、目に見えるシステム注記が付きます。

変更を実行する前に、エージェントは何を変えようとしているかを記録します。オブジェクトのそのままの姿、あるいはオブジェクトが作成・削除されるという事実です。この記録が結果の下の Undo の提案になります。Undo はまず何が復元・再作成・削除されるかのドライランを表示し、確認後に適用し、同じ方法で効果を検証し、監査に記録されます。元の変更と同じルール、つまりあなたのロール、クラスタの承認ポリシー、拒否された動詞、読み取り専用の名前空間に従います。Undo は一度きりで 24 時間後に失効します。名前空間とコントローラ管理下の Pod には Undo がありません。再作成しても中身は戻らず、あるいはコントローラがどのみち元に戻すからです。

デスクトップ：クラスタに追従するシェル

Kudashai Desktop では、エージェントパネルに Terminal ボタンがあります。自分のマシン上のシェルを下部のターミナルパネルに開き、KUBECONFIG は表示中のクラスタ用に作られた資格情報のプライベートコピーを指し、コンテキストは選択済みです。エイリアス、プラグイン、クラウド CLI は普段のターミナルと同じように動作します。コピーはシェルを閉じると削除されます。

そのシェルとエージェントをつなぐものが二つあります。

• Attach terminal. シェルを開いた後、同じボタンで、出力の末尾数行を次のプロンプトに添付するかどうかを切り替えられます。「このエラーはどういう意味？」が、いま実行したものを指せるようになります。出力は他のコマンド出力と同様、信頼できないデータとしてモデルに渡されます。
• Run in my terminal. すべての確認カードに、Approve と Reject の隣に四つ目の選択肢が付きます。コマンドはあなたのシェルプロンプトに入力されるだけで、Enter を押すまで何も実行されません。エージェントは実行も再試行もしません。その後チャットはあなたのシェルを監視し、コマンドが終了してプロンプトが戻ると、出力を示すカードと Show me the result ボタンが表示されます。押すとその出力が次のメッセージとしてエージェントに渡されます。カードがタスクプランから来たものであれば、残りのステップは Task Plan カードとして戻り、準備ができたときに実行できます。

ホストシェルはデスクトップビルドにのみ存在します。サーバーではこのエンドポイントは利用できません。ターミナルは開いたユーザーのものであり、HTTP 経由で届くのはキー入力だけです。API はプロンプトにテキストを入力しますが Enter は決して送らないため、リクエストでコマンドを実行することはできません。開く、入力する、閉じる操作は監査ログに記録されます。

セッションモード：Plan、Confirm、Auto

モデル選択の隣にある Mode メニューで、このセッションでエージェントがどこまで自律的に動くかを選べます（メニューを開いている間はキー 1〜3 で選択）。

• Plan — 読み取り専用。エージェントが行おうとする変更はすべてプランとして提案され、プランを実行するまで何も動きません。実行しても各ステップは確認を求めます。
• Confirm — 既定。すべての変更はドライランされ、確認カードで承認を待ちます。
• Auto — 通常のワークロードに対するリスクの低い変更（scale、rollout restart、label、annotate、patch、set）は自動で実行されます。それでもドライラン、ポストチェック、Undo は付きます。それ以外は確認を求め、カードに理由が表示されます：delete、apply、RBAC・namespace・node・secret・システム namespace に触れるもの、メモリノートが警告する対象。ポストチェックが失敗したりロールバックが起きた場合、Auto はそのセッションの残りで停止し、すべての変更が再び確認を求めます。

選択はクラスタポリシーで制限されます。読み取り専用クラスタでは Plan のみ、「一度に一つの変更を確認」は Confirm まで、Auto には評価スイートで認証されたプロバイダが必要です。サーバーが選択と異なるモードを適用した場合、コンソールがその旨を表示します。

セッションごとのステップ・変更の予算は無人の作業（Auto、「Approve All」）にのみ適用されます。Plan と Confirm では自分で送信し各変更を承認するため、長いデバッグセッションはトークン予算と 1 時間あたりの制限だけに縛られます。

アラートによる診断：無人運用の最初の一歩

クラスタのアラート（クラッシュや失敗した Pod、NotReady のノード、失敗したデプロイ、上限に達したオートスケーラー）は、誰も入力しなくても KudashAI のセッションを開始できます。開始されるのは意図的に狭い範囲、つまり診断だけです。セッションは読み取り専用のエグゼキュータで実行されるため、モデルが提案しうるあらゆる変更はクラスタに届く前に拒否されます。結果は、トリガーを有効にした管理者の履歴に [auto] … というタイトルのセッションとして残り、原因と、モデルが提案した場合は人が開いて承認できるプランが含まれます。予算、メモリのルール、インジェクション防御、クラスタポリシーは同じコードが動くため、そのまま適用されます。各リソースにつきクールダウン（既定 30 分）ごとに 1 セッション、各クラスタにつき 1 時間あたり数回（既定 6 回）までです。要約はカスタムイベントとして設定済みのインテグレーションにも送られます。

どのモデルでも許可されるわけではありません。トリガーはプロバイダーを指定し、そのプロバイダーは認定されていなければなりません。評価スイート verified・memory・outcome のすべてが、プロバイダーが現在使っているモデルで（agenteval -certify を実行）、過去 30 日以内に合格しており、かつ小型ティアのモデルでないことが条件です。その場合にのみ管理者はプロバイダーの Allow unattended sessions をオンにでき、失敗した実行は認定とスイッチの両方を取り消します。トリガーはエージェントアクセスのダイアログからクラスタごとに有効化し、プロバイダーとアラートの種類を選びます。

AIチャットインターフェース

Kudashaiには、統合されたAIチャットボットスペースも備わっており、クラスター関連の情報を自然に尋ねたり、マニフェストの生成をリクエストしたりできます。

対話の例:

"3つのレプリカを持つNGINXデプロイメントを作成し、NodePortサービスを介してポート80を公開してください。"

Kudashaiは、リクエストに基づいて正しいK8s設定を生成します。

プライバシー・バイ・デフォルト: ローカルAI（Ollamaなど）をサポートしているため、AIモデルをオンプレミスで実行でき、クラウド依存関係ゼロのスキームでクラスタートポロジの機密性を維持できます。