はじめに
ひろゆき氏の「軽減税率の定数にゼロを入れる更新に半年掛かる仕様って、どういうアルゴリズムなの？」というSNS投稿が話題になりました。
外から見れば「定数1個書き換えるだけだろう」と感じるのは自然です。一方で、業界標準の仕様書（流通BMS）、ERPベンダーの設計解説、OSS POSのソースを実際に開いてみると、「税率の定数」と呼ぶには分散しすぎていて、「定数1個」モデルが当てはまるのは限定的なアーキテクチャだけ、という景色が見えます。
本記事では政府答弁書・国税庁通達・業界標準仕様書・OSS POSの実装を直接引きながら、POS／会計／EDI のどのレイヤーに税率がどう持たれているのか、技術仕様レベルで整理します。
結論を先に置きます。
| レイヤー | 税率の格納形態 | 「ゼロを入れる」作業 |
|---|---|---|
| POSハードウェア標準（UnifiedPOS / OPOS） | 含まれない（周辺機器ドライバ層） | 関与なし |
| POSアプリ層 | 税率コード参照 | 新コード追加 + 商品マスタ付け替え |
| 会計／ERP層 | 税率コード × 有効期間 で並列管理 | コード追加・申告区分・仕訳パターン整備 |
| 商品マスタ（流通BMS） | 商品ごとに税率属性 | 数十万SKUの税率／税区分再分類とEDI再配信 |
| 取引明細 | 販売時税率をスナップショットで固定 | 引退できない（過去伝票の返品処理に必要） |
1. そもそも「税率の定数」はどこにあるのか — 流通BMS 商品マスタ仕様
日本の小売・卸・メーカー間で商品データを交換する業界標準が、GS1 Japan（一般財団法人流通システム開発センター）が管轄する 流通ビジネスメッセージ標準（流通BMS） です。運用ガイドライン（商品マスタ編）第1.0.1版 PDF を直接開くと、商品マスタが項目グループに分かれていて、税率は「商品管理情報」グループに含まれる商品ごとの属性として定義されています。
該当箇所をPDFから抜き出します。
①消費税税率 ・・・ 消費税の税率%単位で、小数点以下2桁まで入れる。●消費税区分が課税は必須 例：5%の場合、5.00
②消費税区分 ・・・ 商品の消費税区分を下のコードリストから選択する。
コード 区分 説明 1 課税 消費税課税対象 2 免税 輸出取引や国際輸送など 3 非課税 土地、有価証券、商品券などの譲渡、預貯金の利子や社会保険医療など 4 不課税 国外での取引、寄付、出資に対する配当など
商品マスタの構造を擬似スキーマで書くとこうなります（流通BMSで定義された項目の一部を抜粋）。
-- 流通BMS 商品マスタ (グロサリ商材) の主要項目を擬似スキーマで再現
CREATE TABLE product_master (
-- 商品コード
gtin CHAR(14) NOT NULL, -- JAN/EAN/GTIN
-- 商品管理情報
consumption_tax_rate DECIMAL(5,2) NOT NULL, -- 例: 8.00 / 10.00 / 0.00
consumption_tax_kbn CHAR(1) NOT NULL, -- 1=課税, 2=免税, 3=非課税, 4=不課税
-- 価格情報
price_inc_tax_kbn CHAR(1) NOT NULL, -- 1=総額(税込), 2=本体(税抜)
unit_price DECIMAL(10,2) NOT NULL,
-- マスタ有効日
effective_from DATE NOT NULL,
effective_to DATE,
...
PRIMARY KEY (gtin, effective_from)
);
ここで重要なのは：
-
税率は商品マスタの1属性（
consumption_tax_rate）で、商品ごとに値を持つ。グローバルな単一定数ではない。 - 税区分コードは4区分が標準（課税／免税／非課税／不課税）で、「0%」を入れるとき、これを「1=課税」のまま税率0にするのか「2=免税」扱いにするのかで仕入税額控除の可否が分岐する。
- 本体総額区分（税込／税抜）とマスタ有効日（effective_from / effective_to）が組み合わさる。
- 流通BMS は 小売⇔卸・メーカー間で商品マスタをEDI交換する前提で書かれていて、メーカー→卸→小売の3者で商品マスタを同期する。
「定数を1個変える」と聞いて想像する作業と、「商品マスタの数十万行 × 税率／税区分／本体総額区分／有効期間 × 3者同期」では、見えている景色が違います。
2. 「8%」は2種類ある — 同じ数字でも別レコード
SCSK PROACTIVE「軽減税率制度とERP（第3回）会計システムのチェックポイント」 で解説されているとおり、会計システム上では「同じ8%」が2種類並列に管理されています。
| 税率コード | 期間 | 消費税 | 地方消費税 | 合計 |
|---|---|---|---|---|
| 旧税率8% | 2014/4/1 〜 2019/9/30 | 6.30% | 1.70% | 8.00% |
| 軽減税率8% | 2019/10/1 〜 | 6.24% | 1.76% | 8.00% |
| 標準税率10% | 2019/10/1 〜 | 7.80% | 2.20% | 10.00% |
数値はパッと見同じ8%でも、消費税と地方消費税の内訳が違うので、申告書の集計区分・地方税の分配・仕訳パターンが分岐します。混ぜると決算が合いません。
ERP上では税率コードを下記のような形で持つのが一般的です（スキーマは概念的な擬似コード）。
CREATE TABLE tax_rate_code (
tax_code VARCHAR(8) PRIMARY KEY,
display_rate DECIMAL(5,2), -- 表示用税率(%)
national_rate DECIMAL(5,4), -- 消費税率
local_rate DECIMAL(5,4), -- 地方消費税率
effective_from DATE,
effective_to DATE,
is_reduced BOOLEAN, -- 軽減対象フラグ
is_input_credit BOOLEAN, -- 仕入税額控除可否
filing_section VARCHAR(8), -- 申告書集計区分
rounding_rule VARCHAR(8) -- 端数処理 (FLOOR/CEIL/ROUND_HALF_UP)
);
INSERT INTO tax_rate_code VALUES
('STD_05', 5.00, 0.0400, 0.0100, '1997-04-01', '2014-03-31', FALSE, TRUE, ...),
('STD_08', 8.00, 0.0630, 0.0170, '2014-04-01', '2019-09-30', FALSE, TRUE, ...),
('STD_10', 10.00, 0.0780, 0.0220, '2019-10-01', NULL, FALSE, TRUE, ...),
('RED_08', 8.00, 0.0624, 0.0176, '2019-10-01', NULL, TRUE, TRUE, ...);
伝票日付に応じて参照する税率コードを自動切替するために、SCSK 記事も「2019年9月30日までの領収書を入力すると8%、10月1日以降は10%と初期表示される」という有効期間管理を推奨しています。
ここに食料品0%案を足すとどうなるか。新聞・定期購読は「ゼロの対象外で軽減8%維持」の方向で議論されているため、税率コードはこう増えます。
('STD_05', ...),
('STD_08', ...),
('STD_10', ...),
('RED_08', ...),
+ ('FOOD_00', 0.00, 0.0000, 0.0000, '2026-XX-XX', '2028-XX-XX', TRUE, TRUE, 'FOOD0', ...), -- 食料品0% (時限)
+ ('NWP_08', 8.00, 0.0624, 0.0176, '2019-10-01', NULL, TRUE, TRUE, 'NEWS8', ...); -- 新聞は8%維持
さらに「0%課税（免税）」と「非課税」の選び分けが乗ります。前者は仕入税額控除（仕入時に払った消費税の還付）が使えるが、後者は使えません。同じ「税率0%」でも仕訳と申告で行く先が違うため、別レコードになります。
国税庁 No.6371 端数計算 では適格請求書（インボイス）の端数処理は 税率ごとに1回と定められています。3〜4税率で並走する期間は、端数計算のロジックも税率ごとに分岐させて並列実装することになります。
3. 過去取引の返品で「現在の定数」は使えない — 取引明細にスナップショット
ここが個人的にいちばん「外からは見えない」と感じた部分です。OSS の Open Source POS（OSPOS）の Taxes wiki を読むと、商品ごとに Tax Category を割り当てておいて、販売完了時に税率を取引明細にロックする仕様であることが明記されています。
Once a tax has been calculated for a sale, the tax rate is locked in for that sale.
OSS に限らず、商用POS・基幹会計でも当たり前の設計です。スキーマで書くとこんな感じ。
CREATE TABLE sales_line (
sale_id BIGINT,
line_no INT,
gtin CHAR(14),
qty DECIMAL(10,3),
unit_price DECIMAL(10,2),
-- ↓ 販売時の税率を取引明細にロック（マスタを後から書き換えても影響しない）
applied_tax_code VARCHAR(8) NOT NULL,
applied_tax_rate DECIMAL(5,4) NOT NULL,
applied_at TIMESTAMP NOT NULL,
PRIMARY KEY (sale_id, line_no)
);
なぜそれが必要か。例えば 10% 時代に売った商品が改定後に返品されたら、返金額は10%基準で計算しなければ過剰返金になります。
そしてこれはまさに、衆議院 答弁第76号（高市内閣総理大臣、令和7年11月28日） が改修対象として挙げている内容と一致します。
消費税率の引下げ前に販売した商品が、消費税率の引下げ後に返品された場合の消費税額の計算等にも対応できることを確保しながら「ＰＯＳレジシステム」の改修を行う必要がある
この一文は、OSPOS や一般的な ERP がやっている取引時税率スナップショット参照そのものです。返品処理は sales_line.applied_tax_rate を参照してロジックを組むので、現在の税率マスタ（tax_rate_code）を書き換えただけでは過去取引の返品計算は動きません。
テスト会社 ヴェスの 2014年5%→8%変更時のリスクコラム も、税率マスタ更新の同時刻配信によるサーバ過負荷、深夜0時をまたぐ取引、改定前購入の返品処理など、実装で実際にトラブった現場を残しています。
つまり改定前後の数ヶ月〜決算をまたぐ期間、新旧の税率コードは並走稼働し、旧コードを引退させていいのは、それを参照する取引履歴がもう動かなくなった（決算が締まり、申告が終わり、返品保証期間も過ぎた）状態になってからです。
4. ハードウェア標準と業務ロジックは別レイヤー — UnifiedPOS / OPOS
POSハードウェア側にも標準仕様があります。Microsoft POS for .NET が準拠しているのが **UnifiedPOS（国際標準）**で、その前身に当たるのが **OPOS（OLE for Retail POS）**です。
これらは何かというと、レシートプリンタ・キャッシュドロワ・バーコードスキャナ・カスタマーディスプレイなどの周辺機器を抽象化するドライバ仕様です。Service Object（SO）というレイヤーで機器固有のプロトコルを隠蔽します。
┌──────────────────────────────────────────────────┐
│ 業務アプリ層（POSアプリ・基幹会計） │
│ - 税率コード参照、商品マスタ参照、 │
│ 計算経路、仕訳生成、申告区分 │
└────────────────┬─────────────────────────────────┘
│
┌────────────────▼─────────────────────────────────┐
│ POS for .NET / UnifiedPOS / OPOS │
│ - PosExplorer, Service Object (SO) │
│ - 機器カテゴリ (PosPrinter, CashDrawer, ...) │
└────────────────┬─────────────────────────────────┘
│
┌────────────────▼─────────────────────────────────┐
│ 周辺機器ファームウェア／ドライバ │
└──────────────────────────────────────────────────┘
「軽減税率の定数」は、この SO より上のアプリ層・基幹会計層の話で、UnifiedPOS の仕様書には税率の定数は出てきません。POSハードウェア標準と業務ロジックは設計上きれいに分離されているレイヤーで、「レジ端末のファームウェアにある単一の TAX_RATE = 0.08 のような定数を書き換えれば終わる」というモデルは、現代の小売POSアーキテクチャと合いません。
5. では、なぜスマレジは1〜2日で済むのか
産経新聞のスマレジ宮崎社長インタビュー では、同社の主力システムは「税率変更や非課税などの設定がすぐに行える」「最短1〜2日の対応が可能で、（スマレジであれば）大規模な改修は不要」と語られています。
ここまでの構造を踏まえると、これは矛盾していません。クラウド型POSは、商品マスタ・税率コードテーブル・取引明細を全部クラウド側のサーバで集中管理していて、配信先は汎用タブレットのアプリです。だから「税率コードの追加」「商品の税率コード付け替え」「有効期間設定」をクラウド管理画面で完結できる。
逆に大手ターミナル型POSは、店舗ごとにオンプレミスで稼働しているうえ、独自カスタマイズが入っていて、商品マスタも基幹会計も EDI 連携先も別システムで、それぞれの実機テストと配信が必要です。朝日新聞の取材記事「消費減税、レジ改修に『9カ月から1年』 業者が明かす長期化の理由」で大手ベンダーが、
システム改修に半年程度、それぞれの顧客へのシステムの実装に少なくとも3カ月ほどはかかり、POSの改修はレジ本体の対応にとどまらず、会計や発注など関連する周辺システムも合わせて見直す必要がある
と答えているとおりです。政府答弁書も、
税率に関して自由度の高いシステムを構築している事業者は比較的短期間で対応可能
とした一方で、そうでない事業者からは「全ての顧客でのシステム改修を終えるまでには相当な期間を有し、少なくとも一年は要すると見込む事業者も複数あった」と書き分けています。「全社1年」ではない、というのは政府自身が認めているところです。
6. 整理：レイヤー別の「軽減税率の定数にゼロを入れる」作業量
| レイヤー | 必要な作業 | 概ねの期間 |
|---|---|---|
| クラウドPOS単体 | 管理画面で税率コード追加・商品マスタの税区分付け替え・有効期間設定 | 1〜2日 |
| 会計パッケージ単体 | 税率コード追加とテスト、申告書集計区分の追加、仕訳パターン整備 | 3〜4ヶ月 |
| 大手ターミナル型POS | 商品マスタ数十万SKUの税区分再分類と再配信、店舗オンプレ端末への安全配信、実機テスト | 9〜12ヶ月 |
| 連携先基幹系まで含む全体 | 流通BMS経由の商品マスタ同期（小売・卸・メーカー3者）、EDI受発注、在庫、ポイント、適格請求書の端数処理3系統分岐、過去取引と新規取引の並走運用、月次・年次決算検証 | 1年〜 |
期間の出典は日経クロステック、衆議院 答弁第76号、産経新聞・朝日新聞の取材記事を統合しました。
ひろゆき氏の「仮にゼロだとエラー返すならエラーハンドリング直すだけでしょ」という指摘について、税率に「0」を入れたときに掛け算結果が「0」になって計算自体は通るので、ここはエラー系ではなく正常系の業務フロー全体が、税率コード追加に伴って棚卸しになる、というのが実装側の率直な感覚です。税率に依存する計算経路（割戻し計算、税抜から税込への逆算、丸め処理、申告区分集計など）を全部洗い出して回帰テストする時間が、改修工数の大半を占めます。
7. まとめ
- 「税率の定数」はグローバル変数ではなく、商品マスタの1属性として商品ごとに格納されている（流通BMS仕様書）。
- 「8%」は2種類の税率コードが並列で動いている（旧8%と軽減8%、内訳が違う）。「ゼロを入れる」は新コード追加・有効期間設定・仕訳パターン・申告区分の整備が一セット。
- 取引明細には販売時の税率がロックされている（OSPOS実装、政府答弁書、過去の改修事例で一致）。現在の税率マスタを書き換えても過去取引は連動しない。改定後は新旧コードが並走する。
- POSハードウェア標準（UnifiedPOS / OPOS）と業務ロジックは別レイヤー。「ファームウェアの定数を書き換えるだけ」というモデルは現代アーキテクチャと噛み合わない。
- クラウドPOS（スマレジ等）が1〜2日で済むのは事実。集中管理アーキテクチャの強み。日本の主力小売チャネルでターミナル型＋オンプレ基幹系の組み合わせが多いことが、業界全体としての「1年」の正体。
ひろゆき氏の問いは、技術的に整理すると「アーキテクチャ次第」という答えになります。クラウド型POSのような「定数1個」が成立する世界はちゃんと存在していて、それが日本の主力チャネルでまだ少ないだけ、というのが現状です。
参考文献（一次・準一次資料）
- 流通ビジネスメッセージ標準（流通BMS） GS1 Japan
- 流通BMS 運用ガイドライン（商品マスタ編）第1.0.1版 PDF
- SCSK PROACTIVE「軽減税率制度とERP（第3回）会計システムのチェックポイント」
- Open Source POS Taxes wiki (GitHub)
- Microsoft Learn POS for .NET アーキテクチャ
- 衆議院 答弁第76号（令和7年11月28日 高市内閣総理大臣）
- 国税庁 No.6371 端数計算
- 日経クロステック「非課税か0%か、異なる消費税ゼロ化」
- 産経新聞 スマレジ宮崎社長インタビュー
- VES「消費税8%設定変更、本当に不安なし？」（2014年改修事例）
タグ: 消費税 POS 軽減税率 流通BMS ERP