Cowork には「スキル」という仕組みがある。
自分がよくやる作業手順をファイルとして書いておくと、AI がそれを読んで、同じ流れで動きやすくなる機能だ。
以前の記事で、最初の1本である blog-manager を作った時の体験を書いた。
あのときは、手順を言語化するのが一番難しい という話だった。
今回は、その後に inbox-triage、daily-update、save-summary とスキルを増やしていく中で見えてきたことを書いてみる。
結論を先に言うと、どのスキルも結局は同じ流れで動いている ことに気づいた。
そして、最初のスキルで一番迷ったのは、ワークフローをどう分けるか だった。
最初のスキルは、全部入りにしようとして詰まった
blog-manager を作ったとき、最初に書こうとしたのは「ブログ記事を書く手順」全体だった。
ネタ出し、選定、下書き作成、保存。
全部をひとつの流れとして書こうとした。
ところが、実際の運用を考えると、毎回ネタ出しから下書きまで一気にやるわけではない。
- 今日はネタだけ出しておきたい
- 前に出したネタの中から1本選んで書きたい
- 書かないけど、アイデアだけストックしたい
使い方は思っていたよりバラバラだった。
ひとつの手順書に全部を書くと、AI はかなり律儀に最初から最後まで走ろうとする。
「ネタだけ出して」と言っても、下書きまで進もうとしたり、保存先の確認を始めたりする。
やりたいことと、動き方が少しずつズレる。
そこで、ワークフローを
- A: ネタ出し
- B: 下書き作成
- C: アイデア保存
のように分けることにした。
それぞれに 「いつ起動するか」 のトリガーを書いて、独立して動けるようにした。
この 「分ける」判断 が、最初のスキルで一番時間がかかった部分だった。
2本目以降で気づいた「共通の流れ」
blog-manager の後に作ったのは、
inbox-triagedaily-updatesave-summary
の3つだった。
作っているうちに、どれも結局同じ流れで動いていることに気づいた。
- 何かを読む
inboxファイル、会話ログ、blog_ideas.mdなど - 整理・加工する
トリアージ、要約、ネタ出しなど - 確認を挟む
ユーザーに見せて「これでいいか」を聞く - 保存する
指定のファイルに書き込む
たとえば inbox-triage なら、
- inbox を読む
- 整理案を出す
- 確認する
- 各ファイルに振り分ける
という流れになる。
daily-update なら、
- 今日のログを受け取る
- daily 形式にまとめる
- 確認する
- daily ノートに保存する
save-summary も同じだった。
違うのは 何を読むか と どう加工するか だけで、骨組みは同じだった。
2本目の inbox-triage を作るとき、最初は白紙から書き始めようとした。
でも途中で、
「これ、blog-manager の一部と構造が同じだな」
と気づいて、そこから流用した。
3本目以降はさらに早くなった。
ワークフローを分けるかどうかの基準も見えてきた
blog-manager はワークフローを複数に分けた。
一方で、inbox-triage や daily-update は分けていない。
この違いはどこから来るのか。
振り返ってみると、基準はかなりシンプルだった。
途中で止めたいことがあるかどうか だ。
blog-manager の場合は、
- ネタ出しだけで終わりたい日がある
- 下書きだけ書きたい日もある
- アイデア保存だけしたい時もある
つまり、途中で止める使い方が普通にある。
だから分けた。
一方で inbox-triage の場合は、
- inbox を読む
- 整理案を出す
ここまでは毎回やる。
確認を挟むタイミングはあるけれど、それはワークフロー内の ステップ であって、別ワークフローにするほどではない。
だから分けなかった。
つまり、
「違うタイミングで呼びたい単位」がワークフローの区切りになる
ということだった。
これは作る前には分からなくて、実際に使ってみて
「毎回ネタ出しから始まるのが面倒」
と感じた時に初めて見えてきた。
「確認を挟む」は、どのスキルにも共通で必要だった
もうひとつ、スキルを増やす中で固まってきたルールがある。
それは、AI が勝手に書き込まない ということだった。
inbox-triage では
「勝手に書き込まない・必ず確認を挟む」
を原則として最初に書いた。
これは blog-manager を使っているときに、確認なしにファイルが更新されて
「あれ、変わってる」
となった経験から来ている。
情報の整理や保存は、間違っていても気づきにくい。
だから、
- 整理案を出す
- 見せる
- OK が出たら書く
という流れを、どのスキルにも入れるようにした。
daily-update でも、保存前に
「この内容で保存してよいですか？」
と確認を挟むようにしている。
save-summary も同じだ。
結果として、
読む → 加工する → 確認する → 保存する
この4ステップが、全スキル共通のテンプレートになった。
設計の「型」ができると、迷いがかなり減る
スキルを3つ、4つと増やしていく中で、一番変わったのは
新しいスキルを作るときの迷いが減ったこと だった。
最初の blog-manager は、何をどう書けばいいか分からなくて、試行錯誤にかなり時間がかかった。
でも今は、まず
- 読む
- 加工する
- 確認する
- 保存する
という骨組みを置いて、そこに
- 何を読むか
- どう加工するか
を埋めていく、という作り方ができる。
ワークフローを分けるかどうかも、
「途中で止めたい使い方があるか」
で判断できるようになった。
スキルの設計は、プログラミングみたいな厳密さまでは要らない。
でも、自分なりの 型 があると、毎回ゼロから考えなくて済む。
AI に手順を渡すための文章を書いているだけなのに、気がつくと自分の作業の構造そのものが整理されている。
これは、スキルを作る前にはあまり予想していなかった副産物だった。
まとめ
Cowork のスキルを複数作ってみて気づいたのは、結局どのスキルも
「読む → 加工する → 確認する → 保存する」
という同じ流れで動いている、ということだった。
そして、最初に一番迷った ワークフローの分け方 は、
「途中で止めたい単位 = ワークフローの単位」
というシンプルな基準に落ち着いた。
型が見えてからは、新しいスキルを作るのがかなり楽になった。
でもその型は、最初の1本で詰まって、2本目で
「あれ、これ同じだな」
と気づいて、3本目でようやく確信する、という順番でしか見えてこなかった。
作ってみないと分からない。
今のところは、その感覚がかなり正直なところだと思っている。
関連記事
コメント