部門別AI利用ルールの作り方｜二層設計×5部門の実例とテンプレート

入力情報の区分と利用条件を明確にする

最初に決めるべきは、AIに入力する情報の区分と利用条件です。

「原則入力禁止」「条件を満たせば利用可能」「通常利用可能」といった形で区分し、情報そのものの機密性だけでなく、利用するAIサービスの契約条件、データの保存・学習への利用条件、アクセス権限、社内規程なども確認します。たとえば、以下のような情報は、全社共通で慎重に扱う必要があります。

• 氏名、住所、電話番号、社員番号などの個人情報
• 健康情報、信条、マイナンバー、口座情報などの機微性が高い情報
• 未公開の決算情報、M&A情報、人事異動情報
• 顧客の機密情報や契約条件
• 認証情報、秘密鍵、パスワード、脆弱性情報

個人情報保護委員会は、「生成AIサービスの利用に関する注意喚起等について」で、生成AIサービスの利用に際し、個人情報取扱事業者や行政機関等が個人情報保護法の規律に従って個人情報を適正に取り扱う必要があると注意喚起しています。個人情報を扱う場合は、一律に入力可否を決めるのではなく、利用目的、社内規程、契約条件、利用するAIサービスのデータ管理条件を確認したうえで判断する必要があります。

重要なのは、「機密情報を入力しない」といった抽象的な表現だけで終わらせないことです。「顧客名は入れてよいのか」「契約金額は伏せればよいのか」「社内会議の議事録は使えるのか」といった具体的な疑問に答えられる粒度が必要です。

出力の責任者を決める

AIの出力は、必ず人が確認してから使う前提にします。これは全社共通ルールとして明記しておきたい項目です。

特に、次の内容は確認が欠かせません。

• 数字
• 日付
• 固有名詞
• 引用
• 法律、規制、契約に関わる内容
• 人事評価や処遇に関わる内容
• 社外に送る文章

NISTのAI Risk Management Framework（AI RMF 1.0）および生成AI向けプロファイルでは、AIリスクを個人・組織・社会への影響として捉え、組織の目的や利用場面に応じて管理する考え方が示されています。なお、AI RMF 1.0は2026年現在、改訂が進められています。

ここで大切なのは、「誰が確認するのか」まで決めることです。営業メールなら担当者と上長、契約に関わる内容なら法務、評価コメントならマネージャー、人事制度に関する回答なら人事担当者が確認する、といった形です。

「人が確認する」とだけ書くと、実務では責任の所在が曖昧になります。責任者が曖昧なルールは、忙しい現場では機能しにくくなります。

アカウントと権限管理の原則を決める

AI利用環境を安全に運用するには、アカウントと権限管理も全社共通ルールに含める必要があります。

たとえば、以下のような原則です。

• 共有アカウントを作らない
• 退職者・異動者の権限は速やかに変更する
• 機密性の高い情報を扱う場所には、必要な人だけを参加させる
• 管理者権限を持つ人を限定する
• 部門や案件ごとにアクセス範囲を分ける

Kanataでは、スペース、プロジェクト、アプリ、ライブラリという概念が整理されており、プロジェクトごとにメンバーや権限を管理できる構成が説明されています。こうした仕組みは、部門や業務ごとに利用範囲を分けたい場合に役立ちます。ただし、どの単位で情報を分けるか、誰にどの権限を付与するかは、企業側の運用ルールとして設計しておく必要があります。

インシデント時の動きを決める

AI利用では、誤って入力してはいけない情報を入れてしまう可能性もあります。そのときに大切なのは、個人を責めることではなく、早く正確に報告される仕組みを作ることです。

全社共通ルールでは、少なくとも次の流れを決めておくとよいでしょう。

1. 誤入力に気づいた時点で、その会話を続けない
2. 何を、いつ、どの環境に入力したかを記録する
3. 上長、情シス、情報セキュリティ担当へ報告する
4. 必要に応じて影響範囲を確認する
5. 再発防止策をルールや研修に反映する

「ミスした人が怒られる」という空気があると、報告が遅れる可能性があります。AI利用ルールでは、禁止事項だけでなく、問題が起きたときにどう動くかまで決めておくことが重要です。

営業部門のルール例

営業部門では、AIを使いたい場面が多くあります。商談準備、提案書の構成案、メールの下書き、商談メモの整理、次回アクションの抽出などです。

一方で、営業部門は顧客情報や契約情報に触れる機会が多いため、入力前のマスキングルールが重要です。

たとえば、次のような部門別ルールが考えられます。

• 商談準備や提案書のたたき台作成には利用してよい
• 顧客名、担当者名、契約金額は必要に応じてマスキングする
• NDA対象の情報は、契約条件を確認してから扱う
• 社外に送るメールや提案書は、担当者と上長が確認する
• 価格、契約条件、納期の約束はAI出力だけで判断しない

営業部門では、「使ってはいけない」と広く止めるよりも、「どこまでなら使えるか」を明確にしたほうが、現場の判断がしやすくなります。

人事部門のルール例

人事部門では、AI活用の余地がある一方で、個人情報や評価情報を多く扱います。そのため、部門別ルールは慎重に設計する必要があります。

利用しやすい業務としては、研修案内の文面作成、社内FAQの整理、制度説明文の下書き、面談メモの構造化などがあります。一方で、評価コメント、健康情報、懲戒、ハラスメント相談などは、AIにそのまま入力すべきではありません。

人事部門のルール例は、次のようになります。

• 研修資料、制度説明、社内FAQの下書きには利用してよい
• 個人が特定できる面談メモは、原則としてマスキングする
• 健康情報、信条、家庭事情などの機微性が高い情報は入力しない
• 評価コメントは、AI出力を参考にしても、最終的にマネージャーが自分の言葉で確認する
• 社員への制度回答は、必ず就業規則や社内規程の根拠を確認する

人事部門では、「効率化」よりも「誤解を生まないこと」「本人に不利益が生じないこと」を優先する必要があります。

経理・財務部門のルール例

経理・財務部門では、公開済み資料の整理や社内手順書の作成にはAIを活用できます。一方で、未公開の決算情報、資金繰り、M&A、投資判断に関わる情報は特に慎重に扱う必要があります。

部門別ルールの例は、次のようになります。

• 公開済みIR資料や社内手順書の要約には利用してよい
• 経費精算ルールや請求処理のFAQ作成には利用してよい
• 未公開決算、資金繰り、M&A情報は入力しない
• 数値を含む出力は必ず一次情報と照合する
• 外部開示や監査に関わる内容は、専門担当者が確認する

経理・財務部門では、数字の誤りが大きな問題につながる可能性があります。AIを「判断者」ではなく、「整理・下書きの補助」として位置づけることが重要です。

情報システム部門のルール例

情報システム部門では、社内FAQ、手順書、問い合わせ対応、障害報告書の下書きなどにAIを使えます。一方で、認証情報や脆弱性情報を扱うため、入力禁止情報の線引きが重要です。

ルール例は、次のようになります。

• 社内向けIT手順書やFAQの作成には利用してよい
• 問い合わせ内容の分類や回答案の下書きには利用してよい
• パスワード、秘密鍵、アクセストークンは入力しない
• 未公開の脆弱性情報や構成情報は入力しない
• 障害対応時は、AI出力よりも正式な手順書と責任者判断を優先する

情シス部門は、AI活用を進める側であると同時に、全社の安全性を守る立場でもあります。そのため、部門内の利用ルールと、全社への説明責任を分けて考える必要があります。

マーケティング部門のルール例

マーケティング部門では、記事構成案、広告文、メール文面、ウェビナー企画、SNS投稿案など、AIを使いやすい業務が多くあります。

ただし、公開前の情報、顧客事例、競合比較、実績数値を扱う場合は注意が必要です。

ルール例は、次のようになります。

• 公開情報をもとにした調査、構成案、初稿作成には利用してよい
• 実績数値や導入事例は、出典と公開可否を確認する
• 顧客名や事例内容は、掲載許諾の有無を確認する
• 広告表現、比較表現、効果表現は人が確認する
• 誇大表現や断定表現を避ける

マーケティング部門では、AIによって制作スピードを上げられる一方で、表現の責任は企業側に残ります。特にBtoBサービスでは、信頼を損なわない表現管理が重要です。

慎重な部門には、禁止ではなく相談導線を用意する

人事、法務、経理、情報システムなどは、扱う情報の性質上、AI活用に慎重になりやすい部門です。

このような部門に対して、「使ってはいけない」と広く止めるだけでは、AI活用の可能性が閉じてしまいます。一方で、曖昧なまま使わせるとリスクが高まります。

そこで必要なのは、「迷ったら相談できる導線」です。

たとえば、次のような仕組みです。

• 判断に迷うケースを相談できる窓口を設ける
• よくある相談をFAQ化する
• 部門代表が月次でルール見直しに参加する
• 不安な業務は、まず公開情報やマスキング済み情報だけで試す

慎重な部門ほど、ルールが明確になれば安心して使えるようになります。

活用意欲が高い部門には、標準テンプレートを渡す

営業、マーケティング、企画部門などは、AI活用のメリットを感じやすい部門です。

ただし、自由に使い始めると、プロンプトや出力の品質がばらつきます。そこで有効なのが、標準テンプレートの整備です。

たとえば、次のようなテンプレートです。

• 商談メモ整理テンプレート
• 提案書構成テンプレート
• メール下書きテンプレート
• 記事構成案テンプレート
• 調査観点整理テンプレート

Kanataでは、プロジェクト単位でAIチャット、AI要約、eラーニングなどのアプリを追加し、プロンプトや学習データをライブラリとして管理できる構成が説明されています。こうした仕組みは、部門ごとに標準テンプレートを整備し、再利用しやすくする用途と相性があります。

ただし、Kanataに限らず、どのAIツールを使う場合でも、登録するプロンプトや資料の管理ルールは別途必要です。ツールの機能だけで、運用ルールそのものが自動的に整うわけではありません。

使わない部門には、小さな成功例を作る

すべての部門が最初からAI活用に前向きとは限りません。

「何に使えばよいかわからない」「自分たちの業務には関係ない」「間違ったら怖い」と感じる部門もあります。

この場合は、リスクの低い業務から始めることが有効です。

たとえば、次のような業務です。

• 公開情報の要約
• 会議アジェンダの整理
• 社内向け文章のたたき台作成
• FAQの見出し整理
• 研修資料の構成案作成

最初の目的は、大きな成果を出すことではありません。「この業務なら使ってもよさそうだ」と感じてもらうことです。

部門ごとの利用場面を棚卸しする

最初に、各部門がAIを使いたい業務を洗い出します。

このとき、「使ってよいかどうか」を先に判断しないことが大切です。まずは、現場がどのような場面でAIを使いたいのかを集めます。

たとえば、以下のような観点で整理します。

• どの業務で使いたいか
• どのような情報を入力しそうか
• 出力は誰が使うか
• 社外に出る可能性があるか
• 間違った場合の影響はどの程度か

ここで出た業務を、後から「許可」「条件付き許可」「禁止」に分類していきます。

全社共通で禁止・必須にする項目を決める

次に、全社共通ルールを決めます。

ここでは、部門ごとの事情に関係なく、必ず守る項目を整理します。

主な項目は次のとおりです。

• 入力禁止情報
• 出力レビューの責任
• 社外利用前の確認
• アカウントと権限管理
• インシデント報告
• ログや履歴の扱い
• 利用できるAI環境の範囲

この段階で細かくしすぎると、部門別ルールとの差がなくなります。全社共通ルールでは、「全員が必ず守る最低限」に絞ることが大切です。

部門ごとに「許可・条件付き許可・禁止」を分ける

次に、各部門の業務を3つに分類します。

許可

公開情報の要約、社内文書の下書き、会議アジェンダの整理など、比較的リスクの低い業務です。

条件付き許可

顧客情報を含む商談メモ、社内規程を参照したFAQ回答、評価コメントの下書きなど、マスキングやレビューが必要な業務です。

禁止

機微性が高い情報、未公開財務情報、認証情報、重大な法的判断など、AIに入力したり、AI出力だけで判断したりすべきではない業務です。

この分類を部門ごとに作ることで、現場は判断しやすくなります。

部門代表とレビューする

ルール案ができたら、必ず部門代表とレビューします。

確認すべき観点は、次のとおりです。

• 実務に合っているか
• 厳しすぎて使えないルールになっていないか
• 抜け漏れがないか
• 誰が確認するかが明確か
• 相談先が明確か
• 現場の言葉で理解できるか

特に大切なのは、「現場の言葉で理解できるか」です。ルールが法務文書のように難しい表現になっていると、現場では読まれません。AI利用ルールは、規程としての正確さと、現場で使えるわかりやすさの両方が必要です。

定期的に見直す

AI利用ルールは、一度作って終わりではありません。

生成AIの機能も、社内の使い方も、短い期間で変わります。最初から完成版を目指すのではなく、見直しを前提に設計するほうが現実的です。

たとえば、次のような項目を見直します。

• 問い合わせが多かった項目
• 現場が迷ったケース
• 使われなかったテンプレート
• よく使われたプロンプト
• ヒヤリハット
• 新たに追加すべき利用業務
• 厳しすぎたルール
• 曖昧だった禁止事項

見直しの周期は、導入初期であれば30日後、その後は四半期ごとが一つの想定例です。実際には、企業規模、利用者数、扱う情報の機密度に応じて調整してください。

すべてを全社ルールに詰め込む

全社ルールにすべてを書こうとすると、規程が長くなり、現場では読まれにくくなります。

また、部門ごとの細かな違いまで全社ルールに含めると、更新にも時間がかかります。営業部門の提案書ルールを変えたいだけなのに、全社規程の改定が必要になると、現場のスピードに合いません。

全社ルールは最低ラインに絞り、部門別ルールで調整する設計が現実的です。

部門任せにしすぎる

反対に、すべてを部門任せにするのも危険です。

部門ごとに判断基準がばらつくと、同じ情報でも、ある部門では入力してよい、別の部門では禁止という状態が起こります。これでは、会社全体として説明責任を果たしにくくなります。

部門別ルールは、全社共通ルールの上に置くものです。全社の最低ラインを超えて、部門が独自に基準を緩めることは避けるべきです。

禁止事項だけで終わる

AI利用ルールが禁止事項だけになると、現場は使い方を学べません。

「何をしてはいけないか」だけでなく、「何なら使ってよいか」「どう使えば安全か」まで示す必要があります。

たとえば、営業部門には商談メモ整理のテンプレート、人事部門にはFAQ回答のルール、管理部門には規程要約のプロンプトなど、具体的な使い方をセットで示すと、現場は動きやすくなります。

見直しの責任者がいない

AI利用ルールは、作成時よりも運用時のほうが重要です。

見直しの責任者がいないと、古いルールが残り続けます。古い資料やプロンプトが使われたり、現在の業務に合わない禁止事項が残ったりすることもあります。

全社ルールは情シス・DX推進・法務・人事などの横断チーム、部門別ルールは各部門代表が責任を持つ、といった役割分担を決めておくとよいでしょう。