SoA導入チェックリスト｜AIに実行させる業務をどう見極めるか
SoAを導入するとき、最初に決めるべきなのはツールではありません。どの業務をAIやシステムに実行させてよいか、その条件を確認することです。
この記事では、SoA導入前に見るべきチェックリストを整理します。対象業務、SoR、操作権限、承認ゲート、監査ログ、例外処理を確認すると、AIに任せられる業務と人間承認を残すべき業務が見えやすくなります。
本記事のポイント
- SoA導入は、AIに任せたい業務の頻度、失敗コスト、SoR更新の有無を確認するところから始めます。
- 読み取り、下書き、更新、送信、公開、削除を分けると、AIに許可できる操作範囲を決めやすくなります。
- 承認ゲート、監査ログ、例外処理がない業務は、便利そうでも本番SoAとしては危険です。
この記事で扱うテーマ
関連キーワード
- SoA 導入 チェックリスト
- AI 業務実行 チェックリスト
- System of Action 導入
- AIエージェント 業務選定
このページで答える質問
- SoA導入前に何を確認するべき？
- AIに実行させてよい業務の条件は？
- SoA導入チェックリストには何が必要？
- SoA導入で失敗しやすいポイントは？
この記事の直接回答
SoA導入で最初に見るべきことは、AIに任せたい業務が「実行してよい条件」を満たしているかです。頻度、失敗コスト、SoRの所在、操作権限、承認ゲート、監査ログ、例外処理を確認し、読み取りや下書きから始めて承認付き更新へ広げます。
- 最初の判断：できる業務ではなく、止められる業務から選ぶ。
- 優先対象：件数が多く、手順があり、復旧しやすい業務。
- 避ける対象：外部送信、削除、大量更新を無承認で動かす業務。
チェックリストは業務選定から始める
SoA導入で失敗しやすいのは、AIでできそうな業務から始めることです。できそうかどうかより、実行させてもよいか、失敗しても戻せるか、ログで追えるかを先に見ます。
最初の対象には、件数が多く、手順がある程度決まっていて、SoR更新や外部送信が発生する業務が向いています。営業フォロー、問い合わせ分類、CRM更新案、記事公開前レビューなどは候補になります。
| 確認項目 | 見るポイント | NGの兆候 |
|---|---|---|
| 頻度 | 毎週または毎日発生するか | 年数回しか起きず設計コストが見合わない |
| 失敗コスト | 誤送信や誤更新の影響を評価する | 事故時の復旧手順がない |
| SoR | どのシステムが正本か明確か | 同じ情報が複数ツールに分散している |
| 権限 | 読み取りと書き込みを分けられるか | 一括で管理者権限が必要になる |
| 承認 | 実行直前で人が止められるか | 誰が止めるか決まっていない |
| 監査ログ | 依頼、参照、実行、承認を追えるか | ログがツールごとに散らばる |
操作の強さを6段階で分ける
AIに何を許可するかは、業務名ではなく操作の強さで考えると整理しやすくなります。読み取り、要約、下書き、更新、送信、削除ではリスクがまったく違います。
最初は読み取りと下書きまでに限定し、承認付き更新、限定自動実行へ段階的に広げます。いきなり外部送信や削除を自動化すると、現場の信頼を失いやすくなります。
- 読み取りだけ許可する。
- 要約や分類を許可する。
- 下書きや更新案の作成を許可する。
- 人間承認後の更新を許可する。
- 低リスクな限定範囲で自動実行を許可する。
- 削除や外部公開は原則として強い承認を必須にする。
承認ゲートは数より位置が重要
承認を増やすだけではSoAはよくなりません。すべての操作に同じ承認をかけると現場が使わなくなります。重要なのは、事故コストが高い行為の直前に置くことです。
顧客への送信、価格条件の提示、CRM大量更新、契約情報変更、公開ページ更新のような操作では、実行直前の承認が効果的です。
監査ログは改善データとして使う
監査ログは事故対応のためだけに残すものではありません。差し戻し理由、承認にかかった時間、AIが参照したデータ、実行結果を蓄積すると、SoA自体を改善できます。
たとえば差し戻し理由が情報不足に偏るなら入力フォームを見直し、表現不備に偏るならプロンプトやテンプレートを修正します。ログは運用改善の材料です。
導入判断は小さな業務で検証する
SoAをいきなり全社基盤として作るより、1つの業務で検証する方が現実的です。対象業務を絞り、権限、承認、ログ、例外処理をそろえ、1か月単位で運用指標を見ます。
小さく始めても、設計思想は本番前提にします。PoCだからログ不要、PoCだから承認不要にすると、本番移行時に作り直しになります。
スコアリングして候補業務を並べる
候補業務が複数ある場合は、感覚で選ばず、業務頻度、手順の明確さ、失敗時の影響、データ正本の明確さ、承認者の置きやすさで点数化します。高頻度で手順が明確、かつ失敗時に戻せる業務ほど初期導入に向きます。
| 評価軸 | 高評価の状態 | 低評価の状態 |
|---|---|---|
| 頻度 | 毎日または毎週発生する | 年数回で学習効果が出にくい |
| 手順 | 判断条件と入力情報が決まっている | 担当者の暗黙知に依存している |
| 復旧 | 差し戻しや取消ができる | 誤実行後に戻せない |
| 正本 | CRMや台帳など更新先が明確 | 複数ツールに同じ情報が散っている |
本番前に小さく検証する項目
PoCでは、AIの回答精度だけでなく、承認にかかる時間、差し戻し理由、ログ欠損、例外時の停止動作を見ます。ここを測らないまま本番化すると、便利な試作はできても、現場が安心して使えるSoAにはなりません。
本番移行前に決める停止条件
本番移行前には、AIが迷った時、権限エラーが出た時、参照データが古い時、承認期限を過ぎた時にどう止めるかを決めます。停止条件がないSoAは、失敗しても走り続ける仕組みになりやすく、現場の信頼を失います。
- 外部送信や正本更新の前に、必ず承認待ちへ戻せるか。
- 担当者不在、期限超過、データ不足の時に自動停止できるか。
- 停止後に誰が再開判断をするか、監査ログに残るか。
導入ロードマップ
AIエージェントや関連ツールを業務に組み込むときは、対象業務を絞った段階導入が現実的です。3か月で1領域、6か月で2-3領域に展開する流れが、運用負荷とROIのバランスを取りやすくなります。
| 期間 | 取り組み | 達成条件 |
|---|---|---|
| 1か月目 | 対象業務の選定、データ整備、利用範囲の社内合意 | OU/グループ単位の対象を確定 |
| 2-3か月目 | テンプレと承認フローの整備、限定パイロット | 5〜10名で運用、品質と速度を観測 |
| 4-6か月目 | KPI観測と他領域への横展開 | 定量KPIで効果可視化、次領域計画完了 |
禁止事項と運用ルール
- 判断系（採否・契約条件・人事評価）に出力をそのまま使わない
- 個人情報・契約金額をプロンプトに直接入れる前にDLPルールを通す
- 外部連携アドオンを契約前に OAuth スコープ・退出設計を確認
- 監査ログとアラートセンターを月次でレビュー
よくある質問
SoA導入で最初に確認することは何ですか？
対象業務の頻度、失敗コスト、SoRの所在、操作権限、承認ゲート、監査ログ、例外処理です。ツール選定より先に確認すべきです。
AIに実行させてよい業務の条件は？
手順がある程度決まっていて、参照データが明確で、失敗時に止められ、ログで追跡できる業務が向いています。
削除や外部送信もAIに任せられますか？
原則として慎重に扱うべきです。低リスクな限定範囲を除き、人間承認を必須にし、監査ログと復旧手順を整える必要があります。
PoCならログや承認は後回しでよいですか？
後回しにしない方が安全です。PoC段階から最低限のログと承認を入れることで、本番移行時の作り直しを減らせます。
関連ページと関連記事
導入チェックリストは、SoAの定義、ワークフローとの差分、AIエージェント基盤としての設計とあわせて使うと判断しやすくなります。
- SoA（System of Action）とは？：SoAの基本定義と判断軸を確認できます。
- SoAとワークフローシステムの違いとは？：承認フローをSoAへ広げる観点を確認できます。
- AIエージェント基盤としてのSoAとは？：権限、承認、監査ログの設計を深掘りできます。
- AI導入PoCの進め方：小さく検証して本番移行する進め方を確認できます。
SoA導入候補を整理したい場合
AIに実行させる業務を見極めるには、業務頻度、失敗コスト、SoR更新、承認、監査ログをまとめて見る必要があります。ファネルAiでは、候補業務の棚卸しからPoC、本番実装まで支援しています。
導入を全社一括で進めて良いですか？
推奨しません。OU/グループ単位の段階展開が原則です。先行5〜10名のパイロット結果を踏まえてからから他部門へ広げると、再設計コストを抑えられます。
どんな業務にAIエージェントを使うべきですか？
判断系より下処理（要約・分類・整形・候補提示）から始めるのが安全です。判断は人間が握り、AIは「下処理を高速化する補助」として位置づけると運用が安定します。
