1. 結論：IT保守・MSPなら、何から始めるか
IT保守・MSPでAIを使うなら、最初の一手は変更IDの採番です。顧客環境への変更を受け付けた時点でIDを振り、実施・検証・その後の障害までをそのIDへ戻す。次が権限台帳を「承諾の範囲」として作り直すこと、その次が漏えい疑いの初動を「委託元への速やかな通知」を出口として手順化することです。
本記事では、顧客企業のサーバー・端末・ネットワーク・クラウドを月額契約で継続的に監視・保守し、顧客から付与されたIDと権限でリモートまたは現地から操作する事業者を主なモデルとして想定します。受託開発が主の会社、SaaS企業、クラウド基盤の提供事業者は、負う責任も制度も変わるため範囲外です。
この順番になるのは、この業種の仕事が「他人のシステムに、承諾の範囲でだけ触る」イベント処理で動いているからです。アラート・障害・変更依頼が起点になり、そのたびに技術者が顧客の電子計算機を操作します。「対応できるか」の前に「対応してよい範囲か」が問われます。
一方で、AIに渡せない判断もはっきりしています。本番環境を変える承認、データを戻す時点の決定、漏えい疑いで顧客へ何をいつ伝えるかの判断は、人が持ちます（節6）。
判断は人が持ったまま、判断に至るまでの仕事の大半は機械に渡せます。ただし、IDの採番・状態の遷移・成否の集計・完全一致の照合はITSMや監視・バックアップ製品などルールと専用処理の仕事であり、生成AIは自由記述からの抽出、候補の生成、要約、草案を担います。AIが作るのは候補と草案であり、確定するのは人です。この原則は記事全体を貫きます。
2. 業務全体の流れ
IT保守・MSPの仕事は、受注前の環境調査から契約終了時の権限返却まで、ひとつながりです。
| 段階 | 主なこと |
|---|---|
| 1. 相談・環境調査 | 構成・機器・既存契約を棚卸しし、不明な機器や管理者アカウントを見つける |
| 2. 契約・責任分界・権限設計 | 対象範囲、対応時間、誰の承諾でどのIDをどこまで使うか、クラウド事業者・再委託先との責任の切れ目を決める |
| 3. 導入 | 監視を入れ、構成を取り込み、顧客環境のどこに個人データがあるかを確認する |
| 4. 日々の運用 | アラートの分類と一次切り分け、障害対応、問い合わせ対応 |
| 5. 周期の運用 | パッチ・脆弱性対応、バックアップの成否確認、復元テスト、権限の棚卸し |
| 6. 変更 | 変更依頼を受け、影響評価・承認・実施・結果確認を行う |
| 7. 事故 | セキュリティ事象・漏えい疑いの初動と、委託元への通知 |
| 8. 報告・請求 | 月次の稼働報告と、契約外作業の請求 |
| 9. 更新・終了 | 契約の更新・追加提案、または終了時の権限失効・データ返却 |
変更の起点は二つあります。顧客起点の変更（段階6）は契約の範囲内かの判定があり、契約外なら請求につながります。パッチ・脆弱性対応（段階5）は契約内の周期作業で、請求を伴いません。
契約が終わっても、残ったIDや監視の接続が失効するまで承諾の範囲は続きます。
3. AI導入優先Top3
Top 1：変更IDを採番し、実施・検証・変更起因障害まで変更IDへ戻す
何をするか。変更依頼を受け付けた時点で変更IDを振り、対象資産・依頼者・希望日・ロールバック手順の有無を記録します。実施後に想定影響と実稼働の差分を確認し、変更後一定期間内に起きた障害をその変更IDに紐づけます。
なぜ最初か。変更は発生頻度が高く、障害の切り分けでは直前の変更が最初に確認する原因候補になります。後半（実施記録・検証・ロールバック・変更起因の障害）が工程として無い会社であれば、記録を足すだけで始められます。
どう始めるか。1顧客だけで構いません。変更依頼が来るたびに、変更ID・依頼者・対象資産・実施日・実施者・ロールバック手順の有無の6項目を1行で記録します。変更後2週間以内の障害には変更IDを手で書き添えます。2週間は初期値です。影響が遅れて出る変更もあるため、種類ごとに監視期間を変えられる様式にします。採番と記録はチケット管理（ITSM）で足り、AIを入れるのは記録が回り始めてからです。
何を測るか。
- 変更IDが無いまま実施された変更の件数
- 承認を得ないまま実施された変更の件数
- 変更後の監視期間内（初期値2週間）に起きた障害の件数
注意。変更IDの採番と状態の遷移はITSMが持ちます（節1）。AIが担うのは、影響を受ける資産・停止時間・リスクを並べた影響評価案と、変更後の障害との関連候補までです。変更を承認するのも、想定外の影響が出たときに戻すかどうかを決めるのも人です（節6）。紐づけは「変更の後に起きた」という事実であって、因果の確定ではありません。
Top 2：権限台帳を「承諾の範囲」として作り直し、失効を工程にする
何をするか。顧客ごとに、ID・認証経路・MFA・秘密鍵・APIキー・緊急用ID・共有ID・再委託先・利用可能時間帯・作業範囲を一覧にし、契約で確認したアクセス管理者の承諾と結びつけます。技術者の退職・交代、契約終了のたびに台帳を更新し、失効します。
なぜ2番目か。顧客のIDを使った操作の適法性は承諾の範囲で決まります（節6）。既存契約の中で「IDごとの承諾書」を1枚足すだけで始められます。
どう始めるか。直近に契約した1顧客で一覧を作り、その権限の付与を承認できる立場の人の確認を得ます。窓口の担当者が承諾を出せるとは限らないため、アクセス管理者か正式な承認権限者かを確かめます。次に、過去1年に退職・交代した技術者が知り得たIDが変更されているかを確認します。
何を測るか。
- 承諾書と対応しないIDの件数
- 退職者が知っていたIDを失効するまでの日数
- 棚卸しで見つかった不明アカウント・過剰権限の件数
注意。IDと台帳の完全一致の照合はルール処理で足ります。AIが担うのは、入退社連絡など自由記述からの抽出と棚卸し差異の候補整理までです。管理者権限の付与と失効を承認するのは、アクセス管理者として承諾を出す者と自社の責任者です。
Top 3：漏えい疑いの初動を「委託元への速やかな通知」を出口として手順化する
何をするか。顧客環境のどこに個人データがあるか（要配慮個人情報を含むか）を先に記録しておき、漏えい疑いが出たときに証跡と突き合わせて影響範囲を整理し、委託元である顧客へ速やかに通知する手順を作ります。
なぜ3番目か。発生頻度は低い一方、発生時には契約そのものを失い得ます。報告対象事態に当たれば、法令上は委託元と委託先の双方が報告義務を負い得ます。委託先の委員会への報告義務が免除されるのは、報告義務を負う委託元へ、所定の事項を、速やかに通知したときです（節9）。この構造が工程に落ちていなければ、「原因が分かるまで黙っている」初動になります。
どう始めるか。個人データを多く持つ1顧客から、所在を顧客に確認して記録します。次に、通知に必要な項目（概要・項目・本人数・原因・二次被害のおそれ・本人への対応・公表・再発防止）を様式にして、机上演習を1回行います。
何を測るか。
- 所在の記録がある顧客の割合
- 机上演習で、事態を知ってから通知案ができるまでの時間
- 通知案に「不明」として残る項目の数
注意。AIが担うのは、影響範囲の候補整理と通知案の草案までです。本記事では、通知の要否・内容・時期の判断を自社の責任者に置き、委員会への報告は通知を受けた委託元が判断する運用を推奨します。不明は不明のまま通知します。AIの「無い」を鵜呑みにしません。
4. AIに任せやすい仕事
この業種でAIが主に担えるのは、次のような性質の作業です。
| 性質 | IT保守・MSPでの具体例 |
|---|---|
| 形を整える | 監視イベントを資産・重大度・既知パターンで分類し、重複と既知のノイズを抑える |
| 照らし合わせる | 脆弱性情報の自由記述（影響する製品・条件）を資産台帳の候補と対応づける、入退社連絡を権限台帳の差異候補に落とす |
| 違いを見つける・足りないものを探す | 監視データと構成台帳の差異、変更後の想定影響と実際の差分、権限棚卸しの差異（不明アカウント・過剰権限）を出す |
| 下書きを作る | 障害の第一報、影響評価案、月次報告、契約外工数の明細、漏えい疑いの通知案を起こす |
| 探し出す | 障害候補を過去チケット・ナレッジ・ベンダーの既知情報と照合し、類似事象と当時の対処を引く |
バックアップの成否は監視・バックアップ製品が集計します。AIに入るのは失敗ログの分類と要約までで、「成功」は復旧できることを意味しません（節6）。
5. AI支援に向く仕事
次は、AIが案を出し、人が確認してから使う領域です。
- 原因候補の提示——ログ・構成・過去チケットから出せます。候補は候補として記録し、確定した原因と区別します
- ベンダー障害の原因区分の仮判定——自社作業起因かベンダー基盤か顧客側操作かの仮判定を出せます
- 復元テスト未達の原因候補——実測値と目標値の突合は表計算や監視の処理で、AIは未達の原因候補を記録から整理できます。本番へ戻す判断は含みません（節6）
6. 人に残す仕事・判断
線の引き方の原則は、「AIが答えを出せるか」ではなく「誰がその答えに責任を持つのか」です。この業種に業務独占の資格はなく、以下の確定者は法令の定めではなく、本記事が推奨する運用です。
承諾の範囲を決める・変える
不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）は、他人のIDを入力してアクセス制御を解除する行為を不正アクセス行為と定め、アクセス管理者またはそのIDの利用権者の承諾を得てするものを除くとしています（第2条第4項第1号）。誰がアクセス管理者（電子計算機の動作を管理する者。第2条第1項）に当たるかは、誰が利用者と権限を決定しているかという実態と契約関係で確認します。運用を受託しても、常に顧客が管理者になるとは限りません。契約時に承諾を出す者を確認したうえで、どのID・経路・範囲で承諾を得るか、管理者権限の付与と失効を誰が決めるかを、その承諾者と自社の責任者が決めます。特権IDも、現地で「ついでに」頼まれる作業も、承諾の範囲の内側かどうかで見ます。
他人の本番環境を変える
変更の承認、ロールバックの可否、パッチ未適用のリスク受容——顧客の事業を止め得る決定は、顧客側の承認者と自社の責任者が確定します。
復旧のためにデータを戻す
バックアップの成否集計と、復旧の可否判断は別の仕事です。「成功」はジョブの終了であって、その時点へ戻せる意味ではありません。復旧できるかの根拠は復元テストの実施結果だけです。どの時点へ戻し、データ欠損と事業停止を受け入れるかは、顧客と自社の責任者が決めます。
漏えい疑いで、顧客へ何をいつ伝えるか
封じ込めの実施、委託元へ通知する要否・内容・時期、外部への相談の要否は、自社の責任者が確定します。委員会への報告は、通知を受けた委託元が判断します。
ベンダーの責任と自社の責任の線を、顧客に言う
クラウドや回線の障害で原因を区分し、自社が何をして何をしないかを顧客に説明する内容は、自社の責任者が確定します。責任の所在は顧客・自社・クラウド事業者の契約とサービス範囲で異なるため、責任分界と情報連携の役割を契約で確認して説明します。責任分界の外でも「関係ない」と言う立場ではありません。
他人のシステムで実行する手順は、AIが90%正しくても人が全部確認します。精度ではなく影響の不可逆性の問題です。
7. Best Practice
到達点として、次の4つの構造を示します。
ひとつ。資産ID・構成・変更ID・障害IDを接続し、変更の結果を変更IDへ戻す。障害時に、資産IDから依存関係と直近の変更・パッチを引いて原因候補にできる状態です。
ふたつ。承諾の範囲を権限台帳で持ち、承諾の始点と終点を工程として置く。契約時の承諾が台帳の初版になり、権限の付与・剥奪と、技術者交代時・契約終了時の失効が同じ台帳の更新になる状態です。台帳で分からない承諾の範囲は、技術者の善意に適法性を依存させていると整理しています。
みっつ。責任分界表を「障害時に誰が何をするか」の順序で書く。自社作業起因・ベンダー基盤・顧客側操作・回線の別に、誰が一次窓口になり自社は何をし何をしないかを書いた表です。責任分界と対応範囲は別の項目だという設計になります。
よっつ。漏えい疑いの初動を「委託元への速やかな通知」を出口として設計する。所在の記録を先に持てている形です（節3）。
8. Before / After
Before。変更依頼はチャットで受けて夜間に実施し、翌朝に口頭で共有する。管理者パスワードは共有ファイルにあり、退職者が知っていたものが変わっているかは誰も確認していない。バックアップの成功ログは毎朝見るが、復元は障害時に初めて試す。クラウドが止まると「待つしかない」と答える。
この流れには理由があります。少人数で多数の顧客環境を見ていれば、記録より復旧が優先されます。
After。変更は変更IDを持ち、影響評価から検証までが並び、変更後の障害が変更IDへ戻ります。権限台帳は承諾の範囲として作られ、退職者のIDは交代時に失効します。復元は実測の時間で語られ、クラウド障害は責任分界表に照らして顧客へ説明されます。
変わるのは「技術力」ではありません。「触ってよい範囲・触った記録・触った結果が、1本の台帳で追えるか」です。
9. 法令・規制・情報管理
この業種で押さえておきたい制度を、誰に義務があるかという観点で整理します。以下は本記事における実務上の整理であり、個別の適用は契約と事実関係によります。
顧客システムへのアクセス——不正アクセス禁止法
承諾の範囲外の操作は不正アクセス行為に当たり得ます（節6。第2条第4項第1号）。何人もこれをしてはならず（第3条）、違反には3年以下の拘禁刑または100万円以下の罰金が定められています（第11条）。操作した技術者個人と会社の両方にリスクがあります。
また、業務その他正当な理由による場合を除き、他人のIDをアクセス管理者と利用権者以外の者に提供してはならないという規定があります（第5条）。再委託先へ顧客のIDを渡す場面が該当し得るため、「業務」に当たる範囲を契約で明示します。
一方、IDの適正管理やアクセス制御の有効性検証・防御措置はアクセス管理者の努力義務です（第8条）。顧客がアクセス管理者に当たる範囲では自社は代わって実装する立場で、自社が管理者に当たる範囲では自社の努力義務です（節6）。
個人データの委託先としての立場——個人情報保護法
顧客が個人データを含む環境の運用を自社に委託することは第三者提供ではなく委託であり、顧客には委託先を監督する義務があります（第25条・第27条第5項第1号）。安全管理措置（第23条）は顧客と自社がそれぞれ負います。
漏えい等の報告対象事態に該当する場合、原則として委託元（顧客）と委託先（自社）の双方が、個人情報取扱事業者として報告義務を負い得ます。要配慮個人情報を含むもの、財産的被害のおそれがあるもの、不正の目的による行為に起因するもの、本人の数が1,000人を超えるもの（発生のおそれを含む）が報告対象です（第26条第1項本文、同法施行規則第7条）。ただし、委託先が、事態を知った後速やかに、規則で定める事項を報告義務を負う委託元へ通知したときは、委託先は個人情報保護委員会への報告義務を免除されます（第26条第1項ただし書、同規則第9条）。免除には、通知先が報告義務を負う委託元であること、規則所定の事項であること、速やかであることが必要です。委託元へ連絡したという事実だけで、委託先の報告義務が常になくなるわけではありません。本人への通知義務も、この通知をした委託先は除かれます（第26条第2項）。委託元の確報期限は事態を知った日から30日以内（不正の目的による場合は60日以内）であり（同規則第8条第2項）、自社は証跡・原因・再発防止の資料をその期限に合わせて組成します。
再委託と受託——取適法（旧下請法）
製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律（取適法）は、資本金の基準に加えて従業員数の基準を持ちます。プログラムの作成と、運送・倉庫での保管・情報処理の役務は300人の基準側、それ以外の情報成果物作成委託・役務提供委託は100人の基準側です（第2条第8項第5号・第6号、同法政令）。外注する会社は自社が委託事業者に当たるかを確認します。なお、顧客が自ら使う環境の保守を委託する取引は、原則として「業として行う提供の目的たる役務」の委託ではありません。
常駐・現地作業——業務委託と労働者派遣の区分
常駐形態では、顧客の担当者から技術者へ直接作業指示が出る運用が、労働者派遣（自己の雇用する労働者を他人の指揮命令を受けて労働に従事させること。労働者派遣法第2条第1号）に近づきます。「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）は、業務遂行方法・労働時間・秩序維持の指示管理を自ら行い、かつ資金・法的責任・専門技術等に基づき自己の業務として独立して処理する場合を除き、労働者派遣事業を行う事業主とし（第2条）、故意の偽装は免れないとしています（第3条）。
その他、形態によって効くもの
- 電気通信事業法——顧客設備の運用だけなら、通常は「電気通信役務を他人の需要に応ずるために提供する事業」（第2条第4号）に当たりません。自社設備でVPN・メール等を提供する形態は該当性を確認します（専ら一の者に提供する事業などの適用除外は第164条第1項）
- 著作権法——プログラムの複製物の所有者は自ら実行するために必要な限度で複製できます（第47条の3第1項）。ライセンス超過は自社が提示し、是正の判断はライセンシーである顧客が行います
施行前の改正
- 改正労働施策総合推進法（令和7年法律第63号）は、2026年10月1日に施行される予定で、カスタマーハラスメント対策の措置が事業主の義務となります。指針は「顧客等」に取引先の担当者を、「職場」に取引先の事務所を含めています。現時点の義務ではありませんが、相談体制と方針の周知の準備が要ります
- 改正個人情報保護法は2026年7月17日に公布されました。施行期日は原則として公布の日から起算して2年を超えない範囲内で政令が定める日とされており、現時点では施行日が確定していません。委託先が委託業務の遂行に必要な範囲を超えて個人データを取り扱ってはならない旨の明文化や、本人通知義務の緩和が含まれます
生成AIへ投入する情報の条件
自社は顧客の個人データ・ID・鍵・構成図・障害履歴・ログを扱います。外部へ情報を渡す場合は、第三者提供・委託その他のどの類型に当たるかを確認し、必要な同意・通知・契約・委託先の監督等を行います。生成AIへ投入するときは、次で線を引きます。
- 必要最小限にする（顧客のIDと業務データの中身は入れない）。IPアドレスやユーザー名を一律に伏せればよいわけではありません。調査に要る識別性との兼ね合いで決め、AIへ渡す加工済みのデータと、証拠として保全する原本は分けて持ちます
- AI事業者が入力データを学習に使わない設定・契約か
- 保存期間と削除の方法
- 顧客との契約上の機密保持とデータの取扱条件
- アクセス権限と利用ログが残るか
- 再委託・国外保存など、自社の規程上決めておくべき事項
そのうえで、顧客の情報を扱うのは会社が利用を承認したアカウント・サービスに限ります。
法令・制度の記述について
※法令・制度に関する記述は、内容確認日時点の一般的な整理です。実際の適用は、業務内容、契約関係、事業規模、地域、施行時点の法令・行政解釈等によって異なります。重要な判断は、最新の一次情報と自社の具体的な条件を確認してください。
10. 最初の30日プラン
1週目：測ることから始めます。1顧客を対象に、①変更の発生件数と変更IDが採番された件数 ②変更後の監視期間内の障害件数 ③使っているIDの数と承諾書・台帳に載っている数を記録します。この週はAIを使いません。
2週目：ルールを決めます。変更IDの採番規則と記録の6項目、権限台帳の様式（Top2 の項目＋承諾者・承諾日・失効日）を決め、1顧客分を作ります。AIへ投入してよい情報の線引き（節9）を決め、承認前に実施しない運用を技術者全員と共有します。
3週目：低リスクな範囲でAIを使います。構成と依存関係から影響範囲の候補を出す作業を過去の変更で試します。入退社連絡と台帳の突合は、2週目に作った台帳の範囲で。アラートの分類は「抑制候補」のタグを付けるだけにして人が見ます。
4週目：同じ測り方で比べます。①変更IDの無い実施が減ったか ②影響範囲の抽出時間が減ったか ③人の確認工数が増えていないか。③が増えているなら、AIの精度ではなく入力の問題です。
11. AI活用成熟度
自社がどの段階にあるかを判定してみてください。
レベル1：人に依存している。顧客環境の構成・パスワード・過去の障害は担当技術者の頭の中にあり、担当が退職すると誰も説明できません。
レベル2：台帳やツールがある。監視ツール・チケットシステム・資産台帳はありますが、変更・権限・バックアップは別々の場所にあり、資産IDで横断できません。責任分界は契約書の除外事項にだけあります。
レベル3：一元化されている。資産IDに構成・変更ID・障害ID・権限台帳が紐づき、責任分界表が障害時の動きを含み、退職者の失効が工程にあります。
レベル4：AIが支援している。分類・照合・差分・集計はルールと専用処理が、候補と下書きはAIが担い、人は承認と顧客説明に時間を使っています。判断は動いていません。
レベル5：仕組みになっている。この段階は「AIが本番環境を自律的に変更する」ことではありません。技術者が「承諾の範囲内か」「変更の結果はどうだったか」を調べる時間を使っていない状態です。
12. よくある質問
バックアップが毎日成功していれば、復旧は大丈夫でしょうか。
「成功」はジョブの終了であり、戻せる保証ではありません。根拠になるのは復元テストの実施結果だけです（節6）。
漏えいが疑われたとき、個人情報保護委員会への報告は自社がするのですか。
法令上は顧客と自社の双方が報告義務を負い得ます。免除されるのは、報告義務を負う委託元へ、所定の事項を、速やかに通知した場合だけです（節9）。「代わりに報告する」でも「無関係」でもありません。
クラウドが止まったとき、自社に責任はありますか。
責任の所在は契約とサービス範囲で異なるため、責任分界と情報連携の役割を契約で確認します。責任分界の外であることと何もしないことは別です（節6）。
常駐の技術者に顧客の担当者が直接指示を出していますが、問題ありますか。
契約の名称ではなく、告示の要件に照らして実態で判断されます（節9）。指示管理を顧客側が行っているなら、作業指示の経路を自社側に置くことを検討してください。
13. 関連する業種の記事
- SIer・受託開発会社のAI活用——成果物の作成が主論点で、取適法と著作権の帰属が効きます
- SaaS企業のAI活用——変更の起点が自社のプロダクト計画にあり、請求を伴いません
- コールセンター・BPOのAI活用——顧客別の応対ルールの版管理が、本業種の権限・責任分界の版管理と対照になります
シリーズの一覧は業種別AI活用からご覧いただけます。
14. この記事を自社に当てはめたい方へ
同じIT保守・MSPでも、情報の整理状況によって最初の一手は変わります。変更の記録が残っていない会社は「1顧客で6項目を記録する」から、記録はあるが実施後の検証が無い会社は「変更後の障害を変更IDへ戻す」から始めるほうが無理がありません。
15. 無料AI戦略診断／AI顧問サービス
AI戦略診断は無料・登録不要です。回答すると、自社のAI活用がいまどの段階にあるかと、最初に取り組むべき領域が分かります。
より踏み込んだ伴走をご希望の方は、AI顧問サービスもご覧ください。個別のご相談はお問い合わせから承ります（30分の無料リモート面談）。
最終更新日: 2026年8月27日／内容確認日: 2026年8月27日
