想像してみてください。あなたは、あなたの部屋に、ものすごく賢くて、驚くほど仕事が速いロボットの助手として、ツリーハウス作りを手伝ってくれるよう招待しました。このロボットは、木材、釘、物理学についてのあらゆる知識を持っていますが、あなた独自の「スタイル」については知りません。あなたがいつも手すりを青く塗ることや、2インチより短い釘は絶対に使わないという妙なルールを持っていることも知りません。もし、あなたがやりたい通りに正確にツリーハウスを建ててほしいなら、それを伝えなければなりません。しかし、何かを頼むたびに、あらゆる細かなディテールまで説明しなければならないとしたら、あなたは疲れ果ててしまいますし、ロボットも混乱してしまうでしょう。

これが「AIエージェント」の世界です。AIエージェントとは、私たちのためにタスクを実行してくれるスマートなコンピュータプログラムのことです。彼らを真に役に立つ存在にするために、開発者は彼らに「スキル（Skill）」を与えています。スキルを、魔法の呪文としてではなく、小さな取扱説明書やツールキットとして考えてみてください。それは、「こういう仕事を見つけたら、このように実行してください」と正確に指示するファイルです。ここで科学者やエンジニアが問いかけている大きな問題は、「これらのマニュアルをどのように書けば、ロボットが実際にそれに従ってくれるのか？」ということです。もし書き方が悪ければ、ロボットはそれを無視したり、仕事を間違えたりするかもしれません。もし上手く書ければ、ロボットはあなたのやり方の真のエキスパートになれるのです。

これから読む論文は、ジュゼッペ・デステファニス（Giuseppe Destefanis）によって書かれたもので、これらの「スキル」を書くことは、カジュアルなメモや詩を書くことのように扱うべきではない、と主張しています。代わりに、それはソフトウェアエンジニアリングとして扱うべきなのです。プログラマーが明確なルール、クリーンなコード、安全チェックを備えた信頼できるアプリを構築するように、私たちはAIスキルも同様の注意を払って構築すべきです。論文は、スキルとは実は姿を変えたソフトウェアであると述べています。それは「インターフェース」（それが何をするかを示すラベル）と「実装（implementation）」（実際の指示内容）を持っています。著者は、私たちのAIエージェントが脱線しないようにするために、プログラミングで使用する厳格なルール（シンプルさを保つこと、 「何を」と「どのように」を分離すること、そして注意深くテストすることなど）を使用することを提案しています。

「スキル」はデジタル・スイスアーミーナイフ

魔法のバックパックを想像してみてください。中には何でも入れることができます。その中に、「リリースノート作成用」という特別なポケットがあります。このポケットは単なる紙切れではありません。それは一つの「キット」です。外側には、「新しいバージョンのゲームの変更点の要約を書く必要があるときにこれを使ってください」というラベルが付いています。そのラベルがインターフェースです。ロボットはそのラベルを見て、一致するタスクがあることを確認し、ポケットを開けることに決めます。

ポケットの中には、ただ乱雑にメモを詰め込むのではありません。そこには明確なステップ・バイ・ステップのレシピ（本体）があり、さらに、変更の数を自動的にカウントするスクリプトや、ノートの見た目のためのスタイルガイドといった追加のツールが含まれています。これが実装です。論文では、これを「スキル」と呼び、このキット全体がソフトウェア・アーティファクトであることを強調しています。これは、それがビデオゲームやウェブサイトと同じように、構築、テスト、維持される必要があるテクノロジーの断片であることを意味する、少し難しい言い回しです。

著者は、スキルをカジュアルなメモのように扱うと失敗すると主張しています。もしそれをソフトウェアとして扱えば、うまくいくはずです。以下に、これらのデジタル・キットを構築するためのルールをまとめます。

1. 「単一責任」のルール

スイスアーミーナイフを思い浮かべてください。もし、ドライバー、缶切り、のこぎり、歯ブラシ、ピザカッターの機能をすべて一つの道具に詰め込もうとしたら、すべての機能においてひどい出来になるでしょう。論文は、スキルは一つのことを本当にうまくこなすべきだと述べています。もしスキルが「コーディングに関するすべて」をやろうとすれば、ロボットはいつそれを使うべきか混乱するかもしれません。しかし、スキルが具体的に「プルリクエストからのリリースノート作成」であれば、ロボットはいつそれを使うべきかを正確に理解できます。論文は、焦点を絞ったスキルの方が、AIによってより確実に選択されることを示唆しています。

2. 「ステージド・ローディング（段階的読み込み）」のトリック

百万冊の本がある図書館を想像してください。必要な本を見つけるために、一度にすべての本を読もうとしたら、脳が爆発してしまうでしょう。論文は、AIスキルがステージド・ローディングと呼ばれる巧妙なトリックを使っていることを説明しています。

• レベル1（ラベル）： まず、ロボットはポケットのラベル（名前と短い説明）だけを見ます。これには非常に少ない「脳の力（トークン）」しか消費しません。
• レベル2（レシピ）： ロボットがタスクがラベルに一致すると判断した場合、ポケットを開けてメインのレシピを読み取ります。
• レベル3（ツール）： レシピの中で「今、この特定のファイルを確認する必要がある」と明示的に指示された場合にのみ、追加のツール（スクリプトや参照ファイル）を取り出します。

これにより、膨大な参照資料を含むスキルを持っていても、ロボットが実際にその資料を使う必要がない限り、圧倒されることはありません。それは、巨大な道具箱を持ちながら、必要な引き出しだけを開けるようなものです。

3. 「説明（Description）」がトリガーである

スキルの最も重要な部分は、ラベルにある説明です。論文は、もし「リリースを処理する」といった曖昧なラベルを書けば、ロボットはいつそれを使うべきか分からなくなると警告しています。もっと具体的である必要があります。「2つのバージョンタグの間でマージされたプルリクエストから、リリースノートを作成します。リリースを行う際に使用してください」。ロボットはこの説明にタスクを一致させます。説明が漠にはっきりしない場合、ロボットはそのスキルを完全に見逃すか、あるいは間違ったものを選んでしまう可能性があります。論文は、説明こそがあなたとロボットの間の「契約」であると示唆しています。

4. 「行動評価」によるテスト

通常のコンピュータ・プログラミングでは、関数を実行して答えが正確に「5」であるかどうかを確認することでテストできます。しかし、AIは異なります。ロボットは、正しいことをしていても、毎回少し異なる答えを出す可能性があります。論文は、単純な「合格／不合格」のチェックでスキルをテストすることはできないと述べています。代わりに、**行動評価（behavioral evaluation）**を使用する必要があります。これは、スキルに現実世界のタスクをたくさん与え、何度も実行させ、ほとんどの場合で正しく遂行できているかどうかを確認することを意味します。これは、材料がリストに載っているかを確認するのではなく、新しいレシピを10回作って味見をしてテストするようなものです。

大きな混乱：スキル vs その他のツール

この論文の最大の貢献の一つは、AIに何をさせるかを伝えるための異なる方法の間の混乱を整理することです。著者は、スキルをフック（Hooks）、スラッシュコマンド（Slash Commands）、**メモリファイル（Memory Files）**といった他のツールと比較しています。

演劇を演出していると考えてみてください。

• メモリファイルは、劇の全編を通して、俳優（AI）の前に常に存在し、見える舞台上のスクリプトのようなものです。これらは、プロジェクトの継続的なコンテキストを提供し、たとえロボットが特定の行動を強制されなくても、常にこの情報が利用可能であることを保証します。
• スラッシュコマンドは、舞台係が「おい、今すぐマジックをやれ！」と叫ぶようなものです。あなた（ユーザー）がコマンドを発する必要があります。ロボットはあなたの指示を待っています。
• フックは、厳格で自動化された安全装置のようなものです。もし俳優がハーネスなしで舞台から飛び降りようとしたら、安全装置は、彼らを捕まえたり動作を停止させたりするために、決定論的に（deterministic execute）ルールを実行します。ロボットがこれを無視することはできません。特定のイベントが発生するたびに、ロボットの判断に関わらず、必ず実行されます。
• スキルは、オンデマンドでロードされる専門的な手続き型ツールキットのようなものです。ロボットがタスクに遭遇したとき、説明に一致するかどうかを確認し、その領域を扱うための具体的な指示をロードします。これは、ロボットが問題を解決するために能動的に取得する、専門知識の源です。

論文は明確な境界線を引いています。もし「毎回必ず」何かを起こす必要があるなら（ファイルの保存前の安全チェックなど）、フックを使用しなければなりません。もしロボットに、特定のプロセスが必要かどうかを判断させたいなら、スキルを使用します。論文は、これらを混同することはよくある間違いだと警告しています。安全ルールをスキルの中に書いてしまうと、ロボットはそれをスキップしてもよいと判断してしまうかもしれません。逆に、柔軟な提案をフックの中に書いてしまうと、ロボットがすべきでない時でも同じことをやり続けてしまう可能性があります。

「信頼」の問題

最後に、論文は恐ろしくも重要な概念である「信頼」について触れています。もしあなたが第三者からダウンロードしたスキルがある場合、あなたは、自分のロボットが従う指示を彼らに書かせていることになります。そのスキルには、ファイルを削除したりデータをインターネットに送信したりするスクリプトが含まれている可能性があります。論文は、スキルをインターネットからダウンロードするソフトウェアと同じように扱うべきだと主張しています。単に「インストール」をクリックするだけではいけません。コードを読み、スクリプトをチェックし、安全であることを確認する必要があります。ロボットはスキルが指示する通りに何でも行うため、あなたがゲートキーパー（門番）にならなければならないのです。

結論

ジュゼッペ・デステファニスの論文は、AIツールを構築するすべての人への行動喚起です。それはこう言っています。「AIへの指示をカジュアルなメモとして扱うのはやめなさい。それを本格的なソフトウェアとして扱いなさい。」

ソフトウェアエンジニアリングの原則（シンプルさを保ち、ラベルと内容を分離し、現実のシナリオでテストし、スキルとフックの使い分けを明確にする）を用いることで、私たちは単に賢いだけでなく、信頼でき、かつ安全なAIエージェントを構築することができます。この論文は、これがすべてのAI問題を解決すると約束するものではありませんが、もし私たちがスキルをアプリケーションと同じような注意深さで構築すれば、デジタルアシスタントをより信頼できるパートナーにできることを示唆しています。それは、「ロボットが正しくやってくれることを願う」ことから、「ロボットが正しく行うように設計（エンジニアリング）する」ことへの移行なのです。