作った生成AIガイドライン、機能していないな……と思ったことはありませんか?——それは書き方が悪いからではありません。「人が読んで守る文書」として作っているからです。

先に結論を書きます。守られるガイドラインは、書いた内容を4つの層に振り分けて、下の2層は設定ファイルに落とし、上の2層だけを文書に残します。 全部を文書に書こうとすると、読まれずに終わります。
配ったのに使われない状態をどう直すかという全体像は、生成AI 社内導入を定着させる方法にまとめています。
この記事は、情報システム部門やDX推進担当の方が「生成AIのガイドラインを作っておいて」と言われたときに、そのまま作業に入れる形でまとめたものです。私たちDAIJOBUは営業・採用・バックオフィスを含む20名以上が毎日Claude Codeを使っている会社で、ここに書くのは自分たちが実際に運用している組み立て方です。
この記事の要点は3つ
- 生成AIガイドラインが読まれないのは書き方の問題ではなく、設定で止められることまで文書に書いているから。まず書く量を減らす
- 守る場所を①端末 ②コード設定 ③運用ルール ④人の4層に振り分け、①②は設定に落とし、文書に残すのは③④だけにする
- 禁止事項ではなく「渡してよい/加工すれば渡せる/渡さない」の3分類を書く。運用ルールは5つまでに絞る
4層の振り分けを自社のケースで組みたい方へ。①端末・②コード設定・③運用ルール・④人をどう分けるかは、サービス資料(無料・PDF)にまとめています。
目次
- うまくいかない生成AIガイドラインの3つの共通点|禁止事項リスト・設定の丸投げ・配って終わり
- 生成AI社内ガイドラインの作り方|4層構造に振り分けて組む
- ①端末の層|どのPC・どのフォルダで動かすかを環境で決める
- ②コード設定の層|「守ってほしいこと」を設定ファイルに書く
- ③運用ルールの層|生成AIの社内ルールは5つまでに絞る
- ④人の層|業務ごとの確認者と相談先を1行で決める
- 生成AIガイドラインに「書かないほうがいい」もの|設定値・ツール名・罰則・網羅的な禁止事項リスト
- 生成AI社内ガイドラインのチェックリスト|4層の分担表とそのまま使える9項目
- 生成AIガイドラインが読まれない5つの理由|「作っても、どうせ読まれないのでは」
- 生成AIガイドラインの運用|配って終わりにせず、最初の1業務を一緒に通す
- まとめ|生成AI社内ガイドラインの作り方(4層構造と3分類)
うまくいかない生成AIガイドラインの3つの共通点|禁止事項リスト・設定の丸投げ・配って終わり
生成AIガイドラインの作り方に入る前に、失敗の形を見ておきます。これから作るガイドラインが、このどれかになっていないかを確かめるためです。
失敗1|禁止事項リストになっている——シャドーAIが生まれる入り口
禁止事項リストは、いちばん多い失敗の形です。「個人情報を入力しない」「機密情報を入力しない」「業務外の利用を禁止する」——正しいことが書いてあります。しかし現場が知りたいのは「じゃあ何なら入れていいのか」です。
禁止だけを並べると、現場は判断できません。判断できないと、安全側に倒れて使わなくなるか、面倒なので自己判断で使い始めるかのどちらかになります。後者が、いわゆるシャドーAIです。
失敗2|設定ファイルで止められることまで、ガイドライン文書に書いている
「危険なコマンドは実行しない」「送信前に必ず確認する」——これらは設定で強制できることを、人の記憶に預けている状態です。
人は忘れます。忙しい日ほど忘れます。文書に書くべきなのは、設定では表現できない判断だけです。
失敗3|作って配って終わっている|生成AIの利用が個人任せのまま始まる
ガイドラインを作った時点をゴールにすると、現場でどう解釈されているかが誰にも分からないまま運用が始まります。1か月後に「実はみんな別々の理解で使っていた」と気づくのは、よくあることです。
日本企業の生成AI利用は86.4%に達している一方で、生成AIによる業務変革について「組織的な取組はない」と答えた企業が27.0%あります(総務省『令和8年版 情報通信白書』2026年7月公表)。使ってはいるが、組織の決めごとにはなっていない——この隙間で起きるのが、個人任せの利用です。
中小企業では64.9%が生成AIの使用を「個人の判断に任せている」という調査もあります(商工中金・2026年1月調査)。
こちらにデータがあります(一次資料)
調査 | 数字 | 公表時期 |
|---|---|---|
総務省『令和8年版 情報通信白書』(出典PDF) | 日本企業の生成AI利用 86.4%/生成AIによる業務変革について「組織的な取組はない」27.0% | 2026年7月公表 |
商工中金「中小企業の生成AIの利用にかかる調査(2026年1月調査)」n=3,892(出典PDF) | 生成AIの使用を「個人の判断に任せている」64.9% | 2026年3月31日公表 |
参照日:2026年8月26日。数値は各調査の公表時点のもので、以降の変動は反映していません。
生成AI社内ガイドラインの作り方|4層構造に振り分けて組む
生成AIガイドラインは、守る場所を4つの層に振り分けて作ります。私たちが実務で使っている捉え方をお見せします。
- 端末 ── そもそも、どこで動かすか
- コード設定 ── 人の注意力に頼らず、設定で止める
- 運用ルール ── 設定では書ききれない判断を、決めごとにする
- 人 ── 最後の判断と検収を、誰が持つか
文書に残すのは③と④だけ。①②は設定に落として、薄く読まれる文書にします。
この振り分けが、そのままガイドラインの作り方になります。
- ①と②に該当する項目は、文書ではなく設定に落とす。 一度設定すれば、人が忘れても効き続けます
- ③と④だけを、文書に残す。 ここは回し続けないと効かないので、短く、判断できる形で書きます
冒頭で「全部を文書に書こうとすると読まれずに終わる」と書いたのは、この意味です。ガイドラインを薄くするために、下の2層へ落とせるものを落とす。 これが作業の中心になります。

危ない操作は設定が自動で止め、文書は判断だけを短く教える。この2段構えが「構造で対策する」ということです。
①端末の層|どのPC・どのフォルダで動かすかを環境で決める
生成AIガイドラインの4層のいちばん下、①端末の層で決めるのは、AIが手を伸ばせる範囲そのものです。ここは文書ではなく環境設定で決めます。
決めること:
- どのPCで使うか(会社支給機に限るか、私物端末を許すか)
- どのフォルダで起動するか(作業用フォルダを切るか、業務データの本体がある場所で直接動かすか)
- 読ませないものを、読めない場所に置く(認証情報・鍵ファイルなど)
Claude Codeの場合、動ける範囲を箱で囲う仕組み(Sandbox)が用意されています。仮に読ませた資料に不正な指示が仕込まれていても、影響が及ぶ範囲を箱の中に限定しやすくなります。ただし万能ではなく、外部ツール連携の権限とあわせて初めて効きます。
人の注意力ではなく、環境そのものに最後の砦を持たせる考え方です。
ガイドライン文書に書くこと:ここはほぼゼロ。 「作業は◯◯フォルダで行う」の一行があれば十分です。残りは情シスが設定として持ちます。
②コード設定の層|「守ってほしいこと」を設定ファイルに書く
②コード設定の層は、多くの生成AIガイドラインが取りこぼしている層です。人に守らせようとしている内容の大半は、実は設定に書けます。
情報の3分類|「渡してよい/加工すれば渡せる/渡さない」を設定ファイルに書く
Claude Codeには、AIが毎回必ず読む設定ファイル(CLAUDE.md)を置く仕組みがあります。仕様はClaude Code の公式ドキュメントにあります。
ここに情報の線引きを書いておくと、現場が文書を覚えていなくても、線引きが効きます。
書く内容の骨格は3分類です。
分類 | 中身の例 |
|---|---|
渡してよい | 公開情報・社内で共有済みの資料・自分が作った下書き |
加工すれば渡せる | 顧客名や取引先名が入った資料(マスクしてから使う) |
渡さない | 個人情報そのもの・認証情報・持ち出しが契約で禁じられているもの |
この3分類が1つあるだけで、現場は「これは入れていいんだ」と判断できるようになります。禁止事項リストとの違いは、"使ってよい範囲"が書いてあることです。
権限設計|操作を3段階に仕分ける
AIにやらせる操作を、3つに分けて設定します(権限設定=Permissions)。
区分 | 該当する操作 |
|---|---|
そのままやってよい | 読み取り・検索 |
必ず人に聞く | 外部への送信・削除・本番環境の変更・公開 |
そもそもやらせない | 破壊的な操作・本番データベースの削除・機密の公開 |
MCPの権限|私たちが設定に落とすことにした、実際のヒヤリ
権限の仕分けを、私たちは最初から設定でやっていたわけではありません。きっかけは、AIに書き込み権限を渡したまま、社内のタスク管理とドキュメントが書き換わった出来事です。何が起きて、なぜ気づけなかったかは生成AIの情報漏洩リスクと対策に書きました。
そこで分かったのは、AIの一連の操作に紛れた1回の書き込みを、人が毎回目視で拾うのは無理があるということです。人の注意で拾うのをやめて、設定で効かせる形に移したのは、ここからです。
やったことは2つです。ひとつは、外部ツール連携(MCP)の権限を読み取り専用に絞り、書き込み・削除の権限をなくしておくこと。参照はできますが、タスクのステータスもドキュメントも、AIの側からは変えられなくなります。書き込みを許す場面では、あわせて動作の確認を挟みます。
もうひとつは、設定ファイルを先に配ってしまうことです。人数の多い組織に研修で入るとき、私たちは「各自でこの設定にしてください」とは頼みません。権限を絞った状態の設定ファイルを、最初から全員に配ります。
各自に設定を頼む形は、人数が増えるほど崩れます。設定作業そのものが受講者ごとの環境差でつまずく作業で、しかも「後でやります」と言われた分は、たいてい後でもやられません。やっていない人がどこにいるかも分からない——この状態が、②の層に穴が開いたまま人だけ増えていく典型です。
配る側で決めておくのは3つです。外部ツール連携をどこまで許すか/どの操作を実行前に人へ確認させるか/そもそも実行させない操作は何か。 この3つを書いた設定ファイルを1つ作れば、あとは配るだけで全員に同じ前提が入ります。個人が育てるのを待つのではなく、会社の側から前提を配るという順序です。
ルールを浸透させてから絞るのではなく、絞った状態から始める。順番をこちらにすると、②の層は人数が増えても崩れません。
自動停止|危ない操作は、実行される前に止める
危険なコマンドの実行前停止、機密情報が記録に残る前の自動ブロックなど(Hooks)、設定側で塞げるものは塞ぎます。
そしてここが大事な一点です。この安全装置の設定そのものを、現場の判断で緩められない形にしておく。 ここを開けたままにすると、②の層は見た目だけになります。
ガイドライン文書に書くこと:「これらは設定で担保している」という事実と、設定変更の申請先だけ。 設定の中身は文書に転記しません(転記した瞬間に二重管理が始まり、片方が古くなります)。
③運用ルールの層|生成AIの社内ルールは5つまでに絞る
③運用ルールの層が、ガイドライン文書の本体にあたります。設定で表現できるのは「やってよい/だめ」までで、「この場面ではどう判断するか」は、決めごととして書くしかないからです。
ここに書くべきものは、実はそう多くありません。
- 確認を求められたら、中身を見てからOKを出す……反射で「はい」を押さない。迷ったら手を止める
- 大きな変更は、計画を先に出させてから実行する……いきなり実行させない。一度に大きく変えない
- 外部送信は許可制……AIがやるのは下書きまで。人が確認して、はじめて送信する
- 作業の記録を残す……誰が何を変えたかを追えて、元に戻せる状態にしておく
- 秘密が漏れたら、消して終わりにしない……一度記録に残った認証情報は、作り直す
ルールは5つまでに絞ります。
5つに絞っているのは意図的です。 ルールは増えるほど読まれなくなります。6つ目を足したくなったら、まず「②の設定に落とせないか」を検討してください。落とせるなら、文書には書きません。
④人の層|業務ごとの確認者と相談先を1行で決める
生成AIガイドラインの4層のいちばん上、④人の層は、仕組みに置き換えられません。ここに書くのは、責任の所在です。
- 判断と検収は人に残す……AIは下書きと実行を担い、それでよいと決めるのは人
- 業務ごとに、確認する人を決めておく……「みんなで気をつける」は、誰も見ていない状態と同じです
- 困ったときの相談先を書く……これが無いガイドラインは、迷った人を自己判断へ押し出します
この層を曖昧にしたまま自動化を広げると、①〜③をどれだけ固めても、誰も最終責任を持っていない状態が生まれます。
生成AIガイドラインに「書かないほうがいい」もの|設定値・ツール名・罰則・網羅的な禁止事項リスト
生成AIガイドラインを作っていると、つい追加しがちな内容を集めてみました。後々不要になったり、困る種になったりするので、それぞれに対策を用意しました。
書きがちなもの | 書くと何が起きるか | 代わりにどうするか |
|---|---|---|
設定値そのもの | 設定を変えたときに文書が古くなり、間違った情報を配る状態になる | 設定は設定側に置き、文書には「設定で担保している」事実だけ書く |
ツール名・モデル名前提の手順 | 更新が速く、半年後には画面も名称も変わる | ツールが変わっても残る判断を書き、操作手順は別文書に切り出す |
罰則規定 | 現場が判断に迷っても相談しなくなる | 罰則ではなく、迷ったときに聞ける相談先を書く |
網羅的な禁止事項リスト | 網羅するほど長くなり、長くなるほど読まれない | 「渡さない」は3〜5個に絞り、残りは「加工すれば渡せる」に寄せる |
生成AI社内ガイドラインのチェックリスト|4層の分担表とそのまま使える9項目
作った生成AIガイドラインを、この順で確認してください。すべて「はい」になれば、守られる形になっています。
4層の分担を一枚にまとめると、次のようになります。文書に残すのは③運用ルールと④人だけ。運用ルールは5つまでに絞ります。
層 | 設定・環境に落とすこと | ガイドライン文書に書くこと | この層が抜けると起きること |
|---|---|---|---|
①端末 | どのPC・どのフォルダで動かすか。読ませないものは読めない場所へ | ほぼゼロ(「作業は◯◯フォルダで行う」の一行のみ) | 業務データの本体がある場所でAIが直接動き、読ませたくないものにまで手が届く |
②コード設定 | 情報の3分類・権限の仕分け・危ない操作の自動停止・安全装置を勝手に緩めさせない設定 | 「設定で担保している」という事実と、設定変更の申請先だけ(設定値は転記しない) | 設定で止められることを人の記憶に預けることになる。忙しい日ほど忘れる |
③運用ルール | —(設定では表現できない判断) | 文書の本体。ただし5つまで | 判断の場面で現場が迷い、聞ける先もないまま自己判断で進む |
④人 | —(仕組みに置き換えられない) | 業務ごとの確認者・相談先・「判断と検収は人に残す」の明示 | ①〜③をどれだけ固めても、誰も最終責任を持っていない状態が生まれる |
構造
- [ ] 文書に書いてある項目のうち、設定に落とせるものが残っていないか確認したか
- [ ] 文書に残したのは、③運用ルールと④人の層だけになっているか
- [ ] 運用ルールは5つ以下に収まっているか
内容
- [ ] 「渡してよい/加工すれば渡せる/渡さない」の3分類が書いてあるか(禁止だけになっていないか)
- [ ] 困ったときの相談先が書いてあるか
- [ ] 業務ごとの確認者が決まっているか
- [ ] 安全装置の設定を現場が勝手に緩められない形になっているか
運用
- [ ] 配ったあと、現場の解釈を確認する場が設計されているか
- [ ] ルールを追加する手順と、減らす手順の両方があるか
生成AIガイドラインが読まれない5つの理由|「作っても、どうせ読まれないのでは」
生成AIガイドラインを作る側が、いちばん気にしている点だと思います。そのとおりで、たいていのガイドラインは読まれません。 ただし、読まれない理由は決まっているので、先に潰せます。
読まれない理由 | 起きていること | 潰し方 |
|---|---|---|
長い | 全部を文書に書いている | ①②を設定に落とす。文書は③④だけ |
自分に関係ないと思われる | 全社共通の一般論しか書いていない | 業務ごとの確認者を書く。自分の名前が出てくる文書は読まれる |
読む場面がない | 配布時にしか触れられない | 最初の1業務を通すときに、一緒に開いて当てはめる |
読んでも判断できない | 禁止事項しか書いていない | 「渡してよい」の範囲を書く |
古い | 設定値を転記していて更新が追いつかない | 設定の中身を文書に書かない |
いちばん効くのは3行目です。 ガイドラインは、読ませようとしても読まれません。
具体的な業務に当てるときに、自然に開かれるのが理想です。だから「配布」ではなく「最初の1業務を一緒に通す」を運用に入れます。
そしてもう一つ、身も蓋もない話をします。現場が本当に見るのは、文書ではなく「詰まったときに聞ける相手」です。 相談先が明記されていて、実際に答えが返ってくる状態があれば、文書を暗記していなくても運用は回ります。逆に相談先が無い文書は、どれだけ丁寧に書いても、迷った人を自己判断へ押し出します。
ガイドラインの完成度を上げるより、相談先を1人決めるほうが、事故は減ります。 作る側としては認めにくいところですが、実務ではそうです。
生成AIガイドラインの運用|配って終わりにせず、最初の1業務を一緒に通す
生成AIガイドラインの失敗3「作って配って終わっている」への対応を書きます。
生成AIガイドラインは、配った時点では機能していません。 現場がそれぞれの解釈で読んだ状態にすぎないからです。私たちが実務で置いているのは、この2つです。
ひとつ目は、最初の1業務を一緒に通すこと。 抽象的なルールは、具体的な業務に当てて初めて意味が確定します。「この資料は"加工すれば渡せる"に入るのか」——この判断を1回一緒にやると、以降は現場で判断できるようになります。

ふたつ目は、ルールを減らす手順を持っておくこと。 運用していると、ルールは必ず増えます。増える手順しかない組織では、1年後には誰も読まない文書になります。
「このルールは設定に落とせたので文書から消す」を定期的にやるほうが、守られる状態を保てます。
「禁止」で止めてしまう選択については、「生成AI禁止」が一番危ない理由とシャドーAI対策で詳しく書きました。ガイドラインの前提になる、Claude Code自体の安全設計はClaude Codeのセキュリティは大丈夫?事故を防ぐ設計へ。
まとめ|生成AI社内ガイドラインの作り方(4層構造と3分類)
- ガイドラインが機能しないのは書き方ではなく、「人が読んで守る文書」として作っているから
- 守る場所を①端末②コード設定③運用ルール④人の4層に振り分ける
- ①②は設定に落とす。文書に残すのは③④だけ——これでガイドラインが薄くなり、読まれるようになる
- 禁止事項ではなく「渡してよい/加工すれば渡せる/渡さない」の3分類を書く
- 運用ルールは5つまで。6つ目を足す前に、設定に落とせないかを見る
- 配ったあと、最初の1業務を一緒に通す。そしてルールを減らす手順を持つ
社内展開の進め方と、私たちが実際に使っている設計の考え方をまとめた資料を用意しています。
出典・参考
- 総務省『令和8年版 情報通信白書』(2026年7月公表)https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/summary/summary01.pdf ※「86.4%」「組織的な取組はない27.0%」は同白書による
- 商工中金「中小企業の生成AIの利用にかかる調査(2026年1月調査)」(2026年3月31日公表・n=3,892)https://www.shokochukin.co.jp/report/data/assets/pdf/futai202603.pdf ※「個人の判断に任せている64.9%」は同調査による
- Anthropic「Claude Code Overview」https://code.claude.com/docs/en/overview ※設定ファイル・権限・自動停止・箱で囲う仕組みに関する記載は同ドキュメントによる
※本記事は2026年8月26日時点の情報にもとづきます。「4層構造」は私たちの実運用にもとづく整理であり、Anthropicや公的機関が定めた枠組みではありません。具体的な設定内容(検査パターン等)は、攻撃側のヒントになるため公開していません。
この記事について
DAIJOBUは、営業・採用・バックオフィスを含む20名以上がClaude Codeを日常業務で毎日使い、業務別のエージェント30種以上を実運用している会社です。本記事のガイドラインの組み立て方は、自社で実際に運用している設計を、社外秘の部分を除いて整理したものです。
著者 | DAIJOBU株式会社 Claude Code法人研修部 コンテンツ担当 佐藤 雅俊 |
編集責任者 | DAIJOBU株式会社 Claude Code法人研修 事業責任者 石井 雄大 |
監修 | DAIJOBU株式会社 代表取締役 山中 裕貴 |
公開日 | 2026年9月3日 |
最終更新日 | 2026年9月3日 |