動的セッションコンテキスト

セッションに必要なコンテキストはタスクによって異なる。ブログ記事を書くならブランドボイスとSEOワークフローが必要だ。機能をリリースするならアーキテクチャのメモとコーディングスタイルが求められる。デバッグではシステム図と該当するエラー処理ルールが必要になる。

それらをすべてCLAUDE.mdに詰め込んでClaudeが必要なものを拾ってくれることを期待することもできる。あるいは、各セッションタイプに合わせたコンテキストを渡すこともできる。

シンプルな解決策

プロンプトは Claude Code の --init フラグの直後に置く:

claude --init "/blog"

Claude が起動すると同時に /blog スラッシュコマンドが即座に実行される。ブログセッションに必要なものはすべてそのコマンドの中に収まっている: ライティングルール、コンテンツワークフロー、サンプル投稿、内部リンク先。

セットアップフックはゼロ。環境変数もゼロ。ファイルコピーもゼロ。コンテキストを保持するコマンドファイルが1つあるだけだ。

このページは、適切なバンドルでセッションを開始することについて説明している。肥大化したセッションを後から管理する方法ではない。Claude が何を見るべきか、いつ見るべきか、ウィンドウから何を除外すべきかを決めようとしているなら、コンテキストエンジニアリングを読んでほしい。セッションが迷走しているときに回復しようとしているなら、コンテキスト管理を読んでほしい。フック重視の自動化については、Claude Code フックを読んでほしい。

セットアップフックが過剰になるとき

セットアップフックは2026年1月25日にリリースされた。その目的は、決定論的なスクリプトとエージェント的な監視を組み合わせることだ: 依存関係のインストール、データベースの初期化、定期メンテナンス作業。

ただし、セッションタイプごとのシンプルなコンテキストロードには、セットアップフックは省略できる余分な仕組みを持ち込んでしまう。スラッシュコマンドなら、より少ない部品で同じゴールに到達できる。

私たちの実装

ブログ執筆セッションで使用しているレイアウトは以下の通り:

.claude/
  commands/
    blog.md     # コマンド内に埋め込まれたコンテキスト
justfile        # ランチャーショートカット

ブログセッションが必要とするものはすべて blog.md の中にある: ボイスガイド、ワークフローのメモ、ティアロードの指示、SEOチェック、投稿間のリンクルール。

justfile がショートカットを提供する:

blog:
    claude --init "/blog"

just blog と入力すると、Claude はブログコンテキストをすでにメモリに持った状態で起動する。ボイスは設定済み。リンクルールも設定済み。ワークフローはあなたからの指示なしに自動で動く。

コンテキストコマンドに何を入れるか

優れたセッションコマンドは4つの要素をカバーする:

スタートアップメッセージ: セッションタイプを明示し、コンテキストがロードされたことを確認する。

ワークフロードキュメント: この種の作業における各ステップのプロセス。

参照資料: セッション全体にわたって適用されるすべてのルール、サンプル、チェックリスト。

クオリティゲート: 作業完了と言えるための条件。

テンプレート:

---
description: Start a blog writing session with pre-loaded context
---
 
# Blog Session
 
You are starting a blog/content writing session. Report: "Blog session started."
 
---
 
## Content Workflow
 
[Workflow steps and process documentation]
 
## Brand Voice
 
[Guidelines and patterns]
 
## Quality Checklist
 
[Verification steps before publishing]

すべてインラインに収まっている。コマンドを実行すれば、Claude はすべての情報をすでに持っている。

複数のセッションタイプ

作業モードごとに1つのコマンド:

.claude/commands/
  blog.md       # ブログ執筆コンテキスト
  feature.md    # 機能開発コンテキスト
  debug.md      # デバッグコンテキスト
  review.md     # コードレビューコンテキスト

それぞれが独自のルール、ワークフロー、参照セットを持つ。モードの切り替えは一言で済む:

just blog     # ブログ執筆
just feature  # 機能開発
just debug    # デバッグセッション

コピーすべき4つのセッションコマンド

抽象的に考えるのをやめて、実際のセッションタイプを名付け始めると、このパターンはより有用になる。

ブログセッション

claude --init "/blog"

ロード内容:

• ブランドボイス
• 内部リンクルール
• SEO / GEOチェックリスト
• 公開ワークフロー

機能セッション

claude --init "/feature"

ロード内容:

• アーキテクチャメモ
• コーディング標準
• テスト要件
• リリース制約

デバッグセッション

claude --init "/debug"

ロード内容:

• デバッグワークフロー
• ログの場所
• 再現チェックリスト
• ロールバックのセーフティルール

レビューセッション

claude --init "/review"

ロード内容:

• レビュールーブリック
• 深刻度の定義
• ブロッカーの基準
• 期待される出力形式

これが大きな利点だ。単にキーストロークを節約しているわけではない。各セッションタイプを正しい思考フレームで始めているのだ。

何をどこに置くか

最もクリーンなセットアップは、コンテキストを永続性によって分ける:

この分離がシステムを使いやすく保つ。すべてがCLAUDE.mdに入ると、すべてのセッションが肥大化した状態で始まる。すべてがフックに入ると、シンプルなコンテキストロードが必要以上に重くなる。

主なアンチパターン

よくある間違いは、1つの巨大なベースファイルですべてのコンテキスト問題を解決しようとすることだ。

それは通常、次のような結果につながる:

• 肥大化したCLAUDE.mdファイル
• 混在したワークフローが詰め込まれた状態
• すべてのタスクで無関係な指示がロードされる
• セッション開始時の集中力の低下

動的セッションコンテキストは、セッション固有のルールを明示的かつ一時的なものにすることでこれを解決する。ブログセッションにはブログルール。デバッグセッションにはデバッグルール。余計なものは一切ついてこない。

なぜこれが機能するのか

--init に渡したコマンドは、あなたが何かを入力する前に実行される。最初のメッセージを送るころには、コンテキストはすでに Claude の頭の中にある。「まずこれらのファイルを読んでください」という前置きは不要。すぐに作業に入れる。

スキルについても、同じトリックが正しいスキル設定を自動でロードする。CLAUDE.mdのオーバーライドについては、ベースファイルを汚染せずにセッション固有のルールが得られる。

最初はシンプルに保つこと。決定論的なスクリプト、インストール自動化、または起動時のエージェント的な監視が必要な日が来たら、セットアップフックに移行する。それまでは、スラッシュコマンドで十分なことがほとんどだ。ClaudeFast's Code Kit はこのパターンをそのまま実行している。その /blog、/team-plan、/build コマンドは、それぞれ1回の --init 呼び出しでセッション固有のコンテキスト、ワークフロー、クオリティゲートを読み込む。