【ITニュース解説】Anatomy of a skill

ITの分野では、人工知能（AI）が特定の高度なタスクを実行する能力を「スキル」と呼ぶことがある。この記事では、AIプラットフォーム「Claude Code」に組み込まれた「deep-research」というスキルがどのように作られているかを詳しく解説している。このスキルは、あるトピックに関する最新情報の調査を依頼すると、驚くほど詳細なレポートを生成した。27もの情報源から123の主張を抽出し、そのうち25を検証、最終的に18を確認し、7を反証するという高度な作業を、たった一つのスキルがこなしたのだ。この記事の著者は、その内部構造に興味を持ち、スキルの中身を探ることになった。

このスキルは、一般的なファイルパスには存在せず、Claude Codeのプログラム本体に「バンドルされたワークフロー」として組み込まれていた。その正体は、349行のJavaScriptコードであった。このコードを読み解くことが、deep-researchスキルの秘密を明らかにするための調査となった。

スキルの内部には、AIへの「指示文」である「プロンプト」が三つ存在した。これらすべてのプロンプトには共通の書き方がある。まず、プロンプトのタイトルでAIに与える「役割」を明確にする。次に、「コンテキスト」として、元の質問と、現在の状況に応じた具体的な入力情報を与える。その上で、「タスク」として、AIに実行してほしいことを番号付きのチェックリスト形式で具体的に指示する。さらに、「決定基準」として、どのような条件で判断を下すべきかを明示的に示す。最後に、「出力形式」として、AIがどのような形式で結果を返すかを指定する。 例えば、「検証者」という役割のプロンプトでは、「懐疑的になり、主張を反証しようと試みよ」という指示が冒頭にあり、その後に検証すべき主張とそれを裏付ける引用文が示される。そして、「チェックリスト」として、「主張は引用文で実際に裏付けられているか？」「矛盾する証拠をWebで検索せよ」「情報源の品質は十分か？」「主張は時代遅れではないか？」といった具体的な問いかけが並ぶ。 特に注目すべきは、「refuted=false（反証されていない）となるのは、十分に裏付けられ、最新で、情報源の品質が主張の強度と一致する場合のみ」という明確なルールと、「不確実な場合はデフォルトでrefuted=true（反証済み）とせよ」という、迷ったときのデフォルトの判断基準が記載されていた点だ。通常、プロンプトには記載されないこれらの詳細が、AIが不明確な状況で勝手な推測をせず、より信頼性の高い判断を下すために重要であることが示されている。

このdeep-researchスキルは、単に長いプロンプトだけで構成されているわけではない。その実態は、複数の要素が連携して動作する、より洗練されたシステムであった。その構成要素は以下の六つに分けられる。

一つ目は「トリガーメタデータ」である。これは、スキル名、説明、実行フェーズといった情報に加え、「whenToUse」という重要な項目を含む。whenToUseは、AIがこのスキルをいつ呼び出すべきかを判断するための条件であり、「質問が不明確な場合は、開始する前に二、三の質問をして明確にせよ」という事前指示も含まれている。これは、AIが不完全な情報で処理を開始するのを防ぐための工夫だ。

二つ目は「チューニング定数」である。コードの冒頭に、「一つの主張に対する投票数（VOTES_PER_CLAIM）は3回」「反証に必要な数（REFUTATIONS_REQUIRED）は2回」といった数値が明確に定義されている。これらの定数をコード中に直接埋め込まず、一箇所にまとめておくことで、スキルの振る舞いを簡単に調整できるようになっている。

三つ目は「エージェントごとのスキーマ」だ。スキル内部の各処理単位（エージェント）は、結果をJSON形式で出力し、そのデータの構造が「スキーマ」として定義されている。これにより、あるエージェントが出力したデータが、次のエージェントへの入力として正しく型付けされた状態で渡されるため、各処理がスムーズに連携し、全体として安定したパイプラインを構築できる。

四つ目は「関数としてのプロンプト」である。プロンプトの指示文がコード中に固定されているのではなく、「SEARCH_PROMPT(角度)」「FETCH_PROMPT(情報源, 角度)」のように、入力に応じて適切なプロンプトテキストを生成する「関数」として定義されている。これにより、状況に応じて柔軟にプロンプトを生成し、再利用性を高めることが可能となる。

五つ目は「明示的なオーケストレーション」である。これは、複数の処理ステップ（例えば、情報検索、情報の取得、情報の検証）がどのように連携し、実行されるかを明確に設計する部分だ。deep-researchスキルでは、検索（Search）と取得（Fetch）の処理は並行して進み、各角度からの情報取得が完了次第、その情報源のフェッチ（取得）に移行する。しかし、検証（Verification）のフェーズに入る前には「バリア」と呼ばれる待機ポイントが設けられており、すべての主張が揃うまで処理は先に進まない。これは、検証を行う前に全体の主張のプールが完全である必要があるためだ。その後、25個の主張に対してそれぞれ3回の投票を行う並列処理が実行される。このように、いつ並行処理を行い、いつ同期して待機するかが明示的に設計されている。

六つ目は「防御的な設計」である。これは、予期せぬ事態（例えば、抽出できる主張がない、すべての主張が反証された、合成に失敗した）が発生した場合でも、エラーを投げて処理を中断するのではなく、統計情報を含む有用な結果を返すような設計になっている。また、無効な投票は棄権としてカウントされ、安易に主張が通過しないようになっている。さらに、スキルが自身の実行コスト（エージェントの呼び出し回数）を計算する仕組みも組み込まれており、これにより利用者はスキルの実行にかかるリソースを把握できる。

著者は、このdeep-researchスキルの設計パターンを理解したことを証明するために、それを再利用した。同じトピックに関する追加の調査を行う際、検証フェーズの前にセッション制限に達してしまったが、最初から全ての処理をやり直す代わりに、既存の主張の配列を直接検証する新たなスキル「reverify-linea-c」を作成したのだ。これは、元のスキルのメタデータ、定数、スキーマ、そして三者投票による検証ロジックをそのまま継承し、情報収集のフェーズだけを省略して、既に抽出された22の主張を検証するというものであった。結果として、これら全ての主張が確認された。

この記事から得られる教訓は、優れたAIスキルとは、単に長い指示文（プロンプト）のことではないということだ。それは、短く、そして明確に定義されたプロンプトが、複数のステップを効率的に連携させるための「オーケストレーション」によって何度も実行され、どの段階で処理を待機させ、どの段階で並行して進めるかを把握し、さらにその実行にかかるコストを測定する能力を持つシステムなのである。このような構造を持ったスキルは、その仕組みを比較的短時間で理解することができる。