経験豊富なITエンジニアがAIを恐れない理由

1. はじめに

近年、AIの進化は目覚ましく、特にコード生成の領域では Claude Code や Codex といったエージェントの登場により、かつては数日かかっていたコード作成が、数分・数時間で形になる時代になりつつあります。

このような変化を受けて、SNSを中心に「ITエンジニアはこれから不要になる」「コーディングはAIに任せれば人はいらない」といった、いわゆる ITエンジニア不要論 を目にする機会が増えてきました。特に若手のITエンジニアやこれからITエンジニアを目指す方を中心に、こうした言説に触れて自信をなくしてしまっている方も少なくないのではないでしょうか。

しかし、現場で豊富な経験を積んできたITエンジニアほど、それほどAIを恐れていない印象があります。これは「上位数％の特別な層」に限った話ではありません。きちんと現場でITエンジニアとしての経験を積んできた方であれば、同じように感じるはずだと考えています。

本記事では、まずなぜ経験を積んだITエンジニアがAIを恐れていないのかを整理し、そのうえでこれからAI時代を生き残っていくために何を意識すればよいのかを見ていきます。

2. 世間の声と現場の温度差

この温度差を生んでいる最大の要因は、AIで置き換えられる領域が、普段ITエンジニアが行う業務のほんの一部でしかない という現場感覚にあります。言い換えると、ITエンジニアの実務は 手を動かしている時間よりも「考えている時間」の方が圧倒的に多い という特性があり、AIで自動化しにくい部分の方が大きいということです。

AIが現時点で得意としているのは、主にコーディングを中心とした領域です。アプリケーションコードの生成はもちろん、テストコードの自動生成や一部の単体テストの実行、最近では Terraform や CloudFormation を使ったインフラ構築まで、コードとして書き起こせる領域は急速にAIで対応できるようになってきました。さらに MCP (Model Context Protocol) を活用すれば、コードを介さずに AI エージェントから直接 AWS のリソースを作成・操作することすら可能になっています。設計書の作成も、現時点では完璧ではないものの、いずれはさまざまなフォーマットでドラフトを作ってくれるようになっていくでしょう。

ただし、こうしてAIに任せられる領域は、実はITエンジニアの業務全体のごく一部にすぎません。それ以外の大半は、目に見えにくい「考える時間」が占めています。

たとえば、利用者やクライアントが何を達成したいのか、どんなシステム構成にすべきか、セキュリティリスクにどう対処するか、どうすればシステムを安定して動かし続けられるか、出来上がったものが本当に目的どおりに動いているか、運用中に出てきた問題にどう対応するか、といったことを「考える」時間がそれにあたります。

こうした「考える時間」の領域は、AIに補佐させることはできても、AIだけで目的までたどり着けるわけではありません。

たとえば「自社のECサイトで売上を伸ばす機能を追加する」という目的があったとします。AIに頼めば実装やテストのコードはある程度形にしてくれますが、「売上を伸ばすためにそもそもどんな機能を作るか」「複数の案のうちどれを優先するか」「顧客情報や決済データを安全に扱うためにどんなセキュリティ対策が必要か」「セール時のアクセス集中でもサービスを止めないためにどんな可用性を確保するか」「リリース後に売上が本当に伸びたかをどう測るか」「出てきた数字をもとに次の打ち手をどうするか」を考える部分は、引き続き人間が担う領域です。

実はシステム開発や運用の業務は、こうした「〜を考える」工程が大半（感覚としておよそ7〜8割）を占めています。AIがどれだけコーディングを高速化したとしても、ITエンジニアの仕事の大半は手元に残ります。世間で語られている「ITエンジニア不要論」と、現場で働いているITエンジニアの感覚に温度差があるのは、ここに大きな理由があります。

私自身もITの現場に立っていますが、AIによってコーディングやドキュメント作成が格段に効率化されている実感はあります。しかし、それでITエンジニアが不要になったかと言われると、まったくそんなことはありません。要件のすり合わせ、設計判断、運用時の対応など、人手が必要な領域は変わらず多く、業界全体としての人手不足もむしろ深刻なままです。「AIで効率が上がった」ことと「ITエンジニアが不要になった」ことは、まったく別の話だというのが現場の率直な感覚です。

なお、これは肌感覚だけの話ではありません。経済産業省が公表した「IT人材需給に関する調査」では、2030年時点で最大約79万人のIT人材不足が想定されています。AIの普及で個別作業が効率化されても、判断と責任を担えるITエンジニア自体は引き続き足りていない、というのが現場感覚を裏付ける構造です。

見方を変えれば、これまで「時間が足りない」ことを理由に十分にできなかった 「考える時間」 に、AI で生まれた余裕を回せるようになる、ということでもあります。さらに、これまで時間の制約からひとつの案しか実装できなかった場面でも、AIで素早く複数案を試せるようになるため、トライ&エラーを重ねながらより良いものを作っていけるという利点もあります。AIはITエンジニアの仕事を奪う存在ではなく、本来やりたかった部分に集中させてくれる 味方 だと捉えるのが、現場感覚に近い受け止め方です。

3. ITエンジニア不要論を語っているのは誰か

ではなぜ、SNS上ではこれほどまでにITエンジニア不要論が広まっているのでしょうか。

発信源をたどってみると、いくつかの共通したパターンが見えてきます。ここでは、特によく見かける3つの発信パターンを取り上げます。

3.1. AI商材を販売したい人

まず分かりやすいのが、自分が販売しているAI関連の商材を盛り上げたい立場の方からの発信です。AIコンサルティング、AIツールやSaaS、AI関連の教育サービス、AI活用を支援する受託開発など、AIを大きく見せれば見せるほど売上に直結する方々がここに該当します。

これは動機が明確なポジショントークであり、聞く側が「商売の話か」と理解できれば、それほど惑わされることはありません。さらにこのタイプの発信は、「ITエンジニア不要」と言いっぱなしで終わるのではなく、「だからAIを使いましょう」「こうすれば解決します」と一定の解決策までセットで提示してくれているケースが多く、その意味では、ただネガティブを煽るだけの投稿よりはるかに建設的だとも言えます。

3.2. ITエンジニアの解像度が低い人

次によく見かけるのが、ITエンジニアの業務内容を細かく把握していない方からの発信です。経営者・著名インフルエンサー・業界外の評論家など、自身でコードを書いた経験がなかったり、書いたとしてもごく一部の作業だけを見て「これがITエンジニアの仕事の大半」と理解してしまっている方々が該当します。

このタイプの発信には基本的に悪意はなく、純粋に「目に見える成果物が作れた」という事実だけを切り取って結論を出しているケースが多いです。コードの生成や設計書のドラフト作成といった目立つアウトプットの陰で、ITエンジニアがどんな判断に時間を費やしているかが見えていないためです。

ただし、こうした方は影響力のある立場にいることが多く、発信内容の拡散力も大きくなりがちです。受け取る側としては、その方が現場のITエンジニア業務の全体像をどこまで把握しているかを意識して、冷静に受け止める姿勢が必要になります。

3.3. ITエンジニアから別の職種に移った人

そしてもっとも見極めが難しいのが、過去にITエンジニアの経験はあるものの、現在は別の職種に移っている方からの発信です。経営側に回った方、マネジメント職に上がってずいぶん前から現場のコードに触れていない方、別のビジネスを立ち上げた方などが該当します。

このタイプの難しさは、二つの要素が重なる点にあります。ひとつは、自分が現場を離れた選択を肯定する動機がどうしても入りやすいことです。「もうITエンジニアは不要だ」と語ることは、結果として「自分が現場から離れたのは正しかった」というメッセージにもなります。

もうひとつは、「元エンジニア」という肩書きが、発信に強い信憑性を与えてしまうことです。業界外の方の発言なら割り引いて聞ける読み手も、「同じ経験を持つ方が言っているなら本当かもしれない」と受け取ってしまいやすくなります。商材販売や業界外と違い、現場側の感覚で語っているように見えるため、受け取る側もブレーキを掛けにくい構造になっています。

こうした発信を受け止めるうえでもっとも難しいのは、これらの投稿には基本的に解決策の提示が伴わない、という点です。「もう不要だ」とネガティブに言い切るだけのほうがSNSでは伸びやすいものの、解決策が示されていない投稿は、結局のところ受け手の不安を煽る以上の意味を持ちません。3.1の商材販売型は少なくとも「AIで解決しましょう」というセットまで示してくれており、3.2の解像度が低い方も投稿内容から「業務をあまり把握していないな」と気づきやすいので割り引いて聞けます。一方このタイプは、現場経験者の肩書きで語られるぶん知識不足とは見抜きにくく、しかも解決策の提示もない、という二重の難しさを抱えています。

こうした投稿に惑わされないためには、発信者が今も現場で実装や判断をしているのか、現場を離れてからどれくらい経つのか、そして発信内容に解決策まで含まれているのか、を意識して読むのが効果的です。特に、解決策の提示がなく、ただ特定の領域を落としにいくだけの内容については、慎重に距離を取って受け止める姿勢が大切です。

4. AI時代を生き残る変化

ここまでで「ITエンジニアは不要にならない」「しかし変化は確実に起こる」という話を整理してきました。では、その変化に対応してこれからの時代を生き残っていくために、ITエンジニアとしてどんな観点を意識すればよいのでしょうか。

ここでは、特に大切な3つの軸を取り上げます。

なお、これからITエンジニアを目指す方や、まだ経験の浅い方も、これから挙げる変化に対して焦る必要はありません。いずれもキャリアを積みながら少しずつ身につけていくもので、最初から全部揃えておくべきものではありません。むしろもっとも重要なのは、これからの環境変化を前提に、学び続ける姿勢 をベースに置いておくことです。AI時代に強いITエンジニアは、特定のスキルが永久に通用する人ではなく、変化を前提に学び続けられる人になっていきます。

4.1. 上流工程やビジネスサイドを重視する

最初の軸は、目の前のコードや実装の外側に意識を向け、上流工程やビジネスサイドを重視することです。

これまでのITエンジニアの世界では、「いかに美しく効率の良いコードを書くか」「いかに正確に設計書どおり実装するか」といった、いわゆる「詳細設計以降」の工程の腕前によって評価が高まるケースも多くありました。しかしここはまさに、AIが急速に得意としつつある領域です。ここを仕事の主軸にし続けると、AIと直接的に競合する位置に立ち続けることになります。

これからは、その手前にある「そもそも何を作るべきか」「どのような構成にすべきか」「それはビジネスとしてどんな意味を持つのか」を考え抜く力こそが、AI時代のITエンジニアの中心的な評価軸になっていきます。

ここでいう「上流工程」とは、開発フローのなかで時間軸的に上流にある工程だけを指すわけではなく、もう少し広く「何をどう作り、どう動かし続けるかを決めていく仕事」全般を指しています。たとえば、利用者や事業側へのヒアリングをもとにシステムを要件定義し、どんなアーキテクチャやデータモデル、API構成で実現するかまで決めていく、いわゆる工程上の上流工程の業務があります。あるいは、関係者の調整・進捗管理・課題管理を通じて、システムが正しく作られていく状態を作っていくプロジェクトマネジメント業務も、ここでいう上流工程に含まれます。さらに、性能・可用性・セキュリティといった、システムが安定して動作し続けるための非機能要件を設計し、運用に落とし込んでいく業務も同様です。

そしてこれらの「何を作るか」を考えるためには、技術側だけでなくビジネスサイドへの関心が欠かせません。技術力そのものは引き続き重要ですが、その技術が「なぜ事業の目的達成につながるのか」を説明できない状態だと、価値の半分しか発揮できません。同じ技術を使うにしても、「その技術を使うことで、ビジネスとしてどんな課題が解決されるのか」「投資対効果として正しい選択なのか」まで踏み込めるかどうかで、判断の質は大きく変わります。「言われたものを作る」だけのITエンジニアではなく、「事業目的を踏まえて、何をどう作るかまで一緒に考えられる」ITエンジニアが、AI時代に評価される存在になっていきます。

これらを身につけるうえで一番効くのは、実際に上流の業務やビジネス判断の場に関わる経験を積むことです。担当できる機会があれば、できる範囲から手を挙げて関わっていくのが理想です。

ただし、所属するプロジェクトや組織の事情で、すぐにそうした機会が巡ってくるとは限りません。その場合でも、周りの業務に意識を向けるだけで、感覚は確実に育っていきます。たとえば、自分が受け取った仕様に対して「なぜこの要件が必要なのか」「最終的にどんな利益やコスト削減、品質向上につながるのか」を毎回自分で言語化してみる、要件定義や設計レビューに見学や議事録係としてでも参加して上流担当者の思考プロセスを観察する、上流を担当している方やPMに判断の背景を聞いてみる、といった小さな積み重ねでも、長く続ければ確かな差になっていきます。

4.2. 仮説と検証を繰り返す

二つめの軸は、仮説を立てて、それを実際の結果で検証する、というサイクルを意識的に回し続けることです。

「この機能を入れれば、こんな効果が出るはず」「この施策で、こういう数字が動くはず」と仮説を立てて、リリース後に売上・利用率・障害件数・運用コストといった実際の数値で答え合わせをする。そして、その結果を踏まえて次の手を考える。この仮説 → 検証 → 次の打ち手、というサイクルを回せる速度と精度が、これからのITエンジニアの強さを大きく左右します。

仮説と検証の重要性自体は、AIが出てくる以前からビジネスやプロダクト開発の世界では基本中の基本で、特に新しい考え方ではありません。しかしAIによって実装やドラフト作成にかかる時間が大幅に短縮されたことで、これまで「時間がかかるから1案しか試せなかった」場面でも、複数案を素早く形にして実際の反応を見ることができるようになりました。つまり、仮説と検証のサイクルを回せる速度がAIによって一段引き上げられたぶん、もともと有効だったこの考え方が、これからはより一層大事になっていく、ということです。

この姿勢を身につけるうえでもっとも効果的なのは、業務のなかで意識的に「やる前の予測 → やった後の実数値」を比べる習慣を持つことです。たとえば、新しい機能をリリースする前に「これによって◯◯の数字が△△くらい伸びるはず」と自分で予測を書いておき、リリース後にその予測がどこまで合っていたかを振り返ってみる。最初は予測がまったく当たらないものですが、これを繰り返していくうちに、事業上どんな施策が効くのかの精度は着実に上がっていきます。

加えて、施策やリリースを「一発で当てる」のではなく「小さく出して反応を見て直す」前提で設計することにも慣れておくと、AI時代のスピード感とフィットしやすくなります。失敗を恐れずに小さな実験を積み重ねていくことが、結果としていちばん速く正解にたどり着く道になります。

4.3. AIを恐れるのではなく活用する

最後の軸は、AIそのものとの向き合い方です。AIに置き換えられるのを恐れて遠ざけるのではなく、自分がAIを活用する側に回ることが、生き残るための最重要のマインドになります。

AIで効率化できる部分は遠慮なくAIに任せ、人間にしかできない判断や責任の領域に時間を集中する。この使い方ができるかどうかで、これからのITエンジニアとしての生産性は大きく変わります。

そもそも現時点では、AI活用について業界全体として確立されたベストプラクティスはまだ整っていません。日々新しいモデルやツールが登場していて、「こう使えば正解」という形は誰も明確に定義できていない段階です。

そのため、まずは自分なりに効率の良いAIの使い方を模索しながら、それを毎日の業務にしっかりと取り入れていくことが、結果として一番の近道になります。コーディング、設計の壁打ち、技術調査、ドキュメント作成など、AIに任せられそうな場面はまず試してみて、自分の業務スタイルに合うやり方を作り上げていく、その実践の積み重ねがそのまま個人の強みになっていきます。

なお、組織として「AIを使わせない」「自力で書け」と強制することは、もはや単なる旧式のマネジメントではなく、新しい形のパワハラ と言ってもよい段階に入りつつあります。AIで効率化できる時代にあえてそれを禁止することは、本人の成長機会と組織の競争力を同時に奪う行為だからです。所属している組織で生き残るうえでは、そうした方針にひとまず従えば済む話ではあります。しかしその間にも、外でAIを使いこなしながら業務している方々との間には、数年単位で取り返しのつかない差が開いていきます。AI活用が当たり前になった数年後、後からその差を埋めるのは現実的にかなり難しくなります。

5. AI時代に生き残る専門領域

ここまではマインドの話を中心にしてきましたが、最後に、技術領域そのものとして「AIによって個別の作業は効率化されつつも、依然として人間の力が必要とされる」専門領域を紹介します。これからのキャリアの方向性として、こうした領域を意識的に経験していくことが、AI時代を生き残るうえで大きな強みになります。

なお、4章で取り上げた 要件定義・設計といった上流工程 は、ITエンジニア全員が共通して持つべきマインドの土台として扱っているため、ここでは個別の専門領域としては挙げません。その土台のうえに、さらに深めていく専門領域として、代表的な4つを紹介します。

また、これらの中には、これまで存在していた領域に加えて、AIの普及によって 新しく重要性が高まったり、新たに生まれてきた領域 も含まれています。AIは仕事を奪うだけではなく、ITエンジニアにとっての新しい職域・新しい役割も同時に生み出している、ということでもあります。

5.1. DevOps / SRE

DevOps / SRE は、開発と運用をつなぎ、システム全体を安定的に稼働させ続けるための技術領域です。CI/CD パイプラインの構築、IaC によるインフラ管理、監視・アラート設計、障害対応、キャパシティプランニングといった、システムを「動かし続ける」ための仕組みづくりが中心になります。

AIを活用すれば、Terraform や CloudFormation のコード生成、ログのパターン分析、運用スクリプトの作成といった個別の作業は格段に効率化できます。一方で、「どのようなパイプライン構成にすべきか」「障害発生時にどの方針で復旧させるか」「ビジネスへの影響をどう判断するか」「監視のしきい値をどこに置くか」といった判断は、引き続き人間が担う領域です。

システム全体を俯瞰し、ビジネスへの影響まで踏まえて意思決定できる視点は、AIが普及すればするほど価値が高まっていきます。AIによって生まれた余剰時間を、組織の競争力に変換していくうえでも欠かせない領域です。

5.2. セキュリティ

セキュリティは、設計・実装・運用のすべての工程に責任を伴う判断が求められる、極めて重要な技術領域です。クラウドにおける IAM 設計、暗号化や秘匿情報の管理、脆弱性の継続的なスキャン、監査ログの保管、インシデント対応など、扱う範囲はシステム全体に及びます。

脆弱性スキャンやセキュリティ設定のチェック、ログからの異常検知などは、AIによって精度・速度ともに大きく向上していきます。しかし、「どこまでのリスクを受容するか」「インシデント発生時にどう判断するか」「組織や顧客にどう説明するか」「規制要件をどう満たすか」といった判断は、依然として人間が引き受けるしかありません。社会的責任や法的責任とも直結する領域であり、自動化された後ほど、その上位の判断者としての価値が際立ちます。

AIによって表層的な検出作業が自動化されるからこそ、判断と責任を担えるセキュリティ領域の人材の価値は、これからますます高まっていきます。

5.3. データ分析

データ分析は、事業活動から得られるデータをもとに、現状を可視化し、判断や打ち手の意思決定につなげる技術領域です。データ基盤の整備、BI ツールの活用、分析モデルの構築など扱う範囲は広く、ビジネス側との接点も非常に多い領域になります。

SQL の生成、グラフの自動作成、統計的な分析など、データを「処理する」工程はAIによって急速に効率化されています。一方で、「そもそも何を分析すべきか」「分析結果から事業の意思決定にどうつなげるか」「データの解釈に潜むバイアスをどう扱うか」といった、データを 事業の判断に変換する 役割は、引き続き人間が担うことになります。

データから事業を動かせるITエンジニアの価値は、AIが進化すればするほど高まっていきます。「分析を実行する人」ではなく「分析を意思決定につなげられる人」が、これからのデータ分析領域で中心的な役割を担っていきます。データ分析は、4章で挙げた「ビジネスサイドを重視する」「仮説と検証を繰り返す」という2つの軸を、そのまま専門領域として形にした仕事だとも言えます。

5.4. AI開発

AI開発は、AIそのものを活用するシステムや、AIを組み込んだエージェントを設計・実装する技術領域です。Claude や OpenAI の API を使った AI アプリケーション、企業向け業務を支援する AI エージェント、MCP (Model Context Protocol) を使った外部ツール連携、社内業務やシステム運用を効率化するための AI ワークフローなど、AIを「使う」だけでなく「設計し、組み立てる」側のスキルが急速に重要になっています。

この領域は、AIそのものを使いこなす立場にあるため、皮肉なことに「AIに置き換えられる」可能性が最も低い領域のひとつです。AIモデルを呼び出すコード自体は AI でも書けますが、「どのモデルを選定するか」「どんなプロンプトやコンテキストを設計するか」「どこまでの判断を AI に委ねるか」「ハルシネーションをどう抑え込むか」「コスト・速度・品質のトレードオフをどう判断するか」といった設計・運用判断は、依然としてITエンジニア自身が担う必要があります。

AIで業務や開発を効率化する側に立つこと、そしてAIを組み込んだシステムやエージェントを設計・運用できることは、AI時代において最も需要が伸びる領域のひとつであり、これからのITエンジニアにとって大きな強みになります。

6. まとめ

AI不要論はSNSを中心に広がっていますが、その発信の多くは現場から距離のある立場の方によるものです。なかでも、自分の立場や選択を正当化するためにITエンジニアをネガティブに語っているような発信は、現場経験者の肩書きで信憑性が出てしまうぶん、慎重に距離を取って受け止める姿勢が大切です。実際の現場では、AIで置き換わるのはコーディングやテストといった「手を動かす部分」が中心で、ITエンジニア業務全体のごく一部にすぎません。要件定義や設計判断、運用判断といった「考える時間」の領域は、これからも人間が中心となって担っていくことになります。

そのうえでこれからのITエンジニアに求められるのは、上流工程やビジネスサイドを重視すること、仮説と検証を繰り返すこと、そしてAIを恐れるのではなく活用する側に回ること、という3つの軸ではないかと考えています。専門領域としては、DevOps / SRE・セキュリティ・データ分析・AI開発がAI時代でも伸び続けていく領域になっていくはずです。そして何より大切なのは、変化を前提に学び続ける姿勢をベースに置くことだと感じています。

「AIに奪われる」と身構えるのではなく、AIを味方につけてより良いものを作るという発想に切り替えることが、これからのITエンジニアにとっての出発点になります。組織を率いる立場の方は、AIを禁じるのではなく活用する文化を後押ししてください。AIを使いこなすITエンジニアこそが、これからの組織の競争力を支えていきます。