ワークフローは、名前付きで再利用可能な手順です。Okou に、あなたのチームが特定の種類の仕事をどう進めるかを教えるので、次にそれが必要になった人はプロンプトを書き直さずに済みます。
最初に Okou に何かを頼むときは、プロンプトを書きます。2 回目は、少しだけ調整した同じプロンプトを貼り付けます。3 回目には、誰かが「チームプロンプトライブラリ」と呼んだ Notion のドキュメントから長いプロンプトをコピーしているはずです。その瞬間こそ、ワークフローとして保存するときです。
ワークフローが解決する問題
1 回きりのチャットは、1 回きりのタスクには十分です。ですが、ほぼすべてのチームには、繰り返し発生する仕事のバックログがあります。入力は違っても、形は同じです。
- 顧客から連絡が来る → 履歴を確認する → その人の言語で返信案を書く → チケットを記録する
- バグ報告が届く → 再現手順を抽出する → 重大度を分類する → 構造化された issue を作成する
- 月曜の朝 → 先週の数値を取得する → その前の週と比較する → 要約を投稿する
ワークフローがなければ、これらはすべて、誰もが覚えておかなければならない 200 語のプロンプトです。ワークフローがあれば、それぞれは名前になります。triage-bug-report、weekly-metrics、customer-reply。
ワークフロー自体にはスケジュールもトリガーもありません。- それは手順です。自動で実行させるには、自動化 を付けます。
ワークフローに含まれるもの
| 項目 | 内容 |
|---|---|
| Name | 英小文字のスラッグで、文字、数字、内部ハイフンのみを使った 2–64 文字のものです — triage-bug-report。ワークフローが利用可能なチャットで明示的に呼び出すには /triage-bug-report を使います。 |
| Display name | ワークスペースに表示される、人が読めるラベルです。 |
| Description | そのワークフローをいつ適用するかを Okou に伝える 1 行です。Okou は受信したリクエストを説明文と照合するため、言い回しが重要です。 |
| Instruction | 手順そのものです。平易な文章で構いません。使うツール、出力の形、制約を記してください。 |
| Files | 任意の補助ファイルです。テンプレート、チェックリスト、ブランドガイドライン、参照データなどをワークフローにまとめて含められます。 |
| Visibility | private（自分のみ）または public（ワークスペース内の全員）。 |
ノードグラフも、YAML 設定も、トリガーのセクションもありません。指示文は、最初にうまくいったチャットのプロンプトにかなり似た形になることが多いです。
よい説明文は、ワークフローが必要なときに発火するか、まったく発火しないかの分かれ目です。"triage a customer-facing bug report and file it to GitHub with severity" の方が "do bug stuff." より適切です
所有権と公開範囲
My Okou: ワークフローは現在のワークスペースに存在します。Private Workflow は現在のユーザーに属します。Public Workflow はワークスペースのメンバーと共有されます。Public はインターネットに公開されることを意味しません。各実行では、実行するユーザーの個人用の指示（Instructions）、メモリー、接続済みアカウント、権限が使われます。手順を共有しても、それらの個人的なリソースや private な結果は共有されません。
同名のプライベートワークフローは、パブリックワークフローより優先されます。特定の共有定義を識別する必要がある場合は、明示的なワークフロー ID を使用してください。非公開コピーを作成を使うと、調整用の別バージョンが作成されます。後から加えた編集は元のワークフローと同期されません。他のメンバーのオートメーションはコピーされません。プライベートワークフローを作成しても、パブリックワークフローを公開または管理する権限が与えられるわけではありません。既存のワークスペースの公開ルールは引き続き適用されます。
Legacy Agents: すべてのワークフローは 1 つのエージェントに属します。チームメイトも、その所有エージェントへのアクセスが必要です。Copy workflow は保存先のエージェントを選び、private なフォークを作成します。エージェントは自身のプロフィールと個人用の指示（Instructions）を提供し、実行では引き続き実行中メンバーの認可済みアカウントアクセスが使われます。
固定の Instructions については、My Okou と従来のエージェント（Legacy Agents） を参照してください。
どちらの体験を使っていますか？
このドキュメントは両方の体験を扱います。Settings → Personal → My Okou が利用できる場合は、My Okou の手順に従ってください。New agent がある Agents ページを使っている場合は、従来のエージェント（Legacy Agents） の手順に従ってください。利用可否はメンバーごとに異なる場合があります。このドキュメントがあなたの体験を変えることはありません。
どちらの体験でも、複数のチャットやタスクを同時に実行し、ワークフローを再利用し、レビュー済みの作業をチームと共有できます。実行時サブエージェントは実行ツールであり、別途作成すべき独立した製品プロファイルではありません。
ワークフローの作成
ワークフローページから始める
- ワークフロー を開きます。My Okou: Create in chat を選びます。従来のエージェント（Legacy Agents）: 表示されている場合は New workflow を選びます。
- My Okou: 自分のチャットで続けます。エージェントの選択は不要です。従来のエージェント（Legacy Agents）: ワークフローを所有するエージェントを選びます。
- Okou が、ガイド付きのワークフロー作成プロンプトでチャットを開きます。結果、想定される入力、ツール、出力、許可の境界を説明してください。
- Okou が作成する前に、提案された名前、説明、指示文、ファイル、公開範囲を確認します。
既存のチャットから始めて、すでにうまくいったタスクをワークフローに変換するよう Okou に依頼することもできます。最初に成功した実行を同じチャットに残しておくと、Okou が取り込む具体的な入力、修正、出力を把握しやすくなります。
My Okou の例: ワークフローの指示文は、繰り返し使える仕事を説明します。
指示文に何を書くか
| 部分 | 含める内容 |
|---|---|
| Goal | ワークフローが生成しなければならない結果。 |
| Inputs | 呼び出し元や自動化が提供するものと、必須の入力。 |
| Procedure | 接続済みサービスのどれを読み取り、更新するかを含む順序立てた手順。 |
| Output | 必要な形式、保存先、命名規則。 |
| Boundaries | 避けるべき操作、確認が必要なケース、いつ止めるか。 |
| References | 任意のテンプレート、チェックリスト、またはワークフローファイルとして添付する例。 |
資格情報は指示文やファイルに含めないでください。サービスは コネクター で接続し、接続済みアカウントを確認したうえで、ワークフローに必要な権限だけを付与します。従来のエージェント（Legacy Agents）では、その所有エージェントも認可してください。
自動化する前にテストする
- 代表的な入力でワークフローを手動実行します。
- 実行するメンバーに必要なアカウントアクセスと権限があることを確認します。従来のエージェント（Legacy Agents）では、所有エージェントの認可も確認してください。
- 結果のチャットを確認し、コンテキスト不足、想定外の書き込み、最終出力の形を点検します。
- Instructions または添付ファイルを編集し、結果が再現可能になるまで再実行します。
- 手動実行が正しくできてから、自動化を追加します。まずは狭いイベントフィルターか低頻度のスケジュールから始め、最初の数回の発火を確認します。
手動検証を行うと、ワークフローの問題とトリガーの問題を切り分けられます。Run now が失敗するなら、まずワークフローまたはそのアクセスを修正してください。Run now は成功するのにイベントが発火しない場合は、自動化の設定を確認します。
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— あらゆる対象に合わせた進捗レポートとステークホルダー向け更新
あなた自身のワークフローはこれらと並んで存在し、説明文がより近く一致する場合にはそちらが優先されます。
作るべきタイミング
正直なルールはこれです。ほぼ同じプロンプトを 2 回を超えて書いたなら、あるいはチームメイトが書く場面を想像できるなら、保存してください。
具体的なサイン：
- その仕事には、チームですでに使っている名前がある（「朝のブリーフ」「競合調査」）
- プロンプトに、毎回変わるべきでない特定のツール、チャネル、テンプレートが書かれている
- 出力の形が固定されている（要約、下書き、登録済み issue など）
- 2 人以上がそれを起動する必要がある
- スケジュールまたはイベントで実行したい — オートメーション を参照
よくあるパターン
- インテークフォーム。 入力の一部（メール、バグ報告、スレッド）を受け取り、構造化された成果物（issue、下書き、行）を生成します。
- 定期ブリーフ。 スケジュールされた自動化と組み合わさったワークフローで、毎日または毎週実行され、見える場所に投稿されます。
- 会話の途中で助けるもの。 チャンネル内の
@Okouによって起動され、1 つの集中的なサブタスク（検索、要約、分類）を行います。 - コンポーザー。 1 回の実行で、ブログ下書き、ソーシャル投稿、カードなどの複数形式のバンドルを生成します。
- イベント応答者。 イベント自動化と組み合わされます。新しいメール、マージされた PR、新しい Notion ページが実行を開始します。オートメーション を参照してください。
避けるべき落とし穴
- 狭すぎる。 特定の 1 入力にしか合わないワークフローは脆いです。1 つの例の詳細ではなく、仕事の形そのものを狙ってください。
- 曖昧すぎる。 「マーケティングを手伝う」 は範囲が広すぎて、Okou はいつ適用すればよいかわかりません。説明文では具体的にしてください。
- 資格情報の直書き。 API キーを指示文に貼り付けないでください。代わりに custom connectors を使ってください。資格情報はプラットフォーム上に保持され、モデルからは触れません。
- 出力の形が埋もれている。 成果物がどう見えるべきかを明記してください。たとえば 「3 項目の番号付きリスト」 や 「150 語未満の返信案」 です。
- アクセスを忘れる。 共有ワークフローはコネクターへのアクセスを付与しません。接続済みアカウント、要求された権限、利用可能なチャットのアカウント制御を確認してください。従来のエージェント（Legacy Agents）では、所有エージェントの認可設定も確認してください。
