---
title: "Claude Fable 5でサイトのレビューをしてみた"
date: 2026-06-10
categories:
  - "AI IDE"
  - "Claude Code"
url: "https://hidetaka.dev/ja/writing/dev-notes/try-claude-fable-5-for-website-review"
---

Claude Fable 5 が 6/23 以降はサブスクとは別課金になるという話が出ていたので、どう使うか少し考えました。

毎日のコーディングタスクよりも、ロードマップや方向性を決めるような「大きめの判断を要するタスク」に向いているのではと思い、まずは自分のサイト（hidetaka.dev）の現状診断を試してみることにしました。いきなり「方向性を考えてくれ」と投げても抽象すぎるので、現状チェックとそこからの改善提言というかたちで依頼しました。

## プロンプトと実行の様子

デザイン・UI 系のスキルを複数リポジトリに追加していたので、それを活かした依頼にしました。また、個別に開発した GA4 / Google Search Console 連携の MCP サーバーも持っているので、それも使うよう指示しています。

```
デザイン・UI系のスキルを複数追加している。それぞれagent teamで並列実行し、レビューと改善提案をレポートしてください。
ga4 / gscのmcpもあるので、調査して良い。
```

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/82dfa5c2d5a47fa0106575b6d76ebfa8-20260610205519.png)

スキルの定義を確認してから、5 つのエージェントを並列起動する流れになりました。先に GA4 / GSC の調査結果を共有して、後続の統合レポートの優先度付けに使うという段取りも自分で決めていました。

実行ログを展開すると、スキルのスキャンと並行して personal MCP サーバー経由で GA4 プロパティの一覧取得・レポート実行・Search Console のパフォーマンス分析までこなしていることがわかります。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/f80825211587583cfa58399715747455-20260610205536.png)

## エージェントからの中間レポート

Agent Team での作業なので、完了したエージェントから順番に要点が届きます。最初に返ってきた frontend-design 観点のレビューがなかなか手厳しかったです。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/28cb5eec87ba2c398112ee0526dfa923-20260610205607.png)

「blur 円形グラデ×3 + グリッド + hover:scale-105 という AI 生成テンプレ 3 点セット」「誰のサイトか視覚から特定できない」あたりは反論できませんでした。theme-factory 観点のレビューでは、zinc / slate / gray の 3 ニュートラル系統が 31 ファイルに混在しているという指摘も出てきました。コードを触っているときは気づかないものです。

## 統合レポート：深刻度別に整理

全 8 観点のレビューが出揃うと、深刻性で整理した統合レポートが届きます。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/5002f9abfb4ca0063b1cc6e93f42fd5c-20260610205626.png)

P1（即修正推奨）で上がってきた項目の中で、2 番目のコンタクト導線の欠落は面白い発見でした。/contact・/inquiry・/help への継続的なアクセスを GA4 のデータから発見したものです。サイト内に該当ページへのリンクが一切ない状態なので、十中八九スキャン系の攻撃アクセスだとは思いますが、GA4 データをそのまま課題として拾ってくる動き自体は興味深かったです。

## ロードマップまで出てくる

指摘をフェーズに分けた修正ロードマップまで出てきます。どのフェーズまでやらせるか、どう Agent Team を組成するか、といったことを考えるベースにできます。ここで GitHub や Linear に Issue を起票して止めるのも十分ありだと思います。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/6668b9a13a815caeb6af2b563e9929c3-20260610205652.png)

フェーズ 1〜2（即効バグ修正・SEO 基盤）は GSC の CTR 改善に直結するとの判断で、工数感「小〜中」でまとめられています。フェーズ 4〜5（デザイン刷新・構造負債解消）は工数感「大」で、別途計画が必要な扱いです。優先度の根拠として GA4/GSC の実データが紐づいている点がレポートとして使いやすかったです。

## 実装まで走らせた

せっかくなのでフェーズ 1〜3 の実装までやらせてみました。個人的にはフィードバック項目ごとに PR を切ってほしかったのですが、ロードマップのフェーズ単位で作業したようです。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/0c77893b6b09e0ef645da1386cf4969c-20260610205718.png)

結果として 3 フェーズそれぞれ 1 ブランチ = 1 PR の計 3 本（#229〜#231）が作成されました。3 エージェントともに pnpm lint:check / pnpm test / pnpm build を通過してからプッシュしています。マージ順は #229 → #230 → #231 の推奨と、後続 PR のリベース注意点もコメントに書いてありました。

## まとめ

Claude Fable 5 でサイトのレビューから実装 PR まで一通り試してみました。

トークン消費がかなり激しいので、実装作業そのものは Sonnet（あるいは最低でも Opus）に任せるほうが現実的です。Fable 5 の使いどころとしては、Linear / Backlog / GitHub に Issue やマイルストーンを起票する前の「診断と優先度整理」あたりが向いている気がしました。GA4 や GSC などのデータを持ち込んで多角的に分析させられるのは強みで、定期的な診断用途として予算を確保するのがよさそうです。