収益物件の比較表を自動作成する方法｜情報収集・利回り検算・通知までの実践手順

「表面利回りは高いのに、現況家賃が分からない」「同じ物件を別サイトで何度も確認している」「価格変更に気づいたときには掲載が終了していた」。

収益物件を探していると、判断そのものより、検索・転記・再計算・更新確認に時間を取られます。物件数が増えるほど比較表は古くなり、見送り理由や計算条件も分からなくなりがちです。

そこで本記事では、収益物件の比較表を自動作成し、数字を検算したうえで、確認すべき候補だけを通知するワークフローを解説します。

完成後に目指すのは、次の状態です。

• 許可された情報源から物件データを定期取得する
• 円・万円、徒歩分数、築年月などの表記を統一する
• 掲載利回りとは別に、同じ式で利回りを再計算する
• 欠損、重複、異常値、更新差分を検出する
• 資料請求や現地確認が必要な物件だけを通知する
• 元データ、検算結果、見送り理由を履歴として残す

ただし、自動化するのは購入判断ではなく、一次選別と確認作業の整理です。現地調査、契約・権利関係、建物状態、融資、税務などは、資料の原本と専門家の確認が必要です。

本記事は一般的な情報提供であり、特定物件の購入を推奨する投資助言ではありません。

収益物件の比較表を自動作成する全体像

ワークフローは、次の9工程に分けます。

1. 情報を取得する
   ↓
2. 原文・取得日時・情報源を保存する
   ↓
3. 必要項目を抽出する
   ↓
4. 単位と表記を正規化する
   ↓
5. 利回り・NOI・返済後CFを再計算する
   ↓
6. 欠損・重複・異常値を検査する
   ↓
7. 比較表と変更履歴へ登録する
   ↓
8. 条件に合う候補だけを通知する
   ↓
9. 人間が資料・融資・現地・法務を確認する

重要なのは、取得、抽出、計算、検証、保存を一つの処理に詰め込まないことです。

工程を分けておけば、価格が空欄になったときに「ページを取得できなかったのか」「金額抽出に失敗したのか」「単位変換で止まったのか」を切り分けられます。

最初に決めるべき「自動化する範囲」

初心者が最初から「良い物件をAIに選ばせる」と、判断根拠が不透明になります。

まずは目的を、次の一文に限定してください。

新着物件の中から、追加資料を確認する候補を絞り込む。

システムに任せる作業と、人間が担当する作業も分けます。

この線引きを崩さないことが、比較表を過信しないための第一歩です。

比較表に必要な列

初心者はGoogleスプレッドシートやExcelから始めると、抽出結果や計算式を目視できます。データ量や更新回数が増えたら、データベースへ移行します。

一次選別で使う列

保存形式も固定する

列名だけでなく、単位とデータ型まで決めます。

price_yen              販売価格・整数・円
annual_rent_yen        満室想定年収・整数・円
current_rent_yen       現況年収・整数またはnull・円
listed_yield_pct       掲載ページ上の利回り・数値・%
calculated_yield_pct   再計算した表面利回り・数値・%
built_year_month       築年月・YYYY-MM
walk_minutes           掲載情報上の徒歩分数・整数
source_url             取得元URL
fetched_at             取得日時・ISO 8601
validation_status      normal / review / excluded

「価格」列に円と万円を混在させてはいけません。内部保存は円へ統一し、画面表示だけ万円に変換すると計算ミスを減らせます。

また、未確認の値は null、確認済みのゼロは 0 として区別します。

Hiroの一次ログで確認できた「成功」と「途中失敗」

このサイトの auto-ai-blog では、生成、レビュー、最終確認、ファイル保存、Notion保存を工程別に記録しています。

generator/logs/generate.log の2026年7月11日の記録を確認すると、「AIを使った競合物件リサーチの進め方」に対して、次の処理が実行されていました。

テーマ選択からNotion保存までの経過時間は、ログ時刻の差で約9分13秒です。

ただし、これは収益物件の取得時間や投資成果ではありません。Hiroが運用する記事生成工程の実測値です。収益物件の比較システムが同じ速度で動くことを示すデータでもありません。

このログから参考にできるのは、次の設計です。

ファイルを作成できた ≠ 内容の検証に合格した
比較表へ登録できた   ≠ 数字の根拠を確認できた
利回りを計算できた   ≠ 家賃設定が妥当である
通知を送信できた     ≠ 購入条件を確認できた

さらに、最初のレビューツールが失敗しても、代替処理へ切り替えて完了しています。完全自動化で重要なのは「失敗しないこと」ではなく、失敗した工程、代替処理、最終結果を追跡できることです。

収益物件の比較表を自動作成する9ステップ

ステップ1．比較条件と除外条件を決める

ツールを選ぶ前に、何を探す比較表なのかを決めます。

最低限、次の項目を文章にしてください。

• 対象エリア
• 一棟、区分、戸建てなどの物件種別
• 木造、鉄骨造、RC造などの構造
• 価格帯
• 築年数
• 最低戸数
• 駅距離
• 再建築不可、借地権などの除外条件
• 資料請求へ進める条件
• 人間による確認が必要な条件

最初の条件は、確定基準ではなく「仮条件」として登録します。

たとえば利回りの下限だけで除外すると、土地価値、修繕状態、稼働実績などを確認する前に候補を落とす可能性があります。自動判定は「購入」「見送り」ではなく、「資料確認」「融資確認」「情報不足」のような次の作業へつなげます。

ステップ2．取得元と利用条件を確認する

取得元には、次の選択肢があります。

• 正式に提供されたAPIやCSV
• 不動産会社から届くメール
• 手元へ保存した販売図面やPDF
• 自社で管理しているデータ
• 利用条件を確認済みの物件サイト

確認項目は次のとおりです。

• APIやCSVが提供されているか
• 利用規約で自動アクセスが制限されていないか
• アクセス頻度の上限があるか
• ログイン後の情報を保存してよいか
• 個人情報や非公開情報が含まれないか
• 保存データを第三者へ再公開してよいか

robots.txt はクローラーがアクセスできるURLを管理する仕組みですが、データ取得や再利用に対する包括的な許諾ではありません。対象サイトの利用規約、契約、API条件を別に確認してください。Googleのrobots.txt解説

利用条件を確認できない場合は、無理に画面を解析せず、メール受信、正式なデータ提供、手動アップロードを入口にします。

ステップ3．元データと取得時点を保存する

抽出後の数字だけを残すと、誤変換が起きたときに原因を追えません。

可能な範囲で、次の情報を保存します。

• 取得元URL
• 取得日時
• ページやメールの原文
• 元ファイル名
• 資料の版や発行日
• 抽出プログラムのバージョン
• 同じ物件を識別する情報源ID
• 抽出した箇所の引用または位置情報

ただし、ページや資料の保存は、利用規約、契約、著作権、個人情報の取り扱いを確認した範囲で行います。

ステップ4．物件情報を固定JSONで抽出する

CSVのように書式が一定なら、まずルールベースで抽出します。自由記述のメールやPDFは、AI抽出を補助的に使えます。

AIへ自由文を返させるのではなく、出力形式を固定します。

{
  "source_property_id": "sample-001",
  "price_yen": 48000000,
  "annual_rent_yen": 4200000,
  "current_rent_yen": null,
  "rent_basis": "満室想定",
  "structure": "木造",
  "built_year_month": "2001-03",
  "total_units": 8,
  "occupied_units": null,
  "evidence": {
    "annual_rent_yen": "販売図面の満室想定年収欄",
    "structure": "物件概要の構造欄"
  },
  "needs_human_check": true,
  "human_check_reason": [
    "現況年収が未確認",
    "入居戸数が未確認"
  ]
}

これは形式説明用の架空例です。

AIへの指示には、次の制約を入れます。

• 確認できない値は null にする
• 周辺相場から現況値を推測しない
• 金額と利回りは数値型で返す
• 満室想定と現況を別項目にする
• 数値ごとに抽出根拠を返す
• 人間による確認が必要な理由を書く

ステップ5．単位と表記を正規化する

正規化とは、異なる書き方を比較可能な形式へそろえる処理です。

駅距離は、元の表記と正規化値を分けて残します。

walk_text_original = "駅徒歩7分"
walk_minutes       = 7
distance_meters    = null

距離から徒歩分数へ換算する場合、不動産広告では道路距離80メートルを徒歩1分として扱い、端数を切り上げる規定があります。ただし、信号待ち、坂道、改札からホームまでの時間などを表すものではありません。不動産の表示に関する公正競争規約施行規則

ステップ6．利回り・NOI・返済後CFを再計算する

掲載値と再計算値は別々に保存します。

再計算表面利回り
＝ 満室想定年収 ÷ 販売価格 × 100

たとえば、販売価格4,800万円、満室想定年収420万円なら次の計算です。

420万円 ÷ 4,800万円 × 100 ＝ 8.75%

Googleスプレッドシートで、販売価格がB2、満室想定年収がC2なら、空欄を除外する式は次のように書けます。

=IF(OR(B2="",C2=""),"",C2/B2*100)

NOIと返済後キャッシュフローは、次のように分けます。

実効総収入
＝ 賃料収入など － 空室損・滞納損

NOI
＝ 実効総収入 － 物件運営費

返済後CF
＝ NOI － 年間元利返済額

NOIは、一般に借入返済や減価償却を控除する前の物件収益を表しますが、資料によって費用範囲が異なる場合があります。固定資産税、管理費、保険、共用部光熱費、通常修繕など、何を含めたかを列定義に残してください。国土交通省「不動産証券化に係る用語集」

元利均等返済の概算は、月利と返済回数を使って計算できます。Googleスプレッドシートでは次の式です。

=-PMT(年利/12, 返済年数*12, 借入額)*12

さらに、返済余力を見る補助指標としてDSCRを置けます。

DSCR ＝ NOI ÷ 年間元利返済額

ただし、利回りやDSCRだけで購入可否を決めてはいけません。標準ケースと慎重ケースを作り、空室率、修繕費、金利などを変えて比較します。

ステップ7．欠損・重複・異常値を検査する

比較表へ登録する前に、機械的な検査を実行します。

必須項目の検査

• 販売価格が空欄ではないか
• 満室想定と現況が区別されているか
• 情報源と取得日時があるか
• 数値の根拠へ戻れるか

数値の整合性検査

• 築年月が未来になっていないか
• 入居戸数が総戸数を超えていないか
• 土地面積や延床面積が負数になっていないか
• 掲載利回りと再計算利回りの差が大きすぎないか

掲載値との差は、たとえば次の式で確認できます。

=IF(OR(D2="",E2=""),"",ABS(D2-E2))

差が設定値を超えたら、通知ではなく「要確認」へ送ります。差異の原因には、価格変更、共益費、駐車場収入、満室想定と現況の混同などがあります。

重複検査

URLだけでは、別サイトに掲載された同じ物件を検出できません。

次の情報を組み合わせて、重複候補キーを作ります。

正規化住所
＋ 販売価格
＋ 構造
＋ 戸数
＋ 築年月

完全一致しなくても、住所と建物条件が近ければ「重複候補」として人間へ戻します。自動的に片方を削除すると、価格や資料内容の違いを失う可能性があります。

ステップ8．比較表と変更履歴へ登録する

検証結果は、次の3状態に分けます。

更新時は、既存行を無条件に上書きしません。

取得日        販売価格    満室想定年収   変更内容
2026-07-01    5,000万円   420万円        新規
2026-07-08    4,800万円   420万円        価格変更

これは履歴設計を説明するための架空例です。

変更前後を残せば、値下げ、想定家賃の変更、掲載期間、再掲載などを分析できます。

ステップ9．行動が必要な候補だけを通知する

全件を通知すると、通知そのものが確認されなくなります。

通知対象は次のように絞ります。

• 新着で、除外条件に該当しない
• 必須項目と根拠がそろった
• 掲載利回りと再計算値に差がある
• 前回から価格や想定年収が変わった
• 現況年収や入居状況が不足している
• 取得、抽出、保存のいずれかが失敗した
• 同じ失敗が設定回数以上続いた

通知には、最低限次を含めます。

物件名
販売価格
掲載利回り
再計算利回り
賃料の前提
不足項目
要確認理由
掲載URL
比較表へのリンク

「高利回り物件です」ではなく、「現況年収が不明なのでレントロール確認が必要です」のように、次の行動が分かる通知にします。

実行ログに残す項目

無人運転では、正常終了だけでなく失敗も記録します。

実行ID
開始日時・終了日時
取得元
取得件数
抽出成功件数
新規件数
更新件数
重複候補件数
要確認件数
通知件数
失敗した工程
エラー内容
再実行回数
最終状態

処理結果は、少なくとも次のように区別します。

取得成功・検証成功・保存成功
取得成功・検証失敗・保存保留
取得失敗・再実行待ち
保存失敗・再送待ち
規定回数失敗・人間確認待ち

エラー行を削除してはいけません。異常を見えなくするのではなく、比較対象から外した状態で原因を残します。

専門家目線で確認したいポイント

高利回りより「数字の確からしさ」を見る

表面利回りが高くても、満室想定家賃の根拠が古ければ比較材料として弱くなります。

最低限、次を確認します。

• 現況レントロール
• 入居日と契約期間
• 滞納の有無
• フリーレントの有無
• 共益費、駐車場、自販機などの収入内訳
• 管理費、共用部光熱費、保険料
• 固定資産税・都市計画税
• 原状回復や修繕費の実績
• 退去予定や募集条件

融資期間を築年数だけで断定しない

構造や法定耐用年数は融資検討の材料になりますが、実際の融資期間は金融機関、借り手の属性、担保評価、物件状態、取引実績などでも変わります。

比較表では、次のように状態を分けます。

• 未確認
• ルールによる仮試算
• 金融機関へ打診中
• 回答案あり
• 正式審査中
• 正式条件を受領

「推定融資期間」を確定値のように扱わないことが重要です。

AI抽出には証拠を添える

AIが想定年収を抽出した場合は、元資料の該当箇所も保存します。

数字だけでは、次の取り違えを発見しにくくなります。

• 月額と年額
• 万円と円
• 満室想定と現況
• 共益費込みと共益費別
• 住居賃料と駐車場収入
• 税込と税別

自動化の合格基準を決める

「処理が動いた」だけでは合格にしません。

たとえば、次をすべて満たした場合だけ正常とします。

取得元が記録されている
取得日時が記録されている
必須項目がそろっている
数値の根拠へ戻れる
再計算が完了している
異常値検査を通過している
保存先への登録が確認できる

よくある失敗と対策

失敗1．掲載利回りをそのまま比較する

原因: 物件ごとに賃料や費用の前提が違う。

対策: 掲載値を残し、同じ式で計算した再計算利回りを別列にする。

失敗2．空欄をゼロとして処理する

原因: 未確認と実績ゼロを区別していない。

対策: 未確認は null、確認済みのゼロは 0 とする。

失敗3．AIが不足情報を推測する

原因: 「空欄を補完して」と指示している。

対策: 不明値は null、推測による登録は禁止し、確認理由を必須にする。

失敗4．同じ物件が何度も登録される

原因: URLや物件名だけで重複判定している。

対策: 住所、価格、構造、戸数、築年月を組み合わせる。曖昧な一致は重複候補として残す。

失敗5．取得元の変更で全工程が止まる

原因: 取得、抽出、計算、保存を一つの処理にしている。

対策: 工程を分け、失敗工程から再実行できるようにする。

失敗6．通知が多すぎて見なくなる

原因: 新着をすべて通知している。

対策: 価格変更、条件一致、データ異常、処理失敗など、行動が必要な通知に絞る。

失敗7．比較表を購入判断として使う

原因: 検算済みとデューディリジェンス済みを混同している。

対策: 比較表は一次選別専用と定義し、資料、現地、法務、融資、税務を別工程にする。

成果を測るKPI

導入前の手作業を数回計測し、その中央値を基準値にします。業界平均ではなく、自分の運用との比較が重要です。

収益額だけをKPIにすると、市況、融資、物件供給など、自動化以外の影響が混ざります。

「自動化経由で発見した候補」と「手作業で発見した候補」を分け、一次選別時間や資料請求率と一緒に評価してください。

このワークフローの反論と限界

「手作業の方が早いのでは？」

対象が数件だけなら、その通りです。

自動化には設計、テスト、保守の時間がかかります。月に数件しか確認しない場合は、計算式と入力規則を設定したスプレッドシートだけで十分なこともあります。

自動取得の価値が出やすいのは、複数の情報源を繰り返し確認し、更新差分を追う場合です。

「AIを使わずルール処理だけでよいのでは？」

CSVや書式固定のメールなら、ルール処理の方が速く、安定しやすい場合があります。

AIは、自由記述や書式の異なるPDFから補助的に項目を抽出する用途に限定し、金額計算と検証は決定的なルールで処理するのが安全です。

完全自動化が向かないケース

次の案件は、早い段階から個別調査を優先します。

• 未公開情報が中心の物件
• 権利関係が複雑な案件
• 再建築や接道判断が中心になる物件
• 大規模修繕や用途変更を前提とする案件
• OCRで読み取りにくい古い資料
• 自動アクセスの利用条件を確認できないサイト
• 比較対象が少ない地域や特殊用途物件

また、認証切れ、サイト仕様の変更、PDF形式の変更、API停止、AIの抽出ミスは発生します。

現実的な目標は「永久に放置できる仕組み」ではなく、正常時は自動で流れ、異常時だけ理由付きで止まる仕組みです。

類似記事との違い

一般的な比較表の記事は、列の作り方や表面利回りの計算で終わりがちです。

本記事では、次の範囲まで含めました。

• 原文と取得時点の保存
• 掲載値と再計算値の分離
• 満室想定と現況の分離
• AI抽出結果への証拠付与
• 欠損、重複、異常値の検査
• 変更履歴の保存
• 途中失敗からの再実行
• 購入可否ではなく次の確認作業への分類
• 成功率、誤抽出率、復旧時間を含むKPI
• Hiroサイトの成功・失敗・代替実行を含む一次ログ

比較表そのものではなく、候補、根拠、失敗、修正、見送り理由が蓄積される仕組みとして設計している点が差別化ポイントです。

今日から始める最小構成

最初から複数サイトを接続する必要はありません。

今日は、次の手順だけを実行してください。

1. 手元の収益物件を1件選ぶ
2. Google SheetsまたはExcelを開く
3. 「価格、掲載利回り、満室想定年収、現況年収、築年月、構造、戸数、情報源、URL、取得日、検証状態」の列を作る
4. 掲載資料を見ながら1件だけ入力する
5. 表面利回りの再計算式を追加する
6. 掲載値との差を確認する
7. 不明な項目はゼロにせず「未確認」とする
8. 次の作業を「資料確認、融資確認、現地確認、情報不足、保留」から選ぶ
9. 修正したセルと理由を別シートへ残す

1件で正しく動いたら5件へ増やします。

最初から大量の物件を流すと、誤った列定義や計算式まで大量に複製されます。小さく作り、原本照合で問題を潰してから定期実行へ進んでください。

まとめ｜比較表を作るのではなく、検証履歴が残る仕組みを作る

収益物件の比較表を自動作成するワークフローは、次の順序で構築します。

1. 比較目的と除外条件を決める
2. 利用条件を確認した情報源を選ぶ
3. 列、単位、データ型を固定する
4. 原文、根拠、取得日時を保存する
5. 必要項目を抽出して正規化する
6. 利回り、NOI、返済後CFを同じ前提で計算する
7. 欠損、重複、異常値を検査する
8. 比較表と変更履歴へ登録する
9. 行動が必要な候補だけを通知する

自動化が収益を保証するわけではありません。高利回りの表示が、現況家賃、建物状態、融資条件、法的な問題を解決してくれるわけでもありません。

それでも、検索、転記、再計算、重複確認、更新監視を仕組みに任せれば、人間は資料精査、現地確認、金融機関との調整、価格交渉などに時間を使えます。

目指すべきは、判断を機械へ丸投げすることではありません。数字の根拠と異常を機械に整理させ、人間が重要な例外へ集中できる状態です。

本気で自動化・不労所得を構築したい方へ

「比較表を作って終わり」では、数週間後に手作業へ戻りがちです。

継続運用には、データ取得、AI処理、検算、保存、通知、失敗時の再実行を一つの流れとして設計し、止まった場所を特定できる仕組みが必要です。

Hiroの実践マニュアルでは、画面を見ていない時間にも動くワークフローを、保守可能な自動化資産へ育てる手順を実装単位で解説しています。

断片的なノウハウを集め続ける状態から抜け出し、自分専用の自動化ワークフローを構築したい方は、商品一覧を確認してください。

▶ 本気で自動化・不労所得を構築したい方向けの実践マニュアルを見る