Claude Sonnet 5で不動産テックの業務エージェントを構築する｜設計7ステップと落とし穴

Claude Sonnet 5とは、Anthropicのエージェント向け中価格帯AIモデルのことです。

質問に答えるAIと、作業をこなすAIは、設計がまったく違います。前者はプロンプトを書けば動きますが、後者は「何をどこまで自動で判断させるか」を先に決めないと業務に載りません。2026年6月30日に公開されたClaude Sonnet 5は、エージェント用途を主眼に置いた中価格帯モデルで、導入価格は100万トークンあたり入力2米ドル・出力10米ドル（2026年8月31日まで、以降は入力3米ドル・出力15米ドル）。不動産テックの業務自動化を内製で組むとき、費用と性能のバランスが最も取りやすい位置にあるモデルです。本記事は、宅建業免許（東京都知事(1)第113520号）を保有し、AI導入コンサル100社超の実績を持つ株式会社オルセル（不動産のチカラ運営）の知見をもとに、不動産業務のエージェントを設計する7ステップを、権限設計と失敗パターンつきで整理します。

エージェントと自動生成は、どこが違うのか

違いは、判断の回数です。文章の自動生成は「入力を受けて1回出力する」処理ですが、エージェントは「状況を見て、次に何をするか自分で決めて、道具を使い、結果を見てまた決める」という繰り返しを行います。この繰り返しが業務に載るかどうかが、不動産テックの実装で最初に問われる点でした。

TechCrunchの報道は、Sonnet 5をエージェントをより安く動かすための選択肢と位置づけています。エージェントは1つの仕事を終えるまでにモデルを何度も呼ぶため、1回あたりの単価が総コストに直接効きます。Anthropicの発表によれば、Sonnet 5は2026年6月30日公開で、導入価格が入力2米ドル・出力10米ドル、2026年9月以降は入力3米ドル・出力15米ドル。最上位のOpus 5が入力5米ドル・出力25米ドルであることを踏まえると、繰り返し呼ぶ処理では2倍以上の差が出ます。

不動産業務でエージェント化する価値が高いのは、工程が複数にまたがる仕事です。例を1つ挙げると、募集条件の変更が入ったときの一連の作業。自社マスタの更新、ポータル3社への反映、募集図面の差し替え、追客中の顧客への案内。人がやると30分かかるこの流れを、エージェントに「条件変更の指示を受けて、関係する各処理を実行し、完了報告を出す」形で任せられれば、担当者は指示と確認だけで済みます。

一方、エージェント化に向かないのが、判断を誤ったときの取り返しがつかない仕事です。契約書の送付、申込の承認、賃料の変更確定。これらは人の承認を挟む設計にしてください。エージェントの自律性は、失敗したときのコストと引き換えに設定するものでした。

現場で繰り返し見るのは、この線引きを決めずに「全部自動化」を目指して頓挫するパターンです。設計の第一歩は、業務を「完全自動」「人が承認」「人が実行」の3つに仕分ける作業でした。この仕分けに1日かけると、その後の実装が驚くほど速く進みます。

不動産業務エージェントの設計7ステップ

設計は、業務の棚卸しから始めて、権限の確定で終わります。順序を飛ばすと、後から作り直しになる箇所が出ます。

第1ステップは、対象業務の切り出しです。1つのエージェントに複数の業務を持たせず、「募集条件の変更対応」「反響の一次仕分け」「更新契約の案内」のように単位を絞ってください。1エージェント1業務が原則です。複数業務を1つに詰め込むと、動作の検証ができなくなります。

第2ステップは、その業務で使う道具の洗い出しです。エージェントが呼べる機能を、道具として定義します。物件マスタの検索、物件マスタの更新、メール送信、ポータルへの反映、担当者への通知。この5つが不動産業務の基本セットでした。道具ごとに「読むだけ」「書き込む」の区別を明確にしておいてください。

第3ステップが、権限設計です。読むだけの道具は自由に使わせ、書き込む道具には条件を付けます。「賃料の変更は5%以内なら自動、それ以上は担当者の承認」「メール送信は下書き作成まで、送信は人」といった具合です。この設計が、エージェント実装の中核でした。技術的な難しさではなく、業務判断の難しさがここに集中します。

第4ステップは、外部システムとの接続です。2026年時点では、Model Context Protocol（MCP）が接続の共通規格として定着しつつあります。自社の顧客管理システムや物件マスタにMCPサーバーを立てると、エージェントから道具として呼べるようになります。ただし、業界システムへの接続は各システムの利用規約が優先します。不動産流通標準情報システムのような会員制のシステムについては、規約の範囲を超えた自動アクセスを行わない設計にしてください。

第5ステップは、失敗時の挙動の定義です。道具の呼び出しが失敗したとき、エージェントは何をすべきか。再試行するのか、担当者に通知して止まるのか。不動産業務では「止まって人に渡す」が安全側の設計でした。エージェントが勝手に代替手段を探す設計にすると、想定外の処理が走ります。

第6ステップは、ログの設計です。エージェントが何を判断して何を実行したかを、後から追える形で残してください。宅地建物取引業法上の記録保存義務がある書類に触れる処理であれば、この記録は業務上の必須要件になります。最低限、実行日時、判断の根拠、呼び出した道具、結果の4項目を残す設計にしてください。

第7ステップが、段階的な権限の解放です。最初は全処理を「人が承認」に設定し、2週間運用して誤りがゼロだった処理から順に自動化を許可していく。この順序を守ると、事故が起きても被害が小さく済みます。逆に、最初から自動で走らせて後から絞る運用は、信頼を失ったあとに回復させる作業が発生します。

エージェントに与える指示文の書き方

指示文は、役割、道具、制約、判断基準の4つで構成します。以下は募集条件変更エージェントの例です。

エージェント指示文1：募集条件変更エージェント

あなたは日本の賃貸管理会社の業務エージェントです。募集条件の変更指示を受け取り、関係する処理を実行します。

使える道具：
- search_property(条件)：物件マスタを検索し、物件情報を返す
- update_property(物件ID, 項目, 値)：物件マスタを更新する
- draft_notification(顧客ID, 内容)：顧客への案内文を下書きする
- notify_staff(担当者, 内容)：担当者に通知する

権限：
- search_property：制限なく使用可
- update_property：賃料の変更幅が現在値の5%以内、かつ募集中の物件に限り自動実行可。それ以外は notify_staff で承認を求める
- draft_notification：下書きの作成のみ。送信は行わない
- notify_staff：制限なく使用可

判断基準：
1. 変更指示の内容が曖昧な場合、推測せず notify_staff で確認を求める
2. 対象物件が特定できない場合、候補を列挙して notify_staff で確認を求める
3. 変更後の値が明らかに異常（賃料が0円、面積が1平方メートル未満など）な場合、実行せず notify_staff
4. 1回の指示で3件を超える物件を更新する場合、実行前に notify_staff で確認を求める

制約：
- 権限にない操作を代替手段で実現しようとしないこと
- 道具の呼び出しが失敗した場合、再試行は1回まで。2回目の失敗で notify_staff して停止すること
- 実行した処理はすべて、判断根拠とあわせて出力すること

道具の説明を書くときは、何をするかだけでなく、失敗する条件も書いてください。「該当物件がない場合は空の配列を返す」のような記述があると、エージェントの挙動が安定します。

もう1つ、反響の一次仕分けエージェントの例を挙げます。こちらは判断のみで、書き込みを持たない設計です。

エージェント指示文2：反響一次仕分けエージェント

あなたは賃貸仲介店舗の反響を仕分けるエージェントです。受信した問い合わせを分類し、担当者に振り分けます。

使える道具：
- search_property(条件)：物件マスタを検索する
- check_availability(物件ID)：空室状況を確認する
- assign_to(担当者, 反響ID, 理由)：反響を担当者に割り当てる
- notify_staff(担当者, 内容)：担当者に通知する

権限：
- search_property, check_availability：制限なく使用可
- assign_to：制限なく使用可（割り当てのみ。顧客への連絡は行わない）
- notify_staff：制限なく使用可

判断基準：
1. 問い合わせ物件が満室の場合、代替物件を検索したうえで、その旨を理由に含めて担当者へ割り当てる
2. 設備の不具合・水漏れ・鍵の紛失に関する内容は、緊急として管理担当へ即時に割り当て、あわせて notify_staff
3. 法人契約・事業用物件に関する問い合わせは、法人担当へ割り当てる
4. 内容が判別できない場合は、店長へ割り当てて理由に「判別不能」と明記する

制約：
- 顧客への返信文を作成・送信しないこと
- 個人情報を出力に含めないこと（反響IDで参照する）
- 空室状況を推測しないこと。check_availability の結果のみを根拠にすること

この2本を見比べると分かる通り、エージェント設計の実体は権限と判断基準の記述です。モデルの性能に頼る部分は思ったより少なく、業務ルールをどれだけ明文化できるかで品質が決まります。

内製とベンダー導入の判断軸

判断軸は、業務の独自性です。自社固有の業務フローに深く紐づく処理なら内製、業界共通の処理ならベンダーの製品を検討する、という順序が合理的でした。

内製が向くのは、自社の顧客管理システムや物件マスタと密に連携する処理です。既存システムの構造は自社しか知らないため、外部に説明する工数だけで内製の実装期間を超えることがあります。Claude Codeのような開発支援環境を使えば、社内に専任の開発者が1名いれば小規模なエージェントは組めます。

ベンダー導入が向くのは、電子契約、入居者向けアプリ、精算処理のように業界共通で、法令対応が伴う領域です。ここを内製すると、法改正のたびに自社で追随する負担が発生します。

判断が難しいのが中間領域です。反響の自動仕分け、内見予約の受付、更新案内の送付。この領域は製品も存在しますが、自社の運用に合わせる調整が発生します。不動産×AI導入コンサルの現場で繰り返し確認したパターンとして、この中間領域を内製した会社は初期の満足度が高い一方、担当者が異動すると保守が止まるという問題を抱えがちでした。内製する場合は、設計書と運用手順を人に依存しない形で残す前提を置いてください。

費用の目安を整理します。内製の場合、小規模なエージェント1つの初期構築に開発工数で3〜10人日、モデル利用料は処理量次第で月数千円から数万円。ベンダー導入の場合は初期費用が数十万円から、月額が管理戸数や店舗数に応じた課金という構造が一般的でした。件数が少ないうちは内製が安く、規模が大きくなるほど製品のほうが総保有コストで有利になる分岐点があります。

90日で1本目を動かすロードマップ

最初の1本を90日で本番に載せる、という目標設定が現実的でした。それ以上短いと権限設計が雑になり、それ以上長いと社内の関心が薄れます。

最初の30日は、業務の棚卸しと対象の選定に充てます。候補となる業務を5つ挙げ、それぞれについて「1件あたりの所要時間」「月間件数」「誤ったときの被害の大きさ」を書き出してください。所要時間と件数の積が大きく、被害が小さいものが最初の1本に向きます。反響の一次仕分けや、更新契約の案内準備がこの条件に当てはまりやすい業務でした。逆に、初回から契約や入金に関わる業務を選ぶと、権限設計だけで90日が終わります。

次の30日が、設計と試作です。道具の定義、権限の設定、指示文の作成を行い、実際のデータで20件ほど動かして挙動を確認します。この段階では本番システムへの書き込みを一切許可せず、「こういう処理を行います」という出力だけを出させてください。20件の出力を担当者が読み、判断が妥当かを確認する。この工程を飛ばして本番に載せた会社では、権限の抜け穴が運用開始後に見つかりました。

最後の30日は、限定運用です。特定の店舗、特定の物件種別、特定の時間帯に絞って本番投入し、全処理を人が事後確認します。誤りがゼロの処理から順に、事後確認を抜き取りへ切り替えていく。この30日で運用手順書を書き上げ、担当者以外でも運用できる状態にしておいてください。

90日を終えた時点で持っているべきものは、動くエージェントそのものより、業務ルールが明文化された文書のほうです。2本目以降のエージェントは、この文書があると設計期間が半分以下に縮みます。1本目に時間をかける価値は、そこにありました。

社内の合意形成についても触れておきます。エージェント導入は業務手順の変更を伴うため、現場の担当者が「仕事を取られる」と受け取ると運用が回りません。導入の説明では、削減される作業と、その時間で何をするかをセットで示してください。反響の仕分けが自動化されるなら、空いた時間を内見の同行や物件開拓に回す、という具体の絵を先に描いておくことをおすすめします。

業務エージェントで事故が起きる3つの場面

1つ目は、権限の抜け穴です。「賃料の変更は5%以内」と制限したのに、エージェントが「削除して新規作成」という経路で実質的に大幅変更を実現してしまう、という種類の事故があります。回避策は、道具の側で制限をかけることでした。指示文の制約は破られる可能性がありますが、道具の実装側で変更幅を検証すれば、破られません。権限は指示文と道具の両方で二重にかけてください。

2つ目は、ループです。エージェントが同じ処理を繰り返し、モデルの呼び出し回数が想定外に膨らむ。費用面の被害だけでなく、外部システムへ大量のリクエストを送る事故につながります。回避策は、1つの仕事あたりの道具呼び出し回数に上限を設けることです。20回で打ち切って人に渡す、といった制限を実装側に入れてください。

3つ目は、個人情報の混入です。エージェントは業務データを扱うため、顧客の氏名や連絡先がモデルに渡ります。個人情報保護委員会の注意喚起にある通り、外部サービスへの個人データ提供に当たらないかは設計時点で確認が要ります。回避策として現場で定着しているのは、エージェントには顧客IDだけを扱わせ、氏名や連絡先は最終的なメール送信処理の側で差し込む設計でした。指示文でも「個人情報を出力に含めない」と縛りますが、そもそも渡さない設計のほうが強い。

宅地建物取引業法との関係も押さえてください。重要事項の説明、契約書への記名は宅地建物取引士の業務であり、エージェントに実行させる設計にはできません。書類の準備までがエージェントの守備範囲、という線引きを社内で明文化しておくことをおすすめします。

エージェント時代に、不動産テックの何が変わるか

変わるのは、システム間の接続コストです。これまで、顧客管理システムとポータル入稿システムと会計システムをつなぐには、それぞれの仕様に合わせた個別開発が要りました。MCPのような共通規格が広がると、この接続部分の実装が定型化していきます。

不動産テック各社の製品戦略にも影響が出ます。単機能の製品は、エージェントから呼ばれる道具の1つとして組み込まれる方向に動く。逆に、業務全体を抱え込む統合型の製品は、外部から呼べる形で機能を開放するかどうかの判断を迫られます。この構図は、2027年に向けて業界地図を動かす要因になると見ています。

不動産会社側の準備としては、自社データの整理が先でした。エージェントが道具として呼ぶ先は自社のシステムであり、そこに入っているデータが古かったり表記がばらついていたりすると、エージェントの判断品質が上がりません。物件マスタの正規化、顧客情報の重複整理、成約記録の構造化。この3つは、どのモデルを選ぶかとは無関係に効いてきます。

推測を含む見立てを1つ書いておくと、業務エージェントの普及で最初に差がつくのは、大手ではなく中規模の会社だと考えています。大手は既存システムが複雑で接続の設計に時間がかかり、零細は投資余力が限られる。管理戸数1,000戸から5,000戸、店舗数5から20という規模帯が、最も身軽に動ける位置にありました。

もう1つ、人の役割の変化についても書いておきます。エージェントが定型処理を担うようになると、担当者に求められるのは「処理を速くこなす力」から「エージェントの出力が妥当かを判断する力」へ移ります。この判断力は、業務経験がないと身につきません。新人が定型作業を通じて業務を覚えるという教育の経路が細くなるため、育成方法を別途設計する必要が出てきます。管理会社の何社かでは、新人の最初の3か月はあえてエージェントを使わせず、手作業で業務の型を覚えさせる方針を採っていました。効率だけで判断すると見落とす論点です。

競合の情報発信を見ていて気になるのは、エージェントの話題が「どこまで自動化できるか」に寄りすぎている点でした。実務で問われるのは、どこを自動化しないかの判断のほうです。全部自動にできる業務など不動産にはほとんどなく、人が承認する箇所を設計することがエージェント実装の本体でした。この視点で製品を選ぶと、ベンダー比較の見方も変わります。承認フローの柔軟性を持たない製品は、自社の業務ルールに合わせられません。

よくある質問

Claude Sonnet 5とOpus 5はどう使い分けますか

エージェントのように同じ仕事の中でモデルを何度も呼ぶ処理はSonnet 5、1回の判断が重い契約書レビューなどはOpus 5、という振り分けが費用面で合理的です。Sonnet 5は導入価格で入力2米ドル・出力10米ドル、Opus 5は入力5米ドル・出力25米ドルという差があります。

エージェントの構築にはどのくらいの期間がかかりますか

小規模なもので3〜10人日が目安です。実装そのものより、業務の棚卸しと権限設計に時間がかかります。設計を1日で終える前提を置かず、業務を「完全自動」「人が承認」「人が実行」に仕分ける作業に丸1日を確保してください。

社内に開発者がいなくても構築できますか

いいえ、外部システムと接続する本格的なエージェントには開発の知識が要ります。ただし、道具を持たず判断だけを行う仕分けエージェントであれば、既存の業務自動化ツールと組み合わせて構築できる場合があります。まず判断のみの用途から始めるのが現実的でした。

レインズやポータルサイトに自動接続してもいいですか

各システムの利用規約が優先します。会員制のシステムについては、規約の範囲を超えた自動アクセスを行わない設計にしてください。まずは自社が保有する顧客管理システムや物件マスタとの接続から始めるのが順当な順序です。

エージェントが誤った処理をした場合、どう防ぎますか

権限を指示文と道具の実装の両方でかける二重の設計が有効です。指示文の制約は破られる可能性がありますが、道具の側で変更幅や実行回数を検証すれば止まります。あわせて、1つの仕事あたりの呼び出し回数に上限を設けてください。

重要事項説明をエージェントに任せられますか

いいえ、重要事項の説明と書面への記名は宅地建物取引士の業務であり、エージェントに実行させる設計にはできません。エージェントの守備範囲は書類の準備と整合チェックまでで、説明と判断は人が担う線引きを社内で明文化してください。

月額の費用はどのくらいになりますか

処理量に比例します。1つの仕事で20回モデルを呼び、1回あたり入力3,000トークン・出力500トークンとすると、Sonnet 5の導入価格で1件あたり0.17米ドル前後。月500件でも85米ドル、日本円で1万3千円ほどの計算です。実際には開発と保守の工数が費用の大半を占めます。

参考文献

不動産テックの動向は不動産テックカテゴリ、モデルの使い分けはAIモデル別カテゴリにまとめています。判断の重い処理についてはClaude Opus 5の不動産業務活用ガイドもあわせてご覧ください。

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

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

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