Strategic Advisory

「AIが店舗を回す」視点の追加論点 KIWAMI SAUNA の55課題リストに抜けている14の構造論点

作成者
高木 幹太
作成日
2026-04-23
対象
多店舗展開フェーズ
論点数
14論点 / 7カテゴリ

Why This Matters

現在の55件の業務課題リストは「現在の痛みをAIで解消する」発想で構成されている。 しかし多店舗展開を本気で見据えるなら、視点を1段上げる必要がある。

「AIが店舗を回した結果、何が起きるか」を先回りして設計しなければ、 個別課題を解決するほど新しい痛みが生まれる。 本資料は、この視点で不足している14の構造論点を提示する。

14論点 — 現状ステータス

0
○ 体系設計済み
7
△ 部分的な萌芽あり
7
× 完全未着手

31_KIWAMI AI 配下を横断チェックした結果、14論点のうち7論点は既に部分的な萌芽（既存記述・設定値）が存在していた。 各論点カードに「現状の萌芽」欄を設け、既存の該当箇所を引用して示す。 完全にゼロから設計すべきは7論点のみ。

A

AIガバナンス・権限設計

GOVERNANCE / AUTHORITY / AUDITABILITY

01
AIエージェントの決裁権限レベル（Lv0〜Lv3の段階的自律）
△ 部分萌芽あり
PROBLEM

現状の課題は全て「AIが提案・人間が決定」を前提にしている。しかし店舗オペを本当に回すには、AIが単独で決められる範囲を明文化する必要がある。

現状の萌芽（既存記載）
  • 07_設定/kiwami-config.json: expense_approval_threshold_yen: 500000、advertising_approval_threshold_yen: 100000 など複数の金額閾値が定義済
  • 20_PJT/P07_給与振込自動化/README.md: 「振込承認フロー（シングル承認 vs ダブル承認）」が意思決定事項として記載
  • 20_PJT/P27_備品需要予測発注自動化/README.md: 「自動発注の承認フロー（無承認 vs 店長承認 vs 中島代表承認）」
  • 10_打ち合わせ/2026-04-21_*/03_議事録.md #29: 「予約変更・クレームはAI応答停止」の人間エスカレ閾値
DESIGN（体系化の方向）
Lv0: 情報提示のみ（現状の多くがここ） Lv1: AIが判断 → 人間が承認 → 実行 Lv2: AIが判断 → 即実行 → 人間が事後確認 Lv3: AIが判断・実行 → 異常時のみ人間エスカレ
必要な作業: 個別PJT単位で分散している閾値・承認フローを、組織共通の決裁Lv表として一枚に束ねる。ゼロから設計する要素は少なく、既存の金額閾値・承認ルールを横断的に整理する作業が中心。
02
AI判断の監査ログ・可逆性
× 完全未着手
PROBLEM

AIが1日に数百件の判断をする状態で、後から「なぜこの発注が出た」「なぜこのシフトになった」を追えないと、店長の統制不能感と責任所在の曖昧化が発生する。

現状の萌芽（既存記載）

なし。ai_decisions テーブル・取消UI・判断履歴について、ドキュメント上もコード上も言及ゼロ。

DESIGN
  • D1に ai_decisions テーブル: agent_name / input_snapshot / decision / confidence / executed_at / reviewer / reversed_at
  • 「AIの判断を取り消す」ボタンをLIFF管理画面に常設
  • 週次レポートに「AI判断件数 / 人間介入率 / 取り消し率」を追加
03
AI間の矛盾調停メカニズム
× 完全未着手
PROBLEM

/sauna-bucho-finance（コスト削減） × /sauna-bucho-facility（設備投資必要）が 矛盾した提案を出したとき、誰が裁くか未定義。6部長AI + 店長AIの構成は積み木になっているが、 優先順位のヒエラルキーと調停ロジックが不在。

現状の萌芽（既存記載）

なし。AGENTS.md は読み書き権限の分離のみで、AI間の判断衝突解決ルールは記載なし。

DESIGN
  • AI間の優先ルール: 安全 > 法令 > 顧客体験 > 収益 > 効率 のような明文化
  • /sauna-tencho が調停ロールを担う責任を持つ（現状は報告統括のみ）
  • 矛盾検知時は必ず人間（代表）にエスカレーション
B

人間⇔AIのインピーダンスマッチング

HUMAN-AI INTERFACE DESIGN

04
通知疲れ・指示過多への対策
× 完全未着手
PROBLEM

AI部長6人 + 店長AI + シフトAI + 発注AI... が全員スタッフにLINE pushすると、 スタッフ1人が1日10〜20通知を受ける状態になりかねない。 合意済みのLINEリッチメニュー6項目は入力統合だが、出力統合（通知統合）は未設計。

現状の萌芽（既存記載）

なし。「通知上限」「ダイジェスト」「スタッフ通知集約」に関する設計はゼロ。

DESIGN
  • スタッフ個人ダッシュボード: 「今日あなたに来た指示 N件」を1画面に集約
  • 通知優先度: 🔴即対応 / 🟠本日中 / 🟢週内 / ⚪参考
  • 通知上限: 1日の自動通知を5件までに制限、超過分はダイジェストへ
05
スタッフからの"反論・訂正"経路
× 完全未着手
PROBLEM

AIの指示が現場実態と合わないとき、スタッフが「違う」と言える経路がない。 #45 適切な負荷設計と表裏一体だが、AI指示への異議申し立てフローとして独立して設計すべき。

現状の萌芽（既存記載）

なし。「反論」「異議申し立て」「AI指示おかしい」といったフィードバックループの運用ルール・データパイプラインは記載なし。

DESIGN
  • LIFFに「この指示おかしい」ボタン → 店長通知 + AI学習ログに蓄積
  • 月次で「異議申し立てランキングTOP10」をAI改善の優先リストに
  • 現状の #23/#24/#25 は「指示→完了」の一方向、双方向フィードバックが欠けている
06
AI指示の"割込み優先度"管理
△ 部分萌芽あり
PROBLEM

「トイレで水漏れ」という緊急事態の最中に「タオルの発注提案です」が来るような不釣り合いが発生する。 AIタスクキューの優先度スケジューラが未設計。

現状の萌芽（既存記載）
  • 07_設定/kiwami-config.json: safety_critical_max: 1（S級安全関係）など緊急度別の数値定義あり
  • 20_PJT/P36_自動化の推進/README.md: 「優先順位判定軸（ROI・緊急度・戦略性）」が記載
DESIGN（体系化の方向）
  • 緊急（Lv1）: 即割込み、全他タスク中断提案
  • 重要（Lv2）: 現タスク完了後に提示
  • 通常（Lv3）: アイドル時にまとめて提示
  • 論点04（通知統合）と同じ基盤で運用
必要な作業: 既存の優先度軸を、実装レベルのタスクキュー / スケジューラに落とし込む。
C

データ品質・鮮度の経営指標化

DATA QUALITY AS MANAGEMENT METRIC

07
データ鮮度SLA
△ 部分萌芽あり
PROBLEM

「AirMate CSV手動DL」「光熱費スクショ月次」など、AIを動かすデータが人間の手作業に依存している。 データが1日遅れれば、AI判断も1日遅れる。現状これが経営KPIとして可視化されていない。

現状の萌芽（既存記載）
  • CLAUDE.md データソース表: 「頻度」列で「日次」「月次」「随時」が記載済
  • 08_変換スクリプト/sync-all.sh: 各データ整流化スクリプトの実行頻度は明記

ただし「24時間以内」「2時間以内」などのSLA的な許容遅延時間、および遅延時アラートは未定義。

DESIGN（体系化の方向）
  • 各データソースに鮮度SLAを定義: AirMate: 日次 (24h以内) / 光熱費: 月次 (翌月5日)
  • ダッシュボードに「データ遅延アラート」を常設
  • SLA違反が3日続いたら代表にエスカレ
必要な作業: 既存の頻度定義に「許容遅延時間」と「超過時アラート」を上乗せ。
08
マスタデータ品質オーナーの不在
× 完全未着手
PROBLEM

#31 生年月日99.95%空欄 / #3 AirMate商品タグ未付与 / #11 備品マスタにグレード列なし — これらはマスタデータの品質劣化が根本原因。 しかし「マスタ品質オーナー」がKIWAMI側・AI経営側どちらにいるか未定義。

現状の萌芽（既存記載）

なし。マスタオーナー・データオーナーの明示的な設定、欠損率モニタリング、品質責任者の定義は見当たらず。CLAUDE.mdの「マスターデータ」セクションは構造説明のみで品質管理ルールなし。

DESIGN
  • 各マスタにデータオーナーを割り当てる（会員マスタ=中島代表、備品マスタ=店長、etc）
  • 月次でマスタ品質レポート（欠損率・更新日・整合性チェック）を自動生成
  • 品質が閾値を切ったら該当オーナーに通知
D

体験品質の定量指標（"きわまる"のKPI化）

BRAND EXPERIENCE AS KPI

09
"コミュニケーションサウナ"の定量指標
△ 部分萌芽あり
PROBLEM

KIWAMIの差別化ポイント = 「自然な会話やつながりが生まれる場」。 しかしこの体験品質を測る指標がない。客単価・リピート率だけだと、 AIは「単価最大化」方向に最適化してしまい、ブランド毀損につながる。

現状の萌芽（既存記載）
  • 07_設定/kiwami-config.json: review_score（口コミ平均評価） / repeat_visit_rate_pct（リピート率） / review_response_rate_pct（口コミ返信率） など顧客体験関連KPIが定義済
  • 11_検討中事項.md §8「未来構想」: 「常連サウナー同士のマッチング」「最上位ランク特別会」など体験設計のアイデアあり

ただし「会話発生率」「常連認知率」など、コミュニケーションサウナ固有の独自指標は未定義。

DESIGN — 独自KPIの定義案
  • 会話発生率: 接客1回あたり雑談が発生した割合（スタッフ自己申告）
  • 常連認知率: 常連顧客に「おかえりなさい」的声かけができた割合（#33 声かけヒントの実行率）
  • 滞在時間平均: ととのい→会話→再入浴のサイクル回数
  • 再訪意向スコア: 退店時1問アンケート
必要な作業: 既存KPIに「きわまる固有4指標」を追加し、AI最適化の指針に組み込む。
10
体験×収益のトレードオフ判定ルール
× 完全未着手
PROBLEM

例: 混雑時にAIが「料金上げれば利益最大化」と提案したとき、 体験品質を犠牲にしていいラインが決まっていない。 #19 動的価格シミュレーションは収益側の視点のみ。

現状の萌芽（既存記載）

なし。「体験毀損防止」と「収益最大化」の衝突時の判断ルール、最適化閾値の明示的な定義は見当たらず。

DESIGN
  • 「体験指標を○%下げてまで収益を取りにいかない」閾値ルール
  • AI判断の副作用として体験KPIへの影響を必ず試算
  • 代表の経営判断軸（00_経営憲章.md 由来）をAIプロンプトに埋め込む
E

多店舗展開の設計

MULTI-STORE SCALABILITY

11
店舗間比較・ベンチマーク・横展開
△ 部分萌芽あり
PROBLEM

多店舗展開が主眼なのに、店舗間のベストプラクティス自動発見の仕組みがない。 大須で成功した施策を本店に展開する経路が人力。新店舗が増えるほど管理不能になる。

現状の萌芽（既存記載）
  • CLAUDE.md 店舗情報: 本店・大須の営業時間・月間営業時間が分離管理
  • 20_PJT/P36_自動化の推進/README.md: 「複数店舗展開対応」が目的として記載
  • 11_検討中事項.md §6「交差点の示唆」: 店舗間の業務差分と共通化の考察あり

ただし「ベンチマーク自動抽出」「劣化アラート」「ベストプラクティス横展開」の具体的な仕組みは未設計。

DESIGN（体系化の方向）
  • 週次「店舗間ベンチマークレポート」: 全店KPIを横並びで自動比較
  • ベストプラクティス抽出: 特定KPIで突出した店舗の施策を自動ハイライト
  • 劣化アラート: 同業態店舗の中で特定指標が下位◯%に落ちたら警告
12
店舗固有差分と全店共通の管理レイヤー
△ 部分萌芽あり
PROBLEM

マニュアルは target_store: both/osu/honten で対応しているが、 備品・シフト・価格・発注ルールなどの店舗固有パラメータを一元管理する設計がない。 新店舗が増えるとカラム追加のハードコードになる。

現状の萌芽（既存記載）
  • 20_PJT/P27_備品需要予測発注自動化/README.md: 「全店共通の備品を定義 → 店舗固有の備品や発注ラインは別途設定」が明記
  • 07_設定/kiwami-config.json: 「stores」セクションで honten / osu の個別パラメータ化を開始
  • CLAUDE.md マニュアルCMS: target_store: both / osu / honten で記事の適用範囲を分岐

ただし継承モデル全体の設計は未完成。新店舗追加時のenum拡張がハードコードになる。

DESIGN（体系化の方向）
  • store_config テーブル: 店舗ごとの設定値を可変パラメータ化
  • 全店共通ルール（AI判定ベース） vs 店舗固有オーバーライド の継承モデル
  • CLAUDE.md の「ハードコード禁止」原則を店舗差分にも適用
F

縮退運用・BCP

BUSINESS CONTINUITY PLANNING

13
AI停止時・データ断絶時のフォールバック運用
× 完全未着手
PROBLEM

Cloudflare障害・ネット断・API停止・トークン上限到達などで AIが動かなくなった時、店舗は回るのかが検証されていない。 AI依存度が上がるほどこのリスクは大きくなる。

現状の萌芽（既存記載）

なし。「AI停止」「BCP」「ヘルスチェック」「トークン上限アラート」「縮退モード」に関する明示的な実装・運用ルールはゼロ。

DESIGN
  • "AIなし最小運用プロトコル" を紙ベースで用意（開閉店手順・緊急連絡先・手書きタスク表）
  • AI稼働状況のヘルスチェックダッシュボード
  • API/トークン予算の上限アラート（月額上限の80%到達で警告）
  • 各AI機能に「縮退モード」フラグ: 完全AI → 提案のみ → 停止
G

顧客×AI接点の設計

CUSTOMER CONSENT & PRIVACY

14
顧客がAIに触れることの合意形成プロセス
△ 部分萌芽あり
PROBLEM

#12 Webカメラ（保留中）以外にも、#31 誕生日LINE配信 / #33 声かけヒント / #14 離反予兆アラート など、顧客データをAIが処理する場面が増える。プライバシーポリシー・利用規約のアップデートが追いついていない。

現状の萌芽（既存記載）
  • 10_打ち合わせ/2026-04-21_*/03_議事録.md [01:04:44]: 「AI情報漏洩対策」で「多くの利用者はAI活用規約に同意しているが内容を十分理解していない可能性」と言及。「AIに顧客情報直接入力不可」ルール記載
  • AGENTS.md マスキング運用: 顧客データ（会員マスター・取引ログ）のD案マスキング方針を記載

ただし利用規約への「AI活用条項」の組込や、顧客同意取得フローは未整備。

DESIGN（体系化の方向）
  • Mini App利用規約に「AI活用条項」を追加（生年月日取得のタイミングで同時対応可）
  • 会員ランクごとのデータ利用同意レベル
  • 「AIによる提案」とスタッフに明示表示するUI設計（顧客から聞かれたとき誤魔化さない）

※優先順位マップ

14論点を、「体系化するだけ（△）」と「ゼロから設計（×）」を区別しつつ優先度別に整理。

優先度論点ステータス論点アプローチ
最優先 / 今すぐ △ ① 権限Lv定義 / ⑨ 体験KPI 既存の部品（金額閾値・review_score系KPI）を束ねて体系化。ゼロから作る要素は少ない
最優先 / 今すぐ × ⑬ BCP ゼロから設計が必要。AI展開が加速する前に最低限のフォールバック策定
高 / GW明け〜 △ ⑦ データSLA / ⑫ 店舗差分管理 既存の頻度定義・stores設定に拡張を加える形で整備可能
高 / GW明け〜 × ⑧ マスタ品質オーナー ゼロから「誰が何の責任を持つか」のアサインメント定義が必要
中 / Phase 3-4 × ② 監査ログ / ④ 通知統合 / ⑤ 反論経路 AI稼働量が増えた段階で顕在化。ゼロから設計
中 / Phase 3-4 △ ⑪ ベンチマーク 既存の店舗別データを使って自動比較レポート化
低 / 運用定着後 △ ⑥ 割込み優先度 / ⑭ 顧客合意 既存の緊急度軸・マスキング方針を体系化
低 / 運用定着後 × ③ AI間調停 / ⑩ トレードオフ 具体的な矛盾事例が出てからゼロから設計で可

まとめ — 発想の転換案

現在の55件リストは「AIで人の仕事を減らす」発想。 本当に多店舗展開を支えるには、以下の3つに視点を上げる必要がある。

  1. AIを経営メンバーとして扱う — 権限・責任・調停・監査・縮退運用の設計
  2. "きわまる体験"を定量指標化する — AIの最適化の指針を明示
  3. データを経営資産として管理する — 鮮度SLA・マスタ品質オーナー・店舗差分管理
14論点のうち7論点は既に萌芽が存在し、完全にゼロから設計すべきは7論点のみ。 特に最優先3論点のうち①権限Lv・⑨体験KPIは既存部品の体系化で済むため、 実は「⑬ BCPをゼロから設計する」だけが本当の意味で新規着手対象。残りは既存資産の整理・明文化で前進できる。 4/21ヒアリングの「パート5ブランド」で体験KPI定義を議題に入れ、5月研修内で権限Lv表を合意する流れが現実的。