お疲れ様です。ゆうきです。
昨日のYouTube「Claude Codeで開発してわかった、AIに任せていい仕事とダメな仕事」は見てくれましたか？
まだの人はこちらから
今日は、あの動画で話しきれなかった部分を、メルマガ限定でもう少し深く話します。
動画では話さなかった「判断」の具体例
動画では「構造を決めるのは自分、肉付けはAI」っていう話をしました。
で、「構造を決める」って具体的にどこまでやるの？っていう部分を、もう少し踏み込んで話します。
僕が実際にClaude Codeに新しい機能を作らせるとき、事前に自分で決めてることがあります。
1. 「誰が何を呼ぶか」の流れを先に書く
コードを書く前に、処理の流れを3〜5行のメモで書くんですよ。
例えば「ユーザーがプロフィール画像を変更する機能」を作るとき、こう書く。
1. フロントからAPIを叩く（PUT /users/:id/avatar）
2. controllerでファイルのバリデーション（サイズ、形式）
3. serviceでS3にアップロード
4. repositoryでDBのavatar_urlを更新
5. 古い画像をS3から削除
たった5行なんですけど、これがあるのとないのとで、Claude Codeの出力がまったく変わるんですよ。
「いや、その5行がそもそも書けないんだけど…」って思った人もいるかもしれないんですけど、最初から完璧じゃなくていいんですよ。「たぶんこういう順番だよな」ぐらいでOK。
間違ってたらAIの出力を見て「あ、ここ違うな」って直せばいい。
大事なのは「何も考えずにいきなりAIに投げない」ってことだけです。
これがないと、AIは「全部controllerに書いちゃう」とか「S3のアップロードとDB更新の順番を逆にする」とか、ごちゃっとしたコードを出してくる。
でもこの5行を先に渡すと、「あ、この流れに沿って書けばいいのね」ってAIが理解して、きれいに分離されたコードが出てくる。
2. 「エラーのとき何を返すか」を先に決める
これ、意外と多くの人がAI任せにしてる部分なんですけど、エラーが出たときに何を返すかは自分で決めた方がいい。
なぜかっていうと、AIに任せると、ある画面では { error: "Not found" } って返して、別の画面では { message: "ユーザーが見つかりません", code: 404 } って返すみたいに、バラバラになるんですよ。
僕は最初に「エラーはこの形で統一する」って決めてから、AIに実装させてます。
「いや、そんな形を自分で決めるなんて無理…」って思うかもしれないんですけど、別にゼロから考える必要はなくて。
既存のコードで既にエラー返してるところがあるなら、「じゃあ新しいところも同じ形にしよう」って決めるだけでOKです。要は「バラバラにならないようにする」っていう意識だけあればいい。
たとえばこんな感じ
{
"error": {
"code": "USER_NOT_FOUND",
"message": "指定されたユーザーが見つかりません"
}
}で、こういう「プロジェクト全体で揃えるルール」は、AIに決めさせちゃダメなんですよ。
AIは目の前の1つのタスクに対してベストな答えを出そうとするから、プロジェクト全体で統一感を持たせるのは人間がやらないといけない。
ちなみに、僕がこういう「エラーの返し方」とか「APIの作り方の方針」をプロジェクトの最初にパッと決められるのって、「不滅のアーキテクチャ」で学んだ考え方がベースにあるからなんですよね。
今日話したのはあくまで具体例の1つで、これを色んな場面でできるようになるには、もっと根っこの部分を押さえる必要がある。
購入してくれてる人は、今日の記事を読んだ上でエラーハンドリングのパートをもう一度見てみてください。「あ、だからこう作ってたのか」って、前に見たときとは違う角度でわかると思います。
3. 「ファイルの置き場所」を先に決める
新しい機能を作るとき、「このファイルはどこに置くか」を先に決めてからAIに投げる。
例えば、通知機能を追加するとき、AIに丸投げすると既存のuserフォルダの中に通知のロジックを突っ込んだりするんですよ。「ユーザーに通知するんだから、userの中でいいよね」って。
でも、通知は通知として独立した機能だから、notifications/ っていう新しいフォルダを作って分離した方が、後から別の通知（注文通知、システム通知とか）を追加するときに困らない。
こういう「今だけじゃなくて3ヶ月後を見越した判断」は、AIにはできないんですよね。
なぜ「判断」と「作業」を分けられると強いのか
で、ここからが今日一番伝えたいことなんですけど、この「判断と作業を分ける力」って、AIを使うときだけじゃなくて、エンジニアとしての市場価値そのものに直結するんですよ。
現場でよくある話なんですけど、「この人に任せれば大丈夫」って思われるエンジニアと、「指示しないと動けない」って思われるエンジニアがいるじゃないですか。
この差って、コードを書くスピードの差じゃないんですよね。
「判断」ができるかどうかの差なんですよ。
- この機能、どこに置くべきか判断できる
- エラーの設計を自分で決められる
- 今あるコードと矛盾しないか自分でチェックできる
これができる人は、AIを使おうが使うまいが、現場で替えが効かない存在になる。
逆に、「コードを書く」だけの人は、AIに置き換えられるリスクがある。
つまり、AIを使いこなすスキルを磨くことが、そのままエンジニアとしての市場価値を上げることになるんですよ。
設計判断ができるようになるための第一歩
動画では「5分だけ設計を考える」「構造だけレビューする」「同じパターンで指示する」って話しましたけど、もう1つ、メルマガだから話せることがあります。
それは、「なぜこの構造にしたのか」を自分の言葉で説明できるようにすることです。
例えば、通知機能を notifications/ に分離したとき、「なぜuserの中じゃなくて分離したのか」を自分の中で説明できるようにする。
「通知ってユーザー以外のきっかけでも起きる可能性があるから、userの中に入れちゃうと後から広げにくくなる」
これが言えるかどうか。
この「なぜ」を考えるクセがつくと、「どう作るか」を決めるスピードがどんどん上がっていくんですよね。
今日は「なぜ」を考える具体例を1つ話しただけなんですけど、これを色んな場面でパッとできるようになるには、引き出しを増やす必要があるんですよね。
僕自身、この引き出しのベースになってるのが「不滅のアーキテクチャ」で学んだ考え方です。
購入してる人は、教材のサンプルコードを「なぜこう作ってあるのか」を自分で説明できるか？っていう目線でもう一回見てみてください。
今日の記事で話した「なぜを考えるクセ」を教材で試すだけで、前と全然違う気づきがあると思います。
まとめ
- AIに投げる前に「処理の流れ」「エラーの形」「ファイルの置き場所」を自分で決める
- この3つを決めるだけで、AIの出力の質がまったく変わる
- 「判断と作業を分ける力」はエンジニアの市場価値そのもの
- 「なぜこの構造にしたのか」を言語化する習慣が、設計力を上げる一番の近道
次回もYouTube出すので、またメルマガでも深掘りしていきます。
それでは、お疲れ様でした。
ゆうき
