Agent Skillsとは。業務手順書の設計8つのコツを風音屋の記事で整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、風音屋TechBlogが2026年10月30日に公開した記事を紹介します。AIエージェント向けの業務手順書「Agent Skills」の設計方法を扱った記事です。

この記事は、私がブックマークに保存していたものです。手順書は頼む相手を選ばない。止める所を先に決める。訂正はその場の一言で終わらせない。私が過去の記事で書いてきた考え方です。それを日程調整のスキルを題材にした8つのコツとして、順に整理してくれていると読みました。

読み方の筋は次の通りです。AIが質問攻めになる理由から入ります。次に、暗黙知の書き出しを見ます。プログラムと出力先の分け方、ファイルの分け方、承認ゲートへ進みます。そのあとテストと試運転、失敗から育てる流れです。最後は、手順書づくりにAIをどう使うかを書きます。ここは私の考えです。

風音屋TechBlogの記事（スキルは新入社員に渡す手順書、の話）

AIに対して、この「新入社員に渡す業務手順書」の役割を担うのが「Agent Skills」（以下、スキル）です。

スキルは、新入社員に渡す業務手順書の役目をAIに対して担うもの。これがゆずたそさんの出発点です。風音屋のゆずたそさんが、2026年10月30日に公開した記事です。

AIに「日程調整をやっておいて」と頼むと、たいていは2つのどちらかになる、と始まります。ここが入り口です。

1つ目は質問攻めです。「何時間の打ち合わせですか」「相手はどなたですか」と聞かれます。頼む側が全部答えるまで動きません。2つ目は、聞かずに候補を並べてくるパターン。

ただ、集中作業のために空けている曜日や祝日が混じります。ランチ時間にまたがる時間帯も、平気で入ってきます。どちらも困ります。

違いを生むのは、AIの性能ではないそうです。業務手順と、ドメイン知識（その仕事の世界の決まりや前提）を渡したかどうか。新入社員に任せる場面で考えると分かりやすいですね。

先輩は口に出さない判断基準を無数に持っています。「水曜はノー会議デーなので入れない」「ランチの時間帯には打ち合わせを入れない」「候補は少なくとも3日分を並べる」といった具合です。

この暗黙知（言葉にしていない判断のやり方）を渡さず「よろしく」と頼むとどうなるか。新入社員は質問しに来ます。または聞かずに独自解釈で進めて、事故を起こします。AIも同じです。

「Agent Skills」、以下スキルは、AIに読ませる前提で書かれた業務手順書のこと。Claude Codeでは、スキルのフォルダを .claude/skills/ に置くだけです。

置く場所はそれだけです。依頼内容に応じて、AIが自動で読み込みます。

サンプルのスキルは6つの部品でできています。何をするか、いつ使うか、どこまで書き込んでよいかの要約。使ってよい道具の宣言（allowed-tools）。手順ステップ。判断基準の表。NG例とOK例。

参照リンク。allowed-toolsだけは、人間向けの手順書に無い、AIならではの項目です。

8つのコツは、書く（①〜④）、守る（⑤）、確かめる（⑥〜⑦）、育てる（⑧）の順に並んでいます。AIに任せたいと思うと、つい性能やプロンプトの言い回しを考えます。

この記事が先に見る場所として示しているのは、渡している紙の方。私はそう読みました。質問攻めにされた場面か、勝手に進められた場面を1つ思い出しながら読むと、入りやすいと思います。

風音屋TechBlogの記事（背景をセットで書く、の話）

時間帯ポリシーの「水曜は入れない」は、規則だけでなく「打ち合わせを入れない曜日を1日確保し、集中作業や突発対応に充てる」という背景をセットで書きます。

水曜は入れないという規則だけでなく、なぜ入れないのかという背景もセットで書く。これが最初のコツです。

日程調整でいちばん苦労するのは、手順そのものより判断基準を言葉にすることだ、とゆずたそさんは書いています。ベテランが無意識にやっている判断は、聞き出さないと出てきません。

スキルでは、判断基準を独立した節に書き出しています。

1つ目は予定の3分類です。重複してもよい予定（自分が出なくても成立する社内イベント）。相談すれば動かせる予定（社内の1on1や任意参加の会）。動かせない予定（取引先との打ち合わせや採用面接）。

この3つです。この分類が無いと、AIは全部の予定を同じ重みで扱います。そして「社内イベントがあるので候補が出せません」と言い出します。

2つ目は時間帯のルール。業務時間は月・火・木・金です。水曜はノー会議デー、ランチ枠は外します。空き枠は丸（推奨）、三角（許容）、バツ（除外）の3ゾーンに分けます。祝日・年末年始・お盆はバツです。

候補は5日以上のユニークな日付を目標にします。確保できなければ3日まで妥協します。同じ日に偏らないよう、散らします。

水曜のルールには、打ち合わせを入れない曜日を1日確保し、集中作業や突発対応に充てる、という理由が添えられています。理由があると、AIが相談できます。

4月に期初を迎えたお得意様の役員と、1年間の方針を決める会議が来た時も、「水曜ですが例外にしますか」と聞けるんです。規則だけだと、ただ断るか、黙って破るかになりそうです。

毎回聞くことと、聞かなくてよいことの線引きも書きます。所要時間と希望期間は初期値を持たないので、必ず聞く。60分のつもりが90分の会だった、は事故になるからです。

時間帯や候補数のように、判断基準に沿えば決まるものは、聞かずに進めます。この線引きがあれば、毎回全項目を確認しに来るAIにはなりません。

AI氣道『SKILL.mdはAIに渡す作業マニュアル。河村風真さんが動画編集スキルの中身を公開した動画を見た』より

「マニュアルの良さは、頼む相手を選ばない所。上司が部下に渡しても、別のセッションのAIに渡しても、同じ紙を読めば同じ所から始められます。」

手順書は頼む相手を選ばないという話を、私は『SKILL.mdはAIに渡す作業マニュアル。河村風真さんが動画編集スキルの中身を公開した動画を見た』で書いています。

風音屋の「暗黙知を紙にする」と、私の「頼む相手を選ばない」は、同じ向きだと考えています。誰が頼んでも同じ出来になる手順書は、人にもAIにも効くはずです。

上司から部下でも、別のセッションのAIでも、同じ紙を読めば同じ所から始められます。ここが強みです。

自分の会社で「いつもこうしている」と言葉にしていない判断を、1つ書き出してみてください。それが手順書の最初の1行になります。まずは1つで足ります。

風音屋TechBlogの記事（数え直しをAIに任せない、の話）

AIに毎回数え直させると、たまに件数を間違えたり、同じ入力で日によって違う結果を出したりします。

AIに毎回数え直させると、件数を間違えたり、同じ入力で日によって結果が変わったりする。この指摘がこの章の入り口です。

スキル設計でいちばん間違えやすいのは、何でもAIにやらせようとすることだそうです。日程調整のスキルでは、次の処理をPythonのスクリプトに固定しています。AIの自由裁量は認めていません。

自分のカレンダーの空き枠を30分単位で探す。候補が丸・三角・バツのどのゾーンかを判定する。予定同士の重なり（ダブルブッキング）を種別で分ける。候補を日付で散らして選ぶ。

「リスケ必要5件、リスケ不要4件」のような冒頭の件数をまとめる。

どれも、入力が同じなら出力も同じに決まる処理です。逆に、答えが1つに決まらない仕事は、AIの担当になります。似た予定が同じものを指すと判断する。取引先への依頼文を書き上げる。そういう仕事です。

役割分担の例が分かりやすいです。依頼文の冒頭の1文を、候補日の日数で切り替える表があります。3日以上なら「以下日程でいかがでしょうか。

」、2日なら「候補日が少なく恐れ入りますが、以下日程でご検討いただけますと幸いです。」、1日なら「決め打ちとなってしまい恐れ入りますが、以下日程でご検討いただくことは可能でしょうか。」。

日数はスクリプトが数えます。AIは選ばれた文面を組み立てるだけです。「候補が少なくて申し訳なさそうに書いて」と丸投げすると、日によってトーンがぶれます。

③は出力先の話です。月次のカレンダー衝突チェックでは、結果を手元のターミナル画面と、共有チャットの両方に出します。共有チャットには、リモートアシスタント（秘書会社）も参加しています。

日課のランニングや月末の経費申請のように、自分の作業時間を確保する予定を「自作ブロック」と呼びます。候補に重なっても自分で動かせるので外さず、注記を添えます。

注記は3段階です。手元の画面（本人だけが見る）は「※自作ブロックあり」にタイトルを添えます。共有チャット（社外も閲覧）は「※担当者の別予定ありだが調整可能」。取引先向けの依頼文では、注記自体を出しません。

本人向けなら詳細まで、社外も見る場所なら抽象的に、取引先向けなら省く。一度決めれば、以降は同じ判断で書き出せます。内部処理用の英語ラベルと、読み手に見せる日本語の表記を分けて持つ工夫もありました。

出力先ごとに書式が違う場合は、「Slack用スキル」のような出力先ごとのスキルに切り出せます。

計算を数えるのは機械、言い回しを整えるのはAI。この分け方は、人に仕事を頼む時の「ここまでは決まり、ここからはお任せ」と同じ形だと私は読みました。自分の仕事で、毎回同じ結果になる作業を1つ選んでみてください。

風音屋TechBlogの記事（同じ手順を書き写さない、の話）

同じ業務手順を複数のスキルに書き写すと、片方だけ更新されて食い違うのは時間の問題です。

同じ業務手順を複数のスキルに書き写すと、片方だけ更新されて食い違う。これがこの章の核です。スキルを1つのMarkdown（書式つきの文章ファイル）に全部書き込むと、すぐ読めなくなります。

日程調整のスキルは、役割ごとにフォルダを分けています。

SKILL.mdは索引で、何をするか、いつ使うかを書く。runbook/には業務手順書が2本、単発の日程調整と月次の衝突チェック。specs/は空き枠計算や衝突判定の仕様の正本です。

qa/は試運転の手順と実施レポートです。改修のたびに回して、デグレ（直した時に前はできていたことが壊れること）を防ぎます。

references/は業務時間の考え方や依頼文のトーンなど、社内ルールの抜粋。scripts/は答えが1つに決まる処理のプログラム、tests/はそのテストです。

手順書の側に「ゾーン判定の詳細はspecs/analysis.mdを参照。scripts/analyze.pyの実装はこの仕様書に合わせる」と1文置いておく。

すると、仕様と実装がずれた時に、どちらを直せばよいか分かります。「文面のトーンはreferencesの該当ファイルを参考にする」と書いておけば、AIがその場のノリで独自のトーンを作るのも防げます。

責務を分けると、触る場所が決まります。業務の要件が変わったら手順書だけを書き換えます。計算ロジックが変わったら仕様書とスクリプトだけで済みます。

業務手順書を部品に分けて組み合わせる、モジュール化の考え方ですね。分割は、1つのスキルの中だけでなく、スキルをまたいでも行います。

共有チャットへの投稿手順は別スキル（mcp-slack）に切り出し、日程調整スキルからは「投稿する時はこのスキルに従う」とリンクするだけにしています。

1枚の紙に全部を書くと、直す時にどこを触ればいいのか分からなくなります。引き出しにラベルを付けて整理するのと同じです。置き場所が決まっていれば、直す人は迷いません。

その人が人でもAIでも同じだと私は思います。自分のAI用の指示書が1枚で長くなっていないか、1度見てみるのもいいかな。

風音屋TechBlogの記事（承認を何度も求めない、の話）

承認を何度も求めると、承認する側の負担が増えてかえって危険です。面倒くさくなって流し見されるからです。

承認を何度も求めると、承認する側が面倒になって流し見する。かえって危ない、という指摘がこの章の入り口です。取引先へのメールや依頼文のように、社外に出るものは、AIが自動で送らない設計です。

AIが文面を本人に見せ、本人が承認してから送ります。

承認ゲート（送る前に人が確認して許可する関所）ですね。日程調整のスキルでは、Step 4の送信前の承認を3段で組んでいます。

1段目は、送信先、所要時間、候補日時、依頼文の全文を、1回でまとめて見せること。「送ってよいですか？」だけの問いかけは禁止で、内容をすべて見せます。

2段目は、判断が要る箇所を選択肢で聞くこと。自由回答ではなく、(a)AIがこの文面のまま送る、(b)候補日を差し替えて作り直す、(c)今回は本人が送る、のように並べます。

3段目は、承認された内容だけを送ること。承認された範囲を超えて、追加の調整を勝手にしません。

判断を仰ぐ時は、事実とAIの解釈を別々に見せます。事実は「候補時間帯には既存の予定が入っている」。解釈は「別の候補に振り替える必要がある」といった具合です。

事実だけを並べて解釈を選択肢にすると、「事実は同意だけれど、判断は別の案でいきたい」と返す余地が残ります。選択肢の形にしておけば、何を決める場面なのかも、はっきりします。

AI氣道『AIに仕事を任せるなら、送信の手前で止めて最終チェックだけは人が持つ』より

「私には、止めなさすぎたことがあります。5月の時点で、朝LIVEの告知を作る自動の仕事の指示には、1時間返事が来なければ先へ進める、という一文がありました。」

止める所を先に決めるという話を、私は『AIに仕事を任せるなら、送信の手前で止めて最終チェックだけは人が持つ』で書いています。

風音屋の「社外に出るものは本人が承認してから送る」という線と、私の経験を並べてみます。私の場合は、止めなさすぎた方でした。

その1文があったせいで、私の返事を待たずに告知の3点が作られ、私のChatworkへ送られてきました。私は「勝手にやった」「1時間でも10時間でも勝手にやるのは禁止」と伝えました。

その一文を3本の指示から消しました。

題材は、風音屋が日程調整、私は朝LIVEの告知づくりと違います。それでも、勝手に先へ進む余地を指示の中に残さない、という点で重なっていました。

止める線は、送る操作かどうかでなく、そこが私の決める所かどうかで引く。私はそう考えるようになりました。

AIに任せている作業のうち、本人の確認なしに外へ出てしまうものがないか。1つ探してみると、最初に置く関所が見えてきます。

風音屋TechBlogの記事（新入社員に渡して確かめる、の話）

手順書の完成度は「新入社員に渡してやらせてみること」で検証します。

手順書の完成度は、何も知らない相手にやらせて確かめる。これが⑥と⑦に共通する発想です。⑥はテストです。

プログラムに切り出した処理は、pytest（Pythonのプログラムを自動で確かめるツール）でテストにできます。

判断基準の1つ1つに、この入力ならこの出力になるはず、を固定します。テストファイルの冒頭には、観点の一覧をdocstring（プログラムの中に埋め込む説明文）で書きます。

何を確認するテストかが、最初の画面で分かるようにしています。

起点は過去の失敗です。参加辞退した予定をダブルブッキングとして数えてしまう不具合が見つかったら、そのケースを再現するテストを足します。一度決めた除外ルールもテストで固定します。

改修で壊した瞬間にテストが赤くなって気付けます。合意事項が「気付いたら消えていた」を防ぐ仕組みです。

水曜の深夜から木曜にまたがる夜間メンテナンスの立ち会いや、お盆の日付の境界のように、実運用で1度でも出会ったパターンも残します。

⑦は試運転です。過去のやり取りを一切知らない別のAIに、手順書だけを渡して最初から実行させ、意図した成果物が出るかを見ます。

担当のAIには、前回どこで間違えたか、レビュー指摘の内容、直前の改修意図を渡しません。渡すのは、スキル本体、手順書、仕様書、作業対象への行き方だけです。

理由は2つ。書き忘れがあれば、事前情報を持たない側が必ずつまずいてくれること。実運用でもこのスキルは、文脈を持たない別のセッションから呼ばれること。終わったら結果を鵜呑みにしません。

自己申告と成果物を突き合わせます。項目ごとに「適用した」「該当なし」「違反あり」を申告させ、成果物に適用が現れていなければ、手順書の書き方に曖昧さがあります。

この試運転を、改修のたびにレビューの前に1度回す運用だそうです。

私にも、近い経験があります。私のAI用の指示ファイル（CLAUDE.md）に「書く前にSKILL.mdを読み」とやわらかく書いた1行は、AIに試させた4回とも無視されました。

同じ会話の中で動かしたAI2本と、新しく起動したAI2本です。

「書き始める前に必ずReadする（読まずに書かない）」と強めたら、新しく起動した2本とも読みました。Readはファイルを開いて読む操作のことです。

追加した後は、新しいプロセスのログで、本当に読んだかを確かめることにしています。

風音屋の「事前情報を渡さない試運転」と、私の「新しく起動したAIで確かめる」は、同じ向きだと私は読みます。自分が書いた指示書を、何も知らないAIに渡して1回やらせてみる。

書いた本人には見えなかった抜けが出てくるはずです。

風音屋TechBlogの記事（背景を書いておくと削られない、の話）

背景を書いておくと、後の改修で「このステップは冗長では」と削ろうとしたAIが、思いとどまってくれます。

背景を書いておくと、後の改修で手順を削ろうとしたAIが思いとどまってくれる。これが⑧の要です。スキルは作って終わりではなく、使いながら失敗から育てます。

対象予定の識別の仕様書には、欠席で返した予定をダブルブッキングとして数えてしまった取りこぼしの理由が書かれています。

2026年6月のインシデントを受けて追加した、削る時は当時の記録を確認する、と添えられています。例外の追加もなし崩しにはしません。本人がはっきり決めたものだけを除外リストに足す運用です。

スキルの整備そのものも、AIに頼めます。「この手順書を読んで、抜け漏れがあれば直して」と頼めば、AIが手順書を改修してくれます。ただし、更新したら変更後の手順をAIのレビューに通します。

人間が確認してからコミット（変更を正式に記録すること）する、という流れも手順書に書いておきます。

AI氣道『AIへの訂正は、その場の一言で終わらせない』より

「AIへの訂正は、その場の一言で終わらせない。次に同じ言葉が引き出される時にまた縮んで読まれたら、訂正した意味がありません。」

訂正をその場で終わらせないという話を、私は『AIへの訂正は、その場の一言で終わらせない』で書いています。

私は訂正を、その日のやり取りの記録、判断軸の正本の注記、記事や動画に使い回す文章カードの3か所に残しました。

私のAI用のルールのファイルのうち「事故」の節があるものは、2026年11月3日に数えて48本あります。事故、原因、やること、戻し方の順で、失敗を手順に書き足しています。

2026年10月8日、AI氣道のステップメールを分身AIを通さず書き直した時のことです。私は「なんでこんな文章の質が低いの？分身AIひろくんが書いてるの?出だしも違うし」と指摘しました。

あとで、今後いわなくても、と答えました。そこから、ひろくん名義の文章は分身AIが書くというルールのファイルができました。

AIの使い方は、私の考えとして3つです。1つ目は聞き取り役。書き出せない判断基準を、AIに1問ずつ質問してもらい、答える形で書き出します。判断はさせず、聞き取りと整理だけを頼みます。

2つ目は点検役です。書いた手順書を、前提を知らない別のAIに渡し、抜け漏れと曖昧な所を指摘してもらいます。直すかどうかは自分で決めます。

3つ目は、外に出る操作と取り消せない操作をAIに任せず、承認ゲートを先に置くこと。AIの出力は、そのまま貼らず、自分の言葉で読み直します。

始め方は小さくて足ります。時間がかかって今後も繰り返しそうな作業を1つ選び、手順書1枚から。元記事も、8つのコツを最初から全部そろえる必要はない、と言っています。

風音屋のゆずたそさんの記事は、AIが質問攻めになるか独走するかの違いを説明していました。AIの性能ではなく、業務手順とドメイン知識を渡したかどうかです。新入社員に渡す業務手順書が、AIにとってのスキルです。

8つのコツは、書く、守る、確かめる、育てるの順でした。暗黙知を理由つきで書き出します。答えが決まる処理はプログラムに任せ、出力先ごとに書き分けます。ファイルは役割で分けます。送る前は人が承認し、テストと別のAIでの試運転で確かめます。失敗から手順を足していきます。

私は、手順書は頼む相手を選ばないこと、止める所を先に決めること、訂正はその場の一言で終わらせないことを、この8つのコツに重ねて読みました。AIは手順書づくりの聞き取り役と点検役に使います。外に出る操作の承認は人が持ちます。

読み終えたら、自分の仕事から、時間がかかって今後も繰り返す作業を1つ選びます。まず頼む側の判断基準を書き出します。次に止める所を決めます。最後に手順書だけを別のAIに渡して試す。この順で、手順書1枚を作り始められます。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！