税理士の知識とは何かを書く前に、書籍データの取り込みパイプラインを先に設計した

書き出しでつまずいた

夕方に Claude Code を開いて、次の一言を打ち込んだ。

税理士の「知識」とは課税関係の根拠が条文か通達か

書きたかったのはこういう話だ。税理士の頭の中にある「知識」の正体は、判例集や通達集の全文を暗記していることではない。ある取引を見たときに、課税関係の根拠が条文にあるのか、通達にあるのか、それとも 質疑応答事例 や裁決や判例にあるのか、どこを引き当てればいいかを見抜ける能力のことだ。

昔は手元の蔵書とその目次を覚えていることが「実力」だった。今はネット検索と AI で当たれる範囲が広がったので、「どこに根拠があるかを見抜く」ことがそのまま実務の中心になる。

この話を一般読者にも届けたいし、同時に Udemy などで販売予定の教材のドラフトも兼ねたい。書く先は eurekapu-nuxt4 のほうにしたい、と Claude Code に方針を伝えた。

Claude Code から二段構えを提案された

ところが書き始める前に著作権の壁が見えた。手元には市販されている資格試験の参考書（科目別に何冊か）の PDF があって、論点整理の参考にしたい。だが Udemy で販売する教材の下書きに、教材ベースの章立てや例題をそのまま転記すると、当然アウトになる。

Claude Code が提案してきたのは、こういう二段構えだった。

MDX-Playground 側: 一次ソース（条文・通達・国税庁の解説）から自分で書き直したものを蓄積する。学習ノート兼ブログ。
eurekapu-nuxt4 側: MDX-Playground で「自分の言葉で書き切れた」と判定できた単元だけを、販売用フォーマットに昇格させる。

つまり MDX-Playground をろ過装置にする。教材を直接 eurekapu-nuxt4 に置かない。間に「自分で書き直す」工程を必ず挟む。

著作権の整理として、条文・通達・判決文は著作権法 13 条で著作物に該当しないため引用・転載自由。国税庁の解説資料は厳密には著作物性があり得るが、出典明示の常識的範囲なら実務上は問題なし。一方、市販教材は完全に著作物なので、章立て・図表の構成・例題のトレースまで含めて流用は不可。この線引きを計画書に明文化した。

ここで Book Knowledge Base の話が割り込んだ

計画書を保存したあと、もう一つ気になっていたことを Claude Code にぶつけた。

別レポジトリで Book Knowledge Base というプロジェクトを動かしている。裁断してスキャンした書籍 PDF を yomitoku で OCR にかけて、章節単位に再構成して Turso（libSQL/SQLite 互換の DB）に格納する仕組みだ。蔵書全体を AI から横断検索できるようにするためのもので、私が SQL を書くわけではない。Claude Code に「○○について関連書籍から検索して内容を要約して」と頼むと、Turso を裏で叩いて該当セクションを集めてくる、という使い方になる。

この仕組みを、税法コンテンツの作成にも乗せたい。市販教材の PDF を Book Knowledge Base に流し込んで、Turso 側で章節単位に保管する。MDX-Playground で記事を書くときは、Claude Code 経由で「この論点に関連する箇所を教材から拾って」と日本語で質問し、論点把握と章立ての参考に使う。

教材PDF
  -> Book Knowledge Base（OCR・章節分割）
Turso DB (book-knowledge-base)
  -> MDX-Playgroundで参照（Claude Code経由で日本語横断質問）
記事ドラフト（論点整理・章立て・例の発見）
  -> 一次ソース（国税庁・条文・通達・判例）で書き直し
MDX-Playground の公開記事
  -> 品質判定後に昇格
eurekapu-nuxt4（販売用教材）

このフローを計画書に追記してもらった。同時に、ここで一番重要な分離原則も書き加えた。

Turso DB に入れた教材データは、学習・参照専用。自分のローカル蔵書を AI に質問するための内部資産であって、外部公開しない。
記事への出力は必ず一次ソース起点。教材を Turso 経由で読んだとしても、その文章・図表・例題をそのまま記事に貼らない。論点把握と章立ての参考にとどめ、実際の本文は国税庁・条文・通達を開き直して自分で書く。

この分離が崩れると、二段構えの意味がなくなる。販売物の下書きである eurekapu-nuxt4 に教材ベースの内容が紛れ込むリスクが復活してしまう。

段階的にやる

「3 科目全部いきなりやるのは大変なんで、徐々にやっていく感じですかね」と Claude Code に伝えた。私の勉強のまとめも兼ねているので、無理に網羅する必要はない。

計画書では Phase 1 として一科目だけに絞ることにした。その科目の中でも、論点単位で進める。初回の候補テーマは Claude Code に 4 つほど挙げてもらった。所得区分のマップ、特定の所得区分の課税構造、所得区分どうしの境界判定、所得控除の全体像。どれから着手するかは未決のまま、未決事項のチェックボックスに入れた。

Phase 2 で他の科目に同じフォーマットを横展開、Phase 3 で eurekapu-nuxt4 への転用、という大きな順序だけ決めた。

振り返り

今日やったのは、こういう順序だった。

「税理士の知識とは何か」という記事を書こうとして Claude Code に話しかける
著作権の懸念が浮上し、Claude Code から「MDX-Playground でろ過してから eurekapu-nuxt4 に昇格」という二段構えを提案される
方針が固まったところで、計画書を memo ディレクトリにドラフトとして残してもらう
別レポジトリの Book Knowledge Base のパイプラインと接続することを思い出し、データフロー（教材 PDF → Turso → MDX-Playground → eurekapu-nuxt4）を計画書に追記してもらう
教材データは学習・参照専用、記事への出力は一次ソース起点、という分離原則を明文化する

書き始める前に、「書く先のリポジトリ配置」と「書くためのデータパイプライン」を先に設計する必要があった、というのが今日の発見だった。論点を 1 本書くだけなら直接 eurekapu-nuxt4 に書いてもよかったかもしれない。だが学習を兼ねた長期プロジェクトとして 2 科目目・3 科目目まで伸ばす前提だと、最初に分離原則を決めておかないと後で全部書き直す羽目になる。

私が SQL を書くわけではないし、Turso のスキーマ設計を自分で考えるわけでもない。Claude Code が DB を裏で叩いて該当箇所を引いてくる。私がやるのは、引いてきた論点を見て「これは条文に根拠がある」「これは通達」「これは質疑応答事例」と当たりをつけて、一次ソースを開き直して自分の言葉で書き直すこと。それが「税理士の知識とは何か」というテーマで書こうとしていた話そのものだった。

書く前にパイプラインを設計したつもりが、書こうとしていた内容を別の角度から確認していたことになる。

明日以降

計画書の未決事項から最初の論点を 1 つ選ぶ
その論点について、教材を Book Knowledge Base に取り込む単位（科目全体か章単位か）を決める
記事のテンプレート構造（前提 -> 図解 -> 条文 -> 通達 -> 判例 -> 質疑応答 -> まとめ）を 1 本書いて固める
1 本書き終わったら、フォーマットを横展開する前に振り返りを 1 回入れる