MozillaのMythos実験をきっかけに、AIがFirefoxから271件の脆弱性を発見したことがソフトウェア開発の信頼モデルをどう変えるのかを論じる動画である。人間が書いたコードを信頼の基準とする時代から、AIによる敵対的検証とエージェント型パイプラインが品質保証の中心になる時代へ移行しつつあるという視点を解説している。
Mythosが変える人間のコードへの見方
この話の核心は、Mythosと、それが人間のコードに対する見方をどう変えるのかという点にあります。私たちはずっと、人間が書いたコードこそが、自分たちの仕事としてできる限り最善のものだと考えてきました。AIが書くコードなんて大したことはない。実際、シリコンバレーには、2010年代の名作テレビ番組でAIコードのひどさを笑いにするようなジョークさえありました。
そしてまさにそれが、2023年や2024年、さらには2025年にも私たちが当然のように抱いていた前提でした。でも2026年になった今、状況は変わっています。なぜなら、AIが書くコードが最終的にゴールドスタンダードになり、人間のコードよりも信頼されるようになる地点に近づきつつあるからです。
これは実際に起きていることです。インターネット上で最も尊敬されている組織の一つに関わる、最も尊敬されているエンジニアたちの一部が、そう示唆しているのです。だから私たちは注意を払うべきです。たとえ可能性として考え始めるだけでも、これはエンジニアの仕事に対する考え方を変えることになります。システムをどう設計するかについての考え方も変えることになります。
では本題に入りましょう。MozillaのMythos実験で最も重要なのは、AIがFirefoxのバグを見つけたことではありません。重要なのは、優秀な人間のエンジニアがこれを書いた、という文が、以前よりずっと弱いセキュリティ上の主張に感じられるようになったことです。
それは奇妙に聞こえるかもしれません。というのも、ソフトウェアの歴史全体を通じて、基本的に人間が書いたコードが信頼の起点だったからです。人間がコードを書き、機械はせいぜいそれを確認する手助けをする、という構図でした。
しかし、モデルがコードを攻撃し、テストし、修復し、検証する能力において十分に優秀になれば、信頼モデルは反転します。そしてすでに反転し始めている兆候があります。この動画はその反転についてのものです。なぜAIコードの実装が事実上の標準になりつつあるのか。なぜ人間のコードへの信頼が揺らぎ始めているのか。そしてプログラミングの未来が、今のようにコードを個人的に詳しく調べたり、さらには個人的にレビューしたりするものではなく、ソフトウェアが何を意味してよいのかを定義し、エージェントにそれをレビューさせるものに近づいていくのか、という話です。
私たちはすでに、優れたエージェント型パイプラインの中にその兆しを見ています。ここではさらに先へ進みます。
Mozillaは最近、ゼロデイの日々は残りわずかだ、という投稿を公開しました。短く言うとこうです。MozillaはAnthropicのclawed methosプレビューに早期アクセスし、それをFirefoxに向けました。そしてFirefoxバージョン150には、Mythosの評価中に特定された271件の脆弱性の修正が含まれて出荷されました。
Firefoxは当然ながら、テストもない適当な週末プロジェクトではありません。世界でも最もセキュリティが強化されたオープンソースコードベースの一つです。ブラウザは過酷な標的です。なぜなら、インターネット上の信頼できないコンテンツを常に処理しているからです。すでにファジング、サンドボックス化、メモリ安全性への取り組み、社内セキュリティチーム、バグ報奨金プログラム、そして長年にわたる苦労の末に培われた健全な疑い深さがエンジニアリング文化に組み込まれています。そうである必要があります。
それでもMozillaによると、AIシステムであるMythosは、たった1回のリリースサイクルで271件の脆弱性を浮かび上がらせました。AnthropicのOpus 4.6 sixとの以前の共同作業では、Firefoxバージョン148でセキュリティに関わるバグが22件見つかり、そのうち14件が高深刻度でした。
つまりこれは、以前私が話したような、AIがコードレビューを手伝ったというだけの話ではありません。これは、コード内の脆弱性発見における新しい産業プロセスのように見え始めています。そしてそれは、人間のコードの品質についての考え方に挑戦しています。
ただし、ここは慎重にいきたいところです。なぜなら、このあたりで誇大宣伝はあっという間に暴走するからです。これは、今日すべてのAIが安全なコードを書けるという意味ではありません。シニアエンジニアをモデルで置き換えるべきだという意味でもありません。むしろその逆です。AIが生成したすべてのパッチが信頼できるという意味でも、まったくありません。
AIコーディングツールを真剣に使ったことがあるなら分かるはずです。AIはAPIを幻覚することがあります。エッジケースを見落とすことがあります。安全でないデフォルトを作ることがあります。そして、もっともらしく見えるのに、システムの要点を静かに誤解したコードを生成することがあります。
優れた人間のエンジニアは、プロダクトの意図、組織上の文脈、ユーザーへの約束、保守コスト、そして現実世界で本物のソフトウェアを機能させる、明文化されていない奇妙な制約を理解する点では、今でもモデルより圧倒的に優れています。
だから要点は、AIが今やエンジニアより優れている、ということではありません。要点はもっと具体的で、正直に言うとずっと居心地の悪いものです。
人間のコードが信頼されてきた本当の理由
人間が書いたコードを私たちが信頼してきた理由は、人間が完璧だからではありませんでした。私たちがそれを信頼してきたのは、人間の判断こそが、正しい抽象度でソフトウェアを作り、理解できる唯一のものだったからだと思います。
エンジニアが実装を書きます。エンジニアがエッジケースを想像します。エンジニアが差分をレビューします。エンジニアがある程度、システムを頭の中に保持します。ツールは手助けしました。でも実装という中心的な行為は、人間の職人技でした。
Mythosは、それが自明ではなくなる世界を指し示しています。なぜなら、機械がコードの結果を徹底的に探索する能力で人間を上回るようになれば、人間が書いたという事実は私たちにとって信頼の起点ではなくなるからです。それは未検証のリスクの一つの発生源にすぎなくなります。そう考えると、かなり奇妙です。
これを理解する一番すっきりした方法は、通常混同されがちな二つのものを分けて考えることだと思います。意味と実装です。
コードは常にその両方でした。コードは機械が実行できる成果物ですが、同時に意図を表す人間の言語でもあります。関数名、型シグネチャ、モジュール境界を書くとき、テスト、コメント、エラーメッセージ、API契約を書くとき、あなたは機械に何をすべきかを伝えているだけではありません。他の人間に、そのシステムが何であるべきかを伝えているのです。
この意味の層があるからこそ、コードレビューは成り立っています。レビュー担当者はコードを見て、なるほど、これが何をしようとしているのか分かる。このシステムの形が分かる。なぜここにこの境界があるのか分かる。この部分は筋が通っている。でも、と言って、そこから批判したい内容を述べるわけです。
セキュリティ上の失敗は多くの場合、コードが人間にとって意味していることと、コードが実際に許していることの隙間に存在します。これは非常に深い話です。なので、ここは2回か3回聞き直してほしいくらいです。中身がたくさんあります。
言い換えると、作者は、このパーサーは一つの形式を受け付ける、というつもりで書きました。しかし実装上は、二つのパーサーが食い違うことができ、その攻撃は、それらのパーサーが一致するか食い違うかの間に存在できる、ということです。
人間が意図している意味と、技術的な解決策が実際に許していることの違いは、セキュリティ問題の核心です。人間は意図された意味を見ます。攻撃者は実際の振る舞いを探します。脆弱性研究とは、基本的にコードの敵対的な解釈です。それは、作者が自分はこう書いたと思っていたことに関係なく、このコードは何を許しているのか、と問うものです。
ちなみに、プログラマーでなくても、意図しなかった形で解釈される文章を書いたことが一度もないのなら、あなたはあまり物書きとは言えません。というのも、書く人なら誰でも経験があるはずだからです。自分では完全に明快だと思って何かを書いたのに、読者は違う受け取り方をした。ここで話しているのはその違いです。
敵対的なコード解釈とは、基本的にコードをエッセイのように読み、ああ、ここであなたはこれを許していますね。許すつもりはなかったのでしょうが、相手の読み方で読めば、そう解釈できてしまいますね、と言うようなものです。エッセイなら、それについてインターネット上で議論できます。彼がこう言った、彼女がこう言った、という話で済みます。
でもコードの場合、コードはコンピューターを制御できるようにします。そしてコードの読み違いや、コードの読み方の違いがあると、大きな結果につながります。だからこのすべてが重要なのです。そしてだからこそMythosは興味深いのです。
Mythosは、ここで既知の悪いパターンを探しているだけではありません。非常に知的であるがゆえに、研究のループに参加しているように見えます。コードを読みます。仮説を立てます。ツールを使います。テストケースを生成します。問題を再現します。発見内容を洗練させます。そして問題を説明します。
GoogleのProject NaptimeとBig Sleepも同じ方向に進んできました。この言葉が本当に実在するなんて信じられませんが、実在します。OpenAIのCodex securityも明確に似たループを中心に作られています。コードベースを理解し、脅威モデルを構築し、サンドボックス内で問題を検証し、人間のレビュー用にパッチを提案する、というループです。DARPAのAI Cyber Challengeは、大きなコードベース全体で脆弱性を見つけて修正する自律システムをテストしました。
これらの細部は異なります。しかし、自律システムで起きていることの形は非常に一貫しています。そして私たちはそこに注意を払う必要があります。モデルは私たちのためにコードを書いているだけではありません。モデルは本質的に、私たちのためにコードを尋問し、意味が一通りにしか読めないようにすることを学んでいるのです。
そしてモデルが人間よりも上手にコードを尋問できるようになると、この数週間でその転換点に達した兆候がありますが、問いは変わります。優秀なエンジニアがこれを書いたのか、ではなく、この実装は機械規模の敵対的精査を生き残ったのか、になるのです。
この変化だけでも、サイバーセキュリティ業界全体より大きなものです。なぜなら、私たちの前提すべてを変えるからです。
実装から意味へ移る人間の役割
ソフトウェアは以前にも、これに似た変化を経験しています。だから私たちはそれが起きるところを見たことがあります。しかしこれは、この20年で間違いなく最大の変化です。
かつてプログラマーであることは、もっと機械に近いところで書くことを意味していました。その後、アセンブラ、コンパイラ、ガベージコレクタ、マネージドランタイム、型システム、パッケージマネージャ、やがてクラウドプラットフォーム、デプロイシステム、可観測性ツールが登場しました。それらはすべて、実行に関わる部分を人間の手から遠ざけていきました。なぜなら、人間は同じプロセスを何度も何度も大規模に繰り返す存在としては信頼されていなかったからです。
Amazonでは、善意はスケールしない、仕組みが必要だ、という言い方をしていました。そうしたものがすべて起きたとき、私たちは人間がコンピューティングに関わらなくなったとは結論しませんでした。ただ、人間の役割がより高い抽象度へ移ったのだと結論しました。
ほとんどのプログラマーは、もはや手作業でメモリに配置したりしません。なぜなら、その作業は遅く、壊れやすく、大規模に検証するのが非常に難しいからです。そしてほとんどと言いましたが、私の知る限り、それをしている人はいません。責任ある人間の役割は、アルゴリズム、アーキテクチャ、データモデル、インターフェース、システムの振る舞い、意図へ移っていきました。なぜなら、より低いレベルのプリミティブを信頼できるようになったからです。
今、セキュリティはその移行をさらに強く押し進めています。Mythosの話が本当に示しているのはそこです。
そして私たちは過去にも、開発者に何かを任せるのをやめてきました。開発者が気軽に暗号技術を書くことを信頼しなくなりました。それはもう許されません。より安全な代替手段が現実的になると、大規模なソフトウェアの多くの領域で、手動のメモリ管理を信頼しなくなりました。自動化、ロールバック、可観測性、ポリシー制御なしで手作業で本番デプロイすることを信頼しなくなりました。
どの場合でも、人間のスキルが消えたわけではありません。しかし人間による実行は、安全であるという推定を失いました。コードそのものが次に、人間による安全性の推定を失う対象になるのかもしれません。
すべてのコードではありません。明日でもありません。プログラマーが消滅するという芝居がかった意味でもありません。しかし今日でさえ、2026年の2月、3月、4月を経て、私たちがエージェント型コーディングを信じ、エージェント型パイプラインを構築しつつある今でさえ、私たちはまだ、コードが安全であることを確認するために人間がレビューする重要性について話しています。
しかしMythosが私たちに教えているのは、その日々でさえ残りわずかなのかもしれないということです。Mythosそのものが、コード内の脆弱性やセキュリティリスクを見つける点で、人間が到底到達できないほど優れている可能性があるのです。
もしそうなら、人間の抽象度はさらにもう一段上がる必要がある地点に、私たちは到達しつつあるのかもしれません。そして人間の役割は、Mythosのようなものが行ったことをレビューし、ソフトウェア全体の意味がプロダクトの意図と一致していることを確認することになるのです。
それこそが本当の反転です。人間は消えていませんし、これからも消えません。しかし人間は、より意味の層へと移っていくことになります。
ここで、AIは私たちの代わりにコードを書くのか、という議論の多くが、いかに真面目さを欠いているかが見えてきます。ここで私がそう言うのは皮肉ですよね。まさにそこに向かっていると思うでしょうから。でも多くの人は、コーディングがタイピングと同じだと想像しています。だから未来を、タイプする人が減ることとして想像してしまうのです。
違います。私たちは想像をもっと広げなければなりません。そもそもコーディングは、開発者の一日の中で最大の部分ではありませんでした。最初から、タイプすることが難しい部分ではなかったのです。難しかったのは、何が存在すべきで、何が存在すべきでなく、その区別をシステムが変化する中でどう保つかを知ることでした。
その意味を頭の中に保持することは、シニアエンジニアにとって今後も非常に重要であり続けます。AIによってコードを作ることが安くなり、安全に作れるようになるとしたら、そしてそれが今Mythosをめぐる大きな議論ですが、それはソフトウェアが楽になるという意味ではありません。ただ、希少なリソースが何かを変えるだけです。
AIについては、この点をもっと話したいと思っています。実装は当然、豊富になります。そしてソフトウェアを理解する能力は、私たちがそこに投資しない限り、より希少になります。
今、私たちはソフトウェア層から見てきれいな抽象であるプリミティブに投資できます。そうすれば、何が作られているのかを理解し、その意味を翻訳できます。実際、私はこれをいつもやっています。誰かが私にコード片を送ってきたとき、実際によく送られてくるのですが、私はまずCodexやClaude Codeのようなツールを通してそれを見ます。そして自分に問いかけます。この箱の中身は何か。アーキテクチャはどうなっているのか。ここでの抽象レベルは何か。
私はもう、行ごとに見ることはほとんどありません。ほぼまったくありません。そしてそうする必要も感じていません。なぜなら、私が持っているツールは、正しい抽象度で作業することを可能にしてくれるからです。
私たちが話しているのは、セキュリティ領域でそれと同じ種類の移行が起きるということです。つまり、自分のコードについてMythosが言うことを信頼する、という世界です。
Mythosが200件以上の脆弱性を見つける。私たちはその修正に集中します。しかしその後は、高深刻度の脆弱性が存在しない世界へ進みます。なぜなら、コード内の非常に高価で、非常に恐ろしいゼロデイ脆弱性を見つけにくくする状態から、解釈不可能にする状態へ移るからです。言い換えると、それらは消えるのです。私たちはそれらを野生環境から絶滅させようとしているのです。
皮肉なことに、これは2026年のセキュリティの会話をまったく別の方向へ持っていきます。多くのセキュリティ研究者から聞き、正直に言えば多くのメディアで読むような、AIによって物事がより恐ろしくなる、という話ではありません。むしろ私たちは、反撃するためのほぼ完璧な武器を手にしている、と言っているのです。
今や、セキュリティ脆弱性のない完璧なコードに到達することは可能です。ただ、適切なAIシステムにそれを読ませ、そのAIが指摘したものを信頼性高く修正させる必要があります。そしてそれをエージェント型ビルドパイプラインに組み込み、何かを作るときに実際にレビューし、ユーザーとの信頼を壊さずにローンチできるようにしなければなりません。
私が言っているのは、もしそれが本当なら、ソフトウェアの作り方についての考え方は変わらなければならないということです。2月や3月の古いモデル、つまり最後に人間がレビューすべきだ、というだけではありません。最後にMythosのようなモデルがレビューし、そのうえで私たち人間が、作られたものの全体的な意味を見て、このソフトウェアで進もうとしている方向に沿っているかを判断する世界になるのです。そして私たちは、安全でないコードをローンチしていないか心配しなければならない状態から解放されます。
皮肉なことに、私たちはAI生成コードを品質の印として探し始めるかもしれません。それが、私たちが向かっているソフトウェアサプライチェーンだと思います。
AIレビューが組み込まれるソフトウェア供給網
私たちはもはや、手作業でソースコードを変更することについて話しているだけではありません。しかし近いうちには、手作業でレビューするエージェント型パイプラインについてさえ話さなくなるでしょう。
ただし、誰もがMythosを持っているわけではありませんし、すべてのAIシステムが同等だと言っているわけでもありません。だからMythosを持っていないなら、単に別のAIに置き換えて、ネイトがコードレビューにAIを使えと言っていた、などとは言わないでください。特定のシステムだけです。コードレビューにAIを入れるなら、それが実際に機能することが証明されていなければなりません。AIが間違えることと、AIが正しくやることには大きな違いがあります。そしてそこには知能の壁があります。どうやら私たちは、その壁を越えたばかりのように見えます。
ですから、ここ数カ月で、それができるシステムはもっと増えると思います。信頼できるシステムに到達する唯一の方法は、証拠を通じて信頼を強制する習慣を持つことです。
私が本当に主張しているのは、私たちのパイプラインを、最後に非常に優秀な人間がサインオフして、これは私たちの衛生基準とコード基準に沿っている、これはプロダクトの意図に沿っている、これはクリーンなコードだと言えるように設計し始めることです。今日のほとんどのケースでは、それがベストプラクティスです。
あるいは、今日のソフトウェアパイプラインの2、3%くらいはこうしています。自分たちの評価が非常に優れていると信じているので、最後に人間を置かない。評価を信頼する、というものです。今日は非常にまれです。実際にあります。世界の終わりではありませんが、本当に本当に優れていなければなりません。
あるいは、Mythosのような最先端のAIシステムを使い、それをレビュー担当にする、と言うこともできます。ただし今日で言えば、Mythosを持っている場合に限ります。つまり、適切なモデルを持っていなければならないのです。
ただ、私はMythosだけがこの地点に到達するとは思っていません。これを、Claudeだけができることだと誤解しないでください。たとえば、Chad GPT 5.5にもMythosと同じようなセキュリティ嗅ぎ分け能力がいくつかあるという証拠があります。ただし、セキュリティについての横並びのケーススタディははるかに少ないので、確実には分かりにくいです。そして当然、将来のChatGPTモデルが公に追いついてくることを私は期待しています。Claudeが計算資源面で追いつくにつれて、Mythosのような能力を持つClaudeのバージョンが広く出てくることも期待しています。そして最終的には、ダリオが言うように、おそらくクリスマス頃までには、オープンソースモデルもこの地点に到達すると期待しています。
年末までには、私たち全員がNethosikeな能力を持つようになるでしょう。私はそれについてかなり確信しています。だからこそ、これは重要なのです。年末はそれほど遠くありません。私たちはすでに今、ソフトウェアの作り方についてどう考えるかを話しています。そして私たちは、こうした変化を前提にできるようなパイプラインを作りたいのです。
ですから、もしあなたのパイプラインがエージェント型ビルド向けにモジュール化されていて、今日プリンシパルエンジニアがコードをレビューしているなら、それは素晴らしいことです。その役割について考えてください。そして、それがどれほどモジュール化されているかを考えてください。4カ月か5カ月後には、それをMythos、あるいはMythos相当のものに差し替えたくなるかもしれないからです。意識して、準備しておいてください。
そしてその間に、どうやって価値と品質を強制していくのかを考え始めてください。プリンシパルエンジニアからの品質証明をどう得るのか。基本的には、はい、これは十分に良いです。これは本物です。これは良いコードです、と言える状態です。
そして、良いという基準をどれほど明確に定義すれば、Mythos相当のものがやって来たときにそれを自動化できるのかを考えるのです。そうなると、非常にきれいな評価になります。
Mythos自体は、創造的であること、テストケースを書くこと、コードを敵対的に解釈することに十分優れています。だから、安全とマークされたなら、実際に安全であるとかなり自信を持てます。なぜなら、Mythosの技術の多くは、単に評価に従うことではないように見えるからです。優れた評価を書いても、なおコードが安全でない状態になることはあります。安全でないコードというのは、部分的には創造性の行為だからです。
それは単に、そのコードがX、Y、Zを行う、という話ではありません。この点でクリーンなコードであり、あの点でもクリーンなコードである、という話だけでもありません。それは同時に、コードを敵対的に読み、最悪の可能な解釈を加え、壊そうとすることでもあります。そしてMythosはそれが非常に得意に見えます。
現時点で、Mythos以外にそれを世界で最も上手に行える人々は、優れたセキュリティエンジニアのようです。だからこそ、優れたセキュリティエンジニアはコードを注意深く読めるよう、良いコード衛生を強く求めます。そしてだからこそ、評価を書くときに彼らは非常に重要なのです。
少し横道にそれますが、多くの人はエージェント型パイプライン向けの評価を書くとき、80%はここで機能するコードについてで、20%、あるいはそれ以下かもしれませんが、良い衛生状態に関する非機能要件にしています。違います。違います。違います。少なくとも評価の半分は、自分が書くコードの品質についてであるべきです。
関数ごとの行数を一定数に抑えることを求めるべきです。そうすればコードをレビューする人を混乱させません。特定の表現をどう解釈するか、依存関係をどう扱うか、自分が選んだプログラミング言語で何を許し、何を許さないか、許容する表現、信頼できないと分かったために許容しない表現について、自分たちの基準と衛生ルールを持つべきです。どの言語にもそれぞれのバージョンがあります。興味があるなら掘り下げられます。
実際、この文字起こしをそのままChad GPTやClaudeに渡して、さまざまなコーディング言語において、セキュリティ研究者の間で信頼しにくいことで悪名高い表現について教えて、と聞くこともできます。どの言語にも固有のばらつきがあるからです。それをすべて評価に書き込めます。
そのすべて、そのプロセス全体、つまり評価におけるコード衛生と良いコードアーキテクチャを20%から50%へ引き上げることは、それでもまだ、優れたセキュリティ研究者に対して、あなたのコードを読みやすくする優れた眼鏡を与えるだけです。それは素晴らしいことです。そして評価を通過すれば、それはレビューして安全だと認証できるものになる可能性がはるかに高くなります。
しかし数カ月後には、Mythosがそれをすべてあなたのために行えるようになります。Mythosは評価を通過させる部分を担い、あなたが最後に、偏執的で創造的なセキュリティ研究者に一度見てほしいと思う部分も担えます。Mythos、あるいはMythosのようなモデル、もしかするとChad GPTから、もしかするとGoogleから、もしかすると別のどこかから出るものが、それを行うでしょう。
最終的にこれは、強いエンジニアリング文化を作ることについての話です。私が話していることの多くは、強いエンジニアリング文化を作ることなのです。
ですから、AIが急速に進む世界で未来にどう備えるべきかを考えているなら、この動画をブックマークしてください。この動画は、先を見通す方法の一部です。もしMozillaでMythosが今日これをやっているのなら、私たち全員が数カ月後にはこの世界に住むことになります。
私たちのエンジニアリング文化は進化しなければなりません。ビルダーである私たちは、Mythosのようなツールをモジュール化して差し込み、自分たちよりもそれを信頼すると言える抽象度へ移らなければなりません。なぜなら、私たちはすでに安全だと認証した既存コードにそれを実行し、それが私たちの見逃した脆弱性を見つけたからです。それほど創造的なのです。私たちに必要な敵対的解釈の能力を持っているのです。人間が発見したというだけでは安全は保証されません。それは単に、これまで私たちが持っていた最良のものだっただけです。
ゼロデイ脆弱性は、持ちうる中で最も恐ろしいものですが、ベンダーがそれを知り、理解し、修正し、修正を出荷し、ユーザーがそれを導入したときに初めて、ゼロデイ脆弱性ではなくなります。世界には、修正が存在してからも長い間脆弱なままのシステムがあふれています。エンタープライズアプライアンス、エッジデバイス、放棄された依存関係、企業内の内部ソフトウェア、産業システム、古いAndroidフォークなどです。
モデルがバグを見つけても、システムが魔法のように治るわけではありません。だからこそ、21世紀のエンジニアリング文化について考えるとき、私はこうしてほしいのです。AIによって出荷が非常に簡単になるので、あなたはこれまで以上に多くのソフトウェアを出荷することになります。Mythosの物語とは、それらのゼロデイを、外に出る前に止める物語です。
最高のソフトウェアとは、そもそもバグを生まなかったソフトウェアです。あなたが生きる世界では、これまで出荷したソフトウェアは、これから出荷するすべてのソフトウェアの氷山の一角にすぎないと考えてください。企業としてこれから出荷するソフトウェアの90%は、まだ先にあります。AIの時代にはそれが統計的にあり得るからです。私にとってAIコードは非常に安いからです。その90%を正しくやってください。Mythosのようなシステムを導入する準備ができていることを確認してください。
そしてあなたができる最善のことは、この動画で説明したように、エージェント型パイプラインを構築することです。評価に合わせてそれを書きます。今日の時点では最後に人間のセキュリティ研究者がそれを見ます。そして適切な品質のモデルが登場したら、そこをモデルに差し替える準備をしておきます。
そのうえで、すでに外に出ているものの修正に取りかからなければなりません。Mythosのような能力を適用して、自分たちが持っているものを見直し、積極的にパッチを当て、デプロイする必要があります。
ちなみに、Mythosが一部の組織にだけリリースされている理由は、それらの組織がインターネット上で最も強力なシステムの一部を管理しているからです。3カ月か4カ月後に、そうしたシステムの一つによってMozillaが敵対的に攻撃されることは望ましくありません。私たちはMozillaに強化されていてほしいのです。それこそAnthropicが考えたことであり、だからこそこのような形でリリースしたのです。
ここでのより深い制度的な意味については、Substack用に取っておきます。オープンソースのメンテナー、開示規範、資金、そして小規模チームが本物の脆弱性報告であふれ、処理する能力を持たないときに何が起きるのかについては、まったく別のエッセイがあります。この動画よりも深く読む価値があります。
ここでの実践的なポイントはもっとシンプルです。良いコードベースが読みやすいのは、人間が読みやすいコードを好むからだけではありません。それは副次的な利点です。良いコードベースが読みやすいのは、友好的な機械によって攻撃されうるからです。そして自分たちを守る最善の方法は、コードを読みやすくし、クリーンなアーキテクチャをAI研究者が明確に推論するために使えるようにすることです。
狭いモジュールは制約しやすいです。明示的な境界はテストしやすいです。小さなインターフェースは検証しやすいです。良いテストはモデルにフィードバックを与えます。明確な仕様は、モデルが満たすべきものを与えます。
技術的負債は、最近ではずっと直接的にセキュリティ負債になります。なぜなら、私たちは非常に速く作っているからです。乱雑なコードは単に迷惑なだけではありません。乱雑なコードは極めて危険です。乱雑なコードは、それをより安全にし得るAIツールに対して構造的に抵抗するかもしれません。
言い換えると、私たちにはここで黄金のリファクタリング期間があるのかもしれません。そしてこれが、理解可能性がまもなくセキュリティ特性になると私が考える理由です。人間が理解しているベストプラクティスのセキュリティに沿って、AI研究者が解釈できるようにコードをリファクタリングすることが理にかなう4カ月から5カ月の期間があるかもしれません。人間が理解できないシステムは、AI研究者にとっても理解しにくいものになるからです。ついでに言えば、それは人間によって統治されることも難しくなります。
根本的には、組織がそのシステムがどんな約束をしているのか理解していないなら、意味の層は崩壊します。私はここで、あなたのコードを解釈可能にしてほしいと訴えています。
目標は、読みやすいコードを、機械が出力した不可解なものに置き換えることではありません。AIによって私たちが向かう先がそこだと考えている人がいるのは分かっています。私はその逆を訴えています。そしてAIのトレンドは読みやすいコードの方向だと伝えています。なぜなら目標は、実装をより機械的に信頼できるものにしつつ、人間がシステムについて考え、システムについて推論するために必要な意味構造を保つことだからです。
それが基準です。それが私たちの目指すものです。自然言語を入れればアプリが出てきて、はい大丈夫、動きます、というだけの話ではありません。むしろ、自然言語を入力し、トレース、証明、型システム、テスト、敵対的レビューのすべてをエージェント型パイプラインの一部として考え、それが通るかを見て、人間がそれに意味があると同意するかを見る、というものです。
最後には、人間が複数の精度レベルで意図を記述します。モデルが実装を提案できます。別のモデルがその実装を攻撃できます。ツールは何が起きたかの証拠を生成できます。そして最後に人間、おそらくポストMythos時代の非常にシニアな研究者たちが、Mythosレビューサイクルの証拠を検査し始め、ソフトウェア全体の意味を修正し、そのシステムを出荷してよいか判断できます。
つまり本当に私たちは、コードベースそのものがゴールドスタンダードである世界から、コードベースが意図、実装、検証の束の下にあるという考え方へ移行しています。その束は、これから大規模にレビューする必要が出てくるエージェント型パイプラインによって生み出されるものです。
そしてこれは、価値ある開発者がどんな姿に見えるかを変えます。価値あるエンジニアとは、単に巧妙なプロンプトを作れる人ではありません。はい、ここで私はわざとそう言いました。コードを書くとは言っていません。巧妙なプロンプトを作る、と言いました。価値あるエンジニアとは、安全に実装できるシステムを定義できる人です。
その人は、プロダクトの意図を、事業全体のコード衛生慣行の中で、非常に明確な基準と仕様へ変換する方法を知っています。システムを検証可能な境界へ分解する方法を知っています。権限の漏れを最小化するAPIを設計する方法を知っています。ここで言いたいことは分かりますよね。そうしたものすべてを構築する方法を知っているのです。
ですから、人間の判断はここで重要性を失うのではありません。意味がシステムに入る場所に集中するのです。これは実は、シニアエンジニアリングが本来そうであるべきだったものに近いです。ただ、多くの場所では必ずしもそうではありませんでした。
エンジニアが経験を積むほど、その価値はすべての行を自分で打つことからは遠ざかります。彼らは抽象を定義します。隠れた結合に気づきます。小さなプロダクト上の選択がなぜセキュリティ問題を生むのかを理解します。システムが読みにくくなりつつあるときに気づきます。そもそも私たちが、このセキュリティアーキテクチャ全体を支えるためにシニアエンジニアに依存してきた理由は、彼らがそうしたことに優れているからです。
そしてAIは、意味を理解するその能力を消し去るわけではありません。ただ、それをどこに適用するかを変えるのです。
だから私が、信頼される人間のコードという時代の終わりに近づいていると言うとき、そして私はそれが起こる可能性が高いと思っていますが、それは明日から人間がコードを書くのをやめるという意味ではありません。意味しているのは、エンジニアリング文化を作る私たちのデフォルトの前提を、今すぐ変え始める必要があるということです。
今日、人々はAI生成コードが危険だと心配しています。なぜなら、実際には誰もそれを書いていないからです。しかし高保証の環境では、やがて人間が書いたコードが危険だと心配するようになるかもしれません。なぜなら、誰もそれを徹底的に敵対的に探索し、推論していないからです。
この世界では、生成されたコードはモデルから来たから信頼されるのではありません。検証されたプロセスから来たから信頼されるのです。言い換えると、未来に築こうとしているエンジニアリング文化を考えるとき、あなたは自分のコード品質に署名し、認証し、保証するエージェント型パイプラインを構築しているのです。そしてエンジニアは、ソフトウェアの意図を維持するためにそこにいることになります。
そして、やがてと言っても、5月10日、5月15日、5月20日という話ではありませんが、おそらく12月までには、という意味です。それほど遠くありません。個人貢献者なら、その時点に向けて自分のスキルセットについて考え始める時間はほとんどありません。チームのリーダーなら、自分のシステムをどう設計し、これに備えるためのエージェント型パイプラインをどう整えるかについて、今すぐ考え始めなければなりません。そしてCTOなら、まさに今、それらすべての計画と予算づけを始める必要があります。
もちろん、人間は今後もソフトウェアが何を意味するかについて責任を持ち続けます。むしろ、より責任を持つかもしれません。機械は、システムがどんな約束をすべきかを決められません。どんな失敗が道徳的に許容できるかを決められません。ユーザーがどのような権限を持つべきかを決められません。
しかし、その約束を実行する部分は、人間が個人的に書くのではなく、人間が監督するループのものになっていく可能性があります。その世界では、エンジニアは写字生というより、機械のための憲法設計者に近くなります。私たちはその権限、限界、権利、義務、正当性のテストを定義します。
ものすごく抽象的に聞こえますよね。でも、今日あなたが持てる実践的な持ち帰りスキルは、より良い仕様を書くことです。私は仕様と明確な意図についてたくさん話しています。まるで太鼓を叩き続けているように感じます。それが重要な理由は、今仕様を書き下せないなら、6カ月後にMythosのようなツールが使える、良くて明確なソフトウェアで本当に苦労することになるからです。
これはジュニアにも当てはまります。これを聞いて、自分はシニアエンジニアではない。アーキテクトとして信頼されているわけでもない。これがすべて始まったら何が起こるのだろう、と思っているなら、より良い仕様を書いてください。意図の明確さにワクワクしてください。具体性を求めてください。具体性は技術的負債とセキュリティ負債の敵です。
良いコードファイルには、それに対応する動詞があります。それは何かをします。自分のコードについて、そこまで明確になれるようにしてください。コードが動くかどうかだけを問わないでください。それが守れるほど読みやすいかを問うてください。
Mozillaの実験は初期のものです。ツールは不完全です。これをあと何度か再現する必要があります。私たちの周囲の組織、多くの開発チームも含め、この世界への準備はできていません。私がこれを伝えているのは、方向性が見えているからです。すでにこの方向へ動いている企業があります。Mozillaが今日このことを書いているなら、それについて話さず、ただ実行している企業が他に10社はあります。断言できます。
AIがコードを読み始めること自体は構いません。しかしあなたは、AIをコードの保証者として考え始める必要があります。そしてその世界を可能にするパイプラインをどう整えるかを考え始める必要があります。なぜなら、ソフトウェアの未来は、人間が安全なコードを書くという信念の上には築かれないと、私は今や確信しているからです。
それは、人間が意味あるシステムを定義する能力と、機械が実装がそれを裏切っていないことを証明する能力の上に築かれます。これこそが、私たちが一緒に頭に入れなければならない変化です。実装は非常に安くなっていきます。ゼロに近づいていきます。ソフトウェア開発のコストは、ほとんど何もないところへ向かいます。ソフトウェアに対する確信と信頼のコストは、それとは別物です。それは高価かもしれません。なぜなら、それは保証されなければならず、そのためには全体のパイプラインと、おそらくソフトウェアを見守るチームが必要だからです。
だから私たちは、開発のあり方をますますその保証の方向へ移していくことになります。
これについてより深い書き物版が欲しいなら、実装者、エンジニア、エンジニアリング文化を作る人向けに、もっと詳しく書いています。それはSubstackに載せます。なぜなら、この制度的な側面はまったく別の会話だからです。そしてこの捉え方が役に立ったなら、ここも登録してください。
これは私が最も重要だと思う種類のAIの変化です。デモの話ではありません。モデルのリーダーボードの話でもありません。結局のところ、私はそうしたものにどんどん興味を失っています。私が興味を持っているのは、人間のエンジニアリング文化をどう変え始めるかです。機械が、私たちが本質的に人間的だと思っていた役割そのものや、その役割の一部を変え始める中で、私たちが繁栄できる方法をどう見つけるかです。
6カ月後にはAIが書いたコードがゴールドスタンダードになる世界を、私たちが想像し始めているところまで来たというのは、私にとって本当に驚くべきことです。でも、私たちはその方向へ向かっていると思います。だから今から準備を始めたほうがいいです。幸運を祈ります。ではまた。
コメント