Vibe Coding 入門（非エンジニア向け）
AI（Claude Code など）と一緒に開発するときの、いちばん大事な基本だけをまとめた入門版です。 くわしい完全版は vibe_coding.md を読んでください。
ひとことで言うと
- AI は「コードを書くのが速い、優秀な仲間」。あなたの役割は、その仲間が良い仕事をできるように 環境を整える PM（まとめ役） になること。
- AI は放っておくとコードを書きすぎる・複雑にしがち。「小さく・読みやすく・直しやすく」 へ導くのがコツ。
ことばの説明（先に読むと楽）
| ことば | かんたんな意味 |
|---|---|
| ハーネス | AI が働きやすいように整える「ルールと道具の一式」。AI に着せる作業着のようなもの |
| 関数 | ひとまとまりの処理。料理のレシピの 1 工程のようなもの |
| 変数 | 値を入れておく「箱」 |
| テスト | 「ちゃんと動くか」を自動でチェックする小さなプログラム |
| lint（リント） | まずい書き方やクセを自動で指摘してくれるチェック。文章の校正ツールのようなもの |
| CI | コミットのたびに、テストや lint を自動で走らせてくれる仕組み |
| リファクタリング | 動きは変えずに、コードをきれいに整理し直すこと |
1. .claude のハーネス（土台）を整える
ハーネス＝ AI が迷わず良いコードを書けるように、ルールと道具をそろえておく こと。ここに投資するほど、AI の出力の質が上がります。
.claude/CLAUDE.mdにルールを書く：プロジェクトの約束ごと・書き方をここに集約する。長すぎると AI が読み飛ばすので 80 行くらい が目安。settings.jsonを整える：よく使うコマンドをあらかじめ許可しておけば、毎回の確認が減る。保存のたびに自動で整形する設定（hook）も便利。- くり返す作業は「skill」にまとめる：リリースや PR 対応などの定型作業を登録しておけば、毎回指示し直さなくてよい。
- 2 回言ったことは
CLAUDE.mdに書く：同じ注意をくり返さないため。
なぜ？ AI は「書いてあるルール」には従えますが、「あなたの頭の中」は読めません。土台を文字にしておくほど、毎回の手戻りが減ります。
2. 小さく作る
- PR（変更のまとまり）は小さく：数分〜数時間で読めるサイズにする。
- 関数も小さく（次の「5. コードの基本」でくわしく）。
なぜ？ 小さいと、間違えてもすぐ気づけて、捨ててやり直すのも簡単。大きいと、どこで間違えたか分からず、直すのも大変。レビューする人も読めません。「まず動くものを小さく作る → 整える」をくり返すのがいちばん速い。
3. テストを作る
- AI に テストも一緒に書かせる。
- テストしやすいコード＝ 入力に対して出力が決まるだけの素直な関数 に分けておく。
なぜ？ テストがあると、コードを直すたびに「前の機能が壊れていないか」を自動で確認できます。だから安心して大胆に直せる。テストがないと、直すのが怖くてコードがどんどん古くなります。
4. CI を作る
- コミットや PR のたびに、次のチェックを 自動で走らせる：
- テスト（ちゃんと動くか）
- lint（リント）（まずい書き方をしていないか）
- 整形（フォーマット）（見た目の体裁をそろえる）
- 型チェック（値の種類の取り違えがないか ※型のある言語の場合）
- レビューしてくれる bot（CodeRabbit など）も活用する。
なぜ？ 人は忘れます。CI は「壊れたまま先に進む」のを機械的に止めてくれる見張り役。チェックを人の記憶に頼らないことが、品質を保ついちばん確実な方法です。
5. コードの基本（いちばん大事な土台）
AI に書かせるときも、この基準を満たすように指示します。読みやすさは「正しさ」と同じくらい大事 です。
抽象化して、シンプルに・読みやすく書く
ごちゃごちゃした処理は、意味のあるまとまりに分けて名前をつける（＝抽象化）。
なぜ？ 読みやすいコードほど、人も AI も間違いに気づけます。複雑なコードはバグが隠れ、後で直すコストが高くつきます。
1 つの関数はできるだけ小さく（理想は 10 行以下。1 画面より長いのはダメ）
なぜ？ 人の集中力と記憶には限界があります。一目で全部見えれば、理解もチェックも一瞬。画面に収まらないと「上を見ながら下を直す」ができず、ミスが出ます。小さいほどテストもしやすい。
定期的に見直して、必要なら部分的に作り直す（リファクタリング）
なぜ？ 最初から完璧には書けません。作るうちに良い形が見えてきます。放っておくと「散らかった部屋」になり、だんだん手を入れづらくなる。早めに片付ければ低コストで済みます。
関数どうしの「依存」をできるだけ減らす
依存＝「ここを直すと、あっちも直さないと壊れる」というつながり。
なぜ？ 依存が多いと、1 か所直しただけで芋づる式にあちこち壊れます。独立していれば、その部分だけ安心して直せて、テストもしやすく、AI にも「ここだけ見て」と頼めます。
関数名・変数名は、正しい名前をつける
なぜ？ 名前はコードの中で最も読まれる「説明書」です。良い名前があればコメントすら要りません。中身と合っていない名前は、人も AI も誤解させます。名前を見ただけで役割が分かるのが理想。
変数はできるだけ上書きしない
変数＝値を入れる「箱」。その箱の中身を途中で何度も入れ替えない。
なぜ？ 中身が途中で変わると、「今この箱に何が入っているか」を最初から最後まで追わないと分からず、バグの温床になります。上書きしなければ「この値はずっとコレ」と保証され、読む人の負担が激減します。
おまけ：迷ったら
- わからないことは遠慮なく AI に聞く。理解できるまで何度でも。「わかったふり」で進めると、後でコードが読めなくなります。
- ただし AI を過信しない。大事なことは検索させて裏を取る。今日の日付は必ず
dateコマンドで確認する。 - 大事なことはテキストで残し、git で管理する。チャットは消えます。