導入 ― 年間21兆円を賭けた企業が「思ったほど加速していない」と言った

2026年7月2日、Metaの社内タウンホールでマーク・ザッカーバーグが、AIエージェント開発について踏み込んだ発言をした。少なくとも直近4か月のエージェント開発の軌道は、我々が期待したようには加速していない、という趣旨の内容だ。Metaは2026年にAIインフラへ最大1450億ドル、日本円でおよそ21兆円を投じると見られている。その規模の投資を主導する当人が、社内向けとはいえ進捗の遅れを認めたことになる。

この発言は日本のエンジニアにとって他人事ではない。2025年から2026年にかけて、多くの日本企業が「AIエージェントで業務を自律化する」という前提でPoCや予算計画を組んできた。SIerの提案書にも、社内の稟議書にも、エージェントが人手を代替するという絵が描かれている。その絵の描き手であるフロンティア企業が「まだ来ていない」と言っているとき、我々は何を読み取ればいいのか。

ここで一番やってはいけないのは、この発言を「AIはやはりバブルだった」と受け取ることだ。実はデータを見ると、AIの能力そのものは今も指数関数的に伸びている。伸びているのに実運用が進まない。この一見矛盾したふたつの事実が同時に成り立つ理由こそが、本記事の核心である。結論を先に言うと、原因はモデルの賢さではなく、長い手順をまたいで積み上がる「誤差の複利」にある。

なお、Qiitaには既に、エージェント評価をCIに載せる実装手順を丁寧に解説した良記事が存在する。本記事はその手前、つまり「なぜ本番でコケるのか」を数式と外部データで説明し、日本企業がエージェント投資をどう判断すべきかという経営・調達寄りの視点に振り切る。実装ガイドと補完関係にあると考えてほしい。

何が起きているか ― 複数ソースが指す同じ結論

まず事実関係を、一次に近い報道から整理する。

ザッカーバーグは、2026年1月から2月の計画段階では経営陣がAnthropicのClaude Codeのようなツールに「超楽観的」だったと振り返り、その賭けはまだ実を結んでいないと述べた。同時に、今後3〜6か月でより大きな効果が出始めるという期待も示している。この発言の背景には、Metaが2026年5月に約1割の人員削減を行い、およそ7000人をAI関連チームへ再配置した組織再編がある。つまり、組織をエージェント前提に作り替えた直後に、その前提の立ち上がりが遅れているという構図だ。

重要なのは、これがMeta一社の弱音ではないという点だ。同じ現象を、まったく別の角度から測っている研究がふたつある。

ひとつはMETRによる、AIがどれくらい長いタスクを完遂できるかの継続測定だ。彼らは「50%の確率で成功できるタスクの長さ」を時間軸で定義した。現時点のフロンティアモデルは、人間なら4分未満で終わるタスクはほぼ100%こなす一方で、人間で4時間を超えるタスクは10%未満しか成功しない。50%成功の地平線はおよそ1時間で、この地平線は約7か月で倍増するペースで伸び続けている。

もうひとつはSierraのτ-bench（タウベンチ）だ。これはツールを使ってユーザーと対話しながら業務を遂行するエージェントを評価する。彼らが導入したpass^kという指標が示したのは残酷な数字だった。gpt-4oは小売ドメインのタスクを1回で通す成功率（pass@1）が50%未満で、同じタスクを8回連続で全部成功させる確率（pass^8）は25%を切る。1回できることと、毎回できることの間には、これほどの断絶がある。

三者は立場も測り方も違うのに、同じ壁を別の面から触っている。ザッカーバーグは事業の立ち上がりとして、METRは達成可能なタスク長として、Sierraは試行間の一貫性として、いずれも「単発ではできるが、長く確実には続けられない」という同一の限界を報告しているのだ。

技術的な核心 ― なぜ「デモは動くのに本番でコケる」のか

ここからが本題だ。能力が伸びているのに実運用が進まない理由を、数式で説明する。

エージェントの仕事は、単発の質問応答と違って、複数の手順を直列につなぐ。ファイルを読む、APIを叩く、結果を判断する、次の行動を決める、という手順の連なりだ。ここで各手順が独立に確率pで成功すると単純化すると、N手順を全部成功させて初めて完了するタスクの成功率は、およそ p の N 乗になる。

これがどれほど効くかを表にすると直感に反する。

1手順あたりの成功率 p = 0.95（一見かなり優秀）
  10手順のタスク → 0.95^10 ≒ 0.60
  20手順のタスク → 0.95^20 ≒ 0.36
  50手順のタスク → 0.95^50 ≒ 0.08

1手順あたりの成功率 p = 0.99（相当優秀）
  50手順のタスク → 0.99^50 ≒ 0.61
 100手順のタスク → 0.99^100 ≒ 0.37

各手順で95%正しいモデルは、単発で見れば頼もしい。だが50手順のワークフローに載せると、完走率は1割を切る。これが「誤差の複利」だ。金利が元本に積み上がるのと同じで、失敗確率が手順をまたいで掛け算で効いてくる。

この式は、現場でよく聞く三つの症状をきれいに説明する。第一に、デモが動く理由。デモは手順が短く、かつ人がうまくいった実行を選んで見せるので、複利がまだ小さい。第二に、10回に1回コケる理由。一手順の小さな失敗確率が、長い連鎖のどこか一箇所で顕在化する。第三に、モデルを新しくしたら途中の判断がずれて以降が全部おかしくなる理由。3手目の失敗はそれ単体の失敗では終わらず、汚染された状態が後続の全手順に伝播する。

そしてこの式は、ザッカーバーグの発言とMETRのデータの矛盾も解く。METRが測る「50%地平線」は、あくまで五分五分で届く長さだ。事業で使うには五分五分では話にならない。仮に業務要件が「99%確実に完走してほしい」だとすると、必要なのは50%地平線ではなく、はるかに手前にある高信頼地平線である。能力の中央値（50%地平線）は7か月で倍増していても、実運用が要求する裾（高信頼地平線）はずっと短いまま、ゆっくりしか伸びない。ザッカーバーグが見ているのは後者で、ベンチマークが誇るのは前者だ。両者のギャップが、彼の言う「期待したようには加速していない」の正体である。

τ-benchのpass^kは、まさにこの裾を測るために作られた指標だと理解すると腹落ちする。pass@1が単発の器用さを測るのに対し、pass^kは「k回連続で外さないか」という一貫性、つまり業務に載せられる信頼性そのものを測っている。エージェント評価の主戦場が、正解率から一貫性へ移りつつあるのは、この壁を正面から見ているからだ。

補足しておくと、METRは能力向上の主な源泉が、単一手順の知識やスキルではなく、長い行動連鎖をつなぐ力の改善にあると分析している。裏を返せば、モデルは個々の手順ではもう十分賢く、ボトルネックは連鎖の維持にある。だからこそ、モデルの乗り換えだけでは壁は超えられず、システム側の設計で複利を抑え込む必要がある。

日本の実務への示唆 ― 「待つ」のではなく「複利を設計で殺す」

ここまでの理屈を、日本の現場の判断に落とす。ポイントは、3〜6か月待てば解決する話ではないということだ。待っても指数の底（1手順あたりの成功率）は劇的には上がらない。やるべきは、タスクの手順数Nを設計で縮め、失敗を安く巻き戻せるようにして、複利が牙をむく前に断ち切ることだ。

どこにエージェントを入れると今すぐ効くか

複利の式は、投資判断の物差しをそのまま与えてくれる。手順数が少なく、失敗しても巻き戻せる領域は、今のモデルでも十分にペイする。逆に、手順が長く、失敗が不可逆な領域は、現時点では自律に任せるべきではない。

領域の性質	今すぐ自律化して良いか	具体例
手順が短く可逆	積極的に入れる	定型メールの下書き、社内ドキュメント検索と要約、コード差分のレビュー補助
手順は長いが人が要所で承認	人間をチェックポイントに挟んで入れる	経費精算の一次処理、問い合わせ一次対応、テストの自動修正提案
手順が長く不可逆	まだ任せない	本番環境への無人デプロイ、顧客への課金・返金の自動確定、契約文言の自動確定

この表の判断軸は流行りではなく、p の N 乗という一本の式から機械的に導ける。稟議や提案の場で「なぜここは自律で、そこは人手を残すのか」を問われたとき、この式は感覚論ではない根拠になる。

設計で複利を殺す三つの型

自律化する場合も、複利を放置してはいけない。有効な型は三つある。

ひとつめは分割だ。50手順の一枚岩を、人間や決定的なコードが承認する切れ目で5手順×10ブロックに割る。各ブロックの入口で状態を検証してから次に進めば、失敗の伝播はブロック内で止まる。0.95^50が0.08でも、途中で7回チェックポイントを置いて弾き直せるなら、全体の完走率は現実的な水準まで戻せる。

ふたつめは冪等性とロールバックだ。前掲のQiita記事も指摘する「最終的な答えは正しく見えるのに、途中でこっそり2回も課金APIを叩いていた」という事故は、複利が可視化されにくい典型例だ。副作用を持つ手順は、必ず一意なキーで冪等にし、巻き戻せる形にしておく。

# エージェントの副作用は「冪等キー + 検証 + 巻き戻し可能」で囲う
def execute_side_effect(action, state):
    key = idempotency_key(action)          # 同じ行動は同じキー
    if ledger.already_done(key):           # 二重実行を物理的に封じる
        return ledger.result(key)          # 「こっそり2回課金」を防ぐ

    if not precondition_ok(action, state): # 手順の入口で状態を検証
        raise Halt("前提が崩れている。ここで連鎖を止める")

    result = action.run()
    ledger.record(key, result, undo=action.compensate)  # 補償トランザクションを添える
    return result

みっつめは信頼性で測ることだ。本番投入の判断を、うまくいった1回のデモではなく、同一タスクをk回流したときの全問正解率、すなわちpass^k的な指標で下す。社内の受け入れ基準を「一度成功したら合格」から「10回連続で成功したら合格」に変えるだけで、複利に対する防御力は大きく変わる。ここから先の具体的なCI実装は、前掲のQiita記事が詳しい。

経営・調達へのメッセージ

エンジニアが経営層に伝えるべきことは単純だ。エージェントのROIは、モデルの賢さ（1手順の成功率）よりも、タスクをどれだけ短く、可逆に、検証可能に設計できるかで決まる。ベンダーのデモが100手順を一気通貫でこなして見えても、それは複利がまだ小さい選ばれた実行かもしれない。評価は必ず、自社の実データで、複数回の連続試行で行う。ザッカーバーグの3〜6か月という期待値は、裏を返せば、今この瞬間に無人フル自律へ全張りするのは時期尚早だという、フロンティア当事者からの実務的なシグナルでもある。

まとめ ― エンジニアへのアクションアイテム

エージェントのタスクは手順数Nを数え、p の N 乗で完走率を概算してから設計する。式が「なぜ本番でコケるか」を定量的に説明してくれる。
導入先は「手順が短い、または失敗が可逆」を最優先にする。長く不可逆な領域は、人間をチェックポイントに残す。
副作用のある手順は冪等キーと補償トランザクションで囲い、複利が事故化する前に巻き戻せるようにする。
受け入れ基準を単発成功からpass^k的な連続成功へ変える。評価は自社データと複数回試行で行う。
能力（METRの50%地平線）は伸び続けるが、実運用が要求する高信頼地平線はずっと手前にある。この差を埋めるのはモデルの乗り換えではなく、複利を殺すシステム設計だと理解する。

AIエージェントは幻滅期に入ったのではない。単発の器用さという指標では測れない「一貫性」という別の山を、業界全体が登り始めただけだ。日本のエンジニアにとっての勝ち筋は、フロンティアの進化を待つことではなく、誤差の複利を自分たちの設計で抑え込み、今すぐペイする領域から確実に刈り取っていくことにある。

参考ソース