AI機能の追加は、機能開発ではなく体制の作り替えです

自社SaaSにAIを載せる、という相談の多くは「機能をひとつ増やす」話として持ち込まれます。要約ボタンを付けたい、チャットで問い合わせに答えさせたい、入力を自動で補完したい。機能単位で見積もりを取り、開発の1スプリントに収める。従来の機能追加と同じ段取りで進められる、という前提です。

この前提のまま進めた製品は、たいてい運用に入ってから詰まります。出力が毎回わずかに違う、想定していない答えを返す、月末にトークン費が跳ねる、「なぜこうなったのか」という問い合わせにサポートが答えられない。どれも実装のバグではなく、AIという部品の性質そのものから来ます。機能は動いているのに、事業として回らない状態です。

AIを載せるとは、確率的にふるまう部品を製品に組み込み、それを継続して評価し、原価を管理し、ユーザーに説明し続けることです。開発の進め方、原価の構造、サポートの形。この3つが同時に、しかも従来とは違う原理で動きはじめます。機能追加の段取りだけで挑むと、この3つを丸ごと見落とします。

LLMネイティブな開発体制は、従来のSaaS開発と何が違うか

従来のSaaS開発は、決められた入力に決められた出力を返すことを前提に組み立てられています。仕様を決め、実装し、テストが通れば、挙動は確定する。同じ操作をすれば同じ結果が返るので、テストを通した機能は、原則そのまま動き続けます。

LLMを組み込んだ機能は、この前提が成り立ちません。同じ入力でも出力は毎回わずかに揺れ、確率的にふるまいます。「テストが通った」という状態が、そもそも定義しづらい。何をもって正解とするかを人が決め、代表的な入力群に対して許容できる出力の範囲を用意し、それに照らして良し悪しを測る。この評価の仕組みごと作らないと、品質を語れません。

観点 従来のSaaS開発 LLMネイティブな開発
出力 決定的（同じ入力なら同じ出力） 確率的（同じ入力でも揺れる）
正解 仕様で確定する 「何を正解とするか」から決める
テスト 通れば確定する 評価データセットで継続的に測る
完成 リリースで区切れる モデル更新のたびに測り直す
資産 コード コード＋プロンプト＋評価データ

表の右側を回し続けることが、LLMネイティブな開発体制です。プロンプトはコードと同じようにバージョン管理し、変更の履歴と意図を残す。基盤モデルは提供元の都合で更新され、ある日ふるまいが変わることがあります。そのたびに評価データセットを流し直し、品質が落ちていないかを確かめる。出力してよい範囲を外れた回答を止めるガードレールを置き、外れたときにどう振る舞うかまで決めておく。作って納めれば終わり、ではありません。評価し続けることそのものが、運用の中身になります。

弊社がLLMを使った機能を引き受けるときは、実装より先に「何を正解とするか」を発注側と一緒に言語化し、代表的な入力と許容できる出力をまとめた評価データセットを納品物の一部として作ります。プロンプトを変えたとき、モデルが更新されたとき、このデータセットを流せば品質が保たれているかを機械的に確かめられる。「なんとなく良くなった、悪くなった」を感覚で言い合う状態から抜け出すための、最初の投資です。こうした進め方の全体像はAIネイティブ開発でも整理しています。

トークン原価を財務計画に織り込まないと、粗利が崩れます

SaaSが高い粗利を生めたのは、限界費用がほぼゼロだったからです。一度作った機能は、ユーザーが1人増えても1万人増えても、追加でかかる費用はサーバー代くらい。使われるほど売上だけが伸びて、原価は据え置かれる。この構造が、SaaSの利益率を支えてきました。

LLMを組み込むと、この前提が崩れます。トークンは使うほど費用がかかる変動原価です。ユーザーが増え、1人あたりの利用が増えれば、その分だけ原価が積み上がる。機能がよくできていて、たくさん使われるほど、原価も膨らむ。「使われるほど儲かる」はずが、設計を誤ると「使われるほど粗利が溶ける」に反転します。

だから料金設計と原価が、切り離せなくなります。定額で売り切ったまま重い処理を無制限に使わせれば、ヘビーユーザーほど赤字を運んでくる。従量課金にする、プランごとに利用量の上限を設ける、原価の高い処理だけ別枠にする。プライシングを、原価の構造に合わせて組み直す必要があります。この判断は、1件あたりのトークン原価と想定利用量を財務計画に織り込んで、はじめて根拠を持ちます。トークンがどう積み上がるか、その内訳の見積もりは運用コストの見積もりで詳しく扱っています。

AIを載せた製品は、CS体制も作り替えが要ります

従来のサポートは、正しい動作が決まっていることを前提にしています。仕様どおりに動かなければバグ、動けば仕様。問い合わせは「直す」か「使い方を案内する」かに切り分けられました。

AIを載せた製品では、この切り分けが効きません。出力は確率的で、仕様違反ではないのに「期待と違う」答えが返ることがある。ユーザーからの問い合わせは、「なぜこの出力になったのか」「この答えを変えたい」という、正誤では割り切れない相談に変わります。コードのどこにも欠陥はないのに、ユーザーは納得していない。この状態に応えられるかどうかが、AIを載せた製品のサポートの分かれ目です。

求められる役割が、従来と変わります。

これらは、バグ対応の延長では身につきません。サポートが開発と評価の仕組みにつながっていて、はじめて回ります。言い換えると、サポートが製品改善の最前線になります。確率的な出力に対するユーザーの不満は、次にどの入力を評価データセットへ足すべきかを教えてくれる、いちばん濃い情報源です。ここを「クレーム処理」として現場に押し込めると、改善の材料をそのまま捨てることになります。

この移行を越えた企業だけが、参入障壁を得ます

ここまで挙げた作り替えは、どれもコストと手間がかかります。評価の仕組みを作り、原価を財務に織り込み、サポートを開発につなぐ。機能をひとつ足すつもりだった企業には、重すぎる負担に見えるかもしれません。

けれど、この重さこそが参入障壁になります。AI機能そのものは、いまや誰でも同じ基盤モデルを呼べば、見た目は数日で真似できます。真似できないのは、その機能を継続して評価し、原価を管理し、ユーザーに説明し続ける体制のほうです。表に見える機能ではなく、裏で回り続ける仕組みが差になる。

だから、競合が同じボタンを付けてきても、体制のない機能は品質を保てず、原価に押されて続きません。移行を越えた企業だけが、AIを「載せた」ではなく「運用し続けられる」状態に立てます。ここが、模倣されにくい差になります。

弊社の関わり方

弊社は、AI機能の追加を機能開発ではなく、体制設計として引き受けます。どの作業をAIに任せ、どこから人が担うか。1件あたりどれだけのトークンを使い、料金にどう乗せるか。「期待と違う」出力をどのサポートが拾い、どう製品へ戻すか。開発体制・原価設計・サポート設計をひとつながりのものとして、発注側と一緒に決めます。

弊社自身がAIネイティブ開発を軸に手を動かし、評価データセットやプロンプトの運用、ベトナムオフショア開発による継続的な評価・改善の体制まで含めて設計できるのは、これらを日々の受託で回しているからです。作って納めて終わりにせず、動かし続ける仕組みごと引き受けます。

同時に、弊社はこの体制を弊社の中に囲い込みません。評価データセットもプロンプトも運用の勘所も、最終的に発注側が自分で回せるように渡していく。AI開発の伴走支援は、内製化を止めない前提で、体制が自走するところまで並走する関わり方です。

自社SaaSにAIを載せるか迷っている、あるいは載せた後の運用まで見通しておきたい。当てはまるなら、まず対象にしたい機能をひとつ選び、その機能で「何を正解とするか」「月にどれだけ使われるか」「期待と違う出力を誰が拾うか」を書き出してみてください。ここが埋まらないうちは、まだ機能開発の段取りにいます。体制設計からのご相談は、お問い合わせからお聞かせください。