ワークフロー

ワークフローは、エージェントに保存された名前付きの再利用可能な手順です。あなたのチームが特定の仕事をどう行うかをOkouに教えるので、次にそれを必要とする人がプロンプトを書き直す必要はありません。

初めてOkouに何かを頼むとき、プロンプトを書きます。2回目は同じプロンプトを少し直して貼り付けます。3回目には、誰かが「チームプロンプトライブラリ」と呼んだNotionドキュメントから長いプロンプトをコピーしています。それがワークフローを保存する瞬間です。

ワークフローが解決する問題

一度きりのチャットは一度きりのタスクには十分です。しかし、ほぼすべてのチームには繰り返す仕事のバックログがあります。入力は違っても形は同じです:

• 顧客から連絡 → 履歴を確認 → その言語で返信を下書き → チケットを記録
• バグ報告が出る → 再現手順を抽出 → 深刻度を分類 → 構造化されたIssueを作成
• 月曜の朝 → 先週の数字を取得 → 前週と比較 → ダイジェストを投稿

ワークフローがなければ、それぞれは全員が覚える200語のプロンプトです。ワークフローがあれば、それぞれは名前です。triage-bug-report、weekly-metrics、customer-reply。

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

ワークフローの中身

ノードグラフも、YAML設定も、トリガーセクションもありません。インストラクションは、初回にうまくいったチャットプロンプトによく似ています。

良い説明は、発火すべきときに発火するワークフローと、決して発火しないワークフローの違いです。*「triage a customer-facing bug report and file it to GitHub with severity」は「do bug stuff.」*より優れています。

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

すべてのワークフローはちょうど1つのエージェントに属します。それが動作を予測可能にします。ワークフローはそのエージェントのトーン、デフォルト、コネクタ付与で動きます。

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

同じ手順が2つのエージェント上に存在し、異なる結果を生むことがあります。それぞれが自分の声と権限を持ち込むためです。ワークフローを別のエージェントに渡すには、コピーします。これでフォークされ、2つはその後分岐できます。

エージェントの所有がワークフローの触れる範囲をどう形作るかはAgentsを参照。

ワークフローの作成

Workflowsページから始める

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

既存のエージェントチャットで始めて、うまくいったタスクをワークフローに変えるようOkouに頼むこともできます。最初の成功したRunを同じチャットに残すと、Okouが取り込むべき具体的な入力、修正、出力が得られます。

インストラクションに書くこと

認証情報をインストラクションやファイルに入れないでください。サービスはConnectorsで接続し、所有エージェントにはワークフローに必要な権限だけを付与します。

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

1. 代表的な入力でワークフローを手動実行します。
2. 所有エージェントが必要なすべてのコネクタと権限に到達できることを確認します。
3. 結果のチャットを、欠けたコンテキスト、想定外の書き込み、最終出力の形について確認します。
4. Instructionsや添付ファイルを編集し、結果が再現可能になるまで再実行します。
5. 手動実行が正しくなってから自動化を追加します。狭いイベントフィルターや低頻度のスケジュールから始め、最初の数回の発火を確認します。

手動検証はワークフローの問題とトリガーの問題を分けます。Run nowが失敗したら、まずワークフローかそのアクセスを修正します。Run nowは成功するのにイベントが発火しないなら、自動化の設定を確認します。

Okouがワークフローを選ぶ仕組み

ワークフローを名前で呼ぶ必要はありません。受信リクエストが説明に一致すると、Okouが自動で1つを読み込みます。*「draft a reply to a customer email using our voice and docs」*と説明されたcustomer-reply-draftというワークフローは、顧客メールを転送すると発火します。名前は不要です。

特定のものを強制するには、明示します: "Use the customer-reply-draft workflow on this email."

組み込みワークフロー

すべてのOkouエージェントには、Okouが保守する機能横断のワークフローが同梱されています。リサーチと分析、財務と会計、法務とコンプライアンス、プロダクト、マーケティング、カスタマーサポート、チームコミュニケーションです。それらはコネクタの配線ではなくドメインの手順で、それぞれが繰り返しの仕事の扱い方をOkouに教えます。

一部を紹介:

• deep-dive — 構造化されたリサーチとソリューション設計。事実を集めてから選択肢を探る
• prd-writing — 構造化された問題設定と受け入れ基準を備えたプロダクト要件
• copywriting — チャンネル横断のマーケティングコピー（ブログ、メール、SNS、ランディングページ）
• competitor-matrix — 機能比較マトリクス、ポジショニング分析、勝敗分析
• customer-reply — チャンネルと緊急度に合わせた、共感的でブランドに沿った返信
• nda-screening — 受信NDAをGREEN / YELLOW / REDに分類してルーティング
• status-updates — 任意の対象者に合わせた進捗報告とステークホルダー更新

自分のワークフローはこれらと並び、説明がより正確に一致する場合は優先されます。

作るべきタイミング

正直なルール: 実質的に同じプロンプトを2回以上書いたなら、またはチームメイトが書くのが想像できるなら、保存します。

具体的なサイン:

• チームがすでに使う名前がある（「morning brief」「competitor scan」）
• プロンプトが、毎回変わるべきでない特定のツール、チャンネル、テンプレートを名指しする
• 出力の形が固定されている（ダイジェスト、下書き、作成されたIssue）
• 複数の人がトリガーする必要がある
• スケジュールやイベントで動かしたい — Automationsを参照

よくあるパターン

• 受付フォーム。 入力（メール、バグ報告、スレッド）を受け取り、構造化された成果物（Issue、下書き、行）を生成します。
• 定時ブリーフ。 毎日または毎週実行して見える場所に投稿する、スケジュール自動化と組んだワークフロー。
• 会話中のヘルパー。 チャンネル内のOkouでトリガーされ、1つの集中的なサブタスク（調べる、要約する、分類する）を行います。
• コンポーザー。 1回のRunでブログ下書き＋SNS投稿＋カードという複数形式の束を生成します。
• イベント応答。 イベント自動化と組み、新着メール、マージされたPR、新しいNotionページがRunを開始します。Automationsを参照。

避けるべき落とし穴

• 狭すぎる。 特定の入力にしか合わないワークフローは壊れやすい。例の詳細ではなく、仕事の形を狙います。
• 曖昧すぎる。 *「Help with marketing」*は広すぎて、Okouはいつ適用すべきか分かりません。説明を具体的にします。
• ハードコードされた認証情報。 APIキーをインストラクションに貼らないでください。Custom connectorsを使います。認証情報はプラットフォーム上に留まり、モデルの手の届かない場所にあります。
• 埋もれた出力の形。 成果物の見た目を明記します。「a numbered list of three items」や「a draft reply under 150 words.」
• エージェントを忘れる。 ワークフローは、そのホストエージェントが認可されたコネクタしか使えません。ワークフローがGmailに到達できないなら、インストラクションではなくエージェントのAuthorizationタブを確認します。

次へ

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