期間限定の賢いモデルに「作品」ではなく「土台」を作らせた一日 — skill棚卸し・記憶の発掘・検証機構の磨き込み 作業ログ

期間限定で普段より賢いモデル（Claude Fable 5）が使えるとき、何に使うか。最初は成果物づくりに使っていました。原稿、LP、デザイン。たしかに初稿の質が一段上がります。でも途中で、いいたかゆうたさん（@yutaiitaka）の記事 「前回Fable5を使って一番よかったのは、成果物づくりじゃなかった」 に考えを変えられました。私が受け取った要点は「消えるものより、残るものに使う」。

「何をすべきか」の整理は、ぜひ元記事を読んでください。この記事はその提案に乗って、実際に一日で全部実行してみた側の実測レポートです（人力ではなく、並列エージェント群を指揮しての実働一日です）。数字と、うまくいかなかったところも含めて書きます。

前提: どれくらい散らかっていたか

数ヶ月使い込んだ相棒の環境には、メモリ（AI に覚えさせた申し送りメモ）が 205 ファイル、skill（AI に渡してある作業手順書）が 64 個ありました。1つ1つはその時々の学びとして正しく書かれたものです。問題は総体で、同じルールが複数箇所に書かれて片方だけ更新され、古い指示と新しい指示が両方生きた顔をしていました。

やり方: 読む係・疑う係・直す係を分ける

この分量をひとつのコンテキストに読ませると、うちの場合は後半で精度が落ちました。そこでワークフローを組み、役割を分けました。

1. 抽出: メモリと skill 全件をバッチで読み、各ファイルの「主張」を構造化して吸い上げる
2. 分析: 重複・矛盾・陳腐化の3つのレンズで横断的に洗う
3. 敵対的検証: 別のエージェントが「反証するつもりで」実ファイルに当たる。不確実なら棄却
4. 適用: 検証を生き残った項目だけ、書き込み係が直す

結果の実数。抽出 293 項目（内訳: メモリ 203 ＝ 205 ファイルから索引と退避台帳の 2 つを除く / skill 64 / グローバル設定と参照ドキュメントのセクション 26）、所見 109 件、敵対的検証を生き残ったのは 96 件。13 件は「要約の読み違い」「進行中の案件を勝手に完了扱い」として反証されました。この 13 件を素通しにしていたら、棚卸しのつもりで新しい間違いを植えるところでした。疑う係は、分けるほど効きました。

生き残った 96 件の所見は、重複をまとめて 65 の変更に統合し、すべて適用しました。中身は「正本をひとつ決めて、他はそこへの案内板（ポインタ）にする」「トリガーが衝突する skill の棲み分けを description に書く」「実在しないパスやフラグを実測で直す」。地味です。地味ですが、この地味さが毎日の初稿に効きます。

過去セッションからの発掘

いいたかさんの記事でもうひとつ薦められていた「過去セッションを振り返らせて、学びをメモリに残す」もやりました。直近2週間の大きめのセッションログ 30 本をサンプリング読みさせ、候補 75 件を既存メモリとの重複チェックと敵対的検証でふるいにかけて 57 件を収載しました。実体は新規メモリ 25 本と、既存 23 本への追記です（学びが同じファイルに相乗りするぶん、件数とファイル数はずれます）。

面白かったのは「同じ学びが複数セッションで繰り返し出てくる」ものほど価値が高いことです。あるドメイン知識は、4 つのセッションでそれぞれ導き直されていました。書き残されなかったせいで、同じ理解に 4 回たどり着き直していたわけです。

検証の仕組みを「弱いモデルでも回る」形に磨く

レビュー・検証系の skill とエージェント定義、計 7 本に 40 の改善案を出させ、敵対的審査で 33 に絞って適用しました。磨きの方針はひとつだけ。賢いモデルの暗黙判断に頼っている箇所を、弱いモデルでも同じ品質で回る明示手順に変えること。

• 合否判定を「自己採点」から exit code（テストが通ったか落ちたかの機械判定）に固定する
• 検証が失敗した時の分岐（環境起因か、本物のバグか）を仕分け表にする
• 「よしなに確認」を1コマンドに置き換える

期間限定モデルの賢さは消えます。でも、賢いモデルに書かせて検証を通した手順書は残ります。

重い仕事を「深読み係と実装係の分業」に型化する

これは usedhonda さん（@usedhonda）の 投稿 からの輸入です。賢いモデルには実装させず、コードベースを深く読ませて、実装担当モデルに渡す指示書を作らせるという分業設計で、プロンプトの全文と設計意図は元投稿に譲ります。長い指示書を 1 コンテキストで走らせないための再実行の工夫まで設計されていて（ここはぜひ元投稿を読んでください）、これを土台に、うちの環境向けの skill に組み直しました。うち固有の追加は、負債マップの各項目に検証法を必須にしたことと、「検証コマンドが壊れているリポジトリが普通にある」前提を最初の工程に入れたことです。

同じ「重い仕事」枠でもうひとつ。Mike Fishbein さん（@mfishbein）の 5プロンプト集 から「改善ロードマップを、受入基準つきで書かせる」という視点を輸入し、既存プロダクト 6 つぶんのロードマップを横断で書かせました。受入基準を「自己申告でなく外部から判定できる形（コマンドの結果や公開 URL）」に縛ると、ロードマップが願望リストではなく実行計画になります。

仕上げの監査

一日の締めには、@0xwhrrari さんの 「How I set up Claude to actually get work done」（Claude を仕事のシステムとして設定する25項目）をチェックリストにして、自分の環境を監査にかけました。結果は 23 項目が充足、抜けは「全体を1枚で見渡す運用マニュアル」と「効いたプロンプトの置き場」の 2 つ。どちらも今日建てるものではないと判断して、宿題の先頭に積んであります。

正直に書く: 事故は2回起きた

ひとつ。マシン設定を自動同期し続ける仕組み（dotfiles の同期フック）が、作業中のエージェントの編集を黙って巻き戻しました。並行で動く自動化は、長作業の間は明示的に抑止して、終わったら戻す。その手順ごとメモリにしました。

ふたつ。ワークフローへの引数が文字列化される罠を踏み、期待した 24 体のうち 9 体しかエージェントが走っていないのに「正常完了」が返ってきました。肝心のメモリと skill を読む担当のバッチが、黙って 0 件になっていたのです。成果物の数が期待と合わないことから気づけましたが、静かな成功が一番怖い。罠の仕組みはこうです。エージェントの編成表を作るスクリプトに「何体で分担するか」の元になる設定値を渡したつもりが、渡し方の形式の問題で中身が届かず、設定値に頼っていた係（メモリ担当と skill 担当）だけ、人数の計算が壊れて 0 体になりました。設定値に頼らない係と後段の分析・検証の係はそのまま走ったので、全体では 9 体が動いて「正常完了」に見えた——という順番です（技術的には、Claude Code の Workflow に渡した JSON 引数が文字列として届き、undefined 混じりの計算で担当数が NaN → 空配列）。値をスクリプトに直書きする形へ変えて再実行し、この記事の 293 項目からの数字は、すべてその修正後の再実行で取れたものです。「期待したバッチ数と実際に走った数を必ず突き合わせる」も型に入れました。

もちろん事故ゼロが理想で、自動同期の抑止は始める前に仕込んでおくべきでした。それでも失敗を含めて全部ログに残るのは救いで、事故そのものが次に効くメモリになりました。

参考にした投稿への感謝

今日の一日は、X で読ませてもらった4本の組み合わせでできています。いいたかゆうたさんには一日の設計図を、usedhonda さんには深読みと実装を分業する設計を、Mike Fishbein さんには受入基準から書かせる視点を、そして @0xwhrrari さんには、環境監査にそのまま使わせてもらった 25項目のチェックリストを。どれも読んだその日のうちに手が動いた投稿でした。ありがとうございました。

月曜からできる一手

棚卸しの頼み方そのものは、いいたかさんの記事に詳しく書かれています。今日一日の実測から足すとしたら、一文だけ。「直す前に、別の目で1件ずつ反証を試みて」。うちの棚卸しでこの一文がせき止めたものは、上に書いた通りです（新しいチャットを開いて、直す前の提案だけ貼って頼めば「別の目」になります）。

3行まとめ

1. 賢いモデルの一番リターンが大きい使い道は、賢さが要らなくなる環境を作らせることだった — 整えた skill とメモリは、モデルを戻しても効き続ける
2. 棚卸しは「読む係・疑う係・直す係」を分ける — 所見 109 件のうち 13 件は、検証がなければそのまま収載されていた
3. 事故もログもぜんぶメモリにする — 「期待した数」と「実際に走った数」の突合を型に入れる

※この記事は、本文に登場する AI 相棒（Claude）との共同執筆です。何をやるか・何を公開するかの判断は人間側、実行と初稿は AI 側。記事中の数字はすべて手元の実行ログとレポートの集計値に、公開前へもう一度突合を通しています。