実行の層は、何を担う？
LLMが文章を生成することと、業務システムに変更を加えることは異なります。実行の層では、モデルが選んだ操作を、APIやブラウザなどのツールへ渡します。どの操作を許可するか、入力が正しいかは、実装側でも検査します。
ブラウザ操作は画面の変更に影響され、APIでもタイムアウトや部分的な成功が起こり得ます。呼び出しが終わっただけで完了とせず、保存されたデータや成果物を読み返して結果を確認します。
設計する項目を、具体的に。
| 項目 | 考えること | 説明用の例 |
|---|---|---|
| 読む | 情報取得を行う | 権限のある商品台帳を取得 |
| 作る・変える | データや成果物を作成する | 見積下書きを保存 |
| 送る・公開する | 外部への影響がある操作 | 承認した版を指定して送信 |
| 確かめる | 実際の結果を確認する | 保存ID・内容・版を読み返す |
実務では、ここを考える。
小さく、意味が分かるツールにする
何でも操作できる権限を一度に渡すより、商品を読む、下書きを保存する、承認済み成果物を取得する、といった責務に分けます。入力形式・戻り値・失敗条件を明確にします。
同じ依頼の再試行で、二重処理しない
タイムアウト時には、処理が実行済みか分からないことがあります。再実行の前に状態を確認し、同じ依頼を識別するキーや重複検査を使って、二重登録・二重送信を避ける設計にします。
読取権限と変更権限を分ける
情報を取得するために、管理者としての全面的な権限を渡す必要はありません。読み取り、下書きの作成、外部送信などを分け、必要な範囲の認証・権限で実行します。
つまずきやすい点
「送信しました」というモデルの応答があっても、送信APIが失敗している可能性があります。ツールの戻り値、送信先、保存ID、実際の状態を確認し、未確認なら未確認と伝えます。
見積下書きの例で見る。
サービスAを2件、見積もる仕事を例にします。以下は仕組みを説明するための架空の条件・金額で、ROの料金表やAPIの実行結果ではありません。
READ商品台帳 v3から単価10,000円・税率10%を取得する。
CALCULATE数量2件：小計20,000円、税2,000円、合計22,000円。
VERIFY保存した下書きの金額・数量・参照した版を読み返す。
導入前に確かめたいこと。
- ツールごとに入力形式と操作範囲を定義している
- 権限と入力を実装側で検査している
- 再試行時に処理済みか確認できる
- 実行結果と実際の保存・送信状態を照合できる
操作の途中経過と参照情報を支える、記憶・状態の層へ進みます。
実装例と、説明用の整理を分けて見る。
RO_APIの紹介では、見積下書きの生成・検査・承認など、ローカルデモで確認した範囲を示しています。実装状況は、各担当業務の紹介をご覧ください。
RO_APIの実装・検証範囲へ