【神改造Skills】AIエージェントを動かす「オーケストレーションスキル」の設計法
今回はAIのスキルを神改造した「オーケストレーションスキル」のお話です。CodexやClaude Codeを使っている人は、よかったら参考にしてみてくださいね。
オーケストレーションスキルとは、通常の単体スキルを複数組み合わせてワークフローとして指揮するAIスキル(Skills)を指します。
👇作成した時のログ

このスキルで複数のスキルを操りまくります!
このようにすることでAIエージェント構築で指揮能力や改善能力、トークン効率が上がるため、AIエージェントのワークフローにご興味がある方は、ぜひ最後までご覧ください。
前回のSkills魔改造は、AIのスキルを全部外して遠隔に置きスキルフォルダにはルータースキル一つのみにしました。
このルータースキルとオーケストレーションスキルを組み合わせると、最強のAIエージェントスキルとなるでしょう。
【関連動画】
いいね・チャンネル登録していただけると嬉しいです🍀
オーケストレーションスキルは「演奏者」ではなく「指揮者」

オーケストレーションスキルの役割は、機能を抱えることではありません。専門スキル同士の関係を定義し、一つの仕事として成立させることです。
オーケストラに置き換えると分かりやすいでしょう。指揮者は、自分でバイオリンや打楽器を同時に演奏しません。それぞれの演奏者が専門性を発揮できるように、開始のタイミング、順番、強弱、全体のゴールを示します。
AIエージェントでも同じです。
単体スキル:一つの専門作業を高品質に実行する
オーケストレーションスキル:単体スキルの順番と受け渡しを管理する
ルータースキル:依頼に合うスキルやワークフローを探して選ぶ
ユーザー:ゴール、品質、公開範囲、承認条件を決める
オーケストレーションスキルへ必要なのは、主に次の情報です。
最終的に何を完成させるか
どの単体スキルを使うか
どの順番で呼び出すか
前工程から次工程へ何を渡すか
途中で何を確認するか
どの状態で人間へ戻すか
文章の書き方、画像の生成方法、ブラウザの細かな操作手順まで重複して書く必要はありません。それらは担当する単体スキルの責任です。
動画内では、この設計がMixture of Expertsに似ていると説明されています。ただし、これは実装方式が同じという意味ではなく、「専門家を必要な場面で組み合わせる」という設計上の比喩として捉えるのが適切です。
巨大スキルを分割すると改善しやすくなる

一つの巨大スキルへ機能を集めると、最初は便利に見えます。しかし、運用を始めると問題が表面化します。
第一に、同じ機能を二重管理しやすくなります。記事執筆の細則を単体スキルとオーケストレーションスキルの両方へ書けば、片方だけを更新したときに指示が競合します。
第二に、修正範囲が広がります。サムネイルの品質だけを改善したいのに、動画、音声、投稿、記事の指示まで含む巨大ファイルを確認することになります。
第三に、トークン消費が激しくなります。巨大なファイルを更新しようとすると、一旦そのテキストを全て読み込むので、そこでトークンを多く消費します。しかし、オーケストレーション式にすると、修正は単体で読み込むため、トークン消費を抑えることができるのです。
Agent Skillsのベストプラクティスでも、過度に包括的なスキルは、エージェントが必要部分を取り出しにくくなる可能性があると説明されています。核となる指示を簡潔にし、詳細を必要時に参照する構成が推奨されています。
分割の基準は「一つの成果を独立して評価できるか」です。
市場調査レポートを作る
ペルソナを定義する
動画台本を作る
音声を生成する
サムネイルを作る
投稿用の概要欄を作る
note向けMarkdown記事を書く
それぞれを単独で実行し、単独で品質判定できるなら、単体スキルの候補になります。オーケストレーションスキルは、それらを「市場調査→ペルソナ→戦略→広告→効果測定」のような仕事の流れへ変換します。
公式資料によれば、Codexは最初に各Skillの名前と説明を使い、選択後に本文を読みます。したがって分割には、保守性と再利用性の利点がある一方、名前と説明が曖昧なスキルを大量に作ると選択が難しくなります。細かく分けるだけではなく、適用条件と境界を明確にすることが重要です。
作り方の核心は「ゴールから逆算する」こと

オーケストレーションスキルは、使いたいツールを並べるところから作るのではありません。最終成果物から逆算します。
動画内の実践では、「動画を作り、公開準備を整え、その内容をnote記事へ展開する」というゴールが先にありました。そこから必要な専門工程を洗い出し、個別に試し、成功した手順をスキル化し、最後に一つのワークフローへ接続しています。
実務では、次の順番で作ると安定します。
1. 完成状態を定義する
「動画を作る」のような曖昧な目標ではなく、成果物と停止条件を決めます。
たとえば、動画ファイル、サムネイル、タイトル、概要欄、クレジット、チャプター、Markdown記事を所定の場所へ保存し、YouTubeとnoteでは公開直前に停止する、と定義します。
2. 専門工程へ分解する
成果物を作るために必要な能力を、独立して検証できる単位へ分けます。この時点で既存スキルを棚卸しし、不足している部分だけを新設します。
3. 単体で成功させる
各工程を一度実行し、品質、所要時間、権利表記、保存場所を確認します。失敗する単体スキルを連結しても、失敗が見えにくくなるだけです。
4. 入出力を明文化する
各工程が何を受け取り、何を返すかを決めます。動画台本から音声へ何を渡すのか、動画から記事へは文字起こし、要点、リンクのどれを渡すのかを明確にします。
5. 順番と確認点だけを記す
最後に、単体スキル名、実行順、受け渡し、品質確認、停止条件を小さなオーケストレーションスキルへまとめます。
ここで重要なのは、単体でも発火でき、全体でも発火できる命名と説明です。「市場調査して」なら市場調査スキルだけを使い、「マーケティング施策を一式作って」なら全体ワークフローを使う、と区別できる説明が必要です。Codexでも暗黙のSkill選択は`description`に依存するため、公式ガイドは用途と境界を明確に書くよう勧めています。
スキルトレーニングは失敗ログを「手順」に変える

一度動いたスキルが完成品とは限りません。実際の運用では、AIが同じ場所を何度も行き来したり、人間なら簡単な画面操作に時間を使ったり、クレジット表記を忘れたりします。
動画では、この改善活動を「スキルトレーニング」と呼んでいます。
考え方は単純です。
スキルを実行する
失敗、迷い、長時間停止、重複作業を記録する
なぜ時間がかかったかを振り返る
正しい操作や判断基準を言語化する
担当する単体スキルだけを更新する
同じ条件で再実行する
たとえばnoteの目次作成で、AIが本文中に手入力の目次を書いてしまったとします。この場合、「目次を入れる」とだけ書くのではなく、プラットフォーム上の追加ボタンから目次機能を選ぶ、と具体化します。
また、投稿画面の中で本文を何度も修正して時間を使うなら、Markdownを正本として先に完成させ、投稿画面には完成稿を一度だけ貼り付ける手順へ変えます。AIが得意なファイル編集と、苦手になりやすい画面内の細かな修正を分離するわけです。
動画内の試行では、動画から記事までの一連の処理に43分かかり、特に記事の修正工程で迷いが発生したと報告されています。最終的な成果物は完成したものの、所要時間と反復ログから改善点が見つかりました。これは一般的な性能値ではなく、その環境と手順における実践例です。
改善対象は、原則として問題を起こした単体スキルです。記事作成が遅いなら記事スキル、アップロードでクレジットが抜けるならアップロードスキルを直します。順番や受け渡しに問題がない限り、オーケストレーションスキルまで書き換える必要はありません。
ルーターと組み合わせて「探す」と「動かす」を分ける

スキルが増えると、オーケストレーションだけでは別の問題が生まれます。どの単体スキルやワークフローを使うべきかという選択問題です。
そこで、前回の階層型ルーターと今回のオーケストレーションを組み合わせます。
ルーター:依頼を分類し、必要なスキルやワークフローを探す
オーケストレーター:選ばれた複数スキルを正しい順番で動かす
単体スキル:専門作業を実行する
品質ゲート:各工程の出力を確認し、失敗時に止める
「探す」と「動かす」を分けることで、ルーターは実行手順を抱えず、オーケストレーターは全スキルの探索を抱えません。それぞれの責任が明確になります。
ただし、長いワークフローほど権限と失敗の影響も大きくなります。次の点は必ず設計してください。
公開、送信、購入、削除は人間の承認前で止める
各工程の成果物を保存し、途中から再開できるようにする
同じ処理を繰り返さない再試行上限を決める
外部サービスの利用規約とクレジット条件を確認する
実行時間、失敗地点、読んだファイルを記録する
環境ごとに利用できるツールと代替手段を分ける
オーケストレーションスキルの価値は、AIへ長い仕事を丸投げすることではありません。大きな仕事を観測可能な小さな工程へ分け、成功した能力を再利用し、失敗した部分だけを直せるようにすることです。
最初から動画制作から公開までの巨大ワークフローを作る必要はありません。まず二つか三つの単体スキルを接続し、各工程に一つの品質確認を置きます。動作ログを見て、迷いを具体的な手順へ変えます。その小さな循環を重ねることで、単なる自動化ではなく、自分の仕事に合わせて育つAIエージェントへ近づいていきます。
【プロフィール】
ワンダー・佐藤源彦(さとう もとひこ)
1977年生まれ
MBBS & AI共創イノベーション主催。
医療系の研究所、心理学の研究所の勤務を経て独立し、現在は生成AI(ChatGPT、Claude、Geminiなど)と心身に関する研究をしている。
主著『かんたんプロンプト』(芸術新聞社)『東洋医学と潜在運動系』(たにぐち書店)、2年間専門誌に連載、論文執筆などの執筆業を行いつつAI共創ライティングを開発中。
心理学・カウンセリング・コーチングをAIに技術転用し、AI共創プロンプトエンジニアリングを開発している。
AIスクール・AI企業研修・AIアプリ開発などを行う。
✅ワンダー佐藤総合リンク
https://linktr.ee/motohiko.sato
✅ワンダー佐藤源彦・著『かんたんプロンプト』(芸術新聞社から刊行)
※プロンプトエンジニアリングの基本から応用、タスク実行までを網羅
https://amzn.asia/d/80zVtv8
✅note記事
https://note.com/mbbs
※ChatGPT・Claude・Gemini・NotebookLM・Perplexity・Genspark・Feloなどの記事あり
※ワンダー佐藤のMyGPTsも公開しています
※メンバーシップはじめました!
✅AI共創イノベーション(AIスクール・AI企業研修・AIアプリ開発のサイト)
https://mbbs-ai.jimdofree.com/
✅Facebook
https://www.facebook.com/motohiko1977
※リクエスト申請前にメッセージください
【AI共創イノベーションおすすめ動画】
https://www.youtube.com/watch?v=IXbKlwHUdbg&list=PLTcSHWqKTOojc8R-brID5q06JrmtiWRTl
サテライトチャンネル
https://www.youtube.com/@mindbody_ai
#AIエージェント #AIオーケストレーションスキル #プロンプトエンジニアリング #AIワークフロー #AIスキルトレーニング #業務効率化 #ClaudeCode #Codex #AI活用術 #AI自動化 #ハーネス #ハーネスエンジニアリング #ノンハーネス
いいなと思ったら応援しよう!
チップをいただけると、とても励みになります✨
いただいた分はすべて研究活動や記事制作に使わせていただきます🍀