目次
第1 デモの成功を検収条件に置き換える第2 調査・設定・開発・運用の範囲を分ける第3 検収する環境と成功条件を固定する第4 承認を減らす設計と権限の拡大を分ける第5 エラーの種類と再開条件を試験する第6 更新と追加開発の費用・担当を決める第7 障害対応と記録の引渡しを具体化する第8 終了時は別の担当者が再開できるかを確かめる第9 発注前に確認したい事項第10 関連記事と資料の位置付け
第1 デモの成功を検収条件に置き換える
AIエージェントの導入を外注するときは,「このデモと同じことができる」「あとはAIに任せられる」という説明を,対象業務,利用環境,許す操作及び合否を確認する方法へ置き換えたい。
文章を生成できたこと,指定した場所へ保存できたこと,外部システムへ送信できたこと及び受信者が受領したことは,それぞれ別の確認事項である。
本記事は,PC上のファイル,ブラウザー又は外部サービスを操作するAIエージェントについて,導入を依頼する企業・士業事務所の側から,契約と検収で確認する事項を整理する。
以下の表は契約交渉と試験計画のための提案であり,法令が一律に定める検収方式,特定製品の動作保証又はそのまま締結できる契約書のひな型ではない。
まず合意したいのは,①何を納めるか,②どの環境で何ができれば合格か,③どこで人の承認へ戻すか,④更新・障害・終了に誰が対応するか,という事項である。
機能の追加要望と,合意済みの機能が動かない問題を分けて記録すると,検収時の話合いもしやすくなる。
第2 調査・設定・開発・運用の範囲を分ける
「AI導入一式」という名称だけで,調査,設定,個別開発及び継続保守の全てを含むと考えない。
発注書,仕様書,見積書及び適用されるサービス規約を対応させ,成果物と継続する作業を分けて確認する。
工程発注前に具体化すること受け取るものの例調査・実証対象業務,利用できる資料,試行条件,実現できない場合の終了条件調査結果,試行記録,制約と見積りの前提設定・連携対象端末・アプリ・アカウント,読み書きできる範囲,承認条件設定差分,構成一覧,権限表,復元手順個別開発入出力,外部サービスとの接続,異常時の処理,変更手続合意したプログラム・設定,試験結果,利用・改修に必要な資料運用・保守監視,問い合わせ,原因調査,修復,更新,利用料の管理対応範囲表,連絡先,作業記録,更新後の確認結果
利用料には,導入支援の対価のほか,モデル,API,クラウド又は連携サービスの費用が生じる構成もある。
契約上の費用負担者,利用量の警告を受ける者,上限到達時の扱い及び超過を認める者を確認する。
IPAの情報システム・モデル取引・契約書(第二版)は,仕様や検収方法等について当事者間で共通理解を深めるための参考資料になる。
AIを利用するという名称だけで工程の性質や責任範囲を決めず,実際に引き受ける作業と結果を契約書類へ対応させることが本記事の提案である。
第3 検収する環境と成功条件を固定する
試験記録には,端末,OS,アプリ・拡張機能・モデル等の版,利用プラン,アカウントの役割,接続先及び設定の版を残す。
提供者の実演環境と発注者の実利用環境が違う場合は,その差を確認してから試験結果を評価する。
確認項目合否を決める前にそろえる条件対象業務入力資料,対象件数,必要な出力,品質基準,対象外の作業利用環境対象端末・OS・アプリの版,アカウント,連携先,適用設定完了の定義作成,保存,送信,公開,受領を分けた確認方法人の作業修正,承認,例外対応に必要な担当者と総所要時間失敗の扱い対象外入力,拒否,通信断,成否不明,停止後に残る処理
成功した例だけでなく,資料不足,対象外の保存先,未承認の送信及び途中の接続断を,秘密情報を含まない資料と隔離した試験先で確認する。
本番の依頼者情報を試験に使ったり,拒否の試験のために実際の送信・削除を行ったりする必要はない。
合意した機能を確認する検収と,担当者の教育,必要な承認及び保守窓口を整えた上での運用開始も区別したい。
未確認の用途を対応済みと表示せず,試験していない範囲と利用上の制限を記録する。
第4 承認を減らす設計と権限の拡大を分ける
低危険度の操作まで毎回確認する仕組みでは,確認の負担が大きくなる。
他方,その負担を減らすために全ファイル,全アプリ又は外部送信まで一括許可する設計にはしない。
Anthropicのauto modeに関する公式解説は,反復する承認と権限確認の省略に伴う危険を扱っている。
MicrosoftのAIエージェントの最小権限に関する公式説明も,目的,対象,ツール及び実効的な権限を確認する考え方の参考になる。
いずれも提供者の技術資料であり,日本の事業者に同じ設定を一律に義務付ける法的基準ではない。