Okouチームが毎週動かしている5つのワークフローです。それぞれについて、セットアップ、プロンプト、Okouが生み出す成果物、そして取り戻せる時間を紹介します。
そのまま真似することが目的ではありません。完成したOkouワークフローの形をつかみ、自分の仕事に合わせて作り変えるための材料です。
1. 朝のブリーフ
困りごと。 毎朝は追いつく作業から始まります。Slackを開き、@メンションに目を通し、カレンダーを確認し、オープン中のPRをのぞく。最初の本来の仕事に取りかかるまでに20分。
セットアップ。 スケジュール1本、平日8時。Connectors：Slack、GitHub、Google Calendar。
プロンプト。
「平日の毎朝8時（北京時間）に、次の4セクションをDMで送って。
- 直近24時間の未読のSlack @メンション。それぞれ1行の要約付きで
- 自分にアサインされたGitHubのイシュー。古い順に並べ、ステータスと最新コメントを添えて
- 今日のカレンダー。予定のタイトル、時刻、リンクがあれば関連するNotionドキュメント
- 期限超過のものや他の人をブロックしているものを踏まえた、その日の注力先の提案を1つ」
受け取れるもの。 8時に届くSlackのDM。おおむね200〜350語です。各セクションは短く、数値は具体的で、リンクは本文に埋め込まれています。「注力先の提案」は日によって変わります。明らかに優先すべきPRのこともあれば、その日の予定から想像する以上に準備が要る打ち合わせのこともあります。
取り戻せるもの。 1日あたりおよそ20分。加えて、朝いちばんに4つのツールを行き来する際のコンテキストスイッチの負荷もなくなります。
バリエーション。 新規顧客の登録や、Sentryから拾った本番エラーを5つ目のセクションとして追加できます。通知のない朝を過ごしたいなら、Slack DMではなくメールに切り替えてください。
2. 週次の競合ウォッチ
困りごと。 競合が先週何をリリースしたかを把握できるのは有用です。とはいえ、Xのアカウント3つ、チェンジログ3つ、価格ページ3つ、ブログ一覧1つを手作業で確認するのは面倒で、いつの間にか後回しになります。
セットアップ。 ワークフロー（competitor-scan）と、月曜朝のスケジュール実行のautomation。Connectors：XとNotion。ウェブ検索については何も接続する必要はありません。managed serviceとして提供されています。
プロンプト。
「X上の@competitor1、@competitor2、@competitor3と、それぞれのチェンジログを先週月曜以降の分についてスキャンして。価格ページやブログ記事とも突き合わせて。先週のベースライン（Notionページ『Competitor State』）との差分を取って。新機能、価格の変更、採用のシグナル、トーンやメッセージの目立った変化を挙げたダイジェストを
#competitor-intelに投稿して。」
受け取れるもの。 月曜朝のSlackスレッド。親メッセージは5項目の箇条書きサマリー。返信として、競合ごとのセクションに更新内容の引用とリンクが並びます。Notionのベースラインページは自動で更新されるので、翌週の差分も新しい基準の上で取れます。
取り戻せるもの。 週におよそ90分。加えて、「そろそろAcmeを見ておかないと」という見えない心理的負荷もなくなります。
バリエーション。 コミュニティの反応を見るためにRedditやHacker Newsを追加できます。1年分の差分をまとめて取締役会向けの1枚にする四半期ふりかえりを追加するのもよいでしょう。
3. バグのトリアージ
困りごと。 誰かが#bug-reportにスクリーンショットや漠然とした説明を投げ込みます。それを、再現手順、重大度、ラベル、担当チームを備えた本物のGitHubイシューに仕立てる必要があります。この形式化のひと手間は小さいものの、絶え間なく発生します。
セットアップ。 ワークフロー（triage-bug-report）を、#bug-reportで@Okouと呼び出して手動実行。Connectors：Slack、GitHub。
プロンプト（チャンネル内）：
「Okou これをトリアージして。スクリーンショットとスレッドから再現手順を抽出して、関連するGitHubイシューを検索して、重大度を分類して（P0〜P3）、ファイルパスや症状から最も可能性の高いチームにアサインして、重複でなければ新しいイシューを作成して。このスレッドにリンクを返信して。」
受け取れるもの。 約60秒以内に届くスレッド返信。GitHubイシューのリンク、選んだ重大度とその1行の根拠、文脈として関連イシュー2〜3件のリスト、そしてアサインされたチームが含まれます。Okouが重複だと判断した場合は、新規作成せずに元のイシューのリンクを投稿します。
取り戻せるもの。 忙しい1週間を通して見ると、これは整ったイシュートラッカーと、トリアージされないSlackスクリーンショットの山との分かれ目になります。
バリエーション。 報告者が社外かどうかに応じて「customer-facing」タグを付けられます。P0のときはオンコールを自動で呼び出すようにもできます。
4. 顧客返信のドラフト
困りごと。 顧客からのメールには、役に立ち、ブランドに沿い、ドキュメントに裏付けられた返信が必要です。1通5分×週30通は、無視できないコストです。
セットアップ。 ワークフロー（customer-reply-draft）を、Okouへのメール転送またはチャットへの貼り付けで手動実行。Connectors：Gmail、Notion（またはヘルプセンター）、Stripe（請求関連）、Linear（既知の問題）。
プロンプト。
「顧客からこのメールが届いた〔貼り付け〕。この顧客の直近3件のチケットを読んで、該当する箇所を自社ドキュメントで確認して、報告内容に合致する既知の問題がないかLinearを調べて、請求まわりの状況をStripeで確認して。相手の言語で返信を下書きして。ドキュメントの該当セクションを引用して。150語以内に収めて。この顧客への直近のサポート返信のトーンに合わせて。」
受け取れるもの。 末尾に出典リンクを添えた返信ドラフト。通常はドキュメントへのリンク2〜3本に加え、*「Linear ENG-4422がこの件の既知の問題です。対応予定は来週です。」*といった注記が付きます。ざっと目を通し、1行だけ直して送信するだけです。
取り戻せるもの。 メール1通あたり3〜4分ほど。サポート業務の1週間で見れば数時間になります。
バリエーション。 Stripeから顧客ティアを自動判定し、VIP向けの返信は指名したレビュアーの確認を経るようにできます。メールは常にあなたのアカウントに下書きとして届き、人が送信します。つまり、どのティアにどれだけ目を配るかは、このレビュー工程で決められます。
5. 週次のコンテンツ制作
困りごと。 マーケティングは毎週、ブログ記事1本、LinkedIn投稿3本、ソーシャルカード一式を求めます。どれもリサーチと既存コンテンツからの文脈を必要とします。ツールをまたいだ調整は、書く作業そのものより手間がかかります。
セットアップ。 複数ステップのワークフロー（weekly-content）を、金曜午後のスケジュール実行のautomationで動かします。Connectors：Notion（リサーチ）、Plausible（アナリティクス）、Fal（画像生成）、Loops（メール）。
プロンプト。
「毎週金曜14時に、次を実行して。
- 『Marketing Inputs』データベースにある今週の新しいNotionドキュメントを読む
- 先週のブログのトピックと突き合わせて、重複を避ける
- いちばん旬なトピックで800語のブログ記事を下書きし、Notionの『Blog Drafts』に保存する
- 同じ趣旨のLinkedIn投稿を3パターン下書きする——エッセイ、リスト形式、個人の体験談
- 自社のブランドスタイルで正方形のソーシャルカードを3枚生成する
- 一式を
#marketingにレビュー用として投稿する」
受け取れるもの。 金曜午後に届くSlackメッセージ1通に、6つの成果物がすべて含まれています。ブログの下書きは、すでに体裁の整ったNotionページにリンクしています。LinkedInの下書きはそのままコピーして貼り付けられます。ソーシャルカードはダウンロード済みで、すぐ添付できます。
取り戻せるもの。 週あたりおよそ半日分の調整作業。編集担当はレビューして公開するだけで、下書きを書く必要はありません。
バリエーション。 Okouに見出しを2案生成させ、Loops経由で小さなオーディエンスに当てるA/Bテストを追加できます。先週の反応が良かったトピックをPlausibleで確認し、テーマ選びに反映させるのもよいでしょう。
ここで紹介したワークフローは、いずれもセットアップに10〜30分ほどしかかかりませんでした。その後は毎日、あるいは毎週、効果を返し続けます。コストはおおむね各実行が消費するクレジット分で、Billingページで確認できます。計算方法はCredits & billingをご覧ください。
自分用のバージョンを作るには、上のプロンプトをどれか1つコピーし、自分のツール名やチャンネル名に置き換えて試してみてください。あとは結果を見ながら手を入れていけば大丈夫です。
より幅広い例は、公開されているworkflow libraryにあります。各例について、必要なconnectors、起動用のプロンプト、Okouが実行するステップが一覧になっています。
