Claude Fable 5の公開(2026年6月9日)に合わせて、Anthropicが一つの事例を発表しました。決済サービスのStripeが、5,000万行のRubyコードの更改(マイグレーション)をFableで実行し、チーム全体で2か月以上かかる作業を、1日で終えた。動いているコードを、止めずに、生きたまま書き換えた、という事例です。
MicrosoftのCEO、サティア・ナデラが2024年12月のポッドキャストで言っています——「業務アプリケーションは、本質的には、ビジネスロジックを載せたCRUDデータベース(作成・読取・更新・削除)にすぎない」。その通りです。そしてFableは、ビジネスロジックを載せたCRUDデータベースを、一瞬で完璧に書けるようになりました。
なぜ完璧と言えるのか。Fableは、書いて終わりにしません。自分で実行して、確かめて、合わなければ直して、また確かめる——この繰り返しを、機械の速さで何万回でも続けます。必要なのは、答え合わせの相手だけ。そして業務システムには、答え合わせの相手が必ずいます。いま動いている現行システムです。 新しく書いた処理に同じ入力を流して、現行の結果と見比べればいい。正解は、隣で毎日動いています。
Stripe のコードは整備されていてAIが扱いやすいので、そのまま書き換えさせた。ここで扱う古い基幹システムはそうではないので、動かしたまま新しい側を作り、同じ入力で結果を見比べて一本ずつ入れ替える。基本は同じ——Fable が「書いて・確かめて・直す」を機械の速さで繰り返せるからです。
Fableに渡すものは、四つ
では、新しい側を作るために、Fableに何を渡すのか。四つで足ります。
テーブル定義。入力。出力。マニュアル。
データベースの形。入ってきたデータ。出ていった帳票や画面。業務の決まりを書いた文書。——どの会社にも、すでにあります。マニュアルには、決め事が日本語で書いてあります。足りない決め事は、Fableに「決めておくべきことを、私に質問してください」と言えば、聞き出してくれます。答えるのは、業務を知っている現場の人です。
現行のコードは、読む必要がありません。コードは、置いておく。
簡単なところから始める
業務システムの中身は、難しさで三つに分けられます。
一番簡単なのは、読むだけの処理です。帳票を出すバッチ。一覧や検索の画面。データベースを変えないので、失敗しても何も壊れません。読み取り専用でつないで、今日から始められます。ベンダーに修正を頼めば数週間と数十万円かかる帳票が、Fableとなら当日できます。
次が、一つの表に書くだけの処理。顧客マスタの登録のような仕事です。本番のデータベースをコピーして、その上で作ればいい。自分の会社のデータを自分で使うだけなので、誰の許可も要りません。
難しいのは、複数の表にまたがる処理だけです。受注を書いて、在庫を引いて、売掛を立てる——ここは実装が難しくなります。ただし、画面の数で言えば、ここはシステムの一部です。簡単な層で道具に慣れてから向かえば、一人でもできなくはない高さです。
大規模な基幹システムも、同じです。順番に剥がしていけば、問題ありません。大規模に見えても、中でやっていることは——画面で受けて、データベースに読み書きして、集計して、帳票を出す——そんなに複雑なことではないからです。ナデラの言う通り、ビジネスロジックを載せたCRUDデータベース。複雑だったのは業務ではなく、作り方のほうでした。一本ずつ剥がせば、一本ずつは簡単な仕事です。
なお、メール送信や決済、外部システムとの連携など、外に向かって何かを送る処理は、最後でかまいません。 当分、現行のまま動かしておけばいい。新しい側が記録した結果を、現行がいままで通り読んで送る——共有しているのはデータベースなので、新旧は自然に共存できます。急ぐ必要は、どこにもありません。
答え合わせは、見比べるだけ
検算のやり方も単純です。新しく書いた処理に同じ入力を流して、現行の結果と見比べる。 システム全体を二重に動かす話ではありません。確かめたい一本ごとに、手元で流して、見比べるだけです。現行側には何もしません。毎日の入力をそのまま使えば、毎日が実物大のテストになります。テストデータを作る必要はありません。
待つ必要もありません。業務システムは、過去の入力とデータベースを何年分も保存しています。去年一年分を流し直せば、月末も、締めも、特例の顧客も、一晩で検算できます。
違いが出たところだけ、現場の人が見ます。新しい側の間違いか、聞いていなかった決まりか、昔からのバグか——どれでも収穫です。正しいかどうかを判定できるのは、業務を知っている人だけ。日本の現場は、突き合わせと確認が昔から得意です。
JavaやC#のままでは、Fableの力が出ません
「いまのJavaやC#のまま、Fableを使えばいいのでは」と思うかもしれません。それではFableの力が出ません。共通クラスと、JRE/.NETという巨大な部品で、全部が繋がっているからです。Fableの強さは、書いて、確かめて、直して、また確かめる——この繰り返しです。繋がった環境では、やり直すたびに全体を読み直すことになり、直せば影響が全体に波及します。そして、巨大な部品から正しい使い方を調べる時間は、もう書く時間より長い。
繋がりの中心にいるのが、SQLを隠す道具です。名前があります。JavaのHibernate、.NETのEntity Framework Core。売り文句は共通化でした——「どのデータベースでも同じコードで動きます」。現実は逆です。本命の組み合わせ(HibernateならOracle Database、EF CoreならSQL Server)だけが快適に動き、他のデータベースを選ぶと、細かい不具合と非効率に悩まされる。動くけれど、使いづらい。そして使いづらさは、選んだデータベースのせいにされる。共通化を売りながら、現実には他のデータベースを排除する——禁止するより巧妙な、独占の道具でした。
答えは単純です。隠されていた共通語を、取り戻す。処理は、SQLで独立させて、生で書く。 月次の集計なら、SQLと数十行——一つのファイルで完結します。コードも部品も共有しない。共有するのはデータベースだけ。SQLはFableが非常に得意で、日本語で頼めば複雑な集計でも正確に書き、間違いは自分で実行して自分で直します。人間は、出てきた数字を既存の帳票と一度見比べるだけです。
こうすれば、一つの業務処理が一つのファイルになります。Fableに渡すのは、テーブル定義とそのファイルだけ。直したときの影響も、そのファイルの中だけで収まります。一つのファイルを見れば、その処理の全部が分かる——外の巨大な部品を読みに行く必要がありません。共通クラスも、ORMも、巨大な部品も——SQLとあなたの間に挟まった中間の翻訳でした。中間翻訳をやめる。 AI時代には、これが一番重要です。
道具は小さく
言語は、Rubyを勧めます。
Pythonではないのか、と思うかもしれません。Pythonは良い言語ですが、業務システムには道具が多すぎます。業務システムの仕事——画面で受けて、データベースに読み書きする——は、Rubyで全部対応できます。そしてRubyはシンプルです。書き方が一通りに揃っていて、Fableが迷いません。速さも心配要りません——重い計算はデータベースのSQLがやるからです。
JavaやC#からRubyへ、と聞くと不安になると思います。実績で答えられます。Stripeは、世界の決済を15年、Rubyで回してきました。 5,000万行——日本の大きな基幹システムに劣らない規模です。その規模で動き続けていて、しかもFableが1日で更改できることまで、今回証明されました。小さな言語に乗り換えるのではありません。世界最大級の実績のある言語に、乗り換えるのです。
フレームワークはSinatra。ルートと処理を書くだけの、小さくて、2007年からほとんど変わっていない道具です。書き方が一つしかないので、Fableの出力が安定します。
Ruby + Sinatra + 生のSQL。 一本の処理を、一つのファイルに、SQLで書く。処理同士を共通クラスで繋がない。繋がっていなければ、一本ずつ作れて、一本ずつ検算できて、一本ずつ差し替えられます。逆に、共通クラスで繋がったシステムは、一本だけ替えることができません。全部を一度に切り替えるしかない——「切り替えの日」の恐怖は、共通クラスが作っていたのです。
結論
まずは、帳票や照会画面の修正からです。業者に発注すれば、見積もりと稟議で数週間、数十万円。Fableなら、当日です。読むだけの処理は、失敗しても何も壊れません。次の修正は、発注せずに、Fableにやらせましょう。今すぐに。業者に発注するのは、もう金の無駄遣いです。
やることを一行で言えば、こうです。システムを止めないで、更新する。 Fableにコードを書かせて、現行と見比べて、合ったものから替えていく。現行は最後まで動き続けるので、「切り替えの日」の恐怖がありません。処理を止めずにサーバーを一台ずつ入れ替える——インフラの現場で誰もがやってきた、当たり前の手順です。同じことを、処理の一本ずつでやるだけです。替えた後に間違いが見つかっても、心配は要りません。Fableに伝えれば、修正はすぐです。処理は一本ずつ独立しているので、影響もその一本に閉じています。
材料は、全部あります。やり方は、見比べるだけ。道具は、小さい。残っているのは、始めることだけです。
始めない場合の値段も、書いておきます。毎年払っている保守・運用の委託料の額を、見てください。年間数百万円——大きな会社なら、数億円。同じ仕事が、社内で、当日できるようになりました。来年も再来年も同じ額を払い続けるなら、それは全額、無駄です。それを放置していたら、説明のつかない支出になります。会社なら株主代表訴訟、自治体なら住民監査請求の対象になり得ます。
Ruby + Sinatra だったら、できます。
なお、言語はこだわる場所ではありません。Pythonが得意な人であれば、Python + FastAPIで開発しても問題ありません。システムはRubyで作って、データ分析が必要な場合だけPythonを使うことも問題ありません。大事なのは言語ではなく、作り方のほうです——処理を独立させ、SQLを生で書き、止めないで更新する。