自分の仕事をスキルにする最初の一歩｜定型業務の見つけ方と書き方
非エンジニアPdM #業務自動化 #スキル作成 #定型業務 #AI活用 #ClaudeCode #プロンプト設計 #業務効率化 #再現性 #自動化入門
はじめに
「業務をAIで自動化する」と聞くと、エンジニアが複雑なプログラムを書くイメージを持つ人が多いと思います。私もそう思っていました。
でも実際にClaude Codeを使い始めてわかったのは、「スキル」というのはほぼ普通の文章です。「こういうときに、こういう順番で、こういう結果を出して」と書いた指示書が、スキルの実体です。難しいのはプログラミングではなく「自分の仕事の手順を言葉にすること」でした。
毎週当たり前にやっていることを「何をどの順番で判断しているか」に分解する作業が、最初は思ったより手間がかかりました。でもその作業をすると、無駄な手順に気づいたり、暗黙の判断基準が見えてきたりと、副産物も多かったです。
私は非エンジニアのPdM（プロダクトマネージャー）です。コードは書けません。でも今ではスキルを10本以上作って、週に繰り返していた業務の「最初の60〜70%」をAIが担ってくれています。この記事では、私が最初のスキルを作るときにたどった「定型業務の見つけ方」と「スキルへの書き起こし方」を、具体的な手順と一緒にお伝えします。
結論
スキルとはAIへの定型指示書です。「いつ使うか（発動条件）」「何をどの順番でやるか（手順）」「何が出たら完了か（合否チェック）」の3点を書けば、最初のスキルは完成します。難しいのはコードを書くことではなく、自分の業務を言語化することです。
目次
スキルとは何か──最小定義
定型業務の見つけ方──「繰り返し」と「ブレ」を探す
スキルに向いている業務・向いていない業務
発動条件を先頭に書く理由
手順の書き方──「決定的ルール」で曖昧さを消す
完了チェックリストの作り方
最初のスキルを一から書くときの実例
スキルが動いた日の話──最初の感触
最初のスキルを育てる方法
従来の課題と目指す姿
1. スキルとは何か──最小定義
Claude Codeにおけるスキルとは、ホームディレクトリの .claude/skills/ フォルダに置いたMarkdown（テキスト形式の文書）ファイルです。ファイルに書いた内容がAIへの「固定指示」として機能します。
/note-upload や /review-core のように、スラッシュ＋スキル名で呼び出せます。呼び出すと、そのファイルに書かれた手順をAIが実行します。
最小構成で必要なのは3つだけです。
「いつ使うか（発動条件）」：どういう状況でこのスキルを呼び出すか。AIがスキル一覧を見て適切なものを提案するときの手がかりになります。
「何をどの順番でやるか（手順）」：1・2・3と番号をつけて書きます。順番が重要な場合は「Aが完了してからBをやる」と明示します。
「何が出たら完了か（合否チェック）」：完了の定義を書きます。「下書き保存された」「ファイルが指定フォルダに存在する」など、確認可能な状態で書きます。
これだけ書けばスキルは動きます。最初は3〜5行でいいです。
よく「スキルってどれくらい書けばいいですか」と聞かれますが、答えは「動けば十分」です。100行の完璧なスキルより、10行の動くスキルのほうが100倍価値があります。書いてから足していけばいい。
2. 定型業務の見つけ方──「繰り返し」と「ブレ」を探す
スキルに向いている業務の見つけ方は、2つの問いで絞り込めます。
「週に1回以上やっている業務はどれか」──繰り返し頻度が高いほど自動化の効果が大きいです。私の場合は週次の進捗レポート作成、問い合わせメールの返信下書き、議事録の整形でした。どれも「毎週やるのになぜかゼロから始めている」業務でした。
「同じ業務でも仕上がりにブレが出ることがあるか」──「なんとなく」「感覚で」やっている業務は、スキル化することで品質が安定します。逆に言うと「ブレが出る業務」はスキル化の候補です。ブレが出るということは、判断基準が言語化されていないサインです。
実際の探し方として、私がやったのは「先週の作業ログを振り返ること」です。Jiraのコメント履歴・Slackのメッセージ・Googleカレンダーを15分眺めて、「これ先週もやったな」と思ったものを付箋に書き出しました。出てきたのは12個。そのうち「週1以上かつブレが出ている」は4つでした。
その中で「完了の定義が一番明確だった」のが週次進捗レポートの下書き作成でした。所要時間は30〜45分。毎週月曜日にJiraの完了チケット一覧を見ながらマネージャー向けの進捗サマリーを書いていました。内容は毎週似たような構造なのに、なぜか毎回ゼロから書いていました。「これは絶対スキル化できる」と思い、そこから始めました。
3. スキルに向いている業務・向いていない業務
向いている業務を先にまとめます。
入力が「決まった形式のデータ」で、出力も「決まったフォーマット」の業務。週次レポート・議事録・返信メール下書きなどが典型です。手順が毎回ほぼ同じで、判断の余地が少ない業務。完了の定義が明確（「下書きが保存された」「ファイルが生成された」）な業務。
向いていない業務も正直に書きます。
初回だけ・めったにやらない業務（効果が薄い）。「最終判断が案件ごとに大きく変わる」業務（営業交渉の着地点判断、クレーム対応の謝罪文の温度感など）。法的・倫理的に人の判断が必須な業務（人事評価、解雇関連など）。
「向いていない業務」でも「下処理だけスキル化する」という使い方はあります。たとえば営業交渉の場合、「企業の基本情報を整理する」部分だけをスキル化して、交渉戦略は自分で決める、という切り分けです。私はこれを「前半をAIに、後半は人が握る」と呼んでいます。このパターンで考えると、ほとんどの業務がなんらかの形でスキル化できます。
判断の目安としては「この業務を後輩に初めて頼むとき、何を伝えるか」を言語化できるなら、スキル化できます。言語化できないなら、まず言語化することから始めます。その作業自体が業務の整理になります。
4. 発動条件を先頭に書く理由
スキルファイルの先頭に必ず書くべきことがあります。「いつ、このスキルを使うか」という発動条件（トリガー）の説明です。
なぜ先頭に書くかというと、Claude Codeはスキル一覧を参照して「今の状況に合うスキルを提案」できます。このとき参照されるのが説明文の先頭部分です。発動条件が先頭にないと、適切な場面でスキルが提案されません。
実際に私がやらかした失敗があります。最初に作った週次レポートスキルの説明文の先頭が「Jiraチケットのサマリーを生成するスキル」になっていました。発動条件が曖昧すぎて、「週次レポートを作って」と言っても候補として出てこないことがありました。「週次レポート作成」と入力してから手動で呼び出すことになっていた。これは単純に説明の書き方の問題でした。
書き方の例を見てみます。
悪い例：「週次レポートを作成するスキル」 良い例：「毎週月曜日にJiraの完了チケット一覧を渡されたとき、または『週次レポートを作って』と言われたときに使う。Markdownで進捗サマリーを下書き作成する」
良い例は「いつ使うか」「何を渡すか」「何が出るか」が一文で読み取れます。
発動条件は「Use when the user asks...（ユーザーが〇〇と頼んだときに使う）」という形式で書くと、英日混在の環境でも確実に認識されます。私のスキルには全てこの形式を採用しています。
5. 手順の書き方──「決定的ルール」で曖昧さを消す
手順を書くとき、最初によくやる失敗が「曖昧な言葉を使う」ことです。
「適切にまとめる」「いい感じに整理する」「必要に応じて修正する」──これらは人間が読めば意味が伝わる気がしますが、AIに渡すと解釈がブレます。実行するたびに違う結果が出ます。
「決定的ルール」とは、解釈の余地がない指示のことです。判断基準は「この指示を初めて見た人が10人いたとして、10人が同じ動作をするか？」です。9人が違う行動をするなら、その指示は曖昧です。
変換の例を並べます。
「適切にまとめる」→「箇条書き5項目以内にまとめる。各項目は40文字以内」
「いい感じに整理する」→「完了タスクを部門別にグループ化し、部門名を見出しにして箇条書きで列挙する。部門の順序は件数が多い順」
「必要に応じて修正する」→「誤字が1つ以上あれば修正する。文体がです/ます混在なら全文ですます調に統一する」
「重要な点を強調する」→「最も重要な主張1つを第1段落の最後の文として置く。太字は使わない」
数字（5項目・40文字）、形式（部門名を見出し・箇条書き）、条件（件数が多い順・誤字が1つ以上）を明示することで、同じ入力に対して同じ出力が再現されます。
私が週次レポートスキルを最初に書いたとき、手順の2番目が「Jiraチケットを整理する」だけでした。これを使ったら、ある週は日付順・ある週は担当者別・ある週は優先度別にまとめられていて、マネージャーから「フォーマットが毎週違う」と指摘されました。そこで「部門別・完了日時の新しい順・優先度Highを先頭に」と書き直したら、その後ブレがなくなりました。
6. 完了チェックリストの作り方
完了チェックリストとは「この状態になったらスキルは完了」を定義した一覧です。
これを書いておくと2つの効果があります。
一つは、AIが自分の出力を検証できます。「下書きが保存されたか」「ファイルが指定パスに存在するか」をAIが確認して、失敗していれば再実行またはエラーを報告します。
もう一つは、人が確認するときの手がかりになります。「何を確認すればいいか」がリストになっていれば、確認の漏れが減ります。
チェックリストは「あるかないか」で判定できるものと「人が判断すべきもの」の2種類に分けるのがコツです。
「あるかないか」で判定できる例：「マークダウンファイルが /週次レポート/YYYY-MM-DD.md のパスで保存されている」「部門数と完了チケット数が入力と一致している」「文体が全文ですます調になっている」。これはAIが自動判定できます。
「人が判断すべきもの」の例：「内容が事実として正確か」「マネージャーが必要とする情報が含まれているか」「先週と比べて違和感のある変化がないか」。これは人が確認する欄として分けておきます。
私の週次レポートスキルの完了チェックは現在7項目で、うち4項目がAI自動判定、3項目が人確認です。このリストのおかげで、私はレポートの「構造面」を見なくていい。内容面（伝わるか、正しいか）だけに集中できます。
7. 最初のスキルを一から書くときの実例
実際にどうファイルを作ったか、週次レポートスキルの最初のバージョン（v1.0）を再現します。
ファイル名は weekly-report.md、置き場所は ~/.claude/skills/ です。
内容はこうでした。発動条件として「毎週月曜日に進捗レポートを依頼されたとき、またはJiraチケット一覧を渡されたときに使う」。手順1として「渡されたチケット一覧を部門別に分類する」。手順2として「部門ごとに完了チケットを箇条書き3〜5件でまとめる。各項目は『チケット名（担当者名）』の形式」。手順3として「全文ですます調で、Markdownファイルとして /週次レポート/YYYY-MM-DD.md に保存する」。完了チェックとして「ファイルが存在する」「チケット数が一致する」「ですます調になっている」。
このv1.0を最初に実行したとき、出力が出るまで約40秒かかりました。「本当に動くのか」と思いながら待っていると、指定パスにファイルが生成されていました。内容を開いてみると、部門別に整理されていて、書式もほぼ揃っていました。手直しは3か所だけ。普段30〜45分かかっていた作業が、確認込みで10分以内になった瞬間でした。
8. スキルが動いた日の話──最初の感触
最初のスキルが動いたときの感触は、「思ったより地味だった」です。
劇的な演出もなく、ただファイルが出来ていた。でも翌週また月曜日が来て、レポートを作らないといけないとき、「あ、スキルがあった」と気づいて呼び出したら、また10分で終わった。その繰り返しが3週続いたとき、「これは本当に変わった」と実感しました。
最初の感触が地味なほど、長続きします。ドラマチックな変化は一時的なものが多い。「毎週10分で終わる」が続くことのほうが、生産性への貢献は大きいです。
私がスキルを育てていく中でもう一つ気づいたのは、「スキルを作る作業自体が業務の整理になる」ということです。手順を言語化しようとすると、「そもそもなぜこの手順が必要なのか」を考えざるを得ない。不要な手順を削除したり、並び順を変えたりする改善が自然に起きます。スキル化は「自動化ツールを作る」だけでなく「業務プロセスを棚卸しする」機会でもあります。
9. 最初のスキルを育てる方法
最初のスキルは完璧でなくていいです。むしろ「使いながら育てる」前提で作るほうがうまくいきます。
スキルを10回使ったら、こう問い直します。「手順のどこかで毎回修正が必要なことはあったか」「チェックリストの項目は実際に意味があったか」「発動条件の説明は正しかったか」。
問い直しで気づいた点をファイルに追記します。v1.0→v1.1のようにバージョンコメントを入れると、何をいつ変えたか追えます。私はスキルファイルの末尾に「変更ログ」として日付と変更内容を1行ずつ書いています。
私の週次レポートスキルはv1.0から始まって現在v1.4です。変化の内訳はこうです。
v1.1：「優先度Highのチケットを先頭に出す」を追加。マネージャーから「重要なものが埋もれる」と言われたため。
v1.2：「前週比でチケット数の増減をコメントする」を追加。自分で使っていて「先週より減っているな」を手動でコメントしていたことに気づいたため。
v1.3：「来週の予定チケットも末尾に追加する」を追加。マネージャーから「次週の予定も見たい」とフィードバックをもらったため。
v1.4：発動条件の文章を改善。より自然な日本語トリガーで認識されるよう調整。
4回の更新で、最初から比べるとスキルの情報量は3倍になっています。でも根幹の手順は変わっていません。「使いながら積み上げる」のが、スキルを育てる唯一の方法だと思っています。
明日試すアクション
今週やった繰り返し作業を3つ書き出す。所要時間も合わせて書く。
その中で「仕上がりにブレが出ることがある」業務を1つ選ぶ。
その業務の手順を箇条書きで書く。「決定的ルール」を意識して数字や形式を明記する。
~/.claude/skills/ に新しいMarkdownファイルを作り、発動条件・手順・完了チェックを書く。
Claude Codeで1回実行してみて、出力を確認する。修正点をメモしてスキルに追記する。
まとめ
スキルは特別な技術ではありません。「自分がよくやる業務の手順を言語化したもの」です。発動条件・手順・完了チェックの3点を書けば動きます。
難しいのは「コードを書くこと」ではなく「自分の業務を言語化すること」です。でもその言語化そのものが、業務の無駄を発見したり、暗黙の判断基準を可視化したりする副産物を生みます。
非エンジニアだから難しいと思う必要はありません。むしろ、業務の流れを一番よく知っているのは現場でその業務をやっている人です。スキルを作るのに必要な知識は、そこにすでにあります。
最初の1本を動かしてみてください。最初の1本が動いた瞬間、次に自動化したい業務が自然に浮かんできます。
