収益物件の比較表を自動化する方法｜NOI計算・異常検知・通知まで実装する9ステップ

「物件情報を表へ転記している間に、新着物件が増えてしまう」「表面利回りでは魅力的でも、空室や経費を反映すると順位が変わる」「毎朝ポータルサイトを巡回する作業に時間を取られる」。

収益物件を継続的に探している人ほど、こうした問題に直面します。手作業で作った比較表は、その時点では役立っても、価格変更や掲載終了が発生すれば、すぐに古い資料になります。

そこで構築したいのが、物件情報の取得、項目の統一、収支計算、ランキング、保存、通知までを連続処理する収益物件比較表の自動作成ワークフローです。

この記事では、初心者でも実装順序を判断できるように、必要な項目、計算式、異常検知、KPI、停止条件を具体化します。読了後には、手元にある3物件を使って、比較表の試作を始められる状態を目指します。

狙うのは単なる時短ではありません。一度作った処理を定時実行し、自分がパソコンを操作していない時間にも候補物件が整理される再利用可能な自動化資産へ育てることです。

ただし、自動作成された比較表は投資判断を補助する資料です。利益や購入成果を保証するものではなく、元データが誤っていれば計算結果も誤ります。最終判断では、現地調査、契約書類、法令、融資条件などの確認が必要です。

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

ワークフローは、次の7層に分けると理解しやすくなります。

1. 取得：CSV、メール、API、許可されたWebページなどから物件情報を集める
2. 保存：加工前のデータを日時付きで残す
3. 正規化：価格、面積、住所、築年数などの表記を統一する
4. 計算：表面利回り、NOI、NOI利回りなどを同じ式で算出する
5. 検査：欠損、重複、異常値、更新停止を検知する
6. 出力：GoogleスプレッドシートやExcelへ比較表を作る
7. 通知：条件に合う新着物件や処理失敗をメールなどで知らせる

ここでいう正規化とは、異なる書き方を同じ形式へ変換する処理です。たとえば「5,480万円」「54800000円」「54.8百万円」を、すべて整数の54800000へ統一します。

この構造なら、情報源が増えても計算部分を使い回せます。比較表を毎回作り直すのではなく、データが入れば同じ基準で更新される仕組みに変えられます。

比較表に入れる項目

最初から大量の列を作ると、欠損だらけの表になりがちです。まずは比較と検算に使う列へ絞ります。

NOIは、物件運営によって得られる純収益を示す指標です。本稿では、説明のために次のように単純化します。

実効年間収入 ＝ 満室想定年収 ×（1 − 想定空室率）
NOI ＝ 実効年間収入 − 年間運営費
NOI利回り ＝ NOI ÷ 物件価格 × 100

年間運営費には、管理費、固定資産税、保険料、定常的な修繕費などを含めます。一方、本稿のモデルでは、借入返済、所得税、減価償却、大規模修繕などの資本的支出は含めません。

何を含めるかによってNOIの意味は変わります。列名と計算定義を別シートに残し、担当者や計算時期によって式の意味が変わらないようにしてください。

架空の3物件で計算結果を検証

以下は、式の動作を確かめるために作成したモデルデータです。実在物件の運用実績ではありません。

入力するのは「物件価格、満室想定年収、空室率、年間運営費」の4項目です。

Aの計算過程は次のとおりです。

実効年間収入
＝ 384万円 ×（1 − 0.05）
＝ 364.8万円

NOI
＝ 364.8万円 − 75万円
＝ 289.8万円

NOI利回り
＝ 289.8万円 ÷ 4,800万円 × 100
＝ 6.0375%
≒ 6.04%

AとCの表面利回りは、どちらも8.00%です。しかし、空室率と運営費を反映すると、NOI利回りはAが6.04%、Cが5.04%になります。

表面利回りだけで順位付けすると、経費負担や空室リスクの大きい物件を上位に表示する可能性があります。実務では、固定資産税、原状回復費、入居者募集の広告料、修繕履歴、大規模修繕、借入条件などを確認し、モデル値を実データへ置き換える必要があります。

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

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

「高利回り物件を探す」だけでは、基準が曖昧です。たとえば、次のように定義します。

毎朝取得した収益物件から、必須項目がそろい、指定地域内にあり、NOI利回りと築年数の条件を満たす候補を抽出する。

購入候補の探索、営業提案、相場観測、ブログ記事の素材収集では、必要な列が異なります。目的を先に固定すると、判断に使わないデータの取得や保守を減らせます。

2. データ辞書を作る

データ辞書とは、各列の意味、形式、単位、欠損時の扱いを定めた仕様書です。

property_id：掲載元と掲載番号を結合した一意の文字列
price_yen：物件価格、整数、単位は円
annual_rent_yen：満室想定年収、整数、単位は円
vacancy_rate：0以上1以下の小数
operating_cost_yen：年間運営費、整数、単位は円
fetched_at：取得日時、ISO 8601形式
source_url：取得元を確認できるURL

「利回り」のように計算方法が複数ある項目は、gross_yieldとnoi_yieldのように分けます。

さらに、次の3点も決めておくと実装時の混乱を減らせます。

• 金額を円単位で保存するか、万円単位で保存するか
• 利回りを0.08で保存するか、8.0で保存するか
• 不明値を空文字、null、ゼロのどれで表すか

おすすめは、金額を円単位の整数、利回りを0.08のような小数、不明値をnullで保存する方式です。

3. 利用できる情報源を確認する

取得元は、次の優先順位で検討します。

• 正式なAPI
• 提供元が許可しているCSVやデータフィード
• 自分に届いたメールや添付ファイル
• 利用規約で自動取得が認められたページ
• 手入力フォーム

技術的に取得できても、規約上許可されているとは限りません。アクセス頻度、データの保存期間、転載可否、認証情報の扱いを確認してください。

CAPTCHAやログイン制限の回避を前提にした設計は、規約上の問題だけでなく、安定運用にも向きません。取得方法に迷う場合は、APIや正式なデータ提供の有無を提供元へ確認するのが安全です。

4. 加工前データを保存する

取得直後のデータを上書きせず、日付や実行IDごとに保存します。

raw/2026-07-22/run-20260722-060000/source-a.csv
raw/2026-07-22/run-20260722-060000/source-b.json

後から計算結果が疑わしくなったとき、加工前データがなければ原因を追えません。

最低限、次の情報を一緒に保存します。

取得元
取得日時
実行ID
取得件数
ファイル名
ファイルのハッシュ値
取得処理の成否

ハッシュ値とは、ファイルの内容から作る識別値です。同じ名前のファイルでも内容が変わっていないかを確認できます。

個人情報や認証情報を含む場合は、保存範囲、暗号化、アクセス権限、削除期限も決めてください。APIキーやログイン情報をCSVへ書き込んではいけません。

5. 表記を正規化する

自動処理では、次の変換がよく使われます。

• 「5,480万円」→ 54800000
• 「徒歩10分」→ 10
• 「昭和63年」→ 1988
• 全角数字→半角数字
• 都道府県や市区町村の表記揺れを統一
• 空欄、「未定」、「応相談」を欠損値として区別

変換できなかった値をゼロにすると、価格ゼロや経費ゼロとして計算される危険があります。変換失敗はnullとして保存し、needs_review=trueを付けるほうが安全です。

正規化前の値も削除せず、次のように残します。

price_raw：5,480万円
price_yen：54800000
price_parse_status：success

これにより、変換結果が疑わしい場合でも元の表記まで戻れます。

6. 計算列と検算列を作る

計算処理には、最終結果だけでなく途中値も残します。

effective_income ＝ annual_rent × (1 − vacancy_rate)
noi ＝ effective_income − operating_cost
gross_yield ＝ annual_rent ÷ price
noi_yield ＝ noi ÷ price

検算列には、次のような条件を設定できます。

• 価格がゼロ以下ならエラー
• 空室率が0未満または100%超ならエラー
• 年間運営費が負の値ならエラー
• NOIが満室想定年収を上回ったらエラー
• URLが同じ物件を重複候補にする
• 前回価格との差が一定以上なら確認対象にする
• 必須項目が欠損していればランキング対象外にする

Googleスプレッドシートで、D列を価格、E列を満室想定年収、F列を空室率、G列を年間運営費とした場合、次の式で試作できます。

H2（表面利回り）
=IF(OR(D2="",D2<=0,E2=""),"",E2/D2)

I2（NOI）
=IF(OR(E2="",F2="",G2=""),"",E2*(1-F2)-G2)

J2（NOI利回り）
=IF(OR(D2="",D2<=0,I2=""),"",I2/D2)

K2（確認状態）
=IF(D2<=0,"価格エラー",IF(OR(F2<0,F2>1),"空室率エラー",IF(COUNTBLANK(D2:G2)>0,"必須項目不足","計算可能")))

H列とJ列の表示形式はパーセントにします。計算不能な行をゼロとして順位付けしないよう、K列が「計算可能」の行だけをランキング対象にしてください。

7. スコアと除外理由を分ける

点数だけを表示すると、なぜ上位なのか説明できません。スコアと同時に、加点理由、リスク、除外理由を保存します。

score：72
positive_reasons：NOI利回り、駅距離
risk_flags：築年数、修繕履歴未確認
excluded_reason：なし

たとえば、試作用の配点を次のように設定できます。

この配点は、投資成果を予測するものではありません。候補を確認する順番を決めるフィルターとして使います。

購入判断には、現地確認、修繕履歴、契約書類、法令上の制限、賃貸需要、融資条件などの精査を加えてください。

8. 比較表を自動出力する

出力先は、共有しやすさならGoogleスプレッドシート、ローカル分析ならExcelやCSV、履歴検索ならデータベースが候補です。

シートは次の3つに分けると管理しやすくなります。

• 最新候補：条件を満たし、現在確認すべき物件
• 全件履歴：取得したデータ、価格変更、掲載終了の履歴
• 要確認：欠損、異常値、重複、計算失敗がある物件

セルの色分けだけに頼らず、statusやerror_reasonを文字列で残します。色は人間には分かりやすい一方、APIや別プログラムからは判定しにくいためです。

比較表の各行には、最低限、次の追跡情報を残します。

run_id
property_id
source_url
fetched_at
calculation_version
source_file
status
error_reason

calculation_versionを残しておけば、計算式を変更した後も、どのルールで算出した結果かを区別できます。

9. 定時実行・通知・停止条件を設定する

Windowsならタスクスケジューラ、クラウドならスケジュール実行機能を利用できます。

処理結果として、最低限、次の値をログへ残します。

run_id
開始時刻
終了時刻
取得元
取得件数
新規件数
更新件数
除外件数
エラー件数
出力先
最終成功時刻
処理結果

成功通知を増やすよりも、失敗通知と安全停止の設計が重要です。

次のような場合は、古い比較表を正常な最新結果として配信せず、処理を停止させます。

• 取得件数が直近平均より極端に少ない
• 必須列が取得元から消えた
• 全物件の価格がゼロまたは欠損になった
• 同じエラーが連続した
• 最終成功時刻から一定時間を超えた
• 出力件数がゼロなのに処理が成功扱いになっている

通知本文には「失敗しました」だけでなく、次の情報を含めます。

実行ID
失敗した工程
エラー内容
影響を受けた取得元
前回成功時刻
再試行回数
ログの保存先

auto-ai-blogの実行ログから分かった無人運用の落とし穴

本稿の確認時に、auto-ai-blogのgenerator/logs/generate.logを調査しました。

同一トピック「収益物件の比較表を自動作成するワークフロー」について、2026年7月18日12時27分38秒に下書き生成が開始され、12時32分03秒に240秒のタイムアウトが記録されています。その直後、記事生成はスキップされました。

確認できたログの要点は次のとおりです。

これは物件取得処理のログではありませんが、無人ワークフローにも共通する一次情報です。外部処理へ同じ入力を渡しても、必ず同じ時間で正常終了するとは限りません。

収益物件の比較表では、次の制御を組み込みます。

• 再試行回数に上限を設ける
• 失敗理由と最終成功時刻を保存する
• 連続失敗時は取得元単位で停止する
• 前回の正常な比較表を「最新取得」と偽って上書きしない
• 処理停止を管理者へ通知する
• 再試行時も同じ物件を重複登録しない

自動化資産の価値は、単に動き続けることではありません。壊れたときに誤った数字を配らず、どこで止まったのかを追跡できることによって保たれます。

なお、記事内の2枚の画像はワークフローを説明する概念図です。実運用の証拠として公開する場合は、認証情報や個人情報を伏せたうえで、元データ、比較表、実行ログのスクリーンショットを別途掲載してください。

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

表面利回りを最終順位に使っていないか

表面利回りは入口の比較には使えますが、空室や運営費を反映しません。NOI利回り、修繕履歴、賃貸需要などを併記します。

異なる前提を同じ列で比較していないか

満室想定年収と現況年収が混在すると、利回りの意味が変わります。rent_type列を作り、「満室想定」「現況」「査定」の区別を保存します。

諸費用を無視していないか

物件価格だけで利回りを計算すると、取得時の仲介手数料、登記費用、不動産取得税などが反映されません。

物件同士の比較では物件価格ベースのNOI利回りを使い、自己資金計画では総事業費ベースの指標を別に持つと、目的を混同しにくくなります。

総事業費ベースNOI利回り
＝ NOI ÷（物件価格 ＋ 取得諸費用）× 100

データの鮮度を確認できるか

掲載日時だけでなく、実際の取得日時を残します。更新されていない候補を上位表示し続けないよう、経過時間も計算します。

data_age_hours ＝ 現在時刻 − fetched_at

元データまで戻れるか

比較表の各行から、掲載元URL、取得日時、元ファイルへたどれる状態にします。数字だけを転載した表では、条件変更や誤記を検証できません。

収益と作業削減を混同していないか

自動化で直接改善しやすいのは、巡回時間、転記時間、見落とし、比較基準の一貫性です。物件価格、融資条件、入居率、市況を制御できるわけではありません。

一方、定期的に候補を収集できる仕組みは、物件探索、顧客向けレポート、地域相場コンテンツなどへ再利用できます。許諾や法令を守ったうえで、継続的な収益導線を支えるデータ資産へ発展させる余地があります。

画像で説明すべき箇所

記事や社内マニュアルへ画像を追加するなら、次の図が有効です。

• 全体フロー図：取得元から比較表、通知までを矢印で示す
• 変換前後のスクリーンショット：「5,480万円」が整数へ変わる様子
• 比較表の画面：NOI利回り、欠損、リスクフラグを表示する
• 実行ログの画像：取得件数、エラー件数、最終成功時刻を示す
• 表面利回りとNOI利回りの棒グラフ：評価差が生まれる例を示す

視覚的証拠として最も価値が高いのは、完成した表の装飾画像よりも、元データ、変換結果、計算結果、実行ログを追跡できるスクリーンショットです。

ただし、画面を公開するときは、APIキー、メールアドレス、ログイン情報、個人名、非公開URLなどを必ず伏せてください。

よくある失敗と対策

失敗1：最初から全項目を取得しようとする

原因：理想の比較表を先に作り、取得できない列が増える。

対策：価格、年収、所在地、築年、URL、取得日時から始め、実際の判断に使った列だけ追加する。

失敗2：欠損値をゼロとして計算する

原因：空欄と実際のゼロを区別していない。

対策：欠損はnullにし、計算対象外または要確認へ送る。

失敗3：掲載番号だけで重複判定する

原因：掲載元が変わると別物件として登録される。

対策：住所、価格、面積、建築年などを組み合わせた重複候補判定を使う。自動で同一物件と断定せず、確信度が低い場合は人間の確認対象にする。

失敗4：正常終了しか通知しない

原因：停止しても誰も気づかず、古い比較表を使い続ける。

対策：最終成功時刻、連続失敗回数、取得件数の急減を監視する。

失敗5：自動スコアを投資判断として扱う

原因：未取得の修繕履歴、法的制限、賃貸需要まで点数化できたと誤認する。

対策：スコアは確認順の整理に限定し、除外理由と未確認項目を併記する。

失敗6：計算式を変更しても過去データを区別しない

原因：空室率や経費の定義を変更した後も、旧計算結果と新計算結果が同じ列に混在する。

対策：calculation_versionと計算日時を保存し、必要に応じて過去データを再計算する。

成果を測るKPI

最初の4週間は、次の基準値を記録してください。

1週間当たりの取得件数
必須項目充足率
手動で修正した件数
比較表の確認にかかった時間
詳細調査へ進めた件数
処理失敗から復旧までの時間

改善前の数値がなければ、自動化によって何が変わったのか判断できません。

金額KPIを使う場合は、売上、経費、計測期間、帰属条件をそろえます。「比較表を見た後に発生した売上」と「比較表が生んだ売上」は同じではありません。

使えないケースと限界

次の状況では、完全自動化に固執しないほうが安全です。

• 取得元の規約が自動アクセスを認めていない
• 修繕履歴や契約条件が紙資料にしかない
• 住所や物件名だけでは同一性を判定できない
• 地域特有の法規制や再建築条件を機械判定できない
• データ件数が少なく、自動化の維持費が手作業を上回る
• 取得元の画面やデータ形式が頻繁に変わる
• 入力データの正確性を第三者が保証していない

比較表の生成工程は無人化できても、現地調査、契約、融資、法務・税務確認まで無人化するのは現実的ではありません。

また、NOIは採用した空室率と運営費の前提に左右されます。過去実績がない段階では、楽観・標準・悲観の3シナリオを作ると、単一の推計値を過信しにくくなります。

これらの数値は例であり、地域、物件種別、築年数、入居実績に応じて調整が必要です。

本稿は一般的な情報整理を目的としています。個別案件では、宅地建物取引士、税理士、金融機関、建築士などの専門家へ確認してください。

今日から始める具体的アクション

手元にある3物件を選び、次の10列をスプレッドシートへ作ってください。

1. 物件ID
2. URL
3. 取得日
4. 価格
5. 満室想定年収
6. 空室率
7. 年間運営費
8. 表面利回り
9. NOI
10. NOI利回り

可能であれば、11列目に「確認状態」を追加します。

最初の作業は、次の順番で進めます。

1. 3物件の数値を手入力する
2. 表面利回り、NOI、NOI利回りの式を設定する
3. 電卓で1件だけ手計算し、シートの結果と一致するか確認する
4. 必須項目を1つ空欄にし、誤ってゼロ計算されないか確認する
5. 価格をゼロにし、エラーとして除外されるか確認する
6. 元の値へ戻し、3物件をNOI利回り順に並べる
7. 翌日に同じ入力で再計算し、同じ結果になるか確認する

この小さな比較表が、データ取得、履歴保存、定時実行、通知を追加する際の土台になります。

最初から複数サイトの巡回を自動化する必要はありません。まずは「同じ入力なら、誰が実行しても同じ結果になる比較表」を完成させることが第一歩です。

まとめ｜比較作業を「毎回の労働」から「更新される資産」へ変える

収益物件の比較表を自動作成する流れは、取得、保存、正規化、計算、検査、出力、通知の順で組み立てます。

重要なのは、表を自動生成することだけではありません。

• 元データまで戻れる
• 計算式の前提を説明できる
• 欠損値をゼロとして扱わない
• 異常時には安全に停止する
• 最終成功時刻を確認できる
• スコアと除外理由を説明できる
• 自動化前後の成果をKPIで比較できる

ここまで設計して初めて、比較表を実務で継続利用できます。

類似記事との違いは、表の関数や見栄えだけでなく、失敗ログ、再試行上限、欠損管理、計算バージョン、データ履歴、収益導線まで設計対象にしている点です。

人間が毎朝検索して転記する仕組みは、作業を止めれば更新も止まります。定時収集される比較表なら、自分が操作していない時間にも候補データを蓄積できます。そのデータは物件探索の補助に加え、顧客向けレポートや情報コンテンツの基盤にもなります。

収益は保証されません。それでも、労働時間と処理量を切り離し、再利用できるデータとプログラムを残すことは、継続的に働く自動化資産を構築する現実的な一歩です。

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

「比較表は作れた。しかし、定時実行、エラー復旧、通知、収益導線まで自力でつなぐのは難しい」

そこで止まると、せっかくの仕組みが再び手作業へ戻ってしまいます。

寝ている間にもデータが集まり、条件判定が走り、次の行動につながる。 そのような無人運用を形にしたい方へ、実装手順をまとめた実践マニュアルを用意しています。

ツールを眺めて終わるのではなく、今日から動かせる自動化資産を一つずつ構築したい方は、以下の商品一覧をご覧ください。

本気で自動化・不労所得を構築するための実践マニュアルを見る