- AIエージェントブームが2025年に大きく到来するという期待とは裏腹に、実際のプロダクション環境には現実的な限界がある
- エラーの累積とトークンコストの問題により、多段階ワークフローを完全自動化することは現時点では不可能
- 多くの成功しているエージェントシステムは、厳しく制限されたドメインと人間の承認または検証プロセスを必須としている
- 本当に難しいのはAIの性能そのものではなく、エージェントがうまく使えるツールとフィードバックシステムの設計である
- 2025年に完全自律エージェントを前面に押し出すスタートアップ/企業は、実導入と拡張の過程で大きな障害に直面すると見込まれる
2025年にAIエージェントは到来しないと私が賭ける理由（AIエージェントを開発しているにもかかわらず）
- 2025年がAIエージェントの年になるという誇大宣伝があふれている
- 筆者はこの1年間、実際のプロダクション環境で動くさまざまなAIエージェントシステムを自ら構築してきた
- 直接的な実務経験に基づき、市場で語られる「エージェント革命」には懐疑的な立場を取っている
多様なエージェントシステムを構築した経験
- 開発エージェント: 自然言語からのReactコンポーネント生成、レガシーコードのリファクタリング、APIドキュメントの自動管理、仕様ベースの関数生成など
- データ & インフラエージェント: 複雑なクエリやマイグレーション処理、マルチクラウドDevOpsの自動化
- 品質 & プロセスエージェント: lintの自動修正、テストコード生成、コードレビューおよび詳細なPull Requestの自動化
- これらのシステムは実際に価値を生み、時間も節約してくれるが、その経験こそが誇大宣伝に対する批判的な視点の背景になっている
要点: AIエージェントをめぐる3つの冷徹な現実
- エラー率の累積: ステップが増えるほど成功率は幾何級数的に低下する。プロダクション基準（99.9%以上）を満たすのは難しい
- コンテキストウィンドウとコスト: 対話が長くなるほどトークンコストが二乗的に増加し、経済性が崩れる
- ツールとフィードバック設計の難しさ: 技術的限界ではなく、エージェントが活用できるツールとフィードバックシステムの設計こそ最大の課題
エラー累積という数学的現実
- 多段階の自律ワークフローは、エラーの累積により実運用規模では実現不可能
- たとえば各ステップで95%の信頼度があっても、20ステップでは**最終成功率は36%**にすぎない（プロダクションの要求水準は99.9%以上）
- 高い信頼度を仮定しても、ステップが増えるほど失敗確率は大幅に上がる
- 実務ではすべてのプロセスを完全自動化せず、各ステップに独立した検証とロールバック地点、そして人間による確認を置く構造で設計する
- 成功するエージェントシステムのパターン: 明確に制限されたコンテキスト、検証可能な作業、重要な地点での人間の意思決定関与
トークンコスト構造と経済的限界
- コンテキストウィンドウおよび対話を維持するためのトークンコストは、システム拡張時に不経済な現実として浮上する
- 対話型エージェントは毎回すべての会話履歴を処理しなければならないため、ラウンドが増えるほどコストは二乗的に急増する
- 100往復に及ぶ対話では、トークンコストだけで50〜100ドルかかり、大量ユーザーに適用すると経済性が崩壊する
- 一方、Stateless（ステートレス）方式の単一スロットで文脈不要の機能生成エージェントは、コストとスケーラビリティの面で有利である
- 最も成功しているプロダクションエージェントは、「対話型」よりも「明確な目的を持つスマートツール」に近い
ツール設計とフィードバックシステムの壁
- 生産性の高いエージェント開発の本当の難所は、既存チームが過小評価しがちなツール設計能力にある
- ツールコール自体の精度は高くなったが、複雑な状態や結果を効果的に要約してエージェントにフィードバックする設計が鍵となる
- 例:
- 作業が部分的に成功したとき、どれだけの情報とどのような要約が必要かを判断する必要がある
- たとえばクエリ結果が10,000件なら、「成功、1万件、先頭5件のみ」のような状態把握用の抽象化設計が求められる
- ツール失敗時には回復に必要な情報量の調整とコンテキスト汚染の防止が必要
- 実際に成功したデータベースエージェントの核心: エージェントが実質的に意思決定できる構造化フィードバックを提供すること
- 現実にはAIが担うのは約30%で、残りの70%はツールのフィードバック・復旧・コンテキスト管理などの従来型エンジニアリング能力が占める
実際のシステム統合の限界
- 信頼性とコストの問題を解決しても、現実世界との統合問題が別の壁として立ちはだかる
- 現実の組織システムは一貫したAPIではなく、レガシー特性、例外的エラー、変化する認証、可変的な制限、コンプライアンス規定など、予測不可能な複雑性を内包している
- 実際のデータベースエージェントでは、接続プール管理、トランザクションロールバック、読み取り専用レプリカの尊重、クエリタイムアウト、ログなど、従来型プログラミングが不可欠である
- 「AIがすべてのスタックを完全自律的に統合する」という約束は、実際の構築では現実の壁にぶつかる
実際によく機能する方式のパターン
- 成功しているエージェントシステムの共通原則
- UI生成エージェント: ユーザー体験は人間が最終レビュー（AIは自然言語→React変換の複雑さだけを担当）
- データベースエージェント: 破壊的操作は常に人間が確認（AIはSQL変換のみ、データ保全の統制は人間）
- 関数生成エージェント: 明確な仕様内に限定して動作（状態・副作用・複雑な統合なし）
- DevOps自動化: インフラコード生成はAI、デプロイ・バージョン管理・復旧は既存パイプライン
- CI/CDエージェント: 各段階は明確な成功基準とロールバック機構で設計
- パターン要約: AIが複雑性を処理し、人間が制御権を維持し、信頼性は従来型エンジニアリングが確保する
市場見通しと予測
- 完全自律エージェントを掲げるベンチャースタートアップは、収益性の問題に真っ先に直面するだろう
- 5段階ワークフローではデモが見事でも、実際の企業は20段階以上を求め、数学的限界に直面する
- 既存ソフトウェアにAIエージェントを単純追加した企業は、実用的な統合の不備により採用停滞の可能性が高い
- 本当の勝者: 明確に制限されたドメイン内で、AIを難しい作業にだけ適用し、重要な意思決定には人間と境界条件を設けるチーム
- 市場は「デモではうまく動くAI」と「本当に信頼できるAI」の違いを、高くつく経験を通じて学ぶことになるだろう
望ましいエージェントシステム構築の原則
- 明確な境界設定: エージェントの役割と人間/既存システムへのハンドオフ区間を明確に定義する
- 失敗を前提にした設計: AIエラー発生時のロールバック・復旧構造を設計することが必須
- 経済性の検証: インタラクション単価とスケール拡大を踏まえた構造設計（ステート保持よりステートレスのほうが経済的）
- 自律性より信頼性を優先: 一貫して動作する仕組みは、ときどき魔法のように動くシステムより信頼を得る
- 堅牢な基盤の上に構築: 難しい部分（意図解釈、生成など）だけをAIに割り当て、残り（実行、エラー処理など）は従来型ソフトウェアに任せる
実戦経験から得た本当の教訓
- 「デモでは動く」と「実際の大規模運用」の間の隔たりは非常に大きい
- エージェントの信頼性、コスト最適化、統合の複雑性などは、いまだ業界全体で解決されていない主要課題である
- 実際の構築経験と率直な経験共有こそが業界発展の核心である
- 実戦経験者が合理的な方法論と現実的な失敗事例をより多く議論するほど、全体としての成功可能性は高まる
1件のコメント
Hacker Newsの意見
AmazonのAIプロダクションエンジニアと話したことがあるが、その人によれば、現在どの企業も顧客と直接会話する場面で生成AIだけを使っているケースはまったくなく、すべての自動応答は従来の非生成型の「古典的な」技術を使っているという。生成AIの信頼性の問題は、企業の評判を賭けるには大きすぎる
以前は「古典的AI」の記号的手法と伝統的な機械学習を組み合わせるエージェントに強い関心があったが、主にトランスフォーマー以前のニューラルネットワークに携わることになった。結局は常に人間が介在するシステムを先に作り、評価と訓練データを集め、その後でシステムが業務の一部を担い、残りの品質まで一緒に高めていく流れになる。特に「主観的」な作業では、シンボリックシステムも必ず評価すべきで、もしシステムを訓練する必要があるなら評価は避けられない
実際には多くのテック企業がすでに生成AIをリアルタイムのチャットボット顧客対応に導入している。SonderやWealthsimpleのような例を知っている。LLMが問い合わせに答えられない場合は、会話をすぐ人間の相談員に引き継ぐ
まだあまり議論されていない点として、コンテキストウィンドウがある。人間は専門分野では事実上「ほぼ無限大」に近い文脈を扱える。モデルはより大きく多様な学習データによってある程度その限界を克服できるが、本当の解決策ではないと思う。今は人々が自分なりの文脈をプロンプトに圧縮して入れなければならず、英語のような柔軟な言語では工学というより呪文を唱えたり勘に頼ったりする感じだ。決定論的な方法ではなく、データの多くを失っているように感じる
人間は「文脈」と「重み」が分かれて固定的に区別されているわけではない。時間とともに経験や結果が私の「重み」そのものを変え続けるが、LLMはアーキテクチャ上、重みが読み取り専用なので不可能だ
人間が本当にそんな巨大なコンテキストウィンドウを持っているのかには懐疑的だ。私は複雑な問題解決の際に、人間固有の「コンテキストウィンドウ」の限界によくぶつかる。実際にそうした例があるのか気になる
私のAIツール利用経験は概ね前向きだった。休みたい時に小さな作業を任せたり、業務を整理して立ち上げたりするのに大いに役立つ。ただしコストの問題がすぐ出てくる。例えばClaude Codeを大規模コードベースで使うと1〜2時間で25ドルほどかかる。自動化されたレビューまで付けると50ドル/時まで上がる。速度、精度、コストのトレードオフがある。最近出てきたAgentたちもその三角形のどこに位置するのかまだ不明で、さまざまな実験は興味深いが、依然としてリスクがあると思う
少しシニカルに見るなら、LLMが絶えず自分自身を再プロンプトしてエラーを直す構造や、「RAGは不要！ 1mトークンのコンテキストウィンドウに全コードを全部投げ込め」というアプローチは、結局「トークン課金」のビジネスモデルにぴったり合うフレームだ
最近考えているアイデアは、複数のコミット草案を最初からAIに作らせ、その結果を人間が直接あるいは自動でフィルタリングし、手作業で仕上げる構造だ。大きな作業ほど初期の小さなブレが全体結果を壊す確率が高い。だから現在のSOTAでも、エージェントに複数案を並列で試させると手動リファクタリングの時間が減る。関連する手順については GitHubに書いたことがある
サブスクリプションサービスなのかと聞きたくなる
人間の多段階ワークフローには通常、検証チェックポイントがある。人間も99%以上正確というわけではないからだ。今後のエージェントも、出力に対する検証手順を設計し、次の段階へ進む前にこれを通過するよう学習されるだろう。あらかじめ「ここだけは99%以上の正確さが必要だ」といったリスクの事前評価もできるはずだ
Claude Codeは作業を進める前に毎回止まって、続行するかユーザーに尋ね、提案された変更内容も事前に見せてくれる。トークンの浪費や非効率な作業を防ぐのに効果的だ
多くのアプリケーションもこの構造に合わせて再設計が必要だ。私の考えでは、マイクロサービスアーキテクチャはLLMと相性がよく、再び流行すると思う
「本当の問題はAIの能力ではなく、エージェントが実際に効果的に使えるツールとフィードバックシステムを設計することだ」という点に同意する。市場がどう受け止めるか確信が持てずに様子見していたが、エージェント作りに特化したごく小さなスタートアップに参加した。5か月で懐疑から同調、そして確信へと変わった。テーマの範囲を非常に狭く定め、モデルが働くためのツーリングに集中すれば、高い完遂率を経験できた。非決定論的な性質を嫌う傾向はあるが、優れたツーリングとさらに狭いスコープさえあれば、現実的にかなり使える。ツーリング自体は難しく感じられるが、十分うまく解決できると思う。未来には楽観的だ
すべて解決可能な問題だと思う。ただし、素早くARRを確保する競争のせいで、多くのスタートアップはこうした問題に集中していない。エージェントが約束ほど役に立たないという意見にも一理あるが、実際にはエンジニアリングの問題だ。別の視点から取り組めば動くと思う（個人的にはRL寄りだ）。例えば優れた検証者(verifier)が必要だ。多くの作業は、実行することより検証することのほうが簡単だ。精度80%の並列生成物が5個あるだけでも、少なくとも1つが正しい確率は99.96%になり、検証者がそれを選べる。マルチステップの状況でも数学的に有利になる。これまでとは違うやり方のアプローチで、記事でも3〜5段階のワークフローパラダイムに触れているが、これは実際かなり合っている。今後はこういうモデルがもっと出てくるべきだ
多くの作業では、実際には検証のほうが作業そのものより難しいのではないかという議論には一理ある。特にソフトウェアQAの現場では、この論理でリストラが行われることがあり、その結果として品質が下がったと感じている。検証者は、システムや外界の可能な状態の組み合わせ数が幾何級数的に増えるため、非常に難しくなる。LLMはこうした複雑な作業環境で依存関係をモックしたり、データを事前投入したりするような反復的な雑務を代行する点では魅力的だが、検証テストに意味を持たせるには常に100%の正確さが必要という要件が付き、結局は前提条件ごとにまた検証者が必要になる。結局すべての段階が100%でなければならないなら、累積的に確率は下がる。人間はたいていケースごとに慎重にテストするだけで、すべてのケースを完全に検証しているわけではない（ホワイトボックステストのほうがブラックボックスよりはるかに一般的だ）。LLMが大量のコードを生成すると、結局作業者がコード全体を理解しなければホワイトボックス検証ができず、そうなると節約した時間はまた減ってしまう。現状ではLLMが作り、エラーも私が全部直接直さなければならないので、自信はむしろ下がり、時間も余計にかかる。状況によっては、インターフェースをLLMの予想に合わせる形で解決できるが、汎用的ではない。ソフトウェアを離れると、検証がそもそも不可能なことも多い（例: 「最も有望なゲームスタートアップ5社を選べ」のような場合は客観的検証が不可能）。そういう領域まで人間ではなく機械に無批判に任せると、収拾がつかなくなる
5回の生成が互いに独立していると仮定してよいのか気になる
その通りで、複数のエージェントが試行し、何度も繰り返し、多様な解法を適用するのは現実的に有効だ。実際、ある方法でネガティブなフィードバックを受け、別のアプローチで成功した例を経験した
1人の個人（あるいはごく少人数のチーム）が、開発、DevOps、データオペレーションなどで実運用中のAIエージェントを12個以上作ったというのは意外だ。スタートアップの失敗率を見れば、「1つ」の良い製品を作るのさえ難しいのに、12個も作ったというのは驚きだ。こちらもDefiniteのようなデータスタック+AIエージェントツールを作っているが、2年かかってようやく6か月前からまともになってきた。Definite
実際には12個の独立した製品という意味ではなく、必要に応じて職場で使う非常に具体的な目的のツールを12個作ったという意味だ。記事全体のテーマどおり、非常に単純で明確な目的にだけ集中してこそ、役に立つエージェントになる
3年間フルタイムで働きながら12個以上も作ったというのは、どこか不自然に感じる
私もエージェント/AI自動化開発が仕事だが、オープンエンドなコーディングエージェントは単に愚かな発想だ。人間による検証チェックポイント、小さな探索空間、非常に具体的な質問/プロンプト（例: このメールに請求書はあるか YES/NO）が現実的だ。完全自動のエージェントを望む気持ちはわかるが、技術はまだそこに達していない。私はコンテンツ（テキスト、画像、コード）生成には手を出さない。そういうものは結局どこかで痛い目を見るからだ
私もエージェントフレームワークとchat coding（コミュニケーションベースのコーディング）によって作業量の50%ほどを減らしている。GPTで実際の効果も感じている。ただし10回に1回は必ずエラーが起きる。LLMアーキテクチャを根本的に変えない限り、このエラー率は直らないと思う。現時点ではhypeのせいで開発者の信頼が崩れないことを願うが、将来ははるかに堅牢なシステムが出てくると確信している。実際、チームメンバーの採用も以前よりずっと少なくて済むほど生産性向上は目立っている。さまざまなテーマの学習コストも、Google検索の質の低下をLLMが補ってくれるおかげで飛躍的に下がった。自動化ワークフローの中で人間の業務の一部をLLMに担わせるOrchestration Frameworkが最も重要な構造だ。LLM自身が確信度も一緒に報告し、confidence %が低ければすぐ人間に回す。テストやガードレールさえしっかりしていれば、非中核業務から十分に人間の代替が可能だと思う。人を置き換えるというより、業務の自動化によってチーム規模を縮小するのが目標だ。例として、大規模eコマースにおける商品説明、画像検証、誤字、画像不一致など、人間がやっていた作業をLLMが処理する日が来ると確信している
概ね同意するが、そのやり方だと残るのは「ただの高価なワークフローシステム」かもしれない。昔の技術でもできたことを、わざわざLLMでやる必要があるのかは考えるべきだ
私も同意する。現状では「狭い範囲、低リスク、反復性の高い退屈な仕事」がエージェントに最適な領域だ。例としては、dev-logのMarkdown補助作業にエージェントを使った経験を ここに書いた
人間による検証がチェックポイントを作るうえで最も信頼性が高いのは事実だが、ユニットテストやシステム全体のアドホックな検証(ad-hoc validation)など、追加の手法もいくつかある
私は実際、著者は今よりも自律エージェントにもっと楽観的であるべきだと思う。今やっていることの90%は、2024年初頭には不可能だった。進歩のカーブを過小評価してはいけない
私も同感だ。関連ブログ記事もある。核心的な違いは、HITL(Human in the loop)でエラーを減らすのは正しいが、HOTL(Human out of the loop)はむしろ問題を生むという点だ