トークンを水のように使うビッグテックの神話、その裏に隠された3つの構造的限界

最近、ソフトウェア開発業界で「ループエンジニアリング(Loop Engineering)」が大きな注目を集めている。AIがコードを生成(generate)、テスト(test)、デプロイ(deploy)まで自動化した後、再びその結果を入力にフィードバックする閉鎖循環(closed-loop)開発方式を意味する。無限のトークンを持つ超巨大AI組織のように、人間の介入を最小限にしたまま製品を無限に進化させようというビジョンである。

しかし現実は異なる。これまでループエンジニアリングで意味のある成果を出したとされる事例は、大部分がトークンを「水のように」使えるLLM企業か、Google・Meta・Microsoftのようなビッグテック組織に限られている。実際に産業現場でゼロベース(zero-base)から始めて実際のライブサービスに繋がった事例は見つけにくい。本コラムは、ループエンジニアリングが汎用解として定着できない決定的な3つのボトルネックを、具体的な事例・レファレンスとともに分析する。

1. トークン富裕層の専有物 — よく整備された文書・テスト・シナリオの欠如

ループエンジニアリングが効果を発揮するには、LLMが理解できる豊富な文書、ユーザーシナリオ、DB関連のテストコードが支えとなる必要がある。これはデータインフラが莫大な組織だけの特権である。

成功事例 — 整備されたデータの上でのみ動くループ

ビッグテックの成果は例外なく「よく整備された社内データ」という土台の上に立っている。

  • Google: 社内1万人以上の開発者を対象に、8言語、3か月にわたってML基盤のコード補完(ML-Enhanced Code Completion)を適用した。結果、ビルド-テストの反復時間(coding iteration time)が6%減少し、コンテキストスイッチング(context switch)は7%減少、提案の受容率(acceptance rate)は25〜34%に達した。ただしMLが実際に書いたコードは全体の約3%にとどまった[1]。つまり、莫大な資源を投入してもオートメーションの実質的な比重は限られているという点をビッグテック自身が示した形である。
  • Meta: 自社コードベースで学習した「CodeCompose」を1万6千人のエンジニアに配布し、15日間で450万件の提案を提供した。提案受容率22%、開発者が入力したコードの8%がCodeComposeから生まれ、定性フィードバックの91.5%が肯定的だった[2]。注目すべきは別の点である。Metaは学習前段階で「PHP-ism」のような旧式パターンやプロダクションに上がらなかった実験コードを意図的にフィルタリングした。良質なデータを人間が先にキュレーションしたからこそループが機能したのである。
  • Microsoft/GitHub: よく引用される「コパイロットで開発速度55%向上」という数値の正確な出所は、Microsoftの社内一括適用結果ではなく、GitHubの統制実験(controlled experiment)である。専門開発者約95人を2つのグループに分けてJavaScript HTTPサーバーを実装させたところ、コパイロットを使ったグループが平均71分で完了し、対照群(161分)より55%速かった(p=0.0017)[3]。ただし、これは「仕様が明確で普遍的な単一課題」という理想的な条件下での結果であることを明確にしておく必要がある。

現実の壁 — 整備されていない環境では欠陥が量産される

中小規模組織やスタートアップの事情は全く異なる。テストカバレッジが低く文書化が不十分な環境にAIコーディングアシスタントを投入すると、むしろ欠陥が量産される逆効果が現れる。検証なしに採用されたAI生成コードのかなりの部分(一部の分析では約48%)がセキュリティ脆弱性を含む可能性があるという報告が代表的である[4]。ループを回すには、そのループの出力を検証する「ベンチマークデータ」がまず必要だが、大部分の企業はこれを備えないまま流行だけを追って失敗する。

要するに、ループエンジニアリングの第一の参入障壁はモデルの性能ではなく入力データの品質であり、これは本質的に「トークン富裕層」だけの専有物である。

2. 産業ドメイン知識の死角 — LLMもベストプラクティスを見つけられない

LLMが最適な実装パターンを見つけるには、該当ドメインのコードとアーキテクチャが事前学習(pre-training)データに十分反映されている必要がある。Web・モバイルアプリのような普遍的な領域はGitHubに豊富だが、製造・金融・医療のような特殊産業の中核ロジックは公開データにほとんど存在しない。

具体的な限界事例 — ビジネスロジックの前で崩れる変換

レガシーコードの現代化はこの限界を最も鮮明に示す分野である。COBOLは今も世界の銀行取引の約70%を処理するミッションクリティカル(mission-critical)な資産である[5]。

  • 汎用LLMの限界: ある実務比較分析では、汎用ツールであるGitHub CopilotにCOBOLプログラムのJava変換を任せたところ、ビジネスロジックとシステムコンテキストの理解が欠けた「表面的な変換」を出した。DB2連携を漏らし、新規顧客番号生成を制御するNCS(Named Counter Server)の役割も認識できなかった[6]。公開データにないドメインルールはモデルが作り出せないことを示している。
  • 専用ツールでも人間の検証は必須: IBMは1.6兆トークンで学習し、数千組のCOBOL-Javaプログラムでファインチューニングした専用モデル(Granite 20Bベースのwatsonx Code Assistant for Z)を出した[5]。しかし2026年の実務レビューは依然として「精緻化(refinement)なしにプロダクションにそのまま使える結果を期待してはならない」と明示している。つまり、専用ツールでもシニア開発者の手作業検証と意味的等価性(semantic equivalence)テストは省けない[6]。
  • ドメインロジックでの一貫した失敗: 開発者400人余りを対象としたZoomInfoの事例でも、コパイロットはボイラープレート(boilerplate)生成には有用だったが、ドメイン特化ロジック(domain-specific logic)では苦戦した[3]。

正確な産業知識を指示できる人間の専門家の介入なしには、ループはそれらしく見えて実は的外れな方向に収束するだけである。規制が厳しい金融・医療環境ほど、この死角のリスクは大きくなる。

3. 経済性の蜃気楼 — トークンコストと検証人員という二重の請求書

仮に1番(データ)と2番(ドメイン知識)を部分的に解決したとしても、最後の関門が残っている。ループを「回し続ける」コストそのものである。ビッグテックがトークンを水のように使える理由は単純である。自社インフラを持っているか、モデル製造会社自身だからである。一般組織には毎月の請求書が届く。

第一の請求書 — 暴走するトークンコスト

エージェント型(agentic)コーディングは単純なチャット・推論に比べ圧倒的に高価である。

  • ある研究によれば、エージェント型コーディングタスクは、チャット・コード推論よりも約1,000倍多いトークンを消費し、リトライと自己修正(self-correction)ループを含めるとタスク1つ当たり100万〜350万トークンに達する[7][8]。
  • さらに大きな問題は予測不可能性である。同一タスクを繰り返し実行してもトークン使用量が最大30倍まで揺れ動き、トークンをより多く使っても正確度が上がるわけではない。むしろ正確度は中間コスト区間でピークを打ち、それ以上では飽和する。さらにフロンティアモデルは自身のトークンコストをまともに予測できず、体系的に過小評価する[8]。予算を立てる行為自体が成立しないのである。
  • コストは直ちに現金流として現れる。Claude Codeは開発者1人当たりのアクティブ利用日基準で約13ドル、自動化を強く回すとエンジニア1人当たり月500〜2,000ドルまで跳ね上がる[9]。GitHub Copilotがトークン量課金に転換すると開発者は10〜50倍のコスト増加を訴え、エージェントセッションを回すユーザーは月750〜3,000ドルを見込んだ。特に「バイブコーディング(vibe coding)」に依存していた非開発者グループが最も大きな打撃を受けた[10]。

私自身も効率的にトークンを使うため用途に合わせて様々なLLMを使っているが、トークンを燃やすコストをAIタイクーンに投資する方が投資対効果(ROI)が良いだろうという結論に達した。結局、セキュリティなど注意が必要な部分は人間が確認しなければならず、確実にLLMが理解しやすい文書を作った方が効率的だった。

第二の請求書 — 隠れた検証人員コスト

ループの出力は無料で信頼できるものではない。誰かが読んで、検証し、修正しなければならない。そしてそのコストが節約効果を相殺することが多い。

  • 非営利研究機関METRが2025年に実施したランダム化対照試験(RCT)は通念を正面から覆した。平均100万行規模の成熟したオープンソースリポジトリで246件の実タスクを行った熟練開発者16人は、AIツールを使用した際にむしろ作業が19%遅くなった。それでも本人たちは20%速くなったと信じていた[11]。
  • ただしこの結果は慎重に解釈すべきである(不確実性ラベル: 中)。METR自身が2026年の追跡レビューで選択バイアス(selection effect)の可能性を認め、実験デザインを修正中であり、一部の追跡推定では既存参加者-18%、新規参加者-4%と効果の大きさが変化した[12]。つまり、「AIは常に遅くする」という法則ではなく、成熟したコードベースでは検証負担が生産性利得を蝕みうるという強い信号として読むべきである。

総合 — ビッグテックの会計でのみ閉じるROI

結局、ループエンジニアリングの投資収益率(ROI)は、トークンを限界コスト0に近く調達できるビッグテックの会計帳簿の中でのみ一部成立する。一般組織では(1)変動性の大きいトークンコストと(2)減らない検証人員コストが合わさった「二重の請求書」が、保証もされていない速度向上と引き換えになる。コーディングへの理解、産業ドメインの理解がなければ、単に空回りする無限ループになるしかない。

3つのボトルネックの要約

構造的ボトルネック なぜビッグテックは通過できるのか なぜ一般組織は失敗するのか
1. 入力データ(文書・テスト・シナリオ) 社内に整備・キュレーションされたコード、テスト、シナリオが膨大に蓄積(例: Metaの学習データの事前フィルタリング) テストカバレッジ・文書化の不足→検証基準の不在、バグの量産
2. ドメイン知識(産業特化ロジック) 自社ドメインデータで直接ファインチューニング可能 製造・金融・医療の中核ロジックが公開データに不在→表面的・誤った変換
3. 経済性(トークン・検証コスト) 自社インフラ/モデル保有→トークン限界コスト≈0 タスク当たり100万〜350万トークン、最大30倍の変動+検証人員コスト→ROI未達

結論 — ループは電動工具であり、自律的なオラクルではない

ループエンジニアリングのビッグテック成功談をそのまま移植しようとする試みは大抵失敗する。成功の本質が「優れたAIモデル」ではなく、そのモデルを取り囲む整備されたデータ・蓄積されたドメイン知識・限界コスト0のトークン調達という3つのインフラ的前提にあったためである。この前提がない組織で人間の介入を取り除いた完全自動ループを期待することは、道具の性能でインフラの不在を埋めようとする錯覚に近い。

「LLMはエクセルであり、オラクルではない。」エクセルが計算を加速するが会計判断まで代行しないように、ループは開発を加速する電動工具であるだけで、自律的に正しい製品を生み出す神託(oracle)ではない。現実的な戦略は、閉鎖ループの神話を追う代わりに、人間が検証の輪(human-in-the-loop)に残る段階的・部分的な自動化をまず定着させ、その上でデータとドメイン知識を蓄積してループの半径を徐々に広げていくことである。

参考文献(References)

  1. Google Research, "ML-Enhanced Code Completion Improves Developer Productivity," 2022. (社内1万人以上/8言語/反復時間6%減少/MLコード比重約3%/受容率25〜34%)
  2. Murali, A. et al., "AI-assisted Code Authoring at Scale: Fine-tuning, deploying, and mixed methods evaluation (CodeCompose)," Proc. ACM Softw. Eng. (FSE), 2024. (受容率22%/入力コードの8%/肯定91.5%)
  3. Peng, S. et al., "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," arXiv:2302.06590, 2023; GitHub Research Blog, 2022. (統制実験約95人、55%短縮); ZoomInfoドメインロジックの限界関連: Bakal et al. (arXiv:2502.13199引用)。
  4. AI生成コードのセキュリティ脆弱性に関する報告(未検証コードの一部で約48%の脆弱性を含む可能性)およびStanford研究(AIコーディングツール使用時のセキュリティ欠陥増加傾向)。公開2次報道に基づき、精密な数値は環境依存的である(不確実性: 中)。
  5. IBM Research, "Application modernization with IBM generative AI (watsonx Code Assistant for Z)," 2023-2025. (Granite 20B/1.6兆トークン学習/COBOLが世界の銀行取引の約70%を処理)
  6. CROZ, "An Honest Take on watsonx Code Assistant for Z," 2026(実務レビュー); Vicky's Notes(Medium), "Comparing AI Tools for COBOL2Java," 2024(Copilotのビジネスロジック漏れ・NCS未認識の事例)。
  7. iternal.ai, "Tokenization in NLP: Tokens, Usage & Cost Guide," 2026. (エージェント型コーディングタスク当たり100万〜350万トークン)
  8. Stanford Digital Economy Lab, "How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks," arXiv:2604.22750, 2026. (チャット比約1,000倍/同一タスク最大30倍の変動/コスト増が正確度増に直結しない/自己コスト予測の失敗)
  9. Atlas Cloud, "How to Reduce AI Coding Token Cost," 2026(CloudZero 2026引用)。 (Claude Code 1人アクティブ日約13ドル/自動化時月500〜2,000ドル)
  10. TechJournal, "GitHub Copilot Token Billing Backlash," 2026. (量課金転換後10〜50倍のコスト増加を訴え/エージェントセッション月750〜3,000ドル見込み/バイブコーダー最大の打撃)
  11. Becker, J., Rush, N., Barnes, E., Rein, D., "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR / arXiv:2507.09089, 2025. (熟練開発者16人・246タスク、AI使用時19%遅延、本人認識は20%短縮)
  12. METR, "We are Changing our Developer Productivity Experiment Design," 2026. (選択バイアスの認定および設計修正/追跡推定: 既存参加者-18%、新規参加者-4%)

本コラムのすべての定量数値は公開された1次・2次出典に基づき、出典別の測定条件が異なるため直接比較には注意が必要である。確定した結果と解釈上の推定は本文中で区別して表記した。