AI Skillは論文から作る？現場の判断から作る？材料の選び方と検証

日々の反復業務をAIに任せるためのパッケージである「Skill（スキル）」を作るとき、どのような手順を参考にすればよいか迷うことはありませんか。Skillの材料を選ぶときの結論は、「自分がその業務をどこまで知っているか」によって出発点を変えることです。

すでに何度も経験している業務であれば、現場の実務記録やAIへの修正履歴といった実際のデータが出発点になります。一方、これから新しく始める業務であれば、論文や公開されている方法論から始めるのが一つの方法です。AIが元々持っている一般的な知識だけに頼ると、曖昧な手順になりやすいためです。

この記事では、再利用する作業手順をSkillにまとめる際、研究データ、実務の例、AIの一般知識のどれを出発点にすべきかと、それらの手順が食い違った場合にどうやって確かめるかを解説します。自分の反復業務をAIに任せて効率化したい企業の担当者の方は、ぜひ参考にしてください。

Skillの材料は、業務をどこまで知っているかで選ぶ

AIに特定の業務を繰り返し実行させるための手順書であるSkillを作る際、AIが最初から持っている一般的な知識だけに頼るのは避けましょう。

Agent Skillsの公式指針でも、AIの一般知識のみで手順を作成すると、指示が曖昧になりやすいと説明されています。実務で使えるSkillにするためには、実際のタスクで行っている手順、過去の修正履歴、具体的な入力と出力の例、その業務ならではの固有条件などを材料にすることが推奨されています。

なお、Agent Skillsの仕様におけるAgent Skillsとは、AIへの指示やスクリプト、参照資料などをひとまとめにした再利用可能なパッケージのことです。具体的な作業手順やルールは、「SKILL.md」というファイルに記述して管理します。

では、具体的に何を材料にすればよいのでしょうか。それは、あなたがその業務を「すでに知っているか」「これから始めるか」によって異なります。

すでに経験がある業務は「現場の記録」から作る

あなたがすでに何度も行っている反復業務をSkillにする場合、材料になるのは「現場の記録」です。

過去にAIを使って業務を行った際の入力内容や、AIの出力に対して「ここは直してほしい」と伝えたフィードバックの履歴が、そのままSkillの材料になります。例えば、過去の入力とフィードバックからレビュー観点を抽出する方法のように、実際のやり取りや失敗履歴を分析することで、現場の実態に即した具体的な手順を作ることができます。

現場の記録を使うメリットは、あなたの会社や部署に特有の条件を最初からSkillに組み込める点です。「この用語は使わない」「このフォーマットで出力する」といった現場の判断を反映させることで、AIの出力へ固有条件を反映できます。

これから始める新しい業務は「公開情報」から作る

一方、これから新しく取り組む業務で、まだ現場の記録や経験がない場合は、論文や公開されている方法論を出発点にします。

ここで、一つの設計例を考えてみましょう。企業の新規事業担当者が、「経費精算の業務で何に困っているか」を社内でヒアリングするための質問票を作成するとします。この質問票作成をAIのSkillにしたい場合、まだ実施した記録がないため、現場のデータは使えません。

このような場面では、世の中で公開されている「効果的なヒアリングの手法」や「インタビュー設計の基本」といった方法論を材料にします。そこに、「今回は経費精算の課題を調べる」という具体的な目的を掛け合わせてSkillの土台を作ります。

ただし、材料を集める際には注意が必要です。社内の機密情報や、個人が特定できるような顧客情報は決してSkillに含めてはいけません。必ず、許可された匿名の記録や公開情報のみを使用するようにしてください。

現場の記録と公開情報を組み合わせる

Skillの材料選びにおいて、研究（公開情報）と経験（現場の記録）のどちらが常に優れているというわけではありません。

業務の知識が豊富な場合は現場の記録から、知識が少ない場合は公開情報からスタートし、両者を組み合わせる場合も、対象と目的に合うかの確認が必要です。AIの一般知識や公開情報で全体の枠組みを作り、現場の記録で細かな条件や修正点を補うことで、あなたの業務への適用を試すSkillの候補ができます。

論文と現場の手順は、出所と条件を残して比べる

AIへの指示や手順をまとめたSkillを作る際、論文や公開されている方法論、現場の過去の判断、そしてAI自身が持っている一般的な知識などを集めていくと、それぞれが推奨する手順が食い違うことがあります。このような場面での結論は、どれか一つを絶対の正解と決めるのではなく、「その手順がどこから来たのか（出所）」と「どのような前提で使われるものか（条件）」をSkillの中に書き残し、比較できるようにすることです。

なぜ出所と条件を残す必要があるのか

複数の資料や経験を混ぜ合わせて手順を作ると、「なぜこの作業をするのか」という理由が曖昧になりがちです。

たとえば、AIに「良い質問票を作って」とだけ指示すると、AIは一般的な知識に基づき「システムの満足度を5段階で評価してもらう質問」を提案してくるかもしれません。しかし、調査の目的によっては、その形式がまったく適していない場合もあります。後からSkillを修正しようとしたとき、手順の出所が書かれていないと「これはAIが勝手に想定したのか、誰かが意図して追加したルールなのか」が区別できなくなってしまいます。

そのため、Skillのファイルには「この手順はどの資料を参考にしたか」「どんな状況を想定したルールか」を明記することが重要です。

論文と実務ガイドの前提を読み解く

情報を比較するためには、まずその資料が作られた前提条件を確認します。インタビューによる調査手法を例に見てみましょう。

医療分野のインタビュー手法をまとめた論文（DeJonckheereら, 2019年）では、開かれた中立で明瞭な質問を用意し、相手の回答に応じて追加で質問を深掘りすることや、事前に質問ガイドをテストして更新する手順が推奨されています。この方法は非常に体系的ですが、前提として「家庭医療やプライマリケアの調査」を目的としたものであり、AIの活用効果や企業の事業成果をテストした研究ではないことに注意が必要です。

同様に、公共サービスを改善するためのイギリス政府（GOV.UK）の利用者調査の指針では、調査したい話題や導入の質問を用意しつつも、「実際の話と具体例に焦点を置き、ガイドを硬直的に守らない」という柔軟な姿勢が求められています。さらに、チームが調べたい「問い」と、参加者にそのまま尋ねる「質問」は別であると明確に区別しています。

このように、家庭医療を対象とした論文と、公共サービスの利用者調査を目的とした実務ガイドとでは、対象と前提条件が異なります。

経費精算の設計例で食い違いを整理する

では、前の項目で挙げた「経費精算の課題をヒアリングする質問票」をAIに作らせるSkillの設計例で考えてみましょう（これは特定の企業の実例ではなく、考え方を説明するための編集上の例です）。

このSkillの材料として、「論文の手順」「イギリス政府の指針」に加え、「自社の担当者が過去に行った判断（例：部署によって経費の使い方が違うため、最初に所属を必ず聞く）」、そして「AIの一般的な提案（例：使い勝手を5段階で評価させる）」が集まったとします。

ここで手順の食い違いが発生します。AIは「5段階評価」を提案していますが、イギリス政府の指針では「実際の話と具体例に焦点を置く」とされています。また、調べたい問いと、参加者へ尋ねる質問を区別するという指針もあります。

これらをSkillのファイル（SKILL.mdなど）にまとめる際は、以下のように由来と条件をセットで残し、照合できるようにします。

• ルールA：チームが調べたい問いを、そのまま相手への質問にしない。相手の実際の経験を聞き出す質問に変換すること。（由来：上記のGOV.UKの指針 / 条件：今回のインタビュー設計）
• ルールB：単純な評価ではなく、相手の回答に応じて深掘りできる開かれた質問を基本とする。（由来：上記のDeJonckheereらの論文 / 条件：課題の背景を深く探りたい場合）
• ルールC：質問の冒頭で必ず所属部署を尋ねる。（由来：担当者の過去の判断 / 条件：自社の経費精算ヒアリング時のみ）

このように出所と条件を並べて記録しておくことで、複数の材料が持つ知見を整理でき、現場の事情にも合ったSkillの土台を作ることができます。どれを採用すべきか迷った場合は、次のステップとして実際に試してみることが有効です。

同じ課題で試し、食い違いを次のSkillへ戻す

公開情報や現場の経験、そしてAIの一般知識など、複数の材料からSkillの土台となるルールを集めると、推奨される手順に食い違いが生まれることがあります。出所と条件を整理した後は、どのルールを採用すべきかを実際に動かして検証する段階に入ります。

結論から言えば、比較するための入力と環境をそろえて試し、出てきた成果物を人間が原典と照らし合わせて採否を決めることが重要です。AIの自動評価だけに頼るのではなく、結果の食い違いを分析し、判断しきれない部分は人間が業務条件を見直してSkillの更新へとつなげます。ここでは、検証の具体的な手順と、Skillを育てていく方法を解説します。

比較するための入力と環境をそろえる

Skillの精度を確かめるには、Agent Skillsの公式評価ガイドで推奨されているように、現実的な課題と期待する成果、そして具体的な入力を用意します。

検証の基本は、同じ課題に対して「Skillを使わない場合と使う場合」や「旧版のSkillと新版のSkill」を比べることです。過去のやり取りの影響を排除するため、制作会話や過去の情報を引き継がない独立した文脈で実行します。また、AIモデル、参照する資料や道具、調査の対象と目的といった条件もそろえて比較する設計が基本です。

AnthropicのSkill作成者向け説明でも、出力がどの版から生成されたものかを伏せて評価する方法や、独立した文脈での実行、そして処理にかかった時間やトークン数（AIが文章を処理する際の単位数）の記録を残すことが紹介されています。

成果物と原典を読んで採否を決める

同じ条件で出力された結果がそろったら、成果物を評価します。評価は、指定したファイル形式になっているかといった「機械的な確認」と、文体や実際の使い勝手といった「人による確認」に分けて行います。最終的な判断は、単なる合格率だけでなく、実際の成果物の質や実行時の無駄、課題ごとに生じる差を読み取って結びつけます。

前節で挙げた「経費精算の課題をヒアリングする質問票」の架空の設計例で考えてみましょう。この質問票の比較検証は未実施の設計であるため、実際の得点や改善率といった実測値はありませんが、同じ調査目的と入力で比較する設計を想定します。

たとえば、AIが「使い勝手を5段階で教えてください」という質問を出力したとします。第2節で紹介したイギリス政府の指針は5段階評価自体を禁止しているわけではありませんが、実際の経験を掘り下げるという目的においては適さない場合があります。人間は、出所不明な質問や誘導的な質問が含まれていないかを原文と照合します。そのうえで、今回の調査目的や材料の適用条件に合っているかを人間が判断し、採否を決めます。

確認できない場合の行動とSkill更新

比較検証を行っても、出所不明な質問が残ったり、原典の手順と自社の採用条件の食い違いが解消されなかったりすることがあります。このような場合、比較によって得られた「得点」だけで業務への採否を確定させることはできません。

得点だけで判断できないときは、無理にAIの枠内で完結させず、参考資料や業務条件そのものを人が改めて確かめる段階へ進みます。出力結果に差が出たという事実は、原因と自社への適否を調べるための重要な材料になります。

人間が資料や条件を再確認し、「やはりこの現場ルールは必須だ」「この論文の前提は自社の業務には合わない」といった判断を下したら、その結果をSkillへと戻します。比較と確認を経て採用条件を明確にし、SKILL.mdなどのファイルを更新していくことで、日々の反復業務に真に役立つSkillへと改善されていくのです。

よくある質問

Q1. 現場の記録がない新しい業務をSkillにする場合、どのような公開情報を探せばよいですか？

業務の目的に近い、公的機関の実務ガイドや学術論文を探すのがおすすめです。たとえば、ヒアリングの設計であれば、イギリス政府（GOV.UK）の利用者調査の指針や、体系的な手順がまとめられた医療分野のインタビュー論文などが材料になります。ただし、これらはAI向けの指示として作られたものではないため、そのまま使うのではなく「どのような前提や条件で作られたか」を確認し、自社の目的に合わせて調整することが大切です。

Q2. 過去の業務記録を材料にするとき、Skillに入れてはいけないものはありますか？

はい。社内の機密情報や、個人の特定につながる顧客データなどは、絶対にSkillの手順や具体例として含めないでください。現場の記録をAIの入力例や改善案の材料として使う場合は、必ずルールに従って許可された、匿名の記録だけを使用するようにします。

Q3. テストで複数のSkillを比較する際、最も注意すべきことは何ですか？

制作会話や過去の情報を引き継がない独立した文脈でテストを実行することです。AnthropicのSkill作成ガイドでも説明されている通り、過去のやり取りが試行の入力に残った状態でテストをすると、純粋なSkillの実力を比べることができません。Skillを使わない場合と使う場合、あるいは古い版と新しい版を比べる際には、毎回まっさらな環境を用意して同じ課題を与えてください。

Q4. 出力結果の良し悪しは、AIにすべて自動で採点させてもよいですか？

いいえ。機械的に確認できる部分と、人が中身を読んで判断すべき部分を分けることが重要です。Agent Skillsの公式評価ガイドでも、指定したファイル形式になっているかといった基準は機械的に確認できるとされています。しかし、文体が適切か、実務の使い勝手はどうか、質問が相手を誘導していないかといった品質の確認は、人が成果物とルールを照らし合わせて判断する必要があります。