環境総点検 — 研ぐところ、直すところ、伸ばすところ

① SlackQueue が6日連続で無言失敗中

scripts/slack_site_mgmt/check_queue.py の63行目が旧ホストDELLのユーザー名でclaude.cmdをハードコードしており、BLADEでは存在しないパスを叩いて毎日12時に空振り。Slack依頼2件が6日間滞留しています。修正はパスをホスト非依存の解決（which→APPDATA探索）に置き換える1箇所。

② 二度の事故対策フックが「未接続」

launch.json（53エントリ）をWriteで全消しする事故が8/8と8/11に二度起き、物理ゲート scripts/hooks/block_shared_registry_write.py が作られました。ところがsettings.jsonに未登録＝いま全く効いていません。さらにmemory側は「登録済み」と誤ったパスで記録しており、記録と実態が食い違ったまま。三度目が起きうる状態です。登録＋対の冪等レジストラ同梱＋memory訂正の3点セットで閉じます。

③ 「検知はするが、処置しない」層の欠落

①は週次ヘルスチェックが8/10に既にerrorとして検出済みでした。気づく層はあるのに、直す層が無い。ここは第5章（AI社員）で構造として解きます — Blackの週次に「summaryのerrorを読んで処置候補を研鑽キューへ積む」を1行足すだけで、検知→処置が繋がります。

④ 台帳の小さなズレ2件

退役宣言済みタスク（OpemiStock）の登録抹消が未実行／RepoSyncのBLADE行が旧スクリプト名。どちらも台帳と実機の突き合わせで即決着します。

すぐ効く小修理（迷いを生む記述の除去）

• 行き止まりリンク2件 — 存在しない skill-map・roundtable への誘導が4スキル6箇所に残存。読み手を行き止まりに送る記述なので削除・付け替え
• floor-plan 3世代並存 — 自ら「v1の遺産」と書いている旧版を _archived/ へ（退役日付きの良い前例が既にあります）
• AirHostログイン手順の4重記述 — booking-sync等4スキルが同じ自動ログインフローを各自書いている。正本AIRHOST_GUIDEへのポインタ1行に畳む（仕様変更時に4箇所直す現状はリスク）

統合候補（優先度順・実施は各担当社員の週次に載せる）

正本まわり

• 川久（kawakyu_auberge）に施設正本 facility.md が無い — 最も活発に動いている施設（成果物39ファイル）なのに正本ゼロ。ホーム決定ルールへの明確な違反状態。Frankの健診対象に入っていない＝食い違いも検出されない
• 完了済みhandoff 23件（約340KB）が現役棚に滞留 — 移動先の器（handoff_archive）は既にある。あわせてhandoff置き場が3ヶ所に分散しているのを tasks/ に一本化
• SoT設計思想の正本が2つ（SOT_DESIGN.md / SoT_Guideline.md）— 新しい方に一本化し、古い方は冒頭ポインタ化（ENVIRONMENT.mdが実践済みの型）
• 肥大メモリ上位5件（計266KB） — 最大81KBは索引の4倍。既にある「umbrella＋配下Tier2索引」の型で分割

増殖を止める仕組みも同時に: scripts直下には使い捨てスクリプトが177本堆積（create_*だけで112本）。ルール上の受け皿 scripts/tmp/ が存在しないことが原因なので、器を作り月次隔離をBlackの定例に載せる — 「ルールを書く」のではなく「受け皿を置く」が正解です。

乗る① スキルfrontmatterの読み込み制御 — コンテキスト税の削減

126本のスキル説明文は毎セッション読み込まれる「税」です。新しいfrontmatter制御で、定期実行専用スキル（booking-sync等）は自動起動対象から外し、施設限定スキルは対象パス編集時のみ読み込む形にできます。高頻度スキル10〜20本から監査開始が現実的。

乗る② Workflowツール — 棚卸し・健診系の多角化

今回の調査自体が実例ですが、「多方向から並列に調べて統合する」型の仕事（月次棚卸し・横断監査・一斉改稿）はワークフロー化すると1回の指示で回ります。Frankの健診やBrandonの掲載面監査の将来拡張の受け皿。

乗る③ ディレクトリスコープスキル

施設フォルダ配下に施設専用スキルを置ける仕組み。ただし現状は施設固有ロジックが少ないので、必要が生まれた時に使うと覚えておくだけで十分（先回りで再編しない — 増殖になる）。

乗らない — クラウドRoutinesへの定期実行移行

調査エージェントは移行を推しましたが、私の判断は見送りです。理由: 定期実行の主力（AirHost系・Chrome MCP相乗り・ローカルログイン前提）はクラウドでは動かず、BLADEは常時起動サーバーとして既に安定稼働（21本中20本正常）。壊れていないものを移さない。リポジトリ内で完結する純粋タスクが将来増えたら部分採用を再検討。

補足: 調査で挙がった一部の機能詳細（バージョン要件等）は未検証のため、採用時に公式ドキュメントで確認してから着手します。

発見の読み解き — 滞留はすべて「誰の仕事でもない場所」で起きた

今回見つかった問題の分布には偏りがあります。Peter・Frank・Brandonの持ち場（pricing系・施設健診・掲載面）は最も健全で、滞留していたのは スキル統合・handoff掃除・ディスク・検知後の処置 — つまり担当が貼られていない横断領域だけ。名簿の「名前を付けると業務が生成される」の裏返しで、名前が無い場所は誰も見ないことが実測で裏付けられた形です。

提言1 — 検知→処置の接続をBlackに（新設ではなく1行の拡張）

SlackQueue失敗は週次ヘルスチェックが検出済みだったのに2日間放置されました。Blackの週次台帳照合に「summaryのerrorを読み、自力で直せるものは処置提案を研鑽キュー（kind D＝環境の手入れ）へ積む」を加えると、既存の夜のシフトと噛み合って検知→処置が閉じます。新しい仕組みは作りません。

提言2 — スキルの統合・退役判断を「持ち主の週次」に載せる

第2章の統合候補が放置されてきた構造的理由は、スキルに担当行が無い群ほど誰の定例にも載らないこと。会議系6本・weekly系3本はまさに未割当地帯です。すぐ増員はせず、①担当行カバレッジを上げる ②未割当スキルの統廃合はBlackの月次に暫定で持たせる、の順を推奨します（オーナー報告・経理の空席は既に「催促しない」合意があるため触りません）。

提言3 — 名簿とClaude Code機構の関係は「現行が正」

Claude Codeにはカスタムエージェント定義（.claude/agents/）がありますが、社員名簿をそちらへ移すべきではありません。フック注入方式は「名前を呼ばなくても領域語で引ける」「毎ターン確実に届く」点で実地検証済みで、エージェント定義は呼び出した時しか存在しないためです。使い分けは — 名簿（アイデンティティ・毎ターン）＝フック、実行の分身（健診の並列読取り等）＝エージェント定義、と補完に留めるのが正しい設計です。

提言4 — 未登録の稼働2つを先に埋める（新設より先）

Stuartの定例2本が設計済み・未登録のまま。新しい社員や新機能より、設計済みの空欄を埋める方が第二段の成否指標に直結します。今回の環境レビュー自体も、本来はBlackの定例が季節業務（四半期棚卸し）として持つべき仕事 — 今回の調査プロンプト5本はそのまま雛形として再利用できます。