AI機能は自分で使わないと分からない

AI機能を組み込んだプロダクトの開発では、「できました」と言われても判断に困る場面があります。デモを見れば動いているように見えますが、それが自社の業務で使い物になるかは分かりません。通常の機能なら仕様書と突き合わせて確認できますが、AIの出力品質は仕様書に書けないからです。

本記事では、既製のAI API（OpenAI、Anthropic、Google などが提供する大規模言語モデルのAPI）を組み込んだ機能について、発注側が採否を判断するために何を見るべきかを整理します。開発工程そのものにAIを使う話は生成AIを開発工程に組み込むで扱っています。

仕様書に書けないものが合否を決める

通常の機能であれば、「ボタンを押すと一覧が絞り込まれる」という仕様に対して、動くか動かないかで判定できます。AI機能ではこの判定ができません。

たとえば「問い合わせメールを要約する」機能の仕様を書こうとすると、書けるのは入力と出力の形式、応答時間の上限、失敗時の挙動までです。肝心の「要約の質」は、良い要約の定義そのものが業務によって違うため、事前に文章化できません。営業の引き継ぎに使う要約と、クレーム対応の優先度判断に使う要約では、残すべき情報が違います。

この性質があるため、AI機能の検証は「仕様を満たしたか」ではなく「実際の業務で使えたか」という形でしか行えません。そして実際の業務で使うとは、自分たちで毎日使うということです。

「惜しい」と「使えない」の差はどこに出るか

一度触っただけでは、AIの出力はたいてい「思ったより良い」という印象になります。この印象が判断を狂わせます。毎日使うと、印象は次の三つに分かれていきます。

このうち重要なのが「惜しい」の扱いです。惜しい出力は、一回ずつ見ると「まあ許容範囲」と感じます。しかし修正にかかる時間を記録すると、実態が見えてきます。一件あたり1分の修正でも、日に30件あれば毎日30分です。それがAIなしで作業した場合より短いのかどうかが、判断の物差しになります。

想定例：問い合わせ対応の下書き生成を社内で使った場面を考えます。出力そのものは自然な日本語で、印象は良いものでした。しかし2週間記録すると、自社のサービス名の表記ゆれを毎回直していること、返金の可否について誤った案内を混ぜてくることが分かりました。前者は指示の書き方で解決し、後者は「返金に関する問い合わせは対象外にする」という適用範囲の変更で対処する、という判断につながりました。

何を記録するか

毎日使う中で記録する項目は、多すぎると続きません。次の程度に絞ります。

• 出力をそのまま使えたか、直したか、捨てたか
• 直した場合、どこをどう直したか（一言で足りる）
• 想定と違う入力が来たときに何が起きたか
• 応答を待った時間が業務の流れを止めなかったか

最後の二つは見落とされがちですが、本番運用では決定的です。短い文章では良い結果が出ても、実務の文書は長く、形式も揃っていません。添付ファイルだけのメール、箇条書きだけの依頼、複数の話題が混ざった文章。こうした入力への挙動は、実際の業務で使わない限り出てきません。

費用も同じです。試験段階では気にならない金額でも、実際の利用頻度と文書量で計算すると桁が変わることがあります。実データで測ってから本番の設計に入る順序が現実的です。

AIを使わない、という結論も成果

検証の結果、AIを使わない判断になることがあります。これは失敗ではなく、検証が機能した証拠です。

• 入力の形式が決まっていて、条件分岐で処理できる：ルールベースの処理の方が安定し、費用もかかりません
• 誤りが許されず、人が全件確認する必要がある：確認の手間がAIの削減分を上回ります
• 対象の件数が少ない：仕組みを作る費用と運用の手間が見合いません

弊社では、AI機能のご相談をいただいた際、まず「AIで解くべき課題か」を確認します。従来の仕組みで十分な場合はその旨をお伝えします。AIを使うこと自体が目的になると、運用が始まってから費用と品質の両面で苦しくなるためです。詳しくはAI活用開発をご覧ください。

誰が使うかで結論が変わる

自社で使って判断する方法には前提があります。使っている人が、そのAI機能の対象利用者と近いことです。

社内のメンバーはプロダクトの背景を知っているため、AIの出力が多少おかしくても補って読めます。しかし、外部の利用者は補えません。「社内では問題なかったのに、利用者からは意味が分からないと言われた」という食い違いはここから生まれます。

対策は、出力をそのまま外部に出す機能かどうかで検証方法を分けることです。社内の担当者が確認してから出す機能なら社内での検証が有効です。利用者の画面に直接出る機能なら、社内検証に加えて、対象に近い外部の方に見てもらう工程を必ず入れます。この境界の考え方はドッグフーディングの限界と誤判断で整理しています。

社内での確認を終えたあと、限定公開から本番へ広げていく段取りはAI機能を安全に世に出すで扱っています。

使った記録が発注側の判断材料になる

AI機能の採否は、デモの印象でも精度の数値でもなく、実際の業務で使い続けた記録で判断します。そのまま使えた割合、直した箇所の傾向、修正にかかった時間、想定外の入力への挙動、実データでの費用。これらが揃って初めて、本番に載せるかどうかを判断できます。

開発を外部に依頼する場合も、この記録は発注側が持つべきものです。作り手の「動いています」という報告と、使い手の「使えています」という実感は別物だからです。

AI機能の適用範囲の見極めや、検証から本番運用までの設計についてご相談がありましたら、お問い合わせからお気軽にご連絡ください。

本記事は一般的な情報であり、個人情報の取り扱いなど個別の事案は専門家・所管官庁にご確認ください。