Routine Labo 公式LINE特典

Fable 5に投げる
「重い仕事」プロンプト完全版・5選

動画で実演したプロンプトのフル版です。【 】の部分だけ自分の状況に書き換えて、あとはそのままコピペで使えます。

はじめに ─ まずここだけ読んでください

5本共通の使い方

準備(投げる前の3点セット)

  1. Claude Code を最新に:v2.1.170 以上で、/model から Fable 5 を選ぶ(重い仕事のときだけ切り替え、終わったら元のモデルに戻す)
  2. バックアップ:AIに触らせるフォルダは実行前にコピーを取る。失敗しても戻せる状態を先に作る=これが一番大事
  3. 作業フォルダで起動:対象のプロジェクトフォルダで Claude Code を起動してから、プロンプトを貼る

使い方のコツ(ハーネス&ループの考え方)

差し替えルール:プロンプト内の 【 】の部分だけ 自分の状況に書き換え。それ以外はそのままコピペでOKです。

5本のプロンプト

1

業務の棚卸しプロンプト

目安 10〜20分放置でOK 成果物 2ファイル 消費 軽め(読み取り中心)
ねらい:いきなり自動化せず、まず自分の仕事の全体像をAIに整理させる。Anthropic公式が推奨する「振り返り」の手法がベース。
プロンプト ①
あなたに私の業務の「棚卸し」を任せます。いきなり自動化はしません。まず全体像の整理だけを行ってください。

## やってほしいこと
1. このプロジェクトでの過去のやり取り(セッション履歴や作業ファイル)を、サブエージェントを使って振り返り、繰り返し登場するテーマ・作業・つまずきを洗い出してください。
   ※過去のやり取りが少ない場合は、代わりに私に質問して業務を聞き取ってください(質問は一度にまとめて、最大5問まで)。
2. 私の業務を「入力(何を受け取る)→ 処理(何をする)→ 出力(何を出す)→ 人間の判断点(人が決めるべき箇所)」の4要素に分解した業務マップを「業務マップ.md」として作成してください。
3. 業務マップをもとに、自動化・効率化の候補を「効果 × 実現しやすさ」で採点し、上位5件を「自動化候補.md」に提案してください。ただしこの段階では実装しないこと。
4. 各候補には「自動化した場合、うまく動いたことをどう確認するか(検証方法)」を必ず1行添えてください。

## 制約
- 推測で埋めない。わからない箇所は【要確認】と明記する。
- 作成・変更してよいファイルは「業務マップ.md」「自動化候補.md」の2つだけ。他のファイルには触らない。
差し替え基本そのままでOK。特定の業務だけ棚卸ししたい場合は、冒頭に「対象は【◯◯の業務】に絞ります」と1行足す。
ワンポイント出てきた業務マップの「人間の判断点」は消さずに残すのがコツ。全部自動化しようとすると事故ります(動画の⑤参照)。
2

スキル・プロンプト大掃除プロンプト

目安 10〜30分 消費 軽め(読み取り中心) 必須 .claude のバックアップ
ねらい:溜まったCLAUDE.md・スキル・設定をFable 5自身に監査させる。公式も「古いモデル向けの細かすぎる指示は、かえって品質を下げることがある。削除を検討せよ」と明言。
プロンプト ②
私のClaude Code環境(CLAUDE.md と .claude/ 配下のスキル・エージェント定義・hooks・settings)を監査してください。今回は「診断と提案」まで。修正の実施は、私がレポートを確認して承認してからです。

## 背景
古いモデル向けに書いた細かすぎる指示は、いまのモデルには過剰指示となり、かえって出力品質を下げることがあります。その観点で棚卸しをしたいです。

## やってほしいこと
1. 対象ファイルをすべて読み、次の4観点で監査してください:
   (a) 重複・矛盾している指示
   (b) いまのモデルには不要な過剰指示(細かく縛りすぎている箇所)
   (c) 内容が古くなって実態と合っていない記述
   (d) 逆に不足している指示(私が毎回口頭で繰り返していそうなこと)
2. 監査結果を「環境監査レポート.md」に、指摘ごとに「該当ファイル/該当箇所/問題/修正案/影響度(高・中・低)」の形式でまとめてください。
3. 修正案は差分(Before→After)が分かる形で提示してください。まだ適用はしないこと。
4. 最後に「この指示を消すと困る可能性があるもの」も正直に挙げてください。

## 制約
- 環境ファイルの変更は一切しない(レポート作成のみ)。
- 適用は、私がレポートを見て「適用して」と指示してから。
差し替えそのままでOK。監査対象を広げたい場合は1行目にフォルダを追記。
ワンポイントレポートを見て「影響度・高」だけ先に適用→数日使って様子を見る→残りを適用、の順が安全(一気に全部変えると何が効いたか観測できなくなる)。
3

諦めた自動化への再挑戦プロンプト

目安 30分〜数時間の自走 消費 大きめ(自走が長い)
ねらい:過去に挫折した自動化を「スクリプトを直して」ではなく「業務を減らしたい」から丸ごと渡す。公式いわく「最も難しい未解決問題に当てたチームが、最も良い結果を得ている」──難しかったものこそ持ってくる。
プロンプト ③
過去に自動化しようとして諦めた業務があります。以前のやり方の修正ではなく、「この業務を減らす」こと自体をゴールとして、ゼロから設計し直してください。

## 減らしたい業務
【業務を文章で説明。例:毎週のレポート作成。システムAからデータを取り、表計算で整形して、メールで送っている。所要は毎回約1時間】

## 過去の試みと諦めた理由
【例:Pythonスクリプトで途中まで作ったが、ログインまわりのエラーが解決できず放置している。当時のファイルは ◯◯ フォルダにある/何もない場合は「初挑戦です」と書く】

## 進め方(必ずこの順番で)
1. 先に検証ループを作る:実装を書き始める前に「動いたことをどう確認するか」(テスト用データ・確認コマンド・期待する出力)を決めて「検証手順.md」に書いてください。検証手段がないまま実装を積み上げないこと。
2. 過去の試みにこだわらず、いま最適なアプローチを再設計してください(前のコードを直すより、捨てて作り直す方が良ければ、理由を添えてそうしてください)。
3. 小さく作って検証ループを回し、動いたら次に進む。一気に全部作らないこと。
4. 完成したら「README.md」に、使い方/動かなくなったときの調べ方/自動化していない部分(限界)を正直に書いてください。

## 制約
- パスワード・APIキーなどの認証情報は私に聞くこと(コードに直書きしない)。
- 既存ファイルを消す・上書きする前には必ず確認を取ること。
- 完成報告の前に、検証手順.md の手順を実際に実行して、結果を見せること。
差し替え【減らしたい業務】【過去の試み】の2箇所。ここが具体的なほど成功率が上がります。
ワンポイント「何につまずいて諦めたか」を正直に書くのが最大のコツ。AIはそこを最初に潰しに行きます。
4

「一本の流れ」再設計プロンプト

目安 設計の提案まで15〜30分 承認後 に実装
ねらい:バラバラに使っている便利ツール・作業を、入口から出口までの一貫フローに作り直す。コードを書かない人でも「自分の仕事の流れ」を渡せば使える。
プロンプト ④
バラバラに実行している作業を、「入口から出口までの一本の流れ」に作り直してください。

## いまの流れ(手作業でつないでいる工程)
【例:①記事を書く → ②SNS用の要約を作る → ③画像を用意する → ④各サービスに下書き投稿する。いまは各ステップを別々に指示していて、間の受け渡し(コピペ・ファイル移動)が全部手作業】

## やってほしいこと(必ずこの順番で)
1. まず現状の工程をテキストのフロー図に起こし、「どこが手作業か」「どこで情報の受け渡しが切れているか」を可視化してください。
2. 一本の流れとして再設計してください。設計方針:
   - 各工程の出力が、次の工程の入力としてそのまま使えるように、ファイルの置き場所と形式を統一する
   - 人間の確認ポイントを設計に明示的に入れる(全自動にしない。人が確認すべき箇所で止まる作りにする)
   - 途中で失敗しても、どこまで進んだかが分かるようにする(進捗の記録を残す)
3. 設計案を私に見せて、OKが出てから実装してください(スクリプト・スキル・手順書など、私の環境に合う形を提案すること)。
4. 完成したら、流れ全体を1回通しで実行して見せ、各工程の成果物を確認できるようにしてください。

## 制約
- 外部サービスへの投稿・送信は、必ず「下書き」「確認待ち」で止めること(勝手に公開・送信しない)。
- 通しの実行はテスト用の題材で行うこと。
差し替え【いまの流れ】。工程は箇条書きで雑に書いてOK。「どこが面倒か」を添えるとさらに良い。
ワンポイント一番価値があるのは2の設計方針の3つ。受け渡しの統一・人間の確認ポイント・進捗の記録が入っていれば、流れは後からいくらでも育てられます。
5

QA監査プロンプト(事故らない半自動の要)

目安 10〜20分 用途 ①〜④の仕上げに毎回
ねらい:完全自動ではなく「事故らない半自動」へ。作った本人(AI)に自己チェックさせず、まっさらな別のAIに監査させる。公式も「新しい目(fresh context)の検証は自己批評より強い」としています。
プロンプト ⑤
ここまでの作業(または【監査したい対象:例)さっき作ってもらった自動化スクリプト一式】)を、「作った本人とは別の目」で検証してください。

## やってほしいこと
1. 新しいサブエージェントを「検証担当」として起動し、実装の経緯を知らない前提で、ゼロから検証させてください。
2. 検証担当への指示には、必ず次を含めてください:
   - 「完了しました」という報告を鵜呑みにせず、実際のファイルの中身とコマンドの実行結果に照らして確認すること
   - 「動くはず」ではなく、実際に動かして確認すること(実行できるものはすべて実行する)
   - 見つけた問題は、再現手順つきで報告すること
3. 検証結果をもとに、この種の作業の「QAチェックリスト.md」を作ってください。次回から使い回せる形にすること。
4. チェックリストは「AIが自動で確認する項目」と「人間が最後に目で確認すべき項目(最後の5%)」に分けて書いてください。

## 制約
- 問題が見つかっても、勝手に修正しない。まず報告し、修正は私の指示を待つこと。
- 検証で外部への送信・公開・削除が必要になる場合は、実行せずに手順の提示だけにすること。
差し替え【監査したい対象】のみ。直前の作業を見せたい場合は消してそのままでOK。
ワンポイントこれが動画で言った「最後の5%は人間」の実装。チェックリストの「人間が確認すべき項目」だけは、面倒でも自分の目で見てください。ここを守る限り、大胆に任せても事故りません。

よくある質問

Q.枠(50%)が心配です
①と②は読み取り中心なので比較的軽め、③④は自走時間が長いので消費大きめです。残量が少ない週は①②⑤だけでも十分に価値があります。
Q.途中で止まった/変な方向に行った
遠慮なく止めてください。「いまの方針だと◯◯が困る。△△の方向で」と一言足して再開すれば軌道修正されます。ダメだった原因を足して投げ直すのが一番の上達法です。
Q.Fable 5が使えなくなったら無意味?
いいえ。この5本が作るのは「業務マップ・検証手順・チェックリスト・一本の流れ」という残る仕組みです。作った後は普段のモデルでも回せます。