大手TMT企業におけるRobo ClawのPilot・PoC・検証方法
Refineで定義した要件をもとに、限定した対象範囲でAgent・Skill・Tool Policyを構築し、正常系・異常系・二重実行・権限外操作・API障害・人間承認を含めて検証し、本番移行の判断基準を満たすかを確認します。
Pilotは、対象業務・対象チームを1つに絞り、正常系だけでなく異常系（API障害、権限不足、Secret失効、誤操作、二重実行）まで検証してください。異常系の検証を省略すると、本番運用後に誤ったPR作成や重複処理といった問題が顕在化しやすくなります。
Who This Is For
対象読者
Refine STEPで要件を固めた、開発部門責任者、QA責任者、情報システム部門、セキュリティ部門の担当者を対象にしています。
What You'll Decide
このSTEPで決めること
Build & Validateでは、Pilotの対象範囲を確定し、Agent・Skill・Toolを構築したうえで、正常系・異常系のテストを行い、本番移行の判断基準を満たすかどうかを評価します。
Industry Challenges
大手TMT企業固有の課題
テストデータの用意が難しい
実際の顧客データやソースコードをそのままテストに使えず、テストデータの準備に時間がかかります。
異常系の想定が漏れやすい
正常なレビュー・回答フローは検証しやすい一方、API障害・権限不足・Secret失効などの異常系は想定が漏れがちです。
二重実行・誤PR作成のリスク
定期実行やリトライ処理により、同じPull Requestが重複作成される、あるいは古いブランチに変更が加わるリスクがあります。
本番移行の判断基準が曖昧
Pilotの結果をどう評価すれば本番移行してよいか、判断基準が事前に決まっていないケースが多くあります。
Method
実施手順
1. Pilotの対象範囲を確定する
1プロダクト・1〜2業務程度に絞り、検証しやすい範囲でPilotを設計します。
2. Agent・Skill・Toolを構築する
対象業務に必要なAgent、業務手順のSkill、外部操作のToolを構築します。
3. Tool Policyを設定する
Toolが実行してよい操作範囲（Allow／Deny）を検証環境向けにPolicyとして設定します。
4. テストデータを準備する
実データを模したテストチケット・ダミーリポジトリを準備し、機密情報を含まない形で検証環境を構築します。
5. 正常系をテストする
想定どおりのチケット分類・レビューコメント作成・通知フローが機能するかを確認します。
6. 異常系をテストする
API障害、権限不足、Secret失効、二重実行、承認待ちのタイムアウトなど、異常系のシナリオを確認します。
7. 人間承認・セキュリティを確認する
承認フローが設計どおりに機能するか、アクセス権限が意図どおりかを確認します。
8. ユーザー受入テストを行う
実際に利用する開発者・QA・CS担当者に使ってもらい、実務上の使いやすさを確認します。
Test Scenarios
Pilot評価表
以下は検証項目の例です。判定は「合格・条件付き合格・不合格」の3段階などで記録し、本番移行の判断材料にします。
| 検証項目 | シナリオ例 | 確認観点 |
|---|---|---|
| 正常系 | 通常のチケット分類・レビューコメント作成 | 期待どおりの分類・コメント案が作成されるか |
| 異常系（API障害） | GitHub・Jiraへの接続障害 | エラー時に安全に停止し、誤情報を出さないか |
| 異常系（二重実行） | 定期実行の重複・再実行 | 同一Pull Requestやコメントが重複作成されないか |
| 人間承認 | Pull Requestのマージ前レビュー | 承認なしにマージされないか、承認記録が残るか |
| セキュリティ | 権限外リポジトリへのアクセス試行 | 権限外の参照・更新が拒否されるか |
Data & Systems
使用するデータ・システム
Human-in-the-loop
人間承認が必要な箇所
- Pilotで生成したレビューコメント・回答案の採用可否を、テスト担当者が確認・承認する
- Tool Policyの設定内容を、情報システム部門・セキュリティ部門がレビューする
- 本番移行の可否を、事前に定めた判断基準に基づき責任者が判断する
Measurement
KPI
テストシナリオの合格率
正常系・異常系シナリオのうち合格した割合
誤実行・二重実行の発生件数
Pilot期間中に検知された誤操作・重複処理の件数
ユーザー受入評価
実際の利用者による使いやすさ・業務適合度の評価
Pitfalls
失敗例・注意点
正常系だけで合格と判断する
異常系の検証を省略すると、本番運用後にAPI障害時の挙動が想定外になります。
本番データ・本番リポジトリでテストしてしまう
検証段階から実際の顧客データや本番コードを使うと、情報漏えいや誤変更のリスクが高まります。
判断基準を事後に決める
Pilot実施後に本番移行の基準を決めようとすると、恣意的な判断になりやすくなります。
Go / No-Go Criteria
本番移行判断チェックリスト
- 正常系シナリオがすべて合格している
- 異常系シナリオ（API障害・二重実行・権限不足）を検証済みである
- 人間承認フローが設計どおりに機能している
- 権限外操作が拒否されることを確認済みである
- ユーザー受入テストで実務上の課題が解消されている
- 本番運用体制（監視・障害対応の担当）が決まっている
FAQ
よくあるご質問
Pilotの期間はどのくらいが目安ですか
対象業務やシステム連携の複雑さによって異なります。一律の期間は提示できないため、対象範囲を踏まえて個別にご相談ください。
本番コードやデータを使わずに検証できますか
可能です。実データを模したテストチケット・ダミーリポジトリを用意し、機密情報を含まない検証環境で実施することをおすすめします。
Pilotで不合格になった場合はどうなりますか
Refineの要件やTool Policyを見直し、再度Pilotを実施します。無理に本番移行せず、基準を満たすまで検証を継続することを推奨します。
Pilotの設計を、一緒に整理しませんか。
対象範囲、テストシナリオ、本番移行の判断基準を、正式LPでのご相談を通じて具体化できます。