ADR-006: Roselliパターンによるドメイン特化入力コンポーネント

• ステータス: Accepted
• 日付: 2026-02-25
• 決定者: 開発チーム

コンテキスト

TASHIKAの年始調整フォームには、以下のドメイン特有の入力パターンが存在する:

1. 日付入力: 西暦（YYYYMMDD）と和暦ショートハンド（r60224等）の両方で入力される。7言語対応で日付フォーマットが異なる（MDY/DMY/YMD）
2. 金額入力: 円単位（5000000）と万円ショートハンド（500万円）の両方で語られる。税務上の閾値（58万円、95万円、123万円等）との関係がユーザーにとって重要
3. 収入→所得変換: ユーザーは「収入」を知っているが、控除判定に使う「所得」を知らない。従来は紙の申告書の裏面に印刷された変換表を手で引いていた

これらに共通する課題:

• ユーザーが知っている形式（和暦・万円・収入金額）とシステムが必要とする形式（西暦・円・所得金額）にギャップがある
• 入力ミスの発見が難しい（日付の曜日違い、金額の桁数ミス、収入と所得の混同）
• <input type="date"> や <input type="number"> 等のネイティブ入力はカスタマイズ性が低く、和暦・万円ショートハンドに対応できない
• 多言語対応（7言語）との両立が必要

決定

ドメイン特化入力（日付・金額・収入所得変換）に Roselliパターン（Adrian Roselli提唱の単一テキストフィールド + <output> 確認表示）を標準パターンとして採用する。

構成:

<label for="birth-date">生年月日</label>
<span id="birth-date-hint">西暦8桁 または 和暦（例: r60224）</span>
<input type="text" id="birth-date" aria-describedby="birth-date-hint" />
<output for="birth-date">令和6年2月24日（土）　対象年度末時点: 35歳</output>

適用対象:

コンポーネント	入力	<output> 確認表示
日付入力	西暦 / 和暦ショートハンド	ロケール対応フォーマット + 曜日。生年月日では年齢
金額入力	円 / 万円ショートハンド	フォーマット済み金額（円 + 万円）+ 閾値コンテキスト
収入所得変換	収入金額（金額入力コンポーネント）	収入 → 控除額 → 所得の変換過程 + 閾値コンテキスト

収入→所得変換は単方向（収入→所得のみ）とする。逆方向（所得→収入）の入力は提供しない。

理由

Roselliパターンの採用理由

• 入力と確認の分離: ユーザーは自分が知っている形式で入力し、システムがどう解釈したかを <output> で即座に確認できる。これは認知負荷の軽減に直結する（→ AC-002）
• ネイティブライブリージョン: <output> は HTML仕様上 role="status" を暗黙的に持つため、追加のARIA設定なしにスクリーンリーダーが確認表示の変更を自動読み上げする（→ AC-006）
• 柔軟な入力解析: <input type="text"> なのでブラウザのネイティブUI制約を受けず、和暦プレフィックスや万円ショートハンドを自由に解析できる
• 多言語対応: 確認表示をロケールに応じて変えるだけで、入力フィールド自体は言語非依存のまま
• パワーユーザー効率: 連続数字入力（20240224, 5000000）と可読性の高いショートハンド（r60224, 500万）を1つのフィールドで両立

収入→所得の単方向変換の理由

所得→収入の逆変換が数学的に一意でない:

• 別表第五の4,000円グルーピング（収入162.5万円超〜660万円以下）: 同一ブラケット内の複数の収入が同じ所得にマッピングされる（最大3,999円の曖昧さ）
• 算式計算の1円未満切捨て（収入660万円超〜850万円以下）: floor(収入 × 0.9 − 110万円) の切捨てにより、隣接する2つの収入が同一所得にマッピングされるケースがある

配偶者の収入として最も多い帯域（162.5万円超〜660万円以下）が最大の曖昧さを持つため、逆変換をUIとして提供すると不正確な収入金額が記録されるリスクがある。

さらに、TASHIKA の設計原則「属性（事実）をユーザーが入力し、判定はシステムが行う」に照らすと、収入は事実であり所得は導出値であるため、入力すべきは収入である。

却下した代替案

代替案	却下理由
ネイティブ入力型（type="date", type="number"）	ブラウザ間でUI・動作が異なる。和暦・万円ショートハンドに非対応。カスタマイズ性が低い
GOV.UK分割フィールド（日付を年/月/日の3フィールド）	和暦ショートハンドと相性が悪い。多言語対応時にフィールド順の変更が必要
マスク入力（____/__/__, ___,___,___）	スクリーンリーダーでの読み上げが不自然。途中の桁修正が困難
収入⇔所得の双方向変換	所得→収入の逆変換が数学的に一意でない（4,000円グルーピング、1円未満切捨て）。不正確な収入金額がデータに混入するリスク
所得のみの入力（収入フィールドなし）	紙の配偶者控除等申告書と乖離が大きい。e-Tax/eLTAXへの出力時に収入データが必要。ユーザーは収入の方を把握しているケースが大多数
カレンダーピッカー（日付入力）	本コンポーネントが扱うのは既知の日付（生年月日等）でありカレンダーから探す必要がない。スクリーンリーダー操作が困難でキーボードバリアになりうる

トレードオフ・リスク

• 万円ショートハンドの曖昧性: 123.4万 を 1,234,000円（千円未満切捨て）と解釈するが、ユーザーが 1,234,567円 を意図していた場合に端数が失われる。<output> の確認表示で気づける設計だが、確認を怠るリスクは残る
• inputmode の制約: 金額入力で inputmode="decimal" を使用するとモバイルでは数値キーボードが表示され、万円ショートハンド（「万」の入力）にはキーボード切替が必要。大半の入力が数字のみであることを考慮し、数値キーボード優先を選択した
• 学習コスト: 和暦ショートハンドや万円ショートハンドの存在をユーザーに知ってもらう必要がある。ヒントテキストで入力例を示すが、連続数字入力もそのまま使えるため、ショートハンドを知らなくても利用可能
• 年度依存の閾値: 閾値（58万円、95万円等）は税制改正で変動する。フロントエンドにハードコードせず、Tax Calculation Core のAPIから年度パラメータとして取得する設計とするが、API障害時の表示が課題
• 所得しか知らないケースへの対応: 稀ではあるが所得金額のみを把握しているユーザーには、金額入力コンポーネントで所得を直接入力し、収入欄を空欄のまま確認を促す導線が必要。この場合、e-Tax出力時に収入欄が空欄となる制約がある

結果

• 3つの入力コンポーネント仕様を追加（→ 入力コンポーネント仕様）
• AC-009（フォームアクセシビリティ）に <output> ライブリージョン要件を追加（→ AC-009）
• Tax Calculation Core のAPIに年度別閾値パラメータの取得エンドポイントが必要
• 給与所得控除の速算表 / 別表第五、公的年金等控除の速算表をTax Calculation Coreに実装し、フロントエンドから呼び出す構成とする（フロントエンドで計算ロジックを持たない）