はじめに
Fable 5のお試し期間が 6/23まで なので、それまでに一度試しておきたい使い方を整理します。
AI開発ツールを使うとき、最初に思いつくのは次のような使い方です。
この機能を実装してください。
このバグを修正してください。
このコードをリファクタリングしてください。
もちろん、AIに実装を任せる使い方は便利です。
ただ、既存プロジェクトが大きい場合、いきなりコードを書かせるよりも、まずは プロジェクト全体を調査して、構造・課題・改善順序を整理する ほうが効果的だと感じています。
個人的には、Fable 5は「実装を速くするAI」というより、
プロジェクト全体を深く調査して、設計・負債・リファクタリング方針を整理するAI として使うのがよさそうです。
実装そのものは、GPT-5.5やOpus 4.7のようなモデルに任せる。
その前段階として、Fable 5には次のような作業を任せるイメージです。
- 既存構造の把握
- 技術的負債の洗い出し
- 影響範囲の整理
- テスト不足の把握
- リファクタリング方針の作成
- PR分割計画の作成
- 実装前のリスク整理
AIはモデルごとに得意領域が違います。
そのため、単に「どのAIが一番強いか」ではなく、
どの工程に、どのAIを使うか を考えることが重要だと思います。
結論：まず試すなら「大規模リファクタリング計画」を作らせる
Fable 5のお試し期間中に1つだけ試すなら、個人的には 大規模リファクタリング計画の作成 がよさそうです。
理由は、Fable 5の価値が一番わかりやすいからです。
単にコードを書かせるのではなく、既存プロジェクトを調査させて、次のような内容を整理してもらいます。
- 現在のプロジェクト構造
- 長年蓄積した無駄
- 技術的負債になっている箇所
- 先に直すべき箇所
- 後回しにすべき箇所
- リスクが高い箇所
- テストを先に追加すべき箇所
- フェーズごとの改善計画
- GPT-5.5やOpus 4.7に実装を依頼する単位
つまり、Fable 5には 実装前の調査・整理・計画化 を任せます。
実装そのものは、GPT-5.5やOpus 4.7のようなモデルに任せる。
この役割分担にすると、AIを使ったリファクタリングがかなり現実的になると思います。
最初に試すプロンプト：大規模リファクタリング計画
まず試すなら、以下のプロンプトがよさそうです。
今、このプロジェクトには、長年蓄積した大量の無駄があります。
いきなりコードは変更せず、まずはプロジェクト全体を調査してください。
目的は、フェーズに分けて安全にリファクタリングを進めるための詳細な計画を作ることです。
以下の観点で調査し、Markdown形式でリファクタリング計画を作成してください。
## 調査してほしい内容
- 現在のプロジェクト構造
- 主要ディレクトリの役割
- 主要モジュールの責務
- 依存関係の流れ
- 肥大化している箇所
- 重複している処理
- 責務が曖昧になっている箇所
- 技術的負債になっている箇所
- テストが不足している可能性がある箇所
- 影響範囲が大きく、慎重に扱うべき箇所
- 削除候補になりそうなコード・設定・リソース
## リファクタリング計画に含めてほしい内容
- リファクタリングの目的
- 現状の問題点
- フェーズ分割
- 各フェーズで実施すること
- 各フェーズの対象範囲
- 先に着手すべき箇所
- 後回しにすべき箇所
- リスクが高い箇所
- 事前に追加すべきテスト
- レビュー方針
- ロールバック方針
- 実装をGPT-5.5やOpus 4.7に依頼する場合の作業単位
## 出力形式
以下のMarkdownファイルとして保存してください。
docs/refactoring_master_plan.md
なお、実装はまだ行わないでください。
まずは調査結果とリファクタリング方針の整理だけを行ってください。
このプロンプトで期待する成果物
期待する成果物は、以下のMarkdownファイルです。
docs/refactoring_master_plan.md
このファイルに、次の内容が整理されている状態を目指します。
- どこに問題があるのか
- なぜ問題なのか
- どこから直すべきか
- どこは後回しでよいか
- どこは触ると危険か
- 先にどのテストを追加すべきか
- PRをどう分割すべきか
- 実装AIにどの単位で渡すべきか
これが作れれば、Fable 5のお試し期間中の成果としてはかなり価値があると思います。
Fable 5に任せること、実装AIに任せること
役割分担としては、次のようなイメージです。
Fable 5に任せること:
- プロジェクト全体の調査
- アーキテクチャ整理
- 技術的負債の洗い出し
- 影響範囲調査
- テスト不足の整理
- リファクタリング計画の作成
- PR分割計画の作成
GPT-5.5 / Opus 4.7に任せること:
- 実装
- テスト追加
- 具体的なコード修正
- 差分の改善
- レビュー指摘への対応
- エラー修正
Fable 5には、調査と計画を任せる。
GPT-5.5やOpus 4.7には、実装を任せる。
このように分けると、AIに任せる作業の粒度が明確になります。
追加で試したいプロンプト集
大規模リファクタリング計画を作ったあと、さらに深掘りするなら、以下のドキュメントも作らせるとよさそうです。
docs/architecture_review.md
docs/technical_debt_inventory.md
docs/impact_analysis.md
docs/test_coverage_strategy.md
docs/deletion_candidates.md
docs/development_guidelines.md
docs/refactoring_pr_plan.md
全部を一度に作らせる必要はありません。
まずは docs/refactoring_master_plan.md を作る。
その後、必要に応じて個別テーマを深掘りする流れがよさそうです。
追加プロンプト1：プロジェクト全体の構造を調査する
このプロジェクト全体を調査し、現在のアーキテクチャを整理してください。
以下を含めてください。
- 主要ディレクトリの役割
- 主要モジュールの責務
- 主要な処理の流れ
- 依存関係の方向
- 共通処理の置き場所
- 実際に使われている設計パターン
- 設計上の一貫性が崩れている箇所
- 肥大化している箇所
- 今後リファクタリングする際の注意点
成果物は Markdown 形式で、docs/architecture_review.md に保存してください。
追加プロンプト2：技術的負債を分類する
このプロジェクトの技術的負債を調査し、優先順位付きで整理してください。
分類は以下に分けてください。
- すぐ直すべき負債
- 次の改修時に一緒に直すべき負債
- 影響範囲が大きいため設計判断が必要な負債
- 直さなくてもよい、または優先度が低い負債
- 現時点では触らないほうがよい負債
各項目について、以下を記載してください。
- 問題の概要
- 該当ファイル
- なぜ問題なのか
- 放置した場合のリスク
- 修正方針
- 想定される影響範囲
- 優先度
- リスクレベル
- 実装をGPT-5.5やOpus 4.7に依頼する場合の依頼単位
成果物は Markdown 形式で、docs/technical_debt_inventory.md に保存してください。
追加プロンプト3：影響範囲を調査する
以下の機能について、修正・リファクタリング時の影響範囲を調査してください。
対象機能:
〇〇機能
以下を整理してください。
- 関連する画面
- 関連するコンポーネント
- 関連するサービス層
- 関連するAPI
- 関連するDB・キャッシュ・永続化処理
- 関連するバッチ処理
- 関連する設定ファイル
- 関連するテスト
- 影響を受ける可能性があるユーザー導線
- 壊れやすい箇所
- 回帰テストで確認すべき項目
- 実装をGPT-5.5やOpus 4.7に依頼する場合の注意点
成果物は Markdown 形式で、docs/impact_analysis_〇〇.md に保存してください。
追加プロンプト4：テスト不足マップを作る
このプロジェクトのテスト状況を調査し、テスト不足マップを作成してください。
以下を整理してください。
- テストが存在する領域
- テストが不足している領域
- 重要度が高いのにテストがない処理
- 回帰リスクが高い処理
- 優先的に追加すべき単体テスト
- 優先的に追加すべき結合テスト
- 優先的に追加すべきE2Eテスト
- リファクタリング前に最低限追加すべきテスト
- テスト追加のロードマップ
- 実装をGPT-5.5やOpus 4.7に依頼する場合のテスト追加単位
成果物は Markdown 形式で、docs/test_coverage_strategy.md に保存してください。
追加プロンプト5：削除候補のコードを洗い出す
このプロジェクト内で、削除候補となるコード・設定・リソースを調査してください。
以下を分類してください。
- 未使用のクラス
- 未使用の関数
- 未使用の定数
- 古いFeature Flag
- 参照されていないリソース
- 使われていない設定ファイル
- 使われていないバッチ
- 過去施策の残骸
- 削除判断に注意が必要なもの
各項目について、以下を記載してください。
- 削除候補の概要
- 該当ファイル
- 未使用と判断した理由
- 削除前に確認すべきこと
- 削除した場合のリスク
- 安全な確認方法
- 実装をGPT-5.5やOpus 4.7に依頼する場合の削除単位
成果物は Markdown 形式で、docs/deletion_candidates.md に保存してください。
AIの「未使用」判定は、必ず人間が確認したほうがよいです。
特に、次のようなものはAIが見落とす可能性があります。
- 動的呼び出し
- 設定ファイル経由の参照
- 外部サービスから呼ばれる処理
- URLルーティング
- リフレクション
- バッチ処理
- 管理画面からだけ使われる機能
- 特定条件でのみ使われる例外処理
そのため、削除候補は「削除してよいもの」ではなく、
削除前に確認すべき候補 として扱うのが安全です。
追加プロンプト6：今後の開発ルールを整理する
このプロジェクトの現状を調査したうえで、今後の開発で守るべき設計ルールを作成してください。
以下を含めてください。
- 画面・コンポーネントの責務分担
- ビジネスロジックの置き場所
- API通信処理のルール
- エラーハンドリングのルール
- ログ出力のルール
- 状態管理のルール
- DB・キャッシュ利用時のルール
- バッチ処理のルール
- 設定ファイルの扱い
- テスト追加のルール
- 命名規則
- 新規実装時に避けるべきアンチパターン
- レビュー時に確認すべき観点
- 実装をGPT-5.5やOpus 4.7に依頼する場合に必ず守らせるルール
成果物は Markdown 形式で、docs/development_guidelines.md に保存してください。
追加プロンプト7：PR分割計画を作る
このプロジェクトの〇〇領域をリファクタリングする前提で、PR分割計画を作成してください。
以下の条件を守ってください。
- 1 PRあたりの変更量を小さくする
- 動作変更と構造変更を混ぜない
- テスト追加を先に行う
- レビューしやすい順番にする
- 各PRの目的を明確にする
- 各PRの対象ファイルを明記する
- 各PRの確認観点を明記する
- ロールバックしやすい順番にする
- GPT-5.5やOpus 4.7に実装依頼しやすい単位に分ける
成果物は Markdown 形式で、docs/refactoring_pr_plan_〇〇.md に保存してください。
お試し期間中にやるなら、この順番
Fable 5のお試し期間が6/23までなので、全部を試すのは現実的ではないかもしれません。
まずは、以下の順番がよさそうです。
| 優先度 | 作るドキュメント | 目的 |
|---|---|---|
| 1 | refactoring_master_plan.md |
大規模リファクタリングの全体計画を作る |
| 2 | technical_debt_inventory.md |
技術的負債を分類する |
| 3 | test_coverage_strategy.md |
安全に直すためのテスト方針を作る |
| 4 | refactoring_pr_plan.md |
実装AIに渡せる単位へ分解する |
| 5 | architecture_review.md |
プロジェクト全体の構造を整理する |
特に、最初に作るべきなのは以下です。
docs/refactoring_master_plan.md
これがあると、次に何を深掘りすべきかが見えやすくなります。
実装AIに渡すときのプロンプト
Fable 5で作成したドキュメントをもとに、GPT-5.5やOpus 4.7には次のように依頼します。
docs/refactoring_master_plan.md と docs/refactoring_pr_plan.md を確認してください。
今回は PR 1 の範囲だけを実装してください。
条件:
- 動作変更は入れない
- 構造整理のみ行う
- 既存テストが通る状態を維持する
- 影響範囲外のファイルは変更しない
- 不要なファイル変更はしない
- 変更理由をPR説明文としてまとめる
- 実装後に確認すべきテストを一覧化する
さらに、安全性を上げるなら次のように依頼します。
実装前に、まず今回変更するファイル一覧と変更理由を提示してください。
その後、以下を確認してください。
- 仕様変更が含まれていないか
- 影響範囲外の変更が含まれていないか
- 既存テストで確認できる範囲
- 追加すべきテスト
- ロールバックする場合に戻すべきファイル
確認結果を提示してから、PR 1 の実装に進んでください。
このように、Fable 5で作った計画を実装AIに渡すと、作業範囲を制御しやすくなります。
AIにいきなり「全部直して」と依頼するよりも、
調査AIで計画を作り、実装AIで小さく直す ほうが現実的です。
まとめ
Fable 5のお試し期間が6/23までなので、それまでに一度試すなら、個人的には「実装AI」としてではなく、設計調査AI として使ってみたいです。
特に最初に試したいのは、以下の成果物を作らせる使い方です。
docs/refactoring_master_plan.md
このドキュメントで、次の内容を整理します。
- 現状の問題点
- 長年蓄積した無駄
- 技術的負債
- 改善順序
- リスクが高い箇所
- テスト方針
- PR分割方針
- 実装AIに渡す作業単位
Fable 5には、調査・構造理解・方針整理を任せる。
GPT-5.5やOpus 4.7には、実装・テスト追加・修正を任せる。
AI開発で重要なのは、単に「どのAIが一番強いか」ではありません。
重要なのは、
どの工程に、どのAIを使うか です。
Fable 5を使うなら、まずはコードを書かせるより、
プロジェクト全体を読ませて、大規模リファクタリング計画を作らせる。
それが、6/23までのお試し期間で一度試しておきたい使い方です。