TITLE

Claude Fable 5 復帰──「使えるようになった今」まず整理すべきこと

投稿日：2026.07.02

Fable 5 の基本情報を今一度確認する

Fable 5 は 2026年6月9日に一般提供が開始されたモデルです。Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundry、Claude Platform on AWS、Claude.ai、Claude Code、Claude Cowork で利用できます。

価格は入力100万トークンあたり10ドル、出力100万トークンあたり50ドルです。既定のコンテキストウィンドウは100万トークン、1リクエストあたり最大12.8万トークンの出力に対応します(出典: platform.claude.com のドキュメント)。

もう一つ押さえておきたいのが、Fable 5 の思考の挙動です。adaptive thinking(モデルが自律的に思考の深さを調整する仕組み)が常時オンで、無効化はできません。effort パラメータで思考の深さそのものは調整できますが、思考の過程(chain of thought、モデルが結論に至るまでの推論の記録)自体は生の形では返らず、要約または省略されて出力されます。「考えているはずなのに、その過程が見えない」という前提でログ設計や検証方法を考える必要があります。

停止から復帰までに何があったか

Fable 5 は 2026年6月12日、米国政府による輸出規制の対象になりました。Anthropic の公式発表によれば、理由は Amazon の研究者が安全対策を回避する手法を発見し、その手法を使って Fable 5 にソフトウェアの脆弱性を特定させることができたためです。

この規制は 2026年6月30日に解除が確認され、翌7月1日に世界的な復帰に至りました。復帰にあたって、Anthropic は新しい安全分類器を導入しています。判明していたジェイルブレイク手法を99%以上の確率でブロックする仕様です。

ここで実務上重要なのは、この新しい分類器が善良な利用にも影響しうる、と Anthropic 自身が言及している点です。正当なコーディング作業、セキュリティ関連の作業を含めて、誤って拒否される可能性が増える懸念があるとされています。「拒否が増えるかもしれない」という前提を織り込まずに、Fable 5 を単純に「元の状態に戻ったモデル」として扱うと、想定外のところでリクエストが止まります。

復帰後、実務者がまず確認すべきこと

ここまでの事実を踏まえて、私が「まず先に行うべき」と考える確認は 3 つです。

一つ目は、データ保持要件の確認です。Fable 5 の利用には 30 日間のデータ保持が必須で、ゼロデータ保持(zero data retention、利用データを一切保持しない契約形態)では利用できません。もし自社がこの「ゼロデータ保持」を前提にした契約や業務フローを組んでいる場合、その前提のままでは Fable 5 を組み込めません。ここは技術検証より先に、契約・コンプライアンス側の確認が要る話です。

二つ目は、拒否(refusal)が起きた時にどう受け止めるかの設計です。安全分類器が危険と判定したリクエストは、API では stop_reason: "refusal" を HTTP 200(通常の正常応答と同じステータスコード)として返します。つまり、社内システムが「エラー」としてではなく「正常な応答の一種」として拒否を受け取る前提でハンドリングを組む必要があります。拒否されたリクエスト自体には課金されず、別モデルへ切り替えるフォールバックの余地も用意されています。ただし、実際に自動でフォールバックさせるのか、人が内容を確認してから判断するのかは、自社の運用として決める必要があります。前段で触れた「セキュリティ関連の正当な作業でも誤って拒否されうる」という懸念がある以上、拒否=誤りとは限らないという前提での運用が要ります。

三つ目は、Fable 5 をどこに使うかの絞り込みです。入力$10・出力$50/100万トークンという価格を踏まえると、Fable 5 を日常的な全業務に広げる使い方は前提として無理があります。何に使うかを絞り込んでから導入する方が、コストと運用の両面で現実的です。

自社(Leadeas AI 組織)での見直し例

私たちの組織でも、Fable 5 の復帰を受けてモデル運用ポリシーを見直しました。以下は Anthropic の仕様ではなく、私たちが自社の運用として決めた内容です。

私たちの内部評価では、Fable 5 が停止していた間に他の Claude モデル(Opus 4.8、Sonnet 5)で業務が問題なく回っていました。この経験を踏まえて、復帰後も「頂点モデルとして常時 Fable 5 を使う」方針には戻さないことにしました。新規設計かつ高レバレッジ(誤りのコストが大きい、解の探索範囲が広い、複数チームに影響する)と判断できる局面に限って、単発で起動する運用にしています。

もう一つの見直しが、セキュリティ・脆弱性診断系のタスクには Fable 5 を使わない、という方針の追加です。前段で触れた「正当なセキュリティ作業でも誤って拒否されうる」という懸念への、私たちなりの実務対応です。

三つ目は、Fable 5 を並列実行(fan-out)には使わず、設計や判断が必要な単発の利用に限定するというガードです。複数のタスクを同時に走らせる用途には使わない、という線引きです。

正直に書くと、「拒否が起きた時に自動でフォールバックさせるか、人が確認してから判断するか」という論点は、私たちもまだ決めきれていません。セキュリティ・fan-out の 2 つは即断できましたが、この論点は判断が割れやすく、しばらくは人が確認する運用で様子を見るつもりです。

まとめ:私の判断

各論点を踏まえて、私はこう判断しています。

Fable 5 が復帰したからといって、停止前と同じ使い方に戻すのは早計です。3 つの確認事項のうち、私が最初に手を付けるべきだと考えるのは拒否時の運用設計です。データ保持要件は契約書を確認すれば白黒がつきますが、拒否時の扱いは「たぶん誤検知だろう」と楽観的に流してしまいやすく、運用が固まらないまま本番投入されがちだからです。確認した結果として「今は導入しない」という判断に至ることも、当然あり得る選択肢です。

「使えるようになった」ことと「元通りの使い方に戻す」ことは別の判断です。私自身、まず自社の拒否対応の運用ログを見直すところから始めます。