Claude Messages APIの会話履歴：何を保存し、何を再送するか

再送する履歴を意図的に選ぶ

会話に必要な文脈がリクエストへ含まれるように設計します。質問だけを渡して過去の条件を覚えている前提にすると、対象文書や利用者の希望が抜けます。一方で不要な古い資料まで再送すると、費用だけでなく条件の混線も起こり得ます。

履歴を削減する場合は、確定した条件、未決事項、根拠への参照を残します。単なる短縮文を正式な業務データの代わりにせず、注文状態などはアプリ側の管理情報から取得します。

履歴と利用者を結び付ける

会話IDだけでなく、アクセスする利用者や組織の範囲を検証します。別の利用者の会話を誤って連結すると、モデルが自然に前の内容を引き継ぐため、画面の不具合だけでは済みません。履歴の読み出しも認可対象に含めます。

ツールを使う会話では、要求と結果の対応も保持します。結果だけを切り離して貼り直すと、どの操作で得た情報かが失われます。APIのメッセージ構造は公式仕様と照合してください。

並行する送信を処理する

同じ会話で利用者が二回送信すると、古い履歴を元に二つの応答が生成されることがあります。会話の版番号を使う、処理中の送信を待たせるなど、更新の衝突を扱います。モデルへの指示だけで履歴の競合を解決しないようにします。

会話の更新を状態遷移として検証する

同時送信の試験では、Aの読み出し、Bの読み出し、Aの保存、Bの保存という順序を意図的に作ります。最後に保存した文章が残ればよいという設計では、Bが古い文脈で生成したことを検出できません。読み出した履歴の版と保存時の版を比較し、衝突したときに再生成するのか、利用者へ確認するのかを決めます。モデルへ競合を解消させる前に、アプリが状態を識別します。

履歴を圧縮する処理も、どの版を基準にしたかを残します。圧縮中に新しい発言が追加された場合、その発言を落としたメモを最新として保存しないようにします。メッセージの表示順、保存順、処理の識別子を対応させることで、並行処理の不具合を会話の内容の誤りと切り分けられます。

具体例で考える

架空の会話で、送信Aの処理中に送信Bが行われました。

A：履歴版12を読む→応答候補。
B：同じ版12を読む→別の応答候補。
保存時：現在版と読み出し版を照合し、衝突を検出する。

二つを無条件に保存すると、どちらの文脈で答えたかが曖昧になります。先に完了した処理で版を進め、もう一方は再構成または確認へ回すなど、明示的な方針が必要です。

確認課題と合格の目安

二重送信と利用者の切り替えを含む会話保存の状態図を描いてください。

• 送信ごとの履歴版が分かる。
• 他人の履歴を読めない。
• 圧縮した文脈と正式な業務状態を区別できる。