AIエージェントを構築しながらも、私はそれに逆らって賭けています

309日前原文(utkarshkanwat.com)

概要

2025年は「AIエージェントの年」と言われているが、現場経験から見ると過度な期待が多い現実。
実際にプロダクションで稼働するエージェントシステムを構築した経験から、現状の課題と限界を指摘。
信頼性、コスト、ツール設計、現実世界との統合が最大の壁。
成功するパターンは「限定された範囲」「人間の確認」「伝統的なソフトウェア工学との融合」。
本当に価値あるAIエージェントは、2025年の流行とは異なる形で進化する可能性。

AIエージェントの現実と幻想

2025年は AIエージェント が仕事を変革すると騒がれている現状。
実際に 12種類以上 のプロダクションエージェントを開発・運用した実体験。
開発エージェント：自然言語からReactコンポーネント生成、レガシーコードのリファクタリング、APIドキュメント自動生成、仕様→関数の自動実装。
データ＆インフラエージェント：複雑なDB操作やマイグレーション、マルチクラウド対応のDevOps自動化。
品質＆プロセスエージェント：lint自動修正、テスト自動生成、コードレビュー、詳細なプルリク説明文作成。
これらのシステムは 実際に価値を生み出し、日々の手作業を大幅に削減。
しかし「2025年はエージェントの年」という主張には 重要な現実が抜けている と指摘。

AIエージェントの「3つの厳しい現実」

マルチステップワークフローでは エラー率が指数関数的に増加。
- 1ステップ95%信頼性→20ステップで36%成功率。
- 本番運用には99.9%以上の信頼性が必要。
コンテキストウィンドウ によるトークンコストの爆発。
- 長い会話ほどコストが二次曲線的に増加。
- 100ターンの会話で1回$50～$100のコストが発生。
本当の課題はAIの能力ではなく、「 エージェントが効果的に使えるツールとフィードバック設計」。

数学的現実：エラーの複利

各ステップ95%成功でも、5ステップで77%、10ステップで59%、20ステップで36%。
仮に99%でも20ステップで82%。
これは プロンプト設計やモデル性能の問題ではなく、数学的な限界。
成功するDevOpsエージェントは、3～5個の独立した操作＋ロールバック＋人間確認の構成。
成功するエージェントの共通点は「 限定された文脈、検証可能な操作、重要な分岐点での人間介入」。

トークンコストの現実：経済性の壁

会話型エージェントは 過去全履歴を毎回処理、コストが二次曲線的に増加。
50ターン超えると 1回の応答で数ドル 消費、価値を超えるコストに。
ステートレスなエージェント （例：仕様→関数生成）はコスト効率が高い。
実際に運用で成功しているエージェントは「 会話型でなく、特定の課題を効率的に解決するツール」。

ツール設計の壁：AIと人間の違い

ツール呼び出し自体は精度が高くなっているが、 ツール設計が最大の課題。
- 適切なフィードバック設計が必須、情報過多でもコンテキスト不足でも失敗。
- 例：DBクエリの結果は「成功・件数・サンプル」だけで十分。
「API接続すれば自動でエージェントが解決」系のサービスは AIインターフェース設計が不十分。
実際の作業の70%はツール設計とエラー対応、AIは30%程度。
成功するエージェントは「 構造化されたフィードバック、効率的なコンテキスト管理、部分失敗時の回復設計」が重要。

統合の現実：現実世界とのギャップ

エンタープライズ環境は クリーンなAPIではなく、レガシーや不安定な要素が多い。
- 認証フローの変化、時間帯で変わるレートリミット、監査要件など。
成功するDBエージェントは「接続プール、トランザクション管理、監査ログ」など、 AI以外の伝統的システム設計が大半。
「自律エージェントが全て統合」と謳うサービスは 現実の複雑さを過小評価。

成功するエージェントのパターン

UI生成エージェント： 人間が最終確認 を行うことで品質担保。
DBエージェント： 破壊的操作は必ず人間確認、データ整合性を維持。
関数生成エージェント： 明確な入力・出力範囲 で副作用なし、管理容易。
DevOps自動化： インフラコード生成→人間がレビュー・ロールバック可能 な仕組み。
CI/CDエージェント： 各ステージに明確な成功基準とロールバック機構。
AIは複雑さを処理し、人間とソフトウェア工学が信頼性を担保。

2025年に苦戦する組織・勝つ組織

完全自律エージェント を掲げるスタートアップは、経済性・信頼性の壁で苦戦。
既存製品に「AIエージェント」を単純追加したエンタープライズは、 深い統合ができず停滞。
勝者は「 限定的で専門領域に特化、高度なAI＋人間のコントロール」を両立するチーム。
「全自動」より「 極めて有能なアシスタント＋明確な境界線」が現実的な解。

正しいAIエージェント開発の原則

明確な境界線の定義 ：エージェントの役割と人間/決定論的システムへの委譲ポイント。
失敗前提の設計 ：20～40%の失敗をどう処理するか、ロールバック設計。
経済性の検証 ：1回あたりのコスト、利用拡大時のスケーラビリティ。
ステートレス重視 ：信頼性を優先、過度な自律性より一貫性を重視。
堅牢な基盤 ：AIは「意図理解・生成」に活用、 実行・エラー処理・状態管理は伝統的なソフトウェア工学 に依拠。

現場からの本当の教訓

「デモで動く」から「スケールして動く」までの ギャップは非常に大きい。
エージェントの信頼性・コスト最適化・統合の課題は 未解決のエンジニアリング問題。
実際に運用している経験や知見の共有が、業界全体の進化を加速。
導入・運用・設計で悩む場合は 経験者への相談が有効。
本当に価値あるAIエージェントは、2025年の流行とは異なる形で現れる 可能性。

（連絡先等は省略）

Hackerたちの意見

人間のマルチステップワークフローには、次に進む前に作業を確認するチェックポイントがあることが多いよね。人間も99%以上の精度を持ってるわけじゃないし。未来のエージェントは、こうしたチェックを出力に組み込むトレーニングを受けるんじゃないかな。次に進む前にチェックに対して検証する感じで。もしかしたら、「この部分は重要だから、99%正確でないと次に進めない」みたいなリスク評価も含まれるかもね。

└

それがClaude Codeのやり方なんだよね。常に立ち止まって、進むかどうかを聞いてくるし、実装する前に提案された変更を見せてくれる。トークンの無駄遣いや「悪い」仕事を避けるのに役立つよ。

└

それに合わせて多くのアプリケーションを再設計しなきゃいけないね。俺の予想では、マイクロサービスアーキテクチャが再評価されると思う。LLMと相性がいいからね。

リンクは俺にはうまくいかないけど、LLMを使ってる身としてはエージェントには懐疑的だよ。エージェントは大きなエンジニアリング組織の人たちの心を掴んでるけど、彼らの目標は「GenAI」に関すること以外は全く分からない。もう1年以上、次のMSFTやAlphabetのフレームワークが彼らの問題を解決するって約束しながらエージェントに取り組んでるけど、実際に何を解決してるのかは分からない。エージェントが何かを解決したのを見たことがないけど、なぜか「何でも送れるエージェントがあれば会社の問題が全部解決する」っていう考えがあるみたい。LLMには面白いアプリケーションがたくさんあるけど、エージェントにはまだ興味を持ててない。なんでこんなに大企業が時間をかけてるのかも理解できない。商業ツールやオープンソースプロジェクトの前にコードを解読することはないだろうし。エージェントで遊んでる時間を使って、もっと面白いアプリケーションを作れたはずだと思う。中には技術的にはエージェントかもしれないけど、すべてのユースケースを解決しようとするほどの焦点や努力は必要ないものもある。編集：再読してみて、ツールコールチェーンのようなものには場所があると思うけど、実際に話した人たちが「すべてに対応するもの」を作ろうとしてるのが気になる。

└

リンクは俺にはうまくいってるよ — もしかしたら30分前はダメだったのかな？（Safari、MacOS）

└

エージェントが何のためにあるのか全く分からない。自分の無知かもしれないけど。それはさておき、LLMをしばらく使っててすごく助かってる。何かが欠けてるとは感じてないし、エージェントが何をもたらすのかも分からない。知ってる？

└

<< なんでこんなに多くの大企業がそれに時間をかけてるのかも理解できない。商業ツールやオープンソースプロジェクトの前にコードを解読することはないだろうし。FOMOと高い「アップサイド」の可能性が混ざってると思う。高価な「人間の要素」を最小限に（理想的には排除）できるかもしれないからね。特定の世界モデルを描こうとしてるだけなんだ。<< エージェントで遊んでる時間を使って、もっと面白いアプリケーションを作れたはずだと思う。中には技術的にはエージェントかもしれないけど、すべてのユースケースを解決しようとするほどの焦点や努力は必要ないものもある。まさに同意だよ。俺たちはカスタムAIツールを手に入れたけど、業界特有の制約が全部入ってて、実際にはあまり意味がないし、低コンテキストでイライラするし、普通より遅い。なぜなら、今は「バイアス」を含むいくつかの承認レイヤーを通過しなきゃいけないから。しかも、委員会は価値のあるものに影響を与えないようなプロセスの小さな変更で言い争ってる。おかしいよね。

└

一般的に、みんなが解決策について話してて、問題について話さないなら、それはバブルにいるサインだと思う。私の唯一の問題は、タイピングが遅くて面倒だってこと。いつも言ってるけど、もっと少ないタイピングで済む方法があれば使いたい。だから、ここ数年はタブ補完やリファクタリングツールを使ってるんだ。思考をもっと早くコンピュータに入力できるのはちょっとワクワクするけど、自分の代わりに考えてもらうのは、私には問題じゃない。情報を読み取って吸収するのも、また問題じゃない。こういうのは、問題がないところに解決策を当てはめようとしてるだけだと思う。

└

彼らの目標が何かは全く分からないけど、君（人間）を解雇して、コストを下げて、利益を増やすことだろうね。

開発、DevOps、データオペレーションの分野で12以上のプロダクションAIエージェントシステムを構築してきた。一つの良い製品を作るのは難しい（スタートアップの失敗率を見てみて）。君は12個作れなかったのに（ソロ開発者のように見えるのに）驚いてるの？俺たちは小さなチームでDefinite[0]に2年間取り組んできて、過去6ヶ月でやっと本当に良くなり始めた。0 - データスタック + AIエージェント: https://www.definite.app/

└

彼らはフルタイムの仕事をしながら、過去3年間で12以上の製品を作ったみたいだけど、なんかおかしい気がする…

└

彼は12個の独立した販売可能な製品を作ったとは言ってないよ。彼は、自分の仕事で必要な12個のツールを作ったって言ってる。それらはおそらくかなりシンプルで、特定のタスクをこなすためのものだ。記事全体が、使えるものを作るにはシンプルに保つ必要があるって言ってるからね。

私もエージェントやAIの自動化を仕事にしてるけど、コーディングエージェントやオープンエンドなものを作るのはただの無駄だと思う。人間が確認したチェックポイントを設けて、小さな検索範囲と非常に具体的な質問やプロンプト（このメールに請求書は含まれてる？はい/いいえ）を持つのがベストだよ。完全に知的で自動的なエージェントが欲しいのは分かるけど、技術がそこまで来てるわけじゃない。私はコンテンツ（テキスト、画像、コード）を生成するようなことには関わってない。それはただの無駄で、長い目で見れば痛い目に遭うよ。

└

一般的には同意するけど、そういうアプローチの結果として生まれるシステムは「ただの」高価なワークフローシステムになりがちで、古い技術でもできることだよね… ここで本当に必要なLLMはどこにあるの？

└

人間の検証は確かにチェックポイントを導入する最も信頼できる方法だけど、他にもあるよ。ユニットテストを実行したり、システム全体のアドホック検証をしたりとかね。

└

「俺もエージェントフレームワークを作ってて、チャットコーディング（バイブコーディングじゃなくて）を使って作業を生成してるんだけど、GPTに聞くだけで簡単に時間を50%節約できたよ。でも、10回に1回くらいの割合でミスが出るし、LLMのアーキテクチャを大きく変えない限り、これが直るとは思えない。将来的には、今のハイプサイクルが開発者との信頼を壊さなければ、もっと堅牢なシステムができると確信してる。でも、実際の影響は大きいよ。今雇うなら、開発者の生産性が上がってるのがはっきり見えるから、雇う人数はかなり減ると思う。ほとんどのトピックの学習曲線も大幅に短縮されて、Googleの検索結果の質の低下がLLMで補われてる。俺が保証できるのは、自動化とよりスムーズなワークフローだね。普通の人間のタスクが、ワークフローオーケストレーションフレームワーク内でLLMによって強化される感じ。LLMはタスクの結果と一緒に自信のパーセントを返して、理想的でない自信のパーセントの場合は、人間に頼ることができる。正しくテストして、ガードレールを設ければ、LLMがいくつかの重要でないタスクで人間のエージェントを置き換える未来が見えるよ。ポイントは人間を置き換えることじゃなくて、ほとんどの作業を自動化してチームの規模を減らすこと。例えば、大手のeコマース企業は、製品説明や画像を手動で確認するために何百人もの従業員がいるけど、今後はLLMがその仕事をするようになると思う。」

└

「そうだね、今のエージェントにとっては、焦点を絞ったスコープ + 低リスク + 高い作業的なタスクがベストなポイントだと思う。俺はその一つのタスクについてちょっと書いたよ。エージェントにマークダウンの開発ログを補完させるってやつね。ここに書いてるよ: https://github.com/sutt/agro/blob/master/docs/case-studies/a...」

「本当の課題はAIの能力ではなく、エージェントが実際に効果的に使えるツールやフィードバックシステムを設計することだ。」 - この部分には同意する。私はAIのことをしばらく様子見してたけど、最近、小さなスタートアップに参加してエージェントを作ることに集中してる。5ヶ月で懐疑的から興味を持つようになり、「ああ、これはたぶん正しい」と思うようになった。つまり、テーマを非常にうまくスコープして、モデルがそのタスクをこなすために必要なツールに集中すれば、高い完了率が得られる。モデルの非決定的な性質に対する抵抗感はあるけど、実際には本当に優れたツールを提供して、狭くスコープを絞れば、一般的には受け入れられるレベルになる。このブログ記事はツール部分が難しいように見えるけど、実際にはそんなに難しくない。これがどうなるかは見てみないと分からないけど、楽観的でいるよ。

私のAIツールの使用は、仕事でプラスの経験になってる。小さなタスクを引き受けてくれたり、整理したり、勢いをつけたりしてくれるし、全体的に良いサポートをしてくれる。でも、もしそれが私の仕事をできるとしても、コストがすぐに積み上がる。Claude Codeは大きなコードベースで簡単に$25/1-2時間かかるし、タスクを維持して修正を提供できる前提で、プラスのペースで進んでる。修正を自動化すると、$50/時間か、スピード、正確性、コストのトレードオフになる。いつもと同じだね。エージェントに関しては、その三角形が今はあまり定量化されてないから、こういう調査は面白いけどリスクもある。

└

サブスクリプション？

└

「今考えてるアイデアの一つは、最初にAI生成のコミットのラフドラフトをいくつか作って、それを手動でフィルタリングしたり、自動化で手動の修正を加えるってこと。『どう道が道に続くかを知っている』って感じで、タスクが大きくなるほど、早い段階での逸脱が全体の解決策の有効性を台無しにする可能性が高くなる。だから、今の最先端技術でも、並行していくつかの異なる解決策を生成できるエージェントがいれば、手動でのリファクタリングの時間を減らせるんだ。このプロセスについてちょっと書いたよ: https://github.com/sutt/agro/blob/master/docs/case-studies/a...」

とても良い記事だね。数学的な信頼性についてのポイントは興味深い。一般的には同意するけど、人間は100%信頼できるわけじゃないし、99%でもないから、どうやってLinuxカーネルや火星探査機をAIなしで作り上げたんだろう？明らかに、何らかの目標に基づいた自己修正メカニズムがあるよね。そのあたりのAIに関する研究があるのかな？

└

明らかに、私たちには目標に基づいた自己修正メカニズムがあるよね。人間は色々試して学んで、改善していく。LLM（大規模言語モデル）はまだその「学ぶ」って部分ができてない。エラーメッセージをプロンプトにフィードバックすることはできるけど、学習が重み（ウェイト）に加わるわけじゃないから、経験を積んでも知識が増えていかないんだよね。AGI（汎用人工知能）を達成するためには、まだいくつかの理論的なブレークスルーが必要だと思う。その一つが「アクティブラーニング」みたいなやつだね。

└

人間は物事がどう動くかの理論を作るけど、LLMはそうじゃない。理論は決定論的で象徴的だよね。例えば、チューリングマシンは計算の理論、ユークリッド幾何学は空間の理論、ニュートン力学は運動の理論。Linuxカーネルのようなソフトウェアアプリケーションでも、リーナスの頭の中にはオペレーティングシステムがどうあるべきか、どう機能するべきかという理論があったはず。理論は100%正しい予測を提供するけど、その理論自体が世界を正確にモデル化しているわけではない。理論と現実の応用との間のフィードバックが、理論の反復を引き起こすんだ。ニュートン力学から相対性理論へ、ユークリッド幾何学から曲がった空間の幾何学へ。要するに、LLMはこれらからはまだまだ遠い。LLMに対して公平に言うと、平均的な人間も理論を作ってるわけじゃないし、理論を作るには天才が必要だよね（ニュートンやチューリングなど）。平均的な人間はSNSでミームを交換してるだけだ。

└

「人間は100%信頼できるわけじゃないけど、予測を検証するための100%信頼できるツールを作ることはできるよ。」

ここで触れられてないけど、コンテキストウィンドウについても言いたいことがある。人間は「無限」ではないけど、特定の問題を解決するためのコンテキストウィンドウはかなり広いよね。モデルは大きくて多様なトレーニングセットを持つことでコンテキストウィンドウの制限を克服できることが多いけど、それでもコンテキストウィンドウの問題を解決するわけじゃない。確かに、コンテキストウィンドウは時間とともに増えていくし、多くの目的には十分だけど、今のパラダイムでは、自分の個人的なコンテキストをプロンプトに圧縮しないと意味のある結果が出せないんだよね。英語みたいに柔軟な言語だと、これはエンジニアリングというより呪文や推測みたいに感じる。決定論を飛ばすことで、すごく大事なものを失ってる気がする。

└

人間は「コンテキスト」と「ウェイト」に固定的に分かれてるわけじゃない、少なくとも非自明な時間スパンではね。良くも悪くも、私たちが見るものやすることは全て「ウェイト」を変えてしまう。これは現在のLLMにはできないことで、ウェイトは読み取り専用だからね。

エラー率はマルチステップのワークフローで指数関数的に増加する。ステップごとの信頼性が95%だと、20ステップでの成功率は36%になる。生産には99.9%以上が必要だ。でも、これはエージェントの重要な特徴を見落としてる。彼らはリンターやビルドログ、テスト実行、さらにはスクリーンショットからフィードバックを受け取るんだ。そして、そのフィードバックを自分で集める。つまり、途中でいくつかのミスを修正できるってこと。自動フィードバックをどれだけうまく集められるかによって、数学的な結果が変わるんだ。

「信頼性とステップの関係についての『数学』は、ここで説明されているのとは違う結果になると思う。現実世界から新しい事実を得ることで、最終的な状態の信頼性が向上するはずだから。今までに、エージェントシステムが時々その行動を生み出すのを見てきたよね（例えば、テストに失敗するとClaudeのコードが正しくリファクタリングされる）。この方程式の一つの項が現在どれだけ早く増加するか、あるいはどんな状況でそうなるかは良い質問だけど、エージェントの能力を常に欠陥があるものとして、長期的なタスク実行が不可能だと考えるのは正しくない。人間も欠陥があって、正しい答えを得るためには長い時間をかけて多くのタスクを考える必要があるし、タスク実行中に心の外の世界とやり取りしてフィードバックを得ることで、最終的に正しい答えが出る確率が上がるんだ。今のところエージェントの数学はあまり良くないと思うけど、もし幻覚を減らしたり、現実世界のフィードバックの強さや頻度を上げることができれば、これがすぐに違った結果になるかもしれない。少なくとも「もうそこにいる」っていう例はいくつかあるよ。」

ハクソク