翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 開始方法のベストプラクティス
<a name="getting-started-best-practices"></a>

## 会話設計の原則
<a name="conversation-design-principles"></a>

これらの会話設計原則に最初から従えば、自然なやり取りを提供する、より効果的で保守可能でユーザーフレンドリーな Amazon Lex V2 チャットボットを構築できます。

### コア設計原則
<a name="core-design-principles"></a>
+ **ユーザー目標から始める** - システムができることではなく、ユーザーが達成したいことを中心にボットを設計します。ユーザーのジャーニーと期待される成果に焦点を当てます。
+ **自然言語を使用する** - プロンプトとレスポンスを会話で書き込みます。技術的な専門用語は避け、役に立つ人間として話してください。
+ **明確なオプションを提供する** - ユーザーが行き詰まったら、一般的なヘルプテキストではなく、発言できる内容の具体的な例を提供します。
+ **Keep It Simple** - 基本的な機能から始めて、徐々に複雑さを追加します。ユーザーは一般的なタスクをすばやく完了できるはずです。
+ **エラーを適切に処理する - ボットが理解できない場合は、**「理解できない」と言うのではなく、役に立つガイダンスを提供します。
+ **重要なアクションの確認** - 注文や情報の削除など、簡単に元に戻すことができないアクションを実行する前に、必ず確認してください。
+ **エスケープルートを提供する** - 常にユーザーに、必要に応じて最初からやり直したり、ヘルプを得たり、人間とつながったりする方法を提供します。

### 会話フローのベストプラクティス
<a name="conversation-flow-best-practices"></a>
+ **明確な期待を設定する** - ボットが会話の早い段階でできることとできないことをユーザーに知らせます。
+ **プログレッシブ開示を使用する** - 複数の質問でユーザーを圧倒するのではなく、一度に 1 つずつ情報を求めます。
+ **コンテキストを提供する** - 既に収集した情報と、まだ必要なものをユーザーに再認識させます。
+ **修正を簡単にする** - ユーザーが完全にやり直すことなく情報を修正できるようにします。

## 実際のユースケースと例
<a name="real-world-use-cases"></a>

これらの実用的な例は、新しい Amazon Lex V2 ユーザーが遭遇する一般的なシナリオに会話設計原則を適用する方法を示しています。

### ユースケース 1: 予約予約
<a name="use-case-appointment-booking"></a>

**シナリオ:** メディカルオフィスが予約スケジューリングを自動化したいと考えています。

**課題:** ユーザーは複数の情報 (サービスタイプ、日付、時刻、連絡先情報) を指定する必要があり、詳細を変更したい場合があります。

**ソリューションアプローチ:**
+ **Start Broad:** 「どのような予約をしますか？」 (歯、目の検査、診察)
+ **絞り込み:** 「いつ歯の予約を希望されますか？」 (「次の週」や「金曜日の午後」などの柔軟な入力を受け入れる)
+ **変更の確認とオファー:** 「3 月 15 日金曜日の午後 2 時に歯のクリーニングを予定しました。これはうまくいきますか？」
+ **変更の処理:** ユーザーが「代わりに午後 3 時に実行できますか？」と言った場合は、プロセス全体を再起動せずに時間を更新します。

**主なテクニック:**
+ 日付/時刻の柔軟な入力[AMAZON.Time](built-in-slot-time.md)に [AMAZON.Date](built-in-slot-date.md)と を使用する
+ 予約タイプのカスタムスロットタイプを作成する
+ 準備を確定する前に確認プロンプトを使用する

### ユースケース 2: 注文ステータスの照会
<a name="use-case-order-tracking"></a>

**シナリオ:** e コマース企業は、顧客がサポートを呼び出さずに注文ステータスを確認できるようにしたいと考えています。

**課題:** ユーザーは注文番号が役に立たないか、さまざまな方法で に尋ねる場合があります。

**ソリューションアプローチ:**
+ **複数のエントリポイント:**「注文の場所」、「パッケージの追跡」、または「注文ステータス」を受け入れる
+ **柔軟な識別:** 「注文の追跡に役立ちます。注文番号をお持ちですか、または E メールアドレスを使用しますか？」
+ **役立つガイダンス:**「注文番号は通常確認 E メールにあり、「ORD-」で始まります」
+ **クリア結果:** 「注文 \$1ORD-12345 は昨日発送され、明日午後 8 時までに到着します。詳細を追跡しますか？」

**主なテクニック:**
+ 注文番号に AMAZON.AlphaNumeric などの組み込みスロットタイプを使用する
+ 注文を識別する複数の方法 (E メール、電話番号、注文番号) を提供する
+ レスポンスで明確で実用的な情報を提供する

### ユースケース 3: よくある質問とサポート
<a name="use-case-faq-support"></a>

**シナリオ:** ソフトウェア会社が、一般的なサポートの質問を自動的に処理したいと考えています。

**課題:** ユーザーはさまざまな方法で同じ質問をし、一部の問題には人間の助けが必要です。

**ソリューションアプローチ:**
+ **広範なインテント認識:** 「ログインできない」、「ログインの問題」、「パスワードが機能しない」などのバリエーションを認識するようにインテントをトレーニングする
+ **ガイド付きトラブルシューティング:** 「いくつかの簡単なステップを試してみましょう。まず、パスワードをリセットしようとしましたか？」
+ **エスカレーションパス:**「これらのステップが機能しない場合は、サポートチームに接続できます。これを行いますか？」
+ **フォローアップ:** 「これは問題を解決しましたか? 他のサポートが必要な場合は、いつでも「ヘルプ」と言うことができます。」

**主なテクニック:**
+ 多くのサンプル発話を使用して、ユーザーが問題を表現するさまざまな方法をキャプチャする
+ 長い説明ではなくstep-by-stepガイダンスを提供する
+ 自動ヘルプが不十分な場合は、常にヒューマンサポートへの道を提供する

### 複雑なシナリオの処理
<a name="handling-complex-scenarios"></a>

単純なボットでも複雑な状況に遭遇します。これらを適切に処理する方法は次のとおりです。
+ **ユーザーが考え方を変更する場合:**
  + ユーザー：「実際には、チューリップの代わりにバラが欲しい」
  + ボット: "問題なし\$1 注文をバラに更新しました。バラは金曜日の午後 2 時に集荷できるようになります。これは正しいですか？」
+ **情報が不明確である場合:**
  + ユーザー: 「来週の花が必要」
  + ボット: 「よろしくお願いします。来週のどの曜日が最適ですか? 「月曜日」や「次の火曜日」などと言うことができます。
+ **ボットが理解できない場合:**
  + ユーザー：「長い茎を持つ紫が欲しい」
  + ボット: 「これを正しく取得したい」。紫色の花をお探しですか? 紫色のバラ、紫色のチューリップ、紫色の虹彩が利用可能です。」
+ **ユーザーがやり直す必要がある場合:**
  + ユーザー：「Cancel this, I want to start over」
  + ボット: "Of course\$1 現在の注文をクリアしました。今日はどのような種類の花を注文しますか？」