古いシステムにAIを足すとき、いちばん壊れやすいのは「AIそのもの」ではなく、その前後にある既存の仕組みだ――この記事は、そんな現実をかなり生々しく教えてくれます。
DEV Communityの元記事では、2014年から動いているローン申請プラットフォームにLLMを組み込んだチームが、どこでつまずいたのかを順番に振り返っています。読んでいて「そりゃそうなるよね…」と何度も思いました。デモではうまくいくのに、本番では別世界。AI導入あるあるの、かなり本質的な話です。
元記事の舞台は、2014年から動いているフィンテック系のローン申請プラットフォームです。
Node.js の backend と Postgres database を使い、しかも「数秒ごとに実際のお金が動く」checkout flow がある。つまり、ちょっとした不具合がそのまま売上や信用問題につながる、かなりシビアな環境です。
そこに持ち込まれた要望はこうです。
LLMを使ってローン申請を事前審査し、危険そうな申請を人間に回したい
言葉にすると簡単ですが、実際には全然簡単じゃない。
この記事の面白いところは、AIを入れたら何が壊れたかを「壊れた順」に並べている点です。これ、かなりリアルです。現場ってだいたい、一番派手な失敗からではなく、地味な前提のズレから崩れるので。
最初の実装は、いかにも「デモで見せやすい」作りでした。
application submission の処理の中で、そのまま LLM を呼ぶ。申請が来たらモデルに問い合わせ、risk score を返して、そのまま保存する。見た目はシンプルです。
でも本番では、モデル提供元が遅くなっただけで大事故になりました。
response time が 800ms から 19秒に悪化したとき、申請処理が全部ぶら下がって止まり、ローン申請が進まなくなったのです。
ここで重要なのは、LLMを「ちょっと賢い関数」みたいに置いてしまったことです。
普通の関数は、その場で高速に返る前提です。でもLLMは、
という、むしろ「不安定な外部部品」です。
個人的には、この失敗はかなり本質的だと思います。
AI導入でつい忘れがちなのは、モデルの賢さと、システムの安定性は別問題だということです。賢くても遅ければUXは壊れますし、外部依存が強いほど障害の伝染も起きやすい。ここを甘く見ると、AIは便利どころか足を引っ張ります。
timeout を直したあと、次に出てきた問題は「モデルが自信満々に間違える」ことでした。
しかも厄介なのは、出力がちゃんとして見えることです。フォーマットは整っている。説明もそれっぽい。なのに中身がズレている。
原因はモデルではなく、データでした。
元記事によると、applications table には「年収」を意味する列が3つあり、それぞれ別の intake form から10年以上かけて投入されていたそうです。
しかも中身は、
などが混在していた。これではモデルがどれだけ頑張っても、入力がぐちゃぐちゃなので正しい判断は難しいです。
ここでの教訓はかなり重いです。
AI導入は、実はデータ整備の仕事になりやすい。
しかも古いシステムほど「その列、何を意味してるの？」という歴史的経緯が積み重なっています。運用の都合で増えたカラム、フォーム改修の名残、誰も覚えていない変換ルール……。こういう“技術的負債の化石”が、AIで一気に表面化するわけです。
この記事の表現を借りれば、これは「integration project」ではなく「data project wearing an AI hat」です。
これはうまい言い方だなと思いました。まさにその通りで、AIは魔法の粒ではなく、汚いデータを見えにくくする帽子ではありません。
次の問題は、お金です。
最初は少量のトラフィックだったので安く見えた。でもある日、別の product line にも機能が使われ、volume が一気に3倍に増えた。結果、月末の請求額が「桁、間違ってない？」と思うレベルになったそうです。
これはかなりわかりやすい落とし穴です。
AIのコストって、エラーのように即座に悲鳴を上げません。じわじわ積み上がるんです。だから latency や failure は監視していても、cost は後回しにされがち。で、気づいたときには請求書で現実を突きつけられる。
ここはかなり企業あるあるだと思います。
「まずは動かしてみよう」で始めると、コスト計測は後回しになります。でもAIは、動いた瞬間から請求が発生する。これは無料の実験道具ではなく、従量課金の外部サービスです。かなり当たり前なのに、忘れやすい。地味だけど重要なポイントです。
最終的にチームが採ったのは、LLMをアプリ本体に直結しない構成です。
代わりに gateway を置き、その先でAIを扱うようにしました。
gateway とは、ざっくり言えば「アプリと外部AIの間に立つ中継役」です。
アプリは gateway に対してだけ問い合わせればよく、LLM の細かい事情を知る必要がありません。
この gateway が持つ責任は、元記事では主に4つです。
model が遅ければ、待ち続けずに早めに諦める。
circuit breaking は、壊れた外部サービスに延々と突撃しないための仕組みで、「今は危ないから止める」という安全装置です。
LLMがダメなら、古い rules-based score に戻す。
deterministic というのは「同じ入力なら同じ結果になる」こと。要するに、LLMが気まぐれでも、従来のルールベース判定という“確実に返る保険”を用意しておくわけです。
ここ、私はかなり重要だと思います。
AIって「精度が高いほうが勝ち」みたいに語られがちですが、本番では**“少し賢いが止まる”より、“そこそこでも確実に返る”**ほうが勝つ場面が多いです。特に金融みたいに止まれない業務ではなおさらです。
telemetry は、システムの利用状況や動作状況を計測して送る仕組みのことです。
ここでは「1回ごとのコストや利用状況を記録する」ことが大事。急な増加があればアラートを出せるようになります。
audit trail は、あとから「何が起きたか」を追える記録です。
どの入力に対して、どの model version で、最終的に人間がどう判断したか。規制のある金融業界では、これはかなり重要です。
AIの判断をブラックボックスにしてしまうと、後から説明できません。これは単なる便利機能ではなく、責任の所在を守るための装置です。
元記事では、アプリケーション側は aiGateway.scoreRisk() を呼ぶだけで、裏で何が起きているかは気にしない設計にしたと説明しています。
この発想はとても健全です。
AIを「特別な魔法」としてアプリの中心に置くと、壊れたときに全体が巻き込まれます。
でも gateway で隔離しておけば、
といった操作が、アプリ本体に手を入れずにできます。
これは地味ですが、運用上はものすごく大きいです。
個人的には、AIを入れるときほど “アプリはAIの存在を知らなくていい” くらいの割り切りが効くと思います。全部をAIに染める必要はないんですよね。
元記事は、こうした失敗が珍しくない理由として、業界全体の圧力にも触れています。
Gartner の予測として、2027年末までに agentic AI projects の40%以上がキャンセルされる見込みがあるそうです。その理由は、悪いモデルというより、
といった、統合の問題だとされています。
一方で、2026年末までに enterprise applications の40%が task-specific AI agents を備えるとも予測されています。
つまり、企業は「やらない」ではいられない。でも急いで入れると壊れる。なかなか厄介な状況です。
この記事が面白いのは、この板挟みの現実をちゃんと描いているところだと思います。
AI導入は流行りだからやるものではなく、既存システムの制約を理解して初めて成立する仕事です。
元記事では、やり直せるなら次の4点を先にやると言っています。
1週間でも data inventory をやっていれば、3つの年収カラム問題は事前に見つかったはず、という話です。
これは本当にその通りで、AIの前にまず棚卸しです。
4日くらいの追加工数はかかっても、後で大事故を防げるなら安い、という考え方です。
私はかなり同意します。後付けはたいてい高いです。
「請求が来てから考える」は遅すぎる。
これはAIに限らず、従量課金サービス全般に言えることですね。
たとえば「危険な5%を人間レビューに回す」はテストできる。
「AIで underwriting を全部変える」は広すぎる。
この差はかなり大きいです。AIプロジェクトが失敗しやすいのは、最初の目標がふわっとしすぎているからでもあります。
この記事の結論は明快です。
AI導入は、モデルの性能だけで決まりません。むしろ失敗するのは、モデルと既存ソフトウェアの接点です。
なので重要なのは、
という、かなり地味な設計です。
派手さはないけれど、こういう地味な設計こそ本番運用の勝負どころだと思います。
LLMは便利です。でも便利だからこそ、雑にくっつけると簡単に痛い目を見る。この記事は、その現実をとてもわかりやすく、しかも実務の温度感つきで伝えてくれる良いケーススタディでした。
参考: We Connected an LLM to a 12-Year-Old Codebase. Here's What Broke.
