AIにコードを書かせると、プログラムを書けない人でも、業務に使うアプリやデータ処理の仕組みを短い時間でつくれるようになりました。便利になった一方で、AIが書いたコードや、AIにつなげた環境から、思わぬ事故が起きることがあります。
このコラムでは、AIにコードを書かせるときに起こりうる事故を9つに整理し、それぞれについて、リスクを下げる考え方を紹介します。コードを細かく読めなくても、設定と確認の仕方でリスクを下げられる範囲に絞っています。
こうした事故は、AIの性能よりも、使う人の理解や、社内の決まりごとによって起きやすさが変わります。AIを使う人が増えるほど、一部の担当者だけでなく、使う人みんなが基本を知っておけるように、社内で教育を行い、セキュリティへの理解を深めておくことが欠かせません。
なお、ここで紹介するのは「リスクを下げる」ための考え方です。どれか1つをやれば必ず防げる、というものではありません。
情報を守る：鍵と、AIに渡すもの
1. 接続情報・鍵の扱い
起こりうる事故：AIの開発ツールや外部サービスにつなぐための鍵（パスワードの代わりになる文字列）が、コードの中や、コードを保管するサービスに書きこまれてしまい、外から見える状態になります。
リスクを下げる考え方：鍵をコードに直接書かず、環境変数や、サービスが用意している秘密情報の保管機能に置きます。さらに、鍵を検知する専用のツールと、保管するサービス側の「鍵が含まれていたら記録を止める」機能を併用して、記録する前に気づけるようにします。
2. AIに渡す情報
起こりうる事故：個人情報や、まだ公開していない数値を、そのままAIに渡してしまいます。
リスクを下げる考え方：情報を「渡してよい」「確認が要る」「渡さない」の3つに分けておきます。渡す前には、個人が特定できないように、ダミーの値に置きかえます。AIに読ませるデータの表は、接続ツールの許可一覧で、読んでよいものだけに絞ります。
操作を守る：AIに任せてよい範囲
3. AIに許す操作
起こりうる事故：AIが、本番のデータを更新・削除したり、ファイルを消したりします。
リスクを下げる考え方：AIに許す操作を、「許可」「確認」「禁止」に分けて決めます。最初は、読み取り専用から始めます。AIの接続は、データを読む専用の接続ツールに限り、本番に書きこむ処理は、人が内容を読んでから実行します。
4. 手元のパソコンへの持ち出し
起こりうる事故：社内のデータ基盤にあるデータを、手元のパソコンにダウンロードしてAIに処理させると、パソコンや、AIの側にデータが残ります。
リスクを下げる考え方：データを持ち出さず、データ基盤の中で処理する形にします。どうしても持ち出すときは、ダミーの値に置きかえたうえで、保存する場所と、消し方を決めておきます。
見える人を守る：閲覧権限と公開範囲
5. データの閲覧権限
起こりうる事故：申請が必要なデータが、権限のある人がつくったアプリを経由して、ほかの人にも見えてしまいます。
リスクを下げる考え方：役割ごとに、触ってよい層を確認します。アプリは「つくった人の権限で動く」ことを前提に、見せる範囲を設計します。
6. 公開範囲
起こりうる事故：アプリや共有用のURLが、想定していない人にも見えてしまいます。
リスクを下げる考え方：公開する前に、別の役割の人として実際に開いて確かめます。公開前の確認表をつくっておくと、見落としが減ります。
部品と記録を守る：あとから困らないために
7. 部品（ライブラリ）の追加
起こりうる事故：AIが、外部の部品を勝手に足してしまい、その部品の弱点や、外部への情報の送信を持ちこむことがあります。
リスクを下げる考え方：部品の版（バージョン）を固定します。部品を足すときはレビューで止めて、どこから来た部品かを確かめます。
8. 変更の記録と復元
起こりうる事故：誰が何を変えたかを追えなくなります。壊れたときに、元の状態へ戻せません。
リスクを下げる考え方：変更を小さく区切って記録し、コードを保管するサービスに置きます。データ基盤の側に、前の状態に戻せる機能があれば、それも使います。
AIの指摘をどう扱うか
9. 自動レビューの指摘
起こりうる事故：AIが自動でコードを点検し、安全面の指摘を出してくれます。ところが、指摘の意味を理解できないまま、無視して記録してしまいます。
リスクを下げる考え方：指摘の読み方を学びます。重大度の高い指摘や、分からない指摘は、止めて聞くことにします。そして、点検の精度は、人がサンプルを選んで見直す（サンプリングレビュー）ことで確かめます。
9つのうち、最後の項目は少し性質がちがいます。ほかの8つが「AIに何を渡し、何をさせるか」の話であるのに対し、これは「AIが出した答えを、人がどう受け止めるか」の話です。AIの点検は頼りになりますが、AIの出力をそのまま信じるのではなく、人が確かめる仕組みを残しておくことが大切です。
まとめ
AIにコードを書かせるときの事故は、AIの性能の問題というより、「何を渡すか」「何をさせるか」「誰に見せるか」「あとから戻せるか」という、人の側の設計で防ぎやすさが決まります。9つの事故は、そのどれかにあてはまります。
どれも、コードの細かい中身が読めなくても、設定と確認の仕方でリスクを下げられるものです。まずは、自分たちのAIの使い方を、この9つにあてはめて点検してみてください。
「AIをどこまで使ってよいのか、社内のルールをどう決めればよいかわからない」という段階からでも大丈夫です。SecureHatters では、AIの利用を含めたセキュリティの課題の整理から、ルールづくり・運用まで、セキュリティコンサルティングでご支援します。社内で学ぶ場をつくりたい場合は、セキュリティトレーニングもご利用いただけます。お問い合わせから、お気軽にご相談ください。