開発事例：反響灯の開発で考えたこと

不動産会社の「問い合わせが来てから、次に何をするか」が人の記憶に頼っている状態を、どう整理したか。反響灯の開発で考えたこと・決めたこと・まだ確かめていることを、事実に沿って紹介します。

項目	内容
事例の区分	開発事例（設計と開発の記録。業務での効果の測定はこれから）
対象の業務	賃貸仲介・賃貸管理・売買仲介の、問い合わせから契約準備までの流れ
想定した会社	情報システムの担当者がいない、少人数の不動産会社（設計の前提として、従業員3名・月の問い合わせ20件程度の運用を想定）
開発・運営	株式会社アイアール（当サイトの運営者。自社のサービスです）
材料	開発記録の原稿と、2026年9月の設計資料。確認日：2026年10月17日

1. 課題：困っていたのは「作業」より「作業の間」

問い合わせが来た。メールを確認した。担当者に伝えた。物件の状況を調べた。返信を書いた。そして翌日、「このお客様には、次に何をするんだっけ」と考える。一つひとつの作業は難しくなくても、仕事が別々の場所に置かれていると、作業と作業の間を人がつなぎ続けることになります。

受信メールはメールソフトに、問い合わせの一覧は表計算に、内見の予定はカレンダーに、次の連絡の予定は担当者の記憶に。どこか一つを見ても、案件の全体が分からない状態でした。

整理した4つの課題

1. 最初の対応が、担当者の状況に左右される（誰が、いつ確認するかがあいまい）
2. 文章や確認する項目が、担当者ごとに違う（聞き漏れが防げない）
3. 追客の予定が見えにくい（次にいつ連絡するか、なぜ保留か、担当者以外は分からない）
4. 少人数の会社ほど兼務が多い（一人が案件の経緯を全部覚えておくのは限界がある）

2. 何を改善することにしたか

返信文を自動で作るだけでは、仕事全体の問題は解決しません。最初の返信が速くなっても、そのあとの連絡予定が残らなければ、同じ不安が別の場面で出てくるからです。そこで、「記憶に頼る部分を減らし、次に必要な仕事が分かる状態をつくる」ことを目標にしました。

図の見方：AIで補助仕組みで管理人が判断

1. 受付どの問い合わせを、いつ受け取ったか。
   仕組みで管理
2. 担当の確定誰が次の対応をするか。
   仕組みで管理人が判断
3. 最初の対応何を確認して、どこまで案内したか。返信の下書きは用意しても、送る前の確認は人が行う。
   人が判断
4. 次の仕事内見・追加の確認・再連絡など、何をいつ行うか。
   仕組みで管理

3. 方法の選び方：既製のサービスか、自社で作るか

既製のサービスが悪いから作ったわけではありません。機能の数ではなく、「担当者が何回入力し、どの画面で迷い、トラブルのときに誰が直すか」を軸に比べました。

比べる軸	既製のサービスを見るとき	自社で作るとき
日々の操作	現場の仕事の順番と合うか	自社の流れに沿わせられるか
始めるときの準備	今のメールや物件情報をどう移すか	設計・設定・教育に何が必要か
変更への対応	設定で足りるか、個別の対応が必要か	変更の実装と確認を続けられるか
費用	初期・月額・追加作業を合わせる	開発・維持・障害対応を含める
責任	問い合わせ窓口と復旧の条件は明確か	誰が保守し、代わりの運用を決めるか

4. 設計で決めたこと

範囲を「問い合わせ管理」だけにしなかった

初回返信のあとにも、賃貸仲介なら内見・申込・契約準備、賃貸管理なら入退去や修繕、売買なら売主・買主の案件が続きます。入口だけを整えても、その先で情報が切れれば、再入力と再確認が増えます。そこで、案件が次の工程に渡るときに情報を途切れさせないことを重視しました。同時に、範囲を広げると画面や入力項目が増えるため、「同じ内容を二度入力させない」「内部の専門用語をそのまま画面に出さない」ことも原則にしました。

作らない機能を決めた

扱い	意味	例
対象にする	自社の機能として仕様・試験・運用手順を決める	問い合わせ、案件の進み具合、追客、必要書類のそろい具合の確認
対象にしない	この製品では提供しない	契約書・重要事項説明書の本文の作成、会計ソフトの代わり
ほかへ引き継ぐ	別の仕組みや専門家につなぐ	書類の確認のあと、担当者による作成・確認の工程へ進める

書類が「そろっているか」を確かめることと、書類の内容が「正しいか」を判断することは、別の仕事です。後者は人が行います。

お客様のデータは、お客様自身の環境に置く

初期の検討では、外部のサーバーで業務システムを動かす案もありました。その後、問い合わせや案件の情報は、利用する会社自身のGoogleの環境（メール・ドライブ・表計算など）に置き、運営側はお客様の個人情報を見ないという方針に見直しました。どちらの技術が優れているかではなく、「誰がどの情報を持つか」を先に決めた設計の変更です。

AIは開発に使うが、製品はAI前提にしない

仕様の整理やプログラムの作成の補助には、AIを使っています。一方で、製品の毎日の業務がAIサービスの契約がないと動かない設計にはしていません。毎日の業務を止める依存先を増やさないこと、判断の根拠を説明できるようにすること、お客様の情報を外部に自動で送らないことを優先しました。「AIを使って作った」ことと「AIが判断する仕組み」は別のものです。

「画面がある」ではなく「業務として使える」を完成の条件にした

状態	分かっていること	外に向けた書き方
設計	仕様や画面の設計がある	「設計している」
実装	プログラムがある	「実装した範囲がある」
検証	条件を決めて試験した記録がある	「この条件で確かめた」
提供	実際の環境で提供・運用した記録がある	「提供の状況と範囲を示す」

メールの送信が途中で途切れたとき、送れたのか分からない状態で自動的に送り直すと、お客様に同じメールが二通届くおそれがあります。こうした「うまくいかなかったとき」の動きも、通常の操作と同じ重さで確かめる対象にしました。

5. 人が確認する箇所

• 返信の内容（物件の状況、条件、日付）
• 契約書・重要事項説明書の内容と説明
• 費用の最終確認
• 想定していない例外の場面での判断

6. 結果と、まだ確かめていること

• Googleのサービスの利用上限（受信・通知・帳票が重なったとき）を、実際の件数で確かめること
• 二人が同時に同じ案件を更新したときに、記録が消えないか
• 障害のときに、お客様の個人情報を見ずに原因を切り分けられるか
• 説明書がなくても、迷わず操作できるか

7. この開発から、相談でお手伝いできること

反響灯を使うかどうかに関係なく、開発の中で整理した考え方は、自社の業務改善やシステム選びにそのまま使えます。

お手伝いできること	例
業務の流れを言葉にする	問い合わせから契約準備まで、どこで仕事が止まるかを書き出す
既製のサービスと自作を比べる	上の5つの軸で、自社に合う方法を判断する
作らない範囲を決める	要望を「対象にする・しない・引き継ぐ」に分ける
データの置き場所を決める	誰がどの情報を持つかを、導入の前に決める
AIの使い方の線を引く	AIに任せる作業と、人が判断する作業を分ける
完成の条件を決める	「使える」と言える確認の項目をつくる

自社で試せること

問い合わせを1件選び、「受付 → 担当の確定 → 最初の対応 → 次の仕事」の各段階で、必要な情報・操作の回数・例外・担当者・困ったときの戻し方を書き出してみてください。既製のサービスを試すときも、自社で作るときも、同じ表で比べられます。

AIへの指示文の例（コピーして、［ ］の中を書き換えて使えます）

次の業務の流れを、受付、担当の確定、最初の対応、次の仕事、の4段階に分けて表にしてください。
各段階で、必要な情報、作業の回数、起きやすい例外、担当者、困ったときの戻し方を整理してください。
書かれていないことは「未記入」としてください。

業務の流れ：［自社の問い合わせ対応の流れを、個人情報を含めずに書く］