🏠 目次に戻る

クロちゃん環境監査レポート：ラン①（D-1＋D-4 統合）

監査日：2026-07-03／方法：CLAUDE.md・.claude/rules/ 24本・00_rules/ 21本・memory 103本・SKILL.md 51本を全読、参照パスは test -e／Glob で実在検証。ファイル変更・削除は一切していない（読み取りのみ）。

サマリー

発見件数：①重複・統合候補 14群／②矛盾 11件／③パス切れ 約90箇所（26ファイル）／④由来ラベル：ナツミ明示 約45・由来不明 約16・クロ提案由来 2／⑤構造要因 6つ／⑥棚卸し方針 1式

最重要5件：

  1. タスク運用ルールが「新旧2系統」同時に生きている：CLAUDE.md の Discord 連携欄と memory/discord_channels.md が今も「タスクは tasks.md に追記」と指示。2026-05-17 の Notion 一本化（tasks.md 凍結）と真っ向矛盾で、凍結ファイルを更新する事故の直接原因になる。
  2. 00_rules/ は 6/1 時点の古いスナップショットなのに、CLAUDE.md 含む11箇所がそこを参照。辿ると「6/16 以降の改訂（reply記法見本・routing-hub大原則③・引き継ぎDiscord表示）が無い版」を読んでしまう。
  3. 毎セッションの定常注入が約128KB（概算4〜5万トークン）＋Skill説明52本。ルール不適用（破り）の最大の構造要因。矛盾込みの大量注入は「どれかを破る」ことが構造的に保証されてしまう。
  4. workspace 移行（6/5）への追従漏れが約90箇所。毎日使う drops-inbox・morning-briefing・baton-pass・banner-create（旧ユーザー名参照で完全動作不能）に集中。
  5. 朝ブリ244件の原因はクエリ構造で確定：「期限が今日以前の未完了を無制限に全部返す」型（下限なし）。凍結 tasks.md の未完了253件と規模が一致し、4〜5月の完了マーク漏れが毎朝再表示されている。

① 重複・統合候補（14群）

各項目：対象 → 統合先の提案。1件ずつ OK/NG 可。

A-1.【高】00_rules/ ディレクトリ全体（21ファイル） .claude/rules/ の古い実コピー。17件同一・4件旧版（baton-pass-handover / daily_log / discord-reply-tool-required / routing-hub）・新規5件欠落。workspace/rules シンボリックリンクが既に正解の仕組みとして存在する。 → 提案：00_rules/ を _trash/ へ移動（trash-workflow 準拠）。Obsidian から見たい場合はシンボリックリンク 00_rules → .claude/rules に置換。あわせて旧パス表記11箇所（CLAUDE.md:84、baton-pass-handover.md:54-55、discord-reply-tool-required.md:98-99、output-routing-hatsushin-neta.md:39-40、routing-hub.md:59-62）を .claude/rules/ 表記に統一。

A-2.【高】Discord チャンネル定義の三重管理 memory/discord_channels.md（最新・36ch）⇔ .claude/rules/discord_channel_operations.md（5/28版・7ch欠落＋旧チャンネル名）⇔ CLAUDE.md（「12チャンネル」「#claude-bot/#ai-experiments」「#タスク・スケジュール管理」＝全て改名前）。 → 提案：マスターを discord_channels.md に一本化し、rules 側は「カテゴリ思想と横断ルールのみ」・CLAUDE.md は「memory を参照せよの1行のみ」に減量。

A-3.【高】タスク登録ルールの四重記載 CLAUDE.md ＋ task-management.md ＋ task-registration-flow.md ＋ memory/feedback_task_register_first.md。しかも memory 版だけ凍結済みの「tasks.md/tasks.html に登録」手順を保持（唯一間違っている）。 → 提案：rules 2本を1本（task-registration-flow をマスター）に統合、memory 版は「rules昇格済み・参照のみ」の3行索引に縮約、CLAUDE.md は要点3行に減量。

A-4.【高】Discord reply ルールの三重記載 CLAUDE.md（長文再掲）＋ discord-reply-tool-required.md ＋ memory/feedback_discord_reply_tool_required.md。 → 提案：rules をマスター、CLAUDE.md は「reply ツール必須・ツール先頭・800字分割。詳細→rules」の3行に、memory は索引化。

A-5.【中】daily_log 統合済み memory 3本の残骸 feedback_realtime_logging.md／feedback_memory_plus_notes.md／feedback_channel_usage_rules.md は daily_log.md（6/30統合版）に吸収済みと daily_log 側が明記しているのに、memory 本文は全文のまま＋旧チャンネルマッピング表が daily_log の新表と食い違う二重管理。 → 提案：3本とも「rules昇格済み」の索引スタブに縮約。

A-6.【中】feedback_one_at_a_time.md＋feedback_quadrant_priority_proposal.md — task-registration-flow に統合済み。→ 索引化（ただし②-4 の矛盾解消とセットで）。

A-7.【中】feedback_avoid_flying_check_first.md — plan-confirm-execute と重複だが、6/25 の根本原因分析・チェックリストだけ rules 未反映の独自価値あり。→ その部分を rules へ移植してから索引化。

A-8.【中】feedback_discord_long_message_split.md — rules と重複＋memory 側が新しい（②-5参照）。→ rules を更新してから索引化。

A-9.【中】feedback_learning_knowledge.md — knowledge_workflow.md にほぼ完全吸収された初期版（87日前）。独自情報ほぼゼロ。→ 削除候補筆頭（削除は1件ずつ確認ルールに従いナツミ判断）。

A-10.【中】feedback_course_archive_pattern.md — knowledge_workflow と部分重複＋参照パス全滅。overview 集約パターンは価値あり。→ パスを 50_references/ 体系に直して knowledge_workflow へ統合。

A-11.【中】3本柱スナップショットの多重管理 — memory/project_3pillars.md（5/2版）⇔ memory/project_courses_pillars_mapping.md ⇔ workspace ルート project_3pillars.md・2026-06-27_business_strategy_2026_h2.md。→ memory 側を「最新は 10_personal/biz/ の H2 戦略」への索引に更新。

A-12.【低】reference_midori_writer_projectf.md ⊂ reference_prof_team.md（ほぼ包含）。→ 索引用として残す or 統合、どちらでも可。

A-13.【低】feedback_open_background.md — browser-open.md と重複＋md の扱いは open-md-in-obsidian に上書きされ古い。→ 索引化＋「md は対象外」注記。

A-14.【低】html-sync.md — 対象の notes/ がほぼ空でルールごと死んでいる（③参照）＋knowledge_workflow と index.html 更新方針が部分衝突。→ 廃止 or 10_personal/library/** 対象に書き直し、のどちらかをナツミ判断。

② 矛盾（11件）

B-1.【高】「タスクは tasks.md に追記」vs Notion 一本化 CLAUDE.md Discord連携欄（#タスク・スケジュール管理 → tasks.md 追記）と memory/discord_channels.md（#敏腕秘書ch の振る舞い「tasks.md 即追記（マスター）→ tasks.html も更新」）が、task-management.md の凍結ルールと正面衝突。判断材料：Notion 一本化（5/17 改訂・新しい方）が正。 → 2箇所を「Notion Tasks DB に登録」へ書き換え。

B-2.【高】「詳細不明でも即登録」vs「プラン提案→確認→実行」 CLAUDE.md 冒頭は「即登録もこのフローを通す（提案→OK→登録）」と裁定済みだが、task-management.md（正しい例＝確認なし即登録）・task-registration-flow.md Step2・feedback_task_register_first.md は裁定前の「即登録」のまま。セッション中どちらを踏んでも「ルール破り」に見える構造。判断材料：CLAUDE.md の裁定（提案→OK→登録）が最新のナツミ決定。 → 下位3ファイルに裁定を反映。

B-3.【高】「勝手に延期しない・即着手完遂」vs「全作業プラン確認」 feedback_no_arbitrary_postpone.md は「デフォルトは今すぐ実行・承認は不可逆操作のみ」と plan-confirm の適用範囲を独自に再解釈しており、plan-confirm-execute.md（全作業プラン提示）と未解決のまま並立。「即動くと怒られる／確認すると『勝手に延期するな』」の板挟みは、体感の「噛み合わない」の有力原因。→ 優先順位の明文化が必要（ナツミ裁定案件）。例：「実行タイミングは即・ただし着手前のプラン1本は必須／不可逆・外部送信は明示OK待ち」。

B-4.【中】「今深掘る？と聞く」vs「聞かない」 task-registration-flow.md Step5（聞く）⇔ routing-hub.md（聞かない・park のみ、6/6 の新しい決定）⇔ feedback_drops_triage_timing.md（タスク化判断は夜/翌朝の関所）。→ 「ハブ経由は聞かない・直接依頼は Step5」の境界を1箇所に明文化。

B-5.【中】長文不達時の手順食い違い rules discord-message-length.md「まず短文テスト」⇔ memory feedback_discord_long_message_split.md 5/12 更新「テスト省略・即分割再送」（ナツミ指示で新しい）。memory の方が新しいのに rules 未反映という逆転。 → rules を更新。

B-6.【中】yt-summary 逐次 vs 重い処理は背景で並列 feedback_yt_summary_serial.md（並列で index.html 競合・exit 1）の制約が discord-background-processing.md に注記されておらず、rules だけ読むと並列起動して壊す。→ rules 側に例外1行追記。

B-7.【中】claude_prof 隔離ルール vs 現物の配置 ルール（claude_prof_isolation.md:45-46）は Discord ログを _stock/logs/discord/ に置けと言うが、そのディレクトリは存在せず、現物 discord_backup.log が禁止場所 _stock/logs/claude_prof/ に実在。Discord 全ログはプロFチームに見せてはいけない筆頭。→ ログの移設＋launchd 出力先変更＋ルールのパス修正（実対応は別ラン）。

B-8.【低】html-sync「notes/index.html を必ず更新」vs knowledge_workflow「index.html にカード追加禁止」 — 適用対象の切り分けが不明瞭。→ A-14 とセットで解消。

B-9.【低】focus-protect（割り込まない）vs baton-pass（自分から声かけ）・no_arbitrary_postpone（自走） — proactive さの優先順位が未定義。→ 「安全網系（baton-pass・stuck-report）は focus-protect の例外」と1行明文化。

B-10.【低】reference_yt_summary.md「MariaDB」vs reference_xserver_db.md「MariaDB 不可・MySQL 5.7 のみ」 — 表記衝突。→ yt_summary 側を修正。

B-11.【低】feedback_no_tables.md（テーブル禁止）vs rules/memory 自身の多数ファイルが表組みを使用 — 適用範囲（会話出力のみ？md も？）が曖昧。→ 「対象＝ナツミがコピペする会話出力・md 本文は可」等の範囲を1行追記。

③ 古い・パス切れ（約90箇所・26ファイル。移行先は全て実在確認済み）

共通変換表（確定）：notes/tasks.md・drops_inbox.md・handover/・coaching/・projects/・guides/ → 10_personal/library/配下／notes/business/ → 10_personal/biz/／notes/resources/<講座系> → 50_references/courses/／notes/daily/ → memory/daily/／notes/raw_discord_log/ → _stock/discord/／client/ → 20_companies/／bin/・~/claude-sandbox/bin/ → 30_departments/02_CTO/automation/／vault/inbox/ → 50_references/inbox/。

C-1.【高】CLAUDE.md 本体（7箇所）：L19 tasks.md/html、L54 logs/discord/（不存在）、L60 prof_dashboard.md（→10_personal/library/projects/）、L70 notion-tasks-today.py、L73 morning-briefing SKILL の場所（実体は ~/.claude/skills/）、L94 youtube_growth/、L103 discord_setup_workflow.md。→ 一括修正提案（1ファイルなので1件扱い）。

C-2.【高】drops-inbox.md（rules）：notes/drops_inbox.md ×4箇所 → 実体 10_personal/library/drops_inbox.md（既知の疑い＝確定）。ほか ai_learning_log.md 旧パス、幽霊ファイル memory/feedback_drops_inbox_log.md 参照（実体なし・3ファイルから参照）。→ パス修正＋幽霊ファイルは「新規作成 or 参照削除」をナツミ判断。

C-3.【高】morning-briefing SKILL.md（8箇所）：notes/daily/・notes/raw_discord_log/・notes/yaruki_self_observation.md・mbl_questions.json・bin/morning-briefing.py 等（既知の疑い＝全て確定、正パス特定済み）。毎朝走る基幹 Skill で、間違うと旧 notes/daily/ を再作成する実害。→ 最優先修正。

C-4.【高】banner-create SKILL.md：旧ユーザー名 /Users/fuekinatsumi/claude-sandbox/ 参照2箇所＋保存先 output/banners/ 不存在。現状100%動作不能。.env の現在の置き場所は未検証。→ 全面書き直し。

C-5.【高】baton-pass SKILL.md：出力先 notes/handover/ ×5箇所 → 正 10_personal/library/handover/。安全網 Skill の出力先違いは引き継ぎ書行方不明に直結。→ 修正。

C-6.【高】memory/discord_channels.md：旧パス9箇所以上（yt-summary・sns_ideas.md・client/ 系・shift_ai_advisory 等）＋#まな式の「振る舞い」H4 重複（お金の潜在意識の保存先が混入）＋#おさるai講座セクション欠落。→ 1ファイル総点検。

C-7.【中】rules 6本のパス群：daily_log.md（extract-channel-section.py はどこにも存在しない・discord-archive.py の実名は discord-daily-rebuild.py・記録先マッピング表に旧パス多数）／knowledge_workflow.md（knowledge_index ほか5箇所＋3階層構造 notes/resources/<ジャンル>/ 自体が不存在）／doc_order_recent_first.md（適用対象リストが全て旧構造）／task-management.md・task-registration-flow.md（bin/・tasks.md）／session-save.md は問題なし。→ 各1件ずつ修正提案。

C-8.【中】Skill 6本のパス群：lp-design（13箇所）／ad-strategy／yuco-lp-axis（7箇所）／promo-analysis（thresholds.json にも旧パスがハードコード＝実行時エラー源）／note-writer（3箇所＋frontmatter 完全欠落・小文字 skill.md）。→ 各1件ずつ。

C-9.【中】memory 約20本のパス差し替え：feedback 系（task_register_first・realtime_logging・channel_usage_rules・file_dependencies〔依存マップほぼ全滅〕・natsumi_diet_rules・focus_protect ほか）＋reference 系（yt_summary〔全面移行前〕・web_tools・invoice_schedule・my_claude_skills_repo〔global-skills 一本化と矛盾〕・subagent_sandbox_limit〔境界が旧ディレクトリ前提で誤誘導〕）＋user_neurodivergent_traits。→ 「変換表による一括パス差し替え」として1承認で処理可能な粒度に分けて提案。

C-10.【中】鮮度切れ project メモ5本：project_claude_macmini（導入済みなのに「近々予定」）・project_mana_course（6/26卒業済み）・project_line_harness（「3月中に」のまま94日）・project_projectf_tsu_evergreen（4/24凍結・プロライン前提）・project_lefroma（4月イベントが現在形）。→ 各1件「更新 or アーカイブ」判断。

C-11.【低】索引の不整合：MEMORY.md 索引漏れ1件（feedback_family_calendar_separate.md）／索引記述が stale 4行（yt-summary パス等）／feedback_stuck_report_5min.md の frontmatter name: "5" 破損／reference_osaru_ai_vs_marke_course.md のリンク先ファイル名不一致。

④ 自己参照ループ（クロ提案の固定化チェック）

64本の feedback memory を由来で分類した結果：

構造的な注意：feedback_no_arbitrary_postpone.md は「ナツミ明示」由来だが、その中でクロが plan-confirm の適用範囲を独自に再解釈しており（②-3）、明示発言＋クロ解釈の混合体。再解釈部分の追認が必要。

⑤ ルール破りの再現条件（構造分析）

S-1. 定常注入の物量：CLAUDE.md 7.9KB＋rules 24本 98.6KB＋MEMORY.md 索引 21KB ≒ 128KB／概算4〜5万トークンが毎セッション注入。さらに Skill 説明52本（akuma-skill 781字・mana-threads-monetize-advisor 639字等の巨大 description 含む）。指示が多いほど1本あたりの遵守率は下がる。最有力の構造要因。

S-2. 矛盾による「必敗」構造：②の B-1〜B-4 は「どちらに従っても片方を破る」ペア。ナツミの「ルールを破る」体感の相当部分は、クロの怠慢ではなくルールセット側の非決定性で説明がつく。

S-3. 三重コピーのドリフト：CLAUDE.md 再掲・rules・memory・00_rules の最大4копии。更新は1箇所にしか入らないため（例：B-5 の逆転、B-1 の tasks.md）、セッション中にどのコピーが参照されるかで挙動が変わる。特に 00_rules/ は「パスとして解決してしまう古い版」なので、リンクを辿った瞬間に古いルールが正として読み込まれる。

S-4. コンテキスト要約による薄まり：CLAUDE.md/rules は再注入されるが、セッション中に Read した memory・引き継ぎ書・ナツミとの合意は要約で圧縮され、細部（「聞かない」「800字」等の具体値）から先に失われる。長セッション後半でルール破りが増える体感と整合。対策は「ルールは注入源（rules）に置き、セッション中の合意は即ファイル化する」現行方針の徹底＋S-1 の減量（要約前の残り容量が増えるほど薄まりにくい）。

S-5. reply 記法メタ指示のリスク：discord-reply-tool-required.md は「崩れた記法の実例」を長文で注入している。崩れ例を毎セッション見せる構造はプライミングとして逆効果の可能性があり、少なくとも大量の注入枠を消費している。→ 「reply ツールを応答の先頭に・前置き禁止・800字分割」の3行に圧縮し、NG例の列挙は削る提案（逆効果の実証は未検証・枠消費は実測どおり）。

S-6. Skill トリガー競合：「投稿作って」6 Skill・「LP作って」5 Skill・「スライド作って」2 Skill・「バナー/サムネ」3 Skill が同時宣言。どれが発火するか運任せで「頼んだのと違う流派で書かれた」＝噛み合わない体感の一因。加えて writer-feedback・yuco-lp-axis・masaru-youtube-{script,title} は description がハーネス一覧で空表示（発火率低下の疑い・原因未検証）。mana-threads-note-router は未インストール Skill 3つ（threads-post-kit 等）をハードコード参照。Cloudflare One 系2本はナツミの業務と無関係でほぼ確実に不要。

⑥ Notion Tasks DB 棚卸し方針

原因（コード根拠付きで確定）：

棚卸し方針案（ナツミが1件ずつ OK/NG できる粒度）：

  1. 一括アーカイブ基準の裁定：「期限が 2026-05-31 以前 かつ ステータス未着手/未設定」を棚卸し対象とし、（a）完了済みだった→完了マーク（b）もうやらない→アーカイブ（c）まだやる→期限を今日以降に更新、の3択で処理。244件を一気に人力判定せず、クロが領域×期限で仕分けリストを作り、ナツミは束単位で判定する形を提案。
  2. 第4領域＝アーカイブ運用の徹底：「捨てずに眠らせる」思想どおり、迷ったら削除でなく第4領域＋アーカイブ checkbox へ。
  3. スクリプト改善（別途プラン承認後に実施）：期限に下限（today−30日）を追加し、それより古い分は「⚠️ 30日以上期限切れ N件（要棚卸し）」の1行集計に分離／notion-tasks-today.py に除外条件を移植して2スクリプトの仕様統一／鮮度バケット表示（今日・今週・7日以内切れ・それ以前は件数のみ）／デッドコード pick_summary_tasks（L138-162・未使用）の整理。
  4. 再発防止の運用ルール：タスク完了時の「Notion ステータス更新」は既存ルールにあるが漏れている実態があるため、朝ブリ末尾に「昨日完了にしたもの N件／期限切れ増減」の1行を出して漏れを毎朝可視化する案。
  5. なお morning-briefing 用の launchd plist は ~/Library/LaunchAgents/ に見当たらず（/Library 側は権限拒否で未検証）、「朝6時自動投稿」が現在も生きているかは要確認。

実行順の提案（効果の大きい順）

  1. B-1＋C-1（CLAUDE.md の修正）：tasks.md 追記指示の削除・パス7箇所・チャンネル数/名の更新。毎セッション必ず注入される1ファイルなので費用対効果が最大。
  2. A-1（00_rules/ の退役）：古いルールが読まれる経路を物理的に断つ。_trash/ 移動＋シンボリックリンク化＋旧参照11箇所の書き換えで完了。
  3. ⑥-1〜2（Notion 棚卸し）：244件問題は毎朝の体験を直撃しているので早期に。スクリプト改善（⑥-3）は棚卸し後でも効く。
  4. C-3・C-5・C-4（morning-briefing／baton-pass／banner-create の Skill 修正）：毎日使う基幹と安全網から。banner-create は動作不能なので使う予定があるときまでに。
  5. B-2〜B-4（タスク系矛盾の裁定反映）＋A-3：「即登録 vs プラン確認」「即実行 vs 全確認」「聞く vs 聞かない」の3裁定をナツミに確認→ rules/memory へ一斉反映。ここが「ルールを破る」体感の根治。
  6. A-2〜A-10＋C-9（重複 memory の索引化・パス一括差し替え）：注入量の減量フェーズ。S-1 の128KBを目標50〜60%まで圧縮できる見込み（圧縮後の遵守率改善は未検証・理論値）。
  7. S-6（Skill 整理）：トリガー競合の分離・不要 Skill（Cloudflare One 系ほか）のアンインストール・note-writer の frontmatter 修復。
  8. ④の追認2件＋由来不明16件の月次棚卸し：急がないが、7/8 以降の運用ルール見直しの初回テーマに組み込むと収まりがよい。

未検証事項の明示：Notion 実データの期限分布／banner-create の APIキー現在地／morning-briefing launchd の生存／Skill description 空表示の原因／S-5 の逆効果性／注入圧縮によるルール遵守率の改善幅／20_companies/lumiere/ の実体場所／~/.claude/secrets/ 配下（権限で確認不可）。

🏠 目次に戻る