OWNER REPORT 202606

渋谷 6/27「重複」— 原因と是正カルテ

結論: ダブルブッキングではありません。6/5にキャンセル済みのAirbnb予約が宿泊状況一覧に残っていました。金額は「キャンセル料収入」として実在する公算が高く、誤っているのは泊数の方です。

要判断 2 件追認 3 件済 3 件
要判断は2件だけです（どちらも金銭・オーナー提出物なので推奨をプリセットしていません＝明示的にお答えください）。追認は私の側で決めた設計事項なので、違うものだけ触ってください。済は読むだけで結構です。

要判断2 件

Otakeさんにしか答えが無いものだけ。ここをお願いします。

Q1

渋谷6月を是正しますか。するならどの扱いで。要判断

オーナー提出物・支払額に影響

r12「Airbnb 6/27→6/29 99,450 / OTA 15,415 / 2泊」の正体は AirHost予約ID 22189264（Airbnb・ゲストDejuan）で、状態は「システムキャンセル」・キャンセル日 2026-06-05。6/27の夜に実在した宿泊は r11（YS会員・YS伊藤達哉・108,000）だけです。／ 金額99,450がキャンセル料収入として実在する根拠は4点: ①同施設の他のAirbnbキャンセル5件はすべて販売0（AirHostは全額返金を0にする）②99,450 = 198,900（同施設の実在2泊料金）のちょうど50% ③OTA手数料15,415 = 99,450の15.5%＝実際に受け取った金額にしかホスト手数料はかからない ④2025年11月にも同型（84,150 = 168,300の50%）が既提出レポートに計上済み。／ 泊数はどちらの案でも30泊・稼働率100.0%になり、分岐するのは売上だけです。

無回答なら 回答がなければ何も変更しません（Excel・PDF・Web・合本Excel すべて現状のまま）。

Q2

館山・九十九里で見つかった計上差異を、6月分に遡って直しますか。要判断RISK

館山・九十九里オーナーの支払額に影響

全8施設 × 同期DB の双方向突合で、渋谷以外に2件出ました。／ **館山**: 同期DB確認済みの Airbnb 6/20→6/21 168,000（ID 23145996・朝川香織）が宿泊状況一覧に無い。加えて r10「6/27→6/28 168,000」はDB上183,000（ID 22815994）、r7「6/13→6/14 261,000」はDB上228,000（ID 22891885）で不一致。／ **九十九里**: 同期DB確認済みの 一休 6/27→6/28 112,000（ID 22708594・清水千舟）が宿泊状況一覧に無い。また r3「一休 6/6→6/7 22,400」は渋谷と同型のキャンセル料計上で泊数1が稼働率に入っている。／ いずれも**オーナーへの支払額が変わる**ため、私の判断では動かしていません。

無回答なら 回答がなければ何も変更せず、事実の記録（handoff）だけ残します。

追認3 件

私が決めました。違うものだけ触ってください（無操作＝この通り進めます）。

A1

稼働率は「2つの定義が併存している」状態。Excel側をWeb側の定義に寄せます。追認

7月分以降に効く・既提出分は触らない

調査で前提が1つ覆りました。「京都は31で割っている」は誤りで、**Excelは全施設・全月とも /30 のベタ書き**でした（202604/05/06を実査）。京都5月の提出用xlsxの実値は 20.00%（6÷30）です。19.4%の出どころはExcelではなくWebのindicators（別パイプライン）でした。唯一の例外は館山で、202604・202605が /31、202606から /30 ＝ 手で書き換える運用になっており月長に追従していません。

今Excel（収支詳細）: チェックアウト月に全泊を計上・分母は /30 のベタ書き・上限なし → 渋谷6月 106.7%
実態Web（indicators）: 各泊を実際の宿泊月へ配分・分母は暦月の実日数・100%で頭打ち（scripts/owner_report/data.py:298）→ 同じ渋谷6月なら 80.0%（実夜24泊÷30日）
提案Excelの分母だけを実日数に追従させる（=DAY(EOMONTH(...))）。計上基準（チェックアウト月）は既存レポートとの連続性のため当面そのまま置き、オーナー向けには注記で補う

推奨 ① この線でいい（分母だけ実日数化・計上基準は据置） — ②は正しい姿ですが、過去12ヶ月の推移列が全部変わりオーナーへの説明コストが跳ねるので今月は見送り。③は館山の手書き分母が残り続けます。

無回答なら ①で進めます（7月分の月送りから適用・既提出分は触りません）。

A2

根本原因は「売上はあるが泊数はゼロ」を表現できないこと。宿泊状況一覧に区分を足します。追認

全施設のテンプレに効く

キャンセル料収入は実在するのに、宿泊状況一覧はIN/OUTから泊数を自動計算する（H=C-B）ため、金額を載せると必ず泊数もついてきます。これが6/27の見かけ上の重複の正体です。九十九里は D列(宿泊料金のみ)を空欄にし E列(オプション含)だけに入れる形で回避していますが、渋谷の様式には売上列が1本しかなく逃げ場がありません。

提案OTA/会員 列に「Airbnb（キャンセル料）」等の区分を設け、その行は泊数式を0にする（売上・OTA手数料は集計に入り、稼働率・ADRの分母には入らない）

推奨 ① この線でいい — ②は集計式が拾えないので同じ事故が再発します。③だと毎月どこかの施設で同じ重複が出ます（現に6月は渋谷・九十九里の2施設で発生）。

無回答なら ①で7月分の月送りテンプレに入れます。

A3

二度目を構造で止める。月次の突合チェックを owner-report-monthly に組み込みます。追認

毎月の月次業務に効く

今回の突合スクリプト（宿泊状況一覧 × 同期DB の双方向・ヘッダーラベルで列を特定するので施設ごとのレイアウト差に耐える）を、⑥提出用変換の前に必ず走る検証ステップにします。キャンセル済みの計上・計上漏れ・金額不一致の3種を月次で自動検出します。

推奨 ① この線でいい — ②は金額に自動で手を入れることになり、経理の入力意図（オプション売上・撮影ユース等）を潰す危険があるので検出＋申告に留めます。

無回答なら ①でスキル化します。

済3 件

実装・反映済みの事後報告。読むだけで大丈夫です。

✓1

7/9 MTGの「ダブルブッキング」議題は本件と無関係でした。済

Plaud議事録（file_id ab51a654…）を確認。議題は**南房総の7月19日**のダブルブッキングで、渋谷6月の件ではありませんでした。渋谷では物理的なダブルブッキングは起きていません。

推奨 ① 了解

✓2

調査結果を handoff に追記済み。Excel・PDF・Web・合本Excel はいずれも未変更です。済

tasks/handoff_owner_report_202606.md の現在層に「2026-07-28 追記2」として、原因・根拠4点・A案/B案の数値表・分母の実査結果・他施設の差異まで記録しました。『触るな区間』を尊重し、成果物は一切変更していません。

推奨 ① 了解

✎

その他・自由記述済

回答テキスト（自動生成・差分だけ出ます）

下の枠内で Ctrl+A → Ctrl+C でコピー
コピーしました