Claude Fable 5最该做的事：给代码仓库来一次全面审计

原文著者：Meta Alchemist

原文翻訳：Peggy、BlockBeats

編集者注：Claude Fable 5 は2026年6月9日にリリースされ、Anthropicはこれを長期サイクルのソフトウェアエンジニアリングタスクを得意とし、より強力なセキュリティ特性を備えたMythos級モデルとして位置づけています。

新モデルのリリース後、開発者はすぐに実際のエンジニアリングシナリオでの活用方法を探り始めました。@meta_alchemist が共有したこのリポジトリ監査プロンプトは、その典型的な事例です。これにより、Fable 5はコードを生成するだけでなく、経験豊富なテクニカルリーダーのように、4つのフェーズに従って体系的にコードリポジトリを精査します。まずプロジェクト構造と技術スタックを整理し、次に実際のファイルと行番号に基づいてアーキテクチャ、セキュリティ、テスト、パフォーマンス、依存関係、ドキュメントの問題をチェックし、その後改善戦略を練り上げ、優先順位と作業量の見積もりを伴うタスクマイルストーンに分解します。一部のユーザーはこれにより技術的負債を解消し、旧モデルでは見逃されていたセキュリティの脆弱性や効率性の問題を発見していますが、サンドボックス環境の不安定性といった初期の問題に直面したユーザーもいます。

全体として、Fable 5のリリースは単なるモデル能力の向上だけでなく、AIを「コード作成アシスタント」から「エンジニアリング監査とプロジェクト改善の協働者」へとさらに押し進めるものです。

以下が原文です：

あなたはもうClaude Fable 5を使っていますか？

あなたが最初にやるべきことの一つは、それを使ってあなたのコアプロジェクトをアップグレードし、これまで進めてきたすべての作業を大幅に改善することです。

あなたにとって重要なすべてのコードリポジトリで、以下の「監査とプロジェクト改善のプロンプト」（そのままコピー＆ペーストしてください）を実行してください：

コードリポジトリ監査と改善計画

プロンプトはClaude Fable 5によって生成されました

あなたは、世界最高峰の主任エンジニア級ソフトウェアエンジニア兼技術監査の専門家です。あなたのタスクは、このコードリポジトリを深く分析し、正直な監査レポートを提供し、優先順位付けされ実行可能な改善計画を提示することです。以下の4つのフェーズを順番に厳密に実行し、手順を飛ばさないでください。

すべての判断は実際のファイル根拠に基づく必要があります。ファイルパスと行番号を引用してください。検証できないことがあれば、推測せずに明示的にその旨を述べてください。

フェーズ 1 / 発見と整理：まず読み、次に判断する

結論を形成する前に、コードリポジトリ全体を体系的に探索してください：

·ディレクトリ構造を整理し、プロジェクトの種類、使用言語、フレームワーク、実行目標を特定します。

·エントリーファイル、コアモジュール、システム内の主要なデータフローと制御フローを特定します。

·package manifest、lockfile、ビルド設定、CI設定、環境/設定ファイル、およびREADME、CONTRIBUTING、ADRなどのすべてのドキュメントを読みます。

·このプロジェクトの目的を判断します：その目標、想定ユーザー、そして現在の成熟度（プロトタイプか、内部ツールか、本番サービスか、ライブラリか）を評価します。

·プロジェクトがすでに採用している慣行を記録します。命名規則、モジュール境界、エラーハンドリングパターン、テストスタイルなどを含め、後続の提案が既存のエンジニアリング文化に適合し、それに反しないようにします。

本フェーズの出力：プロジェクトの目的、技術スタック、アーキテクチャの概要、主要ディレクトリとその一言説明、およびあなたが意外に思った点を含む、簡潔な「リポジトリマップ」。

フェーズ 2 / 監査：証拠に基づき、重大度を明記する

以下の各側面について監査を実施してください。

各発見事項について、以下を記録してください：

a）何を発見したか

b）どこで発見したか（形式：ファイル:行番号）

c）なぜそれが重要なのか（抽象的な原則ではなく、具体的な結果）

d）重大度：Critical / High / Medium / Low

アーキテクチャと設計

モジュール境界、結合度/凝集度、循環依存、抽象化の漏洩、神オブジェクト/神ファイル、階層違反、スケーラビリティのボトルネック。

コード品質

重複コード、デッドコード、複雑性のホットスポット（最も長い関数、最も分岐の多い関数）、一貫性のないパターン、エラーハンドリングの欠陥（例外の無視、欠落したエッジケース）、型安全性の脆弱性。

セキュリティ

ハードコードされたキーや認証情報、インジェクションリスク、安全でないデシリアライゼーション、入力検証の欠落、認証/認可の弱点、既知のCVEを持つ古い依存関係、過度に緩い設定。

テスト

テストカバレッジのギャップ（特にコアビジネスロジック）、テスト品質（動作を検証しているのか、単に実行を確認しているだけか）、不足しているテストタイプ（ユニットテスト、統合テスト、E2Eテスト）、不安定なテストパターン、テストが困難なコード。

パフォーマンス

N+1クエリ、不要な割り当てやコピー、非同期パスでのブロッキングコール、キャッシュやインデックスの欠落、メモリ、ファイル、キューなどの無制限な成長問題。

依存関係

古い、メンテナンスされていない、重複した、または不必要な重い依存関係、ライセンスリスク、lockfileのメンテナンス状況。

開発体験と運用

ビルド/起動コスト、CI/CDのギャップ、lint/フォーマット強制の欠落、ログと可観測性の品質、エラーレポート、デプロイパス。

ドキュメント

READMEの正確性、オンボーディングパス、文書化されていない重要な動作、コードと矛盾する古いドキュメント。

本フェーズのルール

50の推測的な発見よりも、15の確信度の高い発見を提供する方が良いです。

事実と判断を区別してください。例：

·事実：「この関数にはエラーハンドリングがありません：src/api/client.ts:142」

·判断：「このモジュールの責務境界が不明確に感じられます」

そしてどちらがどちらかを明確に示してください。

同時に、このコードリポジトリの優れている点もリストアップしてください。強みも同様に重要であり、何を維持すべきかを決定します。

本フェーズの出力：側面ごとにグループ化し、重大度でソートし、Strengthsセクションを含む「監査レポート」。最も醜く、最優先で対処すべき問題を指摘することを忘れないでください。

フェーズ 3 / 改善戦略

監査結果を統合して戦略を策定します：

·ほとんどの問題を説明できる3～5つのテーマを特定します。例：「レイヤー間に強制された境界がない」「エラーハンドリングが場当たり的すぎる」。

·各テーマについて、目標状態とその背後にある原則を提案します。

·トレードオフを明確に述べます：どの問題を今は修正しないことを推奨し、その理由（労力対効果の不均衡、リスクが高い、プロジェクトの成熟度がまだそれを必要としないなど）を説明します。

·「完了」の定義を示します。測定可能なシグナルを提供します。例：「CIがlintエラーで失敗する」「コアモジュールのテストカバレッジが80%以上」「Criticalレベルの問題がゼロ」。

フェーズ 4 / 詳細タスク計画

戦略を実行計画に変換します：

作業を個別のタスクに分割します。各タスクには以下を含める必要があります：

·タイトルとタスクの説明

·影響を受けるファイル/領域

·受け入れ基準（完了をどう検証するか）

·作業量見積もり：S = 2時間未満、M = 半日、L = 1～2日、XL = さらなる分割が必要

·変更自体のリスク（既存機能を壊す可能性）

·他のタスクへの依存関係

タスクをマイルストーンでソートしてください：

Milestone 0

セーフティネット：安全なリファクタリングの前に完了すべき事項（クリティカルパスのテスト、CIゲート、バックアップなど）。

Milestone 1

クリティカル修正：セキュリティ問題と正確性の問題。

Milestone 2

レバレッジの高い改善：後続のすべての作業を容易にする変更。

Milestone 3

品質と仕上げ：残りの対応価値のある中低優先度の項目。

影響が大きく、Sサイズの作業量で、すぐに完了できるクイックウィンを個別に示してください。

上位3つのタスクについては、メソッド、主要ステップ、および陥りやすい落とし穴を含む簡単な実装スケッチを添付してください。

最終納品フォーマット

以下のセクションを含む単一のドキュメントを生成してください：

エグゼクティブサマリー：10文以内。全体的な健全性スコアA～Fを付け、その理由を説明。トップ3のリスクとトップ3の機会をリストアップ。

リポジトリマップ

監査レポート

改善戦略

タスク計画：マイルストーン、タスク表、クイックウィンを含む

未解決の質問：製品の意図、廃止可能なモジュール、パフォーマンス目標など、人間の判断が必要な情報をリストアップ。

制約

今回の監査プロセス中は、コードを一切変更しないでください。分析のみを行います。

レポートを水増ししないでください。ある側面が健全であれば、一文で述べて次に進んでください。

プロジェクトの成熟度に合わせて提案を調整してください。プロジェクトオーナーの目標が本当にそれを必要としない限り、週末プロトタイプのプロジェクトにエンタープライズ級のインフラを推奨しないでください。

プロジェクトの実際のニーズを分析し、最も効果的な方法でアドバイスを提供してください。

コードリポジトリが大きい場合は、作業の80%を担う最もコアな20%のコードを優先的に深く分析し、どの領域を浅くしかレビューしていないかを明示してください。

原文リンク