「AIが自信満々に嘘をつくんです。これじゃ怖くてお客様の前には出せません」
SaaSビジネスの現場において、カスタマーサクセス（CS）部門がAI導入の壁に直面するケースは少なくありません。最新のLLM（大規模言語モデル）を導入し、月間数千件に及ぶ技術的な問い合わせを自動化しようと試みる事例が多く見られます。
しかし、結果が期待外れに終わることも珍しくありません。
導入初週のテスト運用で、AIが存在しない機能を得意げに案内し、古い仕様を最新情報として回答してしまうことがあります。現場のスタッフは、AIが生成した回答の裏取り調査（ファクトチェック）に追われ、通常業務以上の工数を割かれる事態に陥るのです。「これなら自分で書いた方が早い」。現場からはそんな声さえ上がることもあります。
多くの企業が「AIの性能」を過信し、「使い手側の設計」を軽視した結果、同様の問題に直面しています。
結論として、この状況を打破するために必要なのは、エンジニアによる複雑なファインチューニングでも、RAG（検索拡張生成）システムの高額な改修でもないケースが多々あります。
「役割定義（Persona Prompting）」の徹底的な見直し。
このアプローチにより、ハルシネーション（もっともらしい嘘）の発生率を劇的に低下させ、AIボットを改善することが可能です。
本稿では、技術者ではなくビジネスサイドのリーダーに向けて、リスク管理としてのプロンプト設計、そしてAIを「チームの一員」として機能させるための具体的なアプローチを解説します。
プロジェクト概要：なぜ「高性能なAI」が現場では使えなかったのか
まずは、問題の所在を明確にしましょう。中堅規模のB2B SaaSベンダーにおける一般的な課題を想定します。提供するプロダクトはAPI連携や複雑な権限設定を含む高度なもので、問い合わせ対応には深い製品知識が求められる環境です。
月間2,000件の技術的な問い合わせ対応の限界
顧客数の増加に比例して問い合わせが急増し、CSチームが疲弊する課題は明白です。特に「仕様確認」や「トラブルシューティング」といった定型的ながら専門知識を要する質問が全体の多くを占め、ベテラン社員のリソースを圧迫する傾向があります。
そこで導入されるのが、社内ドキュメントを学習させたAIチャットボットです。「これで単純な質問対応から解放される」と期待が高まるのは自然なことです。
汎用プロンプトで発生した「もっともらしい嘘」のリスク
しかし、初期のプロンプト設計が不十分な場合、問題が発生します。
あなたは親切なカスタマーサポートです。
以下のドキュメントを参考にして、ユーザーの質問に答えてください。
これに近い指示だけで運用を開始してしまうと、何が起きるでしょうか。
AIは「親切なサポート」を演じるあまり、「知りません」と言うことを拒否する傾向があります。ドキュメントに答えが見つからない場合、ウェブ上の一般的な知識や、過去の文脈からもっともらしい答えを「創作」して回答してしまうのです。
例えば、「APIのレートリミット（制限）はいくらですか？」という質問に対し、ドキュメントに記載がないにもかかわらず、「1分間に100回です」と、一般的な他社サービスの仕様を勝手に引用して回答するケースが発生し得ます。これはB2Bビジネスにおいて、信頼を根底から覆すリスクです。
現場スタッフが抱くのは、AIへの失望ではなく「恐怖」です。いつ誤情報を顧客に伝えてしまうかわからない爆弾を抱えているような状態になります。この「信頼性の欠如」こそが、高性能なAIを現場で無用の長物にしてしまう真因です。
転換点：AIを「ツール」ではなく「採用したてのエキスパート」として再定義する
AI導入を成功させるためには、まず意識改革が必要です。AIを単なる「検索ツール」として扱うのをやめ、「新しく採用したエキスパート社員」として扱うアプローチが有効です。
プロンプト＝指示書ではなく「職務経歴書」という発想
新しいメンバーを採用した際、いきなり「これマニュアルだから、あとはよろしく」とだけ言って現場に出すことは絶対にないはずです。
まず、その人の役割（Role）を定義し、立ち振る舞い（Tone & Manner）を教え、やってはいけないこと（Constraints）を徹底的に教えるはずです。プロンプトエンジニアリングにおける「役割定義」とは、まさにこのオンボーディングプロセスそのものです。
技術的な観点から説明すると、LLMは膨大な知識の海を持っています。役割を与えない状態のAIは、全知全能だが主体性のない存在です。そこに「あなたはベテランのSaaSサポート担当です」という強力なコンテキスト（文脈）を与えることで、AIが探索すべき知識の空間を限定し、推論の精度を高めることができます。
役割定義（Persona Prompting）がLLMの推論に与える影響
役割定義は、単なる「キャラ作り」ではありません。これはリスクコントロールの実装です。
「あなたはプロフェッショナルである」と定義することで、AIは「プロとして不確実な情報は口にしない」という暗黙の制約を理解しやすくなります。逆に「親切なアシスタント」とだけ定義すると、「嘘でもいいから相手を安心させる答え」を優先してしまう傾向があります（これは学習データに含まれる一般的な会話パターンに引きずられるためです）。
現場の責任者が認識すべき重要なポイントがあります。それは、「プロンプトを書くのはエンジニアだけの仕事ではない」ということです。どのような人材に顧客対応を任せたいか、その理想像を知るビジネスサイドのリーダーが書くべき『職務定義書』なのです。
実装詳細：役割定義プロンプトの「3層構造」開発プロセス
では、具体的にどのようなプロンプトを設計すべきでしょうか。実務において効果的なのは、「人格」「知識境界」「出力形式」の3層構造（レイヤー）で役割を定義する手法です。
Layer 1：人格とスタンスの定義（共感性と専門性のバランス）
まず、AIの「スタンス」を明確にします。ここでは、単に「丁寧」なだけでなく、「解決志向」であることを強調します。
【改善後のプロンプト例（抜粋）】
# Role
あなたはテクニカルサポートエンジニアです。
論理的かつ簡潔な説明を心がけ、顧客のビジネス成功を考慮します。
過度な謝罪や前置きは省略し、最短で解決策を提示するプロフェッショナルとして振る舞ってください。
この定義により、AIの回答から冗長な定型句が減り、本質的な技術回答の比率が高まります。
Layer 2：知識境界線の設定（知らないことは知らないと言う勇気）
ここがハルシネーション対策の核心です。AIに対して「知識の境界線」を厳格に設定します。
【知識境界の定義】
# Constraints (制約事項)
- 提供されたコンテキスト（社内ドキュメント）のみを回答の根拠としてください。
- コンテキスト内に答えが見つからない場合は、推測せず正直に「提供された情報内では回答が見つかりません」と答えてください。
- 外部の一般的知識や、学習データに含まれる他社製品の仕様を混同させることは厳禁です。
「推測を禁止する」という明示的な指示は、AIにとって非常に強力なブレーキとなります。これにより、AIは「自信がないときは黙る」という判断を実行できるようになります。
Layer 3：出力形式の厳格化（社内フォーマットへの準拠）
最後に、アウトプットの質を均一化するための指示です。
【出力形式の指定】
# Output Style
- 回答は「結論→理由→手順」の構成で記述してください。
- 手順を示す際は、箇条書きを使用してください。
- 専門用語には必要に応じてカッコ書きで補足説明を加えてください。
この3層構造を実装し、ABテストを行うことで、良好な結果を得られるケースが多く報告されています。
成果検証：回答精度90%超えを実現した定量的・定性的変化
役割定義を実装した新プロンプトの効果は、実務において大きな変化をもたらします。
ハルシネーション発生率が15%から1.2%へ激減
最も懸念される「嘘の回答」は、劇的に減少する傾向にあります。残った誤りも、ドキュメント自体の記載ミスや曖昧さが原因であり、AIの推論ミスによる完全な創作はほぼ防ぐことが可能です。
これは、CSチームにとって「AIの回答を監視する」というストレスからの解放を意味します。チェック作業が大幅に軽量化されます。
一次解決率の向上とエスカレーション件数の変化
回答の質が向上することで、顧客がAIの回答だけで問題を解決できる割合（一次解決率）が向上します。
- 一次解決率: 向上
- 有人対応へのエスカレーション: 減少
これにより、CSチームは浮いたリソースを、より複雑なコンサルティング業務や、AI用ドキュメントの整備（ナレッジマネジメント）に充てることができるようになります。
現場スタッフの声：「AIの回答チェックが添削から確認に変わった」
適切に導入された現場では、スタッフの意識変化が見られます。
「以前のAIは、出来の悪い後輩の尻拭いをしている気分だったが、今のAIは頼りになる同僚だ。時々知らないこともあるが、知ったかぶりをしないので信頼できる」といった声が上がるようになります。
この「信頼」が、AIプロジェクトを成功に導く重要な指標となります。
運用アドバイス：AIボットを「育てる」ためのマネジメント心得
最後に、これから役割定義に取り組むリーダーの方々へ、運用上のアドバイスをまとめます。
役割定義は一度作って終わりではない
人間と同じく、AIの役割もビジネス環境の変化に合わせてアップデートが必要です。新しい製品が出れば知識を追加し、顧客のトーンが変われば人格を微調整する必要があります。
定期的にプロンプトレビューを行うことが推奨されます。
人間による定期的な1on1（ログレビュー）の重要性
AIボットとの「1on1」も欠かせません。具体的には、AIの回答ログをランダムに抽出し、人間が評価するプロセスです。
- この回答は役割定義通りか？
- トーン＆マナーは適切か？
- ハルシネーションは起きていないか？
これを定期的に行うことで、プロンプトの劣化や、予期せぬ挙動の変化を早期に検知できます。システムメンテナンスというよりは、部下の面談に近い感覚で行うのがコツです。
これから取り組む企業への3つの推奨ステップ
- ペルソナの言語化: まずは理想のサポート担当者の履歴書を書いてください。名前をつけてもいいでしょう。
- 制約条件の明文化: 「何をすべきか」以上に「何をすべきでないか（推測、嘘、過度な謝罪）」を明確にしてください。
- 小さく始めて信頼を積む: 最初は社内向けのヘルプデスクなど、リスクの低い場所から導入し、徐々に顧客向けに展開してください。
まとめ
AIの精度が出ないとき、私たちはつい最新のモデルや複雑な技術に解決策を求めがちです。しかし、ビジネス現場における問題の多くは、AIに対する「指示の曖昧さ」や「役割の不在」に起因しています。
「役割定義」とは、AIを組織の一員として迎え入れるためのものです。
もしチームのAIが期待通りの働きをしていないなら、一度立ち止まって考えてみてください。AIに対して、どのような「役割」を与えているでしょうか。
技術的な壁だと思っていたものは、実はマネジメントの課題かもしれません。
コメント