財産データベースを自作する手順｜相続実務を回すための設計リファレンス

なぜ「財産データベース」なのか
設計の3層
持つべき項目（例）
評価はDBではなく「通達」に従う
守秘とローカル管理（ダミーで設計）
AIに任せられる範囲
よくある質問
まとめ

相続の実務は、つきつめると「財産をもれなく把握し、正しく評価する」ことに尽きます。ところが現場では、不動産は登記簿、預貯金は残高証明、証券は取引報告書……と資料がバラバラで、案件のたびに一から集計し直す、ということが起こりがちです。

この記事は、散らばった情報を1つの財産データベース（財産DB）にまとめ、AIを設計の相棒にして自作するための設計リファレンスです。コードを書ける必要はありません。大事なのは設計の考え方です。

この記事の結論
– 相続実務の土台は「財産の網羅」。1件1行の財産DBがあると、集計・見直し・申告準備が一気に楽になる。
– 設計は3層：①項目設計（何を持つか）→ ②台帳（1件1行で記録）→ ③集計（名寄せ・小計）。
– 評価額そのものはDBが決めるのではなく、財産評価基本通達・路線価等に従う。DBは「根拠と数字を並べて管理する器」。
– 財産DBは個人情報の塊。ローカル管理・ダミーで設計し、評価と申告の確定は税理士が持つ。

⚠️ 器は自作できても、評価と申告の確定は税理士が
財産DBは情報を整理する器です。個々の財産評価額や相続税の計算・申告は、財産評価基本通達や関連法令にもとづき、税理士が最終確定してください。DBの数字は「根拠つきの下ごしらえ」であって、結論ではありません（2026年時点の情報です）。

なぜ「財産データベース」なのか

資料が種類ごとにバラバラだと、こんな手戻りが起きます。

財産の数え落とし（把握していない口座・保険・貸付金）
同じ人の財産が名寄せできず、全体像が見えない
評価の根拠資料の所在が分からず、確認のたびに探す

財産DBは、これらを1件1行に集約します。1行に「何を・いくらで・どの根拠で・資料はどこに」を並べておけば、集計も見直しも、後からの確認も速くなります。

設計の3層

①項目設計（何を持つか）

最初に決めるのは列（項目）です。ここが設計の8割を占めます。AIには「相続の財産DBに必要な項目を挙げて」と壁打ちしつつ、自分の実務に合わせて取捨選択します。項目例は次章の表を参照。

②台帳（1件1行で記録）

決めた項目に沿って、財産を1件ずつ1行で記録します。種別が違っても同じ台帳に入れておくのがコツ（不動産も預貯金も同じ表）。種別列で分けられるようにしておけば、後から絞り込めます。

③集計（名寄せ・小計）

名義や種別で名寄せし、小計・合計を出します。「被相続人ごと」「種別ごと」「プラス財産／マイナス財産（債務）」で集計できると、全体像がつかめます。AIには集計の下ごしらえ（合計・並べ替え）を頼み、件数と合計は必ず自分で検算します。

持つべき項目（例）

項目	内容	ねらい
財産種別	不動産／預貯金／有価証券／保険／貸付金／債務…	集計・絞り込みの軸
名義・被相続人	誰の財産か	名寄せの軸
内容・所在	物件所在・金融機関・銘柄など	特定と資料照合
評価額	現時点の評価額	集計の元（根拠は別列）
評価根拠	路線価・残高証明・通達の区分など	あとで確認できるように
取得日・取得原価	取得の記録	譲渡・見直し時に必要
資料の所在	現物・PDFの保管場所	探す時間をなくす
状態・備考	確認中／確定済など	進捗管理

ポイントは、評価額の隣に必ず「評価根拠」を置くこと。数字だけを持つと、後で「なぜこの額か」を追えなくなります。

評価はDBではなく「通達」に従う

ここが最重要の注意点です。財産DBは評価額を入れる器であって、評価額を決める道具ではありません。土地なら路線価方式・倍率方式、非上場株式なら区分に応じた方式——評価そのものは財産評価基本通達や関連法令に従います。AIに「評価額を出して」と丸投げして、その数字を鵜呑みにするのは危険です。

DBに持たせるのは、あくまで「通達に沿って人が確認した評価額」と「その根拠」。AIは、根拠資料の整理や集計の下ごしらえを手伝う役に留めます。

守秘とローカル管理（ダミーで設計）

財産DBは、氏名・資産・家族関係が詰まった最も守秘性の高いデータです。

設計はダミーで：構造を作る段階では実データを使わず、ダミーで組む（ダミーデータ生成の手順）。
実データはローカルで：実際の財産情報は手元で管理し、AIに丸ごと渡さない。
最小限で渡す：AIの助けが要るときも、構造や少数のダミー行だけを渡す。

AIに任せられる範囲

任せやすい（AI）	人が持つ
項目設計の壁打ち・たたき台づくり	どの項目を採用するかの決定
台帳フォーマットの整形・集計の下ごしらえ	評価額の確定・通達適用の判断
名寄せ・並べ替え・合計の補助	件数・合計の検算と最終確認
入力チェックの観点出し	相続税の計算・申告の確定（税理士）

「作ってもらう」と「自分で作る」の線引きは、次の記事「『AIに作ってもらう』と『自分で作る』の境目」でさらに掘り下げます。

よくある質問

Q. Excelでも財産DBになりますか？
A. なります。大事なのは道具ではなく設計（1件1行・種別列・評価根拠列）です。まずは表計算ソフトで十分始められます。

Q. 評価額はAIに計算させていい？
A. 下ごしらえの試算までにとどめ、通達に沿った確定は人（税理士）が行います。AIの数字をそのまま評価額にしないでください。

Q. 財産DBをAIに読み込ませて相談したい。
A. 実データは読み込ませません。相談したいときは構造やダミー行で。実データはローカルに置いたままにします。

Q. どこまで作り込むべき？
A. 最初は「網羅」と「名寄せ」ができれば十分です。使いながら項目を足していくほうが、破綻しません。

まとめ

財産DBは、相続実務の土台を「探す・数え直す」から「引くだけ」に変えます。項目設計→1件1行の台帳→名寄せ集計の3層で組み、評価額の隣に必ず根拠を置く。そして、評価そのものは通達に従い、確定は税理士が持つ。設計の相棒としてAIを使いつつ、実データはローカルで守る——この形なら、コードを書けなくても実務が回る道具になります。

この記事の主な根拠（出典）
・財産の評価方法（路線価方式・倍率方式ほか）は、財産評価基本通達および相続税に関する国税庁タックスアンサー等にもとづきます
・実データのダミー化・ローカル管理は、士業の守秘義務にもとづく実務原則です
・3層設計・項目例・AIとの役割分担は、筆者の運用方針です（2026年時点の情報です）。