Step 2・Refine

NGOがRobo Clawを導入する際の要件・権限・承認設計

Discover STEPで決めた対象業務を、対象事業・地域・言語・デジタルチャネルの範囲、Agent・Skill・Tool・Tool Policy、支援者・寄付者・受益者・ボランティア情報の分類、読み取り・書き込み権限、支援・助成・安全判断との分離、寄付・支出・送金との分離、外部公開・送信の承認、本部・現地・委託先・ボランティアの責任分担、ログ・監査証跡、二重実行・重複送信・誤公開防止、KPIまで具体化します。

Who This Is For

対象読者

Discover STEPで対象業務を決定した、事業責任者、情報システム兼務担当、個人情報保護担当、理事を対象にしています。

What You'll Decide

このSTEPで決めること

Refine STEPでは、対象事業・地域・言語・デジタルチャネルの範囲、扱うデータの分類、接続するシステム、読み取り・書き込み権限、承認条件、本部・現地・委託先・ボランティアの責任分担、KPIを文書化します。

Industry Challenges

NGO・NPO固有の課題

01

データ分類の整理が不十分

支援対象者情報や未成年者情報がどの分類に属し、どこまで利用可能かの整理が進んでいないケースが多くあります。

02

本部・現地・委託先・ボランティア間の責任分界のルールが未整備

委託契約やボランティア規約における情報共有範囲や報告の承認者について、明文化されていないケースがあります。

03

職員とボランティアの役割が曖昧

常勤職員、非常勤スタッフ、ボランティアの役割分担が明確でない状態で運用されていることがあります。

04

説明責任の所在が不明確

AIエージェントの出力を利用した結果について、誰が最終的な説明責任を負うかが整理されていないケースがあります。

Method

実施手順

1. As-Is/To-Beを整理する

現状のデジタル業務フローと、Robo Claw導入後に目指す業務フローを対比して整理します。

2. 対象事業・地域・言語・デジタルチャネルを定義する

対象となる事業、地域、言語、利用するデジタルチャネル(メール・SNS・フォーム等)の範囲を明確にします。

3. Agent・Skill・Toolを設計する

対象業務に必要なAgentの役割、業務手順のSkill、システム操作を行うToolの範囲を設計します。

4. 支援者・寄付者・受益者・ボランティア情報の取扱いを確認する

各情報の入力元・更新方法・正確性の確認方法を整理します。

5. 個人・要配慮情報の利用目的・法的根拠を確認する

支援対象者の個人情報・要配慮情報を扱うか、利用目的・本人同意・法的根拠を確認します。

6. Tool Policyと読み取り・書き込み権限を設計する

Toolが実行してよい操作(読み取り/書き込み、Allow/Deny)と、外部送信・公開確定の可否をPolicyとして定義します。

7. 本部・現地・委託先の責任分界を確認する

委託仕様書・協定書をもとに、データ共有範囲や報告の承認プロセスを関係者と確認します。

8. 職員・ボランティア・現地スタッフの権限分離を定義する

常勤職員、非常勤スタッフ、ボランティア、現地スタッフごとにアクセス権限を分離します。

9. 人間承認・責任者確認を定義する

出力を利用した結果の承認者と、支援対象者の採否・助成可否・安全判断が必要な場合の責任者へのエスカレーション先を定義します。

10. ログ・保存期間・二重実行/重複送信防止・KPIを定義する

操作ログ・監査証跡の保存範囲と保存期間、二重実行・重複送信の防止策、効果測定KPIを定義します。

Data & Systems

使用するデータ・システム

支援者・寄付者情報(分類確認済みの範囲) 支援対象者情報・要配慮情報 拠点情報・連絡先情報 委託先情報・委託契約 助成条件・協定書 アクセス権限台帳 文書管理・クラウドストレージ 権限・ID管理の仕組み

Human-in-the-loop

人間承認が必要な箇所

  • 支援対象者の採否・助成可否・安全判断につながる出力の確認者を役割単位で明確にする
  • 個人情報・要配慮情報を扱う範囲について、個人情報保護担当・法務の確認を得る
  • 支援者・寄付者・受益者への送信やウェブ・SNSへの公開を伴う出力の承認者を明確にする
  • 職員・ボランティア・現地スタッフをまたぐ権限付与について、事業責任者の承認を得る

Measurement

KPI

Refine STEPでは、Build & Validateで検証するKPIの候補を定義します。

問い合わせ一次分類時間の目標水準

問い合わせの一次分類にかかる時間の目標

承認までのリードタイム

出力作成から人間承認までにかかる時間

権限逸脱・重複送信候補の検知件数

定義した権限範囲を超えた操作や、重複送信候補の検知件数

Checklist

要件定義チェックリスト

  • 対象事業・地域・言語・デジタルチャネル(含む業務・含まない業務)が文書化されている
  • 入力データと出力(返信案・報告書案・投稿案)が定義されている
  • 扱うデータの分類(支援対象者情報・個人情報・要配慮情報等)と利用目的・本人同意・法的根拠が確認されている
  • 読み取り・書き込み別のアクセス権限が定義されている
  • 本部・現地・委託先・ボランティアの責任分界(データ共有範囲・報告承認プロセス)が確認されている
  • 職員・ボランティア・現地スタッフの権限分離が定義されている
  • 事業・安全・個人情報責任者へのエスカレーション先とフローが定義されている
  • 出力利用結果の説明責任の所在が定義されている
  • 操作ログ・監査証跡の保存範囲と保存期間、二重実行・重複送信・誤公開の防止策が定義されている
  • 効果測定に使うKPIが定義されている

Pitfalls

失敗例・注意点

01

データ分類の確認を省略する

データ分類を確認せずに進めると、後で支援対象者情報・個人情報の取り扱いに関する重大な手戻りが発生します。

02

承認者が曖昧なまま進める

承認者を役職ではなく個人名で決めると、異動・退任・ボランティア交代時に運用が止まる原因になります。

03

最終判断の所在を明文化しない

AIの出力がそのまま支援対象者の採否・助成可否の判断として扱われる運用にならないよう、責任分界を明文化する必要があります。

FAQ

よくあるご質問

要件定義には誰が参加すべきですか

事業責任者、情報システム兼務担当、個人情報保護担当、現地責任者が最低限参加することをおすすめします。要配慮情報を扱う場合は法務・専門職の確認も必要です。

Tool Policyとは何ですか

Toolが実行してよい操作範囲(読み取り/書き込み、外部送信の可否、公開の確定処理の可否等)を明文化したルールです。Robo Clawでは業務ごとにTool Policyを設計します。

権限分離はどこまで細かく設計すべきですか

最低限、常勤職員・非常勤スタッフ・ボランティア・現地スタッフの4区分での分離を推奨します。地域数や言語数が増える場合は、地域単位・言語単位の分離も検討してください。

二重実行・重複送信の防止はどう設計しますか

同一の返信・報告が複数回生成・送信されないよう、実行ID・べき等性チェック、および人間による最終確認を組み合わせて設計します。詳細はBuild & ValidateとDeploy & Operateの記事で解説します。

要件・権限・承認設計を、一緒に整理しませんか。

対象事業・データ分類・責任分界・承認体制を確認し、要件定義を正式LPでご相談いただけます。

要件定義を相談する