Gemini 3.6 Flashで物件情報を一括処理する｜マイソク・CSV・図面を1件1円弱で構造化する実装手順

Gemini 3.6 Flashで物件情報を一括処理する｜マイソク・CSV・図面を1件1円弱で構造化する実装手順

Gemini 3.6 Flashとは、Googleの低コスト高速AIモデルです。

マイソク1枚を読み取って物件データベース用の項目に落とすコストは、2026年8月時点でおおむね1件1円弱。3,000件の物件を一括で処理しても3,000円前後という計算になります。2026年7月21日に公開されたGemini 3.6 Flashは、100万トークン超のコンテキストとPDF・画像・音声・動画の入力に対応しながら、価格を抑えた位置づけのモデルです。判断の重い契約書レビューには最上位モデルを使い、量をこなす物件データの整形にはFlashを回す。この二段構えが、2026年後半の不動産事業者にとって現実的なコスト設計になりました。本記事は、宅建業免許（東京都知事(1)第113520号）を保有し、AI導入コンサル100社超の実績を持つ株式会社オルセル（不動産のチカラ運営）の現場知見をもとに、物件情報の一括処理をFlashに載せる手順を、プロンプト6本つきで整理します。

マイソクと物件CSVを、1件1円弱で構造化する

一括処理が現実的になった理由は、単価と入力形式の2点です。Google公式のモデル一覧によると、Gemini 3.6 Flashは2026年7月21日に公開され、入力104万8,576トークン、出力6万5,536トークンに対応します。入力はテキストだけでなく、画像、動画、音声、PDFを直接受け付けます。価格はOpenRouterのモデルページの掲載値で入力100万トークンあたり1.50米ドル、出力100万トークンあたり7.50米ドル、キャッシュ済み入力は0.15米ドル（公式の課金体系は契約形態で変わるため要確認）。

この単価を物件処理の実務に当てはめてみます。マイソク1枚をPDFで渡した場合、入力は1,500トークン前後、出力を構造化データ500トークンとすると、1件あたり0.006米ドル、日本円で1円弱です。賃貸仲介の店舗が扱う募集図面が月300枚なら300円、管理会社が保有する3,000件を一括で棚卸ししても3,000円前後。この価格帯だと、費用対効果を議論する前に試せます。

不動産の実務で効くのは、PDFと画像をそのまま渡せる点でした。物件情報は、CSVで整った形で存在していることのほうが少ない。実態はPDFのマイソク、FAXから取り込んだ画像、手書きが混ざった募集条件のメモ、といった雑多な形式です。これらをテキスト化してから渡す工程が要らないのは、実務上の負担が1段階減ります。

現場で繰り返し見るのは、この「前処理が要らない」点が過小評価されている状況です。OCRを別途用意して、精度を検証して、失敗パターンを潰す。この工程に数か月かけた会社を何社も見てきました。マルチモーダル入力に対応したモデルを使えば、その工程そのものが要らなくなります。

もう一点、Artificial Analysisの計測によれば、Gemini 3.6 Flashは前世代より出力トークン数がおよそ17%少ないとされています。同じ答えをより短く返すぶん、出力課金が下がる方向に効きます。知識のカットオフは2026年3月とされているため、それ以降の法改正や制度変更については、資料を一緒に渡して判断させる設計にしてください。

Flashに向く仕事と、向かない仕事の線引き

向くのは、判断基準が明確で量が多い仕事です。向かないのは、法的責任が伴う判断と、微妙なニュアンスの読み取りでした。

向く仕事の代表が、物件データの正規化です。住所表記のゆれ、駅名と徒歩分数の書式統一、面積の単位変換、間取り表記の統一。ルールが明文化できる作業は、量が増えても品質が落ちません。次いで、マイソクからの項目抽出。賃料、管理費、敷金・礼金、間取り、専有面積、築年、所在階、構造といった定型項目は、抽出の正解が一意に決まるため機械処理と相性が良い領域です。

問い合わせメールの分類も向いています。「内見希望」「条件変更の相談」「設備の不具合」「解約の申し出」といったラベル付けは、担当者の割り振りを速くします。直近の支援案件で観測したのは、分類を自動化した結果、返信までの中央値が短くなる一方で、緊急度の高い設備トラブルが「その他」に落ちるケースが出たという現象でした。分類のラベル設計は、運用開始から1週間で見直しが入るものと考えておいてください。

向かない仕事の筆頭が、重要事項説明書のチェックや契約書レビューです。ここは法的責任が伴い、指摘の見落としがそのまま損害につながるため、判断力の高いモデルを使うべき領域でした。Claude Opus 5の1Mコンテキストで契約書をレビューする手順で書いた通り、書類の横断整合を見る仕事は最上位モデルの担当です。

査定額の算出も向きません。というより、どのモデルでも向きません。AI査定は参考値であり、顧客に提示する価格は宅地建物取引士が根拠を持って判断すべきものです。この線引きは、モデルの性能とは無関係に維持してください。

判断が分かれるのが、物件紹介文の生成です。定型的な紹介文なら量産できますが、物件の魅力を言語化する部分では出力が平板になりがちでした。ある管理会社では、Flashで下書きを大量生成して、成約率の高い物件だけ人が書き直す、という二段構えに落ち着いています。全件を人が書くのでもなく、全件をAIに任せるのでもない配分が現実解でした。

物件情報の一括処理プロンプト6本

以下の6本は、Google AI StudioまたはGemini APIでそのまま使えます。件数が多い処理はAPI経由が現実的ですが、まず10件ほど手作業で試して出力の形を確かめてから自動化に進んでください。

1本目は、マイソクのPDFから項目を抽出する基本形です。

プロンプト1：マイソクPDFからの項目抽出

以下のPDFは、日本の不動産の募集図面（マイソク）です。記載内容から以下の項目を抽出し、JSON形式で出力してください。

抽出項目：
building_name（建物名）, room_number（部屋番号）, address（所在地）,
nearest_station（最寄駅）, walk_minutes（徒歩分数・整数）,
rent（賃料・円・整数）, management_fee（管理費・円・整数）,
deposit_months（敷金・か月）, key_money_months（礼金・か月）,
layout（間取り）, area_sqm（専有面積・平方メートル・小数第2位）,
built_year（築年・西暦4桁）, floor（所在階）, structure（構造）,
parking（駐車場の有無と月額）, notes（特記事項）

制約：
- 図面に記載がない項目は null とし、推測で埋めないこと
- 賃料に管理費が含まれているか判別できない場合は notes に記載すること
- 「相談」「要問合せ」などの記載は、数値化せずそのまま文字列で残すこと
- 読み取りに自信がない項目は confidence_low の配列に項目名を列挙すること

2本目は、既存の物件データベースの表記ゆれを一括で直すものです。

プロンプト2：物件データの表記ゆれ正規化

以下のCSVについて、下記ルールで正規化したCSVを出力してください。

正規化ルール：
- 住所：「都道府県＋市区町村＋町名＋丁目-番-号」、数字は半角アラビア数字
- 駅：「路線名／駅名」、徒歩は半角数字＋「分」
- 面積：平方メートル、小数第2位まで、単位表記は列名に含め値には入れない
- 築年：西暦4桁、和暦は変換する
- 間取り：1R／1K／1DK／1LDK／2K／2DK／2LDK／3LDK… の表記に統一
- 賃料・管理費：半角数字のみ、円単位、カンマなし

出力：
1. 正規化後のCSV（ヘッダー付き）
2. 変換できなかった行の行番号と理由
3. 元データに矛盾があった行（例：面積が間取りに対して極端に小さい）

制約：
- 元データにない値を補完しないこと
- 和暦変換で年が特定できない場合は空欄にし、理由に記載すること

入力CSV：
{貼り付け}

3本目は、問い合わせメールの分類と優先度付けです。

プロンプト3：問い合わせメールの分類と緊急度判定

以下の問い合わせを、カテゴリと緊急度で分類してください。

カテゴリ：
A. 内見希望・空室確認
B. 条件相談（賃料・入居時期・ペット等）
C. 設備の不具合・修繕依頼
D. 契約手続き（申込・更新・解約）
E. 苦情・近隣トラブル
F. その他

緊急度：
高（当日中の対応が要る）／中（翌営業日）／低（週内）

緊急度「高」の判定基準：
- 水漏れ、ガス漏れ、鍵の紛失、停電、給湯器の故障（冬季）
- 近隣トラブルで身の危険に言及があるもの
- 当日中の内見希望

出力形式：
問い合わせID／カテゴリ／緊急度／判定理由（40字以内）／推奨担当（営業・管理・工事）

制約：
- 判断に迷うものは緊急度を1段階高く見積もること
- 個人名は出力に含めないこと

問い合わせ一覧：
{貼り付け}

4本目は、物件写真から掲載用のキャプションを作るものです。画像を直接渡します。

プロンプト4：物件写真のキャプション生成

以下の物件写真について、ポータルサイト掲載用のキャプションを1枚につき1本作成してください。

要件：
- 1本あたり30〜40字
- 写真に写っているものだけを記述する
- 設備の有無を断定する場合は、写真から明確に判別できるものに限る
- 主観的な評価語（素敵、快適、理想的）は使わない
- 方位・日当たり・眺望は、写真だけでは判断できないため書かない

出力：
写真番号／キャプション／写真から判別できなかった要素

制約：
- 写っていない設備を推測で書かないこと
- 生活感のある私物が写っている場合は、その旨を別欄で報告すること

5本目は、募集条件の変更履歴を突き合わせて、更新漏れを探すものです。

プロンプト5：ポータル掲載情報と自社マスタの突き合わせ

以下の2つのデータを突き合わせ、内容が食い違っている物件を洗い出してください。

データA：自社の物件マスタ（最新）
{CSV}

データB：ポータルサイトに掲載中の情報
{CSV}

出力：
1. 賃料・管理費・敷金礼金が食い違っている物件（物件ID、項目名、A側の値、B側の値）
2. 自社マスタでは成約済みだが、ポータルに掲載が残っている物件
3. ポータルにあるが自社マスタに存在しない物件
4. 設備・条件（ペット可、楽器可、事務所利用可など）が食い違っている物件

制約：
- 表記ゆれによる見かけ上の差異（「1LDK」と「１ＬＤＫ」など）は差異として報告しないこと
- 判断がつかない差異は「要確認」として分けること

6本目は、内見動画から物件の特徴を抽出するものです。動画入力に対応したモデルならではの使い方でした。

プロンプト6：内見動画からの特徴抽出

以下の内見動画を見て、物件の特徴を整理してください。

出力：
1. 撮影されている部屋の順序と、それぞれのおおよその広さの印象
2. 動画から確認できる設備（映っているものに限る）
3. 内見時に入居希望者から質問が出そうな箇所
4. 動画に映っていないため、別途撮影・確認が必要な箇所
5. この物件の紹介文に使えそうな事実ベースの特徴を3点

制約：
- 映っていないものを推測で補わないこと
- 日当たり・騒音・においなど、動画から判断できない要素は「動画では判断不可」と明記すること
- 広さは断定せず「印象」として記述すること

6本のうち1、2、3は毎日回す処理、4と5は週次、6は案件ごとという運用頻度が現場では定着しやすい配分でした。

一括処理で事故が起きる3つの場面

1つ目は、誤った値がデータベースに書き戻される場面です。抽出処理は精度が100点になりません。図面の印字が薄い、手書きの修正が入っている、単位が省略されている。こうした条件で誤読が起きたとき、そのまま自社マスタに書き戻すと、誤った賃料でポータルに掲載される事故につながります。回避策は、プロンプト1に入れた confidence_low の仕組みです。自信のない項目を機械側に申告させ、その行だけ人が確認する運用にしてください。全件を人が確認するのでは自動化の意味がなくなりますが、申告のあった1割だけなら現実的な工数に収まります。

2つ目は、個人情報が処理対象に混ざる場面です。問い合わせメールの分類では、氏名、電話番号、勤務先が本文に含まれます。個人情報保護委員会の注意喚起にある通り、本人の同意なく個人データを外部サービスへ提供する形になっていないかは事前に確認が要ります。分類処理では、氏名と連絡先を除いた本文だけを渡す前処理を挟むのが定石でした。プロンプト3で「個人名は出力に含めない」と縛っているのは、出力側の保険にすぎません。入力側で落とすほうが筋の良い設計でした。

3つ目は、広告表示の規制に触れる文章が量産される場面です。物件紹介文を一括生成すると、「駅近」「閑静な住宅街」「日当たり良好」といった表現が全物件に付きます。徒歩分数の実測根拠がないまま「駅近」と書けば、不動産の表示に関する公正競争規約に照らして問題になりうる。消費者庁の表示対策が示す考え方に沿って、事実の裏付けがある表現だけを使う制約をプロンプトに入れてください。一括処理は間違いも一括で量産します。

不動産×AI導入コンサルの現場で繰り返し確認したパターンとして、自動化の初期に「量が増えたこと」を成果として報告してしまう傾向があります。処理件数ではなく、人が手直しした件数の比率を追ってください。この比率が下がらないなら、自動化できていないのと同じでした。

一括処理を始める前に決めておく4つのこと

決めるべきは、対象範囲、出力の受け皿、検証の抜き取り率、失敗時の戻し方の4点です。この4つを先に決めないまま3,000件を流すと、出力は手に入るのに使えない、という状態になります。

対象範囲は、物件の種別と時期で切ります。全物件をいきなり対象にせず、「現在募集中の賃貸物件」「直近1年の成約物件」のように条件を絞ってください。種別が混ざると、抽出項目が物件ごとに異なり、出力の形が揃わなくなります。区分マンションと一棟アパートと土地では、必要な項目がそもそも違う。分けて処理するほうが結果的に速く終わります。

出力の受け皿は、自社の物件マスタに直接書き戻すのか、いったん別テーブルに溜めるのかという設計です。直接書き戻す設計は運用が楽に見えますが、誤読が混ざったときに元の値がどこにも残りません。中間テーブルを挟み、差分を確認してから反映する二段構えのほうが、事故が起きたときに戻せます。管理戸数が数百戸を超える会社では、この設計の差が後から効いてきました。

検証の抜き取り率は、最初の1回だけ高めに設定します。300件の処理なら30件、つまり1割を人が目視で照合し、誤りの傾向を掴んでください。誤りには偏りがあります。特定の業者が作成した図面だけ読み取り精度が落ちる、和暦表記の築年だけずれる、といった傾向が見えれば、プロンプト側で先回りできます。2回目以降は3%程度まで下げても運用が回りました。

失敗時の戻し方は、処理前のデータをどこに退避しておくかという話です。CSVを1本コピーしておくだけで済みますが、これを忘れると誤った上書きが取り返しのつかない事故になります。処理日時をファイル名に入れて退避する運用を、手順書の1行目に書いておいてください。

この4点を決める作業に、初回で2時間ほど。3,000件の処理そのものより、前後の設計に時間がかかるのが実情です。

3,000件を流すときの費用と時間の見積もり

費用は、入力の形式で大きく変わります。テキストのCSVなら1件あたり数百トークン、PDFのマイソクなら1,500トークン前後、写真1枚ならさらに増えます。3,000件のマイソクをPDFで処理する場合、入力450万トークン、出力150万トークンとして、掲載値ベースで入力6.75米ドル、出力11.25米ドル、合計18米ドル前後。日本円で2,700円ほどの計算です。

時間は、API経由で並列処理をするかどうかで桁が変わります。Google AI Studioの画面から1件ずつ流すなら3,000件は現実的ではありません。API経由で並列に流せば数時間で終わる規模ですが、そのためには簡単なスクリプトが要ります。社内に開発者がいない場合、まず300件だけ手作業で流して品質を確認し、それから外注や内製の判断をする順序が失敗しにくい進め方でした。

工数の目安としては、初回のプロンプト調整に4〜6時間、出力形式の確定に2時間、実行と検証に1日、という配分です。棚卸しのような一度きりの処理であれば、この初期工数を回収できる件数かどうかが判断基準になります。おおむね500件を超えるあたりから、手作業より速くなる計算でした。

キャッシュ済み入力の単価が通常の10分の1になる点は、同じ指示文を繰り返し使う一括処理と相性が良い仕組みです。プロンプト本体を固定し、物件データだけを差し替える設計にすると、指示文の部分がキャッシュ対象になります。件数が多いほどこの差が効いてきます。

大量処理が安くなると、不動産の情報戦はどう変わるか

変わるのは、情報を持っている会社と、情報を使える会社の差です。これまで、物件データを大量に保有していても、整形と分析に人手がかかるために活用できていない会社が大半でした。処理単価が1件1円を切ると、この制約が外れます。

具体的に効いてくるのが、過去データの棚卸しです。5年分の成約データ、問い合わせ履歴、内見記録。これらを構造化して並べると、自社の成約パターンが数字で見えてきます。どのポータルからの反響が成約に結びついているか、どの条件の物件が長期空室になりやすいか。分析そのものは以前から可能でしたが、データを揃える工程がボトルネックになっていました。

もう一つは、AI検索への対応です。入居希望者が生成AIに条件を伝えて物件を探す行動が増えると、自社サイトの物件ページが引用されるかどうかが集客に効いてきます。引用されるのは、構造化された正確な情報を持つページでした。物件情報の正規化は、社内の効率化であると同時に、外向きの集客施策でもあります。

3つ目に見ておきたいのが、価格競争の行方です。2026年7月にはOpenAIがGPT-5.6 Lunaの価格を8割引き下げたと報じられ、低コスト帯のモデルは各社が数か月おきに単価を切り下げる状況が続いています。この動きは、大量処理を前提とした業務設計にとって追い風でした。ただし裏を返せば、特定のモデルに深く依存した実装は、半年後に割高になっている可能性がある。プロンプトと出力形式をモデル非依存の形で管理しておき、モデルの差し替えが数時間で済む設計にしておくのが、現時点で取れる保険です。

不動産事業者にとって現実的な準備は、社内でどの処理をどのモデルに投げているかを一覧にしておくことでした。この一覧があるだけで、価格改定や新モデルの登場時に「どこを差し替えると効くか」が即座に判断できます。管理表はスプレッドシート1枚で足ります。処理名、使用モデル、月間件数、月額費用、最終更新日の5列を並べておいてください。

推測を含む見立てとして書いておくと、2027年に向けて差がつくのは、モデルの選択ではなくデータの状態だと考えています。どのモデルを使うかは3か月ごとに変わりますが、自社の物件データが整理されているかどうかは数年かけて積み上がる資産です。順序としては、データ整理が先でした。処理単価が下がり続けるということは、いま整理を始める会社ほど安く済むという意味でもあります。

よくある質問

Gemini 3.6 Flashは無料で使えますか

Google AI Studioには無料枠が用意されており、少量の検証であれば費用をかけずに試せます。ただし無料枠には利用回数の制限があり、業務での継続利用や大量処理にはAPIの有料利用が前提になります。無料枠の条件は変更されることがあるため、公式ドキュメントで最新の内容を確認してください。

PDFのマイソクをそのまま読ませられますか

はい、Gemini 3.6 FlashはPDF・画像・音声・動画を入力として直接受け付けます。OCRで事前にテキスト化する工程は不要です。ただし印字がかすれた図面や手書きの修正が入ったものは読み取り精度が落ちるため、自信度を申告させる仕組みを併用してください。

抽出した物件データをそのままポータルに掲載していいですか

いいえ、抽出結果を無検証で掲載する運用は避けてください。誤読による賃料や面積の誤りがそのまま広告表示になると、不動産の表示に関する規制上の問題につながります。自信度の低い項目だけを人が確認する二段構えの運用をおすすめします。

Claude Opus 5とGemini 3.6 Flashはどう使い分けますか

判断が重く責任を伴う仕事はClaude Opus 5などの最上位モデル、量が多く判断基準が明確な仕事はFlash、という振り分けが費用面で合理的です。契約書レビューは前者、物件データの正規化は後者に該当します。

何件から自動化する価値がありますか

おおむね500件が目安です。初回のプロンプト調整と出力形式の確定に1日強かかるため、それを下回る件数では手作業のほうが速く終わります。ただし毎月繰り返す処理であれば、月100件でも数か月で回収できる計算になります。

個人情報を含む問い合わせをそのまま処理していいですか

原則として、氏名・電話番号・勤務先などを除いた本文だけを渡す前処理を挟んでください。入力側で個人情報を落とす設計にしておけば、出力側の制約に頼る必要がなくなります。API利用時は入力データの取り扱い設定を契約形態ごとに確認してください。

出力が途中で切れることはありますか

出力の上限は6万5,536トークンです。3,000件を一度のリクエストで処理しようとすると上限に当たるため、100件前後に分割して回すのが実務的でした。分割の単位は、出力形式が固定されていれば結果の結合が容易です。

参考文献

モデル別の使い分けはAIモデル別カテゴリにまとめています。

著者：齋藤竹紘（株式会社オルセル 編集長／EC支援19年5,000社超／AIコンサル100社超／宅建業免許 東京都知事(1)第113520号）

※不動産のチカラでは、生成AIの導入支援から運用最適化まで、貴社の不動産事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://fudosannochikara.jp/contact/

【監修】齋藤竹紘（株式会社オルセル代表 / 宅建業免許 東京都知事(1)第113520号 / AI導入コンサル100社超）