「生成AIの利用規程を作ってほしい」という相談を情シスや法務から受けたとき、テンプレートを探して項目を埋めるだけでは終わらない。テンプレート自体は無料で複数公開されているが、どの項目を厳格に運用し、どの項目を技術的な設定で強制し、どの項目を「守ってもらうしかない」お願いとして残すかは、テンプレートには書かれていない。この線引きを決めずに規程だけ作ると、「規程はあるが誰も読んでいない」状態になる。
まず切り分ける：規程に書くことと、設定で強制できることは別
以前の記事で、Claude Codeの権限設計は「決める」と「強制する」が別レイヤーになっていることを整理した。利用規程を作るときも同じ切り分けが要る。
規程に「顧客の非公開情報をAIに入力しない」と書いても、実際に入力できてしまうなら規程は紙の上の約束で終わる。一方で、Claude Codeの公式ドキュメントは、組織側が管理設定（managed settings）で許可ルールを配布し、開発者が書き換えられない形で強制できること、/permissionsでの定期監査、ConfigChangeフックによる設定変更の検知、OpenTelemetryによる利用状況の監視までを「チーム向けのセキュリティ対策」として挙げている。つまりツール側には、規程の一部を強制に変換する手段がすでに用意されている。
規程を作る作業は、実質的には「この項目は技術で縛れるか、縛れないなら誰がどう運用でカバーするか」を項目ごとに決める作業になる。
チェックリスト:規程に入れるべき7項目
| 項目 | 規程に書くべきこと | 技術で担保できる範囲 |
|---|---|---|
| ①対象範囲 | 誰が・どのツールを・どの業務範囲で使ってよいか | 座席管理・SSO・ロールベースの権限で利用者を絞れる |
| ②入力禁止情報 | 顧客の非公開情報・個人情報・未公開の経営情報など、入力してはいけない情報の種類 | 完全な自動検知は難しい。フィルタや教育での運用が中心になる |
| ③出力の検証責任 | AIの出力は人がレビューしてから使う、著作権・虚偽情報のリスクを最終的に負うのは人であることの明記 | Claude Codeなら差分の承認プロンプトである程度は担保できるが、内容の正しさの判定は人の仕事 |
| ④委託先データの扱い | 受託開発で顧客のコードを扱う場合、契約・顧客合意の範囲を超えてAIに入力しない | 個別リポジトリ単位の権限設定・作業ディレクトリの制限で一部担保できる |
| ⑤承認・記録フロー | 新しいAIツール・MCPサーバー・スキルを導入する際の承認者と手順 | 管理設定でMCPサーバーの許可リストを組織側が固定できる |
| ⑥インシデント対応 | 誤って機密情報を入力した場合・AIの出力が事故につながった場合の報告先と手順 | ログ・監査証跡を残す設定は可能。判断と報告は人の運用 |
| ⑦見直し頻度 | 半年〜1年ごと、または重大なインシデント・ツールの仕様変更時に規程を見直す | 見直しの実施自体は技術で代替できない |
この並びで見ると、②③⑦は「人に守ってもらうしかない」項目、①④⑤は「規程で決めて、技術で仕上げる」項目という性格の違いがはっきりする。規程を作るときにこの区別をしておかないと、②のような守れない項目にも実現不可能な厳格さを求めてしまい、結局形骸化する。
詰まりやすい箇所
「禁止」だけで終わらせる。 「機密情報を入力しない」という一文だけでは、何が機密情報にあたるか現場が判断できない。受託開発なら「顧客との契約で非開示と定めた情報」、事業会社なら「未公開の決算・人事情報」など、自社の業務に即した例を添える必要がある。
技術的な強制と混同する。 「Claude Codeの設定で制限しているから規程は簡易でよい」という判断は、設定を変更できる権限を持つ開発者がいる限り成り立たない。公式ドキュメントによると、管理コンソール経由でまとめて配布する方式はTeam・Enterpriseプランが前提だが、各端末に設定ファイルを配置する方式はプランを問わず使える。ただしその場合は、端末ごとに配布・維持する運用の手間が組織側に残る。技術で縛れる範囲は選ぶ配布方式によって変わるので、「うちのプランでは強制できない」で終わらせず、規程側の運用（教育・定期確認）でどこを埋めるかを先に決めておく。
公的なガイドラインを丸写しにする。 経済産業省・総務省の「AI事業者ガイドライン」や日本ディープラーニング協会(JDLA)の「生成AIの利用ガイドライン」は、自社の業務実態に合わせて追記・修正することを前提にしたひな形として公開されている。汎用的な記述をそのまま社内文書として配るだけでは、現場は自分ごととして読まない。
このプロジェクト自身の「利用規程」
このブログ自体を運用しているプロジェクトのCLAUDE.mdには、AIエージェント（Claude Code）に対する厳守事項が明文化されている。たとえば「助成金・補助金の数値は断定しない」「触ってよい範囲はプロジェクト配下のみ」「デプロイコマンドは絶対に実行しない」「助成金を主題にした記事は事実確認で問題がなくてもマージせずレビュー待ちで残す」といった項目だ。
これらは上のチェックリストに当てはめると、「触ってよい範囲はプロジェクト配下のみ」が①対象範囲（作業ディレクトリの限定という形で一部は技術的にも担保できる）、「助成金の数値は断定しない」が③出力の検証責任、「助成金主題の記事はレビュー待ちで残す」が⑤承認・記録フローにあたる。とくに③は自動検知できる項目ではないので、「見つかったら断定表現を修正してからでないとマージしない」という運用の手順そのものを規程化してある。実際、この記事も「助成金を主題にした記事ではない」という判定を通ったからこそ、事実確認さえ済めば自動でマージされる経路に乗っている。規程は作って終わりではなく、日々の運用の中でどこまで効いているかを確認できるものにしておく必要がある。
自社のAI利用規程をどこまで技術で強制し、どこを運用でカバーすべきか整理したい場合は、パイロット・構築のフェーズで一緒に設計できる。まずは30分の無料診断から相談してほしい。