出せる履歴は直近30日分だけ。SaaS・AI APIの終了通知が届いたら

たとえば、問い合わせ返信の下書きに使うAPIから、次の終了通知が届いたとします。

終了通知N01（想定例）：2026年9月15日に、AI Aの「返信下書きAPI v1」の終了通知を受領。APIは11月30日17:00に停止し、履歴・設定の出力は12月15日17:00まで可能。旧契約は自動解約されないものとします。日時はすべて日本標準時（JST）です。実在サービスの告知ではありません。

先に拾うのは、APIが止まる11月30日17時、出力できる12月15日17時、そして別途必要な旧契約の解約です。停止後も出力できるからといって、契約や請求まで自動で終わるわけではありません。

さらに、このサービスから出せる履歴は直近30日分だけ、という想定です。11月まで待てば、9月に使った履歴を取り出せなくなるおそれがあります。通知を受けた9月15日に初回出力を試し、必要な履歴を消える前に継続して保存するところから始めます。保存してよい範囲と閲覧者も決めます。

止まるサービスと、使っている業務を対応付ける

外部依存とは、自社システムが動くために外部サービスやAPIを使っていることです。APIは、システム同士が機能やデータをやり取りする窓口を指します。認証、決済、メール、AI、ファイル保存は同じシステムで併用します。それぞれの役割を分けて確認してください。

依存先は会社名だけでなく、サービス・機能・APIの版と、使っている業務を一組にします。契約名義、管理者、通知を受け取る人も記録してください。開発会社名義で契約していれば、社内担当者が通知やデータ出力の権限を持つかを、その会社へ確認します。

表1　外部依存台帳の入口（想定例）

依存先と用途	管理する役割・止まる影響	まず調べること
認証B／社員ログイン	情報システム担当／ログイン不可	利用者ID・権限・再認証の手順
決済C／注文の支払い	経理・開発担当／入金処理に影響	取引ID・返金・重複処理の防止
メールD／受付通知	運用担当／通知が届かない	送信設定・失敗時の再送
AI A／問い合わせ返信の下書き	契約：総務、管理：開発担当／下書き停止	API v1の期限・設定・回答品質
保存E／問い合わせ添付	情報システム担当／添付を参照できない	実ファイル・関連ID・閲覧権限

台帳には次節以降の期限、持ち出せる内容、代替機能、併用・切り戻し・解約まで追記します。不明な欄は「問題なし」にせず、問い合わせ相手と回答期限を残します。パスワードやAPIキーそのものは書かず、保管場所と更新担当を記します。

保守会社の変更やソース・管理権限の引き継ぎが主な課題なら、他社開発システムの保守引き継ぎで調べることで、調べる範囲を整理できます。

停止・出力・解約には、それぞれ期限がある

「終了」という見出しだけで判断せず、通知本文と契約条件を読みます。通知の種類ごとに問い合わせ先を分けます。複数が同時に変わる場合は、それぞれの期限を台帳へ記録してください。

表2　通知の種類と読む条件

通知の種類	読む対象・期限
サポート終了	問い合わせ・修正・更新のどこが終わるか。稼働停止とは別に読む
機能・API・モデルの廃止	対象機能、API版・モデルID、呼び出せなくなる日時
価格変更	新料金の適用日、課金単位、更新・解約の申出期限
仕様変更	入出力・認証・制限値の変更点と、互換性を試せる期間
サービス・契約終了	利用停止、出力・閲覧の期限、削除、請求停止の条件

通知の受領日と原文、対象組織・プラン・地域、日時のタイムゾーンも残します。終了日と出力期限が同じとは決めつけず、記載がなければ提供元へ照会します。返答待ちでも、先に許可された範囲で出力を試し、作業に必要な時間を調べます。

OpenAIの追加学習基盤の終了案内（2026年9月17日確認）

OpenAIのModel optimizationは、同社の追加学習基盤の段階終了を案内しています。Deprecationsでは、2026年5月7日から未利用組織の学習を制限し、7月2日から過去60日間に学習済みモデルで推論していない組織の新規ジョブ作成も停止。利用を継続している既存顧客の新規ジョブ作成は2027年1月6日に終了予定です。一方、学習済みモデルによる推論の停止は、基盤モデルの廃止に連動するとしています。

対象はOpenAIの追加学習基盤です。自社で使うモデルIDと、組織の利用状況に応じた適用条件を読んでください。

受け取ったファイルを、移行先で使えるか

エクスポートは「ファイルを受け取れた」段階です。移行できるかは、必要な範囲が含まれ、移行先で使える形に戻せるかまで確かめて判断します。業務データに加え、添付の実体、操作・承認履歴、設定、権限対応、ソースコード、外部部品のライセンスを対象にします。

例えば、CSVに添付のURLだけが載る場合は、契約終了後も実ファイルを開けるかを試します。旧ユーザーIDと新ユーザーIDの対応、日付や文字コード、親子関係も試します。AIでは、学習データ、プロンプト、評価用データ、モデルの重みを別の資産として扱い、一つの出力で全部が得られるとは見込みません。

AISIのAIガバナンス実務マニュアル（Version 1.00）（PDF）は、終了・重大な条件変更時に返還するモデル・データ・設定・ログの範囲と、移行支援の期間・費用・範囲を合意する例を示しています。以下はその考え方も踏まえた作業例です。持ち出せる範囲は提供元へ確認します。

AI Aの出力範囲・期限・残る疑問の記入見本

表3　AI Aの外部依存台帳・詳細記入例（想定例）

項目	記入済み見本
依存先と用途	返信下書きAPI v1。総務が契約、開発担当が管理。人が確認してから送信
終了期限	API：2026/11/30 17:00。出力：12/15 17:00。いずれもJST
持ち出せる内容	直近30日分の履歴CSV、設定JSON、添付の個別出力を想定。重みは出力不可
代替で試す機能	下書きの妥当性、必須項目、添付参照、応答時間、再試行、費用
併用・切り戻し・解約	11/16切替、11/27までに戻す判断。旧側の出力を開けたら、12/7に解約手続き予定
記録日・版	想定上の記録日：2026/9/15。通知N01・API v1
根拠URL・証跡	URLなし（架空通知N01）。実運用では通知原文・契約条項・出力結果を保存
残る疑問	30日を超える履歴の取得条件・新環境での再利用条件は不明。代替品質は試験で測る

この例では、APIを替えるだけでなく、手元の設定と許可されたデータから下書き機能を作り直す案を試します。長期履歴の取得が不明なら、提供元に範囲・費用・日数を確認し、必要な履歴を自社側から補えるかも調べます。取得できない履歴が業務上必須なら、この移行案のまま進めません。

ファイルを持っていることと、変更・再利用できる権利も別に調べます。IPAの情報システム・モデル取引・契約書（第二版）は、契約不適合、報酬、成果報酬型準委任、協力義務、再構築などを別論点で整理しています。個別の権利帰属をこの案内だけでは決められません。契約本文と現行法に照らす判断は、法務担当や専門家へ確認してください。

注文と添付を、別の保存先で一緒に開く

持ち出したCSVやJSONに注文書のファイル名が残っていても、ファイル本体が出力されていなければ、移行先で注文書は開けません。復元の再現教材では、注文1件・4,000円が一致する状態でも、添付の欠落と、同じ名前の別内容を分けて検出しています。

終了前の試行では、本文と添付を同じ番号へ対応させ、移行先の担当者の権限で開きます。旧サービスへログインしたままの端末で旧URLを開けただけでは、移行先で使える確認になりません。APIや契約を止める前に、旧サービスに頼らず原文を読めるかを確かめてください。

過去の権限・履歴を持ち出せない場合は、何が欠け、どの業務判断に影響するかを先に書きます。「出力成功」と「移行先での利用可能」を別の完了条件にすると、追加で取得するものが明確になります。

同じ仕事で乗り換え先を試す

最初は合成データ、または移行先での利用が許可された小さなデータで試します。実データを別の提供元へ送る前に、再利用条件、保存期間、学習利用の有無、保存地域、送信先のアクセス管理を確認します。不明な条件は、実データを送る前に確認します。

返信下書きAPIの移行では、通常20件、例外10件、長文5件、情報不足5件の計40件を用意する計画です。同じ40件を旧系と候補先へ入力し、設定・モデル版・実行日時を残します。「重大な誤案内と必須項目の欠落は0件」を確認目標にし、人による確認は継続します。

OpenAIのModel optimizationは、評価で基準を作り、指示や学習データを調整し、実際の入力を代表するデータで評価する流れを示しています。同じ入力を使って回答を比較し、モデル名やAPIの呼び出し形式だけで品質を判断しません。

下書きの内容だけでなく、必須項目を含む応答形式、添付の参照、認証、同時処理、制限超過時の再試行を試します。応答時間は同じ入力条件で記録し、費用は同じ件数・期間・通貨・税の扱いで、再試行分、移行作業、データ出力、新旧併用も含めて比べます。小規模試行の合格後に、必要な量と業務時間内に移行できるかをリハーサルします。

文章が自然でも、必須の添付参照を再現できなければ、元の業務の代替にはなりません。逆に、添付を扱わない下書き用途へ範囲を絞り、人が原本を見られるなら、暫定採用を検討できます。仕様は候補先の公式資料・窓口、品質と時間は自社の試行記録、許容範囲は業務責任者から得ます。

停止日から逆算して、移行と解約を進める

冒頭の通知では、11月30日の停止日を「旧側に戻れなくなる上限」として扱い、それまでに切替と試験を終える計画にします。下表は停止日から逆算した計画例です。日数は暦日で、標準工期ではありません。担当者の稼働日、出力量、承認に必要な時間で調整してください。

表4　API終了通知から逆算する移行チェック例（想定例）

日時の指定がある行はすべてJSTです。新旧併用は比較と試験のために行い、同じ問い合わせへの二重送信や決済の二重実行はさせません。切替後に増えた入力・処理結果の保管先と、旧側へ戻すときの反映方法を決めます。戻した後の照合まで含め、停止日に間に合うかを確認します。

旧側が動く期間には旧環境へ戻す選択肢がありますが、停止後は同じ方法を使えません。猶予が短い場合や代替品質が足りない場合は、下書き機能を止めて人が対応する、対象業務を絞る、受付を制限するなど、暫定運用を業務責任者が決めます。手作業の処理量・担当時間も確認し、継続が無理なら利用者へ停止範囲を案内します。

解約は切替と同時に済ませず、必要なデータと設定が保管先で開けること、保管権限と保存期間、旧側に残るデータの削除条件をそろえて進めます。旧キー、連携アカウント、通知先を整理し、解約受理、終了日、残額や最終請求の証跡を残します。

差分の照合や戻す条件の詳細は、システム移行の切り戻し｜新しい注文と訂正の扱いを参照してください。通知の受信担当と台帳の更新担当も決め、次の契約更新や提供元の変更通知で見直せる状態にしておきます。

見本と空欄版を収録した外部依存台帳・移行チェックExcelで、自社の利用先と調べることを整理できます。

乗り換え先へ運用を渡すために、コード・データ・外部サービスの権利を別々に説明しています（システム開発で受け取る権利・コード・データ）。

業務システムの月額保守・運用改善

参考出典

• IPA「情報システム・モデル取引・契約書（第二版）」
• OpenAI「Model optimization」
• OpenAI「Deprecations」
• AISI「Chief AI Officer 設置・AIガバナンス実務マニュアル Version 1.00」（PDF）