生成AIなしの開発には戻りにくい
生成AIを使う機会が増えました。
開発でも文章作成でも、何かを考える最初の一歩としてAIに相談することが自然になっています。
ただ、最近あらためて感じているのは、AIに全部決めてもらう使い方はあまり合わないということです。
自分にとって生成AIは、答えを出してもらう相手というより、考えを前に進めるための壁打ち相手です。
AIに相談する。
視点を増やす。
選択肢を出してもらう。
最後は自分で決める。
この流れが、今のところ一番しっくりきています。
まず壁打ちで論点を出す
最初に使うのは、壁打ちです。
たとえば、実装方針で迷っているときに、いきなり「正解」を聞くのではなく、次のように相談します。
今、Railsで通知機能を作ろうとしています。
迷っていること:
- DBに通知を保存するか
- 外部サービスに寄せるか
- 既読管理をどこまで作るか
前提:
- 最初は小さく始めたい
- 将来的にはメール通知もありそう
考え方を整理してください。
こうすると、AIは論点を整理してくれます。
自分の頭の中だけで考えていると、同じ場所をぐるぐる回ることがあります。AIに投げるために文章化するだけでも、少し整理されます。
考えるために、まず書く。設計が進まないときの思考整理 と同じで、書くこと自体が思考整理になります。
調査では、一次情報に戻る
AIは調査の入口として助かります。
ただし、AIの回答だけで終わらせないようにしています。
技術記事や実装判断で使うなら、必ず一次情報を確認します。
- 公式ドキュメント
- README
- リリースノート
- 仕様書
- ソースコード
AIには「どこを見ればよいか」を出してもらい、最後は自分で開きます。
gpt-4o-search-previewで参考文献URLを出すには、出典の指定を具体的にする でも書いたように、URLが出てきたからといって正しいとは限りません。
AIに調べてもらうほど、確認する力も必要になります。
実装では、タスクを小さく渡す
実装でAIを使うときは、できるだけ小さく渡します。
悪い例は、こういう依頼です。
この機能を全部作って
これだと、AIも広く触りすぎますし、自分もレビューしづらくなります。
自分が使うなら、こう書きます。
目的:
- CSVアップロード時のバリデーションエラーを表示したい
触ってよい範囲:
- app/models/import_file.rb
- app/controllers/imports_controller.rb
- app/views/imports/new.html.erb
完了条件:
- 空ファイルでエラー表示される
- CSV以外は弾く
- 既存テストが通る
これくらいに切ると、AIの出力も確認しやすくなります。
Clineと無料版Geminiを試して、AIエージェントはモデル選びで変わると思った と同じで、AIエージェントに任せるほど、指示の具体性が大事になります。
レビューでは、違和感を拾ってもらう
AIレビューは助かります。
特に、自分が見落としそうな観点を出してもらう用途で使いやすいです。
- 命名が分かりにくくないか
- 責務が増えすぎていないか
- 例外処理が足りているか
- セキュリティ上の懸念がないか
- テスト観点に漏れがないか
ただし、AIのレビューコメントをそのまま正解にはしません。
AIはそれっぽく指摘してくれますが、プロダクトの背景やチームの文脈までは完全には分かりません。
なので、AIレビューは「気づきを増やすためのもの」として使っています。
「良いだろう」で書いた実装は、レビューでだいたい指摘される にもつながりますが、最終的には自分が意図を説明できる状態にしておきたいです。
最後は自分で決める
AIを使うほど、最後に自分で決めることの重みも増えます。
AIが選択肢を出してくれる。
メリット・デメリットを整理してくれる。
コードも書いてくれる。
それでも、どれを採用するかは自分で決める必要があります。
なぜなら、結果に責任を持つのは自分だからです。
特に仕事では、
- チームの方針
- 既存実装との整合性
- 運用負荷
- セキュリティ
- 将来の保守
を踏まえて判断する必要があります。
AI時代の開発者に必要なセキュリティの基本 と同じで、AIが出したものでも責任は人間側に残ります。
AIとの会話も記録しておく
AIとの会話は流れていきやすいです。
その場では役に立っても、あとから「あのとき何を考えていたんだっけ」となることがあります。
なので、重要な判断に関わるAIとのやりとりは、最後に自分の言葉で残すようにしたいです。
今回の判断:
- 通知はまずDB保存にする
理由:
- 既読管理が必要
- 最初は外部サービスなしで運用したい
- 後からメール通知を追加できる
懸念:
- 通知数が増えたときのパフォーマンス
AIの回答そのものではなく、自分がどう判断したかを残すのが大事だと思います。
明日からできること
生成AIを使うときは、まずこの流れにすると使いやすいです。
- いきなり答えを求めず、論点整理を頼む
- 調査では一次情報に戻る
- 実装は小さく切って渡す
- レビューでは観点を増やしてもらう
- 最後に自分の判断を記録する
AIは速くしてくれますが、考えなくてよくなるわけではありません。
まとめ
自分にとって生成AIは、答えを丸ごともらう相手ではなく、思考を増幅してくれる相棒です。
壁打ちで論点を出し、調査で入口を作り、実装で速度を上げ、レビューで視点を増やす。
そして最後は、自分で決める。
この距離感を大事にしながら、生成AIを使っていきたいです。