RFC日本語学習環境をClaude Codeのカスタムスキルで育ててみた

RFC日本語学習環境をClaude Codeのカスタムスキルで育ててみた

2026.03.06

こんにちは。小売流通ソリューション部で認証まわりをやっている宮部です。

皆さん RFC を読んでいますか?
AI に「◯◯という課題を解決したいけど RFC の標準の仕様が定まってるなら教えて」などと質問をしたことがある方も多いかと思います。

私の経験上そのような場面での回答は大枠では正しいのですが、更に詳しくどの RFC のどのセクションなのかを聞くと存在しない RFC やセクションを提示してくることがあります。

これはニュアンスという点では問題ないですが、他人に説明するときに誤った情報を伝えてしまうことになります。
また、大枠で内容が正しい場合でも、複数の RFC を統合して得られた結果である可能性があり RFC 同士が矛盾したりする場合を考えると可能なら一次情報を参照したいです。

しかし、 RFC は英語かつ、RFC の文章フォーマットの都合上翻訳ツールを使うと改行などの影響で意図していない和訳になることがあります。

そこで Claude Code のカスタムスキル機能を使って RFC を日本語翻訳する /rfc-library スキルを作り個人的に使用しています。最初はシンプルな翻訳ツールでしたが、使いながら不満が出るたびに機能を足していき、いつの間にか RFC の学習環境として育っていきました。その過程を紹介します。

Claude Code のカスタムスキルとは

Claude Code には .claude/skills/ ディレクトリにスキルを定義することで、/スキル名 という形でコマンドとして呼び出せる機能があります。

定義ファイル(SKILL.md)の冒頭はこんな形です。

---
name: rfc-library
description: RFCやInternet-Draftを日本語に翻訳してHTMLライブラリとして管理する。
allowed-tools: WebFetch, Write, Bash
---

# RFC翻訳ライブラリスキル
(以降、Claudeへの自然言語の指示...)

この設定で /rfc-library というスラッシュコマンドとして使えるようになります。

翻訳するだけ

最初の /rfc-library はシンプルなものでした。URL を渡すと RFC を取得して翻訳し、マークダウンファイルとして保存するだけです。HTML もなく、出力は .md ファイル1つだけ。

/rfc-library https://www.rfc-editor.org/rfc/rfc6749.html
# → rfc-6749.md が生成されるだけ

この時点で翻訳方針として決めていたのが RFC 2119 キーワードの統一です。MUST / SHOULD / MAY などは RFC の要求レベルを示すキーワードで、訳し方がブレると意味が変わってしまいます。

原文 日本語訳
MUST / REQUIRED / SHALL しなければなりませんMUST
MUST NOT / SHALL NOT してはなりませんMUST NOT
SHOULD / RECOMMENDED すべきですSHOULD
SHOULD NOT / NOT RECOMMENDED すべきではありませんSHOULD NOT
MAY / OPTIONAL してもかまいませんMAY

仕組みとしては RFC に限らず、どんな文章にも応用できますが RFC に絞った結果思わぬ利点がありました。

  • セクション構造が決まっている
    • Abstract・Introduction・Security Considerations といった構成が RFC 全体で共通しているため、「このセクションは翻訳する/しない」という判断を自動化しやすい
  • URL のパターンが一定
    -rfc-editor.org/rfc/rfcXXXXdatatracker.ietf.org/doc/draft-... など URL の形式が決まっているため、RFC 番号や Draft 名の抽出・TXT 版 URL の構築を確実にコード化できる
  • TXT 形式で取得できる
    • RFC は公式に TXT 版を配布しており、マークアップのないプレーンテキストで翻訳対象を取得できる

これだけでも当初の目的(英語の RFC を日本語で読む)は達成できていたのですが、使っていくうちにいくつかの不満ともっと便利にしたい欲が出てきたのでさらに改善をしていくことにしました。

PDF 版でトークンを使い切った

最初は RFC の取得先を指定していなかったため PDF 版で取得するときがありました。巨大な RFC を翻訳しようとしたとき、途中でトークンを使い切ってしまいました。終業です。

RFC Editor は HTML / TXT / PDF などで RFC を配布しています。PDF をテキストとして読み込むと改行・ページ番号・ヘッダーのノイズが多く、トークンを大量消費していたのが原因でした。そこで TXT 版に切り替えたところ、トークン効率が約44%向上しました。TXT 版はプレーンテキストで本文のみなので、Claude が読み込む量も自然と減ります。

また RFC の規模によって処理時間は変わります。短めの RFC であれば数分で完了しますが、長めの RFC はそれなりに時間がかかります。仕事終わりにコマンドを叩いて、翌朝結果を確認するくらいの感覚で使っています。

Internet-Draft はバージョン番号が URL に含まれるため、まず datatracker ページを取得して最新のバージョン番号を確認し、そこから TXT を取得するようにしています。RFC と Draft で挙動を自動的に切り替えているので、どちらの URL を渡しても同じコマンドで動きます。

# RFC の場合
/rfc-library https://www.rfc-editor.org/rfc/rfc6749.html

# Internet-Draft の場合(最新バージョンを自動検出)
/rfc-library https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/

生成したけど読まない

いっぱい出力して読まなくなりました。

日本語で読めるようにはなりましたがそもそもの文章量が多いのもあり後回しにしがちになってしまいました。

そこで最低限の内容だけでも記憶の片隅に入るように以下のファイルも翻訳以外に生成させるようにしました。

tab

RFCの要約

そのRFCがどんな課題を解決したいのか、どんな仕様なのかを要約させるようにしました。

用語集

専門的な用語や、その RFC 内で新たに作られた概念などがあると要約だけあっても理解するのが難しいため用語集も生成させました。

問題集

理解度チェックとして数問の問題を作成させるようにしました。
これは要約をベースにしているため、要約には存在しない重箱の隅をつつく問題は作成されません。

## 重要な用語

| 用語 | 説明 |
|------|------|
| アクセストークン | 保護されたリソースにアクセスするための証明書 |
| 認可サーバー | アクセストークンを発行するサーバー |

このテーブルを読んで、こんな形の問題を自動生成します。

const quizData = {
    title: 'The OAuth 2.0 Authorization Framework',
    questions: [
        {
            text: '保護されたリソースにアクセスするための証明書は何ですか?',
            answer: 'アクセストークン',
            explanation: '正解:アクセストークン \n 解説:保護されたリソースにアクセスするための証明書'
        },
        // ...
    ]
};

翻訳しながら問題集まで一緒に作ってくれるのは、Claude に指示を書いておくだけで実現できるスキルならではの体験です。

question

さらに和訳された RFC はマークダウンとして手元に残るため、AI のリファレンスとして活用できるのも大きなメリットです。翻訳済みの .md ファイルを Claude Code のコンテキストに読み込ませれば、「この RFC のセクション 3.2 にはこう書いてある」という手元の翻訳に基づいた回答が得られます。冒頭で触れたハルシネーション問題への直接的な解決策になります。

また、用語集の蓄積はそのまま他者との会話でも使える資産になります。

この3つを使うことで体系だった理解ではなくとも脳内に少しでもインデックスが貼られるようにと考えました。

生成したページのフォーマットが安定しない

翻訳したファイルが蓄積されていくと新たな不満が出てきました。出力のフォーマットが微妙に変わるのです。要約と用語集の粒度が変わったり、問題集の問題と回答のフォーマットがバラバラだったりと Claude に任せているので毎回少しずつブレが出ていました。

そこで 各ファイルへのリンク集ページ → HTML 化 → テンプレート化 という流れで整備していきました。

RFC ごとに異なるのはタイトルや本文などの中身だけで、ページの骨格は毎回同じです。そこで HTML をテンプレートファイルとして切り出し、変数部分だけを差し込む方式に変えました。

<!-- rfc-page.html(抜粋) -->
<title>{{RFC_NUMBER}} - {{TITLE_JA}}</title>
<h1>{{RFC_NUMBER}}</h1>
<div class="subtitle">{{TITLE_JA}}</div>
{{BADGES}}

Claude はテンプレート変数に埋め込む値(タイトルなど)を生成するだけで、HTML の骨格には一切触れません。generate-html.py というスクリプトが .index.yml(翻訳済み RFC のメタデータ管理ファイル)からそれらの値を読み取ってテンプレートに流し込みます。

これにより Claude のアウトプットが「翻訳テキスト」に集中し、同じ HTML を何度も生成させるトークンの無駄もなくなりました。テンプレートを変更したいときも rfc-page.html を編集して --rebuild-all を叩くだけで全ページに反映されます。

/rfc-library --rebuild-all   # テンプレート変更後に全ページ再生成

ブラウザでプレビュー

/rfc-library --serve
# → http://localhost:8080 が自動で開きます

デフォルトでは 8080 ポートで開きますが被る可能性もあるので指定できます。

/rfc-library --serve 3000

toppage

大きな RFC は少しずつ翻訳したい

巨大な RFC を翻訳していると、途中で Claude のコンテキストが溢れたり、すべてのセクションを翻訳するのは後回しにしたいときがあります。
そこで 1セクション翻訳するたびに .md に追記 + .progress.yml を更新する設計にしました。

# .progress.yml の中身
url: "https://www.rfc-editor.org/rfc/rfc9700.txt"
dir: "oauth-2-0-security-best-practices"
status: "in_progress"
sections:
  - id: "abstract"
    status: "completed"
  - id: "1-introduction"
    status: "completed"
  - id: "2-client-authentication"
    status: "pending"

同じ URL で再実行すると .progress.yml を読んで自動的に続きから再開します。

/rfc-library --resume oauth-2-0-security-best-practices

terminal

Internet-Draft は改版する

OAuth 周りの Internet-Draft は改版が頻繁で、気づいたらバージョンが上がっていることもあります。毎回全文翻訳し直すのは現実的ではないので、差分翻訳機能を実装しました。

/rfc-library --check-updates                       # 更新があるDraftを一覧
/rfc-library --diff draft-ietf-oauth-status-list   # 差分翻訳

処理の中身は以下です。

  1. 旧版と新版の TXT を取得して diff -u で差分検出
  2. 変更セクションのみ翻訳・md を置き換え
  3. 何が変わったかを記録した CHANGELOG.md を生成
  4. .index.yml のバージョンを更新
  5. generate-html.py で HTML を再生成

変更量に応じますが、翻訳時間を最大 90% 削減できます。

RFC が増えて関係が気になってきた

翻訳した RFC が増えてくると「この RFC はどれを参照していて、どれに更新されているのか」といった関係性が見えてきます。
そこで .index.ymlreferencesobsoletesupdates フィールドをもとに、RFC 間の関係をインタラクティブなネットワークグラフとして描画する docs/graph.html を追加しました。

- id: "rfc9449"
  title: "OAuth 2.0 Demonstrating Proof of Possession (DPoP)"
  references:
    - "rfc6749"
    - "rfc7515"
  obsoletes:
    - "rfc8707"
  updates:
    - "rfc6750"

エッジの色でそれぞれ「参照(青・破線)」「廃止(赤・実線)」「更新(オレンジ・実線)」を見分けられます。ノードをダブルクリックすると、収録済みの RFC は個別ページへ、未収録の RFC は rfc-editor.org へ直接飛べます。

/rfc-library --graph   # 関係グラフのみ再生成

graph

3000 行の巨大 SKILL.md になってしまった

機能が増えるにつれて SKILL.md への記述も増え続け、気づいたら 3000 行近い巨大ファイルになっていました。これだと Claude がすべてを読み込むのにトークンを大量消費し、かつ指示が長すぎて意図通りに動かないことも出てきました。もはやスキルの範囲を超えています。

Claude Code と相談しながら設計を見直した結果、以下の方針に切り替えました。

  • 詳細仕様は docs/ 以下のファイルに分散させ、SKILL.md からは参照するだけにする
  • HTML 生成・サーバー起動・セットアップなど副作用を伴う処理はスクリプトに切り出し、Claude は Bash ツール経由で呼び出すだけにする
.claude/skills/rfc-library/
├── SKILL.md                       # スキル本体の定義(120行に収まっている)
├── scripts/
│   ├── generate-html.py           # HTML 生成スクリプト
│   ├── setup.sh                   # 初回セットアップ
│   └── server.sh                  # ローカルプレビューサーバー
└── docs/                          # 詳細仕様ドキュメント
    ├── REFERENCE.md               # 10 ステップの処理フロー詳細
    ├── HTML_GENERATION.md         # HTML 生成仕様
    ├── DIFF_TRANSLATION.md        # 差分翻訳仕様
    ├── GLOSSARY_GUIDE.md          # 用語集の生成ルール
    ├── EXAMPLES.md                # 使用例・チェックリスト
    └── GRAPH.md                   # RFC関係グラフ機能の仕様

Claude はオプションに応じて必要なドキュメントだけを読みに行くため、コンテキストの無駄遣いも減りました。機能を追加しても SKILL.md は 120 行に収まっています。

参照ファイル 役割
docs/REFERENCE.md 翻訳の 10 ステップ詳細・.progress.yml の書き方
docs/HTML_GENERATION.md generate-html.py の仕様・テンプレート変数
docs/DIFF_TRANSLATION.md --check-updates / --diff の処理フロー
docs/GLOSSARY_GUIDE.md glossary.md の生成ルール
docs/GRAPH.md RFC 関係グラフの仕様・フィールド定義

最終形

今では翻訳・HTML 生成・インデックス更新・グラフ更新まですべて 1 コマンドで動きます。

/rfc-library --setup                  # 初期セットアップ(初回のみ)

setup.sh が実行され、_defaults/ からリポジトリの docs/ へテンプレートやアセットをコピーし、空の .index.yml が作られます。

docs/
├── .index.yml
├── .config.yml
├── .glossary.yml
├── _assets/
│   ├── styles.css
│   └── viewer.js
└── _templates/
    ├── rfc-page.html
    ├── index-page.html
    └── graph-page.html

セットアップが完了したら、あとは URL を渡すだけです。

/rfc-library --setup                  # 初期セットアップ
/rfc-library <URL>                    # 翻訳(全自動)
/rfc-library <URL> --full             # References/付録まで全文翻訳
/rfc-library <URL> --skip-html        # HTML 生成をスキップ
/rfc-library <URL> --skip-index       # インデックス更新をスキップ
/rfc-library <URL> --md-only          # マークダウンのみ生成
/rfc-library --resume <rfc-dir>       # 途中から再開
/rfc-library --check-updates          # Internet-Draft の更新確認
/rfc-library --diff <draft-name>      # 差分翻訳
/rfc-library --rebuild-all            # 全 HTML を再生成
/rfc-library --rebuild-index          # トップページのみ再生成
/rfc-library --graph                  # RFC 関係グラフのみ再生成
/rfc-library --serve [port]           # ローカルサーバー起動(デフォルト 8080)
/rfc-library --stop                   # サーバー停止

翻訳のたびに docs/.index.yml にエントリが追加されていき、カテゴリ・ステータス・関連 RFC などをまとめて管理できます。

rfcs:
  - id: "rfc6749"
    title: "The OAuth 2.0 Authorization Framework"
    title_ja: "OAuth 2.0 認可フレームワーク"
    category: "OAuth 2.0"
    status: "Standards Track"
    translated_at: "2026-02-10"
    path: "rfc-6749-the-oauth-2_0-authorization-framework/rfc-6749-the-oauth-2_0-authorization-framework.md"
    references:
      - "rfc6750"
      - "rfc6819"

感想

「URL を渡すと翻訳するだけ」のシンプルなスキルが、使いながら課題を解決していくうちに RFC の学習環境として育っていきました。自分にあった学習スタイルを自分で作れるのはいいですね。

既に多機能すぎるくらいのスキルになってしまっているためこれ以上の拡張はしないつもりです。

SKILL.md に全部書かずに詳細仕様を docs/ 以下のファイルに分散させる設計も、Claude Code と相談しながらスキルとして妥当な規模と範囲になるように数日おきに改善を行わせた結果です。

Claude Code のカスタムスキル、意外と自由度が高くて面白いのでぜひ試してみてください。

参考

この記事をシェアする

FacebookHatena blogX

関連記事