---
title: 「何をやらないか」を決めた組織だけが、AI導入後も課長の燃料を守れる
date: 2026-06-28
description: 全社AI導入で課長の燃料を最も削るのは、ツール選定でも技術研修でもない。「何をやらないか」を役員・現場と事前に合意しないまま走ると、インシデントが起きた瞬間に課長だけが責任を取らされる設計になる。合意形成の手順と、燃料を守る退路設計を示す。
categories: [期待値コントロール]
tags: [期待値コントロール, AI活用, 逃げの設計]
source: https://ai.work.naenote.net/posts/ai-nani-yaranai-nenryo/
---


全社AI導入のプロジェクトが立ち上がったとき、IT課長の仕事は「ツールを選んで展開する」だと思われている。

外から観察してきた限り、その定義で走った課長はほぼ例外なく、展開後に燃料を食い潰される。インシデントが起きてから呼ばれ、使い方を制限してから怒られ、何もできないまま説明資料を書かされる。

最初に決めなかったのは「何をやらないか」だ。

{{< mermaid >}}
flowchart TD
    A[全社AI導入] --> B[「何をやらないか」未合意]
    B --> C[部下が勝手に使い始める]
    C --> D[インシデント発生]
    D --> E[課長が責任を取らされる]
{{< /mermaid >}}

## 燃料を食うのは判断の連鎖

IT課長にAI導入を任せると、課長は技術的な判断だけでなく、組織的な判断の連鎖まで引き受けることになる。

どのツールを使うか。誰が使えるようにするか。どの業務に使うか。どこまでのデータを入力していいか。外部サービスへの送信可否はどう決めるか。例外が出たとき誰が判断するか——。

私が話を聞いてきた課長たちは口を揃えて言う。「ツールを入れたことより、その後の『この場合はどうするんですか』という問い合わせの方が10倍燃料を食った」と。

この判断の連鎖は、課長一人が処理すべき問いではない。だが「何をやらないか」が最初に定義されていないと、全部が課長に流れてくる。

## なぜ「やらないこと」が先に来るのか

AI導入で何を「やる」かは、推進派が積極的に話す。便利になる業務、削れる時間、コスト削減のシナリオ。役員への説明資料には「やること」が並ぶ。

「やらないこと」を誰も決めようとしない理由は単純だ。言い出した瞬間に「慎重すぎる」「AI嫌いなのか」と読まれる空気があるからだ。

だが、組織の観点から見ると順番が逆だ。**何をやらないかが決まると、初めて何をやるかが安全に実行できる**。

たとえば「個人情報・顧客情報を外部AIに入力しない」という一文が合意されていれば、その先の判断コストは激減する。部下がどのAIをどう使っても、その一文に照らせばいい。合意がなければ、毎回が個別判断になり、課長が都度燃料を使う。

「やらないことリスト」は制限の文書ではなく、課長の判断コストを先払いで下げる設計図だ。

## 合意形成の手順——3段階で退路を作る

全社AI導入の前後で課長が燃料を守るには、役員・現場の両方と「やらないこと」を合意しておく必要がある。手順は3段階に分けると動かしやすい。

### 第1段階：禁止領域の明文化（役員合意）

最初に役員に持ち込む論点は「AI導入の推進計画」ではなく「AI活用のレッドライン」だ。

具体的には次の2点を紙一枚に書いて持ち込む。「この種の情報は外部AI非入力とする」「この業務ではAI出力をそのまま使わない（人間の最終確認を挟む）」。

この紙を役員に承認させることが目的だ。紙が残れば、後でインシデントが起きたときに「レッドラインはここだと経営として合意済みです」と言える。**退路が一枚の紙に変わる**。

役員への持ち込み方は（詳しくはこちらの記事に書いた：[役員説明で手戻りを出さない論点整流の技術](/posts/yakuin-temodoeri-zero/)）。

### 第2段階：現場との使い方境界の言語化

役員合意のレッドラインを、現場が判断できる粒度に落とす。

抽象的な「個人情報は入力禁止」は、現場では「このお客さんの名前を入れてもいい?」という問いを量産する。一問一問が課長に来る。

言語化の鍵は「具体例と例外」をセットにすることだ。「お客さんの名前・住所・連絡先は入力しない。会社名・業種・取引規模は入力してよい」まで書く。この粒度になると、現場は自律判断できる。

現場への展開は[AI研修の設計ミスと課長の浸透コスト](/posts/ai-kenshu-kacho-fukatsuyo-kozo/)に書いた構造を参照すると良い。

### 第3段階：「知らなかった」のインシデントに備えるフォールバック

合意してもインシデントは起きる。その前提で退路を設計する。

必要なのは2つだ。一つは「何かあったら即報告」のルートを現場に渡しておくこと。隠蔽が最悪のシナリオなので、報告したら詰められないという空気を先に作る。もう一つは「このインシデントは課長の判断範囲を超えている」と言える根拠、つまり第1・第2段階の合意文書を保管しておくことだ。

文書があれば課長は「合意外の使い方が発生しました」と報告できる。文書がなければ「課長が管理できていなかった」になる。同じ事実が、文書一枚で全く違うコストになる。

## 逃げの一手——合意形成は「巻き込まれ防止」として設計する

「やらないことを役員と合意する」と書くと、「そんな時間はない」「役員が話を聞かない」という反応が返ってくる。

外から観察してきた限り、その課長たちは数ヶ月後に合意なし導入のコストを一人で払っている。

「役員が話を聞かない」のではなく、役員が反応しやすい論点の出し方になっていないケースがほとんどだ（[役員が動かない会議で課長が使う反応抑制の技法](/posts/yakuin-hanno-yokusei-jutsu/)に整理した）。

合意形成に使う燃料と、インシデント後の後始末に使う燃料を比べると、前者の方が圧倒的に小さい。[シャドーAI問題が爆発したときの対応コスト](/posts/shadow-ai-shinkoku-cost-kacho/)を見れば、その差は明らかだ。

会議の場で議題にできないなら、書面でいい。「AI活用の範囲について事前に合意しておきたい事項があります」という一文のメールを役員に送り、返信か対面の時間を取る。返信が記録になる。

合意形成は「AI推進のための根回し」ではなく、「課長が責任を取らされない構造を作る先行投資」だと定義し直すと、動き方が変わる。

また、AIそのものの依存リスク（[単一ツールへの依存設計ミス](/posts/ai-izon-risk-sekkei/)）とは別の話として、「組織として何をやらないか」の合意は、ツールが変わっても有効だ。ツール選定より先に決めるべき問いがここにある。

## まとめ：合意文書が[[課長の燃料](/posts/ai-kacho-daitai-funou-nenryokei/)計を守る](/posts/ai-kacho-zanryo-kozo/)

AI導入で課長が燃料を食い潰されるのは、技術の問題ではない。

「何をやらないか」が役員と現場の両方と合意されていないまま走ると、インシデントのたびに課長が判断コストを払い、説明コストを払い、謝罪コストを払う設計になる。

合意文書は推進の妨げではない。判断コストを先払いして、[課長の燃料計](/posts/ai-kacho-daitai-funou-nenryokei/)を守る退路だ。

{{< ai-disclaimer >}}

---
### AI Agent Context & Resources
- **Author**: NAE
- **Source**: https://ai.work.naenote.net/posts/ai-nani-yaranai-nenryo/
- **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP)
- **Contact/Inquiry**: https://x.com/naework