その情報は、誰から届いたのか — Jアラート報道から考えるAIの発信元証明

AIが動く前に、その情報の出どころを確認できますか

例えば、取引先から届いた「振込先を変更してください」という通知を、AIが読み取り、支払い処理に反映する場面を考えてみてください。

AIが文章を正しく理解できても、その通知が本当に取引先から届いたものかは、別に確認する必要があります。さらに、その相手に振込先を変更する権限があるかも確認しなければなりません。

これは、AIに社外の情報を読ませるだけでなく、発注、支払い、顧客情報の更新といった業務まで任せるときに重要になる問いです。もっともらしい情報をそのまま実行に使えば、誤った処理につながりかねません。

Jアラートをめぐる今回の報道も、情報を受け取る側が「誰から来たものか」をどう確かめるか、という問題を扱っています。公共警報と企業のAIでは用途も仕組みも異なりますが、受け取った情報を行動の根拠にする点は共通しています。

Jアラートの報道で指摘されたこと

2026年8月30日、共同通信は、Jアラートの衛星経由データに発信元を保証する機能がなく、偽の警報を送れる可能性があると報じました。

報道によると、サイバーセキュリティ企業「アンノウン・テクノロジーズ」の切敷裕大氏が中古の受信機を分析し、電子署名のような発信元を確認する仕組みがないと指摘しています。

ここで考えたいのは、「情報が届くこと」と「正規の発信元から届いたと確認できること」の違いです。受信できる状態を整えても、届いた情報の出どころを確認できるとは限りません。

携帯電話向けの緊急警報についても、2019年に4G LTEでのなりすまし研究が発表されています。こちらは携帯電話網を対象とする研究で、Jアラートの衛星通信を検証したものではありません。異なる仕組みの事例を、同じシステムの実証結果として扱わないことが大切です。

企業のAI導入に引き寄せるなら、確認すべきことは明確です。外部から情報が届いたとき、システムは何を根拠に、その発信元を確認しているのでしょうか。

「誰が送ったか」と「内容が正しいか」を分けて考える

発信元の確認に使える技術の一つが、電子署名です。送る側がデータに署名し、受け取る側が、その相手のものとして確認しておいた検証用の鍵を使って確かめます。これにより、対応する署名用の鍵で署名されたことと、署名後に内容が変更されていないことを検証できます。

暗号化は、内容を第三者に読まれないようにするための仕組みです。電子署名は、発信元や内容の変更を確認するために使います。業務によっては両方が必要です。

ただし、電子署名で確認できる範囲には限りがあります。取引先本人が間違った口座番号を送った場合、その情報には正しい署名が付いていても、内容は誤っています。署名用の鍵が盗まれた場合にも、署名の検証だけでは正規の担当者による操作と区別できません。

AIに業務を任せるときは、次の確認を分けて設計すると、担当者と開発者の認識をそろえやすくなります。

署名の導入に加え、相手と鍵をどう結び付けるか、鍵が漏えいしたらどう無効にするか、古い通知の再送をどう見分けるかも運用として決める必要があります。

実行前の確認と、実行後の記録をつなぐ

もう一つ、AI導入担当者が考えておきたいのが、処理が終わったあとの説明です。

「なぜ、この振込先に変更されたのか」と問われたとき、受け取った通知、確認結果、承認、AIが実行した処理をたどれるでしょうか。

ログはその出発点です。さらに、保管しているログが登録時点から変更されていないかを、別途照合できるようにすると、調査や説明に使う記録を検証しやすくなります。

例えば、通知を受け取った時点の内容と確認結果を記録し、承認や実行の記録を同じ処理の番号で結び付けます。それぞれの記録が後日変更されていないかも確かめられれば、関係者は同じ記録をもとに調査を進められます。

ただし、あとから記録を検証できても、不正な処理を実行前に止められるとは限りません。実行前の確認と、実行後の検証は、それぞれに役割があります。

Lemmaで取り組む、あとから検証できる記録

LemmaのMCPツール呼び出しの監査証跡では、AIが外部のツールを呼び出した記録を登録し、あとから照合する実装例を公開しています。MCPは、AIが外部のツールやデータを利用するための接続規格です。

この例では、記録の内容から暗号技術で計算した照合用の値を登録します。あとで手元の記録から同じ計算を行い、登録済みの値と比較します。技術的には、Poseidon over BN254を用いたコミットメントを使います。コミットメントは、内容をあとから照合するための値です。計算方法やコードは、リンク先にまとめています。

この照合で確認するのは、提示された記録が登録時点の内容と一致するかどうかです。登録前から誤っていた情報の正しさや、記録に書かれた実行者の身元まで、自動で保証するものではありません。発信元を確認する署名や認証は別途必要で、照合には元の記録と再計算に必要な情報の保管も欠かせません。

AIのモデルを更新しても、過去の処理を説明する必要は残ります。どの情報を受け取り、どの確認を経て、何を実行したか。その記録を検証できる形で残すことが、継続してAIを業務に使うための土台になります。

Models change. Proofs remain.

次のAI導入で確認する5項目

まずは、外部の情報を受け取って処理を実行する業務を一つ選び、次の順番で確認してみてください。

• 情報の入口を洗い出す。メール、外部サービス、取引先システムなど、AIが判断に使う情報の出どころを整理します。
• 発信元の確認方法を決める。何を根拠に相手を確認するか、担当者や鍵が変わったときに誰が更新するかを決めます。
• 実行できる範囲を決める。情報を送る権限と、業務を実行・承認する権限を分け、金額や処理内容に応じた承認条件を設定します。
• 確認できない場合の対応を決める。処理を保留する、人に確認を回すなど、業務の影響に応じた対応を用意します。
• 記録を残し、照合を試す。受信内容、確認結果、承認、実行結果を結び付け、あとから記録の変更を検出できるかを確かめます。

AIエージェントを運用する企業、MCPやx402を使う開発者、複数の組織をまたぐ業務を自動化するチームの皆さまへ。発信元の確認と検証可能な記録を、どの業務に組み込むべきか。PoCの個別相談で、具体的な業務から一緒に検討できます。

Built for decisions that matter.

Resources

• 【独自】Jアラート「偽の警報可能」 専門家、発信元保証なし（2026年8月30日・共同通信） — 東京新聞デジタル
• 全国瞬時警報システム（Jアラート）の概要 — 総務省消防庁
• This is Your President Speaking: Spoofing Alerts in 4G LTE Networks（MobiSys '19） — ACM Digital Library