rfc-translater

このレポジトリは、翻訳済みRFCをJSON形式で管理しています。

プロジェクト構造

• data/N000/rfcNXXX.json : 段落区切りの文書
• data/N000/rfcNXXX-trans.json : 各文章の翻訳を付与した情報
• data/N000/rfcNXXX-summary.json : RFCの要約

要件定義

• 内容
  • 文章のみ翻訳し、図や表やサンプルコードはそのまま表示すること
  • 文章がページ区切りで分割されていても1つの段落として翻訳すること
  • インデントの深さも表示に反映させること
  • 箇条書き（o + * - など）の記号はそのまま表示すること（翻訳時は箇条書き記号より後の文字列だけを翻訳する）
  • 表題（1.2.～ など）は見出しとして文字を大きくすること
• rfcNXXX-trans.json のJSON構造
  • title: タイトルデータ（オブジェクト）
    • text : 英語の原文（文字列）。先頭は必ず「RFC XXXX - 」から始まる
    • ja : 翻訳後の日本語（文字列）。タイトルのため体言止め。先頭は必ず「RFC XXXX - 」から始まる
  • contents : 各段落の内容（配列）
    • text : 英語の原文（文字列）
    • ja : 翻訳後の日本語（文字列）。箇条書き以外のときは、ですます調で表現すること
    • indent : 表示するときのインデント数（整数）
    • raw : 図表やプログラムのフラグ（true: 翻訳せずにそのまま表示）
    • section_title : 章節項の見出しフラグ（true: 見出しタイトル）
• rfcNXXX-summary.json のJSON構造
  • number: RFCの番号（整数）
  • model: 要約を生成したAIのモデル（Geminiで出力したときは “gemini-3-flash”、Claudeで出力したときは “claude-sonnet-5-5” のようなモデルID）
  • created_at: 要約生成日時（”2026-02-15T00:00:00.000000” 形式で今日の日時）。summaryを修正したときのみ更新すること
  • "summary": [ : 要約内容（配列）… インデントは2
    • 要約文（文字列。最大3文、1文は200文字以内。ですます調。強調の**やコードブロックの記号（バックスラッシュ）は使わないこと） … インデントは4
  • ] : インデントは2

新規RFCの翻訳

新しいRFCの翻訳は Claude が行います（Google翻訳などの機械翻訳は使いません）。 手順は .claude/skills/translate-new-rfc/SKILL.md、翻訳を担当するサブエージェントは .claude/agents/rfc-translator.md に定義しています。 main.py --trans-prepare / --trans-export / --trans-import / --trans-finish は、翻訳対象の抽出と訳文の検証・適用だけを行う補助コマンドです。

要約（rfcNXXX-summary.json）も Claude が作成します。手順は .claude/skills/summarize-rfc/SKILL.md に定義しています。 作成・修正したら python3 main.py --rfc <RFC番号> --summary-check で形式を検証してください。

翻訳スタイルガイド

RFCは仕様書です。読者は日本語訳から実装の可否を判断します。したがって訳文の良し悪しは「読みやすさ」ではなく「原文と同じ規範強度・同じ識別子を復元できるか」で決まります。 以下は訳文が満たすべき必須要件です。人手による修正、AIによるレビュー、新規翻訳のいずれもこの規約に従ってください。

1. RFC2119キーワードの訳語（最重要）

RFC2119/RFC8174のキーワードは規範強度そのものであり、意訳してはいけません。 下表の訳語を1対1で使い、末尾に原語を丸括弧で併記します。

原文	規範強度	日本語訳
MUST / SHALL / REQUIRED	必須	〜しなければなりません (MUST)
MUST NOT / SHALL NOT	禁止	〜してはなりません (MUST NOT)
SHOULD / RECOMMENDED	推奨	〜すべきです (SHOULD)
SHOULD NOT / NOT RECOMMENDED	非推奨	〜すべきではありません (SHOULD NOT)
MAY / OPTIONAL	任意	〜してもよい (MAY)

• 併記する原語は (MUST) のように半角丸括弧で書き、直前に半角スペースを入れます。
• 「〜する必要があります」をMUSTの訳に使わないこと。 SHOULD相当にも読めるため、 規範強度が曖昧になります（現状の最頻出の欠陥です。W012）。
• SHOULD NOT に「〜してはなりません」を当てないこと。MUST NOT に格上げされてしまいます。
• 原語の併記は、原文のキーワードと同じ種類・同じ個数にします。段落内に MUST が2つあれば (MUST) も2つです。
  • 付け漏れは強調表示から抜け、読者が規範を見落とします（E014、1つも併記がない段落は W011）。
  • 原文が小文字の should や is required to の箇所に (SHOULD) (MUST) を付けないこと。原文にない規範性を足してしまいます（E015）。
• 原文が小文字の must / should は通常の助動詞であり、規範キーワードではありません。 この規約の対象外です。

2. 識別子の表記を壊さないこと

プロトコルのフィールド名・変数名・OID名などの識別子は、原文と一字一句同じ表記で 訳文に残します。機械翻訳はCamelCaseを平坦化するため、ここが最も壊れやすい箇所です。

• 誤: smLaunchOwner → 「Smlaunchowner」、id-signedData → 「id-signeddata」
• 正: smLaunchOwner → 「smLaunchOwner」、id-signedData → 「id-signedData」
• 大文字略語（CEDEX, HMAC, PKIXCERT など）も原文の表記を維持します。
• 文脈から一つの名詞句と判断できるもの（例: application/geo+json-seq）は、 / や + の前後の空白を除去します。

3. 翻訳しない要素

• raw が true の段落（図表・プログラム・ASN.1定義など）は ja を空文字にします。 一切翻訳・修正しないこと。
• 参考文献リストの著者名・文献タイトル・URLは原文のまま残します。
  • 参考文献エントリ内の著者名表記（Bradner, S. など）を「、」「。」で区切ったり誤訳したりせず、原文表記のまま残します（E011）。
• 著者情報（氏名・所属・住所・メールアドレス）は原文のまま残します。
• URLは訳文中でも原文のまま残し、表記を変更しません。
  • 全角コロン（https：//）や余計な空白（https ：//）を入れず、半角表記（https://）を維持します（E012）。

4. 差分・対比構文（OLD/NEW）

RFC更新（Updates）や正誤表（Errata）セクションにおける差分指示子は、前後の対比文脈を踏まえて次のように翻訳します。

• OLD: → 「旧：」
• NEW: → 「新：」
• PROPOSED/NEW: → 「提案/新：」
• 「年：」「古い：」「新着：」「新しい：」などの単語直訳を当ててはなりません（E013 相当の誤訳）。

5. 文体

• 本文（section_title が false）はですます調で統一します。
• 見出し（section_title が true）は体言止めにします。
  • 誤: 「6.1.1. hello コマンドを処理します」
  • 正: 「6.1.1. hello コマンドの処理」
• 箇条書きは記号（o * - 1. など）を原文のまま残し、記号より後だけを訳します。
• title.ja は必ず RFC XXXX - で始め、体言止めにします。

6. 単語置換時の段落全体の構文・意味疎通の再検証

機械翻訳由来の訳文は、特定の誤訳単語（例: drop=滴、cell=細胞、close=近い、party=宴会など）の品詞や文脈誤判定に引きずられ、文全体の構文（係り受け、語順、肯定・否定の逆転、時刻表記の分断など）が歪んでいることが多々あります。 単語を置換した際は、単語単体の差し替えにとどまらず、段落全体として技術的・日本語的に意味が通っているかを必ず精査し、必要に応じて段落全体を自然な日本語へ改稿してください。

7. 検証

翻訳を修正したら、必ず次を実行して機械的に検証してください。

python3 tools/lint_translation.py --rfc <RFC番号> --format text

このlinterは上記1〜5のうち原文と照合して決定的に判定できる違反のみを検出します （意訳の良し悪しは検出しません）。E で始まるコードは必ず修正し、W は内容を確認 した上で対応します。JSONの構文が壊れていないことも併せて確認してください。

python3 -m json.tool data/N000/rfcNXXX-trans.json > /dev/null

8. 修正の優先順位

どのRFCから直すかは tools/rank_rfcs.py が決めます。他のRFCからの被引用数を 重要度の代理指標とし、linterの検出数を深刻度として掛け合わせて順位を出します。

python3 tools/rank_rfcs.py --scan            # 全件スキャン (帯ごとに --dir 指定で再開可)
python3 tools/rank_rfcs.py --report --check E002 --limit 30

修正が済んだRFCは再スキャンすると検出数が減り、自動的に順位が下がります。 進捗管理用の状態ファイルは持ちません（linterの結果そのものが進捗です）。

9. 用語集

訳語が複数ありうる用語は、下表の訳語に統一します。同じ原語を1つのRFCの中で訳し分けないこと。

原文	訳語	備考
shared secret key	共有秘密鍵	「共有シークレットキー」「共有秘密の鍵」は使わない
shared secret	共有シークレット	後ろに key が続かない場合。”shared secret information” は「共有シークレット情報」
shared secret keying material	共有シークレット鍵素材	「共有秘密鍵素材」「共有秘密鍵マテリアル」などは使わない
congestion	輻輳	「混雑」「渋滞」は使わない（道路の渋滞を述べる箇所を除く）
ingress	イングレス / 入口	文脈に応じてどちらでもよい（迷ったらイングレス）。「侵入」は使わない（原文が intrusion 等の場合を除く）

機械翻訳に由来する既知の誤訳語も使わないこと: traffic→「交通」、cell→「細胞」、salt→「塩」、 handshake→「握手」、peer→「仲間」、torn down→「取り壊し」「引き裂き」。 ただし、原文が道路・航空・車両の往来を述べている箇所の traffic は「交通」（航空交通管制、交通事故など）、 生物学の cell は「細胞」が正しい訳です。

用語集の違反は linter の W014 で検出されます。また、原文の数値や識別子が訳文から大量に 消えている段落（LLMによる捏造・切り詰めの疑い）は W013 で検出されます。

補足: スクリプトの置き場所

• tools/ : 恒久的に使うツール（linter、優先順位付け）。消さないこと。
• scripts/ : 一括置換などの使い捨てスクリプト。作業後に破棄してよい。

This site is open source. Improve this page.