ワークフロー

ワークフロー は、エージェントに保存された、名前付きで再利用できる手順です。あなたのチーム が特定の種類の仕事をどうやるのかを Okou に教えるものなので、次に同じ仕事が必要になった人はプロンプトを書き直さずに済みます。

最初にお願いするときは、プロンプトを書きます。2 回目は同じプロンプトを少し直して貼ります。3 回目にはもう、誰かが「チームのプロンプト集」と名づけた Notion のドキュメントから長いプロンプトをコピーしています。そこがワークフローを保存すべきタイミングです。

ワークフローが解く問題

一度きりの作業なら、一度きりのチャットで十分です。しかしたいていのチームには、繰り返される 仕事の山があります。入力は違っても、形は同じです。

• 顧客から問い合わせが来る → 履歴を調べる → 顧客の言語で返信を下書きする → チケットに記録する
• バグ報告が上がる → 再現手順を抜き出す → 深刻度を分類する → 構造化された issue を作る
• 月曜の朝 → 先週の数字を取る → その前の週と比べる → ダイジェストを投稿する

ワークフローがなければ、これらはそれぞれ全員が覚えておくべき 200 語のプロンプトです。ワークフローがあれば、それぞれがひとつの名前になります。triage-bug-report、weekly-metrics、customer-reply。

ワークフロー単体にはスケジュールもトリガーもありません。あくまで 手順 です。ひとりでに動かすには、Automation を付けます。

ワークフローの中身

ノードグラフも、YAML の設定も、トリガーの欄もありません。指示はたいてい、最初にうまくいったチャットのプロンプトとよく似た見た目になります。

良い説明は、必要なときに発火するワークフローと、一度も発火しないワークフローの分かれ目です。「顧客向けのバグ報告をトリアージし、深刻度を付けて GitHub に登録する」 は 「バグまわりのこと」 よりずっと良い書き方です。

ワークフローはエージェントに属する

すべてのワークフローは ちょうどひとつのエージェント に属します。これが振る舞いを予測可能にします。ワークフローは、そのエージェントのトーン、既定値、コネクタ権限で動きます。

• プライベートなワークフロー — 自分だけに見えます。個人の Gmail や個人の CRM 席に紐づく個人的な自動化に向きます。
• パブリックなワークフロー — ワークスペース全員に見え、チームが到達できるエージェント上に置かれます。

同じ手順を 2 つのエージェントに置くと、結果は違ってきます。それぞれが自分の語り口と自分の権限を持ち込むからです。別のエージェントに渡すには コピー します。これで枝分かれし、その後は別々に育てられます。

エージェントの所有関係がワークフローの触れる範囲をどう決めるかは Agents を参照してください。

ワークフローを作る

Workflows ページから始める

1. Workflows を開き、New workflow を選びます。
2. そのワークフローを所有するエージェントを選びます。
3. Okou が作成をガイドするプロンプト付きでチャットを開きます。成果、想定される入力、使うツール、出力、承認の線引きを説明します。
4. Okou が作成する前に、提案された名前・説明・指示・ファイル・可視性を確認します。

既存のエージェントのチャットから始めて、すでにうまくいった作業をワークフローにしてほしいと頼むこともできます。最初の成功した Run を同じチャットに残しておくと、具体的な入力、あなたの修正、実際の出力を Okou がそのまま取り込めます。

指示に何を書くか

認証情報は指示にもファイルにも書かないでください。サービスは Connectors から接続し、所有エージェントにはそのワークフローに必要な権限だけを与えます。

自動化する前にテストする

1. 代表的な入力で、ワークフローを手動で一度実行します。
2. 所有エージェントが必要なコネクタと権限にすべて到達できることを確認します。
3. できあがったチャットを見て、足りないコンテキスト、想定外の書き込み、最終出力の形を確かめます。
4. Instructions や添付ファイルを直して、結果が再現できるようになるまで実行し直します。
5. 手動実行が正しくなってから Automation を足します。まずは絞り込んだイベント条件か低頻度のスケジュールで始め、最初の数回の発火を確認してください。

手動での確認は、ワークフローの問題とトリガーの問題を切り分けます。Run now が失敗するなら、まずワークフローかそのアクセス権を直します。Run now は成功するのにイベントが発火しないなら、Automation の設定を見てください。

Okou はどうワークフローを選ぶか

名前で呼び出す必要はありません。届いた依頼が説明文に合致すれば、Okou は自動でワークフローを読み込みます。customer-reply-draft という名前で 「自社の語り口とドキュメントを使って顧客メールへの返信を下書きする」 と説明されていれば、顧客メールを転送したときに名前を出さなくても発火します。

特定のものを指定したいときは、そう言えば大丈夫です。「このメールには customer-reply-draft ワークフローを使って。」

標準で付いてくるワークフロー

Okou のエージェントには、Okou が保守する部門横断のワークフロー群が最初から付いています。リサーチと分析、財務と経理、法務とコンプライアンス、プロダクト、マーケティング、カスタマーサポート、チームコミュニケーションなどです。これらはコネクタの配線ではなく業務の手順で、繰り返し現れる種類の仕事をどう扱うかを Okou に教えます。

一例です。

• deep-dive — 構造化されたリサーチと解決策の設計。まず事実を集め、それから選択肢を検討します
• prd-writing — 問題の構造化された整理と受け入れ基準を備えたプロダクト要件
• copywriting — チャネル横断のマーケティング文（ブログ、メール、ソーシャル、ランディングページ）
• competitor-matrix — 機能比較マトリクス、ポジショニング分析、勝敗分析
• customer-reply — チャネルと緊急度に合わせた、共感的でブランドに沿った返信
• nda-screening — 受領した NDA を GREEN / YELLOW / RED に分類して振り分け
• status-updates — 相手に合わせた進捗報告とステークホルダー向けアップデート

自作のワークフローはこれらと並んで置かれ、説明がより近ければそちらが優先されます。

いつ作るべきか

正直な目安は、ほぼ同じプロンプトを 3 回目に書いたとき、あるいは同僚が同じものを書く姿が思い浮かんだときです。

具体的なサインです。

• その仕事に、チームがすでに使っている名前がある（「朝のブリーフ」「競合スキャン」）
• プロンプトが、毎回変わってほしくない特定のツール・チャネル・テンプレートを名指ししている
• 出力の形が決まっている（ダイジェスト、下書き、登録された issue）
• ひとり以上がそれを起動する必要がある
• スケジュールやイベントで動かしたい — Automations を参照

よくある型

• 受付フォーム型。 入力（メール、バグ報告、スレッド）を受け取り、構造化された成果物（issue、下書き、1 行のレコード）を作ります。
• 定期ブリーフ型。 スケジュール自動化と組み合わせ、毎日または毎週動いて見える場所に投稿します。
• 会話の途中で助ける型。 チャンネルで @Okou と呼ばれ、調べる・要約する・分類するといった絞られた仕事をひとつこなします。
• まとめて作る型。 1 回の実行で複数形式の束（ブログ下書き、ソーシャル投稿、カード）を作ります。
• イベント応答型。 イベント自動化と組み合わせ、新着メール、マージされた PR、新しい Notion ページなどが実行の引き金になります。Automations を参照。

避けたい落とし穴

• 狭すぎる。 ひとつの具体的な入力にしか合わないワークフローは脆いです。例の細部ではなく、仕事の形を狙ってください。
• 曖昧すぎる。 「マーケティングを手伝って」 は広すぎて、Okou はいつ使えばよいか判断できません。説明は具体的に。
• 認証情報の直書き。 API キーを指示に貼らないでください。代わりに カスタムコネクタ を使えば、認証情報はプラットフォームに留まり、モデルの手の届かないところにあります。
• 出力の形が埋もれている。 成果物の見た目を明記してください。「3 項目の番号付きリスト」、「150 語以内の返信下書き」 のように。
• エージェントを忘れている。 ワークフローが使えるのは、ホストのエージェントが認可されているコネクタだけです。Gmail に届かないなら、指示ではなくエージェントの Authorization タブを見てください。

次に読むもの

• あなたなしで動かすには Automations でトリガーを付ける。
• 誰がどの権限でワークフローを実行するかは Agents。
• ワークフローが触れる範囲を絞るには Permissions。
• 最初から最後まで書かれた 5 つの例は Example workflows。