Claude Fable 5 が公開されました（2026年6月9日）。能力は、これまでと桁が違います。
身近なところでは——開発・運用している aiseed.dev のサイトのデザインを Fable に修正させたところ、素人が作ったデザインとは見えないものになりました。まだ、プロレベルではありませんが。
公開に合わせて Anthropic が出した事例では、決済の Stripe が、5,000万行の Ruby コードの更改、チームで2か月以上かかる作業を、1日で終えたとされています。動いているコードを、止めずに、生きたまま書き換えた、という事例です。
残念なことに、その Fable が、急に使えなくなりました。
急に使えなくなった理由
その能力の高さゆえに、米国政府が Fable／Mythos を止めたからです。理由は、語られています。
"The model needs to remain locked down until the U.S. government's national security apparatus is hardened, the official said, adding that could happen in the next few weeks."（Axios）
これは告白だ
止めた理由を、自分たちの基盤がまだ固まっていないから、と認めている。脅威はモデルではなく、自分たちの足元にある。能力の高いモデルが、その脆い基盤を「数週間で固める」までは出せない、と言っているわけです。逆に言えば、基盤さえ固ければ止める必要はなかった。
だとすれば、やるべきことは決まっています。
Anthropic を叩くより、ゼロトラストを完了せよ
Anthropic を叩くよりも、zero-trust 戦略（2021年の EO 以降）が完了できていない機関は至急完了せよです。そうなると Entra ID が使えない。
2021年の大統領令（EO 14028）から、米国政府はゼロトラストへの移行を自分で義務づけてきました。OMB の M-22-09 が定めた期限はすでに過ぎています。やるべき宿題は、外から脅かされて新しく現れたものではなく、自分で課して、まだ終えていないものです。
なぜ本物のゼロトラストは Entra ID を外すことになるのか
本物の zero-trust は、信頼の根（trust root）を自分で制御・監査することを要求します。「暗黙の信頼を置かない、すべてを検証する」が原則です。
ところが Entra ID は、その根を単一の閉鎖ベンダに委ねる構成です。署名鍵もトークン発行も、自分では監査できないクラウドの中にある。これは、ネットワーク境界の暗黙信頼を消すと言いながら、その暗黙信頼を一社のクラウドへ移しただけ、とも言えます。
これは理論ではありません。2023年の Storm-0558 は、盗まれた一本の署名鍵が、22の組織（米国務省・商務省を含む）を同時に貫けることを実証しました。CSRB（米サイバー安全審査委員会）は、この侵害を「防げたはずだ」とし、Microsoft のセキュリティ文化を「不十分」と断じ、さらに Microsoft 自身が鍵の盗まれ方を特定できていないことを指摘しています。発行元（issuer）でトークンを偽造されると、エンドポイントや MFA をいくら固めても迂回される。IdP の完全性は、端末の対策に優先します。
だから、本気で zero-trust を完了すると、Entra を信頼の根としては使えなくなります。Microsoft が売る「Entra でゼロトラスト」は、周辺の柱（デバイス・ネットワーク・MFA）を固めつつ、最も壊滅的な根を、監査不能なベンダのブラックボックスのまま残す構成です。
補足: 「Entra ID が使えない」は「Microsoft 製品に一切触れない」という意味ではありません。単一の閉鎖ベンダの監査不能な root を、唯一の信頼の根として使う構成が、本物のゼロトラストと両立しない、という意味です。サードパーティ IdP でも、単一ベンダの監査不能な root なら同じ問題を抱えます。論点は製品名ではなく、root の主権です。
交点に現れるもの：業務システムの自社開発
そして、Fable の能力と、ベンダの中間層を外すという方向が交わるところに見えてくるのが——業務システムの自社開発です。
Microsoft の CEO サティア・ナデラ自身が言っています。業務アプリケーションは、本質的にはビジネスロジックを載せた CRUD データベースにすぎない、と。そして Fable は、その CRUD を、検証込みで作れるようになりました。
方法：現行システムを「正解器」にする
Fable は、書いて終わりにしません。自分で実行して、確かめて、合わなければ直して、また確かめる——これを機械の速さで何万回でも回します。必要なのは答え合わせの相手だけ。そして業務システムには、答え合わせの相手が必ずいます。いま動いている現行システムです。
新しく書いた処理に同じ入力を流して、現行の結果と見比べる。Fable に渡すものは、四つで足ります。
- テーブル定義
- 入力
- 出力（帳票・画面）
- マニュアル（業務の決め事）
現行のコードは、読む必要がありません。難しさで分ければ、進め方も決まります。
- 読むだけの処理（帳票バッチ、一覧・検索）。DB を変えないので、失敗しても壊れない。読み取り専用でつないで当日から始められる。
- 一つの表に書くだけの処理（マスタ登録など）。本番 DB をコピーした上で作る。
- 複数の表にまたがる処理（受注→在庫引き当て→売掛）。ここだけが本当に難しい。簡単な層で道具に慣れてから向かう。
検算は単純です。確かめたい一本ごとに、同じ入力を流して現行と見比べるだけ。現行側には何もしません。業務システムは過去の入力と DB を何年分も保存しているので、去年一年分を流し直せば、月末も締めも特例も一晩で検算できます。違いが出たところだけ、業務を知っている人が見る。新しい側の間違いか、聞いていなかった決まりか、昔からのバグか——どれでも収穫です。
メール送信・決済・外部連携など、外へ送る処理は最後で構いません。当分は現行のまま動かし、新しい側が記録した結果を現行が読んで送る。共有しているのは DB なので、新旧は自然に共存します。「切り替えの日」は不要です。
中間翻訳をやめる（ORM・共通クラス・巨大ランタイム）
「いまの Java や C# のまま Fable を使えばいい」と思うかもしれません。それでは力が出ません。共通クラスと、JRE／.NET という巨大な部品で全部が繋がっていて、やり直すたびに全体を読み直し、直せば全体に波及するからです。
繋がりの中心が、SQL を隠す ORM です。Hibernate、Entity Framework Core。売り文句は「どの DB でも同じコードで動く」でしたが、現実には本命の組み合わせ（Hibernate なら Oracle、EF Core なら SQL Server）だけが快適で、他の DB を選ぶと細かい不具合と非効率に悩まされる。動くけれど使いづらく、その使いづらさは選んだ DB のせいにされる。共通化を売りながら、実質的に他の DB を排除する soft lock-in です。
答えは単純です。隠された共通語を取り戻す。処理を SQL で独立させて、生で書く。 一つの業務処理が一つのファイルになり、直したときの影響もそのファイルに閉じる。SQL は Fable が非常に得意で、日本語で頼めば複雑な集計でも書き、間違いは自分で実行して自分で直します。
ここで重要なのは、いわゆる Windows 固有の尾（レガシー .NET、深い SQL Server 依存）が、本質的に Windows に縛られていたのではなく、その中間層（ORM・ランタイム・共通クラス）がそれを固定していた、という点です。中間層を外して生 SQL の独立ファイルにすれば、尾は移植すべき高コストではなく、移植可能・再生成可能・正解器で検証可能なものに変わります。これは、信頼の根から仲介を外すのと同じ「中間翻訳をやめる」を、コード層で行っているにすぎません。
道具は小さく
言語は Ruby を一例として挙げます。書き方が一通りに揃っていて Fable が迷わず、重い計算は DB の SQL がやるので速さも問題になりません。Stripe は世界の決済を15年、5,000万行の Ruby で回してきました。小さな言語ではなく、世界最大級の実績のある言語です。フレームワークは Sinatra。ルートと処理を書くだけの小さな道具で、出力が安定します。
Ruby + Sinatra + 生の SQL。 一本の処理を一つのファイルに、SQL で書く。共通クラスで繋がない。繋がっていないから、一本ずつ作れて、一本ずつ検算できて、一本ずつ差し替えられる。逆に共通クラスで繋がったシステムは、一本だけ替えられない。「切り替えの日」の恐怖は、共通クラスが作っていたものでした。
なお、言語はこだわる場所ではありません。Python が得意なら Python + FastAPI でも構いません。大事なのは言語ではなく、作り方です——処理を独立させ、SQL を生で書き、止めないで更新する。
ベンダー委託から自社開発へ
業務システムの保守は、ベンダー委託から自社開発へ、有利が移ります。
まずは帳票や照会画面の修正から。業者に発注すれば見積もりと稟議で数週間・数十万円かかるものが、Fable なら当日できます。読むだけの処理は失敗しても壊れません。
毎年払っている外注の保守費を、見てください。年間数百万円、大きな組織なら数億円。同じ仕事が、社内で、当日できるようになりました。来年も再来年も同じ額を払い続けるなら、それは無駄です。放置すれば、会社なら株主代表訴訟、自治体なら住民監査請求の対象になり得る支出です。
まとめ
- Fable 5 は公開され、能力は実証された（自サイトの再設計、Stripe の5,000万行を1日）。
- それは即座に停止された。理由として語られたのは「基盤がまだ固まっていない」という告白。
- やるべきは Anthropic を叩くことではなく、2021年の EO 以降のゼロトラスト戦略の完了。本気で完了すれば、Entra ID を唯一の信頼の根としては使えなくなる。
- 同じ「中間を外す」原理を、業務システムのコード層に適用すると、現行を正解器にして・生 SQL で・止めずに作り直す自社開発が成立する。
- 材料は全部ある。やり方は見比べるだけ。道具は小さい。残っているのは、始めることだけです。