大手TMT企業がRobo Clawを導入する際の要件定義・権限・承認設計
対象業務が決まったら、As-Is／To-Be、入力・出力、参照データ、システム接続、本番環境へのアクセス権限、Secret管理方針、承認、責任分界、ログ、KPIを具体化します。
Refine STEPの目的は、対象業務を「誰が・どこまで・どの承認のもとで自動化するか」を文書化することです。特に、本番アクセス権限とSecret管理方針、Pull Requestや外部送信の承認条件は、この段階で明確にしてください。ここが曖昧なままPilotへ進むと、後工程で設計のやり直しが発生します。
Who This Is For
対象読者
Discover STEPで対象業務を決定した、情報システム部門、セキュリティ部門、開発部門責任者、内部監査部門の担当者を対象にしています。
What You'll Decide
このSTEPで決めること
Refine STEPでは、対象業務の範囲、扱うデータ、接続システム、本番環境へのアクセス権限、Secret管理方針、承認条件、責任分界、KPIを文書化し、Build & Validateで検証可能な要件に落とし込みます。
Industry Challenges
大手TMT企業固有の課題
プロダクトごとに権限の考え方が異なる
プロダクトやチームごとに既存の権限運用が異なり、統一した権限設計が難しくなります。
Secret管理のルールが未整備
APIキーやトークンの発行・保管について、誰がどこまで管理するかのルールが明文化されていないケースが多くあります。
PRレビューの承認基準が属人化している
どのレビューコメントを採用しマージしてよいかが、レビュアー個人の経験に依存している状態です。
責任分界が曖昧になりやすい
AIエージェントとシステム、人間の間で、障害や誤りが起きた際の責任分界が整理されていません。
Method
実施手順
1. As-Is／To-Beを整理する
現状の業務フローと、Robo Claw導入後に目指す業務フローを対比して整理します。
2. 対象範囲・入力/出力を定義する
対象業務の範囲を明確にし、入力データと出力（レビューコメント案、回答案、更新内容など）を定義します。
3. Agent・Skill・Toolを設計する
対象業務に必要なAgentの役割、業務手順のSkill、外部操作を行うToolの範囲を設計します。
4. Tool Policyを定義する
Toolが実行してよい操作（Allow／Deny）をリポジトリ・環境単位でPolicyとして定義します。
5. 本番環境へのアクセス権限を設計する
開発・検証・本番の環境別に、誰がどの範囲までAgentを利用・変更できるかを設計します。
6. Secret管理方針を定義する
APIキー・トークン等の発行、保管、ローテーションの方針を定義します。
7. 承認・エスカレーションを定義する
Pull Requestのマージ承認者、外部送信の承認者、例外時のエスカレーション先を定義します。
8. 責任分界・ログ・KPIを定義する
AIエージェント、システム、人間の間の責任分界と、保存すべき操作ログの範囲、効果測定KPIを定義します。
Data & Systems
使用するデータ・システム
Human-in-the-loop
人間承認が必要な箇所
- Pull Requestのマージ承認者を役職・チーム単位で明確にする
- 顧客への外部送信の最終承認者を役職単位で明確にする
- Secretの発行・ローテーションについて、情報システム部門の承認を得る
- プロダクト・チームをまたぐ権限付与について、情報システム部門の承認を得る
Measurement
KPI
Refine STEPでは、Build & Validateで検証するKPIの候補を定義します。
レビューコメント作成時間の目標水準
Pull Requestのレビューコメント下書き作成にかかる時間の目標
承認までのリードタイム
下書き作成から人間承認までにかかる時間
権限逸脱の検知件数
定義した権限範囲を超えた操作の検知件数
Checklist
要件定義チェックリスト
- 対象業務の範囲（含む業務・含まない業務）が文書化されている
- 入力データと出力（レビューコメント・回答案・更新内容）が定義されている
- 接続するシステムと、その接続可否が情報システム部門で確認済みである
- 開発・検証・本番環境別のアクセス権限が定義されている
- Secretの発行・保管・ローテーション方針が定義されている
- Pull Requestマージおよび外部送信の承認条件と承認者が定義されている
- 例外時のエスカレーション先とフローが定義されている
- AIエージェント・システム・人間の責任分界が文書化されている
- 操作ログの保存範囲と保存期間が定義されている
- 効果測定に使うKPIが定義されている
Pitfalls
失敗例・注意点
権限設計を後回しにする
まず動かしてから権限を調整しようとすると、複数プロダクトへの展開時に大きな手戻りが発生します。
承認者が曖昧なまま進める
承認者を役職ではなく個人名で決めると、異動・退職時に運用が止まる原因になります。
KPIを効果ありきで決める
希望的な数値をKPIに設定すると、Build & Validateでの評価が形骸化します。
FAQ
よくあるご質問
要件定義はどの部門が主導すべきですか
対象業務の現場責任者（開発、QA、SREなど）と情報システム部門が共同で主導し、外部送信を伴う場合はセキュリティ・法務部門も関与することをおすすめします。
権限設計はどこまで詳細にすべきですか
最低限、開発・検証・本番の環境別アクセス範囲と、Pull Requestマージ・外部送信の承認者を明確にしてください。詳細度は対象業務のリスクに応じて調整します。
Refineに時間をかけすぎるとどうなりますか
要件を完璧にしようとしすぎると着手が遅れます。まずはPilot規模で検証可能な範囲の要件を固め、本番拡大時に見直す前提で進めることをおすすめします。
要件定義・権限設計を、一緒に整理しませんか。
対象業務の範囲、権限、承認フロー、責任分界を、正式LPでのご相談を通じて具体化できます。