AI時代のセキュリティ対策｜非エンジニアのAIコーディングは業務で使える？

「AIで業務ツールを作れた。でも、これを会社で使って大丈夫だろうか」

画面が動き、欲しかった機能も使える。便利さを感じる一方で、情報漏洩やデータの消失が気になる。そんな不安はありませんか。

非エンジニアでも、AIコーディングを業務に生かすことはできます。ただし、処理や権限を確かめる人がおらず、問題が起きても止められない状態で実データを扱うのは危険です。

この記事では、見落としやすい五つのリスクと、業務利用の前に整えたい対策を整理します。自社で試せる範囲、技術面の確認を依頼する相手、利用開始の判断に必要な条件が分かります。

業務利用の判断基準

AIコーディングは、言葉で指示を出し、AIにコードの作成や修正を支援してもらう開発方法です。ツールによっては、ファイルの変更やプログラムの実行まで任せられます。

危険性を判断するときは、作る人の肩書だけでなく、次の三つを見ます。

• 扱う情報は、架空のデータか、社員・顧客の情報や会社の機密情報か。
• 与える権限は、読み取るだけか、書き換え・削除・送信までできるか。
• 利用・公開の範囲は、検証用の環境だけか、社内共有やインターネット公開を伴うか。

架空の備品リストで貸出画面を試す場合と、社員情報に接続して貸出履歴を更新する場合では、同じ見た目のツールでも影響が違います。

英国の国家サイバーセキュリティセンター（NCSC）も、試作品と、認証や機密情報を扱うシステムでは、必要な監督・検証の水準が異なると説明しています[1]。その考え方を踏まえ、本記事では中小企業での判断例を次のように整理します。

利用の例	進め方の目安
架空データで備品貸出の画面を試作する	会社が認めた検証環境で試す。本番データや不要な外部接続の権限を渡さない
社員が使い、実際の貸出情報を記録する	技術面の確認、利用者ごとの権限設定、停止・復旧の準備を終えてから限定運用する
顧客向けに公開する、支払いや重要なデータ更新を行う	設計段階から経験のあるエンジニアやセキュリティの専門家を交え、影響に応じた検証を行う

社内だけの利用でも、閲覧を認めていない社員情報が見えたり、元データを一括削除できたりすれば、影響は小さくありません。この表は、公的な安全認定の区分ではなく、利用条件を考えるための例です。

技術面を確かめる人や管理体制を用意できないなら、業務導入はいったん見送りましょう。架空データで学ぶ、管理できる既製品を選ぶ、外部の専門家と組む、といった進め方があります。

見落としやすい五つのリスク

1. 開発中と完成後の情報漏洩

情報の流れは、二つに分けて確認します。

一つは、開発中にAIへ渡す情報です。指示文に貼った表のほか、AIが読み取るファイルやエラーの記録にも、個人情報や認証情報が入っていることがあります。AIエージェントのセキュリティ資料でも、処理に取り込む情報やログから機密情報が漏れるリスクが挙げられています[2]。

もう一つは、完成したツールが扱う情報です。ツールが情報をどこへ保存し、何を外部へ送るのか、その情報を誰が閲覧できるのかを確かめます。開発に使うAIのデータ取扱条件を確認していても、完成したツールの情報の流れは別に確かめる必要があります。

会社が利用を認めたAIで作ったことだけでは、出来上がったツールを業務で使ってよいとは判断できません。

2. ログインの裏に残る権限不備

「ログインできるようにしたから、安全なはず」

ここは、立ち止まって確認したいところです。

本人かどうかを確かめる「認証」と、その人に何を見せ、何をさせるかを決める「認可」は、別の仕組みです。ログインした社員が、本来は閲覧を許可されていない申請や管理者向け情報まで見られるなら、権限の設定に問題があります。

たとえば、備品貸出ツールを「一般社員は自分の申請だけを見られる」「備品管理者は全員の申請を確認し、貸出状況を変更できる」という設計にしたとします。この設計なら、一般社員がほかの社員の申請を閲覧できてしまわないかを確かめます。

画面のボタンを隠しても、裏側の処理が操作を受け付けてしまう場合があります。画面側の制限だけに頼らず、サーバー側などで、アクセスのたびに権限を確認するようにするなど、誰が何をしてよいかを先に決め、その条件が画面と裏側の処理の両方で守られるかを確認しましょう。

3. APIキーの流出と過大な権限

外部サービスとデータをやり取りする窓口を、APIと呼びます。接続時に使うAPIキーなどの認証情報は、サービスを利用するための鍵です。

その鍵をコードや共有ファイルへ直接書くと、配布・共有の際に流出するおそれがあります。読み取りだけで済む処理に、削除や管理者操作までできる鍵を渡していれば、流出や誤操作の影響も広がります。

認証情報は会社が管理する保管先で扱い、その認証情報で使える権限を用途に必要な範囲へ絞ります。「最小限の権限」と呼ばれる考え方です。

試作のために、普段使う管理者アカウントの鍵を渡していないでしょうか。接続しやすさだけで権限を広げると、確認していない範囲まで操作できる状態になります。

4. AIエージェントの誤操作と外部からの誘導

コードの案を表示するAIに加え、ファイルの変更や命令の実行まで行うAIもあります。ここでは、こうした操作を進めるAIを「AIエージェント」と呼びます。

操作を任せる場合は、完成品を使う前の開発中にも、元ファイルの書き換えや、意図しない外部送信に備える必要があります。また、AIが読むWebページや資料に悪意ある指示が紛れ込み、行動を誘導される攻撃もあります。これは「プロンプトインジェクション」と呼ばれます[2]。

「この資料を参考にして」と渡した資料に、別の場所へ情報を送るよう仕向ける文があったらどうでしょう。AIが、資料の内容と実行すべき命令を取り違える可能性があります。

なお、AIでコードを作ったツールが、稼働中にもAIを呼び出すとは限りません。完成後もAIに外部の資料を読ませ、操作を任せる構成なら、ツールの運用中も同じ種類の攻撃に備えます。

5. 外部の部品と運用中の脆弱性

プログラムには、ほかの開発者が作った「ライブラリ」という部品を組み込むことがあります。自分たちのコードに問題がなくても、使っている部品の弱点が影響する場合があります。

使っている部品とバージョンを把握し、既知の脆弱性を調べ、修正版への更新を検討する必要があります。更新時は、検証環境で動作を確かめてから反映します[5]。

AIから提案された部品も、提供元や利用条件を確認する対象です。インストールする命令の意味が分からなければ、実行前に相談してください。

作った日に動いたことと、使い続けられることの間には、更新と保守の仕事があります。

業務利用前の四つの対策

1. データと操作範囲の制限

試作には架空データを使います。試作する環境は、実際の業務で使う本番環境から分離します。ファイル名やフォルダ名を分けても、開発中のAIやプログラムが本番データへ自由に触れられるなら、分離は不十分です。

検証用アカウントでは本番の保存先を開けないようにし、読み取りだけでよい処理には書き込み権限を渡しません。通信先も必要な相手へ限定します。これらの制限を、実行環境と接続先の設定へ反映します。

「危険な操作は禁止」とAIに伝えることに加え、できる操作そのものを絞りましょう。データの削除、新しい送信先への送信、本番への反映など、影響が大きい操作は、人が対象と内容を確かめてから進められる仕組みにします[2]。

AIへ渡す情報についても、契約と設定を確認します。学習への利用だけでなく、データの保存、アクセスできる人、接続先が自社の情報管理に合うかを見ます。「学習に使われない」という条件だけでは、確認は終わりません。

2. AIと人による確認

「作ったAIにチェックさせたら、問題なしと言われた」

その結果は確認材料にできますが、AIが問題を見逃す可能性があります。別のAIでもう一度調べても、安全性が保証されるわけではありません。GitHubも、Copilotによるコードレビューを、人による慎重なレビューで補う必要があると説明しています[6]。

実務では、AIによる指摘、既知の脆弱性や認証情報の混入を調べる自動検査、動作テスト、人によるレビューを組み合わせます。

そのとき、「技術面を確認する人」が誰なのかを具体的に決めておきます。少なくとも、次のことを確認・説明できる人が必要です。

• コードと変更差分を読み、情報の保存先・送信先と必要な権限を確かめる。
• 許可されていない操作や異常時の動作について、確認方法を設計する。
• 更新の影響と、利用を止める方法、データを復旧する手順を確かめる。

業務担当者は、目的、正しい結果、例外、許可する操作を伝えます。業務担当者には、基本の処理や情報の流れを理解し、分からない操作では止まって相談することも必要です。技術面の担当者は、コードや設定がその条件を満たすかを確認します。

利用の範囲を承認する社内責任者も決めましょう。小規模な組織では兼任も考えられますが、必要な知識と確認に使う時間を確保することが前提です。

3. 「できてはいけないこと」のテスト

備品貸出ツールなら、「申請できた」「一覧が表示された」だけで確認を終えないようにします。前述の「一般社員は自分の申請だけを見られる」という設計なら、次のようなテストを用意できます。

以下は検証用のデータとアカウントで行う設計例です。実施済みの検証結果ではありません。

確認する場面	合格とする動作の例
ログインせずに申請データを開こうとする	閲覧を拒否し、申請内容を返さない
一般社員がほかの社員の申請を開こうとする	申請内容を表示せず、変更も受け付けない
管理権限を外した人が管理操作を行う	以前の利用画面が残っていても操作を拒否する
必須項目を空欄にして申請する	申請を保存せず、不足する項目を示す
保存中に通信が途切れ、保存の完了を確認できない	受付完了と表示せず、登録の有無を記録から確認できる
同じ申請を二重に送信する	同じ申請が重複登録されない
エラーの記録を確認する	APIキーなどの秘密情報や、不要な個人情報が出ていない

通信が途切れた場合の表示と、再送した場合の処理は、併せて確認します。一部のデータだけが更新された場合に、誰がどう調べて復旧するかも決めておきます。

業務担当者が正しい結果を示し、技術面の担当者が画面を経由しないアクセスも含めて検証します。外部公開や決済、重要な情報の更新を伴う場合は、この表に加え、システム全体の構成に応じた確認が必要です。

4. 更新・停止・復旧の担当と手順

ツールを使い始める前に、会社として次の内容を把握します。

• ツールを使う目的と利用者
• 扱うデータと、その保存先・接続先
• コードと設定の管理場所
• 更新・停止・復旧の担当

使うアカウントや契約も、異動・退職時に引き継げるようにしておきましょう。

「作った本人しか分からない」という状態では、必要なときに対応が止まってしまいます。

コードを前のバージョンへ戻す手順と、書き換えられた業務データを復旧する手順は、それぞれ準備します。バックアップを取るだけでなく、検証環境で復元できるかも確かめてください。

全社の利用方針や責任分担は、生成AI社内ガイドラインの作り方でも整理しています。

備品貸出ツールの試作と利用条件

ここまでの対策を、一つの業務に当てはめてみましょう。以下は説明用の想定例です。

試作では業務の流れを確認します。 架空の社員名と備品名を使い、申請画面と検証用の保存先だけを用意します。本番の名簿やメール送信には接続せず、必要な項目と使い勝手を確かめます。

実データの利用前に社内責任者の承認を得ます。 必要なレビューとテストを終え、利用開始を妨げる未解決の問題がないことを確認します。そのうえで、対象データ、利用者、期間、権限、運用担当について社内責任者の承認を得てから、限定運用へ進みます。従来の受付方法へ戻す手順も共有します。

機能を増やすときは影響を確かめ直します。 通知メールや別のシステムとの連携を追加すれば、送信する情報や必要な権限も変わります。最初の承認を、そのまま追加機能の利用許可にしないことが大切です。

社員が身につけたい確認・相談の力は、生成AIリテラシーの記事も参考にしてください。

異常時の停止・報告

知らない送信先が見つかったり、見られないはずの情報が表示されたりしたときは、ツールを繰り返し動かすのをやめ、担当者へ連絡し、問題のあるツールや連携を止めます。

APIキーなどの流出が疑われる場合は、管理担当者が鍵を無効化し、必要に応じて新しい鍵へ切り替えます。コードから鍵の文字を消すだけでは、すでに渡った鍵の利用を止められません（出典4）。

発見時刻、行った操作、関係するデータ、画面やログを会社の決めた場所へ残し、影響を調べる担当者へ引き継ぎます。ログを消したり、流出したかもしれないデータを別のAIへ丸ごと送って調べたりすることは避けましょう。

初動対応や社内報告の詳しい進め方を確認するときは、AIで情報漏洩が起きたときの対応をご活用ください。

作る力と管理する力の育成

AIコーディングは、現場の「ここが不便だ」を、小さな仕組みに変える選択肢です。非エンジニアの業務知識も、必要な機能や例外を見つけるうえで役立ちます。

その力を業務改善につなげるために、扱う情報と権限を把握し、技術面を確かめ、問題があれば止められる状態を用意しましょう。

次の打ち合わせでは、試したいツールを一つ選び、技術面を確認する人と利用を承認する人を決めてみてください。判断に必要な情報が足りなければ、実データを使う前に、その不足を埋めるところから始めます。

ミチガエルでは、非エンジニア中心の組織が、自社の業務に合わせてAIを学び、活用を進めるための支援を行っています。

社内で担う範囲や学習の進め方を整理したい場合は、ご相談ください。支援の選び方に迷う場合は、AI導入の伴走支援の記事でも解説していますので、ぜひご一読ください。