3行まとめ
このテーマをもう少し広げて見るなら、GitHub CopilotのEnterprise-managed pluginsがVS Codeでpublic preview：MCP、hooks、skillsを企業で標準化する確認ポイント と GitHub Copilot SDKが一般提供：6言語対応、MCP/BYOK、課金で自社アプリに組み込む確認ポイント も合わせて確認してください。sandboxの実行境界とあわせて、企業がMCP、hooks、skillsをどこまで標準化するかを確認できるため。
GitHubは2026年6月2日、GitHub Copilotのcloud and local sandboxesをpublic previewとして発表しました。
Copilotがコマンドやツールを実行する場所を、ローカル端末上の制限環境か、GitHubホストのクラウド環境に分けて考える更新です。
ローカルsandboxは標準のGitHub Copilotシートに含まれ、クラウドsandboxはcompute、memory、storageの利用量課金です。
2026年6月5日JST時点で確認できる公式説明を、local、cloud、組織ポリシー、課金に分けて読む。
GitHubは2026年6月2日、GitHub Copilotのcloud and local sandboxesをpublic previewとして発表しました。Copilotがコマンドやツールを実行する場所を、ローカル端末上の制限環境か、GitHubホストのクラウド環境に分けて考える更新です。
ローカルsandboxは標準のGitHub Copilotシートに含まれます。一方、クラウドsandboxはcompute、memory、storageの利用量課金で、組織ではsandbox access policyの有効化と予算管理を先に確認する必要があります。
この記事では、Copilot CLIやCopilot appの新機能紹介ではなく、AIエージェントに実行を任せる前の導入判断に絞ります。公式ドキュメントで確認できる範囲を、ローカル、クラウド、権限、課金、pilotの5つに分けて読みます。
GitHub Copilot sandboxesで何が変わったのか
- 2026年6月2日
GitHub Changelogは、localとcloudの両方のsandboxをpublic previewとして告知しています。
- Copilot CLI
現在の説明では、主な対象はGitHub Copilot CLIセッションです。
- Copilot app
cloud sandboxesはGitHub Copilot appのセッションでも使えるとされています。
- 導入判断
組織のルール、請求、レビュー手順を含めて検証する機能として扱うのが現実的です。
sandboxの価値の中心は、モデル性能ではなく実行場所の制御にあります。
GitHub Copilot sandboxesの要点は、Copilotが「答える」だけでなく、ツールを使い、シェルコマンドを実行し、ファイルに触る場面を前提にした実行環境が用意されたことです。GitHubの発表では、GitHub Copilotがローカル端末上でもクラウド上でも、隔離されたsandbox内で動けるようになったと説明されています。
この発表は、同じ2026年6月2日に出た<a href="https://msft-watch.blog.mo-gmo.com/msft-22-github-copilot-cli-build-2026-voice-schedule-rubber-duck/" rel="noopener">GitHub Copilot CLI刷新</a>や、<a href="https://msft-watch.blog.mo-gmo.com/msft-18-github-copilot-app-preview-build-2026/" rel="noopener">GitHub Copilot appのプレビュー拡大</a>と隣り合う更新です。ただし、本稿の主役はUIやアプリ画面ではありません。Copilotに実行を任せるとき、どこで動かし、何を制限し、誰が許可し、どの費用を見るのかを追います。
public previewの中心は「エージェントの実行場所」
GitHub Docsでは、cloud and local sandboxesを「Copilotがコード、ツール、ファイルシステム、ネットワークリソースと安全にやり取りするための隔離実行環境」と説明しています。現在の説明では、主な対象はGitHub Copilot CLIセッションです。さらに、cloud sandboxesはGitHub Copilot appのセッションでも使えるとされています。
ここで重要なのは、sandboxを「AIが賢くなる機能」と読まないことです。価値の中心は、モデル性能ではなく実行場所の制御にあります。Copilotが代理でコマンドを走らせるなら、どのファイルへ届くのか、外部ネットワークに触れるのか、端末の状態をどこまで変えられるのかを分けて考える必要があります。
根拠
GitHub Changelogは、localとcloudの両方のsandboxをpublic previewとして告知しています。GitHub Docsは、local sandboxを端末上の制限された実行、cloud sandboxをGitHubホストの隔離された一時的なLinux環境として説明しています。この記事では、2026年6月5日JST時点で確認できる公式説明だけを使います。
注意点
GitHub Docsには、cloud and local sandboxesはpublic previewであり変更される可能性があると明記されています。導入判断では「すぐ標準運用へ固定する機能」ではなく、「組織のルール、請求、レビュー手順を含めて検証する機能」として扱うのが現実的です。
既存のCopilot更新と分けて読む
Copilot CLI刷新の記事では、Rubber Duck、音声入力、prompt scheduling、新しいterminal UIが焦点でした。Copilot appの記事では、desktop app、canvas、セッション管理、プレビュー対象が中心でした。GitHub Copilot sandboxesは、それらの体験を支える実行環境の話です。
とくに、CLIで何かを実行する、Copilot appからcloud sessionを扱う、複数のagentic workflowを試す、といった場面ではsandboxが効いてきます。逆に、単にチャットで相談するだけの使い方なら、この記事で扱う課金や組織ポリシーの多くはすぐには関係しません。
確認項目
導入前に最初に見るべき点は4つです。対象がCopilot CLIなのかCopilot appなのか。実行場所は端末なのかクラウドなのか。組織メンバーに許可されているのか。クラウド利用なら誰の請求先に乗るのか。この4点を決めないまま便利そうなコマンド例だけを広げると、あとでセキュリティと費用の両方を説明しづらくなります。
ローカルsandboxとクラウドsandboxの選び方
どちらが安全かを一言で決めず、端末上の制限とクラウド側への切り離しを別の条件として見る。
local sandboxとcloud sandboxは、単純な上位下位ではありません。どちらが「安全」かを一言で決めるより、何をどこから切り離したいのかで選ぶほうが実務に合います。
| 観点 | local sandbox | cloud sandbox |
|---|---|---|
| 実行場所 | 自分の端末上のsandbox | GitHubホストの隔離されたLinux環境 |
| 入口 | Copilot CLIセッション内の/sandbox enable | copilot --cloud |
| 主な価値 | 端末上でのファイル、ネットワーク、システム機能へのアクセスを制限する | ローカル環境から切り離し、クラウド側で実行する |
| 向いている用途 | 既存の作業場所を保ったまま低リスクに試す | 端末に依存関係を入れたくない、重い処理を逃がしたい、複数タスクを並列に動かしたい |
| 費用 | 標準GitHub Copilotシートに含まれる | 利用量課金の対象 |
| 管理上の焦点 | 端末管理、MDM、local policy | 組織の有効化、請求先、budget、停止と削除 |
ローカルsandboxは端末上のCopilot実行を制限する
local sandboxは、Copilot CLIセッション内で/sandbox enableを実行して使います。GitHubの説明では、このセッションでCopilotが代理実行するシェルコマンドはsandbox内で動き、ファイルシステム、ネットワーク、システム機能へのアクセスが制限されます。
開発者にとっては、普段の端末、既存リポジトリ、慣れた作業場所を保ちながら、Copilotの実行範囲を絞れる点が利点です。公式発表では、local sandboxはMicrosoft MXC technologyを使い、macOS、Linux、Windowsで一貫した隔離体験を提供すると説明されています。組織ではMicrosoft Intuneやその他のMDMでlocal sandbox policiesを構成、強制できるともされています。
向いている条件
最初のpilotでは、local sandboxから見る価値があります。追加のクラウド課金を気にせず、低リスクのリポジトリで、Copilotがどんなコマンドを実行し、どんな差分を作り、どこで止まるのかを観察できるからです。
ただし、費用が増えないことと、全社展開してよいことは別です。端末に残る秘密情報、社内ネットワークへの到達性、ローカル依存関係、社内の端末管理ポリシーを見ないまま「localだから安心」と言い切るのは避けるべきです。
注意点
local sandboxは端末上で動きます。クラウド環境へ完全に切り離すものではありません。開発者の端末が扱う認証情報、ネットワーク、ローカルファイルの設計によって、見るべきリスクは変わります。pilotでは、sandboxを有効にした状態でCopilotがアクセスできる範囲と、組織の端末管理で制限したい範囲を並べて確認する必要があります。
クラウドsandboxはGitHubホストの一時的なLinux環境で動く
cloud sandboxは、copilot --cloudでクラウド側のCopilot CLIセッションを開始する仕組みです。GitHub Docsでは、cloud sandbox sessionはローカル環境や他セッションから分離され、GitHubがホストする一時的なLinux環境で動くと説明されています。基盤にはAzure Container Apps Sandboxesが使われ、GitHubがidentity、policy、billing layerを提供します。
この形は、ローカル端末へ依存関係を入れたくない場合、端末のCPUやメモリを使いたくない場合、複数のCopilotタスクを並列で走らせたい場合に向きます。Docsでは、cloud sandbox sessionを停止すると状態のsnapshotが保存され、後で再開できるとされています。削除すると、実行環境とsnapshotは削除され、復元できません。
向いている条件
cloud sandboxが合うのは、端末をまたいで作業を続けたい、重い処理を端末から逃がしたい、ローカル環境を汚したくない、といった条件です。セキュリティ面でも、ローカル端末から切り離した環境で実行できる点は大きな価値になります。
ただし、クラウドで動くということは、利用時間、割り当てメモリ、snapshot storageが費用に直結します。開発者の便利さだけでなく、誰の組織に請求されるのか、いつ停止するのか、いつ削除するのかを先に決める必要があります。
注意点
cloud sandboxは、別のクラウドプロバイダー設定やAPIキー、独自インフラ構築を要求しないと説明されています。認証は既存のCopilot CLI authenticationを使います。それでも、組織やEnterpriseでは、所有者がCloud Sandbox access policyを有効化していなければ、メンバーは利用できません。
判断は「何をどこから切り離すか」で見る
localとcloudの比較では、「どちらが安全か」だけでは判断が粗くなります。守りたい対象がローカル端末なのか、リポジトリの秘密情報なのか、端末リソースなのか、依存関係の再現性なのか、請求の予測可能性なのかで答えが変わります。
小さく始めるなら、local sandboxで低リスクの作業を見ます。クラウドに出すなら、先に組織ポリシー、請求先、budget、停止と削除の運用を決めます。セキュリティ担当とFinOps担当が同じ表を見られるようにしておくと、あとから「誰が許可したのか」「どこに費用が出たのか」で詰まりにくくなります。
評価基準
pilotの前に、対象リポジトリ、秘密情報の有無、外部ネットワークへの依存、実行時間、参加人数、予算上限の6点を決めます。少なくとも、Copilotが実行したコマンドを人間が追えること、差分レビューを挟めること、失敗時に戻せることは必須条件です。
組織で有効化する前に見る権限とポリシー
- 1Copilot CLIの認証
対象ユーザーがCopilot CLIにサインインでき、GitHub Copilotの利用権限があるかを確認します。
- 2Organization settings
Organization settingsからCode, planning, and automation、Sandboxes、Sandbox accessへ進みます。
- 3DisabledまたはEnabled for all members
組織メンバー向けのsandbox accessはデフォルトで無効で、選択肢はDisabledとEnabled for all membersとして示されています。
- 4請求先とbudget
cloud sandboxを使う場合、請求先になる組織を誰が管理するのか、budgetとalertsをどの範囲に設定するのかを決めます。
- 5preview中の検証結果
preview中の検証結果を、正式運用のルールにどう反映するのかを確認します。
localは端末管理と作業範囲、cloudは請求先とbudgetが強く関係します。
開発者個人が新しいCLI機能として試す話と、組織メンバーに許可する話は分ける必要があります。GitHub Docsでは、organization ownerがsandbox access policyを管理できると説明されています。
組織メンバーの利用はデフォルト無効から始まる
公式手順では、organization ownerはorganization settingsからsandboxesのaccess policyを管理します。Docsの説明では、組織メンバー向けのsandbox accessはデフォルトで無効です。選択肢は、DisabledとEnabled for all membersとして示されています。
この点は導入判断でかなり重要です。public previewの段階で、全員に一斉有効化する前に、どの組織で、どのリポジトリで、どのタスクまで試すのかを決める必要があります。公式手順にない細かな段階設定を記事側で作るのは避けます。使える設定は、公開されているDocsの範囲で確認してください。
根拠
GitHub Docsの有効化手順は、Organization settingsからCode, planning, and automation、Sandboxes、Sandbox accessへ進み、DisabledまたはEnabled for all membersを選んで保存する流れです。管理者向けの記事では、この手順を「できるかどうか」ではなく「全員に許可する前に何を決めるか」という文脈で読むべきです。
注意点
組織メンバーに許可する場合、local sandboxとcloud sandboxを同じ温度で扱わないほうがよいです。localは端末管理と作業範囲、cloudは請求先とbudgetが強く関係します。とくにcloud sandboxは、開発者がcopilot --cloudで開始するときに、所有組織を選ぶと説明されています。その選択が請求先にも関わります。
認証はCopilot CLIの既存認証を使う
GitHub Docsでは、sandboxes for GitHub Copilotは既存のCopilot CLI authenticationを使うと説明されています。Copilot CLIにサインインでき、Copilotにアクセスできるユーザーであれば、基本条件は満たします。別のクラウドプロバイダー設定、APIキー、インフラ構築は不要とされています。
ただし、組織利用ではそれだけでは足りません。organization ownerまたはenterprise ownerがCloud Sandbox access policyを有効にしているかが条件になります。既存のCopilot cloud agent policiesとの整合も見るべきです。
確認項目
管理者は、少なくとも次の項目を確認してから有効化します。
- 対象ユーザーがCopilot CLIにサインインできるか。
- 対象ユーザーにGitHub Copilotの利用権限があるか。
- sandbox access policyがDisabledのままか、Enabled for all membersにするのか。
- cloud sandboxを使う場合、請求先になる組織を誰が管理するのか。
- budgetとalertsをどの範囲に設定するのか。
- preview中の検証結果を、正式運用のルールにどう反映するのか。
課金はローカル無料、クラウド従量を分けて読む
2026年6月は誰でも無料で使えるという意味ではなく、eligible account、超過利用、preview後の扱いを分けて読む。
費用面は、local sandboxとcloud sandboxで最初から分けてください。GitHub Docsでは、local sandboxは標準のGitHub Copilot seatに追加費用なしで含まれる一方、cloud sandboxingは利用量に基づいて課金されると説明されています。
| Meter | 何に対する課金か | Unit | 公式Docsで確認した単価 |
|---|---|---|---|
| Compute | cloud sandbox sessionが実行中の時間 | Compute second | $0.000024 |
| Memory | 実行中のcloud sandbox sessionに割り当てられたメモリ | GiB second | $0.000003 |
| Storage | 停止中sessionのsnapshot storage | GiB month | $0.005 |
ローカルsandboxは標準Copilotシートに含まれる
local sandboxは、GitHub Copilotの標準シートに含まれます。初期pilotで費用の論点を増やしたくない場合、まずlocal sandboxでCopilotが実行するコマンド、変更範囲、失敗時の戻し方を見るのは合理的です。
ただし、追加費用がないことを「管理不要」と読まないでください。local sandboxでは、端末管理、MDM、社内ネットワーク、秘密情報の扱いを見ます。費用の代わりに、端末側の統制が焦点になります。
注意点
local sandboxを使う場合でも、Copilotが扱うリポジトリの種類は選ぶべきです。規制対象データ、顧客データ、秘密鍵や本番環境の接続情報が絡むリポジトリを、preview検証の最初に選ぶ理由はありません。低リスクのリポジトリから始め、ログと差分を確認できる形にします。
クラウドsandboxはcompute、memory、storageで見る
cloud sandboxは、使っている間のcompute、割り当てられたmemory、停止中sessionのsnapshot storageで費用を見ます。memoryは実際に使った量ではなく、sessionに割り当てられた量を基準に測られると説明されています。停止したsessionはcomputeとmemoryのmeteringから外れますが、snapshot storageは削除するまで測られます。
このため、費用は「何時間使ったか」だけでは読めません。複数sessionを並列で動かしたか。メモリ割り当てはどのくらいか。停止したまま残しているsnapshotはないか。削除運用を決めているか。これらを一緒に見ます。
確認項目
cloud sandboxをpilotに入れる前に、次の運用を決めます。sessionを誰が開始するのか。所有組織を誰が選ぶのか。使い終わったsessionを停止するのか削除するのか。snapshotをどのくらい残すのか。budgetの上限に達したら誰が判断するのか。
上振れと下振れ
費用が上振れしやすいのは、長時間のactive session、並列実行、停止したまま残るsnapshotです。下振れしやすいのは、短時間の検証、明確な削除運用、budgetによる上限設定です。この記事では実測のない利用料金試算は置きません。公式単価からの単純計算はできても、実際の請求額は使い方とアカウント条件に左右されるからです。
2026年6月のpreview entitlementと予算設定
GitHubのBilling docsでは、public preview中、eligible GitHub accountsにcloud sandboxesを試すための$10 monthly entitlementがあると説明されています。このentitlementは2026年6月に利用可能で、超過分は課金対象です。preview期間後はentitlementが適用されず、すべての利用が課金されるとされています。
この説明は「2026年6月は誰でも無料で使える」という意味ではありません。eligible accountかどうか、超過利用があるか、preview後にどうなるかを分けて読む必要があります。
注意点
cloud sandbox spendingは、Bundled AI creditsのbudget typeには含まれないと説明されています。GitHub Copilot AI creditsやcloud agent AI creditsと同じ枠で管理するのではなく、cloud sandboxにはproduct-level budgetまたはSKU-level budgetを使うのが公式Docsの説明です。予算上限到達時にusageを止める設定も、pilot前に確認しておきたい項目です。
Copilot関連では、<a href="https://msft-watch.blog.mo-gmo.com/msft-14-github-copilot-code-review-actions-minutes/" rel="noopener">Copilot code reviewの課金変更</a>でも、AI CreditsやGitHub Actions minutesとの切り分けが論点になりました。cloud sandboxの費用も同じく、機能名ではなく、どのmeterに乗るのかで読む必要があります。
pilotで確認すべきチェックリスト
コマンド、変更ファイル、外部ネットワークへの接続、テスト結果、失敗時の巻き戻しを確認します。
依存関係のインストールが必要な小さな修正、テスト実行、ドキュメント更新、低リスクなリファクタリングを選びます。
顧客データ、本番秘密情報、社内限定ネットワークに触るタスクは、初回pilotから外します。
有効化範囲、停止条件、扱ってよいデータ種別、cloud利用時のbudget、alerts、請求先を明確にします。
低リスクタスクで再現可能に動くこと、予算上限と請求先を説明できること、管理者が有効化と停止を説明できること、開発者が差分レビューを挟めることです。
public preview中の検証結果は、社内標準の最終版ではありません。
GitHub Copilot sandboxesは、便利そうだから全員で使う、という順番には向きません。public previewの段階では、まず低リスクのタスクでpilotを作り、開発者体験、セキュリティ、再現性、費用、管理運用を同じメモに残すのが堅実です。
開発者側のpilot項目
開発者は、Copilotが何を実行したかを追えることを最初に見ます。コマンド、変更ファイル、外部ネットワークへの接続、テスト結果、失敗時の巻き戻しが確認できなければ、速度が上がってもチーム導入には進めにくいです。
local sandboxとcloud sandboxを同じタスクで比較できると判断しやすくなります。たとえば、依存関係のインストールが必要な小さな修正、テスト実行、ドキュメント更新、低リスクなリファクタリングを選びます。顧客データ、本番秘密情報、社内限定ネットワークに触るタスクは、初回pilotから外します。
評価基準
評価は「早かったか」だけにしないでください。意図しないファイル変更がないか。依存関係の再現に時間がかからないか。Copilotが作った差分をレビュー前に説明できるか。失敗したときに中断、停止、削除の判断ができるか。ここまで見て、初めて次の段階へ進めます。
管理者とFinOps側のpilot項目
管理者は、有効化範囲と停止条件を先に決めます。Sandbox access policyを有効にする組織、対象ユーザー、対象リポジトリ、扱ってよいデータ種別、cloud利用時のbudget、alerts、請求先を明確にします。
FinOps担当は、cloud sandboxをAI Creditsの消費と混同しないようにします。compute、memory、storageの3meterを見て、product-level budgetまたはSKU-level budgetで制御する前提を置きます。preview entitlementがある場合でも、超過分とpreview後の扱いを別に見る必要があります。
確認項目
管理側のチェックリストは次の通りです。
- sandbox access policyの現在値。
- Enabled for all membersにする前の対象組織と対象タスク。
- Copilot cloud agent policiesとの整合。
- cloud sandboxの所有組織と請求管理者。
- product-level budgetまたはSKU-level budget。
- Stop usage when budget limit is reachedを使うかどうか。
- sessionの停止、削除、snapshot storageの扱い。
- preview終了時に再評価する日付。
次の段階へ進める条件
pilotから本番寄りの運用へ進める条件は、少なくとも4つです。低リスクタスクで再現可能に動くこと。予算上限と請求先を説明できること。管理者が有効化と停止を説明できること。開発者が差分レビューを挟めること。
この4条件がそろわない場合、全員有効化ではなく、local sandboxだけに絞る、cloud sandboxは対象組織を限定する、またはpreview中は保留する判断が自然です。
注意点
public preview中の検証結果は、社内標準の最終版ではありません。GitHubのDocsや料金説明が変わる可能性があります。pilotメモには、確認日、参照したDocs、試した範囲、許可した組織、budget設定を残しておくと、後で見直しやすくなります。
どの読者はどこから試すべきか
最初の一歩は低リスクのlocal pilotです。cloudに進む場合は、請求先、budget、停止と削除の運用を先に決めます。
開発者、チームリード、組織管理者、FinOps担当では、最初に見る場所が違います。GitHub Copilot sandboxesは、個人の便利機能としても読めますが、組織導入では権限と費用の設計が同じくらい重要です。
開発者はローカルから、管理者は有効化と予算から
個人開発者や小さなチームは、まずlocal sandboxで低リスクの作業を試すのが現実的です。普段の作業場所を保ちながら、Copilotが実行するコマンドと差分を見られます。cloud sandboxに進む場合は、組織ポリシーと課金の確認を先に挟みます。
チームリードは、どの作業をCopilotに任せてよいかを決めます。管理者は、sandbox access policy、MDM、Copilot cloud agent policies、budgetの整合を見ます。FinOps担当は、cloud sandboxがBundled AI creditsではなく、別のmetered productとして費用管理される点を押さえます。
判断表
| 読者 | 最初の一手 | まだ待つべき条件 |
|---|---|---|
| 個人開発者 | local sandboxで低リスクのCLI作業を試す | 扱うリポジトリに秘密情報が多い |
| チームリード | タスク範囲、レビュー手順、失敗時の戻し方を決める | 差分レビューの責任者が決まっていない |
| 組織管理者 | sandbox access policyとMDM方針を確認する | 全員有効化の説明ができない |
| FinOps担当 | cloud sandboxのbudgetとalertsを用意する | 請求先組織と予算上限が未定 |
結論
GitHub Copilot sandboxesは、Copilotに実行を任せるための土台です。local sandboxは端末上の制限環境として、cloud sandboxはGitHubホストの隔離環境として、それぞれ役割が違います。
2026年6月時点ではpublic previewであり、組織ではデフォルト無効、クラウドは利用量課金、preview entitlementは条件付きという点を崩さずに読む必要があります。最初の一歩は、低リスクのlocal pilotです。cloudに進む場合は、請求先、budget、停止と削除の運用を先に決めてから使うのが安全です。
Microsoft Watch JapanはMicrosoftおよびGitHubと非提携の情報整理サイトです。商標や公式名称は、読者が一次情報を確認しやすくする目的で記載しています。
次に読むなら
次に読むなら
参照した主な情報源
- GitHub Changelog, Cloud and local sandboxes for GitHub Copilot now in public preview, 2026年6月2日発表、2026年6月5日JST確認。https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview/
- GitHub Docs, About cloud and local sandboxes for GitHub Copilot, 2026年6月5日JST確認。https://docs.github.com/en/copilot/concepts/about-cloud-and-local-sandboxes
- GitHub Docs, Enabling or disabling cloud and local sandboxes for GitHub Copilot for your organization, 2026年6月5日JST確認。https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/enabling-or-disabling-cloud-and-local-sandboxes-for-your-organization
- GitHub Docs, Billing for cloud and local sandboxes for GitHub Copilot, 2026年6月5日JST確認。https://docs.github.com/en/billing/concepts/product-billing/cloud-and-local-sandboxes
- GitHub Changelog, Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input, 2026年6月2日発表、2026年6月5日JST確認。https://github.blog/changelog/2026-06-02-copilot-cli-improved-ui-rubber-duck-prompt-scheduling-and-voice-input/
更新履歴
2026年6月5日 JSTにGitHub公式ChangelogとGitHub Docsを確認しました。
public preview、対象範囲、組織有効化、課金単価、2026年6月のpreview entitlementを整理しました。
GitHubのDocsや料金説明が変わる可能性があります。
public previewの仕様、課金、組織設定は確認日を残して読む。
- 2026年6月5日 JST: GitHub公式ChangelogとGitHub Docsを確認し、public preview、対象範囲、組織有効化、課金単価、2026年6月のpreview entitlementを整理しました。