🔁 AIコーディングの時代区分と2030年 — 4つの時代と、誰も名前をつけなかった17ヶ月

この記事は、AIによる開発の歴史を 製品の公式発表日だけで 年表にする。感覚で「だいたい2022年ごろから」と書かない。すべての区切りに、公式ブログの日付と原文がある。

そのうえで、この年表がどこへ向かうのかを、実測データだけで検証する。速くなったのか。安全なのか。2030年に何が自動化され、何が人間の手に残るのか。宣伝値は使わない。ランダム化比較試験と、ベンダー自身が公表した失敗率と、すでに官報に載っている適用日で書く。

依頼者は「2022年までGoogle検索」「2022〜2024はAIに聞いてコピペ」「2025は革命期」「2026からループ」「2030までにほぼ全部」という5段階を持っていた。骨格は正しい。ずれているのは、境界の年と、最後の量化子だけである。

採点の基準を先に示す。○＝一次情報と矛盾しない。△＝方向は正しいが、年か範囲を直す必要がある。✕＝そのまま実行すると不利益が出る。好き嫌いでは採点しない。すべての判定に、公式ブログか官報か査読論文の根拠をつける。

「2022年まではGoogleで調べていた」という記憶は、体験としては正しい。多くの開発者にとって、AIを意識し始めたのは ChatGPT からだった。

だが年表として書くと、ここに17ヶ月の空白ができる。GitHub Copilot の technical preview は 2021年6月29日、一般提供は 2022年6月21日。ChatGPT が公開された2022年11月30日の時点で、Copilot はすでに1年5ヶ月動いており、有料の商用製品として5ヶ月経っていた。

なぜ記憶から抜けるのか。補完は対話ではないからである。AIは問いに答えず、書きかけの行の続きを提案するだけだった。使っている側に「AIに聞いた」という感覚が残らない。だからこの時代には名前がついていない。この記事では便宜上「補完期」と呼ぶ。

2025年に何ができるようになったかは、公式ドキュメントに書いてある。Claude Code は「コードを検索して読み、ファイルを編集し、テストを書いて実行し、GitHubへコミットしてプッシュし、コマンドラインツールを使う」。デプロイまで通せる、というのは事実である。

問題は「すべての」という言葉のほうにある。ベンダー自身が、全自動にしていない。

つまり2025年に到達したのは「人間が承認しさえすれば、間の全工程をAIが通せる」という状態である。承認そのものが消えたわけではない。この差は、2030年の予測（主張7）にそのまま効いてくる。

7つのうち、これだけは「年を直せばいい」という話ではない。ループの中に、外部Webの自動取得を入れるという設計そのものに問題がある。

根拠は、Anthropic が自社モデルについて公表した数字である。プロンプトインジェクション（外部の文書に仕込まれた命令をAIが自分の指示と誤認する攻撃）の成功率は、環境によって桁が違う。

読み方には注意がいる。これは特定の評価環境での参考値であって、安全性の保証ではない。一次PDFは取得できておらず、評価条件も確認できていない。だから「コーディング環境なら安全」とは言えない。

この数値から言えるのは方向だけである。同じモデルでも、AIに何を読ませるかで攻撃面は大きく変わる。そして競合のサイトを取得するループは、AIに読ませる対象を利害が対立する相手の管理下にあるページに広げる設計になっている。

「ログもAIが見て、その場でセキュリティを排除する」。この方向は正しい。しかも、あなたが思っているより実現している。Microsoft Defender の Automatic Attack Disruption は、侵害の拡大を止めるための封じ込め（不審な端末やIDの隔離）を人間の承認なしに自動で実行する。2030年を待つ話ではなく、2026年の製品仕様である。

止まっているのは、その先の一線だけである。元に戻せない対処には、どのベンダーも承認を置いている。アカウントの完全無効化は自動対処の対象外とされ、2025年3月24日に発表された脆弱性修復エージェントのパッチ適用には公式に「with admin approval（管理者の承認付きで）」と書かれている。境界は「AIにできるかどうか」ではなく「取り消せるかどうか」で引かれている。

そして2030年の姿を決めるのは、モデルの性能ではない。EU Cyber Resilience Act の本体義務が全面適用される2027年12月11日である。技術の予測は外れるが、規則の適用日は動かない。詳しくは第11章と第12章で扱う。

2021年6月まで、コードを書くという行為の主語は人間だった。バグに当たったとき、仕様が分からないとき、頼れる相手はAIではなく、他の人間がすでに書いた文章だった。エラーメッセージをコピーして検索窓に貼り、Stack Overflowの回答、公式ドキュメント、個人ブログのどれかにたどり着く。この時代の開発者は、自分の問題を検索エンジンが理解できる言葉に翻訳する、いわば唯一の翻訳機だった。

この時代の規模を示す数字がある。Stack Overflowの月間質問数は、ChatGPT公開直前の2022年11月時点で108,563件あった。これは検索期の最盛期の名残であり、AIに聞くという選択肢がまだ存在しなかった時代の集合知の総量を表している。

この急減は2022年11月末以降に起きたことであり、後述する第2期(コピペ期)の実測データでもある。しかし依頼者の仮説にはもう一つの見落としがある。検索からAIへの移行は、ChatGPTの前に、静かにもう一段階あった。

この17ヶ月のAIには、決定的に欠けているものがあった。会話である。当時のCopilotは、開発者が書きかけたコードの続きを予測して薄い灰色の文字で提示するだけの存在だった。人間が関数名を書き始め、AIがその先の数行を推測する。人間が違うと思えばTabを押さずに書き続け、良ければTabで受け入れる。それだけの関係だった。

問いを立てるのは常に人間であり、AIは問いに答えることさえしていない。答えの断片を差し出していただけである。だから当時の開発者の多くは、自分が「AIを使っている」という自覚を持ちにくかった。エディタの補完機能が少し賢くなった程度の感覚だったという証言は、Copilotの初期レビュー記事にも繰り返し登場する。

2022年12月7日に一般提供が始まったGitHub Copilot for Businessの発表記事には、GitHub自身が実施した公式リサーチとして「開発者が書くコードの40%をCopilotが生成している」「55%速くタスクを完了できる」という数値が記載されている。これらは印象的な数字だが、独立した第三者機関による検証ではなく、GitHubが自社製品について自社で測定した数値である点を明記しておく必要がある。加えて「40%生成」と「55%速い」は母集団も測定方法も異なる別々の数値であり、ひとつの「Copilotの効果」としてまとめて読んではいけない。後述するMETRのランダム化比較試験(第6章)のような外部の無作為化比較試験とは、方法論も利害関係もまったく異なる。

依頼者の年表は「2022年〜2024年はAIに質問しながらコピペする時代」としている。この認識はおおむね正しい。ただし起点の精度に1ヶ月のずれがある。2022年は1月から11月29日まで、まだ前章で見た補完期のままだった。コピペ期が始まるのは、ChatGPTが公開された2022年11月30日である。

開発者が日常的にAIと会話するようになったのは、この日からである。開発者はブラウザの別タブでChatGPTを開き、エラーメッセージを貼り、返ってきた説明を読み、提示されたコードをコピーしてエディタに戻る。これが2年間続いたコピペ期の基本動作である。

この2年間を1つの構造で言い切るなら、「文脈を運ぶ仕事が、全部人間に残っていた」時代だった。ChatGPTもCopilot Chatも、開発者が今どのファイルを開いているか、リポジトリがどう構成されているか、直前のテストがどう失敗したかを、自分では知ることができなかった。

AIはコードを書けたが、それを実行してエラーを確認する手段を持たなかった。だから人間が、ターミナルに出たエラーメッセージをコピーし、チャット窓に貼り、返ってきた修正案をまたコピーしてエディタに戻すという往復を担った。開発者は翻訳機ではなく、AIと実行環境の間を往復する運搬係になった。この構造が変わるのは、次章で見るAIが端末そのものを持つ2025年である。

Cursorが持ち込んだ変化は、チャット窓をブラウザの別タブから、エディタの中に移したことだった。開いているファイルやリポジトリの構造をAIに参照させ、コピー&ペーストの往復を短縮した。この意味で、Cursorはコピペ期の中でも「文脈を運ぶ距離」を縮めた重要な一歩である。

ただし、Cursorがリポジトリを見られるようになったことと、AIがテストを実行して自分の失敗を知ることは別の話である。Cursorの世代でもまだ、コードを実際に動かして検証するのは人間の役目だった。そしてもう一つ、依頼者の年表との違いを正確にしておく必要がある。依頼者はCursorを「2022年〜2024年」の代表として語ったが、公式の初回リリース時期は2023年である。月については一次情報で確認できていないが、年は依頼者の認識より1つ遅い。

2024年3月12日、CognitionはDevinを「最初のAIソフトウェアエンジニア」として発表した。SWE-bench(実在するGitHubのissueをAIに解かせるベンチマーク)での成績は13.86%。それまでの最高記録だった1.96%を大きく上回るという触れ込みだった。この数値は、後にOpenAIが人手検証して精度を上げたSWE-bench Verifiedではなく元のSWE-benchで、unassisted(補助なし)設定において測定された、Cognition社自身の自己申告値である点に注意がいる。

この数字は2通りに読める。1.96%から13.86%への伸びは、7倍以上の進化であり、当時としては劇的な結果だった。しかし同時に、13.86%という数字は「残り86.14%はまだ解けなかった」ことも示している。エージェントが実用段階に達したと言うには、この時点ではまだ早かった。依頼者の「2025年革命期」という区分は、この数字を踏まえると理にかなっている。

2024年8月13日、OpenAIはSWE-bench Verifiedを発表した。従来のSWE-benchには、そもそも人間でも解けない不備のあるタスクが含まれており、モデルの実力を正しく測れていなかった。人手で検証した信頼できるサブセットを作ることで、ベンチマーク自体の精度を上げる動きが始まった。

そしてコピペ期を締めくくる出来事は、コーディングエージェントの発表ではなかった。2024年11月25日、AnthropicはModel Context Protocol(MCP)を公開した。「開発者がデータソースとAI駆動ツールの間に安全で双方向の接続を構築できるようにするオープンな標準」という位置づけである。AIが自分の端末を持つのは、まだ次の章の話である。しかしその前に、AIが外部の情報やツールに手を伸ばすための共通規格が、先に用意されていた。

コピペ期とエージェント期の違いは、AIの賢さではない。権限である。コピペ期のAIはチャット窓の中にいて、コードを読むにも書くにも人間がコピー&ペーストで文脈を運ぶ必要があった。エージェント期のAIは端末を持つ。ファイルを自分で開き、コマンドを自分で実行し、テストが赤くなったら自分でログを読む。人間は「文脈を運ぶ係」から降りた。この章では、その権限移譲が2025年の中でどの順番で起きたか、そして依頼者の主張である「すべてのデプロイまでエージェントで開発できるようになった」がどこまで正しいかを一次情報で確定する。

ただし、AIがコマンドを実行し変化を起こす試み自体は2025年に始まったわけではない。2023年頃には、目標を与えると自律的にツールを反復実行する「AutoGPT」がGitHub上で公開され、大きな注目を集めた（実際の自律実行の精度や実用性には当時から大きな限界があった）。続けて2023〜2024年頃にかけて、リポジトリを横断してコード編集を行う「Aider」や、ソフトウェアエンジニアリングのベンチマークで自律的に課題を解く「SWE-agent」が登場し、Cognition Labsは2024年3月12日にDevinを発表した。これらの正確な公開日・詳細な仕様は本記事では確認していないが、エージェント的にコマンドを実行する試み自体は2023〜2024年に既に存在していたことは動かない。したがって「2025年に技術的に可能になった」は不正確である。正しくは、2025年は発明の年ではなく、承認と権限の設計が伴って実務に耐えるようになった、普及と実用化の年である。

あなたの主張は「2025年にすべてのデプロイまでエージェントでできるようになった」だった。ここは分けて考える必要がある。Anthropic公式が明言しているのは、Claude Codeが「コードを検索・読み込み、ファイルを編集し、テストを書いて実行し、コードをコミットしてGitHubにpushできる」ことまでである。pushの先、つまり本番デプロイに進むかどうかは、CI/CDをどう組んであるか――ワークフローの設定・シークレットの扱い・環境保護ルール・承認ゲートの有無――の問題であって、エージェントの能力の問題ではない。「デプロイまで技術的にできる」と言うためには、pushの先に承認なしで本番へ進むCI/CDが別途組まれている必要があり、それは公式の記述の範囲外である。

GitHub Copilot coding agentの発表記事には、次の一文がある。「GitHub Actionsのワークフローはあなたの承認なしには実行されない」。ただしこれは、GitHubがCopilot coding agentの作るPRに対して設けた特定の安全設計であり、自分のCIやローカルで動かすエージェント全般に自動的に付く関所ではない。関所を外すのも、そもそも作らないのも、利用者の選択である。この非対称——エージェントにファイル操作とコマンド実行の権限を与えながら、本番へつながる実行経路の入り口には既定で人間の承認を残すベンダーが多いこと——が2025年の実像であり、依頼者の「ほぼすべて」を「技術的にはコミットとpushまで確認できており、そこから先は人間が組んだCI/CDの設計次第である」に修正する根拠になる。

体感と実測は、逆を向いていた。2025年、AIエージェントを使った開発者の多くは「速くなった」と感じていた。同じ条件を無作為化比較試験で客観的に計測すると、実際には遅くなっていた。この記事で最も重要な発見は、この体感と実測の乖離そのものである。

ここから先は数値と日付だけで書く。取得できていないものは取得できていないと書き、二次情報は二次情報と明記する。

METR（Model Evaluation & Threat Research）は2025年7月10日、Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity という論文を公開した（metr.org、arXiv:2507.09089）。対象は経験豊富なオープンソース開発者16名、課題数は246件。開発者は自分が普段開発している対象リポジトリで、AI使用を許可される条件と禁止される条件のどちらかに課題ごと無作為に割り当てられ、同種の実タスクを解いた。使用されたAIツールはCursor Pro＋Claude 3.5/3.7 Sonnetである。

結果は、AI使用を許可された条件のほうが完了時間が19%長くなったというものだった。着手前、開発者は「AIを使えば24%速くなる」と予想していた。そして実験後、実際には19%遅くなっていたにもかかわらず、開発者自身は「AIのおかげで20%速くなった」と誤って認識していた。予想・実測・事後認識の3つを並べると、実測だけがマイナス側にある。

METRは論文内で「We do not provide evidence that:」という見出しの表を使い、著者自身がこの結果をどこまで一般化してよいかに、明確な線を引いている。原文の一部を引く。

We do not claim that our developers or repositories represent a majority or plurality of software development work

さらにProgress is difficult to predict（進歩の予測は難しい）とも明記している。この19%という数値は、あくまで早期2025年の特定条件下の結果であり、著者自身がそれ以上の一般化に線を引いているという事実こそ、記事として扱う際に一緒に運ぶべき情報である。

Google CloudのDORA（DevOps Research and Assessment）チームは、個人ではなく組織単位でAI導入の効果を追跡している。2025年版（State of AI-assisted Software Development 2025）の調査対象は世界の技術者約5,000人。AI利用率は90%（前年比+14.1ポイント）、1日あたりのAI作業時間の中央値は2時間、80%超が生産性向上を実感していると回答した。ただしこの80%超は自己申告である（出典: dora.dev/dora-report-2025/）。

2025年版DORAの中心主張はこの一文に集約されている。

AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses.

訳すと「AIの主な役割は増幅装置であり、組織がもともと持つ強みと弱みの両方を増幅する」。これは「AIを入れれば良くなる」という単純な図式の否定である。テストが整い、レビュー文化が機能している組織では、AIは成果を底上げする。逆に基盤が弱い組織では、AIは問題を隠さない。むしろ速く、大量に露出させる。導入は改善そのものではなく、倍率として働く。

この2024年版の数値は、本記事の調査でも原著PDF本文への直接アクセスができておらず、二次情報（RedMonk等）経由の引用であることをここに明記する。DORA自身はこの負の相関を、AIによって1回あたりの変更のバッチサイズが大きくなりがちだという仮説段階の解釈として述べており、因果関係を証明したものではない。

METRのRCTで、開発者本人の体感（+20%速くなった）と客観計測（-19%、実際は遅くなった）が正反対だったことはすでに確認した。ここから導かれる原則はひとつである。自己申告ベースの生産性向上の数値は、それ単独では証拠にならない。DORAの「80%超が生産性向上を実感」も、ベンダーが自社製品について語る「55%速く書ける」型の数値も、測定方法を明示しない限り同じ扱いを受けるべきである。

「速くなったか」という問い自体が、この記事にとっては間違った問いである。METRの19%という遅延は、2025年前半の特定条件下での結果にすぎない。DORAの「増幅装置」という言葉が示すのは、AIが導入前の組織の実力をそのまま拡大するという構造であって、単純な速度の増減ではない。正しい問いは「何が人間の手から離れたか」である。2025年に離れたのは、キーボードを打つ作業ではなく、失敗を観測し、やり直す作業だった。この観測とやり直しが時間軸の上に乗ったとき、次の時代が始まる。

依頼者が提示したループ運用の構成は次の5段階だった。「cronで競合の仕様や開発を取得」「ソースコードへ反映」「セキュリティはCodeRabbitでチェック」「本番反映」。これをそのまま検証対象にする。

この章の仕事は、5段階を部品に分解し、2026年8月時点でそれぞれが実在するかどうかを1つずつ確認することである。

命題6だけは判定が変わる。依頼者が提示したループの2番目のステップ、「競合の仕様や開発を自動取得してソースコードへ反映する」は、設計として推奨できない。

理由は攻撃対象面（サーフェス）の違いにある。Anthropicが自社のClaude Opus 4.6 System Card（2026年2月5日公開。PDFは10MB超で直接全文取得はできておらず、以下は二次情報経由で該当箇所を確認したもの）で計測した数値によれば、プロンプトインジェクションの成功率は環境によって大きく変わる。

ループ期の本質は、AIが賢くなることではない。人間が起動しなくても始まることである。エージェント期の事故は、人間がボタンを押した後に起きた。ループ期の事故は、深夜3時に誰も見ていないところで始まる。

同じ技術でも、事故の見つかり方と被害の広がり方が変わる。次章では、この性質を踏まえたうえで安全な順に組む最小構成を示す。

前章で確認した部品を、安全な順番に並べ替える。目的は依頼者が提示した構成を全否定することではない。取得の対象と本番反映の権限を絞ったうえで、同じ発想を今日から動かせる形にすることである。

安全に広げる順番は3段階で固定する。読むだけのループから始め、PRを作るところまで進め、最後に限定した範囲だけ自動マージを許す。段階を飛ばして最初から本番反映まで作らない。

段階1の設計は、依頼者が最初に想定していた形から一つ変えている。当初案ではエージェント自身に「issueとして起票してください」と指示していたが、同じプロンプトで「コマンドの実行はしないでください」とも命じており、これは矛盾していた。issueを作る操作は実質的にGitHub APIを叩くコマンド実行である。ここでは役割を分ける。エージェントは調査結果をfindings.mdというファイルに書くだけにとどめ、issueを実際に作るのは同じワークフロー内の別ジョブがghコマンドで行う。こうすればエージェントは最後まで読み取り専用のまま動かせるし、issue作成に必要なissues: writeという書き込み権限も、エージェントにではなく人間が定義したCIのステップだけに与えられる。

ここまでの構成は、依頼者が2025年に体験した「エージェントが端末を持った」変化の延長線にある。違うのは、今度は人間が毎回ボタンを押さなくても動き続けることだけである。

だからこそ、動き続けるものの範囲を最初に決めておく必要がある。次章では、この境界を決めずに動かした場合に実際に何が壊れたかを、数字で見る。

ここまでの章で確認したのは、AIコーディングが「補完期→コピペ期→エージェント期→ループ期」と段階を踏んで進んできたという事実と、その裏でセキュリティが壊れている実測値だった。この章の役割は別にある。2030年を語るなら、何を根拠に線を伸ばせるのかを先に確定させることだ。

結論から言う。外挿に使える一次情報上の物差しは、現時点でMETR（AIモデルの能力評価を専門とする非営利研究機関）が公表している「時間地平線（time horizon）」以外に存在しない。そしてこの物差しを作った当人が、2030年の単純計算を強く戒めている。

METRの定義は次の通りである。

"the length (for humans) of tasks that the model can successfully complete with x% probability"（人間換算でのタスク所要時間のうち、モデルがx%の確率で成功できる長さ）

50%成功の時間地平線とは、複数のタスク（人間がこなすと何分〜何時間かかるかが分かっているもの）にモデルを挑戦させ、成功確率をロジスティック曲線でフィットさせたときに、その曲線が「成功確率50%」と交差する所要時間のことである。出典: metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/ （原著2025年3月版、arXiv:2503.14499）。

参考として、Claude 3.7 Sonnetの単体値は2025年3月版の原著論文で「約1時間」と記載されていた。それが約1年弱でClaude Opus 4.5の320分（約5.3時間）まで伸びている。ただしこの2値は測定手法のバージョンが異なる（原著版とTH1.1版）ため、単純な差分計算で「◯倍になった」と断定する数値はこの記事では作らない。

METRの原著（2025年3月）は「過去6年間、フロンティア汎用モデルの自律的タスク完遂（50%信頼度）時間地平線は約7ヶ月ごとに倍増している」と報告していた。著者自身は幅を持たせ、"we're fairly confident that the overall trend is roughly correct, at around 1-4 doublings per year"（年1〜4回の倍加という大まかな傾向は正しいと確信している）とも書いている。

2026年1月29日公開のTH1.1では、この倍加時間そのものが更新された。

2024年以降のデータに限れば、倍加時間は88.6日——約3ヶ月まで縮んでいる。2025年3月時点で語られていた「7ヶ月ごとに倍」という数字は、直近のペースをすでに下回っている。出典: metr.org/blog/2026-1-29-time-horizon-1-1/

倍加時間が分かっているなら、2030年の時間地平線を計算で出したくなる。だが、この物差しを作ったMETR自身が公式ノート「Clarifying limitations of time horizon」（2026年1月22日、metr.org/notes/2026-01-22-time-horizon-limitations/）で、その計算に明確な警鐘を鳴らしている。この記事もその指摘を踏まえ、2030年の時間数を計算しない。原文を引く。

"Time horizon is not the length of time AIs can work independently"（時間地平線は「AIが自律的に働き続けられる時間」ではない）

"I really have no idea whether Claude's 'true' time horizon is 3.5h or 6.5h."（Claudeの「真の時間地平線」が3.5時間なのか6.5時間なのか、著者自身にも本当に分からない）

"Time horizon differs between domains by orders of magnitude"（時間地平線は領域によって桁単位で異なる）。視覚的なコンピュータ操作タスクでは40〜100倍低くなるとも明記されており、コーディング以外の領域への単純な横滑りもできない。

そして最も実務に直結する一文。

"A 50% time horizon of X hours does not mean we can delegate tasks under X hours to AIs"（50%地平線がX時間だからといって、X時間未満のタスクをAIに任せられるわけではない）

50%成功とは、2回に1回は失敗するということでもある。実務でAIに仕事を任せるには、多くの場面でそれよりはるかに高い成功率が要る。だがMETRはこうも書いている。

"Time horizons at 99%+ reliability levels cannot be fit at all without much larger and higher-quality benchmarks."（99%以上の信頼水準での時間地平線は、はるかに大規模で高品質なベンチマークなしには測定すらできない）

つまり「実務で必要な成功率」での時間地平線は、現時点で測る手段そのものが存在しない。だから2030年の実務能力を数値で語ることはできない。METRは念を押すように、こうも書いている。

"Speculating about the effects of a months- or years-long time horizon is fraught."（月単位・年単位の時間地平線がもたらす影響を推測することには危うさが伴う）

METR自身の限界表明とは別に、外部からの技術的批判も一次情報として存在する。Nathan Witkin氏による公開批判「Against the METR Graph」（transformernews.ai/p/against-the-metr-graph-coding-capabilities-software-jobs-task-ai）は次のように指摘している。

元データ（HCAST＋RE-Bench）はタスク数が少なくノイズが大きいため、対数スケール上ではほぼどんな関数にもフィットしうる。長時間タスクほど実際の人間ベースラインを欠き、見積もり時間で代用されている。そして最も現実に近いとされるタスク群（most realistic half of tasks）では、どのモデルも成功率30%を超えていない。

さらにベンチマーク設計自体の偏りとして、HCASTチーム自身の言葉が引用されている。

"in the real world, people mostly attempt tasks they and their employer have very high confidence they will be successful at"（現実世界では、人は成功すると非常に高い確信が持てるタスクにしか着手しない）

ベンチマークのタスクは、この「成功しやすいものだけを選ぶ」バイアスの外側にある可能性がある。時間地平線の伸びが実務能力の伸びをそのまま表しているとは限らない、という指摘である。

ここまでを踏まえて、この記事が2030年について書ける範囲と書けない範囲を分ける。

書けないこと: 「2030年にAIは◯時間（あるいは◯日）の仕事を任せられる」という数値。これは倍加時間88.6日を単純に複利計算すれば作れてしまうが、METR自身が強く戒めている計算であり、この記事では行わない。

書けること: 50%成功という基準で測った時間地平線は倍加を続けており、直近（2024年以降）の倍加ペースは約88.6日である、という測定事実まで。そしてその数字でさえ「信頼区間が非常に広い」指標であることも同時に書く必要がある。

あなたの仮説は「2030年までにほぼすべてのシステムが24時間これで動く」というものだった。命題7の判定は△。方向は正しいが、「ほぼすべて」という量化子が誤っている。

2030年のシステム開発を1枚の絵で表すなら、全システムが同じ自由度でAIに任されるのではなく、壊れたときに何が起きるかで3つの層に分かれる。層が上がるほど、AIが単独でできる範囲は狭くなり、人間の承認が制度として残る。

あなたの仮説の後半、「ログもAIがみてその場でセキュリティを排除する」を実在確認する。最も近い公式発表は、Microsoftが2025年3月24日に公開したSecurity Copilotのセキュリティエージェント群である。

発表記事だけを見ると「提案止まり」に見える。だが運用側の公式ドキュメントまで降りると、あなたの予測に近い動きは、すでに一部が人間の承認なしで実行されている。ここは正確に線を引く必要がある。

Microsoft Defender の Automatic Attack Disruption は、侵害の拡大を止めるための最小限の封じ込め——不審な端末やIDをエンドポイント層で隔離する処理——を自動で実行する。ここには人間の承認が入らない。一方で公式は「contain user（封じ込め）」と「disable user（IDプロバイダ側でのアカウント完全無効化）」を明確に区別しており、恒久的で侵襲的な対処は自動対処の対象外としている。

そして重要なのは、自動で実行された対処にも公式に取り消し手段があることである。公式ドキュメントは「pending actions are approved (or rejected)... completed actions can be undone if needed」（保留中の対処は承認または却下でき、完了済みの対処も必要であれば取り消せる）と明記している。誤検知で止めてしまった場合に戻せる、という設計が先にある。

2030年に消えるのは「タイピング」ではない。消えるのは「待ち時間」である。人間はコードを書かなくなるのではなく、判断と判断のあいだにいる時間がなくなる。次の章では、その境界線を実際に引いているのが技術ではなく制度であることを示す。

2030年のシステム開発の形を最終的に決めるのは、モデルの性能でも、あなたが仮説に置いたcronのループでもない。すでに条文として確定している適用日である。技術の予測は外れるが、規則の適用日は動かない。

この年表を作って見えてくるのは、EUと米国が同じ2026年に逆方向へ動いたという事実である。EUはCRAで義務を強めている。2027-12-11までに、脆弱性対応プロセス・SBOM(Software Bill of Materials＝ソフトウェアの部品表。使っている全依存関係を一覧化した文書)の作成・サポート期間の明示を、対象製品に義務づける。

米国は逆に動いた。2026-01-23のOMB M-26-05は、旧メモについて、実証されていない負担の大きいソフトウェア会計プロセスを課していた、と評したと伝えられており、SBOM提出とセキュア開発の自己証明を各省庁の任意判断へ格下げした。この一次テキスト自体は今回未取得で、二次情報(法律事務所解説)経由の確認であることを明記しておく。

この記事の開発者にとっての意味は一つ。「世界共通のルールが来て、それに合わせれば済む」という前提が誤りだということである。出す市場ごとに要求が違う。EU市場に製品を出すなら、2027年12月11日が締切になる。ただしCRAが対象とするのは、EU市場に出す「デジタル要素を持つ製品(products with digital elements)」であり、2030年の全システム開発を一律に決める法ではない。純粋なSaaS・社内システム・静的サイトは対象外になりうる(クラウドサービスの多くは別途NIS2側の対象になる)。

この記事は NotebookLM に食わせて使うことを前提に作ってある。だから本文を丸ごとプレーンテキストで取り出せるようにした。ページ右下のコピーボタンを押すと、見出しと表を含む本文全体がクリップボードに入る。ビルド時に本文から機械的に抽出したものなので、記事を更新すればコピー内容も一緒に更新される。手で写したものではない。

NotebookLM 側の手順は、ソースを追加 → テキストをコピー → 貼り付け、の3手である。

この記事は公開前に、別のモデル（OpenAI の Codex）に全文を読ませて事実確認をさせている。その結果、公開前の版に複数の誤りが見つかった。直したうえで、何を間違えたかもここに残す。消して出すほうが見栄えはいいが、それでは第6章で書いた「体感と実測が逆を向く」という話を、自分でやることになる。