🤖

Claude Code で個人 PDCA 自動化基盤を作った話 — 1 ヶ月の運用記録

に公開
個人開発
automation
PDCA
Anthropic
Claude Code
tech

はじめに

  • なぜこれを書くか: Claude Code を 1 ヶ月ほど触るうちに、「個人の PDCA」を 4 つの長期テーマで回す土台を一人で組み上げられそうな手応えが出てきた。KGI / KPI / KDI の 3 階層構造をそのままファイルに落としていけるので、その設計判断と途中で踏んだ失敗をまとめて共有したい
  • 読者にどんな価値があるか: 11 スキル + 12 hooks + 3 agents で組んだ個人 PDCA 自動化基盤の全体像を、一気に俯瞰できる。スキルに「学習機能」を持たせる 3 階層（references / cache / vault）、特定領域だけ「決定論化」する 5 重防御、auditor サブエージェントによる Read-only 監査 — この 3 つの設計パターンが見渡せる

筆者プロフィール

  • 保有資格: CKA / CKAD / CKS / KCNA（K8s 4 冠）+ GCP 4 冠（ACE/PCA/PCD/CSE）+ CSM
  • 業務経験: 業歴 約 7 年

📝 個人テーマの伏字方針: 本記事では 4 軸の具体テーマはプライバシー配慮で 軸 A〜D の記号に抽象化して扱う。読者が自分の 4 軸（家族 / 副業 / 読書 / 運動 / 趣味 など、好きに置き換え可）に当てはめて読めるよう、設計の構造だけを切り出す。

結論先出し: Claude Code で個人 PDCA を自動化して見えた 3 つの効果と 3 つの注意

効いた 3 つの効果

  1. 「やる気」依存からの解放 — 毎朝 04:00 に daily-briefing が起動して output/information/YYYY-MM-DD/index.md を自動生成。起床直後の最高集中時間に「読む」より「考える」に脳のリソースを振れる
  2. 連続記録の自動可視化 — pdca/streaks.json で 4 軸の連続達成日数が ⭐⭐⭐🏆 で段階表彰される。「やる気」ではなく「数字で見える実績」が次の日のモチベーションになる、という習慣化の仕組み
  3. 「学んだ知見」の永続化 — 共通ナレッジ層 knowledge-vault（以下 vault）（書籍・記事・動画のハイライトを 3 点要約で蓄積する貯蔵庫）に各スキルから双方向で読み書きできる（手動投入と他スキルからの自動書き出しを同時に受ける）

先に知っておきたい 3 つの注意

  1. 「全部自動化」は罠 — KGI（5 年目標）の変更は 年次のみ手動。週次・月次では機械的にチェックするだけで、目標自体は動かさない。PDCA の基本原則「目標を変えるより手段（KPI/KDI）を変える」と合う運用にしている
  2. 「学習させてはいけない領域」がある — 軸 A（外部データに依存して判定する領域）のスキルだけは 決定論化（外部の客観データだけを根拠に、揺らがず同じ結論が出る状態にすること）する。具体的には「vault から軸 A スキルへの読み込みを禁止」「軸 A スキルから vault への書き出しのみ一方通行で許可」とする。願望や目標を判定の根拠にしないための 5 重防御
  3. 「締め付けを緩める仕組み」を最初から組み込む — pressure_relief_mode: true の一行で、全数値を「ペース調整中 / Sカーブ停滞期」表現に置き換えて逃がせる退避路を必ず作っておく。Atomic Habits も PDCA も「仕組みで続けさせる」のが大前提

個人 PDCA 自動化基盤の全体像

数字で見る現状（2026-05-06 時点・実体カウント）

  • スキル: 11 件 — 本記事で扱うのは 5 件（axis-a-analyst = 軸 A の数値判定スキル / habit-mindset = 習慣・脳科学・770 行 knowledge_core / daily-briefing = 毎朝 04:00 自動 / claude-code-research / knowledge-vault = 共通ナレッジ層）。残り 6 件は本記事のスコープ外のため etc... でまとめる
  • Hooks: 12 件（PreToolUse / SessionStart / PreCompact / PostCompact / SubagentStop / PostToolUseFailure / UserPromptSubmit / StopFailure / PostToolUse:Edit|Write|MultiEdit など複数 lifecycle event に配線）
  • Agents: 3 件 — axis-a-auditor（CL1-CL11 監査・軸 A 専用）/ pdca-auditor（軸 B-D 監査・軸 A パス読取禁止）/ habit-auditor（軸 C 専用粒度・vault 非参照）— 全て Read-only 監査専用 / Write・Edit ツールを持たせない設計

⚠ 上記の数字は 2026-05-06 時点の実体カウント（.claude/skills/ / .claude/hooks/ / .claude/agents/ 配下のファイル数）。Claude Code 自体のリリース更新で events 数の認識訂正等が起きるため、最新値は各自プロジェクトで実体確認することを推奨。

構造マップ — Claude Code の 4 つの構成要素を 1 枚で

各ブロックの役割

ブロック 何をしているか
👤 ユーザー入力 スラッシュコマンド（/daily-briefing 等）や自然言語プロンプト。すべての処理の起点
🛠 SKILL .claude/skills/<skill>/SKILL.md に書かれた手順書の本体（11 件）。「何を読み・何を判定し・何を出力するか」をスキルごとに定義する。daily-briefing / habit-mindset / claude-code-research / knowledge-vault / 軸 A 数値判定スキル などが該当
📦 Cache / References スキルの学習機能（3 階層）。不変の手順（SKILL.md 本文）/ 半永続の知識（references/ や knowledge_core.md を月単位で更新）/ 実行履歴 + 品質スコア（cache/<skill>/_cache.json に quality_score 1-5 で自己採点）を物理的に分けて置く。同じ問いに対して 2 回目以降の出力が安定する仕組み
🔒 PreToolUse hook ツール実行前に走るガード。.env / .git/ / settings.local.json 等の保護対象ファイルへの書き込みや、rm -rf * のような破壊的 Bash コマンドを実行前にブロックする（protect-files.py / protect-bash-sensitive.py）
📄 Output スキルが生成するレポート群（output/information/YYYY-MM-DD/index.md 等）。毎朝 04:00 に daily-briefing が自動で書き出す日次レポートが代表例。ここがユーザーが実際に読むアウトプットの本体
🔍 SubagentStop hook サブエージェント終了後に走る検査。auditor の出力を grep ベースで機械的に走査し、CL FAIL（チェックリスト違反）を .claude/logs/ に追記する。auditor の判定を親 Claude の都合で握り潰さないための「自動化された目」
🧑‍⚖️ Auditor サブエージェント 親 Claude とは独立した会話セッションで動く Read-only の監査人（3 体）。axis-a-auditor（軸 A 専用・CL1-CL11）/ pdca-auditor（軸 B-D・CL_PDCA_1-8）/ habit-auditor（軸 C 専用粒度・CL_HABIT_1-8）が分担。Write / Edit ツールを持たせない設計で監査と修正を物理分離
📚 knowledge-vault 共通ナレッジ層（23 エントリ）。書籍・記事・動画のハイライトを 3 点要約で蓄積。各スキルから双方向に読み書き — ただし軸 A スキルだけは「emit のみ ALLOWED / read FORBIDDEN」 の片方向接続（決定論化のため・後述の 5 重防御の中核）

矢印の読み方:

  • 実線 →: 通常の必須経路（ユーザー → SKILL → Output → SubagentStop → Auditor まで止まらず流れる）
  • 点線 -.emit/read.->: vault との双方向フロー。軸 B-D スキルは双方向だが、軸 A スキルだけは Skill -.emit.-> Vault の片方向のみ（read 経路を構造的に遮断する設計）

設計の核: 監査人（Auditor）を独立した会話セッション（subagent）で動かし、親 Claude が自分の出した結論を自分で監査する循環を断つ。決定論化対象（軸 A）の参照パスは agent description + system prompt + tools 設計 + SubagentStop hook matcher の 4 重ガードで、他軸（軸 B-D）の auditor から構造的に遮断する。

4 軸の運用負荷バランス

output/information/YYYY-MM-DD/ 配下に出力されたレポート本数を軸別に集計したのが以下（直近 1 ヶ月・主出力先での実測カウント）。各レポートはそれぞれ生成所要時間が違うため本数 ≠ 工数だが、運用負荷の「向き」を粗く把握する目的では十分使える。

軸 A（決定論化が必要な領域）  [████████████████████          ] 18 本（軸 A 判定レポート）
軸 B（外部交渉・媒体運用領域） [██████                        ]  5 本（KW設計・草案・公開記事 等）
軸 C（日次行動形成領域）       [██████████████████████        ] 20 本（daily-briefing index.md 連日）
軸 D（知識ストック領域）       [██████████                    ]  9 本（vault エントリ + 原則拡張）
                                                              ─────
                                                              計 52 本（直近 1 ヶ月の主出力カウント）

⚠ 上記は 2026-04-19 〜 2026-05-06 の output/ 配下出力本数の実測カウント。本数当たりの所要時間は軸 A（CL1-CL12 通過と Tier A/B 検証で 1 本 30 分超）が重く、軸 C（テンプレ自動生成で数分）が軽いため、工数に換算すると軸 A の比率はさらに上がる。「決定論化が必要な領域は重く（願望混入を防ぐコストを払う）」「外部交渉系は軽く（実行は休暇期間に集中）」のように軸ごとに濃淡をつけるのが個人 PDCA の現実解。

設計判断 1: 4 軸 KGI を pdca/objectives.md 1 本で永続化した理由

4 軸（テーマと KGI は伏字・構造のみ公開）

軸 領域の性質 KGI（具体値・期日は伏字）
A 決定論化が必要な領域（願望混入で壊れやすい） 20XX-XX-XX までに長期目標値
B 外部交渉・媒体運用領域（市場価値の積み上げ） 20XX-XX-XX までに長期目標値
C 日次行動形成領域（達成率指標） 20XX-XX-XX までに行動率 ≥ XX%
D 知識ストック領域（資格・更新サイクル） 20XX-XX-XX までに資格更新完了

プライバシー配慮で軸の具体テーマと KGI 数値はすべて伏字。読者は自分にとっての 4 軸（家族 / 副業 / 健康 / 学習 等、自由に置換）に当てはめて読んでほしい。重要なのは「4 軸を 1 ファイルに集約して途中変更を抑止する」という構造のほう。

なぜ 1 本のファイルにまとめたか

  • 一覧性が効く: KGI / KPI / KDI を 1 ファイルで見渡せないと、人は途中で目標そのものを動かしたくなる。1 ファイルに並べておくだけで「目標を変える」誘惑が構造的に減る
  • 長期目標と中間 KPI を 1 つの階層図に並べる: 5 年 KGI → 年次 KPI → 月次 KDI を上下に並べておくと、月次の判断が KGI からズレた瞬間に目で気づける
  • habit-mindset の knowledge_core.md 章構造と双方向で参照する: 根拠論文と KGI を相互リンクし、「なぜこの KPI を追っているのか」の出典に最短パスで辿りつけるようにしておく

設計判断 2: スキルに「学習機能」を持たせる 3 階層

スキルを使い捨てにしない仕組みとして、知識の「置き場所」を 3 段階に分けている。動かない手順は 1 階に、ゆっくり育てる知識は 2 階に、実行のたびに書き換わる履歴は 3 階に — というイメージ。

階層 役割 例（実体値・2026-05-06 計測）
1 不変の手順・チェックリスト（書き換えない） SKILL.md / CL1-CL11 等の判定リスト
2 半永続の知識（月単位で育てる） references/ 4 分割 = 389 行（claude-code-research）/ knowledge_core.md = 770 行（habit-mindset・履歴章・補助章を分離した後の本体）
3 実行履歴 + 品質スコア（実行のたび書き換わる） cache/<skill>/_cache.json（11 スキル中 11 スキルで稼働・quality_score 1-5 で自己採点）

効果（実測値ベース・3 つの観点）

階層 2/3 を整備すると、同じ問いに対して 2 回目以降が安定する。実体ファイルから取れる数値で示す。

① 毎日読む行数のトークン削減（階層 2 = knowledge_core.md 圧縮実績）

ここでいう「コアロード」= daily-briefing が毎朝必ず読み込む行数。読む量が減るほど 1 セッションあたりのトークン消費が減り、推論のレスポンスも速くなる。

habit-mindset の knowledge_core.md を別ファイルに物理分離して、章別に「ここからここまで読む」を指定できるようにした結果、daily-briefing が毎日読む行数が下表のとおり減った。

フェーズ knowledge_core.md 全体 コアロード（毎日読む行数） 削減
圧縮前 959 行 583 行 —
Phase 1（履歴章を _history.md に分離） 880 行 583 行（変化なし） 全体 -8.2%
Phase 2（中根拠 27 項目を _ext.md に分離） 758 行 498 行 コアロード -14.6% / 全体 -21.0%
現状（強根拠補強後・2026-05-06） 770 行 510 行（全体の 66.2%） daily-briefing が読まない章を 33.8% に圧縮

② キャッシュ採点による再生成抑制（階層 3 = quality_score）

11 スキル全てで cache/<skill>/_cache.json に quality_score（自分の出した結果を 1-5 で自己採点する数字）を残す運用。実体カウント:

  • 採点済みキャッシュの品質分布（採点済み 37 件 + 未採点 1 件 = 計 38 件・採点累積している 9 スキル分）: 5（最高評価）= 34件（91.9%）・3-4（再利用 OK）= 2 件・1-2（自動無効化対象）= 0 件（=過去に検出された 1件は強制再生成で解消済み・下記）・null（次回採点予定）= 1 件
  • 実行頻度の高いスキルの 5 比率: claude-code-research = 14/14（100%）・system-optimizer = 3/3（100%）（執筆時点での実例）
  • 自動無効化が動いた事例 1 件: 過去のレポートで quality_score: 1 が検出 → 翌日強制再生成 → CL 全項目 pass で 5に更新（再生成後の値が上の 34 件に含まれる）
  • 再利用ヒット: 軸 A スキルのキャッシュに reuse_count 8 回

ルール: quality_score 1-2 = 自動無効化（次回使わない）/ 3-5 = 再利用 OK / null = 未採点なので使ったあとに採点する

③ vault との双方向参照（階層 2 ⇄ 共通ナレッジ層）

書籍ハイライトを 3 点要約で knowledge-vault に集約し、knowledge_core.md の該当章と双方向リンクする。

  • vault 総エントリ: 23 件
  • knowledge_core_section フィールドで knowledge_core_ext.md と双方向リンクされたエントリ: 9 件（kaizoudo / essentialism / atomic-habits / smartphone-brain 等）
  • 効果: 同じ書籍を二重保存していた箇所を解消

「2 回目以降が深くなる」と言える根拠

  • 生成効果: 自分で出力した知識は記憶に残る（Hattie & Donoghue 2021 のメタ分析・242 研究 / 169,179 名）。スキルが cache に出力 → 次回 cache を再利用 → 補正された出力が再び cache を上書き、というサイクルが生成効果と同じ働きをする

設計判断 3: 軸 A の数値判定スキルだけ「決定論化」した理由

ここで言う「決定論化」は、外部の客観データだけを根拠にして判定が決まる、揺らがない状態にしておくこと。Claude の推論で結論が振れないように、入力経路と監査経路を仕組みで縛る、というイメージ。

軸 A は外部の客観データに依存して判定する領域（=願望や目標が混入すると判断が壊れる領域）。本記事では具体テーマを伏せているが、読者の文脈では「KPI ダッシュボード / 競合データ / 業績指標 / 外部 API のメトリクス」など、外部データと願望がぶつかる領域に置き換えて読んでほしい。

5 重防御の構造

  1. CL1-CL11 チェックリスト（投稿時点で 11 段階・本記事公開時点では CL12 まで拡張 = 「上限額 ÷ 残期間」型の根拠ゼロ計算をブロックする項目を追加）
  2. Tier A/B ホワイトリスト（Tier C 以下のソースを構造的に排除）
  3. vault → 軸 A スキルの read を FORBIDDEN（一方通行の emit のみ許可）
  4. axis-a-auditor サブエージェント（CL FAIL を grep ベースで自動検出）
  5. auditor 分離原則（pdca-auditor / habit-auditor は軸 A のファイルを読まない設計を強制）

なぜここまでやるか

  • 軸 A の KGI（5 年先の特定日付までに長期目標値を達成する、というイメージの長期ゴール ─ 実数値は伏字）はあくまで願望・目標であって、判定の根拠ではない。年次の見直しはするが、週次・月次・日次のレポートはこの数値を参照しない（PDCA の基本原則「目標を変えるより手段を変える」とも合う）
  • vault は広い受け皿で、書籍ハイライトの手動投入 + 他スキルからの自動書き出し + 低 tier の補助情報も同居する。Tier A/B ホワイトリスト固定の「揺らがない判定」が、ここを介して崩れていく
  • 一度汚染が起きると過去レポートを遡って直す必要が出る。これが地味に重い

遠回りした話 — 何度も「願望が判定に混ざる事故」を起こして辿り着いた "5 重防御"

この個人 PDCA 自動化基盤を 1 ヶ月運用するなかで、着手当時の自分に戻れるなら避けたい遠回りが 2 つある。これから同種の基盤を作る読者が同じ失敗を踏まずに済むよう、設計上の何が間違っていて、どう直したかを 2 つ抜き出しておく（軸 A 関連の固有名詞・数値は伏せる）。

遠回り 1: 「全スキル共通の知識ボックス」を作って、揺らいではいけない判定スキルにまで直結させた

最初は「読書メモも、各スキルの作業中の気づきも、ぜんぶ同じ場所に放り込んで、必要なときに全スキルから自由に取り出せたら便利」という素朴な発想で、共通の知識ボックス（vault）を作り、軸 A の判定スキルからも自由に出し入れできるようにした。家でいうと「リビングの真ん中に置いた、全員が物を入れたり取り出したりする雑多な棚」 のイメージ。これが、客観データだけで判断したい軸 A の判定スキルにとっては致命的だった。

  • 何が起きたか: 軸 A の判定レポートが、「外部の計画書にメモしただけの机上の数字」を公式データと同じ確度で扱い始めた。具体的には、「目標の上限額を残り期間で単純に等分しただけの数字（実際の裏付けはゼロ・"こうなったらいいな" の機械割り算）」がそのまま判定の根拠に採用され、「だから今月はこの行動をやろう」という次のアクションまで自動でレポートに書かれた。「願望の数字」と「判定に使っていい客観の数字」の境界線が、知らないうちにジワジワ曖昧になっていったのが本質
  • どう直したか: 「共通の棚 → 判定スキル」の取り出しを 完全禁止にし、「判定スキル → 共通の棚」への書き込みだけ一方通行で許可。さらに「共通の棚から混入してないか」のチェック項目（CL11）を判定スキルに足し、監査エージェントが grep で違反を自動検出するようにした。後から「上限額 ÷ 残期間」型の根拠ゼロ計算の混入もブロック（CL12）し、チェックリスト + 自動検出 + 監査エージェントの三重ガードまで発展させた

→ ここが「設計判断 3 の 5 重防御」に行き着いた直接のきっかけ。「何でも受け入れる広い棚」と「客観データだけで判定したい狭いスキル」を分けないと、判定はジワジワ願望に侵されるということを、身をもって学んだ。

遠回り 2: 「全部きっちり自動化」を目指したら、毎朝のレポートが「軽い罰」として効き始めた

PDCA 4 軸ぜんぶに KGI / KPI / KDI を置いて、毎日の達成率を機械的に計算し、⭐で連続記録まで可視化する仕組みを作った。ダッシュボードとしては見栄えがいい。でも実際に運用してみると、毎朝のレポートが「今日もダメでしたね」と静かに通告してくる存在に変わっていった。

  • 何が起きたか: 数日続けて目標に届かない時期に、レポートが「軸 X の達成率 30%・3 日連続未達」のような未達をそのまま突きつける表現を毎朝出し始めた。確かじゃない数字を毎朝目に入れること自体が、地味だけど確実に体力を削る。気づくと「数字を上げるための行動」が、本来の目的（=仕組みに気持ちよく続けさせてもらうこと）を上書きしていた。本当は手段 (KPI/KDI) を直すべき場面で、自分の体調や気力を無理に引き上げに行く、典型的な本末転倒
  • どう直したか: pressure_relief_mode: true の 1 行で、すべての数字を 「ペース調整中 / Sカーブ停滞期（=成果が出る前の踊り場）」のような中性表現に一括で置き換える退避路を最初から組み込んだ。3 日連続未達でも警告は出さず、「今日は 1 つだけでもやってみよう」のような穏やかな 1 行リマインドだけに切り替え。「未達」「失敗」「サボり」のような責める表現は hook と SKILL.md レベルで 使用禁止ワードとして登録。さらに「意図的に休む日」を事前宣言できるフラグも足し、休んでも連続記録が切れない仕組みにした

→ Atomic Habits の 「仕組みで続けさせる」 と PDCA の 「達成率を責めずに手段を直す」 が合流して、「緩める仕組みを最初から組み込む」 が個人 PDCA の必須条件だと気づいた瞬間。自動化基盤は「やめさせない設計」と「責めない設計」の両輪で初めて回り続ける。

効いた対策 / 効かなかった対策（運用 1ヶ月の振り返り）

✅ 効いた対策

  • PDCA × Atomic Habits の合流点を 1 ファイルに集約: pdca/objectives.md に 4 軸 KGI を永続化したことで、「途中で目標を変える」誘惑が構造的に減った
  • 監査人（auditor）を独立した会話セッションに切り出した: 親 Claude が自分で書いた軸 A レポートを自分で監査する循環を断ち、会話文脈を切り分けた決定論化を実現
  • 「学習させてはいけない領域」を明文化: 願望や目標（KGI の長期数値）を判定の根拠にしないよう、vault から軸 A スキルへの読み込みを仕組みで禁止
  • pressure_relief_mode を最初から組み込んだ: 疲弊の兆候を感じたときにすぐ対処できる退避路があると、「仕組みごと捨てる」前に「数値表示を止める」だけで踏み止まれる

❌ 効かなかった / もっと早くやればよかった対策

  • CL チェックリストを文書化せず Claude の自主判断に任せていた時期: 軸 A の禁止ワード（行動を煽る誇張表現）がレポートに混入する事故が頻発し、禁止ワード CL（CL チェックリストの 1 項目として禁止語のリストを持たせた）+ 機械検出 hook の追加で初めて止まった
  • 「全部自動化」を目指して 1 日のタスク数を増やしすぎた時期: streaks.json の達成率が下がる → Claude がプレッシャー表現を出す → 余計に重く感じる、の悪循環。毎日 1% 分の小さい行動を曜日でローテーションする方式 + 達成率 80% 以上で十分とする緩和ルールに切り替えてから安定した
  • MEMORY に軸 A の具体数値を残してしまった時期: SessionStart で毎回読み込まれる auto-memory（=セッション開始時に毎回読み込まれる文書群）に過去の機械算出値が残っていて、それが各セッション冒頭で再注入される経路ができていた。具体的には、外部計画書経由で塞いだはずの「上限値 ÷ 残期間」由来の分割値が、別ルートの auto-memory に「未来計画」として残っていた。塞ぐ層が違うだけで、走り抜けるルートは同じ形だったため、SSOT 原則を「外部計画書を参照させない」から「セッション開始時に毎回読まれる文書には、具体数値を書かない」へ広げた

Claude Code 個人 PDCA 運用 3 原則（科学的根拠ベース）

1 ヶ月の運用ですべての軸に共通して効いた原則を 3 つに絞って整理する。Claude Code 以外の個人 PDCA ツール（Notion / Obsidian / 紙手帳）にも転用可能。

  • 自動化と手動の境界を意識的に引く（決定論化の対象を絞る）: すべてを Claude の判断に任せず、「願望が混入すると壊れる領域」だけを構造的にロックする。軸 A（決定論化対象）= 仕組みでロック、軸 B-D（行動形成・知識ストック）= Claude 推論を活用、の二段構成にした
  • 連続記録は段階表彰で動機づけする: ⭐⭐⭐🏆 で日数の階段を可視化すると、Atomic Habits 由来の「habit stacking（既存の習慣に新しい習慣を積み重ねる手法）」と同じ効果が得られる（生成効果 = 自分で出力した内容は記憶に残りやすい）
  • 緩める仕組みを最初から組み込む: pressure_relief_mode: true の一行で退避できる構造を初日から作っておく。PDCA の 「達成率を責めずに手段を直す」 + Atomic Habits の 「仕組みで続けさせる」 を、たった 1 行のフラグに圧縮するイメージ

出典: 安川康介『科学的根拠に基づく最高の勉強法』KADOKAWA, 2024 / James Clear "Atomic Habits"

使用ツール一覧（個人 PDCA 自動化基盤の構築で使った技術スタック）

Tier 1（必須・公式）

リソース URL 用途
Claude Code（CLI） https://docs.claude.com/en/docs/claude-code スキル / hooks / agents の本体
Anthropic Engineering Blog https://www.anthropic.com/engineering スキル設計のベストプラクティス参照
Claude Agent SDK https://docs.claude.com/en/api/agent-sdk サブエージェント設計の理論補強

Tier 2（補助・有用）

リソース 用途
MCP server（filesystem / fetch / 外部時系列データ系） スキル間連携・外部データ取得（具体名は伏字）
Obsidian（local vault） knowledge-vault と物理的に同一ディレクトリ・MD ベースで二重化
Windows Task Scheduler daily-briefing の毎朝 04:00 自動起動（具体スクリプトパスは非公開・OAuth refresh token を扱うため）

Tier 3（運用上の盲点）

MEMORY と SSOT の使い分け

  • MEMORY/（auto-memory = セッション開始時に毎回読み込まれる場所）には、抽象的な意思決定方針のみ書く（軸 A の具体数値・固有名詞・アカウント系識別子は禁止）
  • 軸 A の具体数値の SSOT（=正本となる 1 箇所）は 日付付きレポート 1 本に集約する（output/.../YYYY-MM-DD/...report.md 形式）
  • 計画書・README は SSOT を参照する側であり、SSOT を上書きしない（「事実状態の SSOT 原則」）

→ この使い分けが守れないと、過去の機械算出値が SessionStart 経路で何度もレポートに再注入される事故が起きる。

まとめ — 読者の次の一手 3 つ

  1. 今日できる 1 歩: pdca/objectives.md 相当の「自分の KGI 4 軸」を A4 1 枚で書いてみる（5 分・期日と数値だけで OK）
  2. 週末にやる中サイズの 1 歩: Claude Code の .claude/skills/ に最初の 1 スキルを作る（既存 SKILL.md (= 階層 1) を 1 つ模写し、references/ (= 階層 2) と cache/ (= 階層 3) の 2 つの置き場を追加）
  3. 1 ヶ月先を見据えた 1 歩: hooks と auditor で「自分が信じたい結論を強化しないための監査機構」を組む（PreToolUse + SubagentStop の 2 events から始めるのが最小構成）

参考文献（一次情報のみ）

Discussion