AI 開発ツールを導入すると、開発効率や製品品質が大きく改善する一方で、「API が止まったら現場は何もできないのでは」という不安を耳にします。私自身、複数の企業で BCP 策定を支援してきましたが、Claude Code を含む LLM ベースのサービスを業務に組み込む際、障害時の代替手段や切り替え判断基準を事前に設計しておかないと、想定外のダウンタイムが発生するケースは実際に存在します。本記事では、API 障害の影響範囲を分析し、他社 LLM やルールベース処理などの代替手段を事前検証する方法、切り替え判断基準とトリガー設定、手動運用マニュアルの整備、復旧後のデータ整合性確保の流れを、具体的な設計例とともに解説します。
本記事の結論: Claude Code の障害対策は影響範囲の分類→代替手段の事前検証→切り替え判断基準の明文化→手動マニュアルの整備→復旧後の整合性確保、の5ステップで設計する
API 障害の影響範囲を分類する
まず、Claude Code の API が停止したときに「どの業務がどれだけ止まるか」を明確にします。影響範囲を以下の3層で分類すると、優先度と代替手段を判断しやすくなります。
| 影響レベル | 業務例 | 停止期間許容度 | 代替手段の必要性 |
|---|---|---|---|
| クリティカル | 本番環境のコード自動生成、顧客向け API のバックエンド | 数分〜数時間 | 即座に代替が必要 |
| 高 | 社内開発ツール、レビュー補助、ドキュメント生成 | 数時間〜半日 | 手動運用で一時対応可 |
| 中 | 実験的プロトタイプ、学習用サンプル生成 | 数日 | 復旧待ちで可 |
たとえば、Claude Code を顧客向け製品の一部（コード補完エンジン、自動テスト生成など）に組み込んでいる場合、API が数時間停止するだけで顧客への SLA 違反やサポート問い合わせが急増します。一方、社内の開発効率化ツールとして使っている場合は、数時間の停止であれば手動レビューで補えるケースが多く、復旧を待つ選択肢もあります。
影響範囲を分類する際のポイントは、業務の時間帯と頻度を考慮することです。たとえば、毎朝9時にバッチ処理でコード生成を行う業務であれば、深夜の短時間障害は影響が小さい一方、リアルタイムに顧客リクエストを処理する API であれば、時間帯を問わず即座の代替が必要です。RPO（Recovery Point Objective：許容データ損失時間）と RTO（Recovery Time Objective：目標復旧時間）は、業務クリティカリティに応じて個別に設定します。一律に「RTO は1時間以内」と定めるのではなく、上記の3層ごとに目標値を決めておくと、障害時の判断がスムーズになります。
代替手段を事前検証する
影響範囲を分類したら、クリティカル・高レベルの業務について、代替手段を事前に検証しておきます。主な選択肢は以下の3つです。
1. 他社 LLM への切り替え — OpenAI GPT-4、Google Gemini、Azure OpenAI Service などを予備系として用意します。プロンプト構造や出力形式が異なる場合があるため、事前にテストデータでコード品質や応答速度を比較し、切り替え時のパフォーマンス低下を把握しておきます。
2. ルールベース処理への縮退 — LLM が不要な単純なコード生成や定型テキスト処理は、正規表現やテンプレートエンジンで代替できます。たとえば、API レスポンスの JSON 整形や簡易的なコメント自動挿入は、ルールベース処理でも十分な品質を保てる場合があります。
3. 手動運用への切り替え — 開発者が直接コードを書く、レビュー担当者が手動でチェックするなど、完全に手動運用に戻す選択肢です。業務量が一時的に増えますが、数時間程度の短期障害であれば、手動で対応する方がシステム変更のリスクが低いケースもあります。
事前検証で重要なのは、切り替えにかかる時間と品質のギャップを測定することです。たとえば、他社 LLM へ切り替える場合、API キーの差し替えや認証フローの変更に5分、プロンプトのチューニングに30分、動作確認に15分かかるとすれば、最短でも50分程度の準備時間が必要です。この数値を RTO と照らし合わせて、「RTO が30分以内であれば他社 LLM では間に合わない」という判断基準を事前に持っておきます。
また、代替手段のコスト構造も確認します。Claude Code が従量課金で月額数万円、予備系の Azure OpenAI が月額数十万円であれば、常時並行運用は現実的でないため、障害発生時に一時的に切り替える設計にします。一方、コストが許容範囲であれば、常時マルチクラウド構成を取り、障害時の切り替えを自動化する選択肢もあります。
切り替え判断基準とトリガー設定
代替手段を用意しても、「いつ切り替えるか」の判断基準が曖昧だと、現場が混乱します。以下の3つの指標でトリガーを設定しておくと、迅速な意思決定が可能になります。
障害検知の基準例:
- API エラー率が5分間で50%を超える
- 連続して3回タイムアウトが発生
- Anthropic 公式ステータスページで「Major Outage」が表示される
これらのトリガーを満たした場合、以下のエスカレーションフローを回します。
- 自動アラート発報 — 監視ツール（Datadog、New Relic、Prometheus など）で API エラー率やレスポンスタイムを監視し、閾値を超えたら Slack や PagerDuty に通知します。
- 影響範囲の確認 — 通知を受けた担当者が、影響レベル（クリティカル/高/中）と業務への波及範囲を確認します。たとえば、顧客向け API が停止している場合はクリティカル、社内ツールのみであれば高と判断します。
- 代替手段の選択 — 事前に検証した代替手段の中から、RTO と業務への影響を考慮して選択します。たとえば、RTO が30分以内であれば手動運用、60分以内であれば他社 LLM への切り替え、といった判断基準を事前に文書化しておきます。
- 切り替え実行と確認 — 選択した代替手段を実行し、動作確認を行います。切り替え後も、Anthropic のステータスページや公式 X アカウント（@AnthropicAI）で復旧状況を定期的に確認し、復旧次第、元の構成に戻す準備を進めます。
切り替え判断基準を明文化する際は、「誰が」「どの情報を元に」「何を判断するか」を具体的に書くことが重要です。たとえば、「エラー率が50%を超えた場合、IT 部門リーダーが Slack チャンネル #incident で影響範囲を確認し、5分以内に代替手段を選択する」といった形で手順書に記載します。
手動運用マニュアルの整備
障害時に手動運用へ切り替える場合、現場の開発者やオペレーターが迷わず作業できるよう、事前にマニュアルを整備しておきます。以下の項目を含めると、実用的なマニュアルになります。
| 項目 | 記載内容 |
|---|---|
| 影響範囲 | どの業務が停止するか、顧客への影響はあるか |
| 代替作業の手順 | 手動でコードを書く、テンプレートを使う、など具体的な作業内容 |
| 担当者と連絡先 | 誰が何を担当するか、エスカレーション先の連絡先 |
| 作業時間の目安 | 手動作業にかかる時間と、復旧までのスケジュール |
| 復旧後の確認項目 | データ整合性チェック、ログの再取得、など |
たとえば、Claude Code でコードレビューの初稿を自動生成している場合、手動運用マニュアルには「開発者が直接レビューコメントを書く」「レビューチェックリストを参照する」「レビュー完了後、Jira チケットにステータスを記載する」といった手順を記載します。また、手動作業の所要時間（例：1件あたり15分）を明記しておくと、障害時のリソース配分や優先順位付けがスムーズになります。
マニュアルは定期的に訓練（ドライラン）を実施して更新します。たとえば、四半期に一度、模擬障害を発生させて、実際にマニュアルに沿って手動運用へ切り替え、復旧までの流れを確認します。訓練で見つかった手順の抜け漏れや不明点を修正し、最新のシステム構成に合わせてマニュアルをアップデートします。
復旧後のデータ整合性確保
Claude Code の API が復旧したら、すぐに元の運用に戻す前に、障害中に発生したデータや処理の整合性を確認します。以下のチェックポイントを押さえておくと、復旧後のトラブルを防げます。
1. 障害中に処理されなかったリクエストの洗い出し — API エラーログやキューに残っているリクエストを確認し、どの処理が未完了かをリストアップします。たとえば、コード生成リクエストが途中で失敗している場合、再実行が必要です。
2. 代替手段で生成したデータの品質確認 — 他社 LLM やルールベース処理で生成したコードやドキュメントが、Claude Code の出力と同等の品質を保っているか、サンプル確認やテストを実施します。品質に問題がある場合は、復旧後に再生成します。
3. ログとメトリクスの再集計 — 障害中のエラー率やレスポンスタイムなど、監視データが欠落している場合があります。復旧後にログを再取得し、監視ダッシュボードや分析レポートを最新化します。
4. 顧客への影響報告と再発防止策の共有 — クリティカルな業務に影響があった場合、顧客や関係部署へ障害の影響範囲と復旧状況を報告します。また、今回の障害で見つかった課題（切り替え判断の遅れ、マニュアルの不備など）を整理し、再発防止策を策定します。
データ整合性の確認には、自動テストや整合性チェックスクリプトを活用すると効率的です。たとえば、コード生成の場合、生成されたコードがビルド可能か、ユニットテストが通るかを自動チェックし、問題があれば再生成します。ドキュメント生成の場合、Markdown の構文エラーやリンク切れを検出するスクリプトを実行します。
復旧後の報告書には、障害の発生時刻・復旧時刻・影響範囲・代替手段の実行状況・データ整合性の確認結果を記載し、社内の BCP ドキュメントやインシデント管理プロセスに反映します。これにより、次回の障害時にはより迅速な対応が可能になります。
まとめ
Claude Code の障害対策は、影響範囲の分類→代替手段の事前検証→切り替え判断基準の明文化→手動マニュアルの整備→復旧後の整合性確保、の5ステップで設計します。RPO・RTO の目標値は業務クリティカリティに応じて個別に設定し、一律の基準を押し付けないことが重要です。代替手段は他社 LLM、ルールベース処理、手動運用の3つを検討し、事前にコストと切り替え時間を測定しておきます。切り替え判断基準は「誰が」「どの情報を元に」「何を判断するか」を具体的に文書化し、定期的に訓練を実施して実効性を高めます。復旧後はデータ整合性を確認し、障害の影響と再発防止策を報告書にまとめます。
株式会社デジライズでは、Claude Code の法人導入支援として、障害対策・BCP 設計を含む包括的なコンサルティングと実務研修を提供しています。影響範囲の分析、代替手段の検証、切り替え手順書の作成、模擬訓練の実施まで、貴社の業務に合わせて支援します。また、業務継続計画の策定や災害復旧手順の整備についても、実績に基づいたノウハウを提供しています。まずは無料相談で現状の課題をお聞かせください。貴社の BCP 要件に最適なフェイルオーバー戦略を一緒に設計します。