PoCで終わらせないAI開発｜本番運用に必要なクラウドインフラの考え方

「検証用の環境では快適に動いていたのに、部署全体に公開した途端に応答が遅くなった」「公開後の監視や障害対応をどう準備すればよいのか分からない」というケースは少なくありません。

動くものができていることと、多数の利用者が毎日使い続けられることの間には、性能・安全性・復旧手段・運用体制という明確な差があります。

本記事では、

• PoCと本番運用の違い
• 本番移行に必要なクラウドインフラの基本構成
• 設計前に決めるべき要件
• 公開までの検証手順

を解説します。扱う範囲は、既存モデルやAPIを利用するAIアプリケーションの推論・提供基盤が中心です。モデルの学習基盤や大規模分散学習の設計は対象外とし、必要になる場面に限って補足します。

PoCの目的は、技術的・業務的な仮説を検証することにあります。

• 「社内文書をベクトル検索して生成AIに渡せば、目的の情報にたどり着けるか」
• 「その回答は業務で使える品質か」

を、限られた人数・限られたデータで確かめる工程です。したがってPoCの成功条件は、狙った仮説に対して判断材料が得られたかどうかであり、環境が多少手作業で組まれていても、担当者のノートPCで動いていても問題にはなりません。

一方で本番運用に移ると、評価軸そのものが入れ替わります。

求められるのは「動くこと」ではなく、想定した利用者が、想定した頻度で、想定した品質の応答を、継続的に得られることです。ここには、ピーク時間帯の性能、権限のないデータを見せない安全性、障害が起きたときの復旧手段、そして担当者以外でも運用できる体制までが含まれます。

重要なのは、この「継続利用の条件」がすべてのAIで同じではない点にあります。

PoCと本番で何が変わるのかを、社内文書検索AIを例に項目ごとに整理すると、必要になる作業の量と種類がはっきりします。

以下は、同じアプリケーションを「開発チーム5名での検証」から「全社1,000名への公開」へ移す場合の比較です。

（数値は説明のための仮定であり、一般的な推奨値ではありません）

表の右列は、そのまま本番移行のタスクリストになります。ただし、すべてを同じ強度で満たす必要はありません。社内限定の利用であれば、夜間の計画停止を許容してコストを抑える判断は十分に成立します。

逆に外部向けサービスであれば、同じ表の「障害対応」と「更新方法」の水準を大きく引き上げることになります。必要水準は用途によって決まるという前提を置いたうえで、各項目の目標値を後述の「本番要件」として言語化していきます。

PoCと本番の差が痛みを伴う形で現れるのが、PoCでは測定していなかった条件下での挙動です。検証時は1件ずつ順番に実行していたため気づかなかった問題が、複数の利用者が同時にアクセスした瞬間に顕在化することがあります。

代表的なものは次の4つです。

• 同時リクエストで待ち時間が急増する
• 再起動でデータが消える
• API制限で処理が失敗する
• 担当者以外が復旧できない

これらはいずれも、モデルの精度とは無関係に発生する運用上の問題です。PoCの評価が「回答品質が良かったので公開しよう」で終わってしまうと、公開後に上記の課題へ対応することになってしまいます。

精度検証と並行して、負荷条件下での応答時間、データの永続性、外部サービスの制限、復旧手順の再現性を確認しておくことが、本番移行の前提になります。

実際のAI開発におけるポイントや注意点はこちらの記事で解説しています。

クラウドインフラとは、アプリケーションを動かすために必要な計算・保存・通信の各リソースと、それらを支える仕組みの総称です。

AIアプリケーションの場合も土台は同じで、「どの処理を、どのリソースの上で、どうつないで動かすか」を設計することがインフラ設計の中身になります。

社内文書検索AIを例にすると、本番構成は最低でも次の6つの役割に分解できます。

1. 利用者接点：ブラウザや社内チャットツールからのアクセス経路
2. 認証：誰がアクセスしているかを確認する仕組み（社内IdPとの連携など）
3. アプリAPI：質問を受け取り、検索と生成を組み立てて回答を返す処理
4. 検索・データ保存：文書の原本、検索用のベクトルデータ、利用履歴の保管
5. 推論先：外部LLM API、マネージド推論サービス、または自社運用のGPU
6. 監視・ログ：応答時間やエラー、回答内容を記録し、異常を検知する仕組み

PoCではこれらが1つのスクリプトに同居していることが多く、役割の境界が曖昧なまま動いています。

本番では役割ごとに責務と設定を分けることで、どこで問題が起きているかを特定でき、必要な部分だけを増強・修正できるようになります。以降の章でも、この6要素を共通の枠組みとして参照します。

インフラの検討は、GPUの機種やインスタンスサイズを選ぶところから始めがちですが、先に決めるべきはどの処理をどこで実行し、どのデータをどこに置くかという配置の設計です。計算・保存・通信の3つに分けて整理すると、必要なリソースが自然に導かれます。

このうち計算リソースの選定では、処理の性質ごとに必要なものが異なる点に注意が必要です。APIリクエストの受け付けや検索結果の整形はCPUで十分に処理できますが、自社モデルによる推論はGPUを必要とします。

埋め込み処理は、モデルの規模や処理件数によってCPUでも成立します。すべてを高価なGPUインスタンス上に載せると、GPUが空いている時間帯にも費用が発生し続けることになります。

推論をどこで実行するかによって、構成図の右半分と、自社が管理する範囲が大きく変わります。

主な選択肢は3つあり、それぞれ確認すべき制限が異なります。

ここで押さえておきたいのは、外部APIを使う場合でも、インフラ設計が不要になるわけではないという点です。推論部分を外部に任せられても、アプリAPI、文書の保存、認証と権限管理、監視、そしてAPI障害時の挙動は自社で設計する必要があります。構成図の6要素のうち、外部化できるのは「推論先」の1つだけだと考えます。

クラウドを使う際に必ず確認すべきなのが、どこまでを事業者が管理し、どこからが自社の責任範囲かという切り分けです。主要クラウドは「責任共有モデル」としてこの境界を明示しており、事業者はデータセンターやハードウェアなど「クラウドのセキュリティ」を担い、利用者はその上で動かすOS・アプリケーション・データ・権限設定など「クラウド内のセキュリティ」を担うという整理になっています。

重要なのは、この境界線が利用するサービスの種類によって動くことです。同じクラウド上のサービスでも、仮想マシンとマネージドサービスとでは自社の責任範囲が変わります。

表を見ると、どの方式を選んでもアプリケーションの脆弱性対応と権限設定は自社に残ることが分かります。

構成を検討する前に、満たすべき条件を数値と文章で確定させることが必要です。要件が曖昧なままインスタンスサイズや冗長化構成を選ぶと、過剰な構成で費用が膨らむか、逆に公開後に性能不足が判明するかのどちらかになります。

以下は社内文書検索AIを想定した本番要件の記入例です。数値はすべて説明のための仮定であり、一般的な推奨値ではありません。

この表を埋める作業自体が、関係部署との合意形成のプロセスになります。特に「利用時間」「復旧目標」「予算」は、開発チームだけでは決められません。要件が確定して初めて、「冗長構成は必要か」「GPUを常時起動しておくべきか」といったインフラの判断が可能になります。

クラウドGPUの料金に関しては、こちらの記事で詳しく解説しています。

ここからは、前章で決めた要件を具体的な構成と設定に落とし込む段階です。要件が「p95で15秒以内」「RTO 4時間」といった目標である一方、設計は「どのコンポーネントをどう分け、何を設定し、何を確認するか」という実装の話になります。

以下の5つの観点は、いずれもPoC段階では省略されがちで、かつ本番で問題が起きたときに後から入れるのが難しいものです。各項目は「起こる問題 → 設計方法 → 確認項目」の順に整理しています。

• API・推論処理・データ保存を分ける

• 負荷の原因に合わせて増強・非同期化を選ぶ

• 認証・権限管理とネットワークの公開範囲を設定する

• インフラの状態とAIの回答品質を監視する

• 環境を再現し、更新に失敗したら戻せるようにする

PoCのコードでは、APIの受け付け、ベクトル検索、推論呼び出し、データ保存が1つのプロセス内で完結していることが多くあります。この状態のまま本番に持っていくと、推論部分の負荷対策としてインスタンスを増やしたときに、それぞれのインスタンスが別々のローカルデータを持ってしまい、回答が一貫しなくなります。

まず、アプリAPIをステートレスに保ちます。ステートレスとは、サーバー側がリクエスト間の状態を保持せず、必要な情報はすべてリクエストと外部のデータストアから得られる状態を指します。

この性質があると、どのインスタンスがリクエストを受けても同じ結果を返せるため、台数の増減や再起動が安全に行えます。

具体的には次のように配置します。

• 永続データは外部のマネージドサービスへ
• コンテナの一時領域はキャッシュ用途に限定
• モデルの重みは共有ストレージまたはイメージに含める

ここで注意したいのは、論理的な責務分離と、物理的にサーバーを分けることは別だという点です。小規模なうちは、アプリAPIと検索処理を同じインスタンス上のプロセスとして動かしつつ、データだけを外部に出す構成でも十分に成立します。

「遅い」という症状の原因は複数あり、原因を特定せずにインスタンスを増やしても改善しないことがあります。GPUメモリが不足しているときに台数を増やせば費用だけが増え、外部APIの制限に当たっているときにGPUを増強しても効果はありません。

まず症状から原因の候補を絞り込みます。以下は社内文書検索AIでよく見られる症状と、調査・対処の対応表です。

自社モデルを運用する場合、VRAM容量が同時実行数の上限を直接決める点は押さえておく価値があります。モデルの重みだけでも、パラメータ数×1パラメータあたりのバイト数が必要で、bfloat16なら70Bクラスのモデルで140GB程度のVRAMが目安になります。

実際にはこれに加えて、同時実行数と入力長に比例して増えるKVキャッシュの領域が必要です。モデルサイズによっては複数GPUへの分割が前提になります。

PoCでは検証を優先して、推論サーバーやデータベースをインターネットから直接アクセスできる状態にしたり、APIキーをコードに直接書き込んだりすることがあります。

この状態で公開すると、認証を経ないアクセスや、リポジトリからの認証情報流出につながります。設計方法では、外部に開く入口を1つに絞ることが基本方針です。

• 公開する入口を限定する
• 内部通信も制限する
• 秘密情報は専用の仕組みで管理する
• 権限は最小限から始める

そのうえで、AIアプリケーション特有の注意点として、利用者認証と文書の閲覧権限は別々に確認する必要があります。「社員であることを確認する」ことと、「この社員がこの文書を見てよいか判断する」ことは別の処理です。

社内文書検索AIでは、認証で得た利用者の属性を検索クエリの絞り込み条件に渡し、権限のあるチャンクだけを対象に検索する実装が必要になります。認証だけを実装して認可を省略すると、ログインした全員が全文書の内容を引き出せる状態になります。

CPU使用率とエラー率だけを監視していると、「システムは正常だが、回答内容が明らかにおかしい」という状態を検知できません。逆に回答品質だけを見ていると、遅延の原因が推論なのか検索なのか通信なのかを切り分けられません。

監視対象をインフラの状態とAIとしての品質の2系統に分けて設計します。

切り分けを可能にするために、リクエストIDによる追跡を組み込みます。利用者からのリクエストごとに一意のIDを発行し、認証、検索、推論、応答生成の各段階のログに同じIDを記録します。

一方で、入力全文を無条件にログへ保存することは避けてください。社内文書検索AIの質問文には、人事情報や取引先名などの機密情報が含まれ得ます。対策としては、ログに残す項目をあらかじめ選定し、本文が必要な場合はマスキング処理と保存期間の上限、閲覧権限の制限をセットで設計します。

「担当者の環境では動くが、本番では動かない」「設定変更後に不具合が出たが、変更前の状態が分からない」という状況は、環境とインフラ設定が手作業で構築されている場合に必ず発生します。

AIアプリでは、ライブラリのバージョン差やGPUドライバの違いが挙動に直結するため、影響がより大きくなります。再現性を確保する仕組みは、対象によって役割が分かれます。

IaCは、インフラの構成をコードとして記述し、同じ内容から同じ環境を再作成できるようにする手法です。手順書に沿った手作業と違い、実行結果が一定になり、変更履歴がコードのdiffとして残ります。

そして、RAG構成のAIで見落とされやすいのが、プロンプトと検索用データも変更管理の対象だという点です。回答品質を左右する要素は、コードとモデルだけではありません。

• システムプロンプトの文面
• 取得するチャンク数、チャンクの分割サイズ
• 埋め込みモデルのバージョン
• 検索用データの更新時点

これらの変更履歴が残っていないと、以前に「正しく答えていた質問に答えられなくなった」ときに原因を特定できません。プロンプトはコードと同じリポジトリで管理し、検索用データは再構築した日時とソースの範囲を記録しておきます。

AIをネイティブ開発するにあたって選ぶべきクラウド基盤に関しては、こちらの記事を参考にしてみてください。

ここまでで、本番に必要な要件と設計の観点が揃いました。

この章では、それらを実際に検証して公開するまでの流れを4つの工程に分けて整理します。

1. PoCの構成と本番要件の差分を洗い出す
2. 本番と条件をそろえた検証環境を作る
3. 負荷・障害・権限・回答品質をテストする
4. 利用者を限定して公開し、実測値をもとに広げる

PoCを本番運用へ進めるうえで必要なのは、より高性能なGPUや複雑な構成ではありません。継続利用の条件を数値と文章で決め、それを満たせる構成を実際に検証することです。

最初の一歩として、本記事の本番要件の記入例をもとに自社の値を埋め、PoCの現状構成との差分を洗い出してみてください。差分を「公開前に必要」と「利用拡大後に検討」に分けるだけでも、次に着手すべき作業がはっきりします。

そのうえで自社モデルの運用を検討する場合は、想定するモデルと負荷条件でクラウドGPUの性能を実測し、VRAMと応答時間の見通しを立てることが、確実な本番移行につながります。