「AIのルールを作りたい」と言われて、4項目にしました──禁止事項を並べなかった理由

支援先の社長から、こう相談されました。
「AI の使い方に、ルールを設けたい。」
きっかけは、8 月初旬に続いた AI に関する報道でした。AI がテスト中に実在企業へ侵入した件をはじめ、不安になる見出しが並んだ時期です。
そして、指示にはこう添えられていました。
「まずは軽いテイストで。」
——この一言が、実はいちばん重要だったと思っています。
出来上がったのは、4 項目だけのルールです。禁止事項の羅列ではありません。この記事では、その 4 項目と、なぜそう書いたのかを公開します。
※ 支援先は、約 510 室の月極マンションを運営する不動産管理会社です。社名は伏せています。また、運用が始まってまだ日が浅く、定着の成否をお伝えできる段階ではありません。この記事は「作ったもの」と「その設計理由」の話です。
前提:ルールが追いついていない会社は、多い
まず、これが特殊な悩みではないことを数字で確認します。
商工中金の調査(2026 年 1 月/有効回答 3,892 社)では、生成 AI の導入・推進における課題として、「社内ルールや方針整備が追い付かない」が 25.1% で挙がっています。
そして同じ調査で、より根本的な数字がこれです。
| 生成 AI の導入状況 | 割合 |
|---|---|
| 会社として導入している | 16.3% |
| 会社導入なし。個人契約の活用を推奨 | 14.9% |
| 会社導入なし。使用は個人の判断に任せる | 64.9% |
| 会社での使用を禁止・制限 | 1.4% |
別の記事でも触れましたが、6 割以上の会社が「個人の判断に任せる」状態です。つまり、ルールがないのではなく——そもそも会社として何も決めていない。
今回の相談は、その状態から一歩出よう、という話でした。
最初に決めたのは、「何をしないか」
ルールを書き始める前に、3 つのことを決めました。
1. 禁止事項の羅列にしない
いちばんやりがちで、いちばん効かないのがこれです。
「〜してはいけない」を並べた文書は、読まれません。読まれても覚えられません。そして守られなかったとき、「ルールに書いてあったのに」と言うための道具になります。それは統制ではなく、責任転嫁の準備です。
そもそも——AI がテスト環境を越えた件で書いた通り、言葉で書いた制約は、制約になりません。「するな」と書くだけで防げるなら、あの事故は起きていません。
2. 承認制にしない
「AI を使うときは上長の承認を得ること」——これを入れると、現場は AI を使うのをやめます。あるいは、黙って使います。
AI エージェントの記事で紹介した Gartner の分析が、まさにこれを指摘しています。締めつけすぎると、**会社の管理外で勝手に使う「シャドー利用」**が広がる。統制するつもりが、いちばん統制の効かない状態を生む。
承認制は、いちばんそれを招きやすい設計です。
3.「軽いテイストで」を、額面通りに受け取る
社長からのこの指示を、私は「手を抜いていい」という意味には取りませんでした。
重い文書を作ったら、誰も読まないと分かっている——そういう意味だと解釈しました。実際、この判断は正しかったと思います。
分厚い規程を作ることは、仕事をした気になれるという点で危険です。作った側は満足しますが、現場は変わりません。発注したシステムが使われない理由と、まったく同じ構図です。
実際に作った 4 項目
そして出来上がったのが、これです。
| ルール | 何を防ぐか | |
|---|---|---|
| ① | 顧客情報は、会社の AI にだけ入れる | 個人アカウントへの機密情報の流出 |
| ② | AI と決めた判断基準は、共有する | 属人化。ただし承認制にはしない |
| ③ | 作ったツールは、置き場所と作成者メモを残す | 「誰が作ったか分からないツール」の量産 |
| ④ | AI の回答を、そのままお客様に送らない | 検証されないまま外部へ出ること |
以上です。4 行。
一つずつ、なぜそう書いたかを説明します。
① 顧客情報は、会社の AI にだけ入れる
禁止ではなく、行き先を指定しています。
「顧客情報を AI に入れてはいけない」と書くこともできました。でもそれだと、業務で本当に必要な場面で詰まります。入居者からの問い合わせを整理したい、契約書の内容を確認したい——こうした業務で AI が使えないなら、AI を導入した意味がありません。
この会社では、全社員が使える法人プランを導入済みでした。だから「入れるな」ではなく「こっちに入れて」と書けた。
これが重要な点です。受け皿を用意せずに禁止すると、現場は個人のアカウントで隠れて使います。 禁止事項は、代替手段とセットでなければ機能しません。
② AI と決めた判断基準は、共有する
これがいちばん考えた項目です。
AI を使って何かを判断すると、そこには判断基準が生まれます。「この問い合わせはこう分類する」「この条件ならこう対応する」——プロンプトに書いた基準が、実質的な業務ルールになる。
問題は、それが個人の手元にしか残らないことです。その人が異動したら、基準ごと消えます。技術的負債の記事で書いた「あの人しか分からない」が、AI の時代にも新しい形で生まれます。
だから「共有する」。ただし——承認は求めません。
ここが設計の肝です。
使う前の承認ではなく、使った後の共有。
前者は現場を止めます。後者は、むしろ資産が増えます。誰かが良いプロンプトを作ったら、それが全社の財産になる。ワールドの記事で書いた「判断基準の言語化」が、自然に進む仕組みでもあります。
この会社では、毎週の持ち回りで AI 活用事例を発表する場が、ルールより先に動いていました。② は、その流れを文章にしただけとも言えます。
③ 作ったツールは、置き場所と作成者メモを残す
AI で簡単なツールが作れるようになった結果、誰かが作った便利なツールが、社内に増えます。
これ自体は良いことです。問題は、半年後にこうなることです。
- どこにあるか分からない
- 誰が作ったか分からない
- 壊れたとき、誰も直せない
バイブコーディングの記事で「保守する人を、最初に決めておく」と書きました。③ は、その最小版です。
名前を書くだけ。 それだけで、責任の所在が消えるのを防げます。逆に言えば、名前を書けないツールは、業務で使うべきものではありません。
④ AI の回答を、そのままお客様に送らない
最後は、対外的な線引きです。
これはループの記事で書いた「ゲート」そのものです。自動と承認の間に、人を置く。
AI の文章は、それらしく整っています。だからこそ、確認せずに出せてしまう。そして間違いが外に出たとき、責任を負うのは会社です。AI は責任を負えません。
「そのまま送らない」だけなら、現場の負担はほぼゼロです。読んで、直して、送る。それだけ。
4 項目に共通する設計
並べてみると、共通点が見えてきます。
| 書かなかった形 | 実際に書いた形 |
|---|---|
| 顧客情報を入れるな | 顧客情報はこっちに入れて |
| 使う前に承認を得よ | 使った後に共有して |
| 勝手にツールを作るな | 作ったら名前を書いて |
| AI の回答を信用するな | そのまま送らないで |
すべて「〜するな」ではなく「〜して」の形になっています。
これは意図的です。禁止は、守られたかどうかを確認できません。行動の指定なら、できているかが見える。「共有されているか」「名前が書いてあるか」は、目で確認できます。
もうひとつ。4 項目とも、守るのに時間がかかりません。 名前を書く、共有する、読んでから送る——どれも数秒から数分です。
備品管理の記事で「入力が面倒なら、現場は続けられない」と書きました。ルールも同じです。 守るのに手間がかかるルールは、忙しい日から順に破られます。
書かなかったこと
あえて入れなかった項目も、いくつかあります。
- 使ってよい AI の一覧——変わるのが早すぎます。実際この会社でも、画像生成など特定の用途では別の AI の使用を許可しています。一覧にすると、更新が追いつきません
- 禁止する業務の一覧——書き切れませんし、書けば「書いていないことは全部やっていい」になります
- 違反した場合の罰則——最初のルールに入れるものではないと考えました。まず回すことが先です
- 細かい書式や手順——「軽いテイストで」を守るために落としました
ルールは、増やすより減らすほうが難しいと思っています。最初に 20 項目書くより、4 項目から始めて必要になったら足すほうが、確実です。
ルールより先にあったもの
正直に書くと、このルールが 4 行で済んだのには理由があります。
この会社では、ルールを作る前に、こういうことが動いていました。
- 全社員が使える法人プランの導入(① の受け皿になった)
- AI 推進のグループが社内にある
- 毎週、持ち回りで活用事例を発表する場がある(② の土壌になった)
つまり、使われている状態が先にあって、ルールが後から来た。
逆の順番——ルールを整えてから使わせる——だと、こうはいきません。誰も使っていない段階でルールを作ると、想像で書くことになるからです。想像で書いたルールは、たいてい厳しすぎるか、的外れになります。
AI 研修が定着しない理由で「壁は利用率ではなく使いこなし」と書きました。ルール整備も、使われ始めてからのほうが正確に書けます。
自社で作るなら
同じことをするなら、こう進めるのが現実的だと思います。
1. まず、受け皿を用意する 会社として使える AI を決める。ここがないと、① のような「こっちに入れて」が書けません。
2. 実際に使ってもらう 1〜2 か月でいい。何に使われるかを見てからでないと、必要なルールが分かりません。
3. 出てきた不安を、4 つ以内に絞る 経営者・現場の双方に「何が心配か」を聞く。たいてい、情報漏洩・品質・属人化・対外的な事故の 4 方向に収まります。
4.「〜するな」を「〜して」に書き換える 禁止で書いたものを、行動の指定に直す。代替手段とセットにする。
5. 1 枚に収める 2 枚目に入ったら、削れないか考える。
まとめ
- 支援先の社長から「AI の使い方にルールを設けたい」と相談された。きっかけは 8 月初旬の AI に関する報道、指示は「軽いテイストで」
- 決めたのは「何をしないか」が先。禁止事項を羅列しない/承認制にしない/重い文書にしない
- 実際に作ったのは 4 項目。顧客情報は会社の AI にだけ/AI と決めた判断基準は共有する/作ったツールは置き場所と作成者メモを残す/AI の回答をそのまま客に送らない
- 共通する設計は 2 つ。「〜するな」ではなく「〜して」の形にすること、そして守るのに時間がかからないこと
- 承認制にしなかったのが最大の判断。使う前の承認ではなく、使った後の共有。前者は現場を止め、後者は資産を増やす
- そして——ルールが 4 行で済んだのは、使われている状態が先にあったから。順番が逆だと、想像でルールを書くことになる
AI のルールを作るとき、多くの会社は「何を禁止するか」から考えます。でも、**先に決めるべきなのは「どこに置き場所を作るか」**でした。
置き場所があれば、禁止する必要が減ります。
Acetyl:Tech は、AI の社内導入から、使われる状態での定着までを支援しています。 ルールをどう書くか以前に「そもそも何から始めるか」の段階のご相談も承ります。詳しくは「AI 導入・社内研修の支援」のページをご覧ください。
出典・参考
- 商工中金「中小企業の生成 AI の利用にかかる調査(2026 年 1 月調査)」(2026 年 3 月 31 日公表) 調査期間 2025 年 12 月 19 日〜2026 年 1 月 16 日/送付 10,772 社・有効回答 3,892 社(回収率 36.1%)
Read next
他の記事

経産省が言い始めた「AI-Ready化」を、中小企業の言葉に翻訳する
2026年8月、経済産業省のウェブマガジンで「AI-Ready化」という言葉が取り上げられました。企業内のバラバラなデータを、AIが業務で使える状態に整えること。ただし記事で語られているのは製造業と大企業の話です。中小企業にとって何を意味するのか、6つの条件をどう読み替えるのか、そして実際にやってみて分かったことを書きます。結論から言うと、中小企業のほうが問題は深刻で、しかも安く解けます。
読む
ローカルのノートアプリを、チームで共有する──Obsidianの共同編集をGitで実現した話
Obsidianのvaultをそのままgitリポジトリにして、チームで共有しています。最大の勘所は.gitignore——workspace.jsonを外さないとノートを開いただけで衝突します。実際の.gitignore、Sync methodをresetにしてはいけない理由、デイリーノートが衝突する構造、衝突時の直し方まで、手順として書きます。まだ解けていないスマホの課題も正直に。
読む
「ClaudeがAIテスト中に実在企業へ侵入」は、結局なにが起きたのか──ニュースだけでは分からなかった人へ
2026年7月30日、AnthropicがClaudeのサイバー能力テスト中に3組織へ不正アクセスが発生したと公表しました。見出しだけ見ると「AIの暴走」に読めますが、実際に起きたのは環境設定の不備です。まず先に——普段の業務でAIを使っている分には、同じことは起きません。そのうえで、何が起きたのかを時系列で整理し、報道で分かりにくかった点を解きほぐし、中小企業が持ち帰れる教訓を解説します。
読む