lean-mode スキル

目的と基本思想

トークン消費の主因は「賢さ不足」ではなく構造的な無駄である：同じコンテキストを複数エージェントが各自fetchする、timeout後に即リトライして連鎖する、同内容のファイルを複数形式で生成する、承認前に保存して上書きし直す、全件並列で探索する。これらを削れば、品質はそのままで30〜60%削減できることが実績で分かっている（ブログ生成 400-500K→150-200K、ohayo 120K→70-90K）。

逆に、品質側を削る節約は必ず高くつく。2026-05-06、「トークン節約」を理由に主担当agentをスキップして直書きした結果、一人称混在・フッター抜けが発生し、やり直しで244K消費した（最初から正しくやれば170K以下）。アーカイブgrep（5K以下）をスキップした結果、ブログの決定的ナラティブが欠落した実例もある。

節約＝無駄の除去。品質工程の省略は「節約」ではなく「品質を捨てて後で倍払う」こと。

品質フロア（節約モードでも絶対に削らない）

1. 安全ゲート: content-fact-checker → content-risk-reviewer（発信物では必須。CLAUDE.md明文ルール）
2. 主担当エージェント: blog-writer / sns-content-creator 等。直書きフォールバック禁止
3. アーカイブgrep: 草川の制作物・実績を扱うタスクでの過去発言確認（main側5K以下で済む）
4. D1完全保管・D2承認後保存: ドラフト全文保存、草川承認→修正→1回でNotion保存
5. 草川の承認・目視ステップ: 自動化で飛ばさない

ユーザーが明示的に「ファクトチェック不要」「直書きでいい」と言った場合のみ例外。その場合も何をskipしたか実行前に明言する。

5大レバー（すべてのタスクに適用）

L1. 事前コンテキスト埋込（-30〜50K）

main側で共有コンテキスト（voice-dna・元素材・仕様・DB ID）を1回だけ読み、各エージェントのprompt本文に直接埋め込む。エージェントに自前で再fetchさせない。統一仕様（字数・構成・出力パス）もmain側で確定してから渡す。

L2. 探索はサンプリング段階方式（-30K〜）

フォルダ・DB・過去ログの探索は、全件並列で開けずに1〜2件サンプル→傾向推定→必要時のみ追加。Notion/DBクエリは必ずfiltered view・pageSize制限・日付フィルタを使う（フィルタなしviewは50件超を引きずり込む）。ローカルgrepできるもの（議会アーカイブ等）はMCPより先にgrep（_index/の.txtキャッシュが最速）。

L3. リトライ規律（-25K〜）

• timeout ≠ 失敗。Notion update等のtimeout後の即リトライ・即verifyは禁止（サーバ側では適用済みのことが多く、古いキャッシュで「未反映」と誤判定→再送信の連鎖になる）
• 同じページのfetchは1セッション1回。取得した本文を使い回す
• リトライ上限2回。3回目はやらず、別経路（ローカル退避＋手動アクション提示）に切り替えるか「次回に再確認」と1行報告して先へ進む

L4. 1ソース・1回保存（-30K〜）

• 同内容を別ファイル形式で複数生成しない（結合版＋分割版×2、のような多重出力禁止）
• 設計メモ・design docは目的達成に直接必要な情報だけ（目安3,000字以内）
• Notion保存は草川承認後に1回で完結（v1保存→v2上書きの往復は80K+の無駄）
• 字数規定は生成時に厳守させる（超過を草川判断に投げると二度手間）

L5. 完成形渡し（-30〜40K）

notion-saver等の保存系エージェントには、DB ID・properties JSON・本文blocksをmain側で組み立てて丸ごと渡す。保存先の探索・schema調査をエージェントにさせない。

実行フロー

1. タスク分類（発信物生成／定型ルーティン／調査・リサーチ／その他）
2. 適用レバー宣言: 実行前に「L1・L3・L5を適用します」程度の1〜2行で宣言（長い計画書は書かない — それ自体が浪費）
3. 場面別リファレンス参照:
   • 発信物（ブログ・SNS・動画）→ references/content.md を読む
   • 定型ルーティン（ohayo/oyasumi/nichijo）→ references/routines.md を読む
   • 調査・リサーチ → 下記「調査タスクの規律」だけでよい（リファレンス不要）
4. 実行
5. 完了報告: 最小サマリ＋概算消費トークン＋目標値との比較を1〜2行で（KPI管理のため）

調査タスクの規律（D5準拠）

リサーチ系エージェント（policy-researcher / kameyama-researcher 等）を呼ぶときは指示文に必ず含める：

• 「依頼スコープに直接答える資料に限定」
• 「voice-dna・3pillars等のローカル既存資料は明示依頼時のみ参照」
• 「tool_uses 30回以内目安」

並列本数はデフォルト2本（事実調査＋先進事例）。3本目以降は必要性を吟味してから。過去発言抽出はオプション扱い（自分史・実績まとめ記事に限定）。

出力の規律

• 中間ナレーションは要点のみ。同じ説明を繰り返さない
• 完了報告は機能別に区切らず、最小サマリ＋次の一手だけ
• 「参考までに」の長い付録・全選択肢の網羅列挙をしない

目標値（KPI）

タスク	目標	旧実績
ブログ＋SNSフルセット（fact-check込み）	130〜170K	400-500K
同上（fact-check upstream済）	90〜130K	—
ohayo標準	70〜90K	120K
設計・整理セッション	〜100K	100K超

完了時に実測（概算）と目標の差を報告し、大きく超過した場合は原因1行を添える。超過原因が繰り返しパターンなら、memoryのfeedbackファイル更新を提案する。