Web受発注システムのセキュリティ対策：提供元に確認する項目と自社の運用の線引き

◆監修・編集責任者　小園 将隆　2026年10月5日

B2B EC-COLUMN

Web受発注で守るデータと、現実に起こりうる被害の見取り図

取引先から「注文はWebでお願いしたい」と求められた、あるいはFAXやメールの受発注をWebへ移そうとしている。
ところが、注文や請求のデータを外部のシステムに預けて安全なのか、何を聞けば判断できるのかが見えない。
Web受発注システムのセキュリティは、クラウド型ならサーバー側は主に提供元、ID・端末・権限の運用は利用企業という分担で考えるのが基本です。
守る対象と起こりうる被害を先に整理すると、提供元に確認する項目と自社で決める運用ルールを分けて考えられます。
事故時に報告が必要になる条件と期限も、導入前に押さえておくと慌てずに済みます。

守る対象は注文・取引先・請求・ログイン権限

Web受発注で扱うデータは、1件の注文が流れる順にたどると整理しやすくなります。
取引先がログインし、商品と数量を入力して注文を確定する。
受注側はその注文を受け付けて出荷し、締めの時点で請求を起こす。
この流れの中で、システムには注文の明細、取引先の会社名や担当者の連絡先、単価や掛け率、請求金額や振込先といった情報がたまっていきます。

見落とされやすいのが、ログイン権限そのものも守る対象だという点です。
注文データが盗まれなくても、取引先のIDを他人に使われれば、正規の画面から偽の注文が入ります。
システムから見れば正しいIDでの操作です。
受注側の担当者が、普段と違う数量や届け先に気付かない限り、そのまま出荷まで進んでしまいます。

守る対象を注文・取引先・請求・ログイン権限の4つに分けておくと、提供元に質問するときにも「このデータはどこに保存され、誰が見られるのか」と具体的に聞けます。
また、取引先の担当者名やメールアドレスは個人データにあたることがあり、事故時に報告が必要かどうかの判断にも関わってきます。

脅威の順位を受発注の業務に当てはめる

どの被害から備えるかの目安として、IPA（情報処理推進機構）が公表している「情報セキュリティ10大脅威」が使えます。
2026年版の組織向けでは、1位がランサム攻撃による被害、2位がサプライチェーンや委託先を狙った攻撃、4位がシステムの脆弱性を悪用した攻撃で、内部不正が7位、DDoS攻撃が9位、ビジネスメール詐欺が10位に入っています¹。
ただし、これは業種を問わない組織全般の順位で、Web受発注システムで起きた被害を数えた統計ではありません。

これらを受発注の業務に当てはめると、次のような被害の場面が考えられます。
起こりうる場面を示したもので、発生の多さを表すものではありません。

• ランサム攻撃：受発注システムや社内のPCのデータが暗号化され、注文の受け付けや出荷指示が止まる
• サプライチェーン・委託先を狙った攻撃：システムの提供元や、つながっている取引先が攻撃され、そこを足がかりに自社のデータに触れられる
• 脆弱性の悪用：公開されているログイン画面や連携部分の弱点を突かれ、注文・取引先のデータが抜き出される
• 内部不正：退職者や、権限を広く持ちすぎた担当者が、取引先の一覧や単価を持ち出す
• DDoS攻撃：大量のアクセスを送り付けられ、取引先が注文画面を開けなくなる
• ビジネスメール詐欺：取引先を装ったメールで「振込先が変わった」と伝えられ、支払先がすり替わる

並べてみると、被害は「データが漏れる」だけでなく、「受発注が止まる」「偽の注文や偽の振込先でお金の損害が出る」という方向にも広がります。
止まる被害にはバックアップと復旧の手順、偽装による被害にはIDの管理と取引先との確認の決まり、というように備え方が違います。
そして、それぞれの備えを提供元が担うのか自社が担うのかで、導入前に確かめる相手も変わってきます。

提供元と利用企業の責任範囲：どこまでが提供元の仕事か

クラウド型の共有責任の考え方

クラウド型（SaaS）のWeb受発注システムでは、サーバーやデータベース、ソフトウェアの更新は提供元が管理し、利用企業はブラウザから使う形が一般的です。
この形では、セキュリティ対策も「どちらの手が届く範囲か」で分けて考えます。
IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版には、付録として「中小企業のためのクラウドサービス安全利用の手引き」があり、クラウドを使う際の留意点と責任分担を扱っています³。

この責任分担の考え方を受発注に当てはめると、サーバー側の脆弱性への対応、データの保管、基盤の障害への備えは主に提供元の仕事になります。
一方で、誰にIDを発行するか、どの担当者にどこまでの権限を与えるか、ログインに使うPCやスマートフォンをどう管理するかは、提供元からは見えません。
ここは利用企業にしか決められない領域です。

前の節の被害に重ねると、線引きがはっきりします。
脆弱性の悪用やDDoS攻撃への備えは、主に提供元の対策に依存します。
偽の注文、内部不正による持ち出し、ビジネスメール詐欺は、IDの管理や社内の確認手順に左右されるため、利用企業側の比重が大きくなります。
ランサム攻撃とサプライチェーン経由の攻撃は、提供元の基盤と自社のPCのどちらも入口になりうるので、双方にまたがります。

ただし、これは一般的な分担の考え方です。
個別のサービスで提供元がどこまで責任を負うかは、利用規約やセキュリティに関する説明で決まり、サービスごとに異なります。
たとえば提供元がデータのバックアップを取っていても、利用企業が誤って削除した注文を、利用企業の求めに応じて戻してもらえるかどうかは、規約を読まないと分かりません。

自社構築・パッケージで増える負担

自社のサーバーに受発注システムを構築する場合や、パッケージソフトを自社の環境に入れる場合は、クラウド型なら提供元に任せられたサーバー側の対策も、自社か保守を委託した会社の責任になると考えておくのが安全です。
OSやソフトウェアの更新を誰がいつ適用するのか、障害時に誰が復旧するのか、バックアップをどこに保管するのかを、自社と委託先の間で決めなければなりません。

ここで迷いやすいのが、「開発会社に頼んだのだから、セキュリティも見てくれているはず」という思い込みです。
構築を請け負った会社が、稼働後の更新や監視まで引き受けているかどうかは、保守契約の範囲次第です。
契約書に書かれていない作業は、誰も担当していない可能性があります。
自社構築やパッケージを選ぶ場合、責任範囲を確かめる先は利用規約ではなく、構築と保守の契約書になります。

導入前に提供元へ確認する項目と、確かめ方

確認項目のチェック表

責任範囲が分かれると、提供元に聞くべきことは「提供元の側の対策が、自社の求める水準に届いているか」と「自社の運用を支える機能があるか」の2つに絞れます。
IPAのガイドライン第4.0版は対策の柱を「6か条」に拡充し、新たに「バックアップを取ろう!」を加えています³。
受発注が止まる被害に備えるうえでも、バックアップは確認項目から外せません。

以下は、ここまでの責任分担と脅威を受発注に当てはめて組んだ確認項目の案です。
公的な基準そのものではないので、自社の取引の事情に合わせて足し引きする前提で使ってください。

• 認証：社内の担当者と取引先がどうログインするか。
  パスワードに加えて別の要素で本人を確かめる多要素認証を設定できるか、利用企業の側で必須にできるか
• 権限：担当者ごとに見られる画面や操作を分けられるか。
  取引先ごとに見せる商品や単価を区切れるか
• ログ：誰が、いつ、どの注文を操作したかの記録が残るか。
  利用企業が自分で確認・出力できるか、どのくらいの期間残るか
• バックアップ：提供元がどの範囲のデータをどこに保管しているか。
  利用企業の求めで特定の時点に戻せるか
• 障害・事故時の連絡：提供元の側で障害や不正アクセスが起きたとき、誰に、どの手段で、いつまでに知らせてくれるか
• データの返却：解約や乗り換えのとき、注文・取引先のデータをどの形式で受け取れるか。
  提供元の側のデータはいつ消去されるか

このうち導入後に変えにくいのは、障害・事故時の連絡とデータの返却です。
機能の不足は設定の変更や運用の工夫で補えることがありますが、契約の条件は一度結ぶと見直す機会が限られます。
とくに事故時の連絡は、最後の節で扱う報告の期限と直接つながります。
提供元から知らせが届くまでに日数がかかれば、その分だけ自社が調べて動ける時間が減るからです。

回答を書面で残す

確かめ方は、まず提供元が公開しているセキュリティの説明資料や利用規約を読み、そこで分からない項目だけを質問として送る順序が効率的です。
公開資料で答えが出る項目まで質問に含めると、回答を待つ時間が延びるうえ、本当に不明な項目が埋もれてしまいます。

質問への回答は、電話や打ち合わせの口頭で済ませず、メールや回答書など後から読み返せる形で受け取ります。
理由は2つあります。
1つは、担当者が替わっても、導入時に何を確かめたのかを社内でたどれること。
もう1つは、取引先から「どのような対策をしているか」と問われたとき、提供元の回答を根拠として示せることです。
受注側として取引先にIDを発行する立場なら、取引先からこうした問いを向けられることも考えておく必要があります。

回答を受け取ったら、項目ごとに「提供元が担う」「自社の運用で補う」「どちらも担っていない」に振り分けます。
3つ目に入った項目が、契約前に交渉するか、自社の運用ルールに組み込むかを決めるべき空白です。
この振り分けがあると、導入後に自社で何を決めればよいかも、そのまま見えてきます。

SCS評価制度の水準の読み方

取引先から対策の水準を問われる場面の背景には、IPAが詳細を公開しているSCS評価制度があります。
★3は「専門家確認付き自己評価」、★4は第三者評価と技術検証を求める水準とされ、★4は「サプライチェーン企業等が標準的に目指すべきセキュリティ対策」と位置づけられています⁴。
運用開始は2026年度下期以降が想定されている段階です⁴。

読むうえで注意したいのは、受発注システムの提供元と利用企業のどちらがこの評価を求められる対象になるのか、制度の詳細情報からは読み取れない点です。
「提供元が★を取っていれば自社は安心」とも、「自社が★を取らなければ取引が続かない」とも、現時点では言えません。

それでも、提供元への確認に使える物差しにはなります。
★3と★4の違いは、自己評価に専門家の確認が付くのか、外部の第三者が評価して技術的な検証まで行うのかにあります。
提供元に「御社の対策は誰が確かめたものか」と尋ねるとき、この区別を頭に置いておくと、回答が自己申告にとどまるのか、外部の確認を経ているのかを聞き分けられます。

発注側・受注側、提供形態で変わる重点

受注側が重視する点

確認項目そのものは共通でも、どこに時間をかけるかは自社の立場で変わります。
受注側、つまり取引先にIDを発行して注文を受け付ける会社は、自社の社員だけでなく取引先の担当者のIDも預かります。
取引先の担当者が退職したり、取引先の社内でIDを使い回したりしていても、受注側からはすぐには見えません。

そのため受注側は、取引先ごとに権限を区切れるか、取引先のIDを受注側の管理画面から止められるか、ログで取引先ごとの操作を追えるかに重点を置くことになります。
偽の注文が入ったとき、「どのIDから、いつ入ったのか」をたどれなければ、取引先に事実を説明することもできません。
取引先の担当者名やメールアドレスを多く抱える立場でもあるため、事故時の報告の判断に関わる範囲も広くなります。

発注側が重視する点

発注側、つまり取引先が用意したWeb受発注システムでIDを発行してもらい、注文を入れる会社は、システムの選定にはほとんど関われません。
関われるのは、受け取ったIDを社内でどう使うかです。

発注側で問題になりうるのは、1つのIDを購買担当の複数人で使い回すこと、担当者が異動してもIDがそのまま残ること、そして請求や支払いに関するメールの真偽を確かめる手順がないことです。
とくに振込先の変更を装うメールは、ビジネスメール詐欺として組織向けの脅威にも挙がっています¹。
支払いの前に、メールの内容を受発注システム上の請求情報と照らし合わせる手順を挟んでおけば、メールだけを根拠に振込先を変えてしまう流れを断ち切る機会ができます。

選定の主導権がなくても、発注側から受注側へ、ログイン方法や多要素認証を使えるか、担当者が替わったときのIDの停止を誰に頼めばよいかを尋ねることはできます。
自社のIDの守り方を決めるために必要な情報だからです。

取引先の要請との向き合い方

サプライチェーンや委託先を狙った攻撃は、組織向けの脅威で2位に入っています¹。
受発注は取引先との接点そのものなので、取引先が対策の状況を尋ねてくる場面も、この流れの中で起きうるものです。

ただ、取引先がいつまでに何を求めるかは、取引ごとに異なります。
SCS評価制度も運用開始前の想定段階で⁴、「いつまでに★をそろえなければならない」と一律には言えません。
要請を受けたら、何を、どの形式で、いつまでに求めているのかを取引先に確かめ、前の節で書面にした提供元の回答と、自社の運用ルールを組み合わせて答える順序が現実的です。

立場と提供形態の組み合わせごとに、自社に残る責任と確認を厚くする項目を並べると、次のようになります。
ここまでの責任分担と脅威の当てはめから組んだ整理で、どの組み合わせが優れているかを示すものではありません。

表で判断が分かれるのは、自社構築の行です。
受注側が自社構築を選ぶと、サーバー側の更新と取引先IDの管理の両方を自社が抱え、確認先も提供元ではなく保守の委託先と社内の担当者になります。
発注側でも、取引先に入力してもらう発注用のシステムを自社で構築するなら、IDを発行する側に回るため、受注側と同じ確認が必要になります。
受注か発注かという呼び名より、誰がIDを発行し、誰がサーバーを管理するかで重点が決まると考えると整理しやすくなります。

導入後のID・権限・取引先対応の運用ルール

ID・権限・退職者対応

契約を結んだあと自社に残るのは、ここまで見てきたID・端末・権限の運用です。
以下は責任分担の考え方から組んだ運用ルールの案で、すべてを一度にそろえる必要はありません。

基本は、担当者ごとに別のIDを発行することです。
1つのIDを複数人で共有すると、ログに残るのは「そのIDが操作した」という事実だけで、誰が注文を変更したのかがたどれません。
担当者ごとに分けておけば、偽の注文や単価の書き換えが見つかったとき、操作した人を絞り込む手がかりが残ります。

権限は、業務に必要な範囲に絞ります。
注文を入力する担当者に、請求先や振込先の情報を変更する権限まで与えておくと、そのIDが乗っ取られたときに被害が請求まで広がります。
見られる画面と操作できる処理を役割ごとに分けることは、内部不正による持ち出しを抑える面でも、乗っ取られたときの被害の範囲を狭める面でも役立ちます。

退職・異動時のID停止は、人事の手続きと結び付けておくと漏れにくくなります。
受発注システムの管理者が退職の連絡を個別に受け取る形だと、連絡が届かなかった時点でIDが残ります。
退職や異動の手続きの中に受発注システムのIDの停止を一項目として入れ、あわせて時期を決めて有効なIDの一覧と在籍者を突き合わせる棚卸しを行えば、止め忘れに気付く機会ができます。

受注側が預かる取引先のIDは、さらに管理が難しくなります。
取引先の担当者が退職しても、受注側には知らされないことがあるからです。
取引開始時に「担当者が替わったら連絡してほしい」と依頼しておくことに加え、棚卸しの際に取引先へ有効なIDの一覧を送り、使われていないIDがないかを見てもらう方法があります。
ログを利用企業の側で確認できるサービスなら、長くログインのないIDを停止の候補として洗い出すこともできます。

多要素認証とバックアップ

多要素認証は、パスワードに加えて、スマートフォンのアプリに表示される確認コードなど別の要素でログインする人を確かめる仕組みです。
パスワードが漏れても、もう一つの要素がなければログインを通さないため、偽の注文につながるIDの乗っ取りへの備えになります。

運用で決めておきたいのは、誰に必須とするかです。
社内の担当者には必須にしやすい一方、取引先の担当者にまで求めると、設定の案内や、スマートフォンを替えたときの再設定の問い合わせが受注側に寄せられます。
まず請求や振込先、権限の設定を変更できる管理者のIDから必須にし、取引先には順を追って案内する、という段階の踏み方もあります。
どの方式を使い、どこまで必須にするかは、サービスで設定できる内容と取引先の事情を見て決めることになります。

バックアップは、IPAのガイドラインで対策の柱に加わった項目です³。
クラウド型で提供元がデータを保管していても、それとは別に、注文・取引先・請求のデータを自社でも出力して保管しておくと、提供元のサービスが止まったときや、誤操作でデータを消したときの手がかりになります。
出力したファイルにも取引先の情報が含まれるので、保管するPCやフォルダーの権限も、受発注システムと同じ考え方で絞っておきます。

取引先への案内

受注側にとって、取引先にIDを渡す時点は、運用ルールを伝えるいちばんの機会です。
IDとパスワードを同じメールで送らない、担当者ごとにIDを発行できることを伝える、担当者が替わったときの連絡先を示す、といった内容を、IDの発行案内と一緒に渡しておきます。

もう一つ伝えておきたいのが、受注側から取引先へ連絡するときの決まりです。
「振込先の変更をメールだけで依頼することはない」「重要な変更はシステム上のお知らせで伝える」と事前に案内しておけば、受注側を装ったメールが届いたとき、取引先が不審に気付く手がかりになります。
ビジネスメール詐欺への備えは自社の中だけでは完結せず、取引先と同じ決まりを共有して初めて働きます。

不正アクセス・誤送信が起きたときの報告と取引先への連絡

報告が必要になる4つの類型

不正アクセスで取引先のデータを見られた、注文確認のメールを別の取引先へ送ってしまった。
こうした事故が起きたとき、最初に判断が分かれるのは、漏れたデータに個人データが含まれるかどうかです。
個人情報保護委員会が示す漏えい等報告は、個人データの漏えい等を対象にしています²。

報告の対象になるのは、次の4つの類型です²。

• 要配慮個人情報が含まれる漏えい等
• 財産的被害が生じるおそれがある個人データの漏えい等
• 不正の目的によるおそれがある漏えい等
• 1,000人を超える漏えい等

Web受発注に当てはめると、法人同士の注文明細そのものより、取引先の担当者の氏名やメールアドレス、個人事業主である取引先の情報などが個人データとして関わってきます。
外部からの不正アクセスが原因なら不正の目的による類型に当たるかを、登録している担当者が多ければ人数の類型を、それぞれ検討することになります。
一方、法人の取引情報だけが漏れた場合にこの報告の対象から外れるのかは、報告の対象と期限を示した委員会のページだけでは判断できません。
迷う場合は、ガイドラインの本文や専門家に確かめる必要があります。

速報・確報の期限

報告は2段階です。
速報は発覚から3〜5日以内、確報は30日以内で、不正の目的による漏えい等の場合は確報が60日以内とされています²。

受発注の運用で効いてくるのは、速報までの短さです。
その間に、どのデータが、どれだけ、どの経路で漏れたのかを調べるには、提供元からの情報とログが欠かせません。
導入前に提供元へ確かめた事故時の連絡の取り決めや、ログを利用企業の側で確認できるかという項目が、ここで意味を持ちます。

なお、本人への通知が必要かどうかや、その例外は、報告の対象と期限を示したページには記載がありません。
報告とは別の手続きとして、ガイドラインの本文で確かめておく事項です。

取引先と受発注を止めない連絡

委員会への報告と並行して、取引先への連絡も必要になります。
こちらは法令で定められた手続きではなく、取引を続けるための対応です。
以下は、事故時の混乱を減らすための手順の案です。

1. 社内の連絡経路を使う：事故に気付いた人から受発注システムの管理者と経営層へ、事前に決めた経路で知らせる
2. 提供元へ連絡し、状況を確かめる：障害なのか不正アクセスなのか、影響を受けたデータの範囲を確認する
3. 報告の要否を判断する：個人データが含まれるか、4つの類型に当たるかを照らし、期限から逆算して動く
4. 影響する取引先に連絡する：何が起きたのか、取引先側で必要な対応（パスワードの変更など）を伝える
5. 受発注の代わりの経路を示す：システムを止める場合、どの手段で注文を受け付けるかを知らせる

最後の代わりの経路は、平時に決めておかないと事故のさなかには決めにくい項目です。
システムを止めれば被害の広がりは抑えられても、取引先は注文を出す手段を失います。
一時的にメールや電話で受け付けるなら、受け付けた注文を誰がどこに記録し、システムの再開後にどう戻すかまで決めておくと、復旧後の二重入力や入力漏れを減らせます。

ただし、普段と違う経路で注文や連絡を受け付ける時期は、受注側や取引先を装った連絡が紛れ込む余地が生まれる時期でもあります。
代わりの経路は平時のうちに取引先へ伝えておき、事故が起きてから初めて案内する形にしないことが、なりすましへの備えにもなります。

出典：個人情報保護委員会「漏えい等報告の対象と期限」。個人データの漏えい等が対象

提供元の回答を受け取っても、どの項目が自社の運用で補うべき空白なのかは、自社の注文や請求の流れと照らし合わせないと判断しにくいものです。

自社の受発注の流れに沿って、提供元に確かめる項目と社内で決める運用ルールをどう切り分けるかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
責任の線引き	クラウド型はサーバー側が主に提供元、ID・端末・権限は自社。個別の範囲は利用規約や契約書で確かめる
提供元への確認	認証・権限・ログ・バックアップ・事故時の連絡・データの返却。回答は書面で受け取る
立場による重点	IDを発行する側は取引先IDの停止とログ、IDを受け取る側は社内のID管理と請求メールの確認
導入後の運用	担当者ごとのID、権限の絞り込み、人事手続きと連動した停止、棚卸し、管理者からの多要素認証
事故時	個人データの有無と4つの類型で報告を判断し、速報は発覚から3〜5日以内。代わりの受注経路は平時に伝えておく

取引先からの要請への答え方や事故時の連絡手順は、自社の立場と取引の条件によって決めるべき内容が変わります。 IDを発行する側か受け取る側か、クラウド型か自社構築かに合わせて、何から決めていくかの順序を確かめられます。

よくある質問

提供元がISMS等の認証を持っていれば、利用企業側の対策は不要になりますか。

不要にはなりません。
提供元がどのような認証を持っていても、誰にIDを発行し、どこまでの権限を与え、退職者のIDをいつ止めるかは、提供元からは見えない利用企業の領域です。
また、認証が受発注サービスそのものを対象にしているかどうかも、提供元の説明で確かめておく必要があります。

取引先から対策状況の提出を求められたら、まず何をすればよいですか。

まず、取引先が何を、どの形式で、いつまでに求めているのかを確かめます。
そのうえで、提供元から書面で受け取った回答と、自社のID・権限・バックアップの運用ルールを組み合わせて答えます。
SCS評価制度は2026年度下期以降の運用開始が想定されている段階で⁴、取引ごとに求められる内容は異なるため、要請の中身を先に確かめることが出発点になります。

受注側だけが取引先のIDを管理する場合、取引先の退職者のIDはどう止めればよいですか。

受注側には取引先の退職が知らされないことがあるため、複数の手段を組み合わせます。
取引開始時に担当者が替わったら連絡してもらうよう依頼すること、時期を決めて有効なIDの一覧を取引先に送り確かめてもらうこと、ログを確認できるサービスなら長くログインのないIDを停止の候補として洗い出すことが考えられます。

Web受発注の誤送信は、個人情報保護委員会への報告が必要になりますか。

送ったデータに個人データが含まれ、要配慮個人情報、財産的被害のおそれ、不正の目的、1,000人超のいずれかの類型に当たる場合は報告の対象になります²。
その場合、速報は発覚から3〜5日以内、確報は30日以内です²。
法人の取引情報だけが誤って届いた場合の扱いは、報告の対象と期限を示したページだけでは判断できないため、ガイドラインの本文や専門家に確かめてください。

セキュリティ対策に使える補助金は、受発注システムの導入費にも使えますか。

使えるとは言えません。
デジタル化・AI導入補助金2026のセキュリティ対策推進枠は、「サイバーセキュリティお助け隊サービスリスト」に掲載され、IT導入支援事業者が登録したサービスを対象としています⁵。
補助率は小規模事業者が2/3以内、中小企業が1/2以内で、サービス利用料は最大2年分が対象です⁵。
受発注システム自体が対象になるかは明記されていないため、この枠はセキュリティサービスの導入に使うものとして考えるのが安全です。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026（組織向け）」（2026年）
2. 2　出典：個人情報保護委員会「漏えい等報告の対象と期限」（2026年）
3. 3　出典：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（2026年）
4. 4　出典：独立行政法人情報処理推進機構（IPA）「SCS評価制度の詳細情報」（2026年）
5. 5　出典：独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金2026 セキュリティ対策推進枠」（2026年）