AIを業務で使うなら、ルールが要ります。
でも、ルール作りには落とし穴があります。
厳しくしすぎると、誰も使わなくなる。 緩すぎると、事故が起きる。
正直に告白します。私は最初、かなり厳しいルールを作ろうとしていました。
顧客環境を預かる仕事なので、情報漏洩のリスクを考えると、制限したくなる。「原則禁止、例外的に許可」という形も検討しました。
でも、それでは使われないルールになると気づきました。
今回は、実際にチームでAI利用ルールを作ったときに決めたことを書きます。
ルールを作る目的を間違えない
最初に整理したのが、何のためにルールを作るのかでした。
考えられる目的は2つあります。
1. リスクを防ぐため 2. 安心して使えるようにするため
一見同じに見えますが、作るルールがまったく違います。
リスクを防ぐことだけを考えると、禁止事項が並びます。「あれもダメ、これもダメ」。結果、何をしていいかわからなくなる。
慎重な人ほど「使わないほうが安全」と判断します。そして、使わない人が増えると、ルールを作った意味がなくなります。
私たちが目指したのは、2のほうでした。
線が引かれていれば、その内側では自由に使える。ルールは制限ではなく、許可の範囲を示すものと考えました。
決めた5つのこと
ここからが本題です。実際に決めたのは、次の5点です。
①入力してはいけない情報
一番重要で、ここだけは例外なしにしました。
- 顧客名、担当者名、契約情報
- ホスト名、IPアドレス、構成情報
- 認証情報全般（パスワード、APIキー、証明書）
- 個人情報
「迷ったら入れない」を原則にしています。
そして、代わりにどうするかもセットで示しました。
固有名詞は「A社」「Webサーバー」のように置き換える。ログを貼るときは、テキストエディタで置換してから渡す。
禁止だけでは、使い方がわかりません。 「こう置き換えれば使える」まで書くことで、実際に使えるルールになります。
この線引きについては、別記事に詳しくまとめています。
②必ず人が判断すること
情報の入力とは別に、判断の線引きも決めました。
- 本番環境への適用可否
- 障害の最終原因判断
- 顧客への回答内容
- セキュリティ対応の可否
AIは判断材料を出す道具であって、判断する主体ではない。
ここを明確にしておかないと、「AIがそう言ったので」という説明が出てきます。それは顧客にも社内にも通用しません。
③使っていい業務を、具体的に挙げる
禁止事項だけでなく、推奨される使い方も書きました。
- 手順書のたたき台作成
- 文書のレビュー、わかりやすさの確認
- 障害調査の切り分け相談
- コマンドやスクリプトの意味確認
- 報告書の文面整理
「これは使っていい」が明示されていると、動きやすくなります。
特に経験の浅いメンバーは、「使っていいのか」を気にします。具体例があると、迷わず試せます。
④生成物の扱い方
AIが出したものを、どう扱うか。ここも決めました。
- コマンド・スクリプトは、必ず内容を理解してから実行する
- 検証環境で確認してから本番に適用する
- 文書は、必ず自分の言葉に直す
- 出典や根拠が必要な内容は、裏を取る
「AIが書いたから正しい」ではない。 これを明文化しておくことが重要です。
特にコードについては、AIが書いたコードの不備で情報漏洩が起きた事例も報告されています。検証を省略しないことが前提です。
⑤困ったときの相談先
意外と忘れられがちですが、これも入れました。
「判断に迷ったら、使う前に相談する」
そして、相談先を明記します。私のチームでは、私か副リーダーとしました。
ルールは全パターンを網羅できません。 必ず「これはどっちだろう」という場面が出ます。
そのとき迷ったまま使われるのが一番危ないので、聞ける先を決めておきます。
ルールを作るときに気をつけたこと
5つの内容とは別に、作り方そのもので意識したことがあります。
①1枚に収める
長いルールは読まれません。
A4で1枚。 これを守りました。細かい補足は別紙にして、本体は簡潔にしています。
②禁止と推奨を、同じ分量で書く
禁止事項ばかりが並ぶと、「使うな」というメッセージに見えます。
使っていいことも、同じくらいの分量で書く。 これだけで受け取り方が変わります。
③リーダーが「使っていい」と明言する
文書だけでは足りません。
口頭でも伝えました。 「効率化のために使うのは推奨している」「AIを使ったことで評価が下がることはない」。
実はこれが一番効いたかもしれません。
慎重な人は「使ったら怒られるのでは」と考えます。上が明言することで、その心配がなくなります。
④運用しながら直す
最初から完璧なルールは作れません。
実際に使っていると、「このケースはどうなるのか」が出てきます。そのたびに追記していく。
ルールは育てるものだと考えています。
作ってみて、どうなったか
正直に書きます。
全員が使うようになったわけではありません。
半分強、というところです。使う人は日常的に使い、使わない人はほとんど使わない。
でも、それでいいと思っています。
ルールを作った目的は「全員に使わせること」ではなく、「使いたい人が、安心して使えるようにすること」でした。その点では、機能しています。
そして、予想外の効果もありました。
「このケースはどうですか」という相談が来るようになったことです。
ルールがないときは、各自が自己判断で使っていました。グレーゾーンも、黙って使うか、黙って使わないか。
ルールができてから、判断に迷ったときに聞いてくれるようになりました。 これは安全性の面で大きい変化です。
ルールがないとどうなるか
逆の話もしておきます。
ルールがない状態は、「各自の判断に任せる」ということです。
一見自由に見えますが、実際には次のどちらかになります。
1. 慎重な人は使わない
リスクを恐れて、便利なものを使えない。効率化の機会を失います。
2. 無頓着な人は、何でも入れる
顧客情報も認証情報も、気にせず入力する。事故が起きるのは、たいていこちらです。
ルールは、この両極端を防ぐためにあります。
まとめ
社内でAI利用ルールを作るとき決めたことをまとめます。
ルールの目的
リスクを防ぐためだけでなく、安心して使えるようにするため
決めた5つのこと
- 入力してはいけない情報 — 置き換え方もセットで示す
- 必ず人が判断すること — 本番適用、原因判断、顧客回答、セキュリティ
- 使っていい業務を具体的に挙げる — 禁止だけでは動けない
- 生成物の扱い方 — 理解してから使う、検証してから適用する
- 困ったときの相談先 — 迷ったまま使われるのが一番危ない
作り方で気をつけたこと
- 1枚に収める
- 禁止と推奨を、同じ分量で書く
- リーダーが「使っていい」と明言する
- 運用しながら直す
作ってみて
- 全員が使うようにはならなかった（半分強）
- でも「このケースはどうですか」という相談が来るようになった
AIのルール作りは、制限ではなく線引きだと思っています。
線が引かれていれば、その内側では安心して使える。逆に線がないと、慎重な人ほど動けません。
もし今、チームでAIを使うかどうか迷っている段階なら——まず線を引くところから始めてみてください。
禁止より先に、「ここまでは使っていい」を決める。そのほうが、結果的にうまくいきます。
コメント