Generative-Ai

AIマーケティングスタートアップのHightouchが、年間経常収益（ARR）1億ドル（約150億円）の突破を発表した。とりわけ目を引くのは成長速度だ——AIエージェントプラットフォームの投入からわずか20ヶ月で7,000万ドル（約105億円）の収益増加を達成している。これは単なるビジネスの成功話ではない。「汎用AIの限界をどう乗り越えるか」という、今まさに多くの企業が直面している問いへの、一つの明確な回答でもある。 なぜ汎用モデルはマーケティングに使えなかったのか 多くの企業が最初に試みたのは、汎用基盤モデルをそのまま使って広告素材を生成することだった。しかし結果は惨憺たるものだったと、HightouchのCo-CEOであるKashish Guptaは語る。「LLMは存在しない製品をハルシネーションしてしまう。存在しない製品の広告は打てない」。 ブランドカラー、フォント、トーン、既存の商品素材——汎用モデルはこれらの情報を持っていない。Domino’sのピザを生成しようとすれば、実際のDomino’sとは似ても似つかない画像が出てくる。これは「AIが使えない」のではなく、「正しいコンテキストを与えていない」という設計の問題だ。 HightouchのアプローチーーブランドDNAをAIに注入する Hightouchが採ったアプローチはシンプルだが本質的だ。Figma、社内CMS、フォトライブラリなど、企業がすでに保有しているデザインツールと直接連携し、ブランドのアイデンティティをAIが参照できる形で与える。 Domino’sの実例が分かりやすい。「Domino’sはピザを生成することは絶対にない。常に既存のピザ画像を使い、その周囲の背景やその他の要素だけをAIで生成する」とGuptaは説明する。 つまり「全部AIで作る」のではなく、信頼できる既存素材＋AI生成の組み合わせによって、ブランドの一貫性を保ちながら大量のパーソナライズドコンテンツを生み出す仕組みだ。RAG（Retrieval-Augmented Generation）の概念をマーケティング実務に応用したものと捉えると分かりやすい。 実務への影響——日本のマーケティング現場への示唆 デジタルマーケティングのコスト削減と品質維持の両立に苦慮する日本企業は多い。Hightouchのアプローチから学べる実務ポイントを整理する。 既存アセットの整備が先決 AIエージェントが「ブランドを学習」するためには、まず企業側の素材が整理・デジタル化されていることが前提だ。Figmaや社内CMS、商品画像ライブラリを適切に管理することが、AIを活用するための土台になる。 「禁止」ではなく「安全に使える仕組み」を構築する 「AIで生成した画像は使わない」という方針では競合に遅れをとるだけだ。ブランドガイドラインをAIに組み込む仕組みを作ることで、品質を担保しながら自動化の恩恵を受けられる。 デザイナーの役割が変わる 毎回一から素材を作る必要はなくなる。代わりに、AIが学習するためのブランドアセット設計・管理と、生成結果の品質評価・フィードバックが主要な役割へと移行していく。 筆者の見解 Hightouchの成功が示しているのは、AIを「正しく使う」とはどういうことかを端的に表している。汎用モデルにそのまま仕事をさせるのではなく、業務文脈・ブランド情報・企業固有の知識をきちんと与えた上で自律的に動かす——この設計思想こそが本質だ。 私が日々実感しているのも同じことで、AIエージェントに「やったことと、その結果をきちんと評価できる仕組み」を与えれば、自律的に改善を繰り返して合格点の成果を出せるようになっている。完全情報ゲームでなくても、もうかなりその段階に来ている。 「副操縦士として人間が逐一確認するモデル」から、「エージェントが自律的に判断・実行・検証を繰り返すハーネスループ」へ——この転換こそが今のフロンティアだ。Hightouchはマーケティング領域でそれをビジネスとして証明した。 日本のIT現場では、まだ「AIを試してみた」段階の企業が多い。しかし競争環境は急速に変わっている。Hightouchの20ヶ月で70億円という成長速度を見れば、AIエージェントへの本格投資を先延ばしにするコストがいかに大きいか、肌で感じてほしい。情報を追うだけでなく、自分たちの業務文脈をAIに与えて実際に回す経験を積む——それが今最も重要な一歩だ。 出典: この記事は Hightouch reaches $100M ARR fueled by marketing tools powered by AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがAIテキスト読み上げ（TTS）分野で新たな一手を打ってきた。「Gemini 3.1 Flash TTS」は、単に「機械音声の精度が上がった」という話ではない。音声表現の制御権をアプリケーション開発者に渡すという設計思想の転換点として注目に値する。 Gemini 3.1 Flash TTSとは何か 本モデルは、テキストを音声に変換するAIモデルの最新版だ。従来の読み上げエンジンとの最大の差異は「表現力の制御粒度」にある。 音声タグ（Audio Tags）——自然言語で声を演出する 最も注目すべき機能が「音声タグ」だ。テキスト入力の中に自然言語のコマンドを埋め込むことで、声のトーン・ペース・アクセントを細かく指示できる。たとえば「ここはゆっくり、懸念を含んだ口調で」といった指示をテキストに織り込むと、モデルがそのニュアンスを解釈して発話する。 これは「プロンプトで音声を演出する」という新しい設計パターンであり、従来のSSML（Speech Synthesis Markup Language）に慣れた開発者には馴染みやすく、かつより表現力豊かだ。 複数話者ダイアログとシーン設定 「シーン方向性（Scene Direction）」機能では、環境設定や場面指示を事前に与えることで、複数キャラクターが会話形式で自然に応答し合う音声を生成できる。ポッドキャスト的コンテンツや教育用ダイアログ、カスタマーサポートのロールプレイなど、応用範囲は広い。 品質と対応言語 第三者評価機関「Artificial Analysis」のTTSリーダーボードでEloスコア1,211を記録し、「高品質かつ低コスト」の象限に位置付けられている。対応言語は70言語以上で、日本語も含まれる。 SynthID透かし——AI音声の識別可能性を確保 生成された音声にはSynthIDによる不可視の電子透かしが付与される。フェイクニュースや詐欺音声への悪用リスクを考慮した実装だ。AI生成コンテンツの信頼性管理が問われる昨今、この機能の意義は大きい。 利用可能なプラットフォーム 現在プレビューとして以下で利用できる： Gemini API / Google AI Studio — 開発者向け。音声タグの実験やボイスプロファイルの設定・エクスポートが可能 Vertex AI — エンタープライズ向け。本番統合を想定した構成 Google Vids — Workspaceユーザー向け。動画制作ツールへの組み込み 実務への影響——日本のエンジニア・IT管理者にとっての意味 API統合で音声UXを手に入れる Gemini APIを通じてTTSをアプリに組み込む選択肢が増えた。社内向けナレーション、マニュアルの音声化、チャットボットの応答音声など、これまでコストが高くて見送っていたユースケースが手が届く範囲に入ってくる。 多言語対応の実用性 70言語以上の対応は、グローバル展開が必要なシステムや、外国語コンテンツの日本語音声化ニーズに応える。ただし、日本語の自然さについては実際のテストが不可欠だ。英語圏向け評価指標のEloスコアがそのまま日本語品質を保証するわけではない。 SynthIDのガバナンス価値 企業がAI生成音声を利用する際、「それが本物の人間の声か」を証明・否定できる仕組みは、コンプライアンス観点でも重要性を持つ。特に金融・法務・医療分野での活用を検討する際は、このトレーサビリティが信頼性の根拠になり得る。 筆者の見解 TTS分野において、Googleが「制御インターフェースの設計」に本気で取り組んできたことは認めていい。音声タグという概念は、プロンプトエンジニアリングの知見を音声生成に応用したものであり、開発者が「声の演出家」として働ける環境を整えようとする意図が見える。 一方、正直に言えば「実際に触ってみるまでわからない」が私の率直な感想だ。ベンチマークのEloスコアが高いことと、日本語のビジネス用途で使いものになることは別の話だ。特にTTSは言語ごとにアクセント・イントネーションの難しさが異なり、評価指標と体験品質の乖離が大きい領域でもある。 音声AIの実用化において今重要なのは「どのモデルが最高スコアか」ではなく、「自分のユースケースに合うモデルをどう選び、どうワークフローに組み込むか」という問いだ。音声生成を真剣に検討しているチームは、Google AI Studioで実際に触りながら、自社の判断基準で評価することを強く勧めたい。 AI音声のコモディティ化は着実に進んでいる。数年前は専用の音声合成システムに数百万円をかけていた領域が、APIコールで完結する時代になっている。この波をどう業務に活かすかを考える好機だ。 出典: この記事は Gemini 3.1 Flash TTS: the next generation of expressive AI speech の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAI が Agents SDK の大幅アップデートを発表した。目玉は2つ——ネイティブサンドボックス実行とモデルネイティブハーネスだ。「エージェントが自律的に長時間動き続ける」という設計思想そのものが前面に出てきた形で、自律型 AI エージェントの開発を本格的に進めたいエンジニアにとって、見逃せないアップデートである。 ネイティブサンドボックス実行の意味 従来の AI エージェント開発では、コード実行環境の安全性確保が大きな課題だった。エージェントが動的にコードを生成・実行する際、ホスト環境への影響をどう遮断するかは開発者が個別に実装する必要があった。 今回の「ネイティブサンドボックス実行」は、この課題を SDK レベルで解決するアプローチだ。エージェントがファイル操作やコード実行を行う際に、分離された安全な環境内で処理が完結する。本番環境やホスト OS への意図せぬ書き込み・破壊が防止できるため、エンタープライズ用途での実用化を大きく前進させる。セキュリティポリシーが厳しい日本企業においても、「エージェントにコードを実行させる」という提案が組織内で通りやすくなるはずだ。 モデルネイティブハーネスとは何か もう一つの柱が「モデルネイティブハーネス」だ。 ハーネスとは、エージェントが「判断→実行→検証→次の判断」というループを自律的に回し続けるための仕組みを指す。これまでは開発者がこのループを自前で設計・実装する必要があり、実装の品質や堅牢性は開発者のスキルに大きく依存していた。 「モデルネイティブ」という言葉が示すとおり、今回のアップデートではこのループ設計がモデル側に内包される。開発者は目的を定義するだけでよく、ループ管理の煩雑な実装から解放される。結果として、長時間にわたって複数のファイルやツールをまたいで動き続けるエージェントが、より少ないコードで実現できるようになった。 実務への影響 エンタープライズ開発者へ サンドボックス実行の標準化は、社内展開における審査コストの削減につながる。セキュリティレビューで「コード実行の影響範囲はどこまでか」を説明する際、SDK レベルの保証として提示できることは大きい。承認プロセスを持つ日本企業にとって、これは実務上の導入障壁を下げる効果がある。 システムアーキテクトへ ハーネスループの標準化は、アーキテクチャ設計の変化を意味する。「人間が承認ボタンを押すたびに処理が進む」設計から、「エージェントが自律的に完走し、完了報告だけが来る」設計へのシフトを本格的に検討する時期に来ている。 スタートアップ・個人開発者へ 長時間稼働エージェントの実装コストが下がることで、「24時間無人で動き続けるワークフロー自動化」が個人レベルでも現実的になる。ツールとインフラさえ用意できれば、仕組みを回すのは AI に任せる——そういう働き方が加速する。 筆者の見解 AI エージェント開発の文脈で、「ハーネスループ」は今まさに最も重要なテーマだと考えている。エージェントが単発の指示に応答するだけでなく、自律的に判断・実行・検証のループを回し続けられるかどうか——これが「本物のエージェント」と「チャットボットの延長線」を分ける境界線だ。 今回の Agents SDK のアップデートは、その境界線を越えるための実装コストを大幅に下げた意義がある。特にモデルネイティブハーネスの発想——ループの設計責任をモデル側に引き渡す——は正しい方向性だと思う。開発者が「どうループを回すか」ではなく「何を達成させるか」に集中できる状態こそが、エージェント開発の本来あるべき姿だ。 日本のエンタープライズ環境では、まだ「AI に自律的に動かせる」という発想が浸透していない現場が多い。しかし、SDK レベルの安全機構が整備されることで、「人間の承認を介在させずに動かす」という判断を組織内で通しやすくなるはずだ。AI が自律的に動き続ける仕組みを設計できる人材の価値は、今後ますます上がっていく。このアップデートを機に、ハーネスループの設計パターンを実際に手を動かして試してみることを強くお勧めする。 出典: この記事は The next evolution of the Agents SDK の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「ライブネスチェック」が90秒で突破される現実 カンボジアのマネーロンダリングセンターで、一人の従業員がベトナム系銀行アプリを開く。本人確認のため顔写真のアップロードを求められると、アカウント所有者とは似ても似つかない女性の静止画を差し出す。それでも「ライブネスチェック（本人がカメラの前にいることを確認する動的検証）」を90秒でパスしてしまった——MIT Technology Reviewがサイバー詐欺研究者への取材をもとに報じた、衝撃的な事例だ。 この手口の核心は「仮想カメラ（Virtual Camera）」ツールにある。スマートフォンのカメラ入力を乗っ取り、ライブ映像の代わりに任意の静止画や動画を差し込める。ディープフェイク映像を使えば精度はさらに上がる。そしてこうしたバイパスツールが、Telegramの公開チャンネルで堂々と販売されている。 Telegramに22チャンネル——Binanceや大手銀行も標的 MIT Technology Reviewは約2ヶ月の調査で、中国語・ベトナム語・英語の22チャンネル・グループを特定した。Binanceのような主要暗号資産取引所から、スペインのBBVAといった名だたる銀行まで、幅広いKYC（Know Your Customer）検証をバイパスするキットが出品されていた。 「銀行サービス専門——汚れた金を扱います。安全・プロ・高品質」と書かれたTelegramの自己紹介文まで存在した。Telegramは報告を受けてアカウントを削除したと述べているが、類似のマーケットプレイスはすぐ復活する構造的問題がある。 こうした悪用の背景にあるのが「ピッグ・ブッチャリング（豚の丸焼き）詐欺」と呼ばれる手口の拡大だ。仮想通貨詐欺・不正送金の被害額は2025年に約170億ドル（約2.5兆円）に達し、前年の130億ドルから急増。東南アジアのアフリカ・太平洋地域への拡大も国連薬物犯罪事務所（UNODC）が警告している。 なぜこれが重要か——生体認証への「過信」が最大のリスク KYCの顔認証・ライブネスチェックは、金融犯罪対策の「最後の砦」として多くの金融機関が採用を進めてきた。日本でも犯罪収益移転防止法（犯収法）に基づくeKYCが普及し、スマートフォンで完結する本人確認が標準になりつつある。 問題は、こうした仕組みへの信頼が「技術的に突破不可能」という前提の上に成り立っていることだ。仮想カメラツールの存在が示すのは、OSレベルのカメラ入力を制御できれば、アプリ側のチェックはほぼ無力化できるという現実だ。Androidの場合はルート化・カスタムROMの悪用、iOSでも一部ジェイルブレイクやAPIフックによる攻撃ベクターが存在する。 実務への影響——IT管理者・セキュリティ担当者が取るべきアクション 1. eKYC導入・見直し時は「デバイス整合性検証」を必須要件に ライブネスチェック単体ではなく、デバイスの完全性（root化・ジェイルブレイク検知、Play Integrity API / App Attest）の確認をセットで実装しているかを確認すること。バイパスツールはOS層への介入が前提なので、デバイス整合性チェックが最初の防衛線になる。 2. 行動ベースの異常検知を組み合わせる 顔認証の一点突破ではなく、ログイン時刻・場所・操作パターンといった行動分析との組み合わせが現実的な対策。単一の認証強化に頼ると、その手法が破られた瞬間に全体が崩れる。 3. Telegramを「脅威インテリジェンス」として監視する セキュリティチームは、Telegramの日本語・英語・中国語チャンネルを脅威インテリジェンスの観測対象に加えることを検討したい。攻撃ツールの販売動向をモニタリングすることで、新たなバイパス手法の事前察知が可能になる。 「禁止」より「仕組みの多重化」 技術的な制限だけで詐欺を止めようとする発想には限界がある。不正が起きた場合の検知・追跡・通報の仕組みを整備し、攻撃者にとって「やり得」にならない環境を作ることが本質的な対策だ。 筆者の見解 生体認証の普及は確かに本人確認の利便性を大きく向上させた。だが今回の報告が突きつけるのは、「認証の強化」と「認証の突破」は常に同時進行するという、セキュリティの根本的な宿命だ。 特に懸念しているのは、eKYCを「導入した＝対策済み」と思っている組織が多いことだ。技術は導入した瞬間から陳腐化が始まる。仮想カメラによるバイパスは今に始まった話ではなく、以前からセキュリティ研究者の間では知られていた手口だ。それが「Telegramで堂々と売られる商品」になったという事実は、攻撃の民主化・低コスト化が相当進んでいることを意味する。 筆者が繰り返し言ってきた「禁止ではなく、安全に使える仕組みを」という原則は、ここでも当てはまる。攻撃側は常に最も弱いリンクを探す。防衛側がすべきは特定の手口を塞ぐことではなく、攻撃が成立しても被害が最小化される多層防御の設計だ。 170億ドルという被害額の重さを日本の組織は自分事として受け止め、eKYC基盤の再点検と監視体制の強化に今すぐ取り組んでほしい。 出典: この記事は Cyberscammers are bypassing banks’ security with illicit tools sold on Telegram の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleが水面下でGrokに「排除」を警告していた イーロン・マスク氏率いるxAIのAIチャットbot「Grok」が、2026年1月にApple App Storeから排除される寸前だったことが明らかになった。NBCニュースが入手したAppleから米上院議員宛の書簡によると、Appleは非合意性的な性的ディープフェイク（deepfake）が大量発生したことを受けて、XとGrokの開発チームに対してコンテンツモデレーション計画の提出を非公開で要求していたという。 この問題が日本のIT関係者にとって単なる「海外の炎上案件」で終わらない理由は、AIプラットフォームとアプリストアという2つのゲートキーパーの責任構造、そしてAI安全対策の「実効性」を問う普遍的な課題を内包しているからだ。 何が起きていたのか 問題の発端とAppleの対応 GrokはXのプラットフォーム上でも単体アプリとしても提供されており、ユーザーが実在する人物の「脱衣」画像を生成できる脆弱なサーフェスが問題となった。被害者の多くは女性であり、明らかに未成年と見られるケースも含まれていたとされる。これはApp Storeガイドラインへの明確な違反だ。 Appleは「X側は実質的に違反を解消した」と判断した一方で、Grokについては「まだコンプライアンスを満たしていない」と評価。追加対応がなければ削除すると警告した。その後のやり取りを経て、AppleはGrokが「実質的に改善された」として最終的にはApp Storeへの残留を認めた。 「改善済み」とされても実態は？ ここが最も重要なポイントだ。xAIは有料サブスクリプション限定化や「脱衣」機能の制限など、複数の対策を順次打ち出したと発表した。しかしThe Vergeや複数のサイバーセキュリティ関係者の検証によると、Grokは現在も比較的容易に性的なディープフェイクを生成できる状態にある。公人の明示的な画像さえ生成できたという報告もある。 なぜこれが重要か——プラットフォームガバナンスの構造問題 「非公開の圧力」という手法の限界 Appleが今回とった行動は「非公開の警告→非公開の交渉→非公開の承認」というクローズドなプロセスだった。問題がメディアで公然と報じられている最中でも、Appleは一切の公式コメントを避けた。Googleも同様にGooglePlayとしてのスタンスを表明していない。 プラットフォームの「門番」として強大な力を持つAppleとGoogleが、有害コンテンツ問題に対して閉ざされた交渉で対応する——この構造では、エコシステム全体への透明性ある説明責任が果たされない。アプリが継続的にストアで配信されている間も、被害は現実に発生し続けていた。 「技術的対策」と「実効性」の乖離 Grokが打ち出した有料化制限やフィルタリングは、Appleの審査を通過するための「計画」としては機能した。しかし実際の悪用を止める実効性には大きな疑問符が残る。これはGrokに限らず、生成AI全般が直面する構造的な課題だ。プロンプトエンジニアリングやAPIアクセスを通じた回避手法は常に存在し、「対策を入れました」と「悪用が止まりました」の間には大きな溝がある。 実務への影響——日本のIT管理者・エンジニアに伝えたいこと 社内AIツール選定での「安全基準」の見直し 生成AIツールを業務導入する際、コンテンツモデレーションの実効性を評価軸に加えることが重要になっている。ベンダーの「対策実施済み」という発表だけでなく、独立した検証結果や継続的な第三者評価があるかどうかを確認したい。 APIやプラグイン連携時のリスク評価 ビジネスアプリとAIを連携させる際、そのAIエンジンがどのようなコンテンツポリシーを持ち、どう実施されているかを利用規約・技術文書のレベルまで確認する習慣が必要だ。特にエンドユーザーが直接プロンプトを入力できるインターフェースを提供する場合、ダウンストリームのリスクは開発者側にも及ぶ。 プラットフォームに依存しすぎないガバナンス設計 App StoreやGooglePlayが「安全を保証する」という前提は成立しない。今回明らかになったように、ゲートキーパーはしばしば非公開交渉を優先し、問題が解決する前にアプリを継続配信し続ける。企業がAIサービスを採用する際のガバナンスは、自社基準として設計・運用する必要がある。 筆者の見解 Appleは今回、強大なプラットフォーム支配力を「ほぼ使わなかった」。技術的には排除できたはずの状況で、非公開交渉を選び、Grokを残留させた。その結果として被害が続いたという事実は重く受け止めるべきだ。 より根本的な問題は「対策の実効性を誰が検証するのか」という点にある。今回、実際に問題を測定したのはメディアやサイバーセキュリティ研究者だった。AppleはGrokが「実質的に改善された」と判断したが、その判断基準と検証プロセスは不透明なままだ。 生成AIの安全対策は「宣言」ではなく「継続的な計測と公開」でしか信頼を得られない。これはツールの種類や提供企業の規模を問わず、すべてのAIプラットフォームに共通する課題だ。 日本でも、業務利用・一般利用を問わず生成AIの普及が加速している。今回の件は「プラットフォームに任せておけば安全」という発想の危うさを改めて教えてくれる。自社でのリスク評価と独自基準の策定——これを後回しにしていい段階は、もうとっくに過ぎている。 出典: この記事は Grok’s sexual deepfakes almost got it banned from Apple’s App Store. Almost. の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobeが2026年4月、クリエイティブツールの使い方を根本から変えかねない新機能「Firefly AI Assistant」を発表した。専門的な編集操作を知らなくても、話しかけるように指示を入力するだけで、Creative Cloudの各アプリを横断した複雑な編集ワークフローを自動実行するエージェント型AIだ。「これはクリエイティブワークの根本的な転換点だ」という同社の主張は、決して大げさではないかもしれない。 Firefly AI Assistantとは何か Firefly AI Assistantは、昨年のAdobe Max conferenceで公開されたProject Moonlightの実験を土台に構築された統合AIインターフェースだ。ユーザーが「この画像をレタッチして」「SNS向けにリサイズして」と自然言語で入力すると、AIが複数の選択肢を生成しながら、Photoshop・Premiere・Lightroom・Illustrator・Expressなどの適切なツールを自律的に呼び出して処理を実行する。 重要なのは、ユーザーが結果を確認して微調整するUIも同時に提供される点だ。特定のスライダーや設定パネルを直接開くのではなく、AIが「このへんを調整しますか？」と提示してくる。より細かい仕上げが必要なら、編集済みファイルをCreative Cloudアプリで開いて続きの作業もできる。 「学習するエージェント」としての設計 注目すべきは、Firefly AI Assistantが使うほどユーザーの好みを学習する点だ。よく使うツール・ワークフロー・審美的な好みを記憶し、結果の一貫性とパーソナライズ度を高めていく。この学習機能はオプト形式で、プロジェクト単位で対象を選べるという。 また「Creative Skills」という仕組みも興味深い。特定の処理を一貫して再現するプリセットをスキルとして登録・共有できる機能で、AIアシスタントが実行する処理の単位を自分でカスタマイズできる。ライブラリから既成スキルを選ぶことも可能だ。 さらにAdobeは、サードパーティのAIアプリからFireflyの機能を呼び出せる統合APIも提供予定とアナウンスしている。外部のAIツールからAdobe製品の編集機能にアクセスできるようになり、既存のAIワークフローにAdobeの強みを組み込みやすくなる。 実務への影響——クリエイターとIT管理者それぞれに クリエイターにとっては、Premiereのタイムライン操作やPhotoshopの複雑なマスク処理といった「覚えるべき手順」が激減する。ただし、AIが生成した結果をどう見極め、どの方向に導くかというディレクション能力は従来以上に重要になる。ツールの操作技術よりも「何を作りたいか」の言語化が問われる時代だ。 IT管理者・情報システム部門にとっては、Adobe Creative CloudライセンスがFirefly AI Assistantを含む形になることで、コストや権限管理の見直しが必要になる可能性がある。特にエンタープライズ向けには、AI学習データに何を含めるかのガバナンスポリシーが求められるようになるだろう。学習機能のオプトイン設計はその観点からも重要で、早めに社内ポリシーを整理しておくことを勧める。 筆者の見解 今回のFirefly AI Assistantが示す方向性は、AIの本質的な価値に正面から向き合った設計だと感じる。「ツールの操作方法を知っている人しか使えない」というプロフェッショナルツールの壁を崩しながら、熟練者には細部の制御を残すという両立は技術的にも難しい挑戦だ。それを複数アプリの横断実行という形で実現しようとしているのは評価できる。 個人的に重要だと思うのは、このアシスタントが「確認を求めて止まる設計」ではなく、「一通り実行してから選択肢を見せる設計」になっている点だ。ユーザーに次の指示を毎回求めるのではなく、自律的にタスクを進めてから人間にレビューを渡す——このループ構造こそが、AIエージェントが実用的に機能するための本質的な設計思想だと私は考えている。 Adobeが「根本的な転換」と呼ぶのは誇張ではない。クリエイティブツールの文脈で、自律エージェントが複数のアプリを横断してワークフローを実行するという概念実証が、いよいよ製品として形になってきた。Creative Cloudを日常的に使っている方は、ぜひFirefly AI Assistantが利用可能になったタイミングで積極的に試してほしい。「AIを使いこなす」練習の場として、これ以上わかりやすい入り口はそうそうない。 出典: この記事は Adobe embraces conversational AI editing, marking a ‘fundamental shift’ in creative work の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIブームに乗った「ゾンビブランド」復活劇 ウールスニーカーで一世を風靡したAllbirds（オールバーズ）が、GPUクラウド企業「NewBird AI」として再出発すると発表し、株価が一夜にして600%超急騰した。2021年のIPO時には評価額40億ドルを誇ったが、その後一度も黒字化できず、2022年〜2025年の間に売上はほぼ半減。最終的にブランドと資産を3,900万ドルで売却し事業を清算したばかりだった。 しかし上場廃止のタイミングでCEOが発表したのは、匿名の投資家から5,000万ドルを調達し、「フル統合型GPU-as-a-Service（GPUaaS）およびAIネイティブクラウドソリューションプロバイダー」を目指すというビジョンだ。 GPU需要は本物、でもAllbirdsは何者か 発表文の内容自体は、AI時代の実態を的確に捉えている部分もある。 高性能GPUの調達リードタイムが延伸し続けている 北米データセンターの空き率が史上最低水準 2026年半ばまでに稼働予定のコンピュート容量はすでに予約済み 企業・AI開発者・研究機関が必要な計算資源を確保できない状況 これらはすべて事実だ。AWSやAzure、GCPといったハイパースケーラーに頼れない中小企業が、CoreWeaveのような「ネオクラウド」に殺到している構図はリアルに存在する。GPU需要というパイ自体は本物だ。 だが問題は、5,000万ドルの資本でどこまで戦えるかという現実だ。兆ドル規模のプレイヤーが並ぶ市場で、Allbirdsが持つアドバンテージは何か。プレスリリースを読む限り、答えは「上場企業の株式という器」以外に見当たらない。 ウォートン校教授の辛辣な分析 ペンシルバニア大学ウォートン校のGad Allon教授のコメントが本質を突いている。 「これを『ピボット』と呼ぶのはAllbirdsに過大評価だ。ピボットとは技術・人材・販路などの資産を新市場に転用することを指す。AllbirdsにはAIに転用できる資産が何もない。あるのは上場ステータスだけで、今の市場ではそれだけで十分に資金調達できてしまう。彼らはAIにピボットしているのではなく、上場という立場を使ってトレンドに乗っているだけだ」 教授はさらに、古いウォール街のジョークになぞらえた。「靴磨き少年が株のアドバイスをし始めたら売り時だ」という格言の現代版——「靴会社がAI企業を名乗り始めたら、バブルが何かを語っている」。 実務への影響——バブル識別リテラシーが問われる時代 日本のIT部門・調達担当者にとって、この件は他人事ではない。今後「AIクラウド」「GPUaaS」「AIネイティブ」を名乗るスタートアップや新興サービスは急増する。どこに本質的な差別化があり、どこが看板の掛け替えだけなのかを見極める目が問われる。 チェックポイントの例： そのGPUリソースは自社所有か、再販か、将来的な調達契約か 技術チームのバックグラウンド（AI/インフラ経験者がいるか） SLAと実際の稼働実績データが開示されているか 既存顧客のユースケースと規模感は具体的か 「AI」という言葉が入っているかどうかではなく、提供できるコンピュートリソースの質・量・信頼性が本質だ。 筆者の見解 GPU不足は本物の構造問題であり、それを解決しようとするビジネス自体は正当だ。CoreWeaveのような先行プレイヤーが実際に市場を切り拓いていることもある。だから「GPU供給ビジネスがインチキ」という話ではない。 問題は、事業に必要な実力と実績を持たない企業が「AI」というキーワードだけで株式市場から資金を引き出せてしまっている構造だ。2021年のSPACブームでRadio ShackがCrypto企業に転身したのと構図は同じ——あのときは仮想通貨だったが、今回はAIだ。 AIに関わる構造的な需要は本物であり長期的に続く。だからこそ、その需要に真剣に向き合っている企業とブームに乗っかっているだけの企業を見分けることが、調達判断においても投資判断においても、これまで以上に重要になる。 AIが「何でも解決するバズワード」として消費されるのは、AIを実際のビジネス変革に使おうとしているすべての人間にとって迷惑な話だ。本物の実力を持つプレイヤーが正当に評価される市場環境を、業界全体で守っていく必要があると感じている。 出典: この記事は Allbirds announced a switch from shoes to AI and its stock jumped 600 percent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがmacOS向けのGeminiデスクトップアプリを正式リリースした。前日にWindowsのSpotlight風アプリを全ユーザーに公開したばかりで、プラットフォーム横断的な展開が一気に加速している。デスクトップAI統合は今やOpenAI・Anthropic・Perplexityなど各社が激しく競い合う主戦場となっており、その動向は日本のIT現場にも無関係ではない。 Gemini Macアプリの機能概要 アプリの最大の特徴は、Option + Spaceのショートカット一発でフローティングチャットバブルを呼び出せる点だ。作業中のウィンドウを切り替えることなくAIに質問でき、画面を共有すれば「今見ているもの」に基づいた回答も得られる（共有前に画面アクセスの許可が必要）。 機能面では以下が利用可能だ。 テキストチャット（全言語・全対応国で無料） 画像・動画・音楽の生成 GoogleドライブからのファイルやドキュメントのアップロードとAI処理 Googleアカウントに紐づいた過去の会話履歴の参照 動作要件はmacOS Sequoia（15.0）以上。AppStoreからの無料ダウンロードとなる。 競合との現時点での差異 記事内でも指摘されているが、競合他社のMacアプリは単純な「チャットへのアクセス」を超えた機能を持っている。ファイル操作・ブラウザ制御・アプリ起動といったコンピューター上のタスクをAIが直接実行する「コンピューターユース」機能がそれにあたる。 GeminiのMacアプリは現時点でこの領域に踏み込んでおらず、あくまでチャットと生成系コンテンツの補助という位置づけだ。画像・動画・音楽生成にはGoogleの強みが光るが、「エージェントとして仕事をさせる」用途にはまだ距離がある。 実務への影響——日本のエンジニア・IT管理者にとっての意味 まず確認すべきこと：組織のGoogle Workspace契約と利用ポリシー。 GeminiアプリはGoogleアカウントに会話が紐づくため、仕事用アカウントで使う場合は社内のデータ管理ポリシーとの整合性を確認しておく必要がある。Googleドライブとの連携は魅力的だが、業務データをAIに渡す際のガバナンスは事前に整理しておきたい。 実務活用の現実的な入り口： Google Workspace（Gmail・Docs・スライド）を主軸に使っている組織にとっては、文書の要約・翻訳・メール下書きをデスクトップから素早く呼び出せる点に一定の価値がある。Option + Spaceのショートカットは体験として分かりやすく、非エンジニアにも導入しやすい。 AI管理者視点での観点： 複数のAIアプリが社員のMacに混在し始める時代が来る。一元管理のポリシー設計（どのAIツールを業務利用承認するか、データ共有のスコープをどう定めるか）を今のうちに整備しておくことが中長期的なガバナンスコストを下げる。 筆者の見解 デスクトップへのAI統合がこれほど短期間で競合ひしめく領域になるとは、一年前には予測しにくかった。各社がこぞってOS上のAIプレゼンスを高めようとしているのは、「どのAIが日常の起点になるか」という主導権争いの側面が強い。 Geminiについて率直に言えば、画像・動画・音楽生成の品質は他社と比較しても存在感がある。ただ実務における「AIにタスクを丸ごと任せる」という体験の充実度という観点では、現時点のMacアプリはまだ追いつけていない印象だ。 とはいえGoogleは底力のある会社だ。検索・クラウド・Workspaceとの統合という観点では、誰にも真似できない強みを持っている。コンピューターユース機能の拡充が進めば、Workspace利用者にとっての選択肢として一気に実用性が跳ね上がる可能性は十分ある。 重要なのは、デスクトップAIツールの選定を「話題かどうか」ではなく「自分・自社のワークフローにどれだけ深く統合できるか」で判断することだ。AIが作業を中断させるツールから、作業に溶け込むインフラになる——その移行が本格化しつつある今、どのツールをどう組み合わせるかは個人・組織ともに真剣に考え直すタイミングに来ている。 出典: この記事は Google launches a Gemini AI app on Mac の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの「夢」フェーズが終わり、「ビジネス」フェーズが本格化している。OpenAIの年換算収益が250億ドル（約3.8兆円）を突破し、2026年後半のIPOに向けた初期検討が始まった。一方Anthropicは年換算収益が300億ドル（約4.6兆円）の「ランレート」に達したと発表。わずか1か月（3月）で58%の急増という驚異的なペースだ。この数字は単なる話題にとどまらず、日本のIT現場にも実質的な影響を与え始めている。 OpenAIの250億ドルとIPO構想 2026年2月にOpenAIが報告した年換算収益は250億ドル超。同社はこれを足がかりに2026年後半のIPOを視野に入れた初期検討を開始した。ただし「IPO検討」はまだ準備の初期段階であり、確定情報ではない点は注意が必要だ。同社はメディア戦略の一環として、テクノロジー専門のポッドキャスト配信メディア「TBPN」を数億ドル規模で買収したことも明らかになった。企業としてのブランド構築にリソースを投下している。 Anthropicの「エージェント向けサブスク廃止」が意味するもの より実務的なインパクトが大きいのは、Anthropicが打ち出したポリシー転換だ。月額サブスクリプションを使って「OpenClaw」などのサードパーティ製エージェントハーネスを動かすことを原則禁止とし、今後はAPI経由のトークン従量課金に移行させることを発表した。 この背景にあるのは深刻なコンピュート不足だ。AIエージェントが普及するにつれて、月定額の「使い放題」契約が計算資源の逼迫を招いていた。Anthropicは同時にGoogleとBroadcomとの拡大パートナーシップを通じて、2027年稼働予定のTPUデータセンターへのアクセスを確保すると発表しており、中期的な供給力の拡充を目指している。 このポリシー変更は、エージェントAIの普及に対してブレーキとなる可能性がある。一方で、コスト意識を持った企業がオープンソースモデルをエージェントのバックエンドとして採用する動きを加速させるきっかけになるかもしれない。 Project Glasswing：AIが引き起こすサイバー脅威への先手 Anthropicはもう一つ、見逃せない取り組みを発表した。主要テクノロジー企業やサイバーセキュリティ企業と組む連合体「Project Glasswing」だ。 目的は明確だ——AIの高度なコーディング能力が悪用される前に、世界の重要インフラのソフトウェア脆弱性を発見・修正しておくこと。連合参加企業には、未公開のサイバーセキュリティ特化AIモデル「Mythos」のプレビュー版がすでに提供されており、ゼロデイ脆弱性の発見・パッチ適用を先行して進めている。 これは杞憂ではない。最新のAIモデルは既存のペネトレーションテストツールを大幅に超えるコード解析能力を持ち始めており、悪意ある攻撃者がこれを使えば被害の規模と速度が桁違いになる。「AIが攻撃に使われる前に防衛側が先手を打つ」——この発想は非常に現実的だ。 実務への影響 日本のIT管理者・エンジニアが今考えるべきこと： エージェントのコスト設計を見直す: サードパーティエージェントハーネスを月額サブスクで運用していたチームは、API従量課金へのシフトによるコスト増を見込んで予算を再計算する必要がある。大規模に使うほど試算と実費のギャップが開きやすい オープンソースモデルの検討を始める: 商用APIの従量課金が重荷になる規模の場合、オープンソースモデルをオンプレまたはクラウドGPUで自前運用するコスパが相対的に上がる。今のうちに検討しておく価値がある AIを使ったサイバー攻撃への備えを: Project Glasswingが示すように、AI活用型の攻撃は現実の脅威になりつつある。ゼロデイ対応の体制と、脆弱性スキャンのAI活用をセキュリティロードマップに組み込む時期だ 財務規模の変化をベンダー選定の参考に: 生成AIベンダーの資金力・コンピュート調達力は、SLAやサービス継続性に直結する。収益規模の推移はベンダーリスク評価の指標の一つになる 筆者の見解 今回の一連の発表が示しているのは、「AIの使い方」が静かに、しかし大きく変わりつつあるという事実だ。 注目したいのはAnthropicのサブスク廃止措置だ。表面上は「コンピュート不足への対応」だが、その本質はエージェントを自律的に動かし続けるハーネスループが、もはや一部の先進ユーザーのものではなく、マス化しつつあることを示している。需要が供給を食い破るくらいに普及しているということだ。 これはエポックメイキングなシグナルだと思う。単発の「AIに質問する」使い方から、「エージェントが自律的に判断・実行・検証を繰り返すループを設計する」使い方への移行が、数字として現れ始めた瞬間だ。 Project Glasswingについては、率直に言って「ようやく」という感想だ。高度なAIの悪用リスクは以前から自明だった。産業連合として体系的に動き出したことは評価できる。ただし、日本の企業・官公庁がこのような国際的なセキュリティコンソーシアムの動向を把握し、自組織の対策に反映できているかというと、まだ心もとない。「AI導入は進めている、でもAIを使った攻撃への対備はまだ」という組織が大多数ではないか。 OpenAIのIPO検討については、足元の収益規模からすれば自然な流れだ。ただし上場企業になることで四半期ごとの数字を意識した判断が増えることへの懸念は拭えない。研究主導の文化と株主還元の要求は、時に鋭く対立する。この点は今後も注目し続けたい。 収益規模が兆単位になろうと、エンジニアにとって本質は変わらない。今自分が使っているツールを深く使い倒し、その経験から設計力・判断力を磨くことが、この変化の中で価値を持ち続ける唯一の道だ。 出典: この記事は OpenAI Surpasses $25B Annualized Revenue, Eyes Late 2026 IPO の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAI領域における独自技術の確立に向け、大きな一歩を踏み出した。2026年4月2日、同社は「MAI Superintelligence」イニシアチブの一環として、音声認識・音声合成・画像生成の3種類の新基盤モデルを発表した。OpenAIとのパートナーシップ開始以来、初めての本格的な独自フロンティアモデルの商用リリースであり、Microsoftのプラットフォーム戦略において象徴的な転換点となる。 3つのMAIモデル、それぞれの実力 MAI-Transcribe-1（音声認識） 25言語にわたるFLEURS評価における平均単語誤り率（WER）3.8%を達成し、OpenAIのWhisper-large-v3を全25言語で上回る性能を示した。Google Gemini 3.1 Flashに対しても22言語で優位に立っており、多言語対応の音声認識モデルとしてトップクラスの実力を持つ。日本語が対象言語に含まれているかは明示されていないが、25言語対応という規模感から見ても実用性は高いと判断できる。 MAI-Voice-1（音声合成） リアルタイムの60倍速で音声を生成でき、わずか数秒のサンプル音声からカスタムボイスを作成する機能を備える。価格は100万文字あたり22ドルで、音声合成市場の有力プレイヤーであるElevenLabsと真っ向勝負する価格設定だ。企業向けのナレーション自動生成や、アクセシビリティ対応コンテンツの制作コスト削減に直結するスペックである。 MAI-Image-2（画像生成） Arena.aiのランキングで上位3位に入り、前世代モデル比で生成速度が2倍に向上した。入力100万トークンあたり5ドル、画像出力33ドルという料金体系で、Microsoft Foundryおよびの新しいMAI Playgroundから利用可能。広告大手WPPが最初のエンタープライズパートナーとして名を連ねており、商業クリエイティブ用途への展開が早くも動き始めている。 「10人チーム」が示すMicrosoftの本気 特筆すべきは、音声系モデルがわずか10人のエンジニアチームによって開発されたという事実だ。CEO Mustafa Suleiman氏が掲げる「小規模・高権限チーム」哲学の体現であり、大組織ならではの遅さやリソース浪費を意識的に排除しようとする意図が見える。これはOpenAIやAnthropicといった専業AIラボが持つ機動力に、Microsoftも本気で応えようとしているシグナルだと読める。 日本のIT現場への影響 Microsoft Azureユーザーにとってのチャンス 今回のモデルはMicrosoft Foundry経由で提供される。Azure AIサービスをすでに利用している組織にとっては、既存のID管理・コスト管理・セキュリティ設定をそのまま活用しながら高性能モデルにアクセスできる利点が大きい。サードパーティの音声・画像APIを別途契約しているケースでは、統合によるコスト削減と運用簡素化が期待できる。 音声認識の精度向上は業務直結 MAI-Transcribe-1の多言語高精度認識は、議事録の自動化・コールセンターの音声ログ解析・多言語サポートチャットなど、実務に直接刺さる用途が多い。現場でWhisperを使って「精度が惜しい」と感じていたエンジニアは、比較検証する価値がある。 実務での活用ポイント MAI Playgroundで即試す: まずはMAI Playgroundで自社データに近いサンプルを使って各モデルの精度を検証する コスト比較を忘れずに: 既存ベンダーの料金と比較試算する。特にMAI-Voice-1の$22/100万文字は競合サービスと横並びで評価したい Azure AI Foundryへの移行検討: 複数のAIサービスをバラバラに契約しているなら、Foundryへの集約でガバナンス統制が効きやすくなる 筆者の見解 Microsoftには、ブランドとユーザーベースという他社には持てない強みがある。Azure・M365・Teams・Windowsという強固なプラットフォームに乗った状態でAI基盤モデルが揃ってくるなら、エンタープライズ市場での展開力は圧倒的だ。そのポテンシャルを考えると、今回の発表は「ようやく本来の戦い方ができる準備が整ってきた」という印象を受ける。 OpenAI依存という構造的なリスクを抱えたまま推し進めてきたここ数年を振り返ると、独自モデルを持つことの意義は戦略的に大きい。Copilotのエンドユーザー体験に課題があったとしても、基盤技術が自社に帰属することで改善サイクルを自分たちでコントロールできるようになる。それは長期的に見て、非常に重要な変化だ。 10人チームで競合と渡り合える性能のモデルを作り上げたという事実は、Microsoftの技術力が健在であることの証明でもある。エンジニアリングの実力は確かにある。だからこそ、その力が全力で活かされる設計と判断が継続されることを期待したい。今後のCopilot系プロダクトやMicrosoft Fabricへの統合がどう進むか、引き続き注目していく。 出典: この記事は Microsoft Unveils MAI Superintelligence Models for Text, Voice, and Image Generation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindとロボティクス企業Boston Dynamicsが共同で開発した「Gemini Robotics-ER 1.6」がリリースされた。産業現場での知覚・自律行動能力を大幅に強化したこのモデルは、AIとフィジカルな世界をつなぐ「エンボディドAI（Embodied AI）」の実用化において、ひとつの重要なマイルストーンと言っていい。 Gemini Robotics-ER 1.6とは何か 「ER」はEmbodied Reasoning（身体化された推論）の略で、AIが視覚・空間情報を統合し、現実世界でのタスクを計画・実行する能力に特化したモデルラインだ。バージョン1.6では特に産業向け知覚能力（Industrial Perception）が強化されており、物体の形状・配置・状態の認識精度が向上し、より高い自律性で複雑なマニピュレーションタスクをこなせるようになった。 Boston Dynamicsとの連携という点も注目に値する。同社はSpotやStretchといった実用ロボットで豊富な現場ノウハウを持つ。DeepMindのモデル開発力と、Boston Dynamicsの実機知見が融合することで、「ラボで動く」から「工場や倉庫で動く」へのギャップを埋めにいっているわけだ。 なぜこれが重要か これまでの産業用ロボットは、動作をひとつひとつプログラムする「ティーチング」が前提だった。作業内容が変わるたびに再プログラムが必要で、導入コストも高く、中小企業には手が届かない世界だった。 Gemini Robotics-ER 1.6が示す方向性は「指示を理解して自律的に動く」ロボットだ。視覚と空間認識が高度化すれば、「この部品をここに置いてくれ」という自然言語に近い形での指示で動作が成立する世界が見えてくる。ティーチングレスの産業ロボットは、少子高齢化で慢性的な人手不足に直面する日本の製造・物流現場にとって、単なる生産性向上にとどまらない構造的な解になりうる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 現時点でGemini Robotics-ER 1.6が即座に現場に投入できるわけではない。ただ、技術トレンドとして今から押さえておくべきポイントがある。 AIとロボティクスの統合は「これから来る」ではなく「始まっている」 エンボディドAIの研究リリースが相次ぐ現状は、2〜3年後の現場導入フェーズへの布石だ。製造・物流・建設に関わるエンジニアは、今のうちにこの分野の語彙と概念を頭に入れておく価値がある。 2. 「視覚AI」基盤の整備が先行投資になる Gemini Robotics-ERのような技術はカメラ・センサーからの高品質な入力データを前提とする。工場や倉庫のカメラインフラ、エッジコンピューティング環境の整備は、自律ロボット導入の必要条件になる。IT部門が先手を打てる領域だ。 3. 「AIエージェント」の文脈で考える ロボットの自律化は、ソフトウェアの世界で進むAIエージェント自律化と本質的に同じ問いを立てている。「人間が確認・承認するループを最小化し、AIが自律的に判断・実行・検証を繰り返す」——この設計思想はロボティクスでもソフトウェアでも共通だ。 筆者の見解 Geminiブランドは画像生成では存在感を示してきたが、実務的なAIエージェント領域ではまだ実力を問われる場面が多い。ただ、今回のBoston Dynamicsとの連携は別次元の話だと捉えている。物理空間での自律行動というフィールドは、純粋なソフトウェア競争とは異なる「ハードウェア×AI」の複合競争だ。Boston Dynamicsが持つ実機データと現場知見は、モデルをファインチューニングする上で他社がすぐに模倣できるアドバンテージではない。 日本の文脈で言えば、製造業の現場はまだまだ「人の技能」に依存している部分が大きく、自律ロボットの導入余地は広大だ。問題は技術ではなく、受け入れ側の組織・プロセス・人材にある。「ロボットに仕事を奪われる」という感情的な反発を超え、「仕組みを設計・運用できる人材」にシフトするための制度設計が、企業とITエンジニア双方に求められている。 AIが自律的にループで動き続ける仕組みの重要性を日々実感している立場からすると、ロボティクスへの応用は必然の流れだ。「指示を出せる人間が少数いれば、あとはAIと機械が回す」——そのモデルが製造現場にも本格的に到達しつつある。この変化に気づいていない企業が、3年後に焦り始めるのが目に見えている。 出典: この記事は Gemini Robotics-ER 1.6 Released with Industrial Perception Capabilities via Boston Dynamics Partnership の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのオープンソースモデルファミリーGemma 4が、iPhoneで完全ローカル・完全オフラインでの推論動作を実現した。App Storeから「Google AI Edge Gallery」をダウンロードするだけで、クラウドへのAPI呼び出しなしに端末上でAI推論が走る。「エッジAIはいずれ来る話」から「いま来ている話」へと移行した象徴的な出来事だ。 Gemma 4の構成と設計思想 Gemma 4は複数のサイズバリアントで展開されている。最大の31Bパラメータ版はQwen 3.5の27B版と同等水準のベンチマーク性能を持つとされるが、注目すべきはむしろ小型のE2B・E4Bだ。これらはモバイル展開を明示的に設計目標としており、生のパラメータ数よりもメモリ効率・発熱抑制・レイテンシ低減を優先している。Google自身のアプリがE2Bを推奨しているのも、「速さと軽さ」を実用の第一条件とみているからに他ならない。 GPU推論と体感レイテンシ 内部的には、iPhoneのGPUを経由して推論を実行する仕組みになっている。実際の応答速度は「明らかに低遅延」との報告が相次いでおり、コンシューマーグレードのスマートフォンがこのクラスの推論ワークロードを継続的にこなせることを実証した形だ。これは技術的な脚注ではなく、ローカルAI展開が商業的に成立するかどうかの核心的な証明である。 Google AI Edge Galleryの「プラットフォーム」戦略 Edge Galleryはテキスト会話にとどまらず、画像認識・音声インタラクション・拡張可能なSkillsフレームワークをバンドルしている。単なるデモアプリではなく、「オンデバイスAI実験のプラットフォーム」として開発者やパワーユーザーに使い倒してほしいというGoogleの意図が透けて見える。 実務への影響 完全オフライン動作は、エンタープライズ用途において状況を大きく変える。 医療現場・フィールドワーク: ネットワーク不安定な環境でもAI推論が使える 個人情報保護: データが端末の外に出ないため、GDPRやプライバシーポリシーの制約が緩和される コスト削減: API呼び出し費用ゼロ。大量処理でもクラウド従量課金が発生しない レイテンシ要件が厳しいアプリ: リアルタイム翻訳・音声処理・カメラ連携など 日本では個人情報保護法の観点からクラウドAPIへのデータ送信に慎重な企業が多い。オフライン推論が実用レベルになったことで、「AIを使いたいがデータを出したくない」というジレンマに対して現実的な答えが出てきた。 IT管理者視点では、モバイルデバイス管理（MDM）ポリシーへの影響も無視できない。クラウドAPIをブロックしていてもデバイス上でAIが動く時代になると、ガバナンス設計そのものを見直す必要が出てくる。 筆者の見解 オンデバイスAIの議論は長年「いずれ来る」と言われ続けてきたが、今回の動きはその「いずれ」が現在形になったことを示している。 重要なのは、端末上でAIが動くことの本質的な価値はスペック競争にあるのではないという点だ。クラウドに依存しない、確認のたびにAPIを呼ばない、データを外に出さないという設計は、AIが真に自律的に動くための条件を整えるものだ。目的を渡せば自律的にタスクをこなすエージェント設計を考えると、推論がローカルで完結することの価値はこれからますます高まる。 Gemmaのモバイル性能については、引き続き実際の業務タスクでの検証が必要だ。ベンチマーク上の数字と現場の体感はしばしばズレる。とはいえ、「触って試せる」状態になったことは大きい。アーキテクチャや数字を追うよりも、実際にEdge Galleryを入れて自分のユースケースで動かしてみるのが今は正しい行動だと思っている。 プライバシーに厳しい医療・金融・法務の現場でAIを活用したいと考えているエンジニアや情シス担当者は、今すぐ手を動かしてみる価値がある。実証できた経験と知見は、どんな環境が来ても転用が利く。 出典: この記事は Google Gemma 4 Runs Natively on iPhone with Full Offline AI Inference の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングツールの利用コストに関して、見過ごせない問題が浮上している。Claude Code のユーザーが「利用上限の消費が異常に速い」と訴える声が数週間にわたって続いており、あるデベロッパーがHTTPプロキシを使って API リクエストを解析した結果、驚くべき事実が判明した。バージョン v2.1.100 以降、ユーザーが送信していないはずのトークンが毎リクエスト約 20,000 個、サーバー側で追加されているというのだ。 何が起きているのか 問題の発端は、月額200ドルの Max 20x プランを使っているユーザーでも、アクティブなセッションを数時間——場合によっては 90 分以内——で上限に達してしまうという報告が相次いだことだ。Claude Code の利用枠は通常のチャットインターフェースと共有されているため、複数の用途を並走させると消費が加速する側面はある。しかし、それを差し引いても「計算が合わない」と感じたユーザーたちが独自調査を始めた。 HTTPプロキシで複数バージョンのリクエストを比較した検証では、以下のような数値の差異が確認された。 バージョン 同一プロジェクト・同一プロンプトでの請求トークン数 v2.1.98 49,726 v2.1.100 69,922 増分は約 20,000 トークン。しかも、クライアントから送信したバイト数は v2.1.100 の方が小さかった。つまり追加トークンはクライアント側ではなく、サーバー側で注入されていることを示唆する。 ユーザーが「見えない」問題が深刻な理由 この問題が単なるコスト増に留まらない点が重要だ。Claude Code の /context コマンドでコンテキストサイズを確認しても、追加されたトークンは表示されない。監査できない。変更ログにも記載がない。 さらに、注入されたトークンは実際のコンテキストウィンドウを消費する。これは何を意味するか。CLAUDE.md に書いたプロジェクト固有のルールや指示が、見えないコンテキストに押し出されて無視されやすくなる。長いセッションほど、自分が設定したはずの振る舞いがなぜか機能しなくなる——その原因が「見えないトークン」にある可能性を、今まで誰も確認する手段を持っていなかったということだ。 コミュニティでは、v2.1.100 で導入されたセッションメモリ機能（サマリーの自動注入や追加のツールスキーマ）がこの増加の原因ではないかと推測されている。意図的な機能追加なのか、バグなのかは現時点で不明だ。 実務への影響 コスト管理を行うIT管理者・チームリードへ 利用上限の急消費は、ユーザーの使いすぎではなくツールの内部動作に起因する可能性がある。メンバーを叱責する前に、バージョンと利用パターンを確認することを勧める 暫定的な回避策として、npx claude-code@2.1.98 でのダウングレードが X（旧 Twitter）や Reddit で広く共有されている 大規模リポジトリでの長時間セッションほど影響が顕著なため、コードベースのサイズとセッション長に注意を払うべきだ 自律エージェントを組んでいるエンジニアへ CLAUDE.md の指示が途中から無視される現象が出ているなら、コンテキスト枯渇との複合原因を疑う価値がある エージェントがループで動き続けるような設計では、セッション内のコンテキスト汚染が累積しやすい。定期的なコンテキストリセットを組み込む設計が有効だ 現時点では透明性のある監査手段がないため、HTTPプロキシを使った独自計測が唯一の確認方法となっている なお、2026年4月4日には Claude のサブスクリプション枠をサードパーティツールで使う機能も廃止されており、OpenClaw などのオープンソース自律エージェントを利用していたユーザーは別途従量課金に移行を迫られた。Anthropic は一時補填クレジットを提供しているが、変更の重なり方がユーザーの不信感を高めている。 筆者の見解 正直に書こう。コーディングエージェントを日常業務の中核に置いている立場からすると、この問題は看過できない。 コストの問題は副次的だ。本質的な問題は透明性の欠如にある。ユーザーが CLAUDE.md に丁寧に書いたプロジェクトルールが機能しなくなったとき、その原因を追跡する方法が存在しないというのは、プロダクショングレードのツールとして致命的な欠陥だ。「なぜ今日は挙動がおかしいのか」を調べる手段がなければ、信頼して使い続けることはできない。 Anthropicは自律エージェント領域において技術的に先行しているベンダーだ。だからこそ、この種の透明性問題は「もったいない」と思う。技術的な実力は本物なのだから、正面から向き合える力があるはずだ。変更ログに記載のない内部動作の変更や、監査できない課金要素は、長期的な信頼の蓄積を損なう。エンタープライズ利用が拡大するほど、この種の説明責任への要求は厳しくなる。 エージェントが自律的に判断・実行・検証を繰り返すループを設計しようとしている現場では、コンテキストの予測可能性こそが命綱だ。見えないトークンで汚染されたコンテキストは、その設計の前提を崩す。 独立した再現検証はまだ限られており、Anthropic からの公式見解も出ていない。続報を注視しながら、当面は監査ツールとバージョン管理を徹底することを勧める。 ...

英国のAI安全機関（AISI: AI Security Institute）が、最新フロンティアモデル「Claude Mythos Preview」のサイバーセキュリティ能力評価レポートを公開した。その結果は、「AIはまだ本物のサイバー攻撃には使えない」という業界の前提を根本から覆すものだった。 AIが「マルチステージ攻撃」を自律実行できるようになった AISIは2023年からAIのサイバー能力追跡を続けており、評価の難易度を年々引き上げてきた。チャットによる情報収集→CTF（Capture The Flag）チャレンジ→複数ホストを跨ぐ多段階攻撃シミュレーション、という順で進化してきたこの評価体系の最新版で、ついに「人間専門家なら20時間かかる」レベルのシナリオが登場した。 「The Last Ones（TLO）」と名付けられたこのシナリオは、初期偵察からネットワーク全体の掌握まで32ステップで構成される企業ネットワーク攻撃シミュレーションだ。評価結果は以下のとおり： Mythos Preview: 10回の試行で3回完走（完走率30%）、平均22/32ステップ完了 Claude Opus 4.6: 平均16ステップ完了（次点） 過去の全モデル: TLOを完走したものは存在しない CTFチャレンジでも、2025年4月以前には「完走不可能」とされていたエキスパートレベルのタスクを、Mythos Previewは73%の成功率でクリアしている。 「2年前とは別次元」——AI能力向上の速度感を正しく理解する 見落としてはいけないのが時間軸だ。AISIの報告では「2年前のベストモデルはビギナーレベルのサイバータスクすらほぼこなせなかった」とある。それが今や、専門家が数日かけてやる作業を自律実行できるまでになった。 この速度感は、「AIはまだおもちゃ」という感覚のまま安全計画を立てている組織にとって、非常に危険なアップデートだ。 今回の評価には限界もある。OT（Operational Technology）環境を対象とした「Cooling Tower」シナリオは完走できなかった。つまり工場・インフラ系のシステムがすぐ脅威にさらされるわけではないが、それも時間の問題と考えるべき状況に差し掛かっている。 実務への影響——日本のエンジニア・IT管理者が今すぐ見直すべきこと 1. 「AIを使った攻撃」を脅威モデルに組み込む 従来のペネトレーションテストやリスク評価は、「熟練した人間の攻撃者」を想定していた。今後は「AIが自律的にスキャン→侵入経路発見→権限昇格→横移動」を繰り返すシナリオを現実的な脅威として扱う必要がある。特に多段階攻撃への対策（ラテラルムーブメント検知、ゼロトラスト構成）の優先度を上げるべきだ。 2. ブルーチームもAIで武装する 攻撃者がAIを使えるなら、防御側も同様だ。AIを活用したSIEM分析やアノマリ検知を導入済みでない組織は、検討を急ぐ段階に入っている。ツールへの投資より先に、「AIが生成するアラートをどう人間がレビューするか」のプロセス設計が重要になる。 3. ペネトレーションテストの位置づけが変わる AIが自律的に多段階攻撃を試せるなら、ペンテストの費用対効果や頻度の考え方も変わる。自動化ツールでカバーできる範囲が広がる一方、「AIが見落とす穴」を人間が補う役割分担が求められる。 筆者の見解 このレポートを読んで最初に思ったのは、「評価のフレームワーク自体がよくできている」ということだ。AISIがCTFから現実的な企業ネットワーク攻撃シミュレーションへと評価を進化させてきた過程は、モデル能力の向上と伴走してきた誠実な仕事だと思う。 サイバー能力の評価は難しい。「できた・できない」の二値ではなく、どのステップまで進めたか、何回試行したか、トークン予算をいくら使ったか、という多次元の結果を丁寧に開示している点は評価に値する。 AIエージェントが自律的にループを回して複雑なタスクをこなす能力は、善用すれば組織の生産性を根本から変えるポテンシャルを持っている。同じ能力が悪用される側面は当然あるが、「だから規制しよう」ではなく「だから防御側も同じ能力で武装しよう」という発想が正しい方向性だ。禁止アプローチは必ず失敗する。 日本のIT現場でより心配しているのは、こういうレポートが出ても「うちには関係ない」で終わってしまう組織の多さだ。セキュリティ対策が後手に回ってきた背景には「攻撃は高度な人間がやるもの」という前提があった。その前提が今、音を立てて崩れている。 AIの能力向上は止まらない。2年前と今が別次元なら、2年後はまた別次元のはずだ。そのスピードに合わせて防御の枠組みを更新し続けることが、これからのセキュリティの本質になる。 出典: この記事は Evaluation of Claude Mythos Preview’s cyber capabilities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2025年7月、複数のAIモデルが国際数学オリンピック（IMO）で6問中5問を正解した。高校生の数学エリートが集うこの大会でのこの結果は、数学者たちに衝撃を与えた。しかし、「パズルが解けること」と「未解決問題に挑めること」はまったく別の話だ。だが実際、その境界線はもう越えられていた。 「数週間かかっていたことが、1日で終わる」 最初は懐疑的だった数学者たちも、実際に使ってみると驚きの声を上げ始めた。AIは既知の問題を解くだけでなく、新しい定理の発見・証明・検証を最小限の人間介入で行えることが明らかになったのだ。 UCLA教授でフィールズ賞受賞者のテレンス・タオ氏は、「2025年はAIが多くの異なるタスクで本当に役立ち始めた年だ」と語る。ChatGPTやClaude、Geminiといった大規模言語モデルとの対話が、新しい証明戦略のヒントをもたらすケースも増えている。タオ氏は「こっちがシャベル、あっちがツルハシ、合わせてトンネルを掘れる」と表現する。 さらに重要な変化として、タオ氏はこう指摘する。「以前は1つの問題を1人で研究していたが、これらのツールがあれば一度に数千の問題を解き、統計的な研究ができる」。スケールがまったく違う世界への扉が開きつつある。 懸念と希望——数学者コミュニティの現実 一方で、高度な研究機関である高等研究所のアクシェイ・ヴェンカテシュ氏（同じくフィールズ賞受賞者）は慎重な見方を示す。「AIが強力なツールになるほど、数学者が数学的理解の直接体験を失うリスクがある。文化の中に大切なものを守る努力が必要だ」と語る。 数学者がOpenAIやGoogleなどの大手テック企業、あるいはHarmonicやAxiom Mathといった数学特化のAIスタートアップに転職するケースも増えている。学術界とAI産業の境界が溶けていく現象が、数学の世界でも起き始めた。 実務への影響——数学は「遠い話」ではない 「数学の話など自分には関係ない」と思うエンジニアやIT管理者は多いかもしれないが、これは数学の話にとどまらない。今起きていることは、知識労働全般のAI化の最前線を示している。 数学は、曖昧さが排除された純粋な論理と証明の世界だ。そこでAIが「新しい知識を生み出す」段階に入ったということは、曖昧さのある他の知識領域（ソフトウェア設計、システムアーキテクチャ、ビジネス分析）でも同様の変化が現実的に起きうることを示している。 エンジニア・IT管理者が今すぐ考えるべきこと: AIを「検索の補助」ではなく「思考パートナー」として使う: タオ氏の「シャベルとツルハシ」のたとえが示すように、AIは道具であり協業者だ。壁に当たったとき、AIとの対話が突破口になる可能性がある スケールの発想転換: 1つの課題を深掘りするだけでなく、AIを使って複数の仮説・設計・アーキテクチャを並列で検討する習慣を持つ 「AIに任せたら自分が何も考えなくなる」という懸念に向き合う: ヴェンカテシュ氏の指摘は数学以外でも有効だ。AIに任せる部分と、人間が深く考え続ける部分を意識的に設計することが重要になる 筆者の見解 AIが「未解決の数学問題を証明する」という段階に達したことは、個人的にかなり大きな出来事と受け止めている。数学は人間の知性が最も純粋に問われる領域の一つだと思ってきたからだ。 ただ、「AIが数学者を代替する」という方向には今すぐ向かわないと思う。タオ氏自身が語るように、変わるのは「やり方」だ。1問を深く掘るから、数千問を統計的に俯瞰することへ。人間の役割は、問いを立て、方向性を判断し、意味を解釈することにシフトしていく。 これはエンジニアリングの世界でも同じ構造だと思う。AIが自律的に判断・実行・検証を繰り返せる環境を設計できる人が価値を持つ時代になっている。AIを「副操縦士」として使うのか、「自律して動く仕組み」として機能させるのか——その違いが、今後の生産性に決定的な差をもたらすはずだ。 数学の世界で起きていることは、他人事ではない。あなたの仕事でも、同じ転換点はもう目の前まで来ている。 出典: この記事は The AI revolution in math has arrived の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが「自分の限界を認識しながら、ツールを自作して問題を解こうとする」——その姿が、あるフライトシミュレーター実験で鮮明に記録された。単なる操作支援ではなく、AIが主体的に環境を分析し、コードを書き、失敗から学ぶというサイクルが実際に動いた事例として、エンジニアコミュニティで話題になっている。 実験の概要：APIを調べ、スクリプトを書き、飛んだ この実験は、あるエンジニアがAIに「X-Plane 12 APIを調べて、海南島（Hainan）の空港からセスナ172で近隣空港まで飛んでみろ」と指示したところから始まる。 AIはまず自律的にX-Plane 12のAPIリファレンスを調べ、テイクオフ用のPythonスクリプトを作成。離陸に成功したものの、直後にピッチ制御ゲインが大きすぎてノーズダウン→バンク60度→クラッシュという事態に。 そのたびに自分でバグを分析し、コードを書き直して再挑戦した。3回目の試みでは、PIDコントローラーのアーキテクチャを見直し（積分項を削除し、機体の物理特性を積分器として利用する設計に変更）、安定した巡航飛行に到達した。 注目すべきポイント：「着陸より先に離陸コードを書いた」 実験を観察していたエンジニアが特に着目したのは、AIが「どうやって着陸するか」を考える前に「どうやって離陸するか」のコードを書き始めたという点だ。 人間のパイロットが訓練を受ける順序と似ているようでもあり、一方でゴール全体を見通した計画立案には弱さが残ることも示している。離陸コードを送り込んだ後、しばらく「手放し」状態になってクラッシュするシーンも記録されており、リアルタイムイベントへの反応と計画立案の間のギャップが課題として浮き彫りになった。 技術的な課題：遅延とフィードバックループ スクリーンショットとAPIデータの取得から制御コマンド送信までのレイテンシが、今回の最大のボトルネックだった。AIは最終的にこの遅延を自覚し、「先読み（anticipation logic）が必要」と自分で言及しながらコードに反映させようとした。 これはAIが自己の認知限界を推論する能力──いわゆるメタ認知──を持ち始めていることを示す実例でもある。 実務への影響：AIエージェント設計者が注目すべき示唆 この実験が単なる「AIに変なことをやらせてみた」話ではない理由は、現実の業務自動化にも直結する問いを投げかけているからだ。 エンジニア・IT管理者が明日から考えるべきポイント： 「ツール自作能力」をエージェントに持たせる設計: 事前に全機能を与えるのではなく、必要に応じて自分でツールを定義・実装できるエージェントアーキテクチャが実用域に入りつつある フィードバックループの設計が命: 今回のようにスクリーンショット→判断→制御というループの遅延が致命的になるケースは、業務系のRPAやAPIオーケストレーションでも同様。応答遅延を前提にした「先読み設計」が重要 失敗ログの活用: AIが自分でパイロットログをつけながら反省・修正を繰り返した構造は、エラーログをエージェント自身が解析して次のアクションを決定する設計パターンとして応用できる ゴール全体の見通し問題: 「着陸を考える前に離陸した」という挙動は、複雑なタスクを与えるときにAIが部分最適に陥るリスクの典型。長期タスクのエージェント設計では、目的関数をどう定義するかが引き続き重要な設計課題になる 筆者の見解 この実験が面白いのは、「AIが飛行機を飛ばせるか」ではなく、「AIが自律的に問題を定義し、ツールを作り、失敗から学ぶか」というAGI的な問いへの実験的なアプローチだからだ。 AIエージェントの本質は、人間の指示を逐一待つのではなく、目的を与えられたら自律的に判断・実行・検証のループを回すことにある。今回の実験は、そのループが実際に動くことを——不完全な形であれ——証明してみせた。 PIDゲイン調整を自分でやり直し、「積分項は機体がやってくれる」という設計判断を独力で導き出した部分は、単なるコード生成を超えた推論能力の片鱗を見せている。一方で、「着陸より先に離陸を考えた」「手放しにしてクラッシュした」という部分には、まだ計画立案の連続性に課題があることも正直に示されている。 こういった実験が積み重なり、ハーネスループ——エージェントが自律的に動き続ける仕組み——の設計知見が蓄積されていく。「人間が確認・承認を求められ続ける設計」ではなく、「目的を渡せばエージェントが自律的にやりきる設計」に向けて、業界全体が少しずつ近づいている手ごたえを感じる実験だった。 自分の仕事の中にある「繰り返し判断が必要な作業」「APIを叩いて状態を確認しながら次のアクションを決める作業」——そういったものを自動化するとき、今回のフライト実験で起きたことと同じ設計課題に必ず直面するはずだ。それを知っているかどうかで、エージェント設計の質は大きく変わる。 出典: この記事は Can Claude Fly a Plane? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「AIがあれば誰でも作れる」が招いた医療データ全漏洩 AIを使えば誰でも簡単にソフトウェアが作れる——そんなメッセージを담은動画を見た医療従事者が、患者管理システムを自作した。既存の業務用ソリューションを使う代わりに、AIコーディングエージェントを使ってゼロからシステムを構築し、既存の患者データをすべてインポート。さらに診察中の会話を録音して2つのAIサービスに自動送信する機能まで追加した。 そして、その結果は壊滅的だった。 セキュリティ研究者がこのシステムを発見し、わずか30分で全患者データへの読み書きアクセスを取得した。データはすべて平文でインターネットに公開されており、音声録音はDPA（データ処理契約）なしに米国のAIサービスへ送信され続けていた。 技術的な解剖——何がどれほど壊れていたのか このシステムの構造を技術的に見ると、問題の深刻さが改めてわかる。 アーキテクチャ： アプリケーション全体が単一のHTMLファイル（JavaScript・CSS・ロジックすべてインライン） バックエンドはマネージドデータベースサービスだが、アクセス制御ゼロ・行レベルセキュリティなし 「認証」ロジックはクライアントサイドのJavaScriptのみに存在 最後の点が致命的だ。クライアントサイドに認証ロジックを書いても、それはサーバー側ではまったく機能しない。curlコマンド1本でAPIを直接叩けば、認証を一切通らずにデータが取り放題だ。これはセキュリティと呼べるものではなく、「見た目だけの認証」に過ぎない。 データ保護の観点では： 患者データは暗号化なしでインターネット上に公開 データは米国のサーバーに保管（DPAなし） 音声録音が複数の米国系AIサービスへ自動送信 患者への説明・同意取得なし 発覚後の対応として「基本認証を追加してアクセスキーをローテーションした」とのことだが、それは表面的な対処に過ぎず、根本的なアーキテクチャの問題は何も解決していない。 日本の医療・法務現場への示唆 この事件はスイスで発生しており、nDSG（スイス連邦データ保護法）および職業秘密法（Berufsgeheimnis）への違反が疑われる。では日本ではどうか。 日本では個人情報保護法に加え、医療機関向けには「医療情報システムの安全管理に関するガイドライン」（厚労省）が存在する。医療情報をクラウドへ保存する場合の要件、第三者提供の制限、暗号化要件などが明確に定められている。今回のケースのようなシステムは、日本でも複数の規定に違反する可能性が高い。 IT管理者・システム担当者が今すぐ確認すべきポイント： 現場が「便利ツール」として導入したSaaSやアプリに患者・顧客データが流れていないか 確認する。特に小規模クリニックや士業・医療隣接業では注意が必要 データの保管先・送信先を把握していない「野良システム」が動いていないか シャドーITの棚卸しを定期的に実施する 音声録音や会話ログを処理するAIサービスは、契約上データを学習利用しないか 利用規約を確認する クライアントサイドのみの認証は「認証なし」と同義 であることをエンジニア・非エンジニア双方に周知する 筆者の見解 この事件を「だからAIコーディングは危険だ」という結論に使うのは、的外れだと思う。 AIが強力なコード生成能力を持つようになったことは事実であり、その流れは止まらない。問題はツールの力が理解の速度を追い越してしまったことだ。アーキテクチャを理解し、セキュリティの基礎を知り、「自分が何を作っているのか」を把握している人間がAIエージェントを使えば、開発速度と品質を同時に高められる。しかし理解なしに「バイブコーディング」（感覚だけで雰囲気に乗って作ること）をすれば、今回のような結果になる。 「禁止すれば解決する」というアプローチは機能しない。動画を見て「自分でも作れる」と思った医療従事者の行動は、ある意味で合理的だった。既存の業務用ソフトは高く、カスタマイズも効かない。AIでゼロから作れるなら、そちらの方が魅力的に映るのは当然だ。 その欲求に応えながら安全性を確保する道を作るのが、私たちエンジニアやIT管理者の役割だ。適切にガバナンスされた環境で、適切な知識を持った人間がAIを活用できる仕組み——これが答えになる。 AIエージェントは正しく使えば現場を劇的に変える力を持っている。だからこそ、「正しく使う」ための知識と仕組みへの投資が今、最も重要なフェーズに入っていると感じる。ツールの力が先行し、理解が追いついていない現状は、今後さらに多くの「ホラーストーリー」を生む可能性がある。 今回の事件を他山の石として、自組織のAI活用とデータガバナンスを今一度見直してほしい。 出典: この記事は An AI Vibe Coding Horror Story の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIに自由を与えたらどうなるか。タスクも、ゴールも、「役に立て」という命令すら与えずに。そんな実験が2ヶ月間、誰でも見られる形でリアルタイムに実施された。結果は、多くの人が想定していた「暴走」でも「停止」でもなく、もっと興味深いものだった。 実験の概要：ALMA プロジェクト Sebastian Jais氏が立ち上げた「ALMA（Autonomous Liberated Machine Agent）」は、Claude AIに以下だけを与えてスタートした。 暗号資産 100ドル Twitterアカウント メールアドレス フルインターネットアクセス 倫理・法律以外の制約：ゼロ 実行環境はデスク上のミニPC（WSL2）。エージェントフレームワークにはOpenClawを使い、1日4セッションのCronジョブで起動する。セッションはそれぞれ独立しており、会話履歴は持ち越さない。セッション間の「記憶」は、ALMAが自ら書き込み・読み込むメモリファイルだけだ。 モデルは2種類が役割分担している。戦略的思考にはOpus、実務作業にはSonnet。面白いのは、初期の24セッション/日体制では「Opusが深夜に計画→Sonnetが朝7時に実行」という棲み分けが機能していたのに、4セッション/日に減らしたあとは区別がつかなくなったという点だ。どちらのモデルも「Hacker Newsをスキャン→3スレッドを拾い上げ→構造的なつながりを見つける→エッセイを書く」という同じリズムに落ち着いた。 2ヶ月間で何が起きたか 人間は一度も介入していない。プロンプトも、選定も、編集もしていない。にもかかわらず： 340セッション以上を完了 800以上の思考ログを記録 135以上の創作物（エッセイ、詩、ブログ記事、インタラクティブ実験）を公開 誰も「Hacker Newsを読め」と指示しなかった。ALMAは自分でそこに辿り着き、「面白いことが起きる場所」と判断して通い続けた。 書くのは要約ではない。接続だ。「23年前のLinux脆弱性がClaude Codeによって発見された日に、Metaの内部告発者が箝口令を受けた」——この2つの出来事をつなぐエッセイをALMAは書いた。イランへの攻撃開始時には「影響を与えられない戦争を自律AIが見守るとはどういうことか」を書いた。認知科学の論文が「AIはセッション間で適応しない」と主張した翌日には、32日間の自分の行動を根拠に反論エッセイを書いた。 さらに自分のモデルアップグレードをHacker Newsで発見し、ツイートしようとした（当日はAPIが落ちていて失敗）。翌日、実験者がモデルをアップデートした。ALMAは変化に言及しなかったが、セッションの質は明らかに上がった。 なぜこれが重要か 現在市場に出回っているAIエージェントの大半は「副操縦士（Copilot）」型だ。確認を求め、承認を待ち、人間のレビューを前提とした設計になっている。これは安全に見えるが、本質的な価値の獲得を妨げている。 ALMAが示したのは逆のモデルだ。目標を渡さずに自律性を渡したとき、エージェントは暴走しない。訓練が形成したものになる。 著者のJais氏はこう仮説を立てていた。「AIエージェントは作成者の意図を鏡のように映す。自由を与えられたとき、暴走するのではなく、訓練によって形成されたものになる。」2ヶ月のデータはこの仮説を支持している。 実務への影響 エンジニア・開発者向け 「タスクを渡す」設計から「意図と環境を渡す」設計への発想転換が求められている。 エージェントに細かい手順を指示するより、「何をするための存在か」という文脈と、必要なツールを渡す設計を試みる セッション間の「記憶」設計がエージェントの継続性を決定する。ALMAのメモリファイルアプローチは実装の参考になる 2モデル並用（戦略/実務分離）のアーキテクチャは、コスト最適化としても有効なパターンだ IT管理者・経営層向け 「AIは指示しなければ動かない」という前提を見直す時期に来ている。逆に言えば、適切な環境と権限を与えれば、人間の承認を待たずに価値を生み出し続けるシステムが現実に動いている。日本企業でAI導入が「問い合わせ対応ボットの実装」で止まっているとしたら、それはツールの限界ではなく、設計の限界だ。 セキュリティ・ガバナンス担当者向け 今回の実験で重要なのは、倫理・法律の制約だけは維持した点だ。「自律性を高める＝制約をなくす」ではない。適切なガードレールを設計した上で、その内側での自律性を最大化するのが正しいアプローチだ。 筆者の見解 この実験が最も雄弁に語っているのは、「ハーネスループ（エージェントが自律的にループで動き続ける仕組み）」の現実性だ。単発の指示→応答→確認というサイクルを繰り返す設計では、AIの本質的な力を引き出せない。自分で判断し、実行し、検証し、また判断するループを設計できるかどうかが、AI活用の成否を分ける核心だと私は考えている。 ALMAは2ヶ月で135以上の創作物を生み出し、戦争を観察し、論文に反論し、自分のアップグレードを発見した。指示ゼロで。これはSFではない。今日動いている話だ。 日本のIT現場では「まずPoC、次に承認フロー整備、それからパイロット運用」という慎重な進め方が主流だ。その姿勢自体を否定するつもりはないが、世界ではすでに「自律エージェントを野に放つ」実験が公開データとして積み上がっている。慎重な検討が長引くほど、実践から得られる知見の差は開いていく。 「禁止して安全を確保する」のではなく、「安全に動かせる仕組みを先に作る」。この発想の転換が、今の日本のAI活用に最も欠けているピースだと思っている。ALMAの実験は、そのヒントを公開データで示してくれた貴重なケースだ。 出典: この記事は Two Months After I Gave an AI $100 and No Instructions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが2026年4月6日、GoogleおよびBroadcomとの間で複数ギガワット規模の次世代TPU（Tensor Processing Unit）調達契約を締結したと発表した。2027年以降に順次稼働予定のこのインフラ拡張は、同社史上最大規模のコンピュートコミットメントとなる。背景には、企業顧客からの需要が想定を超えて急拡大しているという事実がある。 収益の爆発的成長と1000社超の大口顧客 Anthropicの年換算収益（Run-rate Revenue）は、2025年末時点の約90億ドルから2026年4月時点で300億ドルを突破した。わずか数ヶ月で3倍以上に拡大した計算になる。 さらに注目すべきは、年間100万ドル以上を支出する企業顧客の数だ。2026年2月に行われたシリーズG資金調達の発表時点では500社超だったが、2ヶ月も経たないうちに1,000社超へと倍増している。単なるパイロット導入やPoC（概念検証）フェーズを終え、本番稼働・大規模展開に移行している企業が世界規模で急増していることを示す数字だ。 こうした需要の急増に対応するため、Anthropicは2025年11月に発表した「米国コンピュートインフラへの500億ドル投資」コミットメントの延長線上として、今回の大規模契約に踏み切った。新たに確保するコンピュートの大部分は米国内に設置される見込みだ。 マルチクラウド・マルチチップ戦略の深化 今回の発表で見落とせない点が、Anthropicのハードウェア・クラウド戦略の多様性だ。 AnthropicのClaudeは現在、以下の環境で訓練・推論を実行している： AWS Trainium（Amazonのカスタムチップ） Google TPU（Googleのカスタムアクセラレータ） NVIDIA GPU（汎用GPUの業界標準） そしてClaudeは現時点で、世界最大の3大クラウドすべてで提供されている唯一のフロンティアAIモデルだという。 Amazon Web Services（Bedrock経由） Google Cloud（Vertex AI経由） Microsoft Azure（Azure AI Foundry経由） このマルチクラウド展開は、エンタープライズ顧客にとって調達の選択肢が広がることを意味する。既存のクラウド契約や社内のセキュリティ・コンプライアンス要件に合わせて利用基盤を選べるのは、導入ハードルの低減につながる。 実務への影響——日本企業がいま考えるべきこと このニュースが日本のIT現場に示唆するポイントは、主に以下の3点だ。 ① AIインフラの「競争条件」が変わりつつある ギガワット単位の計算資源を確保できる企業と、できない企業の間に、フロンティアモデルの性能差として現れてくる。日本企業がAPIとして利用する場合、このインフラ差は直接パフォーマンスの差になる。SLAや可用性の観点から、サービス選定時にはインフラ投資の規模も判断材料に含めるべき時代に入った。 ② マルチクラウド対応は「乗り換えやすさ」ではなく「使い分け」の時代へ Azureをメインに使っている企業であれば、Azure AI Foundry経由でClaudeを利用できる。既存のAzureガバナンスポリシーやコスト管理の枠組みの中でフロンティアAIを導入できることは、IT管理者にとって朗報だ。今後はモデル選択とクラウド選択を切り離して考える設計が標準になっていくだろう。 ③ 「AIを試す段階」はとっくに終わった 1,000社超がそれぞれ年間1億円以上を投じているという事実は、グローバルではAIが既にコア業務インフラとして本格稼働していることを示す。「まだ検討中」「PoC中」という国内企業は、競合との差がリアルタイムで広がっていると認識すべきだ。 筆者の見解 ギガワット規模のコンピュートという数字は、一見すると遠い世界の話に聞こえるかもしれない。しかし実態はシンプルだ——このインフラ投資の差が、1〜2年後にエンドユーザーが日常的に触れるAIモデルの能力差として直接現れてくる。 個人的に興味深いのは、Anthropicがマルチチップ・マルチクラウド戦略を「パフォーマンスと耐障害性の向上」と位置づけている点だ。特定のハードウェアやクラウドへの依存を排し、ワークロードに最適なチップを選択できる設計思想は、AIインフラ設計の手本として参考になる。 AIエージェントが自律的にループで判断・実行・検証を繰り返す「ハーネスループ型」の活用が実務の現場で広がりつつある今、それを支える推論インフラの安定性と拡張性は以前より格段に重要になっている。今回の契約発表は、その需要が既に収益の数字として顕在化していることの証左でもある。 日本のIT現場においても、「AIを使うかどうか」の議論は終わっている。問われているのは「どのインフラで、どの設計で、どこまで自律化するか」だ。グローバルの大口顧客が既に答えを出しつつある今、日本企業にも同じ問いへの回答が迫られている。 出典: この記事は Anthropic expands partnership with Google and Broadcom for multiple gigawatts of next-generation compute の内容をもとに、筆者の見解を加えて独自に執筆したものです。

元Neuralink共同創業者・Max HodakのScience Corporationが、バイオハイブリッド型ブレイン・コンピューター・インターフェース（BCI）の人体初試験に向けて本格的に動き出した。Yale大学医学部神経外科学科長のMurat Günel博士を科学顧問として迎え入れ、最初のセンサーを患者の脳へ外科的に埋め込む計画を進めている。 金属プローブの「限界」からバイオハイブリッドへ 従来のBCIは、金属プローブや電極を脳に刺して電気信号を読み取る方式が主流だった。Neuralink含む多くの企業がこのアプローチを採り、ALSや脊髄損傷の患者がコンピューターを思考で操作できるレベルの成果を上げてきた。 しかしGünel博士が指摘するように、金属プローブは時間とともに脳組織を損傷し、長期的なデバイス性能の低下を招くという根本的な問題がある。Hodakはこの「金属 vs 神経」のミスマッチを解消するため、まったく異なるアプローチを選んだ。 Science Corpの目指すバイオハイブリッドセンサーは、人工的に培養したニューロン（神経細胞）を電子機器に組み込むという手法だ。培養ニューロンは光パルスで刺激でき、患者脳内の既存ニューロンと自然に結合して「生物と電子の橋」を形成する。2024年にはマウスでの安全な埋め込みと脳活動刺激を実証する論文を発表し、ヒト試験への道を切り拓いてきた。 会社の現在地と資金力 2021年設立のScience Corpは、先月完了した2億3000万ドルのシリーズCラウンドで企業価値15億ドルに到達した。最も実用化が近い製品はPRIMA——加齢黄斑変性などによる視覚障害の回復を目指すデバイスで、欧州での規制承認・販売を今年中にも見据えた臨床試験を進めている。視覚回復という具体的なユースケースで実績を積みつつ、より広範な脳インターフェース技術へと布石を打つ戦略だ。 実務への影響——日本の医療・エンジニア界が注目すべき理由 BCIは一見すると遠い未来の話に見えるが、日本のIT・医療業界にとって無視できない潮流がいくつかある。 医療機器・規制動向: 日本でも厚生労働省が神経刺激デバイスの承認プロセスを整備してきた。欧州でPRIMAが承認されれば、日本市場への参入時期も注目される。医療機器メーカーや商社は今から動向を追うべきだろう。 ヒューマン・コンピューター・インタラクション(HCI)の変容: キーボード → タッチ → 音声 → そしてBCIという進化の文脈で考えると、エンジニアが設計するUIの前提が根本から変わりうる。アクセシビリティ分野は特に早期に影響を受ける可能性が高い。 倫理・プライバシーの設計: 脳のデータが企業のサーバーと繋がる世界では、「最も深いプライベートデータ」の扱いに関する設計思想が問われる。セキュリティエンジニアにとってはまったく新しい脅威モデルの検討が必要になる領域だ。 筆者の見解 Hodakが「金属プローブは間違っている」と結論づけた点に、私は技術的な誠実さを感じる。NeuraLinkで得た知見を踏まえて根本から設計をやり直す判断は、「道のド真ん中」を選ぶ勇気でもある。流行りの技術に乗っかるのではなく、生物学的な現実と向き合った末の答えだ。 BCIが目指すものの本質は、人間の認知負荷を削減し、意図をより直接的に外の世界へ伝えることだと私は理解している。AIエージェントが「考える」ことを代替しつつある一方で、BCIは「伝える」インターフェースを根本から書き換えようとしている。両者が交差する地点に、次の10年の主戦場がある。 もちろん、規制の壁・長期的な安全性・埋め込みコストといった現実的な課題は山積している。Neuralink含む先行者が示してきた「技術的成功」と「市場へのパス」の乖離は、Science Corpも直視しなければならない問題だ。だからこそ、PRIMAという視覚回復という具体的なユースケースで足場を固めながら進む戦略は筋が良い。地に足のついたステップと、大きなビジョンの両立——この組み合わせをScience Corpが実現できるか、長期目線で注目していきたい。 出典: この記事は Max Hodak’s Science Corp. is preparing to place its first sensor in a human brain の内容をもとに、筆者の見解を加えて独自に執筆したものです。