すでに知っている内容と、これから学ぶ内容を分ける
すでに持っている資格の知識を起点に、次の資格で学ぶ「残り」を出したい。そのために、公式の出題範囲を表にし、資格をまたいで内容の重なりを数える仕組みを作りました。
対象は、無料のツール「合格ロードマップ」です。今回扱うのは、2026年10月6日から12日に記録した、比較のための表の設計と検証です。
比較では、同じ論点が出題範囲に含まれるかに加え、どの深さまで扱うかを区別しました。用語や考え方を知っている段階と、計算・処理ができる段階、さらに応用や判断に使う段階を分けています。内容の名前が重なっていても、目標とする資格で求められる深さに届いているかは、別に確認する必要があるためです。
そこで、公式文書の見出し、資格をまたぐ共通の論点、両者を結ぶ対応を、それぞれ別のファイルに持たせました。
原典の見出しと、比較のための判定を分ける
表の構成は次のとおりです。公式文書から写す部分と、自分たちが設計・判定する部分を区別しています。
| ファイル | 中身 | 誰が決めるか |
|---|---|---|
exams.json |
各資格の公式の出題範囲を、見出しのまま行にしたもの（出典の URL と取得日つき） | 公式の文書から写すだけ |
topics.json |
資格をまたぐ共通の論点（論点ID・一般名詞のラベル・分野）。深さの尺度 0〜3 を定義 | 自分たちが設計 |
crosswalk.json |
論点 × 資格 の1行ずつ。その資格でどこまで出るか（depth）・根拠の見出し（exams.json に実在する見出しだけ）・判定の理由 | 自分たちが判定し、根拠を書く |
深さの尺度は、0が「出題範囲に無い」、1が「用語・考え方」、2が「計算・処理ができる」、3が「応用・判断」です。3には、複数の論点の組み合わせ、意思決定、記述を含めました。
公式文書の見出しは、そのまま原典側に残します。一方、共通の論点や深さの対応づけは、比較のために設計し、判定する部分です。その判定を公式文書の記述と混ぜず、理由を専用の欄に書く形にしました。
深さが同じでも、扱う視点が違う論点はあります。その違いも判定理由に記録し、すでに知っている資格の言葉で説明し直す対象にしました。数値として同じ深さに分類されたことだけで、内容の違いまで消してしまわないための扱いです。
対応の欠けと重複を、計算の前に検査する
差分を計算する道具には、起動するたびに通る検証を設けました。条件を満たさなければ、その場で止まります。
検証するのは、論点IDと資格IDが実在すること、depthが0〜3の整数であること、depthが1以上なら根拠の見出しがあることです。さらに、すべての「論点と資格」の組み合わせが、ちょうど1行ずつ存在することを確認します。対応が欠けていても、重複していても検証は通りません。
この設計では、「出題範囲に無い」はdepthの0として表します。行そのものが欠けている状態とは区別されます。内容が対象外なのか、対応表への記載が抜けたのかを、同じ空欄として扱わない構成です。
最初の見本では、論点28、資格3に対して対応は84行でした。28×3の組み合わせがそろい、欠けは0です。比較結果を見る前に、比較に必要な行がそろっていることを確かめました。
ただし、対応がそろっていることと、個々の判定の内容は別です。行数や値の条件は機械で検査し、どの見出しを根拠に、なぜその深さと判断したかは、対応表に残す形にしています。
範囲を広げても、計算と確認の手順を保つ
2026年10月12日時点では、対象を論点66×資格7に広げました。画面では目標の資格を切り替えられ、組み合わせを /?target=...&have=... の形式で共有できます。
また、先に学ぶべき論点の依存関係と目安の時間をつけた「学ぶ順番（残りだけ）」も出しています。この出力にはAIを使っていません。比較のために用意した表に加え、依存の順と目安の時間を持たせています。
AIを使ったのは実装の分担です。差分を計算する道具とテストは、仕様を固めてからCodexに実装させました。その結果を自分たちで実測して確かめてから取り込み、テストは5件から9件になりました。実装を依頼する前の仕様と、取り込む前の確認を、作業の中に置いています。
原典の更新も、追い続ける必要があります。最初の見本に使った公式文書の取得日は、2026年10月6日です。簿記については、次の年度からの暫定版が別に公表されていることを確認しました。対応表を作った時点だけで完結させず、どの版を参照した表なのかを残し、毎年の改定を追う必要があると判断しています。
業務に置き換えると
社内規程、マニュアル、研修資料、製品仕様の差分を取る仕組みに置き換えるなら、今回の記録から点検できるのは次の項目です。
- 原典を見出しの行として残しているか。 比較用の共通項目を設け、その項目と原典の見出しを対応づけます。原典の記述と比較のための分類を分けて確認できる形にします。
- 判断の理由を書く欄が決まっているか。 人が判断した理由は専用の欄に集め、原典から写した記述に混ぜないようにします。対応づけの根拠となる見出しも残します。
- すべての組み合わせがちょうど1行あるか。 対応の欠けと重複は、計算のたびに機械で検査します。行が無い状態を、その項目が対象外であるという判定で代用しないことも点検対象です。
- 原典の版と取得日が残っているか。 どの年度の文書を使って比較したかを記録し、改定を追います。今回も、翌年度の暫定版の存在が、更新を継続して確認する理由になりました。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。