LLMを組み込む計画は、モデルに何を聞くかから始まりがちだ。 けれど実装で詰まるのは、たいていその後に起きる。 返答を画面に出すだけなのか、データとして保存するのか、別のサービスを動かすのか。 この差を曖昧にしたままプロンプトだけを育てると、機能の境界が後から崩れる。
LLMは、もっともらしい文章を返す部品として見るより、条件付きで出力を提案する部品として扱うほうが設計しやすい。 提案をどこまで採用し、どこから先をアプリケーション側のルールに戻すか。 その線を先に引く。
出力がどこへ届くかで、必要な設計は変わる#
LLM機能は、出力先で大きく三つに分けられる。
- 会話の返答：利用者が読み、次の入力を決めるための文章
- 構造化されたデータ：分類、候補、要約などをアプリケーションが受け取るための値
- 外部へのアクション：検索、登録、通知など、別の処理を始めるための指示
会話の返答では、読みやすさと不確実性の伝え方が中心になる。 一方で構造化データや外部アクションでは、流暢な文章よりも、値の形式と検証が先に来る。 たとえば「問い合わせを緊急として扱うか」をモデルに判断させる場合、画面用の説明文と、処理を分けるための判定値は別に持ったほうがよい。 前者は利用者の理解を助けるが、後者は業務の分岐を決めるからだ。
入力に含める事実を、用途ごとに絞る#
モデルへ渡せる情報が増えるほど、判断は賢くなるように見える。 しかし、関係のない履歴や古い状態まで混ぜると、理由を追えない出力が増える。
入力には、少なくとも次の四つを区別して持たせる。
- 依頼：利用者が今してほしいこと
- 前提：判断に必要な事実や制約
- 許容範囲：出してよい形式、長さ、対象外の内容
- 根拠：回答に使ってよい資料やデータ
この分け方をしておくと、出力がおかしいときに「依頼の解釈」「前提データ」「出力形式」のどこを見直すかが分かる。 プロンプトを長くして直す前に、入力の役割を点検したい。
構造化出力は、アプリケーション側で検証する#
JSONや関数呼び出しの形式を使っても、返ってきた値をそのまま信じるわけにはいかない。 必須項目が欠ける、列挙値にない分類が混じる、日付の意味を取り違える、といった失敗は残る。
アプリケーション側では、受け取った値を型と業務ルールで検証する。 検証に通らなければ、再試行、追加質問、人による確認のいずれかへ戻す。 モデルに事実の最終判定まで背負わせるのではなく、候補を整える役割にとどめると、失敗したときの動きも説明しやすい。
外部アクションには、人が止められる場所を置く#
検索や下書きの作成なら、誤った選択肢が出てもやり直せる。 送信、更新、削除のように後戻りしにくい操作は別だ。
外部アクションへ進む前に、対象、変更内容、実行理由を表示し、利用者が取り消せるようにする。 自動実行が必要な場合でも、操作履歴と失敗時の通知を残す。 モデルが決めたことより、誰が何を実行したかを追えることが、運用では効いてくる。
小さなケースで、失敗の形を先に集める#
最初から万能なエージェントを作る必要はない。 実際に起きそうな依頼を少数選び、期待する出力と、出してはいけない出力を並べる。
たとえば、情報が不足している依頼、複数の解釈がある依頼、権限のない操作を求める依頼は、初期から確認したいケースになる。 このときに残るのは、モデルの賢さを測るための問題集ではない。 機能がどこまで責任を持つかを、チームで共有するための仕様である。
LLM機能は、答えを一度返せれば完成ではない。 入力が欠けたとき、値が壊れたとき、アクションを止めるべきときにどう振る舞うかまで決めて、初めて利用者に任せられる機能になる。