判断・計画の層は、何を担う？
判断・計画の層では、依頼と現在の状況から、次に必要な行動を選びます。問い合わせを分類する、参照資料を探す、使うツールを選ぶ、といった場面でLLMを利用できます。LLMの出力は、事実や操作の成功を保証するものではありません。
最初の計画を最後まで押し通すのではなく、ツールの結果や新しい情報に応じて、進む・追加で調べる・人に戻す、を選び直します。金額計算など正確さが必要な処理は、コードや業務ルールに委ねる構成が考えられます。
設計する項目を、具体的に。
| 項目 | 考えること | 説明用の例 |
|---|---|---|
| 観察 | 今、何が分かっているか | 商品は特定できたが、数量が不明 |
| 選択 | 次にどの手段を使うか | 計算に進まず、数量を確認する |
| 実行依頼 | どの条件でツールを呼ぶか | 確認済みの商品IDと数量を渡す |
| 見直し | 結果を受けてどう進めるか | 取得失敗なら再確認し、無限に繰り返さない |
実務では、ここを考える。
ワークフローと、使い分ける
順序が安定している仕事は、決められた手順に沿うワークフローに向いています。入力や途中結果で進め方を変える必要がある部分に、エージェントの判断を置きます。全部を自由な判断にする必要はありません。
行動の理由を、確認できる情報にする
利用者には、選択した操作、参照した資料、不足条件、検査結果を示します。モデルの内部的な思考の全文ではなく、担当者がその行動を承認・検証するために必要な根拠を残します。
試行回数と費用に上限を持つ
目的に届かない状態でツールを呼び続けると、費用と操作回数だけが増えます。試行回数、実行時間、利用量の上限を設け、上限時は担当者に状況を返します。
つまずきやすい点
モデルが「おそらくこの金額」と答えたことと、台帳で確認できたことは別です。もっともらしい文章を根拠として、計算・送信・登録へ進めないようにします。
見積下書きの例で見る。
サービスAを2件、見積もる仕事を例にします。以下は仕組みを説明するための架空の条件・金額で、ROの料金表やAPIの実行結果ではありません。
OBSERVE商品はサービスA、数量は2件と確認済み。
SELECT商品台帳を取得し、ルールに沿って計算する。
REPLAN商品台帳が取得できなければ、金額を推測せず確認に戻る。
導入前に確かめたいこと。
- 決めた手順で足りる部分を切り分けている
- 参照元と行動の選択結果を確認できる
- 不足情報を推測で埋めず、確認に戻れる
- 再試行回数・実行時間・費用の上限がある
選んだ行動を現実のシステムへつなぐのが、実行の層です。
実装例と、説明用の整理を分けて見る。
RO_APIの紹介では、見積下書きの生成・検査・承認など、ローカルデモで確認した範囲を示しています。実装状況は、各担当業務の紹介をご覧ください。
RO_APIの実装・検証範囲へ