Asana が no-code agent builder の StackAI を買収したことは、明確な方向性を示しています。agent はチャット画面の中だけに留まらず、タスク、プロジェクト、承認、部門をまたぐワークフローの中に組み込まれていきます。

これはチームにとって魅力的です。以前ならコードを書かなければつなげなかった流れを、データソース、モデル、アクション、レビュー手順まで no-code で接続できるかもしれません。しかし同時に課題も出てきます。各部門が自分たちで agent を作れるようになったとき、その agent がどのデータを読み、どのタスクを変更し、失敗したときに誰が責任を持つのでしょうか。

できるかどうかではなく、引き継げるかどうか

no-code agent builder では「引き継ぎコスト」が過小評価されがちです。ある自動化は賢く見えても、実際には特定の入力でたまたま成功しているだけかもしれません。プロジェクト管理ツールの中に入ると、期限切れのタスク、権限不足、欠けたフィールド、複数人による同時編集といった現実の問題に直面します。

導入前に、まず次の3点を管理します。

  1. 入力の境界：agent はどのプロジェクト、フィールド、添付ファイル、顧客データを読めるのか。デフォルトで全開にしないこと。
  2. 出力形式：出力はタスク、コメント、ステータス更新、ドラフトのどれなのか。フィールドは固定し、毎回自由に生成させないこと。
  3. 人間のゲート：ステータス変更、メッセージ送信、顧客への影響、支出を伴う操作は、まず review mode から始めること。

小さなチームでの使い方

この種のツールを試すなら、最初のワークフローに「会社全体で最も複雑な問題」を選ばないでください。週次のプロジェクト状況サマリー、問い合わせの分類、会議後の ToDo 整理など、低リスクで、戻せて、形式が固定されたタスクを選びます。まず agent にはドラフトだけを作らせ、書き込み権限は少しずつ開放します。

本当に価値があるのは、すべてを自動化することではありません。「安全に自動化できる部分」を切り出すことです。これは no-code agent builder が玩具から業務システムへ進むときに、最も補う必要がある学びでもあります。

参考來源