「動く」ではなく「運用できる」を受け取る
従来のシステム検収は「仕様書どおりに動くか」を確認すれば成立しました。しかしAIアプリはそれだけでは足りません。回答の精度は入力データや利用状況で揺れ、運用の中で継続的に評価・調整していく前提の成果物だからです。だからこそ検収のゴールを、ベンダーがデモを完走することではなく、自社が引き取った後にそのシステムを運用し続けられる状態にあることに置き換える必要があります。
受け取る対象は2つあると考えると分かりやすくなります。ひとつは動くシステムそのもの。もうひとつは、そのシステムを監視し、直し、必要なら止められる自社の運用能力です。後者を受け取り損ねた検収は、その場では合格に見えても、最初の障害が起きた瞬間に「誰も対処できない」という形で失敗が表面化します。
検収を「動作確認の儀式」で済ませた案件は、半年後にブラックボックスに育つ。外注の成果物は、システムではなく、システムと、それを運用できる自社である。
AIアプリの検収 ― 3つの確認
従来の検収(仕様書どおり動くか)に、AIならではの2つの確認を加えて判定します。この3点がそろって初めて「運用できる状態を受け取った」と言えます。
1. 機能の検収
従来どおり仕様との一致を確認しますが、判定材料を変えます。「あらかじめ用意したデモシナリオで動く」ことではなく、実データ・実利用者によるパイロットの結果で確認します。整えられた見本ではなく、現場の入力で期待どおりに振る舞うかを見るということです。
2. 評価基準の検収
契約段階(シリーズ第3弾)で合意した評価セットと合格基準を使い、発注側の環境で、発注側が立ち会って実行し、記録します。ベンダーが自己申告してきた精度の数字をそのまま検収に使ってはいけません。答えるべきでない質問に答えないか、権限を越えて情報を出さないかといった安全性の基準も、ここに含めて確認します。
3. 運用可能性の検収
引き取り物が一式そろい、自社の運用担当が一連の運用操作 ― 監視ダッシュボードの確認、プロンプトの修正、評価の再実行、停止・切り戻し ― をベンダーの手を借りずに一度自分で実行できることを確かめます。これは「運用できる」ことの実地試験です。ベンダーがデモする検収は、ベンダーの習熟を確認しているだけで、自社の運用可能性を何も証明しません。
ブラックボックスを受け取らない ― 引き取りとナレッジ移転
引き取りで最も避けたいのは「ものは受け取ったが、環境も理解も伴っていない」状態です。判定は「ある」ではなく、「使える」で行います。RFP段階(第2弾)で予告しておいた引き取り物を、次の観点で受領確認します。
| 引き取り物 | 受け取ってはいけない状態 | 受入基準(「使える」で判定) |
|---|---|---|
| ソース・IaC | zipで一式渡される | 自社リポジトリに履歴ごと移管され、手順書どおりにデプロイを再現できた |
| プロンプト一式 | 最終版のテキストのみ | 版履歴・設計意図のコメント・変更手順が運用手順書と紐づく |
| 評価データ・スクリプト | 結果のExcelのみ | 自社環境で再実行でき、回帰テストとしての手順が文書化済み |
| 設計ドキュメント | 構成図1枚 | 設計判断の記録(背景・比較・採らなかった案)が主要判断ぶん残っている |
| 運用手順書 | 画面操作の羅列 | 「よくある障害と初動」「停止・切り戻し手順」を含み、検収の実技で実際に使えた |
| アカウント・権限 | ベンダー個人アカウントが残存 | 全アカウントを突合し自社管理へ移管。残置は保守契約の範囲のみ |
さらに、監視・アラートが自社の見える場所で動いているか、シークレットやAPIキーが自社管理に移っているか、ベンダー側のデータ複製が契約どおり削除されているかといった環境の状態と、運用担当が「このシステムは何を・どこまでやるか」を自分の言葉で説明できるかを口頭で確認します。説明できないシステムは、事故のとき誰も止められません。
そして忘れてはならないのが、ドキュメントを受け取ることと運用できることの間には距離がある、という事実です。この距離を埋めるのがナレッジ移転で、これは「引き継ぎ会」という1回のイベントではなく、期間と活動で設計するプログラムです。納品後1〜3ヶ月のペア運用期間を設け、日常運用と最初の改善サイクルをベンダーと自社担当がペアで回します。このとき手を動かすのは自社側、ベンダーは隣で支える配分にすることが肝心です。逆にすると移転は起きません。
受け手は「学ぶ担当」 ― 保守はレイヤーで分ける
移転の受け手は、契約段階(第3弾)から全期間に同席してきた運用担当、すなわち「学ぶ担当」です。最終盤に初めて登場する引き継ぎ要員では間に合いません。学ぶ担当が全期間を通じて設計判断や評価の意図を見てきたからこそ、最後の移転が仕上げとして機能します。
納品後の体制は「全部内製」か「全部保守」の二択ではありません。次のようにレイヤーで分けて持ち方を決めます。日常運用を自社が持つことが、すべての学習の起点になります。
- 日常運用(監視確認・利用者対応・文書更新)… 自社が持つ。ここを外注すると運用感覚が育たない。
- 定期改善(評価の定期実行・プロンプト調整・小規模改修)… 自社主導＋ベンダー相談(時間契約など)。
- 大規模変更(モデル移行・機能追加)… 都度見積り。引き取り物がそろっていれば相見積りも内製も選べる(ロックイン回避)。
- 緊急対応(重大インシデント支援)… SLA・連絡体制を保守契約で定義。
保守契約には、自走が進んだら保守範囲を縮小できる柔軟性の条項を入れておくと、能力が育つほど無駄な固定費が減っていきます。
内製化への接続 ― 卒業判定と成熟度
ペア運用の締めくくりが卒業判定です。合格ラインは正解手順の完全再現ではなく、「切り分けの筋が良く、止める・戻すの判断を自力でできる」ことです。例えば模擬インシデントとして「回答が古いという報告が数件、エラーはなし」というシナリオを与え、出典ログから参照文書を特定し、旧版の混入か再インデックス漏れかを切り分け、検索から除外して回帰確認まで、手順書だけを頼りに一定時間内で到達できるかを見ます。コスト異常のシナリオなら、ベンダーに電話する前に自分で「止める」判断ができるかが問われます。不合格ならペア期間を延長しますが、延長条件を契約時(第3弾)に合意しておけば揉めません。
こうした賢い発注を重ねると、組織は外注から学び、段階的に成熟していきます。要件もデータも評価も任せて動作確認で検収する「丸投げ」(Lv0)から、RFP・評価合意・引き取りが型として回る「賢い発注」(Lv1)へ。さらに発注側が評価・運用を主体的に担う「協働」(Lv2)を経て、案件ごとに内製・外注・SaaSを目利きして選べる「選べる組織」(Lv3)に至ります。ここまで来ると外注は依存ではなく、必要なときに使える加速手段になります。
受入基準や卒業条件は、検収当日に初めて出すものではありません。RFP(第2弾)と契約(第3弾)であらかじめ予告しておくこと ― これがシリーズ全体を貫く「出口まで決めて始める」という発注の型です。そう設計された発注は、ベンダーにとっても、使われ続ける納品物と次も指名される信頼が残る最良の仕事になります。