---
title: Session と Run
description: Session、Run、Event のログの関係。
---

**Session** は 1 つの作業単位で、会話、チケット、バックグラウンドジョブなどがこれにあたります。Session は Workspace に属し、作成時に使う Agent のバージョンが決まります。Session の中で起きたことは、すべて追記専用の **ログ** に記録されます。

**Run** は、このログをもとに Agent が行う 1 ターン分の作業です。入力があると Run が始まり、Run は進むにつれて自分の Event をログに追記します。終わるときは、終了を表す Event をちょうど 1 つ記録します。

Session と Run を分けて考えるのは、Session が Run より長く存続するからです。Run が失敗したり、停止されたり、Run を見ていた接続が切れたりしても、Session はログを保ったまま残り、次の入力を受け付けます。

## 何がいつ確定するか

| | 確定するとき | |
| --- | --- | --- |
| Agent のバージョン | Session の作成時 | その時点の最新バージョンです。後から公開したバージョンは、それ以降に作成した Session にだけ反映されます。 |
| Skill と Function のバージョン | Session の作成時 | 各 Grant の **最新** はその時点の最新バージョンに決まり、**固定** は指定したバージョンのままです。 |
| Vault | Session の作成時 | Session が使う Credential です。Session ごとに選びます。 |
| Metadata | Session の作成時 | 独自に付けるキーで、すべての使用量の記録にコピーされます。 |

そのため、今朝始めた Session は、途中で何が公開されても、開始時と同じ指示、Tool、Credential のまま最後まで進みます。

## ログ

すべての Event にはシーケンス番号が付き、ログがすべての事実を表します。メッセージ、Agent の Thinking、Tool の呼び出しとその結果、承認、フォーム、Client の参加と退出、各 Run の開始と終了が記録されます。ログはコンソールの **Event** タブで確認でき、API では [ページ単位で取得したりストリーミングしたり](/ja/build/streaming-events) できます。Event の全種類は [Event リファレンス](/ja/reference/events) にあります。

事実を持っているのは接続ではなくログです。そのため Client は、接続が切れても、最後に受け取ったシーケンス番号から再開できます。1 時間後にページを再読み込みしても、同じ会話が表示されます。

## Run の流れ

1. **ログから始める**

    Run はコミット済みの Event から状態を組み立て直します。そのため、失敗した Run の次の Run も、実際に起きたことから始まります。

2. **モデルを呼び出す**

    呼び出しは Subako を経由するので、Run がキーを持つことはありません。Model Provider のキーは Subako の中に封じられたままです。長い会話は、モデルの Context window に近づくと圧縮されます。

3. **Tool を呼び出す**

    各 Tool は、それを提供する Grant を通じ、その Grant の Policy に従って呼び出されます。MCP サーバーと Function の呼び出しには Session の Credential が付き、Client tool の呼び出しはアプリに送られます。

4. **終わる**

    `run_completed`、`run_failed`、`run_cancelled` のいずれかで終わります。承認やフォームで人を待っている Run は、そのまま最大 1 日待ちます。

Run の実行中に送った入力は、後ろに並んで待つのではなく **実行中の Run に加わります**。Run は次のステップでその入力を読み込みます。Run の停止は協調的です。Run は次のチェックポイントで止まって `run_cancelled` で終わり、それまでにコミットした内容はログに残ります。