SoA（System of Action）とは？SoRとの違い、AIエージェント時代に残る業務実行基盤を整理する
SoAという言葉は、AIエージェントや業務自動化の議論でこれから重要になります。CRM、SFA、会計、契約管理、CMSのような正本システムがすでにある一方で、現場では「次に何をするか」「誰が承認するか」「AIにどこまで実行させるか」がまだ人間の画面操作に閉じています。
結論から言うと、SoA（System of Action）は「業務上の行為」を扱う層です。SoR（System of Record）がデータの正本を担うのに対し、SoAは読み取り、判断、承認、更新、送信、公開といった行為を、業務ルールと監査ログつきで進めるための基盤です。AIエージェント時代には、単なる操作画面としてのSoAはAIプラットフォームに吸収されますが、権限、承認、例外処理、SoR更新の境界を担うSoAはむしろ重要になります。
なお、SOAにはService-Oriented ArchitectureやSystem of Agreementなど別の意味もあります。本記事では、AIエージェント時代の業務実行レイヤーとしての System of Action を扱います。
本記事のポイント
- SoAは業務上の行為を実行・承認・記録する層であり、データの正本を担うSoRとは役割が違います。
- 汎用的な操作画面としてのSoAはAIプラットフォームに吸収されやすく、残る価値は統制と業務ルールに移ります。
- AI時代のSoAは、人間用UIではなく、AIと人間が同じ業務状態を扱う実行・承認・監査レイヤーとして設計すべきです。
この記事で扱うテーマ
関連キーワード
- SoAとは
- System of Actionとは
- SoR SoA 違い
- System of Record 違い
- AIエージェント 実行基盤
- 業務実行基盤 AI
このページで答える質問
- SoA（System of Action）とは何か？
- SoRとSoAの違いは何か？
- SoAはClaudeなどのAIプラットフォームに代替されるのか？
- AIエージェント時代に残るSoAをどう設計するべきか？
SoAとは「業務上の行為」に責任を持つシステム
SoA（System of Action）を一言で定義するなら、業務上の行為を設計し、実行し、記録するシステムです。ここでいう行為とは、顧客情報を見る、商談メモを作る、メールを送る、CRMを更新する、承認依頼を出す、契約条件を確認する、公開ページを更新する、といった業務上のアクションを指します。
SoAの中心にあるのは、データそのものではありません。データを使って、誰が、何を、どの条件で、どこまで実行してよいかです。つまりSoAは、業務フロー、権限、承認、監査ログ、例外処理をまとめて扱う実行レイヤーです。
AIエージェントの文脈では、この区別が特に重要です。AIが提案するだけなら、SoAの役割は薄く見えます。しかしAIがCRMを更新し、顧客へメールを送り、チケットを起票し、Webページを公開する段階に入ると、「どの行為を許可するか」「どこで人が止めるか」「失敗したらどう戻すか」を決める層が必ず必要になります。ここがSoAの主戦場です。
| 概念 | 主な役割 | 典型例 | AI時代の論点 |
|---|---|---|---|
| SoR | 正本データを保持する | CRM、会計DB、契約管理、CMS | 何を正として更新するか |
| SoE | 人との接点を作る | メール、チャット、Web、広告 | どの接点でAIが応答するか |
| SoI | 分析や判断材料を出す | BI、スコアリング、予測モデル | 判断根拠をどう説明するか |
| SoA | 行為を実行・承認・記録する | ワークフロー、業務アプリ、エージェント基盤 | AIにどこまで実行させるか |
SoAは「画面」ではなく「行為の責任境界」です。AI時代に価値が残るのは、この責任境界を設計できるSoAです。
SoRとSoAの違いは、正本を持つか、行為を制御するか
SoRとSoAを混同すると、業務システム設計はすぐに崩れます。SoRは「最終的に何が正しいか」を保持します。顧客の正式な会社名、契約金額、請求状態、商談ステージ、公開済み記事の本文などはSoRの責任です。
一方でSoAは、「その正本に対して誰がどう働きかけるか」を扱います。営業担当が商談後にCRMを更新する、AIが議事録から次アクションを抽出する、マネージャーが割引条件を承認する、マーケティング担当が配信対象を確認する、といった行為はSoAの責任です。
重要なのは、SoAがSoRを勝手に置き換えないことです。SoAはSoRの前段に立ち、業務ルールに沿って更新候補を作り、必要な承認を通し、実行結果を記録してからSoRへ反映します。この設計にすると、AIが関わっても正本の信頼性を壊しにくくなります。
| 比較軸 | SoR | SoA |
|---|---|---|
| 責任 | 正本データの保持 | 業務上の行為の制御 |
| 主語 | データ、レコード、状態 | 操作、承認、更新、送信 |
| 失敗時の問題 | 正本が壊れる、重複する、古くなる | 誤送信、誤更新、承認漏れ、追跡不能 |
| 評価指標 | 正確性、整合性、完全性 | 実行速度、承認品質、監査可能性、例外対応力 |
| AIとの関係 | AIが参照・更新する対象 | AIに何を許可するかを決める層 |
例えばCRMはSoRになり得ますが、CRMの画面そのものが必ずSoAとして優れているとは限りません。現場が本当に困るのは、商談情報をどこに保存するかだけでなく、次回フォローを誰が作り、どの条件なら自動送信してよく、どの金額以上なら承認を挟むかです。この行為の設計こそSoAの論点です。CRM連携やMCPの考え方は、CRM APIとMCPの接続設計 とあわせて見ると理解しやすくなります。
短期的にSoAが必要とされる理由
短期的には、SoAのニーズは強くなります。理由は単純で、ほとんどの企業の業務はAIエージェント前提に設計されていないからです。SaaSは部門ごとに分かれ、承認はチャットやメールで流れ、監査ログはツールごとに散らばり、例外処理はベテランの暗黙知に依存しています。
この状態でAIエージェントだけを導入すると、便利になる前に事故の形が変わります。AIが読んだ情報の出所が分からない。CRM更新の根拠が残らない。承認前に外部送信してしまう。人間なら空気を読んで止めていた例外処理を、AIが通常処理として進めてしまう。これらはモデルの性能だけでは解けません。
だから短期的には、SoAが「AIを業務へ接続するための足場」として必要になります。AIに渡す前に業務フローを整理し、操作権限を分け、承認ゲートを置き、ログを残す。この足場があるほど、AIエージェントは単なるチャット相手ではなく、実務に参加できる存在になります。
特にBtoBの営業、マーケティング、カスタマーサクセス、法務、経理では、行為の失敗コストが高くなります。顧客への誤送信、契約条件の誤提示、請求情報の誤更新、公開コンテンツの誤公開は、後から修正できても信用を失います。SoAはこの失敗コストを下げるための設計領域です。
AIプラットフォームに代替されるSoAと、残るSoA
SoAのすべてが長期的に残るわけではありません。むしろ、単なる操作画面、フォーム入力、定型ワークフロー、SaaSをまたいだ軽い自動化は、Claude、ChatGPT、GeminiのようなAIプラットフォームに吸収されやすくなります。自然言語で指示し、ツールを呼び出し、ファイルやSaaSに接続できるなら、人間が専用画面を開いて順番に入力する理由は減っていきます。
ただし、これはSoAが不要になるという意味ではありません。不要になるのは「人間が画面を操作するためだけのSoA」です。残るのは、AIと人間が同じ業務状態を扱い、実行権限、承認、監査、例外処理を共有するSoAです。
| 分類 | 代替されやすいSoA | 残るSoA |
|---|---|---|
| UI | 人間が入力するだけのフォーム | AIと人間が同じ状態を確認する業務コンソール |
| 自動化 | 単純な通知、転記、テンプレ生成 | 条件分岐、承認、復旧まで含む実行制御 |
| ルール | 画面上の注意書きや運用マニュアル | 実行前に機械的に評価されるポリシー |
| ログ | ツールごとの操作履歴 | 業務行為単位の監査ログ |
| AI連携 | AIにプロンプトを渡すだけの機能 | AIの実行範囲と停止条件を管理する制御層 |
ここでの立場は明確です。SoAの未来は「アプリの主役」ではなく「AIエージェントの制御基盤」です。AIプラットフォームが自然言語UIや汎用ツール実行を担うほど、個別企業側のSoAは、何を実行してよいか、誰が承認したか、どのSoRを更新したか、どの例外を止めたかに集中すべきです。
この考え方は、AIエージェントガバナンス や AI運用の承認フロー と同じ方向にあります。モデルを選ぶだけでは業務は動きません。AIが動いた結果を、業務として責任を持てる状態にする必要があります。
AIエージェント時代に残るSoAの設計要件
AI時代のSoAを作るなら、人間用の画面から考えるのではなく、行為の制御から考えるべきです。以下の7要件を満たすほど、AIプラットフォームに代替されるのではなく、AIプラットフォームから呼ばれる側になります。
1. SoRの正本境界を決める
どのデータをどのシステムが正として持つかを先に決めます。顧客情報はCRM、契約情報は契約管理、請求情報は会計、公開記事はCMSというように、SoRの責任が曖昧だとSoAは安全に実行できません。
2. 行為を読み取り、提案、更新、送信、公開に分ける
AIに何を許可するかは、業務名ではなく行為の強さで分ける必要があります。読むだけ、下書きを作る、更新候補を作る、実際に更新する、外部へ送信する、公開する、削除するではリスクが違います。
3. 権限を人間とAIで同じ言葉にそろえる
AI専用の曖昧な権限を作ると運用が壊れます。営業担当、マネージャー、管理者、外部パートナーといった既存の責任単位に合わせ、AIが代理実行できる範囲を明確にします。権限設計は AI活用範囲の決め方 とセットで整理すると実務に落としやすくなります。
4. 承認ゲートを事故コストの高い直前に置く
承認は多ければ安全というものではありません。顧客送信、価格提示、契約変更、CRM大量更新、外部公開の直前に置く方が効きます。AIが生成した時点ではなく、実行する直前に止めることがSoAの重要な役割です。
5. 監査ログを業務行為単位で残す
プロンプトと回答だけでは監査になりません。誰の依頼で、どのデータを参照し、どのツールを呼び出し、誰が承認し、どのSoRに何を反映したかを追える必要があります。監査ログの粒度は AIエージェント監査ログのテンプレート が参考になります。
6. 例外処理と復旧手順を先に決める
AIが失敗しない前提でSoAを作ると危険です。誤更新、誤送信、参照ミス、権限逸脱、外部API失敗が起きたときに、誰が止め、どの状態へ戻し、どのログを見て原因を切り分けるかを決めておく必要があります。
7. AIプラットフォームを置き換え対象ではなく実行主体として扱う
ClaudeなどのAIプラットフォームを競合UIとして見るだけでは視野が狭くなります。実務では、AIプラットフォームが作業者になり、SoAが実行条件と境界を渡す形が増えます。SoAはAIに使われる業務API、ポリシー、監査ログ、承認状態を整えるほど価値を持ちます。
SoAを作る実装手順
SoAは大きな業務アプリを一気に作るより、重要な行為を1つ選び、SoR更新までの責任境界を設計する方がうまくいきます。最初の対象は、営業フォロー、商談更新、リード分類、顧客メール、問い合わせ一次対応、記事公開前レビューのように、件数が多く、事故コストも見える業務が向いています。
ステップ1. 対象業務を「行為」に分解する
「営業支援をAI化する」では広すぎます。例えば、商談後に議事録を読み、次アクションを抽出し、CRM更新案を作り、担当者が承認し、SoRへ反映する、という行為列に分解します。
ステップ2. 行為ごとにSoRと接続先を決める
次に、各行為がどのSoRを読むか、どのSoRを更新するかを決めます。Google Drive、CRM、メール、カレンダー、チケット管理が混在する場合でも、正本の所在を明確にすると事故が減ります。
ステップ3. 自動実行できる範囲と承認必須の範囲を分ける
下書き作成や要約は自動でよくても、外部送信やCRM大量更新は承認を挟むべきです。業務の便利さではなく、失敗時の回復しにくさで判断すると、現場も納得しやすくなります。
ステップ4. 監査ログと差し戻し理由を構造化する
ログは後から読むためだけでなく、SoAを改善するためのデータです。差し戻し理由が「情報不足」に偏るなら入力条件を直し、「表現不備」に偏るならテンプレートを直し、「権限不足」に偏るなら承認設計を見直します。
ステップ5. AIエージェントを作業者として接続する
最後にAIエージェントを接続します。最初から完全自動化を目指す必要はありません。読み取り、提案、承認待ち、実行の順に段階を上げることで、現場の信頼とログが蓄積します。営業領域なら 営業AIエージェントの全体像 と合わせて設計すると、導入範囲を決めやすくなります。
SoA設計で失敗しやすいポイント
画面を作ればSoAになると考える
画面はSoAの一部にすぎません。行為の権限、承認、ログ、例外処理がなければ、それは単なる操作UIです。AI時代には、この種の画面ほど代替されやすくなります。
SoRを曖昧にしたまま実行する
どのデータが正本か曖昧なままAIに更新させると、同じ顧客情報が複数ツールに分散します。SoAはSoRを補完する層であって、正本の責任をぼかす層ではありません。
承認を最後の人間レビューだけに寄せる
最後にまとめて見る方式は、確認負荷が高く、抜け漏れも増えます。データ利用、設定、生成結果、実行直前のどこで止めるかを分ける方が現実的です。
AIプラットフォームを競合としてしか見ない
AIプラットフォームが汎用UIを担うほど、企業側は業務固有の制御層へ寄るべきです。SoAは「AIより賢い画面」ではなく、「AIに実行させても業務責任を保てる基盤」として設計した方が残ります。
よくある質問
SoAはService-Oriented Architectureのことですか？
本記事では違います。Service-Oriented ArchitectureもSOAと略されますが、ここではSystem of Action、つまり業務上の行為を実行・承認・記録する層を指しています。
SoAとワークフローシステムは同じですか？
近いですが同じではありません。ワークフローは承認や手順に寄りがちですが、SoAはそこに実行権限、SoR更新、AIエージェント接続、監査ログ、例外処理まで含めて考えます。
SoAはClaudeやChatGPTに代替されますか？
人間がフォームを操作するだけのSoAは代替されやすくなります。一方で、AIに何を許可し、どこで止め、どのSoRを更新し、どの証跡を残すかを担うSoAは残ります。
小さな会社にもSoAは必要ですか？
必要な範囲は小さくて構いません。顧客送信、契約、請求、公開、個人情報処理のように失敗コストが高い行為だけでも、承認とログを設計しておく価値があります。
SoAを最初に作るならどの業務が向いていますか？
件数が多く、手戻りが多く、SoR更新が発生する業務が向いています。営業フォロー、CRM更新、問い合わせ対応、リード分類、記事公開前レビューは、SoAの効果を確認しやすい領域です。
SoA関連記事の読み順
SoAを実務で使うには、定義だけでなく、既存システム分類、ワークフローとの差分、AIエージェント基盤、導入判断、営業・マーケティングでの具体化を順に押さえると整理しやすくなります。
- SoR・SoE・SoI・SoAの違いとは？：まず正本、接点、洞察、実行の責任境界を整理します。
- SoAとワークフローシステムの違いとは？：承認フローと業務実行レイヤーの違いを確認します。
- AIエージェント基盤としてのSoAとは？：AIに実行させるための権限、承認、監査ログを深掘りします。
- SoA導入チェックリスト：AIに任せてよい業務を見極める実務条件を確認します。
- 営業・マーケティングにおけるSoAとは？：CRM更新、メール送信、承認フローに落とし込みます。
SoAをAIエージェント時代の実行基盤として整理したい場合
ファネルAiでは、AIエージェント、CRM連携、MCP、承認フロー、監査ログを含めて、業務に合わせた実行基盤の設計と開発を支援しています。SoAを単なる画面ではなく、AIと人間が同じ業務状態を扱える制御レイヤーとして作りたい場合は、初期設計から相談できます。
