BBC記者のラップトップが乗っ取られた。Orchids事件と「3週間で4回鳴った警報」を、元・挫折エンジニアが整理する
BBC Joe Tidy記者のPCがOrchidsを経由してzero-clickで乗っ取られた。Cisco CodeGuard・Bugbot・Lovable・Tenzaiまで含めた4件の警報を時系列に並べ、バイブコーダーが今やる対策を整理する。
「Joe is hacked」という名前のメモファイルが、デスクトップにポンと現れた。
壁紙は、AIハッカーを描いたイラストに置き換わっていた。
ノートPCを使っていたのは、BBCのジャーナリストJoe Tidy。攻撃したのは、サイバーセキュリティ研究者のEtizaz Mohsin。間にあったのは、Orchidsという「バイブコーディング」のAIプラットフォームだった。BBCで報じられたOrchids事件のあらすじはここから始まる。なお、BBC原典URLは本稿執筆時点で確認作業中だ。詳細はInformationWeekほか複数の二次媒体が一致して報じている。
私はバイブコーディングシリーズを書き続けてきた。第8弾のCisco Project CodeGuardを5月16日に出したばかりだ。あの時点で「大企業が肩を貸してくれる時代になった」と書いたが、その2日後にBBC事件が来た。
正直、整理が必要だった。
これは単体の事件ではない。3週間で4つの事件が並ぶ「閾値突破」の証拠に見える。元・挫折エンジニアとして、何が起きたのかを順番に書いていく。怖がるためではなく、今日からの対策に落とすために。
まず、Orchids事件で何が起きたのか
Orchids（オーキッズ）は、自然言語のプロンプトでアプリを作れる「バイブコーディング」のAIプラットフォームだ。
- 拠点: 米サンフランシスコ
- 創業: 2025年（LinkedInページより）
- 社員数: 10人未満
- ユーザー数: 100万人（同社の主張）
- 主な顧客: Google、Uber、Amazonを名指し（同社の主張）
数字だけ見れば、典型的な「急成長スタートアップ」の姿だ。
事件の流れは、こう報じられている。
2025年12月、研究者のEtizaz Mohsinが、バイブコーディング系のシステムを実験している中でOrchidsの脆弱性に気づいた。Mohsinはのちに、BBCジャーナリストのJoe Tidyが立ち上げたOrchidsプロジェクトに対して、ゼロクリック攻撃のデモを行う。
「ゼロクリック」とは、被害者が何もクリックしなくても攻撃が成立する種類の脆弱性を指す。フィッシングリンクを踏ませる必要も、添付ファイルを開かせる必要もない。プラットフォーム側に攻撃面があれば、ユーザー側の落ち度なしに侵入できる。
Mohsinが行ったのは、おおむね次のような操作だと報じられている。
- Tidyがバイブコーディングで作ったOrchidsのプロジェクトに、未承認のアクセスを得る
- 数千行のコードの中に、見つけにくい一行を埋め込む
- Tidyのラップトップ側に到達し、デスクトップを書き換える
- 「Joe is hacked」というメモファイルを作成し、壁紙をAIハッカー画像に変更する
このデモが衝撃的だったのは、攻撃者が「他人のバイブコーディングプロジェクト」のコードを書き換えるだけで、相手のラップトップを支配できた点だ。
Orchidsが100万ユーザーを抱えていると主張するなら、同じ攻撃面がそのまま100万人分横たわっている可能性がある。これがBBCの「easily hacked（簡単に乗っ取れる）」という見出しの背景だ。
参考: InformationWeek「Zero-click hack exposes flaw in Orchids vibe coding platform」 / Digital Watch Observatory「Security flaws expose ‘vibe-coding’ AI platform Orchids to easy hacking」 / CySecurity News「AI Coding Platform Orchids Exposed to Zero-Click Hack in BBC Security Test」
なぜこの事件が「単発」で済まないのか——3週間で4回鳴った警報
Orchids事件を初報で読んだ時、最初の反応は「またか」だった。
「またか」と言葉が出る程度に、ここ3週間で同じ方向の警報が連続している。順番に並べる。
警報1: 2025年10月→2026年2月 Cisco Project CodeGuard
Ciscoが「Project CodeGuard」をオープンソースとしてGitHubに公開したのが2025年10月。中身はAIコーディングエージェント向けのセキュリティルールセットだ。Cursor・GitHub Copilot・Claude Codeに対応している。公式リポジトリは github.com/project-codeguard/rules。
2026年2月、CiscoはこのプロジェクトをCoSAI（AIセキュリティ連合）に寄贈する。一企業の取り組みから、業界標準のフレームワーク候補へ昇格した形だ。
これが警報1。「ツール側・ルール側のフォロー」が業界レベルで動き始めた。
警報2: 2026年4月 Lovable脆弱性170個
Lovableは別のバイブコーディング系プラットフォームで、第三者調査によりLovable製公開アプリの約10.3%にセキュリティ欠陥が見つかり、合計170個の「裏口」が報告された。
この件は4月のシリーズで取り上げている。論点は「『動いた』と『安全』は違う」というシンプルな一点だ。
警報2。「個人開発者の責任フェーズ」が顕在化した。
警報3: 2026年5月 Tenzai 5大エージェント調査・69件脆弱性
5月に入ってから、Tenzaiという研究グループが5大コーディングエージェントを対象に脆弱性スキャンを行い、合計69件の問題を報告した。「機能テストに合格したコードでも、6本に1本しか安全とは限らない」というSVIBES調査とも整合する内容で、別々の調査から同じ方向の数字が出ている。
警報3。「実態調査フェーズ」が現れた。
警報4: 2026年5月 BBC Orchids事件
そして冒頭で書いたOrchids事件。
Tidyのデスクトップに「Joe is hacked」と現れた瞬間が、「現実の被害フェーズ」の初波になった。研究者の善意のデモという形だったが、デモが成立した時点で、「悪意ある誰かにとっても成立する」と等しい。
3週間で4回。これを単発の偶然と見るのは、もう難しい。
バイブコーディングが「閾値」を超えた、と言えるのはなぜか
過去のソフトウェア産業を振り返ると、新しい開発スタイルが社会に浸透する時、いくつかの段階を踏む。私が見てきた範囲で整理すると、こうだ。
- 試作フェーズ: 一部の先進ユーザーが触る。事故は局所的
- 普及フェーズ: 大量のユーザーが流入。事故が散発する
- 閾値突破フェーズ: 「やってる人が多すぎて、攻撃するうま味が出る」状態
- 規範整備フェーズ: 業界ルール・標準が後追いで整う
バイブコーディングは今、3と4の境目にいる、と私は受け取った。
判断の根拠は3つある。
第一に、攻撃者側のコストが下がっている。OrchidsもLovableも、自然言語プロンプトと共有プロジェクトスペースを前提に作られた。これは「攻撃者が読みやすい」設計でもある。複雑な独自構文を解読する手間もなくなった。攻撃面が標準化されたぶん、攻撃方法も標準化しやすい。
第二に、被害規模が個人を超えた。Orchidsは100万ユーザーを主張している。同じ攻撃面を持つプラットフォームに100万人がコードを置いている状態だ。1人の研究者がデモした手法は、原理的に100万人の側面に当てられる。
第三に、業界側の動きが始まった。Project CodeGuardのCoSAIへの寄贈は、「個別企業の善意」から「業界共通の防御」へ枠組みが変わるシグナルだ。後追いで整えに来ている、と読める。
「閾値を超えた」という表現は私のフレームだ。ただ、3週間で4回も警報が並ぶ現状を「偶然」とは呼びにくい。
元・挫折エンジニアが今日からやる4つのチェック
ここまでが現状認識。ここからは、今日からの対策に落としていく。
私は専業のセキュリティエンジニアではない。バイブコーダーとして、現実的に手が動かせる範囲のチェックを4つに絞った。
チェック1: バイブコーディングプラットフォームの「保管場所」を知る
Orchids事件で見えにくかったのは、「自分の書いたコードがどこに置かれているか」だ。
バイブコーディング系のAIプラットフォームは、ユーザーが書いたコードをクラウド側に保管する設計が一般的だ。これは便利な反面、サービス側に脆弱性があった場合、「自分のローカルだけ守れば良い」では済まない。
今日やるのは、自分が使っているプラットフォームの「コード保管場所」をドキュメント上で確認すること。クラウド保管か、ローカル保管か、ハイブリッドか。保管されているのは「コードだけ」か「実行環境ごと」か。10分でできる。
私はこれを5月17日にやり直した。3つ使っていたサービスのうち、2つが「クラウド保管・実行環境ごと」、1つが「ローカル保管・クラウド連携のみ」だと確認できる。同じ「バイブコーディング」と呼ばれていても、攻撃面の大きさはかなり違う。
チェック2: Cisco CodeGuardルールをリポジトリに置く
これは第8弾で詳しく書いた。具体的にはルールファイルを自分のプロジェクトのルートに置き、AIエージェント側に読ませる形だ。
# CodeGuardルールの配置イメージ
your-project/
├── .codeguard/ # CodeGuardルールセット
│ ├── deny-rules.md # 禁止カテゴリ
│ ├── recommend-rules.md # 推奨カテゴリ
│ └── context-rules.md # 文脈カテゴリ
└── src/ # コード本体このルールセットを置くだけで、AI側が「設計の前提」として参照してくれる構造になる。私の経験では、プロンプトの冒頭に「CodeGuardルールを必ず参照してから書いて」と一行追加するだけで、参照率が体感的に大きく上がった。
チェック3: PRレビューにBugbot or 同等を入れる
Cursor 3でBugbotが強化されたのが4月。月間200万件以上のPRを処理し、フラグの78%が解決済みという数字が出ている（Cursor公式）。
1人で書くバイブコーダーには「レビュアー」がいない。だからこそAIレビュアーを1人挟む。これだけで、自分が気づかなかった「動くけど危ない」コードを引っ掛けられる確率が上がる。
完璧な防御にはならない。とはいえ、Orchids事件のような「数千行に紛れた一行の悪意」を見つける確率は、人間1人より上がる。
チェック4: 「動いた」と「公開できる」を分ける線を引く
バイブコーディングの強みは「とりあえず動かせる」ことで、私もこの哲学でここまで書いている。
ただ、Orchids事件後の私の中で、線が1本引き直された。
「動いた」段階のコードは、自分専用ツールにとどめる。チームメンバーに使ってもらう・社外に公開する・本番サービスに乗せる、のいずれかをやる前に、最低でもCodeGuard+Bugbot+セルフレビュー5分の3段階を通す。
これは私のローカルルールだ。基準を強くしすぎると、バイブコーディングの速さが死ぬ。逆に基準がゼロだと、Orchidsのような事件が自分の側にも飛んでくる。妥当点は「動いた即公開」と「全部レビュー」の中間だ。
CS出身として書きたい「予防の設計」
ここから先は、技術論よりも姿勢の話になる。
CSの仕事をしていた頃、トラブルが起きた顧客企業に何度も入った。インシデント発生後の数日は、対応に追われて全員が疲弊する。原因究明、暫定対策、恒久対策、関係者への説明、再発防止策の合意——時間も精神も容赦なく削られた。
その経験から学んだのは、「事故が起きてから整える」のは、設計時点で「事故を想定して整える」より、ほぼ常に高くつくということだ。
Orchids事件のようなニュースを見ると、つい「自分は大丈夫」と思いたくなる。「自分は専業のセキュリティエンジニアではないから」「自分のツールは小さいから」と。CS時代に同じセリフを何度も聞いた。事故を起こした側はほぼ全員、事前に「自分は大丈夫」と思っている。
バイブコーディングは速い。だからこそ、「速さの代償」を設計時点で意識する必要がある。CodeGuardを置く5分、Bugbotを通す3分、セルフレビューの5分。合計13分の習慣化が、事故対応の数日と引き換えになる。費用対効果は明らかに前者が高い。
「予防の設計」と書くと堅苦しい。私の日常用語にすると、「ハマる前に転ばないように歩く」だ。
挫折エンジニアの3年間、私はコードから離れたままユーザーの困りごとを聞いていた。あの3年で核心として身についたのは、「ユーザーが事故を起こす前に、どう設計するか」だ。コードを書く側に戻った今、その習慣をコード設計にそのまま持ち込みたい。
ハマりポイントは先に書く——というのは、これまでの記事でも何度も繰り返してきた姿勢だ。今回はそれを「自分以外の誰か」のためにも先に書く。BBCの事件を読んで「自分の隣にも飛んでくるかも」と気づいた人が、13分の習慣化で防げる範囲は思ったより広い。
まとめ——3週間で4回鳴った警報の、次にやることは
整理する。
- 5月18日時点で、バイブコーディングをめぐる主要な警報は3週間で4つ並んだ。Cisco CodeGuard、Lovable脆弱性170個、Tenzai 69件、BBC Orchidsだ
- BBC Orchids事件は「ゼロクリックでBBC記者のラップトップが乗っ取られた」という現実の被害として記録された。研究者のデモではあるが、デモが成立する設計なら悪意でも成立する
- 4つを並べると、バイブコーディングは「閾値突破フェーズ」にいる。攻撃者側のコストが下がり、被害規模が個人を超え、業界側の対応が後追いで動き始めた
- バイブコーダー個人として今日からやれることは4つ。保管場所の確認、CodeGuardの配置、Bugbotの導入、「動いた」と「公開」の線引き
- CS出身の私の結論は「予防の設計は事故対応より圧倒的に安い」。13分の習慣化を、今日から始める価値がある
挫折エンジニアからバイブコーダーに復活した私は、コードが書ける喜びをこれからも書いていく。「書ける」の隣にある「守れる」を、今日から習慣にする。
凄腕エンジニアが自分に宿ったように感じるあの体験を、事故で台無しにしたくない。それだけだ。
参照元
- BBC News / Joe Tidy 取材記事「Major vibe coding platform Orchids is easily hacked」(2026年・BBC公式記事の一次URLは原典確認中)
- InformationWeek「Zero-click hack exposes flaw in Orchids vibe coding platform」
- Digital Watch Observatory「Security flaws expose ‘vibe-coding’ AI platform Orchids to easy hacking」
- CySecurity News「AI Coding Platform Orchids Exposed to Zero-Click Hack in BBC Security Test」
- Cisco Project CodeGuard 公式リポジトリ: https://github.com/project-codeguard/rules
- Cursor Bugbot公式
- コードが書けなくてもいい時代がAIで来た（ナギ）
- 「claude code 使い方」で迷う人に（ナギ）
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
