ドローンの情報は、着陸後にどこへ行くのか―生成AI時代の情報漏洩を考える
機体の通信を厳しく管理していても、撮影した画像を担当者が生成AIへアップロードすれば、そのデータは別の情報システムへ渡る。ドローンの情報セキュリティを考える範囲は、飛行中から、着陸後の解析や報告書作成まで広がっている。
点検画像から異常の候補を整理する。過去の写真と比較して工事の進捗を説明する。飛行記録と作業メモから報告書の下書きを作る。生成AIは、ドローンで取得した情報を業務の成果へ変える工程で、有力な道具になりつつある。
しかし、便利になるほど、これまで分かれていた情報が一か所に集まる。写真、位置情報、設備名、点検結果、顧客とのやり取り。それらを横断的に扱うAIには、何を見せ、どこまで操作させるべきなのか。
最近の情報漏洩を巡る問題は、ドローン業界にもこの問いを突きつけている。
最近のAIセキュリティ問題が示したこと
2026年6月、セキュリティ企業Varonisは、Microsoft 365 Copilot Enterprise Searchに関する脆弱性の連鎖「SearchLeak」を公表した。
同社の検証では、細工されたリンクをクリックすることをきっかけに、利用者がアクセスできるメールや組織内のファイルなどを、外部へ流出させられる可能性が示された。Varonisによれば、この問題はMicrosoftによって修正されている。これは研究者による脆弱性の実証であり、ドローン企業で実際に情報漏洩が起きたという報告ではない。
それでも、ドローン業界が学ぶべき点は明確だ。
AIに社内情報を検索させ、外部の情報も読ませ、さらに別のサービスと連携させる。その利便性を支える接続が、情報流出の経路にもなり得る。
問題は「AIが秘密を学習するか」だけではない。AIがいまアクセスできる情報を、どこへ出力し、誰に渡せるのかも重要になっている。
情報漏洩には、違う種類の問題がある
生成AIと情報漏洩の議論では、異なる問題が一緒に語られやすい。
一つは、担当者が未承認のAIサービスへ業務データを入力することだ。悪意がなくても、会社や顧客が認めていない送信先へ情報を渡せば、管理上の問題になる。ただし、外部サービスへの入力が、直ちに一般公開や第三者への漏洩を意味するわけではない。契約と設定、扱う情報によって評価は変わる。
二つ目は、社内の共有範囲が広すぎることだ。以前から閲覧できる状態だった資料を、AIが検索・要約することで、容易に見つけられるようになる。Microsoftも、生成AIが既存の過剰共有や情報漏洩のリスクを増幅し得ると説明している。
三つ目は、AIが読む外部コンテンツに不正な指示が混ざり、その後の処理を誘導される問題だ。いわゆるプロンプトインジェクションである。AIに検索やファイル操作、送信などの権限を与えるほど、影響を考える範囲も広くなる。
対策はそれぞれ違う。「機密情報を入力しないよう注意する」だけで、すべてを解決することはできない。
ドローン画像は、見た目以上の情報を持っている
例えば、工場の屋根を撮影した画像を生成AIに渡し、点検報告書を作る場面を考えてみよう。
画像には、屋根の損傷だけでなく、隣接設備、搬入口、資材置き場などが写り込んでいるかもしれない。位置や撮影日時が付いていれば、どの施設をいつ調べたかも分かる。そこに設備名や点検履歴を添付すれば、単なる空撮写真が、施設の状態を説明する資料になる。
工事現場でも同じだ。工程表と定点画像を組み合わせれば、進捗の把握に役立つ。その一方で、外部に出していない作業状況や設備配置を推測する材料にもなり得る。
ここで述べているのは想定例であり、特定のドローンサービスで確認された事故ではない。
ただ、生成AIを使う価値が「複数の情報を結びつけること」にある以上、結びつけた後の情報の機微性も評価しなければならない。
写真一枚では問題がなくても、位置、時刻、設備名、過去の記録がそろえば、守るべき情報に変わる。
「学習に使われない」だけでは、判断できない
AIサービスを選ぶとき、「入力データを学習に使わないか」は大切な確認項目だ。しかし、それだけでは十分ではない。
学習への利用と、処理のための送信、会話履歴の保存、管理者や委託先のアクセス、外部ツールへの転送は、別の問題である。
学習に使わない契約でも、保存期間や削除条件を確認する必要がある。別の解析サービスへデータを渡す機能を使うなら、その送信先も評価の対象になる。
個人情報保護委員会は2023年の注意喚起で、生成AIサービスの利用規約やプライバシーポリシーを確認し、入力する情報を踏まえて利用を判断するよう求めている。最近登場した論点ではないが、画像やファイルをまとめて扱う利用が広がるほど、この確認の意味は大きくなる。
個人向けと法人向け、通常のチャットと外部連携機能でも条件は異なる。同じサービス名だから同じ扱いだと考えず、実際に使う契約と機能を確認することが必要だ。
国産かDJIかという比較は、全体の一部分になる
ドローンの情報管理では、国産機とDJIなどの海外製品を比較する議論が続いてきた。製造元、供給網、通信先、保守体制を確認することには意味がある。
ただし、生成AIを組み込む業務では、機体選びだけで情報管理は完結しない。
国産機で取得した画像でも、未承認のAIサービスへ送信すれば、その先の取り扱いを管理する必要がある。海外製の機体でも、製品の仕様と通信設定を検証したうえで、取得後のデータを限定した環境で処理する構成は考えられる。もちろん、案件に調達・利用の制限がある場合は、それを満たすことが前提だ。
経済産業省のドローン向けサイバーセキュリティガイドラインも、機体、地上制御局、運用クラウド、サービス運用クラウドを含むシステムとして整理している。
生成AIの普及によって、この先に「AIによる解析と業務処理」という確認対象が加わったと捉えるべきだろう。
「報告書を作るAI」と「送信するAI」は分けて考える
AIが報告書の下書きを作るだけなら、人が内容と共有先を確認する工程を設けられる。
しかし、共有フォルダを検索し、画像を選び、報告書を作り、顧客へ送るところまで任せれば、AIが扱う権限は大きくなる。便利さと同時に、誤って別案件の資料を参照したり、不要な情報を添付したりする場合の影響も増える。
そこで重要なのは、AIに必要な範囲だけを見せることだ。案件ごとにデータを分け、解析に不要な個人情報や位置情報を除き、外部への送信先を限定する。機微な資料の送信には、人による確認を残す。
OWASPも、AIエージェントの対策として、権限の最小化や重要な操作での人の確認などを挙げている。
「AIに気をつけるよう指示した」ことを、アクセス制御や送信制限の代わりにしてはいけない。
ドローン企業が売るべきものは、安心して使える成果物だ
ここからはDIIJとしての見方である。
ドローン企業の競争力は、撮影できることから、取得した情報を顧客の判断に使える形へ変えることに移っていく。生成AIは、その工程を速くする可能性がある。
だからこそ、情報管理を飛行の付属作業として扱うべきではない。
顧客が知りたいのは、どの機体を使ったかだけではなく、撮影したデータをどのサービスへ渡し、誰が閲覧でき、いつ削除するのかということだ。再委託先が使うAIまで含めて説明できれば、それは受注時の信頼にもつながる。
確認すべき項目は、少なくとも次の五つになる。
AIへ渡してよいデータの範囲
利用するサービスと契約上の取り扱い
案件ごとの閲覧権限と外部連携先
報告書・添付ファイルの送信前確認
保存期間、削除方法、操作記録
生成AIを使わないことが、必ずしも最善の対策とは限らない。承認された使い方を用意しなければ、現場が個人の判断で便利なサービスを使う余地が残る。
効率化と情報管理を一緒に設計することが、現実的な導入につながる。
ドローンが安全に帰還しても、情報の仕事は終わらない。着陸後、そのデータを誰が読み、AIが何と結びつけ、どこへ届けるのか。生成AI時代のドローン産業は、そこまで含めて信頼を問われる。
※2026年10月7日時点の公開資料に基づく。紹介した脆弱性の実証と、ドローン業務への想定上の影響を区別して記載した。
コメント