Claude CodeでAIが勝手に実装範囲を広げる（スコープクリープ）ときの対策

Posted at 2026-05-17

はじめに

Claude CodeのようなAIコーディングエージェントを使うと、実装はかなり速く進みます。

一方で、実務で使うほど困りやすいのが、AIが勝手に実装範囲を広げることです。

たとえば、最初は小さな修正を頼んだだけなのに、次のような差分が混ざることがあります。

ついでに周辺コンポーネントを整理する
今回不要なリファクタリングを入れる
既存のテスト構成まで変える
本来触らないファイルに変更が広がる
仕様確認より先に実装を進める

コード単体で見ると悪くない変更もあります。

ただ、チーム開発では「今回の目的に必要だったか」をレビューする必要があります。

この記事では、Claude CodeでAIが勝手に実装範囲を広げるときに、自分が使っている対策をまとめます。

先に結論を書くと、効いたのは「AIにもっと細かく命令する」ことではなく、実装前に境界（やらないこと）と承認ポイントを作ることでした。以下、具体的な5つの対策とそのまま使える依頼テンプレートを示します。

問題はAIの能力不足ではなく、境界の不足

AIが勝手に広げるように見えるとき、多くの場合はAIが悪いというより、依頼側の境界が足りていません。

人間同士でも、次のような依頼は膨らみます。

設定画面を使いやすくしてください。
必要そうなところも直してください。

この依頼には、変更してよい範囲と、変更してはいけない範囲がありません。

AIは文脈から「よさそうな改善」を補完します。

その補完が便利なこともありますが、チーム開発ではレビュー対象が一気に増えます。

対策1: 最初に「やらないこと」を書く

一番効いたのは、やることより先に、やらないことを書くことです。

## やること

- 設定画面の説明文を変更する
- 入力欄の補足テキストを追加する

## やらないこと

- 保存APIの仕様は変えない
- 状態管理の構造は変えない
- CSS設計の整理はしない
- テストフレームワークは触らない

AIは「関連していそうなこと」を広めに拾います。

だからこそ、今回触らない境界を明示すると、出てくる差分がかなり安定します。

対策2: 実装前に計画だけ出させる

いきなりコードを書かせるのではなく、まず計画だけを出させます。

まず実装しないで、以下を出してください。

- Goal
- Scope
- Non-goals
- Test
- Risks

この時点で、変更範囲が広すぎる場合は止めます。

また、Non-goalsに書いた範囲へ踏み込んでいる場合も、実装前に戻せます。

AIコーディングでは、実装後に止めるより、実装前に止めるほうが安いです。

対策3: 確認する観点を5つに絞る

実装前に見る項目は、増やしすぎると運用されません。

自分は、最低限この5つを見ています。

観点	見ること
Goal	何を達成するか
Scope	どこを変えるか
Non-goals	どこを変えないか
Test	何を確認するか
Risks	どこが危ないか

これだけでも、AIの出力はかなりレビューしやすくなります。

特に Non-goals がない計画は、実装範囲が広がりやすいです。

対策4: 小さいIssueに切る

AIに渡すIssueが大きいほど、AIは広く解釈します。

たとえば、次のようなIssueは広がりやすいです。

ユーザー設定まわりを改善する

これを、次のように分けます。

1. 設定画面の説明文だけを変更する
2. 未入力時のdisabled制御だけを追加する
3. 保存成功時の通知だけを追加する

作業量ではなく、レビュー観点で切るのがポイントです。

1つのPRで見る観点が1つか2つに収まると、人間側の確認も速くなります。

対策5: 承認するまでコードを書かせない

まずはプロンプトだけで十分です。「計画を出すまで実装しないで」と毎回先頭に書くだけでも、実装前に止まる回数は増えます。

考え方はシンプルです。

承認なし、コードなし。

AIにはまず計画を作らせます。

人間が計画を見て、Scope・Non-goals・Test・Risksを確認します。

承認してから、はじめて実装に進めます。

ただしこれは「AIが必ず止まる」保証ではなく、依頼側の運用を毎回同じ形に揃えるための型です。プロンプトの言い回しに頼ると忘れる日が出てくるので、自分はこれをPlanGateというワークフローに固定して、毎回同じ手順を踏むようにしています。仕組みにしておくと、注意力に依存せず安定します。

すぐ使える依頼テンプレート

Claude Codeに渡すなら、最初はこれくらいで十分です。

このIssueを実装する前に、まず計画だけ出してください。
まだコードは変更しないでください。

以下を必ず書いてください。

## Goal
この変更で達成すること

## Scope
今回変更する範囲

## Non-goals
今回変更しない範囲

## Test
確認するテスト観点

## Risks
実装前に注意すべきリスク

計画を出したら、承認があるまで実装に進まないでください。

まとめ

Claude CodeでAIが勝手に実装範囲を広げるときは、AIにもっと細かく命令するよりも、実装前の境界を作るほうが効きました。

重要なのは、次の5つです。

やることだけでなく、やらないことを書く
いきなり実装させず、計画だけ出させる
Goal / Scope / Non-goals / Test / Risks を見る
Issueをレビューできる単位に切る
承認するまでコードを書かせない

なお、typo修正や1行の定数変更のような十分小さい変更では、ここまでの手順は不要です。計画フォーマットは省略し、差分だけ確認すれば足ります。重くするのが目的ではなく、レビュー対象が広がりやすい変更にだけ境界を引くのがポイントです。

AIの実装速度が上がるほど、人間がどこで判断するかが重要になります。

AIを止めることが目的ではありません。

チームで安心して使える形にするために、実装前に一度止まる場所を作るのが大事だと思っています。

この記事は「症状（スコープクリープ）と対策の全体像」を扱いました。各論はシリーズで分けています。

計画フォーマットの詳細（Goal / Scope / Non-goals / Test / Risks の書き方リファレンス）: 「AIコーディング前に確認する5項目」（別記事）
「止めた回数を数字で見る」運用化の実例: AIの止まり方を「数字で見る」ようにした体験：PlanGate v8.6.0

本記事は「まず症状に気づいて止める」、5項目記事は「止めるための計画の書き方」、PlanGate記事は「止めた結果を計測する」と役割を分けています。