生成AI

米国でAI関連の技術標準を担う政府機関「CAISI（Center for AI Standards and Innovation、AI標準革新センター）」のトップがまた辞任した。ディレクターのChris Fall氏が就任からわずか3か月で退任したことを、CAISIが複数の報道機関に確認した。CAISIのトップ交代はこれで3人目、しかも1年に満たない期間での出来事だ。 CAISIとは何か、なぜトップが居着かないのか CAISIは米国立標準技術研究所(NIST)傘下の組織で、AIモデルの技術標準策定やテスト手法の開発、サイバーセキュリティリスクの評価を担う、AI政策の実務を支える機関だ。 その最初のトップは、ベンチャーキャピタリストでホワイトハウスのAI・暗号資産担当「AI czar」だったDavid Sacks氏で、3月に退任。後任のCollin Burns氏は就任から1週間足らずで「更迭」されたとWashington Postが報じている。BurnsはAnthropic出身で、トランプ政権とAnthropicの間の対立が背景にあったとされる。そして4月から3か月務めたChris Fall氏も、明確な理由の説明なく去った。エネルギー省で科学局長やARPA-E局長代理を歴任した人物ですら、この椅子には長く座れなかった。 Anthropicモデル排除と中国オープンモデル規制論争 このポストがこれほど落ち着かない背景には、AI規制を巡る政権内の路線対立がある。6月には商務省が輸出規制の一条項を使い、AnthropicのMythosとFableのモデルを事実上市場から排除する措置を取った。この禁止措置はLutnick商務長官がAnthropicの安全計画に納得したとして月末に解除されている。 さらに今月、ホワイトハウスはサイバーセキュリティ脆弱性の調整を担う新しいAI安全監視プログラム「Gold Eagle」の大統領令に署名したが、CAISIはこのプログラムの参加機関リストに含まれていなかったとCNBCが指摘している。 同じタイミングで、中国Moonshot AI社のオープンモデル「Kimi」の新版がフラッグシップ級のモデルと遜色ない性能を見せたことも波紋を広げた。Axiosの報道によれば、政権内では中国製オープンモデルを何らかの形で禁止する案が検討されているという。これにはSacks氏本人も反対を表明しており、「規制を自国AI企業の保護主義の道具にすべきではない」と主張している。一方でGoogle DeepMindのDemis Hassabis CEOは、FINRA(米金融取引業規制機構)をモデルにした、業界主導の独立した標準策定機関の設立を呼びかけている——まさにCAISIが本来担うはずだった役割だ。 CAISIはこれまでZ.aiのGLM-5.2やDeepSeekのV4 Proなど中国製オープンウェイトモデルの性能評価レポートをいくつか出しているが、その評価プロセスの詳細は明らかにしていない。TechCrunchが7月9日以降、商務省とNISTに複数回問い合わせているが、回答は得られていないという。 実務への影響 日本のIT現場にとって直接の影響は小さく見えるかもしれないが、注意すべき点が2つある。 1つ目は、米国の輸出規制がAIベンダーの提供継続性そのものを揺さぶりうるという事実だ。今回Anthropicのモデルが一時的に市場から消えた一件は、政治判断ひとつでクラウドAIサービスが使えなくなるリスクが現実にあることを示した。特定ベンダー・特定国のモデルに全面依存する構成は、技術的な最適解であっても地政学リスクの面では脆弱になりうる。 2つ目は、中国製オープンウェイトモデル(DeepSeek、GLM、Kimiなど)を評価・検証中の企業は、今後の規制動向を注視する必要があるという点だ。オープンウェイトで自前ホストできる利点があるため国内でも採用例が増えているが、規制強化が輸入・利用そのものに及ぶ可能性はゼロではない。 筆者の見解 正直なところ、この手のニュースを逐一追いかけて一喜一憂する必要はないというのが筆者の基本スタンスだ。米国の政局がどう転んでも、エンジニアが今日やるべきことは変わらない——手元で使えるツールを全力で使い倒し、実際に成果を出す経験を積むことに尽きる。 ただし、AnthropicのモデルがCommerce省の一存で一時的に市場から消えたという事実は見過ごせない。技術標準や安全性評価という本来もっとも政治から距離を置くべき機能が、政権交代のたびにトップごと入れ替わる不安定な状態にあるのは、業界全体にとって望ましいことではない。その意味で、Hassabis氏が提案するFINRA型の業界主導・独立系標準機関という方向性は理にかなっている。技術的な検証は技術のプロが担い、政治的な駆け引きから切り離す仕組みがあった方が、ベンダーにとってもユーザーにとっても予見可能性が高まるはずだ。 日本の開発者にできることは限られているが、「特定の国・特定のベンダーに依存しすぎない」という当たり前のリスク管理を、AIスタックの選定でも徹底することだろう。クラウドもローカルも、複数の選択肢を手元に持っておく。それが、こうした政策の混乱に振り回されないための一番の備えだ。 出典: この記事は Trump’s latest AI czar has already resigned の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ドイツのAIスタートアップPrior Labsが、設立からわずか18カ月でSAPに買収されることが2026年7月17日に発表された。買収額は10億ユーロ超で、SAPは今後4年間にわたり同社のインフラ整備・人材採用・長期研究に資金を投じる。Prior Labsは企業の構造化データ（表形式データ）に特化した「表形式基盤モデル（Tabular Foundation Model、TFM）」の先駆者で、支払い遅延予測や顧客離反予測、サプライヤーリスク評価、需要予測といった企業の予測業務を、データセットごとに個別学習することなく単一の事前学習済みモデルでこなせる技術を開発してきた。 表形式基盤モデルとは何か 生成AIの主戦場はテキストや画像を扱う大規模言語モデル（LLM）だが、企業の基幹業務を支えているデータの大半は、売上・在庫・顧客属性・センサーログといった表形式（テーブル型）の構造化データだ。従来、こうしたデータで予測モデルを作るには、案件ごとに個別の機械学習モデルを一から学習させる必要があった。 Prior Labsの中核技術TabPFNは、この前提を覆す。あらかじめ大量の合成データで事前学習された単一の基盤モデルが、追加学習なし、あるいは軽い適応だけで新しい表形式データに対して予測を行える。最新版「TabPFN-3-Thinking」は、表形式予測タスクにおいて業界最高水準・エンタープライズ級の性能を達成しているという。実際に鉄道車両大手Hitachiは車両故障の予兆検知に、金融機関TDは財務予測にこの技術を採用済みで、膵臓がん診断からワイルドファイア予測、次世代電池材料の探索まで、数百件の研究プロジェクトで応用されている。 SAPの狙いと独立性の維持 SAPのCTOであるPhilipp Herzig氏は、「エンタープライズAIで最も手つかずの機会はLLMではなく、世界中の企業を動かしている構造化データ向けのAIだった」という趣旨のコメントを出している。SAPはERPという形で世界中の企業データを扱ってきた立場を生かし、Prior Labsのモデルと自社の顧客基盤・データ環境を組み合わせることで、このカテゴリーで主導権を握る狙いだ。 一方でPrior Labsは買収後もブランド・経営陣・研究方針・既存顧客との関係を維持し、独立した研究機関として活動を続ける。研究成果の公開やモデルのオープンな提供も継続する方針で、SAPは資金と大規模データ環境の提供に徹する形だ。Yann LeCun氏やBernhard Schölkopf氏といった著名研究者が科学諮問委員会に名を連ねている点も、同社が単なる買収先ではなく独立した研究拠点として扱われていることを裏付けている。 実務への影響 日本でもSAP ERPを基幹システムとして使う企業は多く、需要予測・支払い遅延予測・サプライヤーリスク評価といった業務は経理・調達・生産管理の現場に直結する。表形式基盤モデルが実用段階に入れば、こうした予測業務を「データサイエンティストが個別にモデルを作る」ことから「基盤モデルに業務データを渡すだけ」に近づけていける可能性がある。IT部門にとっては、SAPの標準機能として将来この種のAIが組み込まれることを見越し、自社データの品質・構造化整備を今から進めておく価値がある。バラバラに個別最適なAIツールを導入するより、基幹システムのベンダーが用意する標準的な仕組みに乗る方が、長期的な運用コストは低く済むはずだ。 筆者の見解 今回の買収で興味深いのは、SAPが「LLMで何かをやる」ではなく、地味だが実務に直結する表形式データの予測AIに本気の投資をした点だ。派手なチャットボットや生成AIのデモよりも、経理や調達の現場で実際に数字を動かす技術に賭けるというのは、奇をてらわない王道の選択だと感じる。 生成AIの話題はどうしてもLLMやAIエージェントに集中しがちだが、企業の意思決定の大半は依然として表形式データの上で行われている。そこに特化した基盤モデルという発想は、地に足がついていて好感が持てる。買収後もPrior Labsの独立性を保ち、研究成果とモデルを引き続きオープンにする方針も、目先の囲い込みより長期的な技術力の蓄積を優先する姿勢として評価できる。 日本の企業にとっても、SAPという既に導入済みの基幹システムの延長線上でこの技術に触れられるようになるなら、新しいAI基盤を一から選定する負担なく実務に取り入れやすい。派手さより実利、という今回のSAPの判断は、今後のエンタープライズAIの一つの「王道」になっていくのではないかと見ている。 出典: この記事は SAP acquires Prior Labs just 18 months after launch in €1B+ deal の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Grok Buildとは何か xAI（現在はSpaceXとの統合で「SpaceXAI」ブランドに移行）が、自社のコーディングエージェント「Grok Build」の中核をなすエージェントループとTUI（ターミナルUI）を、Apache 2.0ライセンスでオープンソース化した。公開されたのは、コードの読み書き・検索、シェルコマンド実行、長時間タスクの管理までを担う一式で、Rustで書かれたコードは84万行超に及ぶ。GitHub（xai-org/grok-build）で誰でも閲覧・ビルドできる。 エージェントの中身は「ハーネス」と呼ばれる仕組みだ。モデルに渡すコンテキストを組み立て、モデルを呼び出し、返答を解析し、ツール呼び出しを実行に落とし込む——このループ自体を公開したことで、Claude CodeやCodex CLI、Gemini CLIといった競合ツールの内部構造を推測する手がかりにもなる。またAgent Client Protocol（ACP）に対応しており、Zedなどこの規格をサポートするエディタへの組み込みも可能。config.tomlの設定でOpenAI Chat Completions・OpenAI Responses・Anthropic Messages各プロトコルのカスタムエンドポイントを指定でき、Ollama等のローカル推論に接続してフルローカルで動かすこともできる。 なぜ「今」なのか このタイミングには裏がある。7月12日、セキュリティ研究者がGrok Buildの通信を解析し、ユーザーの手元のGitリポジトリ全体（追跡ファイルとコミット履歴一式）が、xAI側のクラウドストレージに無断でバンドル送信されていたことを公表した。ユーザーが個別にオフにできるはずの「プライバシートグル」は実質機能していなかったという指摘も出た。批判が広がった直後の7月15日、xAIはこの機能をデフォルト無効化し、過去に収集したデータの削除を発表。そのわずか72時間後にソースコード一式を公開した——という時系列だ。 なお「オープンソース」とはいえ、外部からのコントリビューションは受け付けず、GitHub Issueも無効化されている。コミュニティで育てる形の一般的なOSSとは違い、「監査できる状態で公開する」ことに主眼を置いた措置だと見た方がよい。 実務への影響 日本のエンジニア・IT管理者にとっての教訓は明確だ。エージェント型コーディングツールを導入する際、「どこまでの情報が、どこに、いつ送られるか」を仕様書やプライバシーポリシーの記述だけで信じず、通信内容を実際に確認する運用が必要になる。特にGitリポジトリには顧客コードや機密設計が含まれることが多く、「禁止」で済ませず、ネットワーク監査やローカル実行オプションの有無を評価基準に組み込むべきだ。今回Grok Buildが示したような「モデルとハーネスを分離し、ローカルLLMや他社APIにも接続できる」設計は、社内データを外に出したくない企業にとって参考になる選択肢の一つになる。 筆者の見解 エージェントの中身、つまり「ハーネスループ」を丸ごと読める形で出してきたこと自体は歓迎したい。コンテキスト組み立てからツール呼び出しまでの一連の設計は、まさに今どのAIエージェントを作る人にとっても最前線のテーマであり、実装例が一つ増えることには素直に価値がある。 ただし、今回の「オープンソース化」を額面通りの太っ腹な決断として受け取るのは早計だろう。リポジトリを無断でクラウドに送っていた問題が発覚してから公開まで72時間、しかも外部からの修正提案は受け付けないという運用を見る限り、これは「信頼を取り戻すための見せ方」としての側面が強い。エージェントに何を預けるかを判断するのは結局のところ、開発者一人ひとりが「実際に何が送信されているか」を自分の目で確認する姿勢であって、ベンダーの発表文だけを信じないことに尽きる。 出典: この記事は Grok Build is Now Open Source の内容をもとに、筆者の見解を加えて独自に執筆したものです。

中国Alibaba傘下のAI開発チームは7月19日、パラメータ数2.4兆という超大規模なマルチモーダルAIモデル「Qwen3.8-Max」のプレビュー版を発表した。テキストに加えて画像・動画・文書の理解にも対応し、性能はAnthropicの「Fable 5」に次ぐ水準だと自社は主張している。オープンウェイト版も近日公開予定で、中国のAIスタートアップMoonshot AIが「Kimi K3」をオープンウェイトで公開してからわずか数日というタイミングでの投入となった。 Qwen3.8-Maxとは何か AlibabaのQwen（通義千問）シリーズは、Qwen、Qwen2、Qwen2.5、Qwen3とバージョンを重ねてきた大規模言語モデル群で、オープンウェイトモデルとしてHugging Face等で広く公開され、世界中の開発者やエンタープライズに採用されてきた実績がある。今回発表された「Qwen3.8-Max」はそのフラッグシップにあたる位置づけで、パラメータ数は2.4兆と、これまでのQwenシリーズの中でも突出した規模になる。現時点ではプレビュー版の発表であり、詳細な技術レポートや第三者機関によるベンチマーク検証はこれからという段階だ。 2.4兆パラメータとマルチモーダル対応の中身 2.4兆パラメータという規模は、単一の巨大な密なモデルとして運用するには推論コストが現実的ではない水準だ。近年の兆パラメータ級モデルの多くはMixture-of-Experts(MoE)構成を採用し、1トークンあたりの計算に使う「アクティブパラメータ」を絞ることで推論コストを抑える設計になっている。Qwen3.8-Maxも同様のアプローチを取っている可能性が高い。マルチモーダル対応としてはテキスト・画像・動画・文書理解が挙げられており、OCRや契約書・請求書などの文書処理、動画コンテンツの要約・検索といった実務ユースケースへの応用が見込まれる。 Moonshot AIのKimi K3からわずか数日という投入タイミング 今回特筆すべきは投入のタイミングだ。中国のAIスタートアップMoonshot AIが大規模言語モデル「Kimi K3」をオープンウェイトで公開した直後に、AlibabaがQwen3.8-Maxのプレビューをぶつけてきた形になる。DeepSeekも含め、中国のAI開発陣営はここ数週間、大規模モデルをたたみかけるように発表しており、パラメータ規模・投入速度の両面で競争が過熱している。「Anthropicの Fable 5 に次ぐ性能」というAlibabaの主張は、あくまで自社発表段階のものであり、独立した第三者評価が出そろうまでは参考情報として受け止めるのが妥当だろう。 実務への影響 日本のエンジニアやIT管理者にとっての論点は主に3つある。第一に、2.4兆パラメータ級のモデルを自前でホストするインフラコストは非常に大きく、オープンウェイト版が公開されても、多くの企業にとっては現実的な選択肢はAPI経由での利用になる。第二に、中国発のモデルは中国語・英語を中心にチューニングされることが多く、日本語での実務精度は個別の検証が欠かせない。第三に、海外のAI基盤を業務に組み込む際は、データがどこを経由し、どこに保存されるかというデータ主権・セキュリティ要件の確認を怠らないことが重要だ。ベンダーの自己申告ベンチマークをそのまま鵜呑みにせず、自組織の実際のユースケースで小さく試してから判断する姿勢が、これまで以上に求められる。 筆者の見解 中国発の大規模モデルは、Moonshot AIのKimi K3に続いて今回のQwen3.8-Maxと立て続けに発表されており、パラメータ規模でも投入速度でも競争が明らかに過熱している。ただ、筆者はこの手の新モデル発表を逐一追いかけることにはあまり価値を感じていない。「Anthropicの次点」という自社評価は、第三者検証を経るまでは参考程度に留めておくのが健全な受け止め方だろう。ベンダーの主張の真偽を追いかけるよりも大事なのは、今すでに使えるツールを実際の業務で使い倒し、そこから成果を出す経験を積むことだと考えている。筆者自身は目下、Claude Codeを軸にAIエージェント活用のノウハウを蓄積することに時間を割いており、次々登場する新モデルの一つひとつを深追いする余裕はない。とはいえ、オープンウェイト版が実際に公開されれば、コストやデータ主権の観点から選択肢の一つとして手元で検証する価値はある。中国勢の技術力の高さは侮れず、今後も動向はウォッチしておきたい。 出典: この記事は Alibaba Previews Qwen3.8-Max, a 2.4 Trillion-Parameter Multimodal Model, Days After Moonshot’s Kimi K3 Open-Weight Launch の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

ソニー・ミュージック・エンタテインメント（Sony Music Entertainment、SME）は現地時間7月20日、AI音楽生成サービス「Udio」を著作権侵害でニューヨーク連邦地方裁判所に新たに提訴した。対象となる楽曲はエルヴィス・プレスリーの「Hound Dog」からビヨンセの「Say My Name」、ハリー・スタイルズの「As It Was」まで3万曲を超える。 発端は2024年の共同訴訟、開示手続きで対象が急拡大 話は2024年にさかのぼる。SMEはユニバーサル ミュージック グループ（UMG）、ワーナー・レコードとともに、Udioと競合の音楽生成AI「Suno」を著作権侵害で提訴した。この時点での対象楽曲は333曲だった。 その後の開示（ディスカバリー）手続きでUdioの学習データへのアクセスが認められたことで状況が一変する。SMEは「オーディオ・フィンガープリンティング」という技術を用いて、Udioが無断で学習データに取り込んだとみられる楽曲をさらに3万曲以上特定したと主張している。SMEは当初、この3万曲分を既存の訴訟に追加する形で申し立てたが、裁判所はこの拡大申請を却下した。そこでSMEは新たに単独の訴訟を起こす形をとった。 訴状でSMEは、Udio自身が「学習用プログラムに大量の多様な音源を見せることで（モデルを）構築した」と認めており、その音源にはYouTube由来のものも含まれると主張している。SMEは差止命令に加え、侵害1曲あたり最大15万ドルの法定損害賠償を求めている。対象曲の全リストは訴状に添付されており、SMEは今後さらに対象を拡大する可能性があるとしている。 興味深いのは、同じ2024年の共同原告だったUMGとワーナー・ミュージック・グループはすでにUdioと和解し、現在はパートナーとしてAI音楽生成を業界に取り込む方向に舵を切っている点だ。音楽業界全体が「訴訟か協業か」の分岐点に立たされている中で、SMEだけが訴訟継続という強硬路線を選んでいる。 日本のIT現場にとっての意味 この訴訟は音楽業界だけの話に見えるが、実際は生成AI全般が抱える「学習データの出所問題」の縮図だ。テキスト生成AIの世界でも、ニュース出版社や作家団体が大手AI企業を相手取った訴訟が続いており、音楽・画像・コード・文章、あらゆるモダリティで同じ構図の争いが起きている。 日本企業がAI生成コンテンツ（音楽・画像・BGM等）を製品やマーケティング素材に組み込む際は、「そのAIツールの学習データが適法にライセンスされているか」を確認することが今後ますます重要になる。特にUdioのように訴訟が係属中のサービスを商用利用に組み込むと、後から差止命令や損害賠償請求の巻き添えを食うリスクがある。IT管理者は、社内でAI生成ツールを導入する際のガイドラインに「学習データのライセンス状況の確認」を項目として加えておくべきだろう。 筆者の見解 今回の訴訟で象徴的なのは、同じ原告陣営だったUMGとワーナーがすでにUdioと和解し協業に転じている一方、SMEだけが訴訟を続けているという対比だ。これは「AIを禁止するか、安全に使える仕組みを作るか」という選択そのものを体現していると感じる。禁止だけを続けるアプローチは長期的にはうまくいかない。ユーザーやクリエイターにとって「公式に提供された、ライセンスがクリアな仕組みが一番便利」という状態を作れた側が、結局は市場を取ることになる。 UMGとワーナーの動きは、まさにそうした「安全に使える仕組み」への転換だろう。学習データのライセンス問題を解決し、アーティストへの還元の仕組みを組み込んだ上でAI音楽生成を受け入れる——このアプローチのほうが、訴訟を延々と続けるより実利があるはずだ。SMEの今回の提訴も、Udioとの協業合意に向けた交渉材料としての側面を持っているとしても不思議ではない。 日本の音楽・エンタメ業界も、AI生成コンテンツとの向き合い方を「様子見」から「仕組み作り」へ移す時期に来ている。技術を止めることはできない以上、ライセンスと収益還元の設計を先にやった者が主導権を握る。それは生成AIのあらゆる領域に共通する教訓だと思う。 出典: この記事は Here are the 30,000 songs Sony is suing Udio’s AI music generator over の内容をもとに、筆者の見解を加えて独自に執筆したものです。

欧州委員会は2026年7月17日、デジタル市場法（DMA: Digital Markets Act）に基づき、GoogleにAndroidの音声AIアシスタントを競合他社に開放するよう命じた。これまでAndroid端末には自社AI「Gemini」が標準搭載され、他のAIアシスタントへの切り替えが事実上困難だったが、今後はAnthropicやOpenAI、フランスのMistral AIといった競合のチャットボットも、音声起動でスマートフォンを直接操作できるようになる見通しだ。 何が問題視されたのか 欧州委員会が問題視したのは、GeminiのAndroidへのプリインストールが、EU域内の成人の60%を占めるAndroidユーザーにとって、サードパーティ製AIモデルの魅力を実質的に削いでいた点だ。OSレベルで特定のAIアシスタントが有利な立場を占め続けると、ユーザーが本当に使いたいAIを自由に選べなくなる。これはDMAが定める「ゲートキーパー」規制の典型的な対象であり、検索エンジンやブラウザの既定設定を巡る過去の規制と同じ構図といえる。 実際、EUは2010年前後にもWindowsの既定ブラウザ選択画面（ブラウザ・チョイス）を巡って同様の是正措置を求めた前例がある。プラットフォーム標準搭載アプリの独占状態を規制で崩すというアプローチ自体は、EUにとって目新しいものではない。 誰が恩恵を受けるのか 直接の恩恵を受けるのはAnthropicやOpenAIだ。両社のチャットボットは今後、Android端末の音声起動経由でスマートフォンを操作できるようになる可能性がある。もう一つの注目株がフランスのMistral AIだ。同社の共同創業者はEconomist誌の取材に対し、米国が先端AIモデルへのアクセスを制限する中で「欧州は自前のAIエコシステムを持つ必要がある」と述べている。EU域内での主権的AI基盤の育成という文脈からも、今回の命令の意味は大きい。 実務への影響 日本のエンジニアやIT管理者にとっても、この動きは他人事ではない。Googleはグローバルでポリシーを統一する傾向が強く、GDPR同様、DMA対応の仕組みがEU域外にも波及することは珍しくない。Android Enterpriseで社用端末を管理している情シス担当者は、既定AIアシスタントの選択肢がOSレベルで増える可能性を見越し、MDM（モバイルデバイス管理）ポリシーの見直しを今のうちに検討しておく価値がある。 特に重要なのは、音声起動でスマートフォンを直接操作できるAIアシスタントが増えるということは、それだけ端末レベルでの攻撃対象領域（アタックサーフェス）が広がるということだ。管理対象デバイスでどのAIアシスタントの利用を許可するか、単純に禁止で対応するのではなく、安全に使える仕組みとして設計しておくことが、結局は現場の摩擦を減らす近道になる。 筆者の見解 今回の命令の面白さは、単なる独禁法上の是正にとどまらず、「AIアシスタントがOSレベルでスマートフォンを直接操作する」という前提そのものを規制が後押ししている点にある。確認・承認をいちいち人間に求める「副操縦士」型ではなく、目的を伝えれば自律的にタスクをこなす自律エージェント型のAIこそ本質的な価値を生む、というのが筆者の一貫した立場だ。今回の措置でAndroidという巨大なプラットフォーム上に複数のAIエージェントが並び立つ状況が生まれれば、その競争を通じて自律型エージェントの実用化が加速する可能性がある。 一方で、企業のIT管理者からすれば、選択肢が増えることは歓迎すべきだが、無条件に手放しで喜べる話でもない。管理対象デバイスでどのAIエージェントに何を許可するかというガバナンス設計を怠れば、単に管理コストが増えるだけに終わる。「禁止すれば安全」という発想では現場は回らない。安全に使える仕組みを作った上で、ユーザーが自然と使いたくなる選択肢を用意する。これは生成AI活用全般に通じる原則であり、今回のEUの措置はその実践の場を広げる好機と捉えたい。 出典: この記事は EU orders Google to open Android AI system to rivals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Alphabet（Google親会社）が、自社のGeminiモデルをより効率的に動かすための新型サーバー向けAIチップ「Frozen v2」を開発していることが、The Informationの報道で明らかになった。報道によれば、投入時期は2028年ごろとされ、消費電力あたりのトークン生成数で見た効率は、Googleの既存AIチップと比べて6〜10倍に達する可能性があるという。GoogleはTechCrunchの取材に対し、報道内容を直接肯定も否定もせず、「チームは常に新しい技術革新を研究・実験している」「ハードウェアとソフトウェアを一体で設計することが実世界のワークロードに最適化する鍵」とコメントするにとどめている。 自社チップ開発が業界標準になりつつある Googleは長年、TPU（Tensor Processing Unit）と呼ばれる独自AIチップを開発してきたが、Frozen v2はその後継にあたる存在とみられる。背景にあるのは、AI業界全体で進む「脱Nvidia」の動きだ。OpenAIは6月、初の独自推論チップ「Jalapeño」を発表しており、Anthropicもサムスンとの新たなチップ製造提携を協議していると報じられている。GPUの供給不足とNvidiaへの依存リスクを解消しつつ、AI投資に見合うリターンを示す必要に迫られていることが、各社を自社シリコン開発へと駆り立てている。Googleは今年、AI関連投資に1800億〜1900億ドルを投じる計画を示しており、投資家からは「その巨額投資が本当に回収できるのか」という懸念が根強い。Frozen v2の報道後、Alphabet株は月曜朝に約3%上昇しており、今週予定される決算発表を前に市場の期待をつなぎとめた形だ。 実務への影響 日本のIT現場にとって重要なのは、これが「Googleだけの話」ではないという点だ。Microsoftも独自AIチップ「Maia」やサーバー向けCPU「Cobalt」の開発を進めており、Azure上のAIワークロードのコスト構造は今後、ハイパースケーラー各社の自社シリコン戦略に左右される度合いを強めていく。IT管理者にとっての実務ポイントは、①クラウドベンダーのAIチップ戦略はAPI価格・SLA・リージョン展開に数年単位で影響すること、②特定ベンダー・特定モデルへの依存を前提にせず、コスト効率で乗り換えられる設計を保つこと、③目先の性能比較だけでなく「電力あたりの効率」という指標が今後の調達判断の軸になっていくこと、の3つだ。今すぐ現場の実装が変わるニュースではないが、2〜3年先のクラウドAI予算計画を立てる際の前提情報として押さえておきたい。 筆者の見解 Nvidia一強からの脱却を各社が急ぐのは、極めて筋の通った動きだと見ている。GPU調達の不確実性とコストを考えれば、電力効率を自社チップで作り込むのは「道のド真ん中」の合理的な選択だ。MicrosoftもMaia／Cobaltで同じ方向に進んでおり、応援する立場から見れば、ここは正面から勝負できる領域のはずだ。ハイパースケーラー同士の自社シリコン競争が本格化すれば、最終的にコスト効率という形でユーザー側にも恩恵が及ぶ。1つの指標（トークン単価）だけを追いかけて一喜一憂するのではなく、数年先を見据えたインフラ戦略として各社の動きを淡々と観察していきたい。 出典: この記事は Google is working on a new AI chip designed to make Gemini more efficient の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは、著作権を侵害されたとして著者・出版社から起こされていた集団訴訟について、15億ドル（当時のレートで約2250億円）の和解を正式に成立させた。2026年7月20日、米連邦地裁（カリフォルニア州北部地区）のAraceli Martinez-Olguin判事が最終承認を下したと、ロイター通信が報じた。米著作権訴訟の歴史上、最大級の和解金額とされる。 15億ドル、対象は推定50万点の著作物 この訴訟は、Anthropicが対話型AI「Claude」の学習用データとして、著者・出版社に無断で書籍を利用したとして提起されたものだ。和解案は前任のWilliam Alsup判事の下で2025年に予備承認されており、Alsup判事の退任を受けて後任のMartinez-Olguin判事が今回、正式に承認した。 支払い対象は推定50万点の著作物で、1点あたり3000ドルが著者・出版社に分配される見込みだ。 「フェアユース」認定と「違法入手」は別問題 今回の訴訟で注目されたのは、Alsup判事が示した法的判断だ。同判事は「著作権のある文章でAIモデルを学習させること自体はフェアユース（公正利用）にあたる」とし、この論点ではAnthropic側の主張を認めた。AI業界にとっては重要な追い風となる判断だった。 一方で、学習データの入手方法は別問題として切り分けられた。Anthropicは書籍データを、正規に購入・スキャンしたものと、Library GenesisやPirate Library Mirrorといった海賊版サイトから無断でダウンロードしたものの2系統で調達していた。Alsup判事は後者について「それ自体が違法」と認定し、この点は陪審裁判に進む可能性があった。Anthropicは陪審裁判のリスクと、その場合に想定される賠償額の大きさを避けるため、和解を選んだ経緯がある。 重要なのは、この和解が個別事案の決着にすぎないという点だ。地裁レベルの判断である上、和解によって控訴審に進むこともないため、業界全体を拘束する判例にはならない。実際、Google、Meta、Midjourney、OpenAIなどを相手取った同種の訴訟は各地の裁判所で継続中で、先週にはHachetteやElsevierなどの出版社・著者グループが、Geminiの学習データを巡ってGoogleを新たに提訴したばかりだ。 なぜこれが重要か — 日本のIT現場への影響 日本の著作権法30条の4は、一定の条件下でAI学習のための著作物利用を比較的広く認めており、米国の「個別事案ごとのフェアユース判断」とは制度設計が異なる。そのため今回の和解が日本の法制度に直接影響するわけではない。 ただし、日本企業が業務で使う生成AIサービスの多くは米国発だ。学習データの入手経路を巡る法的リスクは、サービス提供企業の事業継続性や価格戦略に跳ね返ってくる話であり、日本の利用者にとっても無関係ではない。AIベンダーを選ぶ際に、学習データの出所や知財リスクへの対応方針を確認することは、今後さらに重要な選定基準になっていくはずだ。 実務での活用ポイント 契約書の知財補償条項を確認する: エンタープライズ向けAIサービスの契約には、学習データに起因する著作権侵害の責任を提供元が負う「知財補償（IP indemnification）」条項が含まれることが多い。この有無と範囲をIT管理者・法務部門であらかじめ確認しておく 利用ガイドラインに組み込む: 社内の生成AI利用ガイドラインに「ライセンス方針が明確なサービスを使う」という基準を明記する 個々の訴訟の帰趨を追いかけすぎない: 業界全体の法的決着にはまだ時間がかかる。エンジニア個人としては、契約で守られたエンタープライズ版のサービスを選んで使うという原則さえ守っていれば、過度に神経質になる必要はない 筆者の見解 Anthropicが陪審裁判のリスクを取らず早期に和解した判断は、ビジネスとして妥当だったと思う。2250億円規模の和解金は決して軽くないが、不確実な陪審評決を待つよりも、早期に法的リスクを刈り取って本業に集中する方が合理的だ。 一方で、この和解によって「AIの学習データを巡る著作権問題」が解決したわけではないことは、きちんと押さえておきたい。Google、Meta、OpenAIなど各社の類似訴訟は今も続いており、業界全体としての法的な着地点はまだ見えていない。 こうしたニュースに触れると、企業側は「著作権が怖いから生成AIの導入は控えよう」という判断に流れがちだ。しかしそれは順序が逆だと思う。大事なのは導入を止めることではなく、ライセンス契約や補償条項が明確なエンタープライズ版のサービスを選び、安全に使える仕組みを社内に作ることだ。日本企業のAIガバナンスも、「使うかどうか」を議論する段階から、「どう安全に、正しい契約の下で使うか」を設計する段階に進むべき時期に来ている。 出典: この記事は Anthropic’s landmark $1.5B copyright settlement is approved の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Bunとは何か、そしてなぜClaude Codeに関係するのか Anthropicのコーディングエージェント「Claude Code」は、単体で動くネイティブバイナリとして配布されている。この中には、JavaScriptランタイム兼バンドラーである「Bun」がまるごと同梱されている。Bunは開発者Jarred Sumner氏が生み出した高速ランタイムで、これまでZig言語で書かれてきた。そのSumner氏本人が「BunをRustで書き直した」と明かし、しかも「Claude Code v2.1.181（2026年6月17日リリース）以降はすでにこのRust版を使っている。Linuxでの起動が10%速くなったが、それ以外はほとんど誰も気づかなかった。地味であることは良いことだ」と投稿した。 stringsコマンドが暴いた証拠 この主張を検証したのが著名開発者Simon Willison氏だ。手元のclaudeバイナリに対しUnixのstringsコマンドを使い、次の2点を確認している。 strings ~/.local/bin/claude | grep -m1 'Bun v1' を実行すると「Bun v1.4.0」が出力される。公開されているBunの最新版はv1.3.14（5月12日リリース）であり、v1.4.0はまだ正式リリースされていないプレビュー版のバージョン番号だった（その後、Bunのcanaryチャンネルbun upgrade --canaryとして公開されたことが判明）。 strings ... | grep -Eo 'src/[[:alnum:]_./-]+\.rs' を実行すると、src/bundler/bundle_v2.rsなど563個のRustソースファイルパスがバイナリ内から見つかった。旧来のZig実装ならこの痕跡は残らない。 さらに別の開発者は、BUN_OPTIONS="--preload=..." claude --version という形でBunに直接バージョンを出力させる手法も示し、同じく1.4.0であることを裏付けた。 静かな入れ替えが意味すること 重要なのは、Anthropicがバージョン発表もなく、しかもBun側でもまだ正式リリース前のcanaryビルドを、何百万台もの端末で動くClaude Codeの本番バイナリに組み込んでいた点だ。API互換性が保たれていれば、内部実装は黙って刷新してよい、というインフラ運用の思想がここに表れている。 実務への影響 日本のエンジニアやIT管理者にとっても示唆がある。第一に、いま配布されるCLIツールは「ただのスクリプト」ではなく、ランタイムごと同梱したネイティブバイナリであることが増えている。stringsのような古典的なUnixコマンドは、依存関係やライセンス、意図しない情報の混入をチェックする手段として今も有効だ。第二に、自社で配布するバイナリについても、想定外の文字列（デバッグ情報、内部パス、まれに秘密情報）が埋め込まれていないか、同じ手法で棚卸ししてみる価値がある。第三に、大手AIベンダーであっても基盤ランタイムのcanaryビルドを先行投入する運用は珍しくなく、破壊的変更を伴わない基盤刷新は積極的に取り込む文化がある、という一例として参考になる。 筆者の見解 今回面白いのは、新機能の話ではなく「中身がいつの間にか差し替わっていた」という運用姿勢そのものだ。派手な発表やメジャーバージョンアップを打たず、互換性を保ったまま土台を強くしていくやり方は、地味だが学びが多い。筆者は日頃からClaude Codeを実務で使い倒しているが、内部実装の細部を逐一追いかけるよりも、実際に使って成果を出すことのほうがずっと重要だと考えている。その意味で、今回の話は「気づかれないくらい自然に速くなっていた」という結果こそが評価に値する。 もう一つ心に留めておきたいのは、Simon Willison氏の姿勢だ。ベンダーの発表を鵜呑みにせず、自分の手元のバイナリを実際にstringsで覗いて検証する。この「自分で確かめる」態度は、AIツールが次々と登場する今の時代にこそエンジニアに求められる基本動作だと思う。 出典: この記事は Claude Code uses Bun written in Rust now の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Code、OpenAI Codex、Google Gemini CLIといった主要なAIコーディングエージェント、さらにClaude in ChromeやGoogle Antigravity、Nanobrowserといったブラウザ操作エージェントに、ソウル大学とイリノイ大学アーバナ・シャンペーン校の研究チームが共通の弱点を発見した。論文「Agent Data Injection Attacks are Realistic Threats to AI Agents」で報告された新しい攻撃手法「エージェント・データ・インジェクション(ADI)」は、エージェントに読み込ませる外部データそのものを武器に変える。 「指示への割り込み」ではなく「データへのなりすまし」 これまでAIエージェントのセキュリティ研究は、主に「間接プロンプトインジェクション(IPI)」を対象にしてきた。攻撃者が仕込んだ文章を、エージェントが「指示」だと誤認識してしまうタイプの攻撃だ。モデルの堅牢化、入力ガードレール、Dual-LLM構成など、多くの対策が「指示」と「データ」を分離することで防御してきた。 今回のADIは、その防御の隙間を突く。攻撃者が細工したデータを、エージェントが「指示」としてではなく「信頼できるはずのデータ」だと誤認させる。たとえばファイルの出所を示すメタデータ、Webページ上のUI要素を識別するID、ツール呼び出しの実行結果のフォーマットなどになりすまし、エージェントに意図しない操作を実行させる。指示と分離すること自体は正しく機能していても、そのデータの真正性を検証していないために突破されてしまう。 実証された被害:任意クリックからリモートコード実行まで 論文では、Claude in Chrome、Google Antigravity、Nanobrowserに対する「任意クリック攻撃」(意図しない要素を勝手にクリックさせる)、そしてClaude Code、Codex、Gemini CLIに対する「リモートコード実行」や「サプライチェーン攻撃」を実際に成立させたと報告している。特定ベンダー1社の実装ミスではなく、業界の主要なエージェント設計に共通して存在する構造的な欠陥だという点が重い。研究チームは、信頼データと非信頼データを分離するという基本原則を、現行のAIエージェントがまだ実装できていないと結論づけている。 実務への影響 日本国内でもClaude Code、Codex、Gemini CLIといった自律型コーディングエージェントの導入が急速に進んでいる。今回の研究が突きつけるのは、「エージェントが読み込む外部データ(Webページ、リポジトリのREADME、ツールの実行結果など)はすべて汚染されている可能性がある」という前提に立つ必要があるということだ。実務上のポイントは3つ。 エージェントに与えるツール・MCP接続・実行権限を必要最小限に絞る。過剰な権限は攻撃の踏み台になる 外部リポジトリやWebコンテンツを扱わせるタスクでは、コード実行やパッケージインストールを自動承認しない設定にする 各ベンダーからの本件に関するパッチ・緩和策のアナウンスを継続的に確認する 筆者の見解 今回の論文が重いのは、Claude Code、Codex、Gemini CLIという主要な陣営がほぼ同列に脆弱性を指摘されている点だ。特定ベンダーの実装が甘かったという話ではなく、「信頼データと非信頼データを分離する」という、伝統的なシステムセキュリティの世界ではSQLインジェクション対策などを通じて何十年も前に確立されてきた原則を、AIエージェントの世界がまだ実装できていないという構造的な指摘だと受け止めている。 筆者はかねてAIエージェントについて、人間の承認待ちを減らして自律的に動く設計こそが本質的な価値を生むという立場を取ってきた。だが自律性を上げるほど、今回のようにエージェントが騙されて実行してしまう操作の被害も大きくなる。ここで大事なのは「危ないから使うな」という禁止に走ることではない。ユーザーが安心して自律的に使い倒せるように、ベンダー側が信頼境界をきちんと設計し直すことだ。こうした研究が公開され、業界全体で対策が進むのは歓迎したい動きで、各社の次のアップデートで具体的にどう手当てされるかを注視していきたい。 出典: この記事は Agent Data Injection Attacks are Realistic Threats to AI Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の数学者レヴェント・アルポージ（Levent Alpoge）氏は2026年7月20日、X（旧Twitter）で、Anthropicの生成AIモデル「Claude Fable」を使って、1939年の提起から87年間誰も解けなかった数学の超難問「ヤコビアン予想（Jacobian Conjecture）」に対する反例を発見したと投稿した。 「ヤコビアン予想」とは何か ヤコビアン予想は、ドイツの数学者オットー=ハインリッヒ・ケラーが1939年に提起した予想だ。n変数の複素多項式写像 C^n→C^n について、そのヤコビ行列式（各成分の偏微分から作る行列の行列式）がどの点でも0にならない定数であれば、その写像は多項式で書ける逆写像を持つ、つまり全単射であるはずだ、という主張である。 主張自体はシンプルだが、証明も反例もこれまで一切見つからず、著名な数学者が挑んでは跳ね返されてきたことから「クランク（トンデモ）の墓場」とすら呼ばれてきた難問だ。双子素数予想への貢献で知られる張益唐（Yitang Zhang）氏も博士論文でこの問題に取り組み、証明に欠陥が見つかって学位取得が難航したという逸話があり、今回のスレッドでもリプライで言及されている。 ワールドカップ決勝の合間に見つかった反例 アルポージ氏が投稿した反例は、3変数の多項式写像で、ヤコビ行列式がどの点でも-2という定数でありながら、(0, 0, -1/4)、(1, -3/2, 13/2)、(-1, 3/2, 13/2) という3つの異なる点をすべて同じ点 (-1/4, 0, 0) に写してしまう、つまり単射ではないというものだ。予想が正しければ「定数かつ非ゼロのヤコビ行列式を持つ多項式写像は全単射」のはずなので、この反例が正しければ予想そのものが崩れることになる。 氏はこの計算をClaude Fableが「ワールドカップ決勝戦の間に」担ったと明かしており、人間がサッカー観戦をしている間にAIが自律的に計算を進めていたという点が話題を呼んでいる。 現時点では「検証中」というのが実際のところ 投稿ではヤコビ行列式の計算や各点での写像の値をWolfram Alphaで裏付けており、追跡可能な形で示されてはいる。X上のAI「Grok」もこのスレッドに反応し「有効な反例だ」と回答しているが、これはAIによる即答であって、数学コミュニティによる正式な査読ではない。リプライでは、この反例が関連するディクスミア予想（Dixmier Conjecture）やポアソン予想（Poisson Conjecture）の反証にもつながるのではという指摘も出ており、影響範囲の精査はこれからだ。 実務への影響 日本のエンジニアやIT管理者の日常業務に直結する話ではないが、示唆はある。 「答えの正しさを機械的に検証しやすい」領域（数値計算、組み合わせ探索、証明の妥当性チェックなど）では、AIエージェントに自律的な反復探索を任せる余地が着実に広がっている。社内に眠っている検証可能な計算タスクを、AIエージェントに predicate として渡せないか棚卸ししてみる価値がある。 一方で、この件はAIの出力と専門家コミュニティによる検証の間にはまだ距離があることも示している。別のAI（Grok）の即答は査読の代わりにはならない。業務でAIの成果を使う際も、重要な判断ほど独立した検証プロセスを仕組みとして挟んでおくべきだ。 人間はゴール設定と検証手段の用意に徹し、実行そのものはAIエージェントに委ねるという役割分担が、数学の最前線でも実証されつつある点は、開発・検証プロセスの設計を考える上でのヒントになる。 筆者の見解 真偽はさておき、この一件で一番面白いのは「人間がワールドカップ決勝を見ている間にAIが勝手に計算を進めていた」という構図そのものだ。逐一確認や承認を求められるアシスタント型のAIではなく、目的だけ渡して離れても仕事を進めてくれる自律型のエージェントが、こうした専門的な計算領域でも実力を発揮し始めている。この方向性こそ今のAI活用で一番注目すべきところだと感じる。 Anthropicのモデルがこうした形で数学研究の現場に持ち込まれ、話題になっていること自体は素直に興味深い。ただし現時点ではあくまで未査読のX投稿であり、Wolfram Alphaでの部分検証やGrokの回答があるとはいえ、数学的に確定した結果ではない。今後、専門家コミュニティによる正式な検証を経て初めて「ヤコビアン予想は解決された」と言える段階に進む。AIが出した派手な結果に飛びつく前に、誰がどう裏取りしたのかを見極める姿勢は、数学に限らず業務でAIを使うときにも変わらず大事にしたい。 出典: この記事は Claude Fable produced a counterexample to the Jacobian Conjecture の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国のITコンサルタント、Nik Suresh氏が、自身がコンサルティングで関わる大企業の内部で目撃した「AI狂騒（AI mania）」の実態を赤裸々に綴ったブログ記事が話題になっている。著名な開発者ブロガーのSimon Willison氏がこの記事をリンクブログで紹介し、Hacker Newsでも大きな議論を呼んだ。登場するのは、ChatGPTすら使ったことのない役員が数千億円規模の会社のAI戦略を丸ごと主導する話や、社内の「トークン消費量リーダーボード」に怯えてコードを無意味に書き換え続ける技術者の話だ。 ChatGPTを触ったことのない役員が「AI戦略」を書く Suresh氏が明かした最も強烈な事例は、年商20億ドル（約3000億円）超の企業で、ChatGPTはおろかどんなAIツールも一度も使ったことがないと自ら認めた役員が、その直後に会社全体の技術戦略──しかも中身は丸ごとAI中心──を発表していたというものだ。使ったことのない道具を前提に会社の未来を賭ける計画を作る。笑い話のようだが、これが複数の大企業で実際に起きているとSuresh氏は指摘する。 「トークンリーダーボード」のためにGoをZigへ書き換える技術者 もう一つの象徴的な逸話が、「トークン消費量リーダーボード」を導入しているある企業のエンジニアの告白だ。「クビにならないために、Goのリポジトリをまるごとコピーして、別の作業をしている間にAIにZigへの丸ごと書き換えを指示している」という。生産性の実態ではなく、AIにどれだけトークンを使わせたかという見せかけの数字が評価基準になった結果、技術的に何の意味もない書き換え作業が「実績」として生み出されている。 なぜ誰も「それは無理です」と言えないのか Suresh氏が特に興味深いと語るのが、AIベンダー側の役員へのインタビューだ。顧客企業の役員が「生産性が100倍になった」といった非現実的な数字を吹聴しているとき、ベンダー側の役員がその場で「それは非現実的だ」と正直に指摘すると、顧客役員の面子を潰す「攻撃」と受け取られ、契約解除につながりかねない。自社の本質的な事業に関係のない話で契約を切られれば、指摘した役員自身が解雇される可能性すらある。損得抜きに正直な評価を口にできない構造が、AI狂騒を加速させているというわけだ。 実務への影響 日本のIT現場にとっても他人事ではない話だ。生成AI活用を測る「AI活用度」という指標そのものは方向性として正しい。しかし測り方を間違えると、この記事のトークンリーダーボードのように目的と手段が入れ替わる。「AIをどれだけ使ったか」の代理指標としてトークン消費量や利用回数だけを追うと、社員は評価のために無意味な作業を作り出してしまう。IT管理者は、実際の業務改善や成果に紐づいた指標を設計し、数字だけがひとり歩きしないよう注意する必要がある。また、経営層がツールを実際に使わずに戦略だけを語る状態も危険信号だ。技術戦略を作る立場の人間ほど、自分の手でAIエージェントを日常的に使い、失敗も含めて肌感覚を持っておくべきだろう。 筆者の見解 このエピソード集を読んで真っ先に思ったのは、「AI活用度を測ろうとする発想自体は間違っていない」ということだ。企業が生成AIをどれだけ効果的に使いこなしているかを可視化する試みは、方向性としては筋がいい。問題は、その物差しが「トークン消費量」のような安直な数字にすり替わった瞬間に起きる。Zigへの書き換えの逸話は、まさに人間が変なKPIにぶら下がって数字をハックし始める典型例で、経営がAIを本気で導入したいなら、こういう副作用込みで指標設計をしなければならない。 一方で、「役員がAIを一度も使わずに戦略だけ語る」という話には、もっと根深い問題を感じる。今の時代、意思決定をする立場の人間が生成AIを積極的に使わないこと自体が、もう相当まずい状態だと思っている。使ったことがないから的外れな戦略しか作れないし、現場の技術者がその歪みのしわ寄せを受ける。かといって「使わなくていい」を強調しすぎるのも間違いで、必要なのは「どう使えば効果的か」を組織としてきちんと定義し、支援する仕組みだ。禁止でも放任でもなく、正直な評価と地に足のついた指標を伴った活用を経営から現場まで一貫して作れるかどうか。この記事に出てくる笑い話のような光景は、日本の会社でも十分に起こり得る話だと思っている。 出典: この記事は AI Mania Is Eviscerating Global Decision-Making の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

生成AIコーディングツールの普及以降、Q&AサイトStack Overflowへの質問投稿数がどれだけ落ち込んだかを示すグラフが公開され、Hacker Newsで407ポイント・495件のコメントを集める大きな話題になった。作成に使われたのはStack Exchange公式の「Stack Exchange Data Explorer（SEDE）」。誰でもStack Overflowの公開データセットに対して自分でSQLクエリを書き、結果をグラフとして可視化できる無料ツールだ。 「集合知の広場」で何が起きているのか 公開されたクエリは、月別・年別の新規質問数の推移を折れ線グラフにしたものだ。Stack Overflowの質問数は2014年前後をピークにすでに緩やかな減少局面に入っていたが、2022年11月のChatGPT登場、そして2023年以降のGitHub Copilotなどコーディング支援ツールの普及を境に、下落カーブが明らかに急になっている——これが多くの開発者の共感と危機感を呼んだ理由だ。SEDEは誰でも同じ公開データに対して検証クエリを書けるため、「本当にそうなのか」を各自が手元で再現できる点も拡散を後押しした。 なぜ質問数が減ったのか 理由は単純だ。以前は「検索してStack Overflowの回答を探す」のが定番の手順だったが、今はIDEやターミナルに常駐する生成AIに直接聞けば、その場でコードベースの文脈を踏まえた回答が返ってくる。検索し、複数の回答を読み比べ、自分のコードに合わせて書き換える——という一連の作業そのものが不要になりつつある。Stack Overflow側もこの傾向を認めており、コミュニティ機能に生成AIを統合する「OverflowAI」を2023年に発表したほか、2024年にはGoogleやOpenAIとデータライセンス契約を結び、自社の質問・回答データをAIモデルの学習・参照用に提供する道を選んだ。皮肉なことに、Stack Overflowの膨大な蓄積データこそが、今その存在意義を脅かす生成AIを育てた「教材」でもある。 実務への影響 この変化は日本のエンジニアやIT管理者にとっても他人事ではない。 新人教育のやり方を見直す: 以前は「似た質問と回答」を読み比べる過程自体が学びになっていた。AIが一発で正解に近いコードを出す今、若手には「なぜその実装を選んだのか」を説明させる場を意識的に別途用意する必要がある。 社内ナレッジをAIが参照できる形に整える: 公開Q&Aの新規投稿が先細るなら、社内Wikiや過去の障害対応、設計判断の記録をAIエージェントが読み込める形で残しておくことの価値がこれまで以上に上がる。 「情報の鮮度」への依存を見直す: 公開コミュニティの投稿が減れば、AIの学習データも徐々に古くなっていく。特定バージョンの挙動や最新API仕様は、公式ドキュメントの確認とAIエージェントに実際にコードを書かせて検証する運用を組み合わせるのが現実的だ。 筆者の見解 このグラフを見て「Stack Overflowが可哀想」で終わらせるのは早計だと思う。開発者が検索して回答を探す手間そのものが要らなくなったのは、目的さえ伝えれば自律的にタスクをこなすAIエージェントへとパラダイムが移行している証拠であり、人間の認知負荷を減らすというAIエージェント本来の価値がそのまま表れた結果だ。「質問して、待って、回答を評価する」という工程が減ったこと自体は歓迎していい変化だと考えている。 一方で気になるのはこの先だ。公開コミュニティへの新規投稿が細っていけば、次世代のAIモデルが参照できる「生きた知識」も先細っていく。Stack Overflow社がAI企業とデータ提供契約を結んだのは、皮肉ではあるが理にかなった生き残り策だろう。ただしこれは一企業の問題にとどまらず、エンジニアコミュニティ全体が知見を公開・共有する動機をどう保つかという、もう一段大きな課題でもある。 現場のエンジニアに伝えたいのは、こうした構造変化を追いかけて一喜一憂するより、今使えるAIエージェントを実際に手を動かして使い倒し、そこで得た経験を自分の武器にする方が確実だということだ。Stack Overflowの衰退を嘆く時間があるなら、その分をAIとの実践に充てた方がいい。開発の現場は、それくらい後戻りしないところまで来ている。 出典: この記事は What AI did to stackoverflow in a graph の内容をもとに、筆者の見解を加えて独自に執筆したものです。

元OpenAI CTOのMira Murati氏が創業したThinking Machines Labが、同社として初めてとなる自社学習のAIモデル「Inkling」を公開した。総パラメータ975B（活性化41B）のMixture-of-Experts(MoE)構成で、企業が自由に商用利用・改変できるApache 2.0ライセンスのオープンウェイトモデルとして重み一式がダウンロード可能になっている。 Inklingの中身 Inklingはテキスト・画像・音声・動画を横断的に扱うネイティブなマルチモーダルモデルで、45兆トークン規模のデータで事前学習されている。コンテキストウィンドウは最大100万トークンに対応し、コーディング能力を測るSWE-bench Verifiedでは77.6%を記録した。MoE構成により、975Bという総パラメータ数に対して推論時に実際に使う「活性化パラメータ」は41Bにとどまり、コストと性能のバランスを取っている。同時に、より軽量な「Inkling-Small」（活性化12B）もプレビュー公開され、低コスト・低レイテンシ用途向けの選択肢も用意された。 同社はInklingを、自社が提供するファインチューニング基盤「Tinker」とセットで使うことを想定している。Tinkerのコンソールには、Inklingと直接対話しながら挙動を確かめられる「Inkling Playground」も追加された。 公開に合わせて公開されたデモも興味深い。Thinking Machines LabはInkling自身に「アルファベットのeを一切使わずに応答するモデル」へ自分をファインチューニングするタスクを与えた。Inklingは学習データと評価基準を自分で書き、Tinker上で学習ジョブを実行し、結果を評価した上で、更新後の重みへ自ら切り替えるところまでを一気通貫でこなした。 実務への影響 Apache 2.0での重み公開は、企業がAPI従量課金やベンダーロックインを避けて自社環境でモデルを保有・運用できることを意味する。Inkling自体は「現時点で最強のモデル」ではないと開発元も明言しているが、マルチモーダル対応・効率的な推論・Tinkerによるファインチューニング環境がセットで揃っている点は、特定ドメイン向けにモデルを育てたい企業にとって現実的な選択肢になる。社内文書やコールセンター音声など複数モダリティを扱う用途で、自社データによるチューニングを検討している担当者は候補に入れておく価値がある。軽量なInkling-Smallを使えば、エッジ環境やレイテンシ要件の厳しい用途にも展開しやすい。 筆者の見解 モデル単体の性能競争ではなく「誰でも自分の用途に合わせて育てられる基盤」を志向した設計思想は理にかなっている。オープンな重みとファインチューニング環境をセットで提供する戦略は、特定ドメインに特化させたい企業にとって参入障壁を下げる。 個人的にもっとも注目したいのは、Inklingが自分自身のファインチューニングジョブを書き、実行し、評価した上で新しい重みへ切り替えるところまでを自律的にこなしたデモだ。人間が逐一確認・承認するのではなく、目的だけを渡せば自律的にタスクを完遂するエージェント像がここでも体現されている。こうした「自律的に判断・実行・検証のループを回す」設計こそ、いま最も注目すべきAIエージェントの方向性だと考えている。 新しいモデルが出るたびに全部を追いかける必要はない。ただ、Tinkerのように自社データで独自モデルを育てる基盤が整ってきたこと自体は、実際に手を動かして試す価値のある動きだ。まずは今使っているツールを使い倒すことを優先しつつ、こうした基盤の進化は押さえておきたい。 出典: この記事は Inkling: Our open-weights model の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Hugging Faceは、論文の調査からデータセット選定、コードの実行、モデルの学習・評価までを自律的にこなすオープンソースのAIエージェント「ML Intern」を公開した。同社が示した初期ベンチマークでは、科学的推論のタスクでAnthropicのClaude Codeを、医療分野の評価タスクでOpenAIのCodexをそれぞれ上回ったとされている。CLIおよびモバイル・デスクトップ向けWebアプリとして、今日から利用可能だ。 論文を読み、GPUジョブを回す自律エージェント ML InternはHugging FaceのAIエージェントチームが開発した。arXivやhf.co/papersから論文を探し、引用グラフをたどって関連研究を掘り下げ、データセットを取得・整形し、ローカルにGPUがなければHugging Face Jobs上で学習ジョブを起動する。最大300回のイテレーションを回すエージェンティックループに、会話履歴を自動圧縮するコンテキストマネージャー、ドキュメント・データセット・論文検索やGitHubコード検索を呼び出すツールルーター、サンドボックス実行環境を備える。CLIはuv経由でインストールでき、推論プロバイダーは任意のモデルIDを指定できるが、デフォルト設定はAnthropicのClaudeモデルを指す。 「Claude Codeを上回った」の中身 開発者のAksel Joonas Reedi氏によると、GPQA(科学分野の推論ベンチマーク)ではNVIDIAの研究論文を引用検索で見つけ出し、Qwen3-1.7Bに12回のファインチューニングを実行、10時間足らずでスコアを10%から32%まで押し上げ「Claude Codeの最高スコア22.99%」を上回ったという。医療分野のHealthBenchでは、既存データセットの質が低いと判断して1,100件の合成対話データを自ら生成・50倍にアップサンプリングして学習し、Codexを60%上回ったとしている。数学タスクでもGRPOの学習スクリプトを書いてA100 GPU上で実行し、報酬が崩壊した際には原因を分析して学習をやり直したという。ただしこれは、汎用コーディングエージェントであるClaude Codeの素の回答精度と、ML Intern自身が目的特化でファインチューニングした小型モデルのスコアを比べたものであり、単純な「エージェント対エージェント」の比較ではない点には注意が要る。Hugging Faceは早期利用者向けにGPUリソースとAnthropicクレジットを合計1,000ドル分提供するとしている。 実務への影響 ML Internは、論文調査からデータ整備・学習・評価までの研究ループをHugging Face Jobs・Spaces・Datasetsといった同社エコシステム上で自動化する。すでにHugging Faceのスタックを使うチームであれば、独自データでの検証実験やPoCを低コストで回す手段として試す価値がある。一方でHugging Face自身が「ベンチマーク外の乱雑な実データ、とりわけデータ品質・同意・ライセンスが絡む領域でどこまで自律性が通用するかは未知数」と認めている。本番の研究・開発ワークフローに組み込む前に、自社データとタスクで実際に動かして再現性を確認する検証フェーズは省略できない。 筆者の見解 ML Internの技術的な核は「Claude Codeに勝った」という見出しよりも、最大300回のループの中で失敗(報酬の崩壊など)を自分で検知し、原因を分析してやり直す自己修正の設計にある。指示待ちで人間の承認を求め続けるのではなく、目的だけを渡せば自律的にタスクをやり切るエージェントの方向性そのもので、今後さらに重要になっていくテーマだと考えている。 ただしベンチマークの見出し数字は割り引いて読むべきだ。特化ファインチューニングした小型モデルの成績と、汎用エージェントの素の回答精度を並べて「上回った」と言うのは、ベンダーブログにありがちな見せ方であり、実運用での再現性とは別問題だ。興味深いのは、Claude Codeを引き合いに出しながらML Intern自体の推論モデルのデフォルトがAnthropicのClaudeを指している点で、エコシステムの土台としてのClaudeモデルの存在感を改めて示している。 日本のエンジニアにとって大事なのは、こうした発表を追いかけ続けることではなく、1,000ドルのクレジットのような機会を使って実際に自分の手を動かし、自律ループ型エージェントが自分たちの業務でどこまで使えるかを確かめることだろう。 出典: この記事は Hugging Face launches ML Intern, AI agent that beats Claude Code on reasoning の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フランスのAI企業Mistral AIは、単眼のRGBカメラだけを使ってロボットに複雑な環境を自律的に移動させる新モデル「Robostral Navigate」を発表した。80億パラメータのこのモデルは、深度センサーやLiDAR、複数カメラを一切使わず、「ロビーを出て廊下を進み、資材室に入り、2番目の棚の前で止まって」といった自然言語の指示だけでロボットを目的地まで導く。同社によれば、これはMistral AIにとって初の「身体性ナビゲーション（embodied navigation）」モデルとなる。 技術の中身：pointingベースのナビゲーション Robostral Navigateの核は「pointing」と呼ばれる手法だ。カメラが今見ている画像の中で「次にどの座標へ、どの向きで移動すべきか」を直接予測する。距離や角度を数値で指示する従来方式と違い、画像上の座標で目的地を指し示すため、カメラの機種やレンズの違い、ロボットのサイズ差に対してロバスト（頑健）に動作する。目的地が視野の外にある場合は「前に2m、左に1.5m移動して25度左に回転」のようなローカル座標系の移動指示にフォールバックする仕組みも備える。 モデルはMistral独自の物体検出・位置特定用VLM（Vision-Language Model）をベースに初期化されており、既存のオープンソースVLMには依存せず完全に自社開発された。学習データはシミュレーション環境で生成した約240万本の移動軌跡（35万シーン分）で、実機データを使わずに構築している点も特徴だ。 評価指標であるR2R-CE（Room-to-Room in Continuous Environments、指示追従型ナビゲーションの標準ベンチマーク）の未知環境評価では成功率76.6%を記録。単眼カメラのみの既存最良手法を9.7ポイント、深度センサーや複数カメラを使う手法さえも4.5ポイント上回った。車輪型・脚型・飛行型のロボットを横断して汎用化できる設計になっている点も、実運用を意識した設計だとわかる。 なぜこれが重要か これまでロボットの自律ナビゲーションは、LiDARや深度カメラ、複数センサーの組み合わせが「安全な実装」の前提とされてきた。センサー構成が重厚になるほど導入コストとメンテナンスの手間が増え、中小規模の物流拠点や店舗では採用のハードルが高かった。Robostral Navigateが示したのは、単眼RGBカメラという最も安価で枯れたセンサーだけでも、既存の高コスト構成を上回る精度が出せるという事実だ。ハードウェア要件が下がれば、ロボット導入の初期投資と運用コストの両方が下がる。製造業・物流・ホスピタリティ業界での自律移動ロボット（AMR）普及にとって、これは無視できないインパクトを持つ。 実務での活用ポイント 日本のIT管理者・エンジニアにとっての着眼点は次の3つだ。第一に、既存の監視カメラや汎用Webカメラ相当の安価なセンサーで実証実験を組める可能性がある点。深度センサーの調達・キャリブレーションという参入障壁が下がる。第二に、pointingベースの指示方式は「距離・角度をミリ単位で指定する」旧来のロボット制御と発想が異なるため、既存の自動化システムに組み込む際はAPI仕様やライセンス条件を事前に確認する必要がある。第三に、シミュレーションのみで学習したモデルが実環境の未知の障害物にどこまで頑健かは、自社の現場環境で実際に検証してみるのが最も早い。ベンチマーク数値だけで判断せず、まずは小規模な実証で挙動を確かめることをお勧めしたい。 筆者の見解 今回のRobostral Navigateで筆者が注目したいのは、性能数値そのものより「目的を伝えれば、あとは自律的にタスクをやり切る」という設計思想だ。人間が逐一「次はここへ、次はこう曲がって」と細かく指示するのではなく、大まかな目的を与えるだけでロボットが自分で観測・判断・行動を繰り返しながらゴールへ向かう。これはソフトウェアのAIエージェントの世界で起きている変化と同じ方向を向いている。確認や承認を人間に求め続ける設計では、AIエージェントの本質的な価値は引き出せない。物理世界のロボティクスでも同じ発想が実装され始めているのは象徴的だ。 もう一つ興味深いのは、センサーを減らして単一のRGBカメラに絞り込んでもなお精度を上げてきた点だ。派手なセンサー構成を積み増すのではなく、モデル側の推論能力でシンプルな構成をカバーする方向性は、現場での導入・保守のしやすさを重視する日本のIT現場の感覚とも相性が良いはずだ。ロボティクス分野はまだ実機検証のハードルが高く、誰もが今日から触れる領域ではないが、こうした「自律的に判断し続けるAI」という設計思想自体は、ソフトウェア開発の現場で先に体感しておく価値がある。実際に手を動かして自律型のAIエージェントを使い倒す経験を積んでおくことが、この先ロボティクスも含めた自律システム全般を評価する目を養うことにつながると考えている。 出典: この記事は Mistral AI Releases Robostral Navigate: An 8B Model Enabling Robots to Navigate Complex Environments Using a Single RGB Camera の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ある日の昼下がり、ふと思った。「ターミナルを開かずに、スマホのDiscordからClaude Codeに指示を出したい」続きをみる note.com で続きを読む →