lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
ホーム
OPRR
速報
深堀り
イベント
BlockBeats Pro
もっと見る
資金調達情報
特集
オンチェーン生態系
用語
ポッドキャスト
データ
BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
Partnered With:

Claude Fable 5を最も活用すべきことは、コードリポジトリの包括的な監査を実施することです。

この記事を読むのに必要な時間は 16 分
コード作成からコード検証へ、AIがエンジニアリング監査の現場に参入し始めている
原文著者: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 / 発見と整理:まず読み、次に判断する


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


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

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

·パッケージマニフェスト、ロックファイル、ビルド設定、CI設定、環境/設定ファイル、およびREADME、CONTRIBUTING、ADRなどのすべてのドキュメントを読む。

·このプロジェクトの目的を判断する:その目標、想定ユーザー、現在の成熟度(プロトタイプ、内部ツール、本番サービス、ライブラリのいずれか)。

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


このフェーズの出力:プロジェクトの目的、技術スタック、アーキテクチャスケッチ、主要ディレクトリとその一言説明、および驚いた点を含む、簡潔な「コードリポジトリマップ」。


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


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


各発見事項について、以下を記録すること:


a)何を発見したか

b)どこで発見したか(形式:ファイル:行番号)

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

d)重大度:Critical / High / Medium / Low


アーキテクチャと設計

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


コード品質

重複コード、デッドコード、複雑性のホットスポット(最長関数、最も分岐の多い関数を含む)、一貫性のないパターン、エラーハンドリングの欠陥(例外の無視、境界ケースの欠落など)、型安全性の脆弱性。


セキュリティ

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


テスト

テストカバレッジの欠落(特にコアビジネスロジック)、テスト品質(動作を検証しているか、単に動作確認だけか)、欠落しているテストタイプ(ユニットテスト、統合テスト、エンドツーエンドテスト)、不安定なテストパターン、テストが難しいコード。


パフォーマンス

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


依存関係

古くなった、メンテナンスされていない、重複している、または不要な重い依存関係;ライセンスリスク;ロックファイルのメンテナンス状況。


開発体験と運用

ビルド/起動コスト、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 = さらなる分割が必要

・変更自体のリスク(既存機能を壊す可能性があるかどうか)

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


タスクをマイルストーンごとに並べること:

マイルストーン0

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


マイルストーン1

重要な修正:セキュリティ問題と正確性の問題。


マイルストーン2

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


マイルストーン3

品質と磨き上げ:残りの対応価値がある中低優先度の事項。


Quick Wins(影響が大きく、Sサイズの作業量で、すぐに完了できるタスク)を個別に明記すること。


上位3つのタスクについては、手法、主要ステップ、陥りやすい落とし穴を含む簡潔な実装スケッチを添付すること。


最終納品フォーマット

以下のセクションを含む単一のドキュメントを生成すること:

エグゼクティブサマリー:10文以内。全体的な健全性スコアをA~Fで示し、その理由を説明。上位3つのリスクと上位3つの機会を列挙。

リポジトリマップ

監査レポート

改善戦略

タスク計画:マイルストーン、タスク表、Quick Winsを含む

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


制約


本監査中は、いかなるコードも変更しないこと。分析のみを行うこと。


レポートを埋めないこと。ある次元が健全であれば、一文で説明し、次に進むこと。


プロジェクトの成熟度に応じた推奨事項を調整すること。プロジェクトオーナーの目標が本当に必要としない限り、週末に作ったプロトタイプにエンタープライズ級のインフラを推奨してはいけない。


プロジェクトの真のニーズを分析し、最も効率的な方法でアドバイスを提供すること。


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


[原文リンク]



BlockBeats の公式コミュニティに参加しよう:

Telegram 公式チャンネル:https://t.me/theblockbeats

Telegram 交流グループ:https://t.me/BlockBeats_App

Twitter 公式アカウント:https://twitter.com/BlockBeatsAsia

举报 訂正/通報
ライブラリを選択
新しいライブラリを追加
キャンセル
完了
新しいライブラリを追加
自分のみが閲覧可
公開
保存
訂正/通報
送信