AIコーディング前に確認する5項目: Goal / Scope / Non-goals / Test / Risks

Posted at 2026-05-18

はじめに

AIコーディングエージェントに実装を任せる前に、毎回長い設計書を書く必要はありません。

ただ、何も確認せずに実装へ進めると、あとからレビューが重くなります。

自分は最低限、次の5項目だけを見るようにしています。

Goal
Scope
Non-goals
Test
Risks

この記事では、AIコーディング前に確認する5項目を、短いテンプレートとしてまとめます。

先に結論を書くと、長い設計書は要らず、Goal / Scope / Non-goals / Test / Risks の5行を実装前に書くだけで、実装後のレビューはかなり軽くなります。なお、姉妹記事「AIが勝手に実装範囲を広げる（スコープクリープ）ときの対策」が"症状と全体像"を扱うのに対し、本記事はその対策の核になる"5項目の書き方"に絞った詳細リファレンスです。

なぜ実装前に確認するのか

AIは実装が速いです。

だから、間違った方向にも速く進みます。

人間同士なら、途中で違和感に気づいて会話できます。

でもAIコーディングでは、依頼が曖昧なままでも、それらしい差分が一気に出てきます。

その結果、レビュー時に次のような確認が必要になります。

この変更は今回の目的に必要だったのか
どこまでが依頼で、どこからがAIの判断なのか
テスト観点は十分なのか
既存仕様を壊していないか
リリース時に見落とすリスクはないか

実装後に全部確認するより、実装前に5項目だけ確認するほうが楽です。

1. Goal: 何を達成するか

Goalでは、この変更で達成したいことを一文で書きます。

## Goal
設定画面の説明文を見直し、ユーザーが入力欄の意味を理解しやすくする。

ここが曖昧だと、AIは「よさそうな改善」を広く始めます。

悪い例はこうです。

設定画面を改善する。

改善という言葉は便利ですが、AIに渡すには広すぎます。

2. Scope: どこを変えるか

Scopeでは、今回変更する範囲を書きます。

## Scope
- 設定画面の説明文
- 入力欄の補足テキスト
- 表示文言に関するテスト

Scopeは、AIにとっての作業範囲です。

レビューする人にとっては、確認範囲になります。

Scopeが広すぎる場合は、Issueを分けたほうがよいです。

3. Non-goals: どこを変えないか

Non-goalsは、実装範囲の暴走を止めるためにかなり効きます。

## Non-goals
- 保存APIの仕様は変えない
- 状態管理の構造は変えない
- デザインシステムの整理はしない
- バリデーション仕様は変えない

AIは、関連していそうな変更を広めに拾うことがあります。

そのため、やらないことを明示しておくと、差分の意図がかなり保ちやすくなります。

自分の感覚では、Scope より Non-goals のほうが重要な場面も多いです。

4. Test: 何を確認するか

Testでは、実装後に何を確認するかを書きます。

## Test
- 設定画面が表示できること
- 説明文が期待どおり表示されること
- 既存の保存処理が壊れていないこと

ここでは、テストコードを書くかどうかだけでなく、人間が動作確認する観点も含めます。AIが自動実行できない確認（実機での見た目、外部サービス連携など）は、「手動確認」と明示して書き分けておくと、完了条件の解釈ズレを防げます。

AIに任せる場合でも、何をもって完了とするかを先に書いておくことが重要です。

5. Risks: どこが危ないか

Risksでは、実装前に気にするべきリスクを書きます。

## Risks
- 既存ユーザーにとって文言の意味が変わる可能性がある
- i18n対象の文言と直書き文言が混ざる可能性がある
- テストがスナップショット依存の場合、差分が大きく見える可能性がある

リスクを書いておくと、AIも人間もレビュー時の焦点を合わせやすくなります。

AIのレビューコメントが散らばるときも、Risksがあると戻る場所になります。

そのまま使えるテンプレート

# AIコーディング前チェック

## Goal
この変更で達成することを一文で書く。

## Scope
今回変更する範囲を書く。

- 

## Non-goals
今回変更しない範囲を書く。

- 

## Test
実装後に確認することを書く。

- 

## Risks
実装前に注意するリスクを書く。

-

Claude Codeに渡す場合

以下のIssueを実装する前に、まずAIコーディング前チェックを作ってください。
まだコードは変更しないでください。

出力する項目は次の5つです。

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

チェック内容を出したら、承認があるまで実装に進まないでください。

チームで使うときのコツ

チームで使う場合は、最初から厳密にしすぎないほうが続きます。

最初は、すべてのIssueで5項目を完璧に書く必要はありません。

まずはAIに実装を頼むIssueだけで使うのがよいです。

特に次のような変更では効果が出やすいです。

影響範囲が読みにくい変更
UIとロジックが混ざる変更
API仕様に触れる可能性がある変更
テスト追加が必要な変更
既存設計を壊しやすい変更

逆に、明らかなtypo修正や文言1行だけの変更なら、ここまで書かなくてもよいと思います。

まとめ

AIコーディング前に見る項目は、複雑でなくてよいです。

まずは次の5つだけで十分です。

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

AIに任せる前に、この5つを確認するだけで、実装後のレビューはかなり楽になります。

AIの実装速度を活かすには、実装前の確認を軽く仕組みにしておくことが大事です。

この記事は「実装前に確認する5項目（Goal / Scope / Non-goals / Test / Risks）の書き方リファレンス」です。シリーズで役割を分けています。

症状と対策の全体像（AIが勝手に実装範囲を広げる＝スコープクリープにどう気づき止めるか）: Claude CodeでAIが勝手に実装範囲を広げる（スコープクリープ）ときの対策
「止めた回数を数字で見る」運用化の実例: AIの止まり方を「数字で見る」ようにした体験：PlanGate v8.6.0

スコープクリープ記事は「まず症状に気づいて止める」、本記事は「止めるための計画の書き方」、PlanGate記事は「止めた結果を計測する」と役割を分けています。先にスコープクリープ記事を読むと、この5項目が何を防ぐためのものか掴みやすいです。