対応表

対応表の概要

目的と役割

対応表は、複数の要素が互いにどう結びつくかを、行と列の構造を用いて明示する仕組みである。主な目的は、異なるデータ源や表現形式の間で「同じ意味」や「同一条件に相当する値」を体系的に扱えるようにすることである。これにより、参照・変換・照合の工程が再現可能になり、担当者やシステムごとの解釈のばらつきを抑えられる。

役割としては、(1) 入力を内部の標準表現へ揃える変換、(2) 保存済みの値を外部仕様に合わせて出力する整形、(3) ある値が別のデータにおいて何に相当するかを確認する照合、の3点が中心となる。さらに、変更が起きた場合に「対応ルール」を表として更新できるため、運用の透明性も高まる。

用語と基本概念

対応関係

対応関係とは、対応表が表す「要素同士の結びつき」の性質である。たとえば、あるコードAがコードBに、名称Xが名称Yに、ある条件値が判定カテゴリに、というように意味的な同値や機能的な同等を対応づける。

対応関係は、単に値を並べることではなく、結びつけの条件（いつ・どの範囲で・どの粒度で同等とみなすか）を暗黙ではなく表の設計として保持する点に価値がある。設計が明確であれば、後から別システムへ移植する際にも同等性の扱いを再現しやすい。

主キーと参照先

主キーは、対応表の中で特定の行を一意に識別するための要素である。参照先は、その主キーに対応して取り出したい結果側の要素（変換後の値、照合の判定結果、参照する外部項目など）を指す。

主キーと参照先を分けることで、問い合わせの方向がはっきりする。たとえば「外部値を主キーとして参照先を取得する」場合は変換用途に向き、「標準値を主キーとして外部表現を参照する」場合は出力整形に適する。方向性が曖昧だと、同じ表でも利用者が誤った列を参照しやすくなるため、列定義と利用手順で明確化する。

一対一・一対多・多対多

対応関係の形式は、主キーに対して参照先がどう振る舞うかで分類できる。

一対一は、主キー1件に対して参照先が1件だけ存在する。変換が単純で、照合の結果も安定しやすい。一対多は、主キー1件に対して参照先が複数存在する。たとえば「同じ分類に属する複数コード」などが該当する。多対多は、双方が複数対応を持つ状態であり、正規化や分解をしないと衝突や重複の管理が難しくなる。

運用上は、どの形式を意図しているかを列設計とデータ制約で表現することが重要である。意図が一対一であるのにデータが増えて一対多に膨らむと、参照結果が決まらず、利用側の推測に依存して破損が起きやすい。

利用場面

対応表は、異なる表現間をつなぐ需要がある場面で頻出する。代表的には、システム間のデータ連携、帳票や画面の表示仕様の差異吸収、レガシーコードの取り扱い、標準分類の適用などが挙げられる。

また、品質監査やデータ統合の局面でも有効である。たとえば複数部門で使われてきた項目名やコード体系を束ねる際、対応表が「統合の根拠」として機能する。加えて、入力値の標準化や、過去データの互換性確保にも役立つため、データガバナンス施策の一部として位置づけられることが多い。

対応表の作り方

データ設計の基本

対象項目の定義

最初に、対応表の対象となる項目を具体的に定義する。項目とは、対応づけの対象となるコード、名称、属性値、あるいは判定カテゴリなどの単位である。定義には、データ型（文字列・数値など）、想定される値の範囲、表記の粒度（短縮形、正式形）、有効期間の有無、欠損の扱い（空欄を許容するか）を含める。

次に、どちらを主キー側として扱うかを決める。主キー側は「検索・変換の入力」になりやすい。ここが不適切だと、利用時に逆参照が多発し、運用ミスの温床になる。要件に応じて「入力→出力」の流れと整合する選択を行う。

変換ルールの決定

変換ルールは、対応関係が成立する条件を定める工程である。単純な対応だけでなく、例外、優先順位、補正、フォールバック（該当なしの扱い）もルールに含める。

たとえば、表記ゆれ（全角半角、大小文字、区切り記号）を吸収するのか、別の前処理で行うのかを整理する必要がある。さらに、同一入力に複数の候補がある場合の解決策（最頻、最新、有効日優先など）を明記しないと、参照結果が非決定になる。

ルールを決める際は、利用者の観点で「この入力を渡したら何が返るべきか」を具体例で確認すると、仕様の抜けを早期に発見しやすい。

表の形式とレイアウト

列の設計

列設計では、最低限として主キー列と参照先列を用意し、必要に応じて補助列を追加する。補助列には、適用条件、有効期間、ソース情報、優先度、メモ（なぜその対応になったか）などが含まれる。

型の整合性にも注意が必要である。文字列として扱うべき値が数値列に混在すると、先頭ゼロの欠落や桁落ちが起きうる。日付や区分の列は、比較可能な形式に揃えておくと後の照合が簡単になる。列名は意味が一意になるようにし、利用側が誤解しないようにする。

また、列の数が増えるほど保守負荷が上がるため、必要性を基準化する。参照先だけで足りる場面では補助列を増やさず、監査や履歴が必要な場面でのみ拡張する方針が合理的である。

見出しと単位の扱い

見出しは、列が表す内容を誤読なく伝えるための要である。特に単位が関係する数値（通貨、長さ、時間、温度など）は、単位を列側に明示し、同じ列に異なる単位を混ぜない設計が望ましい。

単位の扱いが曖昧なまま運用すると、変換表が「正しくても誤った変換」を生成しうる。たとえば、同じ数値でもcmとmmが混ざると結果が10倍違ってしまう。対応表で変換する対象が値のみなのか、単位込みの値なのかを要件段階で切り分けることが重要である。

見出しは日本語・英語の混在があると混乱が増えるため、組織の命名規約に合わせ、表の読み手が迷わない状態を維持する。

品質管理

重複と欠損の検出

品質管理では、対応表の整合性を機械的に検出する。重複は、主キーの一意性が崩れている場合や、同一条件で同じ結果が複数行に現れる場合などに相当する。欠損は、必要な入力に対して対応が存在しない、参照先が空である、または必須列が未入力であるケースである。

検出方法としては、主キーの重複チェック、参照先の必須性チェック、値の範囲検証、外部ソースと突合した件数対照などが用いられる。特に一対一を意図する場合は、重複検知が最重要になる。逆に一対多を意図している場合は、重複を形式的に許容しつつ、候補のルール（優先度や有効日）を検証する必要がある。

一貫性の検証

一貫性とは、表の別列間で矛盾がないこと、期待する対応形式に沿っていることを指す。たとえば、ある列では同一カテゴリに属すると定義しているのに、別の補助列の条件が違うために矛盾する、などが該当する。

検証は「行単位」だけでなく「表全体」でも行う。例として、相互参照（A→Bの後にB→Aが成立するか）、更新時の連鎖影響、履歴の連続性（有効期間が飛ぶ、重なる）などが挙げられる。対応表はデータ変換の基盤であるため、些細な矛盾が上流・下流で増幅されやすい。

そのため、テストデータを用いたサンプル照合や、代表的な入力値セットを固定して回帰検証する運用が有効である。

対応表の運用と管理

更新とバージョン管理

更新履歴の記録

対応表は時間とともに変化する。コード体系の改定、名称変更、分類の見直し、有効期間の追加などが発生するため、更新履歴は必須の管理対象である。履歴には、変更日時、変更者または変更プロセス、変更理由、影響を受ける範囲、テーブル上の差分（どの主キーがどう変わったか）を残す。

履歴を残すことで、監査対応が可能になるだけでなく、過去時点の再現も容易になる。特に有効期間を扱う場合、参照するべきバージョンが時点で決まるため、いつの表を使うべきかを明確化できる。

また、更新は一括で行うだけでなく段階移行する場合がある。その際も、旧ルールと新ルールを共存させる期間や、切替基準を記録に落とすと混乱を減らせる。

互換性の方針

互換性の方針は、旧仕様をどこまで維持し、新仕様へどう移行するかを決める考え方である。たとえば、主キーに対する参照先が変わった場合に、旧値の扱いをどうするかが論点になる。

互換性を保つ代表策には、(1) 旧対応を残し、新しい対応を追加する、(2) 旧対応は無効化するが参照可能な形で保管する、(3) 変換結果が変わる場合は利用側に通知し、再処理を求める、などがある。どの方針を採るかは、利用データの保存期間、再計算コスト、運用体制に依存する。

方針は文書化し、利用者が「この表はいつから何が変わったのか」を判断できるようにするのが望ましい。

参照・利用の手順

利用者向けの説明

利用者向けの説明では、表の使い方が誤解なく伝わるようにする。説明には、主キーの入力条件、照合手順、返却される値の意味、欠損や複数候補時の動作、適用バージョンの指定方法などを含める。

特に重要なのは「どの列をどう使うか」を明文化する点である。利用者が列名から推測して誤る事態を避けられる。加えて、代表的な例（入力→出力の具体例）を添えると理解が早い。

説明は更新と連動させる。表のルールが変わったのに説明文が古いままでは、教育コストが増え、再発防止が機能しなくなるためである。

破損・誤りへの対処

誤対応の影響範囲

誤対応が発生した場合、影響範囲を素早く特定する必要がある。影響は、対応表の利用箇所、参照される主キーの集合、下流でどの処理が行われるかによって変動する。

たとえば変換結果が課金計算に影響している場合と、表示用の補助情報に留まる場合では被害の大きさが異なる。対応表の利用ログ、参照した主キー、当時のバージョンを追跡できる仕組みがあるほど、影響範囲の推定が精密になる。

特定の観点としては、(1) 変換結果が変化した対象、(2) 適用した時点が表の有効期間に入っていたか、(3) その結果が保存されているか、の3点を中心に整理すると判断が速い。

リカバリー手順

リカバリー手順は、復旧と再発防止を両立させる。復旧の最短ルートは、正しいバージョンへのロールバックや、誤った対応を無効化して正しい対応を再適用することになる。

その際、下流で既に保存されたデータの再計算が必要かどうかを判断する。必要であれば、再処理の対象期間、再計算の方法、検証手順（サンプル照合や集計一致）を事前に準備する。再処理はコストが大きくなりうるため、影響範囲が明確であるほど効率的に進む。

再発防止としては、品質検証のルール強化、入力正規化の追加、データ制約（型・範囲・一意性）の適用などが中心になる。誤対応が人の確認不足由来なら、手順のチェックポイントを見直すことも重要である。

応用と実例

コード体系の対応

コード体系の対応は、異なる管理体系間で同等性を持つコードを結びつける代表例である。たとえば、外部機関が定める区分コードと、社内で用いる分類コードの間を接続することで、連携データの解釈を統一できる。

設計上は、コードの桁や先頭ゼロの扱いが重要になる。文字列として保持し、変換の結果も同じ形式に揃えると、整合性が保ちやすい。さらに、有効期間があるコード改定では、いつの規則が適用されるかを行単位の情報として持たせると運用が安定する。

品質面では、参照不能コードの発生率を監視することで、データ受け入れ時の問題を早期に検知できる。

異なる表記ゆれの統合

表記ゆれの統合では、同じ対象を示す値が複数の書き方で存在する状況を扱う。例として、全角半角、記号の有無、スペース有無、表記順の違いなどがある。対応表だけで完全に解決できない場合もあるが、一定の範囲では吸収できる。

統合戦略としては、入力を正規化してから対応表を引く方法と、対応表側に揺れパターンを列挙する方法がある。前者は保守が比較的軽い一方で、正規化ルールの設計が必要になる。後者は対応漏れが起きやすいが、既知パターンを確実に吸収しやすい。

どちらの場合でも「同一視の基準」を明文化し、問い合わせ時にどのルールにより統合されたかを説明できる状態にしておくと、運用上の納得感が高まる。

業務システムでの活用

入力値の標準化

入力値の標準化では、利用者や外部連携から受け取った値を、内部で一貫した形式に直す。対応表は、入力コードから標準コードへ変換する中核として使われることが多い。

標準化の流れは、まず受け取り値の前処理（空白の除去、大小調整など）を行い、次に主キーで対応表を引く。該当がない場合は入力エラーとして扱うのか、代替候補を提示するのか、保留扱いにするのかを仕様で決める。

この標準化は、後工程の計算や集計の再現性を高める。入力のバラつきがなくなることで、集計結果が安定し、監査の説明もしやすくなる。

出力形式の変換

出力形式の変換では、内部の標準表現を、外部仕様や利用画面に合わせた表記へ直す。ここでは対応表が参照の役割を担い、内部値から外部のラベル、略称、表示単位などを取得する。

出力では、欠損時の表示方針も重要である。たとえば「該当なし」を空欄にするのか、「未設定」として文言を出すのか、「未登録コード」としてコード自体を残すのかを統一する必要がある。対応表の参照先列に表示用ラベルを含める設計も可能だが、更新時の影響が広がるため、運用方針に合わせて判断する。

また、フォーマット（桁数、区切り、丸め）を対応表で扱うか、別の出力層で行うかを分離すると、責務が明確になりやすい。

注意点と落とし穴

規模拡大による保守負荷

対応表が大きくなると、更新や検証のコストが線形以上に増えることがある。行数増加に伴い、データ品質のチェックも時間がかかり、変更の影響範囲を見積もる作業が重くなるためである。

保守負荷を抑えるには、列の役割を明確にし、補助情報を必要最小限にすることが有効である。また、有効期間や優先順位などの複雑要素を扱う場合は、表を分割するか、正規化して別の関連表で管理する設計が役に立つ。

さらに、更新頻度の高い部分と低い部分を分けて管理することで、変更のたびに全体を再検証する負担を軽減できる。

暗黙の前提の混入

暗黙の前提が混入すると、対応表が「それっぽく動くが正しくない」状態になりやすい。たとえば、特定の入力値しか来ないという前提、特定の表記が必ず正規化されているという前提、欠損が起きないという前提などである。

これらは、運用が拡大したときに突然破られ、誤対応や例外処理の増加につながる。対処としては、入力条件を仕様に落とし込み、例外ケースを含めたテストを用意することが重要である。加えて、データ制約（許容値、型、範囲）を可能な範囲で設け、表単体でも不正を検出できるようにすると、前提依存の事故が減る。

対応表は「ルールの実装」であるため、暗黙を減らし、必要な判断を表の構造や検証に反映させることが品質につながる。