AIシステムの納品、何を確認して検収する？担当者のチェック表

AIシステムを受け取ったら、まずは納品物リストと契約書を照らし合わせ、機能・バージョン・管理IDが揃っているかを確認します。その後、コードの権利や運用マニュアルを点検し、検収合格と支払判断の根拠を整えることが重要です。以下のチェック項目を順に実施してください。

納品物の内容と範囲を確認する

機能実装は契約通りか

契約書や要件定義に記載された機能一覧と、ベンダーが提供したデモやテスト結果を照合します。機能が欠落している場合は、納品物リストにチェックを入れ、担当者へ修正依頼を出す必要があります。実務部門には実際の業務フローで試用してもらい、期待した出力が得られるか具体的に確認させます。

質問例としては「この結果は業務上どのように活用できるか」「期待した精度は満たされているか」などがあります。記録は検収資料として残すと、後の評価がスムーズです。さらに、機能ごとに受入テストの合格基準を明示し、テスト結果シートにサインオフすることで、合意内容が明確になります。

バージョン情報と管理IDは揃っているか

ベンダーから受領したソフトウェアは、リリース番号やビルド番号が明示された形で受け取ります。バージョンが不明確だと、将来のパッチ適用や障害調査で混乱を招くため、一覧表にまとめて管理者に確認します。リポジトリのURL、ブランチ名、タグ情報も同時に取得し、社内リポジトリへミラーリングできるか確認してください。

ミラーリングが可能であれば、変更履歴の追跡が容易になり、保守コストの低減につながります。また、バージョン管理方針（例：Semantic Versioning）を契約書に盛り込み、ベンダーが遵守しているかを確認することが重要です。

残課題や例外は記録されているか

納品時に残っているバグや未実装項目は、課題管理ツール（Jira、Redmine 等）にチケットとして残すことが推奨されます。未解決課題の一覧と優先度、対応予定日をベンダーと合意し、文書化しておきます。この一覧を検収合格条件に組み込むことで、未解決課題があるまま支払うリスクを防げます。

社内では課題担当者と期限を明確にし、定期的にステータスをレビューする体制を整えておくと安心です。さらに、課題の重要度に応じて支払額の一部留保や保証金の設定を検討することも、リスク低減策として有効です。

ソースコードと権利関係のチェック

コードの完全性とビルド手順

ベンダーから受領したソースコードは、全ファイルが揃っているか、ビルド手順書と合わせて確認します。社内の開発環境で実際にビルドを試し、成功するかどうかでコードの完全性を検証します。手順書には依存ライブラリのバージョンやコンパイルオプション、実行環境の前提条件が記載されている必要があります。

これらが不足していると、運用開始後に環境不整合が発生しやすくなるため、チェックリスト化して抜けを防ぎます。ビルドが成功したら、生成された実行ファイルのハッシュ値を取得し、納品物リストに添付して改ざん防止の根拠とします。

知的財産権とライセンスの取り扱い

納品されたコードにオープンソースが含まれる場合、使用許諾（MIT、Apache、GPL 等）と自社での再配布条件を確認します。ベンダーからは、コードの著作権が自社に譲渡される旨の書面（権利譲渡契約）を取得してください。権利譲渡が不十分だと、将来的に商用利用や二次開発で法的リスクが生じる可能性があります。

法務部門と連携し、契約書に「全ての知的財産権を譲渡する」条項が含まれているか最終確認します。また、第三者の特許権侵害リスクを回避するため、ベンダーに対し「侵害の不存在」保証の有無を確認することも検討してください。

セキュリティ診断結果の有無

AIシステムは外部API呼び出しや大量データ処理が多く、脆弱性リスクが高いです。納品時にベンダーが実施したセキュリティ診断（コードスキャンやペネトレーションテスト等）のレポートを受領し、主要な脆弱性が修正済みか確認します。

診断結果が未提供の場合は、追加実施を依頼し、修正完了後の再診断結果を取得します。社内の情報セキュリティ担当者と協議し、リスク評価基準に合致しているか最終判断します。さらに、診断レポートの添付資料として「脆弱性対応計画」も受領し、期限と担当者を明示しておくと、後続の運用管理が楽になります。

運用・保守資料の受領と評価

ユーザーマニュアルと手順書の内容

システム利用者がスムーズに操作できるよう、ベンダーから提供されるユーザーマニュアルと運用手順書を詳細に確認します。マニュアルは画面キャプチャや操作例が含まれ、手順書はインシデント時の対応フローが記載されている必要があります。

受領した資料は、担当者が手順通りに作業できるかテストし、抜けや曖昧な表現がないかチェックリストに記入します。問題があればベンダーに修正依頼を行い、最終版を正式に受領します。加えて、マニュアルの改訂履歴を管理し、バージョン管理とリンクさせることで、将来の更新時に混乱が起きにくくなります。

障害対応フローとサポート体制

AIシステムは障害発生時の復旧が重要です。ベンダーが提示する障害対応フロー（一次窓口、エスカレーションルート、復旧目安時間）を社内IT部門と照らし合わせ、SLA（サービスレベル合意）として文書化します。サポート体制（営業時間、連絡方法、オンサイト対応の有無）も併せて確認し、社内の運用担当者に共有します。

SLA が契約条件と合致しない場合は、交渉材料として提示できるように準備しておきます。さらに、障害時のインシデント報告テンプレートを作成し、報告フローを自動化できるツール（例：ITSM）と連携させると、対応スピードが向上します。

教育・トレーニング資料の提供状況

AIシステムの効果的な活用には、利用者向けのトレーニングが不可欠です。ベンダーから提供される研修資料や動画、ハンズオン演習の有無を確認し、社内で実施できる体制を整えます。トレーニング実施後は、受講者の理解度をアンケートやテストで測定し、結果を検収資料に添付します。

教育が不十分だとシステムの本来価値が発揮できないため、教育計画も検収項目に含めることがポイントです。加えて、トレーニング実施記録を社内ラーニング管理システムに登録し、継続的なスキル維持の仕組みを構築しておくと、運用定着率が上がります。

検収結果の判断と次のステップ

合格基準と評価シートの活用

検収合格の基準は、契約書に記載された機能要件・品質要件・納期要件を満たすかどうかです。評価シートを作成し、各項目に対して「合格」「保留」「不合格」の判定を付けます。評価シートはプロジェクトマネージャー、開発担当者、利用部門の代表が共同で記入し、最終的に承認サインを得ます。

保留や不合格項目がある場合は、改善計画と期限をベンダーと合意し、再検収のスケジュールを設定します。評価シートは電子化し、変更履歴を残すことで、後日の監査対応が容易になります。

支払判断に必要な証拠書類の整理

検収が合格したら、支払判断に必要な書類（納品確認書、権利譲渡証明書、検収評価シート、SLA 合意書）を一式揃えて経理部門へ提出します。未解決課題が残っている場合は、支払額を減額する根拠として課題一覧を添付します。支払条件（検収完了後○日以内支払）に従い、支払指示書を発行します。

支払後も保守契約が継続する場合は、保守開始日の確認と合わせて契約書類を再度チェックします。さらに、支払完了後にベンダーからの受領証を取得し、監査証跡として保存しておくと、将来のトラブル防止につながります。

検収後のフォローアップ計画

検収完了後も、システムの定期的なレビューと改善が必要です。運用開始後のタイミング（例：1か月、3か月、6か月）で利用状況と障害発生状況をレビューし、必要なチューニングや追加機能の要望を整理します。フォローアップの結果は次回の保守更新や追加開発の見積もり材料となります。

定期的なレビューは社内担当者が主導し、ベンダーとのコミュニケーション窓口を明確にしておくことで、長期的な運用リスクを低減できます。必要に応じて、レビュー結果を元に改善計画書を作成し、経営層へ報告する体制を整えておくと、投資効果の可視化がしやすくなります。