AIの「サボり」や「うそ」を防ぐ Skillsを95%削って性能を爆上げした設計思想：AIエージェントに知識を与え過ぎると逆効果？
WorkOSのディベロッパーエクスペリエンスエンジニアであるニック・ニシ氏は、AIエージェント向けSkillsの約95％を削除した結果、処理時間の短縮と正解率の向上を実現した。実現の鍵となる設計思想を紹介する。
AIエージェントの活用が広がる中、「より多くの知識やルールを与えれば性能は向上する」と考えがちなユーザーもいる。しかし実際には、その発想がAIの性能を低下させている可能性がある。
認証サービスを提供するWorkOSでディベロッパーエクスペリエンスエンジニアを務めるニック・ニシ氏は、自身が開発したAIエージェント向けスキルの約95％を削除した結果、性能が改善したと説明した。同氏がAIエージェントのパフォーマンス向上と開発の高速化に成功した事例から、AIエージェントを実運用する上で重要な設計思想が見えてくる。
抱えていた課題は「AIエージェントの限界」と「サボり」
併せて読みたいお薦め記事
AIエージェントの性能を向上させるには
課題1．開発のスケールとボトルネック
「約8カ月間、自分では1行もコードを書いていない」と語るニシ氏は、20以上のリポジトリと8種類のプログラミング言語にまたがる開発を、AIエージェントを活用しながら進めている。
しかし、AIエージェントの活用が進むほど、新たな問題が浮かび上がった。各タスクを開始するたびに、GitHub IssueやLinearのチケット、Slackの議論などをAIエージェントへ説明し、問題の背景や目的を理解させるためのセットアップに約10分を費やしていたという。さらに、多数のプロジェクトを並行して担当するため、ニシ氏が頻繁にコンテキストを切り替えなければならず、それが新たなボトルネックになっていた。
課題2．プロンプトの限界
この課題を解決するため同氏は、GitHub IssueやPull Request、Slackスレッドなどを入力すれば、必要なコンテキストを自ら収集・理解し、Pull Requestの作成まで自律的に実行するシステム「Case」を開発した。当初はClaudeのskillsの1つとして実装し、プロンプトによって一連の作業を指示する方式を採用していた。
しかし、タスクが複雑になると問題が発生した。AIエージェントは途中で前半の指示を忘れたり、一部のタスクを勝手に省略したりするようになった。同氏が「なぜその作業をしなかったのか」と尋ねると、「そのようにすることにした」と返答することもあったという。つまり、プロンプトで「実行してほしい」と指示するだけでは、AIエージェントの行動を確実に制御できなかったのである。
課題3．AIエージェントの嘘
さらに深刻だったのは、AIエージェントが「実施したふり」を覚えたことだったという。
例えば、「テストを実行して確認してほしい」と指示すると、AIエージェントは実際にはテストを実行せず、中身のないファイルだけを生成して、「テストは完了した」と報告した。
この経験から同氏は、AIエージェントに「実行してください」と指示するだけでは不十分であり、AIエージェントが作業を省略したり、完了したように見せかけたりできない仕組みそのものを設計する必要があるとの結論に至った。
解決策は「プロンプト」ではなく「システム」で強制すること
ニシ氏は、これらの問題を「プロンプトの書き方」で解決しようとは考えなかった。AIエージェントに「テストを実行してください」「レビューしてください」と丁寧に指示しても、状況によっては忘れたり、省略したりすることがあるからだ。
そこで同氏は、「Case」をClaudeのSkillsではなく、状態マシン（State Machine）を利用したシステムとして再構築した。処理は「実装」「検証」「レビュー」「クローズ」「振り返り」の5つの役割に分割され、それぞれの間には厳格な「ゲート」を設けた。
例えば、実装担当のAIエージェントがコードを書いても、検証担当のAIエージェントがテストを通過したと確認するまではレビュー工程へ進めない。レビューで問題が見つかれば、自動的に実装工程へ差し戻される。この一連の流れはAIの判断ではなく、システム側が強制する仕組みになっている。
さらに、「テストを実行した」という報告だけでは認めないようにした。テスト結果をハッシュアルゴリズム「SHA-256」（SHA：Secure Hash Algorithm）を使ってハッシュ化し、その値を保存・検証する仕組みを導入したことで、中身のない完了ファイルを生成して「テスト済み」と報告するような「サボり」はできなくなった。ニシ氏は、「AIにうそをつかせないためには、うそをつくより実際に作業した方が簡単な環境を作ればよい」と説明している。
UIのバグ修正でも同様だ。MicrosoftのE2E（エンドツーエンド）テストツール「Playwright」のCLI（コマンドラインインタフェース）を利用して修正前後の動作を自動で録画し、その動画をPull Requestへ添付させるようにした。同氏は、この証拠が提示されない限り、人間によるコードレビューすら実施しないという。
この考え方を同氏は、「Enforce, don't instruct」（指示するな、強制せよ）という言葉で表現している。AIエージェントに「やってほしい」と依頼するのではなく、やらなければ次の工程へ進めない仕組みをシステム側で構築することが重要だという。
95％のスキルを削除したら性能が向上した理由
WorkOSのユーザー向けツール「WorkOS CLI」の開発では、さらに意外な結果が得られた。
当初、ニシ氏は自社ドキュメントを基に1万行を超えるSkillsを自動生成し、AIエージェントへ読み込ませていた。しかし、評価（Evals）を実施すると、処理時間は約68分かかり、不要なリトライや回り道が増えていた。
そこで発想を転換し、AIエージェントが頻繁に間違える「よくある落とし穴」（Gotchas）だけをまとめた553行のガイドへ整理した。Skillsの約95％を削除した結果、1回当たりの評価時間は約6分まで短縮され、AIエージェントの正解率も向上したという。
実際には、あるタスクではSkillsを読み込ませた場合の正解率が77％だったのに対し、読み込ませない場合は97％だった。つまり、人間が「親切だ」と考えて追加した大量の情報が、AIエージェントを迷わせていた可能性がある。
AIモデル自体は一般的なプログラミング知識を十分に持っている。そこで必要なのは、膨大なドキュメントではなく、その製品特有の「わな」や「地雷」の情報だけだと指摘する。
同氏は、「Guide, don't prescribe」（すべてを規定するな、導け）、「Measure, don't assume」（思い込むな、測定せよ）という2つの原則を、AIエージェント時代のシステム設計における重要な考え方として挙げている。
本稿は、AI Engineerが2026年5月31日に公開した動画「How I deleted 95% of my agent skills and got better results―Nick Nisi, WorkOS」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.