Claude Mythos のハッキング性能と AI の特性

まず、ソフトウェア開発の根本的な性質について考えてみる。

ソフトウェア開発とは、一言で言えば「要求仕様の論理を崩さずにソフトウェアで実現すること」だ。 プログラムは、変数や関数、モジュールといった小さな論理ブロックの組み合わせによって構築される。 これは、数十行のスクリプトであっても、数百万行の OS カーネルや大規模な分散システムであっても変わらない。

ただ、規模が大きくなればなるほど、この「論理を崩さずに」という条件を維持することが指数関数的に困難になっていく。 機能を追加したりバグを修正したりする際、既存のアーキテクチャの制約を満たし、他モジュールの状態遷移と矛盾せず、マルチスレッド環境での競合を避け、リソースリークを防ぐといった、システム全体の整合性を常に意識する必要がある。

例えば、OS のメモリ管理機構やマルチスレッドの同期処理などを考えてみるといい。 ある一つのロックを取得する順番を間違えただけで、システム全体がデッドロックに陥る。 あるいは、特定の条件下でのみ発生する競合状態（レースコンディション）は、システム全体の実行フローを完全に把握していなければ防ぐことができない。 一部のロジックを変更した結果、全く関係ないように見える別のモジュールがエンバグする、というのは開発現場では日常茶飯事に起きる現象だ。

現在の LLM などの AI は、コーディングのアシスタントとしては非常に優秀だ。 特定のアルゴリズムを実装させたり、使い慣れないライブラリの API の使い方を提示させたりする能力は、人間を凌駕することもある。 しかし、大規模なリポジトリ全体を俯瞰し、アーキテクチャの整合性を維持したまま新しい要件を組み込む、といったタスクについては、少なくとも現状はまだ人間の方に分があるように感じる。 コンテキストサイズが数十万トークンに拡大したとはいえ、AI は複雑に絡み合った内部状態の整合性を完全に担保し続けることが苦手だからだ。

一方で、ハッキングというタスクはどうだろうか。

ここで言うハッキングとは、システムに存在する脆弱性やロジックのバグを見つけ出し、意図しない挙動を引き起こすことを指す。

ソフトウェア開発が「整合性の取れた巨大な論理構造を構築し、それを維持する」作業だとすれば、ハッキングは「その構造の中に存在する、たった一つの綻びを見つけ出す」作業である。 ある意味で、ハッキングはひたすらに綻びを発見するための単純作業と言える。

ハッキングにおいて「全体最適」は不要だ。 ハッカーは、システムが期待通りに美しく動くことなど一切望んでいない。 ただの一箇所、例えば入力データの境界値チェックが漏れているバッファを探し出し、そこに想定外の長さのデータを流し込んでスタックを破壊する（バッファオーバーフロー）。 あるいは、メモリ解放後のポインタを再利用している箇所（Use-After-Free）を特定し、そこに悪意のあるコードを配置する。 Web アプリケーションであれば、SQL インジェクションや XSS、あるいは認証トークンの検証漏れなど、特定の入力に対するバリデーションが甘い箇所を一つでも見つければ、そこからシステム全体を掌握できることもある。

システムの全体構造やビジネスロジックを完全に理解していなくても、局所的なコードのパターンマッチングや、膨大なパターンの入力を試行し続けるファジング的なアプローチによって、致命的な脆弱性を発見できることが多い。

そして、この「局所的なパターンの発見」や「膨大な試行錯誤の繰り返し」こそが、圧倒的に AI が強い領域だ。

人間は数万行のコードをレビューしていると集中力が途切れ、境界値チェックの漏れなどを見逃してしまう。 しかし AI は人間のように疲労することなく、過去の脆弱性データベースや学習データに存在する膨大なバグのパターンと、目の前のコードを高速に照らし合わせることができる。

また、静的解析ツールと比べても AI の優位性は明らかだ。 従来の静的解析ツールは、事前に定義されたルールに従って機械的にコードをスキャンするため、誤検知が多く、未知のロジックの欠陥には対応できない。 しかし AI は、「この変数名は is_admin だから、ここになんらかの方法で true を流し込めれば権限昇格できるのではないか」といった、セマンティクス（意味論）に基づいた推論が可能だ。 エラーの出力結果を解析し、失敗した攻撃コードを自動的に修正して再度攻撃を試みる、といったフィードバックループを自律的に、かつ人間とは比較にならない速度で回すことができる。

つまり、Mythos のハッキング性能が高いのは、AI という仕組み自体がハッキングタスクに最適化しやすいからだ。 AI であれば、Claude でなくとも、モデルの基本性能が一定のラインを超えれば十分到達可能な話だと言える。

まぁ、だからこそ、それを Mythos が明確に示してしまったことは、非常にセキュリティとして問題である。

これにより、攻撃と防御の非対称性がこれまで以上に絶望的なレベルにまで拡大してしまった。 攻撃側は AI を用いて、人間が気付かないようなシステム全体の綻びを自動的かつ高速に発見できる。 対する防御側（開発側）は、依然として「全体の論理を崩さずに」堅牢なシステムを構築するという、AI にとっても人間にとっても難易度の高いタスクを強いられる。

防御側も AI を用いて脆弱性スキャンを行うことは可能だが、前述の通り「バグを一つも見逃さずに論理を維持する」のは極めて困難だ。 ハッカーは AI を使って 1000 個の攻撃を試行し、たった 1 つ成功すれば勝ちだが、開発者は AI の支援を受けても 1000 個すべての攻撃を防がなければならない。 これは、これまでも言われてきたサイバーセキュリティの原則ではあるが、AI の登場によって攻撃側の試行回数と精度が劇的に向上したことで、防御側の負担が限界を超えつつある。

Mythos が証明してしまったのは、AI の進化によって、ソフトウェアの脆弱性を突くコストが事実上ゼロに近づいたということだ。 これは特定のモデルが優れているという話に留まらず、AI というテクノロジーそのものがもたらす構造的な脅威の顕在化を意味している。

今後、ソフトウェアを開発する上では、AI による容赦ないハッキングに晒されることを前提とした、これまでとは根本的に異なるレベルの堅牢な設計が求められることになるだろう。 ただでさえバグのないソフトウェアを作るのは難しいのに、本当に厄介な時代になったものだ。

とはいえ、我々エンジニアにできることは、引き続き地道に設計を改善し、AI の支援も借りながら少しでも堅牢なシステムを作っていくことしかない。 これからの開発現場では、これまで以上にアーキテクチャの妥当性とテストの網羅性が問われることになるだろう。