Claude Codeの自動化は「止まる場所」の設計で決まる｜AI秘書の作り方

Claude Codeに一連の作業をまるごと任せたいのに、結局は毎回「次はこれをやって」と指示を出し直していませんか。

実は私も同じ状況でした。部署ごとのフォルダも指示書も揃っているのに、それをつなぐ人がいない。準備は万全なのに、動かすたびに自分が伴走している状態が続いていました。

この記事では、その状態を抜け出すために置いた「秘書」の設計を、実際の記録をもとに公開します。鍵になったのは、どこまで自動化するかではなく、どこで止まるかを先に決めたことでした。私が出した条件はたった一つだったのに、Claudeは停止点を6か所に増やして返してきました。

さらに、AIに仕事を渡した瞬間に自分の手順書の穴が3つ見つかったこと、着手前に「戻し方」を先に決めたこと、課金事故を注意ではなく仕組みで止めたことまで、実装の過程で起きたことをそのまま書きます。生成AI講師として登壇してきた現役教員が、自分の環境で確かめた記録をもとに解説します。

この記事を読めば、Claude Codeの自動化を「止まる場所」から設計できるようになり、任せても事故らない仕組みを自分の仕事にも作れるようになります。

この記事では、次の流れで解説します。

それでは、順番に説明していきましょう。

---

Claude Codeの自動化設計で最初に決めるのは「止まる場所」

自動化の質は、どこまで任せられるかではなく、どこで止まるかで決まります。私がAIに秘書役を任せるとき出した条件は、たった一つでした。それなのに返ってきた設計には、停止点が6か所も並んでいました。この節では次の3点を説明します。

順番に見ていきましょう。

全自動をやめて「6回止まる」設計にした理由

原稿を渡すだけで記事が完成する仕組みを作りながら、あえて6回止める設計にしました。

理由は単純で、構成が間違ったまま本文を書かれると、全部書き直しになるからです。私が伝えた条件は、次の一文だけでした。

重要な点は一箇所のみです。ステップ4の本文執筆に入る前に構成を私に見せて点検してもらうことです。

本文執筆の直前に必ず止まってほしい。それだけが要望でした。ところが実際にできあがった設計は、こうなりました。

社長が原稿を渡す
  │
  ├─ 記事構成の作成
  ■ 停止点① 構成を点検 ← 私が指定した唯一のポイント
  │
  ├─ 本文執筆・FAQ
  ■ 停止点② 原稿を点検
  │
  ├─ 入稿用HTML生成・画像プロンプト作成
  ■ 停止点③ プロンプトを点検
  │
  ├─ 画像を一括生成（約10分）
  ■ 停止点④ 画像を検品
  │
  ├─ 入稿前の検証（実際には投稿しない）
  ■ 停止点⑤ 入稿内容を確認
  │
  ├─ WordPressに下書き入稿
  ■ 停止点⑥ 下書き確認 → 公開指示

結果として、人間の仕事は「原稿を渡す」と「6回OKを出す」だけになりました。手を動かす作業はすべて渡し、判断だけを手元に残したわけです。

止まらない自動化は間違いを全速力で運ぶ

速い自動化ほど、誤りを最後まで運びきってしまいます。

途中に判断が入らない仕組みは、誤りを検知する機会をひとつも持っていません。人間が手作業でやっているときは、次の工程に移る瞬間に無意識で確認していました。その確認の場が、自動化するとまるごと消えます。

たとえば記事構成を間違えたまま止まらずに走ったら、どうなるか。9,000字の本文が書かれ、その本文に合わせた画像プロンプトが作られ、画像が7枚生成され、WordPressに入稿されます。そこで初めて「構成が違う」と気づくわけです。

やり直すのは本文だけではありません。画像も作り直しになります。しかも画像生成は1枚あたり1分ほどかかるので、7枚で10分近く。間違いに気づくのが遅いほど、巻き添えになる工程が増えていく構造です。

止まる設計は、自動化をわざと遅くする工夫ではありません。やり直しの総量を減らすための工夫です。

AIが自分から停止点を増やしてきた理由

私が指定した停止点は1か所でしたが、Claudeは6か所に増やしてきました。とくに③（画像プロンプトの点検）と④（生成画像の検品）は、私が一言も言っていないものです。

なぜ増やしたのか聞いてみると、理由がはっきりしていました。過去に画像生成で事故を起こした記録が、プロジェクトのフォルダに残っていたからです。

その事故というのは、画像の中に実在しない官公庁の文書名と、存在しない条文が書き込まれて生成されたというものでした。パッと見ではもっともらしく仕上がるので、気づかず公開していたら目も当てられません。

だからClaudeは、画像を作る前（プロンプトの点検）と、作った後（生成画像の検品）の両方に人間の目を入れる設計にしてきました。

失敗の記録は、反省文として書くと読み返されないまま埋もれますが、指示書に一行残しておくと、AIが設計のたびに参照してくれます。

---

Claude Codeの自動化を設計すると自分の手順書の穴が見える

自動化の設計を始めてすぐ、思わぬ副産物がありました。手順書とできあがった成果物を突き合わせたところ、書かれていない手順で運用されていた箇所が次々に出てきたのです。この節では次の3点を説明します。

ひとつずつ確認していきましょう。

実際に見つかった3つの穴

手順書に書かれていない作業が、3つ見つかりました。

理由は明快で、人間が暗黙にやっていた作業は、手順書に書き起こされないからです。自分でやっている限り困らないので、書く動機がありません。

見つかったのは次の3つでした。

見つかった穴	実態
画像の差し込み位置を示すコメント	実際のHTMLには8個入っているのに、手順書に一行も書かれていない
画像のファイル名	手順書に命名規則がなく、たまたま一致していただけ
アイキャッチの自動設定	スクリプトが対応しておらず、毎回手作業だった

どれも、自分ひとりでやっているうちは何の問題も起きません。手が覚えているからです。しかしAIに任せた瞬間、書かれていない手順は実行されません。

これらの穴は「見つかった」というより、AIに渡したから「見えた」というのが正確です。

「たまたま一致していただけ」の危うさ

3つのうち、いちばんヒヤリとしたのが命名規則です。

画像のファイル名について、手順書にはルールが一行も書かれていませんでした。それでも今まで動いていたのは、私が毎回なんとなく同じ付け方をしていたからです。偶然の一致で回っていた工程でした。

人間は文脈で補正できます。「01-sessionのやつ」と言えば通じるし、多少ずれていても目で見て直せます。ところがスクリプトは違います。1文字でも違えばそこで止まります。

実際、この仕組みでは入稿用のHTMLに書いたファイル名と、画像作成側が保存したファイル名が完全に一致しないと、入稿処理が停止するようにしました。厳しく見えますが、中途半端に動いて画像が抜け落ちるより、止まってくれたほうがはるかにましです。

AIに渡す手順書は、あいまいさを許しません。そのぶん、書き直したあとの精度は確実に上がります。

校務の引き継ぎ資料でも同じことが起きる

これはブログ運営に限った話ではありません。学校の引き継ぎでも、そっくり同じことが起きています。

引き継ぎ資料にも、必ず「書かれていない暗黙のやり方」が残っているからです。前任者しか知らない提出先の順番、慣例で決まっていた実質的な締切、あの先生には先に一声かけておくという不文律。資料には一行も書かれていません。

4月に着任した人が最初の1か月で苦労するのは、たいていこの部分です。資料に書いてあることは読めばわかる。書いていないことでつまずきます。

AIに任せる作業は、手順書を棚卸しする絶好の機会になります。自動化そのものより、この副産物のほうが職場では効くかもしれません。

---

Claude Codeの自動化を設計する前に「戻し方」を決める

仕組みを作り替えるということは、今動いているものを壊す可能性があるということです。実装を頼む前に、私はこう聞きました。

もし変更後にうまく行かないときはもとに戻せますか? コミットやgitへのプッシュなどで対応できますか?

返ってきたのは、3層の安全策と、戻せないものの明示でした。この節では次の3点を説明します。

順に見ていきましょう。

着手前に用意した3層の安全策

作業を始める前に、戻る先を3層で用意しました。

「たぶん大丈夫」で始めた変更は、失敗したときに切り分けができなくなります。どこまでが元の状態で、どこからが今回の変更か、後から見分けられなくなるからです。

用意したのは次の3つでした。

1. 作業前スナップショットのコミット — 戻る先を作る
2. 専用ブランチで作業 — 失敗したらブランチごと捨てる
3. git管理外のファイルは手動バックアップ

とくに効いたのが2番目です。失敗したときの手順が、たった2行で済みます。

git switch main                  # 元の状態に戻る
git branch -D blog-secretary     # 失敗作を完全に破棄

ブランチごと捨てられる状態を作ってから着手する。これだけで、大きな変更を頼むときの心理的なハードルがまるで違います。

戻せないものを先に洗い出す

ここで感心したのは、AIが「全部戻せます」と言わなかったことです。

戻せないものを、先に挙げてきました。外部のサービスに送信したものと、生成そのものが一回きりのものは、バージョン管理の外側にあるからです。

• WordPressに入稿された記事 — ただし必ず下書きなので、ゴミ箱に入れれば済む
• 生成された画像 — 同じプロンプトを投げても、同じ絵は二度と出てこない

前者には「必ず下書きで入れるから実害はない」という補足まで付いていました。後者は、そもそも取り返しがつきません。だからこそ、画像は生成前と生成後の両方に停止点が置いてあるわけです。

戻せない範囲を知っていれば、そこだけ慎重に運用すれば済みます。全部を等しく怖がる必要がなくなるのが、この洗い出しの効果です。

バックアップと巻き戻しを混同しない

安全策の話の流れで、バックアップのためにGitHubへpushするか聞かれました。結論としては、やめました。

理由は、Claudeが挙げてきた指摘にありました。

• プロジェクト内の指示書に、運営者の個人的な経歴が書かれている
• クラウドストレージの個人フォルダのパスが書かれている
• 公開設定にすると、まさに避けたかった「他人に見られる状態」になる

もともとこの一連の作業は、認証情報を外に出さない設計から始まったものです。その流れでバックアップのつもりが公開設定になっていたら、本末転倒でした。

ここで整理しておきたいのは、巻き戻しとバックアップは目的が違うということです。

目的	必要なもの
失敗したら元に戻したい（巻き戻し）	手元のバージョン管理で足りる
PCが壊れても復旧したい（保険）	別の場所への保存が必要

今回必要だったのは前者で、後者の手段を持ち出す場面ではありませんでした。目的と手段を混同しないというのは、自動化の設計全体に効いてくる考え方です。

---

Claude Codeの自動化設計で課金事故を仕組みで防ぐ

自動化でいちばん怖いのは、寝ている間に課金が積み上がることです。今回の仕組みでは画像を一度に7枚から10枚生成するので、ここは絶対に踏み外せませんでした。私が出した条件はこうでした。

Codexのapiを使ってお金がかかるようなことはやりたくない。しかし、すでにChatGPTに課金しているので、ターミナルでCodexを走らせて画像を作ることはできます。

この節では次の3点を説明します。

仕組みの中身を見ていきましょう。

「気をつける」では事故は防げない

課金事故は、注意力ではなくスクリプトの分岐で防ぎます。

自動化は、人が見ていないところで走ります。注意しようにも、注意する人がその場にいません。だから「気をつける」というルールは、自動化においては存在しないのと同じです。

そこで実装したのは、実行前に認証方式を確認し、想定と違えばその場で停止するという単純な仕組みでした。定額の契約で動いていれば進む。従量課金の認証だったら止まる。それだけです。

守らせたいルールは、破れない形にして初めてルールになります。指示書に「APIを使わないこと」と書くだけでは足りません。使おうとしたら止まる、というところまで作って完成です。

サブスクリプションのまま画像生成を回す

心配していた画像生成は、すでに払っている定額の枠内で自動化できました。

非対話モードのコマンドから、契約中のアカウントの認証を使って実行できたからです。追加の従量課金は発生しませんでした。

しかも、驚いたことがひとつありました。私が前日に手で打った履歴が残っていたのです。

'（画像作成部のフォルダパス）'この中のプロンプトに従って画像を作って

この1文だけで、10枚の画像が生成されていました。

つまり「フォルダを渡すだけ」という運用は、すでに手作業で成立していたわけです。自動化としてやったことは、この1文をスクリプトから呼ぶようにしただけでした。

自動化というと、ゼロから何かを組み立てる話に聞こえます。しかし実際には、すでに手でやって動いている操作を、そのまま呼び出す形にするのが最短でした。所要時間は画像1枚あたり約60秒、9枚で約10分です。

チェックを置く場所は実行の直前

安全確認は、実際にお金が動く処理の直前に置きます。

手前に置くほど、実行までの間に状態が変わる余地が生まれるからです。起動時に一度確認しただけでは、その後に設定が切り替わっていても気づけません。

今回は、生成コマンドを呼び出す直前で認証方式を確認する構成にしました。チェックしてから課金が発生するまでの間に、何も挟まらない状態です。

チェックは「あること」より「どこにあるか」で効き目が変わります。入口に警備員を置いても、裏口が開いていれば意味がないのと同じです。

---

Claude Codeの自動化を自分で設計する4ステップ

ここまでの考え方を、自分の仕事に落とし込む手順としてまとめます。対象はブログである必要はまったくありません。校務でも同じ順番で設計できます。この節では次の4点を説明します。

順番に進めていきましょう。

ステップ1：手でつないでいた作業を工程に割る

まず、自分が毎回手で指示していた作業を、工程として書き出します。

つなぎ目が見えないと、どこを自動化するかも決められないからです。「なんとなく大変」を「4つの工程」に変えるだけで、議論できる対象になります。

今回のブログ運用は、次の4工程に割れました。

1. 原稿を渡して記事を書かせる
2. 画像プロンプトを作らせる
3. 別のツールを立ち上げて画像を作らせる
4. WordPressに入稿する

書き出してみて気づいたのは、それぞれの工程には担当の指示書があるのに、工程と工程の間には誰もいなかったということでした。だから毎回「次はこれをやって」と私が言う必要があったわけです。

工程に割った時点で、抜けている手順も浮かび上がります。ステップ1は準備運動に見えて、実は診断の工程です。

ステップ2：やり直しが一番高くつく工程を探す

停止点は、間違いの修正コストが最大になる工程の直前に置きます。

安いやり直しは自動で回してよく、高いやり直しだけを人が見ればよいからです。すべての工程に人を張り付けたら、それは自動化ではありません。

今回で言えば、本文執筆の直前がそこでした。構成の誤りは全文の書き直しに直結し、さらに画像まで巻き添えにするからです。逆に、FAQを5件書き直すのは安いやり直しなので、止める必要がありません。

停止点は数ではなく、置く位置で価値が決まります。1か所を正しい位置に置くほうが、10か所を適当に散らすより効きます。

ステップ3：AIに触らせない線を引く

自動化の範囲を決めるときは、同時にAIに渡さないものも明文化します。

任せる範囲だけを決めると、認証情報や個人情報の扱いが曖昧なまま残るからです。「言わなくてもわかるだろう」は、AI相手には通用しません。

今回、指示書に書いたのは次の線引きでした。

- 認証情報を会話に打たせない
- スクリプトの引数にも環境変数にもファイルにも書かない
- AIが値を取り出すコマンドを実行してはならない
- 値の取得はスクリプトの内部だけで行う

一言でいえば「AIは存在確認まで。値の取り出しはスクリプトの内部だけ」という線です。そしてClaudeは、実際にこの線を守りました。認証の確認をするときも、自分で値を読み出さず、スクリプト経由で確認していました。

ルールは、書けば守られます。書かなければ守りようがありません。

なお、認証情報そのものをどこに預けるかについては、生成AIにパスワードを打ち込む前に｜安全な管理はmacOSキーチェーンでで手順まで詳しく解説しています。この記事の仕組みは、その預け方が土台になっています。あわせて読むと、任せる範囲と渡さない範囲の全体像がつかめます。

ステップ4：指示書に「止まれ」と書く

停止点は、指示書に明記して初めて機能します。

口頭で伝えた条件は、セッションが変われば消えてしまうからです。今日のやりとりで合意したことは、明日の新しいセッションには引き継がれません。

そこで、プロジェクトの指示書に、こういう一文を書きました。

本文執筆に入る前に、必ず記事構成を点検にかける。
明確なOKが出るまで本文を一文字も書き始めない。
修正が入ったら、そのつど点検を受け直す。

「一文字も書き始めない」というところまで書くのがコツです。あいまいに書くと、あいまいに解釈されます。

設計は、頭の中ではなくファイルに置く。当たり前のようですが、自動化における設計書とは、AIが毎回読む指示書そのものです。別の場所に立派な設計書を作っても、読まれなければ設計したことになりません。

---

Claude Codeの自動化設計でつまずく2つの落とし穴

設計そのものより手前で止まった箇所が、2つありました。どちらも知っていれば数分で解決しますが、知らないとかなりの時間を溶かします。この節では次の2点を説明します。

先に潰しておきましょう。

作ったスキルが一覧に出てこない

スキル（手順書）を作っても、置き場所しだいで認識されません。

既存のスキルは、部署のフォルダの中の設定フォルダに置いてありました。ところがプロジェクトのルートでClaude Codeを起動すると、スキル一覧にまったく出てきません。

サブフォルダ側の設定フォルダは読まれていなかったわけです。ルート直下の設定フォルダに移したら、その場で一覧に現れました。

ブログ部/.claude/skills/     ← ルートで起動すると読まれない
.claude/skills/              ← ここに移したら認識された

「作ったのに使えない」の大半は、中身ではなく場所の問題です。動かないときは、まず中身を疑う前に置き場所を確認してください。

AIの助言を検証せずに採用する

これがいちばん深い落とし穴でした。

AIの助言は、「たぶん動く」で書かれていることがあります。もっともらしく、手順も具体的で、一見すると検証済みに見えます。しかし、こちらが求めない限り、AIは検証せずに答えを返す場合があります。

今回、実際にこういう場面がありました。ある操作について案内を受けたあと、しばらくしてClaudeが自分から前言を撤回してきたのです。

先に訂正させてください。検証したところ、（略）キーチェーンを使う意味そのものが失われます。

つまり、最初の案内は検証されていませんでした。そして検証したら、その案内は安全上まずいと判明した。撤回してきた誠実さは信用できますが、放っておいたらそのまま実行していたわけです。

ここから引き出せる教訓は一つです。

「それ、検証しましたか」と聞く習慣を、設計の一部にする。

これは疑うという話ではありません。AIに手順を出させたら、実際に動かして確かめさせる。その一手間を工程に組み込むということです。停止点を置くのと、まったく同じ発想です。

---

まとめ｜Claude Codeの自動化は設計しだいで戦力になる

まずやるべきなのは、自分の仕事で「やり直しが一番高くつく工程」を探すことです。そこが見つかれば、停止点を置く場所は自動的に決まります。

自動化の失敗は、たいてい能力不足ではなく設計の問題として起きるからです。どこまで任せるかを先に考えると、判断の場が抜け落ちたまま完成してしまいます。

紙に4工程だけでも書き出してみてください。工程に割った瞬間に、つなぎ目が誰の担当にもなっていないことが見えてきます。私の場合、そこが自動化の出発点になりました。

もう一つ大切なのは、着手する前に「戻し方」を決めておくことです。戻れる保証があるかどうかで、任せられる仕事の大きさが変わります。

戻る先を作るのに必要なのは、技術ではなく段取りです。作業前にスナップショットを取り、専用の場所で作業する。それだけで、失敗しても2行で元に戻せる状態になります。

AIが優秀かどうかより、引き返せるかどうかのほうが重要です。

大きな変更を頼む前に、まず「うまくいかなかったら戻せますか」と聞く。

そのうえで停止点を正しい位置に置いておけば、間違いが最後まで運ばれる心配もありません。

止まる場所を設計したClaude Codeは、あなたの仕事を確実に前へ進める戦力になるのです。

あわせて読みたい：この仕組みの土台になっている認証情報の預け方は、生成AIにパスワードを打ち込む前に｜安全な管理はmacOSキーチェーンでで手順まで解説しています。任せる範囲を広げる前に、渡さない範囲を固めておきましょう。

この記事が役に立ったと感じたら、Xのフォローとブックマークをお願いします。教育現場で実際に試した生成AIの設計と失敗を、これからも記録として公開していきます。

---

よくある質問（FAQ）

停止点は必ず6か所にしないといけませんか？

いいえ、工程の数と修正コストで決まります。大事なのは数ではなく位置です。まずは「やり直しが一番高くつく工程」の直前に1か所置いてください。運用しながら、事故が起きた場所に足していくのが現実的です。

Claude Codeを使わなくても、この設計は応用できますか？

できます。工程に割る、高くつく工程の直前で止める、触らせない範囲を明文化する、それを文書に残す。この4つはツールに依存しません。ChatGPTやGeminiに定型業務を任せる場合でも、そのまま使えます。

手順書はどこまで細かく書けばいいですか？

「1文字違ったら止まる」ものは必ず書きます。ファイル名の規則、保存先のフォルダ、置いてはいけない場所などです。逆に文章の言い回しのような、多少ぶれても問題ない部分は方針だけで足ります。

AIに「検証しましたか」と聞くと、機嫌を損ねませんか？

損ねません。むしろ実際に確かめて、結果が違えば訂正してきます。今回も自分から前言を撤回してきました。確かめさせるのは疑うことではなく、工程として組み込むべき手順だと考えてください。

校務の自動化から始めるなら、何が向いていますか？

毎回同じ順番で、同じ形式のものを作る仕事です。通信の定型部分、行事の案内文、集計後の所見の下書きなどが向いています。ただし個人情報を含む工程は、渡さない範囲として先に線を引いてから始めてください。