PHPアプリケーションに統合したAI機能は、応答に時間がかかりすぎたり、利用できなかったり、処理に役立たない結果を返したりすることがあります。すべての応答を有効なものとして扱ったり、リクエストを無期限に繰り返したりしても問題は解決しません。どちらも、ユーザー体験、データ、コストを損なうおそれがあります。PHPでのAI連携におけるフォールバックでは、依存先に障害が起きた際にシステムがどう動作するか、また、妥当な応答が得られないまま続行してはならない処理を定めます。
適切な代替策は、機能が与える影響によって異なります。テキストの提案なら一時的に省略できますが、支払い、権限、データ更新に影響する判断を、不完全または推測に基づく情報で実行してはなりません。目的は、あらゆるエラーを隠すことではなく、予測可能な動作を維持することです。
何を障害とみなすかを定義する
代替策を実装する前に、応答が利用不能となる条件を明確にします。ケースを分けることで、ポリシーを選びやすくなり、その有効性も測定できます。
- タイムアウト：リクエストがアプリケーションの待機時間上限を超える。
- 利用不能または通信エラー：接続に失敗する、またはプロバイダーがエラーを返す。
- 空の応答：呼び出しは完了するが、期待した内容が含まれていない。
- 無効な形式：結果を解析できない、または必要なスキーマに適合しない。たとえば、必須フィールドが欠けたJSON。
- 受け入れられない結果：出力は読めるものの、ビジネスルール、バリデーション、セキュリティ基準を満たさない。
技術的に正しい応答と、有効な判断を同一視してはなりません。アプリケーションが限定された候補群からカテゴリを受け取る場合、その値が候補群に含まれることを検証します。必須フィールドがある場合は、別のコンポーネントに渡す前に検証します。決定論的なチェックはPHPコードで実行し、同じモデルに再度委ねてはなりません。
待機時間と再試行を制限する
処理内容と、ユーザーまたはプロセスが待てる総時間に応じてタイムアウトを設定します。Webサーバー、キュー、中間のHTTPクライアントの制限も考慮してください。ローカルのタイムアウトがリクエスト全体の上限を超えていても、実質的な制御にはなりません。バックグラウンドタスクでは別の待機時間を許容できますが、保留中のジョブに対する明示的なポリシーが必要です。
再試行は回数を制限し、一時的に回復し得る障害にのみ適用します。ネットワークの中断なら追加の試行が妥当な場合がありますが、スキーマ違反の応答には通常、やみくもな再試行ではなく、バリデーション、フォールバック、またはレビューが必要です。試行回数と総時間を制限してください。段階的に待機時間を延ばす場合も、上限を設けます。
呼び出しを繰り返すと、利用量や副作用が重複する可能性があります。無制限の自動再試行を避け、処理が冪等かどうかを確認してください。副作用のないテキスト生成と、注文を作成したり通知を送信したりする操作は同じではありません。影響の大きい操作では、提案の生成とその実行を分離し、実行側に独自の制御を設けます。
影響に応じて代替策を選ぶ
フォールバックは、あらゆる障害に使う汎用的な応答ではありません。ビジネスルールを守り、アプリケーションで何ができるかを明確に伝える必要があります。
- 機能を縮退させる：AIが利便性を高める役割なら、その機能なしで続行できるようにします。たとえば、提案を生成できない場合は通常のフォームを表示します。
- 保留する：結果を後から生成できる場合は、保留状態でジョブを保存し、上限と追跡を設けたキュー経由で再試行できるようにします。
- レビューを依頼する：人の判断が必要なら、提案を下書きとして表示するか、担当者に回します。検証されていない出力を最終判断として提示してはなりません。
- 拒否または停止する：処理に必要な条件を検証できない場合は、操作を止め、続行方法やサポートの依頼方法を説明します。
判断の基準は、中断のコストだけではなく、誤った操作をするリスクに置くべきです。候補を提案する検索機能なら、元の検索クエリで続行できます。一方、顧客データを変更するフローでは、欠けたフィールドを推測で補完してはなりません。AIの出力がビジネス上の判断に影響する場合は、可能であれば手動の経路または決定論的なルールを残します。
プロセスの完全性を守る
モデルの応答は外部入力として扱います。構造を解析し、各値を検証し、実行できる操作を制限してください。SQLクエリ、コマンド、HTML、他システムへの指示に直接挿入してはなりません。ドメイン固有のチェックに加え、プリペアドステートメント、適切なエンコーディング、許可リストを使用します。
提案と実行の境界を定めます。たとえば、AIが分類を提案し、コードが許容可能か検証したうえで、製品のポリシーに従って自動適用するか保留にするかを決定します。必須データが不足している場合、安全な代替策は通常、情報を求める、ケースを未完了のままにする、または処理を停止することであり、値を捏造することではありません。障害時の動作も、通常の権限、バリデーション、認可ルールに従う必要があります。
不要な情報を保存せずに障害を記録する
ログは診断に役立つものであるべきですが、会話のコピーになってはなりません。処理内容、障害の種類、所要時間、試行回数、バリデーション結果、相関IDなどの技術イベントを記録します。タイムアウトと不正なJSONを区別できるだけの情報を加えつつ、プロンプト全文、応答、認証情報、個人データを標準で記録することは避けます。
レビューや監査のために内容を保持する必要がある場合は、保存する前に目的、アクセス権、保存期間、保護策を定めてください。メトリクスでは、タイムアウト、無効な応答、フォールバック、保留中のジョブの発生頻度に加えて、レイテンシと再試行を追跡します。増加は、運用上の問題や出力動作の変化を示している可能性があります。メトリクスは傾向の検知に役立ちますが、個別ケースのレビューに代わるものではなく、応答が正しいことを単独で証明するものでもありません。
シナリオをテストし、基準を合意する
制御された応答を使って連携をテストし、ユーザーに見える結果とシステムへの影響の両方を確認します。高レイテンシ、接続中断、空の応答、無効な形式、ルールに反する値、障害からの復旧を含めてください。操作が重複して実行されないこと、再試行が上限を守ること、ログから機密情報が漏れないことを確認します。タスクが保留になった場合や、人の介入が必要な場合の動作もテストします。
機能を本番環境に投入する前に、プロダクト担当者と技術担当者の間で次の事項に合意してください。
- この機能は処理の完了に必須か、それともユーザー体験を高めるだけか。
- チャネルごとに許容できる総待機時間はどれくらいか。
- どの障害で再試行でき、何回まで許可するか。
- 安全な代替策は何か。AIなしで続行する、保留する、人がレビューする、または停止するのか。
- 応答を利用する前に、どのバリデーションを通過させる必要があるか。
- どのデータを記録し、誰がアクセスでき、どれくらいの期間保存するか。
- チームにどうアラートを通知し、誰が保留中のケースを解決するか。
有効なポリシーでは、付随的な機能は縮退させ、未検証データに依存する操作は停止できます。応答が遅い、無効、または欠落しているときの動作を正確に説明できないなら、その連携にはまだ運用可能なフォールバックがありません。これらのルールを処理フローとともに文書化し、製品、バリデーション、サービスの利用方法に変更があれば再テストしてください。
