何が変わったか
LLM 0.32rc1 は、0.32a0 から進めてきたデータベーススキーマの刷新を完了させたリリース候補版です。狙いは、最新のモデルファミリーが返すプロンプトとレスポンスの詳細を、これまでより正確に記録できるようにすること。あわせて gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna の3モデルへの対応が入りました。
変更は新テーブルの追加という形を取り、古いデータには影響しないとされています。ただしリリース候補版へのアップグレード前には llm logs backup logs-backup.db で既存の logs.db をバックアップしておくことが推奨されています。
最重要は「ハッシュIDによるメッセージ管理」
今回の中心は、保存されるメッセージにコンテンツアドレッサブルなハッシュIDを使う点です。メッセージの中身そのものからIDを導くため、同一内容のメッセージはデータベース上で1つにまとまり、重複が排除されます。さらに、分岐した会話（フォークされた会話）をメッセージの木構造として表現できるようになります。
この2つは別々の機能に見えて、実は同じ設計から出てきます。内容が同じなら同じIDになる以上、複数の会話が同じ前半部分を共有していても実体は1つで済み、そこから枝分かれした先だけが別ノードになる。Git がコミットをハッシュで指し、履歴を木として持つのと同じ発想です。
なぜこの設計が効いてくるのか
LLM の利用実態は、いま「1回聞いて終わり」から「同じ長い文脈を何度も使い回し、途中から条件を変えて試す」方向へ移っています。プロンプトを少しだけ変えて比較する、システムプロンプトを共通にして複数の分岐を走らせる——こうした使い方では、素朴な「会話＝1本の直線」というデータモデルは急速に破綻します。同じ前半を何十回も保存し直すことになり、しかも「どの実行がどの分岐に属するのか」を後から追えません。
ハッシュIDと木構造は、この2つの問題に同時に答えます。保存容量の話に見えて、本質は「実験の系譜をたどれるようにする」ことです。どの分岐点でどう振る舞いが変わったかを、あとから機械的に比較できる形で残せる。ログを単なる記録から、検証可能な資産に変える設計変更だと捉えるのが妥当でしょう。
モデル追加の位置づけ
gpt-5.6-sol / terra / luna の3モデル対応は、機能面では並列に扱われる小さな追加項目です。ただし、スキーマ刷新の目的が「最新モデルファミリーが返す詳細をより良く捉えること」である以上、新スキーマと新モデル対応は同じ流れの上にあります。モデル側が返す情報が豊かになるほど、それを受け止める器の設計が問われる、という順序です。
💼 事業会社視点：これは自社にどう効くか
実務上のポイントは3つあります。第一に、社内でLLMを触っているチームが logs.db を持っているなら、リリース候補版へ上げる前に llm logs backup logs-backup.db を回すルールを明文化してください。新テーブル追加のみで既存データに影響しない設計とはいえ、RC段階での検証は自己責任です。
第二に、受託開発やSaaS事業者にとって重要なのは「プロンプト実行ログをどう保存するか」という設計判断そのものです。LLMが採るハッシュID＋木構造は、同一文脈の重複排除と分岐の追跡を一度に解く型として、自社の内製ログ基盤にそのまま借用できます。プロンプトを1レコード1行のテキストで積み上げているだけの実装は、A/B比較や再現検証の段階で必ず行き詰まります。
第三に、経営判断としては「プロンプト資産の棚卸し」を今のうちに始めるべきです。どのプロンプトが誰の手で何回書き換えられ、どの分岐が採用されたのか。この系譜が残っていない企業は、担当者の退職と同時にノウハウを失います。ECのレコメンド文言生成やカスタマーサポートの応答テンプレートのように、日々改善が積み上がる領域ほど影響は大きくなります。ログ設計は情シスの技術課題ではなく、無形資産の管理の問題です。