はじめに
2026年7月27日のJAWS-UG朝会#83で、「BedrockでFable 5が使えるようになったので性能検証してみた」というテーマで登壇しました。本記事はその発表内容の紹介記事です。
本記事の検証は、2026年7月4日の1日だけ・私の個人サイト1つだけを対象に行った、きわめて限定的なものです。また内容には多分に個人の感想が含まれます。
今更Fable 5の使用感か、と思われるかもしれません。それでも発表しようと思ったのは、自分の作ったサイトにFable 5へ雑な依頼を投げた結果、結構な衝撃を受けたからです。生鮮情報なので、かろうじて7月中に発表の機会をいただけたJAWS-UG朝会さんに感謝しています。
発表資料はこちらです。
Fable 5とは
Mythos、FableはAnthropic社が開発したLLMです。
- Claude Mythos 5（フルスペック版）：脆弱性診断や高度な防御検証といった制限が緩和されたモデル。審査制の限定顧客向けで、誰でも使えるわけではありません
- Claude Fable 5（制限あり版）← 本記事の主役：「サイバーセキュリティ（攻撃転用）」「生物・化学」「モデル蒸留」の3領域のリクエストを検出すると、自動的に安全なモデルであるClaude Opus 4.8へフォールバックします（Claude Code利用時の挙動。API直はオプトイン）
「いい感じにして」— 84,000行のサイトに雑な依頼を投げる
みなさんはFable 5をもう使われたでしょうか？
私は、自分が個人運営しているドキュメントサイト「猫でもわかるAmazon Q Developer CLI 解体新書」（約84,000行）に、こんな雑な依頼を投げてみました。
「本サイト内容を確認していい感じにして。更新手順書も見直して」
これが依頼の全文です。要件定義もなければ、期待する成果物の指定もありません。
検証対象サイトについて
このサイト（kamogashira-sys/q-cli-docs）は、もともとKiro CLIの前身であるAmazon Q Developer CLI（以降Q CLI）のソース解析サイトでした。Q CLI時代はOSSだったので、Q CLI自身を使って約1カ月かけて作成したものです。
2025年11月のKiro CLIへのリブランディング後はクローズド開発になったため、主にKiro CLIの一次情報ベースで、バージョンアップ情報を取りまとめるサイトとして更新を続けてきました。
検証環境・内容
- 検証環境：Claude Code + Bedrock経由でFable 5を使用
- 検証内容：雑な依頼でどこまで依頼者の意図をくみとって仕事をしてくれるのか？
Fable 5はなんと答えたでしょうか？
返ってきたのは「サイトの看板、掛け替えましょう」
Fable 5の回答は、まさかのサイトの看板掛け替え提案でした。
依頼したのは「サイト内容の確認」と「手順書の見直し」です。それに対してFable 5は、リポジトリ全体を調査したうえで「読者が正しい情報に辿り着けない構造問題」を最優先の指摘として挙げてきました。
ここで強調しておきたいのは、Opus 4.6〜4.8の使用開始時にも同じ見直し依頼を実施したものの、この提案は出てこなかった、という点です。
これが今回の検証で感じた、Fable 5の質的な違いの1つ目です。
結論：AI Agentの守備範囲が「システム開発」から「ミニBPR」へ
- 本質を見抜き、As-Is（現状の姿）からTo-Be（あるべき姿）を提案できるようになった
- 全体最適化の提案ができるようになった
- AI Agentの強み・弱みを理解した提案・実装ができるようになった
規模は小さいものの、As-Is分析 → To-Be設計 → 移行という構造はBPR（Business Process Re-engineering）そのものと感じました。そのため私はこれをミニBPRと命名しました。
ちなみに、AWS HERO（AI）のみのるんさんも2026年7月14日のX投稿で似た感想を述べられていて、自分の感覚は大きく外れてはいないと少し安心しました。
Sonnet・Opus・Fable 5を人間に例えると
私の感覚を人間の開発者に例えると以下のようになります。
| モデル | 人間に例えると | 特徴 |
|---|---|---|
| Sonnet 4.5 | 開発歴2年ぐらい | 視野が狭い / 集中力が続かない / Opusと比べて手を抜きがち |
| Opus 4.6〜4.8 | 開発歴5年以上 | 俯瞰してプロジェクトを調査できる / 集中力が持続 / 基本動作がしっかり |
| Fable 5 | 人間のコンサル的立ち位置 | 俯瞰してプロジェクト全体を最適化・提案・実施 / 集中力が長時間持続 / ベストプラクティスを提案・実践 |
Opus 4.6のゲームチェンジャーぶりには2026年2月にかなりの衝撃を受け、JAWS-UG朝会#79（2026年3月）で発表しました。そこからたった半年で今度は異次元の進化と感じました。
以後結論3点を実例で示します。
Before：1,898行の手順書と、人の注意深さ
まず改善前のサイト更新の仕組みを紹介します。手順書の作成はもちろん、機械的にチェックできる検証は、スクリプト化（読取専用・何度実行しても安全）して実行していました。
- バージョンアップ手順書 Rev.4：1,898行の日本語手順書（単一ファイル）。Phase 0〜6の7フェーズ構成
- 支援ツール：Makefile（kiro系9ターゲット）+ 検証スクリプト7本（数値整合/リンク切れ/表記・日付/構造/相互参照/コマンド表記/外部URL生存）
- 原則：品質最優先・推測禁止・各Phaseの節目で目視レビュー
7フェーズの手厚い手順書、多段レビュー、正しさは人力での確認頼みでした。この体制で複数回の版対応をこなし、公開ドキュメントの品質自体は保たれていました。
①本質を見抜く：As-IsからTo-Beを提案
1つ目が、冒頭の「看板の掛け替え」です。
Fable 5は2026年7月時点では、このサイトの主役はKiro CLIアップデート情報であると見抜き、主役交代（kiro-docs/を正面に、旧docs/はアーカイブ宣言）を提案してきました。
| Before（〜2026/07/03） | After（2026/07/04〜） | |
|---|---|---|
| サイトタイトル | 猫でもわかる Amazon Q Developer CLI 解体新書 | 猫でもわかる Kiro CLI アップデート情報 |
| READMEの導線 | ⭐まずここから！→ docs/（開発終了済みQ CLI、128文書・約6.1万行、半年以上更新なし） | 🚀クイックスタート → kiro-docs/（現行Kiro CLI、51文書・約2.3万行） |
| GitHub Pages | 旧docs/のみ公開 | 案内ページに徹し本体へ誘導。docs/には「アーカイブ」宣言 |
| 結果 | 初心者を終了済みツールへ誘導しがち | 誰が来ても現行情報に誘導 |
中身の世代交代はとっくに済んでいたのに、サイトのトップだけが半年前のままでした。言われてみれば「前から気になっていた点」でしたが、依頼文にはこのことは一言も書きませんでした。それを最優先課題として掘り当ててきたのがFable 5でした。
②全体最適化：手順書の構造が根本原因
手順書の見直しでは、Fable 5は個々の記述ミスの修正に留まりませんでした。約1年で1,898行の単一ファイル構造になっていたこと自体を根本問題として指摘してきました。
- 性質の違う要素の同居：手順、事例集、チェックリスト、テンプレートなど、更新タイミングも寿命も大きく異なる情報が1ファイルに混在
- 多重管理：同じチェック項目が手順書内の複数箇所に重複記載
- 除外の悪循環：手順書内のダミー値（N機能、vX.Y.Zなど）がチェックでエラーを起こすため、AIが勝手にチェック対象から除外 → 手順書自身は誰にも検証されない
そして手順を直すのではなく手順書というシステムを再設計することを提案してきました。いつ・どう変化するかで3階層に分離し、正しさのチェックは機械に任せる構成です。
- ランブック：今何をするか（713行。原則と手順のみ・上書き型）
- 事例集：過去に何をしたか（終わった記録を末尾に足すだけ・追記専用）
- テンプレート：何を作るか（コピーしてすぐ使う実物6ファイル）
これに加えて、リンク切れ・数値のズレ・新バージョンの見逃しを自動検出する読取専用チェックツール8本（1本新設＋既存7本を機能強化）を整備してくれました。
③AI Agentの強み・弱みを理解した提案
個人的に一番感心したのは、以下の2点でした。
バージョン体系に合わせた手順の分割
Fable 5は、Kiro CLIのバージョン体系 vX.Y.Z（メジャー・マイナー・パッチ）に合わせて、更新手順をX・Y・Zごとに独立させる提案をしてきました。Zのバグフィックス版のときはX・Yの更新手順は不要になり、複数バージョンを1回のサイト更新でまとめて処理する場合にも便利です。
これもOpus 4.6〜4.8では出てこなかった提案です。プログラムなら「バージョン別に処理を分ける」のは当たり前のロジック。それを『文書の手順書』に適用できたのが、Fable 5の質的な違いの2つ目でした。
自分（AI）の弱みを織り込んだ目標設定
さらにFable 5は、1,898行の手順書はAI Agent向けの手順としては不適切と判断し、AI Agentの弱み＝コンテキストウィンドウ（一度に読み切れる量）を意識して、手順書本体を約700行に目標設定しました。
テンプレートの外出し → 冗長な手順の最適化 → 情報を残しつつ文言圧縮、を削減行数を確認しながら目標行数に届くまで繰り返す。AIが一度に読み切れて、人もレビューしやすいサイズへの作り替えを提案してくれました。
AIが、AI自身の弱みを前提に、自分が使う手順書を再設計したのです。
数字で見るBefore/After
| 項目 | Before | After |
|---|---|---|
| 手順書本体 | 1,898行 | 713行（ランブック：62%削減） |
| 文書構成 | 単一ファイル | ランブック＋事例集＋テンプレート6種 |
| 検証スクリプト | 7本 | 8本（1本新設＋既存7本を機能強化） |
| 手順書内のコマンド | 動かないもの5件 | 全20本実行検証済み |
| 新バージョンの検知 | 人力 | コマンド化（make check-kiro-freshness） |
| 計画書レビュー | 全対応一律の多段レビュー | リスクベースの3階層（パッチ／マイナー／メジャー） |
| 手順書自身の検証 | なし | リンク検査オプション＋改訂時セルフチェック |
62%削減といっても情報を削除したわけではなく、役割ごとの引っ越しと機械への委譲です。思想はこの一文に集約されます。
人間は判断と編集内容に集中し、検証と検出は冪等性を有する読取専用ツールに任せる
リニューアル後、実際どうなったか
その後の実運用でも効果が出ています。
- サイト構成：看板掛け替えに満足（前から気になっていた点）。各フォルダREADMEの集計情報エラーや日付フォーマット間違いなど細かなエラーも解消
- マイナー版対応（v2.13.0で1回確認）：人間の指示回数が大幅削減、判断回数もかなり削減。LLMはSonnetでも問題ない品質に（以前はOpusが必要だった）
- パッチ版対応（v2.12.n系で2回確認）：サイト更新処理時間が大幅短縮、10分弱で完了
結局いくらかかったのか
気になるコストの話です。
- Model：Fable 5固定（effort: xhigh 固定）
- 作業時間：2026年7月4日の1日のみ。10時間48分（API稼働時間 7時間22分）
- 作業品質：申し分なし
- コスト：約$281 ≒ 約4.5万円（$1=160円）
これは私の業務におけるLLM平均月額使用料金（Opus＋Sonnet）の約4割増しに相当します。今後のメンテナンス品質、時間、コストを考えれば、「金額に納得はできないが、理解はできる」と感じました。
まとめ：戦車でコンビニに行かない
お金で時間とアウトプット品質は買える時代になりました。ただし、Fable 5は本当に必要な時のみ使いましょう。
- CDKコーディングならSonnet、デバッグはOpusで十分です
- くれぐれも戦車でコンビニに買い物に行くのはやめましょう
Fable 5は、限定的な検証ながら「本当に人間のコンサルに近い存在」だと感じました。この特性を理解して使えば、今までAI Agentが解決できなかった種類の課題、すなわち「何を作るか」の手前にある「そもそも今どうなっていて、どうあるべきか」に手が届くようになったと感じています。
参考リンク
- 検証対象サイト：https://github.com/kamogashira-sys/q-cli-docs
- Claude Fable 5 on AWS（What's New）：https://aws.amazon.com/about-aws/whats-new/2026/06/claude-fable-5-aws/
- 生成AIによるBPR（AWSブログ）：https://aws.amazon.com/jp/blogs/news/ai-bpr/
- JAWS-UG朝会：https://jawsug-asa.connpass.com/