Microsoft が OSS として公開した microsoft/skill-recorder は、デスクトップ上の実作業を録画し、AI エージェント用のスキル定義（SKILL.md）へ自動変換する Electron アプリです。
この記事では、次の3点を扱います。
- Skill Recorder が「実演の録画」から何をどう取り出しているのか
- 従来の RPA や手書きプロンプトと構造的に何が違うのか
- 現場に入れるとき、先に決めておかないと事故になる条件は何か
対象読者は、社内でエージェント活用の枠組みを決める立場の方です。ツールの操作手順ではなく、プロセスをどう組み替えるかの判断材料として読めるよう整理しています。
なお本記事の記述は、2026-08-03 時点のリポジトリ（約 748 stars、103 コミット、Open Issue 20 件、Open PR 9 件、ライセンス MIT）の公開情報にもとづきます。開発の初期段階にあるプロジェクトなので、細部の挙動は変わりうる前提でお読みください。
スキル作成の起点が「執筆」から「実演」に移る
エージェントに仕事を任せるには、手順をスキルとして与える必要があります。これまでその作成作業は、人間が自然言語で手順書を書き下ろす「執筆」でした。
執筆方式には構造的な弱点があります。
- 熟練者ほど手順を暗黙知として持っており、言語化の段階で工程が抜ける
- 「いつもの画面で承認する」のような、書き手には自明で読み手には不明な記述が残る
- 書いた手順が実作業と一致しているかを検証する手段がない
Skill Recorder はこの起点を変えます。作業者は普段どおり作業し、必要なら声で補足するだけです。ツール側が観察して、意図と手順を再構成します。
スキル作成は次の4工程のパイプラインになります。
| 工程 | 担い手 | 内容 |
|---|---|---|
| 観察 (Observation) | ツール | 画面・コンテキスト・音声をローカル記録 |
| 抽出 (Abstraction) | Copilot CLI | 意図と順序付きステップへ再構成 |
| 点検 (Inspection) | 人間 | 一般化・秘密情報の除去・不審コマンドの確認 |
| 展開 (Deployment) | 人間 / CI | 検証してエージェントへ配布 |
重要なのは、3番目の点検が省略可能な工程ではないことです。この点は後述します。
何を記録し、どこでクラウドに出るのか
録画中にツールが集めるのは、画面フレームだけではありません。
- 画面の視覚的変化（Chromium ベースの動的低レートフレーム抽出）
- アクティブウィンドウ名
- 閲覧 URL（macOS 上）
- クリップボードのプレビューテキスト
- マイクからの音声解説
音声は約 252 MB のオンデバイス Whisper モデルで文字起こしされ、99 言語に対応します。ここが端末内で完結する点は、社内利用を検討するうえで効いてきます。
処理の境界は次のように分かれます。
[ 実作業の録画 ] ← すべてローカル
├── 画面フレーム
├── コンテキスト (ウィンドウ名 / URL / クリップボード)
└── 音声解説 (ローカル Whisper で文字起こし)
│
▼ ユーザーが「Analyze」を押したときだけ送信
[ 意図と手順の再構成 ] ← GitHub Copilot クラウド
│
▼ 人間によるレビュー・一般化・秘密情報の除去
[ 再利用可能なエージェント資産 ]
├── Skill (オンデマンド実行: SKILL.md)
└── Automation (定期・トリガー実行スクリプト)
録画・音声処理・タイムライン生成はローカルで完結します。外部へ出るのは、ミニコントロールバーで「Analyze」を明示的に押した瞬間だけです。
この境界設計は、裏を返せば 「Analyze を押す判断」が情報統制の単一のゲートになっているということでもあります。ツールが守ってくれるのはここまでで、その先は運用側の設計責任です。
RPA との違いは「何を再生するか」
画面操作を記録して自動化する道具は以前からあります。ただし Skill Recorder が生成するものは、従来の RPA とは再生対象が違います。
一般的な RPA は、マウスの X, Y 座標や DOM 要素へのクリックを記録し、それをそのまま再実行します。画面が正解であり、画面が変わると壊れます。
Skill Recorder は、操作の裏にある本質的なコマンドへのマッピングを優先します。ブラウザでフォームを送信した実演から、gh のような CLI コマンドや web_fetch のような API 呼び出しを主体とするスキルを組み立てる方向です。UI が変わってもコマンドが同じなら壊れません。
3方式を並べると、トレードオフがはっきりします。
| 評価軸 | RPA (UI 自動化) | 手動でのスキル執筆 | Skill Recorder |
|---|---|---|---|
| 作成起点 | 画面要素 (DOM / 座標) の記録 | 人間の頭の中の文章化 | 実演の自動観察 |
| 実行形式 | UI のマウス・キーボード再生 | エージェントによるプロンプト解釈 | ネイティブツール (CLI / API) 優先 |
| 画面変更への耐性 | 極めて低い | 高い（概念レベルの指示のため） | 高い（CLI / API へ抽象化） |
| 作成コスト | 専用スクリプトの記述が必要 | 記述漏れ・揺らぎの補正に時間 | 実演 1 回とレビュー |
| ガバナンス | 画面権限で暗黙的に実行 | プロンプトインジェクションのリスク | 人間の承認を前提にした設計 |
「作成コストが下がる」だけの話に見えますが、効き方が大きいのは耐変更性のほうです。RPA 資産の維持コストは、業務システムの UI 更新のたびに発生します。CLI / API へ抽象化されたスキルは、そのメンテナンス連鎖から外れます。
期待しすぎると事故になる3つの点
導入判断では、うまくいく話より先に、限界とリスクを押さえる必要があります。
1. 記録は無差別なので、秘密情報が入りうる
画面録画とクリップボード取得は、内容を選びません。パスワード、API キー、個人情報、社内機密が記録に含まれる可能性があります。
そのうえで、「Analyze」を押した瞬間に抽出フレームとタイムラインが GitHub Copilot クラウドへ送信されます。誤って Analyze を押すことが、そのまま外部送信になる構造です。
さらに、実演した環境固有のパスや社内 ID が一般化されず、SKILL.md にリテラルとして残る事故も起こりえます。これは漏洩であると同時に、他の人が使えないスキルが量産される原因にもなります。
対策として最低限そろえるべきものは次のとおりです。
- 録画対象の作業と、録画してはいけない画面・操作の線引きを事前に決める
- 検証用アカウント・ダミーデータで実演する運用にする
SKILL.mdに対するシークレット検査を、配布前のゲートに組み込む
2. CLI / API がない相手には抽象化できない
Skill Recorder の強みは、UI 操作をネイティブツール呼び出しへ置き換えられる点にあります。逆に言えば、置き換え先が存在しない領域では強みが消えます。
- CLI も API も提供されていないレガシーな社内基幹システム
- グラフィカルな特殊 UI 操作（描画・配置など）
こうした対象では、一般化に失敗するか、粗い自然言語の指示にとどまります。導入効果を見積もるときは、対象業務が触るシステムに CLI / API があるかを先に確認するのが現実的です。
3. 1回の実演からは、うまくいった経路しか出てこない
生成の入力は1回の実演デモです。したがって、例外処理や条件分岐が抜け落ちやすくなります。
たとえば「ログインセッションが切れていた場合」「対象データが0件だった場合」「承認が却下された場合」といった分岐は、成功した実演には現れません。生成された手順はハッピーパスの記録であり、そのまま本番の自動化に載せると、想定外の状態で止まるか、誤った操作を続けます。
結論: これは下書き生成器である
3点をまとめると、Skill Recorder は自動化の終着点ではなく、質の高い下書きを高速に作る装置です。
現場運用では、生成された SKILL.md に対して人間が次を行うレビュー工程を、パイプラインへ明示的に組み込むことが前提条件になります。
- ノイズの除去
- 環境固有値のパラメータ変数化
- 認証情報の排除
- 不審なコマンドが混ざっていないかの点検
- 例外パスの追記
この工程を「あとで気づいた人がやる」にすると、必ず抜けます。ゲートとして設計してください。
導入は「ツール追加」ではなく「プロセス再設計」
以上を踏まえると、Skill Recorder の導入判断は、便利ツールを1つ増やす話ではありません。組織のスキル開発プロセス全体を組み替える話として扱うのが適切です。
具体的なアクションは3つです。
1. スキル作成の工程定義を差し替える
「文章を書く仕事」から「エキスパートの作業観察 → 自動抽出 → エンジニアによる点検 → CI 検証」という標準パイプラインへ移します。誰が観察され、誰が点検し、誰が承認するかを役割として決めます。
2. 点検を通過しないスキルは本番に出さない
生成された SKILL.md をそのまま本番エージェントに渡さず、変数の一般化とシークレット検査を通すゲートチェックを設けます。前節の3リスクは、すべてこのゲートで受け止める設計です。
3. ネイティブツールのエコシステムを先に整える
gh のような CLI や社内 API（MCP サーバーを含む）を拡充しておくほど、Skill Recorder の抽象化能力は引き出されます。逆に画面操作しか手段がない業務では、投資対効果が落ちます。この整備は Skill Recorder の導入前に効いてくる前提条件です。
つまり、導入検討の順序は「録画ツールを配る」ではなく、「対象業務の CLI / API 化状況を棚卸しする → 点検ゲートを設計する → 録画を始める」になります。
まだ分かっていないこと
判断材料として、現時点で確認できていない論点も明示しておきます。
- レガシー Web アプリでの抽象化精度: コマンドラインが存在しない複雑な Web UI に対し、Copilot CLI がどの解像度でスキル化できるか
- 複数デモの合成: 成功パターンとエラーパターンなど複数回の録画から、条件分岐を含む堅牢な
SKILL.mdを自動合成できるか
とくに2点目が実現すると、前述の「ハッピーパスへの偏り」というリスクの性質が変わります。導入後も追いかける価値のある論点です。
まとめ
- Skill Recorder は、スキル作成の起点を「執筆」から「実演の観察」へ移す OSS ツール
- 録画・音声処理はローカル完結で、外部送信は「Analyze」を押したときだけ。この1点が情報統制のゲートになる
- RPA との違いは座標再生ではなく CLI / API へ抽象化する点にあり、効くのは作成コストより画面変更への耐性
- 秘密情報の混入・CLI 非対応システム・ハッピーパス偏りの3つが限界。生成物は完成品ではなく下書き
- 導入判断は「ツール追加」ではなく、点検ゲートの設計とネイティブツール整備を含むプロセス再設計として扱う
この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！