業務アプリ統制の「損切り」ライン：一人情シスが守るべきは全アプリではなく「急所」のみ

「社内で使われているSaaSを全て把握し、管理下においてください」

セキュリティコンサルタントや監査法人の先生は、涼しい顔でそう言います。 CASB（Cloud Access Security Broker）やSSPM（SaaS Security Posture Management）といった横文字のソリューションも、「可視化こそが正義」と謳います。

理想は分かります。全てのアプリがIT部門の管理下にあり、誰がいつアクセスしたかログが残っており、退職と同時に権限が剥奪される。それが「あるべき姿」でしょう。

しかし、実務の現場を知る私は断言します。兼務や一人情シスの体制で、「全ての業務アプリを統制しようとする」のは、組織を機能不全に陥らせる危険な行為です。

本稿では、理想論という重圧に押し潰されそうな一人情シスに向けて、**「何を管理しないか（What NOT to do）」**を定義するための、現実的な防衛戦術を提示します。

1. 「全数把握」という名の沼

なぜ、全てのアプリを管理しようとしてはいけないのでしょうか。それはシンプルに、「変化のスピード」と「情シスの処理能力」の非対称性が原因です。

圧倒的な物量の差

社員数100人の会社で、各部署が「業務効率化」のために新しいツールを探しているとします。

営業：名刺管理アプリ、日程調整ツール
開発：GitHubのプラグイン、デザインツール、テスト自動化SaaS
マーケ：SEO分析、SNS運用ツール、配信スタンド
総務：備品管理、座席表アプリ

これらは月額数百円、あるいは無料で、クレジットカード一枚で利用開始できます。一方で、それを審査し、台帳に登録し、設定を確認する情シスは「一人」です。 1対100の戦いです。あなたが1つのSaaSの利用規約を精読している間に、現場では3つの新しいSaaSが契約されています。このイタチごっこに勝機はありません。

管理コストの指数関数的増大

アプリが10個なら管理は容易ですが、50個、100個となると、管理コストは直線的ではなく「指数関数的」に増えます。「あのツールの管理画面、どこだっけ？」と思い出す時間、パスワードリセットの手間、API仕様変更の対応……。これらを全て背負い込もうとすると、あなたは「会社の守護者」ではなく、単なる「パスワードリセット係」に成り下がります。

2. 「やらない」と決めるべき3つの統制

では、具体的にどの業務を「捨てる」べきなのでしょうか。以下の3つの領域は、リスクベースで判断し、大胆に手放すべきです。

1. 「SSO非対応アプリ」のID管理

OktaやEntra IDなどのIdP（IDプロバイダー）でSSO（シングルサインオン）連携できないSaaSのアカウント管理まで、情シスが手動でやっていませんか？

【決定事項】SSO非対応アプリのID発行・削除は、情シスでは行わない。

理由：手動でのID作成・削除はオペレーションミスの温床であり、情シスの時間を最も奪う「作業」です。
代替案：利用部門のマネージャーに権限を委譲します。「このツールは情シス管理外（Tier 3）です。利用部門の責任で、退職時の削除を行ってください」という誓約書（チェックリスト）を交わすだけで十分です。

2. 「無料・安価ツール」のセキュリティチェックシート

現場が「月額500円の便利ツールを使いたい」と言ってきた時、A4用紙10枚に及ぶ「クラウドサービスセキュリティチェックシート」の記入をベンダーに求めていませんか？あるいは、情シス自身がプライバシーポリシーを読み込んでいませんか？

【決定事項】重要データを扱わないTier 3アプリは、簡易チェックのみで許可する、あるいは事後届出とする。

理由：月額500円のサービスを提供しているスタートアップが、詳細なチェックシートに回答してくれるはずがありません。回答を待っている間に現場の熱量は冷めます。
代替案：「個人情報」「機密情報（顧客リスト、設計図など）」を入れないという条件付きで、利用規約のざっと見だけでGoを出します。リスクの大きさと、確認コストのバランスを取ってください。

3. 「野良SaaS」のヘルプデスク

「自分で勝手に契約したNotionの使い方が分からないんだけど」「変換ツールがうまく動かない」

【決定事項】情シスが選定・導入に関与していないアプリの使い方は、一切サポートしない。

理由：これを一度でも受けてしまうと、「パソコンの画面に出るものは全て情シスが直してくれる」という誤った期待値が醸成されます。
代替案：冷徹に聞こえるかもしれませんが、「それは公式サポートに聞いてください」と突っぱねることが、結果として組織のリテラシーを上げます。情シスのリソースは、全社共通の「Microsoft 365」や「基幹システム」の安定稼働に集中させるべきです。

3. 説明責任との折り合い

「そんなことをして、もし事故が起きたらどうするんだ」「監査で指摘されたらどう言い訳するんだ」

この恐怖心こそが、過剰統制の正体です。しかし、プロフェッショナルとしての情シスは、ここでも論理的に「やらない理由」を説明できなければなりません。

「リスクベース・アプローチ」という魔法の言葉

監査人や経営層には、こう説明します。

「我が社のリソースは有限です。全てのリスクをゼロにすることはできません。したがって、『情報資産の重要度』に基づいて管理濃度に傾斜をつけています（リスクベース・アプローチ）」

Tier 1（重要）：会計、人事、全社グループウェア。ここには顧客情報や財務情報が含まれるため、情シスがガチガチに管理し、SSOも強制し、ログも監視します。
Tier 2（部門）：営業支援、開発管理など。準・重要システム。情シスは「契約」と「権限設定のルール」だけ握り、日々の運用は部門管理者に委譲します。
Tier 3（個人・低リスク）：機密情報を扱わない便利ツール。利用は「禁止リスト方式（ブラックリスト）」で管理し、基本は性善説で許可します。情シスは関与しません。

このように**区分け（トリアージ）**を提示されれば、まともな経営者であれば「Tier 3まで情シスが管理するコスト」と「そこから情報漏洩するリスク（ほぼゼロに近い）」を天秤にかけ、あなたの提案を支持するはずです。

事故が起きた時の「免責」を握る

最も重要なのは、事前にこの合意形成をしておくことです。「Tier 3のアプリで、もし退職者のアカウント消し忘れがあったとしても、それは情シスの責任ではなく、管理を委譲された部門長の責任です」これを社内規定（IT利用ガイドライン）に明記し、部門長会議で周知します。

これは責任逃れではありません。権限と責任を一致させるという、健全なガバナンスです。情シスに権限（人事権や予算）がないのに、責任だけ負わせる構造の方が異常なのです。

結論：情シスの仕事は「監視」ではなく「交通整理」

一人情シスが目指すべきは、全ての車（アプリ）を検問する警察官ではありません。事故が起きやすい交差点にだけ信号機を設置し、あとはスムーズに流れるように道路を設計する「交通整理員」です。

「やらない」と決めることには勇気が要ります。しかし、あなたが疲弊して倒れてしまえば、それこそが会社にとって最大のリスクです。

全てのアプリを守ろうとして全滅するより、「会社の心臓部（Tier 1）」だけは死守し、末端は「カスり傷」で済むように設計する。その冷徹な計算と割り切りこそが、現代の業務アプリ統制には求められています。

今日から、現場からの「このアプリ使っていい？」というSlackに対して、1秒で「機密情報入れないならOK。使い方は自分で調べてね」と返せる準備を始めましょう。それが、あなたの時間を「攻めのIT」に取り戻す第一歩です。

AIに相談するためのプロンプト（テンプレート）

無数にあるSaaSを「管理する・しない」に仕分けし、リスクベースの管理台帳を作るためのプロンプトです。

あなたはITガバナンスとリスク管理のコンサルタントです。
現在、社内で利用されているSaaSを洗い出しましたが、数が多すぎて一人で管理しきれません。
記事にある「Tier（重要度）分け」の考え方に基づき、以下のアプリリストを分類し、それぞれの管理方針（情シスがやるか、現場に任せるか）を提案してください。

# 企業情報
*   社員数: [例: 100名]

# 洗い出したSaaSリスト
1.  [例: Microsoft 365（全社利用）]
2.  [例: Salesforce（営業部のみ、顧客情報あり）]
3.  [例: Canva（マーケ部、画像作成のみ）]
4.  [例: Trello（開発部、タスク管理）]
5.  [例: 調整さん（全社、日程調整）]

# 相談したいこと
1.  **Tier分類**: 各アプリをTier 1（情シス管理）、Tier 2（部門管理）、Tier 3（野良/個人管理）に分けてください。
2.  **管理ルールの策定**: Tier 2, Tier 3のアプリについて、情シスが責任を負わない（免責）ための「利用ガイドライン」の条文案を作成してください。