nta_get_bunshokaitou の仕様

INFO

houki-nta-mcp v0.27.1 の specs/current/nta_get_bunshokaitou/spec.md から自動生成しました（仕様 ID 11 件・2026-10-12）。手で編集しないでください。再生成は node scripts/generate-reference.mjs specs です。

文書回答事例を docId で 1 件取得する

使いどころ・引数・実測の呼び出し例は、ツールのページにあります。

最後に仕様が変わったのは v0.26.0 の「ローカル DB を開けないときの読むだけのツールと書き戻すツールの応答、--bulk-download-tax-answer が索引を保存できないときの終わり方（nta #144・#145）」（2026-10-06 承認）です。それまでの経緯は承認の履歴にあります。

利用者と得られる結果

この機能の利用者と、利用者が渡すもの・得られる結果を示します。

• MCP クライアント（Claude などの LLM、または CLI から呼ぶ人）。docId を渡して、ローカル DB に入っている国税庁の文書回答事例 1 件の本文・発出日・添付 PDF の一覧を受け取る

入力

呼び出すときに渡す値です。

引数	必須	内容
docId	必須	文書 ID。本庁の事例は 税目/フォルダー名（例: shotoku/250416）、国税局の事例は 局/税目/フォルダー名（例: tokyo/shotoku/260218、nagoya/hojin/nag_140625）。フォルダー名の数字の桁数は確かめない。nta_search_bunshokaitou の結果の docId をそのまま渡す。空文字・空白だけは不可（009）。形は 010。全角の数字・ダッシュ類は半角に揃えてから読む（011）
format	任意	markdown（既定）または json

docId を省く、文字列でない値を渡す、上の 2 つ以外の引数を渡す、のいずれもエラー INVALID_ARGUMENT になる（入力の検査はすべてのツールに共通で、このツールのテストは無い。未決 1）。

扱わないこと

この機能が意図して扱わないことです。

• DB に無い文書を国税庁サイトから取ること（docId から個別ページの URL を組み立てるには税目フォルダの世代差を解く必要があるため。取り込むのは --bulk-download-bunshokaitou）。応答に source: "live" が現れることはない
• 題名やキーワードから文書を探すこと（探すのは nta_search_bunshokaitou）
• 添付 PDF の本文を読むこと（一覧と読み方を返すだけ。PDF の一覧だけが要るときは nta_inspect_pdf_meta）
• 本文を照会要旨・回答要旨などの節に分けて返すこと（本文は 1 続きの平文）
• 回答が今の法令・通達でも成り立つかを判定すること

処理の流れ

呼び出しを受けてから応答を返すまでに、何をどの順で確かめるかを示します。図の中の番号は「できること」の仕様 ID の末尾 3 桁です。

仕様項目

この機能の仕様項目を、仕様 ID ごとに並べています。見出しは仕様項目を 1 文で表したもので、条件・応答の細部・例は「詳細」を開くと読めます。仕様 ID はそれぞれ受入テストと対応していて、テストの無い ID があると各リポジトリの CI が止まります。

SPEC-NTA-GET-BUNSHOKAITOU-001 ローカル DB にある文書はエラーにせず返す

詳細

docId の文書回答事例がローカル DB にある（--bulk-download-bunshokaitou で入れた）ときは、その内容を返す。応答に code は付かない。国税庁サイトには取りに行かない。

SPEC-NTA-GET-BUNSHOKAITOU-002 DB に文書回答事例が 1 件も無いときは投入を案内する

詳細

ローカル DB に文書回答事例が 1 件も無い（DB が空、質疑応答事例など他の種別の文書しか入っていない、DB のファイルが無い・版の記録が無い・版が合わない・開けない）ときは、エラー DOC_NOT_FOUND を返す。この応答は次を持つ。

フィールド	内容
error	ローカル DB に文書回答事例が 1 件も無いため、docId="<渡した docId>" を取得できません
hint	DB の状態ごとの文（SPEC-NTA-DB-SCHEMA-029。<種別> は 文書回答事例、フラグは --bulk-download-bunshokaitou）。どの文も開こうとした DB のパスを含む
next_actions	1 件。action: "cli_bulk_download"、example.command は --bulk-download-bunshokaitou を付けた案内のコマンド（SPEC-NTA-DB-SCHEMA-027）。版が新しい・読めない DB と、開けない DB では入れない（SPEC-NTA-DB-SCHEMA-021・029）
tool	nta_get_bunshokaitou
retryable・detail	開けない DB だけ retryable: false と detail.cause（SPEC-NTA-DB-SCHEMA-029。v0.25.x では SPEC-NTA-COMMON-ERRORS-006 の INTERNAL_ERROR だった）

available_doc_ids は付けない（選ばせる文書が無い）。

例: 環境変数を付けずに起動し（ホームディレクトリが /Users/bonji）、改正通達だけを入れた DB で { docId: "shotoku/250416" } を渡すと、hint は ローカル DB（~/.cache/houki-nta-mcp/cache.db）に文書回答事例（doc_type="bunshokaitou"）が入っていません。`npx -y @shuji-bonji/houki-nta-mcp@latest --bulk-download-bunshokaitou` で投入してください。… で始まる（v0.24.x では MCP サーバーが開いている DB（/Users/bonji/.cache/houki-nta-mcp/cache.db）に… で始まり、コマンドは houki-nta-mcp --bulk-download-bunshokaitou）。

SPEC-NTA-GET-BUNSHOKAITOU-003 文書はあるが docId が無いときは「見つかりません」と候補を返す

詳細

ローカル DB に文書回答事例はあるが、渡した docId の文書が無いときは、エラー DOC_NOT_FOUND を返す。「投入されていない」とは書かず、docId の誤りとして案内する。この応答は次を持つ。

フィールド	内容
error	文書回答事例 docId="<渡した docId>" は見つかりません
hint	DB にある文書回答事例の件数（例: DB の文書回答事例 1,841 件に、この docId はありません）、available_doc_ids から選ぶか nta_search_bunshokaitou で探す案内、DB を投入した後に公開された文書は `<コマンド>` をもう一度実行すると取り込める旨。<コマンド> は --bulk-download-bunshokaitou を付けた案内のコマンド（SPEC-NTA-DB-SCHEMA-027）
available_doc_ids	DB にある文書回答事例の docId を発出日の新しい順に最大 30 件。要素は docId・title・issuedAt。他の種別（改正通達・質疑応答事例など）の docId は入らない
next_actions	1 件。{ action: "nta_search_bunshokaitou", reason: "キーワード検索で正しい docId を探せます" }
tool	nta_get_bunshokaitou

例: 環境変数を付けずに起動すると、hint の末尾は DB を投入した後に国税庁が公開した文書は、`npx -y @shuji-bonji/houki-nta-mcp@latest --bulk-download-bunshokaitou` をもう一度実行すると取り込めます（v0.24.x では houki-nta-mcp --bulk-download-bunshokaitou）。

SPEC-NTA-GET-BUNSHOKAITOU-004 国税庁の索引から消えた文書に印を付け、索引にある文書では印のキーを null にする

詳細

DB から返す文書回答事例が国税庁の索引から外れている（bulk download で外れたことを確認した日時が付いている）ときは、応答に印を付ける。

• format が json のとき: index_status: "removed_from_index"、orphaned_at（確認した日時。例: "2026-10-01T00:30:00Z"）、notice（索引から外れている旨と、過去の課税期間では意味を持つ場合があること、現在の取扱いは最新の通達で確かめること、出典 URL が 404 になることがあることの注記）を付ける。document.orphanedAt にも同じ日時が入る。索引にある文書では、index_status・orphaned_at・notice・document.orphanedAt をどれも null にする（キーは無くならない）
• format を省くか markdown のとき: - **取得元** の行（SPEC-NTA-GET-BUNSHOKAITOU-005）の次に - **索引の状態**: removed_from_index（<確認した日時> に確認） の行を入れ、空行を挟んで > で始まる注記の行を入れる。索引にある文書では、この行と注記を入れない

注記の文は nta_get_jimu_unei（SPEC-NTA-GET-JIMU-UNEI-004）と同じである。

例: 索引にある文書回答事例を format: "json" で取ると、index_status: null・orphaned_at: null・notice: null・document.orphanedAt: null を持つ（v0.22.0 では index_status・orphaned_at・notice のキーが無かった）。

SPEC-NTA-GET-BUNSHOKAITOU-005 markdown（既定）の応答

詳細

format を省くか markdown にしたとき、応答は次の順に並ぶ文字列である。

• 見出し # <題名>
• - **種別**: 文書回答事例、- **発出日**: <発出日>（DB にあるときだけ）、- **税目**: <税目>（DB にあるときだけ）、- **docId**: `<docId>`、- **出典**: <国税庁ページの URL>、- **取得**: <DB に入れた日時>、- **取得元**: ローカル DB（bulk download で取り込んだもの） の行
• 国税庁の索引から消えた文書では、索引の状態の行と注記（SPEC-NTA-GET-BUNSHOKAITOU-004）
• 宛先・発出者が DB にある文書では ## 宛先・発出者 の節。各行を > で引用する
• ## 本文 の節と本文
• 添付 PDF がある文書では ## 添付 PDF (<件数> 件) の節（下のとおり。種別は SPEC-NTA-GET-BUNSHOKAITOU-008 で補った後のもの）
• 最後に --- と、*文書回答事例は照会者・国税庁双方の合意に基づく個別事案回答であり、一般的な法的拘束力はない（実務判断は通達・法令本文に基づく必要あり）* の注

添付 PDF がある文書では、## 本文 の後に ## 添付 PDF (<件数> 件) の節を置く。節の中身は次のとおり。

• PDF の本文はこのサーバーが読まないことと、pdf-reader-mcp の read_url か、nta_inspect_pdf_meta を save: true で呼んで extract_tables に渡す読み方の案内（> の引用）
• 種別・タイトル・サイズ・読み方・URL の表。行は種別の順（新旧対照表・別紙・Q&A・参考資料・通知・その他）で、同じ種別の中は DB に入っている順
• ### 読み方 の節。表に現れた種別ごとに 1 行ずつ、その種別の PDF の読み方（nta_inspect_pdf_meta の layout_note と同じ文。SPEC-NTA-INSPECT-PDF-META-005）

「取得元」の行は nta_get_jimu_unei（SPEC-NTA-GET-JIMU-UNEI-006）と同じ文で、このツールは DB だけを引くので値は常に ローカル DB（bulk download で取り込んだもの） である（v0.22.0 ではこの行が無かった）。

SPEC-NTA-GET-BUNSHOKAITOU-006 json の応答

詳細

format を json にしたとき、応答は次のフィールドを持つ。値の無いフィールドは null にし、キーは無くさない。

フィールド	内容
document.docType	bunshokaitou
document.docId / document.taxonomy / document.title	文書 ID・税目・題名
document.issuedAt / document.issuer	発出日（YYYY-MM-DD）と宛先・発出者。DB に無ければ null
document.sourceUrl / document.fetchedAt	出典 URL と DB に入れた日時
document.orphanedAt	索引から消えたことを確認した日時。索引にある文書では null（SPEC-NTA-GET-BUNSHOKAITOU-004）
document.fullText	本文
document.attachedPdfs	添付 PDF の配列。要素は title・url・sizeKb・kind。kind は全要素に付く（DB に無ければ SPEC-NTA-GET-BUNSHOKAITOU-008 で題名から決める）。添付が無ければ空の配列
index_status / orphaned_at / notice	SPEC-NTA-GET-BUNSHOKAITOU-004。索引にある文書では null
legal_status	binds_citizens: false / binds_courts: false / binds_tax_office: false と、個別事案への回答で一般的な法的拘束力はない旨の note
source	db

例: 発出日と宛先が DB に無い文書回答事例では、document.issuedAt: null・document.issuer: null（v0.22.0 ではどちらのキーも無かった）。

SPEC-NTA-GET-BUNSHOKAITOU-007 available_doc_ids は発出日の新しい順で、発出日の無い文書は後ろに置く

詳細

SPEC-NTA-GET-BUNSHOKAITOU-003 の available_doc_ids は、次の順で最大 30 件である。

• 発出日の新しい順
• 発出日の無い文書は、発出日のある文書の後ろ
• 発出日が同じなら docId の降順

例: 発出日が 2026-05-01 の souzoku-X、2026-04-01 の A、発出日の無い B がある DB では、available_doc_ids の docId は souzoku-X・A・B の順になり、B の issuedAt は null。DB に 31 件以上あっても 30 件までしか入らない。

SPEC-NTA-GET-BUNSHOKAITOU-008 kind の無い添付 PDF は題名から kind を決めて返す

詳細

DB に入っている添付 PDF に kind が無い（v0.6.0 期に投入した文書）ときは、題名から kind を決めて応答に入れる。判定は nta_inspect_pdf_meta の SPEC-NTA-INSPECT-PDF-META-003 と同じ（「新旧対照表」「新旧対応表」「対比表」は comparison、「Q&A」「質疑応答」「FAQ」は qa-pdf、「別紙」「別表」「様式」「付録」「添付資料」は attachment、「通知」「お知らせ」「連絡」は notice、「参考」「参考資料」「関連資料」は related、どれにも当たらなければ unknown）。改正通達の「別紙 N」を comparison に付け替える扱い（SPEC-NTA-GET-KAISEI-TSUTATSU-007）は nta_get_bunshokaitou では行わない（docType が kaisei でないため）。json の document.attachedPdfs の全要素に kind が付き、markdown の表と ### 読み方 では決めた種別の行になる（「その他」になるのは unknown のときだけ）。DB の内容は書き換えない。

例: kind の無い「参考資料」「別紙1」「Q&A」を持つ文書回答事例を json で取ると、document.attachedPdfs の kind は順に related・attachment・qa-pdf。markdown の表には「別紙」「Q&A」「参考資料」の行があり、「その他」の行は無い。同じ文書を nta_inspect_pdf_meta で見たときと kind が一致する。

SPEC-NTA-GET-BUNSHOKAITOU-009 docId が空文字・空白だけのときはDBを引かずに INVALID_ARGUMENT を返す

詳細

空文字は inputSchema の minLength: 1 の検査（SPEC-NTA-COMMON-ERRORS-013）で止まり、INVALID_ARGUMENT（tool: "nta_get_bunshokaitou"、detail.issues: [{ path: "docId", message: "空文字は指定できません" }]）を返す。空白（半角スペース・全角スペース・タブ・改行）だけのときは、ツールの処理がDBを引く前に、SPEC-NTA-COMMON-ERRORS-014 の形の INVALID_ARGUMENT（tool: "nta_get_bunshokaitou"、error: "docId が空です"、detail.issues: [{ path: "docId", message: "空白だけは指定できません" }]、hint にnta_search_bunshokaitou の結果の docIdを渡すよう書く）を返す。

例: docId: "" は code: "INVALID_ARGUMENT"・detail.issues[0].message: "空文字は指定できません"。docId: "　"（全角スペース）と docId: " \n" は code: "INVALID_ARGUMENT"・error: "docId が空です"。どれもDBは引かない。

SPEC-NTA-GET-BUNSHOKAITOU-010 docId が受け付ける形でないときは DB を引かずに INVALID_ARGUMENT を返す

詳細

docId は、国税庁サイトの文書回答事例のページの URL のフォルダーの並びで、本庁の事例は 税目/フォルダー名（2 つの要素）、国税局の事例は 局/税目/フォルダー名（3 つの要素）である。どの要素も英小文字・半角の数字・-・_ だけからなる（SPEC-NTA-COMMON-ERRORS-015）。フォルダー名の付け方は国税局や年代によって違う（shotoku/250416・tokyo/shotoku/260218・fukuoka/hojin/20101001・sapporo/hojin/02_01・nagoya/hojin/nag_140625 など）ので、数字の桁数は確かめない。前後の空白を除き、半角に揃えた（SPEC-NTA-GET-BUNSHOKAITOU-011）値がこの形でないときは、DB を引く前に INVALID_ARGUMENT（tool: "nta_get_bunshokaitou"、error: "docId の形が受け付ける形ではありません: <渡した値>"、detail.issues: [{ path: "docId", message: "税目/フォルダー名 か 局/税目/フォルダー名 の形で、英小文字・数字・-・_ だけで指定してください（例: shotoku/250416、tokyo/shotoku/260218）" }]、hint に nta_search_bunshokaitou の結果の docId をそのまま渡すよう書く）を返す。DOC_NOT_FOUND は、形に合うが DB にその文書が無いときだけになる。

例: docId: "shotoku/250416"・"tokyo/shotoku/260218"・"fukuoka/hojin/20101001"・"sapporo/hojin/02_01"・"nagoya/hojin/nag_140625" は検査を通り、DB を引く。docId: "250416"（要素が 1 つ）・"a/b/c/250416"（要素が 4 つ）・"shotoku/250416/index.htm"（. を含む）・"Tokyo/shotoku/260218"（英大文字）・"shotoku/文書/250416"（漢字）は code: "INVALID_ARGUMENT"・detail.issues[0].path: "docId" で、DB は引かない（v0.21.3 では DB を引いてから「見つかりません」の応答になっていた）。

SPEC-NTA-GET-BUNSHOKAITOU-011 docId は半角に揃えてから形を確かめる

詳細

docId は、前後の空白を除いた値を houki-abbreviations の normalizeJpText の規則（全角英数字を半角に、ダッシュ類 － ‐ ‑ – — ― − を - に、全角チルダ ～ 〜 を ~ に、全角空白を半角空白にし、前後の空白を除く。罫線 ─ と長音 ー は変えない。大文字と小文字は区別する）で揃えてから、SPEC-NTA-GET-BUNSHOKAITOU-010 の形の検査に進む（SPEC-NTA-SEARCH-RULES-019）。揃えた後の値で DB を引き、国税庁サイトの URL を組み立てる。

例: { docId: "shotoku/２５０４１６" } は { docId: "shotoku/250416" } と同じ応答（v0.21.3 では全角のまま DB を引いて「見つかりません」だった）。

実装する人に向けた情報

ここから下は、この機能を実装する人と、仕様の変更を追う人に向けた節です。使い方を知りたいだけなら、読まなくて構いません。

検討中のこと

仕様を書き起こしたときに見つかった項目のうち、扱いを Issue で検討しているものです。ここに挙げたことは、今後の版で変わることがあります。開くと、元の仕様書の記述をそのまま読めます。

仕様書の「未決」の節

初版起こしで見つけた、意図か不具合かを人が決める項目です。決まったら「できること」に ID を振るか、specs/changes/ の差分にします。

意図か不具合かの判断が要る項目は houki-nta-mcp の Issue に移し、ここには題と Issue の番号だけを残します。今の振る舞いのままでよくテストが無いだけの項目は、受入テストを書いてから「できること」に ID を振ります。

承認の履歴

この機能の仕様が、いつ、どの変更で承認されたかを新しい順に並べています。各リポジトリの npx spec-ids history nta_get_bunshokaitou と同じ内容です。変更の名前から、変更の理由と前後の振る舞いを書いた文書（GitHub）を開けます。

承認の履歴（14 件）

承認日	版	変更	仕様 PR
2026-10-06	v0.26.0	ローカル DB を開けないときの読むだけのツールと書き戻すツールの応答、--bulk-download-tax-answer が索引を保存できないときの終わり方（nta #144・#145）	#152
2026-10-05	v0.25.0	ローカル DB の場所を、応答・起動時のログ・--status で確かめられるようにし、保存したタックスアンサーの索引を読めないことをログに残す（nta #138・#137、T6）	#142
2026-10-03	v0.24.0	0.22.0 の取り込みで直し漏れた specs/current の文を、取り込んだ本文に合わせる（#123）	#132
2026-10-03	v0.23.0	値の無いフィールドを null にし、検索の結果に発出日と法令時点を揃えて返す（T4 応答の形）	#125
2026-10-02	v0.22.0	文書系 3 ツールの docId の形を、DB にある実際の値に合わせて緩める（T1 の訂正）	#121
2026-10-01	v0.22.0	全角・半角・ダッシュ類の揃え方を houki-abbreviations 0.7.0 に一本化する（T3）	#119
2026-10-01	v0.22.0	「見つからない」と「取得元の失敗」の code を分ける（T2）	#118
2026-10-01	v0.22.0	引数の検査を inputSchema に書き、丸めずに INVALID_ARGUMENT にする（T1）	#117
2026-09-30	v0.21.3	DB に入れる値と保存するファイル名の扱いを直す（#73）	#104
2026-09-27	v0.21.1	索引から消えた文書の印に、取得系 4 ツールの仕様 ID を振り、検索系 4 ツールのテストを足す	#91
2026-09-27	v0.21.1	取得系ツールと nta_inspect_pdf_meta の応答の形に仕様 ID を振る	#89
2026-09-26	v0.21.1	「未決」のうち判断が要る 45 件を Issue に移す	#74
2026-09-26	v0.21.1	全 14 ツールの spec.md に「処理の流れ」の節を足す	#63
2026-09-26	—	初版	#63

関連ページ

このページの元になった文書と、あわせて読むページです。

• houki-nta-mcp の仕様の一覧
• houki-nta-mcp の解説
• nta_get_bunshokaitou のツールのページ（リファレンス）
• 元の仕様書（GitHub、v0.27.1）