Vibe Coding 時代の AI ガバナンス：シャドーIT がシャドーAI になるとき

2026 年 5 月、イスラエルのセキュリティ企業 RedAccess が、vibe coding で作られ公開状態でネット上に置かれていたアプリを 38 万個スキャンで発見しました。そのうち約 5,000 個には本物の企業機密が載っていました。ブラジルのある銀行の資金フローデータ、英国のある臨床試験の患者記録、ある病院の医師と患者の会話および職員シフト表、ある学校の授業録画と生徒の個人情報です。これらのアプリは Lovable、Replit、Base44、Netlify といったプラットフォーム上で動いていました。Axios の報道によれば、その大半はハッキングされたわけではなく、プラットフォームが既定で公開設定になっており、誰も手動で非公開に切り替えなかったため、検索エンジンにそのまま収録されてしまったのです。

これらのアプリを作った人たちの多くは、自分が何かを漏らしてしまったことに気付いていません——これこそが AI 時代のシャドーIT です。この言葉はいったん置いておき、後ほど詳しく説明します。

---

カメラを少し近づけて、もっと日常的なバージョンを見てみましょう。

月曜日の朝 10 時、情シス責任者の田中さんに 1 本の電話がかかってきました。

会社の会員キャンペーン用ページが落ちている。顧客は決済を完了したのに確認メールが届かない。田中さんはダッシュボードを開いてログを追おうとしましたが、そこにそのサービスは存在しません。社内をひと回り問い合わせて、ようやく判明します。先週マーケティング部門が Cursor で書き上げ、誰かの個人クラウドアカウントで稼働させていたものだった、と。

この瞬間から、田中さんの仕事は変わりました。

これは特殊な事例ではありません。シャドーIT（従業員が正式な IT プロセスを迂回して、自分でツールを採用したりシステムを自作したりすること）はずっと存在してきました。けれども AI ツールがマーケティング、営業、人事の担当者にまで本番アプリを自前で書く力を渡したことで、その尺度は「従業員が勝手に SaaS を契約する」段階から「従業員が勝手にバックエンドを 1 セット動かす」段階へと一気に跳ね上がり、旧来の情シス向けツールキットでは、もうこの量には追いつきません。本稿が扱うのは、まさにこの新しい難題です。シャドーIT がシャドーAI になるとき、企業のセキュリティ境界はどう移動するのか。そして最前線で板挟みになる情シス担当者（中小企業や伝統産業では MIS、情報システム責任者とも呼ばれ、会社の規模によっては CIO とも呼ばれます）は、それをどう受け止めればいいのか。現象、原因、そして実際に使えるガバナンス・フレームワークまでを通して見ていきます。

先に本稿の範囲をはっきりさせておきます。AI ガバナンスはより上位の範疇で、モデルリスク、AI 利用ポリシー、Human-in-the-Loop、責任の帰属はすべてその中に含まれます。本稿が焦点を当てるのはそのうちの 1 つ、しかも最近もっとも速く表面化してきた 1 つです。vibe coding がシャドーIT をシャドーAI に変えたあと、企業のセキュリティ境界はどう移動するのか。現象、原因から、実際に使えるガバナンス・フレームワークまでを扱います。他のいくつかの層は、別稿で扱います。

TL;DR

• フレームワーク：AI ガバナンスの 3 つの層、可視性 → 境界 → 監査。順序が大事で、飛ばすと土台から崩れます。
• 主張：サンドボックスは新しい企業境界防御。vibe coding を禁止せず、情シスから見える場所に収めましょう。
• 3 ステップ：いま何が動いているか棚卸しする → 許可されたワークスペースを 1 つ開く → 監査のリズムを定める。

Vibe Coding 時代のシャドーAI：なぜ過去のシャドーIT より十倍深刻なのか

「シャドーIT」は新しい言葉ではありません。ガートナーが 2010 年代にこの現象を専門用語化しました。情シスにとってはガバナンスの死角ですが、従業員にとっては「仕事を片付けるため」の合理的な選択であることが多く、双方それぞれに言い分があります。長く積み上がると、会社のデータ・プロセス・権限が情シスの見えない場所に散らばっていきます。

10 年前のシャドーIT は、従業員が勝手に Notion を使ったり、自腹で Slack を契約したりするものでした。情シス担当者の仕事は、SaaS の調達申請を審査し、acceptable use policy を書き、定期的に棚卸しを走らせることでした。痛点は「データが正しくない場所に散らばる」ことでしたが、その場所は少なくとも有名な SaaS でした。背後には SOC 2 報告書があり、SLA があり、サポート窓口がありました。

シャドーAI は、シャドーIT の AI 時代版です。根っこの問題はまったく同じで、従業員が機微データを、第三者の・IT が未審査のサービスに置く、ということです。本当に変わったのは、その「第三者」の性質です。かつては出来合いの SaaS でしたが、いまは vibe coding プラットフォームや、従業員が自分で組んだバックエンドとデータベースです。容れ物が「監査済みの有名サービス」から「誰も管理しない自作システム」に変わったのですから、リスクの桁も自然と別物になります。並べて比べてみましょう。

最も決定的な違いは「可制御性（コントロール）」です。かつてはデータをうっかり Notion に置き、権限を閉じ忘れ、外部の人がページを開いてしまったとしても、権限を閉じ、ページを消せば、リスクはおおむね止血できました。けれどもシャドーAI は、機微データを生きたシステムに「接続」します。対外エンドポイントが 1 つ破られると、攻撃者は芋づる式に、その裏につながったデータベース・API・他の社内データまで引き出せます。ページを 1 枚消しても元には戻りません。冒頭の流出した 5,000 個のアプリは、まさに既定で公開され、検索エンジンに次々と回収されていったものです。

この現象は思っているよりも普遍的です。いくつかの数字を重ねて見るとわかります。

• 40% 以上の企業が 2030 年までにシャドーAI のセキュリティ／コンプライアンス事故に直面する（ガートナーの予測）。
• 71% の従業員が未承認の AI ツールを使ったことがあり、51% は毎週使っている（Microsoft UK の 2025 年 10 月調査）。
• 本当に定期的に AI を使っている現場従業員は半数のみ。GenAI が手に入ることと（成熟した産業では 7 割の従業員が、未成熟な産業では半数未満）、手に入れて実際に使うことは別の話です。BCG の 2025 年 9 月『The Widening AI Value Gap』（回答者 1,250 名）は、「手に入る vs 実際に使う」というこのギャップを「silicon ceiling（シリコン天井）」と呼びます。

規律的に AI を使っているのが半数だけだとしても、その半数がすでに、情シスから見えないシャドーAI を積み上げています。

vibe coding はこのゲームを変えました。従業員のやることが一段階アップグレードし、「SaaS を契約する」から「自分でバックエンド＋データベース＋API を 1 セット動かす」になったのです。AI ツール（Claude Code、Cursor、GitHub Copilot）は「コードを書く能力」をエンジニアから全員へと拡散させましたが、「本番を動かす責任」はそれに付いて拡散しませんでした。書けることは、次のことを知っていることを意味しません。

• シークレットをリポジトリに書き込んではいけないこと。
• バックアップは自動では走らないこと。
• トラフィックが 10 倍になったときには、まず何かしらの手を打つ必要があること。

結果として、会社は知らないうちに、何のガバナンス記録もない本番サービスを 10 から 30 個積み上げます。それらは顧客データを集め、メールを送信し、社内 ERP を叩いている——なのに情シス担当者は、その名前すら答えられません。このツールの民主化とセキュリティのあいだの綱引きは、vibe coding ガバナンスが避けて通れない根底の緊張です。

旧来のセキュリティ境界は、なぜ vibe coding の成果物を守れないのか

シャドーAI がここまで大きくなった背後には、同時に進行する 3 つの力があります。どれもが、旧来の情シスの防衛線（ファイアウォール、IDP）では従業員の成果物を守れなくしています。

デプロイの敷居がゼロに、可視性の喪失

Lovable、Bolt、v0、Replit Agent、Claude Code はいずれも「書き終えたらそのままプラットフォームのサンドボックスで動く」を既定動作にしました。Dockerfile を書かず、サーバーを設定せず、アカウントも申請しない。従業員にとっては大変ありがたいことですが、情シス担当者にとっては可視性の全面崩壊です。プロセスを通さない本番アプリが会社に何個あるのか、誰の個人アカウントで動いているのか、支払いのクレジットカードは誰のものか、把握できません。

AI が使えるものを作るには、本物の社内データが要る

vibe coding のアウトプットがデモから実際に使えるものへ進化するには、AI に本物のコンテキスト（顧客名簿、注文記録、過去の問題の解法、社内 wiki）を与える必要があります。多くのコンテキストを与えるほど、AI が書くものは場面に合います。けれどもデータを与えれば、脱秘／プライバシー／コンプライアンスの責任に向き合うことになります。与えなければ、従業員は「ない袖は振れず」、アウトプットは「動くように見えるが場面に合わない」玩具版にとどまります。

エージェントと従業員の自走システムが、旧来の認証境界を迂回する

Anthropic の Computer Use（2024 年 10 月）、OpenAI の Operator、Devin などは、エージェント自身がキーボードとマウスを動かしてコードを書き、デプロイすることを可能にしました。従業員の AI アプリも、IDP（identity provider — 認証基盤）を通らないシステムを勝手に立ち上げることがよくあります。SaaS 時代は IDP で「誰がどのシステムにログインできるか」を管理していました。いまや新しいアクター（エージェント）と新しいサーフェス（従業員が自分で立ち上げた本番アプリ）が、揃ってそれを迂回しています。

Deloitte の 2026 年『State of AI in the Enterprise』報告 は、自律 AI エージェントに対して成熟したガバナンスモデルを持つ会社は 5 社に 1 社（20%）のみと指摘し、方向性も直接示しています。「Effective governance integrates with existing risk and oversight structures, not parallel 'shadow' functions（実効的なガバナンスは並行する『シャドー』機能ではなく、既存のリスク管理と監督の構造に統合される）」。つまりガバナンスは既存のリスク構造に統合すべきで、並行するシャドー機能を別に立てるものではない、ということです。

この 3 つの力が、「企業のセキュリティ境界」の定義そのものを変えました。新しい境界はどこに引かれるべきか、なぜその答えが「サンドボックス」を指すのかは、後の節で専門に展開します（この言葉も、いったん置いておきます）。

シャドーAI が制御不能になる 3 つのシグナル：可視性・境界・監査の危機

情シス担当者が次の 3 つを口にし始めたら、シャドーIT の問題はもう動くべきタイミングに達しています。

シグナル 1：可視性の危機

「うちの会社で、いま何個のアプリが動いているのか分からない」

従業員の AI アプリは、別々のアカウント、別々の個人カード、別々の PaaS に散らばっています。情シスには一覧がなく、何かが起きるたびに最初に呼ばれるのは情シスですが、当の本人はそれが何という名前なのかすら知りません。

シグナル 2：境界の危機

「来週退職する社員が作ったものに、どの会社データが使われているのか分からない」

従業員が顧客データベースの接続文字列を AI に見せ、コードに書き込み、自分の個人アカウントで動かしています。その人が去るとき、会社にはこれを引き継ぐ仕組みがなく、アクセス権を回収する手段もありません。

シグナル 3：監査の危機

「年末に監査を通さないといけないのに、これらは自分の管轄外にある」

ISO 27001 や Pマーク（プライバシーマーク）の更新審査、SOC 2、J-SOX。監査員はサイクルごとに同じことを尋ねます。「アクセスログは？バックアップは？変更記録は？誰が変更でき、誰が閲覧できるのか？」情シス担当者には答えがありません。

企業 AI ガバナンスのジレンマ：導入とリスク管理に挟まれる情シス

まず 1 つベースラインの数字を見ましょう。マッキンゼーの 2025 年『The State of AI』グローバル調査（105 か国・1,993 名の回答者）によれば、88% の組織がすでに少なくとも 1 つの業務職能で AI を定期的に使っていますが、全社レベルの AI ガバナンス委員会を設置しているのはわずか 18% です。つまり 8 割以上の会社で、従業員はすでに AI を使っているのに、ガバナンス構造はまだ育っていないということです。情シス担当者のジレンマは、まさにこの落差から生まれます。

情シス担当者の苦境を理解するには、まず上の 2 層の圧力を見る必要があります。

経営層の視点：AI 導入の焦り

2025〜2026 年のこの 2 年間、ほぼすべての経営者が AI 焦りに駆られています。同業がやっている、競合がやっている、メディアが追いかける、従業員が尋ねてくる。本能的な反応はトップダウンの要求です。「来年は AI-first だ」「各部署が AI アプリを 1 つ出せ」「AI を使えない部署は再評価する」。狙いは会社が動いて見えること、淘汰されないことです。けれどもトップダウンの推進と本当の導入のあいだには、1 つの溝が口を開けています。

Duolingo は、その溝が公然と露呈した代表例です。2025 年 4 月 28 日、CEO の Luis von Ahn 氏は LinkedIn で「AI-first」戦略を発表しました。AI が代替できる契約社員を段階的に縮小し、「AI を使えること」を採用条件と業績評価に組み込む方針です。TechCrunch の報道によれば、発表のわずか 2 日後に同社は 148 もの AI 生成コースを公開しました。12 年分のコース開発量を 1 年弱に圧縮した形です。コミュニティの反発は瞬時に爆発しました。受講者はサブスクリプションを解約し、アプリを削除し、TikTok でレビュー爆撃が起きました。Duolingo はすべての TikTok／Instagram 投稿を削除し、全体としてしばらく沈黙に入りました。約 4 週間後、von Ahn 氏は LinkedIn で先の発言を公に撤回し、Fortune は彼の原文を引用しています。「I do not see AI as replacing what our employees do（AI が社員の仕事を置き換えるとは考えていない）」と述べ、採用も従来のペースを維持すると表明しました。Q2 2025 の決算説明会でも、この AI 発言が DAU 成長を予想下限（40% YoY、前年同期は 60%）まで落とした一因だと自ら認めています。

この筋書きは、多くの会社がトップダウンで AI を推すときに繰り返し現れます。Fortune の報道によれば、Klarna が AI でカスタマーサポート 700 名を代替し、半年後に再び人を雇い直したのも、同じ脚本です。

私自身がよく持ち出す一言があります。

使えるようになることは導入することではなく、導入できることは現場で使えることを意味しません。—— Ling Wu

従業員が毎日 Cursor を開いたとしても（それどころか昼食に何を食べるか尋ねていたとしても）、会社が本当に AI をワークフローに導入したことにはなりません。たとえ本当にそれでいくつか小さなシステムを作れたとしても、多くの会社にはまだ、「AI で本当に生産性が上がったのか」を測る物差しがありません。あいだにある 2 つの溝（「treatment vs deployment」「deployment vs utilization」）は、どちらも詰まります。

情シスの視点：リスク管理と柔軟性のジレンマ

このサンドイッチ構造の中で、情シス担当者は経営層の「AI-first にしろ」という要求（導入を押す）に応えながら、同時に vibe coding の蔓延というガバナンスリスクを管理しなければなりません（安定を守る）。これは enable と control を同時にやる仕事です。どちらか一方が多すぎるとひっくり返ります。

対応する 2 つの極端な反応は、どちらも両側を挟みきれていないバージョンです。

反応パターン 1：封殺

「以降、社員が自分で AI でアプリを作るのは禁止、すべて IT 申請プロセスを通せ」。結果として、皆に自分の手を縛るツールを強いることになります。情シスが許可するツール群は、外で builder が使っている能力より一段見劣りすることが多く、従業員が本当にやりたいことができません。従業員は情シスが反対したからといって止まりません（経営層が「皆 AI で効率を上げろ」と言ったばかりです）。だから作り続け、もっと見えにくい場所に置きます。封殺は可視性の危機を地下化の危機へと拡大させ、しかも情シス担当者を経営層の目に「AI を推進できないボトルネック」として映します。

反応パターン 2：放任

「どうせ監査はまだ先だ、とりあえず放っておこう」。とりあえず放置しても、放置するうちに問題は自分で大きくなります。フロントエンドのフレームワークやデータベースの選定に詳しくない同僚たちが、それぞれにツールを選びます。3 人で 3 種類の異なるフレームワーク、4 種類の異なるデータベースを使うかもしれません。10 のシステムが同時に育ち、会社の手元には誰かが片付けるのを待つ、順列のように積まれた tech stack の山が残ります。監査員が本当にドアを叩くとき、情シス担当者が背負うのは監査の悪夢だけではありません。当初放任して処理しなかった tech stack の順列まで一緒に爆発します。

サンドイッチの痛点をはっきり書きましょう。経営層は導入が動いているかしか見ず、従業員は自分が書いたものが動くかしか気にせず、リスク（データ流出、コンプライアンスの破れ目、監査の失敗）とシステム管理の「負債」（誰が直す、誰がバックアップする、誰がツールを入れ替える）は、そのすべてが情シス担当者 1 人にのしかかります——あなたが何を背負っているかは、誰も気にしません。

正しい方向は第三の道です。AI のアウトプットを情シスから見える環境に収めつつ、従業員が作り続けるのは止めない。言い換えると、サンドボックスは新しい企業境界防御になる（英語圏では「sandbox is the new perimeter」と一言で表現されます）。

この切り口の下では、情シス担当者は enable（従業員が AI を使い続ける）と control（情シスが見えて管理できる）を同時に成立させます。経営層のトップダウンに応えつつ、ガバナンスリスクを解き、従業員の日常ワークフローも中断されません。サンドボックスとは結局のところ何なのか、なぜこの 1〜2 年でようやく企業境界防御の既定の答えになったのかは、後の節で専門に説明します。

Vibe Coding ガバナンス・フレームワーク：可視性・境界・監査の三層

vibe coding ガバナンスを真剣な企業レベルの課題として扱うために、業界にはすでにこの課題を扱ういくつかの既存スタンダードがあります。

• NIST Cybersecurity Framework 2.0（2024）— 6 つの functions：Govern、Identify、Protect、Detect、Respond、Recover。リスク識別から事故対応までの完全なサイバーガバナンス・ライフサイクルをカバーします。
• NIST AI Risk Management Framework（NIST AI 100-1, 2023）— 4 つの functions：Govern、Map、Measure、Manage。AI リスクを企業リスクとして統治するための基準です。
• ISO/IEC 42001:2023 — 最初の国際 AI マネジメントシステム標準で、ISO 9001／ISO 27001 などの既存 ISMS フレームワークと整合しています。

これらのスタンダード同士がどう整合するか、中小企業はどこから着手すべきか、実装上どんなトレードオフがあるか（quality gate、operational debt、technical debt、paved path といった AI ガバナンス用語を自社プロセスにどう当てはめるか）は、別稿で完全に分解します。

本稿では、上記のスタンダードを 3 層に要約し、vibe coding の場面で問題を素早く識別できるフレームワークにします。visibility、boundaries、audit の 3 つです。順序が大事です。各層が解く問題は別物だからです。

第 1 層：可視性（visibility）

一番基本の作業は、すべての AI アプリを 1 つの場所に集めて見ることです。1 つの請求窓口、1 つのダッシュボードで全デプロイを把握し、1 つの監査ログで誰が何を変更したかを記録する。

具体的にやるべきことは、従業員に許可された環境（会社が支払うワークスペース、会社が管理するアカウント）を 1 つ与え、彼らの AI アプリをここへデプロイするよう促すことです。従業員は vibe coding を続け、情シスは見られるようになります。可視性が無ければ、後の 2 層は成り立ちません。

国内にも先行事例があります。メルカリの engineering blog は、200 以上のマイクロサービスを抱える社内開発を Platform チームの共通基盤に集約してきた経緯を共有しています。技術組織の話ではありますが、「現場の自走範囲を広げつつ、土台は中央が見える形で握る」発想は、情シスがシャドーAI を見える側に集める設計と同じ向きを向いています。順序ははっきりしています。まずデータと環境を見える形にしてから、AI アプリが接続できる。vibe coding ガバナンスの第 1 層も同じロジックで、まず見える環境があって初めて、後の enable に意味が出ます。

実際の画面に落とすとこうなります。田中さんは会社の IT ワークスペースを開き、まず 12 個のサービスが並んでいるのを目にします。marketing-membership-page（マーケティングが作り、先週担当者が env var を変更）、hr-interview-scheduler（人事が作り、アジア地域で稼働、今月 2.3 GB 使用）、sales-customer-cleanup（営業が作り、すでに 2 週間デプロイなし）……そのどれにも owner、last deploy、region、cost があります。田中さんは誰にも尋ねる必要がなく、ダッシュボードが「いま何が動いているか」に直接答えます。

第 2 層：境界（boundaries）

可視性は「何が動いているか分からない」を解決し、境界は「何に触れているか分からない」を解決します。

具体的にやるべきことは、3 つです。

• 環境分離：dev／staging／production の各環境が独立した権限を持ち、実験が誤って本番データに触れることはない。
• 共用シークレットマネージャー：認証情報は管理された 1 箇所に保管され、AI は参照は持つが平文には触れない。
• 席（シート）回収の自動化：従業員が去るとき、すべてのアクセス経路をワンクリックで回収でき、5 つの PaaS ダッシュボードでモグラ叩きをしなくて済む。

従業員の AI アプリは社内データに接続できますが、認証情報が AI のプロンプトに読み込まれることはなく、従業員が去るときにアクセスは自動で断たれます。

実際の画面に落とすとこうです。先週退職した担当者がかつて作った customer-feedback-collector が、彼自身の GitHub OAuth アカウントで動いていました。田中さんはワークスペースで「collaborator を削除」を 1 回押します。このサービスの prod 環境は自動で「未認領（unclaimed）」に切り替わり、アクセス経路はすべて回収され、課金は会社の主アカウントに帰属します。人事は退職者に何かを追いかける必要がありません。

第 3 層：監査（audit）

監査ログは誰が何をデプロイしたか、誰が env var を変更したか、誰がログを見たかを記録します。リソース所有者は「このサービスは誰のものか」に答えを与えます。デプロイ履歴は、変更記録を従業員自身が保存しなくてもよくします。

この層が解決するのはガバナンスの面だけで、コンプライアンス認証そのものは解決しません。顧客が SOC 2／ISO 27001／Pマーク／業界別コンプライアンスを通したいとき、プラン組み込みのツールを監査フレームワークにマッピングする作業が必要です。これは通常コンサルタントやガバナンス審査を要する仕事で、PaaS が担うべきことではありません。

日本の金融業界にも対応するフレームワークがあります。金融庁が公表してきた AI 活用に関する監督指針やディスカッションペーパーは、AI のライフサイクルを段階に分け、それぞれに対応する原則を示しています。銀行・保険業の情シス担当者にとっては直接あなたに向けて書かれたものであり、他業種にとっても早期の参考になります。けれども監査が求める「誰がどの段階でどんな判断をしたか」は、PaaS の監査ログでは半分しか解けません。残りの半分は、プロセスを現場に落とし込むことに頼ります。

具体的なシナリオを 1 つ。ある社員が自前で組んだワークフロー（Claude Code で書いた小さなツール＋n8n で社内 wiki API を叩く）で、顧客向けの回答内容を自動生成しようとします。AI の精度を上げるため、社内 wiki のデータをプロンプトに引き込みます。けれども社内 wiki のデータは完全には脱秘されていません。人員名簿、提携金額、過去のクレーム履歴がそのまま残っています。AI は「どれが公開してよく、どれが駄目か」を自発的には判別しないため、一部のプライバシー情報が「顧客に見せる回答」に紛れ込んで公開されてしまいます。

このシナリオの当責／訴訟の問題はひとまず脇に置きます。監査層の本当の核心はプロセス設計です。AI が機微データに触れる節点に、検査ポイントを置いているかどうか。監査員が来たときにログを出せるのは基本中の基本。プロセス設計こそが、本当に守っているものです。AI 時代には、次の公的ガバナンス事件がいつ現れるか誰にも分かりません。三層ガバナンスを段階的に実装していくことが、この種のリスクを「災害」から「早期に止められる小さな事故」へと変える鍵です。

具体的なやり方の 1 つは、最初の関門を従業員側に押し出すことです。デプロイの前にまずシークレットスキャン、機微データの漏出経路チェック、依存関係への警告を一通り走らせ、従業員が自分で塞ぐ。情シスが引き継ぐのは、すでに第一関門を通過した成果物です。市場にはすでにこの関門を自動化したサービスが少なくありません。検査ポイントをどう設けるか、Human-in-the-Loop をどう打ち立てるかは、別稿の主題です。

visibility → boundaries → audit の三層を並べると、解いているのは異なる層の問題ですが、この 3 つにはひとつ共通の前提があります。それらが落ち着くための、情シスが見えて管理できる容器が必要だということ。前出の《企業 AI ガバナンスのジレンマ》でこの答えに触れました。サンドボックスは新しい企業境界防御になる、というものです。次節では、なぜこの答えがこの 1〜2 年でようやく浮上したのか、何が変わったのかを展開します。

シャドーIT の新しい企業境界防御：サンドボックス

ここまで「サンドボックス」をずっと答えとして放り投げてきましたが、ここで正式にそれが何なのかをはっきりさせます。

この概念は、実は新しいものではありません。ブラウザにはサンドボックスがあり（Web ページはローカルファイルにアクセスできない）、iOS にはサンドボックスがあり（各アプリは自分のデータしか触れない）、各種プログラミング言語のランタイムも独自の隔離設計を持っています。少なくとも 10 年は遡れます。新しいのは、この 1〜2 年でそれが IT ガバナンス議論の中心に押し上げられ、企業境界防御の既定の答えになったことです。前述の 3 つの力（デプロイの敷居がゼロに、AI が本物のデータを求める、エージェントが IDP を迂回する）が、旧来の防衛線を打ち抜いたからです。

サンドボックスは、この 3 つの力に対する共通の解です。従業員は相変わらず敷居ゼロでデプロイしますが、情シスが見えるサンドボックスの中で動かします。AI はサンドボックス内で準備されたデータの切片だけを見て、機微フィールドはデータがサンドボックスを出る前に処理し終えるので、情シスがプロンプトを 1 件ずつ審査する必要はありません。サンドボックスはエージェントの動作と従業員のシステムを同時に収め、統一された実行境界として機能します。E2B、Daytona、CodeSandbox SDK、Modal、Beam など、エージェント・サンドボックス専業の企業が過去 12 ヶ月で一気に台頭してきたのは、まさにこのギャップを見たからです。

サンドボックス自体は、どこで動かすのか？

サンドボックスの着地には 3 つの選択肢があります。プラットフォーム内蔵のサンドボックスを使う、完全に self-host する、マネージドサンドボックス（PaaS モデル）を使う、の 3 つです。サンドボックスが答えだと認めるのは第 1 歩にすぎません。サンドボックス自体をどこで動かすか、誰が運用するか、壊れたとき誰が直すかは、2026 年にすべての情シス担当者が評価している選択問題で、3 つの道それぞれにトレードオフがあります。

• プラットフォーム内蔵のサンドボックスを使う（Lovable／Bolt／v0 などの既定）：シンプルですが、データと成果物がベンダーに紐づき、情シスはインベントリを取り出せず、支払いはたいてい従業員の個人カードのままです。
• 完全 self-host：技術的には制御可能ですが、専任のインフラ担当を 1 組抱えて維持する必要があります。従業員は情シスのプロセスを避けるために vibe coding しているのに、情シスは vibe coding をサンドボックスに囲い込むためにシステムを 1 セット余計に管理することになり、コストが安いとは限りません。
• マネージドサンドボックス（PaaS モデル）：自分が欲しいクラウド、リージョン、データ主権の範囲を選びつつ、運用はプラットフォームに任せます。

この選択は先送りできません。従業員の vibe coding はあなたを待ってくれません。

前述の 3 つの力を 1 枚に重ねて見ると、企業のセキュリティ境界の定義は実は一貫して移り変わってきたことが見えてきます。2000 年代以前はファイアウォールの時代で、守るべきは「誰が会社ネットワークに入れるか」でした。2010 年から 2024 年にかけては IDP／SaaS に移り、「誰がどのシステムにログインできるか」を守るようになりました。そして 2024 年以降、vibe coding の時代に入ると、守るべきものは「従業員とエージェントの成果物がどのサンドボックスで動くか」へと変わったのです。

このサンドボックスは、従業員の自由のまわりに「情シスから見える範囲」を描きます。従業員（と従業員が立ち上げたエージェント）はその内側で vibe coding を続け、情シスはコードをレビューせず、ツールを禁止せず、従業員の作ったものをやり直しません。情シスが維持するのはこのサンドボックスそのもの、つまりそれがどこにあり、誰が入れて、何が動いていて、どれだけ消費しているか、です。

この切り口は情シス担当者にとって解放です。彼の役回りが「従業員が X をするのを止める」から「従業員が X をできる場所を渡す」へと反転します。前者は彼をボトルネックにし、後者は彼を enabler にします。同じ情シス担当者で、違いは彼がどちらの線を守るかを選ぶことだけです。

情シスが vibe coding ガバナンスを着地させる 3 つのステップ

あなたが情シス担当者で、会社が vibe coding 段階に入り始めたばかりなら：

第 1 ステップ：棚卸しを 1 度走らせる。各部署に「最近 AI を使って何か作って動かしているものはありますか？」と尋ねます。結果はたいてい人を驚かせます。書き留めてください、これがあなたの可視性ベースラインです。

第 2 ステップ：許可されたワークスペースを 1 つ開く。集中デプロイ、共用課金、監査ログ、席管理を一度に整えます。このエコシステムはおおよそ 3 層に分かれ、よくある選択肢は次のとおりです。

• 身元と権限の層：Okta、Entra ID（旧 Azure AD）、Auth0、JumpCloud、GitHub Enterprise SSO。「誰がどのシステムにログインできるか」を管理
• デプロイ＋課金＋監査の統合層：Fly.io organizations、Heroku Teams、Render Teams、Vercel Teams、Zeabur Team Plan。「ものがどこで動き、誰が見えて、誰が払うか」を管理
• リスク管理とコンプライアンス自動化の層：Vanta、Drata、Secureframe、Datadog Cloud Security。「監査準備と異常警告」を管理

完全な stack はたいてい 2〜3 層を組み合わせます。選定そのものが要点ではありません。従業員の既存の AI アプリをここへ移し、新規のものは既定でここで動かすようにすることが要点です。

第 3 ステップ：監査の通路を作る。正式に ISO や SOC 2 を通さなくても、四半期に 1 度は監査ログのチェックを走らせ、すべての本番サービスに owner がいることを確認してください。この習慣は、本物の監査がやってきたときにあなたの命を救います。

業種が異なれば、AI ガバナンスへの取り組み方もそれぞれです。コメディ・エンタメ業界の二人体制エンジンはその最近の一例です。Sunny がマネジメントを主導し、Feng が実装する形で、上記の三層ガバナンスを日常のワークフローに落とし込んでいます。

Vibe coding システムを IT ガバナンス・フレームワークに収める

田中さんの話に戻ります。3 ヶ月が経ちました。

「会員キャンペーンページが落ちた」という電話を受けたとき、田中さんはそのサービスの名前すら知りませんでした。今、会社の IT ワークスペースを開くと、彼が見るのは統一されたダッシュボードです。マーケティングが作った会員キャンペーンページはここ、営業が作った顧客データ整理ツールはそこ、人事が作った面接スケジューラもそこ。各サービスのデプロイ状況、直近で誰がどの env var を変更したか、リソースをどれだけ使ったか、どの地域で動いているか、すべてが同じ画面に並んでいます。

従業員は Cursor で書き続け、新しく作られた AI アプリは既定でこのワークスペースにデプロイされます。田中さんは各部署に「最近何を作りましたか」と追いかけて尋ねる必要がありません。ダッシュボードがその問いに答えるからです。何かが起きたとき、彼は誰を探せばいいか知っていて、対応するサービスがどこで動いているか知っていて、データの境界がどこにあるか知っています。

彼は誰にも AI を禁止しませんでした。やったのは、サンドボックスを整え、従業員の vibe coding がこの許された空間の中で自然に発生する状態を作ったことです。

これが vibe coding 時代の IT ガバナンスです。従業員がどこで動かせるかを設計してはっきりさせれば、誰が書けるかはもはや問題ではなくなります。

すぐに手を動かしてサンドボックスを立ち上げ、従業員の vibe coding を情シスが見える環境に収めたいなら、Zeabur Team Plan はまさにこのために設計されています。