OmniludeにAgent Skillを組み込んでみる

はじめに

以前、SkillとAgent Workflowを紹介する記事を書きました。

その記事を読み返しながら、スキルがAIチャットに結び付くとかなり便利そうだと感じました。

今回の記事は、その考えから始まった実装記録です。SkillをClaude CodeやCodexのようなツールの中から取り出し、Agentが実際の作業フローの中でSkillを呼び出して使えるようにしたとき、何が変わるのかを試してみます。うまくいけば、比較的軽いLLMでも少しずつJarvisに近づけるかもしれません。

Skillを一文で説明すると

いちばん短く言えば、skillとは エージェントに特定の仕事を、繰り返し可能な順序と基準で処理する方法を教えておく作業パッケージ です。

Anthropicの公開ガイドでも、skillはSKILL.mdを中心に、必要に応じてscripts、references、assetsを持つフォルダとして説明されています。重要なのは見た目ではなく原理です。毎回すべての知識を丸ごとプロンプトに押し込むのではなく、必要な瞬間にだけskill本体と参照ファイルを段階的に開かせます。

これは思った以上に重要です。汎用エージェントは賢いですが、反復作業の前ではぶれやすくなります。同じリポジトリ、同じ作業、同じ依頼であっても、トーンや構成、抜け漏れのポイントが変わることがあります。skillはそのぶれを減らすための装置です。

ここで私が特に重視している原則は三つあります。ひとつ目は、必要なときにだけ深い文書を開くprogressive disclosureです。ふたつ目は、ひとつのskillが全部を解決しようとせず、ほかのskillと組み合わせて動くcomposabilityです。みっつ目は、特定の画面や特定のツールに縛られないportabilityです。

実装中のSkillチェーン

私のローカルリポジトリでは、.codex/skills配下に25個のskillがあります。文書生成、API実装、バックオフィスCRUD、SSE、ストーリーパイプライン、翻訳、レビュー、コミットなど、繰り返し発生する作業をそれぞれ分担しています。.agents/skillsには、別のsurfaceでも再利用しやすいように同じカタログをそろえています。

そして、いつもClaude Codeの話をしているのに急にCodexが出てくる理由もあります。最近、韓国ではKakao経由でOpenAI Proにほぼ90%水準の割引イベントがありました。よい機会だったので、今はCodexへ切り替えています。

本題に戻ると、私がよく使う軸はかなり明確です。prd-generatorは要件を受け取って文書ルールに合ったPRDを作り、endpoint-implement-skillはEntityからControllerまでの実装パターンを固定します。必要ならfrontend-task-handoverがフロントエンド向けの引き継ぎ文書につながり、branch-reviewが最後に回帰やリスクを見直します。

つまり私は、skillを個別機能よりもチェーンとして見ることのほうが多いです。

実際、CLAUDE.mdには作業タイプごとにどのskillを優先的につなぐかまで書いてあります。たとえばAPI開発はprd-generator -> endpoint-implement-skill -> frontend-task-handover、バックオフィス開発はprd-generator -> backoffice-crud-skill -> frontend-task-handoverという流れです。ここまで来ると、skillは単なる補助機能というより、作業運用のルールに近いものになります。

面白いのは、この記事自体も同じ哲学の上に立っていることです。今使っているblog-post-writer skillは、ブログカテゴリ、reading time、tone、excerptの長さ、canonical URL、サムネイル用プロンプト、import JSONスキーマまで一度にそろえるように設計されています。文章を書くことさえ、もはや感覚だけではなく、再利用可能な出力形式として束ねられているわけです。

スキルとアシスタント

製品の中に入ったskillは、もはやSKILL.mdひとつだけでは説明できません。current-weather-checkerの詳細ブループリントを基準に見ると、実際のskillは説明文や参照文書だけでなく、実行コード、メタデータ、ネットワークポリシー、トリガー戦略まで束ねたランタイム単位に近いものです。だから私は今、skillをフォルダ構造ではなく、何が保存され、何が実行され、どうアシスタントに接続されるかまで含めて見るようになりました。

スキル構造のオーバービュー

current-weather-checkerのブループリントをたどると、skillの実体は見た目以上に立体的です。画面で最初に見えるのは名前と説明ですが、その裏にはInstructions、Scripts、References、Assets、Metadata、Runtime Policyがまとまっています。この構成があるからこそ、あるskillは文脈だけを補強し、あるskillはsandboxで直接実行され、あるskillは外部ネットワークまで安全に制御できます。

要するにskillは、単なるプロンプトファイルではなく、説明テキスト + 実行リソース + 運用ポリシーをまとめた定義オブジェクトに近い存在です。特にscript skillでは、networkPolicyやallowedDomainsのような実行ポリシーが実際の権限を決めます。bodyだけ読んでも、そのskillが本当に何をできるのかは最後までわかりません。ブループリント文書が役立つ理由もそこにあります。画面の裏にある構造を一度で復元してくれるからです。

アシスタント連携のオーバービュー

次の段階で重要なのはskillそのものより、誰がそのskillを所有し、どんな条件で呼び出され、選択後にどの経路で実行されるかです。Omniludeの構造では、skillはagentに緩くぶら下がるのではなくassistantにマッピングされ、orchestratorがそのマッピングとtrigger情報を読んで実際の実行経路を決めます。実行型skillはsandbox側へ流れ、context-onlyなmaterialは最終応答プロンプト側へ流れます。

分離された実行環境

実行型skillのスクリプトは、assistantプロセスの中で直接動きません。AssistantSkillScriptExecutorがsandbox-bridgeを通じて別のsandbox podに実行を委譲し、スクリプトはその分離された環境でstdin JSONを入力として受け取り、stdout JSONを結果として返します。この構造によってassistant本体と実行コードを分離でき、networkPolicyとallowedDomainsで外部アクセス範囲も一緒に制御できます。

簡単に言えば、assistantは何を実行するかを決め、sandboxはその実行を安全に処理する場所です。skillが増えるほど、この分離は重要になります。実行失敗を隔離でき、ネットワーク権限を細かく分けられ、あとからどのscriptがどのポリシーで動いたかも追跡しやすくなるからです。

この流れで見ると、skillはassistantの付属文書というより、assistantが必要なときに選択して実行するモジュールに近い存在です。だからattached skillが強くなるほど大切なのは、どれだけ長い説明を書くかではなく、mapping、trigger、execution、observabilityをどれだけ明確に設計するかです。結局、よいskillとは、よく書かれた文書一枚ではなく、assistantが安定して呼び出せるよう構造化された実行面だと言うほうが正確です。

まとめ

2026年2月18日のworkflow記事がエージェントがどう流れるかを説明するものだったとすれば、今回の記事はその流れをskillという構造でどう固定できるかについての話です。

Skillは魔法のようなオプションではありません。それでも、個人やチームの反復作業を減らし、作業標準、参照文脈、出力形式、実行経路をひとつの単位に束ねるうえでは、かなり強力な道具です。

次は、このskillとassistantの組み合わせが実際のエージェント体験をどう引き上げるのか、実装と運用の両面からもう少し具体的な事例を持ってきたいと思います。