Agentic Process Transformation（APT）AIエージェント時代、アーキテクトは「業務の流れ」をどう設計するか
- 松井 淳
- 7月29日
- 読了時間: 6分
生成AIに質問し、文章やプログラムを作ってもらう。こうした使い方は、すでに特別なものではなくなりました。ではAIが質問に答えるだけでなく、社内規程を調べ、データを確認し、複数のシステムを操作し、処理結果まで記録するようになったら、私たちの仕事はどう変わるのでしょうか。
この問いを考えるヒントになるのが、Iasa Globalが発行するArchitecture & Governance Magazineの「Agentic Process Transformation: A CIO Perspective」です。本稿では、このコラムが提示するAgentic Process Transformation（以下、APT）のエッセンスを、若手アーキテクトにも身近な言葉で紹介します。本稿は原記事および提供された日本語訳をもとに要約・解釈したものです。詳しくは原記事を参照してください。
「答えるAI」から「仕事を進めるAI」へ
APTとは、自律型または半自律型のAIエージェントが、業務の最初から最後まで参加できるように、ビジネスプロセスを再設計することです。
AIエージェントは、単にプロンプトへ回答するだけではありません。目標を理解して仕事を分解し、必要な情報を検索し、業務システムやツールを呼び出します。情報が足りなければ人に確認し、リスクの高い判断は人へ戻し、経緯を記録しながら仕事を進めます。
たとえば出張規程について、チャットボットは「宿泊費の上限は1泊1万5千円です」と答えるでしょう。一方、エージェント型の仕組みであれば、規程を読み、申請者や出張先を確認し、申請額を照合し、申請データを作り、承認者へ回付し、承認後に記録システムを更新するところまで進められます。
原記事は、この変化を「タスクの自動化から、アウトカムのオーケストレーションへ」と表現しています。個々の作業を速くするだけでなく、成果に向けて仕事の流れ全体を動かす。ここに、従来のRPAやチャットボットとの違いがあります。 AIを載せるのではなく、仕事を組み直す
既存の業務にAIエージェントをそのまま載せればAPTになるのでしょうか。原記事の答えは明確です。古いプロセスの上にAIを置くだけでは、APTにはなりません。
たとえば買掛金管理では、AIエージェントが請求書を読み、発注書と照合し、支払案を作れます。しかし、高額な支払い、取引先マスターの変更、重複請求の疑い、規程外の例外までAIに任せてよいとは限りません。これらは人間の承認者へ回すべきでしょう。
アーキテクトが設計するのはAIモデル単体ではありません。「どこをAIに任せるか」「どこで人が確認するか」「例外時は誰へ戻すか」「最後に誰が責任を持つか」という境界です。
この境界を設計して初めて、プロセスは「速いが無謀ではない」ものになります。APTの本質は、AIによる人の置き換えではなく、人とAIエージェントの協働を前提に仕事を組み直すことなのです。
アーキテクトが押さえたい3つのポイント
原記事ではCIO向けに6段階のフレームワークが示されています。ここでは、アーキテクトの視点から3つに絞ります。
1．AIではなく、ビジネス成果から始める
出発点はモデル選定ではありません。処理時間、コスト、品質、顧客体験、リスクなど、何を変えたいのかを先に定めます。「最新のAIを使う」では成功を測れません。「精算時間を50％短縮する」のように、AIエージェントの行動と測定可能な価値を結びつけます。
対象には、手作業、待ち時間、部門間の受け渡し、反復判断、例外処理が多い業務が向いています。ただし、価値だけでなく、データの準備度やリスクも見なければなりません。
2．信頼できる情報と、安全な「手足」を用意する
AIエージェントの信頼性は、利用する情報とツールの信頼性を超えられません。古い文書を大量に読ませるだけでは、業務で信頼できる仕組みにはなりません。情報の版管理やアクセス制御、訂正の仕組みが必要です。
また、申請の作成、レコードの更新、メール送信など、AIエージェントが使う「手足」は、安全なAPIと明確な権限を通じて提供する必要があります。原記事の重要な指摘は、「エージェントはシステム全体ではなく、ガバナンスされたアーキテクチャの一つの層にすぎない」という点です。
3．自律性を段階的に高める
自律性は、ゼロか100かではありません。原記事では、要約や推奨を行うレベル1から、人の承認を前提に実行案を作るレベル2、低リスクの操作を自律実行するレベル3、例外時だけ人が監督するレベル4、統制された領域で広く自律するレベル5までを示しています。
いきなりレベル5を目指すのではなく、実績と評価結果を積み上げ、得られた信頼に応じて自律性を高めます。「どこまでAIに任せるか」そのものが、重要なアーキテクチャ意思決定なのです。
ガードレールもアーキテクチャである
AIが回答するだけなら、出力を人が確認すれば、多くのリスクを抑えられます。しかしAIエージェントがシステムを操作するなら、入力、判断、実行、記録までのループ全体を制御しなければなりません。
エージェントごとのIDと最小権限、高リスク時の人の承認、操作と判断の監査証跡、継続的な評価などが必要です。「プロンプトに禁止事項を書けば安全になる」わけではありません。権限、API、承認、監視を含む多層の仕組みとして安全性を設計することも、アーキテクトの役割です。
APTは「EA 2.0」への入口になるか
APTを読み解くと、AI時代にもエンタープライズアーキテクチャ（EA）が重要であることが分かります。
ビジネスアーキテクチャは成果とプロセスを定義し、データアーキテクチャは信頼できる情報を整え、アプリケーション／統合アーキテクチャはAPIやツールの境界を設計します。テクノロジー／セキュリティアーキテクチャは、ID、権限、監視、実行基盤を支えます。
従来のEAが業務・データ・アプリケーション・テクノロジーの「構造」を可視化してきたとすれば、APTはそこに「誰が判断し、誰が行動し、どう学習するか」という動的な設計を加えます。この意味でAPTは、AI時代のEA、いわば「EA 2.0」を考える入口になり得るのではないでしょうか。
BTABoKで重要視されるアーキテクトの「意思決定」や、「拡張チーム」を中心とした組織のあり方もここにつながります。AIの自律性や権限は、記録・検証すべきアーキテクチャ意思決定です。またAPTは、業務、開発、データ、セキュリティ、法務、運用などを含むチームで取り組む必要があります。
まず一つの業務から
大規模なAI基盤がなくても、APTの検討は始められます。まず身近な業務を一つ選び、次の4点を書き出してみてください。
• 最終的に生み出したい成果
• 待ち時間、引き継ぎ、反復判断、例外が生じる場所
• 「AIが支援」「AIが実行」「人が判断」の分担
• AIを人へ戻す条件と、判断・操作の記録方法
「どこにAIを入れるか」ではなく、「どこで仕事が滞り、判断や例外処理が必要になるか」から考えることがポイントです。AIに何を任せ、何を任せないのか。これを関係者と合意できる形にすることが、これからのアーキテクトの仕事になります。
まとめ
APTは、新しいAI技術の名前というより、人、システム、データ、意思決定を横断して、仕事の流れを再設計する考え方です。
原記事が最後に投げかけるのは、AIエージェントが企業に入るかどうかではありません。それが「断片的な実験」として入るのか、それとも自律性を安全で有用な価値へ変える「信頼できるオペレーティングモデル」を通じて入るのか、という問いです。
これはCIOだけでなく、これからのアーキテクト一人ひとりへの問いでもあります。まずは身近な業務を一つ取り上げ、人とAIの新しい協働の姿を描いてみてはいかがでしょうか。
最後までお読みいただき、ありがとうございました。
Iasa日本支部では、情報交換や勉強会の場を設けています。ぜひIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。
参考
Magesh Kasthuri, “Agentic Process Transformation: A CIO Perspective,” Architecture & Governance Magazine, July 9, 2026
「BTABoK Decisions ～ AI時代のアーキテクチャ意思決定 ～」Iasa日本支部
「BTABoK：Extended Team ～拡張チームで実現するデジタル変革～」Iasa日本支部
コメント