はじめに
AIエージェントに定型業務を任せたいとき、いま我々がやっていることは「手順書を 書く」ことです。SKILL.md を開き、思い出しながら箇条書きにし、出力フォーマットを決め、試して直す。フォーマット（Agent Skills）は普及したのに、中身を用意する手間は誰も解決していません。
Microsoft が 2026年7月29日に公開した OSS microsoft/skill-recorder は、ここを反転させます。手順を書く代わりに、実際にその作業を1回やって見せる。画面・ウィンドウ切り替え・訪れた URL・（任意で）音声ナレーションを記録し、GitHub Copilot CLI がそれを「意図（intent）＋順序付き手順（steps）」として再構成し、エージェントが再利用できる Skill / Automation に変換します。
README の1行目がそのまま設計思想です。
Record yourself doing a task once, then turn it into a skill your AI agent can repeat.
（出典: microsoft/skill-recorder README）
この記事では、README レベルの使い方だけでなく、生成物の中身・ローカル／クラウドの送信境界・日本語環境での落とし穴・企業導入時のチェックポイントまで踏み込んで整理します。
注意: 本記事は 2026年8月上旬時点の公開情報に基づきます。本ツールは v0.x のプレビュー品質であり、仕様は変わり得ます。
30秒でわかる Skill Recorder
| 観点 | 内容 |
|---|---|
| 何ができるか | 作業を1回録画 → Copilot が「意図＋手順」に再構成 → SKILL.md（オンデマンド実行）または Automation（スケジュール／トリガー実行）を生成 |
| 何を解決するか | Skill を文章で書き起こす手間。1件のフォーム送信を録れば「全件送信」へ一般化させる設計思想 |
| 出力先 | Microsoft Scout / Microsoft 365 Copilot Cowork（Copilot Studio は「Coming soon」枠） |
| 実体 | Electron 製デスクトップアプリ（TypeScript）、MIT ライセンス、GitHub Copilot CLI 同梱 |
| 前提 | GitHub Copilot にアクセスできる GitHub アカウント |
| 対応 OS | macOS（主対象）／Windows 11（x64・ARM64）／Ubuntu |
重要な前提: Skill Recorder 自体は何も実行しません。手順書を「作る」側のツールです。実際に手順を走らせるのは Scout や Cowork といったエージェント側です。ここを取り違えると「入れたのに何も自動化されない」となります。
1. 位置づけ — Agent Skills の「中身を用意する工程」を置き換える
ここ数か月で、エージェントに能力を足す形式は「フォルダに SKILL.md を置く」にほぼ収束しました。Cowork でも、OneDrive の /Documents/Cowork/skills/<name>/SKILL.md に YAML frontmatter（name / description）＋手順本文を置くことでカスタムスキルが認識されます（Cowork は最大50個のカスタムスキルに対応）。
収束したのは 形式 であって、中身 ではありません。Skill Recorder が狙うのはまさにこの隙間です。
[従来] 人間が思い出す → 文章化する → SKILL.md → エージェントが実行
[SR] 人間が1回やって見せる → Copilot が再構成 → SKILL.md → エージェントが実行
↑ ここを自動化した
単なるマクロ記録ツールではない
最大の設計上のポイントは、記録した UI 操作をそのまま再生しないと明言していることです。README は生成物について「エージェントのネイティブツール（gh CLI や web_fetch など）を UI クリックのリプレイより優先する」と書いています。
つまり「ブラウザでこのボタンを押す」ではなく「gh CLI で PR 一覧を取る」に 翻訳 することを狙っています。この方針はソース側の指示文にも一致しており、electron/skillbuilder/instructions.ts には「ネイティブツールを優先せよ」という趣旨の見出しと、デバイス上に一級の CLI があるならブラウザより優先する旨の記述があります。
従来型 RPA との違いを整理すると次の通りです。
| 観点 | 従来型 RPA（Power Automate Desktop 等） | Skill Recorder |
|---|---|---|
| 記録する対象 | 座標・UI 要素の位置 | 操作の意図と文脈（画面・URL・クリップボード・音声） |
| 再現方法 | 同じ操作をリプレイ | エージェントがネイティブツールで再構成して実行 |
| 画面変更への耐性 | 弱い（レイアウト変更で壊れやすい） | 相対的に高い（意図レベルで持つため） |
| 一般化 | 基本しない（1件は1件） |
values と generalization で「1件→全件」を狙う |
| 成果物 | ベンダー固有のフロー定義 | Markdown（SKILL.md）／Automation バンドル |
| 実行主体 | RPA ランタイム | AI エージェント（Scout / Cowork） |
比較対象としてふさわしいのは既存 RPA というより、「担当者が手作業でエージェント向け手順書を書く工数」 の代替、という位置づけです。
2. 使い方 — Record → Control → Analyze → Create の4ステップ
README の "How it works" と実装構成は一致しています。
| ステップ | 操作 | 内容 |
|---|---|---|
| 🔴 Record | 録画ボタン、または ⌘⇧R（macOS）/ Ctrl+Shift+R（Windows） |
画面と操作をローカルでバックグラウンド記録。開始前に毎回プライバシー警告が出る |
| 🎛️ Control | 常に最前面の小バー | キャプチャ／マイク状態の表示、ミュート・解除、マイク切替。失敗テイクは確認ダイアログ付きで破棄 |
| 🧠 Analyze | Analyze ボタン | GitHub Copilot が「1つの全体的な意図＋順序付き手順」を再構成。画面上で手順のクリック編集・並べ替え・追加・削除が可能 |
| ✨ Create | Create ボタン | 承認済みの解析から Skill および／または Automation を生成 |
承認ゲートが2段ある
見落としやすい重要な設計が、承認が2段構えであることです。
Analyze
└─ ① 意図と手順のレビュー（編集・並べ替え・追加・削除）
↓ 承認
propose_plan ← ② どう一般化するか／どんな固定値が要るか／どの native tool を使うか を先に提示
↓ 自然言語で修正・確定
submit_skill → SKILL.md を描画 → Scout / Cowork へエクスポート
いきなり成果物を出さず、方針を先に見せる構成です。レビュー可能性を優先した作りといえます。
手順は「計算」と「実行」に型で分かれている
プラン内の手順はただの文字列ではなく型を持ちます。PlanStepKind は次の2値です。
| 種別 | 意味 | 例 |
|---|---|---|
calculation |
読む・導出する・判断する・整形する。外部に副作用を与えない | 一覧を取得する、条件で絞る、文面を整える |
action |
世界を変える操作 | submit / send / create / delete |
ソースのコメントでは、これを分ける理由を「副作用についてプランを正直に保つため。action こそがリスク面である」という趣旨で説明しています。自動生成された手順を人間がレビューするとき、全ステップを等しく読むのは現実的ではありません。「どれが取り返しのつかない操作か」が型で分かれているのは、レビュー負荷の観点で理にかなっています。
精度を上げるコツ：喋りながら録る
ナレーションは任意ですが、録画映像から推測されるより本人の説明のほうが正確です。音声は Whisper がサポートする99言語で端末内文字起こしされます（初回のみ約252MB のモデルダウンロード）。日本語で解説を吹き込めるのは日本語話者にとって素直な利点です。
実装にも、この思想が現れています。electron/narration/analyze-gate.ts には「ナレーションはユーザー自身の言葉による意図の説明なので、音声があるのに未文字起こしのまま黙って解析を走らせてはならない」という趣旨のコメントがあります。音声があって未文字起こしのときだけ「文字起こし→解析」の順に進む門になっています。
また transcribe.ts には、Whisper が無音区間で定型句を幻覚する既知問題への対処（無音判定と定型句除去）も入っています。
3. 生成物 — SKILL.md と Automation の中身
SKILL.md の形
renderSkillMarkdown() は Copilot に依存しない純粋関数なので、手元で直接呼んで出力を確認できます（コミュニティの検証記事による実測）。生成される形はおおむね次の通りです。
---
name: submit-expense-records
description: "Use when: submitting expense records, 経費精算: colons, commas"
allowed-tools:
- Bash(git *)
- workiq_search_chats
---
Open https://contoso.example/expenses and submit each row.
ここから読み取れることが3点あります。
-
descriptionは必ずダブルクォートで囲まれる — コロンやカンマが入っても YAML が壊れないよう文字列化を通している。日本語もそのまま通る -
{{id}}トークンは書き出し時に実値へ置換される — プラン段階では{{portal}}のような名前付き固定値として扱われ、レンダリング時に URL などへ展開される -
allowed-toolsは配列で frontmatter に入る — ここにworkiq_search_chatsのような Scout 固有のツール名 が入るため、形式は共通でも中身は行き先に依存する
一般化のしくみ — values と generalization
SkillPlan のスキーマは、手順の羅列だけでなく次を別フィールドとして持ちます。
-
generalization— 録画された具体例をどう一般化したか、の説明 -
values— URL・パス・定数などの固定リテラル
つまり録画から作られるのは「操作の記録」ではなく、「変わらない部分」と「変わる部分」に分解された手順です。ここが単なるマクロ記録ツールとの分岐点であり、レビュー時に values を見れば「このスキルが決め打ちしている値」が一覧で分かる構造にもなっています。
Automation 側
Automation は Scout の import JSON にレンダリングされ、インポート可能なバンドルフォルダとして書き出されます（Scout がインポートする形式で、Skill のように自動ロードされるわけではない、とソースのコメントに明記）。スケジュール表現も Scout の3種（single / interval / multi）を写したもので、intervalMinutes には「1440 を割り切ること」というバリデーションまで入っています。
出力先（エクスポートターゲット）
README は生成物を一貫して "an agent" としか書かず、どのエージェント向けかは本文に出てきません。ソースの common/skill.ts に対象が列挙されており、v0.3.1 時点の実測は次の通りでした。
| ターゲット | 有効 | 説明 |
|---|---|---|
skill/scout |
✅ | Scout skill（native WorkIQ、ブラウザ、ファイル、ビルトインスキル） |
automation/scout |
✅ | Scout automation |
skill/cowork |
✅ | Cowork skill（Teams、Outlook、Calendar、SharePoint、ファイル、ビルトインスキル） |
skill/copilot-studio |
❌ | Coming soon |
Claude Code も Cursor も、汎用の「ローカルの .claude/skills/ に置く」も選択肢にありません。 frontmatter の形は Agent Skills として広く見る形と同型ですが、それは「そのまま他所へ持っていける」ことを意味しません。allowed-tools に Scout 固有ツール名が入る以上、手でファイルを移しても機能する保証はない点に注意してください。
保存先
| 対象 | 保存先 |
|---|---|
| 録画セッション（イベント・フレーム・映像・音声） | userData/sessions/ |
| Whisper モデル | userData/models/ |
| 生成された Skill | ~/.copilot/skills/ |
| 生成された Automation | ~/.copilot/automations/ |
macOS の userData は ~/Library/Application Support/ 配下です。
4. インストール
Skill Recorder はバイナリ配布ではなくソースリリース方式です。1コマンドで、ピン留めされた Node.js ランタイムを取得し、指定コミットを手元でビルドし、Skill Recorder (Source) アプリを追加します。グローバルには何もインストールされません。
macOS / Ubuntu
commit="<40-character-release-commit>"
curl -fsSL "https://raw.githubusercontent.com/microsoft/skill-recorder/$commit/install.sh" \
| SKILL_RECORDER_COMMIT="$commit" bash
ターミナルを閉じても動かし続けたい場合は SKILL_RECORDER_DETACHED=1 を追加します。
Windows 11（PowerShell）
$commit="<40-character-release-commit>"
$env:SKILL_RECORDER_COMMIT=$commit
irm "https://raw.githubusercontent.com/microsoft/skill-recorder/$commit/install.ps1" | iex
なぜコミット SHA が2回出てくるのか
これは意図的で、ダウンロードされるスクリプト自体と、そのスクリプトがビルドするソースの両方をピン留めするためです。main やブランチ名、未検証のタグに置き換えてはいけません。インストーラは可変参照を拒否し、フル 40 文字の SHA を要求します。
インストーラは他にも、Node.js 24 を nodejs.org から取得して SHASUMS256.txt で検証（Windows では Authenticode 署名も検証）、Electron を公式リリースエンドポイントから取得してチェックサム照合、npm run compliance:licenses によるライセンス確認、といった手順を踏みます。
開発ビルド
npm ci
npm run compliance:licenses
npm run dev # Vite + Electron をホットリロードで起動
初回起動時、macOS は画面収録の許可を求めます。初回 Analyze 時には、未サインインであれば「Sign in to Copilot」が提示されます。
同梱の評価ハーネス（evals）
地味に重要なのが、Copilot の describer / builder に対する fixture ベースの eval スイートが同梱されている点です。
npm run eval # 合成録画に対して describer をスコアリング
npm run eval:builder # skill / automation の一般化をスコアリング
「録画→意図抽出」「意図→スキル一般化」という非決定的な工程を評価対象として持っていること自体が、このプロジェクトの真面目さを示しています。自社のプロンプト改変を試すときも、ここを起点にするのが筋です。
ちなみにテストは vitest ではなく Node 標準の
node --testを使っており、正しい入口はnpm testです（npx vitest runは "No test suite found" で失敗します）。
5. 何が記録され、どこへ送られるのか
画面録画ツールを業務で使う以上、ここは使う前に必ず確認すべき箇所です。
送信境界
README の記述は明快です。録画・保存・フレーム抽出・ナレーションの文字起こしは、すべて端末内で行われ、録画中は何も外部に出ません。 送信が起きるのは Analyze を押したとき で、そこで初めてイベント時系列（ウィンドウ／ドキュメントのタイトル、URL、クリップボードのプレビュー）、抽出された画面画像、ナレーションのテキストが GitHub のクラウドへ渡ります。
[ローカル完結] 録画 → 保存 → フレーム抽出 → Whisper 文字起こし
│
── Analyze を押す ──▶ [GitHub クラウド]
イベント時系列
抽出画面画像（base64）
ナレーションテキスト
記録される信号
記録項目を選ぶ UI はありません。common/config.ts の冒頭コメントには「レコーダーは毎回すべての利用可能な信号を記録する。ユーザー向けのキャプチャレベルは存在しない」という趣旨が書かれています。重なり合う OS 権限をなぞるだけの段階的ピッカーをやめ、透明性は「何が記録されるか」の説明で担保する、という設計判断です。
| 信号 | 内容 | 必要な権限 |
|---|---|---|
| App switches | 前面アプリの切り替え（アプリ名・bundle・pid） | 不要 |
| Clipboard copies | コピー内容の形式・長さ・ハッシュ・短いプレビュー | 不要 |
| Window titles | ウィンドウ／ドキュメントのタイトル | OS 権限が一度必要 |
| Browser URLs | アクティブなブラウザタブの URL（macOS） | OS 権限が一度必要 |
| Screen video + keyframes | 低フレームレートの画面録画と抽出キーフレーム | 画面収録の権限 |
つまり設定は「録画を開始するか、しないか」の二択です。「このウィンドウだけ除外」「この区間だけクリップボードを録らない」は存在しません。
秘密情報についての警告
README は2か所で警告しています。パスワード・トークン・API キー・資格情報などを、録画・入力・貼り付け・表示・コピー・読み上げしないこと。かなり具体的に列挙されています。
この警告が文言だけでないことはテストコードからも読み取れます。electron/recording-privacy.test.ts には次の2件があります。
- 詳細な開示内容をレビューするまで、録画開始のたびに警告を出す
- レビュー済みの記録はアプリのプロセスをまたいで残らない（次回起動時はまた警告から始まる）
「一度チェックしたら二度と出ない」タイプの同意 UI を意図的に避けている点は、扱うデータの性質を踏まえて妥当な設計です。
6. 企業導入で押さえるべきセキュリティ論点
ここからは、社内の機密データが写り込んだ録画をどう扱うか、という実務の話です。コミュニティによる v0.3.1 のソース実測をベースに整理します。
① マスキングは実装されていない
秘匿情報を検出・除去する仕組みはありません。redact / mask / sanitize / secret / credential といった語をランタイム全体で検索しても、該当する処理は見つからないと報告されています。
唯一それらしいのがクリップボード収集の長さ上限で、electron/collectors/clipboard.ts は 700ms ごとにポーリングし、形式・長さ・ハッシュ先頭16桁・120文字までのプレビューを記録します。ただし作者自身のコメントに「プライバシー対応のマイルストーンでここを厳しくする」とあり、現状は緩いと認識されています。
そして実務上、120文字という上限はフィルタとして機能しません。API キー、PAT、DB 接続文字列、社内 URL＋クエリ、顧客名簿1行——いずれも 120 文字に届かず、1文字も切り詰められないという検証結果が報告されています。この上限は長文を切り詰めるためのものであって、秘匿情報フィルタとして設計されたものではありません。
なお、公平のために設計上の配慮も2点。セッション開始時点でクリップボードに入っていた内容はベースラインとして使うだけで送出されない（録画中にコピーしたものだけを拾う）。録画開始警告はプロセスごとにリセットされ、永続化されない。
② 画面フレームは実データとして Copilot へ渡る
describer はセッションを丸ごと投げつけるのではなく、Copilot セッションにツールを渡してモデルに引かせる作りです。electron/describer/tools.ts が公開するのは get_timeline / get_events / list_frames / get_frames / get_narration / submit_analysis の6つ。
注目すべきは get_frames で、抽出済みの画面フレームが base64 の実データとしてモデルに渡ります。指示文は「イベントが沈黙している、または曖昧な箇所だけフレームを見ろ」と書いていますが、これは方針であって制限ではありません。ツール自体はセッション全区間のフレームにアクセスできます。
つまり、録画中に映ってはいけないものが映っていた場合、それが Analyze で渡らない保証はありません。
③ 通信経路は3つ
アプリ本体のソースツリーには fetch / axios / WebSocket 等の送信 API 呼び出しが0件、テレメトリ SDK も含まれていない、と報告されています。しかしこれは「通信しない」ではなく「通信を外部プロセスに委譲している」ということです。electron/copilot-cli-path.ts は同梱の Copilot CLI バイナリを子プロセスとして起動し、stdio 経由で会話します。GitHub への実際の送信はこのコンパイル済みバイナリの内側で起きます。
| 経路 | 何が出るか | いつ |
|---|---|---|
| 同梱 Copilot CLI（stdio 起動） | イベント時系列・画面フレーム・ナレーション | Analyze を押したとき |
@huggingface/transformers |
Whisper モデルの取得のみ（録画データは出ない） | 初回のナレーション文字起こし |
install.sh ＋ npm |
Node 24・依存パッケージの取得のみ | インストール時 |
企業で送信先許可リストを運用している場合、huggingface.co が登録対象になります。文字起こし自体は端末内で走りますが、モデルの初回取得は外向き通信です。
④ デバッグ zip が最大の落とし穴
アプリには「セッションの詳細をダウンロード」する機能があり、その実装 electron/debug-bundle.ts の writeDebugBundle() は、セッションディレクトリ全体（イベント・フレーム・画面映像・音声・解析結果）をそのまま zip に含めます。ソースのコメントにも「プライベートなキャプチャデータを含むため、呼び出し側は事前に警告しなければならない」と書かれています。
不具合報告のつもりで GitHub Issue に添付すると、録画を丸ごと公開することになります。ここは社内ルールで明示的に禁止すべきポイントです。
⑤ ファイル権限は OS 任せ
アプリ側は mkdir に mode を指定しておらず、作られる権限は umask 任せです（既定環境でディレクトリ 755・ファイル 644）。ただし macOS では親の ~/Library と ~/Library/Application Support が 700 で閉じているため、単独ユーザー環境では実際には保護されています。
守っているのはアプリではなく OS のディレクトリ配置である、というのが要点です。緩い許可ビットが効いてくるのは、データがこの保護チェーンの外に出た瞬間——バックアップ、クラウド同期フォルダ、共有ホームディレクトリ、そしてデバッグ zip です。
企業導入チェックリスト
□ 録画前
□ 認証情報・顧客情報が映る画面を閉じたか
□ パスワードマネージャからの貼り付けを録画中に行わない運用になっているか
□ 秘匿情報を含むタブ・ウィンドウのタイトルは大丈夫か（タイトルも記録される）
□ 検証用のダミーデータで録れないか検討したか
□ Analyze 前
□ この録画をクラウド（GitHub）へ送ってよいか、データ分類上の判断は済んでいるか
□ 社内のAI利用ポリシー／サードパーティ送信ポリシーに適合するか
□ 生成後
□ SKILL.md の本文に社内URL・ID・実データが焼き付いていないか目視
□ values に決め打ちされた値を確認したか
□ allowed-tools が想定どおりか（過剰な権限を要求していないか）
□ action 種別のステップを重点レビューしたか
□ 運用ルール
□ デバッグバンドル（zip）の外部共有を禁止しているか
□ 録画データの保管期間・削除ルールを決めたか
□ huggingface.co / GitHub への通信が許可リストに整合するか
7. 日本語環境の落とし穴 — スキル名が消える
日本語で作業し、日本語で解説を吹き込む使い方を考えると、無視できない挙動があります。
スキル名を生成する slugifySkillName() は、[^a-z0-9]+ に当たる文字をすべてハイフンに潰し、前後のハイフンを削り、60文字で切ります。日本語は英数字ではないため、丸ごと消えます。
コミュニティが同じ関数を実行した結果が次の通りです。
"経費精算を提出する" -> "recorded-skill"
"日報を作成" -> "recorded-skill"
"Slackに投稿する" -> "slack"
"請求書PDFを保存" -> "pdf"
"会議メモを整理" -> "recorded-skill"
distinct inputs: 5 distinct slugs: 3
5つの異なる業務名が3つに潰れ、うち3件が同一の recorded-skill になりました。名前の衝突です。さらに「請求書PDFを保存」が pdf になるように、たまたま混ざった ASCII 断片だけが名前になるケースも起きます。
ただしこれを「バグ」と決めつけるのは正しくありません。ビルダー側の指示（scout-catalog.ts / cowork-catalog.ts）には name を kebab-case（^[a-z0-9-]+$）にせよという要求があり、ツール定義にも submit-expense-records という例が示されています。モデルには英語 kebab-case で名前を出すよう指示されているため、通常経路では日本語名にならない想定で、slugifySkillName はモデルが指示に従わなかった場合のガードレールです。
とはいえ実運用では気に留める価値があります。プランを日本語で詰める過程で名前が日本語に寄れば、静かに recorded-skill に落ちます。
実務対策: 生成後は スキル名だけ必ず目視する。
{{...}}の値展開とallowed-toolsも併せて確認するクセをつけると事故が減ります。
なお混在時は ASCII 部分が素直に残ります（「Slack へ investor update を投稿」→ slack-investor-update、「PR 一覧を取得 (GitHub)」→ pr-github）。
8. 実践 — 最初の1本をうまく録るために
私の経験上、Agent Skills は「小さく作って育てる」のが基本です。Skill Recorder でも同じで、最初の録画で完成品を狙わないのがコツです。
録画対象の選び方
良い題材の条件は3つです。
- 繰り返している — 週次・日次の定型作業（週報、ステータス報告、申請、議事録の登録）
- 手順が短い — 3〜10ステップ程度。長い業務はまず分割する
- 副作用が明確 — 「最後に submit する」のような action がはっきりしている
逆に向かないのは、ターミナル中心の作業です。ターミナルで打ったコマンドは記録対象に含まれないため、映像とウィンドウ名からの推測に頼ることになります。CLI 作業は素直に手で SKILL.md を書いたほうが速いです。
録り方のレシピ
1. 対象業務を1本に絞る（「経費精算のタクシー分だけ」のように狭く）
2. 秘匿情報が映る画面を閉じる／ダミーデータに差し替える
3. ナレーションON。「いまから◯◯をします」「ここは毎回変わる値です」と
声で意図を補足しながら操作する ← ここが精度を最も左右する
4. 一気通貫で1回だけ実行して停止
5. Analyze → 手順をレビュー。余計なステップを削り、順序を直す
6. propose_plan で「一般化の方針」を確認。
固定値にすべきもの／可変にすべきものをここで自然言語で指示する
7. submit_skill → SKILL.md を目視（名前・values・allowed-tools・action）
8. Scout / Cowork へエクスポートし、小さい入力で試す
9. 動かない部分を SKILL.md に手で追記して育てる
ステップ3の「ここは毎回変わる値です」という一言が効きます。values と generalization を分けて持つ設計なので、可変／不変の宣言はナレーションで直接伝えられるからです。
生成後は手で育てる
Skill Recorder が出すのはあくまでドラフトです。実運用では、Agent Skills の一般的な育て方——テンプレートを references/ に置く、AI に任せるとブレる処理を scripts/ に切り出す、外部システム連携は MCP に寄せる——といった発展をこの上に重ねていくことになります。「録って、直して、育てる」が現実的な運用像です。
9. 現時点の評価
向いている場面
- GUI 中心の定型業務をエージェントに教えたい（Web フォーム、社内ポータル、SaaS 管理画面）
- Scout / Cowork をすでに使っている、または導入予定がある
-
SKILL.mdの書き方が分からず着手できていないチームの、最初の1本を出すため - 属人化した「あの人がやると品質が高い」作業を形式知化したい
待ったほうがいい場面
- 出力先が Claude Code / Cursor / 汎用ローカルスキルである（選択肢にない）
- Copilot Studio 向けが本命（v0.3.1 時点では無効枠）
- 秘匿情報の写り込みをツール側の機能で防ぎたい（マスキング機構は未実装）
- 作業がターミナル中心（コマンドは記録されない）
- 安定版を待ちたい（v0.x のプレビュー品質。バイナリ配布もなく、ソースビルド前提）
総評
「スキルを書く」を「スキルを録る」に反転させたアイデアは正しく、実装も——2段階の承認ゲート、calculation / action の型分離、values と generalization の分離、eval ハーネスの同梱——レビュー可能性を真面目に設計していることが読み取れます。
一方で、プライバシー面は「透明性で担保し、判断はユーザーに委ねる」という方針であり、マスキングやキャプチャ範囲の制御は利用者側の運用でカバーする必要があります。公開から日が浅く、v0.x でバイナリ配布もありません。現時点では「本番導入」ではなく「試して評価する」フェーズのツールと捉えるのが妥当でしょう。
とはいえ、Agent Skills の作成コストというボトルネックに正面から取り組んだ最初の Microsoft 公式 OSS であることは間違いなく、この方向性は追いかける価値があります。
FAQ
Q. 無料で使えますか？
A. 本体は MIT ライセンスの OSS で無料です。ただし解析に GitHub Copilot を使うため、Copilot 側のライセンスが必要です。
Q. 録画データは勝手にクラウドへ行きますか？
A. 録画中はローカル完結です。Analyze を押したときに限り、イベント時系列・抽出画像・ナレーションテキストが GitHub のクラウドへ送られます。
Q. Claude Code のスキルとして使えますか？
A. アプリのエクスポート先に選択肢はありません。frontmatter の形式は同型ですが、allowed-tools に Scout 固有ツール名が入るため、ファイルを手で移しても機能する保証はありません。
Q. Copilot Studio 向けは使えますか？
A. v0.3.1 時点ではターゲットとして定義されているものの無効化されており、「Coming soon」表記です。
Q. Windows でも使えますか？
A. Windows 11（x64・ARM64）に対応しています。ただし主対象は macOS で、ブラウザ URL の取得は macOS 向けと明記されています。
Q. 生成された SKILL.md は編集していいですか？
A. むしろ編集前提です。ドラフトとして受け取り、名前・固定値・許可ツール・action ステップを確認してから使ってください。
参考リンク
- microsoft/skill-recorder（GitHub）
- README.md
- INSTALL.md
- Copilot Cowork common questions（Microsoft Learn）
- Build your first skill（Copilot Developer Camp）
- CAT Agent Skills ギャラリー
- Skill Recorder徹底解説（AI Heartland） — ソース実測に基づく検証記事
- Microsoft Skill Recorderとは？（AI革命）
本記事は 2026年8月時点の公開情報およびコミュニティによる v0.3.1 のソース検証結果に基づいています。ソースコードの挙動に関する記述はバージョンにより変わり得ます。導入判断の際は必ず最新のリポジトリをご確認ください。