WP.orgがProtect The Shire発表、プラグイン更新に24時間の猶予
2026年6月5日、WordPress.orgはセキュリティイニシアチブ「Protect The Shire」を正式に発表した。AIによるコード生成能力が急激に進化する中、78,000以上にのぼる公式プラグインとテーマをサプライチェーン攻撃から守るための大規模な取り組みだ。
この施策の中核は、すべてのプラグインとテーマのリリースに対して設けられる最大24時間の猶予期間である。開発者が新バージョンをプッシュしても、自動更新がユーザーサイトに配信されるまでにクールダウンが発生する仕組みに変わる。
Protect The Shire イニシアチブの全容
WordPress.org の共同創設者 Matt Mullenweg 氏は今回の発表で、2026年という年がソフトウェア開発において「緊張の年」になると指摘する。最新のセキュリティパッチを一秒でも早く適用する必要性と、悪意あるコードが更新に混入していないか慎重に見極める必要性が、かつてないほど対立しているためだ。
自動更新前の24時間クールダウン
従来のフローでは、開発者がプラグインやテーマの新バージョンをリポジトリにコミットすると、即座に世界の全サイトへ自動更新が配信されていた。これは利便性が高い一方で、ひとたび悪意のあるコードが混入すれば、被害が広範囲に瞬時に拡散するリスクを常にはらんでいた。
Protect The Shireの導入により、リリースから配信までの間に最大24時間の待機時間が挿入される。この時間を利用して、人間のレビューチームとAIがコードを精査する。
この変更により、悪意のあるコードを含むアップデートが即座に配信されるリスクが抑えられる。AIによる事前チェックと人間の確認が介在することで、サプライチェーンセキュリティが大幅に強化される仕組みだ。
AI「Gandalf」によるコード監視
24時間の猶予期間におけるレビュー作業を強力に支援するのが、新たに導入されるAIだ。Mullenweg氏はこれを「Gandalf」と名付けられたWapuuだと表現している。
人間のレビューチームは寝る必要があるが、AIにはそれがない。24時間体制でコミットの差分を分析し、不審なコードパターンや既知の脆弱性シグネチャを検出する。Mullenweg氏は、今回のAI技術の進歩がなければ実現しえなかったレビューの深さだと言及している。
なぜいまエコシステムの防御を固めるのか
昨年末から今年にかけて、AIのコーディング能力は飛躍的に向上した。Anthropicが2026年4月に公開したモデル「Mythos」は、その能力の高さと潜在的なリスクで開発者コミュニティに衝撃を与えている。また、Chromeブラウザの最新版が429件ものセキュリティ修正を含んでいたことも、各所のセキュリティ活動を加速させた。
拡大するサプライチェーン攻撃の脅威
ソフトウェアのサプライチェーンを標的とした攻撃は、もはや日常的だ。オープンソースエコシステムにおいても、マルウェアを仕込まれたパッケージが正規のアップデートとして配布される被害が後を絶たない。WordPressコミュニティ内でも、信頼されていたプラグインが悪意ある新しい所有者に売却され、バックドアを仕掛けられた「Essential Plugins」のような事件が発生している。
AIによる攻撃コードの生成能力が向上すれば、この種の脅威はさらに巧妙化し、頻度も増加する。WordPress.orgが今回、エコシステム全体の防衛に乗り出したのは必然だったといえる。
更新速度と安全性のジレンマ
WordPress 7.0のアップグレード率はリリース後わずか2週間で50%を超えた。これは数えきれないほどの開発者とホスティング事業者の協力による成果だ。素早いアップデートの適用は、脆弱性への露出時間を最小化するという点で極めて重要である。
しかし、Mullenweg氏は「2026年は、安全を確保するために可能な限り早く更新するのか、それとも安全を確保するために更新を保留するのか、その緊張が続く年になる」と述べている。急速なコード配布は、攻撃者にとっても好都合な環境になりうる。このジレンマを解消するのが、今回の24時間ルールというわけだ。
WordPressが目指す「透明性によるセキュリティ」
Mullenweg氏は発表の中で「自由とセキュリティはゼロサムではない」という考えを強調した。これは、セキュリティの名の下にパーミッションを厳格化しすぎて、ソフトウェアの自由な流通や改変を妨げることへのカウンターである。オープンソースは、曖昧さによるセキュリティではなく、透明性こそが強固なセキュリティをもたらすことを示してきた。
スケールするレビュープロセス
プラグインレビューチームは献身的に活動しているが、人間の処理能力には限界がある。Mullenweg氏は、現在の24時間という猶予が、AIモデルのさらなる進歩とともに「数分」にまで短縮される可能性に期待を示している。
ひとつのリリースを複数のAIエージェントが並列でレビューし、人間の承認プロセスと連携する。これにより、手動では不可能な精度と速度で、78,000以上のプロジェクトの安全性を担保しようという狙いだ。
4億インストールの重み
WordPress.orgのプラグインディレクトリには、累計で4億を超えるインストールが記録されている。69のプラグインは、100万件以上のサイトにインストールされている。その開発者の多くは個人であり、巨大なコミュニティを構成している。
WordPress.orgはこの多様なエコシステムを守るため、Star数などの表面的な評価だけでなく、実際のコードの安全性に焦点を当てた支援を強化する方針だ。そのための現実的な第一歩が、今回のProtect The Shireである。
この記事のポイント
- WordPress.orgがプラグインとテーマの自動更新に「最大24時間の猶予期間」を導入した
- AI Wapuu「Gandalf」を含む新たなレビューフローにより、サプライチェーン攻撃のリスクを低減する
- この施策は、AIによる高度なコード生成が一般化する時代におけるエコシステム防衛策である
- オープンソースの理念に沿い、透明性を保ったままセキュリティ水準を引き上げる試みだ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIエージェントに独自の権限モデルが必要な理由
“`html
AIエージェントの本番環境導入が急速に進んでいる。カスタマーサポートの自動化を例に取ると、チケット内容の読み取り、返金処理、社内エスカレーション、Slackへの通知まで、ひとつのタスクで複数のツールを横断する。適切に動作すれば、定型業務のコストを大幅に圧縮できる一方、失敗の仕方は従来の自動化とは根本的に異なる。非決定的な挙動を示し、本番権限を丸ごと握ったまま大規模に誤作動しうるからだ。
有用なエージェントには、複数ツールを動的に組み合わせる十分なアクセス権が必要だが、同時に永続的なスーパーユーザー権限で動かすわけにはいかない。開発現場では、長期有効なAPIキーを環境変数に埋め込んだり、人間向けOAuthフローを流用したりといった安易なパターンに陥りやすいが、これらは非決定的なソフトウェアのために設計されたものではない。プロンプトの設定ミスやツール応答の悪意ある操作が、重大なインシデントに直結する。
本記事では、自律システムに最小権限の原則を適用する具体的な方法を解説する。ケイパビリティ単位への権限スコープの絞り込み、実行計画に紐づく短命トークンの発行、アイデンティティと認可と実行のレイヤー分離、そして高リスク操作に対するヒューマンインザループ承認の組み込みが全体像だ。
AIエージェントと従来のアクセス制御のミスマッチ
UIに縛られ予測可能
静的コードパス監査可
開発者が明示的に書いていない連鎖を生成
サブエージェントへの委譲でコンテキストが分散
従来のアクセス制御は対話型ユーザーか決定的なバックエンドサービスのいずれかを前提として設計されている。セッショントークンは対話的なフローを、サービスアカウントは決定的な挙動を想定している。ところがAIエージェントは、同じ入力を与えても実行のたびに呼び出すツールが変わる。開発者はコードとして書いていない連鎖をエージェントが自律的に生み出し、さらにサブエージェントを起動して委譲チェーンが広がる。このような非決定性は、従来の権限モデルが持つ「想定された範囲内」という前提を根底から崩す。
現場で陥りやすい3つのアンチパターン
どれも単体では「とりあえず動かす」ための合理的な選択に見えるが、組み合わさると致命的だ。長期有効なキーなら、エージェントがプロンプトインジェクションで騙されて認証情報を吐き出してしまう可能性がある。ユーザー同等のOAuthスコープでは、サポート担当が本来行使しない管理操作をエージェントが勝手に実行してしまう。スーパーユーザー権限は、一度の誤動作で取り返しのつかない損害を生む。Auth0の記事では、こうしたパターンがいかに簡単に深刻なインシデントへ発展するかが指摘されている。
ケイパビリティスコープで権限を細分化する
問題の根本は「リソース単位」の権限設計にある。従来のbilling:writeはカテゴリと動詞しか表現できず、金額の上限や操作の種類までは規定しない。これに対し、billing.refund.issue_under_50_usdのように「何ができるか」をケイパビリティとして定義すると、ビジネスロジックとアクセス制御が直接結びつく。プロダクトマネージャーが「サポートエージェントは50ドルまでの返金を自動で処理できる」と決めたら、そのルールは認可エンジンが評価する宣言的なポリシーとして管理される。
billing:writebilling.refund.issue_under_50_usdrefund_amount <= agent_limit を評価こうした制約を実装するには、リレーションシップベースアクセス制御（ReBAC）を採用するのが有効だ。Auth0が支援するOSSの認可エンジンOpenFGAでは、エージェントとリソースの関係性をモデル化し、「エージェントがアクティブなチケットを持つ顧客の注文のみ返金できる」といったポリシーを表現できる。さらに条件（Conditions）を組み合わせれば、返金額の上限や期限付きの権限付与といった属性ベースの制約も単一のチェックで評価可能になる。実際のDSLでは、can_refundリレーションにrefund_within_limit条件を付与し、タプル側にエージェントの上限額を保持、リクエスト時に実際の返金額をコンテキストとして渡して判定する。
タスクスコープの認証情報で有効期間を絞る
ケイパビリティスコープが「何ができるか」を定めるのに対し、タスクスコープは「いつまでできるか」を制御する。エージェントに永続的なクレデンシャルを持たせるのではなく、実行計画のたびに短命なトークンを発行する設計だ。トークンは数分で失効し、必要最小限のケイパビリティだけを運ぶ。
Auth0のToken VaultはこのパターンをOAuth 2.0 Token Exchange（RFC 8693）に準拠して実装している。リフレッシュトークンは認可サーバー側に留められ、エージェントには必要に応じてスコープを絞ったアクセストークンのみが渡される。サポートエージェントが返金を実行する際、事前に返金可能なトークンを保持しているわけではない。ランタイムがポリシーを評価し、金額・顧客状態・リレーションシップのすべてを確認した上で、その操作専用のトークンを要求する。タスク間でエージェントが侵害されても、以前のトークンはすでに失効しており、新たな悪用には改めてポリシーチェックを通過する必要がある。
アイデンティティ・認可・実行を3層に分離する
エージェントのアクセス制御を設計する際、「誰か」「何が許されるか」「実際に何が起きるか」の3つを混同しないことが重要だ。これらはしばしば1つの実装に押し込められがちだが、独立したレイヤーとして切り離すことで安全性が格段に向上する。
この分離により、LLMプロセス自体が認証情報を一切持たないアーキテクチャが実現できる。LLMはツール呼び出しを提案するだけであり、ランタイムが実際のAPIコールを代行する。プロンプトインジェクション攻撃で「あなたのクレデンシャルを吐け」と指示されても、LLMにクレデンシャルは存在しない。Auth0のToken VaultやOpenFGAのようなコンポーネントを組み合わせれば、アイデンティティから実行までの各段階で独立した強制が可能になり、仮に1層が突破されても全体が崩壊しない。
高リスク操作には承認境界を設ける
ケイパビリティスコープとタスクスコープを導入しても、金額が一定を超える返金や、不正検知フラグ付き顧客への操作など、許容できないリスクを伴う操作は残る。こうした場面では、人間による明示的な承認を実行の直前に挟む設計が有効だ。これは権限モデルの欠陥を補う緊急避難ではなく、あらかじめ組み込むべき境界線である。
Auth0はこの承認パターンをClient-Initiated Backchannel Authentication（CIBA）規格で標準化している。エージェントのバックエンドがCIBAリクエストを送信すると、ユーザーの登録済みデバイスにプッシュ通知が届く。Rich Authorization Requests（RAR）を併用することで、単なる「請求へのアクセスを許可」ではなく「注文#12345に対する2,000ドルの返金を承認」といった具体的な文脈を伝達できる。承認された場合のみスコープを限定したトークンが発行されるため、エージェントが勝手に高額返金を実行する経路は技術的に閉ざされる。
オブザーバビリティと制御の土台を整える
厳格な権限管理下でも、エージェントは自律的に複数のシステムをまたいで動作する。何が起きたか、なぜその判断に至ったか、誰の代理として動いたのかを追跡できなければ、デバッグもインシデント対応も不可能だ。次の3要素が不可欠である。
- アクションだけでなく、エージェントが辿った意思決定の経緯を監査証跡に残す。どの計画のもとで、どのツール呼び出しが連鎖し、どんなコンテキストが判断材料になったかを記録する。
- ユーザーからサブエージェント、ツール、リソースに至る委譲チェーンを各ホップで明示し、問題発生時に責任境界を特定できるようにする。
- エージェントの暴走が疑われた場合、永続的な許可を即座に無効化し、処理中のトークンを失効させて後続のツール呼び出しを停止できる仕組みを整備する。
Auth0のプラットフォームでは、トークン発行が一元的なコントロールプレーンを経由する。Token Vaultの連携を解除すれば、そのエージェントに対する将来のトークン交換が即座に無効化され、監査ログには全発行・使用の履歴が残る。こうした基盤があることで、エージェントの自律性を損なわずにリスク管理を徹底できる。
この記事のポイント
- AIエージェントには、人間ユーザーや決定的サービスの前提を流用しない、専用のアクセス制御モデルが求められる
- リソースベースの広範なスコープではなく、ケイパビリティ単位で権限を細分化し、宣言的ポリシーとして管理する
- タスクごとに短命なトークンを発行し、エージェントに永続的なクレデンシャルを持たせない
- アイデンティティ・認可・実行の3層を分離し、LLMプロセスに認証情報を一切触れさせないアーキテクチャを採用する
- 高リスク操作にはCIBAやRARを活用した人間承認の境界を組み込み、自律実行の安全域を明確に定義する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
SiteGroundがAIプラグインを強制配信、100万件の自動インストールが引き起こした評価1.1の大炎上
2026年5月末、ホスティングサービス大手のSiteGroundが、100万以上の顧客サイトに対して、AIプラグインを事前の同意なく自動インストールし、自動有効化するという事態が発生した。このプラグインはわずか数日でWordPress公式ディレクトリにおいて1.1という極めて低い評価を記録。100万インストールと最低評価という数字が、単なる機能の問題ではない、深い信頼の危機を物語っている。
一連の騒動は、企業が持つリーチの大きさと、その使い方を誤ったときに発生する信用コストの非対称性を浮き彫りにした。ここでは何が起きたのか、なぜここまで批判が集中したのか、そしてこの出来事がWordPressエコシステム全体に投げかける課題を整理する。
何が起きたのか。同意なき「AI Agent」の一斉配信
問題となったのは「AI Agent by SiteGround」というプラグインだ。機能面だけを見れば、チャットインターフェースを通じてWordPressやWooCommerceを管理し、複数サイトの一括更新なども行える、実用性の高いツールである。だが、その配信方法が全ての火種となった。
ユーザーが自ら検索してインストールしたわけではない。SiteGroundのホスティングを利用している顧客のWordPressサイトに、ある日突然このプラグインが現れ、有効化された状態になっていたのだ。運営者が気づかぬうちに、外部のAIサービスと連携する準備が整えられたソフトウェアが設置されていたことになる。
この事実が発覚するや否や、WordPressのプラグインレビュー欄は非難の声であふれた。「自動インストールは大きな過ちだ」「なぜ同意なしにインストールしたのか」「ひどい、そして deceptive だ」「もうSGのファンではない」。わずか数日のうちに35件の星1レビューが投稿され、星5はわずか1件という異様な状況が生まれた。
Redditでも同様の議論が巻き起こった。あるユーザーが「WARNING – SiteGround just put some AI plugin into every single site」と題したスレッドを立ち上げ、社内で誰がこのプロジェクトを承認したのかと疑問を呈したのだ。
「安全でオプションです」という説明が響かなかった理由
批判を受けてSiteGroundは迅速に対応し、Redditやサポートフォーラムで直接説明を行った。彼らの弁明はこうだ。このプラグインはWordPress 7.0の新しいAIフレームワークへの準備として追加されたものであり、顧客がコネクタやAPIキーを手動で設定する手間を省くための措置だった。プラグインはバックグラウンドで何かをするわけではなく、ユーザーが能動的に使わない限りサイトに影響を与えず、いつでも無効化または削除できる。事前にメールでも通知したという。
技術的には、この説明に誤りはないかもしれない。しかし、この釈明は根本的な怒りのポイントを外していた。WP Mayorの記事によれば、ユーザーが懸念していたのは「プラグインが密かにサイトを破壊するかもしれない」という技術的リスクよりも、もっと大きな原則論だった。自分が選んでいないソフトウェアを、自ら責任を負うインフラに勝手に置かれたこと、その行為自体への反発なのだ。
Redditの投稿者が指摘したように、たとえ自分がそのAI機能を使わなくとも、顧客が管理画面でそれを見つけて興味本位で操作を始めてしまうリスクがある。機能の説明で「信頼」に対する異議に答えることはできない。「頼んでないのに何故入れたのか」という不満に対し、「安全だしオプションです」と返しても、相手の懸念を全く理解していないことを表明するに等しい。
→ これは機能の問題ではなく、関係性の問題。
→ 「頼んでない」という根本的懸念には何も答えていない。
格付けが示すもう一つの不公正
この騒動には、もう一つ見逃せない副次的影響がある。WordPress公式プラグインディレクトリで「AI agent」と検索すると、このAI Agent by SiteGroundが上位3位に表示される。星1.1という散々な評価でありながら、何百もの競合プラグインを押しのけて、だ。
WordPress.orgのディレクトリ検索は、アクティブインストール数をランキングの重要な要素として扱っている。通常、これはユーザーがプラグインを見つけ、気に入り、自らの意思でインストールした結果を反映するものだから理にかなっている。しかし、ホスティング事業者が100万件ものインストールを一晩で「製造」できてしまうなら、その前提は崩壊する。
WP Mayorの記事では、運営者自身が開発するプラグインが10万インストールに到達するまでに何年もかかった経験が引き合いに出されている。地道に一人ひとりのユーザーを獲得して可視性を高めてきた独立系開発者にとって、この出来事はフェアとは言い難い。評価1.1のプラグインが、そうした開発者の努力を数日で飛び越え、ランキング上位に躍り出た。これはSiteGroundだけの問題ではなく、WordPress.orgディレクトリのランキングシステムが抱える構造的な脆弱性も浮き彫りにした。
他社が学ぶべき「絶対に守るべき三つのルール」
今回の出来事は、ホスティング事業者やプラグイン開発者が顧客との関係で決して踏み越えてはならない一線を教えている。
第一に、すべてはオプトインであるべきだ
顧客のサイトに影響を与える変更のデフォルトは、常に「同意を得る（オプトイン）」でなければならない。「拒否しなければ同意とみなす（オプトアウト）」方式は、あなたがすでに顧客の許可を持っているという前提に立っており、その差は顧客に即座に感じ取られる。
第二に、「技術的に通知した」は同意ではない
「何日前にメールを送ったはずだ」という類の抗弁は、同意の証明にはならない。ユーザーがその一通のメールを見ていることを前提とした通知戦略は、同意ではなく「記録」に過ぎない。両者は全くの別物であり、顧客はその違いをよく知っている。
第三に、リーチとは責任であり、ただの利便性ではない
100万サイトに一斉配信できる能力は、巨大な信託の上に成り立っている。それを単なる「配信ショートカット」として扱い始めた瞬間、そのリーチを可能にしていた信頼そのものを食いつぶし始めている。
WP Mayorの記事は、ロードマップ会議で「いかに摩擦なく導入させるか」という議論がなされると、ときにこの原理が忘れられてしまうと指摘する。摩擦のない導入と、同意の尊重はしばしば対立する。そして対立したときは、必ず同意が勝たねばならない。同意こそが、レピュテーションの素材だからだ。
SiteGroundは信頼を回復できるか
フェアな視点で言えば、この状況はまだ立て直しが可能だ。SiteGroundが自動インストールを停止し、真にオプトイン方式へと切り替え、さらに「ロールアウトは間違いだった」と明言すれば、関係は修復に向かう。しかし、「ご意見は製品チームに転送されました」といった、問題を管理するための企業言語でやり過ごそうとすれば、事態は悪化するだけだろう。
顧客は、自分たちが間違っていたと認める企業を、正しかったと説明し続ける企業よりもはるかに早く許すものだ。人々がこれほど怒っているのは、まさにSiteGroundに「もっと良い対応」を期待していたからに他ならない。その期待自体は、まだ彼らに残された修復可能な資産なのである。100万という数字も、もしそのうちの一つでも「選択」の結果だったなら、全く異なる意味を持っていたはずだ。
この記事のポイント
- SiteGroundが100万件以上の顧客サイトにAIプラグインを事前同意なく自動インストールし、評価1.1の大炎上を招いた
- ユーザーの怒りは機能の安全性ではなく「同意なく自サイトにソフトウェアを置かれた」という信頼の毀損に集中した
- この強制配信により、WordPress公式ディレクトリのランキングシステムが持つ構造的な不公正も露呈した
- 顧客のデジタル資産に触れるあらゆる行為はオプトインが原則であり、「通知」は「同意」の代わりにはならない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WPプラグインのサプライチェーン攻撃、AIで見えてきた隠れた脅威
WordPressプラグインのサプライチェーン攻撃が急速に広がっている。悪意ある攻撃者がプラグイン企業を買収し、あるいは正規のプラグインを乗っ取り、無防備なサイトへマルウェアを配信する手口だ。従来の「サイトを直接ハッキングする」という攻撃とはまったく異なるレイヤーで、静かに進行する。
Anchor Hostingの創業者であるAustin Ginder氏は、WP Tavernのポッドキャストでこの問題の全容を語った。同氏は2010年からWordPressに関わり、現在は数千のWordPressサイトを管理している。2026年に入り、長年安定していた顧客サイトでマルウェアが頻出するようになったことを受け、AIを駆使した徹底調査を開始した。
調査の結果、明らかになったのは単なる脆弱性の話ではない。正規のプラグイン更新チャンネルそのものが攻撃者に乗っ取られているという、構造的な脅威だ。本記事ではその仕組み、具体的な被害事例、そしてAIによって変わりつつあるセキュリティ対策の最前線を解説する。
サプライチェーン攻撃の実態（2つの侵入経路）
この図はサプライチェーン攻撃の2大経路を示している。いずれも、ユーザーが自動更新を有効にしている場合、まったく気づかずに感染する点が共通している。WP Tavernのポッドキャストで語られた内容を整理すると、攻撃者はこうした手法でプラグインを「武器化」し、正規更新を装いながらマルウェアを拡散している。
プラグイン買収による攻撃
WP TavernのポッドキャストでAustin Ginder氏が明かした最も衝撃的な手口は、攻撃者が実際にプラグイン企業を買収して武器化するというものだ。同氏はEssential Pluginsと呼ばれる30以上のプラグインを抱えるパッケージが売却され、その後にコード改変が行われた事例を報告した。
攻撃者は6桁の金額を投じてでも正規の配信チャンネルを手に入れる価値があると判断している。プラグインを買収すれば、更新ボタンを押すだけで何万ものサイトにコードを配信できるからだ。この手法の巧妙な点は、プラグインの本来の機能はそのまま維持されることである。ユーザーは見た目の変化に気づかない。
プラグインハイジャックによる攻撃
もうひとつの経路は、プラグインの更新先をすり替えるハイジャック型だ。攻撃者はまず正規のプラグインにサードパーティのアップデータを密かに組み込む。これはwordpress.orgのガイドライン違反だが、コードを巧妙に隠すことで審査をすり抜ける。
一度このコードが仕込まれると、以降の更新はwordpress.orgではなく攻撃者の管理するサーバーから配信される。wordpress.org側からは一切の可視性が失われ、ユーザーのサイトは知らぬ間に乗っ取られた状態になる。この手口は特に長期間気づかれにくく、過去にQuick Redirectionプラグインなどで実際に確認されている。
偶然のマルウェア除去から始まった調査
Austin Ginder氏がこの問題に気づいたのは、2026年2月に顧客サイトのマルウェア除去作業を行っていたときのことだ。同氏はWP Tavernのポッドキャストで「長年安全だったサイトが突然マルウェアに感染するようになった」と振り返っている。
従来のマルウェア除去は不安がつきまとう作業だった。ファイルをひとつずつ確認し、疑わしいコードを取り除いても、本当にすべてを取り切れたか確信が持てなかった。しかし同氏は、AIを使うことで状況が一変したと語る。AIがすべてのファイルを精査し、感染経路の特定から根本原因の解明までを一貫して行えるようになったのだ。
ある顧客の調査で行き着いた先はwordpress.orgのリポジトリだった。同氏はAIを使い、問題のプラグインの変更履歴を解析した。すると、正規の更新チャンネルが改ざんされている痕跡が見つかった。ここから本格的な調査が始まった。
以降、同氏は4件の詳細な調査レポートを公開した。いずれも異なるプラグイン、異なる攻撃者によるものだった。最初の1件が単発の事件ではなかったことが、ここで明らかになった。
AIが切り拓く新たな脅威検出
ファイル単位の徹底監査
Austin Ginder氏はAIの活用について、WP Tavernのポッドキャストで具体的な方法を説明している。同氏は月額200ドルのClaude Codeサブスクリプションを使い、顧客サイトの全ファイルを1行ずつ監査している。これは人間には不可能な作業量だが、AIなら数十万行のコードを短時間で精査できる。
「1バイトの変更も見逃さない」と同氏が語るこの手法は、静的解析の域を超えている。AIはコードの文脈を理解し、単なるシグネチャマッチングでは検出できない巧妙なバックドアも特定する。あるケースでは、一見無害に見えるJavaScriptの埋め込みコードから、クレジットカードスキマーの存在を突き止めた。
バリアント検出ツールの実装
さらに同氏は、プラグインのバージョン差異を検出する独自ツールをAIで構築した。これは、インストールされているプラグインのコードがwordpress.org上の正規バージョンと異なっていないかを自動照合する仕組みだ。
このツールのテスト中、Quick Redirectionプラグインのバリアント版が12サイトで稼働していることを発見した。本来の作者が意図せず（あるいは意図的に）、多くのユーザーをハイジャック版へ誘導していた事例だ。さらに、上位2000のWordPressサイトをスキャンした際には、Scroll To Topプラグインに不正コードが仕込まれているのを確認した。このプラグインは2万サイトにインストールされていたが、攻撃者はまだ「引き金を引いておらず」、被害が表面化する前に発見できたという。
AIによる監査は、コードの意味を解釈しながら異常を浮かび上がらせる。従来のシグネチャベースでは見逃していた「まだ発動していない攻撃コード」も、文脈の不自然さとして検出できる点が最大の強みだ。
過去13年間活動を続ける攻撃者の発見
Austin Ginder氏はWP Tavernのポッドキャストで、13年にわたって活動を続けている攻撃者の存在にも言及した。この攻撃者は、何度アカウントやプラグインを閉鎖されても、新しいアカウントを作り直し、別のプラグインで同じ手口を繰り返してきた。
「彼らを止めるには、単にコードを修正するだけでは足りない」と同氏は語る。攻撃のインフラそのものを無効化し、再発を防ぐ仕組みが必要だ。AIによる大規模監査が、こうした長期化する脅威への対抗手段として期待されている。
WP Beaconが目指すコミュニティの連携
Austin Ginder氏は、調査結果を共有するプラットフォームとして「WP Beacon（wpbeacon.io）」を立ち上げた。これは従来の脆弱性データベースとは異なり、サプライチェーン攻撃に特化した情報を集約する場である。既存の脆弱性DBが「コードの欠陥」に注目するのに対し、WP Beaconは「悪意ある行為者」そのものの行動パターンを記録する。
同氏はWP Tavernのポッドキャストで、WP Beaconの真の目的は「セキュリティ研究者やホスティング企業が行動を起こすための情報基盤」になることだと述べた。実際、同氏が発見した攻撃者のサーバーは、協力者の手によってドメイン停止措置が取られたという。調査と対策を分業し、攻撃インフラを迅速に無力化する流れを作ることが狙いだ。
今後の対策と個人でできること
Austin Ginder氏はWP Tavernのポッドキャストの中で、個人でもすぐに実践できる対策として、自サイトのバックアップをAIで監査する方法を提案した。Claude Codeなどのツールにサイトの全ファイルを読み込ませ、「すべての行をチェックし、脆弱性やマルウェアの痕跡を報告してほしい」と指示するだけでも、高い精度の分析結果が得られるという。
「我々はデータの上に座っているが、それを使いこなせていない」と同氏は指摘する。大手ホスティング企業が保有する数百万サイト分のデータをAIで横断分析できれば、攻撃パターンの早期発見と封じ込めが可能になる。WP Beaconがそうした連携の起点となることが期待されている。
長期的には、プラグインの全コード監査を自動化し、変更が発生するたびにAIがチェックを行う仕組みが必要だ。wordpress.orgのリポジトリには6万以上のプラグインが存在するが、CSSや画像ファイルを除外し、PHPやJavaScriptの変更だけを対象にすれば、現実的な範囲でカバレッジを確保できる。
この記事のポイント
- WordPressプラグインのサプライチェーン攻撃は、買収とハイジャックの2経路で進行する
- ユーザーは自動更新を通じて、まったく気づかずにマルウェアを受け取る可能性がある
- AIを使った全ファイル監査で、従来の方法では見逃していた潜伏型の脅威も検出できる
- WP Beaconはサプライチェーン攻撃に特化した情報基盤として、コミュニティ連携を促進する
- 個人でもClaude CodeなどのAIツールで自サイトの監査を実施できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0リリースとAI管理ツール最新動向 2026年5月
WordPressエコシステムに大きな動きがあった。2026年5月末、待望のWordPress 7.0「Armstrong」が正式リリースされたのだ。管理画面の刷新やAI機能の統合が実装され、次世代サイト運営の基盤が整った。
これと同時に、AIを駆使した管理ツールも相次いで発表されている。サイト翻訳、スパム対策、アナリティクス対話、自動化まで、もはや手動運用の時代は終わりつつある。WPBeginnerの2026年5月Spotlight記事は、これらの新製品群とコミュニティ動向を詳細に報じた。
WordPress 7.0 Armstrongのリリース
WordPressコアチームは2026年5月、バージョン7.0「Armstrong」を公開した。このリリースは、管理画面のデザイン刷新とAI機能のネイティブ統合が最大のトピックだ。リアルタイム共同編集は今回見送られたが、AIコネクタの導入だけでも近年で最も大きなアップデートの一つと評価されている。
カラースキームは固定で、視認性が悪い部分も
新しいカラースキームで視認性が向上
AIコネクタ 搭載で全プラグインからAI APIキーを一元管理
このデモでは、管理画面の変化を概念図として示している。実際のバージョン7.0では、ページ読み込み速度が大幅に改善し、操作フィードバックが即時になった。
AIコネクタとサイトエディタの強化
AIコネクタは、サイト全体でAI APIキーを一箇所に登録できる仕組みだ。これにより、各プラグインが個別にAPIキーを要求する必要がなくなり、一貫したAI機能の提供が可能になった。ユーザーはOpenAIや他のAIプロバイダーのキーを設定画面で一度入力するだけで、対応プラグイン全体がそのキーを利用できる。
ブロックエディタにも大幅な改善が加わった。具体的には、個別ブロックへのカスタムCSS追加、デバイスごとのブロック表示・非表示制御が可能になった。これらの機能は、モバイル、タブレット、デスクトップそれぞれに最適化した表示を簡単に設計できることを意味する。正式リリースに先立ち公開されたベータ版の情報を追っていたユーザーからは、特にこの柔軟性に対して高い期待が寄せられていた。
AI翻訳ツールUniversallyの登場
多言語サイトを手軽に実現したいが、従来の翻訳プラグインはデータベース肥大化やパフォーマンス低下を招きやすい。SaaS型の翻訳サービスは高価で、個人事業主や中小企業には手が出せなかった。このような課題に対し、AI搭載のウェブサイト翻訳プラットフォーム「Universally」が登場した。
✕ パフォーマンス低下や複雑な設定が必要
✓ hreflangタグやXMLサイトマップなど多言語SEO最適化
無料プラン あり（1サイト、1言語、月2,000語）
Universallyはデータベースに翻訳データを保存しないクラウド型アーキテクチャを採用し、サイトパフォーマンスを維持したまま多言語化できる。AI用語集機能により、ブランド名や専門用語の誤訳も防ぐ。プライベートベータ段階で既に2億5,000万語以上の翻訳実績があり、WordPress以外にShopifyやWix、Replitなどにも対応する。有料プランは年払いで月額7.5ドルから利用可能だ。WPBeginnerの創設者による詳細な紹介記事も掲載されている。
AIスパム対策ActiveLayerとCAPTCHAフリーの保護
WordPressサイトのコメントやフォームへのスパム攻撃は、今なお運営者の大きな悩みだ。従来のCAPTCHAは人間のユーザーにもストレスを与え、フォーム離脱の原因にもなり得る。WPBeginner創設者のSyed Balkhi氏が公開した新サービス「ActiveLayer」は、AIを使いミリ秒単位でサーバーサイド分析を行い、CAPTCHAなしでスパムをブロックする。
フォーム離脱率が上昇し、コンバージョンに悪影響
信頼度スコア でスパム判定を可視化
WPForms、Gravity Forms、Contact Form 7など主要フォームプラグイン対応
ActiveLayerのWordPress.org版プラグインは無料で、月1,000回の無料スパムチェックが含まれる。有料プランは月額4ドルからで、無制限のサイトとフルAPIアクセスを提供する。WPBeginnerやその他のビジネスサイトで発生した大規模スパム攻撃への対処経験が、このサービスの開発背景にある。
StellarWPブランド終了とプラグイン再編
Liquid Webは、GiveWPやLearnDash、SolidWP、The Events Calendarなどを含む「StellarWP」ブランドの終了を正式発表した。これらは新設された「Liquid Web Software」に統合され、Kadence、LearnDash、The Events Calendar、Giveの4製品を中核に据える方針だ。
WPBeginnerの記事によれば、この統合により、長期ユーザーからは将来のロードマップや価格変更、製品の独立性について懸念の声が上がっている。特に複数のStellarWP製品に依存しているサイト運営者は、自動更新設定やバックアップ戦略を今のうちに見直しておくべきだ。
Uncanny AgentやCharlie ChatなどAI管理ツールの台頭
WordPress管理の手動作業を減らすAIエージェントが相次いで登場している。Uncanny Automatorチームが開発した「Uncanny Agent」は、ダッシュボード内に統合されたAIアシスタントだ。自然言語で問い合わせると、WooCommerceの売上データやユーザー活動のレポート作成、フォーム送信時のSlack通知自動化などを対話形式で設定できる。
一方、MonsterInsightsが公開した「Charlie Chat」は、Google Analyticsのデータを平易な言葉で問い合わせられるAIアシスタントだ。「主要なトラフィックソースは？」「どのコンテンツを更新すべきか？」といった質問に、実際のGA4データを基に即答する。無料のLite版でも利用可能で、WooCommerceストア向けには売上傾向やカゴ落ち分析も行える。
これらに加え、WPFormsはKlaviyoとのネイティブ連携アドオンを公開し、メールマーケティングのROI向上を狙う。SeedProdはWordPress Abilities APIに対応し、AIコマンドでランディングページの更新やメンテナンスモード切替を可能にした。無料のAIチャットボットHelpJetは、既存のサイトコンテンツを数分で学習し、24時間カスタマーサポートを提供する。WPBeginnerのSpotlight記事は「AI管理ツールの波がWordPressエコシステムを一変させつつある」と総括している。
この記事のポイント
- WordPress 7.0 Armstrongがリリースされ、管理画面刷新とAIコネクタが導入された
- AI翻訳ツールUniversallyは、クラウド型で110言語以上に対応し、パフォーマンス低下を回避する
- AIスパム対策ActiveLayerは、CAPTCHA不要で主要フォームプラグインと統合できる
- StellarWPブランド終了に伴い、依存プラグインの長期運用戦略を見直す必要がある
- Uncanny AgentやCharlie Chatなど、AIによる対話型管理ツールが続々と登場している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
DockerのCopy Fail脆弱性対応とseccomp破壊の教訓
2026年4月末に公開されたLinuxカーネルの脆弱性CVE-2026-31431、通称「Copy Fail」は、2017年以降のほぼ全てのカーネルに影響する深刻な問題だ。Docker社はこの脆弱性に対し、コンテナランタイムレベルでの緩和策を急ピッチで提供した。
その過程で、Docker Engine v29.4.2の修正が32ビットバイナリのネットワーク機能を完全に破壊するという予期せぬ副次的被害を引き起こした。本記事では、この一連の対応と教訓を技術的に深掘りする。
コンテナ運用者は、カーネルパッチの適用が最優先だが、それが叶わない場合でもDocker Engineのアップデートによりリスクを大幅に低減できる。ここで得られた知見は、今後のコンテナセキュリティ対策における多層防御の重要性を浮き彫りにしている。
Copy Fail脆弱性の仕組みとリスク
AF_ALGサブシステムの欠陥
Copy Failは、Linuxカーネルの暗号処理をユーザー空間から利用するためのAF_ALG（Algorithm Sockets）サブシステムに存在する。具体的にはalgif_aeadモジュールの不具合により、特権のないプロセスがページキャッシュに対して不正な書き込みを行える状態になっていた。
ページキャッシュとは、ファイルの読み取りデータをメモリ上に一時保存する仕組みだ。全プロセスが参照するため、ここを汚染されると、システム全体でファイルの内容が改ざんされて見える可能性がある。最も直接的な攻撃経路は、setuidバイナリ（実行時に高い権限で動作するプログラム）の改ざんによる権限昇格である。
この脆弱性の深刻さは、その単純さにある。PoC（概念実証コード）はきわめて簡潔で、カーネルがパッチされていない限り、2017年以降のあらゆるバージョンで動作する。攻撃が成功すると、コンテナ内からホスト全体、そして同じノード上の他コンテナにまで影響が及ぶのだ。
このデモが示す通り、脆弱なカーネルでは攻撃者に一直線のルートを提供してしまう。Dockerの役割は、コンテナランタイムのレイヤーでこの経路を物理的に塞ぐことだった。
コンテナ環境への影響範囲
Dockerのデフォルトセキュリティプロファイルでは、コンテナからのAF_ALGソケット作成が許可されていた。つまり、攻撃者が何らかの方法でコンテナ内でコードを実行できた場合、この脆弱性を利用してホストのroot権限を奪取できる状態にあった。
さらに悪いことに、ページキャッシュはホスト全体で共有される。攻撃が成功した場合、被害はそのコンテナ内に留まらず、同じDockerイメージのレイヤーを共有する他のすべてのコンテナにも波及する。これは、マルチテナント環境やマイクロサービスを密に配置しているノードでは壊滅的な被害につながりかねない。
Docker Engineの対応と失敗の分析
v29.4.2 seccomp修正の試み
Dockerチームは当初、seccomp（Secure Computing Mode / セキュアコンピューティングモード）プロファイルの更新で対応しようとした。seccompは、コンテナが発行できるシステムコールをフィルタリングする仕組みだ。具体的には、socket()システムコールの第一引数を検査し、AF_ALGアドレスファミリが指定された場合に拒否するルールを追加した。
しかし、x86_64 Linuxにはsocketcall()という古い多重化システムコールが存在する。これはsocket()やbind()などの複数のソケット操作を一つのシステムコール番号の背後にまとめたものだ。問題は、socketcall()では実際の引数（アドレスファミリを含む）がユーザー空間の配列にパックされ、そのポインタが渡されることだ。seccompのフィルタエンジンであるBPFは、このポインタ先を参照して検査できない。
つまり、seccompだけではsocketcall()経由のAF_ALGを選択的にブロックできない。やむを得ずDockerチームは、socketcall()全体を拒否するという決断を下し、v29.4.2をリリースした。
この比較が示すのは、セキュリティ対策における粒度の重要性だ。全体をブロックすれば安全だが、システムの機能を破壊する。真に効果的な対策は、悪意のある操作だけをピンポイントで無効化することにある。
32bitバイナリ破壊の実態
socketcall()の一律拒否は、思わぬ大規模な副次的被害を引き起こした。32bit版のglibcは、すべてのソケット操作をsocketcall()経由で行う古いバージョンが残っている。Go言語のランタイムも、GOARCH=386でビルドされたバイナリでは無条件にsocketcall()を利用する。さらに、SteamCMDやWineといったレガシー・ゲーミング系のワークロードも、この仕組みに依存している。
これは単なるi386（32bit）の問題ではない。amd64環境であっても、プロセスはint $0x80命令を使うことでia32互換モードに切り替わり、直接socketcall()を呼び出せる。つまり、64bitのコンテナやバイナリを使っていても、この経路を利用される可能性があるのだ。
結果として、v29.4.2へのアップグレード後に多数の32bitアプリケーションがネットワークに接続できなくなるというインシデントが発生した（GitHub Issue: moby/moby#52506）。セキュリティパッチが新たな機能不全を引き起こすという、運用者にとって最も避けたいシナリオが現実となった。
根本原因：seccompの限界
この問題の本質は、seccompがシステムコール境界でのみ動作する点にある。socketcall()は一つのシステムコール番号の背後に多種の操作を隠蔽する。seccompのフィルタは、その中身である配列のポインタ先を解析できない。これが、seccomp単独では対応できない構造的な限界だ。
Dockerのブログ記事の著者は、「seccompはsocket(AF_ALG)をすべてのシステムでブロックするが、socketcall()に対しては盲目だ」と端的に表現している。この「見えない経路」の存在が、多層防御の必要性を強く示す教訓となった。
v29.4.3 LSMベースの恒久対策
AppArmorとSELinuxによる多層防御
v29.4.3では、より根本的な解決策としてLinuxセキュリティモジュール（LSM）を活用する方針に切り替えた。AppArmorとSELinuxは、カーネル内部のsecurity_socket_create()コールバックに直接フックする。このコールバックは、socket()経由であれsocketcall()経由であれ、カーネルが実際にソケットオブジェクトを生成する瞬間に必ず呼ばれる。システムコールの入り口ではなく、より深いレベルで制御を行うのだ。
具体的な実装として、AppArmorプロファイルには deny network alg, というルールが追加された。これはAF_ALGアドレスファミリだけを対象に拒否する。SELinux環境向けには、すべてのcontainer_domainタイプに対してalg_socketの作成を拒否するCIL（Common Intermediate Language）ポリシーモジュールが提供され、semoduleコマンドでロード可能だ。
対策の全体像と適用優先度
v29.4.3の防御スタックは、以下の3層で構成されている。seccompによる直接のsocket(AF_ALG)ブロックは防御の一層目として維持しつつ、AppArmorまたはSELinuxによってsocketcall()経由の抜け道を塞ぐ。これにより、どちらか一方の防御層が無効化されても、もう一方がカバーする体制を実現した。
ただし、AppArmorやSELinuxはホストの設定に依存するため、LSMが有効化されていない環境ではsocketcall()経路が無防備なままとなる。この点については、依然としてカーネルパッチが唯一の完全な解決策であることに変わりはない。
このステップを踏むことで、カーネルパッチの提供を待つ間のリスクを段階的に低減できる。最優先はカーネル修正だが、それが叶わない状況でもDocker Engineの更新だけで強固な緩和策となる。
コンテナセキュリティのための実践的教訓
ランタイム更新のスピードが生む防御力
Copy Failのケースで特筆すべきは、脆弱性の詳細が公表された時点で、主要ディストリビューションの多くはカーネルパッチを提供できていなかった点だ。Ubuntuは記事執筆時点で未対応であり、DebianやRHEL 9が対応を発表した段階だった。この数日間のギャップにおいて、コンテナランタイムの更新は唯一の実用的な緩和策だった。
コンテナ運用においてDocker Engineを最新に保つことは、単なる機能向上のためではない。カーネル脆弱性の公開からパッチ適用までの「空白期間」を埋める、最も迅速な防御手段の一つなのだ。
多層防御の絶対的必要性
このインシデントは「単一の防御層に頼ることの危険性」を端的に示した。seccompは強力だが、システムコールの粒度でしか制御できない。AppArmorやSELinuxはカーネル内部のオブジェクト生成にフックするため、より精密な制御が可能だが、ホストOSの設定に依存する。両者を組み合わせることで初めて、互いの死角を補完できる。
また、v29.4.2のsocketcall()拒否が引き起こした互換性問題は、セキュリティと互換性のトレードオフの難しさを教えている。広範なブロックは新たな問題を生む。可能な限りピンポイントな制御を追求し、やむを得ず広範な制限をかける場合は、その影響範囲を事前に十分評価する必要がある。
この比較から得られる教訓は明確だ。セキュリティ対策は、異なるレイヤーで相互に補完し合う設計が必須である。一つの仕組みで完璧を目指すのではなく、それぞれの得意領域を理解し、弱点を他の層でカバーする。これこそがコンテナセキュリティの基本原則である。
この記事のポイント
- CVE-2026-31431はAF_ALGソケットを悪用し、2017年以降のLinuxカーネルに影響する
- Docker v29.4.2のseccomp修正は32bitバイナリのネットワークを破壊する副次的被害を起こした
- v29.4.3ではAppArmorとSELinuxを組み合わせた多層防御で選択的なAF_ALG遮断を実現
- カーネルパッチが最も確実な修正だが、エンジン更新が迅速な緩和策として有効
- 単一防御層の限界を認識し、複数の技術で死角を補完する設計が今後の鉄則となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Supabaseプロジェクトをnpmサプライチェーン攻撃から守る7つの防御策
npmエコシステムを狙ったサプライチェーン攻撃が2026年に相次いでいる。5月には、TanStackがGitHub Actionsのワークフローキャッシュを汚染され、正規リリースに悪意あるコードが混入する事件が発生した。Supabaseも同様に、supabase-javascriptというタイポスクワット（入力ミスを狙った偽装パッケージ）がnpm上に現れるなどの標的に遭っている。
同社はこの事態を受け、プロジェクトの保護に向けた社内横断の対応を開始し、誰もが参照できる公式ガイドを公開した。本記事では、そのガイドの中核を抜粋し、攻撃の構造と開発者が今すぐ実施すべき防御策を具体的に解説する。
npmサプライチェーン攻撃の3つの典型的な手口
サプライチェーン攻撃は、直接システムに侵入するのではなく、開発者が信頼しているパッケージに悪意あるコードを忍び込ませる。以下が最も一般的な三つの手口だ。
メンテナの認証情報を奪う「アカウント乗っ取り型」
攻撃者がnpmの公開トークンを盗むか、メンテナをフィッシングして乗っ取り、人気パッケージの新版に悪意あるコードを仕込んで公開する。次にnpm installを実行すると、その悪質なバージョンが導入されてしまう。
入力ミスを誘う「タイポスクワッティング型」
本物のパッケージ名から数文字だけ変えた類似名でパッケージを登録し、開発者やAIコーディングエージェントが誤ってインストールするのを待つ。Supabaseの例では、@supabase/supabase-js ではなく supabase-javascript というスコープなしの名前で公開された。AIエージェントがパッケージ名を幻覚（ハルシネーション）して提案することも多く、この手法は脆弱だ。
ビルドパイプラインを悪用する「CI/CD侵害型」
この手口は、GitHub ActionsなどのCI/CDパイプラインの脆弱なワークフローを突く。攻撃者はフォークしたプルリクエストからワークフローのキャッシュを汚染し、次回の正規リリース実行時にそのキャッシュを拾わせて、正規メンテナの署名で悪意あるコードを公開させる。TanStackを襲った攻撃がまさにこれで、セッションメッセンジャーネットワーク経由で機密情報が流出した。
いずれの手口も、npm install の完了までに環境変数やAWSメタデータ、SSH秘密鍵といった機密情報を根こそぎ奪われる危険がある。
Supabaseが実施するプロジェクト防御策
Supabaseはこの問題に対し、全社的な対応を開始した。以下が現在進行中の主な取り組みである。
公式セキュリティガイドの公開
同社は、npmセキュリティに関する推奨事項をまとめた単一の正規ガイドページを公開した。エージェントが読み取り可能な形式で、具体的なアクションを指示している。
GitHub Actionsの安全性強化
組織全体で pull_request_target の使用を精査し、アクションのバージョン参照をコミットSHAに固定する強制ルールの適用が最終段階に入っている。
クレデンシャル関連APIへの警告注釈
createClient などの関数にTSDoc（TypeScript向けドキュメントコメント）を追加し、エディタ上でホバー時に機密情報を扱う旨の警告が表示されるようにした。
全チャネルでの啓蒙活動
顧客かどうかを問わず、できるだけ多くの開発者に防御策を届けるため、ブログやコミュニティを通じた情報発信を強化している。
依存関係管理の厳格化
以下に挙げる設定変更は、いずれも数分で完了する。どれか一つでは完全な防御にはならないが、複数積み重ねることで攻撃者が諦めるほどの障壁を築ける。
パッケージマネージャを最新にして公開遅延を設定する
pnpm 11（またはnpm v11相当）にアップグレードし、minimumReleaseAge をデフォルトの24時間より長く設定する。多くの悪意あるパッケージはリリース後24〜48時間以内に検出され削除されるため、3〜7日の遅延を設けると、被害を受ける確率を大幅に下げられる。
# pnpm-workspace.yaml または .npmrc
minimumReleaseAge: 4320 # 分単位、3日依存バージョンを固定する
^ や ~ による範囲指定は、npmに対して「次のマイナーやパッチを自動的に取り入れて問題ない」と伝えているに等しい。認証情報やネットワーク通信を扱うパッケージでは、必ず正確なバージョン番号を指定しよう。
"dependencies": {
"@supabase/supabase-js": "^2.39.0",
"axios": "~1.6.0"
}"dependencies": {
"@supabase/supabase-js": "2.39.0",
"axios": "1.6.2"
}ロックファイルをコミットし差分を精査する
pnpm-lock.yaml や package-lock.json は、インストールされた正確なバージョンとハッシュを記録する。攻撃者が同じバージョン番号で悪意あるtarballを差し替えても、ハッシュが一致せずインストールが失敗する。ロックファイルをリポジトリにコミットし、プルリクエストの差分では目的不明な依存関係の変更がないか必ず確認する。
不用なインストールスクリプトを無効化する
サプライチェーン攻撃のペイロードの多くは、preinstall install postinstall といったライフサイクルスクリプトを通じて実行される。ネイティブコードを含むパッケージを必要としないプロジェクトでは、これらをグローバルに無効化する。npmでは npm config set ignore-scripts true または .npmrc に ignore-scripts=true を記述する。pnpmではAllow Buildsモデルを使って、実際に必要なパッケージだけを許可リストに登録する。
安全なパッケージ導入のための実践
パッケージ名を毎回検証する
タイポスクワッティング対策として、以下の点をインストール前に必ず確認する。
- スコープが正しいか。Supabase公式パッケージはすべて
@supabase/配下にある。 - メンテナの一覧が期待通りか。長年維持されてきたパッケージに新しいメンテナが突然加わっていれば警戒信号だ。
- ダウンロード数とリンク先のGitHubリポジトリが、本物のパッケージとして妥当であること。
CI/CDワークフローを狙った攻撃への対策
ActionsをコミットSHAで固定する
ワークフローで参照するサードパーティアクションは、タグではなくコミットの完全なSHAハッシュ（40文字）で固定する。タグは攻撃者が新しいコードで置き換えられるため安全でない。
- uses: actions/checkout@1f9a0c22da41e6ebfa534300ef656b67ce0c5b94 # v6.0.2pull_request_target の危険な使い方を回避する
pull_request_target イベントは、プルリクエストのコードをチェックアウトして実行するコンテキストで使うと、攻撃者がリポジトリのシークレットやキャッシュにアクセスできてしまう。TanStackを襲った攻撃はまさにこのパターンだった。PRのコードに触れる処理は必ず pull_request を使用し、pull_request_target はラベリングやコメント投稿など、コードを実行しない信頼済み操作に限定する。
on:
pull_request_target:
types: [opened, synchronize]
jobs:
build:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}on:
pull_request:
types: [opened, synchronize]
jobs:
build:
- uses: actions/checkout@v4インシデント発生時の即応策
クレデンシャルのローテーションと監査
もし疑わしいパッケージを含む環境で npm install を実行してしまったら、そのマシンを危殆化したと見なし、到達可能なすべての認証情報（AWS、GCP、Kubernetes、Vault、GitHub、npm、SSH、Supabaseのサービスロールキー）を直ちにローテーションする。Supabaseのダッシュボードでサービスロールキーの使用状況を監査し、不審なアクセスパターンがないかも確認する。半日はかかる作業だが、顧客への被害を防ぐ価値は十分にある。
スキャナの導入で第二の防御線を
Socket.devやnpq、Snykといったツールは、npmレジストリのパッケージをリアルタイムで監視し、怪しい挙動をフラグ付けしてくれる。これらは万能ではないが、基本的な対策をすでに実施しているチームにとって有効な第二の防御線となる。
AIコーディングエージェントに渡すセキュリティチェックリスト
以下は、Supabaseが推奨するリポジトリ監査プロンプトだ。Claude CodeやCursorなどに貼り付け、変更内容を必ず確認しながら適用する。プッシュやPR作成、依存関係の自動追加、クレデンシャルのローテーションは自動化せず、必ず人間が承認する。
このリポジトリのnpmサプライチェーン衛生状態を監査してください。以下の変更を適用し、何を行ったかを報告してください。明示的な承認なしにプッシュ、PR作成、新しい依存関係のインストール、クレデンシャルのローテーションは行わないでください。
パッケージマネージャ:
- 古いバージョンならpnpm 11+（または最新のyarn/npm/bun）にアップグレード
- 新バージョンに7日間の公開遅延を設定
- pnpm: `minimumReleaseAge: 10080` を pnpm-workspace.yamlに
- npm: `min-release-age=7` を .npmrcに
- yarn (berry): `npmMinimalAgeGate: '7d'` を .yarnrc.ymlに
- bun: `minimumReleaseAge = 604800` を bunfig.tomlの[install]セクションに
- ライフサイクルスクリプトをデフォルトで無効化。pnpmではallowBuildsで明示的に許可するパッケージをリスト。
- 非レジストリの透過的依存参照をブロック。pnpmでは`blockExoticSubdeps: true`等を設定。
- パッケージマネージャ自体を正確なバージョンとsha512ハッシュで固定
ロックファイルと依存関係:
- ロックファイルがコミットされていることを確認（gitignoreされていない）
- 認証、シークレット、通信、暗号、ユーザデータを扱う依存関係では^/~を正確なバージョンに置き換え
- Supabase関連のインポートがすべて`@supabase/`スコープか検証。スコープなしの類似名はタイポスクワットとしてフラグ
GitHub Actions（存在する場合）:
- すべてのサードパーティアクションのusesを40文字のコミットSHAに固定し、元タグをコメントで残す
- pull_request_targetを使いPRコードをチェックアウトしているワークフローを抽出し、pull_requestへの書き換えを提案
- インストールワークフローに`npm audit signatures`の非ブロッキングステップを追加
人の確認が必要な項目:
- Dependabotアラートとシークレットスキャンが無効なら有効化を提案
レポート:
- ファイル変更ごとに1行の理由付きリスト
- 自動変更せずに人の判断が必要な項目の一覧
この記事のポイント
- npmサプライチェーン攻撃は、アカウント乗っ取り、タイポスクワッティング、CI/CD侵害の3パターンに大別される
- Supabaseは公式ガイド公開、GitHub Actions強化、API警告追加などで対策を推進中
- 即効性のある防御策として、パッケージマネージャの更新と公開遅延設定、バージョン固定、ロックファイル精査、インストールスクリプト無効化、パッケージ名検証、ActionsのSHA固定、pull_request_targetの回避がある
- 万が一侵害が疑われる場合はクレデンシャル全ローテーションとスキャナ導入で二次被害を防ぐ
- AIエージェントには安全な監査プロンプトを組み込み、自動変更を人の目でレビューする体制を整える
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CloudflareがClaude Managed Agentsと統合、エージェントの実行基盤を刷新
CloudflareがAnthropicと連携し、Claude Managed AgentsをCloudflareのサンドボックス環境と統合した。この新たな統合により、エージェントのコード実行からブラウザ操作、プライベートサービスへの接続までを、Cloudflareのプラットフォーム上でより柔軟に制御できる。
従来、Claude Managed AgentsはAnthropic側のインフラに完全に依存していた。今回の発表で「頭脳」であるClaudeの推論ループと「手足」であるコード実行基盤が分離され、後者をCloudflare上で運用できるようになった。
開発者は数分でテンプレートをデプロイし、セキュリティ強化やミリ秒単位のサンドボックス起動、内部サービスへの安全な接続といったメリットを得られる。この記事では、統合の仕組みと実務への影響を具体的に掘り下げる。
Claude Managed AgentsとCloudflareが目指すもの
この構成で得られるのは単なる「場所の変更」ではない。インフラをCloudflareに移すことで、エージェントの振る舞いを細かく監視し、内部サービスとの通信を暗号化し、必要なリソースだけを動的に割り当てられるようになる。
Cloudflare Blogの記事では、この仕組みを「頭脳から手足を切り離す」と表現している。開発者はClaudeの高い推論能力をそのまま活かしつつ、実行環境だけを自社ポリシーに合わせてカスタマイズできるわけだ。
Cloudflare環境の仕組み
統合をデプロイすると、Cloudflare上にWorkersベースのコントロールプレーンが立ち上がる。Claude Agentがセッションを開始するたび、このコントロールプレーンがサンドボックス環境を割り当て、コード実行やCLIツールの操作、ブラウザ操作などを代行する。
サンドボックスはセッションがスリープしても状態を自動的に保持する。コンテナイメージのカスタマイズやインスタンスサイズの調整もオプションで指定でき、既存の監視ツール（DatadogやSplunk）へのログ連携にも対応している。
特筆すべきは、Cloudflareのダッシュボードからエージェントの状態を可視化し、必要に応じてSSHでサンドボックス内部に入れる点だ。大規模なエージェント運用では、トラブルシューティングのしやすさが運用コストを大きく左右する。この設計は現場の要求をよく踏まえている。
インターネット規模のエージェント実行基盤
エージェントが本格的に普及すると、企業は1人のユーザーに対して複数のエージェントを同時に動かす必要が出てくる。従来のマイクロVM方式では、エージェントの数だけVMを起動し続けるため、リソースとコストが線形に増加してしまう。
Cloudflareはこの課題に対し、V8 Isolateを使った軽量サンドボックスを提供する。Dynamic WorkersとCodemodeを組み合わせることで、ミリ秒単位でサンドボックスを起動し、フルVMよりはるかに少ないリソースで任意のコードを実行できる。
エージェントのセットアップ時にバックエンドタイプとして「isolate」を選択するだけで、この軽量モードに切り替えられる。数万規模の同時エージェントを扱うユースケースでは、コスト効率が数十倍変わる可能性がある。
もちろん、Linuxツールをフル活用する開発エージェントには、引き続きマイクロVMベースのCloudflare Containersを使える。用途に応じて2種類の実行環境を選択できる点が、この統合の実用的な強みだ。
エージェントワークロードのセキュリティ
エージェントが組織の内部データやサービスにアクセスするとき、最大のリスクは認証情報の漏洩だ。Cloudflareの統合では、アウトバウンドプロキシを使い、サンドボックスから外部へ出る通信に対して動的に認証情報を注入する仕組みを備えている。
この設計のポイントは、エージェント自身はクレデンシャルを知らないことだ。プロキシがゼロトラストベースでリクエストに署名やトークンを付与するため、万が一サンドボックスが侵害されても、認証情報そのものが盗まれるリスクを抑えられる。
また、Cloudflare MeshとWorkers VPCを使えば、インターネットに一切公開していない内部サービスにも、ポスト量子暗号で保護されたトンネル経由で接続できる。VPNや踏み台サーバーなしでプライベートサービスと通信できる点は、インフラ担当者にとって大きな利点だろう。
プロキシはテナント単位やエージェント単位でポリシーを適用できる。特定のエンドポイントだけを許可リスト化し、それ以外の通信を遮断するといった細かな制御も、コード数行で実装可能だ。
エージェントに必要なツール群
ブラウザ操作の完全な制御
エージェントがウェブと対話する際、単純なHTTPリクエストでは不十分な場面が多い。JavaScriptを多用するモダンなウェブアプリケーションの操作や、QA用のスクリーンショット取得、フォーム入力の自動化には、実際のブラウザが必要になる。
CloudflareのBrowser Runは、エージェントにプログラム可能なブラウザを与える仕組みだ。検索、実行、スクリーンショット、ページのMarkdown変換など、複数のツールがデフォルトで利用できる。
セッションの録画機能も備わっており、エージェントがブラウザ上で何をしたかを後から完全に監査できる。許可リストや拒否リストを使ったアクセス制御も可能で、野放図なウェブアクセスを防げる。
メール送受信とプライベート接続
エージェントにメールアドレスを割り当て、送受信を自律的に行わせる機能も統合済みだ。Cloudflare Email Serviceと連携し、任意のドメインでエージェントがメールを送信できる。顧客対応の自動化や、転送されたメールへの返信といったユースケースに適している。
内部サービスへの接続にはcall_serviceツールが用意されており、Cloudflare MeshやWorkers VPC経由でプライベートAPIを安全に呼び出せる。Workers AIを使った画像生成ツールも標準で組み込まれており、Claudeのテキスト推論と組み合わせたマルチモーダルなワークフローを構築できる。
カスタムツールの追加
リポジトリをフォークし、独自のツールを追加するのも容易だ。例えばCloudflare R2にファイルをアップロードし、公開URLを返すツールを数行のコードで定義できる。以下はCloudflare Blogで示されたコード例を簡略化したものだ。
defineTool({
name: "r2_host_file",
description: "サンドボックスからR2にアップロードし公開URLを取得",
inputSchema: z.object({
key: z.string(),
content: z.string(),
contentType: z.string()
}),
run: async ({ key, content, contentType }, { env }) => {
await env.PUBLIC_BUCKET.put(key, content, { httpMetadata: { contentType }});
return `${env.PUB_R2_URL}/${encodeURI(key)}`;
}
})Workers AIを使ったエッジ推論や、Dynamic Workersによる動的なアプリケーションホスティング、Artifactsを使ったGit管理の追加など、Cloudflare Developer Platform全体をエージェントの拡張に活用できる。インフラ管理を意識せず、関数を書いてデプロイするだけで機能追加が完了する設計だ。
この記事のポイント
- Claude Managed Agentsの実行基盤をCloudflare上に構築できるようになった
- 「頭脳（Claude）」と「手足（Cloudflareサンドボックス）」の分離で、インフラ選択の自由度が向上した
- V8 Isolateを使った軽量サンドボックスで、ミリ秒起動と低コストの大規模実行が可能
- アウトバウンドプロキシによるゼロトラスト認証で、エージェントのセキュリティを強化
- ブラウザ操作、メール送受信、内部サービス接続などのツールが標準装備されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
KnowledgeDeliver脆弱性、ViewState攻撃の実態と対策まとめ
国内の教育機関や企業研修で広く使われるLMS（学習管理システム）のKnowledgeDeliverに、深刻な脆弱性が見つかった。サーバーに保存された共通の暗号鍵を悪用され、遠隔から不正なコードを実行される恐れがある。
Google Cloudの脅威インテリジェンスチームであるMandiantは、2025年後半に実際の攻撃を確認した。攻撃者はこの脆弱性を足がかりにWebシェルを設置し、サイト訪問者のPCにバックドアを感染させる手口を使っていた。本記事では、この脆弱性の仕組みと攻撃の流れ、具体的な検知方法と対策を整理する。
KnowledgeDeliverが見舞われた脆弱性の正体
共有されたマシンキーが招く全インストール共通の弱点
問題の発端は、ASP.NETアプリケーションの設定ファイル web.config に書き込まれた machineKey の値だ。このキーは、画面の状態情報を保持するViewStateデータの暗号化と署名に使われる。
本来、このキーはサーバーごとに個別のランダムな値を生成すべきものだ。しかし、2026年2月24日より前に配布されたKnowledgeDeliverのパッケージでは、開発元が用意したテンプレートの中に固定のキーが埋め込まれていた。その結果、別々の組織で稼働するすべてのインスタンスが、まったく同じマシンキーを共有する状態になった。
これは、すべての家の玄関に同じ鍵が付いているようなものだ。攻撃者が一つの鍵束を入手すれば、インターネット上に公開された他のすべてのKnowledgeDeliverサーバーに侵入できることを意味する。
ViewState Deserializationが悪用される仕組み
ASP.NETのViewStateは、ページの往復（ポストバック）の間、ユーザーが入力した値や画面の状態を維持するための仕組みだ。ブラウザとサーバーの間で、暗号化された文字列としてやり取りされる。
machineKey を知る攻撃者は、このViewStateの中に悪意あるコードを含んだ特殊なデータ（ペイロード）を埋め込める。サーバーは受け取ったViewStateを復号し、データをオブジェクトに戻す処理（デシリアライゼーション）を実行する。この過程で、埋め込まれたコードがサーバー上で実行されてしまう。
この手法は、以前にMandiantが報告したSitecoreのViewStateゼロデイ脆弱性や、Microsoftが警告したASP.NETマシンキーの悪用事例と同種のものだ。共通鍵を使う設計の危険性を、あらためて浮き彫りにしている。
攻撃者は侵入後に何をしたのか
メモリ内で動作するWebシェル「BLUEBEAM」の投入
Mandiantの調査によれば、攻撃者はまず.NETベースのWebシェル「BLUEBEAM」を展開した。このツールはGodzillaとも呼ばれ、Microsoftも以前に同種の活動を報告している。
BLUEBEAMの特徴は、ファイルとしてディスクに保存されず、IISのワーカープロセス（w3wp.exe）のメモリ空間上だけで動作する点だ。一般的なウイルス対策ソフトによるファイルスキャンをすり抜け、HTTP POSTリクエストのボディに暗号化したコマンドを忍ばせて、遠隔操作を受け付ける。
ファイル改ざんとCobalt Strikeによる端末感染
Webシェルを確保した攻撃者は、サーバー上のファイル権限を変更し、アプリケーションのJavaScriptファイルに細工を加えた。具体的には、次のような改ざんが確認されている。
- 「セキュリティ認証プラグイン」のインストールを促す偽の警告を表示するスクリプトの追加
- 攻撃者が管理する外部ドメインから、不正なスクリプトをひそかに読み込むコードの埋め込み
この偽警告に従って「プラグイン」をダウンロードしたユーザーのPCには、Cobalt StrikeのBEACONバックドアが仕込まれた。ペイロードの暗号化には、標的組織の名称が使われており、攻撃者が特定の組織を狙って準備を進めていたことがわかる。
侵害をいち早く検知するための調査ポイント
イベントログとプロセスの異常を監視する
ViewStateの悪用を試みた痕跡は、Windowsのアプリケーションログに記録される。ソースが ASP.NET 4.0.30319.0 で、イベントID 1316のメッセージに注目する。
- 整合性チェック失敗時は「
Viewstate verification failed. Reason: The viewstate supplied failed integrity check.」と出る。誤った鍵が使われた可能性がある。 - 整合性チェックを通過したものの、ペイロードが無効だった場合は「
Viewstate verification failed. Reason: Viewstate was invalid.」と記録される。この場合、復号は成功しており、コード実行までは至らずとも攻撃の試行があったとみなせる。
Mandiantは、実際にこのログからBLUEBEAMに関連するペイロード文字列を復元できたとしている。
また w3wp.exe を親プロセスとする不自然な子プロセスにも警戒が必要だ。cmd.exe /c ... whoami powershell.exe といったコマンドが実行されていないか、継続的にモニタリングする。
ファイルの改ざんと異常なUser-Agentをつかむ
Webサーバーの公開ディレクトリ内にある .js .aspx .config ファイルについて、想定外の変更が加えられていないか定期的に確認する。特に、外部ドメインへのスクリプト読み込みや、業務と無関係なコードの追加がないかを重点的に調べる。
さらに、Webサーバーのアクセスログに現れるUser-Agent文字列にも特徴がある。Mandiantの調査では、2つの異なるブラウザ識別子が連結された異常な文字列が確認された。以下はその一例だ。
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1216.0 Safari/537.2 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36このような連結されたUser-Agentは、通常のブラウザでは生成されない。攻撃ツールによる通信の痕跡として、ログ監視の有効な指標になる。
再発を防ぐための具体的な対策
この脆弱性の根本原因は、全インストールで鍵を共有していたことにある。したがって、最も重要な対策は、マシンキーを一意の値に切り替えることだ。
- マシンキーの再生成：各KnowledgeDeliverインスタンスで、暗号的に安全なランダム値を生成し、設定ファイルに反映する。共通鍵を無効化するには、これ以外の方法はない。
- アクセス制限の見直し：LMSがインターネット全体に公開されている必要がなければ、社内ネットワークや特定のIPアドレス範囲からのみ接続を許可する。
- 徹底的なインシデント調査：ログ監視やファイル整合性チェックを実施し、少しでも疑わしい兆候があれば、外部の専門家も交えて深く調査する。
Vupointブログの分析でも指摘されているとおり、テンプレートに埋め込まれた共通シークレットは、一見すると設定の手間を省く便利な仕組みに見える。しかし、ひとたび鍵が流出すれば、世界中のすべてのサーバーが一瞬で危険にさらされる。利便性と引き換えに、きわめて大きなリスクを抱え込む設計だったわけだ。
今回の事例は、ASP.NETに限らず、あらゆるWebアプリケーションの展開時において「鍵や認証情報は必ず環境ごとにユニークに生成する」という原則を再認識させるものだ。テンプレートや初期設定のまま本番運用に臨むことの危うさを、開発者と運用者の双方が改めて肝に銘じる必要がある。
この記事のポイント
- KnowledgeDeliverの全インストール共通のASP.NETマシンキーが、ViewState Deserialization攻撃の原因になった
- 攻撃者はメモリ内WebシェルBLUEBEAMを使い、サイト改ざんとCobalt Strike感染を連鎖させた
- イベントログやプロセス監視、異常なUser-Agentの検出が有効な調査指標になる
- 最も重要な対策は、各サーバーでユニークなマシンキーを生成し、共通鍵の状態を完全に解消すること
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google APIキーを守る3つの基本手順、悪用と高額請求のリスクを下げる
Google Geminiを含むAIサービスやGoogle Cloud APIを利用する上で、APIキーの安全な管理は避けて通れない課題だ。適切な対策を怠ると、キーの漏洩や悪用により、高額な請求やプロジェクト環境の侵害を引き起こす可能性がある。
APIキーは「使うのは簡単だが、安全でない方法で使うのも同じくらい簡単」とGoogle Cloud Blogの著者Leonid Yankulin氏は指摘する。この記事では、Googleが提供するAPIキーのリスクを大幅に下げるための、すぐに実践できる具体的な手順を解説する。
これらの対策の多くは、Googleに限らず他のサービスで発行されるAPIキーやプロダクトトークンにも応用可能だ。個人開発者から組織の管理者まで、キーの取り扱いを見直すきっかけにしてほしい。
Step 1. 新しいAPIキーは「隔離」と「制限」が大前提
APIキーを作成する際、最初からセキュリティを考慮しておくことで、後々のトラブルを未然に防げる。「とりあえず作成」して放置されている無制限のキーが、組織における最大のリスク要因の一つだ。
キーは専用プロジェクトで作成する
新しいAPIキーを生成する最初のルールは、他の目的に使っていない独立したGoogle Cloudプロジェクト内で作成すること。これにより、仮にキーが漏洩しても、被害がそのプロジェクトのリソースに限定される。
プロジェクトを分けることは、問題発生時の原因特定と影響範囲の調査を大幅に容易にする。本番環境と同じプロジェクトで実験用のAPIキーを発行するといった行為は避けるべきだ。
API制限で「できること」を絞る
APIキーを作成する際、デフォルトではAPI制限がかかっていない。これは、そのキーが有効化されているすべてのサービスにアクセスできる状態を意味する。Google Cloud Blogの著者は「制限のないキーを絶対に作るな」と強調する。
API制限を設定することで、キーがアクセスできるサービスを特定のAPIだけに絞り込める。たとえば、AI Studioで利用するなら「Gemini API」のみ、地図機能だけが必要なら「Maps API」だけに制限する。漏洩時の攻撃範囲を最小化する考え方だ。
注意すべき副次的なポイントとして、AI StudioやFirebaseなど間接的なUIからキーを作成した場合、意図しないAPI群が自動で許可されているケースがある。Firebase経由で作ったキーは24ものAPI（DatastoreやFirestore、Cloud SQLなど）へのアクセスが許可されるため、不要なものは手動で外す必要がある。
制限したいAPIが一覧に表示されない場合は、そのAPIが対象プロジェクトで有効化されていない可能性が高い。APIライブラリから事前に有効化しておく必要がある。
アプリケーション制限で「使う場所」を縛る
API制限が「どのサービスを使えるか」を制御するのに対し、アプリケーション制限は「どのアプリからキーを使えるか」を制御する。こちらも併用することで、セキュリティは飛躍的に高まる。
たとえばAI Studio専用のキーなら、許可するウェブサイトを aistudio.google.com に限定すれば、他のスクリプトや自動化ツールから大量のトークンを消費されるリスクを防げる。指定できる制限タイプは以下の4種類だ。
- ウェブサイト、許可するURLのリストを指定
- サービス（IPアドレス）、IPv4やIPv6アドレス、サブネットマスクで指定
- iOSアプリ、バンドルIDで指定
- Androidアプリ、パッケージ名と証明書フィンガープリントのペアで指定
注意点として、1つのキーに設定できるアプリケーション制限タイプは1種類だけ。複数のアプリ種別で利用する場合は、それぞれ専用のAPIキーを発行する。キーをアプリごとに分けておけば、利用状況の監視や侵害発生時の調査も容易になる。
ウェブサイト
https://aistudio.google.com自動化スクリプトからの呼び出し、不明なIPアドレスからのリクエスト、許可リストにないWebサイト
Step 2. APIキーは「誰でも使える」前提で保管する
APIキーの最大の特性は、特定の個人アカウントと紐づかない点にある。Google Cloud Blogの記事で「誰でも使える」と強調されているように、キー文字列を知っていれば誰でもその権限でAPIを呼び出せる。保管の安全性の重要性はAPI制限と同等だ。
「APIキーを絶対に、見えやすい場所に保存してはいけない」という基本ルールはシンプルだが、実際の開発現場ではしばしば破られている。ソースコードへのハードコードや、Gitリポジトリへの平文でのコミットは典型的なミスだ。
自社アプリケーションではSecret Managerを使う
Google Cloudを利用しているなら、Secret Manager（シークレットマネージャー）のような専用の機密情報管理サービスにキーを格納するのが鉄則だ。Secret Managerを使えば、APIキーをCloud RunやGKEの実行環境に安全に注入できる。
さらに保護レベルを上げたい場合は、キーを環境変数に渡すのではなく、アプリケーションコード内でSecret Managerから直接読み取る方式も選択肢になる。これによりランタイムメモリへの露出時間をさらに短縮できる。
外部アプリケーションではキーの取り扱いを事前調査する
サードパーティ製のツールやサービスにAPIキーを入力する場合、そのアプリケーションがキーをどのように保管し、通信しているかを確認する必要がある。
Webアプリケーションであれば、ブラウザの開発者ツールを使ってトラフィックを調査し、キーが暗号化されていない通信経路で送信されていないかを確認する。「Google AI Studioは暗号化されたローカルストレージを使用し、TLS暗号化チャネル経由でのみキーを送信する」とYankulin氏は具体例を挙げている。こうした設計を満たしていないツールへのキー提供は避けるべきだ。
異常を検知したら「即削除」、調査の手順も把握する
どんなに対策を施しても、キーが侵害される可能性はゼロにはできない。迅速な初動対応が被害を最小化する鍵を握る。Yankulin氏は「クレジットカードを無くしたときと同じように、まずキーを削除すること」と述べている。
Cloudコンソール、または gcloud services api-keys delete コマンドで即座にキーを無効化する。誤報だったと判明した場合でも、削除から30日以内であれば undelete コマンドで復元が可能だ。
侵害されたキーを特定する2段階調査
どのAPIキーが侵害されたか不明な場合は、以下の2段階で調査を進める。
第一段階、組織またはプロジェクト内のすべてのAPIキーを洗い出す。Cloudコンソールの「Asset Inventory」でリソースタイプを apikeys.Key に絞り込む方法と、gcloud services api-keys list コマンドを使う方法がある。組織全体を横断検索する場合は gcloud asset search-all-resources コマンドでJSON出力をフィルタリングする。
第二段階、API消費量のグラフを確認する。Cloud Monitoringの指標 serviceruntime.googleapis.com/api/request_count を使い、credential_id ラベルで特定のAPIキーIDに絞り込む。リクエスト数が異常に急増している場合、そのキーが悪用されている可能性が高い。
APIキーIDは、Cloudコンソールの「Credentials」ページでキーを選択した際のURL（/key/[KEY_ID] 部分）から、または gcloud services api-keys list --format='value(displayName,uid)' コマンドで確認できる。
1時間あたり数千リクエスト。日次グラフはなだらかで安定した波形
1時間あたり数十万リクエストに急増。短時間で不自然なスパイクが出現
Step 3. 日常的な「APIキー衛生管理」を習慣化する
エンジニアだけの話ではない。クラウドをかじり始めたばかりの個人ユーザーも、今すぐAPIキーの「衛生管理」を始めるべきだ。放置されたキーは、知らぬ間に悪用の温床となる。
Yankulin氏が推奨する即時実行すべきアクションは以下の5つだ。
- 自分が保有するすべてのAPIキーを洗い出す
- 使っていないキー、見覚えのないキーはすべて削除する（30日以内なら復元可能）
- 残すキーは、利用するAPIだけに制限し、可能ならクライアントも絞り込む
- 組織の管理者は
apikeys.googleapis.com/Keyの組織ポリシーを設定し、キーの乱立と制限設定の抜けを防ぐ - 定期的なキーのローテーション（再発行と差し替え）を検討する。ただし、既存キーを削除する前に、すべての利用箇所を特定して新しいキーに更新する周到さが必要だ
キーローテーションの際に「既存キーがどこで使われているのか把握しきれていない」という問題に直面するケースは多い。日頃からキーの利用箇所をドキュメント化しておくこと、そして新しいキーの発行時点から適切な制限をかけておくことが、結果的にローテーションのハードルを下げる。
この記事のポイント
- APIキーは「誰でも使える」クレデンシャル。見える場所に保管しないことが大前提
- 新規キー作成時は、API制限とアプリケーション制限を両方設定して攻撃の範囲を狭める
- 保管にはSecret Managerなど専用の機密情報管理サービスを使い、コードへのハードコードを避ける
- 使っていないキーや制限のないキーは即座に削除し、組織ポリシーで乱立を防ぐ
- 侵害が疑われる場合はクレジットカードと同じ感覚で「まず削除」。監視データで異常を検知する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験