AIエージェントに「状態」はなぜ必要？
Session・Context・Memoryの違い

AIエージェントが、一度の質問に答えるだけなら話は比較的単純です。

しかし、

• 数十分かかる調査
• 複数ファイルにまたがる修正
• 途中でToolを何度も使う作業
• 数日にわたって継続するタスク
• 複数Agentで分担する仕事

になると、一つの問題が出てきます。

Agentは「どこまで仕事をしたのか」を、どうやって覚えているのでしょうか。

ここで登場するのが、

• State
• Session
• Context
• Memory

です。

似た言葉ですが、同じものではありません。

さらに、次のような関連用語も加わると、概念の境界が曖昧になりがちです。

• Context Window：Modelが一度に扱える情報量の上限
• Conversation History：過去の会話ややり取りの記録
• RAG：外部情報を検索し、必要な情報をContextへ加えて生成する仕組み
• Long-term Memory：Sessionをまたいで再利用する情報やその保持・取得の仕組み

これらはそれぞれ役割が異なります。最初に整理します。

今この瞬間
Context

↓　

一連の仕事
State / Session

↓

後から再利用
Memory

1. なぜAgentには「状態」が必要なのか

単発のChatbotなら、

User
↓
Question
↓
Model
↓
Answer

で終わります。

しかしAgentでは、

Goal
↓
検索
↓
結果を見る
↓
ファイルを読む
↓
判断
↓
コードを変更
↓
テスト
↓
失敗
↓
修正
↓
再テスト

というように、複数のステップを進みます。

このときAgentは、

• 何を調べたか
• 何が分かったか
• 何を変更したか
• 何が失敗したか
• 次に何をすべきか

を把握していなければなりません。

これがなければ、

同じファイルを何度も読む。

同じ検索を繰り返す。

既に失敗した方法をもう一度試す。

といったことが起こります。

つまりAgentには、

「今どこにいるのか」を表す情報

が必要です。

これを広い意味でState（状態）と考えることができます。

2. Stateとは何か

Stateは、

仕事が現在どの状態にあるかを表す情報

です。

たとえば旅行予約Agentなら、

destination = "Tokyo"
departure_date = "2026-10-10"
budget = 150000
flight_selected = true
hotel_selected = false

のような情報がStateになり得ます。

Coding Agentなら、

target_file = "app.js"
bug_found = true
patch_applied = true
tests_passed = false

という状態を持つかもしれません。

重要なのは、

Stateは「文章の履歴」だけではない

という点です。

Stateは、

• 変数
• フラグ
• タスク進捗
• Tool結果
• 中間成果物
• 現在の担当
• エラー状態

など、さまざまな形を取れます。

Google ADKでも、SessionにStateを持たせ、EventによるStateの更新を管理できる仕組みがあります。

3. Contextとは何か

Contextは、

モデルが今この瞬間の判断に利用できる情報

です。

たとえばモデルへ、

System Instruction

User:
このエラーを修正してください

Assistant:
関連ファイルを確認します

Tool:
app.js の内容

Tool:
test result: failed

Assistant:
原因を確認します

と渡されているなら、

この一連の情報がモデルの判断材料になります。

これがContextです。

Contextは保存場所ではない

ここは重要です。

Contextは、

情報を永久保存する場所

ではありません。

モデルが一度に扱えるContextには上限があります。

会話やTool結果が増え続ければ、

すべてをそのままモデルへ渡し続けることは難しくなります。

そのため実際のAgentでは、

• 古い情報を削る
• 要約する
• 必要な情報だけ選ぶ
• 外部に保存する
• 必要になったら再取得する

といった処理が必要になります。

4. Context Windowとは？

ContextとContext Windowも分けて考えます。

Context

＝モデルへ実際に渡している情報

Context Window

＝モデルが一度に扱える情報量の上限

です。

たとえばContext Windowに余裕があっても、

不要なログや大量のTool結果をすべて入れれば、

重要な情報が埋もれてしまう可能性があります。

したがってAgent設計では、

Context Windowを大きくすること

だけでなく、

何をContextへ入れるか

が重要になります。

5. Sessionとは何か

Sessionは、

一連の仕事や対話を継続するための単位

として考えると分かりやすくなります。

たとえば、

Session A
「新しいWebサイトを作る」

という仕事があったとします。

その中に、

Turn 1
要件を整理

Turn 2
HTMLを作成

Turn 3
修正

Turn 4
テスト

という複数のTurn（ユーザー入力やTool実行を契機とする、一連の処理ステップややり取りの単位）が存在します。

つまり、

Session
 ├ Turn 1
 ├ Turn 2
 ├ Turn 3
 └ Turn 4

という関係です。

6. OpenAI Agents APIではSessionをどう扱う？

OpenAI Agents APIではSessionが明確な基本概念になっています。

OpenAIはSessionを、

状態が永続化されるAgentのインスタンス

として定義しています。SessionはAgentの構成、会話、保存された作業内容を継続的に保持し、同じSessionへ追加メッセージを送ることで仕事を続けられます。

つまり、

Agent definition
↓
Session作成
↓
Turn
↓
Turn
↓
Turn

という構造です。

ここで重要なのは、

AgentとSessionも同じものではない

ということです。

Agentは、

「どのModel・Instruction・Toolを使うか」

といった構成。

Sessionは、

そのAgentが実際に一つの仕事を継続している状態

と考えると整理しやすくなります。

7. SessionがあればContextは無限になる？

なりません。

ここも重要です。

Sessionが長期間続いても、

モデルが一度に利用できるContext Windowは有限です。

そのため、

Session
 ├ 過去の作業
 ├ 過去の作業
 ├ 過去の作業
 ├ 過去の作業
 └ 現在

を毎回すべてモデルへ渡すとは限りません。

OpenAI Agents APIでは、長時間の作業を継続できるよう、OpenAI側がContext Compactionを自動的に管理します。そのため、Sessionへ保存されているすべての履歴を毎回そのままModelへ渡し続ける必要はありません。

ここから、

「Sessionを保存すること」と「モデルへすべての情報を毎回渡すこと」は別問題だと分かります。

8. Context Compactionとは？

長いContextを小さくしながら、後続処理に必要な状態を残すことをContext Compactionと呼びます。

要約（Summarization）は、Compactionを実現する方法の一つとして使われることがあります。たとえば、

100件の会話
↓
重要な決定だけ抽出
↓
「現在の仕様」
「未解決項目」
「変更済みファイル」
「次に行う作業」

という形に要約・整理するアプローチです。

ただし、Context Compaction ＝ 必ず人間が読める要約を作ること、ではありません。OpenAIのCompaction機能のように、人間が読むための要約ではなく、後続処理に必要な状態をopaqueな形で保持しながらContextサイズを削減する実装もあります。

これは単なるToken節約ではありません。Agentにとって、

何を残し、何を落とすか

を決める処理でもあります。

9. Memoryとは何か

Memoryは最も曖昧に使われやすい言葉です。

CORE SPECでは、

現在のTurnだけでなく、後のTurnやSessionでも再利用する情報を保持・取得する仕組み

という広い意味で扱います。

たとえば、

• ユーザーの好み
• 過去のプロジェクト方針
• 以前の失敗
• 採用済みの設計判断
• 長期的なタスク情報

などです。

Memoryは一つの箱ではない

「Memory」という巨大なデータベースが一つある、と考える必要はありません。

実際には、

Memory
├ Database
├ File
├ Summary
├ Vector Store
├ User Profile
└ Event History

など複数の方式が考えられます。

つまりMemoryは、

保存技術の名前

というより、

後で必要な情報を再利用できるようにする設計

として理解した方がよいでしょう。

AgentのMemoryとPCのメモリ（RAM）は別物

ここでいうMemoryは、PCのRAMやVRAMとは別の概念です。

PCのRAM / VRAMは、

• ProgramやModelが処理中のDataを保持するHardware上の記憶領域

です。

一方、Agent Memoryは、

• どの情報を保存するか
• どこへ保存するか
• いつ再取得するか
• いつ忘れるか

を含むSoftware上の状態・記憶設計です。

Agent Memory ≠ PCのメモリ容量

です。

10. SessionとMemoryは何が違う？

ここも混同されやすいところです。

Sessionは、

一連の仕事を継続するための単位

です。

Memoryは、

Sessionを越えて情報を再利用することも含む仕組み

です。

たとえば、

Session A
「記事Aを作る」

Session B
「記事Bを作る」

があるとします。

Session Aだけで使った、

「現在article.htmlを編集中」

という情報は、Session Bでは不要かもしれません。

しかし、

「CORE SPECでは確定情報とリークを分離して書く」

という編集方針は、別Sessionでも役立つ可能性があります。

前者はSession固有State。

後者は長期的に再利用するMemory候補。

という違いです。

11. MemoryとRAGは同じなのか？

同じではありません。

RAGは、

外部の情報源から関連情報を検索し、その情報をModelのContextへ加えたうえで回答や生成を行う設計パターン

です。

たとえば、

Question
↓
Vector DB検索
↓
関連Document取得
↓
Contextへ追加
↓
Model

です。

一方Memoryは、

Agent自身の過去の情報や、後で必要な情報を保持・取得・再利用するための設計

として使われます。

もちろんMemoryの実装として、Vector DatabaseやRetrievalを利用することはあります。しかし、

RAG = Memory

ではありません。

RAGは外部知識を検索して生成へ利用する仕組み、Memoryは後で必要な情報を保持・取得・再利用するための設計と分けて考えます。

RAGそのものの学習順序については、「RAG学習ロードマップ」で詳しく整理しています。

12. 「長期記憶＝Vector DB」でもない

Agent Memoryを学ぶと、

「Vector DBを入れれば長期記憶になる」

と考えたくなります。

しかし、それだけでは十分ではありません。

重要なのは、

• 何を保存するのか
• いつ保存するのか
• いつ取得するのか
• 何を忘れるのか
• 更新された情報をどう扱うか
• 誤ったMemoryをどう修正するか

です。

つまりMemory設計では、

StorageよりMemory Policyの方が重要

になる場合があります。

何でも記録すれば良いわけではありません。

13. Agentは何を覚えるべきなのか？

すべてを覚える必要はありません。

むしろ、

覚えすぎることも問題

です。

たとえばAgentが、

• 古い仕様
• 一時的な判断
• 誤った推測
• 期限切れの情報

を長期Memoryとして保持すると、

後の仕事へ悪影響を与える可能性があります。

そこで情報を、

Temporary
↓
Session State
↓
Reusable Memory

と分けて考える意味があります。

14. StateとMemoryを分けると設計しやすい

たとえばECサポートAgentなら、

State

current_customer = 12345
current_order = A001
refund_requested = true
refund_completed = false

Memory

customer prefers email
customer has premium plan
previous issue category = shipping

と分けられます。

Stateは、

今の仕事を進めるために必要。

Memoryは、

今後の仕事にも役立つ可能性がある。

という違いです。

15. Multi-AgentになるとState管理はさらに難しくなる

シリーズ第4回『Single AgentとMulti-Agentの違い』で見たように、複数Agentへ仕事を分けることがあります。

たとえば、

Research Agent
↓
「公式仕様Aを確認」

Coding Agent
↓
???

Research Agentが得た情報をCoding Agentが知らなければ、

正しい実装ができません。

そこで、

Research Agent
↓
Shared State / Artifact（ファイルなどとして残した成果物）
↓
Coding Agent

という受け渡しが必要になります。

しかし何でも共有すると、

今度はContextが膨らみます。

したがってMulti-Agentでは、

誰が、何を、どの粒度で共有するか

までState設計になります。

16. Google ADKでもSessionとStateは分けられている

Google ADKにもSessionという概念があり、そのSessionにStateを持たせることができます。

Session Serviceは、

• Sessionを作成・取得する
• SessionにEventを記録する
• 保存されたSessionやEventを管理する

といった役割を持ちます。

ADKではEventに含まれるState Deltaを通じてSession Stateを更新でき、InstructionからSession Stateの値を参照することもできます。

これは、

Sessionという器の中にStateがある

という関係を理解する具体例になります。

ただし、OpenAIとGoogleでSessionの詳細仕様が完全に同じという意味ではありません。

17. 実行環境にも「状態」がある

さらにAgentでは、

会話だけでなくEnvironment側にもStateが残る場合があります。

たとえばコード実行環境で、

import pandas
df = load_data()

↓ 次のTool Call

df.groupby(...)

と続ける場合です。

Google Cloud Agent RuntimeのCode Executionでは、一つのAgentタスク中でSandboxを維持し、変数・Import・File Stateを複数のTool Callにまたがって保持できます。

つまりAgentの「状態」は、

Conversation State
Task State
Memory
Environment State

など、複数の場所に存在し得ます。

ここも重要です。

18. Contextへ何を入れるかは設計問題

大量のStateやMemoryを保存できても、

そのすべてを毎回モデルへ渡す必要はありません。

むしろ、

保存されている情報
1000件

↓

現在の仕事に必要
10件

↓

Contextへ投入

という選択が必要です。

つまり、

「保存できる情報量」と「モデルへ見せる情報量」は別です。

Agentの品質は、

大量のMemoryを持っているかではなく、

今の判断に必要な情報を、適切なタイミングでContextへ持ってこられるか

にも左右されます。

19. Contextが多いほどAgentは賢くなるのか？

必ずしもそうではありません。

不要な情報が大量に入ると、

• 重要情報を見落とす
• 古い情報を参照する
• 指示が競合する
• Token Costが増える
• 処理時間が増える

可能性があります。

そのため、

Contextを増やす

のではなく、

Contextを編集する

という考え方が重要になります。

これは今後のAgent設計で大きなテーマになります。

20. Memoryが多いほどAgentは賢くなるのか？

これも同じです。

Agent Memoryでは、

「保存する」より、

何を保存しないか

も重要です。

たとえば、

「ユーザーが昨日一度だけ選んだ設定」

を永久に覚える必要があるでしょうか。

逆に、

「このプロジェクトではTypeScriptを使う」

という決定は、継続的に使う意味があります。

たとえばMemory設計では、次のような観点を持つと整理しやすくなります。

• relevance
• freshness
• confidence
• scope
• lifetime

のような考え方が必要になります。

21. Agentの「記憶」を人間と同じものだと思わない

Memoryという言葉を使うと、

人間の記憶と同じように感じます。

しかし実際には、

AgentのMemoryは多くの場合、

• データベース
• 保存されたSession
• ファイル
• Summary
• Retrieval
• Application State

などの仕組みです。

Agentが人間のように、

「なんとなく覚えている」

わけではありません。

何を保存し、何を再取得し、何をContextへ入れるか

というソフトウェア設計があります。

22. Claude Code・Codex・Antigravityを見る視点も変わる

Coding Agentを使っていると、

「前に言ったことを覚えている」

ように感じることがあります。

しかし見るべきなのは、

本当にModel自身が覚えているのか

ではありません。

• Sessionを保存しているのか
• Conversation Historyを再投入しているのか
• Summaryしているのか
• Project Fileを読み直しているのか
• Stateを外部保存しているのか

という状態管理の仕組みです。

製品ごとに実装は異なります。

だから、

「このAgentはMemoryがある」

という一言だけで判断しないことが重要です。

23. State設計で考えるべき4つの問い

Agentを設計するときは、まず次の4つを考えると整理しやすくなります。

1. 今の仕事に必要な情報は何か？

→ Context

2. 今どこまで進んでいるか？

→ State

3. どこまでを一つの仕事として継続するか？

→ Session

4. 次の仕事でも残したい情報は何か？

→ Memory

この4つを分けるだけでも、

Agent設計はかなり分かりやすくなります。

24. CORE SPECの整理

最終的に、CORE SPECでは次のように整理します。

Context
今、モデルが見ている情報

State
今、仕事がどこまで進んでいるか

Session
一連の仕事を継続する単位

Memory
後でも再利用したい情報

さらに、

Stored Data
↓
必要情報を選択
↓
Context
↓
Modelが判断
↓
Action
↓
State更新
↓
Session継続
↓
必要ならMemoryへ保存

という循環で考えると、Agentの状態管理が見えやすくなります。

まとめ

AIエージェントに「状態」が必要なのは、

複数ステップの仕事を続けるため

です。

Contextは、

今モデルが判断に使える情報。

Stateは、

仕事が今どこまで進んでいるか。

Sessionは、

その仕事を継続するための単位。

Memoryは、

後の仕事でも情報を再利用するための仕組み。

です。

そして重要なのは、

覚えることそのものではなく、必要な情報を必要なときに使えること。

Agentに大量の情報を保存すれば賢くなるわけではありません。

何を残すか。

何を忘れるか。

何をContextへ戻すか。

そこまで含めてState / Memory設計です。