契約の確認は、技術の確認とは別の作業
技術的な検証を丁寧にやった案件でも、契約条項の確認は抜けます。読む人が違い、読む時期が遅く、そして読む時間が工程に入っていないためです。
発注側が自分で作ってしまう罠も含めて扱います。多くの型は、発注側の準備で防げます。
型1 ― 要件定義書への過信
要件定義書は必要です。しかしAIを含む案件では、要件定義書が完成しても実現可能性は確定していません。実現可能性が自社データの状態に依存するためです(第6章)。
「請求書から金額を読み取り、基幹システムに登録する」という要件は明確です。しかし実際にできるかどうかは次で決まります。
- 取引先ごとの書式が何種類あるか
- 手書きの割合はどれくらいか
- 基幹システムに登録用の接続口があるか
- 登録時の必須項目が、請求書から取れる項目で埋まるか
- 承認済みの状態を判定する条件が仕様書に記載されているか
これらは要件定義の作業ではなく現物の調査です。要件定義書と並行して、実データのサンプル調査を工程に入れる必要があります。この工程を省くと、開発が進んだ段階でデータ側の制約が判明し、対象を縮めるか要求水準を下げるかの選択に追い込まれます。
型2 ― SLA・契約条項の確認を怠らせる説明
契約条項について確認を求めたときに返ってくる説明の型を並べます。
| 返ってくる説明 | 実務上の扱い |
|---|---|
| 「標準的な規約なので他社と同じです」 | 他社と同じであることは、自社に適していることを意味しない |
| 「そこは実務上問題になったことがありません」 | 問題になっていないことは、条項がないことと違う |
| 「詳細は法務部門にご確認ください」 | 正しい対応。ただし確認の期間を工程に入れる必要がある |
| 「まず始めてから条件を詰めましょう」 | データを預けた後の交渉は不利になる |
| 「規約はこちらのページに記載しています」 | 正しい対応。原文を確認する |
4行目が最も注意が必要です。データを預けた後、業務に組み込んだ後の条件交渉は、依存の段階が上がった状態で行うことになります(第10章)。契約条件の確認は着手前に済ませる必要があります。
SLAで見落とされやすい2点
表の第17章で挙げた項目のうち、実務で最も影響するものを再掲します。
- 測定の方法 ― 何を停止と数えるか。応答遅延が停止に含まれない場合、実用に耐えない遅さでも保証の対象外になります。推論モデルのように応答時間が長い処理では、この点の確認が必要です。
- 除外事由 ― 計画停止、上流事業者の障害、利用側の設定。除外が広いと保証の実効性が下がります。とくに上流事業者の障害が除外されている場合、他社モデルの再提供構成ではリスクが実質的に自社に残ります。
型3 ― 独占的な条項を忍ばせる
第10章でも扱いましたが、契約管理の観点から整理します。他の事業者のサービスを併用できない条項は、表現が穏当なため見落としやすい項目です。
確認すべき条項の性質を挙げます。
- 競合するサービスの併用を制限する条項
- 本サービスを主たる手段として使用することを求める条項
- 最低利用量の設定(実質的に他への切り替えを困難にする)
- 長期契約と引き換えの値引き
- データの独占的な利用に関する条項
これらがあると、リスク分散の設計(停止が許されない処理だけ二重化する等)が契約上できなくなります。値引きの条件として提示された場合は、分散の必要性と天秤にかけて判断します。
単価の値引きと引き換えに長期契約または最低利用量が提示された場合、次の2点を計算してください。(1) その期間に単価が下がる可能性。この領域の単価は下がる傾向にあります(表の網羅版 第9章「プロジェクトマネジメント・投資対効果」)。(2) 期間内に切り替えが必要になる可能性。モデルの世代交代、業務の変更、より適した選択肢の登場。値引き幅がこの2つのリスクを上回るかを判断します。
型4 ― 納品物と受け入れ条件が曖昧なまま進む
完了の判断ができない契約になる型です。次の4点が決まっていない発注は、検収の段階で判断ができません。
| 項目 | 決めないと起きること |
|---|---|
| 実際に作業する者(再委託の有無) | 提案者と実装者が異なり、品質と工数が想定と違う |
| 受け入れの条件 | 「正常に動作すること」では判定できない(第11・14章) |
| 納品物の範囲 | 設計資料・運用手順書・検証セットがないと以後の変更ができない |
| 稼働後の保守 | 稼働直後に追加契約の交渉が始まる |
3番目について補足します。納品物に検証セットと回帰テストの仕組みを含めておくと、稼働後の品質監視を自社で継続できます(第14章)。これがないと、モデル更新のたびにベンダーへの依頼が必要になります。
型5 ― 仕様の膨張が変更管理として処理されない
着手後に「せっかくだからこの機能も」という要望が増える現象です。AI案件で特に起きやすい理由があります。動くものを見ると、追加でできそうなことが具体的に想像できるためです。
膨張自体が問題ではありません。問題は、追加の判断基準と費用の扱いが決まっていないことです。次の2点を契約時に決めておけば、追加要望は正常な変更管理として処理できます。
- 追加要望の窓口と判断者 ― 誰が受け、誰が可否を決めるか。
- 追加時の費用と期間の扱い ― 無償の範囲、有償になる境界。
これが決まっていないと、追加は「善意の対応」または「交渉」として処理され、どちらの場合も後の関係に影響します。
朝凪精機の社内チャット「コネクトAIアシスト」の契約は、一年目の一月に常務の大槻が提供元の説明を聞いたその日に一人で決めたもので、条件を読む工程を通っていませんでした。二年目の八月のある朝、応答が極端に遅くなり、1時間ほど使いものにならない時間がありました。十一月二十七日、更新の検討で総務課の戸田主任が条文を声に出して読むと、SLAの停止は「応答が返らない状態をいう」とあり、遅くても返ってくれば停止に数えない書き方でした。業務は事実上止まっていましたが、保証の対象にはなりませんでした。次の契約からは応答時間の上限を個別に取り決めることにし、総務課の契約前確認表に「停止の数え方(応答の遅さを含むか)」の行を入れました。契約条件の確認期間を工程に入れていれば、最初の契約で手当てできた項目でした。
この場面は網羅物語之巻 第8章「乗り換えられない」に出てきます。
発注側が先に決める6項目
この章の型は、発注側の準備でほぼ防げます。所要は半日程度です。
- 実データのサンプル調査を工程に入れる ― 要件定義と並行して、現物を数十件見る。
- 受け入れ条件を件数で定義する ― 「実データ○件で修正必要が○件以下」。検証データは自社が用意する。
- 納品物に設計資料・運用手順書・検証セットを含める ― 以後の変更と品質監視を自社で継続できる。
- 追加要望の窓口・判断者・費用の扱いを決める ― 変更管理として処理できる。
- 稼働後の保守範囲と費用を発注時に見積もる ― 後からの交渉を避ける。
- 契約条件の確認期間を工程に入れる ― 法務の確認を後回しにしない(表の網羅版 第19章「法規制・コンプライアンス」)。
いずれも技術的な知識を必要としません。発注の一般的な作法をAI案件に当てはめただけです。逆に言えば、最大の罠はAIという言葉に気を取られて通常の発注管理が抜け落ちることです。