ChatGPTを使って「すごい、これ業務に使えそう」と思った次の瞬間、本番システムにどう組み込むかで手が止まる。私たちのところにも「ChatGPTのAPIを叩くところまではできた。でもそこから先がわからない」という相談がよく来ます。
試作と本番の間には設計上の判断がいくつもあります。この記事では、LLMを業務システムに組み込む際に必ず考えることになるポイントを書きます。
プロンプトはコードの一部として管理する
LLMの振る舞いはプロンプトで決まります。つまりプロンプトは仕様そのものです。にもかかわらず、管理画面のテキストエリアに直接書いて運用している例をよく見ます。
私たちはプロンプトをソースコードと同じリポジトリでバージョン管理します。理由は単純で、「先週まで動いていたのに急におかしくなった」ときに差分を追えないと原因調査ができないからです。誰がいつ何を変えたかが追えること、変更前に戻せることは、本番運用の最低条件です。
LLMは落ちる前提で設計する
外部APIは落ちます。LLMのAPIも例外ではなく、レートリミット、タイムアウト、モデル側の一時障害は日常的に起きます。
業務システムの場合、LLMが応答しないときにシステム全体が止まるのは許容できません。設計の基本は「LLMなしでも最低限の業務が回るフォールバックを用意する」ことです。たとえば、LLMによる自動分類が失敗したら人間の確認キューに回す、要約生成が使えなければ元の文書をそのまま表示する、といった具合です。
レスポンスは信用しない
LLMの出力は確率的です。同じ入力に対して毎回同じ出力が返る保証はなく、ときどき形式が崩れたり、指示を無視した回答が返ってきます。
業務システムに組み込む場合、LLMの出力をそのまま後続処理に流すのは危険です。必ずバリデーション層を挟みます。JSONで返すよう指示しているなら、返ってきた文字列が有効なJSONかをパースして確認する。分類結果を返すなら、想定カテゴリに含まれるかをチェックする。検証に失敗したらリトライするか、フォールバックに回します。
コストは「1件あたり」で見える化する
LLMのAPIはトークン課金です。開発中は気にならなくても、本番で1日数千件処理するようになると月額が跳ね上がることがあります。
設計時にやるべきは、「1業務処理あたり何円かかるか」を概算しておくことです。入力トークン数はプロンプトの長さと入力データの長さで決まるので、代表的なケースで計算できます。その上で、コストが見合わない処理にはキャッシュ（同じ入力には過去の結果を返す）や、軽量モデルへの振り分け（簡単な判定は小さいモデル、複雑な生成は大きいモデル）で最適化します。
ログは全部残す
LLMを使った処理は、入力・プロンプト・出力・処理時間・トークン数をすべて記録します。理由は3つです。
1つめは品質改善。「最近この種類の入力で精度が落ちている」はログを分析して初めてわかります。2つめはコスト管理。どの処理がトークンを食っているかはログで見えます。3つめは障害対応。おかしな出力が出たとき、何を入力して何が返ってきたかの記録がないと再現も修正もできません。
まとめ
LLMを業務システムに組み込む設計は、「APIを叩く」の先にあるプロンプト管理・フォールバック・出力検証・コスト制御・ログの5つが柱です。どれも地味ですが、これらがないまま本番に出すと、動いたり動かなかったりする不安定なシステムになります。
私たちはLLMを組み込んだ業務システムの設計・構築を手がけています。「APIは叩けたが本番化の設計がわからない」という段階でもご相談いただけます。お問い合わせからお気軽にどうぞ。