入力コンポーネント仕様
年始調整フォームのドメイン特化入力コンポーネント仕様を定義する。全コンポーネントは ADR-006 で決定した Roselli パターン（単一テキストフィールド + <output> 確認表示）を採用している。
→ 設計判断の背景: ADR-006 Roselliパターンによるドメイン特化入力コンポーネント
日付入力コンポーネント
年始調整では生年月日・契約日・異動日など多数の日付入力が発生する。既知の日付（ユーザーが把握している値）の入力に特化したコンポーネントを設計する。
設計方針: Roselliパターンの採用
単一テキストフィールド + <output> 確認表示（Adrian Roselliパターン）を採用する。
採用理由:
- 和暦ショートハンド対応: 日本のユーザーは「令和6年2月24日 = r60224」のように和暦で記憶していることが多い。単一フィールドなら西暦・和暦どちらでも入力可能
- 多言語対応: 7言語で日付フォーマットが異なる（MDY/DMY/YMD）。分割フィールド方式ではラベル順の変更が必要だが、単一フィールド + ロケール別確認表示なら言語切替に自然に対応
- パワーユーザー効率: 税務担当者は大量の日付を入力する。8桁連続入力（
20240224）が最も高速 - アクセシビリティ:
<output>はネイティブライブリージョン（role="status"）であり、追加のARIA設定なしにスクリーンリーダーが確認表示を自動読み上げ
入力仕様
フィールド属性:
<input type="text">: ブラウザのネイティブ日付ピッカーを回避inputmode="text": 和暦プレフィックス（r,h等のアルファベット）を含むためnumericは不可- プレースホルダー不使用（デジタル庁デザインシステム方針準拠）
- フォーマットヒントはフィールド外に配置し、
aria-describedbyで紐づけ
受け付ける入力パターン:
| パターン | 入力例 | 解釈 |
|---|---|---|
| 西暦8桁 | 20240224 | 2024年2月24日 |
| 西暦区切り文字あり | 2024/02/24, 2024-02-24, 2024.2.24 | 2024年2月24日 |
| 和暦ショートハンド | r60224 | 令和6年2月24日 |
| 和暦区切り文字あり | r6/02/24, r6-2-24, r6.2.24 | 令和6年2月24日 |
和暦プレフィックス:
| プレフィックス | 元号 | 期間 |
|---|---|---|
r | 令和 | 2019年5月1日〜 |
h | 平成 | 1989年1月8日〜2019年4月30日 |
s | 昭和 | 1926年12月25日〜1989年1月7日 |
t | 大正 | 1912年7月30日〜1926年12月24日 |
m | 明治 | 1868年1月25日〜1912年7月29日 |
正規化ルール（デジタル庁デザインシステム準拠）:
- 全角数字 → 半角数字（
２０２４→2024） - 全角アルファベット → 半角小文字（
Ｒ→r） - 月日のゼロ埋め自動補完（
2024/2/4→2024/02/04） - 和暦プレフィックスは大文字小文字不問（
R6=r6）
確認表示（<output> 要素）
有効な日付が入力されると、<output> 要素にロケール対応の確認表示を行う。
ロケール別表示フォーマット:
| ロケール | 表示例 |
|---|---|
| ja（和暦） | 令和6年2月24日（土） |
| en | Saturday, February 24, 2024 |
| zh | 2024年2月24日 星期六 |
| pt | sábado, 24 de fevereiro de 2024 |
| es | sábado, 24 de febrero de 2024 |
| vi | Thứ Bảy, 24 tháng 2, 2024 |
| fil | Sabado, Pebrero 24, 2024 |
- 曜日を含める: 入力ミスの検出を助け、認知障害のあるユーザーへの追加的な確認手がかりとなる（→ AC-002 認知的アクセシビリティ）
生年月日コンテキストでの年齢表示:
日付入力フィールドが生年月日として使用される場合、確認表示に対象年度12月31日時点の満年齢を含める。
- 年齢計算は前日満了ルールを適用する（→ 年齢計算）
- 1月1日生まれ → 前年12月31日に加齢 → その年の年齢区分に反映
- 1月2日生まれ → 翌年1月1日に加齢 → その年は前の年齢のまま
- 表示例:
令和6年2月24日（土） 対象年度末時点: 35歳
年齢閾値ハイライト:
年齢が税務上の区分境界に近い場合（±1歳以内）、確認表示をハイライトし注意を促す:
| 閾値 | 意味 | 影響する控除 |
|---|---|---|
| 16歳 | 控除対象扶養親族の下限 | 扶養控除（38万円）の適用開始 |
| 19歳 | 特定扶養親族の下限 | 控除額が63万円に増額 |
| 23歳 | 特定扶養親族の上限 | 控除額が38万円に減少 |
| 70歳 | 老人扶養親族の下限 | 控除額が48万円/58万円に増額 |
→ 年齢区分の詳細: 扶養親族のカテゴリ
アクセシビリティ
- フォーマットヒント: フィールドの下にヒントテキスト（例:「西暦8桁 または 和暦（例: r60224）」）を配置し、
aria-describedbyで紐づけ <output>ライブリージョン:<output>は HTML仕様上role="status"を暗黙的に持つため、スクリーンリーダーが確認表示の変更を自動的に読み上げる。追加のaria-live設定は不要- エラー表示: 無効な日付の場合、
<output>にエラーメッセージを表示し、aria-describedbyでフィールドと関連付け - カレンダーピッカー不提供: 本コンポーネントが扱うのはユーザーが既に知っている日付（生年月日、証明書の日付等）であり、カレンダーから日付を探す必要がない。カレンダーピッカーはスクリーンリーダー操作が困難であり、キーボード操作のバリアになりうるため提供しない
→ 満たす要件: AC-009 フォームアクセシビリティ、AC-001 多言語対応、AC-006 スクリーンリーダー対応
不採用とした方式
| 方式 | 不採用理由 |
|---|---|
<input type="date"> | ブラウザ間で UI・動作が大きく異なる。和暦表示の制御不能。カスタマイズ性が低く、ロケール対応がブラウザ依存 |
| GOV.UK分割フィールド（年/月/日の3フィールド） | 和暦ショートハンド入力と相性が悪い（どのフィールドにプレフィックスを入力するか不明瞭）。多言語対応時にフィールド順（MDY/DMY/YMD）の変更が必要 |
マスク入力（____/__/__） | スクリーンリーダーでの読み上げが不自然。カーソル位置の制御が複雑。途中の桁を修正しづらい |
金額入力コンポーネント
年始調整では収入額・控除額・保険料など多数の金額入力が発生する。税務の文脈では金額を「万円」単位で語るのが一般的であり（「年収500万円」「58万円の壁」等）、円単位の入力ではゼロの桁数ミスが起きやすい。日付入力と同じRoselliパターン（単一フィールド + <output> 確認表示）を適用する。
入力仕様
フィールド属性:
<input type="text">: 万円ショートハンドを受け付けるためtype="number"は不可inputmode="decimal": 大半の入力は数字であるためモバイルでは数値キーボードを優先表示。万円ショートハンド使用時はキーボード切替で対応- プレースホルダー不使用（デジタル庁デザインシステム方針準拠）
受け付ける入力パターン:
| パターン | 入力例 | 解釈 |
|---|---|---|
| 円単位（連続数字） | 5000000 | 5,000,000円 |
| カンマ区切り | 5,000,000 | 5,000,000円 |
| 万円ショートハンド | 500万 | 5,000,000円 |
| 万円＋端数 | 123万4567 | 1,234,567円 |
| 万円（小数） | 123.4万 | 1,234,000円 |
| 全角数字 | ５００万 | 5,000,000円 |
正規化ルール:
- 全角数字 → 半角数字
- 全角「万」→ 半角変換後に万円ショートハンドとして解釈
- カンマの除去
- 「円」サフィックスの除去
- 負数は受け付けない（金額は0以上）
確認表示（<output> 要素）
有効な金額が入力されると、<output> 要素にフォーマット済みの確認表示を行う。
基本表示:
5,000,000円（500万円）円単位と万円単位の両方を表示し、桁数の認識ミスを防ぐ。
コンテキスト別の閾値表示:
金額フィールドの用途（配偶者の合計所得金額、扶養親族の合計所得金額、本人の合計所得金額等）に応じて、税務上の閾値との関係を確認表示に含める:
| コンテキスト | 表示例 |
|---|---|
| 配偶者の合計所得金額 | 580,000円（58万円）— 同一生計配偶者の合計所得金額の要件ちょうど |
| 配偶者の合計所得金額 | 600,000円（60万円）— 同一生計配偶者の合計所得金額の要件超過 |
| 扶養親族の合計所得金額 | 570,000円（57万円）— 控除対象扶養親族の合計所得金額の要件内 |
| 本人の合計所得金額 | 9,800,000円（980万円）— 配偶者控除の合計所得金額の制限まで残り20万円 |
| 閾値 | 意味 |
|---|---|
| 58万円（R7〜） | 扶養親族・同一生計配偶者の合計所得金額要件 |
| 95万円 | 源泉控除対象配偶者の合計所得金額上限 |
| 133万円 | 配偶者特別控除の合計所得金額上限 |
| 1,000万円 | 配偶者控除を受けられる本人の合計所得金額上限 |
| 2,500万円 | 基礎控除がゼロになる本人の合計所得金額 |
閾値の値は年度パラメータとして Tax Calculation Core が管理し、フロントエンドはAPIから取得する。フロントエンドに閾値をハードコードしない。
アクセシビリティ
- 日付入力コンポーネントと同じ
<output>ライブリージョンパターンを適用 - 閾値超過・閾値近接の警告は色だけでなくテキストでも伝達（→ AC-005）
→ 満たす要件: AC-009 フォームアクセシビリティ、AC-002 認知的アクセシビリティ
収入→所得変換表示
配偶者や扶養親族の所得を申告する際、ユーザーは「収入」（源泉徴収票の支払金額）を知っているが、控除判定に使う「所得」（収入から給与所得控除等を差し引いた金額）は知らないことが多い。本コンポーネントは収入を入力すると所得を自動計算して確認表示する。
設計方針: 収入→所得の単方向変換
収入を正（primary）、所得を従（derived）とする。逆方向（所得→収入）の入力は提供しない。
逆変換が不可能な理由:
- 別表第五の4,000円グルーピング（収入162.5万円超〜660万円以下）: NTAのルックアップテーブルは収入を4,000円単位のブラケットにグルーピングしてから所得を算出する。同一ブラケット内の複数の収入が同じ所得にマッピングされるため、所得から収入を一意に特定できない（最大3,999円の曖昧さ）
- 算式計算の1円未満切捨て（収入660万円超〜850万円以下）:
所得 = floor(収入 × 0.9 − 110万円)の切捨てにより、隣接する2つの収入が同じ所得にマッピングされるケースがある（最大1円の曖昧さ）
→ 給与所得控除の計算式: 給与所得 → 端数処理ルール: 年税額計算
この方針は TASHIKA の設計原則「属性（事実）をユーザーが入力し、判定はシステムが行う」に合致する。収入は事実であり、所得は導出値である。
対応する所得種類
| 所得種類 | 入力 | 変換方法 | 変数 |
|---|---|---|---|
| 給与所得 | 給与収入 | 給与所得控除の速算表 / 別表第五 | 収入金額のみ |
| 雑所得（公的年金等） | 年金収入 | 公的年金等控除の速算表 | 年齢（65歳未満/以上）、年金以外の合計所得金額 |
| 退職所得 | 退職金収入 | 退職所得控除（勤続年数ベース） | 勤続年数、役員区分、短期退職該当 |
→ 年金所得の3変数テーブル: 雑所得
確認表示（<output> 要素）
給与所得の場合:
[給与収入] 1,230,000円（123万円）
↓ 給与所得控除 650,000円
[給与所得] 580,000円（58万円）— 同一生計配偶者の合計所得金額の要件ちょうど- 変換過程（控除額）を明示し、ブラックボックスにしない
- 変換後の所得金額に対して、金額入力コンポーネントと同じ閾値表示を適用
年金所得の場合:
[年金収入] 1,580,000円（158万円） 65歳以上 / 年金以外の所得1,000万円以下
↓ 公的年金等控除 1,100,000円
[雑所得] 480,000円（48万円）— 同一生計配偶者の合計所得金額の要件内- 変換に影響する変数（年齢、他の所得区分）を明示表示
- 年齢はFamilyMemberの生年月日から自動計算（→ 年齢計算）
フォーム構成
配偶者控除等申告書では、紙の書式上「給与収入」と「給与所得」の2欄があるが、TASHIKA では:
- 入力フィールドは収入の1つのみ（金額入力コンポーネントを使用）
- 所得は
<output>に表示（ユーザーは入力不要） - e-Tax/eLTAX出力時は収入・所得の両方をデータとして生成
「収入がわからない」ケースへの導線:
| ケース | 対応 |
|---|---|
| 源泉徴収票を見ている | 「支払金額」欄の値を入力するようヒントテキストで案内 |
| 給与明細から概算 | 月額×12等の概算入力を受け付け、所得は自動計算 |
| 所得しか知らない（稀） | 金額入力コンポーネントで所得を直接入力可能。ただし収入欄は空欄とし、確認表示で「源泉徴収票で正確な収入金額をご確認ください」と案内 |
→ 満たす要件: AC-009 フォームアクセシビリティ、AC-002 認知的アクセシビリティ
送金記録入力コンポーネント
非居住者親族への送金記録を管理し、38万円判定をリアルタイムで支援するフォームコンポーネント。個別の日付・金額フィールドには上述の日付入力コンポーネント・金額入力コンポーネント（Roselliパターン）を活用する。
→ データモデル: DM-303 RemittanceRecord → ドメイン知識: 非居住者親族
設計方針
非居住者親族の扶養控除（30〜69歳の③-c区分）では、年間38万円以上の送金が控除適用の前提条件となる。従来の紙ベースでは送金記録を集めて手計算する必要があったが、TASHIKA では送金記録を逐次入力すると邦貨換算後の累計額をリアルタイム表示し、38万円到達状況を可視化する。
対象ユーザー: 非居住者親族を扶養控除の対象としたい従業員。特に③-c区分（30歳以上70歳未満で留学・障害者に該当しない親族）の場合に必須。
フォーム構成
各非居住者親族に対して、送金記録のリストを管理する:
[非居住者親族名: 〇〇さん（フィリピン在住）]
送金記録 #1
送金方法: [銀行送金 ▼]
送金日: [20250315 ] → 2025年3月15日（土）
通貨: [PHP ▼]
外貨金額: [50000 ] → ₱50,000
換算方法: [● TTM ○ 実支出額]
TTMレート:[2.65 ] → 1PHP = 2.65円
円換算額: 132,500円
証憑: [📎 送金明細書.pdf]
送金記録 #2
送金方法: [クレジットカード ▼]
送金日: [20250720 ] → 2025年7月20日（日）
通貨: [PHP ▼]
外貨金額: [30000 ] → ₱30,000
換算方法: [● TTM ○ 実引落額]
TTMレート:[2.70 ] → 1PHP = 2.70円
円換算額: 81,000円
証憑: [📎 カード利用明細.pdf]
[＋ 送金記録を追加]
──────────────────────────────
年間送金額合計: 213,500円 / 380,000円（56.2%）
⚠ 38万円に166,500円不足しています
──────────────────────────────送金記録の入力項目
| 項目 | フィールド型 | 説明 |
|---|---|---|
| 送金方法 | セレクト | 銀行送金 / クレジットカード / 電子決済手段（R6〜） |
| 送金日 | 日付入力コンポーネント | 銀行送金: 送金実行日、クレジットカード: カード利用日 |
| 通貨 | セレクト | ISO 4217通貨コード。JPY選択時は外貨金額・換算方法・TTMレートを非表示 |
| 外貨金額 | 金額入力コンポーネント | 外貨建ての送金額。通貨がJPYの場合は不要 |
| 換算方法 | ラジオボタン | 送金方法に応じて選択肢が変わる（下表参照） |
| TTMレート | テキスト入力 | 換算方法がTTMまたは一括換算の場合。手動入力 |
| 円換算額 | <output> 表示 | 外貨金額 × TTMレート、または実支出額。自動計算 |
| 手数料含む | チェックボックス | 38万円送金書類に手数料額の記載がある場合のみ |
| 手数料額 | 金額入力コンポーネント | 手数料含むがオンの場合に表示 |
| 証憑 | ファイルアップロード | 送金関係書類（送金明細書、カード利用明細書等） |
換算方法の選択肢（送金方法別）:
| 送金方法 | 選択肢 |
|---|---|
| 銀行送金 | TTM（送金日）/ 実支出額（円→外貨→即時送金）/ 一括換算（年最後の送金日TTM） |
| クレジットカード | TTM（カード利用日）/ 実引落額（円口座引落）/ 一括換算（年最後のカード利用日TTM） |
| 電子決済手段 | TTM（支払日）/ 実支出額 / 一括換算 |
一括換算モード
一括換算（例外②）を選択する場合、送金方法ごとに年最後の支払日のTTMレートで全記録を一括換算する。
動作:
- ある送金方法の1件でも「一括換算」を選択すると、同一送金方法の全記録が一括換算モードに切り替わる
- 基準日（その送金方法の年最後の支払日）を自動判定し、入力済みの送金記録から特定
- 通貨ごとに基準日のTTMレートを1つ入力すれば、同一通貨の全記録に適用
- 異なる通貨が混在する場合は、通貨ごとにTTMレートを入力
一括換算モード（銀行送金分）
基準日: 2025/11/15（年最後の銀行送金日）
通貨別TTMレート:
USD: [150.00] 円
PHP: [2.65 ] 円
換算結果:
USD送金 3件 合計 $2,000 × 150.00 = 300,000円
PHP送金 2件 合計 ₱50,000 × 2.65 = 132,500円
銀行送金分 小計: 432,500円送金方法の混在時: 銀行送金分とクレジットカード分はそれぞれ独立に換算方法を選択できる。一方が一括換算でも他方は原則（個別TTM）を選択可能。最終的な38万円判定は全送金方法の合算額で行う。
38万円判定の表示
送金記録の合計額に対して、38万円閾値との関係をリアルタイム表示する:
| 状態 | 表示 |
|---|---|
| 38万円未満 | ⚠ 38万円に{不足額}円不足しています |
| 38万円ちょうど | ✓ 38万円の要件を満たしています（ちょうど） |
| 38万円超 | ✓ 38万円の要件を満たしています（{超過額}円超過） |
- 閾値表示はテキスト + アイコンで伝達し、色だけに依存しない（→ AC-005）
- 38万円の閾値は Tax Calculation Core のAPIから取得（フロントエンドにハードコードしない）
- 合計額の
<output>はライブリージョンとして機能し、送金記録の追加・変更のたびにスクリーンリーダーが合計額を読み上げる
書類提出の簡略化表示
年間3回以上の送金がある場合、最初と最後の送金関係書類の提出で中間の全送金をカバーできる旨をガイダンス表示する。証憑のアップロード状況に応じて:
| 状態 | 表示 |
|---|---|
| 送金3回以上 & 最初/最後の証憑あり | ✓ 最初と最後の送金書類が揃っています。中間の{N}件は省略可能です |
| 送金3回以上 & 証憑不足 | ℹ 最初と最後の送金書類をアップロードすれば、中間の送金書類は省略できます |
| 送金2回以下 | 全件の証憑アップロードを案内 |
アクセシビリティ
- 送金記録リストは
<fieldset>+<legend>でグループ化し、親族名を<legend>に含める - 各送金記録は番号付きで識別可能（「送金記録 #1」「送金記録 #2」等）
- 記録の追加・削除時は
aria-live="polite"で変更を通知 - 合計額の
<output>はネイティブライブリージョンとして機能 - 通貨セレクトには通貨名と通貨コードの両方を表示（「フィリピンペソ (PHP)」）
→ 満たす要件: AC-009 フォームアクセシビリティ、AC-002 認知的アクセシビリティ