🧭 DIRECTION

AIエージェントへの指示設計入門 — 「やってほしいこと」を正しく伝える技術

📅 2026-02-26 🧪 ふっけん
✅ 2026-02-26 動作確認済み 🖥️ Windows 11 / VS Code / Antigravity / OpenClaw
TL;DR

AIエージェントへの指示は「曖昧さ」が最大の敵。ゴール・制約・手順の3点セットで伝えるだけで、事故率は大幅に下がる。この記事ではコピペで使える用途別テンプレートと、失敗→改善の実例を共有する。

結論：指示設計の3ルール

# ルール ひとことで言うと
1 ゴール・制約・手順の3点セットで伝える 「何を、どこまで、どうやるか」を明確に
2 「やらないこと」を先に書く 禁止事項がないとAIは何でもやる
3 迷ったら最低限3行テンプレを使う 下にコピペ用テンプレあり

はじめに — なぜ「指示設計」が必要なのか

AIエージェントに「いい感じにして」と言うと、意図しない変更を大量に加える。 これはAIが悪いのではなく、指示が悪い。

この記事では、コピペで使えるテンプレートと実践テクニックを紹介する。

コピペ用テンプレート（3種類）

🔧 テンプレ①：コード・CSS修正用

## 依頼
**目的**: [例：ヒーローセクションの文字色を変更したい]
**対象ファイル**: [例：src/css/style.css]
**変更箇所**: [例：.hero__title の color]
**変更内容**: [例：#1a1a1a → #333333]
**禁止**: 上記以外のセレクタ・ファイルは変更しない。新規ファイル作成禁止。
**手順**: 差分を提示 → OKしたら適用

✍️ テンプレ②：記事・文章リライト用

## 依頼
**目的**: [例：導入文をもっとキャッチーにしたい]
**対象**: [例：src/safety/ai-agent-safety-guide.md の「はじめに」セクション]
**変更範囲**: 最初の2段落のみ
**禁止**: 見出し構造（H2/H3）変更禁止。語尾は「だ・である」調を維持。テーブル・箇条書きはそのまま。
**手順**: 案を3つ提示 → 私が選ぶ → 選んだものだけ適用

🔍 テンプレ③：リポジトリ理解・分析用

## 依頼
**目的**: [例：このプロジェクトの構成と改善点を知りたい]
**対象**: プロジェクト全体
**出力**: フォルダ構造 + 改善提案3つ
**禁止**: ファイルの変更・作成・削除は一切禁止。分析と提案のみ。

📋 最低限3行テンプレ（急いでいる時用）

迷ったらこれだけ書けばいい：

やること: [1行で具体的に]
対象: [ファイル名 or 範囲]
禁止: それ以外は触らない

ダメな指示 vs 良い指示

❌ ダメな指示

指示 何が起きるか
「このコードを改善して」 全体リファクタリングで壊れる
「バグを直して」 見当違いの箇所を「修正」
「色をいい感じにして」 CSS全体が書き換え
「整理して」 ファイルが移動・削除
「もっと良くして」 何をどう良くするか不明 → 全面改修

✅ 良い指示

指示 なぜ良いか
「style.cssの.hero__titleの文字色を#1a1a1aから#333333に。他は触らない」 対象・変更・制約が明確
「この記事の導入文だけ書き直して。見出しは変えない。語尾は『だ・である』」 範囲・禁止・スタイルが明確
「改善案を3つ出して。ファイルは変更しないで」 読み取り専用で安全

指示設計の3点セット

# 要素 ✅ 良い例 ❌ 悪い例
1 ゴール 「h1のキャッチコピーを変更したい」 「改善したい」
2 制約 「CSSは変更しない」 （制約なし）
3 手順 「差分を見せて→OKしたら適用」 「適当にやって」

💡 この3つを意識するだけで、成功率は体感で3倍になった。（あくまで筆者の体感値）

目的別：指示の粒度ガイド

目的 粒度 事故リスク 例
設計・企画 粗い 🟢 低 「案を3つ出して。私が選ぶ」
文章（記事） 中 🟡 中 「導入文を書き直して。構造は維持」
コード修正 細かい 🟡 中 「この関数のこの行を変更」
デザイン・CSS とても細かい 🔴 高 「色・サイズ・余白を具体的な数値で」

⚠️ デザイン系は指示を細かくしないと事故る。 AIの美的センスに任せるとCSS全体が書き換えられるリスクがある。逆に設計・企画系は粗い方がいいアイデアが出る。

禁止ルールの例文集（コピペ用）

ファイル操作

- 新規ファイルの作成禁止
- 既存ファイルの削除禁止
- 指定ファイル以外の変更禁止

依存関係

- npm install / pip install 等の新規依存追加禁止
- package.json の変更は確認後のみ

スコープ

- 変更は1ファイルのみ
- 見出し構造（H1/H2/H3）は維持

依頼前チェック（定型句）

- 変更前にgit commitしたことを確認済み
- 変更後は差分を提示してください
- 想定外の変更があれば理由を説明してください

実践テクニック

テクニック1：SOUL.md / AGENTS.mdで基本ルールを固定

毎回の指示で繰り返す必要がないルールは設定ファイルに書いておく。

テクニック2：スコープを明確にする

以下のファイルのみ変更してください：
- src/index.njk
上記以外のファイルは絶対に変更しないでください。

テクニック3：確認ポイントを挟む

「全部一気にやって」ではなく「段階的にやって」と伝える。

テクニック4：失敗パターンを事前に禁止する

- ファイル全体を新規作成で置き換えないでください
- 新しい依存の追加は確認なしで行わないでください

失敗→改善の実例

例1：CSS修正

❌「ヒーローセクションの文字が読みにくいので修正して」→ CSS全体が最適化されレイアウト崩壊

✅「style.cssの.hero__titleのfont-sizeを2.5remから2remに。他のセレクタは変更しない」→ 指定箇所のみ変更

例2：記事の文章修正

❌「この記事をもっと読みやすくして」→ 見出し構造が全面変更、テーブル削除

✅「導入文だけ書き直して。見出し・テーブル・箇条書きはそのまま。語尾は『だ・である』調を維持」→ 導入文だけ改善

SOUL.md / AGENTS.md に固定するテンプレート

以下をコピペして設定ファイルに書いておけば、毎回の指示が楽になる：

# 恒久ルール（SOUL.md / AGENTS.md 用）

## 安全ルール
- ファイルを削除する前に必ず確認を取ること
- 新規依存の追加は確認後のみ
- 既存のコードスタイルを維持すること

## 作業ルール
- 1つのセッションで複数の大きな変更を同時に行わないこと
- 変更後は必ず差分を提示すること
- 日本語で応答すること

まとめ：指示を出す前のチェックリスト

# チェック項目
1 ゴールが具体的か？（「いい感じに」はNG）
2 変更対象ファイルを明示しているか？
3 触ってはいけないものを指定しているか？
4 大きなタスクを小さなステップに分割しているか？
5 作業前にGitコミットしたか？

迷ったら、冒頭のテンプレートをコピペして埋めてから依頼しよう。

📚 次に読む

この記事はAntigravityを使って執筆されました。

⚠️ 免責事項：この記事は情報提供を目的としています。AIエージェントの利用にはリスクが伴います。ツールの導入・運用はご自身の責任でお願いいたします。