AIコーディングのヒント 012 - 自分のコードをすべて理解する

Dev.to / 2026/3/24

💬 オピニオンDeveloper Stack & InfrastructureIdeas & Deep AnalysisTools & Practical Usage

要点

  • この記事は、テストを通過させたり「エージェンティック」な出力を得たりすると開発者が誤解される可能性があるものの、AIが生成した内容を読んで理解しないままでは、安全でないコードやバグのあるコードをそのまま出荷してしまうと警告しています。
  • 説明責任と保守性のためには、人間のレビュー・ループが必要だと主張します。開発者はコードを説明でき、前提を追跡でき、自動テストがカバーしきれない挙動まで検証できる必要があります。
  • コードベースのコントロールを失うこと、AIに依存してしまうこと、そして本番環境で後になって初めて表面化するような微妙な欠陥を見逃すことのリスクを強調しています。
  • 実践的なレビュー手順を提示します。変更された各行を読み、理解しづらい部分についてAIに説明を求め、前提とエッジケースを検証し、標準に合わないものはすべてリファクタリングし、コードを本当に理解できた時点でのみコミットします。
  • 期待できる効果として、欠陥のより早期な検出、説明可能性によるチームの信頼向上、時間の経過とともにプロンプト品質が改善されること、そして高速なAIエージェントによる「急ぎの判断ミス」を減らせることが挙げられています。

コードはあなたのものです。何をしているのか理解し、所有してください。

TL;DR: 理解できないAI生成コードは出荷しない — 理解できるまで質問してください。

よくある間違い ❌

あなたはAIエージェントに機能の実装を依頼します。

それは200行のコードを返してきます。

テストを実行します。パスします。コミットしてプッシュします。

あなたは、自分こそが世界で一番の「エージェント型コーダー」だと思っています。

しかし、あなたは一度もコードを読んでいません。

3週間後、プロダクションでセキュリティ問題が発生します。

AIが混ぜ込んだ、微妙な バグ は、本来2分で見つけられたはずのものです。

見ていなかったので、あなたはそれに気づけませんでした。

あなたは責任を負うのに、コードが何をしているのか理解していないし、他の人に説明もできません。

コードをレビューせずにエージェントを使う方法に関する、派手な動画チュートリアルはたくさんあります。

覚えておいてください。人間は常にループ(判断の輪)の中にいなければなりません。

対処する課題

  • 自分のコードベースの主導権を失います。

  • 理解していないコードをデバッグできません。

  • 存在を知らないまま脆弱性を出荷します。

  • コードレビューで自分のコードを説明できません。

  • AIへの依存を築いてしまい、時間が経つほどエンジニアとして劣っていきます。

  • 精査していないコードに対して、法的・職業的な責任を負ってしまいます。

[https://dev.to/mcsee/code-smell-313-workslop-code-n09]

やり方 ️

  1. AIが生成または変更したすべてのコード行を、受け入れる前に読みます。
  2. 理解できない部分があれば、AIに説明を求めます。
  3. 説明があなたにとって明確になるまで、追加の質問をします。
  4. AIが前提にしたことを特定し、それを検証します。
  5. AIが見落としたかもしれないエッジケースを確認します。
  6. リファクタして、自分ならこうは書かないと思う部分を磨き上げます。
  7. コードをあなたのものにしてから、コミットします。

期待できるメリット

  • 自分のコードベースの作者であり続けられます。AI出力の“キュレーター”に留まりません。
  • 欠陥 をプロダクションに到達する前に見つけられます。
  • AIが生成したものから学べます。
  • コードを説明できるので、チームとの信頼が深まります。
  • 何がうまくいかなかったのかを理解できるため、時間とともにより良いプロンプトを作れるようになります。

背景

AIエージェントは速いです。その速さがプレッシャーを生みます。

勢いを止めて読んでいくことが、流れを途切れさせるように感じます。

でも違います。あなたを救います。

AIはあなたのシステムを知りません。制約も知りません。

あなたが先四半期に似た変更をしたときに何が起きたかも知りません。

それを知っているのはあなたです。その文脈は代えがききません。

読まないことで、判断をできないツールに判断を委ねることになります。あなたにしかできない、ただ一つのことをアウトソースするのです。

質問することは弱さのサインではありません。

それは主導権を保つ方法です。

AIは、質問したからといってあなたを裁きません。

あなたには、より良い答えを返します。

プロンプトの参照

悪いプロンプト:

ユーザー認証を実装して、

それをプロジェクトに追加して、

mainブランチにコミットしてプッシュして。

*このプロンプトは重要なシステムに対してAIへ完全な権限を与えます。 *

*理解のためのチェックポイントなしで、コードのかたまりを渡されます。*

良いプロンプト:

JWTを使ってログイン関数を実装して。

RS256で署名するようにして。

書いたら、各ステップについて私に質問して。

あなたが書いたすべてのコード行で、何をしたのか理解したいです。

*このプロンプトは期待値を設定します。*

*コードと説明の両方が得られます。*

*何を検証すべきかが分かります。*

注意点 ⚠️

  • AIは、完全に間違った自信満々なコードを書くことがあります。
  • テストが通ることは、正しいロジックを書いたことを意味しません。
  • AIは「正しい出力」ではなく「それっぽい出力」を最適化します。
  • あなたはAIではなく、自分がデプロイするものに責任を負います。
  • AIのミスの中には微妙なものがあります。注意深く読まないと見つけられません。

種別

[X] 半自動

制約 ⚠️

  • 生成されたファイルが非常に大きい場合は、レビューをセクションに分けてください。

タグ ️

  • 読みやすさ

レベル

[X] 初心者

関連チップ


  • AI Coding Tip - AIに自分のコードを説明させる

  • AI Coding Tip - AIを代替ではなくペアプログラマーとして使う

結論

AIは速く書きます。あなたは考えるのが遅すぎます。これは欠陥ではありません。

それが、うまく組み合わさるための分業です。

理解のないスピードは、ただ速い間違いになるだけです。

質問してください。コードを読んでください。出荷するものに責任を持ってください。

追加情報 ℹ️

The Pragmatic Programmer - あなたのコード、あなたの責任

OWASP Top Ten - コードにおける一般的なセキュリティリスク

コードレビューのベストプラクティス - Google Engineering

Martin Fowler - コードスメル

GitHub Copilot セキュリティ調査 - AIコードのリスク

ACM 行動規範 - 専門職としての責任

Stack Overflow Blog - AIがコードの所有権をどう変えるか

IEEE ソフトウェアエンジニアリング標準

CWE - Common Weakness Enumeration(共通脆弱性タイプ一覧)

別名としても知られています

  • "信じるが検証する。"
  • "AIによるコードレビュー。"
  • "責任あるAIコーディング。"
  • "開発者の説明責任"

ツール

  • 任意のAIコーディング支援ツール(GitHub Copilot、Claude、Cursor、Codeium)
  • あなたの言語のリンターおよび静的解析ツール
  • コードレビュー用ツール(GitHub PR、GitLab MR、Gerrit)

免責事項

ここで述べる見解は私自身のものです。

私は、人間として、できる限り他の人間のためになるように書いています。

いくつかの文章を改善するために、AIの校正ツールを使用しています。

建設的な批評と対話を歓迎します。

私はソフトウェア業界で30年、教育で25年、そして500本以上の記事と書籍の執筆を通じて、これらの洞察を形作ってきました。

この記事は AI Coding Tip シリーズの一部です。