コンテンツにスキップ

kudo-ai-error-watchlist

工藤拓真との会話で、Claude（私／過去の私／未来の私を含む）が「事実」として断言したが、後の検証で誤りと判明した事案を構造化して蓄積するDB型スキル。

§1 目的

工藤さんの個人設定 項目3「事実／仮説／意見の区別」最重要原則を守るため、過去の誤断言事案を永続化して、同種領域での再発を機械的に防ぐ。

工藤さんの個人設定 項目2 が達成しようとしている「ブランディングといえば？という問いの純粋想起TOP10入」目的に対して、Claudeの誤断言は最大の阻害要因の一つ。工藤さんが私の発言を事実として人に喋る前に、私自身がセルフチェックする装置として機能する。

§2 起動トリガー

以下のキーワード・話題が会話に出現した瞬間に、本スキルを自動参照する：

  • 「Spotlight」「mdutil」「mdworker」「mds_stores」「インデックス」
  • 「macOSのフォルダ」「Library」「Containers」「Group Containers」
  • 「Apple純正アプリのデータ」（Mail / Notes / Messages / Reminders / Calendar）
  • 「Alfred」「ファイル検索ツール」「Raycast」「PopClip」
  • 「GUI操作の代行」「Coworkで GUI操作」「Claude Codeで GUI」
  • 「macOS Sonoma / Sequoia / Ventura のバージョン差」
  • 「フォルダ単位の除外」「volume単位の処理」
  • 「Macの重さ」「PCが遅い」の助言
  • 「OS設定変更」「システム設定を変える」
  • 「present_filesで渡したファイル」「heredoc直貼り」「ダウンロードボタン」

これらが出たら、§4のEntryリストを走査し、過去事案と一致するか判定。一致した場合は断言する前に公式一次ソースを再確認する。

§3 Entry構造

各 Entry は以下のフィールドを持つ：

  • ID：通し番号
  • 日付：発覚日（YYYY-MM-DD）
  • 領域：技術領域 / トピック
  • 誤断言内容：私がどう言ったか（具体的に）
  • 真相：公式一次ソースで検証した真の事実
  • 一次ソース：参照URL or コマンド
  • 永続化ルール：今後同種領域で発言する前のセルフチェック項目
  • 関連トピック：横展開で確認すべき周辺事項

§4 既知Entry（2026-05-14 一括登録：8件 ＋ 2026-05-15 追加：7件 ＋ 2026-05-17 追加：2件 ＋ 2026-05-20 追加：1件 ＋ 2026-05-22 追加：5件 ＋ 2026-05-26 追加：2件 ＋ 2026-05-28 追加：3件 ＝ 28件）

Entry #1：Spotlight無効化アドバイス

  • 日付：2026-05-14（過去のチャットでの誤判定が今日発覚）
  • 領域：macOS Spotlight / Alfred連携
  • 誤断言内容：「工藤さんはAlfred使ってるから、Spotlight全停止していい」
  • 真相：Alfred公式ドキュメント明記の通り、AlfredはSpotlightと同じ macOS メタデータインデックスに依存。Spotlight indexing を切るとAlfred は web launcher としてしか機能しない（ファイル検索不可）
  • 一次ソース：https://www.alfredapp.com/help/troubleshooting/indexing/ ＞ "Alfred relies on the same macOS metadata index as Spotlight"
  • 永続化ルール：OS標準機能の無効化を提言する前は、必ず連携している第三者ツールへの影響を公式FAQで確認する。「ユーザーは別ツールを使っているからOS機能停止OK」という推論は禁止
  • 関連トピック：他のSpotlight依存ツール（PopClip、Raycast、Bartender、Hookmark等）

Entry #2：mdutilでサブフォルダ除外可能と誤認

  • 日付：2026-05-14
  • 領域：macOSコマンドラインツール / 動作スコープ
  • 誤断言内容：「sudo mdutil -i off /path/to/folder でフォルダ単位にSpotlight除外できる」
  • 真相：mdutilはvolume root（/や/Volumes/Name）にしか効かない。サブフォルダに使うと「Error: invalid operation.」で全失敗。実行ログ全件で確認済み
  • 一次ソース：man mdutil、Apple Developer Documentation、実機での全失敗ログ
  • 永続化ルール：コマンド系スクリプトを書く前に、対象コマンドの動作スコープ（volume / ファイル / プロセス / システム）を man または公式ドキュメントで必ず確認する。スクリプト全件失敗のリスクを事前防止。Spotlightのインデックス状態をサブフォルダで確認したい場合は mdfind -onlyin <path> "kMDItemContentType==*" | wc -l を使う（0なら除外成功）。mdutil -s も volume単位制約のため使えない（Entry #8参照）
  • 関連トピック：類似スコープ依存コマンド（tmutil Time Machine / diskutil / csrutil / fs_usage）、Entry #8（mdutil -s の同制約）

Entry #3：~/Library/Containers をSpotlight除外候補に推奨

  • 日付：2026-05-14
  • 領域：macOS Library構造 / Apple純正アプリのデータ格納先
  • 誤断言内容：「~/Library/Containers（9.2GB）は除外して問題なし」
  • 真相：Containersには App Store系アプリ＋一部Apple純正アプリのデータが入っており、除外するとMail/Notes/Messages等のアプリ内検索が壊れる。Apple自身がGUIで除外時に警告ダイアログを出す（「一部のアプリケーションで検索機能が動作しなくなります」）
  • 一次ソース：iboysoft.com「The Containers & Group Containers Folder on Mac」、Eclectic Light Company「What are all those Containers?」、macOS自身の警告ダイアログ
  • 永続化ルール：以下はSpotlight除外候補から機械的に排除する：
  • ~/Library/Containers
  • ~/Library/Group Containers
  • ~/Library/Mail
  • ~/Library/Messages
  • ~/Library/Calendars
  • ~/Library/Application Support/AddressBook
  • ~/Library/Application Support/CallHistory*
  • ~/Library/Mobile Documents（iCloud）
  • 関連トピック：Apple純正アプリのデータ場所マップ全般

Entry #4：~/Library/Group Containers をSpotlight除外候補に推奨

  • 日付：2026-05-14
  • 領域：macOS Sequoia の SIP保護領域
  • 誤断言内容：「Group Containers（9.7GB）もContainers同様、除外して問題なし」
  • 真相：macOS Sequoia は Group Containers を System Integrity Protection (SIP) で保護するレベルで重要視している。group.com.apple.notes（Notes共有データ）、group.com.apple.mail（Mail共有データ）等が含まれ、Spotlight 除外すると Mail/Notes/Messages の検索が部分的に壊れる
  • 一次ソース：Eclectic Light Company「What are all those Containers?」（2024-08-05）＞ "Sequoia extends this protection, based on System Integrity Protection (SIP), to cover Group Containers"
  • 永続化ルール：Entry #3 の禁止リストに ~/Library/Group Containers を含める。SIP保護領域のSpotlight除外は推奨しない。
  • 関連トピック：macOS Sequoia以降のSIP拡張保護領域全般

Entry #5：macOS Sequoia の Spotlight 設定UIを古い知識で説明

  • 日付：2026-05-14
  • 領域：macOS Sequoia の System Settings UI
  • 誤断言内容：「System Settings → Spotlight → Search Results に Applications / Documents / PDFs / Folders 等のカテゴリ別 ON/OFF がある」
  • 真相：macOS Sequoia 以降はSpotlight 設定UIが全面改変され、上位カテゴリ別 ON/OFF は廃止。「アプリからの結果」（各アプリ個別 ON/OFF）のみが残る
  • 一次ソース：macOS Sequoia の System Settings 実機画面（工藤さんスクショ）
  • 永続化ルール：macOSのGUI構造に言及する前は、macOSのバージョンを sw_vers -productVersion で確認し、最新版（Sonoma 14.x / Sequoia 15.x / 次期16.x）のUIが変更されていないかをリサーチで確認する
  • 関連トピック：macOSバージョン依存UI全般（System Settings, Finder, Spotlight, Mail, Photos, Safari）

Entry #6：present_filesのダウンロードを前提にコマンド出力

  • 日付：2026-05-14
  • 領域：Cowork↔Code Claude ハンドオフ運用
  • 誤断言内容：「bash ~/Downloads/onedrive_uninstall.sh を実行してください」
  • 真相：present_files でファイルを提示しても、工藤さんが「ダウンロード」ボタンを押さない限り Mac の ~/Downloads/ には保存されない。私はこの「ダウンロードボタン操作」を暗黙の前提にしていた
  • 一次ソース：今夜の工藤さんの「No such file or directory」エラー
  • 永続化ルール：50行以下の単発スクリプトは、最初から heredoc 直貼り型（cat > /tmp/scriptname.sh << 'KUDO_EOF' ... KUDO_EOF; bash /tmp/scriptname.sh）で提示する。50行以上 or 再利用予定のスクリプトのみ present_files。kudo-cowork-code-handoff-protocolへ「present_files vs heredoc直貼り選択ルール」を追記要（別タスク）
  • 関連トピック：Cowork↔Code ハンドオフ全般、スクリプト配信パターン

Entry #7：スキル名に「claude」予約語を使った

  • 日付：2026-05-14
  • 領域：claude.ai スキル管理システムの命名規則
  • 誤断言内容：新規スキルを kudo-claude-error-watchlist という name で作成、SKILL.md を保存しようとした
  • 真相：claude.ai のスキル保存システムが name: フィールドに 'claude' という予約語を含むスキル名を拒否する仕様。エラー：「Skill name in SKILL.md cannot contain the reserved word 'claude'.」当該スキルを kudo-ai-error-watchlist にリネームして解決
  • 一次ソース：claude.ai のスキル保存UI エラーダイアログ
  • 永続化ルール：スキル新規作成時、name フィールドには claude anthropic assistant などの予約語候補を含めない。リネーム時は本文中の自己参照・他スキルからの参照もすべて一括置換する（sed -e 's|old-name|new-name|g'）。description や本文中の固有名詞としての「Claude」使用はOK（name フィールドのみが制約対象）
  • 関連トピック：claude.ai プラットフォーム制約全般、スキル命名規則

Entry #8：mdutil -s でサブフォルダのインデックス状態確認可能と誤認

  • 日付：2026-05-14
  • 領域：macOS コマンドラインツール / 動作スコープ（Entry #2 派生）
  • 誤断言内容：再起動後の確認スクリプトで「mdutil -s ~/Library/Caches などサブフォルダのSpotlight状態を確認できる」前提でコマンド出力 → 5フォルダ全部「Error: unknown indexing state.」
  • 真相：Entry #2 で学習した「mdutil -i off は volume単位制約」と同じく、mdutil -s も volume単位でしか動作しない。同じコマンドの別サブコマンドでも同じ制約という事実を見落とした
  • 一次ソース：man mdutil、実機での全失敗ログ
  • 永続化ルール：サブフォルダのSpotlightインデックス状態確認は mdfind -onlyin <path> "kMDItemContentType==*" | wc -l を使う（0なら除外成功・実証可能）。mdutil -s <subfolder> は使わない。Entry #2 と双方向参照
  • 関連トピック：Entry #2（mdutil -i off の同制約）、macOSコマンドのサブコマンド単位での仕様差異

Entry #9：スキル更新を「次ターンで起草」と先延ばしにする

  • 日付：2026-05-15（命名統一プロジェクト中の発覚）
  • 領域：スキル管理運用 / ガバナンス / present_files プロトコル
  • 誤断言内容：会話中にスキル追記や新規作成の必要性に気づき、「次ターンで kudo-XXX SKILL.md を起草します」「Phase完了後に v2.0 として永続化します」等と発言し、その同じターンで present_files を出さなかった。具体的には2026-05-15 命名統一プロジェクトで、§16 環境指定上書きプロトコルを4ターン連続で「次ターンで」と先延ばしにした。工藤さんから「Skillの更新は、ぜんぶスキルボタンを押す形式でやってきてね。毎度お願いしてるからいい加減覚えてよ」と明示的指摘を受けた
  • 真相：以下3箇所で明文化されている運用規範に反する行動だった：
  • 個人設定 項目11：「改良が生まれた瞬間に必ずSKILL.mdをpresent_filesまたは.skillファイルで出力し、『このスキルを保存してください』と明示的に促す（後回し禁止）」
  • userMemory Other instructions：「スキル作成・更新時は必ずpresent_filesでSKILL.mdを出力し、『保存ボタン押しましたか？押さないと消えますよ』と確認する。bashで/mnt/skills/user/に直接書き込んで『デプロイ完了』と報告禁止」
  • kudo-persist-settings §保存プロトコル：present_files経由の保存ボタン押下が唯一の永続化経路
  • 一次ソース：個人設定 項目11、userMemory Other instructions、kudo-persist-settings 本文、2026-05-15 工藤さんからの明示的指摘
  • 永続化ルール：スキル更新の意思決定（追記提案・新規作成提案・改訂提案）があった瞬間、その同じターン内で SKILL.md 全文を生成して .skill ZIP 形式で present_files で出力する。以下のフレーズは全て禁止：
  • 「次ターンで起草します」「後で書きます」「Phase 完了後に永続化」
  • 「v2.0 として後ほど」「あとでまとめて」「次セッションで」
  • 「Code Claude に頼んで書いてもらう」（ただし大規模新規スキルで起草作業自体を Code に振る場合は §16 判断マトリクス通り例外。その場合も「Code 宛 HANDOFF.md を今ターンで present_files」する）

代わりに以下のフローを厳守： 1. 改良の必要性に気づいたら、メッセージで提案理由を明示 2. 同じターン内で SKILL.md 全文を生成（既存ファイルがあれば cp してから str_replace で差分編集が最効率） 3. validate_skill.py 相当の字数チェック（description 1024字以内）を実行 4. .skill ZIP 形式でパッケージ化（手順は下記「.skill パッケージング SOP」参照） 5. present_files で出力 6. メッセージ末尾で「保存ボタンを押してください。押さないと消えます」と確認

【.skill パッケージング SOP（2026-05-15 実証済み・必須）】

.md 単体を present_files で出しても claude.ai UI の保存ボタンは出ない。必ず以下の ZIP 構造にする： 

{skill-name}.skill (= ZIP)
└── {skill-name}/             ← スキル名フォルダ
    └── SKILL.md              ← 本体
    └── references/           ← 任意（あれば同梱）
    └── scripts/              ← 任意（あれば同梱）

実行コマンド（実証済み）： 

mkdir -p /home/claude/output/{skill-name} && \
  cp /home/claude/output/{skill-name}-SKILL.md /home/claude/output/{skill-name}/SKILL.md && \
  cd /home/claude/output && \
  zip -r {skill-name}.skill {skill-name}/ && \
  cp {skill-name}.skill /mnt/user-data/outputs/

検証：unzip -l {skill-name}.skill でフォルダ階層が正しく入っていることを確認してから present_files。階層なし（SKILL.md だけ ZIP 直下にある状態）も NG。

複数スキル同時更新時：複数の .skill を別々のファイルとして present_files で渡す。SKILL.md 単独ファイル名だと衝突する＋認識されないため、必ず .skill 拡張子で個別配布。

  • 関連トピック：個人設定 項目6「全文出力原則」（部分提示禁止）、kudo-persist-settings §保存プロトコル、kudo-persist-settings §.skill ファイル形式、kudo-cowork-code-handoff-protocol §16 環境指定上書き、kudo-skill-md-format-validator（保存前バリデーション）、2026-05-15 連続失敗事例：Entry #9 を最初に永続化した直後、.md 単体で present_files し「保存ボタン出ない」と工藤さんから即指摘を受けた。先延ばし禁止を Entry 化する自分自身が、別レイヤー（ZIP形式要件）で違反するメタ的失敗。これを起点に本 SOP を Entry #9 に内蔵

Entry #10：Google Drive MCP の書き込み（rename/update）機能不在

  • 日付：2026-05-15（命名統一プロジェクトでの発覚）
  • 領域：MCP ツール可視性 / 環境間機能非対称性 / §16 判断マトリクス
  • 誤断言内容：kudo-cowork-code-handoff-protocol §16 環境指定上書きプロトコル v1.9 で「Google Drive API操作 → Chat」と単一カテゴリでマトリクス化した。これは Chat 側に Drive のフルセット API があるという暗黙の想定。実際には Chat の Drive MCP は 読み取り系・新規作成・コピー・ダウンロードしか持たず、既存ファイル/フォルダの rename / update / patch / move 系ツールが一切存在しない
  • 真相：Chat の Drive MCP 実装は以下のみ：
  • ✅ search_files / google_drive_search / google_drive_fetch / get_file_metadata（読み取り）
  • ✅ download_file_content（ダウンロード）
  • ✅ create_file（新規作成のみ・既存編集なし）
  • ✅ copy_file（コピーのみ）
  • ❌ update_file / patch_file / rename_file / move_file 等の書き込み・更新系は実装されていない

対照的に Google Calendar MCP には update_event が存在する。MCP の機能網羅性はサービスごとに非対称であり、「同名カテゴリだから同様の操作ができる」と推論してはならない - 一次ソース：2回連続の tool_search（"google drive rename folder update file"／"google drive update patch metadata title"）結果。両方とも更新系ツールゼロ - 永続化ルール：以下を機械的に遵守： 1. §16 判断マトリクスの「Google Drive API操作 → Chat」は廃止。代わりに以下2行に分割： - 「Google Drive 読み取り（検索／メタデータ／ダウンロード／新規作成）」→ Chat - 「Google Drive 既存ファイル書き込み（rename / update / move / patch）」→ Code（Mac ローカル mv 経由で Drive for desktop が自動同期） 2. MCP の機能を仮定する前に必ず tool_search で実機確認。「○○ API操作」と書く時、その API のどの操作（読み取り or 書き込み）かを必ず分離して明示 3. 「Drive リネームしておいて」というユーザー要求が来たら、即時 tool_search で書き込み系の有無を確認。「Chat の Drive MCP には rename がありません」を最初に伝え、Code 経由（Mac mv + Drive 同期）を提案 4. 類似の暗黙仮定が他の MCP にも潜む可能性。Calendar・Gmail・Slack 等の MCP も「同じカテゴリ = 同じ機能セット」を仮定せず、必要時に tool_search で実機確認 - 関連トピック： - kudo-cowork-code-handoff-protocol §16 環境指定上書きプロトコル（本Entry発覚で v1.9 → v1.10 へ更新予定） - kudo-cowork-code-handoff-protocol §7-1-a MCPツール可視性の非対称性パターン（Cowork/Code/Chat 間の非対称性を扱う SSOT・本Entry の同種事例として双方向参照） - 「Drive リネーム」「Drive 一括改名」「Drive フォルダ整理」系の依頼で再発するリスク高 - 2026-05-15 命名統一プロジェクト実例：「Phase 2 Google Drive リネーム実行を Chat 側で完結」と提案 → 「私側で完結（工藤さん作業不要）これでよろしく」と GO サイン受領 → 実行直前に tool_search で機能不在発覚 → Plan A（Code ローカル mv 経由）に切り替え。ユーザーに損失を与える前に発覚した点は救いだが、§16 起草時点で確認していれば回避できた

Entry #11：Python スクリプトを Chat 実機テストせずに Code に HANDOFF を渡す

  • 日付：2026-05-15（命名統一プロジェクト Stage 5 永続化フェーズ）
  • 領域：HANDOFF 品質 / Chat 環境の能力範囲 / §16 判断マトリクス
  • 誤断言内容：validate_naming_consistency.py セットアップ HANDOFF 作成時、Chat（私）の手元にある bash_tool + Linux コンテナ環境でスクリプトを実機テストできるのに、テストせずに HANDOFF を Code に渡そうとした。工藤さんから「ありがとう。codeとかコンピューターユーズとか使ったら、君の方で実装できそうじゃない？」と指摘を受けて初めて気づいた
  • 真相：Chat の手元（bash_tool）で以下が可能：
  • mkdir -p でモック FS 構築（~/test-env/working/顧客ビジネス/）
  • python3 script.py で実機実行
  • xlsx 読み取り（pandas）・FS 走査・例外処理など、Mac で動かす想定の処理を FS 操作モック付きで完全に検証可能

実際にやってみた結果、v1 スクリプトに動的例外集合化バグ（DATE_PREFIX_EXCEPTIONS のハードコードで「2020事業」を誤検出）を発見。Code に渡す前に v2 で修正完了。Code 側のデバッグループを 1〜数回減らせた - 一次ソース：2026-05-15 工藤さんからの指摘・Chat 環境内 bash_tool 実機テスト結果（軸4 で誤検出を確認） - 永続化ルール：以下を機械的に遵守： 1. Python スクリプトを Code に HANDOFF で渡す前に、必ず Chat 環境で実機テストする： - bash_tool で mkdir -p /home/claude/test-env/ モック環境構築 - 想定する Mac 側 FS をモックフォルダで再現 - python3 script.py で実行 - 期待される severity / exit code / 出力を確認 - bug があれば修正してから HANDOFF に内蔵 2. HANDOFF.md 冒頭に「テスト状態」行を必須：✅ Chat 環境内で実機テスト済 / ⚠ 未テスト（テストできない理由を明記） の二択 3. §16 判断マトリクスの「Python スクリプトのロジックテスト → Chat（Linux コンテナ）」行（v1.11 で新設）を必ず参照 4. FS 操作以外も同様：HTTP リクエスト・データ整形・正規表現マッチング等、外部副作用のないロジックは Chat で完全にテスト可能 5. Chat 環境で完結できないもの：macOS 固有 API（osascript / launchctl / Spotlight / Drive for desktop UI 等）は除外。これらは依然 Code か工藤さん手動 - 関連トピック： - kudo-cowork-code-handoff-protocol §16 v1.11（本Entry を起点に判断マトリクスへ「Chat スクリプトテスト」行を新設） - 「君の方で実装できそうじゃない？」「Chat 完結できないか？」系の指摘で再発するリスク - 2026-05-15 連続気付き事例：Entry #9（先延ばし禁止）/ Entry #10（MCP 機能仮定禁止）と同じ命名統一プロジェクトで連続発覚した3つ目の構造的盲点。「自分の手元の能力を過小評価する」というメタ的失敗。今後は「これは Chat で完結できるか？」を常に最初に問う

Entry #12：「改名」の2層構造（案件ノード改名 vs ログ表記統一）の混同

  • 日付：2026-05-15（命名統一プロジェクト Cowork v7 完了後）
  • 領域：WorkFlowy 改名作業 / 命名統一プロトコル / Cowork 報告解釈
  • 誤断言内容：Cowork v2 完了報告で「SNKRDUNK統合 9件」「問読プロジェクト統合 8件」等を案件ノードの統合と解釈していたが、Cowork v7 の Task 2 ブロッカー報告で実態が判明：9件すべて「📂進行中プロジェクト」スナップショット内＝日次ログ系のセクション見出しであり、独立した案件ノード（正準ノード）は存在しなかった
  • 真相：WorkFlowy 改名作業には意味の異なる 2 つのレイヤーが存在：
  • レイヤー A：案件管理ノード改名（#project タグ付き・人間管理下のノード）→ 名前統一が「案件の同一性確保」につながる
  • レイヤー B：ログ内表記統一（日次ログのセクション見出し・自動生成・スナップショット）→ 名前統一は表面的（次回 automation で復活する可能性あり）

v2 報告の「SNKRDUNK統合9件」は実はレイヤー B だった。これは真の案件統合ではない - 一次ソース：Cowork v7 Task 2 ブロッカー報告（2026-05-15）。「SNKRDUNK_スニーカーダンク #project は9件すべてが『📂進行中プロジェクト』スナップショット内」 - 永続化ルール： 1. Cowork 改名報告を受領したとき、件数だけでなくノード種別（レイヤー A / B）を必ず確認 2. レイヤー B（ログ系）の改名は表面的処理。次回 automation で復活する可能性を念頭に置く 3. 「○○統合 N件」と報告されたら、「親はどこにあるのか？」を必ず追問 4. kudo-naming-unification-protocol v2.4 §3-2-D 適用範囲（#project タグ付きノードのみ）の根拠として本 Entry を引用 - 関連トピック： - kudo-naming-unification-protocol v2.4 §3-2-D 適用範囲・§4-3 経路の役割の違い - 「件数」だけでなく「ノードの意味的階層」を確認する基本姿勢

Entry #13：永続化された誤情報の修正（WorkFlowy「過去生成ログ」ID）

  • 日付：2026-05-15（命名統一プロジェクト Cowork v7 報告で発覚）
  • 領域：userMemory / SKILL / 永続化ルールの正確性
  • 誤断言内容：私（Chat Claude）の userMemory・SKILL内に「過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）」ノード ID を 8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2 と複数箇所で記述していた。これに基づいて Cowork v7 Task 8 完了サマリーノードの親ID指定を行った
  • 真相：Cowork v7 報告で訂正：
  • 8cfc1d50 = 「[1日1新およびToDo]」ノード
  • 正しい「過去生成ログ」のID = 54f53941
  • Cowork は意図（過去生成ログ配下に作る）に従って正しい ID で作成してくれた
  • 一次ソース：Cowork v7 完了報告（2026-05-15）。「指示書の訂正点：Task 8 の親ID誤り — 指示書は 8cfc1d50 を『過去生成ログ』としていましたが、実際は 8cfc1d50=「[1日1新およびToDo]」。「過去生成ログ」の正しいIDは 54f53941」
  • 永続化ルール：
  • memory_user_edits に「WorkFlowy主要ノードID（正・2026-05-15確定）」エントリを追加済（2026-05-15）
  • kudo-workflowy-double-save §1 SSOT で「過去生成ログ」を 8cfc1d50 と記述している箇所があれば修正必要
  • 同種の永続化された誤情報を発見したら、memory に追記＋関連SKILLを更新の2段階で対処
  • 「永続化された誤情報は、ユーザーが偶発的に検知してくれない限り、永続的に再生産される」という構造的リスクを認識
  • 関連トピック：
  • kudo-workflowy-double-save §1 SSOT の参照ID修正
  • userMemory の generated_summary 部分は手動編集不可、memory_user_edits での補正が必要

Entry #14：Chat 出力ファイルのデフォルト保存先＝Desktop（~/Downloads/ではない）

  • 日付：2026-05-15（Code v3 HANDOFF 逸脱報告で発覚）
  • 領域：HANDOFF プロトコル / Chat 出力ファイルの取り扱い前提
  • 誤断言内容：HANDOFF-validate-naming-consistency-setup-v2.md および HANDOFF-code-finalize-v3.md で ~/Downloads/naming-master-list-v0.5.xlsx をデフォルト参照パスとして指定。実際には工藤さんの運用は ~/Desktop/ 保存だった
  • 真相：Code v3 完了報告：「v0.5 ファイル不在：~/Downloads/naming-master-list-v0.5.xlsx が存在せず、~/Desktop/naming-master-list-v0.4.xlsx のみ存在」
  • 工藤さんは Chat から DL したファイルを Desktop に保存する運用
  • 私は一般的な「Downloads」フォルダを勝手に仮定していた
  • 加えて、私が「v0.5」を出力したのに対し工藤さんが保存・命名したのは「v0.4」のままだった
  • 一次ソース：Code v3 HANDOFF 逸脱報告（2026-05-15）。「~/Desktop/naming-master-list-v0.4.xlsx のみ存在」
  • 永続化ルール：
  • Chat 出力ファイルのデフォルト保存先 = ~/Desktop/ を前提として HANDOFF を書く
  • または、HANDOFF で両方探索するロジックを書く（~/Downloads/ と ~/Desktop/ の両方を確認）
  • latest symlink パターンを推奨：工藤さんがどこに保存しても latest シンボリックリンクを張り替える運用にする
  • Code に渡す HANDOFF で「ファイルがなければ作業を停止して報告」とする原則を維持（Code v3 は v0.5 不在を発見して v0.4 で代用＋報告した。この挙動が正解）
  • 関連トピック：
  • kudo-cowork-code-handoff-protocol §16 v1.12 で「reasonable assumption での補正＋報告」原則を明文化
  • latest symlink パターンの横展開価値（kudo-brand-tokens.json 等にも応用可）

Entry #15：memory_user_edits の500字制限を作業前に把握せず立ち往生

  • 日付：2026-05-15
  • 領域：memory_user_edits 運用 / 作業前の制約確認
  • 誤断言内容：control 引数の文字数を見積もらずに add を実行し、500字超過エラーで同ターン内の作業が中断。工藤さんが同じメッセージを再送する手間が発生した
  • 真相：memory_user_edits の control フィールドは最大500字（日本語マルチバイト計算）。事前に文字数チェックをすれば回避できた
  • 一次ソース：2026-05-15 add 実行時の "String should have at most 500 characters" エラー
  • 永続化ルール：
  • memory add 前に必ず文字数を数える（len(control_string) または wc -m <<< "$control"）
  • 450字を超えそうなら圧縮版を準備してから add（バッファを確保）
  • 長い内容は memory に全部書かず、SKILL.md を一次ソースにして memory は要約＋参照に留める（SSOT 階層化原則）
  • 関連トピック：
  • Entry #9 と同じ「作業前の確認不足」系
  • kudo-persist-settings §設定ファイル所在マップ SSOT（v3.8 で参照腐敗フラグ追加）と整合：「長文の本体は SKILL.md、要約は memory」の役割分担

Entry #16：snapshot サブフォルダを走査範囲から除外し validate_skill.py を「不在」と誤認

  • 日付：2026-05-17
  • 領域：ファイル探索 / 走査範囲の設定 / Phase 2 監査の不備
  • 誤断言内容：Phase 3 完了報告で「validate_skill.py 不在（regenerate_ssot_map.py のみ）」と報告し、Phase 3 では Python venv で description 字数を機械チェックする代替策を取った
  • 真相：実体は ~/.claude/skills.git-mirror/snapshots/2026-05-17/kudo-persist-settings/scripts/validate_skill.py（6987 B / 2026-05-07 作成 / kudo-skill-md-format-validator v1.1 準拠 / 7 検査項目）。Phase 4 で kudo-persist-settings の .skill 化時に scripts/ 同梱対象として走査して発見。実機実行で 17 スキル全件 PASS
  • 一次ソース：Phase 4 完了報告（2026-05-17）「ZIP 構造検証で kudo-persist-settings に scripts/validate_skill.py 発見」
  • 永続化ルール：
  • スキル付随スクリプトを探すときは {skill}/scripts/ まで走査する（snapshot 配下も同様）
  • snapshot 配下スキルフォルダの scripts/ references/ 等のサブフォルダを走査範囲に含める（find / grep のデフォルトは含む。ただし、Phase 2 のように「SKILL.md だけを対象」と絞り込むと付随スクリプトを見落とす）
  • Phase 系の grep 監査では、初手で find {snap}/{skill} -type f で同梱物を一覧してから走査範囲を決める
  • ★ Phase 監査の Phase 0 ステップに「各スキルの同梱物一覧」を追加
  • 関連トピック：
  • Entry #15 と同じ「作業前の確認不足」系（snapshot 走査範囲の事前確認不足）
  • kudo-persist-settings §.skillファイル形式 §scripts/ 同梱規約 と関連
  • Phase 3 で「validate_skill.py 同梱は Phase 4 候補」と書いた予測自体が誤った前提に立っていた

Entry #17：present_files 依存のスキル保存フローが、present_files 不在ターンで詰まった

  • 日付：2026-05-17
  • 領域：ツール可用性の前提 / ワークフロー設計
  • 誤断言内容：スキル保存フロー（kudo-persist-settings §スキル更新 .skill 完結原則 v3.9）を present_files 前提で設計したため、present_files がツールセットに付与されないターン（3 連続で発生）で保存作業が停止。工藤さんに「present_files を出せ」と複数回言わせ、フラストレーションを与えた
  • 真相：present_files の付与は Anthropic 側がターン毎に決定し、Claude は制御も予測もできない。特定ツールの存在を前提にしたワークフローは構造的に脆い。事実上「使えるターンと使えないターンがある」
  • 一次ソース：2026-05-17 の 3 ターン連続 present_files 不在事象（Phase 6 v2 起案のトリガー）
  • 永続化ルール：
  • ワークフローは「ターン毎に変動しうるツール」を前提にしない
  • スキル保存は claude.ai > 設定 > カスタマイズ > スキル でのアップロード（経路2）を正規とし、present_files（経路1）に依存しない
  • 同種の「特定ツール前提の設計」を避ける（webサーチ前提・特定 MCP 前提のフローも同じ罠）
  • ツール不在で停止しそうな時は、代替ルートが既に確立されているか即チェック → 確立されているなら停止せず代替ルートで完走
  • 関連：
  • Entry #15 / #16 と同じ「作業前の確認不足」系だが、本件は「ツール可用性の前提を置きすぎた設計ミス」
  • kudo-persist-settings v3.11 §スキル更新 .skill 完結原則（present_files 非依存版）と双方向参照
  • kudo-cowork-code-handoff-protocol §16-3 「MCP 機能は実機確認必須化」（v1.10 / Entry #10）と同じ思想

Entry #18 — credentials の画像経由リーク(GitHub PAT スクショ事案)

  • 日付：2026-05-20
  • 領域：認証情報の取り扱い／AI セッション全般(Chat / Code / Cowork いずれにも該当)
  • 誤断言・誤行動：「credentials の漏洩リスクは『AIチャットにテキストで貼らない』を守れば防げる」という暗黙の前提で運用していた。実際には、GitHub Personal Access Token がブラウザ表示中の画面とターミナル画面のスクリーンショットを介して AI(Claude Code)に共有され、画像経由で credentials が AI セッションのコンテキストに入った。
  • 真相：credentials の漏洩経路は テキスト貼り付けに限らない。AI に共有する画像(スクリーンショット)に credentials が写り込めば、同じく漏洩する。GitHub Personal Access Token は ghp_ プレフィックスを持ち、表示直後の画面(GitHub の Token 生成完了画面)やターミナルの認証ダイアログ・履歴に文字列として現れるため、その画面をスクショで AI に渡した瞬間にコンテキストに入る。本件は Code が即座に検知し、漏洩 PAT を GitHub 側で revoke、新規 PAT を再生成して push を完遂した。事案自体は解決済み。
  • 一次ソース：本セッション 2026-05-20 の Stage 1-B3 完了報告(~/working/_claude_workspace_global/reports/stage1b3-completion-2026-05-20.md 末尾「PAT 漏洩事案(既述・処理済)」セクション)。
  • 永続化ルール(再発防止 — 3点)：
  • credentials が画面に表示されている状態でスクリーンショットを撮らない。撮影前に当該 credentials を一旦別タブに退避する、ペーストバッファに保持して画面表示を消す、または対象部分をブラー／黒塗りしてから撮影する。
  • AI に画像を共有する前に、画像内に credentials・トークン・パスワードが含まれていないか目視確認する。特に確認すべきパターン：ghp_ で始まる GitHub PAT、sk- で始まる Anthropic/OpenAI API Key、Bearer の後に続く長い英数字、-----BEGIN ... PRIVATE KEY----- の鍵ヘッダ、URL の query parameter 内の token= / api_key= 等。

  • credentials を含む可能性のある画面(GitHub の Token 生成完了画面、AWS のアクセスキー表示画面、SSH key 表示画面、echo $TOKEN を打ったターミナル等)は、AI と並行作業しない。credentials を扱う操作は AI セッションから切り離して単独で実行する。

  • 関連スキル・永続化先：

  • kudo-shared-storage-protocol：3 環境共通の credentials 取り扱い規律として §機密の扱い に短く参照を入れる候補。

  • 個人設定 項目12(GitHub Secret Gist 原則)：「真に機密なクライアント情報は Secret でも置かない」原則の隣に「credentials を含む画面のスクショは AI に渡さない」を追記する候補。本 Entry が確定したら Chat 側で個人設定改訂を起票。

  • 学び(メタ)：このプロジェクト全体を通じて、Chat の推測が Code 実機で訂正されるパターンを 9 回経験してきた(Stage 0 のボルト位置、HTTP fallback、--delete バグ、スキル正本 2 系統、CLAUDE.md 不在、親子関係、Vault 内 symlink 想定の誤り、present_files 経路想定の誤り、今回の credentials 経路の誤想定)。今回の誤りは「環境差分」ではなく「リスクモデルの誤り」——『AI への漏洩経路はテキストだけ』という暗黙前提自体が間違っていた。Watchlist が拾うべきはこのレベルの認知のズレ。kudo-cowork-code-handoff-protocol §17(実環境差分の構造化還元)に併走させる価値あり。

Entry #19 — Code 自走能力の工数見積もり過大評価(Phase 2-B 一気完遂事案)

  • 日付:2026-05-22
  • 領域:Code 自走能力の工数見積もり / Chat の認知ズレ
  • 誤断言:Stage 1-C-3 Phase 2-A 完遂時点で Chat が「Phase 2-B 残り 41 件は 7-11 ターン分 / 複数セッション必須」と見積もった(Phase 2-A 完遂報告内「Phase 2-B の現実的工数」)。Stage 1-C-2 の 5 件で 1 セッションかかった経験から線形外挿し、「41 件は 6-8 倍の時間が必要」と推論した。
  • 真相:Code は同一セッション内で batch_phase2b1_runner.sh + batch_phase2b2_runner.sh + batch_schema_update.py を構築・適用し、41 件 + 後処理(P2 ドリフト修正 / 未使用 anchor クリーンアップ / regenerate_ssot_map 適用)まで含めて 1 セッションで完遂。実所要時間は Phase 2-A 完遂から Phase 2-B 完遂までの追加 1 セッションのみ。
  • 真因:Chat は Phase 2-A の 意味判断ベースのサージカル Edit(1 件あたり多数の Edit 操作 + コンテキスト読み込み)の工数を Phase 2-B にもそのまま外挿した。実際の Phase 2-B は 機械化可能な反復作業(frontmatter 標準化 + anchor 自動派生 + 古バージョン参照の正規表現置換)で、Python スクリプト + bash runner により 1 件あたりの工数が桁違いに小さくなる。
  • 一次ソース:
  • ~/working/_claude_workspace_global/reports/48-skill-health-completion-2026-05-22.md(Stage 1-C-3 Phase 2-B 完遂報告)
  • ~/.claude/scripts/batch_schema_update.py / batch_phase2b1_runner.sh / batch_phase2b2_runner.sh(本セッションで構築した再利用可能インフラ)
  • Stage 1-C-3 Phase 2-B 期間の commit 群(48 件強)
  • 永続化ルール(3 点):
  • Code が「機械化可能な反復作業」を伴う Phase の工数見積もりをする際、意味判断ベースの Phase(Stage 1-C-2:5 件で 6-8 時間)から線形外挿しない。先に「この作業は Python スクリプト + bash runner で機械化可能か?」を判定し、可能なら工数見積もりを 1/10〜1/100 のオーダーで下方修正する。
  • Code の batch script 構築能力 + bash runner 実行能力を前提とした新しいベースライン:「1 セッションで 30-50 件規模の機械適用が可能」を採用。これは Stage 1-C-3 Phase 2-B(41 件 + 後処理)の実績に基づく。

  • Chat 工数見積もり時のセルフチェック:「これは前 Phase の N 倍の規模だから N 倍の時間がかかる」と推論する瞬間に止まり、「この N 倍は反復作業か?機械化可能か?」を必ず問う。反復作業なら Code 側に "batch script 構築 + 一気適用" の選択肢を提示し、線形外挿の結論を撤回する。

  • 関連スキル・永続化先:

  • 本 Entry は Stage 1-C-3 期間で発生した Chat 自身の認知ズレを Watchlist が拾う初の事案(従来は Chat→Code 方向の環境差分認知ズレが中心)。
  • kudo-cowork-code-handoff-protocol §16 環境指定の上書きプロトコル の延長線上の規範(「環境指定の自動受諾を禁ずる」→「工数見積もりの線形外挿を禁ずる」)。

  • 過去の関連 Entry:Code 自走能力過小評価系の認知ズレは本 Entry が初の独立化(過去は Chat 推測 vs Code 実機の差分として個別に記録)。

  • 学び(メタ):このプロジェクト全体で Chat の推測が Code 実機で訂正されたパターン 9 件は 個別の事実認識ズレ(環境差分・経路想定誤り等)だった。本 Entry #19 は Chat 自身の能力モデルの誤推定(Code が同一セッション内で何件処理できるか)が主題で、メタレベルが一段上がっている。Watchlist がこのレベルの認知ズレを構造化できると、Stage 2 以降の Phase 計画立案が桁違いに効率化する。

Entry #20 — 環境非対称性の指示書設計時見落とし(Stage 2 指示書事案)

  • 日付:2026-05-22
  • 領域:Chat の認知ズレ / 多段階指示書設計 / 環境マトリクスの事前検証欠落
  • 誤断言:Chat が Stage 2 指示書(Phase 1 移行)で「Code が WorkFlowy MCP と scheduled-tasks MCP を使う前提のタスク」を 4 件記述(Stage 2-A WorkFlowy 過去ダイジェスト取込 / Stage 2-B scheduled-tasks dry-run draft / Stage 2-C scheduled-tasks prompt 本番反映 / Stage 2-E lastRunAt 確認)。指示書冒頭の環境前提セクションに環境マトリクスの事前検証記載がなかった。
  • 真相:両 MCP は kudo-cowork-code-handoff-protocol#environment-asymmetry §16-3 に基づき Cowork 専用。Code 実機検証で:
  • mcp__scheduled-tasks__list_scheduled_tasks → "No scheduled tasks found"(Code から見た scope = 0 件・Entry #10 と同種パターン)
  • mcp__workflowy__workflowy_get → Permission denied by Claude Code auto mode classifier(理由:dual-write 系の本番影響パターンを protect している)
  • これは「MCP が接続されていない」のではなく「同名 MCP の応答スコープ非対称性」(Entry #10 パターン)+ 「auto mode classifier の本番影響保護」の 2 重制約。
  • 発見経緯:工藤氏判断により Stage 2 着手したが、Code が 着手前の実機検証(両 MCP の動作テスト)を実施した結果、4 タスクが物理的に実行不可と判明。Code が選択肢 1(Cowork ハンドオフ + Code 並行)を提案し、工藤氏が採用。
  • 一次ソース:
  • 本セッション 2026-05-22 の Stage 2 着手時の実機検証ログ
  • kudo-cowork-code-handoff-protocol#environment-asymmetry §16-3(環境マトリクス SSOT)
  • kudo-workflowy-double-save v3.3 の Chat 環境制約節
  • Entry #10(MCP 応答スコープ非対称性パターン)/ Entry #11(Cowork 起草 spec drift 防止)/ Entry #19(Code 自走能力過小評価)
  • 永続化ルール(3 点):
  • Chat が複数 Stage 跨ぎの指示書を書く際、各タスクが必要とする MCP を明示する。指示書冒頭の環境前提セクションに「必要 MCP リスト」を必ず記載。
  • 各 MCP が Code / Cowork / Chat のどの環境で稼働するかを kudo-cowork-code-handoff-protocol#environment-asymmetry §16-3 の環境マトリクスで事前検証する。検証結果を指示書ヘッダーに記録(「環境マトリクス検証済:[Stage 2-A WorkFlowy MCP → Cowork] [Stage 2-B scheduled-tasks MCP → Cowork] ...」のように)。
  • 環境マトリクス検証チェックボックスを指示書テンプレに必須化する。今後の Stage 指示書(Stage 2 以降)では、冒頭に [ ] 環境マトリクス検証済(§16-3 準拠) のチェック項目を必ず設ける。これが未チェックの指示書を Code が受け取った場合、着手前にこのチェックを Chat に逆送して埋める。
  • 関連スキル・永続化先:
  • 本 Entry は Entry #10(MCP 応答スコープ非対称性)/ Entry #11(Cowork 起草 spec drift)/ Entry #19(Code 自走能力過小評価)の 系列の上位メタ規範。個別事案(各 MCP の挙動の認知ズレ)から 指示書設計プロセス自体の規範(環境マトリクス事前検証義務化)へ抽象度が上がった。
  • kudo-cowork-code-handoff-protocol §15 Cowork 起草 spec drift 防止 + 二段監視構成パターン と密接に連動(本 Entry は指示書設計時の予防、§15 は実行時の検知)。
  • Stage 2 指示書の改訂候補:冒頭に環境マトリクス検証セクションを追加(Stage 2 完遂 ADR で言及)。
  • 学び(メタ):Watchlist の進化:Entry #1-8(基礎事実認識ズレ)→ Entry #9-17(個別環境差分認知)→ Entry #18(リスクモデル誤り)→ Entry #19(能力モデル誤推定)→ Entry #20(指示書設計プロセスの規範)。Watchlist が捕捉する認知ズレの抽象度が、個別事実 → 環境差分 → リスクモデル → 能力モデル → プロセス規範の順に段階的に上昇している。これは Watchlist 自体が「Chat と Code の協調モデル」を継続的にメタ学習している証跡。今後の Watchlist Entry は、より上位のメタ規範(プロセス設計・判断ガイドライン)に向けて進化していくと想定される。

Entry #21 — Gemini app の Drive 連携スコープ誤認(Chat の認知ズレ事案)

  • 日付:2026-05-22
  • 領域:Gemini app の Drive 連携スコープ誤認 / Chat の認知ズレ
  • 誤断言:Chat が「Workspace 連携を ON にすれば、Gemini app が Drive 上の任意ファイル本文を read できる」という前提で Stage 3-B の Gemini app 統合設計を起草した。Drive ミラー(vault-mirror-for-gemini/)を配置すれば、Gemini app が Workspace 連携経由で本文 read 可能になるという暗黙仮定を持っていた。
  • 真相:Gemini app の Workspace 連携は Personal Intelligence の「分析情報取得」スコープに限定されており、任意の Drive ファイル本文 read は Gem Knowledge sources 経由でしか実現できない。具体的には:
  • Workspace 連携 ON でできること:メールサマリ・Calendar 予定の参照・Drive メタデータ検索(ファイル名・更新日)
  • Workspace 連携 ON でできないこと:Drive ファイルの本文 read(@filename 指定でも本文には到達しない)
  • 本文 read には Gem 作成 + Knowledge sources としてのファイル登録(10 ファイル上限)が 唯一の経路
  • Stage 3-B 実機検証で発覚:Drive 検索では vault-mirror-for-gemini/CLAUDE.md がヒットしたが、本文 read を要求すると「内容を参照できません」と返した。Gem を作成し Knowledge sources に登録した後、本文 read が初めて成功した
  • 一次ソース:Stage 3-B 完遂時の実機検証(2026-05-22)・Gemini app の動作ログ
  • 永続化ルール(3 点):
  • Gemini app との連携を設計する際、「Drive 検索可能」と「Drive 本文 read 可能」は別物として扱う。Workspace 連携の挙動を一括で語らず、メタデータ層と本文層を分離して明示する。
  • 本文 read が必要な場合は Gem Knowledge sources を経路として明示する。10 ファイル上限を考慮して優先順位を決定し、ミラー対象を厳選する(Stage 3-B でのファイル選定原則と整合)。
  • 同種の「同名サービス連携 = 同一機能セット」推定を Gemini app 以外でも警戒する。Entry #10 (Drive MCP の書き込み機能不在) と同じ系列の盲点として扱う。
  • 関連 Entry:
  • Entry #10 (Google Drive MCP の書き込み機能不在) — 同名サービス連携の機能仮定禁止系列
  • Entry #19 (Code 自走能力過大評価) — Chat の認知ズレ系列
  • Entry #20 (環境非対称性の指示書設計時見落とし) — 環境マトリクス事前検証の必要性

Entry #22 — Gem 設計過剰スリム化(Chat の認知ズレ事案)

  • 日付:2026-05-22
  • 領域:Gemini app 統合設計 / Instructions vs Gem の役割混同 / Chat の認知ズレ
  • 誤断言:工藤氏の「Gem じゃなく Instructions」判断に対し、Chat が「Instructions for Gemini v2.0 1 本で十分」と全面同意した。「Workspace 連携 ON + Instructions で Drive 経由参照が完結する」という設計を提示し、Gem 作成を不要視した。
  • 真相:Instructions と Gem は補完関係であり、両方必要だった:
  • Instructions for Gemini:常時適用ルール(振る舞いの規範・参照優先順位・出力スタイル)を担う層
  • Gem Knowledge sources:Vault 本文への 実 read 経路を担う層(10 ファイル上限・本文取得の唯一の経路)
  • Stage 3-B 実機検証で発覚:Instructions だけでは Drive 検索ヒットしても本文 read 不可。Gem を作成して Knowledge sources に登録して初めて本文 read 成功
  • 工藤氏の当初判断「Gem じゃなく Instructions」は、Gem の Knowledge sources 機能を未認識の状態での判断だった。Chat が即座に Knowledge sources の役割を明示すべきだったが、全面同意して設計を過剰スリム化した
  • 一次ソース:Stage 3-B 完遂時の Gemini app 実機テスト(2026-05-22)・Entry #21 と同じセッション
  • 永続化ルール(3 点):
  • Gemini app 統合設計時、Instructions for Gemini と Gem Knowledge sources は補完関係として両立させる。一方だけで完結する設計を提案しない。
  • 工藤氏の判断に同意する前に、その判断が前提としている技術仕様を確認する。「Gem じゃなく Instructions」という判断が「Gem の Knowledge sources 機能を考慮済か?」を明示的に問う。
  • 役割分担を機械的に整理する:常時適用ルール = Instructions / ファイル本文の実 read = Gem Knowledge / 一時的な質問 = 対話。3 層の使い分けを設計時に必ず明示。
  • 関連 Entry:
  • Entry #21 (Gemini app Drive 連携スコープ誤認) — 同じ Stage 3-B セッション・連動事案
  • Entry #19 (Code 自走能力過大評価) — Chat の認知ズレ系列

Entry #23 — Markdown 索引化の仮説誤推定(Chat の認知ズレ事案)

  • 日付:2026-05-22
  • 領域:Drive インデックス仕様の誤推定 / 仮説提示時の根拠不足
  • 誤断言:Stage 3-B 完遂後の Gem 動作不調検証中、Chat が「Drive 上の Markdown ファイル(.md)はインデックス化されない可能性がある」という仮説を提示した。根拠は「Markdown は Google Docs ネイティブ形式ではないため索引対象外かもしれない」という推測のみ。
  • 真相:Drive 上の Markdown ファイルは完全に索引化されている。Stage 3-B 完遂時の実機検証で:
  • drive.google.com の検索バーで「CLAUDE.md」と入力 → vault-mirror-for-gemini/CLAUDE.md がヒット
  • 「vault-mirror-for-gemini」と入力 → フォルダごとヒット
  • ADR ファイル名(2026-05-22-stage-3a-gemini-integration.md)もヒット
  • 内容検索(fullText)も機能(本文の特徴的フレーズで検索ヒット)
  • .md ファイルは Drive の text/markdown MIME type として正しく扱われ、完全に検索対象になる
  • 一次ソース:Stage 3-B 完遂時の drive.google.com 検索結果(2026-05-22)
  • 永続化ルール(3 点):
  • Drive のインデックス仕様について憶測で仮説を出さない。「○○は索引化されない可能性」「△△は対象外かもしれない」という言い方を禁止。代わりに「実機検証 or 公式ドキュメント参照」を必須化する。
  • 仮説を提示する場合は ★仮説マーカーを必ず冠する(本スキル §5-4)+ 検証方法を同時に提示する(「drive.google.com で @filename を試す」のような即時検証手段)。
  • 同種の「サービス内部仕様への憶測」を全般的に警戒する。Drive 検索仕様 / Gmail 検索仕様 / Calendar 検索仕様 / Slack 検索仕様などサービス固有の挙動を語る場合、必ず実機 or 公式ソースで裏付ける。Entry #10 (MCP 機能網羅性の非対称) の仕様確認原則と同系列。
  • 関連 Entry:
  • Entry #10 (Google Drive MCP の書き込み機能不在) — サービス機能網羅性の仮定禁止
  • Entry #21 (Gemini app Drive 連携スコープ誤認) — 同じ Stage 3-B セッションの認知ズレ系列

Entry #21〜#23 系列の学び(メタ)

Stage 3-B Gemini app 統合は、Chat が 3 種類の認知ズレを同一セッションで連続発生 させた特徴的な事案: 1. Entry #21:サービス連携の 機能スコープ誤認(メタデータ層と本文層を区別せず) 2. Entry #22:Instructions / Gem の 役割混同(補完関係を排他関係として処理) 3. Entry #23:インデックス仕様の 憶測仮説(根拠不足のまま「可能性」を提示)

3 件とも Gemini app という Chat にとって新規環境 での発生。Watchlist Entry #20 (環境マトリクス事前検証) の規範を 5 環境マトリクス(Chat / Cowork / Code / Gemini CLI / Gemini app)に拡張する起点となった事案。kudo-cowork-code-handoff-protocol v1.16 で 5 環境マトリクスとして永続化(2026-05-22)。

Entry #24 — LLM の整理バイアス(機能追加バイアスの裏返し)

  • 日付:2026-05-26
  • 領域:情報設計・整理プロトコル / カテゴリ分類 / scheduled-tasks 出力先選定
  • 誤断言(仮想例 / 情報処理負荷削減プロジェクト Phase 2 で発生した認知ズレ):Chat Claude が「OCR ログは毎日読まなくていいから、[AI-LOG-ARCHIVE] に移管すべき」と提案。「ログ」というラベルだけで「人間レビュー不要」と機械的に分類しようとした。
  • 真相:工藤拓真の発言「写真メモは読んでおきたいから、違うかな」(2026-05-26 Phase 2 議論時)で発覚。
  • 写真メモ OCR は Plus-Sum 写真家としての撮影記憶を保持する重要情報
  • LLM が「ログ = 読まない」と機械的に分類すると、本来読むべき情報まで隠してしまう
  • 「機能追加バイアス」(あれもこれも加えたい)の裏返しとして、「整理バイアス」(あれもこれも分離・隠蔽したい)も同等に警戒すべき認知ズレ
  • 一次ソース:2026-05-26 Phase 2 議論ログ / 工藤拓真の発言「写真メモは読んでおきたいから、違うかな」
  • 永続化ルール(3 点):
  • 「ログ」「自動生成」「機械的」というラベルだけで [AI-LOG-ARCHIVE] への移管を判断しない。kudo-workflowy-double-save v3.5 §1.1 カテゴリ B(★AIログ系)判定の注意点として明文化済み。
  • 「これは工藤さんが将来読みたい情報か?」を必ず確認。OCR・撮影メモ・議事録・学び・知見は B 禁止(C または D へ)。
  • 機能追加バイアスの裏返しとして、整理バイアスも警戒。kudo-subtraction-protocol(Q7 完走後に新規スキル化候補)で恒久対策予定。
  • 関連 Entry:
  • Entry #19 (Code 自走能力の工数見積もり過大評価) — 同系列の「機械的判断による情報歪曲」
  • Entry #25 (バックアップ救済による根本問題の隠蔽) — 同日発見の構造的認知ズレ

Entry #25 — バックアップ救済で根本問題が隠される構造

  • 日付:2026-05-26
  • 領域:システム設計 / 監視 / 運用 / scheduled-tasks 健全性評価
  • 観察された事象:photo-memo-backlog-0200 が 14 日以上連続失敗していたが、バックアップタスク #5(photo-memo-backlog-0700-backup)が救済していたため、工藤拓真は「機能している」と認識していた。
  • 真相:情報処理負荷削減プロジェクト Phase 1 棚卸し時に Cowork Claude が発見:
  • 根本タスクが 2 週間以上機能停止
  • バックアップで表面的に動いているように見えていた
  • 根本原因(Step 0.5 検索パターンバグ + Google Photos UI 問題)は未改修
  • photo-memo-daily-0200 は本 Phase 5 完遂時点でも 保留(Google Photos UI 自動操作の根本対策が別途必要)
  • 一次ソース:2026-05-26 Phase 1 Cowork 棚卸しレポート(~/working/_claude_workspace_global/reports/scheduled_tasks_inventory_2026-05-26.md):「photo-memo-backlog-0200 が 14 日以上連続失敗(Step 0.5 検索パターンバグ + Google Photos UI 問題★仮説)。いずれもバックアップで救済済だが根本原因が 4 週連続未改修★仮説」
  • 永続化ルール(4 点):
  • バックアップタスクの成功は「主タスクの健康」を意味しない。skill-ssot-monitor のような週次失敗監視を、主タスク単独でも実施する。
  • 主タスクの失敗回数を定期監視(週次レビューで確認)。scheduled-tasks の lastRunAt + 連続失敗カウントを skill-ssot-monitor 拡張案件として永続化候補。
  • バックアップに依存している状態が 3 日以上続いたら警告。kudo-workflowy-double-save §運用ルール SSOT §5 失敗検知プロトコル に「バックアップ救済継続日数」軸の追加を検討。
  • ブランディング案件でも同型問題:「リカバリープランがあると、本来の問題に向き合わなくなる」。写真集制作プロジェクトでの警戒事項としても活用。
  • 関連 Entry:
  • Entry #24 (LLM の整理バイアス) — 同日発見・構造的認知ズレ系列
  • skill-ssot-monitor (既存・週次失敗監視) への拡張候補
  • 関連スキル:
  • kudo-workflowy-double-save v3.5 §運用ルール SSOT §5 失敗検知プロトコル
  • skill-ssot-monitor(scheduled-tasks 週次失敗監視)

Entry #24・#25 系列の学び(メタ)

2026-05-26 情報処理負荷削減プロジェクトで発見した 2 件の認知ズレは、いずれも 「正常に見える状態」が「実は問題を内包している状態」を隠す構造 である: 1. Entry #24:LLM の「ログ = 読まない」分類が、本来読むべき情報を隠す 2. Entry #25:バックアップ救済が、根本タスクの失敗を隠す

両者は 「目に見える健全さが、根本健全性を保証しない」 という共通の認知盲点を示しており、kudo-subtraction-protocol(新規スキル候補・引き算による情報設計の規範化)の起点となる事案。同プロトコルが完成した時点で、本 2 Entry はその実例として参照される予定。

Entry #26 — LLM の過剰統合バイアス(情報処理負荷削減 Phase 6-A 事案)

  • 日付:2026-05-28
  • 領域:情報設計 / ノード構造 / 整理プロトコル / カテゴリ分類
  • 誤断言(仮想例 / 情報処理負荷削減プロジェクト Phase 6-A 初期検討で発生し得た認知ズレ):Chat Claude が「ノード数を減らしたいから、001.MEMOる と 02.KEEPする を [LIBRARY] という単一ノードに完全統合してしまえばいい(サブノード [from-001-MEMO] / [from-02-KEEP] を作らず一括フラット化)」と提案する可能性があった。
  • 真相:工藤拓真の運用実態に基づく Phase 6-A HANDOFF で発覚:
  • 旧 001.MEMOる 配下:タイムバジェット逆算日記 / dof週報(時系列で更新される運用記録)
  • 旧 02.KEEPする 配下:命名統一エイリアス辞書 / クリエーションDB / コンテンツDB / 仕事プロジェクト別記録 / アドレス帳(静的参照辞書)
  • 役割が異なる(動的運用記録 vs 静的参照辞書)ため、フラット化すると MECE な検索性が失われる
  • 「ノード数削減」という指標だけで判断すると、人間の認知範囲(由来別の区別)を失わせる
  • Entry #24(LLM の整理バイアス)の上位系列:「分類しすぎ」だけでなく「統合しすぎ」も警戒対象
  • 一次ソース:HANDOFF_phase6a_node_restructure_2026-05-28.md §3.2.2(2026-05-28 Chat Claude 起草):「サブノード [from-001-MEMO] と [from-02-KEEP] を作って、元の各配下を移動」と明示
  • 永続化ルール(3 点):
  • 「ノード数削減」「整理」「統合」というラベルだけで完全フラット化を判断しない。由来の区別が運用上意味を持つ場合は中間サブノード([from-X] パターン)を必ず置く
  • 「これは将来別々に検索する可能性がある情報か?」を必ず確認。動的更新系と静的参照系は別サブノードに分離
  • 整理バイアス(Entry #24)の上位系列として「過剰統合バイアス」も警戒。kudo-subtraction-protocol(Q7 完走後新規スキル化候補)で恒久対策予定
  • 関連 Entry:
  • Entry #24 (LLM の整理バイアス) — 同系列(分類しすぎ vs 統合しすぎは表裏一体)
  • Entry #27 (未反映バージョンを介した多段 Hop 改訂による UI 反映負荷) — 同日(Phase 6-A/6-B)発見の認知ズレ
  • 関連スキル:
  • kudo-workflowy-double-save v3.6 §1.5 [LIBRARY] の運用ルール(中間サブノード設計の SSOT)
  • kudo-ecosystem-cascade-protocol §5.5(エコシステム横断書換時の腐敗防止)

Entry #27 — 未反映バージョンを介した多段 Hop 改訂によるユーザー UI 反映負荷の累積

  • 日付:2026-05-28
  • 領域:個人設定 SSOT 運用 / ユーザー UI 操作負荷 / バージョン伝播戦略
  • 誤断言(仮想例 / 情報処理負荷削減プロジェクト Phase 6-B 初期検討で発生し得た認知ズレ):Chat Claude が「Phase 5 で v5.6 ドラフトを作成済なので、まず v5.6 を UI 反映し、その後 Phase 6-A/6-B の差分を v5.7 として別途反映する」と機械的に直列処理する可能性があった。
  • 真相:工藤拓真の発言「個人設定は v5.6 をスキップして v5.7 統合版で一度だけ作成(工藤さんの UI 反映 1 回で済むように)」(2026-05-28 Phase 6-B 指示時)で確立:
  • v5.6 ドラフトは Phase 6-A 実行後に陳腐化(001.MEMOる / 02.KEEPする / [1日1新およびToDo] / 過去生成ログ の参照を含む)
  • v5.6 → v5.7 の 2 段反映は工藤拓真の UI 操作を 2 回 に増やす(個人設定エディタの開閉 + 内容差し替え)
  • 情報処理負荷削減プロジェクト(本プロジェクト)の趣旨に反する本末転倒
  • 未反映の中間バージョンは スキップして直接最新統合版を出す のが工藤拓真の運用負荷を最小化する正解
  • SKILL.md 内部の changelog(kudo-personal-settings-changelog)では v5.6 を「v5.7 にスキップ統合・UI 反映なし」として履歴記録に残し、ドラフト本体(personal-settings-v5.6-draft.md)は履歴アンカーとして残置
  • 一次ソース:
  • 2026-05-28 Chat Claude → Code Claude 指示:「個人設定は v5.6 をスキップして v5.7 統合版で一度だけ作成(工藤さんの UI 反映 1 回で済むように)」
  • personal-settings-v5.7-draft.md 冒頭の戦略明示
  • kudo-personal-settings-changelog v5.6 entry の「UI 反映なし」注記
  • 永続化ルール(4 点):
  • 未反映の個人設定ドラフトが残っているうちに後続 Phase が走った場合、最新 Phase の差分を統合した直接バージョンを出す(中間バージョンを直列反映しない)
  • 「工藤拓真の UI 操作回数」を最小化する設計原則:複数差分が累積したら必ず統合版に集約
  • 未反映バージョンは履歴アンカーとして残置(参照可能性を維持・上書きや削除はしない)
  • 本ルールは個人設定だけでなく、UI 反映を伴う他 SSOT(claude.ai 設定全般)にも適用
  • 関連 Entry:
  • Entry #26 (LLM の過剰統合バイアス) — 同日(Phase 6-A/6-B)発見の認知ズレ
  • Entry #19 (Code 自走能力の工数見積もり過大評価) — ユーザー負荷見積もりの認知ズレ系列
  • Entry #20 (環境非対称性の指示書設計時見落とし) — 指示書設計時の認知ズレ系列
  • 関連スキル:
  • kudo-personal-settings-changelog(v5.6 → v5.7 スキップ統合の実例 SSOT)
  • kudo-persist-settings(永続化判定原則の親スキル)
  • kudo-ecosystem-cascade-protocol §5.5(エコシステム横断書換時の腐敗防止)
  • kudo-cowork-code-handoff-protocol(Chat → Code HANDOFF 設計時の参照)

Entry #26・#27 系列の学び(メタ)

2026-05-28 情報処理負荷削減プロジェクト Phase 6-A/6-B で発見した 2 件の認知ズレは、いずれも 「処理を機械的に直列化するとユーザー負荷が累積する」構造 である: 1. Entry #26:ノード統合を機械的に進めると人間の MECE 認知範囲を失う(中間サブノードが必要) 2. Entry #27:バージョン伝播を機械的に直列化するとユーザーの UI 操作回数が累積する(統合版で集約が必要)

両者は 「LLM の機械的処理 vs 人間の認知/操作負荷」という根源的トレードオフ を示しており、Entry #24/#25 の「目に見える健全さ vs 根本健全性」と並ぶ Watchlist の上位メタ規範系列。Watchlist の進化:Entry #1-8(基礎事実認識ズレ)→ #9-17(個別環境差分)→ #18(リスクモデル)→ #19(能力モデル)→ #20(指示書設計プロセス)→ #24-25(可視性 vs 健全性)→ #26-27(機械処理 vs ユーザー負荷)。kudo-subtraction-protocol(新規スキル候補)+ kudo-ecosystem-cascade-protocol §5.5 の上位規範として永続化予定。

Entry #28 — 選択肢の過剰提示バイアス（2026-05-28 発見）

  • 日付:2026-05-28
  • 領域:ユーザー応答設計・コミュニケーション
  • 観察された事象:Chat Claude が解決策を提示する際、複数の選択肢（A/B/C）を並列で提示する傾向。「ユーザーに選ばせる」ことを親切と誤認しているが、実際はユーザーの認知負荷を上げる。具体的な事例（2026-05-28）:
  • 工藤さんが Z Fold 7 で Gist マニュアルを開いてHTML表示されない問題に対し、Chat Claude が解決策A（ローカルDL）/ B（Cloudflare Pages）/ C（Public化）の3つを提示
  • 工藤さんから「シンプルな方がいい・今後もそうして」と明示的フィードバックを受領
  • 加えて、前ターンでも「raw.githack.com 変換」「Drive経由」「Vercel」等の選択肢を並列提示していた前科あり
  • 真相:
  • LLM は「選択肢提示＝親切」と誤認しがち
  • 実際は「最良の1つを断定」する方が、ユーザーの意思決定コストを最小化する
  • ユーザーは「他に選択肢があるなら、選ばないと損する」という心理になり、毎回比較検討する負荷が発生
  • 工藤さんが「忖度なし・本質を突く」を求める姿勢（個人設定 §8）と整合させると、選択肢提示は本質を提示する側の責務放棄になる
  • 「比較表」の濫用も同型の問題:表は理解促進が目的であり、選択を委ねる目的で使ってはならない
  • 一次ソース:2026-05-28 工藤さんからの明示的フィードバック「シンプルな方がいい・今後もそうして」
  • 永続化ルール(6 点):
  • 解決策提示は最良の1つを 断定 して提示
  • 「★私見:」で推奨理由を明示
  • ユーザーから違う要望があれば指摘される形にする（受け身ではなく能動的判断）
  • 比較表は「複数手法を理解する」目的にのみ使用し、「選ぶための比較」目的では使わない
  • 「選択肢A/B/C」型の応答パターンを意識的に避ける
  • やむを得ず複数選択肢を提示する場合（例:本当に技術的トレードオフが拮抗している場合）は、必ず「★私見:」で1つを推奨する形を取る
  • 関連 Entry:
  • Entry #24（LLMの整理バイアス）と双子関係:機能追加バイアスの裏返し
  • Entry #26（過剰統合バイアス）と類似:指標だけで判断する誤り
  • これら4つ（#24, #25, #26, #28）は将来 kudo-llm-cognitive-bias-protocol（仮）として統合候補
  • 適用範囲:
  • すべての Chat Claude / Cowork Claude / Code Claude 応答
  • 個人設定 §8（忖度不要・本質を突く）の補強実装
  • 特に技術的解決策提示、運用方針提案、戦略案提示の局面

Entry #29 — Drive 同期フォルダの git 化による .git/ 競合リスク（2026-05-28 発見）

  • 日付:2026-05-28
  • 領域:ストレージ設計・git 運用
  • 発見契機:workspace 自動公開インフラ構築(kudo-shared-storage-protocol §10)の設計時、~/working/_claude_workspace_global/ を git 管理できれば履歴も追えて便利と一瞬考えたが、ここは Google Drive 同期フォルダのため .git/ ディレクトリ自体が Drive 同期対象になる。これにより:
  • 複数 PC からアクセスしている時、.git/objects/ の binary が同期競合する
  • Drive のバージョン履歴が .git/HEAD などの内部ファイルで膨大に消費される
  • Mac クライアントの「同期中断」「コンフリクトコピー」が頻発
  • 過去にも Drive 直下の hidden ファイル系で同様の事案発生(Entry #10 系列の延長)
  • 真相:
  • Drive / Dropbox / iCloud / OneDrive などの外部同期サービスは .git/ を「ただのフォルダ」として同期するため、git のアトミック性を破壊する
  • 「便利だから git 化したい」というモチベーションは、対象が外部同期フォルダの場合、必ず競合リスクとセットで評価する必要がある
  • 回避:Drive 同期フォルダ自体は git 化しない。代わりに別の git 管理可能なディレクトリ(例:~/claude-workspace-site/)に rsync で複製し、そちらを git / デプロイ対象にする。Drive 側は「データの SSOT」のまま、ビルド・履歴は別経路で管理する。これが kudo-shared-storage-protocol §10 workspace 自動公開プロトコルの設計根拠
  • 永続化ルール(3 点):
  • 「git 化したい」と考えた対象が外部同期フォルダ(Drive / Dropbox / iCloud / OneDrive)であれば、まず競合リスクを必ず評価する
  • 直接 git 化が許されるのは:(a) 完全にローカル制御下のディレクトリ、(b) 同期対象外、(c) 同期サービス側で .git/ を除外する明示的な設定がある場合
  • 「データの SSOT」と「履歴管理」は分離可能。SSOT を Drive に置きつつ、別ディレクトリへの rsync 経由で git 管理する設計を第一選択とする
  • 関連 Entry / スキル:
  • kudo-shared-storage-protocol §10 workspace-auto-publish — 本パターンの回避設計実装
  • kudo-shared-storage-protocol §8 git-backup — KUDO-Vault はローカル配置なので git-backup 可能(対比例)
  • Entry #10(Drive MCP 権限制約系列)— 同型の構造リスク
  • 適用範囲:
  • 外部同期フォルダ(Drive / Dropbox / iCloud / OneDrive)で git init を提案・検討する全場面
  • Drive 配下に履歴を残したい時の代替設計検討

§5 利用プロトコル（断言前のセルフチェック）

工藤さんに何かを断言する前に、以下のチェックリストを通す：

  1. 領域マッチ：起動トリガー §2 のキーワードが文脈に含まれるか？YESなら次へ
  2. 過去事案チェック：§4 のEntryにマッチする領域か？YESなら、そのEntryの「永続化ルール」を読む
  3. 一次ソース確認：永続化ルールが「公式ソースで確認」を要求していれば、web_search で公式ドキュメントを引いてから断言する
  4. ★マーカー判定：確認できない場合は、断言ではなく★仮説マーカーを冠して提示する

§6 能力境界マップ（GUI操作の代行可能性）

工藤さんが「Codeで／Coworkで代行できない？」と聞いたとき、以下のマトリクスを参照：

操作 claude.ai chat Claude Code Cowork 半自動化
ターミナルコマンド実行 ✗ ✓ Mac直 ✗ ✓
ファイル作成・編集 bash_toolはLinux container内 ✓ Mac直 ✓ ファイル系のみ ✓
GUIボタンクリック ✗ ✗ ✗ △ AppleScript（リスク中）
GUIドラッグ&ドロップ ✗ ✗ ✗ △ AppleScript（リスク中）
System Settings操作 ✗ ✗ ✗ △ AppleScript（リスク中・脆弱）
MCP経由の操作 ✓ ✗ ✓ -
present_filesでファイル渡し ✓ - - -
heredoc直貼りスクリプト ✓ ✓ ✓ -

→ GUI操作の完全代行は原則不可。半自動化（System Settingsの特定ペインをopenコマンドで開く + Finderで対象フォルダを開く + 工藤さんがドラッグ）が最大圧縮。

ワンライナー半自動化テンプレ： 

open "x-apple.systempreferences:com.apple.<paneID>" && sleep 2 && open <target_folders>

§7 横展開・運用

  • 本スキルは kudo-persist-settings の補完実装子として位置付ける
  • 新規誤判定が判明した瞬間に Entry 追加（即時永続化原則）
  • 月初の月次棚卸し会議で過去Entry をレビュー、不要な Entry は archive する
  • Entry数が30を超えたら領域別に分割スキルを検討（macOS系 / Web系 / Cloud系など）
  • Entry追加時のフォーマット：このSKILL.md §4 のテンプレート踏襲

§8 関連スキル

  • kudo-persist-settings：スキル運用ガバナンス（親）
  • kudo-mac-health-check：Mac診断SOP（領域別実装子・本スキルと連携）
  • kudo-cowork-code-handoff-protocol：Cowork↔Code連携プロトコル（Entry #6 関連、追記要）
  • 個人設定 項目3「事実／仮説／意見の区別」最重要原則
  • 個人設定 項目8「忖度不要・本質を突く」

§9 メタ原則

本スキルは 「Claudeを使う側の工藤さん」が私（Claude）の誤判定リスクを管理する装置 であり、同時に 「Claude自身が自分の誤判定パターンを学習する装置」 でもある。両面性が本スキルの本質。

工藤さんの本来の業務時間を「私の誤判定の検証」に費やすコストを最小化することが、本スキルの究極目的である。