生成AIの契約は更新すべきか。利用数と業務成果から見直す

生成AIの契約更新は、ログイン回数や未使用席の数だけでは決められません。利用中でも、同じ用途の契約が重複していたり、出力確認の負担が成果に見合わなかったりすれば、現状維持を見直す余地があります。利用頻度が低い契約も、代替しにくい業務や事業継続に関わる依存があれば、移行条件が整うまで残す判断が必要です。

判断の中心に置くのは、契約単位で「利用状況」「担当業務と重複用途」「成果物の確認作業」「停止時の代替方法・依存関係」を横並びにした更新レビューです。結論は、更新・縮小・統合・停止・条件付き継続の五つから選びます。どれに分けるかは、利用数に業務上の条件を重ねて説明できるかで決まります。

生成AIの契約更新を利用数だけで決めない

契約一覧には、製品名や契約部門だけでなく、その契約が担う業務を記します。2026年9月21日時点で、NISTのAI RMF Playbook「Govern」は、AIシステム台帳を組織内のAI資産を全体として把握するためのデータベースと説明しています。導入済みモデル数や影響を受ける利用者数などの問いに答えられるようにし、通常は全モデルまたは全システムを対象にするという考え方です。

この公式資料が示すのは、組織としてAI資産を把握する一般原則です。契約更新のための席別評価や、以下の五分類を定めたものではありません。そこで実務上は、この原則を契約台帳へ置き換え、部門契約と個別契約を同じ範囲に集めます。把握から漏れた契約があれば、重複も停止時の影響も比較できません。

台帳の最小項目は、次のようにします。

• 契約名・管理部門・利用者
• 担当する業務と成果物
• 未使用席または利用実態を確認できない席
• 同じ用途を担う別のツールや人の手順
• 出力を確認する担当者と確認内容
• 停止時に影響する業務、データ、上下流の手順
• 代替方法と移行責任者

一つの契約について「誰の、どの業務で、何を生み、その後に誰が確かめるのか」を追える状態が、台帳の完成条件です。追えない契約は、更新理由も停止理由もまだ説明できません。

更新レビューの判断表

次の表は、NISTの一般原則を基に、契約更新向けに整理した実務上の提案です。NISTが定めた分類や義務ではありません。各契約を一行にし、席数の集計と業務上の評価を分離せずに記入します。

空欄は推測で埋めず、未確定の判断材料として扱います。たとえば未使用席が見つかっても、その席に紐づく定例業務や引き継ぎ前の依存を確認できなければ、「条件付き継続」に置きます。そのうえで、縮小または停止へ移すために確認する項目、責任者、再判定の条件を明記します。利用中の席も、担当業務、重複、確認作業のいずれかを説明できない間は、更新条件がそろっていません。

判断表は、次の順序で埋めると会議での論点が混ざりません。

1. 契約と席を洗い出し、利用記録を確認した時点と根拠をそろえる
2. 席ごとの担当業務と成果物を置き、同じ目的を担う契約や既存手順を対応させる
3. 成果物の確認担当・確認内容と、停止時の依存関係・代替方法を書く
4. 空欄を残したまま五つの判断へ仮置きし、空欄の責任者と再判定条件を決める

この順序なら、利用記録がない状態と、利用はあるが成果や確認方法を説明できない状態を分けて扱えます。

未使用席と重複用途を同じ行で見る

未使用席は削減候補を見つける入口です。まず利用者名と席が担う業務を対応させます。担当業務が見つからない席は縮小候補です。業務がある席は、その業務を担える別契約や既存手順も並べ、更新判断へ進みます。

重複して見える契約でも、担当する成果物や人による監督が異なる場合があります。製品が違っていても、同じ担当者が同じ種類の成果物を作り、同じ確認をしているなら、統合候補として比較できます。ここでいう「重複」は、自社業務で担う役割が重なっている状態を指します。製品の機能一覧だけで判定すると、必要な監督の違いを見落とします。

2026年9月21日時点のNISTのAI RMF Playbook「Manage」は、AIが特定の業務課題に必ずしも適切な解決策とは限らないとし、負のリスクと便益を比較して、意図した目的と目標を達成しているか判断する考え方を示しています。また、性能と信頼性は運用開始後に変化し得るため、運用後も継続的に追跡するよう提案しています。

この一般原則から、記事として提案する実務上の方法は、未使用席、業務目的、代替するツールや手順、運用後に確認できる便益とリスクを同じ行で点検することです。これはNIST所定の契約評価方法ではありません。利用の有無を目的の達成と結び付けるための社内レビュー方法です。

導入直後で利用実態の記録がまだ整っていない場合は、契約更新だけを独立したイベントにしない方が整理しやすくなります。AI導入は何から始めるべきか｜中小企業の最初の90日で対象業務、利用記録、継続条件を先にそろえ、その記録を更新レビューへ引き継ぎます。

確認工数は生成時間と分ける

生成AIが成果物の下書きを出した時点で、業務が終わるとは限りません。情報源や引用を確認し、社内基準に照らして修正する作業が残る用途では、その確認も契約が生む業務の一部です。生成する工程だけを見て継続を決めると、担当者に残る負担を判断表から落としてしまいます。

NISTが2024年7月26日に公開した生成AIプロファイル（NIST AI 600-1）は、生成AIの作話リスクへの対応として、導入前のリスク測定と継続的な監視の中で、出力に含まれる情報源と引用をレビューし、検証するよう提案しています。また、生成AIシステムを台帳へ列挙し、既知の問題、人による監督の役割と責任、基盤モデルとその版、アクセス方法などを台帳項目として検討するよう示しています（2026年9月21日確認）。

したがって、更新レビューには、確認担当、確認する内容、確認後に成果物を使える条件を書きます。これは出典の一般原則を基に記事が提案する方法であり、原典所定の分類や義務ではありません。確認条件を定められない用途は条件付き継続とし、責任分担が整うまで生成物を未確認のまま業務へ流さない運用にします。社内で承認ツールや入力情報の線引きも曖昧なら、生成AIの社内ルール・利用ガイドラインの作り方【テンプレート付き】と併せて、利用前と出力後の判断をつなげます。

停止候補ほど代替方法を先に決める

停止は、契約画面で更新を外せば完了するとは限りません。判断表で停止候補になった契約は、影響を受ける利用者、上下流の依存関係、保持が必要な対象、代替手順、移行責任者を確認してから終了条件を決めます。

前掲のNIST「Govern」と生成AIプロファイルは、AIシステムの停止について、利用者への影響、上下流の依存関係、事業継続、データ保持、必要に応じた代替システムへの移行などを考慮した方針と手順を設けるよう提案しています（2026年9月21日時点）。公式資料が特定契約の解約手順を定めているわけではありませんが、停止を場当たり的に扱わないための根拠になります。

実務上は、停止の行に次の条件を残します。

• どの業務を止めるか、または別の方法へ移すか
• 何がその契約に依存しているか
• 保持対象を誰が確認するか
• 代替手順を誰が引き受けるか
• どの状態をもって停止可能とするか

この整理は、NISTの一般原則を契約終了へ適用した記事独自の提案であり、原典所定の義務ではありません。代替方法が存在するだけでは停止条件を満たしません。移行後も業務目的を満たせることと、監督や確認の責任が途切れないことまで確かめて、初めて「停止」を選べます。

更新会議で契約と次回の条件を決める

更新会議では、五つの判断と、判断表に残った未確定箇所を扱います。契約管理者は利用状況、業務責任者は目的と成果物、確認担当は確認条件、移行責任者は代替方法と依存関係を確認します。担当者の兼務は可能ですが、誰の確認を経て結論を出したかは記録に残します。

結論が更新なら、次回も見る目的と監視項目を残します。縮小なら、残す席と業務を対応させます。統合なら、移行先と責任者を決めます。停止なら、依存関係と保持対象を処理してから終了します。材料が足りなければ、曖昧なまま更新へ流さず、再判定条件を伴う条件付き継続にします。

生成AIの契約更新では、「何席使われたか」に、業務目的、重複用途、成果物の確認、停止後の代替という四つの条件を重ねます。一行で説明できる契約は、更新・縮小・統合・停止の条件を比較できます。説明できない契約は、利用数にかかわらず、条件付き継続として責任者と再判定条件を置き、空欄を解消します。この判断表が、契約を惰性で残すことと、依存業務を不用意に止めることの両方を避ける更新レビューになります。