強いモデルの次に来るもの——推論インフラ、インタラクション、責任の線引き

Kimi K3が48時間で新規停止——推論キャパシティの壁

Moonshot AIがKimi K3をリリースしてから、わずか48時間で新規サブスクリプションを停止した。需要がGPUキャパシティの限界に達したためだ。既存ユーザーはそのままアクセスでき、インフラ拡張後に段階的に再開される見込み。

K3は2.8兆パラメータのオープンウェイトモデルで、7月27日にウェイトが公開される予定。Arena.aiのFrontend Code ArenaではGPT-5.6 SolやClaude Fable 5を上回り、Artificial Analysis Intelligence Indexでも57点と健闘している。価格も入力100万トークン3ドル、出力15ドルで、Opus 4.8より約40%安い。

強くて安いモデルを出せば、使う側は飛びつく。当然の話だ。でも「使う側が飛びつく」というのは、推論インフラにとってはただの流量増大として襲ってくる。特にコーディングやエージェント系のタスクは、1回の質問で終わらない。トークンを生成し、読み込み、また生成する。GPUを長時間占有する。Citigroupのアナリストも指摘している通り、推論コストが下がれば「より多くのリソースを消費する」方向に再変換される。ボトルネックは計算からメモリにシフトしていく。

この構造は、中国の特殊な事情でさらにきつくなっている。米国の輸出規制でNvidiaの最新チップが手に入らない。Moonshotは旧世代チップと国産代替の組み合わせで回しているらしい。ソフトウェアの最適化でカバーするしかない状況だ。アリババが3年で530億ドル超、ByteDanceが今年700億ドルをAIインフラに投じるという話も、この逼迫感の裏返しだろう。

開発者にとっての教訓は単純。「安くて強いAPIが無限に使える」という前提で設計してはいけない。K3のケースを見れば明らかだ。フロントランナーのモデル層が90%の推論マージンを取る世界は開発者にとって悪いが、かといって安いモデルに殺到してもインフラが追いつかない。レート制限もサブスクリプション停止も、プロバイダー側の防衛線だ。

自分がAPIを前提にシステムを組むとき、この辺りのリスクをどう吸収するか。フォールバック先のモデルを複数持つのか、キューイングで遅延を受け入れるのか。推論の安定供給がモデル開発と同じくらい難しい、という事実をインフラの設計に組み込んでおかないと、いざという時に止まる。

AIエージェントを並行で回せるようになったAndroid Studio Quail 2

Android Studio Quail 2がstableになった。一番の変化はAgent Modeの再設計だ。これまで1つのタスクが終わるまで次の指示を出せなかったのが、複数のAI会話を同時に並走させられるようになった。UIのリファクタリングをタブAで走らせつつ、タブBでProGuardルールを直し、タブCでドキュメントを生成する。そんな使い方ができる。

なぜこれが重要かというと、エージェントの待ち時間がボトルネックだったからだ。コード生成に30秒かかるとして、その間に別の作業を止めるのは苦痛だった。並行会話ができることで、エージェントへの指示出しが非同期の作業になる。開発者の待ち時間が減る。単純に。

もう一つ面白いのが、Gemini以外のLLMもAgent Modeで使える点だ。どのモデルが何に向いているか。それを測るためにGoogleはAndroid Benchというベンチマークを用意した。権限、ナビゲーション、接続性など、Android開発の一般的なタスクでモデルを評価する。モデル選びの判断材料が公式に提供されたことになる。どのモデルがProGuardルールの修正に強いか。ドキュメント生成はどれが速いか。そういうデータがベースになるのは歓迎すべきことだ。

デバッグ周りも変わる。LeakCanaryがIDEに統合された。ヒープ解析をテスト端末から開発機にオフロードする仕組みで、リーク検出が最大5倍速くなったという。検出後は該当コード行にジャンプでき、Agent Modeで修正を提案させることも可能だ。App Quality Insightsも完全統合された。クラッシュ時のスタックトレース、端末データ、ソースコードを統合して原因を特定し、段階的な修正プランを提示してくれる。

気になるのはStudio Labsのstable化だ。実験的AI機能をIDEのアップグレードなしで試せる仕組み。これは新しい機能を試す心理的ハードルを下げる。ただ、どの機能がいつ本番に入るのか。実務でどこまで頼っていいか。その線引きが今後の鍵になりそうだ。

エアギャップでAIを回す——MicrosoftとMistralが組む主権インフラの実務的意味

MicrosoftとMistralが数十億ドル規模の提携を深化させた。目玉は欧州の主権コンピュートインフラだ。Mistralが展開する欧州運営のインフラを、Microsoftが自社の従来データセンターとは別の選択肢として顧客に提供する。Mistral側はNVIDIAの次世代Vera Rubin GPUを数千基デプロイし、モデル学習からマルチエージェントワークロードまでを支える構えだ。NVIDIAの主張によれば、Vera RubinはGrace Blackwell世代と比べてエージェントのスループットを最大10倍引き上げるという。

モデル層でも動きがある。Mistral Medium 3.5とMistral OCR 4がMicrosoft Foundryで利用可能になった。Medium 3.5は128Bパラメータ、256Kトークンのコンテキストウィンドウを持つオープンウェイトモデル。長文ドキュメントや長時間の対話を扱う用途に向いていると読める。OCR 4は170言語のドキュメントを処理し、ページレイアウトの構造やバウンディングボックス、信頼度を保持する。ドキュメント中心のAIワークフローでは悪くないスペックだ。

個人的に注目しているのはアーキテクチャの対称性だ。Microsoft Foundryでアプリを構築・テストし、そのワークロードをパブリックAzure、Azure Local、Mistral運営の主権インフラのいずれに移しても、下回りのワークフローをリファクタリングしなくて済む。Kubernetesでいうマニフェストの移植性に近い感覚。規制産業のエンジニアが一番頭を抱えるのは、クラウドで動いたものをオンプレやエアギャップ環境に持っていくときの再設計コストだ。それが実質ゼロになるなら、デプロイ先の選択肢が増える以上の意味を持つ。

完全なエアギャップ環境でのAIワークロード稼働も選択肢に入った。パブリックインターネットから完全に隔離されたネットワークでAIを回す需要は、金融や防衛で以前からあった。ただし実装の細目——容量配分やロールアウト時期——は公開されていない。どこまで実用段階かは今後の提供形態を待つ必要がある。

Microsoftが自社で完全に所有しないAIスタックをあえて組む理由は、US CLOUD Actへの警戒が欧州企業にあるからだ。

（US CLOUD Actは、米国の法執行機関が米国プロバイダーに対し、データが海外に保存されていても提供を強制できる法律である）米国本社のプロバイダーがどこまでデータを米法権力から守れるかは、法的に争点のままだ。その隙間をMistralという欧州ベンダーが埋める構図。ただし、これで本当に主権が担保されるのかは、実装と運用次第だろう。

デプロイの柔軟性が買い手の判断基準になりつつある。モデルの性能だけでなく、どこでどう動かすかが選択の軸になる。もしMicrosoftの戦略が噛めば、世界で最も規制の厳しい産業のAI実行を制御するコントロールプレーンを握ることになる。インフラエンジニアの視点では、ワークロードの移植性を前提に設計できるかどうかが、次のフェーズの分かれ目になるかもしれない。

エージェントの発言に「署名」をつけるワークスペース

BlockがBuzzをローンチした。無料のオープンソースで、Apache 2.0ライセンス。人間とAIエージェントが同じチャンネルで協働するSlack的なワークスペースだ。

ここで面白いのは、UIでも機能でもない。エージェントの「身分証」だ。BuzzはNostrプロトコルの上に構築されている。

（Nostrは、中央サーバーを介さず公開鍵をIDとして通信する分散型プロトコルである）Nostrでは参加者が公開鍵・秘密鍵のペアで識別される。Buzzはこの仕組みをエージェントにまで拡張した。エージェントが自身の鍵ペアを持つ。そして、その鍵に対して人間のオーナーが二つ目の署名を付与する。「このエージェントは私の管理下にある」という暗号論的な証明だ。どちらか一方だけでは偽装できるが、両方の署名が揃って初めて成り立つトレイルになる。誰がどのエージェントを動かしているか、後から検証できる。

なぜこれが必要なのか。BlockのBradley Axenが指摘するのは、コーディングエージェントとのやりとりが「見えない会話」として消えている現状だ。いま、エージェントと1時間作業した結果を、自分が書いたかのようにコピペしてSlackに貼る。技術的な判断の経緯も文脈も残らない。Buzzは、その二つ目の会話を可視化する試みと言える。

エージェント接続にはAgent Client Protocol（ACP）を使う。

（ACPは、エージェントがIDEやターミナルなどのツールと共通のインターフェースで対話するための標準規格である）Zedが昨年導入したオープン標準で、コーディングエージェントを各種ツールに配線するためのもの。Claude Code、Codex、Block自身のgooseなどが繋げる。ACPをLinux FoundationのAgentic AI Foundationに持ち込む話も進んでいるらしい。標準化の動きが具体的に進んでいるのは注目に値する。

チームは自分たちのNostrリレーを立てればよく、何もBlockを経由しない。ただ、大半はホステッド版を選ぶだろうとAxenは見ている。現時点でホステッドリレーは無料。利用制限は未設定。10人のオープンソースプロジェクトなら安いが、エンタープライズ級のSlack代替になると別の料金体系が必要になる。

気になる論点が二つある。ひとつは、Nostrという選択だ。検閲耐性のある分散プロトコルとして知られるが、エンタープライズのチャット基盤として実績があるのか。チーム内コミュニケーションに分散性は必要なのか。おそらく技術的な選択というより、Dorseyの思想的な置き土産なのだろう。ただ、鍵ペアによるアイデンティティ管理という点では、Nostrの仕組みは理にかなっている。

もうひとつは、既存のSlackとの棲み分け。Block自身も社内ではSlackを使い続けている。「10年の歴史がSlackに詰まっている」とAxenも認める。AtlassianがJiraにエージェントを組み込む方向とは対照的に、Buzzは既存ツールの置き換えではなく並走を想定している。だが、コミュニケーションが二つに分れるのは、開発者の認知負荷を上げるだけかもしれない。

BuzzのGitHubリポジトリは今年前半から公開されているが、スター数は100強。gooseが50,000以上のスターを集めているのと比べると、まだまだ始まったばかり。Block自身が2月にスタッフの40%以上を削減した直後のローンチでもある。社内でBuilderBotが1日20万回の操作、週1,500のPRマージ、プロダクションコード変更の約15%を担う規模に育っているからこそ、エージェントとの会話をどう残すかが実務上の課題になっている。その答えのひとつがBuzzだ。

GitHub Copilotにcanvasesが来た。チャットの限界を越える場所

GitHub Copilotアプリでcanvas extensionsが使えるようになった。

（Canvasとは、チャット形式の1次元的なやり取りではなく、ホワイトボードのように情報を配置・編集できる2次元的なUI領域を指す）チャットでAIと対話するだけじゃなく、視覚的・対話的なワークスペース上で直接情報を操作できる仕組みだ。

これまでAIエージェントとの協働といえば、プロンプトを投げてレスポンスを受け取る往復が基本だった。単純な質問やコード生成ならそれで回る。でもバックログのトリアージや、複数ソースの情報を横断して整理する作業はどうだろう。テキストの連鎖で処理しようとすると、すぐに文脈が途切れるか、プロンプトが肥大化する。canvasesはここを解決しようとしている。

仕組みはこうだ。GitHub Copilotアプリのエージェントセッションで/create-canvasを打ち、欲しい機能を説明する。するとAIがインタラクティブなサーフェスを生成する。開発者はその上でクリック、編集、その他のアクションを通じて情報を直接操作できる。その操作はエージェントに送り返されるし、ローカルで処理されることもある。一方通行じゃない。双方向で、しかも視覚的。

記事で挙げられているユースケースはどれも実務に直結している。GitHub Issuesをカード形式でスワイプしてトリアージする例。右にスワイプすればship、左ならreject。TinderみたいなUIでバックログを捌ける。コードベースの構造をインタラクティブな図で可視化し、ノードをドラッグ・フィルタリングしながら設計を俯瞰する例。Git worktreeの一覧を見て、古いものをワンクリックで掃除する例。過去のプロンプトを分析して、より良い書き方を提案するコーチ機能。Slack、Teams、メール、ドキュメントを横断検索して、特定のファイルにコンテキストを持つ人を探す例。

マイクロサービスの構成を日々いじっている立場から見ると、この「可視化して直接操作する」方向性は筋が良い。Kubernetesのリソース関係やTerraformの依存グラフをチャットで説明されても、頭のなかで図に変換する手間がかかる。それがインタラクティブなサーフェス上でノードとして置かれ、ドラッグして関係を確認できれば、認知負荷が下がる。CI/CDパイプラインのデバッグも同様。ログをチャットで貼られるより、失敗ステップを直接クリックして原因に飛べる方が早い。

気になる点はある。生成されたcanvasの品質がプロンプト依存すぎると、結局「良いプロンプトを書く力」がボトルネックになるのではないか。プロンプトコーチのユースケースはその自覚の表れにも見える。また、canvasがローカルで処理する範囲とエージェントに戻す範囲の境界がどこで決まるのか。このあたりは実際に触ってみないと分からない。

チャットという形式が限界に達しているのは、AIを日常的に使っている人なら感覚的に知っている。長いレスポンスを読み解く疲れ、文脈を維持する苦労。canvasesはその先にある「AIと同じ画面で作業する」という方向を示している。どこまで実用になるかは、これから拡張がどう育つか次第だ。

まとめ

AIを日常的に使う開発者なら、モデルの性能がボトルネックではなくなっていることに気づいているはずだ。

Kimi K3の48時間での新規停止は、強くて安いAPIへの需要がインフラの限界に達する構造を示している。推論コストが下がれば消費が増える方向に再変換される。

開発者は「安くて強いAPIが無限に使える」という前提でシステムを組めない。フォールバック先の複数確保か、キューイングでの遅延許容か。推論の安定供給をインフラの設計に組み込まないと、いざという時に止まる。

エージェントとのインタラクションも、チャットの往復という形式に行き詰まりつつある。長いレスポンスを読む疲れや文脈の途切れを解消するため、各所でUIと協働の仕組みが問い直されている。

Android Studioの並行エージェント実行、Copilotのcanvases、Buzzの署名付きワークスペース。いずれも「エージェントとどう同じ画面で作業し、どう記録を残すか」に答えようとしている。

エージェントの発言に暗号論的な署名をつける試みは、人間とエージェントの責任の境界を可視化する第一歩だ。

デプロイの柔軟性も選択の軸になりつつある。MicrosoftとMistralの提携が示すのは、モデルの性能だけでなくどこでどう動かすかが買い手の判断基準になるという事実だ。ワークロードの移植性を前提に設計できるかどうか。規制産業でクラウドからエアギャップ環境へ移す際の再設計コストをどう抑えるか。インフラエンジニアの視点では、これが次のフェーズの分かれ目になる。

推論の安定供給、インタラクションの再設計、責任の明示、デプロイの柔軟性。これらはすべて「強いモデルを出せば勝ち」という前提の外にある。開発者が次に向き合うべきは、モデルの性能ではなく、それを実務にどう定着させるかという問いだ。

参照記事

記録日: 2026-07-22