はじめに——本番GOの最後に立ちはだかるのは「技術」ではなく「人」
本連載はここまで、企業AI導入で多くの現場がつまずく3つの壁を順に越えてきました。第1回では「使われずに終わる（定着）」の壁を、第2回では「効果が見えない（ROI）」の壁を、そして第3回では「PoCから本番に進めない（PoC死）」の壁を扱いました。第3回の最後で予告したとおり、最終回手前の本稿が向き合うのは、技術でもコストでもない——「人」と「組織」の壁です。
本番GOの号令がかかった直後、展開が止まる典型的な理由がこれです。「現場は早く使いたいのに、IT部門（情シス）が慎重すぎて話が進まない」「IT部門はガバナンスを守りたいのに、現場が勝手にツールを使い始めてしまう」——どちらの声も、現場のリーダーからは日常的に聞こえてきます。
ここで強調したいのは、この対立は「どちらかが間違っている」から起きるのではないという一点です。早く使いたい現場も、ガバナンスを守りたいITも、どちらも自分の責任範囲で正当な懸念を持っています。問題は人の良し悪しではなく、両者の正当な主張を調停する「制度（ルール・責任分担・共通言語）の不在」にあります。
筆者はネットワークのNOC（ネットワークオペレーションセンター）とTAC（テクニカルアシスタンスセンター）で長年、運用部門（Ops）と開発・事業部門（Dev/Business）の古典的な緊張関係を間近で見てきました。「止めたくない事業側」と「壊したくない運用側」——この対立を、ネットワーク運用は変更諮問（CAB）・RACIによる責任分担・SLAという共通言語で橋渡ししてきました。本稿の核心は、その運用の知恵が、そのまま「現場とIT部門のAIをめぐる対立」の解消に転用できるという点にあります。
想定読者は、本番GOまで来たものの現場とIT（あるいは情シスと事業部）の温度差で展開が止まっている方、またはシャドーAIと統制のはざまで板挟みになっている、DX推進・情報システム・経営企画の担当者です。
なぜ対立が起きるのか——両者の懸念はどちらも正当
対立の根っこにあるのは、「速度」と「ガバナンス」のトレードオフです。現場が最大化したいのは業務スピードと成果であり、IT部門が最小化したいのは情報漏洩・コンプライアンス違反・運用破綻のリスクです。この2つは本質的に引っ張り合う関係にあり、どちらか一方を完全に満たせば、もう一方が必ず犠牲になります。
重要なのは、両者の主張がそれぞれの責任範囲では完全に正しいことです。現場が「早く使わせてほしい」と言うのは、競合に後れを取らないための正当な事業判断です。IT部門が「待ってほしい」と言うのも、一度の情報漏洩が会社全体を揺るがしかねないことを知っているがゆえの正当なリスク管理です。正しい主張同士が衝突している——これが対立の正体です。
NOCの世界でも構図は同じでした。事業部門は「新サービスを今すぐ出したい」と言い、運用部門は「無停止の変更手順を踏ませてほしい」と言う。どちらも正しい。だからこそ、勝ち負けを決める「悪者探し」ではなく、両者の正当な懸念を制度の中で両立させる仕組みが必要になります。対立を「制度の不在」として捉え直すと、解くべき問題が「人の説得」から「設計」へと変わります。
対立の4類型——どこで火花が散るのかを見極める
「現場とITの対立」とひとくくりにしても、火花が散るポイントは大きく4つに分かれます。どの類型でつまずいているかを特定しないと、対策がかみ合いません。まずは自社の対立がどこに属するかを切り分けます。
| 類型 | 現場の正当な主張 | IT部門の正当な懸念 | 衝突が起きる場面 |
|---|---|---|---|
| ① スピード | 競合に勝つには今すぐ使いたい | 検証なしの導入は事故のもと | 導入承認のリードタイム |
| ② 責任所在 | 使った結果の責任を負わされたくない | 誰が責任を持つのか曖昧なまま広げたくない | インシデント発生時の責任分界 |
| ③ ツール選定権 | 業務に最適なツールを自分で選びたい | 野放図なツール乱立を統制したい | 新ツール採用の決定権 |
| ④ データの扱い | 手元のデータを自由に投入したい | 機密・個人情報の外部流出を防ぎたい | 入力可能なデータの範囲 |
多くの組織では、これら4類型が同時並行で起きています。そして厄介なことに、表面上は「①スピードの不満」として現れていても、根っこは「②責任所在が決まっていない不安」だった、というケースが少なくありません。対立を解く第一歩は、感情的な温度差の奥にある「どの類型の制度が欠けているか」を見極めることです。
「禁止」でも「放任」でもない第三の道——ガードレール付きの権限委譲
対立に直面した組織が取りがちな選択肢は、両極端のどちらかです。ひとつは「禁止」——「許可するまで一切使うな」という強い統制。もうひとつは「放任」——「各自の判断に任せる」という無管理。しかし、どちらも失敗します。
「禁止」は現場の正当な需要を地下にもぐらせ、シャドーAI（IT部門が把握していない無断利用）を生みます。統制したかったはずが、かえって可視化できない領域を増やしてしまう。「放任」は逆に、機密データの無防備な投入や、責任所在のない事故を野放しにします。
ネットワーク運用が選んだのは、その中間の第三の道——ガードレール付きの権限委譲でした。すべての変更を中央が握るのでもなく、誰でも何でも触れるのでもなく、「この範囲なら現場の裁量で進めてよい。ただし境界（ガードレール）を越えるときは諮問にかける」という設計です。これはセキュリティでいう最小権限の原則を、組織の意思決定に応用したものと言えます。
| アプローチ | 現場への影響 | ガバナンス上の帰結 |
|---|---|---|
| 禁止（過剰統制） | 需要が地下化しシャドーAI化 | 把握不能な領域が増え、かえって統制が効かない |
| 放任（無管理） | 自由だが事故時に責任所在が不明 | 機密流出・コンプライアンス違反のリスク露出 |
| ガードレール付き委譲 | 許可された範囲で迅速に動ける | 境界を明示し、越境時のみ諮問で統制 |
ガードレールを設計するとは、「やってよいこと／諮問が必要なこと／禁止すること」の3層を、現場が自分で判断できる粒度で言語化することにほかなりません。現場は境界の内側を全速力で走れ、IT部門は境界線だけを守ればよくなります。
共通言語をつくる——RACI・SLA・変更諮問の「軽量版」
対立が長引く組織には、共通の語彙がありません。現場は「使わせてくれない」と言い、ITは「ルールを守らない」と言う。同じ事象を別々の言葉で語っているため、議論がかみ合わないのです。ここで効くのが、ネットワーク運用がOpsとDevの橋渡しに使ってきた3つの共通言語の「軽量版」です。重厚なITILをそのまま導入する必要はありません。AI利用に必要な最小限だけを借りてきます。
① RACI——「誰が何の責任を持つか」を1枚で決める
対立の②責任所在は、RACI（実行・説明責任・相談・報告）で解けます。たとえば「生成AIで作った資料を顧客に出す」という行為について、実行（R）は現場担当、最終的な説明責任（A）は部門長、相談先（C）は情シス、報告先（I）はガバナンス担当、と1枚の表で決めておく。これだけで「事故ったら誰のせい？」という不安が消え、現場は安心して動けます。
② SLA——IT部門の「応答速度」を約束する
対立の①スピードは、現場の遅さではなくIT部門の応答が読めないことへの不満であることが多いものです。「新ツールの審査依頼は5営業日以内に一次回答する」といった軽量なSLA（サービス品質の約束）をIT側が掲げるだけで、現場は見通しを持て、勝手な導入に走る動機が減ります。SLAは現場を縛るためでなく、IT部門が現場に対して負う約束として設計するのがコツです。
③ 変更諮問（CAB）の軽量版——越境時だけ通す関所
すべてを諮問にかけると現場は窒息します。ガードレールを越えるとき（新しいデータ種別を扱う、外部公開する等）だけ通す軽量な関所を設けます。週1回・15分の定例レビュー、あるいは標準的なケースは事前承認済みリストで自動通過、といった運用にすれば、統制と速度が両立します。NOCの変更諮問も、標準変更（事前承認済み）・通常変更（諮問）・緊急変更の3区分で、止めるべきものだけを止めていました。
| 共通言語 | 解く対立類型 | 軽量版の実装イメージ |
|---|---|---|
| RACI | ② 責任所在 | 主要なAI利用シーンごとに責任分担を1枚の表で明示 |
| SLA | ① スピード | IT側が審査・回答の上限日数を約束 |
| 変更諮問（軽量版） | ③ ツール選定権 | 標準ケースは事前承認、越境時のみ短時間レビュー |
シャドーAIを”敵”でなく”需要シグナル”として読む
IT部門にとってシャドーAIは「統制を破る敵」に見えます。しかし視点を変えると、シャドーAIは「現場が公式チャネルでは満たせなかった切実な需要のシグナル」です。誰かがリスクを冒してまで無断で使うのは、それだけ業務上の必要があるからです。
NOCの世界でも、許可されていない通信（シャドーIT）の出現は、まず「遮断すべき脅威」であると同時に「現場が公式には用意されていない手段を必要としている証拠」として読まれました。やみくもに遮断するだけでは、需要は別の抜け道を探すだけです。
だからこそ、対応は2段構えになります。まず可視化——何が、誰に、どれだけ使われているかを把握する。これは本サイトのシャドーAI対策（無断利用の可視化・ポリシー設計）とAI利用ログ管理・監査（監視の仕組み）で扱った統制側の技術手順そのものです。そのうえで、可視化されたシャドーAIを需要シグナルとして読み解き、公式の許可ルートに「合流」させる。「禁止」ではなく「正規化」へ導くことで、現場の需要を満たしつつガバナンスの傘の中に取り込めます。
温度差を埋める運用設計——サンドボックス→許可リスト→展開
制度（RACI・SLA・諮問）という骨格ができたら、温度差を実際に埋める運用フローを設計します。鍵は、いきなり全社展開しない段階設計です。NOCのインシデント対応が「観測→緩和→展開」と階段を踏むのと同じく、AI利用も安全な実験から段階的に広げます。
| 段階 | 現場ができること | IT部門のガードレール |
|---|---|---|
| ① サンドボックス | 機密を含まないデータで自由に試行 | 環境を隔離し、入力データ種別を限定 |
| ② 許可リスト | 承認済みのツール・用途を本番業務で利用 | RACIと利用範囲を明示、ログを取得 |
| ③ 展開 | 成功事例を他部門へ横展開 | SLA・監査・人間承認ワークフローで統制 |
この段階設計の利点は、現場とITの双方に「次に進む条件」が見えることです。現場は「サンドボックスで実績を出せば許可リストに上がる」という前進の道筋を得て、IT部門は「各段階のガードレールさえ守られていれば前進を止めない」という安心を得ます。温度差は、相手を説得して縮めるものではなく、双方が同じ階段を共有することで自然に縮むのです。とくに③の展開段階では、重要な操作に人間承認ワークフローを組み込むことで、スピードを保ちながら最後の砦を残せます。
対立解消チェックリスト
自社の「現場とITの対立」がどこまで制度化できているかを点検するチェックリストです。チェックが付かない項目が、今まさに火花が散っているポイントです。
| 領域 | チェック項目 |
|---|---|
| 対立の特定 | 4類型（スピード／責任所在／ツール選定権／データ）のどこで衝突しているか言語化できている |
| 姿勢 | 「禁止」でも「放任」でもなく、ガードレール付きの権限委譲を方針として明文化している |
| 責任分担 | 主要なAI利用シーンについてRACIで責任所在が決まっている |
| 速度の約束 | IT部門が審査・回答のSLA（上限日数）を現場に提示している |
| 諮問の軽量化 | 標準ケースは事前承認、越境時のみ短時間レビューで通す仕組みがある |
| シャドーAI | 無断利用を可視化し、需要シグナルとして正規ルートに合流させている |
| 段階設計 | サンドボックス→許可リスト→展開の道筋と各段階のガードレールが共有されている |
| 越境統制 | 展開段階の重要操作に人間承認ワークフローが組み込まれている |
よくある質問（Q&A）
Q1. 現場とITのどちらの言い分が正しいのでしょうか？
どちらも正しい、というのが本質です。早く使いたい現場は事業競争力の観点で正当であり、ガバナンスを守りたいITはリスク管理の観点で正当です。問題は人の正誤ではなく、両者の正当な懸念を調停する制度（責任分担・速度の約束・諮問の仕組み）が存在しないことにあります。解くべきは「どちらかの説得」ではなく「制度の設計」です。
Q2. シャドーAIは見つけ次第すべて禁止すべきですか？
禁止だけでは需要が別の抜け道を探すだけです。まず可視化して把握し、そのうえで「なぜ現場がリスクを冒してまで使うのか」という需要シグナルとして読み解き、公式の許可ルートに合流させるのが有効です。可視化の技術手順は本サイトのシャドーAI対策・AI利用ログ管理の記事で詳説しています。
Q3. 重厚なITILやCABを導入する体力が自社にはありません。
フルセットは不要です。本稿が勧めるのは「軽量版」——RACIは主要シーンを1枚の表に、SLAはIT側の回答上限日数を一言、変更諮問は越境時だけ通す週1回15分のレビュー、といった最小限から始められます。標準的なケースは事前承認済みリストで自動通過させれば、現場を窒息させずに統制できます。
Q4. 経営層を巻き込むべきタイミングはいつですか？
「ガードレールの境界線」と「RACIの最終説明責任（A）」を決める段階です。どこまでを現場裁量とし、どこからを諮問にかけるかは事業リスクの許容度の問題であり、これは経営の判断事項です。逆に言えば、日々の運用フローまで経営が握る必要はありません。経営は境界線を、現場は境界の内側を、ITは境界の監視を担う——という分担が機能的です。
Q5. 制度を作っても現場が従わない気がします。
制度が「現場を縛るもの」に見えると従われません。SLAをIT側の約束として設計する、サンドボックスで前進の道筋を見せる、といった「現場にとっての利得」を制度に組み込むのが鍵です。次回（第5回）で扱う「運用が続かない・形骸化する」問題とも地続きで、制度は作って終わりではなく、現場が使い続けたくなる設計が要点になります。
まとめ——対立は「悪者探し」ではなく「制度設計」で解く
本番GOの最後に立ちはだかる「現場とIT部門の温度差・対立」は、技術ではなく組織の問題です。要点は3つに集約されます。
1. どちらも正しい。 早く使いたい現場も、ガバナンスを守りたいITも、それぞれの責任範囲で正当です。対立の正体は人の正誤ではなく「制度の不在」です。
2. 第三の道を取る。 「禁止」は需要を地下化させ、「放任」はリスクを露出させます。ガードレール付きの権限委譲——境界を明示し、越境時だけ諮問にかける設計が、速度とガバナンスを両立させます。
3. 共通言語と段階設計で橋渡しする。 RACI・SLA・軽量版の変更諮問という共通言語と、サンドボックス→許可リスト→展開という段階設計が、温度差を「説得」ではなく「仕組み」で縮めます。シャドーAIは敵ではなく需要シグナルとして読み、正規ルートに合流させます。
これらはすべて、NOC/TACが運用部門と事業部門の古典的緊張を橋渡ししてきた知恵の応用です。対立を「悪者探し」から「制度設計」へと捉え直したとき、止まっていた本番展開は再び動き出します。
次回予告（第5回）
組織と人の壁を越えても、まだ油断はできません。連載第5回は、導入後にじわじわと効いてくる「現場の運用が続かない／形骸化する」問題を扱う予定です。最初は盛り上がったAI活用が、半年後には誰も使わなくなる——その「定着の劣化」を、運用設計とKPIの観点でどう防ぐか。本稿で作った制度を「使い続けられる仕組み」へと育てる方法を掘り下げます。
参考リンク（連載・関連記事）
- 【連載①】企業AI導入「つまずき」解決シリーズ——「使われずに終わる（定着）」問題
- 【連載②】企業AI導入「つまずき」解決シリーズ——「効果が見えない（ROI）」問題
- 【連載③】企業AI導入「つまずき」解決シリーズ——「PoCから本番に進めない（PoC死）」問題
- シャドーAI対策——無断利用の可視化とポリシー設計
- AI利用ログ管理・監査の設計ガイド
- AIの人間承認ワークフロー（Human-in-the-Loop）設計パターン
免責事項： 本記事は2026年6月時点の一般的な情報提供であり、特定の組織・体制における有効性を保証するものではありません。また、法的・労務的な助言ではありません。実際の制度設計や権限委譲の範囲は、自社の事業リスク許容度・社内規程・関連法令に照らして検討し、必要に応じて専門家にご相談ください。
コメント