AIツール開発の民主化が招く「SLOPの量産」——Excelマクロ地獄の再来を防ぐ経営者の選択
生成AIの進化により、CursorやClaude Codeなどを使えば誰でも業務ツールを開発できる時代が到来した。しかしこの「開発の民主化」は、かつて多くの企業を苦しめたExcelマクロ地獄を再現するリスクをはらんでいる。特にERP、人事システム、CRM/SFAといった基幹領域では、ガバナンスの崩壊やメンテナンス不能、ツールの暴走といった深刻な問題を引き起こしかねない。本記事では、AIが量産する「SLOP（動くが管理できないコード）」の危険性と、経営者が取るべき統制のあり方について解説する。
はじめに：誰もが開発者になれる時代がやってきた
「プログラミング経験がなくても、業務ツールが作れる」——この夢物語が、いま現実のものになりつつあります。
ChatGPTやClaude、GitHub Copilotといった生成AIの登場により、自然言語で指示を出すだけでコードが生成される時代が到来しました。さらに最近では、CursorのようなAI搭載エディタや、AnthropicのClaude Code、OpenAIのCodexといった開発特化型のAIツールも次々と登場しています。これらのツールは、プログラミング未経験者でも驚くほど簡単に動くコードを生成できてしまいます。
営業担当者が自分専用の顧客管理ツールを作り、経理担当者が請求書処理の自動化スクリプトを組み、マーケティング担当者がデータ分析ダッシュボードを構築する。かつてはIT部門に依頼しなければ実現できなかったことが、現場の担当者自身の手で、ほんの数時間で形になってしまうのです。
この「開発の民主化」は、間違いなく歓迎すべき変化です。現場の課題を最もよく知る人が、その解決策を自ら作れる。IT部門のバックログに埋もれて何ヶ月も待たされることなく、今日の課題を今日解決できる。ビジネスのスピードは確実に上がります。
しかし、この革命的な変化の裏側で、私たちは20年前に経験した悪夢を繰り返そうとしているのではないでしょうか。
その悪夢とは、「Excelマクロ地獄」です。
Excelマクロ地獄——組織が経験した負の遺産
2000年代、多くの企業でExcel VBAによる業務自動化が爆発的に広がりました。現場の「できる人」がマクロを組み、部門の業務効率を劇的に改善していったのです。経営層から見れば、追加のIT投資なしに生産性が上がる魔法のような現象でした。
しかし、その10年後、15年後に何が起きたでしょうか。
作成者が異動や退職でいなくなり、誰も中身を理解できないマクロが業務の根幹を支えている状態が至るところで発生しました。エラーが出ても直せない。Excelのバージョンアップで動かなくなっても対処できない。「このファイルを開くときは必ずマクロを有効にして、この順番でボタンを押して、絶対にこのセルは触らないで」——こうした口伝のルールが増殖し、新人の教育コストは膨れ上がっていきました。
最も深刻だったのは、業務プロセスがブラックボックス化したことです。なぜその計算式なのか、なぜその分岐条件なのか、作った本人以外には誰にも分からない。監査対応で「この数字の根拠は？」と問われても、「このマクロが出した数字です」としか答えられない。内部統制の観点から見れば、これは重大なリスクでした。
いま、生成AIによる開発民主化は、このExcelマクロ地獄を、より大規模に、より高速に、より深刻な形で再現しようとしています。
SLOPの量産——AIが生み出す「動くが管理できないコード」の山
「SLOP」という言葉をご存知でしょうか。もともとは「Synthetic Low-quality Output Products」の略とされ、AIが大量生成する低品質なコンテンツを指す俗語として使われ始めました。最近では、AIが生成した「一応動くが、品質や保守性に問題があるコード」を指す文脈でも使われるようになっています。
CursorやClaude Codeのような高機能なAI開発ツールを使えば、確かに洗練されたコードが出力されます。しかし問題は、出力されたコードの質ではなく、それを受け取る側——つまり利用者がコードの意味を理解しているかどうかにあります。
AIにプロンプトを投げれば、確かにコードは出てきます。そしてそのコードは、多くの場合「動き」ます。目の前の課題は解決されます。しかし、そのコードにはいくつかの共通した問題が潜んでいることが少なくありません。なぜそのロジックなのか、設計意図が不明確なまま使われている。エラーハンドリングが不十分で、想定外の入力で破綻する。セキュリティ上の考慮が欠けている。他のシステムとの整合性が検証されていない。そして何より、作成者自身がコードの中身を十分に理解していないケースが多いのです。
Excelマクロ時代との決定的な違いは、生成速度と適用範囲にあります。マクロを書くにはVBAの知識が必要で、習得には時間がかかりました。しかしAIを使えば、プログラミング未経験者でも、1日に何十ものスクリプトやツールを量産できてしまいます。
結果として、組織内に「誰が作ったか分からない」「何をしているか正確には分からない」「でも業務に組み込まれていて止められない」ツールが、Excelマクロ時代とは比較にならない速度で増殖していくことになります。
民主化が危険な領域——ERP、人事システム、CRM/SFA
開発の民主化それ自体は、繰り返しになりますが、良いことです。単純な業務自動化、個人の生産性向上ツール、一時的なデータ処理——こうした領域では、現場主導の開発は大いに推奨されるべきでしょう。
しかし、民主化が深刻なリスクをもたらす領域があります。それは、組織の基幹業務を支え、複数部門にまたがり、データの一貫性と正確性が経営判断に直結するシステム群です。
ERP（基幹業務システム）への無秩序な接続
ERPは、会計、購買、在庫、生産、販売といった企業活動の根幹を統合的に管理するシステムです。ここに「ちょっと便利だから」と現場が独自ツールを接続し始めると、何が起きるでしょうか。
マスタデータの整合性が崩れていきます。ある部門が独自に作った顧客登録ツールが、名寄せルールを無視してデータを投入する。会計処理の前提となる数字が、検証されていないロジックで加工される。監査証跡が取れない経路でデータが更新される。
ERPの価値は「Single Source of Truth（唯一の真実の源泉）」であることにあります。現場の善意による改善ツールが、その価値を根底から毀損してしまう可能性があるのです。
人事システムと個人情報保護リスク
人事データは、個人情報保護の観点から最も厳格な管理が求められる領域です。給与計算、評価情報、健康診断結果、マイナンバー——これらを扱うシステムに、現場が「便利だから」と作ったツールが接続されるリスクを考えてみてください。
アクセス権限の管理はどうなっているのか。データの持ち出し制御はされているのか。ログは取られているのか。退職者のアクセス権は適切に剥奪されるのか。
人事部門の担当者がAIで作った「評価集計ツール」が、実は全社員の評価データをローカルPCにコピーしていた——こうした事態は、決して絵空事ではありません。
CRM/SFAにおける顧客データの分散
顧客データと営業活動の履歴は、企業にとって極めて重要な資産です。この領域で現場主導のツール開発が暴走すると、複数の問題が同時に発生します。
顧客データの重複と分散という問題がまず起きます。営業担当者がそれぞれ「自分用の顧客管理ツール」を作り、本体のCRMとは別にデータを持ち始める。名寄せができなくなり、同じ顧客に複数の担当者が別々にアプローチする。顧客から見れば「この会社は情報共有ができていない」という印象を与え、信頼を損ないます。
パイプラインの数字が信用できなくなるという問題も深刻です。独自の案件管理ツールが乱立すると、経営層が見ている数字と現場の実態が乖離します。予測精度は下がり、リソース配分の判断を誤るリスクが高まります。
なぜ危険なのか——ガバナンス、メンテナンス、持続性、暴走の4つの視点
これらの領域で現場主導の開発が危険な理由を、4つの観点から整理してみましょう。
ガバナンスの崩壊
誰が、いつ、どのような権限で、どのようなツールを作り、どのデータにアクセスしているのか。これが把握できなくなることが、最大のリスクです。
IT部門が管理するシステムには、承認プロセス、アクセスログ、変更管理、監査証跡といったガバナンスの仕組みが組み込まれています。しかし現場がAIで作ったツールには、こうした仕組みがありません。
内部監査で「このデータはどこから来たのか」と問われたとき、「営業の田中さんがChatGPTで作ったスクリプトが集計しています」と答えることになります。監査法人がこれを許容するでしょうか。上場企業であれば、内部統制報告書にどう記載するのでしょうか。
メンテナンス不能という現実
AIが生成したコードを、作成者自身が完全に理解していないケースは珍しくありません。「プロンプトを投げたら動くものが出てきたので使っている」という状態です。
このツールにバグが見つかったとき、仕様変更が必要になったとき、連携先のシステムがアップデートされたとき、誰が対応するのでしょうか。作成者に「直してください」と依頼しても、「AIに聞いてみます」という回答が返ってくる。AIに聞いても、文脈が失われているため、的外れな修正案が出てくる。
結局、IT部門が一から解析することになりますが、ドキュメントもなく、設計意図も不明なコードの解析は、新規開発より時間がかかることすらあります。
持続性の欠如
現場のツールは、作成者の異動や退職とともに孤児化します。引き継ぎ資料は存在せず、口頭での説明も不十分で、気づいたときには「誰も中身を知らないが、止めると業務が回らないツール」が出来上がっています。
Excelマクロ時代に、どれだけ多くの企業がこの問題に苦しんだことか。そしてAIツールは、マクロよりも複雑で、マクロよりも多くのシステムと連携し、マクロよりも大量に生成されます。
暴走のリスク
もう一つ見過ごせないのが、ツールが「暴走」するリスクです。
現場担当者が作った自動化ツールが、想定外の条件下で大量のAPIコールを発生させ、連携先のシステムに負荷をかける。誤ったロジックで顧客データを一括更新してしまう。本番環境のデータを意図せず削除する。
IT部門が管理するシステムであれば、テスト環境での検証、段階的なリリース、ロールバック手順の整備といったセーフガードがあります。しかし現場で作られたツールには、こうした安全装置がないことがほとんどです。
経営者が取るべきスタンス——禁止ではなく、統制
では、経営者はどうすべきでしょうか。
「現場でのAI活用を禁止する」というのは、現実的でもなく、望ましくもありません。CursorやClaude Code、Codexといったツールは日々進化しており、これらを使いこなせる組織とそうでない組織の生産性の差は、今後ますます開いていくでしょう。開発の民主化がもたらす恩恵を、みすみす放棄することになります。
重要なのは、「どこまでを民主化の対象とし、どこからは統制下に置くか」の線引きを明確にすることです。
民主化を推奨する領域
個人の生産性向上ツールで自分だけが使うもの、一時的なデータ加工や分析、プロトタイピングやアイデア検証——こうした領域では、現場の自由な試行錯誤を奨励すべきです。むしろ、AIツールの活用スキルを高める機会として積極的に推進してもよいでしょう。
統制を維持すべき領域
一方で、基幹システムとの連携、複数部門にまたがるデータ処理、個人情報や機密情報を扱う処理、業務プロセスに組み込まれる自動化——こうした領域では、IT部門の関与と承認プロセスを必須とすべきです。
具体的な施策として考えられること
まず取り組むべきはポリシーの明文化です。どのような用途であればセルフサービスで開発してよいのか、どのような用途ではIT部門への相談が必要なのか、判断基準を明確にします。
インベントリの把握も重要な施策となります。現場で作られたツールを定期的に棚卸しし、存在と利用状況を把握する仕組みを作ります。完全な把握は難しくとも、「把握しようとしている」という姿勢自体がガバナンス上の意味を持ちます。
教育と啓発も欠かせません。現場の担当者に対して、「なぜ特定の領域では自由に作ってはいけないのか」を理解させることが重要です。禁止の理由が分からなければ、ルールは形骸化してしまいます。
IT部門のサポート体制の見直しも必要でしょう。現場のニーズに対して「ダメです」と言うだけでは、結局は隠れて作られるだけです。「こういう形なら実現できます」「ここまでは私たちがサポートします」という建設的な対応ができる体制を整えることで、現場との信頼関係を築きながらガバナンスを維持できます。
おわりに：歴史に学び、同じ過ちを繰り返さない
AIによる開発の民主化は、不可逆的な潮流です。CursorやClaude Code、Codexといったツールは今後もさらに進化し、より多くの人がより簡単にコードを生成できるようになるでしょう。この流れを止めることはできませんし、止める必要もありません。
しかし、私たちにはExcelマクロ地獄という歴史的な教訓があります。便利さの追求が、長期的には組織に大きな負債を残しうることを、私たちは経験から知っています。
生成AIは、Excelマクロよりもはるかに強力なツールです。それだけに、統制なき民主化がもたらす負の影響も、はるかに大きくなりえます。
経営者に求められるのは、この技術革新の恩恵を最大化しながら、組織が将来支払うことになるかもしれない「技術的負債」を最小化するバランス感覚です。
「便利だから」という理由だけで、基幹領域への野良ツールの浸透を放置すれば、5年後、10年後に何が起きるか。Excelマクロ地獄を経験した世代であれば、想像に難くないはずです。
いま、ルールと仕組みを整えておくこと。それが、AIによる開発民主化の恩恵を持続可能な形で享受するための、経営者の責任ある選択です。