🧠 AI時代のエンジニアに必要なスキルを考える【第二回】変わらず必要なスキル・新たに必要なスキル・これからの学び方

1. 👋 はじめに

前回はAI開発ツールの現在地（GitHub Copilot・Cursor・AIエージェント）と、AIが得意なこと・苦手なことを整理しました。

今回はより深い問いに向き合います。

「AIが普及した世界で、エンジニアに求められるスキルはどう変わるの？」

答えを先に言うと：

🔑 変わらず必要なスキル：
  「コンピュータサイエンスの基礎・設計力・問題解決力」

🆕 新たに必要なスキル：
  「AIを正しく使いこなす力・AIの出力を評価する力」

📉 比重が下がる作業：
  「定型的なコーディング・調べればわかること」

それぞれを詳しく見ていきましょう💪

---

2. 🏛️ 変わらず必要なスキル

① 問題を正しく定義する力

AIはコードを書くのは得意
でも「何を作るべきか」は決められない

例：
  ❌ 「ユーザー管理システムを作って」
     → AIは動くコードを作るが
       要件の曖昧さは解決できない

  ✅ 「月額課金制SaaSの管理者が
      ユーザーを招待・削除・権限変更できる
      管理画面のAPIを作って」
     → 明確な要件があればAIも高精度で作れる

問題を定義する力がない人は
AIにもうまく指示できない！

問題定義のスキル：
  └─ 「何が問題か」を正確に言語化できる
  └─ 「誰のための・何のための機能か」を整理できる
  └─ 要件を具体的・測定可能な形に落とし込める

② アーキテクチャ設計力

「どういう構造でシステムを作るか」は
AIにはまだ決められない

AIができること：
  ✅ 「こういう設計にしてはどうか？」の提案
  ✅ 既存の設計パターンの説明

AIができないこと：
  ❌ プロジェクトの制約・チームのスキル・予算を踏まえた
     「この案件に最適な設計」の判断
  ❌ 5年後のスケーラビリティを考慮した選択

設計の判断は「文脈」が必要：
  └─ チームの技術スタック・スキルセット
  └─ 予算・スケジュールの制約
  └─ 将来の拡張性・保守コスト
  └─ ビジネス要件・非機能要件

→ これらを総合的に判断できるのは
  経験を積んだ人間のエンジニアだけ！

③ コンピュータサイエンスの基礎

「基礎があるとAIの出力の良し悪しがわかる」

基礎知識があると気づけること：

📊 アルゴリズム・データ構造：
  AIが O(n²) のコードを生成した場合
  → 「これは大規模データで遅くなる」と気づける
  → 「O(n log n) で書き直して」と指示できる

🗄️ データベース：
  AIが N+1問題のあるクエリを生成した場合
  → 「これはパフォーマンスに問題がある」と気づける
  → 「JOINを使って1クエリにして」と指示できる

🔒 セキュリティ：
  AIが脆弱なコードを生成した場合
  → 「ここにSQLインジェクションのリスクがある」と気づける
  → 「プリペアドステートメントを使って」と指示できる

💡 基礎がなければAIの出力を評価できない
   基礎があればAIを強力な相棒にできる！

④ デバッグ・トラブルシューティング力

AIが生成したコードが動かない…
そのとき何をするか？

AIは「エラーメッセージを説明する」のは得意
でも「なぜこのプロジェクトで今このエラーが出るか」
の文脈を理解するのは苦手

デバッグで必要なこと：
  └─ エラーの原因を仮説・検証できる
  └─ ログ・スタックトレースを読み解ける
  └─ 問題を切り分けて原因を特定できる
  └─ 環境・バージョン・依存関係の問題を見分けられる

→ デバッグ力は「AIを使う時代」でも
  むしろ重要性が増している
  （AIが生成したコードのバグを直すのは人間）

⑤ 読解力・コミュニケーション力

「コードを書く力」より「読む力・伝える力」が重要に

AIが普及した世界での変化：
  Before：エンジニアの仕事の70% → コードを書く
  After ：エンジニアの仕事の70% → 読む・考える・伝える

読む：
  └─ AIが生成したコードを読んで評価する
  └─ チームメンバーのコードをレビューする
  └─ ドキュメントや仕様を正確に理解する

考える：
  └─ 要件を整理して設計に落とし込む
  └─ AIの提案の良し悪しを判断する
  └─ 問題の根本原因を特定する

伝える：
  └─ AIに正確に指示を出す（プロンプト）
  └─ チームに設計の意図を伝える
  └─ 顧客・ステークホルダーに技術的な内容をわかりやすく説明する

---

3. 🆕 新たに必要なスキル

① プロンプトエンジニアリング

「AIに正確に指示を出す力」

プロンプトの質でAIの出力の質は大きく変わる

❌ 曖昧な指示：
  「ユーザー認証を作って」

✅ 具体的な指示：
  「FastAPI + PostgreSQLで
   JWTを使ったユーザー認証APIを実装してください。
   - エンドポイント：POST /auth/login, POST /auth/logout
   - パスワードはbcryptでハッシュ化
   - JWTの有効期限は24時間
   - レスポンスはJSON形式
   - エラーハンドリングも含めてください
   - Pytestでユニットテストも書いてください」

効果的なプロンプトの要素：

① 役割を与える
  「あなたはFastAPIの専門家です」
  → より専門的な回答が得られる

② 文脈・制約を伝える
  「このプロジェクトはPython 3.11を使っています」
  「初心者が読めるようにコメントを入れてください」

③ 出力形式を指定する
  「コードブロックで出力してください」
  「手順をステップごとに番号付きで説明してください」

④ 例を示す
  「以下の形式で出力してください：[例]」

⑤ 段階的に進める
  一度に全部やらせるより
  「まず設計を考えて → 確認してから実装」
  の方が精度が上がる

⑥ 検証を依頼する
  「このコードの問題点を指摘してください」
  「セキュリティ上のリスクはありますか？」

② AIの出力を検証・評価する力

「AIが出したコードを鵜呑みにしない」

前回も触れた「コードの審美眼」の具体的な中身：

動作確認：
  □ 実際に動かして期待通りの結果が出るか
  □ エッジケース（空文字・null・大量データ等）でも動くか
  □ エラーハンドリングは適切か

コード品質：
  □ 命名は適切でわかりやすいか
  □ 関数・クラスの責任が適切に分離されているか
  □ 重複したコードがないか

パフォーマンス：
  □ 計算量に問題はないか（N+1・O(n²)等）
  □ 不必要なデータを取得していないか
  □ メモリを無駄遣いしていないか

セキュリティ：
  □ 入力値のバリデーションはあるか
  □ SQLインジェクション・XSSのリスクはないか
  □ 認証・認可は正しく実装されているか

保守性：
  □ 半年後の自分が読んで理解できるか
  □ テストは書かれているか
  □ 変更が必要になったとき修正しやすいか

③ AIとの協働プロセスを設計する力

「AIをどう使えば最も効果的か」を設計できる

単純なAI活用（Before）：
  「コードを書いて」→ AIが出力 → そのまま使う

効果的なAI活用（After）：
  ① 問題の定義（人間）
  ② 設計方針の決定（人間）
  ③ AIへの指示（人間 + AI）
  ④ コードの生成（AI）
  ⑤ レビュー・修正（人間）
  ⑥ テスト・検証（人間 + AI）
  ⑦ ドキュメント作成（AI）
  ⑧ 最終確認（人間）

AIと人間の役割分担を意識することで
品質と速度を両立できる！

チーム開発でのAI活用設計：
  └─ どのツールをどの場面で使うか決める
  └─ AIの出力のレビュー体制を作る
  └─ AIが作ったコードもGitで管理・レビューする
  └─ チームのプロンプトの知識を共有・蓄積する

④ ドキュメントを書く・管理する力

「AIエージェント時代に特に重要になるスキル」

第一回で触れた「AIの記憶問題」の解決策が
ドキュメント化！

ドキュメントには2つの役割があります。どちらも重要です。

📄 役割① AIに渡すためのドキュメント
  → セッションをまたいでも文脈を維持するため

📖 役割② AIが書いたコードを人間がメンテナンスするためのドキュメント
  → 「誰が・なぜ・どういう意図で」書いたコードかを残すため

📄 役割①：AIに渡すためのドキュメント

なぜ必要？：
  AIは毎回ゼロから始まる
  → ドキュメントがないと同じ説明を何度もする
  → ドキュメントがあれば即座に文脈を理解できる

書くべきドキュメント：

📋 AGENTS.md / CLAUDE.md（プロジェクトルール）：
  └─ 使用言語・フレームワーク・バージョン
  └─ コーディング規約・命名ルール
  └─ ディレクトリ構造の説明
  └─ テストの実行方法
  └─ 「やってはいけないこと」のリスト

📐 ADR（Architecture Decision Records）：
  └─ 「なぜこの設計を選んだか」の記録
  └─ 検討した選択肢と却下した理由
  └─ AIも人間も「過去の意思決定」を理解できる

📖 役割②：人間がメンテナンスするためのドキュメント

「AIが書いたコード」の新たな問題：

Before（人間がコードを書いていた時代）：
  コードを書いた人が「なぜそう書いたか」を知っている
  → 後から聞けば意図がわかる

After（AIがコードを書く時代）：
  AIは「なぜそう書いたか」を後から聞けない
  → ドキュメントがないと意図が永遠にわからない 😱

特に起きやすい問題：
  └─ 6ヶ月後に「このコードは何のため？」が誰もわからない
  └─ 「とりあえず動いていた」コードの変更が怖くてできない
  └─ バグを直そうとして別のバグを生む

✅ AIが書いたコードに残すべき情報：
  □ このコードが解決している問題・背景
  □ なぜこのアプローチを選んだか（AIが提案した理由）
  □ 既知の制約・注意点
  □ 変更する際に気をつけるべきこと

💡 具体的な手段：docstringとコメントを活用する

「ドキュメントを別ファイルに書く」のが大変なら、
コードの中にdocstringやコメントとして残すのが最も手軽で効果的です。

# ❌ AIが生成したままのコード（意図が伝わらない）
def get_products_with_cache(category_id: int):
    cache_key = f"products:{category_id}"
    cached = redis.get(cache_key)
    if cached:
        return json.loads(cached)
    products = db.query(Product).filter_by(category_id=category_id).all()
    redis.setex(cache_key, 300, json.dumps(products))
    return products


# ✅ docstring＋コメントで意図を残したコード
def get_products_with_cache(category_id: int) -> list[Product]:
    """カテゴリIDに紐づく商品一覧をキャッシュ付きで取得する。

    背景：
        商品一覧APIのレスポンスが遅かったため、Redisキャッシュを導入。
        DBへの直接クエリを減らしてパフォーマンスを改善している。

    Args:
        category_id: 取得対象のカテゴリID

    Returns:
        商品オブジェクトのリスト

    注意：
        TTLは5分（300秒）。在庫の変動はリアルタイムに反映されない。
        在庫管理の仕様変更時はTTLの見直しも検討すること。
    """
    cache_key = f"products:{category_id}"

    # キャッシュヒット時はDBを叩かずに返す
    cached = redis.get(cache_key)
    if cached:
        return json.loads(cached)

    # キャッシュミス時はDBから取得してキャッシュに保存
    products = db.query(Product).filter_by(category_id=category_id).all()
    redis.setex(cache_key, 300, json.dumps(products))  # TTL: 5分
    return products

✅ AIにdocstringを書かせるプロンプトの例：

「このコードにGoogleスタイルのdocstringを追加してください。
 背景・選定理由・注意点・変更時の考慮点も含めてください」

→ AIが実装したコードの意図を
  AIに説明させてdocstringに残す！
  一石二鳥の使い方 🎯

具体例：
  # AIが生成したキャッシュ処理
  # 【背景】商品一覧APIが遅かったため追加（2026-03-17）
  # 【選定理由】Redisを使うよりシンプルな実装を優先した
  # 【注意】TTLは5分。在庫が変わっても即座には反映されない
  # 【変更時の注意】在庫管理の仕様変更時はTTLを見直すこと
  def get_cached_products(): ...

→ AIが書いたコードこそ
  「なぜこう書いたか」を人間が記録する必要がある！

⑤ セキュリティ意識

「AIが生成したコードのセキュリティを評価できる」

AIはセキュリティを「知っている」が
「あなたのプロジェクトのセキュリティ要件」は知らない

AIが見落としやすいセキュリティの問題：
  └─ 認証・認可のロジックの欠陥
  └─ 環境変数・シークレットの扱い
  └─ SQLインジェクション・XSSのリスク
  └─ 過剰な権限設定
  └─ ロギングに個人情報が含まれる

エンジニアに求められること：
  □ OWASP Top 10を理解している
  □ AIの出力のセキュリティをレビューできる
  □ 「このコードはセキュリティ的に問題ないか？」
     とAIに逆質問できる

---

4. 📉 比重が下がる作業

AIの普及で「時間をかけなくてよくなる」作業：

① 定型的なコーディング
  └─ CRUD操作・バリデーション・テンプレートコード
  └─ 「よくある実装」はAIに任せる時代に

② 構文エラー・タイポの修正
  └─ AIが自動検出・修正を提案
  └─ 人間がゼロから直す必要がほぼなくなる

③ ドキュメントの下書き
  └─ コメント・README・APIドキュメントの初稿
  └─ 人間は内容確認・修正に集中できる

④ 単純な技術調査
  └─ 「〇〇の使い方は？」をドキュメントで調べる作業
  └─ AIに直接聞く方が速い場面が増える

⑤ コードのフォーマット・整形
  └─ Prettier・ESLint等との連携で自動化が進む

💡 ただし重要な注意点：
  これらの作業が「なくなる」わけではない
  「AIが初稿を作り・人間が評価・修正する」
  という役割分担に変わる

  → 評価・修正できない人は
    AIの出力をそのまま使うことになり
    品質が下がるリスクがある！

---

5. 📚 これからの学び方

基礎力を大切にする

「AIが普及したからこそ基礎が重要」

逆説的に聞こえるかもしれないが：

AIがコードを書いてくれる時代
  ↓
コードの「量」を書く必要が減る
  ↓
でも「品質を判断する力」は必要
  ↓
品質を判断するには基礎が必要！

学ぶべき基礎：
  □ アルゴリズム・データ構造
  □ データベース設計・SQLの基本
  □ ネットワーク・HTTP・APIの基礎
  □ セキュリティの基礎（このシリーズ！）
  □ コンピュータのしくみ（メモリ・CPU）
  □ OSとファイルシステム（Linuxコマンド）

AIを「学習ツール」として使う

「AIは最高の学習パートナー」

❌ 悪い使い方：
  わからないことをAIに聞いて
  そのままコードをコピペ
  → 理解がないまま進む → スキルが身につかない

✅ 良い使い方：
  わからないことをAIに聞いて
  └─ 「なぜこうなるの？」と深掘りする
  └─ 「別の書き方はある？」と比較する
  └─ 「この実装の問題点は？」と批評させる
  └─ 「なぜこの実装なのか？」を徹底的に解説させる
  └─ 「もしこのコードに100倍のアクセスが来たら、
       どこがボトルネックになる？」と弱点を探らせる
  └─ 理解してから自分で書いてみる
  → 理解が深まる → スキルが身につく

💡 「100倍のアクセス」問いかけが効果的な理由：

  通常の使い方：「このコードは正しいですか？」
  → AIは「正しい」と答えがち

  スケーラビリティ視点の問いかけ：
  「100倍のアクセスが来たらどこが壊れますか？」
  → AIが「この部分がボトルネックになります」と答える
  → N+1問題・メモリリーク・DBの過負荷などを自ら発見

  さらに発展させると：
  「10倍・100倍・1000倍のアクセスで
   それぞれどこが限界になるか教えて」
  → 段階的にスケーラビリティを学べる！

AIを使った学習の例：
  「このコードを説明してください」
  「もっとシンプルに書けますか？」
  「パフォーマンスを改善するには？」
  「テストコードの書き方を教えてください」
  「このアーキテクチャの長所・短所は？」

「手を動かす」を止めない

AIに任せてばかりいると起きること：

  コードを読むスピードが落ちる
  デバッグの勘が鈍る
  「0から作る」力が落ちる

バランスを保つために：

  ✅ 小さなプロジェクトは自力で実装する
  ✅ AIが書いたコードを読んで理解する
  ✅ AIの提案を「なぜ？」と考えてから採用する
  ✅ 定期的に「AIなし」でコードを書く時間を作る

💡 職人の例え：
  電動工具を使いこなす職人も
  「手道具の使い方」を知っている
  → 道具の特性を理解しているから
    電動工具も正しく使える

  AIも同じ。
  基礎があるから AIを正しく使える！

T字型・π字型のスキルを目指す

「広く浅く + 深く」のバランス

💡 なぜπ字型なのか？

  AIが「広く浅い知識」を補完してくれる時代
  → 人間が幅広い知識を一から習得する時間が減る
  → その分「深い専門性」をもう1本育てられる！

  T字型エンジニア：1つの深い柱
  π字型エンジニア：2つ以上の深い柱

  例：
    深い専門性①：バックエンドAPI設計・セキュリティ
    深い専門性②：AIを使った開発・プロンプトエンジニアリング

  → 掛け合わせることで唯一無二の強みになる 🌟

---

6. 🎯 まとめ

変わらず必要なスキル

スキル	なぜ重要か
🎯 問題定義力	AIに正しく指示するためにも必要
🏗️ 設計力	文脈・制約を踏まえた判断はAIにはできない
🏛️ CS基礎	AIの出力の良し悪しを判断する土台
🐛 デバッグ力	AIのコードのバグを直すのは人間
📖 読解・伝達力	読む・考える・伝える力の重要性が増す

新たに必要なスキル

スキル	具体的な内容
💬 プロンプト力	AIに正確・具体的に指示する力
👁️ 評価・審美眼	AIの出力を正しく検証・評価する力
🔧 協働設計力	AIと人間の役割分担を設計する力
📝 ドキュメント力	AIエージェントに文脈を伝えるための記録力
🔒 セキュリティ意識	AIの出力のセキュリティをレビューする力

🌟 一番大切なこと：

「AIを使う力」と「AIなしでも考える力」
この両方を持ったエンジニアが
AI時代に最も価値を発揮できる！

AIは強力なツールだが、ツールを正しく使うのは人間。
基礎を磨き・AIを学び・両方を組み合わせることで
あなたのエンジニアとしての価値は高まります💪

次回はAI時代のエンジニアとしての生き方を解説します！AIに任せていいこと・任せてはいけないこと・キャリアの考え方・今日からできる具体的なアクションをまとめます🌟

💬 質問や感想があれば、コメント欄でお気軽にどうぞ!
👍 役に立ったら、いいね&ストックをお願いします!
🎓 ここまで読んでくださって、本当にありがとうございました!

---

🔗 シリーズ記事

• 【第一回】AI開発ツールの現在地
• 【第二回】AI時代にエンジニアに求められるスキル（この記事）
• 【第三回】AI時代のエンジニアとしての生き方（近日公開）