比較表

「表面利回りは高いのに、現況家賃が分からない」「同じ物件を別サイトで何度も確認している」「価格変更に気づいたときには掲載が終了していた」。 収益物件を探していると、判断そのものより、検索・転記・再計算・更新確認に時間を取られます。物件数が増えるほど比較表は古くなり、見送り理由や計算条件も分からなくなりがちです。 そこで本記事では、収益物件の比較表を自動作成し、数字を検算したうえで、確認すべき候補だけを通知するワークフローを解説します。 完成後に目指すのは、次の状態です。 許可された情報源から物件データを定期取得する 円・万円、徒歩分数、築年月などの表記を統一する 掲載利回りとは別に、同じ式で利回りを再計算する 欠損、重複、異常値、更新差分を検出する 資料請求や現地確認が必要な物件だけを通知する 元データ、検算結果、見送り理由を履歴として残す ただし、自動化するのは購入判断ではなく、一次選別と確認作業の整理です。現地調査、契約・権利関係、建物状態、融資、税務などは、資料の原本と専門家の確認が必要です。 本記事は一般的な情報提供であり、特定物件の購入を推奨する投資助言ではありません。 収益物件の比較表を自動作成する全体像 ワークフローは、次の9工程に分けます。 1. 情報を取得する ↓ 2. 原文・取得日時・情報源を保存する ↓ 3. 必要項目を抽出する ↓ 4. 単位と表記を正規化する ↓ 5. 利回り・NOI・返済後CFを再計算する ↓ 6. 欠損・重複・異常値を検査する ↓ 7. 比較表と変更履歴へ登録する ↓ 8. 条件に合う候補だけを通知する ↓ 9. 人間が資料・融資・現地・法務を確認する 重要なのは、取得、抽出、計算、検証、保存を一つの処理に詰め込まないことです。 工程を分けておけば、価格が空欄になったときに「ページを取得できなかったのか」「金額抽出に失敗したのか」「単位変換で止まったのか」を切り分けられます。 最初に決めるべき「自動化する範囲」 初心者が最初から「良い物件をAIに選ばせる」と、判断根拠が不透明になります。 まずは目的を、次の一文に限定してください。 新着物件の中から、追加資料を確認する候補を絞り込む。 システムに任せる作業と、人間が担当する作業も分けます。 システムに任せる 人間が確認する データ取得、転記、単位変換 現地の騒音、周辺環境、建物状態 利回りの再計算 家賃設定の妥当性 欠損、重複、異常値の検出 接道、境界、再建築、権利関係 掲載内容の変更検知 修繕履歴と将来の工事 候補の通知 融資条件と購入判断 この線引きを崩さないことが、比較表を過信しないための第一歩です。 比較表に必要な列 初心者はGoogleスプレッドシートやExcelから始めると、抽出結果や計算式を目視できます。データ量や更新回数が増えたら、データベースへ移行します。 ...

「気になる収益物件は増えたのに、比較する前の転記作業で疲れてしまう」 収益物件を探していると、販売図面はPDF、仲介会社からの提案はメール、家賃相場は不動産ポータル、融資条件は別のメモに分散します。 そのたびにExcelへ価格や賃料を転記し、単位をそろえ、利回りを計算していると、肝心の物件調査に使う時間が残りません。 そこでこの記事では、収益物件の比較表を自動作成する仕組みを、初心者でも試せる7ステップに分けて解説します。 完成後に目指す状態は次のとおりです。 メールやCSVから物件情報を取り込む 価格・賃料・築年などの表記を統一する 表面利回りや戸数ベースの空室割合を計算する 不明項目と危険信号を表示する 条件に合った物件だけ通知する 人間が修正した内容を次回の抽出ルールへ反映する 成功件数だけでなく、失敗理由も記録する 目的は、AIに物件購入を決めさせることではありません。 転記、整形、計算、一次選別を自動化し、人間の時間を原本確認、現地調査、融資相談へ振り向けることです。比較表を一度きりの資料ではなく、判断履歴を再利用できる運用資産へ育てます。 本記事は一般的な情報提供を目的としており、特定の物件、融資、購入または売却を推奨するものではありません。実際の投資判断は、原本や現地を確認したうえで、宅地建物取引士、金融機関、税理士、建築士、弁護士などへ相談してください。 Hiroの実行ログで確認した「止まる前提」の自動化 私は auto-ai-blog という自動生成環境を運用しています。 2026年7月22日22時16分時点のローカルログを集計したところ、同日の Saved to Notion successfully. は55回記録されていました。 ただし、同じ日には次のエラーも発生しています。 AIの下書き処理が240秒でタイムアウト Gemini CLIでコマンド長エラー Gemini CLIで認証エラー 品質検査が最低合格スコアに届かず停止 レビュー処理に失敗し、下書きをそのまま採用 実際のログには、次のような記録が残っています。 2026-07-22 19:49:05 [INFO] Saved to Notion successfully. 2026-07-22 19:51:41 [ERROR] AI slop validation failed: score=7/8; failed=他者が書けない独自情報, 反論・限界・注意点, 差別化 品質設定ファイルは2026年6月26日に取得されており、チェック項目は10個、最低合格スコアは8点です。 ここで注意したいのは、10項目中7項目を満たしていても、合格基準8点には届かないことです。また、上記の7点時に不足していた項目は「独自情報」「反論・限界・注意点」「差別化」の3つでした。 この実行ログから分かったのは、自動化では「一度も止まらないこと」より、次の情報を残す方が重要だということです。 いつ実行したか 何件入力したか 何件成功したか どの工程で失敗したか 何を直せば再実行できるか 再実行によって重複登録されないか 収益物件の比較表も同じです。読み取りに失敗した物件を黙って除外せず、「どの資料の、どの項目を、なぜ取得できなかったか」を記録します。 収益物件の比較表を自動作成する全体像 自動化する処理は、次の8段階です。 物件メール・PDF・CSV ↓ 必要項目の抽出 ↓ 単位と表記の正規化 ↓ 入力値の検証 ↓ 利回り・空室割合の計算 ↓ 比較表へ保存 ↓ 条件一致時だけ通知 ↓ 人間の修正を抽出ルールへ反映 ここでいう正規化とは、同じ意味のデータを同じ形式へ変換する処理です。 ...

「物件情報を表へ転記している間に、新着物件が増えてしまう」「表面利回りでは魅力的でも、空室や経費を反映すると順位が変わる」「毎朝ポータルサイトを巡回する作業に時間を取られる」。 収益物件を継続的に探している人ほど、こうした問題に直面します。手作業で作った比較表は、その時点では役立っても、価格変更や掲載終了が発生すれば、すぐに古い資料になります。 そこで構築したいのが、物件情報の取得、項目の統一、収支計算、ランキング、保存、通知までを連続処理する収益物件比較表の自動作成ワークフローです。 この記事では、初心者でも実装順序を判断できるように、必要な項目、計算式、異常検知、KPI、停止条件を具体化します。読了後には、手元にある3物件を使って、比較表の試作を始められる状態を目指します。 狙うのは単なる時短ではありません。一度作った処理を定時実行し、自分がパソコンを操作していない時間にも候補物件が整理される再利用可能な自動化資産へ育てることです。 ただし、自動作成された比較表は投資判断を補助する資料です。利益や購入成果を保証するものではなく、元データが誤っていれば計算結果も誤ります。最終判断では、現地調査、契約書類、法令、融資条件などの確認が必要です。 収益物件の比較表を自動作成する全体像 ワークフローは、次の7層に分けると理解しやすくなります。 取得：CSV、メール、API、許可されたWebページなどから物件情報を集める 保存：加工前のデータを日時付きで残す 正規化：価格、面積、住所、築年数などの表記を統一する 計算：表面利回り、NOI、NOI利回りなどを同じ式で算出する 検査：欠損、重複、異常値、更新停止を検知する 出力：GoogleスプレッドシートやExcelへ比較表を作る 通知：条件に合う新着物件や処理失敗をメールなどで知らせる ここでいう正規化とは、異なる書き方を同じ形式へ変換する処理です。たとえば「5,480万円」「54800000円」「54.8百万円」を、すべて整数の54800000へ統一します。 この構造なら、情報源が増えても計算部分を使い回せます。比較表を毎回作り直すのではなく、データが入れば同じ基準で更新される仕組みに変えられます。 比較表に入れる項目 最初から大量の列を作ると、欠損だらけの表になりがちです。まずは比較と検算に使う列へ絞ります。 分類 推奨項目 用途 識別 物件ID、掲載元、URL、取得日時 重複判定と追跡 価格 物件価格、諸費用、総事業費 投資額の比較 建物 所在地、構造、築年、戸数、延床面積 リスク分類 収入 満室想定年収、現況年収、空室率 売上の検算 支出 管理費、修繕費、税金、保険、その他経費 NOI計算 指標 表面利回り、NOI利回り、1戸当たり価格 横比較 品質 欠損数、異常値フラグ、最終確認日 データの信頼度確認 判断 スコア、除外理由、要確認事項 優先順位付け NOIは、物件運営によって得られる純収益を示す指標です。本稿では、説明のために次のように単純化します。 実効年間収入 ＝ 満室想定年収 ×（1 − 想定空室率） NOI ＝ 実効年間収入 − 年間運営費 NOI利回り ＝ NOI ÷ 物件価格 × 100 年間運営費には、管理費、固定資産税、保険料、定常的な修繕費などを含めます。一方、本稿のモデルでは、借入返済、所得税、減価償却、大規模修繕などの資本的支出は含めません。 何を含めるかによってNOIの意味は変わります。列名と計算定義を別シートに残し、担当者や計算時期によって式の意味が変わらないようにしてください。 架空の3物件で計算結果を検証 以下は、式の動作を確かめるために作成したモデルデータです。実在物件の運用実績ではありません。 ...

収益物件を探すたびに、物件サイトを開き、価格や利回りをExcelへ転記し、仲介会社から届いたPDFと照合する。数日後には「この物件を保留にした理由」が分からなくなり、同じページをもう一度調べる――。 この繰り返しに時間を使っていると、候補が増えるほど判断が遅くなります。そこで役立つのが、収益物件の比較表を自動作成するワークフローです。 この記事では、物件情報の取得、必要項目の抽出、表記の統一、比較表への登録、優先順位付け、通知までをつなぐ方法を解説します。完成後に目指す状態は、パソコンの前にいない時間もシステムが候補を整理し、人間には「追加確認が必要な物件」だけが届く運用です。 ただし、比較表の自動作成は購入判断の自動化ではありません。買付、融資、契約、修繕、税務、法務に関する判断は、資料の原本と専門家の確認が必要です。本記事は一般的な情報提供を目的としており、特定の物件の取得を勧めるものではありません。 Hiroサイトの実行ログで分かったこと この記事は架空の成功談ではなく、Hiroが運用する auto-ai-blog のローカルデータと実行ログを基にしています。 2026年7月18日にリポジトリ内を再集計した結果は次の通りでした。 確認項目 検証結果 前提・確認方法 AI・技術サイトの記事 304本 sites/ai-tech/content/posts のMarkdownを集計 ビジネスサイトの記事 366本 sites/business/content/posts のMarkdownを集計 不動産サイトの記事 115本 sites/real-estate/content/posts のMarkdownを集計 合計 785本 上記3ディレクトリのローカル実測値 品質検証 終了コード0 AIスロップ防止関連のテスト3件を実行 比較用の物件レコード 7件 notion_search.json 内の価格・利回り付きデータ 同じ「収益物件の比較表」テーマについて、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つの部品に分けると理解しやすくなります。 部品 役割 具体例 入力 物件情報を集める URL、メール、PDF、CSV、Notion 抽出 必要な項目を取り出す 価格、利回り、構造、築年数、戸数 正規化 表記と単位を統一する 円を万円、年月日を同一形式へ変換 判定 確認する順番を分類する 資料確認、融資確認、現地確認、保留 出力 比較表と通知へ送る Google Sheets、Notion、メール たとえば、物件価格が比較表へ入らなかった場合、入力データが取得できなかったのか、AIが金額を抽出できなかったのか、単位変換に失敗したのかを切り分けられます。 比較表の自動作成によって蓄積されるのは、物件一覧だけではありません。取得元、調査日、抽出結果、修正履歴、見送り理由が残ります。これらは、次回以降の調査時間を減らす自動化資産になります。 収益につながる可能性があるのは、比較表そのものではなく、候補の見落としを減らし、転記に使っていた時間を資料精査や別の収益活動へ振り向けられる点です。利益や成約は保証されません。 ステップ・バイ・ステップで作る自動化ワークフロー 1. 比較表の目的を一文で決める 最初に「何を決める表なのか」を定義します。 ...

収益物件を探していると、物件ページ、仲介メール、PDF、Notionメモ、融資条件、周辺相場を何度も見比べることになります。 最初の数件なら手作業でも回ります。しかし10件、30件、100件と候補が増えると、問題は「良い物件がない」ではなく、どれを先に確認すべきか判断できないことになります。 この記事では、収益物件の比較表を自動作成するワークフローを、初心者でも作れる順番で解説します。 ここで作る比較表は、単なる物件一覧ではありません。価格、表面利回り、築年数、融資上の残存年数、戸数、エリア、情報源、取得日、ステータス、要確認理由を横並びにし、次に見るべき物件を絞るための判断画面です。 先に結論を書くと、自動化するべきなのは「購入判断」ではありません。自動化するのは、次の4つです。 物件情報を集める 比較表に必要な項目を抽出する 単位と表記をそろえる 人間が確認すべき候補だけを通知する 買付、融資、契約、税務、法務、修繕判断は、人間と専門家が確認する領域です。AIに任せる範囲を間違えると、時短ではなく事故の入口になります。 この記事で扱う一次情報と限界 一般論だけで終わらせないため、この記事ではHiro側の auto-ai-blog リポジトリで確認したローカルデータを前提にしています。 2026年7月12日に再確認した実測値は次の通りです。 確認項目 実測・ログ 確認方法 ai-tech 投稿Markdown数 269本 sites/ai-tech/content/posts/*.md をローカル集計 business 投稿Markdown数 317本 sites/business/content/posts/*.md をローカル集計 real-estate 投稿Markdown数 103本 sites/real-estate/content/posts/*.md をローカル集計 AIスロップ防止テスト 3 passed in 0.40s python -m pytest tests/test_slop_guard.py tests/test_validate_ai_slop.py Notion由来の物件データ 7件 notion_search.json から価格・表面利回り項目を持つページを抽出 品質基準 最低スコア8 generator/ai_slop_guidelines.json、取得日時 2026-06-26T00:00:00+09:00 この記事内の画像は、ワークフローを理解しやすくするための概念図です。投資判断の根拠そのものではありません。根拠として扱うべきなのは、物件URL、取得日、販売図面、レントロール、メール、PDF、修正履歴、そして人間による確認ログです。 Notion由来の7件には、次のような物件レコードが含まれていました。 物件名 価格 表面利回り 築年数 融資上の残存年数メモ 戸数 情報源 調査日 横浜市港北区 菊名駅7分 一棟アパート 3,360万円 12.21% 42年 5年 8戸 健美家 2026-06-29 千葉市緑区 戸建賃貸 480万円 17.5% 45年 2年 1戸 健美家 2026-06-29 相模原市緑区 一棟アパートS造 2,000万円 12.72% 41年 0年 10戸 健美家 2026-06-29 横浜市保土ケ谷区 戸建 390万円 24.61% 61年 0年 1戸 健美家 2026-06-29 東久留米市小山5丁目 1K×12戸 5,580万円 9.33% 36年 11年 12戸 業者直接 2026-06-29 この表は投資推奨ではありません。目的は、収益物件の比較表にどの項目が必要かを示すことです。 ...

収益物件を探すとき、最初に時間を奪われるのは「買うべきかどうか」の判断ではありません。 その前段階にある、物件情報を比較できる形にそろえる作業です。 物件概要書、販売図面、レントロール、ポータルサイト、家賃相場、修繕履歴、融資条件。これらを毎回Excelやスプレッドシートに手入力していると、検討数が増えるほど、判断前の作業だけで疲弊します。 この記事では、収益物件の比較表を自動作成するワークフローを、初心者でも再現できる順番で解説します。 ここでいう比較表とは、物件価格、満室想定年収、表面利回り、運営費、空室率、修繕リスク、エリアメモ、次アクションを横並びにした検討用の一覧表です。 目的は、AIに購入判断を任せることではありません。 人が判断する前の情報整理を自動化し、検討履歴が残る仕組みに変えることです。 なお、本記事は一般的な情報提供であり、特定物件の購入・売却・融資判断を勧めるものではありません。最終判断は、宅建業者、税理士、金融機関、建築士、弁護士などの専門家に確認してください。 このサイトの実行ログから見えた自動化の前提 Hiroのこのサイトでは、記事生成から保存までを自動化する仕組みを実運用しています。リポジトリ内の generator/ai_slop_guidelines.json には、Notion由来のAIスロップ防止基準として、次の条件が残っています。 項目 実行ログ・設定の内容 取得日時 2026-06-26T00:00:00+09:00 最低スコア 8 チェック項目 10個 必須レビュー役割 編集長、専門家、SEO、画像品質、法務・リスク また、generator/logs/generate.log には、2026-07-11に複数回の Saved to Notion successfully. が記録されています。たとえば、14:22:01、14:38:57、14:51:29、15:06:19、15:21:45、15:37:55、15:52:01にNotion保存成功ログが残っています。 一方で、同じログには失敗も残っています。 Gemini CLI failed: The command line is too long. Gemini CLI failed: Error authenticating: IneligibleTierError git commit failed: fatal: cannot lock ref 'HEAD' .git/HEAD.lock が存在してコミットできないエラー ここが重要です。実運用の自動化は、「毎回きれいに成功する魔法」ではありません。 成功ログ、失敗ログ、再実行条件、手動確認ポイントを含めて設計しておかないと、動いているのか止まっているのか判断できません。 収益物件の比較表自動作成も同じです。必要なのは、AIに丸投げすることではなく、入力、抽出、正規化、計算、検証、保存、通知、ログ確認までの流れを作ることです。 比較表自動作成ワークフローの全体像 収益物件の比較表は、次の7段階で作ると設計しやすくなります。 入力元を決める CSV、物件概要書PDF、メール本文、ポータルサイトの保存データなど。 必要項目を抽出する 価格、所在地、築年数、構造、戸数、満室想定年収、現況賃料、管理費など。 ...