AIエージェントのプロンプトや実行手順(本稿では「スキル」と呼ぶ)を自動で最適化する試みにおいて、従来の「実行ログを直接スキルにフィードバックする」手法には、スキルの肥大化や一時的な知恵の埋没という限界があった。
Googleリサーチが発表した「WikiSkill」は、スキル(手続き的知識)と実行ログの間に「Wiki(知識ベース)」を仲介させることで、この課題を解決する。本アーキテクチャは、実行ログから失敗・成功のパターンを抽出してWikiに蓄積し、それを基に別のエージェントがスキルを提案・更新する。これにより、手続き的知識と教訓(パターン)の「関心の分離」を実現し、実務タスク(スプレッドシート操作やWeb検索検証など)において高い精度改善効果を示している。
![[WikiSkill]AIエージェントの自己進化](https://s.wordpress.com/mshots/v1/https%3A%2F%2Farxiv.org%2Fpdf%2F2608.27454?w=320&h=180)
事象の背景と構造
従来のスキル更新アプローチとその限界
CursorやClaude Code、CodexといったAIツールを実務で運用する際、実行ログ(`sessions`フォルダ内のJSONL等)は自動的に蓄積される。従来、これらのツールや自作のAIエージェントにおいて、スキルを改善するアプローチは以下のいずれかであった。
- 直接的なフィードバックの追記: 失敗が発生するたびに、スキルのプロンプト(例: `Gotchas`(おとし穴)セクションなど)に直接「〜をしないこと」といった指示を追記する。
- 人間による都度の修正: 実行時の失敗を人間が検知し、その都度プロンプトを手動で書き換える。
しかし、これらのアプローチにはシステム設計上、以下の致命的な課題が存在する。
- スキルの肥大化(大化): 失敗事例や個別具体的な対策をスキル定義ファイルに書き込み続けると、プロンプトのコンテキストが肥大化し、モデルの処理効率や指示追従性が低下する。
- 知恵の埋没と忘却: 実行時の成功・失敗から得られた「右足から強く蹴る」といった手続き上の本質的な教訓(パターン)が、ログの山に埋もれるか、次回の実行時に引き継がれずに忘れ去られてしまう。
- フィードバックの不完全性: すべての失敗や成功の要因を、人間が毎回適切に分析してスキルに反映することは運用上不可能である。
![[WikiSkill]AIエージェントの自己進化](https://mtoy.work/develop/wp-content/uploads/sites/3/2025/06/AI_usage_methods-160x90.jpg)
コアとなる技術的仕組みの解説
WikiSkillの核心は、「手続き的知識(スキル)」と「教訓・パターン(Wiki)」を分離して管理するマルチエージェント・アーキテクチャである。
WikiSkillの全体アーキテクチャ
システムは以下のコンポーネントと、役割が明確に分離された複数のサブエージェントによって構成される。
[AIエージェント (スキル実行)] ──> [実行ログ (sessions.jsonl等)]
│
▼ (週次などの定期実行)
[Wikiメンテナー・エージェント]
│
▼ (失敗・成功パターンの抽出)
[Wiki (patterns/Pxxx.md)]
│
▼ (現在のスキル・ログ・Wikiを分析)
[スキルプロポーザー・エージェント]
│
▼ (新スキルの提案)
[評価 (人間 or 評価エージェント)]
│
▼ (承認: Accept)
[スキル・Wikiのアップデート]1. フォルダ構造の設計
論文で示されている推奨されるディレクトリ構成は以下の通りである。
- `skills` フォルダ: スキルの実体を定義するファイル(例: `paths.md` などのMarkdown形式)。
- `wiki` フォルダ:
- `patterns` フォルダ: 抽出された失敗・成功のパターン(例: `P001.md` など)。
- `logs.md`: 動作ログの要約。
- `skill_impact.md`: スキル更新による影響や評価スコアの記録。
2. サブエージェントによる自律的更新サイクル
- ログの蓄積: メインのAIエージェントがスキルを実行し、その詳細なプロセスがログとして保存される。
- Wikiのメンテナンス(Wiki Maintainer):
- 定期的なスケジュール(例: 週に1回)で「Wikiメンテナー」エージェントが起動。
- 蓄積されたログを分析し、例えば「同様のミスが4件発生している」といった事象から共通の失敗パターンを抽出する。
- 抽出したパターンをWiki(`patterns`フォルダ内)にドキュメント化して書き込む。
- スキルの提案(Skill Proposer):
- 「スキルプロポーザー」エージェントが、現在のスキル定義、Wikiに蓄積されたパターン、および直近のログの3点をインプットとして受け取る。
- これらを総合的に分析し、既存のスキル定義をどのように修正すべきか(新スキル)を提案する。
- 評価と承認:
- 提案された新スキルを、人間または別の評価エージェントが検証する。
- 評価スコア(例: 0.72はリジェクト、0.78はアクセプトなど)に基づき、承認された場合のみ実際のスキル(`paths.md`等)とWiki(`skill_impact.md`等)に反映・更新する。
![[WikiSkill]AIエージェントの自己進化](https://mtoy.work/develop/wp-content/uploads/sites/3/2025/09/china-ai-qwen-kimi-threat-160x90.jpg)
今後の影響と論点
1. 実務タスクにおける高い改善効果
本手法は、抽象的なベンチマークにとどまらず、エンジニアの実務に極めて近いタスクにおいて顕著な効果を発揮する。特に以下のタスクで高い精度向上が確認されている。
- スプレッドシートの操作: 複雑な構造を持つデータの処理やAPI連携。
- Web検索を伴う長文質問への回答精度検証: 外部情報の探索と論理構成。
2. 「関心の分離」がもたらすメンテナンス性の向上
LLMのモデル自体がアップデート(例: GPT-4から次世代モデルへ)された際、プロンプトに記述すべき最適な指示の粒度やフォーマット(「指示は簡潔にする」「特定の記法を使う」など)は変化する。
WikiSkillの設計では、「得られた教訓(Wiki)」と「具体的なプロンプト記述(スキル)」が分離されているため、モデルの変更に伴ってスキル(プロンプト)の書き直しが必要になっても、蓄積されたWiki(知識ベース)側はそのまま再利用できる。この疎結合な設計は、プロダクション環境における長期的な運用コストを大幅に引き下げる。
3. 開発プロセスへの組み込み
本アーキテクチャは、論文内に「メンテナーエージェント」や「スキルプロポーザー」の具体的なシステムプロンプトが公開されているため、実装のハードルは低い。
開発者は、Claude CodeやCursorなどのLLMツールに対し、この論文情報と自身のプロジェクトのフォルダ構造(Obsidianのナレッジベースなど)をコンテキストとして与えることで、自己進化型のスキル管理システムを自律的に構築させることが可能である。
コメント