mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-19 23:33:07 +08:00
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>
This commit is contained in:
Claude
306
docs/ja-JP/skills/santa-method/SKILL.md
Normal file
306
docs/ja-JP/skills/santa-method/SKILL.md
Normal file
@@ -0,0 +1,306 @@
|
||||
---
|
||||
name: santa-method
|
||||
description: "収束ループを持つマルチエージェント敵対的検証。2つの独立したレビューエージェントが両方合格して初めて出力を出荷できます。"
|
||||
origin: "Ronald Skelton - Founder, RapportScore.ai"
|
||||
---
|
||||
|
||||
# Santa Method
|
||||
|
||||
マルチエージェント敵対的検証フレームワーク。リストを作り、二度確認する。問題があれば、良くなるまで修正する。
|
||||
|
||||
核心的な洞察: 自分の出力をレビューする単一のエージェントは、その出力を生み出したのと同じバイアス、知識のギャップ、体系的なエラーを共有しています。共有コンテキストを持たない2人の独立したレビュアーは、この障害モードを解消します。
|
||||
|
||||
## 起動するタイミング
|
||||
|
||||
以下の場合にこのスキルを呼び出します:
|
||||
- 出力が公開、デプロイ、またはエンドユーザーに提供される場合
|
||||
- コンプライアンス、規制、またはブランドの制約が適用される必要がある場合
|
||||
- コードが人間のレビューなしに本番環境にデプロイされる場合
|
||||
- コンテンツの正確性が重要な場合（技術文書、教育資料、顧客向けコピー）
|
||||
- スポットチェックで体系的なパターンを見逃す可能性のある大規模バッチ生成
|
||||
- ハルシネーションリスクが高い場合（主張、統計、API リファレンス、法的言語）
|
||||
|
||||
内部ドラフト、探索的調査、または確定的な検証がある場合（それらにはビルド/テスト/Lint パイプラインを使用）には使用しないでください。
|
||||
|
||||
## アーキテクチャ
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ GENERATOR │ フェーズ1: リストを作る
|
||||
│ (Agent A) │ 成果物を生成する
|
||||
└──────┬───────┘
|
||||
│ output
|
||||
▼
|
||||
┌──────────────────────────────┐
|
||||
│ DUAL INDEPENDENT REVIEW │ フェーズ2: 二度確認する
|
||||
│ │
|
||||
│ ┌───────────┐ ┌───────────┐ │ 2つのエージェント、同じルーブリック、
|
||||
│ │ Reviewer B │ │ Reviewer C │ │ 共有コンテキストなし
|
||||
│ └─────┬─────┘ └─────┬─────┘ │
|
||||
│ │ │ │
|
||||
└────────┼──────────────┼────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────────────────────┐
|
||||
│ VERDICT GATE │ フェーズ3: 良いか悪いか
|
||||
│ │
|
||||
│ B passes AND C passes → NICE │ 両方が合格する必要がある。
|
||||
│ Otherwise → NAUGHTY │ 例外なし。
|
||||
└──────┬──────────────┬─────────┘
|
||||
│ │
|
||||
NICE NAUGHTY
|
||||
│ │
|
||||
▼ ▼
|
||||
[ SHIP ] ┌─────────────┐
|
||||
│ FIX CYCLE │ フェーズ4: 良くなるまで修正
|
||||
│ │
|
||||
│ iteration++ │ 全フラグを収集する。
|
||||
│ if i > MAX: │ 全問題を修正する。
|
||||
│ escalate │ 両レビュアーを再実行する。
|
||||
│ else: │ 収束するまでループ。
|
||||
│ goto Ph.2 │
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
## フェーズの詳細
|
||||
|
||||
### フェーズ1: リストを作る（生成）
|
||||
|
||||
主要タスクを実行します。通常の生成ワークフローに変更はありません。Santa Method は生成後の検証レイヤーであり、生成戦略ではありません。
|
||||
|
||||
```python
|
||||
# ジェネレーターは通常通り実行される
|
||||
output = generate(task_spec)
|
||||
```
|
||||
|
||||
### フェーズ2: 二度確認する（独立したデュアルレビュー）
|
||||
|
||||
2つのレビューエージェントを並列で起動します。重要な不変条件:
|
||||
|
||||
1. **コンテキスト分離** — どちらのレビュアーも相手の評価を見ない
|
||||
2. **同一ルーブリック** — 両方が同じ評価基準を受け取る
|
||||
3. **同じ入力** — 両方がオリジナルの仕様と生成された出力を受け取る
|
||||
4. **構造化出力** — それぞれが散文ではなく型付き判定を返す
|
||||
|
||||
```python
|
||||
REVIEWER_PROMPT = """
|
||||
あなたは独立した品質レビュアーです。この出力に対する他のレビューは見ていません。
|
||||
|
||||
## タスク仕様
|
||||
{task_spec}
|
||||
|
||||
## レビュー対象の出力
|
||||
{output}
|
||||
|
||||
## 評価ルーブリック
|
||||
{rubric}
|
||||
|
||||
## 指示
|
||||
各ルーブリック基準に対して出力を評価してください。それぞれに対して:
|
||||
- PASS: 基準が完全に満たされ、問題なし
|
||||
- FAIL: 特定の問題が見つかった（正確な問題を引用）
|
||||
|
||||
評価を構造化JSONとして返してください:
|
||||
{
|
||||
"verdict": "PASS" | "FAIL",
|
||||
"checks": [
|
||||
{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
|
||||
],
|
||||
"critical_issues": ["..."], // 修正が必要なブロッカー
|
||||
"suggestions": ["..."] // ブロックしない改善提案
|
||||
}
|
||||
|
||||
厳格に評価してください。あなたの仕事は問題を見つけることであり、承認することではありません。
|
||||
"""
|
||||
```
|
||||
|
||||
```python
|
||||
# レビュアーを並列で起動（Claude Code サブエージェント）
|
||||
review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
|
||||
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")
|
||||
|
||||
# 両方が同時に実行される — 互いに見えない
|
||||
```
|
||||
|
||||
### ルーブリックの設計
|
||||
|
||||
ルーブリックは最も重要な入力です。曖昧なルーブリックは曖昧なレビューを生みます。すべての基準には客観的な合否条件が必要です。
|
||||
|
||||
| 基準 | 合格条件 | 失敗シグナル |
|
||||
|-----------|---------------|----------------|
|
||||
| 事実の正確性 | すべての主張がソース資料または常識から検証可能 | 作り上げられた統計、誤ったバージョン番号、存在しないAPI |
|
||||
| ハルシネーションなし | 作り上げられたエンティティ、引用、URL、参照なし | 存在しないページへのリンク、出典のない引用 |
|
||||
| 完全性 | 仕様のすべての要件が対応されている | 欠落しているセクション、スキップされたエッジケース、不完全なカバレッジ |
|
||||
| コンプライアンス | すべてのプロジェクト固有の制約に合格 | 禁止語の使用、トーン違反、規制への非準拠 |
|
||||
| 内部一貫性 | 出力内に矛盾なし | セクションAがXと言い、セクションBがX以外と言う |
|
||||
| 技術的正確性 | コードがコンパイル/実行され、アルゴリズムが健全 | 構文エラー、ロジックのバグ、誤った計算量の主張 |
|
||||
|
||||
#### ドメイン固有のルーブリック拡張
|
||||
|
||||
**コンテンツ/マーケティング:**
|
||||
- ブランドボイスの遵守
|
||||
- SEO要件の充足（キーワード密度、メタタグ、構造）
|
||||
- 競合他社の商標の誤用なし
|
||||
- CTAが存在し正しくリンクされている
|
||||
|
||||
**コード:**
|
||||
- 型安全性（`any` リークなし、適切なnull処理）
|
||||
- エラー処理のカバレッジ
|
||||
- セキュリティ（コードにシークレットなし、入力検証、インジェクション防止）
|
||||
- 新しいパスのテストカバレッジ
|
||||
|
||||
**コンプライアンスが重要な場合（規制対象、法的、財務的）:**
|
||||
- 結果の保証や根拠のない主張なし
|
||||
- 必要な免責事項が存在する
|
||||
- 承認された用語のみ
|
||||
- 管轄区域に適した言語
|
||||
|
||||
### フェーズ3: 良いか悪いかの判定（Verdict Gate）
|
||||
|
||||
```python
|
||||
def santa_verdict(review_b, review_c):
|
||||
"""両方のレビュアーが合格する必要がある。部分的な評価なし。"""
|
||||
if review_b.verdict == "PASS" and review_c.verdict == "PASS":
|
||||
return "NICE" # 出荷する
|
||||
|
||||
# 両方のレビュアーのフラグをマージし、重複を排除
|
||||
all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
|
||||
all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)
|
||||
|
||||
return "NAUGHTY", all_issues, all_suggestions
|
||||
```
|
||||
|
||||
両方が合格する必要がある理由: 1人のレビュアーだけが問題を検知した場合、その問題は実在します。もう1人のレビュアーのブラインドスポットこそ、Santa Method が解消しようとしている障害モードです。
|
||||
|
||||
### フェーズ4: 良くなるまで修正する（収束ループ）
|
||||
|
||||
```python
|
||||
MAX_ITERATIONS = 3
|
||||
|
||||
for iteration in range(MAX_ITERATIONS):
|
||||
verdict, issues, suggestions = santa_verdict(review_b, review_c)
|
||||
|
||||
if verdict == "NICE":
|
||||
log_santa_result(output, iteration, "passed")
|
||||
return ship(output)
|
||||
|
||||
# すべての重大な問題を修正する（提案はオプション）
|
||||
output = fix_agent.execute(
|
||||
output=output,
|
||||
issues=issues,
|
||||
instruction="フラグが立てられた問題のみを修正してください。リファクタリングや未要求の変更は行わないでください。"
|
||||
)
|
||||
|
||||
# 修正した出力で両方のレビュアーを再実行する（新しいエージェント、前のラウンドの記憶なし）
|
||||
review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
|
||||
review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
|
||||
|
||||
# イテレーション回数を超えた — エスカレート
|
||||
log_santa_result(output, MAX_ITERATIONS, "escalated")
|
||||
escalate_to_human(output, issues)
|
||||
```
|
||||
|
||||
重要: 各レビューラウンドは**新鮮なエージェント**を使用します。レビュアーは前のラウンドの記憶を持ってはいけません。前のコンテキストはアンカリングバイアスを生み出すためです。
|
||||
|
||||
## 実装パターン
|
||||
|
||||
### パターンA: Claude Code サブエージェント（推奨）
|
||||
|
||||
サブエージェントは真のコンテキスト分離を提供します。各レビュアーは共有状態を持たない別個のプロセスです。
|
||||
|
||||
```bash
|
||||
# Claude Code セッションでエージェントツールを使用してレビュアーを起動する
|
||||
# 速度のために両エージェントを並列で実行する
|
||||
```
|
||||
|
||||
```python
|
||||
# エージェントツール呼び出しの擬似コード
|
||||
reviewer_b = Agent(
|
||||
description="Santa Review B",
|
||||
prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
|
||||
)
|
||||
reviewer_c = Agent(
|
||||
description="Santa Review C",
|
||||
prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
|
||||
)
|
||||
```
|
||||
|
||||
### パターンB: 逐次インライン（フォールバック）
|
||||
|
||||
サブエージェントが利用できない場合、明示的なコンテキストリセットで分離をシミュレートします:
|
||||
|
||||
1. 出力を生成する
|
||||
2. 新しいコンテキスト: 「あなたはレビュアー1です。このルーブリックのみに対して評価してください。問題を見つけてください。」
|
||||
3. 所見を逐語的に記録する
|
||||
4. コンテキストを完全にクリアする
|
||||
5. 新しいコンテキスト: 「あなたはレビュアー2です。このルーブリックのみに対して評価してください。問題を見つけてください。」
|
||||
6. 両方のレビューを比較し、修正して繰り返す
|
||||
|
||||
サブエージェントパターンは厳密に優れています — インラインシミュレーションはレビュアー間のコンテキスト漏れのリスクがあります。
|
||||
|
||||
### パターンC: バッチサンプリング
|
||||
|
||||
大規模バッチ（100件以上）の場合、全アイテムへの完全な Santa 適用はコスト的に非現実的です。層別サンプリングを使用します:
|
||||
|
||||
1. ランダムサンプルで Santa を実行（バッチの10〜15%、最低5件）
|
||||
2. 種類別に失敗を分類（ハルシネーション、コンプライアンス、完全性など）
|
||||
3. 体系的なパターンが現れた場合、バッチ全体に対象を絞った修正を適用
|
||||
4. 修正されたバッチを再サンプリングして再検証
|
||||
5. クリーンなサンプルが合格するまで継続
|
||||
|
||||
```python
|
||||
import random
|
||||
|
||||
def santa_batch(items, rubric, sample_rate=0.15):
|
||||
sample = random.sample(items, max(5, int(len(items) * sample_rate)))
|
||||
|
||||
for item in sample:
|
||||
result = santa_full(item, rubric)
|
||||
if result.verdict == "NAUGHTY":
|
||||
pattern = classify_failure(result.issues)
|
||||
items = batch_fix(items, pattern) # パターンに一致する全アイテムを修正
|
||||
return santa_batch(items, rubric) # 再サンプリング
|
||||
|
||||
return items # クリーンなサンプル → バッチを出荷
|
||||
```
|
||||
|
||||
## 障害モードと緩和策
|
||||
|
||||
| 障害モード | 症状 | 緩和策 |
|
||||
|-------------|---------|------------|
|
||||
| 無限ループ | レビュアーが修正後に新しい問題を見つけ続ける | 最大イテレーション上限（3回）。エスカレートする。 |
|
||||
| スタンプ承認 | 両方のレビュアーがすべてを通す | 敵対的プロンプト: 「あなたの仕事は問題を見つけることであり、承認することではありません。」 |
|
||||
| 主観的ドリフト | レビュアーがエラーではなくスタイルの好みにフラグを立てる | 客観的な合否基準のみを持つ厳格なルーブリック |
|
||||
| 修正による退行 | 問題Aの修正が問題Bを引き起こす | ラウンドごとの新鮮なレビュアーが退行を検知 |
|
||||
| レビュアーの合意バイアス | 両方のレビュアーが同じことを見逃す | 独立性によって緩和されるが排除はされない。重要な出力には3人目のレビュアーか人間のスポットチェックを追加 |
|
||||
| コスト爆発 | 大規模出力に対して多すぎるイテレーション | バッチサンプリングパターン。検証サイクルあたりの予算上限。 |
|
||||
|
||||
## 他のスキルとの統合
|
||||
|
||||
| スキル | 関係 |
|
||||
|-------|-------------|
|
||||
| Verification Loop | 確定的なチェック（ビルド、Lint、テスト）に使用。Santa はセマンティックチェック（正確性、ハルシネーション）に使用。先に検証ループを実行し、その後 Santa を実行。 |
|
||||
| Eval ハーネス | Santa Method の結果がEval メトリクスに反映される。Santa の実行全体で pass@k を追跡して、経時的なジェネレーターの品質を測定。 |
|
||||
| Continuous Learning v2 | Santa の発見が本能になる。同じ基準での繰り返し失敗 → パターンを避ける学習された行動。 |
|
||||
| Strategic Compact | コンパクト前に Santa を実行する。検証途中でレビューコンテキストを失わない。 |
|
||||
|
||||
## メトリクス
|
||||
|
||||
Santa Method の効果を測定するためにこれらを追跡します:
|
||||
|
||||
- **初回合格率**: ラウンド1で Santa を通過する出力の % （目標: >70%）
|
||||
- **収束までの平均イテレーション**: NICE になるまでの平均ラウンド数（目標: <1.5）
|
||||
- **問題の分類**: 失敗の種類の分布（ハルシネーション対完全性対コンプライアンス）
|
||||
- **レビュアー合意**: 両方のレビュアーがフラグを立てた問題 対 片方のみの % （低い合意 = ルーブリックの改善が必要）
|
||||
- **エスケープ率**: Santa が検知すべきだったが出荷後に見つかった問題（目標: 0）
|
||||
|
||||
## コスト分析
|
||||
|
||||
Santa Method は検証サイクルあたり、生成単体のトークンコストの約2〜3倍のコストがかかります。高リスクな出力のほとんどにとって、これは割安です:
|
||||
|
||||
```
|
||||
Santa のコスト = (生成トークン) + 2×(ラウンドあたりのレビュートークン) × (平均ラウンド数)
|
||||
Santa を使わないコスト = (評判の損害) + (修正の労力) + (信頼の侵食)
|
||||
```
|
||||
|
||||
バッチ操作では、サンプリングパターンにより、体系的な問題の>90%を検知しながら、完全な検証の約15〜20%のコストに削減されます。
|
||||
Reference in New Issue
Block a user