収益物件の比較表を自動作成する方法｜候補収集から通知まで無人化する実践ワークフロー

収益物件を探すたびに、物件サイトを開き、価格や利回りをExcelへ転記し、仲介会社から届いたPDFと照合する。数日後には「この物件を保留にした理由」が分からなくなり、同じページをもう一度調べる――。

この繰り返しに時間を使っていると、候補が増えるほど判断が遅くなります。そこで役立つのが、収益物件の比較表を自動作成するワークフローです。

この記事では、物件情報の取得、必要項目の抽出、表記の統一、比較表への登録、優先順位付け、通知までをつなぐ方法を解説します。完成後に目指す状態は、パソコンの前にいない時間もシステムが候補を整理し、人間には「追加確認が必要な物件」だけが届く運用です。

ただし、比較表の自動作成は購入判断の自動化ではありません。買付、融資、契約、修繕、税務、法務に関する判断は、資料の原本と専門家の確認が必要です。本記事は一般的な情報提供を目的としており、特定の物件の取得を勧めるものではありません。

Hiroサイトの実行ログで分かったこと

この記事は架空の成功談ではなく、Hiroが運用する auto-ai-blog のローカルデータと実行ログを基にしています。

2026年7月18日にリポジトリ内を再集計した結果は次の通りでした。

同じ「収益物件の比較表」テーマについて、2026年7月11日15時57分38秒に処理が始まり、16時05分27秒に最終チェック、Markdown保存、Notion保存が完了しています。ログ時刻の差は約7分49秒です。

一方、2026年7月18日12時27分38秒の実行は、CLIが240秒でタイムアウトし、12時32分03秒に記事生成がスキップされました。

この成功と失敗の両方から、完全自動化には次の要素が必要だと分かります。

• 成功時に比較表や記事を保存する処理
• タイムアウトや抽出失敗を検知する処理
• 失敗した対象を再実行キューへ戻す処理
• 人間へ通知する条件を絞る処理
• 元データと修正履歴を残す処理

無人運転とは、エラーが起きない仕組みではありません。エラーが起きても記録され、安全に停止し、再実行できる仕組みです。この考え方を収益物件の比較表にも適用します。

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

初心者は、ワークフローを5つの部品に分けると理解しやすくなります。

たとえば、物件価格が比較表へ入らなかった場合、入力データが取得できなかったのか、AIが金額を抽出できなかったのか、単位変換に失敗したのかを切り分けられます。

比較表の自動作成によって蓄積されるのは、物件一覧だけではありません。取得元、調査日、抽出結果、修正履歴、見送り理由が残ります。これらは、次回以降の調査時間を減らす自動化資産になります。

収益につながる可能性があるのは、比較表そのものではなく、候補の見落としを減らし、転記に使っていた時間を資料精査や別の収益活動へ振り向けられる点です。利益や成約は保証されません。

ステップ・バイ・ステップで作る自動化ワークフロー

1. 比較表の目的を一文で決める

最初に「何を決める表なのか」を定義します。

初心者向けには、次の目的が扱いやすいでしょう。

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

「良い物件を自動で選ぶ」では範囲が広すぎます。融資条件、建物状態、賃貸需要、権利関係まで一つの点数へ押し込むと、危険な単純化が起きます。

自動判定するのは購入可否ではなく、次に確認する作業です。

2. 比較表の列を固定する

列が毎回変わると自動登録が不安定になります。初期版では、次の項目を用意します。

最初から接道、境界、用途地域、修繕履歴、固定資産税などをすべて入れると、入力負担が増えます。初期比較では候補を絞る列に限定し、精査段階の項目は別シートへ分けます。

3. 情報源を登録する

入力元は、次の3種類に分けます。

1. 物件ポータル
   URL、価格、利回り、所在地、構造などを取得します。自動取得する場合は、対象サイトの利用規約やアクセス制限を事前に確認します。

2. 仲介メール・PDF
   受信日時、送信元、件名、添付ファイル名を残します。同じ物件でも資料の更新版が届くことがあるため、ファイル名だけでなく取得日時も必要です。

3. 人間の確認メモ
   仲介会社への電話確認、現地調査、金融機関からの回答などを登録します。確認済みの事実と担当者の所感は別の列に分けます。

情報源が残っていない数値は、誤りを発見しても原本へ戻れません。

4. AIの出力形式をJSONに固定する

自由文の要約は読みやすい一方、比較表へ自動登録しにくい形式です。AIには次のようなJSONを返させます。

{
  "property_name": "菊名駅7分 一棟アパート",
  "price_million_yen": 3360,
  "gross_yield_percent": 12.21,
  "current_annual_rent_million_yen": null,
  "rent_basis": "満室想定",
  "building_age_years": 42,
  "structure": "木造",
  "units": 8,
  "source": "物件ポータル",
  "acquired_date": "2026-06-29",
  "needs_human_check": true,
  "human_check_reason": "現況年間賃料と修繕履歴が未確認"
}

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

• 不明な値を推測で埋めず null にする
• 金額と利回りは数値型で返す
• 満室想定と現況を別項目にする
• 根拠となるページまたはファイル名を返す
• 人間確認が必要な理由を書く

空欄は調べ直せます。もっともらしい推測値は、誤情報だと気づかず使われる恐れがあります。

5. 単位と表記を正規化する

「3,360万円」「3360万」「33,600,000円」が混在すると、並べ替えや計算が崩れます。比較表へ登録する前に統一します。

変換できない値は無理に登録せず、エラー表へ送ります。「価格応相談」や「利回り未掲載」をゼロとして扱うと、実在するゼロと区別できません。

6. バリデーションを実行する

登録前に、データの異常を検査します。

• URLまたは資料名が空欄ではないか
• 取得日が入っているか
• 価格が文字列のままではないか
• 利回りの計算根拠が記録されているか
• 満室想定賃料と現況賃料が混ざっていないか
• 戸数より入居戸数が多くなっていないか
• 同一URLや同一住所が重複していないか
• AIが推測した値に確認フラグが付いているか

HiroサイトではAIスロップ防止関連のテスト3件を2026年7月18日に実行し、終了コード0を確認しました。収益物件のワークフローでも、比較表を目視する前に機械的な検査を通す構成が有効です。

7. 「見る順番」を自動分類する

総合点だけで購入候補を決めず、次の作業に分類します。

Hiro側の物件データ7件には、価格480万円・表面利回り17.5%・築45年・1戸というレコードがありました。数値は2026年6月29日のNotion記録に基づきます。利回りだけなら上位に見えますが、戸数、建物状態、融資条件、現況賃料を確認しなければ評価できません。

そのため、「高利回り＝高得点」ではなく「高利回りだが追加確認あり」と分類する方が安全です。

8. 通知と再実行を設定する

比較表が更新されても、毎日人間が開いて確認するなら完全自動化には届きません。通知は次のように絞ります。

• 新規候補が登録された
• 必須項目がそろいA分類になった
• needs_human_check が真になった
• 取得処理がタイムアウトした
• 同じエラーが連続した
• 取得日から設定日数を超えた
• 以前の物件と重複した

2026年7月18日のHiroサイトでは、生成処理が240秒でタイムアウトしました。この種の失敗を黙って捨てると、候補の取りこぼしに気づけません。失敗行を再実行キューへ移し、一定回数を超えた場合だけ人間へ通知します。

平常時は無人で動き、例外時だけ確認を求める設計なら、自分の時間を消耗しにくくなります。

専門家目線のチェックポイント

表面利回りを最終判断に使わない

表面利回りは、一般に年間賃料を物件価格で割った指標です。管理費、空室、修繕、税金、保険、購入諸費用、融資金利などが反映されていない場合があります。

比較表では、少なくとも次を分けます。

• 売主資料上の表面利回り
• 満室想定年間賃料
• 現況年間賃料
• 入居戸数と総戸数
• 運営費の確認状況
• 修繕履歴の確認状況

満室想定と現況を混ぜない

販売資料の年間賃料が満室時の想定なのか、現在の入居状況に基づくのかで意味が変わります。

AIが判別できなかった場合は、「不明」として人間へ戻します。周辺相場から推測した賃料を、現況賃料として登録してはいけません。

自動取得の規約を確認する

物件サイトへ機械的にアクセスする方法は、サイトごとに扱いが異なります。公式API、許可されたCSV、受信メール、手動保存したPDFなど、利用条件を確認できる入力元を優先します。

規約を確認できないサイトを無理に自動取得する運用には向きません。

法務・税務・建物状態を自動確定しない

次の項目はフラグ付けまでにとどめ、原本と専門家へ確認します。

• 再建築の可否
• 接道や境界
• 用途・建築上の制限
• 契約条件
• 権利関係
• 税務上の処理
• 違法建築・既存不適格に関する判断
• 修繕費や建物状態

AIの回答を重要事項説明書や専門家の確認の代わりにはできません。

画像で説明すべき箇所と視覚的証拠

記事内へ追加すると理解が深まる画像は、次の3種類です。

1. 入力から通知までのフロー図
   URL・メール・PDFからAI抽出、JSON変換、比較表、通知へ流れる図。

2. 比較表の実画面スクリーンショット
   物件名や住所を匿名化し、価格、利回り、取得日、情報源、要確認理由が並ぶ画面を掲載します。

3. 成功ログと失敗ログの対比
   2026年7月11日の保存成功行と、2026年7月18日の240秒タイムアウト行を並べます。自動化が正常系だけで成立していないことを示す視覚的証拠になります。

画像生成による概念図だけでなく、個人情報や認証情報を隠した実ログのスクリーンショットを入れると、類似記事との差が明確になります。

よくある失敗と対策

AIが空欄を推測で埋める

原因: 「不足項目も補って」と指示している。

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

同じ物件が何度も登録される

原因: 掲載サイトごとにURLや物件名が違う。

対策: URLだけでなく、住所、価格、構造、戸数を組み合わせた重複判定を行います。完全一致しない場合は重複候補として保留します。

単位が混在して計算が壊れる

原因: 円、万円、億円が同じ列に入っている。

対策: AI抽出後、比較表へ登録する前に数値と単位を分離します。変換できない行はエラー表へ送ります。

高利回り物件ばかり通知される

原因: 利回りだけを通知条件にしている。

対策: 取得日、情報源、賃料根拠、築年数、戸数、確認フラグを組み合わせます。通知は購入推奨ではなく、確認順序として扱います。

エラー後に処理が止まったままになる

原因: 正常終了だけを想定している。

対策: タイムアウト、認証切れ、JSON解析エラー、保存エラーを別々に記録し、再実行回数と通知条件を設定します。

自動化したのに毎日表を確認している

原因: 通知設計がない、または全件通知している。

対策: 人間の判断が必要な行、失敗した行、新規候補だけを通知します。正常に登録できた行は週次集計へ回します。

成果を測るKPI

自動作成した件数だけでは、時間や収益機会が改善したか判断できません。次のKPIを記録します。

収益KPIには、物件取得後の実績と比較表の効果を混ぜない配慮が必要です。比較表が直接利益を生んだと断定せず、「自動化経由で発見した候補」「人力で発見した候補」を分けて記録します。

このワークフローが使えないケースと限界

次のケースでは、完全自動化より個別調査が適しています。

• 公開情報が少ない未公開物件
• 権利関係が複雑な案件
• 再建築や接道の判断が中心になる物件
• 大規模修繕や用途変更を前提とする案件
• OCRで読み取りにくい古い図面
• 利用規約上、機械取得が認められていないサイト
• 取引件数が少なく、比較対象を確保できない地域

また、自動化しても、認証切れ、サイトの仕様変更、PDF形式の変更、AIの抽出ミスは起こり得ます。「一度作れば永久に放置できる」とは限りません。月次でエラー率と修正履歴を確認し、普段は無人で動かす運用が現実的です。

類似記事との差別化ポイント

一般的な比較表の記事は、Excelの列や利回り計算を紹介して終わることがあります。本記事では、次の範囲まで扱いました。

• URL・メール・PDFからの入力
• JSONによる構造化
• 単位の正規化
• 不明値を推測しないルール
• 購入可否ではなく確認順序の分類
• 成功ログとタイムアウトログ
• 再実行と例外通知
• 修正履歴を次回ルールへ戻す仕組み
• 人間の確認時間と収益経路を測るKPI

比較表を一度作る作業ではなく、候補と判断履歴が増えるほど使いやすくなる不労所得的な自動化資産として設計している点が差別化になります。

読了後すぐにできるアクション

今日の作業は、次の1件に絞ってください。

1. 手元の収益物件を1件選ぶ
2. Google SheetsまたはExcelに「価格・利回り・賃料種別・築年数・構造・戸数・情報源・取得日・要確認理由」の列を作る
3. 物件資料をAIへ渡し、固定JSONで抽出する
4. 元資料と照合し、誤りを修正ログへ残す
5. 次に確認する作業を「資料・融資・現地・情報不足・保留」から選ぶ

1件で正しく動いたら5件へ増やします。最初から大量データを流すと、誤った列設計や抽出ルールまで大量複製されます。

まとめ：比較作業を、眠っている間も育つ情報資産へ変える

収益物件の比較表を自動作成するワークフローは、情報取得、AI抽出、正規化、検証、分類、通知の順で組み立てます。

人間が担当するのは、原本確認、融資、建物、法務、税務、購入判断です。システムには、転記、重複確認、形式統一、期限監視、例外通知を任せます。

この役割分担ができると、毎晩物件サイトを巡回して表を埋める生活から離れられます。候補がない日は静かに終了し、確認が必要な案件やエラーが出たときだけ通知する。修正内容は次回の抽出ルールへ戻し、比較表は運用するほど精度を上げていきます。

収益は保証されません。それでも、手作業を繰り返す状態から、データと判断履歴が残る状態へ移行することはできます。自分の時間を切り売りせず、収益機会を探し続ける仕組みを持つための土台になります。

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

「比較表を作って終わり」では、まだ人間が動き続けなければなりません。

情報収集、AI処理、比較、通知、コンテンツ化、販売導線までつなげれば、あなたが画面を見ていない時間にも仕組みが働きます。必要なのは、気合いで作業量を増やす方法ではなく、一度作った工程が繰り返し価値を生む設計です。

本気で自動化・不労所得を構築したい方向けに、実装手順をまとめた実践マニュアルを用意しています。

次の自動化資産を作り始める方はこちら：/products/