AI 機能を、
既存プロダクトに載せる前に。

「AI 機能を載せたら1日の利用者数が下がった」「LLM の利用料が想定を大きく超えた」「顧客から個人情報の取り扱いについて指摘を受けた」— 既存プロダクトへの AI 機能の追加で起きやすい、典型的な失敗パターンです。新規プロダクトをゼロから作るときには現れない、既存ユーザー・既存データ・既存運用を抱えたまま AI を載せることによる固有の難しさがあります。どの業務に AI を使うべきかについては、コラム「AI エージェントが効く5つの業務パターン — リサーチ・定型・判断・対話・連携の見極め方」で整理しています。本稿は「載せると決めたあと、実装に入る前に固めておく5つのこと」に絞って解説します。

1. 既存プロダクトへの AI 搭載が頓挫する3大要因

失敗事例を分解すると、原因はおおむね3つの構造的な要因に集約されます。

1.1 データの前提が崩れる

「自社にはデータがある」と思って着手したものの、フォーマットが揃っていない、更新されていない、利用規約上 AI に渡せない、というケースがよくあります。データを使える状態に整えるだけで2〜3ヶ月かかることもあります。

1.2 コスト試算が甘い

PoC のときの月額数万円という感覚のまま本番化を決めると、利用者が増えたところで費用が月額数百万円に達することもあります。価格に転嫁できなければ、その機能は赤字になります。試算の段階から、処理する文字量（LLM の課金単位になるトークン）、使うモデルの選び方、キャッシュ（同じ指示文を使い回して費用を抑える仕組み）の3点を織り込んでおく必要があります。

1.3 UX が AI の誤答を想定していない

「AI は100%正解する」前提で画面や操作の流れを作ると、誤答が一度出ただけで利用者の信頼を失います。誤答が出ても利用者が困らない画面の作りを、最初から設計に組み込みます。

2. データ — 既存データが AI に使えるかを見る5つのチェック項目

実装に着手する前に、既存データが AI に使える状態かどうかを、次の5つの項目で確認します。

2.1 ボリューム — 必要な最低件数

必要な件数は、用途によって大きく変わります。自社データを参照させる仕組み（RAG）なら、100件以上で動きます。手本となる例を見せて出力を整える方式（Few-shot）では、一度に見せる手本は数件で済みます。ただし、状況に合う手本を選び出す元データとして、1,000件以上あると安定します。自社データで追加学習させる方式（Fine-tuning）なら、10,000件以上が目安です。

2.2 構造化度 — そのまま読み込めるか

CSV やデータベースなど整形済みのデータであれば、ほぼそのまま使えます。PDF・Word・スキャン画像の文書は、読み込める形に整える前処理が必要です。その費用も試算に入れておきます。

2.3 品質 — ノイズ・欠損率

欠損率（値が空になっている割合）が30%を超える項目は、事実上使えません。重複や矛盾を含むデータも、AI の精度を直接押し下げます。データの修正・整理（クレンジング）にかかる工数を、最初から見積もりに入れます。

2.4 アクセス権限 — 利用条件

社内データなら通常は問題ありませんが、顧客データは利用規約・個人情報保護法・GDPR（EU の一般データ保護規則）の確認が必須です。「AI の学習に使う」場合と「回答を作らせるときに渡すだけ」の場合とで、扱いが変わることもあります。

2.5 更新頻度 — 鮮度低下のリスク

データが定期的に更新されないと、AI の出力は徐々に古くなり、利用者の信頼を失います。参照型ならデータ更新の自動化が、追加学習型なら再学習の計画が必要です。

3. コスト — LLM の利用料を利用者数から試算する

LLM の利用料は、利用者数と処理する文字量（トークン）の掛け算で急激に膨らみます。本番化の前に試算しておくべき要素は4つです。1つ目はトークン量で、1回あたりの入力と出力の量に利用回数を掛けて求めます。2つ目はモデルの選び方で、最上位モデルと軽量モデルでは単価が大きく違います。3つ目はキャッシュ率です。AI への指示文（プロンプト）を使い回す仕組みを入れれば、その部分の費用を50〜80%削減できることがあります。Anthropic と OpenAI はどちらも公式のキャッシュ機能を用意しているので、設計の段階から織り込んでおきます。4つ目は、自社でモデルを動かすか、外部の AI サービス（API）を使うかです。軽い処理なら、自社で動かすほうが大幅に安く済むこともあります。この4つに分けて試算しておかないと、利用者が増えたときの費用を正しく見積もれません。

試算は「1日の利用者が1万人のときにいくらか」「10万人のときにいくらか」と、利用者数の段階ごとに出します。ある利用者数を超えた途端に赤字へ転じる分岐点を、見落とさないためです。

4. UX — 精度80%でも使える4つの UI パターン

AI の回答には、一定の割合で誤りが混じります。それを前提に、誤答が出ても使い続けられる UI のパターンが4つあります。

5. セキュリティ — 顧客データを LLM に渡す前の4つの対策

顧客データを LLM に渡した時点で、セキュリティと法務の新たなリスクが生じます。本番化の前に、次の4つの対策を講じておきます。

5.1 個人情報の除去

氏名・住所・電話番号など個人を特定できる情報は、LLM に渡す前に伏せ字に置き換えます（マスキング）。既製の変換ツールを使うか、自社で置き換えのルールを決めて自動で処理するのが一般的です。

5.2 API 提供元の利用規約

入力したデータを AI の学習に再利用するかどうかの方針は、OpenAI・Anthropic・Google で異なります。Enterprise プランや、入力データを保持しないオプションを利用できるかどうかを、契約前に必ず確認します。

5.3 自社運用かクラウドか

金融・医療・法務などのデータをクラウドの LLM に渡せない場合は、オープンソースの LLM を自社の設備で動かす（オンプレミス）選択肢があります。コスト・運用負荷・精度の3つの軸で比べて決めます。

5.4 顧客への通知・同意

プライバシーポリシーに「AI 処理のために第三者サービスにデータを送信する」旨を明記します。既存顧客への通知が必要になり、場合によっては同意を取り直す必要もあります。

6. 運用 — 公開後の評価と監視の最低構成

本番公開後も改善を続けるには、次の4つが最低限必要です。これらがないと、AI 機能の品質が落ちても誰も気付かないまま放置されます。

6.1 継続監視 — 精度劣化・コスト・応答速度

モデルが更新されたり、入力データの傾向が時間とともに変わったりすることで、精度は徐々に落ちていきます。本番のログから精度を測り続ける仕組みを、最初から組み込みます。コストと応答速度も同じように監視します。

6.2 自動評価（Eval）の組み込み

代表的な入力を100〜1,000件選んでテストケースとして固定し、モデルやプロンプトを変えるたびに自動で評価する仕組みを用意します。詳しくは、コラム「PoC で終わらせない — 本番運用に届ける7つの設計原則」の「出力品質の自動評価」の章で解説しています。

6.3 A/B テストの設計

新しいプロンプトやモデルを一部の利用者にだけ公開し、従来版と比べる仕組み（A/B テスト）を用意します。事業の KPI（コンバージョン率・継続率）への影響を測ります。

6.4 インシデント対応プロセス

「AI が不適切な回答をした」「コストが急増した」「外部の AI サービスが止まった」といった事態への対応を、手順書にまとめておきます。問題が起きたときに AI 機能だけをすぐ止められるよう、機能のオン・オフを切り替える仕組み（機能フラグ）も組み込んでおきます。

7. 発注前ヒアリングシート（5つの項目）

本稿の5つの観点を、開発を発注する前に自社で答えておくべき質問として整理しました。

1. データ準備度：既存データのボリューム・構造化度・品質・アクセス権限・更新頻度は把握できているか？
2. コスト許容ライン：1日の利用者が1万人・10万人になったときの月額コストの上限と、価格に転嫁できるかどうかは決まっているか？
3. UX 設計方針：候補提示・編集前提・確認ボタン・フィードバック収集のどのパターンを採るか？
4. セキュリティ要件：個人情報の除去、利用規約の確認、自社運用かクラウドかの選択、顧客への通知について、方針は決まっているか？
5. 運用体制：精度の監視・自動評価・A/B テスト・インシデント対応について、責任者と工数は確保できているか？

5つすべてに具体的な回答が出る状態で発注すれば、PoC から本番化までの期間は大きく縮まります。Kmetric の AI エージェント開発では、初回の要件整理（Discovery）で、このヒアリングシートを必ず埋めるところから始めます。

8. AI 機能の実装パターン3例

既存プロダクトへの AI 機能の載せ方を、代表的な3つの例で整理します。

この3例は、UX パターン・基盤・コスト戦略の組み合わせがそれぞれ異なります。自社に合う組み合わせは、第7章のヒアリングシートに答えていくと絞り込めます。