elias/everything-claude-code
1
0
Fork 0
mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-05-18 21:31:15 +08:00
Code Issues Packages Projects Releases Wiki Activity
everything-claude-code/docs/ja-JP/commands/save-session.md
Claude ec9ace9c54 docs: add native Japanese translation of ECC documentation (ja-JP) 
Translate everything-claude-code repository to Japanese including:
- 17 root documentation files
- 60 agent documentation files
- 80 command documentation files
- 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web)
- 199 skill documentation files

Total: 455 files translated to Japanese with:
- Consistent terminology glossary applied throughout
- YAML field names preserved in English (name, description, etc.)
- Code blocks and examples untouched (comments translated)
- Markdown structure and relative links preserved
- Professional translation maintaining technical accuracy

This translation expands ECC accessibility to Japanese-speaking developers and teams.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-05-17 02:31:40 -04:00

13 KiB
Raw Blame History

description
description
現在のセッション状態を日付付きファイルとして ~/.claude/session-data/ に保存し、完全なコンテキストを持った状態で将来のセッションで作業を再開できるようにします。

セッション保存コマンド

このセッションで起こったすべてのこと（何を構築したか、何がうまくいったか、何が失敗したか、何が残っているか）をキャプチャし、日付付きファイルに書き込みます。これにより、次のセッションはこのセッションが中断した場所から正確に再開できます。

使用するタイミング

  • Claude Codeを閉じる前の作業セッションの終了時
  • コンテキスト制限に達する前（まずこれを実行し、その後新しいセッションを開始する）
  • 記憶しておきたい複雑な問題を解決した後
  • 将来のセッションにコンテキストを引き継ぐ必要がある任意のタイミング

プロセス

ステップ1: コンテキストの収集

ファイルを書き込む前に、以下を収集します：

  • このセッション中に変更されたすべてのファイルを確認する（git diffを使用するか、会話から思い出す）
  • 議論した内容、試みた内容、決定した内容を振り返る
  • 発生したエラーとその解決方法（または未解決の場合はその旨）を記録する
  • 関連がある場合、現在のテスト/ビルドの状態を確認する

ステップ2: セッションフォルダが存在しない場合は作成する

ユーザーのClaudeホームディレクトリに正規のセッションフォルダを作成します：

mkdir -p ~/.claude/session-data

ステップ3: セッションファイルを書き込む

~/.claude/session-data/YYYY-MM-DD-<short-id>-session.tmp を作成します。今日の実際の日付と、session-manager.js の SESSION_FILENAME_REGEX が適用するルールを満たすshort-idを使用します：

  • 互換性のある文字: 英字 a-z / A-Z、数字 0-9、ハイフン -、アンダースコア _
  • 互換性のある最小長: 1文字
  • 新規ファイルの推奨スタイル: 小文字、数字、ハイフンで8文字以上（衝突を避けるため）

有効な例: abc123de、a1b2c3d4、frontend-worktree-1、ChezMoi_2 新規ファイルでは避けるべき例: A、test_id1、ABC123de

完全な有効ファイル名の例: 2024-01-15-abc123de-session.tmp

レガシーファイル名 YYYY-MM-DD-session.tmp も引き続き有効ですが、新しいセッションファイルは同日の衝突を避けるためshort-id形式を推奨します。

ステップ4: 以下のすべてのセクションをファイルに記入する

すべてのセクションを正直に記入してください。セクションをスキップしないでください。セクションに本当に内容がない場合は「Nothing yet」または「N/A」と記入してください。不完全なファイルは、正直な空のセクションよりも悪い結果をもたらします。

ステップ5: ファイルをユーザーに表示する

書き込み後、完全な内容を表示し、以下のように尋ねます：

セッションを [セッションファイルへの実際の解決パス] に保存しました。

内容は正確ですか？閉じる前に修正や追加はありますか？

確認を待ちます。要求があれば編集します。

セッションファイルの形式

# セッション: YYYY-MM-DD

**開始:** [わかる場合はおおよその時刻]
**最終更新:** [現在の時刻]
**プロジェクト:** [プロジェクト名またはパス]
**トピック:** [このセッションの内容を一行で要約]

---

## 構築しているもの

[機能、バグ修正、またはタスクを説明する1〜3段落。このセッションの記憶がゼロの人でも
目標を理解できる十分なコンテキストを含めてください。
含めるべき内容: 何をするのか、なぜ必要なのか、大きなシステムにどのように適合するのか。]

---

## うまくいったこと（証拠付き）

[動作が確認されたものだけをリストしてください。各項目について、なぜ動作すると
わかるのかを含めてください — テストが通った、ブラウザで動作した、Postmanが200を返した、など。
証拠がない場合は、代わりに「まだ試していないこと」に移動してください。]

- **[動作するもの]** — 確認方法: [具体的な証拠]
- **[動作するもの]** — 確認方法: [具体的な証拠]

確認済みの動作がまだない場合: 「確認済みの動作はまだありません — すべてのアプローチが進行中またはテスト未実施です。」

---

## うまくいかなかったこと（理由付き）

[これは最も重要なセクションです。試みて失敗したすべてのアプローチをリストしてください。
各失敗について正確な理由を記入し、次のセッションが同じことを再試行しないようにしてください。
具体的に: 「YのためにXエラーが発生した」は有用です。「動かなかった」は有用ではありません。]

- **[試みたアプローチ]** — 失敗理由: [正確な理由 / エラーメッセージ]
- **[試みたアプローチ]** — 失敗理由: [正確な理由 / エラーメッセージ]

失敗がない場合: 「失敗したアプローチはまだありません。」

---

## まだ試していないこと

[有望に見えるがまだ試みていないアプローチ。会話の中で出たアイデア。
検討する価値のある代替ソリューション。次のセッションが何を試すべきか
正確にわかるよう、十分に具体的に記述してください。]

- [アプローチ / アイデア]
- [アプローチ / アイデア]

キューに入っているものがない場合: 「特定の未試行アプローチは特定されていません。」

---

## ファイルの現在の状態

[このセッションで触れたすべてのファイル。各ファイルの状態を正確に記述してください。]

| ファイル              | ステータス         | メモ                      |
| ----------------- | -------------- | -------------------------- |
| `path/to/file.ts` | PASS: 完了    | [何をするか]             |
| `path/to/file.ts` |  進行中 | [完了部分、残り部分] |
| `path/to/file.ts` | FAIL: 壊れている      | [何が問題か]             |
| `path/to/file.ts` |  未着手 | [計画済みだが未着手]  |

ファイルが触れられていない場合: 「このセッションではファイルの変更はありません。」

---

## 決定事項

[アーキテクチャの選択、受け入れたトレードオフ、選択したアプローチとその理由。
これにより、次のセッションが既に決定された事項を蒸し返すのを防ぎます。]

- **[決定]** — 理由: [代替案よりもこれを選んだ理由]

重要な決定がない場合: 「このセッションでは大きな決定はありませんでした。」

---

## ブロッカーと未解決の質問

[次のセッションで対処または調査する必要がある未解決の事項。
出てきたが回答されなかった質問。待機中の外部依存関係。]

- [ブロッカー / 未解決の質問]

ない場合: 「アクティブなブロッカーはありません。」

---

## 正確な次のステップ

[わかっている場合: 再開時に行うべき最も重要な単一のこと。
開始場所について考える必要がないほど正確に記述してください。]

[わかっていない場合: 「次のステップは未定です — 方向性を決める前に
『まだ試していないこと』と『ブロッカー』セクションを確認してください。」]

---

## 環境とセットアップに関するメモ

[関連がある場合のみ記入 — プロジェクトの実行に必要なコマンド、
必要な環境変数、実行中である必要があるサービスなど。標準的なセットアップの場合はスキップ。]

[ない場合: このセクション全体を省略してください。]

出力例

# セッション: 2024-01-15

**開始:** 約14時
**最終更新:** 17:30
**プロジェクト:** my-app
**トピック:** httpOnlyクッキーによるJWT認証の構築

---

## 構築しているもの

Next.jsアプリのユーザー認証システム。ユーザーはメールアドレスとパスワードで登録し、
httpOnlyクッキー（localStorageではなく）に保存されたJWTを受け取り、保護されたルートは
ミドルウェアを通じて有効なトークンを確認します。目標は、トークンをJavaScriptに
公開することなく、ブラウザのリフレッシュ間でセッションの永続性を実現することです。

---

## うまくいったこと（証拠付き）

- **`/api/auth/register` エンドポイント** — 確認方法: Postman POSTがユーザーオブジェクト付きの200を返し、
  Supabaseダッシュボードで行が確認でき、bcryptハッシュが正しく保存されている
- **`lib/auth.ts` でのJWT生成** — 確認方法: ユニットテストが通る
  （`npm test -- auth.test.ts`）、jwt.ioでデコードしたトークンが正しいペイロードを表示
- **パスワードハッシュ化** — 確認方法: テストで `bcrypt.compare()` がtrueを返す

---

## うまくいかなかったこと（理由付き）

- **Next-Authライブラリ** — 失敗理由: カスタムPrismaアダプターと競合し、
  すべてのリクエストで「Cannot use adapter with credentials provider in this configuration」をスロー。
  デバッグする価値なし — 我々のセットアップには意見が強すぎる。
- **localStorageへのJWT保存** — 失敗理由: SSRレンダリングはlocalStorageが利用可能になる前に行われ、
  すべてのページ読み込みでReactのハイドレーション不一致エラーが発生。
  このアプローチはNext.jsのSSRと根本的に互換性がない。

---

## まだ試していないこと

- ログインルートのレスポンスでJWTをhttpOnlyクッキーとして保存する（最も可能性の高いソリューション）
- `next/headers` の `cookies()` を使用してサーバーコンポーネントでトークンを読み取る
- クッキーの存在を確認してルートを保護するmiddleware.tsを書く

---

## ファイルの現在の状態

| ファイル                             | ステータス         | メモ                                           |
| -------------------------------- | -------------- | ----------------------------------------------- |
| `app/api/auth/register/route.ts` | PASS: 完了    | 動作確認済み、テスト済み                                   |
| `app/api/auth/login/route.ts`    |  進行中 | トークンは生成されるがクッキーの設定はまだ      |
| `lib/auth.ts`                    | PASS: 完了    | JWTヘルパー、すべてテスト済み                         |
| `middleware.ts`                  |  未着手 | ルート保護、クッキー読み取りロジックが先に必要 |
| `app/login/page.tsx`             |  未着手 | UIは未着手                                  |

---

## 決定事項

- **localStorageよりhttpOnlyクッキー** — 理由: XSSトークン盗難を防ぎ、SSRで動作する
- **Next-Authよりカスタム認証** — 理由: Next-AuthがPrismaセットアップと競合し、闘う価値がない

---

## ブロッカーと未解決の質問

- `cookies().set()` はRoute Handler内で動作するのか、それともServer Actions内でのみか？確認が必要。

---

## 正確な次のステップ

`app/api/auth/login/route.ts` で、JWTを生成した後、
`cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })` を使用して
httpOnlyクッキーとして設定する。
その後Postmanでテスト — レスポンスに `Set-Cookie` ヘッダーが含まれるはず。

注意事項

  • 各セッションには独自のファイルが割り当てられます — 以前のセッションのファイルに追記しないでください
  • 「うまくいかなかったこと」セクションが最も重要です — このセクションがないと、将来のセッションは失敗したアプローチを盲目的に再試行します
  • ユーザーがセッション途中（終了時ではなく）での保存を求めた場合、現時点でわかっていることを保存し、進行中の項目を明確にマークしてください
  • このファイルは次のセッションの開始時に /resume-session を通じてClaudeに読み込まれることを目的としています
  • 正規のグローバルセッションストアを使用してください: ~/.claude/session-data/
  • 新しいセッションファイルにはshort-idファイル名形式（YYYY-MM-DD-<short-id>-session.tmp）を推奨します