import { NavigationBlock } from "@/components/blog/NavigationBlock";
AIを入れたいと言われたとき、まず整えること
判断の構造 第2回
「来月までに全社でAIを入れたい」
「競合が使っているので、うちもChatGPTを導入したい」
「業務をAIで自動化して人件費を下げたい」
——相談の入口では、ツール名とスピードが先に来ることが多いです。
私たちは、このタイミングですぐライセンス契約や開発提案をしません。AIに反対しているわけではなく、境界のない導入が最も壊れやすいと知っているからです。
この記事は、匿名化したケース構造として、相談で何をしたかを共有します。
30秒で要点
- AI導入は目的ではなく手段
- 先に決めるのはツールではなく、任せる範囲・人が見る範囲・停止線
- 仮説は1業務・1週間で検証
- 拡大は線引きが機能してから
- 前提が変わったら見直す条件まで書く
| 用語 | 意味 |
|---|---|
| API | システム同士がデータをやり取りする窓口 |
相談の入口
ある相談では、経営層から次のような圧力がありました（要約）。
- 取締役会で「AI活用」の報告を求められている
- 情報システム部門は情報漏洩が怖く、全面禁止に近い
- 現場は個人でChatGPTを使い始めており、統制がない
- ベンダーからは「○○万円で全社導入」の提案が来ている
確かなこと： 社内外に「遅れている」という焦りがある。
不確かなこと： どの業務を、どのリスク許容度で、誰の責任で回すか。
入口の時点では、「とにかく導入」が結論になっていました。
すぐツール導入を提案しなかった理由
AI市場では、導入＝前進に見えやすい構造があります。
- 経営はスピードと話題性を求める
- ベンダーはライセンス数と実装工数で語りやすい
- 現場は「禁止」より「使える方が楽」
- 法務・情報システムは事例がないと止めにくい
このときツールを先に売ると、一時的に安心します。一方で、次の失敗像がよく起きます。
- 全社ライセンスだけ契約し、使える人が一部
- 無承認で顧客データが入力され、後から発覚
- 出力をそのまま対外送信し、誤情報が信用問題に
- 「AIは使えない」か「野良利用」に振れる
だから私たちは、導入を悪いと言うのではなく、拡大の前に境界を決めない立場から入ります。
分解した論点
初回で論点を4つに分けました。
1. 解きたい課題（何のためのAIか）
| 言葉 | 表面の意味 | 確認したいこと |
|---|---|---|
| 人件費削減 | コスト削減 | 削減対象の業務は特定できるか |
| 全社導入 | 組織的に進める | 全業務か、一部か |
| 競合対策 | 遅れを取りたくない | 競合と同じ課題か |
2. リスク許容度（何を絶対に守るか）
- 個人情報・契約情報の入力可否
- 対外送信前の人の確認の要否
- ログ・監査の粒度
3. 体制（誰が止めるか）
- 推進役・業務オーナー・情報システム・法務の役割
- 「AIが書いたから」で責任が消える構造になっていないか
4. 成功の定義（どうなったら前進か）
「ライセンスが契約された」は成功ではありません。例として一緒に書いたのは次です。
- 対象業務1つで、停止線付き運用が2週間回った
- 事故ゼロ、または事故時に誰が何をしたか説明できる
- 経営報告に使えるのは「導入した」ではなく「何を任せ、何を人が見たか」
置いた仮説
論点を踏まえ、仮説は1つに絞りました。
仮説： いま必要なのは全社展開ではなく、問い合わせ対応の下書き工程だけを対象に、入力禁止データと対外前確認を明文化した1週間の試行である。
正解ではありません。検証可能な最小ステップです。
判断したこと
2週間後のフォローで、次を判断しました。
- 全社ライセンス契約は保留
- 境界が決まる前の一括契約は、後から止めにくいため。
- 試行は1業務・既存ツールで開始
- 新規開発は不要。運用ルールの文書化を先に。
- 停止線を3つに限定して合意
- 顧客固有情報の入力禁止
- 対外送信前の人の承認必須
- 同種の誤りが2回で用途凍結
- 4週間後に拡大可否を再判断
- 試行ログ（止めた回数・理由）を見て、次の業務を1つだけ追加するか決める。
「導入しない」と言ったわけではありません。拡大の順番を、境界の後にずらした判断です。
相談後に整理されたもの
クライアント側に残ったものの例です（形式は案件ごとに変わります）。
- 任せる範囲・人が見る範囲・停止線の1ページサマリー
- 責任表（入力・確認・更新・事故時初動）
- 試行対象業務と4週間後の再判断条件
- 全社展開に進むためのチェックリスト（5項目以内）
API連携やカスタム開発の見積もりは、この段階では出していません。
次に見直す条件
| 条件 | 見直しの方向 |
|---|---|
| 停止線が守られず野良利用が増える | 範囲を狭めるか、正式な許可リスト制に切り替える |
| 法務・規制要件が変わる | 入力禁止カテゴリとログ粒度を更新 |
| 経営が「来月中に全社」と期限を短縮する | スコープを1業務に固定したまま報告設計を変えるか、見送る |
| 試行で業務オーナーが変わる | 責任表を再合意 |
この型が効く条件・効きにくい条件
効きやすい：
- 経営と現場・情報システムの温度差がある
- ベンダー提案が先に来ている
- 「とりあえず導入」が会議の結論になっている
効きにくい：
- 対象業務・責任・法務レビューがすべて完了している
- 実装のみを短納期で依頼したい
関連する読み物
- AIを入れる前に、止める線と責任の範囲を決める — 商談前の手順ガイド
- リニューアルしたいと言われたとき、まず整理すること — 判断の構造 第1回
links={[ { href: "/column/judgment-structure-hub", label: "判断の構造シリーズへ" }, { href: "/column/when-renewal-requested-organize-first", label: "第1回（リニューアル）" }, { href: "/blog/ai/ai-stop-line-responsibility-first", label: "停止線と責任の実践ガイド" }, { href: "/services/ai", label: "AI導入・業務設計コンサル" }, { href: "/contact", label: "状況を共有して相談する" }, ]} />