バイブコーディングの普及とRPAの教訓から考える、シャドーAI時代の最小ガバナンス設計

IT管理部門が把握していない「シャドーAI（管理外ツール）」の急増が、いま多くの組織で新たなガバナンスの課題になっています。

背景にあるのは、生成AIやAIエージェントによる開発支援ツールの進化です。プログラミングやインフラの知識がない非エンジニアでも、AIに指示を出すだけでGAS（Google Apps Script）やPowerShell、簡易的なWebアプリなどを即座に作り、動かせるようになりました。感覚的に指示を出してコードを書かせる「バイブコーディング」の普及が、現場発のツールの量産を後押ししています。

しかし、個人主導で作られた「とりあえず動くツール」は、時間が経つにつれて深刻な運用負債へと変わります。典型的なのが、現場の社員が業務自動化のために作ったスクリプトが、本人の異動や退職で引き継がれないケースです。毎日動いてはいるものの、コードの仕様も動作原理も誰も知らないブラックボックスが生まれます。ある日突然APIの仕様変更などでツールが止まったとき、業務が麻痺するだけではありません。脆弱性や機密データの漏洩リスクを抱えたまま、誰の手にも負えなくなります。

非エンジニアの開発は現場の生産性を高める力を持っています。しかし野放しにすれば、属人化とブラックボックス化を招きます。現場のスピード感を損なわずに、組織としての統制をどう築くか。これが、現在のITガバナンスに問われている論点です。

TOC

• 本記事の結論
  • 1. 成果物の「重要度」に応じた統制レベルの分類
  • 2. 共同責任に基づく、ドキュメント化と台帳の維持
  • 3. 手動での最小スタートから「検知・監査」への移行ロードマップ
• 現場のスピード（アジリティ）を阻害せずに統制を維持できる理由
  • 1. 成果物の重要度に応じた分類統制
  • 2. 共同責任に基づくインベントリ維持
  • 3. 手動スタートからアンケート・ログ監査への移行ロードマップ
• 最小の手動運用から始める管理実務
  • 1. 重要度分類に基づく管理実務
  • 2. 台帳への共通登録項目（一律記入）
  • 3. 共同責任による共有スペースの運用と役割分担
  • 4. 段階的なシステム監査への移行ロードマップ
• 総括：インセンティブ設計に基づく協調的ガバナンス
  • 参考文献

本記事の結論

バイブコーディングで乱立するツールを、現場のスピード（アジリティ）を落とさずに統制するには、次の3点を組み合わせた管理モデルが効果的です。

1. 成果物の重要度に応じた統制レベルの分類
2. 共同責任に基づく、仕様のドキュメント化と台帳維持
3. 「手動の最小スタート」から「アンケートやログ監査による検知」への段階的移行

各項目の要点は次のとおりです。

1. 成果物の「重要度」に応じた統制レベルの分類

急増する自作ツールのすべてに一律の厳しいセキュリティ審査を課すのは、管理リソースの面から現実的ではありません。そこで、クレジットカード情報や決済データ、機密情報といったデータの性質や影響範囲に応じて重要度を分類します。個人のPCローカルで完結する低リスクなツールは現場の責任に委ね、機密データに触れる高リスクなツールにだけ監査リソースを集中させます。

2. 共同責任に基づく、ドキュメント化と台帳の維持

作成者本人しか仕様がわからない状態を放置すると、退職や異動の際にツールがブラックボックス化し、深刻な運用負債になります。これを防ぐため、役割を分担します。IT部門はソースコードを一元管理する共有ドライブなどの「指定格納領域」を用意し、現場の作成者はツールの「所有者・用途・停止時の代替手順」を共通のスプレッドシート台帳に登録する責任を負います。

3. 手動での最小スタートから「検知・監査」への移行ロードマップ

最初から大がかりなシステムを入れようとせず、まずは指定領域へのコード保存とスプレッドシート登録という「自己申告ベースの手動運用」からコストゼロで始めます。ツールが増えて未登録が目立ち始めた段階で、定期アンケートや既存の資産管理ソフト、プロキシログの簡易チェックなどを手動で組み合わせ、登録漏れを裏から補足・検知する体制へと段階的に移行します。

現場のスピード（アジリティ）を阻害せずに統制を維持できる理由

1. 成果物の重要度に応じた分類統制

現場の「目の前の業務を今すぐ効率化したい」という要望に対し、一律の利用禁止や過度なセキュリティ審査を課しても機能しません。KlotzらのシャドーIT研究（2019）¹が示すように、厳しすぎる制限は申請の手間を嫌った現場の「隠れ利用」を招き、IT部門からリスクの可視性を奪う結果になります。また、Cloud Security AllianceとZenityの共同レポート（2026）²が指摘するように、急増するツールすべてを手動監査するのはIT部門のリソース上不可能です。外部ホストへの過剰アクセス（DoSリスク）のような加害性も、ツールの性質で異なります。一方でEulerichらの研究（2022）³が警告するように、仕様変更を検知できず誤データを投入し続ける整合性リスクや、特権アカウントの悪用リスクも見過ごせません。

特にバイブコーディングで深刻なのは、認証情報やアクセス権限の管理不備です。GitGuardianによるシークレット漏洩実態調査（2025）⁴によると、AIコーディングアシスタントを有効化したリポジトリではシークレット漏洩率が6.4%に達し、全体平均（4.6%）と比べて40%高いことが報告されています。さらに、漏洩したGitHubトークンの96%（うち95%がフルアクセス権限）が過剰な権限を持っていました。非エンジニアが「動けばよい」と平文で書き込んだ認証情報から、クラウドアカウントの乗っ取りへと被害が連鎖する危険があります。OWASPの『LLMアプリケーションのTop 10（2025年版）』⁵も同様の警鐘を鳴らしています。過剰な権限付与による被害拡大（LLM06: Excessive Agency）や、生成コードを検証なしに実行する不適切な出力処理（LLM05: Improper Output Handling）が主要リスクに挙げられています。

したがって、扱うデータの性質や他システムへの影響度に応じて重要度を分類する必要があります。クレジットカード情報の有無、外部通信の有無、API権限のスコープなどが判断の基準です。個人のPC内で閉じる低リスクなツールは現場の責任に任せ、リスクの高い処理にだけ監査リソースを集中させる。この重要度の切り分けこそが、現実的な統制アプローチとなります。

2. 共同責任に基づくインベントリ維持

現場には、開発に伴う管理負担やインフラ保守の手間をできるだけ減らしたいという本音があります。しかしEulerichら（2022）³が指摘するように、仕様書のない自作ツールは退職や異動に伴って誰も保守できなくなります。「ドメイン知識の空洞化」による深刻な運用負債です。またZenity（2026）のレポート²が警告するとおり、稼働中のツールと所有者が可視化されていなければ、インシデント発生時の緊急停止や特権アクセスの漏洩に対処できません。

グローバル企業の市民開発プラットフォームを調査したHeuerら（2022）の実証研究⁶でも、同様の設計原則が提唱されています。IT部門による一方的な締め付けを避け、現場の自律性を保ちながらリスクを制御するには、次の3原則が有効だとされています。アプリの用途や影響度に応じた資産分類（DP1）、事業部門を意思決定に巻き込む共同統治（DP2: Co-governance）、そして安全なテンプレートの提供（DP3）です。

このトレードオフを乗り越える鍵が、運用の役割分担です。IT部門が共有ドライブなどの「コード置き場」を用意してインフラ保守の手間を引き受け、現場はスプレッドシートに用途や代替手順を1行書く。Klotzら（2019）¹やHeuerら（2022）⁶が提唱する共同ガバナンスモデルに倣い、この役割分担を徹底することで、現場の開発スピードを落とさずにツールを一元管理できます。

3. 手動スタートからアンケート・ログ監査への移行ロードマップ

自己申告だけに頼る登録ルールは、時間が経つと必ず形骸化します。Klotzら（2019）の系統的レビュー¹によると、セキュリティポリシーに違反している従業員の実に80%が、自身が違反している自覚を持っていませんでした。現場にとって「ルールを把握し、自発的に登録し続ける」こと自体の負荷が高いためです。

そこで、最初は現場の入力負担がもっとも軽い「スプレッドシートへの手動記述」だけで始めます。ツールが増えて手動登録の漏れが目立ってきた段階で、Klotzら（2019）の研究¹でも有効性が示されている定期アンケートを実施します。さらに、Lanscopeなどの資産管理ソフトによる開発端末のCSV抽出や、プロキシログによるAI APIへのアクセス監査などを手動で組み合わせます。現場の作業負担を増やさずに、台帳の漏れを裏から補正していくロードマップが効果的です。

最小の手動運用から始める管理実務

結論で示した管理モデルについて、実務における具体的な運用イメージを整理します。

1. 重要度分類に基づく管理実務

現場の社員が自作したGASやPythonスクリプトなどのツールは、次の基準で「低重要度」と「高重要度」に分け、それぞれに適した管理方法を適用します。

2. 台帳への共通登録項目（一律記入）

登録時の自己判断による漏れを防ぐため、台帳スプレッドシートへの登録項目は、重要度の高低にかかわらず例外なく以下の4項目で統一します。この内容をもとに、IT部門や管理者が客観的に重要度を判定し、監査を行います。

1. 作成者名・ツール名
2. コードの格納場所（共有ドライブ等のパス）
3. 用途（どのようなデータを扱い、どこに通信・アクセスするか）
4. 手動代替手順書（ツールが停止した際の手動業務手順）のリンク

3. 共同責任による共有スペースの運用と役割分担

開発スピードを落とさないための役割分担として、IT部門はコードの「指定格納領域（社内共有ドライブ内の専用フォルダなど）」と共通のスプレッドシート台帳を用意します。現場の作成者は、コードを指定領域に保存したうえで、台帳の4項目を記入する責任を担います。

4. 段階的なシステム監査への移行ロードマップ

運用のスタート時は、新たなツール導入などの追加コストをかけず、「フォルダ保存とスプレッドシートへの手動記述」だけで始めます。ツールが増えて手動登録の形骸化が目立ち始めた段階で、IT部門が既存のインフラ機能を活用した月1回程度の手動チェックを組み合わせ、監査を補強します。

• 自己申告アンケート (半年に1回): 「ローカルで動くPythonやPowerShell、Vercelなどの外部SaaSにデプロイしたツールがないか」を全社アンケートで尋ね、回答を回収して台帳を更新します。
• PC資産管理ソフトによる確認 (月1回): Lanscopeなどの既存ツールから「PythonやGit等の開発環境が入っている端末一覧」を抽出し、該当する非エンジニア社員へツールの有無を確認します。
• プロキシログのドメイン簡易監査 (月1回): 既存の通信ログから api.openai.com や vercel.app へのアクセス状況や、特定外部ホストへの過剰アクセスの有無を目視チェックします。未申請ツールの検知に加え、外部ホストへの意図しない過度なアクセス（DoSリスク）や不適切な通信を防ぎます。

総括：インセンティブ設計に基づく協調的ガバナンス

本記事で提示した「協調的アセット管理モデル」は、バイブコーディングによるツールの乱立に対し、現場の生産性を犠牲にせず組織のガバナンスを維持するための現実的な枠組みです。要点は次の3点に集約されます。

1. 重要度に応じた分類統制：扱うデータのリスクに基づいてツールを分類し、監査リソースにメリハリをつけて配分する。
2. 共同責任に基づくインベントリ維持：IT部門がコードの格納領域を提供する代わりに、現場は仕様や代替手順を台帳に登録する責任を担う。
3. 段階的なシステム監査への移行：最初は手動の自己申告から小さく始め、ツールの増加に合わせて資産管理ソフトやプロキシログなどの既存インフラを活用した検知体制へ移行する。

この仕組みを取り入れることで、現場の開発スピードを保ちながら、組織的な属人化負債やセキュリティリスクの蓄積を未然に防げます。

ツールの禁止や一律の厳しい制限は、ルールの形骸化とブラックボックス化を招くだけです。この結論は先行研究や各社のレポートでも一致しています（Klotzら 2019¹、Eulerichら 2022³、Heuerら 2022⁶、CSA・Zenity 2026²、GitGuardian 2025⁴）。ガバナンスの役割はツールを縛ることではありません。IT部門と現場が責任を分担し、持続可能なアセットのライフサイクルを整えることにあります。

参考文献