AIに「昨日の続きをお願い」と頼んだのに、話がまったく違う方向へ進んでしまったことはありませんか。
前の日に、作業の目的、修正した内容、残っている課題まで細かく話したはずなのに、翌日になるとAIが別の前提で答え始める。
そのたびに、また最初から説明し直すことになります。
これは、AIが急に不親切になったからではありません。でもからかわれてる感じがして頭きますよね。これが原因で私はかなりうちのAIと喧嘩になります（笑
人間側では「昨日の続き」としてつながっているつもりでも、AI側では、今見えている会話、過去の履歴、途中で作ったファイル、現在の進行状態が、同じ場所にまとまっているとは限らないからです。
たとえば、次のような場面でズレが起きます。
- ChatGPTに前回の相談内容を前提にしてほしい
- Claude Codeに昨日の修正作業の続きを頼みたい
- Discord連携したAIに過去のやりとりを踏まえて返してほしい
- n8nのワークフロー内で、AIに途中結果を引き継がせたい
- 作業中の判断、未完了タスク、次にやることをAIに忘れさせたくない
このとき必要なのは、「AIに全部覚えてもらうこと」ではありません。大事なのは、AIがその場で見られる情報と、人間側がファイルとして残しておく情報を分けることです。
この記事では、AIが「忘れた」ように見える原因を、作業状態の残し方として整理します。
最初から難しい仕組みを理解する必要はありません。
まず見るべきなのは、AIが続きを失敗するときに、どの情報が渡っていなかったのかです。
そこが分かると、「昨日の続き」を頼むときに、何を会話で伝え、何をMarkdownやタスク状態として残すべきかが見えてきます。
AIが途中経過を失うように見える理由
AI が昨日の続きを失うのは、性格ではなく構造の問題です。何で止まっているのかが見えないと、AI を責めてしまいたくなりますよね。ここでは「忘れる」ように見える正体を、状態の分離不足という観点で整理します。
「忘れる」ように見える正体
AI が忘れたように見える場面の多くは、別セッションで始まり context が空の状態になっていることが原因です。前回のチャット画面が残っていても、AI 側から見ると別の作業台に座り直したのと同じです。
Claude Code の公式ドキュメントには「Each Claude Code session begins with a fresh context window.」と書かれており、毎セッションが新しい作業台から始まる仕様です。ChatGPT のように画面上に過去スレッドが見えていても、AI が常に参照しているわけではなく、サービス側がどこまで読み込んでいるかは画面の見た目とは別の話になります。
これエンジニア出身者には理解できても、非エンジニアなどの一般層の方にはなかなか理解し難いのではないかと思います。私はこれまでずっとエンジニア業を生業にしてきましたが、これが原因でかなりの確率で我が家のAIと衝突を繰り返してきました。
context / history / memory / 途中成果 / タスク状態の分離不足
ccontext、history、memory、途中成果、タスク状態と並べられても、最初はどれも「AIが覚えている情報」に見えますよね。
でも、実際にはそれぞれ置き場所が違います。
たとえば、AIに作業を頼んでいるとき、今この瞬間にAIが見ている情報があります。これが context です。作業机の上に広げている資料のようなものです。
その作業机の上には、これまでの会話も積まれます。これが history です。何を話したかの履歴です。
一方で、途中で作ったMarkdown、JSON、ログ、チェックリスト、修正済みファイルは、AIの中に自動で残るものではありません。
これらは途中成果です。ファイルとして保存しておかないと、次に作業を再開するときに確認できません。
さらに、「未着手」「作業中」「完了」「保留」「失敗」「再実行待ち」のような進行状況も、会話とは別に残す必要があります。
これがタスク状態です。
HermesAgent memory のような仕組みも、すべての会話や作業を丸ごと覚えるものではありません。あらかじめ書き込まれた短い情報や、明示的に検索・注入された情報だけが使われます。
つまり、AIが見ている会話、過去の履歴、途中で作ったファイル、作業の進行状態、外部メモリは、全部同じ場所にあるわけではありません。
この5つを同じものとして考えると、「昨日話したのに、なぜ伝わっていないのか」が分からなくなります。
逆に、どの情報がどこにあるのかを分けて考えると、AIが続きを失敗したときに「会話が足りなかったのか」「ファイルが残っていなかったのか」「タスク状態が渡っていなかったのか」を切り分けられます。
context と history の違い
context と history は、どちらも「AI が見ている会話」に見えるかもしれません。
ですが、この 2 つは同じものではありません。
context は、AI が今の返答を作るために見ている作業領域です。
history は、これまで積み上がってきた会話の記録です。
人間の感覚では、過去に話したことはそのまま残っているように見えます。
でも AI から見ると、「会話として残っていること」と「今の返答で参照できること」は別です。
ここを分けて考えないと、「前に話したのに、なぜ伝わっていないのか」が分からなくなります。
context window という有限の作業領域
context window は、AI が 1 回の返答を作るときに見られる範囲です。
作業机をイメージすると分かりやすいです。机の上に広げられる資料には限りがあります。資料が増えすぎると、古い資料や細かい内容を見落としやすくなります。
AI も同じです。
長いやり取り、貼り付けたコード、調査結果、エラー内容、修正方針などが増えていくと、作業領域がいっぱいになります。
その結果、まだ会話履歴には残っていても、今の返答ではうまく使われない情報が出てきます。
Claude などのモデルには、参照できる token 数の上限があります。
大きな context window を持つモデルでも、情報を大量に詰め込めば常に正確に扱えるわけではありません。
大事なのは、容量の数字そのものではありません。
「会話に書いたから大丈夫」と考えず、重要な判断、完了条件、次にやることは、別のファイルやチェックリストにも残しておくことです。
history と作業状態のズレ
history は、これまで何を話したかの履歴です。
一方で、作業状態は「いま何がどこまで進んでいるか」です。
この 2 つも同じではありません。
たとえば、会話の中に「修正しました」と書かれていても、実際のファイルが保存されていなければ、作業は残っていません。
「確認しました」と書かれていても、確認結果のログやチェックリストがなければ、後から検証できません。
会話履歴は、あくまで会話の記録です。
作業そのものを保証してくれるものではありません。
ここを混同すると、AI に「昨日の続き」を頼んだときに、AI は会話の流れからそれらしい続きを作ってしまいます。
でも、実際にはファイルが残っていない、タスク状態が更新されていない、検証結果がない、ということが起きます。
だから、作業を続けてもらうには、会話履歴だけでは足りません。
- 何を完了したのか。
- 何が未完了なのか。
- どのファイルを見ればよいのか。
- どこで止まったのか。
こうした作業状態を、会話とは別に残す必要があります。
/compact で残るもの・失われるもの
Claude Code の /compact は、長くなった会話を短くまとめる機能です。
要点は残ります。
一方で、細かいやり取り、ツールの完全な出力、中間の検討内容まですべて残るわけではありません。
たとえば、次のような情報は残りやすいです。
- ユーザーが何をしたかったのか
- 重要な技術的な話題
- 調査したファイルや修正したファイル
- 発生したエラーと対応内容
- 残っているタスク
- 現在取り組んでいる作業
逆に、次のような情報は落ちやすくなります。
- コマンドの完全な出力
- 途中で出た細かい候補
- 検討中に捨てた案
- 一時的な判断理由
- 長いログの詳細
- その場では重要に見えなかった補足情報
つまり、/compact 後に残るのは「要約された作業の流れ」です。
作業を再現するための完全な記録ではありません。
だから、あとで必要になりそうな情報は、会話の中だけに置かない方が安全です。
調査結果は Markdown に残す。
実行結果はログとして残す。
完了条件や未完了タスクはチェックリストに残す。
修正内容は Git の差分やコミットで残す。
このように、会話とは別の場所に作業状態を出しておくと、/compact された後でも、翌日でも、別セッションでも続きから再開しやすくなります。
途中成果を残さない作業の危険性
AI に作業を頼んでいると、「やりました」「修正しました」「確認しました」と返ってくることがあります。
そのとき、何を見て確認していますか。
会話の中で「やりました」と書かれていても、実際にファイルが保存されていなかったり、ログが残っていなかったり、どこまで終わったかのチェックがなかったりすると、後から確認できません。
人間が作業するときでも、メモも保存もせずに作業を進めると、次の日に「どこまでやったっけ」となりますよね。
AI でも同じです。
途中で作ったものを外に残しておかないと、会話が長くなったとき、別のセッションで再開するとき、翌日に続きを頼むときに、何を根拠に進めればよいのか分からなくなります。
途中成果をファイルに残す理由
AI に作業を任せるときは、会話だけに頼らず、途中でできたものを外に残しておく必要があります。
ここでいう「途中成果」は、完成品だけではありません。調べた内容、決めた方針、実行したコマンド、出たエラー、修正した差分、残っている作業も含みます。
たとえば、次のように分けて残します。
| 残すもの | 役割 |
|---|---|
| Markdown | 調査結果、設計メモ、判断理由を残す |
| JSON | タスクリスト、設定、記事設計などを機械的に扱える形で残す |
| ログ | 実行結果、エラー、コマンド履歴を残す |
| 差分 | どこを変更したかを残す |
| チェックリスト | 完了したこと、まだ残っていることを残す |
難しく考える必要はありません。要するに、「AI が作業中に見ていた情報」を、あとから人間や別の AI が見ても分かる形で残すということです。
- これをしておくと、途中で止まっても再開できます。
- 別の日に続きを頼んでも、前回の状態を説明しやすくなります。
- AI の返答が正しいかどうかも、会話の雰囲気ではなく、実際のファイルやログで確認できます。
逆に、途中成果を残していないと、AI は会話の流れからそれらしい続きを作るしかありません。その結果、「前回と違うことを言い始めた」「直したはずの内容をまた戻した」「どこまで終わったか分からない」という状態になります。
続きを任せるときに渡すべき 5 要素
AI に続きを任せるときは、長い説明をもう一度書くよりも、最低限の情報を整理して渡した方が安定します。
必要なのは、次の 5 つです。
| 渡す情報 | 意味 |
|---|---|
| 完了条件 | 何ができたら終わりか |
| 現在の状態 | どこまで進んでいるか |
| 中断理由 | なぜ止まっているか |
| 次のアクション | まず何をやるか |
| 参照ファイル | どのファイルを見ればよいか |
たとえば、AI に「続きからお願いします」とだけ言うと、AI は前回の状態を推測するしかありません。
でも、次のように渡せば、再開しやすくなります。
- 完了条件: 記事の冒頭と最初の H2 を読みやすくする
- 現在の状態: 冒頭は修正済み、途中成果の章を修正中
- 中断理由: 専門語が多く、一般読者に伝わりにくい
- 次のアクション: 途中成果の章をやさしい文章に直す
- 参照ファイル: 対象の記事 Markdown と画像配置メモ
ここまで書いておけば、AI は何をすればよいかをかなり正確に判断できます。大事なのは、AI に「前回の流れを思い出してもらう」ことではありません。人間側が、再開に必要な情報を見える場所に残しておくことです。
完了条件、現在の状態、中断理由、次のアクション、参照ファイル。この 5 つを残しておくだけで、「昨日の続き」がかなり安定します。
タスク状態を外部化する必要性
AI に作業を頼んでいるとき、今その作業がどこまで進んでいるかを、AI に聞かなくても確認できますか。
- 「さっきまでやっていたはず」
- 「たしか修正済みだったはず」
- 「前回の会話では終わったと言っていたはず」
このような状態だと、次の日に続きを頼むときに不安定になります。
会話の中に「完了しました」と書かれていても、本当に完了しているとは限りません。
実ファイルが更新されているのか、確認が済んでいるのか、エラーで止まっているのか、次に何をすればよいのかは、会話だけでは分からないことがあります。
だから、タスク状態は会話の中だけに置かず、外から見える場所に残す必要があります。
「済 / 未」だけでは足りない理由
タスクの状態を「終わった」「まだ終わっていない」だけで分けると、途中で困ることがあります。
実際の作業には、もっと細かい状態があります。
| 状態 | 意味 |
|---|---|
| 未着手 | まだ始めていない |
| 作業中 | いま進めている |
| 完了 | 作業が終わっている |
| 保留 | いったん止めている |
| 失敗 | 実行したがうまくいかなかった |
| 再実行待ち | 条件を直したあと、もう一度実行する |
| レビュー待ち | 人間の確認が必要 |
| ブロック中 | 依存する作業や判断が止まっている |
たとえば、「完了」と見えていても、まだ確認が終わっていないことがあります。
「失敗」と見えていても、原因を直せば再実行できることがあります。
「未完了」と見えていても、実際には人間の判断待ちで止まっていることもあります。
これらを全部「未」や「途中」にしてしまうと、AI も人間も次に何をすればよいか判断できません。
タスク状態を細かく分ける目的は、管理を難しくすることではありません。
- 次に動ける状態なのか。
- 人間の確認が必要なのか。
- エラー対応が必要なのか。
- もう一度実行すればよいのか。
この判断をしやすくするためです。
タスク状態を置く場所
タスク状態は、1つの会話の中にだけ置かない方が安全です。
使っている道具ごとに、向いている保存先があります。
| 置き場所 | 残す内容 |
|---|---|
| Claude Code | 作業中のタスク、次にやること、短いチェックリスト |
| Git | 変更履歴、差分、どこまで保存されたか |
| GitHub Issues | 未着手、作業中、保留、レビュー待ちなどの管理 |
| n8n DB | ワークフローの実行状態、成功、失敗、再実行待ち |
| Obsidian / Markdown | 作業メモ、判断理由、次に見る場所 |
たとえば、Claude Code の会話の中で「修正しました」と言われても、Git に差分が残っていなければ、後から変更内容を確認しにくくなります。
n8n のワークフローでエラーが出た場合も、会話で説明するだけでは足りません。
どの実行で止まったのか、どのノードで失敗したのか、再実行できるのかを、実行履歴や外部 DB に残しておく必要があります。
Obsidian や Markdown には、作業の背景や判断理由を残せます。
「なぜこの対応にしたのか」「なぜ保留にしたのか」「次に何を見るのか」を書いておくと、翌日でも別のAIでも再開しやすくなります。
大事なのは、すべてを1か所に詰め込まないことです。
- 会話は会話。
- 変更履歴は Git。
- 作業状態は Issues やチェックリスト。
- 自動化の実行状態は n8n。
- 判断理由や作業メモは Markdown。
このように分けておくと、AI に聞かなくても、いま作業がどこで止まっているかを確認できます。
AIに任せるための状態管理
AI に仕事を任せるなら、「今どうなっているか」をAIの返答だけに頼らない方が安定します。
- AI が「完了しました」と言ったら、何をもって完了とするのか。
- エラーになったら、どこに失敗状態を残すのか。
- 人間の確認が必要なら、どこにレビュー待ちとして置くのか。
- 再実行が必要なら、どこに再実行待ちとして残すのか。
ここまで決めておくと、AI は次にやることを判断しやすくなります。
人間側も、毎回会話を読み直さなくて済みます。
タスク状態を外に出す目的は、管理表を増やすことではありません。
AI に作業を任せても、途中で迷子にならないようにすることです。
そして、人間が画面に張り付かなくても、どこまで進んだかをあとから確認できるようにすることです。
HermesAgent を状態管理の万能手段にしない考え方
HermesAgent や AI エージェントなら全部覚えてくれる、と思っていませんか。HermesAgent と言われても何ができるか分かりにくいので、少し整理してみました。実体は約 1,300 tokens のテキストファイルで、全会話を保存する仕組みではありません。
memory (MEMORY.md + USER.md / 約 1,300 tokens) の実体
HermesAgent の memory は MEMORY.md と USER.md の 2 ファイル、合計約 1,300 tokens のテキストファイルです。セッション開始時に system prompt に注入されます。
公式ドキュメントによると、MEMORY.md は環境事実・習得事項 (約 2,200 文字制限)、USER.md はユーザー設定・コミュニケーションスタイル (約 1,375 文字制限) を担い、保存場所は ~/.hermes/memories/ です。frozen snapshot pattern と呼ばれる仕組みで、変更はディスクへ即時永続化されますが、次セッション開始時まで context への反映はありません。AI の永続記憶の考え方を別角度から扱った記事として、AIに過去の記憶を忘れさせない方法｜LLMナレッジベースという考え方 も併せて読むと、memory ファイルと知識ベースの違いが整理できます。
FTS5 クロスセッション検索と context 自動展開の違い
FTS5 という SQLite の全文検索機能で過去セッションを検索できますが、自動で context に展開されるわけではありません。明示的にツール呼び出しが必要です。
HermesAgent は全 CLI・メッセージングセッションを SQLite (~/.hermes/state.db) に保存し、session_search ツールで FTS5 全文検索を呼び出せます。ただし、検索結果が自動で AI の作業台に並ぶわけではなく、ツール呼び出しを設計に組み込まないと参照されません。「常駐エージェントだから過去を全部覚えている」というイメージと、実際の「明示検索が必要」という挙動の間にはギャップがあります。
Discord 連携で過去文脈を期待して失敗するケース
Discord 連携 AI に「前の会話の続きをお願い」と頼んでも、過去文脈が自動で読まれるとは限りません。state.db に取り込まれるかは公式に明示記述がなく、未確認の仕様です。
仮に state.db にあったとしても、LLM の context に自動展開はされず、FTS5 検索ツール (session_search) の呼び出しを設計に組み込む必要があります。「Discord チャンネルに履歴が見える=AI もそれを参照できる」と考えると、過去文脈が引き継がれず失敗します。HermesAgent の Discord 履歴が state.db に取り込まれる仕様は公式記述がないため、過去文脈を使わせたい場合は明示的なツール呼び出しを前提に設計する必要があります。
AIに仕事を任せる前に人間が残すべき情報
AI に作業を任せる前、何を残しておけば翌日も続きを頼めますか。判断と作業を分けたうえで、人間側がファイルに残すべき情報を最後に整理します。
完了条件・現在の状態・中断理由・次のアクション
完了条件・現在の状態・中断理由・次のアクションの 4 つは、AI を始める前か止める前に必ず書き出します。これがないと再開時に推論で補完されてしまいます。
完了条件は「何ができたら done か」を 1 行で言語化したもの、現在の状態は「どこまで進んだか」をチェックリストや進捗率で示したもの、中断理由は「なぜ止まったか」(待ち / 失敗 / 一時退避) を分類で残したもの、次のアクションは「最初に何をやるか」を 1 文で書いたものです。AI に作業を任せる前の役割分離 (判断と作業の分け方) については、シリーズ前段の AIをどう活用するか──手放す作業と残す判断、作業者に戻らない使い方 で扱っており、本記事の状態管理はその「作業を渡す前提」が整った後の話になります。
CLAUDE.md / MEMORY.md / 外部 Markdown / Issues / n8n DB の役割分担
保存先は 1 つにまとめず、CLAUDE.md (恒久ルール) / MEMORY.md (自動再注入) / 外部 Markdown (詳細) / Issues (タスク) / n8n DB (実行状態) で役割を分けます。
CLAUDE.md は context に毎回注入される恒久的な役割・スタイル・前提を置く場所で、200 行以内を推奨されています。MEMORY.md は auto memory として先頭 200 行または 25KB のみが読み込まれるため、頻繁に参照する要点を簡潔に残します。外部 Markdown は CLAUDE.md からリンクして必要時に AI が読み出す詳細領域、Issues はタスクの進行段階を label / status で外部化する場所、n8n DB は自動化フローの実行状態を後続ノード・他エージェントから参照可能にする場所です。1 つのファイルに全部詰め込むと auto memory の上限を超え、最初の 200 行以外が読み込まれない状態になります。
まとめ
AI が途中経過を失うのは性格ではなく構造です。context・history・途中成果・タスク状態・HermesAgent memory の 5 つを分けて、状態を AI 内部に置かず外部化することで、翌日も続きを頼める状態になります。
5 領域のどこで切れているかが見えれば、「AI が忘れた」と感じる場面の多くは、人間側が状態を渡せていなかっただけだと分かります。HermesAgent のような自律エージェントを導入しても、約 1,300 tokens の memory + FTS5 明示検索という構造は変わりません。CLAUDE.md / MEMORY.md / 外部 Markdown / Issues / n8n DB を役割で使い分け、完了条件・現在の状態・中断理由・次のアクション・参照ファイルの 5 要素を書き出しておくのが、最初の一歩になります。
