業務システムに生成AIを組み込むときの設計上の勘所｜情シス・発注担当者の視点

「ChatGPTに繋ぐだけ」では業務システムにならない

「ChatGPTのAPIは数行で繋がります」「Claudeも同じです」――これは事実です。簡単に動くサンプルは、公式サイトに山ほどあります。

ですが、それは 検証レベル の話です。業務システムとして本番運用するには、生成AIへのつなぎ込みの周辺で、次のような問題が必ず発生します。

• ユーザーが20秒待たされる（生成AIの応答が遅い）
• 同じ質問に毎回違う答えが返る（出力が安定しない）
• 「JSON形式で返してください」と指示したのに自由文で返ってくる
• 毎月の利用料が想定の3倍になっていた
• 誰が何を質問したかの記録がなく、問題発生時に追えない
• 使用中の生成AIサービスに障害があり、システム全体が停止する

これらは技術ブログのサンプルでは出てきませんが、業務利用では必ず直面します。本記事では、業務システムに生成AIを組み込むときに 「最初から考えておくべきポイント」 を、発注担当者目線で整理します。発注先の見積もりや設計提案が、これらをカバーしているかをチェックする観点としても使えます。

1. 出力形式を機械処理できる構造にする

業務システムでは、生成AIの出力を 後続のシステムにそのまま渡せる形式で受け取る必要があります。たとえば「自由文で返ってきた回答を、文字列処理でなんとかパースする」設計は、本番で必ず破綻します。

確認すべきこと

• 出力形式（項目名・型）を生成AIに強制する仕組みを使う設計になっているか
• 稀に想定と違う形式で返ってきた場合の処理（再試行・人手介入）が決まっているか
• 「プロンプトでJSONで返してくださいと指示するだけ」になっていないか

「プロンプトで指示するだけ」は、稀に違う形式で返ってきたり壊れたデータが返ったりして、業務システムの後続処理を止める原因になります。出力形式を強制する仕組みを使うべきです。

2. 応答時間と中断対策

生成AIは、通常の業務システムよりはるかに応答時間が長く、不安定です。

設計上のポイント

• ユーザーを待たせない設計: 業務系チャットなら必ず「文字を1文字ずつ表示」する形式（タイプライター風）にする。固まったように見えない
• 長時間処理は裏で動かす: 要約・分類などは画面で待たず、完了したら通知する仕組みにする
• タイムアウト設定: 60〜120秒で打ち切り、再試行は最大3回まで（無限再試行は利用料の暴発につながる）

3. 利用料の暴発を防ぐ仕組み

生成AIは 1回の呼び出しに数円〜数十円 かかります。再試行のループや想定外のエラーで何度も呼び出されると、月末の請求で気づくパターンが発生します。

利用料暴発の典型と対策

• 無限再試行: 失敗→自動再試行が永遠に続く。最大試行回数を必ず設定
• 同じ処理の二重実行: 同じ入力に対する重複実行を防ぐ仕組みを入れる
• 利用回数制限: ユーザーごと、部署ごと、組織全体の3層で上限を設ける
• 月額アラート: 利用料が想定を超えたら通知される設定（Slack通知など）
• テスト環境と本番環境の利用枠を分ける: 開発で誤って本番枠を消費しないように

特に テスト環境で誤ってループ処理を回した結果、月数十万円の請求 が発生する事故は実際によくあります。最初から防御層を入れておくべきです。

4. プロンプト（指示文）の管理体制

業務システムでは、生成AIに送る指示文（プロンプト）が、業務ロジックと同じくらい重要です。

よくある失敗パターン

• プロンプトをコードに直接埋め込んで管理 → 変更履歴が追えない、A/Bテストできない
• 管理画面でプロンプトを編集できるようにした → 誰がいつ変えたか追えなくなり、本番で壊れる
• プロンプトを変えたら全機能の精度が変わった → 影響範囲が読めず、怖くて変えられない

確認すべきこと

• プロンプトのバージョン管理（誰がいつ変えたかの履歴）の仕組みがあるか
• プロンプト変更時に、自動で品質チェックが走る仕組みがあるか
• 本番反映前に、過去の質問群で精度が劣化していないか確認する仕組みがあるか

5. 「もっともらしい嘘」への対策

生成AIは、もっともらしい嘘を返すことがあります。業務システムでは、この性質を 設計でカバーする 必要があります。

業務利用での「もっともらしい嘘」対策

• 参照元を必ず出力させる: 「この回答は◯◯の資料を参照しています」と一緒に返す
• 分からないときは「分からない」と答えさせる: 推測で答えさせない指示を組み込む
• 検索ヒットがゼロなら回答しない: 社内資料を参照させる場合、該当文書がなければ「該当なし」を返す
• 金額・日付などは生成AI単独で扱わせない: 抽出箇所だけ示させ、値は別の処理で正確に取り出す
• 業務影響の大きい判断は人間レビュー: 「生成AIが下書き、人間が承認」のフロー設計

「もっともらしい嘘をゼロにする」は不可能なので、ゼロを目指すのではなく、業務影響を許容範囲に抑える設計が現実解です。

6. 監査ログと利用状況の見える化

業務利用では、誰が・いつ・何を質問し、生成AIが何を回答したかを全件記録することが基本です。

最低限保存すべきデータ

これらを後から追加するのは大変なので、最初から保存する設計にします。

7. 使う生成AIの世代交代に備える

ChatGPT、Claude、Gemini いずれも、サービス仕様の変更と古いバージョンの廃止が日常的に発生します。

• OpenAI: 古い ChatGPT のバージョンは段階的に廃止
• Anthropic: Claude も世代交代が継続的
• Google: Gemini も同様

業務利用なら、最初から「使う生成AIを差し替えられる構造」で実装します。

確認すべきこと

• 使う生成AIを将来差し替えられる構造（ベンダーロックインを避ける設計）になっているか
• 新しい生成AIに切り替えるときの精度比較を、既存のテストデータで自動評価できる仕組みがあるか
• 切替時の追加費用が事前に見積もられているか

まとめ: 業務システムに必要な「生成AIの周辺装置」

業務システムに生成AIを組み込むとき、生成AIへの呼び出しそのものはシステム全体の1割程度です。残り9割は次の「周辺装置」になります。

1. 出力形式を機械処理できる構造に
2. 応答時間対策と中断時の再処理
3. 利用料の暴発防止
4. プロンプト（指示文）の管理体制
5. 「もっともらしい嘘」への対策
6. 監査ログと見える化
7. 使う生成AIの世代交代対策

「検証は動いた → 本番化はすぐできる」と思っていると、ここで大きく工数が膨らみます。発注先の提案にこれらの観点が含まれているか、見積もり比較時にチェックすることを勧めます。

Beekleにご相談ください

Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。

お問い合わせはこちら