AIがコードを書く時代になりました。Claude、ChatGPT、Gemini、Codex は、簡単なWebサービスなら数分で作ってしまいます。 しかし、実際にサービスを運用した経験のある人なら、あることをよく知っています。 サービスはコードを作って終わりではなく、運用が始まってからが本当のスタートです。 なぜ多くのAIサービスは「リリース」で止まってしまうのか？ 多くの人がAIにこう頼みます。 ECサイトを作って 予約システムを作って 顧客管理システムを作って AIは驚くほどの速さでプログラムを作ります。ところが、いざ実際に公開しようとすると、やるべきことが一気に増えます。 サーバーはどこにデプロイする？ データベースはどう作る？ SSL証明書は？ ドメインは？ CDNは？ ロードバランサーは？ バックアップは？ 障害が起きたら？ セキュリティは？ ログはどこで見る？ コストはどう下げる？ ここからは開発ではなく インフラ運用 の領域です。まさにこの地点で、多くのプロジェクトがリリース直前に止まってしまいます。 AIコーディングツールが解決したのは「作る速さ」であり、まだ残っているのは 「運用可能な状態までの距離」 です。 インフラを人が手作業で作る時代は終わりつつある 以前はインフラエンジニアがサーバーを一台ずつ構築していました。しかし現在、AWS・Azure・GCP では、ほとんどのインフラを コードで定義（Infrastructure as Code, IaC） できます。 例えば Webサーバー3台 データベース2台 ロードバランサー ファイアウォール モニタリング これらすべてを、人がコンソールでクリックするのではなく コードを一度実行するだけで自動生成 します。Terraform、Kubernetes、GitOps といった手法は、すでに現代のクラウド運用の標準になっています。 つまり、 インフラはもはや手作業ではなく、自動生成されるソフトウェア になりつつあります。 それでもなぜインフラの専門家が必要なのか？ 自動で作れるからといって、「どう作るべきか」がわかるわけではありません。 自動車を自動組み立てする工場があっても、 設計図が間違っていれば、間違った自動車...
Kimi K3が登場するや、見慣れた光景が繰り返されました。2025年初頭にDeepSeek R1が「少ないリソースでGPT級」を掲げたときと同じく、「もうGPUもHBMも要らなくなる」という論調が再び流れ始めたのです。今回の引き金はKimi K3が採用した**KDA(Kimi Delta Attention)**という線形アテンション系の構造。KVキャッシュ負荷を大きく減らす点から「メモリ・ネットワーキング需要が鈍る」という解釈が出ました。 ところが実際に精査すると、結論はむしろ逆に近い。本記事はKimi K3を巡る論点を整理し、 何が検証済みの事実で、何がまだ議論中の解釈か を区別したうえで、「では自分はこれを実際に使う価値があるのか」を自ら判断できるようにまとめます。 まず事実関係:Kimi K3とは何か 議論の前に確認可能なスペックを整理します(以下はMoonshot AIの公開資料と複数メディア報道で相互確認できる範囲)。 公開日 : 2026年7月16日、Moonshot AIがKimi K3を公開。全重み(open weights)は7月27日頃に公開予定(Modified MIT系ライセンス)。 規模 : 総パラメータ約**2.8兆(2.8T)**のMoE(Mixture of Experts)モデル。世界初の「オープン2.8T級」として紹介。 エキスパート構成 : 全 896エキスパート のうちトークンあたり少数(約16個)のみを活性化するsparse構造。 KDA(Kimi Delta Attention) : 線形アテンション系。線形3層+フルアテンション1層を 3:1比率 で交互配置し、局所文脈は安価に、大域情報はフルアテンションが保持。百万トークン域でデコード速度を数倍改善と主張。 コンテキスト : 最大 100万(1M)トークン 、ネイティブ・ビジョン(画像理解)対応。 ここまでは「論争」ではなく「スペック」です。問題はここから ハードウェア需要の方向をどう推論するか です。 論点の核心:「線形アテンション=半導体の悪材料」という誤解 パニック論法はシンプルです。 KDAがKVキャッシュを減らす → 推論に必要なメモリ・帯域が減る → NVIDIA・HBM・DRAM・ネットワーキング需要が鈍る。 KVキ...