PowerPointのゴミが、本番環境に来る時代──AIが広げる「作り逃げ」の技術的負債

• Facebook
• Twitter
• はてブ
• LINE
• Pocket

以前なら、企画は実装の手前で止まることがあった。
発注者が意思決定を説明し、社内で正当化できるPowerPointがあれば、それで役目を果たす案件もあったからである。

それらしい課題整理と業務フロー、将来像が描かれていても、実際に作ろうとすれば問題が見つかる。
要件が曖昧で、例外処理が考えられておらず、現場の業務とも噛み合わない。
その結果、PoCで止まる。

振り返れば、この「簡単には作れない」という制約には、安全装置としての側面もあった。

生成AIは、この制約を弱めている。
要件整理、アプリケーションやインフラの設計、画面やAPIの作成、データ連携、Infrastructure as Code、テストまで、一連の開発作業を支援できる。
エラーが出ても、原因の調査と修正を続けられる。

その結果、以前ならPowerPointやPoCで止まっていた企画でも、一応動くものを本番環境まで持っていける可能性が高まった。

この記事では、短期間で動くものを作った時点で成果が評価され、その後の運用、保守、セキュリティ対応、引き継ぎ、廃止を別の人が引き受ける構造を「作り逃げ」と呼ぶ。

この構造自体はAI以前から存在した。
生成AIが変えるのは、作り逃げそのものを発明することではなく、動くものを作れる速度と量である。

生成AIによって作るコストは下がっている。
一方、作ったものを安全に持ち続けるコストが同じ割合で下がったとは限らない。
私は、この非対称性がRPAや従来のDXより大きな問題になると考えている。

RPAから生成AIへ

似た問題は生成AI以前から存在した。

金融庁は2020年の「金融機関のITガバナンス等に関する調査結果レポート」で、管理者が不在になったまま稼働したり、業務変更や引き継ぎによって処理内容が分からなくなったRPAを「野良ロボット」と呼び、ブラックボックス化や維持・管理コストを課題として挙げている[1]。

RPAで問題になったのは、作った人しか仕組みを理解していないことや、担当者がいなくなった後も処理だけが残ることだった。
金融庁の調査時点では、RPA導入の主な目的は定型業務の自動化であり、自動化の対象は電子化された業務と整理されている[1]。

生成AIを使った開発では対象範囲が広がる。

NISTの2026年のDevSecOps文書では、生成AIを要件整理、作業の分解、チケット作成、ソースコードの生成・修正、インフラ設定、テストケース生成などに利用した例が示されている[2]。

生成AIで作ったシステムは、データベース、クラウド、認証基盤、外部サービスなど複数のシステムへ接続できる。
RPAで問題になった「野良ロボット」が、より広い範囲へ影響する「野良システム」になる可能性がある。

「生成AIはRPAより危険である」という比較を直接実証した統計があるわけではない。
ここは私自身の評価である。

それでも、RPAで既に問題になった属人化や管理不全が、API、データ、認証、クラウドまで含むシステムで起きれば、障害や情報漏洩が起きた場合の影響範囲は広くなり得る。

生成速度とレビュー負荷

生成AIを使った開発が、常に粗悪な成果物を生むわけではない。
私自身も仕事で利用しており、調査、設計案の比較、実装、テストなどで時間を短縮できる場面は多い。

ただし、設計やコードを作る速度と、企業が安全にソフトウェアをリリースする速度は区別した方がよい。

2026年にKIKKAKE ITREND（運営元：株式会社キッカケクリエイション）が、業務でコードレビューを担当するITエンジニア322人を対象に実施した調査では、AI生成コードのレビュー経験者277人の49.5%が「提出者本人がコードの内容を説明できなかった」と回答した。
また、調査対象322人の74.8%は「コードを書く速度は上がったが、届ける速度はあまり変わらない」と回答している[3]。

Stack Overflowの2026年Developer Surveyでも、AIによる問題でチームの時間を消費したものとして、回答者13,648人の69.3%が「もっともらしいが誤ったコード」、54.2%が「レビューしづらい生成コード」を挙げている[4]。

GitLabが公表した、The Harris Poll実施による6か国1,528人の開発者・技術購買担当者を対象とした2026年調査では、78%がAI導入後にコードを書く速度が上がったと回答した一方、85%がボトルネックはコードを書くことからレビューと検証へ移ったと回答した。
82%は、組織が管理する準備のできていない新たな技術的負債をAI生成コードが生むリスクを挙げている[5]。

これらは対象者も調査方法も異なり、特に[3]と[5]は民間企業による意識調査である。
生成AIの利用が原因でレビュー負荷が増えたことを実験的に証明したものではない。

一方、AI利用によって実際の作業時間が短くならなかった実験結果もある。

METRが2025年に行ったランダム化比較試験では、経験豊富なオープンソース開発者16人が、自分たちが複数年関わってきた成熟したプロジェクトで、バグ修正、機能追加、リファクタリングなど246件の実際の開発課題（Issue）に取り組んだ。
その結果、AI利用を許可された課題では、利用しない場合より完了時間が平均19%長くなった[6]。

対象人数や開発環境が限られるため、この結果から「生成AIは開発を遅くする」と一般化することもできない。
新規開発や不慣れな技術の調査では、逆に大幅な時間短縮が起こる場合もある。

生成AIの効果を一つの生産性指標で測ると、この違いを見落とす。
要件整理、設計、実装、テスト、既存コードの調査など、どの工程が速くなり、その結果どこに負荷が移るかを見る必要がある。

技術的負債と撤去コスト

ソフトウェア開発では、市場投入を急ぐために設計上の妥協を受け入れ、後で改善するような状態を技術的負債として扱うことがある。

生成AIによって増えると私が懸念しているのは、それより手前の問題である。
誰が使うのか、何年使うのか、どのデータが正なのか、障害時に誰が責任を持つのかが曖昧なまま、「動いている」という理由でシステムだけが残るケースである。

この状態では、返済すべき設計上の負債すら明確ではない。
将来、誰かが利用状況と依存関係を調査し、安全に撤去しなければならないという意味では、廃棄物に近い。

GitClearは2020年から2024年までの2億1,100万行の変更コードを分析し、リファクタリングに関連する変更行の割合が2021年の25%から2024年には10%未満へ低下する一方、copy/pasteと分類された変更行は8.3%から12.3%へ増加したと報告している[7]。

この分析は、AIを利用した変更と利用しなかった変更を無作為に比較した実験ではない。
AI利用の拡大期とコード変更傾向の変化が重なっていることは示しても、「AIが原因でコード品質が悪化した」とまでは言えない。

この記事で問題にしたいのも、生成AIが必ず悪いコードを書くかどうかではない。
コードやシステムを追加するコストが低下しても、それを保守し、最後に撤去する仕事まで消えるわけではない。

PowerPointなら、不要になればファイルを閉じられる。
PoCも、他の業務やデータから依存されていなければ環境を削除しやすい。

本番システムでは利用者、蓄積データ、他システムとの連携、業務上の依存関係が生じるため、作るだけでなく捨てることにもコストがかかる。

人間の理解と組織の制御

生成AIによる開発を批判するとき、「人間がコードを理解できなくなるから危険だ」と説明することがある。
この説明だけでは、今後の開発を捉えきれない可能性がある。

2026年10月に公開されたエンジニアによる個人論考では、生成AIによってコード作成だけでなく、既存コードの調査、バグ修正、機能追加、インシデント調査までAIに任せることが可能になり、人間がシステム全体を把握しない開発や保守が広がっていることが論じられている[8]。

これは実証研究ではないが、問題提起には説得力がある。

そもそも生成AI以前のシステムも、すべて人間に理解されていたわけではない。
巨大なシステムの一部を特定の担当者しか知らない、あるいは全体を完全に把握する人がいない状況は以前からあった。

生成AIを使って必要な部分を調査し、影響範囲を確認し、修正案やテストを作れるなら、従来は熟練者に集中していた作業をより多くの人が担えるようになる可能性もある。
生成AIが開発や保守の平均的な能力を底上げする面は認めるべきだと思う。

その変化によって、人間がコードの細部まで理解していることを保守の絶対条件にする必要は弱まるかもしれない。
一方、人間による完全な理解が不要になることと、組織による制御が不要になることは別である。

企業は少なくとも、システムの目的、扱うデータ、外部から到達できる範囲、権限、障害時に守るべき機能、復旧方法、変更を検証する方法、本番投入の承認者を把握する必要がある。

コードの一行一行を人間が説明できなくても、変更結果を検証できず、障害時の判断主体も存在しない状態では、企業としてシステムを管理できない。

生成AIによって緩和されるのは、人間がすべての実装を記憶し理解するという条件である。
組織としてシステムを制御し、その結果に責任を持つという条件は残る。

プロトタイプと「作り逃げ」の評価構造

Forward Deployed Engineer（FDE）は、この問題そのものではない。

PalantirはForward Deployed Software Engineerを、顧客に直接入り込み、同社の既存ソフトウェア基盤を構成して顧客の課題を解き、エンドユーザーと協働してソリューションを実装するソフトウェアエンジニアと説明している[9]。

利用者と短い周期で試行し、実際の業務を確認しながら改善する方法には利点がある。

生成AIによって、要件定義の段階から動くものを見せながら利用者と話せるようになったことも同じである。
文章や図だけでは伝わりにくかった要件を実際に触りながら確認でき、利用者も試作品を見て初めて必要な機能に気付ける。

問題は、動くものを短期間で作ることだけが成果として評価される場合に生じる。

生成AIによって目に見える成果物を短期間に増やせるようになれば、品質や将来の保守性より、アウトプットの量が評価される場面も増え得る。
70点で十分なシステムは当然あり、すべてを90点にする必要はない。

しかし、その70点を誰が何年間維持するかというコストが評価から抜け落ちれば、短期的な生産性と長期的な負担が別の人へ配分される。

この構造はAI以前にもあった。
プロジェクトを作る側と運用する側が分かれるSIerの開発でも、担当者が異動した後に残るRPAでも起こり得た。

生成AIが変えるのは、その構造が生まれる速度と量である。

試作品にも同じ問題がある。
動くものを目の前にすれば、「このデータともつなげたい」「この機能も追加したい」という要望が出るのは自然であり、生成AIを使えばその場で追加機能まで試作できる場合がある。

そこで追加機能の実装コストだけを見れば、プロトタイプへ機能を積み上げる判断は合理的に見える。
本番投入後には、監視、障害対応、権限管理、データ整合性、仕様変更への追従、廃止が必要になるため、機能を追加するコストと持ち続けるコストは一致しない。

「動いた」は要件を確認する材料にはなるが、完成の判定には使えない。
生成AIによってプロトタイプ作成が容易になるほど、本番投入の判定を別に設ける必要がある。

FDE、コンサルタント、SIer、社内エンジニアのどの立場でも、この評価構造は起こり得る。
本稿では、作ることで評価を得る側と、作った後の責任を負う側が分離するこの構造を「作り逃げ」と呼んでいる。

チーム単位の制御

私自身も仕事で生成AIを使っている。

実装を生成させる場合は、できるだけチームが検証できるプログラミング言語やフレームワークを選ぶようにしている。
ここでいう「検証できる」は、生成されたコードを人間が一行ずつ完全に説明できるという意味ではない。

技術の基本的な性質を理解し、変更の妥当性を評価し、問題が起きたときに生成AIの調査結果を検証できるという意味である。

インフラやデータ連携でも、生成された案をそのまま採用するとは限らない。
動作する構成であっても、障害からの復旧、監視、データ量の増加、ネットワークと権限、既存システムとの責任分界、原因調査まで考えると構成を変更する必要がある。

この考え方を、実装者個人の注意力だけに依存させるわけにはいかない。
生成AIを使う開発では、Human in the Loopをチームの工程として組み込む必要がある。

NISTの2026年のDevSecOps文書では、AI生成物を既存のDevSecOpsプロセスでレビュー・検証し、生成元のコンテキストまで追跡可能にし、監査用ログを残したうえで、責任ある担当者が承認してから要件、コード、設定、デプロイへの入力として利用する考え方が示されている[2]。

チーム開発へ当てはめると、例えば次のようになる。

• 採用する言語やフレームワークを、チームが検証できる範囲にする
• AI生成コードも通常のコードレビュー、テスト、セキュリティ確認を通す
• インフラやデータ連携は、運用担当者の視点でも確認する
• 本番投入前に、監視、復旧、ロールバック、権限、データ整合性を確認する
• 所有者、問い合わせ先、引き継ぎ先を決める
• システムの目的、重要な仕様、データ、セキュリティ境界、責任分界を組織として把握する
• AIによる変更を検証する手段を用意する
• 廃止条件と廃止方法を決める

こうした制御の実践例として、David Doddaは生成AIへいきなり実装させず、コーディング規約、データベース設計、タスクリスト、開発記録を先に用意し、計画を作らせ、人間がレビューしたうえで実行させる流れを紹介している[10]。

この方法自体を標準にする必要はない。
参考になるのは、生成された大量のコードを後から人間が追いかけるのではなく、生成前から制約と検証工程を設けている点である。

本稿でいうHuman in the Loopは、人間が生成AIの仕事をすべてやり直すことではない。
生成AIを含む開発工程を、チームとして検証、追跡、承認できる状態にすることである。

運用能力と攻撃対象領域

生成AIによって開発コストが低下しても、企業が既存システムを安全に運用する仕事は残る。

JPCERT/CCは2026年10月、国内組織で不正アクセスによる個人情報等の漏洩被害が相次いでいるとして注意喚起を出した。
被害は一般利用者向けアプリだけでなく、BIツールや従業員向け管理システムにも及び、APIへの不正な操作、既知の脆弱性、機器の管理不備など複数の手口が確認されている[11]。

この事実だけから、被害企業に情報システムの運用能力がなかったとは判断できない。
十分な対策をしていても侵害を完全には防げず、それぞれの事故には個別の原因がある。

一方、企業が継続的に管理すべき項目が多いことは分かる。
公開範囲、認証、権限、脆弱性、APIキー、ログ、監視、復旧などである。

生成AIを使ってアプリケーション、API、管理画面、データ連携を増やせば、この管理対象も増える。
新しいシステムには認証情報、権限設定、外部から到達可能な入口、依存ライブラリ、外部サービス、保存データ、監視対象が付随するためである。

これら外部から攻撃され得る入口や依存関係の総体を攻撃対象領域（Attack Surface）という。
生成AIによって個々の保守作業が効率化されても、システム数や接続関係が増えれば、企業が管理すべき攻撃対象領域も広がり得る。

セキュリティ上の問題も、「生成AIが安全なコードを書けるか」だけでは決まらない。
企業が自社のシステムを把握し、安全に所有し続けられるかが別に問われる。

作る判断と持つ判断

生成AIには、開発能力の平均を引き上げる可能性がある。
以前なら一人では難しかった設計案の作成、知らないコードの調査、バグ原因の特定、修正案、テスト作成まで支援できるからである。

従来うまく開発できなかった人や組織でも、生成AIによって一定水準まで引き上げられることはあり得る。
この意味で、生成AIが弱い開発者や組織をまったく救わないと考えるのも正確ではない。

ただし、平均的な作業能力の向上と、組織としてシステムを所有する能力は別の問題である。

企業は、何を作るか、どの品質を要求するか、どのリスクを受け入れるか、誰が所有するか、どのデータを扱うか、どこまで公開するか、障害時にどう事業を継続するか、いつ廃止するかを決めなければならない。

将来は、こうした意思決定についても生成AIから有力な助言を得られるようになるだろう。
それでも、助言を採用してシステムを事業に組み込み、その結果を引き受ける主体は企業である。

生成AIによって要件整理、設計、実装、テスト、調査、保守に必要な手作業が減れば、作れるものは増える。
作れるものが増えるほど、「作れるから作る」という判断と「持つ価値があるから作る」という判断を区別する必要がある。

PowerPointなら、企画が終わればファイルを閉じられた。
生成AIを使えば、その企画から短期間でコード、データ、API、クラウド上のリソースを作り、他システムと接続できる。

本番投入した時点で、それは成果物であるだけでなく、保守対象、セキュリティ管理対象、将来の廃止対象になる。

問うべきなのは、「AIで作れるか」だけではない。
「このシステムを本番環境に置き、組織として責任を持って所有し続ける価値があるか」である。

PowerPointのゴミを、本番環境のゴミに変えてはいけない。

参考文献

[1] 金融庁「金融機関のITガバナンス等に関する調査結果レポート」2020年6月
https://www.fsa.go.jp/news/r1/20200630-2/it_02.pdf

[2] National Institute of Standards and Technology / National Cybersecurity Center of Excellence, “Notional Reference Model for DevSecOps for Demonstration of NIST SSDF,” §2.7 “Artificial Intelligence,” 2026
https://pages.nist.gov/nccoe-devsecops/notational-reference-model.html

[3] KIKKAKE ITREND（運営元：株式会社キッカケクリエイション）「【AI生成コードのレビュアー負担に関する調査】レビュー担当者の約9割が『負担増』を実感78.6%がAI起因のバグ修正を経験、『本人がコードを説明できない』課題も」2026年4月21日
https://itrend.kikkakeagent.co.jp/articles/210

[4] Stack Exchange Inc., “Did AI cause business disruptions?”, Stack Overflow Developer Survey 2026, 2026
https://survey.stackoverflow.co/2026/technology/data/disruption

[5] GitLab Inc., “GitLab Research Reveals Organizations Are Generating AI Code Faster Than They Can Control It,” survey conducted by The Harris Poll, 2026
https://about.gitlab.com/press/releases/2026-06-23-gitlab-research-reveals-organizations-are-generating-ai-code-faster-than-they-can-control-it/

[6] Joel Becker, Nate Rush, Beth Barnes, David Rein, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” Model Evaluation & Threat Research (METR), 2025
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[7] GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data,” 2025
https://www.gitclear.com/ai_assistant_code_quality_2025_research

[8] m.o.b.「自分は旧時代のエンジニアになってしまったのでは」2026年10月25日
https://www.mobtown.jp/article/old-engineer/

[9] Palantir Technologies, “A Day in the Life of a Palantir Forward Deployed Software Engineer,” 2020
https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1

[10] David Dodda, “Most AI Code is Garbage. Here’s How Mine Isn’t.” Updated September 17, 2025
https://blog.daviddodda.com/most-ai-code-is-garbage-heres-how-mine-isnt

[11] JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」2026年10月8日公開、10月23日更新
https://www.jpcert.or.jp/at/2026/at260030.html

• Facebook
• Twitter
• はてブ
• LINE
• Pocket