この記事はFusic Advent Calendar 2025 23日目の記事です！
昨日の記事はこちら
はじめに
LLM（大規模言語モデル）の登場により、簡単な指示でコードを生成してくれるAIサービスが数多く登場しています。しかし、生成されたコードの品質を保証するのはあくまで自分たちで、手綱を握らなければ意図が追えない、品質が低いコード（AI slop）が生まれてしまうという話も多いです。ある時レビューで「AIが書いたコードをきちんとレビューして、自分で一行一行説明できるレベルでないとAIにコードを書かせない方がいい」ということを言われた事がとても印象的でした。
今回は新卒エンジニアとして働き始めて8ヶ月ほど経った今、改めてAIの手綱を握りしっかりとレビューするために必要だと（個人的に）思っている考え方をここに備忘録として残しておこうと思います。AIコーディングに直接は関係が薄い「キホンのキ」の話ばかりですが、AIコーディングというのはこういった礎の元に成り立つものだと思うので。
1. 最低限アーキテクチャを理解しておく
全体の動作の流れ（どのエンドポイントにどんなリクエストが来たら、どのクラスのどんなメソッドが呼ばれてその中でどんなモジュールを呼び出してどんな処理をして最終的にどんな結果をどう返すのか）を理解し、今から行おうとしている変更が全体にどういった影響を与えるのかを把握する必要があります。
AIが意図せず別モジュールまで編集し、影響がタスク外へ飛び火する可能性があります。
日頃からコードを追う癖をつけたいです。コードの追いかけ方としては、Ask Devinを使うもよし、Claude codeやCodexに聞くもよしだと思います。（ちゃんと読み取り専用モードに切り替えないと頼んでもないコード編集をしてくることもあるので注意）
2. 類似した（踏襲できそうな）処理がないか探す
コードを追いかけることができたならば、似たような実装を見つけることもできるはずです。同種のタスクは実装パターンも近いことが多いのでGitHubのblame機能などを活用して、過去に行われた実装においてどこのファイルをどう変更したのかを調べましょう。そして、マネできるところはマネしましょう。既に受け入れられているコードということは、（そのコード自体が実は間違っている可能性を一旦置いておいて）そのプロジェクトの設計思想・レビュー基準に沿っている可能性が高いので。
3. 自分自身がコードの説明責任を果たせるかどうか入念に吟味する
冒頭のレビューでの言葉に遡りますが、レビュワーにコードの意図を説明するのは自分です。自分で説明ができないのであれば誰もそのコードを理解できません。理解できないコードはもちろん受け入れられないので、腹落ちする（処理一つ一つに対して"なぜ"を説明できる状態になる）まで入念に吟味する必要があります。
温故知新。
もちろん、日進月歩で進化しているコーディングエージェントたちをキャッチアップしていくこともとても大事なことだと思います。
ですが、だからこそ、ちゃんと自分のコーディング能力（レビュー能力）に向き合わなければいけないと思わずにはいられないのです。