Anthropic CEO、AIが3-6ヶ月でコードの90%を書くだろうと言った — 証拠が示すもの

「AIがコードの90%を書く」という主張が重要な理由

1つの文が市場、チーム、ニュースルームにどのように波及したか

2025年3月、Anthropic CEO Dario Amodeiは、AIが3〜6ヶ月以内にコードの90%を書く可能性があるという、注目を集める予測を発表しました。その発言はテックフィードやビジネスページに急速に広がり、株価変動、エンジニアリング組織内のSlack議論、開発者ツールやエンタープライズリスクを扱う記者への緊急の質問を引き起こしました。多くの読者にとって、この主張は馴染みのあるパターンを凝縮したものでした。主要なAIの進歩は、生産性向上への楽観と、安全性、雇用、ガバナンスへの不安の両方を引き起こすのです。

Anthropicの予測はニュースメディアで広く報じられ、いくつかのフォローアップ記事ではタイムラインや主張の範囲に疑問が呈されました。本稿は、それらの議論を既存の研究やセキュリティ監査とともにまとめ、根拠のある見解を提供します。

「AIがコードの90%を書く」ために実際に必要な機能と出力

単一ファイルの補完から全プロジェクトの提供まで

AIが「コードの90%を書く」と言うのは、開発者がすでに活用しているオートコンプリートをはるかに超える一連の能力を意味する略称です。そのレベルに到達するには、システムが以下の次元にわたって一貫して本番レベルの出力を生成する必要があります：

• 複数ファイルのプロジェクト合成：複数のソースファイルを設計・生成・更新し、アプリケーション全体が意図どおりにコンパイル・実行できる能力。

• 正確なAPI配線：ライブラリを正しく呼び出し、認証フローを尊重し、モジュールを接続してランタイム動作が仕様に一致するようにする。

• 信頼できるテストとCI統合：重要なパスを検証する単体テストおよび結合テストを生成し、ビルドシステムや継続的インテグレーションパイプラインと統合する。

• 動作を保持した安全なリファクタリング：既存のコードベースを変更してもリグレッションを導入せず、既存のテストスイートに合格する変更セットを生成する。

• セキュアバイデフォルトのパターン：一般的な脆弱性（インジェクション、安全でないデシリアライゼーション、安全でない依存関係の使用）を避け、ライセンスおよび出所制約を遵守する。

これらの能力の多くは現在のツールではまだ初期段階です。開発者はIDEプラグインやクラウドツール内でインラインオートコンプリート、単一関数の生成、単体テストの提案を日常的に使用しており、小規模で局所的なタスクの摩擦を低減しています。例えば、関数レベルの足場を提供したりテストケースを提案したりするツールは、エディタ拡張やクラウドIDEで一般的になっています。しかし、これらの製品スタイルの機能と、複数のモジュールからなるシステム全体を確実に提供する能力の間には依然として大きなギャップがあります。

主張を評価する際は、出力の実用的特性に注目してください：生成速度（モジュールを生成するのにかかる時間）、生成されるモジュールのサイズと複雑さ（単一関数 vs サービス層）、言語・フレームワークのサポート、依存関係の管理（AIは互換性のあるライブラリバージョンを選択するか？）、および付随するテストの品質とカバレッジ。1つのファイルを生成する派手なデモは印象的ですが、20のサービスにわたる変更を調整し、インフラ・アズ・コードを更新し、本番テストに合格できるシステムとは同等ではありません。

洞察：記者はベンダーに対し、デモがコンパイル、テストスイート、デプロイ手順を含むエンドツーエンドの実行を含むか、単一ファイルのプレビューのみに限定されているかを尋ねるべきです。

現在の能力と失敗モードに関する研究ベースラインについては、コードモデルの学術的評価を参照してください。これらは小規模スコープでの強みと、より大きな文脈やステートフルシステムにわたる推論での弱みを強調しています research on code-generation models。Amodeiの発言とその後の議論の報道も、世間の反応と期待を理解する助けになります WindowCentral summarized the prediction and its context。

重要なポイント：印象的な単一ファイルの結果は本番レベルのプロジェクト生成とは異なります。コンパイル、テスト合格率、依存関係解決の証拠を求めましょう。

AI生成コードのベンチマーク、セキュリティ率、モデル性能

ベンチマークが測定するものと測定しないもの

ベンチマークは我々が持つ最も具体的なシグナルですが、正しく解釈することが重要です。学術および業界の評価では、docstringから短い関数を合成する、タスク、部分的に書かれたコードを完成させる、孤立したメソッドの単体テストを生成するといったタスクを測定するのが一般的です。これらのテストは局所的な推論、パターンマッチング、APIの理解におけるモデルの能力を明らかにします。しかし、エンドツーエンドのソフトウェア配信（大規模プロジェクトのコンパイル、結合テストの実行、本番システムでのランタイム安全性の確保）を測定することはほとんどありません。

公開されているモデルベンチマークはトークンレベルの補完や合成単体テストの合格率で着実な改善を示していますが、これらの向上は人間に完全に信頼されるシステムレベルの置き換えに直接つながるものではありません。研究者にとって、コード生成文献にまとめられたベンチマークのようなものはモデルを比較する標準化された方法を提供しますが、文脈長、長距離依存関係、ファイル間の意味的正しさに関する既知の盲点もあります see code-generation research summaries。

セキュリティは別だが決定的な制約です。複数の分析とテスト演習により、生成されたコードのかなりの割合に欠陥（安全でないデフォルトから攻撃面を開く論理エラーまで）が含まれていることが判明しています。ある調査結果の報道では、テストされたサンプルのAI生成コードの約半数がセキュリティ問題を含んでおり、安全性や規制遵守が重要な本番システムへの採用に大きな障壁となることを指摘しています nearly half of AI-generated code has security flaws。

ベンダーの主張を比較する際、ジャーナリストやエンジニアは以下の指標を求めるべきです：

• モデルアーキテクチャとサイズ、トレーニングコーパスとその出所の説明（使用されたコードとライセンス）。

• 大規模プロジェクトのレイテンシとスループット（複数モジュールのシステムを生成またはリファクタリングするのにかかる時間）。

• 標準ベンチマークおよび代表的なエンタープライズコードベースでのテスト合格率（おもちゃのデータセットだけでなく）。

• 独立したセキュリティ監査またはレッドチーム演習で測定された経験的脆弱性率。

ベンダーの声明にしばしば欠けているのは、トレーニングデータの出所（トレーニング例がどこから来たか）、脆弱性が発見された際のモデルの更新方法、正しさや修復に関するSLAレベルの保証の有無といった必須仕様です。これらのギャップは重要です。なぜなら、エンタープライズは規制された環境にコードをデプロイする際にトレーサビリティと予測可能な動作を必要とするからです。

洞察：セキュリティ調査結果は単なる学術的なものではなく、調達やQAポリシーを形作るべきです。ベンダーが本番対応を主張する際は、独立したレッドチームまたはブルーチームのレポートを求めましょう。

重要なポイント：ベンチマークは局所タスクでの実質的な進歩を示しています。セキュリティ分析は大規模での実質的なリスクを示しています。両方とも評価の一部である必要があります。

ロールアウトのタイムラインと市場採用 — AIがコードの90%を書くのに3〜6ヶ月は現実的か？

タイムライン vs 現実世界の摩擦

Amodeiのタイムライン（3〜6ヶ月）はメディアの急速な増幅と鋭い反発を引き起こしました。報道は予測の素直な報道から、その数字を誇大広告と表現する懐疑的な見方まで幅広く、一部の業界関係者は現在の制約を考慮すると90%という数字は非現実的だと述べました。この予測はBenzingaやWebsitePlanetなどの媒体によって迅速に報じられ、投資家や開発者層に届きました Benzinga coverage of Amodei prediction および WebsitePlanet’s summary of the claim。

市場採用のシグナルはより慎重です。企業は生産性向上タスクのためにAIコーディングアシスタントを急速にパイロット導入しており、多くのチームが定型業務や日常的なリファクタリングで具体的な速度向上を報告しています。企業による採用に関するFinancial Timesの報道は、企業関心の高まりを強調しつつ、採用が人間による著述の全面的な置き換えを意味するものではないことを指摘しています。ほとんどの組織はレビュー、コンプライアンス、統合業務に人間を関与させ続けています FT on adoption trends。

規制と標準も広範な展開を遅らせます。規制セクターで事業を行う企業は、調達ルール、セキュリティ標準、時には業界固有のコンプライアンス体制に合わせる必要があります。既存のISO標準および進行中の標準化作業は、ツールが重要なコードベースを任される前に満たすべきガバナンスの期待を生み出します ISO standard context。同様に、主要市場における保留中の立法および調達フレームワークは、トレーサビリティとリスク評価を要求し、統合スケジュールに数ヶ月を追加します。

記者が強調すべき実用的ロールアウト障壁には、統合作業（connecting AI outputs into CI/CD pipelines）、コンプライアンスチェック（ライセンス出所とデータプライバシー）、セキュリティ監査（自動および手動レビュー）、生成された出力を検証するためのQAパイプラインの更新が含まれます。これらのプロセスは、モデル精度の向上だけでは容易にタイムラインを延ばします。

業界の反応には慎重な声も含まれました。例えば、Linus Torvaldsの反応（一部の報道で90%という数字を「誇大広告」と呼んだ）は、大規模で複雑なコードベースを管理する実務者からの懐疑を表しています India Today reported that criticism。

重要なポイント：モデルの急速な改善は重要ですが、ガバナンス、統合、セキュリティの現実を考慮すると3〜6ヶ月は楽観的です。

現在のLLMコーディングツールと90%の主張の比較

今日のアシスタントが確実にできることとできないこと

現在の大規模言語モデル（LLM）コーディングツールは、特定の限定されたタスク（オートコンプリート、短いヘルパー関数の生成、定型コードの作成、孤立したユニットのテスト提案）で優れています。開発者はこれらの機能を活用して日常業務を加速し、迅速にプロトタイプを作成します。しかし、モデルが大規模コードベースにわたって推論したり、ステートフルな相互作用を管理したり、長期的な文脈を必要とするアーキテクチャレベルの設計判断を下したりする必要がある場合、パフォーマンスの範囲は狭まります。

研究比較では、モデル世代を通じてベンチマークタスクで意味のある改善が見られますが、クロスファイル推論やセキュリティの堅牢性などの側面では向上が停滞するパターンが現れます code-generation research。一方、セキュリティテストは持続的な脆弱性を強調しています。独立した分析では、生成されたスニペットの高い割合に欠陥が含まれており、この問題は主要なモデル全体で続いています TechRadar’s security findings。

記者がベンダーの発表を報道する際は、主張される指標を学術的ベースラインと照合すべきです。ベンダーには以下を求める：

• 標準およびエンタープライズ類似ベンチマークでのテスト合格率。

• 独立した監査人による経験的脆弱性率。

• コンテキスト長の処理能力（モデルがリポジトリのどれだけを合理的に考慮できるか）。

• 生成コードのバージョンおよび依存関係解決戦略。

完全自動化に代わる実用的で広く使われている選択肢もあります。Human-in-the-loopワークフロー（AIが変更を提案し、開発者がレビュー・洗練する）は、モデルの速度と人間の判断を組み合わせます。AIとのペアプログラミングは、設計とシステムレベルのトレードオフの制御を開発者に保持させます。企業の独自コードベースで小規模モデルをファインチューニングする専用パイプラインは、内部標準やライセンスに合わせることで一部のリスクを低減できますが、運用およびデータガバナンスのオーバーヘッドも生じます。

洞察：ベンダー仕様を学術的ベンチマークおよび独立したセキュリティレポートと比較することは、信頼できる報道に不可欠です。

重要なポイント：今日のLLMツールは強力なヘルパーであり、エンジニアリングチームのターンキー代替品ではありません。ドメイン固有のファインチューニングと人間の監督は依然として重要です。

実世界の使用と開発者への影響 — AIがコードの90%を書く場合、チームと本番システムが実際に経験すること

エンジニアリング組織内の運用現実

AIがコードの大部分を生成する場合、チームは即時的かつ構造的な変化の両方を経験する可能性が高いです。短期的には、多くの組織が反復的なタスク（新しいサービスの足場作り、APIクライアントの生成、テストスタブの作成）を自動化することで価値を引き出します。これらの利点は定型業務での速度向上として現れる傾向があります。

しかし、これはトレードオフを伴います。組織は新しいQAチェックポイントを必要とします：AI出力の専用セキュリティスキャン、疑わしいパターンでビルドを失敗させるより厳格なCI/CDゲート、強化されたライセンス出所チェックです。新しい役割（AI-auditors or model-evaluation engineers）が生まれる可能性があり、その仕事は生成されたコードを検証・キュレーションすることです。開発者のスキルセットは変化します：効果的なプロンプトを作成する専門知識（プロンプトエンジニアリング）、モデル出力を評価する、AIの提案を安全に統合する、などが職務記述書の一部になります。

セキュリティ研究は注意を促す証拠を提供しています：バグ密度の増加と安全でないデフォルトが、AI-generated codeに非自明な割合で現れ、チームは検出および緩和パイプラインへの投資を必要とします analysis of security flaws in AI code。実際、企業は機密コンポーネントに小規模でファインチューニングされたモデルを使用する、AI出力向けに調整された自動静的解析を適用する、重要なパスに人間の承認を強制する、といった緩和策を採用しています。

実際のユーザー影響は様々です。一部のチームは日常タスクでの反復速度向上を報告し、他は複雑なモジュールでのレビューオーバーヘッドと手戻りが初期の速度向上を相殺すると感じています。採用と組織設計では、優先事項が純粋な実装スキルからシステム設計、レビュー、モデル評価能力へと移行する可能性があります。

洞察：即時の生産性見出し（「より速いコーディング」）は、システムを安全かつ保守可能に保つために必要な下流作業の増加をしばしば過小評価しています。

重要なポイント：定型やテンプレートでの意味のある生産性向上は期待できますが、複雑で本番クリティカルなコードではレビューとセキュリティオーバーヘッドの増加も予想されます。

FAQ

「AIがコードの90%を書く」という主張に関するよくある質問

Q1: AIは本当に3〜6ヶ月でコードの90%を書けるのか？

• 短い回答：多様な実世界のコードベースで本番レベルの90%コード生成をそのタイムフレームでサポートする明確な公的証拠はありません。予測は広く報じられましたが、実務者やアナリストは懐疑を表明しており、ベンチマークとセキュリティ調査結果はその結論を制限しています Anthropic CEO prediction reported および industry pushback was documented。

Q2: 今日の90% AI生成コードを阻む最大の技術的限界は何か？

• 限界には、大規模コードベースのコンテキストウィンドウ制約、生成コードにおける持続的なセキュリティ脆弱性、結合フローの信頼できないテストカバレッジ、生成出力を既存システムに統合する困難が含まれます。学術的評価はこれらのギャップを明確に示しています code-generation research。

Q3: AI生成コードは本番に投入して安全か？

• セーフガードなしでは安全ではありません。研究では生成されたスニペットに顕著な脆弱性率が示されており、エンタープライズはAI生成の変更を受け入れる前にセキュリティスキャン、人間によるレビュー、出所チェック、より厳格なCI/CDゲーティングを採用しています security findings on generated code。

Q4: ニュースルームは「AIがほとんどのコードを書く」というベンダーの主張をどのように精査すべきか？

• ベンダーに対し、コンパイルしてテストに合格するサンプルプロジェクト、標準ベンチマークでのテスト合格率、独立したセキュリティ監査、トレーニングデータ出所の文書化を求めましょう。これらの主張を学術的ベースラインおよび独立した分析と比較してください research summary および critical commentary。

Q5: AIがコードの大部分を生成し始めた場合、関連するポリシーと標準は何か？

• 既存のISO作業および新興の立法フレームワークはAIの展開と調達に関連します。エンタープライズは、生成コードの検証とガバナンスに影響する関連ISOソフトウェア/AIガイダンスや各国の調達ルールなどの標準を監視すべきです ISO standard context およびより広範な立法議論。

「AIがコードの90%を書く」という主張が開発者とエコシステムにとって意味すること

理にかなった予測と実践的な次のステップ

証拠は明確なパターンを示しています：コード生成モデルは対象タスクで目覚ましい進歩を遂げ、開発者ワークフローを引き続き変革するでしょうが、我々が持つデータと監査は、多様なシステムにわたる即時の90%本番対応AI記述コードへの大転換を支持するものではありません。モデルアーキテクチャとデプロイツールの急速な反復は、定型、テスト足場、小規模サービステンプレートなどで意味のある生産性向上をもたらすでしょう。しかし、ソフトウェアエンジニアリングのより困難な部分は当面は人間中心のままです。

今後数ヶ月から数年で、真の構造的変化を示すいくつかのシグナルに注目してください：複数モジュールの生成と統合を測定する再現可能な独立ベンチマーク、トレーニングデータ出所と脆弱性修復に関する透明なベンダー開示、セキュリティ態勢の変化なしまたは改善された状態で本番までの時間短縮を示す監査済みエンタープライズケーススタディです。規制と標準化作業も実用的採用を形作るでしょう。規制産業の企業は、AI-generated code as routineとして扱う前に、トレーサビリティと監査可能性を実証する必要があります。

組織にとって sensible な姿勢は適応的であることです：リスクが低い領域（内部ツール、プロトタイプ、生成テストスイート）で積極的にパイロットし、レビューとスキャンインフラに投資し、プロンプト設計とモデル評価のスキルを育成する。ベンダー主張を報道する記者にとって、最良の質問は具体的です：コンパイルされた成果物、テスト合格記録、独立したセキュリティ監査、モデルがライセンスと出所をどのように扱うかの明確な説明を見るよう求めましょう。

先の物語は二元的なものではありません。AIは開発者にとって力の増幅器となり、一部のタスクを加速し、他のタスクを変えるでしょう。同時に、セキュリティ、ガバナンス、システム思考が重要性を増し、役割と組織の優先事項を再形成するでしょう。その二重性（速度と caution ）が、AIがほとんどのコードを書くという見出しの背後にある実践的現実です。それらの変化を報道または対応しようとするなら、再現可能な証拠を求め、安全性を優先し、次の意味のある変化の指標として独立したベンチマークを追跡してください。

Anthropic’s prediction and its media ripple、金融メディアで報じられたより広範な採用トレンド、モデルの強みとセキュリティリスクの技術的分析は、1つの実践的な結論を示唆しています：ベンダーのタイムラインには健全な懐疑心を持って接し、本当の本番対応の尺度として測定可能で監査可能な成果に焦点を当てましょう。