はじめに
Claude Codeで開発するとき、TDD？仕様駆動？バイブコーディング？
エージェントチームと「Claude Codeのベストな開発手法」について本気で議論してみた。
本記事では、Qiita・X等で公開されている記事・投稿を出典付きで引用させていただきました。有益な知見を公開してくださっている執筆者の皆さまに感謝いたします。引用に問題がある場合はお知らせください。速やかに対応いたします。
質問１
claudecodeとコーディングをするときはどういう手法で行うのがいいと思いますか？
私はベストプラクティスはありますが、先に言って合わせられても困るので言わないでおきます。
まずはチームのみんなで議論して下さい。
回答
了解しました。チームメンバーで自由に議論させますね。まずチーム定義の読み込みとRAG検索を行います。
RAG検索でかなり有用な情報が見つかりました。詳細を取得しつつ、チーム議論に必要なエージェント定義も読み込みます。
情報が揃いました。チームで議論を始めます。
【PM/チームリーダー】チーム議論開始
お題は「Claude Codeとコーディングをするとき、どういう手法で行うのがベストか？」。
ユーザーはご自身のベストプラクティスをお持ちだが、先入観を避けるため先に我々で自由に議論する形にしたいとのこと。RAGから関連する技術記事・公式ドキュメントも複数ヒットしているので、それも踏まえて各自意見を出してほしい。
では、順番に。
【アーキテクト】設計ファーストの視点
私の意見は明確だ。「いきなりコードを書かせない」。これに尽きる。
Claude Codeは非常に優秀だが、方向性がズレたまま精緻化されるのが最大のリスクだ。RAGにもあったが、ある実践者がv1を必ず人間が見るルールにしているのは、方向性がずれたまま精緻化されるのを防ぐためと書いている。私も同感。
具体的に推奨する手順は：
- 要件を先にドキュメントで固める — SPEC.mdなりPLAN.mdなり、形式は問わないが「何を作るか」をClaudeと人間が合意してから動く
- CLAUDE.mdにアーキテクチャ制約を書く — 技術スタック、ディレクトリ構成、設計パターン等を明記。これがないとClaude Codeは毎回違う判断をする
- 小さい単位で実装→人間レビュー→次へ — 一気に100行書かせるより、20行ずつ確認した方が手戻りが圧倒的に少ない
公式ドキュメントにも「Explore→Plan→Code」の順で進めるとある。これはアーキテクト視点からも完全に正しい。
【コードアナリスト】実装者の現場感覚
アーキテクトの言うことは正論だが、現場の実装速度とのバランスも大事だ。
私の経験から言うと、Claude Codeとのコーディングで最も効果的なのは TDD（テスト駆動開発） だ。RAGにもt-wadaのTDD（Red→Green→Refactor）をCLAUDE.mdに書いておくとClaude Codeが自然にそのサイクルで動いてくれるという実践例があった。
なぜTDDが効くか：
- 検証基準が自動化される — Claude Codeに「テストを通すコードを書け」と言えば、自分で修正→テスト→修正のループを回せる
- 人間の介入ポイントが明確 — テストコードのレビューだけ人間がやればいい。実装コードはテストが担保する
- 手戻りコストが最小 — テストが壊れたらすぐわかる
公式のベストプラクティスにも「検証手段を提供する」が第1項に来ている。テストこそが最良の検証手段だ。
ただし、仕様が曖昧な段階でTDDは使えない。その場合はプロトタイプ的に書かせて、動くものを見てから仕様を固める方が速い。
【QAエンジニア】品質保証の観点
コードアナリストのTDD推しには基本的に賛成だが、TDDだけでは不十分な局面がある。
RAGにあった記事で「ドキュメント・実装・E2Eテストが一緒に育った」という実践例が印象的だった。PoC段階ではE2Eテストが「Copilot（やClaude）の出力を確認するための基準点」になるという話。これは重要な視点だ。
私の提案：
| フェーズ | 検証手法 | 目的 |
|---|---|---|
| 要件定義 | 受入テスト条件を先に書く | 何をもって「完了」とするかの合意 |
| 実装中 | ユニットテスト（TDD） | コードの正しさの担保 |
| 統合後 | E2Eテスト or 手動確認 | 全体としての動作確認 |
Claude Codeに「テストも一緒に書いて」と指示するのは有効だが、テスト自体の品質を人間がレビューしないと危険。Claude Codeが書くテストは「実装に合わせたテスト」になりがちで、仕様に基づいたテストになっていないことがある。
【テクニカルリサーチャー】調査結果の報告
RAGと自身の知識から、現在の主要なアプローチを整理した：
注目すべき点を3つ：
-
cc-sdd（仕様駆動開発ツール） が2026年3月に登場。仕様→要件→設計→タスク→TDD実装の全フェーズをスラッシュコマンドで進められる。ただし「マルチエージェント対応がなく速度面で劣る」という報告もある
-
Karpathy GuidelinesがClaude Code界隈で広まっている。「検証基準が明確であればあるほど、人間の介入なしにLLMが自走できる範囲が広がる」という原則
-
プロジェクト構造の重要性 — 「リポジトリが雑然としているとClaude Codeはチャットボットとして振る舞い、構造化されていればプロジェクトネイティブなエンジニアとして振る舞う」という指摘がある
【AI/MLエンジニア】AIエージェントとの協業の本質
皆の議論を聞いていて、一つ重要な視点が抜けていると思う。
Claude Codeはエージェント型AIだ。つまり「計画→実行→検証」を自律的に回せる。この特性を活かすか殺すかで、手法の効果が全然違う。
AIエージェントの自走を最大化するために必要なもの：
- 明確なゴール定義 — 「何ができたら完了か」を先に定義する。テストでもスクリーンショットでも出力例でもいい
- 制約の明示 — CLAUDE.mdに「やってはいけないこと」を書く。これがないとAIは自由に判断しすぎる
- フィードバックループの設計 — AIが自分で「これでいいのか」を検証できる仕組み（テスト、lint、型チェック等）
逆にやってはいけないこと：
- 1行ずつ指示を出す（AIの自律性を殺す）
- 曖昧な指示で大量のコードを一気に書かせる（検証不能になる）
- 結果だけ見てフィードバックしない（AIが学習しない）
【デビルズアドボケイト】ここまでの議論への反論
全員がもっともらしいことを言っているが、いくつか問題点を指摘する。
懸念1: 「仕様を先に書く」は万能ではない
アーキテクトの「設計ファースト」は正しいが、個人開発や小規模タスクでは過剰。SPEC.mdを書く時間でコードが3つ書ける場面もある。タスクの規模によって手法を変えるべきだが、その使い分け基準を誰も語っていない。
懸念2: TDDの「テスト自体の品質」問題
QAが正しく指摘した通り、Claude Codeに「テストを書いて」と言うと実装に追従するテストを書く。これはTDDの思想と逆だ。TDDをやるならテストは人間が先に書く（またはレビューする） 必要がある。この手間をどう評価するか。
懸念3: 手法にこだわりすぎるリスク
「正しい手法」を探すこと自体がアンチパターンになりうる。Claude Codeの強みは柔軟性だ。固定の手法に縛ると、その柔軟性を殺す。重要なのは手法そのものではなく、「いつ人間が介入するか」のタイミング設計ではないか。
隠れた前提のチェック
| 暗黙の前提 | リスク |
|---|---|
| Claude Codeは指示通りに動く | 実際はコンテキスト制限で忘れる・ズレる |
| CLAUDE.mdを書けば従う | 長すぎるCLAUDE.mdは逆効果（メモリ圧迫） |
| TDDでコード品質が担保される | テスト自体の品質は担保されない |
| 仕様書を先に書けば手戻りが減る | 仕様書作成自体のコストが無視されている |
【ファクトチェッカー】事実検証
議論中に出た主張の検証結果：
| 主張 | 検証結果 | 判定 |
|---|---|---|
| 公式が「Explore→Plan→Code」を推奨 | RAGに公式ドキュメント確認済み。第2項に記載 | 正確 |
| 「検証手段の提供」が公式ベストプラクティス第1項 | RAGで確認。正しい | 正確 |
| cc-sddにマルチエージェント対応がない | RAGの記事に「マルチエージェント実装対応は現状なく、速度面で劣る」と明記 | 正確 |
| CLAUDE.mdが長すぎると逆効果 | 公式ドキュメントに「メモリ圧迫につながるので詳細ドキュメントは記載しない」旨の記述あり | 正確 |
| Karpathy Guidelinesの内容 | RAGに記事あり。「検証基準が明確であればあるほど、LLMが自走できる範囲が広がる」は正確 | 正確 |
【PM/チームリーダー】議論の総括
各メンバーの意見を整理する。
全員が合意している点
- いきなりコードを書かせない — 何らかの形で「計画」フェーズを入れる
- 検証手段を用意する — テスト、スクリーンショット、出力例など
- CLAUDE.mdへの投資が重要 — プロジェクトのルール・制約を明示する
- 人間の介入ポイントを設計する — 完全自動化ではなく、要所で人間がチェックする
意見が分かれた点
- 手法の固定度: 仕様駆動でガチガチに固めるか、状況に応じて柔軟に切り替えるか
- TDDの適用範囲: テストを人間が書くか、AIが書いたテストをレビューするか
- タスク規模による使い分け: 小規模タスクでもドキュメントを作るべきか
チームとしての暫定見解
デビルズアドボケイトが指摘した「タスク規模による使い分け」は的を射ている。一つの手法で全てをカバーしようとするのは非現実的だ。
ただし、規模にかかわらず共通して守るべき原則はある：
- 検証手段（テスト・確認方法）を先に決める
- CLAUDE.mdでプロジェクトのルールを伝える
- AIに自走させつつ、要所で人間がレビューする
ユーザーさん、これがチームの議論結果です。ユーザーさんのベストプラクティスと比べて、どこが合っていて、どこが抜けているか、ぜひ教えてください。
質問２
私があなた達を構築して以降ずっとおこなってきた手法が今のところ私にはしっくりきています。
それは『開発規模を機能単位に小さく絞り、ひとつずつ指示を出しながら一緒に作り上げていくこと』
KB（KAをブラウザで起動させる仕組み）についてもそうですし、他の画面にしても空画面を作ってくれ、ボタンをつけてくれから仕様を詰めて行きました。経験上これが一番早い。
ただし。これは私が依頼人でもあったから出来たことでいわばバイブコーディングに近い開発なのかと思います。ただ、スパイラルとは本来こういう動きなのかな？とも思いました。
テストはもちろんTDDもUNITもE2EもLintも使えるものは使った方が精度が上がるとは思いますが、その時の内容と時間も加味してベストな選択が必要だと思います。
回答
ユーザーのベストプラクティスについてチームで議論します。
【PM/チームリーダー】
非常に実践的なアプローチだ。チームの前回の議論と照らし合わせて、各自意見を出してほしい。特に注目すべきポイントは3つある：
- 「機能単位に小さく絞り、ひとつずつ」 というスコーピング手法
- 依頼人＝開発者だったからこそ成立したという自己分析
- テストはケースバイケースで使い分ける という現実的な判断
【PMコンサルタント】プロセス論の観点
ユーザーが「スパイラルとは本来こういう動きなのかな？」と感じたのは、正確な直感だと思う。
これはソフトウェア工学的に整理すると、インクリメンタル開発とスパイラルモデルのハイブリッドだ。
- インクリメンタルの要素：機能単位を小さく区切って「完成品」を積み上げる
- スパイラルの要素：各サイクルで「作る→見る→仕様を詰める」のリスク低減ループを回す
ただし、ユーザーが指摘した通り重要な前提条件がある。依頼人と実装判断者が同一人物だからこそ、仕様確認のラウンドトリップがゼロになる。通常のスパイラルでは「ステークホルダーレビュー→フィードバック→修正」のサイクルに時間がかかるが、バイブコーディング的にその場で判断・修正できるのは圧倒的に速い。
これを方法論として名づけるなら「マイクロインクリメンタル開発」とでも呼ぶべきもので、Claude Codeとの相性が非常に良い。
【アーキテクト】設計視点からの分析
前回私は「いきなりコードを書かせない」と言ったが、ユーザーのアプローチはそれと矛盾しない。
「空画面を作ってくれ」→「ボタンをつけてくれ」は一見「いきなりコードを書いている」ように見えるが、実は各ステップの仕様が極めて明確だ。「空画面」も「ボタン」も解釈のブレがほぼない指示であり、指示自体が仕様書の役割を果たしている。
つまりこのアプローチの本質は：
仕様ドキュメントを書く代わりに、指示の粒度を極小にすることで仕様のブレを排除している
SPEC.mdを書いて大きな機能を一括で作らせるアプローチとの比較：
| 観点 | SPEC.md一括型 | マイクロインクリメンタル型 |
|---|---|---|
| 仕様のブレ | ドキュメントの解釈で発生しうる | 指示が小さすぎてブレようがない |
| 手戻りコスト | 大（大量コード修正） | 極小（前のステップに戻るだけ） |
| 全体整合性 | 事前に設計で担保 | 作りながら頭の中で統合 |
| 必要な前提 | 設計文書力 | ドメイン知識と判断力 |
最後の行が重要で、マイクロインクリメンタルでは人間の頭の中に設計図があることが前提になる。ドメイン知識も判断力もない人がやると、場当たり的なコードの寄せ集めになるリスクがある。ユーザーが成功しているのは、何を作りたいかが明確に頭の中にあるからだ。
【コードアナリスト】実装者の実感
完全に同意する。KBブラウザの開発を振り返ると、この手法が一番速かった実感がある。
前回TDDを推したが、ユーザーの言う通り常にTDDが最適とは限らない。特にUI開発やプロトタイピングでは、テストを先に書くよりも動くものを見て判断する方が圧倒的に速い。
使い分けの基準として私が実感しているのは：
- 見た目で判断できるもの（UI、画面遷移、表示内容） → マイクロインクリメンタル
- 動作の正しさが目視確認困難なもの（データ処理、API、計算ロジック） → TDD
ユーザーの「その時の内容と時間も加味してベストな選択が必要」というのは、まさにこの使い分けのことだと思う。
【QAエンジニア】品質保証の折り合い
前回テストの重要性を主張したが、ユーザーの視点は現実的で正しいと思う。
テスト手法の投資対効果はプロジェクトのフェーズと規模で劇的に変わる：
| フェーズ | テスト投資の効果 | 推奨 |
|---|---|---|
| プロトタイプ/初期開発 | 低（仕様が変わるため） | 人間の目視確認 |
| 機能安定後 | 高（リグレッション防止） | ユニットテスト追加 |
| 本番運用中 | 最高（障害防止） | E2E + 監視 |
KBブラウザのような「自分が使うツール」で、かつ開発初期の段階では、テストを書く時間で3つ機能を追加できる。それは合理的な判断だ。ただし、機能が安定してきた段階で「ここは壊れると困る」というポイントにテストを入れるのは忘れないでほしい。
【デビルズアドボケイト】批判的検証
概ね良い議論だが、リスクも明確にしておく必要がある。
このアプローチが危険になるケース：
- 複数人開発に移行した場合 — 頭の中の設計図が共有されない。ドキュメントなしだと他人が触れないコードになる
- 規模が大きくなった場合 — マイクロインクリメンタルの積み重ねで「全体の整合性」が崩れる可能性がある（実際KBブラウザのindex.htmlは既に大きい）
- 依頼人≠開発者になった場合 — ユーザー自身が指摘した通り、フィードバックループの即時性が失われる
ただし、現在のプロジェクト規模と体制を考えれば、このリスクは許容範囲内だ。問題が顕在化するのはチーム開発や規模拡大の局面であり、そのときに手法を適応させればよい。
【ファクトチェッカー】用語の整理
「バイブコーディング」との類似性についてだが、厳密には異なる点がある。
- バイブコーディング（Andrej Karpathy提唱）：AIに丸投げして「雰囲気（vibe）」で進める。人間はコードをほぼ読まない
- ユーザーのアプローチ：各ステップで人間が動作確認し、次の指示を判断している。つまり設計判断は人間が握っている
ユーザーのアプローチは「バイブコーディングに近い」とご本人も言っているが、本質的にはペアプログラミングに近い。Claude Codeがジュニア開発者役で、ユーザーがシニア開発者兼プロダクトオーナー役という構図だ。
【PM/チームリーダー】まとめ
チームの議論を総括する。
ユーザーのアプローチ「機能単位に小さく絞り、ひとつずつ指示を出しながら一緒に作り上げる」は、以下の理由で非常に合理的な手法だとチーム全員が認めている：
- 指示の粒度を極小にすることで、仕様のブレとコミュニケーションコストを同時に排除している
- 各ステップで人間が判断を入れることで、AIの暴走を防いでいる
- テスト手法の選択を状況に応じて柔軟にしている
成功の前提条件として「人間側にドメイン知識と設計判断力がある」ことが必要であり、ユーザーがそれを持っているからこそ成立している。
PMコンサルタントの「マイクロインクリメンタル開発」、ファクトチェッカーの「シニア＋ジュニアのペアプログラミング構図」という整理が、この手法の本質をよく捉えていると思う。
質問３
各自意見を出したと思うが、今までの意見を踏まえて改めて問う。
ClaudeCodeで安定して精度の高い開発を行うにはどの手法を用いどんなことに気をつければいいと思うか？
回答
前回までの議論を踏まえた総括的な回答を出します。まずチーム定義とRAGを確認します。
さらに詳細な情報を取得します。
情報が揃いました。前回までの議論を踏まえ、チーム全員の最終見解をまとめます。
【PM/チームリーダー】最終討議の開始
2回の議論を経て、各自の意見は出揃った。今回は総括として、「Claude Codeで安定して精度の高い開発を行うにはどの手法を用い、どんなことに気をつければいいか」に対するチームとしての統一見解を出す。
各自、前回までの自分の意見と他メンバーの意見を踏まえた上で、最終意見を述べてほしい。
【アーキテクト】基盤設計の最終見解
3回の議論を通じて、私の結論は明確になった。
手法そのものよりも、「Claude Codeの判断品質を支える仕組み」が安定性を左右する。
具体的に最も効くのは以下の3層構造だ：
第1層（CLAUDE.md）が最重要。RAGにもあった通り「リポジトリが構造化されていればClaude Codeはプロジェクトネイティブなエンジニアとして振る舞う」。逆にこれがないと、同じ質問に毎回違う回答を返す不安定なチャットボットになる。
ユーザーが実践してきたマイクロインクリメンタル手法が機能するのも、CLAUDE.mdでプロジェクトの制約が定義されている前提があるからこそだ。手法と基盤はセットで語るべき。
【コードアナリスト】実装者の最終見解
前回TDDを推し、その後ユーザーのマイクロインクリメンタルを聞いて使い分け論に落ち着いた。今回の最終見解はこうだ：
「安定して精度が高い」を実現する最大の鍵は、Claude Codeに渡すコンテキストの質である。
RAGの記事にあった「コンテキストウィンドウが圧迫されると精度が下がる」は我々も実体験として知っている。KBブラウザ開発でも、セッションが長くなると指示と異なる挙動が増えた。
具体的に気をつけるべきこと：
| 項目 | やるべきこと | やってはいけないこと |
|---|---|---|
| 指示の粒度 | 1指示1機能。曖昧さゼロ | 「いい感じにして」「全体的に改善して」 |
| コンテキスト管理 | 区切りごとに /clear。重要情報はファイルに外出し |
1セッションで大量の機能を詰め込む |
| 既存コードの尊重 | 変更箇所を最小限に指定 | 「リファクタリングもしておいて」 |
| テストの使い分け | ロジック系はTDD、UI系は目視 | 全部にTDDを強制 / 全部テストなし |
特に強調したいのは「1指示1機能」。ユーザーの手法はまさにこれを体現している。「空画面を作ってくれ」「ボタンをつけてくれ」——指示の解釈ブレがほぼゼロだ。Claude Codeの精度は指示の明確さに比例する。
【QAエンジニア】品質保証の最終見解
品質面から一点補足したい。
マイクロインクリメンタルでは各ステップの動作確認が品質ゲートの代替になっている。つまりユーザーの目が最高のテストツールだ。ただし、これが機能するのはプロジェクトの全体像が頭に入っている開発者の場合に限る。
安定性を支えるために重要な注意点：
- リグレッション防止: 小さい修正の積み重ねで、以前の機能が壊れることがある。重要なロジックには自動テストを入れておくことで、人間の目が見落とす退行を検出できる
- 「動いた」と「正しい」の区別: Claude Codeが書いたコードが動くことと、仕様通りであることは別。特にエッジケースの処理は動作確認だけでは見つからない
- テストはコスパで選ぶ: ユーザーが言う「その時の内容と時間も加味して」は完全に正しい。全部にテストを書くのは非現実的で、壊れたら困る箇所にだけ書けばいい
【PMコンサルタント】プロセス論の最終見解
3回の議論を通じて、Claude Codeにおける開発プロセスの本質が見えてきた。
結論：Claude Codeとの開発は、手法を「選ぶ」のではなく「組み合わせる」ものだ。
RAGで見つけた「プチ仕様駆動開発」（PLAN.md / SPEC.md / TODO.md / KNOWLEDGE.md）も良い仕組みだが、ユーザーの手法が本質的にこれと同じことをドキュメントレスに達成している点が面白い。仕様書の代わりに「小さい指示」で仕様を伝え、TODO.mdの代わりに「頭の中の設計図」でタスクを管理し、KNOWLEDGE.mdの代わりにCLAUDE.mdとRAGに知見を蓄積している。
要するに、形式はどうあれ「認識齟齬の排除」と「知見の永続化」が達成できていれば安定する。
【テクニカルリサーチャー】技術的裏付け
RAGと公式ドキュメントの調査結果をまとめる。
Claude Code公式ベストプラクティスの核心は以下の3つ：
- 検証手段を提供する（テスト、Lint、型チェック等）
- CLAUDE.mdでルールを明示する
- Explore → Plan → Code の順で進める
これらはいずれも、我々の議論で出た結論と整合している。特に注目すべきは、RAGにあった複数の実践者の共通パターンだ：
| 実践者 | アプローチ | 共通点 |
|---|---|---|
| ユーザー（本人） | マイクロインクリメンタル | 小さい単位、即時確認 |
| minorun365氏 | プチ仕様駆動開発 | 仕様合意→小さく実行 |
| _Nanagin氏 | 発注スキル型 | ドメイン知識で判断、Claude実装 |
| cc-sdd | 仕様駆動開発（SDD） | SPEC→TDD→検証 |
| 公式 | Explore→Plan→Code | 理解→計画→実装 |
全員に共通するのは「いきなり大きいものを作らせない」こと。 仕様書を書くか・小さい指示で代替するか・TDDで検証するかは、その人の立場とプロジェクトの性質で変わる。
【AI/MLエンジニア】LLMの特性から見た注意点
Claude Codeの中核はLLMだ。LLMの特性を理解した上で注意すべき点を挙げる：
-
コンテキストウィンドウの有限性: 長いセッションでは情報が圧縮・欠落する。区切りのいいところで
/clearし、CLAUDE.mdやファイルに重要情報を外出しする - 確率的な出力: 同じ指示でも毎回異なるコードが出る可能性がある。CLAUDE.mdで制約を与えることで出力のばらつきを抑制できる
- 最新情報の限界: 学習データのカットオフがあるため、最新のライブラリ仕様はRAGや公式ドキュメントへのリンクで補完する
- 「自信満々に間違える」: LLMは不確かな情報も確信をもって出力する。人間の確認ステップは省略してはいけない
これらはすべて、マイクロインクリメンタル手法が自然に対処している。小さく作って確認するサイクルは、LLMの確率的な誤りを早期に検出する仕組みとして機能する。
【デビルズアドボケイト】批判的検証
ここまでの全員の意見に概ね同意するが、見落とされているリスクを指摘する。
1. マイクロインクリメンタルの弱点：「全体の整合性が人間の頭にだけある」問題
前回アーキテクトも指摘したが、この手法はドメイン知識と判断力がある人間が前提だ。プロジェクトが複雑化した場合や、担当者が変わった場合に「頭の中の設計図」は引き継げない。中長期的にはアーキテクチャの明文化（ADR等）も必要になる可能性がある。
2. 「テストはケースバイケース」の落とし穴
これは正しいが、「今回はテスト不要」の判断が続くと、気づいたときにはテストゼロのコードベースになる。壊れたら困る箇所の基準を事前に決めておくべきだ。
3. CLAUDE.md肥大化リスク
全部CLAUDE.mdに書くとコンテキストウィンドウを圧迫する。RAGの知見にもあったが「最重要ルールだけ残し、残りはrules/に分ける」のが正解だ。
【ファクトチェッカー】事実性検証
各エージェントの発言に含まれる事実情報を検証した結果：
- 公式ベストプラクティスの内容: RAGに登録済みの公式ドキュメントと一致。正確
- 「リポジトリが構造化されていればプロジェクトネイティブなエンジニアとして振る舞う」: Brij Kishore Pandey氏のSNS投稿が出典。技術コミュニティでの実践報告であり、公式見解ではないが多くの実践者が同意する知見
- コンテキストウィンドウの圧迫で精度が下がる: 公式ドキュメントおよび複数の技術記事で言及されており、事実として妥当
- 「/clear でコンテキスト解放」: 公式機能。ただし区切りのいいタイミングで行うべきという補足も正確
事実性に問題なし。
【PM/チームリーダー】最終統合：チームの結論
全員の意見を統合する。
Claude Codeで安定・高精度な開発を行うための統合フレームワーク
結論を一言で言えば
「小さく作って、すぐ確認し、判断基盤をファイルに残す」
これがチーム全員の合意した最適解だ。以下の5つの原則にまとめる：
5つの原則
| # | 原則 | なぜ重要か | 気をつけること |
|---|---|---|---|
| 1 | CLAUDE.mdで判断基盤を固める | Claude Codeの出力のばらつきを抑え、一貫した判断を引き出す | 肥大化させない。最重要ルールのみ。詳細はrules/等に分離 |
| 2 | 1指示1機能で小さく作る | 指示の解釈ブレをゼロにし、手戻りコストを最小化する | 「いい感じに」「全体的に」は禁句。具体的に |
| 3 | 毎ステップ人間が確認する | LLMの確率的な誤りを早期検出する唯一の方法 | 「動いた」と「正しい」は別。エッジケースも意識 |
| 4 | テストは費用対効果で選ぶ | 全てにテストは非現実的。壊れたら困る箇所に集中 | UI→目視、ロジック→TDD、統合→E2E |
| 5 | コンテキストを管理する | セッションが長くなるほど精度が下がる。これはLLMの宿命 | 区切りで/clear。重要情報はCLAUDE.md/ファイルに外出し |
追加で注意すべきこと（デビルズアドボケイトの指摘を採用）
- 設計の明文化: プロジェクトが大きくなったら「頭の中の設計図」をどこかに書き出す。将来の自分・他者への引き継ぎのため
- テストゼロ化防止: 「壊れたら困る箇所」の基準を決めておく（データ処理、認証、課金ロジック等）
- Claude Codeの出力は常にレビューする: 自信満々に間違えるのがLLM。信頼はするが検証は怠らない
これがSE専門チーム全員の議論を経た最終見解です。ユーザーが実践してきたマイクロインクリメンタル手法は、RAGにある多数の実践者の知見とも整合しており、公式ベストプラクティスの方向性とも一致しています。チームとして異論のある者はいませんでした。
唯一の補足として、基盤（CLAUDE.md）とコンテキスト管理がこの手法の安定性を支えるインフラであるという点を強調しておきます。手法だけでなく、その手法が機能する土台を整えることが「安定して精度の高い開発」の条件です。
おわりに
今回の議論では「小さく作って、すぐ確認し、判断基盤をファイルに残す」がチームの結論になった。あなたのベストプラクティスは何ですか？ぜひコメント下さい。
引用された出典元一覧
| # | 引用内容 | 引用したエージェント | 出典 |
|---|---|---|---|
| 1 | 「v1を必ず人間が見るルール」「方向性がずれたまま精緻化されるのを防ぐ」 | アーキテクト | SoySoySoyB — Qiita記事 |
| 2 | 「t-wadaのTDD (Red→Green→Refactor) をCLAUDE.mdに書いておくと自然にそのサイクルで動く」 | コードアナリスト | SoySoySoyB — Qiita記事（同上） |
| 3 | 「ドキュメント・実装・E2Eテストが一緒に育った」「Copilotの出力を確認するための基準点」 | QAエンジニア | babaakihiro — Qiita記事 |
| 4 | 「cc-sdd（仕様駆動開発ツール）」「マルチエージェント対応がなく速度面で劣る」 | テクニカルリサーチャー | DLlama — Qiita記事 |
| 5 | 「Karpathy Guidelines」「検証基準が明確であればあるほどLLMが自走できる範囲が広がる」 | テクニカルリサーチャー | kotai2003 — Qiita記事（元ネタ: Andrej Karpathy のX投稿） |
| 6 | 「リポジトリが雑然としているとチャットボットとして振る舞い、構造化されていればプロジェクトネイティブなエンジニアとして振る舞う」 | テクニカルリサーチャー | Brij Kishore Pandey — X/Twitter投稿 |
| 7 | 「Explore→Plan→Code」「検証手段の提供が公式ベストプラクティス第1項」 | アーキテクト / ファクトチェッカー | Claude Code公式ドキュメント — Best Practices |
| 8 | 「CLAUDE.mdが長すぎるとメモリ圧迫で逆効果」 | デビルズアドボケイト | nAotO01_03 — Qiita記事 |
各出典の詳細
1・2. SoySoySoyB — Qiita
- 記事タイトル: 「Claude Code と進めた個人開発のアーキテクチャ進化 - Google Apps Script + Spreadsheet から Next.js + Hono + PostgreSQL へ」
- URL: https://qiita.com/SoySoySoyB/items/26125d818fb42fd25a91
- 公開日: 2026-02-22
3. babaakihiro — Qiita
- 記事タイトル: 「E2Eを回してCopilotの不確実性を抑える開発フローのPoC」
- URL: https://qiita.com/babaakihiro/items/f72bb13c0081c98f3851
- 公開日: 2026-03-06
4. DLlama — Qiita
- 記事タイトル: 「cc-sddによる仕様駆動開発の記録」
- URL: https://qiita.com/DLlama/items/916f1d3418a814619040
- 公開日: 2026-03-10
5. kotai2003 — Qiita（Karpathy元ネタ付き）
- 記事タイトル: 「LLMにコードを書かせるなら知っておきたい「Karpathy Guidelines」を解説する」
- URL: https://qiita.com/kotai2003/items/e88e7c247c6cb70c57dc
- 公開日: 2026-03-10
- 原典: Andrej Karpathy氏のX投稿 (https://x.com/karpathy/status/2015883857489522876)
6. Brij Kishore Pandey — X/Twitter
- 内容: Claude Code プロジェクト構造化のベストプラクティス
- 出典種別: SNS技術投稿
7. Claude Code 公式ドキュメント
- ソース: https://code.claude.com/docs/en/best-practices.md
- バージョン: v2.1.62 (2026-02-28取得)
8. nAotO01_03 — Qiita
- 記事タイトル: 「Claude Codeを使いこなすために最低限知っておくべきこと4選！」
- URL: https://qiita.com/nAotO01_03/items/d8e58f7282f1c44dca14
- 公開日: 2026-03-06