OpenAI Atlasは8月9日に動作停止｜AIツールは「どれを入れるか」より「消えたらどうするか」——採用稟議に組み込むExit条件の設計

最初に結論を書く。OpenAIはAIブラウザ「Atlas」の廃止を公式に発表し、2026年8月9日にAtlasは動作を停止する。2025年10月21日にmacOS向けに提供が始まってから、わずか9ヶ月余りでの終了である。同じ公式リリースノート（2026年7月9日付）では、ChatGPTのグループチャット機能についても7月9日以降は新規作成・招待リンクからの参加ができなくなることが告知された。7月30日にはGitHub Modelsの全面終了も控えている。この夏だけで、大手AI企業の提供機能が立て続けに「消える」わけだ。

ここから引き出すべき教訓は「Atlasを入れなくてよかった」ではない。AIツールは従来のSaaSよりライフサイクルが構造的に短く、どのツールを選んでも「突然の終了」は前提条件であるということだ。だから本記事は、Atlasの移行手順の紹介ではなく、AIツールを業務に組み込むすべての会社に向けた「消滅リスク管理」の設計方法を扱う。具体的には、直近1年の終了実例の整理、採用時に確認すべきExit条件チェックリスト5項目、稟議書に「消えたらどうするか」欄を設ける提案、そして現場が勝手に導入したツールの棚卸し手順である。読み終えたときに、「うちの会社で今AIツールが1つ消えたら、どの業務が何日止まるか」に答えられる状態を目指す。

この記事を読むべき人

• 現場主導でChatGPT・Copilot・各種AI SaaSが増殖しており、全社で何を使っているか正確に答えられない経営者・役員
• 兼任情シスとして「AIツールの管理もよろしく」と言われたが、何から手を付けるべきか決めかねている担当者
• 特定のAIツールを前提にした業務フロー・マニュアル・研修を作り込みつつある部門責任者
• AIツール導入の稟議・決裁を回す立場で、「選定理由」は書かせているが「終了時の想定」は書かせていない管理部門
• Atlasは使っていないが、「うちが使っているあのツールも同じことになるのでは」と感じた人

逆に、Atlasからのブックマーク移行手順そのものを探している人には、この記事は遠回りだ。OpenAIの公式ヘルプ（文末に掲載）を直接参照してほしい。

何が起きたのか——公式発表の事実関係

まず事実を一次ソースで確定させておく。OpenAIの公式ヘルプセンター記事「Evolving Atlas into ChatGPT for browser-based agentic work」およびChatGPTリリースノート（2026年7月9日付）によると、内容は次のとおりだ。

• OpenAIはAtlasを廃止（deprecate）し、ブラウザ上のエージェント機能をChatGPT本体とCodexに統合する。
• Atlasは2026年8月9日に動作を停止する予定。それ以降、Atlasは起動・ブラウジング・エージェント処理をサポートしなくなる可能性があると明記されている。
• Atlasのブラウザデータ（ブックマーク・開いているタブ・閲覧履歴）は自動では引き継がれない。ブックマークはHTMLファイルとしてエクスポートしてChromeなどへ手動で取り込む必要があり、Cookieとパスワードは新しいChatGPTデスクトップアプリへのエクスポートが案内されている。
• ChatGPTの会話履歴はAtlasのブラウザデータとは別管理で、引き続きChatGPT側で利用できる。
• 後継としては、複数タブ・ダウンロード・ログイン対応などを備えたChatGPTデスクトップアプリと、Chrome向けのChatGPT拡張機能・サイドバーが案内されている。

同じ日付のリリースノートには、グループチャットの段階的終了も並んでいる。2026年7月9日以降、Web・iOS・Androidで新しいグループチャットの作成、既存会話のグループチャット化、招待リンクからの参加ができなくなる。既存のグループチャットは当面利用できるが、読み取り専用化が予告されており、その時点では過去のメッセージ・ファイル・画像の閲覧のみが残る。

注意してほしいのは、これが「OpenAIの経営が傾いた」という話ではまったくないことだ。むしろ逆で、学んだことをChatGPT本体に統合するという前向きな整理である。急成長している大手ベンダーでも、個別プロダクトは1年未満で消える。これがAI時代のツール調達の前提条件だ。

直近1年でこれだけ消えた——終了・廃止の実例表

Atlasは特殊事例ではない。OpenAIの公式リリースノートとGitHubの公式発表から確認できるものだけでも、この1年で次の機能・サービス・モデルが終了している。

実例を時系列で眺めたとき、経営判断に効く示唆は3つに集約される。

第一に、頻度が高い。四半期に一度どころか、ほぼ毎月どこかで何かが終わっている。ここに挙げたのはOpenAIとGitHubの2社だけであり、他のAIベンダーやスタートアップまで含めれば実例はさらに増える。

第二に、猶予が短い。従来の業務システムやSaaSであれば、大きな機能の終了には比較的長い移行期間が取られることが多かった（大手クラウドでは1年程度前の廃止告知を運用ポリシーとする例もある）。この表の猶予は最短で即日、多くが2週間〜1ヶ月である。「告知が出てから対応を考える」やり方では、検討している間に期限が来る。

第三に、終了の形が多様である。サービスまるごとの停止（Atlas、GitHub Models）だけでなく、モデルの世代交代（GPT-4o、GPT-4.5）、機能単位の廃止（グループチャット、旧deep research）がある。契約上は「サービス継続中」でも、自社が依存していた特定モデル・特定機能だけが消えることは普通に起きる。「ベンダーが潰れなければ大丈夫」という感覚は、この点で既にずれている。

なぜAIツールは従来SaaSより短命なのか——3つの構造要因

「たまたまOpenAIの整理が続いただけでは」と思うかもしれない。そうではなく、AIツールの短命さには構造的な理由がある。採用判断の前提として、3つに整理しておく。

第一に、モデルの世代交代がプロダクトの土台ごと入れ替える。 通常のSaaSは、会計や勤怠といった業務ロジックが土台にあり、土台は何年も安定している。AIツールの土台は基盤モデルそのものであり、その基盤が半年〜1年周期で世代交代する。新世代モデルが出るたびに、旧モデル前提のプロダクトは維持コストだけが残る負債になる。今回の表でモデル引退が繰り返されているのはこの構造の現れで、モデルに紐づいた周辺ツールは、モデルと一緒に寿命を迎える。

第二に、機能はより大きなプラットフォームに吸収される。 Atlasの廃止理由をOpenAI自身が「ブラウザエージェント機能をChatGPTとCodexへ統合するため」と説明していることが象徴的だ。AI業界では、単機能ツールとして始まったものが成功すると、汎用アシスタントの一機能として吸収される。議事録AI、翻訳AI、検索AI、ブラウザAI——単体プロダクトとして買ったものが、1年後には大手アシスタントの標準機能になっているというのは、利用者にとって便利になる話であると同時に、単体ツールの契約・業務フロー・連携がまとめて宙に浮く話でもある。

第三に、撤退・ピボットの判断が速い。 AI市場は投資も競争も過熱しており、ベンダーは「勝てない領域からの撤退」を従来のソフトウェア企業よりはるかに速く決める。資金調達したスタートアップだけの話ではない。今回見たとおり、OpenAIやGitHub（Microsoft傘下）のような体力のある企業ほど、選択と集中の判断は速い。継続性の担保を「企業の規模」に求めるのは、AI領域では機能しない。

まとめると、従来SaaSの寿命を決めていたのは主に「そのベンダーの事業継続性」だったが、AIツールの寿命は「モデル世代・プラットフォーム戦略・競争環境」という自社もベンダー担当者すら制御できない変数で決まる。だから、個別ツールの目利きをどれだけ磨いても消滅リスクはゼロにならず、「消えても困らない設計」を自社側で持つしかない。

依存には段階がある——「どこまで依存してよいか」の上限を決める

消滅リスクへの対処は「AIツールを使わない」ではない。それは競争力の放棄である。正しい問いは「どの深さまで依存してよいか」だ。依存には段階があり、深くなるほど、消えたときの被害が「不便」から「業務停止」に変わる。

• レベル1：個人の作業補助。 社員が下書き・要約・調べ物に使っている。消えても個人の生産性が一時的に下がるだけで、業務は止まらない。
• レベル2：チームの業務フローに組み込み。 「問い合わせの一次回答はこのAIで作る」「議事録はこのツールで自動生成して共有する」など、手順書・マニュアル・研修がそのツール前提で書かれている。消えると、そのフローが回らなくなり、代替手順の再構築と再教育が必要になる。
• レベル3：システム・データに組み込み。 APIで社内システムと連携している、そのツールの中に業務データ（プロンプト資産、ナレッジ、顧客とのやり取り、設定）が蓄積されている。消えると、開発を伴う移行が必要になり、データを取り出せなければ資産そのものを失う。

実務的な判断基準はこうだ。レベル1は自由にやらせてよい。レベル2からは登録制にし、Exit条件（次章）の確認を必須にする。レベル3は、後述の稟議とデータ・API設計の検証なしには進ませない。 グループチャット終了の例で言えば、個人の雑談用途ならレベル1だが、「顧客対応チームの共有チャットとして運用していた」ならレベル2であり、7月9日の告知は業務フローの再設計案件になる。同じ機能でも、使い方によって管理すべき深さが変わる——だから「ツール名の許可リスト」だけでは管理にならず、「用途と依存度」で見る必要がある。

なお、レベル3のAPI連携やAIエージェント構築では、特定ベンダーのAPIを業務ロジックに直書きせず、切り替え可能な抽象化層を挟んで実装するのが定石だ。この設計判断は後から直すと高くつくため、AIエージェント開発の設計段階で織り込んでおくことを強く勧める。抽象化層がなければ移行負担が跳ね上がることは、GitHub Modelsの終了対応が示したとおりだ。

AIツール採用時のExit条件チェックリスト

ここからが本記事の中核だ。AIツールを業務（レベル2以上）に採用する前に、次の5項目を確認する。ポイントは、これを「導入後の保険」ではなく採用可否の判定条件として使うことである。5項目のうち確認できないものが2つ以上あるなら、そのツールへの依存はレベル1に留めるのが安全だ。

• 1. データを取り出す手段が現時点で存在するか。 プロンプト資産・生成物・会話履歴・設定・学習させたナレッジを、汎用形式（CSV、JSON、HTML、Markdown等）でエクスポートできるか。「いざとなれば取り出せるはず」ではなく、導入前に一度実際にエクスポートして中身を開いてみる。Atlasの例では、ブックマークはHTMLで出せるが開いているタブや履歴は自動では移らない。何が出せて何が出せないかは、やってみないと分からない。
• 2. 代替ツールの当たりが付いているか。 「このツールが消えたら、第二候補はどれか」を採用時点で1〜2個名指しできるか。代替が存在しない唯一無二のツールは、便利さの裏で依存度上限を厳しくすべき対象だ。逆に代替が複数ある領域なら、深めに使っても復旧の道はある。
• 3. 業務フロー依存度の上限を決めたか。 このツールを前提にしてよい業務範囲を明文化したか。「この業務の一次ドラフト作成には使うが、この業務の最終判断・顧客送信には組み込まない」「手動での代替手順を手順書に併記する」など、消えた瞬間に手作業で回せるラインを残しているか。
• 4. 終了時の通知条件を確認したか。 利用規約・契約書に、サービス終了時の事前通知期間とデータ返却・取り出し期間の定めがあるか。多くのAIツールの規約は「いつでも変更・終了できる」に近い書きぶりであり、それ自体は止められないが、通知期間の定めがない前提でこちらの監視体制（公式のリリースノート・changelogを誰が定期的に見るか）を決めておく必要がある。今回のAtlasも、把握の起点は公式リリースノートだった。
• 5. 移行工数を見積もったか。 実際に終了告知が出た場合、データ移行・代替選定・フロー書き換え・再教育に何人日かかるかを概算したか。精緻でなくてよい。「半日で済む」のか「2人月かかる」のかの桁が分かっていれば、猶予1ヶ月の告知が出たときに慌てずに済む。桁が大きすぎるなら、それは採用前に依存度を下げる設計変更のサインである。

この5項目は、ベンダー選定の比較表に並ぶ「機能」「価格」「精度」と同格の評価軸として扱ってほしい。機能比較は「使えるか」を測るが、Exit条件は「やめられるか」を測る。AI時代の調達では、やめられないツールは良いツールではない。

稟議書に「消えたらどうするか」欄を設ける

チェックリストを組織に定着させる最も簡単な方法は、承認プロセスに埋め込むことだ。具体的には、AIツール導入の稟議書・申請書に次の欄を追加することを提案したい。名称は何でもよいが、趣旨は「このツールが12ヶ月以内に終了告知を出した場合の対応を、導入前に書かせる」である。

記入させる内容は3行で足りる。

1. データの逃がし先：何をどの形式でエクスポートし、どこに保管するか（例：プロンプト集は月次でMarkdown出力し社内Wikiへ）。
2. 代替の当たり：第二候補ツール名、または「手動運用に戻す」と明記。
3. 移行工数の桁：終了告知から移行完了までの概算（例：約3人日／約1人月）。

この欄の効用は、記載内容そのものより書けるかどうかの判定にある。起案者がこの3行を書けないなら、そのツールの理解が「便利そう」の段階を出ていないということであり、依存度を上げるべきではない。書けるなら、終了告知が実際に出た日に、稟議書がそのまま初動対応のメモになる。数年放置される事業継続計画書より、承認フローに埋まった3行のほうが実効性は高い。

もう1つ、運用面の提案を加えたい。採用したAIツールには「見直し期限」を付けることだ。AIツールの1年は従来ソフトの数年に相当する。導入から12ヶ月経ったら、ツールの継続・乗り換え・依存度変更を再判定する——この定期見直しをカレンダーに入れておくだけで、「気づいたら誰も使っていないのに課金が続いている」「気づいたら想定以上に深く依存している」の両方を防げる。

現場が勝手に導入したツールの棚卸し手順

ここまでは「これから採用するツール」の話だった。しかし多くの会社にとって、より切実なのは既に現場に散らばっているAIツールである。生成AIは個人のブラウザとクレジットカードで使い始められるため、シャドーIT化のスピードが従来の比ではない。経営者や情シスが把握していないツールは、終了告知が出ても誰も気づかず、止まった日に初めて発覚する。以下の手順で棚卸しすることを勧める。

手順1：責めない申告期間を設ける（1週間）。 最初にやるべきは検閲ではなく申告の呼びかけだ。「業務で使っているAIツール・AI機能をすべて教えてほしい。申告しても咎めない。目的は禁止ではなく、突然消えたときに会社として守るためだ」と明確に伝える。ここで「勝手に使って」と責める空気を出すと申告が止まり、棚卸しは失敗する。Atlasやグループチャットの終了は、この呼びかけの格好の説明材料になる。

手順2：申告漏れを機械的に補足する。 申告と並行して、経費精算・法人カード明細からAI系サブスクリプションの支払いを拾う、SSO・Google Workspace・Microsoft 365の「サードパーティアプリ連携」一覧を確認する、可能であればネットワークログやブラウザ拡張の一覧から主要AIサービスへのアクセスを確認する。個人課金・無料利用はここでも漏れるので、申告と機械的検出の両輪が必要だ。

手順3：台帳に4つの軸で記録する。 集まったツールを一覧化する。最低限の軸は、①ツール名と提供元、②利用部署と用途、③依存レベル（前述の1〜3）、④そのツールの中にあるデータ（顧客情報・機密情報の有無を含む）。この時点で、個人情報や取引先情報が無管理のAIツールに入っているケースが見つかることが多い。それは消滅リスク以前のセキュリティ・コンプライアンス案件として先に処置する。

手順4：レベル2以上に前章のExit条件を遡及適用する。 全ツールに一律の管理を掛けようとすると破綻する。依存レベル1は台帳記載のみで自由利用を継続、レベル2以上に絞ってExit条件5項目を確認し、欠けている項目（特にデータエクスポートの実地確認）を埋める。ここで「代替がない・データも出せない・でも業務の中核に入っている」ツールが見つかったら、それが自社の最優先リスクである。

手順5：入口のルールを1枚にして再発を防ぐ。 棚卸しは一度やって終わりではなく、入口を管理しないと半年で元に戻る。「レベル1は自由・レベル2から申請・レベル3は稟議」という簡単な区分と、稟議の「消えたらどうするか」欄をセットで全社に示す。ルールが複雑だと現場は再びルール外で使い始めるため、A4一枚に収まる粒度に留めるのがコツだ。

この棚卸しは、AIツールに限らず自社のIT資産管理・DX推進体制の成熟度をそのまま映し出す。ツール台帳が存在しない、責任者が決まっていない、といったより根本的な課題が見えた場合は、DX成熟度診断で全体の優先順位から整理し直すことを勧める。また、棚卸しの結果「どのツールを残し、どれを乗り換え、どこを内製・開発に切り替えるべきか」の判断が社内で付かない場合、その選定と依存度設計を第三者の立場で検証するのがAIアセスメントの役割である。ベンダーの営業資料ではなく、発注側の立場でExit条件込みの評価を行う。

FAQ——よくある疑問への回答

Q1. OpenAIやMicrosoftのような大手製を選んでおけば安心ではないのか。

安心ではない。本記事の実例表が示すとおり、Atlas・グループチャット・GitHub Models・各世代モデルの終了は、いずれも業界最大手による判断だ。大手であることは「会社が突然消えるリスク」を下げるが、「プロダクトや機能が統合・整理で消えるリスク」はむしろ大手のほうが高いとさえ言える。プロダクトポートフォリオが広く、選択と集中が頻繁だからだ。ベンダーの規模はExit条件の代わりにならない。規模で選んでよいのは、データエクスポートや移行支援の整備水準——つまり「消え方の行儀の良さ」までである。

Q2. 無料ツールしか使っていなければリスクはないか。

支払いがないことと依存がないことは別問題だ。無料ツールでも、業務フローがそれ前提で組まれていれば（依存レベル2）、消えた日に業務は乱れる。むしろ無料ツールは契約関係がないぶん、通知なしの仕様変更・終了が起きやすく、経費明細にも現れないため棚卸しから漏れやすい。管理の要否は金額ではなく依存レベルで判定してほしい。

Q3. 終了告知が出てから対応を考えるのでは駄目なのか。

猶予が十分ならそれでも回るが、実例表のとおり、直近の猶予は即日〜1ヶ月が中心だ。告知から対応を設計し始めると、検討・承認・移行作業のどこかで期限を超える。事前にExit条件を確認してある場合、告知日にやることは「稟議書の3行を実行する」だけになる。準備の有無は、対応の質ではなく対応が間に合うかどうかを分ける。

Q4. それほど消えるなら、AIツールの業務利用自体を待つべきではないか。

待つのは最も高くつく選択だ。競合が学習を積む間、自社だけ立ち止まることになる。本記事の主張は「使うな」ではなく「消えても困らない形で深く使え」である。依存レベルの上限を決め、データの逃がし先を確保し、代替の当たりを付けておけば、ツールの消滅は「数日の乗り換え作業」に縮む。リスクを理由に止まるのではなく、リスクを設計してから踏み込むのが正しい。

Q5. 内製すれば消滅リスクはなくなるか。

移らないだけで、形を変えて残る。内製アプリも基盤モデルのAPIに依存しており、モデルの廃止・世代交代の影響は受ける（GPT系モデルの引退はまさにこれだ）。内製の利点は、依存箇所を自社のコードとして把握でき、抽象化層で切り替え可能にできる点にある。つまり内製は「リスクをなくす」のではなく「リスクを管理可能な場所に移す」手段であり、その設計を怠った内製は、市販ツール依存より始末が悪い。

GXOに相談すべきサイン

次のいずれかに当てはまるなら、棚卸しか採用ガバナンスの整備を、外部の目を入れて一度やり切るタイミングだ。

• 全社で使っているAIツールの一覧を、誰も即答できない
• 特定のAIツール前提の業務フロー・マニュアルが既にあり、そのツールが止まった場合の代替手順がない
• AIツールの中に顧客情報・機密情報が入っているかどうかを確認したことがない
• 導入稟議はあるが、終了時の想定・データエクスポート・移行工数を書かせる欄がない
• GitHub ModelsやAtlasのような終了告知が出るたびに、「うちは関係あるのか」の確認に数日かかっている
• ベンダー提案を受けているが、Exit条件込みで評価できる人が社内にいない

GXOは、AI導入の可否・ツール選定・依存度設計を発注側の立場で検証するAIアセスメントを提供している。売りたいツールを持たない第三者として、「導入すべきか」だけでなく「どこまで依存してよいか」「消えたらどうするか」まで含めて評価するのが特徴だ。棚卸しの進め方の相談、既存ツール構成のセカンドオピニオン、Exit条件を織り込んだ開発設計まで、お問い合わせフォームから気軽に相談してほしい。8月9日にAtlasが止まる前に、自社の台帳を一度確かめておく価値はある。

参考ソース

• OpenAI ヘルプセンター「Evolving Atlas into ChatGPT for browser-based agentic work」 https://help.openai.com/en/articles/20001371-evolving-atlas-into-chatgpt-for-browser-based-agentic-work （2026年7月18日確認）
• OpenAI ヘルプセンター「ChatGPT — Release Notes」（2026年7月9日付エントリ：Retiring Atlas／Retiring group chats、ほか各モデルの引退告知） https://help.openai.com/en/articles/6825453-chatgpt-release-notes （2026年7月18日確認）
• OpenAI「Introducing ChatGPT Atlas」（2025年10月21日発表） https://openai.com/index/introducing-chatgpt-atlas/
• GitHub Changelog「GitHub Models is being fully retired on July 30, 2026」（2026年7月1日発表） https://github.blog/changelog/2026-07-01-github-models-is-being-fully-retired-on-july-30-2026/

本記事の日付・終了範囲は各社の公表時点のものです。終了スケジュールや移行手段は変更される可能性があるため、対応の実行前に必ず各社の公式情報を再確認してください。依存レベルの区分・Exit条件チェックリスト・稟議欄の設計はGXO独自の判断フレームであり、各社の公式見解ではありません。