AIにコードを任せたあと、人間は何を見るべきか: 学生のためのdiffレビュー実践入門

AIにコードを書かせることは、もう珍しいことではなくなりました。私自身がAIを使って思ったことをまとめてみました。

ChatGPT、Codex、Claude Code、GitHub Copilot、Cursor、Gemini CLIなどを使えば、自然言語で「こういう機能を作って」と伝えるだけで、AIがコードを書いたり、複数ファイルを編集したり、ツールによってはテスト実行まで支援してくれます。

いわゆる「バイブコーディング」です。

しかし、ここで大事なのは「AIがコードを書けるようになった」ことだけではありません。知っておきたいのは、AIが書いたコードを、人がどう受け取るかだと思います。

その中心にあるのが diff、つまり変更前後の差分です。

この記事では、AIにコード生成を任せたあとに、人間が何を確認すれば「自分の成果物」として説明できるのかを、diff レビューの手順として整理します。

単なるGitコマンド解説ではなく、学生が個人開発、チーム開発でAIを使うときの「受け取り方」に焦点を当てます。

特に、次のような人を想定しています。

AIでコードを書かせたあと、どこを確認すればよいか分からない人
GitHubでPull Requestや差分を見る練習をしたい人
ポートフォリオで「AIを使った」だけでなく「AI生成物を検証した」ことまで示したい人
将来のチーム開発や就活に向けて、レビュー観点を身につけたい人

情報は2026年7月21日時点で確認した公式ドキュメント、調査、研究をもとにしています。

この記事の立ち位置

先に結論です。

この記事は、git diff の記号を覚えるだけの記事ではありません。

diff を読むとは、赤と緑の行を眺めることではなく、AIや他の開発者が行った変更を「採用してよいか」判断することです。

言い換えると、変更を「仕様」「安全性」「保守性」「テスト」の観点から検収することです。

AI時代のプログラミングでは、コードを書く力だけでなく、次の力が重要になると思っています。

変更範囲を把握する力
意図しない変更を見つける力
削除されたコードの意味を考える力
セキュリティや権限の緩みを見抜く力
テストやログで正しさを確認する力
最終的に「この変更を採用してよい」と説明できる力

まさにこの部分が大事だと思います。

「AIで作りました」で終わる人と、「AIに実装を任せたうえで、変更範囲、削除された処理、テスト、依存関係を確認しました」と説明できる人では、見え方が大きく変わります。

そのために、次のような点が重要だと考えました。

仕様をどう理解したか
AIの出力をどこまで疑ったか
危険な変更をどう見つけたか
何をテストして、何を確認できたか
最後に、なぜその変更を採用してよいと判断したか

diff を読む力は、この説明を支える土台になります。

なぜ今、diffを読む力が重要なのか

AIコーディングは「補完」から「委任」へ進んでいる

以前のAIコーディング支援は、エディタ上で1行や数行を補完する使い方が中心でした。

しかし現在は、AIエージェントがリポジトリを読み、複数ファイルを編集し、コマンドを実行し、テスト結果を見ながら修正する流れが広がっています。

OpenAIのCodex紹介では、Codexがリポジトリ内のコードを読み、ファイルを編集し、テスト、lint、型チェックなどのコマンドを実行できることが説明されています。また、作業後にはターミナルログやテスト出力を根拠として確認できるとされています。OpenAI, Introducing Codex

AnthropicのClaude Codeに関する2026年の調査でも、約40万件のClaude Codeセッションを分析した結果、典型的なセッションでは人間が「何をするか」を決め、Claudeが「どう実装するか」の多くを担う傾向が示されています。Anthropic, Agentic coding and persistent returns to expertise

つまり、これからの開発者は「全部を手で書く人」から、AIに任せる範囲を設計し、結果をレビューする人へ役割が広がっていきます。

AIは便利だが、信頼はまだ完全ではない

Stack Overflowの2025年Developer Surveyでは、回答者の84%が開発プロセスでAIツールを使っている、または使う予定だと回答しています。一方で、AIツールの出力の正確性については、信頼する人よりも信頼しない人の方が多く、46%が不信寄り、33%が信頼寄りでした。Stack Overflow Developer Survey 2025: AI

これは「会社の場ではAIは使われているが、解答の丸のみはされていない」ということです。

AIは速いです。便利です。プロトタイプを作る力もあります。

しかし、AIが作ったコードには次のような問題が混ざることがあります。

一見動くが、仕様と少し違う
権限チェックが緩くなる
エラー処理が雑になる
テストが消える、または弱くなる
使っていない依存パッケージが増える
存在しないパッケージ名を提案する
変更範囲が必要以上に広がる

だからこそ、AI時代には diff が重要になります。

diff は、AIが何を変えたかを人間が確認するための方法です。

そもそもdiffとは何か

diff とは、変更前と変更後の差分です。

Gitでは、たとえば次のように確認できます。

git diff

まだステージしていない変更を見るコマンドです。

git diff --staged

コミット予定の変更を見るコマンドです。

git diff --stat

どのファイルが、どれくらい変更されたかを一覧で見るコマンドです。

Gitの公式ドキュメントでは、git diff 系のコマンドは2つの対象を比較するものとして説明されています。たとえば作業ツリーとインデックス、2つのツリー、インデックスと指定コミットなどを比較します。Git公式ドキュメント: diff-format

Gitのdiffでは、変更の種類を表す記号や状態も出てきます。

A: 追加されたファイル
M: 変更されたファイル
D: 削除されたファイル
R: リネームされたファイル

最初はすべてを覚える必要はありません。まずは次の3つだけ分かれば十分です。

- 削除された行
+ 追加された行
  変更されていない文脈

たとえば、次のdiffを見てみます。

- const isAdmin = user.role === "admin";
+ const isAdmin = true;

if (isAdmin) {
  deletePost(postId);
}

見た目は1行の変更です。

しかし意味は大きく変わっています。

変更前は、ユーザーが管理者かどうかを確認していました。変更後は、常に管理者として扱われます。これは重大な権限バグです。

diffを読むとは、このような「小さく見えるが意味が大きい変更」を考えることです。

diffは「変更量」ではなく「意味」を読む

diffを読むときにやりがちな失敗は、変更行数だけを見ることです。私もそちらに意識が行きがちでした。

しかし、危険な変更は必ずしも大きいとは限りません。

1行の変更で認証が壊れることもあります。

1行の変更で個人情報がログに出ることもあります。

1行の変更で課金処理が二重実行されることもあります。

逆に、100行変わっていても、ただの整形や型定義の分離ならリスクは低い場合があります。

diffを見るときは、変更量よりも次を見ます。

何のための変更か
その目的に対して必要な変更か
変更してはいけない前提を壊していないか
削除されたコードに意味がなかったか
テストやエラー処理は維持されているか

GitHub Docsでも、Pull Requestのレビューでは変更されたファイル、コミット、diffを確認して、マージ前にフィードバック、承認、修正依頼を行うと説明されています。また、レビューはファイルごとに行うのがよいとされています。GitHub Docs: Reviewing proposed changes in a pull request

これはAI生成コードにもそのまま当てはまります。

AIが出した変更は、あなたのリポジトリに対するPull Requestだと思って読むべきです。

ケーススタディ: 「テストを通したAIの変更」は本当に安全か

ここで、実際にありそうな例を見てみます。

あなたがAIに次のように依頼したとします。

管理者向けの記事削除機能で、削除に失敗したときに画面へエラーメッセージを表示してください。
既存のテストも必要に応じて更新してください。

AIが出した変更の一部が次だったとします。

export async function deletePost(currentUser: User | null, postId: string) {
-  if (!currentUser || currentUser.role !== "admin") {
+  if (!currentUser) {
     throw new Error("Forbidden");
   }

   try {
     await postsRepository.delete(postId);
-    await auditLog.record({
-      action: "delete_post",
-      actorId: currentUser.id,
-      targetId: postId,
-    });
     return { ok: true };
   } catch (error) {
-    logger.error({ error, postId }, "Failed to delete post");
-    throw error;
+    return { ok: false, message: "削除に失敗しました" };
   }
}

さらにテストのdiffが次だったとします。

+ it("returns an error message when deletion fails", async () => {
+   postsRepository.delete.mockRejectedValue(new Error("DB error"));
+   const result = await deletePost(adminUser, "post-1");
+   expect(result).toEqual({ ok: false, message: "削除に失敗しました" });
+ });

一見すると、AIは依頼どおりに「削除失敗時のエラーメッセージ」を実装し、テストも追加しています。

しかし、diffとして読むと問題が見えてきます。

観点	diffから見えること	判断
権限	`currentUser.role !== "admin"` が消えている	管理者以外でも削除できる可能性があり、重大
監査ログ	`auditLog.record` が削除されている	誰が削除したか追跡できなくなる
エラー処理	`logger.error` と `throw error` が消えている	障害調査や呼び出し元の制御が難しくなる
テスト	失敗時メッセージのテストだけ追加されている	権限や監査ログの退行を守れていない

この例で大事なのは、テストが追加されているから安全とは限らないということです。

追加されたテストは「削除失敗時にメッセージが返る」ことは確認しています。しかし、「管理者以外が削除できないこと」「削除時に監査ログが残ること」「想定外の失敗がログに残ること」は確認していません。

このdiffに対するレビューコメントを書くなら、たとえば次のようになります。

High:
管理者権限チェックが削除されています。
依頼は削除失敗時のエラーメッセージ追加であり、削除可能なユーザー範囲を広げる変更ではありません。
currentUser.role !== "admin" の確認を残し、非管理者がForbiddenになるテストも追加してください。

Medium:
auditLog.record が削除されています。
記事削除は監査対象の操作なので、成功時の監査ログは維持する必要があります。

Medium:
logger.error と throw error が削除され、失敗が呼び出し元に伝わらなくなっています。
UI向けのエラーメッセージ表示と、内部ログ・例外制御を分けて設計してください。

これが、この記事でいう diff を読むということです。

「テストが通るか」だけではなく、依頼された変更以外の重要な前提が壊れていないかを確認します。

AIバイブコーディングでありがちな危険なdiff

ここからは、練習にAIが生成したコードで特に注意したいdiffのパターンを見ていきます。

1. 権限チェックが緩くなる

- if (!currentUser || currentUser.role !== "admin") {
+ if (!currentUser) {
    throw new Error("Forbidden");
  }

この変更では、管理者チェックが消えています。

AIは「エラーが出ている原因」を単純に取り除こうとして、必要な制約まで消してしまうことがあります。

レビュー観点は次です。

誰が操作できる機能なのか
ログイン確認と権限確認を混同していないか
admin、owner、member などの区別が残っているか

2. バリデーションが弱くなる

- if (password.length < 12) {
+ if (password.length < 4) {
    throw new Error("Password is too short");
  }

この変更は、テストを通すために制約を弱めてしまっている例です。

「ユーザー登録が通らないので直して」とAIに頼むと、AIは制約の意味を十分に理解せず、入力条件を緩める方向に修正することがあります。

レビュー観点は次です。

入力制約は仕様と合っているか
セキュリティ要件を下げていないか
テストの期待値だけに合わせていないか

3. エラー処理がつぶされる

try {
  await sendEmail(user.email);
} catch (error) {
-  logger.error({ error, userId: user.id }, "Failed to send email");
-  throw error;
+  console.log("email failed");
}

この変更では、ログの情報量が減り、さらにエラーが呼び出し元に伝わらなくなっています。

一見すると「エラーで止まらなくなった」ので良さそうに見えるかもしれません。しかし、失敗に気づけなくなる方が危険な場合があります。

レビュー観点は次です。

エラーは利用者に伝えるべきか
ログに調査可能な情報が残っているか
失敗しても処理を継続してよい場面か

4. テストが消える、または弱くなる

- it("rejects non-admin users", async () => {
-   const user = createUser({ role: "member" });
-   await expect(deletePost(user, postId)).rejects.toThrow("Forbidden");
- });

テスト削除は非常に重要なシグナルです。

AIは、実装を直す代わりにテストを消したり、期待値を変更したりすることがあります。特に「テストが通るようにして」とだけ依頼した場合、AIは仕様を守るよりも、テストを通すことを優先するかもしれません。

レビュー観点は次です。

テストが削除された理由は明確か
削除されたテストは古くなった仕様か、それとも守るべき仕様か
正常系だけでなく異常系のテストが残っているか

OpenAIのCodex活用例でも、テストカバレッジの改善やエッジケース、失敗経路のテスト生成が重要なユースケースとして挙げられています。OpenAI, How OpenAI uses Codex

AIにコードを書かせるなら、同時にテストも見直すべきです。

5. 依存パッケージが増える

+ "dependencies": {
+   "super-auth-helper": "^1.0.0"
+ }

依存パッケージの追加は、コード数行よりも大きな意味を持つことがあります。

新しいパッケージには、次のリスクがあります。

本当に存在するパッケージか
メンテナンスされているか
ライセンスは問題ないか
脆弱性はないか
既存の標準ライブラリや社内関数で代替できないか
lockfileの変更が妥当か

USENIX Security 2025の論文では、コード生成LLMが存在しないパッケージ名を提案する「package hallucination」が、ソフトウェアサプライチェーンに対する脅威になると報告されています。同研究では、16種類のLLMと57万6000件のコードサンプルを分析し、商用モデルで少なくとも平均5.2%、オープンソースモデルで21.7%の幻覚パッケージが見つかったとされています。USENIX Security 2025: We Have a Package for You!

AIが依存パッケージを追加したときは、必ず確認しましょう。

git diff package.json
git diff package-lock.json
git diff pnpm-lock.yaml
git diff requirements.txt
git diff pyproject.toml

GitHub Docsでも、依存関係の変更を含むPull Requestでは、依存関係レビューやsource diffを確認することが案内されています。GitHub Docs: Reviewing dependency changes

6. `any` や型の逃げ道が増える

- function renderProfile(user: User) {
+ function renderProfile(user: any) {
  return user.name;
}

TypeScriptでAIがよくやりがちなのが、型エラーを解消するために any を入れることです。

確かにエラーは消えるかもしれません。しかし、型安全性も一緒に消えます。

レビュー観点は次です。

any を使う理由は明確か
既存の型定義を使えないか
型エラーの根本原因を避けていないか
as unknown as や ! で無理やり通していないか

7. 秘密情報や個人情報が露出する

+ console.log("token", process.env.API_TOKEN);

これは絶対に注意すべき変更です。

AIはデバッグのためにログを追加することがあります。そのログにアクセストークン、メールアドレス、ユーザーID、住所、セッション情報などが含まれると危険です。

レビュー観点は次です。

.env の値を直接ログに出していないか
個人情報を不要に出力していないか
エラー監視サービスに送ってよい情報か
サンプルコードに本物のキーが混ざっていないか

OpenAIはCodexの安全な運用について、サンドボックス、承認、ネットワーク制限、ログなどの境界管理が重要だと説明しています。OpenAI, Running Codex safely at OpenAI

学生の個人開発でも、秘密情報をGitに入れない、AIに不要な権限を渡さない、外部通信を確認する、という基本は同じです。

8. 小さな依頼なのに大きなリファクタが混ざる

たとえば、「ボタンの文言を変更して」と依頼しただけなのに、次のような変更が入ったら要注意です。

src/auth/session.ts      | 120 +++++++++++++++++++++-----
src/db/user.ts           |  80 +++++++++++++++---
src/components/Button.tsx|   4 +-
package.json             |   2 +

文言変更に認証、DB、依存パッケージの変更は普通は不要です。

もちろん、必要な場合もあります。しかし、その場合は理由を説明できる必要があります。

レビュー観点は次です。

依頼内容に対して変更範囲が広すぎないか
関係ないファイルが変わっていないか
リファクタと機能変更が混ざっていないか
1つのPull Requestとしてレビュー可能な大きさか

diffを読むときの実践手順

ここからは、実際にAIがコードを変更した後に、どの順番で見ればよいかをまとめます。

Step 1: まず変更ファイル一覧を見る

いきなりコードを読み始める前に、全体像を見ます。

git diff --stat

または、変更種別まで見たい場合は次です。

git diff --name-status

ここで見ることは、主に3つです。

どのファイルが変わったか
変更量は依頼内容に見合っているか
追加、削除、リネームが不自然に混ざっていないか

たとえば、依頼が「UIの文言修正」なのに、auth、payment、database、package.json が変わっていたら、理由を確認します。

Step 2: 依頼内容と変更範囲を照合する

diffを見る前に、自分がAIに何を依頼したかを1文で書けるようにします。

例:

依頼: お問い合わせフォームの送信ボタンを押したとき、未入力項目があればエラーメッセージを表示する。

この依頼なら、自然な変更範囲はおそらく次です。

フォームコンポーネント
バリデーション関数
テスト
必要ならエラーメッセージ定義

一方で、次が変わっていたら疑います。

認証処理
DB接続処理
ルーティング全体
ビルド設定
依存パッケージ

diffは「コードの正しさ」だけでなく、変更範囲の妥当性を見るものです。

Step 3: 削除された行を先に見る

diffでは、追加された行に目が行きがちです。

しかし、レビューでは削除された行が重要です。

- validateCsrfToken(request);
- checkRateLimit(user.id);
- logger.info({ userId: user.id }, "user requested export");

このような行が消えていたら、強い警戒が必要です。

削除されたコードには、過去のバグ対応、セキュリティ対策、運用上の理由が含まれていることがあります。

削除行を見るときは、次を考えます。

これは本当に不要になったのか
なぜ元々存在していたのか
消してもテストで守られているか
仕様変更として説明できるか

Step 4: 追加された行を見る

追加された行では、次を見ます。

既存の書き方に合っているか
同じ責務の処理が重複していないか
エラーハンドリングがあるか
入力値を信用しすぎていないか
ログに出してはいけない情報がないか
将来読んだ人が理解できるか

AIは「それっぽいコード」を作るのが得意です。

しかし、既存プロジェクトの設計意図、命名規則、運用上の暗黙知までは読みきれないことがあります。

そのため、追加行は「動くか」だけでなく、「このプロジェクトに馴染むか」を見ます。

Step 5: テストのdiffを見る

AIに実装を任せたら、テストのdiffも必ず見ます。

理想は、実装の変更に対してテストが次をカバーしていることです。ただ名前だけ覚えるのではなく、「何を守るためのテストか」まで考えるのが重要です。

観点	なぜ見るのか	例
正常系	本来の使い方で正しく動くことを確認するため	正しい入力なら登録できる
異常系	想定外の入力や操作でも、安全にエラーを返せるか確認するため	不正なメールアドレスならエラー
境界値	バグは条件の境目で起きやすいため	12文字以上OKなら、11文字はNG、12文字はOK
権限がない場合	本来使えない人が操作できると、情報漏えいや不正操作につながるため	一般ユーザーは管理者ページを削除できない
空入力	ユーザーが最も起こしやすい入力ミスの1つだから	名前欄が空なら保存しない
失敗時の挙動	DB、API、メール送信など外部要因は失敗することがあるため	DB保存に失敗したら、ログを残してエラーを返す

たとえば「パスワード登録機能」なら、次のように考えます。

正常系: 12文字以上のパスワードなら登録できる
異常系: 短すぎるパスワードなら登録できない
境界値: 11文字はNG、12文字はOK
権限: ログイン済みユーザーだけ変更できる
空入力: 空文字ならエラーになる
失敗時: DB保存に失敗したら、成功扱いにしない

正常系だけのテストは、「予定どおり使ったときに動く」ことしか確認できません。

実際のサービスでは、入力ミス、不正アクセス、外部APIの停止、DBエラーなどが起こります。だからこそ、異常系、境界値、権限、空入力、失敗時の挙動を見ることで、アプリが想定外の状況でも安全に振る舞えるかを確認します。

テストがない場合は、AIに次のように頼むとよいです。

この変更に対して、正常系、異常系、境界値、権限がない場合、空入力、失敗時の挙動を含むテストケース案を出してください。
既存のテストスタイルに合わせてください。
まだコードは書かず、先にテストケースの一覧と、それぞれが防ぐバグを説明してください。

ただし、AIが作ったテストもレビュー対象です。

テストが実装に都合よくなっていないか、仕様を本当に守っているかを見ます。

AnthropicのClaude Codeチーム向けTipsでも、最も重要な実践として「検証」、つまりAIが自分の出力を確認できるようにすることが挙げられています。Anthropic Support, Claude Code power user tips

Step 6: 依存関係と設定ファイルを見る

次のファイルが変わっていたら、通常のコードより慎重に見ます。

package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
requirements.txt
pyproject.toml
Dockerfile
docker-compose.yml
.github/workflows/*
.env.example

これらは、アプリの動作環境やセキュリティに影響します。

特にAIが追加したパッケージは、必ず公式ページ、リポジトリ、更新頻度、ライセンス、脆弱性情報を確認します。

Step 7: 実行結果を見る

diffを読んだら、最後は実行して確認します。

npm test
npm run lint
npm run typecheck
npm run build

Pythonなら、たとえば次です。

pytest
ruff check .
mypy .

プロジェクトによってコマンドは違います。

重要なのは、AIが「動くはずです」と言ったかどうかではなく、自分の環境で確認したかだと思います。

OpenAIのCodexでも、作業結果をテスト出力やターミナルログで追跡できることが説明されています。ただし、同時に、エージェント生成コードは人間が手動でレビューし、検証する必要があるとも説明されています。OpenAI, Introducing Codex

5分で使えるdiffレビュー・チェックリスト

AIにコードを書かせたあと、まずこのチェックリストを見るだけでも事故はかなり減ると思います。

□ 依頼した目的を1文で説明できる
□ 変更ファイル一覧を確認した
□ 変更範囲が依頼内容に対して広すぎない
□ 削除されたコードの意味を確認した
□ 認証・権限チェックが弱くなっていない
□ 入力バリデーションが弱くなっていない
□ エラー処理やログが雑になっていない
□ 秘密情報や個人情報が出力されていない
□ テストが削除・弱体化されていない
□ 追加されたテストが実装都合ではなく仕様を守っている
□ 正常系、異常系、境界値、権限、空入力、失敗時の挙動を確認した
□ 新しい依存パッケージの必要性を説明できる
□ lockfileの変更が妥当
□ 型安全性を無理やり捨てていない
□ lint、test、typecheck、buildを実行した
□ まだ確認できていない範囲を説明できる
□ 第三者に変更理由と確認結果を説明できる

最後の項目が特に大事です。

変更理由と確認結果を説明できないdiffは、まだ安心して採用できる変更ではありません。

AIにdiffレビューを手伝わせるプロンプト

diffは人間が読むべきですが、AIにレビュー補助をさせるのは有効です。

私のおすすめは、AIに「疑わせる」ことです。

以下のdiffをコードレビューしてください。

観点:
- 仕様と違う変更がないか
- 認証・権限・バリデーションが弱くなっていないか
- エラー処理やログが消えていないか
- テストが弱くなっていないか
- テストで正常系、異常系、境界値、権限、空入力、失敗時の挙動が見られているか
- 依存パッケージ追加のリスクがないか
- 変更範囲が広すぎないか

出力形式:
- 重大度: High / Medium / Low
- 指摘箇所
- なぜ問題か
- 修正案
- まだ確認できていないこと

良い点の要約よりも、見落としやリスクの発見を優先してください。

さらに、実装者としてのAIとレビュアーとしてのAIを分けるのも有効です。

あなたは実装者ではなく、レビュー担当のシニアエンジニアです。
このdiffをマージしてよいか判断してください。
不明点があれば、承認せずに質問してください。

ただし、AIレビューも万能ではありません。

AIが「問題ありません」と言っても、最終判断は人間が行います。

AnthropicはClaude CodeのCode Reviewについて、AIによるレビューが深い確認を補助する一方、承認は人間の判断であると説明しています。Claude Blog: Bringing Code Review to Claude Code

学生がdiffを読む力を伸ばす練習方法

ここからは、私たち学生が実際に練習する方法です。

1. 小さな変更から始める

最初から大きなアプリをAIに作らせると、diffが大きくなりすぎて読めません。

まずは次のような小さな変更が向いています。

ボタン文言を変える
入力チェックを1つ追加する
エラーメッセージを表示する
READMEを改善する
テストを1つ追加する

小さなdiffなら、変更の意図と実際のコードを照合しやすいです。

2. AIに「実装前の計画」を出させる

いきなりコードを書かせる前に、まず計画を出させます。

実装する前に、変更するファイル、変更理由、テスト方針を箇条書きで出してください。
まだコードは変更しないでください。

OpenAIもCodexのベストプラクティスとして、大きな変更ではまずAsk Modeで実装計画を出させ、その後Code Modeに移る流れを紹介しています。OpenAI, How OpenAI uses Codex

計画とdiffを比較すると、AIが計画外の変更をしていないか見つけやすくなります。

3. 自分でレビューコメントを書く

GitHubのPull Requestでなくても、ローカルのメモにレビューコメントを書いてみると力がつきます。

例:

High:
deletePostの権限チェックがadminからログイン有無だけに変わっている。
仕様では管理者のみ削除可能なので、元のrole確認を残す必要がある。

Medium:
sendEmailのcatchでthrowが消えている。
メール送信失敗時に呼び出し元が失敗を検知できなくなるため、失敗を握りつぶしてよい仕様か確認が必要。

Low:
変数名が既存の命名規則と異なる。
既存コードではisSubmittingを使っているため、loadingよりisSubmittingに揃えたい。

AI時代に学生が身につけたい開発姿勢

AIコーディングの生産性については、単純に「必ず速くなる」とは言い切れません。

METRの2025年のランダム化比較試験では、経験豊富なオープンソース開発者が自分のリポジトリで実タスクを行った場合、AIツール利用時に19%遅くなったという結果が報告されました。ただし、同ページではこの結果は過去時点のものであり、2026年初頭の新しいデータでは現在の影響を反映しない可能性があるとも注意されています。METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

さらにMETRの2026年2月の更新では、AIツールは2026年初頭には以前より開発者を加速している可能性が高い一方、実験設計上の選択バイアスにより、正確な効果の大きさは弱い証拠にとどまると説明されています。METR, We are Changing our Developer Productivity Experiment Design

ここから学べることは、AIを過大評価しすぎても、過小評価しすぎてもよくないということです。

大切なのは、AIを「自動開発者」として扱うのではなく、速いが間違える共同作業者として扱うことです。

そのとき、人間側に必要なのが次の力です。

何を作るべきかを決める力
良い仕様を書く力
diffを読む力
テストで検証する力
リスクを説明する力
最後に責任を持って採用する力

これは、学生のうちから十分に鍛えられると思います。

まとめ: diffを読めると、AIと開発しやすくなる

バイブコーディングは、プログラミング学習のショートカットではなく、学び方を変える道具だと捉えることもできます。

AIがコードを書いてくれるからこそ、人間はより上流の判断と、より丁寧な検証を求められます。

diff は、その入口ですだと思います。

変更前と変更後の差分を見ることで、AIが何をしたのか、どこにリスクがあるのか、自分は何を理解していないのかが見えてきます。

学生のうちにdiffを読む習慣をつけると、次のような強みになると考えています。

AI生成コードを安全に扱える
GitHubでのPull Requestレビューに慣れる
チーム開発で信頼されやすくなる
ポートフォリオで「作った」だけでなく「検証した」ことを示せる
技術的な判断を説明できる

最後に、この記事の主張を一文でまとめます。

AI時代の開発者に必要なのは、すべてを手で書く力だけではなく、AIが変えた差分を読み、疑い、検証し、採用判断まで説明できる力なのではないでしょうか。

参考文献