Claude Fable 5が突然使えなくなりました。
2026年6月13日時点で、Claude StatusにはFable 5とMythos 5のアクセス停止に関する案内が出ています。
このニュース自体も大きいのですが、AIを使って開発をしている立場から見ると、別の意味でかなり考えさせられます。
高性能なAIモデルは、開発やバグチェックの質を一段引き上げてくれます。
しかし、そのモデルが明日も同じように使えるとは限りません。
AI開発では、どのモデルを使うかだけでなく、「そのモデルが使えなくなったときに、仕事を止めない設計」も必要になってきたと感じます。
Fable 5は、レビュー担当としてかなり強かった
最近、Claude Codeでデスクトップアプリの開発や、WordPressプラグイン開発のバグチェックを行っていました。
特に、Codexで開発しているWordPressのAIチャットボットプラグインをFable 5に見てもらうと、かなり細かい指摘が出てきました。
管理画面の権限チェック。
入力値の扱い。
ログの持ち方。
エラー時の挙動。
cronや自動更新まわりの確認。
通常のチャットでは見落としやすいような観点まで拾ってくれる感覚がありました。
もちろん、AIの指摘がすべて正しいわけではありません。
それでも、「ここは確認しておいた方がいい」という観点を大量に出してくれるだけで、開発者にとってはかなり助かります。
AIをコード生成に使うだけでなく、レビュー担当として使う価値を強く感じたところでした。
AIモデルによって、見つけるバグが違う
今回あらためて感じたのは、AIモデルによって見えているものがかなり違うということです。
同じソースコードを渡しても、あるモデルはセキュリティ面をよく見ます。
別のモデルは、UIや文章の違和感を拾います。
また別のモデルは、実装方針や設計上の矛盾を指摘します。
今回の用途では、Fable 5のバグチェックはかなり相性が良く感じました。
一方で、ほかのモデルでは同じレベルの指摘が出てこない場面もありました。
これは、そのモデルが悪いという話ではありません。
AIにも得意不得意があり、コードレビュー、仕様確認、文章校正、調査、UI改善では、向いているモデルが変わるということです。
人間でも、デザイナー、エンジニア、保守担当、運用担当では見る場所が違います。
AIも同じように、複数の視点を組み合わせた方が強くなります。
高性能モデルを前提にした工程は止まりやすい
問題は、優秀なモデルほど頼りたくなることです。
このモデルなら、最後のバグチェックを任せられる。
このモデルなら、リリース前の確認に使える。
このモデルなら、プラグインの弱いところを見つけてくれる。
そう感じたタイミングで、そのモデルが突然使えなくなると、工程そのものが止まります。
AIサービスは、こちらの都合だけで動いているわけではありません。
仕様変更、提供範囲の変更、アクセス制限、障害、法的な事情、料金プランの変更など、さまざまな理由で使えなくなる可能性があります。
これはClaudeに限った話ではありません。
ChatGPTでも、Geminiでも、その他のAIサービスでも同じです。
高性能AIを使うほど、便利さと同時に依存リスクも大きくなります。
指摘は、その場で消費せずチェックリスト化する
では、どうすればよいのか。
ひとつは、AIから出てきた良い指摘を、その場限りで終わらせないことです。
たとえば、Fable 5がプラグインのバグチェックで良い指摘を出してくれたなら、それを次のような形で残します。
- WordPressプラグイン用のレビュー観点
- 管理画面の権限チェック項目
- REST APIやAjax処理の確認項目
- 入力値のサニタイズと出力時のエスケープの確認項目
- cronや自動更新処理の確認項目
- ログ、個人情報、エラー表示の確認項目
- アンインストール時に消すデータ、残すデータの判断項目
- リリース前に人間が見る最終チェック項目
こうしておけば、特定のモデルが使えなくなっても、モデルが見ていた観点の一部は残ります。
強いAIモデルを使う価値は、単にその場で答えをもらうことだけではありません。
良いレビュー観点を自社のチェックリストに変換して、次回以降も使える資産にすることが大事です。
AIレビューは、複数モデルで分担する
もうひとつは、最初から複数モデルを前提にすることです。
たとえば、開発工程を次のように分けます。
| 役割 | 使い方 |
|---|---|
| 実装担当 | CodexやClaude Codeで、仕様に沿って実装を進める |
| 調査担当 | Geminiや検索系AIで、既知の問題や仕様変更を調べる |
| レビュー担当 | Claude、ChatGPT、Geminiなど複数モデルでコードや仕様を確認する |
| 最終判断 | AIの指摘を人間が読み、必要なものだけ採用する |
どれか1つのAIに全てを任せるのではなく、得意な仕事を分担させるイメージです。
これは少し手間が増えます。
しかし、開発や保守のように失敗すると困る仕事では、1つのAIの見落としを別のAIで補う価値があります。
AIはとても便利ですが、最終的な責任を持つのは人間です。
そのためにも、AIの意見を複数並べて、どれを採用するか判断できる状態にしておく必要があります。
WordPressプラグイン開発では、AIに見せる観点を決めておく
WordPressプラグインの場合、AIにざっくり「バグを探して」と頼むだけでは不十分です。
特に見てほしい観点を指定した方が、指摘の質が上がります。
- 管理画面で、適切な権限チェックが入っているか
- nonce確認が必要な処理に入っているか
- 保存する値をサニタイズしているか
- 画面に出す値をエスケープしているか
- REST APIやAjaxの入口が開きすぎていないか
- cron処理が重くなりすぎないか
- 外部APIの失敗時に、画面やログが破綻しないか
- APIキーや個人情報がログに残らないか
- アンインストール時のデータ削除方針が明確か
- PHPバージョンやWordPress本体の互換性を考慮しているか
こうした観点は、モデルが変わっても使えます。
Fable 5が使えないなら、別のAIに同じ観点でチェックさせればよい。
そのためには、優秀なモデルに丸投げするのではなく、こちら側がレビュー項目を持っておくことが重要です。
使えなくなったときの代替手段を用意する
高性能モデルが使えなくなったときは、慌てて同じ品質の代替モデルを探したくなります。
しかし、完全に同じAIはありません。
まずやるべきことは、工程を分解することです。
- 仕様の読み直し
- 既知の問題の調査
- コードの静的チェック
- セキュリティ観点のレビュー
- UIと文言の確認
- 実機テスト
- ログとエラー処理の確認
このように分けると、1つのモデルで全てを置き換えなくてもよくなります。
あるAIには調査を任せる。
別のAIにはコードレビューを任せる。
人間は実際の操作と判断を担当する。
この形にしておけば、特定のモデルが止まっても、開発全体は止まりにくくなります。
AI開発は、モデル選びより工程設計が大事になる
今回の件で感じたのは、AI開発ではモデル選びだけでなく、工程設計が大事になるということです。
もちろん、性能の高いモデルは魅力的です。
バグを見つける力が強いモデル。
長いコードを読めるモデル。
仕様の矛盾を見つけるモデル。
こうしたAIを使えることは、開発者にとって大きな武器になります。
しかし、それを前提にしすぎると、そのAIが使えなくなった瞬間に弱くなります。
大事なのは、強いAIを使いながら、そのAIの見方を自社のチェックリストや開発手順に落とし込むことです。
AIの能力を借りる。
ただし、AIに工程そのものを預けきらない。
これが、これからのAI開発でかなり重要になると思います。
Fable 5が突然使えなくなったことは困った出来事でした。
ただ、AIを使った開発フローを見直すきっかけとしては、かなり大きかったと思います。
