AI・LLM 機能の企画

LLM（大規模言語モデル）の出力は、もっともらしい誤りを含むことがあり、精度は100%になりません。企画では「どう正しく答えさせるか」と同じくらい、間違えたときの体験・確認の仕組み・コストを設計します。

誤り前提の設計：出典を表示する、人が確認・修正してから使う、「役に立たなかった」を押せるようにする、自信がないときは人に引き継ぐ、などを仕様に入れます。

ML の「LLM アプリの評価」

ML の「安全性とコスト」

LLM は、大量の文章から学んで、入力に続く言葉を確率で選ぶことをくり返して文章を作ります。「調べて答える」のではないので、知らないことや最新のことも、それらしく答えてしまうことがあります（ハルシネーション）。

RAG（検索拡張生成）は、質問に関係する文書を先に検索し、その部分を LLM に渡して答えさせる作り方です。社内の規程やヘルプ記事のように、LLM が学習していない情報で答えられ、出典を見せられるので確かめやすくなります。

答えが悪いとき、原因は LLM より検索で正しい文書が取れていないことが多いです。評価では、検索の結果と答えを分けて見ます。

ML の「LLM」

評価：「なんとなく良さそう」で出さないために、代表的な質問と期待する答えを集めた評価用データ（まず数十〜数百件）を作り、プロンプトやモデルを変えるたびに同じデータで点数を比べます。採点は人が行うか、別の LLM に基準を渡して採点させます。出したあとは、低評価の率や人への引き継ぎ率を見続けます。

評価用データは、実際の問い合わせから作り、間違えやすい質問や答えてはいけない質問も入れます。PdM は「どの点数なら出してよいか」の基準を決めます。

コスト（トークン）：多くの LLM はトークン（文字のかたまりの単位）の数で課金され、入力と出力で単価が違います。トークンの数え方はモデルや言語で変わり、同じ内容でも日本語は英語よりトークンが多くなることがよくあります。実際の数は、使うモデルのトークン数を数える機能で測って確かめます。「1回あたりの入力・出力のトークン数 × 単価 × 1日の回数」で月の費用を試算し、長い文書を毎回すべて渡す設計は特に高くなる点に注意します。小さいモデルを使い分ける、回数に上限をつける、なども選択肢です。

費用を下げる方法には、渡す文書を絞る、答えを短くする、簡単な質問は小さいモデルに回す、同じ質問の答えを使い回す、1人あたりの回数に上限をつける、などがあります。無料で無制限にする前に、使われすぎたときの費用を必ず試算します。

データの扱い：入力した個人情報や社内情報が提供元でどう扱われるか（学習に使われないか、保存期間）を契約で確認します。ユーザーの入力で指示を乗っ取られるプロンプトインジェクションへの対策も、エンジニアと一緒に考えます。

特に、AI にメール送信や購入などの操作をさせる機能は、乗っ取られたときの被害が大きくなります。最初は「提案だけして、実行は人が押す」形から始めるのが安全です。