LLM チャット体験を内包した AI アプリの作り方

ユースケースと成功指標から始める

モデルを選んだりチャット UI を設計したりする前に、チャット体験が「何のため」なのかを具体化してください。「LLM チャットを追加する」自体はユースケースではありません — ユーザーが求めているのはチャットではなく、結果です：回答、完了したアクション、やり取りの削減。

ユーザーの課題を明確にする

ユーザー視点で一文の問題定義を書きます。例：「5つのタブを開かずに返品ポリシーの迅速で正確な回答が欲しい」「1分以内で必要な詳細を含んだサポートチケットを作成したい」など。

チェックのコツ：その一文から「チャット」という語を外しても意味が通じるなら、実際のユーザーニーズを表現しています。

コアタスクを3〜5個選ぶ（まずはそれ以外を無視する）

初期バージョンは集中しましょう。アシスタントがエンドツーエンドで扱うべき少数のタスクを選びます。例：

• 公式ドキュメントに基づいた FAQ に回答する
• ユーザーの問題を要約してサポート返信を下書きする
• システム内の項目を作成・更新する（チケット、注文、CRM レコード）
• 返金、オンボーディング、トラブルシューティングなどのワークフローを案内する

各タスクには「完了」の状態が明確であるべきです。アシスタントがタスクを確実に終えられないと、デモのように感じられます。

測定可能な成功指標を定義する

アシスタントが機能しているかを判断する方法を決めます。ビジネス指標と品質指標を混ぜて使ってください：

• Time saved: タスク完了までの平均時間（ベースライン比）
• Resolution rate: ユーザーの目的が達成された会話の割合
• Escalation rate: ユーザーがまだ人間を必要とする頻度
• CSAT やサムズアップ/ダウン: 重要なやり取り後の簡易フィードバック
• 品質のスポットチェック: サンプリングした会話をルーブリックでレビュー

各指標に対して初期目標を設定してください。粗い目標でもプロダクト判断が容易になります。

制約を早めに列挙する（後で設計をやり直さないために）

設計を左右する境界条件を記録しておきます：

• レイテンシ: プロダクトで受け入れられる応答時間
• 予算: 会話あたり、またはアクティブユーザーあたりのコスト
• プライバシーとコンプライアンス: モデルが見たり保存したりログに残せるデータ
• 対応言語とトーン: 対象ユーザーにとっての「良し」を定義

明確なユースケース、小さなタスクリスト、測定可能な指標、制約があれば、残りの LLM チャット構築は実用的なトレードオフの連続になります。

モデルの選択：ホステッド API vs セルフホスト

適切なモデル選びは流行ではなくフィット感です：品質、速度、コスト、運用負荷。選択は UX から保守運用に至るまで全てを形作ります。

ホステッド API（マネージドモデル）

ホステッドプロバイダーは迅速な統合を可能にします：テキストを送信して返答を得るだけで、スケーリングやアップデート、ハードウェアを処理してくれます。これは多くの場合、AI アプリ開発の出発点として最適です。インフラチームにならずにLLM チャットを反復できます。

トレードオフ：スケール時にコストが高くなる可能性、データ居住性オプションの制約、サードパーティの稼働率やポリシーに依存する点。

セルフホスト / オープンモデル

自前でオープンモデルを動かすと、データ取り扱いの制御やカスタマイズ、ボリュームでの低い限界コストを得られます。オンプレや厳格なガバナンスが必要な場合に有利です。

トレードオフ：モデルのサーブ、GPU キャパシティ計画、モニタリング、アップグレード、インシデント対応などを全て自分たちで負う必要があります。スタックが未調整だとレイテンシが悪化することもあります。

コンテキストウィンドウ：実際の会話に合わせる

コンテキストを過剰に確保しないでください。典型的なメッセージ長と、どれだけの履歴や取り出したコンテンツを含めるかを見積もります。長いコンテキストは継続性を向上させますが、コストとレイテンシを上げることが多いです。多くのチャットフローでは、小さなウィンドウに適切な検索（後述）を組み合わせるほうが効率的です。

コスト、レイテンシ、品質のバランス

チャットボット UI ではレイテンシは機能です：ユーザーは遅延を即座に感じます。複雑なリクエストには高品質モデルを、日常的なタスク（要約、リライト、分類）には高速で安価なモデルを検討してください。

フォールバックモデルは初日から計画する

シンプルなルーティング戦略を設計してください：プライマリモデルと、障害・レート制限・コスト制御時のフォールバックを 1–2 個。実務では「まずプライマリを試し、必要ならダウングレードする」方式が多く、出力フォーマットを一貫させることでアプリ側が壊れないようにします。

シンプルで拡張可能なアーキテクチャ設計

表面上は「シンプル」に見えるチャット体験でも、裏のアプリは明確な境界が必要です。目的は、モデル変更、ツール追加、安全対策強化を UI を書き直さずに可能にすることです。

システムを三つのレイヤーに分割する

1) チャット UI（クライアント層）

フロントエンドは対話パターンに集中させます：ストリーミング応答、メッセージ再送、引用やツール結果の表示。モデルロジックをここに置かないで、UI の独立したリリースを可能にしてください。

2) AI サービス（API 層）

UI が /chat、/messages、/feedback に対して呼ぶ専用バックエンドサービスを作ります。このサービスは認証、レート制限、リクエスト整形（system プロンプト、フォーマット規則）を扱います。製品とモデルの間の安定した契約として扱ってください。

3) オーケストレーション層（AI サービス内、または別サービスとして）

ここが「知的」機能を保守可能にする場所です：ツール／関数呼び出し、検索（RAG）、ポリシーチェック、出力検証。オーケストレーションをモジュール化しておけば、検索、チケット作成、CRM 更新などをプロンプトと絡めずに追加できます。

プロダクト（UI + バックエンド + デプロイ）を早く回しつつ、プロンプト、ツール、RAG を反復するなら、Koder.ai のようなビブコーディングプラットフォームでチャットからフルスタックを生成し、準備ができたらソースをエクスポートするのも手です。

永続化するべきものを選ぶ（単なるメッセージ以上）

会話だけでなく、ユーザープロファイル（設定、権限）、イベント（ツール呼び出し、RAG クエリ、使用モデル、レイテンシ）も保存してください。イベントデータは後のデバッグと評価に不可欠です。

初日からオブザーバビリティを組み込む

構造化されたペイロードのメタデータ（生の機密テキストではなく）、メトリクス（レイテンシ、トークン使用量、ツールエラー率）をログに取り、UI→API→ツール間のトレースを追加します。何かが壊れたときに「どのステップが、どのユーザーで、なぜ失敗したのか」を推測せずに答えられるようにします。

プロンプトと出力の基準を作る

チャット体験が「賢く」感じられるには一貫性が必要です。プロンプトと出力の基準は、プロダクトとモデルの契約です：何が許されるか、どのように話すか、アプリが信頼して使える出力の形。

明確な system 指示を定義する

アシスタントの役割、範囲、トーンを定めた system メッセージから始めます。具体的に：

• 役割：「あなたは Acme Billing のサポートアシスタントです。」
• 範囲：「請求、支払い、プランについてのみ回答してください。無関係な質問には誘導してください。」
• トーン：「親切で簡潔、推測しない。必要なら確認の質問をする。」

全てを system に詰め込みすぎないでください。安定したポリシーや振る舞いはそこに置き、可変の内容（ユーザーデータや取得コンテキスト）は別にします。

アプリで使う出力は構造化を優先する

UI がカードやテーブル、ステータスラベルをレンダリングする必要がある場合、自然言語だけでは壊れやすくなります。アプリが決定論的に解析できるように、JSON スキーマなどの構造化出力を使ってください。

例：応答は次のような形を目標にします（コード風に示すと）：

{'answer': string, 'next_steps': string[], 'citations': [{'title': string, 'url': string}]}

最初は厳密にバリデートしなくても、目標スキーマがあると驚きが減ります。

ガードレール：拒否とリダイレクト挙動を追加する

アシスタントが拒否すべきこと、確認すべきこと、提案できることを明示します。安全なデフォルトを含めてください：

• 必要な情報が欠けているときは確認の質問をする。
• 機密データや許可されないリクエストには拒否し、安全な代替を提示する。
• 不確かならその旨を伝え、検証手順を提案する。

スロット付きのプロンプトテンプレートを作る

毎回同じ構造になるテンプレートを使うと、プロンプトのデバッグや評価が容易になります：

• System: 指示とポリシー
• User: ユーザーのメッセージ
• Context: 関連する事実（必要最低限）
• Tools: 利用可能なアクションと制約

この分離はプロンプトの進化をプロダクトに影響させずに行えます。

実際のアクションのためのツールと関数呼び出しを追加する

チャットが本当に役立つのは「行動できる」時です：チケット作成、注文照会、予定調整、メール下書きなど。モデルにアクションを提案させ、実際に実行するのはバックエンドに任せるのが鍵です。

AI がトリガーできる操作を決める

まずは厳格で明示的なアクションのリストから始めます。例：

• 社内ナレッジの検索（読み取り専用）
• アカウントや注文ステータスの取得（読み取り専用、スコープ限定）
• サポートチケットや CRM メモの作成
• 下書きコンテンツの作成（メール、告知、チェックリスト）
• 予定の作成・再調整（制約あり）
• 返金／クレジットリクエストの開始（自動承認は絶対にしない）

お金、アクセス、データ可視性を変更する操作はデフォルトで「リスキー」と扱ってください。

信頼性のために関数呼び出しを使う

モデルに「API リクエストを書かせる」代わりに、get_order_status(order_id) や create_ticket(subject, details) のような少数のツール（関数）を公開します。モデルはツールと構造化された引数を選び、サーバーがそれを実行して結果を返し会話を継続します。

これによりエラーが減り、挙動が予測可能になり、実行ログが明確になります。

サーバー側で検証と認可を行う

ツールの引数を直接信頼してはいけません。各呼び出しで：

• 入力を検証する（型、フォーマット、必須フィールド、範囲）
• 権限を適用する（誰がどの顧客／テナントに何をできるか）
• レート制限と冪等性を適用する（重複アクションを避ける）

モデルは「提案」し、バックエンドが「検証」するべきです。

リスキーな操作には確認を追加する

取り消し不能または影響が大きい手順には、人間向けの確認を挟みます：何が起こるか、どのデータが影響を受けるかを短くまとめて「確認／キャンセル」の明確な選択肢を出します。例：「注文 #1842 に対して $50 のクレジットを申請します。よろしいですか？」

検索（RAG）でデータを接続する

製品、方針、顧客履歴に関する質問に答える必要があるなら、すべてをプロンプトに焼き込んだりモデルの一般的学習に頼ったりしないでください。RAG（Retrieval-Augmented Generation）を使うと、ランタイムで自社のコンテンツから最も関連するスニペットを取得し、LLM がそのコンテキストを使って回答します。

何を検索して何をハードコードするかを決める

実用的な分け方の例：

• ハードコード：トーン、拒否ルール、フォーマット、常に真である事実（例：サポート時間）
• 検索：変更頻度が高い、あるいはプロンプトに収まりきらない大きなコンテンツ（ヘルプドキュメント、社内ウィキ、リリースノート、料金表、契約、FAQ）

これによりプロンプトがシンプルになり、アシスタントが自信満々に誤るリスクが減ります。

高品質な検索のためにドキュメントを準備する

RAG の品質は前処理に大きく依存します：

• テキストのクリーン化： ナビゲーション、クッキーバナー、繰り返しのフッター、壊れた OCR を除去する。
• チャンク化： 意味のある小さな単位（通常数段落）に分割する。チャンクが大きすぎると関連性が希釈され、小さすぎると文脈を失う。
• メタデータ： ソース URL/パス、プロダクト領域、バージョン/日付、オーディエンス、アクセスレベルなどを持たせる。メタデータはフィルタリング（例：「v2 のドキュメントのみ」）に役立つ。

埋め込みモデルとベクトルストアを選ぶ

各チャンクに対して埋め込みを生成し、ベクターデータベース（またはベクトル対応検索エンジン）に保存します。言語やドメインに合った埋め込みモデルを選び、スケールと制約に合ったストレージ方式を選んでください：

• まずは管理されたベクトルストアで簡単に始める。
• 厳格なデータコントロールや性能調整が必要ならセルフホストに移行する。

ユーザーが信頼できる引用を設計する

RAG の回答は検証可能であるほど信頼されます。回答に引用を添えて、ドキュメントタイトルと短い抜粋を示し、ソースへリンクする（相対パス例：/docs/refunds）。リンクできないプライベートドキュメントなら「Policy: Refunds v3, updated 2025-09-01」のように明確なソースラベルを表示します。

RAG をうまく使えば、LLM チャットは根拠のあるアシスタントになります：役立ち、最新かつ監査しやすい。

会話のメモリとパーソナライゼーション

メモリは LLM チャットを一回限りの Q&A ではなく継続的な関係に感じさせます。ただしコストが増えたり保存すべきでないデータを溜めたりするリスクもあります。シンプルに始め、ユースケースに合った戦略を選んでください。

メモリ戦略を選ぶ

多くのアプリは次のいずれかに当てはまります：

• メモリなし： 各メッセージを独立で扱う。敏感なトピックや単発タスクに最適。
• 短期メモリ（セッション）： アクティブなチャット中の最近のターン（または要約）を保持。デフォルトとして優秀。
• 長期プロファイル： トーン、タイムゾーン、プラン、呼称（「Alex と呼んで」）などの安定した好みを保存。パーソナライズに有用だが管理を厳格にする必要あり。

実用的なアプローチは「短期の要約 + 任意の長期プロファイル」で、フルトランスクリプトをずっと持ち歩かずにコンテキスト感を保ちます。

必要なものだけを保存する（デフォルトで敏感データを避ける）

何を永続化するかを明示してください。生のトランスクリプトを「念のため」保存しないでください。構造化フィールド（例：優先言語）を好み、認証情報、健康情報、支払いデータなど正当化できないものは収集しないでください。

メモリを保存するなら、運用ログと分離し保持期間ルールを設定してください。

古いターンを要約してトークンコストを削る

会話が長くなるとトークン使用量（とレイテンシ）が増えます。古いメッセージを次のような簡潔なノートに要約します：

• ユーザーの目標
• 下した決定
• 制約や好み
• 未解決の質問

最新数ターンと要約だけを残す方式が有効です。

ユーザーにコントロールを与える

UI に次のような明確な操作を追加します：

• チャットをクリア（セッションメモリを終了）
• 履歴を削除（保存データを消去）
• データをエクスポート（信頼構築、サポートに有用）

これらの小さな機能は安全性、準拠、ユーザー信頼を大きく改善します。

チャット UI とインタラクションパターンを作る

良い LLM チャット体験は主に UX の問題です。インターフェースが不明瞭だったり遅かったりすると、モデルが正しくてもユーザーは回答を信用しません。

コアなチャット UI：基本を明確にする

シンプルなレイアウトから始めてください：明確な入力ボックス、見える送信ボタン、読みやすいメッセージ表示。

メッセージ状態を含めて、常に状況が分かるようにします：

• Sending…（送信中）
• Streaming…（アシスタントが入力中）
• Done（最終回答）
• Failed（再試行が必要）

タイムスタンプ（少なくともメッセージグループ単位）や長い会話用の区切りを加えると、後で見返したときに変化を把握しやすくなります。

ストリーミング応答：ユーザーが体感する速度

総生成時間が同じでも、トークンをストリーミングするとアプリは速く感じられます。即座に入力インジケータを出して、到着するたびに応答をストリーミングしてください。さらに「生成を停止」できると、特に回答が外れたときにユーザーがコントロールを感じます。

ガイドは助けになるが邪魔にならないように

多くのユーザーは何を尋ねればいいか分かりません。軽量のヘルパーは成功率を上げます：

• 入力下の推奨プロンプト（例：「要約する」「返信を下書き」「アクション項目を抽出」）
• メッセージのクイックアクション（コピー、再生成、短くする、詳細）
• ドキュメントが有用な場合のファイルアップロード—アップロード進捗を表示し、受信内容を確認する（ファイル名、サイズ、ページ数）

エラーハンドリング：怖くない、穏やかな表示

障害（ネットワーク切断、レート制限、ツールエラー）は発生します。フレンドリーで具体的なメッセージ（「接続が切れました。再試行しますか？」）を使い、ワンクリック再試行と下書きを保持してください。長いリクエストには明確なタイムアウトを設定し、その後は「再試行」「プロンプト編集」「新しいスレッド開始」などの選択肢を提示します。

セーフティ、セキュリティ、ポリシー制御

チャット可能なアプリは悪用や攻撃を受けやすいです。セーフティとセキュリティは「あると良いもの」ではなくプロダクト要件です。目的はシンプル：有害な出力を防ぎ、ユーザーと企業データを保護し、濫用下でもシステムを安定させること。

リスクの高いリクエストに対するポリシーチェック

アプリが拒否すべきもの、制約付きで答えるもの、ハンドオフが必要なものを定義します。一般的なカテゴリ：自傷、医療／法律／金融助言、憎悪／嫌がらせ、性的コンテンツ（特に未成年含む場合）、マルウェア生成やセキュリティ回避の要求など。

生成前（場合により生成後にも）軽量なモデレーションステップを実装してください。敏感トピックでは安全モードに切り替え：高水準の情報提供、専門家への相談を促し、手順の詳細を避けます。

プロンプトインジェクションとデータ漏洩を減らす

取得ドキュメントやユーザーメッセージが悪意のある命令を含む可能性を常に想定してください。次の区分を厳格に保ちます：

• System 指示（変更不能のルール）
• ツール出力／取得コンテンツ（未検証の証拠として扱う）
• ユーザー要求

実装上は取得テキストを参照テキストとして明確にラベル付けし、指示レイヤーに混ぜ込まないでください。ログからは機密情報を削除し、API キーをプロンプトに入れないでください。

濫用防止：認証、制限、監視

プライベートデータや課金リソースに触れる操作には認証を必須にします。ユーザー／IP ごとのレート制限、スクレイピング検出の異常検知、ツール呼び出しのハードキャップを設定してコスト暴走を防いでください。

ユーザー報告と人間によるエスカレーション

チャット UI に目立つ**「回答を報告」**ボタンを追加してください。報告はレビューキューに送られ、会話コンテキスト（PII を最小化）を添えて高リスク事例や繰り返しのポリシー違反は人間オペレーターにエスカレーションされる流れを作ります。

出荷前にテストと評価を行う

LLM チャット体験を見た目だけで判断してユーザーに出すのは危険です。ローンチ前に評価を品質ゲートとして扱い、「良い」を定義して繰り返し測定し、リグレッションはリリースをブロックしてください。

実際に近いテストセットを作る

小さくても代表的な会話のテストセットを作成します。典型的なハッピーパス、乱れたユーザーメッセージ、あいまいなリクエスト、エッジケース（未対応機能、欠けたデータ、ポリシー違反プロンプト）を含め、それぞれに期待される結果を添えます：理想的な回答、引用すべきソース（RAG 使用時）、拒否すべき場合の判定など。

明確な指標で品質を測る

ユーザー信頼に結び付くいくつかのコアメトリクスを追います：

• Accuracy: シナリオに対して正しく答えられているか
• Groundedness: 主張が取得データで裏付けられているか、推測か
• Refusal correctness: 拒否すべき場合に明確かつ安全に拒否しているか（過度に厳しくないかも含む）

簡単なレビュールーブリック（1–5 点＋短い理由）でも非公式なフィードバックより遥かに優れます。

ツール呼び出しをエンドツーエンドで検証する

ボットがアクションを取るなら、ツール呼び出しも API エンドポイント同様に厳密にテストします：

• 正しいパラメータ（型、必須フィールド、単位）が送られているか
• 再試行と部分失敗を検証する
• 冪等性を担保して注文やチケットが重複しないようにする

監査できるようにツール入力／出力をログに残してください。

コントロールされた実験を行う

プロンプトや UI の変更は推測で出すのではなく A/B テストで検証します。まず固定のテストセットで比較し、安全なら実運用で小さなトラフィック割合に対して試験します。成果は成功指標（タスク完了率、解決までの時間、エスカレーション率）に結びつけて評価してください。

コスト、レイテンシ、信頼性の管理

プロトタイプでは無料に感じられたチャットが、本番で請求額や遅延、断続的な障害で驚かせることがあります。コスト、速度、稼働率をプロダクト要件として扱ってください。

支出を予測して制御する

会話あたりのトークン使用量を見積もります：平均ユーザーメッセージ長、送るコンテキスト量、典型的な出力長、ツールや検索呼び出し頻度。期待される日次チャット数を掛けて基準を作り、アラートとハードリミットを設定してアカウントが暴走しないようにします。

実用的なトリック：高コスト要素をまず制限する。

• 最大コンテキストサイズ（常に全文を送らない）
• 最大回答長（多くのユーザーは簡潔な回答を好む）
• ターンごとの最大ツール呼び出し数（ループやツールスパムを防ぐ）

品質を落とさずレイテンシを下げる

レイテンシの主因は (1) モデル生成時間 と (2) ツール／データソース待ちです。両方を削減できます：

• よくある質問や繰り返しの検索結果はキャッシュする。キャッシュキーは正規化された意図＋ユーザーセグメントに基づくべきで、生テキスト単独ではない。
• 可能な処理を並列化する：検索と軽いチェックを同時に走らせ、最終回答を合成する。
• プロンプトを簡潔に保つ。余分な指示や長い履歴はトークンと応答時間を増やす。

モデルルーティングを使う

全てのメッセージが最大モデルを必要とするわけではありません。ルーティングルール（または小さな分類器）で、単純なタスク（FAQ、フォーマット、単純抽出）は小さな安価なモデル、複雑な推論や多段階計画、敏感会話は大型モデルに回すと、コストも速度も改善します。

本格的なサービスとして信頼性を設計する

LLM とツール呼び出しは時々失敗します。備えをしてください：

• ツールリクエストのタイムアウトとバックオフ付き再試行
• フォールバック（代替モデル、単純回答、または「もう一度試します」UX）
• 依存先が不安定な場合のサーキットブレーカー
• 部分障害時の明確な回答（「カレンダーに接続できませんでした。再試行しますか？」）

これらをうまくやれば、ユーザーは高速で安定したアシスタント体験を得られ、あなたは予測可能なコストでスケールできます。

デプロイ、監視、そして継続的改善

LLM チャットを出荷するのは始まりに過ぎません。ユーザーが本番で使うと新たな失敗モードやコスト、改善の機会が見つかります。プロンプトを締め、検索コンテンツを改善してアシスタントをより賢く感じさせてください。

ユーザーが感じること（と壊れる箇所）を監視する

技術的信号を UX に結びつける監視を設定します。最低限、レイテンシ（p50/p95）、エラー率、失敗カテゴリ（モデルタイムアウト、ツール／関数呼び出し失敗、検索ミス、UI 配信問題）を追跡してください。

役立つパターンとして、メッセージごとに構造化イベントを 1 つ出し、次のようなフィールドを含めます：モデル名／バージョン、トークン数、ツール呼び出し（名前＋ステータス）、検索統計（返されたドキュメント数、スコア）、ユーザーに見える結果（成功／放棄／エスカレーション）。

プロンプトと出力を安全にログする

デバッグや改善のために例を残したいですが、責任を持って保存してください。プロンプトとモデル出力は自動的に機密フィールド（メール、電話番号、住所、支払い情報、アクセストークン）を赤線でマスキングしてログし、生のテキストアクセスは限定的かつ時間制限付きにします。

会話を再生する必要がある場合は、サニタイズ済みトランスクリプトと機密コンテンツの別途暗号化されたブロブを保持し、大部分のワークフローが生データに触れないようにします。

タイトなフィードバックループを作る

UI に軽量のフィードバックコントロール（サムズアップ/ダウン＋任意コメント）を追加し、ネガティブフィードバックを次の内容付きでレビューキューに送ります：

• サニタイズ済みトランスクリプト
• 取得された抜粋（RAG 使用時）
• ツール呼び出しトレースとエラー

そして改善に繋げます：プロンプト修正、検索ソースの追加、同じ問題が回帰しないようターゲットテストを作成します。

変化を伝える：ロードマップと期待値

LLM の振る舞いは進化します。改善予定（精度、対応アクション、言語、統合）を公開し、どこが次に良くなるかをユーザーに知らせてください。プランによって機能差があるなら（高いレート上限、長い履歴、プレミアムモデルなど）/pricing への案内を示し、プロダクト内でその制限を明示してください。

短期間で出荷しつつ将来カスタムスタックに「卒業」するオプションを残したい場合、初期バージョンを Koder.ai 上で構築し（ソースエクスポート、スナップショット／ロールバック付き）、使用量が増えたら評価・安全対策・観測性を強化していく方法が現実的です。