Skip to Content
Docs07. ケーススタディケーススタディ: 撤退したプロジェクト(PoC 死とコスト爆発)
中級ai-agentpocroi更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ケーススタディ: 撤退したプロジェクト(PoC 死とコスト爆発)

注記: 本記事は、本ライブラリの設計判断を具体化した**架空の事例(構成事例)**です。組織・数値・撤退までの経緯は説明のための設定であり、実案件の調査結果や失敗率の実証ではありません。「うまくいかなかった判断」から学ぶための教材です。

この記事の目的

華々しいデモから始まり、パイロットで品質が出ず、コスト試算が崩れ、撤退を決めたプロジェクトを追います。デモの罠・成功基準を緩める誘惑・サンクコストと撤退基準・撤退の実務を、「撤退は失敗ではなく組織学習」という観点から持ち帰れる状態を目指します。成功事例だけでは見えない、やめる判断の実務を扱います。

対象読者

前提知識

本文

概要: 何をやろうとして、なぜやめたか

題材は、専門性の高い問い合わせ対応(複雑な製品仕様に関する社外からの照会)を Agent で自動化する構想でした。経営の期待が大きく、デモは高く評価されました。しかし本番に近づけるほど品質が出ず、コストが想定を超え、半年で撤退を決めました。この事例は、その意思決定を誠実に振り返るものです。撤退は残念な結果ですが、やめる判断を正しくできたこと自体は成功でした。

詳細: 発端 — デモの罠

最初のデモは印象的でした。難しい質問にすらすら答え、経営は「これはいける」と判断しました。ここに最初の罠がありました。

  • 選ばれた入力: デモで使った質問は、担当者が事前に選んだ「答えられるもの」でした。実際の問い合わせは、曖昧・複合的・前提が抜けたものが多く、デモの成功率とはかけ離れていました
  • 選別したデモは代表的な評価ではない: このデモは「うまくいく例が存在する」ことを示すだけで、実入力全体での成功率は測っていません。この区別を曖昧にしたまま、本番の期待値が跳ね上がりました(よくあるアンチパターン集)

詳細: パイロット — 品質が出ない

本物の問い合わせでパイロットを始めると、品質の壁にぶつかりました。

  • 正答率が要求水準に届かない: 専門的な照会では、もっともらしいが微妙に誤った回答が一定割合で出ました。この領域は誤答の失敗コストが高く、「8 割正解」では使えませんでした。残り 2 割の誤りを人が全部チェックするなら、自動化の意味が薄れます
  • 知識源が整っていなかった: 回答の根拠となる製品仕様が、古い・散在・矛盾していました。検索を改善しても、知識源の品質が回答の上限を決めていました。これは着手前に見抜くべき前提でした(ユースケース発見と要件定義)

詳細: 崩れる試算 — 成功基準を緩める誘惑

品質が出ないと、次に起きたのが成功基準を後から緩める動きでした。

  • ゴールポストを動かす: 「正答率 95%」の目標が達成できないと、「難しい質問は人にエスカレーションするから 80% でよい」と基準が下がりました。しかしエスカレーション率が高いと、そもそもの省力化効果が消えます。基準を緩めて「成功」に見せかけることは、判断を誤らせます(ROI とビジネスケース)
  • コストが想定を超える: 精度を上げるための試行(より大きなモデル・多段検証・人手レビュー)でトークンと工数が膨らみ、削減できる人件費より運用コストが上回る試算になりました。費用対効果が反転したのです

詳細: 撤退の判断 — サンクコストに抗う

ここで最大の分岐が来ました。「ここまでやったのだから」というサンクコストの引力です。

  • 撤退基準に立ち返る: 幸い、着手時に「パイロットで正答率と費用対効果の水準に届かなければ撤退する」という基準を決めていました。基準に照らすと、届いていませんでした。すでに使った費用は判断に含めない——これから追加で使う費用と得られる価値だけで判断する、というサンクコストの原則に立ち返りました
  • 延命の誘惑を退ける: 「もう少し予算を足せば」という延命案もありましたが、品質の壁が知識源の構造問題に根ざしており、追加投資で解ける見込みが薄いと判断しました。撤退を決めました

詳細: 撤退の実務 — 何を残すか

撤退は「終わり」ではなく、資産を回収して次に活かす工程として実施しました。

  • 利害関係者への説明: 経営・現場・関係部署に、なぜ撤退するか(基準・試算・根拠)を誠実に説明しました。曖昧にごまかすより、判断根拠を明示するほうが信頼を保てます(エージェントの責任と説明責任)
  • 残る資産: 作った評価セット・知識源の棚卸し結果・問い合わせの分類は残りました。特に「知識源が整っていない」という発見は、別プロジェクト(知識源の整備)の起点になりました。学びと評価資産は撤退後も価値を持ちます
  • 撤退 = 失敗ではない: 損失を最小で止め、次に活かせる形で終えたことは、ずるずる続けて大きく損なうより良い結果でした。組織として「やめる判断ができる」ことは、健全さの証でした

設計判断: この事例の教訓

  1. デモと実力を区別する — 選ばれた入力の成功例は、本番の入力分布を代表するとは限りません。本番の成功率は別の評価で測ります
  2. 失敗コストの高い領域は基準を高く保つ — 誤答が高くつく領域で、後から成功基準を緩めません
  3. 知識源の品質を着手前に見抜く — 検索は知識源の品質を超えられません。整っていない知識源は前提の欠落です
  4. 撤退基準を先に決め、サンクコストに抗う — これから得られる価値で判断し、使った費用は含めません
  5. 撤退を資産回収の工程にする — 評価セット・学びは残します。やめる判断ができることは、組織の健全さの表れです

実務での注意点

アンチパターン

  • デモの成功を本番の見込みとして経営に伝える → 選別された事例を一般化し、見込みを過大評価する → デモの選定条件を明示し、本番を代表する入力分布で見込みを評価する
  • 品質が出ないとき成功基準を緩める → 「成功」に見せかけて判断を誤る → 基準は着手時に固定し、達成できないなら撤退を検討する
  • 知識源の整備を後回しにして検索を改善し続ける → 上限が知識源で決まるため報われない → 着手前に知識源の品質を評価する
  • サンクコストを理由に延命する → 損失が拡大する → これから得られる価値と追加費用だけで判断する
  • 撤退を隠すように終える → 学びも信頼も失う → 判断根拠を説明し、評価セット・学びを資産として残す
  • 架空事例の数値(95%・80%・2 割等)を基準値として引用する → これらは物語のための例示で実測値ではない → 自案件の許容水準・撤退基準は自分のデータで定める
  • 架空事例の「撤退が正解」を一般則と読む → 続けるべきプロジェクトもある → 撤退基準という判断の型を持ち帰り、自案件で判断する

チェックリスト

  • デモの成功を、本番の期待値の根拠にしていないか
  • 失敗コストの高い領域で、必要な正答率の水準を高く保っているか
  • 着手前に知識源の品質(鮮度・網羅・矛盾)を評価したか
  • 撤退基準(品質・費用対効果の閾値)を着手時に決めているか
  • 判断からサンクコストを除外し、これからの価値で決めているか
  • 撤退時に、利害関係者への説明と資産(評価セット・学び)の回収を計画したか

関連トピック

参考資料

外部の実証事例として引用する記事ではありません。架空の設定と撤退判断は、次のライブラリ内記事を題材にしています。

TODO・未確認事項

なし

ケーススタディ: データ分析 Agent(もっともらしい誤りとの戦い)セクション概要