RECRUIT

風音屋では、データエンジニア、データアナリスト、データコンサルタントを募集しています。

書籍執筆者やOSSコントリビューターなど、業界を代表する20名以上のアドバイザーと一緒にベストプラクティスを追求できる環境です。

ご興味のある方は、ぜひご応募ください。

25 minute read

風音屋（@Kazaneya_PR）のゆずたそ（@yuzutas0）です。 この記事では、AIエージェント向けの業務手順書「Agent Skills」の設計方法を紹介します。 実際に私が使っている「ミーティング日程調整」スキルを題材にして、8つのコツを解説します。

はじめに

AIに「日程調整をやっておいて」と頼むと、たいていはどちらかの反応が返ってきます。 ひとつは「何時間の打ち合わせですか」「相手はどなたですか」「候補は何日分ほしいですか」と質問攻めにされて、こちらが全部答えるまで動いてくれないパターン。 もうひとつは、聞かずに勝手に候補を並べてくるものの、いざ見てみると、集中作業のために空けている曜日や祝日、ランチ時間にまたがる時間帯が平気で混じっているパターンです。

この違いを生んでいるのは、AIの性能ではありません。 「業務手順」と「ドメイン知識」を渡していないことです。 新入社員に日程調整を任せる場面を思い浮かべると分かりやすいでしょう。 その業務を担当していた先輩は、口には出さない判断基準を無数に持っています。 「水曜はノー会議デーなので入れない」「ランチの時間帯には打ち合わせを入れない」「候補は少なくとも3日分を並べる」といった具合です。 この暗黙知を渡さないまま「よろしく」と頼むと、新入社員はいちいち質問しに来るか、聞かずに独自解釈で進めて事故を起こすかのどちらかになります。

AIに対して、この「新入社員に渡す業務手順書」の役割を担うのが「Agent Skills」（以下、スキル）です。 スキルとは、AIに読ませる前提で書かれた業務手順書のことです。 たとえばClaude Codeでは、スキルのフォルダを .claude/skills/ に置くだけで、依頼内容に応じてAIが自動で読み込んでくれます。 さらに、スキル自身をAIに改修させることもできます。 新入社員がマニュアルの不備を見つけたら、その場で直してもらうのと同じ感覚です。

AIエージェントに渡す業務手順書をエージェントスキルと呼ぶことを説明したスライドで、スキルの管理画面と、メール返信の手順をテキストで書き出したスキルの記述例が並んでいる

画像はメール返信業務の例ですが、日程調整のスキルも同じ体裁で書けます。 本記事の画像は技術カンファレンス「Data Engineering Summit 2026」の登壇資料から引用しています。

日程調整という題材を選んだ理由は、暗黙知が多く、判断が細かく、失敗パターンも豊富で、スキル設計の勘所が全部詰まっているためです。 同じ考え方は「経理データからの月次コスト集計」「会議録画からのロードマップ更新」など、バックオフィスを含むあらゆる業務にそのまま応用できます。

スキルのサンプルを見る

言葉で説明する前に、スキルのサンプルを見ていただきます。 といっても、そのままの転載は難しいため、社内の情報を伏せて架空の業務設定に書き起こし、全体から一部を抜粋しています。

このスキルは複数のファイルでできています。 ファイル構成は以下のとおりで、それぞれの役割は後述します。

./skills/mtg-scheduling/
├── SKILL.md
├── runbook/
│   ├── scheduling.md
│   └── monthly-conflict-check.md
├── specs/
│   └── analysis.md
├── qa/
│   └── trial-runbook.md
├── references/
│   └── scheduling-guideline.md
├── scripts/
│   └── analyze.py
└── tests/
    └── test_analyze.py

これらのファイルから要点を1つのMarkdownにまとめたのが、以下のサンプルです。

---
name: mtg-scheduling
description: |
  What: 日程調整に関わる2つの業務手順を配下に持つ。
        (1) 単発のミーティング設定・リスケ: 相手・目的・所要時間・希望期間を確認し、空き枠から候補を提示して依頼文のドラフトを作る。
        (2) 月次のカレンダー衝突チェック: 今後の予定を巡回し、祝日・ダブルブッキングなどの衝突を検出してリスケ候補と依頼文ドラフトを提示する。
  Why: 「気付いたら会議当日」を避けるため。早く手を打つほど相手の負担が小さく、こちらも日程を確保しやすい。
  When: (1) ユーザーが「◯◯さんとミーティング設定して」等で依頼した時。
        (2) 月初・週初の予定棚卸し時、または明示的に呼び出された時。
  Where: ローカル開発環境。書き込みはユーザー承認後の共有チャットへの投稿のみ、カレンダーへの書き込みは行わない。
allowed-tools: Bash, Read, Edit, Write, Grep, Glob, Task
---

# 業務手順（1）単発のミーティング設定・リスケ

## Step 1: 依頼内容の確認（未指定ならヒアリング）

以下の必須項目のうち、依頼に含まれていないものはユーザーに聞く。
デフォルト値を持たない項目を勝手に決めない。

| 項目 | 内容 |
| ---- | ---- |
| 相手 | 先方の社名・氏名。社外か社内かの判別に使う |
| 目的 | 何のためのミーティングか。予定タイトルにも使う |
| 所要時間 | デフォルトなし。必ず聞く（例: 30分・60分・90分） |
| 希望期間 | デフォルトなし。必ず聞く（例:「来週中で」「今月中で」） |

## Step 2: 空き枠の計算（スクリプトに委ねる）

自分のカレンダーを取得したうえで、以下をスクリプト（analyze.py）で計算する。
AI側での判断は入れない。

- 空き枠の候補時間帯を◯△✕のゾーンで分類する
- 前後30分のバッファが取れない候補は◯から△に降格する
- 候補が同じ日に偏らないよう、日付を分散して5日分を目標に選ぶ

## Step 3: 候補の提示と依頼文の作成

Step 2の結果を読み、以下の2つを整形する。

- 候補提示（ユーザー向け、ラベルと補足を含む）
- 依頼文ドラフト（取引先向け、ラベルと補足を含まない自然な文章）

依頼文の宛先は「（宛先：〇〇様）」のプレースホルダにする（誤送信防止）。

## Step 4: 送信前の承認（人間の判断を待つ）

取引先向けの依頼文は、AIが自動で送らない。文面をユーザーに提示し、承認を得てから送信する。

# 判断基準

## 予定の3分類

| 分類 | 説明 |
| ---- | ---- |
| 重複してもよい | 自分は出なくても成立する社内イベント（並行で他予定を入れてよい） |
| 相談すれば動かせる | 社内1on1・任意参加の会（相手と調整すれば動く） |
| 動かせない | 取引先との打ち合わせ・採用面接（動かさない前提） |

## 時間帯ポリシー

- 業務時間: 月・火・木・金の10:00〜19:00
- ノー会議デー: 水曜（打ち合わせを入れない曜日を1日確保し、集中作業や突発対応に充てるため）
- ランチ枠: 11:30〜13:00
- ◯ゾーン: 13:30〜18:00
- △ゾーン: 10:00〜11:30、13:00〜13:30、18:00〜19:00
- ✕ゾーン: それ以外、および祝日・年末年始・お盆

# NG例／OK例

- NG: AIが候補時間帯を自分で数え上げ、「候補5件」と言いながら4件しか出さない
- OK: スクリプトが候補件数を確定し、AIは文面の言い回しだけを担う

# 参照

- 空き枠計算の詳細仕様: specs/analysis.md
- 共有チャットへの投稿手順: 別スキル（mcp-slack）を参照

「新入社員に渡す業務手順書」と体裁がそっくりなのが分かるはずです。 サンプルの構成は上から順に以下のとおりです。

  • ヘッダー：「何をするか」「いつ使うか」「どこまで書き込んでよいか」の要約
  • allowed-tools: このスキルの作業で使ってよいツールの宣言
  • 手順ステップ：依頼内容の確認から送信前の承認まで
  • 判断基準の表：予定の3分類と時間帯ポリシー
  • NG例とOK例：避けたい動きと期待する動きの対比
  • 参照リンク：詳細仕様や別スキルへの案内

このうち allowed-tools だけは、人間向けの業務手順書には無い、AIならではの項目です。 「シェル実行」「ファイルの読み書き」「検索」「別のAIへの作業依頼」といった、AIが作業に使う道具の名前を並べます。 このスキルの場合、空き枠計算スクリプトをBashで実行し、計算の中間結果をReadやWriteで読み書きするために使います。

人間が読みやすい業務手順は、AIにとっても読みやすい業務手順になります。

以降の章では、このサンプルに加えて、同じスキル配下のもう1つの業務手順である月次のカレンダー衝突チェックからも素材を引きながら、そこに込めた8つのコツを見ていきます。 各節で挟むスキル断片は、いずれも手順書・仕様書・テストを含むこのスキルの一式から切り出したものです。 並び順は「書く（①〜④）→ 守る（⑤）→ 確かめる（⑥〜⑦）→ 育てる（⑧）」の順で、スキル作りの時系列に沿っています。

スキルに込める8つのコツ

①暗黙知・判断基準を書き出す

日程調整で最初に苦労するのは、業務手順そのものよりも「判断基準の言語化」です。 ベテランが無意識でやっている判断は、多くの場合こちらから聞かないと出てきません。 日程調整スキルでは、判断基準を独立したセクションとして書き出しています。

# 判断基準

## 予定の3分類

| 分類 | 説明 |
| ---- | ---- |
| 重複してもよい | 自分は出なくても成立する社内イベント（並行で他予定を入れてよい） |
| 相談すれば動かせる | 社内1on1・任意参加の会（相手と調整すれば動く） |
| 動かせない | 取引先との打ち合わせ・採用面接（動かさない前提） |

## 時間帯ポリシー

- 業務時間: 月・火・木・金の10:00〜19:00
- ノー会議デー: 水曜（打ち合わせを入れない曜日を1日確保し、集中作業や突発対応に充てるため）
- ランチ枠: 11:30〜13:00

## 空き枠のゾーン

- ◯ゾーン（推奨）: 13:30〜18:00
- △ゾーン（許容、優先度低い）: 10:00〜11:30、13:00〜13:30、18:00〜19:00
- ✕ゾーン（候補から除外）: 上記以外、および祝日・年末年始・お盆

## 候補の並べ方

- 5日以上のユニーク日付を目標とし、確保できなければ3日まで妥協する
- 同じ日に候補が偏らないよう、日付を分散して選ぶ

3分類がないと、AIは既存の予定をすべて同じ重みで扱い、「社内イベントがあるので候補が出せません」と言い出します。 分類を書き出しておけば、社内イベントと並行する枠も候補にでき、取引先との打ち合わせと重なる枠は候補から外す、という当たり前の判断を任せられます。

時間帯ポリシーの「水曜は入れない」は、規則だけでなく「打ち合わせを入れない曜日を1日確保し、集中作業や突発対応に充てる」という背景をセットで書きます。 背景が書いてあると、AI側でも例外の相談を返せるようになります。 たとえば4月、期初を迎えたお得意様の役員と1年間の方針を決めるような会議は、優先する価値がありそうです。 そうした打診が来たとき、背景を知っているAIは「水曜ですが例外にしますか」と相談できます。 ◯△✕のゾーン化も、時間帯を推奨・許容・除外という意味で整理できるので、後で見直すときに「どの帯を何に使う想定だったか」を復元しやすくなります。

祝日の考慮や、候補日を同じ日に固めないための日付分散も、ここに書いておきたい項目です。 「候補は少なくとも3日分を並べる」だけでは、極端な場合には同じ日から3枠出てしまいかねません。 日付を散らして選ぶルールを言語化しておくと、AIが同日集中を避けてくれます。

もうひとつ、手順書側で書いておくべきことがあります。 それは「毎回聞くこと」と「聞かなくてよいこと」の区別です。 日程調整の場合、所要時間と希望期間はデフォルト値を持たないので必ず聞きます。 60分固定だと思って進めたら90分の会だった、というのは事故です。 一方で、時間帯や候補数のように既存の判断基準に沿えばよいものは、聞かずに進めます。 この線引きを手順書に書いておくと、AIが毎回全項目を確認しに来る「新入社員あるある」を避けられます。

②答えが1つに決まる処理はプログラムに、AIは判断だけ

スキルを設計するときに一番間違えやすいのが「なんでもAIにやらせようとすること」です。 日程調整のスキルでは、単発・月次の両方の業務手順を通じて、以下の処理をプログラム（Pythonスクリプト）に固定しています。 AI側での自由裁量を認めていません。

  • 自分のカレンダーの空き枠を30分単位で探す。
  • 各候補が◯△✕のどのゾーンに入るかを判定する。
  • 予定同士の重なり（ダブルブッキング）を検出し、「他者の参加者がいる予定同士」「自作の作業ブロックと重なる」「その他」の種別で分類する。
  • 候補を「同じ日に集中しないよう」日付分散して選ぶ。
  • 「リスケ必要5件・リスケ不要4件」のような冒頭サマリーの件数を算出する。

これらはすべて、入力が同じなら出力も同じに決まる処理です。 AIに毎回数え直させると、たまに件数を間違えたり、同じ入力で日によって違う結果を出したりします。 プログラムに書けば、その心配がなくなります。

逆に、答えが1つに決まらない仕事は、プログラムには書けません。 たとえば「似たような予定が同じものを指していると判断する」「取引先に送る日程調整の依頼文を書き上げる」といった仕事です。 ここはAIに任せます。

役割分担の例として、取引先に送る依頼文の冒頭を、候補の日数に応じて切り替える仕様を紹介します。 仕様書には条件と文面の対応表を書き、スクリプトが候補日のユニーク日数を数え、AIは選ばれた文面を組み立てるだけの構造にしています。

# 冒頭の候補数表現（依頼文の冒頭1文）

候補日のユニーク日数で分岐する。件数はスクリプトが決定論で数え、AIは選ばれた文面をそのまま組み立てる。

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

「候補が少なくて申し訳なさそうに書いてください」といった曖昧な指示をAIに丸投げすると、日によってトーンがぶれます。 判断の分岐点だけをスクリプトと表で固定しておけば、AIは自然な日本語を書く役割に集中できます。

同趣旨で、予定衝突を種別に振り分ける処理も、入力が同じなら同じ結果になる形でスクリプト側が行い、AI側は判定結果に沿ってレポートを整形するだけにしています。

契約書の締結業務を入力・加工・出力の3列で整理し、「ヒトがやるべきこと」をオレンジ、「AIが一部担えること」を青、「DXで実現できること」を緑で色分けした図

③出力先ごとに書き分ける

もう1つの業務手順である月次のカレンダー衝突チェックでは、判定結果をAIエージェントを動かしている手元のターミナル画面に出します。 さらに、リモートアシスタント（秘書会社）も参加している共有チャットにも投稿します。 同じ判定結果でも、それを「どこに書き出すか」で表記を変えます。 手元のターミナル画面、社外の関係者も見る共有チャット、取引先に送る依頼文で、書ける情報の範囲が違うからです。

例として、自分だけで入れている予定の扱いを紹介します。 カレンダーには「日課のランニング」や「月末の経費申請」のように、自分の作業時間を確保するための予定があります。 これを「自作ブロック」と呼んでいます。 候補時間帯に自作ブロックが重なっても、自分で動かせるため候補からは外さず、注記を添えて出します。 この注記を、出力先ごとに3段階で書き分けています。

# 自作ブロック注記（出力先で表記が分離）

候補時間帯に自作ブロックが重なる場合、下表に沿って注記を添える。

| 出力先 | 表記 | 理由 |
| ------ | ---- | ---- |
| 手元のターミナル画面（本人だけが見る） | ※自作ブロックあり：[ブロックのタイトル] | 判断者本人が具体名で並行可否を判断できる |
| 共有チャット（社外のリモートアシスタントも閲覧） | ※担当者の別予定ありだが調整可能 | 閲覧範囲が広い場所には、担当者個人の予定の詳細まで出さない |
| 取引先向けの依頼文 | （注記自体を出さない） | 社外向けに内部判断材料を見せない方針 |

出力先の性質は依頼受付時に確定させ、以降は本表に沿って書式を選ぶ（AI側での判断は入れない）。

「本人向けなら詳細OK」「社外も見る共有スペースなら抽象化」「取引先向けなら省略」というルールを一度決めれば、以降は同じ判断で書き出せます。 AIに毎回考えさせずに手順書に固定しておくのが要点です。

内部処理用のラベルと、読み手に見せる表記を分けて持つ工夫もあります。 プログラムの中では英語のラベル名で予定の種別を管理し、レポートに書き出すときに読み手向けの日本語へ変換します。 この変換テーブルをスキル側に置いておけば、実装の中身を変えても表示は安定します。

なお、Docs向けのMarkdown、共有チャット向けの独自記法など、出力先ごとに書式が違う場合もあります。 その場合は、使い分け自体を「Slack用スキル」のような「出力先ごとのスキル」に書いておき、日程調整スキルからはそれを参照させる形にできます。 次節の「参照させる」構造につながる話です。

④手順書・仕様書・参考資料を分けて参照させる

スキルは1つのMarkdownファイルに全部を書き込むと、あっという間に読めなくなります。 日程調整のスキルは、最初に見せたファイル一式を、以下のように役割で分けています。

./skills/mtg-scheduling/
├── SKILL.md                       # 索引: このスキルは何をするか・いつ使うか
├── runbook/                       # 業務手順書（人間向けの業務手順）
│   ├── scheduling.md              #   単発の日程調整
│   └── monthly-conflict-check.md  #   月次の衝突チェック
├── specs/                         # 技術仕様の正本（ロジックの定義）
│   └── analysis.md                #   空き枠計算・衝突判定・依頼文ドラフト仕様
├── qa/                            # 試運転の手順と実施レポート（改修時には毎回実行してデグレを防ぐ）
│   └── trial-runbook.md
├── references/                    # 参考資料（社内ルールの抜粋）
│   └── scheduling-guideline.md
├── scripts/                       # 答えが1つに決まる処理のプログラム
│   └── analyze.py
└── tests/                         # scripts/ に対する回帰テスト
    └── test_analyze.py

各ディレクトリの役割は以下のとおりです。

  • runbook/: 業務手順書を置く場所です。サンプルで見た単発のミーティング設定（scheduling.md）と、月次のカレンダー衝突チェック（monthly-conflict-check.md）の2本が並びます。
  • specs/・scripts/: 計算ロジックの仕様書と、その実装です。手順書側に「◯△✕のゾーン判定の詳細はspecs/analysis.mdを参照。scripts/analyze.pyの実装はこの仕様書に合わせる」といった1文を置いておくと、仕様と実装がずれてきたときにどちらを直せばよいかが分かります。
  • qa/: 改修後に走らせる試運転の手順と、その実施レポートを置きます。試運転そのものは後述の⑦で扱います。
  • references/: 判断の背景になる社内ルールを置きます。業務時間の考え方や依頼文のトーンなど、社内で使われている参考資料の抜粋です。手順書の中で「文面のトーンはreferencesの該当ファイルを参考にする」と参照させておくと、AIがその場のノリで独自トーンを作ってしまうのを防げます。

責務を分けておくと、どこを触るかが明確になります。 業務要件が変わったときは手順書だけを、計算ロジックが変わったときは仕様書とスクリプトだけを書き換えれば済みます。

これは、業務手順書を部品に分けて組み合わせる、いわばモジュール化の話です。 部品への分割は、1つのスキルの中だけでなくスキルをまたいでも行います。 共有チャットへの投稿手順は別スキル（mcp-slack）に切り出し、日程調整スキルからは「投稿するときはこのスキルに従う」とリンクするだけにしています。 同じ業務手順を複数のスキルに書き写すと、片方だけ更新されて食い違うのは時間の問題です。

⑤人間の承認ゲートを置く

スキルの中でも、取引先へのメール送信・依頼文の送付など、社外に出るものについては、AIが自動で送らない設計にしています。 AIが文面を私に見せ、私が承認してから送信します。 日程調整のスキルでは、送信前の承認を以下のStepで組んでいます。 サンプルのStep 4を詳しく示したものです。

## Step 4: 送信前の承認

取引先向けの依頼文はAIが自動で送らない。以下の手順で承認を得てから送信する。

| 順序 | やること |
| ---- | -------- |
| 1. 送信対象をまとめて提示 | 送信先・所要時間・候補日時・依頼文ドラフト全文を、1回でまとめて会話に提示する。「送ってよいですか?」だけの問いかけは禁止、内容を全て見せる |
| 2. 判断が要る箇所は選択肢で聞く | 自由回答で聞かず、明示的な選択肢で提示する。例: (a) AIがこの文面のまま送る / (b) 候補日を差し替えて作り直す / (c) 今回はユーザーが送る |
| 3. 承認後に送信 | ユーザーが選択・承認した内容だけを送信する。承認された範囲を超えて追加の調整を勝手に行わない |

承認を何度も求めると、承認する側の負担が増えてかえって危険です。 面倒くさくなって流し見されるからです。 1回でまとめて全内容を提示するのが要点です。

判断を仰ぐときは、選択肢を明示的に並べます。 「どうしますか？」ではなく、上記の3択のように選んでもらう形です。 このとき、事実とAI側の解釈・提案は別々に見せます。 事実は「候補時間帯には既存の予定が入っている」「取引先の想定時間帯が業務時間の外にはみ出ている」等、解釈・提案は「別の候補に振り替える必要がある」といった判断です。 事実だけを並べて、解釈は選択肢として提示することで、「事実は同意だが、判断は別案でいきたい」と応答できる余地を残します。

AIエージェントのアウトプットを人間が手直しし、その結果を社内ルールや過去の文例としてコンテキストに追加して、次の作業に活かす流れを示した図

⑥テストで業務ルールを固定する

②でプログラムに切り出した処理には、テストを書けます。 日程調整スキルでは、判断基準の1つ1つに対して「この入力ならこの出力になるはず」をpytestで固定しています。 pytestは、Pythonで書いたプログラムを自動でテストするツールです。 テストファイルの冒頭には、観点の一覧をdocstringという説明文の形でプログラム内に埋め込みます。 何を確認しているテストなのかを、ファイルを開いた最初の画面で把握できるようにするためです。

# tests/test_analyze.py冒頭抜粋
"""analyze.pyの決定論ロジックに対する回帰テスト。

## テスト観点の一覧

| 観点 | 代表テスト | 意図 |
| ---- | ---------- | ---- |
| 対象予定の識別 | test_self_declined_excluded | 参加辞退した予定を計上しない |
| 予定の重複排除 | test_dedupe_same_ical_uid_start_end | 同じ予定を1件として扱う |
| ゾーン判定 | test_lunch_slot_excluded | ランチ枠を候補から外す |
| お盆判定 | test_obon_boundaries | 8/9開始と8/10開始で扱いが変わる |
| 除外パターン | test_optional_event_excluded_from_both | 自分は出なくても成立する社内イベントはBusy集合とtarget集合の両方から外す（重複してもよい予定として扱い、候補時間帯も潰さない） |
"""


def test_self_declined_excluded():
    # 自分がdeclinedで返した欠席予定をダブルブッキングとして計上していた不具合の再発防止
    event = make_event(self_response_status="declined")
    assert identify_targets([event]) == []

テストを書くときの起点は、過去の失敗事例です。 たとえば「参加辞退した予定をダブルブッキングとして計上する」という不具合が実際に見つかったとき、そのケースを再現するテストを追加します。

「自分は出なくても成立する社内イベント・仮押さえ枠は候補判定から除く」のような、一度決めた除外ルールも、テストで固定します。 改修でスクリプトを書き換えてこのルールを壊した瞬間に、テストが赤くなって気付けます。 合意事項が「気付いたら消えていた」を防ぐ仕組みです。

境界や例外を突く確認ケースも入れておきます。 実運用で1度でも遭遇したパターンは、テストとして残しておきます。

  • ランチ枠の境界：12:30開始と13:00開始でゾーン判定が変わる
  • 水曜の深夜から木曜にまたがる夜間メンテナンスの立ち会い予定
  • 祝日の前日夜
  • お盆判定の日付境界：8/9開始と8/10開始で扱いが変わる

⑦手順書だけ渡して試運転する

プログラムはテストで確かめられますが、手順書の完成度は「新入社員に渡してやらせてみること」で検証します。 日程調整スキルでは、これをAIで実現しています。 過去のやり取りを一切知らない別のAIに、手順書だけを渡して業務を最初から実行させ、意図した通りの成果物が出るかを確認する試運転です。

試運転を担当するAIには「前回どこで間違えたか」「レビュー指摘の内容」「直前の改修意図」といった事前の情報を一切渡しません。 渡すのは「スキル本体」「手順書」「仕様書」「作業対象への到達方法」だけです。 指示テンプレは以下のような形になります。

# 試運転担当エージェントへの指示テンプレ

あなたはmtg-schedulingスキルの月次衝突チェック業務の呼び出しを受けたエージェント（試運転担当）です。
以下を1から通読し、runbook/monthly-conflict-check.mdのStep 1〜4に従って実行してください。

## 必読ファイル

- ./skills/mtg-scheduling/SKILL.md
- ./skills/mtg-scheduling/runbook/monthly-conflict-check.md
- ./skills/mtg-scheduling/specs/analysis.md

## 期待されるアウトプット

runbook Step 4「報告」フォーマット通りのMarkdown本体（全文、要約なし）。

## 厳守ルール

- 本テンプレと必読ファイルに書かれていない独自判断はしない
- Fact-first: 確認できないことは「未確認」と明記する
- 判定（合否）は試運転担当の責務外。呼び出し元のAI側で行う

## 報告の構成

1. 数値サマリー
2. Step 4報告フォーマットのMarkdown本体
3. 適用したサブルールの自己申告（項目ごとに「適用した / 該当なし / 違反あり」）

事前情報を渡さない形にする理由は2つあります。 第1に、手順書に書き忘れがあれば、事前情報を持たない試運転側が必ずつまずいてくれるので、書き漏れが見つかります。 第2に、実運用でもこのスキルは「事前の文脈を持たない別のセッションから呼び出される」ので、その状況を再現しないと本当の完成度は測れません。

試運転が終わったら、結果を鵜呑みにせず、成果物と自己申告の両方を突き合わせて確認します。 試運転を担当したAI自身に「手順書のどのサブルールを適用しましたか」を項目ごとに自己申告させ、その申告と実際の成果物が一致しているかをこちら側で照合します。 「適用しました」と自己申告があっても、成果物側にその適用結果が現れていなければ、手順書の書き方に曖昧さがあるということです。

この試運転を、業務手順やロジックを変える改修のたびに、レビューへ出す前に必ず1度回す運用にしています。 手順書上は正しく書けたつもりでも、実行してみるとゾーン判定の境界がずれていたり、依頼文の末尾が想定と違う文面になっていたり、といったズレが出ることがあります。 試運転で発見したズレは、その場で手順書・仕様書・スクリプトのどこに起因するかを特定して直します。

⑧失敗から手順を育てる

スキルは、作って終わりではありません。 使いながら、失敗から手順を育てていきます。

日程調整スキルには、過去のミスを「だからこのステップがある」と手順書の中に組み込んだ箇所がいくつもあります。 以下は両方の業務手順が参照する共通の仕様書の抜粋で、判断基準と背景をセットで書いておく形の例です。

# 対象予定の識別（候補計上の母集団）

以下を全て満たす予定を対象予定とする。

- statusがcancelledではない
- event_typeがoutOfOffice / focusTime / workingLocationのいずれでもない
- all_dayがfalse（終日予定はリスケ対象としない）
- selfエントリのresponse_statusがdeclinedではない（＊）
    - 過去に、自分がdeclinedで返した欠席予定をダブルブッキングとして計上する取りこぼしが見つかったため、明示的に除外する
- selfエントリを除いた他者参加者が1人以上いる

（＊）：2026年6月のインシデントを受けて追加。削除・簡略化する時は、当時の記録（qa/ の試運転レポート）を確認する。

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

例外の追加は、なし崩しにせず明示的な合意だけをリストに足す運用にしています。 「社内のドキュメントに『この会議は担当者不在』と書いてある」「実態として何回か欠席している」といった状況証拠だけでは、除外パターンを増やしません。 私が「この予定は除外する」とはっきり決めたものだけを、除外リストに追記します。 この規律を破ると、除外パターンが際限なく増えて、意図しない予定が対象から漏れる事故につながります。

スキル自体の更新プロセスも、手順書内に書きます。 「本ファイルを更新したら、変更後の手順をAIレビューに通し、人間が確認してからコミットする」といった1文を残しておくと、更新の質が安定します。

スキルを育てるループは、⑤で紹介した承認ゲートとも接続します。 人間が承認・修正した内容を手順書に反映すれば、次回以降の判断精度が上がる。 この繰り返しが、スキルを実際の業務に合わせて育てていく仕組みです。

スキルの位置づけ

あらゆる業務の手順書がスキルになる

ここまで日程調整を例にしてきましたが、同じ考え方は社内のあらゆる業務にそのまま応用できます。 「経理データからの月次コスト集計」「会議録画からのロードマップ更新」「契約書のチェック」「採用スカウトの判定」など、バックオフィス業務も対象です。

人間または定期トリガーを起点に、AIエージェントがスキルを参照して対象業務を行う流れの図と、風音屋のバックオフィス部門で使っているスキルの例として「定例会議の録画からロードマップを更新する手順」と「経理データから毎月のコスト上位を精査する手順」を挙げたスライド

業務の一覧が、そのままスキルの一覧になります。 業務手順書＝スキルです。 担当者の頭の中で管理するか、Wordに書き出すか、AIが読める場所に書き出すかの違いでしかありません。 ここまで実例で見てきた考え方は、日程調整に固有のものではありません。 「暗黙知の言語化」「決まり切った処理はプログラム側で固定」「テストで業務ルールを守る」「承認ゲートで社外への出力を止める」は、いずれも業務手順書に広く共通する設計原則です。

AIの得意・不得意と役割分担

スキルを組む前提として、AIの得意・不得意を知っておく必要があります。 手順書側でどこをAIに任せ、どこをプログラム・人間に任せるかを設計するときの土台になります。

  • コンテキストとは、指示文・添付資料・スキル本文など、AIが判断のために読み込む前提情報のことです。コンテキストは、設計しないと判断を誤ります。似た資料を大量に渡すのではなく、どの情報を、どこから、どう取得し、どう解釈するかを言語化する必要があります。だからこそ、スキルを整備して、業務手順と参考資料を分けて渡す形にしています。
  • AIは作業の代理人であって、データベースではありません。AIエージェント自身が過去のセッションの情報をずっと持ってくれるわけではありません。契約書を文字起こしした結果を後で使いたいなら、その結果をデータベースやファイルに保存する手順まで、スキルに書いておく必要があります。
  • 同じ指示で同じ結果になるとは限りません。数値の集計や条件分岐のような「答えが1つに決まる処理」は、プログラムで管理して、AIにはプログラムを呼ぶ側の役割を持たせます。②で紹介したスクリプト分離が、この考え方の実践です。
  • AIが一度に読み込める分量には上限があり、それを超えるデータは丸ごと渡せません。契約書100件を1セッションで全部処理しようとせず、1件ずつに分けて処理する、または集計だけをプログラムに委ねる形にします。

これらの制約があるからこそ、AIに業務を渡すには「スキル」と「コンテキスト」の整備が必須です。 しかも、その整備自体をAIに依頼できます。 「この手順書を読んで、抜け漏れがあれば直して」とAIに頼めば、AIが手順書を改修してくれます。 これが本記事の冒頭で触れた「スキル自体をAIに改修させられる」の意味です。

何から始めるか

ここまで読んで「じゃあ何から始めればいいか」と思われた方に向けて、始め方の型を1つ紹介します。

今週のTODO計画から「時間がかかりそうで、今後も繰り返しそうな作業」を1つ選んで、業務手順書を書くつもりでスキル化するのがおすすめです。 すでにやってきた作業に限らず、これから発生する作業も対象になります。 想定の作業時間と、その作業が今後どのくらいの頻度で繰り返されそうかを見積もり、時間 × 頻度が大きいものから順にスキル化するのが効率的です。

そのうえで、週の振り返りで「AIに任せたが、手直しや追加作業が多かった作業」を洗い出し、その作業のスキルを直すと良いでしょう。 手直しが多いということは、手順書のどこかに書き漏れがあるか、判断基準が曖昧か、AIに判断を任せすぎているかのいずれかです。 手直しの内容を見れば、どこを直すべきかが分かります。

この2つを繰り返していけば、実際に必要な作業から順にAIに渡っていきます。 大事なのは、小さく始めることだと思います。 全部の業務を一気にスキル化せず、まず今週の1つに絞りましょう。 最初から8つのコツを全部そろえる必要はありません。 手順書1枚から始めて、うまくいかなかった箇所から順に、判断基準の書き出しやテストを足していけば十分です。

「毎週の作業プランニングと振り返りを通してスキルを育てる」という考え方は、以下の投稿でも紹介しています。

風音屋では、こうしたスキル整備を通じて、データ領域の業務からバックオフィス業務まで、AIと一緒に運用する体制を作っています。 スキル（Agent Skills）の設計・導入・運用のご相談は、以下よりお気軽にどうぞ。

https://kazaneya.com/service

Tags: , ,

Posted:

Author: yuzutas0

ゆずたそ（@yuzutas0）。 風音屋の代表。 著書に『個人開発をはじめよう！』『データマネジメントが30分でわかる本』『実践的データ基盤への処方箋』など。 PyCon JP, Developers Summit, Google Cloud Day, 日本統計学会といった場で積極的に情報発信している。

You May Also Enjoy