AI と一緒に開発する

今、AI を使わずにコードを書いている現場はほとんどありません。 新人研修でも、AI ツールの使い方が正式な講義として組まれています。

つまり、「使うかどうか」はもう論点ではありません。 差がつくのは使い方です。そして実際、次の2人の差は非常に大きくなります。

A: AI に書かせ、動いたのでそのまま PR を出す
B: 自分で設計を決め、AI に書かせ、全部読んで、テストは自分で書く

半年後、A は自分では何も直せない状態になっています。 この章は、そうならないための使い方の話です。

得意なことと、苦手なこと

右側は、すべて人間が判断する領域です。 そして実務の難しさは右側にあります。

使い方の型

1. 書かせる前に、自分で設計を言葉にする

悪い: 「注文機能を作って」
良い: 「注文を確定する処理を書きたい。
       入力は注文ID、出力はエラーのみ。
       確定できるのは status が draft の時だけで、
       明細が0件なら弾く。永続化は OrderRepository interface 経由で。」

後者を書ける時点で、設計は8割終わっています。 そして AI が出す答えの精度も、比較にならないほど上がります。

逆に言えば、曖昧なまま投げると、曖昧なものが返ってきます。 これは人間に依頼する時と同じです（ドキュメントを書く）。

2. 小さく頼む

一度に大きな塊を生成させると、

• 読むのが面倒になり、読まずに使う
• 間違いが混ざっていても気づけない
• どこが原因か切り分けられない

関数1つ、ファイル1つの単位で頼み、都度確認するほうが速く終わります。

3. 出てきたコードを、1行ずつ説明できるまで読む

これが最も重要です。

□ この行は何をしているか
□ なぜこの書き方なのか
□ エラーの時どうなるか
□ 自分のプロジェクトの規約に合っているか
□ 使われているライブラリは、本当にプロジェクトに入っているか

4. テストは自分で書く

AI に実装とテストの両方を書かせるのは、危険です。

実装が間違っている
   ↓
その実装に合わせたテストが生成される
   ↓
テストが通る
   ↓
間違いが「検証済み」になる

テストの目的は「自分の意図どおりか」を確かめることです。 意図を持っているのは人間だけなので、期待値は自分で決めてください。

AI が有効なのは、テストケースの洗い出し（境界値や異常系の候補を挙げさせる）です。 そこから採用するかは自分で判断します。

5. レビュー用途が、実は最も費用対効果が高い

「このコードの問題点を、セキュリティ・エラー処理・境界値の観点で挙げて」
「この関数を、この言語の慣用的な書き方に直すとどうなるか」
「この設計で見落としている失敗パターンは？」

自分が書いたものを見てもらう使い方は、

• 出力を鵜呑みにするリスクが低い（自分が正解を知っている）
• 人間のレビュアーの時間を使う前に、明らかな指摘を潰せる
• 指摘の理由を読むことで学習になる

新人がすぐ効果を出せるのは、この使い方です。

ハルシネーションに備える

AI は、存在しないものを自信を持って提示します。

□ 実在しないライブラリ・パッケージ
□ 実在しない関数・オプション
□ 古いバージョンの API（既に削除されている）
□ もっともらしいが誤った説明

情報の扱い

これは技術ではなくルールの問題です。

□ 会社が許可したツール・アカウントを使う（個人アカウントで社内コードを扱わない）
□ 顧客データ・個人情報・認証情報を貼らない
□ 未公開の仕様や社内固有の情報の扱いを、社内規程で確認する
□ 生成物の権利とライセンスの扱いを確認する（ライセンスと依存ライブラリ）

学習への影響

短期の生産性と、長期の実力は別です。

・エラーの原因を、まず15分は自分で追う
・設計は自分で決めてから、AI に批評させる
・知らない概念が出てきたら、AI の説明で終わらせず一次情報を読む（新しい言語をどう学ぶか）

レビューする側として

将来、あなたも AI 生成のコードをレビューする側になります。

□ プロジェクトの規約と違う書き方が混ざっていないか
□ 使われていない引数・過剰な抽象化・不要な設定が入っていないか
□ 存在しないライブラリ・古い API を使っていないか
□ エラー処理が形だけになっていないか（catch して握り潰す等）
□ 業務ルールの解釈が、勝手に一般論になっていないか

最後の項目が最も重要で、かつ AI では検出できません。 そこを見るのが人間のレビュアーの仕事になります。

実務の落とし穴まとめ

1. 理解せずマージする — 障害時に説明できない。責任は出した人にある
2. 実装とテストの両方を生成させる — 間違いが「検証済み」になる
3. 業務ルールを AI の一般論に任せる — 動くのに仕様が違う
4. 知らないパッケージ名をそのまま install — 存在しないパッケージ名を狙う攻撃がある
5. 曖昧な指示で大きな塊を作らせる — 読めない量が返ってきて、結局読まない
6. 社内コード・顧客データを個人アカウントで扱う — 規程違反
7. ログをそのまま貼る — トークンや個人情報が混ざる
8. 説明を読んで理解した気になる — 説明できるかで判定する
9. デバッグまで丸投げする — 最も身につかなくなる領域

まとめ

• 論点は「使うか」ではなく使い方。半年後の実力に直結する
• 書かせる前に、自分で設計を言葉にする。それができれば設計は8割終わっている
• 小さく頼み、全行を読んで、1行ずつ説明できる状態にする
• テストの期待値は自分で決める。実装とテストの両方を任せない
• 自分のコードをレビューさせる使い方が、最も費用対効果が高い
• ハルシネーションに備え、知らないパッケージ名は必ず自分で調べる
• 情報の扱いは技術ではなくルール。許可されたツールで、貼る前に読む
• デバッグ・設計・業務理解は、苦労した量でしか身につかない。 意図的に自分でやる時間を残す

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、その依存ライブラリ自体をどう選び、 どう法的リスクを避けるかを扱います。