AI PM・自動化SaaSの勢力図2026 — エージェント時代の競合分析

コラボ・AI実行・自動化がこぞってエージェントを載せた2026年、競争の軸は有無ではなく「どこに住み、誰が組み立てるか」。ONTLEの派遣型をその上に置く。
← 목록으로
박
박도현
2026년 10월 03일 更新 2026.10.16 読了 17分 閲覧 2

「AI PMサービス」という一語の下には、性格のまったく異なるいくつかの市場が混在している。コラボボードやドキュメントから出発したワークスペース、スケジュール配置を自動化する実行ツール、アプリとアプリをつなぐ自動化プラットフォーム、そしてプロジェクトごとに担当者をつける対話型・派遣型のアプローチまで。数年前なら「AIが入っているかどうか」で線引きしただろうが、2026年にはその問いはもう有効ではない。AsanaもNotionもMotionもZapierもMakeも、すでに自ら判断し行動するエージェントを自社製品の中に載せている。要約や下書きを手伝うだけの時代は終わった。

そこでこの記事は、「誰がエージェントを持っているか」ではなく、別の問いで勢力図を引き直す。そのエージェントはどこに住んでいて、それを組み立て管理する負担は誰が負うのか。この軸の上に立つと、各サービスの位置がくっきりし、ONTLEの派遣型ポジションがどこにあるのかも誇張なく見えてくる。

四つに分けると市場が見えてくる

A. コラボワークスペース — エージェントがボードの中に入ってきた

Asana、Monday.com、ClickUp、Jira、Notion、Linearがこのグループだ。もともとはチームが一緒に見るボード・ドキュメント・チケットのシステムであり、今もその骨格は同じ。変わったのは、その上に載ったAIの性格だ。

AsanaはAIを二つの形で載せている。ノーコードビルダー「AI Studio」では、入ってきたリクエストを分類し、担当者にアサインし、ステータスを更新し、必要なら人にエスカレーションする処理を、ワークフローの中にAIエージェントとして組み込んで設計できる。もう一つの「AI Teammates」は別立ての協業エージェントで、こちらには事前に用意された役割も提供され、必ずしも一から設計しなくても使える。Notionは2025年9月の3.0発表でエージェントを正式化した。このエージェントはドキュメントを作り、データベースを構築し、複数ステップにまたがる作業を実行する。つまりこのグループのAIは、もはや「要約してくれるアシスタント」にとどまらない。ワークスペースの中で実際にカードを作り、動かし、アサインする。

ただし位置ははっきりしている。そのエージェントは、チームが採用し維持するワークスペースの上で動作する。ここで一つ区別しておくべきことがある。同じグループの中でも、標準搭載のエージェントと設定型のエージェントは性格が異なる。Notionの標準エージェントはユーザーの既存の権限をそのまま引き継ぎ、対話で依頼を受けてドキュメント・データベース・成果物を作る。別途トリガーやワークフローをユーザーが設計する必要はない。逆に、Asana AI Studioで組み立てるワークフローや、Notionの設定型Custom Agentsのように、役割・権限・判断ポイントをユーザーが(ノーコードであっても)設計する形もある。一方でAsana AI Teammatesのように、事前役割が用意されていて設計の手間が軽い中間形もある。どちらにせよ、ワークスペースを採用・運用し、ボードに溜まっていくデータを管理する主体はチームだ。エージェントはこのグループ製品の強力な機能であって、製品の外から派遣されてくる人ではない。

B. AIネイティブな実行ツール — スケジュールを代わりに組む角度

Motionが代表格だ。人がやるべきことと締め切りを入れると、AIがカレンダー上にタスクを自動配置し、優先順位と衝突を調整する。この「時間配分をAIが決める」という角度がMotionのアイデンティティだ。

ここで原文が誤っていた部分を正しておく。Motionは個人のスケジュールだけを組むツールではない。List・Kanban・Ganttビューを備えた立派なプロジェクト管理ツールであり、チームのプロジェクトを共有し、タスクごとに担当者を指定する。担当者を置いてチームが同じプロジェクトを見る、といったコラボができない、という記述は事実と異なる。Motionの差別化ポイントは「チームが画面を見られない」ことではなく、標準的なPMビューの上にスケジュール自動化という意思決定レイヤーを載せたところにある。リクエストを対話で委任するアプローチとは毛色が違うだけで、コラボの可視性そのものが弱いわけではない。

C. ワークフロー自動化プラットフォーム — ルールの上にエージェントを載せる

ZapierとMakeは、もともとプロジェクト管理ツールではなく自動化プラットフォームだ。「このアプリでこのことが起きたら、あのアプリでこれを実行せよ」というトリガー→アクションのルールを設計しておけば、そのまま繰り返し実行される。このルールベースが今も土台であるのは確かだ。

だが「決めておいたルールの外のリクエストは判断できない」という記述は、現在の製品にはもう当てはまらない。Makeは2025年4月に「AI Agents」を発表した。ユーザーが自然言語で目標を書けば、エージェントが文脈に応じてどのツールを使うかを自ら選び、状況の変化に合わせて行動を調整する。Zapierのエージェントも平文の指示を受けて計画し、推論し、数千の連携を横断しながら自律的に実行する。初期にツールをつなぎ目標を定義する設定が必要だ、という事実と、あらゆる判断の分岐を人があらかじめ組まなければならない、という主張はまったく別の話だ。後者はもう間違っている。

正確な位置はこうだ。このグループは依然としてアプリとアプリをつなぐ自動化が中心であり、エージェントを使うとしても、そのエージェントの目標・ツール・ガードレールを組み立ててガバナンスする主体はユーザーだ。自動化プラットフォームの中に設置する知的な部品だと捉えると理解が早い。

D. 派遣型・対話型 — リクエストを受け付けて成果物まで

ONTLEは前の三つとは軸が違う。プロジェクトごとに専任のAI PMをアサインして、対話で入ってくるリクエストを受け付け、作業を管理し、成果物まで発行する。ユーザーはワークフローを設計しないし、エージェントにツールをつなぐこともしない。「これやって」と言い、結果を確認して承認する。組み立ての負担が製品側に移っている、というのがこのグループの特徴だ。

比較表で整理すると

区分 A. コラボワークスペース (Asana, Monday, ClickUp, Jira, Notion, Linear) B. AI実行ツール (Motion系) C. 自動化プラットフォーム (Zapier, Make) D. 派遣型・対話型 (ONTLE)
核となる軸 チームのコラボワークスペース スケジュール・時間配分の自動化 アプリ連携の自動化 リクエスト受付から成果物まで代行
AI・エージェントの役割 ワークスペース内で分類・アサイン・ステータス更新・複数ステップの作業を実行 スケジュール自動配置が中心、担当者アサイン・コラボビューも提供 自然言語の目標でツールを選ぶエージェントをルールの上に追加 対話でリクエストを理解し、作業管理と成果物生成まで
人が依然として担うこと ワークスペースの維持、設定型エージェントはワークフロー設計・ガバナンス、承認 優先順位の確認、スケジュールの受け入れ・調整、プロジェクトビューの管理 エージェントの目標・ツール・ガードレールの組み立て、例外のガバナンス リクエストの伝達、確認・承認
よく解ける問題 チーム全体の可視性、多人数コラボ、履歴管理 多忙な個人・チームの時間割の自動化 反復的・連続的なデータ連携と、その上での自律実行 実行人員が足りないチームの対話型委任
組み立て・設定の負担 チームがワークスペースを運用、設定型エージェントのみ設計・ガバナンス(事前役割つきなら軽い) ユーザーがビュー・スケジュールルールを設定 ユーザーが自動化・エージェントを組み立て・ガバナンス ONTLEが組み立てを引き受ける

「エージェントがあるかないか」の欄を消したことに注目してほしい。その欄は今や四つとも「ある」で埋まるので、識別力がない。実際に差が出るのは下の二行、「人が依然として担うこと」と「組み立て・設定の負担」だ。

オフィスの比喩で見ると違いが鮮明になる

コラボワークスペースは会議室のホワイトボードだ。最近のホワイトボードは、付箋を貼ると要約を整理してくれるだけでなく、言えば付箋を代わりに動かし、新しいボードを開いてくれるアシスタントまで付いている。それでもそのホワイトボードは自分の部屋にあり、アシスタントに何ができるかを決めて管理するのは自分だ。

AI実行ツールは、手帳にやることを書いておくと秘書が時間割に配置してくれるのに近い。その秘書はチーム共用のボードを一緒に整理することもできる。ただし秘書の得意分野は「いつやるか」を決める方だ。

自動化プラットフォームは、かつては決められたルール通りに手紙を仕分けする郵便室だった。今はその郵便室に「こういう目的で処理して」と書いておけば、自分で判断して引き出しを選ぶ担当者を置くこともできる。肝心なのは、その郵便室と担当者を自分が自分のオフィスに設置して運用する、という点だ。

ONTLEのような派遣型アプローチは、家具を新しく買ったり郵便室を構えたりすることではない。プロジェクトに派遣社員を一人迎えるのに近い。「この仕事お願い」と言えば、その担当者がリクエストを受け付け、仕事を回し、成果物を作ってくる。ホワイトボードを買うのか、担当者を呼ぶのかの違いだ。

ツール選びの観点 — 弱い例/強い例

エージェントの有無だけ見て、どれも同じと片づけてしまう場合

  • 弱い例: 「もうどこもエージェントがあるのだから、マーケティングが派手なものを選べばいい」と、そのエージェントが何の上で動き、誰が設計・管理しなければならないのかを吟味せずに導入する。結局、ツールによってはワークフローを自分で設計・運用しなければならないという事実に後からぶつかる。
  • 強い例: エージェントがどこに住むのかから問う。自分が維持するワークスペースの上なのか、自分が組み立てる自動化の上なのか、それとも対話で委任する派遣担当者なのか。そして、その設定・ガバナンスの負担を自分たちのチームが背負えるかで判断する。

ツールの実際の守備範囲を確認せずに決めつける場合

  • 弱い例: Motionをスケジュール自動配置用としてだけ使い、「チーム単位のプロジェクト管理はできないね」と決めつける。実際にはList・Kanban・Ganttビューと担当者アサインをすでに提供しているのに、使ってみなかっただけだ。
  • 強い例: 導入前に各ツールの公式ドキュメントでビュー・担当者・コラボ機能の実際の守備範囲を確認し、すでにある機能を最大限活かしたうえで、足りない分だけ別のアプローチで埋める。

設定・ガバナンスの負担を計算に入れない場合

  • 弱い例: ノーコードのエージェントビルダー(Asana AI Studio、Make・Zapierのエージェント)を「設定なしで勝手に全部やってくれるもの」と期待し、役割・ツール・ガードレールを定義して例外を管理する運用負担に疲れる。
  • 強い例: プラットフォーム内蔵のエージェントを使うときは、設計・ガバナンスの工数を最初から予算に入れるか(事前役割つきのAI Teammatesのように負担が軽い選択肢があるかも確かめる)、その組み立ての負担自体を手放したいなら、対話で委任する派遣型を選ぶ。

ONTLEはこの勢力図のどこにいるのか

A・B・Cグループのエージェントは、共通して「ユーザーが運用する製品の中に住む機能」だ。Asana AI StudioのワークフローもAI Teammatesも、Motionのスケジューラも、Make・Zapierのエージェントも、結局はユーザーがそのツールを採用し、データと例外を管理するという前提の上で動作する。役割・権限をユーザーがどれだけ設計しなければならないかは製品によって異なる。Notionの標準エージェントのようにユーザーの権限をそのまま引き継いで対話だけで成果物を作る場合もあれば、Asana AI Teammatesのように事前役割が用意されていて設計の手間が軽い場合、Asana AI Studioや設定型Custom Agentsのように役割・権限・ガードレールを自分で設計しなければならない場合もある。共通するのは、そのエージェントがユーザーの採用・運用する製品の中の機能であること、そしてその製品を運用する主体が人であること、だ。

ONTLEはその前提を動かす。プロジェクトごとに専任のAI PMをアサインして、対話でリクエストを受け付け、作業を管理し、成果物まで発行する仕事を代わりに担う。Palantirのフォワード配置モデルをAIに移したアプローチで、軸で表すなら「製品の中の設定可能な機能」ではなく「プロジェクトに派遣された役割」に位置する。エージェントを持っているという点はもう他社と同じだが、そのエージェントをユーザーが組み立てるのか、ONTLEが組み立てて派遣するのかで分かれる。

このポジションがよく合う場所ははっきりしている。専任の実行人員を別途置くのが難しい小規模チームや一人プロジェクト、毎回少しずつ文脈が変わる反復リクエストが多い組織なら、ツールを新しく学んでワークフローをセットアップする代わりに「これやって」と言う方が速い。

限界も正直に指摘しておく。ONTLEは万能ではない。チーム全体がリアルタイムで同じボードを見ながらコラボしなければならない大規模組織なら、コラボワークスペースの可視性を代替するのは難しい。1日に数百件、完全に定型化された大量データ連携なら、自動化プラットフォームの方がコスト・安定性の面でより適していることもある。ONTLEは、対話でリクエストし、判断の必要な成果物を受け取る領域で強みがあるのであって、チームのコラボボードや大量パイプラインを新しく発明したわけではない。

ツール選びの基準三つ

一つ目、エージェントはどこに住むか。自分が運用するワークスペースや自動化の中の機能が必要ならA・Cグループ、時間配分の自動化が核ならB、対話でリクエストを丸ごと渡したいならDだ。

二つ目、組み立て・ガバナンスの負担を誰が負うか。ワークフローを自分たちの手で細かく設計・コントロールしたいなら、プラットフォーム内蔵のエージェント(A・C)が有利だ。その設計の負担自体を手放して結果だけ受け取りたいなら、派遣型(D)がその負担を代わりに負う。

三つ目、チームの規模とコラボの必要度。複数人がリアルタイムで同じ状況を見なければならないなら、コラボワークスペース(A)が基本の骨格として必要だ。少人数がリクエスト中心で働くなら、派遣型(D)が軽い。大事なのは、これらが競合ではなく互いに別々の軸をカバーしている、という点だ。コラボボードはAに置き、毎回異なる非定型のリクエストは対話でDに任せる、という併用が自然だ。

FAQ

競合ツールも今はどれもエージェントがあるのに、ONTLEと何が違うのですか?

その通りだ。2025年を経て、コラボワークスペース・実行ツール・自動化プラットフォームのいずれもエージェントを載せた。だから違いはエージェントの有無ではない。他のツールのエージェントは、ユーザーが採用・運用する製品の中に住む機能だ。設定型エージェントならその役割とガードレールも人が設計するし、Asana AI Teammatesのように事前役割が用意されていて設計の手間が軽いものや、Notionの標準エージェントのようにユーザーの権限をそのまま引き継いで対話で使う形もある。どちらにせよ、その製品を採用・運用する主体はユーザーだ。ONTLEはプロジェクトに専任のAI PMを派遣し、対話でリクエストを受け付けて成果物まで作ってくる「役割」モデルだという点で毛色が違う。

すでにNotionやAsanaを使っているチームもONTLEを併用できますか?

できる。既存のコラボワークスペースはチーム内部の記録と可視性のためにそのまま残し、別途の実行人員が足りない反復リクエストや成果物作業だけを対話でONTLEに任せる、という併用が自然だ。二つのアプローチは競合というより、互いに別々の軸をカバーしている。

MotionのようなAIスケジュールツールとはどう違うのですか?

Motionはスケジュール自動配置を中心に据えたツールでありながら、List・Kanban・Ganttビューと担当者アサインを備えたプロジェクト管理ツールでもある。時間をどう使うかを決めるところに強みがある。ONTLEは時間割を組むのではなく、プロジェクトのリクエストそのものを受け付けて作業を管理し、成果物を作って届けるところに焦点がある。二つは併用できる。

ONTLEが合わない場合もありますか?

ある。チーム全体がリアルタイムで同じボードを見ながらコラボしなければならない大規模組織にはコラボワークスペースが、1日数百件以上の完全に定型化された大量データ連携には自動化プラットフォームの方がより適していることがある。ONTLEは、対話でリクエストし、判断の必要な成果物を受け取りたい状況に強みがあるのであって、あらゆる用途の代替品ではない。

ONTLEで始める

プロジェクト管理ツールを新しく学んでワークフローをセットアップする代わりに、専任のAI PMに対話でリクエストを任せたいなら、ONTLEで始めてみることができる。

https://ontle.kr

参考資料