「いま社内で使われている SaaS（クラウドサービス）を、すべて挙げられますか？」――この問いに即答できる中堅企業は、ほとんどありません。 クラウドサービスは、現場の判断で簡単に契約でき、生成 AI を使えば現場が自分でシステムまで作れてしまう時代です。その結果、情報システム部門が把握していないツールやシステムが、社内のあちこちで動いているという状態が当たり前になっています。これが シャドー IT（管理外の IT） です。
本連載のテーマである バイブコーディング（ChatGPT・Claude・Cursor・GitHub Copilot などで自社開発したシステム）も、現場が情報システム部門に相談せず立ち上げれば、立派なシャドー IT です。動いているうちは便利ですが、誰がどんなデータを持つツールを使っているか把握できていないと、セキュリティ・コスト・法令対応のすべてで穴が生まれます。本連載第 21 回（ログ管理）・第 22 回（個人情報マッピング）で扱った対策も、「どんな IT が社内にあるか」を把握していなければ、対象が漏れてしまいます。
そこで有効なのが、年 1 回の IT 棚卸しです。本記事は連載「バイブコーディング危機」第 23 回（防衛策の実装編）として、棚卸しの 4 カテゴリ、シャドー IT を見つける方法、統廃合を判断する 5 つの軸、コスト削減効果の試算、そして 30 日で棚卸しを完結するプログラム を、IPA・ISO 27001・ISACA を一次ソースに整理します。
目次
なぜ社内のITは「把握できなくなる」のか
IT 資産が把握できなくなるのは、特定の誰かの怠慢ではなく、いまの業務環境の構造によるものです。
クラウドは「現場が契約できる」
かつてのシステム導入は、サーバーを買い、情報システム部門が構築する大がかりなものでした。いまは、現場の担当者がクレジットカード一枚で、その日のうちに SaaS を契約できます。便利な反面、情報システム部門を通さずに導入されるため、全社で何のサービスを使っているかが一元的に分からなくなります。
バイブコーディングは「現場が作れる」
生成 AI の普及で、現場の担当者が「自分で業務ツールを作る」ことが容易になりました。これは生産性向上の面では歓迎すべきことですが、ガバナンスの面では、情報システム部門が知らないシステムが社内に増えることを意味します。本連載第 1 回で示したとおり、専門家不在のまま自社開発が広がる現象そのものが、棚卸しを難しくしています。
退職・異動で「使われなくなる」
担当者の退職や異動で、誰も使わなくなった SaaS の契約だけが残り続ける、というのもよくあります（本連載第 8 回の属人化とも重なります）。使われていないのに料金は発生し続け、しかもアカウントは生きたまま放置される――これはコストとセキュリティの両面でリスクです。
要点：IT 資産が把握できなくなるのは、導入が容易になり、作るのも容易になった結果です。だからこそ、意図的に「定期的に棚卸しする」という運用が必要になります。
MANUFACTURING DX
Excel限界から受発注システムへ、同規模の概算は？
中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。
シャドーITが生む4つのリスク
把握できていない IT は、次の 4 つのリスクを生みます。
1. セキュリティの穴
情報システム部門が知らないツールは、セキュリティ設定の確認も、ログの取得も、アクセス権の管理もされません。本連載第 21 回（ログ管理）の対象からも漏れます。攻撃者は、こうした「管理の目が届かないツール」を狙います。
2. 個人情報の所在不明
シャドー IT に顧客情報や従業員情報が入っていると、本連載第 22 回で扱った個人情報マッピングの対象から漏れ、漏えい時に「どこに何があるか」を答えられなくなります。
3. 無駄なコスト
使われていない SaaS、機能が重複する複数のサービス、退職者分のライセンス――これらは把握されていないと払い続けることになります。棚卸しは、こうした無駄を可視化します。
4. 退職時の剥奪漏れ
把握していないサービスは、退職者のアカウントを止め忘れます（本連載第 19 回・第 20 回で扱う退職時の対応とも直結します）。元従業員が前職のツールにアクセスし続けられる状態は、重大なリスクです。
IT棚卸しの4カテゴリ
棚卸しは、対象を 4 つのカテゴリに分けて進めると、漏れなく整理できます。
| カテゴリ | 具体例 | 把握のポイント |
|---|---|---|
| ハードウェア | PC、サーバー、ネットワーク機器、スマホ | 台数・利用者・設置場所・保証期限 |
| ソフトウェア | OS、業務アプリ、ライセンス | バージョン・ライセンス数・利用者 |
| SaaS・クラウド | 各種クラウドサービス、外部 API | 契約数・料金・利用部署・管理者 |
| 自社開発システム | バイブコーディング製ツール、社内システム | 開発者・利用範囲・保持データ |
ハードウェア
PC・サーバー・ネットワーク機器などの物理資産です。台数と利用者、設置場所、保証・サポート期限を把握します。サポートが切れた機器は、セキュリティ更新が止まるため、優先的に洗い出します。
ソフトウェア
OS や業務アプリケーション、そのライセンスです。ライセンス数と実際の利用者数が合っているか（過剰契約・不足）を確認します。
SaaS・クラウド
シャドー IT が最も生まれやすいカテゴリです。契約しているサービス、月額・年額の料金、利用部署、管理者を一覧化します。同じ目的のサービスが複数契約されていないか（機能の重複）も確認します。
自社開発システム
本連載のテーマであるバイブコーディング製ツールを含む、社内で作ったシステムです。誰が作ったか・誰が使っているか・どんなデータを持っているかを把握します。開発者が退職している場合は、中身の把握自体が課題になります（本連載第 8 回）。
シャドーITを見つける方法
「把握していないものを見つける」のは、矛盾するようで難しい作業です。次の方法を組み合わせます。
1. 各部署へのヒアリング
最も基本的な方法です。各部署に「業務で使っているサービス・ツールを挙げてください」と依頼します。このとき、「正式に申請したものだけでなく、現場の判断で使い始めたもの・自分で作ったものも含めて」と明確に伝えることが重要です。曖昧に聞くと、シャドー IT は出てきません。
2. 経費・請求の確認
クレジットカードの利用明細や経費精算を確認すると、情報システム部門が把握していない SaaS の支払いが見つかることがあります。「このサブスクリプションは何か」を一つずつ確認します。
3. 認証ログ・通信ログの確認
本連載第 21 回で整備したログを使うと、社内からどんな外部サービスへアクセスしているかが見えます。SSO（シングルサインオン）を導入している場合は、SSO 経由でどのサービスにログインしているかも把握できます（本連載第 20 回）。
4. 専用の可視化ツール
Microsoft 365 などのクラウド管理画面や、SaaS 管理に特化したツールを使うと、社内で利用されているクラウドサービスを一覧化できます。規模が大きい場合は、こうしたツールの導入が現実的です。
見つけたら責めない
シャドー IT を使っていた現場を責めると、次回から正直に申告してもらえなくなります。「便利だから使っていた」を否定せず、把握したうえで正式な管理下に置くという姿勢が、継続的な棚卸しには欠かせません。
統廃合を判断する5つの軸
棚卸しで洗い出したツールは、すべてを残すわけではありません。残す・正式化する・統合する・廃止するを判断します。その軸が次の 5 つです。
軸1：実際に使われているか（利用状況）
契約しているが、ほとんど使われていないサービスは、廃止の候補です。ログイン履歴や利用実績で判断します。
軸2：機能が重複していないか
同じ目的のサービスが複数契約されている場合は、1 つに統合できないかを検討します。たとえば、複数のチャットツールやファイル共有サービスが併存しているケースです。
軸3：セキュリティ・コンプライアンス上の問題はないか
セキュリティ設定が不十分、個人情報を不適切に扱っている、法令上の問題があるツールは、改善するか廃止するかを判断します。
軸4：コストに見合う価値があるか
料金に対して、得られている価値が見合っているかを評価します。安価でも使われていなければ無駄ですし、高額でも業務に不可欠なら残します。
軸5：代替できるか
廃止・統合する場合、その業務を別の手段で代替できるかを確認します。代替先が無いまま廃止すると、現場が困り、再びシャドー IT が生まれます。
| 判定 | 該当するケース |
|---|---|
| 残す（正式化） | 使われており、価値があり、問題が無い |
| 統合する | 機能が重複している |
| 改善する | 価値はあるがセキュリティ等に問題がある |
| 廃止する | 使われていない・代替がある・問題が大きい |
コスト削減効果を試算する
IT 棚卸しは、セキュリティ対策であると同時に、コスト削減の取り組みでもあります。経営層に取り組みの意義を説明するうえで、コスト面の効果は説得力があります。
削減できるコストの例
-
使われていない SaaS の解約：契約だけ残っているサービスの月額・年額
-
重複サービスの統合：同目的の複数契約を 1 つにまとめる
-
退職者・異動者分のライセンス削減：使われていないアカウント分
-
過剰契約の適正化：実利用者数を上回るライセンス数の見直し
試算の考え方
たとえば、月額の合計が把握できれば、年額に換算して「年間でいくら払っているか」が見えます。そのうち、使われていない・重複しているサービスを特定すれば、削減可能額が試算できます。具体的な金額は各社の契約状況によりますが、棚卸しによって初めて「何にいくら払っているか」が見えること自体が、大きな前進です。
コスト削減は「副産物」と位置づける
ただし、コスト削減を主目的にすると、必要なツールまで削ってしまい、現場が困って再びシャドー IT が生まれる、という本末転倒になりかねません。**本来の目的は「把握とガバナンス」**であり、コスト削減はその副産物として位置づけるのが健全です。
30日で棚卸しを完結するプログラム
棚卸しは、30 日を目安に集中して進めると、間延びせずに完了できます。年 1 回、この 30 日プログラムを回すイメージです。
ステップ1（〜10日）：洗い出し
4 カテゴリ（ハード・ソフト・SaaS・自社開発）について、各部署へのヒアリング・経費確認・ログ確認を組み合わせて、対象を洗い出します。この段階では「漏れなく挙げる」ことを優先し、判断は後回しにします。
ステップ2（〜20日）：台帳への記入
洗い出した IT 資産を、台帳（Excel で十分です）に記入します。IPA の情報資産管理台帳をベースにすると、ゼロから作る必要がありません（IPA: 中小企業の情報セキュリティ対策ガイドライン）。各資産について、利用者・管理者・料金・保持データ・セキュリティ状況を記入します。
ステップ3（〜30日）：統廃合判断とアクション
5 つの軸で、残す・統合・改善・廃止を判断し、アクションリストを作ります。廃止・統合は、代替手段の確認をしてから実行します。あわせて、次回の棚卸しに向けて、新規導入時の申請ルールを整備すると、シャドー IT の発生そのものを抑えられます。
工程のまとめ
| 期間 | やること | 成果物 |
|---|---|---|
| 〜10 日 | 4 カテゴリの洗い出し | 対象一覧（ドラフト） |
| 〜20 日 | 台帳への記入 | IT 資産台帳 |
| 〜30 日 | 統廃合判断・アクション・ルール整備 | アクションリスト・導入申請ルール |
年1回を「仕組み」にする
棚卸しは一度きりでは効果が続きません。年 1 回の定例として、たとえば年度初めや予算編成のタイミングに組み込むと、継続しやすくなります。SOC 2 や ISO 27001 といった認証（本連載第 26 回で扱います）を目指す場合、定期的な資産棚卸しはその要件とも整合します。
中堅・中小企業が陥りやすい5つの失敗
1. 正式なシステムだけを数える
情報システム部門が把握しているものだけを台帳化し、現場のシャドー IT を見ないケースです。ヒアリング時に「現場判断で使っているもの・自分で作ったものも含めて」と明確に伝えることが必要です。
2. シャドー ITを使っていた現場を責める
発見した現場を叱責すると、次回から申告されなくなります。把握して正式な管理下に置く、という前向きな姿勢が、継続的な棚卸しを支えます。
3. 一度やって終わりにする
棚卸しを単発のプロジェクトで終え、その後の新規導入を管理しないケースです。年 1 回の定例化と、新規導入時の申請ルールで、台帳の鮮度を保ちます。
4. コスト削減だけを目的にする
削減を急ぐあまり必要なツールまで切り、現場が困って再びシャドー IT が生まれるケースです。目的は把握とガバナンスで、コスト削減は副産物と位置づけます。
5. 自社開発システムを台帳に入れ忘れる
SaaS は数えても、バイブコーディングで作ったツールを資産として認識しないケースです。自社開発システムも「誰が作り・誰が使い・何のデータを持つか」を必ず台帳に含めます。
国内・国際の文脈：IPA・ISO 27001・ISACA
IT 資産の棚卸し（インベントリ）は、国内外の主要な枠組みで、セキュリティ管理の出発点に位置づけられています。
IPA「中小企業の情報セキュリティ対策ガイドライン」
IPA のガイドライン（第 4.0 版）には、情報資産管理台帳 の Excel テンプレートが付属し、情報資産の名称・種類・利用業務・保管場所・利用者・管理者などを記録して、各資産の重要度を評価する仕組みが示されています（IPA: 中小企業の情報セキュリティ対策ガイドライン）。IT 棚卸しの台帳は、これを基盤にできます。
ISO 27001「資産の目録（Annex A 5.9）」
情報セキュリティマネジメントの国際規格 ISO/IEC 27001 では、附属書 A の管理策 5.9「情報及びその他の関連資産の目録」 として、組織が保有する資産の目録を作成し、各資産に管理責任者を割り当てることを求めています。さらに管理策 5.10「資産の許容される利用」と結び付けられており、利用ルールを定めるには、まず資産を特定していることが前提であると整理されています（ISO/IEC 27001 公式）。
ISACA「COBIT」（IT ガバナンスの枠組み）
ISACA の COBIT は、IT 資産を含む IT 全体のガバナンスと統制の枠組みで、IT 資源を適切に管理・監視することを重視しています（ISACA COBIT）。棚卸しは、このガバナンスを支える基礎的な活動にあたります。
実務判断のポイント
この記事を読むべきなのは、経営者、DX責任者、情シス、業務責任者です。単に情報を把握するだけでなく、現状棚卸し、業務改善、AI/DXロードマップ、実装優先順位の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。IT棚卸しを年1回やる実践 2026｜中堅企業のシャドーIT発見と統廃合を30日で進めるプログラム｜バイブコーディング防衛策実装編に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの見解
DXは流行ツールの導入ではなく、現場業務、データ、権限、KPI、投資判断をつなぐ実装計画である。
GXOは最初から大規模刷新するより、棚卸し、優先順位付け、小さな実装、効果測定を繰り返すべきだと見る。
GXOが提供できる価値は、DX成熟度診断、業務棚卸し、ロードマップ、AI/システム実装まで支援できる。 ことです。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、DX診断、要件定義、システム開発、AI活用支援へ接続。さらに、短期診断から段階実装に進め、継続支援へ展開。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問（FAQ 10問）
Q1. IT 棚卸しは、どれくらいの頻度でやればよいでしょうか？
A. 年 1 回の定例が一つの目安です。年度初めや予算編成のタイミングに組み込むと継続しやすくなります。加えて、大きな組織変更やシステム導入があったときには、随時更新します。
Q2. シャドー IT は、どうやって見つければよいでしょうか？
A. 各部署へのヒアリング、経費・請求の確認、認証・通信ログの確認、専用の可視化ツール――これらを組み合わせます。ヒアリングでは「現場判断で使っているもの・自分で作ったものも含めて」と明確に伝えることが重要です。
Q3. シャドー IT を使っていた現場を、どう扱えばよいでしょうか？
A. 責めずに、把握したうえで正式な管理下に置く、という姿勢が大切です。叱責すると次回から申告されなくなり、かえってシャドー IT が見えなくなります。
Q4. 棚卸しに専用ツールは必要でしょうか？
A. 規模が小さいうちは Excel の台帳で十分です。IPA の情報資産管理台帳をベースにできます。SaaS 数が多く把握が難しい場合は、クラウド管理画面や SaaS 管理ツールの導入を検討します。
Q5. バイブコーディングで作ったツールも棚卸しの対象でしょうか？
A. 対象です。自社開発システムは「誰が作り・誰が使い・何のデータを持つか」を台帳に含めます。開発者が退職している場合は、中身の把握自体が課題になるため、優先的に確認します。
Q6. 棚卸しで、どれくらいコストを削減できますか？
A. 各社の契約状況によります。使われていない SaaS の解約、機能が重複するサービスの統合、退職者分のライセンス削減などで、削減余地が見つかることが多いです。まず「何にいくら払っているか」を見えるようにすること自体が前進です。
Q7. 廃止すると現場が困るツールは、どう判断すればよいでしょうか？
A. 代替手段の有無を確認してから判断します。代替先が無いまま廃止すると、現場が困って再びシャドー IT が生まれます。価値があり使われているものは、正式に管理下に置いて残します。
Q8. 棚卸しと、第 21 回・第 22 回の対策はどう関係しますか？
A. 棚卸しは、ログ管理（第 21 回）や個人情報マッピング（第 22 回）の「対象を漏れなく洗い出す」前提になります。どんな IT が社内にあるかを把握していなければ、ログも個人情報も対象が漏れてしまいます。
Q9. 新しいシャドー IT が生まれるのを防ぐには？
A. 新規導入時の申請ルールを整備します。「新しいサービスを使う・作るときは情報システム部門に申請する」という流れを軽い手続きで用意すると、現場が正式ルートを使いやすくなり、シャドー IT の発生を抑えられます。
Q10. まず何から始めればよいでしょうか？
A. SaaS・クラウドサービスの洗い出しから始めることをおすすめします。シャドー IT が最も生まれやすく、経費確認で見つけやすいためです。各部署ヒアリングと請求確認を組み合わせ、台帳の最初の数行を埋めてください。
参考一次ソース
まとめ
-
クラウドの普及と生成 AI による自社開発の容易化で、**情報システム部門が把握しないツール（シャドー IT）**が増えています
-
バイブコーディングで現場が作ったシステムも、申請しなければ シャドー IT です
-
把握できていない IT は、セキュリティの穴・個人情報の所在不明・無駄なコスト・退職時の剥奪漏れの 4 つのリスクを生みます
-
棚卸しは **4 カテゴリ（ハード・ソフト・SaaS・自社開発）**に分けると漏れなく整理できます
-
シャドー IT は、ヒアリング・経費確認・ログ確認・可視化ツールを組み合わせて見つけ、見つけても現場を責めません
-
統廃合は 利用状況・機能重複・セキュリティ・コスト・代替可否の 5 軸で、残す・統合・改善・廃止を判断します
-
棚卸しは **洗い出し（〜10 日）→ 台帳記入（〜20 日）→ 判断・ルール整備（〜30 日）**を 年 1 回の定例にすると効果が続きます
「便利だから現場が勝手に使う・作る」を否定するのではなく、年 1 回の棚卸しで把握し、正式な管理下に置く。これが、バイブコーディング時代の IT ガバナンスの実装ステップです。
IT棚卸しとシャドーIT対策を相談したい方へ
GXO の バイブコーディング監査 + IT ガバナンス支援サービスでは、中堅企業向けに次のようなご相談を承っています。
-
IT 資産の棚卸し支援：ハード・ソフト・SaaS・自社開発の 4 カテゴリを台帳化
-
シャドー IT の可視化：ヒアリング・経費・ログを用いた管理外ツールの洗い出し
-
統廃合の判断支援：5 つの軸での残す・統合・改善・廃止の評価とコスト試算
-
バイブコーディング製ツールの棚卸し：開発者不在のシステムの中身把握と台帳化
-
新規導入の申請ルール整備：シャドー IT の発生そのものを抑える仕組みづくり
関連記事
著者: GXO株式会社 初回公開: 2026 年 6 月 12 日 最終更新: 2026 年 6 月 12 日 連載: バイブコーディング危機 第 23 回（全 30 回予定 / 第 5 週・防衛策の実装編）
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
