本プロジェクトで使用する用語の定義です。実装の詳細は含めず、用語の意味・用例・関連のみを記載します。
本サービスのブランド名（製品名）。不動産業界向けに提供する、AIによる 画像生成（ホームステージング等）を中核としたWEBサービスを指す。 エンドユーザー向けの通知メール等、対外的な表記では「スマピタ」を用いる（例：問合せ通知メールの件名「スマピタお問合せ通知」）。 運営会社は株式会社空間Lab（公開サイトのヘッダー表記・プライバシーポリシーの事業者名）。「スマピタ」はあくまで本サービスのブランド名で、会社名とは区別される。
用例
開発者：「お客様向けの文言ではサービス名をどう表記しますか？」
ドメインエキスパート：「ブランド名の『スマピタ』を使ってください。メール件名や問合せ画面など対外的な箇所はすべて『スマピタ』表記です。」
スマピタの提供形態を表す方針。
サービスの詳細情報は紹介者を通じて個別に案内し、
公開ページ上では必要最低限の情報のみを掲載する（限定公開）。
新規の申し込み・相談も紹介者経由を起点とする。
この方針を対外的に告知するのが公開サイトの
/service ページ。
用例
開発者：「公開ページにはサービスの詳細をどこまで載せますか？」
ドメインエキスパート：「スマピタは完全紹介制です。公開ページには必要最低限だけにして、詳細は紹介者経由で個別にご案内します。」
システム管理者が、本サービスを利用する全組織・全ユーザーに向けて発信する通知。 運営からのメンテナンス告知、機能追加のお知らせ、重要なご連絡などを伝えるために用いる。 特定の組織やユーザーに絞った配信は行わず、公開対象は常に全ユーザーである。
用例
開発者：「このお知らせは特定の組織だけに出せますか？」
ドメインエキスパート：「いいえ、お知らせは運営から全ユーザーへ一斉に出すものです。組織ごとの出し分けはありません。」
お知らせが受信側（ユーザー・組織管理者）に表示される状態、およびその期間を指す。 「公開開始日（publishedAt）」が現在時刻以前であり、かつ「公開終了日（expiredAt）」が未設定または未来である間、お知らせは公開状態となる。 公開開始日が未設定または未来のお知らせは「未公開」、公開終了日を過ぎたお知らせは「期限切れ」と呼ぶ。
用例
開発者：「公開終了日を設定しなかった場合はどうなりますか？」
ドメインエキスパート：「公開終了日が無ければ、そのお知らせは期限切れにならず、ずっと公開され続けます。」
あるユーザーが、特定のお知らせを読んだ状態。ユーザーとお知らせの組み合わせごとに記録される。 ユーザーがお知らせの詳細を表示した時点で、自動的に既読として記録される。
用例
開発者：「既読はボタンを押して付けるのですか？」
ドメインエキスパート：「いいえ、お知らせの詳細を開いた時点で既読になります。明示的な操作は不要です。」
あるユーザーが、公開中のお知らせをまだ読んでいない状態。 「既読の記録が存在しない公開中のお知らせ」が、そのユーザーにとっての未読お知らせとなる。 未読の件数や一覧は、受信側の各画面で「未読バッジ」「未読のお知らせリスト」「未読お知らせバー」などとして提示される。
用例
開発者：「期限切れのお知らせも未読として数えますか？」
ドメインエキスパート：「いいえ、未読はあくまで公開中のお知らせが対象です。期限切れのものは未読には含めません。」
ユーザー画面のヘッダー直下に表示される、未読お知らせを知らせるための横長の帯。
公開中で未読のお知らせを全件、上部に提示し、ユーザーが各画面のどこにいても未読に気づけるようにする。
各行をクリックするとお知らせ詳細へ遷移し、そこで既読となるとバーから消える。
PC表示（/h）・モバイル表示（/v）の両方に表示され、挙動は共通である。
用例
開発者：「未読お知らせバーはスマホ版にも出ますか？」
ドメインエキスパート：「はい、PC表示（/h）でもモバイル表示（/v）でも、ヘッダーの下に同じように出ます。」
組織単位で、特定機能の利用可否（ON/OFF）を切り替えるための設定。 システム管理者がシステム管理画面の組織詳細ページで切り替える。 ある機能を「使える組織」と「使えない組織」を分けたいときに用いる。 機能ごとにフラグが存在し、現時点では「3D間取り」「ユーザー管理」の2つがある。 フラグには、明示的にONにした組織だけが使えるオプトイン型（既定OFF）と、 明示的にOFFにした組織だけが使えなくなるオプトアウト型（既定ON）がある。
用例
開発者：「機能フラグは全ユーザー一律ですか？」
ドメインエキスパート：「いいえ、機能フラグは組織ごとに設定します。同じ機能でも、組織Aは使えて組織Bは使えない、という状態にできます。」
組織管理画面（organization-manager）において、組織管理者が自組織に所属するユーザー（メンバー）を
一覧・追加・編集・削除する機能。/users 配下の画面群を指す。
機能フラグ（isUserManagementAvailable）により組織単位でON/OFFでき、
既定はON（オプトアウト型）。OFFの組織では、ヘッダーの「ユーザー」ナビが消え、
/users 配下は利用不可画面となる。
なお、ここでの「ユーザー」は組織に所属するメンバー（人）を指し、組織そのもの（顧客）とは異なる概念である。
用例
開発者：「ユーザー管理をOFFにすると、その組織のユーザーは消えるのですか？」
ドメインエキスパート：「いいえ、ユーザーのデータは残ります。OFFにするのはあくまで管理画面の操作で、組織管理者がメンバーの追加・編集・削除をできなくなるだけです。」
組織がシステムに登録された日時。組織一覧の並べ替えにおける既定（デフォルト）のキーであり、 並び順が指定されていないときは「作成日時が新しい順」で並ぶ。 利用開始日時（有効化日時）とは別概念で、こちらは「いつレコードが作られたか」を表す。
用例
開発者：「組織一覧の初期表示は何順ですか？」
ドメインエキスパート：「組織作成日時が新しい順です。並べ替えを変えなければ、最近作られた組織が上に出ます。」
生成タイプごとに定められた、画像生成AIに関する システム管理者向けの設定。内訳は「生成プロンプト」（AIへ渡す共通の基本プロンプト＝従来「AIプロンプト設定」と呼んでいたもの）と、 モデル設定（使用する生成エンジンのモデル）からなる。 システム管理者がシステム管理画面で編集し、ユーザーが当該タイプの生成を行う際に、生成プロンプトはユーザー個別の入力（個別指示・参考画像など）と組み合わせてAIへ送られる。タイプごとに1つだけ存在する。 生成タイプ9種のうちAI設定を持つのは7種（家具消し・DIYリフォーム・居抜き・家具引越し・3D間取り・画像キレイ・外構）。 ホームステージングは例外でAI設定を持たず、スタイル／部屋タイプのマスタが持つ指示で生成する。 リフォームはペンディングのため対象外。 モデル設定を持つのは現状 3D間取り のみ（ChatGPT へ切替済みのため。他タイプは Gemini 固定でモデル選択UIを持たない）。
用例
開発者：「生成タイプごとのプロンプトやモデルはユーザーが選ぶのですか？」
ドメインエキスパート：「いいえ、AI設定としてシステム管理者が一括で設定します。生成プロンプトは全タイプ、モデルは今のところ3D間取りだけ選べます。ユーザーは生成時に個別の指示を足すだけです。ホームステージングだけはAI設定を使わず、スタイルや部屋タイプの設定で生成します。」
画像生成が1回行われるごとに記録される実行記録。 どの組織・どのユーザーが、どの生成タイプの生成を、いつ行ったかを表す。 組織ごとの生成数の SoT（Source of Truth／信頼できる唯一の情報源）であり、 画像生成数はこの生成ログを数えて求める。 用途は3つ：(1) 組織ごとの生成数の根拠、(2) 課金額計算の根拠（予定）、(3) ユーザーの生成履歴。 ユーザー画面では「履歴」、組織管理画面では年月別の集計として提示される。
用例
開発者：「組織の生成数は各生成タイプのテーブルを数えるのですか？」
ドメインエキスパート：「いいえ、生成ログが生成数の正（SoT）です。生成数はこのログを数えて出します。将来の課金額計算もこのログを根拠にします。」
ある組織がこれまでに行った画像生成の累計件数。 ホームステージング・リノベーション・装飾・外観・3D間取りなど、すべての生成種別を区別せず合算する。 集計対象は全期間（期間の絞り込みはしない）で、取り消された（削除された）生成は数に含めない。 組織ごとの利用ボリュームを表す指標として用い、組織一覧の並べ替えキーのひとつとなる。
用例
開発者：「画像生成数は今月分だけを数えるのですか？ また削除された生成も含めますか？」
ドメインエキスパート：「いいえ、画像生成数は全期間の累計です。種別は問わず合計し、削除されたものは含めません。」
/h・/v）
ユーザー画面（apps/user）が持つ2つの表示形態。
モバイル版（/v = vertical）は現場でスマートフォンから利用する縦長レイアウトで、本サービスの原点となる形態。
PC版（/h = horizontal）は後から要望に応じて追加された横長レイアウト。
両者は機能が完全には一致しない。生成タイプ（ホームステージング等）はモバイル版にのみ画面があり、
PC版には現在「画像キレイ」「お知らせ」などの一部機能のみが存在する。
モバイル版機能のPC版への移植は要望としては存在するが、優先度は低く意図的に未対応の状態である（不具合ではない）。
なお、ルート（/）はアクセス端末のUA判定で振り分けられ、モバイル端末は /v、PCは /h へリダイレクトされる。
用例
開発者：「ホームステージングがPC版（/h）に無いのは実装漏れですか？」
ドメインエキスパート：「いいえ、意図的です。モバイル版（/v）が先にあり、PC版（/h）は後から一部機能だけ追加しました。生成機能のPC移植は要望はありますが、今は優先度を下げています。」
生成タイプ「画像キレイ（Refinement）」だけが持つ、 一括処理したい複数の画像をまとめる束（フォルダ的な単位）。 例えば1つの物件の写真一式をひとつのグループにまとめ、グループ単位でまとめて画質補正（画像キレイ）を実行する。 他の生成タイプ（ホームステージング等）は1画像=1案件のフラットな構造で、グループの概念を持たない。 画像キレイがこのグループ構造を持つのは、同じ物件の多数の写真を一度に処理する運用に対応するためである。
用例
開発者：「画像キレイは1枚ずつ処理するのですか？」
ドメインエキスパート：「いいえ、グループに写真をまとめて投入し、グループ単位でまとめてキレイにします。1物件の写真一式を1グループにする使い方が基本です。」
本サービスの中核となる、入力画像とAIへの指示をもとに新しい画像を生成する一連の機能の総称。 ユーザーは物件の写真などを入力画像としてアップロードし、生成タイプを選んで生成を行う。 生成の種類（ホームステージング・画像キレイ・家具消し など）はすべてこの「画像生成」に属し、 いずれも「入力画像 → AIによる加工・生成 → 出力画像」という共通の流れを持つ。 個々の生成の実行記録は画像生成数として集計される。
用例
開発者：「『生成』というのは、どの機能のことを指していますか？」
ドメインエキスパート：「ホームステージングや画像キレイなど、入力画像からAIで画像を作る機能はすべて『画像生成』です。種類はいくつもありますが、やっていることは共通です。」
画像生成で、出力画像が得られなかった状態。
3D間取りでは2系統に分かれる。
ひとつはソフト失敗＝生成エンジン（ChatGPT）が画像を返さなかったケースで、
generationError にエラー文言を保存して終端化（再生成しない）し、
一般ユーザーには失敗を見せず入力画像を結果として表示する（エラー文言はシステム管理者のみ閲覧）。
もうひとつはハード失敗＝アップロードや通信などで例外が発生したケースで、こちらは終端化せず一定時間後に自動再試行される。
いずれの失敗でも生成ログは作らないため、画像生成数には数えない。
用例
開発者：「生成に失敗したとき、ユーザーにはどう見せますか？」
ドメインエキスパート：「失敗は一般ユーザーには見せません。入力画像をそのまま結果として出し、エラーの中身はシステム管理者だけが見られればよいです。失敗した生成は数にも数えません。」
画像生成で実際に画像を生成するAIモデル。
多くの生成タイプは Google Gemini（@google/genai）を使用するが、
3D間取りのみ ChatGPT（OpenAI）へ切り替え済み
（Responses API。使用モデルは AI設定 で選択可能：ChatGPTモデル gpt-5.4 / gpt-5.4-mini / gpt-5.4-nano ＋ 画像モデル image_generation ツール gpt-image-2）。
生成タイプごとのAI設定
（ホームステージングはマスタの指示）をエンジンに渡し、出力画像を得る。
生成に使った指示は instructions（kind で gemini / chatgpt を区別）として保存される。
用例
開発者：「画像生成は何のAIで動いていますか？」
ドメインエキスパート：「基本は Gemini ですが、3D間取りだけ ChatGPT に切り替えています。」
一部の生成タイプで、生成時の指示としてあらかじめ用意された選択肢データ。 代表はスタイル（Style／内装テイスト）と部屋タイプ（RoomKind）。 ホームステージングはAI設定（共通プロンプト）を持たず、 これらマスタの指示で生成エンジンへ渡す点が他タイプと異なる。 マスタ管理は2階層：システム管理者が共通のスタイル・部屋タイプを管理し、組織管理者は自組織独自のスタイルのみを管理する（部屋タイプは組織側では持たない）。 3D間取りも専用のスタイル（SolidFloorPlanStyle）を持つ。
用例
開発者：「ホームステージングの指示はどこで決まりますか？」
ドメインエキスパート：「スタイルと部屋タイプのマスタで決まります。共通分は運営が、各社独自のスタイルは組織側で登録します。」
画像生成の種類。現時点で9種類あり、 それぞれ目的・入力・AIへの指示が異なる。各タイプには社内の実装名（英語）とは別に、 サービス上の正式な表示名（日本語）があり、両者は必ずしも直感的に一致しない点に注意する。 以下が正式な対応である。
| 表示名（正式・日本語） | 実装名（英語） | 概要 |
|---|---|---|
| ホームステージング | Homestaging | 空室に家具・装飾を配置した状態を生成する |
| 画像キレイ | Refinement | 画像を補正・高品質化する（唯一グループを持つ） |
| 家具消し | Cleaning | 室内の家具・物を消去して空室状態を生成する |
| DIYリフォーム | Decorating | 内装の装飾・仕上げを変更する |
| 居抜き | Furnishing | 什器・設備が残った状態を生成する |
| 家具引越し | Replacement | 既存の家具を別の家具に置き換える |
| リフォーム ペンディング | Renovation | 内装をリフォームした状態を生成する。生成品質が不十分なためシステム未組み込み（モデルのみ存在） |
| 外構 ペンディング | Exterior | 建物外観・外構を生成する。生成品質が不十分なためシステム未組み込み（ユーザー画面に画面実装は存在するが、ホームメニューに導線が無く到達不可） |
| 3D間取り | SolidFloorPlan | 間取り図から立体的な間取りを生成する |
※ 概要欄は実装からの暫定整理。各タイプの正確な定義は機能ドキュメント作成時に確定する。
用例
開発者：「コードに Cleaning とありますが、これは清掃機能ですか？」
ドメインエキスパート：「いいえ、Cleaning はサービス上は『家具消し』です。実装名と表示名が違うので、画面やお客様への説明では必ず『家具消し』と呼んでください。」
組織に割り当てる料金プラン。月額（monthlyCharge）と、月あたりに利用できる 生成数区分ごとの上限・超過課金を定める。 システム管理者がシステム管理画面で作成・編集し、各組織に割り当てる（組織は最大1プラン。未割当もあり得る）。 なお、生成数に基づく実際の課金（請求）の実行は現時点では未実装で、プランは「定義」として存在する段階である。
用例
開発者：「契約プランは組織ごとに複数持てますか？」
ドメインエキスパート：「いいえ、組織に割り当てる契約プランは1つです。プランで月額と生成数の上限・超過課金が決まります。」
組織1つ・年月1つにつき1件持つ、月別の課金記録。 契約プランに基づく自動計算値（プラン内容のスナップショットと、 画像生成数の実測）を保持しつつ、初月の日割りなど例外時には手動入力で上書きできる（手動値が空のときは自動計算値を使用）。 プランが後から変わってもレコードは凍結された値を持ち続ける（履歴性）。 超過分は前月の生成実績に対する後払いで、M月のレコードは「M月分の月額」と「M-1月分の超過課金」を合算する。
用例
開発者：「3月の課金履歴に出ている超過分は、3月の生成数で計算するんですか？」
ドメインエキスパート：「いえ、超過は後払いです。3月の課金履歴は、月額が3月分、超過分が2月の生成実績に対するものです。」
GMOペイメントゲートウェイが提供するマルチペイメントサービス。本サービスのクレジットカード登録・3Dセキュア認証に用いる。 決済上の会員＝組織として扱う。 現状はカード登録（＋3Dセキュア）までの実装で、契約プランに基づく 月額・超過分の課金実行は未実装。
用例
開発者：「カード情報はどこで扱っていますか？」
ドメインエキスパート：「Mulpay（GMO）に登録します。会員は組織単位です。実際の請求処理はまだ入れていません。」
契約プランにおける画像生成数の数え方の区分。 区分2は「画像キレイ（Refinement）」専用、区分3は「3D間取り（SolidFloorPlan）」専用、 区分1はそれ以外の生成タイプ（画像キレイ・3D間取りを除く）を指す。 区分ごとに「月間生成数の上限（quota）」と「上限超過分の課金額（extra charge）」が別々に設定される。 画像キレイと3D間取りがそれぞれ別枠で扱われる。
用例
開発者：「生成数の上限は全タイプ合算ですか？」
ドメインエキスパート：「いいえ、区分が3つあります。画像キレイは区分2、3D間取りは区分3、それ以外は区分1で、それぞれ別に上限と超過課金を持ちます。」
組織がサービスを利用できる期間を表す。有効化日時（activatedAt）＝利用開始日、 無効化日時（deactivatedAt）＝利用終了日で、システム管理者が組織の作成・編集時に設定する。 有効化日時が未設定の組織、または無効化日時を過ぎた組織は利用不可となり、組織管理画面では無効化アラートが表示される。
用例
開発者：「無効化日時を設定しないとどうなりますか？」
ドメインエキスパート：「無効化日時が無ければ期限なしで使い続けられます。有効化日時が来ていれば利用可能、無効化日時を過ぎると利用できなくなります。」
組織がサービスの利用を終了すること。システムでは 無効化日時（deactivatedAt） が設定されることを解約とみなす。解約した組織は 無効化日時 を過ぎるとサービスを利用できなくなる。
用例
開発者：「解約数とはどうやって数えますか？」
ドメインエキスパート：「無効化日時（deactivatedAt）がその月に設定された組織の数が解約数です。一時停止と恒久的な解約を区別するフィールドは現状ありません。」
組織ごとに用意される、エンドユーザー（物件のお客様など）向けの公開ページ。公開画面（apps/www）の
/lp/[landingPageId] で表示され、ロゴ・住所・電話番号などの組織情報と、
問合せフォームを持つ。
LP はシステム管理者が組織ごとに作成し、組織管理者およびシステム管理者が内容（ロゴ・連絡先・通知先メール）を編集する。
用例
開発者：「LPは組織が自分で作るのですか？」
ドメインエキスパート：「LPの枠は運営（システム管理者）が組織ごとに用意します。組織側はロゴや連絡先、問合せの通知先メールなどを編集します。」
エンドユーザーがランディングページのフォームから送信する問い合わせ。
お名前・メールアドレス・ご希望の内容に加え、アクセスメタデータ（流入元の referer と URL クエリパラメータ）を記録する。
電話番号（tel）はデータモデル上は保持できるが、現状の公開フォームには入力欄が無く常に空文字で保存される（軽微なブレ）。
問合せが送信されると、その LP に設定された通知先メールアドレス宛にメール通知が送られる。
受け取った問合せは組織管理者が組織管理画面で一覧・確認する。
用例
開発者：「問合せが来たら誰に通知されますか？」
ドメインエキスパート：「そのLPに設定した通知先メールアドレスへメールが飛びます。内容は組織管理画面の問合せ一覧でも確認できます。」
生成した画像を集めて共有用のイメージギャラリーとして束ねたもの。名前・カテゴリ・住所・備考を持ち、
各生成タイプの生成結果を項目（イメージギャラリー項目 / TrackingItem）として複数登録する。
公開URL（/t/[trackingId]）でエンドユーザー（お客様）に共有でき、
閲覧されるとURL追跡ログとしてアクセスが記録される。
ユーザー（営業担当）が物件ごとに生成画像をまとめて見せ、相手が見たかどうかを把握するための仕組み。
エンドユーザー向けの表示名は「URL追跡」、社内・コード上の名称は「トラッキング（Tracking / @namespace トラッキング）」。
用例
開発者：「URL追跡というのは何を束ねるものですか？」
ドメインエキスパート：「お客様に見せたい生成画像を一つのギャラリーにまとめたものです。共有リンクを送って、相手が見てくれたかをログで確認します。」
共有されたURL追跡の公開ページが閲覧されたときに記録されるアクセスログ。 IPアドレスとユーザーエージェントを記録する。これにより、共有相手がギャラリーを見たかどうか・いつ見たかを把握できる。 ログはユーザー画面（URL追跡ごとのログ画面）や組織管理画面で確認できる。
用例
開発者：「閲覧されたことはどう分かるのですか？」
ドメインエキスパート：「共有ページが開かれるとURL追跡ログが残ります。IPやブラウザ情報が記録されるので、見てもらえたか確認できます。」
本サービスを契約・利用する顧客の単位。契約プランの割当・ 有効化/無効化・機能フラグ・課金は すべて組織単位で管理される。組織には複数のユーザー（メンバー）が所属する。 「組織」は顧客（契約主体）であり、「ユーザー」は組織に所属する人である点を区別する。
用例
開発者：「契約や課金は『ユーザー』単位ですか？」
ドメインエキスパート：「いいえ、契約・課金・機能の可否はすべて組織単位です。ユーザーは組織に属する個々のメンバーです。」
組織に所属するメンバー（人）。メールアドレスとパスワードでログインする。 2つのフラグでロールが決まり、利用するアプリが分かれる。
isOrganizationManager）：組織管理画面で自組織のメンバー管理・問合せ確認・生成ログ閲覧などを行う。isSystemManager）：運営。システム管理画面で組織・プラン・AI設定などを管理する。用例
開発者：「『ユーザー』は管理画面にもログインできますか？」
ドメインエキスパート：「ロール次第です。一般ユーザーはユーザー画面、組織管理者は組織管理画面、システム管理者はシステム管理画面、と使う画面が分かれます。」
特定のユーザー・組織として
ログインし、その視点で動作確認するための仕組み。専用のサインイン経路
（/sign-in/debug/users/[userId]/organizations/[organizationId]）を用い、
作成されるセッションに一時組織ID（debugOrganizationId）を記録する。
用例
開発者：「特定の組織で起きている不具合を、その組織の見え方で確認したいのですが？」
ドメインエキスパート：「デバッグログインを使えば、そのユーザー・組織としてログインして同じ画面を確認できます。」
3D間取りに付ける名称
（SolidFloorPlan.name）。ユーザーが任意に編集でき、
空欄にすると表示上は作成日時（createdAt）が代わりに使われる。
UI 上の正式な呼称は「物件名」であり、実装初期にあった「部屋名」表記は誤り（部屋単位ではなく案件＝物件単位の名称）。
空欄保存時は内部的に null として保持する。
用例
開発者：「3D間取りの名前は『部屋名』でよいですか？」
ドメインエキスパート：「いいえ、物件名です。部屋単位ではなく物件（案件）に付ける名前で、空欄なら作成日時を表示します。」
3D間取りを一覧から隠す状態
（SolidFloorPlan.isUnlisted、既定 false）。
削除（論理削除）とは別概念で、レコードは残したまま一覧の既定表示から外すだけ。
とくに生成済み（生成開始後）は削除できないため、不要なものを片付ける手段として用いる。
詳細画面の「一覧に表示」スイッチで切り替え、一覧では非表示のものに EyeOff アイコンを表示する。
検索の「非表示を含める」をONにすると非表示分も一覧に含めて表示する。
用例
開発者：「もう使わない3D間取りを消したいのですが、生成済みだと削除できません。」
ドメインエキスパート：「生成済みは削除せず一覧非表示にしてください。一覧から消えますが、データは残ります。」