最近、「AIで開発速度10倍」「100倍エンジニア」みたいな言葉をよく聞きます。本当にそうなのか、自分の現場の手触りと合わせて、考えてみました。
結論を先に書くと、「タスクの性質で大きく変わる」「書くフェーズだけ見ると過大評価になる」というのが、現状の自分の観察です。

• 「10倍」「100倍」と言っているのは誰か
• タスクの性質で大きく変わる
• 「書く」と「保守」を分けて考える
• 保守の自動化への期待
• でも、判断材料が揃わない
• AIに任せられないものを、3層に分けてみる
• 影響範囲のレイヤー
• 保守はどこまで自動化できるか
• 「AIのレビューが通った」は「完了」ではない
• コードベースの量と保守コスト
• まとめ

「10倍」「100倍」と言っているのは誰か

OpenAIの Sam Altman は、2025年4月頃に「AIで10倍の生産性」と発言。Anthropicの Dario Amodei は「3-6ヶ月で AI が90%のコードを書く」、Microsoft CTO の Kevin Scott は「5年で95%のコードが AI」、Surge CEO の Edwin Chen は「100x エンジニアが生まれている」と言っています。

一方、冷静な数字も出てきています。
Coinbase のエンジニアが InfoQ で発表した観察では、「現実的な生産性向上は 15-20%」(つまり 1.15〜1.2倍)。METR の研究では、「実際の end-to-end のスループットは、AI 補助で減少した」という結果もあります。Google の DORA レポートも、2024年版では AI 導入が throughput や安定性にマイナスという結果でしたが、2025年版では throughput はプラスに転じています。ただし、安定性(本番障害など)は、依然として課題のままです。

「10倍」「100倍」と「現実は 15-20%、安定性は課題」── これだけ印象が違うのは、なぜか。

タスクの性質で大きく変わる

自分の現場で AI を使ってみた手触りは、こんな感じです。

単純な機能の開発: AIが書いたコードが読みやすく、生産性が上がる。規約・パターンが明確で、AIも適切なコードを生成しやすい。レビューも軽い。

複雑な機能の開発: 要件を自然言語で伝えるのに時間がかかる。生成されたコードを理解するのにも時間がかかる。期待通り動かないとき、修正の指示を出すのも難しい。そんなに生産性は上がらない。

アラート調査・対応: ハマらなければ早くなった。AI が並行して複数の観点で調査してくれるので、初動が速い。ただし、間違いもそこそこあるので検証が必要。正しくないと結果を伝えても、沼にハマることが多い。Opus から Codex に切り替えて解決したこともあれば、切り替えても迷宮入りしたこともある。

つまり、タスクの性質で、生産性が大きく変わる。「10倍」「100倍」というキャッチーな数字は、特定の条件(新規実装、定型タスク、よく知られたパターン)では成立するかもしれないが、全体としては成立しないことが多い。

自分の現場では、AIの進化とハーネスを育てた結果、従来の2-3倍のアウトプットが出せている実感があります。「10倍」「100倍」ではないが、確実な向上。これは現在の数字で、今後さらに上がる可能性はあります。

「書く」と「保守」を分けて考える

もう一つ、重要な観点があります。「書く」と「保守」を、分けて考える必要があるかもしれません。「コード生成が55%速くなった」というような数字は、よく見ます。これは、書くフェーズの話。新規実装、機能追加、定型的なコード生成など、「ゼロから書く」場面に集中した計測です。

でも、開発の現場では、書く時間より保守の時間の方が長いことが多い。バグ修正、リファクタ、障害対応、依存ライブラリのアップデート── これらは、すべて「既存コードに向き合う」活動です。
保守の本質は、「書く」ではなく「理解する」ことかなと思います。既存コードの構造、過去の判断の経緯、ドメイン特有の暗黙の前提を理解する。これらは、AIで効率化しにくい領域です。

つまり、書く時間が半分になっても、保守時間が変わらなければ、全体の生産性は2-3割の改善にとどまる可能性がある。「AIで開発速度が10倍」というキャッチーな数字は、書くフェーズに集中した計測なら成立するかもしれませんが、保守を含めた全体を見ると、現場の手触りとは違ってきます。

保守の自動化への期待

「保守も自動化できないか」と考えたことがあります。

理想のシナリオ: アラート発生 → AI起動(自動) → 調査(ログ・コード・依存関係) → 原因特定 → 修正コード生成 → PR作成 → E2Eテスト(自動) → 人間がレビュー → リリース

これが実現すれば、保守の大部分が自動化できる。

技術的には、繋げられます。Datadog の Webhook、GitHub Actions、Claude Code、MCP で各種ツールに接続── 部品は揃っている。
でも、実用的に運用できるかは、別の問題でした。

でも、判断材料が揃わない

人間が PR を出すとき、こんなエビデンスを添えます。

• 修正前のスクリーンショット(エラー画面、誤った表示)
• 修正後のスクリーンショット(正しい画面、期待通りの表示)
• 修正前後のログ
• 手動で動作確認したシナリオ
• 影響範囲の確認結果

レビュワーは、これを見て「本当に問題が再現していたか」「修正後に解消されているか」「別の問題を引き起こしていないか」を判断します。
AIにこれができるか。技術的には、部分的にできます。スクリーンショットは Playwright MCP で取れるし、ログも MCP で取得できる。テストの実行結果も貼れる。
ただ、「私が確認した」という人間の責任は、AIには持てない気がしています。たとえテスト結果を揃えられても、「これで本当に解決した」と判断する責任は、人間に残る。

AIに任せられないものを、3層に分けてみる

層1: 構造的にできない(本質)

• 「私が確認した」という人間の責任
• 政治、人間関係、ステークホルダーの意図
• ビジネス判断、緊急度・優先順位の判断
• 「やらない」「撤退する」の判断

これらは、将来 AI が進化しても、人間の領域に残ると思います。

「責任」という言葉は便利ですが、実際には複数の側面があります。
問題が見つかったときに対応しきる責任(障害を復旧させる、フォローアップする)は、プロセスを設計すれば AI にもある程度できるかもしれません。説明の文面(報告書、メール、ステータスページ)も、AI が書けます。

一方、謝罪の主体になる、信頼を回復するような対人的責任は、AI には難しい。AI が「すみません」と書いた文面を、人間が確認して送る、という形になる。「書ける」と「主体になれる」は、別です。

そして、意思決定の責任は、特に AI に任せにくい。「この修正は諦める、revert して別のアプローチで行こう」のような撤退の判断、「今日はここまでにする」のような時間配分の判断── AI は「やる方向」に動きがちで、自発的にこの判断はしない。明示的に「revert して」と言えば実行はできますが、判断の起点は人間です。
AI 化が進むほど、「責任」の中身を分けて考える必要があるのかもしれません。

層2: 現状では難しい(技術で解決可能)

• UI 確認(Playwright MCP などで進化中)
• 本番環境特有の挙動(サンドボックス、シャドウデプロイ)
• 動的・実行時の影響範囲の追跡

これらは、技術の進化で、徐々に AI でもできるようになっていく気がします。

層3: 情報を持たないだけ(与えれば解決)

• 暗黙のルール・慣習(CLAUDE.md、skill に書けば改善)
• 過去の議論・経緯(MCP で Notion などに接続、開発時に ADR に経緯を残せば AI も読める)
• プロジェクト固有の規約

これらは、ハーネスを育てることで、AI も対応できるようになります。

影響範囲のレイヤー

• 静的なコードの影響範囲: AI が得意。grep、依存関係追跡、似たパターン探し
• 動的・実行時の影響範囲: 部分的に AI、部分的に人間
• コード外の影響範囲: 人間が判断。別チーム、別システム、データへの影響
• 時間的な影響: 人間が判断。キャッシュ、データ蓄積、月次バッチへの影響

AI は「コードを静的に追う」のは得意です。例えば「75ファイルで使われている関数を deprecated にする」のような作業は、AIの得意領域。
でも、「コード外の影響」「時間的な影響」は、人間でないと判断が難しい。

保守はどこまで自動化できるか

AI が調査して、修正案(PR の下書き)を出すところまでは、現実的です。でも、その先── 人間のレビューを経ずに、自動でリリースまで── は、まだ早い気がします。

理由は、「完成度のギャップ」が残るから。70% を 90% にするのは AI でもできるが、最後の数%(本番リリースまで)を埋めるのが、AI だけでは難しい。最後の数%は、人間の判断と責任が必要。

具体的には、PR 作成までは AI、その後は AI レビュー(ふるい)と合わせて、人間がレビューする── これが、現状で品質を担保する、現実的な運用かなと思っています。AI レビューが明らかな問題を弾き(ふるい)、人間が前提確認・テストの妥当性・取捨選択を見る(品質担保)。両者は補完的で、AI が人間の負荷を下げ、人間が AI の盲点を埋める。

「AIのレビューが通った」は「完了」ではない

「異なるモデルでレビューさせて、指摘がなくなったら完了」── これで AI だけで品質が担保できるのか?

理論的には、効きそうに見えます。Sonnet で実装、Opus でレビュー、Codex でレビュー、指摘がなくなるまで繰り返す。多層レビューの効果。
でも、現実は、いくつかの問題があります。

1. 共通の盲点は埋まらない

すべての LLM はインターネット由来のテキストで訓練されているので、インターネット上で語られない知識(社内ドメイン、業務ルール、プロジェクト固有の慣習)には、どのモデルも弱い。全モデルから指摘がなくても、全モデルが同じ箇所を見落としている可能性があります。

2. 「無限ループ」のリスク

Opus が指摘 → 修正 → Codex が「その修正は別の問題」と指摘 → 修正 → Opus が「Codex の指示で書いたコードは別の問題」と指摘 → 修正、というループに入ることがあります。沼にハマるパターン。

3. ビジネス判断、ドメイン判断は出てこない

AIのレビューでは、ビジネスインパクト、暗黙のルール、ステークホルダーの意図、「やらない」「撤退する」の判断は出てこない。

4. エビデンスがない

人間の PR には「私が確認した」エビデンス(スクリーンショット、動作確認)がある。AI 同士のレビューでは、これがない。「指摘がない = 動作確認した」ではない。

5. 「読みやすさ」の判断が甘い

AIは「動く」「規約に従う」を重視するが、「人間が読んで意図が伝わる」の判断は、人間の方が得意。AI 同士のレビューでは、「読みにくいが動く」コードが通過することがある。

これらを踏まえると、「AIのレビューが通った = 完了」とするのは、まだ早い。
現実的には、AIのレビューは「ふるい」として使い、完了の判断は人間が持つ。AI のレビューを通過したコードを、人間が最終確認する。動作確認のエビデンスを添える。ビジネス判断、構造、読みやすさを見る。

そして、もう一つの観察があります。「指摘がなくなるまで対応」を目指すと、コードが無駄に大きくなる可能性があります。

AIのレビュー指摘を全部対応すると、起こりにくいエッジケースへの対応、過剰なバリデーション、防御的すぎるエラーハンドリング、「念のため」のチェックが積み重なって、コードが肥大化する。本質的なロジックが、防御コードに埋もれる。結果、読みやすさが下がる。

「人間が分かり難いものは、AI も分かり難い」── 全部対応した結果、人間にも AI にも分かりにくいコードができてしまう、というのは皮肉な話です。

現実的には、AI のレビュー指摘も取捨選択の判断が必要です:

• 重要な指摘 → 対応
• 些末な指摘 → 却下、または別タスクとして積む
• 誤解の指摘 → 却下、理由を記録

AI が指摘に優先度(高・中・低)をつけてくれることもありますが、優先度で機械的に切るのは危険です。「高」でも、誤解や過剰防御、スコープ外で却下すべき場合がある。「低」でも、将来の負債なら今直すべき場合がある。優先度は、見る順番の参考であって、対応するかの判断は、文脈を踏まえて人間がする。

「指摘がなくなる」を目的化するのではなく、「良いコードになる」を目的にする。シニアエンジニアが、レビュー指摘に対して取捨選択の判断を持つように、AI のレビューに対しても同じ判断が必要です。

コードベースの量と保守コスト

AI で大量にコードを書けるようになると、コードベースが膨らみます。コードベースが膨らむと、保守の負担も増える。「書く速度」と「保守の容易さ」は、トレードオフかもしれない。

最近、「AI slop」という言葉も広がっています。AI が大量生成した、質の低いコンテンツ── 動くけど深さがない、読みにくい、保守しにくい。コードベースでも、同じことが起きうる気がします。気がつかないうちに、AI slop が溜まっていく。

書ける量が増えるほど、「書く前に、本当に書くべきか考える」が、より重要になっている気がします。

「目的化させない」「最小から始めて、対話で育てる」という考え方が、ここでも効いてくる気がします。AIで効率化が進むほど、「やる/やらない」「どこまで書くか」の判断が、人間に残る。

まとめ

「AIで開発速度10倍」「100倍エンジニア」── キャッチーな数字は、業界の言説として目立ちます。でも、現場の手触りでは、もう少し慎重な観察になります。

• タスクの性質で生産性が大きく変わる(単純な機能は上がる、複雑なものは上がりにくい)
• 書く時間だけ見ると過大評価になる、保守を含めると改善は2-3割程度
• 保守の本質は「理解」で、AIで効率化しにくい
• 判断材料の非対称性がある(エビデンス、ビジネス判断、影響範囲)
• 保守の自動化は、AI が PR 下書きを出すまでは現実的、自動リリースまでは早い
• PR 作成まで AI + ふるい + 人間レビューが、品質担保の現実的な運用
• 「AIのレビューが通った = 完了」ではない、人間の判断が残る
• 取捨選択の判断が、AI のレビュー指摘に対しても必要(優先度で機械的に切らない)
• コードベースの量と保守コストはトレードオフ(AI slop を溜めない)

未来は分からないけど、現在は、こんな感じかなと思います。「過剰な期待にも過剰な不信にも振れない」「自分の文脈で判断する」── AI で生産性を測るときも、同じだと思います。

これも結局、いつものエンジニアリングの延長な気がしています。派手な数字に振れない、現場の手触りで判断する、書く時間だけでなく保守を含めて全体を見る。AIコーディング特有の話というより、何かを測るときの基本かもしれません。