Sessionはチャットログではない：実行単位のエンジニアリング

前節ではMemory Engineeringについて議論したが、メモリだけでは完全な答えにはならない。知識を永続化することはできるが、肝心な抽象化がまだ欠けている。何が保存され、再開され、中断され、移行されるのか？ この問いに答えなければ、いわゆる「長時間実行」の操作は、散在するトランスクリプト、一時ファイル、アドホックな人間の慣習の山に必然的に劣化する。

Harness Engineeringにおいて、真にエンジニアリングすべきは「チャットログ」ではなくSessionだ。モデルがCPUでHarnessがオペレーティングシステムだとすれば、Sessionはプロセスに近い。単なるメッセージの配列ではなく、完全な実行単位である。現在の目標、contextの状態、使用中のツール、バインドされたファイル、中間出力、ランタイム制約のすべてがこの単位にカプセル化されるべきだ。

最小限のSessionは複数のカテゴリの情報を含まなければならない。第一にcontext状態：システムプロンプト、会話履歴、ワーキングメモリ。第二に関連リソース：読み書きしているファイル、依存するデータベースやMCPサービス、呼び出し可能なツール。第三にメタデータ：名前、優先度、作成時刻、最終アクティブ時刻、所有Agent。第四にライフサイクル状態：実行中、サスペンド、スリープ、または終了。これらすべての情報がバンドルされて初めて、Sessionは復元可能、スケジューリング可能、ガバナンス可能なオブジェクトとなる。

このSessionの定義により、重要な区別が明確になる。SessionはAgentではない。Agentはロールやアイデンティティであり、Sessionはそのロールが担う具体的な作業単位だ。HR Agentが同時に3つのSession「月次給与計算」「採用スクリーニング」「社会保険申請」を所有しているかもしれない。同じAgentに属するが、contextと境界は完全に異なるべきだ。これらすべてを1つの超長い会話に混ぜるとcontextのクロスコンタミネーションを引き起こすだけであり、専用のSessionに分割することが複雑さを真に制御する唯一の方法だ。

これがまた、Sessionがcontextの爆発を解決する鍵となる抽象化である理由でもある。多くのチームの最初の本能は、Agentにより大きなcontext windowを与え、より多くの素材を詰め込むことだ。しかし、真にスケーラブルなアプローチは無制限の拡張ではなく、作業を複数の専用で独立したSessionにスライスすることだ。各Sessionは1つの明確な目標に奉仕し、その達成に必要な最小限のcontextのみをバインドする。HR給与計算Sessionは給与テーブル、社会保険基準料率、個人税率、先月の結果をバインドする。毎月1日にアクティブ化され、計算を完了し、サスペンドし、次のアクティベーションを待つ。面接のスケジューリングについて知る必要はなく、その情報に邪魔されるべきでもない。

Sessionを実行単位として扱うと、その周りに一連の操作プリミティブが自然に現れる。最も基本的なのはsave、load、compressで、Sessionが会話をまたいで生存できるようにする。さらに進んでactivate、suspend、interrupt、cancelがあり、スケジューリングを可能にする。さらにfork、merge、send、migrateにより、Sessionは分岐してサイドクエストに対応したり、モデル間を移動したり、互いに通信したりできる。これらの操作をすべて最初から実装する必要はないが、アドホックなスクリプトや手動の手順に依存し続ける代わりに、Harnessに明確なシステムコールテーブルを与える。

Sessionには見落とされがちだが重要な次元もある。依存関係だ。Sessionはプロンプトだけでなく、その周囲の環境にも依存する。バインドされた仕様、コードディレクトリ、設定ファイルが変更された場合、Sessionの再アクティベーションが必要になるかもしれない。これはHeartbeatが機械的なポーリングからイベント駆動型のアクティベーションへと進化することを意味する。APIドキュメントのSessionはsrc/ディレクトリに新しいコミットが入った後にウェイクアップでき、給与計算Sessionは社会保険基準料率テーブルが更新された後に自動的に再計算できる。Sessionは「受動的なアーカイブ」から「反応的な作業単位」に変わる。

もちろん、このアナロジーは完全ではない。オペレーティングシステムのプロセスは決定的であるが、Sessionはそうではない。プロセスの状態は正確にスナップショットできるが、Sessionの圧縮と復元はしばしば非可逆的だ。2つのプロセスのマージには意味上の問題は生じないが、2つのSessionのマージは対立する見解を生む可能性がある。しかし、これは抽象化を放棄する理由ではない。Sessionのシステムコールはより保守的で、より明示的でなければならないというだけだ。最初のバージョンでは最も価値の高い操作のみを実装する方が、最初から完全な仮想マシンスタイルの移行を追求するよりもはるかに現実的だ。

ここから自然に次章のトピックに到達する。Multi-Agent協調は単に「チャットウィンドウを増やす」ことではない。複数のAgentがそれぞれSessionの集合を所有し、分離、契約、統合のメカニズムを通じて連携することだ。Sessionという中間層がなければ、Multi-Agentシステムはすぐに、スケジューリングが困難で、復元が困難で、ガバナンスが困難な一時的な会話の塊に劣化する。