賃貸選びの「なんとなく」をやめた──NotionスコアリングとClaude MCPで感情を手放す方法

はじめに

引っ越しを考え始めて数ヶ月経ったころ、気づいたことがある。物件を見れば見るほど、判断が定まらなくなっていた。

内見後の「なんとなく良かった」は翌日には揺らぐ。妻と話せば話すほど、互いの優先順位がすれ違う。それは物件が悪いのではなく、自分たちの「決め方」が決まっていないからだった。

この記事は、賃貸選びの判断をスコアリングで構造化し、NotionとClaude MCPで運用できる形に落とし込んだ話だ。AIを使って「答えを出してもらう」のではなく、「自分の優先順位を言語化するための道具」として使った記録でもある。

この記事で作るもの

物件ページをコピーして貼り付けるだけで、採点から記録まで完結するシステムだ。全体の流れはこうなっている。

① SUUMOなどの物件ページを全選択してコピー
         ↓
② Claude.ai に貼り付け＋「採点基準に従って採点してDBに書き込んで」
         ↓
③ Claude が Notion の採点基準ページを読む（MCP）
         ↓
④ 25点満点で採点・出力
         ↓
⑤ Notion の物件DBに自動書き込み（MCP）
         ↓
⑥ Notionで物件一覧を比較・検討

採点基準はNotionで管理する。Claudeはその基準を読みに行き、採点し、結果をDBに書く。人間がやることはコピペだけだ。

各ステップの設計思想と、使い続けてわかったことを順に書いていく。

---

賃貸選びはなぜこんなに難しいのか

引っ越しのタイムリミットはまだ1年先だった。
焦る必要はない。でも、これが意外と厄介だった。

締め切りがあいまいな状態では、
「もう少し待てばもっといい物件が出るかもしれない」
という思考から抜け出せない。
物件を見るたびに判断がブレ、気づけば何ヶ月も経っていた。

妻は「早く決めて安心したい」と言う。
その気持ちはわかる。でも、いざ具体的な物件を前にすると、
「築10年だけど設備ちゃんと替えてもらえるかな」
「初期費用、オプションも全部つけた方がよくない？」
と、決めようとするたびに新しい不安が出てくる。

私はといえば、古い設備は後でなんとでもなると思っている楽観派だ。
管理会社のオプションは金稼ぎと疑ってかかる。
初期費用は1円でも抑えたい。

どちらも間違っていない。ただ、その優先順位を事前に合意していなかった。

だから物件を前にするたびに議論がゼロから始まる。
「早く決めたい」という気持ちと「でも不安」が
同じ人の中で共存しているのは矛盾ではなく、
判断の基準が言語化されていないから、どちらも本音として出てくるのだ。

そして満点の物件はまず出てこない。
「あと間取りだけ違えば理想なのに」という物件は出る。
でも「その間取りをどこまで妥協できるか」が言葉になっていないと、
判断のたびに一から考え直すことになる。

問題は物件ではなかった。
決め方を、決めていなかった。

スコアリング軸の設計思想

賃貸選びで最初にやったのは、物件を見ることではなく**「何を基準に決めるか」を言語化すること**だった。

内見した物件の印象は簡単に上書きされる。広いリビングを見た後は狭さが気になり、新築を見た後は築年数が引っかかる。これはバイアスではなく、比較基準が固定されていないことが原因だ。判断が物件に引っ張られている状態では、何十件見ても決断は難しくなるばかりだった。

だから先に「型」を作ることにした。

足切りと採点を分ける

最初に気をつけたのは、条件をすべて点数化しないことだ。

たとえば「幼稚園のバスが通らないエリア」や「ハザードマップで浸水リスクが高い物件」は、他の条件がどれだけ優れていても選択肢に入らない。それを点数にしてしまうと、設備が充実した危険な物件が高得点になるという逆転が起きる。

そこでスコアリングを2層構造にした。

• 必須条件：エリア・バスアクセス・浸水リスク・間取り・家賃上限・築年数。どれか一つでも外れたら即除外、採点すらしない。
• 採点条件：必須をクリアした物件だけを25点満点で評価する。

足切りを先に置くことで、「採点に入った時点でその物件は最低限信頼できる」という状態を作れた。

採点の3層設計

25点の内訳は重要条件12点＋加点条件13点で構成している。

重要条件（各2点、計12点） は生活の骨格になる軸を6つ選んだ。新幹線アクセス・在来線アクセス・主要駅アクセスという交通3軸、最寄り駅の徒歩距離、専有面積70㎡以上、寝室6.5帖以上。どれも「欠けたら毎日のストレスになる」と判断したものだ。各2点と統一したのは、優先順位に差をつけないという意図がある。どれが欠けても同等に痛い。

加点条件（計13点） は設備系の1点項目6つと、家賃・築年数・初期費用の段階配点で構成している。段階配点が重要で、たとえば家賃は「16万以下：3点 / 16〜18万：2点 / 18〜20万：1点 / 20〜22万：0点」と刻んでいる。上限22万は必須条件で足切り済みなので、加点側では**「安いほど良い」という傾斜を点数で表現**している。

初期費用も同様に段階配点にした。礼金・仲介手数料などの合計が家賃の1.55ヶ月以下なら2点、2ヶ月超は0点。「1円でも抑えたい」という自分の優先順位を、点数という形で設計に組み込んだ。

閾値に行動ルールを紐づける

点数を出して終わりにしないために、スコアに応じた行動ルールをあらかじめ決めた。

スコア	行動
21点以上	即決（迷わず申し込む）
20点	候補（他と比較してから判断）
15〜19点	検討中（条件交渉の余地があれば）
14点以下	要再検討

ここで大事なのは「21点以上なら即決」というルールを先に決めたことだ。良い物件に出会った瞬間に閾値を考え始めると、判断が感情に引きずられる。基準は物件を見る前に固定しておく必要があった。

スコアリングとは、未来の自分が感情に負けないための仕組みだと思っている。

この設計はAIとの壁打ちで作った

実はこのスコアリング設計、最初から完成した状態で作ったわけではない。

最初に自分でやったのは「何が外せない条件か」を箇条書きにしただけだった。エリア、広さ、家賃上限……と並べてみたものの、それぞれの重みをどうするか、点数にするかしないかの区別もついていなかった。

そこでClaudeに投げた内容は、ほぼ以下のようなものだ。

「3LDKの賃貸を探している。子どもが2人いて、バスアクセスが必要。通勤は週2回新幹線、週2回在来線でオフィス。感情で決めたくないのでスコアリングしたい。どう設計すればいい？」

返ってきたのは「足切りと採点を分けた方がいい」という示唆だった。致命的な条件を点数化すると逆転現象が起きる、という話は自分では気づいていなかった。

その後も対話を重ねながら設計を詰めていった。たとえば寝室の条件は最初「部屋数があればいい」程度に考えていたが、「大人2人・子ども2人が1部屋で寝られるサイズ感」を言語化したことで、6.5帖以上の洋室が1部屋以上あることという具体的な条件に落ちた。家賃の段階配点や閾値の設定も同じで、「どこで線を引くか」を対話の中で一つずつ決めていった。トータルの壁打ち時間は1時間程度だ。

AIとの壁打ちが有効なのは、「答えを出してもらう」からではなく「自分が見落としている問いを立ててもらえる」からだと思っている。スコアリングの軸は自分の生活から来ているので、AIには決められない。でも設計の構造的な穴は、対話の中で見えてくる。

チャットAIだけでは足りない

スコアリングの設計ができた。最初はシンプルにやろうとした。採点基準をテキストにまとめ、Claude.aiのチャットに貼り付け、物件情報と一緒に送る。それで採点してもらえばいい。

一応は動く。でも続けるうちに、3つの摩擦がある。

毎回、基準を貼り直す必要がある

Claude.aiのチャットは会話をまたいで記憶を持たない。新しいチャットを開くたびに採点基準をコピペしなければならない。基準を育てて長くなるほど、この作業が重くなる。

採点結果がチャット画面に散らばる

10件採点すれば、10回分の会話が残る。「あの物件は何点だったか」を確認するために会話履歴を遡るのは、システムとして機能していない。比較が、できない。

基準の更新が引き継がれない

キャリブレーションで採点基準を修正しても、それは次のチャットには伝わらない。「日当たりを加点に追加した」という変更が、次回の採点に反映される保証がない。

これらはチャットAIの構造的な問題だ。会話の外に何も持てないことが原因で、採点を続けるほど運用コストが上がっていく。

Notionを「外部の記憶」にする

解決策は「AIの外に記憶と基準を置く」ことだ。

Notionに2つのものを置いた。

採点基準ページ：足切り条件・各項目の点数・段階配点の定義・出力フォーマットをすべて書いたページ。ここが採点ロジックの正本になる。

物件星取表DB：採点済みの物件が1行1物件で蓄積されていくデータベース。主なプロパティは物件名・ステータス（検討中/内見済み/見送り）・必須条件クリア・総合スコア・家賃・初期費用・築年数・最寄り駅徒歩・専有面積・メモ。

採点ロジックはDBに持たせない。DBは結果の置き場として使う。採点はClaudeに任せ、基準は採点基準ページが管理する。

物件DBのプロパティ構成はこのとおりだ。Notionで新規データベースを作り、同じプロパティを追加すれば再現できる。

プロパティ名	型	内容
物件名	タイトル	管理会社や物件サイトの表記をそのまま
ステータス	セレクト	検討中 / 内見済み / 見送り / 申し込み済み
必須条件クリア	チェックボックス	足切りをパスしたか
総合スコア	数値	25点満点
家賃（万円）	数値	管理費込みの月額
初期費用（家賃換算）	数値	礼金・仲介手数料等の合計を家賃で割った倍率
築年数	数値	年
最寄り駅徒歩（分）	数値	分
専有面積（㎡）	数値	㎡
メモ	テキスト	内見印象・交渉メモなど

MCPがAIとNotionをつなぐ

MCPという言葉は技術的に聞こえるが、やっていることはシンプルだ。Claude.aiに「Notionを読み書きする権限」を渡す仕組みだと思えばいい。

これがあると、ClaudeはNotionの採点基準ページを自分で読みに行ける。採点基準ページには採点軸だけでなく出力フォーマットも書いてあるため、毎回のプロンプトに「こう出力してください」と指示する必要がない。Notionが採点基準と出力形式の両方を管理する「唯一の正」になっている。

物件情報（コピペ）

↓ 貼り付け＋「採点基準に従って採点してDBに書き込んで」

Claude
  ├─ MCP → Notionの採点基準ページを読む
  ├─ 採点（出力フォーマットも基準ページの指示どおり）
  └─ MCP → Notion DBに書き込む

人間がやることは、物件ページをコピーして貼り付けることだけだ。

MCP自体の設定はClaudeに頼んで構築したので、技術的な詳細は把握していない。それでも使えている。「仕組みを理解していなくても使える」ことが、今のAIツール活用の現在地だと思っている。

「聞く道具」から「育てる道具」へ

チャットボット的な使い方は「質問して答えをもらう」だ。会話が終われば、その内容は消える。

この仕組みは違う。採点基準はNotionで育ち、採点結果はDBに蓄積され、Claudeは次の会話でも同じ基準で動く。使えば使うほど、自分の判断基準が外部化・精緻化されていく。

AIに自分の代わりに決めてもらうのではなく、自分の判断基準を持った道具として育てる。それがこのシステムの本質だ。

運用してみて変わったこと

システムを動かしてみると、予想していた変化と、予想していなかった変化があった。

採点の摩擦が消えた

物件ページをコピーして貼り付け、一言添えるだけで採点とDB書き込みが完了する。慣れれば1物件2〜3分だ。Claudeが返してくる採点結果はこういう形になる。

物件名：〇〇マンション ××号室
家賃：17.5万円
初期費用：1.8ヶ月分
築年数：8年
最寄り駅徒歩：12分
専有面積：72㎡

【重要条件】
新幹線アクセス：2点 / 在来線アクセス：2点 / 主要駅アクセス：2点
最寄り徒歩：1点（12分、基準12分以内で2点の境界）
専有面積：2点 / 寝室6.5帖以上：2点
小計：11点

【加点条件】
家賃：2点（17〜18万）/ 築年数：2点（10年未満）/ 初期費用：1点（2ヶ月以下）
設備（宅配ボックス・床暖房・浴室乾燥・ディスポーザー・2口以上ガス・独立洗面台）：3点
小計：8点

総合スコア：19点 / 25点

フォーマットが毎回揃うのは、採点基準ページに出力形式が書いてあるからだ。プロンプトに指示しなくても形が安定する。

スコアが感覚とズレるとき

運用を始めてすぐ気づいたのは、「感覚では良いと思う物件」と「点数が高い物件」がたまにズレることだった。

そのズレを修正しようとすると、必ず「なぜそう感じるのか」を言語化しなければならない。

採点基準に入れていなかった「南向き・日当たり」が気になった物件があった。そのとき初めて、「日当たりが1点分くらい自分には効いている」と気づいた。Notionの採点基準ページを更新すれば、次の採点から反映される。

こうした調整を何度か繰り返すうちに、採点基準は自分の優先順位を正確に映すものになっていった。スコアリングは一度作れば終わりではなく、使いながら育てるものだった。

運用初期のベンチマークとして残しておいた物件がある。スコアは16点だった。「条件が2〜3個変われば住みたい」という水準だ。「16点の物件がどういう印象か」を体感として持っておくことで、それ以上の物件が出たときに比較軸が機能する。点数は絶対値ではなく、自分の感覚をキャリブレーションするための物差しだ。

変わったのは、物件の見方だけじゃなかった

採点システムを使い始めて気づいたのは「物件を数字で見るようになった」ことだ。だが運用を続けるうちに、もっと大きな変化があった。

妻と物件の話をするとき、議論の出発点が変わった。

以前は「この物件どう思う？」から始まり、それぞれの感想をぶつけ合っていた。築年数への不安、初期費用へのこだわり、広さの感覚——判断軸が違う者同士が、同じ物件を見ながら別々のことを話していた。

スコアができてからは「この物件は19点だけど、1点は徒歩距離で落としてる」という会話ができるようになった。「その1点は許容できるか」「できないなら他のどの条件を諦めるか」——感情ではなく構造の話ができる。

スコアリングは意思決定ツールであると同時に、共通の土台で話すための言語になった。

おわりに

この記事で作ったのは「賃貸を選ぶシステム」だが、本質的にやっていたのは優先順位の言語化だ。

スコアリング設計の壁打ちで条件の構造に気づき、運用しながらキャリブレーションを繰り返すことで採点基準は育った。MCPが書き込みの摩擦を消し、システムを続けられるものにした。そして気づけば、妻との会話が変わっていた。

フェーズ	やったこと	得られたもの
設計	AIと壁打ち	足切りと採点の2層構造
運用	Notionでスコア管理	物件比較の共通軸
自動化	Claude MCP連携	コピペだけで完結するフロー
副産物	キャリブレーション	条件の言語化・夫婦の共通言語

「感情で決めない」というのは、感情を無視することではない。感情が出る前に、判断の型を用意しておくことだ。良い物件に出会ったとき、スコアがすでに「申し込んでいい」と言っていれば、迷う必要はない。