7〜8割動いていたAIエージェント基盤を捨てた — 「引き継げない」という技術的負債

AI導入の記事は、うまくいった話がほとんどです。ただ、実際にご相談をいただくお客様の関心は「なぜPoCが本番にならないのか」にあります。

そこで、自社の失敗から書きます。7〜8割動いていたものを捨てた話です。

何を作っていたか

自社のバックオフィス業務をAIエージェントで自動化する基盤を、Amazon Bedrock AgentCore の上に構築していました。複数の業務をここに載せていく前提の、土台という位置づけです。

ある業務領域は7〜8割が動作するところまで進んでいました。デモもできる。触れば動く。

何が起きたか

ここで重要なのは、技術的に失敗したのではないということです。動いていました。失敗したのは体制との適合です。

何を基準に捨てたか

動作率で見れば、作り直す必要はありませんでした。7〜8割です。あと少しに見える。

実際に基準にしたのは「動くか」ではなく「引き継げるか」でした。

# 判断に使った基準
動作率                : 7〜8割          ← 十分だった
引き継ぎ試行          : 2回とも難航
ランニングコスト      : この用途にはオーバースペック
特定の人しか触れない  : はい

→ 動くかどうかではなく、自分たちの体制で維持できるかで決める
→ 7〜8割動いていた実装を再設計する

動いているものであっても、特定の人しか触れない状態が続くなら、業務の基盤としては持続しない。

社内業務の基盤は、一度作って終わりではありません。何年も動かし続けるものです。そこに「この人が抜けたら止まる」という条件を残したまま進めるのは、単に先送りでした。

どう作り替えたか

重厚な基盤を前提にすると、機能を1つ足すたびに構築の難易度と引き継ぎの難易度も一緒に上がります。まず無理なく運用できる形に戻して、そこから必要な機能を積む順番にしました。

関連して、社内の小さいAIアプリについては、管理不要のクラウド（Vercel + Supabase）で組む案も出ています。この構成ならコストは月500〜1000円程度、保守はモデルの廃止通知が来たときだけです。すべての業務を1つの重厚な基盤に載せるという発想自体を捨て、規模と重要度で構成そのものを分けることにしました。

どこまで作るかを、先に数字で決める

そもそも「どこまで作るか」を決めていないと、この種の作り直しは起きやすくなります。社内では現在、こう決めています。

# 業務改善にかけていい開発工数
対象業務の工数   = 15時間 / 月
回収したい期間   = 9ヶ月
────────────────────────────────
かけていい工数   = 135時間   ← これを超える機能は作らない

乱暴な計算です。ただ、この一行があると会議の性質が変わります。「あったら便利ですよね」で始まった議論が、「それは残り何時間の枠に入りますか」で終わる。

効くのは諦める判断がしやすくなることです。枠がないと「できない」と言うのに勇気が要ります。枠があれば「今回の枠には入らないので次回」と言える。担当者を守る仕組みでもあります。

一般化できること

技術的にできることと、その組織で維持できることは別です。当たり前のようですが、動くものが目の前にあると判断が曇ります。7〜8割動いていると、なおさらです。

だからいま、AI導入のご相談を受けたときに弊社が最初に伺うのは「誰が運用しますか」になりました。