Talk Lowy(jp)

最近、スタートアップの代表やSES営業の担当者に会うと、似たような質問を聞きます。 「開発者をこれ以上採用せずに、AIでサービスを作れないだろうか？」 「顧客プロジェクトに投入するエンジニアが足りないのに、AIが代わりにできないだろうか？」 「コードはAIが書くというが、運用人員まで減らす方法はないだろうか？」 ChatGPT、Claude、Geminiのような汎用AIは、文書作成、調査、会議のまとめといった一般的なオフィス業務を素早く処理します。Cursor、Claude Code、GitHub Copilot、DevinのようなAIコーディングエージェントは、ソースコードを分析し機能を実装し、テストやPull Requestの作成まで行います。 しかし企業が実際に必要としているのは、単に コードを書くAI ではありません。 顧客がお金を払って使えるサービスを作るには、開発の後にも次の作業が継続して必要です。 開発・ステージング・本番環境の構築 データベースとネットワークの構成 WAF、CDN、ロードバランサーとセキュリティポリシーの適用 CI/CDと本番デプロイ モニタリングと障害対応 性能チューニングとクラウドコスト最適化 承認記録、変更履歴とロールバック管理 この地点で、AIコーディングツールと AI開発・運用自動化プラットフォーム の違いが生まれます。 AI開発自動化の競合サービスはすでに存在する GIIPと比較できるサービスがまったくないわけではありません。ただし市場は大きく3種類に分かれます。 1. AIコーディングエージェント 代表的にはGitHub Copilot、Claude Code、Cursor、Devinなどがあります。 これらは既存のリポジトリを分析し、コードを修正し、テストを実行したりPull Requestを作ったりするのに強みがあります。実際のAIコーディングエージェント比較研究でも、Codex、Copilot、Devin、Cursor、Claude Codeが機能開発、バグ修正、ドキュメント化など異なる作業で活用されていることが示されています。ただし、どのエージェントもすべての作業タイプで最も優れているわけではなく、最終的なマージと責任はほとんど人間が担っていました。 Devinは専用...

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キ...

先日、こんな質問を受けました。 「GIIP FDE Box は Claude Cowork と何が違うのですか?」 良い質問です。そして最近AI業務ツールを検討しているスタートアップのCEOや企業担当者なら、誰もが一度は投げかける質問でもあります。 Claude Cowork をはじめ、ChatGPT の業務機能、Perplexity Computer、Genspark、Manus といったサービスは、文書作成、調査、資料整理、レポート作成など一般的なオフィス業務を支援することに強みがあります。 GIIP FDE Box も Slack を中心にこうした業務を処理できます。しかし GIIP FDE Box の核心は、単なるオフィス業務の補助ではありません。 GIIP FDE Box の核心は『実際にシステムを作り、運用する能力』です GIIP FDE Box は、アイデアを整理したりコードを書いたりする段階では終わりません。 外注開発チームの企画とデザイン、機能設計、コード作成から、実際にサービスが稼働するインフラ環境まで、一つの流れとして接続します。 例えば、次のような業務を行います。 要件を整理し、開発計画を策定 画面およびサービス構造の設計 フロントエンドとバックエンドのコード作成 Dev、Staging、Production 環境の構成 サービスに適したデータベースの設計・構築 セキュリティポリシーとアクセス権限の設定 ALB、NLB、CDN を用いた負荷分散構成 デプロイ後のシステム運用と障害対応 データベースとアプリケーションの性能分析 ボトルネック区間の改善と性能チューニング 使用量とアーキテクチャ分析によるクラウドコスト最適化 つまり GIIP FDE Box は、質問に答えたりコードを提案したりするツールではありません。 企画から開発、インフラ構築、デプロイ、運用、性能最適化まで、実際の成果物を作り出すAIベースの技術組織に近い存在です。 本当にこのような業務が可能なのでしょうか? GIIP はある日突然作られたデモプロジェクトではありません。 現在 GIIP インフラ管理サービスには、3万を超えるソースコードと2,500を超える技術文書が蓄積されています。 GIIP 自体も、最初から人...

SE、SRE、FDEは何が違うのか? 語源から役割、性格、学習の方向性まで整理するエンジニア職種の比較 IT業界の職種名は、思っている以上に危うい。 同じ「エンジニア」という名前を使っていても、実際にやっていることはまったく違うことがある。Software Engineer、Systems Engineer、Site Reliability Engineer、Forward Deployed Engineerはいずれもエンジニアだが、問題の見方と成功の基準が異なる。 特にSEという略語は、国や業界によって意味が揺れる。韓国や日本のSI業界ではSEをSystems Engineerとして使うことが多く、韓国ではServer Engineerを略してSEと呼ぶこともある。一方、グローバルIT企業の求人ではSEはおおむねSoftware Engineerに近い。 したがって職業を選ぼうとする人は、単に職種名だけを見るのではなく、その職種が何を作り、何に責任を持ち、どんな性格の人に合うのかを見るべきだ。 この記事では、SE、SRE、FDEを語源から役割、性格、学習の方向性まで比較してみたい。 1. SEの語源と意味 SEは最も混同の大きい表現だ。 一般的には次の三つの意味で使われる。 第一に、 Software Engineer である。 グローバルIT業界で最も一般的な意味だ。ソフトウェアを設計し実装するエンジニアを指す。Webサービス、モバイルアプリ、バックエンドAPI、データ処理システム、SaaS製品などを開発する人がこれに当たる。 第二に、 Systems Engineer である。 韓国や日本のSI業界では、以前からSEをSystems Engineerの略として多く使ってきた。この場合のSEは単なるプログラマーというよりも、要件分析、基本設計、詳細設計、顧客調整、テスト、プロジェクト管理の一部までを含む広い意味のシステムエンジニアに近い。 第三に、 Server Engineer である。 韓国では現場でServer Engineerを略してSEと呼ぶこともある。しかしこの表現は国際的に標準化された略語とは言いがたい。Linux、Windows Server、仮想化、ストレージ、ネットワーク、ミドルウェア運用を担当するインフラエ...

業務別エージェントを何千個も量産するのも、すべての仕事を一つの万能AIに任せるのも——私はどちらも慎重であるべきだと考える。大企業AXの核心は エージェントの数 ではなく、 運用可能な単位で管理されているか である。 先日、ある動画を見ながら少し長く考え込んでしまった。 動画の要点はおおよそこうだった。企業が「〇〇業務自動化エージェント」を一つずつ作り始めると、結局は数百、数千のエージェントが積み上がり、それは保守の地獄になりかねない、という話だ。だから特定の業務ごとにエージェントを作り続けるSI的な発想から抜け出し、Claude CodeやCodexのような汎用スーパーエージェントを組織全体でうまく活用できるようにすべきだ、という主張だった。 動画の問題意識そのものは理解できる 実際、AI時代に過去のSI方式そのままで「議事録エージェント」「カードニュースエージェント」「リスクアセスメントエージェント」「財務予測エージェント」をそれぞれ別々に構築するやり方は危険になりうる。そうやって作れば機能が重複し、プロンプトも散らばり、権限も散らばり、データも散らばり、誰が保守するのか分からない自動化の断片が社内に積み上がっていく。 その意味で「業務別エージェントの乱立を警戒すべきだ」というメッセージは正しい。 しかし「エージェント4,000個」という前提が引っかかった だが私が引っかかったのはその先だった。そのリスクを説明するために「大企業がエージェントを300個、400個、4,000個と作るようになる」という前提が敷かれているように聞こえたからだ。 私はこの前提をそう簡単には受け入れられなかった。 私が経験した大企業はそのように動かない。もちろん非効率もあり、部門のセクショナリズムもあり、古いSIの文法もある。しかしだからといって、大企業が何の統制もなく業務別エージェントを数千個も発注し運用する組織ではない。 大企業には次のようなものがある。 稟議（りんぎ） 予算審査 セキュリティレビュー アーキテクチャレビュー 個人情報レビュー 運用引き継ぎ条件 障害責任 保守契約 監査ログと権限管理 これらの仕組みが完璧だという意味ではない。しかし少なくとも正式な運用システムに入る瞬間、個別部門の要求がそのまま一つの独立システムとして...