Skill Recorder徹底解説｜作業を録画してAIエージェントのスキルに変えるMicrosoft公式OSS

「この作業、毎回やってるからAIに任せたい」と思ったとき、いまは手順書を書く必要がある。Microsoftが2026年7月29日に公開した microsoft/skill-recorder は、そこを逆転させる。手順を書く代わりに、実際にその作業を1回やって見せる。画面・ウィンドウの切り替え・訪れたURL・（任意で）声の解説を記録し、GitHub Copilotがそれを「意図＋順序つきの手順」として再構成し、エージェントが再利用できる形に変換する。

Skill Recorderとは——「書くスキル」から「録るスキル」への反転

Agent Skillsは、ここ数か月で「フォルダに SKILL.md を置く」という形式にほぼ収束した。だが収束したのは形式であって、中身を用意する手間は誰も解決していない。手順書は結局、人間が思い出しながら文章にする必要がある。

Skill Recorderはこの前提を反転させる。READMEの1行目がそのまま設計思想になっている。

Record yourself doing a task once, then turn it into a skill your AI agent can repeat. （出典: microsoft/skill-recorder README）

思い出して書くのではなく、やって見せる。人間が業務を教えるときに実際にやっていることと同じ手順だ。そして重要なのは、記録した操作をそのまま再生する（UIクリックのリプレイ）のではない、と明言している点である。READMEは生成物について「Both prefer the agent’s native tools (like the gh CLI or web_fetch) over replaying UI clicks」と書く。つまり「ブラウザでこのボタンを押す」ではなく「gh CLIでPR一覧を取る」に翻訳することを狙っている。

この方針はソース側の指示文にも一致していた。electron/skillbuilder/instructions.ts には ## Prefer native tools (read the catalogue below) という見出しがあり、「When a service ships a first-class CLI on the device, prefer it over the browser」と続く。UI操作の記録を、UI操作ではない形に落とすことが明示的な設計目標になっている。

リポジトリの実体は、GitHub APIで取得した値で次の通りだった。

公開から4日で★398という立ち上がりだが、コミット数103・コントリビューター3名という規模感の通り、まだ若いプロジェクトである。v0.1.0・v0.2.0・v0.2.1・v0.3.0 の4リリースは 2026-07-29 19:50:29〜19:50:31 UTC の3秒間に、v0.3.1のみ翌日に公開されている。初期リリース群がまとめて発行された形だが、その理由はリポジトリ上に記載がないため、ここでは事実の記載にとどめる。

エクスポート先はScoutとCowork——Claude Codeは選択肢に無い

ここが本記事でもっとも伝えたい点であり、READMEを読むだけでは分からない部分だ。

READMEは生成物を一貫して「an agent」「your AI agent」としか書かない。どのエージェント向けなのかは本文に登場しない。そこでソースを読むと、common/skill.ts に対象が列挙されていた。

実際にリポジトリをクローンし、リポジトリ自身のローダー経由でこの定数を実行して出力させた結果が次である。

=== ARCHITECTURES ===
scout           enabled=true
cowork          enabled=true
copilot-studio  enabled=false
=== TARGETS ===
skill/scout            enabled=true   Scout skill
automation/scout       enabled=true   Scout automation
skill/cowork           enabled=true   Cowork skill
skill/copilot-studio   enabled=false  Copilot Studio

つまり選べる出力先は Scout・Cowork・Copilot Studio（無効） の3系統4枠で、Claude Codeも、Cursorも、汎用の「ローカルの .claude/skills/ に置く」も選択肢に無い。

ソース内の各対象の説明文（note）はそれぞれこう書かれている。Scoutが「Microsoft Scout: native WorkIQ, browser, files, and built-in skills.」、Coworkが「Microsoft 365 Copilot (Cowork): native Teams, Outlook, Calendar, SharePoint, files, and built-in skills.」、Copilot Studioは「Coming soon.」のみ。Scoutについては筆者の知識時点より後に登場した製品のため、リポジトリが自称する上記の説明以上の内容は本記事では断定しない。

Automation側も同様にMicrosoft寄りで、common/automation.ts のコメントには「rendered to Scout’s import JSON and written into an importable bundle folder (Scout imports it; it is not auto-loaded like a skill)」とある。スケジュールの表現も「Scoutの3種（single / interval / multi）を写したもの」と明記され、intervalMinutes には「1440を割り切ること」というバリデーションまで入っていた。

何が記録され、どこへ送られるのか

画面録画ツールである以上、「何が・どこへ行くのか」は使う前に確認したい部分だろう。

READMEの記述は明快だ。録画・保存・フレーム抽出・ナレーションの文字起こしは端末内で行われ、録画中は何も外部に出ない。送信が起きるのは Analyzeを押したときで、そこで初めてイベントの時系列・抽出画像・ナレーションのテキストがGitHubのクラウドへ渡る。

記録される信号そのものは common/config.ts に単一の定義がある。注目すべきはこのファイル冒頭のコメントだ。

The recorder captures every available signal on every recording — there is no user-facing capture level. （出典: common/config.ts）

記録項目を選ぶUIは無い。設計判断として「重なり合うOS権限をなぞるだけの段階的ピッカー」をやめ、透明性は「何が記録されるか」の説明で担保する、と書かれている。実際の項目と必要な権限は次の通り。

（出典: common/config.ts の CAPTURE_SOURCES / FULL_CAPTURE）

ナレーションは任意で、READMEによればWhisperがサポートする99言語で端末内で文字起こしされ、初回のみ約252MBのモデルをダウンロードする。日本語の音声解説を付けられるのは、日本語話者にとっては素直に利点だ。

秘密情報の扱いについては、READMEが2か所で警告している。パスワード・トークン・APIキーなどを「録画・入力・貼り付け・表示・コピー・読み上げ」しないこと、とかなり具体的に列挙されている。この警告が単なる文言でないことは、テストコードからも読み取れた。electron/recording-privacy.test.ts には次の2件があり、手元でも合格を確認している。

・詳細な開示内容をレビューするまで、録画開始のたびに警告を出す（startDecision() が show-warning を返し続ける）
・レビュー済みの記録はアプリのプロセスをまたいで残らない（次回起動時はまた警告から始まる）

「一度チェックしたら二度と出ない」タイプの同意UIにしていない点は、扱うデータの性質を踏まえた妥当な設計に見える。

ナレーションの扱いにも、同じ「黙って進めない」という方針が現れている。electron/narration/analyze-gate.ts はたった1行の純粋関数だが、コメントが意図を説明していた。

The narration is the user’s own words describing their intent, so analysis must never silently run without it when it’s available but not yet transcribed. （出典: electron/narration/analyze-gate.ts）

音声が保存されていて、まだ文字起こしが無いときだけ「文字起こし→解析」の順に進む。音声が無いセッション、あるいは既に文字起こし済みのセッションはそのまま解析へ行く。ユーザーが自分の言葉で吹き込んだ意図を、取りこぼしたまま解析を走らせないための門である。録画映像から推測するより本人の説明のほうが正確なのだから、理屈は通っている。

なおナレーション周りには、Whisperが無音区間で定型句を幻覚（hallucinate）する既知の問題への対処も入っている。transcribe.ts には「Whisper hallucinates stock phrases over silence/noise; drop the usual suspects」というコメントとともに、無音判定と定型句の除去が実装されていた。音声を扱うツールとしては現実的な作り込みだ。

録画から生成までの流れ

アプリの操作フローは4段階で、READMEの「How it works」と実装の構成が一致している。

ポイントは、承認ゲートが2段あることだ。1段目はAnalyze直後の「意図と手順」の確認（画面上で手順をクリックして編集・並べ替え・追加・削除できる）、2段目はスキルを書く前のプラン提示である。common/skill.ts のコメントによれば、propose_plan は「どう一般化するか、どんな固定値が必要か、どのnative toolを使うか」を先に出し、ユーザーが自然言語で詰めてから初めて submit_skill に進む。いきなり成果物を出さず、方針を先に見せる構成になっている。

手順を「計算」と「実行」に割る

プランの中の手順は、ただの文字列ではなく型を持っている。PlanStepKind は calculation と action の2値で、コメントが理由を説明している。

読む・導出する・判断する・整形するだけで外部に影響を与えないものが calculation、submit・send・create・deleteのように世界を変えるものが action。分ける理由はコメントに「Splitting them keeps the plan honest about side effects; the actions are the risky surface」と書かれている。副作用のある手順だけを危険面として明示するという考え方だ。

録画から自動生成されたスキルを人間がレビューするとき、全手順を等しく読むのは現実的でない。「どれが取り返しのつかない操作か」が型で分かれているのは、レビュー負荷の面で理にかなっている。

Skill Recorderが生成するSKILL.mdを実際に描画して確かめた

renderSkillMarkdown() はCopilotに依存しない純粋関数なので、手元で直接呼べる。実際に呼び出して、このツールが吐くバイト列そのものを確認した。

リポジトリのテストがNode標準のテストランナーと --experimental-transform-types（TypeScriptをそのまま実行する仕組み）を使っているため、同じローダーを借りて実行する。

git clone https://github.com/microsoft/skill-recorder.git
cd skill-recorder && npm ci
# リポジトリ自身のテストを実行（Copilotのサインイン不要）
npm test

手元（macOS）での実行結果は 58 tests / 58 pass / 0 fail、所要 1.2秒だった。テスト対象は音声処理・マイク・ナレーション・フレーム抽出・録画コントロール・プライバシー・セッション管理・コンプライアンスなど14ファイルで、Copilotへのサインインなしで通る。

その上で renderSkillMarkdown() に、コロンとカンマと日本語を含む説明文・allowed-tools 2件・`` という値トークンを含む本文を渡した。出力は次の通り（234バイト）。

---
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が壊れないよう JSON.stringify を通している（ソースのコメントにも「so colons/commas in it never break the YAML」とある）。日本語もそのまま通る
・トークンは書き出し時に実際の値へ置換される**。プラン段階では という名前付きの固定値として扱われ、レンダリング時にURLへ展開された
・allowed-tools はfrontmatterに配列で入る**。ここに workiq_search_chats のようなScout固有のツール名が入るため、形式が同じでも中身は行き先に依存する

この `` の仕組みは、READMEが掲げる「1件の送信を録れば全件送信を教えられる」という一般化と対になっている。SkillPlan のスキーマを読むと、プランは手順の羅列だけでなく generalization（録画された具体例をどう一般化したか、という説明）と values（URL・パス・定数などの固定リテラル）を別々のフィールドとして持つ。録画に映った「1回きりの具体値」を固定値として切り出し、繰り返す部分だけを手順として残す、という分離だ。

言い換えれば、録画から作られるのは「操作の記録」ではなく「変わらない部分と変わる部分に分解された手順」である。ここが単なるマクロ記録ツールとの分岐点で、レビュー時に values を見れば「このスキルが決め打ちしている値」が一覧で分かる構造にもなっている。

日本語のスキル名は消える——slugifySkillNameの実測

日本語で作業して日本語で解説を吹き込む使い方を考えると、無視できない挙動が見つかった。

スキル名を作る slugifySkillName() は、[^a-z0-9]+ に当たる文字をすべてハイフンに潰し、前後のハイフンを削り、60文字で切る。日本語は英数字ではないため、丸ごと消える。同じ関数を手元で実行した結果が次である。

"経費精算を提出する" -> "recorded-skill"
"日報を作成"       -> "recorded-skill"
"Slackに投稿する"  -> "slack"
"請求書PDFを保存"  -> "pdf"
"会議メモを整理"   -> "recorded-skill"

distinct inputs: 5  distinct slugs: 3  => [ 'recorded-skill', 'slack', 'pdf' ]

5つの異なる業務名が3つの名前に潰れ、うち3件は同一の recorded-skill になった。日本語が完全に消えた場合はフォールバック値の recorded-skill が使われる仕様（ソース上 return slug || "recorded-skill";）で、これは名前の衝突を意味する。また「請求書PDFを保存」が pdf になるように、たまたま混ざったASCII断片だけが名前になるケースも起きる。

ただし、これを「バグ」と決めつけるのは正しくない。ビルダー側の指示を確認すると、electron/skillbuilder/scout-catalog.ts と cowork-catalog.ts の双方に `name` — kebab-case, `^[a-z0-9-]+$` という要求が書かれており、ツール定義（electron/skillbuilder/tools.ts）にも「kebab-case skill id, e.g. “submit-expense-records”」と例示がある。モデルには英語のkebab-caseで名前を出すよう指示されているため、通常の経路では日本語名にならない想定だ。slugifySkillName はあくまで、モデルが指示に従わなかった場合に不正な名前を通さないためのガードレールである。

とはいえ、日本語話者が実運用で気に留める価値はある。プランを日本語で詰める過程で名前が日本語に寄れば、静かに recorded-skill に落ちる。生成後はスキル名だけ目視するのが安全だ。なお、混在時の挙動も測っており、「Slack へ investor update を投稿」→ slack-investor-update、「PR 一覧を取得 (GitHub)」→ pr-github と、ASCII部分は素直に残る。60文字の上限も実測で確認した（140文字の入力→60文字）。

Skill Recorderのインストールと同梱の評価ハーネス

配布形態も一般的なアプリと違うので触れておきたい。Skill Recorderはビルド済みバイナリを配らない。READMEいわく「published as a source release」で、1コマンドが①固定されたNode.jsランタイムをダウンロードし、②リリースのコミットを自分のマシンでビルドし、③再起動できるアプリとして登録する。グローバルには何もインストールされない。

# 実際のコマンドはリリースページに掲載された40文字のコミットハッシュを入れる
commit="<40-character-release-commit>"
curl -fsSL "https://raw.githubusercontent.com/microsoft/skill-recorder/$commit/install.sh" \
  | SKILL_RECORDER_COMMIT="$commit" bash

READMEはこの方式の意図を「The commit pins both the downloaded script and the source it builds」と説明する。取得するスクリプトとビルドされるソースの両方が同じコミットに固定されるという設計だ。install.sh を読むと、Node 24系を https://nodejs.org/dist/latest-v24.x から取得し、取得後に [ "${node_version%%.*}" = "24" ] でメジャーバージョンを検証して合わなければ停止する、という実装になっていた。

実行前にスクリプトを読みたい場合の手順、更新、アンインストールは INSTALL.md に分けて書かれている。curlをそのままbashへパイプする形が気になるなら、まずそちらを読むのが筋だろう。ターミナルを閉じてもアプリを動かし続けたい場合は SKILL_RECORDER_DETACHED=1 を付ける、といった環境変数もREADMEに列挙されている。インストール先はmacOSなら ~/Applications で、Spotlight・Launchpad・Dockから再起動できる。

なお動作要件として、READMEは「You’ll need a GitHub account with Copilot access」と明記している。Copilot CLI自体はアプリに同梱される（electron/copilot-cli-path.ts は @github/copilot-<platform>-<arch> というパッケージからバイナリを解決していた）。macOSが主対象で、Windows 11（x64／ARM64）もサポート対象、Ubuntu向けのインストール手順も用意されている。

評価用のハーネスが同梱されている（describer / builder）

もう一点、若いリポジトリとしては珍しい部分がある。Copilotの「describer（記録から意図と手順を起こす部分）」と「builder」に対して、fixtureベースの評価スイートが同梱されている。

npm run eval          # describerを合成録画に対して採点
npm run eval:builder  # スキル／automationの一般化を採点

evals/README.md は、あえて実キャプチャを使わない理由を「Live capture … is flaky and slow, and it’s not the part we’re trying to measure」と説明している。イベント列を固定することでdescriberを切り出し、1シナリオ15〜25秒で再現可能にし、失敗したらキャプチャの不安定さではなくモデル／指示文を指していると分かるようにする、という設計だ。ただしこの2コマンドはCopilot CLIへのサインインが必要なため、本記事では実行していない（サインイン不要な npm test のみ実行した）。

類似ツールとの比較——生成側・管理側・完成品集のどこに座るか

「スキル」を扱うOSSは増えたが、担当している工程はそれぞれ違う。Skill Recorderの位置は入力の作り方が決定的に異なる。

表の通り、入力元に「画面操作の録画」を置いているのはSkill Recorderだけである。テキストで指示して生成させる（Agent Skill Creator）、既にあるスキルを管理・配布する（Skill Harbor / SkillHub）、人間が書いた完成品を使う（mattpocock/skills）、品質を測る（Waza）——これらはいずれも「スキルの中身は言語で表現できる」ことを前提にしている。Skill Recorderが賭けているのは、言語化できていない作業ほど自動化されずに残っているという反対側の仮説だ。

同じMicrosoftから出ているWazaが「できたスキルを測る」側、Skill Recorderが「スキルを作る」側と、工程として綺麗に分かれている点も押さえておきたい。作る側と測る側が別リポジトリとして並行して出ていることからも、Microsoftがスキルを「一度書いて終わり」ではなく、生成・評価・配布まで含めた工程として扱おうとしている様子がうかがえる。

現時点の評価——向いている場面と、待ったほうがいい場面

公開4日で★398という数字は関心の高さを示すが、採用判断は分けて考えたい。

向いている場面

・Microsoft 365 / Scout環境で働いている。エクスポート先がそこに限られている以上、この前提を満たすかどうかが最大の分岐点になる
・説明しづらいGUI作業を自動化したい。Excelとブラウザとチャットを行き来する類の、手順書に書き起こしづらい作業ほど録画の利点が出る
・手順の一般化をレビューしたい。プラン提示→自然言語で修正→確定、という2段ゲートは、生成物をそのまま信じない運用に向く

待ったほうがいい場面

・Claude CodeやCursorでスキルを使いたい。現時点でエクスポート先に無い。この用途なら上の表にある生成側のツールを見るほうが早い
・Copilotのサブスクリプションが無い。Analyzeが動かないため、録画しかできない
・機密性の高い画面を扱う。記録項目を絞るUIが無く、Analyzeで画面画像がクラウドへ渡る。READMEの警告どおり、扱う情報を選べる作業に限るのが前提になる
・安定性を求める。v0.3.1・コミット103・公開からわずか4日という段階で、Open Issuesは26件ある。仕様が動く前提で触るべきフェーズだろう

総じて、アイデアとしては筋が良く、適用範囲は現時点でかなり狭いというのが実装を読んだ上での評価だ。「録画してスキルにする」という発想自体はエージェント全般に効くもので、エクスポート先が広がれば評価は変わる。copilot-studio が enabled: false で置かれていることからも、対象を増やす前提の設計にはなっている。

参照ソース

・microsoft/skill-recorder — GitHub（README・INSTALL.md・common/skill.ts・common/config.ts・common/automation.ts・electron/skillbuilder/instructions.ts・evals/README.md を v0.3.1 時点で参照。star・リリース・言語構成はGitHub APIで取得）
・microsoft/skill-recorder Releases（v0.1.0〜v0.3.1の公開日時）
・microsoft/skill-recorder LICENSE（MIT）