AI時代のデジタルサプライチェーンリスクとマイクロソフトの取り組み

現在、サプライチェーンのリスクが重要課題となっており、多くの組織がその軽減策を模索しています。本セッションでは、日本マイクロソフトでCSO（Chief Security Officer：最高セキュリティ責任者）を務める河野 省二氏をお招きし、PwC Japan有限責任監査法人パートナーの川本 大亮との対談を通じて、生成AIの普及が進む中での企業の責任範囲の明確化や、サプライチェーンにおける信頼性の可視化について意見を交わしました。

登壇者

日本マイクロソフト株式会社
Chief Security Officer
河野 省二氏

PwC Japan有限責任監査法人
パートナー
川本 大亮

複雑化するデジタルサプライチェーンの危機

川本：
人工知能（AI）技術の進展で、サプライチェーンはデジタル空間でも複雑化・高度化しています。Society 5.0を見据える中、デジタルサプライチェーンのリスク管理は重要度を増しています。PwCコンサルティング合同会社が2025年2月に公開した「サプライチェーンデジタルリスク実態調査」でも、経営層が懸念するデジタルリスクの第1位は、「関係会社や外部委託先を経由した情報漏洩」でした（図表1）。

また、情報処理推進機構（IPA）の調査でも、サプライチェーンの脆弱性を突く攻撃は近年常に上位にあります。さらに、総務省と経済産業省が公表したAIガイドラインでは、AI開発者・提供者・利用者という立場ごとに責任を明確化するなど、サプライチェーンの視点を踏まえた対応が求められるようになっています。河野さんは、この点についてどのようにお考えでしょうか。

図表1：サプライチェーン先での情報漏洩が大きな懸念事項に

河野氏：
デジタルサプライチェーンの管理は非常に難しく、ハードウェア、ソフトウェア、データのそれぞれにリスクが存在します。例えば、データ漏えいの懸念からガバナンスの重要性が叫ばれている一方で、実際には顧客データをCSVファイルで保険会社にメール添付して送るといったケースも見られます。この場合、データベース内ではアクセス権が制限されていても、外部に渡した時点で制限が失われるなど、コントロール不能な状況が増えています。

マイクロソフトが築く次世代サプライチェーン管理

川本：
マイクロソフトは、自社のサプライチェーンにおけるトラスト構築で、非常に先進的な取り組みをされています。その1つがPwC Japan有限責任監査法人（以下、PwC Japan監査法人）も独立評価を支援している「SSPA（Supplier Security and Privacy Assurance）」プログラムです。

これは、必要な投資を行った信頼性の高いサプライヤーのみがエコシステムに参加できる仕組みであり、参加後はビジネス機会も広がる設計になっています。つまりSSPAは従来のようにコスト優先で安価なサプライヤーを選ぶのではなく、信頼性を重視して選定する新しい調達モデルです。さらに、このエコシステムは、ESG（環境・社会・ガバナンス）やレスポンシブルAIといった新たなテーマにも、既存のSSPAフレームワークを活用して柔軟に対応できる可能性を持っています。

図表2：Microsoft SSPAプログラムの概要（SSPA Program Guide v10から抜粋）

こうした取り組みは他社でも始まりつつありますが、河野さんはこの現状をどのようにご覧になっていますか。

河野氏：
マイクロソフトとしては、自社内と同様の管理をサプライヤーの皆さまにもご協力いただきたい。しかし、それを実現するのは難しく、たとえば、ISMS認証やプライバシーマークの取得など、組織としての信頼性を評価することで対応してきました。ただ、今は「データそのもの」に対する信頼性が重要視されています。マイクロソフトとしては「きちんとデータ管理をしていますか」という点をサプライヤーの皆さまに問いたいのですが、その状況を可視化し、適切に管理するには、ガバナンス体制の整備とリアルタイムのモニタリング機能が不可欠です。

そのため、デジタル技術を活用してサプライヤーの皆さまに情報を提供する際には、私たちがいつでもトレースできる形でお渡しするようにしています。データを提供する前にアクセス権や利用範囲をあらかじめ設定しておき、その設定を逸脱した場合にはバイオレーションとして即座に把握できるような仕組みにしています。

こうした取り組みでサプライヤー自身の「組織としての信頼性」と、「データ管理やIT利用といった運用面での信頼性」とを切り分けて評価しながら、サプライヤー側の負担をなるべく抑えつつも、リアルタイム性を確保するということを重視しています。

川本：
リアルタイム性というのは非常に重要なキーワードであり、今までにないデータ管理の考え方ですね。

「セキュリティ バイ デザイン」で実現する
クラウド事業者としてのマイクロソフトの責任

川本：
ここまでは、マイクロソフトの自社としての取り組みについて伺ってきました。一方で、マイクロソフトはクラウド事業者として、企業や組織のサプライチェーンにおけるトラスト構築を支える基盤も提供されています。責任範囲の可視化や各種認証制度への対応を通じて、利用者への積極的な情報提供も進めてられていると理解しています。

クラウドセキュリティに加えて、レスポンシブルAI^（※1）やESG（環境・社会・ガバナンス）などの新たなトピックも増える中で、トラストを証明するためのコストが拡大しているのが実情です。そうしたコストを抑え、効率的に対応していくための仕組みについてはどのようにお考えでしょうか。

河野氏：
マイクロソフトでは「セキュリティ バイ デザイン」に注目しています。これは、セキュリティを後から追加するのではなく、最初から設計に組み込む考え方です。ソースコードに脆弱性につながるバグがないようにするだけでなく、何かが起きたときに対応できる機能をあらかじめ入れておく。これはデータレベルでも同じです。

大きな変化があったのは2015年の新しいオペレーティングシステム登場時です。それ以前は、サーバー用OSを立ち上げてファイルサーバーを構築し、フォルダ単位でアクセス制御を設定してデータ管理を行っていました。しかし、外部のサプライチェーンとの連携で、ライセンスコストを抑えるため、アカウントを1つだけ発行して共有するケースもありました。その結果「いつ」「どこで」「誰が」「何をしたか」に対する説明責任が果たせない状況が発生していました。

こうした課題を解消するため、マイクロソフトが最初に取り組んだのがデータの標準化です。従来は、アプリケーションやデータ管理に対して非常に厳密な要件を課していたため、運用コストが高騰していました。これをOpen XMLのような標準形式にすることで、場所を問わず同じデータを利用できるようになったのです。

現在では、クラウド上のデータも、別の環境に移しても同様の権限管理が適用され、他サービスから持ち込んだデータにも統一的な管理が可能です。こうした仕組みは、米国政府と協力しながら推進しています。

川本：
なるほど。私たち利用者側も従来のやり方にとらわれず、データ管理のあり方そのものをアップデートしていく必要があるということですね。

河野氏：
はい。それに加えてAIの登場で、いま最も懸念されているのが「オーバーシェアリング」です。アクセス権やラベルの設定が適切でないと、本来見えてはいけないデータが、生成AIによって露出してしまう可能性があるという懸念です。

ただし実際には、ラベルを付けるだけでは不十分です。たとえば、会議用の資料などを作成するためにチームで情報をやりとりすると、同一のデータファイルがPCのローカル環境、クラウドストレージサービス、メール添付など、さまざまな場所に保存され、結果として広く分散してしまうことがあります。その結果、1つのデータがアクセス制御のない状態で広がり、生成AIがそれらを収集してしまうことで、意図しない情報が表示されるリスクが生じます。

この問題は、ネットワーク管理者と同等の操作権限を第三者に与えてしまうような脆弱性にもつながるものです。特にサプライチェーンにおいては、メールによる情報共有が日常的に行われており、その運用慣習にも見直しが求められていると感じています。

新技術活用時のリスクバランスを考える
レスポンシブルAIが示す安全性のあり方

川本：
生成AIの話題が出ましたので、もう少し掘り下げたいと思います。数々の新しいAIモデルが登場していますが、こうした新技術を組織はどう捉え、活用すべきでしょうか。私自身は便利な技術があれば前向きに活用したいですが、やみくもに使うのではなく、セキュアなものを積極的に使いたいという感覚です。

河野氏：
新しい技術は、実際に使ってみないとわからないことが多いです。私は2008年頃、経済産業省の『クラウドサービス利用者のための情報セキュリティマネジメントガイドライン』の執筆に関与しましたが、その際も多くの不安の声がありました。それを1つ1つガイドラインに盛り込み、数年後に再調査したところ、大きな事故はほとんど起きませんでした。

新しい技術には、従来の課題を解決する力も備わっています。そのため、大切なのは正しく活用していくことです。マイクロソフトでも現在、「Responsible AI Standard」という枠組みを整備しています。これは、自社のAIが安全であることを担保するのに加え、それを用いてサービスを提供する企業や、社内ルールを整える際の基準として活用できるよう設計されたものです。

多くの方に実際にAIを活用していただき、そのフィードバックを基にサービスを改善することで、AIの安全性に対する信頼を着実に高めていきたいと考えています。

「信頼できるAI」の必須条件、LLMの動作を透明化する取り組み

川本：
先日、米国マイクロソフトのCEOが来日時に使われた「Trustworthy AI」というキーワードが印象的でした。信頼できるAIを構築するためには、デジタルサプライチェーンリスクという論点も避けて通れません。AIをサプライチェーン管理に活用するという話は多くありますが、「活用するAIそのもののリスクをどう捉えるか」も重要です。AIは単体で動くものではなく、クラウドの基盤上で構築されるものなので、AIを取り扱うクラウドに求められる要件というのもあると思います。その点についてはいかがでしょうか。

河野氏：
マイクロソフトは生成AIを活用した業務支援アシスタントを提供しています。これは基本的に安全なモジュールをひとかたまりにして活用していますから、お客さまには「多くのことを気にする必要はありません」と説明しています。

ただし、それは私たちマイクロソフトが自社でコントロールできているからこそ成立します。サプライチェーンやAIビジネスのエコシステム全体では、そう簡単にはいかないかもしれません。

たとえば、他のAIプロバイダーのモジュールを組み合わせて利用する事業者にとっては、それらをどう統制するかが今後の課題です。クラウドでは、「シェアードレスポンシビリティ」^（※2）や「オンデマンドセルフサービス」^（※3）といった概念で、ユーザーとプロバイダー間の仕組みが可視化されてきました。しかし、AIではその中身が見えづらいという課題があります。

現在、私たちはAIがどのようなデータをどのように扱っているのかを可視化する仕組みづくりに取り組んでいます。プラットフォーマーとして、利用者の皆さまが管理しやすくなる環境を整えることを目指しています。

川本：
これから整備が進んでいく分野ですね。

河野氏：
そうですね。クラウドには「クラウドセキュリティポスチャーマネジメント（CSPM）」という考え方があり、ユーザーによる構成ミスを防ぐために、コンフィグレーションAPIを通じて環境の可視化が進められています。AIにおいても、どのようなデータやLLMを参照し、どのようなアウトプットを出そうとしたのか、またフィルターがかかったかどうかといった、一連のプロセスを把握できる仕組みを整えていきたいと考えています。

DevOps時代の協業スタイル――SBOM実現に向けた開発環境整備とIT資産の可視化

川本：
最後に構成管理の話に関連してお伺いします。今、ソフトウェアサプライチェーン対策としてSBOM（Software Bill of Materials）への関心が高まっています。ただし、ソフトウェア構成要素レベルでの管理を実現するには、そもそもIT資産の把握が前提になります。しかし日本企業では、どのソフトウェアが使われ、どう管理されているかを正確に把握できていないケースが多い印象です。この点について、どのようにお考えでしょうか。

河野氏：
まず、ソフトウェア開発環境そのものをデジタルで統合・標準化するDXの必要があります。特に日本の中小企業では、開発者が自分の使いやすいエディタを選び、好きなライブラリを持ち込んで、個人の裁量で開発を進めるケースが少なくありません。しかし、現在の開発現場では、DevOpsのように複数の専門家が連携しながら進める「協業型の開発スタイル」が主流です。

マイクロソフトでもIDE（Integrated Development Environment：統合開発環境）を提供しています。しかし、サインインせずに利用している方も多く、その場合「誰が」「どのようなコードを」「どのような環境で」作成したかが追えません。署名がなければ改ざんにも気づきにくく、旧バージョンに戻るなどのトラブルにもつながります。

ですからSBOMに進む前に、開発環境を整備し、開発プロセスの見える化と管理の徹底を進めることが重要です。そうした環境が整えば、IDEがライブラリの利用状況を自動で記録してくれるため、SBOMも自然と出力されるようになります。

川本：
単にIT資産管理を高度化するだけでなく、開発環境の整備も直結するということですね。本日は貴重なお話をありがとうございました。

^※1 レスポンシブルAI（Responsible AI）：倫理性・透明性・公平性・説明責任・安全性などを確保しつつ、責任あるAIを設計・運用するための枠組み

^※2 シェアードレスポンシビリティ（Shared Responsibility）：ユーザーとクラウド事業者が責任を分担するモデル。インフラの保守は事業者が、データやアクセス管理はユーザーが担う。

^※3 オンデマンドセルフサービス（On-Demand Self-Service）：必要なときにユーザー自身がシステム資源を追加・変更できるクラウドの特徴。