Nexus AIコミュニティにお越しいただき、ありがとうございます。
WordPressを継続的に運営していると、最近になって「セキュリティアップデートが増えていないか」と感じた方もいるかもしれません。
私自身もWordPressを運営する中で、同じ違和感を持ちました。
2026年7月17日にWordPress 7.0.2が公開されたと思ったら、8月6日には7.0.3、さらに8月12日には7.0.4が公開されています。
しかも、これらはすべてセキュリティ上の問題に対応するリリースです。
WordPress 7.0.2 では深刻度CriticalとHighの問題が修正され、影響の大きさからWordPress.orgによる強制自動更新まで有効化されました。
そこで、一つの疑問が生まれました。
なぜ、これほど短い期間にセキュリティアップデートが続いているのでしょうか。
調べていくと、単に「最近のWordPressには脆弱性が多い」と考えるだけでは、この現象を十分に説明できないことが見えてきました。
特に興味深いのが、脆弱性を発見した研究者や組織です。
WordPress 7.0.3では、pwn.aiやAnthropicを含む研究者・組織から報告された複数の脆弱性が修正されています。7.0.4でも、pwn.aiによって報告されたリモートコード実行につながる脆弱性が修正されました。
WordPressはすでにAI基盤としての性格も強めつつあり、この動きも無関係ではありません。
AIは、ソフトウェアを作る能力を急速に拡張しています。
しかし同じことは、ソフトウェアに潜む欠陥を探す能力にも起き始めています。
この記事では、WordPress 7.0系で相次いだセキュリティアップデートを一つのケーススタディとして、「脆弱性が増えたこと」と「脆弱性が見つかるようになったこと」の違いを整理します。
そのうえで、AIがソフトウェア開発とセキュリティの関係をどのように変えていくのかを考えていきます。
確認できるのは、AIを活用する研究者・組織が実際に脆弱性発見へ関与していることです。
WordPress全体の脆弱性発見速度がAIによって統計的に上昇したかどうかは、今回の事例だけでは証明できません。
結論|AIは「欠陥を見つける能力」も拡張している
先にこの記事の結論を整理しておきます。
WordPress 7.0系でセキュリティアップデートが相次いだからといって、「WordPressが急に危険になった」とは限りません。
ソフトウェアの脆弱性には、大きく分けて二つの状態があります。
- すでに存在しているが、まだ誰にも発見されていない
- 発見され、脆弱性として認識されている
脆弱性は、発見された瞬間に初めて発生するわけではありません。
何年も前からコードの中に存在していた問題が、新しい解析手法や研究によって後から発見されることもあります。
WordPress 7.0.4で修正された脆弱性も、最新の7.0系だけに修正が適用されたわけではありません。
WordPress.orgは、必要な修正をWordPress 4.7系までバックポートすると発表しています。
つまり、この問題を「WordPress 7.0で新しく生まれた脆弱性」と単純に捉えることはできません。
ここから一つの重要な視点が生まれます。
セキュリティアップデートが増えることと、ソフトウェアそのものの安全性が低下することは同じではありません。
以前から存在していた未知の脆弱性が発見される速度が上がれば、修正リリースの回数も増えます。
そしてAIは現在、コード生成だけではなく、大量のコードを読み、パターンを分析し、異常や弱点を探索する領域にも使われ始めています。
したがってAI時代のソフトウェア開発では、「コードを書く速度」だけでなく「コードを疑う速度」も上がるという変化を考える必要があります。
今回のWordPressの連続セキュリティ更新は、その変化を考えるうえで非常に興味深い事例です。
WordPress 7.0系ではセキュリティ更新が相次いでいる
まずは、実際に何が起きているのかを整理してみましょう。
WordPress 7.0は2026年5月20日に公開されました。
その後、7月9日に7.0.1が公開されていますが、こちらはCore・Block Editorなど31件のバグ修正 を含むメンテナンスリリースでした。
大きな変化が起きたのは、その後です。
| バージョン | 公開日 | 主な内容 |
|---|---|---|
| WordPress 7.0.1 | 2026年7月9日 | Core・Block Editorなど31件のバグ修正 |
| WordPress 7.0.2 | 2026年7月17日 | Critical 1件、High 1件のセキュリティ問題を修正 |
| WordPress 7.0.3 | 2026年8月6日 | 12件のセキュリティ問題を修正 |
| WordPress 7.0.4 | 2026年8月12日 | 悪意あるファイルアップロードを利用したRCEにつながる問題を修正 |
7.0.2から7.0.4までは、わずか26日です。
しかも3回ともセキュリティリリースです。
WordPress.orgはいずれも、影響を受けるサイトに対して速やかなアップデートを推奨しています。
私が「最近、WordPressのセキュリティアップデートがずっと続いている気がする」と感じたのも、単なる印象ではありませんでした。
実際にリリース履歴を確認すると、短期間で重要なセキュリティ修正が連続しています。
私の場合は、マイナーアップデートが自動で適用されるように設定しているため、これらのセキュリティリリースは即座に適用されました。
そのうえで、Wordfence Centralで運営している全サイトの状況を確認し、アップデートが正しく反映されていることも確かめています。
自動更新の運用と考え方については、以下の記事でも同じ考え方に触れています。
WordPress 7.0.2ではSQLインジェクションとRCEにつながる問題を修正
2026年7月17日に公開されたWordPress 7.0.2では、二つのセキュリティ問題が修正 されました。
一つはSQLインジェクションに関連する問題です。
もう一つはREST APIのbatch routeに関する混同とSQLインジェクションを組み合わせることで、最終的にRemote Code Execution(RCE)につながる問題でした。
RCEとは、攻撃者が対象となるシステム上で任意のコードを実行できる可能性がある脆弱性です。
Webサイトの改ざんや不正なプログラムの実行など、重大な被害につながる可能性があります。
この問題の深刻度は高く、WordPress.orgは影響を受けるバージョンに対して自動更新システムによる強制アップデートを有効にしました。
重要なのは、WordPressに限らず、Webサイトを運営する以上「一度安全に設定したから終わり」にはならないということです。
新しい脆弱性が発見されれば、それに合わせてシステム側も変化させる必要があります。
WordPress 7.0.3では12件のセキュリティ問題をまとめて修正
そこから約3週間後の2026年8月6日、WordPress 7.0.3が公開されました。
このリリースでは、12件のセキュリティ問題が修正 されています。
内容は多岐にわたります。
- ログイン画面における認証前の反射型XSS
- 投稿などを利用した複数のStored XSS
- Multisiteにおける権限昇格
- パスワード保護された投稿に関連する情報漏洩
- 投稿slugの列挙
- CSS Injection
- メールアドレス確認フローのバイパス
- SSRF(Server-Side Request Forgery)
特にログイン画面のXSSは、条件によってPHPコード実行へつながる可能性がある問題として報告されています。
そして、この記事のテーマを考えるうえで興味深いのが報告者です。
ログイン画面のXSSを報告したのはpwn.aiのチームで、CSS InjectionについてはAnthropicが報告者として記載されています。
もちろん、7.0.3のすべての脆弱性がAIによって発見されたわけではありません。
WordPress Security TeamやAikido Security、独立したセキュリティ研究者など、多数の研究者・組織による報告が含まれています。
それでも、AIに深く関わる組織が実際の脆弱性発見プロセスに登場しているという事実は、AIとソフトウェアセキュリティの関係を考えるうえで見逃せません。
WordPress 7.0.4では古いコードに潜んでいた脆弱性が修正された
そして2026年8月12日、7.0.3の公開からわずか6日後にWordPress 7.0.4が公開されました。
今回修正されたのは、特定の条件を満たすサイトで、認証済みのAuthor以上の権限を持つユーザーが悪意あるファイルをアップロードすることでRemote Code Executionにつながる可能性がある脆弱性です。
影響条件として、ImagickとGhostscriptを利用しているサイトが挙げられています。
この問題はpwn.aiによって報告され、CVE-2026-65640として公開されています。
WordPress.orgはセキュリティリリースであることから、サイトを直ちにアップデートするよう推奨 しています。
最新バージョンだけの問題ではない
ここで私が特に興味深いと感じたのが、修正対象の範囲です。
WordPress.orgは、今回の修正をWordPress 7.0だけではなく、WordPress 4.7系列まで必要に応じてバックポートすると説明しています。
WordPress 7.0で新しく追加されたコードだけが原因なら、通常は7.0系だけを修正すれば済みます。
しかし今回の修正は、かなり以前のWordPress系列まで遡って適用されます。
つまり、少なくとも問題となった構造は「WordPress 7.0になったから突然生まれたもの」と考えるべきではありません。
以前から存在していたコードや処理の組み合わせに、後からセキュリティ上の問題が見つかった可能性を考える必要があります。
ここで、セキュリティに対する見方が少し変わってきます。
私たちは「脆弱性が発表された」というニュースを見ると、「新しい問題が発生した」と感じがちです。
しかし実際には、「以前から存在していた問題を、今になって発見できた」という場合もあります。
この違いは、AI時代のセキュリティを考えるうえで非常に重要です。
「脆弱性が増えた」と「脆弱性が見つかるようになった」は違う
ここまでWordPress 7.0.2から7.0.4までの流れを見てきました。
確かに、セキュリティアップデートは短期間で続いています。
しかし、この事実だけから、「WordPressの脆弱性が最近になって急増した」とは言えません。
なぜなら、「脆弱性が存在すること」と「脆弱性が発見されること」は別だからです。
ソフトウェアに脆弱性が存在してから修正されるまでには、いくつかの状態があります。
- コードの中に脆弱性が存在する
- まだ誰にも認識されていない
- 研究者や開発者が問題を発見する
- 開発元へ報告される
- 修正方法が設計・実装される
- セキュリティアップデートとして公開される
- 運営者がアップデートを適用する
この構造で考えると、「セキュリティアップデートが増えた」という現象には複数の原因が考えられます。
たとえば本当に新しい脆弱性が増えている可能性もあります。
一方で、
- コードを解析する技術が進歩した
- セキュリティ研究者が増えた
- 脆弱性報告の仕組みが整備された
- 自動解析ツールの能力が向上した
- 従来見つけにくかった問題まで発見できるようになった
といった変化によって、発見される脆弱性が増えることもあり得ます。
これは、少し逆説的です。
セキュリティアップデートが増えていると、「以前より危険になっている」ように見えます。
しかし、未知だった脆弱性が発見され、修正されているのであれば、別の見方もできます。
それまで未知だった問題が発見され、「観測できないリスク」から「修正できるリスク」へ変わった瞬間でもあります。
もちろん、だからセキュリティアップデートが多い方が良い、と単純化することもできません。
重要なのは、何件アップデートされたかという数字だけでは、ソフトウェアの安全性を評価できないということです。
Webサイトは一度公開すれば完成する静的な成果物ではありません。
外部環境を観測し、問題が見つかれば改善し、それを繰り返しながら運営していくシステムです。
脆弱性も同じです。
見つかっていない脆弱性は、「存在しない」のではありません。
まだ観測できていないだけかもしれません。
そして現在、この「観測する能力」そのものを大きく変えようとしている技術があります。
それがAIです。
AIはすでに、プログラマーの代わりにコードを書くためだけの技術ではなくなりつつあります。
大量のコードを読み、関連性を分析し、人間が見落としていた異常な組み合わせや振る舞いを探す側にも使われ始めています。
WordPress 7.0.3や7.0.4の脆弱性報告者にAIと深く関わる組織が現れていることは、その変化を考える一つの手がかりです。
では、AIによって「脆弱性を探す能力」が高まると、ソフトウェア開発そのものはどのように変わっていくのでしょうか。
AIは脆弱性を探す能力まで拡張し始めている
このように、WordPress 7.0系では短期間に複数のセキュリティアップデートが公開されました。
しかし重要なのは、その件数だけではありません。
誰が、どのように脆弱性を発見しているのか。
この点を見ると、AI時代らしい変化が少しずつ現れ始めています。
WordPress 7.0.3では、ログイン画面に存在した認証前の反射型XSSをpwn.aiのチームが報告しています。
WordPress.orgによれば、この問題は条件によってPHPコード実行につながる可能性がありました。
さらにWordPress 7.0.4では、ImagickとGhostscriptを利用するサイトにおいて、Author以上の権限を持つ認証済みユーザーが悪意あるファイルをアップロードすることでRemote Code Executionにつながる脆弱性が修正されました。
この問題もpwn.aiによって責任ある形で報告されています。
ここで注意したいのは、「AIが自動的にWordPressの脆弱性をすべて発見した」と単純化しないことです。
セキュリティ研究には、コード解析、Fuzzing、実際の挙動確認、攻撃条件の組み合わせ、再現性の検証など、さまざまな手法があります。
AIは、それらをすべて置き換える魔法の技術ではありません。
しかし、大量のコードを読み、異なる処理同士の関係を追い、仮説を生成し、検証対象を絞り込む能力は、人間だけで調査する場合と比べて大きく拡張できます。
この構造は、AIコーディングで起きていることとよく似ています。
AIを使えば、人間が一行ずつコードを書く必要はなくなります。
同じようにAIをセキュリティ研究へ活用すれば、人間がすべてのコードを一行ずつ目視して弱点を探す必要もなくなっていきます。
つまりAIは、「コードを書く能力」だけではなく、「コードを読む能力」も拡張していると捉えられます。
そしてコードを読む能力が高まれば、その延長線上にある
- 「異常を探す」
- 「条件を組み合わせる」
- 「想定外の挙動を発見する」
といった能力も高まっていきます。
これは、AI時代のソフトウェア開発を考えるうえで非常に重要な変化です。
人間が見落としていた組み合わせをAIが探索できる
ソフトウェアの脆弱性は、必ずしも一つの明らかなミスから生まれるわけではありません。
個々の処理だけを見れば正常でも、複数の条件が組み合わさることで問題になる場合があります。
たとえば、
- 特定の権限を持つユーザー
- 特定のファイル形式
- 特定のライブラリ
- 特定のAPI
- 特定の入力方法
といった条件が重なったときだけ発生する問題です。
こうした脆弱性は、人間がコードレビューをしていても発見が難しくなります。
なぜなら、人間には認知できる範囲に限界があるからです。
コードベースが大きくなるほど、すべての関数、ライブラリ、権限、入力経路、例外条件を同時に頭の中へ保持することは難しくなります。
一方、AIは大量の情報を横断しながら、
- 「この入力がここへ到達したらどうなるのか」
- 「この権限でこの処理を呼び出せないか」
といった探索を支援できます。
もちろん、AIが導いた仮説が常に正しいわけではありません。
しかし、人間だけでは調べきれなかった範囲まで探索できるようになること自体に大きな意味があります。
AI時代には、脆弱性そのものが突然増えるのではなく、これまで人間が見つけられなかった脆弱性へ到達できる範囲が広がる可能性があります。
WordPress 7.0.3や7.0.4の事例は、それを考える一つの手がかりになります。
AI時代のセキュリティは「防御側の受け身」では対応できない
ここまでの話は、AIによって脆弱性が発見されやすくなるという、防御側にとって歓迎すべき変化として読めます。
実際、防御側にとってAIのメリットは大きいものです。
AIを活用すれば、
- コードレビューを高速化する
- 怪しい処理を探索する
- 脆弱性につながる条件を洗い出す
- テストケースを生成する
- 修正案を検討する
- 過去の脆弱性パターンと照合する
といった作業を支援できます。
これまで人間の専門家が長い時間をかけて行っていた調査の一部を、AIが補助できるようになります。
ただし、ここで一つ意識しておきたい前提があります。
分析能力そのものを高める技術は、使う対象によって結果が変わるということです。
コードを読み、パターンを分析し、条件の組み合わせを探索する能力は、それ自体に「守るため」という方向性が組み込まれているわけではありません。
したがって、AI時代のセキュリティを考えるうえでは、「AIを使っているから安全」と考えるのではなく、「分析能力が全体として底上げされている」という前提で防御態勢を設計するという発想が重要になります。
分析・検証という汎用的な能力を拡張する「能力増幅器」です。
AI時代には、防御側が受け身のままでは相対的に不利になっていくことを前提として、開発プロセスそのものを設計する必要があります。
pwn.aiやAnthropicのような組織がWordPressの脆弱性報告に登場していること自体が、この「分析能力の底上げ」を象徴する事例だといえます。
インジェクションという攻撃手法一つを取っても、AIとWebセキュリティ、そして人間の認知には共通する構造があります。
この点については、以前別の記事で詳しく整理しています。
だからこそ重要なのは、AIそのものを恐れることではありません。
防御側もまた、その分析能力を開発プロセスへ積極的に組み込んでいくことです。
Nexus AIでも「継続的な観測」を前提にしている
今回のWordPressの連続セキュリティアップデートを見ていて、私は以前から考えていた「運営とは観測と改善の継続である」という考え方を改めて実感しました。
ソフトウェアは、完成した瞬間に安全性が確定するものではありません。
公開時点では問題が見つからなくても、後から新しい解析技術によって弱点が見つかることもあります。
使用しているライブラリに脆弱性が見つかることもあります。
新しい機能を追加した結果、以前は存在しなかった組み合わせが生まれることもあります。
つまり「安全である」という状態は固定されたものではありません。
環境の変化に応じて更新され続ける状態です。
私自身、AIと共同で開発を進めるときも、一度実装した機能を「完成したから終わり」とは考えていません。
- 実装する
- テストする
- レビューする
- 問題が見つかれば修正する
- 新しい知識や技術が得られれば、以前の設計を再評価する
こうした改善の連続によって、システムは少しずつ強くなっていきます。
ChatGPT・Codex・GitHubなど複数のAIやツールを役割分担させながら開発を進めるAI共同開発の考え方は、こうした継続的な改善サイクルとも相性がよい方法です。
これは、WordPress本体の開発でも同じです。
7.0.2では重大な脆弱性が修正され、強制自動更新まで有効化されました。
7.0.3ではさらに複数のセキュリティ問題が修正され、7.0.4では新たに報告されたRCEにつながる問題が修正されています。
短期間で立て続けに修正が入ったことは、「何度直しても問題がなくならない」とも見えます。
しかし、見方を変えれば観測された問題を、その都度修正しているということでもあります。
WordPressのように長期間運用される巨大なソフトウェアでは、「永久に問題のない完成状態」を作ることよりも、問題が見つかったときに修正し続けられる仕組みの方が重要です。
AI時代になると、この観測と改善の速度そのものがさらに上がる可能性があります。
- 開発が速くなる
- テストも速くなる
- 脆弱性探索も速くなる
- 修正も速くなる
その結果、ソフトウェアは「完成させて維持するもの」から、継続的に観測しながら更新し続けるものとしての性格をさらに強めていくでしょう。
WordPressが危険になったと単純に考えるべきではない
ここまで読むと、「それではWordPressには大量の脆弱性が潜んでいて危険なのではないか」と感じるかもしれません。
しかし、その判断にも注意が必要です。
今回確認できた事実から言えるのは、2026年7月から8月にかけて複数の重要なセキュリティ問題が発見され、WordPress側が短期間で修正リリースを行ったということです。
そこから、
- 「WordPressは他のCMSより危険である」
- 「AIによってWordPressの脆弱性が急増した」
- 「WordPress 7.0になったことでセキュリティ品質が低下した」
と結論づけることはできません。
特に意識したいのは、次の違いです。
| 観測できる事実 | それだけでは判断できないこと |
|---|---|
| セキュリティリリースが短期間に続いた | WordPress全体の品質が低下したか |
| 複数の脆弱性が発見された | 脆弱性そのものが以前より増えたか |
| AI関連の研究者・組織が報告に関与している | WordPressの更新増加がAIによって引き起こされたか |
| 古い系列まで修正がバックポートされた | その脆弱性がいつ発生したか |
ここを分けて考えることが重要です。
セキュリティに関する話題は、どうしても「危険」「重大」「攻撃」といった強い言葉が並びます。
しかし、その言葉だけを追うと、現象を必要以上に恐れてしまいます。
むしろ運営者として重要なのは、脆弱性が存在する可能性を前提として、発見されたときに適切に更新できる状態を維持することです。
「問題が存在しないシステム」を求めるのではなく、「問題を迅速に修正できるシステム」を作る。
この考え方の方が、現実的です。
知識の現在地|WordPressセキュリティは「観測と改善」の一例である
今回の記事は、WordPress 7.0.2から7.0.4までの連続セキュリティアップデートを扱いました。
しかし、Nexus AIの知識体系の中では、この出来事そのものが最上位のテーマではありません。
より上位にあるのは、「運営とは観測と改善の継続である」という考え方です。
この考え方を具体的な脆弱性事例として掘り下げたのが、wp2shellを扱った記事です。
実際に私が自動更新とWordfence Centralでの確認をどのように運用しているかについても、詳しく紹介しています。
そして今回の記事では、さらにAIという新しい要素を加えました。
WordPressセキュリティ
↓
脆弱性の発見
↓
観測能力の向上
↓
AIによる探索能力の拡張
↓
AI時代の開発プロセス
このようなつながりです。
つまり今回のWordPress 7.0系アップデートは、一つのニュースとして終わる話ではありません。
AIによってソフトウェアを「作る能力」と「検査する能力」の両方が変化していることを考えるための具体例です。
そして、ここから得られる考え方はWordPress以外にも応用できます。
- AIを使ってコードを書くのであれば、AIを使ってコードを疑う。
- 高速に作れるのであれば、高速に検証する仕組みも作る。
- 新しい問題が発見されることを失敗と捉えるのではなく、改善できる情報が増えたと捉える。
この発想を支えているのが、「実験回数」そのものを競争力として捉える視点です。
仮説を立て、検証し、次の仮説につなげるサイクルを速く回せるほど、開発でもセキュリティでも有利になります。
この発想が、AI時代の開発ではますます重要になっていくでしょう。
【まとめ】AI時代は「作る速度」と「疑う速度」の両方が上がる
WordPress 7.0系では、2026年7月から8月にかけて7.0.2、7.0.3、7.0.4とセキュリティリリースが続きました。
最初に私が感じたのは、「最近、WordPressのセキュリティアップデートが多いのではないか」という単純な違和感でした。
実際に調べてみると、その感覚は間違っていませんでした。
しかし、さらに調べることで、それだけでは見えなかった構造も見えてきました。
セキュリティアップデートが増えたからといって、脆弱性そのものが最近になって急増したとは限りません。
脆弱性には、存在することと、発見されることの間に時間差があります。
そしてAIは現在、その「発見する能力」を拡張する技術としても使われ始めています。
- AIがコードを書く
- AIがコードを読む
- AIが問題を探す
- AIが修正案を考える
この循環が高速化すれば、ソフトウェア開発の姿も変わります。
速く作れるようになったからこそ、「速く疑い、速く検証し、速く改善できる仕組み」まで設計する必要があります。
セキュリティの理想を「一度安全にしたら終わり」と考えると、現実のソフトウェア運営とは噛み合いません。
未知の脆弱性は、いつ発見されるか分かりません。
新しい解析技術によって、何年も眠っていた問題が突然見つかることもあります。
だからこそ必要なのは、完璧な状態を一度作ることではありません。
「発見 → 修正 → 更新 → 再観測」という循環を止めないことです。
AIは、この循環そのものを高速化していく可能性があります。
そしてAIがソフトウェアを作る能力と、ソフトウェアの欠陥を発見する能力の両方を高めていくのであれば、これからの開発者に求められるのは単なるコーディング能力ではありません。
作る知性と疑う知性を、同じ開発システムの中に組み込む設計力です。
WordPressの連続セキュリティ更新は、その変化がすでに始まっていることを考える、一つの興味深い事例なのかもしれません。
参考情報(公式サイト)
AIと脆弱性の発見速度に関するFAQ
WordPress 7.0系でセキュリティアップデートが短期間に続いたのはなぜですか?
複数の重要な脆弱性が相次いで発見され、WordPress 7.0.2から7.0.4まで短期間に修正リリースが行われたためです。
WordPressのセキュリティアップデートが増えたのは、脆弱性そのものが増えたからですか?
そうとは限らず、以前から存在していた未知の脆弱性が新しい解析手法などによって発見される速度が上がった可能性もあります。
WordPress 7.0系のセキュリティ更新が増えた原因はAIですか?
AIが原因とは断定できませんが、pwn.aiやAnthropicなどAIに関わる研究者・組織が実際の脆弱性報告に関与しています。
AIはWordPressなどのソフトウェアの脆弱性発見にどのように活用できますか?
AIは大量のコードを読み、処理の関連性を分析し、異常な組み合わせや脆弱性につながる可能性のある条件の探索を支援できます。
セキュリティアップデートが多いWordPressは危険だと考えるべきですか?
更新回数だけで危険とは判断できず、未知の脆弱性が発見されて継続的に修正されているという側面も考える必要があります。
AI時代のソフトウェア開発では、セキュリティ対策をどのように考えるべきですか?
AIで開発を高速化するだけでなく、コードレビュー・テスト・脆弱性探索・修正といった検証と改善も継続的に高速化することが重要です。
AI時代の開発で「作る速度」と「疑う速度」の両方が重要なのはなぜですか?
AIによってコード生成が速くなるほど、問題を素早く発見・検証・修正し、「発見→修正→更新→再観測」の循環を回す仕組みも必要になるからです。