コードを理解する力 —— AI時代の品質担保プロセス
「書く」はAIに任せていい。でも「理解して品質を担保する」は人間の責任。 コード行を自分で追わなくても、AIに説明させて設計意図と品質を把握すれば、 最終責任は人間が持てる。——その根拠と具体的なやり方。
1. Anthropicの研究が証明した事実
2026年1月、Anthropicが52人のジュニアエンジニアで実験を行いました。
実験内容
PythonAI・データ分析の分野で最も使われるプログラミング言語（読み: パイソン）。AI関連の道具が最も豊富で、文法が読みやすいのが特徴の新しいライブラリ（Trio）を学んでもらい、AI補助ありグループと手書きグループで比較。タスク後に理解度テスト（コード読解・デバッグ・概念理解）を実施。
結果
| AIの使い方 | 理解度テストのスコア |
|---|---|
| AIに完全に丸投げ（コード生成のみ） | 24〜39% |
| AIに概念的質問 / 説明を求める | 65〜86% |
| 手書き（AI未使用） | 67% |
完全にAIに丸投げした人は、何も理解していなかった。
Anthropic研究チームの結論
「AIによる生産性向上は、能力への近道ではない」
「特に安全上重要な領域では、AI生成コードを検証するスキルが求められる。しかしAIへの依存がそのスキル形成を阻害する可能性がある」
出典: Anthropic Research, "How AI assistance impacts the formation of coding skills" (2026年1月)
この研究が示す本当のメッセージ
注目すべきは「AIに説明を求めた人がスコア65〜86%に達している」点です。つまり、コードを自分で一行ずつ追わなくても、AIに「これは何をしている？」「なぜこの実装？」と説明させることで、手書きの人（67%）と同等以上の理解度に達する。これが本章の核心です。
2. 「書けない」と「理解しない」は別物
| 書く（Writing） | 理解して品質を担保する（Understanding） | |
|---|---|---|
| AIに任せる？ | ✅ 任せるべき | ❌ 任せきれない |
| コード行を自分で追う必要？ | — | 必ずしも不要（AIに説明させればよい） |
| 必要なのは | （AIがやる） | AIに的確に問い、回答を品質判定する力 |
| 比喩 | 大工が壁を建てる | 建築家が図面の意図を確かめ、検査する |
「コードの記述をAIに任せる」のは2026年の合理判断です。しかし「作ったものが正しいかを理解しないまま放置する」のは弱点です。図面の意図を確かめず検査印を押す建築家と同じ。
重要なのは、コード行を自分で読むことではなく、AIに説明させて「何をしているか・なぜそうしたか・品質は十分か」を把握し、最終的に自分で品質判定を下すことです。
3. 「理解しない（AI丸投げ）」が致命的な3つの理由
① チーム開発では「理解して説明する」ことが仕事の半分
| 場面 | 必要な能力 |
|---|---|
| PRレビュー | 「この変更は何をしているか」を判断する |
| インシデント対応 | エラーの原因をAIに解かせ、結果を判断する |
| 設計議論 | 「この実装のトレードオフは？」に答える |
| ペアプロ・モブプロ | その場でAIに説明させ、それを相手に翻訳する |
会議中に「ちょっとAIに聞いてきます」と言って終わるわけにはいきません。しかし「AIに説明させて、その内容を自分の言葉で伝える」ことは、AI丸投げの人にはできず、説明を求めた人（理解度65〜86%）にはできることです。
② 「品質判定」が売りなのに、理解しないと判定できない
私のスタンスは「要件定義「何を・何のために作るか」を言葉に整理して関係者で合わせる最初の作業。ここが曖昧だと手戻りが最大になる・品質判定・運用設計を指揮する」です。
品質判定の対象はコードの挙動ですが、それは「コード行を自力で読む」ことと同義ではありません。AIにコードを説明させ、テスト結果と動作確認で裏付け、設計意図と照合して判定する——このプロセスが私の品質担保の方法です。理解（＝AIに説明させて把握すること）を抜きに品質判定はできません。
③ AIが書いたコードの「最終責任」は人間
Anthropicの研究が指摘：
「AI生成コードをデプロイ作ったプログラムを、実際に動くサーバーや公開環境へ設置して動かし始めること前に理解し検証する能力。このスキルは、AIがコードを書く時代にこそ最も重要になる」
4. AIに説明させて理解する3レベル
完全なプログラマーになる必要はありません。以下の3レベルができれば実務で困らないラインです。
Level 1: エラーの原因をAIに解読させる（最重要・1〜2週間）
Traceback (most recent call last):
File "app.py", line 42, in process_order
total = price * quantity
TypeError: unsupported operand type(s) for *: 'str' and 'int'
AIへの問い方:
- 「このエラーの原因は？ 修正方法は？」
AIの答えを品質判定する:
- 「42行目で文字列と数値を掛け算しようとしている」→ 納得できるか？
- 「
quantityが文字列として渡っていた。入力時の型変換漏れが原因」→ 再現するか？
→ AIに解かせた原因が正しいかを、実際の入力値で確認できれば、バグ報告の精度が劇的に上がります。
Level 2: 変更内容（diff）をAIに説明させる（2〜4週間）
- def calculate_total(price):
+ def calculate_total(price, tax_rate=0.1):
+ return price * (1 + tax_rate)
- return price
AIへの問い方:
- 「この変更は何を意図している？」「副作用はない？」「テストは足りる？」
AIの答えを品質判定する:
- 「消費税率の引数が追加され、合計に税が含まれるようになった」
- 「既存の呼び出し元で税なしを期待している場合、影響が出る可能性」
→ AIに説明させた変更意図と影響範囲を判断できれば、コードレビュー書かれたコードを、書いた本人以外の視点で読んで問題を指摘する作業。バグ・読みにくさ・危険な書き方を第三者が見つけるのに有効に参加できます。
Level 3: 全体の流れをAIに解説させる（1〜2ヶ月）
@app.route("/api/orders", methods=["POST"])
def create_order():
data = request.json
order = Order(**data)
db.session.add(order)
db.session.commit()
return jsonify(order.to_dict()), 201
AIへの問い方:
- 「この一連の処理の流れを説明して」「セキュリティ上の懸念は？」
→ AIに解説させた全体像を把握し、設計上の判断（ここは認証が必要等）ができれば、設計議論に参加できます。
必要ないもの
- アルゴリズムの暗記
- データ構造の実装
- 複雑な構文をゼロから書くこと
- ホワイトボードコーディング
5. 正しい使い方（Anthropic推奨パターン）
Anthropicの研究が示したスコア65〜86%のパターンをそのまま実践します。
❌ やらないこと（スコア24〜39%）
- AIに「このコードを書いて」とだけ頼む
- エラーが出たらAIに丸投げして直してもらい、理由を聞かない
- コードをコピペして終わり
✅ やること（スコア65〜86%）
- 「このコードが何をしているか説明して」
- 「このエラーの原因は何？」
- 「この変更の意図と影響は何？」
- 「なぜこの実装になっているの？ もっと良い方法は？」
AIに「説明させる」ことで、自分の理解が深まる。 これがAnthropic推奨の正しい使い方であり、コード行を直接読まない私が品質を担保する核心の方法です。
1日15分の練習メニュー
| 曜日 | やること | 身につく力 |
|---|---|---|
| 月 | 自分のリポジトリのPR diffをAIに説明させる | 変更内容の把握 |
| 火 | pytestの失敗出力をAIに解読させる | エラー原因の把握 |
| 水 | 自分のプロジェクトの1ファイルの流れをAIに解説させる | 全体把握 |
| 木 | エラーメッセージを5個AIに読ませて原因を当てさせる | トレース力 |
| 金 | 新しいライブラリのサンプルコードをAIに解説させる | キャッチアップ |
6. まとめ
┌──────────────────────────────────────────────────────────┐
│ │
│ 「書けない」→ 選択。AIに任せればいい。OK。 │
│ 「理解しない」→ 弱点。AI時代でも人間の責任。要改善。 │
│ │
│ コード行を自力で読まなくても │
│ AIに説明させることで理解度65〜86%に届く（Anthropic） │
│ │
│ 人間に残る核心は │
│ 「AIに的確に問い、回答を品質判定する力」 │
│ │
│ → 今日から自分のコードをAIに説明させながら │
│ 理解と品質判定の精度を磨く │
│ │
└──────────────────────────────────────────────────────────┘
面接で聞かれたら
Q: 「コードは読めるのですか？」
実装はAIに任せていますが、作ったものが正しいかを理解し、品質を担保するプロセスには全力を注いでいます。具体的には、AIにコードを説明させて設計意図と変更内容を把握し、8,000件以上のテストと動作確認で裏付けを取り、セキュリティ要件を満たすかを判定しています。
Anthropicの2026年の研究で、AIに丸投げする人は理解度が24〜39%に落ちる一方、AIに「説明を求める」使い方をすれば65〜86%の理解度を維持できることが分かっています。私は後者の使い方で、コードの挙動を理解し、品質の最終責任を自分で持つことを徹底しています。
用語の平易な解説（専門用語を読み解く）
🐛 Traceback（トレースバック）・スタックトレース
一言で: 「エラーが起きた時の、通過経路の記録」。
- Traceback: Pythonでエラーが起きた時に表示される、処理の追跡記録。「どこ→どこ→どこで止まった」が順に表示される
- スタックトレース: 同じ意味の一般用語。関数の呼び出し履歴を遡って表示する
- 読み方のコツ:一番下の行に「本当の原因（エラーの種類）」が書いてある
🔢 TypeError（タイプエラー）・型（かた）
一言で: 「データの種類（型）が合わず起きるエラー」。
- 型（かた）: データの種類。「文字列（str）」「数値（int）」等。Excelでいう「文字か数値か」の区別
- TypeError: 「文字列と数値を掛け算しようとした」等、型の組み合わせがおかしい時に起きるエラー
- 例：「"100" × 3」は「100100100」（文字の反復）になるか「300」（数値の掛け算）か曖昧。Pythonでは型を明確に区別する
🔀 diff（ディフ）
一言で: 「2つのバージョンの差分（変更内容）」。
- diff: 変更前と変更後を比べて「どこが変わったか」を表示したもの
- 表示ルール:
-（赤）＝消えた行、+（緑）＝追加された行 - PRレビューの基本は、この diff をAIに説明させて「何をどう変えたか・影響は」を把握すること
👁️ PRレビュー・PR（プルリクエスト）
一言で: 「提案されたコード変更を、他の人が確認する作業」。
- PR（Pull Request・プルリクエスト）: 「この変更を本体に取り込んでください」という提案。「マージ（統合）の依頼」
- PRレビュー: 提案された変更を、バグがないか・読みやすいか等の観点で確認すること
👥 ペアプロ・モブプロ
一言で: 「2人〜複数人で1つのコードを見ながら進める開発スタイル」。
- ペアプロ（ペアプログラミング）: 2人で1台のパソコンを囲んで作業する手法
- モブプロ（モブプログラミング）: 3人以上で1台のパソコンを囲む手法
- いずれも「その場でAIに説明させ、内容を相手に翻訳する力」が必要
📋 ホワイトボードコーディング
一言で: 「面接等で、ホワイトボードに手書きでコードを書かせる試験」。
- 昔の技術面接でよく行われた「その場でコードを書いてください」という課題
- AI駆動開発の時代には不要になりつつある