多くのチームの最初の 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 の出力にはランダム性があり、チャット欄で数回試しただけで合格と宣言することはできません。現実的なのは、検証をリスク別の多層に分けることです。
| 層 | 検証対象 | 自動実行の可否 |
|---|---|---|
| ユニットテスト | ツール関数、引数解析、データ形式変換などの決定的ロジック | 可。コミットごとに実行すべき |
| プロンプト回帰 | 固定入力に対し、出力が期待の形を保っているか | 可。逐語比較ではなく主要フィールドのアサーションで |
| 評価セット | 代表ケース数十件の合格率による品質の定量化 | 可。合格率の閾値をリリースゲートに |
| エンドツーエンド | 実ツール連携、権限、副作用（データ書き込み等） | 一部可。副作用はサンドボックスか mock で |
テストケースが何をカバーすべきかについて、カーネギーメロン大学の 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% に低下したことを実測しました——コードは一行も変えていないのに、挙動はすでに変わっているのです。実務上の推奨は次のとおりです。
テストとバージョン管理が整ったら、次はそれらを人の記憶に頼らず自動実行することです。このレイヤーのツールチェーンは既に成熟しています。オープンソースの promptfoo は宣言的な YAML でテストケースを定義し、CI に直結してコミットごとに回帰テストとセキュリティスキャン（プロンプトインジェクション、データ漏えい）を実行できます。LangSmith と Braintrust はデータセット管理、バージョン比較、人手アノテーションを提供します。業界でよくある構成は「軽量フレームワーク（promptfoo、DeepEval）を CI ゲートに、プラットフォーム（Braintrust、LangSmith）を回帰追跡とダッシュボードに」という組み合わせです。パイプラインでは、コミットごとにユニットテストとプロンプト回帰を起動し、マージには評価セットの合格率閾値の通過を必須とします。リリースは段階化し、テスト環境で評価一式を回し、人手の抜き取り検査を経てから本番へ、ワンクリックのロールバックも保持します。価値は「このバージョンを出せるか」を主観判断から定量的な関門に変えることにあります。前述の LangChain 調査でオフライン評価を実施しているのは約半数にとどまるため、この関門を先に築いたチームは、それだけで多くの同業より先行できます。
本番環境での Skill の挙動はテスト環境では完全に予測できないため、稼働後に「観察可能」であることが必須です。少なくとも三種類のシグナルを記録します。入力と出力の完全なトレース（事後の問題再現用）、呼び出しごとのレイテンシとツールエラー率（性能・安定性の監視用）、そして確認率・リトライ率・人手介入率などの品質指標（退行検知用）です。あるケース群の失敗率が急上昇したら、ユーザーの苦情を待つのではなく、監視が即座にアラートを出すべきです。この層はバージョンアップも制御可能にします。新版リリース後に旧版の指標と比較すれば、進歩か退行かを客観的に判定でき、必要なら即座にロールバックできます。さらに重要なのは、本番で収集した実際の失敗ケースを評価セットに還流させ、「リリース—観察—テスト補充—再リリース」の閉ループを作ることです。これこそが「89% が観測、52% が評価」というギャップの埋め方です。テストケースに還流しないオブザーバビリティデータは、高価なログにすぎません。
ネルドテクニック（恩梯科技）は、AI Skill を「動くプロトタイプ」から「長期運用できるソフトウェア資産」へ引き上げるお手伝いをします。テストの多層化と評価セットの構築、モデルバージョン固定と依存性ガバナンスの導入、promptfoo などによる CI リリースゲートの設置、そして稼働後のオブザーバビリティとアラートの整備まで支援します。すでにいくつかの Skill が動いているのに手を入れるのが怖くなってきたチームは、この工学的規律の整備について、ぜひご相談ください。
これらの手法を自社に導入したいですか？
LINEで無料相談
技術共有
多くのブランドはチャネルごとに別々のAIボットを設置し、音声・チャット・CRMがかみ合わず、同じ顧客がつながりのない断片に分割されています。本記事では、CXMのチャネル横断統合を三層——統一顧客ビュー、システム統合、チャネル横断のオーケストレーション——として実データとともに読み解き、あらゆる接点が同一の顧客レコードの上に成り立つ仕組みを示します。
技術共有
会話が長くなるほど AI はなぜ高く、そして散漫になるのでしょうか。本稿は Chroma や Anthropic などの最新研究データをもとに、スライディングウィンドウ、要約圧縮（compaction）、分割による外部退避、重要情報のピン留めという四つの戦略と、その組み合わせ方を解き明かします。
技術共有
多くの企業は AI への権限委譲を白か黒かのスイッチとして扱い、全件を人が審査するか、すべてをシステムに自動で任せるかのどちらかになりがちです。しかし Gartner は、リスク管理の不足により agentic AI プロジェクトの 40% 超が 2027 年までに中止されると予測しています。本記事は人間工学と AI エージェントの実在する分級枠組みをもとに、全件人手審査から完全自律までの五段階の権限委譲の階段を示し、定量的な昇格基準と品質低下時のサーキットブレーカーによるフォールバックまでを扱います。
サポートが必要ですか？
ここをクリックしてお問い合わせください！
