Skill エンジニアリング：AI スキルをソフトウェアとしてテスト・バージョン管理・運用する

Skill が「動く」から「長期保守が必要」に変わるとき、鍵は工学的規律です

多くのチームの最初の OpenClaw Skill は、同じように生まれます。チャットでプロンプトとツール呼び出しを調整し、2〜3 のケースを試して使えると判断し、そのまま本番投入する——問題は動かないことではなく、3 か月後には誰も手を入れられなくなることです。変更したら壊れるのか分からず、前のバージョンとの差分も分からず、本番環境のどこで失敗しているのかも追えません。このギャップはデータでも裏付けられています。LangChain の State of Agent Engineering 調査（2026 年、回答者 1,300 名超）によれば、AI Agent にオブザーバビリティを導入済みのチームは 89% に達する一方、体系的な評価（evals）フローを持つチームは 52% にとどまり、約 3 分の 1 のチームが「出力品質」を Agent が本番に到達できない最大の障壁に挙げています。また Gartner は、AI 評価・オブザーバビリティ基盤を使うソフトウェアエンジニアリングチームが 2025 年の 18% から 2028 年には 60% に増えると予測しています。つまり、AI 資産をソフトウェアとしてテストし運用することは、少数派の自己流から業界標準へと移りつつあります。本記事は最初の Skill の作り方ではなく、Skill が本番に入り、複数人での協働と長期保守が必要になったときに補うべき工学的な要素を扱います。

テスト戦略：「手動で数回試す」を多層検証に置き換える

Skill の出力にはランダム性があり、チャット欄で数回試しただけで合格と宣言することはできません。現実的なのは、検証をリスク別の多層に分けることです。

テストケースが何をカバーすべきかについて、カーネギーメロン大学の 2025 年の研究「What Prompts Don't Say」（arXiv 2505.13360）は明確な警告を与えています。プロンプトに明記されていない要件をモデルが自力で推測して満たす確率は 41.1% にすぎず、しかもこの「たまたま当たる」挙動は脆弱で、未明記の要件はモデルやプロンプトの変更時に退行する確率が明記された要件の 2 倍、精度低下が 20% を超えることもあります。つまり評価セットは「プロンプトに書いた挙動」だけを測るのでは足りず、暗黙に依存しながら文書化していない期待（形式、トーン、してはいけないこと）をすべてアサーションに変えなければ、次の改版で退行するのはまさに誰も見ていないその部分です。実装面の原則は、決定的な部分（解析、形式、境界）は通常のユニットテストで固定し、非決定的な部分（自然言語出力）は逐語一致ではなく構造と主要フィールドのアサーションで検査することです。例えばレポート照会 Skill なら、日付解析と権限判定は決定的ロジックとしてユニットテストで全境界をカバーし、生成される要約文は「金額フィールドを含む、表形式である、他部門のデータを漏らさない」といった構造条件のみをアサートします。こうしておけば、モデルやプロンプトの微調整後に、どの種類のケースが退行したかを即座に把握でき、人が出力を読み直して感覚で判断する必要がなくなります。

バージョン管理と依存性ガバナンス：見えないドリフトへの対抗

Skill は孤立したプロンプトではなく、プロンプトテンプレート、ツール定義、モデルバージョン、外部依存を同時に束ねたものであり、どれか一つの変動でも挙動が変わり得ます。最も見落とされやすいのはモデル自体です。Stanford と UC Berkeley の研究チームは 2023 年に、同じ GPT-4 の名を冠したモデルの素数判定精度が 3 月版の 84% から 6 月版の 51% に低下したことを実測しました——コードは一行も変えていないのに、挙動はすでに変わっているのです。実務上の推奨は次のとおりです。

• モデルバージョンの固定：「最新」ではなく日付付きバージョンを指定し、「いつアップグレードするか」を自分で制御できる意思決定に変え、アップグレード前に評価一式を実行します。
• セマンティックバージョニング：挙動互換の調整は minor、出力契約を変える変更は major とし、呼び出し側がリスクを予期できるようにします。
• すべてをバージョン管理下に：Anthropic の Agent Skills の設計自体が、スキルをバージョン管理・監査可能なファイルとして定義しています。プロンプトテンプレート、ツール定義、依存ロックファイルはコードと同じリポジトリに置き、同じレビュープロセスを通すべきです。
• 変更履歴：リリースごとに何を変え、どの評価ケースに影響するかを記録し、追跡とロールバックの根拠を残します。

CI パイプライン：検証をリリースの関門にする

テストとバージョン管理が整ったら、次はそれらを人の記憶に頼らず自動実行することです。このレイヤーのツールチェーンは既に成熟しています。オープンソースの promptfoo は宣言的な YAML でテストケースを定義し、CI に直結してコミットごとに回帰テストとセキュリティスキャン（プロンプトインジェクション、データ漏えい）を実行できます。LangSmith と Braintrust はデータセット管理、バージョン比較、人手アノテーションを提供します。業界でよくある構成は「軽量フレームワーク（promptfoo、DeepEval）を CI ゲートに、プラットフォーム（Braintrust、LangSmith）を回帰追跡とダッシュボードに」という組み合わせです。パイプラインでは、コミットごとにユニットテストとプロンプト回帰を起動し、マージには評価セットの合格率閾値の通過を必須とします。リリースは段階化し、テスト環境で評価一式を回し、人手の抜き取り検査を経てから本番へ、ワンクリックのロールバックも保持します。価値は「このバージョンを出せるか」を主観判断から定量的な関門に変えることにあります。前述の LangChain 調査でオフライン評価を実施しているのは約半数にとどまるため、この関門を先に築いたチームは、それだけで多くの同業より先行できます。

オブザーバビリティ：本当の試練はリリース後に始まります

本番環境での Skill の挙動はテスト環境では完全に予測できないため、稼働後に「観察可能」であることが必須です。少なくとも三種類のシグナルを記録します。入力と出力の完全なトレース（事後の問題再現用）、呼び出しごとのレイテンシとツールエラー率（性能・安定性の監視用）、そして確認率・リトライ率・人手介入率などの品質指標（退行検知用）です。あるケース群の失敗率が急上昇したら、ユーザーの苦情を待つのではなく、監視が即座にアラートを出すべきです。この層はバージョンアップも制御可能にします。新版リリース後に旧版の指標と比較すれば、進歩か退行かを客観的に判定でき、必要なら即座にロールバックできます。さらに重要なのは、本番で収集した実際の失敗ケースを評価セットに還流させ、「リリース—観察—テスト補充—再リリース」の閉ループを作ることです。これこそが「89% が観測、52% が評価」というギャップの埋め方です。テストケースに還流しないオブザーバビリティデータは、高価なログにすぎません。

ネルドテクニックがお手伝いできること

ネルドテクニック（恩梯科技）は、AI Skill を「動くプロトタイプ」から「長期運用できるソフトウェア資産」へ引き上げるお手伝いをします。テストの多層化と評価セットの構築、モデルバージョン固定と依存性ガバナンスの導入、promptfoo などによる CI リリースゲートの設置、そして稼働後のオブザーバビリティとアラートの整備まで支援します。すでにいくつかの Skill が動いているのに手を入れるのが怖くなってきたチームは、この工学的規律の整備について、ぜひご相談ください。

参考資料

• LangChain、「State of Agent Engineering」、2026年。出典リンク
• Gartner、「Market Guide for AI Evaluation and Observability Platforms」（Comet 経由引用）、2026年。出典リンク
• Yang, Shi, Ma, Liu, Kästner, Wu（カーネギーメロン大学）、「What Prompts Don't Say: Understanding and Managing Underspecification in LLM Prompts」（arXiv:2505.13360）、2025年。出典リンク
• Chen, Zaharia, Zou（スタンフォード大学／UC バークレー校）、「How Is ChatGPT's Behavior Changing over Time?」（arXiv:2307.09009）、2023年。出典リンク