0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yoyoshi_lab

AIコーディング時代の新人教育：何を覚えるべきで、何をAIに任せるべきか

0
Last updated at Posted at 2026-05-09

AIコーディング支援ツールや関連ガイドラインは変化が速いので、この記事では2026年5月時点で確認できた情報をもとに整理しています。

はじめに

生成AIやGitHub Copilotのようなコーディング支援ツールが当たり前になりつつあります。

すると新人教育では、こんな問いが出ます。

  • もう文法やAPIを覚えなくていいのか？
  • 新人にAIを使わせると基礎力が育たないのでは？
  • 逆に、AIを禁止すると現場の実務からズレるのでは？

結論から言うと、新人が覚えるべきことは減ったのではなく、変わったのだと思います。

AIより速くコードを打つ力ではなく、

  • 何を作るべきかを分解する力
  • AIの出力を読んで疑う力
  • テストで確かめる力
  • セキュリティや保守性を判断する力
  • 自分の変更を説明する力

が、より重要になりました。

この記事では、2026年5月時点で確認できる公式情報・調査をもとに、新人教育で「人間が覚えるべきこと」と「AIに任せてよいこと」を整理します。

まず事実：AIコーディングは「使う前提」になりつつある

AIコーディング支援の普及状況を見るなら、現時点では2025年の調査を中心にするのが自然です。

Stack Overflow Developer Survey 2025では、AIツールの利用はかなり一般化しています。

  • 回答者の84%が、開発プロセスでAIツールを「使っている、または使う予定」
  • 2024年の76%から増加
  • プロ開発者の51%が、AIツールを毎日利用

JetBrains Developer Ecosystem Survey 2025でも、同じ流れが見えます。

  • 85%の開発者が、コーディングや開発でAIツールを定期的に利用
  • 62%が、少なくとも1つのAIコーディング支援、エージェント、コードエディタに依存

つまり、AIコーディング支援は「一部の人が試している便利ツール」ではなく、実務の前提に近づいています。

ただし、普及していることと、全面的に信頼できることは別です。

Stack Overflow Developer Survey 2025では、AI出力の信頼性についても慎重な結果が出ています。

  • 信頼している開発者: 33%
  • 信頼していない開発者: 46%
  • 「ほぼ正しいが完全ではないAI解決策」への対応に不満: 66%
  • 「AI生成コードのデバッグに時間がかかる」と回答: 45%

DORA 2025の State of AI-assisted Software Development では、AIは単体で組織を良くする魔法ではなく、組織の既存の強みや弱みを増幅する存在だと整理されています。つまり、テスト、レビュー、設計、チームの学習習慣が弱いままAIだけを入れると、弱さも拡大しやすいということです。

2024年のStack Overflow調査やGitHub Copilot研究は、普及の推移や初期の生産性効果を見る資料としては有用です。ただ、現状認識の中心に置くなら2025年調査を使う方がよいです。

現時点のAIは、

速く書く助けにはなるが、正しく作る責任までは引き受けてくれない

という位置づけで見るのが安全です。

新人が「自力で覚えるべきこと」

1. 問題を小さく分ける力

AIに頼る前に、まず人間が「何を頼むか」を決める必要があります。

新人に最初に身につけてほしいのは、いきなりコードを書く力よりも、問題を分解する力です。

例えば、

ユーザー一覧画面を作って

ではなく、

  • どのデータを表示するのか
  • 並び順は何か
  • ページングは必要か
  • 権限で見える項目は変わるか
  • API失敗時はどう表示するか
  • テストでは何を確認するか

まで分けられること。

AIへの指示も、結局はこの分解力に依存します。雑な依頼からは雑なコードが出やすく、具体的な依頼からは検証しやすいコードが出やすくなります。

2. 最低限の文法・標準ライブラリ・データ構造

「AIが書いてくれるから文法はいらない」は危険です。

文法を完璧に暗記する必要はありません。しかし、AIが出したコードを読んで、

  • 変数のスコープ
  • null/undefined/nilの扱い
  • 例外処理
  • 非同期処理
  • 配列・Map・Setなどの基本データ構造
  • 計算量のざっくりした感覚

を理解できないと、レビューもデバッグもできません。

新人教育では「白紙から全部暗記して書ける」よりも、読める・直せる・説明できるを到達目標にした方が実務に合っています。

3. Git、CLI、HTTP、DBの基礎

AIコーディング時代でも、次の基礎は省略しない方がよいです。

  • Git: branch、commit、diff、rebase/mergeの考え方
  • CLI: ファイル操作、grep、環境変数、標準出力/標準エラー
  • HTTP: request/response、status code、header、cookie、認証
  • DB: SELECT、JOIN、index、transaction、migration

なぜなら、AIが生成したコードが壊れる場所は、だいたいこの境界面だからです。

アプリケーションは、言語の文法だけで動いているわけではありません。ネットワーク、データベース、認証、権限、デプロイ環境とつながっています。

この接続部分を理解していないと、「ローカルでは動いたが本番で壊れる」コードを見抜けません。

4. テストとデバッグ

AI時代の新人教育で、最も重視したいのがテストです。

GitHubのCopilot公式ドキュメントでも、生成されたコードは受け入れる前にレビュー・検証する必要があるとされています。生成コードには、バグ、脆弱性、IP上のリスクが含まれ得るためです。

新人には、少なくとも次を覚えてほしいです。

  • 正常系・異常系・境界値を考える
  • 失敗するテストを先に確認する
  • エラーメッセージを読む
  • ログを増やしすぎず、必要な観測点を置く
  • AIに「直して」と言う前に、どこまで事実確認したかを整理する

AIにテストコード案を出してもらうのは有効です。ただし、そのテストが本当に仕様を守っているかは人間が判断します。

5. セキュリティと機密情報の扱い

新人に最初から高度なセキュリティ診断を求める必要はありません。

しかし、最低限の「やってはいけない」は早く覚えるべきです。

  • APIキー、トークン、パスワードを貼らない
  • 個人情報や顧客データをAIに入れない
  • SQLインジェクション、XSS、CSRFなど代表的な脆弱性を知る
  • 認可チェックを「画面で隠す」だけで済ませない
  • 依存ライブラリを不用意に追加しない

IPAの情報セキュリティ10大脅威2025でも、組織向け脅威としてランサム攻撃、サプライチェーン、システム脆弱性、内部不正、不注意による情報漏えい等が挙げられています。

AIにコードを書かせるほど、レビューすべきコード量は増えます。だからこそ、セキュリティの基礎は「専門家だけの仕事」ではなくなっています。

6. 仕様確認とユーザー視点

AIは、それっぽい実装を出すのが得意です。

しかし、ユーザーにとって正しいか、業務上正しいか、運用で困らないかは別問題です。

DORA 2025では、AIは組織の既存の強みや弱みを増幅する存在だと整理されています。だからこそ、AIを使う前提でも、ユーザー視点・テスト・レビュー・継続学習のような基礎は弱めない方がよいです。

新人には、コードを書く前後で次を確認する習慣をつけたいです。

  • この機能は誰の何の困りごとを解決するのか
  • 例外時にユーザーは次に何をすればよいのか
  • 運用者はログから原因を追えるか
  • 仕様が曖昧なままAIに投げていないか

AIは「仕様の穴」を勝手に埋めます。新人はその穴を見つけて、質問できるようになる必要があります。

AIに任せてよいこと

新人がAIを使うべきでない、とは思いません。

むしろ、正しく使えば学習速度は上がります。

AIに任せてよい代表例は次です。

1. 雛形の生成

  • CRUDの雛形
  • テストの雛形
  • バリデーション処理のたたき台
  • APIクライアントのサンプル
  • 設定ファイルの初期案

ただし、生成されたものをそのままマージしないこと。雛形は「出発点」であって「完成品」ではありません。

2. 説明してもらう

新人にとって、AIの強い使い方は「コードを書かせる」よりも「説明させる」ことです。

例:

この関数を初心者向けに説明してください。
副作用、例外が起きる条件、改善点も分けてください。

または、

このエラーメッセージの原因候補を3つ挙げ、確認手順を簡単な順に並べてください。

これは、メンターへの質問前の整理にも役立ちます。

3. 比較案を出してもらう

設計や実装方針で迷ったとき、AIに比較表を作らせるのは有効です。

A案: DBに状態を保存する
B案: キューにイベントとして流す
それぞれのメリット、デメリット、障害時の注意点を比較してください。

ただし、最終判断は人間がします。AIの比較は、判断材料を増やすためのものです。

4. テスト観点の洗い出し

AIは境界値や異常系の候補出しに向いています。

この仕様に対して、正常系、異常系、境界値、セキュリティ観点のテストケースを出してください。

新人は、AIが出したテスト観点を見て「漏れを学ぶ」ことができます。

5. ドキュメント草案

  • README
  • PR説明
  • 変更点の要約
  • API仕様のたたき台
  • リリースノート案

このあたりはAIに任せやすい領域です。

ただし、事実確認は必須です。AIは存在しない仕様や、実装と違う説明を混ぜることがあります。

AIに丸投げしてはいけないこと

1. 要件定義

AIは、ユーザーや事業の責任を持ちません。

曖昧な要件をAIに渡すと、もっともらしいが間違った仕様を作ることがあります。

要件は人間が確認し、AIには整理・論点出し・質問案作成を手伝わせるのがよいです。

2. 設計判断

AIは設計案を出せます。

しかし、

  • チームの運用能力
  • 既存システムとの整合性
  • 障害時の復旧手順
  • 将来の変更頻度
  • セキュリティ要件
  • コスト制約

まで責任を持って判断するわけではありません。

設計判断は、人間がレビューし、チームで合意する必要があります。

3. セキュリティ判断

OWASP Top 10 for LLM Applicationsは、LLMアプリケーション固有のリスクを整理しています。NIST AI RMFも、AIの設計・開発・利用・評価にリスク管理を組み込む考え方を示しています。

AIを使うほど、次のような観点が必要になります。

  • プロンプトに機密情報を入れていないか
  • AI出力をそのまま実行していないか
  • 生成コードに脆弱性がないか
  • ライセンスや権利面の確認をしているか
  • ログや履歴に秘密情報が残らないか

ここは「AIが大丈夫と言ったからOK」にはできません。

4. マージ判断

新人がAIでコードを書いたとしても、PRの責任は人間にあります。

PRでは、最低限次を説明できるようにしたいです。

  • 何を変えたか
  • なぜ変えたか
  • どう確認したか
  • どのリスクが残っているか
  • AIを使った場合、どの部分を生成し、どの部分を自分で確認したか

「AIが書きました」は説明になりません。

新人教育は「AI禁止」ではなく「利用レベル制」がよい

新人教育でありがちな二択は、

  • AIを禁止して基礎を鍛える
  • 最初から自由に使わせる

です。

しかし、どちらも極端です。

おすすめは、AI利用を段階化することです。

Level 0: AIなしで読む・動かす

目的は、環境、テスト、エラー、Gitに慣れること。

  • 既存コードを読む
  • テストを実行する
  • 小さなバグを直す
  • diffを説明する

この段階では、AIは使わないか、説明用途に限定します。

Level 1: AIに説明させる

目的は、理解の補助。

  • エラーの原因候補を出す
  • 関数の説明をさせる
  • 用語を説明させる
  • テスト観点を出す

コード生成より、読解支援に使います。

Level 2: AIに小さな雛形を書かせる

目的は、反復作業の効率化。

  • テストの雛形
  • 型定義
  • バリデーション
  • 単純な変換処理

ただし、生成コードは必ず読んで、手元でテストします。

Level 3: AIと設計案を比較する

目的は、判断材料を増やすこと。

  • 実装方針の比較
  • パフォーマンス上の懸念洗い出し
  • 代替案の作成
  • レビュー観点の整理

この段階では、AI出力を鵜呑みにしないレビュー力が必要です。

Level 4: 実務タスクでAIを使う

目的は、実務の生産性向上。

  • 機能実装
  • テスト追加
  • リファクタリング
  • ドキュメント更新

ただし、PRでは自分の言葉で説明します。

メンター側が見るべきポイント

新人がAIを使っているかどうかだけを見ると、育成を誤ります。

見るべきなのは、次です。

1. 生成コードを読めているか

質問例:

  • この関数の入力と出力は？
  • 例外はどこで起きる？
  • このif文が必要な理由は？
  • このライブラリを追加した理由は？

答えられないなら、まだマージできません。

2. 確認手順を持っているか

質問例:

  • どう動作確認した？
  • 失敗するケースは試した？
  • テストは何を保証している？
  • ログや監視への影響は？

AIが生成したかどうかより、確認の質が重要です。

3. 仕様の曖昧さに気づけるか

新人が成長すると、「実装できました」より先に「ここが曖昧です」と言えるようになります。

これはAI時代でも非常に重要なスキルです。

4. 秘密情報を守れているか

組織では、AI利用ルールを明文化すべきです。

最低限、以下は決めておくとよいです。

  • 入力してよい情報、いけない情報
  • 利用可能なAIツール
  • ソースコードやログの扱い
  • 顧客情報・個人情報の扱い
  • AI生成コードのレビュー基準
  • AI利用をPRやチケットに記録するか

GitHub Copilotにはコンテンツ除外設定もありますが、公式ドキュメント上、一部機能では除外が対応していない旨も記載されています。ツールごとの仕様確認は必須です。

新人に渡す「AI利用チェックリスト」

PR前に、次を確認してもらうと実務に乗せやすいです。

[ ] 仕様の不明点を放置していない
[ ] AIに機密情報・個人情報・秘密鍵を入力していない
[ ] 生成コードを自分で読んだ
[ ] 主要な分岐・例外・境界値を確認した
[ ] テストを追加または更新した
[ ] 手元でテストを実行した
[ ] 依存ライブラリの追加理由を説明できる
[ ] セキュリティ上の懸念を確認した
[ ] 変更内容を自分の言葉で説明できる
[ ] AIが生成した部分と自分が判断した部分を区別できる

このチェックリストの目的は、AI利用を萎縮させることではありません。

AIを使っても、最終的な品質責任は人間が持つ、という習慣を作ることです。

「覚える」と「任せる」の整理

最後に、表でまとめます。

領域 新人が覚えるべきこと AIに任せてよいこと
文法 読める、直せる、説明できる 書き方の例、構文の候補
実装 小さく分ける、責務を考える 雛形、単純な変換処理
テスト 何を保証するか判断する テストケース案、雛形
デバッグ 事実を集め、仮説を立てる 原因候補の列挙
設計 トレードオフを理解する 比較表、代替案の作成
セキュリティ 秘密情報、脆弱性、認可を判断する チェック観点の洗い出し
ドキュメント 事実確認、読み手への配慮 草案、要約、表現調整
レビュー マージ可否の判断 レビュー観点の候補出し

まとめ

AIコーディング時代の新人教育で大切なのは、AIを禁止することではありません。

かといって、AIに丸投げすることでもありません。

新人に必要なのは、

AIより速く書く力ではなく、AIの出力を評価し、検証し、説明し、責任を持つ力

です。

AIは、雛形作成、説明、比較、テスト観点の洗い出し、ドキュメント草案では強力な相棒になります。

一方で、要件、設計、セキュリティ、マージ判断、ユーザーへの責任は人間の仕事です。

これからの新人教育は、

  • 基礎を覚える
  • AIで加速する
  • テストで確かめる
  • レビューで学ぶ
  • 自分の言葉で説明する

というサイクルを回すものになっていくはずです。

AIに仕事を奪われない新人を育てる、というより、AIを使っても品質と責任を手放さない開発者を育てる。

それが、AIコーディング時代の新人教育の中心になると思います。

関連記事

参考資料

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?