AIモデル世代交代で腐る5つの社内資産と点検の型

結論から言うと、AIモデルが新しくなるたび、社内のマニュアル・コスト試算・プロンプト・研修教材・権限設計の5つが、エラーも警告も出さないまま静かに古くなっていきます。動いているように見えるからこそ、誰も点検しないまま数か月〜1年が過ぎ、あるとき「なぜかAPIが呼べない」「見積もりが実際の請求と合わない」という形で表面化します。

この記事の要点

• 危険なのは「動かなくなること」より「エラーにならず動き続けるのに前提だけがズレていくこと」
• 社内で古くなりやすいのはマニュアル・コスト試算・プロンプト・研修教材・権限設計の5資産
• 点検は「四半期の定例」と「新モデル発表・廃止通知のタイミング」の二段構えで回すと運用が破綻しない

対象読者: 生成AIを業務導入している企業のAI推進担当・情報システム部門・研修担当者

読了後にできること: 自社のどの資料が「静かに腐っている」可能性があるかを洗い出し、四半期ごとの点検チェックリストとして運用に落とし込めるようになります。

研修先の情報システム担当から、こんな相談を受けることがあります。「半年前に作った社内マニュアル通りにAPIを呼んだら、いきなりエラーになった」。原因を一緒に確認すると、たいていマニュアルに書かれたモデル名のまま止まっていて、そのモデルはとっくに提供終了になっていた、というオチです。

怖いのはここからで、エラーになって気づけるのはまだ良いほうです。実際に自社のメディア記事を横断監査したところ、公開済みのコード例に実在しないモデルIDが19箇所残っていました。うち1つは、存在するはずのない未来の日付が入ったモデル名でした。読者がそのままコピペすればAPIエラーになる状態を、当の書き手が気づかずに放置していたわけです。

この手の「腐り」は、コードだけの話ではありません。旧モデルの単価で組んだコスト試算、旧モデルの癖に合わせて作り込んだプロンプト、旧モデルの操作画面のまま更新されない研修教材、そして新モデルの挙動変化を前提にしていない権限設計。どれもエラーにはならず、静かに前提だけがズレていきます。

この記事では、AI導入を支援する立場から見えてきた「モデル世代交代で腐る5つの社内資産」と、それを事故になる前に見つけるための点検の型を、コピペで使えるプロンプトつきで整理します。

まず試したい「5分点検」— これだけで社内の”腐り”の芽が見つかる

本格的な運用ルールを作る前に、まず5分でできる棚卸しを3つ試してみてください。どれも検索するだけで、社内資料の”腐り”がどこにあるかが見えてきます。

1. 社内の共有ドライブ・Wiki・Slackを「モデル名」で検索する
「Sonnet」「Opus」「Haiku」「GPT-4」などのモデル名で全文検索をかけ、ヒットした資料の最終更新日を確認します。1年以上前の更新日で、かつ具体的なモデル名やAPIのモデルIDが書かれている資料は、まず疑ってかかったほうがいい候補です。

2. コード例のモデルIDを公式の廃止スケジュールと突合する
社内マニュアルやREADMEに書かれたモデルID(例: claude-3-5-sonnet-20241022 のような日付付き文字列)を、提供元の公式ページに載っているActive/Deprecated/Retiredの一覧と1つずつ照合します。

3. 予算資料の単価に「作成日」が書いてあるか確認する
コスト試算のスプレッドシートを開き、単価を入れたセルの近くに「いつ時点の料金か」がメモされているかを見ます。書いていない資料は、いつの前提で作られたか誰にも分からなくなっている可能性が高いです。

AIモデル世代交代で腐る5つの社内資産

実際に企業を見ていて、モデルが切り替わるたびに”静かに”古くなっていくのは、だいたい次の5つに集約されます。

1. 社内マニュアル・手順書のモデル名・APIモデルID

もっとも実害が分かりやすい資産です。エンジニアが書いたセットアップ手順や、非エンジニア向けの「ChatGPT/Claudeの使い方」マニュアルには、たいてい具体的なモデル名やAPIのモデルIDがそのまま書かれています。

❌ 古いマニュアルに残っていた例(2026年7月時点ではRetired=呼び出し不可)
import anthropic
client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[{"role": "user", "content": "議事録を要約して"}]
)

✅ 現行モデルに書き換えた例
import anthropic
client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "議事録を要約して"}]
)

claude-3-5-sonnet-20241022 は2025年10月28日に提供終了(Retired)となったモデルIDです。マニュアルがこのまま残っていれば、真似したメンバーのコードは確実にエラーになります。

2. コスト試算・予算資料(旧モデルの単価前提)

稟議を通すために作った「月額◯円で導入できます」という試算は、その瞬間の料金表を前提にしています。値上げ・値下げ・プラン再編があっても、一度承認された試算資料はそのまま社内に残り続けます。参考までに、Claude Proは年払いなら月額17ドル(年間200ドル一括)、月払いなら月額20ドル、Maxはプランによって月額100ドルから(利用量5倍・20倍のティール制)というのが現行の料金です。この数字を前提に組んだ試算も、次の料金改定でそのまま古くなります。

3. プロンプト(旧モデルの癖に合わせて作り込んだもの)

「このモデルは前置きが長いと精度が落ちる」「箇条書きで指示すると従いやすい」といった、旧モデルの癖に最適化されたプロンプトは、業務部門でひそかに”職人技”として蓄積されていきます。モデルが切り替わると、この職人技が通用しなくなることがあります。厄介なのは、新モデルでも「それなりに動いてしまう」ケースが多いことです。出力の質が落ちていることに誰も気づかないまま、劣化したプロンプトが使われ続けます。

4. 研修教材・社内Wiki

操作画面のスクリーンショットが古い研修教材ほど、新入社員や異動者が混乱します。ボタンの位置、メニュー名、料金プランの表示が実際の画面と食い違っていると、「教材通りにやったのにできない」という問い合わせが研修担当者に集中します。プロンプトエンジニアリングの基本原則自体は変わりにくいので、そちらの教材はまだ寿命が長いほうですが、UIのスクリーンショットや具体的な操作手順は半年単位で陳腐化すると考えたほうが安全です。

5. 権限設計(新モデルで挙動が変わる前提の見直し)

もっとも見落とされがちなのがここです。旧モデルを前提に「AIには単純な下書き作成だけ任せる」という権限設計をしていた企業が、新モデルに切り替えた途端、そのモデルがツール呼び出しや複数手順の自律実行(エージェント的な動作)をこなせるようになっていた、というケースが増えています。モデルの”賢さ”だけでなく”自律性”が上がると、旧モデル前提で設計した承認フロー・アクセス権限が、想定より広い範囲を勝手に処理してしまう余地を生みます。

なぜ気づかれないのか — 「新モデル公開」と「旧モデル停止」はタイミングが違う

この”腐り”が見えにくい最大の理由は、新モデルが出た瞬間に旧モデルが止まるわけではない、という提供側の仕組みにあります。多くのAIベンダーは、モデルの状態を「Active(現役)」「Deprecated(非推奨・まだ動く)」「Retired(提供終了・呼び出し不可)」の3段階で管理しており、AnthropicはDeprecatedからRetiredまで通常60日以上の告知期間を設けています。つまり、新モデルが発表されてからしばらくは旧モデルも普通に動き続けるため、「もう古い」という感覚を持つきっかけがないまま数か月が過ぎてしまうのです。

実際、Claude Sonnet 4/Opus 4は2026年6月15日に提供終了となりましたが、告知自体はその2か月前でした。Claude の1Mコンテキスト機能の廃止のように、モデル本体ではなく特定機能だけが期限付きで廃止されるケースもあり、点検範囲は「モデル名」だけでは足りません。同じ構図はAnthropicに限った話ではなく、GPT-4.5の廃止のようにOpenAI側でも起きています。AIモデルをどう業務に組み込むかという設計の土台については、AI導入戦略ガイドで全体像を整理しています。

今日から使える5つの点検プロンプト

ここからは、5つの資産をそれぞれ点検するために、そのままコピペで使えるプロンプトを紹介します。生成AIに投げて、たたき台や確認リストを作らせる想定です。

プロンプト1: マニュアル内のモデル名・IDを棚卸しする

あなたは社内のAI運用担当です。
以下のマニュアル本文から、生成AIのモデル名・APIのモデルID(日付付き文字列を含む)を
すべて抜き出し、一覧表にしてください。

出力する列:
- 該当箇所の見出し/行番号
- 記載されているモデル名・ID
- そのモデル名が提供元の公式サイトでActive/Deprecated/Retiredのどれに該当するか(分からない場合は「要確認」と明記)

【マニュアル本文】
(ここに点検したいマニュアルを貼り付け)

不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず"仮定"と明記してください。

プロンプト2: コスト試算の前提単価をチェックする

あなたは社内のAI予算担当です。
以下のコスト試算資料を読み、単価・料金プランの前提が
「いつ時点の情報か」を明記できているかを確認してください。

確認項目:
- 単価の根拠(URL・取得日)が資料内に書かれているか
- 現在の公式料金表と数字が一致するか(分かる範囲でよい)
- 一致しない、または根拠不明な箇所を一覧化する

【コスト試算資料】
(ここに貼り付け)

数字と固有名詞は、根拠(出典・取得日)を添えてください。
仮定した点は必ず"仮定"と明記してください。

プロンプト3: プロンプトの”賞味期限”を確認する

以下は、業務で継続的に使っているプロンプトです。
このプロンプトを、現行の最新モデルに対してそのまま使った場合に
起こりうる変化を検討してください。

観点:
- 旧モデルの癖(冗長な前置きを嫌う、箇条書き指示に弱い等)を前提にした
  記述が含まれていないか
- 現行モデルでは不要、または逆効果になりうる指示がないか
- より簡潔な指示に書き換えられる箇所

【対象プロンプト】
(ここに貼り付け)

実際の出力比較は必ず人間が行い、AIの回答だけで判断を確定しないでください。

プロンプト4: 研修教材の陳腐化ポイントを洗い出す

あなたは社内研修の教材レビュー担当です。
以下の研修資料の目次・スクリーンショット説明文を読み、
現行のツール画面と食い違っている可能性が高い箇所を指摘してください。

確認したいポイント:
- 「◯◯ボタンをクリック」のような具体的なUI操作の記述
- 料金プラン・機能名の記載
- 「最新版」「2025年〇月時点」のような日付表現の有無

【研修資料の目次・本文】
(ここに貼り付け)

不足している情報があれば、最初に質問してから作業を開始してください。

プロンプト5: 権限設計を新モデルの自律性に合わせてレビューする

あなたは社内のAIガバナンス担当です。
現在の生成AI利用における権限設計(承認フロー、AIが自律的に
実行してよい操作の範囲)について、以下を整理してください。

- 現行の権限設計が前提としているモデルの能力(単純な下書き作成か、
  複数手順の自律実行=エージェント的動作まで含むか)
- 使用モデルを最新版に切り替えた場合、その前提が崩れる可能性がある箇所
- 見直しが必要な承認フロー・アクセス権限の候補

【現行の権限設計・運用ルール】
(ここに貼り付け)

仮定した点は必ず"仮定"と明記し、最終的な承認可否の判断は必ず人間が行ってください。

【要注意】よくある失敗パターンと回避策

失敗1
❌ エラーが出ていないから大丈夫だと判断する
⭕ エラーの有無ではなく「モデル名・単価・前提が今も正しいか」を定期的に確認する。動き続けていることと、正しく動いていることは別物です。

失敗2
❌ 日付付きのモデルID(例: claude-opus-4-5-20251101)と日付なしのID(例: claude-opus-5)を同じ感覚で扱う
⭕ 日付付きIDは特定時点のスナップショットに固定する用途、日付なしIDは提供元の判断で継続的に更新される名称という違いを理解した上で、用途に応じて使い分ける。

失敗3
❌ コスト試算を稟議通過後は一度も見直さない
⭕ 料金改定やモデル切替のタイミングで前提単価を洗い替える運用を、あらかじめ予算資料の更新ルールとして決めておく。

失敗4
❌ 研修教材を「作って終わり」にする
⭕ 教材のスクリーンショット・操作手順に作成日を明記し、半年に一度は現行のツール画面と突き合わせる担当を決めておく。

運用の型: 点検表と点検トリガー

5つの資産それぞれに、点検内容・頻度・担当を決めておくと運用が回りやすくなります。以下はそのまま使える点検表の型です。

ポイントは「定例」と「イベント」の二段構えにすることです。四半期定例だけだと、その間に発表された新モデルや廃止通知を見逃した資産が、最大で3か月近く古いまま放置されます。逆にイベント点検(新モデル発表・廃止通知のたびに毎回全資産を洗い直す)だけだと、通知メールを見逃した瞬間に点検自体が止まってしまいます。定例で下限を保証しつつ、イベントで即応する二段構えが現実的です。

権限設計は「新モデルの自律性」を前提に見直す

5資産の中でも権限設計は、点検を怠ったときの実害がもっとも大きくなりやすい項目です。旧モデルを前提にした承認フローは、多くの場合「AIは提案するだけ、実行は人間が行う」という設計になっています。ところが新しいモデルほどツールを呼び出したり複数の手順を自律的にこなしたりする能力が上がっているため、同じ権限設計のまま切り替えると、想定より広い範囲を人間の承認なしに処理できてしまう余地が生まれます。

これは「新しいモデルが危険」という話ではありません。モデルの能力が上がったのに、権限設計だけが旧モデルの前提のまま据え置かれていることが問題なのです。モデル切替のタイミングでは、コストやプロンプトだけでなく、承認フローとアクセス権限のセットも必ず見直し対象に含めてください。より体系的なチェック項目はAIエージェント運用ガバナンスのチェックリストにまとめています。

よくある質問

Q. 古いAPIモデルIDを使ったコードは、モデルが新しくなると必ずエラーになりますか？

いいえ。Deprecated(非推奨)の間はまだ呼び出せますが、性能や料金体系が現行モデルと異なる場合があります。Retirement(提供終了)日を過ぎると呼び出しがエラーになります。提供元は通常60日以上前に告知するため、告知メールと公式の廃止スケジュールページを定期的に確認しておくことが重要です。

Q. 日付付きモデルIDと日付なしモデルID、どちらを使うべきですか？

挙動を完全に固定したい本番用途では日付付きID、常に最新の改善を受けたい用途では日付なしIDが向いています。ただし日付なしIDでも提供元が内部的にモデルを更新することがあるため、重要な用途では出力の変化に気づける体制を作っておく必要があります。

Q. 点検はどのくらいの頻度で行えばいいですか？

目安は四半期に1回の定例点検に加えて、提供元から新モデル発表や廃止通知が来たタイミングでの臨時点検です。定例だけだと、その間に出た通知を見逃した資産が数か月古いままになるため、二段構えが安全です。

Q. 小規模な会社でも専任の点検担当を置く必要がありますか？

専任である必要はありません。ただし、マニュアル・コスト試算・プロンプト・研修教材・権限設計の5資産それぞれに、最低1人の担当を割り当てておくことは重要です。担当者が決まっていないと、モデル切替の情報が届いても誰も資料を直さないまま放置されがちです。

まとめ: 今日から始める3つのアクション

1. 今日やること: 社内の共有ドライブ・Wikiを「モデル名」で検索し、ヒットした資料の最終更新日を確認する(5分点検)
2. 今週中: 5つの資産(マニュアル・コスト試算・プロンプト・研修教材・権限設計)それぞれに点検担当を1人ずつ割り当てる
3. 今月中: 四半期定例点検の日程をカレンダーに登録し、点検表(本記事のプロンプト1〜5)を使って初回点検を実施する

あわせて読みたい

• AIエージェント運用ガバナンス完全ガイド — 権限設計・承認フローの35項目チェックリスト
• Claude 1Mコンテキスト廃止｜API移行完全ガイド — 機能単位の廃止に対応した実例

次回は、AIベンダーを選定する際に「モデルのライフサイクル管理体制」をどう確認すればよいかを、具体的な質問リストとともに掘り下げる予定です。

著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。
SoftBank IT連載7回執筆(NewsPicks最大1,125ピックス)。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

参考・出典

• Model deprecations — Anthropic公式ドキュメント(参照日: 2026-07-27)
• Claude Pricing — Anthropic公式(参照日: 2026-07-27)
• Deprecations — OpenAI公式ドキュメント(参照日: 2026-07-27)
• Commitments on Model Deprecation and Preservation — Anthropic(参照日: 2026-07-27)