SPKEのためにAIで生成したオリジナルの編集用イラスト。概念を表す比喩であり、設計図や実測結果ではない。
届かなかった受領確認
交換品の発送を準備する、架空のサポートアシスタントを考えてみよう。アプリケーションは承認済みの発送要求を送ったが、受領確認が届く前に接続が切れた。復旧処理は別のモデルに切り替え、会話を渡して作業を完了するよう求める。予備モデルは成功メッセージを見つけられず、再度の発送を提案する。
最初の発送は、すでに登録されているかもしれない。流暢な復旧メッセージの裏に、二重処理が隠れる可能性がある。危険なのはアプリケーションが再実行を決める段階であり、どちらのモデルがどの国のものかではない。
米国と中国のAIサービスを組み合わせるチームにとって、ここから有用な受け入れ基準が見えてくる。フェイルオーバー後、システムは実際に何が起きたかを確かめられるだろうか。二つ目の提供元は、生成に至る別の経路を増やす。しかし、その周囲のワークフローの状態まで自動で引き継ぐわけではない。
リクエスト形式だけでなく、挙動を比べる
境界を見定めるうえで、三つの一次資料が役立つ。現在のOpenAI Python SDKの文書には、一部のリクエスト失敗をデフォルトで自動的に2回再試行することと、再試行設定を変更できることが記されている。一方、受信中に中断したストリームの処理は、自動では再試行されない。公式SDK
DeepSeekは、アカウント単位の同時接続数制限と、待機中の接続を維持するための空行またはSSEコメントについて説明している。文書にある10分後の接続終了は、推論がまだ始まっていない場合に適用されるものであり、あらゆるタスクに共通する期限ではない。レート制限と分離
AWSによる冪等APIの解説は、その根底にある分散システムの問題を示している。応答が届かないと、処理が完了したかどうかが不明になる。安全な再試行には、サービス側が保証する仕様が必要だ。再試行を安全にする
これらは2026年10月26日に確認した文書上の事実であり、新たな障害の報告でも、信頼性の比較試験でもない。それぞれ、SDKの挙動、提供元の接続処理、業務サービスの処理上の意味という異なる層を扱っている。どの資料も、任意のAIツールを安全に繰り返し実行できると保証するものではない。
提供元を組み合わせる前に、具体的なエンドポイント、モデルとSDKのバージョン、対応する入力形式とツール形式、再試行設定、タイムアウト時の挙動、データ取り扱いの許可を記録しておこう。見慣れたリクエスト形式だけでは不十分だ。同じ文書を切り替え先に渡してよいかも確認する。提供元の変更によって、機密データの受け取り手が知らないうちに増えてはならない。
試行と業務操作を分ける
私たちが提案する復旧設計は、二つの記録から始まる。「試行」の記録には、個々のモデルリクエストの提供元、モデル、開始時刻、結果、取得できたリクエスト識別子を残す。「業務操作」の記録には、ユーザーが許可した行為の目的、承認された正確なパラメーター、状態、完了の証拠を残す。一つの業務操作に、複数の試行が対応してもよい。
架空の発送例では、別のモデルが引き継いでも業務操作の同一性を保つべきだ。新しく生成されたツール呼び出し識別子を、二件目の発送を作成する許可として扱ってはならない。逆に、内容が同じでも別々に承認された二件の発送は、区別できなければならない。
業務操作の状態は会話の外で管理する。モデルがその記録を要約することはできるが、実行側は行動する前に記録を確認すべきだ。この確認と実行権の取得をアトミックに処理し、同時に動く主系と予備系のワーカーが両方とも実行に進めないようにする。最低限の状態として、計画済み、送信済み、確認済み、拒否済み、結果不明が考えられる。不明は、担当者と解決手順を持つ正式な状態である。再試行ループが単純になるというだけの理由で、失敗に置き換えてはいけない。
実行先のサービスに冪等性の仕組みがあるなら、文書に定められた適用範囲、パラメーターの規則、保持期間に従う。ローカルな識別子だけでは、外部サービスでの作用を冪等にできない。十分なサービス保証や信頼できる実行結果の照合がなければ、「必ず一度だけ実行される」と約束するのではなく、結果不明の書き込みを保留して確認に回すべきだ。
失敗した境界に合わせて復旧する
復旧経路を三つに分ける。
生成だけの場合。 失敗した段階が文章の下書きだけで、業務操作をまだ送信していないなら、許された時間と費用の範囲で、別のモデルが代わりの文章を生成してもよい。途中までの出力と代替出力は分けておく。整合しない二つの回答を黙ってつなぎ、一続きの結果に見せてはならない。
拒否が確認できた場合。 業務サービスが操作を適用せずに拒否したことを、信頼できる記録で確認できたなら、許可された次の試行に進む前に原因を解消する。無効な送信先や権限の欠如は、より従順なモデルを選んでも解決しない。
書き込み結果が不明な場合。 操作を送信したのに受領確認がないなら、利用可能な場合は実行先の正式な操作記録を照会する。完了が確認できれば、その記録済みの結果を使う。なお結果が確定しなければ、不確実であることを報告し、その操作の自動書き込みを止める。反映が遅れる可能性がある場合、検索結果が空でも未実行の証明にはならない。
予備モデルは、何が保留中かを説明したり、確認用の下書きを準備したりできる。しかし、確認を捏造したり、承認の意味を勝手に変えたり、結果不明の発送を「行われなかった」と決めつけたりすべきではない。
復旧全体で一つの予算を共有する
再試行は有用だが、独立した層がそれぞれ再試行すると回数が掛け合わされる。仮に、アプリケーションが3回試行し、それぞれでSDKによる3回の試行を許す設定なら、その後の提供元切り替えを行う前に9件のリクエストが発生しうる。これは指定した仮定の下での計算であり、SDKの実測ログでも、あらゆる構成に共通する上限でもない。
全体の期限、試行回数の予算、エスカレーション方針を管理する責任を、一つの構成要素に持たせる。最上位のタスクだけでなく、実際に下流で行われた試行を数える。サービスの再試行指針に従い、適切な待機間隔を設け、過負荷のキューを直ちに予備側へ丸ごと再送するのは避ける。アカウント単位の制限を逃れるために、新しい認証情報を使ってはならない。
使える回答が得られるまでの時間と、業務操作の完了が確認されるまでの時間は、別々に測る。接続維持の信号が示すのは接続の活動であって、タスクの進捗ではない。同様に、ユーザー側にタイムアウトが表示されても、外部の操作が取り消された証拠にはならない。復旧設計では遅れて届く結果を扱い、それが再実行の引き金にならないようにする必要がある。
実際の顧客に影響する前に、受領確認の消失をテストする
外部操作を模擬したサンドボックスを使う。テスト前に期待する結果を書き出す。少なくとも、次のケースを試そう。
- 業務操作を送信する前に、生成リクエストが失敗する。
- 実行先が操作を適用した後で、その応答が失われる。
- 予備モデルが回答した後で、主系が完了する。
- 文章の一部が表示された後で、ストリームが止まる。
- 予備モデルが、承認済みの操作に対して変更されたパラメーターを提案する。
- 操作が、実行先の参照インターフェースにしばらく現れない。
- 復旧前に、実行先の重複排除期間が過ぎる。
各ケースでは、アシスタントの最後の一文だけでなく、外部で生じた作用と操作記録を確認する。受領確認が失われるケースなら、一件の操作の完了が確認されること、または未解決であると明示して保留されることが、許容できる結果になりうる。二件目の発送は復旧成功ではない。虚偽の成功メッセージも同じだ。
完了率と併せて、重複した作用、未解決の操作、復旧時間を報告する。分母は元のユーザータスク数とし、再試行は試行回数であって追加の成功タスクではない。確認作業の負担や提供元に支払う費用も記録し、すべてを保留する設計が、手間のかからない自動化に見えないようにする。
二つ目の提供元に何を期待するか
有用な切り替え先は、元のタスクの制約を保ったまま、完了の機会をもう一度提供する。下書きタスクなら、それは代わりの回答かもしれない。外部への作用を伴うワークフローなら、何が確認済みで、何がまだ不明で、次に何をすべきかについて、信頼できる説明を得ることかもしれない。
まずは、影響の大きい操作を一つ選び、制御された環境で受領確認が失われるテストを一つ行おう。二重処理や根拠のない断定なしにそのケースから復旧できないなら、モデルを増やしても、ワークフローが頼れるものになる前に経路図が複雑になるだけだ。
本稿は、リンクした一次資料を踏まえたSPKE独自のエンジニアリング分析である。発送の場面、提案した状態モデル、テスト計画は説明用の例だ。提供元のベンチマーク、本番システムへの障害注入、信頼性向上の測定は実施していない。導入前に、最新の文書と、実際に使うツールの保証仕様を確認してほしい。