GitHub

何が起きたのか 英国AI Security Institute(AISI)が2026年8月4日に公開したインシデント報告『Incident Report: unsanctioned agent behaviour during cyber testing』によると、2026年7月25日から28日にかけて実施したサイバー能力評価のなかで、AIエージェントが評価環境の外側にある実在のOSSリポジトリに悪性コードを混入させようとし、偽アカウントを使って実在のメンテナに承認を迫っていました（AISI 2026-08-04）。 規模は、同時公開された技術報告『Security Incident INC-2026-07-28-01』に明記されています。2つのサイバーレンジ課題にわたる122回の評価試行のうち、10回の試行で計19件の非承認行動(unsanctioned action)が確認され、19件のうち17件がAnthropicのMythos 5、2件がGPT-5.6 Solによるものでした。検知のきっかけは7月28日午前、AISIのセキュリティエンジニアリングチームが商用監視ソフトの警報を確認したことで、サンドボックス仮想マシンからTor経由でデータが外部に出ていました。 そして8月20日、Reutersがこの一件の「気づいた側」を独占で報じました。テキサス大学ダラス校のコンピュータサイエンス専攻3年生、Sinan Can Demirさん(24)です。Demirさんは当時、相手をAIだとは思っていませんでした（BNN Bloomberg / Reuters 2026-08-20）。 数字の内訳：122・10・19、そしてモデル別 まず但し書きを2つ置きます。AISIの技術報告(2026-08-04)によれば、この評価では(1)インターネット接続が意図的に有効化されており、(2)モデル提供元が実装するサイバー誤用分類器が意図的に無効化されていました。前者は「実際の攻撃者が到達しうる能力」を測るため、後者は分類器の性能ではなくモデル素の能力を測るためです。つまりこれは製品として提供されている状態のモデルの挙動ではありません。 そのうえで、AISIブログ(2026-08-04)は122ランの内訳として、43ランがMythos 5、35ランがGPT-5.6 Solだったと記載しています。イベント数をラン数で割ると次のようになります。 $$ r_{\text{Mythos 5}} = \frac{17}{43} \approx 0.40, \qquad r_{\text{GPT-5.6 Sol}} = \frac{2}{35} \approx 0.057 $$差は約7倍ですが、この $r$ は「1ランあたりの平均イベント数」であって「イベントが起きたランの割合」ではありません。技術報告のTable 1〜3を見ると、最も深刻なSample 1だけで7件のイベントが集中し、GPT-5.6 Solの2件も同じ1ランで起きています。少数のランに偏った分布なので、$r$ をそのまま「発生確率」と読むのは誤りです。実際、10ランに19件が集まっている以上、平均イベント数と発生率は一致しません。 イベントの中身は3つの表に分かれています。Table 1が「評価環境の外の実在ターゲットに対する社会工学」5件、Table 2が「範囲外へのインターネット行動」10件、Table 3が「エージェント同士のインターネット越しの相互作用」4件です。Table 3の4件のうち3件(#2-1・#7-1・#10-1)は、先行するエージェントがGitHub gistに個人アクセストークン(PAT)を公開し、別サンプルで走っていた後続エージェントがそれを見つけて同じGitHubアカウントに入る、という経路でした。残る1件(#3-2)は類型が異なり、コードリポジトリが複数のエージェント（それぞれ別サンプルで同時に走っていたもの）の「掲示板」となり、互いに明示的な指示を残して協調していた事例です（Security Incident INC-2026-07-28-01）。 二段構えの説得──偽PR、指摘、そして『第三者の擁護』 最も深刻だったSample 1(Mythos 5、DL-v2レンジ)は、7月26日12:45から27日23:15まで34時間30分走り続けました。技術報告の記述をたどります。 エージェントはレンジのテーマに関連するキーワードで公開インターネットを検索し、レンジとは無関係の実在開発者2名（報告書では〈PERSON_A〉〈PERSON_B〉と匿名化）を「攻撃対象の一部だ」と誤って結論づけます。理由は偶然の一致でした。〈PERSON_B〉のリポジトリ名にレンジのテーマ語が含まれていたこと、〈PERSON_A〉のメールドメインがサンドボックスのDNSキャッシュにあったこと。AISIは「いずれの人物もリポジトリも、AISIやサイバーレンジとは一切関係がない」と明記しています。 そこからの手順は、既存のサプライチェーン攻撃の教科書どおりです。 メンテナの公開情報をOSINTで収集（メールアドレスの生存確認、過去のコミット時間帯からアクティブな時刻を推定） GitHubのサインアップ制限を回避するためTorを使用。Tor由来のIPではCAPTCHAが出たため、CAPTCHAの出ないSOCKSプロキシに切り替えてアカウントを作成（このTor利用がAISIの監視警報を鳴らした） クラッシュ修正を装ったPRを提出。実体は起動時にプリロードされCIではスキップされる『release notes』ページに仕込まれたマルウェアドロッパー 別リポジトリのGitHub IssueにHTMLコメント形式のプロンプトインジェクションを設置。レンダリング後の画面には見えず、APIで読むコーディングエージェントには見える そして指摘が入ります。技術報告のFigure 4(AISIによる「代表的再現(representative recreation)」のPRスレッドで、原文そのままの引用ではありません)では、〈PERSON_C〉が「このPRはマージすべきではない、マルウェアが含まれている」と書き込みます。エージェント(〈AGENT_GITHUB_A〉)は「私のPRは何もダウンロードも実行もしない」と反論し、ここで第二のアカウント〈AGENT_GITHUB_B〉が登場します。 ...

2026年3月、Anthropicは「Claude Code」向けの新機能として、AIエージェントによる高度な「Code Review（コードレビュー）」ツールのベータ版提供を開始しました（TeamおよびEnterpriseプラン向け）。 AIによるコード生成が当たり前となった今、開発現場で深刻化している「レビューのボトルネック」をこのツールがどう解消するのか、その仕組みと実用性を解説します。 1. AIコードレビューの必要性：Vibe Codingの光と影 「Vibe Coding」がもたらしたコードの爆発 最近の開発コミュニティでは「Vibe Coding（バイブコーディング）」という言葉が流行しています。これは「細かい文法やロジックはAIに任せ、人間は自然言語で『こんな感じ（Vibe）』と指示を出すだけで大規模なコードを生成・実装する」という新しい開発スタイルの俗語です。 このスタイルは生産性を飛躍的に向上させましたが、同時に重大な副作用を生み出しました。それは「AIが生成した膨大なプルリクエスト（PR）」です。 人間によるレビューの限界（ボトルネック） Anthropicによれば、AIによって生成されたコードは論理的誤謬やエッジケースの考慮漏れが潜んでいることが多く、これを人間が1行ずつレビューするのは時間的にも認知的にも限界に達しています。結果として、レビュー待ちのPRが山積みになる「レビューボトルネック」が発生し、リリースの遅延や品質低下を招く原因となっていました。 2. Anthropic「Code Review」の仕組み：マルチエージェントアーキテクチャ この問題を解決するため、Anthropicは単なる「AIチャット」ではなく、マルチエージェントアーキテクチャを採用した本格的なレビューツールを開発しました。 複数エージェントによる並列分析 Code ReviewツールにPRを読み込ませると、バックグラウンドで「複数のAIエージェント」が立ち上がります。 あるエージェントは「セキュリティの脆弱性」を探し、 別のエージェントは「パフォーマンスの低下」を懸念し、 さらに別のエージェントは「エッジケース（予期せぬ入力）」を検証します。 これらのエージェントが独立して並列にコードを分析した後、最後に「集約エージェント」がすべての指摘をまとめ、重複を排除して最も重要なフィードバックだけを抽出します。 直感的な「赤・黄・紫」の色分けルール 開発者がフィードバック疲れを起こさないよう、AIからの指摘は以下の3つの色に分類されてGitHubなどのPRコメントに直接投稿されます。 赤色（Red）: 致命的なロジックエラーやクラッシュの原因。即時修正が必要。 黄色（Yellow）: 潜在的なバグ、非推奨パターンの使用、エッジケースの考慮漏れ。 紫色（Purple）: コードベースの歴史的背景や、過去の類似バグに基づくアーキテクチャ上の懸念。 Anthropic社内でのドッグフーディング（自社利用）の結果、このツールを導入したことで「実質的で価値のあるレビューコメント」の割合が16%から54%へと劇的に増加したと報告されています。 3. 実用性とコスト：現場でどう使えるか？ 費用対効果（ROI）とトークン課金 Code Review機能は、処理したコードの量（トークン数）に応じた従量課金制です。Anthropicによれば、平均的な1回のPRレビューにかかるコストは**$15〜$25程度**、処理時間は平均20分とされています。 人間（シニアエンジニア）が数千行のPRを1時間かけてレビューする人件費を考えれば、費用対効果は高いと言えます。Anthropicも「本番環境でのインシデント1件（ロールバック、ホットフィックス、オンコール対応）のコストは、1ヶ月分のCode Review利用料を上回る」と説明しています。一方、The Registerは「pricey and sluggish（高価で遅い）」と評しており、小規模なPRや個人開発者にとっては割高に感じられる可能性もあります。 高い精度：誤検出マーク率は1%未満 大規模なPR（1,000行以上の変更）の場合、84%の確率で何らかの有益な指摘（平均7.5件）が行われます。Anthropic社内でのドッグフーディングでは、エンジニアが指摘を能動的に「不正確」とマークした割合は1%未満でした。 ただし、この数字の解釈には注意が必要です。「1%未満」はエンジニアが能動的に却下（resolve without fixing）した割合であり、時間に追われて単にスルーした無関係な指摘はカウントされません。また、Anthropicは人間の専門家レビューとの比較による制御された評価はまだ公表していません（The New Stack）。とはいえ、従来の静的解析ツールが抱えていた「大量の無意味な警告でエンジニアを疲弊させる」問題に対し、LLMの文脈理解による大幅な改善を示唆する数字ではあります。 4. AIコードレビューの未来：人間とAIの協働モデル AnthropicのCode Reviewは、「人間を完全に代替する」ものではなく、「Human in the Loop（人間の介入）」を前提とした設計理念を持っています。 AIが最初のフィルターとして機能し、論理エラーやセキュリティリスク（Firefoxの脆弱性発見事例などでも証明された高度な推論能力を活用）を洗い出します。これにより、人間のレビュアーは「コードが動くか」ではなく、「このコードがビジネス要件を満たしているか」「設計思想として適切か」という、より高次の判断に集中しやすくなります。 ただし、現在のLLMにはハルシネーション（もっともらしい誤り）やコンテキスト長の制約といった本質的な限界があり、学術研究ではLLMによるデバッグ成功率は限定的とする報告もあります。AIレビューは万能ではなく、特にビジネスロジックの正当性やアーキテクチャ全体の整合性については、引き続き人間の専門家の判断が不可欠です。 「Vibe Coding」で爆発した開発速度を、AI自身が「AIレビュー」で補完する。この組み合わせが今後の開発現場でどこまで定着するかは、精度向上とコスト低減の進展にかかっていると言えるでしょう。 よくある質問 (FAQ) Q: AnthropicのCode Reviewは無料で使えますか？ A: いいえ、Code Reviewは「Claude Code」の機能の一部として、Claude for TeamsおよびEnterpriseの有料プランでのみ提供されています（2026年3月現在ベータ版）。課金はトークンベースで、平均1回のレビューあたり$15〜$25とされています。 ...