GitHub Sparkのgithub.com版は、2026年8月4日に新規ユーザーの受け入れと新規アプリ作成を停止し、既存ユーザーがアプリを書き出せる期間も2026年8月31日までとされました。2026年9月3日時点では、公式に案内されたエクスポート期限はすでに過ぎています。
既存のデプロイ済みアプリはGitHub Spark終了後も稼働を続けます。しかし、今後もコードを編集するには、期限前にSparkのワークベンチから「Create repository」を実行し、ソースコードをGitHubリポジトリへ書き出しておく必要がありました。また、llm()が利用していたGitHub Modelsは2026年7月30日に終了しているため、AI機能を残す場合は別の推論プロバイダーへの置き換えが必要です。(The GitHub Blog)
この記事では、GitHub Spark終了による影響を整理したうえで、書き出したコードの確認方法、llm()の移行手順、独立した環境へ再デプロイする際の注意点を解説します。
GitHub Spark終了で何が変わったのか
GitHub Spark終了への対応では、Spark本体の終了とGitHub Modelsの終了を分けて考える必要があります。
| 日付 | 変更内容 | アプリへの影響 |
|---|---|---|
| 2026年7月30日 | GitHub Modelsが終了 | Sparkのllm()呼び出しが動作しなくなった |
| 2026年8月4日 | Sparkの新規ユーザー受け入れを停止 | 新たにSparkを利用開始できなくなった |
| 2026年8月4日 | Sparkでの新規アプリ作成を停止 | 既存ユーザーも新しいアプリを作成できなくなった |
| 2026年8月31日 | 既存ユーザー向けアクセス期間が終了 | Spark上からコードを書き出せる公式期限が終了した |
| Spark終了後 | デプロイ済みアプリは稼働を継続 | 表示や一部機能は引き続き利用できるが、Sparkでの編集は継続できない |
GitHubは、今回の変更が「github.com上で提供されている現在のGitHub Spark」に適用されると説明しています。そのため、GitHub Sparkという名称を持つ将来の機能や、別の形態で提供されるサービスまで一律に終了したと解釈するのは適切ではありません。(The GitHub Blog)
「既存デプロイは継続する」だけでは不十分な理由
既存アプリが今も表示できる場合、「そのまま使い続ければ問題ない」と判断しがちです。しかし、デプロイの継続と、ソースコードを保有して編集できる状態は別です。
特に注意したいのは、次の3点です。
- デプロイ済みアプリが動いていても、Spark上でコードを編集できるとは限らない
llm()を使ったAI機能は、アプリ本体の稼働継続とは別に停止している- 稼働中のアプリから、後で完全なソースコードを復元できるとは限らない
GitHubが継続すると説明しているのは、すでにデプロイされたアプリの稼働です。将来にわたる無期限のホスティング、コード編集機能、AI推論機能まで保証しているわけではありません。(The GitHub Blog)
そのため、既存デプロイは本番環境というよりも、移行完了までの参照環境として扱うのが安全です。
最初に自分の状況を判定する
まず、GitHubリポジトリへの書き出し状況と、llm()の使用状況を確認してください。
| コードを書き出したか | llm()の使用 | 優先すべき対応 |
|---|---|---|
| 書き出し済み | 使用していない | ローカルビルドを確認し、独立したホスティング環境へ移行する |
| 書き出し済み | 使用している | llm()を別の推論プロバイダーへ置き換える |
| 書き出していない | デプロイは稼働中 | リポジトリやローカルコピーを探し、現行アプリの仕様を保存する |
| 書き出していない | デプロイも利用できない | 手元の資料や画面記録を基に再構築を検討する |
最も重要なのは、デプロイURLの有無ではなく、編集可能なソースコードを確保できているかどうかです。
Create repositoryで行うコード書き出しの手順
GitHubが案内していた正式な書き出し方法は、ファイルをZIP形式でダウンロードする操作ではありません。SparkのワークベンチからGitHubリポジトリを作成する方法です。
期限前に必要だった操作は、次のとおりです。
- 書き出したいアプリのSparkワークベンチを開く
- 画面内の「…」メニューを選択する
- 「Create repository」を選択する
- 画面の案内に従ってGitHubリポジトリを作成する
- 所有しているアプリごとに同じ操作を実行する
GitHubは、今後もアプリを編集したいユーザーに対して、2026年8月31日までにこの操作を行うよう案内していました。(The GitHub Blog)
リポジトリ作成後に確認する項目
「Create repository」を実行しただけで、移行が完了したとは判断できません。作成されたリポジトリを開き、次の項目を確認します。
| 確認項目 | 確認する内容 |
|---|---|
| リポジトリ所有者 | 個人アカウントか、所属Organizationか |
| 公開範囲 | PublicまたはPrivateのどちらになっているか |
| ソースファイル | 画面、ロジック、設定ファイルが保存されているか |
| 依存関係 | package.jsonやロックファイルが存在するか |
| ビルド手順 | READMEやpackage.jsonに実行コマンドが記載されているか |
| シークレット | APIキーや認証情報がコミットされていないか |
| 外部サービス | データベース、ストレージ、認証機能への依存があるか |
| ライセンス | 使用しているライブラリや素材を移行先でも利用できるか |
リポジトリは、必ずローカル環境にも複製しておきます。
git clone https://github.com/OWNER/REPOSITORY.git
cd REPOSITORY
git statusNode.jsプロジェクトで、package-lock.jsonと対応するスクリプトが存在する場合は、次のように依存関係とビルドを確認できます。
npm ci
npm run
npm run buildnpm runを実行すると、そのプロジェクトで定義されているスクリプトを確認できます。buildやtestが定義されていない場合は、存在しないコマンドを無理に実行せず、READMEとpackage.jsonを確認してください。
8月31日までに書き出せなかった場合の対応
2026年9月3日時点では、GitHubが案内していたSparkへのアクセス期間は終了しています。公式発表には、期限後も同じ方法でエクスポートできることや、書き出していないコードを必ず復元できるという案内はありません。(The GitHub Blog)
書き出しを行っていない場合は、次の順番で確認します。
GitHub上に作成済みのリポジトリがないか探す
自分の個人アカウントだけでなく、所属しているOrganizationも確認してください。
確認対象は次のとおりです。
- 2026年8月前後に作成されたリポジトリ
- Sparkアプリ名と同じ、または似た名前のリポジトリ
- 他のメンバーが所有者になっているリポジトリ
- Private設定で作成されたリポジトリ
- アーカイブ済みのリポジトリ
アプリ名とリポジトリ名が一致しているとは限らないため、作成日や更新日も手掛かりにします。
ローカルコピーや過去の作業環境を確認する
以前にリポジトリを開いたことがある場合は、次の場所にコードが残っている可能性があります。
- 開発用PCの作業フォルダ
- GitHub Desktopのローカルリポジトリ
- VS Codeの「最近使用した項目」
- ダウンロード済みのZIPファイル
- バックアップサービスや共有ストレージ
- チームメンバーのローカルクローン
GitHubリポジトリが削除されていても、完全なローカルクローンが残っていれば、別のリポジトリへプッシュできる場合があります。
稼働中のアプリから仕様を保存する
ソースコードを確保できない場合でも、デプロイ済みアプリが動いている間に、再構築に必要な情報を保存します。
- 全画面のスクリーンショット
- 入力から出力までの操作動画
- 使用している文言やプロンプト
- データの項目名と入力規則
- エラー時の動作
- 認証方法と権限の違い
- 独自ドメインやDNSの設定
- 外部APIやWebhookの接続先
- エクスポート可能なユーザーデータ
業務で利用しているアプリでは、画面だけでなく、誰がどの権限で何を操作するのかも記録してください。
GitHub Supportへ問い合わせる
業務上重要なアプリで、リポジトリもローカルコピーも見つからない場合は、GitHub Supportへの問い合わせを検討します。
問い合わせには、次の情報を含めると状況を伝えやすくなります。
- GitHubアカウント名
- Organization名
- Sparkアプリ名
- デプロイ済みアプリのURL
- 最後にSparkへアクセスした日
- 「Create repository」を実行したかどうか
- 業務への影響
- 必要としている対応がコードの取得なのか、データの取得なのか
ただし、期限後のコード復元は公式に保証された手続きではありません。問い合わせと並行して、現行アプリの仕様保存と再構築準備も進める必要があります。
llm()を使用しているか確認する方法
GitHub SparkアプリがAI機能を使っているかどうかは、リポジトリ内でllm()を検索して確認します。
GitHubも、コード内にllm()の呼び出しがなければ、GitHub Models終了の影響を受けないと説明しています。一方、llm()が見つかった場合は、AI機能を維持するために別の推論プロバイダーへ置き換える必要があります。(The GitHub Blog)
macOSやLinuxで検索する
ripgrepが利用できる場合は、次のコマンドで検索できます。
rg -n \
--glob '!node_modules/**' \
--glob '!dist/**' \
--glob '!build/**' \
'\bllm\s*\(' .Windows PowerShellで検索する
Get-ChildItem -Recurse -File |
Where-Object {
$_.FullName -notmatch '\\(node_modules|dist|build)\\'
} |
Select-String -Pattern '\bllm\s*\('VS Codeで検索する
VS Codeでは、対象リポジトリを開いてCtrl+Shift+Fを押し、次の文字列を検索します。
llm(直接のllm()呼び出しが見つからなくても、独自の関数でラップされている可能性があります。たとえば、generateAnswer()やcreateSummary()の内部からllm()を呼び出している場合です。
検索結果が見つかったら、その関数だけを置き換えるのではなく、呼び出し元までたどって次の情報を整理してください。
- どの画面から呼び出されているか
- どのような入力を渡しているか
- テキストとJSONのどちらを期待しているか
- ストリーミング表示を使用しているか
- エラー時にどのような処理をしているか
- 入力内容に個人情報や機密情報が含まれるか
llm()を別の推論プロバイダーへ移行する手順
llm()は単純に別の関数名へ置き換えればよいとは限りません。プロバイダーによって、認証方法、リクエスト形式、レスポンス形式、利用できるモデル、料金、レート制限が異なるためです。
移行先を選ぶときの判断基準
| 判断項目 | 確認する内容 |
|---|---|
| 出力形式 | 通常のテキスト、JSON、ストリーミングなどに対応しているか |
| データ管理 | 入力データの保存、学習利用、保持期間を管理できるか |
| リージョン | 必要な国や地域で処理できるか |
| 認証 | APIキー、クラウドID、サービスアカウントなどに対応しているか |
| 料金 | 入力・出力トークン単価と最低料金を確認できるか |
| 利用制限 | 1分当たりのリクエスト数やトークン数が要件を満たすか |
| 可用性 | 障害時の代替モデルや再試行方法があるか |
| 移植性 | 将来、別のプロバイダーへ変更しやすい設計にできるか |
個人開発では導入の速さを優先できますが、業務アプリではデータの保存方針、契約、処理リージョン、監査ログを先に確認してください。
APIキーをブラウザーへ埋め込まない
移行後の基本構成は、次のようにします。
利用者のブラウザー
↓
自分で用意したバックエンドAPI
↓
外部の推論プロバイダーブラウザーから推論プロバイダーへ直接アクセスし、JavaScript内にAPIキーを埋め込む構成は避けてください。フロントエンドに含めた値は、環境変数として設定していても、ビルド後のファイルや通信内容から取得される可能性があります。
静的サイトとして書き出されたアプリの場合は、サーバーレス関数やAPIサーバーを追加し、その中でAPIキーを読み込む構成に変更します。
プロバイダー固有の処理を分離する
アプリ全体に特定プロバイダーのSDKを直接記述すると、次回の移行が難しくなります。推論処理を1か所にまとめるため、次のような共通インターフェースを作成します。
export type GenerateInput = {
prompt: string;
};
export type GenerateOutput = {
text: string;
};
export interface InferenceProvider {
generate(input: GenerateInput): Promise<GenerateOutput>;
}アプリ本体は、このInferenceProviderだけを呼び出します。実際のエンドポイント、認証ヘッダー、モデル名、レスポンス変換は、プロバイダーごとの実装に閉じ込めます。
const result = await inferenceProvider.generate({
prompt: userInput,
});
setAnswer(result.text);この構成にしておけば、将来プロバイダーを変更するときも、画面や業務ロジックへの修正を最小限に抑えられます。
シークレットを環境変数で管理する
APIキーやモデル名は、コードに直接記述せず、移行先のホスティングサービスが提供するシークレット管理機能へ登録します。
LLM_API_KEY
LLM_ENDPOINT
LLM_MODEL.envファイルを利用する場合は、.gitignoreの対象になっていることを確認します。
.env
.env.*誤ってAPIキーをコミットした場合は、ファイルから削除するだけでは不十分です。リポジトリ履歴に残る可能性があるため、対象キーを無効化して再発行してください。
推論プロバイダー置き換え後に必要なテスト
別のモデルへ変更すると、同じプロンプトでも回答内容やJSON形式が変わることがあります。正常な応答が1回返っただけで移行完了と判断せず、次のテストを行います。
| テスト項目 | 確認内容 |
|---|---|
| 通常入力 | 一般的な入力で期待する回答が返るか |
| 空入力 | 未入力時に不要なAPI呼び出しが発生しないか |
| 長文入力 | 上限超過時に適切なエラーを表示できるか |
| JSON出力 | 必須項目が欠けた場合に処理が停止しないか |
| タイムアウト | 応答が遅い場合に画面が固まらないか |
| レート制限 | 429などのエラーを適切に処理できるか |
| 認証エラー | APIキー失効時に利用者へ安全なメッセージを表示できるか |
| 不適切な出力 | モデルの回答を無条件に実行していないか |
| コスト | 1操作当たりのトークン数と費用を把握できるか |
| ログ | 個人情報やプロンプト全文を過剰に保存していないか |
特にJSONを期待する機能では、モデルの回答をそのままJSON.parse()へ渡すだけでは不安定です。スキーマ検証を行い、必須項目の欠落や型の違いを処理できるようにします。
コードを書き出した後のホスティング移行
「Create repository」で取得できるのは、移行の起点となるコードです。アプリのデータ、認証、シークレット、独自ドメインまで自動的に別環境へ移るとは限りません。
再デプロイ前に、次の構成要素を洗い出してください。
| 構成要素 | 確認する内容 |
|---|---|
| フロントエンド | ビルドコマンド、出力先、ルーティング方式 |
| バックエンド | API、サーバーレス関数、実行環境 |
| データ | データベース、ファイル、ユーザー設定 |
| 認証 | GitHubログイン、メール認証、アクセス制御 |
| AI推論 | 移行先プロバイダー、モデル、APIキー |
| ドメイン | DNS、HTTPS証明書、リダイレクト |
| 外部連携 | Webhook、外部API、CORS設定 |
| 運用監視 | ログ、エラー通知、稼働監視、費用監視 |
安全な移行順序
- ローカル環境でアプリを起動する
- ビルドエラーと依存関係の問題を解消する
- 開発用の推論プロバイダーへ接続する
- 移行先にプレビュー環境を作成する
- データと認証機能を移行する
- 主要な画面と業務フローをテストする
- 独自ドメインやDNSを切り替える
- 旧デプロイをすぐには削除せず、切り戻し手段を残す
データを持つアプリでは、コードより先にデータ移行方法を決める必要があります。移行先で画面が表示できても、過去のデータを参照できなければ業務を継続できません。
Spark終了後はGitHub Copilotで編集を続けられるのか
GitHubは、アプリ開発を続ける環境として、VS Code、Copilot CLI、GitHub Copilotアプリなどの統合された開発ワークフローを挙げています。(The GitHub Blog)
ただし、GitHub Copilotは、書き出したコードの修正や機能追加を支援する開発ツールです。次の機能が自動的に置き換わるわけではありません。
- Sparkが提供していたホスティング
llm()が提供していたAI推論- アプリ固有のデータ保存
- 認証とアクセス制御
- 本番環境の監視や障害対応
したがって、移行先は「GitHub Copilotだけ」と考えるのではなく、次の3つに分けて選定します。
- コードを編集する開発環境
- アプリを動かすホスティング環境
- AI機能を動かす推論プロバイダー
この3つを分離して考えると、Spark終了後の構成を整理しやすくなります。
GitHub Sparkのコード移行で失敗しやすいポイント
リポジトリを作成しただけで移行完了と考える
リポジトリにはソースコードがあっても、データ、シークレット、認証設定、ホスティング設定が不足している可能性があります。必ずローカル起動と外部環境へのテストデプロイを行ってください。
アプリが表示できるためllm()も動いていると思い込む
アプリの画面表示とAI推論は別の処理です。ボタンを押したときだけllm()が呼ばれる構成では、通常画面を見ただけでは障害に気付けません。
APIキーをフロントエンドへ設定する
フロントエンド用の環境変数にAPIキーを登録しても、安全になるとは限りません。推論プロバイダーへのアクセスはバックエンド経由にします。
モデルを変更して出力形式を確認しない
モデルによって、改行、JSON構造、文章量、拒否応答などが変化します。既存コードが特定形式を前提にしている場合は、レスポンスを検証してから画面へ渡します。
利用料金の上限を設定しない
Sparkでは利用者が直接管理していなかった推論費用も、移行後は自分で管理する必要があります。APIキーの利用制限、予算通知、レート制限を設定し、異常な連続実行に備えてください。
旧デプロイを先に削除する
新環境のテストが終わる前に旧デプロイを削除すると、画面仕様や動作を確認できなくなります。移行が完了し、必要なデータと設定を回収できるまでは維持するのが安全です。
今すぐ行うべき対応
GitHub Sparkからコードを書き出している場合は、リポジトリをローカルへ複製し、ビルドできるか確認してください。続いてllm()を検索し、見つかった場合はバックエンド経由で別の推論プロバイダーへ接続する構成に変更します。
書き出したリポジトリが見つからない場合は、個人アカウント、Organization、ローカルPC、GitHub Desktop、バックアップを確認します。それでも見つからなければ、稼働中のアプリから画面、データ、処理手順を保存し、GitHub Supportへの問い合わせと再構築を並行して進める必要があります。
重要なのは、「デプロイが動いているか」だけで判断しないことです。ソースコード、データ、認証、AI推論、ホスティングをそれぞれ確認し、GitHub Sparkに依存しない状態まで移行しておくことが、今後もアプリを維持するための確実な対応です。
コメント