AI はなぜ「気の利かない新人」のように振る舞うのか
初めて Vibe Coding（自分でコードを書かず、AI に指示して作る方法）をやると、AI は実力はあるのに的外れに働く場面によく出くわす。こちらの事情を知らないからだ。頼んでいない機能を足し、「ここだけ直して」と言えば隣まで触り、「できました」と言うのにボタンを押すと動かない。
AI が劣っているのではない。相手（自分）が何を望んでいるのか、このプロジェクトがどんなものかを知らないだけだ。優秀な新人が初出社の日に会社の事情を知らないのと同じである。必要なのは数枚のメモ——机に貼っておけば毎回説明し直さずに済む指示書だ。
そのメモをどこに貼るか —— ハーネス
そのメモを貼る場所が、CLAUDE.md（または AGENTS.md）というファイルだ。プロジェクトフォルダの一番上に置く文字だけのファイルで、AI は対話の開始ごとに自動でまず読む。こうして AI が自分に合わせて働くよう先に土台を敷いておくことを、ハーネスと呼ぶ。
何を書くか。幸い、開発者たちが昔から整理してきた原則のいくつかが、そのまま良いメモになる。大きく二つのグループだ——（A）AI への頼み方、（B）コードと情報の整頓の仕方。
A グループ —— AI への頼み方：アンドレイ・カルパシーの4原則
アンドレイ・カルパシーは「Vibe Coding」という言葉を作った AI 研究者だ。彼が「AI にコードを頼むときの指針」としてまとめた四つを、非開発者の目線で言い換えるとこうなる。
まず考える（Think First）。優秀な新人ほど、聞けばすぐ自分のやり方で作ってくる。「会員登録を作って」と言ったらメール登録で作り上げたが、こちらが欲しかったのは Kakao ログインなら、また一から。だから作る前に「こう理解しましたが合っていますか？」と言わせる。言葉で方向を合わせる五秒が、全部作り直す三十分を節約する。
余計を足さない（Simplicity First）。AI は「親切に」頼んでいない機能まで足す癖がある。保存ボタン一つ頼んだのに、自動保存やバージョン管理まで付いてくる。三つとも使わないのに、三つとも壊れうる箇所になる。今頼んだ最小限だけを作らせる。
直す所だけ（Surgical Changes）。「ボタンの色だけ青に」と言ったのに、ボタンを丸ごと作り直してクリック動作を消してしまう、ということがよくある。色は変わったのに押しても反応がない。頼んだ部分だけ直し、関係ない所は触らせない。
ゴール駆動（Goal-Driven）。完了基準がないと、AI は「一応できました」で止まる。画面だけ作って、実際の保存のつなぎ込みは抜けたまま。逆に「保存後にページを更新しても記事が残ること」と釘を刺せば、その状態になるまで自分で直して試し続ける——これが大規模言語モデル（LLM）の最大の強みだ。
B グループ —— コードと情報を整頓する：SSOT・DRY・KISS・YAGNI
これはコードそのものをきれいに保つ原則だ。今すぐ知らなくてもいいが、知っておくと AI が作った成果物が後で絡まりにくくなる。
答えは一か所（SSOT、Single Source of Truth）。同じ情報を複数箇所にコピペすると必ずずれる——一つ直して残りを忘れるからだ。一か所に置き、他はそれを参照させる。繰り返さない（DRY、Don't Repeat Yourself）はそのコード版で、同じコードが二回以上出たら一度作って再利用する。下が実際のコード例だ。
シンプルに（KISS、Keep It Simple）。賢ぶって複雑にせず、分かりやすい方法を先に選ぶ。今要らないものは作るな（YAGNI、You Aren't Gonna Need It）。「あとで要るかも」は今作らない。気づいたと思うが、KISS と YAGNI はカルパシーの「余計を足さない」と実質同じことだ。
// 悪い例 —— ブランド色があちこちに散らばる
ボタン色 = "#E1892F"
見出し色 = "#E1892F"
リンク色 = "#E1892F"
// 色を変えるには三か所すべて直す必要があり、一つ漏らすと色がバラバラ
// 良い例 —— 一か所で定義して参照する（SSOT + DRY）
ブランド色 = "#E1892F"
ボタン色 = ブランド色
見出し色 = ブランド色
リンク色 = ブランド色
// これでブランド色の一行を変えるだけで、ボタン・見出し・リンクが一度に変わる八つに見えて、実は四つの常識
八つ見てきたが、重なりを取り除けば、覚えるのは四つの常識だけだ。
八つの略語に怯む必要はない。「着手前に確認し終わりに検証する／シンプルにいく／任せた所だけ触る／一か所にまとめる」——この四文がすべてだ。
| ひと言でいう常識 | まとまる原則 | 新人に言うこと |
|---|---|---|
| ① 着手前に確認、終わりに検証 | Think First + Goal-Driven | 「この理解で合ってますか？」を先に · 「できました」でなく実際に確認 |
| ② シンプルに | Simplicity First + KISS + YAGNI | 今頼んだ分だけ · 先回りして作らない |
| ③ 任せた所だけ | Surgical Changes | その部分だけ · 隣は触らない |
| ④ 一か所にまとめる | SSOT + DRY | 答え・ひな形は一か所に · コピペ禁止 |
そのまま貼れる CLAUDE.md（実例）
ここまでの原則を実際のファイルに落とすと、こうなる。プロジェクトフォルダの一番上に CLAUDE.md という名前で保存すれば完了だ。（Claude Code を使うなら CLAUDE.md、Cursor や Codex など複数のツールを混ぜて使うなら、同じ内容を AGENTS.md に置けばいい。）
# このプロジェクトで AI が守るルール
私は開発者ではない。専門用語はやさしい言葉で、短く簡潔に説明せよ。
## 進め方
- まず考える：コードを書く前に、何をどう作るのかをやさしい言葉で説明し、私の確認を取れ。要求があいまいなら、勝手に進めず聞き返せ。
- 余計を足さない：今の要求を解く最小限だけ作れ。頼んでいない機能は入れるな。
- 直す所だけ：頼んだ部分だけ直し、関係ないコードは触るな。
- ゴール駆動：先に成功基準を決め（例：保存後にページを更新しても記事が残ること）、実際にそうなるまで確認しながら繰り返せ。
## コード・情報の整頓
- 答えは一か所（SSOT）：同じ設定値・情報は一か所だけに置き、他はそれを参照せよ。
- 繰り返さない（DRY）：同じコードが二回以上出たら、関数にまとめて再利用せよ。
- シンプルに（KISS）：複雑な作りより、分かりやすい方法を先に選べ。
- 今要らないものは作るな（YAGNI）：「あとで要るかも」は今作るな。
## 安全
- ファイル削除など元に戻しにくい作業の前には、必ず先に確認せよ。今すぐ始める
四ステップでいい。（1）今作っているプロジェクトフォルダを開く。（2）一番上に CLAUDE.md ファイルを新しく作る——または AI に「CLAUDE.md ファイルを作って、このルールを入れておいて」と言葉で頼んでもいい。（3）上の内容を貼り付ける。（4）次の対話から、AI はこのメモを先に読んで始める。
Vibe Coding が上手いとは、コードをうまく書くことではなく、AI が自分をうまく助けられるよう舞台を整えることに近い。その舞台こそ、新人の机に貼ったこの数枚のメモだ。