生成AIの利用可否をツール名だけで決めると、すぐに運用が破綻します。同じツールでも、社内メモの要約と顧客向け提案書の自動生成では、見るべきリスクも承認の重さも違うからです。
AI活用範囲は、ツール名ではなく「どの業務に」「どのデータを入れ」「結果を社外に出すか」「AIに自動で実行させるか」の4つを掛け合わせて決めます。組み合わせごとに「許可（自己判断でよい）」「要申請」「禁止」のどれかを書いたマトリクスを作ると、現場は申請が必要かどうかを自分で判断でき、承認者は判断に迷う案件だけを見ればよくなります。最初は頻度の高い業務10件前後から作り始めます。
要点
- AI活用範囲はツール名ではなく、業務、入力データ、外部共有、自動実行の4つを掛け合わせて、許可・要申請・禁止を決めます。
- 個人情報や取引先の秘密情報を入れる、社外に公開する、AIが人の確認なしに送信・更新する、のどれかに当たれば少なくとも要申請にします。
- 最初は頻度の高い業務10件前後で作り、迷うセルは要申請から始めて、問題がなかったものを許可へ移します。
活用範囲の結論は「ツール単位ではなく業務単位で切ること」
同じ生成AIでも、議事録要約、社内FAQ、顧客向け公開文書ではリスクの重さが違います。そのため、『このツールは使ってよい』のような表現ではなく、『どの業務に、どのデータを入れ、どの用途で出すか』で範囲を決めた方が運用しやすくなります。
範囲が曖昧なままだと、現場は毎回相談するか、勝手に自己判断するかの二択になりやすくなります。マトリクス化すると、この間を埋めやすくなります。
「ChatGPTの利用を許可」のようにツール単位で決めると、「そのツールにどのデータを入れてよいか」は決まっていないままになります。結果として、顧客から預かった未公開の資料を提案書づくりに使うといった判断が、利用者ごとにばらつきます。
活用範囲を決めるとは、AIを許可することではなく、どの条件なら自己判断してよいかを決めることです。
| 軸 | 区分の例 | 判断が重くなる方向 |
|---|---|---|
| 業務 | 社内の下書き・要約／顧客対応／社外への公開 | 社外の人の目に触れるほど重い |
| 入力データ | 公開情報／社内資料／個人情報・顧客情報／取引先から預かった秘密情報 | 本人や取引先の同意・契約が絡むほど重い |
| 外部共有 | 社内だけで使う／特定の顧客に渡す／Webなどで公開する | 取り消しにくいほど重い |
| 自動実行 | AIは下書きだけ／人が確認してから実行／AIが自動で送信・更新する | 人の確認なしに外部へ出るほど重い |
許可・要申請・禁止を書き込んだマトリクスの記入例
次の表は、4つの軸を掛け合わせた記入例です。自社のデータ区分や業務名に置き換えて使います。「許可」は利用者が自分で判断してよい範囲、「要申請」は事前に申請して承認を得る範囲、「禁止」は申請しても認めない範囲です。
| 業務 | 入力データ | 外部共有 | 自動実行 | 判定 | 条件・理由 |
|---|---|---|---|---|---|
| 社内会議の議事録要約 | 社内資料 | 社内だけ | 下書きのみ | 許可 | 会社が契約したツールを使う |
| 公開情報をもとにした競合調査メモ | 公開情報 | 社内だけ | 下書きのみ | 許可 | 出典URLをメモに残す |
| 顧客への個別メールの下書き | 顧客情報 | 特定の顧客 | 人が確認して送信 | 許可 | 送信前に宛先・金額・日付を本人が確認する |
| 顧客から受け取った要件書の要約 | 取引先から預かった秘密情報 | 社内だけ | 下書きのみ | 要申請 | 秘密保持契約でAIへの入力が認められているかを確認する |
| 提案書の作成 | 社内資料・顧客情報 | 特定の顧客 | 人が確認して提出 | 要申請 | 顧客ごとの情報の取り扱い条件を確認する |
| Web記事・プレスリリースの作成 | 公開情報・社内資料 | 公開 | 人が確認して公開 | 要申請 | 公開前に広報の確認を通す |
| 顧客リストへの一括メール送信 | 顧客情報 | 多数の顧客 | AIが自動送信 | 要申請 | 送信前の承認段階を置いた運用に限る |
| CRMの一括更新 | 顧客情報 | 社内だけ | AIが自動更新 | 要申請 | 更新件数の上限と元に戻す手順を決める |
| 人事評価・採否の判断 | 個人情報 | 社内だけ | AIの結果で決定 | 禁止 | AIの出力を判断材料の一つにとどめ、決定は人が行う |
| 会社が契約していない個人アカウントの利用 | 社内資料・顧客情報 | — | — | 禁止 | データの保存先と学習利用の条件を管理できない |
判定を決めるときの順番
- 入力データ：個人情報や取引先の秘密情報を含むなら、少なくとも要申請にする。
- 外部共有：社外に出るなら、人の確認を条件にする。公開するなら要申請にする。
- 自動実行：AIが人の確認なしに送信・更新するなら、要申請にして実行前の承認段階を置く。
- 業務：人の権利や待遇に関わる判断は、AIの結果だけで決めない。
迷ったセルは最初は要申請にしておき、申請の実績を見て問題がなかったものを許可へ移すと、後から範囲を広げる理由を説明しやすくなります。
マトリクス設計でよくある詰まり
ありがちなのは、全社共通の完全版をいきなり作ろうとして止まることです。実際には、頻出業務から先に範囲を切り、その後で例外処理を追加した方が進みます。
もうひとつは、機密情報と公開物だけで区切ってしまい、承認要否や出力用途の違いを見落とすことです。データ区分だけでは十分ではありません。
「全社共通版を作る」議論に引っ張られて止まるのを防ぐには、最初に「マーケ部門の頻出5業務」や「営業部門のよくある3パターン」に限定してマトリクスを作り、3か月運用してから横展開する流れが有効です。部門限定版から始めることで、「完全版を作らないと動けない」という思考から抜け出せます。
データ区分の見落としについては、「社内資料」の中に「取引先との秘密保持契約下の資料」が含まれるケースが特に抜けやすいです。自社の機密指定だけで判断していると、取引先から預かった資料を誤ってAIに入力するリスクが残ります。マトリクスに「取引先提供資料」という区分を独立させると、このリスクを明示的にカバーできます。上の記入例でも独立した区分にしています。
マトリクスを運用に載せる進め方
- 頻出業務を10件前後に絞って棚卸しする。
- 各業務について入力データと出力用途を整理する。
- 自己判断で使える範囲と要申請範囲を分ける。
- 要申請のセルについて、申請先と確認する人を決める（詳細は承認基準・承認フローの記事へ）。
- 月次で例外案件を見てマトリクスを更新する。
要申請の案件をどう判定するかは生成AIの承認基準、誰がどの段階で確認するかはAI運用の承認フローで整理しています。
棚卸しの進め方として、各部門に「現在AIを使っている業務」と「使いたいが判断できない業務」を5件ずつ提出してもらう方法が現実的です。「使いたいが判断できない」業務こそ、マトリクスが最も価値を発揮する領域です。収集した業務リストを見ると、多くの場合「社内向けの要約・下書き作成」は自己判断可に分類でき、「顧客への提案書・公開物」は要申請か条件付きに分類されます。この分類作業自体が、担当者の判断基準を揃える教育効果を持ちます。
月次の例外案件の確認では、「自己判断可とされていた業務で問題が起きた案件」と「要申請とされていたが実際は問題なかった案件」の2種類を見ることが改善につながります。前者はマトリクスの判定を厳しくする根拠になり、後者は承認負荷を下げる根拠になります。両方の視点でマトリクスを更新すると、過剰規制と過少規制のバランスが取りやすくなります。
マトリクスに加えて、許可と要申請の具体例を数件ずつ添えると、現場は自分の業務に当てはめやすくなります。具体例は月次の見直しのたびに追加します。
よくある質問
AI活用範囲は部門ごとに分けるべきですか？
部門だけでなく業務とデータ区分まで見る方が精度が上がります。部門だけだと例外処理が増えやすくなります。
ツール単位の利用許可では不十分ですか？
不十分です。同じツールでも用途によって承認の重さが違うため、業務単位で見る方が自然です。
マトリクスはどこまで細かく作るべきですか？
最初は頻出業務から始め、例外が多い領域だけ細かくする方が運用しやすくなります。
活用範囲を決めた後に何を作るべきですか？
要申請のセルについて、申請書の項目、判定の基準、確認する人と期限を決めます。申請書は生成AI利用申請書、判定は承認基準、確認の流れは承認フローの記事で整理しています。
AIエージェントに操作させる業務は、生成だけの業務と分けるべきですか？
分けるべきです。同じ業務とデータでも、AIが人の確認なしに送信や更新まで行う場合は、取り消しにくさが変わります。自動実行の軸を独立させ、実行前の承認段階を置いた運用に限って認めると線引きが明確になります。
