Claudeと「仕事の流れ」を回す ─ 要件定義から資料・PDF・メールまで一気通貫

Claudeに作業を任せられるようになると、次に気になってくるのがこれです。調べ物を頼んで、その結果をもとに資料を作って、体裁を整えて、送る。ひとつずつはお願いできるのに、工程が変わるたびに前提を話し直している。仕事は本来、そうやって細切れになっているものではないはずです。

今回は、Coworkにひとつの仕事を最初から最後まで通してもらう使い方を紹介します。私たちが実際に回していた流れを、そのまま追いかける形でお話しします。

前回の記事では、Coworkの基本として、ブラウザ調査やファイル整理をひとつずつ任せる話を取り上げました。今回はその先、任せる単位を「作業」から「流れ」に広げます。

ひとつ任せるから、流れごと任せるへ

ひとつの案件を思い浮かべてみてください。お客様に提出する資料を作るとして、実際にやることはこれくらいあります。

何を伝えたいのかを整理して、必要な項目を洗い出して、構成を決めて、中身を書いて、読みやすく整えて、印刷できる形にして、送付の文面を用意する。ひとつひとつは短い作業でも、つなげると半日仕事になります。

Coworkが効いてくるのはここです。工程が変わってもやりとりが途切れないので、前の工程で決めたことを踏まえたまま次に進めます。「さっき決めた構成に沿って」と言えば通じる状態が、最後まで続きます。

実際に回していた流れ

私たちが資料作成の案件で回していた流れは、こんな順番でした。

• 目指したいゴールを伝える: 何のための資料で、誰に読んでもらい、どうなったら成功かを最初に言葉にする
• 要件を聞き出してもらう: こちらが説明しきれていないところを、Coworkが質問で埋めていく。ここで前提がはっきりする
• 概要の設計を見て直す: 出てきた構成を読んで、違うところを指摘して直してもらう
• 詳細の設計をレビューにかける: 私たちはレビュー専用のSkillを作ってあって、細かい設計をそれにかけています。人が読む前に一度ふるいにかける形です
• 資料を作ってもらう: 設計に問題がなければ構築を依頼する。ここもSkillを呼び出して、決まった作り方で進めてもらう
• デザインの方向を指示する: 内容に合わせて見せ方を決めるのはこちら側。決めたらデザイン用のSkillで整えてもらう
• 形を選んで詰める: スライドの形がいいのか、A4縦の読み物がいいのか。読み手に合うほうを選んで、そこから細部を詰める
• PDFにして仕上がりを確かめる: 書き出したあと、印刷したときに切れていないかを確認して整える
• 送付の文面を用意して送る: メールの文章を書いてもらい、PDFを添えて送る

途中でカレンダーやメールなどの外部サービスにつないでおくと、日程や宛先を調べ直す手間もなくなります。コネクタで許可した範囲だけを見にいってくれるので、必要なものだけつなぐ形にしておくと安心です。

手放すところと、握るところ

この流れを書き出してみて、あらためて気づいたことがあります。手を動かす作業はほとんど渡しているのに、決めることは一度も渡していないのです。

どこへ向かうか。設計が意図とずれていないか。どの形式が読み手に合うか。印刷して切れていないか。送っていいか。この5つは、どれもCoworkに聞けば意見は返ってきます。それでも自分で決めていたのは、間違ったときに困るのがこちらだからです。

逆に言えば、この線さえ引いておけば、あとは安心して渡せます。全部を任せようとすると怖くなりますが、「決めるのは自分」と決めてしまえば、作業は思い切って手放せます。

決まった時間に走らせる

Coworkには、頼んだ作業を決まった間隔で自動的に走らせる機能もあります。毎日、毎週、毎月といった間隔を選んでおくと、こちらが何もしなくても動きます。

私たちが入れていたのは、毎週月曜の午後4時に先週やったことを振り返らせる、というものでした。週の終わりに自分で書き出すのは後回しになりがちなので、勝手に用意されている状態を作りたかったからです。

正直なところ、そこまで使いこなせたとは言えません。作られた振り返りを読む習慣のほうが続かず、置いてあるだけになった時期もありました。定期実行は「設定すれば回る」のは確かですが、受け取ったものを使う側の習慣とセットにしないと効いてこない、というのが実感です。

これから試すなら、まずは手動で流れを回すほうを先にしたほうがいいと思います。何度か通してみて、毎回同じ形になった作業が見つかってから定期実行にする。その順番のほうが無理がありません。

ここから先はClaude Codeへ

ここまで書いてきたとおり、Coworkはひとつの流れを最後まで通すのが得意です。逆に、そこを超えたときに足りなくなるものもはっきりしています。

私たちが今Coworkを使っていないのは、作業場を複数持って同時に動かしたくなったからです。別々の案件を、それぞれ独立した場所で並行して進める。片方で調べ物をしながら、もう片方で修正を走らせる。この持ち方はCoworkにはありません。

ひとつ紛らわしいのは、Coworkにも大きな仕事を内部で分割して同時に進める仕組みがあることです。ただしそれはひとつの作業の中身が分かれる話で、作業場そのものは常にひとつです。ここを同じものだと思って試すと、期待した動きにならず戸惑うことになります。

複数の作業場を並べたくなったら、それがClaude Codeに移るタイミングです。前回「CoworkはClaude Codeの練習台」と書きましたが、練習台を卒業する合図は、機能の物足りなさではなく仕事の持ち方が変わったときにやってきます。

まとめ

今回のポイントを整理します。

次回は、ここまで何度も出てきた「Skill」をまとめて配れるようにするプラグインの話です。自分のために作った型が、チームで使えるものに変わっていく回をお届けします。