サプライチェーンの信頼が高コスト化｜査読前研究

ソフトウェアサプライチェーンへの信頼は、静かに、しかし確実に「高くつくもの」へ変わっています。米ノースカロライナ州立大学とカーネギーメロン大学の研究チームが2026年8月21日にarXivで公開した査読前論文は、実務者38人へのインタビューから、チェックの仕組み（統制）は積み上がる一方でめったに撤去されず、その負担を下げるために実務者は「信頼の置き場所」を移しているという実態を描き出しました。

結論から言えば、サプライチェーンは低信頼な世界に転落してはいません。ただし「何も確かめずに使う」時代は終わり、確かめるコストを誰が負担するのかという問題に置き換わりました。情シスにとっては、自社が無自覚に担っている（あるいは誰かに任せきりにしている）検証コストを可視化するのに、ちょうどよい材料です。

この記事でわかること

  • ソフトウェアサプライチェーンへの信頼が「どう」変化しているのか（崩壊ではなく再編）
  • 実務者が実際に採用している統制と、判断に使っている「シグナル」の実態
  • AIが依存関係の選定と検証に入り込むことで生じている、新しい信頼のねじれ
  • 情シスが自社の委託先・OSS管理を見直すときのチェック観点と、参照すべき公的指針

どんな研究か（1文要約）

ソフトウェアサプライチェーンとは、自社のコード以外から取り込むすべて（第三者ライブラリ・OSS依存、それをビルドし配布する仕組み、そしてそれらを開発・保守する人々）を指します。本研究は、その全体に対して実務者がどこまで信頼を寄せているかを、「意見」ではなく「実際に導入した統制」から読み解いた質的インタビュー調査です。

調査は2025年12月から2026年4月にかけて実施され、産業界19人・OSS実務者19人の計38人が対象です。特徴的なのは、募集資料にも質問にも「信頼（trust）」という言葉を一切使っていない点です。信頼度を直接尋ねると回答者ごとに解釈がばらつき、社会的望ましさバイアスも入るため、経済学の顕示選好（revealed preference）の考え方を借り、「最後に依存関係を追加したのはいつか、そのとき何をしたか」といった具体的行動を聞き取っています。書き起こし928ページをテーマ分析にかけ、10の発見にまとめています。

本論文は査読前のプレプリントです。また38人の質的調査であり、「日本企業の何％が」といった分布を示すものではありません。結果は今後変わりうる点を踏まえて読む必要があります（限界は後述）。

何が分かったのか

統制は積み上がるが、めったに撤去されない

最も基調となる発見は、統制が一方向に増え続けていることです。依存関係の管理ではSnykやDependabotといったSCA（ソフトウェア構成分析）ツールによる自動スキャンの導入が最も多く、CI/CDへのセキュリティゲート組み込み、SBOMの自動生成、再現ビルド、サードパーティ製GitHub Actionsのレビューが続きます。「汚染された更新を踏まないよう、公開から1週間〜1か月は意図的に更新を遅らせる」という運用を挙げた参加者もいました。

そして重要なのは、これらの統制の追加がほとんど後追い（reactive）だという点です。自社で起きたインシデント、ニュースで見た攻撃、先輩の一言。そうした外部からの刺激で1つずつ増え、いったん入った統制が「もう要らない」と外されることは稀でした。研究チームはこれを、個々のメンテナが信用できなくなったからではなく、サプライチェーンという「仕組み全体」への信頼（システム信頼）を維持するコストが上がった結果だと解釈しています。

意識の外では、信頼は「選ばれる」のではなく「既定で」与えられている

統制を入れていない人が、リスクを検討したうえで「不要」と判断しているとは限りません。調査では、リスクも対策の選択肢も視野に入っていないまま、既定値として信頼が与えられているケースが目立ちました。インタビューを受けたことで初めてリスクを意識し、その場で統制を検討し始めた参加者が複数います。ある参加者は「パッケージがLLMによって作られている可能性なんて、考えたこともなかった」と気づく場面がありました。意図的に「費用対効果が合わない」と判断するのと、選択肢を知らないまま使うのとでは、同じ「統制なし」でも意味がまったく違います。

判断材料は今も「スター数と更新頻度」。そこにAIが圧力をかけている

では実務者は何を根拠に依存関係を採用しているのか。答えは拍子抜けするほど従来どおりで、人気度（GitHubのスター数など）、メンテナの活動状況、ドキュメントの品質、Stack OverflowやRedditでの推薦といった、取得コストの安いシグナルが主役でした。人気度を「多くの目に晒されているから品質・セキュリティも大丈夫だろう」という代理指標として使う、という構図です。

ここに2つの変化が重なっています。1つは、依存関係の選定そのものをAIに推薦させる実務者が現れていること。もう1つは、こうした安価なシグナルは偽装しやすいことです。スター数の水増し（fake stars）やAI生成のもっともらしいドキュメントを懸念していた参加者は、38人中わずか4人でした。研究チームは、AIによるシグナルの劣化はまだ実務者の意識の前面には出ておらず、しかし今後変わりうる、と慎重に書いています。

コストを下げるために、信頼は「移動」する

統制が増えれば負担も増えます。実務者はそれを、信頼を手放すのではなく置き場所を移すことで凌いでいました。研究が挙げる移動先は3つです。

移動先 具体例 新たに生じる論点
自動化 手作業の監査をSCAツールや静的解析、AIレビューに置き換える。ソースを直接読まなくなった参加者も 自動化そのものが新しい信頼対象になる。ツールが見落としたときの露出は誰の責任か
ガーディアン（信頼の代行者） 社内のセキュリティ／コンプライアンス部門が許可リストや内部ミラーを用意し、開発者は外部依存を直接採用しない。外部では、ベンダーが検証済みとして提供するOSSディストリビューションなど 「一度検証して多数を救う」効率はあるが、ガーディアン自身が高価値の攻撃対象になる
統制水準の委譲 「スキャンを通さなければ出荷させない」といった規律を中央のセキュリティ部門が敷く。外部指針（OpenSSF、OWASP、NIST SSDF）に準拠する 開発者は決められた線より上に信頼を伸ばせなくなる。歓迎する声と、コストや形式主義への不満が並存

興味深いのは、ガーディアン役をAIが担い始めている点です。「使う依存はClaudeが既定で選んだものだ」と語る参加者がいました。研究チームはこれを、人間のガーディアンとは決定的に違うと指摘しています。社内セキュリティ部門は「一度の検証を多数で分かち合う」仕組みですが、個々人のLLM利用にはその共有効果がなく、説明責任の引き受け手もいません。

「自分のAIは信じるが、他人のAIは信じない」

本研究で最も示唆的なのは、AIに対する信頼が誰がそれを操作しているかで反転するという観察です。実務者はAIを「速さと網羅性」については信頼する一方、「品質」は信頼せず自分で確認する傾向がありました。さらに、自分が使うAIには信頼を寄せるのに、他人がAIで生成した依存関係には強い警戒を示すという非対称が繰り返し現れます。複数のツールやAIを互いに監視させる運用を採る参加者もいました。

これはAIコーディング支援が普及した組織なら、そのまま自社に当てはめられる論点です。社内で「AIで書いたコードはレビューを厚くする」と決めていても、外部から取り込む依存関係の向こう側で同じことが起きているのかは、SBOMを見ても分かりません。

統制は「信頼される側」の証明としても使われる

統制はすべてが自衛のためではありません。アテステーション（成果物の来歴証明）、SBOM、認証取得、ポリシー順守の文書化など、下流の利用者から信頼されるために採用される統制があります。これらは偽装しにくいため、シグナルとして機能します。さらに、政府系の顧客が「依存ツリーに既知の脆弱性がないSBOM」を求める、PCI DSSのような市場標準が事実上の要件になる、といった取引条件として外から課される統制も挙がっています。日本でも委託先へのセキュリティ要求は調達要件として広がっており、他人事ではありません。

「そもそも依存しない」という選択肢

統制を積むのではなく、依存関係そのものを持たないことで露出を消す動きも、少数ながら語られました。ある参加者は1000行未満の依存であればLLMに書かせると述べ、同時に「Springフレームワークを一から作ることは絶対にない」と限界も認めています。研究チームはこれを、極端な不信の表れとも、「自前で作るコスト」が「検証するコスト」を下回った合理的判断とも読めると両論を示しています。いずれにせよ、信頼はコード生成プロセスへ移るだけで、消えるわけではありません。

情シスの実務にどう効くか

この研究は開発者コミュニティを対象にしていますが、示唆は情シスの調達・委託先管理にほぼそのまま転用できます。読みながら自社に当てておきたい観点を3つ挙げます。

1. 自社の「ガーディアン」は誰か、を言えるようにする。開発部門がどの依存を使ってよいかを、誰がどんな基準で決めているのか。情シスなのか、開発チームの慣習なのか、ベンダー任せなのか、あるいは誰も決めていないのか。研究では、社内セキュリティ部門を信頼している開発者の多くがその部門が実際に何をチェックしているかを知らなかったと報告されています。委ねる側と委ねられる側の認識がずれたまま「誰かがやっているはず」になっている構図は、日本の情シスにも心当たりがあるはずです。

2. 統制の棚卸しを「増やす」だけでなく「見直す」方向でも行う。統制は事件のたびに増え、外されない——これが本研究の中心的な観察でした。増やすこと自体は悪ではありませんが、リスクに見合わない統制は現場の反発と迂回を生みます。参加者からは「必要性は理解しているが、これだけ統制を強いられると苛立つ」「過剰で形式的だ」という声も出ていました。研究チームは、目標を「信頼の回復」ではなく較正（キャリブレーション）——重要度の高い依存には厚く、そうでないものには薄く——と表現しています。脆弱性の優先度が組織ごとに変わることを示した研究と併せて読むと、優先度づけの発想がつかみやすいはずです。

3. AI生成の依存関係を、資産管理の視野に入れる。「うちはAIにコードを書かせていない」としても、取り込んでいるOSSの上流で使われている可能性は排除できません。現時点でこれを検出する実用的な手段は乏しく、研究でもそこは未解決です。だからこそ、再現ビルドの検証が実際にはどこまで通るかを調べた研究や、LLM基盤OSSの脆弱性を分析した研究のように、来歴と検証可能性を高める取り組みの意味が相対的に増しています。

現場目線の所感

読んでいて一番こたえたのは、「インタビューを受けて初めてリスクに気づいた」参加者が複数いた、というくだりです。責める話ではありません。日々の業務に追われていれば、依存パッケージの向こう側まで意識が届かないのは当然で、これは情シスの現場でも同じです。台帳に載らないもの、開発チームが自己判断で入れたもの、パッケージ製品のインストーラが勝手に入れたミドルウェア。「見えていないものは、信頼しているのではなく、ただ気づいていないだけ」という指摘は、耳が痛いところを正確に突いています。

そしてもう1つ。統制を増やすほど現場は苦しくなり、迂回する動機が生まれます。「締め切りに追われているとセキュリティを回避したくなる」という参加者の率直な言葉は、統制を設計する側が忘れがちな現実です。統制を足す判断と同じ熱量で、その統制が守っているリスクを説明し続けること。結局はそこに尽きると感じました。

限界と留意点

  • 査読前のプレプリントであり、内容は今後変わりうる。
  • 38人の質的調査であり、母集団の分布を示す統計調査ではない。「◯％の企業が」という読み方はできない。
  • 参加者は北米19人、アジア11人、欧州7人、アフリカ1人。英語での実施かつ対象国が限られ、日本の実務を直接反映したものではない。
  • 調査に応じた人ほど関心が高く実践も進んでいる可能性がある（自己選択バイアス）。産業界の参加者19人中12人は研究者の人的ネットワーク経由で、サプライチェーンセキュリティに元々関与している層に偏る。
  • 研究チーム自身が明記するとおり、行動から信頼を読み取ることは「測定」ではなく「解釈」であり、別の分析者なら異なる読み方をしうる。分析の信頼性向上のため補助的にLLMを利用した点も、論文内で論争のある手法として明示されている。

情シスはどうすべきか（公的指針への誘導）

自前で長大なチェックリストを作る前に、まずは公的機関が整理した指針にあたるのが近道です。

あわせて、地道な啓発が効く領域でもあります。「そのライブラリ、誰がどう選びましたか」「その判断はスター数だけで足りますか」と問いかけられる関係を開発部門と作れているかが、統制の数より効くことは少なくありません。統制を増やす前に、現状の依存関係と決定プロセスを一緒に眺める場を持つことをおすすめします。

まとめ

  1. 信頼は崩壊ではなく「高コスト化」している。統制はインシデントのたびに積み上がり、めったに撤去されない。実務者はそれを、自動化・ガーディアンへの委譲・統制水準の委譲という形で凌いでいる。
  2. 依存の選定は今もスター数や更新頻度という安価なシグナルに依存し、AIがそれを揺さぶっている。自分の使うAIは信じるが他人のAI生成物は信じない、という非対称が現れている。
  3. 情シスがまず言語化すべきは「自社のガーディアンは誰か」。委ねる側と委ねられる側で認識がずれたまま「誰かがやっているはず」になっていないかを確認し、統制は増やすだけでなく重要度に応じて較正する。

出典

タイトルとURLをコピーしました