自治体連携NGOがRobo Clawを導入する際の要件・権限・承認設計
対象業務が決まったら、As-Is／To-Be、対象事業・地域・窓口、自治体との契約・協定上の責任分界、入力・出力、データ分類、個人情報・要配慮情報、読み取り・書き込み権限、職員・ボランティアの権限分離、人間承認、専門職確認、ログ、KPIを具体化します。
Refine STEPの目的は、対象業務を「誰が・どこまで・どの承認のもとで自動化するか」を文書化することです。特に、支援対象者の個人情報・要配慮情報のデータ分類と利用目的・本人同意・法的根拠、自治体との責任分界、職員・ボランティア・外部委託先の権限分離は、この段階で明確にしてください。ここが曖昧なままPilotへ進むと、後工程で設計のやり直しが発生します。
Who This Is For
対象読者
Discover STEPで対象業務を決定した、事業責任者、情報システム担当（兼務含む）、相談支援員、理事を対象にしています。
What You'll Decide
このSTEPで決めること
Refine STEPでは、対象業務の範囲、扱うデータの分類、接続するシステム、読み取り・書き込み権限、承認条件、自治体との責任分界、職員・ボランティアの権限分離、KPIを文書化し、Build & Validateで検証可能な要件に落とし込みます。
Industry Challenges
自治体連携NGO・NPO固有の課題
データ分類の整理が不十分
相談記録・支援記録の個人情報・要配慮情報がどの分類に属し、どこまで利用可能かの整理が進んでいないケースが多くあります。
自治体との責任分界のルールが未整備
委託事業・協定における個人情報の共有範囲や報告の承認者について、明文化されていないケースがあります。
職員とボランティアの役割が曖昧
常勤職員、非常勤スタッフ、ボランティアの役割分担が明確でない状態で運用されていることがあります。
説明責任の所在が不明確
AIエージェントの出力を利用した結果について、誰が最終的な説明責任を負うかが整理されていないケースがあります。
Method
実施手順
1. As-Is／To-Beを整理する
現状の業務フローと、Robo Claw導入後に目指す業務フローを対比して整理します。
2. 対象事業・地域・窓口を定義する
対象となる事業、地域、相談窓口の範囲を明確にします。
3. Agent・Skill・Toolを設計する
対象業務に必要なAgentの役割、業務手順のSkill、システム操作を行うToolの範囲を設計します。
4. データ分類・利用目的・法的根拠を確認する
入力・出力データが個人情報・要配慮情報に該当するか、利用目的・本人同意・法的根拠を確認します。
5. Tool Policyと権限を設計する
Toolが実行してよい操作（読み取り／書き込み、Allow／Deny）と、外部送信の可否をPolicyとして定義します。
6. 自治体との責任分界を確認する
委託仕様書・協定書をもとに、データ共有範囲や報告の承認プロセスを自治体担当者と確認します。
7. 職員・ボランティアの権限分離を定義する
常勤職員、非常勤スタッフ、ボランティア、外部委託先ごとにアクセス権限を分離します。
8. 人間承認・専門職エスカレーションを定義する
出力を利用した結果の承認者と、危険度判定等が必要な場合の専門職エスカレーション先を定義します。
9. ログ・保存期間・KPIを定義する
操作ログ・監査証跡の保存範囲と保存期間、効果測定KPIを定義します。
Data & Systems
使用するデータ・システム
Human-in-the-loop
人間承認が必要な箇所
- 支援対象者の採否・処遇・危険度判定につながる出力の確認者を役割単位で明確にする
- 個人情報・要配慮情報を扱う範囲について、専門職・法務の確認を得る
- 自治体への報告・住民向け送信を伴う出力の承認者を明確にする
- 職員・ボランティアをまたぐ権限付与について、事業責任者の承認を得る
Measurement
KPI
Refine STEPでは、Build & Validateで検証するKPIの候補を定義します。
問い合わせ一次分類時間の目標水準
問い合わせ分類にかかる時間の目標
承認までのリードタイム
出力作成から人間承認までにかかる時間
権限逸脱の検知件数
定義した権限範囲を超えた操作の検知件数
Checklist
要件定義チェックリスト
- 対象事業・地域・窓口（含む業務・含まない業務）が文書化されている
- 入力データと出力（要約案・報告書案・分類結果）が定義されている
- 扱うデータの分類（個人情報・要配慮情報等）と利用目的・本人同意・法的根拠が確認されている
- 読み取り・書き込み別のアクセス権限が定義されている
- 自治体との責任分界（データ共有範囲・報告承認プロセス）が確認されている
- 職員・ボランティア・外部委託先の権限分離が定義されている
- 専門職へのエスカレーション先とフローが定義されている
- 出力利用結果の説明責任の所在が定義されている
- 操作ログ・監査証跡の保存範囲と保存期間が定義されている
- 効果測定に使うKPIが定義されている
Pitfalls
失敗例・注意点
データ分類の確認を省略する
データ分類を確認せずに進めると、後で個人情報・要配慮情報の取り扱いに関する重大な手戻りが発生します。
承認者が曖昧なまま進める
承認者を役職ではなく個人名で決めると、異動・退任時に運用が止まる原因になります。
最終判断の所在を明文化しない
AIの出力がそのまま最終判断として扱われる運用にならないよう、責任分界を明文化する必要があります。
FAQ
よくあるご質問
要件定義はどの立場が主導すべきですか
対象事業の責任者と情報システム担当（兼務含む）が共同で主導し、個人情報・要配慮情報・自治体への送信を伴う場合は専門職・法務・自治体担当者も関与することをおすすめします。
権限設計はどこまで詳細にすべきですか
最低限、事業単位での読み取り・書き込み範囲と、支援対象者に関わる出力の承認者を明確にしてください。詳細度は対象業務のリスクに応じて調整します。
自治体との責任分界はどのように確認しますか
委託仕様書・協定書・助成金要項の内容をもとに、データ共有範囲や報告の承認プロセスを自治体担当者と個別に確認することをおすすめします。
要件・権限・承認設計を、一緒に整理しませんか。
対象業務の範囲、データ分類、自治体との責任分界、権限、承認フローを、正式LPでのご相談を通じて具体化できます。