AIを業務で使うようになって、正直、手放せなくなりました。
障害の切り分け、手順書のレビュー、報告書のたたき台。明らかに仕事が楽になっています。
でも同時に、こう思うこともあります。
「これ、聞いていい内容だったかな」
正直に告白します。使い始めたころ、危ないことをしかけた経験があります。障害対応で焦っていて、ログをそのまま貼り付けようとした。ホスト名も、IPアドレスも、顧客名も入ったままのログを。
送信ボタンを押す直前で、手が止まりました。
あのとき止まらなかったら、と思うとぞっとします。
今回は、運用保守でAIを使うときの線引きについて書きます。便利だからこそ、決めておくべきことがあります。
線引きは2種類ある
まず整理しておきたいのが、**「入れてはいけない情報」と「任せてはいけない判断」**は別の話だということです。
- 情報の線引き — 何を入力するか（セキュリティの問題）
- 判断の線引き — 何を決めさせるか（責任の問題）
どちらも重要ですが、性質が違います。順に見ていきます。
入れてはいけない情報
①顧客を特定できる情報
これが最優先です。
- 顧客名、企業名
- 契約情報、金額
- 担当者の氏名、連絡先
- 顧客固有のシステム名
運用保守は、顧客の環境を預かる仕事です。 その情報が外部サービスに渡ることは、契約違反になる可能性があります。
「AIに聞いただけ」では済みません。多くの保守契約には、機密保持条項が入っています。
②環境を特定できる情報
こちらも同様に危険です。
- ホスト名、サーバー名
- IPアドレス、ドメイン名
- ネットワーク構成
- ポート番号、ファイアウォールの設定
これらは、攻撃者にとって価値のある情報です。
「うちの環境なんて誰も狙わない」と思うかもしれません。でも、情報が漏れるルートを自分から作る必要はない。
③認証情報
言うまでもありませんが、明記しておきます。
- アカウント名、パスワード
- APIキー、トークン
- 証明書、秘密鍵
- 接続文字列（パスワードを含むもの）
設定ファイルを丸ごと貼り付けると、これが紛れ込みます。 「設定ファイルの内容を確認してほしい」というときが一番危ない。
④個人情報
- 従業員の氏名、社員番号
- メールアドレス
- ログに含まれるユーザーID
ログを貼り付けるとき、ユーザーIDが個人を特定できる形式になっていないか確認が必要です。
じゃあ、どうやって聞くのか
「入れてはいけない」と言われても、実務では聞きたい。当然です。
やり方はシンプルで、置き換えてから聞くだけです。
置き換えの例
- 顧客名 → 「A社」
- ホスト名
srv-abc-prod01→ 「Webサーバー」 - IPアドレス
192.168.x.x→ 「内部セグメントのIP」 - ドメイン
example-customer.co.jp→ 「顧客ドメイン」
大事なのは、聞きたいことの本質は変わらないということです。
「srv-abc-prod01のディスクが90%です」も「Webサーバーのディスクが90%です」も、AIから得られる回答は同じ。固有名詞は、AIにとって意味を持ちません。
つまり、伏せても損しない。これが線引きを守れる理由です。
ログを貼るときは、少し手間ですが、テキストエディタで置換してから貼り付けます。この一手間を惜しまないこと。
任せてはいけない判断
ここからは、責任の話です。
情報を伏せていれば何でも聞いていいかというと、そうではありません。AIに決めさせてはいけないことがあります。
①本番環境への適用可否
AIが出したコマンドやスクリプトを、そのまま本番で実行する。これは絶対にやってはいけません。
理由は明確で、AIは「その環境」を知らないからです。
一般論として正しいコマンドでも、その環境では致命的かもしれない。依存関係、稼働状況、他システムへの影響——AIには見えていません。
内容を理解してから、自分の責任で実行する。 これが原則です。
②障害の最終原因判断
AIは、原因の候補を挙げるのは得意です。切り分けの手順を示すのも上手い。
でも、「これが原因です」と断定するのは人間の仕事です。
AIの回答は、与えられた情報の範囲での推測にすぎません。現場を見ているのは自分だけ。最終的な判断は、自分が持つ必要があります。
③顧客への回答内容
AIに作らせた文章を、そのまま顧客に送る。これも危険です。
AIは、その顧客との関係性を知りません。
過去の経緯、担当者の性格、これまでのやり取り——文面の温度感は、そこで決まります。AIが作るのは、あくまでたたき台です。
そして何より、送った文章の責任は自分にあります。 「AIが書いたので」は通用しません。
④セキュリティの最終判断
「この脆弱性、対応すべきですか」
AIに聞けば、それらしい答えは返ってきます。でも、その判断には責任が伴います。
適用しない判断をして、後で問題が起きたとき。「AIがそう言ったから」では、誰も納得しません。
判断材料としてAIを使うのはいい。でも、判断そのものは自分でする。
チームで使うなら、ルールを明文化する
個人で気をつけるだけでは、限界があります。
私のチームでは、AI利用のルールを文書化しました。内容はシンプルです。
入力してはいけない情報
- 顧客名、担当者名、契約情報
- ホスト名、IPアドレス、構成情報
- 認証情報全般
- 個人情報
必ず人が判断すること
- 本番環境への適用
- 障害の最終原因判断
- 顧客への回答内容
- セキュリティ対応の可否
明文化する理由は2つあります。
- 判断に迷わなくなる（迷うたびに考えると、いつか間違える）
- 使っていいことが明確になり、安心して使えるようになる
意外かもしれませんが、ルールを作ったほうがAIの利用は増えます。
「何をしたら怒られるかわからない」状態では、慎重な人ほど使えません。線が引かれていれば、その内側では自由に使える。
それでも迷ったときの判断基準
明文化しても、判断に迷う場面は出てきます。
そういうとき、私はこう考えています。
「この内容が外部に出ても、顧客に説明できるか」
これが一つの基準です。
説明できないなら、入力しない。単純ですが、実務では十分機能します。
もう一つは、「AIの回答が間違っていたとき、自分が責任を取れるか」。
取れないなら、それはAIに任せてはいけない判断です。
まとめ
運用保守でAIを使うときの線引きをまとめます。
入れてはいけない情報
- 顧客を特定できる情報（顧客名、契約情報、担当者名）
- 環境を特定できる情報（ホスト名、IP、構成）
- 認証情報（パスワード、APIキー、秘密鍵）
- 個人情報（氏名、メールアドレス、ユーザーID）
聞き方の工夫
- 固有名詞は汎用名に置き換える
- 伏せても、得られる回答は変わらない
任せてはいけない判断
- 本番環境への適用可否
- 障害の最終原因判断
- 顧客への回答内容
- セキュリティの最終判断
迷ったときの基準
- この内容が外部に出ても、顧客に説明できるか
- AIの回答が間違っていたとき、自分が責任を取れるか
AIは、運用保守の仕事を確実に楽にしてくれます。
でも、預かっているものの重さは変わりません。
線を引いておけば、その内側では安心して使えます。まずは自分のルールを決めるところから始めてみてください。
コメント