2026.07.28 2026.07.28

AIへの依存リスクが現実になった日 — Fable 5停止事件に学ぶフォールバック設計

ゲンキ

AIへの依存リスクが現実になった日 — Fable 5停止事件に学ぶフォールバック設計

AI依存リスクという言葉は、2026年6月12日までは半分比喩でした。障害でAIが数時間止まる、値上げでコストが跳ねる——その程度の想定で、多くの組織は「まあ何とかなる」と構えていたはずです。

その想定は6月に壊れました。発表からわずか3日の最上位モデルが、国家の判断でスイッチを切られ、7月1日まで戻らなかったのです。障害でも値上げでもない第三のリスク——供給そのものが政策の変数になるリスク——が、具体的な日付と共に実証されました。

本稿は、この事件の事実経過を整理したうえで、教訓を「フォールバック設計」という実務に落とし込みます。政治的な是非は扱いません。扱うのは、あなたの業務が明日も動くための設計だけです。事件を含む3ヶ月の全体像はClaudeの最新情報に一気に追いつく (2026-07-27 公開)を、止まった当のモデルの詳細はClaude Fable 5とは何者か (2026-07-28 公開)を参照してください。

6月に起きたことを、感情抜きで並べ直す
何が新しいリスクだったのか — 障害・値上げ・そして供給
「AIはインフラ」の本当の意味
依存の棚卸し — AIがどこに埋まっているかを地図にする
設計原則1: 抽象化レイヤ — モデル名を業務から引き剥がす
設計原則2: フォールバック連鎖 — 同格・格下・ローカルの3段構え
設計原則3: 切替は訓練されて初めて存在する
ツールの現在地 — 公式機能だけでもここまで組める
個人と小さなチームは何をすべきか
まとめ — 「止まらないAI」ではなく「止まっても続く仕事」

忍者AdMax

6月に起きたことを、感情抜きで並べ直す

まず事実だけを時系列に置きます。6月9日、AnthropicはClaude Fable 5とClaude Mythos 5を発表しました。6月12日（金）、米政府が両モデルに輸出規制を適用し、提供が停止します。6月30日に規制解除が発表され、7月1日からClaude Platform・Claude.ai・Claude Code・Coworkでグローバルに提供が再開されました。再開直後の有料プランには、7月7日まで週次上限の最大50%までFable 5を使える経過措置が設けられています。

重要な留保が2つあります。第一に、止まったのはFable 5とMythos 5だけで、Opus 4.8やSonnet系はその間も動き続けました。全面停止ではなく「最上段の消失」です。第二に、規制の理由について確定的な公表は乏しく、報道は安全保障上の懸念とジェイルブレイク報告を伝えつつ、専門家によるリスク誇張の指摘も併記しています（Al Jazeera報道）。理由の解釈に踏み込むより、「この種の停止は起こりうる」という事実を設計条件に加えるほうが生産的です。

何が新しいリスクだったのか — 障害・値上げ・そして供給

システム設計者はこれまで、AIサービスについて2種類のリスクを管理してきました。ひとつは可用性リスク、つまり障害やレート制限で一時的に使えなくなること。もうひとつは経済リスク、つまり値上げや無料枠縮小でコスト構造が変わることです。どちらも対策の型が確立しています。

6月の事件が突きつけたのは第三の類型、供給リスクです。サービス提供者に落ち度がなくても、規制・輸出管理・地政学の判断ひとつで、特定のモデルが法的に提供できなくなる。しかも停止の予告期間はほぼゼロで、復旧時期は当事者にも約束できません。実際、停止は金曜日に突然始まりました。

この類型が厄介なのは、SLA（サービス品質保証）の外側にあることです。契約でどれだけ高い稼働率を約束されていても、供給の法的根拠が失われれば意味を持ちません。AI依存リスクの管理とは、この「契約の外側」まで含めて業務の継続性を設計することを指します。

類似の構図は他の産業が先に経験しています。半導体の供給網が地政学の変数になったとき、製造業は在庫戦略と調達先の多元化を根本から見直しました。特定国のクラウドサービスが規制対象になった事例では、データの置き場所と移設可能性が契約審査の必須項目になりました。AIモデルも同じ道をたどっている、と考えれば驚きは減ります。違いがあるとすれば、AIの場合は「在庫」を持てないことです。モデルは倉庫に積んでおけないため、備えは調達の多元化と切替能力の側に全振りするしかありません。

「AIはインフラ」の本当の意味

AIはインフラになった、という言い回しには続きがあります。インフラになったのなら、インフラとして扱う責任が使う側にも生じる、という続きです。

電力を考えてみてください。停電が現実に起こると知っている組織は、非常用電源を備え、切替手順を文書化し、年に何度か訓練します。クラウドも同じで、リージョン障害を前提にマルチリージョン構成を組むのが当然になりました。要するに、成熟したインフラ利用とは「止まらないと信じること」ではなく「止まっても続く形に組むこと」です。

電力やクラウドとの違いにも目を向けるべきです。電気はどの電力会社から買っても同じ電気ですが、AIモデルは供給元ごとに個性があり、切り替えれば挙動が変わります。つまりAIは、互換性が保証されないインフラという厄介な性質を持ちます。プロンプトという「接続仕様」が事実上ベンダー方言を含むため、切替には翻訳コストが伴う。この翻訳コストを平時に払っておくのがフォールバック設計だ、と言い換えることもできます。

AIだけがこの規律の例外でいられる理由はありません。むしろAIは電力やクラウドより供給の集中度が高く、代替の互換性が低いぶん、設計の優先度は高いはずです。6月の事件は、その優先順位を書き換えるための、比較的安価な授業だったと捉えるべきでしょう。実害を被った組織には気の毒ですが、業界全体としては「最上位モデルだけが消え、代替は動き続けた」という、教訓の割に傷の浅いケーススタディでした。

依存の棚卸し — AIがどこに埋まっているかを地図にする

フォールバック設計の第一歩は、コードを書くことではなく、依存の地図を作ることです。多くの組織は、自分たちがどこでAIに依存しているかを正確に列挙できません。

棚卸しの軸は2つで足ります。横軸に利用頻度、縦軸に停止時の業務影響を取り、AIが関与する業務をすべて4象限に置いていきます。毎日動いて止まると業務が止まる象限——たとえば顧客対応の自動化や継続的なコード生成——が最優先の防御対象です。逆に、頻度も影響も低い象限は、対策を後回しにしてよい領域だと明確になります。

このとき見落としやすいのが、間接依存です。自社が直接AIを呼んでいなくても、使っているSaaSの中核機能がAIで動いていれば、依存は存在します。ベンダーに「どのモデルに依存し、停止時はどうなるか」を問う項目を、調達チェックリストに一行加えるだけで、地図の精度は大きく上がります。

規模感の参考に、当サイト自身の制作フローを棚卸ししてみます。記事の執筆と品質チェックはClaude系モデルに依存しており、これが止まると制作は大きく減速します——影響大・頻度高の最優先象限です。一方、記事用の画像生成は手元のGPUで動くローカル環境に載せてあるため、外部供給が止まっても影響を受けません。デプロイは自作スクリプトで、AI依存はゼロ。つまり守るべき一点は執筆工程だと即座に特定でき、フォールバック投資をそこへ集中できます。数人規模の運営でも、地図を描けば優先順位はここまで明確になります。

設計原則1: 抽象化レイヤ — モデル名を業務から引き剥がす

地図ができたら、防御の第一原則は抽象化です。業務コードのあちこちに特定のモデルIDが直書きされている状態は、特定の発電所に配線を直結しているのと同じです。

やることは単純で、モデル呼び出しを一枚のレイヤに集約し、業務側は「要約する」「設計案を出す」といった役割名で呼ぶようにします。どの役割をどのモデルで実装するかは、レイヤの設定ファイルだけが知っている。この形にしておけば、モデルの差し替えは設定変更ひとつで済み、6月のような停止時にも業務コードには手を触れずに切り替えられます。

役割の切り方には少しだけ設計判断が要ります。細かすぎる役割分割は管理負荷を生み、粗すぎると「この役割はどのモデルでも務まる」という言い切りができなくなります。目安は、切替訓練のときに合否を判定できる粒度です。「議事録を要約して決定事項を抽出する」なら判定できますが、「文章をいい感じにする」では判定できません。判定可能な役割定義は、そのままプロンプトの品質向上にもつながります。

抽象化には副産物もあります。役割ごとに入出力の形式を決めることになるため、モデルを替えたときに「同じ役割を果たせているか」を試験する基準が自然に手に入ります。後述する切替訓練は、この基準があって初めて機械的に実行できます。

設計原則2: フォールバック連鎖 — 同格・格下・ローカルの3段構え

第二原則は、代替先を1つではなく連鎖として持つことです。実務的には3段で考えると整理しやすくなります。

1段目は同格の代替です。同一ベンダー内の別モデル、あるいは他社の同クラスモデルへ切り替え、品質をほぼ保ったまま凌ぎます。6月のケースでは、Fable 5の仕事の多くをOpus 4.8が受け止められました。2段目は格下への縮退です。品質や速度を落としてでも、業務の芯だけは止めない。すべての機能を守ろうとせず、棚卸しで特定した最優先象限だけを守る割り切りが要ります。そして3段目がローカルモデルという最後の保険です。外部供給が全て断たれても、手元のGPUで動く小型モデルなら、最低限の分類・要約・下書きは続けられます。

3段のどこまで備えるかは、事前の合意事項として決めておくべきです。技術チームだけで「品質を落として凌ぐ」と決めても、その品質低下を顧客対応部門や経営が許容できなければ、切替は本番で差し戻されます。縮退時に何を諦めるか——応答の精度か、対応範囲か、処理速度か——を平時に文書で合意しておくことは、フォールバック連鎖の技術構成と同じくらい重要です。避難計画は、避難先の生活水準まで含めて初めて計画と呼べます。

複数ベンダーの併用体制をどう組むかは、Claude vs ChatGPT vs Gemini 三国志比較 (2026-05-24 公開)で詳しく扱いました。あの記事では併用をコスト最適化の文脈で論じましたが、6月以降は同じ構成がそのままAI依存リスクの保険として二重の意味を持ちます。

設計原則3: 切替は訓練されて初めて存在する

第三原則は、最も地味で最も破られやすいものです。避難経路は、避難訓練をして初めて存在すると言えます。設定ファイルに書いてあるだけのフォールバック先は、本番の切迫の中ではしばしば動きません。

訓練の内容は大げさでなくて構いません。四半期に一度、フォールバック先へ意図的に切り替えて1日運用してみる。プロンプトが代替モデルでも意図どおり機能するかを確認し、出力形式の崩れを検出するテストを回す。切替の所要時間と品質低下の幅を記録しておく。これだけで、「いざというとき動く保険」と「書いてあるだけの保険」の差が生まれます。

プロンプトの可搬性は特に見落とされがちです。特定モデルの癖に最適化しすぎた指示は、代替先で急に精度を失うことがあります。中核業務のプロンプトについては、主力モデルと1段目の代替の両方で定期的に動作確認しておくと、切替時の品質の崖を大幅に緩和できます。

訓練を仕組みにする方法として、クラウド運用の世界で定着した「ゲームデー」の考え方がそのまま流用できます。あらかじめ日程を決め、関係者を集め、想定シナリオ——今回なら「主力モデルが今朝から使えない」——を宣言して、実際にフォールバック手順を走らせる。うまくいかなかった箇所は責めずに記録し、設計の修正項目に変換する。訓練の目的は合格ではなく、失敗の在庫を平時に消化しておくことです。6月の実例が生々しいうちに初回を実施すれば、参加者の本気度も自然と高くなります。

ツールの現在地 — 公式機能だけでもここまで組める

幸い、2026年7月時点では、フォールバックの土台をベンダー公式機能だけで組めるようになっています。

Claude APIには、リクエストに fallbacks パラメータを付けておくとサーバー側が代替モデルで自動リトライする仕組みがベータ提供されています（Claude APIとClaude Platform on AWS）。Fable 5の安全分類器による拒否にはstop_reason: refusalという明示的な応答形式が定義され、拒否されたリクエストは出力生成前なら課金されません。切替に伴うプロンプトキャッシュ費用を相殺するfallback creditまで用意されています。

導入したら、フォールバックの発動を数える仕組みも添えてください。どの役割で、どの頻度で、どの段まで落ちたか。この記録は依存地図の実測データそのものであり、次の四半期にどこへ投資すべきかを教えてくれます。発動がゼロのまま続くならそれ自体が健全性の証明になり、監査や経営への説明資料としても機能します。

開発環境側では、Claude CodeのfallbackModel設定が最大3つの代替モデルを順に試します。日常のコーディング作業なら、この一行の設定だけでモデル供給の突発事象からかなりの程度守られます。API側のfallbacksとClaude Code側のfallbackModelは別の機能ですが、思想は同じです。切替をアプリケーションの責務から、プラットフォームの標準機能へ下ろしていく流れは、この事件を経てさらに加速すると見てよいでしょう。

個人と小さなチームは何をすべきか

ここまでの原則は組織規模を問わず縮尺を変えて適用できますが、個人や数人のチームなら、優先順位はさらに絞れます。

最初の一手は、主力ツールのフォールバック設定を今日入れることです。Claude CodeならfallbackModelの一行で済みます。次に、決定的に重要なプロンプトとワークフローの記録を、特定ツールの外——プレーンなテキストやリポジトリ——に持っておくこと。資産がツール内に閉じているほど、乗り換えの自由度は下がります。

3段目の保険であるローカルモデルも、個人にとっては現実的な選択肢になっています。消費者向けGPUで動く量子化済みの小型モデルでも、分類・要約・下書きといった縮退運転には十分実用になります。重要なのは平時に一度動かして、自分の用途でどこまで務まるかを把握しておくことです。停止が起きてからローカル環境を構築するのでは、保険になりません。

当サイトの読者に多いメイカー層であれば、設計プロンプトやパラメトリックCADのコード資産がこれに当たります。モデルが替わっても、蓄積した設計意図の記述はそのまま次のモデルへの指示になります。AI依存リスクへの最良の保険は、実は「AIに渡してきた知識を自分の手元にも残しておくこと」だったりします。

まとめ — 「止まらないAI」ではなく「止まっても続く仕事」

6月の停止事件から引き出すべき結論を並べます。第一に、AI供給は政策の変数になり、SLAの外側のリスクとして管理対象に加える必要があります。第二に、対策の骨格は棚卸し・抽象化・フォールバック連鎖・切替訓練という古典的な継続性設計であり、新奇な技術は要りません。第三に、公式のfallbacksやfallbackModelといった道具立てが既に揃っており、着手のハードルはかつてなく低くなっています。

着手の順序も提案しておきます。最初の1週間で依存の棚卸しと4象限の地図づくり。最初の1ヶ月で最優先象限の抽象化レイヤ導入と、fallbacksやfallbackModelといった公式フォールバック機能の設定。最初の四半期のうちに、1段目の代替への切替訓練を一度。この3ステップだけで、6月と同型の事件が再来したときの被害曲線は別物になります。

AI依存リスクは、AIを使わない理由にはなりません。電力への依存をやめた組織が競争に勝てないのと同じです。問うべきは依存するか否かではなく、依存の形を自分で設計できているか否かです。設計されていない依存だけが、リスクの名に値します。6月12日の朝を「他社の災難」で終わらせるか、「自社の設計を変えた日」にするかは、ここからの数週間の動き方で決まります。

主要出典:

#AIインフラ #AI依存リスク #Anthropic #BCP #Claude Fable 5 #フォールバック

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】