Okouでワークフローの手順を作成する

白紙のページからワークフローの手順を書く必要はありません。まず、エージェントを使って実際のタスクを完了してください。結果が役立つものになったら、共同で作り上げた方法を再利用可能なワークフローに変えるようエージェントに依頼します。

最初の下書きはエージェントが作成します。あなたの役割は、その前提を確認し、別のチームメンバーが信頼できる結果を得られるように、ワークフローのどこにより明確な制約が必要かを判断することです。

My Okou では、個人用の指示（Instructions）に各メンバーの好みが保持され、ワークスペースのワークフローには再利用可能な手順とチーム標準が保持されます。非公開ワークフローは現在のユーザーに属し、公開ワークフローはワークスペース内で共有されます。実行では、実行するメンバー自身の個人用の指示（Instructions）、メモリー、アカウント、権限が使われます。Legacy Agents では、ワークフローは引き続き1つのエージェントに紐づきます。Instructions と利用体験モード を参照してください。

成功した実行から始める

エージェントがタスク、ソース資料、あなたのフィードバック、そして受け入れ可能な結果を見ていれば、ワークフローは作成しやすくなります。

1. エージェントに実際のタスクと、それに必要な実際の入力を与えます。
2. 結果を確認し、足りないコンテキスト、弱い推論、または間違った形式を修正します。
3. 結果が良ければ、再利用可能な方法を抽出するようエージェントに依頼します。
4. ワークフロー名、説明、手順、そして推奨される参照ファイルがあればそれらの下書きをエージェントに作成させます。
5. ワークフローを公開する前に、下書きを一緒に確認します。

次のように依頼できます:

いま行ったことを、チーム向けの再利用可能なワークフローに変えてください。名前、説明、手順の下書きを作成してください。再利用可能な方法と、このケースにだけ当てはまる詳細を分けてください。最終確定する前に、私が確認すべき前提条件と制約を一覧にしてください。

これにより、下書きを作成する役割はエージェントに、どの部分を制御すべきかを判断する役割はあなたに与えられます。

制約を置く一般的な場所としてのワークフローの指示

ワークフローの手順はワークフローに付随し、実行されるたびに適用されます。そのため、必要な入力、承認済みソース、出力形式、品質基準、確認が必要なアクションなどの制約を定義する最も一般的な場所の1つです。

ただし、これだけが制御層ではありません:

手順の文面をアクセス制御の代わりとして頼りにしないでください。あるアクションを技術的に制限する必要がある場合は、明確な手順に加えて、実際のコネクタ認可と名前付き権限を使ってください。

エージェントの最初の下書きを確認する

すべての文を言い換える必要はありません。チームにとって重要な判断に確認を絞ってください。

いつ使うべきか?

• どの依頼や状況でこのワークフローを選ぶべきですか?
• どのような場合にエージェントはこれを使うべきではありませんか?
• 説明は、似たワークフローと区別できるほど具体的ですか?

どの入力が必要か?

• 作業を始める前に、チームメイトは何を提供する必要がありますか?
• どの不足入力があれば、エージェントは質問すべきですか?
• どの詳細が、永続的な手順ではなく各実行に属しますか?

どのソースとルールが優先されるか?

• 正本は何ですか?
• 承認済みのルーブリックまたはテンプレートが入っている添付ファイルはどれですか?
• 2つのソースが矛盾する場合、どちらが優先されますか?
• エージェントは、検証できない事実をどのようにラベル付けすべきですか?

出力はどのような形であるべきか?

• 必要なセクションや項目はどれですか?
• どの程度の詳細が有用ですか?
• 出力に引用、リンク、または信頼度ラベルは必要ですか?
• 宛先が指定されている場合、結果はどこに送るべきですか?

エージェントはどこで止まるべきか?

• どのアクションに確認が必要ですか?
• 送信や公開の代わりに、エージェントは下書きを作成すべきですか?
• どのデータが公開ワークフローや共有結果に表示されてはなりませんか?

これらは、明示しておく価値のある制約です。文言はエージェントに任せつつ、その文言があなたの判断を反映しているか確認してください。

一緒に確認するための構成

エージェントは最初の下書きに次の構成を使えます。これは、あなた自身が埋めるべきフォームではなく、確認用の枠組みとして扱ってください:

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

単純なワークフローなら、必要なのは少数のセクションだけかもしれません。重要度の高いワークフローでは、より明示的なソース、検証、承認のルールが必要になる場合があります。チームが依存する判断を隠さない範囲で、手順をできるだけ短く保つようエージェントに依頼してください。

例: リード選別ワークフローを共同作成する

1件のインバウンドリードを調査して返信案を作るよう、エージェントに依頼したとします。実行の途中で、会社規模を修正し、CRM が正本であることを説明し、チームの ICP ルーブリックを適用し、より短いメールを求めます。

結果が承認されたら、その会話をワークフローに変えるようエージェントに依頼します。エージェントが手順を下書きします。次に、このリードを超えても残すべき制約を追加します:

• 公開情報を調べる前に CRM を確認する;
• スコアリングには添付の ICP ルーブリックを使う;
• 会社規模、所在地、現在の役職の情報源を引用する;
• 検証できない必須事実は Unknown とラベル付けする;
• Account summary、Evidence、ICP score、Risks、Recommended next step、Reply draft を返す;
• メールの下書きを作成し、確認なしに決して送信しない。

これで、エージェントはそれらの判断を手順に組み込めます。研究のすべての手順を細かく指定する必要はありません。チームのソース、出力契約、承認境界をあいまいでないものにする必要があります。

制約に関するフィードバックは平易な言葉で伝える

エージェントに、何を変えるべきかを伝えることで下書きを絞り込めます:

• 「CRM レコードがない場合は、開始前にそれを求めてください。」
• 「会社名が食い違う場合は、CRM を正本として扱ってください。」
• 「要約内のすべての事実主張には、ソースリンクが必要です。」
• 「返信は 150 語未満にしつつ、インバウンドメッセージに合わせてトーンを調整してください。」
• 「メールは下書きとして作成してください。自動送信はしないでください。」
• 「このワークフローは既存の商談では実行しないでください。」

どの制約に各変更が対応しているのかを要約して、ワークフローを更新するようエージェントに依頼してください。そうすると、誤解されたルールや、誤ったセクションに置かれたルールを見つけやすくなります。

手順の外に置くべきものを保つ

一部の情報は、永続的なワークフローテキストにしてはいけません:

• 顧客名、一度きりの期限、ケース固有の送付先は実行リクエストに属します;
• パスワード、トークン、秘密の認証情報は、手順や添付ファイルに属しません;
• スケジュールやイベントは 自動化 に属します;
• 技術的なアクセス境界は、コネクター認可と名前付き権限に属します;
• 1つの結果にだけ適用される個人的なフィードバックは、そのチャットに残してかまいません。

手順には、再利用可能な方法と行動上の制約を含めるべきであり、作業を取り巻くすべての詳細を含めるべきではありません。

一緒にテストして洗練する

少なくとも2つの現実的な入力で、できれば2人目のチームメイトと一緒にワークフローを実行してください。各実行の後で、次のことを尋ねます:

• ワークフローは正しいタスクで起動しましたか?
• 必要な入力を要求しましたか?
• 意図したソースの優先順位に従いましたか?
• 結果は、硬直しすぎずに一貫していましたか?
• 必要な承認境界で停止しましたか?
• 問題は繰り返し発生しますか、それともこのケースにだけ当てはまりますか?

繰り返し使える不足に対しては、手順を改訂するようエージェントに依頼してください。1回限りの修正は実行に残してください。その方法が元の作成者以外の人にも有効になったら、ワークフローをチームと共有してください。