目次
AIを業務システムに組み込む要件を書いている方へ
問い合わせ対応、文書の下書き、コードの生成、社内検索。業務システムにLLMを組み込む案件の要件定義や、開発会社からの提案の評価を担当している情報システム部門、DX推進、事業部門の方に向けて書いています。
プロバイダを非難する記事ではありません。私たち自身が開発にClaudeとCodexを使っています。止まることは前提で、止まったときの動きを誰が決めるかが、要件書で空欄になっている、という話です。
LLMのプロバイダはどれくらい止まるのか
各社は障害の記録をステータスページで公開しています。2026年9月8日の朝に取得した内容を、取得できた期間、公開インシデント数、影響度がmajor以上の件数、暦週あたりの件数、公開から解決までの時間の中央値で並べます。
| 項目 | Claude（status.claude.com） | OpenAI（status.openai.com） |
|---|---|---|
| 期間 | 2026年7月1日〜9月7日の69日 | 2026年8月4日〜9月4日の32日 |
| 件数 | 86件 | 25件 |
| major以上 | 28件（critical 6、major 22） | 2件（major 2） |
| 週あたり | 4〜8件 | 1〜8件 |
| 解決の中央値 | 約59分（直近50件） | 約162分 |
件数の比較には使えません
2社の数字を横に並べましたが、多い少ないを言うための表ではありません。ステータスページに何を載せるかの基準は会社ごとに違います。Claude側は個別モデルのエラー率上昇を1件ずつ載せており、OpenAI側は取得できる履歴が直近25件に限られていました。読み取るのは、どのプロバイダでも週に数件は公開される事象が起きていて、影響度の高いものも月に数件はある、という頻度の桁です。
エラーの返り方は、各社の公式ドキュメントに書かれています。各行の太字が状況です。
| Claude API | OpenAI API |
|---|---|
| 呼びすぎ：429 rate_limit_error | 429 Rate limit reached |
| プロバイダ側の混雑：529 overloaded_error | 503 The engine is currently overloaded |
| 急な増加：429（acceleration limits） | 503 Slow Down。元の頻度に戻して15分保つ |
| 内部エラー：500 api_error。指数バックオフで再試行 | 500。少し待って再試行 |
| 処理の時間切れ：504 timeout_error | 記載なし |
Claudeの公式SDKは、接続エラー、レートリミット、5xxを既定で2回まで自動で再試行します（Claude API Errors）。OpenAIは、急な増加に対して「元の頻度に戻して15分以上維持してから徐々に増やす」と書いています（OpenAI Error codes）。再試行を重ねるほど回復が遅れる状況があることを、プロバイダ側が明記しています。
落ちたときの動きは4つしかありません
プロバイダが応答しない、または遅いときに、組み込んだシステムが取れる動きは4つです。
| 動きと内容 | 向く場面 |
|---|---|
| 待つ。間隔を空けて再試行する | 数十秒の乱れ。SDKの既定はこれだけ |
| 替える。別のモデル、別のリージョン、別のプロバイダへ切り替える | 数分以上続く障害。切替先の品質を先に測っておく |
| 縛る。定型の返答やキャッシュした結果を返し、機能を絞る | 切替先もないとき。業務を止めずに済ませる範囲を決める |
| 止める。処理を人へ回し、AIの呼び出しを閉じる | 副作用のある操作。誤った実行より停止を選ぶ |
サーキットブレーカとは、外部への呼び出しを監視し、失敗が閾値を超えたら呼び出し自体を止め、一定時間後に少しだけ通して回復を確かめる仕組みです。Michael Nygardが『Release It』で広め、Martin Fowlerが2014年に整理しました（Circuit Breaker）。閉じている（通常）、開いている（遮断）、半開き（試している）の3つの状態を持ちます。フォールバックは、遮断中に「替える」か「縛る」を実行する側の部品で、サーキットブレーカと組で使います。
4つのうち、どれをどの順で使うかは技術の話ではなく業務の話です。問い合わせ対応なら「縛る」で定型文を返して人につなげば済み、発注処理なら「止める」しかありません。ここが要件書に書かれていないと、開発側は技術的に無難な「待つ」だけを実装し、障害の日に業務が丸ごと止まります。
要件書に書く5項目
LLM組み込みの要件書に書く5項目
-
縮退時の動き。プロバイダが応答しないとき、機能ごとに待つ・替える・縛る・止めるのどれを取るか。利用者の画面に何を出すか
-
切替の判断値と所在。エラー率と応答時間の閾値を数値で書き、切替を自動にするか人が押すかを決める。閾値は通常時の応答時間の分布から起こす
-
切替先の品質確認。フォールバック先のモデルで同じ評価データを通し、許容できる差かを切替の前に確認して記録する
-
副作用のある操作の冪等。発注・送信・更新を伴う呼び出しには冪等キーを付け、再試行で二重に実行されないことを受け入れ条件にする
-
復旧の手順と記録。半開きの状態で段階的に戻す手順と、事象の開始・切替・復旧の時刻を残す場所を決める
RFPの非機能要件の節、または開発会社の提案書の評価項目に、そのまま転記できます
ゲートウェイに置くか、アプリごとに置くか
切替と遮断の仕組みは、業務アプリごとに作るのではなく、LLMへの呼び出しを束ねる共通層に置きます。AIゲートウェイと呼ばれる層です。理由は3つあります。
- 管理が1か所になる。閾値と切替先の設定を、アプリの数だけ持たずに済みます
- 再試行の集中を止められる。障害時に全アプリが一斉に再試行して負荷を増やす状態を、1か所で遮断できます
- モデルの入れ替えがアプリに波及しない。切替先の追加や変更を、業務アプリの変更なしに行えます
3000体のエージェントの裏にあった基盤も、画面と承認を業務アプリ側に残す組み込み方も、同じ構造です。AIの部品は業務アプリの外に置き、業務の判断は業務アプリの中に残す。障害時の動きも、この分け方に従います。
副作用のある操作だけは別扱いです
再試行は無害ではありません。発注、メール送信、在庫の更新のように外に効果が出る操作は、応答が返らなかった1回目が実は成功していると、再試行で2回実行されます。冪等キーは、同じ操作に同じ鍵を付けて2回目を無効にする仕組みです。承認を挟んだつもりが素通りしていた例と同じく、仕様書ではなく実装で確かめる項目です。
読むだけの呼び出しは、待って替える。書く呼び出しは、止める。この線を要件書に引きます。
切替先の品質は障害の日に初めて分かる、では遅い
フォールバック先のモデルは、普段は使いません。だから品質の差は、障害の日に初めて表に出ます。切替先で同じ評価データを通して差を数字で持っておくのは、モデルを替えずにハーネスでスコアが変わる話の裏返しで、ハーネスを変えずにモデルを替えたときの差を測る作業です。
切替が起きたことを人が知る経路も、要件に含めます。異常を見つける部分にAIを使わない監視の設計と同じで、遮断と切替の通知は、AIの外側にある監視から出します。データを外に出せるかの議論は3つの層で確認する話に書きましたが、フォールバック先が別のプロバイダになるなら、その層の確認も切替先について繰り返します。
数字の出どころと限界
この記事の件数は、2026年9月8日6時45分（日本時間）に、ClaudeのステータスページとOpenAIのステータスページから取得した公開履歴に基づきます。Claudeは月別の履歴から7月1日〜9月7日の86件を数え、解決までの中央値は取得できた直近50件で計算しました。OpenAIは取得できる履歴が直近25件までで、それ以前の件数は分かりません。暦週あたりの件数は、期間の両端にかかる週が1週間に満たない場合を含みます。解決までの時間は、公開から解決の記録までの差で、監視を続けていた時間を含みます。
影響度の区分は各社が自社の基準でつけたもので、業務への影響の大きさを揃えて測ったものではありません。エラーの返り方は各社の公式ドキュメントの2026年9月時点の記載で、変わることがあります。