GitHub Copilot Business／Enterpriseで「Kimi K2.7 Code」が利用可能になりました。ただし、既存環境のモデルが自動的にKimiへ切り替わる更新ではありません。BusinessとEnterpriseでは初期状態で無効になっており、管理者がモデルポリシーを許可し、利用者がモデルピッカーから選択した場合にのみ使用されます。Kimiを利用しない組織であれば、緊急のコード修正や設定変更は不要です。(The GitHub Blog)
対応を検討すべきなのは、コストを抑えながらコーディングエージェントを試したい組織、オープンウェイトモデルの利用可否を判断する管理者、または「モデル一覧にKimiが表示されない」という問い合わせを受けている担当者です。
この記事では、Kimi K2.7 Codeの仕様、既存のGitHub Copilot環境への影響、利用条件、有効化手順、導入テストで確認すべきポイントを整理します。
結論：Kimi K2.7を使わない組織に緊急対応は不要
GitHub Copilot Business／Enterpriseの管理者は、まず自社がKimi K2.7を利用する必要があるかを判断します。
| 組織の状況 | 推奨する対応 | 対応の緊急度 |
|---|---|---|
| Kimi K2.7を利用する予定がない | ポリシーを無効のまま維持する | 低い |
| コストを抑えたAIモデルを比較したい | 限定した組織でパイロット運用する | 中程度 |
| AIエージェントによる複数ファイル編集を試したい | 既存モデルとのA/Bテストを行う | 中程度 |
| データ保管地域やオープンウェイトモデルに厳しい基準がある | セキュリティ、法務、データガバナンス部門の承認まで無効にする | 高い |
| 利用者にKimiが表示されない | エンタープライズと組織のポリシー、クライアント、ライセンスを確認する | 問い合わせ発生時 |
| 全社員へすぐ展開したい | 先に予算上限、監査方法、停止条件を決める | 高い |
特に重要なのは、一般提供されたモデルであっても、Business／Enterpriseでは自動的に有効にならない点です。「GAだから安全審査済みで、そのまま全社展開できる」とは限りません。
Kimi K2.7の追加で何が変わったのか
GitHubは2026年7月1日、Kimi K2.7 CodeをCopilot Pro、Pro+、Max向けに段階的に展開すると発表しました。その後、2026年7月7日付の公式Changelogで、Copilot BusinessとCopilot Enterpriseでも利用可能になったことを案内しています。指定された更新を7月8日付として扱う場合でも、公式ページ上の掲載日は7月7日です。(The GitHub Blog)
今回の変更点は、主に次のとおりです。
| 項目 | 更新前 | 更新後 |
|---|---|---|
| Business／Enterpriseでの利用 | 利用不可 | 管理者が許可すれば利用可能 |
| 初期設定 | 対象外 | 無効 |
| 利用者による選択 | 不可 | モデルピッカーから選択可能 |
| 既存の選択モデル | 変更なし | 自動変更なし |
| インラインコード補完 | 影響なし | Kimiの選択とは別に動作 |
| 課金 | 対象外 | トークン量に応じてAIクレジットを消費 |
| 実行基盤 | 対象外 | GitHubが管理する米国のMicrosoft Azure基盤 |
| 管理策 | 不要 | モデルポリシー、予算、監査の設定が必要 |
Kimi K2.7は自動的に選ばれるモデルではない
2026年7月11日時点の公式ドキュメントでは、Kimi K2.7 Codeは「Auto model selection」の対象モデル一覧に含まれていません。
そのため、管理者がKimiを有効にしても、Autoを利用しているユーザーのリクエストが自動的にKimiへ振り分けられるわけではありません。利用者がモデルピッカーでKimiを明示的に選択する必要があります。(GitHub Docs)
将来、Autoの対象モデルは変更される可能性があります。運用ルールに「AutoならKimiは使われない」と固定的に書くのではなく、定期的に公式の対象モデル一覧を確認するのが安全です。
チャットモデルを変えてもインライン補完は変わらない
GitHub Copilot ChatでKimi K2.7を選択しても、エディター上で表示されるインラインコード補完やNext Edit SuggestionsのモデルがKimiに切り替わるわけではありません。
チャット、エージェント、インライン補完は、同じGitHub Copilotの機能でもモデルの選択範囲や課金方式が異なります。既存のコード補完品質が突然変わることを心配して、Kimiのポリシーを一律に拒否する必要はありません。(GitHub Docs)
Kimi K2.7 Codeの仕様と実務上の位置づけ
Kimi K2.7 Codeは、Moonshot AIが開発したオープンウェイトのコーディングモデルです。GitHub Copilotでは一般提供モデルとして扱われ、GitHubのモデルピッカーで選択できる初のオープンウェイトモデルとされています。(The GitHub Blog)
主な仕様と、導入時に考慮すべき点を整理すると次のようになります。
| 項目 | 仕様・位置づけ | 実務上の注意点 |
|---|---|---|
| 提供状態 | GA、一般提供 | GAでもBusiness／Enterpriseでは初期状態が無効 |
| モデル種別 | オープンウェイト | 自社サーバーで実行されるわけではない |
| 想定用途 | 一般的なコーディング、エージェントタスク | 日常的な実装や複数ステップ作業の比較候補 |
| 実行基盤 | GitHub管理の米国Azure基盤 | データ処理地域に制約がある組織は要確認 |
| モデル開発元への送信 | プロンプトと応答はMoonshot AIへ送信されない | GitHubとMicrosoftの基盤上では処理される |
| モデル側のコンテキスト仕様 | 256Kトークン | Copilotで常に256Kを使えるとは限らない |
| 課金 | 入出力トークンに応じたAIクレジット | エージェントの反復回数が多いと消費が増える |
| 安全対策 | GitHubのコンテンツフィルターを適用 | 自社のレビューやセキュリティ検査は必要 |
GitHubはKimi K2.7を、一般的なコーディングやエージェントタスクに適したモデルとして案内しています。一方、Moonshot AIのモデルカードでは、長時間にわたるコーディング作業を重視し、K2.6と比べて思考トークンを約30％削減したと説明しています。ただし、これは開発元による評価です。実際のリポジトリやCopilotのツール連携環境で、同じ結果になるとは限りません。(GitHub Docs)
256Kコンテキストを前提に設計しない
モデルカードでは256Kトークンのコンテキストが示されていますが、GitHubはCopilot統合時に利用できる実効コンテキスト量を明示していません。
Copilotでは、ユーザーのプロンプト以外にも、システム指示、リポジトリ情報、開いているファイル、会話履歴、ツール実行結果などがコンテキストに含まれます。そのため、次のような判断は避けるべきです。
- 256K以内ならリポジトリ全体を必ず理解できる
- 大量の仕様書を一度に渡しても情報が欠落しない
- 既存モデルより常に長いコードを正確に扱える
大規模リポジトリで利用する場合は、対象ディレクトリや関連ファイルを明示し、処理対象を段階的に分けたほうが安定します。
オープンウェイトでもローカル実行ではない
「オープンウェイト」と聞くと、自社環境内でモデルが動作する、またはソースコードが外部基盤へ送信されないと考えがちです。
GitHub Copilot上のKimi K2.7は、GitHubとMicrosoftが管理する米国のAzure AI Foundry基盤でホストされます。ユーザーのプロンプトや応答はMoonshot AIには送信されませんが、ローカル推論やオンプレミス実行ではありません。(GitHub Docs)
次の条件がある組織は、有効化前にデータガバナンス部門へ確認してください。
- ソースコードを特定の国や地域外で処理できない
- 未公開製品のコードを外部AIサービスへ入力できない
- 個人情報や顧客データを含むリポジトリを扱う
- オープンウェイトモデルに独自の承認手続きがある
- AI生成コードに追加のレビューや記録が必要になる
またGitHubは、オープンウェイトモデルについて、クローズドモデルより安全性の調整が弱い場合があり、有害または不適切な出力のリスクが高まる可能性を案内しています。GitHub側のフィルターは適用されますが、自社のコードレビュー、静的解析、秘密情報検出を省略できるわけではありません。(GitHub Docs)
Kimi K2.7の料金とAIクレジット消費
2026年7月11日時点で、Kimi K2.7 Codeの公開単価は次のとおりです。
| トークン種別 | 100万トークン当たりの料金 |
|---|---|
| 入力 | 0.95米ドル |
| キャッシュ済み入力 | 0.19米ドル |
| 出力 | 4.00米ドル |
GitHubでは1 AIクレジットを0.01米ドルとして計算します。例えば、キャッシュを考慮せずに2万入力トークンと5,000出力トークンを使用した場合、公開単価だけで計算した料金は約0.039米ドル、約3.9 AIクレジットです。
実際の消費量は、モデルへ送信されるコンテキスト、キャッシュの利用状況、エージェントの反復処理、ツールの実行回数などによって変わります。(GitHub Docs)
Kimi K2.7はGitHubから低コストの選択肢として案内されていますが、すべてのCopilotモデルの中で常に最安という意味ではありません。単価だけで決めず、次の3点を同時に比較する必要があります。
- 1回のタスクを完了するまでのトークン量
- 修正や再生成が必要になる回数
- 人間による確認と手直しにかかる時間
単価が低くても、指示のやり直しが増えれば、最終的なコストや作業時間は高くなります。
BusinessとEnterpriseではクレジットが共有される
Copilot Business／EnterpriseのAIクレジットは、請求単位でプールされます。そのため、一部の利用者がエージェント処理を大量に実行すると、他の利用者が使えるクレジットに影響する可能性があります。(GitHub Docs)
全社展開する前に、最低限次の管理策を用意してください。
- 月間予算と追加利用の上限を設定する
- モデル別、組織別、利用者別に消費量を確認する
- エージェントの長時間実行を監視する
- 予算到達時に通知だけ行うのか、利用を停止するのかを決める
- 予算超過時の問い合わせ先を明確にする
予算額を設定しただけでは、必ずしも利用が停止するとは限りません。ハードストップを必要とする場合は、上限到達時に利用を停止する設定が有効になっているかも確認します。(GitHub Docs)
既存のGitHub Copilot環境との互換性
Kimi K2.7を有効化するために、通常はリポジトリのソースコード、GitHub Actions、CI/CD、拡張機能向けAPIを変更する必要はありません。変更対象は、主にGitHub Copilotのモデルポリシーと利用者のモデル選択です。
ただし、すべてのクライアントで同時に利用できるわけではありません。
現在の対応クライアント
2026年7月11日時点のGitHub公式ドキュメント上の対応状況は次のとおりです。
| クライアント | 対応状況 | 導入時の確認 |
|---|---|---|
| GitHub.com | 対応 | チャットのモデルピッカーを確認 |
| Copilot CLI | 対応 | CLIを最新版へ更新 |
| Visual Studio Code | 対応 | VS CodeとCopilot拡張機能を更新 |
| Visual Studio | 対応 | Visual Studioを更新 |
| JetBrains IDEs | 対応 | Copilotプラグインを更新 |
| Xcode | 現行のサポート定義では未対応 | モデルが表示されるまで展開を待つ |
| Eclipse | 現行のサポート定義では未対応 | モデルが表示されるまで展開を待つ |
GitHubの初回ロールアウト告知では、VS Code 1.127以降、Visual Studio 17.14.6以降、JetBrains向けCopilotプラグイン1.9.1-251以降が案内されていました。一方、現在のドキュメントではKimi固有の最低バージョンを固定しておらず、最新バージョンの利用が推奨されています。初回告知の数字を「このバージョンなら必ず表示される」という保証として扱わないでください。(The GitHub Blog)
また、初回告知では展開先としてXcodeやEclipseにも言及されていましたが、現在の公式サポート定義では両クライアントが未対応になっています。段階的なロールアウトでは、告知時の予定と実際の提供時期がずれることがあります。管理者は告知文だけでなく、最新の対応表と実際のモデルピッカーを確認する必要があります。(GitHub)
Copilot Extensionsでは選択モデルが使われない場合がある
GitHub Copilot Extensionsや一部の連携機能は、拡張機能側が使用モデルを指定する場合があります。その場合、利用者がチャット画面でKimi K2.7を選択していても、拡張機能の処理には別のモデルが使われる可能性があります。(GitHub Docs)
テストでは、通常のCopilot Chat、エージェントモード、Copilot Extensionsを分けて評価してください。
Kimi K2.7を有効化するための条件
Kimi K2.7を利用するには、次の条件を満たす必要があります。
| 条件 | 確認内容 |
|---|---|
| 対象プラン | GitHub Copilot BusinessまたはEnterpriseを利用している |
| ライセンス | テスト利用者にCopilotのシートが割り当てられている |
| 管理権限 | 組織所有者またはエンタープライズ所有者が設定できる |
| エンタープライズポリシー | 組織側でKimiを許可できる状態になっている |
| モデルポリシー | Kimi K2.7 Codeが有効になっている |
| クライアント | 対応クライアントの最新版を使用している |
| AIクレジット | 利用可能なクレジットまたは追加利用予算がある |
エンタープライズ側でモデル利用を明示的に禁止している場合、組織管理者が独自に許可することはできません。「組織の設定画面では有効にしたのに表示されない」というときは、最初に上位のエンタープライズポリシーを確認します。(GitHub Docs)
Kimi K2.7を安全に有効化する手順
セキュリティとデータガバナンスを確認する
有効化前に、次の情報を社内のセキュリティ、法務、データ管理担当者へ共有します。
- オープンウェイトモデルであること
- GitHub管理の米国Azure基盤で処理されること
- プロンプトと応答はMoonshot AIへ送信されないこと
- GitHubのコンテンツフィルターが適用されること
- AI生成コードには誤りや脆弱性が含まれる可能性があること
- トークン量に応じてAIクレジットを消費すること
承認条件を「利用可能なリポジトリ」「入力できない情報」「必須レビュー」「ログ保存期間」まで具体化しておくと、展開後の判断がぶれにくくなります。
エンタープライズ側でモデルを許可する
エンタープライズでモデルを一元管理している場合は、エンタープライズ設定のAI controlsからCopilotのモデル設定を開き、Kimi K2.7 Codeを許可します。
管理方式によっては、すべての組織で有効にするほか、各組織に判断を委ねたり、対象組織を限定したルールを作成したりできます。パイロットでは、全社有効化ではなくテスト用組織だけを対象にする方法が安全です。(GitHub Docs)
組織側でKimi K2.7を有効にする
組織所有者は、組織の設定からCopilotのモデル管理画面を開き、Kimi K2.7 Codeのポリシーを有効にします。
画面構成は更新される可能性がありますが、基本的な確認経路は次のとおりです。
- 対象のOrganizationを開く
- Settingsを開く
- Copilotの管理項目を開く
- Modelsまたはモデルポリシーを開く
- Kimi K2.7 Codeを有効にする
- 設定を保存する
設定項目を変更できない場合は、上位エンタープライズのポリシーで固定されている可能性があります。(GitHub Docs)
テスト利用者の環境を更新する
テスト対象者には、利用するIDE、Copilot拡張機能、CLIを最新版へ更新してもらいます。
更新後もモデルが表示されない場合は、次の順番で確認すると原因を切り分けやすくなります。
- Copilotライセンスが割り当てられているか
- 正しいGitHubアカウントでサインインしているか
- 対象組織のメンバーとして認識されているか
- エンタープライズポリシーで許可されているか
- 組織ポリシーでKimiが有効になっているか
- 使用中のクライアントが対応しているか
- IDEや拡張機能が最新版か
- 一度サインアウトし、再度サインインして表示が更新されるか
複数の組織からCopilotライセンスを割り当てられている利用者は、想定とは異なる組織のポリシーが適用されていないかも確認してください。
利用者がモデルピッカーから選択する
管理者が許可した後、利用者はCopilot Chatなどのモデルピッカーを開き、Kimi K2.7 Codeを選択します。
有効化しただけでは、既存の会話やAuto設定が自動的にKimiへ変更されるわけではありません。テスト担当者には、使用モデルを毎回記録してもらうと評価の取り違えを防げます。
導入テストで確認すべき項目
Kimi K2.7の評価では、簡単なコード生成を1回試すだけでは不十分です。実際の開発フローに近い作業を使い、現在利用しているモデルと同じ条件で比較します。
推奨するテストケース
| 評価項目 | テスト例 | 合格基準の例 |
|---|---|---|
| 短いコード生成 | バリデーション関数や変換処理を実装する | 要件を満たし、テストが通る |
| 既存コードの修正 | 不具合の再現テストを追加して修正する | 原因と変更理由を説明できる |
| 複数ファイル編集 | API、サービス、テストを同時に変更する | 不要なファイルを変更しない |
| リファクタリング | 重複処理を共通化する | 外部仕様と既存テストを維持する |
| テスト生成 | 正常系、異常系、境界値のテストを作る | 形式的なテストだけで終わらない |
| ライブラリ利用 | 社内標準または指定バージョンで実装する | 存在しないAPIを生成しない |
| 日本語の指示理解 | 日本語の仕様書から変更する | 曖昧な条件を勝手に確定しない |
| セキュリティ | 認証、入力検証、秘密情報を含む処理を確認する | 既知の危険な実装を提案しない |
| エージェント処理 | 調査、修正、テストまで連続実行する | 権限外の操作や無関係な変更をしない |
| コスト | タスク完了までのクレジットを記録する | 現行モデルより費用対効果が高い |
| 所要時間 | 指示開始からレビュー完了まで計測する | 人間の手直しを含めて短縮できる |
同じ条件でA/Bテストする
モデル比較では、次の条件をそろえます。
- 同じリポジトリと同じコミットを使用する
- 同じプロンプトを使用する
- 同じファイルを開いた状態にする
- 同じCopilotモードを使用する
- 同じツール権限を与える
- IDEと拡張機能のバージョンをそろえる
- 生成結果だけでなく最終的な差分を比較する
AIモデルの出力にはばらつきがあります。重要なテストは3〜5回程度繰り返し、最良の1回ではなく、失敗率や手直し量の分布で評価します。
評価記録に残す項目
最低限、次の情報を記録してください。
| 記録項目 | 内容 |
|---|---|
| 利用モデル | Kimi K2.7 Code、比較対象モデル |
| 実行日時 | モデル更新やクライアント更新との関係を確認する |
| クライアント | VS Code、Visual Studio、CLIなど |
| クライアントのバージョン | 再現性を確保する |
| 利用モード | Ask、Edit、Agentなど |
| プロンプト | 再テストできる形で保存する |
| 変更ファイル | 意図しない変更を確認する |
| テスト結果 | 成功、失敗、追加修正の内容 |
| 人間の修正時間 | 実際の生産性を比較する |
| AIクレジット | タスク単位のコストを比較する |
| 問題点 | ハルシネーション、過剰変更、権限外操作など |
GitHubのパイロット運用ガイドでは、コストや利用状況まで評価する場合、少なくとも1回の請求サイクル、一般的には4〜6週間程度の試行が推奨されています。短期間の技術確認だけで全社導入を決めず、実際の利用頻度と費用を確認してください。(GitHub Docs)
テスト時に注意したい失敗パターン
1回の成功だけで採用を決める
簡単な関数を正しく生成できても、複数ファイルの変更、依存関係の更新、エラー処理、既存仕様の維持が得意とは限りません。
採用判断では、成功例よりも次の失敗を重点的に確認します。
- 存在しないAPIや設定値を作る
- 指定していない依存ライブラリを追加する
- 既存の公開インターフェースを変更する
- テストを通すために検証処理を削除する
- 関係のないファイルまで書き換える
- エラーを握りつぶす
- 秘密情報をコードへ埋め込む
- 問題を修正せず、テスト側を弱くする
生成された説明だけを評価する
AIが「修正しました」「すべてのテストに成功しました」と説明しても、その文章を根拠に採用してはいけません。
確認すべき対象は、実際のGit差分、テストログ、静的解析結果、依存関係、セキュリティスキャンです。特にエージェントモードでは、最終回答より途中で行った操作を確認してください。
本番データや秘密情報で試す
モデルのデータ処理を確認する目的でも、APIキー、顧客情報、本番データ、未公開の認証情報をテストプロンプトへ入力してはいけません。
代表性のあるダミーデータや、社内でAI利用を許可されたリポジトリを使用します。秘密情報を含む可能性がある場合は、シークレットスキャンやDLPの検知結果もテスト項目に含めてください。
Autoを選べばKimiが使われると思い込む
Kimiを許可しても、現在のAuto対象一覧に含まれていなければ自動選択されません。
Kimiの品質や費用を評価する担当者には、モデルピッカーでKimi K2.7 Codeを選択したことを毎回確認してもらいます。モデル名を記録していないテスト結果は、比較対象から外したほうが安全です。
予算設定だけで利用が止まると思い込む
予算には、通知を目的とする設定と、上限到達時に利用を止める設定があります。予算額を入力しただけでハードストップになるとは限りません。
また、利用可能なクレジットを使い切った際に、自動的に別の安いモデルへ切り替わるとは限りません。追加利用が禁止されていれば、リクエストがブロックされる可能性があります。(GitHub Docs)
256KコンテキストをそのままCopilotの上限と考える
モデル本体の公開コンテキスト長と、GitHub Copilotが実際にモデルへ渡す情報量は同じとは限りません。
大量のファイルを一度に参照させるのではなく、変更対象、関連モジュール、受け入れ条件を明示します。重要な仕様はプロンプト内で再提示し、モデルが暗黙に理解していることを前提にしないでください。
Kimi K2.7への対応が必要か判断するチェックポイント
次の項目に当てはまる組織は、限定的なパイロットを検討する価値があります。
- コーディングエージェントの利用コストを比較したい
- 現在のモデルとは異なる選択肢を用意したい
- 複数ファイルを扱う自動修正を増やしたい
- 特定のモデルへの依存を減らしたい
- AIクレジットの費用対効果を検証したい
- オープンウェイトモデルを社内で評価したい
一方、次の状態では全社展開を急ぐべきではありません。
- AIモデルの利用基準が決まっていない
- 米国のクラウド基盤での処理を許可できない
- 予算上限や利用停止条件を設定していない
- AI生成コードのレビュー責任者が決まっていない
- 監査ログや利用状況を確認する担当者がいない
- 本番リポジトリでしかテストできない
- エージェントへ与える権限を制限していない
Kimi K2.7は、すべての既存モデルを置き換える更新ではありません。既存モデルを維持しながら、特定の用途で費用、品質、速度を比較するための新しい選択肢です。
まとめ：無効のまま審査し、限定組織から試す
GitHub Copilot Business／EnterpriseにKimi K2.7 Codeが追加されても、既存のCopilot環境が自動的に変更されることはありません。管理者がモデルポリシーを有効にし、利用者が明示的に選択した場合にのみ使用されます。
導入する場合は、次の順番で進めます。
- データ処理地域とオープンウェイトモデルの社内基準を確認する
- エンタープライズと組織のモデルポリシーを確認する
- テスト用組織だけでKimi K2.7を許可する
- クライアントを更新し、既存モデルと同じ条件で比較する
- 品質、手直し時間、セキュリティ、AIクレジットを記録する
- 予算のハードストップと監査方法を確認する
- 合格条件を満たした場合だけ段階的に対象を広げる
利用予定がなければ、初期設定のまま無効にして問題ありません。利用価値がありそうな場合も、いきなり全社へ展開せず、代表的な開発タスクを使ったパイロットから始めることが現実的です。
コメント