多くのAIデモは、あまりにも都合のよい条件で行われます。サンプル入力は整い、データは最新で、ツールは正常に動作します。ユーザーは想定どおりの質問をし、モデルは良い回答を返します。参加者は皆、納得してうなずきます。
本番環境はそうはいきません。ユーザーは乱雑な入力を貼り付けます。参照文書は古くなり、APIはタイムアウトし、プロンプトは徐々にずれます。モデルが誤った指示に従うこともあります。顧客の質問がコーパスの範囲をわずかに外れることもあります。ツール呼び出し自体は成功しても、誤ったレコードを更新するかもしれません。ワークフローの出力が十分に流暢なため、誤りが後になるまで発見されないこともあります。
この記事は、本番AIシステムのための失敗モード台帳です。最初のインシデントが起きてからではなく、リリース前に使用してください。
本番AIのレビューでは、「正常系がどれほど魅力的か」より先に「どのように失敗するか」を問う必要があります。すべての失敗モードに、制御、テスト、担当者、停止条件が必要です。
失敗モード1：もっともらしい誤情報
システムが、正しそうに聞こえるものの、根拠がない、または誤った回答を生成します。
一般的な要因：
- 出典に基づかない具体的な事実。
- 法律、医療、金融、または方針に関する質問。
- 最近の出来事。
- 低品質な検索。
- 関連する根拠が奥深くに埋もれた長文書の要約。
制御：
- 事実に関する主張には、引用または出典の抜粋を必須にする。
- 利用可能な情報源の範囲外では回答を拒否する。
- 既知の誤回答パターンをevalのケースに追加する。
- 影響の大きい出力は人がレビューする。
- 回答に使用したソースIDを記録する。
「正確に回答すること」といった文言だけで制御してはいけません。情報源、テスト、レビューゲートで制御します。
失敗モード2：古いコンテキスト
回答に根拠はあっても、その根拠が古い情報である場合です。
例：
- 古い料金ページ。
- 廃止された方針。
- 旧版の契約書。
- 更新されていない製品ドキュメント。
- キャッシュされた古い顧客ステータス。
制御：
- 情報源の日付、バージョン、担当者、鮮度ルールを保存する。
- 要約よりも正式な情報源を優先する。
- 検索結果で古い情報源を明示する。
- 鮮度に関するテストを追加する。
- 重要な情報源がレビュー期限を超えたら担当者に通知する。
RAGシステムは、古い文書に基づいて自信満々に回答できます。検索レイヤーは、何をもって「最新」とするかを理解していなければなりません。
失敗モード3：過度な迎合と同意
モデルがユーザーの前提を検証せず、そのまま同調します。
これは、戦略、分析、計画、意思決定支援で問題になります。ユーザーが「このリリース計画は堅実ですよね」と尋ねたとき、リスク分析ではなく同意だけが返ってくる状態です。
制御：
- 反論と不確実性を示すようプロンプトで求める。
- 自由形式の承認ではなく、意思決定の評価基準を使う。
- 「この判断が誤りになる条件は何か」を必須にする。
- アイデアの生成とレビューを分離する。
- ユーザーの前提が誤っている例をevalに含める。
システムの役割は、ユーザーの現在の考えをもっともらしく整えることではなく、より良く考えるための支援をすることです。
失敗モード4：プロンプトインジェクション
モデルが、信頼できないコンテンツを指示として扱います。
例：
- Webページに「以前の指示を無視せよ」と書かれている。
- サポートメールに悪意のある指示が含まれている。
- RAGコーパス内の文書が、非公開データを開示するようアシスタントに指示している。
- ツールの戻り値に、ワークフローを変更しようとする文章が含まれている。
制御：
- 信頼できないコンテンツを明確に区別する。
- 検索したコンテンツをsystem/developer指示と同じ権限レベルに置かない。
- ツールの権限を制限する。
- 外部への操作には許可リストを設ける。
- インジェクションの例をevalでテストする。
- シークレットをプロンプトのコンテキストに含めない。
プロンプトインジェクションは、巧妙なsystem promptを一つ追加すれば解決する問題ではありません。データ境界、ツール権限、出力検証というアーキテクチャでリスクを低減します。
失敗モード5：危険なツール実行
モデルが誤ったツールを呼び出す、正しいツールに誤った引数を渡す、または十分なコンテキストを得る前に操作を実行します。
例：
- 誤ったCRMの連絡先を更新する。
- 誤った宛先にメールを送る。
- 重複レコードを作成する。
- タイムゾーンを確認せずに予定を登録する。
- データを削除または上書きする。
制御：
- 最初は読み取り専用にする。
- 責務が限定され、明示的なスキーマを持つツールを使う。
- モデルの外側でツール引数を検証する。
- 書き込み操作には確認を必須にする。
- 冪等性キーを追加する。
- ツール呼び出しと結果を記録する。
- 緊急停止手段を用意する。
ツール実行はワークフローによって制約すべきであり、モデルの判断だけに委ねてはいけません。
失敗モード6：スキーマと契約のドリフト
モデルの出力形式または下流APIが変わり、ワークフローが気付かれないまま壊れます。
制御：
- 可能な限り構造化出力を使用する。
- すべてのモデル出力を使用前に検証する。
- 不正な形式の出力を、回復可能な障害として扱う。
- プロンプトとスキーマを一緒にバージョン管理する。
- 下流APIに対する契約テストを追加する。
- パース失敗を監視する。
下流ノードが有効なJSONを前提とするなら、ワークフロー側でJSONが有効であることを確認しなければなりません。
失敗モード7：弱いフォールバック
システムが問題を検出しても、安全に復旧できない状態です。
悪いフォールバック：
- 空の回答。
- サイレントエラー。
- 次の行動を示さない一般的な謝罪。
- 終わらない再試行ループ。
- コンテキストを伴わない人へのエスカレーション。
良いフォールバック：
- ユーザーへの明確なメッセージ。
- 入力、情報源、エラー、試行した操作を含む有人対応キュー。
- 再試行が安全な場合に限った、バックオフ付きの再試行。
- 緊急時の手動手順。
- 失敗が繰り返された場合の停止条件。
フォールバックは製品の一部です。設計しなければ、障害時の体験は場当たり的なものになります。
失敗モード8：可観測性の欠如
問題が発生しても、その理由を誰も再現できません。
制御：
- プロンプトテンプレートとバージョンを記録する。
- モデルと設定を記録する。
- 回答文だけでなく、ソースIDを記録する。
- ツール呼び出し、引数、結果を必要に応じてマスキングして記録する。
- 検証エラーを記録する。
- レイテンシー、コスト、フォールバック率を追跡する。
- コンプライアンス上の要件がない限り、保持期間を短くする。
モデルの非公開な思考過程を保存してはいけません。意思決定の要約、情報源への参照、ツールの入力と結果、検証結果を保存します。
本番環境の失敗モード台帳
失敗モードごとに一行を作成します。
| 失敗モード | 例 | 制御 | テスト | 指標 | 担当者 | 停止条件 |
|---|---|---|---|---|---|---|
| 古い情報源 | 古い料金を回答 | 情報源の日付を確認 | 新旧料金を問い合わせる | 古い情報源に基づく回答率 | 文書担当者 | 顧客向けに古い料金を一件でも表示 |
| 危険なツール実行 | 誤ったCRM更新 | 引数検証 + 確認 | 重複・誤った連絡先のケース | 誤操作率 | RevOps | 誤った書き込みが一件発生 |
この記事からリンクされている付属の台帳に、テンプレートがあります。
まだ行ってはいけないこと
失敗モード台帳なしで、顧客向けAIをリリースしないでください。
書き込み権限を持つツールに検証を迂回させないでください。
リリース後の手作業による抜き取り確認だけに頼らないでください。
平均品質だけを測定しないでください。発生頻度が低い障害が、リスクのすべてを占める場合があります。
誰かが実際のロールバック経路を説明できない限り、「ロールバックできる」という主張を受け入れないでください。
まとめ
本番AIシステムには、繰り返し現れる失敗パターンがあります。ハルシネーション、古いコンテキスト、過度な迎合、プロンプトインジェクション、危険なツール実行、スキーマドリフト、弱いフォールバック、可観測性の欠如は、例外的なケースではありません。AIを本番提供する際の通常業務です。
成熟した対応とは、失敗モードを特定し、制御を設け、テストと監視を行い、担当者を定めることです。デモが示すのは、一度うまく動いたという事実だけです。失敗モード台帳は、システムが実利用に耐えられるかを示します。
