記憶・状態の層は、何を担う？
記憶・状態の層は、エージェントが必要な情報を継続して扱うための仕組みです。直前の会話、社内文書や商品台帳、処理の進行状態は、それぞれ役割が異なります。すべてを会話履歴に詰め込むと、何が現在の正しい情報かが曖昧になります。
情報を保存しただけで、モデルそのものが自動的に再学習するわけではありません。保存先から必要な情報を取得し、現在の処理へ渡す仕組みと、アクセス制御・更新・削除の運用を設計します。
設計する項目を、具体的に。
| 項目 | 考えること | 説明用の例 |
|---|---|---|
| 会話・作業文脈 | 今回の依頼に必要な情報 | 確認済みの数量や利用者の条件 |
| 参照する知識 | 根拠となる業務データ | 商品台帳、規程、手順書とその版 |
| 進捗・状態 | 仕事がどこまで進んだか | 処理中、確認待ち、完了、失敗 |
| 証跡 | 後から確かめるための情報 | 操作履歴、成果物ID、参照した版 |
実務では、ここを考える。
RAGと業務の進捗管理を混同しない
RAGは、外部の情報を検索して回答や判断の文脈へ渡すための方法です。一方、処理中か、承認済みか、送信済みかは業務状態です。検索結果から推測せず、状態を管理する仕組みで確認します。
古い情報を、今の根拠にしない
単価や規程は更新されます。参照元、更新日時、版を持たせ、成果物をどの版で作ったか追跡できるようにします。重要な条件が変わったら再検査や再承認を行います。
必要な情報だけを、必要な期間残す
顧客情報や会話履歴を無制限に保存する設計は避けます。保存目的、閲覧権限、保持期間、削除方法を決め、別の利用者や案件の情報が混ざらないようにします。
つまずきやすい点
「前の会話で承認した気がする」を、現在の下書きの承認として扱うと、変更後の版がそのまま送信されるおそれがあります。承認は、対象の成果物と版に対応づけて記録します。
見積下書きの例で見る。
サービスAを2件、見積もる仕事を例にします。以下は仕組みを説明するための架空の条件・金額で、ROの料金表やAPIの実行結果ではありません。
KNOWLEDGE商品台帳 v3：単価・税率の根拠。
STATE依頼A：下書き v1／確認待ち。
RESUME再開時は状態と保存済み成果物を確認し、最初から作り直さない。
導入前に確かめたいこと。
- 会話・知識・進捗・証跡を区別している
- 参照情報と成果物の版を追跡できる
- 中断後に処理済みの仕事を識別できる
- 保存目的・閲覧権限・保持期間・削除手順を決めている
記録した情報を使って、正しく止め、検査し、復旧する仕組みを見ます。
実装例と、説明用の整理を分けて見る。
RO_APIの紹介では、見積下書きの生成・検査・承認など、ローカルデモで確認した範囲を示しています。実装状況は、各担当業務の紹介をご覧ください。
RO_APIの実装・検証範囲へ