WrikeのAIエージェント

スペース設定の概要で AIエージェント タブ 2 を選択し、開始 3 をクリックします。

ドロップダウン 4 から トリアージ、インテイク、リスク のいずれかのエージェントタイプを選択するか、+ カスタムAIエージェント 5 をクリックして独自のカスタムエージェントを作成します。

詳細を設定します:

1. エージェントに名前を付けます。 エージェントにわかりやすい名前を付けます。これは場所に割り当てる際の @ハンドル として使用されます。

2. 一般的な指示 セクションで、エージェントの役割、目的、ロジック、想定されるアクション、フォールバック動作を記述します。 動作を明確にするために、入力と出力の例を追加するとよいでしょう。

   例: 「あなたはプロジェクトアシスタントとして行動します。」 「担当作業を監視し、リスクをフラグし、作業アイテムを更新して明確で実行可能なコメントを残すことでチームの足並みをそろえます。」

3. エージェントをいつトリガーするかを選択します:

   • スケジュール型エージェント（例: リスク状況レポーター）: エージェントの実行頻度を設定します（日単位、週単位、または カスタム）。
   • イベントベース型エージェント: 新規アイテム作成 や フィールド値の変更（ステータスや他のフィールド）などのトリガーを選択します。
   • 日付ベース型エージェント: 「期限の 3 日前」や「開始日になったとき」など、日付フィールドの値に基づいてエージェントをトリガーします。 日付および日時のカスタムフィールドで機能し、稼働日計算もサポートします。 リマインダー、エスカレーション、期限ベースのアクションに最適です。
   • API トリガー型エージェント: Wrike API を介して行われた変更でもエージェントがトリガーされ、外部システムとの統合が可能になります。
   • Wrike Automations との統合: エージェントは Wrike Automations と双方向に連携します。 従来の自動化ルールがエージェントをトリガーでき、エージェントのアクションが自動化ルールを起動することもできます。 これにより、AI の推論とルールベースの自動化を組み合わせた複雑な複数ステップのワークフローが実現します。

   注

   AIエージェントは、次のカスタムフィールドタイプを読み取り、反応できます: テキスト、数値、パーセント、通貨、日付、単一選択、複数選択、期間、チェックボックス、データベースへのリンク、ミラー、計算済みフィールド。

   カスタムフィールドに加えて、エージェントは次の内容を読み取ることができます:

   • 作成者と担当者
   • 空のカスタムフィールド - エージェントは存在する情報だけでなく、欠けている情報についても推論できます。
   • 計算済みフィールド - 容量、作業負荷、予定時間など、エージェントが直接アクセスできないシステムデータを公開できます。
   • 親アイテムのカスタムフィールド - エージェントは親タスクまたはプロジェクトのカスタムフィールドを読み取ることができます。
   • 同レベルおよびサブタスク - エージェントは同レベルのアイテムとサブタスクを確認してアイテム間の推論を行えます。
   • 場所のコンテキスト - エージェントはスペースとアカウント階層内での位置を把握しています。

4. トリガーが発生するスコープを設定します:

   • エージェントが追加された作業アイテムのあらゆるサブアイテム:

     インテイクやトリアージのようなタスクレベルのアクションに使用します。 エージェントはサブアイテムの変更に反応し、そのサブアイテムに対してアクションを実行します。

     例: インテイクエージェントを「Incoming Requests」フォルダーに追加します。 このフォルダーに新しいサブアイテムが追加されると、エージェントがトリガーされ、担当者や期限などの必須情報がすべて入力されているかを確認します。 不足がある場合、エージェントはそのサブアイテムにコメントを投稿して知らせます。

   • エージェントが追加されたアイテム:

     リスクレポートなどの集約アクションに使用します。 エージェントはこのアイテムの変更に反応し、このアイテム自体に対してアクションを実行します。

     例: カスタムエージェントを「Product Launch」プロジェクトに追加し、プロジェクトの変更をフォロワーに通知します。 プロジェクトのカスタムフィールドが変更されると、エージェントはその変更についてプロジェクトにコメントを投稿し、フォロワー全員を @メンション します。

5. アクションを定義します:

   • コメントを投稿: エージェントは関連アイテムに分析結果や決定事項をコメントとして共有します。

   • フィールド値を更新: エージェントは 担当者、カスタムフィールド、アイテム名、ステータス などの特定フィールドを更新します。

     • カスタムフィールドを変更: エージェントが指定したカスタムフィールドを更新します（更新するフィールドを選択）。

       注

       AIエージェントが更新できるカスタムフィールドタイプ: テキスト、単一選択、複数選択、数値、パーセント、通貨、データベースへのリンク、チェックボックス、日付。

       読み取り専用（エージェントは書き込み不可）: ミラーフィールドおよび計算済み/数式フィールド。 エージェントはこれらの値をコンテキストとして読み取ることはできますが、更新はできません。 人物タイプのカスタムフィールドは、エージェントが読み書きできません。

       時間コンポーネントを含む日付フィールド（Labs 機能）は、エージェントのアクションではサポートされていません。 これらのフィールドは、エージェントを設定する際のカスタムフィールドピッカーに表示されません。 エージェントを含むアクションに設定済みの日付フィールドが後から時間を含む形式に変更された場合、そのアクションは実行のたびに失敗します。

     • 担当者を変更: エージェントはプロンプトに基づいて作業アイテムをユーザーに割り当てます。 エージェントはユーザープロファイル属性（役職、部署、国、タイムゾーン、割り当てタスク数）およびユーザーグループの所属を確認できるため、役割、所在地、部署、グループによる割り当てが可能です。 エージェントはタスク数を除き、作業負荷やキャパシティのデータにはアクセスできません。
     • 作業アイテム名を変更: エージェントが分析に基づいてタスクまたはプロジェクトのタイトルを更新します。
     • ステータスを変更: エージェントが定義した条件に基づいてタスクのステータスを更新します。 標準ワークフローとカスタムワークフローの両方で機能します。

     • Link-to-Database レコードを選択: エージェントは Link-to-Database フィールドで選択されているデータベースレコードを変更できます。 エージェントがデータベースレコードから選択してアイテムを分類する必要がある場合に使用します。

       注

       データベースへのリンクのコンテキストアクセス:

       • L2DB フィールド変更アクション: エージェントはデータベース全体を検索できます。 列名ではなく値で検索します。
       • その他のアクション（コメント投稿、ステータス変更など）: エージェントはデータベース全体ではなく、現在選択されている値のみを参照します。

       例

       • ✅ 「値を含むレコードを選択」
       • ❌ 「列名が値であるレコードを選択」

     • 開始/期限日を変更: エージェントはタスクの開始日と期限日を変更できます。 タスクがブロックされた際に期限を延長したり、インテイク基準に基づいて開始日を設定したりするなど、期限管理のワークフローに使用します。

       プロンプト例:

       • 「ステータスが Blocked になったら、期限を 5 営業日後に延長する。」
       • 「必須フィールドがすべて入力されたら、開始日を今日に設定する。」

     • 場所: エージェントは設定時に定義したフォルダーへ作業アイテムを移動または追加できます。 このアクションを設定する際、特定のフォルダーやプロジェクトへの構造化参照であるロケーションチップを、アクションの指示テキストに直接埋め込みます。 エージェントは作業アイテムを分析し、それらのチップの中から適切な宛先を選択します。

       利用可能なモードは2種類あります:

       • 場所へ移動: 現在のフォルダーから項目を削除し、ターゲットフォルダーにのみ配置します。
       • 場所へ追加: 項目を現在のフォルダーに保持したまま、追加のフォルダーに追加します。

       プロンプト例:

       • 「タスクの説明に“legal”、“compliance”、“regulatory”が含まれる場合、タスクを Legal Review フォルダーに移動する。」

       • 「優先度が Critical に設定された場合、両チームが確認できるようにそのタスクを Urgent Queue フォルダーに追加する。」

         重要

         エージェントは、指示内でロケーション チップとして明示的に参照されたフォルダーにのみ項目を移動できます。 任意の場所へ項目を移動したり、新しいフォルダーを作成したりすることはできません。

       • 承認フローを開始または管理: エージェントはワークアイテムに新しい承認を作成するか、既存の下書き承認を更新します。 アクションの指示でユーザーチップを使用して承認者を指定できます。

         サポートされる承認アクション:

         • ワークアイテムに新しい承認を作成する
         • 既存の下書き承認を更新する
         • 承認者を追加または削除する
         • アイテムの作成者または担当者を承認者として選択する
         • ユーザーチップを使用して個々のユーザーまたはユーザーグループを承認者として指定する

         プロンプト例:

         • 「ステータスが Ready for Review に変更されたら、プロジェクト オーナーを承認者として承認を開始する。」
         • 「Budget フィールドが 50,000 を超えた場合、Finance Team ユーザーグループで承認を開始する。」
       • メールを送信（Gmail または Outlook）: エージェントは接続された OAuth アカウント経由でメールを送信します。 エージェントのセットアップ時に、スペース管理者が Gmail または Outlook アカウントを認証します。 エージェントは、ワークアイテムのコンテキストとアクション指示から件名、本文、宛先を作成します。

       • メールプロンプトの作成:

         プロンプトでは、誰にメールを送るかをエージェントに指示する必要があります。 受信者アドレスをどこから取得するかを明確に指定してください。

         エージェントは次の情報からメールアドレスを取得できます:

         • 担当者のプライマリ メールアドレス（例:「タスクの担当者に送信」）
         • 作成者のメールアドレス（例:「作成者に通知」）
         • メールアドレスを含むカスタムフィールドの値
         • メールアドレスを含むタスクのタイトルまたは説明
         • プロンプト内で明示されたアドレス（例:「intake@company.com に送信」）
         • 構成ルール（例:「名 + ドット + 姓 + @contoso.com」）

         エージェントは次の情報からメールアドレスを取得できません:

         • フォローしている人
         • セカンダリ メールアドレス

         件名と本文は空のままでもかまいません。プロンプトで指示した場合にのみ、エージェントが入力します。

         ヒント

         あいまいなプロンプトには注意してください。 「Update assignees on the project status」のようなプロンプトは、「担当者を変更する」という意味に解釈される可能性があり、「担当者にプロジェクトの状況をメールで送る」という意味にならない場合があります。 「担当者にプロジェクトの状況を要約してメールを送信する」のように、あいまいさのない表現を使用してください。

         プロンプト例:

         • 「ステータスが Blocked に変わったら、タスクをブロックしている内容の概要を割り当て先にメールで送信する。」
         • 「Incoming フォルダーで新しいタスクが作成されたら、タスクのタイトルと説明を含めて intake@company.com にメールを送信する。」

         • 「作成者のメールアドレスに期限超過のサブタスクをすべて含む週間サマリーを送信する。」

           重要

           1 つのメールアクションで複数の受信者（複数の \"To\" アドレス）に送信できます。 メールの制限: CC/BCC フィールドなし、添付ファイルなし、副次的メールアドレスなし、フォロワー用メールアドレスなし。 メッセージの送信者には接続されたアカウントが表示されます。

         • Slack で通知: エージェントはアクションとして Slack チャンネルにメッセージを投稿します。 エージェントのセットアップ時に、スペース管理者が Slack ワークスペースを接続し、Slack チャンネル チップを使用して対象チャンネルを選択します。 宛先チャンネルはセットアップ時に固定されます—各 Slack 通知アクションは 1 つのチャンネルにのみ投稿します。 エージェントはワークアイテムのコンテキストとアクションの指示を使用してメッセージ本文のみを作成します。

           重要

           Slack 通知を使用するには、エージェント設定で Slack ワークスペースを接続する必要があります。 接続を完了できるのはスペースの管理者のみです。 エージェントが投稿するすべてのチャンネルに Slack アプリがインストールされている必要があります。 Wrike の Slack アプリは Slack Marketplace に承認されています。Slack ワークスペースでサードパーティ アプリのインストールが制限されている場合は、接続を完了する前にワークスペース管理者が Slack Apps ディレクトリで「Wrike」を事前承認する必要があります。

           プロンプト例:

           • 「ステータスが Blocked に変更されたら、タスクを阻害している要因を要約して接続済みチャンネルに投稿する。」
           • 「Incoming フォルダーで高優先度のタスクが作成されたら、タスクのタイトル、担当者、説明を含めて接続済みチャンネルに投稿する。」

           例: ステータスが「At Risk」に変更されたときにトリガーされるエージェントは、タスク名、オーナー、阻害要因を含む通知をプロジェクトの Slack チャンネルに投稿でき、誰も Wrike に切り替えて確認する必要がありません。

           Slack 通知の制限事項: 1 アクションにつき 1 つのチャンネルのみ（V1 では複数チャンネルやダイレクトメッセージは非対応）、スレッド返信やスレッドの文脈保持なし、Slack ユーザーへの @メンション不可。

         • Microsoft Teams で通知: エージェントが Microsoft Teams のチャネルにメッセージを投稿します。 エージェントのセットアップ時に、スペース管理者が Microsoft Teams アカウントを接続し、対象チャネルを選択します。 宛先チャネルはセットアップ時に固定されます。各 Notify-on-Teams アクションは 1 つのチャネルに投稿し、実行時にエージェントがチャネルを選択することはありません。 エージェントはワークアイテムのコンテキストとアクションの指示を用いて、メッセージ本文のみを作成します。 メッセージは Wrike Microsoft Teams アプリによって配信され、Wrike のワークアイテムへのリンクが含まれます。 アクティビティログには配信ステータスとチャネル名が記録されます。

         プロンプト例:

         • 「ステータスが Blocked に変わったら、タスクをブロックしている内容を要約して接続済みの Teams チャネルに投稿する。」
         • 「Incoming フォルダーで高優先度のタスクが作成されたら、タスクのタイトル、担当者、説明を添えて接続済みの Teams チャネルに投稿する。」

               Microsoft Teams 通知の制限: チーム内のチャネルへの投稿のみ対応 — チャット（グループ DM）への投稿は未対応、Teams ユーザーへの @メンション不可、スレッドメッセージ不可、1 アクションにつき 1 チャネル。

   更新を実行する場所を選択します:

   • エージェントが追加されたワークアイテム: アクションは、エージェントが設定されている親アイテムを対象とします。
   • エージェントが追加されたワークアイテムのすべてのサブアイテム: アクションはすべての子アイテムを対象とします（1 回の実行につき最大 1,000 サブアイテム）。
   • トリガーが発生したワークアイテム: アクションはエージェントをトリガーした特定のアイテムを対象とします。
   • トリガーされたアイテムのサブアイテム: アクションは、エージェントをトリガーした特定のアイテムのサブアイテムを対象とします。 直接の子のみ（トリガーされたアイテムの 1 レベル下）。 使用例: ブループリントがインテーク フォルダー内にサブタスクを持つプロジェクトを作成する場合、エージェントはその新規プロジェクトのサブタスクのみに作用し、他のプロジェクトのサブタスクには作用しません。

   • ワークアイテムのフィルタリング

     アクションを適用するアイテムをフィルターします。各アクションにはフィルターピッカーがあり、Wrike の他の場所と同じフィルターコントロールを使用できます。 アイテムタイプ、ステータス、担当者、カスタムフィールド、重要度、名前などでフィルターでき、組み合わせも可能です。 フィルターに一致しないアイテムはスキップされ、エージェント クレジットは消費されません。

     これはアクションごとに設定されるため、同じエージェント内の異なるアクションで異なるフィルターを使用できます。 たとえば、あるアクションはステータス「New」のタスクのみを対象とし、別のアクションは完了したプロジェクトを対象とすることができます。

   ヒント

   エージェントがプロジェクトとタスクを両方含むフォルダーに任命されている場合、フィルターを使用して対象とするアイテムタイプにアクションを制限してください。

   注

   + Action をクリックして複数のアクションを追加できるため、エージェントは 1 回の実行で複数の更新を行えます。

   重要

   複数アクションの動作

   • アクションは独立しており、1 つのアクションの結果が他のアクションに影響することはありません。
   • 実行順序は保証されません。 Action 1、Action 2、Action 3 は任意の順序で実行される可能性があり、並列で実行されることもあります。 各アクションが最初に実行される可能性があると考えてください。
   • 各アクションは独自の指示を持ち、異なる場所（親アイテム、すべてのサブアイテム、またはトリガーされたアイテム）を対象にできます。
   • 一般指示はすべてのアクションで共有されますが、各アクションには固有のプロンプトがあります。
   • 設定やアクティビティログで識別しやすいように、各アクションに名前を付けることができます。 たとえば、汎用ラベルではなく「Set Priority」「Route to Team」「Post Summary」などの具体的な名前を付けましょう。 これは、エージェントが同種のアクションを複数持つ場合に特に有用です。

   プロンプト作成のポイント:

   • 各アクションのプロンプトは単独で機能し、ワークアイテムのフィールド、コメント、親コンテキスト、参照されたロケーション チップから情報を取得する必要があります。
   • 「前のアクションが投稿したコメントを読んでください」「Action 2 で計算した値を使用してください」「Action 1 が成功した場合は...」などの記述は避けてください。 Action 1 は存在せず、アクションが複数あるだけで、そのいずれが最初に実行されるかわかりません。
   • 2 つのアクションが同じ計算値（例: プロジェクト開始日と緊急度に基づくマイルストーン日）を必要とする場合は、それぞれのアクションが同じ情報源から独立して計算してください。 同じデータを読み取るため、結果は同一になります。

   Action B が本当に Action A の出力を必要とする場合、1 つのマルチアクション エージェントでは機能しません。 エージェントの連鎖を使用してください。Agent 1 がカスタムフィールドまたはステータスを書き込み、Agent 2 がその変更をトリガーとして次のステップを実行します。

   マルチアクション エージェントの適切なユースケース:

   • カテゴリ フィールドを設定し、分類コメントを投稿する（依存関係なし）
   • 担当者を変更し、ステータスを更新する（依存関係なし）
   • 複数のカスタムフィールドを同時に更新する

   ステータス変更を使用するタイミング:

   ステータス変更はワークフローを自動で進行させるのに最適です:

   • インテークの検証: 必須フィールドがすべて入力されたらステータスを Ready に変更します。
   • 期限超過の追跡: 期日を過ぎたタスクを Overdue としてマークします。
   • 依存関係の検出: コメントで依存関係が言及された場合、ステータスを Blocked に設定します。
   • プロジェクト完了: すべてのサブタスクが完了したらタスクを Complete に移動します。

   ステータス変更に関する重要な注意:

   • エージェントはワークフローの遷移ルールを尊重し、必須ステータスをスキップできません。
   • ステータス変更は、エージェントの理由付けとともにタスクのアクティビティ履歴に記録されます。
   • ステータスが既に正しい場合、エージェントはログエントリのみを作成し、重複コメントは残しません。
   • 標準の Wrike ステータスとカスタムワークフローステータスの両方で機能します。

   ステータス変更プロンプト例:

   • 期限超過タスクをマーク:

     タスクが期日を過ぎ、ステータスが Completed でない場合、ステータスを Overdue に変更します。

   • インテーク完了を検証:

     タスクで必須 3 フィールド（Budget、Assignee、Deadline）がすべて入力されたら、ステータスを New から Ready for Work に変更します。 既に Ready for Work または Completed にマークされているタスクは無視します。

   • ブロックされた作業を検出:

     コメントに「blocked」「waiting on」「dependency」が含まれ、ステータスが Blocked または Completed でない場合、ステータスを Blocked に変更し、タスクを阻害している要因を要約したコメントを投稿します。

6. Testing Playground で設定をテストし、エージェントがどのように推論し応答するかを確認します。 Playground の実行は AI 使用量制限に含まれないため、エージェントをデプロイする前にプロンプトや設定を自由に反復できます。
7. 作成をクリックしてエージェントを有効化します。

8. エージェントをロケーションに任命: エージェントを作成した後、稼働させたい特定のフォルダー、プロジェクト、またはタスクに任命する必要があります。 対象のロケーションに移動し、コメントストリームでエージェントを @メンション して有効化します。 エージェントは任命された範囲内のみを監視し、行動します。

   重要

   スペース設定でエージェントを作成するだけでは不十分です。@メンションして特定のロケーションに任命する必要があります。 この手順を行わないと、エージェントはアクティブになりません。