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-18 14:53:05 +08:00 · 2026-05-16 20:12:58 +09:00
parent b66ae3fbe0
commit ec9ace9c54
376 changed files with 48957 additions and 0 deletions
--- a/docs/ja-JP/rules/common/agents.md
+++ b/docs/ja-JP/rules/common/agents.md
@@ -0,0 +1,49 @@
+# Agent オーケストレーション
+
+## 利用可能な Agent
+
+`~/.claude/agents/` に配置:
+
+| Agent | 目的 | 使用タイミング |
+|-------|---------|-------------|
+| planner | 実装計画 | 複雑な機能、リファクタリング |
+| architect | システム設計 | アーキテクチャの意思決定 |
+| tdd-guide | テスト駆動開発 | 新機能、バグ修正 |
+| code-reviewer | コードレビュー | コード記述後 |
+| security-reviewer | セキュリティ分析 | コミット前 |
+| build-error-resolver | ビルドエラー修正 | ビルド失敗時 |
+| e2e-runner | E2Eテスト | 重要なユーザーフロー |
+| refactor-cleaner | デッドコードクリーンアップ | コードメンテナンス |
+| doc-updater | ドキュメント | ドキュメント更新 |
+
+## Agent の即座の使用
+
+ユーザープロンプト不要:
+1. 複雑な機能リクエスト - **planner** agent を使用
+2. コード作成/変更直後 - **code-reviewer** agent を使用
+3. バグ修正または新機能 - **tdd-guide** agent を使用
+4. アーキテクチャの意思決定 - **architect** agent を使用
+
+## 並列タスク実行
+
+独立した操作には常に並列 Task 実行を使用してください:
+
+```markdown
+# 良い例: 並列実行
+3つの agent を並列起動:
+1. Agent 1: 認証モジュールのセキュリティ分析
+2. Agent 2: キャッシュシステムのパフォーマンスレビュー
+3. Agent 3: ユーティリティの型チェック
+
+# 悪い例: 不要な逐次実行
+最初に agent 1、次に agent 2、そして agent 3
+```
+
+## 多角的分析
+
+複雑な問題には、役割分担したサブ agent を使用:
+- 事実レビュー担当
+- シニアエンジニア
+- セキュリティエキスパート
+- 一貫性レビュー担当
+- 冗長性チェック担当
--- a/docs/ja-JP/rules/common/code-review.md
+++ b/docs/ja-JP/rules/common/code-review.md
@@ -0,0 +1,124 @@
+# コードレビュー基準
+
+## 目的
+
+コードレビューは、コードがマージされる前に品質、セキュリティ、保守性を確保します。このルールは、コードレビューの実施タイミングと方法を定義します。
+
+## レビューのタイミング
+
+**必須レビュートリガー:**
+
+- コードの作成または修正後
+- 共有ブランチへのコミット前
+- セキュリティに関わるコードが変更された場合（認証、決済、ユーザーデータ）
+- アーキテクチャの変更時
+- プルリクエストのマージ前
+
+**レビュー前の要件:**
+
+レビューを依頼する前に、以下を確認してください：
+
+- すべての自動チェック（CI/CD）が通過している
+- マージコンフリクトが解決されている
+- ブランチがターゲットブランチと最新状態である
+
+## レビューチェックリスト
+
+コードを完了とマークする前に：
+
+- [ ] コードが読みやすく、適切に命名されている
+- [ ] 関数が焦点を絞っている（50行未満）
+- [ ] ファイルが凝集している（800行未満）
+- [ ] 深いネストがない（4レベル以上）
+- [ ] エラーが明示的に処理されている
+- [ ] ハードコードされたシークレットや認証情報がない
+- [ ] console.logやデバッグ文がない
+- [ ] 新機能にテストが存在する
+- [ ] テストカバレッジが最低80%を満たしている
+
+## セキュリティレビュートリガー
+
+**以下の場合はsecurity-reviewerエージェントを使用してください：**
+
+- 認証または認可コード
+- ユーザー入力の処理
+- データベースクエリ
+- ファイルシステム操作
+- 外部APIコール
+- 暗号化操作
+- 決済または金融コード
+
+## レビュー重大度レベル
+
+| レベル | 意味 | アクション |
+|--------|------|------------|
+| CRITICAL | セキュリティ脆弱性またはデータ損失リスク | **BLOCK** - マージ前に修正必須 |
+| HIGH | バグまたは重大な品質問題 | **WARN** - マージ前に修正すべき |
+| MEDIUM | 保守性の懸念 | **INFO** - 修正を検討 |
+| LOW | スタイルまたは軽微な提案 | **NOTE** - 任意 |
+
+## エージェントの使用
+
+コードレビューには以下のエージェントを使用してください：
+
+| エージェント | 目的 |
+|-------------|------|
+| **code-reviewer** | 一般的なコード品質、パターン、ベストプラクティス |
+| **security-reviewer** | セキュリティ脆弱性、OWASP Top 10 |
+| **typescript-reviewer** | TypeScript/JavaScript固有の問題 |
+| **python-reviewer** | Python固有の問題 |
+| **go-reviewer** | Go固有の問題 |
+| **rust-reviewer** | Rust固有の問題 |
+
+## レビューワークフロー
+
+```
+1. git diffを実行して変更を理解する
+2. セキュリティチェックリストを最初に確認する
+3. コード品質チェックリストをレビューする
+4. 関連するテストを実行する
+5. カバレッジ >= 80%を検証する
+6. 詳細レビューに適切なエージェントを使用する
+```
+
+## よくある問題の検出
+
+### セキュリティ
+
+- ハードコードされた認証情報（APIキー、パスワード、トークン）
+- SQLインジェクション（クエリでの文字列連結）
+- XSS脆弱性（エスケープされていないユーザー入力）
+- パストラバーサル（未サニタイズのファイルパス）
+- CSRF保護の欠如
+- 認証バイパス
+
+### コード品質
+
+- 大きな関数（50行超）- より小さく分割
+- 大きなファイル（800行超）- モジュールを抽出
+- 深いネスト（4レベル超）- 早期リターンを使用
+- エラー処理の欠如 - 明示的に処理
+- ミューテーションパターン - イミュータブルな操作を優先
+- テストの欠如 - テストカバレッジを追加
+
+### パフォーマンス
+
+- N+1クエリ - JOINまたはバッチングを使用
+- ページネーションの欠如 - クエリにLIMITを追加
+- 制約のないクエリ - 制約を追加
+- キャッシュの欠如 - 高コスト操作をキャッシュ
+
+## 承認基準
+
+- **承認**: CRITICALまたはHIGHの問題なし
+- **警告**: HIGHの問題のみ（注意してマージ）
+- **ブロック**: CRITICALの問題が検出
+
+## 他のルールとの統合
+
+このルールは以下と連携します：
+
+- [testing.md](testing.md) - テストカバレッジ要件
+- [security.md](security.md) - セキュリティチェックリスト
+- [git-workflow.md](git-workflow.md) - コミット規約
+- [agents.md](agents.md) - エージェント委任
--- a/docs/ja-JP/rules/common/coding-style.md
+++ b/docs/ja-JP/rules/common/coding-style.md
@@ -0,0 +1,48 @@
+# コーディングスタイル
+
+## 不変性（重要）
+
+常に新しいオブジェクトを作成し、既存のものを変更しないでください:
+
+```
+// 疑似コード
+誤り:  modify(original, field, value) → original をその場で変更
+正解: update(original, field, value) → 変更を加えた新しいコピーを返す
+```
+
+理由: 不変データは隠れた副作用を防ぎ、デバッグを容易にし、安全な並行処理を可能にします。
+
+## ファイル構成
+
+多数の小さなファイル > 少数の大きなファイル:
+- 高い凝集性、低い結合性
+- 通常 200-400 行、最大 800 行
+- 大きなモジュールからユーティリティを抽出
+- 型ではなく、機能/ドメインごとに整理
+
+## エラーハンドリング
+
+常に包括的にエラーを処理してください:
+- すべてのレベルでエラーを明示的に処理
+- UI 向けコードではユーザーフレンドリーなエラーメッセージを提供
+- サーバー側では詳細なエラーコンテキストをログに記録
+- エラーを黙って無視しない
+
+## 入力検証
+
+常にシステム境界で検証してください:
+- 処理前にすべてのユーザー入力を検証
+- 可能な場合はスキーマベースの検証を使用
+- 明確なエラーメッセージで早期に失敗
+- 外部データ（API レスポンス、ユーザー入力、ファイルコンテンツ）を決して信頼しない
+
+## コード品質チェックリスト
+
+作業を完了とマークする前に:
+- [ ] コードが読みやすく、適切に命名されている
+- [ ] 関数が小さい（50 行未満）
+- [ ] ファイルが焦点を絞っている（800 行未満）
+- [ ] 深いネストがない（4 レベル以下）
+- [ ] 適切なエラーハンドリング
+- [ ] ハードコードされた値がない（定数または設定を使用）
+- [ ] 変更がない（不変パターンを使用）
--- a/docs/ja-JP/rules/common/development-workflow.md
+++ b/docs/ja-JP/rules/common/development-workflow.md
@@ -0,0 +1,44 @@
+# 開発ワークフロー
+
+> このファイルは [common/git-workflow.md](./git-workflow.md) を拡張し、Git操作の前に行われるフル機能開発プロセスを説明します。
+
+機能実装ワークフローは、開発パイプラインを説明します：調査、計画、TDD、コードレビュー、そしてGitへのコミット。
+
+## 機能実装ワークフロー
+
+0. **調査と再利用** _（新規実装の前に必須）_
+   - **まずGitHubコード検索：** 何か新しいものを書く前に、`gh search repos` と `gh search code` を実行して既存の実装、テンプレート、パターンを見つける。
+   - **次にライブラリドキュメント：** Context7またはベンダーの公式ドキュメントを使用して、API動作、パッケージ使用方法、バージョン固有の詳細を実装前に確認する。
+   - **最初の2つが不十分な場合のみExa：** GitHub検索と公式ドキュメントの後、より広範なウェブ調査や発見のためにExaを使用する。
+   - **パッケージレジストリを確認：** ユーティリティコードを書く前にnpm、PyPI、crates.ioなどのレジストリを検索する。手作りのソリューションよりも実績のあるライブラリを優先。
+   - **適応可能な実装を検索：** 問題の80%以上を解決し、フォーク、移植、またはラップできるオープンソースプロジェクトを探す。
+   - 要件を満たす場合、完全な新規コードよりも実績のあるアプローチの採用や移植を優先する。
+
+1. **まず計画**
+   - **planner**エージェントを使用して実装計画を作成
+   - コーディング前に計画ドキュメントを生成：PRD、アーキテクチャ、system_design、tech_doc、task_list
+   - 依存関係とリスクを特定
+   - フェーズに分割
+
+2. **TDDアプローチ**
+   - **tdd-guide**エージェントを使用
+   - まずテストを書く（RED）
+   - テストを通すように実装（GREEN）
+   - リファクタリング（IMPROVE）
+   - 80%以上のカバレッジを検証
+
+3. **コードレビュー**
+   - コード作成直後に**code-reviewer**エージェントを使用
+   - CRITICALとHIGHの問題に対処
+   - 可能な場合はMEDIUMの問題も修正
+
+4. **コミットとプッシュ**
+   - 詳細なコミットメッセージ
+   - Conventional Commitsフォーマットに従う
+   - コミットメッセージのフォーマットとPRプロセスについては[git-workflow.md](./git-workflow.md)を参照
+
+5. **レビュー前チェック**
+   - すべての自動チェック（CI/CD）が通過していることを確認
+   - マージコンフリクトを解決
+   - ブランチがターゲットブランチと最新状態であることを確認
+   - これらのチェックが通過した後にのみレビューを依頼
--- a/docs/ja-JP/rules/common/git-workflow.md
+++ b/docs/ja-JP/rules/common/git-workflow.md
@@ -0,0 +1,45 @@
+# Git ワークフロー
+
+## コミットメッセージフォーマット
+
+```
+<type>: <description>
+
+<optional body>
+```
+
+タイプ: feat, fix, refactor, docs, test, chore, perf, ci
+
+注記: Attribution は ~/.claude/settings.json でグローバルに無効化されています。
+
+## Pull Request ワークフロー
+
+PR を作成する際:
+1. 完全なコミット履歴を分析（最新のコミットだけでなく）
+2. `git diff [base-branch]...HEAD` を使用してすべての変更を確認
+3. 包括的な PR サマリーを作成
+4. TODO 付きのテスト計画を含める
+5. 新しいブランチの場合は `-u` フラグで push
+
+## 機能実装ワークフロー
+
+1. **まず計画**
+   - **planner** agent を使用して実装計画を作成
+   - 依存関係とリスクを特定
+   - フェーズに分割
+
+2. **TDD アプローチ**
+   - **tdd-guide** agent を使用
+   - まずテストを書く（RED）
+   - テストをパスするように実装（GREEN）
+   - リファクタリング（IMPROVE）
+   - 80%+ カバレッジを確認
+
+3. **コードレビュー**
+   - コード記述直後に **code-reviewer** agent を使用
+   - CRITICAL と HIGH の問題に対処
+   - 可能な限り MEDIUM の問題を修正
+
+4. **コミット & プッシュ**
+   - 詳細なコミットメッセージ
+   - Conventional Commits フォーマットに従う
--- a/docs/ja-JP/rules/common/hooks.md
+++ b/docs/ja-JP/rules/common/hooks.md
@@ -0,0 +1,30 @@
+# Hooks システム
+
+## Hook タイプ
+
+- **PreToolUse**: ツール実行前（検証、パラメータ変更）
+- **PostToolUse**: ツール実行後（自動フォーマット、チェック）
+- **Stop**: セッション終了時（最終検証）
+
+## 自動承認パーミッション
+
+注意して使用:
+- 信頼できる、明確に定義された計画に対して有効化
+- 探索的な作業では無効化
+- dangerously-skip-permissions フラグを決して使用しない
+- 代わりに `~/.claude.json` で `allowedTools` を設定
+
+## TodoWrite ベストプラクティス
+
+TodoWrite ツールを使用して:
+- 複数ステップのタスクの進捗を追跡
+- 指示の理解を検証
+- リアルタイムの調整を可能に
+- 細かい実装ステップを表示
+
+Todo リストが明らかにすること:
+- 順序が間違っているステップ
+- 欠けている項目
+- 不要な余分な項目
+- 粒度の誤り
+- 誤解された要件
--- a/docs/ja-JP/rules/common/patterns.md
+++ b/docs/ja-JP/rules/common/patterns.md
@@ -0,0 +1,31 @@
+# 共通パターン
+
+## スケルトンプロジェクト
+
+新しい機能を実装する際:
+1. 実戦テスト済みのスケルトンプロジェクトを検索
+2. 並列 agent を使用してオプションを評価:
+   - セキュリティ評価
+   - 拡張性分析
+   - 関連性スコアリング
+   - 実装計画
+3. 最適なものを基盤としてクローン
+4. 実証済みの構造内で反復
+
+## 設計パターン
+
+### Repository パターン
+
+一貫したインターフェースの背後にデータアクセスをカプセル化:
+- 標準操作を定義: findAll, findById, create, update, delete
+- 具象実装がストレージの詳細を処理（データベース、API、ファイルなど）
+- ビジネスロジックはストレージメカニズムではなく、抽象インターフェースに依存
+- データソースの簡単な交換を可能にし、モックによるテストを簡素化
+
+### API レスポンスフォーマット
+
+すべての API レスポンスに一貫したエンベロープを使用:
+- 成功/ステータスインジケーターを含める
+- データペイロードを含める（エラー時は null）
+- エラーメッセージフィールドを含める（成功時は null）
+- ページネーションされたレスポンスにメタデータを含める（total, page, limit）
--- a/docs/ja-JP/rules/common/performance.md
+++ b/docs/ja-JP/rules/common/performance.md
@@ -0,0 +1,55 @@
+# パフォーマンス最適化
+
+## モデル選択戦略
+
+**Haiku 4.5**（Sonnet 機能の 90%、コスト 3 分の 1）:
+- 頻繁に呼び出される軽量 agent
+- ペアプログラミングとコード生成
+- マルチ agent システムのワーカー agent
+
+**Sonnet 4.5**（最高のコーディングモデル）:
+- メイン開発作業
+- マルチ agent ワークフローのオーケストレーション
+- 複雑なコーディングタスク
+
+**Opus 4.5**（最も深い推論）:
+- 複雑なアーキテクチャの意思決定
+- 最大限の推論要件
+- 調査と分析タスク
+
+## コンテキストウィンドウ管理
+
+次の場合はコンテキストウィンドウの最後の 20% を避ける:
+- 大規模なリファクタリング
+- 複数ファイルにまたがる機能実装
+- 複雑な相互作用のデバッグ
+
+コンテキスト感度の低いタスク:
+- 単一ファイルの編集
+- 独立したユーティリティの作成
+- ドキュメントの更新
+- 単純なバグ修正
+
+## 拡張思考 + プランモード
+
+拡張思考はデフォルトで有効で、内部推論用に最大 31,999 トークンを予約します。
+
+拡張思考の制御:
+- **トグル**: Option+T（macOS）/ Alt+T（Windows/Linux）
+- **設定**: `~/.claude/settings.json` で `alwaysThinkingEnabled` を設定
+- **予算上限**: `export MAX_THINKING_TOKENS=10000`
+- **詳細モード**: Ctrl+O で思考出力を表示
+
+深い推論を必要とする複雑なタスクの場合:
+1. 拡張思考が有効であることを確認（デフォルトで有効）
+2. 構造化されたアプローチのために **プランモード** を有効化
+3. 徹底的な分析のために複数の批評ラウンドを使用
+4. 多様な視点のために役割分担したサブ agent を使用
+
+## ビルドトラブルシューティング
+
+ビルドが失敗した場合:
+1. **build-error-resolver** agent を使用
+2. エラーメッセージを分析
+3. 段階的に修正
+4. 各修正後に検証
--- a/docs/ja-JP/rules/common/security.md
+++ b/docs/ja-JP/rules/common/security.md
@@ -0,0 +1,29 @@
+# セキュリティガイドライン
+
+## 必須セキュリティチェック
+
+すべてのコミット前:
+- [ ] ハードコードされたシークレットなし（API キー、パスワード、トークン）
+- [ ] すべてのユーザー入力が検証済み
+- [ ] SQL インジェクション防止（パラメータ化クエリ）
+- [ ] XSS 防止（サニタイズされた HTML）
+- [ ] CSRF 保護が有効
+- [ ] 認証/認可が検証済み
+- [ ] すべてのエンドポイントにレート制限
+- [ ] エラーメッセージが機密データを漏らさない
+
+## シークレット管理
+
+- ソースコードにシークレットをハードコードしない
+- 常に環境変数またはシークレットマネージャーを使用
+- 起動時に必要なシークレットが存在することを検証
+- 露出した可能性のあるシークレットをローテーション
+
+## セキュリティ対応プロトコル
+
+セキュリティ問題が見つかった場合:
+1. 直ちに停止
+2. **security-reviewer** agent を使用
+3. 継続前に CRITICAL 問題を修正
+4. 露出したシークレットをローテーション
+5. 同様の問題がないかコードベース全体をレビュー
--- a/docs/ja-JP/rules/common/testing.md
+++ b/docs/ja-JP/rules/common/testing.md
@@ -0,0 +1,29 @@
+# テスト要件
+
+## 最低テストカバレッジ: 80%
+
+テストタイプ（すべて必須）:
+1. **ユニットテスト** - 個々の関数、ユーティリティ、コンポーネント
+2. **統合テスト** - API エンドポイント、データベース操作
+3. **E2E テスト** - 重要なユーザーフロー（フレームワークは言語ごとに選択）
+
+## テスト駆動開発
+
+必須ワークフロー:
+1. まずテストを書く（RED）
+2. テストを実行 - 失敗するはず
+3. 最小限の実装を書く（GREEN）
+4. テストを実行 - パスするはず
+5. リファクタリング（IMPROVE）
+6. カバレッジを確認（80%+）
+
+## テスト失敗のトラブルシューティング
+
+1. **tdd-guide** agent を使用
+2. テストの分離を確認
+3. モックが正しいことを検証
+4. 実装を修正、テストは修正しない（テストが間違っている場合を除く）
+
+## Agent サポート
+
+- **tdd-guide** - 新機能に対して積極的に使用、テストファーストを強制