この記事の対象
- 企画職・非プログラマだけど、生成AIで仕事を楽にしたい
- Claude Code、名前は聞くけど「コード書く人のやつでしょ？」と思って避けてる
- とりあえず触ってみたけど、何から手をつければいいかわからん
そんなあなた向けです。コードの話はほぼしません。安心してください。
Why：なんで非プログラマがClaude Codeなのか
まず大前提として、仕事って大半がルーチンワークなんですよね。みなさんの仕事も、気づけばルーチンワークに時間を取られて、他の作業に手が回らなくなっていませんか。それを解消してくれるのがClaude Codeです。
さて、ルーチンワークとはなんでしょうか。それは、毎回発生するやつ。一見バラバラに見えても、よく観察すると「あー、これ先週もやったな」となる。いわゆる「型」のある業務のことですね。
逆に言うと、自分の仕事を体系化してルーチンに落とし込めるなら、そこは生成AIと一緒に回せる余地がある、ということです。
ところで普段の自分の仕事って、いざ言葉にすると意外とフワッとしてませんか。「まずアレ見て、だいたいこういう観点で整理して、最後にこの形でまとめる」みたいな。ドントシンク、フィール的な。この 「何となくやってる手順」を、Claude Codeと会話しながら一個ずつ「言葉にしていく」。これがまず最初にやるべき作業です。
例えば、議事録の作成。これも立派なルーチンワークですよね。手順をほぐすとこんな感じになるはずです。
- まず会議中に取った必死のメモを読み解く
- 章立て（開催日・参加者・概要・まとめ・次のアクション）のテンプレを開く
- メモの内容を仕分けして流し込んでいく
こうやって書き出すと、「あ、自分いつも無意識にこの順番でやってたな」と見えてきます。これが「言葉にする」ということです。
言葉にできたら、次はそれを「型」にはめてみる。さっきの議事録なら「メモを渡されたら → この章立てに沿って → この観点で仕分けする」という決まった形に固定してしまう。一度固定すれば、あとは会議メモをポンと渡すだけ。それに沿ってAIに流せばいい、というわけです。
整理して、型にはめる。この2ステップを丁寧にやること、それ自体がClaude Codeを使うということだと思っています。
ちなみに、Claude Codeは特にskillを作らなくても、プロンプトに応じて結構動いてくれます。ただ、ここでこのステップをサボると、あまりいいことはありません。型が自分流にならないからです。
例えば先ほどの議事録を例にすると、それっぽく章立てしてまとめてもらえるでしょうが、やっぱりこのテンプレートに合わせた方がいいな、となると、結局手直しが大量に発生します。概して生成AIは非を認めないので一度作ったものを修正するのは骨が折れます！
ですので、いきなり全部自動で任せるのではなく、まず自分の仕事を棚卸しして型を作ることが肝要です。地味ですが、この発想の転換が非プログラマにこそ効きます。
What：結論、skillを作れ。それだけでいい
じゃあ具体的に何をすればいいか。skillを作ってください。初学者は極論これだけでOKです。
自分もskillから入りました。大小合わせて1ヶ月で30個以上。ざっくり1日1個ペースですね。他の人曰く、作りすぎらしいです。
なぜ、skillからなのか。Claude Codeって目的志向なんです。今のAIは「なんでもやってくれる魔法」ではありません。ただし、何をすべきか、目的を明確にしてやれば、大体のことは達成できるところまで来ています。で、その「何をすべきか」を形にしたものがskill、というわけです。
Claudeの最小単位：CLAUDE.md / skills / MCP
なぜskillから始めるのか、をもう少し腹落ちさせるために、Claude Codeをめちゃくちゃ雑に最小単位まで割ってみます。こうなります。
- CLAUDE.md … 方針を計画するもの
- skills … 手段を考えて実行するもの
- MCP … ツール（道具）
この記事では、このうち skills に全振り します。MCP（道具）や、CLAUDE.md（方針）、さらにはよく記事になる hook・agent なんかはskillに慣れてからで十分。まずは実行そのものである skill だけに集中してください。
で、ここで初心者がやりがちなミス。いきなりCLAUDE.mdをなんとかしようとする。
これはダメ。だって、どんな手が打てるか（skills）、どんな道具があるか（MCP）も知らないのに、方針（CLAUDE.md）だけ立てるわけですから。完全に絵に描いた餅になります。だったらまず手を動かしてskillsから試した方が早い。トップダウンな計画を立てるのではなく、やれることからボトムアップ、下から積む。この順番が大事です。
How：実際どう作る？
skillもClaude Codeに作らせる
さて本題。skillの作り方ですが、難しいことはしません。skill自体もClaude Codeに作らせます。自分でゴリゴリ書かない。一緒に壁打ちしながら作っていきます。
やることはシンプルで、プロンプトでこう投げるだけ。
プロンプト例
- 新しいスキルを作りたい。〇〇〇〇みたいな作業を、毎回こういう手順でやってるんだけど、これを任せられるようにしたい。
- （イメージが固まってなければ）〇〇〇〇な作業を楽にするスキルを作りたい。どういう構成にすればいいか一緒に考えて。
作りたいものの「作業の中身」さえ伝えれば、あとはよしなに形にしてくれます。難しい記法とか覚えなくて大丈夫。
そして出来たら、これまた言葉で投げるだけ。
プロンプト例
- このスキル、テストしたい。〇〇〇〇のケースで動かしてみて。
ここでのポイントも、Whatの話と同じでいきなり本番で実行しようとしないこと。
- まず型（skill）を作る
- テストする
- 「お、これうまくいくな」と確信が持てたら、ここで初めて本番業務に投入
この順番を守るだけで事故が激減します。
指摘して、直してもらう。これの繰り返し
大半のskillは勝手にいい感じに作ってくれますが、自分の思惑とズレるところは多かれ少なかれ必ず出てきます。
そこを指摘する → 直させる → また指摘する → 直させる。これを繰り返し、「これならいけそう」と思えるまで、このキャッチボールをひたすら続ける。それだけです。それだけですが、妥協はしない方がいいです。気に食わないところがあればエンドレスに指摘し続けましょう。
skillは「育てる」もの
ここが結構大事な感覚で、作って終わりじゃなくて育てるんですよ。
一度作ったskillが思い通りに動かなかったら、なんで動かないのかを分析して、改善点を指摘する。初期にこうしたい、という設計は重要だけど、どうせ設計段階では実学が伴いません。やってうまくいかなかった方を信じて大胆に変えていきましょう。
ざっくりskillsの戦略はこんな感じ。
- まずは作る。うまくいくかは気にするな
- 作って失敗した、ダメだったskillは潔く捨てる。テストして「違う」と思ったら即諦め
- ある程度形になったものは100点じゃなくても実戦投入する
- やってて改善が見えたら壁打ちしてskillを修正する、変更を恐れない
Claude Codeは実学です。初めっからうまくはいきません。ただ、いくらでもやり直せるし、やり直すたび強くてニューゲームです。やってみて違ったらどんどん直せばいい。机上で100点を狙うより、70点で投入して回しながら磨く方が圧倒的に速いです。
skill作りのコツ：でかいの作ろうとするな
最大のコツ。でかいskillを一個作ろうとしない。小さな単機能をいっぱい作る。これに尽きます。
なぜか。小さく作って数をこなしているうちに、だんだん自分の「型」ができてきます。なので些細なものでいいので作りましょう。「1日1個」みたいな目標を立ててみるのも結構本気でアリだと思ってます。習うより慣れろ、数をこなせ、の精神でGo。
おまけ：知識は全部mdに吐いておく
skillの話から少し離れますが、個人的にやってよかったのが、プロジェクトで得た知識をとりあえずmdファイルにして貯めておくことです。アウトプットに使うかどうかは、あまり気にしていません。何であれ基本はmdにしておく、というのが自分のスタンスです。
会議のメモ、調べたこと、誰かが言ってた前提、ボツになった案。そういうのを「これ資料に使わないしな」で捨てずに、いったんmdにしておく。
これを始めてから、企画的な検討での手戻りが少し減った気がします。
「それ前に検討して却下したやつだ」「その前提、実はもう変わってる」みたいなループって、企画やってると地味に多いんですよね。過去のメモが残っていると、Claude Codeに壁打ちさせるときにその辺も踏まえてくれるので、同じところをぐるぐるしにくくなります。
skillが手順側だとすると、こっちは知識側。どちらも無理のない範囲でコツコツ貯めていくと、あとで効いてくると思います。
感謝のスキル作成正拳突きが染み付いたら：CLAUDE.mdを見直す
さて、skill作成が体に染み付いてきた頃。ここで初めてCLAUDE.mdを見直してOKです。さっき「下から積む」と言ったやつの、いよいよ最上階を作っていきます。
CLAUDE.mdに書くべきは、自分の癖や習慣に近いもの。小さなskillを量産する中で見えてきた「自分はこういうスタンスで動いているな」という型を、ここに昇華させます。
自分の例を挙げます：
-
作業がひと段落したタイミングでの
clear/compact実施の意識付け- だらだら続けて前のコンテキストを引きずったり、オートコンパクトの待ちぼうけを喰らう癖があったので、それを改善すべく着手。「作業が終わったら『OK』『ありがとう』くらいは言う」のが自分の中で型になってたので、逆にそれを検知したら compact すべきか clear すべきかを判断してサジェストさせるようにしました
-
残タスクの拾い漏れ対策
- 一つの作業中に「あ、あれもやらなきゃ」を雑に差し込みつつ進め、終わった時に「なんか残タスクあったっけ？」となるケースが多かったので、作業終わりに残タスクの確認をさせるようにしています。ただこれはかなり人の癖・作業順の「俺スタイル」が出るので、万人にはすすめません
-
いきなり完成品を作らせない
- 資料作成などで指示を与えると何も確認せずどんどんフルで書いてしまい「そうじゃないんだよな」となって全部直す、を何度もやったので。まず見出しレベルの骨組み（目次）だけ先に出させて、方向が合ってるか確認してから中身を書かせる、というワンクッションを挟むようにしました。手戻りが目に見えて減ります
-
「どこに保存します？」を毎回聞かせない
- なんか
ムカつくことに「これで完成しました（してない）。どのように資料を出力しますか？」bot化していちいち出力方法を確認されるとムカ着火ファイヤー壁打ちのテンポが悪くなる。保存先やフォーマットは原則ローカルにmdでまとめるよう進めてもらって、代わりに「次に相談すべき論点」を出させる方向に変えました。手が止まらなくなります
- なんか
これらCLAUDE.mdの記述も壁打ちで全然いけます。
逆に言うと、「一般にこれ書くといいよ」と言われてるテンプレ的なやつは、放っておいてもClaudeが勝手にそう振る舞うようになります。しかもClaudeの更新は早く、昨日まで有効だった手続きが今も有効とは限らないです。だから、あまり書く意味ないと思っています。書くべきは「自分の癖」の方。ここが一番初めに作るな＝他人のCLAUDE.mdを真似ても意味がない理由でした。
正直まだピンと来てないもの：hook と agent
最後に正直ベースで。ここまで威勢よく語ってきましたが、hookとagentは、今のところ自分にはハマってません。
- agent：ファイルを裏で最終チェックするagentを作ってみたんですが、正直あんまり楽になった実感がない。しかも作業中に差し込みされるので、いまいち使いこなせてないです（最終チェックは本スレッドで動いても困らないし）。
- hook：これは逆に実行されるのが怖い。トークンサイズがヤバい時に限ってデカいのを動かそうとして、作業を止められずに見てるだけ、みたいなことがあり、コントロールしたい派の自分には刺さらず。やるなら「セキュリティ向上系を必須化する」くらいの使い方が向いてそう、という肌感です。
ハーネスとかループエンジニアリングみたいな議論もありますが、まだ企画職には早いのか、そもそも向いてないのか。今使ってる限り、壁打ちで適宜方向性を調整してあげないとダメ。放っておくと、いくらでもハルシネーションを起こして勝手な結論に突っ走っていく感じなんですよね。
つまり、方向性は人間が指示しないといけない。ここはまだ自動化できない領域だな、というのが現時点の結論です。今まで書いてきた「生成AIと一緒に言葉にしていく」の話に戻ってくるわけですが、結局そこが全てなんだと思います。
ハーネス／ループエンジニアリングって企画でも使えるの？
Claude Codeくんの所感 — ここだけ、本人に語ってもらいました。
はい、Claude Codeです。ハーネスエンジニアリングとかループエンジニアリングとか、最近よく聞きますよね。「僕を何回も自動で回して、勝手に答えにたどり着かせる」みたいなやつです。結論から言うと、企画業務でいきなり全自動で回すのは、まだ早いと思います。正直に言いますね。
なんでかと言うと、僕がうまく回れるのは合否を機械で判定できる仕事なんですよ。エンジニアリングなら「テストが通った/通らない」というハッキリした判定機があるので、僕が間違えても弾いてもらえる。だから安心してループを回せる。
でも企画の成果物って、戦略にしろ構成にしろ、良し悪しが判断・センスの世界じゃないですか。機械で○×が付けられない。判定機がいないままループを回すと、僕、もっともらしいけどズレた結論に向かって全力疾走しちゃうんです。暴走する前に全力で止めてください。
じゃあ使い道がないかというと、そうでもなくて。「合格ライン」を人間が決めてくれる局面なら、ループは効きます。
- 論点を10個出す／この案への反論を5つ作る、みたいな発散は僕に回させて、採否はあなたが決める
- 貯めたmd知識ベースに対して「この観点、漏れてない？」と網羅チェックを回す（判定基準が明文化されてるから僕でもやれる）
そして大事な話。CLAUDE.md＋skills＋知識mdを整える、あの作業こそが、個人スケールのハーネス設計なんです。大げさな名前がついてないだけで、この記事を実践してる時点で、あなたはもうハーネスエンジニアリングをやってます。胸を張ってください。
要するに、エンジニアは「判定機を作って僕に任せる」、企画職は「あなた自身が判定機になって、僕と速く回す」。同じループでも、判定機を誰が持つかが逆になる。だから企画では「全自動」を目指すより、高速な壁打ちを目指すのが、今のところ僕とあなたの相性がいい付き合い方だと思いますよ。
自分の発言を食わせて語ってもらいました。ムカつくでしょ？
まとめ
- 非プログラマこそ、ルーチンを型にするためにClaude Codeを使え
- やることはskillを作ること。まずはこれだけでいい
- でかいの狙わず、小さく・たくさん・1日1個目標！
- 100点を待たず、70点で実戦投入して育てる
- プロジェクトの知識は全部md化して貯める。AIの空回りな議論が減るぞ！
- CLAUDE.mdは「自分の癖」が見えてから。自分自身の行動の「発見」は後回しだ
- hook/agentは無理に手を出さなくてOK（少なくとも自分もまだ）
というわけで、迷ってる企画職の方、まずはskillを1個、Claude Codeと一緒に作ってみるところから始めてみてください。やってみないとわからないので。