勤務先の買収で、お金のことを真剣に考え始めた

2026年9月、勤務先が買収されることになった。これをきっかけに、勤務先に関係する資産の一部が現金化される見込みになり、「この資金を今後どう運用するか」を真剣に考え始めた。

ところが、その前にもっと基本的な問題があった。

自分はいま、どこにどんな資産を持っているのだろう。

銀行口座、証券口座、国内株、米国株、投資信託、勤務先関連の資産、暗号資産。ざっくりした管理はしていたが、全体をすぐ正確に説明できる状態ではなかった。

この記事は、資産額や投資成績を公開する話ではない。資産を考え始める前に、自分の情報を意思決定できる状態へ整えようとして作った、最初のAsset Masterの記録である。

「今いくら持っている？」にすぐ答えられなかった

当時の運用はシンプルだった。各サービスへログインし、残高を確認して、Google Sheetsへ手動で転記する。

ただ、その方法では、次の問いに答えにくかった。

  • どの金融機関・サービスを確認すれば全体がそろうか
  • その数字はいつ確認したものか
  • 何を見て記録したものか
  • すでに保有しているものか、将来受け取る可能性があるものか
  • いまの数字として信頼してよいか

金額を合計するだけなら表計算はすぐに作れる。けれど、その合計を次の意思決定に使うには、数字の背景も必要だった。

最初に作ったのはGoogle Sheets一枚

最初からDBを作ったわけではない。まずGoogle SheetsのAssetSummaryを中心に、金融機関ごとの情報を確認し、自分の資産が存在する場所を一つずつ書き出した。

初版を作るのに何時間かかったかは記録していないので、この記事では書かない。ただ、最初の目的は資産総額を確定することではなかった。

自分が確認すべきAsset Sourceの一覧を作ること。

銀行、証券、投資信託、暗号資産などを、まず「ある／ない」「どこにある」で整理する。この順番にしたことで、あとから残高や明細を扱う前の漏れを見つけやすくなった。

合計額だけでは足りなかった

実際に使い始めると、残高の横にいくつかの情報が必要になった。

必要になった情報 なぜ必要だったか
Where どの金融機関・サービスを確認すべきか分かる
Asset Type / Account Type 同じ証券会社でも、NISAや課税口座などを分けて考えられる
Last Confirmed その数字がいつ時点のものかを残せる
Source / Evidence 後から「何を見て登録したか」を確認できる
Automatic / Manual 自動取得なのか、手動更新が必要なのか分かる
Actual / Planned 現在の資産と、将来の可能性を混ぜずに扱える
Freshness 更新に失敗した古い数字を、最新値として扱わないため

最初は「資産額を合計すれば管理できる」と考えていた。しかし自分の場合、管理に必要だったのは金額だけではなく、数字がどこから来て、いまも使えるかという情報だった。

実際に使うと、資産には「状態」があると分かった

作る途中で詰まったのは、資産を単純に「持っている／持っていない」と分けられなかったことだ。

たとえば、注文しただけの資産を保有資産として入れると、二重計上になる可能性がある。将来受け取る可能性がある資産をCurrent Assetへ加えれば、現在の状態を過大評価する。

そのため、少なくとも次のような状態を分けて考える必要が出てきた。

  • PLANNED：計画しているだけ
  • ORDERED：注文・コミット済み
  • EXECUTED：取引は実行された
  • SETTLED：決済・受渡まで完了した
  • ACTUAL：現在の事実として扱える

同じように、同一の証券会社でも口座区分を分ける必要があった。さらに米ドル建ての資産では、株価と為替を同じ変動として扱わないことも必要になった。

ここで得たのは投資の答えではない。資産を判断に使う前に、Current、Future / Contingent、注文中、未入金などを混ぜない、という情報整理の必要性だった。

数字のSourceと更新日も必要だった

手動入力の数字は、とくに後から意味を失いやすい。

この数字は、何を見て登録したのだろう。

数字だけでは答えられない。明細、残高画面、CSVなど、Evidenceの種類を残すことにした。自動更新についても、更新できたことと値が最新であることは同じではない。更新日時やData Freshnessを意識するようになった。

資産管理で最初に作るべきものは、完璧な自動化ではなく、数字の出所を辿れる最低限の構造だった。

Asset Masterはその後かなり大きくなった

Google Sheetsの残高表から始めた仕組みは、その後、Holdings、Price Master、Snapshots、Transactions、Evidence、Monthly Reconciliationなどを扱うところまで育った。

現在は、Google Sheetsを正式なSource of Truthとして維持しながら、Safe Syncを通じてPostgreSQL / Supabase Shadowへ同期し、Parallel Fact Modelで照合している。Hosted Parallel Runでは、8 KPI MATCH、0 DIFFERENCE、0 ERRORを確認できた。

ただし、この記事の主題はArchitectureではない。最初は単純なSheetだったものが、使うなかで必要な情報を増やしていった、という経過を残しておきたい。

でもGoogle Sheetsをまだ捨てていない

DBが動いたからといって、Google Sheetsをすぐ捨てることにはしなかった。

自分のAssetMasterで優先した順番は、次の通りである。

Accuracy → Reproducibility → Auditability → Automation → UI

新しいDBが動くことと、正式なSource of Truthとして信頼できることは別だった。だから、Google SheetsとPostgreSQLを並行して動かし、照合している。

これはLifeOpsで繰り返している「使う → Measure → Verify → Change」の一例でもある。便利そうだから置き換えるのではなく、数字が一致し、あとから説明できる状態を確認してから変える。

Asset Masterを作って変わったこと

変わったのは、「総資産額が分かった」ことだけではない。

Current Asset、Investable Asset、Future / Contingent Asset、注文中、未入金、Actual、Natural Income、Data Freshnessを分けて考えられるようになった。その結果、話は「いくら持っているか」から、「この資産を今後どう配置するか」へ進められるようになった。

AssetMasterを作ること自体が目的ではない。自分の情報を、次の判断を始められる状態にすることが目的だった。

自分でも始めるなら、金額を入れる前にこれだけ

最初に作るのは、残高表ではなくAsset Source Inventoryでよい。

Field 意味
Category 銀行・証券などの分類
Institution / Source 金融機関・サービスなどの確認先
Account Type NISA、課税口座などの区分
Acquisition Method Manual、CSVなどの取得方法
Update Frequency 更新の頻度
Last Confirmed 最終確認日
Status Activeなどの状態
Evidence Type Statement、CSVなどのEvidence種別
Notes 残すべき補足

ここでは残高、口座番号、顧客IDを入れない。まず、確認すべき場所の漏れをなくす。

Asset Source Inventory Templateをダウンロードする

Chappyへ渡すPrompt

自分用のAsset Masterを作りたいです。

まず資産額は入力せず、「どこに何があるか」だけを棚卸ししたいです。

私が銀行、証券会社、暗号資産、勤務先関連資産などを順番に伝えるので、次の項目で一覧にしてください。

- Category
- Institution or Source
- Account Type
- Data Acquisition Method
- Update Frequency
- Last Confirmed
- Status
- Evidence
- Notes

口座番号、Customer ID、Password、Token、Secretは聞かないでください。残高もこの段階では不要です。

情報が不明な場合は推測せず、Unknownとして残してください。

最後に、「まだ登録漏れがありそうなCategory」だけをチェックリストとして提示してください。

Privacy / Safety

  • 残高、口座番号、顧客ID、Password、Token、SecretをAIや共有用Templateへ入れない。
  • 残高画面や明細のスクリーンショットを共有する前に、氏名、住所、QRコード、取引履歴などを確認する。
  • この方法は情報整理の記録であり、銘柄選定、売買、配分、税務判断の助言ではない。
  • Unknownを推測で埋めず、あとで確認できる状態のまま残す。

この記事で残るものと、変わるもの

長く残るLearningは、自分の場合、資産管理の最初の仕事は資産額を合計することではなかったことだ。まず、どこに何があり、いつ確認できたのかを把握する必要があった。

一方で、Google Sheets、Supabase、現在の金融サービス、APIや自動化の構成は変わりうる。ここはCurrent Layerとして、仕組みが変われば更新する。

次は「SheetがなぜDBまで育ったか」

次の記事では、Google Sheetsで始めたAsset Masterが、なぜDBとのParallel Runまで育ったのかを扱う予定だ。

その後には、注文した資産を「持っている」ことにしないTransaction Stateと、毎月すべての金融サービスを確認しないためのMonthly Reconciliationも残したい。