Bedrock でFable 5 が使えるようになったので性能検証してみた。Fable 5 に「いい感じにして」と雑に頼んだら、 サイトの看板を掛け替えられた話

Bedrock でFable 5 が使えるようになったので性能検証してみた。Fable 5 に「いい感じにして」と雑に頼んだら、 サイトの看板を掛け替えられた話

Transcript

1. 2026/07/27 JAWS -UG 朝会 #83 ～ Bedrock でFable 5 が使えるようになったので性能検証してみた ～ Fable 5 に「いい感じにして」と雑に頼んだら、 サイトの看板を掛け替えられた話 NTT テクノクロス株式会社 加藤 © NTT TechnoCross Corporation 洋雄
2. 自己紹介 ◼ 氏名：加藤 洋雄 (X ： @kamogashira) ◼ 所属： NTT テクノクロス株式会社 ⚫ AWS 業務歴約6 年 ◼ AWS 認定 ⚫ 2024 － 2026 Japan AWS All Certifications Engineers ⚫ 2026 AWS Community Builders(AI Engineering) ◼ JAWS -UG 横浜支部運営 ◼ 好きな AWS サービス： Kiro CLI( 旧Amazon ◼ うさぎのけんた (ネザーランドドワーフ Q Developer CLI) )の飼い主 けんたのオリジナルイラストです X のアイコンにも使用しています © NTT TechnoCross Corporation 2
3. はじめに ◼ 本発表は限定的(後述)な条件かつ、ごく限られた期間で Fable 5 を使用した結果がベースです ◼ 発表内容には多分に個人の感想が含まれています ◼ 上記を十分ご理解のうえ、 Fable ◼ 生鮮情報なので、かろうじて ます 5 がどういうものかの片鱗でもお伝えできればと思います 7 月中に発表の機会をいただけた JAWS -UG 朝会さんに感謝してい © NTT TechnoCross Corporation 3
4. 今日話すこと・話さないこと ◼ 話すこと ⚫ Fable 5 のざっくり説明 ⚫ Fable 5 を使ってみての個人的感想 ⚫ 雑な依頼に Fable 5 がどう応えたかの実例 ◼ 話さないこと ⚫ LLM 、 AI Agent 全般について ⚫ 仕様駆動開発、 AI -DLC ⚫ Fable 5 の内部仕様・ベンチマーク © NTT TechnoCross Corporation 4
5. Fable Mythos 5 の超ざっくり紹介 、 Fable はAnthropic 社が開発した LLM ◼ Claude Mythos 5( フルスペック版 ) ⚫ 脆弱性の診断や高度な防御検証といった制限が緩和 ⚫ AI によるハッキング手法の分析や、創薬・生命科学などの専門的な研究目的で使用される ⚫ 審査制の限定顧客向け(誰でも使えるわけではない ) ◼ Claude Fable 5( 制限あり版 ) ← 今日の主役 ⚫ 「サイバーセキュリティ（攻撃転用）」、「生物・化学（危険物質の生成など）」、「モ デル蒸留（競合 AI の模倣防止）」の 3 領域のリクエストを検出 ⚫ 検出すると自動的に安全なモデルである Claude Opus 4.8 へフォールバック (*1) 出典: AWS What's New (2026/06) https://aws.amazon.com/about *1 ： Claude Code 利用時の挙動（ API 直はオプトイン） -aws/whats © NTT TechnoCross Corporation -new/2026/06/claude -fable -5 -aws/ 5
6. AWS でのFable 5 のサービス状況 ◼ 7 /27 時点： AWS 環境では、 Claude Code+Bedrock 、 Bedrock 単体でFable 5 使用可能 ◼ 教訓：商用 LLM は輸出管理等の規制により 、 突然利用不能になるリスクがある 日付(UTC 基準) 出来事 2026 年6 月9 日 AWS がClaude Fable 5 サービス状況一覧 を発表。 Amazon Bedrock / Claude Platform on AWS で一般提供（ GA ）開始 2026 年6 月12 日 米商務省がAnthropic に輸出管理指令を発出。 Fable 5 と Mythos 5 について、 米国内外を問わず外国籍者（ Anthropic 社員含む）のアクセスを禁止するよう要求 →全世界でアクセス停止（約 18 〜 19 日間） 2026 年6 月30 日 米商務省が輸出管理指令を撤回 2026 年7 月1 日 AWS 上でClaude Fable 5 / Mythos 5 （ジェイルブレイク対策の強化）も同時導入 出典: AWS What's New (2026/06) https://aws.amazon.com/about のアクセスが復旧。新しい安全分類器 -aws/whats © NTT TechnoCross Corporation -new/2026/06/claude -fable -5 -aws/ 6
7. みなさん Fable 5 はもう使われましたか？ © NTT TechnoCross Corporation 7
8. 私は、自分のドキュメントサイト 「猫でもわかる Amazon Q Developer CLI 解体新書」 (約84,000 行)に以下の雑な依頼を投げてみました “ 本サイト内容を確認していい感じにして。更新手順書も見直して さて、 Fable ” 5 はなんと答えたでしょうか？ © NTT TechnoCross Corporation 8
9. 検証対象「猫でもわかる Amazon Q Developer CLI ◼ 私が個人的にGitHub ◼ 元は、 Kiro 解体新書」とは に公開しているまとめサイト CLI の前身Amazon Q Developer CLI( 以降Q CLI と略す )のソース解析サイト ◼ Q CLI 時代はOSS としてソースが公開されていたため 、 Q CLI 自身を使って約 1 カ月かけて作成 ◼ Kiro CLI へのリブランディング後はクローズド開発になったため スで Kiro CLI バージョンアップ情報を取りまとめ たサイトに ◼ 2026 年7 月27 日時点でのボリューム：約 、 主にKiro CLI 一次情報ベー 84 , 000 行 2025 年10 月29 日 JAWS -UG AI/ML 支部 #32 にて発表 https : //github . com/kamogashira -sys/q -cli -docs © NTT TechnoCross Corporation 9
10. サイトの看板、掛け替えましょう まさかの「サイトの看板掛け替え」提案！ 今回最大の差別化ポイントその1 Opus 4.6〜4.8使用開始時にもサイト、手順書見直し 依頼を実施したが、この提案は出なかった © NTT TechnoCross Corporation 10
11. 結論： AI Agent 守備範囲がシステム開発からミニ BPR へ ※あくまでも個人の感想です ①本質を見抜き 、 As -Is( 現状の姿)から To -Be( あるべき姿 )を提案できるようになった ②全体最適化の提案ができるようになった ③AI Agent の強み・ 弱みを理解した提案 ・ 実装ができるようになった ・ 規模は小さいものの 、 As -Is 分析 → To -Be 設計 → 移行という構造は BPR( *1 )そのもの → ” ミニ BPR” 【 ★注意★】 あくまでも今回検証に使用した GitHub サイト 「猫でもわかる Amazon Q Developer CLI 解体新書」 (*2) を見直しさせた結果からの結論です *1 ： Business Process *2 ： https : //github Re -engineering . com/kamogashira https : //aws . amazon . com/jp/blogs/news/ai -bpr/ -sys/q -cli -docs © NTT TechnoCross Corporation 11
12. 参考：みのるんさん (のつぶやき )も似た感想 ◼ 2026 年7 月14 日(火)にAWS HERO(AI) みのるんさんの X 投稿(*1 ) みのるんさん最近 の著書です *1 ： https : //x . com/minorun 365 /status/ 2077036698597466461 © NTT TechnoCross Corporation ?s= 20 12
13. Fable 5 を使ってみての個人的感想 © NTT TechnoCross Corporation 13
14. ざっくり比較： ◼ Opus Sonnet ・ Opus ・ Fable 5 を人間に例えると 4 . 6 の2 月頭リリースからたった半年で異次元の進化 ◼ AI Agent のオーケストレーション 、 ワークフロー設計が秀逸 Opus 4.6からたった 半年で異次元の進化 Sonnet 4.5 ・人間開発者だと開発歴 2 年ぐらい ・ 視野が狭い ・ 集中力が続かない ・ Opus と比較して手を抜くことが多 い *1 ： Opus 4.6 の「ゲームチェンジャー」ぶりは Opus 4.6 (*1) 〜 4.8 ・人間開発者だと開発歴 5 年以上 ・ 俯瞰して CDK プロジェクトを調査 できる ・ 集中力が持続する ・ 基本動作がしっかりしている JAWS -UG 朝会#79(2026 Fable 5 ・ 人間のコンサル的立ち位置 ・ 俯瞰してプロジェクト全体を最適化 ・提案・実施ができる ・ 集中力が長時間持続する ・ ベストプラクティスを提案・実践 年3 月)の発表資料参照 © NTT TechnoCross Corporation 14
15. 検証条件 ◼ Fable 5 利用環境： Claude Code ＋Bedrock ◼ 検証対象： 「 猫でもわかる Amazon 経由(effort Q Developer ： xhigh 固定) CLI 解体新書」 ◼ 検証内容：雑な依頼でどこまで依頼者の意図をくみとって仕事をしてくれるのか ？ 依頼内容(全文) 「本サイト内容を確認していい感じにして。更新手順書も見直して」 © NTT TechnoCross Corporation 15
16. Before ：改善前のサイト更新の仕組み ◼ ポイントは３つ：７フェーズの重い手順書 バージョンアップ手順書 、 多段レビュー 、 正しさは人力頼み Rev.4 支援ツール ・ 1,898 行の日本語手順書(単一ファイル ) ・ Phase 0 〜 6 の7 フェーズ構成 (情報収集→計画書→changelog→ 機能文書→ サマリ ー→検証→最終確認) ・ 原則：品質最優先・推測禁止・各 Phase の節目で 目視レビュ ー 手順書を読んで、 Makefile ・ Makefile (kiro 系 9 ターゲット ) － make check -kiro -quick … 6 本まとめ実行 (高速・オフライン ) － make check -kiro -all … 7 本まとめ実行 (URL 検査込み) ・検証スクリプト 7 本(数値整合/リンク切れ /表記・ 日付/構造/相互参照/コマンド表記 /外部URL 生存) 、検証スクリプトも使って更新してるよー © NTT TechnoCross Corporation 16
17. 結論の再掲 ◼ 依頼内容：「本サイト内容を確認していい感じにして。更新手順書も見直して」 ①本質を見抜き、 As -Is( 現状の姿)から To -Be( あるべき姿 )を提案できるようになった ②全体最適化の提案ができるようになった ③AI Agent の強み・弱みを理解した提案・実装ができるようになった © NTT TechnoCross Corporation 17
18. ①本質を見抜き、 As -Is から To -Be を提案 ◼ 主役交代(kiro -docs/ を正面に 、 旧 docs/ はアーカイブ宣言 )を提案 →2026 年7 月時点ではKiro Before( CLI アップデート情報が主役のサイトと見抜く 〜 2026/07/03) After(2026/07/04 ・ タイトル ： ・ タイトル ： 「 猫でもわかる Amazon Q Developer CLI 解体新書」 ・ README まずここから ！→ docs/( 開発終了済みQ CLI) 「 猫でもわかる Kiro CLI ・ README クイックスタート － 128 文書・約 6.1 万行(半年以上更新なし ) ・ GitHub Pages 〜 ) ： アップデート情報 」 → kiro -docs/( 現行Kiro CLI) － 51 文書・約 2.3 万行(可能な限りバージョンアップに追随 ・ GitHub Pages 旧docs /のみ公開 ) ： 案内ページに徹し本体誘導。 docs /には「アーカイブ」宣言 結果 結果 ・ 初心者を終了済みツールへ誘導しがち ・ 誰が来ても現行情報に誘導 © NTT TechnoCross Corporation 18
19. ①Fable 5 の実際の提案(原文抜粋) Fable 5 の出力(抜粋) ◼ 事実： サイトタイトルが「 Amazon Q Developer CLI Documentation 」のまま ◼ 問題： Web 経由の訪問者は更新終了済みQ CLI の情報しか見られない。プロジェクトの主力 (Kiro CLI) と Web 公開物が完全に乖離 ◼ 改善案： 方針決定が必要。 kiro -docs を Pages 公開対象に加える。 Pages をアーカイブサイトと明示 してトップに kiro -cli(GitHub 本体)への誘導を置く © NTT TechnoCross Corporation 19
20. ②全体最適化の提案：手順書の根本問題を指摘 根本的な問題： 約1 年で1 , 898 行の単一ファイル構造になっていた 問題1 ：性質の違う要素の同居 ◼ 手順、事例集、チェックリスト、テンプレートなど、更新タイミングも寿命も大きく異なる情報 が1 ファイルに混在 問題2 ：多重管理 ◼ 同じチェック項目が手順書内の複数箇所に重複記載されていた 問題3 ：除外の悪循環 ◼ 手順書に例として記載されたダミー値 (N 機能、 vX.Y.Z など )がチェックでエラーを起こし、 が勝手にチェック対象から除外 → 結果、手順書内の適宜更新する情報のチェックが実施されていなかった © NTT TechnoCross Corporation AI 20
21. ②「手順を直す」ではなく「手順書というシステムを再設計」 ◼ いつ ・ どう変化するかで３階層に分離 Before 。 正しさのチェックは機械に任せる 役割で3 つに分けるでー After ：役割で 3 つに分ける ： 1 ファイルに全部入り ◼ 作業原則 / 作業手順と実行コマンド / 成果 物のひな形 / 過去の作業履歴 / 手順書自体 の更新履歴 ◼ 性質も寿命も異なる 5 種類の情報が1 ファイ ルに同居 ①ランブック ： 今何をするか (713 行。原則手順のみ・上書き型 ) ②事例集： 過去に何をしたか (終わった記録を末尾に足すだ け・追記専用 ) ③テンプレート ： 何を作るか (コピーしてすぐ使う実物 6 ファイル ) 正しさを保つ手段は「人の注意深さ」だけ 読取専用チェックツール 8 本がリンク切れ・数値の ズレ・新バージョンの見逃しまで自動検出 © NTT TechnoCross Corporation 21
22. ③AI Agent の強み・弱みを理解した提案 – 最適解の発見 ◼ Kiro CLI のバージョン体系 vX . Y . Z ( メジャー 、 マイナー 、 パッチ ) に合わせ 、 更新手順書を X ・ Y ・ Z ごとに独立させる提案をしてきた ⚫ Z のバグフィックス版のときは X ・ Y の更新手順は不要になる ⚫ 複数のバージョンアップを１回のサイト更新で実施する場合にも便利 今回最大の差別化ポイントその 2 ・ Opus 4.6 〜 4.8 使用開始時にも手順書見直し依頼を実施したが、この提案は出なかった ・ プログラムなら「バージョン別に処理を分ける」のは当たり前のロジック ・ それを “ 文書の手順書” に適用できたのが Fable 5 の質的な違い ※ X: メジャー (v1 、 v2 、もうすぐ v3 リリース予定 ) / Y: マイナー (機能追加管理用) / Z: バグフィックス © NTT TechnoCross Corporation 22
23. ③AI Agent の強み・弱みを理解した手順書へ修正の流れ ◼ 現行サイト更新手順書 (約1 , 898 行)は AI Agent 向け手順としては不適切 ◼ 手順書は約700 行を目標値設定し 、 情報の別ファイル化 、 記載内容の最適化をしてくれた ① コピーして使う定型 文はテンプレートと して外だし ② ③ ④ 冗長な処理手順記載 を最適な処理手順へ 重要度の低い処理手 順について、情報を 残しつつ文言圧縮 行数確認 最初にざっくり削除できる箇所を本文か ら削除 目標の約700 行で 完了 こまめに削減行数を確認しながら目標の 行数近くになるまで③を繰り返す © NTT TechnoCross Corporation 23
24. ③AI Agent の強み・弱みを理解した手順書へ修正提案・実施 ◼ 現行サイト更新手順書 (約1 , 898 行)は AI Agent 向け手順としては不適切 ◼ AI Agent の弱み＝コンテキストウィンドウ 700 行を目標値に設定 ◼ ※3 層分離(①ランブック ( 一度に読み切れる量 ) を意識し 、 手順書本体は約 ②事例集 ③テンプレート )の構造は、 ②で再設計したとおり 手順だけに絞った新しい手順書本体は約 700 行 ＝ AI が一度に読み切れて、人もレビューしやすいサイズにしたでー © NTT TechnoCross Corporation 24
25. 数字でみる Before/After 項目 Before After 手順書本体 1,898 行 713 行(ランブック： 文書構成 単一ファイル ランブック＋事例集＋テンプレート 検証スクリプト 7本 8 本(1 本新設＋既存7 本を機能強化 ) 手順書内のコマンド 動かないもの 5 件 全20 本実行検証済み 新バージョンの検知 人力(kiro -cli update 認) 計画書レビュー 全対応一律の多段レビュー リスクベースの３層 手順書自身の検証 なし リンク検査オプション＋改訂時セルフチェック コマンド確 62% 削減) コマンド化 (make check 6種 -kiro -freshness) 人間は判断と編集内容に集中 検証と検出は冪等性を有する読取専用ツールに任せる © NTT TechnoCross Corporation 25
26. Fable 5 でリニューアル後の結果 サイト構成 (エラー対処含む ) ・ 看板掛け替えに満足 (前から気になっていた点だった ) ・ 各フォルダ README.md の集計情報エラーが解消 ・ ヘッダーの日付フォーマット間違いなど細かなエラーも解消 サイト更新処理 ・ vX.0.0 ：近日 GA 予定のv3.0.0 待ち (未検証) ・ v?.Y.0( マイナ ー)： v2.13.0 時の1 回確認。人間の指示回数が大幅削減、判断回 数もかなり削減。 LLM はSonnet でも問題ない品質 (前までは Opus 利用) ・ v?.?.Z( パッチ )： v2.12.n 時の2 回確認。サイト更新処理時間が大幅短縮、 10 分 弱で完了 © NTT TechnoCross Corporation 26
27. Fable 5 の作業品質と LLM コストの関係 ◼ Model ： Fable 5 固定(effort ： xhigh 固定) ◼ 本作業稼働： 2026 年7 月4 日の1 日のみ。 10 時間48 分(API 稼働時間 7 時間22 分) ◼ 作業品質：申し分なし ◼ コスト：約 $ 281 ≒ 約4 . 5 万円 ($ 1 = 160 円) ⚫ 私の業務における LLM 平均月額使用料金(Opus ＋Sonnet) の約4 割増し 今後のメンテナンス品質、時間、コストを考えれば 金額に納得はできないが、理解はできる © NTT TechnoCross Corporation 、 27
28. 最後に お金で時間とアウトプット品質は買える時代に！ ただし Fable 5 は本当に必要な時のみ使いましょう ◼ CDK コーディングなら Sonnet 5 、デバッグは Opus で十分です ◼ くれぐれも戦車でコンビニに買い物に行くのはやめましょう © NTT TechnoCross Corporation 28