共有スキルを2分類で管理する――AIスキル設計の理想と現実
スキルとは、今や多くのコーディングAIエージェントに組み込まれた機能です。自然言語で示された条件を元にAIが自動的にスキルを起動することで、スキルとして設定されたプロンプトをAIが読み込み、それに従ってAIが動くというものです。また、いわゆるスラッシュコマンドとして、ユーザーが明示的にスキルの使用を指示することもできます。
現在、スキルはAIを拡張し、カスタマイズする主要な手段として用いられています。つまり、良いスキルを用意してあげることで、AIがより多くのことを、効率よく、あるいは精度高く行えるようになるのです。
スキルの共有と課題
そうなると、特に複数人で開発を行っている場合、スキルを自分のローカルで管理するだけでなく、チーム全体で共有したいと考えるのは自然なことです。
その方法として、リポジトリにスキルをコミットするという方法があります。あるいは社内マーケットプレイスを構築してそこからスキルを配布することで、複数リポジトリでもスキルを共有できます。
その結果として、課題も発生します。一言で言えば、課題とは、スキルにオピニオンが入りやすい・入れざるを得ないことです。つまり、スキルを書いた人が望ましいと思う仕事の進め方が、自然とスキルに反映されます。例えば、ある人はgit commitを全部自動でやって欲しいと思うかもしれないし、別の人はコミットメッセージに目を通してからコミットして欲しいと思うかもしれません。
他にも、AIとの付き合い方の違いがスキルにも現れます。例えば、ガチガチに手順を固めるのか、それとも大ざっぱな指示に留めてAIの柔軟性に期待するのかです。
自分とは異なる考え方の人のために作られたスキルを使うのは、ストレスが溜まるし、効率低下の原因となります。そのため、個人ごとにカスタマイズされたスキルの需要があります。
一方で、だからといってスキルを何も共有しないというのも非効率です。共有できるスキルもあるはずです。
ここで生まれる問いは、どのスキルを共有するべきかということです。あるいは、共有するスキルと個人で管理するスキルをどう分けるべきかということです。
スキルの2分類
ここで筆者が考えているのが、スキルは大枠で以下の2種類に分けられるのではないかということです。
- 知識系スキル: AIが素の状態では持っていない知識を与えるスキル。
- ワークフロー系スキル: 特定の作業手順やプロセスを自動化するスキル。要するに指示をプロンプトにまとめてコマンド化したもの。
お察しのとおり、知識系スキルは共有するのに適している一方で、ワークフロー系スキルは個人ごとにカスタマイズされたものが求められる傾向があります。
知識系スキルの例としては、チケット管理システムの読み書きです。AIは、「FOO-123」のような文字列が出てきたら、文脈や自身の知識からそれがチケット番号であると認識することはできます。しかし、チケット管理システムがJiraなのか、Jiraだとしたらドメインが何なのか、ということはAIは知りません。そういった情報をスキルとして与えることで、AIは「FOO-123をやって」と言われたら、チケットの内容を読んで作業を開始することができます。
また、Jiraの場合は公式のAtlassian CLI (acli) がありますが、AIは素の状態ではacliの使い方が分かりません。acliの存在とその基本的な使い方をスキルとして与えることも有用であり、これも知識系スキルの一例と言えます。
その他、普遍的ではない、プロジェクト特有の知識を与えるスキルも知識系スキルに分類されます。例えば、プロジェクト特有のコードスタイルや命名規則、コミットメッセージのルールなどです。
ワークフロー系スキルの例としては、「PRを作る」スキルがあります。PRを作る手順は、おおよそ以下のとおりになります。
- （まだブランチがない場合）ブランチを切る
- （まだコミットしていない場合）変更をコミットする
- pushする
- PRを作る
一連の手順をプロンプトとしてまとめることで「PRを作る」スキルができます。
しかし、以上の手順に対する具体的な要望は人によって異なります。例えば、PRを出す前に説明文を人間がレビューすることを望む人もいれば、AIに任せてMRを作っちゃっていいという人もいます。
そのため、ワークフロー系スキルは個人ごとにカスタマイズされたものが求められる傾向があります。
スキルのモジュラー化
何事も、全てが理想通りにはいきません。スキルを「知識系」と「ワークフロー系」にすっぱり分けることもまた難しいでしょう。
例えば、PRを作るスキルは、本来ワークフロー系に分離されますが、いとも簡単に「知識系」の要素を含み始めます。
具体例としては、PRを作るスキルの最中にコミットすることになるので、そこにコミットメッセージのルールに関する記述が混ざるなどです。また、PRのタイトルにもルールがあれば、PRを作るスキルに含めたくなりますが、本来はこれも「知識系」に分類されるべきです。
理想的には、あるワークフローの過程で要求される知識は、別の知識系スキルとして分離されているべきです。これがスキルのモジュラー化です。全ての情報をまとめたでかいスキルを作るのではなく、細かく分割されたスキル群として運用すべきだということです。
モジュラー化されたスキルは、自然言語の繋がりによって自動的に呼び出されるのが理想です。
つまり、「PRを作る」ワークフロー系スキルの手順に「コミットして」と書いてあったのであれば、AIは自動的に「コミット時のルール」知識系スキルを呼び出すべきだということです。
モジュラー化の現実
筆者は実際にこのような運用を試みています。しかし、あまりうまくいかないのが現実です。理由は、抽象化して言えば、AIの指示追随能力がまだ十分ではないからだと考えています。
AIに直接「コミットして」と頼めば、AIが自動的に「コミット時のルール」スキルを呼び出してくれる可能性は大きいです。しかしながら、「PRを作る」スキルの中に「コミットして」と書いてあった場合、AIは「PRを作る」スキルの作業に集中するあまり、「コミット時のルール」スキルを呼び出すのを忘れてコミットしてしまうことが多くあります（体感では50%以上の確率で呼び出し忘れます）。
このように、自然言語を介したモジュラーなスキル運用はまだうまく回りません。
次善策としては、スキル名を明示する方法があります。つまり、「PRを作る」スキルの中に単に「コミットして」と書くのではなく、「コミットして（ルールはcommit-ruleスキルを呼び出して確認）」のように書くことで、AIが「コミットして」と頼まれたときに「commit-rule」スキルを呼び出すことを促す方法です。
筆者の体感としては、このように明示することで的確にスキルを呼び出してくれる確率は大幅に上がります。
その代わり、スキル名を明示することによる密結合化というデメリットがあります。
理想ではないが、スキルのモジュラー化を実現するための現実的な方法です。
知識系スキルを呼び出すのは大抵ワークフロー系スキルの中であり、ワークフロー系スキルは個人で管理する運用にする前提であれば、まあ回せないこともないかなという印象です。
まとめ
この記事では、筆者の考えるスキルの分類として「知識系」「ワークフロー系」という分け方を考察しました。
この分け方を活かすためには、スキルのモジュラー化が必要ですが、現実にはAIの指示追随能力の限界から、自然言語を介したモジュラー化はうまくいかないことが多いのが現状です。
それでも、社内で共有するスキルを作る際には、このような分類とモジュラー化の考え方を念頭に置いて、スキルを設計することが望ましいと考えています。
全社的な知識は知識系スキルとして共有し、個人のワークフローはワークフロー系スキルとして個人で管理するという運用が、現在現実的に可能な運用の一つでしょう。
Discussion