記事公開日
【Copilot Studio】SkillsとMemoryを設定してみた｜新UIで増えた2つの機能
この記事の重要ポイント
- Skills は Markdown で書く再利用可能な指示です。
AI に下書きさせる・空から作る・ファイルをアップロードするの3通りで用意でき、複数のエージェントで使い回せます。 - Memory に残るのはその利用者に固有で、次回以降も役に立つ情報です。
毎回ナレッジから引ける社内情報は対象になりません。 - Memory はユーザーごとに記憶を保持しますが、28日間活動がないとそのユーザーの記憶は削除されます。
またグループ チャットや Microsoft Teams のチャネルでは無効化されます。 - Memory は「運用に対応したプレビュー」で、追加使用条件の対象です。
提供状況・画面構成・名称は変更される場合があるため、最新の情報は Microsoft 公式ドキュメントでご確認ください。
こんにちは、DXソリューション営業本部の中井です。
本ブログでは、Copilot Studio の GitHub Copilot ハーネスにある Skills と Memory の2つを取り上げます。
以前は「新しいエージェント エクスペリエンス」と呼ばれていたもので、ドキュメントでの呼び方が整理されつつあります。
正式名称は GitHub Copilot ハーネスですが、毎回この長さで書くと読みづらいため、本ブログの中だけ「新UI」とも呼ばせていただきます。
Microsoft が定めた名称ではありませんので、その点はご承知おきください。
エージェントに何を知らせ、何を覚えさせ、どう振る舞わせるかを設計したい方に向けて、実際に設定しながら解説します。
執筆者：中井（DXソリューション営業本部）
Power Platform と Copilot Studio を中心に業務改善・DX 推進に従事。
市民開発者の教育・コミュニティ運営支援やガバナンス整備を強みとし、ハンズオン／ハッカソン登壇は数十件以上。
2つのコンポーネントの役割
GitHub Copilot ハーネスの Build タブには、エージェントが使えるリソースと機能を設定するコンポーネント パネルがあります。
その中でも、GitHub Copilot ハーネスならではの要素が Skills と Memory の2つです。
| コンポーネント | 役割 |
|---|---|
| Skills | 特定のタスクに対する振る舞いを、再利用可能な指示として定義する |
| Memory | 会話をまたいでコンテキストを保持し、応答をパーソナライズする |
ここで押さえておきたいのが、Skills と Tools の違いです。
Tools はコネクタや API など外部サービスへの接続を担います。
対して Skills は自己完結した指示とロジックであり、外部への接続を伴いません。
公式ドキュメントでは、Skills をエージェントが必要に応じて有効化できる「専門的な役割やモード」と説明しています。
前提条件と提供状況
どちらも、GitHub Copilot ハーネスで作成したエージェントで利用します。
クラシック版には存在しないため、クラシック版に切り替えている場合は新UIに戻す必要があります。
このハーネス自体は、2026年8月3日に一般提供が開始されました。
本記事の執筆時点（2026年8月）における提供状況は次の通りです。
| 対象 | 提供状況 |
|---|---|
| Skills | 画面上にプレビューの表記なし |
| Memory | 運用に対応したプレビュー（追加使用条件の対象） |
ハーネス自体は一般提供になりましたが、同じ GitHub Copilot ハーネスの機能でも2つで扱いが違います。
Skills は画面上にプレビューの表記がありません。
一方 Memory は「運用に対応したプレビュー」とされ、追加使用条件の対象になります。
本番運用を見据えるなら、この差は押さえておきたいところです。
⚠️ 提供区分の表記は短い期間で変わっています
本記事の準備中にも、公式ドキュメントの構成と呼称が変わりました。
導入判断の際は、必ず最新の公式ドキュメントでご確認ください。
あわせて押さえておきたいのが課金です。
ここで扱う2つはいずれも GitHub Copilot ハーネスの機能で、公式ドキュメントには「使用率に基づく請求は、エージェントの使用、構築、テスト、評価に適用されます」と記載されています。
消費する操作として挙げられているのは、自然言語を用いた自動化ソリューションの作成、エージェントのプレビューとテスト、エージェント評価の作成の3つです。
設定を手で入力する作業そのものは挙げられていませんが、設定したスキルやメモリの効き方はプレビューで動かして確かめることになります。
検証を始める前に、環境へのクレジット割り当てを確認しておくことをおすすめします。
課金の仕組みと見積もりの考え方については、こちらの記事でまとめています。
実際に使ってみた
Skills を作って複数のエージェントで使い回す
Skills は、名前と説明、そして Markdown で書かれた指示のセットからなります。
エージェントの振る舞いを、焦点を絞った単位に分割して管理できるのが特徴です。
公式ドキュメントでは、Skills を使うメリットとして次の4点が挙げられています。
| 観点 | 内容 |
|---|---|
| 再利用性 | 一度作成すれば、複数のエージェントに追加できる |
| モジュール性 | 複雑な振る舞いを、焦点の絞られた扱いやすい単位に分割できる |
| 共有のしやすさ | Markdown ファイルやパッケージとしてエクスポートし、他者と共有できる |
| 明確さ | スキルごとに目的が明確になり、振る舞いを理解・保守しやすい |
スキルの用意のしかたは、コンポーネント パネルの Skills から追加する画面で3つ選べます。
| 方法 | 内容 |
|---|---|
| Generate with AI | やりたいことを言葉で伝えて、スキルの下書きを作ってもらう。 ゼロから書くのが大変なときの入口として使いやすい |
| Create from blank | 名前・説明・指示を自分で入力して作る。 作りたい内容が固まっているときはこちらが早い |
| Upload a skill | 手元で用意したファイルをアップロードする。 使い慣れたエディタで書いた指示を持ち込める |
アップロードで受け付けるフォーマットは2種類です。
- スキル名と説明を YAML フロントマターに記述し、指示を Markdown で書いた .md ファイル
- SKILL.md を含む ZIP ファイル。
スクリプト、テンプレート、参照ドキュメントなどの補助ファイルを任意で同梱できる
💡 スキル名に使える文字
公式ドキュメントには、名前は小文字・数字・ハイフンのみを使い、先頭と末尾にハイフンを置かないよう記載されています。
例として customer-support-escalation のような書き方が挙げられています。
ここでは Upload a skill の手順を見てみます。
STEP 1 Copilot Studio でエージェントを開き、Build タブを選択します。
STEP 2 コンポーネント パネルで Skills を選択します。
STEP 3 スキルの追加画面で「Upload a skill」を選択します。
STEP 4 アップロード ボックスにファイルをドラッグ＆ドロップします。
ボックスを選択してファイルを参照する方法でも構いません。
STEP 5 ファイルが検証され、スキルがエージェントに追加されます。
スキルが呼び出されるタイミングは、こちらで明示的に指定するものではありません。
エージェント側が、利用者のメッセージとスキルの説明文を照らし合わせて起動を判断します。
指示の中身については、公式ドキュメントが盛り込むべき要素を挙げています。
- スキルが扱うタスクやシナリオの明確な説明
- エージェントがどう動くべきかの段階的なガイダンス
- 応答の形式に関する要件
- エッジケースとその対処法
- 該当する場合、使用すべきツールへの参照
💡 説明文の書き方が精度を左右します
適切に書かれたスキルの説明文が、正しいスキルを正しいタイミングで呼び出す助けになります。
指示の中身を作り込む前に、まず「どんなときに使うスキルなのか」が伝わる説明文を用意することをおすすめします。
なお、アップロードしたスキルは、使い慣れたテキストエディタで指示を編集してから差し替えることもできます。
まずシンプルなスキルから始めて、テストしながら磨き込んでいく進め方が良いかと思います。
Memory でユーザーごとの記憶を持たせる
Memory は、エージェントがやり取りの中の詳細を記憶し、次回以降に活かすための機能です。
有効にすると、エージェントは利用者ごとに個別のメモリ ストアを保持します。
記憶は、次の3段階で扱われます。
- キャプチャ：利用者の好みや、会話中に共有された関連するコンテキストなどのシグナルを記録する
- ストア：これらのシグナルを、Microsoft 管理ストレージ内の専用フォルダーにファイルとして保存する
- 適用：以降のやり取りでこのメモリを読み出し、応答や判断に反映する
有効化は Build タブのコンポーネント パネルにある Memory のトグルで行います。
作り手が利用の可否を制御できる、エージェント単位の機能です。
気になるのは、何が記憶に残って、何が残らないのかです。
ドキュメントの「キャプチャ」の説明だけでは判断しづらかったので、実際に会話しながら確かめてみました。
触ってみた範囲では、指示文・ナレッジ・スキル・ツール等では補えない、その利用者に固有の情報が対象になっているように見えます。
言い換えると、次回の会話でも役に立つ、その人ならではの情報かどうかが判断の軸になっているようでした。
| 扱い | 対象 |
|---|---|
| 記憶される | その利用者に固有で、次回以降のやり取りでも役に立つ情報 |
| 記憶されない | SharePoint のナレッジのように、必要なときに毎回引ける社内情報 |
試しに自分に関する情報を会話の中で伝えてみたところ、きちんとメモリに保存されました。
そのうえで新しいチャットを開いて自分のことを尋ねると、保存された記憶をもとに回答が返ってきます。
会話をまたいでコンテキストが引き継がれることを、この流れで確認できました。
💡 ナレッジと Memory の使い分け
社内規程や手順書のような誰にとっても同じ情報はナレッジ ソースの担当で、Memory には入りません。
Memory が受け持つのは利用者ごとに違う情報です。
「毎回検索して引けるものはナレッジ、その人に紐づくものは Memory」と切り分けて設計すると、どちらに何を持たせるか迷わずに済みます。
ここで押さえておきたいのが、記憶を管理するのは作り手ではなく利用者本人だという点です。
作り手ができるのは Memory のオン／オフを切り替えることまでで、中身を覗くことはできません。
保存された記憶は、利用者が専用のメモリ ポータルで管理できます。
ポータルは新しいブラウザー タブで開き、保存されている記憶の確認と、すべての記憶の削除ができます。
利用者が新しいチャネルでメモリ対応エージェントと初めてやり取りしたとき、エージェントの応答にポータルへのリンクが含まれます。
会話の途中でも、記憶について尋ねればリンクが表示されます。
制限事項
どちらも便利な機能ですが、運用に乗せる前に知っておきたい挙動があります。
まず Memory の保持期間です。
ある利用者がそのエージェントを28日間使わなかった場合、その利用者の記憶は削除されます。
月に一度しか使わない業務では記憶が積み上がらない可能性があるため、Memory を前提にした体験設計をする際は利用頻度を考慮しておくと安心です。
次に、展開先による制限です。
グループ チャットや Microsoft Teams のチャネルでは、ユーザー メモリが無効化されます。
Teams のチャネルに配置してチーム全員に使ってもらう、という展開を想定しているなら、Memory を前提にした体験設計は成立しません。
個人とのチャットで使う場合との差になるため、展開先を決める段階で確認しておきたい点です。
次に、Memory をオフにしたときの挙動です。
オフにしても保存済みの記憶は削除されません。
エージェントがその記憶を使わなくなるだけです。
記憶そのものを消したい場合は、メモリ ポータルから削除する必要があります。
Skills については、前述の通り説明文の書き方が起動精度に直結します。
スキルが期待通りに呼び出されないときは、指示の中身よりも先に説明文を見直すのが近道です。
呼び出しの状況は、Preview タブでエージェントを動かしたときのアクティビティ トレースで確認できます。
よくある質問
Q. Memory をオフにすると、保存済みの記憶は削除されますか？
削除されません。
オフにするとエージェントがその記憶を使わなくなるだけで、保存済みのメモリは残ります。
すべて削除したい場合はメモリ ポータルから一括削除し、個別の削除や更新はチャットからエージェントに依頼します。
Q. スキルはどのような形式で用意すればよいですか？
スキル名と説明を YAML フロントマターに記述し、指示を Markdown で書いた .md ファイルを用意します。
スクリプトやテンプレート、参照ドキュメントなどの補助ファイルを含めたい場合は、SKILL.md を含む ZIP ファイルとしてアップロードします。
Q. Skills と Tools は何が違いますか？
Tools はコネクタや MCP サーバー、REST API など外部サービスへの接続を担います。
対して Skills は自己完結した指示とロジックで、外部への接続を伴いません。
公式ドキュメントは Skills を、エージェントが必要に応じて有効化できる「専門的な役割やモード」と説明しています。
まとめ
Skills と Memory は、それぞれ「どう振る舞うか」「何を覚えているか」を担うコンポーネントでした。
Skills は Markdown で書いて使い回せるため、組織内で品質の揃った指示を共有する土台になります。
Memory は、その利用者に固有で次回も役に立つ情報だけを拾ってくれます。
ナレッジから毎回引ける社内情報は対象外なので、誰にとっても同じ情報はナレッジ、その人に紐づく情報は Memory という切り分けで設計できます。
一方で28日の保持期間、Teams のチャネルでの無効化、オフ時の挙動など、運用設計で押さえておくべき点もあります。
特に Memory はプレビュー段階の機能ですので、まずは検証環境で実際に触れて、自社の業務に合うかどうかを確かめてみてください。
GitHub Copilot ハーネスの画面構成とエージェントの作り方については、こちらの記事でまとめています。
これらの機能を支えている GitHub Copilot ハーネスについては、こちらの記事でまとめています。
QESでは、Copilot エージェントのセキュリティ・ガバナンス設計から、PoC・本番構築、運用と継続改善までを一貫してご支援しています。
プロフェッショナル開発と市民開発のどちらにも対応していますので、以下のリンクからサービスの詳細をご確認ください。
※ 本ブログで参照されている、Microsoft、Microsoft Copilot Studio、Power Platform、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
※ その他の会社名、製品名は各社の登録商標または商標です。
