AIスキルとは、AIツールが繰り返し使える指示のまとまりです。チームにとっての価値は、良い指示を一度書くことだけでは決まりません。修正がそのスキルを使う全員に届く必要があります。実用的な構成は、編集用の版をNotionに置き、GitHubを通じて配布し、更新した指示をClaude Codeなどのツールで使えるようにするものです。

チームで編集する場所を一つにする

ある人が個人のチャットの中でワークフローを改善しても、同僚は古い版を使い続けるかもしれません。その修正はチームの作業指示にならず、会話とともに消えてしまうおそれがあります。Notionの共有スキルデータベースがあれば、スタッフは同じページを確認し、コメントし、修正できます。エージェントもNotion MCPを通じてこれらのページを扱えます。Notion MCPは、AIツールがNotionのコンテンツにアクセスするための接続です。

この役割分担は、GitHubでファイルを管理しない人にとって重要です。ライターやプロデューサーは使い慣れたページを編集し、ファイルの配布はGitHubが裏側で担います。また、スキルをAIツールの設定担当者に任せきりにせず、実際の業務を担う人を編集の過程に加えることにもなります。

整理された参考資料の横で、複数の手が共有ボード上の白紙の指示カードを並べ替えている様子。

▲ スキルの共同編集

ページのスキルを共有ツールに届ける

基本的な構成は、スキルの目標、必要な入力、ルール、作業手順を記したNotionページから始まります。チームはページ設定で「Use with AI」、続いて「Use as AI skill」を選び、そのページを中央のスキルデータベースに置きます。

そのスキルをNotionからチームのツールに届けるには三つの段階があり、最初の段階はテスト専用です。

  1. 手早く試すにはローカルにインストールします。 コマンドnpx skills@latest add notion --globalは、利用できるNotionのスキルを見つけ、Claude Codeを含む対応ツールへのインストールを提案します。シンボリックリンク(symlink)を使うと、ローカルの各ツールが別々のコピーを持たずに同じインストール済みファイルを参照できます。その後、Claude Codeでは/skillsで登録済みのスキルを一覧表示できます。
  2. チームで使うにはリポジトリ同期を設定します。 ローカルインストールだけではスナップショットにすぎず、Notionページを変更しても新しい内容は自動では取り込まれません。共有構成では、スケジュール実行のGitHub Action(リポジトリで動く自動化ジョブ)がNotionのスキルデータベースを読み込み、各スキルをGitHubのSKILL.mdファイルに書き出します。
  3. リポジトリのスキルをClaudeにインストールします。 リポジトリはClaudeのPluginsのマーケットプレイスから追加でき、チームメンバーは個々のスキルをインストールできます。リポジトリが更新されると、プラグインマネージャーは自動で更新できます。テスト中に同期したばかりの版を取り込むには「Check for updates」を使えます。

このスキルライブラリの構成では、GitHub Actionが1時間ごとにNotionを確認します。同期に使うNotionの接続には対象のSkillsデータベースへの読み取り権限を与え、そのトークンはリポジトリ内のファイルではなくGitHub ActionsのシークレットにNOTION_API_TOKENとして保存します。編集は引き続きNotionで行う作業です。ここでの区別は重要です。シンボリックリンクはローカルのインストールをまとめるものですが、後のページ修正を共有リポジトリに運ぶのはNotionからGitHubへのパイプラインです。

最初のメール文面のテストでは、Claude Codeが登録済みのスキルを見つけ、Notionからキャンペーンの情報を取得し、三つの草案をプロジェクトのデータベースに書き込みました。この実行には9分23秒かかりました。これは一つのタスクが完了したことを示すもので、速度や出力品質の一般的な目安ではありません。

実際の業務から指示を改善する

ある映像制作会社は、この方法を二つのワークフローに適用しました。台本の執筆と、プロデューサーと顧客とのやり取りです。最初のスキルは、リードプロデューサーへの約45分のインタビュー2回と、その書き起こし、標準業務手順、承認済みの参考台本をもとに作られました。インタビューからは、汎用の指示テンプレートでは見落としがちな点が浮かび上がりました。執筆前にライターが必要とする情報、ブリーフの保管場所、資料どうしが食い違うときの扱い方、若手ライターがよく犯すミスです。

スキル作成用のエージェントがNotion AI上で最初の台本執筆スキルを組み立て、構成のルールと、出力を正しいNotionデータベースに置くための指示を盛り込みました。チームはその後、別のプロジェクトで試し、コンセプトと草案がスキルの要件を満たすか、存在しない素材に言及していないかを確認しました。この創作作業での目標は、台本の最初の15〜20%を役立つ形で用意することであり、ライターの判断を経ない完成品ではありませんでした。

フィードバックの循環は、後の草案レビューでより明確になりました。スキル編集用のエージェントがNotionの指示を更新し、新しいコンセプトを提案する前にプロジェクトの現状と過去のフィードバックを確認するよう求める手順を加えました。1時間ごとのGitHubのジョブが、変更された指示をリポジトリに反映しました。プラグインを更新した後、別のチャットでの実行は追加された確認手順に従いました。一回の草案レビューから始まった修正が、共有スキルの一部になったのです。

修正された指示がフォルダーを通って複数のワークステーションへ届く中、レビュー担当者が白紙の草案カードを調整している様子。

▲ 共有スキルを通じたフィードバックの流れ

別のコーチング事業の導入例では、同じ仕組みをより速く回していました。そのワークスペースには、文面、スライド資料、キャンペーンなどを担う専門エージェントが9つありました。事業主はNotionで運用指示を修正でき、GitHub Actionが5分ごとに変更を確認し、リポジトリへの新しいコミットをきっかけに再ビルドと再デプロイが行われました。この5分ごとの確認はこの導入例のもので、スキルライブラリの例の1時間ごとのスケジュールとは別です。

ビジネス事例が示すこと、示さないこと

この映像制作会社は、二つの共有スキルを対象とする初期導入に$1,000を支払いました。これはこの事例の価格であり、ほかのチームが特定の金額を稼いだり節約したりできる根拠ではありません。むしろ参考になるのはパイロットの範囲かもしれません。チームの業務の仕組み全体を一度に置き換えるのではなく、手間の多い既存の二つのワークフローに絞っていました。

人が確認できるワークフローから始める

入力が明確で、修正が頻繁に入るタスクを一つか二つ選びます。その業務を担う人に話を聞き、ルールと参考資料をNotionの共有スキルにまとめ、最初の版をその実務者に確認してもらいます。実際のプロジェクト資料で試し、出力に足りなかった点を記録して、中央のページを修正します。複数の人やツールがそのスキルを必要とするなら、修正がチームに届いたと考える前に、GitHubの同期とインストール済みの版の両方を確認します。