生成AIで社内システムを素人が作る前に｜情シスが見てきた7つの落とし穴と事故事例【2026年版】
「Cursorを使ったら、エンジニアじゃない自分でも動く社内ツールが作れた」「CopilotでExcelマクロから脱却してSaaS風の業務システムを作った」——2026年現在、生成AIで非エンジニアがコードを書ける時代が本格的に到来しています。
たしかに、これまで外注するしかなかった小規模ツールを、業務部門の担当者が数日で動くシステムにできるのは革命的な変化です。しかし、その裏側では情シスが把握していない野良システムの増殖、セキュリティ事故、作った本人以外誰も触れないブラックボックス化といった、新種の問題が各社で表面化しています。
本記事では、情シス担当者が実際に遭遇する 「生成AIで素人が作る社内システムの7つの落とし穴」 と事故事例、それでもAI活用を続けるための現実的な共存ルールを解説します。
この記事でわかること
- 2026年現在、なぜ「AIで素人がシステムを作る」が増えているのか
- 7つの落とし穴と、それぞれで実際に起きている事故事例
- AI生成コードを社内で安全に活用するための共存ルール
- 「プロのエンジニアが介在すべきライン」の判断基準
- 情シス部門が取るべき3つのガバナンス施策
目次
想定読者
本記事は、次のような方を想定しています。
- 業務部門が勝手にAIでシステムを作り始め、管理に悩む情シス担当者
- 生成AIでの内製化を推進中だが、リスクを整理したいDX推進担当者
- 「素人が作ったシステムで事故が起きたらどうする？」と経営層に問われている事業責任者
- 自分でも生成AIで業務ツールを作ってみたい非エンジニア
なぜ今「AIで素人がシステムを作る」が増えているのか
2024〜2026年にかけて、非エンジニアでもコードが書けるようになった背景には、3つの大きな変化があります。
| 変化 | 内容 | 代表ツール |
|---|---|---|
| AIコーディング支援の進化 | 自然言語で指示するだけで動くコードを生成できるように | Cursor、GitHub Copilot、Claude Code |
| ノーコード/ローコードの普及 | コードを書かずに業務アプリが作れる | Power Apps、kintone、Zapier |
| クラウドとSaaSの普及 | サーバー構築なしでサービスを動かせる | Vercel、Supabase、AWS Amplify |
その結果、業務部門の担当者が週末の数時間で以下のようなものを作れるようになりました
- 受注情報を自動集計するExcel連携ツール
- 顧客データをLINEに通知する業務Bot
- 簡易的な在庫管理Webアプリ
- 社内FAQ検索用のチャットボット
便利である一方、情シス部門が認識していない場所でシステムが量産されているのが2026年の実態です。
7つの落とし穴と事故事例
落とし穴1：情シスの知らないところで野良システムが量産される（シャドーIT化）
起こりがちな状況：
業務部門が独自判断でAIコーディングツールを使い、クラウド上に業務ツールをデプロイ。情シスは存在すら知らず、セキュリティレビュー・バックアップ・障害対応の対象から漏れる。
事故事例：
「営業部が勝手にSupabaseで顧客DBを作り、Claude Codeで管理画面を作って動かしていた。3ヶ月後、認証なしで全顧客情報が読める状態になっていることが判明した。」
リスク： 個人情報漏洩・コンプライアンス違反・退職時の引き継ぎ不能
落とし穴2：セキュリティ設計を知らないまま個人情報・機密情報を扱う
起こりがちな状況：
AIが生成したコードには一見動作するが、認証・認可・CSRF対策・SQLインジェクション対策が抜け落ちているケースが多い。作った本人はセキュリティ知識がないため気づけない。
典型的な抜け落ち：
- APIエンドポイントに認証がない（URLを知っている人は誰でもアクセス可能）
- パスワードが平文で保存される
- HTTPS化されていない
- CORS設定が
*（全許可）のまま本番稼働
事故事例：
「AIに『顧客情報の一覧画面を作って』と頼んだら動くページができたが、URLを知っていれば外部から閲覧可能な状態になっていた。」
落とし穴3：AIが古い・非推奨のベストプラクティスを提案する
起こりがちな状況：
生成AIの学習データには古い情報も含まれており、数年前は推奨だったが今は非推奨の技術や書き方を提案することがある。非エンジニアは「AIが言っているから正しい」と信じて採用してしまう。
典型例：
- 既に廃止された古いライブラリバージョンの使用
- セキュリティパッチが出ていない依存パッケージ
- クラウドサービスのIAM権限が過剰（AdministratorAccess相当を割り当て）
- バージョン管理されていないコードのコピペ
リスク： 脆弱性を抱えたまま本番稼働・将来のアップデート不可能
落とし穴4：動くけれど保守できないコードができる
起こりがちな状況：
AIが生成したコードは「動く」が、構造が整理されていない・命名規則が統一されていない・コメントが不足していることが多い。作った本人でも数ヶ月後に読めなくなる。
典型的な負債パターン：
- 同じ処理が複数箇所にコピペされている
- 変数名が
data,temp,resultなど意味不明 - エラー発生時の挙動が定義されていない
- テストコードが一切ない
事故事例：
「業務部の担当者がAIで作った集計ツールを、本人が退職後に別担当者が改修しようとしたら、コードの意図が読み取れず結局ゼロから作り直しになった。半年分の開発投資が無駄になった。」
落とし穴5：エラー処理が甘く、本番で事故が起きる
起こりがちな状況：
開発時は動いたが、例外的な入力・ネットワーク障害・データ不整合に対する処理が入っていない。本番運用で初めて問題が表面化する。
典型的な事故：
- 空欄入力でクラッシュ
- 重複登録を防ぐ仕組みがなく二重計上
- APIタイムアウト時の再試行処理がない
- ロールバック処理がなく、中途半端な状態でデータが残る
リスク： 業務停止・データ破損・顧客トラブル
落とし穴6：ライセンス違反・データベース設計の欠如
起こりがちな状況：
AIは既存コードを参考に生成するため、知らずにライセンス違反の可能性。またDB設計を学ばずにテーブルを作るため、正規化されていない・インデックスがない・スケールしない設計になる。
典型的な問題：
- GPLライセンスのコードを商用利用可能と誤認
- 1テーブルに大量のカラム（正規化違反）
- WHERE句で使う列にインデックスがなく性能劣化
- 文字コード・タイムゾーン設定が混在
リスク： 法的リスク・データ量増加で性能破綻
落とし穴7：作った本人が辞めると誰も触れない（新種の属人化）
起こりがちな状況：
従来の属人化は「特定のベテランしかシステムを理解していない」だったが、AI時代は「作った本人すら中身を把握していない」という新種の属人化が発生する。退職・異動で対応不能になる。
古典的な属人化 vs AI時代の属人化：
| 観点 | 古典的な属人化 | AI時代の属人化 |
|---|---|---|
| 原因 | ベテランが知識を抱え込む | AIが作ったので誰も中身を知らない |
| ドキュメント | 手書きメモで存在する可能性あり | 「AIに作らせただけ」で存在しない |
| 引き継ぎ | 本人から口頭伝達可能 | 本人も説明できない |
| 対処 | OJT・ドキュメント化 | ゼロから作り直すしかない |
事故事例：
「人事部の担当者がClaude Codeで勤怠管理ツールを作って運用していたが、本人が退職。後任が引き継ごうとしたら、本人も『AIに作らせただけで仕組みはわからない』と言い残して去った。結局、別ベンダーに依頼して1から作り直した。」
「うちでも社員が勝手にAIでシステムを作っている」「野良ツールをどう管理すべきか悩んでいる」——そんな場合は、まずは現状の棚卸しと運用ルール設計をプロと一緒に進めるのが近道です。
AI生成コードを安全に活用するための共存ルール
落とし穴を理解した上で、生成AIを全否定するのは現実的ではありません。むしろ活用しながら、安全に運用するためのルール設計が重要です。
ルール1：用途別の「許可範囲」を明文化する
すべてを一律禁止・一律許可にせず、用途・データの機微性で分類します。
| 用途 | 判断 | 根拠 |
|---|---|---|
| 個人の生産性向上ツール（個人フォルダ・自分のみ使用） | ⭕ 許可 | 業務影響が限定的・作った本人のみ責任 |
| 部署内の共有ツール（個人情報なし） | ⚠️ 条件付き許可 | 情シスへの事前届け出＋簡易レビュー必須 |
| 個人情報・顧客情報を扱うシステム | ❌ 原則不可 | プロエンジニアによるセキュリティレビュー必須 |
| 基幹システム・外部公開サービス | ❌ 不可 | 正式な開発プロセスで実装 |
ルール2：「届け出制」でシャドーIT化を防ぐ
情シスが把握できないシステムを減らすため、申告ベースでの届け出を義務化します。
- 誰が・何の目的で・どのツールで作ったかを登録
- 取り扱うデータの範囲・利用者数を申告
- 情シスは最低限のセキュリティチェックを実施（30分で完了するチェックリストで十分）
- 不備があれば指摘し、是正支援
ルール3：プロエンジニアによるスポットレビュー体制
AIで作ったコードは、本番稼働前にプロのエンジニアが30分〜1時間レビューするだけで、致命的な事故の大半は防げます。
- 認証・認可の実装確認
- SQLインジェクション・XSS対策の確認
- ライセンス・依存パッケージのチェック
- 最低限のエラーハンドリング確認
社内にエンジニアがいない場合は、外部パートナーとスポット契約（1回2〜5万円程度）でもレビュー体制を整えられます。
ルール4：技術的な「教育」ではなく「判断力」の教育
非エンジニアにコーディングを教える必要はありません。代わりに、「これはプロに頼むべきか自分でやってよいか」の判断基準を教えるのが効果的です。
- 顧客データを扱う → プロに相談
- 認証機能を入れる → プロに相談
- 外部公開する → プロに相談
- 個人用の集計ツール → 自分で試してよい
プロのエンジニアが介在すべきラインの判断基準
「どこからがプロの領域か」を明確にするため、以下の7項目のうち2つ以上該当するならプロのエンジニアに相談すべきサインです。
| # | チェック項目 | 該当 |
|---|---|---|
| 1 | 個人情報・顧客情報を扱う | □ |
| 2 | 社外の人がアクセスする（外部公開する） | □ |
| 3 | 3人以上が利用する | □ |
| 4 | 業務が止まったら影響が大きい（売上や生産に直結） | □ |
| 5 | データが失われると復旧困難（バックアップがない） | □ |
| 6 | 既存の基幹システムと連携する | □ |
| 7 | 年間100万円以上のコストをかけている | □ |
2つ以上該当 → プロのエンジニア（内製チームまたは外部パートナー）に相談
情シス部門が取るべき3つのガバナンス施策
施策1：野良システムの棚卸し（3ヶ月に1回）
各部門に「AIツールで作ったシステム・ツール」を自己申告してもらう調査を実施。想定より多くのシステムが稼働していることが判明することがほとんどです。
施策2：AI活用ガイドラインの策定・周知
「どこまでなら自分でやってよい・どこからはプロに相談」を明文化した1ページのガイドラインを作成し、全社に周知します。口頭説明だけでは伝わらないため、社内Wikiや稟議テンプレートに組み込むのが効果的です。
施策3：「気軽に相談できる窓口」の設置
プロに相談する心理的ハードルを下げるため、情シス・外部パートナーへのカジュアル相談窓口を用意します。
- Slackの専用チャンネル（例：#ai-tool-consultation）
- 月1回のドロップイン相談会
- 外部パートナーとのスポット契約（30分5,000円など低額）
よくある質問
Q. 業務部門が勝手にAIでシステムを作るのを全面禁止すべきですか？
A. 全面禁止は逆効果です。禁止しても隠れて使われるだけで、シャドーIT化が悪化します。代わりに用途別の許可範囲＋届け出制で、情シスが把握できる仕組みを整えるのが現実的です。個人の生産性向上ツールは許可しつつ、顧客データを扱うシステムはプロの介入を必須にする、という線引きが有効です。
Q. すでに野良AIシステムが部署内で大量に動いています。何から手をつけるべきですか？
A. 棚卸し → 分類 → 高リスクから対処の順です。まず全部署にアンケートで自己申告を求め、一覧化します。その中で「個人情報を扱う」「外部公開している」「3人以上が利用」に該当するものを優先的にセキュリティレビューし、問題があれば再実装または停止を判断します。一気に整理しようとせず、リスクが高いものから順に対処してください。
Q. 生成AIで作ったコードを、情シスが全てレビューするのは人的に無理です。
A. 全件レビューは不要です。届け出で上がってきたもののうち「用途別の許可範囲」で条件付き・原則不可に分類されたものだけをレビュー対象にします。個人の生産性向上ツールは対象外とし、リスクの高い領域だけに集中すれば、月数件のレビュー工数で済みます。
Q. AI生成コードのセキュリティレビューを自社でできる人がいません。
A. 外部パートナーとのスポット契約が現実的です。「AIで作ったコードの30分レビュー」というメニューを用意している開発会社・セキュリティ企業もあります。1件5,000〜30,000円程度で、致命的な事故を防げる費用対効果の高い投資です。
Q. 生成AIを使った開発は、今後なくなることはないですよね？
A. はい、不可逆な流れです。禁止ではなく共存が前提になります。ただし、「動くもの」と「本番運用に耐えるもの」の間には大きな差があり、そのギャップを埋めるのがプロのエンジニアの役割です。完全外注か完全内製かの二元論ではなく、どこまで自分で・どこからプロにの線引きを企業ごとに設計することが、2026年以降のシステム開発の標準です。
まとめ
本記事のポイントをまとめます。
- 2026年の現実：生成AIで非エンジニアがシステムを作れる時代。便利な一方で7つの落とし穴がある
- 7つの落とし穴：シャドーIT化・セキュリティ欠如・古いベストプラクティス・保守不能コード・エラー処理甘い・ライセンス/DB設計欠如・新種の属人化
- 共存ルール4点：用途別許可範囲・届け出制・スポットレビュー・判断力教育
- プロ介入ライン：7項目中2つ以上該当でプロ相談必須
- 情シスのガバナンス施策：棚卸し・ガイドライン策定・相談窓口設置
「素人がAIで作ればすべて解決」でも「禁止してすべてプロに任せる」でもなく、企業ごとの線引き設計が重要です。この線引きは、戦略的なシステム投資判断と同じく、社内だけで決めるのは難しい場合が多いため、実績あるパートナーと一緒に整理するのが近道です。
c3index に相談する
シースリーインデックスは、受託開発・AWS導入・保守運用に加え、生成AI時代の社内システムガバナンス設計にも対応しています。「野良AIシステムの棚卸しをしたい」「AI活用ガイドラインを作りたい」「プロのセキュリティレビューをスポットで頼みたい」——そうしたご相談にも対応しています。
業務部門が自由に使える領域と、プロが介在すべき領域の線引き設計から、既存AIツールの安全性レビュー、必要に応じた本格的なシステム刷新まで、一貫してサポートいたします。まずはお気軽にお問い合わせください。
