Microsoft Foundry（旧Azure AI Foundry）のモデルカタログに、Moonshot AI製のコーディング特化モデル「Kimi K2.7 Code」がパブリックプレビューとして追加された。中国のAI研究機関Moonshot AIが開発したKimiシリーズの最新版で、長時間にわたる複雑なコーディングタスクをこなすことに特化したモデルだ。

Kimi K2.7 Codeの技術的な特徴

前バージョンのK2.6と比較して、Kimi K2.7 Codeは「思考トークン」（モデルが回答を生成する前に内部で使う推論用トークン）の使用量を約30%削減しながら、複数ステップにまたがる長期のコーディングタスクの成功率を高めているという。

コンテキストウィンドウは256Kトークンに達し、これは大規模なコードベース全体や複数ファイルにまたがる仕様書を一度に読み込ませるのに十分な容量だ。またマルチステップのツール呼び出し（ファイル編集、テスト実行、ビルドコマンドの実行などを連続して行う「エージェント的」な動作）にも対応しており、コーディングエージェントの裏側モデルとして使うことを想定している。

Microsoft Foundryは、Azure OpenAIのモデル群に加えて、Meta Llama・Mistral・DeepSeek・xAI Grokなど自社製以外のモデルも一つのカタログで横断的に扱えるプラットフォームだ。今回のKimi K2.7 Code追加も、その「モデルの選択肢を増やす」路線の一環と言える。

実務への影響

日本のエンジニアやIT管理者にとって重要なのは、「新しいモデルが一つ増えた」という以上に、そのモデルをどこで、どう安全に使うかという点だ。

Foundry経由でKimi K2.7 Codeを使う最大のメリットは、Microsoft Entra IDによるアクセス制御や監査ログ、データ処理リージョンの指定といったガバナンス機能をそのまま適用できることにある。Moonshot AIは中国のAI企業であり、モデル単体を個人契約のAPIキーで直接呼び出すと、データの取り扱いやコンプライアンス上の説明責任があいまいになりがちだ。Foundryのカタログ経由であれば、企業のセキュリティポリシーの枠内でモデルを評価・利用できる。

長時間コーディングタスクでの思考トークン削減は、そのままAPIコストの削減に直結する。エージェント型のコーディング支援を業務で使っているチームは、既存のワークフローの中でKimi K2.7 Codeをベンチマークし、コスト対効果を検証する価値がある。256Kの大きなコンテキストウィンドウは、モノレポや大規模プロジェクトでの活用にも向いている。

筆者の見解

今回の件で興味深いのは、モデル単体の性能競争ではなく、Microsoft Foundryという「基盤」の戦略の方だ。マイクロソフトは最先端のAIモデルを自社だけで作り切る競争では必ずしも先頭を走っていない。しかし、Entra IDによるガバナンスの下で多種多様なモデルを安全に選べる場を用意する競争では、むしろ有利な立場にいる。

エンジニアが「このタスクにはこのモデルが速い・安い」と気づいたとき、会社のセキュリティポリシーの外側でこっそりAPIキーを契約して使ってしまう、いわゆるシャドーAIが一番のリスクだ。禁止で対処しようとすると必ず抜け道が生まれる。今回のようにFoundryのカタログへ正式に追加し、IT管理者が許可した範囲で使える状態を作ることこそが、現実的な解決策だと考える。

正直なところ、Windows・Azure・M365のアップデートを一つひとつ逐一追いかける意味は薄れてきている。大事なのは個別モデルのスペック表を追い回すことではなく、Foundryという土台を活かして「使えるAIを選べる自由」をどう業務に落とし込むかだ。マイクロソフトには、Entra IDを軸にした管制塔としての役割を今後も伸ばしてほしい。基盤を作る力は間違いなくあるのだから、そこを正面から伸ばしていくべきだと思う。

出典: この記事は Introducing Kimi K2.7 Code in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。