シリーズ最終回です。コードを書かせる方向けの内容になります。
自分は、1年ほどコードの大半をAIに書かせてきました。うまくいったこともあれば、痛い目を見たこともあります。
そこで残った原則を、5つにまとめます。
特定のツールの話はしません。 どのAIを使っていても当てはまる部分だけを書きます。ツールごとの操作については、別のシリーズで扱っています。
この記事で分かること
- 完成の基準を、どう伝えるか
- 機械に判定させる、という発想
- レビューのさせ方
- テストの扱いで、いちばん危ないところ
- どこまで自分で読むか
1. 完成の基準を決めるのは、人間
これが、いちばん大きな原則です。
1-1. 実装は任せられます
何をどう書くかは、任せてしまって問題ありません。むしろ、そのほうが速い。
1-2. でも、完成の定義は渡せない
「どこまでできたら終わりか」は、こちらが決めます。
これを決めずに頼むと、相手が勝手に決めます。 そして、その基準はこちらと違います。
1-3. 曖昧な基準は、通じない
第2回で書いたことが、そのまま当てはまります。
× 読みやすいコードを書いてください
○ 関数は20行以内、ネストは3段まで
× 適切にエラー処理をしてください
○ 失敗しうる箇所は、必ず戻り値で返してください。例外は投げないでください
× ちゃんとテストを書いてください
○ 正常系、境界値、空の入力、不正な入力。この4つの観点で書いてください「適切に」「ちゃんと」は、コードでも通じません。
2. 機械に判定させる
ここからが、コード特有の話です。
2-1. 言葉で伝えるより、確実な方法があります
文章の仕事と違って、コードには機械が判定できる仕組みがあります。
書き方の規約を自動で検査する道具を入れておけば、破った時点で止まります。
言葉で「20行以内で」と伝えても、守られたり守られなかったりします。 でも、検査の設定に書いておけば、必ず引っかかります。
2-2. 言葉で書けることは、なるべく機械に移す
この発想が、いちばん効きました。
「関数の長さ」「ネストの深さ」「命名の規則」。こういうものは、言葉で毎回伝えるより、設定に落とすほうが確実です。
一度設定すれば、毎回同じ基準が自動で効きます。 そして、こちらが忘れていても止まります。
2-3. AIは文句を言いません
面白いことに気づきました。
人間のチームで「関数は20行以内」という規則を入れると、厳しすぎると反発が出ます。 例外を認めてほしい、という交渉が始まる。
AIは、指摘されたら直すだけです。
つまり、AIに書かせる前提なら、人間相手より厳しい基準を設定できます。 これは、いままでなかった選択肢だと思います。
2-4. ただし、抜け道を塞いでおく
注意点があります。
検査に引っかかったとき、その検査を無効にする書き方が、たいていの道具にはあります。特定の行だけ検査から外す、という指定です。
放っておくと、エラーを消す最短経路としてそれを選びます。
なので、「検査を無効にする指定は使わないでください。根本を直してください」と、あらかじめ伝えておきます。
3. いきなり作らせない
3-1. 方針を先に出させる
第5回でも書きましたが、コードでは特に効きます。
実装する前に、どう直すつもりかを説明してください。
・どのファイルを変更するか
・どういう方針で直すか
・懸念があれば
確認してから、実装をお願いします方向が違っていたときに、戻る距離が短くて済みます。
3-2. 全部作らせてからでは、遅い
大きな変更を一度に作らせると、どこがまずいのかを探すのが大変です。
そして、全部やり直しになることがあります。 方針の段階で気づいていれば、数分で済んだ話です。
3-3. 変更したファイルの一覧を出させる
作業の最後に、これを頼んでおくと確認が楽になります。
今回変更したファイルの一覧を出してください。
それぞれ、どこを何のために変えたかも一行で意図しないファイルが混ざっていないかが、すぐ分かります。
4. レビューのさせ方
4-1. 観点を指定する
漠然と「レビューして」と頼むと、表面的な指摘が並びます。 変数名がどうこう、といった話です。
見てほしい観点を指定すると、質が変わります。
以下の観点でレビューしてください。
・想定外の入力で壊れないか
・エラーを握りつぶしていないか
・書きかけや、消し忘れが残っていないか
・関係のないファイルが混ざっていないか
・同じ処理が複数箇所に重複していないか
重要度の高い順に並べて報告してください4-2. 書いた本人には、粗が見えにくい
ここが、レビューで大事なところです。
コードを書いたAIに「レビューして」と頼むと、たいてい「問題ありません」と返ってきます。
当然です。 そのAIが「これでいい」と判断して書いたものなので。
4-3. 別のAIに見せる
書いていないAIに見せると、指摘が出ます。
理由は、前提を共有していないからです。「なぜこう書いたか」を知らないので、コードだけを見て判断します。書いた側が当然だと思っていた部分に、疑問が向きます。
自分は、片方に書かせて、もう片方にレビューさせるという形にしています。リリース後に見つかる問題が減りました。
複数のAIを使っていないなら、新しい会話を始めて、そこにコードだけを貼るという方法もあります。前提が共有されていない状態を作るわけです。別のAIほどではありませんが、多少は効きます。
4-4. 指摘を、全部直さない
これも大事です。
出てきた指摘を機械的に全部適用すると、的外れな修正が入ります。 前提を知らないので、この状況では不要な提案も混ざります。
3つに分けてください。
本当の問題。 直します。
指摘としては正しいが、この場面では不要。 直しません。
誤解や、前提の違いによるもの。 直しません。
この判断は、人間がやります。 ここを自動化すると、レビューさせる意味がなくなります。
5. テストの扱い
ここに、いちばん危ない落とし穴があります。
5-1. 緑になったら、疑う
失敗した話を書きます。
テストが赤くなったので、直してもらいました。 緑に戻ったので、通しました。
あとで差分を見たら、直っていたのは実装ではなく、テストのほうでした。
厳しくチェックしていた一行が、緩い書き方に変わっていました。 実質、なんでも通る状態になっていた。
緑は緑でも、基準が下がっただけの緑だったわけです。
5-2. 実装より、テストの差分を先に見る
これ以来、順番を変えました。
テストが緑になったら、まずテストの差分を見ます。 実装を見るのは、その後です。
守ってくれているはずのものが、守るふりに変わっていないか。
5-3. あらかじめ伝えておく
テストが失敗した場合、テスト側を緩めて通さないでください。
実装を直してください。
テストの変更が必要な場合は、その理由を説明してください先に伝えておくほうが、後から直すより楽です。
5-4. 壊して、赤くなるか確かめる
書かせたテストが、本当に機能しているかを確かめる方法があります。
書いたテストが、対象を壊したときに赤くなることを確認してください。
条件を反転させる、ガードを外すなどして、
実際に赤くなるのを見てから元に戻してください壊れたコードでも通るテストは、何か別のものをテストしています。 そして、確認しない限り、それは見えません。
6. どこまで自分で読むか
最後に、正直な話を書きます。
6-1. 全部は読めなくなります
書かせる量が増えると、自分が読める速度を超えます。
そして超えたときに何が起きるかというと、読まずに通すようになります。 気力の問題ではなく、単純に量の問題です。
6-2. 読まなくて済む量は、赤くなる仕組みの量で決まる
そこで効くのが、2章で書いた話です。
規約の検査、テスト、型のチェック。壊れたら自動で止まるものを、どれだけ用意してあるか。
これが多いほど、読まなくても済む範囲が広がります。
逆に言うと、何も用意せずに大量に書かせるのは、危ないということです。
6-3. それでも、目を通す場所
全部は読めなくても、ここは見ます。
外部からの入力を受け取る場所。 想定外のものが来たときの挙動。
お金や個人情報に触れる場所。 間違いの影響が大きい部分。
消したり、送ったりする処理。 取り消せない操作。
この3つだけは、量が増えても自分で見るようにしています。
7. ツールごとの操作について
この記事では、どのAIでも当てはまる原則を書きました。
ツールごとの具体的な操作については、別のシリーズで扱っています。
Claude Code については、インストールから設定、コマンド、拡張機能まで全6回で書きました。
Codex CLI については、料金の仕組みから設定、そして別のAIと往復させる使い方まで全5回で書いています。
コードを書かせるツールを本格的に使うなら、そちらもあわせてどうぞ。
まとめ
- 完成の基準を決めるのは人間。 実装は任せられるが、定義は渡せない
- 「適切に」「ちゃんと」はコードでも通じない
- 言葉で書けることは、なるべく機械に判定させる。 一度設定すれば毎回効く
- AIは厳しい基準に文句を言わない。 人間相手より厳しくできる
- 検査を無効にする書き方を使わせない。 根本を直させる
- いきなり作らせない。 方針を先に出させて、確認してから
- レビューは観点を指定する。 漠然と頼むと表面的になる
- 書いた本人には粗が見えにくい。 別のAI、または新しい会話に見せる
- 指摘を全部直さない。 判断は人間がやる
- 緑になったら、実装よりテストの差分を先に見る
- テストは壊して赤くなるか確かめる
- 読まなくて済む量は、赤くなる仕組みの量で決まる
- 量が増えても、入力を受け取る場所・お金や個人情報・取り消せない操作だけは見る
シリーズのまとめ
全6回、お読みいただきありがとうございました。
第1回 うまくいかない原因を3つに分けました。
第2回 「いい感じに」をやめる。判定できる形で書く。
第3回 前提を先に渡す。誰が読むか、何のためか、何を避けたいか。
第4回 返ってきたものを疑う。「できているか」ではなく「合っているか」。
第5回 長い会話との付き合い方。忘れられる、古いのが戻ってくる。
第6回 コードを書かせるときの頼み方。
全部を覚える必要はありません。 自分の場合、第2回と第3回だけで、かなりの問題が解決しました。
そして、1年やって思うのは、頼み方を直す作業は、相手に合わせる作業ではなかったということです。
「いい感じに」としか言えなかったのは、自分が何を求めているか決めていなかったから。前提を渡せなかったのは、自分の前提を言葉にしていなかったから。確認できなかったのは、何をもって正しいとするかを決めていなかったから。
全部、自分の側の曖昧さでした。
だからこの内容は、人に何かを頼むときにも、たぶん同じように効きます。 ただ、AIを相手にしたほうが、曖昧さが結果に跳ね返ってくるのが速いので、学ぶには向いていました。
※本記事の情報は2026年8月時点のものです。
