マスタ（マスターデータ）とは？トランザクションデータとの違いと管理・MDMの進め方

マスタ（マスターデータ）は、顧客・商品・取引先など、業務で繰り返し参照する対象の基本情報をまとめたデータです。受注や請求を処理するシステムの多くは、必要な情報を事前にマスタへ登録しておくことを前提にしています（SAPのワンタイム顧客のように、相手ごとのマスタを作らず伝票側に入力させる仕組みもあります）。この記事では、トランザクションデータとの違いという定義から始めて、代表的なマスタの種類、コードの設計、マスタ管理（MDM）の進め方までを整理します。あわせて、社内採番のコードだけでマスタを設計すると後から効いてくる問題を、国税庁やGS1 Japanの一次情報にあたって解説します。

まとめ：マスタは業務の前提として先に登録しておく基準データ

結論から整理します。マスタとは、取引や活動の前提として先に登録しておき、繰り返し参照される基準データのことです。これに対してトランザクションデータは、発生の都度に記録される活動そのもののデータを指します。顧客マスタ・商品マスタがマスタで、受注明細・入出庫履歴がトランザクションです。

実務で押さえておきたい要点は次の4つです。

• マスタとトランザクションを分ける基準は、何を表すデータか（業務対象の基本情報か、出来事の記録か）であって、更新頻度やテーブル名、システムの種類ではない。
• マスタのコードは社内採番だけで設計せず、法人番号やGTIN（JANコード）など外部の標準コードを併せて持たせると、後の名寄せと外部連携が楽になる。
• ただし外部の標準コードも不変ではない。GTINには変更が必要になる10の基準があり、GS1事業者コードには有効期限がある。マスタ側に「いつ変わりうるか」の想定が要る。
• MDMという略語には、マスタデータ管理（Master Data Management）とモバイルデバイス管理（Mobile Device Management）の2つがある。社内の資料や見積書では必ずどちらか明示する。

マスタ（マスターデータ）の定義と関連用語の違い

マスタは、日本語の現場では「マスタ」「マスター」「マスタデータ」「マスターデータ」と表記が揺れますが、指しているものは同じです。英語のmaster dataに由来し、複数の業務やシステムから共通して参照される基準データを指します。

トランザクションデータとの違い

両者の違いは、更新の頻度ではなく「何を表しているか」で判断します。マスタは実体（誰・何・どこ）を表し、トランザクションは出来事（いつ、何が起きたか）を表します。顧客の住所が毎月変わることもあれば、年に一度しか売れない商品もあるため、更新頻度だけを基準にすると判定を誤ります。

最後の行が、マスタ管理に手をかける理由そのものです。トランザクションの誤りも後続処理に波及しますが、商品マスタの分類コードの誤りは、それを参照する複数の取引に広がります。集計処理そのものが正しくても、分類別の売上や取引先別の残高を正確に把握できなくなります。なお過去の集計への影響は、取引時点の属性を伝票側に保存しているかどうかで変わります。分析基盤を作る前提としても、ここが崩れていると先に進めません（データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説）。

マスタ・マスタテーブル・マスタ管理の使い分け

近い言葉が並ぶので、指すものを分けておきます。

• マスタ（マスターデータ）…データそのもの。「顧客マスタが古い」と言うときはデータの中身を指しています。
• マスタテーブル…そのデータを格納しているデータベース上の表。実装の話です。1つのマスタが複数テーブルに分かれることも、逆に1テーブルに複数のマスタが同居することもあります。
• マスタ登録・マスタメンテナンス（マスタメンテ）…マスタに新しいレコードを追加したり、属性を修正したりする日常の運用作業。
• マスタ管理・マスタ整備…上の運用作業に加えて、コード体系の設計、正とするシステムの決定、承認ルールの整備までを含む取り組み全体。

MDMの意味：マスタデータ管理とモバイルデバイス管理

マスタ管理を調べると必ずMDMという略語が出てきますが、IT分野ではこの3文字に別々の意味が2つ割り当てられています。

• Master Data Management…この記事で扱うマスタデータ管理。全社で参照されるマスタを整合させる取り組みとその基盤を指します。
• Mobile Device Management…業務用のスマートフォンやタブレットを管理する仕組み。情報システム部門が端末のキッティングや紛失時の遠隔ロックに使うものです（MDMとは？モバイルデバイス管理の仕組みとEMM/UEMの違い・選び方【情シス向け】）。

検索結果でも見積書でも、この2つは同じ「MDM」として並びます。社内で稟議を回すときは、初出で正式名称を添えてください。

代表的なマスタの種類と、そこに持たせる項目

企業で扱うマスタは業種によって増減しますが、基幹業務で共通して現れるのは次の6種類です。

組織・拠点マスタに有効期間を挙げているのは意図的です。組織改編がある場合、現在の組織情報だけでは過去の所属を再現できないことがあります。改編前後を比較するなら、当時の組織情報や新旧組織の対応関係も保存します。マスタの属性には、いつからいつまで有効かを持たせるかどうかという設計判断が常に付いて回ります。

マスタのコード設計：社内コードと外部標準コードの併用

マスタの主キーに社内で採番した独自コードを使う場合も、それとは別に、外部で公的に採番されている標準コードを属性として持たせておくかどうかで、後の名寄せ・突合・外部連携の難易度が変わります。

取引先マスタ：法人番号とインボイス登録番号

国内法人の名寄せキーとして使えるのが、国税庁が指定する法人番号です。国税庁法人番号公表サイトによれば、同サイトで検索できるのは「基本3情報」で、これは「1.商号又は名称、2.本店又は主たる事務所の所在地、3.法人番号」を指します。法人番号は13桁の半角数字です。社名の表記揺れに左右されない識別子なので、「株式会社ABC」と「（株）ABC」が同一法人かどうかを機械的に判定できます。

取得手段は3つあり、使い分けが必要です。

Web-APIについて、同サイトは「Web-APIのアーキテクチャスタイルは、REST方式です」と記載し、Ver.1.0からVer.4.0までのバージョンごとに提供機能を分けています。Ver.2.0で商号・所在地の英語表記、Ver.3.0で商号のフリガナ表記、Ver.4.0で検索対象除外法人の情報が、それぞれ下位バージョンのデータ項目に加えて取得できます。

導入時に見落としやすいのが、次の2点です。

• アプリケーションIDが必要で、発行までに時間がかかる。同サイトは「アプリケーションIDの発行に費用は掛かりません」としつつ、「アプリケーションIDの発行に２週間から１か月程度要します」と明記しています。開発スケジュールの初期に申請しておく種類の手続きです。
• Web-APIでは全件を取れない。同サイトは「Web-API機能では全件データを取得することはできません」と注記しています。全国の法人情報を一括取得する初期整備には基本3情報ダウンロードを使います。自社の取引先だけを照会する場合は、件数や処理頻度に応じてWeb-APIも選べます。

もう1つ、取引先マスタの陳腐化を検知する用途でも使えます。公表サイトの検索条件には「公表以後の変更履歴を検索対象に含める」「登記記録の閉鎖等が生じた法人を検索対象に含める」という指定があり、商号変更や登記記録の閉鎖が起きた法人を抽出できます。取引先マスタを手で棚卸しする代わりに、法人番号をキーにした差分照合で「名称が変わった取引先」「登記が閉鎖された取引先」を機械的に洗い出す設計が取れます。

インボイス制度の登録番号も取引先マスタの項目になりますが、ここには落とし穴があります。国税庁インボイス制度適格請求書発行事業者公表サイトは登録番号の構成を次のように説明しています。法人番号を有する課税事業者は「T」（ローマ字）＋法人番号（数字13桁）。それ以外の課税事業者（個人事業者、人格のない社団等）は「T」（ローマ字）＋数字13桁で、この13桁について「マイナンバー（個人番号）は用いず、法人番号とも重複しない事業者ごとの番号になります」と注記されています。

つまり登録済みの法人であれば登録番号の文字列は法人番号から組み立てられるが、それだけでは登録の有無を確認できず、個人事業者等の登録番号は組み立てること自体ができないということです。「法人番号さえ持てば登録番号は計算で出せる」という設計は、この2点で破綻します。登録番号は独立した項目として持たせ、値は公表サイト側で確認してください。なお同サイトの検索は「一度に10件まで検索することができます」とされており、大量照合にはWeb-APIか公表情報ダウンロードを使います。

商品マスタ：GTIN（JANコード）とGS1事業者コード

商品マスタ側の標準コードがGTIN（JANコード）です。GS1 Japan（一般財団法人流通システム開発センター）は、GTIN（Global Trade Item Number）を「どの事業者の、どの商品か」を表す国際標準の商品識別コードと説明し、日本国内ではJANコード（Japanese Article Number）とも呼ばれるとしています。

構成は次のとおりです。GS1事業者コードは国際的にはGS1 Company Prefixと呼ばれ、GS1 Japanは「45」または「49」で始まる9桁、10桁または7桁の番号を貸与しています。標準タイプのGTINは13桁で、GS1事業者コード（9桁、10桁または7桁）、商品アイテムコード（3桁、2桁または5桁）、チェックデジット（1桁）で構成されます。短縮タイプは8桁で、GTIN-8ワンオフキーと短縮タイプ6桁事業者コードによる2種類があります。

商品マスタの設計で効いてくるのは事業者コードの桁数が事業者によって違う点です。13桁という全体の長さは共通でも、どこまでが事業者でどこからが商品アイテムかは相手によって変わります。GTINの先頭n桁を切り出して取引先を判定するような実装は、相手の事業者コードが7桁か9桁か10桁かで壊れます。

外部コードの変更条件・利用期限と関連属性の更新

外部の標準コードを管理するときは、コード自体の変更条件、利用を継続するための手続き、紐づく属性の更新を分けて確認します。

1つ目はGTINそのものが変わる場合です。GS1は「GTINが変更になる10の基準」を公開しており、新商品の発売（基準1）、商品表示の変更をともなう成分や機能の変更（基準2）、商品表示の変更をともなう正味内容量の変更（基準3）、包装の外寸または総重量の変更程度が20%を超える場合（基準4）、認証マークの追加・削除（基準5）、ブランドの変更（基準6）などが該当します。販促のための期間限定の包装変更や景品・試供品の添付（基準7）は、単品・最小取引単位では変更なしですが、集合包装では新しいGTINが必要という具合に、粒度によって扱いが分かれます。商品マスタで「いつ新しいコードを採番し、いつ既存コードを使い続けるか」の社内ルールは、この10の基準に合わせて決めるのが出発点になります。

2つ目はGS1事業者コードの有効期限です。GS1 Japanは「有効期限後も継続して利用する場合は更新手続きが必要です」とし、有効期限の約1〜2か月前に更新申請書が管理担当者宛てに郵送されると案内しています。更新申請料は貸与を受けているコード数・事業者全体の年間売上高・支払年数の組み合わせで決まり、標準タイプの1登録単位・1年払いでは年間売上高1億円未満の区分で6,050円、5000億円以上の区分で110,000円（いずれも消費税10%込）です。自社が供給者側である場合、この更新は商品マスタの前提が切れるかどうかの話なので、担当者の異動で郵便が届かなくなる事態を避ける必要があります。

3つ目はコードに紐づく属性の変化です。公表サイトが商号・所在地の変更履歴と登記記録の閉鎖等を検索条件に持つのは、法人番号という識別子が変わらなくても、それに紐づく名称や所在地は変わるからです。

マスタ不備による取引・集計・連携への影響

マスタの不備は、単一システム内でも誤った請求や集計として表れます。システム間の突き合わせでは、表記揺れや更新時点の違いも問題になります。現場で頻出するのは次の4パターンです。

表記揺れと重複登録。同じ取引先が「株式会社」と「（株）」、全角と半角、旧社名と新社名で別レコードになると、取引履歴が分断されます。与信枠を相手ごとに管理しているなら、実質的な与信超過が見えなくなります。前述の法人番号を持たせておくと、この判定を表記に依存せず行えます。

コードの欠損による集計からの脱落。連携先のマスタに存在しないコードを含むトランザクションは、突合処理で弾かれるか、不明区分に寄せられます。弾かれた側がエラーとして見えていれば気づけますが、不明区分に黙って寄せられていると、合計は合っているのに内訳だけが狂うという最も見つけにくい壊れ方をします。システム間の残高や件数を定期的に突き合わせる仕組みが要ります（リコンサイルとは？会計・金融・ITで異なる意味と照合実務）。

更新タイミングのずれ。基幹側で商品マスタを更新しても、在庫管理やECへの反映が夜間バッチなら、その間に発生したトランザクションは旧い前提で処理されます。これはマスタの中身の誤りではなく連携方式の問題なので、マスタを直しても解決しません。どの方式で配るかを設計し直す必要があります（ERP連携とは？連携先別の設計とAPI上限から決める方式選定・失敗条件、データ連携の事例：6つの型と業種別の制約・効果指標の置き方）。

採番ルールの例外増殖。事業の拡大に伴って既存の体系に収まらない商品が出ると、臨時コードが付与されます。この臨時コードが恒久化すると、コードから商品の属性を読み取る運用（先頭2桁がカテゴリ、など）が成立しなくなります。コードに意味を持たせる設計は、意味が変わった瞬間に破綻するため、分類は属性列として別に持ち、コード自体は意味を持たない連番にしておくほうが長持ちします。

マスタ管理（MDM）の進め方

対象マスタや責任者を決めずにツールを選ぶと、必要な機能や承認経路を確定できません。決めるべきことの順番は、正とする場所、責任者と承認フロー、そのあとに実装手段です。

マスタ統合方式と正とするデータの所在

ここでは、既存システムの更新経路と正とするデータの所在に着目し、参照統合型・統合ハブ型・共存型を比較します。

参照統合型は、各システムのマスタはそのままに、どのレコードが同一かの対応表だけを別に持ちます。改修は小さい代わりに、入力時点の重複は防げません。統合ハブ型は新設した基盤を唯一の正として各システムへ配信するため効果は大きい一方、全システムの登録経路を変える必要があります。どこまでの改修を許容できるかを先に決めないと、ツール比較は意味を持ちません。

マスタ管理の責任者と登録・変更・廃止の承認フロー

項目の定義や変更の可否を決める責任者が不明だと、部門ごとに異なる基準でマスタが更新されます。マスタごとに、項目の定義を決める責任者（データオーナー）を1人置きます。複数部門が使う商品マスタであれば、販売・在庫・会計の各部門が使う項目それぞれについて、誰の定義が優先するかまで決めます。

登録・変更・廃止の申請には、少なくとも次を確認する経路を通します。

• 重複がないか（外部の標準コードを持っていれば、ここで機械判定できる）
• 採番ルールに沿っているか
• 後工程（会計・在庫・EC）で必須になる項目が埋まっているか
• 廃止する場合、そのコードを参照している未完了のトランザクションがないか

変更履歴を残すことは、内部統制の観点でも要件になります。上場企業の内部統制報告制度（J-SOX）ではIT全般統制の整備が求められ、財務報告に直結する単価マスタや取引先マスタについては、いつ・誰が・何を変更したかを追跡できる状態が前提になります。監査対応の記録を後付けするのではなく、承認フローの副産物として履歴が残る設計にしておくほうが安く済みます。

MDMツール選定前の対象範囲・連携方式・名寄せ体制

MDMツールの比較に入る前に、自社の状況を次の観点で確認しておくと、必要な機能の範囲が絞れます。

• 対象マスタは何か。取引先だけなら、法人番号を軸にした名寄せで足りる場合があります。
• 既存システムとの連携方式。APIで受けられるのか、ファイル連携しかないのかで実装量が変わります。
• 名寄せの判定を誰が確認するか。類似度スコアが閾値以上なら同一と判定する方式では、閾値を下げると誤統合のリスクが、上げると重複を見逃すリスクが高まります。人が確認する画面と体制が要ります。
• どの項目を管理対象にするか。まずシステム間で共有される項目を対象にし、財務報告や法令対応に関わる項目も、その影響に応じて管理対象に含めます。

なお、どのマスタがどこにあり誰が使っているかを可視化するところから始めたい場合は、マスタ統合そのものより先にメタデータの整理が要ります（データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説）。

よくある質問

マスタとトランザクションの違いを一言で言うと？

マスタは実体（誰・何・どこ）を表す基準データ、トランザクションは出来事（いつ何が起きたか）を表す記録です。更新頻度の多寡ではなく、表しているものが実体か出来事かで判断します。

マスタとマスタテーブルは同じ意味ですか？

厳密には違います。マスタはデータの内容を、マスタテーブルはそれを格納するデータベース上の表を指します。1つのマスタが複数のテーブルに分かれて実装されることもあるため、設計を議論するときは区別して話したほうが誤解が減ります。

MDMツールを入れず、エクセルでマスタを管理してはいけませんか？

参照するシステムと登録担当者がそれぞれ1つ・1人で、件数や変更頻度が少なく、入力チェックやバックアップを運用できるなら、エクセルで管理する選択肢もあります。問題が出るのは、同じマスタを複数のシステムと複数の担当者が更新し始めたときです。判断の目安は、シートを更新したあと他のシステムへ手で反映する作業が発生しているかどうかです。発生しているなら、その反映が漏れた日がマスタのずれの始まりになります。

マスタ整備はどのマスタから着手すべきですか？

参照しているシステムの数が多いものからです。多くの企業では取引先マスタか商品マスタが該当します。参照元が多いほど、ずれたときの影響範囲が広く、直したときの効果も大きくなります。

法人番号を取引先マスタのキーにしてよいですか？

名寄せ用の識別子として持たせるのは有効ですが、主キーそのものにするのは慎重に判断してください。個人事業主や、日本の法人番号を指定されていない海外法人を扱う場合は、法人番号が入らないレコードが生じます。社内採番のコードを主キーにしたうえで、法人番号を一意性のある属性として持たせる形が扱いやすい設計です。

インボイスの登録番号は法人番号から作れますか？

法人番号を有し、適格請求書発行事業者として登録済みの事業者では、登録番号は「T」＋法人番号（数字13桁）です。ただし、この文字列を組み立てただけでは、その事業者が実際に登録されているかは確認できません。また個人事業者や人格のない社団等の登録番号は、国税庁が「マイナンバー（個人番号）は用いず、法人番号とも重複しない事業者ごとの番号」と説明しているとおり別の番号です。導出できない相手がいる前提で、登録番号は独立した項目として持たせてください。

関連記事

• ERP連携とは？連携先別の設計とAPI上限から決める方式選定・失敗条件
• データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説
• データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説
• データ連携の事例：6つの型と業種別の制約・効果指標の置き方
• MDMとは？モバイルデバイス管理の仕組みとEMM/UEMの違い・選び方【情シス向け】