サプライチェーン攻撃はAI導入にも及ぶ｜調達の経路を点検する

「取引先から、うちの体制について答えてほしいという確認票が届きました」「社内でAIの道具を入れ始めたのですが、どこまで安全かを誰も確かめていません」——この2つは、別々の相談として、ほぼ同じ時期に届きます。片方は外から確認される話、もう片方は自分で確かめる話ですが、扱っている中身は同じものです。サプライチェーン攻撃は、取引先が悪いという話ではありません。本当は、自社に入ってくるものの経路が増えたのに、その一覧を誰も持っていないという話です。この記事では、AIを入れることで増える4つの入口を書き出したうえで、入れる前の確認、入れた後の棚卸し、事故が起きたときの連絡という3つの段階に分けて、点検を運用に載せる手順を整理します。

「うちは直接狙われるほど大きくない」が通じなくなった理由

この言い分は、いまも現場でよく聞きます。自社の規模なら標的になるはずがない、という感覚です。ただ、この前提は「攻撃する側が、狙う相手を先に選んでいる」という想定に立っています。実際に増えているのは、相手を先に選ばず、多くの組織が共通して受け入れているものの側に細工をして、受け入れた先へまとめて届く形です。この形では、規模の大小は選別の条件になりません。

公的な整理でも位置づけははっきりしています。情報処理推進機構が2026年1月29日に公表した「情報セキュリティ10大脅威 2026」では、組織向けの2位が「サプライチェーンや委託先を狙った攻撃」でした。2019年に初めて選ばれてから8年連続での選出です。このランキングは、前年に起きた事案をもとに、研究者や企業の実務担当者およそ250名の選考会が審議して決めています。一過性の流行ではなく、8年居座り続けている型だという点が要点です。

同じ表で、3位に初めて「AIの利用をめぐるサイバーリスク」が入りました。4位は「システムの脆弱性を悪用した攻撃」です。この3つは別々の脅威に見えますが、実務では1本につながります。AIを入れるほど外から取り込むものが増え、取り込んだものに穴があれば、それが経路になる。順位を3つ別々の課題として読むと、担当も対策もばらばらになります。

サプライチェーン攻撃とは何か。狙われるのは自社ではなく、自社に入ってくるもの

言葉の定義から確認します。サプライチェーン攻撃とは、自社の防御を正面から破るのではなく、自社が信頼して受け入れているものの側に細工をして、その受け入れに乗って入ってくる攻撃のことです。業界団体の技術資料でも、ソフトウェアの製造や提供の工程を侵害し、本体や更新の仕組みに不正なコードを混ぜて標的組織へ入る形が、その中心として整理されています。

この攻撃が厄介なのは、受け入れる側の動作がすべて正常に見えることです。更新は正しい手順で配られ、部品は正規の配布元から届き、委託先は契約どおりに作業している。異常な通信や不審な添付ファイルという、分かりやすい合図が出ません。怪しいものを見分けて止める、という考え方の対策が効きにくいのは、この性質のためです。

裏返すと、効く対策の方向も決まります。何を受け入れているかの一覧と、受け入れるときの条件。この2つに絞られます。守りを厚くする話ではなく、通り道を数える話だと捉え直すと、情報システム部門だけでなく、道具を選んで使っている各部門の仕事に落ちてきます。備えの第一歩は、外から何が入ってきているかを書き出すことです。

公的な注意喚起での位置づけと、そこに書かれていない実務の負担

先ほどの10大脅威をもう少し丁寧に見ます。1位は「ランサム攻撃による被害」で11年連続、2位が今回の主題で8年連続、4位の「システムの脆弱性を悪用した攻撃」は6年連続9回目でした。上位の顔ぶれがほとんど動いていないことは、対策の目新しさより同じことを続けられているかどうかが分かれ目になっていることを示しています。

2位に対して挙げられている対策の方向は、大きく3つです。取引網全体の対策状況を把握すること、系列企業や取引先に改善を求めること、外から見えている自社の入口を継続して洗い出す取り組みを広げること。ただし前の2つは、実務では「相手を評価する作業」として読まれがちです。評価票を送っても、自社に入ってくるものの数は1つも減りません。

解説で触れられている2025年の状況にも、見落としやすい点があります。委託先で事故が起き、委託元である企業が説明や対応に追われる例が散見された、という整理です。ここが実務では重い。契約上の責任が相手側にあっても、自社の顧客に説明するのは自社です。責任の所在と、説明の負担は別々に動きます。だから相手を評価するだけでは足りません。

AI導入で経路が増える。増える入口は4つに整理できる

AIを業務に入れると、なぜ経路が増えるのか。理由は3つあります。1つ目は、道具の追加が現場の判断でできてしまうこと。2つ目は、外部の部品やサービスを前提に組む設計が多いこと。3つ目は、外部とつなぐこと自体が機能の本体になっていることです。データを渡す、処理を任せる、結果を受け取る。この往復が価値の源なので、つなぎ先を減らすと機能が減ります。安全のために接続を減らす、という選択が取りにくいという点が、従来の道具との一番の違いです。

増える入口は、次の4つに分けると担当と点検方法が決まります。まとめて「AIのセキュリティ」と呼んでいる限り、誰の仕事なのかが決まらず、結果として誰も手を付けません。

入口	何が入ってくるか	主に入れているのは誰か	先に見る1点
外部の拡張機能	業務の道具に後から足す小さな追加機能	現場の担当者。承認を経ないことが多い	配布元と、その拡張機能が読める範囲
公開されている部品	開発で取り込む共通部品と、その更新	開発担当と、自動で取り込む仕組み	何をどの版で使っているかの一覧の有無
外部とつなぐ鍵	接続のための認証情報と、渡した権限	各部門の運用担当	権限の広さと、有効期限の有無
委託先の環境	自社が渡したデータと、その先での取り扱い	発注部門。契約に条件が書かれる	渡したデータの所在と量、再委託の可否

表を作る目的は網羅ではありません。4つの列のうち「主に入れているのは誰か」が決まっていない行を見つけることが目的です。担当が空欄の行は、点検の周期も、事故のときの連絡先も決まっていません。まずそこを埋めます。

入口1：外部の拡張機能と、担当者が自分で足した道具

開発の道具にも、事務の道具にも、後から機能を足す仕組みがあります。この追加は多くの場合、現場で完結します。申請の対象になっていないうえ、無料で数秒で入るため、入れた本人にも「導入した」という自覚が残りません。自覚が無いものは、後から聞いても申告されません。2025年には、配布の場に、広く使われている道具の名前に似せた偽物が置かれ、段階を踏んで遠隔操作の仕組みが仕込まれた例が報告されています。

見つけにくい理由は、台帳の作り方にあります。資産の管理は端末とソフト本体までで、その中に足された追加機能までは追えていないことがほとんどです。目視で見つけるのも難しく、空白や空行の中に不正なコードを隠し、画面上はきれいなコードに見せる手口も報告されています。人の目で読んで安全を確かめる、という前提はもう置けません。

マーケティング部門でも事情は同じです。閲覧の補助、資料作成の補助、会議の文字起こし。どれも便利で、どれも現場で入ります。ここで確かめる1点は機能ではなく、その追加機能が読める範囲です。多くの場合、渡しているのは「いま見ている画面の中身すべて」であり、顧客名や商談の内容がそこに含まれます。

入口2：公開されている部品と、それを自動で取り込む仕組み

開発では、公開されている共通部品を取り込むのが当たり前になっています。AIに書かせたコードも、部品を使う前提で書かれます。そして取り込みが自動化されている場合、更新のたびに新しい中身が入ってきます。人がひとつずつ確かめて取り込んでいるわけではない、という点がこの入口の特徴です。しかも、取り込んだ部品がさらに別の部品を呼ぶため、直接選んだ覚えのないものが数十から数百の単位で入ってきます。

2025年3月には、開発工程の自動処理で広く使われていた公開部品が書き換えられ、その処理を使っていた組織の秘密情報が、誰でも見られる実行の記録に流出したと報じられました。よく使われる部品の名前を1文字だけ変えた偽物を置き、打ち間違いで取り込ませる手口も、通年で報告が続いています。どちらも、取り込む側の手続きは正常に動いています。

対策の中心は、ソフトウェア部品表です。何を、どの版で使っているかを、機械が読める形で持っておくこと。先ほどの10大脅威の解説でも、4位への対策として、製品の中のソフトを把握するために部品表を活用することが挙げられています。穴が公表された当日に、影響の有無を数時間で答えられるかどうかが分かれ目です。答えるのに数週間かかる状態は、事実上「分からない」と同じです。

入口3：外部とつなぐ仕組みに渡した鍵と権限

AIを業務に組み込むと、外部の仕組みとの接続が増えます。接続には認証のための鍵と、相手側で何ができるかという権限が要ります。つなぎ先が1つ増えるたびに、鍵が1本増える。この本数が、そのまま経路の本数になります。ここは、増えていることに気づきにくい入口です。鍵は目に見えず、動いている間は何も起きないからです。使わなくなった接続の鍵が、失効されないまま何年も生き続ける、という形で残ります。

起きやすい失敗は3つあります。権限を必要以上に広く取ること、有効期限を切らないこと、誰がいつ何のために発行したかの記録が無いことです。ある調査では、公開されている拡張機能を調べたところ、数百件から外部につなぐための鍵が読み取れる状態のまま公開されており、中にはその拡張機能自身を更新できる権限を持つ鍵まで含まれていたと報告されています。

実務の型は単純です。鍵は台帳に載せ、発行時に有効期限と用途を書く。そして、つなぐときに、止める手順を同時に書いておくこと。止め方が書かれていない接続は、事故が起きたときに止められません。夜間に連絡が来て、誰がどの画面から何を押せば切れるのかを探すところから始まる、という状態を避けるためです。

入口4：委託先の環境に置かれた自社のデータ

制作会社、代行会社、開発の委託先。BtoBのマーケティングでは、顧客名簿、原稿、ウェビナーの参加者情報が日常的に外へ出ます。ここに新しい要素が加わりました。委託先がAIの道具を使い始めると、渡したデータがさらに別の仕組みへ渡る可能性が出てきます。委託契約を結んだ時点では存在しなかった経路です。契約を見直していない限り、この経路は書面のどこにも書かれていません。

契約で見るべき項目は4つです。再委託を認めるかどうか、渡したデータをAIの学習に使わせないこと、保管する場所と期間、そして事故が起きたときの連絡です。実務では、最初の3つは書いてあるのに、AIの道具を使ってよいかどうかだけが書かれていない契約が多く残っています。締結が数年前であれば、書かれていなくて当然です。

ここでも、確認するのは相手の姿勢ではありません。渡したデータの所在と量です。どの案件で、何件の個人情報を、どこに置いてもらっているか。この3つを自社側で言えるかどうかを先に確かめます。言えないなら、相手を評価する前に、自社の記録を作るほうが先です。相手の回答は、自社の記録と突き合わせて初めて意味を持ちます。

運用の第1段階：入れる前の確認を1枚の関門にする

ここから運用の話です。第1段階は、入れる前の確認。よくある失敗は、確認票を丁寧に作りすぎることです。項目が30を超えると、現場は関門を避けて通るようになります。避けられた時点で、その関門は存在しないのと同じです。1枚に収め、答えるのに5分で済む形にします。

この関門の目的は、可否を判定することではありません。入ったことを記録に残すことが目的です。止められない道具は現実に存在しますし、止めれば業務が回らない道具もあります。それでも記録があれば、後から棚卸しができ、事故のときに影響範囲が言えます。判定の関門にすると通過率を上げる圧力がかかりますが、記録の関門なら通してよいので、現場も協力します。

運用の第2段階：入れた後の棚卸しと、台帳に載らない道具の見つけ方

台帳は、作った瞬間から古びます。関門を通ったものだけを載せた台帳は、現実の3割から半分程度しか映していないと考えたほうが安全です。そこで第2段階として、四半期に1回の棚卸しを置きます。周期を決めておかないと、事故が起きたときにだけ慌てて調べることになり、そのときには時間がありません。

台帳に載っていない道具は、次の3つの記録から探せます。1つ目は経費の記録で、少額の継続決済に道具の名前が残ります。2つ目は通信の記録で、社内から外部のどこへ接続しているかが分かります。3つ目は端末側の一覧で、追加機能まで含めて取得できる仕組みがあれば、いちばん確実です。3つとも、既に社内にある記録です。新しい仕組みを買う前に、ここを見ます。

見つかったときの扱いを、先に決めておきます。棚卸しで見つかった道具について、入れた本人を罰しないことです。罰する運用にすると、次から申告されなくなり、見えない道具だけが増えます。実務では「見つかったら台帳に載せる。危ないものだけ止める」と宣言してから始めます。第1回の棚卸しでは、想定の何倍もの道具が出てきますが、それが現実の姿です。

運用の第3段階：事故が起きたときの連絡の順番を先に決める

第3段階は、事故が起きたときの連絡です。ここは平時に決めておかないと、必ず遅れます。決めるのは3つ。誰が第一報を出すか、誰に出すか、何を書くか。第一報に書くのは、確定していることだけです。原因も影響範囲も、初日には分かりません。分からないことを分からないと書くのが正しい第一報です。

• 第一報の宛先を、社内の上長・情報システム・法務・広報の順で先に名前で決めておく。役職だけの指定だと不在時に止まる
• 委託先から連絡を受け取る期限を契約に書く。「事故を把握してから何時間以内に第一報」まで数字で書かないと、数日後に届く
• 顧客への説明は自社が行う前提で、説明文の下書きと想定問答を平時に用意する。事故当日に文章を考える時間はない
• 連絡の練習を年1回行う。訓練は攻撃を防ぐためではなく、連絡の穴を見つけるために行う
• 事故ではないと判断した場合も、判断した人と根拠を記録に残す。記録が無いと、同じ事象で毎回同じ議論をやり直すことになる

委託先が絡む事故では、連絡が来ない時間がそのまま自社の遅れになります。だから契約に期限を書きます。加えて、連絡が来ない場合に自社から確認する日を決めておくと、待ち続ける事態を避けられます。報道で知る、という順番になると、顧客への説明で最も苦しい立場に立つことになります。

取引先を疑うのではなく、経路を書き出す。依頼と契約の文面

確認票を送る側になったときの話をします。文面を疑いの形にすると、返ってくるのは形式的な回答だけです。「対策を実施していますか」に「はい」と返ってくる往復を何十社と続けても、経路は1つも分かりません。聞くべきなのは姿勢ではなく事実で、しかも相手が調べずに答えられる事実です。

• 「情報セキュリティ対策を実施していますか」——はい以外の答えが返らない。回答から何も分からない
• 「体制は万全ですか」——万全と答える以外に選択肢がない聞き方は、質問として機能しない
• 「規程を整備していますか」——規程の有無と、実際の運用は別。あると答えられても経路は分からない
• 40問を超える確認票を全取引先に一律で送る——回収率が落ち、回答の質も落ちる。件数が多いほど中身が薄くなる
• 回答をもらったあと、何も返さない——次回から回答が雑になる。受け取った旨と、追加で確認したい点だけ返す

代わりに聞くのは3つです。渡したデータを何に置いているか、そこにAIの道具を使っているか、止めるときは誰に言えばよいか。この3つは相手が即答でき、しかも答えが具体的です。姿勢を聞くのをやめて、置き場所と連絡先を聞くと、回答の質が変わります。

自社が答える側になったときも同じ姿勢で臨みます。答えられない項目には、答えられないと書く。分からないものを「実施しています」と書いた場合、事故が起きたときにその1行が最も重い問題になります。正直に空欄を返した相手のほうが、後で信頼されます。

AIに任せてよい工程と、人が決める工程の線

この点検作業そのものにAIを使う話をします。任せてよいのは、量をさばく作業と、抜けを指摘する作業です。逆に、量を絞る判断と、責任を伴う決定は渡せません。具体的には、次の3か所が向いています。

1. 一覧づくりの下ごしらえ：経費の記録、通信先の記録、端末の一覧といった散らばった資料から、道具の名前らしきものを拾い出させる。人が最初から目で追うと、数百行で集中が切れる
2. 確認票の抜けの指摘：作った確認票と、相手から返ってきた回答を渡し、聞けていない項目と、回答が質問に答えていない箇所を挙げさせる。指摘の当たり外れは人が見る
3. 公表された知らせの一次仕分け：外部で公表された注意喚起を渡し、自社の一覧に載っている道具や部品に関係しそうかを仕分けさせる。関係ありと出たものだけを人が読む

3つ目には条件が付きます。関係なしと判定されたものも、件数と判定理由を残させることです。調達の知らせは数が多く、外した理由が残っていないと後から精度を測れません。関係ありだけを残す運用は、点検の材料そのものを捨てていることになります。見逃しの点検ができない仕分けは、仕分けとして使えません。

渡してはいけないのは3つです。道具を入れてよいかの可否判断、事故かどうかの判定、顧客に連絡するかどうかの決定。理由は能力の問題ではなく、根拠の説明と責任の所在にあります。事故の判定を機械の出力に委ねた場合、後から「なぜそう判断したのか」を説明できません。使うときは必ず、出典の名前と日付を添えて書かせ、人がその出典を確かめてから動きます。

この点検が効かない場面と、途中でやめる条件

最後に、やらないほうがよい場面を書きます。この点検は手間がかかるので、使いどころを外すと、担当者が疲弊して1回で終わります。1回で終わった点検は、翌年には古い一覧が残るだけになり、あるという事実がかえって判断を誤らせます。

この状態なら軽くする・やめる	そこで実際に起きていること	代わりに先にやること
使っている道具が10個以下で全部把握できている	一覧を作る作業に、一覧が無いことによる損失を上回る手間がかかっている	台帳を1枚の表で持ち、四半期の棚卸しだけを残す。関門は口頭でよい
業務のほぼ全部が1社のサービスに載っている	経路は増えていない。実質的にはその1社の管理状況の話になっている	その1社の公表資料と障害の履歴を読む。自社側は鍵と権限の管理に絞る
確認票の回収率が5割を切っている	評価すること自体が目的になり、回答が形式化している	項目を10問に減らし、置き場所と連絡先だけを聞く形に作り直す
棚卸しで見つかった道具を毎回止めている	現場が申告しなくなり、見えない道具が水面下で増えている	止める基準を先に公開する。基準に当たらないものは載せるだけにする
担当が1人で、その人の残業で回っている	属人化しており、その人が異動した時点で運用が消える	周期を半年に伸ばしてでも、2人以上で回す形に組み替える

表の3行目と4行目は、やめるというより作り直しの合図です。回収率と申告数は、運用が生きているかどうかを測る数字として使えます。どちらも落ちているのに続けている場合、成果物は毎年出るのに、中身は誰も信じていないという状態になっています。

よくある質問

規模の小さい取引先にも、同じ確認票を送るべきですか

同じものを送る必要はありません。渡しているデータの量と種類で、聞く深さを変えます。個人情報を渡していない相手には、置き場所と連絡先の2問で十分です。逆に、顧客名簿を扱う相手には、再委託の可否とAIの道具の利用可否を必ず加えます。相手の規模ではなく、渡したものの重さで決めます。

現場が勝手に入れた道具は、見つけたら止めるべきですか

止める基準を先に公開してから、基準に当たるものだけを止めます。基準の例は、顧客情報や商談の内容を外部に送るもの、配布元が確認できないもの、権限の範囲が説明できないものの3つです。基準に当たらないものは台帳に載せるだけにします。全部止める運用にすると、次回から申告が来なくなります。

AIの道具を使ってよいかは、契約のどこに書けばよいですか

再委託の条項の近くに、独立した1条として置くのが扱いやすい形です。書く内容は、利用の可否そのものより、利用する場合の条件です。渡したデータを学習に使わせないこと、利用する道具を事前に知らせること、変更したときも知らせること。禁止と書くだけの条項は、実際には守られているかどうかを確かめられません。

ソフトウェア部品表は、誰が作るのですか

自社で開発している部分は開発担当が、購入した製品については提供元に求めるのが基本です。提供元が出せないと答える場合、それ自体が判断材料になります。マーケティング部門が関わるのは、外部に制作を委託した仕組みについて、使っている部品の一覧を納品物に含めてもらう部分です。契約時に書いておかないと、後から出してもらうのは難しくなります。

まとめ

サプライチェーン攻撃は、取引先の姿勢を疑う話ではありません。自社に入ってくるものの経路が増えたのに、その一覧を誰も持っていないという話です。公的な整理でも、この型は8年連続で組織向けの2位に居座り続けており、同じ表には初めてAIの利用をめぐるリスクが3位で入りました。2つは別の課題ではなく、AIを入れるほど外から取り込むものが増えるという、1本の線でつながっています。

増える入口は4つに分けます。外部の拡張機能、公開されている部品、外部とつなぐ鍵、委託先の環境。分けるのは網羅のためではなく、担当が空欄の行を見つけるためです。そのうえで運用を3段階に載せます。入れる前の関門は可否の判定ではなく記録のために置き、入れた後の棚卸しでは見つかった人を罰せず、事故のときの連絡は宛先と期限を平時に名前で決めておく。

AIに任せてよいのは、一覧づくりの下ごしらえ、確認票の抜けの指摘、公表された知らせの一次仕分けまでです。道具を入れてよいかの可否、事故かどうかの判定、顧客に連絡するかどうかは人が決めます。そして、道具が10個以下で全部見えているなら、この点検はやりません。使う場面を選ぶところから、すでにこの作業は始まっています。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。