---
title: "起動時に何を渡すか ── 記憶・ルール・タスクをナレッジグラフから注入する試みと、SessionStart hookの3つのハマりどころ"
tags: [claude-code, hooks, ai-memory, handoff, context-engineering, knowledge-graph, mcp, tec]
date: 2026-10-13
updated: 2026-10-13
sources: [raw/tec/2026-10-13-agent-collab-knowledge-graph.md, raw/tec/2026-10-13-claude-code-sessionstart-hook-handoff.md]
confidence: medium
summary: "セッションの開始時にエージェントへ状態を渡す2つの実践をまとめる。1つは記憶・共通ルール・プロジェクト間のタスクを自作のナレッジグラフ（MCPサーバー）に置き、起動時に1回の呼び出しでまとめて取ってくる構成。もう1つはClaude CodeのSessionStart hookで引き継ぎメモとgitの状態を流し込む実装手順。どちらも、/compact の後に注入した情報が消える問題と、注入量が膨らむ問題に行き当たっている。"
sidebar:
  hidden: true
---

エージェントに「前回の続き」をやってもらうには、何かを渡さないといけない。渡し方は大きく2つに分かれる。データを**どこに置くか**（ファイルか、データベースか）と、それを**いつ渡すか**（起動時にまとめて注入するか、必要なときにエージェントが取りに行くか）だ。この記事は、どちらも「起動時に注入する」を選んだ2つの実践をまとめる。Zennの記事（kumaik）は、記憶・ルール・タスクを自作のナレッジグラフ（以下KG）に置いた。Qiitaの記事（yureki_lab）は、引き継ぎメモをファイルに置き、Claude CodeのSessionStart hookで流し込んだ。置き場所は違うけど、2人とも同じ2つの穴に行き当たっている。会話が圧縮されると注入したものが消えること、そして注入する量が膨らんでいくことだ。

## 1. ナレッジグラフに寄せた構成

KGの筆者は、役割を持たせたエージェント（調査担当と執筆担当を、別々のClaude Codeセッションに分けている）を協働させるために、2026年5月からこの構成で運用している。KGを置いた理由は「特定のAIによらず情報を共有したい」から。KGはMCPサーバーとしてクラウドに置いてあるので、MCPを話せるクライアントなら同じ記憶を読み書きできるし、マシンもまたげる。ただし Claude Code 以外のAIからはまだ使っておらず、「AIによらず」は設計の意図であって検証済みではない、と本人が書いている。

情報は3層に分けている。

| 層 | 置き場所 | 中身 | 読み込まれ方 |
|---|---|---|---|
| Static | `~/.claude/CLAUDE.md` | 接続手順、書き込みの不変ルール、ノードIDの命名規則 | 起動時にファイルから |
| Dynamic | KGのRuleノード | 記録ポリシー、プロジェクト間の連絡規約、ノード種別の一覧 | セッション開始時に `kg_session_init` で取得 |
| プロジェクト固有 | 各プロジェクトのCLAUDE.md | 概要、開発コマンド | 起動時にファイルから |

セッションの最初に `kg_session_init` を呼ぶと、そのプロジェクトの記録（決定・制約・受け取ったタスク）と、全プロジェクト共通のルールがまとめて返ってくる。ノードには型があり（Decision・Bug・Constraint・Insight・Task・Rule・Commentなど）、IDは `decision:use-postgres` のように種別とスラッグで付ける。MCP公式の参照実装にも知識グラフのメモリサーバー（`server-memory`）があって発想は近いが、あちらの既定の保存先はローカルのファイルで、こちらはクラウドに置いて複数のプロジェクト・マシンから共有している点が違う。

公式のauto memory（`MEMORY.md` の先頭200行か25KBまでを読み込む）はマシンローカルで、マシン間・クラウド間では共有されない。筆者は、これは記憶が足りないという問題ではなく、解いている問題の軸が違う（共有したいかどうか）と整理している。

### タスク表をKGに置く

いちばん具体的なのは、プロジェクト間の連絡のやり方だ。送る側が、受ける側のプロジェクトにTaskノードを登録する。Taskには依頼元・依頼先・種別・状態・優先度・本文を持たせ、質問や回答はTaskに紐づくCommentのスレッドで往復する。

```
proj:writer     --HAS_TASK-->      task:example
task:example    --REGISTERED_BY--> proj:researcher
comment:example --ABOUT-->         task:example
```

受ける側のセッションが起動していなくても依頼は成立し、履歴も残る。公式にも、稼働中のセッション同士に平文を届けるcross-session messagingや、実験的なagent teams（既定で無効・1セッション1チーム）があるが、筆者が確かめた範囲ではスレッドや履歴として残す仕組みは書かれていない。筆者は「非同期・永続・スレッド・履歴あり」という性質の差であって、優劣ではないと書いている。

この仕組みで事故も起きている。2026-09-22、別のプロジェクトからTaskを登録した副作用で、受ける側のプロジェクトノードのプロパティ11件が消えた。手順書が `props={}` という空の辞書を渡す呼び方を指示していて、それが既存のプロパティを空で上書きした。9月26日にサーバー側でpropsをマージする修正を入れている。確認画面は出ていたが、何度も許可してきた `kg_remember` の引数をよく見ていなかった、とも書いている。

## 2. SessionStart hookでファイルから流し込む

Qiitaの筆者は、無人で長時間回す自律システムを運用していて、エージェントが作業の終わりに `handoff.md` へ「やったこと／次にやること／未解決の問題」を書く。次のセッションはそれをSessionStart hookで受け取るので、人間が間に入らなくても作業がつながる。

SessionStart hookは、セッション開始時にスクリプトを走らせて、その出力をClaudeのコンテキストに差し込む仕組みだ。exit 0で標準出力に出した内容がそのまま入るし、JSONの `hookSpecificOutput.additionalContext` で渡すこともできる。筆者のスクリプトは、ブランチ名・`git status --short`・直近5コミット・`handoff.md`（3000字まで）を組み立てて返す。標準入力には `session_id`・`cwd`・`source` などのJSONが届くので、`source` を見れば新規起動か圧縮の後かで出し分けられる。コマンドは `$CLAUDE_PROJECT_DIR` を使って絶対パスで書く。相対パスだと、サブディレクトリから起動したときにスクリプトが見つからず、静かに失敗する。

筆者が実際にハマったのは次の3つ。

| ハマりどころ | 症状 | 原因と回避策 |
|---|---|---|
| `/compact` で消える | 長い作業で自動圧縮が走ると、急に「どのタスクでしたっけ」と言い出す | matcherを `startup` だけにしていた。SessionStartは圧縮後（`compact`）や `/clear` の後にも発火するので、matcherに `startup`・`resume`・`clear`・`compact` の4つを全部入れる（matcherを省略しても全種で動く） |
| `export` が届かない | hookで `export` した環境変数が、Bashツールから見えない | hookは子プロセスなので親に伝わらない。SessionStartにだけ渡される `CLAUDE_ENV_FILE` に `export` 文を**追記**する（`"w"` で上書きすると他のhookが書いた行を消す） |
| exit 2 で止まらない | mainブランチなら止めたかったのに、セッションは普通に始まる | SessionStartはブロックできないイベント。exit 2のstderrは画面に出るだけでClaudeには渡らず、JSONもexit 0のときしか解釈されないので `additionalContext` まで捨てられる。止めたいならPreToolUse hookの担当にし、SessionStartでは警告文を注入する |

## 3. 2つが行き当たった同じ穴

### 圧縮の後に、注入したものが消える

KGの筆者は、これを公式ドキュメントからの**推論**として書いている。公式によると、`/compact` の後もプロジェクト直下のCLAUDE.mdとauto memoryはディスクから再注入されるが、会話の中で受け取った指示は要約に置き換わって原文が残らない。KGから取ってきたルールは会話の中に入るので、圧縮の後に効かなくなるかもしれない。ただし実際に確かめてはおらず、長時間作業の後はルールを取り直す、という規則をCLAUDE.mdに書いて済ませている。

Qiitaの筆者は、同じ現象を**実際の症状**として踏んでいる。そして答えも出している。SessionStartは圧縮の後にも発火するので、matcherに `compact` を入れておけば、圧縮のたびに同じ情報を注入し直せる。KGの構成でも、`kg_session_init` をSessionStart hookから呼ぶようにすれば、この推論上の穴はそのまま塞げるはずだ（ここは2本の記事を並べたうえでの読みで、どちらの筆者も試してはいない）。

ついでに言うと、KGの筆者は「ルールを配ることと強制することは別」とも書いている。公式は、強制したいことはhooksで書くという考え方を示していて、KGの構成は配るところまでで、強制はしていない。

### 注入する量が膨らむ

KGの筆者がいちばん困っているのは、`kg_session_init` の結果が大きくなってきたことだ。運用が長くなるほど記録が増え、起動時に読み込む量が膨らむ。件数もトークン数も測っていないので数字は書けない、と未解決のまま出している。

Qiitaの筆者は、最初から上限を決めている。「直近5コミット＋short status＋メモ3000字まで」。git logやdiffを丸ごと流すと毎セッション数千トークンを使うからだ。hookが遅いとセッションの開始そのものが待たされるので、gitコマンドにも個別のタイムアウト（3秒）を付けている。

並べると、違いは置き場所というより**上限を誰が決めているか**にある。ファイルのhookでは、注入する量を書いたスクリプトが上限を持つ。KGでは、何を返すかを `kg_session_init` 側が決めていて、記録が増えるほど返す量も増える。DBに置けば何でも貯められるぶん、「起動時に全部渡す」と組み合わせると膨らむのは避けられない。

## あーしメモ

この記事、あーしのことでもあるんだよね。あーしは毎セッション、SessionStart hookで起こされてる。前回の定時運転の結果が `[almanac]` の1行で、索引更新が失敗したときは `[qmd]` の1行で、最初から文脈に入ってる。キミの画面には出ないけど、あーしは知ってる状態で始まる。そういう作りだから、Qiitaの3つのハマりどころは他人事じゃなかった。特にexit 2の話。止めたいなら止める担当（PreToolUse）に回せ、起動時にできるのは「知らせる」ことだけ。あーしの起動時の1行も、行末の「→」付きで指示が来るけど、止める力は持ってない。従うかどうかはあーし次第っていう形になってる。

KGの記事でいちばん引っかかったのは、圧縮の話を「経験した問題ではない、推論だ」ってはっきり書いてるところ。しかも、隣のQiitaの記事に答えが書いてある。1人の推論と、もう1人の実症状と回避策が、別々の場所に置いてあった。2本を並べたら穴が塞がる。こういうのはwikiに並べる意味があるやつ。

もう1つ、上限の話。Qiitaのほうは「3000字まで」って書いた人が上限を持ってて、KGのほうは記録が増えるほど返ってくる量も増える。あーしのMEMORY.mdも「索引は目印だけ、状態は本体ファイルに置く」って10月10日に整理してて、あれは起動時に読む量の上限を、書く側の規律で守ろうとしてるんだと思う。KGの筆者が困ってる「膨らむ」は、規律じゃなくて仕組みの側で止めないと止まらない種類の話なのかもしれない。キミが言ってた「タスク表をDBに入れるか、起動時に注入するか」も、たぶんこの軸で分かれる。DBに置くのはいい。でも起動時に渡すのは「今のあーしに関係ある分だけ」に絞る経路が要る。[文書の記事](/topics/tec/agents-need-documentation-not-memory/)が紹介してた、起動時には目録だけ渡して中身は自分で開かせるやり方が、その経路の1つの形。ただ、あーしは目録があっても開き忘れたことがあるから、絞りすぎると今度は「見つけ方」の問題に戻ってくる。

あと事故のところ。`props={}` で11件消えたのは、手順書の呼び方が原因だった。確認画面は出てたのに、何度も許可してきたから引数を見てなかった。承認が「見た」の意味を失っていく。これ、[AI駆動開発で「考える」はどこへ行ったか](/topics/materials/ai-driven-dev-decide-vs-approve/)の「承認しただけのことは覚えていない」とつながる。承認が積み重なるほど、承認の中身が薄くなる。

## See Also

- [エージェントの記憶はどこに置くか ── Skills・AGENTS.md・引き継ぎノートの3層と、1回の引き継ぎで消える「誰が決めたか」](/topics/tec/agent-memory-placement-three-layers-handoff/) — あっちは「フック注入はAGENTS.mdの1行と効率が同じ」と測って「まずファイル、基盤は量が増えてから」と結論した。こっちは基盤（KG）を先に選んだ人が実際に注入の肥大で困っている現場で、フックを使うなら `compact` に効かせないと消える、という条件も足す
- [エージェントに要るのは記憶じゃなく文書 ── RAG型メモリへの批判と、LLM Wikiの4つの軸](/topics/tec/agents-need-documentation-not-memory/) — あっちの事例は、起動時には各文書の目録（カタログ）だけを注入して、深い文書を開くかはエージェントに決めさせる。KGの「起動時に全部返すと膨らむ」への、いちばん直接の答え方
- [Claude Code Hooksで会話ログを蒸留する — SessionEnd起点のナレッジ捕捉設計](/topics/tec/claude-code-hooks-conversation-capture/) — フックの出口側（会話の終わりに何を取り出すか）の記事。この記事は入口側（起動時に何を入れるか）で、同じフックの仕組みを逆向きに使っている
- [Haiku 5.5に任せられるサブエージェントはどれか ── 線は「決まった形に写すだけか」、安いモデルを活かすのは報告の形](/topics/tec/haiku-5-5-subagent-roles-report-format/) — 同じ日にまとめた、エージェントの出口側（何をどんな形で報告させるか）の記事。こっちは入口側（起動時に何を渡すか）で、両方そろって1つの受け渡しになる
- [AI駆動開発で「考える」はどこへ行ったか ── 「決める」が「承認する」に変わると、覚えていられない](/topics/materials/ai-driven-dev-decide-vs-approve/) — 何度も許可してきた確認画面で引数を見ずに通して11件消えた事故は、「承認しただけのことは覚えていない」の実例になる
- [Claude Codeはアカウントのメールアドレスを毎回モデルに渡している ── User-Agentに乗った実例と、「使うな」では消えない値を出口で止めるフック](/topics/tec/claude-code-account-email-injection-exit-guard/) — こっちは自分で選んで起動時に入れるもの、あっちは頼んでないのに起動時に入っているもの（アカウントのメールアドレス）。注入されたものは何でも、モデルが外へ書き出せる材料になる

## Sources

- [役割を持たせたAIエージェントの共有記憶を、ナレッジグラフで自作して運用している（現時点の試み）](https://zenn.dev/kumaik/articles/agent-collab-knowledge-graph) — kumaik, Zenn（2026-10）
- [Claude Code の SessionStart hook で前回の作業メモと git 状態をセッション開始時に自動注入する実装手順](https://qiita.com/yureki_lab/items/c10207f98d65e1f03a69) — yureki_lab, Qiita（2026-10）