理論から現実へ：なぜAIエージェントのプロジェクトの多くが失敗するのか（そして自分もそうだった）

Dev.to / 2026/4/20

💬 オピニオンSignals & Early TrendsIdeas & Deep AnalysisTools & Practical UsageModels & Research

共有:

要点

著者は、AIエージェント作りに関するオンラインの多くのチュートリアルが楽観的すぎるとし、自身の「BRAG」プロジェクトは動く状態になるまで17回の壊れた反復を要したと述べています。
期待される「文脈の理解」や「ユーザーのニーズへの適応」といった能力が実運用では破綻しがちな点を、夢と悪夢の対比で説明しています。
開発の厳しい数値として「17件中1件が稼働（成功率5.88%）」「847時間が無駄になった」「うまくいかないAPI/LLM呼び出しに1,247ドルを費やした」「8〜12回ほど諦めかけた」といった実態を提示しています。
実際に機能したBRAGでは、文脈管理が想像以上に難しく、LLM任せではなく明示的な文脈管理システムの構築が必要だと強調しています。
成功するエージェント開発には、プロンプトやAPI呼び出しでできることの限界を見据えた現実的な期待値と、エンジニアリング上の規律が重要だという示唆が含まれています。

理論から現実へ：なぜほとんどのAIエージェント案件は失敗するのか（そして僕のもそうだった）

正直に言うと、1年前にAIエージェントシステム「BRAG」を作り始めたとき、2週間で完璧に動くようになると思っていました。ネタバレですが、できませんでした。実際に、ちゃんと動くものを手に入れるまでに、完全に壊れているバージョンを17回も作り直しました。そして残酷な真実は？オンラインで見かける「AIエージェントを作る方法」の多くは、楽観的すぎるか、現実から完全に切り離されています。

夢（ドリーム）と悪夢（ナイトメア）

そこからすべてが始まりました。私は、「文脈を理解する」「ユーザーから学ぶ」「変化するニーズに適応する」ことができるAIエージェントは簡単に作れる、という記事ばかり読んでいました。チュートリアルでは、プロンプトをいくつか投げて、API呼び出しを少し足すだけで、あとは出来上がり――つまり賢いアシスタントが手に入る、といった感じに聞こえました。

記事が言っていたこと： 「適切なプロンプトでLLMを使えば、エージェントはユーザーの意図を理解します！」

実際に起きたこと： 私の最初のエージェントは、「旅行プラン」という質問をされたときに飛行機の予約をしようとし続け、「ファイル管理」と「ドキュメント編集」を取り違え、そして全体的に、英語を理解できているのか自分に疑問を持たせるような振る舞いをしました。

現実は？現実世界で本当に動くAIエージェントを作るのは、ほとんどのチュートリアルが認めているよりずっと難しいです。17回失敗した後、あまり語られていない、いくつかの痛い真実を学びました。

AIエージェント開発の残酷な統計

砂糖をまぶすのはやめて、厳しい数字を出しましょう：

試した総プロジェクト数： 17
実際に動いたバージョン： 1（成功率 5.88%）
壊れた約束に費やした時間： 847
動かなかったAPIに使ったお金： $1,247（主に、どこにも行かなかったLLM呼び出しに）
ほぼやめかけた回数： 8（まあ、12回かもしれません）

本当に、成功率5.88%はきついです。でも、それだからこそ、動いた1つがとても満足感があるんです。94%の登山者が途中で諦めるような山を登って、たどり着けた人は特別な何かを持っている――そんな感じです。

チュートリアルと違って、実際にうまくいくこと

失敗を重ねるうちに、「本当に機能するもの」と「ただの理論上のナンセンス」を見分けるパターンが見えてきました。結論はこれです：

1. 文脈は見た目より難しい

神話： 「LLMは自然に文脈を理解する！」

現実： 明示的な文脈管理の仕組みを作る必要があります。私が動いているBRAGエージェントでは、3層の文脈システムを使っています：

class ContextManager {
    constructor() {
        this.shortTerm = new Map(); // 直近5回のやり取り
        this.longTerm = new JSONStorage('"agent-memories.json'"); // 永続的な記憶
        this.relevantContext = new Set(); // 文脈的に関連のある情報
    }

    addInteraction(userMessage, botResponse) {
        // 古いやり取りを削除
        if (this.shortTerm.size >= 5) {
            const oldest = this.shortTerm.keys().next().value;
            this.shortTerm.delete(oldest);
        }

        // 新しいやり取りを保存
        this.shortTerm.set(Date.now(), {
            user: userMessage,
            bot: botResponse,
            timestamp: new Date()
        });

        // 長期保存のための重要情報を抽出
        this.extractImportantInfo(userMessage, botResponse);
    }

    extractImportantInfo(userMessage, botResponse) {
        // ここで魔法が起きます
        // ユーザーの嗜好、パターン、重要な事実を抽出
        // ただ正直、この部分はまだ80%がアートで20%がサイエンスです
    }
}

残酷な真実？文脈管理は作業の80%を占めますが、チュートリアルはそれに5分しか割かず、「クール」な機能には2時間使います。

2. 記憶システムは「保存して取り出す」だけではない

神話： 「全部保存しておけば、AIが覚えてくれる！」

現実： 記憶には整理、劣化（減衰）、そして関連度スコアリングが必要です。私のエージェントが、6か月前の情報をまるで現在のことのように使おうとしたときに、このことを痛いほど学びました。

返却形式: {"translated": "翻訳されたHTML"}

class MemorySystem:
    def __init__(self):
        self.memories = []
        self.importance_threshold = 0.7
        self.decay_rate = 0.95  # 記憶は時間の経過で薄れていく
    def add_memory(self, content, importance=0.5):
        # 時間減衰を考慮して関連性を計算する
        age_factor = self.calculate_age_decay()
        final_importance = importance*age_factor

        if final_importance >= self.importance_threshold:
            self.memories.append({
                'content': content,
                'importance': final_importance,
                'created': time.time(),
                'last_accessed': time.time()
            })

    def calculate_age_decay(self):
        # 古い記憶ほど関連性が低くなる
        # ここが「AIはすべてを覚えてしまう」問題と戦う場所だ
        pass

3. ユーザー適応は、あなたが思っているよりずっと気味が悪い

神話: 「AIエージェントはユーザーから自動的に学習すべきだ！」

現実: あなたが「学習」しすぎると、ユーザーは気味悪がります。僕のエージェントは一度、ユーザーの勤務スケジュールを学習してしまい、予定のない提案をし始めました。ユーザーは、それはストーキングだと思ったんです。

学びは？ユーザー適応には、明確な許可とはっきりした境界線が必要です。それは賢くなることではなく、気味悪がらせずに役に立つことです。

実際に機能するアーキテクチャ

17回の試行のあと、機能するアーキテクチャを見つけました。見た目はきれいではありませんが、ちゃんと動きます：

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   入力レイヤー   │───▶│ コンテキスト・エンジン  │───▶│ レスポンス生成 │
│                 │    │                 │    │                 │
│ - ユーザー入力   │    │ - 短期           │    │ - LLM呼び出し  │
│ - APIイベント   │    │ - 長期           │    │ - 出力の形式化 │
│ - システムイベント │    │ - 関連性         │    │ - 検証          │
└─────────────────┘    └─────────────────┘    └─────────────────┘
                                │
                                ▼
                       ┌─────────────────┐
                       │ メモリーシステム  │
                       │                 │
                       │ - 永続         │
                       │ - 減衰ロジック   │
                       │ - 重要度       │
                       └─────────────────┘

重要な洞察は？主役はLLMではなくコンテキスト・エンジンです。LLMは、正しく動かすには完璧なコンテキストが必要な“ただの”生成器にすぎません。

「学習」についての残酷な真実

ほとんどのチュートリアルは「学習」を、魔法のようなプロセスだと語ります。実際には、こういう意味です：

パターン認識: 「理解」ではなく、ユーザー行動の統計的なパターンを見つけること
適応: 「正しい」ことに合わせるのではなく、うまくいくことに基づいてレスポンス用のテンプレートを変えること
メモリー減衰: すべてを覚えていると気味悪く見えるので、意図的に忘れること

僕のエージェントは、「『これ直して』と言うユーザーは、機能要望ではなくバグ修正を求めている」ことを「学習」しました。これは知能ではなく、パターンマッチングです。でも、機能します。

誰も話さないメリットとデメリット

AIエージェントとして働くことのメリット:

実際に時間を節約する: 17回の失敗バージョンを乗り越えると
動くと魔法みたいに感じる: 「すごい」という要素は本物
複雑なマルチステップ作業を扱える: 単純なチャットボットと違って
個々のユーザーに適応する: 本当に役立つパーソナライズ

残酷なデメリット:

継続的なメンテナンスが必要: 現実世界は変わり続け、あなたのエージェントも適応しないといけない
運用コストが高い: LLM呼び出しはすぐに積み上がる
動きすぎると気味悪い: あなたが知りすぎると、ユーザーは疑い始める
メンテナンスが仕事の90%: 動き続ける状態を保つことに比べれば、作るのは簡単です
セットアップと現実のギャップ
- セットアップ（チュートリアルで見せられるもの）: 2時間のコーディング
- 現実: 847時間のデバッグ、調整、想定外ケースの修正
コストの現実
- 期待: 「ただAPI呼び出し代を払うだけ」
- 現実: 1,247ドル後に気づく。実際のコストはお金ではなく、時間とメンタルの方だと
学習という神話
- 約束: 「AIエージェントは学習して適応する」
- 現実: ほとんどの「学習」は、ただのパターンマッチングに過ぎない。名前がかっこいいだけ

真実の瞬間：実際にうまくいったとき

16回失敗したあと、僕はもうやめようと思っていました。でもある夜、午前2時。まだ別の壊れたバージョンをデバッグしている最中に、何かがパチッと腑に落ちたんです。僕のエージェントは、次を必要とする複雑なマルチステップの依頼を処理できました：

ユーザーの苛立ちを理解する（言葉だけではない）
3週間前の関連する記憶にアクセスする
複雑なタスクを扱いやすい手順に分解する
ユーザーの感情状態に基づいてレスポンスを適応させる

ユーザーはこう言いました。「これが、本当に僕のことを分かってくれる最初のAIアシスタントです。」

その瞬間で、847時間すべてが報われました。でも残酷な真実は？誰も話さない16回の失敗の上に、その成功は築かれていたんです。

返却形式: {"translated": "翻訳されたHTML"}

「簡単」なAIエージェントの本当のコスト

「週末でAIエージェントを作ろう」みたいな記事を読んでいるとき、彼らが教えてくれないのはこういうことです：

メンタルへの負荷： 絶えず「なぜうまくいかないんだ？」というイライラ
機会費用： 他のプロジェクトに使えたはずの時間
技術的負債： 近道としてやってしまったことが、後から必ず牙をむく
学習曲線： 誰もが「簡単だ」と言うけれど、実際は簡単ではない

私に誰かが先に教えてくれていたらよかったこと

小さく始める： 汎用のAIエージェントを作ろうとしないでください。現実の「1つの本当の課題」を解決する、具体的なものを作りましょう。
文脈管理に集中する： 勝負の80%はLLM呼び出しではなく、文脈管理です。
失敗を受け入れる： あなたは失敗します。しかもたくさん。これは普通のことです。
ミスの予算を見込む： 想像しているよりも、もっとお金と時間を使うことになります。
実際のユーザーと話す： 早く、そして頻繁に。あなたにとって「賢い」ように見えることが、他の人には混乱を招く可能性があります。

これからの道のり：BRAGは次に何をするのか

動くバージョンができた今、いよいよ本当の仕事が始まります：

よりニュアンスのある文脈理解の追加
記憶の整理と検索の改善
パーソナライズのためのユーザー許可管理
コスト最適化（あのLLM呼び出し、安くはありません）
現実が投げてくるイレギュラー（エッジケース）への対応

ところで、あなたの経験は？

ここがポイントです。17回も失敗したAIエージェント開発を経験したのは、私だけではないはずです。あなたはどうでしたか？

質問です：

実際に動くAIエージェントを作ったことはありますか？ 何回失敗（うまくいかなかった試行）が必要でしたか？
誰も語っていない、AIエージェント開発で一番の驚きは何ですか？
「学習」できる能力は、チュートリアルが見せるほど魔法のようだと思いますか？それとも、主にパターンマッチングに近いものだと思いますか？
17回の試行が必要になるかもしれないと分かっていても、もう一度挑戦しますか？それとも、その投資量は大きすぎますか？

正直に言うと、あなたの苦戦談（ウォーストーリー）をぜひ聞きたいです。なぜなら、私が学んだことが1つあるとすれば、私たちはみんな壊れたバージョンを1つずつ作りながら、これを一緒に理解しようとしているだけだ、ということだからです。

あなたはAIエージェントの旅の中で何を発見しましたか？コメント欄は開いています—あなたの考え、失敗、成功を教えてください。私の5.88%という成功率が普通なのか、それとも私は単にこの手のことが特別に下手なだけなのか、気になっています！

Black Hat USA

AI Business

ブラックハット・アジア