Localize：ローカライズと翻訳レビューは何をしますか？

0. 一言で言うと

ローカライズとは、言語Aを言語Bに置き換えることではなく、まずAを意味に戻し、その意味をBで書き直すことです。このスキルの価値は「自然な翻訳を生成する」こと（モデルはすでにそれができます）ではなく、「自然だが誤っている」文を見つけ出し、その判断を再利用可能な用語集、スタイルシート、確認リストとして蓄積することにあります。

文中の「実測」事例はすべて実際のプロジェクトに基づき、機密情報は除去されています。プロジェクト名や製品名は匿名化されています。引用、投票数、統計数値は元の記録のままです。「例示」と表示されている単語は置き換えられたものであり、元の単語ではありません。

1. 絶対ルール（すべてのエントリーポイントに適用）

ユーザーの原文ファイルと翻訳ファイルは変更しません。 すべての成果物は作業ディレクトリに書き込まれます（§3参照）。レビュー出力は発見リストであり、ユーザーが確認して承認した後にのみ修正が適用されます。
原文の意味が読み取れない場合は推測しません。 確認待ちリストに記載します。翻訳エントリーポイントで、複数箇所に影響する疑問はまずユーザーに確認してから作業を進め、1箇所のみに影響する場合は成果物の該当箇所に「推測」と注釈を付けます。
モデルは「出典あり」と主張してはいけません。 「この用語はターゲット市場でこのように使う」という判断は、言語ペアパック/ロケールパックに根拠があるか、WebSearchでターゲット言語の類似資料における実際の使用例を見つけるか、または「未検証」と標示しなければなりません。
生成とレビューはコンテキストを分離します。 レビューは独立したサブエージェントが実行します。翻訳生成のコンテキストは自身の翻訳をレビューできません。
事実確認はスクリプトに委ねます。 数字、日付、通貨、URL、単位、文字の正規化については、まず scripts/ を実行します。モデルは記号や単位レベルの誤検出率が高いため、感覚でロケールエラーを判断させてはいけません。
各発見には重大度を付け、「エラー」と「好み」を区別します。 §6を参照。
セグメントごとにレビューし、全文を一度に処理しません。 各セグメントは約1500文字の原文とします。テキストが長くなるほど、モデルが見つけるエラーは少なくなります。
書き換えは表現を変えることはできますが、指示対象を変えてはいけません。 文型の変更、単語の置き換え、情報の並べ替え（ブランドコピーライティングでは書き直しも可能）は許可されますが、原文が指しているもの（用途、対象、数量、主体）を変えることは許可されません。 原文の事実に問題（存在しない製品、計算が合わない数字、自己矛盾）を発見した場合は、確認待ちリストに記録して著者の判断を仰ぎ、著者の代わりに修正してはいけません。指示対象を変えると、新たな矛盾を連鎖的に生み出します。
翻訳カラムには、直接リリースできる文字列のみを配置します。 確認待ちプレースホルダ、案の比較（A案/B案）、内部ポインタ（「以下を参照…」）、幅の注釈、処理説明は、すべて独立したカラムまたは独立したリストに移動します。翻訳単位でないものを翻訳テーブルに行として立ててはいけません。 例えば、「このラベルはコードで組み立てられており、i18nキーはない」「この数字は疑わしい」といったものは、行全体を確認待ちリストに移動し、翻訳カラムに説明を書いてはいけません。納品前に scripts/deliverable_check.py を実行します。char_lint.py でバイリンガルテーブルをチェックする際は、必ず --tgt-col を指定してください。指定しないと、原文カラムの文字が翻訳文として誤って報告されます。
本プロジェクトの開始ファイルとカーネルルールが矛盾する場合は、まず記録し、矛盾の方向に基づいてどちらに従うかを決定します。 開始時に作成されたコンプライアンス表、スタイルシート、用語集はその時点での判断であり、カーネルルールはプロジェクト横断的な判断であり、両者は矛盾することがあります（典型的な例：コンプライアンス表が段落全体のトーンを和らげることを要求する一方で、diagnostics.md §10は機能説明は肯定的な表現を維持することを要求する）。まず矛盾の方向を明確にし、それからどちらに従うかを決定します:
- 開始ファイルがカーネルよりも厳しい場合（禁止用語、必須の免責事項、より保守的な表現の強度）→ 開始ファイルに従い、裁定を待ちます。コンプライアンスには通常、それなりの理由があります。緩い側の誤りの代償はより高くなります。
- 開始ファイルの事実が古くなっているか、カーネルよりも緩い場合（仕様変更、制限緩和、カーネルが要求する処理が欠落している）→ カーネルに従い、開始ファイルを更新します。どちらの場合も：① 確認待ちリストに記録し、それが原文の問題ではなく内部ルールの矛盾であることを明記します。② レポートにどのルールに従ったか、その理由を記載します。黙って一方を選択してはいけません。 独立したレビューパスではあなたの選択は見えず、それを違反として再度報告することになります。

2. 入力契約

作業開始前に以下の表を収集します。欠落がある場合は「欠落時」の列に従って処理し、レポートヘッダーにその旨を記載します。

入力	必須	欠落時
原文（ファイルパスまたは貼り付け）	review/translate で必須	原文なし → §5.3の縮退フローへ
翻訳文	review で必須	—
原文ロケール / ターゲットロケール	必須	テキストから自動判断し、レポートに「自動判断」と記載
資料タイプ（`references/material-types.md`参照）	必須	1回質問する。回答がない場合はテキスト特性から判断して記載
シーンを一言で：誰が、どのような場面で、この資料を読み、どのような決定を下すのか	必須	1回質問する。回答がない場合は資料タイプからデフォルトを取得し、レポートヘッダーに「シーン未確認」と記載
既存の用語集 / スタイルシート	任意	`templates/` から新しいものを作成
レイアウト制約（文字数上限、ボックス幅、ソフトウェア文字列かどうか）	任意	G7レイアウトゲートをスキップし、レポートにその旨を記載
ターゲット言語の類似資料サンプル（translateエントリーポイントでは強く推奨）	任意	レポートに「シーン再構築のためのサンプルなし」と記載
翻訳文の出典（人間翻訳 / 機械翻訳 / AI / 前バージョン）	review で推奨	「不明」と記載
ターゲット言語テキストの著者/出典（ターゲット言語のネイティブスピーカー / 非ネイティブスピーカー / 不明）	原文がない場合は必須	不明の場合は縮退し、その旨を明記
投入グレード（§8参照）	任意	デフォルトは「フルグレード」

3. 作業ディレクトリと成果物

デフォルトでは、原文ファイルのディレクトリに <原文ファイル名（拡張子除く）.l10n/> を作成します。ユーザーが指定した場合は、そのディレクトリを使用します。

⚠ 最終レポートのディスクへの書き込み責任はメインダイアログにあり、サブエージェントはテキストで返します。 実測：一部の実行環境では、ファイル名で findings.md/report/summary クラスのファイルをサブエージェントが書き込むのをブロックしますが、同じスキルが別のセッションで同名ファイルを書き込むことは可能です。ブロックはセッションをまたいで変化するため、どちらかの側が仮定してはいけません。 → サブエージェントはコンテンツを生成し、テキストで返します。メインダイアログ自身がディスクに書き込み、検証します（ls -lT ＋エントリ数）。書き込みに失敗した場合、サブエージェントは名前を変更したり、別のBashコマンドで回避しようとしてはなりません。それは別のツールを使って、下されたばかりのブロックを無効にすることになります。中間成果物（list-a.md scripts-report.md open-questions.md など）は実測上、制限を受けないため、直接書き込むことができます。

帰属の規律：「環境がブロックした」と断言する前に、まず隔離実験を行います（名前変更/ディレクトリ変更/容量変更を各1回）。 同じ実行内に反例（他のファイルが書き込めた）がある場合、環境に帰属させることはできません。 実測：メインダイアログが「ブロックしていないのはお前が書いていないからだ」と断言し、サブエージェントが3回のプローブでメインダイアログの誤りを証明しました。実験を行った側が正しいです。

ファイル	内容
`00-brief.md`	シーンを一言、資料タイプ、言語ペアとロケール、今回の近道、グレード、スペースなどの戦略スイッチ、入力の欠落
`glossary.md`	用語集（テンプレート `templates/glossary.md`）。却下理由とステータスを含む
`style-sheet.md`	スタイルシート（テンプレート `templates/style-sheet.md`）。ロケールパックのデフォルト値から開始
`open-questions.md`	確認待ちリスト（テンプレート `templates/open-questions.md`）
`scripts-report.md`	R1の各スクリプトの出力
`findings.md`	レビュー発見リスト（テンプレート `templates/findings-report.md`）。ディスクへの書き込み責任はメインダイアログにあり、サブエージェントにはありません（下記参照）
`draft.<locale>.md`	translateエントリーポイントの翻訳成果物（「推測」マークを含む）
`decisions.md`	全体で統一する事項の決定記録（用語、記号、文体、重要な取捨選択）

4. 開始前に準備する4つのもの＋ルールパッケージの読み込み

順番に実行し、00-brief.md に書き込みます。

シーンを一言で（§2）、そしてそれを即座に「不合格になれる」基準のセットに展開します。

実測の教訓：シーンを一言だけ持っていても役に立たない。 あるビジネス提案では、シーンは非常に具体的に定義されていました（読者の身分、読了時間、読後に下すべき決定が明記されていた）。それでも、そのまま用語決定エージェントのプロンプトに書き込んだところ、いくつかの重要な用語はネイティブスピーカーによってすべて否決されました。後で数えてみると、用語集60項目のうち、根拠に「誰が読むか」について言及していたのはわずか9項目でした。シーンは座右の銘にはなったが、「これは合格か」という判断基準には入っていなかったのです。

したがって、シーンは以下の表に落とし込み、00-brief.md に書き込み、後続のすべての決定をこの表で検証する必要があります。

決定の種類	シーンを使ってどう検証するか（「不合格」と答えられる必要がある）
語彙選択	検索時にシーンを限定詞と単語に分解して一緒に検索します（資料タイプ＋読者の身分）。限定後に使用例が見つからない＝未検証、広範な検索方法にごまかしてすり替えてはいけません。`diagnostics.md` §7の第一関門を参照
数字・単位・通貨	「この読者がこの時間内にざっと見て、すぐに量感を得られるか？」——実測で失敗した例：シーンに「数十分で読む」と書いてあるのに、円換算をしないと決定し、3人のネイティブスピーカーから「都度計算しなければならず読むのをやめる原因」と言われました
レジスター（文体）	「この単語がこの読者の日常的な文書（デューデリジェンスレポート/仕様書/社内稟議）に出てきたら、違和感があるか？」違和感があれば、同じレジスターの同義語に置き換えます。ただし、意味も一緒に下げてはいけません。 `diagnostics.md` §10bを参照
構造・順序	「彼はこの時間内にその決定を下すために、必要な情報の順序は何か？」原文の順序と異なる場合は、確認待ちリストに記録します
翻訳しないで残す	「この読者が原文の形態（英語の小見出し、外貨、仕様名）を見たとき、プロフェッショナルな印象か、外来感か？」実測：そのまま残した英語の小見出しが「海外テンプレをそのまま使っている印象」と判定されました

基準は失敗できるものでなければ、基準とは呼べません。 「不合格がどのようなものか」に答えられない基準は、テストになっていません。

今回の「安易な対応」の近道を書き留めます。 すべての言語ペアには、一見正当に見える近道が存在します。言語ペア間には「一対一対応できるように見える」浅い層（語形/字形/語順）があり、真の差異はより深い層（語義/地域語彙/構文）にあります。対応表が使いやすいほど、危険です。 言語ペアパックの最初のセクションからコピーするか、（言語ペアパックがない場合）モデルにまず仮説を書かせます。
ルールパッケージを読み込みます。

パッケージ	パス	パッケージがない場合
言語ペアパック（方向依存）	`references/pairs/<src>-<tgt>.md`、例：`zh-ja.md`	モデルが近道の仮説を自動作成。G3/G6の信頼度が低下。レポートヘッダーに「言語ペアパックなし」と記載
ターゲットロケールパック	`references/locales/<locale>.md`、例：`ja-JP.md`	スタイルシートを空のテンプレートから開始。G5の信頼度が低下。レポートに「ロケールパックなし」と記載
資料タイプルール	`references/material-types.md`	—

既存パッケージ：pairs = zh-ja（完全版）、ja-zh、en-ja、ja-en、zh-en、en-zh（シード版）。locales = ja-JP（完全版）、zh-CN、zh-TW、en-US、en-GB（シード版）。シード版は出典のあるコンテンツのみを含み、不足部分は明記します。 4. 用語集、スタイルシート、確認待ちリストを作成します。 用語集は作業しながら拡張し、用語を決定するたびにエントリを追加します。スタイルシートはロケールパックのデフォルト値をコピーした後、プロジェクトに合わせて変更します。確認待ちリストは最初の文から記録を開始します。

5. 3つのエントリーポイント

5.1 review：既存翻訳のレビュー（原文＋翻訳文あり）

これは最も間違いやすい形態です。誘惑は「翻訳文だけを読んで、おかしな箇所を見つける」ことです。実証的な結論：単一言語レビュー単独では最も質が低い。バイリンガル対照レビューが必須。翻訳文からスタート。2つのパスの順序は自由。

R0 入力を収集（ターゲット言語テキストの著者/出典を含む）→ 00-brief.mdを書く → ルールパッケージを読み込む → 3つのものを作成
R1 スクリプトを実行（§7）：fact_check / char_lint / length_estimate / term_coverage / **distribution_check** → scripts-report.md
    **`distribution_check`は単言語パスの前に実行する必要があります**。これは全体の分布を報告しますが、単言語パスは項目ごとに見ていきます。
    分布データを先に取得することで、単言語パスはどこを見るべきかを知ることができます。
R2 セグメント化：原文と翻訳文を段落ごとに整列させ、各セグメントは約1500文字の原文以下とし、S01、S02…と番号を付けます。
R3 単言語パス（独立したサブエージェント、翻訳文＋ロケールパック＋シーンのみを与える）：
    「ネイティブスピーカーが書いたようには読めない」箇所、4つのトリガーヒット、文体の断絶をマーク
    → **そのまま `review/list-a.md` に書き込む**（要約ではなく、原文）
    → **メインダイアログがファイルの存在と行数 ≥ 候補数を検証**。検証に失敗した場合はR3を再実行し、要約を持って先に進んではいけません
R4 バイリンガルパス（独立したサブエージェント、セグメントごとに原文＋翻訳文＋言語ペアパック＋用語集の該当エントリを与える）：
    対照がなければ発見できない5種類のエラー＋モデル特有の失敗（文の欠落/追加/過度な装飾）＋情報粒子のカウント
    → list-Bを出力
R5 マージして重複排除し、§6に従って重大度を決定し、§6の3つのオプション形式で提案を記述
    **マージ後、必ず「list-AにN件あり、そのうちM件が最終リストに含まれた」と報告しなければなりません。**
    単言語パスの発見が一括で除外されるのはプロセスの失敗であり、「重要ではない」からではありません。——§5.5を参照。
R6 懐疑論者による検証（独立したサブエージェント、**Read/grep機能を与える必要があります**）：critical/majorを項目ごとに審査し、
    デフォルトでは不確実な場合はグレードを下げます。一度書き換えてみて、明らかに改善されない場合はneutralにグレードダウンします。
    実測経験：約半数のcritical/majorがグレードダウンされ、中にはgrepで論拠が直接覆される項目もあります。
    **懐疑論者はグレードダウンのみを行い、見逃しのチェックは行いません。** それが審査できないminorは、処理しなくてもよいという意味ではありません。§5.5を参照。
R7 findings.mdを書く。glossary.md / open-questions.md / decisions.md を更新
R8 ユーザーへ：最初に全体で統一する事項をリストアップしてユーザーに決定させ、次に項目ごとのリストでユーザーにチェックを入れさせます。チェック後にのみ修正を適用

R3/R4/R6のサブエージェントプロンプトテンプレートは references/subagent-prompts.md にあります。自己完結型である必要があります（ファイルパス、シーン、近道をすべて書き込み、継承されたコンテキストに依存しない）。 このスキルの絶対パスは ${CLAUDE_SKILL_DIR} です。 ディスパッチ前に、テンプレート内の {{skill_dir}} をすべてこれに置き換えてください。置き換えないと、サブエージェントは言語ペアパックやロケールパックを読み取れません。（上記が ${CLAUDE_SKILL_DIR} のまま表示され、パスに置き換えられていない場合——例えばCodexなどの他のツールの場合——は、このSKILL.mdファイルがあるディレクトリの絶対パスを使用してください。このファイル内の他の ${CLAUDE_SKILL_DIR} も同様です。）

5.5 単言語パスの発見はマージ時に消失してはならない

これは実測で踏んだ落とし穴であり、理論上の懸念ではありません。 あるSaaSランディングページプロジェクトでは、ネイティブスピーカーからの10件のフィードバックのうち8件は、すでに私たちの単言語パスが報告していたものでした。そのうち6件は懐疑論者による検証にすら回っていませんでした——マージ時にバイリンガルパスの発見（漏訳/指示対象/用語）から候補を選んだため、単言語パスの読み味に関する発見が一括で除外されたからです。単言語パスが存在する唯一の理由は「翻訳のように読める」箇所を捉えることであり、その出力は検証に入る前に捨てられていたのです。

原因は構造的な3つの要素が重なったものです：① 単言語パスの発見はほぼすべてminorである（それがminorの定義です）。② 懐疑論者は設計上critical/majorのみを審査するため、minorは永遠に検証に入らない。③ 重大度表は項目ごとに評価され、項目単体では「理解に影響しない」ものが、同じ文に複数積み重なると「この文は翻訳のように読める」となるが、それらを合算するステップはどこにもありません。

4つの固定アクション（プロセスの順序に従う）：

A. list-Aは必ずディスクに書き込まれ、メインダイアログが検証する必要があります。 要約では原本の代わりになりません。——§9.1のクロスチェックはlist-Aとの項目ごとの比較であり、要約だけではチェーンが切れ、後で「この項目は以前報告したかどうか」を確認できなくなります。「必ずディスクに書き込む」というルールを書くだけでは不十分です：実測で書き込まれなかったのは、サブエージェントが書き戻す際にAPI 400で中断されたためであり、ルールはネットワークエラーを防げません。したがって、これはメインダイアログ自身のアクションです——R3終了後、メインダイアログ自身が wc -l でファイルが存在し、行数が一致することを確認してから、R5に進みます。（エージェントが「完了した」と言っても、メインダイアログは自身で検証しなければなりません。）
B. 密度のアップグレード。 同じ文字列が単言語パスで 3回以上報告された場合、各項目がどれほど軽微であっても、文字列全体をT5の書き換え候補とします。理由：3つの独立した欠点が一文に詰まっている場合、項目ごとに修正しても直らず、書き換えの方が速いからです。
C. 単言語パスの「書き換えの方が速い」「読めない」は強力なシグナルです。 単言語パスが特定のセクションについて「個別修正より書き直しが早い」または「完全に読めない」と述べた場合、重大度フィルターを通さずに直接T5に送ります。これは単言語パスがネイティブ視点として唯一与えられる強い判断であり、minorとして処理してはいけません。
D. マージ時に生存率を報告します。 R5の出力には、必ず「list-A N件 → 最終リスト M件」の行を含める必要があります。M/Nが著しく低い場合は、再びバイリンガルパスの発見だけを選んでいないか確認します。

なぜ懐疑論者にもminorを審査させないのか：その役割が希薄になります。懐疑論者のタスクはグレードダウン（過剰な評価を防ぐ）であり、漏れの防止ではありません。漏れの防止は上記の4つのアクションでマージ段階で解決する必要があり、検証段階で補うことは期待できません。

5.6 グループレベルの発見は、一つのメンバーを変更して「修正した」ことにしてはいけない

実測で踏み、しかもマイナス点を出しました。 とある実際のプロジェクトで、4つのオプションにそれぞれ説明ラベルがありました。単言語パスは「4つのオプションの説明の軸が揃っていない」と報告しました——4つはそれぞれ用途、推奨度、品質、仕様について説明していました。これはこの4つをグループとして見た発見です。当時の処理は、最も目立つ1つだけを書き換えることでした。結果：軸はまだ揃っていません（他の3つは変更されていません）。そして、変更された項目は、その後の3人によるブラインドテストで全員一致で3つのバージョン中最悪と評価され、変更前の原文よりも悪かったのです。一つのメンバーを変更しても、グループの問題は解決せず、新たな個別の問題を追加しただけです。

判断基準：発見の記述に「揃っていない」「統一されていない」「パラレルでない」「スタイルが一貫していない」「これらの間で」とある場合—— 主語は複数形であり、それはグループレベルの発見です。

2つの正当な処理方法があり、第3の方法はありません。

グループ全体を一緒に変更し、変更後にグループ全体を一緒に検証します（レイアウト、幅、軸、文体をグループとして確認）。
グループ全体を変更せず、この発見を確認待ちリストに記録し、「グループ全体の書き換えが必要。今回のラウンドでは未実施」と明記します。

やってはいけないこと：グループ内で最も目立つ1つを変更し、それを解決したことにすること。グループレベルの発見に対する正しい成果物は グループ全体の代替案であり、1つの項目ではありません。

5.6a グループ全体を書き換えた後は、スタイルシートに照らして再検証しなければならない——グループレベルの修正は、すでにこれらのメンバーを拘束している制約に違反してはならない

§5.6は「グループ全体を変更する」と言っていますが、半分しか言っていません。 実測：§5.6に従ってラベルのグループ全体を書き換えたところ、軸は統一され、幅も収束しました（3.00×→1.43×）。しかし、ネイティブスピーカーによるブラインドテストでは**「指摘された1つだけを変更した」ケースに敗れました**——2人が却下した理由は「体言止めで短く揃えるのが日本のUI標準」であり、これはすでにプロジェクト自身のスタイルシートに記載されていたのです。軸は修正されましたが、文体のルールを踏みました。根本原因はルールではなく、プロンプトが記憶に頼って制約を再現し、スタイルシートの原文をコピーしなかったことにあります。

固定アクション：既に確定した文字列を書き換える前に、まず「この文字列はすでにどのような決定によって拘束されているか」を問い、それらの項目の原文をプロンプトにコピーします。記憶に頼って再現してはいけません。少なくとも以下の4種類をコピーする必要があります。

コピーするもの	コピー元
該当する用語エントリ	`glossary.md`
適用されるスタイルシートの行（文体、語尾、句読点、スペース、幅のハード制約）	`style-sheet.md` ← 最も見落とされやすいのはこれです
該当するパラレルグループの確立された記述軸	`style-sheet.md`「パラレルグループの記述軸」行
シーンを一言と今回の近道	`00-brief.md`

T3にはもともとこの要件があります（§5.2「各セグメントにglossaryの該当エントリ + style-sheet + シーン + 近道を含める」）。 落とし穴を踏んだのは、フロー外の一時的な書き換えタスクでした——ネイティブフィードバックの修正、統合版の作成、1つの漏訳の補完。このようなタスクはT3の番号が付かないため、「ついでに修正する」ものとして扱われ、ペイロードを持たずに実行されがちです。これらはT3と同様に、完全なペイロードを持つ必要があります。

パラレルグループの軸と「指示対象」が衝突する場合、指示対象が優先されます。軸を壊しても、意味を変えてはいけません。 実測：原文の4つのセルのうち3つは A + B、1つは A / B（または）でした。スタイルシートはこのグループの接続詞を「＋」で統一していました。生成側は軸に従い、そのセルの**「または」を「および」に書き換えました**——レイアウト統一のために原文の意味を変えたのであり、これはまさに絶対ルール8で禁じられていることです。 軸は表現のレベルであり、指示対象は事実のレベルです。 衝突した場合は、このセルは軸を壊し（「／」を使用）、レポートにその理由を記載します。レイアウトの一貫性は指示対象に優先してはいけません——この点もレビュー側のチェック項目に含める必要があります。なぜなら、それは完全に自然に読めるため、原文と照らし合わせて初めてわかるからです。

検証アクション：グループ全体を書き換えた後、新しいグループをスタイルシートの項目ごとにチェックし、新しいグループが古いグループに存在しなかった問題（幅、文体、句読点、隣接グループとの一貫性）を導入していないことを確認します。 length_estimate.py --siblings は幅しかチェックできません。文体は人間が見る必要があります。

副産物：グループ内のばらつきは機械的にチェック可能です。 パラレルグループ（キー内の1トークンだけが異なる、例： plan_lite_/standard_/pro_/max_description（例示））の表示幅の範囲（最大値－最小値）は、length_estimate.py --siblings でリストアップされます。とある実際のプロジェクトの実測では、6つのパラレルグループのうち5つは範囲が ≤1.67倍でしたが、変更によって壊されたグループだけが3.00倍でした。 スクリプトはリストアップするだけで判断はしません——しきい値を何倍にするかはプロジェクト横断的な根拠がないため、無理に決めてはいけません。

5.2 translate：ゼロからの翻訳（原文のみ）

T0 入力を収集（可能であればターゲット言語の類似資料サンプルも）→ 00-brief.md → ルールパッケージを読み込む
T1 全文の事前分析、書き換えはしない：全文を通読 → 用語候補を抽出 → 確認待ちリストを作成
    複数箇所に影響する疑問 → まずユーザーに確認。1箇所のみに影響するもの → 「推測」とマークして続行
T2 用語決定（3つの関門：既存の用語か？競合するか？レイアウトに収まるか？）→ glossary.md
    **確実性の段階、ステータスバッジのような「自成体系」の用語は、ターゲット市場の類似資料で既存の言い回しを探さなければなりません。**
    実測：フローが確実性の上限を調整するために4段階の尺度を設計し、最強の段階を `検証済み` としました——**設計は正しくても、用語の選択が間違っていました**。
    3人のネイティブスピーカーが一致して、投資資料のtractionバッジの定番は `実績` であり、`検証済み` は第三者検証を連想させると指摘しました。
    **自己矛盾のない尺度であっても、ターゲット市場で使用されている尺度とは限りません。**
    **用語の出典は「その資料が誰に向けたものか」と一緒に記録しなければなりません。用語がターゲット言語に存在する ≠ ターゲット読者が一読して理解できる、です。**
    実測で**4回同じパターン**：4つの用語がすべて「検証済み」と見なされましたが、その根拠はそれぞれ、他社の製品ページ、汎用辞書、自作の尺度、メーカーの技術ブログでした。
    結果：1つは他社の製品ではできるが、資料内の製品ではできないこと。1つは日本語では別の分野でのみ使用されること。
    1つはターゲット読者の資料では過大表示であること。1つは技術読者には一般的だが、ビジネス読者にはほとんど使われないこと。
    **共通の根本原因**：出典の読者と資料の読者が同じ集団ではなかったこと。
    → 出典欄は `出典（読者像）` の形式で書かなければなりません：`某メーカー技術ブログ（読者＝エンジニア）` と
    `投資家向け事業計画書（読者＝投資担当）` は**別物であり、互いに代用することはできません**。
    検証時には、**同じ種類の読者**を対象とした資料を優先的に探します。
    **用語の選択は、「この用語は難しそうだ」という感覚だけで行ってはいけません。まず頻度を実行する必要があります**：
    `term_coverage.py cover` で、原文の高頻実詞のうち用語集に収録されていないものをリストアップします。**高頻度で、かつ並列位置に繰り返し出現する用語は、たとえ難しそうに見えなくてもエントリが必要です**。
    収録しないと決定した場合も、表に「統一不要。理由は…」の行を書き、後続の人が見えるようにします。
    実測で漏れた例：`团队`（9箇所）と `企业`（10箇所）はどちらも「難しそうに見えない」ため表に入りませんでした。翻訳文ではそれぞれ2種類の訳語が出現しました。
    一方、**表に収録された用語の一貫性は100%でした**。エントリがない → 機械的一貫性リストがカバーしない → 納品前のgrepゲートでチェックできない →
    バイリンガルパスで「表に従っているか」を確認するための表がない → **1層漏れると、4層すべてが空になります。**
    スタイルシートはロケールパックのデフォルト値から開始 → style-sheet.md
    **作業終了前に、決定ファイル間の一貫性を確認する必要があります**：同じ用語が glossary / style-sheet / decisions の
    3箇所で同じ表記である必要があります。実測で踏みました——glossary では `一括エクスポート` と定めたのに、
    style-sheet の同じパラレルグループでは `まとめて書き出し`（単語は例示）と書いてあり、生成側はどちらかを選ぶしかなく、
    どちらを選んでもレビュー側がエラーとして報告することになります。**2つの決定ファイルが矛盾していると、下流では解決不可能です。**
    機械チェック：glossaryの「ターゲット言語の用語」カラムを、他の2つのファイルでgrepし、異なる形態が見つかった場合は統一します。
T3 セグメントごとに生成（各セグメントに、同じglossaryから該当するエントリ + style-sheet + シーン + 近道を含める）：
    ① 意図の抽出：この文は一体何を言おうとしているのか（文字面を離れて）
    ② シーンの再構築：ターゲット市場の人がこのシーンでどのように書くか（サンプルがあれば、そのサンプルの文型/文体と照合）
    ③ 語感の研磨：文体、長さ、全体との一貫性
    常に自問する：この単語を選んだのは、原語もこの形式だから（翻訳）か、それともこの種の資料はこう書くから（ローカライズ）か？
    → draft.<locale>.md
T4  (原文, draft) に対して §5.1 の R1–R7 を実行（独立したコンテキスト）
T5 発見に基づいてdraftを修正。一貫性スキャンを実行（用語集の各用語の全文における実際の用法）。
    **もう一度 `distribution_check` を実行**——項目ごとの修正は全体の分布を変えるため、修正後は必ず分布を再確認する必要があります
T6 納品：draft + glossary + style-sheet + open-questions + decisions（＋ 長さレポート）

5.2b adapt：著者承認後の構造/ジャンル再構築（MVP）

translate はすでに文型の変更と表現の並べ替えを許可しています。adapt の違いは事前承認 + 監査可能な構造/ジャンル再構築です。ユーザーが単に「翻訳/ローカライズ」と言った場合は、引き続き translate を使用します。「日本市場向けに作り直す/日本企業の書き方に変更する/提案を再構築する」と明確に言い、かつ明示的に承認した場合にのみ adapt を使用します。

開始前に必要なもの：ターゲット読者に適合する類似資料サンプル、著者承認表、成功基準。1つでも欠けている場合は、adapt を中止するか translate に戻し、モデルが自己判断してはいけません。

再構築可能なもの：タイトルと情報階層、段落/ステップの順序、表現単位の結合/分割、ターゲット市場の表示階層、承認された業界/ジャンルの表現、 提示形式（散文 ↔ 表/番号付きステップ、AUTH-08）——この項目は単独で列挙します。なぜなら、散文から表への変更は1つの文を複数のセルに分割する可能性があり、条件や否定が分割の過程で脱落しやすいからです。 決して変更してはいけないもの：数字、日付、主体、対象、数量、時間、機能、価格、無料/有料条件、効果の強度、法的意味、否定と制限。

フロー：A0 入力/承認 → A1 ターゲット市場の慣習 → A2 事実台帳 → A3 最大2つの構造案を作成し、著者の承認を待つ → A4 セグメントごとに再構築 → A5 独立した事実/指示対象と自然さのレビュー → A6 著者による検収。著者が構造案を承認しない限り生成してはいけません。著者が検収しない限り「完了」と見なしてはいけません。

成果物：authorization.md、market-conventions.md、fact-ledger.md、structure-options.md、adapt-map.md、decisions.md、open-questions.md、完成原稿。adapt-map は、1つのソースユニットが複数のターゲットユニットに対応すること、複数のソースユニットが1つのターゲットユニットに統合されることをサポートします。N≠M は漏訳を意味しません。マッピングと事実台帳による照合が必要です。

操作型資料には、さらに task-test.md が必要です：主要タスクの成功率は translate を下回ってはなりません。より自然であっても、ユーザーが操作を失敗しやすくなる場合、adapt は失敗と見なします。

2つの機械チェックゲート（通過させなければ先に進んではいけない）：

# A3→A4：実際の著者承認イベントがなければ生成してはならない
python3 ${CLAUDE_SKILL_DIR}/scripts/adapt_check.py gate \
    --authorization <承認表> --structure <構造案> --conventions <市場慣習> [--map <adapt-map>]
# A4→A5：多対多マッピングと事実粒子を1つずつ検証
python3 ${CLAUDE_SKILL_DIR}/scripts/adapt_check.py map \
    --source <原文> --ledger <事実台帳> --map <adapt-map> --draft <目標稿> \
    --authorization <承認表> --glossary <用語集>

原文と目標稿の両方にユニットアンカー（ / ）を打つ必要があります。そうしなければユニットレベルの照合ができません。 gate の終了コード2 ＝生成不可。これがブロックするもの：AUTH-07のロック解除、「承認済み」とマークされているが著者確認イベントがない、承認された案がまだ A / B / 不承認 のようなプレースホルダである、読者に適合する検証済みサンプルがない、mapが未承認のAUTHを参照している。 「モデルが自分で表に『承認済み』と記入すること」こそ、このゲートがブロックしようとしているものです。 map の終了コード1 ＝ブロックあり。これがブロックするもの：台帳のハッシュが原文と一致しない（生成後に台帳を変更した）、ソース/ターゲットユニットがマッピングされていないか出典がない、台帳の粒子が検証表に行として存在しない（マッピングの欠落）、検証表が台帳の原文値を書き換えた、 宣言されたターゲット実装文字列がそのターゲットユニット内に見つからない（統合時に粒子が失われた）、主体のターゲット実装が用語集の定訳と一致しない（受益者が変更された）、数字/日付/URLのいずれかが片方にしかない（事実の喪失または追加）。

これらの2つのゲートが証明できることとできないことを、一緒に述べる必要があります：スクリプトは「宣言された文字列が指定されたユニットに一字一句存在するか」のみを検証し、 この文字列が意味的にその粒子を本当に表現しているかどうかは判断しません——否定を削除し、同時に検証表を実際に存在する無関係な文字列に変更した場合、機械チェックは見逃します。もう1つの穴は、ターゲット側のカバレッジがユニットレベルまでしかないことです。各ターゲットユニットに出典があることは保証しますが、ユニット内部のすべての文に出典があることは保証しません。そのため、すでにマッピングされたユニット内に捏造された文を1つ挿入しても、スクリプトは検出できません（数字/日付/URLのレベルで一部をキャッチできるだけです）。 → 対策：adapt-map 内に、人手で「追加されたテキスト」の表を作成し、表ヘッダー、脚注マーク、参照文、小見出しなどの非原文アサーションを項目ごとに書き出し、独立したレビュー担当者にチェックさせる必要があります。意味が保持されているかどうかはテンプレートFの独立レビューに、ジャンルが適切かどうかは著者検収に委ねます。スクリプト通過 ≠ adapt 通過。

詳細なテンプレートとプロンプトは、templates/authorization.md、templates/adapt-map.md、references/subagent-prompts.md のテンプレートE/Fを参照してください。

現在の検証ステータス：承認ゲートと事実マッピング契約は 32項目の自動正逆回帰テスト（evals/test_adapt_checks.py、サンプルは evals/smoke/adapt/）があり、「2→1統合ですべての条件を保持すれば通過 / 1つの否定を削除すれば失敗 / 受益者を変更すれば失敗 / 未承認では生成不可」を含みます。実際の資料（Joplinヘルプドキュメント en→ja、Evernoteセクション 15ユニット → 9ユニット）では、A0–A4 を完了しました： gate と map の両方でブロックは0、5回の敵対的改ざんはすべてブロックされました（「原稿と申告を同時に変更」による受益者すり替えを含む）。 A5 独立レビューは実施済み（バグ埋め込みラウンド + クリーンラウンドの2ラウンド検証）。A6 著者検収、ターゲットユーザーによるタスクテスト、ネイティブ通読は未実施——これら3つが完了するまで、adapt は通過と見なしてはいけません。実測の教訓：実際の資料での初回実行で報告された5つの問題はすべてゲート/テンプレート自体の欠陥でした。（案名が1文字に固定されている、慣例ファイルが2つの表形式になっている、英語の数字の綴り方、ゲートが自身で許可した「散文→番号付きステップ」をブロックしている、構造変更のない行が許可の参照を強制される）。ゲートが実際の資料に初めて触れたときに報告したエラーは、まずゲートを疑いましょう。

5.3 原文なし（翻訳文のみ）

原文がない場合、漏訳、指示対象のずれ、数字の不一致など、翻訳の実質的なエラーはチェックできません。語感、内部一貫性、表記の正規化は可能です。 char_lint / term_coverage / distribution_check（書き起こし率は適用不可）とR3を実行し、判断できないものは確認待ちリストに記載します。

ただし、sourceLanguage で指定された言語 ≠ そのテキストの著者がその言語のネイティブスピーカーであること、を意味しません。 原文なしで作業を開始する際は、必ず質問します： “このターゲット言語のテキストは誰が書いたのですか？”

ターゲット言語のネイティブスピーカーが書いた場合 → 上記の制限が成立します。読み味の問題を翻訳エラーとして記載してはいけません。
非ネイティブスピーカーが直接書いた場合（独立系開発者、海外進出チームが自社で作成したコピー）→ 著者の母語が「隠れた原文」となります。対応する pairs/<著者の母語>-<ターゲット言語>.md を読み込み、バイリンガルパスの方法で母語の干渉をスキャンします。false friend、著者の母語の語彙の残存、同一概念の未統一を発見できます。ただしレポートには、これが「母語の干渉」であり、「原文-翻訳文の対照による結論」ではないことを明記します。
著者不明 → 著者の母語を推測しません。ターゲット言語内で検証可能な問題のみを報告し、別途「著者出典未確認」とマークします。

実測（とあるアプリ、ターゲット言語のコピーが非ネイティブの著者によって直接書かれた）：単言語パスで、著者の母語の語彙の残存を数箇所発見しました。同じアプリの他の文字列では、同じ概念がすでに自然な表現で書かれていたため、これらは内部で検証可能な母語の干渉でした。 このようなケースは、独立系開発者や海外進出チームでは一般的であり、例外ではありません。

5.4 多言語並行 / 継続的更新（概要）

多言語並行：まず source of truth を決定します。用語集にカラムを追加します（概念 | 言語A | 言語B…）。数字と事実をすべてのバージョン間で照合します（fact_check.py をペアごとに実行）。「意図的に異なる」説明を保持します。継続的更新：用語集とスタイルシートは長期的な資産であり、ユーザーのプロジェクト内（.l10n/ 一時ディレクトリではなく）に配置します。新しいコンテンツはR1–R4のみを実行します。

6. 重大度、発見の形式、3つのオプション

…

[翻訳のため省略]

Localize：ローカライズと翻訳レビュー