Claude CodeはRSA-2048を破ることなくHP BIOSの署名チェック回避を支援した
Anthropicは、Claude CodeがHP製ノートPC 1台のBIOS改変と55件の隠し設定の表示を支援したと報じられたことで、異例のセキュリティ論争の渦中に入った。Tom's Hardwareの見出しは、AIがファームウェア認証に使われる暗号標準の一つであるRSA-2048を破ったかのように示唆している。しかし証拠が裏付ける結論は、より限定的ながら依然として重要だ。Claude Codeは、ある実装の判定ロジックを回避する方法を見つけた。
この違いは重要である。ノートPCの所有者によれば、Claude Codeは検証コードの特定、圧縮されたファームウェアモジュールの解析、パッチのテスト、動作するイメージの再構築を支援した。HPの署名鍵を復元したわけでも、有効な署名を偽造したわけでも、RSA-2048の背後にある数学的問題を解いたわけでもない。
したがってこの結果は、二つのよくある前提に疑問を投げかける。ノートPCベンダーは、一般の所有者にとってファームウェア制御のリバースエンジニアリングは依然として現実的ではないと考えている。AIベンダーは、ユーザーがセキュリティ上重要なシステムへとAIを向ける場合であっても、コーディングエージェントを生産性向上ツールとして安全に位置付けられると考えている。
この実験は、BIOSバージョンF.68を実行するHP 15-dw1036ne 1台で成功したとされる。独立した技術監査はまだ実施されておらず、他のシステムへの適用可能性も不明だ。それでも、このワークフローはAIコーディングエージェントが専門的なファームウェア研究に必要な作業量をどのように減らし得るかを示している。
Claude Codeは1件のBIOSダンプを動作する改変へと変えた
重要な変化は新しい暗号攻撃ではない。難しいリバースエンジニアリングのワークフローが、ユーザー主導のAIセッション一つに圧縮されたことだ。
Reddit_2049として投稿したRedditユーザーは、HPノートPCが改変されたファームウェアを「BIOS Corruption Detected」というメッセージで拒否したと述べた。ユーザーによれば、その正確なモデル向けの既知のアンロック手法は公開されていなかった。ユーザーはBIOSダンプと、既存の複数のリバースエンジニアリングツールをClaude Codeに提供した。
報告されたワークフローでは、Ghidra、UEFITool、UEFIExtract、UEFIFind、Unicorn Engine、Capstone、Python、暗号ライブラリを組み合わせた。各プログラムにはすでに明確な技術的用途がある。Claude Codeの報告上の役割は、それらを連携させ、出力を解釈し、追加分析用のスクリプトを生成することだった。
Ghidraはファームウェアモジュールを逆アセンブルし、関連する制御フローを明らかにした。UEFIユーティリティはイメージをコンポーネントに分割した。Unicorn Engineは抽出した検証ルーチンを実機のノートPCから切り離してエミュレートし、実際のファームウェア書き込みで各変更をテストするリスクを低減した。
暗号ライブラリは、エミュレートされたルーチン向けの有効なテスト署名を生成した。この点は、ユーザーが有効な入力と破損した入力を比較できたため重要である。改変済みファームウェア用の有効なHP署名を作成したわけではない。
元のユーザー投稿によると、分析では三つの変更群が特定された。一つは圧縮されたDXEファームウェアボリュームを保護するチェックを回避した。もう一つは55件のセットアップ項目を表示した。三つ目はAdvanced、Power、Debug、Bootのタブを表示した。
DXE、すなわちDriver Execution Environmentは、オペレーティングシステムの起動前にデバイスとサービスを初期化するUEFIのフェーズである。このレベルのファームウェアコードはWindowsやLinuxより下位で動作する。誤りがあれば、コンピューターはどちらのオペレーティングシステムにも到達できなくなる可能性がある。
55件の項目は、27件の抑制された項目と28件のグレーアウトされた項目で構成されていたとされる。これらの定義はすでにファームウェアのセットアップフォーム内に存在していた。ハードコードされた条件への小さな変更により、これらの項目が表示された。
これは、表示されたすべてのオプションがサポート対象のハードウェアを制御することを意味しない。ユーザーは後に、GPS設定を含め、一部の項目はノートPCと無関係に見えると認めた。メーカーは複数の製品でファームウェアコンポーネントを共有することが多く、共通インターフェース内に非アクティブな項目を残している。
追加された四つのタブも同様のパターンをたどった。ファームウェアにはそれらが含まれていたが、インターフェースロジックがこのモデルでの表示を妨げていた。パッチは、まったく新しい設定機能を追加するのではなく、その判定を変更した。
ユーザーは、完成したイメージが自身のノートPCで動作したと述べた。また、ストックダンプから変更を再現することを意図したPythonスクリプトも公開した。ただし投稿では、このスクリプトは指定されたマシンでのみテストされており、近縁モデルでしか動作しない可能性があると警告している。
これは依然として自己申告による実証である。HPもAnthropicも、改変済みイメージ、分析、あるいは結果として得られた設定オプションを公に検証していない。同じノートPCモデルで完全な再現を公表した独立研究者もいない。
この検証上の空白は、Tom's Hardwareの記事に関するすべての解釈を左右すべきだ。ユーザーが示した裏付けの詳細には信頼に足る技術的な筋書きが見られるが、個人による一度の成功実験は、汎用的なBIOSアンロック能力を意味しない。
Tom's Hardwareの見出しはRSA-2048に起きたことを誇張している
Claude Codeは、検証結果を強制するソフトウェア分岐を回避したとされる。RSA-2048アルゴリズム自体を破ったわけではない。
デジタル署名により、デバイスはファームウェアが認可された発行元から提供され、改変されていないかを確認できる。ベンダーは秘密鍵を使って承認済みデータに署名する。検証側は対応する公開鍵を使って、その署名を確認する。
RSA-2048を破ることは、暗号学における重大な成果を意味する。攻撃者が秘密鍵を復元したり、認可なしに署名を作成したり、根底にある数学的仮定を破ったりできる可能性がある。Redditアカウントは、そのような結果をいずれも説明していない。
代わりにユーザーは、Claude Codeが署名結果の処理を担うコードを見つけたと述べている。この改変は、数学的な検証が通ったかどうかにかかわらず、そのコードを成功パスへ進ませたとされる。
分かりやすい例えは、警備員が有効なバッジを確認し、その回答を記録に残す場面だ。報告された改変は有効なバッジを作り出したのではない。警備員が回答を返した後に何が起きるかを変更した。
この違いは、結果を些細なものにするわけではない。圧縮されたファームウェア内で関連する検証器を特定するには、展開、リバースエンジニアリング、コードトレース、慎重なイメージ再構築が必要だった。改変済みバイナリも、マシンが起動するために必要な構造を維持しなければならなかった。
それでも、暗号プリミティブ自体は設計どおりに動作していた。報告された弱点は周辺の強制経路と、システムが改変済みの検証コードを実行することを許容しているように見える点にあった。
Microsoftのファームウェアガイダンスは、この分離が重要である理由を説明している。署名済みファームウェアコードは実行前に検証されるべきであり、認可されていないコンポーネントは実行されるべきではない。より前段の信頼レイヤーが検証機能自体を保護していなければ、検証機能が提供する保護はほとんどない。
ノートPCの所有者は、影響を受けたコードをハードウェアに裏付けられた信頼チェーンに固定するために必要なIntel Boot Guard構造を見つけられなかったと述べた。Intel Boot Guardは、メインファームウェアが続行する前に初期ブートコンポーネントを認証するよう設計されたプラットフォーム機構である。
この主張は、この特定のマシンについて独立して確認されていない。しかし正確であれば、検証器の編集が再起動後も残った理由を説明できる。この実装は、書き換え可能なフラッシュに保存されたコードに、他のコードを信頼すべきかどうかを決定させていた。
ここに中心的な逆転がある。RSA-2048が数学的に健全なままでも、それを使う製品が認可されていないファームウェアを受け入れる可能性はある。セキュリティは、一つのアルゴリズムの名称や鍵長ではなく、完全な検証チェーンに依存する。
この区別には歴史的な前例がある。Nintendo 3DSを調査した研究者らは、パーサーの欠陥により認可されていないファームウェアを受け入れるRSA署名実装を記録した。彼らのboot ROM研究は、RSA-2048の数学的困難性ではなく、署名の処理方法を対象としていた。
HPの改変は技術的には異なる。公開された説明では、パーサーを悪用する不正形式の署名ではなく、変更された制御フローが述べられている。どちらの事例も、「RSA-2048を使用している」というだけでは完全なセキュリティ説明にならない理由を示している。
Tom's Hardwareの表現は、Claude Codeに過度な自律性を与えるおそれもある。人間がファームウェアを提供し、ツールを選び、操作を承認し、結果をテストし、改変済みコードを書き込むリスクを引き受けた。Claudeはユーザーが設計した研究環境の中で動作した。
より正確な見出しは、Claude CodeがHPのあるファームウェアビルドにおけるRSA-2048署名チェックの回避を支援した、とするものだろう。通常は相当な専門知識を求められる分野を、このアシスタントが進めたと報じられている点で、依然として注目に値する。
本当の変化はAI支援によるリバースエンジニアリングにある
この実験は、根底にある脆弱性が従来型のものであっても、コーディングエージェントが高度な技術ワークフローをより粘り強いユーザーにとって利用しやすくできることを示唆している。
ファームウェアのリバースエンジニアリングには歴史的に、アセンブリコード、バイナリ形式、圧縮、暗号技術、ハードウェア初期化、復旧手順にまたがる習熟が必要だった。報告されたワークフローの各ステップ自体は前例のないものではない。すべてのステップを連携させることは依然として難しい。
AIエージェントは、この連携コストを変える。ツール出力を調べ、次のクエリを提案し、小規模な分析ユーティリティを生成し、仮説を追跡し、バイナリレイアウトが予想と異なる場合にスクリプトを書き直せる。この作業には以前、マニュアル、フォーラム、ソースリポジトリを何度も検索する必要があった。
Claude Codeは、ワンショットのハッキングボタンとして動作したわけではないようだ。むしろ、この説明は反復的なプロセスを描いている。ユーザーが専門ツールへのアクセスを提供し、モデルがそれらにまたがる断片的な発見を結び付けた。
このパターンは、目に見えるBIOSタブよりも重要だ。セキュリティ研究の経済性を変えるために、モデルが新たなエクスプロイトを発明する必要はない。より多くの人が、従来の分析をより速く完了できるよう支援すればよい。
この事例はまた、エージェント型システムが会話型チャットボットと異なる理由も示している。エージェントはファイルを調べ、プログラムを呼び出し、コードを生成し、一つの操作の結果を別の操作の計画に利用できる。このループは、進捗が数十に及ぶ小さな技術的判断に依存するタスクで大きな力を生む。AnthropicはClaude Codeを、コードベースの読み取り、ファイル編集、テスト実行、外部ツール横断の作業が可能なエージェント型コーディングシステムとして説明している。
開発者にとっての教訓は、Claude Codeが自律的なファームウェア専門家になったということではない。有能なユーザーが、一つのモデルと複数の決定論的ツールを中心に、一時的な研究チームを構築できるということだ。
提供されたツールは、重要な形の検証基盤をもたらした。逆アセンブラは機械命令を明らかにした。エミュレータは隔離されたテストを可能にした。バイナリユーティリティはファームウェアの内部構造を維持した。モデルの提案は文章として受け入れられるのではなく、プログラム出力と照合された。
この組み合わせはハルシネーションのリスクを低減できるが、排除することはできない。モデルはアドレスを誤解したり、二つのファームウェアフェーズを混同したり、安全でないパッチを推奨したりする可能性がある。通常のアプリケーションコードでは、テストがこのような誤りを発見することが多い。ファームウェアの失敗は、デバイスを起動不能にする可能性がある。
これはAnthropicや他のAIプロバイダーへの圧力を高める。彼らのコーディング製品は、セキュリティ研究、システム管理、ハードウェア制御にまたがって動作する場面が増えている。正当な所有者がノートPCを調査する助けとなる能力は、攻撃者によるファームウェア保護の分析にも使われ得る。
したがって争点となるのは、能力と検証のせめぎ合いだ。モデルはより大胆な変更を提案できるが、ユーザーには依然として、それらをテストする信頼できる手段が必要である。HPの所有者はエミュレーションを用い、復旧用のハードウェアプログラマーも用意していたと報じられている。
ここでは、個人向けナレッジシステムも技術チームの助けになり得る。研究者は長期にわたる調査の中で、ツール出力、仮説、ハードウェア識別子、テスト結果を保存する必要がある。検索可能なエンジニアリング・ナレッジベースは、ファームウェアそのものを検証するふりをせずに、こうした記録を支援できる。
業界全体としては、コーディングエージェントがより特殊な技術環境へ到達することを見込むべきだ。リバースエンジニアリング、組み込み開発、ドライバーのデバッグ、プロトコル解析にはいずれも、モデルが加速できる反復的な作業が含まれている。
この拡大によって専門知識が不要になるわけではない。むしろ、専門知識が不可欠となる地点が変わる。ユーザーはユーティリティスクリプトの作成に費やす時間を減らし、脅威モデルの定義、前提の確認、安全なテストの設計により多くの時間を割く可能性がある。
Tom's Hardwareの事例は、この移行を端的に捉えている。Claude Codeは、ある愛好家が障壁を越える助けとなるだけの分析作業を担ったと報じられている。ただし、その結果の責任を負うのは依然として人間だった。
隠し設定がもたらす所有者の利点とセキュリティリスク
デバイスのロック解除は所有者による制御を取り戻す手段になり得る一方、ファームウェアレベルの実験には、AIアシスタントがユーザーに代わって引き受けられない結果が伴う。
ノートPCメーカーがBIOS設定を隠す理由はいくつかある。一部のオプションは、搭載されているハードウェアには適用されない。他の設定は、メモリー、熱制御、ストレージ、電源管理、起動動作を不安定にする可能性がある。
共有ファームウェアという事情も、別の説明になる。ベンダーは多くのモデルで類似したセットアップコードを使い、各製品で検証済みの項目だけを公開することがある。そのため隠しオプションは、意図的に封じられた動作機能ではなく、未使用のインターフェース部品を示している場合がある。
報告されたGPSオプションは、この限界をよく示している。メニュー項目を表示しても、欠けている無線モジュール、アンテナ、ドライバー、基板接続が生まれるわけではない。表示された項目が機能しなかったり、誤解を招いたり、安全でなかったりする可能性もある。
それでも、より深い制御を求める正当な理由を持つユーザーはいる。高度な設定は、仮想化、ストレージモード、電力チューニング、デバッグ、非対応OSの利用に役立つことがある。修理技術者や研究者も、消費者向けインターフェースが制限しているアクセスを必要とする場合がある。
この緊張関係は、単純にベンダーのセキュリティとユーザーの自由との対立ではない。検証済みの構成と、制御されない実験との対立である。文書化されていない組み合わせが障害を引き起こせば、ベンダーにはサポートや保証のコストが発生する。一方で所有者が、購入したハードウェアに対する権限を期待することにも妥当性がある。
AIは双方を強める。不透明なファームウェアの理解や機能の回復を所有者に支援できる一方、対象の基板で一度もテストされていない組み合わせについて、もっともらしい指示を生成することもある。
元の投稿者は、CH341A系のチッププログラマーを用意しておくことを明確に推奨していた。この種のハードウェアは、ノートPCが起動しなくなった場合にフラッシュチップを直接書き換えられる。この警告は、成功時のスクリーンショットよりも実際のリスク水準をよく表している。
プログラマーがあっても、苦労なく復旧できる保証はない。チップへのアクセスには、ノートPCの分解、正しいパッケージの特定、電圧レベルの管理、元のダンプの保存が必要になることがある。ミスはハードウェアの損傷や、デバイス固有データの消去につながり得る。
ファームウェアはまた、非常に高い特権を持つ位置にある。悪意あるコードや不具合のあるコードは、OSより先に実行され、通常の再インストール後も残存し得る。そのためセキュリティ研究者は、無許可のファームウェア変更を通常のアプリケーションのカスタマイズとは異なるものとして扱う。
最近の学術研究は、静的チェックだけではすべてのファームウェア脅威を観測できないと論じている。Peacock frameworkは、攻撃者が初期チェック後にファームウェアの挙動を操作できるため、ランタイム監視を提案している。この研究は、多層的な保護の必要性を裏付ける。
報告されたHPの事例は、このノートPCがリモートから悪用可能になったことを示すものではない。ユーザーはすでにマシンを所有し、ファームウェアを入手し、意図的に変更済みのイメージをインストールしていた。物理的な所有と意図が、このシナリオの中心である。
しかし、信頼できない主体が影響を受けるフラッシュ領域へ書き込める別の経路が存在すれば、このバイパスの重要性は増す。書き込みプリミティブと弱い起動時強制の組み合わせは、ローカル変更の手法を永続化リスクへと変え得る。
ソース資料には、このモデルにそのようなリモート経路が存在する証拠はない。何百万台ものHPノートPCが現在露出していると示唆するのは無責任だ。この発見は、1つのファームウェアイメージと1件の報告済みインストールに関するものである。
移植性も大きな不確実性である。ファームウェアはモデル、マザーボード改版、BIOSリリースごとに変わる。アドレスは移動し、モジュールは変化し、より強力な信頼メカニズムが同じ手法を拒否する可能性もある。
ユーザーによれば、タブのロック解除変更は別のHP基板に対して試した際にはすでに失敗していた。この結果は、万能スクリプトという考えを損なう。同時に、より興味深い解釈も裏付ける。AIは、個別の研究を対象ごとにより迅速に適応させる助けになるかもしれない。
HPは将来のファームウェアアップデート、より強力な書き込み制御、あるいはより早い段階の検証済みブートコンポーネントによって対応できる。HPは、ハードウェアに裏打ちされたSure Start technology is designed to prevent unauthorized firmware changes and recover compromised BIOS codeと説明しているが、ソース資料はこのコンシューマー向けノートPCにその保護が搭載されていることを立証していない。ノートPCの所有者によれば、最後のファームウェア更新は2024年に提供された。古いコンシューマー向けデバイスは、信頼チェーンの再設計を受けない可能性がある。
Anthropicは、ガードレールに関する別の問題に直面している。この作業には明確なデュアルユースの性質があり、正当な研究と有害な改変の双方を支援し得る。一律の拒否は所有者や防御側を妨げる一方、無制限の自動化は攻撃者への障壁を下げ得る。
妥当な安全境界は、文脈、アクセス、意図、運用上の詳細に依存する。署名チェックが失敗した理由を説明することと、複数のマシンにわたるステルスな永続化の展開を支援することは別物だ。モデルプロバイダーは、すべてのファームウェア作業を悪意あるものと決めつけずに、これらのシナリオを区別しなければならない。
1台の成功事例は一般的な能力を証明しない
この実演はケーススタディとしては説得力があるが、Claude Codeが現代のBIOS保護を確実に解除できる証拠としては弱い。
最も強い証拠は、ユーザーによる詳細な説明である。投稿者はノートPC、BIOS改版、ツール、ファームウェア構造、発見した項目、大まかな検証プロセスを挙げている。また、普遍的な互換性を主張するのではなく、制約も明らかにしている。
最も弱い証拠は、独立した再現だ。別のアナリストが、クリーンなF.68イメージを使って別のHP 15-dw1036neで同じ結果を得たと公に記録した例はない。HPもアーキテクチャを確認しておらず、報告されたバイパスを評価していない。
目に見える結果だけでは、説明内のすべての手順を証明することもできない。新しいメニュータブの写真は、変更されたインターフェースが起動したことを示すだろう。しかし、どのコードパスがファームウェアを受け入れたのか、あるいは別の保護がそれ以前に無効化されていたのかまでは立証しない。
公開されたスクリプトはレビューのための追加資料を提供するが、通常の読者にとって実行は安全な検証方法ではない。責任ある監査では、コードを精査し、バイナリ変換をオフラインで再現し、独自に入手したファームウェアと出力を比較する必要がある。
研究者は、Intel Boot Guardの強制が存在しないという主張も確認する必要がある。この確認は、報告された成功がハードウェアに裏打ちされた信頼の基点の欠如に依存していたかを判断する。また、新しいシステムやビジネス向けシステムについて導ける結論も限定する。
モデルへの帰属は依然として不正確だ。Redditユーザーは主にClaude Opus 4.8を使用し、ときどきClaude Codeを通じてSonnet 5も使用したと述べている。記録からは、どのモデルが各要素を見つけたのか、また最終的な手法をどの程度人間の指示が形作ったのかは切り分けられない。
プロンプト履歴があれば、発見と誘導された実装を区別しやすくなる。ユーザーが可能性の高いモジュール名、既知のファームウェアパターン、候補となる分岐を提示していた場合、Claudeの貢献は、ほぼ独立した探索の場合とは異なる。
トークン数、失敗した試行、経過時間も、より多くの文脈を与える。大幅な介入を要したワークフローにも価値はあるが、クリーンな出発点から再現可能な実行と比べれば、自律的な性能について語れることは少ない。
「AIがRSA-2048を破る」という表現は、この検証に耐えない。報告された変更はRSAの鍵空間を攻撃したものではない。別の層でその仕組みを保護できなかったとされるシステム上で、結果処理メカニズムをバイパスしたものだ。
この訂正は、作業を軽視する口実にすべきではない。圧縮されたファームウェアの中から関連コードを見つけるには、相当な人間の時間を要し得る。オフセットや依存関係を壊さずにイメージを再パックすることも、別の実務上の課題を加える。
重要な問いは、Claude Codeがこの労力を一貫して削減するかどうかだ。1つの逸話では答えられない。有用な評価では、複数の研究者に複数のファームウェア対象を与え、完了までの時間、正確性、安全でない推奨を比較することになる。
そのテストには、保護されたプラットフォームと保護されていないプラットフォームの両方を含めるべきだ。エージェントは、提案したパッチがハードウェアに裏打ちされた検証段階を通過できない場合を認識しなければならない。誤った理論に固執すれば、時間を無駄にしたりデバイスを損傷したりする可能性がある。
研究者は、モデルが隠し設定に対して裏付けのない意味を捏造するかどうかも測定すべきだ。インターフェースのラベルだけでは、機能が動作することを証明しない。最も安全なシステムは、「項目を発見」「項目を表示」「挙動を検証」を分けて扱うだろう。
こうしたテストが存在するまでは、Tom's Hardwareの記事は、報告されたAI支援セキュリティ研究のカテゴリーに属する。汎用的な自動BIOSエクスプロイトを実証したものではない。ただし、専門的なツール利用が非専門家に近づいていることは示している。
これが逸話か転換点かを示す3つのシグナル
次に必要な証拠は、もう1本の劇的な見出しではなく、再現、ベンダー分析、より広範なエージェント評価から得られるべきだ。
最初のシグナルは、同じモデルとファームウェアでの独立した再現である。信頼できる研究者は、クリーンなイメージを入手し、関連モジュールを確認し、変更を再現し、復旧時の注意事項を文書化する必要がある。
再現に成功すれば、技術的な説明がノートPCの信頼パスを正確に描いているという主張は強まる。失敗すれば、記録されていないデバイス状態、事前の改変、または欠けている手順が結果に影響したことを示唆する。
2つ目のシグナルは、HPまたは基盤となるファームウェア供給元からの回答である。ベンダーは、影響を受けたボリュームが別のメカニズムによって保護される想定だったかを確認できる。また、そのノートPCがアクティブなファームウェアサポートの終了に達しているかも明らかにできる。
より早い信頼アンカーによって検証器を保護するファームウェア更新は、この報告のセキュリティ上の重要性を裏付けるだろう。ベンダーが、この変更には制限のない物理フラッシュ書き込みが必要だったと判断すれば、脅威としての意味合いは限定される。
第三のシグナルは、無関係なファームウェアを対象としてもAIエージェントが再現性ある性能を示せるかどうかだ。研究者は、Claude Codeが対象固有の指示なしに、同程度の実装上の欠陥を見つけられるかを追跡すべきである。成功例だけでなく、誤検知や破損したテストイメージも記録する必要がある。
成功が繰り返されれば、AIエージェントがファームウェアのリバースエンジニアリングへのアクセスしやすさを変えつつあることを示すだろう。一貫しない結果であれば、この事例は汎用的な能力ではなく、意欲的な一人のユーザーとモデルによる印象的な協業として位置づけられる。
読者は、AI企業がこうしたシステムをどう説明するかにも注目すべきだ。「コーディングアシスタント」という表現では、逆アセンブラ、エミュレータ、バイナリユーティリティ、暗号テストを連携させられるエージェントをもはや捉えきれない。製品の安全性に関する主張では、ユーザーがモデルの周囲に構築できる環境も考慮しなければならない。
開発者とセキュリティチームにとって、実務的な対応は規律ある検証だ。元のイメージを保存し、テストを隔離し、前提条件を文書化し、デプロイ前にはハードウェア固有のレビューを必須とする。AIが生み出す確信は、復旧手段の代わりにはならない。
ナレッジワーカーにとっても、関連する教訓がある。エージェントは、その作業が追跡可能な証拠に基づくとき、より有用になる。プロンプト、出力、バイナリハッシュ、テスト時の観察結果を構造化されたパーソナルナレッジシステムに保存しておけば、後からのレビューが可能になる。
Tom's Hardwareの見出しは、Claude CodeをRSA-2048と対峙させるため注目を集めるだろう。しかし、長く残るストーリーはそれほど映画的ではない。報道によれば、ユーザーはAIエージェントと専門ツールを組み合わせ、堅牢な暗号技術の周辺にある弱点を見つけたという。
それでも重要な意味を持つ。セキュリティはしばしばコンポーネントの接続部分で破綻し、コーディングエージェントはそのつながりをたどる能力を高めている。次の問いは、独立した研究者が元のユーザーの前提を引き継がずに、この結果を再現できるかどうかだ。
それまでは、このBIOS改変を、技術的にはもっともらしく慎重に記述されているものの、未検証のケーススタディとして扱うべきだ。再現実験を追い、ベンダーからの回答があれば精査し、破綻した執行と破綻した暗号技術を区別してほしい。
