「 でコード書かせて、それをコピペでコミットしてます」と仰る方、よくいます。それでも一定の効果は出ますが、AIネイティブな受託開発の本領は別のところにあります。今回は、ふくふくが採用している「プロンプト一発に頼らない」スタイルを共有します。
受託開発で を「正しく」使う3原則
- 1コンテキスト設計を最重要視：CLAUDE.md・スタブ・参考実装を先に整える
- 2人間のレビューを必ず通す：マージ判断は人間、AIは下書き製造機
- 3並列で複数タスクを走らせる：単発生成より並列タスクで効率10倍
コンテキスト設計：3階層で渡す
L1 は CLAUDE.md でプロジェクト起動時に自動読み込み。L2 と L3 はタスクごとに渡します。「 モデル1個追加」を頼むなら、既存のよく似たモデル3つを `@models/marts/finance/fct_orders.sql` のように指定して参考実装として渡します。
プロンプトの実例：「悪い指示」と「良い指示」
| ❌ 悪い指示 | ✅ 良い指示 |
|---|---|
| 顧客の解約率を出すSQLを書いて | @models/marts/finance/fct_subscriptions.sql を参考に、月次解約率（churn_rate）を mart_subscriptions_monthly として実装。テストは fct_orders と同等粒度で。NULL扱い・タイムゾーンは既存モデル準拠 |
| リファクタして | @src/lib/legacy_adapter.py の関数を分割。@docs/architecture.md の責務分離に従う。後方互換は維持、テスト失敗ゼロ条件 |
| バグ直して | Issue #234 のバグ。再現手順・期待値・実際の値は issue 本文。@tests/test_billing.py に再現テスト追加してから修正 |
レビュー文化：AI 生成コードをマージしない条件
AI生成コードのマージ条件
(1) 人間が必ず読んだ、(2) テストが通った、(3) 既存パターンと整合性が取れている、の3つが揃わないとマージしない。これを徹底するだけで、後日のリファクタコストが激減します。
並列実行：1人で「3人並走」する技
ふくふくでは、1人の作業中に Claude Code に並列で別タスクを走らせるのが日常です。例：自分は仕様検討中、Claude Code に「既存テストの整理」「ドキュメント更新」「廃止コードの掘り起こし」を同時依頼。
並列タスクの依頼例
以下3つを並列で進めてください。完了したら統合状況をレポート。
## Task A: 既存テストの整理
- @tests/ で skip されているテストを全部洗い出し
- 「もう価値がないもの」「直せばまた使えるもの」を分類
- 廃止候補は削除PR、復活候補は修正PR
## Task B: ドキュメントの古さチェック
- @docs/ 内の各ファイルを最新コードと比較
- 説明と実装がズレている箇所を抽出
- 修正案を docs/ に PR
## Task C: 廃止候補コードの掘り起こし
- @src/ で6ヶ月以上 import されていないファイル
- 削除可能か lineage を調べて判定
- 削除PR の dry-run 想定される実行結果（例示）
## 並列実行レポート
### Task A: テスト整理（完了）
- skip されたテスト 23件
- 削除候補 14件（PR #145 として作成）
- 復活候補 9件（PR #146）
- 残課題: 該当機能の責任者確認待ち 2件
### Task B: ドキュメント古さチェック（完了）
- 古いドキュメント 8ファイル特定
- 修正案を PR #147 で提案
- 大きな乖離: docs/architecture.md の図3つが古い → 新規生成
### Task C: 廃止候補コード（完了）
- 6ヶ月import無しファイル 12個発見
- うち削除安全 8個（PR #148）
- 残4個: lineageに痕跡あり、削除前に再確認推奨
3つのPRが同時に開きました。マージは順番（Task B → A → C）推奨。次回予告
EP.03 では、見積もりが3倍速くなった、要件定義時の Claude Code 活用法をお届けします。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。