Algion代表の岡本です。
生成AIを使った機能は、最初のデモまでは比較的早く作れます。入力した文章から必要な情報を抽出し、JSONで返して、後続のシステムへ渡す。数件のサンプルで試すだけなら、きれいに動くことも少なくありません。
一方、実際の業務では入力が欠けていたり、表記が揺れていたり、想定していない内容が含まれたりします。AIの出力も毎回同じとは限りません。フィールドが抜ける、型が変わる、説明文が混ざる、選択肢にない値が返るといったことが起こります。
生成AIが構造化された出力を返せることと、その出力を業務システムで安全に扱えることは別です。本記事では、AIと業務システムの境界に何を用意すべきかを整理します。
1. デモでは動くのに、業務システムでは壊れる理由
デモでは、入力する人も期待する結果もある程度わかっています。開発者が用意した例を使い、出力に問題があればその場でプロンプトを調整できます。
本番では、次のような条件が加わります。
- 必要な情報が入力に含まれていない
- 同じ意味が異なる表記や単位で書かれている
- 複数の文書やシステムから情報が渡される
- AIが判断できない内容も処理対象になる
- 出力がそのまま登録、通知、計算などの後続処理に使われる
人が画面を見て違和感に気付けるデモと異なり、システム連携では不正な出力が後続処理まで進む可能性があります。したがって、AIの出力を信頼するのではなく、検査できる入力として扱う必要があります。
2. 構造化出力だけでは十分ではない
JSONや表形式で出力させると、プログラムから扱いやすくなります。しかし、構文が正しいことは、内容が正しいことを意味しません。
例えば、日付フィールドに存在しない日付が入る、金額が文字列として返る、必須項目が空になる、候補にない分類名が生成されるといったことがあります。JSONとして解析できても、業務上は受け入れられない出力です。
確認すべき内容は、大きく三つに分けられます。
- 構文: JSONなどの形式として読み取れるか
- スキーマ: 必要な項目、型、選択肢を満たしているか
- 業務ルール: 項目同士の関係や、許容範囲を満たしているか
構造化出力は入口であり、その後にスキーマ検証と業務ルールの確認が必要です。
3. 必須・任意・欠損を先に定義する
AIに返してほしい項目を並べるだけでなく、情報がない場合にどう扱うかまで決めます。
| 状態 | 意味 | システムでの扱い |
|---|---|---|
| 必須 | 後続処理に必要 | 欠損していれば処理を止める |
| 任意 | なくても処理可能 | 欠損を許容し、既定値で補わない |
| null | 入力に情報がない | 「不明」という結果として保持する |
| 不正 | 形式や値が条件外 | 補正、再試行、確認へ振り分ける |
特に、「情報がない」と「AIが抽出に失敗した」を区別することが重要です。どちらも空欄にすると、後から原因を判断できません。
また、AIに推測させてはいけない項目も明示します。入力にない顧客名や日付をそれらしく補うより、nullとして返し、人や別のシステムで確認できる方が安全です。
4. 検証と正規化を分ける
出力を受け取った後の処理は、検証と正規化に分けると設計しやすくなります。
検証では、そのまま受け入れてよいかを判定します。必須項目、型、文字数、選択肢、数値範囲、項目間の整合性などを確認します。
正規化では、意味を変えずに表記を揃えます。全角・半角、日付形式、単位、余分な空白、既知の表記揺れなど、決定的なルールで直せるものを対象にします。
ここで大切なのは、プログラムで確実に直せる内容を再びAIへ任せないことです。日付形式の統一や既知の名称変換は、固定ルールの方が再現性を確保できます。一方、内容の再解釈が必要な場合は、勝手に補正せず、再試行や確認へ進めます。
5. 再試行・フォールバック・人手確認を使い分ける
検証に失敗した出力を、すべて同じ方法で処理する必要はありません。失敗の種類と影響に応じて経路を分けます。
- 再試行: 出力形式の崩れなど、同じ入力でも改善する可能性がある場合
- 修正して再試行: 検証エラーをAIへ伝え、対象項目だけを出し直せる場合
- 固定ルールへ切り替え: 単純な分類や変換を決定的な処理で代替できる場合
- 人手確認: 金額、契約、外部送信など、誤りの影響が大きい場合
- 安全に停止: 入力不足や外部システム障害など、続行すべきでない場合
再試行回数には上限を設けます。同じ失敗を繰り返して処理時間とコストを増やすより、理由を示して人へ戻す方が適切なこともあります。
また、フォールバックは「何が起きても処理を続ける」ためのものではありません。失敗時にも業務を安全な状態へ戻すための設計です。
6. 後から原因を確認できるログを残す
AIの出力が期待と異なったとき、最終結果だけを保存しても原因はわかりません。少なくとも、次の情報を追跡できるようにします。
- 使用したモデルや設定、プロンプトのバージョン
- スキーマと業務ルールのバージョン
- 検証で失敗した項目と理由
- 正規化した内容
- 再試行の回数と結果
- フォールバックや人手確認へ進んだ理由
- 最終的に採用した結果と処理状態
一方で、機密情報や個人情報をそのままログへ残さない配慮も必要です。入力全文を保存するのではなく、識別子、ハッシュ、必要な差分などで追跡できる構成を検討します。
ログは障害調査のためだけではありません。どの入力で失敗しやすいかを把握し、評価データや設計を改善する材料になります。
7. 本番投入前のチェックリスト
- 出力項目の必須・任意・nullが定義されているか
- 構文、スキーマ、業務ルールを分けて検証しているか
- AIに推測させてはいけない項目が決まっているか
- 決定的な正規化はプログラムで処理しているか
- 再試行の条件と上限が決まっているか
- フォールバックと人手確認の条件が明確か
- 不正な出力が後続システムへ進まないか
- 採用結果と失敗理由を後から追跡できるか
- ログに機密情報を残しすぎていないか
結論
生成AIを業務システムへ組み込むとき、重要なのは正常な出力を増やすことだけではありません。期待どおりにならなかったときに、検知し、安全な経路へ切り替え、後から改善できることが必要です。
スキーマ、検証、正規化、再試行、フォールバックをAIと業務処理の境界に置くことで、確率的な出力を扱いながら、システムとしての再現性と安全性を高められます。
Algionでは、生成AIの出力設計から既存システムとの接続、本番運用を見据えた検証まで支援しています。構想段階からでもご相談いただけます。