Notion SkillをSKILL.mdへ手作業で移す対応表とチェックリスト

Notion Skillのタイトル、本文、ページ上の雛形を人が読み、Agent Skills仕様のSKILL.mdと任意ディレクトリへ割り当てる対応表です。実移行デモではなく、起動時の暗黙入力を明文化する判断、架空の完成例、目視チェックまでを示します。

公開資料で確定できるNotion Skill

Notionの公開Helpで確認できるSkillは、指示を本文に書き、通常のページと同様に共有できるページです。BusinessとEnterpriseが対象で、Notion Agentは関連する依頼でSkillを自動的に利用できると説明されています。Helpとリリース記事では管理画面の表記が異なるため、本稿はUIの再現手順ではなく「共有可能なページ」という性質だけを前提にします。

自動利用にはdescriptionが必要で、Notion Helpではskills databaseにあるSkillだけがdescriptionを持つと説明されています。単独ページを元にする場合、移行元の用途説明が存在しない可能性があるため、本文の手順から「何をするか」「いつ使うか」を人が起こします。

Notionでは選択したテキストやブロックに対してSkillを起動でき、slash menuは内容のある行で表示されると説明されています。つまり元の指示が「選択中の内容」を暗黙の入力にしている可能性があります。Agent Skills仕様はmetadataから本文、必要な参照ファイルへ進む読み込み順を定めますが、選択範囲などの入力受け渡しは規定していません。そこで本稿では入力が自動で渡る前提を置かず、元ページの実行対象を「利用者が渡す入力」としてSKILL.mdへ明記します。

本稿の出典3件には、Notion SkillをAgent Skills形式で書き出す機能の記述がありません。そこで画面で読める本文とページ内要素を出発点にし、Agent Skills仕様へ手作業で割り当てます。

NotionページとAgent Skillsファイルの対応表

Agent Skills仕様ではディレクトリ直下のSKILL.mdが必須で、scripts/、references/、assets/は必要な場合だけ置きます。Notionの要素から配置先を機械的に決めるのではなく、用途を読んで次の候補へ分けます。

• ページタイトル：手動設計時の候補：frontmatterのname候補／人が判断する基準：日本語をそのまま転記せず、用途を英小文字とハイフンで短く表す

• 用途説明：手動設計時の候補：frontmatterのdescription／人が判断する基準：説明があれば具体化し、単独ページなど説明がなければ本文から「何を」「いつ」を起こす

• 選択テキスト・実行対象ブロックという暗黙の入力：手動設計時の候補：SKILL.mdの入力定義／人が判断する基準：元ページが何に対して走るかを読み取り、利用者が渡す入力として明示する

• 本文の指示：手動設計時の候補：SKILL.md本文／人が判断する基準：目的、入力、手順、出力を分け、元ページにない条件を追加しない

• 実行可能なコード：手動設計時の候補：scripts/候補／人が判断する基準：実際に実行するコードだけ。コードがなければ作らない

• 補足文書：手動設計時の候補：references/候補／人が判断する基準：エージェントが作業中に読む根拠・仕様・長い例

• ページ内の出力テンプレートや素材：手動設計時の候補：assets/候補／人が判断する基準：生成物へ再利用する雛形・画像・リソース

• ページの共有設定：手動設計時の候補：移さない／人が判断する基準：ファイルへ自動移行する根拠はないため、配布先のリポジトリまたは共有ディレクトリで別途設定する

Agent Skills仕様のprogressive disclosureでは、metadataを先に読み、SKILL.md本文はSkill選択後、参照ファイルは必要時に読みます。したがって毎回必要な目的・入力・短い手順は本文に残し、条件付き規約、長い例、用語集はreferences/へ分け、本文からファイル名で参照します。会議メモ例なら抽出手順は本文、部署別の長い出力例はreferences/output-examples.mdです。

次のNotion固有構造が元ページにあると仮定した場合、本稿では次の運用判断を使います。これは仕様・Helpに規定された自動変換ではなく、架空例に対する筆者の手動設計です。

• トグル：変換前の例：「出力形式」内に箇条書き／変換後の候補：## 出力形式と通常の箇条書きへ展開

• データベースビュー：変換前の例：列＝担当者・期限・状態／変換後の候補：必要列だけをreferences/action-fields.mdの表へ分離

• 子ページ：変換前の例：「部署別の例」／変換後の候補：references/department-examples.mdへ分離し本文から参照

• 同期ブロック：変換前の例：共通ポリシー／変換後の候補：複製時点の本文か正本リンクかを人が選び、更新方法を明記

• コールアウト：変換前の例：注意事項／変換後の候補：Markdownの注意書きへ変換

• 埋め込み：変換前の例：外部資料／変換後の候補：URLリンクを残し、取得できない内容は補完しない

name・descriptionを設計する具体例

仕様上、nameは1〜64文字で、小文字英数字とハイフンだけを使い、先頭・末尾のハイフンと連続ハイフンを避け、親ディレクトリ名と一致させます。日本語タイトルから意味を保って短くします。

2語以内を基本にし、原則は「対象＋成果物」、動作が対象語から自明でない場合だけ「対象＋動作」にします。

• 会議メモ整理：name例：meeting-notes／判断：対象＋成果物。整理は用途から自明なので動作語を省く

• 採用面談レビュー：name例：interview-review／判断：対象＋動作。面談だけではレビュー用途が自明でない

• 月次レポート作成：name例：monthly-report／判断：対象の限定語＋成果物。作成は自明なので省く

descriptionは1〜1024文字で、「何をするか」と「いつ使うか」の両方を含めます。仕様は関連タスクの識別を助ける具体的なキーワードも推奨しており、Notion側でも関連依頼に応じた自動利用が説明されています。無関係な検索語を足すのではなく、元ページにある用途の語を具体化します。

• 会議メモを整理する：会議メモから決定事項、担当者、期限付きアクションを抽出する。議事録の整理、アクション洗い出し、リキャップ作成を依頼されたときに使う。

• 面談内容をまとめる：採用面談の記録を評価観点別に整理し、確認が必要な根拠を示す。面談レビュー、候補者評価、採用記録の整理を依頼されたときに使う。

動作の言い換えを「いつ」として繰り返さず、後半には利用者が実際に使う依頼語を置きます。

仕様を満たすSKILL.md記述例

架空入力を次の内容まで明示します。

• タイトル：会議メモ整理

• 本文：選択したブロックの内容から決定事項、担当者、期限付きアクションを抽出し、情報がない項目は未記載とする

• 用途説明：議事録の整理、アクション洗い出し、リキャップ作成に使う

• 子ページ「部署別の出力例」：営業部では顧客への連絡アクションを決定事項の直後へ置き、元メモにない顧客名・担当者・期限を補完しない

• ページ内の「議事録レポートの雛形」：4見出しの順序、各アクションの担当者・期限の記入欄、欠損時の「未記載」表記を持つ

元の「選択したブロック」はNotion上の暗黙入力です。移行後は「利用者が渡した会議メモだけを使う」と明示入力へ書き換えます。毎回必要な手順は本文、条件付きの部署別例はreferences/、再利用する雛形はassets/へ分けます。

meeting-notes/
├── SKILL.md
├── references/
│   └── department-examples.md
└── assets/
    └── recap-template.md

---
name: meeting-notes
description: 会議メモから決定事項、担当者、期限付きアクションを抽出する。議事録の整理、アクション洗い出し、リキャップ作成を依頼されたときに使う。
metadata:
  notion-source-url: https://example.com/notion-skill-page
---

## 目的
会議メモを、決定事項と実行可能なアクションへ整理する。

## 入力として扱う内容
利用者が渡した会議メモだけを使う。本文に担当者または期限がない場合は推測せず、該当項目を未記載とする。

## 実行手順
1. 決定済みの事項を抽出する。
2. アクション、担当者、期限を対応づける。
3. 根拠となる元メモの記述を確認する。
4. 指定の出力へ整える。
5. 部署別の書き分けが必要な場合だけ`references/department-examples.md`を参照する。
6. 出力は`assets/recap-template.md`の見出し構成に合わせる。

## 出力する項目
出力書式は`assets/recap-template.md`に従う。

H1は置かず##で統一しています（仕様の必須条件ではありません）。

references/department-examples.mdの最小内容は、条件付きの長い例を本文から分離するためのものです。

## 営業部向け
- 決定事項の直後に、顧客への連絡アクションを並べる。
- 元メモにない顧客名、担当者、期限は補完しない。

assets/recap-template.mdは生成物へ毎回コピーする実体なので、本文と別に管理します。

## 決定事項
- {{決定内容}}
## アクション
- {{アクション}}
  - 担当者: {{氏名または未記載}}
  - 期限: {{日付または未記載}}
## 担当者
上の各アクション内に記載する。
## 期限
上の各アクション内に記載する。

notion-source-urlは実在URLではないプレースホルダーです。metadataのキーは他クライアントとの衝突を避けるため固有にします。更新日が入力にある場合だけ版情報をmetadataへ追加します。compatibility、allowed-tools、licenseはいずれも仕様上は任意で、この架空入力には対応情報がないため記載しません。allowed-toolsは実装間で対応が異なる実験的項目です。

公開前の静的チェックリストと合格条件

目視で判定する静的チェックリスト

手作業で作った後は、まず次を1行ずつ静的に判定します。

• [ ] ディレクトリ直下にSKILL.mdがある

• [ ] YAML frontmatterがファイル先頭にある

• [ ] nameが1〜64文字で小文字英数字とハイフンだけである

• [ ] nameの先頭・末尾、連続位置にハイフンがない

• [ ] nameと親ディレクトリ名が一致する

• [ ] descriptionが1〜1024文字で「何を」と「いつ」を含む

• [ ] descriptionがない元ページでは、本文から起こした用途説明を記録した

• [ ] 本文に元ページにない業務条件を追加していない

• [ ] 元ページの暗黙入力を、利用者が渡す入力として本文に明記した

• [ ] ページ内の要素を実行コード、補足文書、出力素材、移さない要素へ分類した

• [ ] 本文からreferences/やassets/への参照先が存在する

• [ ] 毎回不要な長い例・条件付き規約をreferences/へ出し、本文からファイル名で参照している

• [ ] 配布先（リポジトリまたは共有ディレクトリ）の閲覧権限を決め、記録した

• [ ] 代表入力に対する期待出力を定義した

• [ ] 入力に担当者または期限がない場合の出力を「未記載」と本文に明記した

利用クライアントで確かめる動作条件と合格条件

この確認は、利用中のクライアントがAgent Skills形式を読み込める場合に実施します。本稿の出典では各クライアントの対応可否を確認できません。

代表入力は「決定：来週公開。田中さんが告知文を作る。期限の記載なし」です。合格条件は、決定事項＝「来週公開」、アクション＝「告知文を作る」、担当者＝「田中さん」、期限＝「未記載」と一致することです。

利用するクライアントでは、(1)Skillが一覧に出る、(2)議事録整理の依頼で選ばれる、(3)期限の未記載ルールを守る、の3点を観察します。

まず自分のSkillを1つ選ぶ

書き出し機能を待たなくても、対応表とチェックリストで手作業の配置は決められます。

1. 元ページの要素を対応表へ置く

2. nameとdescriptionを決める

3. SKILL.mdと必要な任意ファイルを作る

4. 静的チェックリストを埋める

descriptionがない場合は、手順2で本文から「何を」「いつ」を起こします。

弊社では、AI社員の導入支援や企業のAX推進支援を行っています。人員を増やさず、今の体制のまま生産性と売上を伸ばしたい法人のご担当者様は、下記のボタンからお気軽にお問い合わせください。

出典

• https://www.notion.com/help/create-and-manage-skills

• https://www.notion.com/en-gb/releases/2026-03-20

• https://agentskills.io/specification