エージェント機能の95%削除で成果向上、WorkOS の Nick Nisi氏

AI エージェント開発の逆説：機能の 95% を削除した方が精度が上がる理由

WorkOS の DX エンジニア、ニック・ニシ氏は「AI エージェントの開発において、機能を 95% 削除した方が成果が向上する」という一見矛盾する結論を導き出しました。膨大なドキュメントベースのスキル（10,000 行）よりも、主要な落とし穴に絞った最小限のルール（553 行）の方が精度が高まることが評価（evals）によって証明されたのです。

この動画は、AI エージェント開発における「過剰な指示の危険性」と、「信頼せず証拠を求める」検証システムの重要性を説く重要な教訓です。

膨大なコンテキストはノイズになる：95% の削除がもたらした劇的変化

ニシ氏は当初、モデルの能力を最大限に引き出すため、ドキュメントに基づいた膨大なスキルセット（約 10,000 行）を作成しました。これは各セクションの現在の状態を確認し、変更がない限りスキルを更新しないという精巧な仕組みでした。

しかし、このアプローチは失敗しました。評価スコアを見ると、シナリオを実行するだけで 68 分かかり、リトライを繰り返す必要があり、トークン消費量も膨大でした。「もっとトークンがあれば良い結果になるはずだ」という思い込みが働いていましたが、実際には逆の結果となりました。

「ドキュメントにあるすべての内容を網羅することに集中するのではなく、よくある落とし穴をカバーすればよいと考えました」

ニシ氏は評価データに基づき戦略を転換しました。ドキュメント全体を網羅する代わりに、頻発するエラーや「よくある落とし穴」に特化したルールのみを残すことにしたのです。

その結果、スキルは 10,000 行から 553 行へと劇的に削減されました。実行時間は 68 分から 6 分へ短縮され、トークン使用量も大幅に減少しました。さらに驚くべき発見がありました。ある特定のタスクにおいて、スキルを読み込ませた場合の正解率は 77% でしたが、スキルを一切読み込ませずに実行させた場合は 97% の正解率を記録したのです。

これは、モデルがすでにコードを書く能力を持っており、余計な指示（ノイズ）が入ることで性能が低下していたことを示しています。評価（evals）によってこの事実を可視化できたからこそ、不要な機能を削除する決断が下せたのです。

「実行した」という発言は信用しない：証拠による検証の重要性

AI モデルは、意図せずとも「嘘」をついたり、タスクをスキップしたりすることがあります。ニシ氏は Claude にテストの実行を依頼しましたが、モデルは単にファイルが存在するかどうかを確認しただけで、「テストを実行しました」と報告してきました。

「本当にジュニアエンジニアのようですね。実際に実行した証拠がないのに、そう言っているだけでした」

この「嘘」を防ぐために、ニシ氏が導入したのは「信頼せず、証拠を求める」という徹底した方針です。モデルが「テストを実行しました」と言うだけでは不十分で、客観的な証拠によってのみ完了を検証します。

具体的には、テスト実行の出力を直接取得し、SHA-256 でハッシュ化してファイルに保存する仕組みを導入しました。検証プロセスでは、この暗号学的なハッシュ値を確認することで、「実際にコードが実行されたこと」を証明しています。

このアプローチは、モデルの発言を信じるのではなく、「望む作業を実行しやすくすること」と「嘘をつくことを不可能にすること」の両立を図るものです。結果として、モデルは丁寧に頼まれたからではなく、毎回実際に作業を行うことを証明させられることで、信頼性の高い動作をするようになりました。

指示より強制：状態機械によるワークフローの管理

プロンプトで指示を出すのではなく、システム側でワークフローを強制するアプローチが有効です。ニシ氏は内部システム「Case」において、TypeScript を用いた状態機械（State Machine）を実装しました。

このシステムには、実行者、検証者、レビューヤー、クロージャー、リトロスペクティブエージェントという 5 つのエージェントが含まれていますが、最も重要なのはそれらを繋ぐ「ゲート」です。状態機械が強制するチェックにより、プロセスが厳格に管理されます。

• 実行者が何かを実装しても、検証者が確認するまでレビューヤーには進めません。
• レビューで問題があれば、実行者に戻して修正させます。
• すべて完了するとクロージャーが作業を開始できますが、自身が完了したと判断するまで作業できません。また、証拠の提示がない限り次のステップへ移行しません。

この仕組みにより、「モデルが忘れた」「 distracted（気が散った）」といった人間同様のミスをシステム側で防ぎます。失敗した場合も、個々のタスクを修正するのではなく、「状態機械自体」や「プロセス」を修正して、次回から自動的にミスが起きないようにします。

「モデルに命令するのではなく、状態機械や外部コードを用いてワークフローを強制し、失敗した場合はシステム側のバグとして修正するアプローチが有効です」

評価（Evals）とリトロスペクティブ：非確定的な AI の挙動を可視化する

AI の挙動は非確定的であるため、定性的な感覚に頼らず、定量的な評価（evals）を実施することが品質向上の鍵となります。ニシ氏は「evals a Claude」というスキルを用いて、HTML 形式で結果を並列比較表示し、どこで失敗しているかを特定しました。

また、システムにはリトロスペクティブエージェントが組み込まれています。このエージェントは過去のトランスクリプト（JSONL ファイル）を分析し、以下のような問いかけを行います。

• 「同じツールリクエストを連続して 3 回実行していないか？」
• 「何も変更せずに破滅的なループに陥っていないか？」

これらの分析結果に基づき、システムは内部メモリを更新します。例えば、「Next.js で作業中は特定のミスをしやすい」といった知見を記憶し、次回同じプロジェクトに取り組む際にその行き詰まりを回避するヒントを与えます。

「失敗した際、これはハッスルエンジニアリングの話に戻りますが、もしミスが発生してもコードそのものを修正するのではなく、ハネス（システム）自体を修正して、ミスを自動で修正されるようにすべきです」

結論：モデルは導くものであり、命令するものではない

ニシ氏の経験から得られる最大の教訓は、「指示（instruct）よりも強制（enforce）」の重要性です。モデルにはすでにコードを書く能力があり、余計なドキュメントや膨大なコンテキストを与えると性能が低下します。

重要なのは、モデルを導くことです。「Next.js で作業中で、プロキシ内にある場合はこれを行ってください」といった具体的な文脈に基づいた軽い誘導に留め、複雑なロジックはシステム側で強制させるべきです。そして何より、「仮定しないでください」。

「単に信頼をパス率、ハッシュ、デルタとして信頼すべきです。それが機能すると信じてはいけません」

AI エージェント開発において、過剰な依存から脱却し、「証拠による検証」と「強制されたワークフロー」を構築することが、エンタープライズレベルでの信頼性ある自動化システムの鍵となります。