自動化のアイデアがないことよりも、汎用的な自動化が自社の承認ルールや責任分担に合わないことが、運用停滞の原因になります。SankaのCustom Agentは、エージェントの判断基準、実行範囲、承認が必要なポイントを明確化し、自社運用に合わせた形で設計できるように構成されています。
ロール、ステータス、業務影響度に応じたガードレールを定義し、エージェントの提案と実行を統制します。
見積承認、請求例外、決算準備など、業務単位でプロンプトとアクション手順を設計できます。
提案と実行の両方を、実行者、時刻、関連レコードと紐づけて記録し、追跡可能にします。
最初から全業務を対象にせず、摩擦が大きい引き継ぎポイントから着手するのが実務的です。
| 設計レイヤー | 決めること | 具体例 |
|---|---|---|
| 意図レイヤー | どの質問・依頼に対応するか | 「この請求の遅延理由は?」 |
| 判断レイヤー | 提案前に必要な確認項目 | ステータス、担当者、期限、承認状態 |
| 実行レイヤー | ロール別の許可アクション | タスク作成、承認回付、非財務項目の更新 |
| 統制レイヤー | 監査・レビュー条件 | クレジット調整は財務責任者承認を必須化 |
Custom Agentを「ワークフロー起点のオーケストレーター」として使い、トリアージと回付を標準化します。
商談から受注・請求への引き継ぎ停滞を検知し、原因を要約して担当者へ回付します。
発注、入荷、請求書の不一致を検知し、ルールに沿って修正・承認を振り分けます。
未突合、承認待ち、異常値の残件を集約し、月次締め前にアクションを確定します。
Custom Agentは速度を上げるための手段ですが、権限と監査の前提が崩れると逆効果です。最初に統制を定義し、その範囲で段階的に自動化を拡張します。
エージェントの実行は、ログインユーザーとワークスペースの権限範囲内に限定されます。
業務影響の大きい変更は、定義済みの承認経路を通過した後にのみ実行します。
判断、提案、実行、結果を一連の履歴として残し、レビューと説明責任を担保します。
Custom Agent導入は、機能実装ではなく運用設計プロジェクトとして進めると定着しやすくなります。
| 導入フェーズ | 主要KPI | 実務上の確認ポイント |
|---|---|---|
| パイロット | 解決までの時間 | 例外対応の手戻りが減っているか |
| 拡張 | 統制を保った処理量 | ポリシー逸脱なく処理件数を増やせているか |
| 標準化 | 再利用性 | 新規プレイブックの立ち上げ時間を短縮できるか |