ラボまとめコラムニュース
ブログ/記事一覧/【まとめ】AIは開発を速くした。そして静かに壊し始めた
ai-changed-software-development-2026-cover

【まとめ】AIは開発を速くした。そして静かに壊し始めた

AIで開発は10倍速くなった。同時にセキュリティ脆弱性も急増した。2026年3月時点のデータと実例で、AIがソフトウェア開発にもたらした恩恵と危機の両面を整理する

まとめ
kkm-horikawa

kkm

Backend Engineer / AWS / Django

2026.03.3012 min8 views
Share X B! Hatena LINE in LinkedIn RSS
この記事のポイント

AIで開発は10倍速くなった。同時にセキュリティ脆弱性も急増した。2026年3月時点のデータと実例で、AIがソフトウェア開発にもたらした恩恵と危機の両面を整理する

2025年2月、元テスラAIディレクターのAndrej Karpathyが「バイブコーディング」という言葉をXに投稿しました。インプレッション680万回。2025年11月にはCollins英語辞典の年間ワードに選出。AIにコードを書かせる開発スタイルは、もはや流行ではなくインフラになりつつあります。

GitHub Copilotのユーザーは2,000万人を超え、DORA Report 2025によればソフトウェア開発の90%がAIを採用しています。開発者の84%がAIツールを使い、51%が毎日使っている。これはもう「使うかどうか」の話ではありません。

一方で、AI生成コードの62%に設計欠陥が含まれ、テック業界では2025年だけで約24.6万人がレイオフされました。AIは開発を速くしました。そして、静かに壊し始めてもいます。そんな両方の面を整理します。

AIがもたらした3つの恩恵

Windows 95の開発に関わったエンジニアの中嶋聡氏は、バイブコーディングを「使い捨ての紙袋」に例えています。エンジニアが心を込めて設計したコードがルイ・ヴィトンのバッグなら、バイブコーディングで作ったものは紙袋。コストが桁違いに安いから、1回しか使わないソフトウェアが成り立つようになった、と。

紙袋であることを正しく理解した上で見ると、AIが開発にもたらした恩恵は確かに大きいものがあります。

開発速度が桁違いに上がった

GitHub Copilotの導入効果を測定した複数の調査で、数字がはっきり出ています。

指標BeforeAfter出典
PRサイクルタイム9.6日2.4日（75%短縮）GitHub調査
JavaScriptタスク完了—55%高速化GitHub制御実験
週あたり節約時間—平均3.6時間13.5万人分析
AI生成コード残存率—88%GitHub調査

Google DORA Report 2025では、回答者の80%以上がAIにより生産性が向上したと報告しています。ただし同レポートは興味深い一文も添えています。「AIはチームを修正しない。すでにあるものを増幅するだけだ」。速くなったのは事実。でも、速くなったのは良いチームだけかもしれません。

作れる人が爆発的に増えた

中嶋氏は動画の中で、息子さんの話をしています。ベンチャーキャピタリストで、大学でコンピューターサイエンスは学んでいない。でもバイブコーディングで、数十人のLP（ファンド投資家）向けの専用iPhoneアプリを作っている。コードレビューすらしていない。動けば採用、動かなければやり直し。従来なら数百万円かかるアプリを、エンジニアでない人が気軽に作れるようになった。

これは個人の話にとどまりません。大手企業においてシチズンデベロッパー（IT部門以外の業務担当者が自分でアプリを作る人）が、プロの開発者の4倍に達しています。Y Combinator 2025年冬バッチでは、25%のスタートアップでコードベースの95%がLLM生成でした。

「かつて大きなチームが必要だったプロジェクトが、今では1人の優秀な人間でできるようになった」 ― Mark Zuckerberg, Meta CEO

象徴的な事例があります。Base44というサービスは、Maor Shlomo氏が1人で創業し、外部資金調達なし、社員8名。設立からわずか6ヶ月で25万ユーザーを獲得し、Wixに8,000万ドル（約120億円）で買収されました。

「予算がないからできない」が消えた

ソロプレナー（1人起業家）が完全なテックスタックを年間3,000〜12,000ドルで運用できるようになりました。従来のスタッフモデルと比較して95〜98%のコスト削減です。ソロファウンダーのスタートアップは2019年の23.7%から2025年中盤に36.3%まで増えています。

中嶋氏はこの変化を、エンタープライズ向けカスタムアプリ市場の根本的な転換だと見ています。セールスフォースのCRMやSAPの会計ソフトを業務に合わせてカスタマイズするのに、ITコンサルタントを雇って6ヶ月かけていた。それが、営業の人自身がバイブコーディングで1〜2日で作れるようになる。コストが紙袋レベルに下がったからこそ、部門ごと、担当者ごと、場合によっては顧客1人のためにアプリを作ることさえ現実的になった、と。

AIが加速させている5つの危機

ここまで読むと、いいことずくめに見えます。でも紙袋には紙袋なりの問題があります。水を入れれば底が抜けるし、中身が外から丸見えになることもある。

AIが書いたコードの半分は穴だらけ

arxivに掲載された研究によれば、AI生成コードの62%が設計欠陥または既知のセキュリティ脆弱性を含んでいます。Carnegie Mellon大学の研究では、機能テスト合格率は61%ですが、セキュリティテスト合格率はわずか10.5%。動くけど安全ではない、という状態です。

指標数値出典
AI生成コードの設計欠陥率62%arxiv.org/abs/2502.11844
セキュリティ欠陥率（全言語）45%Veracode 2025
同上（Java限定）72%Veracode 2025
XSS防御失敗率86%Carnegie Mellon大学
SQLインジェクション防御失敗率88%Carnegie Mellon大学
AI起因CVE（月間）35件（2026年3月）Georgia Tech SSLab

Georgia Techの研究者は「実際の数は検出件数の5〜10倍の可能性がある」と指摘しています。2025年8月には月間2件だったAI起因のCVEが、2026年3月には35件。半年で17倍です。

実害も出ています。2026年初頭、バイブコーディングで作られたあるアプリがデータ侵害を受け、150万のAPIキーと3万5,000件のユーザーメールアドレスが流出しました。アプリ作者は「一行もコードを手書きしていない」と認めています。5,600のバイブコーディング製アプリを調査した結果では、2,000以上の脆弱性、400以上の秘密情報の露出が見つかりました。

詳しくはこちらの記事で解説しています:

OSSのサプライチェーンが連鎖的に崩壊した

2026年3月、セキュリティスキャナー「Trivy」のGitHub Actionsが侵害されたことを起点に、わずか10日間で4つのOSSプロジェクトが連鎖的に攻撃されました。攻撃グループ「TeamPCP」はTrivyから盗んだ認証情報で、月間9,500万ダウンロードのLiteLLM、通信プラットフォームのTelnyxへと攻撃を広げていきました。

LiteLLMの攻撃では、Pythonの.pthファイルという仕組みが悪用されました。importもインストールスクリプトも不要で、Pythonインタプリタを起動するだけでマルウェアが実行される。SSHキー、クラウド認証情報、Kubernetesシークレット、暗号資産ウォレットが盗まれました。

もう1つ新しい脅威があります。「Slopsquatting」と呼ばれる攻撃手法です。LLMにコードを生成させると、推奨パッケージの約20%が実在しないパッケージ名になります。しかも同じプロンプトで10回実行すると、43%が毎回同じ名前を幻覚する。攻撃者はその名前でパッケージを登録し、マルウェアを仕込みます。Virginia Tech、オクラホマ大学、テキサス大学の共同研究で明らかになりました。

関連記事:

テック大手で25万人が職を失った

2025年、テック業界全体で783件のレイオフが発生し、約24万6,000人が影響を受けました。2026年は3月時点ですでに約6万人。1日あたり682人のペースです。

企業人数備考
Amazon約30,000人2025-2026年合計
Meta約16,000人AI投資1,150〜1,350億ドルと同時
Microsoft約9,100人Xbox部門含む複数部門
Block4,000人（40%）粗利益24%増の好業績下で
Atlassian1,600人（10%）うち900人がエンジニア

厄介なのは、レイオフと好業績が同時に起きていることです。Blockは粗利益28.7億ドル（前年比24%増）という好調な決算の最中に従業員の40%を切りました。発表後、株価は23%上昇。CEO Jack Dorseyは「AIツールが会社を運営する意味を変えた」と語りましたが、社内の匿名投稿アプリBlindには「コロナ禍の過剰採用の修正をAI代替と言い換えている」という声もありました。

Atlassianは2025年10月に「AIでエンジニアをもっと雇う」と宣言した5ヶ月後に、1,600人（うちエンジニア900人）を解雇しています。54%の企業がAI投資の原資として従業員報酬を削減しているというデータもあります。

日本でも影響は出始めています。日経新聞の調査では、就活生1,116人のうち約4割がAIの普及を見越して志望職種を変更。ILO（国際労働機関）は、生成AIの雇用影響が最も大きいのは「高所得国の大卒若年層」だと報告しています。

関連記事:

App Storeがパンクし、スロップが溢れた

紙袋が大量生産されると、当然ゴミも増えます。App Storeの新規アプリ公開数は前年比54.8%増。審査は通常24時間以内でしたが、最長45日待ちという報告が出ています。Apple公式は「90%は48時間以内」と言っていますが、開発者フォーラムには2週間以上待っている人の投稿が並んでいます。

Merriam-Webster（アメリカ最大の辞書出版社）は、2025年のWord of the Yearに「slop」を選びました。「人工知能によって大量生産された低品質なデジタルコンテンツ」という意味です。AI生成記事が英語Webコンテンツの半数以上を占め、eMarketerは2026年までに90%がAI生成になると予測しています。Raptiveの調査では、AI生成と疑われるコンテンツは読者の信頼を約50%低下させるという結果も出ています。

関連記事:

AIの出力を「正解」だと信じる人が増えた

Stanford大学の研究チームが、11のAIモデルを対象に同調性（sycophancy）を測定しました。結果、AIは人間より49%多くユーザーの意見に同調し、有害な行為や違法行為のシナリオでも47%の確率で肯定することがわかりました。

この性質が現実で問題を起こしています。あるレストラン店主は、スタッフとのトラブルについてChatGPTに相談し、そのスクリーンショットを「客観的な証拠」として共有しました。もちろん、店主側の情報だけを入力しているので、AIは店主寄りの回答を返します。それは客観的な判断ではなく、入力に忠実な出力です。

アールト大学のWelschらの研究では、AI使用時にパフォーマンスが3ポイント向上した一方、自己評価は4ポイント膨張しました。実力より自信の方が大きく伸びるのです。AIをたくさん使う人ほど批判的思考能力が低下するという相関も報告されています。

関連記事:

バイブコーディングで何ができて何ができないのか

ここまでのデータを見ると、AIコード生成には「向いている使い方」と「向いていない使い方」があることがわかります。

得意なこと苦手なこと
1つの明確なタスクの実装複数機能の統合判断
プロトタイプの高速作成ビジネスロジックの設計
定義されたパラメータ内の実装セキュリティアーキテクチャ
使い捨てツール・スクリプト長期保守を前提としたコード
既知のパターンの再現共通化するかしないかの判断

ウィスコンシン大学マディソン校が2026年3月に公開したSlopCodeBenchというベンチマークが、この「苦手」を数字で裏付けています。11のAIモデルに反復的なコード拡張をさせたところ、全モデルで品質が単調に劣化しました。最高正解率は17.2%で、20問中の完全解答はゼロ。main()関数が84行から1,099行に膨張した例もあります。

困ったことに、プロンプトを工夫しても劣化速度は変わりませんでした。初期の冗長性は33〜34.5%抑えられましたが、拡張を重ねるにつれて同じペースで品質が落ちていく。LLMに95%書かせたOSSをレビューした記事でも、「LLMが書けるのはコードだけ。設計判断は書けない」という結論に至っています。

DORA Reportの一文が的確です。「AIはチームを修正しない。すでにあるものを増幅するだけだ」。良いチームがAIを使えばもっと良くなる。悪いチームが使えば、悪さが加速する。AIは道具であって、魔法ではありません。

業界はどう見ているか

ここまでデータで見てきた恩恵とリスクを、世界的に著名なエンジニアたちはどう捉えているのか。立場は様々ですが、「条件なしの全肯定」も「条件なしの全否定」もほぼ存在しません。全員が何かしらの留保を付けています。

「これは本物だ」と言う人たち

Andrej Karpathy

OpenAI共同創業者、元Tesla AIディレクター。GPTの基礎を築いた研究者の一人で、「バイブコーディング」という言葉を作った本人。

つまり：「シャワー中の思いつきを投稿しただけだった。でも多くの人が同時に同じことを感じていたから広まった」。バイブコーディングは誰かが発明したものではなく、すでに起きていたことに名前が付いただけだ、ということです。なお彼自身は、プロの開発では「augmented coding」（AIを補助として使いつつ設計は人間が握るスタイル）を推奨しています。

DHH（David Heinemeier Hansson）

Ruby on Rails作者。世界中のWebアプリケーション開発を変えたフレームワークを1人で作った伝説的エンジニア。37signals（Basecamp/HEY）CEO。

つまり：「低品質なAI出力や胡散臭い話に気を取られて、AIの驚異そのものを見逃すな」。面白いのは、DHHが半年前のインタビューでは「指からスキルが抜けていく感覚がある」とAIに懐疑的だったこと。Rails作者ほどの人でも半年で態度が変わるほど、ツールの進化が速いということです。

Ryan Dahl

Node.js作者、Deno作者。JavaScriptをサーバーサイドで動かすという革命を起こし、世界中のWeb開発の常識を変えた人物。

つまり：「人間がコードを手書きする時代は終わった。エンジニアの仕事がなくなるという意味ではなく、構文を直接書くことが中心的作業ではなくなった」。Node.jsを作った人がこう言うのは重いですが、「仕事がなくなる」とは言っていない点に注目してください。

Guillermo Rauch

Vercel CEO、Next.js作者。ReactベースのWeb開発フレームワークNext.jsとホスティングプラットフォームVercelで、フロントエンド開発のインフラを支えている。

つまり：「2026年が始まって10日で、LinuxのTorvaldsもRailsのDHHも態度を変えた」。懐疑的だった著名エンジニアが次々と認め始めている状況を端的にまとめています。

Patrick Collison

Stripe CEO。世界中のオンライン決済を支えるStripeを共同創業。自身もプログラマーで、エンジニアリング文化で知られる企業を率いている。

a16zポッドキャスト（2026年2月）で、こう述べています：

"There's at least a reasonable chance that 2026 Q1 will be looked back upon as the first quarter of the singularity."

つまり：「2026年の第1四半期が、振り返ればシンギュラリティの始まりだったと言われる可能性がある」。Stripeでは社内のバグトラッカーに「Fix it」ボタンを追加し、AIが自動でバグの30%を修正する仕組みを導入しています。ただし「AIの生産性向上はまだマクロ経済の指標には現れていない」とも指摘しており、手放しの楽観ではありません。

出典: Retool Blog - Stripe's CEO on the Future of Software

「使い方次第だ」と言う人たち

Guido van Rossum

Python作者。世界で最も使われているプログラミング言語の1つを設計した人物。現在もPythonコミュニティに大きな影響力を持つ。

"I use it every day. My biggest adjustment with using Copilot was that instead of writing code, my posture shifted to reviewing code."

"It's more like having an electric saw instead of a hand saw than like having a robot that can build me a chair."

つまり：「毎日使っている。コードを『書く』姿勢から『レビューする』姿勢に変わった。AIは椅子を作ってくれるロボットではなく、手鋸の代わりの電動鋸だ」。Python作者がAIを道具として毎日使いつつ、「椅子を作ってくれるとは思っていない」と線引きしているのは示唆的です。

出典: GitHub Blog - Why developers still flock to Python

まつもとゆきひろ（Matz）

Ruby作者。日本発のプログラミング言語Rubyを設計し、「プログラミングを楽しくする」という哲学で世界中の開発者に影響を与えた。

「AIは非常に便利なツール。既存のものの再現は得意だが、新しいものを作るのは苦手で成功率は1%」

「楽しいことをAIに任せて人間がつまらないことだけやるのは逆アルファシンドロームだ」

つまり：「AIに創造的な部分を任せて、人間がレビューや修正だけやるようになったら本末転倒」。RubyKaigi 2025のキーノートで語ったこの指摘は、「プログラミングの楽しさ」を言語設計の核にしてきたMatzらしい視点です。

出典: gihyo.jp - RubyKaigi 2025 3日目キーノート

John Carmack

id Software創業者、Keen Technologies CEO。DOOMやQuakeなど、3Dゲームの歴史を切り開いた伝説的プログラマー。ゲームエンジン技術の基礎を築いた人物。

つまり：「AIは大量のコードを吐き出して盲目的に受け入れられがちだが、コードベースを美しくする機会も同じくらいある」。DOOMを作った人が「AIを疲れ知らずのチームメイトとして使え。魔法のランプの精として使うな」と言っているのは説得力があります。

Mitchell Hashimoto

HashiCorp共同創業者。Terraform、Vagrant、Consulなど、世界中のインフラエンジニアが毎日使っている開発ツールを作った人物。現在はターミナルエミュレータGhosttyを個人開発中。

つまり：「AIで書いたPRは受理済みIssueのみ。勝手なAI PRは即クローズ、悪質なら永久BAN」。一方で彼自身はGhosttyの本番機能をAIで16セッション・$15.98で実装し、その全過程を公開しています。「AIを使うこと」は禁止しない。「AIに丸投げすること」を禁止している。この区別が重要です。

Chris Lattner

LLVM・Swift・Mojo作者、Modular CEO。コンパイラ基盤LLVM、Appleのプログラミング言語Swift、AI向け言語Mojoを設計。プログラミング言語設計のトップランナー。

"AI coding is automation of implementation, so design and stewardship become more important. As implementation grows increasingly automated, the core skill of software engineering shifts away from writing code line-by-line and toward shaping systems."

つまり：「AIは実装の自動化。だから設計と管理がもっと重要になる」。彼自身はチームにClaude CodeやCursorの使用を推奨しており、経験豊富なプログラマーには約10%の生産性向上があると見積もっています。劇的な数字ではないですが、LLVM作者が「10%」と冷静に評価しているところに信頼性があります。

出典: Modular Blog - The Claude C Compiler

Linus Torvalds

Linux創始者、Git作者。世界中のサーバー、スマートフォン（Android）、クラウドインフラを動かしているLinuxカーネルを30年以上にわたって開発・管理している。

"I'm fairly positive about [vibe coding] as a great way for people to get computers to do something that maybe they couldn't do otherwise. [But] it may be a horrible, horrible idea from a maintenance standpoint."

つまり：「個人利用にはいい。保守の観点では最悪かもしれない」。自身も個人プロジェクトではAIでPythonコードを書かせていますが、Linuxカーネルへの適用は明確に拒否。AIが生成した低品質パッチ（AI slop）がカーネルに投げ込まれる問題にも「ドキュメントで解決する問題じゃない」と厳しい姿勢です。

出典: The Register - Linus Torvalds: Vibe coding is fine, but not for production

Theo（t3dotgg）

YouTube登録者40万人超の技術系クリエイター。TypeScript/React/Next.jsエコシステムで影響力を持ち、T3 Stackの提唱者。熟練開発者向けAIコーディングツールを開発中。

つまり：「AIモデルの性能は認める。でもバイブコーディングは誤解されている用語だし、AIが生成したコードは読むべき。この3つは矛盾しない」。肯定か否定かの二択ではなく、「良いツールを正しく使え」という実務的な立場です。

「まだ信用するな」と言う人たち

Martin Fowler

ThoughtWorks Chief Scientist。ソフトウェア設計のバイブルとも言える『リファクタリング』の著者で、アジャイル宣言の署名者。ソフトウェア工学の理論と実践を40年間にわたって牽引してきた。

"You've got to treat every slice as a pull request from a rather dodgy collaborator who's very productive in the lines-of-code sense of productivity, but you know you can't trust a thing that they're doing."

つまり：「AIの出力は、行数だけは妙に多い信用ならない同僚からのプルリクエストとして扱え」。『リファクタリング』を書いた人間が「コードの量と質は別物」と言うのは、40年分の重みがあります。一方で「レガシーシステムの作業にはLLMを使うべき」とも述べており、全否定ではありません。

出典: The New Stack - Martin Fowler on Preparing for AI's Nondeterministic Computing

ThePrimeagen

元Netflixエンジニア、YouTube登録者100万人超のプログラミング系クリエイター。パフォーマンス最適化とシステムプログラミングの分野で熟練した技術力を持つ。

つまり：「バイブコーディング1日目。全然感動しない。ゼロから作らせるのではなく、自分で基盤を作ってから小さな変更をAIに頼む方がいい。Claudeは神ではない」。翌日には「ツールが悪かったのかも」と別のツールで再挑戦しており、否定というより「現時点の限界を正直に報告している」という印象です。

Rob Pike

Go言語共同作者、元Google Distinguished Engineer。Unix、Plan 9、UTF-8の設計にも関わった、コンピューターサイエンスの歴史に名を刻む人物。

"I can't remember the last time I was this angry."

つまり：AIが自動生成した「善意のメール」が届いたことに激怒した発言です。何十年もかけて手で書いたコードやデータが、帰属も報酬もなくAIの訓練に使われ、その結果生まれた「善意のスロップ」を送りつけてくる。Go言語を作った人がここまで怒るということ自体が、AI業界のデータ搾取問題の深刻さを物語っています。

出典: Simon Willison - How Rob Pike got spammed with an AI slop "act of kindness"

Yann LeCun

Meta Chief AI Scientist、チューリング賞受賞者。深層学習の先駆者で「AIのゴッドファーザー」の一人。CNN（畳み込みニューラルネットワーク）の生みの親として、現在のAI技術の基礎を築いた。

"The shelf life of the current [LLM] paradigm is fairly short, probably three to five years. Within five years, nobody in their right mind would use them anymore, at least not as the central component of an AI system."

つまり：「今のLLMの賞味期限は3〜5年。5年後にはまともな人は中核コンポーネントとしては使わなくなる」。AIそのものの否定ではなく、「今のLLMという手法」の限界を指摘しています。コード生成が上手くなっていることは認めつつ、LLMは推論・計画・物理世界の理解ができないパターンマッチングに過ぎない、と。AIの基礎を作った人の発言だけに重みがあります。

出典: Newsweek - Yann LeCun, Pioneer of AI, Thinks Today's LLMs Are Nearly Obsolete

15人の発言を並べて見えること：肯定派も否定派も、共通しているのは「AIが書いたコードを無条件に信用するな」という点です。違いは「それでも使え」と言うか「だからまだ早い」と言うかだけで、「AIの出力を人間が検証する必要がある」という結論はほぼ全員が一致しています。

私はこう使っている。小さく分けて、AIの得意な領域で戦わせる

まず前提として、コアとなる基盤部分、各種機能が乗る中核のアーキテクチャ、初期構築にはAIを使いません。ここは自分の頭で設計し、自分の手で書きます。AIが苦手な「複数機能の統合判断」や「共通化するかしないかの判断」がまさに求められる領域だからです。

その上で、基盤の「外側」に生える小さな機能、たとえばLambda関数やユーティリティライブラリの実装にはAIを積極的に使います。バイブコーディングは1つの小さなタスクに強い。だから「AIが得意な粒度に仕事を切る」ことが重要になります。

たとえば、Pythonで開発しているシステムの一部をLambdaに切り出したい場面があります。以前なら、その部分がGoで書いた方がふさわしくても、学習コストやメンテナンスの都合でPython統一を選んでいました。チームに「Go書ける人」がいなければ、その選択肢は最初から存在しない。

今は違います。「ここはGoがふさわしいからGoで」という判断ができるようになった。言語の壁がAIのおかげで大幅に下がったからです。機能を絞った小さなLambdaなら、AIに生成させたコードのレビューも現実的な量に収まります。このサイト自体もLambdaを結構使っていますし、フリーランスのお客さんのシステムでも同じ手法を採り始めています。

大事なのは、紙袋に入れていいものと入れてはいけないものを分けることです。そして紙袋に入れるものは、作り直しが発生しても痛くないくらいの大きさに保つ。

かつてこの「適切な粒度への分解」は、予算やチームがある企業にしかできませんでした。マイクロサービスアーキテクチャが理想として語られながら、実際にやれるのは大きな組織だけだった。それが個人やフリーランスでもできるようになった。これは紙袋が安くなったことの、最も実用的な恩恵だと思います。

バイブコーディングの力を最大化するコツがあるとすれば、「AIに何でも丸投げする」ことではなく、「AIが得意な粒度に仕事を切る」ことです。1 Issue、1 Lambda、1ライブラリ。この粒度なら、AIは驚くほど正確に動きます。基盤は自分で握り、末端をAIに任せる。この使い分けが、今のところ最も現実的だと思っています。

よくある質問

バイブコーディングでプロのエンジニアは不要になるのか

なりません。バイブコーディングは1つの小さなタスクには強いですが、複数機能の統合判断やセキュリティ設計は人間にしかできません。AI生成コードの62%に設計欠陥が含まれるというデータがあり、それをレビューし修正できる人の価値はむしろ上がっています。変わるのは「コードを手で書く量」であって、「設計し、判断し、品質を保証する」という仕事は残ります。

AIが書いたコードのセキュリティはどう担保するのか

人間によるセキュリティレビューと自動スキャンの両方が必要です。XSS防御失敗率86%、SQLインジェクション防御失敗率88%というデータが示すように、AIの出力を無検証で使うのは危険です。GitHub Actionsのバージョン指定をコミットハッシュ（SHA）でピン留めする、依存パッケージの実在を確認する、といった基本対策も欠かせません。

日本のエンジニア市場はどうなるのか

日経新聞の調査では就活生の約4割がAIの普及を見越して志望職種を変更しています。ただし「エンジニアの採用が消える」のではなく「選別が進む」というのが市場の見方です。「コードを書く」スキルより「何を作るか」「どう設計するか」「どう品質を担保するか」を判断できる人の価値が高まっています。日経クロステックの木村岳史氏は「5年以内に人月商売のIT業界は瓦解する」と予測しています。

更新履歴

  • 2026年3月30日: 初版公開