AIとビジネスプロセスアーキテクチャ：信頼できる唯一の情報源を整える

AIアシスタントは、受注から入金までの一般的な流れを数秒で説明できます。しかし、財務チームがある例外を承認し、別の例外を上位に引き継ぐ理由や、倉庫が安全在庫のルールを例外的に適用する理由までは分かりません。そうした知識はビジネスプロセスアーキテクチャにあり、文書化されている場合に限って参照できます。

問うべきなのは、AIがアーキテクチャ業務を変えるかどうかではありません。すでに変化は始まっています。問うべきなのは、定義、優先順位、トレードオフ、承認のうち、何を組織自身で決めるかです。私たちの立場は明確です。AIを支持しますが、それ以上に人を大切にします。AIが取り除くべきなのは、判断そのものではなく、判断に付随する作業です。

AIとビジネスプロセスアーキテクチャが互いを必要とする理由

AIのないアーキテクチャは、レビューの合間に古くなる手作業です。アーキテクチャのないAIは、速く自信に満ちた一般論を返すだけです。

情報の収集、図の作成、説明、確認をすべて手作業で行うと、ビジネスプロセスアーキテクチャを最新に保つには大きなコストがかかります。AIは、最初の下書きを作るコストと、プロセス全体像を読み取るコストを下げます。一方、アシスタントには推論能力があっても、組織のプロセスに関する情報がありません。生のデータを渡すと、ワークフローを推測する必要があります。情報を精選したアーキテクチャを渡せば、モデル、文書、ロール、測定された実態をもとに回答できます。

この組み合わせでは、一方が対応範囲を広げ、もう一方が正確さを支えます。AIに図を加えるだけではありません。組織が業務の意味を記録した場所と、AIを組み合わせるのです。

アシスタントをデータに接続することと、プロセスの知識に接続することは異なります。MCPによるプロセスコンテキストは、接続そのものを扱います。さらに重要なのは、このページのテーマでもある、アシスタントが接続先で何を見つけるかです。組織のデジタルツインも同じです。モデルとデータは、測定や判断につながって初めて役立ちます。

つながりのある情報基盤の姿

ビジネスプロセスアーキテクチャは、業務の進め方をつなげて示す構造です。バリューストリーム、プロセス、サブプロセス、アクティビティ、それらの責任を担うロール、業務を支えるシステム、内容を説明する文書や成果物、各要素のステータスとバージョンをまとめます。1つのファイルではなく、1つの場所に集約します。

人は階層をたどって情報を探し、アシスタントは要素間のつながりをたどって情報を探します。図をまとめたフォルダーでプロセスの位置は分かっても、「このプロセスに依存するものは何か」「責任者は誰か」「どのバージョンが承認済みか」には答えられません。こうした問いに必要なのは、書類棚ではなく、つながりを示す構造です。

BPMアーキテクチャ、エンタープライズプロセスアーキテクチャ、ビジネスプロセスマネジメントアーキテクチャと呼ばれることもあります。名称より大切なのは、各情報に1つの参照先があり、「どのバージョンが正しいか」に答えられることです。

APQCなどのフレームワークは、階層を表す用語を提供します。しかし、組織のプロセスや責任者、例外までは定めません。それらを決めて記録するのは、組織自身です。

つながりのないモデルも、ワークショップでは役立ちます。つながりのあるモデルなら、人はバリューストリームからアクティビティへとたどれます。アシスタントも同じ経路をたどって回答できます。だからこそ、情報を整えて維持する価値があります。

階層、プロセス、ステータスを1つの構造でつなぐプロセスカタログ

AIがアーキテクチャ業務を速める領域と、判断を任せてはいけない領域

AIが力を発揮するのは、答えを確認できる作業や、人が修正できる最初の下書きです。アーキテクチャ業務には、その両方が多くあります。

どちらの作業をAIに任せるかを分ける基準は、能力ではなく権限です。AIは人より優れたモデルの下書きを作れても、会社の業務の進め方を決める権限はありません。

実務では、レビューできる作業をAIに任せ、責任者が必要な判断は人が担うのが有効です。モデルの下書き、要約、不足している文書の一覧、改善案は、いずれもレビューできます。一方、承認基準の変更、新しい責任者の設定、統制の廃止は、レビューだけでは済みません。合意内容の変更には、合意に関わる人の参加が必要です。

文化や目標をAIに任せられない理由

プロセスアーキテクチャには、組織の業務の進め方に関する判断が記録されます。その判断の源は戦略や文化であり、データではありません。

2社が同じERPで同じ量の受注から入金までのプロセスを運用していても、必要なアーキテクチャは異なることがあります。一方は納期の約束を守るためにコストを受け入れ、もう一方は利益率を守るために条件を再交渉します。一方は現場の管理者に例外の承認を任せ、もう一方は承認を中央に集約します。モデルは似ていても、適切な判断は同じではありません。

目標によって、スピード、コスト、回復力、コンプライアンス、顧客の負担のうち、何を最適化するかが決まります。文化によって、判断の進め方、相談する相手、例外を認める条件、組織として受け入れないことが決まります。こうした内容はイベントログには記録されず、文書にも残っていないことがあります。プロセスを運用する人が知っているのです。

アシスタントは、記録された言葉を学ぶことはできます。しかし、その言葉の背景にある判断に責任を持つことはできません。モデルを大きくしても解決しない問題です。なぜそう判断したのかを問われ、答えられる人が必要です。

人とAIの両方に向けて、どのように文書化すればよいですか？

まず人に向けて書きます。同僚に必要な分かりやすさは、アシスタントにも必要です。機械だけを対象にした別の文書一式を作ると、最初の文書とのずれが生じます。

プロセスを開いた人は、何をするプロセスか、なぜ必要なのか、誰が責任者なのか、どこに例外があるのか、次に何をすべきかを知りたいと考えます。同じプロセスを読むアシスタントにも、たどって確認できる構造で同じ情報が必要です。モデルは手順とつながりを示し、文書化した情報は意味を伝え、成果物は根拠を示し、ロールは権限を明らかにします。

そのため、長いテンプレートを埋めるより、「短く書き、理由を残す」ほうが役立ちます。承認が必要な理由を記録した説明は、新しい同僚にも、承認をなくせるか尋ねられたアシスタントにも役立ちます。図を繰り返し説明するだけでは、どちらにも役立ちません。

接点は3つ、情報源は1つです。プロセスポータルは、業務を担う人のためにあります。MCPサーバーは互換性のあるアシスタントが利用できます。MCPはオープン標準のため、同じ接続を複数のクライアントで使えます。REST APIは、データを移動したりシミュレーションを実行したりするスクリプトや連携に使います。どの接点にも、アーキテクチャの別コピーはありません。

これがワークフローアーキテクチャの全体像です。情報を精選した単一の情報源、3つの読み取り経路、そして二重化された情報源はありません。ポータルで下書きを公開する必要はなく、アシスタントが下書きを読む必要もありません。

情報の不足が、AIの推測につながる

文書化されていないルールは、中立ではありません。モデルがもっともらしい内容で空白を埋めることになります。

ラベルのないゲートウェイは、アシスタントが名前を付けた判断になります。担当者が設定されていないロールは、「チーム」として扱われます。文書化されていない例外は、通常どおり進む前提で処理されます。説明のないプロセスは、目的ではなく形だけの要約になります。アシスタントが「分かりません」と答えることは、ほとんどありません。もっともありそうな答えを返しますが、その答えは他の組織のプロセスをもとにしています。

これが、実務における制御の意味です。分かっていることは明確に記録します。記録されていない部分はAIが判断することになり、その判断には確信が伴います。

モデル品質を確認すると、こうした不足が見えるようになります。キャンバス上の品質バッジには、割合スコアと確認項目の一覧が表示されます。未接続の要素、ラベルの不足、ゲートウェイの不整合、文書化した情報やロールの不足などです。管理者はアーキテクチャレベルごとに確認項目を設定できます。そのため、100％はそのレベルの要件をすべて満たしていることを示します。

スコアは成績ではなく、知識の確認リストとして見てください。確認に失敗した項目は、まだ決めていないことや、記録していない事実を示します。特に重要なのは、図の誤りよりも、文書やロールの不足です。そこには意図や責任の所在が関わります。アシスタントが根拠を得にくく、推測の余地が大きい部分です。モデル品質は、モデル作成者の成績表というより、組織がまだ決めていないことを示す地図です。

モデル品質の確認により、文書化されていないアクティビティ、ロールの不足、モデリング上の誤りが一覧で分かります

バージョン管理でコントロールを保つ

記録を残さずに変わるアーキテクチャは、信頼できる唯一の情報源ではありません。その時点での意見にすぎません。

各プロセスには、下書き、レビュー中、承認済み、廃止、アーカイブ済みのいずれかのステータスが設定されます。公開するとバージョンのスナップショットが作成され、プロセスポータルで閲覧できるのはその公開済みバージョンです。レビュー担当者は、バージョン名を付けて承認し、同じ手順で公開できます。カタログでは、最新のもの、レビュー待ちのもの、古くなったものを確認できます。エンタープライズアーキテクチャのガバナンスでいうレビューを、プロセスアーキテクチャでは変更のたびに行います。すでにアーキテクチャレビューボードのプロセスがある場合も、同じ取り組みをより短いサイクルで行えます。

バージョン履歴は、AIを使う際に重要な機能を提供します。スナップショットに名前を付け、下書きと比較し、変更をまとめて確認し、変更ごとに承認または却下し、以前の状態に戻し、特定のバージョンを公開できます。レビューの判断は対象のスナップショットに紐づくため、後から編集しても過去の承認が気づかないうちに引き継がれることはありません。

AIにも同じルールを適用します。アシスタントが参照するのは、レビュー担当者が確認していない下書きではなく、承認済みまたは公開済みのバージョンです。AIの提案はレビュー対象の変更として提示され、都合がよいからといって自動的に正しいものとして扱われることはありません。バージョンは、判断を下した人と情報を読むシステムの間の合意です。責任者の設定、レビューの頻度、変更の承認を含む、その背景にある運用モデルについては、プロセスガバナンスで説明しています。

公開履歴とステータス管理により、組織が承認したプロセスのバージョンを確認できます

アーキテクチャの承認後にAIができること

情報を精選し、承認したアーキテクチャがあれば、アシスタントは一般論を返すだけでなく、確認できる作業を行えるようになります。

• プロセスを分析し、根拠とともに検証する価値のある改善案を提示します。
• モデル、成果物、関連プロセスをもとに、アクティビティの文書を下書きします。
• 定義済みのロールを使ってRACIの割り当てを提案し、人が修正できるようにします。
• プロセス全体を横断して質問に答えます。責任者のいないプロセス、文書が不足している箇所、前回の承認済みバージョンからの変更を確認できます。
• 最初のモデルを作成し、文書をもとに最初のアーキテクチャを作成して、プロセスごとにレビューできるようにします。
• シミュレーションのパラメーターを設定し、提案した変更を現在のプロセスと比較します。

これらの作業を行うために、アシスタントに判断を任せる必要はありません。アーキテクチャと承認プロセスの範囲内で動作させれば十分です。

MCPサーバーを通じて、互換性のあるアシスタントが情報にアクセスできます。エンタープライズプランでは、範囲を限定したAPIキーを使って、プロセスとBPMNモデル、文書化した情報、ロールとRACI、担当者と組織のメタデータ、プロセス統計に加え、ProcessMindの分析ツールを利用できます。書き込み権限のあるキーでは書き込みツールも使えますが、ツールが返すのは提案です。人が承認する前に、事前確認用のプレビューを実行します。呼び出しはキーに紐づけられ、監査ログに記録されます。データセットのアップロード、データマッピング、シミュレーションは、判断ではなく操作にあたるため、引き続きREST APIを使用します。

AIアシスタントも、ここで役立ちます。プロセスに関する質問に答え、回答の根拠となるダッシュボードやモデルを参照し、変更案を差分として提示してレビューを促します。範囲が明確だからこそ、アシスタントは役立ちます。

エージェントも運用モデルに加わりつつあります。プロセスに働きかけるアシスタントには、システムやロールと同じように、責任者、権限の範囲、アーキテクチャ上の位置づけが必要です。エージェントが変更案を提示できる場合は、承認の責任者をアーキテクチャに記録します。別の枠組みを新たに作らなくても、エージェントをアーキテクチャの記述対象に加えることで、AIエージェントを管理できます。

最初からすべてに取り組まずに始めるには

AIを役立てるために、組織全体をアーキテクチャに盛り込む必要はありません。実際の判断につながる、ひとまとまりのプロセスから始められます。

1. バリューストリームを1つ選び、関連するプロセスをいくつか選定します

   責任者と測定可能な成果があり、すでに議論になっている業務を選びます。承認、引き継ぎ、手戻りのいずれか1つだけでも、進め方を検証できます。

2. まず責任者とレビュー担当者を決めます

   アシスタントを接続する前に、ロールとRACIを設定します。権限がなければ読み取ることもできません。レビュー担当者は、アーキテクチャ上で責任の所在が明確な人にします。

3. 必要なレベルまで文書化します

   各アクティビティに説明、ロール、明確な境界を設定します。使われない情報は省きます。完成していても読まれないアーキテクチャは、図をしまったフォルダーと変わりません。

4. 品質要件を満たします

   ラベルやつながり、文書が不足している要素を修正します。残った未達項目は不具合の一覧ではなく、今後の検討事項として扱います。

5. バージョンを公開し、アシスタントを1つ接続します

   答えが分かっている質問をして、その回答をワークスペースの情報と照らし合わせます。正しい回答は情報源が整っている証拠であり、誤った回答は不足がある証拠です。

6. 定期的にレビューします

   モデル品質、前回のバージョンからの変更、AIが提示した改善案を確認します。それぞれを承認、却下、保留にし、その理由を記録します。

最初の範囲で進め方を検証できます。2つ目からは、より速く進められます。アーキテクチャは文書作成の取り組みではなく、判断を重ねながら広げていきます。

アーキテクチャは合意を表す

AIによって、文書化の価値は下がるどころか高まります。これまでワークショップの外では参照されなかったモデルが、今では社内のすべてのアシスタントが業務の進め方について何を答えられるかを左右します。

AIの価値を得る組織は、エージェントの数が最も多い組織ではありません。知識が明確に記録され、責任者が定まり、最新の状態に保たれ、承認されている組織です。人が内容をたどる場所と、アシスタントが情報にアクセスする方法も整っています。

これが、私たちが考える役割分担です。AIは読み取り、下書き、確認を行います。何が正しいかを決めるのは人です。アーキテクチャは、その両者の合意を表します。