生成AIの社内ルールを作った。
入力してはいけない情報も決めた。
確認者も一応決めた。
でも、しばらく使っていると、また迷いが出てくる。
この問い合わせ文は、名前を消せばAIに入れていいのか。
議事録の要約は、どこまで社内共有していいのか。
AIが作った文章を、誰が最終確認するのか。
古いプロンプトのまま使っているけど、今の業務に合っているのか。
こういう迷いは、社内ルールを作っていないから起きるわけではありません。
一度作ったルールが、実際の使い方に追いついていないから起きます。
僕は、AI社内ルールは「完成版を作って配るもの」ではなく、「改善会議で出た決定事項から小さく更新するもの」だと思っています。
以前、生成AIの社内ルールは、禁止より入力ルールから考える で、まず入力してよい情報の線引きを決める話を書きました。
その後に、AI活用の効果測定は、成果より先に運用ログから始める と AI活用を社内展開する前に、改善会議を15分だけ作る で、ログを残して改善する流れを整理しました。
今回は、その次です。
ログを見た。
改善会議で決めた。
では、その決定をどうやって社内AIルールへ落とすのか。
ここが曖昧だと、せっかくの改善会議が「話して終わり」になります。
総務省・経済産業省の AI事業者ガイドライン第1.2版 では、AIの安全安心な活用に向けて、リスクやガバナンスを継続的に見直す考え方が整理されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、生成AI利用時の最低限のセキュリティ対策を、利用者側にも分かる形で整理しています。
ただ、小さな会社が最初から大きな規程を作るのは大変です。
必要なのは、現場が明日から迷わないための、小さく更新できるルールです。
AI社内ルールは、分厚い規程を一度で作るより、改善会議で決めたことを1行ずつ運用ルールに変えていく方が続きます。
今日は、中小企業や小規模事業者が、生成AIの社内ルールを作って終わりにせず、実務の中で更新していく手順を整理します。
AI社内ルールは、一度作って終わりではなく運用で更新する
AI社内ルールを作るとき、多くの人が「ちゃんとしたものを作らないと」と考えます。
情報漏洩を防ぎたい。
社員に勝手な使い方をしてほしくない。
お客様に出す文章でミスをしたくない。
だから、最初にきれいなルールを作ろうとする。
気持ちは分かります。
でも、AI活用の初期段階で、完璧な社内ルールを作るのはかなり難しいです。
理由はシンプルで、まだ実際の使い方が見えていないからです。
どの業務でよく使われるのか。
どんな入力で迷うのか。
どの出力がそのまま使いにくいのか。
誰の確認で止まりやすいのか。
どこに保存しておくと後から見返せるのか。
これは、使う前には分かりません。
机上で決められる部分もあります。
個人情報や機密情報をそのまま入れない。
AIの出力をそのまま外部へ送らない。
契約、法務、医療、会計などの専門判断をAIだけで決めない。
こういう基本線は先に決めた方がいいです。
ただ、それだけでは現場の迷いは消えません。
たとえば、問い合わせ返信の下書きにAIを使うとします。
お客様の名前は消す。
会社名も伏せる。
でも、問い合わせの内容そのものに、業界や地域や状況がかなり出ている。
ここまで匿名化すべきなのか。
それとも、社内契約しているAI環境なら入れていいのか。
この判断は、会社ごとの業務、使うツール、契約形態、確認体制によって変わります。
だから、最初から正解を固定しようとすると苦しくなります。
AI社内ルールは、最初に最低限の線引きを作る。
そのうえで、実際に使ったログと改善会議を見ながら更新する。
この順番が現実的です。
NISTの 生成AI向けAIリスク管理フレームワークプロファイル でも、生成AIのリスクは用途や業務プロセスに応じて整理し、組織の目的や優先順位に合わせて管理する考え方が示されています。
小さな会社に置き換えるなら、こうです。
うちの業務では、どこでAIを使うのか。
その使い方で、どんな迷いが実際に出たのか。
次から迷わないために、何を1つだけ決めるのか。
この積み重ねが、使われる社内AIルールになります。
一度作ったPDFを配って終わりにすると、ルールは古くなります。
逆に、改善会議で決めたことを小さく反映していけば、ルールは現場に近づきます。
AI社内ルールは、完成物というより運用品です。
作る力より、直し続ける力の方が大事です。
改善会議の決定事項を、まず1行ルールにする
改善会議で話したことを、そのまま議事録に残すだけでは足りません。
議事録は、あとから読む人が解釈しないといけないからです。
「問い合わせ返信では個人情報に注意する」
「議事録要約は確認してから共有する」
「ブログ下書きはAI出力をそのまま使わない」
こういう書き方は、分かったようで分かりません。
注意するとは、何をすることなのか。
誰が確認するのか。
そのまま使わないとは、どこを直すことなのか。
ここが曖昧だと、次回また同じ話になります。
改善会議の決定事項は、まず1行ルールにするのがおすすめです。
たとえば、こんな形です。
- 問い合わせ返信では、顧客名と会社名を伏せたうえでAIに下書きを作らせる
- AIが作った返信文は、送信前に担当者本人と責任者のどちらかが確認する
- 議事録要約では、決定事項と未決事項を分けて出力させる
- ブログ構成案は、公開前に自社の言葉へ書き換えた箇所を1つ以上残す
- 社内資料をAIへ入れる前に、公開情報か社内限定情報かを確認する
ポイントは、「次回から何をするか」が分かる文にすることです。
ルールっぽい言葉にしすぎる必要はありません。
むしろ、現場の人が読んで行動できる言葉の方がいいです。
「個人情報に留意する」より、「氏名、会社名、電話番号を伏せてから入れる」。
「出力を確認する」より、「外部送信前に担当者が事実と表現を確認する」。
「適切に保存する」より、「使った業務名、入力の種類、修正した箇所をログへ残す」。
こういう1行の方が、運用に残ります。
ここで欲張って、いきなり細かい規程にしない方がいいです。
改善会議で出た迷いを、1つの行動に変える。
まずはそれで十分です。
もちろん、会社として正式な規程が必要な場面もあります。
個人情報、契約、医療、金融、労務、機密性の高い業務が絡む場合は、専門家の確認も必要です。
ただ、すべてのAI活用を最初から正式規程にしようとすると、現場改善が止まります。
小さな会社の初期段階では、正式規程の前に「運用ルールカード」を作る感覚が合っています。
改善会議で決めたことを、1行で書く。
誰が見ても、次回の行動が分かるようにする。
これだけで、AI活用はかなり安定します。
ルールは長いほど強いわけではありません。
使われる粒度で書けているかが大事です。
入力・出力・確認・保存の4つに分けると迷いが減る
AI社内ルールを更新するとき、何でも同じ場所に書くと分かりにくくなります。
入力してよい情報の話。
AIが作った文章の確認の話。
外部へ送る前の承認の話。
ログの保存場所の話。
これらを全部まとめて「AI利用ルール」と書くと、読む側が迷います。
僕なら、最初は4つに分けます。
入力。
出力。
確認。
保存。
この4つです。
入力は、AIに何を渡してよいかです。
公開情報だけなのか。
匿名化すればよいのか。
社内資料を入れてよいのか。
顧客情報を入れないのか。
ここは安全面の土台です。
以前の 生成AIの社内ルールは、禁止より入力ルールから考える でも書いた通り、最初に「入れていい・確認して入れる・入れない」を分けると、現場の迷いが減ります。
出力は、AIから返ってきたものをどう扱うかです。
そのまま使ってよいのか。
下書きとして使うのか。
根拠確認が必要なのか。
表現だけ使って、事実は人が確認するのか。
AIの出力は、見た目がきれいです。
だからこそ、正しそうに見えてしまう。
でも、きれいな文章と正しい内容は別です。
ここを分けておかないと、現場は危ない使い方をしてしまいます。
確認は、誰が何を見るかです。
担当者本人が見るのか。
責任者が見るのか。
専門家に確認するのか。
外部送信前だけ見るのか。
社内共有でも見るのか。
AIエージェント導入前に決めたい権限設計 でも整理したように、AIが「読む・作る・送る・消す」のどこまで関わるかで、確認の重さは変わります。
文章の下書きだけなら軽い確認で足りるかもしれません。
でも、メール送信、顧客対応、契約条件、外部公開が絡むなら、確認者を決める必要があります。
保存は、あとから見返せる状態にすることです。
どの業務で使ったか。
何を入力したか。
AIの出力をどう直したか。
最終的に使ったか、使わなかったか。
次回の改善点は何か。
ここが残っていないと、改善会議で材料がありません。
AI社内ルールを更新するときは、この4つのどこを直す話なのかを分けます。
たとえば、問い合わせ返信で毎回迷いが出るなら、入力のルールを直すのか、出力確認のルールを直すのか、確認者を決めるのか、ログの残し方を変えるのかを分ける。
ここを分けるだけで、議論がかなり整理されます。
「AIが不安です」ではなく、「入力範囲が不安です」になる。
「ルールが足りません」ではなく、「外部送信前の確認者が決まっていません」になる。
問題が小さくなれば、ルールも小さく直せます。
ルールを増やすより、古いルールを直す担当を決める
AI社内ルールは、油断すると増えます。
新しいツールが出た。
新しい使い方を試した。
危ない場面があった。
お客様から質問された。
社内で不安の声が出た。
そのたびにルールを足していく。
最初はよくても、だんだん読まれなくなります。
なぜなら、現場から見ると「どれが今のルールなのか」が分からなくなるからです。
AIルールの運用で大事なのは、増やすことより直すことです。
古いルールを残したまま新しいルールを足すと、矛盾が生まれます。
以前は「社内資料はAIに入れない」と書いていた。
でも今は、法人契約した環境で一部の社内資料を扱うようになった。
そのとき、古いルールを残したまま「一部の社内資料は利用可」と追記すると、現場は迷います。
結局、どっちなのか。
誰が判断するのか。
どのツールならいいのか。
ここを整理しないと、ルールは安心材料ではなく混乱材料になります。
だから、AI社内ルールには担当者が必要です。
担当者といっても、AIにいちばん詳しい人である必要はありません。
むしろ、業務と現場の迷いを拾える人が向いています。
役割は大きく3つです。
1つ目は、改善会議で出た決定事項を1行ルールにすること。
2つ目は、古いルールと矛盾していないかを見ること。
3つ目は、次の会議で見直す候補を残すこと。
これだけでも十分です。
小さな会社なら、社長、事務担当、現場リーダー、外部伴走者の誰かが兼ねてもいいと思います。
大事なのは、「誰かが見ている状態」にすることです。
全員で管理するルールは、だいたい誰も管理しません。
いや、言い方が少し強いですが、実務では本当にそうなりがちです。
AI活用は変化が早いです。
ツールも変わる。
社内の使い方も変わる。
業務の優先順位も変わる。
だから、ルールも変わります。
変わる前提なら、更新担当を決める。
これが、AI社内ルールを生きた状態に保つための地味だけど大事な設計です。
ルールを作る人ではなく、ルールを育てる人を決める。
ここまで決まると、社内AIルールはかなり運用しやすくなります。
現場へ広げるときは、禁止ではなく判断例で共有する
社内AIルールを現場に共有するとき、禁止事項だけを並べると使われにくくなります。
これは入れてはいけない。
これはやってはいけない。
これは外に出してはいけない。
もちろん、禁止が必要な場面はあります。
でも、禁止だけだと現場はこう思います。
「じゃあ、何なら使っていいの？」
ここで止まります。
AI活用を社内に広げたいなら、禁止事項と一緒に判断例を出した方がいいです。
たとえば、問い合わせ対応ならこうです。
良い例。
顧客名、会社名、電話番号を伏せて、問い合わせ内容を要約させる。
注意が必要な例。
契約条件や料金交渉の内容を含む問い合わせ文を、そのままAIに貼る。
使わない例。
個人情報、決済情報、パスワード、非公開の契約情報を含む文章をAIに入れる。
議事録ならこうです。
良い例。
会議メモから決定事項、未決事項、次の担当を分けて整理する。
注意が必要な例。
人事評価、未発表の売上、社外秘の方針が含まれる会議メモを、そのままAIに貼る。
使わない例。
個人の健康情報や機密性の高い相談内容を、外部AIへ入力する。
ブログや資料ならこうです。
良い例。
公開済みの自社情報や匿名化した相談パターンを使って、構成案を作る。
注意が必要な例。
お客様の具体名や未公開事例を含む文章を、そのままAIに入れる。
使わない例。
他社の著作物を丸ごと貼って、書き換えだけを依頼する。
こうやって、具体例で共有すると、現場は判断しやすくなります。
ルールは、抽象度が高いほど正しそうに見えます。
でも、実務で使われるのは具体例です。
「個人情報に注意する」ではなく、「氏名、会社名、連絡先は伏せる」。
「AIの出力を確認する」ではなく、「外部送信前に事実、金額、約束表現を確認する」。
「機密情報を入れない」ではなく、「契約書、見積書、パスワード、未公開の顧客資料は入れない」。
この粒度まで落とすと、現場は動けます。
AI社内ルールは、守らせるためだけのものではありません。
安心して使える範囲を広げるためのものです。
禁止を伝えるだけで終わると、AI活用は萎縮します。
判断例を一緒に出すと、現場は「ここまでは使っていいんだ」と分かります。
ここが、AI内製化ではかなり大事です。
使わせたいのか、止めたいのか。
社内ルールの伝え方で、現場の受け取り方は変わります。
30日後に見直す前提で、社内AIルールを育てる
AI社内ルールは、最初から長く使える完成版にしなくていいです。
むしろ、最初は30日後に見直す前提で作った方がいいです。
なぜなら、最初のルールは仮説だからです。
この情報は入れない方がいいだろう。
この業務ならAIを使いやすいだろう。
この確認者で回るだろう。
このログ項目なら続くだろう。
全部、実際に使ってみないと分かりません。
だから、最初からこう決めておく。
30日後に見直す。
使われたルールを残す。
使われなかったルールを直す。
迷いが多かった箇所を具体例にする。
危なかった場面を入力・出力・確認・保存のどこかへ反映する。
これで十分です。
見直すときは、難しい評価表はいりません。
次の5つだけ見れば始められます。
- 実際に使われたAI業務は何か
- 迷いが多かった入力情報は何か
- AI出力で修正が多かった箇所はどこか
- 確認者が困った場面は何か
- 次の30日で追加・修正・削除する1行ルールは何か
大事なのは、ルールを増やすだけでなく、削除や統合も見ることです。
使われていないルール。
抽象的すぎるルール。
古いツール前提のルール。
現場の実態と合っていないルール。
こういうものを残したままにすると、社内AIルールはどんどん読みにくくなります。
ルールを育てるというのは、足すことだけではありません。
直す。
まとめる。
消す。
具体例にする。
担当を変える。
この全部が運用です。
中小企業や小規模事業者にとって、AI活用は大きなシステム導入だけではありません。
問い合わせ返信の下書き。
議事録整理。
資料構成。
FAQ案。
ブログやSNSの下書き。
社内マニュアルの整形。
こういう身近な業務から始まります。
だからこそ、社内AIルールも身近な言葉で育てた方がいいです。
最初から完璧なAIガバナンスを目指すより、現場で起きた迷いを1行ずつ直す。
その方が、会社に残ります。
AI活用を社内に広げたいけれど、ルール作りで止まっている。
運用ログや改善会議までは始めたけれど、社内ルールへの落とし込み方が分からない。
そんな場合は、まず1業務だけで構いません。
「次回からどうするか」を1行で決めてみてください。
その1行を、入力・出力・確認・保存のどこに入るか分ける。
30日後に見直す。
ここまでできれば、AI社内ルールは少しずつ育ちます。
カタチ舎では、生成AIの導入そのものだけでなく、業務棚卸し、入力ルール、運用ログ、改善会議、社内ルール更新まで含めて、AI内製化の進め方を一緒に整理しています。
「AIを使いたいけれど、社内でどう安全に回すかが曖昧」という方は、お問い合わせ から相談してください。
ツールを増やす前に、まずは今の業務と判断ルールを一緒に見える形にしていきましょう。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。