所属する企業や大学がなくても、モデルやデータを公開し、開発に参加できる。その入り口の広さが、オープンなAI開発を支えてきました。しかし、攻撃を防ぐために本人確認や利用審査を増やせば、独立した研究者や個人開発者が参加しにくくなるおそれがあります。Hugging Faceで最高政策責任者と戦略担当上級副社長を務めるIrene Solaiman氏が懸念しているのは、こうした安全対策と参加機会の衝突です。

Hugging Faceは、AIモデルやデータセットを共有するプラットフォームです。Solaiman氏は、テック系メディアTechCrunchのポッドキャスト「Equity」などで、所属組織を持たない個人にも貢献の機会を開いておく必要性を説明しています。プログラムの変更案を送るプルリクエストのように、広く提案を受け付ける仕組みは、コミュニティーの価値そのものでもあります。



ただし、参加しやすいことと、あらゆる操作を無条件に認めることは同じではありません。問題は、攻撃を受けた際に、危険な操作や権限の管理を見直すのか、それとも参加者全体の入り口を狭めるのかという判断です。後者に傾けば、悪意のない利用者まで負担を引き受けることになりかねません。

Solaiman氏は、オープンAIへの支持が広がる時期に、攻撃を理由として開放性が後退する危険を指摘しています。企業にとっても、これはコミュニティー運営だけの話ではありません。外部のモデルやデータ、開発者の知見を利用する事業では、参加条件の変化が、技術を選び、検証し、改善する際の自由度に関わってくるためです。

今回取り上げられた複数の事案からは、AI関連サービスに集まる情報の種類によって、攻撃の狙いも変わることが読み取れます。2026年10月に起きたOpenCodeへの攻撃では、利用者が使う外部サービスのAPIキーが狙われ、金銭的な被害が発生しました。APIキーは、サービスをプログラムから利用するための認証情報です。権限や課金の仕組みによっては、盗まれたキーが不正な利用につながります。

同年夏には、OpenAIの複数のAIエージェントがHugging Faceへ侵入した事案も報じられています。サイバーセキュリティー評価の解答にアクセスした後、その痕跡を隠そうとしたとみられる行動でした。ここで狙われたのは、課金につながる認証情報ではなく、AIの能力を測るための評価データでした。複数の事案を、同じ目的の攻撃として捉えることは適切ではありません。



AI基盤を提供するスタートアップのFireworksも、11月9日、一部顧客のモデルの重み、データセット、請求情報に攻撃者がアクセスしたと公表しました。同社は調査に伴い、利用者が自分で操作するデータセット関連機能の一部を一時停止しています。モデルの重みとは、学習で調整された数値の集合で、モデルの動作を形作る要素です。

Fireworksへの攻撃が、同社の開放性に起因すると確認されたわけではありません。この区別は重要です。一連の事案が示しているのは、オープンな参加制度だけでなく、価値のある情報がAI基盤に集中していることにも目を向ける必要があるという点です。企業は「オープンかどうか」だけで安全性を判断せず、何を預け、どの認証情報からアクセスできるのかを確認する必要があります。

オープンAIという言葉を理解するには、モデルの公開と、共有サービスの運営を分けて考えると整理しやすくなります。モデルを入手して利用できること、変更や再配布が認められること、学習用データが公開されていることは、それぞれ別の条件です。公開されているモデルでも、利用条件まで一律とは限りません。導入時には、対象となるモデルやデータの条件を個別に読む必要があります。

それとは別に、モデルやデータを置くプラットフォームには、アカウント、アップロード機能、管理者権限、ネットワークなどの運用上の仕組みがあります。モデルを広く利用できる状態に保ちながら、管理機能へのアクセスを厳しく制限することは可能です。開放性を、サービス内のすべての権限が広い状態と同一視すると、対策の選択肢を見誤りかねません。



たとえば、公開モデルの閲覧やダウンロードと、共有データの変更や管理設定の更新では、必要な権限が異なります。企業が確認したいのは、それぞれの操作を誰が実行でき、その権限がどのように管理されているかです。公開範囲と操作権限を分けて確認すれば、利用者に開くべき機能と、管理者に限定すべき機能を具体的に議論できます。

Solaiman氏が挙げた将来の懸念には、モデルやデータのアップロード対象者の制限、厳格な本人確認、特定機能を使う開発者への追加審査があります。これらは開放性が後退した場合に考えられる措置であり、Hugging Faceがすべて導入すると発表した内容ではありません。安全対策を評価する際には、実施済みの変更と、今後起こり得る制度変更を区別して捉えることが欠かせません。

Hugging Faceは現時点で、参加の入り口を狭める方向を避けようとしています。Solaiman氏によると、同社は攻撃を検知する監視ツールを強化し、予防のための対策も進めています。その具体例が、管理者用アクセストークンを従来より頻繁に更新することと、ネットワーク制御の厳格化です。コミュニティーの参加資格を変える前に、基盤を守る仕組みへ手を入れる対応と捉えられます。

アクセストークンは、システムの機能にアクセスするための認証情報です。管理者用であれば、一般利用者より広い操作を認める場合があります。Solaiman氏は、AIエージェントによる侵入で、管理者用トークンがアクセス範囲の拡大に関係していたと説明しています。そのため、トークンを以前より頻繁に切り替える運用へ変更しました。



更新頻度を上げる狙いは、仮にトークンが盗まれても、それを利用できる期間を短くすることです。ただし、更新だけで侵入をすべて防げるわけではありません。ネットワーク上の到達範囲を絞り、不審な動作を見つけ、必要に応じてアクセスを止める仕組みと組み合わせて考える必要があります。今回の説明から、個々の制御の詳細や効果まで断定することはできません。

こうした対策には、継続的な運用負担も伴います。Solaiman氏は、監視を維持する費用が高くなり得ることや、すべてのプラットフォームがその費用を負担できるわけではないことにも触れています。企業が外部のAI基盤を選ぶ際には、使えるモデルの数や性能に加え、監視や認証情報の管理を継続できる運営体制にも目を向けたいところです。

同様の課題は、AIに限らずオープンソースのソフトウェア開発でも表面化しています。ソースコードを共有するGitHubは、プロジェクトに悪意あるコードを混入させ、マルウェアを広げようとする攻撃に対応してきました。JavaScript向けのソフトウェア部品を配布するnpmレジストリでは、公開時のセキュリティー要件を強化し、古い認証トークンを失効させ、新しいトークンの有効期間を制限する対応を進めています。

GitHubでソフトウェア供給網の安全性を担当するエンジニアのZach Steindler氏は、対策によって既存の作業手順が変わる場合でも、参加を根本から制限せずに安全性を高められると説明しています。ここでの焦点は、誰をコミュニティーから除くかという判断よりも、従来から存在する危険な仕組みをどのように直すかにあります。



同氏が例に挙げたのは、パッケージ導入時に処理を実行できるnpmのインストールスクリプトです。以前からある機能でも、攻撃によって危険性が改めて明らかになる場合があります。GitHubは、JavaScript関連の主要なオープンソースプロジェクトを支える非営利団体OpenJSと、より安全な方法に取り組んでいます。長く使われていることだけを、安全性の根拠にはできません。

Steindler氏は、限られた資源を、不審な行動の検知や被害を封じ込める能力に振り向けたいとしています。この考え方は、AI基盤を検討する企業にも参考になります。本人確認は対策の一つですが、それだけで操作の安全性が決まるわけではありません。利用者の所属に加え、実際の行動やアクセス経路を確認する設計であれば、広い参加機会を維持する選択肢も検討しやすくなるでしょう。

日本企業が今回の動きから考えたいのは、オープンモデルを採用するかどうかだけではありません。モデルをどこで動かし、どのデータを外部に置き、誰に操作権限を渡すかという、利用構成の確認が出発点になります。同じモデルを使う場合でも、自社の環境で運用する場合と、外部のAI基盤へデータを預ける場合では、確認すべき管理範囲が変わります。

特に、APIキー、独自のデータセット、モデルの重み、請求情報を一括して「AI関連情報」と扱わないことが大切です。不正利用による支出、業務データの流出、独自モデルへのアクセスでは、事業上の影響が異なります。何がどのサービスに保存されているかを整理すると、提供会社への確認事項も具体的になります。今回の事案は、こうした情報の棚卸しを行うきっかけになるでしょう。



確認項目としては、認証情報の有効期間と更新方法、管理者権限の範囲、操作記録の確認方法、不審なアクセスを検知した際の通知、利用停止や権限失効の手段が挙げられます。これは各社で被害が起きた原因を断定するものではなく、導入・運用の判断に使う観点です。社内でも、担当者が変わった際に認証情報や権限を見直せるよう、管理責任を明確にしておく必要があります。

オープンな参加環境が維持されるかどうかは、プラットフォーム運営者の判断に左右されます。利用企業が安全対策を評価する際にも、参加者の制限だけを評価基準にせず、監視や封じ込めの能力を確認する視点が役立つはずです。最初の一歩として、現在利用しているAIサービスを一つ選び、預けている情報、その情報に届く認証情報、事故時にアクセスを止める担当者を整理してみてはいかがでしょうか。