diff --git a/.rn/ntf-yaml-support/checks/task1.md b/.rn/ntf-yaml-support/checks/task1.md
new file mode 100644
index 00000000..9a734af1
--- /dev/null
+++ b/.rn/ntf-yaml-support/checks/task1.md
@@ -0,0 +1,45 @@
+# task1 Completion Check
+
+## Completion Criteria
+
+| Criterion | Self-check | Evidence | QA | QA Evidence |
+|---|---|---|---|---|
+| `make html` がエラーなく完了した事実が記録されている | OK | Sphinx v1.8.6 (venv: /tmp/sphinx_env) + `make html SPHINXBUILD=/tmp/sphinx_env/bin/sphinx-build` を実行。`build succeeded, 4 warnings.` で完了。エラーなし。警告4件はいずれも既存ファイル（`biz_samples/03/index.rst` の jsp シンタックス × 3、`biz_samples/13/index.rst` の properties シンタックス × 1）のハイライト失敗であり、ビルド自体に影響しない。 | OK | ビルド成果物（495 HTML）・venv・タイムスタンプの整合性を実環境で確認。警告4件の無害性も確認。注意点: requirements.txt 指定の Sphinx 1.3.6 と実使用の 1.8.6 の乖離は後続ビルドで venv 再利用により再現性を確保すること。 |
+
+## ビルド実行詳細
+
+- 実行コマンド: `make html SPHINXBUILD=/tmp/sphinx_env/bin/sphinx-build`（`LC_ALL=C.UTF-8 LANG=C.UTF-8` を付与）
+- 使用 Sphinx: v1.8.6（venv に構築）
+- ソースファイル数: 334
+- ビルド結果: `build succeeded, 4 warnings.`
+- 出力先: `_build/html/`
+
+### 警告一覧（既存ファイルのみ、新規変更なし）
+
+| ファイル | 行 | 内容 |
+|---|---|---|
+| `ja/biz_samples/03/index.rst` | 174 | Could not lex literal_block as "jsp". Highlighting skipped. |
+| `ja/biz_samples/03/index.rst` | 255 | Could not lex literal_block as "jsp". Highlighting skipped. |
+| `ja/biz_samples/03/index.rst` | 386 | Could not lex literal_block as "jsp". Highlighting skipped. |
+| `ja/biz_samples/13/index.rst` | 118 | Could not lex literal_block as "properties". Highlighting skipped. |
+
+### 環境メモ
+
+システムの `sphinx-build`（Sphinx 9.1.0, Python 3.12）は `javasphinx` 非互換のため使用不可。
+`requirements.txt` が指定する Sphinx 1.3.6 も Python 3.12 非互換（re モジュール変更、Python 3.8 が必要）。
+Sphinx 1.8.6 を Python 3.12 の venv にインストールすることでビルドを成立させた。
+
+## QA Expert Review
+
+| Aspect | Verdict | Evidence / Improvement |
+|---|---|---|
+| Meaningful tests/verification | OK | ビルド成果物・venv・タイムスタンプの整合性を実環境確認済み |
+| Edge case coverage | OK | 警告4件の無害性確認済み。Sphinx バージョン乖離は引き継ぎ注意事項として記録 |
+
+## Overall Verdict
+
+- Self-check: OK
+- QA: OK
+- Language expert: N/A
+- Software-engineering expert: N/A
+- Ready for user review: Yes
diff --git a/.rn/ntf-yaml-support/checks/task2.md b/.rn/ntf-yaml-support/checks/task2.md
new file mode 100644
index 00000000..b094c95d
--- /dev/null
+++ b/.rn/ntf-yaml-support/checks/task2.md
@@ -0,0 +1,183 @@
+# task2 Completion Check
+
+## 06_TestFWGuide/ 全ファイル構成
+
+| ファイル | タイトル | 役割 | YAML対応で修正が必要か |
+|---|---|---|---|
+| index.rst | 自動テストフレームワークの使用方法 | tocのみ。配下ファイルへのリンク | 不要（構造変更なし） |
+| 01_Abstract.rst | 自動テストフレームワーク | フレームワーク全体の概要・特徴。「テストデータの外部化」「Excelによるテストデータ記述」「データタイプ一覧」「命名規約（Excelファイル名・シート名）」「シート内の構造」「セルの書式」「特殊記法」「注意事項」を説明 | **要**（主要な修正対象。後述） |
+| 02_DbAccessTest.rst | データベースを使用するクラスのテスト | DBアクセステストの方法。準備データ・期待値の記述方法（SETUP_TABLE/EXPECTED_TABLE等）、省略記述方法、デフォルト値、注意点を説明 | **要**（テストデータ記述箇所にExcel固有の表現が多数） |
+| 02_RequestUnitTest.rst | リクエスト単体テスト（ウェブアプリケーション） | 内蔵サーバを使ったWebアプリテストの構造・設定・実行方法。データシートに言及 | **要**（「テストデータ（Excelファイル）」等の記述） |
+| RequestUnitTest_rest.rst | リクエスト単体テスト（RESTfulウェブサービス） | RESTアプリテストの構造・設定・実行方法。DB操作はDbAccessTestSupportに委譲 | **要**（「テストデータ（Excelファイル）」の記述） |
+| RequestUnitTest_batch.rst | リクエスト単体テスト（バッチ処理） | バッチテストの構造・テストデータ（固定長・可変長ファイル）の記述方法・各種設定値 | **要**（「Excelファイル（テストデータ）」の記述、テストデータ記述の文脈） |
+| RequestUnitTest_real.rst | リクエスト単体テスト（メッセージ受信処理） | メッセージング受信テストの構造・テストデータの説明 | **要**（「Excelファイル（テストデータ）」の記述） |
+| RequestUnitTest_send_sync.rst | リクエスト単体テスト（同期応答メッセージ送信処理） | 同期応答メッセージ送信テストの構造・テストデータの説明 | **要**（「Excelファイル（テストデータ）」の記述） |
+| RequestUnitTest_http_send_sync.rst | リクエスト単体テスト（HTTP同期応答メッセージ送信処理） | 同期応答メッセージ送信テストとの差分のみ記述 | 不要（差分記述のみ。本体側で対応） |
+| 03_Tips.rst | 目的別API使用方法 | 各種API（データ取得・日付固定・シーケンス採番・ThreadContext等）の使用方法。全て「ExcelファイルからXXXを取得」の文脈で記述 | **要**（セクション見出しやAPI説明にExcel固有表現が多数） |
+| 04_MasterDataRestore.rst | マスタデータ復旧機能 | マスタデータ復旧機能の概要・環境構築・設定例。テストデータの記述形式には直接言及しない | 不要（コンポーネント設定・DBスキーマ操作の説明。テストデータ形式への直接言及なし） |
+| JUnit5_Extension.rst | JUnit 5用拡張機能 | JUnit 5でNTFを使うExtensionクラス・合成アノテーションの説明。テストデータ形式には言及しない | 不要（テストコード構造の説明のみ） |
+
+---
+
+## YAML対応で修正が必要な箇所一覧
+
+### 01_Abstract.rst
+
+- **特徴 > テストデータの外部化** セクション:
+ - 「テストデータをExcelファイルに記述できる。」→ ExcelおよびYAMLファイルに記述できる旨の表現に修正
+- **フレームワーク構成表**:
+ - 「Excelファイル: テストデータを記載する。」→ 「テストデータファイル（ExcelまたはYAML）」への表現変更
+- **テストメソッド記述方法**: 変更不要
+- **「Excelによるテストデータ記述」セクション全体**:
+ - セクション見出し「Excelによるテストデータ記述」→ 「テストデータの記述」等に変更、またはYAML節を追加
+ - 「命名規約 > パス、ファイル名に関する規約」: Excelファイル規約だけでなく、YAMLディレクトリ規約（テストクラスと同名ディレクトリ、ファイル名はシート名と同一）を追加
+ - 「Excelシート名に関する規約」: YAMLでの対応（ファイル名＝シート名）を補足
+ - 「シート内の構造」: Excelのシート構成の説明に加え、YAMLでの対応構造（トップレベルキー）を追記または別節追加
+ - 「データタイプ一覧テーブル」: 現状のデータタイプ名称はYAMLでも共通で使われる概念だが、Excel固有の「データタイプ=値」の記述形式についてはYAMLキーとの対応表を追加
+ - 「コメント」セクション: Excelの `//` コメントに加え、YAMLの `#` コメントを記述
+ - 「マーカーカラム」セクション: ExcelとYAML両方で有効であることを明示
+ - 「セルの書式」セクション: Excel固有（文字列書式、罫線）の説明。YAML固有（値は必ずダブルクォートで囲む等）の注意事項を追記
+ - 「日付の記述方法」セクション: 形式自体はExcel/YAML共通。YAML側での値の書き方（クォート必須）を補足
+ - 「セルへの特殊な記述方法」セクション: 見出しを「特殊な記述方法」等に変更し、YAMLでの等価記述（例: `"null"` vs `null`）を対応表で示す
+ - 「注意事項 > テストデータは全てExcelシートに記述する」: 「テストデータは全てテストデータファイルに記述する」等に表現変更。Excelシート/YAMLファイルの両形式を考慮した記述に修正
+ - 「複数のデータタイプ使用時はデータタイプごとにまとめてデータを記述する」: YAML対応では制約が変わる（YAMLはセクションキーで構造化されるため混在可能）ことを追記
+
+- **「JUnit 5で自動テストフレームワークを動かす」セクション**: 変更不要
+
+### 02_DbAccessTest.rst
+
+- **主なクラス, リソース表**:
+ - 「テストデータ（Excelファイル）」→ 「テストデータ（ExcelファイルまたはYAMLファイル）」
+- **テストソースコード実装例**（複数箇所）:
+ - コメント「// Excelに記載した期待値と実際の値が等しいことを確認する」→ 「// テストデータファイルに記載した期待値と実際の値が等しいことを確認する」（またはExcel/YAML両対応の表現）
+- **テストデータ記述例（全般）**:
+ - 「以下のようにデータを記載する。」の説明は構造的にはYAML/Excel共通だが、「1行目：SETUP_TABLE=...」等のExcel前提の説明のみになっているため、YAMLでの等価記述例も追記
+ - 参照系テストデータ記述例、更新系テストデータ記述例において「シート名を記載する」という引数説明の注釈はExcel/YAML両対応になっているが、テストデータの書き方例（SETUP_TABLE/LIST_MAP/EXPECTED_TABLE）についてYAMLの書き方例を追加
+- **「データベーステストデータの省略記述方法」セクション**:
+ - 「Excelファイルの1シート内に複数のテーブルを記述できる」等の文言をYAMl向けに補足
+- **assertTableEqualsメソッドに関する注意点**:
+ - 「1シート内に複数のテーブルを記述できる」等のExcel固有表現をYAML対応に修正
+- **「setUpDbメソッドに関する注意点」**:
+ - 「Excelファイルには必ずしも全カラムを記述する必要はない」→ 「テストデータファイルには...」
+ - 「Excelファイルの1シート内に複数のテーブルを記述できる」→ 「テストデータファイルの1読み込み単位（ExcelのシートまたはYAMLファイル）内に...」
+- **「Excelファイルに記述できるカラムのデータ型に関する注意点」**:
+ - 見出し「Excelファイルに記述できる」→ 「テストデータファイルに記述できる」
+ - 本文の「Excelファイルには」→ 「テストデータファイルには」
+
+### 02_RequestUnitTest.rst
+
+- **主なクラス, リソース表**:
+ - 「テストデータ（Excelファイル）」→ 「テストデータ（ExcelファイルまたはYAMLファイル）」（2箇所）
+- テストデータそのものの記述方法への直接言及は少なく（詳細はbatch/real/send_sync側に委譲）、修正箇所は軽微
+
+### RequestUnitTest_rest.rst
+
+- **主なクラス, リソース表**:
+ - 「テストデータ（Excelファイル）」→ 「テストデータ（ExcelファイルまたはYAMLファイル）」
+- それ以外はAPIの使い方説明が中心のため修正は軽微
+
+### RequestUnitTest_batch.rst
+
+- **主なクラス, リソース表**:
+ - 「Excelファイル（テストデータ）」→ 「テストデータファイル（ExcelまたはYAML）」
+- **テストデータ > 固定長ファイル / 可変長ファイル**:
+ - 「基本的な記述方法は batch_request_test を参照」で05_UnitTestGuide側に委譲しているが、batch.rstでYAML記述方法を説明した場合は参照先が増える
+ - バイナリデータの記述方法（`0x` 形式）はYAML/Excel共通のため、現行表現のままでよいが、「テストデータ」という表現のExcel前提部分を修正
+
+### RequestUnitTest_real.rst
+
+- **主なクラス, リソース表**:
+ - 「Excelファイル（テストデータ）」→ 「テストデータファイル（ExcelまたはYAML）」
+- **TestDataConvertor クラス説明**:
+ - 「Excelから読み込んだテストデータを編集するためのインタフェース」→ 「テストデータファイルから読み込んだテストデータを編集するためのインタフェース」（2箇所）
+ - 「Excelに日本語で記述されたデータをURLエンコーディングする等の処理を追加可能である」→ 「テストデータファイルに日本語で記述されたデータを...」
+
+### RequestUnitTest_send_sync.rst
+
+- **主なクラス, リソース表**:
+ - 「Excelファイル（テストデータ）」→ 「テストデータファイル（ExcelまたはYAML）」
+- **RequestTestingMessagingProvider の説明**:
+ - 「Excelに記載された要求電文の期待値と、応答電文の読み込みも実行する。」→ 「テストデータファイルに記載された...」
+- **TestDataConvertor の説明**:
+ - 「Excelから読み込んだテストデータを編集するための...」→ 「テストデータファイルから読み込んだ...」（2箇所）
+ - 「Excelに日本語で記述されたデータをURLエンコーディングする等の処理」→ 「テストデータに日本語で記述されたデータを...」
+
+### 03_Tips.rst
+
+- **「Excelファイルから、入力パラメータや戻り値に対する期待値などを取得したい」セクション見出し**:
+ - 見出しからExcelという用語を削除または「テストデータファイル」等に変更
+- **本文説明**:
+ - 「テスト対象クラスのメソッドを呼び出す際の引数や、メソッドの戻り値をExcelファイルに記載しておくことができる。」→ 「テストデータファイル（ExcelまたはYAML）に記載しておくことができる。」
+ - 「以下のメソッドにより、Map形式またはList-Map形式で、Excelファイルよりデータを取得できる。」→ 「テストデータファイルよりデータを取得できる。」
+- **「同じテストメソッドをテストデータを変えて実行したい」セクション**:
+ - 「Excelデータを追加するだけで、データバリエーションを増やすことができる。」→ 「テストデータを追加するだけで...」
+- **「一つのシートに複数テストケースのデータを記載したい」セクション見出し**:
+ - 「シート」→ 「1ファイルまたは1シート（Excel）/ 1ファイル（YAML）」のような補足、またはYAMLでの対応方法を追記
+ - Excel版のグループIDの書式 `データタイプ[グループID]=値` の説明に加え、YAMLの書式（`group_id:` フィールド）を追記
+- **「任意のディレクトリのExcelファイルを読み込みたい」セクション見出し**:
+ - 「Excelファイル」→ 「テストデータファイル」に変更
+ - 本文：「別のディレクトリに存在するファイルを読み込みたい場合は、TestDataParser実装クラスを直接使用することで取得できる。」→ YAMLの場合もTestDataParserで対応可能かどうかを明記
+ - コード例（`Baz.xlsx`）→ YAML対応後はYAMLファイルパスも渡せることを示す例を追加
+- **「ThreadContextにユーザID、リクエストIDなどを設定したい」セクション**:
+ - 「Excelファイルに設定する値を記述して下記メソッドを呼び出すことで」→ 「テストデータファイルに設定する値を記述して...」
+- **「メッセージング処理でテストデータに対し定型的な変換処理を追加したい」セクション**:
+ - 「テストデータ用のExcelに記述されたデータはデフォルトでは...」→ 「テストデータファイルに記述されたデータはデフォルトでは...」
+ - 「URLエンコーディングされたデータをExcelに記述する必要があるが」→ 「テストデータファイルに記述する必要があるが」
+
+---
+
+## 05_UnitTestGuide/ への影響
+
+05_UnitTestGuide/ はリクエスト単体テストの「具体的な使い方」を説明するハウツーガイドであり、06_TestFWGuide/ の仕様説明と対になっている。以下のファイルが影響を受ける可能性が高い。
+
+### 強く影響を受けるファイル
+
+| ファイル | 影響理由 |
+|---|---|
+| `02_RequestUnitTest/batch.rst` | バッチリクエスト単体テストのテストデータ記述方法（SETUP_FIXED/SETUP_VARIABLE/EXPECTED_FIXED/EXPECTED_VARIABLE）の実例を含む。Excel前提のテストデータ記述例がYAML対応で追記・変更が必要になる |
+| `02_RequestUnitTest/real.rst` | メッセージ受信テストのテストデータ記述方法（MESSAGE/EXPECTED電文等）の実例を含む。Excel前提のテストデータ記述例がYAML対応で追記・変更が必要になる。具体的には: 42行目「テストデータを記載したExcelファイルは…テストソースコードと同じディレクトリに同じ名前で格納する」（命名規則説明）、45行目「how_to_write_excel 参照」リンク、34行目・36行目「１テストクラスにつき１テストメソッド、１テストシートを原則」「メソッドやシートを分割しても良い」（テストメソッド分割方針）、71行目「同じシート内に記載したデータのグループID」、268行目「準備したテストシートに対応するメソッドを作成する」、286行目「テストデータのシート名を指定できる」など計12箇所。YAML対応後は命名規則（ディレクトリ規約・ファイル名）・シート分割概念のYAML版説明を追記する必要がある |
+| `02_RequestUnitTest/send_sync.rst` | 同期応答メッセージ送信テストのテストデータ記述方法（EXPECTED_REQUEST_*_MESSAGES/RESPONSE_*_MESSAGES等）の実例を含む。Excel前提 |
+| `02_RequestUnitTest/index.rst` | testShots/requestParamsの定義方法（LIST_MAP=testShots等）を説明する。YAML版での記述方法を補足する必要がある |
+| `02_RequestUnitTest/http_send_sync.rst` | send_syncと同様 |
+| `01_ClassUnitTest/02_componentUnitTest.rst` | コンポーネント単体テストのテストデータ（LIST_MAP等）記述例を含む |
+| `01_ClassUnitTest/01_entityUnitTest/01_entityUnitTestWithBeanValidation.rst` | エンティティバリデーションテストのテストデータ記述例を含む |
+| `01_ClassUnitTest/01_entityUnitTest/02_entityUnitTestWithNablarchValidation.rst` | 同上 |
+
+### 軽微な影響が考えられるファイル
+
+| ファイル | 影響度 | 影響箇所 |
+|---|---|---|
+| `02_RequestUnitTest/rest.rst` | 軽微（要修正） | 84行目: `how_to_write_excel` 参照リンク、91行目・92行目: 「テストクラス一つにつきExcelファイルが必ず一つ必要」「Excelファイルが存在しない場合でも」、96行目: 「上記以外のテストデータをExcelファイルに記載可能」、97行目: `how_to_get_data_from_excel` 参照リンク、115行目: 「テストデータを記載したExcelファイルにテストメソッドの名前でシートを用意」の計7箇所。参照リンク先（`how_to_write_excel`・`how_to_get_data_from_excel`）がYAML対応で変更された場合はリンク先の更新も必要。それ以外の修正箇所はExcel/YAMLを包含する表現への置き換えで対応可能 |
+| `02_RequestUnitTest/mail.rst` | 軽微（要修正） | 28行目: 「期待する上記3テーブルの状態をExcelシートに記述すればよい」→ 「テストデータファイル（ExcelシートまたはYAMLファイル）に記述すればよい」に修正が必要。言及は1箇所のみ |
+| `02_RequestUnitTest/fileupload.rst` | 軽微（要修正） | 66行目・111行目: 「テストデータシート」という表現が2箇所。Excelと明示してはいないが「シート」はExcel前提の語であるため、「テストデータファイル」等の表現に修正が必要 |
+| `02_RequestUnitTest/http_send_sync.rst` | 軽微（要修正） | 33行目: 「1セルに全部記述すると可読性が落ちる場合」（Excelセルへの言及）、47行目・49行目: 「1Excelシートに1テストケースのみ記述すること」「Excelの各行の文字列長が同一であることを期待している」というNTF制約の説明。YAML対応後は制約の適用範囲をExcel/YAML別に説明する必要がある |
+| `02_RequestUnitTest/http_real.rst` | 軽微（要修正） | `real.rst` との差分のみを記述するファイルだが、固有のExcel言及が3箇所ある。39行目: 「Excelファイルのメッセージボディとの比較で行う」（tipブロック内）、151行目: 「1Excelシートに1テストケースのみ記述すること」（JSON/XMLデータ形式使用時のNTF制約）、153行目: 「Excelの各行の文字列長が同一であることを期待している」（NTF制約の理由説明）。`http_send_sync.rst` と同様のパターンであり、YAML対応後は制約の適用範囲をExcel/YAML別に説明する必要がある |
+| `03_DealUnitTest/batch.rst` | 強い影響（要修正） | 29行目・37行目・39行目・46行目・52行目・53行目・67行目・80行目・113行目・125行目・136行目・147行目・153行目・164行目・180行目: 「1シートにつき1テストケース」「1つのシートに全テストデータを詰め込む」「1ケースを複数シートに分割して記述してもよい」「1シートに全テストケースを含めてもよい」「1シートにまとめて記述する」「1シート内に複数のバッチ実行を記述」「グループIDを使用することで1シートに複数ケースのテストデータを記述できる」等、テストケース分割方針の説明がExcelシート前提で全面的に記述されている。YAML対応後はファイル単位の対応概念を追加説明する必要がある |
+| `03_DealUnitTest/send_sync.rst` | 強い影響（要修正） | 51行目・54行目・55行目・65行目・68行目・70行目・72行目・77行目・84行目・143行目・173行目・176行目・177行目・187行目・189行目・301行目・304行目・312行目・319行目・326行目・333行目: 「応答電文のフォーマットおよびデータをExcelファイルに定義する」「ファイルの名前は「RM21AA0101.xlsx」となる」「Excelファイルの書き方」セクション見出し、「Excelファイルを記載する」「シート名は「message」固定」「Excelファイルの再読み込み」機能の説明、「Excelファイルの配置場所の設定」等、ファイル形式・命名規則・配置設定レベルで多数のExcel前提の記述がある。Excelファイル名（.xlsx）・シート名・配置設定をYAMLに対応させる必要がある |
+| `03_DealUnitTest/http_send_sync.rst` | 強い影響（要修正） | 22行目・25行目・27行目・34行目: 「Excelファイルの書き方」セクション見出し（主要見出しレベル）、「定められた記述ルールに従いExcelファイルを記載する」「Excelファイルに定義した応答電文のフォーマットおよびデータは」「以下に、Excelファイルの記載例を示す」。send_sync.rst との差分のみを記述するファイルだが、Excelファイルに関するセクション見出しと説明が直接記述されており修正が必要 |
+| `03_DealUnitTest/delayed_receive.rst` | 影響なし（修正不要） | 本文7行のみ。「取引単体テストの実施方法は、同期応答メッセージ受信処理と同じである。実施方法の詳細は `./real` を参照すること。」という参照のみ。Excel/シート/セルへの言及は一切なし |
+| `03_DealUnitTest/delayed_send.rst` | 影響なし（修正不要） | 本文7行のみ。「取引単体テストの実施方法は、同期応答メッセージ送信処理と同じである。実施方法の詳細は `./real` を参照すること。」という参照のみ。Excel/シート/セルへの言及は一切なし |
+| `01_ClassUnitTest/02_componentUnitTest.rst` | 強い影響（要修正） | 14行目・16行目: ダウンロードリンクで「UserComponentTest.xlsx」というExcelファイル名を直接参照。43行目: 「テストデータ(Excelファイル)そのもの」。47行目・48行目: 「テストデータを記載したExcelファイルは〜同じ名前で格納する（拡張子のみ異なる）」「全てのテストデータは同じExcelのシートに記載する前提」という命名規則・格納方法の説明。242行目・244行目: 「getListMapメソッドを用いてExcelシートからデータを読み込んでいる」「how_to_get_data_from_excel へのリンク参照」。314行目: 「同じExcelシート内に正常系と異常系のデータを混載している」。YAML対応ではディレクトリ規約・ファイル命名・データ読み込み方法の説明を全面的に修正・追記する必要がある |
+
+---
+
+## Completion Criteria
+
+| Criterion | Self-check | Evidence | QA | QA Evidence |
+|---|---|---|---|---|
+| 06_TestFWGuide/ 配下の全ファイルの役割とYAML対応修正箇所の一覧が記録されている | OK | 上記「06_TestFWGuide/ 全ファイル構成」テーブル（12ファイル全列挙）および「YAML対応で修正が必要な箇所一覧」セクション（修正が必要な8ファイルについて具体的なセクション・箇所を列挙） | OK | 全26ファイルをfindで列挙して突き合わせ。Excel/シート言及のある未記載ファイルなし。05_UnitTestGuide影響範囲も実ファイル確認済み（2回の修正で補完）。 |
+
+## QA Expert Review
+
+| Aspect | Verdict | Evidence / Improvement |
+|---|---|---|
+| Meaningful tests/verification | OK | 前回2回の指摘事項（計12ファイル）がすべてtask2.mdに反映。影響度・行番号レベルで具体的に記載されている |
+| Edge case coverage | OK | 05_UnitTestGuide/ 配下全26ファイルをfindで列挙し突き合わせ。Excel/シート言及のある未記載ファイルはゼロ |
+
+## Overall Verdict
+
+- Self-check: OK
+- QA: OK
+- Language expert: N/A
+- Software-engineering expert: N/A
+- Ready for user review: Yes
diff --git a/.rn/ntf-yaml-support/input/ntf-doc-terms.md b/.rn/ntf-yaml-support/input/ntf-doc-terms.md
new file mode 100644
index 00000000..91b67147
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-doc-terms.md
@@ -0,0 +1,538 @@
+# NTF 解説書（v6）用語リファレンス
+
+NTF（自動テストフレームワーク）解説書から抽出した用語の引き表。`ntf-testdata-doc.md` の見直しで、解説書の正式な用語名・表記・仕様を引くために使う。
+
+取得元の解説書 URL ベース:
+`https://nablarch.github.io/docs/LATEST/doc/development_tools/testing_framework/guide/development_guide/`
+
+取得対象は `06_TestFWGuide/` 配下、補足参照は `05_UnitTestGuide/` 配下。各用語の出典ページは見出し直下に示す。
+
+---
+
+## 用語ドメインの全体像
+
+```mermaid
+flowchart TB
+ DT[データタイプ
Excel 1行目のキーワード]
+ SHEET[シート・行・列・セル
テストデータの物理構造]
+ GID[グループID
同シート内データの識別標識]
+ TS[testShots / requestParams
テストケース一覧]
+ FILE[ファイルデータ
固定長・可変長のフィールド定義]
+ MSG[メッセージング
電文・FW制御ヘッダ]
+ FORMAT[特殊記法・コメント・マーカーカラム
セル値の解釈規則]
+
+ SHEET --> DT
+ DT --> GID
+ DT --> TS
+ DT --> FILE
+ DT --> MSG
+ SHEET --> FORMAT
+```
+
+データタイプが解析の起点（Excel 1 行目の `データタイプ=値`）で、グループ ID・testShots・ファイルデータ・メッセージングはいずれもデータタイプに紐づく。特殊記法・コメント・マーカーカラムはセル値の解釈規則として全データタイプに横断的にかかる。
+
+---
+
+## データタイプ（Data Types）
+
+出典: `06_TestFWGuide/01_Abstract.html`
+
+フレームワークが認識する固定キーワード。データ 1 行目に `データタイプ=値` の形式で記載する。
+
+| データタイプ | 設定値 | 用途 |
+|---|---|---|
+| `SETUP_TABLE` | テーブル名 | テスト前に DB へ登録する準備データ |
+| `EXPECTED_TABLE` | テーブル名 | テスト後の DB 期待値（省略カラムは比較対象外） |
+| `EXPECTED_COMPLETE_TABLE` | テーブル名 | テスト後の DB 期待値（省略カラムにはデフォルト値を適用して比較） |
+| `LIST_MAP` | 一意の ID | `List>` 形式で取得するデータ |
+| `SETUP_FIXED` | ファイルパス | 固定長ファイルの事前準備データ |
+| `EXPECTED_FIXED` | ファイルパス | 固定長ファイルの期待値 |
+| `SETUP_VARIABLE` | ファイルパス | 可変長ファイルの事前準備データ |
+| `EXPECTED_VARIABLE` | ファイルパス | 可変長ファイルの期待値 |
+| `EXPECTED_REQUEST_HEADER_MESSAGES` | リクエスト ID | 要求電文（ヘッダ）の期待値（固定長ファイル形式） |
+| `EXPECTED_REQUEST_BODY_MESSAGES` | リクエスト ID | 要求電文（本文）の期待値（固定長ファイル形式） |
+| `RESPONSE_HEADER_MESSAGES` | リクエスト ID | 応答電文（ヘッダ）データ（固定長ファイル形式） |
+| `RESPONSE_BODY_MESSAGES` | リクエスト ID | 応答電文（本文）データ（固定長ファイル形式） |
+
+`MESSAGE` 系データタイプには、固定 ID として `setUpMessages`／`expectedMessages` も使う（メッセージング処理テスト）。
+
+---
+
+## シート・行・列・セル
+
+出典: `06_TestFWGuide/01_Abstract.html`
+
+| 用語 | 定義 |
+|---|---|
+| ファイル名 | テストクラス名と同一（拡張子のみ `.xlsx`） |
+| シート名 | テストメソッド名と同一 |
+| setUpDb シート | テストクラス共通の DB 初期値を記載する特殊シート名（テストメソッド実行前に自動投入） |
+| 1 行目（データタイプ行） | `データタイプ=値` を記述する行 |
+| 2 行目（ヘッダ行） | カラム名（Map のキー）を記述する行 |
+| 3 行目以降（データ行） | 実データ・レコードを記述する行 |
+| カラム | Excel の列に対応する概念（フィールド名） |
+| セル | 個々の入力値の単位。書式は全て文字列として記述する |
+
+2 行目以降の具体構造はデータタイプごとに異なる（後述「データタイプ別の行構造」）。
+
+---
+
+## セル値の解釈規則（特殊記法・マーカーカラム・コメント）
+
+出典: `06_TestFWGuide/01_Abstract.html`
+
+### 特殊記法
+
+| 記述 | 変換内容 |
+|---|---|
+| `null` | null 値 |
+| `"null"` | 文字列 `null`（前後のダブルクォートを除去） |
+| `""` | 空文字列 |
+| `${systemTime}` | システム日時（実行時に挿入） |
+| `${setUpTime}` | コンポーネント設定ファイルで定めた固定タイムスタンプ |
+| `${文字種,文字数}` | 指定文字種・文字数で生成（例: `${半角英字,5}`） |
+| `${binaryFile:パス}` | 指定パスのバイナリファイル内容（BLOB 列用） |
+| `\\r` | CR 改行コード |
+| `\\n` | LF 改行コード |
+
+### マーカーカラム
+
+カラム名を半角角括弧で囲む（例: `[no]`）と、そのカラムはテスト実行時に読み込まれない。Excel 上の可読性向上（行番号表示など）に使う視覚的マーカー。
+
+### コメント
+
+セル値の `//` 以降はフレームワークが読み込まない（ドキュメント注釈用途）。
+
+### 日付記述フォーマット
+
+`yyyyMMddHHmmssSSS` または `yyyy-MM-dd HH:mm:ss.SSS`。ミリ秒・時刻部分は省略可能。
+
+### 設計原則（用語として登場する概念）
+
+- テスト独立性: テストメソッドの実行順序に依存しない設計
+- データ集約: テストデータは全て Excel に記述
+- データタイプまとめ記述: 複数データタイプ使用時は種類ごとにまとめる（混在するとデータ読み込みが途中で終了する）
+
+---
+
+## グループ ID
+
+出典: `06_TestFWGuide/02_RequestUnitTest.html`
+
+同じシート内に記載したデータを識別する標識。`setUpTable`・`expectedSearch`・`expectedTable` などのカラムでグループ ID を参照し、対応するデータセットを紐付ける。
+
+- 書式: `データタイプ[グループID]=値`（例: `SETUP_TABLE[case_001]=EMPLOYEE_TABLE`）
+- `default`: デフォルトグループ ID（省略時に使用される）
+
+---
+
+## データタイプ別の行構造
+
+### DB 系（SETUP_TABLE / EXPECTED_TABLE / EXPECTED_COMPLETE_TABLE / LIST_MAP）
+
+出典: `06_TestFWGuide/02_DbAccessTest.html`
+
+いずれも 1 行目に `データタイプ=値`、2 行目にカラム名（Map のキー）、3 行目以降にデータ行を置く。
+
+| データタイプ | 2 行目 | 3 行目以降 |
+|---|---|---|
+| `SETUP_TABLE=テーブル名` | カラム名（複数列） | 登録レコード |
+| `LIST_MAP=任意のID` | Map のキー（SELECT 句で指定したカラム名） | 期待結果（SELECT 対象カラムは全て記述必須） |
+| `EXPECTED_TABLE=テーブル名` | カラム名 | 期待値（省略カラムは比較対象外） |
+| `EXPECTED_COMPLETE_TABLE=テーブル名` | カラム名 | 期待値（省略カラムにはデフォルト値が格納されているものとして比較） |
+
+#### デフォルト値
+
+| データ型 | デフォルト値 |
+|---|---|
+| 数値型 | `0` |
+| 文字列型 | 半角スペース |
+| 日付型 | `1970-01-01 00:00:00.0` |
+
+カスタマイズは `BasicDefaultValues` クラスで設定。
+
+#### カラム省略の制約
+
+- 主キーカラムは省略不可。
+- 省略カラムへのデフォルト値適用は `EXPECTED_COMPLETE_TABLE` のみ（`EXPECTED_TABLE` では省略カラムを比較対象外とする）。
+
+#### タイムスタンプ形式
+
+`java.sql.Timestamp` 型: `yyyy-mm-dd hh:mm:ss.fffffffff`（f は 9 桁ナノ秒）
+
+#### マスタデータ復旧機能
+
+外部キー設定テーブルの親子関係データを扱う際に利用する機能。読み取り専用マスタを共通ファイルで再利用する場合にも用いる。
+
+### 固定長ファイル（SETUP_FIXED / EXPECTED_FIXED）
+
+出典: `06_TestFWGuide/RequestUnitTest_batch.html`、`05_UnitTestGuide/02_RequestUnitTest/batch.html`
+
+```
+SETUP_FIXED[グループID]=ファイルパス
+
+[ディレクティブ行] ← text-encoding, record-separator 等
+[レコード種別行]
+[フィールド名称行]
+[データ型行] ← 日本語表記（例: 半角英字）
+[フィールド長行]
+[データ行]
+```
+
+- バイナリデータは 16 進数形式（例: `0x4AD`）で記述。`0x` プレフィックスがない場合は文字列として解釈。
+- 指定したフィールド長に対してデータのバイト長が短い場合、フィールドのデータ型に応じたパディングが行われる。
+
+### 可変長ファイル（SETUP_VARIABLE / EXPECTED_VARIABLE）
+
+出典: `06_TestFWGuide/RequestUnitTest_batch.html`、`05_UnitTestGuide/02_RequestUnitTest/batch.html`
+
+```
+SETUP_VARIABLE[グループID]=ファイルパス
+
+[ディレクティブ行]
+[レコード種別行]
+[フィールド名称行]
+[データ型行]
+（フィールド長行は存在しない）
+[データ行]
+```
+
+固定長との違いはフィールド長を記載しない点。
+
+### ファイルデータのフィールド定義用語
+
+| 用語 | 定義 |
+|---|---|
+| レコード種別行 | ファイルデータのレコード種別を示す行 |
+| フィールド名称行 | 各フィールド名称を並べた行 |
+| データ型行 | フィールドのデータ型を示す行（日本語表記例: 「半角英字」） |
+| フィールド長行 | 各フィールドのバイト長を示す行（固定長のみ存在） |
+| データ行 | 実データを並べた行 |
+| パディング | フィールド長に対してデータのバイト長が短い場合に自動補完される処理 |
+
+### ディレクティブ
+
+出典: `06_TestFWGuide/RequestUnitTest_batch.html`
+
+ファイル／電文フォーマット定義の設定行。コンポーネント設定でデフォルト値を map 形式で指定可能。
+
+| ディレクティブキー | 対象 | 説明 |
+|---|---|---|
+| `text-encoding` | 共通 | 文字エンコーディング（例: `Windows-31J`） |
+| `record-separator` | 共通 | レコード区切り文字（例: `CRLF`） |
+| `quoting-delimiter` | 可変長 | 引用符区切り文字 |
+| `file-type` | メッセージ | 電文全体を文字列として扱うか項目単位で分割するかの制御（`Fixed` / `XML` / `JSON` 等） |
+| `record-length` | 固定長 | レコード長。フィールド長から自動計算のため記載不要な場合あり |
+
+デフォルト値設定のコンポーネントプロパティ:
+- `defaultDirectives`（共通）
+- `fixedLengthDirectives`（固定長専用）
+- `variableLengthDirectives`（可変長専用）
+
+---
+
+## testShots / requestParams（テストケース一覧）
+
+`LIST_MAP` データタイプで定義するテストケース一覧。固定 ID `testShots` と `requestParams` を持ち、カラム構成はテスト種別ごとに異なる。
+
+| 用語 | 定義 |
+|---|---|
+| `testShots` | テストケース一覧の `LIST_MAP` ID（固定値） |
+| `TestShot` | テストケース 1 件分の情報を格納・実行するクラス |
+| `requestParams` | リクエストパラメータの `LIST_MAP` ID（固定値） |
+| 行単位の関連付け | testShots と requestParams は同じ行番号で対応する |
+
+### testShots カラム一覧（ウェブアプリケーション）
+
+出典: `06_TestFWGuide/02_RequestUnitTest.html`、`05_UnitTestGuide/02_RequestUnitTest/index.html`
+
+| カラム名 | 必須 | 説明 |
+|---|---|---|
+| `no` | ✓ | テストケース番号（1 からの連番） |
+| `description` | ✓ | テストケースの説明。HTML ダンプファイル名に使用される |
+| `context` | ✓ | リクエスト ID・ユーザ・HTTP メソッドを記載 |
+| `cookie` | - | Cookie 情報 |
+| `queryParams` | - | クエリパラメータ情報 |
+| `isValidToken` | - | トークン設定の要否（`true` / `false`） |
+| `setUpTable` | - | テストケース実行前の DB 登録用グループ ID |
+| `expectedStatusCode` | ✓ | 期待する HTTP ステータスコード |
+| `expectedMessageId` | - | 期待するメッセージ ID（複数の場合はカンマ区切り） |
+| `expectedSearch` | - | 期待する検索結果のグループ ID（`SqlResultSet` 型、リクエストスコープキー `searchResult`） |
+| `expectedTable` | - | 期待するテーブル状態のグループ ID |
+| `forwardUri` | - | 期待するフォワード先 URI |
+| `expectedContentLength` | - | ダウンロード時のコンテンツレングス期待値 |
+| `expectedContentType` | - | ダウンロード時のコンテンツタイプ期待値 |
+| `expectedContentFileName` | - | ダウンロード時のファイル名期待値 |
+| `expectedMessage` | - | メッセージ同期送信時の要求電文グループ ID |
+| `responseMessage` | - | メッセージ同期送信時の応答電文グループ ID |
+| `expectedMessageByClient` | - | HTTP メッセージ同期送信時の要求電文グループ ID |
+| `responseMessageByClient` | - | HTTP メッセージ同期送信時の応答電文グループ ID |
+
+#### requestParams の仕様
+
+- `LIST_MAP=requestParams` として定義。HTTP リクエストパラメータを表す。
+- パラメータが不要なテストケースでもダミー行の定義が必須。
+- 1 つのキーに複数の値を指定する場合はカンマ区切り。カンマ自体を含める場合は `\\` でエスケープ。
+
+### testShots カラム一覧（バッチ処理）
+
+出典: `06_TestFWGuide/RequestUnitTest_batch.html`、`05_UnitTestGuide/02_RequestUnitTest/batch.html`
+
+| カラム名 | 必須 | 説明 |
+|---|---|---|
+| `no` | ✓ | テストケース番号（1 からの連番） |
+| `description` | ✓ | テストケースの説明 |
+| `expectedStatusCode` | ✓ | 期待するステータスコード |
+| `diConfig` | ✓ | バッチ実行時のコンポーネント設定ファイルへのパス |
+| `requestPath` | ✓ | バッチ実行時のリクエストパス |
+| `userId` | ✓ | バッチ実行ユーザ ID |
+| `setUpTable` | - | テスト前の DB 登録用グループ ID |
+| `setUpFile` | - | 入力用ファイル作成時に参照するデータのグループ ID |
+| `expectedTable` | - | 期待する DB 状態のグループ ID |
+| `expectedFile` | - | 出力ファイルの期待値データのグループ ID |
+| `expectedLog` | - | 期待するログメッセージを記載した `LIST_MAP` の ID |
+| `args[n]` | - | コマンドライン引数（n は 0 以上の整数、連続した添字が必要） |
+
+### testShots カラム一覧（メッセージング受信）
+
+出典: `06_TestFWGuide/RequestUnitTest_real.html`、`05_UnitTestGuide/02_RequestUnitTest/real.html`
+
+| カラム名 | 必須 | 説明 |
+|---|---|---|
+| `no` | ✓ | テストケース番号（1 からの連番） |
+| `description` | ✓ | テストケースの説明 |
+| `expectedStatusCode` | ✓ | 期待するステータスコード |
+| `diConfig` | ✓ | コンポーネント設定ファイルパス |
+| `requestPath` | ✓ | リクエストパス（常駐バッチ） |
+| `userId` | ✓ | 実行ユーザ ID |
+| `setUpTable` | - | テスト前の DB 初期化用グループ ID |
+| `expectedTable` | - | 期待する DB 状態のグループ ID |
+| `expectedLog` | - | 期待するログメッセージ ID |
+
+### ログ検証（expectedLog）
+
+出典: `06_TestFWGuide/RequestUnitTest_batch.html`
+
+`LIST_MAP=expectedLogMessages` として定義し、以下のカラムを含む（AND 条件で評価）。
+
+| カラム名 | 説明 |
+|---|---|
+| `logLevel` | 期待するログレベル |
+| `message1` | 期待するログに含まれる文言（複数設定可: `message1`, `message2`, ...） |
+
+---
+
+## メッセージング
+
+### 基本用語
+
+| 用語 | 定義 |
+|---|---|
+| 電文 | メッセージング処理のメッセージ |
+| 要求電文 | 送信するメッセージ（リクエスト） |
+| 応答電文 | 受信するメッセージ（レスポンス） |
+| 電文種別 | 要求電文／応答電文の分類 |
+| フレームワーク制御ヘッダ | メッセージに付与される制御情報（`requestId` 等） |
+| メッセージボディ | フレームワーク制御ヘッダ以降の実データ部分 |
+| `setUpMessages` | メッセージング受信テストにおける要求電文 ID（固定値） |
+| `expectedMessages` | メッセージング受信テストにおける応答電文期待値 ID（固定値） |
+| `no`（電文側） | 複数電文送信時の連番・送信順序を示す電文内フィールド |
+
+### メッセージデータ構造（受信: setUpMessages / expectedMessages）
+
+出典: `06_TestFWGuide/RequestUnitTest_real.html`、`05_UnitTestGuide/02_RequestUnitTest/real.html`
+
+`MESSAGE=setUpMessages` または `MESSAGE=expectedMessages` として定義。
+
+セクション 1 ─ ディレクティブ行:
+- `text-encoding`（文字エンコーディング）
+- `record-separator`（レコード区切り）
+- `requestId`（フレームワーク制御ヘッダ: リクエスト識別子）
+- `file-type`（電文種別の解釈方式）
+
+セクション 2 ─ メッセージボディ:
+- 1 行目: フィールド名称（先頭セルは `no`）
+- 2 行目: データ型（先頭セルは空白）
+- 3 行目: フィールド長（先頭セルは空白）
+- 4 行目以降: 実データ（先頭セルは通番）
+
+#### `FwHeaderDefinition` / `fwHeaderDefinition`
+
+- `FwHeaderDefinition` 実装クラスが `fwHeaderDefinition` という名前でコンポーネント登録されていることが前提。
+- 異なる名称の場合は `getFwHeaderDefinitionName()` メソッドをオーバーライドする。
+
+### メッセージデータタイプ（同期応答メッセージ送信）
+
+出典: `06_TestFWGuide/RequestUnitTest_send_sync.html`、`05_UnitTestGuide/02_RequestUnitTest/send_sync.html`
+
+| データタイプ | 設定値 | 用途 |
+|---|---|---|
+| `EXPECTED_REQUEST_HEADER_MESSAGES` | リクエスト ID | 要求電文ヘッダの期待値 |
+| `EXPECTED_REQUEST_BODY_MESSAGES` | リクエスト ID | 要求電文本文の期待値 |
+| `RESPONSE_HEADER_MESSAGES` | リクエスト ID | 応答電文ヘッダデータ |
+| `RESPONSE_BODY_MESSAGES` | リクエスト ID | 応答電文本文データ |
+
+グループ ID 付き書式例: `EXPECTED_REQUEST_BODY_MESSAGES[グループID]=リクエストID`
+
+電文データの行構造: `no` カラム（複数電文送信時の連番・送信順序） → フィールド名称行 → データ型行（日本語表記例: 「半角英字」） → フィールド長行 → データ行。
+
+ディレクティブの記載不要項目:
+- `file-type`（テスティングフレームワークが固定長のみ対応）
+- `record-length`（フィールド長から自動計算）
+
+### 障害系テスト用特殊値
+
+応答電文の最初のフィールド（`no` 除く）に設定する。
+
+| 設定値 | 発生する例外 |
+|---|---|
+| `errorMode:timeout` | `MessageSendSyncTimeoutException`（タイムアウトシミュレート） |
+| `errorMode:msgException` | `MessagingException`（メッセージ受信エラーシミュレート） |
+
+### 制約事項（同期応答メッセージ送信）
+
+- フィールド名称に重複は許容されない。
+- 複数レコード電文の場合「ヘッダ → 本文」を交互に記載する必要がある。
+- `expectedMessage` および `responseMessage` が空欄で送信が行われた場合、テストは失敗する。
+
+### HTTP 同期応答メッセージ送信の用語読み替え
+
+出典: `06_TestFWGuide/RequestUnitTest_http_send_sync.html`
+
+「同期応答メッセージ送信処理テスト」との差分のみ。基本は同期応答メッセージ送信を参照。
+
+| 標準用語（同期応答メッセージ送信） | HTTP 版の対応用語 |
+|---|---|
+| 同期応答メッセージ送信 | HTTP 同期応答メッセージ送信 |
+| `MockMessagingContext` | `MockMessagingClient` |
+| `RequestTestingMessagingProvider` | `RequestTestingMessagingClient` |
+
+---
+
+## テスト種別と主要クラス
+
+### テスト種別の正式名称
+
+| 正式名称 | 内容 |
+|---|---|
+| クラス単体テスト | Action/Component の単体テスト |
+| リクエスト単体テスト（ウェブアプリケーション） | HTTP リクエスト 1 件単位のテスト（シンクライアント型）。Ajax 等のリッチクライアントは未対応 |
+| リクエスト単体テスト（RESTful ウェブサービス） | REST API の 1 リクエスト単位テスト |
+| リクエスト単体テスト（バッチ処理） | バッチ処理の 1 バッチ起動単位テスト |
+| リクエスト単体テスト（メッセージ受信処理） | 電文受信 1 件単位テスト |
+| リクエスト単体テスト（同期応答メッセージ送信処理） | 同期応答電文送信の 1 リクエスト単位テスト |
+| リクエスト単体テスト（HTTP 同期応答メッセージ送信処理） | HTTP 同期応答電文送信の 1 リクエスト単位テスト |
+| 取引単体テスト | 複数リクエストをまたぐ業務取引単位のテスト |
+
+### DB アクセステスト
+
+出典: `06_TestFWGuide/02_DbAccessTest.html`
+
+| 分類 | 操作 | 検証・要件 |
+|---|---|---|
+| 参照系テスト | SELECT | `setUpDb` で準備データを投入し、`assertSqlResultSetEquals` で検証。コミット処理は不要 |
+| 更新系テスト | INSERT / UPDATE / DELETE | 実行後に `commitTransactions()` が必須。`assertTableEquals` で検証 |
+
+| メソッド | 用途 |
+|---|---|
+| `setUpDb(String sheetName)` | シート内の全 SETUP_TABLE を処理して準備データを投入 |
+| `assertSqlResultSetEquals(sheetName, mapId, SqlResultSet)` | 参照結果を LIST_MAP と比較（レコード順序を厳密に比較） |
+| `assertTableEquals(sheetName)` | 更新後 DB を EXPECTED_TABLE と比較（主キーで照合、順序不問） |
+| `commitTransactions()` | トランザクションをコミット（更新系テストで必須） |
+
+### リクエスト単体テスト（ウェブアプリケーション）の主要クラス
+
+出典: `06_TestFWGuide/02_RequestUnitTest.html`、`05_UnitTestGuide/02_RequestUnitTest/index.html`
+
+| クラス名 | 役割 |
+|---|---|
+| `DbAccessTestSupport` | DB 関連の準備データ投入・検証機能 |
+| `HttpServer` | 内蔵サーブレットコンテナ（内蔵サーバ） |
+| `HttpRequestTestSupport` | リクエスト単体テスト用アサート提供 |
+| `BasicHttpRequestTestTemplate` | テストソース記述量を削減するテンプレートクラス |
+| `TestCaseInfo` | データシートに定義されたテストケース情報を格納するクラス |
+
+シート構成: `setUpDb` シート（テストクラス共通 DB 初期値）、`testShots` シート（テストケース一覧、`LIST_MAP` ID は `testShots`）、`requestParams` シート（HTTP リクエストパラメータ、`LIST_MAP` ID は `requestParams`）。
+
+#### HTML ダンプ出力
+
+- デフォルト出力先: `./tmp/html_dump`
+- ディレクトリ構造: テストクラスごとのディレクトリ／テストケース説明と同名の HTML ファイル
+- CSS・画像等のリソースも同ディレクトリに出力。
+
+#### コンポーネント設定の主要項目
+
+| 項目名 | デフォルト値 | 説明 |
+|---|---|---|
+| `htmlDumpDir` | `./tmp/html_dump` | HTML ダンプの出力先 |
+| `webBaseDir` | `../main/web` | ウェブアプリケーションルート |
+| `userIdSessionKey` | `user.id` | ユーザ ID を格納するセッションキー |
+| `dumpVariableItem` | `false` | JSESSIONID・トークンのダンプ出力制御 |
+| `checkHtml` | `true` | HTML チェック実施フラグ |
+
+### リクエスト単体テスト（RESTful ウェブサービス）
+
+出典: `06_TestFWGuide/RequestUnitTest_rest.html`
+
+| クラス名 | 役割 |
+|---|---|
+| `RestTestSupport` | DB 機能を含む完全版スーパクラス |
+| `SimpleRestTestSupport` | DB 不要な場合の簡略版スーパクラス |
+| `RestMockHttpRequest` | リクエスト構築に使用するオブジェクト |
+
+- リクエスト構築（流れるようなインターフェース）: `get` / `post` / `put` / `patch` / `delete` および汎用の `newRequest` で `RestMockHttpRequest` を生成。
+- 結果検証: `assertStatusCode`（HTTP ステータスコード）、`readTextResource`（ファイルベースの期待値読み込み）。レスポンスボディは JSONAssert・json-path-assert・XMLUnit 等の外部ライブラリを推奨。
+- 必須モジュール: `nablarch-testing-rest`・`nablarch-testing-default-configuration`・`nablarch-testing-jetty12`。
+
+### リクエスト単体テスト（バッチ処理）
+
+出典: `06_TestFWGuide/RequestUnitTest_batch.html`、`05_UnitTestGuide/02_RequestUnitTest/batch.html`
+
+| クラス名 | 役割 |
+|---|---|
+| `StandaloneTestSupportTemplate` | コンテナ外処理のテスト環境を提供 |
+| `BatchRequestTestSupport` | テスト準備・アサート提供 |
+| `TestShot` | テストケース 1 件分の情報を格納・実行するクラス |
+| `MainForRequestTesting` | テスト用メインクラス |
+
+常駐バッチテスト時のハンドラ変更: `RequestThreadLoopHandler` を `OneShotLoopHandler` に変更する（セットアップした要求データ全件処理後にバッチ実行が終了するため）。
+
+### リクエスト単体テスト（メッセージ受信処理）
+
+出典: `06_TestFWGuide/RequestUnitTest_real.html`、`05_UnitTestGuide/02_RequestUnitTest/real.html`
+
+| クラス名 | 役割 |
+|---|---|
+| `StandaloneTestSupportTemplate` | コンテナ外処理のテスト環境を提供 |
+| `TestShot` | テストケース 1 件分の情報を格納・実行するクラス |
+| `MessagingRequestTestSupport` | 同期応答メッセージ用スーパクラス |
+| `MessagingReceiveTestSupport` | 応答不要メッセージ用スーパクラス |
+
+### リクエスト単体テスト（同期応答メッセージ送信処理）
+
+出典: `06_TestFWGuide/RequestUnitTest_send_sync.html`、`05_UnitTestGuide/02_RequestUnitTest/send_sync.html`
+
+| クラス名 | 役割 |
+|---|---|
+| `StandaloneTestSupportTemplate` | Action 実行後に `MockMessagingContext` で要求メッセージを検証 |
+| `AbstractHttpRequestTestTemplate` | HTTP ベース処理用スーパクラス |
+| `RequestTestingMessagingProvider` | 要求メッセージ検証・応答メッセージ生成 |
+| `MessageSender` | 同期応答メッセージ送信処理コンポーネント |
+| `TestDataConvertor` | Excel から読み込んだテストデータの編集インターフェース |
+| `MockMessagingContext` | モックメッセージングコンテキスト |
+
+---
+
+## その他のフレームワーク固有用語
+
+| 用語 | 定義 |
+|---|---|
+| 内蔵サーバ | テスト時に使用するサーブレットコンテナ（`HttpServer`） |
+| リクエストスコープ | HTTP リクエスト単位のスコープ（例: 検索結果格納キー `searchResult`） |
+| `BasicDefaultValues` | デフォルト値設定をカスタマイズするクラス |
+| `FixedSystemTimeProvider` | システム日時を固定値に設定するコンポーネント（形式: `yyyyMMddHHmmss`） |
+| `FastTableIdGenerator` | シーケンスオブジェクト採番をテーブル採番に置き換えるコンポーネント |
+| `nablarch.test.resource-root` | テストデータ読み込みディレクトリの設定キー（セミコロン区切りで複数指定可） |
+| `BasicAdvice` | `execute(Advice advice)` で使用するコールバック実装クラス |
+| `beforeExecute()` | リクエスト送信前コールバック |
+| `afterExecute()` | リクエスト送信後コールバック |
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-file.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-file.md
new file mode 100644
index 00000000..17f11f6a
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-file.md
@@ -0,0 +1,308 @@
+# NTF テストデータ解説書 — 記述例（ファイルデータ）
+
+ファイルデータ（固定長／可変長）のテストデータを Excel と YAML で書くための記述例集です。該当するシナリオの節を引いて、Excel 表と YAML を写して使います。
+
+## 全体像
+
+各形式は同じ NTF 仕様上の意味を別の記法で表します。中核要素の対応は次のとおり。
+
+```mermaid
+flowchart LR
+ subgraph Excel
+ E1[SETUP_FIXED=パス / 区切り行]
+ E2[レコード種別+フィールド名称行]
+ E3[データ型行 / フィールド長行]
+ E4[データ行 先頭セル空]
+ end
+ subgraph YAML
+ Y1[path / type / group_id]
+ Y2[record_type]
+ Y3["fields: name/type/length"]
+ Y4["rows: 値配列"]
+ end
+ E1 --- Y1
+ E2 --- Y2
+ E3 --- Y3
+ E4 --- Y4
+```
+
+| 節 | シナリオ | 引くきっかけ |
+|---|---|---|
+| [6.1](#61-固定長ファイル) | 固定長ファイル | 入出力とも固定長の基本形 |
+| [6.2](#62-エンコーディング指定付き固定長ファイル) | エンコーディング指定 | `text-encoding` 等のディレクティブを付ける |
+| [6.3](#63-groupid-付き固定長ファイル) | groupId 付き | ケースごとに入力ファイルを使い分ける |
+| [6.4](#64-可変長ファイル) | 可変長ファイル | CSV など区切り文字形式 |
+| [6.5](#65-複数レコードレイアウト) | 複数レコードレイアウト | 1 ファイルに HEADER と DATA が混在 |
+| [6.6](#66-空ファイル) | 空ファイル | 0 バイトのファイルを生成 |
+
+形式間で共通する記法規則:
+
+- フィールドは Excel では「レコード種別+フィールド名称行・データ型行・フィールド長行」の 3 行、YAML では `fields:` 配列の 1 要素（`name`／`type`／`length`）で定義します。
+- データ値はパディングなしで記述します。フレームワークが自動付与します。
+- YAML の `rows:` 各配列は `fields:` と**完全に同じ順序・件数**で値を並べます。
+- Excel のデータ行は先頭セルを必ず空にします（Excel 固有の制約）。YAML に先頭要素を空にする制約はありません。
+
+各節の YAML キーは上記を前提に、節固有の差分（ディレクティブ・groupId・レコード数）だけを示します。
+
+---
+
+
+
+## 6.1 固定長ファイル
+
+注文データのバッチ処理テスト。固定長の入力ファイルを読み込んで処理し、結果を固定長の出力ファイルに書き出すことを確認するケース。
+
+### Excel
+
+| SETUP_FIXED=work/input.txt | | | | |
+|---|---|---|---|---|
+| データ | ID | COUNTER | MESSAGE | |
+| | 半角 | 数値 | 半角 | |
+| | 5 | 5 | 10 | |
+| | 10001 | 10 | hello | |
+| | 10002 | 20 | good bye. | |
+
+| EXPECTED_FIXED=work/output.txt | | | | |
+|---|---|---|---|---|
+| データ | ID | COUNTER | MESSAGE | |
+| | 半角 | 数値 | 半角 | |
+| | 5 | 5 | 10 | |
+| | 10001 | 11 | HELLO | |
+| | 10002 | 21 | GOOD BYE. | |
+
+### YAML
+
+```yaml
+setup_files:
+ - path: work/input.txt
+ type: fixed
+ records:
+ - record_type: データ
+ fields:
+ - {name: ID, type: 半角, length: 5}
+ - {name: COUNTER, type: 数値, length: 5}
+ - {name: MESSAGE, type: 半角, length: 10}
+ rows:
+ - ["10001", "10", "hello"]
+ - ["10002", "20", "good bye."]
+
+expected_files:
+ - path: work/output.txt
+ type: fixed
+ records:
+ - record_type: データ
+ fields:
+ - {name: ID, type: 半角, length: 5}
+ - {name: COUNTER, type: 数値, length: 5}
+ - {name: MESSAGE, type: 半角, length: 10}
+ rows:
+ - ["10001", "11", "HELLO"]
+ - ["10002", "21", "GOOD BYE."]
+```
+
+---
+
+## 6.2 エンコーディング指定付き固定長ファイル
+
+MS932 エンコーディングで顧客データファイルを読み込むケース。ディレクティブでエンコーディングを明示指定します。
+
+### Excel
+
+| SETUP_FIXED=input/data.dat | | | |
+|---|---|---|---|
+| text-encoding | MS932 | | |
+| DATA | USER_ID | USER_NAME | AMOUNT |
+| | X | N | Z |
+| | 10 | 20 | 10 |
+| | 001 | 山田太郎 | 5000 |
+| | 002 | 鈴木花子 | 3000 |
+
+- ディレクティブ行はレコード定義より前に記述します（「キー | 値」の 2 セル構成）。
+
+### YAML
+
+```yaml
+setup_files:
+ - path: input/data.dat
+ type: fixed
+ directives:
+ text-encoding: MS932
+ records:
+ - record_type: DATA
+ fields:
+ - {name: USER_ID, type: 半角, length: 10}
+ - {name: USER_NAME, type: 全角, length: 20}
+ - {name: AMOUNT, type: 数値, length: 10}
+ rows:
+ - ["001", "山田太郎", "5000"]
+ - ["002", "鈴木花子", "3000"]
+```
+
+- ディレクティブは `directives:` オブジェクトの `key: value` 形式で記述します。
+
+---
+
+## 6.3 groupId 付き固定長ファイル
+
+テストケースごとに異なる入力ファイルを使い分けるケース。groupId なしがデフォルトの 1 件処理、`case2` が追加データありの複数件処理に対応します。
+
+### Excel
+
+| SETUP_FIXED=work/input.txt | | | | |
+|---|---|---|---|---|
+| データ | ID | COUNTER | MESSAGE | |
+| | 半角 | 数値 | 半角 | |
+| | 5 | 5 | 10 | |
+| | 10001 | 10 | hello | |
+
+| SETUP_FIXED[case2]=work/input.txt | | | | |
+|---|---|---|---|---|
+| データ | ID | COUNTER | MESSAGE | |
+| | 半角 | 数値 | 半角 | |
+| | 5 | 5 | 10 | |
+| | 20001 | 30 | morning | |
+
+- groupId は `SETUP_FIXED[case2]=パス` のように指定します。
+
+### YAML
+
+```yaml
+setup_files:
+ - path: work/input.txt
+ type: fixed
+ records:
+ - record_type: データ
+ fields:
+ - {name: ID, type: 半角, length: 5}
+ - {name: COUNTER, type: 数値, length: 5}
+ - {name: MESSAGE, type: 半角, length: 10}
+ rows:
+ - ["10001", "10", "hello"]
+ - group_id: case2
+ path: work/input.txt
+ type: fixed
+ records:
+ - record_type: データ
+ fields:
+ - {name: ID, type: 半角, length: 5}
+ - {name: COUNTER, type: 数値, length: 5}
+ - {name: MESSAGE, type: 半角, length: 10}
+ rows:
+ - ["20001", "30", "morning"]
+```
+
+- groupId は `group_id:` フィールドで指定します。省略するとグループ ID なし（デフォルトグループ）扱いです。
+- groupId なしと `group_id: case2` の 2 エントリが同一 `setup_files:` リストに並びます。
+
+---
+
+## 6.4 可変長ファイル
+
+CSV 形式の顧客データファイルを入力として使うケース。フィールド区切り文字をディレクティブで指定します。
+
+### Excel
+
+| SETUP_VARIABLE=input/data.csv | | | |
+|---|---|---|---|
+| field-separator | , | | |
+| DATA | USER_ID | USER_NAME | AMOUNT |
+| | X | N | X |
+| | 001 | 山田太郎 | 5000 |
+| | 002 | 鈴木花子 | 3000 |
+
+### YAML
+
+```yaml
+setup_files:
+ - path: input/data.csv
+ type: variable
+ directives:
+ field-separator: ","
+ records:
+ - record_type: DATA
+ fields:
+ - {name: USER_ID, type: X}
+ - {name: USER_NAME, type: N}
+ - {name: AMOUNT, type: X}
+ rows:
+ - ["001", "山田太郎", "5000"]
+ - ["002", "鈴木花子", "3000"]
+```
+
+- 固定長との差異は `type: fixed` / `type: variable` と `length` の有無だけです。可変長では `fields:` の各要素から `length` を省略します。
+
+---
+
+
+
+## 6.5 複数レコードレイアウト
+
+1 ファイルに HEADER レコードと DATA レコードが混在する振込依頼ファイルを扱うケース。
+
+### Excel
+
+| SETUP_FIXED=input/multi.dat | | | |
+|---|---|---|---|
+| HEADER | SEQ | TYPE | |
+| | X | X | |
+| | 4 | 2 | |
+| | H001 | 01 | |
+| DATA | USER_ID | AMOUNT | NOTE |
+| | X | Z | N |
+| | 10 | 10 | 20 |
+| | 001 | 5000 | 備考 |
+
+- 同一セクション内でレコード種別+フィールド名称行を続けて書くと、複数レコードレイアウトになります。
+
+### YAML
+
+```yaml
+setup_files:
+ - path: input/multi.dat
+ type: fixed
+ records:
+ - record_type: HEADER
+ fields:
+ - {name: SEQ, type: X, length: 4}
+ - {name: TYPE, type: X, length: 2}
+ rows:
+ - ["H001", "01"]
+ - record_type: DATA
+ fields:
+ - {name: USER_ID, type: X, length: 10}
+ - {name: AMOUNT, type: Z, length: 10}
+ - {name: NOTE, type: N, length: 20}
+ rows:
+ - ["001", "5000", "備考"]
+```
+
+- `records:` 配列に複数のレコードレイアウトを並べます。
+
+---
+
+
+
+## 6.6 空ファイル
+
+出力ファイルがゼロ件のときに 0 バイトの空ファイルを生成することを確認するケース。
+
+### Excel
+
+| SETUP_FIXED=input/empty.dat | |
+|---|---|
+| text-encoding | MS932 |
+
+- ディレクティブ行のみ記述してレコード定義以降を省略します。
+
+### YAML
+
+```yaml
+setup_files:
+ - path: input/empty.dat
+ type: fixed
+ directives:
+ text-encoding: MS932
+ records: []
+```
+
+- レコードは `records: []` と空配列で記述します。
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-messaging.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-messaging.md
new file mode 100644
index 00000000..73dee960
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-messaging.md
@@ -0,0 +1,197 @@
+# NTF テストデータ解説書 — 記述例（メッセージングテストデータ）
+
+
+
+メッセージング系データブロック（MESSAGE / SendSync 期待値 / sendSyncTestData 配置 / ステータスコードデフォルト）の Excel・YAML 記法をケースごとに引く。各ケースとも Excel と YAML の対応例を並べ、末尾に制約・補足を示す。
+
+## 7.1 MESSAGE セクション（メッセージ送受信）
+
+受信電文と応答電文を定義するケース。実物のデータは `MessageParserTest.xls` の `testParse` シートを参照。
+
+### Excel
+
+| MESSAGE=requestMessages | | | |
+|---|---|---|---|
+| text-encoding | Windows-31J | | |
+| requestId | hoge | | |
+| userId | moge | | |
+| | ユーザ名 | 備考 | FILLER |
+| | 全角 | 全角 | 半角 |
+| | 50 | 200 | 252 |
+| 1 | 電文太郎 | 特筆なし | |
+| 2 | | ユーザ名が空欄なのでエラーが発生します。 | |
+
+| MESSAGE=responseMessages | | | |
+|---|---|---|---|
+| no | 処理結果コード | 会員ID | FILLER |
+| | X | X | X |
+| | 2 | 10 | 490 |
+| 1 | 00 | 1234567890 | |
+| 2 | 01 | | |
+
+### YAML
+
+```yaml
+messages:
+ - id: requestMessages
+ directives:
+ text-encoding: Windows-31J # ディレクティブ
+ fw_header: # FW制御ヘッダ（任意キーのマップ）
+ requestId: hoge
+ userId: moge
+ records:
+ - record_type: default
+ fields:
+ - {name: ユーザ名, type: 全角, length: 50}
+ - {name: 備考, type: 全角, length: 200}
+ - {name: FILLER, type: 半角, length: 252}
+ rows:
+ - ["電文太郎", "特筆なし", ""]
+ - ["", "ユーザ名が空欄なのでエラーが発生します。", ""]
+ - id: responseMessages
+ records:
+ - record_type: default
+ fields:
+ - {name: 処理結果コード, type: 半角, length: 2}
+ - {name: 会員ID, type: 半角, length: 10}
+ - {name: FILLER, type: 半角, length: 490}
+ rows:
+ - ["00", "1234567890", ""]
+ - ["01", "", ""]
+```
+
+### 制約・補足
+
+- ディレクティブ行（`text-encoding` など）はフィールド定義より前に記述する
+- Excel のフィールド名称行の先頭セルは空にする（Excel 固有）
+- `no` 列（先頭列）はフレームワークが除去する。データとして保存されない
+- `record_type` の値はフレームワーク内部で `"default"` に置き換えられる。任意の値を記述できる（`FW_HEADER` のような予約値はない。FW制御ヘッダは `fw_header:` マップに記述する）
+
+---
+
+## 7.2 要求電文・応答電文の期待値（SendSync メッセージング）
+
+バッチリクエスト単体テストで電文の送受信をテストするケース。実物のデータは `RequestTestingSendSyncSupportTest.xls` を参照。
+
+### Excel
+
+| LIST_MAP=testShots | | | | | | | | | | |
+|---|---|---|---|---|---|---|---|---|---|---|
+| no | description | expectedStatusCode | setUpTable | expectedTable | expectedLog | diConfig | requestPath | userId | expectedMessage | responseMessage |
+| 1 | 電文送受信テスト | 0 | | | | batch-test-component-configuration.xml | BM21AA0106 | batch_user | case1 | res_case1 |
+
+| EXPECTED_REQUEST_HEADER_MESSAGES[case1]=RM21AA0104_01 | | | |
+|---|---|---|---|
+| text-encoding | ms932 | | |
+| no | requestId | | |
+| | 半角 | | |
+| | 20 | | |
+| 1 | RM21AA0104_01 | | |
+
+### YAML
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "電文送受信テスト"
+ expectedStatusCode: "0"
+ setUpTable: ""
+ expectedTable: ""
+ expectedLog: ""
+ diConfig: "batch-test-component-configuration.xml"
+ requestPath: "BM21AA0106"
+ userId: "batch_user"
+ expectedMessage: "case1"
+ responseMessage: "res_case1"
+
+expected_request_header_messages:
+ - group_id: case1
+ id: RM21AA0104_01
+ directives:
+ text-encoding: ms932
+ records:
+ - record_type: default
+ fields:
+ - {name: requestId, type: 半角, length: 20}
+ rows:
+ - ["RM21AA0104_01"]
+```
+
+### 制約・補足
+
+- `expectedMessage` カラムには要求電文の groupId、`responseMessage` カラムには応答電文の groupId を指定する
+- YAML では `expected_request_header_messages:` の `group_id:` が `testShots` の `expectedMessage` カラムに対応する
+- `id:` はリクエスト ID（フォーマット定義ファイルの解決に使われる）
+- ヘッダとボディのエントリ数（rows 合計）は一致が必須
+
+---
+
+## 7.3 sendSyncTestData の配置規則
+
+テストデータファイルを `sendSyncTestData/{requestId}/message` に配置するケース。
+
+### Excel
+
+| MESSAGE=sendSyncTestData/REQ001/message | | | |
+|---|---|---|---|
+| no | errorMode | field1 | field2 |
+| 1 | | value1 | value2 |
+| 2 | | value3 | value4 |
+
+### YAML
+
+```yaml
+messages:
+ - id: sendSyncTestData/REQ001/message
+ records:
+ - record_type: DATA
+ fields:
+ - {name: no, type: 半角, length: 2}
+ - {name: errorMode, type: 半角, length: 10}
+ - {name: field1, type: 半角, length: 10}
+ - {name: field2, type: 半角, length: 10}
+ rows:
+ - ["1", "", "value1", "value2"]
+ - ["2", "", "value3", "value4"]
+```
+
+### 制約・補足
+
+- `MESSAGE=sendSyncTestData/{requestId}/message` というパスで配置する
+- `no` 列の値は送信順序と一致させる
+- `errorMode` に `errorMode:timeout` を指定するとタイムアウトエラー、`errorMode:msgException` を指定すると例外エラーのシミュレーションになる。どちらを指定した場合も他フィールドはパース対象外になる
+- N 回送信する場合はヘッダ件数とボディ件数をともに N 件ずつ記述する
+
+---
+
+## 7.4 ステータスコードのデフォルト値
+
+HTTP 同期応答テストでステータスコードカラムを省略するケース。
+
+### Excel
+
+| RESPONSE_BODY_MESSAGES=REQ001 | | |
+|---|---|---|
+| no | body | |
+| | 半角 | |
+| | 10 | |
+| 1 | RESULT_OK | |
+
+### YAML
+
+```yaml
+response_body_messages:
+ - id: REQ001
+ records:
+ - record_type: DATA
+ fields:
+ - {name: body, type: 半角, length: 10}
+ rows:
+ - ["RESULT_OK"]
+```
+
+### 制約・補足
+
+- ステータスコード列がない場合、実行時にデフォルト値 `"200"` が使用される
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-overview.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-overview.md
new file mode 100644
index 00000000..2c07be9e
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-overview.md
@@ -0,0 +1,194 @@
+# NTF テストデータ解説書 — 記述例（概要・groupId）
+
+
+
+## 1. NTF テストデータ
+
+リクエスト単体テスト（バッチ処理）の例。1 ファイルにテストケース・セットアップ・検証が共存する。
+
+### Excel
+
+| LIST_MAP=testShots | | | | | | | | | | |
+|---|---|---|---|---|---|---|---|---|---|---|
+| no | description | expectedStatusCode | setUpTable | expectedTable | setUpFile | expectedFile | diConfig | requestPath | userId | expectedLog |
+| 1 | 注文カウンタが正しくインクリメントされます | 0 | default | default | | | nablarch/test/core/batch/BatchSample.xml | DBtoDBBatchSample | test | expectedLog |
+
+| SETUP_TABLE=ORDER_HEADER | | | |
+|---|---|---|---|
+| ORDER_ID | ITEM_COUNT | REMARKS | |
+| 10001 | 10 | 通常注文 | |
+| 10002 | 20 | まとめ買い | |
+
+| EXPECTED_TABLE=ORDER_HEADER | | | |
+|---|---|---|---|
+| ORDER_ID | ITEM_COUNT | REMARKS | UPDATE_DATE |
+| 10001 | 11 | 通常注文 | 2010-09-13 12:34:56.0 |
+| 10002 | 21 | まとめ買い | 2010-09-13 12:34:56.0 |
+
+| LIST_MAP=expectedLog | | |
+|---|---|---|
+| message | logLevel | |
+| 注文ID[10001] | INFO | |
+| 注文ID[10002] | INFO | |
+
+- 種別はブロック先頭のラベルで決まる：`LIST_MAP=testShots` がテストケース定義、`SETUP_TABLE` がセットアップ、`EXPECTED_TABLE` が検証、`LIST_MAP=expectedLog` が期待ログ
+
+### YAML
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "正しく更新されます"
+ expectedStatusCode: "0"
+ setUpTable: "default"
+ expectedTable: "default"
+ setUpFile: ""
+ expectedFile: ""
+ diConfig: "nablarch/test/core/batch/BatchSample.xml"
+ requestPath: "DBtoDBBatchSample"
+ userId: "test"
+ expectedLog: "expectedLog"
+ - id: expectedLog
+ rows:
+ - message: "注文ID[10001]"
+ logLevel: "INFO"
+ - message: "注文ID[10002]"
+ logLevel: "INFO"
+
+setup_tables:
+ - table: ORDER_HEADER
+ rows:
+ - ORDER_ID: "10001"
+ ITEM_COUNT: "10"
+ REMARKS: "通常注文"
+ - ORDER_ID: "10002"
+ ITEM_COUNT: "20"
+ REMARKS: "まとめ買い"
+
+expected_tables:
+ - table: ORDER_HEADER
+ rows:
+ - ORDER_ID: "10001"
+ ITEM_COUNT: "11"
+ REMARKS: "通常注文"
+ UPDATE_DATE: "2010-09-13 12:34:56.0"
+ - ORDER_ID: "10002"
+ ITEM_COUNT: "21"
+ REMARKS: "まとめ買い"
+ UPDATE_DATE: "2010-09-13 12:34:56.0"
+```
+
+- 種別はトップレベルキーで決まる：`list_maps:` の `id: testShots` がテストケース定義、`setup_tables:` がセットアップ、`expected_tables:` が検証
+- `id: expectedLog` のような任意 ID の `list_maps:` エントリも同一ファイルに共存できる
+- 同一の `list_maps:` キーには複数エントリをリストとして並べる（YAML はトップレベルキーの重複不可のため）
+
+> [要確認] `description` カラムが Excel 例（注文カウンタが正しくインクリメントされます）と YAML 例（正しく更新されます）で食い違う。両形式は同一データを表すべきなのでどちらかが誤り。正しい文言を確認のうえ揃える。
+
+---
+
+
+
+## 4.3 セクションのグループ化（groupId）
+
+テストケースごとに異なるセットアップ／検証データを使い分けるシナリオ。`testShots` の `setUpTable`／`expectedTable` カラムに書いた値が groupId となり、その groupId が付いたセクションだけが対象になる。
+
+| ケース | setUpTable | 投入されるセクション |
+|---|---|---|
+| ケース1（正常注文） | `case01` | `SETUP_TABLE[case01]` |
+| ケース2（大量注文） | `case02` | `SETUP_TABLE[case02]` |
+
+`expectedTable` も同様に、書いた値の groupId が付いた `EXPECTED_TABLE[...]` セクションが検証に使われる。groupId を省略したセクションは `setUpTable` が空のケースで使われる（groupId なし = デフォルトグループ）。
+
+### Excel
+
+groupId はセクションラベルの `[...]` で表す。
+
+| LIST_MAP=testShots | | | | |
+|---|---|---|---|---|
+| no | description | expectedStatusCode | setUpTable | expectedTable |
+| 1 | 正常注文 | 0 | case01 | case01 |
+| 2 | 大量注文 | 0 | case02 | case02 |
+
+| SETUP_TABLE[case01]=ORDER_DETAIL | | | | |
+|---|---|---|---|---|
+| ORDER_ID | PRODUCT_CODE | QUANTITY | UNIT_PRICE | |
+| 1001 | P-001 | 5 | 1500 | |
+
+| EXPECTED_TABLE[case01]=ORDER_DETAIL | | | | |
+|---|---|---|---|---|
+| ORDER_ID | PRODUCT_CODE | QUANTITY | UNIT_PRICE | |
+| 1001 | P-001 | 5 | 1500 | |
+
+| SETUP_TABLE[case02]=ORDER_DETAIL | | | | |
+|---|---|---|---|---|
+| ORDER_ID | PRODUCT_CODE | QUANTITY | UNIT_PRICE | |
+| 2001 | P-003 | 100 | 500 | |
+| 2001 | P-004 | 200 | 300 | |
+
+| EXPECTED_TABLE[case02]=ORDER_DETAIL | | | | |
+|---|---|---|---|---|
+| ORDER_ID | PRODUCT_CODE | QUANTITY | UNIT_PRICE | |
+| 2001 | P-003 | 100 | 500 | |
+| 2001 | P-004 | 200 | 300 | |
+
+### YAML
+
+groupId は各セクションの `group_id` キーで表す。
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "正常注文"
+ expectedStatusCode: "0"
+ setUpTable: "case01"
+ expectedTable: "case01"
+ - no: "2"
+ description: "大量注文"
+ expectedStatusCode: "0"
+ setUpTable: "case02"
+ expectedTable: "case02"
+
+setup_tables:
+ - group_id: case01
+ table: ORDER_DETAIL
+ rows:
+ - ORDER_ID: "1001"
+ PRODUCT_CODE: "P-001"
+ QUANTITY: "5"
+ UNIT_PRICE: "1500"
+ - group_id: case02
+ table: ORDER_DETAIL
+ rows:
+ - ORDER_ID: "2001"
+ PRODUCT_CODE: "P-003"
+ QUANTITY: "100"
+ UNIT_PRICE: "500"
+ - ORDER_ID: "2001"
+ PRODUCT_CODE: "P-004"
+ QUANTITY: "200"
+ UNIT_PRICE: "300"
+
+expected_tables:
+ - group_id: case01
+ table: ORDER_DETAIL
+ rows:
+ - ORDER_ID: "1001"
+ PRODUCT_CODE: "P-001"
+ QUANTITY: "5"
+ UNIT_PRICE: "1500"
+ - group_id: case02
+ table: ORDER_DETAIL
+ rows:
+ - ORDER_ID: "2001"
+ PRODUCT_CODE: "P-003"
+ QUANTITY: "100"
+ UNIT_PRICE: "500"
+ - ORDER_ID: "2001"
+ PRODUCT_CODE: "P-004"
+ QUANTITY: "200"
+ UNIT_PRICE: "300"
+```
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-special.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-special.md
new file mode 100644
index 00000000..6c3a299d
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-special.md
@@ -0,0 +1,321 @@
+# NTF テストデータ解説書 — 記述例（特殊値・ディレクティブ・ヘッダ）
+
+特殊値・インタープリタ、ファイルディレクティブ、ヘッダ／コメント／空エントリの Excel・YAML 記法を項目ごとに引く。各項目とも Excel と YAML の対応例を並べ、末尾に制約を示す。
+
+
+
+## 8. 特殊値・インタープリタ
+
+### 8.1 日付型・Timestamp・特殊値
+
+`EXPECTED_TABLE` で日付・タイムスタンプ・NULL・システム日時を使うケース。実物のデータは `BasicTestDataParserTest.xls` の `convertedValues` シートを参照。
+
+#### Excel
+
+| EXPECTED_TABLE=SCHEDULE | | | |
+|---|---|---|---|
+| ID | EVENT_NAME | START_DATE | CREATED_AT |
+| 1 | 会議 | 2024-01-15 | 2024-01-01 09:00:00.0 |
+| 2 | NULLテスト | NULL | NULL |
+| 3 | システム時刻 | ${systemTime} | ${systemTime} |
+| 4 | 更新時刻 | ${updateTime} | ${setUpTime} |
+
+#### YAML
+
+```yaml
+expected_tables:
+ - table: SCHEDULE
+ rows:
+ - ID: "1"
+ EVENT_NAME: "会議"
+ START_DATE: "2024-01-15"
+ CREATED_AT: "2024-01-01 09:00:00.0"
+ - ID: "2"
+ EVENT_NAME: "NULLテスト"
+ START_DATE: null
+ CREATED_AT: null
+ - ID: "3"
+ EVENT_NAME: "システム時刻"
+ START_DATE: "${systemTime}"
+ CREATED_AT: "${systemTime}"
+ - ID: "4"
+ EVENT_NAME: "更新時刻"
+ START_DATE: "${updateTime}"
+ CREATED_AT: "${setUpTime}"
+```
+
+#### 制約
+
+- `NULL` 文字列は `NullInterpreter` が Java null に変換する。大文字小文字不問（`null`・`Null` も同様）。YAML ではアンクォートの `null` で記述し、`"null"` とクォートすると文字列として格納される
+- `${systemTime}` は完全一致のみ変換される。文字列中に埋め込むには `CompositeInterpreter` との組み合わせが必要
+- `java.sql.Timestamp` 型カラムの期待値は末尾 `.0` が必須（`"2024-01-01 09:00:00.0"`）。末尾 `.0` がないとアサートが失敗する
+
+> [要確認] `${updateTime}`・`${setUpTime}`（行 4）が解決する値の定義が本ファイルにない。`${systemTime}` との違いと対応するインタープリタを確認のうえ補う。
+
+---
+
+### 8.2 QuotationTrimmer によるスペース値明示記法
+
+空白値やダブルクォート文字を明示して記述するケース。
+
+#### Excel
+
+| EXPECTED_TABLE=ITEM | | |
+|---|---|---|
+| ID | NAME | MEMO |
+| 1 | " " | """ |
+
+#### YAML
+
+```yaml
+expected_tables:
+ - table: ITEM
+ rows:
+ - ID: "1"
+ NAME: " "
+ MEMO: "\""
+```
+
+#### 制約
+
+- Excel: `" "` → 半角スペース1文字、`"""` → ダブルクォート1文字。半角または全角ダブルクォートで前後が囲まれた場合のみ外側1層を除去する
+- YAML: `" "` でスペース1文字。ダブルクォート文字は `"\""` または `'"'` で記述する
+
+---
+
+### 8.3 バイナリデータ
+
+BLOB カラムにバイナリデータを記述するケース。
+
+#### Excel
+
+| SETUP_TABLE=FILE_TABLE | | |
+|---|---|---|
+| FILE_ID | FILE_DATA | |
+| 001 | 0xCAFEBABE | |
+| 002 | ${binaryFile:testdata.bin} | |
+
+#### YAML
+
+```yaml
+setup_tables:
+ - table: FILE_TABLE
+ rows:
+ - FILE_ID: "001"
+ FILE_DATA: "0xCAFEBABE"
+ - FILE_ID: "002"
+ FILE_DATA: "${binaryFile:testdata.bin}"
+```
+
+#### 制約
+
+- `0x` プレフィクス付き16進数でバイナリ値を記述する。`0x` がない場合は文字列としてエンコードされる
+- `${binaryFile:パス}` でファイル内容をバイナリ読み込みして HexString に変換する
+
+---
+
+
+
+## 9. ディレクティブ
+
+### 9.1 固定長ファイルのディレクティブ
+
+エンコーディングとゾーン10進数の符号ニブルを指定するケース。
+
+#### Excel
+
+| SETUP_FIXED=input/data.dat | | |
+|---|---|---|
+| text-encoding | MS932 | |
+| positive-zone-sign-nibble | C | |
+| DATA | USER_ID | AMOUNT |
+| | X | Z |
+| | 10 | 10 |
+| | 001 | 5000 |
+
+#### YAML
+
+```yaml
+setup_files:
+ - path: input/data.dat
+ type: fixed
+ directives:
+ text-encoding: MS932
+ positive-zone-sign-nibble: C
+ records:
+ - record_type: DATA
+ fields:
+ - {name: USER_ID, type: X, length: 10}
+ - {name: AMOUNT, type: Z, length: 10}
+ rows:
+ - ["001", "5000"]
+```
+
+#### 制約
+
+- Excel のディレクティブ行は「キー | 値」の2セルで記述する。YAML は `directives:` オブジェクトの `key: value` 形式
+- `file-type` と `record-length` はフレームワークが自動設定するため通常は記述不要
+- 無効なディレクティブキーを指定すると `IllegalArgumentException` がスローされる
+
+---
+
+### 9.2 可変長ファイルのディレクティブ
+
+タブ区切り・CRLF 改行のファイルを扱うケース。
+
+#### Excel
+
+| SETUP_VARIABLE=input/data.tsv | | |
+|---|---|---|
+| field-separator | \t | |
+| record-separator | CRLF | |
+| DATA | FIELD1 | FIELD2 |
+| | X | X |
+| | value1 | value2 |
+
+#### YAML
+
+```yaml
+setup_files:
+ - path: input/data.tsv
+ type: variable
+ directives:
+ field-separator: "\\t"
+ record-separator: CRLF
+ records:
+ - record_type: DATA
+ fields:
+ - {name: FIELD1, type: X}
+ - {name: FIELD2, type: X}
+ rows:
+ - ["value1", "value2"]
+```
+
+#### 制約
+
+- タブ文字の記法が形式で異なる。Excel セルには `\t`（バックスラッシュ + t の2文字）を入力し、フレームワークがタブ文字（0x09）に変換する。YAML は `"\\t"` と記述する（YAML の `\t` は実際のタブ文字になるためバックスラッシュをエスケープする）
+- `record-separator` には `NONE` / `CR` / `LF` / `CRLF` または任意リテラル文字列が有効
+- `field-separator` は1文字のみ有効。2文字以上は `IllegalArgumentException` がスローされる
+
+---
+
+
+
+## 10. ヘッダ・コメント・空エントリ
+
+### 10.1 コメントとマーカーカラム
+
+#### Excel
+
+| SETUP_TABLE=TEST_TABLE | | | | |
+|---|---|---|---|---|
+| // この行はコメントです | | | | |
+| [no] | PK_COL1 | PK_COL2 | NUMBER_COL | [desc] |
+| 1 | 0000000001 | AB | 100 | テスト1 |
+| // この行もスキップされます | | | | |
+| 2 | 0000000002 | CD | 200 | テスト2 |
+
+#### YAML
+
+```yaml
+setup_tables:
+ - table: TEST_TABLE
+ rows:
+ # この行はコメントです（YAML の # 構文）
+ - "[no]": "1"
+ PK_COL1: "0000000001"
+ PK_COL2: "AB"
+ NUMBER_COL: "100"
+ "[desc]": "テスト1"
+ - "[no]": "2"
+ PK_COL1: "0000000002"
+ PK_COL2: "CD"
+ NUMBER_COL: "200"
+ "[desc]": "テスト2"
+```
+
+#### 制約
+
+- Excel: `//` で始まる行は丸ごとスキップされる（テスト実行に影響しない）。**行内コメント**は先頭以外の要素が `//` で始まる場合にその要素以降が切り捨てられる（Excel 固有）
+- YAML: 標準のコメント構文（`#`）を使う。行末コメントも可（`NUMBER_COL: "100" # 数値カラム`）
+- `[no]`・`[desc]` のように角括弧で囲んだカラムはマーカーカラムで、DB 操作から除外される。YAML ではダブルクォートで囲む（`"[no]"`）
+
+---
+
+### 10.2 空エントリのスキップ
+
+全要素が null または空文字のエントリは読み飛ばされる。
+
+#### Excel
+
+| SETUP_TABLE=USER | | |
+|---|---|---|
+| USER_ID | NAME | |
+| 001 | 山田太郎 | |
+| | | |
+| 002 | 鈴木花子 | |
+
+#### YAML
+
+```yaml
+setup_tables:
+ - table: USER
+ rows:
+ - USER_ID: "001"
+ NAME: "山田太郎"
+ # 空行はここには書かない（YAML にはそもそも空エントリの概念がない）
+ - USER_ID: "002"
+ NAME: "鈴木花子"
+```
+
+#### 制約
+
+- Excel: 全セルが空の行は自動的にスキップされる
+- YAML: キーを省略するだけのため空エントリを記述する機会はほとんどない。空行を挿入しても無視される
+
+---
+
+
+
+## 11. DB アサート
+
+> テーブルアサートの記法・省略カラムの扱い・主キー突合は [ntf-testdata-doc-examples-table.md](ntf-testdata-doc-examples-table.md#table-data) と本体仕様（[ntf-testdata-doc.md](ntf-testdata-doc.md) 5.4）に詳しい。ここでは DB アサート固有の挙動だけを示す。
+
+### 11.1 テーブルアサート（順序不問・主キー突合）
+
+`EXPECTED_TABLE` は記述順と DB の格納順が違っても、主キーで突合して比較する。下記は順序が違っても成功するケース。
+
+#### Excel
+
+| EXPECTED_TABLE=USER | | |
+|---|---|---|
+| USER_ID | NAME | |
+| 001 | 山田太郎 | |
+| 002 | 鈴木花子 | |
+
+#### YAML
+
+```yaml
+expected_tables:
+ - table: USER
+ rows:
+ - USER_ID: "001"
+ NAME: "山田太郎"
+ - USER_ID: "002"
+ NAME: "鈴木花子"
+```
+
+### 11.2 EXPECTED_COMPLETE_TABLE（省略カラムにデフォルト値補完）
+
+省略したカラムにデフォルト値を補完してから比較する。
+
+#### YAML
+
+```yaml
+expected_complete_tables:
+ - table: USER
+ rows:
+ - USER_ID: "001"
+ NAME: "山田太郎"
+ # AGE など省略したカラムはデフォルト値（数値型なら "0"）で補完される
+```
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-table.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-table.md
new file mode 100644
index 00000000..4622e079
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-table.md
@@ -0,0 +1,182 @@
+# NTF テストデータ解説書 — 記述例（テーブルデータ）
+
+
+
+テーブル系データブロック（SETUP_TABLE / EXPECTED_TABLE / EXPECTED_COMPLETE_TABLE / LIST_MAP）の Excel・YAML 記法を種別ごとに引く。各種別とも Excel と YAML の対応例を並べ、末尾に制約を示す。
+
+## 5.1 テーブルデータの基本形式
+
+
+
+### SETUP_TABLE
+
+会員テーブルへ初期データを INSERT するケース。
+
+#### Excel
+
+| SETUP_TABLE=MEMBER | | | | | | |
+|---|---|---|---|---|---|---|
+| MEMBER_ID | NAME | RANK | SCORE | RATE | PROFILE | PHOTO |
+| 0000000101 | 山田太郎 | 1 | 85000 | 1.5 | ゴールド会員です | ${binaryFile:testdata.txt} |
+| 0000000102 | 鈴木花子 | 2 | Null | 2.25 | シルバー会員 | ${binaryFile:member_photo.jpg} |
+
+- 1 行目にカラム名、2 行目以降にデータ
+- `//` で始まる行はコメント（型情報・桁数などの注記に使う）
+
+#### YAML
+
+```yaml
+setup_tables:
+ - table: MEMBER
+ rows:
+ - MEMBER_ID: "0000000101"
+ NAME: "山田太郎"
+ RANK: "1"
+ SCORE: "85000"
+ RATE: "1.5"
+ PROFILE: "ゴールド会員です"
+ PHOTO: "${binaryFile:testdata.txt}"
+ - MEMBER_ID: "0000000102"
+ NAME: "鈴木花子"
+ RANK: "2"
+ SCORE: null
+ RATE: "2.25"
+ PROFILE: "シルバー会員"
+ PHOTO: "${binaryFile:member_photo.jpg}"
+```
+
+- 1 行が 1 オブジェクト、カラム名がキー
+- 値は文字列で記述（`"0000000101"` のようにクォート）
+- NULL 値はアンクォートの `null`。`"null"` とクォートすると文字列として格納される
+
+#### 制約
+
+- **主キーカラムは省略不可**。省略すると `"0"` やスペースのデフォルト値が INSERT される
+- `NULL` 文字列は `NullInterpreter` により Java null に変換される（YAML ではアンクォート `null`）
+- `${binaryFile:パス}` はファイル内容をバイナリ読み込みして HexString に変換する
+
+---
+
+
+
+### EXPECTED_TABLE と EXPECTED_COMPLETE_TABLE
+
+バッチ処理後の会員スコアと注文カウンタを検証するケース。
+
+#### Excel
+
+| EXPECTED_TABLE=MEMBER | | | | |
+|---|---|---|---|---|
+| MEMBER_ID | NAME | RANK | SCORE | UPDATED_DATE |
+| 0000000101 | 山田太郎 | 1 | 87500 | 2024-04-01 09:00:00.0 |
+| 0000000102 | 鈴木花子 | 2 | 42000 | 2024-04-01 09:00:00.0 |
+
+| EXPECTED_COMPLETE_TABLE=ORDER_HEADER | | | |
+|---|---|---|---|
+| ORDER_ID | ITEM_COUNT | STATUS | UPDATE_DATE |
+| 10001 | 3 | 1 | 2024-04-01 12:30:00.0 |
+| 10002 | 5 | 1 | |
+
+#### YAML
+
+```yaml
+expected_tables:
+ - table: MEMBER
+ rows:
+ - MEMBER_ID: "0000000101"
+ NAME: "山田太郎"
+ RANK: "1"
+ SCORE: "87500"
+ UPDATED_DATE: "2024-04-01 09:00:00.0"
+ - MEMBER_ID: "0000000102"
+ NAME: "鈴木花子"
+ RANK: "2"
+ SCORE: "42000"
+ UPDATED_DATE: "2024-04-01 09:00:00.0"
+
+expected_complete_tables:
+ - table: ORDER_HEADER
+ rows:
+ - ORDER_ID: "10001"
+ ITEM_COUNT: "3"
+ STATUS: "1"
+ UPDATE_DATE: "2024-04-01 12:30:00.0"
+ - ORDER_ID: "10002"
+ ITEM_COUNT: "5"
+ STATUS: "1"
+ # UPDATE_DATE を省略 → BasicDefaultValues のデフォルト値で補完されて比較
+```
+
+#### 省略カラムの扱い
+
+| キーワード | 省略カラムの扱い | YAML での省略 |
+|---|---|---|
+| `EXPECTED_TABLE` / `expected_tables:` | 比較対象外。検証したいカラムだけ列挙できる | キーを書かない |
+| `EXPECTED_COMPLETE_TABLE` / `expected_complete_tables:` | `BasicDefaultValues` のデフォルト値を補完してから比較 | キーを書かない |
+
+#### 制約
+
+- **Excel は混在禁止**: 同一ファイル内で `EXPECTED_TABLE` と `EXPECTED_COMPLETE_TABLE` を混在させると後半のデータが読み込まれない
+- **YAML は混在可**: `expected_tables:` と `expected_complete_tables:` は別キーのため、YAML パーサーが両方を独立に読み込んでマージする
+
+---
+
+
+
+### LIST_MAP
+
+キーバリュー形式の汎用データ。マーカーカラム・期待ログ・リクエストパラメータ等に使う。
+
+#### Excel — リクエストパラメータ（マーカーカラム付き）
+
+注文検索画面の HTTP リクエストパラメータを定義するケース。
+
+| LIST_MAP=searchParams | | | | | |
+|---|---|---|---|---|---|
+| [no] | memberId | orderStatus | fromDate | toDate | [desc] |
+| 1 | 0000000101 | 1 | 2024-04-01 | 2024-04-30 | 4月注文検索 |
+| 2 | 0000000102 | | 2024-01-01 | | 全件検索 |
+
+#### Excel — 期待ログ
+
+| LIST_MAP=expectedLog | | |
+|---|---|---|
+| message | logLevel | |
+| 会員ID[0000000101]の注文を処理しました | INFO | |
+| 会員ID[0000000102]の注文を処理しました | INFO | |
+
+#### YAML
+
+```yaml
+list_maps:
+ - id: searchParams
+ rows:
+ - "[no]": "1"
+ memberId: "0000000101"
+ orderStatus: "1"
+ fromDate: "2024-04-01"
+ toDate: "2024-04-30"
+ "[desc]": "4月注文検索"
+ - "[no]": "2"
+ memberId: "0000000102"
+ orderStatus: ""
+ fromDate: "2024-01-01"
+ toDate: ""
+ "[desc]": "全件検索"
+ - id: expectedLog
+ rows:
+ - message: "会員ID[0000000101]の注文を処理しました"
+ logLevel: "INFO"
+ - message: "会員ID[0000000102]の注文を処理しました"
+ logLevel: "INFO"
+```
+
+#### マーカーカラム
+
+- 角括弧で囲んだカラム（`[no]`・`[desc]`）はマーカーカラム。DB 操作から除外される（Excel 上の見やすさのために使うことが多い）
+- YAML ではダブルクォートで囲む（`"[no]"`）。YAML の角括弧構文との衝突を避けるため
+
+#### 制約
+
+- `testShots` は予約 ID。フレームワークがテストケース定義として自動読み込みする
+- ID は完全一致で検索される。同一 ID の重複エントリは先着一致で、2 件目以降は無視される
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-testshots.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-testshots.md
new file mode 100644
index 00000000..cb65b18f
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc-examples-testshots.md
@@ -0,0 +1,287 @@
+# NTF テストデータ解説書 — testShots カラム一覧
+
+処理方式ごとの `testShots` カラムを引くためのリファレンス。どの処理方式でも `testShots` は `LIST_MAP` として記述する。
+
+- [全体像](#overview)
+- [共通カラム](#common)
+- [ウェブアプリケーション](#web)
+- [バッチ処理](#batch)
+- [メッセージング](#messaging)
+- [エンティティバリデーション](#entity)
+
+---
+
+
+
+## 全体像
+
+`testShots` の 1 行が 1 テストケース。カラムには値を直接書くものと、別セクション（`LIST_MAP` や各種テーブル／ファイル／電文セクション）の groupId・名前を指す参照型がある。処理方式ごとに必須カラムとオプションカラムが定まる。
+
+```mermaid
+flowchart LR
+ TS["testShots（LIST_MAP）
1行=1テストケース"]
+ REQ[必須カラム]
+ OPT[オプションカラム]
+ REF["別セクション
LIST_MAP / テーブル / ファイル / 電文"]
+ TS --> REQ
+ TS --> OPT
+ OPT -.参照型は名前/groupIdで指す.-> REF
+```
+
+各処理方式の対応クラス:
+
+| 処理方式 | 対応クラス |
+|---|---|
+| ウェブアプリケーション | `HttpRequestTestSupport` |
+| バッチ処理 | `BatchRequestTestSupport` |
+| メッセージング | `MessagingRequestTestSupport` |
+| エンティティバリデーション | `EntityTestSupport` |
+
+---
+
+
+
+## 共通カラム
+
+ウェブ・バッチ・メッセージングで共通の必須カラム。エンティティバリデーションは別体系（[該当節](#entity)を参照）。
+
+| カラム名 | 説明 |
+|---|---|
+| `no` | テストケース番号。空の場合はエラー |
+| `description` | テストケースの説明（旧名 `case` も可）。`description` も `case` も未定義の場合はエラー |
+| `expectedStatusCode` | 期待するステータスコード（ウェブは HTTP ステータスコード） |
+
+以降の各処理方式の表では、固有カラムを示す。
+
+---
+
+
+
+## ウェブアプリケーション（HttpRequestTestSupport）
+
+### 必須カラム
+
+[共通カラム](#common)（`no`／`description`／`expectedStatusCode`）に加えて:
+
+| カラム名 | 説明 |
+|---|---|
+| `isValidToken` | CSRF トークン制御フラグ（`1`: あり、`0`: なし） |
+| `forwardUri` | 期待するフォワード先 URI |
+| `context` | リクエスト ID・ユーザ・HTTP メソッドを記載した `LIST_MAP` 名。1エントリのみ有効。`REQUEST_ID` が空の場合は例外がスロー |
+
+### オプションカラム
+
+| カラム名 | 説明 | 空の場合 |
+|---|---|---|
+| `setUpDb` | この値と同じ名前の `LIST_MAP` を持つシートの全 `SETUP_TABLE` を、テストメソッド開始前に1回だけ INSERT | スキップ |
+| `setUpTable` | この値と同じ groupId を持つ `SETUP_TABLE` セクションを収集して INSERT | スキップ |
+| `expectedTable` | この値と同じ groupId を持つ `EXPECTED_TABLE`/`EXPECTED_COMPLETE_TABLE` セクションで DB を検証 | スキップ |
+| `expectedSearch` | 検索結果期待値の groupId（対応する `LIST_MAP` セクションを収集） | スキップ |
+| `expectedMessageId` | 期待するメッセージ ID（カンマ区切りで複数指定可） | スキップ |
+| `requestParams` | HTTP リクエストパラメータの `LIST_MAP` 名。指定した LIST_MAP の行数がテストケース番号より少ない場合はエラー | — |
+| `responseResult` | HTTP レスポンス（リクエストスコープ）期待値の `LIST_MAP` 名 | スキップ |
+| `cookie` | Cookie 値の `LIST_MAP` 名。指定した LIST_MAP が空の場合はエラー | Cookie なし |
+| `queryParams` | クエリパラメータの `LIST_MAP` 名。指定した LIST_MAP が空の場合はエラー | パラメータなし |
+| `HTTP_METHOD` | HTTP メソッド | `"POST"` |
+| `expectedContentLength` | 期待する Content-Length | スキップ |
+| `expectedContentType` | 期待する Content-Type | スキップ |
+| `expectedContentFileName` | 期待する Content-Disposition ファイル名 | スキップ |
+| `expectedMessage` | この値と同じ groupId を持つ要求電文セクション（`EXPECTED_REQUEST_HEADER/BODY_MESSAGES`）で検証 | スキップ |
+| `responseMessage` | この値と同じ groupId を持つ応答電文セクション（`RESPONSE_HEADER/BODY_MESSAGES`）をレスポンスとして返す | スキップ |
+| `expectedMessageByClient` | HTTP 同期応答メッセージ送信の要求電文グループ ID | スキップ |
+| `responseMessageByClient` | HTTP 同期応答メッセージ送信の応答電文グループ ID | スキップ |
+
+### 記述例
+
+#### Excel
+
+| LIST_MAP=testShots | | | | | |
+|---|---|---|---|---|---|
+| no | description | isValidToken | expectedStatusCode | forwardUri | context |
+| 1 | 正常ケース | 0 | 200 | /success | context001 |
+| 2 | 認証エラー | 0 | 400 | /error | context002 |
+
+| LIST_MAP=context001 | | |
+|---|---|---|
+| REQUEST_ID | USER_ID | HTTP_METHOD |
+| REQ_001 | user001 | POST |
+
+#### YAML
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "正常ケース"
+ isValidToken: "0"
+ expectedStatusCode: "200"
+ forwardUri: "/success"
+ context: "context001"
+ - no: "2"
+ description: "認証エラー"
+ isValidToken: "0"
+ expectedStatusCode: "400"
+ forwardUri: "/error"
+ context: "context002"
+ - id: context001
+ rows:
+ - REQUEST_ID: "REQ_001"
+ USER_ID: "user001"
+ HTTP_METHOD: "POST"
+```
+
+---
+
+
+
+## バッチ処理（BatchRequestTestSupport）
+
+### 必須カラム
+
+[共通カラム](#common)（`no`／`description`／`expectedStatusCode`）に加えて:
+
+| カラム名 | 説明 |
+|---|---|
+| `diConfig` | DI コンポーネント設定ファイルパス |
+| `requestPath` | リクエストパス |
+| `userId` | 実行ユーザ ID |
+
+### オプションカラム
+
+| カラム名 | 説明 | 空の場合 |
+|---|---|---|
+| `setUpDb` | この値と同じ名前の `LIST_MAP` を持つシートの全 `SETUP_TABLE` を、テストメソッド開始前に1回だけ INSERT | スキップ |
+| `setUpTable` | この値と同じ groupId を持つ `SETUP_TABLE` セクションを収集して INSERT | スキップ |
+| `expectedTable` | この値と同じ groupId を持つ `EXPECTED_TABLE`/`EXPECTED_COMPLETE_TABLE` セクションで DB を検証 | スキップ |
+| `setUpFile` | この値と同じ groupId を持つ `SETUP_FIXED`/`SETUP_VARIABLE` セクションを入力ファイルとして配置 | スキップ |
+| `expectedFile` | この値と同じ groupId を持つ `EXPECTED_FIXED`/`EXPECTED_VARIABLE` セクションで出力ファイルを検証 | スキップ |
+| `expectedLog` | 期待ログの `LIST_MAP` 名。指定した LIST_MAP が空の場合はエラー | スキップ |
+| `args[0]`, `args[1]`, ... | コマンドライン引数 | — |
+| その他任意カラム | コマンドラインオプション | — |
+
+### 記述例
+
+#### Excel
+
+| LIST_MAP=testShots | | | | | | |
+|---|---|---|---|---|---|---|
+| no | description | expectedStatusCode | diConfig | requestPath | userId | setUpFile |
+| 1 | 正しく更新されます | 0 | nablarch/test/core/batch/BatchSample.xml | DBtoDBBatchSample | test | |
+| 2 | 入力ファイルあり | 0 | nablarch/test/core/batch/BatchSample.xml | FileToFileBatchSample | test | case2 |
+
+#### YAML
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "正しく更新されます"
+ expectedStatusCode: "0"
+ diConfig: "nablarch/test/core/batch/BatchSample.xml"
+ requestPath: "DBtoDBBatchSample"
+ userId: "test"
+ setUpFile: ""
+ - no: "2"
+ description: "入力ファイルあり"
+ expectedStatusCode: "0"
+ diConfig: "nablarch/test/core/batch/BatchSample.xml"
+ requestPath: "FileToFileBatchSample"
+ userId: "test"
+ setUpFile: "case2"
+```
+
+---
+
+
+
+## メッセージング（MessagingRequestTestSupport）
+
+### 必須カラム
+
+[共通カラム](#common)（`no`／`description`／`expectedStatusCode`）に加えて:
+
+| カラム名 | 説明 |
+|---|---|
+| `diConfig` | DI コンポーネント設定ファイルパス |
+| `requestPath` | リクエストパス |
+| `userId` | 実行ユーザ ID |
+
+### オプションカラム
+
+| カラム名 | 説明 | 空の場合 |
+|---|---|---|
+| `setUpDb` | この値と同じ名前の `LIST_MAP` を持つシートの全 `SETUP_TABLE` を、テストメソッド開始前に1回だけ INSERT | スキップ |
+| `setUpTable` | この値と同じ groupId を持つ `SETUP_TABLE` セクションを収集して INSERT | スキップ |
+| `expectedTable` | この値と同じ groupId を持つ `EXPECTED_TABLE`/`EXPECTED_COMPLETE_TABLE` セクションで DB を検証 | スキップ |
+| `expectedMessage` | この値と同じ groupId を持つ要求電文セクション（`EXPECTED_REQUEST_HEADER/BODY_MESSAGES`）で検証 | スキップ |
+| `responseMessage` | この値と同じ groupId を持つ応答電文セクション（`RESPONSE_HEADER/BODY_MESSAGES`）をレスポンスとして返す | スキップ |
+| `expectedLog` | 期待ログの `LIST_MAP` 名。指定した LIST_MAP が空の場合はエラー | スキップ |
+
+### 記述例
+
+#### Excel
+
+| LIST_MAP=testShots | | | | | | | |
+|---|---|---|---|---|---|---|---|
+| no | description | expectedStatusCode | diConfig | requestPath | userId | expectedMessage | responseMessage |
+| 1 | 電文送受信テスト | 0 | batch-test-component-configuration.xml | BM21AA0106 | batch_user | case1 | res_case1 |
+
+#### YAML
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "電文送受信テスト"
+ expectedStatusCode: "0"
+ diConfig: "batch-test-component-configuration.xml"
+ requestPath: "BM21AA0106"
+ userId: "batch_user"
+ expectedMessage: "case1"
+ responseMessage: "res_case1"
+```
+
+---
+
+
+
+## エンティティバリデーション（EntityTestSupport）
+
+[共通カラム](#common)とは別体系。`no`／`description`／`expectedStatusCode` は使わない。
+
+### 必須カラム
+
+| カラム名 | 説明 |
+|---|---|
+| `title` | テストケースの説明 |
+| `expectedMessageId1` | 期待するバリデーションメッセージ ID（複数ある場合は `expectedMessageId2`, `expectedMessageId3`, ... と連番で追加） |
+| `propertyName1` | バリデーション対象プロパティ名（同上、連番で追加可能） |
+
+### 関連予約 ID
+
+| 予約 ID | 説明 |
+|---|---|
+| `params` | 入力パラメータ定義。`testShots` の行数と一致が必須 |
+
+### 記述例
+
+#### Excel
+
+| LIST_MAP=testShots | | | |
+|---|---|---|---|
+| title | expectedMessageId1 | propertyName1 | |
+| 必須チェック | errors.required | userName | |
+
+#### YAML
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - title: "必須チェック"
+ expectedMessageId1: "errors.required"
+ propertyName1: "userName"
+```
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-doc.md b/.rn/ntf-yaml-support/input/ntf-testdata-doc.md
new file mode 100644
index 00000000..9a1a424c
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-doc.md
@@ -0,0 +1,699 @@
+# NTF テストデータ リファレンス
+
+Nablarch Testing Framework（NTF）が読み込むテストデータの記述仕様。Excel・YAML のどちらで書く場合にも共通して適用される。各節末尾のリンクから Excel 表と YAML コードブロックの対比例を参照できる。
+
+---
+
+## 目次
+
+1. [全体像](#1-全体像)
+2. [テストデータの基本構造](#2-テストデータの基本構造)
+3. [データブロック識別](#3-データブロック識別)
+4. [テストケース定義](#4-テストケース定義)
+5. [テーブルデータ](#5-テーブルデータ)
+6. [ファイルデータ](#6-ファイルデータ)
+7. [メッセージングテストデータ](#7-メッセージングテストデータ)
+8. [値の書き方](#8-値の書き方)
+9. [ディレクティブ](#9-ディレクティブ)
+10. [ヘッダ・コメント・空エントリ](#10-ヘッダコメント空エントリ)
+
+---
+
+## 1. 全体像
+
+テストコード（Java）がテストデータファイルを読み込み、DB へのデータ投入・入力ファイルの配置・期待値との比較を行う。テストデータには **テストケース**・**セットアップ**・**検証** の3用途のデータを記述し、いずれも **データブロック** 単位で管理する。
+
+| 用途 | 内容 | 主なデータブロック |
+|---|---|---|
+| テストケース | 1エントリ1ケースの実行条件（ウェブ:「ユーザ ID・期待ステータスコード・期待フォワード先 URI」、バッチ:「リクエストパス・ユーザ ID・DI コンフィグ・期待ステータスコード」など） | `LIST_MAP=testShots` |
+| セットアップ | テスト前に投入するデータ（DB INSERT、固定長・可変長ファイルの入力） | `SETUP_TABLE` / `SETUP_FIXED` / `SETUP_VARIABLE` |
+| 検証 | テスト後の期待値（DB・出力ファイル・電文・ログ・検索結果） | `EXPECTED_*` / `RESPONSE_*` |
+
+データの格納階層は次のとおり。テストクラス1つ分のデータが読み込み単位（Excel は1シート／YAML は1ファイル）に分かれ、その中に複数のデータブロックが共存する。
+
+```mermaid
+flowchart TD
+ TC[テストクラス
Excel: 1ブック / YAML: 1ディレクトリ] --> U1[読み込み単位
Excel: 1シート / YAML: 1ファイル]
+ TC --> U2[読み込み単位]
+ U1 --> B1[データブロック
種別 + 識別子]
+ U1 --> B2[データブロック]
+ B1 --> F[レコード定義 / フィールド / データ]
+```
+
+データブロックは **種別**（`SETUP_TABLE` など14種）と **識別子の値**（テーブル名・ファイルパス・ID など）の組み合わせで区別する。詳細は [3章](#3-データブロック識別)。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-overview.md#overview)
+
+---
+
+## 2. テストデータの基本構造
+
+テストデータはテストクラスと1対1で対応する。
+
+| 形式 | テストクラス対応 | 読み込み単位 |
+|---|---|---|
+| Excel | 同名の1ブック（`.xls`） | 1シート |
+| YAML | 同名のディレクトリ | 1ファイル（Excel の1シートに相当） |
+
+```
+【Excel】 【YAML】
+src/test/java/com/example/ src/test/java/com/example/
+ FooTest.xls FooTest/
+ ├── case01 ← シート ├── case01.yaml ← ファイル
+ └── case02 ← シート └── case02.yaml ← ファイル
+```
+
+1読み込み単位の中に、テストケース・セットアップ・検証の複数データブロックを共存させて記述する。
+
+YAML ファイルは **YAML 1.2** に準拠する。YAML 1.1 との主な違いとして、`yes` / `no` / `on` / `off` は真偽値ではなく文字列として扱われる。
+
+### ファイルの読み込みルール
+
+| 項目 | Excel | YAML |
+|---|---|---|
+| ファイルなし時 | エラー | ファイルが存在しない、またはパース失敗時はエラー |
+| 空ファイル時 | 空シートは存在しないシート扱い | 空ファイル（0バイト）は空データ扱い（エラーにならない） |
+| 値の書き方 | セルは必ず**文字列書式**。数値・日付書式の動作は保証しない | 値は必ず**ダブルクォートで囲む** |
+
+---
+
+## 3. データブロック識別
+
+### 3.1 識別の構成要素
+
+各データブロックは **データブロック種別**（[3.2](#32-データブロック種別の一覧) の14種）と **識別子の値**（テーブル名・ファイルパス・ID など）の2要素で識別される。
+
+| 形式 | 記述方法 |
+|---|---|
+| Excel | データブロック先頭セルに `データブロック種別=識別子の値`。種別名で始まれば合致（前方一致）。例: `SETUP_TABLE=USER_MASTER` |
+| YAML | 種別ごとの専用トップレベルキー（下表）。完全一致のため前方一致は発生しない |
+
+YAML のトップレベルキー対応:
+
+| データブロック種別 | YAML キー |
+|---|---|
+| `SETUP_TABLE` | `setup_tables` |
+| `EXPECTED_TABLE` | `expected_tables` |
+| `EXPECTED_COMPLETE_TABLE` | `expected_complete_tables` |
+| `LIST_MAP` | `list_maps` |
+| `SETUP_FIXED` / `SETUP_VARIABLE` | `setup_files` |
+| `EXPECTED_FIXED` / `EXPECTED_VARIABLE` | `expected_files` |
+| `MESSAGE` | `messages` |
+| `EXPECTED_REQUEST_HEADER_MESSAGES` | `expected_request_header_messages` |
+| `EXPECTED_REQUEST_BODY_MESSAGES` | `expected_request_body_messages` |
+| `RESPONSE_HEADER_MESSAGES` | `response_header_messages` |
+| `RESPONSE_BODY_MESSAGES` | `response_body_messages` |
+
+```yaml
+setup_tables:
+ - table: USER_MASTER
+ rows: ...
+```
+
+**同種データブロックの記述ルール**:
+
+- YAML: 同一ファイル内のトップレベルキーの重複は禁止。同種データは同一キーにリストとして並べる（重複時はエラー）
+- Excel: 同一シート内に同種データブロックを複数記述できる。DataType により全件収集または先着一致で収集される（[3.3](#33-同一ファイルシート内に複数のデータブロックを書く場合の注意) 参照）
+
+### 3.2 データブロック種別の一覧
+
+使用できる種別は以下の14種。
+
+| データブロック種別 | 用途 | 同一 ID が複数ある場合 |
+|---|---|---|
+| `SETUP_TABLE` | INSERT 用テーブルデータ | 同じグループのものをすべて収集 |
+| `EXPECTED_TABLE` | 比較用テーブルデータ（省略カラムは比較対象外） | 同じグループのものをすべて収集 |
+| `EXPECTED_COMPLETE_TABLE` | 比較用テーブルデータ（省略カラムにデフォルト値補完） | 同じグループのものをすべて収集 |
+| `LIST_MAP` | キーバリュー形式の汎用データ（テストケース定義・期待値等） | 最初の1件のみ有効（2件目以降は無視） |
+| `SETUP_FIXED` | 固定長ファイルの入力データ | 同じグループのものをすべて収集 |
+| `EXPECTED_FIXED` | 固定長ファイルの期待値データ | 同じグループのものをすべて収集 |
+| `SETUP_VARIABLE` | 可変長ファイルの入力データ | 同じグループのものをすべて収集 |
+| `EXPECTED_VARIABLE` | 可変長ファイルの期待値データ | 同じグループのものをすべて収集 |
+| `MESSAGE` | メッセージング電文データ | 最初の1件のみ有効（2件目以降は無視） |
+| `EXPECTED_REQUEST_HEADER_MESSAGES` | 要求電文ヘッダの期待値 | groupId 指定時は全件収集、ID 直接指定時は最初の1件 |
+| `EXPECTED_REQUEST_BODY_MESSAGES` | 要求電文ボディの期待値 | groupId 指定時は全件収集、ID 直接指定時は最初の1件 |
+| `RESPONSE_HEADER_MESSAGES` | 応答電文ヘッダデータ | groupId 指定時は全件収集、ID 直接指定時は最初の1件 |
+| `RESPONSE_BODY_MESSAGES` | 応答電文ボディデータ | groupId 指定時は全件収集、ID 直接指定時は最初の1件 |
+| `DEFAULT` | フレームワーク内部用（通常使用しない） | — |
+
+### 3.3 同一ファイル（シート）内に複数のデータブロックを書く場合の注意
+
+- **複数テーブルの INSERT**: `setup_tables` などの全件収集タイプは同一 groupId のものをすべて収集する。複数テーブルデータを並べて記述できる
+- **データタイプの混在順序（YAML）**: YAML はトップレベルのセクションキー（`expected_tables` / `expected_complete_tables` 等）ごとに独立して取得する。記述順序や異なるセクションの交互記述に関わらず正しく読み込まれる
+- **`LIST_MAP` / `MESSAGE` の重複 ID**: 同一 ID が複数ある場合は最初の1件のみ有効。2件目以降は無視
+
+> **Excel との違い**: Excel（旧形式）は行を順に読む方式のため、同一シート内で別のデータタイプを挟むと後半が読み込まれない制約があった（解説書の旧 Doc-4）。YAML はセクションキーで構造化されるためこの制約はなく、移行時にデータタイプごとにまとめ直す必要はない。
+
+グループの指定方法（groupId）は [4.3](#43-データブロックのグループ化groupid) を参照。
+
+---
+
+## 4. テストケース定義
+
+### 4.1 testShots
+
+`testShots` はテストケース定義の予約 ID。フレームワークがこの ID を自動的に読み込み、各エントリを1テストケースとして実行する。旧称 `testCases` も動作するが、新規作成では `testShots` を使う。
+
+- テスト実行には `testShots` に1件以上のエントリが必要（0件はエラー）
+- **Excel**: `LIST_MAP=testShots` データブロックに記述
+- **YAML**: `list_maps:` 下の `id: testShots` エントリに記述
+
+### 4.2 testShots のカラム仕様
+
+カラムは処理方式によって異なる。各処理方式の詳細は以下を参照。
+
+- [ウェブアプリケーション（HttpRequestTestSupport）](ntf-testdata-doc-examples-testshots.md#web)
+- [バッチ処理（BatchRequestTestSupport）](ntf-testdata-doc-examples-testshots.md#batch)
+- [メッセージング（MessagingRequestTestSupport）](ntf-testdata-doc-examples-testshots.md#messaging)
+- [エンティティバリデーション（EntityTestSupport）](ntf-testdata-doc-examples-testshots.md#entity)
+
+### 4.3 データブロックのグループ化（groupId）
+
+複数のテストケースで異なるセットアップデータや期待値を使い分けたい場合、データブロックに **groupId** を付加してグループ化する。`testShots` の各カラム（`setUpTable` / `expectedTable` / `setUpFile` / `expectedFile` 等）に groupId の値を指定すると、そのテストケースでは対応する groupId を持つデータブロックだけが収集される。
+
+| 形式 | 記述方法 |
+|---|---|
+| Excel | DataType 名の直後に `[groupId]`。例: `SETUP_TABLE[case01]=USER_MASTER` |
+| YAML | `group_id:` フィールド |
+
+```yaml
+setup_tables:
+ - group_id: case01
+ table: USER_MASTER
+ rows: ...
+```
+
+**制約**:
+
+- `testShots` の各カラムで groupId を省略すると、groupId なしのデータブロック（デフォルトグループ）が収集される
+- バッチ固有の動作として groupId に `"default"` を指定すると groupId なし扱いと同等になる（HTTP テスト・メッセージングテストでは適用されない）
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-overview.md#groupid)
+
+---
+
+## 5. テーブルデータ
+
+### 5.1 データの形式
+
+各エントリはカラム名と値の組み合わせで記述する。省略したカラムには INSERT 時にデフォルト値が補完される。
+
+**Excel**: 1行目にカラム名、2行目以降にデータ。
+
+```
+| SETUP_TABLE=テーブル名 | | |
+| カラム1 | カラム2 | カラム3 |
+| 値1 | 値2 | 値3 |
+```
+
+**YAML**: `rows:` 配列に各行をオブジェクトで記述。
+
+```yaml
+setup_tables:
+ - table: テーブル名
+ rows:
+ - カラム1: "値1"
+ カラム2: "値2"
+ カラム3: "値3"
+```
+
+**YAML 必須キー**: `setup_tables` / `expected_tables` / `expected_complete_tables` の各エントリには `table` キーが必須（省略時エラー）。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-table.md#table-data)
+
+### 5.2 SETUP_TABLE
+
+DB への INSERT 用データ。
+
+- 各エントリのカラム名と値を記述する
+- **主キーカラムは省略しない**。省略すると型に応じたデフォルト値（数値型は `"0"`、文字型はスペース等）が INSERT される
+
+**null 値・空文字の動作**:
+
+| 値の指定 | Excel | YAML |
+|---|---|---|
+| null（Java null） | セルに `null`（大文字小文字不問） | アンクォートの `null`（`"null"` でも同結果） |
+| 空文字 | セルを空にする | `""` |
+| 日付型カラムの空文字 | セルを空にする → `null` 扱い | `""` → `null` 扱い |
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-table.md#setup-table)
+
+### 5.3 EXPECTED_TABLE
+
+テスト後の DB 状態と比較するデータ。
+
+- **省略したカラムは比較対象外**。検証したいカラムだけを列挙できる
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-table.md#expected-complete-table)
+
+### 5.4 EXPECTED_COMPLETE_TABLE
+
+省略カラムにデフォルト値を補完してから比較するデータ。
+
+| カラム型 | デフォルト値 |
+|---|---|
+| 数値型 | `"0"` |
+| 固定長文字列型（CHAR, NCHAR） | 半角スペース × カラム長 |
+| 可変長文字列型（VARCHAR 等） | `" "`（半角スペース1文字） |
+| 日付型 | epoch 起点（JVM タイムゾーン依存。JST 環境では `"1970-01-01 09:00:00.0"`） |
+| バイナリ型 | 10バイトのゼロバイト列の HexString |
+| Boolean 型 | `"false"` |
+
+**注意**: DATE カラムのデフォルト値は JVM のタイムゾーン設定に依存する。JST 環境と UTC 環境では値が異なる。
+
+**Excel 混在禁止**: Excel では `EXPECTED_TABLE` と `EXPECTED_COMPLETE_TABLE` を同一シート内で混在させると後半のデータが読み込まれない。同じ種別をまとめて記述する。YAML では `expected_tables` と `expected_complete_tables` は別キーのため混在可能。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-table.md#expected-complete-table)
+
+### 5.5 LIST_MAP
+
+キーバリュー形式の汎用データ。テストケース定義（`testShots`）・リクエストパラメータ・期待値オブジェクト・期待ログなど様々な用途で使う。
+
+**Excel**:
+
+```
+| LIST_MAP=testShots | | |
+| no | description | status |
+| 1 | 正常系 | active |
+| 2 | 異常系 | error |
+```
+
+**YAML**:
+
+```yaml
+list_maps:
+ - id: testShots
+ rows:
+ - no: "1"
+ description: "正常系"
+ status: "active"
+ - no: "2"
+ description: "異常系"
+ status: "error"
+```
+
+- ID は完全一致で検索される
+- 同一ファイル内で同一 ID の重複エントリは先着一致、2件目以降は無視
+- 指定 ID のエントリが存在しない場合は空データ扱い（エラーにならない）
+
+主な予約 ID は [4章](#4-テストケース定義) を参照。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-table.md#list-map)
+
+---
+
+## 6. ファイルデータ
+
+### 6.1 固定長・可変長の統合
+
+セットアップ用ファイルデータ（`SETUP_FIXED` / `SETUP_VARIABLE`）は固定長・可変長の区別なくまとめて収集される。期待値ファイル（`EXPECTED_FIXED` / `EXPECTED_VARIABLE`）も同様。固定長か可変長かはデータブロック内の記述で区別される。
+
+**YAML 必須キー**: `setup_files` / `expected_files` の各エントリには `path` キーが必須（省略時エラー。`table` キーと同様）。
+
+### 6.2 ファイルデータブロックの構造
+
+ファイルデータブロックは次の順序で記述する。
+
+```mermaid
+flowchart TD
+ D["ディレクティブ（0件以上）
エンコーディング等のファイル属性"] --> N["レコード種別 + フィールド名称
先頭要素=レコード種別、以降=フィールド名称"]
+ N --> T["データ型（各フィールドの型記号）"]
+ T --> L["フィールド長（固定長のみ）
各フィールドのバイト長"]
+ L --> R["データ（1件以上）"]
+```
+
+**Excel 固有の制約**: データの先頭要素は必ず空（null または空文字）にする。YAML にこの制約はない。
+
+**Excel の記述例**（各セルを `|` で区切って表示）:
+
+```
+行1: SETUP_FIXED=work/input.txt [空] [空]
+行2: text-encoding MS932 [空]
+行3: DATA USER_ID AMOUNT
+行4: [空] 半角 数値
+行5: [空] 10 10
+行6: [空] 001 5000
+```
+
+**YAML の記述例**:
+
+```yaml
+setup_files:
+ - path: work/input.txt
+ type: fixed
+ directives:
+ text-encoding: MS932
+ records:
+ - record_type: DATA
+ fields:
+ - {name: USER_ID, type: 半角, length: 10}
+ - {name: AMOUNT, type: 数値, length: 10}
+ rows:
+ - ["001", "5000"]
+```
+
+- `fields:` の各要素は `{name: フィールド名, type: データ型, length: バイト長}` の形式
+- **`type` は日本語型名称（`半角`, `全角`, `数値` 等）で記述する**（[8.10](#810-データ型マッピング) 参照）。Excel と同じ表記であり、変換ツールも Excel の型名称をそのまま出力する
+- `length` は整数（`length: 10`）または文字列（`length: "10"`）どちらでも有効。変換ツールが生成した YAML は文字列形式（`"10"`）
+- `rows:` の各行は配列形式で、`fields:` と**同じ順序・同じ件数**で値を並べる
+- `rows:` 内の値はダブルクォートで囲む（[8章](#8-値の書き方) 参照）
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-file.md#file-data)
+
+### 6.3 固定長ファイル固有の仕様
+
+- フィールド名称・データ型・フィールド長の3リストが同サイズで必須
+- 1ファイルデータブロック内の全レコード定義は同一レコード長でなければならない（違反時エラー）
+- フィールド値がフィールド長を超えた場合はエラー
+
+### 6.4 可変長ファイル固有の仕様
+
+- フィールド名称・データ型の2リストが同サイズで必須。フィールド長は不要
+- **空エントリの動作**: ファイルデータの空エントリ（先頭フィールドが空の行）はデータ行として扱われる。可変長は全フィールドが `""` のレコードとして保持され、固定長はスペースパディングされた定長レコードとして書き出される（テーブルデータの空行スキップとは異なる。[10.5](#105-空エントリのスキップ) 参照）
+
+### 6.5 複数レコードレイアウト
+
+1ファイルデータブロック内に複数のレコードレイアウトを連続して記述できる。データの後ろに新たなレコード種別とフィールド名称を書くと、新しいレコードレイアウトとして扱われる。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-file.md#multi-record)
+
+### 6.6 空ファイル
+
+0バイトの空ファイルを表現するには、ディレクティブのみを記述してレコード定義を省略する。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-file.md#empty-file)
+
+### 6.7 `"-"` 長フィールド
+
+フィールド長に `"-"` を指定すると、追加された全レコードの最大バイト長に自動拡張される。値は改行コードと前後空白が除去される。
+
+### 6.8 エラーになるケース
+
+- 同一レコード種別内でフィールド名称が重複している
+- フィールド名称リストまたはデータ型リストが未指定または空
+- フィールド名称・データ型・フィールド長リストのサイズが一致していない
+- 存在しないフィールド名称を指定している
+- データ要素数が不正
+- ディレクティブまたはレコード種別/フィールド名称定義の要素数が2未満
+- ファイルの読み込みに失敗した（IO エラー）
+- 日付型カラムの値が日付として解析できない
+
+---
+
+## 7. メッセージングテストデータ
+
+### 7.1 sendSyncTestData の配置規則
+
+テストデータファイルは `sendSyncTestData/{requestId}/message` というパスに配置する（末尾の `message` は固定のパスセグメント）。
+
+- **Excel**: `MESSAGE=sendSyncTestData/{requestId}/message` をデータブロック識別子として記述
+- **YAML**: `messages:` の `id:` に `sendSyncTestData/{requestId}/message` を指定
+
+### 7.2 FW 制御ヘッダフィールド
+
+> **適用範囲**: `fw_header:` マップは `messages`（MESSAGE: MockMessaging 経路の要求/応答電文）でのみ使用する。`expected_request_header_messages` / `expected_request_body_messages` / `response_header_messages` / `response_body_messages` の4種では使用しない。これらは `requestId` 等のヘッダフィールドも含めて `records` の `fields:`/`rows:` にフィールド単位（型・長さつき）で記述する（[7.x EXPECTED/RESPONSE 系の記述](#) 参照）。両者はテスト手法が異なる（値の指定 か フィールド単位の検証/生成 か）ため表現も異なる。
+
+FW 制御ヘッダのフィールド名は**プロジェクトごとに異なる**。フレームワーク標準では4種が既定値だが固定ではなく、`SystemRepository` の `reader.fwHeaderfields` キーでプロジェクトが任意の名前に変更できる（例: `reader.fwHeaderfields=requestId,addHeader`）。
+
+- 既定値の例: `requestId`, `userId`, `resendFlag`, `resultCode`
+
+| 形式 | 記述方法 |
+|---|---|
+| Excel | フィールド名称行（`no` 行）より前に `| フィールド名 | 値 |`（ディレクティブと同じ「名前｜値」形式） |
+| YAML | `fw_header:` マップ（キー: 値）。キー名は固定でなく任意（`reader.fwHeaderfields` 設定に合わせる） |
+
+```yaml
+messages:
+ - id: requestMessages
+ directives:
+ text-encoding: Windows-31J # ディレクティブはここに書く
+ fw_header: # FW制御ヘッダは名前: 値のマップ（キーは任意）
+ requestId: hoge
+ userId: moge
+ records:
+ - record_type: default # MessageParser は record_type を無視する（7.10 参照）
+ fields:
+ - {name: ユーザ名, type: 全角, length: 50}
+ - {name: 備考, type: 全角, length: 200}
+ - {name: FILLER, type: 半角, length: 252}
+ rows:
+ - ["電文太郎", "特筆なし", ""]
+```
+
+- **`directives:`（`text-encoding` 等）と `fw_header:`（`requestId` 等）は別キー。** Excel ではどちらも「名前｜値」の行だが、FW 制御ヘッダはフレームワークが電文ヘッダとして分離して扱うため YAML では区別する
+- **`fw_header:` のキーはすべて FW 制御ヘッダとして扱われる。** ランタイムは `fw_header:` マップをそのまま FW ヘッダとして使い、`reader.fwHeaderfields` でフィルタリングして取り捨てることはしない（記述したものが黙って消えない）
+- 電文ボディのフィールドは従来どおり `records:` の `fields:`/`rows:` に記述する
+
+### 7.3 HEADER / BODY MESSAGES の構造と件数制約
+
+- `EXPECTED_REQUEST_HEADER_MESSAGES` と `EXPECTED_REQUEST_BODY_MESSAGES` のエントリ数（rows 合計）は一致が必須（不一致時エラー）
+- HTTP 同期応答メッセージ（`response_body_messages`）の各データエントリは文字列長が同一である必要がある
+
+### 7.4 no 行（フィールド名称行）と errorMode
+
+**電文の行構造**: ディレクティブ群・FW 制御ヘッダの後、`no` で始まる行がフィールド名称行。以降、データ型行・フィールド長行・データ行が続く（公式仕様の電文表書式に準拠）。
+
+- **Excel**: フィールド名称行の先頭セルに `no` を記述。データ行の先頭セル（`no` カラム）はフレームワークが除去しデータとして保存しない
+- **YAML**: フィールド名称は `fields:`、データは `rows:` に記述（`no` カラム自体は YAML の構造に現れない）
+
+**errorMode（RESPONSE 系・MockMessaging 経路のみ）**:
+
+- `response_header_messages` / `response_body_messages` で、データ行の先頭値が `errorMode:timeout` または `errorMode:msgException` の場合、そのエントリは送受信エラーをシミュレートするマーカーとして扱われる
+- errorMode 行は `fw_header:` の分離とは独立した別の仕組み。`fw_header:` を分離した後も errorMode 行はそのまま機能する
+- `RequestTestingSendSyncSupport` 経路（GroupMessageParser）では errorMode は使用されない
+
+### 7.5 複数回送信
+
+N 回送信する場合は、ヘッダ件数とボディ件数をともに N 件ずつ記述する。同一リクエスト ID で複数回送信する場合は `no` 値を変えて連続記述し、送信順序と `no` 値を一致させる。
+
+### 7.6 メッセージの groupId 収集
+
+同一 groupId を持つ複数のメッセージプールを収集する。識別子の値をリクエスト ID として使用する。
+
+### 7.7 ステータスコード
+
+ステータスコードカラムがない場合はデフォルト値 `"200"` が使用される。Excel・YAML 両方で共通。
+
+### 7.8 フォーマット定義ファイルの命名規則
+
+- 応答電文: `{requestId}_RECEIVE`
+- 要求電文: `{requestId}_SEND`
+
+### 7.9 アサート方式の切り替え
+
+`SystemRepository` の `messaging.assertAsMapFileType` キーの設定値に応じてアサート方式が切り替わる。未設定時のデフォルトは `"Fixed"` 形式（項目単位アサート）。
+
+### 7.10 record_type の扱い
+
+`messages` / `expected_request_*_messages` / `response_*_messages` の `record_type` 値は、フレームワーク内部で常に `"default"` に置き換えられる。
+
+- **Excel**: フィールド名称行の先頭セルに任意の値を記述できる（装飾的なメタデータ扱い）
+- **YAML**: `record_type:` に任意の値を記述できる（可読性のためだけで実行時挙動に影響しない）
+
+> **注意**: 旧版では FW 制御ヘッダを `record_type: FW_HEADER` のレコードとして表していたが、本仕様では FW 制御ヘッダは `fw_header:` マップで記述する（[7.2](#72-fw-制御ヘッダフィールド) 参照）。`record_type` に特別な予約値はない。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-messaging.md#messaging)
+
+---
+
+## 8. 値の書き方
+
+### 8.1 値の種類と Excel / YAML 対比
+
+| 値の種類 | Excel での記述 | YAML での記述 | 備考 |
+|---|---|---|---|
+| 通常の文字列 | `abc` | `"abc"` | YAML はクォート必須（型変換防止） |
+| null（DB に null を格納） | `null`（大文字小文字不問） | `null`（クォートなし） | YAML の `"null"`（クォートあり）も同結果 |
+| 空文字 | 空セル | `""` | |
+| 先頭ゼロ付き数値 | `001` | `"001"` | YAML でクォートなしだと `1` に型変換される |
+| `true` / `false`（文字列） | `true` | `"true"` | YAML でクォートなしだと真偽値に型変換される |
+| 半角スペース1文字 | `" "`（セルに `"` space `"` と入力） | `" "` | 外側クォートが除去されてスペースになる |
+| ダブルクォート1文字 | `"""`（セルに `"` `"` `"` と入力） | `'"'`（YAML シングルクォート） | |
+| 日時プレースホルダ | `${systemTime}` | `"${systemTime}"` | 完全一致のみ変換。[8.4](#84-datetimeinterpreter-の完全一致制約) 参照 |
+| バイナリファイル参照 | `${binaryFile:path}` | `"${binaryFile:path}"` | パスはどちらもデータファイルのディレクトリ基準。[8.6](#86-binaryfileinterpreter-のパス基準) 参照 |
+| 文字種生成 | `${半角英字,10}` | `"${半角英字,10}"` | [8.5](#85-文字種生成の有効文字種) 参照 |
+| 改行文字（CR） | `\\r` | `"\\r"` | LineSeparatorInterpreter が変換（デフォルト設定は CR のみ） |
+
+**YAML のクォートルール**:
+
+- `rows:` 内のすべてのデータ値は**必ずダブルクォートで囲む**。クォートなしだと SnakeYAML が数値・真偽値に型変換する
+- `null` のみクォートなしで記述（ただし `"null"` でも同じく Java null になる）
+- `type:`, `record_type:`, `path:` 等のスキーマ構造値はクォート不要
+
+**Excel のセル書式**: セルは必ず**文字列書式**で記述する。数値・日付書式の動作は保証されない。
+
+### 8.2 インタープリタチェーンの仕組み
+
+テストデータの値はパース時にインタープリタチェーンを通過して変換される。DI 設定で注入されたインタープリタが順番に適用される。
+
+### 8.3 インタープリタ一覧
+
+| インタープリタ | 変換内容 |
+|---|---|
+| `NullInterpreter` | `null` / `NULL` / `Null`（大文字小文字不問）→ Java null |
+| `QuotationTrimmer` | 半角または全角ダブルクォートで前後が囲まれた場合のみ外側1層を除去 |
+| `DateTimeInterpreter` | `${systemTime}` / `${updateTime}` / `${setUpTime}` の完全一致のみ変換 |
+| `LineSeparatorInterpreter` | `\\r` → CR（0x0D）に変換（デフォルト設定）。`setMatchPattern` / `setLineSeparator` で変換対象・変換後の改行コードを変更可能 |
+| `BinaryFileInterpreter` | `${binaryFile:パス}` でファイル内容をバイナリ読み込みし HexString に変換。パスはデータファイル（Excel / YAML）のディレクトリからの相対パス |
+| `BasicJapaneseCharacterInterpreter` | `${文字種,文字数}` 形式で文字列生成 |
+| `CompositeInterpreter` | 文字列中の `${...}` 要素を個別解釈して置換 |
+
+### 8.4 DateTimeInterpreter の完全一致制約
+
+`DateTimeInterpreter` は完全一致のみ変換する。部分文字列は変換されない。文字列中の `${...}` を置換するには `CompositeInterpreter` との組み合わせが必要。
+
+### 8.5 文字種生成の有効文字種
+
+14種類の文字種が使用できる: 半角英字 / 半角数字 / 半角記号 / 半角カナ / 全角英字 / 全角数字 / 全角ひらがな / 全角カタカナ / 全角漢字 / 全角記号その他 / 中国語 / サロゲートペア / 改行 / 外字。
+
+上記以外の文字種を指定するとエラーになる。
+
+### 8.6 BinaryFileInterpreter のパス基準
+
+`${binaryFile:パス}` のパスは**テストデータファイルのディレクトリ**からの相対パス。Excel・YAML 両方で同じ動作。
+
+| 形式 | 基準ディレクトリ |
+|---|---|
+| Excel | Excel ファイル（`.xls` / `.xlsx`）が置かれているディレクトリ |
+| YAML | YAML ファイル（`.yaml`）が置かれているディレクトリ |
+
+### 8.7 日付型カラムの記述形式と境界値
+
+有効な記述形式:
+
+- `yyyyMMddHHmmssSSS`（17文字）
+- 後置0埋め短縮形
+- JDBC タイムスタンプエスケープ形式（5文字目が `-`）
+
+`java.sql.Timestamp` 型カラムの期待値は末尾 `.0` が必須（例: `"2010-01-01 12:34:56.0"`）。末尾 `.0` がないとアサートが失敗する。
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-special.md#datetime)
+
+### 8.8 バイナリデータの記述
+
+`0x` プレフィクス付き16進数で記述できる。`0x` がない場合は文字列としてエンコードされる。
+
+### 8.9 X9/SX9 型フィールドの記述
+
+パディング文字・符号を含めた実際のバイト列表現（固定長フォーマットの実値）をそのまま記述する。
+
+### 8.10 データ型マッピング
+
+フィールドのデータ型は以下の日本語型名称で指定する。使用できない型名称を指定するとエラーになる。
+
+| 型名称 | 型記号 | 用途 |
+|---|---|---|
+| `半角英字` / `半角数字` / `半角記号` / `半角カナ` / `半角英数字` / `半角英数字記号` / `半角` | `X` | 半角文字 |
+| `全角英字` / `全角数字` / `全角ひらがな` / `全角カタカナ` / `全角漢字` / `全角` | `N` | 全角文字 |
+| `全半角` | `XN` | 全角・半角混在 |
+| `数値` / `符号無ゾーン10進数` | `Z` | ゾーン10進数（符号なし） |
+| `符号付ゾーン10進数` | `SZ` | ゾーン10進数（符号あり） |
+| `符号無パック10進数` | `P` | パック10進数（符号なし） |
+| `符号付パック10進数` | `SP` | パック10進数（符号あり） |
+| `符号無数値` | `X9` | バイナリ表現の数値（符号なし） |
+| `符号付数値` | `SX9` | バイナリ表現の数値（符号あり） |
+| `バイナリ` | `B` | バイナリデータ |
+
+`TEST_{型名称}` という名前のデータ型を定義すると、同名の基底型より優先して使用される（テスト専用の型定義に使う）。
+
+---
+
+## 9. ディレクティブ
+
+### 9.1 ディレクティブの構成
+
+ディレクティブは「キー名・値」の2要素で記述する（最低2要素必要）。
+
+- **Excel**: ファイルデータブロックの先頭（レコード定義より前）に `| キー名 | 値 |` の形で記述
+- **YAML**: `directives:` オブジェクトに `key: value` 形式で記述
+
+### 9.2 固定長ファイルのディレクティブ
+
+有効なキーは以下に限定される。無効なキーを指定するとエラーになる。
+
+| ディレクティブキー | 説明 |
+|---|---|
+| `file-type` | 自動設定（`"Fixed"`）。通常は記述不要 |
+| `text-encoding` | ファイルの文字エンコーディング |
+| `record-length` | フィールド長合計から自動計算。通常は記述不要 |
+| `record-separator` | レコード区切り文字 |
+| `positive-zone-sign-nibble` | ゾーン10進数の正符号ニブル |
+| `negative-zone-sign-nibble` | ゾーン10進数の負符号ニブル |
+| `positive-pack-sign-nibble` | パック10進数の正符号ニブル |
+| `negative-pack-sign-nibble` | パック10進数の負符号ニブル |
+| `required-decimal-point` | 小数点を必須とするか（`true` / `false`） |
+| `fixed-sign-position` | 符号を固定位置に置くか（`true` / `false`） |
+| `required-plus-sign` | 正符号を出力するか（`true` / `false`） |
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-file.md#file-data)
+
+### 9.3 可変長ファイルのディレクティブ
+
+有効なキーは以下に限定される。無効なキーを指定するとエラーになる。
+
+| ディレクティブキー | 説明 |
+|---|---|
+| `file-type` | 自動設定（`"Variable"`）。通常は記述不要 |
+| `text-encoding` | ファイルの文字エンコーディング |
+| `record-separator` | レコード区切り。`NONE` / `CR` / `LF` / `CRLF` または任意リテラル文字列が有効 |
+| `field-separator` | フィールド区切り文字。デフォルトは `","`。`"\\t"` 指定でタブ文字。**1文字のみ有効**（2文字以上はエラー） |
+| `quoting-delimiter` | クォート文字 |
+| `ignore-blank-lines` | 空行を無視するか |
+| `requires-title` | タイトル行の有無 |
+| `max-record-length` | レコードの最大長 |
+| `title-record-type-name` | タイトルレコードの種別名 |
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-file.md#file-data)
+
+### 9.4 デフォルトディレクティブの DI 設定
+
+`SystemRepository` への DI 設定で、全ファイル共通または種別専用のデフォルトディレクティブを一括設定できる。
+
+| DI キー | 適用対象 |
+|---|---|
+| `defaultDirectives` | 全ファイル共通のデフォルト |
+| `fixedLengthDirectives` | 固定長ファイル専用。`defaultDirectives` より後に上書き適用される |
+| `variableLengthDirectives` | 可変長ファイル専用 |
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-special.md#directive)
+
+---
+
+## 10. ヘッダ・コメント・空エントリ
+
+### 10.1 ヘッダの構造
+
+ヘッダにはカラム名を列挙する。
+
+- ヘッダ末尾の空カラムは除去される（末尾カラムの省略が可能）
+- データエントリがヘッダより少ない場合、不足分は空文字 `""` で補完される
+
+### 10.2 マーカーカラム
+
+カラム名が `[カラム名]` 形式（角括弧で囲まれた名前）のカラムはマーカーカラムとして扱われ、DB 操作から除外される。
+
+| 形式 | 除外対象 |
+|---|---|
+| Excel | `SETUP_TABLE` / `EXPECTED_TABLE` / `LIST_MAP` すべて |
+| YAML | `setup_tables` / `expected_tables` / `list_maps` すべて |
+
+### 10.3 エントリ単位のコメント
+
+エントリをコメントとしてマークすると、そのエントリ全体がスキップされる。
+
+- **Excel**: 先頭要素が `//` で始まる行はスキップされる
+- **YAML**: `#` がコメント記号（行頭・行末どちらにも使える）
+
+### 10.4 要素途中からのコメント（Excel 固有）
+
+- **Excel**: 先頭以外の要素が `//` で始まる場合、その要素以降が切り捨てられる
+- **YAML**: `#` を行末に書いて同等の記述ができる（例: `NUMBER_COL: "100" # 数値カラム`）
+
+### 10.5 空エントリのスキップ
+
+全要素が null または空文字のエントリは読み飛ばされる。
+
+- **Excel**: 行の全セルが空の場合にスキップされる
+- **YAML**: `rows:` 内の要素が空マッピング（`{}`）またはすべての値が空文字の場合にスキップされる
+
+→ [Excel / YAML Example](ntf-testdata-doc-examples-special.md#header-comment)
diff --git a/.rn/ntf-yaml-support/input/ntf-testdata-loading.md b/.rn/ntf-yaml-support/input/ntf-testdata-loading.md
new file mode 100644
index 00000000..5ddc9b6b
--- /dev/null
+++ b/.rn/ntf-yaml-support/input/ntf-testdata-loading.md
@@ -0,0 +1,263 @@
+# NTF テストデータ読み込み機構
+
+NTF 本体が Excel のテストデータを読み解き、構造化オブジェクトへ変換するまでを解説します。
+利用者向けの「テストデータの書き方」（`ntf-testdata-doc.md`）が表側だとすれば、本書はその裏側──本体がどう動くか──です。読み終えると、**どの段階で何が変換・整形され、どこから元の値に戻せなくなるか**を追えるようになります。
+
+- **用語**：NTF 解説書（`ntf-doc-terms.md`）に準拠（データタイプ、ヘッダ行、データ行、ディレクティブ、電文 など）
+- **対象範囲**：NTF 本体（`nablarch.test.core.reader`）の読み込み経路。変換ツール・YAML 経路は対象外
+
+---
+
+## 1. 読み込みの4段階
+
+Excel の1シートは、4つの段階を経て構造化オブジェクトになる。
+
+```mermaid
+flowchart LR
+ A["① 読む
PoiXlsReader
シートを
文字列の表に"] --> B["② 掃除する
TestDataParsingTemplate
コメント・
空行を除去"] --> C["③ 変換する
各 Interpreter
特殊記法を
実値へ"] --> D["④ 組み立てる
各データタイプのパーサ
構造化
オブジェクトへ"]
+ style A fill:#e8f0fe
+ style B fill:#e8f0fe
+ style C fill:#e8f0fe
+ style D fill:#ede7f6
+```
+
+利用者は入口インタフェース `TestDataParser` 経由でデータを取得する。各段階を束ねるクラスの関係は次のとおり。
+
+```mermaid
+classDiagram
+ class TestDataParser {
+ <>
+ }
+ class BasicTestDataParser
+ class TestDataParsingTemplate
+ class TestDataReader {
+ <>
+ }
+ class PoiXlsReader
+ class Interpreter
+ class データタイプ別パーサ
+
+ TestDataParser <|.. BasicTestDataParser
+ TestDataReader <|.. PoiXlsReader
+ TestDataParsingTemplate <|-- データタイプ別パーサ
+ BasicTestDataParser ..> データタイプ別パーサ : 生成しparseを委譲
+ BasicTestDataParser --> TestDataReader : 保持
+ TestDataParsingTemplate --> TestDataReader : 保持
+ TestDataParsingTemplate --> Interpreter : 保持
+```
+
+図の各クラスと、4段階での役割の対応は次のとおり。
+
+| 段 | 担当クラス | 役割 |
+|---|---|---|
+| 入口 | `TestDataParser` | 利用者の窓口 |
+| ① 読む | `PoiXlsReader` | Excel シートを1行ずつ文字列のリストにする |
+| ② 掃除する | `TestDataParsingTemplate` | コメント・空行を除いて意味のある行だけ残す |
+| ③ 変換する | 各 `Interpreter` | 特殊記法を実値へ変換する |
+| ④ 組み立てる | データタイプ別パーサ（次章）| 構造化オブジェクトへ組み立てる |
+
+押さえるべき勘所は3点。
+
+- **①〜③はすべてのデータタイプで共通**。同じ経路を必ず通る。
+- **分岐するのは④だけ**。データタイプ（`データタイプ=値` の1行目）を見て、対応する組み立て方を選ぶ。
+- **③の変換は④より前にセル単位で完了している**（詳細は3章）。④へ渡るのは実値へ変換済みのデータである。
+
+---
+
+## 2. データタイプと組み立て方の対応
+
+④で分岐する先は、データタイプごとに異なる。ただし**組み立て方は実質2系統に集約される**。
+
+④を担当するパーサは、共通の `TestDataParsingTemplate` を頂点とする継承ツリーを成す。
+データブロックの選び方（Single / Group、7章）で枝が分かれ、その先に各データタイプのパーサが位置する。
+
+```mermaid
+classDiagram
+ class TestDataParsingTemplate
+ class SingleDataParsingTemplate
+ class GroupDataParsingTemplate
+ class DataFileParser
+ class FixedLengthFileParser
+ class VariableLengthFileParser
+ class MessageParser
+ class SendSyncMessageParser
+ class GroupMessageParser
+ class TableDataParser
+ class ListMapParser
+
+ TestDataParsingTemplate <|-- SingleDataParsingTemplate
+ TestDataParsingTemplate <|-- GroupDataParsingTemplate
+ GroupDataParsingTemplate <|-- DataFileParser
+ DataFileParser <|-- FixedLengthFileParser
+ DataFileParser <|-- VariableLengthFileParser
+ GroupDataParsingTemplate <|-- TableDataParser
+ GroupDataParsingTemplate <|-- GroupMessageParser
+ SingleDataParsingTemplate <|-- MessageParser
+ SingleDataParsingTemplate <|-- ListMapParser
+ MessageParser <|-- SendSyncMessageParser
+ MessageParser ..> FixedLengthFileParser : 委譲
+ GroupMessageParser ..> MessageParser : 委譲
+```
+
+| データタイプ | 構造化オブジェクト | 組み立て方 | 担当パーサ |
+|---|---|---|---|
+| `SETUP_FIXED` / `EXPECTED_FIXED` | 固定長ファイル | 状態機械 | `FixedLengthFileParser` |
+| `SETUP_VARIABLE` / `EXPECTED_VARIABLE` | 可変長ファイル | 状態機械 | `VariableLengthFileParser` |
+| `MESSAGE` / `*_MESSAGES`（電文各種） | メッセージ | 状態機械（ファイルデータを内部再利用）| `MessageParser` 系 |
+| `SETUP_TABLE` / `EXPECTED_TABLE` / `EXPECTED_COMPLETE_TABLE` | テーブルデータ | ヘッダ行＋データ行 | `TableDataParser` |
+| `LIST_MAP` | `List