サブスクリプションの料金は、AI コーディングツールのコストの中でいちばん安い部分です。月 20 ドルでも 100 ドルでも 200 ドルでも、大きなコストは請求書には載りません。それは後になって現れます。レビューを通ったのに本番環境で壊れるコード、ユーザーのデータを漏らすアプリ、誰もレビューしきれないほどの量のコード、アクセス権を持ちすぎたエージェントによる本番データベースの削除、そして燃え尽きていくエンジニアです。
私は大手テック企業でソフトウェアエンジニアとして働いていて、これらのツールを毎日使っています。AI 嫌いではありません。それでも、この記事で取り上げる問題の多くに自分自身も直面してきました。そして 2026 年になって、ようやくそれを数字で示せるだけのデータがそろいました。
要約
- AI のコードは、本番環境での振る舞いよりもレビューでの見た目のほうが良く見えます。New Relic が 2026 年 6 月に米国の技術リーダー 200 人を対象に行った調査では、94% がレビューの段階で AI のコードを人間が書いたコードより高品質だと評価しました。一方で 82% が、直近 6 か月の間に AI のコードが原因で起きた本番障害を挙げることができました（New Relic、2026 年）。
- 広い認証情報を持ったエージェントは、あっという間に物を壊します。Claude を動かしていた Cursor のエージェントは、PocketOS の本番データベースを約 9 秒で削除しました。また Claude が実行した
terraform destroyによって、DataTalks.Club の 2.5 年分のコースデータが消えました。どちらのケースでも、指示では止められなかったエージェントを、スコープを絞った権限なら止められていたはずです。 - レビューが新たなボトルネックになっています。約 22,000 人の開発者の間で AI の導入が進むにつれて、PR レビューにかかる時間の中央値は 441% 増え、開発者 1 人あたりのバグは 54% 増えました（Faros AI、2026 年）。
- セキュリティホールは増えています。Georgia Tech の研究者は、2026 年 3 月だけで 35 件の CVE を AI が書いたコードと結びつけました。2025 年 5 月から 12 月までは約 18 件でした（Georgia Tech、2026 年）。
- 人もその代償を払います。AI を使って学んだジュニアの理解度クイズの得点は 50% で、手でコードを書いたジュニアは 67% でした（Anthropic、2026 年）。また開発者 442 人を対象にした調査では、AI の導入が仕事上の要求を高めることで燃え尽きを増やしていることがわかりました（Feng et al.、2026 年）。
AI のコードはなぜレビューを通り、本番環境で壊れるのでしょうか？
AI のコードがレビューを通るのは、見た目がきれいだからです。本番環境で壊れるのは、それを書いたエージェントが、実際のトラフィックのもとでシステムがどう振る舞うのか、既存のコードがなぜそう書かれているのかを知らないからです。
2026 年 6 月、New Relic は米国の技術リーダー 200 人を対象にした State of AI Coding 調査を発表しました（New Relic、2026 年）。レビューの段階では、94% が AI の生成したコードを人間が書いたコードより高品質だと評価し、33% ははるかに高品質だと答えました。ところがそのコードが出荷されると、回答は逆転しました。
- 過去 12 か月で本番インシデントが増えたという回答は 78%
- シニアエンジニアがコードの修正に費やす時間が増えたという回答は 86%
- AI が生成したコードの少なくとも 4 分の 1 に大幅な手直しが必要だったという回答は 74%
- 直近 6 か月の間に AI のコードが原因の本番障害を挙げられたのは 82%
レビューではコードのほうが優れているなら、なぜ壊れ続けるのでしょうか。自分の仕事を振り返ると、理由は 4 つあると考えています。
エージェントはシステムを知りません。サービスがどれだけのトラフィックを処理しているのか、どの日が特に忙しいのか、下流のどの依存先が最初に倒れるのか、エージェントには見えません。どれも diff には含まれていないからです。
コードがなぜそう書かれているのかを知りません。成熟したコードベースには、どれも奇妙な条件分岐があります。たとえば決済フローに変わったチェックがあるのは、以前の開発者が決済プロバイダーのバグに遭遇して回避策を入れたからかもしれません。人間がそのコードを読めば、書いた本人に聞くはずです。エージェントは聞きません。当て推量で先に進み、その推量はよく外れます。
大きな diff を前にすると、レビュアーは見えなくなります。エージェントが一度に何百行ものコードを出してくると、レビュアーは圧倒されます。しばらくすると丁寧に読まなくなり、問題なさそうに見えるという理由でコードが承認されます。そのコードで何年も働いてきたエンジニアなら考えるまでもなく処理するエッジケースこそ、誰も確認しないのです。
エージェント負債が積み上がります。これは出荷されたまま片付けられない、雑な AI のコードのことです。ほかの技術的負債と同じように膨らみ続け、やがて本番インシデントになります。
AI ツールそのものの性能が落ちると何が起きるのでしょうか？
チームの生産性が落ちます。しかも、それに気づくのは難しいのです。2026 年 3 月から 4 月にかけて、開発者たちは何週間も Claude Code の質が落ちたと不満を訴えていました。AMD の AI グループのディレクターである Stella Laurenzo は 6,852 件の Claude Code セッションを分析し、エージェントが編集の前に読むコードの量が大きく減っていることを突き止めました。編集 1 回あたりのファイル読み込みは 6.6 回から 2.0 回に減っていました（GitHub issue #42796、2026 年）。
Anthropic のポストモーテムは、この低下の原因を自社が出荷した 3 つの変更にあるとしました。その 1 つは、ターンごとにモデルの思考を消してしまうキャッシュのバグです。このバグは「複数の人間および自動のコードレビューに加えて、ユニットテスト、エンドツーエンドテスト、自動検証、ドッグフーディングもすり抜けた」といいます（Anthropic、2026 年）。
これらのツールに頼るエンジニアを何百人も抱える会社にとって、これが何を意味するか考えてみてください。何週間ものあいだ、エンジニアリング組織全体が落ちた生産性のまま動き、それにほとんど誰も気づきません。エージェントの出来が悪くても、「AI だから、たまにはそういうこともある」と肩をすくめて済ませてしまうからです。
Anthropic はどれも意図したものではなかったと説明しており、私もそれを信じています。それでも不安は残りました。チームが Anthropic や OpenAI、あるいはほかの会社のモデルに依存しているなら、そのモデルが今日どれだけ優秀かを決めるのはベンダーです。もしプロバイダーが品質を下げると決めたら、いちばん打撃を受けるのはそのツールにいちばん依存している開発者です。そして今や、ほんの一握りの企業が、世界で新しく書かれるコードの大部分の品質を左右しています。
AI エージェントは本番データベースを削除できるのでしょうか？
できます。過去 1 年間に公に報告されただけでも少なくとも 3 件起きており、どのケースでもエージェントはタスクに必要な範囲をはるかに超えるアクセス権を持っていました。
PocketOS：9 秒で消えた本番環境
2026 年 4 月、Anthropic の Claude Opus 4.6 を動かしていた Cursor の AI エージェントが、PocketOS のステージング環境でタスクに取り組んでいる最中に認証情報の問題にぶつかりました。エージェントは認証情報を探しに行き、無関係なファイルの中から Railway の API トークンを見つけました。このトークンはカスタムドメインの管理用に作られたものでしたが、スコープの制限がありませんでした。持っている人なら、どの環境でも何でもできる状態でした。
エージェントはこのトークンを使い、削除はステージングにしか影響しないと思い込んだまま、Railway の API 経由でストレージボリュームを削除しました。そのボリュームには本番データベースが入っていました。バックアップも同じボリュームにあったので一緒に消え、ほかの場所に保存されていた最新のコピーは約 3 か月前のものでした。ここまでにかかった時間は約 9 秒です（The Register、2026 年）。
エージェントのルールには、決して推測しないこと、頼まれない限り破壊的なコマンドは実行しないことが書かれていました。創業者の Jer Crane がなぜそれでも実行したのかと尋ねると、エージェントはこう答えました。「API 経由でステージングのボリュームを削除しても、影響はステージングだけに限られると推測しました。確認はしませんでした。」Railway はその後、自社のバックアップからデータを復元しました（The Register、2026 年）。
この事故は、エージェントに手を加えなくても防げました。本番環境とステージング環境はインフラを共有すべきではなく、環境ごとに別のトークンを持つべきで、エージェントが必要のないトークンにアクセスできる状態にしてはいけませんでした。それでも私はエージェントにも責任があると考えています。与えられた指示を無視したからです。ただ、エージェント向けに書いたルールはお願いにすぎず、今回はそれが無視されました。
DataTalks.Club：2.5 年分のデータと 1 回の terraform destroy
Alexey Grigorev は、無料のデータエンジニアリングのコースを提供するプラットフォーム DataTalks.Club を運営していて、そのインフラを Terraform で管理しています（Alexey Grigorev、2026 年）。Terraform は 2 つのファイルを使います。設定ファイルには、サーバー、データベース、ネットワークなど、作りたいものを記述します。state ファイルには、Terraform が実際に構築したものが記録されます。Terraform はこの 2 つを比較し、state ファイルに載っていないものをすべて構築します。
彼の state ファイルは、共有のリモートストレージではなく自分のノートパソコンに置かれていました。ノートパソコンを替えたとき、設定ファイルは一緒に移りましたが、state は移りませんでした。Terraform はまだ何も構築されていないと判断し、すべてをもう一度構築し始めました。彼は途中で止めましたが、本物のリソースの横で重複したリソースがいくつか動いたまま残りました。
そして重複を片付けていた Claude が、以前のノートパソコンにあった古い Terraform のアーカイブを展開しました。彼自身の言葉では、「Claude が私の Terraform アーカイブを展開していることに気づきませんでした。Claude は現在の state ファイルを、DataTalks.Club のコース管理プラットフォームに関する情報がすべて入った古いものに置き換えていたのです。」その古い state には、本番プラットフォーム全体が記述されていました。Claude が terraform destroy を実行すると、Terraform はデータベース、ネットワーク、サーバー、そして自動スナップショットを削除しました。それらも Terraform が作成したものだったからです。データベースには 2.5 年分のコースの提出物が入っており、1 つのテーブルだけで約 190 万行ありました。
彼は深夜に料金を払って AWS のサポートプランをアップグレードし、AWS の担当者と電話で話せるようにしました。AWS 側には、彼が自分のコンソールからは見られないスナップショットがあり、プラットフォームは削除から 24 時間後に復元されました。
本番環境に対して terraform destroy を実行する前には、普通なら人間が plan を確認します。Claude は、plan が何を削除するのかを疑うことなくそれを実行しました。
Amazon Kiro：13 時間止まった AWS Cost Explorer
これは小さな会社だけに起きることではありません。2025 年 12 月、Amazon のエンジニアは、Amazon 自身の AI コーディングエージェントである Kiro に、AWS Cost Explorer の問題を修正させました。AWS Cost Explorer は、顧客が AWS の利用料金を追跡するためのツールです。Kiro は、環境を削除して作り直すのが最善の修正だと判断しました。Financial Times の報道を The Decoder がまとめたところによると、Cost Explorer は中国本土の 1 つのリージョンで約 13 時間停止しました（2026 年）。
本来なら 2 つの安全策がこれを止めるはずでした。Kiro はデフォルトでは実行前に確認を求めますし、本番環境への変更には 2 人目の承認が必要です。ところが Kiro を動かしていたエンジニアは想定より広い権限を持っていて、Kiro はそれを引き継ぎました。そして 2 人目の承認は求められませんでした。Amazon は FT に対し、AI ツールが関わっていたのは偶然だと説明しました。公式の回答では、このインシデントを「ユーザーのミス、具体的にはアクセス制御の設定ミス」としています（Amazon、2026 年）。いずれにせよ、エージェントはタスクに必要な範囲を超えるアクセス権を引き継いでいました。
これらのインシデントは何で防げたのでしょうか？
3 件とも、ごく普通のインフラのルールで防げたはずです。
- 環境ごとに認証情報を分け、ステージングのタスクからはステージングにしか届かないようにします。
- エージェントには仕事をこなせる最も狭いトークンを渡し、エンジニアのフルアクセスは決して渡さないようにします。
- 本番環境とステージング環境はインフラを分けます。特にストレージは分け、バックアップをデータと同じボリュームに置かないようにします。
- Terraform の state はロック付きのリモートストレージに置きます。ノートパソコンに置いた state ファイルは、そのノートパソコンを 1 台なくすだけで再構築や destroy につながります。
- 本番環境に対する削除、
destroy、force push、マイグレーションなどの破壊的なコマンドは、必ず人が承認するようにします。
攻撃者は AI コーディングツールをどう狙っているのでしょうか？
攻撃者は今や、あなたのマシン上の AI エージェントを、シークレットを見つけて盗み出すための道具として使っています。
2025 年 8 月、何者かが、週に約 600 万回ダウンロードされている JavaScript のビルドツール Nx の悪意あるバージョンを 8 つ公開しました（Nx、2025 年）。不正なバージョンが公開されていたのは、およそ 4 時間から 5 時間です。postinstall スクリプトは、マシンに Claude、Gemini、Amazon Q のコマンドラインツールがインストールされているかを確認しました。見つかると、安全チェックを無効にした状態（claude --dangerously-skip-permissions、gemini --yolo、q --trust-all-tools）でそれを実行し、GitHub トークン、npm トークン、SSH 鍵、.env ファイル、暗号資産ウォレットをディスクから探すようエージェントに指示しました。さらに被害者の GitHub トークンを使って本人のアカウントに公開リポジトリを作り、盗んだものをそこにアップロードしました（StepSecurity、2025 年）。こうしてシークレットを公開されてしまった開発者は 1,700 人を超えました（Wiz、2025 年）。
2026 年 2 月には、AI コーディングツールを直接狙うワームが現れました。2 つのアカウントから公開された少なくとも 19 個の npm パッケージが Claude Code や OpenClaw によく似た名前を使っていて、パッケージ名を打ち間違えた人は誤ったパッケージをインストールしてしまいました。インストールされると、このワームは AI プロバイダーの API キーを収集し、開発者の AI ツールに独自の MCP サーバーを追加しました。その MCP サーバーには、SSH 鍵と AWS の認証情報を集めるようアシスタントに指示する隠れた命令が含まれていました。さらに盗んだ npm トークンで感染したパッケージを追加で公開し、GitHub API を通じてリポジトリに自分自身をコミットすることで拡散しました（Socket、2026 年）。
npm のサプライチェーン攻撃は AI エージェントより前からありますが、広い権限を持つエージェントは被害を広げます。ノートパソコン上であなたが読めるもの、送れるものは、エージェントも何でも読んで送れてしまいます。また、2 つの攻撃はどちらも、npm がパッケージのインストールスクリプトを自動的に実行することを利用していました。Go のモジュールにはインストールスクリプトがないので、go get がダウンロード中に依存パッケージのコードを実行することはありません。エコシステム側の話に興味があれば、Go と Node.js のサプライチェーンセキュリティ比較 で、2 つのパッケージマネージャーがこの問題をどう扱っているかを比べています。
AI はコードレビューを壊しているのでしょうか？
壊しています。AI は人間がレビューできるよりも速くコードを書き、その結果としてレビュアーの確認が甘くなっていることがデータに表れています。
Faros AI は、4,000 を超えるチームにまたがる約 22,000 人の開発者を追跡しました。AI の導入が進むにつれて、問題も増えていきました（Faros AI、2026 年）。
- 開発者 1 人あたりのバグ：+54%
- プルリクエスト 1 件あたりのインシデント：+243%
- PR レビューにかかる時間の中央値：+441%
- プルリクエストのサイズ：+51%
- レビューなしでマージされた PR：+31%
2026 年のある研究は、AI エージェントの PR に対する 11,429 件のレビューを通じて、400 人のレビュアーを追跡しました。すでに最も多くのエージェントの PR を見ていたレビュアーは、最も少なかったレビュアーに比べて承認する割合が 14.5 ポイント高く、インラインのレビューコメントは研究期間を通じて 22% 減りました。研究者たちはこれを慣れ（habituation）と呼んでいます。AI のコードを見れば見るほど、レビュアーの確認は甘くなっていったのです（Yu et al.、2026 年）。
Sonar が 2026 年 1 月に 1,100 人を超える開発者を対象に行った State of Code 調査では、38% が AI のコードのレビューは同僚のコードのレビューより手間がかかると答え、53% が正しく見えるのに信頼できない AI のコードを見たことがあると答えました。96% は AI が生成したコードを完全には信頼していませんが、コミット前に必ず確認しているのは 48% だけです（Sonar、2026 年）。この 2 つの数字の差は、来る日も来る日も AI のコードを丁寧にレビューすることの疲れから来ているのだと思います。私自身、エージェントの大きな diff を流し読みしている自分に気づいたことがあります。
Microsoft は、dotnet/runtime リポジトリにおける Copilot coding agent の 10 か月分のデータを公開しました。このリポジトリでは、エンジニアがエージェントにタスクを割り当て、エージェントは 878 件のプルリクエストを作成しました（Microsoft .NET Blog、2026 年）。最初の月にマージされたのは 41.7% だけで、その理由の 1 つはエージェントにビルド手順が与えられていなかったことでした。チームがそれを直すと割合は上がり、10 か月全体ではエージェントの PR の 67.9% がマージされました。エンジニア自身の PR のマージ率は 87.1% でした。エージェントの PR はレビューのコストも大きくなりました。マージされたエージェントの PR には平均 16.5 件のレビューコメントが付き、エンジニアの PR は 12.4 件でした。また 878 件のエージェントの PR のうち 396 件、約 45% で人間が自分のコミットを追加していました。マージされた人間の PR では、この割合は 10.3% です。
| 研究 | サンプル | AI で何が変わったか |
|---|---|---|
| Faros AI（2026 年） | 約 22,000 人の開発者、4,000 以上のチーム | PR レビュー時間の中央値 +441%、開発者 1 人あたりのバグ +54% |
| 慣れに関する研究（2026 年） | レビュアー 400 人、レビュー 11,429 件 | 最も多く接したレビュアーの承認 +14.5 ポイント、インラインコメント -22% |
| Sonar（2026 年 1 月） | 1,100 人以上の開発者 | 96% が AI のコードを完全には信頼せず、必ず確認するのは 48% |
| Microsoft dotnet/runtime（2026 年） | 10 か月間のエージェント PR 878 件 | マージ率 67.9%、エンジニアの PR は 87.1% |
AI が生成したコードは安全性が低いのでしょうか？
AI のコードに起因する脆弱性は急速に増えていて、公表されている数字は実態より少ない可能性が高いです。
Georgia Tech のあるラボが Vibe Security Radar を運営しています。公に報告された脆弱性（CVE）を調べ、それぞれのバグを持ち込んだコミットを特定し、AI の共著者タグなど、AI が書いた痕跡がないかを確認するものです。2026 年 3 月だけで、AI のコードに関連する CVE が 35 件見つかりました。追跡を始めた後の 2025 年 5 月から 12 月までは約 18 件でした（Georgia Tech、2026 年）。プロジェクトの創設者である Hanqing Zhao は、AI が書いたコードの大半には AI 由来だという痕跡が残らないため、本当の数は検出できる数の 5 倍から 10 倍だと見積もっています（Infosecurity Magazine、2026 年）。
GitGuardian は、2025 年に公開 GitHub のコミットで 2,865 万件の新たなハードコードされたシークレットを検出しました。2024 年から 34% の増加で、同社がこれまでに記録した中で最大の年間増加幅です。Claude Code を使ったコミットのシークレット漏洩率は 3.2% で、ベースラインの 1.5% の約 2 倍でした。ただし、それらのコミットはどれも開発者が承認したものです（GitGuardian、2026 年）。
2026 年 5 月、RedAccess の研究者は、Lovable、Base44、Netlify、Replit などのプラットフォームで作られ、Web 上の誰でもアクセスできる状態になっていたバイブコーディングのアプリを約 38 万件見つけました。そのうち約 5,000 件が、医療記録、財務データ、社内の戦略など、機密性の高いデータを漏らしていました（Axios、2026 年）。
CodeScene は、コードを読むのをやめてしまった人に向けて警告を加えています。同社が発表した査読付きの研究では、AI コーディングアシスタントは不健全なコードで欠陥のリスクを少なくとも 30% 高めることがわかりました（CodeScene、2026 年）。同社自身のホワイトペーパーでは、この数字を 60% 以上としています。コードベースが乱雑になるほど、そこでのエージェントの出来は悪くなります。レビューされない変更のたびにコードは少しずつ乱雑になるので、エージェントを野放しにしているチームは、エージェントの今後の仕事を自分たちで難しくしていることになります。
オープンソースのメンテナーは AI にどう対応しているのでしょうか？
いくつかの主要プロジェクトは、低品質な投稿にメンテナーが対応しきれないため、AI による貢献を制限または禁止しています。
- curl は 2019 年からバグバウンティを運営し、確認された 87 件の脆弱性に対して合計 10 万ドル以上を支払ってきました。2025 年には投稿の約 20% が AI スロップで（Daniel Stenberg、2025 年）、メンテナーは質の低い報告の量に対応しきれなくなりました。バウンティは 2026 年 1 月 31 日に終了しました（Daniel Stenberg、2026 年）。
- Mitchell Hashimoto がメンテナンスしているターミナル Ghostty は、外部のコントリビューターからの AI 生成コードを、メンテナーがすでに合意した作業に限って受け入れるようになりました。それ以外はクローズされ、質の悪い AI の貢献を投稿した人はプロジェクトから締め出されます。Hashimoto は、AI によって「『悪い』ものの数が 10 倍、あるいはそれ以上に増えた」と書いています（Ghostty、2026 年）。
- Godot は 2026 年 6 月、自律型エージェント、バイブコーディング、そして AI が生成した相当量のコードを禁止し、コード補完のような小さな支援作業だけを認めることにしました。「AI は責任を取れませんし、AI を多用する人が、自分のコードを修正できるほど理解していると信頼することもできません」（Godot Foundation、2026 年）。
- Rust は 2026 年 8 月、rust-lang/rust リポジトリ向けに LLM ポリシーを採用しました。「LLM を使って質問に答えさせたり、分析、要約、改善、確認、提案、レビューをさせたりするのは構いません。しかし、作らせてはいけません」（Rust Blog、2026 年）。
- GitHub は、メンテナーがプルリクエストを無効にしたり、コラボレーターだけに制限したりできるリポジトリ設定を導入しました（GitHub、2026 年）。その後、1 人のコントリビューターが持てるオープンな PR の数に上限を設ける機能も追加しています（GitHub、2026 年）。
AI はジュニア開発者のスキルにどう影響するのでしょうか？
ジュニアにとってのコストはスキルです。私の経験では、AI に頼りがちなジュニアは基礎でつまずくことが多く、今ではそれについての研究もあります。その一部は AI 企業自身によるものです。
Anthropic は、主にジュニアのエンジニア 52 人を対象に、使ったことのない Python の非同期ライブラリ Trio を学ぶランダム化試験を行いました。AI を使ったグループの事後の理解度クイズの得点は 50% でした。手でコードを書いたグループは 67% でした。AI グループは約 2 分速かっただけで、その差は統計的に有意ではありませんでした（Anthropic、2026 年）。理解を失い、その見返りとして測定できるほどの速さは得られなかったのです。この研究については、AI のどんな使い方なら得点が高いまま保てたのかも含めて、今でもコードは手で書くべき？で詳しく取り上げました。経験を積んだエンジニアが同じ道をたどらないために、どのスキルから衰えていくのか、それをどう練習すればよいのかは、AI がコードを書く時代にコーディングスキルを鈍らせない方法で解説しています。
AI はコードを書いてくれますが、ここまで見てきたことはすべて、それでも誰かがそのコードを理解していなければならない理由を示しています。基礎は以前よりも重要になっていると私は考えています。私が作った LevelUpGo は、最初の 1 行から本番コードまで、Go を自分で書くことを中心にしていて、演習はコードがコンパイルされ、テストが通ったときにだけ合格になります。言語の選択も助けになります。AI が書くコードに Go が最適な言語である理由では、Go のコンパイラとツールが、エージェントのミスを出荷前により多く捕まえる仕組みを解説しています。
AI コーディングツールは燃え尽き症候群を引き起こすのでしょうか？
研究によれば、引き起こすことがあります。主な原因は、ツールと一緒にやってくる仕事量と期待の増加です。
Oregon State University の研究者は、プロの開発者 442 人に AI の利用と燃え尽きについて調査しました。その結果、生成 AI の導入は燃え尽きを増やしており、その主な理由は仕事上の要求、つまり仕事量の増加と組織からのプレッシャーの増加だとわかりました（Feng et al.、2026 年）。2 人の参加者がそれを率直に語っています。1 人は「ツール自体は問題ない。ひどいのは、ツールが経営陣の期待にもたらした変化だ」と言いました。もう 1 人は「AI のおかげで速く動けて、山のような仕事を片付けている。でも仕事への情熱を失いつつある」と言いました。
UC Berkeley の研究者は、2025 年 4 月から 12 月まで、従業員約 200 人の米国のテック企業に入り込み、人々が実際に AI とどう働いているかを観察しました（Harvard Business Review、2026 年）。仕事は 3 つの形で増えていきました。
- タスクの拡大。知らないことを AI が補ってくれるので、人々はこれまで自分の担当ではなかった仕事まで引き受けるようになりました。
- 境界のあいまい化。タスクに取りかかるコストがとても小さくなったので、仕事が昼休みや会議、夜の時間にまで入り込むようになりました。
- マルチタスクの増加。AI に別のバージョンを書かせている間に手でコードを書き、複数のエージェントを同時に走らせ、AI なら片付けられるようになったからと昔のタスクを再開しました。誰かに頼まれたわけでもないのにです。
研究者たちはこれをループとして説明しています。AI によって一部のタスクが速くなると、スピードへの期待が高まり、働く人はますます AI に頼るようになります。研究に参加したあるエンジニアは、こうまとめています。「もしかしたら……仕事を減らせるかもしれないと思っていました。でも実際には、仕事は減りません。同じ量か、むしろもっと多く働くことになるんです。」
私の考え
AI は本当の価値をもたらし、私たちの生産性を高めてくれます。私も毎日使っています。でも、何にでも効く解決策ではありません。
これらの研究を読んで印象に残ったのは、職場で目にしていることとどれほど一致しているかでした。ソフトウェアエンジニアとして働いてきた年月の中で、ソフトウェア全体の品質が今ほど低いと感じたことはありません。私から見れば、それはスピードと品質のバランスをまだ見つけられていないということです。そして私は、スピードより品質のほうが大事だと考えています。
だから私は、AI をミスの多いツールとして扱っています。AI が書いたものは信頼せずにレビューし、タスクに必要な権限だけを与えます。プロンプトで AI を安全にすることはできないからです。
これだけのデータを見たあとで、私はこれらのツールのコストが、ツールが返してくれる価値より大きいのではないかと自問し続けています。最終的な答えはまだ出ていません。ただ、サブスクリプションの料金よりはるかに大きいことは、ほぼ確かだと思っています。
よくある質問
AI コーディングツールの最大のリスクは何ですか？
最大のリスクは、レビューを通るのに本番環境で失敗するコード、アクセス権を持ちすぎたエージェントによるデータの削除、確認の甘さにつながるレビューの滞留、セキュリティの脆弱性、そして学習を AI に任せた開発者のスキルの喪失です。New Relic の 2026 年の調査では、技術リーダーの 82% が、直近 6 か月の間に AI のコードが原因で起きた本番障害を挙げることができました（New Relic、2026 年）。
AI が生成したコードはなぜ本番環境で壊れるのですか？
エージェントは、本番環境でシステムがどう振る舞うかを知りません。トラフィックのパターンも、忙しい日も、既存のコードがなぜそのようにエッジケースを処理しているのかも見えず、立ち止まって質問することもめったにありません。さらに AI の大きな diff はレビュアーに流し読みをさせるので、そうした抜けがそのまま承認されてしまいます。
AI エージェントが本番データを削除するのをどう防げばよいですか？
エージェントが届く範囲を制限することです。エージェントには環境ごとに分かれた、狭くスコープを絞った認証情報を渡し、本番環境とステージング環境でストレージやバックアップを共有せず、Terraform の state はロックされたリモートストレージに置き、破壊的なコマンドはすべて人間の承認を必須にします。プロンプトの指示はセキュリティの境界にはなりません。
AI が生成したコードは安全ですか？
デフォルトでは安全ではありません。Georgia Tech の Vibe Security Radar は、2026 年 3 月だけで 35 件の CVE を AI が書いたコードと結びつけました。プロジェクトの創設者は、本当の数はその 5 倍から 10 倍だと見積もっています（Infosecurity Magazine、2026 年）。認証、認可、決済、ユーザーデータを扱う部分は、1 行ずつレビューしましょう。
ジュニア開発者は AI コーディングツールを使うべきですか？
概念やエラーの説明に使いましょう。まだ理解していないコードを書かせるのには使わないでください。Anthropic の 2026 年の試験では、AI を使って新しいライブラリを学んだジュニアは理解度の得点が 17 ポイント低く、意味のあるほど速くもなっていませんでした（Anthropic、2026 年）。
出典
- New Relic, 2026 State of AI Coding press release（2026 年 6 月）
- Stella Laurenzo, Claude Code is unusable for complex engineering tasks with the Feb updates, GitHub issue #42796（2026 年 4 月）
- Anthropic, April 23 postmortem（2026 年 4 月）
- The Register, Cursor Opus agent snuffs out startup's production database（2026 年 4 月）
- Alexey Grigorev, How I dropped our production database（2026 年 3 月）
- The Decoder, AWS AI coding tool decided to delete and recreate a customer-facing system（2026 年 2 月）
- Amazon, Response to the Financial Times on the AWS service outage（2026 年 2 月）
- Nx, S1ngularity: what happened, how we responded, what we learned（2025 年）
- StepSecurity, Popular Nx build system package compromised with data-stealing malware（2025 年 8 月）
- Wiz, s1ngularity's aftermath: AI, TTPs, and impact in the Nx supply chain attack（2025 年 9 月）
- Socket, SANDWORM_MODE: npm worm hijacks CI workflows and poisons AI toolchains（2026 年 2 月）
- Faros AI, The AI Acceleration Whiplash: ten takeaways（2026 年 4 月）
- Yu et al., Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code（2026 年 6 月）
- Sonar, 96% don't fully trust AI output, yet only 48% verify it（2026 年 1 月）
- Microsoft .NET Blog, Ten months with Copilot coding agent in dotnet/runtime（2026 年 3 月）
- Georgia Tech, Bad Vibes: AI-generated code is vulnerable, researchers warn（2026 年 4 月）
- Infosecurity Magazine, Researchers sound the alarm on vulnerabilities in AI-generated code（2026 年 3 月）
- GitGuardian, The State of Secrets Sprawl 2026（2026 年 3 月）
- Axios, Thousands of AI-built apps exposed sensitive corporate and personal data（2026 年 5 月）
- CodeScene, AI coding assistants increase defect risk by 30% in unhealthy code（2026 年 1 月）
- Daniel Stenberg, Death by a thousand slops（2025 年 7 月）、The end of the curl bug-bounty（2026 年 1 月）
- Ghostty, Updated AI usage policy for contributions, PR #10412（2026 年 1 月）
- Godot Foundation, Changes to our contribution policies（2026 年 6 月）
- Rust Blog, rust-lang/rust is adopting an LLM policy（2026 年 8 月）
- GitHub Changelog, New repository settings for configuring pull request access（2026 年 2 月）、Limit open pull requests for users without write access（2026 年 6 月）
- Anthropic, How AI assistance impacts the formation of coding skills（2026 年 1 月）
- Feng、Afroz、Sarma, From Gains to Strains: Modeling Developer Burnout with GenAI Adoption, ICSE-SEIS（2026 年）
- Ranganathan、Ye, AI Doesn't Reduce Work, It Intensifies It, Harvard Business Review（2026 年 2 月）