なぜClaude CodeのPlan Modeが開発を加速させるのか｜品質管理の完全ガイド

開発の主導権をAIから取り戻す

AIにコードを書かせると、勝手に10個のファイルが作成される。

やり直しを指示すると、既存のコードまで破壊される。

解決策は作業前の合意とルールの定着だ。

Claude CodeのPlan Modeとハーネスエンジニアリングを組み合わせる。

これがAIエージェントの出力品質を変える方法だ。

Claude Codeが提示する新しい品質管理の形

AIとの協働スタイルは、自動コーディングから自律的な品質管理基盤へと変化している。

その中核はPlan Modeによるタスク単位の合意形成だ。

通常モードのAIは、指示を受けた瞬間にコードを書き始める。

複雑な機能追加やリファクタリングでは、この即時性が仇となる。

通常モードのAIによる失敗パターンは以下の3つだ。

• 不要なファイルの大量生成: 頼んでいないテストファイルやモックデータが作成される。
• 既存アーキテクチャの破壊: プロジェクトの規約を無視したディレクトリ構造が導入される。
• 破壊的変更の無断実行: 既存のコアロジックが書き換えられる。

ブログ機能を追加する際、AIは勝手に型定義やAPI呼び出しなど10個のファイルを作成する。

やり直しを指示するとトークンを消費し、コードベースは混沌とする。

ここでPlan Modeが機能する。

Plan Modeでは、AIが何をするかを先に提案し、人間が確認してから実行に移る。

AIが提示する計画には以下の要素が含まれる。

• 作成・変更するファイルのリスト: 影響範囲を確認できる。
• 導入するライブラリや依存関係: セキュリティやライセンスのリスクをチェックできる。
• 実装の具体的なステップ: ロジックの組み立て方を確認できる。

人間はそれを確認し、不要なものを削り、方針を修正してから実行を許可する。

1回で正しい方向に進めるのがPlan Modeの価値だ。

品質管理を支えるもう一つの手法がハーネスエンジニアリングだ。

これはAIエージェントの出力品質を、周辺環境の設計で改善する手法だ。

ルール、コマンド、ワークフローを整備し、AIがプロジェクトの規約に従うようにする。

クォートはシングルを使う、特定のライブラリは使わないといった規約は環境として定義する。

これを実現するのがルールディレクトリによる階層的な管理だ。

チーム共有のルールと個人用のルールを分ける。

日々の開発で気づいたAIの癖や規約違反を記録し、ルールとして抽出する。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

AIを「作業者」から「設計パートナー」へ引き上げる

開発者はAIにコードを書かせる作業者から、AIの思考プロセスを設計するAIアーキテクトへと役割を変える。

Plan Modeはコンテキストウィンドウの節約という観点でも機能する。

AIが間違った方向にコードを生成すると、そのコード自体がコンテキストに含まれる。

Plan Modeで事前に合意形成すれば、間違ったコードの生成を防げる。

コンテキストは常にクリーンな状態に保たれる。

しんたろー：
Claude Codeでコードを書く際、Plan Modeは命綱だ。
既存のコアロジックを触らせる時、いきなり実行されると不安を感じる。
計画段階で「AIが勘違いしている」と気づけるだけで、数時間のデバッグを回避できる。

ハーネスエンジニアリングによるルールの定着は、AIとの対話コストを下げる。

ルールが定着すれば、そもそもAIが規約違反のコードを書かなくなる。

品質チェックをできるだけ上流に寄せるという原則が達成される。

指摘の繰り返しがなくなると、会話の中で本質的な設計の議論に時間を使える。

AIは単なるタイピストではなく、設計の壁打ち相手として機能する。

プロジェクトの文脈や規約は、ルールファイルとして外部化されている。

AIは起動時にこれらのルールを読み込み、プロジェクトの文脈を理解した状態で待機する。

AIアーキテクトとしての役割は以下の3つだ。

• コンテキストの制御: AIに与える情報を絞り込み、ハルシネーションを防ぐ。
• ルールの設計: プロジェクトの規約を言語化し、AIが理解できる形式に落とし込む。
• 対話の最適化: Plan Modeと通常モードを使い分け、トークン消費と実行速度のバランスを取る。

プロジェクトに「ルール」を定着させる実践ステップ

最初は、何度も同じ指摘をしていることをルール化するだけで十分だ。

文字列リテラルのクォートスタイルや、特定ライブラリの使用制限などが良い例だ。

ルールの定着サイクルは以下の3ステップで構成される。

1. 記録: AIが規約違反のコードを書いた日付、状況、頻度をジャーナルとして残す。
2. 抽出: 蓄積されたジャーナルからパターンを見つけ、ルール候補を作成する。
3. 昇格: 個人で効果を確認したルールを、チーム全体の共有ルールディレクトリに移動する。

例えば、文字列リテラルのクォートスタイルを守らないというパターンだ。

これに対する解決策として、文字列は式展開がない限りシングルクォートを使うというルールを提案する。

しんたろー：
フロントエンドのコンポーネント分割でAIと意見が食い違うことがある。
AIは全部1ファイルにまとめたがるため、ディレクトリ構成のルールを固めた。
ルールファイルに「App Routerの規約に従え」と書くと、AIの挙動が安定した。

最後に、個人で効果を確認したルールをチーム全体の共有ルールへと昇格させる。

プロジェクトのルートディレクトリにある「.claude/rules/」フォルダに配置する。

補助的なコマンドやスクリプトを用意するのも効果的だ。

• 状態把握のコマンド: 現在適用されているルールの一覧を表示する。
• メンテナンスのコマンド: 使用頻度の低いルールや、重複しているルールを検知する。

このサイクルを回すことで、プロジェクトの成長に合わせてルールが洗練されていく。

誤操作が許されない複雑なタスクでは、必ず作業前に計画を確認する。

まずはPlan ModeでAIの思考の癖を把握する。

慣れてきたら、重要な変更のみに絞ってPlan Modeを使うのが効率的だ。

よくある質問：AIとの協働を最適化する疑問と回答

Plan Modeと通常モードはどのように使い分けるべきですか？

タスクの複雑さと影響範囲で判断する。

ファイル作成や削除、既存コードの大幅なリファクタリングなど、誤操作が許されない複雑なタスクにはPlan Modeが必須だ。

逆に、単一ファイルの修正や、既存のパターンに従った単純なコード追加であれば、通常モードの方が高速だ。

ハーネスエンジニアリングのルールはどこまで細かく書くべきですか？

最初は何度も同じ指摘をしていることをルール化するだけで十分だ。

細かすぎるルールは、AIの推論リソースを無駄に消費させる原因になる。

日々の開発で記録を残し、ルール候補を生成するサイクルを回す。

ルールファイルが肥大化した場合の対処法はありますか？

ルールの階層化とスコープの限定で対応する。

フロントエンド専用、バックエンド専用など、ディレクトリごとにルールを分割して配置する。

定期的にルールの棚卸しを行い、不要になったルールは削除する。

最後に

AIエージェントは放置すれば暴走する。

計画の事前確認とルールの環境構築を徹底する。

しんたろー：
AIを使いこなせるかどうかは、AIのミスをどうシステムで防ぐかにかかっている。
毎回怒るのではなく、怒らなくて済む仕組みを作る。
開発者としての真価は、コードを書く速度ではなく、この仕組み作りの上手さにある。

👉 ThreadPostでSNS運用を自動化する