※この記事は、2026年7月時点の自分のAI運用メモです。Claude Codeの機能名に少し触れますが、特定のテンプレートや有料資料の中身を紹介する記事ではありません。
最近、AIに自動化の設計書を作らせようとして、少し肩透かしを食らいました。
やりたかったのは、Claude Codeのような開発支援エージェントを前提にした、自動化の設計書づくりです。
ただ、特定のプロジェクトだけでしか使えないものではなく、別の作業にも横展開できる形にしたかった。
そこで、ざっくり言うと、こんな方向で頼みました。
「Claude Code用の自動化設計書を、汎用的に使える形にしてほしい」
ところが、出てきたものを見た時に、何か物足りなさがありました。
間違っているわけではない。
それっぽい項目も並んでいる。
でも、期待していたほど刺さらない。
よく見ると、たぶん原因は「汎用化」という言葉にありました。
自分が欲しかったのは、Claude Codeの前提を残したまま、プロジェクトをまたいで使える設計書でした。
でも、AI側には、
「どんなAIでも使えるように薄めて」
に近く伝わってしまったのかもしれません。
ここで、かなり大事なことに気づきました。
AIに設計書を作らせるなら、「汎用化していい部分」と「残す前提」を分けて渡さないと、成果物が一気に薄くなる。
「汎用化して」は便利だけど、かなり危ない
AIに何かを頼む時、「汎用化して」と言いたくなることがあります。
一回きりのメモではなく、他でも使える形にしたい。
特定の作業だけでなく、似た作業にも使えるようにしたい。
自分以外のAIや別プロジェクトでも使い回したい。
この気持ちはかなり自然です。
自分も、せっかく設計書を作るなら、今の作業だけで終わらせたくありませんでした。
ただ、「汎用化して」という言葉は広すぎます。
何を汎用化するのか。
何は固定したままにするのか。
どこまで薄めてよいのか。
どこから先は薄めてはいけないのか。
ここを渡さないと、AIは安全側に寄せます。
特定の道具に依存しないようにする。
専門用語を減らす。
誰でも読める構成にする。
抽象的なチェックリストにする。
結果として、きれいだけど普通の設計書になります。
これはAIが悪いというより、自分の依頼が足りなかったのだと思います。
Claude Code用なら、残すべき前提がある
Claude Codeは、普通のチャットAIとは少し違います。
2026年7月9日に公式ドキュメントで確認した範囲では、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携するエージェント型のコーディング支援ツールとして説明されています。
さらに、CLAUDE.md、Skills、Hooks、Subagents、MCP、権限設定のような要素もあります。
ここで大事なのは、これらを細かく解説することではありません。
自分が気づいたのは、こういう前提を消してしまうと、Claude Code用の設計書ではなくなるということです。
たとえば、Claude Code用の自動化設計書なら、本来はこういう問いが必要になります。
どの作業をSkill化するのか。
どの作業をSubagentに分けるのか。
どのタイミングでHookを使うのか。
外部ツールや資料へ接続するなら、MCPをどう扱うのか。
どこで人間の承認を挟むのか。
どの操作は許可し、どの操作は止めるのか。
こういう問いが抜けると、ただの「自動化の進め方」になります。
もちろん、それはそれで役に立ちます。
でも、自分が欲しかったものとは違います。
欲しかったのは、一般的な自動化論ではありません。
Claude Codeのように、ファイルを読み、変更し、検証し、必要なら外部ツールともつながるAIを、どう安全に作業へ組み込むかという設計書でした。
そこを残さずに汎用化してしまうと、いちばん欲しかった部分が抜け落ちます。
汎用化していい部分と、してはいけない部分を分ける
今回の失敗を整理すると、汎用化には層があるのだと思います。
まず、汎用化していい部分があります。
たとえば、対象プロジェクトです。
ブログ運用でも、コード修正でも、資料整理でも、基本の考え方を横展開したい。
言語やフレームワークも、できれば固定しすぎない方がいい。
Python専用、WordPress専用、Obsidian専用にしすぎると、別の場面で使いにくくなります。
次に、半分だけ汎用化する部分があります。
設計、実装、レビュー、検証、リリース、改善のような工程です。
工程そのものは広く使えます。
でも、それぞれの工程で何を確認するかは、作業によって変わります。
だから、ここは「型」は汎用化してもいいけれど、「確認項目」は作業ごとに差し替える必要があります。
そして、汎用化しすぎるとダメな部分があります。
今回で言えば、Claude Codeを前提にする部分です。
ファイルを読む。
編集する。
コマンドを実行する。
スキルやフックを使う。
サブエージェントに分ける。
権限や承認を設計する。
ここまで薄めてしまうと、Claude Code用である意味がなくなります。
つまり、こう頼むべきだったのだと思います。
「汎用AI向けに薄めるのではなく、Claude Code前提は残したまま、プロジェクト横断で使える設計書にしてほしい」
この一文があるかどうかで、出てくる成果物はかなり変わりそうです。
AIは「残してほしい前提」を勝手には守れない
今回の話は、AIに設計書を作らせる時だけの話ではありません。
AIは、こちらが明示していない前提を、必ずしも守ってくれません。
こちらの頭の中では、当然残ると思っているものがあります。
このツールを使う前提。
この作業環境で動かす前提。
この読者に向ける前提。
この公開範囲は守る前提。
この失敗だけは避ける前提。
でも、AIから見ると、それは見えていないことがあります。
だから、AIは一般化します。
使いやすくする。
読みやすくする。
無難にする。
どこでも通じるようにする。
その結果、こちらが一番残したかったクセや強みまで消えることがある。
今回の「Claude Code用の設計書を汎用化して」は、まさにそれでした。
自分としては、Claude Codeらしさを残したかった。
でも、AIには「汎用化」が強く伝わりすぎた。
その結果、きれいだけど、どこか普通のものになった。
これは、かなり実運用っぽい失敗だと思います。
これからは、設計書を頼む前に前提を分ける
次に同じような依頼をするなら、最初にこう分けたいです。
まず、残す前提。
Claude Codeを使うこと。
ファイル操作やコマンド実行を前提にすること。
Skills、Hooks、Subagents、MCP、権限設計のような要素を設計対象に入れること。
人間の確認点を必ず残すこと。
危険な操作は止めること。
次に、汎用化してよい部分。
対象プロジェクト。
言語やフレームワーク。
ブログ、コード、資料整理などの作業分野。
細かいファイル名や具体手順。
さらに、成果物の条件。
ただの説明文にしない。
実装や運用に落とせる粒度にする。
どの工程で何を確認するかを書く。
どこでAIを止めるかを書く。
どこから人間が判断するかを書く。
ここまで分けてから頼めば、AIの出力はもう少し狙った方向に寄るはずです。
プロンプトを強くするというより、残す前提と変えてよい部分を分ける。
たぶん、自分に足りなかったのはそこです。
「使い方が悪い」で終わらせない方がいい
こういう話を書くと、簡単に「それは使い方が悪い」と言えてしまいます。
たしかに、依頼の出し方は悪かったと思います。
でも、それだけで終わらせると、あまり学びになりません。
自分が感じたがっかり感も、たぶん大事です。
高性能AIなら、もう少しこちらの意図を汲んでくれるのではないか。
ふわっと投げても、欲しいものの輪郭を補ってくれるのではないか。
普通のテンプレではなく、期待以上のものを出してくれるのではないか。
そう期待していたから、出てきたものが普通に見えた時に引っかかりました。
ただ、そこから見えたのは、モデルの良し悪しだけではありません。
AIが強くなっても、こちらが何を残したいのかは渡す必要がある。
特に設計書やテンプレのようなものは、一般化しすぎると一気に薄くなる。
だから、AIに設計書を作らせる時ほど、最初にこう言う必要があるのだと思います。
「ここは変えていい」
「ここは変えないでほしい」
この線引きです。
まとめ
AIに設計書を作らせる時、「汎用化して」と頼むのは便利です。
でも、そのままだと危ないです。
AIは、特定の道具や環境に依存しないように、成果物をきれいに薄めてくれます。
それが欲しい時もあります。
ただ、Claude Code用の設計書のように、使う道具の前提そのものが重要な場合は、そこまで薄められると困ります。
今回、自分が欲しかったのは、どんなAIでも使える自動化テンプレではありませんでした。
Claude Codeのような開発支援エージェントを前提にしつつ、プロジェクトをまたいで使える設計書でした。
だから、次からはこう分けたいです。
汎用化していい部分。
残す前提。
人間が確認する場所。
AIに任せる工程。
AIを止める条件。
このあたりを先に渡してから、設計書を作ってもらう。
AIに仕事として渡すだけでは、まだ足りないことがあります。
その仕事の中で、何を変えてよくて、何を変えてはいけないのか。
そこまで渡せると、AIの成果物はもう少し自分の運用に近づくのかもしれません。
参考情報
- Claude Code Docs: Overview（確認日: 2026年7月9日）
- Claude Code Docs: Skills / Hooks / Subagents（確認日: 2026年7月9日）
コメント