「Azureを使っているから保守されている」は、安全確認になりません。確認すべきなのは製品名ではなく、実際の呼び出し先とAPIバージョンです。
Microsoftの製品ライフサイクル一覧では、Computer Vision API 1.0、2.0、2.1、3.0、3.1のサポート終了日が2026年9月13日とされています。Azure AI Visionの更新情報にも、旧版は同日廃止され、その後はAPI呼び出しができなくなると記載されています。推奨されている移行先は一般提供版のComputer Vision API 3.2です。
ところが、公式情報には一つ注意点があります。製品ライフサイクル一覧には2.1を含む5版が載る一方、更新情報の廃止案内本文は1.0、2.0、3.0、3.1の4版を列挙し、2.1を記載していません。本稿では、終了日を管理する製品ライフサイクル一覧に従って2.1も対象として扱います。2.1を使う環境は「更新情報にないから対象外」と自己判断せず、管理画面、契約窓口、Microsoftサポートのいずれかで個別に確認してください。
経営者が決めるべきことは、新しい画像AIを比較するかどうかではありません。9月13日をまたいで止まる業務がないかを見つけ、移行後の結果が業務で受け入れられるかを誰が判定するかです。本稿では、専任のクラウド担当者がいない中堅・中小企業でも、開発会社や保守会社へ確認を依頼できる形に分解します。
結論：製品名ではなく「7列台帳」で停止範囲を確定する
最初に、次の7列を埋めてください。1行は一つの業務、または一つの呼び出し元です。
横にスクロールして確認できます
| 列 | 記録する内容 | 判定に使う問い |
|---|---|---|
| 1. 業務 | 請求書読取、本人確認、画像検品、写真分類など | 止まると売上、出荷、請求のどれに影響するか |
| 2. 呼び出し元 | 業務システム、スマートフォンアプリ、定期処理、連携基盤 | 修正と再配布を担当する会社はどこか |
| 3. 接続先 | Azureの接続先名とリージョン | 本番、検証、災害対策環境を網羅したか |
| 4. APIバージョン | 1.0、2.0、2.1、3.0、3.1、3.2など | 9月13日終了対象か |
| 5. 認証方式 | キー、マネージドID、保管場所、更新担当 | 移行時に認証情報の変更が必要か |
| 6. 代替先 | 原則3.2、または業務要件に合う別方式 | 同じ入力と出力を保てるか |
| 7. 責任者 | 業務判定、技術変更、承認、障害連絡の担当 | 誰が「移行完了」と判断するか |
この表の価値は、古いバージョンの件数を数えることだけではありません。「請求書OCRは経理部が結果を判定する」「スマートフォンアプリは配布審査がある」「外部ベンダーの共通部品なので他社案件にも影響する」という、停止時間と変更責任の違いを同じ場所に置けることです。
9月13日までに全件を改修できない場合も、表があれば順序を決められます。売上計上や出荷を止めるものを最優先にし、代替入力がある業務は手作業へ切り替え、利用されていない検証環境は停止します。表がないまま「Azureはベンダーに任せている」と回答する状態が、最も判断しにくい状態です。
SECURITY OPERATION
日常の脆弱性運用、情シス1人で回せる体制にしませんか？
月次棚卸・重大度判定・パッチ適用代行まで含む「セキュリティ運用伴走」プラン。単発対応からの卒業で、止まらない運用体制を作ります。
終了対象と公式情報の読み方
2026年9月12日時点の確認結果を整理すると、次のとおりです。
横にスクロールして確認できます
| APIバージョン | 製品ライフサイクル一覧 | 更新情報の廃止案内本文 | 本稿の扱い |
|---|---|---|---|
| 1.0 | 9月13日終了 | 9月13日終了と記載 | 移行対象 |
| 2.0 | 9月13日終了 | 9月13日終了と記載 | 移行対象 |
| 2.1 | 9月13日終了 | 列挙なし | 移行対象として個別確認 |
| 3.0 | 9月13日終了 | 9月13日終了と記載 | 移行対象 |
| 3.1 | 9月13日終了 | 9月13日終了と記載 | 移行対象 |
| 3.2 | 終了対象として掲載なし | 一般提供版の移行先として案内 | 第一候補。ただし業務テストが必要 |
ここで二つの判断ミスを避けます。
一つ目は、「サポート終了だから問い合わせができなくなるだけ」と読むことです。Azure AI Visionの更新情報は、終了後に対象APIを呼び出せなくなる旨を案内しています。保守の相談窓口がなくなるだけではなく、業務機能が動かなくなる前提で計画すべきです。
二つ目は、「最新版へ番号を変えれば移行完了」と考えることです。画像解析やOCRでは、同じ画像でも文字の区切り、座標、信頼度、言語判定、応答形式が変われば、後続処理の結果も変わります。接続できたことと、業務で正しい結果が得られたことは別の合格条件です。
また、古い更新情報にはプレビュー版への移行を案内する記述が残る場合があります。今回の基準は、2026年9月12日時点の廃止案内が推奨する一般提供版3.2です。検索で見つけた古い記事や画面だけを根拠に、プレビュー版を新しい本番基盤として選ばないでください。
自社が旧版を使っているか調べる順番
「使っているか分からない」場合は、コードを最初から全て読む必要はありません。次の順で範囲を狭めると、経営側でも進捗を管理できます。
1. 業務名から候補を出す
請求書、領収書、申込書、免許証、製品画像、現場写真、監視カメラ画像など、画像を入力して文字や分類結果を返している業務を並べます。名称に「AI」や「Azure」がなくても対象です。たとえば「帳票取込」「画像品質判定」「写真検索」という社内名で使われている場合があります。
2. Azure資産と請求明細を突き合わせる
Azure上のComputer Visionまたは関連する認知サービスの資産を一覧にし、サブスクリプション、リソースグループ、リージョン、月額費用を記録します。費用がゼロに近くても、災害対策用や月末だけ動く処理かもしれません。直近一週間の利用だけで不要と判断せず、少なくとも月次・四半期・年次の業務周期を確認します。
3. 呼び出し記録と設定値を見る
アクセス記録、アプリケーション設定、環境変数、構成ファイル、API管理基盤の経路から、接続先とバージョン指定を探します。ソースコード以外に、ノーコード連携、定期処理、外部ベンダーの共通基盤から呼ばれている場合もあります。開発会社には「コード内を検索したか」だけでなく、「実行時の通信記録で確認したか」を聞いてください。
4. 本番以外も同じ表へ入れる
検証環境、災害対策環境、旧スマートフォンアプリ、停止中のバッチ処理も対象です。本番だけを3.2へ変えて検証環境を旧版のまま残すと、次の改修で古い設定が本番へ戻る可能性があります。環境ごとに別行として記録し、残す、移行する、削除するを決めます。
5. 契約と保守責任を確認する
自社のAzure契約でも、実際のAPI呼び出しは委託先の契約配下という構成があります。その場合、管理画面を見ても対象が出ないことがあります。契約書、構成図、見積書から、クラウド利用料の請求主体と改修責任を確認します。「当社環境では見つからなかった」という回答だけで終了しないことが重要です。
EOL資産の見つけ方をAPI以外にも広げる場合は、Windows Server 2016の終了期限から逆算する棚卸しと、廃止指示が出た製品を利用停止まで管理する考え方が参考になります。定期更新の担当と証跡を保守契約へ入れる方法は、月例パッチを契約条件に変える実務で整理しています。
移行前チェック7項目
旧版を見つけた後は、次の7項目を一件ずつ確認します。接続試験だけで完了扱いにしないための受入条件です。
1. 入力条件
本番で扱う画像の形式、最大容量、解像度、向き、言語、枚数を確認します。きれいな試験画像だけで合格にすると、斜めの領収書、薄い複写伝票、暗い現場写真で失敗します。直近の実データから、正常、低品質、手書き、複数ページ、個人情報を含むものを匿名化して試験集合を作ります。
2. 出力の互換性
項目名、データ型、座標、並び順、信頼度、エラー形式を比較します。後続システムが「文字列の位置」を使って欄を判定しているなら、文字そのものが合っても座標の変化で誤登録が起きます。旧版と3.2の結果を同じ表へ出し、差分を分類してください。
3. 業務精度
技術者が見る正解率だけでなく、業務上の誤りを測ります。請求金額、口座番号、製品番号の誤読は、住所の一文字違いより損失が大きい場合があります。重要項目ごとに許容する誤り率を決め、人手確認へ回す条件も定義します。
4. 処理速度と同時実行
一件の応答時間だけではなく、月末の集中処理や開店直後の同時利用で測ります。再試行が増えると、呼び出し回数と料金も増えます。平常時、繁忙時、障害時の三条件で、待ち時間と失敗率を記録します。
5. 料金と上限
新しい版の単価、無料枠、回数の数え方、リージョン差、再試行分を見積もります。旧版の月額をそのまま新しい予算に置かないでください。月間画像数に繁忙係数と再試行率を加え、通常月と最大月の二つの金額を稟議へ載せます。
6. エラー処理と監視
呼び出し不能、時間切れ、回数制限、認証失敗、形式不正を区別し、どの部署へ通知するかを決めます。9月13日以降に旧版が呼べなくなった場合、利用者の画面に「処理中」とだけ出続ける設計では発見が遅れます。エラー率、処理件数ゼロ、待ち行列の滞留を監視対象にします。
7. 切替と切戻し
切替時刻、作業者、承認者、停止可能時間、旧版へ戻さず業務を継続する代替手段を決めます。終了後は旧版への切戻しが成立しない可能性があるため、「問題があれば元へ戻す」だけでは計画になりません。手入力、処理保留、別経路への振替のどれで業務をつなぐかを用意します。
開発会社・保守会社へそのまま送れる確認文
次の文面は、技術用語を詳しく知らなくても使えます。
Microsoftの製品ライフサイクル一覧で、Azure Computer Vision API 1.0、2.0、2.1、3.0、3.1が2026年9月13日に終了すると確認しました。当社業務について、①利用の有無、②業務名、③呼び出し元、④本番・検証を含む接続先、⑤APIバージョン、⑥9月13日以降の影響、⑦3.2等への移行状況、⑧実データによる精度・速度・料金・エラー処理の受入結果、⑨未完了の場合の代替手順を、証跡付きで回答してください。「Azure利用あり／なし」ではなく、実行時の通信または設定値で確認した結果をお願いします。
回答が「最新版です」だけなら、版番号と確認証跡を追加で求めます。「影響ありません」なら、対象業務をどう網羅したかを聞きます。「自動更新されます」なら、APIの呼び出し形式と後続処理の互換性試験が済んでいるかを聞きます。口頭の安心材料ではなく、7列台帳と受入結果が納品物です。
経営者が避けたい5つの失敗
失敗1：請求書にAzureとあるので問題ないと判断する。 Azureはサービス群の名称で、個々のAPIには別のライフサイクルがあります。請求先のブランド名では利用版を判定できません。
失敗2：ベンダーから連絡がないので対象外だと思う。 通知先が退職者のメールアドレス、販売店、開発当時の担当者になっている可能性があります。連絡の有無と技術的な利用有無を分けて確認します。
失敗3：URLの版番号だけを置き換える。 接続に成功しても、応答形式や認識結果の差で後続業務が壊れることがあります。実データと重要項目で業務判定を行います。
失敗4：本番だけを直す。 検証環境や古いアプリに旧設定が残ると、次の配布や障害復旧で設定が戻ります。全環境を台帳に入れ、廃止まで完了条件にします。
失敗5：緊急だから言い値で改修を発注する。 期限が近くても、対象件数、変更範囲、試験範囲、切替手順、未完了時の代替策を分ければ見積を比較できます。見積もりセカンドオピニオンで、緊急対応と恒久刷新を混ぜない確認も可能です。
9月13日までに間に合わない場合の優先順位
全件の移行が間に合わない場合、隠して「対応中」とするのではなく、影響を経営判断へ上げます。
横にスクロールして確認できます
| 優先 | 条件 | 取る行動 |
|---|---|---|
| 最優先 | 売上、出荷、請求、安全確認が止まり、代替手段がない | 責任者を固定し、緊急移行と業務継続手順を同時に実施 |
| 高 | 個人情報や重要データを扱い、結果の誤りが顧客影響になる | 実データ試験と人手確認を必須にして切替 |
| 中 | 手入力や翌日処理で代替できる | 利用者へ切替手順を周知し、移行日を確定 |
| 低 | 未使用の検証・旧環境 | 接続を止め、認証情報を失効し、資産台帳から廃止 |
「間に合わない」と分かった時点で必要なのは、責任追及よりも、業務停止時間と代替策の承認です。終了日を越えた後も、失敗した呼び出しを繰り返す処理が料金や負荷を増やさないか確認し、利用者へ見えるエラーに変えます。
今回だけで終わらせず、外部APIのEOL管理へ広げる
Computer Visionだけを直しても、同じ会社が別の決済、地図、生成AI、認証、配送の旧APIを使っていれば、次の終了日で同じ問題が起きます。7列台帳へ「終了日」「最終確認日」「次回確認日」を加え、四半期に一度見直す運用へ変えてください。
保守契約には、終了情報の監視担当、通知期限、影響調査の納品形式、改修見積を出す期限、受入試験、緊急時の代替手順を明記します。「脆弱性対応を含む」「最新版へ追随する」だけでは、API終了が契約範囲か判断できません。契約更新時に具体化することが大切です。
月次会議で追う4つの数値
台帳を作った後は、件数を追わなければ再び古くなります。経営会議や情報システムの月次報告では、外部API総数、終了日が12か月以内の件数、移行計画が未承認の件数、受入試験が未完了の件数を並べます。総数だけが増え、終了日不明の項目が残る場合は、新しい連携を開始する際の登録手順が抜けています。
改修の進捗は「着手率」ではなく、業務責任者が受け入れた割合で見ます。接続変更済みでも、精度試験や切替手順が未承認なら未完了です。逆に、利用実績がなく廃止承認と認証情報の失効まで済んだものは、移行せず完了にできます。この区別により、技術者の作業量ではなく、停止リスクがどれだけ減ったかを経営者が把握できます。
終了日不明の資産をゼロ件と報告させるのではなく、不明件数として残すことも大切です。不明を隠さず減らす運用のほうが、根拠のない全件対応済みより経営判断に使えます。
外部APIの追加時には、7列台帳の登録を本番公開の条件にします。終了日が未公表なら「未公表」と最終確認日を入れ、確認担当を空欄にしません。買収や事業譲受でシステムが増えたときも、契約書と構成図だけでなく、この台帳の引き渡しをITデューデリジェンスの条件へ加えます。
GXOのレガシー刷新・移行準備度診断では、古いAPI、基幹システム、OS、外部連携を同じ資産台帳に置き、停止影響と移行順を整理します。既に停止期限が迫っている場合はレガシーEOL緊急相談、刷新全体の方式選定はレガシーシステム刷新支援が対象です。製品を売る前に、どの業務をいつ、どの受入条件で移すかを第三者の立場で整理します。
FAQ
Q. OCRも対象ですか。
A. 「OCRを使っている」という業務名だけでは判定できません。Computer Visionの旧APIを呼んでいれば対象になり得ます。別のDocument Intelligenceなどを使っている場合は製品ライフサイクルが別です。接続先とバージョンを実行時の記録または設定で確認してください。
Q. 2.1は終了対象ですか。
A. Microsoftの製品ライフサイクル一覧は2.1を含めて2026年9月13日終了としています。一方、Azure AI Visionの更新情報にある廃止案内本文は2.1を列挙していません。本稿はライフサイクル一覧に基づき対象として扱い、利用者には個別確認を勧めています。
Q. 9月13日以降はどうなりますか。
A. Azure AI Visionの更新情報は、対象となる旧APIを呼び出せなくなる旨を案内しています。実際の画面表示や後続処理の挙動は自社システムのエラー設計次第です。事前に遮断試験を行い、利用者に何が表示されるかまで確認してください。
Q. 3.2へ変えれば終わりですか。
A. 接続先の変更だけでは終わりません。入力条件、出力互換性、業務精度、速度、料金、エラー処理、切替の7項目を受け入れて完了です。業務部門の責任者が重要項目の結果を承認する必要があります。
Q. どこまでを緊急改修に含めるべきですか。
A. まず業務継続に必要な接続変更、互換対応、監視、代替手順までです。画面全面改修や基盤統合は、期限後の恒久対応として見積を分けます。緊急性を理由に全刷新を一括発注すると、比較と検収が難しくなります。
この記事の確認範囲
本稿は2026年9月12日に、Microsoftの製品ライフサイクル一覧とAzure AI Visionの更新情報を再確認して作成しました。終了日、対象版、終了後に呼び出せなくなる旨、3.2への移行推奨は公式記載に基づきます。2.1の表記差は両ページを比較して明示しています。個別契約、リージョン、利用機能、料金、移行後の精度は企業ごとに異なるため、本稿だけで適用可否を断定しません。公開後も終了日の延長、対象版、推奨先に変更がないかを確認します。
