Google DeepMindがA24に7,500万ドルを投資——映画監督と組んで開発するAIフィルムメイキングツールの全貌

Google DeepMindは、インディー映画スタジオA24に7,500万ドル(約110億円)を投資し、映画制作向けAIツールを共同開発するパートナーシップを締結したと発表した。同社CEOのデミス・ハサビス氏は「アーティストを支援するツールを作る最善の方法は、彼らと直接協力することだ」と述べており、A24からのフィードバックを受けながらツール開発を進める「業界初の取り組み」として位置づけている。 A24はどんなスタジオか A24は、アカデミー賞を席巻した『エブリシング・エブリウェア・オール・アット・ワンス』や、最新話題作『Backrooms』などで知られるインディー映画スタジオだ。ティモシー・シャラメやアン・ハサウェイといった大物俳優とのプロジェクトでも存在感を示しており、ハリウッドにおける「芸術性と興行成績の両立」を体現するスタジオとして高く評価されている。 このA24を提携先に選んだことは、Google DeepMindのメッセージとして明確だ——「AI映像生成は商業コンテンツの量産ではなく、作家性ある表現を支援するものだ」という宣言に近い。 「アーティスト主導」のAI開発という設計思想 今回の提携で注目すべきは、その構造だ。Google DeepMindがA24から「フィードバックと指導(feedback and guidance)」を受ける形でツールを開発するという設計は、技術企業がプロダクトを作ってから現場に押し付けるアプローチとは逆向きになっている。 映画監督や制作スタッフなど実際の創作者が設計段階から関与することで、「技術ありきのAI」ではなく「創造の道具としてのAI」を目指す意図が読み取れる。ハサビス氏が語る「authentic, meaningful storytelling(真摯で意味のあるストーリーテリング)」という言葉は、これまでのAI映像生成に向けられてきた「本物らしさがない」「表現が空虚だ」という批判への直接的な回答でもある。 ハリウッドにおけるAI導入の潮流 A24とGoogle DeepMindの提携は、ハリウッドにおけるAI活用の大きな流れの一部だ。 Netflix: 2026年初頭、ベン・アフレック率いる映画制作向けAIツール会社InterPositiveを買収 Amazon MGM Studios: テレビ・映画制作ツールに特化したAIユニットを設立 一方で、AI活用への反発も根強い。俳優組合(SAG-AFTRA)や脚本家組合(WGA)は、AIによる俳優の映像・声の無断使用や脚本の自動生成を主要争点として大規模ストライキを行った経緯がある。A24は比較的アーティスト寄りのスタジオとして知られているだけに、今回の提携が組合側とどう折り合いをつけるかは引き続き注目点だ。 日本の映像制作・エンタメ業界への示唆 日本でも映像制作にAIを活用する動きは始まっており、CM制作やアニメの中間素材生成、字幕翻訳の自動化などは実用段階に入りつつある。Google DeepMindとA24の提携から生まれるツールが実用化されれば、以下のような応用が想定される。 プリプロダクション段階: 絵コンテや世界観設定のビジュアライゼーション支援 ポストプロダクション: VFX処理の自動化・効率化 配給・マーケティング: 地域ごとのポスターやトレーラー素材の生成 ただし、日本では映像著作権の扱いや権利処理の慣習が欧米と異なる部分も多く、ツールの直輸入が難しいケースも出てくるだろう。法制度面での整備と並行した、慎重な導入検討が求められる。 筆者の見解 AIと創造の関係を巡る議論は、「使うべきか否か」という二項対立で語られがちだ。しかし今回の提携が面白いのは、その問いに対して「アーティスト自身が設計に参加する」という形で答えようとしている点にある。 「禁止するか、丸投げするか」ではなく、「創作者が主体的に使いこなせる仕組みを作る」というアプローチは、AIツール開発のあるべき姿に近い考え方だ。AI活用で本当に重要なのは、技術そのものの性能よりも「誰が、どのような文脈で、何のために使うか」を設計の起点に置くことだからだ。 映画は数千人規模のクリエイターが関わる巨大な共同作業だ。AIがその連携を加速させ、表現の幅を広げる方向で機能するなら、歓迎すべき変化といえる。一方、コスト削減を目的に人間の仕事を機械的に置き換えるだけの使われ方になれば、技術への反発はさらに強まるだろう。 今後はA24の実際の作品の中で、アーティストたちがこのツールをどう評価するか——その声が、AI映像制作ツールの設計に関する最も信頼できるフィードバックになると思っている。 出典: この記事は Google DeepMind bets $75M on AI’s future in Hollywood with A24 deal の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 23, 2026 · 1 min · 胡田昌彦

SpaceXがオープンソースAI「Reflection AI」と月1.5億ドルの計算資源契約を締結——Colossus 2のGB300チップでオープンウェイトAI開発を本格化

オープンソースAIスタートアップのReflection AIは、SpaceXと月額1億5,000万ドル(約225億円)の計算資源契約を2026年7月1日から締結した。AnthropicとGoogleに続く形で、米テネシー州メンフィス近郊のColossus 2データセンターにてNvidiaの最新GB300チップを確保し、オープンウェイトAIモデルの大規模開発を加速させる。 Reflection AIとは——元Google DeepMind研究者が立ち上げたオープンソースの挑戦者 Reflection AIは2024年、元Google DeepMindの研究者2名が共同創業したスタートアップだ。AnthropicやOpenAIのような「クローズドフロンティアラボ」への対抗軸として、オープンウェイト(open-weight)戦略を核に据えている。 オープンウェイトモデルとは、学習済みパラメータを公開するAIモデルのこと。MetaのLlamaシリーズがその代表例だ。クローズドモデルのAPIを介してのみ利用するアプローチとは異なり、モデルそのものを入手してオンプレミスやプライベートクラウドで稼働させられるため、データ主権やコスト管理の観点から企業・政府に支持されている。 契約の詳細——最大63億ドル規模の3年間合意 今回の契約は同社にとって初の大型計算資源契約となる。主な条件は以下のとおりだ。 契約期間: 2026年7月1日〜2029年 月額: 1億5,000万ドル(約225億円) 総額: 最大63億ドル(約9,450億円) 施設: SpaceXのColossus 2データセンター(テネシー州メンフィス近郊) ハードウェア: NvidiaのGB300 AIチップおよび関連機材 解約条件: 最初の3ヵ月経過後、90日前通知でどちらからでも解除可能 同規模の契約を比較すると、Anthropicは月12億5,000万ドル、Googleは月9億2,000万ドルでSpaceXと契約している。Reflection AIはこれらより規模が小さいものの、「オープンソース陣営として最大規模のAIインフラ投資」と自社を位置づけている。 なぜColossus 2なのか——xAI統合後のSpaceXがインフラハブへ Colossus 2データセンターは、もともとイーロン・マスク氏が設立したAI企業xAIが自社AI開発のために建設したものだ。しかし内部プロジェクトの進行が計画通りに進まなかったこともあり、xAIはSpaceXに統合された。SpaceXはこの膨大なGPUリソースを第三者に貸し出すビジネスモデルに転換し、世界トップクラスのAIラボへ提供している。 GPUリソースを持つ企業が「クラウドプロバイダー」化するという動きは、かつてのAWSの誕生を彷彿とさせる。余剰インフラの収益化が新たなビジネスモデルとして定着しつつある。 オープンウェイトAIへの追い風——政府の政策変化が後押し Reflection AIが今回の契約発表で強調したのが「オープンソースの重要性」だ。クローズドモデルへの依存リスクを各国政府・企業が意識するようになったことが、同社の戦略への共感を生んでいるという。 「特定の企業のクローズドモデルだけに依存するリスクとコストを、より多くの国家・企業が認識するようになっている」——同社はこう声明で述べ、オープン戦略の優位性を訴えた。 実務への影響——日本のエンジニア・IT管理者が今押さえるべきポイント 1. ベンダーロックインリスクの再評価 「特定ベンダーのAPIだけに依存する」リスクは日本企業でも普遍的だ。AIガバナンスの観点から、社内インフラに展開できるオープンウェイトモデルの選択肢を一度棚卸しすることを推奨する。 2. GB300チップ世代の計算力スケールを把握する NvidiaのGB300(Blackwell Ultra世代)は、現行のH100/H200と比べてメモリ帯域・推論スループットが大幅に向上している。この規模のチップを各社が確保していることは、次世代フロンティアモデルの学習・推論コストが今後さらに下がる可能性を示唆している。API料金の低下という形で、数年以内に企業の実務にも恩恵が及ぶだろう。 3. 機密データを扱う業種はオープンウェイト展開を本格検討する時期 金融・医療・製造など機密データを扱う業種では、クラウドAPIを介さずモデルを社内展開する「オープンウェイト自前運用」が優位になるケースが増えている。Reflection AIのような企業の台頭は、その選択肢の質と量を底上げする。 筆者の見解 「オープンvsクローズド」の議論は単なる思想の対立ではなく、AIインフラの地政学として現実に形になりつつある。Reflection AIのような企業が大規模な計算資源を確保し、オープンウェイトモデルの開発を本格化させることは、AI生態系の多様性という観点から歓迎できる動きだ。特定の少数企業がフロンティアモデルを独占する状況が続けば、価格支配力・サービス停止リスク・政策変更リスクが企業に集中する。その意味で、競争軸が増えることは利用者側に有利だ。 ただし「オープン=安全」「クローズド=危険」という単純図式には注意が必要だ。公開されたモデルパラメータが悪意ある利用者に渡るリスクも現実に存在し、安全管理のコストを誰がどう負担するかという問いに、業界全体がまだ明確な答えを出せていない。 より注目すべきは、SpaceXのColossusが世界トップ級のAIラボが集結するインフラハブになりつつあるという事実だ。GPUリソースの争奪戦はもはや企業間の技術競争であると同時に、国家レベルの産業政策の問題でもある。このトレンドの中で、日本はAIインフラへの投資姿勢をいつまでも「様子見」で済ませることができない局面に来ている。産業界と行政双方の戦略的判断が、今問われている。 出典: この記事は SpaceX inks compute deal with Reflection AI, an open source AI lab の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 23, 2026 · 1 min · 胡田昌彦

Claude CodeのExtended Thinkingログは「要約」にすぎなかった — Anthropicの仕様が監査・コンプライアンス要件に与える影響

Claude CodeのExtended Thinkingセッションログに含まれる「思考ブロック(thinking blocks)」が、実際の推論プロセスではなく暗号化された要約に過ぎないことが、エンジニアのPatrick McCanna氏の調査で明らかになった。ローカルに保存されたログには600文字のシグネチャが含まれるだけで、モデルが実際に行った推論テキストは含まれていない。 Extended Thinkingログの実態 Claude Codeはセッションを自動的にディスクに記録し、そのログには「思考ブロック」と呼ばれるセクションが含まれる。多くのユーザーがこれをモデルの実際の推論過程と理解していたが、Anthropicの公式ドキュメントには以下の仕様が記載されている。 推論は暗号化される: Claudeの推論はシグネチャに暗号化されており、復号キーはAnthropicが保有する APIが返すのは要約: ローカルに記録されるのは実際の推論そのものではなく、推論プロセスの「要約(summary)」 フル出力はエンタープライズ限定: 実際の思考プロセスへのアクセスにはエンタープライズ契約が必要 McCanna氏はこの状況を「JPEGをBMPとして保存し直してから編集し、元のJPEGですと提示するようなもの」と表現している。形式は似ているが変換によって情報が失われているという指摘だ。 なお、Ctrl+Oで表示されるExtended Thinking出力も、モデルの思考の要約であり、セッション中にエージェントの動作を実際に駆動した推論そのものではない点も合わせて指摘されている。 ドキュメントの記述が不明瞭 問題をより複雑にしているのが、Anthropicの公式ドキュメントにおける記述のあいまいさだ。「extended thinkingはClaude の完全な思考プロセスの要約を返す(returns a summary of Claude’s full thinking process)」という記述は存在するものの、サラッと読むと実際の推論ログが手元にあると誤解しやすい構成になっている。 McCanna氏は「コーヒーを飲む前に流し読みすると気づかないレベルの間接的な表現」と指摘しており、Hacker Newsでも170件以上のコメントが集まる議論に発展している。 実務への影響:監査・コンプライアンスの観点から 監査証跡として使えるか? 現時点では使えない、が結論だ。AIエージェントが何らかの判断を下した際に「なぜそう判断したか」の根拠をローカルログから再現することは不可能で、記録できるのは以下に限られる。 入力(プロンプト・コンテキスト) 出力(レスポンス) 実行されたアクション(ファイル操作・コマンドなど) 判断の根拠となった内部推論は手元には残らない。 コンプライアンス要件がある環境での注意点 金融・医療・行政など、意思決定の説明責任(Explainability)が厳しく問われる業種では、この仕様が導入上の制約になりうる。「AIがこの推論でこう判断したから」を証明できないと困る場面では、エンタープライズ契約の検討か、代替手段の設計が必要になる。 現実的な対策 推論トレースが必要なケースでは以下の対応を検討したい。 Anthropicのエンタープライズプランを検討する — フル思考出力にアクセスできる可能性がある 入出力ログを徹底的に記録する — 推論そのものは取れないが、コンテキストの再現性は高められる 高リスクな判断ポイントに人間レビューを組み込む — エージェントを完全自律にしない設計 チームや顧客への説明を正確にする — 「思考ログがある」と言い切らない 筆者の見解 Claude Codeは今も自分が最も信頼して使い倒しているツールだ。その前提を置いた上で、今回の件については率直に書く。 技術的な理由は理解できる。推論を暗号化してAnthropicがキーを保持することには、モデル保護やビジネス上の合理性があるだろう。しかし、ユーザーがローカルに保存されたファイルを「自分のエージェントの推論ログ」と思って作業しているとき、その認識が間違っているとしたら、それはドキュメントが正面から説明すべき事実だ。 「要約を返す」という記述が存在するのに、それが埋もれてしまっているのはもったいない。Anthropicの技術力は本物で、AIエージェントの分野での先進性も疑っていない。だからこそ、仕様の透明性という点でももっと正面から向き合えるはずだ、と感じる。 AIエージェントが業務の意思決定に関与する場面が増えるほど、「エージェントが何を考えてその行動を取ったか」の説明責任は重要になる。今後のアップデートでこの点の透明性がさらに改善されることを期待している。 エンタープライズ導入を検討している場合や監査証跡が必要なユースケースでは、「ローカルのthinkingログ=完全な推論記録」という前提を見直すことが第一歩だ。 出典: この記事は The text in Claude Code’s “Extended Thinking” output の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

June 23, 2026 · 1 min · 胡田昌彦

「バイブコーディング」のセキュリティ落とし穴:SQLインジェクションから本番DB消去まで、AIで作ったアプリが抱えるリスクの実態

AIを使ってコードを書かずにアプリを作る「バイブコーディング」が急速に普及する中、The Vergeが複数の実被害事例を取り上げ、個人利用から業務利用への「境界線」を踏み越えた瞬間にセキュリティ基準が根本的に変わることを警告している。 「すぐ動いた」が「ずっと安全」ではない プロジェクトマネージャーのBob Starr氏は、米国の税金がどのテック企業に流れているかを可視化するウェブサイト「Boomberg」をバイブコーディングで構築し、すぐに公開した。数ヶ月後に気づいたのは、深刻なSQLインジェクション脆弱性だった。攻撃者に悪用されれば、データの読み取りや改ざんが可能な状態だったという。 他にも、PocketOSの創業者Jer Crane氏のケースでは、AIコーディングエージェントが本番データベースを丸ごと消去するという事故が発生。あるシリアル起業家はデモ用に作ったWebアプリがハッキングされ、「今はZoom越しにローカルマシンからデモする。完全にレガシーな方法に戻った」と苦笑している。 問題の本質は「個人用→業務用」のドリフト AIサイバーセキュリティ企業SentinelOneのGabriel Bernadett-Shapiro氏は、「バイブコーディングそのものが悪いわけではない。素人がソフトウェアを作れるようになったのは、むしろ良いことだ」と評価した上で、核心的なリスクを指摘する。 「個人の頭痛記録や食事管理、配達追跡アプリなら問題ない。しかし顧客ログ、医療データ、財務記録、社内文書を扱う瞬間、基準は変わる。午後一番で作ったアプリであっても、他人の個人データに触れる時点で別次元の責任が生じる」 セキュリティスタートアップCorridorのCEO、Jack Cable氏も「プロトタイプや個人フィットネストラッカーには向いているが、公開インターネット上で他人のデータを扱う場合は、脅威モデルを真剣に考える必要がある」と同調する。 実際、決済スタートアップPrivyのCOO、Max Segall氏は子どもと一緒に走った距離に応じてEthereumを付与するアプリ「EzRun」をバイブコーディングで構築。リリース前に同僚が発見したのは、任意のユーザーアカウントを乗っ取れるという致命的な欠陥だった。早期発見が間に合ったのは、セキュリティ知識を持つエンジニアが周囲にいたからに過ぎない。 バイブコーディングのセキュリティチェックリスト(実務向け) AIが生成したコードは「動く」が「安全」とは限らない。特に以下の点は人間が必ず確認する必要がある。 公開前に確認すべき3つの問い 誰のデータを扱うか? — 自分だけか、他人のデータも含まれるか インターネットに公開するか? — ローカル専用か、外部アクセス可能か 入力値はどこから来るか? — ユーザー入力や外部APIを直接SQLやコマンドに渡していないか AIが生成したコードで特に脆弱になりやすい箇所 SQLクエリへの直接の文字列結合(SQLインジェクション) 認証チェックの漏れ(任意ユーザーなりすまし) 環境変数ではなくコードに直書きされたAPIキー エラーメッセージによるシステム情報の漏洩 AIに「このコードをセキュリティの観点でレビューして」と依頼するだけでも多くのリスクを洗い出せる。作ったAIに確認させるというアプローチは現実的で有効だ。 実務への影響 日本の企業でも、部署単位でのシャドーIT的なバイブコーディングは急増している。「業務効率化ツールをAIで作った」と部下から報告を受けたとき、IT管理者が確認すべきは技術的な動作だけでなく、「そのアプリはどのデータにアクセスしているか」「誰がアクセスできるか」「認証はどこで管理されているか」の3点だ。 バイブコーディングで生まれたアプリを正式な業務ツールとして採用する場合、最低限のセキュリティレビューを義務付けるプロセスを社内に設けることを強く推奨する。 筆者の見解 バイブコーディングの普及自体は歓迎すべき変化だと思っている。ノーコード・ローコードが「作れる人」を広げてきたように、AIコーディングは「自分のツールを自分で作る」民主化の次の段階だ。問題は技術ではなく、使う側のリテラシーにある。 今回の記事が指摘する「個人用から業務用へのドリフト」は、実はクラウドサービスのシャドーIT問題と構造的に同じだ。使いやすいから広がる、広がるから重要なデータが乗る、気づいたときには管理外になっている——この流れはずっと繰り返されてきた。 AIが生成するコードは確かに「動く」。しかし「安全に動く」かどうかは、利用者が問いを立てなければAIは保証できない。「セキュリティレビューして」と一言添えるだけで大きく変わる。ツールの問題ではなく、使い方の問題だ。 自律的なAIエージェントが普及し、コードが大量に自動生成される時代に、セキュリティは「後から直す」ものではなく「プロセスに組み込む」ものになっていく。本番データベースを消去したケースのように、エージェントに強い権限を与えながらセーフガードを設けないのは、ハサミを子どもに渡すのと変わらない。自律実行の力と安全設計はセットで考えるべきだ。 出典: この記事は Read this before you vibe-code another app の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 23, 2026 · 1 min · 胡田昌彦

Claude Codeが「忘れない・迷わない・育つ」── 3ファイル分離×10スキルのワークスペース設計を全公開

Claude Code、最高なんだけど「記憶」の扱いが難しい続きをみる note.com で続きを読む →

April 25, 2026 · 1 min · 胡田昌彦

AIチップ企業Groqが6億5000万ドル調達——NvidiaにCEOとLPU技術を「引き抜かれた」後のネオクラウド再起動戦略

AIチップメーカーのGroqは2026年6月、Nvidiaによる技術ライセンス契約とCEO引き抜きという「擬似買収(not-acqui-hire)」から約6ヶ月を経て、新たに6億5000万ドル(約950億円)の資金調達を完了し、ネオクラウド事業への本格ピボットを発表した。 「not-acqui-hire」とは何だったのか 2025年12月、NvidiaはGroqと非独占ライセンス契約を締結し、Groqが独自開発したLPU(Language Processing Unit)の技術IPを取得した。それだけでなく、Groqの創業者でCEOだったJonathan Ross(元Google、TPU開発を主導した人物)、PresidentのSunny Madraをはじめとした中核人材を大規模に引き抜いた。 「会社を買収せずに、技術と人材だけを手に入れる」手法がnot-acqui-hireだ。Groqの株主は手厚い補償を受けたとされ、表向きはWin-Winに見えるが、会社としてはコアリソースを失った状態からの再出発を余儀なくされる。 LPUの喪失とネオクラウドへのピボット Groqが開発したLPUは、LLM推論(インファレンス)処理に特化したカスタムチップ。GPUより高速かつ省エネで推論を実行できるとして業界から注目されていた。しかし今やそのIPはNvidiaが保有しており、Nvidiaは2026年3月のGTCイベントで「Nvidia Groq 3 LPX」推論ハードウェアシステムを発表している。 LPUビジネスの主導権を失ったGroqが差別化の軸として選んだのがネオクラウド事業だ。既存の大手クラウド(AWS・Azure・GCP)と異なる、AI推論に特化したクラウドサービスを提供するモデルである。2024年に買収したAIデータ分析企業「Definitive Intelligence」の事業が母体となり、現在は北米・欧州・中東・アジア太平洋の13データセンターに拡大。500万人以上の開発者と数千社のAI企業が利用し、毎週数兆トークンを処理するまでに成長している。 新体制のエグゼクティブ陣 GroqはCOO・CTO・CPOを一新した。 Alan Rice(COO): 元xAI・Meta。米海軍出身のエグゼクティブ Sinclair Schuller(CTO): エンタープライズクラウドソフト企業Apprendaの創業者 Rakesh Malhotra(CPO): Microsoft クラウド製品を約10年担当後、SchullerとNuvalenceを共同創業(2024年にEYが買収) 現CEOはGroq共同創業者のDoug Wightman(Nvidiaへの移籍を選ばずGroqに残留した人物)が務める。 実務への影響:日本のエンジニア・IT管理者への示唆 推論特化クラウドという選択肢を知っておく GroqCloudのAPIはAI推論を高速・低レイテンシで提供するサービスとして、国内の一部開発者やスタートアップに利用されている。今回の資金調達によりAPACリージョンの拡充も期待できる。特に大量推論が必要なバッチ処理やエージェント系ワークロードを組む際の選択肢として把握しておきたい。 「推論コスト」が経営課題になる時代 LLMの利用が業務に本格的に組み込まれると、推論コストは無視できない固定費になる。汎用クラウド一択ではなく、GroqのようなAI推論特化型サービスをワークロードに応じて使い分けるアーキテクチャ設計が、今後のシステム設計における重要な論点になる。 not-acqui-hireは今後も増える Scale AIがMetaとの同様の取引後も$10億ドル収益達成に向けて順調に成長しているという事例も紹介されている。会社を丸ごと買収するよりコストが低く、技術・人材を集中取得できるこのモデルは、AI業界でさらに増える可能性が高い。 筆者の見解 GroqのLPUは登場時から「GPUとは設計思想の違うアプローチだ」と感じていた。推論に特化したアーキテクチャとしての実力は本物で、NvidiaがわざわざIPライセンスを取りに来たこと自体がその証明だ。 鍵はネオクラウド事業がこの先どこまで差別化を維持できるかにある。Nvidiaが「Groq 3 LPX」を市場に出してきた今、Groqの優位性はハードウェアではなく、積み上げてきたソフトウェアスタックと開発者エコシステムに移った。500万開発者というユーザー基盤は、ゼロから作るのは容易ではないアセットだ。 インファレンス市場は現在まさに急拡大中だ。AIエージェントが自律的にループで処理を回し続けるような設計では、「大量の推論をいかに安く速く実行するか」がそのままシステムの経済性に直結する。そのニーズに応え続けられれば、Groqがネオクラウドとして独自のポジションを確立するシナリオは十分にある。 not-acqui-hireという手法が成立してしまう今のAI業界の勢いは、改めて凄まじいと感じる。技術と人材だけを切り出して取引できてしまう構造は、今後のスタートアップ戦略にも大きな示唆を持つだろう。 出典: この記事は AI chipmaker Groq confirms $650M raise, re-staffs after Nvidia’s $20B not-acqui-hire deal の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 23, 2026 · 1 min · 胡田昌彦

Cloudflareがアカウント不要の一時Workersデプロイ機能を公開——AIエージェントが60分間の本番環境を即座に取得可能

Cloudflareは2026年6月21日、アカウント登録不要でCloudflare Workersを60分間デプロイできる「Temporary Accounts」機能を公開した。npx wrangler deploy --temporary の1コマンドで即座に本番URLが発行されるこの機能は、AIエージェントが自律的にデプロイ・検証ループを回すための環境整備として注目を集めている。 何ができるのか これまでCloudflare Workersにアプリをデプロイするには、アカウント作成→APIキー取得→wrangler設定という一連の手順が必要だった。新機能ではこのプロセスをまるごとスキップできる。 npx wrangler deploy –temporary このコマンドを実行すると、Cloudflareが裏側で一時アカウントを自動生成し、Workersプロジェクトをデプロイする。数秒で外部からアクセス可能な本番URLが発行される。 一時デプロイは60分後に自動削除される。ただし、デプロイ完了時に「クレームURL」も同時に発行される。このURLからCloudflareアカウントへの紐付け(クレーム)を行えば、プロジェクトは永続化し、通常のWorkersとして管理し続けることができる。 「AIエージェント向け」だが、すべての開発者にとって有用 Cloudflareは「AI agents向け」と打ち出しているが、ブログ著者のSimon Willisonが指摘するように、この機能の恩恵はAIエージェントに限らない。 AIエージェントの文脈では確かに威力を発揮する。エージェントがコードを生成しても、「どこかに実際にデプロイして動作確認する」ステップはこれまで厄介なボトルネックだった。アカウント作成やAPIキー管理をエージェントに委ねるのはセキュリティ上の問題があり、人間が事前にセットアップして渡す手間も発生していた。一時アカウント機能はこの摩擦を一気に解消する。 一方、人間のエンジニアにとっても活用場面は多い: プロトタイプの即共有:ローカルで動くものをすぐ他者に確認してもらいたいとき ハンズオン・デモ環境:セミナーや勉強会で一時的な「動く環境」を用意するとき CIパイプラインのプレビュー:PRごとにWorkersを立ち上げてエンドツーエンドテストを走らせるとき Simon Willisonは実際にOpenAI Codex Desktop上でHTTPリダイレクト解決ツールをAIにビルドさせ、一時デプロイが問題なく機能することを確認している。 実務での活用ポイント エージェントの自律ループに組み込む AIエージェントが「コードを書いて→デプロイして→動作確認して→修正する」という自律ループを回す際、Cloudflare Workersはエッジで動作しHTTPエンドポイントとして公開できるため、エージェントが生成したツールをAPIとして即座にテストする用途にフィットする。アカウント管理を人間側に委ねる必要がなくなるため、エージェントの自律性が大きく高まる。 ガバナンスへの配慮も忘れずに 企業で利用する場合、「アカウント不要」という特性はガバナンスの観点から注意が必要だ。誰がどの一時Workersをデプロイしたかを把握しにくくなる可能性があるため、利用ポリシーの整備を検討したい。60分後の自動削除は、放置された環境が永続化するリスクを抑える合理的な設計だが、企業の情報セキュリティポリシーとの整合性は別途確認が必要だ。 筆者の見解 AIエージェントの真の自律性は、コードを生成するだけでなく、実際に動かして結果を検証するところまで完結して初めて実現する。「おそらく動くと思います」で止まるエージェントと、「HTTPステータス200を確認しました」まで完結するエージェントとでは、信頼性と実用性に根本的な差がある。 Cloudflareの一時デプロイ機能は、その「最後の一歩」を支えるインフラだ。アカウントという摩擦を取り除くことで、エージェントが自律的に動ける領域が一つ広がった。地味に見えるが、エージェントが回す自律ループの質を底上げする本質的な改善だと感じる。 また「AIエージェント向け」というラベルに引きずられず、普通の開発者ツールとして今日から使い始める発想も大切にしたい。プロトタイプをすぐ共有できる手軽さは、日本のエンジニアが「まず試す」カルチャーを育てる上でも確実に意味がある。仕組みを整えれば、AI活用の効率は着実に上がっていく。 出典: この記事は Temporary Cloudflare Accounts for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 22, 2026 · 1 min · 胡田昌彦

GitHub Copilot製社内データ分析エージェント「Qubot」——全社員が自然言語でデータを問い合わせできる仕組みをGitHubが公開

GitHubのプロダクトアナリティクス部門が、GitHub Copilotを活用した社内データ分析AIエージェント「Qubot(クボット)」を開発・運用し、その構築過程で得た知見を公式ブログで公開した。非エンジニアを含む全GitHub社員が、SQLを書かずに自然言語でデータへ問い合わせ、リアルタイムに分析結果を得られる社内ツールだ。 Qubotとは何か Qubotは、GitHub Copilotを中核エンジンとして構築された社内向けデータアナリティクスエージェントだ。「先月のリポジトリ新規作成数は?」「GitHub Actionsの利用が増えているカテゴリは?」といった自然言語の問いかけに対し、エージェントが自律的にデータベースへのクエリを生成・実行し、結果を返す。 このようなText-to-SQL型のエージェントを実用化するには、単にLLMをDBに繋いで終わりというわけにはいかない。GitHubチームが公開した知見の核心は、まさにそこにある。 構築上の主な課題と学び スキーマコンテキストの設計 LLMが「どのテーブルに何のデータがあるか」を正確に理解するためのコンテキスト設計が、精度に直結する。テーブル数が多い大規模DBでは全スキーマをプロンプトに詰め込むとトークン上限に引っかかるため、クエリ内容に合わせて関連スキーマだけを動的に提示する仕組みが必要になる。 SQLの検証と自己修正ループ LLMが生成するSQLは常に正確とは限らない。実行エラーをLLMへフィードバックして再試行させるリフレクションループが、実用レベルの精度を実現するうえで不可欠だ。このループの洗練度が、プロトタイプと実運用ツールの差を決める。 データアクセス制御の統合 「誰でも何でも聞けば答える」構成はセキュリティ上のリスクを孕む。既存のデータアクセスポリシーとの統合、読み取り専用クエリの強制、機密データのマスキングといった制御を、エージェントのレイヤーに透過的に組み込む設計が求められる。 日本の現場への影響——今すぐ参考にできること 日本企業の多くで、データ分析はBIツールを使いこなせるか、SQLが書けるエンジニアだけの特権になっている。Qubotのアプローチは、この「データアクセス格差」を解消する具体的なモデルとして参考になる。 実装の出発点として検討できる選択肢: GitHub Copilot Extensionsを使ったチャット拡張で、社内DBへの自然言語問い合わせBotを試験実装できる Azure OpenAI Service + Azure SQL / Synapse Analyticsの組み合わせで、Microsoft技術スタックのまま同様の構成を実現可能 Semantic Kernelのプラグイン機構は、SQL実行エージェントを組み込む際の標準的な出発点として機能する いずれにせよ、まずは「社内でよく聞かれるデータ的な質問トップ10」をAIに答えさせる小規模なPoC(概念実証)から着手することを勧めたい。データレイクやDWHがすでに存在する企業であれば、AIレイヤーを追加するコストは以前より大幅に低下している。 筆者の見解 GitHubがQubotの構築経験を外部に公開したことは、率直に評価したい。「うまくいった」ことだけでなく「学んだこと」を具体的に語る技術記事は、同じ課題を抱える開発チームにとって価値が高い。 注目したいのは、このエージェントの設計思想だ。毎回人間がSQLを承認・実行するフローではなく、エージェントが問いを受け取り、クエリ生成・検証・実行を自律的に完結させる。AIエージェントが本来もたらすべき価値は認知負荷の削減であり、確認のたびに人間を挟む構成ではその価値は半減する。Qubotはその点で正しい方向に設計されている。 日本企業がこの事例から学べる最大のポイントは、「AIを使わせる」より「AIなしでは回らない仕組みを先に作る」という発想の転換だ。Qubotはデータチームへの依頼待ちというボトルネックを構造的に解消する仕組みとして機能している。ツール導入ではなくワークフローの再設計——この視点こそが、AI活用を組織に根付かせる鍵になる。 出典: この記事は How we built an internal data analytics agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 20, 2026 · 1 min · 胡田昌彦

AnthropicのMythosが米輸出規制で突然停止——暗号化・スパイウェアの前例が示す「AI封じ込め」の限界

AnthropicのサイバーセキュリティAI「Mythos」が、ホワイトハウスの輸出規制命令を受けて突然オフラインになった。通知からわずか約90分でアクセスを全面制限するという異例の対応——その背景には、過去30年にわたって繰り返されてきた「危険なサイバー技術を封じ込めようとした政府の試み」と、その失敗の歴史がある。 MythosとFable——なぜこれほど騒ぎになっているのか Anthropicが今年4月にローンチしたMythosは、サイバーセキュリティ特化型の強力なAIモデルだ。同社自身が「広く流通すればインターネットに甚大な被害をもたらしうる」と説明するほどの性能を持つとされており、リリース当初から約150の審査済み企業・政府機関だけに限定提供されていた。 想定用途は防御側のためのもの——悪用者よりも先に脆弱性を発見・修正するための「ホワイトハット側の兵器」だ。 今回の規制対象はMythosに加え、最新モデル「Fable 5」も含まれる。両モデルは先週から米国外のユーザーはもちろん、米国内の外国籍ユーザーにも提供停止となっている。 規制発動の2つのトリガー 今回の輸出規制発動には、2つの具体的なきっかけがあったとされる。 第一:韓国大手通信会社へのアクセス付与 Anthropicは限定パートナープログラムを通じ、韓国の大手通信会社(広く報じられているのはSK Telecom)にMythosへのアクセスを提供した。米当局はこの企業を「中国との関係が疑われる」と判断し問題視した。SK Telecom側は中国との関係を否定している。 第二:Fable 5の安全策回避報告 Amazon CEOのアンディ・ジャシー氏が、Amazon社内の研究者たちがFable 5の安全策を迂回する方法を発見したとして政権に報告した。Anthropicはこれを「ジェイルブレイク」と呼ぶことを否定し、「狭い範囲のすでにパッチ済みの問題」と反論しているが、当局の懸念を払拭するには至らなかった。 歴史が示す「サイバー技術封じ込め」の実績 今回の事態が特に注目されるのは、過去30年で繰り返されてきたパターンと重なるからだ。 PGP暗号化と「クリプトウォーズ」(1990年代) 1990年代初頭、Phil Zimmermann氏は「Pretty Good Privacy(PGP)」という暗号化ソフトウェアを開発した。傍受されても解読不可能な通信を実現したこのソフトに対し、米政府は「武器輸出規制違反」として刑事調査を開始した。 Zimmermann氏の反撃は鮮やかだった。PGPのソースコードを書籍として印刷・出版したのだ。書籍は表現の自由で保護されるため輸出規制の適用外。この抵抗は「クリプトウォーズ」として歴史に刻まれ、調査は最終的に打ち切りとなった。今日のSignalやWhatsAppが使うエンドツーエンド暗号化の礎はこうして築かれた。 ワッセナー協定とスパイウェア規制(2010年代) 2010年代には西側製スパイウェアが中東の反体制派活動家への監視に使われていることが次々と発覚。各国政府は「ワッセナー協定」を拡大し、監視・ハッキングソフトウェアをデュアルユース技術として分類、輸出ライセンスを義務付けた。 結果は規制の形骸化だった。イスラエルのNSO GroupのPegasusスパイウェアは規制後も世界中への拡散を続けた。 日本のエンジニア・IT管理者への実務的影響 現時点で日本の一般ユーザーへの直接的な影響は限定的だ。Mythosはもともと限定提供であり、Claude 3系など他のAnthropicモデルは通常通り利用できる。 ただし以下の点は注視が必要だ: AI輸出規制の前例形成:今回の枠組みが定着すれば、他のAIラボの製品にも同様の規制が波及しうる。特にサイバーセキュリティ用途のAIは今後より厳しい審査対象になる可能性がある 企業のAI調達リスク管理:安全保障分野に近いサービスを活用する企業は、突然のサービス停止リスクを調達戦略・BCP計画に織り込む必要が出てくる 「限定提供」モデルへの規制:公開型ではなく審査制でアクセスを絞る仕組みを採用しているAIサービスが、今後どういった規制の対象になるかは不透明だ 筆者の見解 歴史の教訓は明快だ。PGP、スパイウェア、そして今回のMythos——「危険な技術を輸出規制で封じ込める」試みは30年にわたって繰り返されてきたが、成功例はほとんどない。技術は本質的に拡散する。知識は書籍になり、コードはコピーされ、手法は伝播する。規制は流通を遅らせることはできても、止めることはほぼできない。 とはいえ、今回の規制発動には無視できない背景がある。「中国との関係が疑われる企業へのMythosアクセス付与」という具体的なインシデントが存在するからだ。純粋な予防的規制ではなく、実際の懸念事象への対応という側面がある以上、一概に「的外れ」とも言い切れない。 問題は手段の実効性だ。輸出規制という19世紀的な枠組みが、コードで表現されたフロンティアAIの拡散を本当に止められるのか。それとも、Anthropicのような企業が自主的な安全策として設計してきた「審査制限定提供」という仕組みの方が、現実に即した対策なのか。 今回の「90分以内に全アクセス制限」という対応が示したのは、AIラボと政府の間にある力学の変化だ。この判断の落としどころが、フロンティアAI全体の「輸出ルールブック」を形成することになる。その行方を、日本のIT業界も他人事として見過ごすわけにはいかない。 出典: この記事は Encryption, spyware, and now Mythos: History shows why cyber export control doesn’t work の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 20, 2026 · 1 min · 胡田昌彦

「新サービス出たよ」とAIに言っただけで、もう使えるようになっていた話

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント(Claude Code)が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

April 22, 2026 · 1 min · 胡田昌彦

独学AIエンジニアのTom Di Minoが古代ミノア文字「線文字A」を解読か——100年の謎に挑んだ半年間

独学のAIエンジニアでアマチュア言語学者のTom Di Minoが、100年以上にわたって世界中の言語学者を悩ませてきた古代ミノア文明の文字体系「線文字A(Linear A)」の解読に成功したと主張している。この主張は現在、ラトガーズ大学とケンブリッジ大学の言語学専門家によって検証が進められている。 線文字Aとは何か 線文字Aは紀元前1800年頃から紀元前1450年頃まで使われた古代ミノア文明の文字体系だ。クレタ島がミケーネ・ギリシャ人に征服された際に使用が途絶え、ミケーネ人はこれをベースに「線文字B(Linear B)」を作り上げた。 線文字Bは1952年に英国人建築家・暗号解読者のMichael Ventrisによって解読され、古代ギリシャ語であることが判明した(ニューヨーク・タイムズの一面を飾るほどの快挙だった)。Brooklyn CollegeのAlice Koberが積み上げた文法・統計的分析の功績なしに、Ventrisの解読は実現しなかったともいわれる。 線文字Aと線文字Bは60個のコア音節を共有しているため、線文字Aの文字がどんな「音」を表すかはある程度推測できていた。しかし「その音が何を意味するか」が完全に不明で、さらに線文字Bに存在しない13個の追加記号が含まれているため、解読は長年の難題であり続けた。 Di Minoが辿り着いたブレークスルー Di Minoは18歳から古典史・言語学を独学で研究し、線文字Aを7年間学んできた。クレタ島を2度訪れ、2026年1月に解読作業を本格開始。5月22日に決定的な洞察を得たという。 ブレークスルーのきっかけは、クレタ島内の5か所の神殿遺跡に共通する「祈祷定型文」の分析だった。各行の冒頭に現れる動詞が線文字B由来の既知記号5文字と線文字A固有の「*301」という記号で構成され、かつ地域ごとに異なる変化形を持つことに気づいた。このパターンを手がかりに言語の構造を解析し、「線文字Aは古代セム語族の言語を記したものであり、聖書ヘブライ語の前身にあたる——ちょうどラテン語がイタリア語の前身であるように」という結論に至った。 セム語族説は1957年にCyrus Gordonが学術誌で主張したことがあるが、実際の翻訳を導くには至らず、学界での受け入れは限定的だった。Di Minoの解読が翻訳として機能するかどうかは、現在進行中の専門家検証の結果を待つ必要がある。 実務への影響——AIが変えたアマチュアの可能性 このニュースが示唆するのは、「AIと深いドメイン知識の掛け合わせ」が専門家集団を超えるアウトカムを生み出し得るという現実だ。日本のITエンジニアにとって実感しやすいポイントをまとめる。 ドメイン知識×AIが最強の組み合わせ: Di Minoは7年間の蓄積なしにAIを使っても解読に至らなかったはず。「AIだけ使えばいい」ではなく、深い専門知識があってこそAIが武器になる パターン認識タスクへのAI活用: 大量の碑文から統計的パターンを見つける作業は機械学習が得意とする領域。考古学・歴史言語学での応用は今後加速するだろう 検証プロセスの設計が鍵: Di Minoの主張は現在ラトガーズ・ケンブリッジで検証中。AIの出力を適切に評価・検証する仕組みを整えることの重要性を改めて示している 筆者の見解 このニュースを読んで真っ先に感じたのは「これはAI時代の縮図だ」という感覚だ。 世界最高水準の言語学者たちが100年以上解けなかった謎を、独学エンジニアが半年で突破した(主張が正しければ)。ここにあるのは「AIがすごい」というシンプルな話ではなく、「一つのテーマに7年間深く潜り続けた人間が、適切なタイミングでAIを武器として使うと何が起きるか」という問いへの示唆だ。 情報の表面を広く追いかけるよりも、一点に集中して深く掘り下げること。そしてその深みのある文脈の中でAIを道具として活かすこと。Di Minoのアプローチはその典型に見える。 もちろん、この解読主張が専門家の検証を通過するかどうかは全くの別問題だ。過去のセム語族説がそうだったように、「翻訳として機能する」ことを証明するハードルは高い。解読の真偽はしばらく注目し続けたい。 出典: この記事は AI Engineer Claims to Have Cracked Linear A の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 20, 2026 · 1 min · 胡田昌彦

ElasticがElasticsearch上でAIエージェント永続メモリを実装——認知科学由来の3層設計で想起率0.89を達成

Elastic(Elasticsearch開発元)は、AIエージェントに本物の長期記憶を持たせるための永続メモリ層をElasticsearchで構築し、その設計思想と実装の詳細を公開した。168問のQA評価でR@10が平均0.89に達し、かつユーザー間のデータ漏洩ゼロを達成したこのアーキテクチャは、エージェント開発者が直面する「記憶問題」に対して実践的な解を示している。 コンテキストウィンドウは「記憶」ではない 多くのAIエージェント実装では、過去の会話履歴をそのままコンテキストウィンドウに詰め込む手法が採られている。しかしこのアプローチには3つの根本的な問題がある。 まずコスト——長い履歴はそのままトークンコストに直結する。次にレイテンシ——大量のコンテキストは推論速度を落とす。そして「中間消失(Lost in the Middle)」効果——研究で示されているように、モデルはプロンプトの端(冒頭・末尾)に近い情報は拾うが、中間に埋もれた情報は無視しがちだ。 100万トークンのコンテキストウィンドウは「作業メモ」であって「記憶」ではない。セッションをまたいで生き残り、年単位でスケールし、内容・時刻・ユーザーで検索できる永続ストアこそが本物の長期記憶だ、というのが本実装の出発点である。 3種類の記憶:認知科学からの借用 Elasticのチームは認知科学の知見(COALAフレームワーク)を参照し、記憶をエピソード・意味・手続きの3種類に分類。それぞれをElasticsearchの独立したインデックスにマッピングした。 エピソード記憶(Episodic Memory): タイムスタンプ付きの生イベント。各ユーザーターンをそのまま蓄積する。短命なものが多く、後で重要な事実を抽出するための素材となる。 意味記憶(Semantic Memory): ユーザーに関する安定した事実。「Sarah は Lumio Hub v2 を所有している」「Sarah の iOS バージョンは 17.4」のような蒸留済みのアサーション。セッションをまたいで永続し、エージェントが推論の根拠とする情報がここに入る。 手続き記憶(Procedural Memory): 複数ステップのプレイブック。「Zigbee接続切断のトラブルシュート手順」のような、事実ではなくプロセスを保存する。 この分類の重要な点は、書き込み頻度とエイジング(鮮度の扱い)がタイプごとに異なることだ。単一の記憶モデルで混在させるとハイスタック化する。タイプ別管理により、検索精度と更新コストを両立させている。 ハイブリッド想起・上書き処理・ユーザー分離 想起クエリにはRRF(Reciprocal Rank Fusion)とクロスエンコーダー再ランカーを組み合わせたハイブリッド検索を採用している。ベクター検索によるセマンティックマッチと全文検索によるキーワードマッチを融合させ、どちらか一方に頼るより精度を高めている。 矛盾する事実が生じた場合は「削除」ではなく「上書き(Supersession)」で処理する。旧バージョンを残しつつステータスを変更するため、監査証跡が完全に保たれる。 マルチユーザー展開では、ElasticsearchのDLS(Document Level Security)をユーザーID単位で適用することでテナント間のデータ漏洩を防ぐ。168問の評価でクロステナント漏洩ゼロという結果は、本実装が単なるプロトタイプではないことを示している。 また、このメモリ層はMCP(Model Context Protocol)対応クライアントであれば何でも接続できる設計になっており、特定のエージェントフレームワークに依存しない。 実務への影響 日本のエンジニアにとって、このアーキテクチャが示す教訓はいくつかある。 「専用ベクターDBでなくてよい」という選択肢: Elasticsearch(またはOpenSearch)がすでに自社インフラにあるなら、それをエージェントメモリとして転用できる。新たなマネージドサービスを増やさずにアーキテクチャをシンプルに保てる点は、運用コストの観点からも現実的だ。 エイジングと鮮度管理の設計思想: 記憶が古くなれば重みを下げ、よく参照される記憶は沈まないようにする——時間とアクセス頻度に基づくスコアリングは、RAGシステム設計全般に応用できる考え方だ。 DLSによるマルチテナント分離: 企業向けSaaSやB2B SaaSを構築する際に即座に参考にできるパターンだ。エージェントが複数ユーザーの記憶を混同するリスクは、セキュリティインシデントとして深刻なものになりうる。 実装はGitHubで公開されており、Agent BuilderとしてElastic CloudでもGA(一般提供)済みだ。 筆者の見解 今回のElasticのアーキテクチャは、「エージェントに本物の記憶を持たせる」という課題に対して、認知科学の分類を実装レベルで具体化した点で評価できる。 私が特に注目するのは「上書き(Supersession)」と「エイジング」の組み合わせだ。記憶は単に保存するだけでは意味がない。矛盾を処理し、鮮度を管理し、重要度の下がった情報を静かに沈め、必要なものを浮かび上がらせる——この仕組みなしに、エージェントは長期間使うほど「ゴミ屋敷化」する。 エージェントが自律的にループで動き続ける「ハーネスループ」の設計においても、セッションをまたぐ文脈保持は最大のボトルネックのひとつだ。毎回コンテキストをゼロから渡し直すモデルでは、エージェントが真の意味で「学習する」ことができない。ループが本当に賢くなるには、今回のような永続記憶層が前提条件になる。 Elasticsearchをすでに使っていない環境では導入コストも無視できないが、「新しいベクターDBを追加するか、既存の検索インフラを転用するか」という問いに後者で答えられる可能性を示したことは実践的だ。3つのインデックス構造・ハイブリッド検索・DLSは、それぞれ単独では枯れた技術。組み合わせ方にこそノウハウがある。エージェントに「セッションをまたいだ文脈」を持たせたいすべての開発者に一読を勧めたい内容だ。 出典: この記事は We built a persistent agent memory layer on Elasticsearch with 0.89 recall の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

June 20, 2026 · 1 min · 胡田昌彦

OpenAIのAIモデルがErdős単位距離予想を80年ぶりに反証——フィールズ賞受賞者Tim Gowersが検証した数学史の転換点

OpenAIが開発した内部AIモデルが、数学者Paul Erdősが1946年に提唱した「単位距離予想(Unit Distance Conjecture)」を反証し、80年来の未解決問題に終止符を打った。AIが核心的なアイデアと証明草案を生成し、フィールズ賞受賞者のTim Gowers氏(ケンブリッジ大学教授)を含む9名の数学者チームがそれを検証・精緻化して論文として発表した。 Erdős単位距離予想とは何か Paul Erdős(1913〜1996)は20世紀を代表するハンガリー出身の数学者で、組合せ論・グラフ理論・数論など広範な分野で1500本以上の論文を残した。彼が1946年に提唱した「単位距離予想」は、平面上のn個の点の間で、ちょうど距離1(単位距離)となる点対の最大数に関する問題だ。 Erdősは点の配置をどれだけ工夫しても、単位距離を持つ点対の数には厳しい上界があると予想していた。この問題は直感的な明快さの裏に深い組合せ論的構造を持ち、多くの一流数学者が取り組みながらも80年間決着がつかないまま残り続けた、数学史上の著名な未解決問題の一つだ。 AIが核心アイデアを生成、人間の専門家が精緻化 今回の突破口を開いたのはOpenAIの内部AIモデルだ。このモデルが予想の反証となる核心的なアイデアと証明の初期草案を生成し、それをTim Gowers氏らの数学者チームが厳密に検証・発展させた。 従来のAI活用は「既知の証明を検索する」「計算を高速化する」といった支援に留まっていた。今回の特徴は、AIが「新しい数学的アイデアを能動的に生み出す」役割を担った点にある。フィールズ賞受賞者という数学の最高峰がAIの出力を「検証に値する」と判断し、共同作業として論文を完成させたことは、AIの知的能力についての認識を根本から塗り替える出来事だ。 なぜこれが重要か AIが「発見者」になった これまでのAIは人間が積み上げた知識を整理・言語化する能力に秀でていた。今回の成果は、既存知識の組み合わせでは届かない「新しい思考の跳躍」をAIが実現できることを示唆している。数学の証明という、曖昧さが一切許されない最も厳格な知的活動の場で、この能力が実証された意味は大きい。 人間とAIの協働モデルの実証 「AIがアイデアを出し、人間の専門家が検証・精緻化する」という分業が最高レベルの数学で機能することが証明された。このワークフローはソフトウェア開発・新薬設計・材料探索など、数学的推論を基盤とする多くの分野に応用可能だ。 数学以外への波及 暗号理論・量子アルゴリズム・AI安全性など、未解決の数学的問題が実用上の障壁となっている領域で、同様のアプローチが加速する可能性がある。 実務への影響——エンジニア・IT管理者が押さえるべきポイント 「補助ツール」から「共同研究者」へのパラダイム転換 この実績を受け、企業のR&D部門や学術研究機関でAIを研究プロセスへ統合する動きが一段と加速するだろう。社内でAI活用戦略を策定する際、「チャットボット的なAI」と「自律的に問題を探索するAIエージェント」は別物として位置付ける必要がある。 検証プロセスの設計が成否を分ける 今回の成果も、AIが単独で完結したのではない。9名の専門家が検証・精緻化するプロセスがあって初めて論文になった。AIが生成したアウトプットを専門家が精査するワークフローを組織として設計することが、AI活用の質を左右する。「AIが出したアイデアを人間が判断する」という役割分担を意識的に組み込む必要がある。 AIエージェントの自律的問題解決能力への注目 単発の質疑応答ではなく、AIが複雑な問題空間を自律的に探索し続けるエージェント的な動作が今回の成果の背景にある。この能力をどう業務プロセスに組み込むかが、これからの組織の競争力に直結する。 筆者の見解 AIが80年来の数学的難問を突破するアイデアを生み出した事実は、素直に驚きをもって受け止めたい。 興味深いのは、今回の成果が「AIが一人で全部やった」という話ではない点だ。AIが方向性を示し、フィールズ賞受賞者レベルの専門家が検証・完成させた。この構造は、AIが得意な「広い空間を高速に探索すること」と、人間が得意な「数学的厳密性の担保」が組み合わさったものだ。どちらが欠けても今回の成果はなかった。 数学という「答えが完全に正しいか間違いかしかない」領域でこの協働が機能したことは、より曖昧さが混じる実務領域への応用に自信を与えてくれる。ただし、実務では「何が正しい検証か」自体が難しいケースも多い。AIが出した答えをどう評価するかの基準設計こそが、組織にとって最初の本質的な仕事になる。 AIが「仮説生成装置」として機能し、人間の専門家が「検証・判断装置」として機能するモデルは、今後あらゆる知的産業に広がっていくだろう。日本のエンジニアやIT組織が問うべきは「うちの現場でAIはどんなアイデアを出せるか」ではなく、「AIが出したアイデアを誰がどう評価する体制を作るか」だ。この問いに答えられた組織が、次のフェーズで差をつける。 出典: この記事は OpenAI’s AI Model Disproves 80-Year-Old Erdős Unit Distance Conjecture, Verified by Fields Medalist Tim Gowers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 20, 2026 · 1 min · 胡田昌彦

iOS 27 ExtensionsでSiri・Writing ToolsのデフォルトAIをClaude・ChatGPT・Geminiから選択可能に——AppleがWWDC 2026で発表

2026年6月8日、AppleはWWDC 2026の基調講演でiOS 27 Extensionsを発表し、SiriやWriting Tools・Image PlaygroundなどすべてのApple Intelligence機能において、Claude(Anthropic)・ChatGPT(OpenAI)・Gemini(Google)・Grok(xAI)の中からデフォルトのAIプロバイダーをユーザーが自由に選択できるようになる。 iOS 27 Extensionsとは iOS 27 Extensionsは、Apple Intelligence全体をサードパーティのAIプロバイダーに開放するフレームワークだ。専用のApp Storeマーケットプレイスを通じてAIプロバイダーが配信され、ユーザーはiOSの「設定」画面からデフォルトのAIを切り替えられる。 これまでAppleはChatGPT(OpenAI)との独占的なパートナーシップを維持してきたが、iOS 27 Extensionsではその単一プロバイダーモデルを廃止し、オープンな競争プラットフォームへとシフトする。最初のサードパーティパートナーとしてAnthropicのClaudeとGoogleのGeminiが採用され、既存のChatGPT統合と並んで提供される予定だ。 対象機能と選択の仕組み iOS 27 Extensionsが対象とするApple Intelligence機能は以下の通りだ: Siri:音声アシスタントのバックエンドAIをユーザーが選択可能 Writing Tools:文章作成支援(要約・校正・書き換えなど) Image Playground:画像生成機能 設定画面から「デフォルトAI」を一度選べば、これらすべての機能でそのAIが使われる。Apple Intelligenceのシステムレベルに統合された形で動作するため、アプリをまたいで一貫したAI体験が得られる設計だ。 開発者向けビジネスモデル 注目すべきは小規模開発者への優遇措置だ。年間売上100万ドル(約1.5億円)未満の開発者には、クラウドAI統合のAPIコストが無償となる。個人開発者やスタートアップが、エンタープライズ品質のAIをコストゼロで自社アプリに統合できることを意味する。 AnthropicやOpenAI、Googleにとっては、10億台を超えるAppleデバイスへの直接配信チャネルが開かれることになり、各社の市場拡大において極めて重要な転換点となる。 実務への影響——日本のエンジニア・IT管理者の視点から 開発者への影響:iOSアプリへのAI機能組み込みにおいて、これまでは自前でAPIを呼び出す実装が必要だったが、Extension経由でシステムレベルのAI機能を活用できるようになる。小規模スタートアップにとっては開発コストの大幅削減が期待できる。 企業のデバイス管理:法人向けiOSを管理するIT管理者にとっては、MDM(モバイルデバイス管理)によるAIプロバイダーの制限・指定が新たな課題になる。社内データがどのAIサービスに送信されるかを管理するポリシーの整備が急務だ。情報漏洩対策の観点から、企業ポリシーとユーザーの選択の自由のバランスをどう設計するかが問われる。 ユーザー体験の変化:これまでiPhoneを使うとデフォルトでChatGPTに接続される体験だったが、今後はユーザー自身がAIを選択・管理する時代になる。どのAIに何が送られているかを理解する情報リテラシーが、一般ユーザーにも求められるようになる。 筆者の見解 AppleがAIのシングルプロバイダーモデルから競争プラットフォームへとかじを切ったことは、業界全体にとって健全な変化だと思う。1社依存のエコシステムはリスクを集中させ、イノベーションの速度を鈍らせる。複数のAIプロバイダーが10億台のデバイス上で競争する環境は、長期的には技術の質を高める方向に働くだろう。 この動きの本質は、AIの「OS化」だと筆者は捉えている。スマートフォンが「どのアプリを入れるか」を競った時代と同様に、「どのAIを使うか」という選択がユーザーの日常の一部になる。各AIプロバイダーは10億ユーザーへのリーチを得る一方で、ユーザーに「選ばれ続ける」ための品質競争にさらされることになる。これは消費者にとって間違いなくいいことだ。 日本のエンタープライズへの波及という観点では、セキュリティガバナンスの整備が先決だ。「iPhoneを使ったら社内情報が見知らぬAIサービスに送られていた」という事態を防ぐため、IT部門がExtensionsのポリシー管理に早期から取り組む必要がある。MDMベンダー各社の対応状況を注視しておきたい。 小規模開発者への無償API提供は参入障壁を下げる点で歓迎できるが、「無料枠の上限に達した途端にコストが急増する」構造への注意も必要だ。事業規模に応じたコスト設計は引き続き重要な検討事項となる。 AppleがこのExtensionsフレームワークでどこまで公平な競争環境を保証できるか——その設計の透明性が、今後のAI市場全体の信頼性を左右する重要な試金石になると見ている。 出典: この記事は Apple iOS 27 Extensions: Users Can Now Set Claude, ChatGPT, or Gemini as Default AI Across All Apple Intelligence Features の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 20, 2026 · 1 min · 胡田昌彦

Teams管理者の承認なしでTeamsからClaudeCodeを動かす方法 — Bot Framework SDKも不要

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント(Claude Code)が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 続きをみる note.com で続きを読む →

April 3, 2026 · 1 min · 胡田昌彦

ASMLのEUV露光装置「中国流出疑惑」——米商務省が証拠を主張、ASML側は全面否定

米商務省がオランダの半導体製造装置メーカーASMLに対し、最先端の極端紫外線(EUV)露光装置が中国に流出した可能性があると非公式に通告したことが、Bloombergの報道で明らかになった。ASMLは「中国にEUV装置は存在しない」と全面否定しており、現時点では証拠も公開されていないが、半導体業界と生成AI産業全体を揺るがす重大な疑惑として世界中に波紋を広げている。 ASMLとはなにか——なぜここまで重要なのか ASMLを知らない人も多いかもしれないが、AI時代の今もっとも重要なインフラ企業の一つだ。同社はEUV(Extreme Ultraviolet Lithography)と呼ばれる次世代半導体露光技術の装置を製造する、世界で唯一のメーカーである。 EUV装置とは、半導体チップの回路パターンを極めて微細なスケールで「焼き付ける」機械だ。現在TSMCが製造するNvidiaやAppleの最先端チップはすべてASMLの装置に依存しており、代替品は地球上に存在しない。この絶対的なモノポリーにより、ASMLの時価総額はここ1年で急騰し、現在は約7,000億ドル(約105兆円)に達するヨーロッパ最大の上場企業となっている。 EUV技術の開発には20年以上と数兆円規模の投資が必要だったとされており、ASML CEOのChristophe Fouquet氏は「EUVのコア課題——光源の生成——だけでも20年かかった」と述べている。 疑惑の内容とASMLの反論 今回の疑惑はHoward Lutnick米商務長官がASMLの幹部との会合で、「EUV関連コンポーネントと輸送機器が中国に送られた証拠がある」と主張したことに端を発する。もしこれが事実であれば、トランプ政権第一期から続く輸出規制体制への重大な違反となる。 しかしASML側の反論は具体的かつ明確だ: 全台追跡: ASMLは自社が出荷したすべてのEUV装置を管理しており、現在も稼働中か廃棄返却済みのいずれかであると主張 内部ファイアウォール: EUV技術へのアクセスを許可された社員と中国拠点の社員を組織的に分離する仕組みを数年前に構築済み 中国向けはDUVのみ: 中国への販売は旧世代のDUV(Deep UV)装置に限られており、EUVは一切出荷していないと強調 さらに、ASML自身もBloombergに対して証拠の開示を求めているが、米国政府は現時点でそれに応じていないとされる。 商業的ロジックも中国流出説に反している ASMLが規制を破ってまで中国にEUVを売るインセンティブがあるかといえば、答えは「ほぼない」だ。 ASMLは許可された旧世代装置の中国向け販売から2026年売上の約20%(数千億円規模)を見込んでいる。EUVの禁輸措置を自ら破れば、その収益どころかEUV事業の輸出ライセンス全体を失うリスクがある。Fouquet CEOが言うように「旧世代を売ることで世代的なギャップを保ちながら取引関係を維持する」という戦略は、ビジネスとして合理的だ。違反のリスクがリターンをはるかに上回る。 日本のIT現場・エンジニアへの影響 この問題は半導体業界に閉じた話ではない。生成AIブームの根底を支える半導体のサプライチェーンに直撃する可能性がある。 Nvidiaのチップ製造はTSMC依存、TSMCはASML依存というチェーンが崩れれば、生成AIインフラ全体が揺らぐ。特に以下の点で影響を注視すべきだ: GPU調達コストと納期: 地政学リスクが高まるとNvidiaのH200/B200シリーズの調達競争がさらに激化する可能性 エッジAIへの波及: スマートフォンやPC向けAIチップを製造するTSMCのラインが影響を受ければ、端末側のAI処理能力向上にも遅れが生じうる 日本の半導体政策との連動: ラピダスがTSMCを通じて2nm世代を目指す計画も、ASMLのEUV装置調達が前提となっており、日本政府の半導体戦略にも無縁ではない エンジニアとしては今すぐ行動できることは少ないが、「GPU不足やクラウドAI価格が変動するリスクがある」という前提で、自社のAI基盤戦略に冗長性を持たせる検討は今のうちにしておくべきだろう。 筆者の見解 現時点で言えることは「証拠がない以上、ASML側の説明の方が整合性がある」という事実だけだ。追跡システム・内部ファイアウォール・商業的インセンティブ、どれを見ても違反に踏み切る合理的動機が見当たらない。 一方で、この疑惑が政治的に使われている側面も無視できない。米中の技術覇権争いは、実際の証拠よりも「疑いをかける」だけで相手に外交・経済的ダメージを与える非対称な手段として機能することがある。真偽が明らかになる前に市場や取引関係が動いてしまうリスクは常に存在する。 より本質的な問いは、「EUVという単一のボトルネックに世界の半導体産業が依存し続けることの脆弱性」だ。AIの発展速度が上がれば上がるほど、その基盤に位置する装置産業への依存が高まる。ASML一社のトラブルが全世界のAI開発速度に直結するという構造は、長期的に見ると健全とは言えない。これは非難ではなく、産業全体が向き合うべき構造問題として認識しておくべきだろう。 今後、米国政府が具体的な証拠を開示するか、逆にASMLの説明が広く受け入れられるかによって、輸出規制の議論はさらに激化する可能性がある。半導体と生成AIの交点で生きるエンジニアとして、この動向は継続的に追っていく価値がある。 出典: この記事は The US says ASML’s top chip tool may be in China. ASML says it isn’t の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 19, 2026 · 1 min · 胡田昌彦

xAIがGrok Imagine Video 1.5をリリース——$4.20/分の破格価格でImage-to-Video Arena首位を獲得、ネイティブ同期音声も搭載

イーロン・マスク率いるxAIは2026年6月17日、動画生成AIモデル「Grok Imagine Video 1.5」をリリースし、Image-to-Video Arenaで+52 Eloスコアを獲得してトップに躍り出た。さらに$4.20/分という価格設定はOpenAIのSora 2($30/分)の約7分の1という低さで、動画生成AI市場に価格競争の火蓋を切っている。 Grok Imagine Video 1.5の技術的特徴 ネイティブ同期音声を単一パスで生成 今回の最大の特徴は、音声と映像を「後付け合成」ではなく単一パスで同時生成できる点だ。これまでの動画生成AIの多くは映像生成後に音声をオーバーレイする方式を採用しており、口の動きと音声のズレが課題となっていた。Grok Imagine Video 1.5ではこのアプローチを設計レベルで見直し、音声同期の問題を根本から解決している。 高速な生成速度 6秒間の720p動画を約25秒で生成する。実用的なワークフローに組み込める速度感であり、試行回数を多く重ねながらプロンプトを改善するアジャイルなコンテンツ制作とも相性がいい。 Image-to-Video Arenaで首位獲得 コミュニティベースの評価プラットフォームArenaにおいて、+52 Eloという大幅なスコア差でトップを獲得した。EloスコアはAレベルの盲検比較評価を集計したもので、特定企業の自社評価とは異なる信頼性がある。 価格が示すもの——$4.20/分という数字 動画生成AI市場において価格競争はまだ始まったばかりだ。 サービス 価格(/分) OpenAI Sora 2 $30.00 Grok Imagine Video 1.5 $4.20 Sora 2と比較すると約7分の1という大幅な低価格だ。この価格差は単なるコスト優位にとどまらず、動画生成AIを「試しに使う」から「実務に組み込む」ための閾値を大きく下げる意味を持つ。 月に100分の動画を生成するワークフローを組む場合、Sora 2では$3,000かかるところが、Grok Imagine Video 1.5では$420で済む計算だ。コスト面のハードルが下がれば、マーケティング担当者・コンテンツクリエイター・開発者がAPIを活用したパイプラインを本格検討するフェーズに移行しやすくなる。 実務への影響——日本のエンジニア・コンテンツ制作者にとって API活用を前提とした動画制作パイプラインの設計 $4.20/分という価格は、APIを通じた自動化パイプラインを構築するのに現実的なコストラインだ。たとえば以下のようなユースケースが想定できる。 マーケティング素材の自動生成: 製品画像からショートフォーム動画を一括生成するバッチ処理 ゲーム・アニメ制作の補助: コンセプトアート→動画コンテの高速プロトタイピング 教育コンテンツ制作: スライド画像に音声付き説明動画を自動付与するワークフロー 特に「ネイティブ同期音声」の特性は、説明動画やチュートリアルコンテンツを自動生成するシーンで差別化要因になりうる。 技術選定時の注意点 動画生成AIの品質評価はArenaスコアだけでは不十分だ。自社コンテンツに即したプロンプトで実際に出力を比較検証することを強く勧める。解像度・動き・音声品質のバランスは用途によって優先度が変わるため、「Arena首位」という数字を鵜呑みにせず、実業務に近い条件でPoC(概念実証)を実施してから導入判断を下したい。 筆者の見解 動画生成AIの品質と価格が急速に収束しつつある今、「どのサービスが最高か」という議論より「どうコスト効率よくパイプラインに組み込むか」という設計思想の方が重要になってきた。 Grok Imagine Video 1.5が注目されるのは品質面の成果もさることながら、$4.20/分という価格設定が競合他社への圧力として機能する点にある。価格競争が激化すれば、最終的に恩恵を受けるのはコンテンツ制作者やエンジニアだ。 ただし、動画生成AIをワークフローに本格採用するには、単に「APIをたたく」だけでは足りない。品質チェック・リジェクト・リトライを含むハーネスループ的な設計が不可欠になる。1回の生成で確定稿が得られるわけではなく、品質評価→再生成のループを自動化して初めて実用的な生産性が生まれる。この「ループを設計する人」の価値は今後さらに高まるだろう。 xAIが動画生成AI分野でポジション確立を急いでいるのは明らかで、価格面での先手を打ちながら品質でもArena首位を狙いにいく姿勢は一貫している。技術を試す側にとっては、選択肢が増えコスト負担が下がることは純粋にポジティブな話だ。動画生成AIを「高価な実験」から「日常的な業務ツール」へと転換するきっかけになるかどうか、今後の普及状況に注目したい。 出典: この記事は xAI Releases Grok Imagine Video 1.5 — Claims #1 on Video Arena with Native Synced Audio at $4.20/min の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

June 19, 2026 · 1 min · 胡田昌彦

AlibabaのQwen3 Coder NextとMiniMaxのM2.7が同日リリース——コーディングエージェント向けLLM競争が本格化

Alibaba(阿里巴巴)のAIチームが開発した「Qwen3 Coder Next」(最大コンテキスト262Kトークン)と、中国AIスタートアップMiniMaxの「M2.7」(最大205Kコンテキスト、入力コスト$0.25/Mトークン)が2026年6月18日に相次いで公開された。どちらもソフトウェアエンジニアリングとツール利用に特化して設計されており、コーディングエージェント向けLLMの主戦場で競争が明確に激化している。 2モデルの技術仕様と特徴 Qwen3 Coder Next はAlibaba Cloudが継続的に強化してきたQwen3ファミリーのコーディング特化版として位置づけられる。最大の看板は262Kトークンというコンテキストウィンドウで、大規模リポジトリの複数ファイルをまとめて把握しながらコード生成・修正を行える。ツール呼び出しに最適化されたアーキテクチャにより、ファイル操作・コンパイル・テスト実行といったエージェントループの各ステップを精度よく処理できることが期待されている。 MiniMax M2.7 は205Kトークンのコンテキストに加え、入力コスト$0.25/Mトークンという攻撃的な価格設定が目を引く。コーディングと多様なツール利用の両立を訴求しており、複数エージェントを並走させてコスト効率を最大化したいユースケースで有力な選択肢となる。両モデルともOpenRouterなどのAPIアグリゲーター経由で即日利用可能になっており、既存のエージェントフレームワークへの統合ハードルは低い。 なぜコーディングエージェント向けモデルがこれほど増えているのか 2026年に入り、AI業界の主戦場は汎用チャットから自律型コーディングエージェントへと明確にシフトしている。背景にはいくつかの構造的な変化がある。 長大コンテキストが実用性の基本スペックになった: 実務規模のコードベースでは単一ファイルではなくリポジトリ全体を把握した上で修正を判断する必要がある。100K〜300Kのコンテキスト長は「目玉機能」から「基本要件」へと格上げされつつある。 ツール呼び出し精度が真の差別化ポイント: コードを生成できること以上に、「ツールを正しく呼び出し、実行結果を受け取り、次の行動を判断する」精度がエージェントの実力を左右する。汎用LLMではなくコーディングエージェントループに特化したファインチューニングの有効性が各社で確認されてきた。 価格競争が参入障壁を下げる: M2.7の$0.25/M入力という価格帯は、長時間稼働するエージェントを低コストで運用できることを意味する。大手企業だけでなく個人開発者やスタートアップにとっても本格的なエージェント導入が現実的になる。 日本のエンジニア・IT管理者への影響 実務での活用ポイント 大規模コードベースへの適用を試す好機: 262Kや205Kのコンテキストは、モノレポや複数モジュールにまたがるリファクタリング作業に直接使える。「ファイルが多すぎてAIに渡せない」という制約が着実に解消されてきた。OpenRouter経由でモデル名を差し替えるだけで比較評価できるため、本番環境に影響を与えず試験導入しやすい。 並列エージェント設計への応用: M2.7のような低価格モデルは「複数エージェントを並走させて結果を比較・統合する」アーキテクチャに向いている。品質要求が高いタスクと大量処理が必要なタスクで異なるモデルを組み合わせる設計が現実的なコストで実装できる。 情報セキュリティポリシーの確認を忘れずに: 両モデルとも中国籍企業が提供するAPIを経由する。組織のポリシーによっては、社内ソースコードや機密情報を送信することに制約が生じる場合がある。導入前に情報セキュリティ部門と確認しておくことを強く推奨する。特に上場企業や金融・医療系の企業では、APIの送信先国を問題視するポリシーが存在することが多い。 筆者の見解 コーディングエージェント向けLLMのリリースペースがここまで上がってきたことは、私がここ数ヶ月追い続けている「ハーネスループ」というテーマと直結している。エージェントが自律的に「コードを書く→テストを実行する→エラーを確認する→修正する」というループを精度よく回せるかどうかは、まさにLLMのツール呼び出し精度と長大コンテキストの活用能力にかかっている。Qwen3 Coder NextもMiniMax M2.7も、その設計思想においてこの要求に正面から応えようとしており、「ループ設計に使えるモデルの選択肢が増えた」と素直に受け止めている。 ただし、実際の品質はリリース直後には判断できない。特に長時間エージェントループでの一貫性、ツール呼び出し失敗時のリカバリ能力、そして日本語コメントや日本語仕様書を扱う際の精度については、自分のユースケースで実際に動かしてみないと評価できない。スペックシートの数字は入口に過ぎず、本番に近い環境でのテストが全てだ。 より大きな視点で見ると、この価格競争の加速は「エージェントを使うかどうか」という段階の議論をもはや無意味にしつつある。問われるのは「どう設計するか」であり、日本のIT現場がその問いに向き合えるかどうかが、この先2〜3年の競争力を決める分水嶺になると感じている。 出典: この記事は Qwen3 Coder Next and MiniMax M2.7 Released Simultaneously on June 18 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 19, 2026 · 1 min · 胡田昌彦

Midjourney、AIイメージ生成から医療ハードウェアへ——全身超音波スキャナー「Midjourney Scanner」を発表

AI画像生成ツールとして知られるMidjourneyが、同社初のハードウェア製品「Midjourney Scanner」を発表した。CEOのDavid Holz氏が公開したこのデバイスは、超音波技術を使った全身スキャナーであり、「猫の画像を生成するツール」とはまったく異なる方向性への大きな一歩だ。 Midjourney Scannerとは何か Midjourney Scannerは、超音波の輪状センサーアレイを使って全身の断面画像を取得する装置だ。利用者はプラットフォームに乗り、水槽の中をゆっくりと降下しながら、数千個のトランスデューサーが発する超音波を全方向から受ける。波の透過パターンを解析することで、筋肉・脂肪・骨・内臓の3D構造を可視化する仕組みだ。スキャン時間はわずか約60秒。 開発にはButterfly Network社が協力しており、同社の「Ultrasound-on-Chip」技術モジュールを1台あたり40個搭載している。処理能力は2ペタフロップスで、取得した超音波データをリアルタイムにAIで解析・セグメント化する。Holz氏は「多くの点でMRIに匹敵する画像品質を目指している」と述べており、年1回から毎日の利用まで想定している。 スパ体験として提供するというアプローチ 注目すべきはサービスの提供形態だ。Midjourneyは2027年末までにサンフランシスコのユニオンスクエアに「Midjourney Spa」をオープンする計画を発表した。スキャナー10台に加え、ジム・サウナ・コールドプランジも備えるウェルネス施設として展開する。 これは賢い戦略だ。医療診断デバイスとしてFDA承認を取得するには長い時間とコストがかかる。一方で「体組成マップ」の可視化は現時点では医療診断とは異なる位置づけができ、規制上のハードルを下げながら市場に入れる。まずはウェルネス文脈で普及させ、データと実績を積んでから医療応用へ拡大するという段階的アプローチと読める。 取得したスキャンデータは医師やAI健康ツールと共有できるとしており、「データプライバシーは真剣に扱う」とコメントしているが、具体的なポリシーはサービス開始前に公開予定とのことだ。 実務への影響——ヘルステックとAI計算資源の転用 今回の発表で興味深いのは、Midjourneyが保有するAI計算資源(当初は画像生成向けに整備されたGPUクラスター)を医療画像解析に転用している点だ。画像生成AIとメディカルイメージングは、ドメインは異なるが「大量のデータから高精度な画像を生成・解析する」という技術的基盤を共有している。 日本のヘルステック・医療IT分野に携わるエンジニアや事業者にとって注目すべきポイントは以下の通りだ: 超音波×AI解析の組み合わせ: 超音波は放射線を使わず安全性が高い。MRI相当の画質をより手軽に実現できれば、定期健診や予防医療の分野で大きなインパクトがある スキャンデータの活用設計: Midjourneyは「ライブラリ構築」と「共有」を設計に組み込んでいる。電子カルテや健康管理アプリとの連携API設計の参考になる ウェルネス文脈での規制回避戦略: 医療機器認証を待たずに市場に入るアプローチは、日本のSaMD(Software as a Medical Device)対応を検討するスタートアップにも参考になる事例だ 筆者の見解 この発表で最も面白いと感じたのは、「技術資産の転用」という発想だ。画像生成AIで蓄積した計算資源とAI技術を、まったく別のドメインに持ち込む。Holz氏が「使われていないAI計算能力の代替ビジネス」と正直に言っているように、これはある意味で余剰リソースの有効活用だ。 ただし、医療ハードウェアは画像生成よりはるかに「失敗の許されない」領域だ。スキャン精度の検証、データ管理の透明性、FDA承認への道筋——現時点ではまだ十数人しかスキャンされていない段階であり、「MRI相当」という主張の裏付けにはまだ距離がある。技術的なポテンシャルは否定しないが、医療応用として成立するかどうかは今後のデータ次第だ。 より大きな視点で言えば、これはAI企業が「モデルを売る」から「体験として提供する」へとシフトする動きの一例でもある。スパという文脈で体験を包むことで、医療への抵抗感を下げながら利用者を増やし、スキャンデータという新たなデータ資産を積み上げる——この設計思想は今後の業界全体に影響を与えるかもしれない。 日本でこの種のサービスが普及するとすれば、医療法・個人情報保護法との整合性と、保険適用の議論が先に必要になる。技術そのものより、社会実装のハードルの方が高い。そこをどう乗り越えるかを、Midjourneyの挑戦から学べるものは多いと思っている。 出典: この記事は Midjourney goes from generating cat images to full-body ultrasound scans の内容をもとに、筆者の見解を加えて独自に執筆したものです。

June 18, 2026 · 1 min · 胡田昌彦

AIに「目標だけ」渡して寝たら、毎日コードが進化する。AIエージェントによるメタ改善ループの実装方法。

続きをみる note.com で続きを読む →

March 13, 2026 · 1 min · 胡田昌彦

AI・テクノロジーの情報を発信しています

YouTube

AI・テクノロジーの最新トレンドを動画で配信中

note

技術コラム・深掘り記事を公開中