現場の勝手なSaaS導入を防ぐ、シャドーIT対策

プロジェクトのリーダーが、外注のデザイナーへ大量の図面を一晩で共有しなければならなくなりました。社内のファイルサーバーは遅く、情シスへの申請は日数がかかります。そこで前職で使っていたクラウドストレージとコラボレーションのサービスに手を伸ばし、法人カードで3分で契約し、図面をアップロードしました。プロジェクトは期日通りに完了しました。しかし2か月後の内部統制レビューで、顧客の設計図や仕入先の価格表が、情シスが一度も審査していないアカウントの中に置かれていたことが発覚します。そのアカウントは、すでに別プロジェクトへ異動した一人のログインIDに紐付いたままでした。そのアカウントが今も支払われているのか、パスワードを誰が持っているのか、その方が退職したらそのデータはどうなるのか、誰にも分かりません。

これは珍しい事例ではありません。ほぼすべての企業でシャドーITが生まれる経緯です。情シスもセキュリティも一度も審査していないツールが、気づけば日常業務の一部になります。そして企業データは、誰も意図して選んだわけではないサービスの中に散らばっていきます。原因は悪意ではありません。新しいツールの導入が早く、統制から外れ、いかなる審査とも切り離されていることです。申請と承認のワークフローを持つ基幹システムは、症状ではなく根本原因を解決します。

統制のないSaaS導入がレビューで落ちる理由

新しいオンラインサービスへの登録は、生産性の向上に見えます。実際には、メールと法人カードでは保持しきれない3つの要素を持つ情報セキュリティと内部統制の意思決定です。

1つ目はデータの散逸です。チームが審査されていないサービスにファイルをアップロードすると、企業は自社の情報がどこにあるか把握できなくなります。顧客リスト、図面、価格、人事情報が、設置場所も保持期間も削除方針も一度も評価されていないサーバーに置かれます。内部統制やセキュリティの点検では、こうした管理されていないデータの拡散が最も解消しづらいリスクとして繰り返し指摘されます。発覚した時点では、データはすでに社外に出てしまっているからです。

2つ目は監査証跡です。監査人が、設計チームが顧客の設計図を特定のクラウドサービスに置くことを誰が認可したかを問うたとき、答えがカードの利用明細であってはなりません。上場企業がJ-SOXの下で応える内部統制の枠組みや、より広い情報セキュリティの期待は、何が申請され、誰が審査し、どんなデータを保持し、誰が承認したかを示す記録を求めます。ソフトウェア購読の領収書1枚は、この問いに耐えられません。

3つ目は退出の瞬間です。アカウントを開設した方は、いずれプロジェクトを移り、役割が変わり、あるいは退職します。しかしアカウントは必ず閉鎖されるとは限りません。購読は請求され続け、ログインは動き続け、データは誰の持ち物でもないサービスの中に置かれ続けます。管理されていないアカウントが生きている期間が長いほど、それが漏洩、忘れられた支払い、あるいはコンプライアンス指摘事項になる可能性は大きくなります。ここでのコストは時間では測れません。取り消せないその1件の事故で測るしかありません。

3つすべてに共通する欠陥は、新しいツールを導入することに統制された申請・承認の経路がないことです。新しいサービスの利用申請がITとセキュリティの審査を経てから許可される単一の場所も、使われなくなったツールが見直され廃止される予定の時点も存在しません。

統制されたSaaS導入ワークフローが実際にどう見えるか

解決策は、後から追加する単体のクラウド監視ツールではありません。経費や購買発注、アクセス権の申請を既に動かしている基幹システムと同じ場所にある承認ワークフローです。実際のワークフローエンジンを読むと、今日本当に実装されていることと、正直言ってまだロードマップ上にあることが以下の通りです。

1件の申請を、役割と条件でITとセキュリティへ

新規ツールの申請は1件の構造化されたフォームから始まります。チームのリーダーはツール名、利用目的、触れるデータ、必要な席数を選びます。ケースごとに異なる項目を表示するよう設定できるため、デザインコラボレーションの申請には対象ファイルの種類を、アンケートツールの申請には取り扱うデータ区分を尋ねる、といった切り替えが可能です。これは経費や休暇のワークフローが既に使っている動的フォームと同じ機能を、ツール導入に適用したものです。

申請が提出された瞬間、設定可能な承認ルートを流れます。重要なのは、このルーティングは今日実装され稼働しているということです。ワークフローエンジンは管理者を固定の名前ではなく申請者から解決するため、申請は自動的に申請者の直属の上司に届きます。その後、技術審査のためにITへ、データとベンダーの評価のためにセキュリティへ、並列で回ります。並列ルーティングがここで重要な理由は、新規ツールの申請を最も殺す手順が、ITとセキュリティに順番待ちを強いることだからです。並列審査にすれば、両方の確認が同時に走り、両方が揃った時点で申請が前に進みます。

ルーティングは条件で分岐できます。機密データを保持しない低リスクのツールは、直属上司とITの確認1件だけで済むかもしれません。顧客情報や図面、財務データを保持するツールは、2人目の承認者や委員会に回ります。アクセス権の申請と同じ感度の閾値がここでも働き、個人情報に触れるツールには公開マテリアルだけを扱うツールより多くの目を要求します。

この条件付きで役割を意識したルーティングこそ、メールで最も失敗しやすい部分です。新規ツールにはITの承認が必要と規程に書いておきながら、実際にはITが耳にする前にチームがもう購入している、という運用になりがちです。ワークフローエンジンは、申請こそが正面玄関であるため、規程を毎回必ず適用します。設定された審査者が実際に決定するまで、ツールは一つも導入されません。

すべての申請がどこで詰まっているか一目で分かる

すべての申請がワークフローの中にあるため、進行中の新規ツール申請の状態をすべて確認できます。どれが直属上司待ちか、どれがITのキューにあるか、どれがセキュリティへの質問で差し戻されたか、どれが稼働準備完了か。廊下を歩いて人を探す必要も、チームが期日までに希望のツールを手に入れられるか推測する必要もありません。承認者ではなく申請を追いたい関係者、例えば締切を追うプロジェクトのスポンサーは、審査の連鎖を乱すことなく申請の動きを追えます。

審査と承認の内容を固定スナップショットで証跡化

申請が承認されると、システムは決定内容を固定スナップショットとして記録します。ツール名、利用目的、データ区分、承認者、審査メモ、タイムスタンプです。これが、監査人の問いに記憶から履歴を再構築せずに答える監査証跡です。今日システムが経費承認やアクセス承認を守っているのと同じスナップショットの規律を、ツール導入まで広げたものです。1年後、誰も申請した覚えのないサービスに会社が課金している理由を問われたとき、答えはそこにあります。

審査者の不在でも止まらない安全な代理承認

ITのリードやセキュリティ責任者が出張中でも承認は止まりません。エンジンは安全な代理承認に対応しており、出張中の審査者は自身のキューを代理者に委ねられます。ただし高リスクの項目には必須の再承認経路が設定されます。ツールの申請が、顧客先に出向いている1人の都合で1週間止まることはありません。それはまさに、チームがカードで契約して手続き全体を迂回したくなる種類の遅延です。

自動書き戻しについて正直に

すべての購入者が尋ねるべき境界を、率直に述べます。

申請と承認の統制は今日実装され稼働しています。チームが新規ツールを申請し、ワークフローが役割と条件によってITとセキュリティの審査へ申請を並列で回し、決定とその完全な文脈が固定された監査スナップショットとして記録され、申請の移動中の状態がすべて見える、という統制の階層は実在し、動いています。会社がどのツールを導入し、誰が承認すべきかを管理する本物のガバナンス層です。

ロードマップにあり、まだ実装されていないのは、対象サービス自身への自動書き戻しです。承認が完了した瞬間にクラウドサービスを自動でプロビジョニング、あるいはブロックし、すでに利用中の未審査サービスを自動で発見し、承認済みのツールの審査期限が切れたときに自動で廃止することは、これから進める作業であり、完成した作業ではありません。正確な表現はこうです。申請と承認の統制は現在稼働しており、稼働中のサービスに対する自動強制と発見は次のステップです。承認ボタンを押すだけで今日、すべてのクラウド購読を自動で制御すると語る方は、過剰に売り込んでいます。

書き戻しがなくても、価値は具体的です。今日のギャップは通常、ITがツールを審査できないことではありません。誰がそれを認可したか証明できないこと、どんなデータを保持しているか分からないこと、そして廃止の持ち主がいないことです。ワークフローは証明と持ち主、そしてスケジュールを閉じます。統制が整った後、各クラウドサービスへの最終自動ステップはまとまった作業であり、それこそがロードマップが担う部分です。

事例：静岡の精密部品メーカー

自動車や産業機械のOEM各社に部品を供給する、静岡の精密部品メーカーを想像してください。社員数は約280名。本社と工場、営業拠点を持っています。情シスチームは小規模で、エンジニアリングの各チームは顧客プログラムを高速に進めています。2025年のレガシーシステムの崖と、デジタルトランスフォーメーションの絶え間ない圧力により、チームはデザインコラボレーションのサービスからアンケートのプラットフォーム、スケジュールのアプリまで、常に新しいツールに手を伸ばします。

従来の流れでは、各チームは作業を早めるのに役立つものなら何でも導入し、法人カードで支払い、何かが壊れたときにだけITに伝えていました。図面、仕入先の見積り、プロジェクトのスケジュールが、ITが一度も評価していない6つのサービスに散らばりました。その年の内部統制レビューでの指摘は単刀直入でした。どのサービスが顧客データを保持しているかを示す綺麗な記録を提出できず、どれ一つとしてセキュリティ審査を通ったと証明できず、数か月前に退職した方に紐付いた購読にまだ課金し続けていました。

統制された流れでは、すべての新規ツールがワークフローの中の申請として始まります。チームのリーダーが利用目的とデータ区分とともに申請を提出します。申請は自動的に直属上司に届き、その後技術確認のためにITへ、データ評価のためにセキュリティへ並列で回ります。顧客の図面を保持するツールは条件により2人目の承認者に回るため、機密データが1回のクリックに依存することはありません。情シスは保留中の申請をすべて確認でき、プロジェクトの期日までに審査が終わるよう計画できます。

ツールが承認されると、スナップショットは何が審査され、どんなデータを保持し、いつ審査を見直すべきかを記録します。プロジェクトが終わるとき、廃止の申請は同じ経路を流れるため、購読の閉鎖は願いではなく統制された記録された事実になります。翌年のレビューでは、導入されたすべてのツールに固定スナップショットがあり、すべての廃止に綺麗な記録が見つかります。未審査サービスの指摘は戻ってきません。

ここでの価値は主にリスクです。忘れられ未審査のサービスを経由して顧客のデータセット1件が漏洩するコストは、会社が購入する購読すべての料金を合わせても及びません。統制された導入ワークフローは、単に時間を節約するだけではありません。次の未審査サービスが静かに責任案件になるのを止めます。

ERPの横ではなく、ERPの中にあるべき理由

別のクラウド監視ツールを買い込み、ツールの拡散を純粋なITの課題として扱う誘惑があります。それがシャドーITが戻ってくる経緯です。ツールを導入することは他のどの承認決定とも同じ性質のものであり、経費や購買、アクセスの監査規律を既に保持しているのと同じ基幹システム、すなわちERPの中にあるべきです。

導入のワークフローが基幹システムの中にあるとき、3つのことが揃います。承認ルートは経費承認と同じ管理者解決を使えるため、組織改編でルーティングが壊れません。監査スナップショットは内部統制の他の部分と同じ固定記録の規律を使うため、監査人は一貫した1つの証跡を見ます。そして新規ツールの申請は、アクセス権の申請のすぐ隣に置かれます。2つの問いは関連しているからです。チームが新しいコラボレーションサービスを欲しがるとき、誰がそれを使ってよく、どんなデータを保持するかという問いは、誰がそのログインを持つかという問いと一緒に動くべきです。

より広い恩恵もあります。一度ツールの導入が統制された申請になれば、同じ型をベンダー登録、契約更新、データ持ち出しの承認へと拡張できます。これらは今日チャットやカードの1アクションで行われている決定であり、いずれも次のレビューを待つ指摘事項です。

よくある質問

承認していないツールを自動でブロックしてくれますか？

申請と承認の統制は今日実装され稼働しています。すべての新規ツールは許可される前にITとセキュリティの審査を経て、決定は固定された監査スナップショットとして記録されます。ネットワークや調達の層で未承認のサービスをブロックする自動書き戻しはロードマップにあり、まだ実装されていません。統制と記録は今日稼働しており、稼働中のサービスに対する最終自動強制はこれからです。

顧客データに触れるツールにセキュリティ審査を必須にできますか？

はい。低リスクのツールは1人の承認者へ、顧客情報を保持するツールは条件により2人目の承認者や委員会へ回せます。設定された承認者が実際に決定するまで申請が完了しないため、規則は毎回必ず適用されます。これは実装済みで稼働しています。

審査者が不在のときはどうなりますか？

ワークフローは安全な代理承認に対応しています。出張中のITリードやセキュリティ責任者はキューを代理者に委ねられます。ただし高リスクの項目には必須の再承認経路があります。ツールの申請が、顧客先に出向いている1人の都合で1週間止まることはありません。

既存のクラウド監視ツールを置き換えることになりますか？

いいえ、置き換える必要もありません。ワークフローは申請と決定を統制し、スナップショットを記録します。承認された申請から既存の発見ツールや調達ツールへの接続は、ロードマップが担う書き戻しのステップです。重要なのは、導入の前に統制された監査可能な管理を置くことであり、すでに動いているものを引き剥がすことではありません。

重要なポイント

シャドーITはITの事故ではありません。それは、統制された申請と承認の経路なしにツールを導入した結果として予測可能に起こるものです。設定可能なワークフローを持つ基幹システムは根本原因を解決します。すべての新規ツールが申請として始まり、役割と条件によってITとセキュリティへ並列で回り、固定された監査スナップショットとして記録されます。稼働中のサービスに対する自動強制と発見はロードマップ上の次のステップです。統制と記録は今日稼働しており、それこそが次の未審査サービスが静かに企業データを広げるのを止めるものです。

Kikan System で始める

未審査のサービスや忘れられた購読が点検で繰り返し指摘されているなら、Kikan System をご覧ください。申請と承認のワークフローは、新規ツールの申請を役割と条件によってITとセキュリティへ並列で回し、すべての決定を監査スナップショットとして固定し、導入の進行を見える形で保持します。2ユーザーまで無料、カード不要のフリープランですぐに始められます。/#get-startedからご開始ください。

-> 関連：基幹システムに連動するロールベースアクセス制御