AIコーディングエージェント時代に、本当にエンジニアは不要になるのか？

本記事は筆者個人の見解であり、所属組織の公式見解ではありません。また、記事中のチーム構成は説明のための仮定であり、特定の組織を想定したものではありません。

はじめに

GitHub Copilot、Claude Code、Cursor、Devinなど、AIコーディングエージェントの進化が目覚ましい。これらのツールは、自然言語で指示を出すだけで動くコードを生成してくれる。

こうした状況を受けて、「AIがコードを書けるなら、エンジニアはもう不要なのでは？」という声が聞こえてくるようになった。本記事では、この「エンジニア不要論」を真剣に考えてみる。

「エンジニア不要論」には2つの解釈がある。1つは「エンジニアという職種が消える」という職種消滅論。もう1つは「組織にエンジニアを置かなくてよくなる」という組織運用論だ。本記事では前者、つまり「エンジニアという職種は消えるのか？」を考察する。

アプローチとして、極端なケースを想定する。非技術者のPMとデザイナーが、AIコーディングエージェントだけを使ってサービスを運営できるか？というシナリオだ。もしこれが成立するなら、エンジニアの仕事はAIで完全に代替可能であり、職種として消えることになる。

考察の前提条件

本考察の意図

本考察は、PMやデザイナーの専門性や価値を否定するものではない。それぞれの職種には固有の専門性があり、エンジニアには代替できない価値を提供している。ここでは「技術的判断」という特定の領域に焦点を当てて、その判断ができる人材の必要性を考察する。

AIの能力設定

本考察では、AIコーディングエージェントの能力を以下のように設定する。

• ユーザーから与えられた指示を汲み取り、機能的に動くものを出力できる
• セキュリティやエッジケースについて提案することもあるが、必ずしも提案するとは限らず、提案しても網羅的とは限らない
• 最終的な保証・責任は持てない

現在のAIコーディングエージェントは、XSS対策や排他制御などを自ら提案することもある。しかし、提案するかどうかは状況によって異なり、提案したとしてもそれが網羅的かどうか、自社サービスの文脈で適切かどうかの判断と責任は、依然として人間側に残る。

重要な前提として、公開サービスは「動く」だけでは足りない。「守れる」「説明できる」「復旧できる」が求められる。AIは局所的な正しさは出せるが、全体最適・トレードオフ・説明責任は担えない。

本考察の時間軸

本記事の考察は、2025年時点のAI能力を前提としている。AIの進化は急速であり、技術的な能力は予測が難しい。しかし、以下の理由から本記事の結論は当面有効と考える。

1. 技術的限界：AIが「責任を取る」ことは法的・倫理的に困難。判断の最終責任は人間に残り続ける。
2. 組織的限界：仮にAIが完璧な判断をできても、ステークホルダーへの説明責任、監査対応、契約上の責任者は人間が必要。
3. 信頼の問題：ユーザーや取引先が「AI任せのサービス」を信頼するかは技術とは別の問題。

ただし、AIが自律的に判断・修正・学習できるようになれば、この前提は崩れる可能性がある。その時点で本記事は改めて検証が必要だ。

チーム構成

従来のチーム構成として、5人体制を想定する。

役割	人数	主な業務
PM	1人	企画・戦略（市場調査、ロードマップ策定）、要件定義（ユーザーストーリー作成、仕様策定）、進行管理（リリース計画、各チームへの依頼）、検証（受け入れテスト、効果測定）
インフラエンジニア	1人	クラウドインフラ構築・運用（AWS/GCP等）、CI/CDパイプライン構築、監視・アラート設定、ログ収集・分析基盤構築、セキュリティ対策、障害対応・復旧作業、技術キャッチアップ・情報共有（インフラ関連の新技術、脆弱性情報）
サーバーエンジニア	1人	システムアーキテクチャ設計、技術選定、DB設計（テーブル設計、インデックス設計）、API設計・実装、認証・認可設計、自動テスト作成、コードレビュー、技術キャッチアップ・情報共有（バックエンド関連の新技術、ライブラリの脆弱性情報）
アプリエンジニア	1人	アプリアーキテクチャ設計、UI実装、API連携実装、ローカルDB設計・実装、プッシュ通知実装、アプリストア申請・リリース、クラッシュ分析・対応、技術キャッチアップ・情報共有（モバイル関連の新技術、OS/ライブラリの脆弱性情報）
デザイナー	1人	ユーザーリサーチ、UIデザイン（Figma等）、プロトタイプ作成、デザインシステム構築、デザインガイドライン策定、実装後のデザインQA

これに対し、「エンジニア不要論」を適用した場合のチーム構成は以下の通りだ。

役割	人数	備考
PM	1人	変更なし
デザイナー	1人	変更なし
エンジニア	0人	AIコーディングエージェントで代替

つまり、3人分のエンジニアの専門的な業務をAIと非技術者で代替できるか？という検討になる。

対象範囲とスキルレベル

新規開発だけでなく、運用・保守・障害対応もすべて含む。サービスを継続的に運営していく全てのフェーズを対象とする。

また、PMとデザイナーは非技術者を想定する。プログラミング経験はなく、技術用語の理解も限定的とする。

例外：エンジニア0人でも成立しうる条件

公平を期すために、エンジニアがいなくても許容できる可能性があるケースについても触れておく。以下の条件を満たす場合、エンジニア0人でも成立しうる。

• 利用者が限定され、外部公開しない： 社内ツールなど、利用者が特定されている
• 失敗コストが小さい： 使い捨てのMVP、法的リスクが低い、捨てても問題ない
• SLO・監査・セキュリティ要件が軽い：24時間稼働不要、個人情報を扱わない

例えば、完全に使い捨てのMVP（Minimum Viable Product）であれば、セキュリティや保守性の問題があっても「検証が終わったら捨てる」前提で割り切れる。

ただし、本記事で扱っているのは「継続運用する公開サービス」であり、上記の条件を満たさないケースだ。この前提においてはエンジニアが必要という結論は変わらない。

考察結果：エンジニアが必要な7つの理由

1. セキュリティ観点

AIコーディングエージェントは、セキュリティ対策を提案することもある。しかし、その提案が網羅的かどうか、自社サービスの文脈で適切かどうかを判断する責任は人間側に残る。問題は、非技術者のPMにはその判断が難しいということだ。

具体例を挙げよう。PMが「ユーザー検索機能を作って」と指示したとする。AIはORMやパラメータ化クエリを使った安全なコードを出力することもあれば、SQLを直接組み立てる脆弱なコードを出力することもある。仮に安全なコードを出力したとしても、それが本当に安全かどうか、他に対策すべき箇所がないかを検証できるのは技術的知識を持った人間だけだ。非技術者は「動いた」ことは確認できても、「安全か」は判断できない。結果として、攻撃を受けて情報漏洩につながる可能性がある。

セキュリティ対策を網羅的に指示するには、たとえば以下のような知識が必要になる。

• SQLインジェクション、XSS、CSRFなどの攻撃手法
• 認証・認可の設計（セッション管理、トークンの有効期限、リフレッシュトークン）
• パスワードのハッシュ化アルゴリズムの選定
• 依存ライブラリの脆弱性チェック

これらはほんの一例であり、実際にはサービスの特性に応じてさらに多くの観点が存在する。これらを「指示すべきこと」として認識し、適切に指示できるのは、セキュリティの知識を持ったエンジニアだけである。

2. 品質・保守性観点

エンジニアがいないチームでは、コードの一貫性やアーキテクチャの整合性を維持できない。リファクタリングの必要性を判断できないし、技術的負債が蓄積していることにも気づけない。

1年間、PMとAIだけで開発を続けるとどうなるか。コードベースがスパゲッティ化し、新機能追加に異常に時間がかかるようになる。しかし、なぜ遅くなったのか原因がわからない。結果としてサービスが停滞する。

仮にAIが一貫性のある読みやすいコードを常に出力できるとしても、問題は残る。「読みやすい」と「正しい」は別問題だからだ。

観点	AIが出力できること	人間が判断すべきこと
コードスタイル	一貫性のある可読なコード	-
設計の妥当性	設計パターンの適用	そのアーキテクチャが要件に適切か
技術選定	ライブラリの提案	選んだライブラリが適切か、将来性があるか
ビジネスロジック	指示に基づく実装	仕様通りに実装されているか
テスト戦略	テストコードの生成	テストが十分か、エッジケースを網羅しているか

例えば「商品のお気に入り機能を作って」と指示した場合、お気に入りの上限は？削除商品の扱いは？ソート順は？といった詳細を非技術者PMは「指示すべきこと」として認識できない。AIが確認を求めることもあるが、何を確認すべきか網羅的ではない。また、確認されても非技術者にはその重要性を判断できない。

また、選んだORMが1年後にメンテナンス停止になるかもしれないし、使ったライブラリに重大な脆弱性が後から見つかるかもしれない。非技術者は技術選定の妥当性を評価できない。

特に脆弱性の問題は深刻だ。エンジニアは日常的にセキュリティ情報をキャッチアップし、使用しているライブラリに脆弱性が発見されれば即座にチームに共有してアップデートを行う。しかし非技術者は脆弱性情報を日常的に追う習慣を持ちにくい。CVEやセキュリティアドバイザリを監視する習慣もなければ、それを読んで自社サービスへの影響を判断する知識もない。結果として、重大な脆弱性が放置されたままサービスが運用され続けるリスクがある。

「ポイント付与機能を作って」と指示した場合も同様だ。同時リクエスト時の排他制御は？トランザクション整合性は？監査ログは？非技術者は動作確認で「動いてる」と判断するが、エッジケースや並行処理の問題は見逃す。

読みやすいコードでも、同じ処理が複数箇所に散らばっていたり、本来分離すべき責務が1つのクラスに集中していたりする。これらは「読めばわかる」レベルの問題ではなく、システム全体を俯瞰する目が必要だ。

「AIの出力がより正確になれば、レビュー自体が不要になる」という意見もある。さらに進んで、設計方針もAIが決めて忠実に守ってくれる（既存のアーキテクチャやコーディング規約との整合性を保証する）という前提を置いたらどうだろうか。それでも以下の問題が残る。

まず、設計方針そのものの妥当性を誰が評価するかという問題がある。AIが決めた設計方針が、そのサービスやビジネスにとって本当に適切かどうかは、AIには判断できない。「この規模のサービスにこのアーキテクチャは過剰ではないか」「この技術選定は3年後も維持可能か」といった判断には、ビジネス文脈の理解と技術的知見の両方が必要だ。

次に、設計方針を変更すべきタイミングの判断がある。サービスの成長に伴い、当初の設計方針では対応できなくなる局面は必ず来る。「今のアーキテクチャではこれ以上スケールしない」「技術的負債が限界に達している」といった判断は、システム全体を俯瞰し、将来を見据えられるエンジニアでなければできない。AIは現状の設計方針を守ることはできても、その方針自体を見直すべきかどうかは判断できない。

また、AIがどれだけ正確にコードを出力しても、そのコードに対する責任は人間に残る。障害が発生したとき、セキュリティインシデントが起きたとき、ユーザーに損害を与えたとき、「AIが出力したコードなので」は言い訳にならない。責任を取れる人間が、出力されたコードを理解し、承認する必要がある。

最後に、ビジネス要件との整合性の問題がある。AIが設計方針を守って一貫性のあるコードを出力しても、そのコードがビジネス要件を満たしているかどうかは別問題だ。「この機能は法規制上問題ないか」「このデータの扱いはプライバシーポリシーに違反しないか」「この仕様変更は既存ユーザーに影響を与えないか」といった判断は、技術とビジネスの両方を理解している人間でなければできない。

3. 障害対応観点

障害対応は、リアルタイムで判断を続ける作業である。AIに指示→回答待ち→理解できない→再質問...というサイクルでは間に合わない。

非技術者が障害対応できない理由は複数ある。まず原因特定において、ログの読み方、メトリクスの見方、システム構成の理解が必要だ。緊急度の判断も難しい。DB破損なのか、ネットワーク障害なのか、リソース枯渇なのかを判断できない。復旧手順の実行も困難で、AIが「DBのレプリカにフェイルオーバーして」と言っても、非技術者は実行できない。二次被害の防止も同様で、復旧作業中に別の問題を起こさないための判断ができない。

深夜2時にサービスダウンしたとしよう。PMがAIに「直して」と指示しても、AIに指示→回答待ち→理解できない→再質問...というサイクルを繰り返すうちに、復旧までの時間（MTTR）は伸び続ける。障害対応において「待ち」は致命的だ。エンジニアであれば数分で判断できることが、非技術者とAIの往復では数時間かかり、売上損失やユーザー離脱につながる。

4. スケーラビリティ観点

パフォーマンス問題は「起きてから」では遅い。「ユーザー数が10倍になったらどうなる？」という質問を非技術者が発想できない。N+1問題、インデックス設計、キャッシュ戦略などを事前に考慮できないし、Auto Scaling、ロードバランサー、CDNの設定を適切に指示できない。

スケーラビリティは事前投資である。サービスがバズって急にアクセスが増加したとき、その場で対応しようとしても手遅れだ。事前に設計されていないシステムを後から直すコストは、最初から考慮して設計するコストの何倍にもなる。非技術者は「今は動いているから大丈夫」と判断しがちで、この事前投資の発想を持ちにくい。

5. コスト観点

クラウドサービスの料金体系は複雑で、適切な選択をしないと想定外の高額請求、いわゆる「クラウド破産」を引き起こすリスクがある。非技術者がAIにインフラ構築を指示した場合、このリスクは特に高くなる。

例えば、「データベースを作って」と指示したとき、AIは動くものを作ってくれる。しかし、非技術者には「何を指示すべきか」がわからない。本番と開発でインスタンスサイズを変えるべきか、Savings Plansとオンデマンドのどちらが適切か、Auto Scalingの上限をいくつに設定すべきか——これらは「指示すれば対応できる」問題だが、そもそも指示すべきことを知らなければ、AIに伝えようがない。非技術者はこれらの設定が月額料金にどう影響するか判断できない。

エンジニアがいれば、以下のようなコスト最適化の判断ができる。

• 「この散発的な処理はEC2じゃなくてLambdaで十分」
• 「開発環境は夜間と週末は停止しよう」
• 「このワークロードはスポットインスタンスで80%コスト削減できる」
• 「Savings Plansを購入すれば40%安くなる」
• 「このS3バケットはアクセス頻度が読めないからIntelligent-Tieringにしよう」

これらの判断には、各サービスの料金体系、ワークロードの特性、可用性要件のバランスを理解している必要がある。非技術者には「動いているから大丈夫」としか判断できず、月末の請求書を見て初めて問題に気づくことになる。

6. アプリリリース観点

モバイルアプリを提供している場合、AppleやGoogleのプラットフォームポリシーへの対応が継続的に必要になる。これはエンジニアでなければ対応が難しい領域だ。

プライバシーポリシーの強化、新しいAPIへの移行義務、審査基準の変更など、対応が必要な変更は多岐にわたる。これらは事前に告知されるものの、非技術者はApp Store ConnectやGoogle Play Consoleからの通知を日常的にチェックする習慣がない。気づいたときには対応期限が迫っていたり、審査でリジェクトされてから慌てることになる。ポリシー違反は対応が遅れれば、アプリがストアから削除されるリスクもある。

エンジニアがいれば、これらの情報を早期にキャッチアップし、「来年の○月までにこの対応が必要なので、ロードマップに入れておきましょう」と提案できる。非技術者だけでは、このような先回りの対応は難しい。

7. 会議・要件定義観点

サービス開発の会議において、エンジニアは「技術的フィルター」として機能している。

エンジニアがいる場合の流れは以下の通りだ。PMが「こういう機能を作りたい」と言い、エンジニアが実現可能性、リスク、代替案、工数感といった技術的フィルターを通す。その上で合意形成し、開発に進む。

一方、エンジニアがいない場合はどうなるか。PMが「こういう機能を作りたい」と言い、AIが実装する。AIが確認や警告を出すこともあるが、非技術者にはその重要性や影響範囲を判断できず、「動いたからOK」で進んでしまう。後から問題が発覚する。

具体的なシーンを見てみよう。

技術的実現可能性の判断

エンジニアがいる場合：

PM「商品画像をAIで自動生成したい」

エンジニア「現状のインフラだとGPUがないので、外部API使うことになります。コストが1枚あたり○円かかりますが、それでいいですか？」

エンジニアがいない場合：

PM「商品画像をAIで自動生成したい」

AI「はい、実装します」

→ コストや制約の説明なく進み、月末に想定外の請求が来て慌てることになる。

仕様の曖昧さ・抜け漏れ

エンジニアがいる場合：

PM「クーポン機能を作りたい」

エンジニア「いくつか確認させてください。1人何回まで使えますか？他のクーポンと併用できますか？有効期限切れたクーポンの表示はどうしますか？対象商品の制限はありますか？最低購入金額の条件はありますか？」

エンジニアがいない場合：

PM「クーポン機能を作って」

AI「作りました。併用可否は禁止、有効期限は30日で実装しています」

PM「動いてるからOK」

→ AIは一部の仕様を報告するが、PMはそれが適切か判断できない。確認すべき観点の抜け漏れにも気づけず、後から仕様変更の嵐になる。

代替案の提示

エンジニアがいる場合：

PM「リアルタイムで在庫を表示したい」

エンジニア「完全なリアルタイムは負荷が高いので、5分間隔の更新か、WebSocketで変更時のみ通知する方式が現実的です。どちらがいいですか？」

エンジニアがいない場合：

PM「リアルタイムで在庫を表示して」

AI「WebSocket実装しました」

→ 非技術者は選択肢があることを知らないまま、オーバースペックな実装になるか期待と違う実装になる。

セキュリティ・法規制の懸念

エンジニアがいる場合：

PM「ユーザーの行動履歴を全部保存してパーソナライズしたい」

エンジニア「個人情報保護法やGDPRの観点で、同意取得のフローが必要です。データ保持期間を決める必要があります。ユーザーからのデータ削除要求に対応する機能も必要です」

エンジニアがいない場合：

PM「ユーザーの行動履歴を全部保存して」

AI「保存する機能を実装しました」

→ 法規制違反のリスク、後から大幅な改修が必要になる。

運用視点での懸念

エンジニアがいる場合：

PM「管理画面から商品を一括登録できるようにしたい」

エンジニア「10万件とか一括登録されるとDBロックで本番に影響出る可能性があります。バックグラウンドジョブにして、進捗表示する形にしましょう」

エンジニアがいない場合：

PM「一括登録機能を作って」

AI「同期処理で実装しました」

→ 運用時に大量登録でサービスダウンする。

技術的負債の警告

エンジニアがいる場合：

PM「とりあえず急ぎで作って、後で直せばいいから」

エンジニア「それだと後で直すコストが3倍になります。今ちゃんと作るか、スコープを削って品質を保つかどちらかにしませんか？」

エンジニアがいない場合：

PM「急ぎで作って」

AI「作りました」

→ 技術的負債の蓄積を誰も警告しない。気づいたときには手遅れだ。

新技術の提案

エンジニアがいる場合：

エンジニア「最近○○というサービスが出てきて、うちのユーザー認証をパスキーに対応させるのが簡単になりました。パスワード忘れの問い合わせも減るし、セキュリティも上がるので導入を検討しませんか？」

PM「それいいね、次のスプリントで検討しよう」

エンジニアがいない場合：

PMは新技術の存在を知る機会がない。技術ブログやカンファレンス、セキュリティアドバイザリを日常的にチェックする習慣がないため、サービス改善に活用できる技術があっても気づけない。AIに「何か新しい技術ある？」と聞いても、自社サービスの文脈に合った提案は期待できない。

→ 競合他社が新技術を採用して差別化される一方、自社サービスは古い技術のまま取り残される。

本質的な問題

非技術者は「何を質問すべきか」がわからない。エンジニアは会議で「待って、それって○○の場合どうなる？」と質問する。この質問自体が技術的知識に基づいているため、非技術者には発想できない。

結論：エンジニア0人は無理。必要なのは「実装者」ではなく「判断者」である。

なぜエンジニアは不要にならないのか、ここまでの考察で明らかになったのは、以下の関係性である。

AIの能力 = f(指示の質)
指示の質 = f(技術的知識)
∴ AIの能力は、指示者の技術的知識に制約される

つまり、「AIが賢くなるほど人間は不要になる」のではなく、「AIを使う人間の判断品質がボトルネックになる」のである。ここでいう技術的知識とは、プログラミング言語の文法ではなく、非機能要件・運用・リスクに関する知識を指す。

AIコーディングエージェントは、指示されたことを実行する能力は非常に高い。セキュリティやエッジケースについて提案することもある。しかし、その提案が網羅的か、自社サービスの文脈で適切かを判断する責任は人間側に残る。

言い換えれば、AIは「超優秀なアシスタント」だ。指示されたタスクは高品質にこなせるし、相談すれば意見も出してくれる。しかし、最終的な判断を下して責任を取るのは人間だ。プロジェクト全体を俯瞰した判断や、先を見据えた設計の責任は人間のエンジニアが担う必要がある。実装力と判断力は別の能力であり、AIがどれだけ賢くなっても、この「判断と責任の所在」は変わらない。

だからこそ、「エンジニア0人」は無理だが、「少人数のエンジニア＋AI」は非常に強力な組み合わせになる。判断力のあるエンジニアがAIを使いこなせば、コーディング作業の効率は大幅に上がる。エンジニアが不要になるのではなく、エンジニアがより価値の高い判断業務に集中できる時代が来るのだ。

では、PMやデザイナーが技術的知識を身につけてその役割を担えばいいのではないか？という反論があるかもしれない。実際、これは一つの現実的な未来像だ。

「技術がわかるPM」や「PM兼アーキテクト」といった、職種の境界を越えたハイブリッド人材が活躍する時代が来るかもしれない。ビジネス視点と技術視点の両方を持ち、AIを駆使して高速にプロダクトを形にできる「スーパージェネラリスト」の誕生だ。

ただし、これは「エンジニアが不要になった」のではなく、「エンジニアリングスキルがより広い職種に求められるようになった」ということだ。技術的判断力を持つ人材は組織に必要であり続ける。その人の肩書きが何かは本質ではない。

つまり、「エンジニア」という職種名は変わるかもしれない。しかし「技術的判断ができる人」は必要であり続ける。これが本記事の結論だ。

エンジニアの役割はどう変化するのか

「エンジニアが不要になる」のではなく、エンジニアの役割が変化する。

単純な機能の実装作業の多くはAIが担うようになる一方で、以下のようなスキルがより重要になる。

1. システム全体を俯瞰する力：アーキテクチャ設計や技術選定を主導できる
2. 特定領域の専門性：セキュリティ、スケーラビリティ、インフラ等の深い知識で複雑な問題を解決できる
3. AIへの適切な指示力：AIに何を任せ、何を自分で判断すべきかを見極められる
4. レビュー力：AIの出力に潜む問題を発見し、修正する
5. コミュニケーション力：要件の曖昧さや技術的リスクを指摘し、合意形成する
6. タスク分解力：複雑な開発要件を適切な粒度に分解し、効率的に進められるようにする

注意すべきは、これらのスキルは従来のコーディングスキルとは異なるという点だ。コーディングそのものに多くの時間を割いていた時代から、「何を作るべきかを判断し、AIの出力を検証できる」ことが求められる時代への転換である。

つまり、エンジニアも安泰ではない。これまでコーディングに特化してきたエンジニアは、新しいスキルセットへのアップデートが求められる。アーキテクチャ設計やレビューの経験が少ないエンジニアにとって、この転換は容易ではないだろう。AI時代に生き残るためには、エンジニア自身も継続的な学習と適応が必要になる。

AI時代のエンジニア育成の課題

ここで一つの懸念が生じる。判断力は経験から生まれるが、AIがコーディングを代替する時代に、その経験をどう積むのか？

コーディング経験と判断力の関係

従来、エンジニアは様々な経験を通じて判断力を身につけてきた。

設計・実装の経験

• 自分で設計を考え、トレードオフを検討する
• 「この方法とあの方法、どちらがいいか」を比較検討する
• 実装してみて初めて設計の問題点に気づく

コードレビューの経験

• 他人のコードを読み、改善点を指摘する
• 自分のコードにフィードバックをもらい、視点を広げる
• 「なぜこの書き方がダメなのか」を言語化する

技術選定の議論

• チームで技術選定を議論し、各選択肢のメリット・デメリットを比較する
• 過去の選定が正しかったか、後から振り返る

既存コードの読解

• 大規模なコードベースを読み、設計意図を理解する
• 「なぜこう書かれているのか」を推測する

リファクタリングの経験

• 既存コードの問題点を特定し、改善する
• 変更による影響範囲を予測する

AIがコーディングを代替すると、特に「設計・実装の経験」の入口が狭まる懸念がある。自分で試行錯誤する機会が減ることで、判断の根拠となる「引き出し」が増えにくくなる可能性がある。

AI時代でも残る学習機会

一方で、AI時代でも判断力を養う機会は残る。

• AIの出力を比較検討する：複数のアプローチをAIに出させ、どれが最適か判断する経験
• AIの出力の問題点を発見する：動くコードの中に潜む設計上の問題を見抜く目を養う
• AIへの指示を改善する：より良い出力を得るために、何を明示すべきか学ぶ

重要なのは、AIの出力を鵜呑みにしない姿勢だ。これはAI時代に始まった話ではない。かつてStackOverflowで見つけたコードをそのままコピペして「動いたからOK」としていたエンジニアと、コードの意味を理解してから使っていたエンジニアでは、成長速度に大きな差があった。AIの出力も同じだ。

AIが出力したコードに対して「なぜこの実装なのか？」「他の方法はないのか？」と疑問を持ち、AIに質問を重ねる。あるいは、自分でドキュメントを読んだり、実際にコードを動かして検証したりする。この「理解しようとする努力」が判断力を養う。

AIは答えを出してくれるが、その答えに至る過程を理解しなければ、応用が利かない。「動いたから終わり」ではなく、「なぜ動くのか」を追求する姿勢は、エンジニアにとって以前から重要だった。しかし、AIが簡単に「動くコード」を出力してくれる時代だからこそ、この姿勢の有無が成長の差としてより顕著に表れるようになる。

むしろ「手を動かす作業」から解放されることで、「考える時間」が増える可能性もある。ただし、これは意識的に学習機会を作る場合の話だ。漫然とAIに任せるだけでは、判断力は身につかない。

考えられる育成パス

AI時代でも判断力を身につけるための育成方法として、以下が考えられる。

1. レビュー中心の育成：AIの出力をレビューし、問題を発見・修正する経験を積む。「書く」から「検証する」へのシフト。
2. 障害対応での学習：本番障害の対応に同席したり、ポストモーテムを読んだりして、システムの挙動を深く理解する。
3. AIとの対話による深掘り：AIに複数のアプローチを出させ、それぞれのメリット・デメリットを議論する。「なぜこの方法を選んだのか」をAIに説明させ、自分でも検証することで理解を深める。
4. 意図的な制約下での実装：特定の機能（認証、決済など）については、学習目的であえて自分で設計・実装する。全てをAIに任せるのではなく、重要な領域は手を動かす経験を残す。
5. メンターによる伝承：判断力のあるシニアエンジニアが、「なぜこの設計にしたか」「何を警戒すべきか」を言語化して伝える。

AIを育成ツールとして活用する

AIは学習の障害になるだけでなく、むしろ育成ツールとして活用できる可能性がある。

• AIにわざと悪いコードを書かせてレビューする：「セキュリティを無視して」「エラーハンドリングなしで」と指示し、出力された問題のあるコードをレビューする訓練ができる
• 設計段階でAIを壁打ち相手にする：「この設計のデメリットは？」「他のアプローチは？」とAIに問いかけ、設計の引き出しを増やす
• 実装後にAIに説明させて理解を深める：AIが書いたコードについてAIに説明させ、自分の理解が正しいか確認する。見解が異なる場合は自分で検証し、AIに指摘することでさらに理解を深める

シニアエンジニアに質問するのは気が引けても、AIには何度でも質問できる。この「質問しやすさ」を活かした育成は、AI時代ならではの可能性だ。

AI時代のエンジニア育成は、業界全体で取り組むべき課題だ。判断できるエンジニアが育たなければ、AIを活用する人材も不足することになる。

まとめ

AIコーディングエージェントの進化により、エンジニアの仕事は確実に変化する。しかし、それは「不要になる」ことではない。AIの能力は指示者の技術的知識に制約されるという本質的な限界がある限り、技術的な判断ができるエンジニアは必要であり続ける。

本記事のポイントをまとめると以下の通りだ。

1. セキュリティ：非技術者は脆弱性対策を網羅的に指示できない
2. 品質・保守性：技術的負債の蓄積を誰も検知できない
3. 障害対応：リアルタイムの判断が必要な場面でAIを介すと間に合わない
4. スケーラビリティ：予防的な設計を考慮できない
5. コスト：クラウド料金の最適化判断ができず想定外の高額請求のリスクがある
6. アプリリリース：プラットフォームポリシーの変更に先回りで対応できない
7. 会議・要件定義：非技術者は「何を質問すべきか」がわからない

エンジニアの価値は「コードを書くこと」ではなく、「何を作るべきか」「どう作るべきか」を判断することにある。AIがどれだけ進化しても、この判断能力の価値は変わらない。むしろ、AIを効果的に活用するためには、より高度な技術的判断力が求められるようになる。

「AIでエンジニアは不要になる」のではなく、「AIによってエンジニアの価値がより明確になる」と言えるのではないだろうか。

結局、エンジニア0人が成立するのは「捨てられる・閉じている・責任が軽い」世界だけだ。公開サービスの継続運用では「判断と責任」が残る。そしてその判断と責任を担えるのは、技術的知識を持った人間、つまりエンジニアなのだ。