「ハンバーガー店」のルールファイル（bedrock_rules_hamburger_pro）を優れた見本として、ルール設定のポイントを改めて解説します。
「正しい」形式とは「誰が読んでも理解しやすく、メンテナンスが容易で、拡張性の高い構造」になっておりMarkdown記載でも問題はない。
正しいルールファイルを書くための重要なポイントは以下の通りです。
1. 処理の流れ（フロー）を明確に定義する
まず最初に、ユーザーからの質問がどのような順序で処理されるのかを定義します。これにより、ルール全体の骨格が明確になります。
良い例（ハンバーガー店のルールファイルより）:
1. Phase 1: ガードレール（入力フィルタリング）
2. Phase 2: インテント分類
3. Phase 3: エンティティ抽出とAPIマッピング
4. Phase 4: 実行とレスポンスハンドリング
5. Phase 5: フォールバックこのように段階（Phase）を分けることで、「まず不適切な質問を弾き、次にお客様かスタッフかを分類し…」という論理的な流れが非常に分かりやすくなります。
2. 「インテント（意図）」中心で考える
単純なキーワードのマッチングだけでなく、「ユーザーが最終的に何をしたいのか」というインテント（Intent）を定義することが最も重要です。
良い例（ハンバーガー店のルールファイルより）:
- インテント
Inquiry（店舗・メニューに関する問い合わせ）: ユーザー（お客様）は「お店やメニューの情報」を知りたい。 - インテント
Internal_Report（内部データ確認）: ユーザー（スタッフ）は「売上や在庫などの内部情報」を知りたい。
このように大まかな目的を定義することで、新しい言い回しや質問が増えても、どちらのインテントに属するかを判断するだけで済むため、ルールが破綻しにくくなります。
3. 「エンティティ（対象）」を明確にする
ユーザーの意図（インテント）が分かったら、次はその意図が「何に対して」向けられているのか（エンティティ）を定義します。
良い例（ハンバーガー店のルールファイルより）:
Store_Info: 営業や場所など、店舗の基本情報について知りたい。Menu_Item: 特定のハンバーガーについて知りたい。Sales_Data: 売上について知りたい。
4. インテントとエンティティの組み合わせでAPIを決める
最終的に呼び出すAPIは、「どのインテント」で「どのエンティティ」が指定されたかの組み合わせで決定します。これにより、ルールが非常に整理されます。
良い例（ハンバーガー店のAPIルーティング定義より）:
Inquiry（問い合わせ） +Store_Info（店舗情報） →/storeInfoAPIを呼び出すInternal_Report（内部データ） +Sales_Data（売上） →/reports/salesAPIを呼び出す
5. 正常系以外のルール（フォールバック）を必ず書く
ルールに合致しなかった場合や、情報が足りない場合にどう振る舞うかを定義しておくことで、システムが停止したり、ユーザーを混乱させたりするのを防ぎます。
良い例（ハンバーガー店のルールファイルより）:
- パラメータ不足時のエラーメッセージ:
予約時間不足なら「ご予約ですね。ご希望の日時と人数を教えていただけますか？」と具体的に聞き返す。 - 不明瞭なインテントの解決: どのルールにも合致しない場合に、ユーザーに「例：「営業時間を教えて」「予約したい」など」と例を挙げて対話を促す。
まとめ
Bedrock KnowledgeBaseのインテントルーティングは、このハンバーガー店のルールファイルのように、
- 処理フローの明確化
- インテント（意図）ベースの設計
- エンティティ（対象）の抽出
- インテントとエンティティの組み合わせによるAPI決定
- フォールバック（エラー処理）の定義
という構造で書くのが、最も堅牢な形式と言えます。この形式は、どんな業種であってもルールの可読性、保守性、拡張性を大きく向上させます。
コメント