Kubernetes 上の kagent で安全な AI エージェントを構築する

開発者は現在、CNCF Sandbox プロジェクトである kagent をノートパソコン上でローカルに実行し、Kubernetes リソースとして動作する AI エージェントを構築できます。2026 年 10 月 12 日に Antonio Berben と Felipe Vicens によって公開されたこのガイドでは、他のエージェントを安全に生成する「エージェントビルダー」を作成する方法を実演しています。このプロセスは、大規模言語モデル（LLM）を暗黙的に信頼するのではなく、厳格なガードレールに依存しています。

何が起きたか

この記事では、kagent を使用したエージェントビルダーのセットアップに関するステップバイステップの実験室（ラボ）の詳細が記されています。kagent はエージェントをスタンドアロンのプロセスとして扱うのではなく、Kubernetes のカスタムリソースとして定義します。このアプローチにより、既存のエージェントが新しいエージェント用の YAML マニフェストを生成できるようになり、事実上セルフサービスのビルダーが実現されます。セットアップには Docker、kind、kubectl、helm、jq、Ollama などのオープンソースツールが使用されており、コストを最小限に抑え、クラウドへの依存を避けています。

セットアップの重要な部分には、ツールサーバーの安全な設定が含まれます。デフォルトでは、kagent チャートが cluster-admin 権限を付与する可能性があり、これはローカルテストであっても危険です。ガイドでは、ビルダーエージェントが特定のリソースタイプのみを作成できるように権限を制限するよう指示しています。これにより、生成されたエージェントが定義されたスコープ内で動作することが保証され、シークレットや Deployment など、クラスターの機密コンポーネントへの不正アクセスを防ぎます。

デモンストレーションでは、必要なインフラストラクチャのインストール、高性能なローカルモデルの選択、ユーザーインターフェースまたは API を通じたビルダーとの対話の手順が示されます。目標は、エージェントの構築が魔法ではなく、構造化されたエンジニアリングタスクであることを示すことです。初期セットアップは簡単ですが、これらのエージェントが単一のノートパソコン環境を超えてスケールするにつれて、ガバナンスとセキュリティの管理が真の課題となることを強調しています。

仕組み

このシステムは、プロンプトだけに依存しない 3 つの異なるセキュリティレイヤーに基づいています。第一に、許可リストにより、モデルが見ることができるツールが制限されます。利用可能な 22 個のツールのうち、ビルダーは 3 個にのみアクセスできます。第二に、human-in-the-loop メカニズムにより、状態を変更するすべてのツール実行の前にユーザーの承認が必要になります。エージェントが変更を提案すると、実行が一時停止し、ユーザーは適用前に正確なマニフェストを確認できます。第三に、Kubernetes レベルでのロールベースアクセス制御（RBAC）により、マニフェストが承認された場合でも、API サーバーはサービスアカウントの権限外のアクションを拒否します。

ビルダーエージェントは、「サポートチーム用のエージェントを作成する」といった自然言語のリクエストを受け取ることで動作します。その後、新しい Agent リソース用の Kubernetes マニフェストを生成します。このマニフェストには、システムプロンプト、モデル設定、および制限された読み取り専用ツールセットが含まれます。ビルダーは作成を直接実行せず、代わりにレビュー用に YAML を出力します。承認されると、kagent コントローラーがマニフェストを適用し、Agent-to-Agent（A2A）プロトコルを使用する新しい Pod を起動します。

このアーキテクチャは、プロンプトを保証ではなくリクエストとして扱います。実際の強制執行はインフラストラクチャから行われます。例えば、モデルがツール名を幻覚（ハルシネーション）したり、エージェントではなく Deployment を作成しようとしたりした場合、許可リストまたは RBAC ポリシーがそのアクションをブロックします。この関心の分離により、モデル出力のエラーがセキュリティ侵害や意図しないクラスター変更につながることはなくなります。

主要な詳細

• 推奨されるローカルモデルは qwen3-coder:30b-a3b です。より小さなモデルは有効な Kubernetes マニフェストを生成できないことが多いためです。
• ビルダーは、サーバー上で利用可能な 22 個のツールのうち 3 個の許可リストを使用しており、機能を制限しています。
• 状態を変更するすべてのツール呼び出しに対して人間の承認が必要であり、実行前のチェックポイントを提供します。
• RBAC ポリシーにより、ビルダーのサービスアカウントは Agent リソースの作成のみが許可され、シークレットや Deployment へのアクセスはブロックされます。
• セットアップでは、Kubernetes クラスターに kind を、ローカルモデル推論に Ollama を使用して、コストを最小限に抑えています。
• UI は kubectl port-forward を介して localhost 上で実行され、テスト中にパブリックインターネットに公開されないようにしています。

なぜ重要なのか

ソフトウェアエンジニアやテクニカルリードにとって、このアプローチは焦点をプロンプトエンジニアリングからインフラ設計へシフトさせます。安全性のためにプロンプトだけに頼るのは不十分です。なぜなら、モデルは指示を誤解したり、ツール名を幻覚したりする可能性があるからです。セキュリティを Kubernetes レイヤーに組み込むことで、チームはモデルエラーに対して堅牢なエージェントを構築できます。この方法は、明確な監査証跡と強制可能な境界を提供し、本番環境において不可欠です。

記事はまた、ローカル実験とエンタープライズガバナンスの間のギャップも浮き彫りにしています。ノートパソコン上では、すべてのアクションが同じユーザーから来ているように見えるため、コストや所有権を追跡するのが困難です。企業環境では、複数のエージェントやフレームワークが共存し、それぞれ異なるセキュリティ体制を持つ可能性があります。この複雑さは、トラフィックのプロキシ、認証処理、すべてのエージェントインタラクションにわたる可観測性を提供する中央集権的なガバナンスレイヤーの必要性を示唆しています。

これらのメカニズムを理解することは、開発者が単純なデモを超えて信頼性の高いシステムを構築するのに役立ちます。YAML や kubectl といった慣れ親しんだツールを使用して、AI エージェントを既存の DevOps ワークフローに統合できることを示しています。これにより、すでに Kubernetes に投資しているチームにとって参入障壁が低くなり、まったく新しい運用パラダイムを採用せずに AI を活用できます。

できること

• ラボのためのローカル環境を準備するために、Docker、kind、kubectl、helm、jq、Ollama をインストールします。
• 信頼できるマニフェスト生成を確保するために、Ollama を使用して qwen3-coder:30b-a3b モデルを取得します。
• kagent-builder という名前の kind クラスターを作成し、kagent をインストールします。
• 許可リストを設定し、ビルダーエージェントがアクセスできるツールを制限します。
• human-in-the-loop 承認ワークフローを実装し、状態変更を伴うツール実行の前に確認ステップを追加します。
• RBAC ポリシーを適用し、ビルダーのサービスアカウントが Agent リソースのみを作成できるように制限します。