Skill Creatorの技術設計と動作原理

エージェントが新たなスキルを自律的に獲得し、確実に実行できる理由

Transcript

1. Skill Creatorの 技術設計 ＆ 動作原理 エージェントが新たなスキルを自律的に獲得し、確実に 実行できる理由 Presented by MOAI Lab
2. 現代のエージェント開発の限界と課題 アドホックなプロンプトの限界 エージェント開発の初期段階では、システムプロ ンプトや命令の『継ぎ足し』が行われがちです。 しかし、命令が増大するにつれ、LLMが指示を無 視したり、過去の命令と矛盾した行動をとる『指 示ドリフト』が頻発します。 コンテキスト制限と指示の希釈 プロンプトの肥大化は、LLMの注意力を薄れさせ、タスク精 度を著しく低下させます。 車輪の再発明とハルシネーション 計算や正確な手続きをLLMに推論させると、もっともらしい 嘘（ハルシネーション）を語り始めます。 2
3. Skill Creator の革新的なパラダイム 単なるプロンプトから「スキル」へ 私たちは、エージェントへの直接指示という密結 合な開発から、機能ごとに分離された疎結合な『 カプセル化』へと移行します。 機能、実行スクリプト、アセットを1つのディレ クトリにまとめ、必要に応じてエージェントにロ ードさせるのが『スキル』です。 自律的な獲得ループ 人間が詳細なコーディングをすることなく、対話を通じてエー ジェント自身がスキルを設計・構築します。 ポータブルなエコシステム 生成されたスキルは .skill 形式でパッケージ化され、他のエー ジェントに一瞬で配布・インポート可能です。 3
4. 「スキル (Skill)」を構成する4大要素 SKILL.md (振る舞いの定義) トリガー条件、詳細なデザイン原則、注意すべきアンチパ ターンが記述された、エージェントのための『マニフェス トドキュメント』。 scripts/ (オフロードコード) 計算やデータ操作など、LLMが本質的に苦手な手続き型処 理を肩代わりするPythonやJavaScriptなどの実行コード。 references/ (仕様・知識ベース) APIスキーマ、仕様書、ドキュメントなど。通常時はコン テキストを節約し、必要な場合のみエージェントが参照す る。 assets/ (一貫性アセット) テンプレート、静的ロゴ、固定データ、共通フォントなど 、出力物の品質を一貫させるために事前定義されたアセッ ト群。 4
5. 「オンデマンド・ロード」のメリット コンテキスト効率の極大化 エージェントにすべてのスキルを常時記憶させて おく必要はありません。 ユーザーの入力意図を検知した瞬間のみ、特定の スキルフォルダがロードされ、タスク完了ととも にアンロードされることで、コンテキストの圧迫 とコストを最小化します。 ロスト・イン・ザ・ミドルの回避 コンテキストが極限まで絞り込まれるため、LLMの集中力は 『ロードされた特定のルール』にのみ注がれます。 機能の衝突（衝突バグ）の防止 スキル同士の競合が発生しないため、エージェントの挙動が常 に極めてクリーンに保たれます。 5
6. P A R T 0 2 スキル定義 (SKILL.md) の解剖 エージェントの頭脳を規定するドキュメント設計のすべて
7. メタデータ（フロントマター）の設計仕様 YAML形式による厳格な定義 SKILL.md の最上部には、エージェントのメタシ ステムが読み取るための YAML フロントマター を定義します。 ここにはスキルの名前、ライセンス、そして何よ りも重要な『description』が格納され、これがス キルのエントリーポイントとなります。 name: システム識別子 システムがスキルを識別し、フォルダパスや実行権限を関連付 けるためのユニークな小文字のID。 description: トリガー条件 エージェントが『このスキルをロードすべきか』を判定するた めの最重要情報（次のスライドで詳述）。 7
8. 説明文（Description）の極限の役割 トリガー判定の唯一のトリガー description は単なる説明書きではありません。 エージェント自身のシステムプロンプトの最上部 に常にインポートされ、ユーザーの曖昧な指示や ニアミスな要求に対して、このスキルを起動すべ きかどうかのルーティングに使用されます。 「おせっかい」な設計の推奨 ユーザーが直接スキルを指定しなくても、関連するタスク（ typo、ファイル拡張子、カジュアル指示）で自律起動するよう 強気に書く。 非トリガーガードの設定 余計な起動を防ぐため、キーワードが類似していてもロードし てはならない『除外条件』も記述する。 8
9. クイックリファレンスとワークフロー設計 迷わせないためのナビゲーション スキルがロードされた直後、エージェントが最初 に行動すべきルートを規定します。 『どのスクリプトをどの引数で叩くか』『どのド キュメントを真っ先に読み込むべきか』が簡潔な テーブルや箇条書きで示され、エージェントを迷 わせません。 コマンド実行指示の統一 python3 scripts/xxx.py --arg のように、実行コマンドの絶対パ スと必要な引数の形式を明記する。 スキーマへの依存関係定義 scripts実行前に references/ の JSONスキーマでパラメータが 合致しているか確認するルールを敷く。 9
10. デザイン原則とルール（Design Guidelines） 「超おせっかい」な品質の言語化 単にタスクをこなすだけでなく、出力物の『美し さ』や『プレミアム感』を保証するための詳細な 命令群です。 『原色の赤・青・緑は使用せず、洗練されたダー クテーマ配色を用いること』『フォントは Georgiaを使用すること』など、極めて詳細かつ 厳格なルールを書き込みます。 AI Slop (安直な出力) の排除 AIがよく出力しがちな凡庸なデザイン（グラデーション下線や 無駄なアイコン配置）をルールレベルで禁止する。 エッジケースへの対応規定 データにマイナス値がある場合、日本語フォントがインストー ルされていない場合など、エラーを防ぐ先回りルールを記述。 10
11. QA（クオリティ・アシュアランス）の規定 セルフ検証のための自己テスト定義 エージェントがアウトプットを生成した後に、自 律的にそれをダブルチェックするための基準（ア サーション）を規定します。 エージェントは自身で markitdown を実行して出 力にプレースホルダーが残っていないか、文字溢 れがないかを自己チェックします。 検証用コマンドの記述 python3 -m markitdown output.pptx のような、チェックに使 用する検証ツールの起動手順を包含。 ビジュアルアサーションの定義 『文字サイズはタイトルが36pt以上、本文は14pt以上で、重な りがないこと』などの厳格な視覚検証基準。 11
12. SKILL.md のアンチパターンと失敗事例 抽象的な指示のみの記述 『綺麗に可視化してください』といった抽象的な指示は、 LLMの気まぐれな解釈を招き、品質を著しく低下させます 。具体的なフォント、カラー、サイズを指定すべきです。 スクリプト実行手順の欠落 scripts/配下にスクリプトがあっても、SKILL.mdにその使 い方が無ければエージェントは忘れてしまい、自力でプロ グラミングしてバグを生み出します。 エッジケース対策の未記入 空白データや文字化け対策が書かれていないと、特殊なデ ータが入力された瞬間にスキルがクラッシュし、タスク全 体の失敗に直結します。 トリガー条件が弱すぎる description が曖昧だと、無関係なタスク（PDF変換など） で無駄に起動し、エージェントのコンテキストと実行リソ ースを無駄に浪費します。 12
13. P A R T 0 3 支援スクリプトの動作原理 LLMの限界をプログラムコードで超越する技術設計
14. スクリプトの最大の役割：ロジックのオフロード 知性と計算の役割分担 LLMは優れた知性（Contextual Intelligence）を 持っていますが、計算、厳密な手続き、大量デー タのソートなどのロジック（Logical Computation）は本質的に苦手です。 scripts/ 配下のコードは、LLMが一番やりたがら ない『作業』を引き受け、エージェントには『ロ ードと判断』のみを集中させます。 確実性の担保 (Determinism) コード化された処理は常に100%同じ結果を返し、ハルシネー ションの付け入る隙を完全に消し去ります。 パフォーマンスの最適化 PandasやPillow、Sharpなどのネイティブライブラリを直接実 行し、LLMによるテキスト生成よりも何十倍も高速に処理し ます。 14
15. scripts/quick_validate.py の仕様 スキルの文法・構造チェッカー スキル開発の最初の門番として機能するバリデー ションスクリプトです。 SKILL.md が正しい YAML フロントマターを持っ ているか、必須セクション（Quick Reference, QA, Design Ideas等）が存在するかを瞬時にパー スして確認します。 YAML構文エラーの即時検知 フロントマター内のタイポやインデントズレをパースエラーと して検知し、ロード不能になるのを防ぎます。 依存アセットの存在確認 SKILL.md内で指定されているスクリプトファイルが、実際に scripts/ 内に存在するかをマッピングします。 15
16. scripts/run_eval.py の動作メカニズム ダブルラン評価のテストエンジン スキルの真の価値を測定するための、最も重要な テストランナーです。 evals/evals.json に定義された各テストプロンプ トを読み込み、同じ入力に対して『スキルをイン ポートして実行した場合 (with_skill)』と『イン ポートせずデフォルトで実行した場合 (without_skill / baseline)』の2種類を並行実行し ます。 成果物の独立した出力 with_skill/ と without_skill/ の別々のフォルダに生成された成 果物HTMLや画像を出力します。 実行メトリクスのトラッキング 各実行におけるトークン消費量、APIリクエスト回数、所要時 間（ミリ秒）を正確に計測し保存します。 16
17. scripts/aggregate_benchmark.py の集計 定量的なアサーション合否の集計 各ランの完了後、実行されたすべてのテストケー スの結果を統合・集計するスクリプトです。 各ラン配下の grading.json (アサーション合否) と timing.json をスキャンし、最終的なスコアと改 善率（デルタ値）を算出します。 benchmark.json の生成 定量的な通過率、平均実行時間、消費トークンを構造化した JSONファイルを合成します。 benchmark.md の生成 集計データを人間がパッと見て理解できるようにマークダウン のテーブル形式に整形して出力します。 17
18. generate_review.py と eval-viewer 人間中心のビジュアル比較ビューア データ集計が終わると、このスクリプトが超高機 能な HTML ビューア（review.html）を合成出力 します。 このビューアは、ユーザーがブラウザ上で直接 with_skill と without_skill のビジュアル出力を切 り替えて比較し、その場で各ケースにコメントを 書き込めるように設計されています。 スタンドアロン HTML (--static) サーバーを起動しなくても、ブラウザで直接クリックして完璧 に動作する静的HTMLを出力可能。 フィードバックのエクスポート すべてのコメントを集約し、ワンクリックで feedback.json を ダウンロードするクライアントサイドロジックを搭載。 18
19. scripts/run_loop.py の自動化ループ 自己修正ループを回すメインランナー 開発全体のイテレーションを統括するオーケスト レータです。 1. スキルの検証 (quick_validate) 2. テスト実行 (run_eval) 3. ベンチマーク集計 (aggregate_benchmark) 4. 評価ビューア生成 (generate_review) をワンステップで連続実行し、開発ループを完全 に自動化します。 イテレーション管理の自動化 コマンド一発で全テストを再実行し、前回からの改善スコアを 比較出力します。 最適化処理の連動 description の自動最適化プロセスと連携し、最適解が出るま でループを回し続けます。 19
20. scripts/package_skill.py による最終出力 スキルのプロダクション・パッケージ 化 すべてのイテレーションが完了し、アサーション を100%クリアしたスキルをプロダクション環境 用にパッケージングするスクリプトです。 開発用の evals/ やテストデータを綺麗にフィルタ リングし、必要なアセットとコードだけを圧縮し て極めてコンパクトな .skill アーカイブファイル を生成します。 最終クイックバリデーションの連動 パッケージ化の直前に、再度 quick_validate を自動実行し、破 損が無いことを再確認する安全設計。 クリーンなポータビリティ 余分なテストファイルを排除し、エージェントが即座にパース できるクリーンなファイル構成を保つ。 20
21. P A R T 0 4 評価・イテレーション・最適化 ループ AIが自己評価し、自らをアップデートし続ける設計のすべて
22. テスト仕様 evals/evals.json の設計 評価基準の明文化と構造化 エージェントが正しく動作したかを判定するため の、テストケースの設計図です。 テスト用プロンプト、入力用データファイルのパ ス、期待される出力ファイル名、および合否を分 ける複数の『assertions』を配列形式で定義しま す。 多様なデータのインプット定義 時系列、多次元カテゴリ、アンケートなど、スキルの対応範囲 を網羅する異なるファイルを指定。 評価アサーションの定義 『〇〇という要素がHTML内に含まれていること』など、検証 可能な具体的な基準を記述。 22
23. アサーションによる「客観的測定」の科学 感覚的評価から定量的測定へ 『なんとなく綺麗』という感覚的な評価では、ス キルの継続的な改善は不可能です。 アサーションは、生成された成果物ファイルをプ ログラム的にパースし、指定された正規表現やタ グ、スタイル記述が含まれているかを客観的にジ ャッジします。 自動合格率 (Pass Rate) の算出 全アサーションに対する合格率を算出し、スキル適用による品 質の絶対的な差を定量化。 デグレーション（品質後退）の即時検出 スキルの一部を修正したことで、別のテストケースが動かなく なるデグレーションを即時発見。 23
24. 人間中心フィードバック (feedback.json) の力 人間の感性をAIのコンテキストに繋ぐ アサーションだけでは判定しきれない『デザイン の高級感』や『レイアウトの使いやすさ』は、人 間が評価ビューアに書き込みます。 エクスポートされた feedback.json は、エージェ ントのコンテキストに再装填され、AIが『何を修 正すべきか』の最も強力な指針となります。 定性データの定量データ化 人間のレビューコメントをJSON形式で構造化し、LLMが確実 に理解・処理できるデータ形式に変換。 意図のギャップの解消 仕様書の行間にある『人間の本当の望み』を、対話を通じてス キル定義に正確に反映させます。 24
25. メタプログラミングによる「自己修復 (Self- Correction)」 AIみずからが脳（SKILL.md）を書き 換える エージェントは feedback.json を読み込むと、エ ラー箇所や改善要望を自律的に分析します。 そして、自分自身の行動指針である『SKILL.md 』のデザインルールを追加・改訂したり、 scripts/ のバグを自分で修正して再コンパイルし ます。これが自律的な自己修復ループです。 人間の介入コストの最小化 人間はビューアに感想を書き込むだけで、コードの修正やドキ ュメントの改訂はAIがすべて裏で完了。 知能の漸進的進化 ループを回すごとにスキル定義が洗練され、エージェントの処 理精度は対数曲線を描いて向上します。 25
26. トリガー説明文の最適化アルゴリズム run_loop.py による自動説明文最適化 スキルのdescriptionを最適化するために、テスト 用の仮想クエリ群を使用します。 『起動すべきクエリ（should-trigger）』と『起 動してはならないクエリ（should-not-trigger） 』をそれぞれ10個程度用意し、エージェントが description の微調整を繰り返しながら、トリガ ー成功率100%を目指してテストを回します。 過学習の防止 (Generalization) 特定のキーワードだけでなく、類義語や意図の揺らぎに対して も強固に反応するように説明文を汎用化。 ニアミス検知の精緻化 類似した無関係なタスクを弾くガード条件（not trigger）を自 動で説明文に組み込みます。 26
27. パッケージ化と配布エコシステム (.skill) プロダクション環境への即時インポート 完成した .skill ファイルは、他のユーザーのエージェントに ロードするだけで、そのエージェントの『システム能力』 として即座に追加されます。 機能の衝突を完全に防止 各 .skill は完全に独立したネームスペースとフォルダを持つ ため、他のスキルやシステムの設定を汚すリスクがゼロで す。 アセットのパッケージング 実行スクリプトだけでなく、一貫性を保つためのフォント 、ロゴ、テンプレートが同梱されており、インポートした エージェントはどこでも同じ高品質な出力を生成できます 。 バージョニングと再現性 検証されたテストケースとアサーション情報が含まれてい るため、異なる環境でもスキルが同じ品質で動作すること を保証・再現できます。 27
28. P A R T 0 5 結論 ＆ エージェント開発の未 来 指示から進化する知性へ：新たなソフトウェアパラダイム
29. エージェント開発のネクストステージ 静的プロンプトから動的エージェント へ これまでの開発は、人間が長大なシステムプロン プトを固定して与える『静的』なものでした。 Skill Creator は、エージェント自身が新しいスキ ル（能力）を必要に応じて自律獲得し、自己学習 ・自己修正し続ける『動的』な知性のステージを 切り拓きます。 知能のオンデマンド構成 タスクに応じて、その場で最適な知能構造をモジュール式に組 み立てる能力。 成長し続けるシステム 使えば使うほど、フィードバックによってスキル定義が洗練さ れ、エラー率が下がっていく成長型AI。 29
30. 開発者（人間）の新しい役割の定義 コーダーから意図のデザイナーへ 人間はもはや、1行ずつのコードや長大な命令を 書く作業に時間を費やす必要はありません。 人間の最も重要な役割は、エージェントが目指す べき『ゴール（意図）』を明確にし、それを厳格 に検証するための『アサーション』をデザインす ることにシフトします。 ゲートキーパーとしての人間 AIが生成したビジュアルやコードの最終的な良し悪し（品質・ ブランド感）を感覚的にジャッジする。 ハイレベルな要件定義 『何が起きるべきか』『何をしてはならないか』というシステ ム境界（境界条件）を設計する役割。 30
31. 協調的知性 (Collaborative Intelligence) の未来 人間とAIのハイブリッド共生システム Skill Creator が示す未来は、AIによる人間のリプ レイスではありません。 人間が『魂（感性と意図）』を吹き込み、AIが『 手足（コードとドキュメンテーション）』を動か し、対話を通じて共にソフトウェアを成長させる 、究極の協調的開発パラダイムです。 自律的な進化スピード 手動開発に比べ、イテレーション速度が何十倍も向上し、アイ デアから実装までの時間が極限まで圧縮される。 信頼性の高いシステム共創 アサーションとコードオフロードにより、大規模AIシステムで も極めて堅牢でバグのない設計を共創可能に。 31
32. Skill Creator 技術設計の総括 ① カプセル化による絶対的信頼性 SKILL.mdとscriptsを結合し、必要な時にだけロードするオンデマンド・アーキテクチャが、コンテキスト希釈 と命令衝突を完全に防ぐ。 ② 客観的アサーションと人間中心ビューア 定量的テスト（evals.json）と人間の定性的フィードバック（feedback.json）を評価ビューアでシームレスに結 合し、確実な改善のコンパスとする。 ③ メタプログラミングによる自律的な自己修正 人間がレビューするだけで、AI自身がSKILL.mdのデザイン原則や実行コードを自動修正し、クオリティを対数 曲線的に成長させる。 32