先週 Tenkai について書いたとき、実験分析に関する重要な側面に触れませんでした。それは、実験からどのように洞察を抽出するかということです。要約や統計的指標、テストを備えた素晴らしい frontend があるとはいえ、単なる要約から各設定のニュアンスを捉えるのは非常に困難です。
たとえば、読み取り操作（例：read_file や godoctor の smart_read）は、失敗したか、完了までに時間がかかったシナリオと強い相関関係があることに頻繁に気づきます。これは読み取り操作が悪いからでしょうか？いいえ、これはエラーから回復するために、エージェントがコードを再度読み込んでソースコードの知識を更新しなければならなかったためです。つまり、読み取りと遅さや失敗の間には強い相関関係がありますが、これは決して因果関係ではありません。統計学者が言うように、「相関関係は因果関係を意味しない」のです。
ここ数週間、多くの実験を行ってきた中で、毎回モデルに深い分析を行うよう教えるのはあまり効果的ではないとすぐに気づきました。通常、このようなシナリオでは、agent context（GEMINI.md 経由）に分析指示を追加するか、必要な prompt を MCP server に保存して slash commands にマッピングするかのどちらかを行います。
どちらの方法も機能しますが、それぞれに制限があります。実行したいすべてのタスクについて agent context を拡張すると、context bloat（コンテキストの肥大化）が発生し、動作の効率が低下します。各 prompt に対して slash commands を作成する場合、エージェントは設計上それらを認識していないため、私が明示的にコマンドを呼び出す必要があります。
幸いなことに、Agent Skills は両方の力を組み合わせた解決策を提供します。Agent Skills は Gemini CLI の新機能で、エージェントにオンデマンドの能力を与えるように設計されています。これは agent tool と同様に動作します（実際、skill は tool call によってアクティブ化されます）が、skill は prompt とサポートファイルへのオンデマンドアクセスを可能にし、エージェントが必要なときだけコンテキストに置いて専門的なタスクを実行できるようにします。
完全な技術仕様は公式ドキュメントにありますが、この記事では、使い始めるための基本について説明します。
スキルの解剖学#
スキルとは、プロンプトと、オプションでドキュメントやスクリプトなどのサポートファイルを含むフォルダに過ぎません。
my-skill/
├── SKILL.md (必須) 指示とメタデータ
├── scripts/ (オプション) 実行可能なスクリプト/ツール
├── references/ (オプション) 静的ドキュメントと例
└── assets/ (オプション) テンプレートとバイナリリソース
SKILL.md ファイルは、スキルの prompt が存在する場所です。スキルの名前と説明を定義するための小さな frontmatter がありますが、それ以外は通常のマークダウンファイルです。
---
name: <一意の名前>
description: <スキルが何をするか、Gemini がいつそれを使用すべきか>
---
<エージェントがどのように振る舞うべきか / スキルをどう使用すべきかについての指示>
プロジェクトにスキルを追加するには、.gemini/skills の下にフォルダを作成します。たとえば、上記の my-skill は .gemini/skills/my-skill に配置されます。Gemini CLI は、以下の優先順位でスキルを自動的に検索します。
- Workspace (<プロジェクト名>/.gemini/skills)
- User (~/.gemini/skills)
- Extensions (~/.gemini/extensions/<拡張機能名>/skills)
重要な点は、Gemini CLI が起動したとき、それはスキルの名前と説明しか認識していないということです。それ以外のすべては、スキルがアクティブ化されたときにオンデマンドで読み込まれます。
では、実験分析ワークフローを改善するために、私がどのようにスキルを使用しているかを見てみましょう。
experiment-analyst スキル#
私は experiment-analyst スキルを、Gemini CLI に実験を評価するよう依頼したときにアクティブ化されるように設計しました。次のように構成されています。
experiment-analyst/
├── SKILL.md <-- 分析ガイドライン
├── references/
│ └── tenkai_db_schema.md <-- データベーススキーマ。エージェントが毎回発見する必要がないようにする
└── scripts/
├── analyze_experiment.py <-- frontend で行っている分析の一部を再現する
├── analyze_patterns.py <-- 一般的なパターンを深掘りして洞察を抽出する
├── get_experiment_config.py <-- 実験設定の詳細を取得する
└── success_determinants.py <-- ツール呼び出し分析と相関関係
専門家のペルソナを定義する#
SKILL.md ファイルは分析手順を定義します。エージェントに何をすべきかを教えつつ、単純な「画一的（cookie-cutter）」な方法にならないようにバランスを取ろうとしています。重要な側面の一つは、エージェントが結論に飛びつくのを防ぎ、より地に足の着いたペルソナを定義することです。私は依然としてすべての主張を検証し、すべての結論を話半分に聞いていますが、このバージョンは、そうでなければ発見するのに多大な労力を要したであろう興味深い洞察を提供してくれました。
---
name: experiment-analyst
description: Tenkai エージェント実験の分析における専門知識。「実験 X を分析して」と依頼されたときに、成功要因、失敗モード、行動パターンを決定するために使用します。
---
# Experiment Analyst
## Core Mandates
1. **Evidence-Based:** データなしに主張を行わないこと。特定の Run ID を引用すること。
2. **Correlation ≠ Causation:** ツール（例：`read_file`）は回復に使用されるため、失敗と相関している可能性があります。常に使用の*コンテキスト*を調査すること。
3. **Comparative:** 常に代替案のパフォーマンスを対比すること。
スキルのアセット#
今後数週間、私がこれについて多く話すのを聞くことになるでしょうが、本質的に非決定論的なエージェントを扱う場合、品質を保証する唯一の方法は、彼らに決定論的なツールを与えることです。スキルはこの哲学によく適合します。なぜなら、エージェントにどのように行われるかを「推測」させるのではなく、一貫した方法でタスクを実行するためのスクリプトをバンドルできるからです。
実験分析スキルのために、私はエージェントに探索の自由を持たせたいと思いましたが、同時に毎回車輪の再発明をしてほしくないとも思ったので、いくつかの事前にパッケージ化されたスクリプトを同梱しました。
analyse_experiment.py: frontend にあるものと同様の実験サマリーを再現しますが、シェルコマンドの tool call におけるいくつかのグループ化を含みます。analyse_patterns.py: ツール使用パターンを特定するために、エージェントの会話からサンプルを抽出します。get_experiment_config.py: 実験の定義を取得することで、エージェントが実験を理解するのを助けます。success_determinants.py: 成功した結果と tool call の間の相関関係を計算します。
エージェントがアドホックなクエリを行うことを決定した場合のために、references/tenkai_db_schema.md でデータベーススキーマを提供しています。これにより、エージェントは毎回スキーマを再発見する必要がなくなります（このスキーマは実行間でかなり安定しています）。
この設定が完璧だとは言いません。洗練させるのにそれほど時間をかけていないからです。しかし、この情報の組み合わせと事前にパッケージ化されたスクリプトは、私が通常エージェントに探索を依頼する質問のほとんどをカバーしています。
おわりに#
Agent Skills は、エージェントワークフローを設計する方法における重要なシフトを表しています。巨大でモノリスなシステムプロンプトから、モジュール式でオンデマンドな機能へと移行することで、私たちは一度に2つの問題を解決します。エージェントのコンテキストをクリーン（かつ安価！）に保ち、一般的なパフォーマンスを低下させることなく、深く専門化された専門知識を可能にするのです。
私にとって、experiment-analyst スキルはゲームチェンジャーでした。これは、退屈で反復的なデータ処理タスクを、「なぜこの実行は失敗したのか？」「成功した試みにパターンはあるか？」といった高レベルの質問をし、証拠に裏付けられた回答を得ることができる動的な会話へと変えました。そして、重い処理は決定論的な Python スクリプトによって行われるため、エージェントの物語を合成する能力を楽しみながら、数学的な結果を信頼することができます。
このモジュール性は、共有への扉も開きます。kubernetes-debugger スキルをリポジトリにドロップしてチームがポッドのトラブルシューティングを行えるようにしたり、特定の frontend スタックをチェックする方法を正確に知っている accessibility-auditor スキルを使用したりすることを想像してみてください。私たちは実質的に、誰もが使用できるペルソナをパッケージ化しているのです。
コミュニティが何を構築するのかを見るのが楽しみです。ぜひ、あなた自身のワークフローを見直してみてください。常に同じ指示を繰り返している場所はどこですか？専門家が必要な場所はどこですか？それが、次に書かれるのを待っているあなたのスキルです。
Happy coding!