SKILL.md補修の衝撃：AIエージェントの「一貫性のギャップ」を潰す

深夜の障害対応でモニタと対峙している時、最も我々シニアエンジニアを絶望させるのは「再現性のないバグ」だ。従来の確定的なソフトウェアであれば、スタックトレースを追い、デッドロックやメモリリークの原因を特定すれば確定的に修正できた。しかし、LLM（大規模言語モデル）を駆動エンジンとするAIエージェントの現場で今起きているのは、さらに不気味な現象である。「昨日は100回連続で完璧に動いていたGitHub Issueの集計エージェントが、今朝はなぜか途中で満足して処理を打ち切る」といった、非確定的な挙動のブレだ。

多くの開発者は、この不具合に直面した際、壊れたプロンプトやSKILL.md（エージェントに与える手順指示書）をコピペし、チャットUI上のLLMに向かって「なんか動かないから直しておいて」と雑に命令を投げて済ませていないだろうか。私に言わせれば、これは最悪のアンチパターンだ。人間が手順書を真面目に読まず、LLMに場当たり的な修正（モンキーパッチ）を行わせれば行わせるほど、プロンプトはスパゲッティコード化し、特定条件下でしか動かない張り子のようなシステムへと成り下がっていく。

IBM Researchの研究者らが2026年9月に発表した論文（Duesterwald et al.）では、この現象の本質を「Consistency Gap（一貫性のギャップ）」と名付けている。彼らが提示した衝撃的なベンチマークデータを見てほしい。エージェント評価用データセット「AppWorld」において、GPT-4.1を用いたエージェントの5回実行における「平均成功率」は77%と一見高水準に見える。しかし、同じタスクを5回「連続で成功」させた確率（Pass^5）を計測すると、数字はわずか53%まで急落するのだ。

平均値という甘美な数字に騙されて導入を決めたエンタープライズの現場が、運用フェーズで叩き落される地獄の正体がここにある。LLMの推論プロセスの中に「行動の判断に迷うステップ（確率分布が平坦なトークン選択）」が存在すると、そのわずかな揺らぎがバタフライエフェクトのように増幅し、最終的なタスク失敗を引き起こす。我々エンジニアが立ち向かうべきは、単なるプロンプトのタイポ修正ではなく、この確率的な迷いをいかにしてシステム的に潰し込むかという構造的課題なのだ。

では、この「一貫性のギャップ」をいかにして埋めるべきか。IBM ResearchのDuesterwaldらが論文『Closing the Consistency Gap: Self-Evolving Agents That Learn to Stay on Course』で提示したアプローチ「Self-Evolving Agents（自己進化型エージェント）」は、極めて洗練された回答を示している。その核心は、プロンプト修復というメタな作業そのものを、人間や一発のLLMの気まぐれに委ねるのではなく、「スキルの改善を行う定型ハーネス（評価・修正フレームワーク）」としてシステム内部に組み込む点にある。

この手法の技術的インサイトにおいて最も白眉と言えるのが、「将来失敗しそうな潜在的リスクの先回り検知」である。従来の自動修復が「すでにクラッシュしたコード」しか見ないのに対し、本手法はエージェントの実行履歴における各ステップに対し、裏でプロンプトの再サンプリング（複数回の試行）を実行する。これにより、各ステップにおける「回答の分散（ブレ幅）」を定量的に測定するのだ。もし特定のステップでモデルの出力が分散している（確率分布が乱れている）ならば、仮にその回の実行自体は成功していたとしても「将来爆発する危険地帯」と判定し、先回りしてガイドラインを補強する。

彼らがAppWorldを用いて行った検証結果は、このアプローチの正当性を雄弁に物語っている。以下にそのパフォーマンス比較をまとめた。

単に特定タスクでの連続成功率が16.0ポイント向上（53.0%→69.0%）しただけでなく、ガイドラインを抽出したタスクとは異なる「未知の類似タスク」へ適用した場合でもPass^5が13.0ポイント向上している点に注視すべきだ。これは、過学習（オーバーフィッティング）的なハックではなく、LLMが迷いがちな「抽象的な判断基準」そのものが、定型化されたハーネスによって一般化・強靭化されたことを意味している。雑なプロンプトエンジニアリングの時代は終わり、スキルの改善プロセス自体をプログラマブルに制御する時代が到来したのだと、私は確信している。

論文の理論は美しいが、現場の泥臭いコードで使い物にならなければ意味がない。エンタープライズ領域でRAGや生成AIプロダクトの開発を手掛ける株式会社ナレッジセンスの門脇敦CEOは、この論文の着想を手元で即座に追試すべく、オープンソースの自動修復ハーネス『agent-repair』（https://github.com/tankadoko/agent-repair）を構築・公開した。この実装は、エージェントが実行に失敗したセッションIDを渡すだけで、過去の履歴とスクリプトを解析し、スキル（SKILL.md等）を自律修正するという極めて実用的なアプローチを取っている。

門脇氏らによる検証結果は、我々現場のエンジニアにとって極めて示唆に富む。デモ1として行われた「GitHubのIssue/PR取得スキル」の修正検証を見てみよう。このスキルには「APIレスポンスの最初の100件を取得した時点でAIが勝手に満足し、処理を終了してしまう」という、典型的なLLMの横着癖が存在していた。agent-repairを適用した結果、ハーネスは実行履歴とスクリプトを自律的に検証し、ページネーション（次ページの取得ループ）を確実に実行するようスキルを修正した。

125件のデータで修正されたスキルが、203件という未知のスケールでも全件取得を達成しつつ、元々正常に動いていた25件の小規模ケースを破壊（先祖返り）していない点は特筆に値する。

しかし、私が真に興奮したのはデモ2の「PowerShellウィンドウタイトル変更スキル」の検証結果だ。ここで興味深い「LLMの限界」が露呈した。agent-repairが一度目に提示した修正案において、LLMは付属スクリプトのバグは直したものの、スキル本文（SKILL.md）に記載されていた「実行コマンドの例」の中にある不具合を見落とし、修正が不完全なままで出力してきたのだ。従来の雑なプロンプト修復であれば、この時点で「修正完了」と判定され、本番環境で再び深夜にアラートが鳴り響くことになっただろう。

だが、門脇氏のハーネスは修正案を出力した後の「確認・検証工程（Evaluation Loop）」を多重化していた。ハーネス自身がこの修正漏れを検知し、LLMに対して「スキル本文と実行例の整合性が取れていない」とフィードバックを送ることで、最終的にスクリプトとスキル本文の双方を完全に補修させたのだ。LLMは一度で完璧な答えを出せない。だからこそ、LLMの不完全さを織り込んだ「二重三重の自動チェック機構」をハーネス側で実装することこそが、プロダクション品質を担保する唯一の解答であることをこの実験は明かしている。

「昨日動いたものが、なぜか今日は動かない」――我々はこの呪いのような非決定性に対して、いつまで「プロンプトに『絶対に途中で止めないでください』と強調のびっくりマークを増やす」というような呪術的アプローチで対抗し続けるつもりだろうか。ナレッジセンスの実証実験とIBMの研究が我々に突きつけているのは、スキルのメンテナンスを人間の職人技や勘に頼る時代の完全な終わりである。

エージェント開発における真の課題は、「LLMにどう指示を出すか」ではなく、「LLMの出力ブレを評価・修復するハーネスをいかにコードとして定義・改善し続けるか」というメタエンジニアリングへとシフトしている。スキルのカイゼンを人力で行っている限り、システムのスケールは不可能であり、技術的負債は指数関数的に増大する。

明日からの開発現場において、我々シニアエンジニアが直ちに組み込むべき「実践的な処方箋」は以下の3点に集約される。

• スキルの仕様書に「回帰テスト用データ」をセットで定義せよ： SKILL.mdを単独で放置するな。agent-repairの検証が示したように、小規模、境界値、大規模のテストケースを定義し、修復後のスキルが既存動作を壊していないかを自動検証するテストハーネスをCI/CDに組み込むべきだ。
• プロンプト修復プロセスに「多重の自己検証ループ」を強制せよ： LLMに修正を行わせる際、一回の出力で結果を信じてはならない。生成された修復案に対し、「コードとドキュメントの整合性」「エッジケースでの破綻」を別のプロンプトや決定論的スクリプトでチェックさせる二重のハーネス構造を必須とせよ。
• 「ブレの兆候」を再サンプリングによって事前検知せよ： 本番環境でクラッシュするのを待つのではなく、定期的にエージェントの推論ログに対して裏で複数回の再サンプリングを行い、回答の不確定性（分散）が高いステップをログから検知・先回り修復するバッチ処理を導入せよ。

最後に、現場でコードを書くすべてのエンジニアに問いかけたい。あなたはこれからも、破綻したプロンプトを前に「お願いだから今回は動いてくれ」と神に祈るだけの呪術師であり続けるのか？それとも、LLMの不確定性すらも決定論的なハーネスで包み込み、堅牢なシステムとして制御する真のソフトウェアエンジニアへと進化するのか？選択の刻は、すでに訪れている。