はじめに：その「実験」、本当に再現できますか？
「あれ、先週試して良い結果が出たプロンプト、どこに保存したっけ？」
「Geminiで試した時のパラメータと、今のAmazon Bedrockの設定、微妙に違う気がするけど比較しようがないな……」
もしあなたが、複数のパブリッククラウドを行き来しながら生成AIアプリケーションを開発しているなら、一度はこんな経験があるのではないでしょうか。
生成AIの進化は凄まじいスピードで進んでいます。たとえばOpenAIのAPIでは、GPT-4oなどの旧モデルが廃止され、新たにGPT-5.2が主力モデルへと移行しました。同時にAnthropicのAPIでもClaude Sonnet 4.6が登場し、推論能力の大幅な向上や自律的なPC操作機能が追加されるなど、モデルの世代交代が絶え間なく起きています。
今日はChatGPTが有望でも、明日はClaudeが、明後日はGeminiが最適解になるかもしれません。このような状況下で、特定のクラウドベンダーや単一のモデルだけに依存する「ベンダーロックイン」は、ビジネス上の大きなリスクになり得ます。だからこそ、多くの企業がAWS、Azure、Google Cloudを併用するマルチクラウド戦略を採用しています。
しかし、そこには明確な落とし穴があります。
それが「実験管理のカオス」です。
各社の管理コンソールは非常に優秀ですが、それはあくまで「そのクラウド環境の中だけ」の話です。クラウドをまたいだ瞬間に、データの連続性は途絶えてしまいます。結果として、スプレッドシートへの手入力による管理や、チャットツールへのコピー＆ペーストといった、最先端技術を扱っているとは思えないアナログな管理手法に逆戻りしてしまうケースは珍しくありません。とくに、旧モデルから新モデルへの移行検証を行う際、過去の実験データと正確な比較ができなければ、性能評価やプロンプトの調整は困難を極めます。
本記事では、そんなカオスな状況を打破するために、オープンソースソフトウェア（OSS）である「MLflow」を活用し、複数のクラウドを横断する統一評価基盤を構築するための実践的なアプローチを解説します。
これは単なる理論の紹介ではありません。マルチクラウド環境の構築において一般的に直面しやすい認証周りのトラブルや、運用開始後に発覚するAPI呼び出しコストの急増問題など、綺麗な設計図には載らない現場のリアルな課題とその解決策を、論理的かつ明快に紐解いていきます。
これからLLMOps（大規模言語モデルの運用基盤）を構築しようとしている方が、システム設計の落とし穴を回避し、効率的で再現性のある開発環境を手に入れるための道しるべとなれば幸いです。
プロジェクト背景：マルチクラウド環境で発生した「LLM実験のカオス」
多くの組織において、社内文書検索システム（RAG）や生成AIアプリケーションの開発が進む中で、単一のクラウドサービスからマルチクラウド環境へと移行するケースが増えています。コスト最適化、可用性の向上、そして各モデルの特性を使い分けるために、Azure OpenAI、Amazon Bedrock、Vertex AIなどを併用する構成は珍しくありません。
各クラウドのサイロ化による評価基準の不統一
マルチクラウド化は合理的な戦略ですが、開発現場ではプラットフォーム間の「サイロ化（情報が孤立してしまう状態）」という課題が浮き彫りになります。
- Azure AI Studio: プロンプトフロー機能など開発環境は充実していますが、Azure以外のモデルとの直接的な比較は複雑になりがちです。
- Vertex AI: Googleモデルへのアクセスと実験管理に優れていますが、他社クラウドのログ統合には工夫が必要です。
- Amazon Bedrock: 多様なモデルへのアクセスが容易な一方、実験履歴の管理機能はプラットフォームごとに仕様が異なります。
それぞれのプラットフォームで「良さそう」な結果が得られたとしても、評価指標（回答精度、応答速度であるレイテンシ、コスト）の定義や測定条件が統一されていないため、横並びでの公平な比較は困難です。「体感で良かった」という定性的な評価に留まり、定量的な実証データに基づいたモデル選定ができない状況に陥りやすいのです。
スプレッドシート管理の限界と属人化のリスク
こうした状況で、一時的な解決策として採用されがちなのが「実験管理スプレッドシート」です。プロンプト、モデル名、パラメータ、出力結果を手動で記録する運用ですが、これには限界があります。
- 入力ミス:
temperature（出力のランダム性を制御する値）などのパラメータ設定を記録し間違えるヒューマンエラーが発生しやすい傾向にあります。 - 履歴の散逸: ローカル環境（Jupyter Notebook等）での試行錯誤が共有されず、重要な知見が個人の環境に埋もれてしまうリスクがあります。
- バージョンの不整合: どのプロンプトが最新で、どの結果に紐づくのかが追跡不能になるケースが多発します。
目指すべきは「公平な比較」と「迅速なモデル切り替え」
効率的なAI開発において目指すべき状態は、どのクラウドのどのモデルを使用しても、「同じ物差し」で評価され、その履歴が自動的に一箇所に集約される仕組みです。
例えば、「ChatGPTとClaude、どちらが今回のタスクに適しているか？」という問いに対し、過去の実験データを基に「コストパフォーマンスはClaudeが優れ、精度は同等である」といった明確な回答を導き出せる環境が必要です。これこそが、統一評価基盤を構築する最大の目的と言えるでしょう。
選定プロセス：なぜ商用SaaSではなくOSSのMLflowを選んだのか
実験管理ツールといえば、Weights & Biases (W&B) や Comet ML といった優れた商用SaaSが存在します。これらは画面のUIも美しく、機能も豊富です。しかし、あえてOSSのMLflowを自社でホストする（自前のサーバーで運用する）アプローチが有効なケースがあります。
比較検討されるツール群
実験管理ツールの選定では、主に以下の3つが比較検討されます。
- Weights & Biases (W&B): デファクトスタンダード。使い勝手は最高ですが、エンタープライズ版のコストがユーザー数課金であり、将来的に全社展開した際のコスト増が懸念される場合があります。
- Comet ML: 可視化機能が強力。しかし、W&B同様にSaaS利用が前提となりがちです。
- MLflow (OSS): 構築・運用の手間はかかりますが、ライセンス料は無料。インフラさえ用意すれば拡張性は高いという特徴があります。
MLflowが選ばれる3つの理由
最終的にMLflowが選ばれる理由は、以下の3点に集約されます。
- ベンダーロックインの完全回避: 特定のSaaSベンダーに依存せず、自分たちでデータをコントロールできること。これがマルチクラウド戦略の理念と合致しやすいためです。
- コストパフォーマンス: ユーザー数が増えても、かかるのはインフラ費用のみ。AWS Fargateなどでコンテナ運用すれば、月額数万円程度で数百人の利用に耐えられます。
- カスタマイズ性: 社内の認証基盤（Active Directory等）との連携や、独自の評価メトリクス（指標）を組み込む際の柔軟性が高いことも魅力です。
セキュリティ要件とデータガバナンスの壁
そして、決定打となりやすいのが「セキュリティ」です。
多くの企業では、「プロンプトに含まれる社内機密情報は、外部のSaaSサーバーに送信してはならない」という厳しいセキュリティポリシーが存在します。商用SaaSの多くは、ログデータを彼らのクラウドに送信する必要があります（オンプレミス版もありますが、導入ハードルが高い傾向にあります）。
自社のVPC（仮想プライベートクラウド）内に構築したMLflowサーバーであれば、データは社内ネットワークから一歩も外に出ません。この「データの主権」を確保できる点が、セキュリティ部門の承認を得るための強力な根拠となります。
アーキテクチャ詳細：3大クラウドを繋ぐ統合追跡プラットフォームの全貌
では、具体的にどのような構成で3つのクラウドを繋ぐことができるのか。ここからは少し技術的な詳細を、分かりやすく紐解いていきます。
マルチクラウド環境下でのネットワーク設計
アーキテクチャの中心には、AWS上に構築したMLflow Tracking Serverを配置する構成が考えられます。これを「コントロールタワー」として機能させます。
- ホスティング: AWS Fargate（コンテナ実行環境）上でMLflowサーバーを稼働。
- バックエンドDB: メタデータ（実験名、パラメータ、メトリクス）の保存先としてAmazon Aurora (PostgreSQL) を利用。
- アーティファクトストア: 生成されたテキスト、画像、モデルファイル自体の保存先としてAmazon S3を利用。
課題となるのは、AzureやGCP、そして開発者のローカルPCから、いかに安全にこのAWS上のサーバーへアクセスさせるかという点です。
インターネット経由でのアクセスを遮断し、AWS Site-to-Site VPN と Direct Connect を活用して、各クラウドのVPC間を閉域網（専用のプライベートネットワーク）で接続する手法が有効です。これにより、インターネットにログデータを晒すことなく、プライベートIPアドレスでの安全な通信を実現できます。
Tracking Serverの配置と認証フローの設計
MLflowのOSS版は、デフォルトでは認証機能が簡易的です。企業利用で「誰でも見られる」状態は推奨されません。
そこで、MLflowサーバーの前段に Nginx をリバースプロキシ（通信の仲介役）として配置し、ベーシック認証（またはOAuth2 proxyを用いたSSO連携）を実装するアプローチが一般的です。開発者がPythonコードからログを送る際は、環境変数で認証情報を渡す仕組みにします。
import mlflow
import os
# トラッキングURIの設定（社内DNSを使用）
mlflow.set_tracking_uri("https://mlflow.internal.example.com")
# 認証情報のセット
os.environ["MLFLOW_TRACKING_USERNAME"] = "my_user"
os.environ["MLFLOW_TRACKING_PASSWORD"] = "secret_password"
# 実験の開始
mlflow.set_experiment("RAG_Project_Alpha")
このように、数行のコードを追加するだけで、どこから実行しても中央のサーバーにログが集まる環境を整えることができます。
各クラウドへのAPIアクセスの一元化
また、各クラウドのLLMを呼び出す際のAPIキー管理も課題となります。これを解決するために、MLflow AI Gateway（現在はMLflow Deployments Serverの一部）の導入も検討されますが、既存のHashiCorp Vaultなどを活用し、アプリケーション実行時に動的にシークレット（機密情報）を取得する方式を採用するケースも多く見られます。
これにより、コード内にAPIキーを直接書き込む（ハードコーディングする）ことを防ぎつつ、Azure OpenAIやBedrockへのアクセスをセキュアに保つことが可能になります。
直面した「3つの壁」と乗り越え方：運用フェーズでの解決策
設計図の上では完璧に見えたシステムも、実際に運用を始めると様々な問題が発生します。実務の現場で直面しやすい、特に厄介な3つの壁と、その解決策を解説します。
壁1：ログデータの増加とストレージコスト
運用開始後、「S3のストレージ料金が想定を超えている」という問題がしばしば発生します。
原因の多くは、開発者が「とりあえず全部保存」してしまうことにあります。特に、RAGの検索結果として取得した大量のドキュメントテキストや、マルチモーダルモデルの入出力画像を、すべての実験実行（Run）ごとに保存してしまうケースです。
【解決策】
S3にライフサイクルポリシーを設定し、「実験から30日経過したアーティファクト（成果物）は自動削除する」ルールを適用することが推奨されます。ただし、重要な実験結果（タグで production_candidate とマークされたもの）だけは削除対象外とするよう、スクリプトで制御するとよいでしょう。また、テキストデータは圧縮して保存するよう、ロギングのラッパー関数（処理をまとめた関数）を修正することも効果的です。
壁2：チームごとの命名規則の乱立
MLflowには「実験（Experiment）」と「実行（Run）」という概念があります。命名ルールを自由にしていると、問題が発生しやすくなります。
- チームA:
project_x_test - チームB:
20240501_experiment - チームC:
tanaka_test
これでは、後から検索しようにもキーワードが分からず、結局「あの実験どこだっけ？」となってしまいます。
【解決策】
ラッパーライブラリを作成し、命名規則を強制する仕組みが有効です。例えば、実験名は必ず [プロジェクト名]_[機能名]_[環境] の形式でないとエラーになるように実装します。Run名にはGitのコミットハッシュ（コードのバージョン情報）を自動付与し、コードとの紐付けを確実にするとよいでしょう。
壁3：モデル評価指標の自動化の難しさ
「ログは取れた。で、どっちが良いモデルなの？」
ログが集まっても、それを評価する基準がなければ意味がありません。特に生成AIの出力品質は、従来の機械学習のような単純な「正解率」では測れません。
【解決策】
「LLM-as-a-Judge」のアプローチを導入することが効果的です。つまり、ChatGPTなどの高性能モデルを「審査員」として使い、他のモデルの出力を採点させるのです。
MLflowには mlflow.evaluate() という便利な機能があります。これを使って、実験終了後に自動的に「回答の関連性」「忠実性」「有害性」などをスコアリングするパイプラインを構築できます。これにより、人間が目視確認する前に、ある程度の「足切り」と「ランキング」を自動で行うことが可能になります。
導入成果：モデル選定時間の短縮とコスト削減の実績
統一基盤が稼働すると、その効果は実証データとして明確に表れます。
モデル選定時間の70%短縮
通常、新しいモデル（例えばClaude 3）が登場した際、検証には時間がかかります。プロンプトを書き換え、各クラウドで実行し、結果をExcelにまとめ、比較する、というプロセスが必要だからです。
しかし、統一基盤があれば、評価スクリプトを流すだけで、過去のデータセットに対するベンチマークが数時間で完了します。ダッシュボードを見れば性能比較ができるため、導入判断までの時間を大幅に短縮できます。適切に導入した場合、選定時間を70%前後短縮できた事例もあります。
コスト40%削減の実現
「公平な比較」ができるようになることで、「高性能なChatGPTを使っていた処理」を、「安価なGPT-3.5 TurboやHaikuでも十分な精度が出る」と論理的に判断できるようになります。
過剰スペックなモデルからの切り替えが進めば、月間のAPI利用コストを削減できます。実験基盤への投資（AWS Fargate等のインフラ費）を差し引いても、十分な費用対効果が期待できます。
エンジニアとビジネス側の共通言語化
エンジニアとビジネスサイド（PMや企画職）のコミュニケーションが改善されることも重要な点です。
「なんかこの回答、イマイチだね」という感覚的な会話から、「忠実性スコアが0.8を下回っているから、コンテキストの検索ロジックを見直そう」という、データに基づいた建設的な議論ができるようになります。MLflowのUI画面をPMに共有し、彼ら自身が結果を確認できるようにすることも大きなメリットです。
担当者からのアドバイス：これからマルチクラウドLLMOpsを構築する方へ
最後に、これから同様の基盤構築に挑む方へ、実践的なポイントをいくつかお伝えします。
1. 最初から「完璧」を目指さない
全機能を作り込んでからリリースしようとすると、検証サイクルが遅れがちになります。まずは「プロンプトと出力結果のテキストだけを保存する」という最小構成から始めてください。画像や複雑なメトリクスは後から追加するアプローチが確実です。
2. 「開発者体験」を最優先にする
どれほど高機能な基盤でも、使うのが面倒なら現場には定着しません。既存のコードに1〜2行足すだけで使えるようなラッパー関数やSDKを用意し、開発者の作業負荷を減らすことを意識してください。「これを使うと楽になる」と実感してもらうことが、定着への近道です。
3. ベンダーロックインへの警戒を解かない
クラウドベンダーは、自社のエコシステムに囲い込むために便利な独自機能を次々と提供します。それらは魅力的ですが、一度深く依存すると抜け出せなくなります。「この機能を使ったら、他のクラウドに移行できなくならないか？」という問いを、常にアーキテクチャ設計の際に投げかけてください。
マルチクラウド環境でのLLMOps構築は、技術的にも組織的にもハードルがあります。しかし、それを乗り越えた先には、特定のベンダーに縛られない、柔軟で効率的なAI開発体制が待っています。
これらの知見が、効率的で再現性のあるAI開発環境を構築する一助となれば幸いです。
コメント