生成AIの社内ルールの作り方｜そのまま使えるひな形2点を全文公開

「AIを入れる前に、まず社内ルールを整備しないと」——顧問の現場で、この言葉を何度聞いたか分かりません。順番としては正しく聞こえます。ところが、この順番で始めた会社の多くが、AI活用にたどり着く前に止まります。利用規程のひな形を探し、総務や情報システム担当が条文を練り、承認を回している間に数ヶ月。ようやく完成した規程は立派ですが、そのころには現場の熱が冷めている。私の見聞きする範囲では、これが最も多い「AI導入が始まらない理由」です。

先に結論を言います。生成AIの社内ルールは、「作ってから使う」ではなく「小さく使いながら育てる」。そして紙の規程としてではなく、「AIが毎回読む設定ファイル」として作る。この2点を変えるだけで、ルールは「活用を止める門」から「活用を支える手すり」に変わります。これが、生成AI顧問として累計15社ほど、研修・講座を含めれば30社超の企業を支援してきた私の結論です。

ここからは、私が顧問先に実際に配っているルールのひな形を、2点セット——人間向けの「1枚ガイド」と、AIが毎回読む「agent.md」——の全文でそのまま公開します。会社名と管理者名を入れ替えれば今日から使える完成度にしてあります。あわせて、ルールに入れるべき7項目、従来の情報セキュリティ規程との決定的な違い、運用の中でルールを育てる方法まで、この1本で社内ルールづくりが完結するように書きました。

※本記事は2026年7月10日時点の各サービス仕様に基づいています。学習設定の初期値などは変わることがあるため、個別の手順は最新の公式情報もあわせて確認してください。なお、AIに何を見せてよいか・壊れたらどう戻すかという「設計の考え方」そのものは、AI導入のセキュリティ設計の記事で先に詳しく書きました。本記事はその実践編——考え方を「そのまま配れるルール」に落とす回です。

---

なぜ「規程を作ってから」の順番だと止まるのか

生成AIの利用規程やガイドラインを「先に」整備しようとする会社は、真面目な会社です。だからこそ止まり方も真面目です。ひな形を探し、他社事例を集め、リスクを洗い出し、条文をレビューする。どの工程も正しい。ただし、その間、現場では誰もAIを使っていません。使っていない業務のルールを、使ったことのない人が書く——ここに構造的な無理があります。

私の見聞きする範囲では、こうして作られた規程には共通のパターンがあります。想像で書かれた禁止事項が並び、「起こらなそうな事故」への備えは厚いのに、実際に起こる事故——古い資料を読ませて堂々と間違った回答をさせる、AIの下書きを未確認のまま送ってしまう——はカバーされていない。そして何より、完成した瞬間が規程のピークで、あとは誰も読み返さない。立派なAI利用規程を作った会社ほど活用が進んでいない、という逆転現象すら珍しくありません。規程の存在自体が「ルールはもう整備した」という安心を生み、現場は「何をしたら怒られるか分からないから触らない」まま止まる。門は立派に建ったのに、誰もくぐらないのです。

最初にできるルールは、たいてい長すぎる

偉そうに書いていますが、私の会社のルールファイルも、最初からいまの短さだったわけではありません。事故が怖くて禁止事項と確認手順を足すたびに長くなり、何度も書き直しては削って、いまの形に落ち着いています。そして顧問先で最初にできあがるルール案も、ほぼ例外なく長すぎる。理由は単純で、使う前に書くルールは「起こるかもしれない全部」に備えようとするからです。でも、長いルールは読まれなくなり、読まれないルールは守られません。ルールの価値は網羅性ではなく、毎回読まれることにある——書き直しを重ねてたどり着いた結論です。

だから顧問先には、順番を逆にしてもらっています。①最低限の3つ（後述する学習オプトアウト・入力の線引き・出力は下書きまで）だけ決めて、まず小さく使い始める。②実際に困ったこと・ヒヤリとしたことだけをルールに足す。③月に1回見直す。ルールは机上で完成させる文書ではなく、運転しながら描き足していく地図です。走ったことのない道の地図を、想像で描き込むから止まるのです。

誤解のないように添えると、「ルールなしで好きに使わせてよい」という話ではありません。初日に決めるべき最低限は確かにあります。それを含めて、私が顧問先で最終的に行き着く共通項が、次の7項目です。

生成AIの社内ルールに入れるべき7項目

7項目それぞれの「なぜ必要か」という設計の理屈は考え方編の記事で詳しく書いたので、ここでは「ルール文としてどう書くか」に絞ります。まず全体を一覧で。右列の型は、そのまま自社のルールに流用してかまいません。

#	項目	決めること	ルール文の型（流用可）
1	学習オプトアウト	全員分の設定オフと記録	利用する全アカウントで入力データの学習利用をオフにし、設定画面を保存する
2	入力情報の3段階	そのまま／必要時のみ／渡さない、の線引き	個人情報・非公開の契約情報・パスワード類は入力しない。必要な業務ではダミー化・匿名化して渡す
3	出力は下書きまで	社外に出る文書の最終確認者	社外提出文書は必ず人間の確認を受けてから使用する。送信・提出は人が行う
4	認証情報の扱い	例外なしの禁止事項	APIキー・パスワード・認証情報は、AIにも共有場所にも一度も入れない
5	危険操作の許可制	確認省略モードの扱い	確認を省略する全自動モードは原則使わない。使う場合は範囲を限定し、管理者が許可する
6	バックアップ	「戻せる」状態の作り方	AIの作業場所は専用フォルダに限定し、クラウドの履歴管理で元に戻せる状態を保つ
7	見直しサイクル	頻度・管理者・変更履歴	ルールは月1回見直す。違反・ヒヤリは責めず、ルール改定の材料にする

1. 学習オプトアウト——ルールの前提になる初日の設定

ChatGPTやClaudeの個人向けプランは、入力データがAIの学習に使われる設定が初期状態でONです（2026年7月時点）。全員分をオフにして、設定画面をスクリーンショットで記録する——これはルールというより、ルールを書く前提の土台です。ここを飛ばして「機密を入れるな」という条文だけ作っても、床の抜けた家に施錠しているようなものです。ルール文には「オフにする」だけでなく「記録する」まで含めるのがコツです。取引先から「AIのデータの扱いはどうなっていますか」と聞かれたとき、口頭でなく画面で答えられるかどうかが、信頼の差になります。

2. 入力情報の3段階——全か無かにしない

「そのまま渡してよい情報」「その作業のときだけ参照させる情報」「直接渡さず、ダミー化して渡す情報」の3段階に分けます。ここでよくある書き方の失敗は、禁止する情報だけを列挙してしまうことです。禁止リストだけのルールは、現場に「じゃあ何なら入れていいのか」という迷いを残し、迷った人は使わなくなります。「そのまま入れてよいもの」を明記することが、活用のアクセルになります。自社の実際の情報名——顧客リスト、図面、レシピ、見積データ——で書き換えると、ルールの効き方がまるで変わります。

3. 出力は「下書きまで」——仕事の単位を決める

AIの成果物はすべて下書きであり、社外に出るもの——メール、見積、提案書——は人間が確認してから送る。この一文があるだけで、「AIが間違ったことを書いたらどうする」という不安の大半は消えます。事故の可能性を消すのではなく、事故が社外に出る前に必ず人間を通る構造にするからです。書き方のコツは「AIの回答を鵜呑みにしない」のような心構え表現を避けること。心構えは守れたか検証できません。「送信・提出は人が行う」という行為の線で書きます。

4. 認証情報——唯一の「例外なし」

APIキー・パスワード・認証情報は、AIへの入力にも、チームの共有場所にも、一度も入れない。7項目の中でこれだけは、初日から例外なしの禁止として書きます。理由は不可逆性です。他の違反はやり直せますが、共有履歴に一度入った鍵は、消したつもりでも履歴に残ります。誤って入れてしまった場合の正解は削除ではなくキー自体の無効化・再発行——ここまでルール文に書いておくと、いざというとき現場が正しく動けます。

5. 危険操作の許可制——「速いから」で外さない

Claude Codeのような自律型のAIエージェントには、ファイル操作やコマンド実行の前に人間へ許可を求める仕組みがあります。この確認を省略して全自動で走らせるモードは、原則使わない。使う場合は「このフォルダ内のみ」「削除はしない」と範囲を固めて管理者が許可する——例外扱いにします。確認が面倒になってくる時期が必ず来ますが、面倒になったときこそ、確認が仕事をしている時期です。

6. バックアップ——「壊されないか」ではなく「壊れても戻せるか」

AIの作業場所を専用フォルダに限定し、クラウドの履歴管理やGit連携で「元に戻せる」状態を保つ。事故をゼロにする設計は現実的ではありませんが、事故がダメージにならない設計は今日からできます。ルール文としては「AIは専用フォルダの中で働かせる」という1行が本体です。この1行が、後述するagent.mdの「参照してよい範囲」の条項とそのまま対応します。

7. 見直しサイクル——ルールに「育つ仕組み」を内蔵する

ここが従来の規程づくりで最も抜け落ちる項目です。誰が管理者か、どの頻度で見直すか、変更履歴をどこに残すか。この3点をルール自体に書いておくと、ルールは配布物ではなく運用物になります。詳しくは後半の「運用の育て方」で書きますが、先に一つだけ——見直しの材料は違反とヒヤリです。それを集めるためにも、違反を責めない方針をルール文の中に明記しておきます。

そのまま使えるひな形全文——「1枚ガイド」と「agent.md」の2点セット

お待たせしました。ここからが本題の持ち帰りです。私が顧問先に配っているルールのひな形を、2点セットの全文で載せます。なぜ2点なのか。人間向けの文書だけだと、AIは読まない。AI向けの設定ファイルだけだと、人間側の行動が揃わない。だから、人間の入口になる「1枚ガイド」と、AIが作業のたびに読む「agent.md」を対で運用します。書いてある中身は同じ7項目です。同じルールを、人間には人間の言葉で、AIには命令形の短文で渡す——それだけのことですが、この「それだけ」をやっている会社はまだ少数です。

ひな形①：人間向け「生成AI利用ガイド」（全社員向け・1枚版）

◯◯に会社名、△△に管理者名（推進担当者名）を入れれば、そのまま配れます。印刷してA4一枚に収まる分量に抑えてあります。分量を増やしたくなったら、この記事の前半——長いルールは読まれなくなる話——を思い出してください。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
【株式会社◯◯】生成AI利用ガイド（全社員向け・1枚版）
版数：v1.0 ／ 最終更新：20XX年X月X日 ／ 管理者：△△
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■ 基本方針
・生成AIは業務に積極的に使ってよい。ただし、このガイドの範囲で使う。
・迷ったら、使う前に管理者（△△）に聞く。聞いた人を責めない。

■ 最初に必ずやること（初回のみ）
1. 会社が認めたツール・アカウントで使う（認めたツールは別紙一覧を参照）。
2. 設定で「入力データをAIの学習に使う」をオフにする（個人プランは初期設定がON）。
3. オフにした設定画面のスクリーンショットを保存し、管理者に送る。

■ 入力してよい情報（3段階）
○ そのまま入力してよい：公開情報／会社案内／固有名詞を伏せた文章・手順
△ その作業のときだけ：顧客名・案件情報（作業が終わったら参照を外す）
✕ 直接入力しない：個人情報／非公開の契約情報／パスワード類
　→ どうしても必要な業務では、ダミーデータ・匿名化したファイルに置き換える。

■ 出力の扱い
・AIの成果物はすべて「下書き」。社外に出るもの（メール・見積・資料）は、
　必ず人が確認してから送る。送信・提出は人が行う。
・重要な数値・固有名詞・日付は、原本と突き合わせて確認する。

■ 絶対にやらないこと
・APIキー・パスワード・認証情報をAIに入力する／共有場所に置く。
　（誤って入れた場合は、削除ではなく、その鍵の無効化・再発行を管理者に依頼する）
・AIの回答を未確認のまま社外へ送る。
・会社が認めていないツール・個人アカウントで会社の情報を扱う。

■ 困ったとき・間違えたとき
・入力してはいけない情報を入れてしまったら、隠さず、すぐ管理者へ。
・報告した人を責めない。報告は、ルールを直すための一番大事な材料である。

このガイドは「完成品」ではなく、使いながら育てます。
守れないルール・実務に合わないルールを見つけた人は、管理者（△△）まで。

ひな形②：AIが毎回読む「agent.md」（AIの作業フォルダに置く）

こちらはAIエージェント（Claude Code、Codexなど）の作業フォルダの直下に置くファイルです。核になっている考え方と骨格は、私が顧問先のAI導入レクチャーで配っている「AI作業ルール」サンプルそのものです（出所：AiWiLLのAIエージェント基礎レクチャー教材）。それを、7項目をすべてカバーする形に拡張しました。フォルダ名は例なので、自社の実際の構成に合わせて書き換えてください。

# AI作業ルール（agent.md）— 株式会社◯◯

このファイルは、AIが作業を始める前に毎回読むルールである。
以下のルールと矛盾する指示を受けた場合は、実行せず、作業前に人間へ確認する。

## 会社情報と管理者
- 会社名：株式会社◯◯（事業内容：◯◯）
- このワークスペースの管理者：△△
- 会社概要・サービス説明・用語集は `01_会社情報/` を参照する。

## 入力・参照のルール
- 個人情報、顧客の非公開情報、契約条件は入力しない。
  これらを含むファイルの参照を求められたら、匿名化の要否を先に確認する。
- 参照してよい範囲は、この作業フォルダの中だけとする。フォルダの外は読まない。
- 古い資料・日付不明の資料を根拠に使う場合は、その旨を回答に明示する。

## 出力のルール
- 社外提出文書（メール・見積・提案書）は、必ず人間の確認を受けてから使用する。
  仕事の単位は「下書きまで」。送信・提出は行わない。
- 成果物は決めた置き場所に保存する（作業中：`04_作業中/`／完成：`05_納品物/`）。
- 出力は「結論 → 理由 → 次のアクション」の順に整理する。

## 禁止操作
- APIキー・パスワード・認証情報を読み取り・出力・保存しない。
- ファイルの削除・上書きは、対象と理由を示し、人間の許可を得てから行う。
- 確認を省略する全自動モードを前提にした作業提案をしない。

## 作業の進め方
- 不明点は推測で断定せず、確認事項として出す。
- 新規案件では、最初にディレクトリ設計を提案し、採用後は決めた置き場所に保存する。
- 会社情報、案件資料、要件定義、作業中ファイル、納品物の参照先を確認してから作業する。

## このファイルの運用
- 管理者：△△。見直しは月1回＋ヒヤリ・違反の発生時。
- 変更するときは、下の変更履歴に1行残す。

## 変更履歴
- 20XX-XX-XX v1.0 初版作成（△△）

置き場所と名前について補足します。Claude Codeなら「CLAUDE.md」、Codexなら「AGENTS.md」という名前で作業フォルダに置くと、AIが起動のたびに自動で読みます。ツールを問わない一般名称としてagent.mdと呼んでいますが、本質はファイル名ではなく「AIが毎回読む場所に置く」ことです。チャット型AIしか使っていない段階なら、プロジェクト機能のカスタム指示欄に同じ内容を貼れば、効果はほぼ同じです。

従来の情報セキュリティ規程との決定的な違い——ルールを「AIが毎回読む設定ファイル」にする

ここが本記事でいちばん伝えたい一点です。従来の情報セキュリティ規程は、正直に言えば「読まれない前提」で設計されています。入社時に読んで誓約書に判を押し、あとは監査の前に見返すだけ。それでも機能してきたのは、教育と誓約と監査という外側の仕組みで実効性を担保してきたからです。ところが生成AIのルールでは、状況が根本から変わります。ルールを守らせたい相手の一人が、AI自身だからです。そしてAIは、人間と違って、毎回読むことを面倒がりません。

観点	従来の情報セキュリティ規程	AIが毎回読む設定ファイル（agent.md）
読む主体と頻度	人間が入社時と監査前に読む	AIが作業のたびに毎回読む（人間は1枚ガイドで補完）
実効性の担保	教育・誓約書・監査	AIが参照して実行。矛盾する指示には作業前に確認を返す
更新のコスト	改定手続きが重く、年1回が現実的	テキスト1行の修正。直したその日の作業から反映
文体	条文体・網羅的	命令形の短文・A4一枚以内
違反への働き方	事後に発覚し、指摘・懲戒で対応	作業前の確認として現れる（事前に止まる）
形骸化したときの症状	誰も気づかない	AIの挙動が実務とズレるので、すぐ気づく

私はAI導入の方法論を「優秀なAI社員＝Prompt×Context×Harness」という式で説明しています。伝え方×会社の情報密度×守らせるルール。agent.mdはこのHarness（ハーネス）の実装であり、社内ルールをagent.md化するというのは、規程をHarnessに変換するということです。人間への通達は破られても気づけませんが、AIが毎回読む設定ファイルは、破られる前に「このルールと矛盾しますが、実行しますか」という確認になって現れる。ルールが事後の裁きから、事前の手すりに変わるのです。

一つ、誠実に添えておきたい注意があります。agent.mdを置けばAIが100%ルールを守る、という保証はありません。AIは確率的に動くもので、まれに読み落としも起きます。だからこそ、7項目は多重の手すりとして設計してあります。仮にAIがルールを読み落としても、出力は下書きまでだから社外に出る前に人間を通る。仮にファイルを壊しても、専用フォルダとクラウド履歴で戻せる。設定ファイル・人間の確認・戻せる構造の三層で守る——どれか一つに全体重をかけない設計です。

すでに情報セキュリティ規程がある会社は、置き換える必要はありません。既存規程の下に、この1枚ガイドを「生成AI利用に関する運用ガイドライン」として、agent.mdを「その実装」としてぶら下げてください。重い改定手続きを通さずに、運用文書として月次で育てられる位置に置くのがポイントです。

運用の育て方——違反を責めず、ルールを直す

ひな形を配ったあとの運用について、私が顧問先に必ず伝えていることは一つです。違反が起きたら、人を直すのではなく、ルールを直す。違反やヒヤリは、ルールが実務に合っていないというシグナルです。禁止した情報をつい入れてしまう業務があるなら、そこにはダミー化の手順が用意されていないという設計の穴がある。責めれば報告が消え、報告が消えれば、社員は見えないところで個人アカウントを使い始めます。いわゆるシャドーAIの大半は、ルールが厳しいから生まれるのではなく、ルールが直らないから生まれます。

短いルールが続く実例——「書かないもの」を先に決める

顧問先での実例を一つ——セキュリティ設計の記事でも紹介した例ですが、今度は「ルール文の書き方」として見てください。業歴30年以上の総合防災点検会社・株式会社WECSでは、AIに書かせる業務ログの運用ルールを作るとき、「何を書くか」ではなく「書かないもの」を先に4つだけ決めました——秘密情報・個人情報・顧客の非公開情報・パスワード類。書いてよいことを網羅的に定義する代わりに、越えてはいけない線だけを最小の本数で引く。ルールが短いから全員が覚えていて、覚えているから運用が続いています。禁止事項は、少数精鋭にするほど強くなる。長すぎるルールを削り続けてきた私の経験を、顧問先では最初から仕組みにしてもらっている格好です。

変更履歴は「育てた証拠」になる

agent.mdの末尾に変更履歴を残すのは、単なる管理作法ではありません。「いつ・何を・なぜ変えたか」の1行が積み重なった変更履歴は、この会社がルールを運用しながら育てている証拠そのものです。取引先からAIの利用体制を聞かれたとき、立派な規程の表紙を見せるより、月次で更新されている変更履歴を見せるほうが、はるかに信頼されます。見直しの頻度は、導入から3ヶ月は月1回、その後は四半期に1回＋ヒヤリ発生時の臨時見直し、が私の推奨です。所要時間は毎回15分もあれば足ります。議題は2つだけ——「守れなかったルールはどれか」「新しく困ったことは何か」。

そして、1人で使う段階からチームへ広げる段階に入ると、ルールと一緒に会社の情報（コンテキスト)を共有する設計が必要になります。共有した瞬間に閲覧範囲が個人からチームへ広がるため、「共有に入れるもの・入れないもの」の線引きが要る——この設計はコンテキストのチーム共有の記事で、私の自社運用の実物を含めて書きました。ルールが1枚で回り始めたら、次はそちらへ進んでください。

よくある質問（顧問先で実際に聞かれる順）

Q1. ひな形はそのまま使っていいですか。どこを書き換えるべきですか？

そのまま使ってください。書き換え必須は3ヶ所——会社名、管理者名、フォルダ名（agent.mdの参照先を自社の実際の構成に合わせる）です。加えて効果が大きいのは、入力3段階の中身を自社の実際の情報名（顧客リスト・図面・レシピ・見積データなど）に置き換えることです。逆にやらないでほしいのは、配る前に禁止事項を足し込むこと。足すのは運用が始まって、実際に困ってからで間に合います。

Q2. 既存の情報セキュリティ規程や就業規則との関係はどうすればいいですか？

既存規程の置き換えではなく、その下にぶら下げてください。1枚ガイドを「生成AI利用に関する運用ガイドライン」、agent.mdをその実装として位置づければ、重い改定手続きなしで月次更新できます。なお、違反を懲戒と結びつけたい場合は就業規則との整合が必要になるため、その段階では社会保険労務士や弁護士に確認してください。ただ私の顧問先では、懲戒の議論より先に運用を回すことを勧めています。1枚ガイドは罰するための文書ではなく、迷わないための文書だからです。

Q3. 社員がすでに個人アカウントで勝手に使っています。禁止すべきですか？

禁止から入ると、利用が見えなくなるだけです。先にやるべきは、会社が認めるツールとアカウントを決めて、全員分の学習オプトアウトを設定し、野良利用を公認の入口に吸収すること。そして、すでに使っている社員を「違反者」ではなく「先行ユーザー」として扱ってください。その人が実務でどう使っているかを聞き取ると、自社に合ったルールの初版が最短で書けます。ルールの材料を一番持っているのは、先に使っていた人です。

Q4. ChatGPTとClaudeなど複数ツールを併用する場合、ルールは分けるべきですか？

分けなくて大丈夫です。ひな形が「会社が認めたツール」という書き方にしてあるのはそのためで、ツール名は別紙の一覧で管理し、ルール本体はツールに依存しない書き方にします。ツールは入れ替わりますが、7項目の骨格は変わりません。ちなみに費用感でいうと、私の顧問先の実務では、ツール実費は1人あたり月3,000円〜1万円程度に収まっています。ルール整備を理由に高価な専用システムから入る必要はありません。

Q5. agent.mdはどこに置くのですか。チャット型AIしか使っていない場合は？

AIエージェントの作業フォルダ直下です。Claude Codeなら「CLAUDE.md」、Codexなら「AGENTS.md」という名前にすると自動で毎回読まれます。チャット型AIだけの段階なら、プロジェクト機能のカスタム指示欄に1枚ガイドの内容を貼ってください。本質は「AIが毎回読む場所に置く」ことで、ファイル名や置き場所は手段です。エージェント型に進むときに、カスタム指示の内容をagent.mdへ引っ越せば、それまでの運用がそのまま資産になります。

Q6. 罰則は入れるべきですか？

初期は入れないことを勧めます。最初に罰則を置くと報告が止まり、ルールを育てる材料——ヒヤリと違反の実例——が入ってこなくなるからです。罰則を検討してよいのは、ルールが定着して報告文化ができた後です。ただし一つだけ例外があります。認証情報だけは、初日から「絶対にやらないこと」として明記してください。これは不可逆な事故だからです。それ以外は「責めずにルールを直す」で運用するほうが、結果として違反は減ります。

持ち帰り用：生成AI社内ルール導入チェックリスト

ひな形2点とあわせて、導入の進み具合をこのチェックリストで確認してください。上から順に進めれば、専任の情シス担当がいない会社でも、1〜2日でルールの初版が立ち上がります。

1. 会社として使うAIツールとプラン（アカウントの持ち方）を決めた
2. 利用する全員のアカウントで学習利用をオフにし、設定画面を記録した
3. 入力してよい情報の3段階を、自社の実際の情報名で仕分けした
4. 「社外に出る文書は下書きまで・送信は人が行う」と決め、最終確認者を決めた
5. 認証情報は一度も入れない・誤入力時は無効化と再発行、と明記した
6. 確認を省略する全自動モードは原則使わないと決めた
7. AIの作業場所を専用フォルダに限定し、クラウド履歴で戻せる状態にした
8. 1枚ガイドを自社名入りに直して配布し、「聞いた人・報告した人を責めない」と伝えた
9. agent.md（CLAUDE.md／AGENTS.md）をAIの作業フォルダに置いた
10. 管理者・見直し頻度・変更履歴の置き場所を決め、初回の見直し日を予定に入れた

まとめ：ルールは門ではなく、手すり

規程を先に完成させる力のある会社ほど、立派な門を建てて、その前で止まります。生成AIの社内ルールは、くぐらせるための門ではなく、進みながら掴むための手すりです。作ってから使うのではなく、小さく使いながら育てる。人間への通達で終わらせず、AIが毎回読む設定ファイルにする。違反を責めず、ルールを直して、変更履歴に1行残す——この記事のひな形2点は、そのための最初の足場として作りました。◯◯を自社名に置き換える5分から、始めてください。

そして、ルールが回り始めた会社が次に取り組むべきは、AIに会社の仕事を教える設計——フォルダとコンテキストの整備です。ルールづくりで整理した「見せてよい情報」は、そのままAIが最も良い仕事をするための教材になります。守りの1枚が、攻めの土台になる。この順番で進めたい企業に伴走するのが、私の生成AI顧問の仕事です（AI顧問とは何かはこちら）。

ひな形を自社の名前に書き換えていて手が止まった箇所があれば、それがあなたの会社の「線引きの論点」です。その論点を整理するための無料の資料セットを、こちらに置いておきます。