Who This Is For
対象読者
Discover STEPで対象業務を決定した、プロダクト責任者、官公庁営業・自治体営業担当、情報セキュリティ担当、個人情報保護担当、法務担当を対象にしています。
What You'll Decide
このSTEPで決めること
Refine STEPでは、対象自治体・部署・制度・住民接点の範囲、扱うデータの分類、接続するシステム、読み取り・書き込み権限、承認条件、自治体・スタートアップ・再委託先の責任分担、KPIを文書化します。
Industry Challenges
GovTechスタートアップ固有の課題
データ分類の整理が不十分
住民情報や要配慮情報がどの分類に属し、どこまで利用可能かの整理が進んでいないケースが多くあります。
自治体・スタートアップ・再委託先間の責任分界のルールが未整備
契約・仕様書における情報共有範囲や承認者について、明文化されていないケースがあります。
自治体ごとに要件・様式が異なる
同じ業務でも自治体ごとに求められる要件・様式が異なり、共通の要件定義に落とし込みにくい状態です。
説明責任の所在が不明確
AIエージェントの出力を利用した結果について、誰が最終的な説明責任を負うかが整理されていないケースがあります。
Method
実施手順
1. As-Is／To-Beを整理する
現状の業務フローと、Robo Claw導入後に目指す業務フローを対比して整理します。
2. 対象自治体・部署・制度・住民接点を定義する
対象となる自治体、部署、制度、住民接点(問い合わせ・申請・予約等)の範囲を明確にします。
3. Agent・Skill・Toolを設計する
対象業務に必要なAgentの役割、業務手順のSkill、システム操作を行うToolの範囲を設計します。
4. 住民情報・本人確認情報・要配慮情報の取扱いを確認する
各情報の入力元・更新方法・正確性の確認方法を整理します。
5. 個人・要配慮情報の利用目的・法的根拠・同意を確認する
住民の個人情報・要配慮情報を扱うか、利用目的・本人同意・法的根拠を確認します。
6. Tool Policyと読み取り・書き込み権限を設計する
Toolが実行してよい操作（読み取り／書き込み、Allow／Deny）と、外部送信・住民情報更新の可否をPolicyとして定義します。
7. 給付・資格・本人確認判断との分離を確認する
給付・資格・本人確認の判断が自治体担当者・所管部署の確認を経る設計になっているかを確認します。
8. 申請承認・却下・住民情報更新との分離を確認する
申請の承認・却下や住民記録の更新が、自治体側の承認を経る設計になっているかを確認します。
9. 契約・調達・特定個人情報の扱いを確認する
契約・調達・支出の確定やマイナンバー等特定個人情報の扱いが、AIの自動化範囲から分離されているかを確認します。
10. 自治体・スタートアップ・再委託先の責任分界を確認する
契約・仕様書をもとに、データ共有範囲や承認プロセスを自治体担当者と確認します。
11. 人間承認・責任者確認を定義する
出力を利用した結果の承認者と、給付・資格・本人確認判断が必要な場合の所管部署へのエスカレーション先を定義します。
12. ログ・保存期間・二重実行/重複申請処理防止・KPIを定義する
操作ログ・監査証跡の保存範囲と保存期間、二重実行・重複申請処理・誤送信の防止策、効果測定KPIを定義します。
Data & Systems
使用するデータ・システム
Human-in-the-loop
人間承認が必要な箇所
- 給付・資格・本人確認判断につながる出力の確認者を役割単位で明確にする
- 個人情報・要配慮情報を扱う範囲について、個人情報保護担当・所管部署の確認を得る
- 住民・自治体担当者への送信、住民向け重要通知を伴う出力の承認者を明確にする
- スタートアップ・自治体・再委託先をまたぐ権限付与について、プロジェクト責任者の承認を得る
Measurement
KPI
Refine STEPでは、Build & Validateで検証するKPIの候補を定義します。
問い合わせ一次分類時間の目標水準
問い合わせの一次分類にかかる時間の目標
承認までのリードタイム
出力作成から人間承認までにかかる時間
権限逸脱・重複申請処理候補の検知件数
定義した権限範囲を超えた操作や、重複申請処理候補の検知件数
Checklist
要件定義チェックリスト
- 対象自治体・部署・制度・住民接点（含む業務・含まない業務）が文書化されている
- 入力データと出力（回答案・報告書案・不足項目候補等）が定義されている
- 扱うデータの分類（住民情報・個人情報・要配慮情報・本人確認情報等）と利用目的・本人同意・法的根拠が確認されている
- 読み取り・書き込み別のアクセス権限が定義されている
- 自治体・スタートアップ・再委託先の責任分界（データ共有範囲・承認プロセス）が確認されている
- マイナンバー等特定個人情報の扱い（対象外または厳格分離）が定義されている
- 自治体所管部署・情報政策/セキュリティ・個人情報保護担当へのエスカレーション先とフローが定義されている
- 出力利用結果の説明責任の所在が定義されている
- 操作ログ・監査証跡の保存範囲と保存期間、二重実行・重複申請処理・誤送信の防止策が定義されている
- 効果測定に使うKPIが定義されている
Pitfalls
失敗例・注意点
データ分類の確認を省略する
データ分類を確認せずに進めると、後で住民の個人情報・要配慮情報の取り扱いに関する重大な手戻りが発生します。
承認者が曖昧なまま進める
承認者を役職ではなく個人名で決めると、異動・担当変更時に運用が止まる原因になります。
最終判断の所在を明文化しない
AIの出力がそのまま行政処分・給付・資格判断として扱われる運用にならないよう、責任分界を明文化する必要があります。
FAQ
よくあるご質問
要件定義には誰が参加すべきですか
プロダクト責任者、情報セキュリティ担当、個人情報保護担当、法務担当が最低限参加することをおすすめします。自治体との責任分界に関わる論点は、自治体側の担当者との確認も必要です。
Tool Policyとは何ですか
Toolが実行してよい操作範囲（読み取り／書き込み、外部送信の可否、住民情報更新処理の可否等）を明文化したルールです。Robo Clawでは業務ごとにTool Policyを設計します。
権限分離はどこまで細かく設計すべきですか
最低限、スタートアップ社内・自治体担当者・再委託先の3区分での分離を推奨します。対応自治体数が増える場合は、自治体単位・部署単位の分離も検討してください。
マイナンバー等の特定個人情報は要件に含めるべきですか
初期導入では対象外とすることをおすすめします。対象に含める場合は、厳格な分離と専門職・自治体担当者による個別確認を前提に設計してください。
要件・権限・承認設計を、一緒に整理しませんか。
対象自治体・部署・データ分類・責任分界・承認体制を確認し、要件定義を正式LPでご相談いただけます。