AIコーディングで何を理解すべきか。
成長と速度を両立する進め方

AIコーディングの違和感は、コードが書けないことではありません。むしろ、動くものが早く出てくるからこそ、理解の空白が見えにくくなることです。

差分は小さく、テストも通っています。レビューの画面を閉じようとしたところで、手が止まる。この変更がどの入力で壊れるか、なぜこの設計にしたか、明日の障害でどこを戻せばよいかを聞かれたら、すぐ答えられるでしょうか。

INTERPRETATION 速さを測る単位を「何行出たか」だけにすると、理解と検証に使った時間が消えます。AIを使うかどうかではなく、生成、理解、検証、復旧を合わせた一つの仕事として測る必要があります。

AIに任せる範囲は、実装技術の難しさだけで決めません。変更の意味を誰が決め、失敗したときに誰が説明し、どの証拠で出荷を承認するかで決まります。

GitHubはAI生成コードについて、機能確認、テスト、静的解析、依存関係、ハルシネーションしたAPI、削除されたテストまで人が確認するよう案内しています。Claude Codeの公式ドキュメントも、計画モードで先に読み、変更を小さく分け、承認前にコマンドと差分を確認する流れを示しています。

RECOMMENDATION AIに「実装を任せる」ことと、「判断を任せる」ことを分けてください。人が目的と制約を決め、AIが候補を作り、人が証拠を見て承認する。この往復を崩さないことが、速度と責任を同時に守る境界になります。

すべてのコードを同じ深さで読む必要はありません。理解のコストを下げるには、変更が壊れたときの影響、戻しやすさ、見つけやすさを見積もります。

この表の狙いは、低リスクの作業まで重い審査にすることではありません。逆に、高リスクの変更を「テストが通ったから」で通過させないための線引きです。特に権限、外部送信、破壊的操作、顧客データに触れる変更は、AIの説明を証拠として扱わないでください。

学習を守るためにAIを使わない時間を増やす方法もあります。しかし、毎回手書きに戻ると、速度を失ったうえで学びも断片的になりがちです。先に判断を置き、後から説明と検証を必ず通すループのほうが、現場では続けやすいでしょう。

1. 成功条件と非目的を書く。

   「プロフィール画面を直す」では足りません。誰が、何をすると、どう見えれば成功か。今回触らない範囲はどこか。失敗時はどうなるかを先に決めます。

2. AIにはまず調査と計画をさせる。

   いきなり編集を許可せず、関連ファイル、データの流れ、既存のテスト、懸念点を挙げさせます。計画が自分の理解と違ったら、実装前に直せます。

3. 人が設計の選択を一つ決める。

   状態をどこに置くか、エラーをどこで扱うか、互換性をどう守るかを人が選びます。AIに案を出させても、採用理由は自分の言葉で残します。

4. 一時間で終わる大きさに切る。

   OpenAIのCodex活用ガイドも、ひとつのタスクを一時間程度、数百行程度の範囲に絞ると扱いやすいと説明しています。大きな機能は、観測できる小さな縦切りに分けます。

5. テストの前に差分を見る。

   テストが通ることは、要求を満たすことと同じではありません。不要な変更、例外の握りつぶし、権限の広がり、依存関係の追加、テストの削除を先に見ます。

6. AIに説明させたあと、自分で問い直す。

   説明は理解の入口です。「この処理を入力から順に説明して」「失敗する条件を三つ挙げて」「なぜ別案を採用しなかったか」と尋ね、最後はコードと実行結果で確かめます。

7. 独立した証拠で検証する。

   ユニットテスト、型検査、静的解析、ブラウザ確認、ログの確認を変更に合わせて組み合わせます。同じAIに書かせて、同じAIに「問題なし」と言わせるだけでは、検証の独立性が弱くなります。

8. 出した後の観測と学習を残す。

   リリース後に何を見るか、異常ならどこまで戻すかを決めます。最後に、理解できたこと、まだ曖昧なこと、次に手書きで練習する小さな課題を記録します。

まず実装せず、次の順で調査してください。
1. 関係するファイルとデータの流れ
2. 既存の制約と、壊してはいけない挙動
3. 成功条件と失敗条件
4. 小さく分けた実装計画
5. 追加すべきテストと、残る不確実性

この段階ではファイルを変更しないでください。

このループは、AIを使う量を減らす話ではありません。理解と検証を、気合いではなく工程として置く話です。

同じAIコーディングでも、扱うデータ、承認者、納品物、障害の影響が違えば、許される自律性も変わります。自分の手元で動くかだけでなく、誰の環境で、誰の期待に対して出すのかを起点にします。

FDEは、顧客の現場に入り、製品を実際の環境へ適応させるForward Deployed Engineerを指します。開発と導入の境界に立つため、動けば終わりにはなりません。顧客のデータを扱う理由、設定を戻す方法、担当者へ渡す手順までが成果物です。

RECOMMENDATION 案件の種類が変わったら、プロンプトだけでなく権限、入力データ、レビュー者、出荷条件を変えてください。AIの性能より先に、周辺の運用を変える必要があります。

AIを使った実装が自分の経験にならないのは、生成物だけが残り、判断の過程が消えるからです。長い日報は必要ありません。次の4つを、変更単位で短く残します。

学びを「理解した気がする」で終わらせず、次の変更で使える形にします。たとえば、AIが書いたキャッシュ処理を読んだ翌日に、同じ要件を小さな純粋関数として手書きし、テストを先に作る。知識は、次の判断で再利用できたときに経験になります。

AIが生成したコードに問題があったとしても、「AIが書いたから」は、利用者や顧客にとって説明になりません。ツールの提供元も、生成物の正確性や安全性を無条件に保証していません。GitHubは利用者にレビューと検証を求め、Claude Codeも承認した権限の範囲で動く道具であり、提案されたコードやコマンドの確認は利用者の役割だと説明しています。

責任を重く感じるほど、AIを避けたくなるかもしれません。実際には、責任を分解すると速度を保つ方法が見えてきます。

INTERPRETATION 人間の役割は、すべてのコードを一文字ずつ手で書くことではありません。生成物を自分の判断として出せるところまで、文脈、証拠、復旧経路を持つことです。