自治体がRobo Clawを導入する際の要件・権限・承認設計
対象業務が決まったら、対象部局・業務・住民サービス、住民情報の分類、法的根拠、読み取り・書き込み権限、部局間共有、外部送信、電子決裁との境界、人間承認、職務分掌、ログ・監査証跡、KPIを具体化します。
Refine STEPの目的は、対象業務を「誰が・どこまで・どの承認のもとで自動化するか」を文書化することです。特に、住民情報を扱う際の利用目的・法的根拠・データ分類、部局間共有と外部送信の範囲、電子決裁との境界、法務・個人情報保護・情報セキュリティ担当への確認プロセス、部局・職位・委託先の職務分掌は、この段階で明確にしてください。ここが曖昧なままPilotへ進むと、後工程で設計のやり直しが発生します。
Who This Is For
対象読者
Discover STEPで対象業務を決定した、情報システム部門、担当部局責任者、個人情報保護担当を対象にしています。
What You'll Decide
このSTEPで決めること
Refine STEPでは、対象部局・業務・住民サービスの範囲、扱う住民情報のデータ分類、法的根拠、読み取り・書き込み権限、部局間共有、外部送信、承認条件、職務分掌、責任分界、KPIを文書化し、Build & Validateで検証可能な要件に落とし込みます。
Industry Challenges
自治体固有の課題
部局ごとに権限の考え方が異なる
部局ごとに既存の権限運用が異なり、統一した権限設計が難しくなります。
住民情報の分類・法的根拠が未整理
住民情報を業務でどこまで利用してよいか、法的根拠や分類が明文化されていないケースが多くあります。
電子決裁との役割分担が曖昧
AIエージェントの出力と既存の電子決裁プロセスの関係が整理されていないことがあります。
再実行時の挙動(二重実行防止)が未検討
同じ処理を再実行した際に、住民記録の二重更新や重複送信が起きないかの設計が検討されていないケースがあります。
Method
実施手順
1. 対象部局・業務・住民サービスを定義する
対象となる部局、業務、関連する住民サービスの範囲を明確にします。
2. Agent・Skill・Toolを設計する
対象業務に必要なAgentの役割、業務手順のSkill、文書管理・グループウェア操作を行うToolの範囲を設計します。
3. Tool Policyを定義する
Toolが実行してよい操作(読み取り／書き込み、Allow／Deny)をPolicyとして定義します。住民記録の確定更新はDenyとします。
4. 住民情報のデータ分類・法的根拠を整理する
扱う住民情報のデータ分類、利用目的、法的根拠を整理し、最小限利用の範囲を定義します。
5. 読み取り・書き込み権限、部局間共有、外部送信を設計する
部局・職位別のアクセス権限、部局間でのデータ共有範囲、外部送信の可否と承認条件を設計します。
6. 電子決裁との境界を定義する
AIエージェントの出力はあくまで下書き・候補にとどめ、正式な決裁は既存の電子決裁プロセスで行う境界を定義します。
7. 承認・職務分掌・エスカレーションを定義する
人間承認が必要な操作の承認者、部局・職位・委託先の職務分掌、法務・個人情報保護・情報セキュリティ担当へのエスカレーション経路を定義します。
8. ログ・監査証跡・二重実行防止・KPIを定義する
保存すべき操作ログ・入出力記録、再実行時に誤更新が起きない設計、効果測定KPIを定義します。
Data & Systems
使用するデータ・システム
Human-in-the-loop
人間承認が必要な箇所
- 行政処分・給付可否・審査に関わる最終承認者を役職単位で明確にする
- 住民情報の第三者提供・外部送信の承認条件を明確にする
- 住民情報の分類・法的根拠について、法務・個人情報保護担当の確認を得る
- 部局をまたぐ権限付与・データ共有について、情報システム部門の承認を得る
Measurement
KPI
Refine STEPでは、Build & Validateで検証するKPIの候補を定義します。
庁内照会一次分類時間の目標水準
照会分類にかかる時間の目標
承認までのリードタイム
下書き作成から人間承認までにかかる時間
権限逸脱の検知件数
定義した権限範囲を超えた操作の検知件数
Checklist
要件定義チェックリスト
- 対象部局・業務・住民サービス(含む業務・含まない業務)が文書化されている
- 入力データと出力(分類案・要約・下書き)が定義されている
- 住民情報のデータ分類、利用目的、法的根拠が整理されている
- 読み取り・書き込み別のアクセス権限が部局・職位単位で定義されている
- 部局間共有・外部送信の範囲と承認条件が定義されている
- 電子決裁との境界が定義されている
- 行政処分・給付可否・審査等の承認条件と承認者が定義されている
- 法務・個人情報保護・情報セキュリティ担当への確認プロセスが定義されている
- 部局・職位・委託先の職務分掌が定義されている
- 二重実行・誤更新防止の設計が検討されている
- 操作ログ・入出力記録の保存範囲と保存期間が定義されている
- 効果測定に使うKPIが定義されている
Pitfalls
失敗例・注意点
権限設計を後回しにする
まず動かしてから権限を調整しようとすると、複数部局展開時に大きな手戻りが発生します。
承認者が曖昧なまま進める
承認者を役職ではなく個人名で決めると、異動・退職時に運用が止まる原因になります。
電子決裁との境界を曖昧にする
Tool Policyで住民記録の確定更新や正式決裁を明示的にDenyしないと、意図しない書き込み権限が付与されるリスクがあります。
FAQ
よくあるご質問
要件定義はどの部門が主導すべきですか
対象業務の担当部局と情報システム部門が共同で主導し、住民情報を扱う場合は個人情報保護担当、外部送信を伴う場合は情報セキュリティ・法務部門も関与することをおすすめします。
権限設計はどこまで詳細にすべきですか
最低限、部局・職位単位での読み取り・書き込み範囲と、行政処分・給付可否・審査等の承認者を明確にしてください。詳細度は対象業務のリスクに応じて調整します。
住民情報を扱う場合、必ず個人情報保護担当の確認が必要ですか
利用目的、法的根拠、データ分類、外部送信の有無によって必要度は異なりますが、要配慮個人情報を扱う場合や部局間共有・外部送信を伴う場合は、確認を得ることを強く推奨します。
二重実行防止とは何ですか
同じ処理を複数回実行しても、住民記録が二重に更新されたり、通知が重複送信されたりしない設計のことです。通信エラー時のリトライなどで重要になります。
要件・権限・承認設計を、一緒に整理しませんか。
対象業務の範囲、住民情報の権限、承認フロー、責任分界を、正式LPでのご相談を通じて具体化できます。