この記事の結論
- AIが事業の中核か業務効率化かで、投じる額も撤退の基準も別物になります
- 中核でないなら、既製のサービスで足りないかを確かめるのが先です
- AIを使うこと自体が目的になっている投資は、フェーズを問わず止めてよいものです
AI関連の投資判断が難しいのは、金額の大小より、何に対する投資なのかが曖昧になりやすいからです。「AIを入れる」という一言の中に、売上を作るための機能開発と、社内の手間を減らすための効率化が混ざっています。この二つは、投じるべき額も、成功の測り方も、やめる基準も違います。
本記事では、その区別を起点にフェーズごとの賭け方を整理します。開発工程そのものに生成AIを使う話は生成AIを開発工程に組み込むで扱っているため、ここではプロダクトと事業への投資判断に絞ります。
まず「中核か、効率化か」を分ける
判断の最初の分岐は、AI機能が事業の中核かどうかです。
中核であるとは、顧客がその機能のために対価を払っている状態を指します。AI機能を止めたら、顧客が離れる。競合との比較で、その機能の品質が選定理由になる。この場合、AIへの投資は事業そのものへの投資であり、相応の額と時間を割く根拠があります。
効率化であるとは、社内やオペレーションの手間を減らすための利用を指します。問い合わせ一次対応の下書き、議事録の要約、書類の分類。顧客はその存在を意識しません。この場合の投資判断は、削減できる時間と費用に対して支出が見合うかという、通常の業務改善と同じ尺度で判断できます。
両者が混ざると判断が歪みます。効率化のための機能に中核のような予算を割く。逆に、顧客が対価を払っている中核の機能を片手間の稼働で運用してしまう。まずこの区別を書き分けてください。
| 中核として投資する場合 | 効率化として投資する場合 | |
|---|---|---|
| 成功の測り方 | 受注率、継続率、単価 | 削減できた時間、対応件数 |
| 品質の要求 | 顧客が見るため高い | 人が確認する前提なら緩められる |
| 投じる額 | 事業投資として評価 | 削減効果との比較で判断 |
| やめる基準 | 顧客が選ぶ理由になっていない | 削減効果が支出を下回った |
| 進め方 | 検証を重ねて作り込む | 既製のサービスで足りないか先に確認 |
フェーズごとの賭け方
シード — 小さく試し、やめる前提で始める
この段階の目的は検証です。AI機能についても、MVPの考え方をそのまま当てはめられます。
具体的には、既製のAI APIをそのまま呼ぶ、もっとも単純な形で作り、限られた顧客に使ってもらいます。ここで確かめるのは精度の絶対値ではなく、「この機能があることで、顧客の行動が変わるか」です。行動が変わらないなら、精度を上げても結果は同じです。
避けたいのは、この段階で大がかりな仕組みを組むことです。データを集めて独自に学習させる、専用の検索基盤を用意するといった投資は、そもそもその機能が要るかどうかが分かっていない時点では割に合いません。既製のAPIに、適切な指示と手元にあるデータを渡す形で、まず試してください。
やめる基準も、始める前に決めておきます。「三か月使ってもらって、この機能を経由する利用が全体の一定割合に届かなければ外す」といった形です。
シリーズA — 費用の予測可能性と、外せるかどうか
顧客が増える段階になると、二つの論点が出てきます。
一つは費用です。AI APIの利用料は利用量に比例するため、顧客が増えると支出も増えます。顧客一人あたりの粗利を計算し、AI機能の費用がそれを侵食しないかを確かめてください。無料プランでAI機能を開放すると、利用が増えるほど赤字が膨らむ構造になりがちです。上限の設定や無料枠での回数制限といった設計が必要になります。
もう一つは、乗り換えられる形になっているかです。提供事業者の料金体系や仕様は変わります。呼び出しが画面のあちこちに散らばっていると、変更のたびに広範囲の修正が必要になります。呼び出し口を一箇所にまとめておくだけで、この負担は大きく下がります。
シリーズB以降 — 品質の維持を仕組みにする
この段階では、AI機能が期待どおりに動き続けているかを、人の感覚ではなく仕組みで確かめる必要が出てきます。提供事業者がモデルを更新すると、同じ指示でも出力が変わることがあるためです。
とはいえ、最初から精緻な評価の仕組みを組む必要はありません。代表的な入力と期待される出力の組を数十件用意し、変更のたびに通して目視で確認する程度から始められます。そこで問題が見えるようになってから、自動化の範囲を広げてください。
既製のサービスで足りないかを先に確かめる
投資判断の前に通しておきたい問いがあります。それは作る必要があるのか、という問いです。
近年、使っている業務ソフトやSaaSの側にAI機能が標準で備わっていることが増えました。メールの下書き、表計算の要約、問い合わせ管理ツールの回答候補提示など、すでに契約している製品で足りるケースは少なくありません。
順序としては次のようになります。
- すでに契約している製品に同等の機能がないか確認する
- 追加契約で済むSaaSがないか調べる
- 既製のAI APIを呼ぶ小さな実装で足りないか試す
- それでも足りない場合に、作り込みを検討する
1と2で足りるなら、開発は不要です。発注を受ける立場でこう書くのは奇妙に見えるかもしれませんが、使われない機能を作ることは双方にとって損失です。弊社は既存のAIサービスをWebアプリに組み込む開発を行っており、AI活用開発でもその範囲を明示しています。モデルをゼロから学習させる研究開発は専門ではないため、その必要がある案件では正直にお伝えします。
やめたほうがよい投資
最後に、フェーズを問わず止めてよいと考えているものを挙げます。
AIを使うこと自体が目的になっている投資。「AIを活用している」と言いたいがために機能を足す判断は、運用の手間と費用だけを残します。プレスリリースの一行のために機能を作るなら、その予算は別の用途に回すほうが合理的です。
精度の要求水準を決めずに始める投資。「もっと精度を上げたい」は終わりのない要求です。何割の正しさがあれば業務として成立するのか、間違ったときに誰がどう気づくのかを先に決めてください。これが決まらない案件は、いつまでも完成しません。
人の確認を前提にできない領域への適用。出力が顧客の重要な判断や金銭に直接影響する場面で、人の確認を挟まない設計は避けるべきです。医療、法務、金融など規制のある領域では、適用の可否を含めて専門家の確認が要ります。
検証なしで顧客データを外部APIに送る設計。利用規約上許されるか、顧客への説明が済んでいるかを確認せずに進めると、後から止めることになります。
賭ける前に、外せるようにしておく
AIへの投資判断でもっとも実務的な原則は、始めるときに、やめ方を決めておくことです。中核として賭けるならどこまで投じるかを、効率化として入れるなら削減効果が出なかったときにいつ外すかを、先に書いておく。これだけで、惰性で続く支出をかなり減らせます。
そして、フェーズが上がるにつれて判断の重心は「作るか」から「足りているか」に移ります。既製のもので足りる範囲は年々広がっており、作る必要のある領域は狭くなっています。作らずに済むなら、それが最良の投資判断です。
自社の状況でAIをどこまで組み込むべきか、あるいは組み込まない判断が妥当かを一緒に整理したい場合は、AI活用開発やWebシステム開発の観点からご相談に応じます。お問い合わせからどうぞ。ご相談・お見積りは無料です。
なお本記事は一般的な情報です。個人情報の取り扱い、規制のある業種への適用、利用規約の解釈といった事項は、個別の事案について専門家にご確認ください。
チェックリスト
- AI機能が売上の理由か、コストの削減かを区別できているか
- その機能がなくなったときに顧客が困るかを確かめたか
- 既製のSaaSや標準機能で代替できないか調べたか
- 利用量に比例する費用の上限を決めているか
- 精度がどの水準なら使い物になるかを事前に決めたか
- やめる基準と、いつ判断するかを決めているか
よくあるご質問
AI機能は早く入れないと競合に遅れませんか
顧客が選ぶ理由がAIそのものであるなら急ぐ意味がありますが、多くの場合、選ばれる理由は別のところにあります。AI機能の有無で受注が決まっているかを確かめてから判断することをおすすめします。確かめずに投資すると、使われない機能が運用費だけを消費します。
独自のモデルを学習させる必要がありますか
業務に当てはめる用途の大半は、既製のAI APIに適切な指示と自社のデータを渡すことで足ります。モデルを自ら学習させる判断は、研究開発として相応の体制と期間を要する領域であり、事業の中核がそこにある場合に限られます。弊社はその領域を専門としていないため、必要な場合は素直にそう申し上げます。
AI機能の費用が読めないのが不安です
利用量に比例する料金体系のため、上限の設定と利用状況の可視化を最初に入れてください。多くの提供事業者が利用上限や使用状況の確認手段を用意しています。設計の段階で、想定外の量が発生したときに止まる仕組みを入れておくと安全です。
関連する記事
- 技術・インフラ生成AIを開発工程に組み込む — 品質を落とさず速く安く作る実務設計書の下書き、コード生成とレビュー、テスト生成、既存コードの解析、ドキュメント整備での生成AIの使いどころと、人がレビューする原則、顧客データや秘密情報の扱い、向く作業と向かない作業を整理します。
- プロダクトMVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- グロース・収益化PMFをどう見極めるか — 指標と判断の考え方PMFの定義と、継続率やチャーンなどの定量シグナル、利用者の声に表れる定性シグナルの読み方、PMF前に投資してはいけないもの、誤認しやすいパターン、PMF後に変わる開発の優先順位を整理します。
関連するサービス
関連用語: MVP、API、プロダクトマーケットフィット、LTV
監修: フィリット・コンサルティング株式会社公開