# 外に出ている商品を AI が毎日「実機で見て・結果で判断して・止まったら気づく」運用の作り方 価格・在庫・求人・広告など、客に見えているものを自動で動かしている AI エージェントが「設定上は正しいのに客画面では売れない状態」を何週間も放置する事故を防ぐ型。宿泊施設の自動価格（PMS = Beds24、OTA = Airbnb / Booking.com）で実証したが、求人掲載や広告配信にもそのまま置き換えられる。 ## 起きた事故（なぜこの型が要るか） - 3 連休初日、近隣ホテルは安い部屋が売り切れていたのに、自社の一棟貸しだけ空室のまま高値表示。 - 原因は 3 つ重なっていた: (1) AI が 25 日前に決めた「床価格」を「2 週間で再判断」と書いたまま誰も見直さなかった、(2) 施設を 1 行で除外したコードが、値下げ経路まで止めていた、(3) 「毎日実機を見る」という指示が、会話内の検証ルールとしてだけ運用され、日次の自動点検になっていなかった。 - 教訓は 60 件以上「文章」で残っていたが、自動で検査されるものは 1 つも無かった。 ## 構成（3 つのジョブ ＋ 3 層の監視） ### ジョブ 1: 日次実機点検（1 日 2 回） 1. API で事実を集める: 今後 14 日の在庫・価格・最低泊数、予約（ページングを完走、到着日フィルタは窓の 45 日前から）。 2. **3 日以内に空室がある対象は、客側の画面をヘッドレスブラウザで開いてスクショと表示額を台帳に残す**（直販・各 OTA）。開けなかったら「未確認」と書き、成功扱いにしない。 3. 市場と比べる: 競合スキャンに加えて、Google の宿泊検索（またはマップ）で当日・翌日の価格帯別の残室数を数える。「市場が売り切れなのに自社だけ空き」は価格ではなく売り方（最低泊数・人数条件・露出）を疑う。 4. 決定台帳の監査: すべての決定に `successMetric`（何が何件になれば成功）と `reviewBy`（既定 = 決定日 + 14 日）を持たせ、期限切れ／決定後 14 日で成果ゼロ／読み戻し無し を「要見直し」として列挙する。 5. 安い LLM（Gemini / DeepSeek / Groq 等）に事実 JSON を渡し、原因を 4 分類（価格・露出・条件・需要）で仮説化し、期待効果順に打ち手 3 つを返させる。事実の行番号を引用しない提案と値上げ提案は捨てる。 6. チャット（Discord 等）に 1 通、台帳を 1 本。送信応答が 429 や null なら「到達」と書かない。 ### ジョブ 2: 目標レビュー（点検の直後） 固定目標（例: 全室稼働 95%）に対して、毎回次の 5 項目を出す。 1. 目標までの距離（対象別の不足量と金額） 2. 今日の最大の問題を 1 つ（事実の行番号つき） 3. 原因の仮説と「制限を外したら何をするか」（商品形態の変更・新チャネル・条件緩和まで含めて 5 つ以上） 4. 最短経路 3 つ（期待効果 = 埋まる量 × 単価 の大きい順。自動で動かせるものは即実行、承認が要るものは 1 タップ承認） 5. 昨日の打ち手の結果（前後比較で 強化 / 継続 / 停止） 「様子見」「維持」だけの出力は不採用にして再試行させる。 ### 監視 3 層（これが無いと「止まっていたことに気づけない」） 1. **PC の外からの心拍監視**: 各ジョブは開始・終了時にクラウド側（Google Apps Script のシートなど）へ心拍を送る。クラウド側の時間トリガーが締切時刻に心拍の欠落・失敗・古さを見て通知する。PC が落ちていても通知が出る。 2. **出力妥当性**: 「動いた」ではなく「正しい」を検査する。市場最安が自社単価の 3 倍超／未確認が半分超／打ち手 0 件／表示額が設定の 0.8〜3 倍の範囲外／直前帯で値下げが効いていない／最終新規予約から 14 日超、のどれかに当たれば failed にして通知する。 3. **過去事故のプローブ化**: 事故 1 件 = 検査スクリプト 1 本（例: 「施設除外が値下げ経路まで止めていないか」「最低泊数が 部屋・日別・料金ルール の 3 層で食い違っていないか」「配信中のコードが HEAD と一致しているか」）。毎日全部走らせ、`ok / NG / 未変換（事故総数に対して）` を通知に出す。**未変換の数を毎日減らすのが仕事**になる。 ## 実装のコツ - 最低泊数・価格のような制約は、PMS 内で複数層（部屋・日別カレンダー・料金ルール/チャネル）に存在する。API で 1 層を直して読み戻しが合っても、客画面が変わらなければ別の層を疑う。 - 「この対象はこのロジックの対象外」と書くときは、その除外が「下げる経路」まで止めていないことをテストで示す。 - 決定を保存する JSON には必ず `reviewBy` を入れ、期限切れを watchdog に出す。期限切れのまま放置された決定は「AI の不作為」として事故履歴に残す。 - 推論は安い LLM、設計と検証だけ高価なモデル。日次ジョブのログに呼び出し記録が残ることを「使っている」の定義にする。 ## 最小のファイル構成（Node.js の例） - `tools/daily-reality-check.mjs`（事実収集→実機読み戻し→市場比較→台帳監査→LLM→通知） - `tools/daily-goal-review.mjs`（5 項目の目標レビュー） - `tools/reality-validity.mjs`（妥当性 6 検査） - `tools/incident-probes/<事故名>.mjs` と `run.mjs`（集計と通知） - `tools/heartbeat.mjs` と クラウド側の `Heartbeat.gs`（heartbeat / getHeartbeats / checkHeartbeats / dailySummary） - `config/decisions.json`（current / decidedAt / rationale / successMetric / reviewBy / resultSinceDecision / history） - OS のタスクスケジューラに 09:30 / 18:30 と翌朝の watchdog を登録。失敗はクラウド側の心拍監視が拾う。 ---