← 記事一覧へ戻る

AI プロジェクトがデモと本番の間で止まる理由

動くデモと稼働するシステムを隔てるいくつかの工程と、それらを初めから計画する方法を紹介します。

障害の後も業務を続ける方法を決める

デモは準備した入力で成功経路を通ります。本番では依存先のタイムアウト、混雑、連続クリック、キャンセル、資料更新も発生します。公開日を約束する前に、利用者、許可する操作、人への引き継ぎ、停止を判断する責任者を受入条件に含めます。

説明用の仮定であり、実際の顧客事例や容量保証ではありません。 社内アシスタントが資料を検索して問い合わせチケットを作り、試験利用者が 5 人から 50 人へ増えると仮定します。論理タスク task-42 の記録は作成されたものの、戻りの接続が切れました。利用者はタイムアウトを見て再度クリックし、その後キャンセルしました。クリックごとに新規タスクを作ると重複し、キャンセルボタンを無効にしても外部記録が取り消されたとは限りません。

失敗したタスクから依存関係を調べる

認証、ナレッジ索引、モデル、タスクキュー、チケットシステムを図にします。同じタスク番号で待機、各呼び出し時間、再試行、版、終了状態を記録し、顧客内容の生データは最小限にします。どこで止まったかを調べてから、モデル、接続、クォータ、業務手順の対策を選びます。

失敗箇所 診断すること 業務の継続方法
ID・権限サービス 本人確認と現在の権限を確認できるか 確認不能なら保護された操作を停止する
索引更新 元文書と索引の版が対応するか 新資料に依存する回答を止め、人が照合する
モデルの制限・停止 クォータ、同時実行、待機、再試行が重なるか 待機・再試行を制限し、期限後に引き継ぐ
書き込み結果不明 既に外部記録があるか 再作成前に状態を照合する
要求の滞留 キューの古さ、処理中件数、遅い依存先 新規処理を制限、拒否、延期し、無制限にためない

5 人から 50 人への増加をモデル容量の単純な倍算にはできません。一件で複数回呼び出し、再試行も資源を使います。代表的な同時実行と遅い依存先で待機、取消、費用、失敗を演習し、キューとタスクの上限を決めてから広げます。

再試行、重複、キャンセルを区別する

同じ論理的な意図に安定したタスク番号を付け、再試行では同じ冪等性キーを使い、要求の要約と結果状態を保存します。プロンプト文字列だけで重複排除すると、正当な似た要求まで抑止します。外部システムに冪等性があれば範囲と有効期間を確認し、なければ状態照合、制御した直列実行、人の確認でリスクを下げます。無条件の「正確に一回」を保証しないでください。

タイムアウトは結果が時間内に届かなかったという意味で、外部操作が起きなかった証拠ではありません。task-42 は作成済み記録を調べ、元の結果を返すか補償処理を決めます。有限の再試行とバックオフは AWS のタイムアウト・再試行の説明を参照してください。

待機を止める、後続処理を止める、上流へ取消を依頼する、完了済み操作を戻すことは別です。cancel_requested を保存しても遅れて来る結果を処理します。完了・取消を確認できなければ unknown として照合キューへ送ります。作成済みチケットには明示的な終了・補償手順が必要で、画面の取消表示だけで未書き込み扱いにはできません。

更新とロールバックにも境界を設ける

コード、モデル、プロンプト、索引、権限、ツール構造を版管理します。資料責任者の承認後、取り込み、キャッシュ失効、引用先アクセスを確認し、影響する質問を再検証します。旧コードへの復帰で撤回済み権限や無効な規程を戻してはいけません。必要なら該当機能を止めます。

代替モデルは処理地域、費用、ツール引数、回答の振る舞いを確認します。承認済み経路がなければ後日の再試行や人への引き継ぎを案内します。公開を戻す前に、処理中タスクの停止、排出、照合を定めます。ページやプロンプトを戻すだけでは外部への副作用は解消せず、責任者が別途処理します。

責任者別の公開判定チェック

  • 業務責任者: 用途、手動の代替、失敗案内を承認する。読み取りから始め、確認結果に応じて提案・書き込みを追加する。
  • 資料・安全責任者: 版、権限、ログ、処理範囲を承認する。権限撤回の失敗、無権限検索、未確認の書き込みがあれば拡大を止める。
  • 技術責任者: 依存障害、重複、取消、遅いコールバック、容量不足を演習し、状態と照合証拠を残す。
  • 運用責任者: 停止条件、復元可能な版、切替スイッチ、戻し手順を記載し、処理中タスクと外部記録の担当を定める。
  • 共同受入: 品質、待ち時間、費用、資料更新の基準を合意する。重要項目に責任者や確認可能な結果がなければ試験範囲を広げない。

公開判断は証拠と責任から行い、動いたデモや固定日数から決めません。段階的な拡大なら、障害の影響を管理できるうちに手順を改善できます。