ワークフローに分類ノードを追加する(GitHub Copilot)

Note

この記事の機能は、GitHub Copilot harnessを搭載するエージェントやワークフローで使用されています。

使用率に基づく請求は、エージェントの使用、構築、テスト、評価に適用されます。 これらの行動はCopilotクレジットを消費することがあります。 詳細は「GitHub Copilot harnessで動くエージェントのコスト管理」をご覧ください。

分類ノードはテキストの一部を受け取り、あなたが定義したカテゴリのいずれかに分類します。 各カテゴリを平易な言葉で説明し、ノードはAIを使って入力が最も合うカテゴリーを判断します。 各カテゴリが独立したブランチとなり、結果に応じてワークフローが異なるアクションを取ることがあります。

固定されたフィールドやキーワードマッチではなく、フリーフォームテキストの 意味 (メール本文、フォーム提出、サポートメッセージ)に基づいて作業をルーティングする必要がある段階は、分類ノードを使いましょう。 一般的な使い方はメールのトリアージです。届くメッセージを読み、内容に応じて異なるルートに送ります。

分類ノードを使うことで、以下が可能です:

  • テキスト入力を自然言語で説明したいくつかのカテゴリーのいずれかに分類してください。
  • ワークフローを分岐させて、各カテゴリごとに異なるステップセットを実行させましょう。
  • 自動 デフォルト カテゴリと一致しないものはすべて検出してください。
  • 各カテゴリーごとに例の入力を提供して精度を向上させましょう。

分類ノードを追加

  1. Copilot Studioで、Flows に移動して既存のワークフローを開くか、新しいワークフローを作成します。

    • 新しいワークフロー: トリガーを構成するためにデザイナーにアクセスします。
    • 既存のワークフロー: ワークフローを開き、[ ビルド ] タブに移動します。
  2. 追加パネルで 分類 アイコンを選択してください。

  3. 分類ノードの設定パネルが開きます。

キャンバス上のノードは、カテゴリごとに1つの接続ポイントと、 その他(デフォルト )分岐を示しています。 各ブランチをそのカテゴリで実行すべきステップに配線します。

分類のための入力を提供します

「 Input to classify 」欄で、ノードに分類したいテキストを入力します。 動的コンテンツピッカーを使って、前のステップの文字列変数を挿入し、ノードが実際の実行時データを分類できるようにします。

例えば、新しいメールが届くとトリガーされるワークフローでは、トリガーの Body 変数に入力を設定し、各実行ごとに実際のメール内容を分類します。

入力は自由形式のテキスト用に設計されています。 複数の値を一緒に考慮したい場合(例えばメールの件名と本文)、動的コンテンツピッカーを使ってそれらをフィールドにまとめてください。

モデルを選択する

入力の分類フィールドのモデルドロップダウンを使って、分類をパワーアップするモデルを選択します。 モデルごとにパワーとスピードのトレードオフがあることを覚えておいてください:

  • カテゴリが複雑で混乱しやすい場合や、入力が長くて慎重な解釈が必要な場合は、より能力の高いモデルを選びましょう。 この場合、モデルの処理にはより多くの時間が必要です。
  • カテゴリが明確に区別され、ワークフローが大量に動作する場合は、より速いモデルを選びましょう。

カテゴリーを定義しましょう

カテゴリセクションで、ルーティングしたい結果ごとに1つずつエントリを追加してください。 各カテゴリーについて:

  1. このカテゴリーに短く説明的な 名前を付けましょう。 ノードを出る枝のラベルは名前になりますので、キャンバス上で認識できる名前(例えば Product issue や Account update)にしてください。

  2. 「 このカテゴリボックスに何が属するかを説明 」欄で、ここに属する入力の種類をわかりやすく説明してください。 明確な記述は正確な分類の最大の要素です。

「 カテゴリを追加 」を選択して、さらに作成してください。 明確に異なるカテゴリーを目指し、期待する入力を一つにまとめてカバーするものを目指しましょう。

デフォルトカテゴリー

定義したどのカテゴリとも明確に一致しない入力に対して、 デフォルトカテゴリが 自動的に作成されます。 ノード上で 「もう一方 の枝」として表示されます。 このカテゴリを適切なフォールバック先に紐付けて、何も気づかれずに取りこぼされないようにしましょう。 例えば、手動で確認するためにアイテムをルーティングしたり、記録したり、誰かに通知したりします。

精度向上のための例を追加(任意)

「Examples」では、サンプル入力とそれぞれが属するカテゴリを指定できます。 例はノードに境界線のケースの扱い方や、実際の入力が使う言語の種類を教えます。

例を挙げると:

  1. 「 例を追加する」を選択します。

  2. 「カテゴリ選択」で、その例が属するカテゴリを選択します。

  3. テキストボックス内に、そのカテゴリの代表的な入力を貼り付けるか入力してください。

混乱しやすいカテゴリーや、説明だけで正解が明らかでない例外的なケースの例を追加しましょう。 曖昧なカテゴリーごとに選ばれたいくつかの例は、長いリスト以上の効果をもたらします。

結果に対してワークフローを分岐させる

各カテゴリ( その他を含む)はノード上の独立した出力分岐です。 ノードが入力を分類した後、ワークフローはそのマッチングカテゴリの分岐を下って進みます。 各枝種ごとに必要なステップを追加してください:

  • 商品はカテゴリに応じて別のエージェント、メールボックス、またはキューに送ってください。
  • 一方のブランチでは終端アクション(例:削除やアーカイブ)を行い、他のブランチはフォローアップのためにルーティングします。
  • カラムまたはステータス値を設定し、共有された下流ステップを続けます。

特定の入力に対してはマッチングブランチのみが実行されるため、各パスはそのカテゴリに必要なものに合わせて調整できます。

自動化のシナリオ

分類ノードはルーティングステップとして最適です。自由なテキストが入り、ノードがその内容を決定し、各ブランチがそのケースを処理します。

メールの仕分け

ワークフローは「 新しいメールが届くと」でトリガーされます。 分類ノードはメール の本文 を入力として受け取り、 Product issue、 How-to question、 Account update、 Spam、 その他に分類します。 各ブランチはメッセージを正しい場所にルーティングします:

  • 製品問題:チケットを提出し優先順位をつける Issue Triager Agent 。
  • ハウツークエスチョン:知識ベースから回答を作成する ドキュメントレスポンダーエージェント 。
  • アカウント更新:変更を適用する アカウントアップサーエージェント 。
  • スパム:メール を削除する アクションで、メッセージを削除します。
  • もう一つは、メールを手動で確認するためにルーティングする代替手段です。

受信箱は一つ、ワークフローも一つで、すべてのメッセージが本来の場所に届き、誰も一つ一つ読んで整理することはありません。

受信するサポートリクエストのルーティング

ワークフローは、フォームや共有メールボックスを通じてリクエストが提出されるとトリガーされます。 分類ノードはリクエストテキストを読み取り、 Billing、 Technical、 Salesに分類します。 各ブランチはリクエストをマッチングチームのキューに割り当て、そのチームに通知するため、リクエストが途中でトリアージステップを省くことなく正しい人に届くようにします。

フィードバックを優先する

顧客がフィードバックを提出したときにワークフローが発動します。 分類ノードはコメントを Bug report、 Feature request、 Praiseに分類します。 バグ報告は作業項目を開き、機能リクエストはバックログリストに追加され、称賛はアカウントチームに転送されます。 この分岐により、単一のフィードバックチャネルが3つの個別化されたフォローアップに変わります。

よく寄せられる質問

分類ノードとエージェントノードはいつ使うべきですか?

分類 ノード は、テキストを既知のカテゴリのいずれかに分類し、その結果に分岐することだけの場合に使います。 分類ノードはこの作業専用に設計されており、設定も簡単でキャンバス上で読みやすいです。

ステップが分類だけでなく、複数の入力を解析したり、ツールを呼び出したり、知識から取得したり、構造化フィールドを返したりする必要がある場合にエージェント ノード を使いましょう。 エージェントは単一のステップで分類 ・ 行動できますが、その代償として設定が増えます。

入力がどのカテゴリにも当てはまらなかったらどうなりますか?

入力は自動デフォルトカテゴリ(Otherブランチとして表示されます)に送られます。 その分岐は常にフォールバックに配線して、マッチしない入力を処理できるようにしてください。

分類をより正確にするにはどうすればいいですか?

何が属し、何が該当しないかを明確に示す明確で明確なカテゴリー説明を書きましょう。 混乱しやすいカテゴリーの例を追加してください。 カテゴリーが微妙な場合は、より能力の高いモデルを選びましょう。 明確なカテゴリーと鋭い記述を持つカテゴリーの方が、カテゴリーの数よりも重要です。