Claude Fable 5の活用事例100件を集計するとコード43%・UI26%に偏る。その理由を検証可能報酬(RLVR)の学習原理から解き、CLAUDE.md・ハーネス・会社OSという上流設計と中小企業の回収算術まで、実務に降ろして解剖する。
新しいAIモデルの公式発表を読むと「すごそう」までは分かるが、自分の仕事や会社の業務にどう関係するかは見えない——この距離を埋めるために、ある実務者がClaude Fable 5の活用事例100件を公式発表とX(旧Twitter)の日本・海外投稿から集め、スプレッドシートに構造化して無料公開した。AIで収集したため事実確認は必須という注記付きの、生のデータセットである。本稿はこの100件を一次資料として、分布の偏りがなぜ生じるのかをAIの学習原理(検証可能報酬)から説明し、「デモがすごい」と「仕事が楽になる」を分かつ境界線を、CLAUDE.mdとハーネスという実装の単位まで降りて解剖する。集計が示す最大の発見は、モデルの性能ではなく、導入する側の設計力が成果を決めるという身も蓋もない事実だ。
43%がコードに集中する学習理論上の必然
100件の分布を先に示す。集計の生データは次の通りである。
| 順位 | カテゴリ | 件数 | 構成比 |
|---|---|---|---|
| 1 | コーディング/開発 | 43件 | 43% |
| 2 | UI/視覚/プロトタイプ | 26件 | 26% |
| 3 | AIエージェント/自動化 | 9件 | 9% |
| 4 | 文書/知識作業 | 6件 | 6% |
| 5 | 研究/生命科学 | 6件 | 6% |
| 6 | 分析/金融/スプレッドシート | 6件 | 6% |
| 7 | セキュリティ/サイバー防御 | 3件 | 3% |
| 8 | 法務/契約 | 1件 | 1% |
最大カテゴリはコーディング/開発の43件だった。代表例は、Stripeの大規模Rubyコードベース移行——5,000万行のコードに対し、従来ならエンジニアチームで2カ月超かかる全面移行を1日で完了させた(Anthropic、2026年6月)——、GitHubやCursorでの長期コーディング作業、Claude Codeとの組み合わせ、リファクタリング、アプリ開発、Minecraft風クローンの作成、OpenClawへの対応などである。CursorのCEOミハエル・トルエルは「Fable 5はCursorBenchで最高性能」と公言した。
コードに事例が偏るのは流行ではなく、学習理論上の必然である。鍵はRLVR(検証可能報酬による強化学習)という訓練手法にある。従来のRLHFが「人間がどちらの回答を好むか」という主観的で高コストな信号に頼るのに対し、RLVRは単体テストの合否という決定論的な信号を報酬にする。コードは書かせて、走らせて、テストが通れば報酬1、落ちれば0——同じ入力には常に同じ報酬が返り、人間のラベル付けが要らない。この「自動採点できる領域」では強化学習が高速に回るため、モデルの能力はコード・数学・形式検証可能なタスクから先に伸びる。事例の43%がコードなのは、ユーザーの好みの反映である以上に、モデルが実際にそこで一番強くなっているからだ。逆に言えば、自動採点器が存在しない業務——交渉、企画、感情労働——では、同じ速度の改善を期待してはいけない。この非対称が、本稿全体を貫く第一原理になる。
26%のUI事例が「Xで伸びる」視覚の経済
第2位は視覚理解/UI/プロトタイプの26件。スクリーンショットからWebアプリを再構築する、UIをワンショットで生成する、3D表現やインタラクティブなアプリを作る、PDF・図表・チャート・画面を読ませる、といった事例群である。見た瞬間に「すごい」と伝わり、Xで最も拡散しやすいのもこの領域だ。文章生成より、アプリやUIや動画のほうが変化が一瞬で伝わる。
技術的には、画像をパッチ(小区画)に分割してトークン列に変換し、テキストと同じTransformerの注意機構で統合処理するマルチモーダル構造が土台にある。スクリーンショット→アプリ再構築とは、視覚トークンからレイアウト・階層・配色という構造を抽出し、それをコードという別の記号系へ翻訳する作業であり、43%のコード能力と26%の視覚能力は実は同じ幹から伸びた枝である。ただし、ここに集計者自身が置いた重要な但し書きがある。見た目が派手なものほど、業務改善とは別の話になりやすい。すごいデモが作れることと、会社の毎日の仕事が改善されることは同じではない——この線引きが、100件を「すごい」で終わらせないための分水嶺になる。
エージェント9件が突きつける「任せ方」の工学
AIエージェント/業務自動化は9件にとどまった。公式では長期エージェント作業、Managed Agents、Claude Code、Factorio(工場建設ゲーム)やSlay the Spire(カードゲーム)のような長時間タスクの攻略が示され、XではFable 5をオーケストレーター(指揮者)として使い、Codexと組み合わせ、複数ツールを触らせる構成が報告されている。Fable 5はエージェントハーネスの中で数日単位の連続稼働ができ、自分で計画を立て、進捗を目標と照合し、作業を修正しながら進む(Anthropic、2026年6月)。
件数が少ないのは能力不足ではなく、受け入れ側の工学が追いついていないからだ。集計者の言葉を借りれば、Fable 5の価値は「回答がうまい」ではなく「任せられる仕事のサイズが少し大きくなる」ことにある。調べる、分ける、作る、直す、確認する、次へ進む——この一連の流れを持たせられる。しかしエージェントに任せるには、会社側が仕事を分解できていなければならない。何を見てよいか、何を触ってよいか、どこで人間が確認するか、失敗したらどこまで戻るか。ここが曖昧なまま「AIエージェントすごい」と言っても現場では止まる。強いモデルほどプロンプトだけでは足りず、コンテキスト・ハーネス・権限・ログ・レビューの設計が要る。モデルの知能が上がるほど人間の仕事は減るのではなく、設計責任が露出する。当サイトが先に解剖したClaude Codeの権限モデル(settings.jsonのdeny→ask→allow評価、PreToolUseフック、guard.shによる決定論的ブロック)は、まさにこの「任せ方の工学」の実装例である。
地味な17%にこそ実務がある ― 検証の非対称性
分析/金融/スプレッドシートが6件、文書/知識作業が6件、研究/生命科学が6件、セキュリティ/サイバー防御が3件、法務/契約が1件。派手さは開発やUIに劣るが、会社の実務に近いのはむしろこちらだ。スプレッドシートの整理、資料の読み込み、契約書の下読み、調査レポートの作成、会議メモからの論点抽出、大量情報からの仮説出し——毎日コードを書く会社ばかりではないが、この種の仕事はどの会社にもある。
ではなぜ事例が少ないのか。検証の非対称性で説明できる。コードは動かせば分かり、UIは見れば分かる。だが法務・分析・調査の出力は、気づかないズレが自然な文章に包まれて出てくる。RLVRの言葉で言い直せば、自動採点器が無い領域では訓練信号も弱く、利用者側の検証コストも高い——生成は一瞬、検証は重労働という生成・検証コストの逆転が起きる。だからこの領域の正しい使い方は「全部任せる」ではない。AIに下読み・整理・比較・初稿を任せ、人間が最終判断・数字の確認・リスクの確認・公開前レビューを担う。セキュリティ事例が3件と少ない背景には、Fable 5がサイバー・生物の高リスク領域に新たな出力遮断を実装したという供給側の安全設計もある(Anthropic、2026年6月)。少なさは弱さではなく、領域ごとの「確認の難しさ」と「安全弁」の写像なのだ。
会社OSの設計 ― CLAUDE.mdは入社初日の教科書である
事例群は開発・UI/視覚・エージェント・文書/分析の4用途に束ねられ、それをコンテキスト・ハーネス・ログ・人の判断という4つの設計層が受け止め、組み上がった全体が「会社OS」になる。人の判断からは事例側への還流ループが伸びる——使った結果が次の設計を育てる構造である。整理すると次の通りだ。
| 流れ | 要素 | 役割 |
|---|---|---|
| 入力 | 事例100選 | 収集した活用事例の母集団 |
| 用途の束 | 開発/UI・視覚/エージェント/文書・分析 | 100件が集約される4用途 |
| 設計層 | コンテキスト | AIに渡す会社の前提・判断基準 |
| 設計層 | ハーネス | 実行環境と安全柵(権限・停止条件) |
| 設計層 | ログ | 判断の記録と失敗時の巻き戻し |
| 設計層 | 人の判断 | 確認ポイント。事例側への還流起点 |
| 出力 | 会社OS | 4設計層が組み上がる組織基盤 |
集計者が経営者として実践する手順は、単発の業務改善ではなく上流からの組み替えである。どの業務にAIを入れるか、どの情報を渡すか、どの判断を人間に残すか、どこまで自律実行させるか、失敗時にどのログを見て戻るか——これを先に決める。第一の柱がCLAUDE.md(コンテキストファイル)だ。これは注意書きではなく、AIにとっての会社の前提・判断基準・禁止事項・役割・仕事の進め方を記す場所——人間で言えば入社初日のオンボーディング資料、業務マニュアル、上司の口癖、権限表、過去の失敗例集に相当する。ここが薄いまま強いモデルを入れても、AIは「賢い一般人」のままで、会社の文脈を持ったメンバーにはならない。書き込むべき項目は具体的である。
- 任せてよい判断と任せてはいけない判断/顧客・財務・人事情報の扱い/成果物を出す前の確認ルール
- Google Drive・Docs・Sheets・Gmail・Slackなど外部サービスの操作ルール/記事・提案書・スプレッドシート・コードなど成果物ごとの品質ゲート
- 人間に確認を戻す条件/ログに残す判断と残さなくていい作業/AI担当ごとの役割分担/過去に同じ失敗をした時の修正ルール
第二の柱がハーネス(実行環境と安全柵)である。どのツールを使えるか、どのコマンドは止めるか、どの操作はログを残すか、どこまで並列実行してよいか。ここが整っていないと、強いモデルを入れても毎回「その場の頑張り」になる。逆に整えば、AIは単発回答ではなく業務フローの中で動く。今回の100選自体がその実演で、X APIで収集し、公式ソースと分け、シートに構造化し、URLをリンク化し、ジャンル別に集計し、記事化し、noteやXへ展開する——この流れを手作業ではなく運用として育てている。便利な使い方を1つ覚えることではなく、会社の仕事の流れにAIが入れる入口を作り、その入口をCLAUDE.mdとハーネスで育て続けること。ここまで作ると、新しいモデルが出るたびに単発の驚きではなく会社OSそのものが少し強くなる。学習理論の言葉で締めれば、CLAUDE.mdとログの蓄積は、自社業務という「採点器の無い領域」に検証可能性を後付けする営みであり、RLVRが模型の中でやったことを、組織が現実の中で再現する行為にほかならない。
中小企業のマネタイズ ― デモではなく回収から逆算する
100件をそのまま中小企業に持ち込んで「御社も変わります」と言うのは雑だ、と集計者は明言する。事例の多くはコードを書ける人、環境を作れる人、APIを触れる人、Claude Codeを扱える人がいる前提であり、多くの中小企業ではそのまま再現できない。デモと業務は違う。会社で本当に困っているのはもっと地味な仕事だ。
- 営業前の顧客調査、提案書の骨子作成、議事録からのToDo抽出、社内マニュアル整備
- 数字の確認、採用・評価の文章整理、問い合わせ対応の下書き、過去資料の検索
回収の算術は単純である。議事録整理が30分から5分になれば1件25分、週10件で月約17時間——時給換算でモデル利用料を一桁上回る。先に派手なデモを狙わず、仕事が少し楽になる、判断材料が早く揃う、手戻りが減る、若手でも質の高い初稿が出せる、上司の確認時間が減る——この実感(小さな成功体験)が出て初めて次に進める。成功体験がないとAI活用は続かない、という集計者の観察は、導入の順序問題として読むべきだ。マネタイズの構図も実はここに重なる。100選という無料スプレッドシート自体が読者を集める入口(リードマグネット)になり、noteやXでの発信、そしてその先の導入支援へ繋がる——そして導入支援業の商品とは、API転売でもデモ制作でもなく、CLAUDE.mdの整備とハーネスの構築という上流設計そのものである。強いモデルほど会社側の設計が問われるなら、設計を売る仕事が立ち上がる。これが100件の分布が示す、最も実務的な金脈だ。
100選は結論ではなく入口である
この100選は「Fable 5ではこんなことができるらしい」で終わらせるための一覧ではなく、「自分の会社ならどの仕事を置き換えられるか」を考える材料だ。見るべき問いは5つに集約される。この仕事はAIに渡せる形になっているか。成果物を人間が確認できるか。失敗した時に戻れるか。会社の文脈をAIに渡せているか。任せた結果、人間の判断時間が増えるか。ここが無い会社では、Fable 5を入れても劇的には変わらない——高性能なモデルを使っても、仕事の渡し方が雑なら出てくるものも雑である。AI活用の論点は「モデルを知っているか」から「どの仕事を、どの単位で渡せるか」へ移った。単なるニュースを現場で使える形に翻訳し続けること。43対26対9対22という偏った分布は、その翻訳作業の出発点として、モデルの能力地図と組織の設計課題を同時に映す、いま最も正直な鏡である。
