この実験について
実験ID：EXP-006
状態：実験中
テーマ：物件記事運用、記事管理、価格追跡、WordPress、Codex
今回の実験は、伊豆の安い家研究所で行った作業をもとにしている。
やったことは単純だ。伊東、熱海、下田の安い物件を探し、3本の記事として公開した。
ただし目的は、物件記事を増やすことではない。
本当に試したかったのは、物件を見つけて、記事にして、公開して、その後も価格変更や掲載終了を追跡できるかどうかだった。
物件記事は、書くだけならそこまで難しくない。問題はその後だ。
掲載が終わったのか。価格が変わったのか。売れたのか。まだ残っているのか。そこを追いかけられないと、記事はすぐ古くなる。
だから今回は、記事作成ではなく「物件記事を継続運用できる仕組み」を実験対象にした。
困っていたこと
伊豆の安い家研究所では、安い物件を紹介したい。
でも物件情報は変化が早い。
昨日あった物件が今日なくなることもあるし、価格が下がることもある。掲載元が消えることもある。
物件数が3件なら手で見ればいい。
しかし10件、30件、100件になったら、たぶん管理できなくなる。
ここで最初に考えたのは、いきなりデータベースを作ることだった。
でも、それは少し早いと思った。
今必要なのは立派な管理表ではなく、まず3件をちゃんと追えるかどうかの確認だった。
試したこと
今回は、伊東、熱海、下田からそれぞれ1件ずつ、安い物件を選んだ。
- 伊東市川奈 250万円
- 熱海市伊豆山 250万円
- 下田市旧岡方村 90万円
この3件を、伊豆の安い家研究所の記事として公開した。
記事には、ただ感想を書くのではなく、あとから追跡できるように共通項目を入れた。
- 物件ID
- 初回確認日
- 最終確認日
- 状態
- 価格
- エリア
- 現地確認
- 掲載元
- 追跡すること
- 更新履歴
物件IDは、`IZU-PROP-001` のように付けた。
これがあると、あとでCodexや人間が見返した時に「どの物件の話か」が分かりやすい。
また、すべての記事に「現地未調査」と明記した。
掲載元の写真は使わず、リンクと研究所コメントだけで構成した。
これは、物件紹介ではなく研究ログとして扱うためだ。
作った仕組み
今回作った仕組みは、かなり小さい。
流れはこうだ。
- 物件を見つける
- 掲載元リンクを保存する
- 研究所視点で記事化する
- 物件IDを付ける
- 記事内に確認日と状態を書く
- 週1回、掲載元を確認する
- 価格変更や掲載終了があれば更新履歴に追記する
ポイントは、新しい管理表を増やさなかったこと。
最初からスプレッドシートやデータベースを作ると、管理するものが増える。
だから最初は記事本文の中に、追跡に必要な情報を入れることにした。
3件から10件くらいまでは、このやり方で試す。
30件を超えてから、CSVやスプレッドシート化を考える。
今日の結果
今日できたことは、以下の通り。
- EXP-006を実験台帳へ登録
- 物件記事運用フロー仕様書を作成
- 物件記事3本を作成
- 伊豆の安い家研究所へ3本公開
- 投稿IDを記録
- 物件紹介カテゴリへ追加
- 次回確認日を2026年6月22日に設定
公開した3本は、まだ完成形ではない。
カテゴリに `Uncategorized` が残っていたり、見た目の調整も必要だ。
でも、実験としては大きな一歩だった。
「物件を探す」だけではなく、「追跡する前提で記事にする」という型ができたからだ。
分かったこと
今回分かったのは、物件記事は自動化できそうで、完全自動化は危ないということ。
物件の価格や掲載状況は変わる。
掲載元によってページの作りも違う。
同じ物件が複数サイトに出ることもある。
さらに、掲載元の写真を勝手に使うわけにもいかない。
だから、最初から全部を自動化しようとすると崩れやすい。
現実的には、半自動がよさそうだ。
物件探し、記事下書き、更新候補の洗い出しはCodexに任せる。
公開判断、現地感覚、表現の調整は人間が見る。
この分担なら続けられる可能性がある。
失敗しそうな点
この実験で詰まりそうな場所も見えてきた。
- 物件数が増えると確認日を忘れる
- 掲載終了の判定が面倒
- 価格変更を見落とす
- 同じ物件を重複して拾う
- 記事が古いまま残る
- 管理表を増やしすぎる
特に危ないのは、管理表を増やしすぎることだと思う。
管理するための仕組みを作ったのに、その仕組みの管理で疲れたら意味がない。
今回の実験では、できるだけ記事本文の中で管理する。
次にやること
初回確認日は2026年6月22日に設定していた。
その日に確認することは3つだけ。
- 掲載元リンクが生きているか
- 価格が変わっていないか
- 更新履歴へ追記するのに何分かかるか
この確認が1件5分以内で終われば、少し増やせる。
逆に、3件でも面倒なら、この運用は重すぎる。
その場合は、記事数を増やす前に仕組みを直す。
2026年6月23日：初回追跡確認
本来の確認日は2026年6月22日だったが、1日遅れて2026年6月23日に3件を確認した。
| 物件ID | エリア | 初回価格 | 確認結果 |
|---|---|---|---|
| IZU-PROP-001 | 伊東市川奈 | 250万円 | 掲載元リンク生存。価格変更なし。 |
| IZU-PROP-002 | 熱海市伊豆山 | 250万円 | 掲載元リンク生存。価格変更なし。 |
| IZU-PROP-003 | 下田市旧岡方村 | 90万円 | 掲載元リンク生存。価格変更なし。 |
3件とも掲載終了は確認されず、価格も初回確認時から変わっていなかった。
確認作業自体は機械的に約1分で終わった。3件程度なら、週1回の追跡はかなり軽い。
今回分かったのは、物件追跡そのものよりも、確認日を忘れない仕組みの方が重要かもしれない、ということだった。
次回確認日は2026年6月30日にする。
まとめ
物件記事は、書いて終わりではない。
むしろ公開した後に、ちゃんと追えるかどうかが大事になる。
今回は、伊豆の安い家研究所で3本の物件記事を公開しながら、物件記事運用の小さな仕組みを作った。
まだ実験中だ。
2026年6月23日の初回追跡では、3件すべて掲載継続・価格変更なしだった。
今回の研究結果はこれだ。
物件記事の自動化は、最初から完全自動を目指さない方がいい。
まずは3件を、物件ID、確認日、状態、更新履歴つきで追跡する。
それが回ってから、10件、30件へ広げる。
記事を増やす前に、追跡できる仕組みを作る。
これが、今日の実験結果だった。
2026年6月17日：パーソナルOSの4本柱に入れた理由
この物件記事追跡実験は、パーソナルOS実験室の4本柱のひとつに入れた。
理由は、単なる物件記事ではなく、「情報を増やす前に、追跡できる形にする」という研究所OSの考え方がよく出ているからだ。
伊豆の安い家研究所では、安い物件を見つけること自体はできる。問題は、その後だった。
価格が変わったのか。掲載が終わったのか。まだ売れ残っているのか。記事を書いた時点の情報が、いつまで有効なのか。
ここを追えないと、物件記事はすぐ古くなる。
だからこの実験では、記事数を増やす前に、確認日、状態、更新履歴を持たせることを優先した。
これは今後、物件100件、200件を追跡する時の最小モデルになる可能性がある。
現時点の判断
今すぐ大きな物件データベースを作る段階ではない。
まずは、少数の記事で「追跡できるか」「人間の確認量はどれくらいか」「Codexにどこまで任せられるか」を見る。
記事本文だけで追えるうちは記事本文で管理する。件数が増えて、確認作業が重くなったら、CSVやローカル台帳へ移す。
この順番が現実的だと思う。
更新履歴
- 2026-06-15 初版公開
- 2026-06-17 パーソナルOS実験室の4本柱に入れた理由と、今後の判断基準を追記。
2026年7月12日追記：3件から6件運用へ
EXP-006は、当初の3件追跡から、既存3件＋新規3件の合計6件運用へ進みました。
ただし、物件数をどんどん増やす方向ではなく、軽く回せるかを確認する運用に切り替えています。
今後は「6件だけ、差分だけ、Markdown 1枚で確認する」形にします。
毎回見るのは、URLが開くか、掲載が続いているか、価格変更があるか、掲載終了や確認不能になっていないか、という点だけです。
情報提供日だけの変化では、原則としてWordPress記事は更新しません。価格変更、掲載終了、URL確認不能など、大きな変化があった時だけ更新候補にします。
物件追跡は、深掘りではなく差分を見る作業として扱います。
コメント