8月13日、Daniel Bryant（Syntasso）が「LLMOps and platform engineering: Who should own the AI pipeline?」と題した記事を公開した。LLMを本番運用しようとした瞬間、DevOps・MLOps・プラットフォームの三チームが同時に「自分たちの仕事ではない」と感じる——その組織的空白を埋めるべく、プラットフォームエンジニアリングの観点からLLMOpsの所有権と実装指針を整理した論考だ。

本質的な問いは「誰がパイプラインを所有するか」ではない

LLMを本番環境に載せることは、従来のMLとは別物だ。プロンプトをバージョン管理し、ベクターデータベースを呼び出し、出力のトーンや安全性を評価する——そのような運用を指すのがLLMOps（大規模言語モデルオペレーション）である。Google Cloudはこれを「MLOpsの特化したサブセット」と位置づけているが、差は大きい。LLMはファインチューニングとサービングのコストが高く、精度という単一の数値では品質を測れない。モデルが「安全で信頼できる」ことを継続的に保証しなければならず、それは一度きりのデプロイチェックリストでは到底足りない。

問題はここに組織的な摩擦が生じる点だ。DevOpsチームはデプロイチケットに追われ、MLOpsチームはMLflow・Kubeflow・Weights & BiasesといったDevOpsが想定していなかったデータバージョニングやドリフト監視のために独自スタックを構築してきた。そこへLLMOpsが加わると、プロンプト・ベクターストア・RAGパイプライン用の第三のスタックが誕生し、誰も統治できない状態になる。

Bryantが提示する問いの転換が核心だ。「誰がパイプラインを所有するか」ではなく、「誰がどのレイヤーを所有し、誰が横断調整するのか」が正しい問いである。

最大のリスクは「シャドーLLMOps」

モデルが幻覚を起こすことより危険な状況がある。あるチームが未レビューのベクターストアを使って独自にRAGパイプラインを立ち上げ、誰もそれを把握していない——というシャドーAIの拡散だ。なお、本稿における「シャドーLLMOps」という表現は、元記事がシャドーITの文脈で描写しているこの状況を編集部が端的に言い表したものであり、元記事固有の術語ではない。

これはかつてDevOpsとプラットフォームの分断が引き起こしたのと同じパターンである。プラットフォームが間に合わなかった機能が外部で作られ、結局プラットフォームに取り込まれないまま残る。Bryantの処方箋は「チームを遅くすることではなく、ガバナンスを組み込んだうえでプラットフォームが素早くYESと言えるようにすること」だ。

CNCFのレイヤーモデルで整理する

CNCF TAG App Delivery のPlatforms Whitepaperは、プラットフォームを3層で描いている。

• Products（上位）：開発者が実際に触るもの
• Platform（中位）：最小限の統合レイヤー
• Capability Providers（下位）：インフラそのもの

LLMOpsの各要素——モデルのファインチューニングジョブ、ベクターデータベース、プロンプトレジストリ、推論エンドポイント——は機能的には他のプラットフォームケーパビリティと同じであり、同じAPI・バージョニング・明確な所有者が必要だという整理だ。

CNCFエコシステムにはすでにツールが揃っている。Backstageがプロダクト層でゴールデンパス（推奨ワークフロー）を提供し、Crossplaneが下位層でインフラを構成する。中間層ではKratix・KusionStack・KubeVelaがLLMパイプラインを他のワークロードと同じセルフサービスインターフェイスで公開できる。なお、著者のBryantが所属するSyntassoはKratixの開発元である。記事の主張自体はCNCF全体のエコシステムを横断しているが、読者はこの利害関係を念頭に置いて参照されたい。

プラットフォームチームが実装すべき4つのガバナンス

Bryantが具体的に挙げる実装項目は以下の通りだ。

• ガバナンス済みAPI：ファインチューニングジョブ・プロンプトデプロイ・推論エンドポイントを、既存のセルフサービスUIから依頼できるようにする
• リクエスト時のポリシー適用：コスト上限・データ所在地ルール・モデルアクセス制御をジョブ開始前にチェックする（クラウド請求書が届いてから気づくのではなく）
• 影響範囲に応じた人間承認：すべてのプロンプト変更に承認は不要だが、顧客のPIIを扱うモデルや自律的な判断を行うモデルは別だ
• 監査証跡：モデル・プロンプト・データの何が変わり、誰が承認したかを追跡できる記録

まとめ

LLMOpsは独立した王国を必要とするわけではない。バージョン管理・オブザーバビリティ・コスト意識・フィードバックループを備えた、既存のプラットフォームに「迎え入れてもらう」ことが答えだ。DevOps対プラットフォーム対MLOpsの論争に加担するのではなく、LLMワークロードを含むパイプライン全体をプロダクトとして扱うチームが、この問題を解決しつつある。

この議論はCNCF内で継続中であり、TAG App Delivery Platforms Working Groupが窓口となっている。

※編集部の考察：本記事の論点はKubernetes時代のCI/CD統合議論と構造的に酷似している。当時も「Jenkinsは誰が管理するのか」問題が組織を悩ませたが、プラットフォームチームがセルフサービス化することで決着した。LLMOpsも同じ道筋を辿るとすれば、今まさにその転換点にあると見てよいだろう。プラットフォームエンジニアリングに携わるTechFeed読者にとっては、LLMワークロードをいつ・どの粒度でプラットフォームに取り込むかの判断軸を持つことが、次の12〜18ヶ月の競争力を左右する可能性がある。

詳細はLLMOps and platform engineering: Who should own the AI pipeline?を参照していただきたい。