どの組織もシャドウITの存在を認識している。この問題を具体的に示す数字は、ほとんどの組織が1,000以上のクラウドアプリケーションを運用しているにもかかわらず、IT部門が把握できるのはそのうちの10%未満に過ぎないという点だ。大企業では平均473のSaaSアプリケーションが稼働しているが、IT部門が直接管理しているのはそのごく一部に過ぎない。従業員の80%は、業務遂行のために非公式のアプリケーションを使用している。これらの数字はどの調査でも一貫しているが、それはこれらの数字が反映するダイナミクスが一貫しているからだ。つまり、従業員や事業部門は、ITガバナンスプロセスが評価・承認するよりも早く、差し迫った問題を解決できるツールを採用してしまうのだ。
2026年のシャドウITに関する議論は、DNSログのスキャン、SSO OAuthトークンの分析、経費報告書の監査、ネットワークトラフィックのフィンガープリンティングなどを行い、従業員が無許可で使用しているクラウドアプリケーションを検出するSaaS検出ツールが中心となっている。これらのツールはSaaSレイヤーの問題を解決し、その解決能力はそれなりに高い。しかし、これらのツールが解決できない、あるいはどのSaaS検出ツールも対処できないのが、もう一つのシャドウITの問題である。それは、企業アプリケーションポートフォリオに存在し、資産管理システム、変更ログ、ITインベントリに一度も記載されていない、独自開発のアプリケーション、文書化されていないバッチプログラム、非公式のデータパイプライン、ゴーストユーティリティプログラムなどである。これらは従業員が展開したクラウドアプリケーションではない。これらはメインフレームやミッドレンジシステム上で稼働する本番環境プログラムであり、所有する組織が完全に把握できないビジネス上重要な機能を実行している。
これら2つの問題には、それぞれ異なる発見手法が必要です。SaaSのシャドウIT問題では、ネットワークの可視化とID統合が求められます。一方、コードレベルのシャドウIT問題では、実際のソフトウェア成果物、ソースコード、ロードライブラリ、JCLジョブストリームを解析し、どのようなプログラムが存在し、どのような動作をするのかを列挙する必要があります。本ガイドでは、この両方を網羅していますが、特に、これまで他の分野では取り上げられてこなかった後者のカテゴリに焦点を当てています。
シャドウITの2つの問題点
シャドウITとは、一般的に、組織内でIT部門の明確な承認や認識なしに使用されているテクノロジーと定義されます。この定義は、根本的に異なる2つの現象を包含しており、それぞれ異なる発見方法とガバナンス対応が必要となります。
シャドウSaaSおよびクラウドツールとは、正式なIT調達手続きを経ずに従業員や事業部門が導入したアプリケーションやサービスのことです。例えば、マーケティングチームが承認されていないAIライティングツールを使用しているケース、財務チームが個人のDropboxアカウントを通じてスプレッドシートを共有しているケース、開発者が承認されていないAIコーディングアシスタントを使用して独自のソースコードを外部APIに送信しているケースなどが挙げられます。これらのアプリケーションは組織のインフラストラクチャの外部に存在し、DNSクエリ、OAuth認証、経費精算明細、ネットワークトラフィックのフィンガープリントといった外部シグナルによって検出可能です。
シャドウアプリケーションソフトウェアとは、本記事で特に取り上げるカテゴリであり、組織独自のインフラストラクチャ内で作成され、適切に文書化、インベントリ化、または管理されてこなかったカスタム構築プログラムおよびバッチ処理のことです。例えば、1994年に財務部門の開発者が特定の税額計算の特殊なケースを処理するために作成したCOBOLプログラム。ビジネスアナリストが特定の取引先向けにEDIファイルを生成するために作成したRPGプログラム。2009年に組織を離れた契約社員が作成した、毎月末に実行されコンプライアンスチームが依存する規制レポートを生成するJCLジョブ。2018年のシステム統合プロジェクト中に「一時的に」作成されたJavaユーティリティが、誰もそうすべきだと決めていないにもかかわらず、恒久的な依存関係になってしまったもの。
これらのプログラムは内部インフラストラクチャ上で実行されるため、DNSログには表示されません。OAuthの導入以前に作成されたため、OAuth認証レコードにも表示されません。また、ITガバナンスレビューのために正式に提出されたことがないため、公式のアプリケーションインベントリにも登録されていません。これらのプログラムは、インフラストラクチャ自体、ロードライブラリ、ソースコードリポジトリ、ジョブスケジューラ、および実行ログを調査して、実際に環境で実行されているソフトウェアを明らかにすることによってのみ発見できます。
これが在庫の完全性以上に重要な理由は、組織の74%が、未知または未管理の資産に起因するセキュリティインシデントを経験しているからです。シャドウアプリケーションソフトウェアは、ネットワークベースの検出ツールやSaaS可視化プラットフォームでは検出できない、未知の資産のカテゴリーに該当します。
シャドウアプリケーションソフトウェアが蓄積する理由
企業環境において、文書化されていないカスタムアプリケーションが蔓延する理由を理解することで、標準的なガバナンスプロセスがそれを防止できない理由、そして事後的な発見が必要な理由が明らかになる。
即時解決が求められる状況。事業部門は、特定の運用上の問題に直面しており、それに対して特定の解決策が必要となる。承認済みのアプリケーションでは、例外的なケースに対応できない。IT部門のリクエストキューはバックログでいっぱいになっている。IT部門に所属する開発者、あるいは事業部門に所属する開発者が、動作するソリューションを作成する。ソリューションは実行され、問題を解決し、運用ワークフローの一部となる。問題は既に解決されているため、正式なガバナンスプロセスは実行されない。
一時的なものが恒久的なものになるパターン。最も悪質なシャドウアプリケーションソフトウェアは、最初は明確に一時的な解決策として始まります。「実際のシステムが準備できるまで」「データ形式の問題に対する簡単な回避策」「ベンダーがAPIを修正するまでの一時的なもの」。一時的な解決策は、それらの周りに蓄積された依存関係が決して解消されないときに恒久的なものになります。Y2K対策のために書かれたCOBOLの日付計算修正は、後続の開発者がなぜそれが存在したのか、削除しても安全なのかを知らなかったため、25年経った今でも呼び出されています。ターゲットアプリケーションが実際に構築されなかったため、夜間バッチの一部となった「一時的な」データベース正規化スクリプト。
知識移転の失敗。特定の個人によって構築されたシャドウアプリケーションは、その個人が退職すると組織の文書化された知識から切り離されてしまう。プログラムは稼働し続け、それに依存する本番プロセスに組み込まれるが、ドキュメントは存在せず、所有権も割り当てられておらず、安全に変更できるほど詳細な動作を知っている人は誰もいない。それは本番環境における幽霊のような存在となる。その影響は目に見えるが、ガバナンスは見えないのだ。
シャドウデータパイプライン。データ統合は、文書化されていないカスタムソフトウェアにとって特に肥沃な土壌です。公式のETLレイヤーが必要な変換をサポートしていない場合、またはビジネスプロセスが公式の統合プロセスで許容されるよりも速くシステム間でデータを移動する必要がある場合、開発者は非公式のデータ移動プログラムを作成します。本番データベースにクエリを実行し、結果を下流プロセスが取得する共有ドライブに書き込むPythonスクリプト。メインフレームDB2から読み取り、クラウドアプリケーションが取り込むフラットファイルに書き込むCOBOLプログラム。これらの非公式のデータパイプラインは、システム境界を越え、機密データを扱う可能性があり、統合ガバナンスフレームワークの完全な外部で動作します。
シャドウアプリケーションソフトウェアの4つのカテゴリ
カテゴリー1：事業部門向けカスタムアプリケーション
ビジネスユニット、財務、調達、運用、コンプライアンスなどに組み込まれた開発者によって構築され、特定のドメインの問題を解決するプログラム。これらのプログラムは通常、次のような特徴を持つ。
- 企業命名規則に従わず、非公式な名称（TAXCALC、VENDREPT、ADJBATCH）が付けられている。
- IT部門ではなく、事業部門が管理するディレクトリやライブラリに格納する。
- 構成管理データベース（CMDB）にエントリがない
- ITサービス管理システムに技術担当者が割り当てられていない
- 正式な文書、テストカバレッジ、変更管理履歴が不足している
事業部門はプログラムの機能を把握しており、「自分たちのもの」だと考えているため、その重要性が過小評価されることがよくあります。一方、プログラムの存在を知らないIT部門は、その重要性を評価することができません。IT部門のアプリケーションインベントリにそのプログラムが含まれていないということは、事業継続計画（BCP）、災害復旧計画、セキュリティ評価、および近代化プログラムの範囲にも含まれていないことを意味します。
カテゴリー2：ゴーストプログラム
本番環境で実行されるプログラムの中には、その起源、目的、所有者が現在の組織には不明なものがある。これらのプログラムはロードライブラリやソースリポジトリに存在し、他のプログラムから呼び出されたり、JCLジョブによって実行されたりする。また、下流工程が依存する出力を生成するが、なぜこれらのプログラムが存在するのか、誰が責任者なのかといった組織内の記憶は失われている。
ゴーストプログラムは、セキュリティとコンプライアンスの観点から特に危険です。なぜなら、現行の基準に照らしてレビューすることができず、アプリケーションの所有権の割り当てを必要とする脆弱性スキャンプログラムに含めることができず、また、アクセスするデータや提供する業務機能が不明なため、規制遵守状況を評価することもできないからです。
カテゴリー3：シャドウデータパイプライン
公式に認められた統合アーキテクチャの枠外で、システム間でデータを移動させる非公式プログラム。これには、高度なETL代替ツールから単純なファイル転送スクリプトまで、さまざまなものが含まれる。
パイソン
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")このプログラムは、企業環境全体に見られる典型的なパターンを示しており、ハードコードされた本番データベースの認証情報を使用し、機密性の高い請求データを暗号化せずに共有ネットワークの場所に書き込み、作成者が組織を去った後も何年も監視されずに稼働し続けています。内部インフラストラクチャ上で動作するため、SaaS検出ツールには表示されません。また、識別可能なシグネチャを生成しない標準的なデータベースプロトコルを使用しているため、ネットワークトラフィック分析にも表示されません。このプログラムは、ソースコード自体の中にのみ存在が確認されます。
カテゴリ4：文書化されていないバッチジョブ
本番環境のインフラストラクチャ上で実行されるものの、公式のジョブスケジュール文書には記載されていないJCLジョブストリームおよびスケジュール済みプログラム。これらは以下の方法で蓄積されます。
- 標準のジョブスケジューラ以外から直接送信されたジョブ
- 他のプログラム内から動的に呼び出されるプログラム（そのため、スケジューラのインベントリには独立して表示されない）
- 月末、年末、または特定のビジネス状況が発生した時のみ実行される、頻度の低いジョブで、通常の在庫監査ではこれまで捕捉されたことがないもの。
- 移行されたものの正式には廃止されなかった、前身システムから引き継がれたジョブ
文書化されていないバッチジョブは、次のような場合に重大な障害点となる。
- メンテナンス期間が発生すると、それらが稼働しているシステムに影響が出るが、その出力に依存している事業部門に通知する必要があることを誰も知らない。
- セキュリティ評価が実施され、これらのジョブは監視対象外のサービスアカウントとして、高い権限で実行されます。
- 近代化プログラムは、文書化されたジョブスケジュールに基づいて移行の範囲を定め、重要なバッチ処理が欠落した状態でターゲット環境に到達します。
Shadow Softwareカテゴリによる検出方法
SaaSシャドウITに適した検出方法は、シャドウアプリケーションソフトウェアにはほとんど適用できません。必要な方法は以下のとおりです。
ロードライブラリ分析。メインフレームまたはミッドレンジシステムにコンパイルおよびデプロイされたすべてのプログラムは、実行可能ファイルのリポジトリであるロードライブラリに存在します。ロードライブラリ内のプログラムと公式アプリケーションインベントリ内のプログラムを比較すると、ギャップが明らかになります。ライブラリには存在するがインベントリには存在しないロードモジュールはすべて、シャドウプログラムです。この分析にはソースコードは不要で、コンパイル済みの実行可能ファイルとそのメタデータに基づいて動作します。
ソースリポジトリの走査。ソースコードリポジトリ（COBOLソースPDS、Gitリポジトリ、RPGソースライブラリなど）には、非公式に作成され、非公式に展開され、ITガバナンスシステムに登録されていないプログラムも含め、これまでに作成されたすべてのプログラムが含まれています。CMDBに対してソースリポジトリ全体を走査することで、ソースコードには存在するものの、ガバナンス記録がないプログラムが明らかになります。
JCLとスケジューラの照合。公式スケジューラ経由で投入されたか、手動で投入されたか、または他のジョブによって呼び出されたかにかかわらず、本番環境で実行されるすべてのJCLジョブストリームは、ジョブ実行ログ（JESLOG、SYSLOG）に痕跡を残します。本番実行ログに表示されるプログラムを公式インベントリのプログラムと比較することで、ガバナンスの適用範囲外で本番環境で実行されているプログラムを特定できます。
動的CALL解析。コンパイル時ではなく実行時に呼び出されるプログラム名が決定される、他のプログラムを動的に呼び出すプログラムは、静的スケジューラ解析では見えない依存関係を生み出します。動的CALL解析は、可変のプログラム名を持つCALL文を発行するプログラムを追跡し、呼び出される可能性のあるプログラムの範囲を特定し、静的依存関係マップには表示されない可能性のある、動的ディスパッチによって到達可能なプログラムにフラグを立てます。
データフローのトレース。シャドウデータパイプラインは、ファイルシステムとデータベースのアクセスパターンを分析することで発見できます。つまり、どのプログラムがどのデータセット、ファイル、またはデータベーステーブルから読み書きしているかを把握します。本番データベースから読み込み、標準のデータ管理階層外のファイルパスに書き込むプログラムは、シャドウパイプラインの候補となります。
シャドウAIディメンション
2026年におけるシャドウIT問題の深刻化は、シャドウAI、すなわちIT部門の承認を得ずにAIツールやエージェントを使用する従業員や事業部門の実態にまで及ぶ。IBMの「2026年データ侵害コストレポート」によると、セキュリティインシデントの43%は、従業員がシャドウAIを使用していることが原因となっている。ガートナーは、2030年までに、企業の40%以上が、不正なシャドウAIに関連したセキュリティまたはコンプライアンス違反を経験すると予測している。
シャドウAIがもたらす、コードレベルのシャドウITに直接関連する具体的なリスクは、AIコーディングアシスタントに独自のソースコードが渡ってしまうことです。従業員が承認されていないAIコーディングアシスタントを使ってレガシーCOBOLプログラムの作業を支援する場合、そのプログラムのソースコードが外部のAIプロバイダーに送られてしまいます。ソースコードには、ハードコードされた認証情報、企業秘密となるビジネスロジック、あるいはデータ所在地の要件に違反するデータ構造が含まれている可能性があります。この具体的なリスクを検出する方法は、ネットワークトラフィック分析ではなく、外部AI APIと通信するツールによってアクセスされたプログラムを検出することです。そのためには、ネットワークレベルの監視ではなく、アプリケーションレベルの監視が必要となります。
シャドウAI問題とシャドウアプリケーションソフトウェア問題は、重要な共通点を持っている。どちらも、SaaSシャドウIT市場を支配するネットワークベースの検出ツールでは検出できない。どちらも、アプリケーションレベルの監視か構造的なコード分析によってのみ顕在化できる。
完全なアプリケーションインベントリの構築
企業アプリケーションソフトウェアを対象としたシャドウIT発見プログラムの出力は、以下の4つの対象を網羅する調整済みインベントリです。
既知かつ文書化されているプログラム：公式のインベントリと実際の運用環境の両方に存在するプログラム。これらのプログラムには、ガバナンスの適用範囲、割り当てられた所有者、変更管理履歴、災害復旧計画が整備されています。
既知だが未展開：公式インベントリには記載されているものの、ロードライブラリや本番実行ログには見当たらないプログラム。これらは廃止候補であるか、正式な廃止手続きを経ずに既に廃止されているか、あるいは記載内容が誤っている可能性があります。
正体不明だが展開されているプログラム（シャドウプログラム）：本番環境の実行ログやロードライブラリには表示されるものの、公式のインベントリには登録されていないプログラム。これらはシャドウITの中核となる発見事項であり、直ちに所有者の割り当て、セキュリティ評価、ガバナンス登録が必要となるプログラムです。
文書化されていない依存関係：公式のインベントリにも主要な本番実行ログにも記載されていないが、動的CALL解析やデータフロー追跡によって本番プロセスからアクセス可能であることが判明したプログラム。これらはゴーストプログラムであり、発見が最も困難で、発見されないまま放置すると最も危険である。
これら4つの集団間の和解により、行動計画が策定される。すなわち、非公式プログラムを登録し、そのセキュリティ体制を評価し、所有権を割り当て、その処分方法（管理・維持、近代化、または廃止）を決定する。
認定条件 SMART TS XL コードレベルのシャドウIT検出を実行する
SMART TS XLのシャドウIT検出へのアプローチは、ネットワークベースのツールでは到達できないコードレベルのカテゴリに対応しています。
静的コード解析機能は、ソースリポジトリの完全な走査から始まります。環境内のすべてのCOBOLプログラム、RPGモジュール、PL/Iアプリケーション、Javaサービス、Pythonスクリプト、およびJCLジョブストリームは、ソースの場所、言語、サイズ、および予備的な複雑性プロファイルとともにカタログ化されます。このインベントリは、CMDBと公式アプリケーションレジストリを照合するための基準となり、ソースリポジトリには存在するが公式インベントリには存在しないプログラムが、主要なシャドウアプリケーション検出対象となります。
アプリケーション依存関係マッピングは、動的CALLの問題を解決します。プログラム名が変数である動的呼び出しを含む、すべてのプログラム内のすべてのCALLステートメントをトレースすることで、依存関係マップは、静的スケジューラインベントリに存在しない場合でも、本番プロセスからアクセス可能なプログラムを特定します。独立したJCLジョブ定義を持たない場合でも、10個の本番プログラムから動的に呼び出されるゴーストプログラムは、依存関係マップに表示されます。
JCL展開機能は、すべてのJCLジョブストリームの実行チェーン全体を追跡します。具体的には、PROC参照の解決、シンボリックパラメータの展開、各ジョブが呼び出すプログラムの完全なマップの構築を行います。このマップを公式のジョブスケジュールドキュメントと比較することで、ドキュメントの網羅性がないまま本番環境で実行されるジョブとプログラムが自動的に特定されます。
影響分析機能により、発見された結果を実用的なものにすることができます。発見されたシャドウプログラムごとに、それに依存するすべての本番プロセスを列挙します。依存関係のないシャドウプログラムは、廃止しても問題のないデッドコード候補です。一方、20個の本番依存プロセスを持つシャドウプログラムは、文書化されていない重要な資産であり、直ちにガバナンス上の対応が必要です。影響範囲によって、修復の優先順位が決まります。
エンタープライズ検索機能により、インベントリ全体をクエリ可能になります。特定のデータセットにアクセスするすべてのプログラム（潜在的なシャドウデータパイプライン候補）、特定の日付以降に作成されCMDBエントリがないすべてのプログラム（最近のシャドウアプリケーション）、標準データ管理階層外の外部ファイルパスに書き込むすべてのプログラムを検索できます。この検索機能は、初期検出作業と、初期クリーンアップ後にシャドウアプリケーションの蓄積が再開するのを防ぐ継続的な監視の両方をサポートします。
レガシーシステムの近代化プログラムを実施する組織にとって、シャドウアプリケーションの発見は必須のステップです。公式のアプリケーションインベントリに基づいて移行範囲を決定し、実行途中でシャドウプログラムを発見するような近代化プログラムは、計画段階で範囲、スケジュール、予算のすべてが間違っていたと言えます。計画前に実施されるべきだった発見が、最もコストがかかる実行段階で行われることになるのです。
ガバナンスの対応：ブロックではなく、可視性
2026年にシャドウITを効果的に管理できる組織は、全面的な禁止は効果がなく、逆効果を生み出すことを学んでいます。ほとんどの組織でシャドウITの報告がうまくいかない理由はただ一つ、従業員が罰を期待しているからです。財務チームのメンバーが承認されていない経費追跡ツールを使用し、それを自己申告した場合、セキュリティチームが叱責で対応すれば、その従業員だけでなく、その従業員が話をするすべての人が、次回は黙っているように訓練されてしまうのです。
シャドウアプリケーションソフトウェアにも同じ原則が適用されます。組織が依存する業務上重要なCOBOLユーティリティを構築した開発者は、当時明確に伝達されていなかった可能性のあるガバナンスプロセスを経ていないことを理由に罰せられるべきではありません。シャドウアプリケーションの発見に対するガバナンス対応は次のとおりであるべきです。
削除ではなく登録が重要です。業務プロセスのクリティカルパスに存在することが判明したシャドウプログラムは、削除すべきシャドウプログラムではなく、ガバナンスの適用が必要な、文書化されていない本番アプリケーションです。登録を行い、所有者を割り当て、セキュリティ体制を評価し、他の本番アプリケーションと同様のガバナンス規律で管理する必要があります。
自己開示に対する恩赦。事業部門が構築した非公式アプリケーションを開示するための安全なチャネルを提供するガバナンスプログラムは、あらゆる技術的な発見手法よりも迅速にシャドウソフトウェアを明らかにします。開示によって懲戒処分ではなく、ガバナンス支援、文書化支援、セキュリティレビュー、正式な登録につながるという保証は、隠蔽する動機を排除します。
プロセスによる予防。シャドウアプリケーションの蓄積の根本原因は、ガバナンスの摩擦です。新規アプリケーション開発を要求する公式プロセスが、ビジネス上の課題の解決に必要な速度よりも遅いのです。この摩擦を軽減し、軽量で迅速な開発ガバナンス、事業部門へのITガバナンスサポートの組み込み、低リスクの内部ツールに対する合理化された承認プロセスを導入することで、継続的な技術的調査を必要とせずに、新規シャドウアプリケーションの作成率を低減できます。
あなたが持っていると思っている在庫は、あなたが持っている在庫ではありません
IT部門が管理するアプリケーション一覧と、企業環境で実際に稼働しているアプリケーションソフトウェアとの間の差異は、決して軽微なものではありません。数十年にわたりアプリケーションを蓄積してきた大規模組織では、文書化されたものと実際のものとの間のギャップが、プログラム全体の30%にまで及ぶことがあります。文書化されていないこの30%には、機密データを処理するプログラム、規制遵守機能を実行するプログラム、ビジネスプロセスのクリティカルパス上に位置するプログラム、そして誰もその脆弱性を認識せずに放置してきたために誰もレビューしていないセキュリティ脆弱性を抱えたプログラムが含まれます。
SaaSのシャドウIT検出ツールは、この問題のクラウド層にうまく対処します。しかし、コードレベルのシャドウIT問題、つまり企業のレガシー環境に蔓延するカスタムプログラム、ゴーストユーティリティ、非公式なデータパイプライン、文書化されていないバッチジョブといった問題には、ネットワークトラフィックの監視ではなく、実際のソフトウェアアーティファクトの構造分析という、異なるアプローチが必要です。この分析から得られるインベントリは、その網羅性においてしばしば驚くべきものです。この作業を行う組織は、本番環境で稼働していると思っていたものと、実際に稼働しているものが、大きく異なることに一貫して気づきます。このギャップを埋めることが、組織の実際の運用状況を把握することを前提とする、あらゆるガバナンス、セキュリティ、BCP、および近代化プログラムの基盤となります。
