WebサイトのAI機能はどこに依存し、どこから壊れるのか―Fable 5、Mythos 5の停止に学ぶ
X-tech推進本部 白何が起きたのか
2026年6月12日、AnthropicのAIモデル「Fable 5」と「Mythos 5」へのアクセスが一時的に停止されました。Fable 5は同月9日にリリースされたばかりのモデルでした。Bloombergの報道によれば、米商務省の命令はすべての外国籍者によるアクセスの即時停止を求めるものでした。しかし、APIリクエストから利用者の国籍を判別することは技術的に困難なため、Anthropicは全ユーザーへの提供停止を選択しました。大規模言語モデル（LLM）への輸出規制の発動は史上初のケースで、Fable 5を指定したAPIリクエストは利用できなくなりました。
命令の背景について、Tom's Hardwareの記事では、政権関係者が、Fable 5のジェイルブレイク（安全機能を迂回する手法）の修正要求をAnthropicが拒否したためだと主張していることが紹介されています。一方、Anthropicは公式声明で、報告されたジェイルブレイクは限定的なものであり、Fable 5だけを規制対象とすることに合理性はないと反論しています。
事実の整理はここまでとして、本稿ではWebサイトにAI機能を組み込む場面を想定し、この事件を「Webサイトはどこで外部AIに依存しうるのか」を確認する機会にします。
WebサイトとAIの接点
まず前提から確認します。情報掲載や問い合わせ導線を中心としたコーポレートサイトであれば、今回のようなモデル停止が起きても直接の影響を受けないケースが多いでしょう。
一方で、WebサイトにAI機能を組み込むには、多くの場合、外部のAIサービスをネットワーク越しに呼び出します。例えばAIチャットボット、AIサイト内検索などは、サイト側の処理だけで完結しません。呼び出し先のモデルやAPIが止まれば、サイト上の機能も止まります。今回の件で見えたのは、この依存関係です。
Webサイトに関わるAI利用の3つのパターン
WebサイトとAIの接点は、大きく3つのパターンに分けられます。
1つ目はSaaS型ウィジェットの埋め込みです。サイトにscriptタグを1行追加すると、チャットボットなどのUIが表示されるタイプです。実際の会話処理はベンダーのサーバーで行われ、そのベンダーはさらに裏側でAnthropicやOpenAIなどのモデルAPIを呼んでいます。つまりサイト→ベンダー→モデルプロバイダーという二段の依存が生まれます。サイト所有者はもちろん、導入に関わった側でも、最終的にどのモデルに依存しているかは把握しづらくなります。
2つ目はモデルAPIとの直接連携です。AIサイト内検索、説明文の動的生成など、WebサイトからモデルAPIを直接呼ぶ実装です。依存は一段ですが、そのぶんモデル停止の影響が機能に直撃します。
3つ目は制作プロセスでのAI利用です。コーディング支援や原稿作成にClaude CodeなどのAIツールを使う形です。ただしこれは制作の時に使うだけで、公開されるサイトには何も残りません。ツールが止まれば制作の効率は落ちますが、納品済みのサイトは壊れません。
この3つを区別すると、リスクの所在がはっきりします。パターン3は制作プロセス上の影響にとどまります。壊れるのはパターン1と2、つまりAI機能がサイトに組み込まれている場合です。しかもパターン1では、自分が何に依存しているかさえ見えにくくなります。
導入前に確認したいこと
この整理を踏まえると、AI機能を導入する時に確認したい観点は大きく3つあります。
1つ目は依存の可視化です。AI機能を提案・導入する際は、それが上記のどのパターンにあたり、依存の連鎖の先にどの事業者とどのモデルがいるのかを確認しておくと、停止した時の影響を説明しやすくなります。scriptタグを1行貼るだけの導入であっても、裏側のモデルまで確認できると影響範囲を判断しやすくなります。過去に導入したツールが、知らないうちにバージョンアップでAI機能を組み込んでいるケースもあるため、運用中のサイトについても、埋め込まれている外部サービスにAI由来のものがないかを確認しておくとよいです。
2つ目は主要動線の分離です。問い合わせ、資料請求、購入、予約といったサイトの主要動線は、AI機能なしでも完結できる設計にしておくと、停止した時の影響を抑えやすくなります。チャットボットはフォームへの近道であって、唯一の窓口にしないほうが安全です。AI機能が応答しない時は、エラーメッセージを表示するのではなくウィジェットごと非表示にし、FAQやフォームといった静的な導線に切り替える方法も考えられます。
3つ目は保守範囲の確認です。外部AIサービスの停止を保守の想定項目に含めるのか、誰が停止を検知し、誰の判断で機能を無効化し、誰がクライアントに連絡するのかを確認しておく必要があります。サーバー障害やCMSの不具合とは違い、外部AIの停止は保守の想定から抜け落ちやすい論点です。
まとめ
一般向けに提供されていたFable 5の停止が示したのは、外部AIサービスに依存する機能は、依存先の都合で止まることがあるという事実です。依存すること自体が悪いのではありません。問題は、その依存が見えないまま組み込まれ、止まった時に何が影響を受けるのか分からない状態になることです。どこに依存があり、止まったら何がどう壊れ、その時誰が何をするのか。AI導入の相談が増えていくなかで、こうした点を説明できる状態にしておくことは、Webサイトの設計・運用における重要な論点になるはずです。