LLMOps 全体地図 — 「どんな構成で作られているか」を調べたメモ

GitHub のリファレンス実装・企業エンジニアブログ・ベンダー解説を横断調査して、 LLMOps プラットフォームが一般にどんなステージ／コンポーネントで構成されるかを1枚に束ねたメモ。 このリポジトリには既に LLMOps の構成要素（観測=langfuse_basics、評価=eval_basics、 安全=guardrails_basics、RAG=rag_*、サービング=local_models…）が個別の lecture として揃っている。 このメモはそれらが全体のどこにハマるかを示す地図であり、実装の入口でもある（→ 末尾「学習ロードマップ」）。

調査日: 2026-06-26。各主張は一次資料（企業ブログ・GitHub・公式ドキュメント）で裏取りした URL を末尾「参照ソース」に付す。 確認できた事実と、ソースの主張・位置づけ（業界で定説化しきっていないもの）は「〜とされる」で区別する。

---

0. 一言で（直感）

LLMOps は 「学習を回す MLOps」から「プロンプトとコンテキストを回す運用」へ重心が移ったもの。

• MLOps の主役が 重み（学習） なら、LLMOps の主役は プロンプト・埋め込み・コンテキスト（推論時の入力）。
• モデルは多くの場合 API 越しの外部資産になり、自分で重みを制御できない。だから改善の第一手は「再学習」ではなく プロンプト改善 → RAG コーパス更新 → ガードレール調整、ファインチューニングは最後の手段。
• コストの重心も 学習 → 推論（トークン課金） へ移る。
• 評価は 正解が一意でないので accuracy/F1 が効かず、LLM-as-a-Judge ＋ 人手 ＋ golden dataset の回帰ゲートで代替する。

掴ませたい対比は「絶対精度を上げる ML vs 揺れる出力を観測・評価・ガードで囲って運用する LLM」。後者は生成の周りを固める仕事が増える。

---

1. 全体アーキテクチャ（定番の7ステージ + 2つの sidecar）

複数のリファレンス（TrueFoundry / NVIDIA / lakeFS / Caylent(AWS) / Red Hat 等）で共通して現れる形は、 縦に5層（データ→開発→評価→サービング→観測）を積み、横に「ガードレール」と「監視」を全層貫通の帯（sidecar）として置き、本番ログをフィードバックループでデータ層へ戻すというもの。

flowchart TD
    subgraph DATA["① データ層 Data / Knowledge"]
        PROMPT["プロンプトカタログ<br/>バージョン管理"]
        GOLD["golden dataset<br/>評価の正解集合"]
        VEC["ベクトルストア<br/>chunk + embed"]
    end

    subgraph DEV["② 開発層 Development"]
        PE["プロンプトエンジニアリング"]
        RAG["RAG パイプライン構築"]
        FT["ファインチューニング / PEFT"]
    end

    subgraph EVAL["③ 評価層 Evaluation"]
        OFF["オフライン eval<br/>BLEU/ROUGE/人手"]
        JUDGE["LLM-as-a-Judge"]
        GATE["回帰ゲート<br/>閾値割れで merge block"]
    end

    subgraph SERVE["④ サービング層 Serving"]
        GW["LLM ゲートウェイ<br/>認証/ルーティング/semantic cache"]
        INF["推論サーバ<br/>GPU / streaming"]
    end

    subgraph OBS["⑤ 観測層 Observability"]
        TRACE["トレーシング"]
        COST["トークンコスト監視"]
        QUAL["品質メトリクス<br/>幻覚率/毒性/refusal"]
    end

    GUARD["⑥ ガードレール sidecar<br/>入力フィルタ / PII / injection / 出力フィルタ"]
    LOOP["⑦ フィードバックループ<br/>本番ログ + User Feedback"]

    DATA --> DEV
    DEV -->|変更を push| EVAL
    EVAL -->|pass| SERVE
    VEC -.->|意味検索で文脈注入| SERVE
    PROMPT -.->|配信| SERVE
    SERVE --> OBS
    GUARD -.->|全リクエストを貫通| SERVE
    OBS --> LOOP
    LOOP -->|dataset / golden 更新| DATA
    LOOP -->|再評価 CT/CE| DEV

各ステージが何をするか・なぜ LLM 特有か

#	ステージ	何をするか	なぜ LLM 特有 / 強化されるか
①	データ層	プロンプトカタログ（テンプレのバージョン管理・比較）、golden dataset（回帰の正解集合）、ベクトルストア（chunk→embed して保存）	特徴量ストアの代わりに埋め込み＋ベクトル検索が中核。プロンプトという自然言語の資産をバージョン管理する必要がある（NVIDIA「embedding management が feature store を置き換える」）
②	開発層	ベースモデル選定、プロンプトエンジニアリング、RAG パイプライン構築、PEFT/LoRA	ゼロ学習せず基盤モデルからの転移が前提。「特徴量エンジニアリングをプロンプトエンジニアリングが置き換える」。多段チェーン/エージェントは従来 ML に対応物なし
③	評価層	golden dataset に対するオフライン eval、LLM-as-a-Judge、A/B、回帰ゲート（閾値割れで merge をブロックする CI ステップ）	出力が非決定的で正解が一意でないため accuracy/AUC が効かず、関連性・幻覚率・有害性を質的・人間中心に測る
④	サービング層	推論サーバ（量子化・streaming・オートスケール）、LLM ゲートウェイ（統一 API・認証・レート制限・プロバイダ間フェイルオーバー・版間 A/B ルーティング・トークン粒度コスト計測）、semantic cache	マルチプロバイダを束ねトークン課金・フォールバック・意味キャッシュを扱う「API 層オーケストレータ」が新たに要る
⑤	観測層	トレーシング（多段チェーンの各ステップ入出力）、トークンコスト、レイテンシ、品質メトリクス（幻覚率・毒性・関連性・refusal・ドリフト）	監視対象が accuracy/drift から関連性・毒性・幻覚率＋トークンコストへシフト。非決定生成の品質追跡が要る
⑥	ガードレール (sidecar)	入力フィルタ（prompt injection / jailbreak 検知）、出力フィルタ（漏洩・有害遮断）、PII 検出/マスキング、実行サンドボックス	自然言語入力そのものが攻撃面になる prompt injection / jailbreak は LLM 固有の脅威クラス。多層防御（defense-in-depth）が前提
⑦	フィードバックループ	本番ログ・低評価応答・失敗例を収集 → dataset/golden へ還流 → 再評価 → プロンプト改善・再 fine-tune（RLHF / binary feedback）	重みだけでなく会話・プロンプトをチューニング対象に含む。人間のフィードバックが性能評価に必須（lakeFS「Human Feedback: Required」）

⑥ガードレールと⑤観測は sidecar（全層を貫く帯） として描くのがポイント。TrueFoundry は明示的に「Monitoring と Guardrail の2つの sidecar が複数レイヤをまたぐ」と記述している。

データフローを言葉で追う（CI/CD・CT を含む）

1. 生データがデータ層でクリーニング→チャンク化→埋め込み化されベクトルストアへ。プロンプトはカタログにバージョン管理される。
2. 開発層がベースモデルを選び、プロンプト設計・RAG 構築・PEFT を行う。RAG は実行時にベクトルストアへ意味検索し、取得文脈をプロンプトへ注入する。
3. プロンプト/モデル版を変更すると CI/CD が起動し、評価層が golden dataset を流して LLM-as-a-Judge で採点。回帰ゲートが閾値割れなら merge をブロック、合格なら次へ。
4. 合格成果物がサービング層へ。リクエストはゲートウェイ（認証・レート制限・ルーティング・semantic cache）→推論サーバへ。RAG 検索とプロンプトカタログを参照して応答を生成。
5. すべての入出力はガードレール sidecar（入力フィルタ→生成→出力フィルタ/PII マスク）を通り、観測層 sidecarがトレース・トークンコスト・レイテンシ・品質メトリクスを記録。
6. 本番ログとユーザーフィードバックはフィードバックループで収集され、dataset/golden を更新→再評価（CT=continuous training / CE=continuous evaluation）→プロンプト改善・再 fine-tune に戻る。これが継続的改善の閉ループ。

---

2. このリポジトリの lecture が、地図のどこに当たるか

この ai-engineering-study には LLMOps の構成要素が既に個別 lecture として揃っている。 各 lecture が上の7ステージのどこを担うかを対応させると、「全体像の中で自分が何を学んできたか」が見える。

地図のステージ	対応する既存 lecture	補足
① データ層（RAG/ベクトル）	rag_basics / rag_vector_basics / rag_graph_basics	素手実装 → LangChain+Chroma → LlamaIndex グラフ RAG
① データ層（コンテキスト管理）	context_basics	trim/要約圧縮/スクラッチパッド/長期メモリ（write・select・compress・isolate）
② 開発層（オーケストレーション）	langgraph_basics / multi_agent / langchain_v1 / functional_api / dspy_basics / claude_agent_sdk	チェーン/グラフ/エージェント/宣言的最適化
③ 評価層	eval_basics	決定論チェッカー / golden dataset / LLM-as-a-Judge / judge バイアス実測 / 回帰ゲート
④ サービング層	local_models	Ollama で「モデルは base_url 1つで差し替え可能な部品」を学ぶ。ゲートウェイ（LiteLLM 等）は未カバー → 拡張候補
⑤ 観測層	langfuse_basics	trace/span/generation/observation の階層、コスト集計、LangChain CallbackHandler
⑥ ガードレール	guardrails_basics / sandbox_basics	Middleware による入出力ガード・権限ゲート・lethal trifecta／コード実行隔離
⑦ フィードバックループ	（横断。eval の golden 更新 + langfuse の score がループの素材）	専用 lecture は無い → CI で回す形が拡張候補

抜けているピース（＝今後の実装候補）: ④の LLM ゲートウェイ/ルーティング（LiteLLM・Portkey）、③〜⑦を束ねる CI 回帰ゲートの実パイプライン化、②の ファインチューニング/PEFT（Axolotl・LLaMA-Factory・Unsloth）。

---

3. OSS ツールマップ（ステージ ↔ 代表ツール 早見表）

「構成」を実在ツールで埋めるとこうなる。OSS 中心、自己ホスト可否と GitHub を併記。スター数は出典で確認できたものだけ記載。

ステージ	代表ツール（OSS 中心）
アプリ構築・オーケストレーション	LangChain / LangGraph、LlamaIndex、Haystack、DSPy
検索基盤（RAG / ベクトル DB）	Chroma、Qdrant、Weaviate、Milvus、pgvector
プロンプト / 実験管理	Langfuse Prompts、PromptLayer、Agenta、MLflow
ゲートウェイ / ルーティング	LiteLLM、Portkey、Kong AI Gateway、OpenRouter
推論サービング	vLLM、TGI、Ollama、BentoML/OpenLLM、Ray Serve、LMDeploy
ガードレール（入出力安全）	Guardrails AI、NeMo Guardrails、Llama Guard、Rebuff、LLM Guard
観測 / トレーシング	Langfuse、LangSmith、Arize Phoenix、Helicone、OpenLLMetry、Lunary
評価（オフライン/オンライン）	Ragas、DeepEval、OpenAI Evals、promptfoo、TruLens、Phoenix Evals
ファインチューニング	Axolotl、LLaMA-Factory、Unsloth、PEFT

カテゴリ別のポイント（選定時に効く相対関係）

• 観測: Langfuse（MIT・自己ホスト可・プロンプト/eval も統合）が「全部入りの OSS」。LangSmith は LangChain 公式 SaaS で連携が自動だが基本マネージド。OpenLLMetry は OpenTelemetry 計装なので span の移植性が最も高い（Langfuse/Phoenix/LangSmith が取り込める）とされる。
• ゲートウェイ: LiteLLM が 100+ プロバイダを OpenAI 互換 API に統一＋フォールバック＋予算制御（OSS・無料 self-host）。Portkey はガードレール/PII 秘匿込み。OpenRouter はマネージド。
• サービング: vLLM（PagedAttention/連続バッチング）が高並列で TGI 比の大幅高スループットとされる。Ollama は手元/単一リクエスト向けで同時並行に弱いとされる。
• ベクトル DB: Chroma（軽量・プロトタイプ）↔ Qdrant（Rust・高スループット・強フィルタ）↔ Milvus（K8s ネイティブ・大規模、運用負荷高めとされる）↔ pgvector（既存 Postgres に同居）。
• 評価: Ragas（RAG 特化・参照不要スコアラ）、DeepEval（pytest 風ユニットテスト型・13,000+ stars）、promptfoo（ローカルファースト CLI＋レッドチーミング）。
• ファインチューニング: Axolotl（設定駆動・柔軟）、LLaMA-Factory（Web UI でノーコード寄り）、Unsloth（単一 GPU で高速・省メモリ）。

リポジトリ移動の注記（鮮度）: NeMo Guardrails は NVIDIA-NeMo/Guardrails へ、Axolotl は axolotl-ai-cloud/axolotl へ移動済み（旧 URL はリダイレクト）。

---

4. 実プロダクトの構成事例（誰が・何のために・どう組んだか）

GitHub・企業エンジニアブログで公開された実在の本番構成。各社の自社公表値は「自社ブログ記載」と明示する。

4-1. Uber — GenAI Gateway（社内 LLM 統一ゲートウェイ）

• 目的: 社内 60+ ユースケースに対し、外部（OpenAI / Vertex AI）と自社ホスト LLM への統一アクセス層を提供。チームごとの個別実装乱立を解消。
• 構成: Go 製サービス、OpenAI API 互換インターフェース（LangChain/LlamaIndex 等をそのまま使える）、PII リダクタ（外部送信前に匿名プレースホルダ化→応答で復元）、認証・認可・監査ログ、キャッシュ、コスト/安全ガードレール、メトリクス。
• 設計判断: 独自 API を作らず OpenAI 互換に揃えた（OSS の進化に取り残されないため）。Java/Go クライアントを明示サポート。利用前に標準セキュリティレビュー必須。
• ハマりどころ（記事明記）: PII リダクト/復元がレイテンシ増＋文脈喪失で品質劣化。同一エンティティでも位置で異なる番号が振られる。
• 規模: 約30チーム / 月間1,600万クエリ / ピーク25 QPS（2024時点・自社ブログ）。

4-2. LinkedIn — GenAI アプリケーション・テックスタック

• 目的: 10億人規模プロダクト（Hiring Assistant 等）向けに、高速実験と安定運用を両立する統一 GenAI 基盤。
• 構成: Python + LangChain（薄くラップして社内ロギング/計装/ストレージに橋渡し）、Prompt Source of Truth（Jinja テンプレ＋バージョン管理）、Skills（中央レジストリにツール登録＝Skill Inversion）、会話メモリ（メッセージング基盤を流用）、全モデルを OpenAI Chat Completions API で公開（Azure OpenAI も fine-tuned Llama も透過切替）、Inference Gateway（Trust/Responsible AI チェック・クォータ集中処理）。
• 設計判断: Java→Python を段階移行（GenAI OSS が Python 中心のため）。レガシー rest.li を後付けせず gRPC へ寄せる。
• 教訓: 万能解は無く短期速度と長期抽象のバランス／メモリが personalization の核／モデル抽象化で実験コスト減。

4-3.（日本①）メルカリ — LLM Key Server

• 目的: 社内 LLM API 利用で恒久キーを廃し、内部アカウント由来の短命クレデンシャルで安全＋便利にアクセス。
• 構成: LiteLLM（統一 API でマルチプロバイダ・ロックイン回避）、OIDC ID トークン（Google）で本人確認→署名検証→短命キー発行→自動更新。ローカル CLI / GitHub Actions（OIDC）/ Google Apps Script に対応。
• 設計判断/教訓: 「過度に煩雑なセキュリティはかえって迂回を促す」＝セキュリティと利便性の両立を明言。Apps Script では裏の GCP プロジェクトが組織フォルダ配下かまで検証。

4-4.（日本②）LINEヤフー（LY Corporation）

• 目的: 全社生産性（社内 QA）＋業務適用（EC 商品属性抽出）。
• 構成/事例: SeekAI（2024/7 全社導入・OpenAI API 上にRAGで社内ドキュメント DB を参照、年70〜80万時間削減=社内推計）、LINE Shopping TW（LLM で2,000万点超の商品属性抽出・プロンプト設計）。プライベートクラウド「Flava」、2026前半に20+エージェント展開予定、自社日本語 LLM（36億パラメータ公開）。
• 注: SeekAI の削減数値は社内推計（OpenAI 記事経由）、内部アーキ詳細（ベクタ DB 等）は一次資料で未確認。

4-5. DoorDash — RAG ベースの Dasher サポート自動化

• 目的: 配達員サポートを LLM 自動化。1日数千件を捌きつつ誤回答・コンプラ違反を抑制。
• 構成: 社内ナレッジのRAG + LLM Guardrail（応答をリアルタイム検証）+ LLM Judge（品質モニタ）。中央集約の埋め込み管理で「chatbot-as-a-service」化。
• 設計判断: 生成と検証（guardrail）・評価（judge）を分離した多段品質管理。
• 成果（自社ブログ）: ハルシネーション90%減、コンプラ問題99%減。

4-6. GitHub の参照実装・テンプレート

• Azure-Samples/azure-search-openai-demo — Azure OpenAI + Azure AI Search の RAG リファレンス（認証・マルチモーダル・履歴永続化・監視込み。「本番にはさらに硬化が必要なサンプル」と明言）。
• aws-samples/amazon-bedrock-rag ほか — Bedrock Knowledge Bases / OpenSearch Serverless / Bedrock Agents で RAG パイプラインをマネージドで隠蔽。
• コミュニティ: ray-project/llm-applications（本番 RAG を Ray でスケール）、infiniflow/ragflow（企業スケール OSS RAG エンジン）、validatedpatterns/rag-llm-gitops（監視込みで RAG を GitOps デプロイ）、Shubhamsaboo/awesome-llm-apps（100+ サンプル集）。

事例から見えた共通パターン

1. 「ゲートウェイ/プロキシ層」で LLM を抽象化 — Uber・LinkedIn・メルカリ いずれもアプリと多数モデルの間に統一アクセス層を挟み、認証・コスト・監査・ガードレールを一点集約。
2. OpenAI 互換 API がデファクト — 社内全モデルを OpenAI Chat Completions 互換で公開し、エコシステム流用とモデル切替を容易に。
3. 生成と「検証・評価」を分離 — DoorDash の Guardrail/Judge、LinkedIn の Trust チェックなど、生成パスとは別に品質・安全の検証段を持つ。
4. セキュリティ＝短命クレデンシャル＋PII 制御、かつ「便利さを損なうと迂回される」運用観点。
5. RAG が業務適用の主力 — 社内 QA・サポート自動化・EC 属性抽出。クラウド各社テンプレも RAG 中心。
6. 言語は Python へ収斂、ただし既存資産と折衷 — LinkedIn は Java→Python 段階移行、Uber はインフラ言語を残しゲートウェイで吸収。
7. マネージド化 vs 自前の二極化 — クラウドテンプレは RAG をマネージドで隠蔽、大手社内基盤は自前で集約層を作る。

---

5. MLOps vs LLMOps（何が変わるか）

観点	MLOps（従来）	LLMOps
中心成果物	学習データ・特徴量・モデル重み	プロンプト・埋め込み・ベクトルインデックス・コンテキスト
モデルの出自	自前データでスクラッチ学習が多い	基盤モデルを起点、API 越しの外部資産（重み/学習データを自分で制御できない）
開発ループ	収集→学習→評価→デプロイ→再学習（低速）	プロンプト/RAG/ガードレールを差し替える高速ループ（フル再学習を伴わない）
主要コスト	学習が支配的、推論は安価	推論が支配的（トークン課金＋ベクトル演算＋ツール呼び出し）
評価	固定データの決定的指標（accuracy/F1）	正解が一意でない。LLM-as-a-Judge ＋人手＋groundedness
再現性	同一条件で再現可能	temperature 等で非決定、同一入力でも揺れる
知識更新	再学習でモデルに取り込む	RAG で推論時に注入し再学習を回避
安全性	限定的	hallucination/prompt injection/PII の監視・フィルタ層が必須
レイテンシ/配信	バッチ/同期中心	ストリーミング・体感レイテンシ最適化が UX 上必須
改善の第一手	フル再学習	プロンプト改善 → RAG 更新 → ガードレール調整、FT は最後
ドリフト	入力データドリフト→再学習	埋め込みドリフト・インデックス陳腐化・コーパス鮮度・品質劣化（手法は確立途上とされる）

LLMOps 固有要素が「なぜ新しく要るか」

• プロンプト管理/バージョニング: 小さな変更が出力を大きく変えるのに元来 versioning が無い → コードと並ぶ一級成果物として registry で管理。
• 評価の難しさ: 唯一解が無くオープンエンド → 自動指標＋LLM-as-a-Judge＋人手＋golden dataset。judge は人間選好に近い反面、頑健性に限界との学術指摘もある（arXiv 2506.09443）。
• 非決定性: 「同一条件＝同一結果」が崩れ、単一パスでなく複数回・統計的評価が前提。
• コスト/トークン経済: 重心が学習→推論。多段エージェントは1リクエストで多数の LLM 呼び出し→コスト膨張。予算アラートが運用に組み込まれる。
• RAG/コンテキスト管理: 再学習せず外部知識を注入する中核。ベクトル DB・検索パイプラインを成果物として維持。MLOps に対応物なし。
• ガードレール: 自由生成ゆえの新しい攻撃面/失敗面。入力（injection 検知）と出力（hallucination/有害）の両監視＋PII 匿名化。
• 人間フィードバック必須: 会話・プロンプトもチューニング対象。RLHF/binary feedback を継続ループに統合。

派生概念

• RAGOps — RAG パイプライン（検索・ベクトル DB・コーパス鮮度・groundedness）の運用に特化した新興規律。MLOps→LLMOps の延長線上とされる。
• AgentOps — 自律マルチステップ・ツール使用エージェントの運用/監視/最適化に特化。急速発展中とされる。
• GenAIOps — 生成 AI 運用全般の包括語として使われることがある（用語整理は途上）。

NVIDIA は「LLMOps は MLOps の全面置換ではなく、基盤モデル対話・RAG・プロンプト駆動ロジックの領域で既存 MLOps を適応・拡張したもの」とする。一方 TrueFoundry/lakeFS はプロンプト管理・ゲートウェイ・幻覚監視を「従来 ML に無い新層」と位置づける。「拡張」か「新規」かの強調はソースで差がある（共通して挙がるコンポーネント群は上記の通り）。

---

6. 用語集（混同しやすい同系語）

用語	何を指すか	隣の語との違い
LLMOps	LLM アプリの開発〜本番運用のライフサイクル全体	MLOps の上位/隣接。プロンプト・RAG・eval・ゲートウェイを含む
MLOps	機械学習モデルの学習〜運用	学習中心。LLMOps はここから推論/プロンプト中心へ重心移動
RAGOps	RAG パイプライン運用に特化	LLMOps の部分集合（検索・ベクトル DB・groundedness）
AgentOps	エージェント（多段・ツール使用）運用に特化	LLMOps の部分集合（長時間・自律実行の監視）
LLM ゲートウェイ	アプリと多数モデルの間の統一アクセス層	プロキシ。認証/ルーティング/コスト/キャッシュ/ガードレールを集約（例: LiteLLM）
golden dataset	評価の「正解集合」。回帰の基準	学習データではなく評価用。回帰ゲートで流す
LLM-as-a-Judge	別の LLM が出力を採点する評価手法	人手評価の代替/補完。バイアス（position/verbosity）に注意
回帰ゲート	評価が閾値割れなら merge をブロックする CI ステップ	「テストの red で止める」の LLM 版（→ eval_basics）
ガードレール	入出力を検査して危険を遮断する層	確率の防御（LLM 分類）＋構造の防御（決定論フィルタ）の多層（→ guardrails_basics）
semantic cache	意味的に等価なリクエストへキャッシュ応答	文字列一致でなく埋め込み近傍でヒット判定。トークンコスト削減
PEFT / LoRA	パラメータ効率的ファインチューニング	フル FT より少データ・低コスト。FT は「最後の手段」
CT / CE	Continuous Training / Continuous Evaluation	フィードバックループで dataset 更新→再学習/再評価を自動化

---

7. 学習ロードマップ（このメモを起点に実装して動かす）

「全体地図」を描いたので、次は抜けているピースを手で組んで動かすのが自然な続き。優先度順の拡張アイデア:

1. LLM ゲートウェイを建てる（④の穴埋め・最優先） — LiteLLM をローカルに立て、OpenAI 互換 API で複数プロバイダ（OpenAI / Ollama）を1エンドポイントに統一し、フォールバック・予算上限・トークンコスト計測を体験する。local_models の「base_url 差し替え」をプロキシ層に昇格させる位置づけ。事例の Uber/メルカリと同じ構図を最小再現。
2. 回帰ゲートを CI に組む（③⑦の接続） — eval_basics の golden dataset + LLM-as-a-Judge を GitHub Actions のブロッキングステップにし、プロンプトを変えると CI が走って閾値割れで merge をブロックする閉ループを作る。
3. 観測 → フィードバックの一周 — langfuse_basics の score を本番ログに見立て、低評価トレースを golden dataset に追記 → 再評価、という⑦の閉ループを最小実装。
4. ガードレール sidecar をゲートウェイに差す — guardrails_basics の入出力ガードを①のゲートウェイ前段に置き、PII マスク（Presidio 等）を通す。Uber の PII リダクタの縮小版。
5. RAG を「マネージド隠蔽」と「自前」で対比 — rag_* の自前パイプラインと、クラウドテンプレ（Bedrock Knowledge Bases / Azure AI Search）の二極を読み比べ、どこまで隠蔽すべきかを判断する目を作る。
6. エージェント観測（AgentOps） — multi_agent / langgraph_basics のグラフ実行を langfuse でトレースし、多段チェーンのコスト/レイテンシ内訳を可視化。

実装フォルダを作るときは、このリポジトリの流儀（ex01_*.py → ex0N_*.py の段階積み上げ、.env.op + op run、uv sync）に合わせる。

---

8. 参照ソース

全体アーキテクチャ

• LLMOps Architecture: A Detailed Explanation — TrueFoundry
• What is LLMOps? Key Components & Differences to MLOps — lakeFS
• Building an LLMOps Platform on AWS — Caylent
• Mastering LLM Techniques: LLMOps — NVIDIA
• What is LLMOps — Red Hat
• Inference routing — BentoML LLM Inference Handbook
• High-Performance LLM Serving on GKE: Inference Gateway — Google Cloud
• LLM-as-a-judge: a complete guide — Evidently AI
• What is LLM evaluation? — Braintrust
• Testing LLM Applications — Langfuse
• How Good Are the LLM Guardrails on the Market? — Palo Alto Unit 42
• LLM Prompt Injection Prevention Cheat Sheet — OWASP
• Presidio PII Masking with LiteLLM — LiteLLM Docs
• Monitoring LLM behavior: Drift, retries, refusal patterns — VentureBeat

MLOps vs LLMOps

• MLOps vs LLMOps — ZenML
• What is LLMOps? — MLflow
• What Is AI LLMOps? — Datadog
• LLMOps vs MLOps: the Governance Gap — Atlan
• LLMs Cannot Reliably Judge (Yet?) — arXiv 2506.09443
• RagOps: The Next Frontier in AI Operations — LinkedIn

OSS ツール（公式 GitHub）

• Langfuse https://github.com/langfuse/langfuse ／ Arize Phoenix https://github.com/Arize-ai/phoenix ／ OpenLLMetry https://github.com/traceloop/openllmetry
• LiteLLM https://github.com/BerriAI/litellm ／ Portkey https://github.com/Portkey-AI/gateway
• vLLM https://github.com/vllm-project/vllm ／ Ollama https://github.com/ollama/ollama ／ BentoML https://github.com/bentoml/BentoML
• Ragas https://github.com/explodinggradients/ragas ／ DeepEval https://github.com/confident-ai/deepeval ／ promptfoo https://github.com/promptfoo/promptfoo
• Guardrails AI https://github.com/guardrails-ai/guardrails ／ NeMo Guardrails https://github.com/NVIDIA-NeMo/Guardrails ／ Llama Guard(PurpleLlama) https://github.com/meta-llama/PurpleLlama
• Chroma https://github.com/chroma-core/chroma ／ Qdrant https://github.com/qdrant/qdrant ／ pgvector https://github.com/pgvector/pgvector
• Axolotl https://github.com/axolotl-ai-cloud/axolotl ／ LLaMA-Factory https://github.com/hiyouga/LLaMA-Factory ／ Unsloth https://github.com/unslothai/unsloth

実プロダクト事例

• Uber GenAI Gateway ／ InfoQ 解説
• LinkedIn GenAI Tech Stack
• メルカリ LLM Key Server
• LY Corporation × OpenAI ／ LINE Shopping TW 属性抽出
• DoorDash Dasher Support 自動化
• Azure-Samples/azure-search-openai-demo ／ aws-samples/amazon-bedrock-rag ／ ray-project/llm-applications ／ infiniflow/ragflow

---

作成: 2026-06-26 ／ 最終更新: 2026-06-26