ロボットを長く運用していれば、いかに「スキル」の質が重要であるかにお気づきでしょう。
著しく出来の悪いスキルであれば、むしろ対処は簡単です。2 回ほど稼働させて全く機能しないと判断できれば、その場でアンインストールして終了だからです。
しかし、最も厄介なのは「完全には使えないわけではない」スキルです。7 割の確率では正常に動作するものの、残りの 3 割で致命的なエラー（フリップ）を発生させる、そんな中途半端な不安定性を抱えています。
これは極めて現実的な課題です。著名な AI 研究者であるアンドレイ・カルパシー（Andrej Karpathy）氏は最近、大規模言語モデル（LLM）のトレーニングをエージェントに自律最適化させるオープンソースプロジェクト「autoresearch」を発表し、その驚異的な効果を証明しました。
しかし、このメソドロジは他のシナリオにも応用可能です。
本稿では、この理論をロボティクス用スキルの最適化に適用した最佳事例（ベストプラクティス）を共有します。
autoresearch の本質は「AI による AI の最適化」に他なりません。
であれば、当然ながら AI にスキルの自動反復最適化を行わせることも可能です。実際に Web コピー関連のスキルでテストしたところ、成功率を 56% から 92% へと飛躍的に向上させることができました。
スキルが最も恐れるのは「不安定性」
スキルに不安定さがある場合、その手順を実行しても大規模言語モデルが期待通りの結果を出力できない確率が存在することを意味します。
そして往々にして、なぜそのような不具合が発生したのか、その原因特定が困難を極めます。
では、どうすべきか。多くの場合、AI に内省（リフレクション）させ、感覚を頼りに闇雲な修正を加えることになります。
その結果、スキルは継ぎ接ぎだらけの「キメラ」と化してしまうのです。
autoresearch が行うべきことは、このプロセスを「再現可能な実験」として体系化することです。
その中核は驚くほどシンプルで、エージェントに一度にスキル全体を書き換えさせる必要はありません。
一度にほんの一小箇所のみを変更し、再実行してスコアリングします。改善されていれば変更を採用し、悪化していれば撤回する。これだけです。
つまり、測定可能なものであれば、何でも autoresearch の対象となり得るのです。
それは様々なスキルも例外ではありません。
「良い」の定義を明確にする
なぜスキルは不安定になるのでしょうか。
それは、指示の中に曖昧な表現が含まれているからです。
例えば、「AI っぽさを消し、もっと自然にせよ」といった指示がそれにあたります。
言っていることは間違っていませんが、実行段階では極めて主観的（オカルト的）な判断を迫られることになります。autoresearch は、こうした曖昧さを「Yes/No で答えられる明確な問題」へと分解することを強制します。
あなたにとっての「良い結果」とは何か。
例えば、記事作成スキルにおける定義の一例は以下の通りです。
- 全文が 1500 字以内に収まっているか？
- 冒頭 3 文で要点が明確になっているか？
- タイトルに特定の要素が含まれているか？
このように「Yes/No」で判定可能な定義を行うことで、AI は安定的にスコアリングを行えるようになります。
以下に、評価基準（Eval）を策定するための具体的なプロンプト事例を示します。
### 評価（Eval）ガイドライン
あなたのスキルを真に向上させる評価基準を作成する方法。虚偽の安心感を与える基準ではない。
---
### 黄金律
すべての評価（eval）は「Yes / No」で答える問題でなければならない。
スケール評価（点数制）ではない。
感覚的な判断ではない。
二値的（バイナリ）でなければならない。
理由：スケール評価は変動を蓄積させる。4 つの評価項目があり、それぞれを 1〜7 点で評価する場合、総点は実行ごとに大きなばらつき（分散）を生む。安定した信頼できるシグナルを得るには、二値的評価が必須である。
---
### 良い評価と悪い評価
#### テキスト / コピーライティング系スキル
例：ニュースレター、ツイート、メール、ランディングページ
**悪い評価：**
- 「この文章は上手か？」（曖昧すぎる。「上手」とは何か？）
- 「魅力に 1〜10 点をつける」（スケール評価＝信頼性なし）
- 「人間が書いたように聞こえるか？」（主観的。評価者がブレる）
**良い評価：**
- 「出力中に、以下の禁止語句リスト [game-changer, here's the kicker, the best part, level up] が完全に含まれていないか？」（二値的・具体的）
- 「冒頭 1 文目で、具体的な時刻、場所、または感覚的詳細に触れているか？」（二値的・検証可能）
- 「出力は 150〜400 字の範囲内か？」（二値的・測定可能）
- 「結びで、読者の次のアクションを明確に指示する具体的な CTA（行動喚起）が使われているか？」（二値的・構造的）
#### ビジュアル / デザイン系スキル
例：図解、画像、スライド
**悪い評価：**
- 「プロフェッショナルに見えるか？」（主観的）
- 「視覚的品質に 1〜5 点をつける」（スケール評価）
- 「レイアウトは良いか？」（曖昧）
**良い評価：**
- 「画像内のすべての文字は、欠け、重なり、被りなしに明瞭に読み取れるか？」（二値的・具体的）
- 「配色はソフト / パステル系のみで、蛍光色、鮮烈な赤、高彩度の色を使っていないか？」（二値的・検証可能）
- 「レイアウトは線形（左から右、または上から下への流れ）であり、要素が散在していないか？」（二値的・構造的）
- 「画像内に、数字のステップ、序数、または連番が完全に含まれていないか？」（二値的・具体的）
#### コード / 技術系スキル
例：コード生成、設定、スクリプト
**悪い評価：**
- 「コードはクリーンか？」（主観的）
- 「ベストプラクティスに従っているか？」（曖昧。どのベストプラクティスか？）
**良い評価：**
- 「コードはエラーを出力せずに実行可能か？」（二値的・テスト可能：実際に実行する）
- 「出力中に「TODO」やプレースホルダーのコメントが完全に含まれていないか？」（二値的・grep 可能）
- 「すべての関数名および変数名は記述的か（ループカウンタを除き、1 文字名を使っていないか）？」（二値的・検証可能）
- 「すべての外部呼び出し（API、ファイル I/O、ネットワーク）に対してエラーハンドリングが実装されているか？」（二値的・構造的）
#### ドキュメント系スキル
例：提案書、レポート、デッキ
**悪い評価：**
- 「内容は網羅的か？」（何に対して網羅的か？）
- 「クライアントの要望に応えているか？」（開放的すぎる）
**良い評価：**
- 「ドキュメントに必要な全セクション [セクション名を列挙] が含まれているか？」（二値的・構造的）
- 「すべての結論が、具体的な数値、日付、または出典によって裏付けられているか？」（二値的・検証可能）
- 「ドキュメントは [X] ページ / [X] 字以内に収まっているか？」（二値的・測定可能）
- 「エグゼクティブサマリーは 1 段落かつ 3 文以内に圧縮されているか？」（二値的・計数可能）
---
### 一般的な過ち
#### 1. 評価項目が多すぎる
評価項目が 6 つを超えると、スキルは「評価の抜け穴」を見つけ始める。真に良い結果を出すことではなく、テストをパスすることだけを最適化してしまう。まるで内容を理解せず、答えを丸暗記する生徒のようだ。
**修正法：** 最も重要な 3〜6 のチェック項目を選別する。これらが通過すれば、出力は概ね良好である。
#### 2. 狭すぎる / 硬すぎる
「必ず 3 つの箇条書きを含むこと」や「because を 2 回以上使用すること」といったルールは、技術的にはテストを通過するが、出力は奇異で硬直したものになる。
**修正法：** 評価は、ランダムな構造制約ではなく、あなたが真に重視する品質特性を検査するものであるべきだ。
#### 3. 評価項目の重複
評価 1 が「文法は正しいか」で、評価 4 が「スペルミスはないか」の場合、両者は重複している。文法エラーには往々にしてスペルミスも含まれる。重複カウントを行っているに過ぎない。
**修正法：** 各評価項目は、独立した 1 つの次元のみをテストすべきである。
#### 4. エージェントが測定できない項目
「人間はこの文章に魅力を感じるか？」エージェントはこの問いに安定的に答えることはできない。ほぼ常に「感じる」と答えるだろう。
**修正法：** 主観的感覚を観察可能なシグナルに変換する。例えば「魅力的」は、「冒頭 1 文が、漠然とした陳述ではなく、具体的な主張、物語、または問題提起を含んでいるか？」と書き換える。
---
### 評価を書く前の 3 つの自問
評価項目を確定する前に、自らに問いかけよ：
1. **別の 2 つのエージェントが同じ出力を受け取った際、同じ採点を行うか？**
できない場合、その評価は主観的すぎる。書き直せ。
2. **スキルが実際には改善していなくても、抜け穴を突いてこの評価を通過できるか？**
できる場合、その評価は狭すぎる。緩和せよ。
3. **この評価が測っているのは、ユーザーが真に気にする事象か？**
違うなら削除せよ。重要でない評価は、真に重要な評価のシグナルを希薄化させるだけだ。以上を踏まえた完全なサイクルは以下の通りです。
1. 最適化したいスキルを 1 つ選択する。
2. テスト用の入力データを準備する。
例えば、長文記事の冒頭作成、Google の 5 つのスキル原則に基づくコンテンツ作成など。
3. チェックリストを与える。
3〜6 項目が適当だろう。少なすぎれば制約として不十分であり、多すぎればエージェントはチェックリスト迎合のための「テスト対策」を始めてしまう。
4. スコアリング → 反復 → スコアリング。
まずスコアリングを行い、結果が低ければ、エージェントに失敗点を分析させ、小修正を加えて再テストする。スコアが向上すれば採用し、低下すれば撤回する。
これを次のラウンドへ続ける。
高得点が連続して達成されるまでこれを繰り返す。
変更履歴（チェンジログ）の価値
ここにはスキルの完全な進化の歴史が記録される。
何を変更したのか、なぜ変更したのか、変更によって向上したのか、あるいは理にかなった変更ではあったが最終的に効果が出なかったのはどの部分か。
この記録は極めて重要だ。
将来的にモデルがアップグレードされた際や、スキルを別プラットフォームへ移行したい際に、ゼロからやり直す必要がなくなるからだ。手元には「検証済みのスキルの進化パス」が残っている。
これこそが、エージェント時代において極めて希少な資産なのである。
結びに
実はこれらの手法は、スキル最適化のみに限定されるものではない。
私はこれをコードのパフォーマンス最適化にも応用している。
あるウェブページの読み込みにおいて、67 回の反復により、1100ms から 67ms へと劇的な短縮を達成した。
つまり、スコアリングルールを定義さえできれば、エージェントに自律的な反復最適化を行わせることができるのだ。
これは一種の強化学習であり、スコアリングルールが「報酬スコア」となる。
もはや「感覚」を頼りに最適化するのはやめよう。autoresearch はすでに誰の目にも明らかな事実を突きつけている。
あるものが繰り返し呼び出されるのであれば、それは繰り返しテストする価値がある。
あるものが繰り返しテスト可能であれば、それはエージェントによる自動最適化に任せる価値がある。