Claude Code v2.1.108徹底解説｜/recap・Skill経由スラコマ・プロンプトキャッシュ1時間TTLで何が変わるか

Claude Code v2.1.108リリース｜「長時間エージェント運用」を楽にする3つの新機能

2026年4月14日、Anthropicは Claude Code v2.1.108 をリリースした。マイナーバージョンだが、セッションの復帰・ツール呼び出し・キャッシュという「長時間エージェント運用の3つの痛点」に対する手当てが同時に入っており、日常的にClaude Codeを使うチームには 設定を見直す動機がある程度にはある アップデートだ。一方で後述するように「全員が即座に有効化すべき」とまでは言えない微妙な制約もある。

▲ 関連機能デモ: Monitor toolでエージェントが背景プロセスを監視する様子（Anthropic公式動画より）

注目すべきは以下の3機能：

1. /recap — セッション復帰時に過去文脈を自動サマリ挿入
2. Skill経由のスラッシュコマンド自動呼び出し — /init・/review・/security-review をモデルが自律起動
3. プロンプトキャッシュ1時間TTL — 長時間セッションのAPIコスト削減

いずれも全OS（macOS/Linux/Windows）共通のアップデートで、今すぐ claude update で適用できる。本記事では この3機能が何を変えるのか、どう使うのか、既存ワークフローにどう統合するか を実例ベースで徹底解説する。

/recap機能｜長時間ブランク後のセッション復帰を省力化

Claude Codeを日常的に使う開発者なら、必ず経験する「数時間後にターミナルに戻ったら、何をやっていたか忘れている」問題。特にリモート作業で昼休みや会議を挟んだ後、文脈を再確認するだけで5〜10分溶かすことも珍しくなかった。

v2.1.108の /recap は、この問題を AI側から能動的に解決 する機能だ。セッションに戻った時に、それまでの対話内容を要約して自動で文脈を再ロードしてくれる。

基本的な使い方

手動で実行する場合：

# セッションで数時間ぶりに戻ってきた時
/recap

実行すると、それまでの対話履歴をモデルが要約して「何をしていたか」「次に何をすべきか」を構造化テキストで提示する。

自動化する場合は /config で設定：

/config
# UIから auto-recap を有効化

これでブランク後に最初のプロンプトを送ると、裏で自動的に /recap が走り、文脈要約が先頭に挿入される。

テレメトリ無効環境での強制有効化

企業環境などで DISABLE_TELEMETRY=true にしている場合、デフォルトでは /recap の自動実行が無効になる。これを強制有効化するには：

export CLAUDE_CODE_ENABLE_AWAY_SUMMARY=true
claude

.bashrc や .zshrc に書き込んでおけば、プライバシー設定を維持したまま /recap を恒常的に使える。

/recap の実際の出力イメージ

📋 セッション要約（過去3時間の対話）

目的: Next.js 15プロジェクトのauth middleware実装

進捗:
- ✅ middleware.ts の基本構造を作成
- ✅ Supabase統合の型定義を追加
- 🔄 JWT検証ロジックを実装中（まだテスト未通過）
- ❌ E2Eテストの構成はこれから

未解決の懸念:
- リフレッシュトークンの有効期限をどう扱うか未決
- 本番環境での cookie.domain 設定を確認する必要あり

次のアクション候補:
1. JWT検証の単体テストを完成させる
2. リフレッシュトークン戦略を決める
3. E2Eテスト雛形をCypressで作る

手動でログをスクロールするより、要約を先に出してもらった方が復帰が速い——というのが /recap の実用価値だ。ただし後述の通り、要約そのものが完璧とは限らない点は理解しておく必要がある。

/recap の制約と失敗パターン

使ってみると分かる実際的な制約：

• 非常に長いセッション（数千ターン）では要約が粗くなる — モデルが履歴全体をコンテキストに入れて要約するため、トークン上限に近づくと重要度の低い詳細が削られる。極端なケースでは「最後のファイル編集が議事から抜ける」ことも
• 日本語混在セッションは英語より要約精度が下がる傾向 — 非公式な挙動だが、英語のみのセッションで出た要約の方が構造的に整うことが多い。日本語でやり取りする場合は /recap 後にもう1度「この要約で抜けている点は？」と問い直すと補完される
• /recap 自身がトークンを消費する — キャッシュの1時間TTLと組み合わせてもゼロコストではない。コスト意識の強いチームは /recap を「使う場面を絞る」運用が現実的
• DISABLE_TELEMETRY=true の環境では自動実行しない — 強制有効化の環境変数は用意されているが、意図的にオプトアウトしている組織は手動実行を前提に設計すべき
• 要約はあくまで「人間向けのリマインダー」 — モデルが要約を読んだ後に続行するので、重要な決定（例: 「このAPIは削除しないと決めた」）が要約に含まれるかは運賈次第。クリティカルな決定は CLAUDE.md に転記しておく方が確実だ

Skill経由のスラッシュコマンド自動呼び出し｜モデルがコマンドを「探して使う」時代へ

v2.1.108の最も本質的な変化は、スラッシュコマンドを「ユーザーが覚えて打つもの」から「モデルが自律的に探して呼び出すもの」に変えたことだ。

何が変わったか

従来は、/init・/review・/security-review といったビルトインのスラッシュコマンドは、ユーザーが明示的に入力する必要があった。

# 従来: ユーザーが手動で打つ
/review src/auth/middleware.ts

v2.1.108では、モデルが Skillツール経由でスラッシュコマンドを検出・呼び出し可能 になった。

ユーザー: 「この認証ミドルウェアをセキュリティ観点でレビューして」

↓

モデル（内部動作）:
  Skill tool で /security-review コマンドを検出
  → /security-review を自動実行
  → 結果を解釈してユーザーに返す

ユーザーはコマンド名を覚えなくていい。自然言語で依頼すれば、モデルが適切なコマンドを選んで実行する。これはClaude Skillsの仕組みとスラッシュコマンドを統合する、地味だが重要な変化だ。

対応する3つのビルトインコマンド

v2.1.108時点でSkill経由で呼び出せるコマンド：

実際の動作フロー

ユーザー側のメリット

• コマンド名を覚える必要がない: 自然言語で頼めばよい
• 新しいビルトインコマンドが追加されても自動的に使える: モデルが発見してくれる
• カスタムスラッシュコマンド（.claude/commands/）もSkill経由で呼ばれる: 自作コマンドの活用頻度が上がる

/undo → /rewind エイリアス化

関連して /undo が /rewind のエイリアスとして追加された。タイプミスで /undo を打ってしまう人のUX改善。地味だが歓迎される変更だ。

プロンプトキャッシュ1時間TTL｜長時間セッションのAPIコスト大幅削減

3つ目の目玉機能は、プロンプトキャッシュの保持時間を従来の5分から1時間に拡張 できるようになったこと。長時間のコーディングセッションでは、これだけでAPIコストが半分以下に下がるケースもある。

従来の問題：5分キャッシュの制約

Claude APIのプロンプトキャッシュ機能は、同じシステムプロンプト・ツール定義・ファイル内容を繰り返し送信する際にキャッシュヒットさせて通信コストを削減する仕組みだ。だが従来の TTL（生存時間）は5分 だった。

これが実務では以下の問題を引き起こしていた：

• 考え事・会議・離席で5分以上経過 → キャッシュ失効
• 次のメッセージで全コンテキストを再送信 → フルコスト
• 長時間セッションでは 無駄な再送信が常態化

v2.1.108の解決策：1時間TTLのopt-in

環境変数1つで、プロンプトキャッシュのTTLを1時間に拡張できる。

# ~/.bashrc または ~/.zshrc に追加
export ENABLE_PROMPT_CACHING_1H=true

# 即時反映
source ~/.bashrc
claude

対応するバックエンド：

• Anthropic API直接（APIキー利用）
• AWS Bedrock
• Google Vertex AI
• Azure AI Foundry

5分TTLを強制したい場合

逆に何らかの理由で5分TTLを維持したい場合：

export FORCE_PROMPT_CACHING_5M=true

企業のコスト管理ルールで短時間キャッシュしか許可していない環境で活用する。

DISABLE_TELEMETRY利用者向けの修正

v2.1.108以前、DISABLE_TELEMETRY=true を設定しているサブスクリプション利用者は、1時間TTLのopt-inを指定していても なぜか5分TTLにフォールバックする不具合 があった。v2.1.108でこの問題が修正され、テレメトリ無効環境でも正しく1時間TTLが動くようになっている。

コスト削減インパクトの試算

長時間セッションほど削減効果が大きいため、日常的にClaude Codeを使うチームは有効化を検討する価値がある。ただし後述の制限を理解した上での判断が必要だ。

1時間キャッシュの注意点・制限事項

「長時間TTLにすればコスト半分」という単純な話ではない。実際には以下の制約がある：

• キャッシュヒットも完全無料ではない — Anthropic APIの料金表では、キャッシュヒット時は 通常の約10%のコスト がかかる。9割引ではあるが「ゼロ円」ではない点は会計処理で重要
• キャッシュキーはコンテキスト全体の組み合わせ — システムプロンプト・ツール定義・先頭ファイル群の順序と内容がハッシュ化されてキーになる。つまり ツール追加・CLAUDE.md 編集・/model 切替 のいずれかでキャッシュは即失効する。1時間TTLにしても日常作業で失効は普通に起きる
• キャッシュ書き込み側のコストは発生する — 初回のキャッシュ書き込みには 通常の約25%上乗せ の料金がかかる（1.25倍）。短時間で失効させる運用だと「書き込み損」になる。5分以上連続で同じコンテキストを叩くケースでは5分TTLの方が安いことさえある
• エンタープライズ環境の既定値は従来通り5分 — 企業利用では ENABLE_PROMPT_CACHING_1H=true を明示的に有効化しないと1時間TTLにはならない。デプロイ戦略として「まずdevチームで有効化→効果測定→全社展開」が無難
• 観測可能性は /cost コマンドで — v2.1.108（同時期の改善）で /cost がキャッシュヒット率・モデル別内訳を出すようになった。有効化した後は必ず /cost で実効率を確認すること

# キャッシュ効率を検証する手順
/cost
# → per-model / cache-hit breakdown を確認
# 目安: hit率 >60% なら1時間TTL有効化の価値あり
#       hit率 <30% ならコンテキスト設計を見直す

試算表は理想値——実運用では コンテキスト変更の頻度 がそれ以上に効く。1時間TTLの真価を引き出すには「システムプロンプトや主要ファイル群を作業開始時に固めて、途中で足さない」設計規律がセットで必要だ。

その他の改善｜/resume・/model・小さな修正

3つの目玉機能の他にも、実用性を高める改善が多数入っている。

/resume ピッカーの改善

過去セッションを再開する /resume コマンドの挙動が変わった。

現在のプロジェクトで作業中にセッションを再開したい時、関係ない他プロジェクトのセッションに埋もれる問題が解消された。

/model 切替時の警告

会話の途中で別モデルに切り替えると、キャッシュ失効やコンテキスト解釈の差で混乱することがある。v2.1.108では /model で切り替える前に警告が表示される。

⚠️  別モデルへの切替はキャッシュを失効させます。続行しますか？
   現在: claude-opus-4-6
   切替先: claude-sonnet-4-6
   [Y/n]

/login コードプロンプトのpaste修正

v2.1.105で /login 時にコード入力欄にpasteが効かないregressionが発生していたが、v2.1.108で修正。2段階認証コードを正しく貼り付けられるようになった。

多言語モードでのdiacritical mark保持修正

言語設定を有効にすると、モデル応答から é・ü・ç などのdiacritical mark（アクセント記号・ウムラウト等）が欠落する不具合があった。v2.1.108で修正済み。フランス語・ドイツ語・スペイン語等のコードベースで作業する開発者には重要な修正だ。

「thinking hints」の高速化

長い処理中に「考え中…」というヒント表示が出るまでの時間が短縮された（v2.1.107での変更）。ユーザー体感で「反応がない」と感じる時間が減る。

アップデート方法と検証手順｜3分で完了

アップデート

# 一番簡単
claude update

# バージョン確認
claude --version
# → 2.1.108 以降が表示されればOK

各OS別の代替手段

新機能の動作確認

アップデート後、以下の順で動作確認するとスムーズ。

# 1. /recap の動作確認
claude
> /recap
# → 現セッションが空なら「過去の対話がありません」と返る

# 2. プロンプトキャッシュ1時間TTL opt-in
export ENABLE_PROMPT_CACHING_1H=true
claude
# → 長いコンテキストで連続質問してキャッシュヒット率を計測

# 3. Skill経由スラコマの確認
claude
> このファイルをセキュリティ観点でレビューして src/auth/middleware.ts
# → モデルが内部で /security-review を呼び出すか観察

実務でv2.1.108を使い倒す｜3つのワークフロー改革

3機能がどう連携して効いてくるかを図で整理する。

3機能を組み合わせると、日常のエージェント運用が根本的に変わる。

ワークフロー1：長時間の大規模リファクタ

従来は「リファクタ対象を宣言→1時間で切断→5分以上離席→キャッシュ失効→続きを頼むとゼロから再送信」が常態だった。

v2.1.108後：

# 環境変数を一度だけ設定
export ENABLE_PROMPT_CACHING_1H=true

# 朝イチで /init でプロジェクト初期化（モデル経由で呼ばれる）
claude
> このリポの構造を分析して、リファクタ計画を立てて
  （モデルが /init を Skill 経由で呼ぶ）

# 数時間働く

# 昼食後に戻る
> /recap
  （過去の進捗が要約される）

# 続きの作業を自然言語で指示
> さっきのauth周り、次はJWT検証テストを完成させよう
  （1時間キャッシュが効いているのでコスト低）

ワークフロー2：PRレビューのバッチ処理

複数PRをレビューする際、従来は /review を手動で叩いていた。v2.1.108では自然言語で依頼するだけ：

> GitHub PRの #123・#124・#125 を連続でレビューして、
  各PRの主要な懸念点と改善提案を3つずつまとめて

モデルがPRごとに /review を Skill経由で自動呼び出し、結果を集約する。1時間キャッシュのおかげで、同じリポジトリコンテキストが使い回されて効率的だ。

▲ 関連機能デモ: Ultraplan（クラウドでプラン作成→ローカルで実行）。Week 15の新機能で、v2.1.108の/recapと組み合わせると長時間セッションの効率がさらに上がる。

ワークフロー3：セキュリティ監査の定期実行

週次のセキュリティ監査も、自然言語指示で完結する。

> 認証・セッション管理・API endpointsの3領域について
  セキュリティ観点でレビューして、重要度順に issue 案を作って

モデルが /security-review を3回（領域ごとに）呼び出し、結果を統合してissueテンプレを生成する。

▲ 関連機能デモ: /autofix-pr — ブランチから1コマンドでPRの自動修正を有効化。v2.1.108のSkill経由スラコマと組み合わせると完全自動化が射程に入る。

セキュリティと権限の考慮点｜盲点になりがちな3つ

新機能の利便性と引き換えに、企業導入・機密プロジェクトで注意すべき点がある。公式ドキュメントには明示されていないが、メカニズム的に発生しうるリスクだ。

1. Skill経由スラコマの「意図しない起動」

モデルがユーザー発話を解釈して /security-review や /init を自動で呼び出すようになった。これは基本的には便利だが、機密コードベースで予期せぬコマンドが走る可能性 がある。例えば「ちょっとこのファイル見て」と軽く依頼しただけで /security-review が起動し、社外に出せないコードの詳細がモデル側で再解釈される——というケースは論理的に起こりうる。

対策：

# ビルトインスラッシュコマンドの自動呼び出しを抑制したい場合、
# settings.json でSkillツール側の動作を絞る
{
  "skills": {
    "disableModelInvocation": ["security-review", "init"]
  }
}

権限モデルが厳しい組織では、disableModelInvocation で明示的に無効化するか、/config で自動起動を切る運用が無難だ。

2. /recap と監査ログの関係

/recap はセッション履歴をモデルに再要約させる。これは 社内監査ログ・SIEM・DLP の観点では「古いセッションデータの再参照」として扱われる可能性がある。データ分類ポリシーが厳しい組織では、CLAUDE_CODE_ENABLE_AWAY_SUMMARY=false で無効化してから本格展開する方が安全。

3. 1時間キャッシュとデータ保持

キャッシュはAnthropic側のインフラに1時間保持される。通常はエンドツーエンドで暗号化され他テナントから隔離されるが、機密性の高いプロンプト・ソースを頻繁に送るワークフロー では保持時間が延びること自体を議論すべき場面がある。EnterpriseプランのCustomer Data Processing契約を再確認しておく価値がある。

Windows環境での実戦｜PowerShell / Git Bash / WSL2 の挙動差

v2.1.108の新機能は全OS共通だが、Windowsで どのシェル環境で動かすか で体験が変わる。実際に各環境を触るとぶつかる差異を整理する。

PowerShellの強み（v2.1.85以降）

Week 13で入った「native PowerShell tool for Windows」により、Claude Codeが bash ツール相当のコマンドをPowerShellネイティブで実行できるようになった。これにより：

# Claude CodeがBashツール呼び出しを裏でPowerShellに変換
# ユーザー視点では意識不要
> このプロジェクトで失敗したテストを走らせて
# → 内部で `pnpm test --filter=failed` がPowerShellで実行される

Windows主ユーザーは PowerShell + Windows Terminal の組み合わせが推奨される。v2.1.108の /recap や Skill経由スラッシュコマンドも、環境差なく動作する。

Git Bashの向き・不向き

Git Bashは「Unix的なシェル体験がWindowsで欲しい」という要望に応える選択肢だが、make・sh スクリプト・grep パイプライン多用プロジェクトでは有用。ただし：

• パス変換の罠：/c/Users/Name/project 形式に変換されるため、AIが生成するスクリプトで直接 C:\... を期待すると動かないことがある
• バックグラウンドプロセスの扱いが弱い：v2.1.108で強化された Monitor ツールは動くものの、sleep 系でまれに挙動不安定になる
• Windows Defender干渉頻度が高い：MSYS2のパスが監視対象になりやすい

Git Bashを使うなら、CLAUDE_CODE_PERFORCE_MODE のように 環境変数で挙動を明示 しておくのが無難だ。

WSL2の圧倒的優位（エンジニアリング系なら第一選択）

Linux環境を前提に設計されたClaude Codeの多くの機能は、WSL2で動かすのが最も自然 だ。特に：

• ファイルシステムの一貫性：WSL2の ext4 上で作業すればパス変換・権限問題ゼロ
• パフォーマンス：ファイル監視・ビルドが Windows ネイティブより数倍速い（Node.js系で顕著）
• VSCode Remote-WSL統合：VSCodeを「WSL2内のLinuxプロジェクトを編集する」モードで起動すると、ターミナルもVSCode内でWSL2に自動切替
• Bedrock/Vertex統合も素直：Week 15で入った認証ウィザードもLinux版の方が先行して安定している

結論：用途別の推奨構成

Claude Desktop（Cowork）との統合運用｜エンジニア・非エンジニア併用のベストプラクティス

Claude Codeだけでなく、Claude Desktop（Cowork）をWindows端末に同居 させる構成は、2026年春時点で最も実戦的な「フルスタックAI業務環境」になっている。v2.1.108は前者のアップデートだが、チーム運用では両方を理解しておく意味がある。

基本の役割分担

v2.1.108はClaude Code専用アップデート。Claude Desktop側は別系統のアップデートサイクルで進化している（2026-04-09にWindows版Cowork GA）。

Windows上で両方を同居させる構成

Windows 11
├─ Claude Desktop (Cowork)                    # 業務側
│   ├─ Cowork機能: ファイル/Excel/PDF処理
│   ├─ 11種プラグイン: GitHub/Notion/Slack/Jira...
│   └─ Customize Tab: Skills・Connectors管理
│
├─ Claude Code (PowerShell/WSL2)              # 開発側
│   ├─ v2.1.108: /recap・Skill連動・1H cache
│   ├─ Monitor tool / Ultraplan / autofix-pr
│   └─ GitHub連携（OAuth or GitHub App）
│
└─ claude.ai (ブラウザ)                        # 補助
    └─ アーティファクト試作・軽量チャット

この3レイヤーが揃うと、ユースケースごとに最適なツールへ自然に手が伸びる 環境になる。開発中はClaude Code、Excelレポート作成はCowork、ちょっとしたアイデア出しはWeb、というように作業粒度と相性がマッチする。

実際の使い分けシナリオ例

シナリオ1：朝のセットアップ

1. PowerShellで claude 起動 → /recap で前日コンテキスト復元
2. 並行してClaude Desktop起動 → Coworkで受信メールから「今日やるべきこと」を自動ブリーフ生成
3. ブラウザでclaude.aiを開いて、チーム朝会用のスライド素材を即興生成

シナリオ2：PR作成〜レビュー〜デプロイ

1. Claude Codeで実装 → /autofix-pr でPR自動修正有効化
2. Claude Desktop（Cowork）でSlackプラグイン経由にPRリンク投稿＋社内連絡
3. レビューコメントがSlack経由で来たら、Claude Codeに戻って対応

シナリオ3：月次レポート生成

1. Claude Desktop（Cowork）で部署別Excelを集計 → 統合ダッシュボードExcel生成
2. Claude CodeでそのExcelを読んでREADMEのKPIセクションを自動更新
3. GitHub Actionsに組み込んだClaude Code (/autofix-pr) が自動でPR作成

プラグイン活用の Windows 特化Tips

Claude DesktopのプラグインはWindows版でも11種すべて動作する。Windows環境で特に相性が良いのは：

• Slack: Windows通知センターと統合、投稿/リマインド通知が取りこぼされない
• Google Drive: Windowsのエクスプローラ統合と合わせて、GDrive同期フォルダを Cowork-Workspace/input/ にすることで自動供給が効く
• GitHub: PowerShell版のGit/GH CLIと並行使用可能、認証情報はWindows Credential Managerに保持される
• Notion: Windows版Notion Desktop Appと併用で「編集はNotion、分析はCowork」の切り分けが明確

トレードオフ：両方使うリソース負荷

Desktop + Code + ブラウザを同時稼働すると、RAM消費の合計が2〜3GB規模 になる。8GB以上の搭載は事実上必須。ノートPCで常用する場合は16GB以上が無難だ。また、Claude Desktopはバックグラウンドで常時VMを一つ立てているため、バッテリー駆動時は消費が増える点にも留意。

まとめ｜2026春の「長時間エージェント運用」が変わる

Claude Code v2.1.108は、マイナーバージョンながら 日常の痛点に手当てを入れた実用的な3機能 を同時追加した。/recap によるセッション復帰、Skill経由のスラコマ自動化、プロンプトキャッシュ1時間TTL——いずれも「長時間Claude Codeを使うほど効いてくる」改善だ。一方で、キャッシュの書き込みコスト・Skillの意図しない自動起動・要約の精度限界など、全員が即座に採用すべきとまでは言えない制約も同時に抱えている。

Windows特化でもデスクトップアプリ刷新でもなく、全OS共通のClaude Code CLIアップデート として今日から claude update で即有効化できる。あわせて2026-04-09の Claude Cowork Windows GA も踏まえて、非エンジニア向けにはClaude Cowork入門ガイド、Claude Code全般の運用指針にはベストプラクティス完全ガイド、スキル活用にはClaude Skills徹底解説、Karpathy流の指針にはandrej-karpathy-skills CLAUDE.mdと組み合わせて使うのが2026春時点の標準構成になる。

参照ソース

• Claude Code Changelog — v2.1.108の公式リリースノート
• anthropics/claude-code (GitHub) — 本体リポジトリ
• Claude公式サポート — 設定・機能解説
• @claudeai (X公式) — 本記事で引用したアナウンスポスト
• Claude Cowork リリースノート（2026-04-09） — Windows GA情報