AIスキルが、実際の依頼で本当に期待通りの役割を果たしたかを確認したい場面があります。利用者がAIに「今回の仕事でスキルを使いましたか」と質問し、AIが「使いました」と答えたとします。しかし、その返答だけでは証拠として不十分です。スキルが単に候補として選ばれただけなのか、作業の手順を読み込んだのか、それとも必須の確認まで全て終えたのかが分からないからです。
作業の実態を確かめるには、システムの記録を三つの段階に分けて確認します。一つ目は、依頼内容に合わせて対象のスキルが選ばれた記録です。二つ目は、実行時にスキルの定義や必要な資料を読み込んだ記録です。
三つ目は、指定されたツールの呼び出しやデータの検証、成果物の更新といった必須の作業を終えた記録です。この三つの記録を同じ実行IDで結びつけます。各段階の開始、終了、失敗を漏れなく残せば、後から作業がどこまで進んだかをたどれます。
この記事では、商品説明の公開前チェックを例にしながら、何をログに残すべきかを具体的に考えます。さらに、作業を自動選択に任せる場面と明確に指定して呼び出す場面の分け方や、選択から漏れてしまった記録をどう改善に生かすかについても整理します。AIスキルが実際の依頼で役割を果たしたかを、モデルの自己申告ではなくどう確認すればよいでしょうか。
「使われた」という返答だけでは確認にならない
利用者がAIに「今回の依頼で確認スキルは使われましたか」と質問し、AIが「使いました」と答えても、その返答を業務が完了した証拠にしてはいけません。AIの回答は、モデル自身が生成した自己申告にすぎないからです。AIの返答だけでは、どのルールを読み込み、どの確認を実行し、どの成果物を更新したのかという過程を後から再現できません。
たとえば、商品説明の公開前検査をAIスキルに任せるとします。この作業では、根拠となるURLを照合し、禁止表現を確かめ、判定結果を保存する工程が必要です。
もしAIが「すべて確認しました」と報告しても、各工程の成功または失敗を示す記録がなければ、担当者はどこをやり直すべきか判断できません。そのため、AIの自己申告は補助的な情報にとどめ、必ずシステムの実行記録を確かめます。
AnthropicのAgent Skillsでは、自動選択と定義の読み込みを分けて確認する必要があります。最初からすべての定義を読むのではなく、まずスキルの名前や説明文が候補の選定に使われるためです。
ほかの実行環境では、選択と読み込みの記録方法を個別に確認します。利用者の依頼内容とスキルの説明文が合っていた事実だけを見て、必須の作業工程まで完了したと推測してはいけません。
AIスキルが確実に役割を果たしたと判断するには、「使われたか」という一つの結果で終わらせず、実行時の詳細な記録を追う必要があります。どのような記録を確かめればよいのか、具体的な内容を整理します。
確認する証拠は選択・定義読込・必須工程の3つです
システムの実行記録を確認するときは、対象を三つの層に分けます。こうする理由は、作業が失敗したときに、原因がスキルの「選択」「読み込み」「実行」のどこにあったのかを突き止めるためです。スキルが候補に挙がったか、実行に必要なルールを読み込んだか、そして決められた仕事を最後まで終えたかという順番で記録を確かめます。
一つ目の証拠は、選択の記録です。ここには、匿名化した依頼の番号、候補になったスキルのID、選ばれた時刻、選択の判断に使われた説明文のバージョンを残します。この記録は、利用者の依頼とスキルの目的がずれていなかったかを後から確かめるためのものです。自動選択に任せた場合、ここでスキルが選ばれていなければ、その後の読み込みや実行には進みません。
二つ目の証拠は、定義の読み込み記録です。スキルは、AIへの指示やプログラム、参考資料などをまとめたパッケージとして扱われます。
記録には、どのファイルをいつ読み込み始め、どういう結果になったかを残します。システムによって資料をどこまで読み込むかは異なるため、一般的な仕組みの説明をそのまま自分の環境に当てはめないことが大切です。
三つ目の証拠は、必須工程の完了記録です。ここでは、必要なツールの呼び出しと作業の開始・終了時刻を残します。実行結果やエラーの理由、更新した成果物のハッシュも記録します。ログの仕組みを使えば、AIによる文章の生成やツールの実行といった過程を実行記録に含めることができます。
ただし、ログを記録する機能があるだけでは、業務が正しく終わったという保証にはなりません。ログを見て完了を確かめるには、スキルを作る側が「どんな記録がそろえば作業完了とするか」をあらかじめ決めておく必要があります。
公開前チェックを例に、ログを同じ実行IDで結びます
商品説明を公開する前の確認作業を例に、実際の記録に何を残すかを見ていきます。最初の準備として、一回の処理ごとに実行IDを発行し、すべての作業記録をこのIDで結びつけます。依頼には匿名化した識別子を付けます。選択理由の検証に必要な依頼文は、個人情報や機密情報を削除したうえで、閲覧権限を制限して別に保存します。
次に、スキルの選択と指示の読み込みに関する記録を実行IDに追加します。対象のスキルが選ばれた時刻や、使われた説明文のバージョンを記録します。続いて、必要なファイルや参考資料を読み込んだイベントも残します。必要なファイルとバージョンが一致し、読み込み結果が成功になっていれば、確認作業を始める準備が完了したと判断できます。
さらに、根拠となるURLの照合や表現の検査といった実際の作業工程を記録します。それぞれの作業について、開始と終了の時刻、そして結果を実行IDに紐付けます。
GitHub Copilot SDKには、ツール実行後に処理を追加するhookがあります。公開前チェックへ応用する場合は、各検証の結果をhookなどで記録します。
必須項目の成功記録がそろわなければ公開処理を止める制御は、別途実装します。
最後に、判定結果と実行記録を対応付けるため、成果物のハッシュを実行IDの記録に加えます。すべての記録を一つの実行IDでつなげておけば、後から問題が見つかったときに、スキルの選択漏れと実行途中の失敗を切り分けやすくなります。このように記録を残す仕組みを整えたうえで、次は作業をAIの自動選択に任せるか、それとも明確に指定して呼び出すかを判断していきます。
自動選択に任せる場面と明示呼出しにする場面を分けます
利用者の依頼文とスキルの説明文の対応は、AIがスキルを自動選択するときの主要な判断材料の一つです。実際の選択条件は、実行環境ごとに確認します。そのため、大まかな指示から関連する補助作業を見つけ出す用途に向いています。しかし、公開の条件となるような重要な作業を任せるときは、AIが自ら候補に挙げるのを待つだけでは不十分です。
作業が実行されなかったときの影響が大きい工程では、自動選択から明示的な呼び出しへ切り替えます。具体的には、外部への公開や、顧客へ渡す資料の作成などです。このような場面では、利用者やシステムが必須のスキルを直接指定して実行させます。作業が漏れたとき、最終的な文章を作り直すだけで済まない業務が切り替えの目安です。
このように扱いを分けるのは、自動選択の仕組みが不要になるという意味ではありません。今回必ず実行する検査と、自動で選ばれる精度を観測して改善していく対象を分けるためです。実行記録を確かめた結果、自動選択から外れてしまった入力が見つかった場合は、その記録を次の改善に生かします。
自動選択から漏れた入力を説明文と回帰テストへ戻します
AIによる自動選択から漏れてしまった入力は、単なる失敗として消してはいけません。どのような依頼の言葉に対して、どのスキルが選ばれるべきだったのかを匿名化して記録に残します。この記録は、スキルの自動選択の精度を上げるための貴重なテストケースになります。
選択漏れを防ぐために直すのは、スキルの名称や、どのような場面で使うかを示した説明文です。起動のきっかけとなる具体的な依頼文の例も修正の候補になります。スキルの動作を確かめる際に、利用者の実際の入力を使ってテストすることは、公式のガイドでも推奨されています。
ただし、スキルの説明文に語句を足しただけでは、正しく選ばれるようになったと断定できません。説明を書き換えた後は、過去に選択漏れを起こした入力と、選ばれてはいけない似た入力を集めて再試験を行います。こうすることで、期待した入力でスキルが選ばれるようになったかだけでなく、関係のない入力で誤って選ばれないかも同時に確かめられます。
一連の運用で蓄積していくのは、AIの働きに対する曖昧な印象ではありません。実行IDに結びついた具体的な観測結果です。スキルの選択、定義の読み込み、必須工程の完了という三つの証拠を区別して残すことで、自動選択を改善しながら、必須工程の未実行や失敗を検出できます。
よくある質問
Q1. AIが「スキルを使った」と答えれば確認できますか？
確認できません。AIの自己申告は、モデル自身が生成した結果報告にすぎないからです。本当に使われたかを確かめるには、スキルの選択、定義の読み込み、必須工程の完了という三つの段階がシステムの実行記録に残っているかを別々に確認します。
Q2. 選択記録には何を残しますか？
選択記録には、情報を守るために匿名化した依頼の識別子を残します。さらに、候補に挙がったスキルや選ばれたスキルのID、スキルのバージョン、選択された時刻、そして判断に使われた説明文のバージョンを記録します。
Q3. 定義を読んだ記録だけでは不十分ですか？
不十分です。スキルの説明やルールを読み込んだだけでは、決められた作業を最後までやり遂げた証明にはなりません。根拠の確認や表現の検査、成果物の更新といった、そのスキルが必ず行うべき工程の開始時刻、終了時刻、そして実行結果まで確認する必要があります。
Q4. run IDはなぜ必要ですか？
作業が失敗した原因を後からたどるためです。スキルの選択から最終的な成果物の状態までを、一連の処理として結びつけます。そのために、実行IDやtrace ID、相関IDなどの共通識別子を使います。
Q5. いつ明示呼出しにすべきですか？
作業漏れの影響が大きい場合は、スキルを明示的に呼び出します。そのうえで、選択または起動、定義の読み込み、必須工程の完了記録を確認します。具体的には、情報の公開可否を決める場面、契約や規制に関わる対応、顧客に直接渡す資料の作成などです。
Q6. 自動選択されなかった入力はどう扱いますか？
選択から漏れてしまった利用者の入力は、匿名化したうえでテスト用の記録に加えます。この記録を使って、スキルの説明文や起動のきっかけとなる例文を修正します。修正後は、期待した入力で選ばれるようになったかだけでなく、関係のない入力で誤って選ばれないかも確かめます。
調査手法について
こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。
Screenshot
調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。
また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。
ご利用をご希望の方は、こちらよりお申し込みください。
また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
コメント