AI PoCを既存システムへ本番実装する進め方

「PoCのデモは動いた。あとは本番に組み込むだけ」と思っていたら、着手して1ヶ月経っても終わらない——AI機能の開発でよく聞く状況です。PoCコードをそのまま本番の画面に持っていこうとして、既存の認証やエラー処理と噛み合わず作業が膠着する。この記事では、PoCが本番化しない理由を踏まえた上で、実際に既存システムへ組み込むときに何を追加で作る必要があるかを具体的に整理します。

PoCコードは本番の設計図ではない

PoCのコードは「AIが期待通りの出力を返すか」を確かめるためのものです。Pythonスクリプト1本、あるいはJupyter Notebookで完結していることも多く、次の要素がほぼ確実に欠けています。

• 既存システムの認証・権限モデルとの接続
• 異常系（APIタイムアウト・レート制限・不正な入力）の処理
• 同時実行時の挙動（複数ユーザーが同時にAI機能を使ったら何が起きるか）
• ログ・監視・アラート
• コストの上限管理

PoCコードを「動いているから」という理由でそのまま本番の既存コントローラーに移植すると、これらが後から次々に発覚し、結果的にPoCの何倍もの工数がかかります。PoCは「AIが使えるかの検証」、本番実装は「既存システムの一部として安全に動かす設計」——別の仕事だと最初から切り分けておくことが重要です。

本番実装で追加が必要になること

1. 既存機能との統合

AI機能を単体のAPIエンドポイントとして作るのは簡単ですが、既存の画面のどこに置くか、既存のデータモデルとどう紐づけるかが本番実装の大半を占めます。例えば「問い合わせ内容をAIが要約する」機能なら、既存の問い合わせ一覧画面のどこに表示するか、要約結果をDBに保存するのかその場で生成するのか、既存のステータス管理とどう連動させるかを設計する必要があります。ここは既存コードの理解が要るため、PoCを作った人（社内エンジニアや別ベンダー）と本番実装を担当するチームが違う場合、引き継ぎに時間がかかりがちです。

2. 認証・権限

AI機能が扱うデータに閲覧権限があるか、既存の権限モデル（ロールベース、テナント分離など）をAI呼び出しの前に必ず通す必要があります。PoCでは「管理者だけが触る前提」で権限チェックを省略していることが多く、一般ユーザー向けにリリースする段階で権限漏れが見つかるケースがあります。特にマルチテナントのSaaSでは、AIへのプロンプトに他テナントのデータが混入しないかの確認が必須です。

3. エラー処理とフォールバック

外部AI APIは必ず失敗します。タイムアウト、レート制限、一時的な障害、想定外のレスポンス形式——これらが起きたときにユーザーにどう見せるか、既存の処理をどう続行させるかを設計します。目安として最低限用意すべきものは次の通りです。

• タイムアウト値の設定：既存のHTTPリクエストタイムアウトとAI API呼び出しのタイムアウトは分けて設定する（AI APIは数秒〜数十秒かかることがあるため）
• リトライとバックオフ：一時的な失敗は自動リトライ、恒久的な失敗（不正なプロンプト等）は即座にエラー表示
• フォールバック挙動：AIが使えないときに機能自体を止めるのか、AIなしの従来動作にフォールバックするのかを事前に決める。既存機能に後付けする場合は「AIがなくても既存の動作は維持される」設計が基本

4. レート制限とコスト管理

本番トラフィックでAI APIを呼び続けると、想定外のコストが発生します。ユーザー単位・テナント単位でのレート制限（1日あたりの呼び出し回数上限など）を実装しないと、一部の利用者の使い方でAPI費用が青天井になるリスクがあります。コスト管理の具体的な削減策は既存AI機能のLLMコストを抑える改善ポイントで詳しく解説していますが、本番実装の設計段階で次の3点は最低限決めておく必要があります。

• ユーザー/テナントごとの呼び出し上限（例: 1日100回まで）
• 月次のAPI費用アラート（想定額の何%で通知するか）
• 上限到達時のUI挙動（エラー表示か、翌日まで待つ案内か）

5. 監視と評価

AI機能はデプロイして終わりではなく、「出力の質が劣化していないか」を継続的に見る仕組みが要ります。エラー率・レイテンシといった通常のシステム監視に加え、AI特有の監視項目があります。

• 出力ログの保存：入力と出力のペアを一定期間保存し、問題発生時に再現・検証できるようにする（個人情報を含む場合はマスキングや保存期間の設計が必要）
• 異常検知：出力が極端に短い/長い、特定のエラーパターンが急増しているなど、精度劣化の兆候を検知する仕組み
• 評価の仕組み：AIの出力が「正しいか」を継続的に測る方法。詳細はAI出力の品質評価の進め方を参照してください。人手レビューのサンプリングだけでも、何もしないよりはるかに安全です

6. ガードレール

ユーザーの入力がそのままAIへのプロンプトに渡る設計では、意図しない指示（プロンプトインジェクション）や不適切な出力のリスクがあります。入力のサニタイズ、出力のフィルタリング（NGワード・フォーマット検証）、AIに渡してよい情報の範囲の制限は、本番リリース前に必ず組み込む項目です。特に既存システムの内部データ（他ユーザーの情報、内部APIキーなど）がプロンプトに混入しない設計になっているかは、PoCでは見落とされがちな点です。

PoCコードをそのまま使わない

PoCで書かれたプロンプトやAPI呼び出しのロジックは、本番実装のベースにはなりますが、そのまま流用すると次の問題が起きます。

• プロンプトがテストケースに過剰最適化されていて、本番の多様な入力でぶれる
• エラー処理が「動くことを確認する」ためのtry-exceptで、ユーザー向けの適切なメッセージになっていない
• 既存のコーディング規約・アーキテクチャに沿っていない（PoCは規約を無視して書かれることが多い）

本番実装では、PoCを「仕様のたたき台」として扱い、既存システムのコーディング規約・レイヤー構成に沿って書き直すのが基本です。ここを妥協してPoCコードをそのままマージすると、後から保守できないコードが本番に残り続けます。

段階リリースで進める

本番実装が終わったら、全ユーザーに一斉公開するのではなく段階的に展開するのが安全です。

1. 社内・特定ユーザーへの限定公開（フィーチャーフラグで一部のテナント/ユーザーIDだけに表示）
2. 一部トラフィックへの展開（全ユーザーの5〜10%など）でコスト・エラー率・出力品質を実測
3. 全体公開、その後も監視を継続し、異常があれば即座にフラグを切って従来動作に戻せる状態を維持

この進め方であれば、想定外のコスト高騰や精度問題が起きても、影響範囲を限定した状態で対処できます。フィーチャーフラグの仕組みが既存システムにない場合は、本番実装の一部としてここも用意する必要があります。

外注する場合の進め方

社内でPoCまで作ったが本番実装は外部に依頼する、というケースも多くあります。この場合、発注者側で準備しておくと進行がスムーズになる点は次の通りです。

• PoCのコードと、うまくいかなかったケースの記録を渡す（成功例だけでなく失敗例の共有が重要）
• 既存システムのどこに組み込みたいかの要望を明確にする（画面イメージや既存機能との関係）
• コストの許容ラインを事前に伝える（月間予算の上限がないと、精度優先で高コストな設計になりがち）
• 本番化の判断ゲートを一緒に確認する（PoCが本番化しない理由にある精度・コスト・運用・統合の4ゲート）

外部チームに丸投げすると、既存システムの理解不足からズレた実装になりやすいため、既存コードの構造やビジネスルールを伝える初期の擦り合わせ期間を持つことをお勧めします。

まとめ

• AI機能の本番実装は、PoCの延長ではなく別の作業。既存機能との統合、認証・権限、エラー処理、レート制限、コスト管理、監視・評価、ガードレールを追加で設計・実装する必要がある。
• PoCコードは仕様のたたき台として扱い、既存システムの規約に沿って書き直すのが基本。そのまま流用すると保守できないコードが本番に残る。
• 全体公開の前にフィーチャーフラグでの段階リリースを挟み、コスト・精度・エラー率を実測しながら展開範囲を広げるのが安全。

「PoCは手元にあるが、本番実装として何が足りないか分からない」という段階のご相談も多く受けています。AI機能を後付けする前に既存プロダクト側で確認しておくべき観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめています。torcheees では AI・LLM活用の技術支援 を軸に、既存のRails/Reactプロダクトへの AI機能開発の支援 を行っています。まずは「要件整理・開発診断」（1〜4週間）でPoCの現状と本番化に必要な作業を棚卸しするところから、あるいは継続的な改善支援で本番実装まで一貫して伴走することも可能です。お問い合わせからお気軽にご相談ください。