kintone不動産管理｜物件・契約・発注・請求の一元化と事例

「あの物件、いま契約手続き中だったか、それとももう契約済みだったか」。不動産管理会社や仲介会社では、こうした確認のために担当者のExcelや紙の台帳を探し回る場面が日常的に起きます。物件情報は台帳、契約状況は担当者ごとのメモ、修繕の手配は電話とメール、入居者からの問い合わせは口頭、とバラバラだと、探す手間がかかるだけではありません。契約更新の見落としや二重対応のリスクも高まります。

この記事では、物件・契約・発注・請求・問い合わせの情報を、どのアプリに分けてどうつなぐかを整理します。読み終えたときに、自社の最初の1アプリを決められる状態を目指します。

1. Excel・紙管理の限界と、不動産管理アプリの全体像

物件・契約・入居者の情報をExcelや紙で管理していると、担当者ごとにファイルが分かれ、最新版がどれか分からなくなりがちです。同じ物件の情報を「物件台帳」「契約書ファイル」「対応履歴メモ」の3か所に別々に記録していると、1か所を更新しても他が古いまま残ります。担当者の異動や休みのタイミングで、引き継ぎ漏れも起きやすくなります。

特に契約更新期限のような「日付が来たら対応が必要な情報」は、担当者の記憶やカレンダーの手動チェックに頼ると見落としが避けられません。物件数・契約件数が増えるほど、この管理コストは重くなります。

賃貸管理の業務は、大きく次の流れに分けられます。

業務	管理したい情報	アプリの例
物件の管理	所在地・間取り・賃料・入居状況	物件マスタ
関係者の管理	オーナー・入居者・連帯保証人	オーナーマスタ、入居者マスタ
契約の管理	契約期間・賃料・更新方法・進捗	契約管理
修繕・清掃の手配	業者・発注内容・支払い状況	業者マスタ、発注管理
お金の管理	退去精算・請求・オーナーへの報告	請求管理
入居者対応	受付内容・担当・対応状況	問い合わせ管理

これを最初から全部作る必要はありません。まず物件マスタと契約管理の2つから始め、運用しながら発注や問い合わせへ広げる進め方が現実的です。kintoneアプリの作り方を3ステップで解説も、最初に何を作るかを決めるうえで参考になります。kintone公式の導入ガイドも、導入失敗パターンとして「100点を目指してリリースが遅れる」ことを挙げ、75点で早期に公開して改善する進め方を勧めています（kintoneの歩き方）。

2. マスタ設計：物件・オーナー・入居者を独立させる

アプリ分割の基本は、「変わりにくい情報」と「そのつど増える情報」を分けることです。物件、オーナー、入居者は前者、契約や発注、問い合わせは後者にあたります。

ここで押さえたいのは、物件と契約の2アプリだけで済ませないほうがよい場面があることです。1人の入居者が複数の物件を借りている場合や、連帯保証人・緊急連絡先を持たせたい場合です。契約アプリの中に入居者の氏名と連絡先をそのまま書くと、同じ人の情報が契約の数だけ複製されます。連絡先が変わったとき、直す場所が増えてしまいます。入居者を独立したマスタにしておけば、直す場所は1か所で済みます。連帯保証人や緊急連絡先も、入居者マスタの項目として持たせるか、別アプリにするかを、運用に合わせて選べます。

マスタ同士・マスタと契約をつなぐ仕組みは、2つあります。

• ルックアップ：参照先アプリのレコード一覧から選ぶか、キーワードで絞り込んで一致するレコードを取得します。取得したデータには自動でリンクが生成され、クリックで取得元レコードを開けます（kintoneヘルプ：ルックアップの使い方）。
• 関連レコード一覧：参照先アプリを指定し、フィールドの対応付けや絞り込み条件、表示フィールド、並び順、最大表示件数を設定して、他アプリのレコードを一画面にまとめて表示します（kintoneヘルプ：関連レコード一覧フィールドの仕様）。

使い分けは次のとおりです。契約アプリの入力時に物件や入居者を選ぶ場面ではルックアップ、物件や入居者の詳細画面でその人・その物件に紐づく契約をまとめて見たい場面では関連レコード一覧が向いています。

なお、ルックアップで取得した情報は選択した時点のデータです。参照元を後から更新したときに自動で反映されるかどうかは、今回確認した公式ヘルプの本文では明確に確認できませんでした。更新頻度の高い項目は関連レコード一覧で常に最新を参照する構成にするなど、自社の環境で動きを確かめてから運用に組み込むと安心です。

「入居状況」を選択肢フィールドにしておくと、一覧で空室か入居中かを見分ける軸として使えます。上の画面は色付きの表示例ですが、見た目の設定は環境やカスタマイズによって変わりうるため、まずは選択肢で状態を持たせるところから始めてください。「年間賃料見込」のような単純な計算フィールドを1つ入れておくだけでも、収支の見通しを電卓で計算する手間は省けます。

3. 契約管理：ステータスとプロセス管理の二段構え

契約管理アプリは、次のようなフィールド構成が出発点になります。特定の企業の実装を再現したものではなく、不動産管理で共通して登場する項目をもとにした設計例です。会社ごとに過不足は調整してください。

区分	フィールド名	種類・選択肢
契約基本	物件名	ルックアップ（物件マスタ）
契約基本	契約者名	ルックアップ（入居者マスタ）
契約基本	契約開始日	日付
契約基本	契約終了日	日付
契約条件	月額賃料	数値
契約条件	更新方法	選択：自動更新、再契約、更新なし
契約条件	契約ステータス	選択：空室確認中、申込受付、契約手続き中、契約済み

契約の進捗は、プロセス管理機能で追えます。初期設定のまま「未処理→処理中→完了」の3段階で運用を始めれば、いま対応中の契約がどの段階で止まっているかを一覧で追えます。

物件ごとのもっと細かい状態（空室確認中・申込受付・契約手続き中・契約済みなど）は、先ほどの「契約ステータス」の選択肢フィールドで持たせます。こう役割を分けると、プロセス管理の設定はシンプルに保てます。そのうえで、現場が実際に使う言葉での状態管理も両立できます。

更新期限のリマインダー条件通知

契約更新期限のような「日付が来たら知らせてほしい情報」には、条件通知の中の「リマインダーの条件通知」が使えます。条件にできるのは日付または日時のフィールドのみで、条件を満たすと通知が1回だけ送信されます。下の画面は契約開始日を基準にした設定例です。更新リマインドとして使う場合は、契約終了日のような更新期限に近いフィールドを条件に選べば、同じ手順で設定できます。

設定した日付を過ぎたあとに自動で繰り返し通知されることはありません。そのため、更新のたびに日付を再設定するか、更新のサイクルが複数回あることを見込んで、テーブル機能で複数の日付フィールドを用意しておく必要があります（kintoneヘルプ：リマインダー条件通知の繰り返し設定）。更新手続きを終えたら次の期限を入れ直す、という作業を運用ルールに入れておくと、通知が途切れずに済みます。

なお、契約ステータスを計算式の条件に使って更新方法ごとに自動判定する仕組みを組みたくなるかもしれません。ただ、プロセス管理のステータスを計算フィールドの条件式で直接参照できるかどうかは、公式ヘルプで確認できていません。自動判定を組む場合は、事前に自社の環境で確かめてください。

4. 発注管理：修繕・清掃・点検を会社全体で追う

修繕、退去後の清掃、設備の点検。こうした外部業者への発注は、担当者ごとに電話やメールで済ませてしまいやすい業務です。現場でよくあるのは、退去立ち会いの翌週に、別の担当者が同じ部屋の清掃を同じ業者へ重ねて依頼してしまう場面です。誰がどの業者に何を頼み、支払いが済んだかどうかは、本人に聞かないと分かりません。

これを防ぐには、業者を業者マスタ、個々の依頼を発注管理に分け、発注管理から物件と業者をルックアップで選ぶ構成にします。設計例は次のとおりです。

アプリ	主なフィールド
業者マスタ	業者名、対応分野（修繕・清掃・点検など）、連絡先、担当者
発注管理	物件（ルックアップ）、業者（ルックアップ）、発注内容、発注日、完了予定日、金額、支払い状況（選択）

物件マスタの詳細画面に発注管理の関連レコード一覧を置けば、その部屋の修繕履歴が時系列で見えます。業者マスタ側にも置けば、特定の業者への発注状況を一覧できます。発注の進み具合を追いたい場合は、契約管理と同じようにプロセス管理を使う手もあります。

5. 請求・収支報告書管理：標準機能でどこまで組めるか

退去時の精算、入居者への請求、オーナーへの月次の収支報告。お金に関わる業務も、アプリ化の対象になります。設計の考え方は、次の2段階です。

1. 請求管理アプリに、契約（ルックアップ）、請求区分（家賃・退去精算・修繕費など）、請求額、請求日、入金状況を記録する
2. オーナー別に請求・入金・発注の金額を集めて、月次の報告に使う

2のオーナー別の集計は、請求管理や発注管理のレコードにオーナー名を持たせておくと、一覧の絞り込みや集計の元データとして使えます。

ただし、請求書や収支報告書を所定の書式で出力したい場合や、会計ソフトと連携したい場合に、kintone標準機能でどこまで対応できるかは、この記事では確認できていません。kintoneで見積書・納品書を印刷する3つの方法では帳票出力の手段をまとめているため、参考にしたうえで、「kintoneでデータを持ち、帳票・会計は別の手段を使う」という線引きも選択肢に入れてください。最初から全部を1つのアプリで済ませようとせず、記録と集計をkintone、書式を整える部分は別、と分けたほうが失敗しにくくなります。

6. 問い合わせ管理と、売買・地図への広げ方

入居者からの問い合わせや対応履歴は、専用の問い合わせ管理アプリにすると追いやすくなります。項目の設計例は、受付日、物件（ルックアップ）、入居者（ルックアップ）、内容、担当者（ユーザー）、対応状況（選択）です。担当者を「ユーザー」フィールドで指定しておけば、誰が対応中かも同時に管理できます。対応期限を日付で持たせれば、先ほどのリマインダーの条件通知で期限を知らせることもできます。通知は1回きりなので、期限を延ばしたら日付を入れ直してください。

各レコードのコメント欄には、担当者間のやり取りや対応記録を時系列で残せます。電話やメールで個別に管理していた履歴を、そのレコードを開くだけで確認できるようになります。

売買の管理は賃貸と分けて考える

地主・用地・商談の記録といった不動産売買の管理は、賃貸管理と必要な項目や進み方が違います。賃貸の契約管理アプリに無理に混ぜず、売買用に別のアプリ（案件、地主・用地など）を用意し、物件マスタだけを共通にする形が整理しやすいでしょう。

地図で見たいとき

物件の所在地を地図上に表示したい、というニーズもよくあります。ただし、kintoneの標準機能には地図・位置情報を表示するフィールドは含まれていません。地図表示には、公式ソリューションサイトに掲載されている専用の地図表示プラグインを別途導入する必要があります（kintone公式ソリューションサイト：地図表示プラグイン）。料金や設定手順はプラグインごとに異なるため、導入前に各製品の情報で確認してください。

7. 導入事例と、導入時の注意点・選び方

公式の導入事例3社

kintone公式サイトでは、不動産会社の事例が複数紹介されています。

千葉県八千代市の川島不動産では、Windows XP専用機で動くAccess製の日報システムと、後から編集できないGoogleフォーム＋スプレッドシートによる顧客管理をkintoneに置き換えました。日報アプリは1時間、来店カードアプリは半日で完成し、特別な指導をしなくても現場ですぐに運用が始まったといいます（kintone公式事例：川島不動産）。

京都で賃貸7,000室とマンスリーマンション300室を管理するフラットエージェンシーでは、単一のExcelファイルによる予約管理から、kintoneとExcelのガントチャート連携によるリアルタイムの空室確認、タブレットでの写真付きメンテナンス報告へ移行しました。フォームクリエイターとの連携でFAXなし・海外からの入居申込受付も可能になり、「受付がスマートになりスタッフ2人分の業務を圧縮できた」「退去後から再貸出までの期間短縮で稼働率が向上した」と報告されています（kintone公式事例：フラットエージェンシー）。

小田急沿線20店舗で分譲・賃貸・仲介を手がける小田急不動産では、委託先に依存したCRM運用と、営業日報を別システムへ二重入力する非効率が課題でした。顧客・物件・案件の情報を一元管理し、駅情報や郵便番号などのマスタ管理を含む30を超えるアプリを運用することで、二重入力が解消し、レコード連携によってアプリ間の情報が常に最新の状態に保たれるようになったといいます（kintone公式事例：小田急不動産）。

3社に共通するのは、紙やExcelの運用をそのまま写すのではなく、情報の持ち方から整理し直している点です。料金面では、スタンダードコースが1ユーザー月額1,800円（税抜・月額契約時、最低10ユーザーから）です。コース選びの比較はkintoneのライト・スタンダード費用と機能で選ぶ判断ガイドにまとめています。

導入時に気をつけたいこと

アプリを増やしすぎない。ここまで多くのアプリを挙げましたが、最初から全部作る必要はありません。物件マスタ＋契約管理から始め、必要になった順に発注、請求、問い合わせを足してください。アプリの数が増えるほど、関係を把握する担当者が必要になります。公式の導入失敗パターンには「担当者が一人しかいない」「現場の『使いづらい』の放置」も挙がっています。つまずきやすい点はkintone導入失敗パターンでも整理しています。

カスタマイズに頼りすぎない。既存の紙・Excel業務をそのまま踏襲するためのカスタマイズ開発は、開発工数・期間・保守コストを増大させやすいとされ、業務側をkintone標準の考え方に合わせる設計変更が推奨されています（SIGNPOST 1-06）。要件を検討する際も、「カスタマイズ開発で実現できることか」ではなく「カスタマイズ開発でしか実現できないことか」を確認すべきとされています（SIGNPOST 2-14）。推奨されない実装方法に依存した大幅なUI/UXカスタマイズは、アップデートの影響で想定どおり動作しなくなる可能性があるとも警告されています（SIGNPOST 3-29）。

容量の大きいファイルと外部連携は事前に整理する。物件写真のように容量の大きいファイルを多く扱う場合は、契約しているコースの容量条件を公式の仕様で事前に確認してください。この記事では容量の数値は確認できていないため、書いていません。会計ソフトや入退去管理システムなど外部システムと連携したい場合も、標準機能の範囲でどこまで対応できるかを先に整理しておくと、後戻りが減ります。

トラブル時の窓口を決めておく。公式ガイドは「kintoneが動かない」原因を、kintone自体の障害、カスタマイズJSの問題、連携先の外部システム障害、ユーザー端末・ブラウザの問題の4種類に分類しています。事前に対応フローを決めていないと、対応時間が膨れやすいと指摘しています（SIGNPOST 5-39）。

構築を相談する相手の選び方

自社だけで作り切れないとき、相談先を選ぶ基準は一つではありません。拠点が多く、体制や組織力を重視する場合は、認定パートナー企業の体制が合うことがあります。認定は、kintoneの技術を外形的に確認できる目安になります。一方で、認定が示すのはkintoneの技術であり、発注する側の業務（契約更新、修繕の手配、オーナー報告など）の実務理解までを保証するものではありません。見積りの内訳や進め方の確認は、認定の有無にかかわらず必要です。

kintone開発会社の選び方｜7つの基準では、相談先を選ぶときの判断軸をまとめています。運営者のpullieは、kintoneの認定パートナーではありません。建設・不動産の現場実務を経験したエンジニアが、業務の言葉のまま要件を聞き、小さく作って現場の声を聞きながら直していく進め方をとっています。現場への定着を最優先に小さく始めたい場合は、「自社の業務をどこまで理解してくれるか」を判断軸に加えてみてください。最初の相談では、実際の構築物と進め方を画面でお見せできます。まずは無料相談で、自社の最初の1アプリをどこにするか整理するところから始められます。

8. まとめ

不動産管理のアプリは、変わりにくいマスタ（物件・オーナー・入居者・業者）と、そのつど増える取引（契約・発注・請求・問い合わせ）に分けると整理できます。ルックアップで選び、関連レコード一覧で履歴をたどる。契約の進捗はプロセス管理と契約ステータスの二段構えにし、更新期限はリマインダーの条件通知で知らせる。この基本があれば、物件・契約・発注・請求・問い合わせを1か所から追える状態を作れます。

帳票出力、会計連携、地図表示のように標準機能だけでは足りない部分は、最初から抱え込まずに線引きしておきます。最初の1アプリは、いま最も担当者の頭の中に偏っている情報、多くの場合は物件マスタと契約管理から選んでください。