1つの日常的なメッセージからAIキャラクターのテキスト返信を再設計する方法
有用なAIキャラクターの返信は、決まり文句のパーソナリティフレーズではなく、送信者の実際のリクエストと直接的なコンテキストから始まります。架空のテキストのやり取りでは、まず送信者が何を必要としているか、何が分かっていて何が不確かなままかを明確にします。次に、返信のための短いルールをいくつか書き出し、メッセージのわずかなバリエーションに対してそれらをテストします。このプロセスにより、実在の人物のプライベートメッセージをコピーしたりその人物になりすましたりすることなく、キャラクターに一貫性を持たせることができます。
1つの創作したやり取りから始める
作り話の、ごく普通のシナリオを使用します。例えば：
> マヤ：「明日、青いフォルダーを持ってきてくれる？玄関のドアのところに置いておいたの。」 > > AIキャラクター：「もちろん、持っていくよ。」
これはこの練習のために作成された架空の例です。送信者は「フォルダーを持ってくる」という1つの具体的な行動を求めています。「明日」は時間を示し、「青い」はアイテムを特定し、玄関ドアは場所の手がかりを示しています。リクエストが理解できるほど十分に具体的であるため、受信者は直接答えることができます。返信を人間らしく聞こえさせるために、裏設定を作ったり、気分を推測したり、長い飾り言葉を付け足したりする必要はありません。
その最初の読み取りはデザイン上の解釈であり、すべての読者が推測することを証明するものではありません。Googleの会話デザインガイダンスでは、ユーザーの目的とコンテキストをインタラクションデザインの一部として扱っており、メッセージを分析する実用的な方法を提供しています。つまり、タスクとそれを取り巻く状況の両方を記録することです。Googleによる会話デザインの概要
ルールをドラフトする前に、日常的な言葉で短いメッセージブリーフを作成します：
リクエスト：青いフォルダーを持ってくること。
いつ：明日。
どこ、またはどれ：玄関のドアのところにある青いもの。
不明瞭な詳細：メッセージには明日の何時かが書かれていない。
返信が果たすべきこと：根拠のない時間や約束を付け加えることなく、その行動を確認すること。
このブリーフは、この記事における意思決定の補助となります。単一のメッセージを「アクション」「コンテキスト」「不確実性」「応答の役割」という4つのチェック項目に変換します。これにより、テキストに実際に含まれている情報と、書き手が思わず補足したくなる詳細とを区別するのに役立ちます。
リクエストとキャラクターの口調を切り離す
口調（ボイス）を加える前に、最も平易で正確な返信を書きます。「もちろん、明日青いフォルダーを持っていくよ。」この文はリクエストに対応し、キャラクターが何を理解したかを確認するのに十分な詳細を繰り返しています。その後に初めて、そのキャラクターが自然にどう表現するかを決めます。例えば「了解、明日青いフォルダー持っていくね」などです。言い回しは変わっても、タスクは変わりません。
この順序にすることで、口調は理解の代用品ではなく、キャラクターの表現となります。ウィットに富んでいたり温かみがあったりしても、行動を確認できていなければ、返信の基本的な役割を果たしていません。逆に、簡潔な確認であっても、親しみのある短縮表現や、穏やかな感嘆符、または特徴的な丁寧さの度合いを通じて、個性を十分に伝えることができます。
口調のルールは客観的に観察可能な状態にしておきます。「魅力的であること」では多くの解釈の余地が残ってしまいます。「日常的な単語を使い、手の込んだ冗談は避け、ルーチンの確認は1文にとどめる」とすれば、書き手が一貫して適用し、比較できる基準になります。W3C Web Accessibility Initiativeは、明瞭で簡潔な文章作成に関するガイダンスにおいて、文脈に適した短く明確な文と平易な言葉遣いを推奨しています。そのページはWebコンテンツを対象としているため、それを架空のテキストメッセージに適用することはデザイン上の選択であり、キャラクターの対話を規定していると主張するものではありません。
最初のドラフトを返信ルールに落とし込む
このやり取りのためのコンパクトなルールセットは、次のようになります：
まず求められている行動に答える。
理解したことを確認するのに役立つ場合は、主要なアイテムや時間を繰り返す。
ルーチンの確認には、短く自然な1文を使用する。
メッセージで確定していない時間、場所、追加の約束を捏造しない。
不足している詳細によってキャラクターが取れる行動が変わる場合は、焦点を絞った質問を1つ行う。
これらのルールは、タスク処理と口調の制約を組み合わせたものです。また、キャラクターの振る舞いをどこで止めるべきかも示しています。メッセージは「明日フォルダーを持っていく」と確認することを裏付けていますが、特定の時間に持っていくと約束したり、すでに受け取ったと主張したりすることを裏付けるものではありません。
OpenAIのプロンプト生成ドキュメントでは、タスク、制約、および期待される出力を明示することを推奨しており、意図した結果を示すためのオプションの方法として例を挙げています。ライティングの演習においては、曖昧な指示を短くテスト可能なルールセットに変え、サンプルのやり取りと組み合わせることがこれに該当します。特定の表現セットがあらゆるモデルから特定の結果を保証することを立証するものではありません。OpenAIのプロンプト生成ガイド
わずかなバリエーションを1つずつテストする
あるメッセージに適したルールが、類似した別のケースに対しては曖昧すぎたり、厳格すぎたりすることがあります。基本的なやり取りを維持し、テストごとに詳細を1つだけ変更します。これにより、どのルールが有効に機能しており、どの返信に明確化が必要かが明らかになります。
テストメッセージ：「明日、青いフォルダーを持ってきてくれる？」; 変更点：場所の手がかりを削除; 試す返信：「もちろん、明日青いフォルダーを持っていくよ。」
テストメッセージ：「明日の朝、青いフォルダーを持ってきてくれる？」; 変更点：時間を絞り込み; 試す返信：「もちろん、明日の朝持っていくよ。」
テストメッセージ：「明日、フォルダーを持ってきてくれる？」; 変更点：色を削除（どのフォルダーか不明瞭になる可能性あり）; 試す返信：「もちろん。どのフォルダーのこと？」
テストメッセージ：「青いフォルダーを持ってきてくれる？」; 変更点：日付を省略; 試す返信：「もちろん。いつ持っていけばいい？」
サンプルの返信は設計の例示であり、計測された結果ではありません。バリエーションの目的は、識別子や時間が欠落している場合にルールセットがどのように応答するかを確認することです。顧客の意図の曖昧さ解消に関するマイクロソフトのガイダンスでは、確認を入れることでユーザーが意味することを絞り込める一方で、不要な質問を避けて明確さとのバランスを取るようデザイナーにアドバイスしています。ここでは、不足している詳細が行動に影響を与える場合にのみ、的を絞った質問を行います。
複数の変更を一度に行うのは避けてください。送信者の言い回しを変え、新しい場所を追加し、キャラクターの口調も変えるということを1つのテストでまとめて行うと、なぜ答えが変わったのかを判断するのが難しくなります。シンプルなテストメモを作成し、メッセージ、テスト対象のルール、返信、およびその返信が適合する理由を記録しておくとよいでしょう。予期しない回答が出た場合は、キャラクターの性格設定をより複雑にする必要があるという証拠ではなく、ルールやサンプルを見直すためのきっかけとして捉えてください。
コンテキストを捏造せずに不確実性に対処する
送信者は相手が分かっている前提で送るため、短いメッセージでは詳細が省かれることがよくあります。この演習では、その限界を尊重する必要があります。メッセージに「そのフォルダー」と書かれていて、当てはまるフォルダーが複数ある場合、キャラクターはどれかを尋ねることができます。会話の中で1つのフォルダーだけがすでに特定されているなら、書き手はそのコンテキストを利用できます。そのようなコンテキストが存在しない場合、確実性をでっち上げると、返信はそのやり取りに不誠実なものになってしまいます。
フォールバックとハンドオフに関するマイクロソフトのガイダンスでは、理解を求める応答と、リクエストを満たせない場合に別へ誘導する応答とを区別しています。この日常の架空のシーンにおいて応用できる考え方はごく控えめなものです。キャラクターが目下の会話タスクを確実に完了できない場合は、送信者に明確な次のステップを提示します。「どのフォルダーのこと？」といった自然な確認は、不足している詳細を特定しているため、一般的な「よく分かりません」よりも役に立ちます。
また、不確かな解釈と既知の事実を区別してください。「明日フォルダーを持っていくよ」は、架空の送信者がその行動を求めており、キャラクターが同意できるのであれば明確な確認になります。「9時に持っていくよ」は、メッセージで一切提供されていない情報を付け加えています。慎重に設計された返信は、推測を黙って約束へと変えてしまってはなりません。
テスト後にルールを修正する
テストの後は、具体的な不一致を探します。詳細が重要でないにもかかわらず、キャラクターは説明を求めましたか？一度も提示されていない時間を確認してしまいましたか？口調のルールによって、わかりやすくならないまま応答が長くなってしまっていませんか？問題を説明できる最小のルールを修正し、同じバリエーションを再度実行して、その変更があるケースを修正する一方で別のケースを不自然にしていないかを確認します。
例えば、元のメッセージにすでに「明日」と書かれているのに「いつかを尋ねる」によって不要な質問が生じてしまう場合は、「日付または時間がリクエストを完了するために必要であり、かつ提示されていない場合にのみ時間を尋ねる」とルールを研ぎ澄まします。このルールは、無条件の癖ではなく、判断条件を記述しています。後からの編集を同じ少数のケースで確認できるように、テストメッセージはルールの横に残しておきます。
目指すのは、再現可能なライティング手法です。1つの架空のやり取りを用い、そのリクエストとコンテキストを特定し、返信の役割を観察可能な少数のルールに落とし込み、周辺のバリエーションをテストします。そうすることで、キャラクターの口調は会話に役立つ選択から生まれ、メッセージそのものがキャラクターの知っていることの境界線であり続けます。