シリコンバレーから日本のエンタープライズまで、MLOpsの現場で共通して立ちはだかる壁があります。
それは、Kubernetesのマニフェストファイル、特にCustom Resource Definition（CRD）の記述です。
KServeは素晴らしいツールです。サーバーレスな推論、Scale-to-Zero（ゼロスケーリング）、カナリアリリースなど、AIモデルをプロダクション環境で運用するために必要な機能がすべて揃っています。しかし、その代償として、InferenceServiceのリソース定義は非常に複雑になりがちです。Knativeの設定、Istioのルーティング、リソース制限、環境変数……これらをドキュメントと睨めっこしながら手書きで正確に記述するのは、まさに「YAML地獄」と言っても過言ではありません。
「インデントが一つずれていてデプロイできない」「アノテーションのキー名を間違えてオートスケールしない」——皆さんも、そんな経験はありませんか？
今日は、視点を変えましょう。YAMLを「書く」のではなく、AIに「書かせる」のです。LLM（大規模言語モデル）をKServe専任のアシスタントとして活用し、要件を伝えるだけで最適な設定ファイルを生成させる。まずは動くものを最速で作り上げる、そんな「AI駆動のインフラ構築」テクニックを共有します。
なぜKServeの設定は「AIに書かせる」べきなのか
KServeの導入を決定したチームが最初に直面するのは、学習コストの壁です。ビジネスへの最短距離を描く上で、このコストは無視できません。通常のKubernetes Deploymentとは異なり、KServeは独自のCRD（Custom Resource Definition）構造を持っており、その複雑さはエコシステムの進化と共に増しています。
InferenceService記述の複雑性と人的ミスのリスク
例えば、TensorFlowのモデルをデプロイする場合と、Hugging Faceの最新モデルをカスタムコンテナでデプロイする場合では、YAMLの構造や要求されるランタイム設定が大きく異なります。
特に近年では、TensorFlowにおけるGPU利用環境の推奨手順が変化（例：Windows環境でのNVIDIA Docker利用の推奨化など）したり、Hugging FaceでmmBERTのような新しいアーキテクチャが登場したりと、技術の進化が非常に高速です。これらに追従しながら、GPUリソースの割り当てや、リクエスト数に応じたオートスケーリング（HPAやKPA）の設定を正確に記述するのは至難の業と言えます。
人間が手書きで設定を行う場合、以下のようなミスが頻発することは珍しくありません。
- APIバージョンと依存関係の不整合:
serving.kserve.ioのバージョンと、基盤となるKubernetes（最新のv1.35等）やKnativeの互換性ミス。 - アノテーションの誤記:
autoscaling.knative.dev/targetなどのKnative特有の設定や、GPUドライバに関連する記述のスペルミス。 - リソース定義の欠落: 推論ワークロードに応じた適切なLimits/Requestsの設定漏れによるOOMKilled（メモリ不足エラー）。
ドキュメントを行き来する時間をゼロにする
KServeの公式ドキュメントは充実していますが、実運用環境ではKnative、Istio、そしてKubernetes本体のドキュメントも併せて参照しなければならないケースが多々あります。「この設定はどのバージョンのKnativeに対応しているのか？」「最新のGKE環境でこのパラメータは有効か？」とタブを行き来して確認する作業は、エンジニアにとって大きな負担となります。
本記事のゴール：コピペで動くマニフェストの生成
仮説を即座に形にして検証するため、本記事のアプローチはシンプルかつ合理的です。複雑化するエコシステムの知識を内包したLLMに対し、「要件定義プロンプト」を入力し、「検証済みYAML」を出力させることです。これにより、構文エラーやバージョン不整合のリスクを低減し、実装時間を大幅に短縮することが期待できます。現場ですぐに使用できるプロンプトテンプレートを公開しますので、ぜひ活用してください。
KServe用プロンプト設計のコア原則
AIにコードを書かせる際、適切な指示がなければ期待通りの結果が得られない場合があります。特にインフラ設定においては、厳密なコンテキスト注入が必要です。生成AIは「なんとなく」の指示を補完してくれますが、Kubernetesのマニフェストにおいては、その曖昧さがデプロイエラーの温床となります。
バージョン互換性の明示（v1beta1 vs v1）
KServeは進化が速いプロジェクトであり、APIの仕様変更も頻繁に行われます。古いバージョンの構文が生成されないよう、必ずターゲットとするAPIバージョン（例：serving.kserve.io/v1beta1）を指定します。
また、使用しているKServeのバージョン（例：v0.13系など）も伝えるとより正確です。ドキュメントの更新頻度が高いため、特定のバージョンに依存する機能を使用する場合は、その前提をプロンプトに含めることが重要です。
リソース要件とハードウェア制約の定義
「GPUを使って」と言うだけでは不十分です。AIモデルの推論ワークロードに応じた具体的なハードウェア指定が不可欠です。
例えば、「NVIDIA H100を1枚、メモリは80GB確保」といった具体的な制約をプロンプトに含める構造にします。特に大規模言語モデル（LLM）の推論においては、使用するGPUアーキテクチャ（Ampere, Hopper, Blackwellなど）がパフォーマンスやコストに直結します。
以前はA100が主流でしたが、現在はH100やそれ以降の次世代GPU（Blackwell等）への移行が進んでいます。プロンプトでは、「nodeSelector や tolerations を使用して、H100インスタンスをターゲットにする」といった具体的な指示を与えることで、インフラの実情に即したYAMLを生成させることができます。
ストレージ（PVC/S3）連携のコンテキスト注入
モデルがどこにあるか（S3バケットなのか、PVCなのか、HTTP URIなのか）は、YAMLの storageUri フィールドに直結します。ここを曖昧にしないことが重要です。
以下に、すべてのテンプレートの基礎となる「共通コンテキスト」の例を示します。バージョンや環境は実際のプロジェクトに合わせて調整してください。
# 前提条件
- 対象環境: Kubernetes (最新安定版) + KServe (v0.11以降)
- API Version: serving.kserve.io/v1beta1
- クラウドプロバイダー: AWS (EKS)
- ハードウェア: NVIDIA H100 GPUインスタンス
- 目的: プロダクション環境へのAIモデルデプロイ
Template 1：基本のInferenceService生成
まずは、最も基本的な推論サービスを立ち上げるためのテンプレートです。ここでは「モデルの種類」と「保存場所」を指定するだけで、デプロイ可能なYAMLを生成させます。
単一モデルデプロイ用のプロンプト
以下のプロンプトをコピーして、{{ }} で囲まれた部分を要件に書き換えてLLMに入力してください。
あなたはKServeのエキスパートです。以下の要件に基づいて、KubernetesのInferenceServiceマニフェスト（YAML）を作成してください。
【要件】
1. サービス名: {{model_name}} (例: sklearn-iris)
2. ネームスペース: {{namespace}} (例: kserve-inference)
3. フレームワーク: {{framework}} (例: sklearn, pytorch, tensorflow)
4. モデルの保存場所: {{storage_uri}} (例: s3://my-bucket/models/iris)
5. サービスアカウント: {{service_account}} (S3アクセスのためのSA名)
【制約事項】
- APIバージョンは `serving.kserve.io/v1beta1` を使用すること。
- リソース制限として、CPU {{cpu_limit}}、メモリ {{memory_limit}} を設定すること。
- 不要なコメントは省き、そのまま `kubectl apply` できる形式で出力すること。
出力YAMLの解説と検証
このプロンプトを実行すると、以下のようなYAMLが生成されるはずです。ここで注目すべきは、AIがフレームワークに応じて適切な predictor ブロックを選択している点です。
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: sklearn-iris
namespace: kserve-inference
spec:
predictor:
serviceAccountName: s3-sa
sklearn:
storageUri: "s3://my-bucket/models/iris"
resources:
limits:
cpu: "1"
memory: "2Gi"
requests:
cpu: "0.5"
memory: "1Gi"
手書きの場合、sklearn なのか pytorch なのか、あるいはカスタムコンテナ(containers)を使うべきかで迷うことがありますが、プロンプトでフレームワークを指定すればAIが構造を決定してくれます。
Template 2：サーバーレス＆オートスケーリング設定
KServeの真骨頂は、Knativeベースのサーバーレス機能です。リクエストがない時はPod数を0にし（Scale-to-Zero）、リクエスト急増時に自動でスケールアウトする。この設定はアノテーションが複雑で、最もミスが起きやすい部分です。
ゼロスケーリングと同時実行数（Concurrency）設定
以下のプロンプトは、スケーリング戦略を自然言語で指示し、複雑なアノテーションに変換させるためのものです。
作成したInferenceServiceに対して、以下のオートスケーリング設定を追加・修正したYAMLを出力してください。
【スケーリング要件】
1. 最小レプリカ数: {{min_replicas}} (0にすればゼロスケーリング有効)
2. 最大レプリカ数: {{max_replicas}}
3. スケール指標: 同時リクエスト数 (Concurrency)
4. 目標同時実行数: {{target_concurrency}} (1ポッドあたり何リクエストまで捌くか)
【追加指示】
- コールドスタート対策として、初期化のタイムアウト時間を長めに設定してください。
- Knativeのアノテーション (`autoscaling.knative.dev/*`) を正しく使用してください。
- GPUを使用する場合の許容設定も含めてください。
期待される出力（オートスケーリング設定のYAML抜粋）
AIは以下のように、metadata.annotations に適切なキーと値を挿入します。
metadata:
annotations:
# ゼロスケーリング設定
autoscaling.knative.dev/min-scale: "0"
autoscaling.knative.dev/max-scale: "5"
# 同時実行数設定（ソフトリミット）
autoscaling.knative.dev/target: "10"
ここで重要なのは、target の値です。例えば「1ポッドで10リクエストまで並列処理可能」とAIに伝えれば、それが autoscaling.knative.dev/target に反映されます。自分で計算式を思い出す必要はありません。
Template 3：カナリアリリースとトラフィック分割
モデルのバージョンアップ時、いきなり全トラフィックを新モデルに向けるのは危険です。KServeでは簡単にカナリアリリースができますが、YAMLの記述は少しトリッキーです。
新旧モデルの安全な切り替え
新しいモデルをデプロイし、トラフィックの10%だけを流す設定を生成させましょう。
既存のInferenceServiceを更新し、カナリアリリース構成にしてください。
【要件】
1. 現行モデル (Default): そのまま維持
2. 新モデル (Canary):
- Storage URI: {{new_model_uri}}
- トラフィック比率: {{canary_percent}}% (例: 10)
【指示】
- `spec.predictor` とは別に、`spec.predictor` (canary) を定義するのではなく、KServeの標準的なカナリアリリースの記述方法（canaryTrafficPercentなどを使用、またはv1beta1の仕様に従い`canary`フィールドを使用）に従ってください。
- 正しいYAML構造で出力してください。
注意: KServeのバージョンによってカナリアの記述方法が微妙に異なる場合があります（canaryTrafficPercentを使うか、canaryセクションを設けるか）。プロンプトで「v1beta1の仕様で」と強く制約することが重要です。
期待される出力（カナリアリリース設定のYAML抜粋）
spec:
predictor:
canaryTrafficPercent: 10
# カナリアモデルの設定（更新部分）
sklearn:
storageUri: "s3://my-bucket/models/iris-v2"
※ 実際のKServeの仕様では、InferenceServiceの predictor 内のURIを新モデルに書き換え、同時に canaryTrafficPercent を指定することでトラフィック分割を行います。AIが最新のドキュメント（学習データ）に基づいて、適切な分割設定を提案してくれるはずです。
Template 4：トラブルシューティングとバリデーション
デプロイしたけれど READY 状態にならない。そんな時こそAIの出番です。エラーログをそのまま貼り付けて解析させます。
エラーログ解析と修正案の提示
KServeのInferenceServiceをデプロイしましたが、以下のエラーが出て起動しません。
【エラーログ / kubectl describe output】
{{error_log_paste_here}}
【質問】
1. 原因は何ですか？
2. 修正したYAMLコードを提示してください。
3. 今後防ぐためのチェックポイントを教えてください。
よくある原因として、「ServiceAccountがS3にアクセスできない（IAMロール不足）」「リソース不足（Insufficient memory）」「Readiness Probeの失敗」などが挙げられます。AIはログの断片からこれらを推測し、例えば「resource.requests.memory を増やしてください」といった具体的な修正案付きのYAMLを返してくれると考えられます。
生成されたマニフェストの品質管理チェックリスト
AIは強力なツールですが、最終責任は人間にあります。生成されたYAMLを本番環境に適用する前に、以下の3点は必ずエンジニアの目で確認してください。
人間が必ず確認すべき3つのポイント
- リソース制限の妥当性: AIはデフォルト値や適当な値（例: CPU 100m）を入れることがあります。実際のモデルサイズに合わせて、特にGPUメモリやCPUリクエストが適切か確認してください。
- セキュリティコンテキスト: 特権モード（
privileged: true）になっていないか、不要な環境変数が含まれていないかを確認します。 - イメージタグ:
latestタグが使われていないか。商用環境では必ず具体的なバージョンタグ（例::v1.2.3）やSHAハッシュを使用するよう修正してください。
CI/CDパイプラインへの組み込み
プロンプトで生成したYAMLは、そのままGitリポジトリにコミットするのではなく、KubevalやKube-linter、あるいはArgoCDのドライラン機能で構文チェックを通すフローを構築しましょう。
KServeのYAML記述は、AIプロンプトを活用することで「苦行」から「創造的な設計作業」へと変わります。細かな構文エラーに悩まされる時間を削減し、モデルのパフォーマンスチューニングやビジネス価値を生むアーキテクチャの改善にリソースを集中させましょう。まずは動くプロトタイプを作り、そこから最適化を図っていく。このスピード感こそが、AIプロジェクトを成功に導く鍵となります。
コメント