家賃15万円を払い続けるのと、1億円の中古マンションをフルレバで買うのと、どっちが得なのか。一度ちゃんと式に落として、自分で触れるシミュレーターを作りたかった。最初は「数字を出して」とだけ Claude Code に頼んだが、途中で「公開コンテンツで Vue ページにしたい」と方針を切り替え、結果として4回ほど設計をひっくり返すことになった。最終的には「所得の低い個人事業主に1億円フルレバはほぼ無理」という、購入前提を根本から覆す結論まで辿り着いた。
その試行錯誤の記録を残しておく。
1. まず相場を拾わせるところから
自分の住んでいる地域近辺の中古マンション相場と価格推移を、SUUMO と utinokati から Claude Code に取りにいかせた。東京のある中心区の70平米台3LDKを基準にすると、1億円前後がリアルな価格帯だった。坪単価と直近数年の上昇率も並行で拾わせて、年率4.4%程度の値上がり率を仮置きした。
このあたりはまだ「数字を出して」ベース。Claude Code が WebFetch と並列検索で相場・推移・物件サンプルを揃え、僕は手元の家賃15万円という事実だけを渡した。
2. 方針切り替え：マークダウンではなくVueページに
シミュレーション結果をマークダウンに書き出させようとしたところで、自分で気が変わった。「式を式のまま閉じ込めるのはもったいない。スライダーで触れる Vue ページにしたい」と Claude Code に伝えた。
Vue Pages のルールを読み直させ、既存ブログページのテンプレートを参考にしつつ、次の方針で書かせた。
- 純粋関数を
app/utils/mansion-simulation.tsに切り出す（カバレッジ対象・テスト可能） - 入力は ref で持ち、computed で再計算
- 結果ダッシュボード・シナリオ表・内訳テーブルを Vue で描画
ここで一段抽象化されたのが効いた。後でロジックを書き直す局面が何度も来たが、純粋関数とテンプレートが分かれているおかげで影響範囲が限定された。
3. 仲介手数料の閾値ミスと、印紙税の500万円バンド
純粋関数を Claude Code に書かせて最初に走らせたユニットテストで、2件の事実誤認が露呈した。
仲介手数料の閾値ミス。 Claude Code の初稿では仲介手数料の段階計算の境界が法律と微妙にズレていた。200万円以下5%、200万円超400万円以下4%、400万円超3%という宅建業法の上限を「修正して」と指示すると、関数が一発で直った。
印紙税の500万円バンド。 テストが落ちた原因は、印紙税の期待値を僕が書き間違えたことだった。500万円の不動産売買契約書は「1千万円以下」のバンドに入り、軽減税率で5,000円が正解。期待値を直してテストを通した。
カバレッジは98%、型エラーは0で着地。試算ロジックの足場ができた瞬間に、後段の調整がぐっと早くなった。
4. 「保有コスト、ローン返済しかないじゃん」と指摘される
最初の画面を見て自分で違和感を拾った。保有コストの内訳がローン返済中心で、税金や保険のテキストが薄い。「保有コストが借り入れローン返済しかない」と Claude Code に投げると、固定資産税は入っていたが、都市計画税・火災保険・専有部修繕・大規模修繕の一時金が粗いことが判明した。
内訳を分離してテーブル化させ、月額と10年合計の両方を表示するようにした。金額自体は本体ローン返済に比べれば小さいが、見えていなかった項目が並ぶだけで、購入後のキャッシュフロー像が一段現実に寄った。
5. 「家賃と物件価格、不公平比較じゃん」
次に自分で気付いたのが、賃貸物件価格との比較の不公平さだった。家賃15万円で住める物件が市場では旧耐震2,500万円相当だったとして、それと新耐震1億円の購入物件を並べて「買う方が得」と言っても比較対象が違いすぎる。
ここで Claude Code に「家賃から逆算した妥当物件価格」セクションを追加させた。利回り（Cap Rate）を7%でスライダー入力にして、家賃15万円なら年間180万円、利回り7%で逆算すると約2,571万円。この数字と購入価格を並べて初めて、賃貸と購入の比較がフェアになった。
6. 法人購入の社宅扱いを反映
ここまで個人購入前提で組んでいたが、法人で買って社宅扱いにする選択肢が当然ある。Claude Code に「個人vs法人の税制比較を調査して」と並行で投げ、その間に UI 側で社宅扱いの実質家賃負担率（rentPersonalBurdenRate）を入力に追加させた。
調査結果が戻ってきたら、税制比較表として一気にテンプレートに反映。役員社宅の賃料計算ルール、減価償却の取り扱い、売却時の課税の違いまで表で並べた。
7. 「これ、フルレバ無理なんじゃ？」というツッコミ
ここで自分から本質的な問いを投げた。「1億円の借り入れって個人でやる時、年収倍率8倍ルールあるじゃないですか。しかも僕、個人事業主で大した利益出てないんですよ。これフルレバ現実的に借りられますかね、税理士の属性はあるけど所得そんなないんですよ」
Claude Code が即答した。「個人事業主・所得低ならほぼ無理です」。事実関係を整理してから「借入可能額試算」セクションを追加することになった。
純粋関数として maxLoanByIncomeMultiplier（年収倍率ルール）と maxLoanByDebtToIncome（返済比率35%ルール）を切り出し、両方の小さい方を上限とする maxBorrowableLoan を追加。テストも先に書かせた。
UI には借り手プロファイル（年収・年収倍率・返済比率・金利）を入力するセクションを置き、その下に「不足額」を表示。年収500万円で年収倍率7倍を入れると借入可能額は3,500万円、1億円との差は6,500万円。フルレバが現実的に成立しないことが画面で一発で見える状態になった。
8. 「株式譲渡益は年収にカウントされる？」
最後にもう一段気になることを Claude Code に投げた。「実現した株の譲渡益って、住宅ローン審査ではコールされるんですかね」
調べさせた結果、住宅ローン審査では基本的にカウントされないのが原則だった。継続性のある給与・事業所得が審査対象で、譲渡益は一過性とみなされる。ただし住宅ローン控除の所得制限の判定では合算される点に注意が必要。富裕層向けの資産連動型融資なら金融資産自体が信用補強になるが、一般的な住宅ローンの俎上では戦力外。
このリアリティチェックをページ末尾に追記して、「金融資産があるなら自己資金に回す方が効く」という落としどころに置いた。
できあがったもの
- 純粋関数
app/utils/mansion-simulation.ts（カバレッジ98%） - Vue ページ
app/pages/blog/taito-mansion-simulation.vue - ユニットテスト
tests/mansion-simulation.test.ts - セクション構成：シミュレーター入力 → 結果ダッシュボード → 家賃から逆算した妥当物件価格 → 借入可能額試算 → 個人vs法人比較表 → 結論
振り返り
最初の指示は「数字を出して」だけだった。そこから
- 「公開Vueページにして」（出力形式変更）
- 「保有コストが薄い」（モデル粒度の修正）
- 「比較が不公平」（前提条件の修正）
- 「法人購入も入れて」（軸の追加）
- 「フルレバ無理じゃ？」（前提自体の破壊）
- 「株式譲渡益は？」（細部の追い込み）
と、6回ほど方針を切り替えた。Claude Code 側はそのたびに純粋関数を切り出し直し、テストを更新し、テンプレートに反映し直した。僕は画面を見て違和感を拾う係に徹していた。
個人事業主・所得低・タワマン1億円フルレバは画面上で数字を眺めるとほぼ門前払いだった。「買うと得」という結論ありきの式は、借入可能額の現実を入れた瞬間にひっくり返る。シミュレーターは答えを出す道具ではなく、自分の前提が破綻していることを発見する道具だった。