AIエージェントの導入・保守を外注するときの契約―検収，権限設定，更新及び障害対応（AI作成）

第１　デモの成功を検収条件に置き換える

AIエージェントの導入を外注するときは，「このデモと同じことができる」「あとはAIに任せられる」という説明を，対象業務，利用環境，許す操作及び合否を確認する方法へ置き換えたい。
文章を生成できたこと，指定した場所へ保存できたこと，外部システムへ送信できたこと及び受信者が受領したことは，それぞれ別の確認事項である。

本記事は，PC上のファイル，ブラウザー又は外部サービスを操作するAIエージェントについて，導入を依頼する企業・士業事務所の側から，契約と検収で確認する事項を整理する。
以下の表は契約交渉と試験計画のための提案であり，法令が一律に定める検収方式，特定製品の動作保証又はそのまま締結できる契約書のひな型ではない。

まず合意したいのは，①何を納めるか，②どの環境で何ができれば合格か，③どこで人の承認へ戻すか，④更新・障害・終了に誰が対応するか，という事項である。
機能の追加要望と，合意済みの機能が動かない問題を分けて記録すると，検収時の話合いもしやすくなる。

第２　調査・設定・開発・運用の範囲を分ける

「AI導入一式」という名称だけで，調査，設定，個別開発及び継続保守の全てを含むと考えない。
発注書，仕様書，見積書及び適用されるサービス規約を対応させ，成果物と継続する作業を分けて確認する。

利用料には，導入支援の対価のほか，モデル，API，クラウド又は連携サービスの費用が生じる構成もある。
契約上の費用負担者，利用量の警告を受ける者，上限到達時の扱い及び超過を認める者を確認する。

IPAの情報システム・モデル取引・契約書（第二版）は，仕様や検収方法等について当事者間で共通理解を深めるための参考資料になる。
AIを利用するという名称だけで工程の性質や責任範囲を決めず，実際に引き受ける作業と結果を契約書類へ対応させることが本記事の提案である。

第３　検収する環境と成功条件を固定する

試験記録には，端末，OS，アプリ・拡張機能・モデル等の版，利用プラン，アカウントの役割，接続先及び設定の版を残す。
提供者の実演環境と発注者の実利用環境が違う場合は，その差を確認してから試験結果を評価する。

成功した例だけでなく，資料不足，対象外の保存先，未承認の送信及び途中の接続断を，秘密情報を含まない資料と隔離した試験先で確認する。
本番の依頼者情報を試験に使ったり，拒否の試験のために実際の送信・削除を行ったりする必要はない。

合意した機能を確認する検収と，担当者の教育，必要な承認及び保守窓口を整えた上での運用開始も区別したい。
未確認の用途を対応済みと表示せず，試験していない範囲と利用上の制限を記録する。

第４　承認を減らす設計と権限の拡大を分ける

低危険度の操作まで毎回確認する仕組みでは，確認の負担が大きくなる。
他方，その負担を減らすために全ファイル，全アプリ又は外部送信まで一括許可する設計にはしない。

Anthropicのauto modeに関する公式解説は，反復する承認と権限確認の省略に伴う危険を扱っている。
MicrosoftのAIエージェントの最小権限に関する公式説明も，目的，対象，ツール及び実効的な権限を確認する考え方の参考になる。
いずれも提供者の技術資料であり，日本の事業者に同じ設定を一律に義務付ける法的基準ではない。

発注時には，利用者が許した業務，システム上の実行権限，自動審査及び独自のチェックを分けて説明してもらう。
読取り，作業用の新規保存，既存原本の上書き，外部送信，公開，削除及び権限変更について，許可範囲と人へ戻す条件を権限表にする方法が考えられる。

設定変更の納品では，変更前後の差分，変更理由，維持した安全対策，試験した操作及び元へ戻す方法を受け取る。
審査が通ったことだけで利用者の依頼範囲が広がったと扱わず，アプリを操作できることだけで全データへのアクセスや公開を許されたと扱わない。

第５　エラーの種類と再開条件を試験する

AWSのタイムアウトと再試行に関する公式解説は，応答が得られなくても処理の副作用が発生している場合を説明している。
契約上の確認例として，保存先や送信先の現在状態を調べる手段，二重実行を防ぐ方法，確認できない場合の担当者への連絡を試験項目へ入れたい。

通常の取得失敗，設定の不整合及び明示的な拒否を同じ「AIが止まった」という結果へまとめない。
拒否を別アカウントや別経路で回避する手順を復旧方法として受け入れず，許される再審査又は管理者の確認へ戻す条件を定める。

第６　更新と追加開発の費用・担当を決める

導入後には，OS，アプリ，連携先又はAIサービスの変更があり得る。
Microsoftの安全な導入に関する公式説明は，設定変更も含めた事前確認，段階的な導入及び回復の設計を考える参考になる。

発注者としては，合意済みの機能の不具合，外部サービスの仕様変更への対応，利用範囲の拡大及び新機能の追加を分け，誰が調査・判断し，料金へどう反映するかを確認する。
どの類型に当たるかを担当者だけで断定せず，発生条件と契約書類を照合して協議する手順を置く。

更新前には，設定と復旧に必要な資料を保全し，代表的な業務の確認項目を固定する。
更新後は，起動したことだけで合格とせず，同じ入力・権限・完了条件で再試験し，確認できなかった項目と利用を制限する範囲を残す。

別のPCへ設定を移す場合も，ファイルのコピー，移行先での読込み，実効権限及び業務の動作確認を分ける。
一台で確認できた結果を，未試験の全端末での動作保証へ広げない。

第７　障害対応と記録の引渡しを具体化する

保守の確認では，問い合わせの受付時間，最初の応答，原因調査，暫定対応，修復及び復旧後の確認を分ける。
「迅速に対応する」という表現だけで済ませず，優先度，連絡先，必要な資料及び時間外の扱いを合意したい。

ログについては，取得する者，閲覧できる者，保管先，保存期間，秘密情報を減らす方法及び障害時の提供範囲を確認する。
画面画像だけで足りるか，元ファイル，受付情報，設定の版又は操作記録も必要かを，問題の性質に合わせて決める。

提供者が制御できる設定と，第三者サービスが制御する仕様も分ける。
第三者の変更が原因であるという説明だけで対応を終えず，調査結果，残る制限，代替業務及び次に判断する者を記録することを契約上の確認例とする。

第８　終了時は別の担当者が再開できるかを確かめる

契約終了時には，成果物，設定，必要な利用・改修権限，手順書，試験記録及び未解決事項の引渡しを確認する。
認証情報は手順書へ秘密の値を貼り付けず，発注者が管理できる方法で引き継ぎ，提供者に残るアクセスを整理する。

受け取ったファイルを実際に開き，版，添付及び参照先を確認する。
別の担当者又は環境で業務を再開する試験も計画し，「出力できた」「受信箱へ置いた」「相手が読めた」という状態を区別して記録する。

利用停止，課金停止，アクセス失効，データ返還及び削除は，それぞれ契約と実際の操作を対応させる。
保存が必要な原資料まで一括削除せず，返還物と削除対象，残る複製・ログ及び確認できる範囲を具体化する。

第９　発注前に確認したい事項

費用や時間の短縮は，発注者の確認・修正・承認を含む総作業で評価する。
検収記録と運用記録を残し，できたこと，できなかったこと及び次の判断者を説明できる状態にしたい。

第１０　関連記事と資料の位置付け

事務所内の権限と承認の設計は，AIエージェントに専用PCを与えるときの安全設計を参照されたい。
停止後の外部状態の確認と二重実行の防止は，AIエージェントが停止したときの再開手順で扱っている。

提供する側の料金と保守工数は，AIエージェント導入支援の採算を考えるで整理している。
本記事は発注者側の契約・検収を対象とし，個別の契約不適合，解除又は損害賠償の結論を示すものではない。

前記のIPA資料と各社の公式技術資料を基に，本文の範囲表，試験表及び確認事項を実務上の提案としてまとめた。
資料が説明する特定の製品・工程と，発注者が実際に使う環境の一致は，導入時に別途確認する必要がある。