GitHub Spark が廃止へ — 新規停止、2026-08-31 までにリポジトリへエクスポートを

要約

github.com 上の GitHub Spark の廃止が予告されました。2026-08-04 以降、新規ユーザーの受け入れと新規アプリの作成が停止され、既存ユーザーがアプリをリポジトリとしてエクスポートできるのは 2026-08-31 までです。告知から期限まで 4 週間弱しかありません。

Spark は自然言語からミニアプリを生成してそのままデプロイできるサービスでした。GitHub は廃止理由を、AI モデルとエージェント開発ツールの進化により、Spark が担っていた「短時間でアイデアを形にする」用途が VS Code と Copilot CLI 側の開発体験に統合されたためと説明しています。つまり機能が消えるのではなく、置き場所が変わったという整理です。

ただし移行にあたって、見落とすと詰まる点があります。デプロイ済みのアプリは廃止後も動作を続けますが、llm() 関数を使っているアプリは既に動きません。Spark の llm() は GitHub Models を裏側で使っており、その GitHub Models 自体が 2026-07-30 に廃止済みだからです。AI 機能を持つアプリを移行するなら、OpenAI などの別プロバイダーへ切り替え、API キーの管理と課金を自分で持つ構成に作り直す必要があります。エクスポートしてリポジトリになった時点で完了、とはいきません。

同日、Copilot Billing Preview アプリの廃止も告知されています。

何が変わったか

• 2026-08-04 以降、github.com 上の GitHub Spark で新規ユーザーの受け入れと新規アプリの作成を停止
• 既存ユーザーは 2026-08-31 まで、作成済みアプリをリポジトリとしてエクスポート可能
• デプロイ済みアプリは廃止後も動作を継続する
• ただし llm() 関数を使うアプリは、GitHub Models の廃止（2026-07-30）により既に動作しない
• AI 機能を維持するには OpenAI 等の別プロバイダーへの切り替えが必要（API キー管理と課金は利用者側の負担になる）
• 廃止理由は、Spark の用途が VS Code / Copilot CLI の開発体験へ統合されたため
• 同日、Copilot Billing Preview アプリの廃止も告知

業務インパクト（一般企業向け）

最初にやることは棚卸しです。社内の誰が Spark で何を作っているかを 8月31日までに把握する必要があります。Spark のような「非エンジニアでも作れる」ツールは、情シスの管理外で使われている典型例です。部門の担当者が業務改善のつもりで作った小さなアプリが、いつのまにか日常業務に組み込まれている、という状況は珍しくありません。棚卸しなしに期限を迎えると、エクスポートすらできないまま資産が失われます。

次に、動くアプリと動かないアプリの切り分けです。デプロイ済みなら動き続けるという説明は、AI 機能を使っていないアプリに限った話です。llm() を使っているものは既に停止しているはずで、「Spark 廃止で止まる」のではなく「7月末に GitHub Models が消えた時点で止まっていた」ことになります。もし社内で「最近あのツールが動かない」という報告が上がっていたなら、原因はこれかもしれません。

移行先の判断には、コスト構造の変化が伴います。Spark では GitHub 側がモデルアクセスをまとめて提供していましたが、移行後は自社で API キーを持ち、従量課金を負担することになります。金額としては小さいことが多いものの、「誰の予算で、誰がキーを管理するか」という話は必ず発生します。部門で作られたアプリを情シスが引き取るのか、部門が予算を持つのか、あるいは移行せず廃止するのか——この判断を 8月31日より前に始める必要があります。

より本質的な論点は、プラットフォーム提供のモデルアクセスに依存するリスクです。今回は GitHub Models の廃止と Spark の廃止が1か月強の間に連鎖しました。「ツールに付属しているから無料で AI が使える」という構成は、その付属部分が消えた瞬間にアプリごと止まります。今後の内製ツール選定では、モデルアクセスを自社のキーで抽象化しておく設計を標準にしておくと、同種の連鎖に巻き込まれにくくなります。

副業・個人活用視点

Spark でクライアント向けにプロトタイプを作っていた場合、8月31日は自分の期限ではなくクライアントの期限です。納品済みの案件があるなら、こちらから連絡してエクスポートを促すか、代行を提案する。これは単なる善意ではなく、移行作業そのものが仕事になります。「無料で使えていたものが有料の作り直しになる」という話は、自分から切り出すと売り込みに見えますが、公式の廃止告知という外部要因があれば正当な連絡です。

移行案件として見ると、内容は分かりやすい構成です。エクスポートしたリポジトリを受け取り、llm() を OpenAI などの API 呼び出しに置き換え、キー管理とデプロイ先を用意する。規模は小さく、期限が明確で、クライアント側も必要性を理解しやすい。小口の案件を複数まとめて受けるのに向いています。

自分の学習・実験用に Spark を使っていたなら、エクスポートだけは期限内に済ませておくのが無難です。移行するかどうかは後で決めればよく、リポジトリさえ手元にあれば選択肢が残ります。8月31日を過ぎるとコードそのものが取り出せなくなります。

そして教訓として残しておく価値があるのは、AI ベンダーの機能は数か月単位で消えうるという事実です。Spark は「アイデアを短時間で形にする」というポジションで登場し、その用途ごと VS Code / Copilot CLI に吸収されました。ツール選定の際、単体で完結するサービスより、既存のワークフローに統合されていく方向のものを選ぶ——という判断軸は、今回の件がそのまま裏づけになります。