はじめに
最近、これまで本気でやったことのなかったことを始めました。AIに日々の開発の大部分を任せることです。
オートコンプリートのことではありません。「チャットボットに質問してコピペする」ことでもありません。ターミナルでClaudeにタスクを渡し、コードベースを読ませ、ファイルを編集させ、コマンドを実行させ、反復させる——そして自分は舵を取る。そういう開発のことです。
謙虚な気持ちにさせられる体験でした。魔法のように感じる日もあれば、ボトルネックはAIではなく自分の使い方だったと気づく日もあります。
なのでこの記事は、ほとんど自分自身へのメモです。学んだことを忘れて、同じ教訓を苦労して学び直す前に、いつでも戻ってこられる場所として。
この分野の専門家ではありません。まだ数週間です。でも、だからこそ今のうちに書き留めておきたいのです。
「AI駆動開発」が今の自分にとって意味すること
始めたばかりの頃、AI駆動開発とはこういうものだと思っていました。
曖昧なお願いを打ち込めば、動くコードが出てくる。終わり。
今は違う見方をしています。
それはロボットに命令するというより、速くて有能で、ちょっと前のめりなジュニアエンジニアと一緒に働くことに近い。彼はあらゆるものを読んでいるけれど、あなたのプロジェクト、あなたの制約、あなたの好みは知りません——伝えない限りは。
得られる成果の質は、ほぼ次の要素で決まります。
- どれだけコンテキストを与えるか
- どれだけ明確にタスクを切り出すか
- どれだけ丁寧に返ってきたものをレビューするか
AIは速い。自分の仕事はコードを打つことから、明確に考え、しっかりレビューすることへと変わりました。
まずCLAUDE.mdを用意する
成果を最も大きく改善してくれたのは、たった一つのファイル——**CLAUDE.md**でした。
これはClaudeが自動的に読み込み、プロジェクトの指示として扱うファイルです。自分のものには次を記載しています。
- コマンド（
build、lint、test、dev） - アーキテクチャとフォルダの規約
- コードスタイルのルール（「データには
interface、ユニオンにはtype」「デフォルトはServer Components」） - 自分のスタックに特有の「やってはいけないこと」
## コードスタイル
- 関数コンポーネントとアロー関数を使う。
- 文字列をハードコードしない——i18n定数を使う。
- デフォルトはServer Components。必要なときだけ 'use client' を使う。
これがないと、Claudeは一般的な慣習をもとに推測します。あると、出力が自分のコードのようになります。自分が繰り返し直していると気づいた指摘は、二度言わずに済むようこのファイルに追記しています。
自分のなかで定着しつつあるベストプラクティス
最も差が出た習慣をいくつか。
小さく、範囲を絞ったタスクで進める。「ブログページにcanonical URLを追加して」はうまくいきます。「SEOを良くして」はうまくいきません。タスクが狭いほど結果も良く、レビューも楽になります。
**作る前に計画する。**少しでも複雑なものは、まず計画を出してもらい、承認する前に読みます。計画の段階で誤った前提に気づけば数秒で済みますが、コードを書いた後だとずっと高くつきます。
**こまめにコミットする。**Claudeに変更させ、差分をレビューし、コミットする。小さなコミットなら、何かおかしくなってもgitが「元に戻す」ボタンになります。バージョン管理の規律なしのAI駆動開発は、火遊びです。
**自分の仕事を自分で検証させる。**変更後にビルドやリンター、テストを実行させると、自分が見る前にほとんどのミスが見つかります。「npm run buildを実行して、壊れたところを直して」は自分の頻出フレーズです。
**すべての差分を、見知らぬ人からのPRのようにレビューする。**実際そうだからです。理解できない速いコードは、勝利ではなく負債です。
やるべきこと・やってはいけないこと
自分に言い聞かせ続けていることです。
やるべきこと：
- 最初にコンテキストを与える——ファイルパス、例、制約
- タスクは小さく具体的に切る
- 複雑なものはまず計画を求める
- 手動でやらず、ツール（ビルド、テスト、git）を実行させる
- 指摘を
CLAUDE.mdに蓄積し続ける - コミット前に全行を読む
やってはいけないこと：
- 「もっと良くして」と言って満足を期待しない
- 理解できないコードを受け入れない
- 確認せずに10ステップも走らせない
- 「今回だけ」とバージョン管理を飛ばさない
- プロジェクトを知っていると思い込まない——伝えたことしか知らない
- 考えることを外注しない。外注するのは打つことだけ
最後のひとつが、自分に一番繰り返し言い聞かせる必要があります。
プロンプトの書き方を学んでいること
プロンプトは小手先の技ではなく、本当のスキルだとわかりました。一貫して役立つことをいくつか。
意図と制約から始める。
ナビバーにダークモードのトグルを追加して。
既存の next-themes のセットアップを使って。
components/ui/Button.tsx の RetroUI ボタンのスタイルに合わせて。
新しい依存関係は追加しないで。
これで一発で使えるものが返ってきます。「ダークモードを追加して」だけだと、当てもの遊びになります。
例を指し示す。「BlogCard.tsxみたいにして」は、三段落の説明より多くの情報を運びます。語るより、見せる。
**やらないことを伝える。**制約は目標と同じくらい価値があります。「MDXファイルには触らないで」「無関係なリファクタはしないで」で変更が焦点を保ちます。
質問させる。「曖昧な点があれば、コードを書く前に聞いて」は、自信満々に間違った出力を大きく減らします。
**会話の中で反復する。**一発で完璧になることはほとんどありません。「いいね、次は余白をもっと詰めてアクセントカラーを使って」と続けるのは普通のことで、しかも速い。
自分が実際にやらかした失敗
数週間やってみて、自分が繰り返しやってしまうものたちです。
- 曖昧なタスクを渡しておいて、出力のせいにする
- 見た目の良い差分を、ろくに読まずに受け入れる
- 小さなステップではなく、一気に大きな変更をさせてしまう
- コミットを忘れて、良い状態を失う
- 同じ規約を説明し直す代わりに
CLAUDE.mdに入れ忘れる - 導くべき協力者ではなく、神託のように扱ってしまう
どれも大げさなものではありません。でもこれが、AIが自分を加速させるか、AIがあとで掃除する羽目になる混乱を静かに生むかの分かれ目です。
おわりに
AI駆動開発はエンジニアリングを楽にしたというより、労力のかかる場所を移したのだと思います。
打つ時間は減り、明確に考え、コンテキストを与え、丁寧にレビューする時間が増えました。今いちばん大事なスキルは、古くからのもの——明確なコミュニケーション、良い判断、バージョン管理の規律——を、とても速い協力者に対して適用することです。
この記事は今の自分のスナップショットです。数か月後に読み返して、まだまだ学ぶことだらけだったなと少し恥ずかしくなるはず。それでいい。それが目的なのですから。
読んでくれてありがとうございます。これからも学び、作り、共有し続けます🙏