GitHub Sparkは2026年8月4日に新規利用者の受け入れと新規アプリ作成を終了しました。すでにSparkで作ったアプリを持つ企業担当者にとって重要なのは、8月31日までにコード退避を済ませること、GitHub Modelsの終了でllm()依存がすでに止まっていないか確認すること、そして今後の開発先をCopilot中心の運用に切り替えることです。
GitHubの公式Changelogによると、既存のデプロイ済みアプリ自体はSpark終了後も動き続けます。ただし編集を続けたい場合はSpark workbenchの「...」から「Create repository」を実行し、GitHubリポジトリへ移しておく必要があります。加えて、Sparkのllm()関数が依存していたGitHub Modelsは2026年7月30日に正式終了しているため、AI機能を残したいアプリは別の推論基盤へ置き換える前提で見直す必要があります。
GitHub Spark終了で最初に押さえるべき結論
結論を先にまとめると、確認事項は3つです。1つ目は8月31日までのコード退避、2つ目はllm()利用有無の棚卸し、3つ目はSpark後の保守体制の再設計です。Sparkは「新しく作れないが、過去資産は残る」という中途半端な状態に見えますが、実際には編集経路とAI機能の一部が失われるため、放置コストの方が高くなりやすい段階に入っています。
特に社内PoCでSparkを使っていたケースでは、担当者が「公開済みだから大丈夫」と誤解しやすい点に注意が必要です。公開済みアプリが動いていても、次の改修依頼が来た瞬間にコードの所在、権限、代替推論先、予算管理をまとめて確認することになります。今のうちにリポジトリ化しておく方が、後から緊急対応するより圧倒的に楽です。
どの利用者が影響を受けるのか
影響が大きいのは、Copilot Enterprise配下でSparkを試験導入していた企業、Copilot Pro+で業務アプリの試作を作っていた個人、そしてデモ用に一般公開したSparkアプリをそのまま営業資料や社内説明に使っているチームです。公式Docsでは、SparkはCopilot Pro+またはCopilot Enterpriseの機能として案内されており、Enterpriseでは既定で無効、管理者がAI Controlsから有効化する設計でした。つまり、企業利用では個人開発よりも権限整理が残りやすい構造です。
もう1つの分岐点は、アプリがAI推論を使っているかどうかです。GitHub Sparkの概要ページでは、AI機能はGitHub Modelsと統合され、自然言語プロンプトからアプリを作り、必要に応じて推論コンポーネントを追加できると説明されていました。しかしChangelogでは、GitHub Modelsの終了によりllm()呼び出しは2026年7月30日以降は動かないと明記されています。AIなしの業務フォームや簡易データ管理アプリなら延命しやすい一方、要約・分類・生成を入れたアプリは追加対応が必須です。
8月31日までにやるべき退避手順
GitHub公式が案内している最低限の手順は明快です。Spark workbenchで対象アプリを開き、「...」メニューから「Create repository」を選び、コードをGitHubリポジトリへ保存します。SparkのDocsでは、この作業を行うとアプリのコードをGitHubの標準ワークフローへ移せるうえ、CodespacesやPull Request、Issuesなど既存の運用へ接続しやすくなると説明されています。少なくとも8月31日を過ぎる前に、全Sparkアプリでこの作業が終わっている状態を目標にすべきです。
実務上は、退避作業を単なるバックアップで終わらせないことが大切です。おすすめは、アプリ名、公開URL、所有者、利用部門、llm()利用有無、外部キー保管場所、次の改修担当を1枚の台帳にまとめるやり方です。5本や10本のSpark資産がある組織でも、この台帳があれば「どれを残すか」「どれを止めるか」の判断が早くなります。逆に台帳がないと、退避後に誰も保守しない休眠アプリが増え、セキュリティ面でも管理対象が曖昧になります。
llm()停止で何が起きるのか
GitHub Sparkの終了と混同しやすいのが、GitHub Models終了の影響です。Spark自体は8月31日まで既存利用者がアクセスできますが、llm()は7月30日の時点で別途停止しています。つまり、アプリが見た目上は公開中でも、要約生成、説明文生成、分類、タグ付けなどAI依存の処理だけ先に壊れている可能性があります。Changelogでは、該当コードを検索してllm()があるかどうか確認し、見つかった場合は自前の推論プロバイダーへ置き換えるよう案内しています。
ここで重要なのは、機能停止だけでなく費用責任も移る点です。GitHub Sparkの料金説明では、アプリ作成時のプロンプトはAI creditsを消費し、専用SKUで予算や分析を分けて管理できる一方、デプロイ済みアプリ自体には当面追加料金が発生しないとされています。しかしllm()を外部推論へ置き換えると、APIキー管理、従量課金、レート制御、ログ方針を自社で持つことになります。PoC段階のまま残していたアプリほど、この運用差分を見落としやすいので要注意です。
移行後の開発先をどう決めるか
GitHubはSpark終了の理由として、開発者がすでにVS Code、Copilot CLI、GitHub Copilot appのような統合環境を選び始めている点を挙げています。実務でも妥当な方向です。短命なデモを量産したいならVS CodeやCopilot appでコード中心に回した方が引き継ぎやすく、長期保守する社内ツールなら最初からリポジトリ、レビュー、課金、監査を含む開発体制へ乗せた方が事故が減ります。
判断の目安としては、社外公開中で更新予定があるアプリは「即移行」、社内限定で価値検証が終わったアプリは「退避後に停止判断」、AI推論が止まって価値が落ちたアプリは「リプレース前提で棚卸し」が現実的です。Enterprise管理者は、Sparkが既定無効だったことも踏まえ、誰が有効化されていたか、どの部門が使っていたか、コードが個人アカウントに閉じていないかまで確認しておくと、後工程がかなりスムーズになります。
FAQ
よくある質問は3つあります。1つ目は「公開済みアプリは8月31日以降も見られるのか」で、公式には既存のデプロイ済みアプリは継続稼働するとされています。2つ目は「新しくSparkで作業を始められるのか」で、これは2026年8月4日以降は不可です。3つ目は「AI機能はそのまま残るのか」で、llm()を使っている場合は7月30日以降に別対応が必要です。期限が2段階あるため、8月31日だけでなく7月30日の影響も一緒に説明できる体制が必要です。
GitHub Spark終了に伴う資産棚卸しや、Copilot中心の再設計、外部LLMへの置き換えまでまとめて進めたい場合は、 HelloCraftAIへのご相談はこちら 。公開中アプリの継続判断、AI機能の移行、社内統制まで含めて整理できます。
