【Claude Code】1画面で可能な限り全ての業務を完結させるために、セッション管理アプリを作った

この記事の概要

Claude Code の全セッションを1画面で一覧・操作できるローカル Web アプリ csviz を自作した話です。Go と vanilla JS の単一バイナリで、外部ライブラリへの依存はありません。

タブとウィンドウの往復、実行許可の見落とし、作業を切り替えるたびの思い出し作業を無くすのが目的です。いまはセッションの閲覧・送信・許可応答に加えて、定型業務の定期実行までアプリの中で完結します。

記事の中心は「何ができて、何が解決したか」です。あわせて、作る過程で実測した Claude Code の内部仕様（セッション JSONL の構造、--resume の挙動、モデルがプロセス起動時に固定されること）と、そこでの設計判断も書いています。

経緯

みなさん、Claude Code のセッション、今いくつ動いてますか？

僕は、開発ではVSCode 拡張、SKILL作成やログ調査はターミナル、技術調査はweb版のように使い分けをしており、
複数セッションを同時並行で動かしている際はウィンドウやタブを行ったり来たりしていました。

困っていたこと

このような使い方をしていた頃、困っていたことがいくつかありました。

1. 並行作業時の複数タブ・ウィンドウ移動が面倒

VSCode拡張もweb版も、基本1画面に1セッションの表示なので、並行で作業をする際はタブやウィンドウの切り替えが必要です。
その際、どのタブでどの作業をしていたかを探すという手間が発生し、とても面倒に感じていました。

2. 作業中の実行許可を忘れる・見逃す

別タブで走っているセッションで、コマンドや編集の実行許可を忘れてしまうパターンです。
他の作業に集中していて、ふと戻ってみたら実行許可待ちのまま止まっていたということもあります。

すぐに許可していたら今頃には完了していたと思うと、時間を無駄にしてしまったな...と思います。

3. 脳の切り替えが大変

複数の画面を切り替えながら作業をしていると、別の作業へ切り替える時に

• 作業内容は何だったか
• どこまで進めたか
• 後で指示しようと思っていたことがあった気がする

など、頭から一旦抜けていたことを思い出す必要がありました。

つまり、どのタブでどの会話をしていたか、そのタブがどこにあるか、会話の進み具合などを覚えておいて、必要に応じて切り替えながら作業する負担が大きかったです。

4. CLI版で、Claudeからの回答の Markdownがテキストのまま表示されて見づらい

見出しも表もコードブロックも記号のまま並ぶので、長い調査結果を読むのは負担が大きいです。
Web版のようにプレビュー形式でレンダリングして読みたいと考えていました。

これらを解決するために、GUI で複数セッションを一覧・可視化するローカルアプリを作ってみました。

着想をもらった2つの記事

このアプリは次の2記事から着想を得て実装しています。

1. Claude Codeのセッション管理、自作という選択肢もあり——hooksを理解しながら作ってみた

Claude Code の hooks でセッション監視ダッシュボードを自作された記事です。「複数セッションが並立するとどのタブで何が起きているか分からなくなる」という課題設定がそのまま僕の悩みで、各セッションが稼働中なのか入力待ちなのかをカンバンで可視化する、というアイデアをここでもらいました。

僕のアプリは hooks ではなく後述の JSONL 直読み方式を選びましたが、「セッションの状態を横断して1画面に出す」という方針は、この記事から得たものです。

2. Claude Codeですべての日常業務を爆速化しよう！

経費精算や月末の定常業務など、コーディング以外の日常業務を Claude Code で回すという記事です。こちらは記事後半で書く「日常タスク」機能に直結しています。

実際、日常タスク機能の実装計画を立てるときは、この記事でやられている運用と自分のアプリを突き合わせて、足りないものだけを洗い出すという進め方をしました。

足りなかったもの	記事での実現方法	このアプリでの実現方法
トリガー（定期実行）	Amazon EventBridge + Bedrock AgentCore	アプリの常駐プロセスに内蔵。既定は手動実行
入口（業務カタログ）	業務ごとのリポジトリと手順書	タスクタブ + タスク定義ファイル
結果の回収	Slack 通知	ブラウザ通知 + タブの要対応バッジ + 結果ファイル

前提

• Claude Code v2.1.220 〜 v2.1.224 での実機検証がベースです（2026年8月時点）
• 記載する JSONL の構造や CLI の挙動はバージョンによって変わる可能性があります
• その後 9月現在も必要に応じて機能追加を続けており、この記事を書いている時点の手元は v2.1.267 です

なぜ自作したのか

自作したのは以下の理由です。

1. 自分の仕事のやり方に合わせて自由に機能追加・修正ができる（よくhtmlで資料を作成するので、アプリ内で開けるようにしたいなど）
2. claudeからのmd形式の回答をレンダリングできるので、CLIよりも視覚的にわかりやすい
3. 可能な限り外部依存をなくし、外部ライブラリ汚染などによる問題を避けたい

最終的に目指しているところ

そのうえで、最終的に、このアプリの中で、可能な限りすべての業務が完結することを目標として随時機能追加をしています。

調査を頼む、結果を読む、資料を開く、差分を確認する、許可を出す、定型業務を回すなどを、全てブラウザのタブ1枚で済ませたいということです。

記事の前半は「セッションを見失わないための可視化ツール」の話で、後半はこの目標に向けて足していった機能について紹介します。

作ったもの

csviz（Claude Session Visualizer）という名前のローカル Web アプリです。

go run . するとローカルにサーバーが立ち、ブラウザで全セッションを一覧・操作できます。

セッション一覧

会話ビュー

主な機能は以下のとおりです。

機能	内容
セッション一覧	全プロジェクトのセッションをカードで一覧。更新が新しい順。状態（動作中/直近活動/待機）と TODO 進捗を表示
会話ビュー	複数セッションを 横並びのペインで同時表示。
リアルタイム反映	ポーリング + SSE※。VSCode やターミナルでのやり取りも自動で画面に出る
送信・新規開始	GUI から Claude にメッセージを送れる。権限確認や選択肢にも GUI のボタンで応答できる
セッション分岐	git branch の思想で、会話の任意の時点から履歴を引き継いだ新セッションを作る
資料プレビュー	Claude が作った HTML 資料や画像をアプリ内で表示
使用量表示	プランのレート制限使用率をヘッダーに常時表示

※ SSE（Server-Sent Events）は、サーバーからクライアントへHTTP接続を維持したまま一方向にテキストデータを継続配信する仕組みです。
ブラウザのEventSource APIで簡単に受信でき、チャット通知やリアルタイム更新など軽量な用途によく使われます。

ここまでが最初の数日で作った範囲です。その後に足したものは記事の後半にまとめます。

規模感

項目	v0（2026-08-12）	現在（2026-09-11）
コミット数	73	96
Go（テスト除く）	3,329行	7,101行
Go テスト	1,838行	4,388行
フロント（JS/CSS/HTML）	3,051行	5,581行
外部ライブラリ依存	0	0

※行数は find + wc -l の概算です。依存ゼロというのは、go.mod の require が空のまま・npm も未使用、という意味です。

依存ゼロは意図的にそうしました。理由は後述します。

一覧を作る仕組み

Claude Code は、セッションの全履歴を ローカルの JSONL ファイル に書き出しています。

~/.claude/projects/<作業ディレクトリをエンコードしたディレクトリ名>/<session-id>.jsonl

1行1エントリの JSON Lines で、中身は次のような形です（抜粋・整形しています）。

{
  "type": "user",
  "message": { "role": "user", "content": "このバグの原因を調べて" },
  "uuid": "5d7434b7-...",
  "parentUuid": "ee02d987-...",
  "sessionId": "105021d5-...",
  "cwd": "/Users/you/github/your_project",
  "gitBranch": "feature/xxx",
  "timestamp": "2026-08-10T03:46:54.129Z",
  "entrypoint": "claude-vscode"
}

つまり、このディレクトリを監視して JSONL をパースすれば、誰が作ったセッションでも中身が読めます。ターミナルで動かそうが VSCode 拡張で動かそうが、記録先は同じなので一元管理できます。

主な type の一例

type	内容	アプリでの用途
user	ユーザー発話	会話表示
assistant	Claude の応答（content[] に text / tool_use）	会話表示・ツール実行の把握
ai-title	自動生成されたタイトル	一覧のセッション名
last-prompt	直近のプロンプト	一覧のサブテキスト
attachment	todo_reminder（TODO の状態）	進捗バー
system	compact_boundary など	圧縮完了の通知表示

未知の type は読み飛ばす 方針にしています。Claudeのバージョン更新で知らない type が増えても、他のエントリの表示を維持するためです。

開発の進め方

最初から実装せず、要件定義所や設計書、UIモックなどを先に作り、それぞれ都度レビューしながら進めました。

AI に「〇〇作って」と丸投げすると、意図と違うものができた際の手戻りや、なぜその作りになっているのかを 自分が説明できなくなるためです。
以前書いた激詰レビュワーSKILLの記事と同じ問題意識です。

実際には、こういう順番で進めました。

1. 要件定義書（HTML）→ レビュー → 修正
2. 基本設計・詳細設計書（HTML）→ レビュー → 修正
3. UI モック（フロントだけで動くもの）→ レビュー → 修正
4. 実装
5. 単体テスト → 結合テスト
6. 動作チェック・README
7. 使いながら改善

各工程の資料ができた時点で必ず止めさせて、僕がレビューしてから次に進めています。

これにより、例えばモックの段階で「送信ボタンと使用量表示が重なっている」「一覧は全画面3〜4列がいい」など細かい指摘を先にできたため、実装後の手戻りを減らせました。

技術選定（go + vanilla JS）

フロントは vanilla JS（素の JavaScript）です。ビルドツールも使っていません。<script src="app.js"> を読むだけです。

理由として一番大きいのは配布性です。「go build で単一バイナリ作成・依存ゼロ」を最優先の要求にしていたので、TS/Vue/React を入れて node + npm のツールチェーンがビルドに必須になると、この前提が成り立たなくなります。

また、個人ツールに脆弱性追随の保守コストを持ち込みたくない、という気持ちもありました。

フロントについては、型がないというデメリットがありますが、Claudeで開発することと、規模が小さめのため問題ありません。

型による検査が欲しくなる複雑なロジックは、全部 Go 側にあります。JSONL のパース、履歴チェーンの抽出、状態判定あたりです。フロントは fetch して表示するだけなので、TS の恩恵が薄いと判断しました。

Go 側も標準ライブラリのみで、go.mod の require は空のままです。HTTP サーバーも SSE も JSON パースも標準ライブラリで足りました。

Markdown 描画も自前で書いた

Claude の応答は Markdown なので、描画が必要になります。ライブラリ等を使うか迷いましたが、自前で書きました（300行くらい）。セキュリティ上、そのほうが安全だと判断したためです。

ライブラリ方式は innerHTML + サニタイザで「防ぐ」構図になるので、1箇所の適用漏れ・設定ミスで回避されます。自前実装なら createElement + textContent だけで組み立てられるので、HTML 文字列を一度も経由しません。つまり XSS が構造的に発生しません。

HTML 文字列を経由すると、たとえば次のようなコードで XSS が起こります。

// NG: Markdown を HTML 文字列に変換してから innerHTML に入れる
// Markdown はインライン HTML をそのまま通す仕様なので、この <img> は変換後も残る
const answer = '調査結果です <img src=x onerror="fetch(\'/api/sessions\', { method: \'POST\', body: attack })">';

bubble.innerHTML = renderMarkdown(answer); // ← 画像の読み込みに失敗した時点で onerror が実行される

innerHTML は 渡した文字列をHTMLとして解釈して描画するためonerrorが実行されてしまいます。

自前実装では、要素を createElement で作り、文字は textContent に入れます。

// OK: HTML 文字列を作らないので、タグとして解釈される経路がそもそも無い
const bubble = document.createElement("div");
bubble.textContent = answer; // <img src=x onerror="..."> はそのまま文字として表示される

つまづいた点

ここからは、作ってみて初めて分かった Claude Code の挙動です。目立ちませんが実用上は重要なものを選びました。

① モデルは プロセス起動時 に決まる

アプリにモデル選択機能を実装する前に、あるセッションで作業中にFableの使用量が切れそうになりました。

そこで、VSCode拡張側で同じセッションを開き、 fable から opus にモデルを変えて、opus で応答されることを確認し、その後アプリ側GUI からメッセージを送ると You've reached your Fable 5 limit. が返ってきました。

原因は、GUI 側の常駐プロセスが起動時のモデル（fable）を保持し続けていたことでした。
つまり、VSCode拡張とこのアプリが、同一セッションを別プロセスで開いており、VSCode側のプロセスにのみOpusへの変更が反映された状態です。

claude CLI のモデルは起動時の --model（未指定ならセッションが直前に使ったモデル）で決まり、稼働中のプロセスに外部からモデル変更を反映する手段がありません。VSCode の /model は VSCode プロセス内の状態なので、別プロセスには伝わりません。

対処として、GUI で違うモデルを指定されたら常駐プロセスを一度落として起動し直す実装にしました。

// CLI はモデルを起動時にしか決められないため、
// 常駐プロセスと異なるモデルを指定されたら作り直す
needRestart := s != nil && s.model != model
if needRestart {
    r.Stop(sessionID)
    r.waitGone(sessionID)
}

② 会話が伸びると読み込みトークンは二次関数的に積み上がる

LLM API はステートレスなので、毎ターン履歴全体を送っていますが、このアプリを使う中で想像以上に一気に増えたので驚きました。

このアプリの開発セッション（JSONL 17.8MB）を実測したところ、

• 1メッセージあたりの読み込み量: 序盤 50K → 終盤 680K トークン
• 応答1,184回の累計: cache_read 466M / cache_create 23M / 出力 1.6M

会話長に比例して1回あたりが増えるので、累計は二次関数的に伸びます。

ただし大半は プロンプトキャッシュの読み取り として処理されていて、生の input_tokens は非常に小規模でした。キャッシュによる削減がかなり大きいです。

長い調査セッションを延々 --resume （会話履歴の全送信）し続けるより、区切りのいいところで分岐させたりcompactした ほうが効率がいい というのが実感です。

セッション分岐と、その家系図

調査タスクや実装をやっていると、「1, 2, 3 まで調査や実装が進んだ状態から、3-a と 3-b に分けてそれぞれ試したい」ということがあります。

そこで、git の branch と同じ発想で、会話履歴の任意の箇所からセッションを分岐させる機能を追加しています。

JSONLファイルに含まれる parentUuid を遡って履歴チェーンを抽出し、新しい session id を振って別ファイルとして書き出すだけです。元のファイルは一切変更しません。

// 分岐点から親を遡ってチェーンを集め、
// session id と cwd を書き換えて新しい JSONL として書き出す
func CreateBranch(srcPath, atUUID string) (string, error) {
    // ...
}

そして先日、その分岐の親子関係を家系図として表示する機能 を追加しました。

作業の区切りで分岐して引き継いできた履歴がここで確認できます。

工夫した点

分岐に付けた「実装引き継ぎ」といったラベルは、VSCode のセッション履歴一覧には反映されません。

理由は、ラベルをこのアプリ専用の管理ファイルにしか保存していないからです。分岐は親の JSONL をコピーするだけなので、VSCode がタイトルに使う aiTitle フィールドは親のものが複製されるだけです。

これは意図的に、元のセッションデータは一切改変しないよう実装しています。Claude Code 公式のスキーマに存在しないフィールドを、外部アプリが勝手に足すべきではない と考えたためです。

権限確認に GUI から答える

最初、GUI からの送信は claude -p のヘッドレス実行でやっていました。これだと権限確認（「このコマンドを実行していい？」）に答えられません。

そこで、--input-format stream-json --output-format stream-json --permission-prompt-tool stdio で 常駐する双方向プロセス として起動する方式に変えました。

• --input-format stream-json: ユーザーの発言をJSON形式でstdin経由で送り込む
• --output-format stream-json: 応答をJSON形式でstdout経由で逐次出力する
• --permission-prompt-tool: 実行許可の確認を対話UIではなく指定したツールに委ねる

つまり、「人間がターミナルで対話する代わりに、GUIツールがstdin/stdoutを通じてJSONでCLIプロセスと会話し、許可確認もGUI側で処理する」というオプションです。

こうすると、権限確認が control_request として stdout に流れてくるので、それを GUI にカードとして出して、ユーザーが押したボタンの結果を control_response として stdin に書き戻せます。

AskUserQuestion（Claude からの選択肢付き質問）にも同じ仕組みで応答できるようにしました。ターミナルとほぼ同じ対話体験がブラウザで得られます。

無応答のまま放置されると危ないので、10分で自動拒否、30分アイドルでプロセス終了、という安全弁も入れています。

「許可待ちで止まっている」を無くす

ただ、これだけだと冒頭に書いた不満（別タブの実行許可を忘れて作業が止まる）が半分しか解決していませんでした。確認カードはそのセッションのペインを開いていないと見えないからです。

そこで、待っている確認をヘッダーの「⏳ 確認待ち N」に集約して、どのタブにいても、どのダイアログを開いていても、その場で答えられるようにしました。

• 確認が出た時点でパネルが開く（探して押す操作が要らない）
• 資料プレビューや差分ビューを開いたままでも押せる（パネルが出ている間はダイアログが左に寄る）
• 自動拒否までの残り時間を秒単位で表示する

これにより、別タブでの実行許可忘れによる作業中断がほぼ0になりました。

「アプリ内で業務が完結する」ことを目指す

ここまででは、まだ「セッションを見失わないためのビューア」でした。

ここからは冒頭に書いた目標、アプリの中で業務が完結することに向けて足していった機能の話です。「作業のどこでアプリの外に出てしまうか」を一つずつ解消していく、という進め方をしました。

確認作業をアプリの中で完結させる

アプリの外に出ていた場面	足した機能
「何を変更したのか」を確認しに IDE へ戻る	セッション内の編集差分を、リポジトリ / ブランチごとにファイル一覧化。クリックで GitHub 風の赤緑差分
Claude が作った HTML 資料をブラウザの別タブで開く	モーダルにて資料プレビュー。ペインヘッダーの「📄 資料」ボタンから、作った資料を一覧・常時表示
長いツール実行で「何を頼んだか」が上に流れて見失う	直近に送った依頼を会話エリアの上端にピン留め
夜に目がやられる	配色の切替（自動 / ライト / ダーク）。既定は OS 追従

差分ビューアは、実現可能性の調査の時点で方針が決まりました。JSONL には Edit / Write の差分がそのまま記録されているため、差分を自前で計算する必要がありませんでした。作業ツリーの現在の状態にも依存しないので、そのセッションで何をしたかを後から純粋に振り返れます。

複数ブランチにまたがる作業をする場合を考慮し、git diffはここでは使用していません。
現状は、push前に軽く修正内容を確認しておきたい場合などに利用しています。

ひとつだけ慎重にしたのが .env などの秘匿ファイルです。差分をそのまま出すと認証情報が画面に載ってしまうので、メタ情報（編集回数・増減行数・時刻）だけを出して、本文はサーバー側で保持も配信もしないようにしました。画面上はグレーアウト + 🔒 でクリックできません。

定型業務をボタン1つで回す

ここが、Claude Codeですべての日常業務を爆速化しよう！ に着想をもらった部分です。

「タスク」タブに定型業務をカードで並べて、ボタン1つで実行できるようにしました。タスクの定義は Markdown ファイル1枚です。
以下は朝の仕事始めに実行するタスクの一例です。

---
name: 未レビューPRチェック
group: 日次チェック
model: haiku
approval: propose # ask（通常確認）/ auto（自動承認）/ propose（提案のみ）
schedule: 平日 09:00
usage_guard: 70 # 5時間枠の使用率が70%を超えていたら実行しない
---

以下2つのタスクを実施し、それぞれ結果を返す。

1. 未レビューPRチェック
レビュワーに自分自身が含まれている open な PR のうち、自分が既にレビューを提出したものを除いて、
リポジトリ・タイトル・リンクを表で出力してください。1件も無ければ「対象なし」とだけ返してください。

2. レビューされた自身のPRチェック

Assigneesに自分が含まれているPRのうち、前回の本タスク実行日時から現在時刻の間に、github actions等によるAIレビューを除く"人間メンバー"からのレビューやコメント、approve、change requestなどがあった場合、そのリポジトリ・タイトル・リンクを表で出力してください。進捗がないものは対象外です。

前回の本タスク実行日時が不明な場合はその旨も報告し、"過去1日の間"で検索してください。

frontmatter が実行条件、本文がそのまま Claude への依頼文になります。Claude Code のスキル（SKILL.md）と同じ書式にしたので、エディタからでも Claude 自身にでも編集させられます。

設計で意識したのはこのあたりです。

判断	理由
業務の手順そのものは ~/.claude/skills 側に置いたままにできる	アプリは「起動する・見張る・結果を受け取る」だけの薄いハブに徹する。手順を二重管理しない
タスクの実行セッションはセッション一覧に出さない	定期実行のたびにカードが増えて一覧が埋まるため
承認レベルを3段階（通常確認 / 自動承認 / 提案のみ）でタスクごとに選べる	「調べて提案するだけ」の業務にまで毎回許可を出したくない
使用量ガード（5時間枠が指定値を超えていたら実行せずスキップ）	定期実行が枠を使い切って、本業の作業ができなくなるのを防ぐ

現状は、

• 先ほど挙げた確認すべきPRの調査
• Notion記載の議事録を確認したうえで、進捗があった件についてまとめる
• claudeへの自身の指示傾向分岐とrule更新
• 過去に実施した業務のまとめを作成

などを登録してみています。今まではターミナルから/task_nameのような形で手動実行していたので実行忘れがありましたが、やるべきことが可視化することで忘れることがなくなりました。

自分だけのツールで終わらせない

社内の他メンバーにも使ってもらえる状態にしました。

依存ゼロなので、クロスコンパイルは Go だけで完結します。タグを push すると GitHub Actions がテスト → 3ターゲット分のビルド → Release 作成 → バイナリ添付までやってくれます。

配布物	対象
csviz_darwin_arm64	Mac（Apple Silicon）
csviz_linux_amd64 / csviz_linux_arm64	Linux・WSL

配布を前提にすると、自分だけで使っていたときには見えなかった問題が出てきます。

• コード署名をしていないので、ブラウザでダウンロードすると Gatekeeper に止められる（gh / curl 経由なら隔離属性が付かないので大丈夫、という案内を README に書いた）
• そもそも使い方が分からない

最後の点への対策として、ヘッダーに「QA」ボタンを付けました。使い方の知識をバイナリに焼き込んで、専用のチャットセッションが操作方法だけに答えます。リポジトリを持っていない人でも動くようにするためで、ツールは無効にしてあるので環境は触られません。既定モデルは sonnet で、サブスクリプションの利用枠で回答できるようにしています（他人が使う機能なので、トークン消費は控えめにしておきたかった）。

副次的な良かったこと

このアプリを使い始めた頃は、5時間や週の利用枠を使い切ってしまうことがありました。

初期は本アプリ自体の修正も多かったことや、複数セッションを並行で回せるようになったぶん、チャットの量が増えました。GUI で全部見えていると、つい「ついでにこれも」と頼んでしまいます。

おかげで、それまで後回しにしていたトークンを効率的に使うための設定をまとめて整えることになりました。

• 定型の作業は軽いモデル（haiku / sonnet）のサブエージェントに任せる
• 重い推論が要る場面だけ advisor に相談する
• 出力を絞る（成功したテストの一覧やビルドログは返させない、など）

サブエージェントは ~/.claude/agents/ に Markdown を置くだけで定義できます。実際に使っている例を2つ載せておきます。

## <!-- ~/.claude/agents/test-runner.md -->

name: test-runner
description: テストスイートを実行し失敗のみ報告する。テスト実行が必要なときに使用。
model: haiku

---

テストを実行し、以下だけを報告してください：

- 失敗したテスト名
- エラーメッセージと該当ファイル・行番号
- 推定される原因(1〜2行)

成功したテストの一覧やビルドログは報告に含めないでください。

## <!-- ~/.claude/agents/log-analyzer.md -->

name: log-analyzer
description: ログファイルを解析しエラーパターンを抽出する。ログ調査が必要なときに使用。
model: haiku
effort: low

---

ログから ERROR / WARN を抽出し、パターンごとに集約して報告してください。
発生回数、代表的な1件のスタックトレース、時系列上の偏りのみを返します。
生ログは貼り付けないでください。

model で軽いモデルを指定することと、「何を報告しないか」を書くことが重要です。ログ調査もテスト実行も、生の出力をそのまま親セッションに戻すと、それがそのままコンテキストに積み上がってしまいます。

ヘッダーに使用量を常時出しているので、残り枠を見ながら「この作業はサブエージェントに任せるか」を判断する、という使い方に落ち着きました。

まとめ

個人的な不便から始めて、数日で一通り動くところまで来ました。そこからさらに1か月ほど、アプリの中で業務が完結するという目標に向けて機能を足しています。

今後も随時機能追加して、効率化していきたいですね。

参考

• Claude Code 公式ドキュメント: https://docs.claude.com/en/docs/claude-code/overview
• Claude Codeのセッション管理、自作という選択肢もあり——hooksを理解しながら作ってみた（エムスリーテックブログ）
• Claude Codeですべての日常業務を爆速化しよう！（@minorun365）
• ※本記事に記載した JSONL の構造や CLI の挙動は、v2.1.220〜v2.1.224 での実機検証に基づく非公式な調査結果です。将来のバージョンで変更される可能性があります。