結論から言うと、Claude Codeで記事を書くとき、毎回プロンプトを打つのをやめた。/goalっていうコマンドに「ビルドが通るまでやって」と一言投げたら、1ターン・364トークンで勝手に終わって、勝手に止まった。料金が青天井になりそうで自動化を避けてた自分が、一番びびってた部分が拍子抜けするほど軽かった。その話を書く。
この記事でわかること
/goalが何をするコマンドで、何を解決するか- 料金が怖い人向けに「実際いくらかかったか（トークン数）」を先に出す
- 読み終えたら、そのままコピペで試せる安全なコマンドを置いておく
Claude Codeを使って文章を執筆している副業ブロガー向けの記事。難しいエンジニア用語はなるべく避けて書く。
記事概要図
毎回プロンプトを打つのが、地味にしんどかった
副業でブログを書いている。平日は会社員、子育てもあるから、動けるのは週末だけ。その限られた時間で、Claude Codeに記事を書かせたり、構成を直させたり、公開前のチェックをさせたりしている。
ありがたい仕組みなんだけど、ずっと引っかかっていたことがある。毎回、自分でプロンプトを打っている。「ビルド通った？」「frontmatter見て」「公開前のチェックやって」と、同じようなお願いを手で何度も投げる。一回叩いて一回返ってくる。また叩く。この往復が、地味に時間と気力を食う。
しかも一番怖いのが、AIが「できました」と言ったのを信じて記事を出したとき。過去に一度、設定ファイルの書き方をひとつ間違えたまま公開して、サイトが丸ごと更新されなくなったことがある。新しい記事を出したつもりが、Webには前のままの状態が残り続ける。URLを開いても中身が出ない。原因に気づくまで、しばらく放置してしまった。未完成の制作中ページを誤って公開して、すぐ引っ込めたこともある。
AIに「やった？」と聞いて、AI自身に「やりました」と答えさせる限り、この「やったつもり」は消えない。そう感じていた。
実はこれ、自分だけが感じてた違和感じゃなかった。Claude Codeを作ったBoris Chernyという人が、ある場で「もうClaudeにプロンプトは送らない。プロンプトを送るのはループの方。自分の仕事はループを書くことだ」と言っている。別のAIエージェントを作っている人も、まったく違うルートで同じ結論にたどり着いていた。手で毎回お願いするのをやめて、回し続ける仕組みを作れ、という話。
料金が青天井になりそうで、ずっと避けてた
じゃあ自動化すればいいじゃん、という話なんだけど、ここでブレーキがかかっていた。料金が怖かった。
AIを使った自動処理って、放っておくと裏で動き続ける。何ターンも勝手に回る。それってつまり、知らないうちに使用量がどんどん積み上がるってことだよな、と。残高が青天井で増えていく絵が頭に浮かんで、ずっと手を出せずにいた。週末しか見られないのに、平日の間に勝手に暴走してたら、と思うと余計に。
でも、/goal の仕組みを調べてみて、少し見方が変わった。
/goal は「達成したい状態」を書くと、それが満たされるまでClaudeが自動で作業を続けてくれるコマンド。ポイントは完了したかどうかの判定。これを、作業した本人（高いモデル）ではなく、別の小さくて安いモデル（Haiku）が裏で確認する仕組みになっている。「条件は満たされた？」をその安いモデルが見て、ダメなら続行、達成なら自動で止める。
つまり、一番コストを心配していた「ちゃんと終わったかのチェック」部分は、そもそも安いモデルが担当している。判定のために高いモデルをぐるぐる回しているわけじゃなかった。これは想像と違った。
実際に/goalを1本打ってみた
理屈を読んでも腹落ちしないので、一番安全なやつを1本だけ打ってみた。記事を公開する前の「ビルドが通るか」のチェック。これなら公開もされないし、ファイルも書き換わらないから、何が起きても事故にならない。
実際に打ったのがこれ。
/goal （ブログのフォルダ）で npm run build が [build] Complete! で通る。
コードやmdは変更しない。失敗時のみ原因を1行で報告して止める。最大5ターン。「最大5ターン」と入れているのは保険。条件の書き方をミスして永遠に回り続ける、みたいな暴走を防ぐためのストッパー。これは入れておいた方がいい。
で、結果。
✔ Goal achieved (21s · 1 turn · 364 tokens)1ターン、364トークン、21秒で自動で止まった。すでにビルドが通る状態だったから1ターンで終わったんだけど、何より「達成したから止まる」を自分が何もしなくてもやってくれた。Escも押してない。/goal clearもしてない。条件を満たしたのを裏で確認して、勝手に降りた。
364トークンって、感覚で言うと短いチャット1往復にも満たない量。青天井を心配してたのが拍子抜けするレベル。もちろん「まだ通ってない」状態から直しながら回せばもっと食うけど、それでも「裏で勝手に何時間も燃え続ける」みたいな絵とはぜんぜん違った。
そして地味に効くのが、この「ビルドが通るまで」を任せられること。さっき書いた、設定ミスでサイトが更新されなくなった事故。あれは公開前に**「通ったつもり」で出してしまった**のが原因だった。/goalなら、通るまで止まらないし、通ったかどうかを別モデルが見届ける。「つもり」で先に進めない。
結局のコツは「集めるのはツール、判断だけAI」
ここからが、自分が一番伝えたい部分。
トークンを食うのって、実は/goalそのものというより、「集めて、読んで、判断する」を全部AIにやらせるときなんだよね。たとえば「最新の情報を全部読んで、要点をまとめて、どれを記事にするか決めて」と一息でお願いすると、集めてきた生のデータが全部AIの読む対象になる。ここでトークンが膨らむ。
だから分ける。
- 集める係：これはAIじゃなくていい。普通のスクリプトや定期実行（cron）に任せる。ここはトークンを使わない。
- 判断する係：集まって整理済みのものだけAIに渡して、「どれがいい？」を決めさせる。
集める部分をAIの外に逃がすだけで、AIが読む量が桁で減る。結果、料金もぐっと下がる。これが/goalの「判定だけ安いモデルに任せる」発想と、根っこは同じ。重い作業と軽い判断を分ける、というだけの話。
白状すると、これ、自分はもう前からやっていた。毎週やっているブログの定点チェックで、数字を集めてくる部分はスクリプトに先にやらせて、AIには「集まった数字を見て、次どうする？」だけ聞いている。当時は節約のつもりでやってただけなんだけど、今回/goalを触って「あ、自分が無意識にやってたのはこれの一種だったのか」と線がつながった感覚があった。
試すなら、この1行から
長く書いたけど、やることは1行。コピペできる安全なやつを置いておく。
/goal （あなたのプロジェクト）で ビルド（npm run build 等）が成功する。
ファイルは変更しない。失敗時のみ原因を1行で報告して止める。最大5ターン。ポイントは3つだけ。
- 「最大5ターン」を必ず入れる：暴走の保険。
- 「ファイルは変更しない」「公開しない」を明記：チェックだけさせて、勝手に手を加えさせない。
- 公開（git pushなど）は条件に入れない：そこは自分の手で最後に押す。自動化していい部分と、人間がゲートを握る部分は分ける。
仕組みの一次情報は公式ドキュメントが正確なので、ちゃんとやりたい人はこのあたりを読むといい。Keep Claude working toward a goal（/goal 公式ドキュメント）とRun a prompt on a schedule（定期実行）。
「毎回プロンプトを打つのが当たり前」だと思っていたけど、しんどい往復を仕組みに渡せる場所は、思ったより多い。まずは事故にならないビルドチェックの1本から。これなら料金もサイトも怖くない。
AI絡みで前に書いた話だと、NotebookLMとClaudeでトークンを使わずに調べる方法や、ObsidianとClaudeをつないで外部脳にした体験記あたりも、同じ「重い作業を外に逃がす」発想でつながっている。よかったら。
