ソース駆動開発

概要

フレームワーク固有のコード決定は、すべて公式ドキュメントによって裏付けられなければなりません。記憶に頼って実装するのではなく、検証し、引用し、ユーザーにソースを確認させましょう。トレーニングデータは陳腐化し、API は廃止され、ベストプラクティスは進化します。このスキルにより、ユーザーは信頼できるコードを得られます。なぜなら、すべてのパターンは、ユーザーが確認できる信頼できるソースにさかのぼるからです。

いつ使うか

• ユーザーが特定のフレームワークの現在のベストプラクティスに従ったコードを求めている
• ボイラープレート、スターターコード、またはプロジェクト全体でコピーされるパターンを構築している
• ユーザーが明示的にドキュメント化された、検証された、または「正しい」実装を求めている
• フレームワークの推奨アプローチが重要な機能を実装している (フォーム、ルーティング、データ取得、状態管理、認証)
• フレームワーク固有のパターンを使用しているコードをレビューまたは改善している
• フレームワーク固有のコードを記憶から書こうとしている時点で

使わないでよい場合:

• 正確性が特定のバージョンに依存していない (変数の名前変更、typo 修正、ファイルの移動)
• すべてのバージョン共通で同じように動作する純粋なロジック (ループ、条件分岐、データ構造)
• ユーザーが明示的に検証より速度を優先している ("とにかく素早くやってくれ")

プロセス

検出 ──→ 取得 ──→ 実装 ──→ 引用
 │        │        │       │
 ▼        ▼        ▼       ▼
どの    関連する  ドキュメント  ソースを
スタック? ドキュメントを化されたパターン  示す
         取得する     に従う

ステップ1: スタックとバージョンを検出

プロジェクトの依存ファイルを読んで、正確なバージョンを特定します:

package.json    → Node/React/Vue/Angular/Svelte
composer.json   → PHP/Symfony/Laravel
requirements.txt / pyproject.toml → Python/Django/Flask
go.mod          → Go
Cargo.toml      → Rust
Gemfile         → Ruby/Rails

見つけたものを明示的に述べます:

スタック検出:
- React 19.1.0 (package.json から)
- Vite 6.2.0
- Tailwind CSS 4.0.3
→ 関連するパターンの公式ドキュメントを取得中です。

バージョンが不明確または曖昧な場合は、ユーザーに質問してください。推測しないでください。バージョンが正しいパターンを決定します。

ステップ2: 公式ドキュメントを取得

実装している機能の特定のドキュメントページを取得します。ホームページではなく、完全なドキュメントでもなく、関連するページです。

ソース階層 (信頼度順):

優先度	ソース	例
1	公式ドキュメント	react.dev、docs.djangoproject.com、symfony.com/doc
2	公式ブログ / チェンジログ	react.dev/blog、nextjs.org/blog
3	ウェブ標準リファレンス	MDN、web.dev、html.spec.whatwg.org
4	ブラウザ/ランタイム互換性	caniuse.com、node.green

信頼できない — プライマリソースとして引用しないでください:

• Stack Overflow の回答
• ブログ記事またはチュートリアル (人気のあるものでも)
• AI が生成したドキュメントまたは要約
• 独自のトレーニングデータ (これが全ポイントです — 検証してください)

取得する内容を正確に:

悪い例:  React ホームページを取得する
良い例: react.dev/reference/react/useActionState を取得

悪い例:  「django authentication best practices」で検索
良い例: docs.djangoproject.com/en/6.0/topics/auth/ を取得

取得後、主要なパターンを抽出し、廃止予定の警告またはマイグレーションガイダンスに注意してください。

公式ソースが互いに矛盾する場合 (例: マイグレーションガイドが API リファレンスと矛盾している)、ユーザーに矛盾を提示し、検出されたバージョンに対して実際に機能するパターンを検証してください。

ステップ3: ドキュメント化されたパターンに従って実装

ドキュメントに示されているコードを書きます:

• ドキュメントの API シグネチャを使用します。記憶からではなく
• ドキュメントに新しい方法が示されている場合は、新しい方法を使用します
• ドキュメントがパターンを廃止している場合は、廃止予定バージョンを使用しません
• ドキュメントが何かをカバーしていない場合は、検証されていないとしてフラグを立てます

ドキュメントが既存のプロジェクトコードと矛盾する場合:

矛盾を検出:
既存のコードベースはフォームの読み込み状態に useState を使用していますが、
React 19 ドキュメントはこのパターンに useActionState を推奨しています。
(ソース: react.dev/reference/react/useActionState)

オプション:
A) モダンパターンを使用する (useActionState) — 現在のドキュメントと一致
B) 既存コードに合わせる (useState) — コードベースと一致
→ どちらのアプローチを好みますか?

矛盾を提示します。黙って一つを選ばないでください。

ステップ4: ソースを引用

すべてのフレームワーク固有のパターンは引用を取得します。ユーザーはすべての決定を検証できなければなりません。

コードコメント内:

// React 19 フォーム処理 useActionState 使用
// ソース: https://react.dev/reference/react/useActionState#usage
const [state, formAction, isPending] = useActionState(submitOrder, initialState);

会話内:

フォーム送信状態に useActionState を使用しています。手動の useState の代わりに
React 19 は手動の isPending/setIsPending パターンをこのフックで置き換えました。

ソース: https://react.dev/blog/2024/12/05/react-19#actions
「useTransition は非同期関数に対応するようになり、保留中の状態を
自動的に処理します」

引用ルール:

• 短縮されていない完全な URL
• 可能な限りアンカー付きのディープリンクを推奨 (例: /useActionState より /useActionState#usage) — アンカーはトップレベルページより文書の再構成に強い
• 非明白な決定を支持する場合は関連する一節を引用
• プラットフォーム機能を推奨する場合はブラウザ/ランタイムサポートデータを含める
• パターンのドキュメントが見つからない場合は、明示的に言及してください:

検証されていません: このパターンの公式ドキュメントが見つかりませんでした。
これはトレーニングデータに基づいており、廃止されている可能性があります。
本番環境で使用する前に検証してください。

検証できなかったことについての正直さは、虚偽の確信よりも価値があります。

一般的な正当化

正当化	現実
「この API について確信している」	確信は証拠ではありません。トレーニングデータには、正しく見えるが現在のバージョンに対して破損する廃止予定パターンが含まれています。検証してください。
「ドキュメントの取得はトークンを浪費する」	API の幻覚化がより浪費します。ユーザーは 1 時間デバッグし、その後関数シグネチャが変更されたことを発見します。1 回の取得で数時間の再作業を防ぎます。
「ドキュメントに必要なものがない」	ドキュメントがカバーしていない場合、それは貴重な情報です — パターンが公式に推奨されていない可能性があります。
「古い可能性があると言及するだけです」	免責事項では役に立ちません。検証して引用するか、明確に検証されていないとしてフラグを立ててください。曖昧にすることは最悪のオプションです。
「これは簡単なタスクなので、確認する必要はない」	間違ったパターンの簡単なタスクはテンプレートになります。ユーザーは廃止予定のフォームハンドラーを 10 個のコンポーネントにコピーしてから、モダンアプローチが存在することを発見します。

赤旗

• そのバージョンのドキュメントを確認せずにフレームワーク固有のコードを書く
• API について「信じている」または「思う」代わりに引用元を使用する
• どのバージョンに適用されるかを知らずにパターンを実装する
• 公式ドキュメントの代わりに Stack Overflow またはブログ投稿を引用する
• トレーニングデータに表示されるため廃止予定 API を使用する
• 実装する前に package.json / 依存ファイルを読まない
• フレームワーク固有の決定のソース引用なしでコードを配信する
• 関連するページが 1 つだけの場合、ドキュメントサイト全体を取得する

検証

ソース駆動開発で実装した後:

• フレームワークとライブラリのバージョンが依存ファイルから識別されている
• フレームワーク固有のパターンの公式ドキュメントが取得されている
• すべてのソースが公式ドキュメントであり、ブログ記事やトレーニングデータではない
• コードが現在のバージョンのドキュメントに示されているパターンに従っている
• 非自明な決定には完全な URL を含むソース引用がある
• 廃止予定 API は使用されていない (マイグレーションガイドに対して確認)
• ドキュメントと既存コード間の矛盾がユーザーに提示されている
• 検証できないことはすべて明示的に検証されていないとしてフラグが立てられている