CamundaのProcessOSが主張: BPMは常にAIエージェントの正しいレイヤーだった

2026年のほとんどのエンタープライズAI戦略は、誤ったレイヤーを中心に構築されています。モデルレベルでエージェントを管理するか、エージェントプラットフォームを選んでガバナンスが付いてくることを期待するかです。Camundaは両方のアプローチが的を外していると主張しました。

要点: 2026年5月20日、Camundaはアムステルダムで開催されたCamundaConで25か国から約1,200人のエンタープライズリーダーおよび技術者の前でProcessOSを発表しました。ProcessOSはCamundaの既存のオーケストレーションプラットフォーム（すでに毎日数百万の同時ワークフローインスタンスを処理している）の上位にあるAIインテリジェンス層として位置します。この製品はプロセスライフサイクル全体をカバーする4つのAIエージェントを使用します。現状の実際の運営方法を発見し、望む成果に向けて再設計し、新しいプロセスを構築・デプロイし、本番環境で継続的に改善します。Camundaの2026年5月20日の発表によると、中核となる主張は、エンタープライズのAI採用がタスク支援に止まっているのは、エージェントがプロセスレベルで行動するための権限もガバナンス構造も与えられていないからだというものです。ProcessOSはそれに対するCamundaの答えです。

ProcessOSが実際に行うこと

この製品は自然言語から機能します。成果を説明すると、ProcessOSが完全なプロセスベースのソリューションを生成します。エージェント型のワークフロー、データマッピング、統合ロジック、意思決定ルール、エージェントプロンプト、そして人間がまだ手を触れる必要があるUIフォームです。Camundaのマーケットプレイスカタログから拡張機能を引き出すため、ゼロから作るのではなく既存のコネクターを基盤に構築します。

4つの専門AIエージェントがプロセスライフサイクル全体で業務を分担します。最初のエージェントはプロセスが実際にどのように実行されているかをマッピングします（あなたが想定する方法ではなく）。2番目はあなたが指定した成果を中心にプロセスを再設計します。3番目は構築とデプロイを担当します。4番目は本番環境を監視し、ドリフトを検知し、継続的な改善をループに戻します。

データが示すこと

• Camundaの既存プラットフォームは大規模エンタープライズのデプロイで毎日数百万の同時ワークフローインスタンスを処理しています（Camunda、2026年）
• CamundaCon Amsterdam 2026には25か国から約1,200人のエンタープライズリーダーおよび技術者が集まりました（Camunda、2026年）
• エンタープライズのAI採用はタスク支援に止まっており、ほとんどのデプロイが推薦やチャットボットに留まりプロセスレベルでの行動には至っていません（Camunda ProcessOSローンチブリーフ、2026年）

ProcessOSはAmazon Web Services（AWS）上でネイティブに動作し、Amazon BedrockおよびAmazon Bedrock AgentCoreと深く結びついています。基盤モデル、エージェントメモリ、アイデンティティ管理、ゲートウェイサービスをカバーします。現在クローズドベータ段階にあり、企業はcamunda.com/process-osで参加登録できます。

CTOのDaniel Meyerはこのローンチの命名された経営幹部です。彼のフレーミングは直接的です。企業はAIがどのタスクを支援できるかという考え方をやめ、プロセスレベルで、完全なトレーサビリティを持って、どのタスクをエージェント対人間が実行すべきかを決定する必要があります。

プロセス層が新たな競争領域となっている理由

BPMN（ビジネスプロセスモデルと表記法）は20年の歴史を持つエンタープライズ標準です。Camundaはその最大のプラットフォームベンダーの一つです。ProcessOSの賭けは、このレイヤー、具体的には定義された役割、受け渡し、SLA（サービスレベル契約）を持つ複数ステッププロセスのオーケストレーションが、常にエージェントを管理する正しい場所だったというものです。LLM（大規模言語モデル）レイヤーは抽象度が高すぎます。チャットレイヤーは浅すぎます。プロセス層にはすでに企業が必要とするものがあります。

そしてこの動きをしているのはCamundaだけではありません。IBM、Pega、AppianはすべてBPMツールをエージェントに向けて拡張しています。同時に、Salesforce Agentforce、ServiceNow AIプラットフォーム、Microsoft Copilotはすべてエージェントプラットフォームとして始まったものにプロセス機能を構築しています。両方の陣営が同じコントロールサーフェスをめぐって競争しています。

CTOにとっての問いは、どのベンダーが勝つかではありません。どのアーキテクチャ層がエンタープライズエージェント戦略のアンカーとなるべきかです。これがProcessOSが引き出す真の判断です。

CTOに対する3つの意味合い

収束は現実であり、レイヤーを選ぶ必要がある

BPMベンダーとエージェントプラットフォームベンダーは同じコントロールサーフェスに収束しています。Camundaの主張は、BPMにはすでに企業がエージェントに必要なプリミティブがあるということです。監査証跡、バージョン管理、SLAの強制適用、役割ベースの受け渡し、人間が関与するチェックポイントです。エージェントプラットフォームはプロセスガバナンスではなくタスク実行のために設計されたアーキテクチャにこれらの機能を後付けしようとしています。

これはBPMが自動的に勝つことを意味しません。しかし、プロンプトエンジニアリングとガードレールによってモデル層でエージェントを現在管理している場合、それは誤ったレベルで行っているということを意味します。プロンプトレベルのガバナンスは14ステップと4つの受け渡しがあるプロセスでは機能しません。

コンプライアンスにはエージェントをアプリではなくタスクとして扱うことが有効

規制対象業界で最も重要なパターンは「エージェントが管理されたプロセス内のステップを実行する」であり、「エージェントが自律型アプリケーションとして動作する」ではありません。返金承認、KYC（本人確認）チェック、保険金請求の審査はすべて、実行者が人間でも、スクリプトでも、AIエージェントでも同じトレーサビリティが必要です。プロセス層はすでにそれを強制します。プロセスの定義がエージェントより前に存在するからです。

BPMプラットフォームはここで真の構造的な優位性を持っています。エージェントをBPMNプロセス内で実行すると、監査証跡は追加するものではなく、継承するものになります。コンプライアンスチームはエージェントを信頼する必要はありません。プロセスを信頼し、エージェントはすでに承認したステップのもう一つの実行者に過ぎません。

これがさまざまなエージェントユースケースでどのように展開するかについてはパターン別ガバナンス要件、エージェント実行ガバナンスが重要な理由の広範なコンテキストについてはExecute: AIが外部状態を変更するときを参照してください。

調達の問いが変わった

これまで一般的なCTOの問いは「どのエージェントプラットフォームを標準化するか」でした。今や2つの問いになる必要があります。第一に、実行者が人間でもエージェントでも、プロセスの設計・デプロイ・監査をどのオーケストレーション層が管理するか。第二に、そのプロセス内のAI実行ステップにどのエージェントランタイムを使用するか。そして重要な問いが、それらは同じプラットフォームか異なるプラットフォームか、です。

組織によっては答えが統合になるでしょう。SalesforceまたはServiceNowを選択して、オーケストレーションとエージェントランタイムが同じベンダーであることを受け入れます。他の組織、特に複雑で規制を受けた複数システムにまたがるプロセスを持つ組織は、BPMをオーケストレーション層として維持し、エージェントプラットフォームをその中にプラグインする実行エンジンとして扱うことが答えかもしれません。

ProcessOSは本質的に、選択しなくても良いというCamundaの主張です。プロセス層がオーケストレーションとガバナンスを担い、基盤モデルがインテリジェンスを処理する。きれいな分離です。実際に機能するかどうかは既存のアーキテクチャに依存します。しかしフレーミングは正しいです。

経営幹部レベルでこの購入対構築対パートナーの問いにアプローチする方法のフレームワークについては、購入対構築対パートナーフレームワークを参照してください。

プロセス層コントロールテスト

エージェントガバナンスアプローチにコミットする前に、このチェックとして3つの質問を実施してください。各質問は異なる層にマッピングされます。

質問1: このプロセスはコンプライアンスまたは法的審査のために文書化された監査証跡が必要か。 必要な場合、プロセスオーケストレーション層が必要です。モデルレベルのガードレールは、コンプライアンスチームが必要とするステップバイステップの監査ログを生成しません。BPMは生成します。

質問2: このプロセスには人間とエージェント間、または複数のエージェント間での受け渡しがあるか。 ある場合、ツールを呼び出すだけのエージェントではなく、明示的なオーケストレーションが必要です。プロセスオーケストレーションプラットフォームは受け渡しポイント、エスカレーションパス、SLAを定義します。エージェントプラットフォームは通常、そのロジックを自分で構築しない限りそうではありません。

質問3: このプロセスはバージョン管理、ロールバック、または技術者以外の利害関係者による承認が必要か。 必要な場合、プロセス定義を実行から分離する層が必要です。BPMNの図はプロセスオーナーとコンプライアンスチームが読めます。エージェントのコードはそうではありません。CISOやコンプライアンス担当者がプロセスを承認する必要がある場合、Pythonコード以外の何かで読める必要があります。

これら3つの質問のうち2つまたは3つに「はい」と答えた場合、プロセスオーケストレーション層が評価に含まれるべきです。どれにも「はい」と答えない場合、エージェントプラットフォームまたは直接のモデル統合で十分かもしれません。

90日間の評価リストに載せるべきもの

90日間のウィンドウが重要なのは、今下したプラットフォームの判断が12か月後には覆しにくくなるからです。構造化された評価はこのようになります。

1から30日: 規制対象プロセスのインベントリをマッピングする。 コンプライアンス、監査、またはSLAの要件を持つ組織内のすべての複数ステッププロセスを取り出してください。上記の3つの質問でそれぞれをスコアリングしてください。すべてを評価する必要はありませんが、ガバナンスのリスクがどこにあるかを知る必要があります。

31から60日: 並行アーキテクチャテストを実施する。 現在エージェントを使用しているまたはエージェント用に構築中の中程度の複雑さのプロセスを1つ選んでください。2回実装してください。一度は現在のエージェントプラットフォーム内で、一度はCamundaのようなBPMツール内で（無料ティアでも）。監査アウトプット、新しい受け渡しステップを追加するまでの時間、技術者以外の利害関係者がどのようにレビューして承認するかを比較してください。

61から90日: 1ページのADR（アーキテクチャ判断記録）を作成する。 環境内でどのレイヤーがどのクラスのプロセスを管理するかを文書化してください。これが次のチームが判断をゼロから再構築しないで済む成果物です。エージェントプラットフォームで十分だと結論付けても、ADRを書くことでトレードオフが明確になります。

これがAI人材とオペレーション戦略全体にどう収まるかのフレームワークについては、AIワークフォース戦略の経営幹部向け判断フレームワークとガバナンスのギャップ: リーダーが職場でのAIについて間違えることを参照してください。

今週すべきこと

ProcessOSの発表は強制力です。Camundaを具体的に評価する必要があるからではなく、BPMとエージェントプラットフォームの市場が公式に同じ競争に入ったことを示すシグナルだからです。今遅らせる判断は、6か月後にベンダーの圧力の下でより困難になります。

今週、3つのことをしてください。AIエージェントで現在動いているまたは構築中の規制対象の複数ステッププロセスを1つ取り出してください。上記のプロセス層コントロールテストを適用してください。次に、コンプライアンス責任者とエージェントプラットフォームのリードを同じ部屋に集めて30分の会議を設定し、現在のガバナンスアプローチが監査を乗り越えられるかどうかを話し合ってください。

この対話は、プロセス層がアーキテクチャに属するかどうかについて、あらゆるベンダーブリーフィングよりも多くを教えてくれます。そして答えが「はい」であれば、ProcessOSはその評価リストに載せる具体的な製品を提供しました。

参考情報

• 自律エージェント: ツールを使った複数ステップの目標
• ACEフレームワーク: ビジネスAIの周期表
• BPMの紹介: プロセス管理のフレームワーク

---

よくある質問

CamundaのProcessOSとは何ですか。

ProcessOSはCamundaの既存のプロセスオーケストレーションプラットフォームの上に構築されたAI搭載のインテリジェンス層です。2026年5月に発表され、ビジネスプロセスを発見、再設計、構築、継続的に改善するための4つの専門AIエージェントを使用します。ユーザーが自然言語で望む成果を説明すると、ProcessOSは統合、データマッピング、エージェントプロンプトを含む完全なプロセスソリューションを生成します。

AIエージェントにとってプロセス層が重要な理由は何ですか。

プロセスオーケストレーション層はすでにエンタープライズがエージェントに必要なガバナンスのプリミティブを持っています。監査証跡、SLAの強制適用、バージョン管理、役割ベースの受け渡し、人間が関与するチェックポイントです。モデルまたはエージェントプラットフォーム層でエージェントを管理することは、これらの機能を後付けで追加することを意味します。BPMプラットフォームは20年間のエンタープライズプロセス管理からそれらを継承しています。

CTOはAgentforceやServiceNow AIプラットフォームなどのエージェントプラットフォームに対してProcessOSをどのように評価すべきですか。

重要な区別は各層が何を管理するかです。エージェントプラットフォームはどのエージェントが存在し、どのツールを呼び出せるかを管理します。プロセスオーケストレーションプラットフォームは複数ステッププロセスがどのように実行され、各ステップを誰または何が実行し、完全な実行履歴がどのように記録されるかを管理します。規制対象ワークフロー（請求、KYC、承認）については、どのエージェントプラットフォームを選んでも関係なく、プロセス層が必要な可能性が高いです。よりシンプルなタスクの自動化については、単独のエージェントプラットフォームで十分かもしれません。この記事のプロセス層コントロールテストを使用して、具体的なプロセスがどこに位置するかを判断してください。