ドキュメントに戻る対象ユーザー

エージェントとワークフロー手順を作成する

エージェントと共同でワークフロー手順を作成し、入力・情報源・出力・品質・承認範囲の制約箇所を確認します。

最終更新日: 2026年10月29日 · 2 min read

ワークフロー手順を最初から書く必要はありません。まずはエージェントと実際のタスクを完了させてください。結果が有用であれば、その方法をエージェントに再利用可能なワークフローへ変換するよう依頼しましょう。

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

すべてのワークフローは1つのエージェントに属します。エージェントは広範な役割と能力を提供し、ワークフローは1つの繰り返し可能なタスクの手順と制約を記録します。

成功した実行から始める

エージェントがタスク、資料、フィードバック、そして許容できる結果を経験した後の方が、ワークフローは作成しやすくなります。

  1. エージェントに実際のタスクと必要な入力を与えます。
  2. 結果を確認し、足りない文脈や弱い推論、不適切な形式を修正します。
  3. 結果が良ければ、エージェントに繰り返し可能な方法を抽出するよう依頼します。
  4. エージェントにワークフロー名、説明、手順、おすすめの参照ファイルの下書きを作成させます。
  5. ワークフローを公開する前に、一緒に下書きを確認します。

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

今行った作業をチーム用の再利用可能なワークフローにしてください。名前、説明、手順を下書きしてください。再利用可能な方法と、このケース固有の詳細を分けてください。最終化前に、私が確認すべき前提と制約をリストアップしてください。

これにより、エージェントが下書きを作成し、あなたがどの部分を管理すべきか判断する役割分担ができます。

手順は制約を定義する一般的な場所

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

ただし、これだけが制御レイヤーではありません:

レイヤー制約する内容例
説明ワークフローを選択すべきタイミング新規インバウンドリードの調査・評価用。既存案件には使用しない。
手順タスクの実施方法まずCRMを確認し、公的な主張を引用し、ICPルーブリックに従い、送信せず下書きを作成する。
ファイル方法が従うべき安定した参照ICPルーブリック、承認済み例、レポートテンプレート、製品用語集
エージェント権限エージェントが実際に許可されている外部アクションCRM記録の閲覧、メール下書きの作成(送信は不可)
実行リクエストこのケース固有の入力と範囲このリードを評価、このCRM記録を使用し、結果をこのチャットに返す。
自動化ワークフローの実行タイミングと実行者平日毎日09:00に実行し、結果を指定チャンネルに投稿。

アクセス制御の代わりに手順テキストだけに頼らないでください。技術的に制限が必要な場合は、エージェントの認可や権限設定と明確な手順の両方を使用してください。

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

すべての文を自分で書き直す必要はありません。チームにとって重要な判断点に集中して確認しましょう。

いつ使うべきか?

  • どのリクエストや状況でこのワークフローを選択すべきか?
  • どんな場合にエージェントは使うべきでないか?
  • 説明は類似ワークフローと区別できるほど具体的か?

必要な入力は?

  • 作業開始前にチームメンバーが必ず提供すべきものは?
  • 入力が不足している場合、エージェントはどのような質問をすべきか?
  • 各実行ごとに必要な詳細と、恒久的な手順に含めるべきでない詳細は?

どの情報源とルールが優先されるか?

  • 正式な記録システムは何か?
  • 添付ファイルのどれが承認済みルーブリックやテンプレートか?
  • 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.

シンプルなワークフローなら数セクションで十分です。重要度の高いワークフローでは、情報源、検証、承認ルールをより明確にする必要があります。エージェントには、チームが依存する判断を隠さず、できるだけ簡潔に手順をまとめるよう依頼しましょう。

例:リード評価ワークフローを共同作成

例えば、エージェントにインバウンドリードの調査と返信案の作成を依頼したとします。実行中に、会社規模を修正し、CRMが正式な記録システムであることを説明し、チームのICPルーブリックを適用し、メールを短くするよう指示します。

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

  • 公開調査の前にCRMを確認する;
  • 評価には添付のICPルーブリックを使用する;
  • 会社規模、所在地、現職の情報源を明記する;
  • 未検証の必須事項には「不明」とラベル付けする;
  • アカウント要約、証拠、ICPスコア、リスク、推奨次ステップ、返信案を返す;
  • メールは下書きのみ作成し、確認なしに送信しない。

これらの判断をエージェントが手順に組み込めるようになります。すべての調査手順を細かく指示する必要はありません。チームの情報源、出力条件、承認範囲を明確にすることが重要です。

制約フィードバックは平易な言葉で

下書きをより厳密にするには、エージェントに変更すべき点を伝えます:

  • 「CRM記録がない場合は開始前に必ず依頼してください。」
  • 「会社名が矛盾する場合はCRMを正式記録としてください。」
  • 「ブリーフ内の事実にはすべて情報源リンクを付けてください。」
  • 「返信は150語以内にし、インバウンドメッセージのトーンに合わせてください。」
  • 「メールは下書きとして作成し、自動送信は絶対にしないでください。」
  • 「このワークフローは既存案件には実行しないでください。」

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

手順に含めるべきでない情報

一部の情報は恒久的なワークフローテキストにすべきではありません:

  • 顧客名、単発の締切、ケース固有の宛先は実行リクエストに含める;
  • パスワード、トークン、秘密情報は手順や添付ファイルに含めない;
  • スケジュールやイベントは自動化に含める;
  • 技術的なアクセス制限はエージェントの認可・権限に含める;
  • 個別のフィードバックはそのチャット内に留める。

手順には再利用可能な方法と行動制約のみを記載し、作業を取り巻くすべての詳細は含めないでください。

一緒にテスト・改善する

ワークフローを少なくとも2つの現実的な入力で実行し、できれば2人目のチームメンバーと試してください。各実行後に次を確認します:

  • 適切なタスクでワークフローが起動したか?
  • 必要な入力を要求したか?
  • 意図した情報源の優先順位に従ったか?
  • 出力が一貫していて、硬直的になっていないか?
  • 必要な承認範囲で停止したか?
  • 問題は再現性があるか、それともこのケースだけか?

エージェントに繰り返し発生するギャップを手順に反映させましょう。単発の修正は実行内に留めます。方法が作成者以外にも機能するようになったら、ワークフローをチームと共有してください。