Generative-Ai

AIエージェントを本番環境に投入したいのに「セキュリティとコンプライアンスの壁」で止まっている——そんなチームにとって、見逃せない動きがあった。Microsoftがオープンソースとして「Agent Governance Toolkit」を公開した。AIエージェント向けのランタイムセキュリティ基盤であり、OWASP Agentic Top 10への全項目対応、EU AI ActやHIPAA・SOC2へのコンプライアンス自動化、サブミリ秒のポリシーエンジンなどを備える。 AIエージェントに「新しいセキュリティの考え方」が必要な理由 従来のWebアプリやAPIのセキュリティとAIエージェントのセキュリティは、根本的に異なる。エージェントは自律的に判断し、外部ツールを呼び出し、連鎖的にタスクを実行する。これは「制御できる入力と出力がある」という前提を崩す。プロンプトインジェクション、権限昇格、ツール悪用、予期しない情報漏洩——こうした脅威は従来のWAFやアクセス制御だけでは防げない。 この文脈でOWASPが整理した「Agentic Top 10」は、エージェント固有のリスク項目を定義したものだ。Agent Governance Toolkitはその全10項目を実行時に監視・制御できるポリシーエンジンを内包している。評価や設計時の話ではなく、本番稼働中のエージェントをリアルタイムで守るという点がポイントだ。 主要な機能構成 サブミリ秒ポリシーエンジン エージェントのアクション一つひとつをポリシーに照らして評価する。処理遅延をほぼゼロに抑えることで、エージェントのパフォーマンスを損なわずにガバナンスを挟める設計になっている。 暗号化エージェントID どのエージェントが何をしたかを追跡可能にするための仕組み。マルチエージェント環境で特に重要で、エージェント間の呼び出しチェーンにおいても信頼の連鎖を保証する。 コンプライアンス自動化 EU AI Act・HIPAA・SOC2といった規制要件への対応を自動化する機能を内包している。ログの取り方・監査証跡の形式・リスク分類の自動付与など、手作業では追いきれない要件をツールキット側が吸収してくれる。 主要フレームワーク統合済み LangChain、OpenAI Agents SDK、LangGraphといった現場で広く使われているフレームワークとの統合が最初から用意されている。新規実装だけでなく、既存プロジェクトへの組み込みも現実的だ。 日本の現場への影響——「止まっている案件」が動き始める可能性 日本のエンタープライズでAIエージェント導入が止まる理由のトップに来るのが、セキュリティ審査とコンプライアンス対応だ。特に金融・医療・製造の現場では「エージェントが自律的に動く」こと自体が審査を通りにくい。 Agent Governance Toolkitが提供するものは、そのままそれへの答えになり得る。「ランタイムでポリシーを強制できる」「全操作のログと監査証跡が残る」「既知のセキュリティリスク項目に正面から対応している」——これらをチェックリストに添えて社内審査に持ち込めば、議論のスタート地点が変わる。 実務上の活用ポイントをまとめる。 PoC段階からガバナンスを組み込む: 後から追加するほど難易度が上がる。Toolkitは軽量設計なので、最初から入れておくコストは低い OWASP Agentic Top 10を社内審査の語彙として使う: 「どんなリスクがあるか」を問われたときの共通言語として活用する コンプライアンス要件の自動化から着手する: 手動での証跡収集・レポート作成は現場の大きな負担。ここを自動化するだけでも導入価値は出る OSSである点を活かして先行検証する: ライセンス費用なしで動かせるため、本番移行前の検証投資が軽くなる 筆者の見解 AIエージェントが「単発の指示応答」から「自律ループで動き続ける」フェーズに移行しつつある今、ガバナンスをランタイムで担保する仕組みは確実に必要になる。Agent Governance Toolkitはそのニーズに対して技術的に真剣に向き合った成果物だと思う。 Microsoftがこれをオープンソースで出してきたことも評価したい。クローズドに囲い込むのではなく、業界標準として普及させることを優先した判断は、エコシステム全体を底上げする動き方として正しい。LangChainやLangGraphとの統合を最初から用意していることからも、特定スタックへのロックインよりも「使ってもらえる基盤」を目指しているのが伝わる。 もっとも、ツールキットが公開されたからといって組織のガバナンスが自動的に整うわけではない。ポリシーを設計するのは人間であり、何を許可し何を禁止するかの判断は現場ごとに異なる。Toolkitは「実装の手間を減らすもの」であって「判断を代行するもの」ではない。その前提を踏まえた上で使えば、エージェント導入の障壁を実質的に下げる強力な選択肢になる。 エージェントが自律的にループで動く世界が現実になりつつある今、こうしたセキュリティ基盤の整備は「後回しにしていい話」ではなくなってきた。今のうちにキャッチアップしておく価値は十分にある。 出典: この記事は Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ある人気AIコーディングツールのソースコードが先日誤って流出し、開発者コミュニティに大きな波紋を呼んだ。話題の中心は「流出」という事実よりも、コードの中身──端的に言えば、驚くほど雑に書かれていたという点だ。「バイブコーディング（vibe coding）の産物」と揶揄する声も上がったが、このツールは年間経常収益（ARR）25億ドル（約3750億円）を1年未満で達成した超ヒット製品。この矛盾が、ソフトウェア開発の根本を問い直す議論に発展している。 「ゴミコード」が数千億円規模のプロダクトを生む時代 流出コードを見た開発者たちの第一反応は「これは酷い」だった。コードレビューなら即リジェクト案件、と言う声もあった。しかし冷静に考えれば、これは単純に「雑なコードでも売れる」という話ではない。 核心にあるのは製品市場適合（Product-Market Fit / PMF）だ。このツールは開発者・デザイナー・プロダクトマネージャー・マーケター、さらにはCEOまでが熱狂して使っている。ユーザーが評価するのは「コードがどう書かれているか」ではなく「何が解決されるか」だ。 この現実は、SaaSに限った話でもない。すべてのソフトウェアに当てはまる原則だ。コードが美しいかどうかより、ユーザーが抱える課題を本当に解決できているか──それが製品の価値を決める。 品質担保の哲学が根本から変わりつつある このツールの開発者インタビューが非常に示唆に富んでいた。チームが重視しているのはオブザーバビリティ（可観測性）とセルフヒーリング（自己修復）システムだという。 従来のQAは「コードを読んでバグを見つける」だった。しかし新しいアプローチはこうだ。 「ユーザーが今ログインできない」とシステムが検知し、問題を引き起こしたコードを自動で変更・リバートする コードを文字レベルで完璧にするのではなく、変化の影響を素早く検知し自動対応できる仕組みを設計することで開発速度を最大化する発想だ。多少のリスクを受け入れながら高速でイテレーションし、問題はシステムが拾う──この設計思想が「汚いコードでも高品質なプロダクト」を実現している。 著作権という皮肉なブーメラン 今回の騒動にはもうひとつ見逃せない側面がある。著作権の問題だ。 AIのトレーニングデータと著作権をめぐる訴訟の当事者として名が上がることもある企業が、今度は自社コードの流出・無断利用を気にしなければならない立場になった。著作権という問題がAI時代においていかに複雑で双方向的かを象徴するエピソードだ。この議論はまだ決着がつかず、今後も業界全体に影響を与え続けるだろう。 実務への影響──日本のエンジニア・IT管理者へ 1. コードレビューの優先度を問い直す 全コードを完璧に仕上げることにリソースを注ぐより、本当にリスクが高い領域（セキュリティ・認証・課金処理等）に集中する配分の見直しを検討したい。全量精査は限界に来ている。 2. オブザーバビリティへの先行投資 Application InsightsやDatadogのような監視ツールを、コードを書いた後ではなく最初から設計に組み込む姿勢が重要だ。問題を素早く検知できる仕組みは、きれいなコード以上の価値を持つ。 3. 「動くものを出してループを回す」サイクルへ 日本企業は品質へのこだわりが強い。それは美徳だが、AIが書いたコードを人間が全て精査するフローはスケールしない。「自動検知→自動修正→再デプロイ」のループを設計することで、品質担保の考え方自体を更新するタイミングが来ている。 筆者の見解 「雑なコードでも大成功した」という文脈で語られがちなこの話だが、本質はそこではないと思っている。 本当のポイントは、品質担保の責任がコードの丁寧さから、システムの自律的な修復能力へと移行しつつあるという構造変化だ。コードを書く人間の腕前ではなく、そのコードが動く環境と「監視→修正→検証のループ」の設計品質が、ソフトウェアの信頼性を決める時代になりつつある。 AIエージェントが自律的に判断・実行・検証を繰り返すループを設計する──そのアーキテクチャこそが次のソフトウェア開発の主戦場だ。コードの品質論から、システムの自律性と回復力の議論へ。今回の流出騒動は、その転換点を象徴するエピソードとして記憶されるかもしれない。 日本のエンジニア文化においては「美しいコード＝良いエンジニア」という価値観が根強い。それ自体は悪くない。だが、その美学を追い求めるあまりリリースが遅れ、PMFの検証が後回しになるなら本末転倒だ。コードへのこだわりは大切にしながらも、「何を担保するための品質なのか」を今一度問い直すことが、AI時代のエンジニアに求められているのではないだろうか。 出典: この記事は The Claude Code Leak の内容をもとに、筆者の見解を加えて独自に執筆したものです。

人気HTTPライブラリ「Axios」で発生したサプライチェーン攻撃のポストモーテムが公式に公開された。今回特に注目すべきは、単なる無差別攻撃ではなく、特定のメンテナを徹底的に調査した上で仕掛けられた「個別ターゲティング型」のソーシャルエンジニアリングだった点だ。OSSエコシステムに関わるすべての開発者が知っておくべき手口が、克明に記録されている。 攻撃の全手順：精巧すぎる罠 メンテナのJason Saayman氏への攻撃は、以下のステップで実行された。 1. 企業・人物の完全クローン 攻撃者はある実在企業を模倣し、その創設者の外見までなりすまし、Saayman氏に接触してきた。単なるメール詐欺ではなく、企業ブランドと人物像を丸ごと模倣した精巧な偽装だ。 2. 説得力のある偽Slackワークスペース 本物の企業名・CIブランドを冠したSlackワークスペースに招待。LinkedInの投稿シェア、他のOSSメンテナの（おそらく偽の）プロフィールまで用意され、非常に自然な「業界コミュニティ」の雰囲気が演出されていた。 3. Microsoft TeamsでのミーティングとRAT投下 複数の「参加者」が揃ったTeamsミーティングを設定。ミーティング中に「お使いのシステムが古い」と表示され、Teamsの動作に必要なものだと思い込んでインストールしたのがRAT（Remote Access Trojan）だった。この罠で認証情報が窃取され、攻撃者はAxiosのリポジトリに悪意ある依存パッケージを公開することに成功した。 この手口はGoogleのThreat IntelligenceチームがUNC1069として文書化している攻撃グループのパターンと一致しており、暗号資産・AI関連企業を標的にした活動として知られる。 なぜこれが重要か 「ソーシャルエンジニアリングに注意」は耳タコな話だ。しかし今回の攻撃は次元が違う。本物そっくりのSlackワークスペース、実在企業の精巧なクローン、複数人が関与するTeamsミーティング——ここまでの工数と精度で特定個人を攻撃するケースは、以前は国家レベルのAPT攻撃でしか見られなかった。それが今やnpmパッケージのメンテナを標的に実行されている。 日本企業でも多数のプロダクトがAxiosに依存しており、悪意あるバージョンがインストールされた環境があればリスクは無視できない。サプライチェーンセキュリティはもはや「大企業だけの話」ではない。 実務での活用ポイント OSSメンテナ・開発者向け ミーティング直前の「ソフトウェアインストール要求」は即座に疑え。時間的プレッシャーは攻撃者が意図的に作り出すものだ 初回コンタクトで別のチャンネルへ誘導してくる相手は要注意 LinkedInや企業サイトが本物そっくりでも、それだけでは信頼の根拠にならない npmやGitHubのリリース権限は多要素認証＋物理セキュリティキーで保護する IT管理者・セキュリティ担当者向け 依存ライブラリの整合性チェック（npm audit、SBOMの活用）を自動化する 新バージョンリリース直後の依存アップデートに対し、短時間の検証フェーズを設ける 開発者向けセキュリティトレーニングにサプライチェーン攻撃の具体的シナリオを組み込む 筆者の見解 今回の攻撃でTeamsが最後の一手として使われた点は気になる。攻撃者はTeamsの普及度と「ミーティング直前に何かインストールしなければ」という心理的プレッシャーを巧みに利用している。Teamsそのものの問題ではないが、正規のインストール要求と偽物を区別しにくい現状は課題だ。Microsoftには、こうした手口を踏まえたセキュリティアドバイザリの強化や、インストール要求をより明確に識別できるUX改善を期待したい。ブランドとエコシステムを持つMicrosoftだからこそ、こういう部分で業界をリードしてほしい。 より根本的な問題として、OSSエコシステムはごく少数のメンテナが巨大なサプライチェーンの鍵を握る構造的脆弱性を抱えている。Axiosは週次ダウンロード数が数千万件規模のライブラリだ。一人のメンテナへのソーシャルエンジニアリングが世界中のシステムに影響し得る。 「禁止」や「ゼロトラスト」だけでは解決しない。メンテナが安全に作業できる環境、二人以上のレビューが必要なリリースフロー、そして実例を具体的に共有するコミュニティの文化こそが必要だ。今回Axiosチームが詳細なポストモーテムを公開したことは、その意味で業界全体への貴重な貢献だと思う。 出典: この記事は The Axios supply chain attack used individually targeted social engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの競争は、チャットボットや開発者ツールの領域を超えて、いよいよ「科学研究そのもの」へと踏み込み始めた。Anthropicが米バイオテックスタートアップ「Coefficient Bio」を約4億ドル（約590億円）の株式取引で買収したと報じられた。生成AIが創薬や生命科学の現場をどう変えるか、その輪郭が一気に鮮明になってきた。 Coefficient Bioとは何者か Coefficient Bioは、創業わずか8か月のステルス系スタートアップだ。創業者のSamuel StantonとNathan C. Freyはいずれも、大手製薬グループ・Genentechの計算創薬部門「Prescient Design」出身。AIを活用して創薬プロセスや生物学的研究の効率化を目指しており、従業員は約10名という小規模な組織だった。 その規模でこの買収額が意味することは大きい。1人当たり換算で40億円超。テクノロジー業界でも屈指の「才能への賭け」といえる。 なぜ今、創薬×AIなのか 従来の創薬プロセスは、1つの新薬を市場に出すまでに平均10〜15年、費用は2,000〜3,000億円に上るとも言われてきた。失敗率も非常に高く、製薬業界全体として効率化は長年の悲願だった。 AIは、この「効率の壁」を突破する有力な手段として注目されている。具体的には以下のような場面での活用が進んでいる： タンパク質構造予測：創薬ターゲットとなる分子の立体構造を高速に推定 候補化合物の絞り込み：膨大な化学空間から有望な分子を事前スクリーニング 臨床試験の設計最適化：過去のデータからより効率的な試験設計を提案 論文・データの大規模解析：最新の研究知見をリアルタイムで統合 Anthropicは昨年10月に「Claude for Life Sciences」を発表。科学研究者が発見を加速するためのツールとして医療・生命科学分野への本格参入を宣言していた。今回の買収はその続きであり、単なるツール提供にとどまらず、専門人材と研究ノウハウを取り込む形で垂直統合を進めている。 日本のエンジニア・IT管理者への影響 このトレンドは、日本の医療・製薬・バイオ業界のIT部門にとっても他人事ではない。 製薬・ヘルスケア企業のIT部門向け ライフサイエンス向け生成AIの導入検討サイクルが想定より早まる可能性がある。既存の研究情報システム（ELN：電子実験ノートなど）との統合シナリオを今から描いておくことが重要 データガバナンス・プライバシーの観点から、どのデータをクラウドAIに流せるかを整理する作業が急務になる エンジニア・開発者向け バイオインフォマティクス（生物情報学）とLLM（大規模言語モデル）の融合領域は、次の数年で需要が急拡大する可能性がある。PyMOL、RDKit、Biopython等の生命科学系ライブラリとAI APIの組み合わせを試しておく価値がある 「研究データを扱うエージェント設計」の知見は、製薬だけでなく食品・農業・素材など幅広い産業に転用できる 筆者の見解 今回の動きを見て思うのは、AIがいよいよ「知識労働の自動化」から「発見プロセスの自動化」へと踏み出したということだ。 単に文書を要約したり、コードを補完したりする段階は、振り返ればウォーミングアップに過ぎなかった。これからのAIエージェントに求められるのは、目的を与えれば自律的に実験を計画し、結果を検証し、次の仮説を立てて繰り返すループを回せる能力だ。創薬とはまさにそのループを何千回・何万回と繰り返す営みであり、AIとの親和性は極めて高い。 日本の視点で言えば、製薬分野では武田薬品や第一三共が海外のAIスタートアップとの連携をすでに加速している。こうした動きに「ITシステム側」がついていけるかどうかが、今後5年の競争力を左右すると思う。ライフサイエンス領域でのAI活用は「やるかやらないか」の段階をとっくに過ぎており、「どう本格展開するか」のフェーズに入りつつある。 一方で懸念もある。創薬AIには膨大な実験データと専門知識が不可欠だ。データの品質や科学的妥当性の担保なしに「AIが薬を作った」という誇大な期待が先行すると、のちに大きな反動が来る。技術の可能性を信じつつも、地道に科学的検証を積み重ねるプロセスを省略しないことが、この分野の長期的な信頼構築には欠かせない。今回の買収が、そうした誠実なアプローチの上に成り立つものであることを期待したい。 出典: この記事は Anthropic buys biotech startup Coefficient Bio in $400M deal: Reports の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIで相次ぐ幹部異動が明らかになった。急成長を続けるAI企業が「組織の成熟化」という避けられない課題に直面する中、それでも推進力を失わない体制づくりを見せた形だ。 何が起きたか Fidji Simo（AGI開発担当CEO）が社内向けメモで発表した内容によると、主な変更点は以下の通りだ。 Brad Lightcap（COO） は「特別プロジェクト（Special Projects）」担当の新役職へ移行する。複雑なディールや投資案件を横断的に担当し、Sam Altman CEOに直接報告する体制となる。COOとしての商業業務は後任に引き継がれる。 Denise Dresser は元SlackのCEOで、最近OpenAIに最高収益責任者（CRO）として参画した人物。Lightcapが担っていたビジネス面の職責を引き継ぐ。 Fidji Simo本人 は神経免疫疾患の治療のため、数週間の医療休暇に入る。「避けられる限りのことはすべて試みたが、残念ながら体が言うことを聞かない」とメモに記した。休暇期間中は共同創業者でもあるGreg Brockman会長が製品部門を管轄する。 Kate Rouch（CMO） はがんの治療に専念するため退任。体調が回復した段階で「より範囲を絞った別の役職」に復帰する予定で、新CMOの採用活動も始まる。 なぜこれが重要か OpenAIは現在、世界で約10億人のユーザーを抱えると発表している。スタートアップとして産声を上げた組織が、事実上のグローバルテクノロジー企業として機能し始めた時に起きがちな変化がまさに今起きている。 注目すべきは「特別プロジェクト」という新設ポジションの意味だ。COOという執行機能からAltman CEOの直轄ラインへのシフトは、戦略的なディールや投資判断を最高権力層に集約しようとする意図を示している。Lightcapが培ってきた幅広いビジネスネットワークを「攻め」に活用する布石と読むことができる。 Denise DresserはSlack CEO時代に大企業向けコラボレーション文化を根付かせた実績を持つ。エンタープライズ展開を本格加速させたいOpenAIにとって、彼女の起用は理にかなった人事だ。 実務への影響 — 日本のエンジニア・IT管理者にとって 短期的な影響は限定的だ。OpenAI自身が「継続性と推進力を持って実行できる体制が整っている」とコメントしており、API・製品のロードマップに直接的な変更は見込みにくい。 ただし、エンタープライズ契約を検討・交渉中の組織は以下の点を注視しておく価値がある。 商業部門の刷新：Dresserの就任により、エンタープライズ向けの価格体系やサポート体制が変化する可能性がある。現在交渉中・更新時期が近い契約は動向を確認しておきたい 製品判断権の一時的な変化：Brockmanが製品を管轄する期間中、研究寄りの判断が強まる可能性もある。新機能リリースのタイミングへの影響は軽微だろうが、念頭に置いておきたい CMO交代の余波：マーケティング・コミュニケーション戦略が一時的に不安定になりうるが、中長期の事業影響は軽微とみている 筆者の見解 この種の幹部異動は、「成長企業が成熟する証」として概ねポジティブに捉えていい。 COOを特別プロジェクト担当にシフトし、元Slack CEOを収益責任者に据える——これは、製品・研究優先のカルチャーが強かったOpenAIが、本格的にエンタープライズ市場を取りにいくという意思表示だ。Fidji SimoとKate Rouchの健康問題については、ただ回復を願うばかりだ。 気になるのは「特別プロジェクト」の具体的な中身だ。「複雑なディールや投資」という言葉は意図的に曖昧に書かれている。大型パートナーシップ、M&A、政府・規制当局との折衝——何が含まれるのかによって、OpenAIの次のフェーズが見えてくる。2026年後半の動きに注目したい。 AIの世界は今、製品そのものの優劣を競う段階から、いかに大規模に普及・定着させるかという段階に移行しつつある。今回の体制変更はその文脈で読むべきだろう。どのAIツールを活用する立場であっても、OpenAIが安定した組織として長期的に研究と製品開発を続けることは業界全体の底上げにつながる。その意味で、この組織変更が円滑に機能し、ロードマップが着実に前進することを期待している。 出典: この記事は OpenAI executive shuffle includes new role for COO Brad Lightcap to lead ‘special projects’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米ユタ州が、AIチャットボットに精神科薬の処方更新を認める1年間のパイロットプログラムを開始した。医師の関与なしにAIが臨床判断の一端を担うという前例のない試みは、医療アクセスの拡大という希望と、安全性への懸念を同時に呼び起こしている。 何が起きているのか サンフランシスコのスタートアップ「Legion Health」が開発したAIチャットボットが、ユタ州の規制当局との合意のもと、一定条件を満たす患者に対して精神科薬の処方更新を行えるようになった。月額19ドル（約2,900円）のサブスクリプションで、「迅速でシンプルな処方更新」を提供するという。 重要なのはそのスコープの狭さだ。対象となるのはフルオキセチン（プロザック）、セルトラリン（ゾロフト）、ブプロピオン（ウェルブトリン）など、すでに医師から処方されている15種類の低リスク維持薬のみ。新規処方や血液検査が必要な薬、ベンゾジアゼピン系薬（抗不安薬）、抗精神病薬、リチウム（双極性障害の標準治療薬）は対象外だ。 患者側の条件も厳格で、「安定している」と判断された既存患者のみが対象。直近1年以内に入院歴があったり、用量変更があった場合は除外される。10回の更新ごと、または6カ月ごとに医師との確認が義務付けられており、「AIが全部やる」わけでは決してない。 なぜこの試みが生まれたのか 背景にあるのは深刻な医療アクセス問題だ。ユタ州だけで50万人もの住民がメンタルヘルスケアを受けられていないという。精神科医や心療内科医の絶対数が足りない。地方や低所得層は特に深刻で、診療予約まで数カ月待ちという状況は珍しくない。 この問題は日本でも無縁ではない。精神科・心療内科の初診待ち期間は都市部でも数週間〜数カ月に及ぶことが多く、「クリニックに繋がれれば御の字」という現実がある。維持処方のためだけに月1回の通院を繰り返すという構造的非効率は日本でも同様だ。 医師コミュニティの懸念 これに対し、精神科医たちは複数の問題点を指摘している。 システムの不透明性がまず挙げられる。AIがどのような基準で「更新可」と判断するのかが外部から検証しにくい。精神状態のアセスメントは非常に繊細で、テキストや定型質問だけでは捉えきれないニュアンスがある。 また「本当に必要な人に届くか」という疑問もある。$19/月というコスト、スマートフォン操作の必要性、英語でのやりとり——これらのハードルを越えられる人はすでにある程度のリソースを持っている人だ。最も支援が必要な層にリーチできるかは不明確だと批判する声もある。 実務への影響：IT・医療DX担当者の視点で このパイロットが示すのは、AIを「補助ツール」ではなく「プロセスの一部として組み込む」設計への転換だ。以下のポイントはITや医療DXに関わるエンジニア・管理者にとって参考になる。 スコープの厳密な定義が鍵 AIに委譲するタスクを「維持薬の更新のみ」「安定患者のみ」と極限まで絞っている。これはAI導入設計の基本だが、特に安全性が求められる業務では「何をやらせないか」の定義が「何をやらせるか」と同等かそれ以上に重要になる。 エスカレーションパスの設計 リスクサインを検知した場合に人間のクリニシャンへ引き渡す仕組みが明確に定義されている。AI自律化のデザインパターンとして、「完全自律」ではなく「条件付きエスカレーション」モデルはエンタープライズ導入においても参考になる。 規制サンドボックスの活用 ユタ州は「AI政策局（Office of Artificial Intelligence Policy）」という専門組織を持ち、法整備より先に実証できる仕組みを用意している。日本でも規制のサンドボックス制度は存在するが、医療AIへの適用は遅れており、制度設計の議論が急がれる。 筆者の見解 「これが大丈夫なのか」という直感的な不安は理解できる。精神科の薬は効果も副作用も個人差が大きく、「安定しているかどうか」の判断はそれ自体が高度な臨床スキルだ。だからこそ今回の設計があえてスコープを極限まで絞ったことは、むしろ誠実だと思う。 重要なのは「AIが精神科医を代替する」ではなく、「精神科医にしかできない仕事に精神科医の時間を集中させる」という発想だ。維持薬の更新確認という、ある種の定型タスクをAIが担うことで、医師が複雑なケースに集中できる——その全体最適の発想は正しい方向性だと感じる。 AI自律化の設計において、「人間の承認を都度求め続ける副操縦士型」と「条件定義の中で自律的に動き続けるエージェント型」の間には大きな差がある。今回のモデルはその中間に位置するが、「安定患者×低リスク維持薬×定期エスカレーション」という条件設計は、自律性と安全性を両立しようとした真剣な試みとして評価できる。 ただし、「このパイロットが成功する」ことと「このモデルが広がる」ことは別の話だ。50万人のアクセス問題は本物だが、その解決策がAI処方更新の普及である必要はない。遠隔診療の整備、保険適用の見直し、精神科医の養成——AIが医療格差を解消する手段になりうるとすれば、それは処方権限の委譲よりも、診断支援・トリアージ支援という形の方が当面は現実的かもしれない。 世界初の試みが安全に完走できるかどうか。この1年のデータが、医療AIの未来地図を大きく書き換える可能性がある。 出典: この記事は Chatbots are now prescribing psychiatric drugs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「ゼロデイを探せ」——そう指示するだけでよくなる日が来る セキュリティ研究の世界に、静かだが根本的な地殻変動が起きている。著名なセキュリティ研究者 Thomas Ptacek が発表した考察「Vulnerability Research Is Cooked（脆弱性研究は終わった）」は、最前線の大規模言語モデル（LLM）エージェントが、脆弱性探索の実践と経済性を「段階的にではなく、階段関数的に」変えようとしていると主張している。 「ソースツリーにエージェントを向けて『ゼロデイを探してくれ』と入力するだけで、大量の高インパクトな脆弱性研究が成立する時代がくる」——この一文は、セキュリティコミュニティに大きな波紋を呼んでいる。 なぜエージェントは脆弱性探索が得意なのか LLMはすでに膨大な「バグ知識」を内包している フロンティアモデルと呼ばれる最高性能の LLM は、学習済みの重みの中に、これまで文書化されてきたほぼすべての「バグクラス（bug classes）」を内包している。 ステールポインタ（stale pointer）: 解放済みメモリへの参照 整数ミスハンドリング（integer mishandling）: オーバーフローや符号の扱いミス 型混乱（type confusion）: 異なる型として誤解釈されるオブジェクト アロケータグルーミング（allocator grooming）: ヒープ配置を意図的に操作する手法 Linux KVM ハイパーバイザーが hrtimer サブシステムや workqueue、perf_event とどう接続されているか——そういった深い依存関係の知識も、すでにモデルの重みに焼き込まれている。 脆弱性探索はLLMが最も得意な問題と一致する Ptacek が指摘する核心はここだ。脆弱性の発見とは本質的に、「パターンマッチング（バグクラスの照合）＋制約解決（到達可能性・悪用可能性の検証）」の組み合わせだ。これはまさに LLM エージェントが最も得意とする暗黙的な探索問題である。 さらに重要な点として、エクスプロイト検証の成否は「動くか・動かないか」という明確なフィードバックで返ってくる。エージェントは疲れることなく、指示する限り探索し続けられる。 実務への影響——攻撃者も防御者も同じツールを使う 日本のセキュリティチームへの示唆 この変化は、攻撃側と防御側の双方に等しく影響する。 攻撃側：これまで熟練した研究者が数週間かけて行っていた脆弱性探索が、エージェントによる自動化で劇的に短縮される。「既知脆弱性のパッチ未適用」という日本企業に多いリスクは、これまで以上に危険な状態になりうる。 防御側（Defender）：同じツールを使えば、自社システムの脆弱点を攻撃者より先に見つけることができる。ペネトレーションテスト（侵入テスト）の在り方が大きく変わり、より広いカバレッジを低コストで実現できる可能性がある。 実務で今すぐ考えるべきポイント 自動脆弱性スキャンの戦略を見直す: 従来の SAST/DAST ツールに加え、LLM エージェントを活用したコードレビューの試験的導入を検討する時期に来ている パッチ適用の優先度と速度を上げる: エージェントによる発見・悪用のサイクルが加速する前提で、パッチ管理の SLA を再設定する セキュリティ研究者の役割を再定義する: 手動での脆弱性調査から、エージェントの指示設計・出力検証・倫理的判断という上位レイヤーへのシフトを今から準備する Bug Bounty の経済性変化に備える: 脆弱性発見の参入障壁が下がると、プログラムへの報告数が急増する可能性がある 筆者の見解 この話を読んで真っ先に思ったのは、「これはまさにエージェントの本質が問われる分野だ」ということだ。 AIエージェントが真に価値を発揮するのは、人間への確認・承認を繰り返す「副操縦士」的な設計ではなく、自律的に判断・実行・検証のループを回し続ける設計においてだ。脆弱性研究はその典型で、「コードを解析 → バグクラスと照合 → 到達可能性を検証 → 試行する → 結果を確認 → 次を試す」という繰り返しのループこそがエクスプロイトの本質だ。エージェントが疲れを知らずにこのループを回し続けられるという特性が、まさにここで爆発的な威力を発揮する。 ...

GitHubのCOOであるKyle Daigle氏が公開した統計が、開発者コミュニティに波紋を広げている。2025年の年間コミット数は10億件だったが、2026年に入って週2.75億件ペースにまで急騰。このまま成長が続けば年間140億件に達する計算だ。同時にGitHub Actionsの実行時間も2023年の週5億分から2025年に週10億分、そして現在は週21億分と、わずか数年で4倍以上に膨れ上がっている。 何がコミット数を爆発的に増やしているのか 数字だけを見れば「何かの誤りでは」と思うほどの急増だが、現場の肌感覚と照合すると辻褄が合う。AIアシスタントを使ったコーディングが当たり前になるにつれ、1人のエンジニアが1日に書けるコード量・コミット頻度は飛躍的に上がっている。以前なら「大きな機能ブロックをまとめてコミット」が普通だったが、今は細かい反復サイクルで何度もコミットを積み上げるスタイルが定着しつつある。 加えて、AIエージェントが自律的にリポジトリを操作するケースも増えている。人間が書くのではなく、エージェントがブランチを作り、コードを生成し、テストを実行してプルリクエストを投げる——そうしたワークフローが普及すれば、コミット数が人間の頭数に比例しなくなるのは当然だ。 GitHub Actionsの急成長が示すもの コミット数と並んで注目したいのがGitHub Actionsの数字だ。週21億分という実行時間は、単に「CI/CDを使う人が増えた」では説明がつかない水準に達している。 背景にあるのは、AIが生成したコードを自動検証するパイプラインの拡大だろう。コードがAIによって大量生成される世界では、それを検証・テスト・デプロイするための自動化基盤の需要も比例して増える。GitHub Actionsはその受け皿として機能している。 日本企業の多くはまだCI/CDの導入率そのものが低く、「GitHub Actionsをフル活用している」という現場は限られる。だが海外では、AIコーディング→自動テスト→自動デプロイのサイクルが当たり前のインフラになりつつある。この差は今後のエンジニアリング生産性に直結する。 実務への影響——日本のエンジニア・IT管理者へ ① コスト設計を見直す GitHub ActionsはPublicリポジトリなら無料だが、Privateリポジトリでは実行時間に応じた課金が発生する。AIエージェントが自律的にActionsを起動するようになると、想定外の課金増が起きやすい。Actionsの実行時間を定期モニタリングする習慣と、月次予算アラートの設定を今すぐ確認しておくべきだ。 ② セルフホストランナーの検討タイミング 実行時間が増えるほど、GitHub-hosted runnerよりセルフホストランナーのコスパが良くなる閾値に近づく。Azure VMやAzure Container Instancesでセルフホストランナーを動かす構成は、特にEnterpriseプランを使う日本企業には現実的な選択肢だ。 ③ ブランチ戦略・コードレビュー体制の再設計 AIが大量のコミットを積み上げる世界では、従来の「人間がすべてのコードをレビューする」前提が崩れる。レビュー自動化・品質ゲートの自動化をどこまで進めるか、組織のポリシーとして明文化する必要がある。 筆者の見解 GitHubはMicrosoftが2018年に買収して以来、開発者プラットフォームとして着実に成長を続けてきた。今回のデータはその集大成とも言える数字で、素直に評価していい。 ただ、ここで大事なのは数字の裏にある構造変化だ。「コミットが増えた」のではなく「AIエージェントがコードを書く量が増えた」と読み替えたとき、開発現場のあり方は根本から変わる。自分でコードを書くことよりも、AIが回すループを設計・管理する能力が問われる時代になってきた。 個人的に今一番注目しているのは、AIエージェントが自律的に判断・実行・検証を繰り返すハーネスループの設計だ。単発の指示と応答を繰り返すだけでは、この数字の伸びについていけない。エージェントが連続して動き続ける仕組みをどう構築するか——それが今のエンジニアリングの最前線だと感じている。 日本の多くの現場ではまだAIコーディングの導入すら遅れているが、海外の数字はもうここまで来ている。「うちはまだそこまで」と思っているうちに、気づけば取り返しのつかない差が開く——そういうフェーズに入ってきた、というのが正直な実感だ。 出典: この記事は Quoting Kyle Daigle の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが2026年4月4日より、Claudeの定額プランをOpenClawなどのサードパーティ製「ハーネスツール」から利用できないよう変更した。AIエージェントが日常業務を自律的に代行するツールが急成長する中、プラットフォーム側の容量管理と利用者の自由の間に、初めて本格的な摩擦が生じた形だ。 何が変わったのか 変更の核心は「サブスクリプションの利用枠をサードパーティハーネスに使えなくなる」という点だ。これまでOpenClawユーザーはClaude Proなどの定額プランのリクエスト枠をそのまま流用できたが、今後は別途「従量課金バンドル」を購入するか、Claude APIキーを直接使う必要がある。 Anthropic側は既存ユーザーへの配慮として、月額プランと同額の一時クレジットを付与。割引バンドルの提供と全額返金の選択肢も用意している。同社Claude Code担当エグゼクティブのBoris Cherny氏は「急増する需要に対応するため、自社製品とAPIを優先する必要がある」と説明した。 OpenClawとは何か、なぜここまで広がったか OpenClawは受信トレイの管理・カレンダー調整・フライトチェックインといった「人間がやっている反復タスク」をAIが自律的に代行するツールとして、今年初めに爆発的に普及した。AIモデルの前後に処理を差し込み、自律ループを実現する「ハーネス」の先駆的な実装として注目を集めた。 シンプルな使い勝手と強力な自動化能力が口コミで広がり、Anthropicのインフラに想定外の負荷をかける規模にまで成長した。 競合ダイナミクスも背景に 今回の変更には、もう一つ見逃せない文脈がある。OpenClawを開発したPeter Steinberger氏がすでにOpenAIへ転職済みという事実だ。Steinberger氏は「Anthropicを説得しようとしたが、せめて1週間の猶予を得るのが精一杯だった」とコメントしている。 競合他社に人材を渡した製品のインフラ負荷を、自社の定額料金で支え続けることへの合理的な判断——とも読めるだろう。Anthropicが自社の統合ツール群へユーザーを誘導したい意図もにじむ。 実務への影響 — 日本のエンジニア・IT管理者にとって 日本でOpenClawを直接利用しているユーザーはまだ少ないが、この変更が示すメッセージは明確だ。「個人向けサブスクリプション」と「業務用エージェント基盤」は、根本的に別の設計思想が必要ということだ。 すぐに取れる行動： 試用・個人利用ならサブスクリプションで引き続き問題ない 業務用の自動化・エージェントを構築するなら、最初からAPIキーベースで設計する 従量課金への移行は「コストが増える」という側面だけでなく、「AIの稼働量を可視化・管理しやすくなる」という面もある サードパーティハーネスを業務フローに組み込む際は、プラットフォーム側のポリシー変更リスクを織り込んだ設計を意識する クリティカルな業務フローを外部ツール依存で構築する場合、APIの直接利用か、複数モデルへのフォールバックを検討したい。 筆者の見解 OpenClawの急成長は、「ハーネスループ」——AIエージェントが自律的に判断・実行・検証を繰り返すループ型の設計——がついに一般ユーザーの実生活に浸透し始めたことを象徴している。単発の質問に答えるだけのAIから、自分で動き続けるエージェントへ。その移行が静かに、しかし確実に進んでいる。 Anthropicの今回の判断は、ビジネス上の合理性は十分理解できる。急増するハーネスツールの負荷を定額料金で無制限に吸収するのは、長期的に持続可能ではない。熱心なパワーユーザーに追加コストを求めることになるのは痛みを伴うが、インフラの健全性を保つための必要な一手と見ることもできる。 より本質的な示唆は、ハーネスツールがここまで普及したという事実そのものだ。メールの返信・予定調整・手続き処理——これらを人間が手作業でこなしている時代は、終わりに近づいている。日本のIT現場でも、「AIに単発の質問をする」フェーズから「AIが自律的に動く仕組みを設計する」フェーズへのシフトを、本気で考える時期に来ている。今回の騒動は、そのことを改めて教えてくれた。 出典: この記事は Anthropic essentially bans OpenClaw from Claude by making subscribers pay extra の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI電力争奪戦の新局面——大手テック各社が天然ガスに殺到 AIブームは今、データセンターの電力需要という形で地面の上に降り立ちつつある。Microsoft、Google、Metaの3社が相次いで天然ガス発電所の建設計画を発表し、業界全体が電力インフラの確保に血眼になっている。これはもはや「AI競争」ではなく「エネルギー競争」の様相を呈している。 3社が競って発表した巨大プロジェクト MicrosoftはChevronおよびEngine No. 1と連携し、テキサス州西部に最大5ギガワット（GW）規模の天然ガス発電所を建設すると発表した。Googleはテキサス州北部にCrusoeと共同で933メガワット（MW）の発電所を整備する。そしてMetaはルイジアナ州のHyperionデータセンターに天然ガス発電所を7基追加し、合計容量を7.46GWにまで引き上げる計画だ。この数字はサウスダコタ州全体の電力消費量に相当するという。 天然ガスが選ばれた理由は単純で、テキサス州やルイジアナ州などアメリカ南部地域には世界有数の天然ガス埋蔵量があるからだ。米地質調査所（USGS）によれば、ある1つの地域だけでもアメリカ全土の10カ月分のエネルギー供給が賄えるほどの埋蔵量がある。 なぜこれが重要か——見えてきたリスク構造 これらの投資が単純な「設備増強」とは異なる点が2つある。 タービン不足と価格高騰: エネルギーコンサルタントのWood Mackenzieによると、発電所用ガスタービンの価格は2019年比で今年末までに195%上昇する見込みで、新規発注は2028年まで受け付けられない状態だ。納品には6年かかる。つまり各社は「今すぐ確保しなければ永遠に出遅れる」という焦りの中でこの賭けに出ている。 電力価格への波及: アメリカの発電量の約40%を天然ガスが担っている（米エネルギー情報局）。各社は発電所をグリッド（電力網）に接続せず、データセンターに直結させる「メーター裏（behind the meter）」方式で外部の電力価格上昇の影響を回避しようとしている。しかし需要が際限なく膨らめば、それでも周辺の電力価格を押し上げる可能性がある。過去にも似たような状況が起きている。 供給の有限性: 天然ガスが豊富とはいえ無限ではない。近年、米国内の主要シェールガス3地域の生産増加ペースが著しく鈍化していることも懸念材料だ。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと この動向が日本のIT現場に与える影響は、以下の点で具体的だ。 クラウドコスト上昇の可能性: Azure・AWS・Google Cloudはいずれも電力コストをクラウド料金に転嫁する。エネルギーコストの上昇はサービス料金の値上げ圧力につながる。 AI利用コストの試算見直し: 生成AIをフル活用したシステム設計を検討している場合、中長期のランニングコストは現在の試算より高くなるシナリオを想定しておく必要がある。 グリーンIT目標との矛盾: 多くの日本企業が掲げるカーボンニュートラルへの取り組みと、天然ガス依存のAIクラウドの利用が矛盾を生む可能性がある。CSR・ESG報告においてこの観点を整理しておくことが求められる。 オンプレ・ハイブリッド戦略の再評価: エネルギーコスト上昇を理由に、一部ワークロードをオンプレミスやエッジに寄せるアーキテクチャを再評価する動きが加速するかもしれない。 筆者の見解 MicrosoftがChevronと組んでテキサスに5GW規模の発電所を建設する——この規模感だけでも、今のAI競争がいかに「フィジカルな戦い」に変容しているかがわかる。 ただ、正直に言えばこの状況には「FOMOが孫の代まで増殖している」という記事の表現が的を射ている気がしてならない。タービンは不足し、納期は6年、価格は倍以上——それでも各社が走り続けるのは、出遅れた場合のリスクを誰も取れないからだ。 Microsoftにはこの賭けに勝つだけの資本力もインフラ運営の実績もある。それは間違いない。問題は「電力を確保すれば勝てる」という前提がどこまで正しいかだ。エネルギーは必要条件であって十分条件ではない。AIの競争優位はモデルの質、エコシステム、開発者体験の総体で決まる。そこに本来の注力ポイントがある。 AIの電力消費が増え続けるという前提の下で天然ガスに張るのは、一面では合理的な判断だ。だが「AIが今後も指数関数的に電力を必要とし続ける」という前提そのものが崩れるリスクも見ておく必要がある。モデルの効率化が進めば、数年後には今ほどの電力を必要としない可能性もある。長い納期で発注したタービンが届く頃に市場がどうなっているか、誰にも断言できない。 インフラへの大胆な先行投資はMicrosoftの強みでもある。その強みを生かしながら、電力確保だけでなくエネルギー効率の改善にも同じくらい本気で取り組む姿を見せてほしい——そう期待している。 出典: この記事は AI companies are building huge natural gas plants to power data centers. What could go wrong? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの覇権争いは、技術の優劣だけでなく「資本市場での証明」へと舞台を移しつつある。Anthropic と OpenAI という生成AI業界の二大プレイヤーが、いずれも2026年後半のIPO（新規株式公開）を目標に動いていることが明らかになった。しかも両社は互いに「先を越されたくない」という意識を持ちながら、上場のタイミングを競い合っているという。 このニュースは単なる財務イベントの予告ではない。生成AIが「実験的なテクノロジー」から「巨大産業」へと脱皮する歴史的な転換点を象徴している。 両社の現在地——数字が語るスケール Anthropicは直近のシリーズGラウンドで300億ドル（約4兆5000億円）の資金調達を完了しており、IPO前の企業評価額はすでに天文学的な水準に達している。 OpenAIは年間売上高が250億ドル（約3兆7500億円）を突破。ChatGPTのリリースからわずか3年ほどでここまで来たのだから、成長速度としては異常値と言っていい。 両社に共通するのは「研究機関から始まったが、いまや巨大ビジネスになった」という文脈だ。Anthropicは安全性重視の非営利的な理念を持ちつつ、Amazonなど大企業からの巨額投資を受け入れてきた。OpenAIはMicrosoftとの深い提携関係を持ちながら独立性を模索し続けてきた。IPOはその複雑な資本構造に一定の答えを出すプロセスでもある。 なぜいまIPOなのか 「競合に先を越されたくない」というプレッシャーに加え、いくつかの構造的な理由がある。 第一に、投資家の「EXIT」ニーズ。 両社には初期から資金を投じてきたVC（ベンチャーキャピタル）や機関投資家が多数いる。成長フェーズが一段落した現在、IPOによる流動性確保は自然な流れだ。 第二に、企業顧客への信頼性向上。 上場企業であることは、大企業・官公庁・金融機関との契約において「ガバナンスの透明性」を示す重要なシグナルになる。特に規制産業では「上場しているかどうか」が調達条件に関わるケースすらある。 第三に、人材確保のためのストックオプション設計。 AI人材の争奪戦は熾烈を極めており、上場後の株式報酬設計を明確にすることは採用競争力に直結する。 日本のIT現場への影響 このIPO競争が示す最大のメッセージは「生成AIはもはや一過性のブームではない」という資本市場からの宣言だ。日本のIT業界にとっていくつかの実務的な含意がある。 調達・契約の安定性が増す。 上場企業になることで財務開示が義務化され、サービスの継続性や企業の健全性を客観的に評価できるようになる。「このAIスタートアップ、突然消えないか？」という不安を抱えてきた企業にとっては追い風だ。 エンタープライズ向け機能・コンプライアンス対応が加速する。 IPO後は機関投資家の目が向くため、ガバナンスや規制対応（SOC2、ISO27001等）の強化が促進される。日本企業が求めるセキュリティ要件を満たすソリューションの充実が期待できる。 競争激化によるコスト低下。 上場で調達した資金はインフラ拡充・研究開発に投じられ、APIの低価格化・高性能化が続く可能性が高い。生成AIを使い倒すコストは今後も下がっていく方向だ。 実務での活用ポイント 今のうちに両社のエンタープライズプランを評価しておく: IPO後は利用規約・価格体系・SLAが変わる可能性がある。現在の条件でPoCを始めておくのが得策 ベンダーロックインへの備えを: 上場後は株主利益のためにAPIの仕様変更・値上げが起こりうる。抽象化レイヤーの設計やマルチベンダー戦略を今のうちに検討する 調達・情報システム部門との連携を: IPO後は「上場企業との取引」として稟議が通りやすくなるケースがある。社内説得の文脈で活用できる 筆者の見解 個人的には、このIPO競争を「生成AI第一章の幕引き」として捉えている。技術が実証され、市場が形成され、資本市場がそれを評価する——これはひとつのサイクルの完成だ。 一方で、IPOによって両社に新たな重力が生まれることも忘れてはならない。四半期ごとの業績開示が求められれば、長期的な安全性研究よりも短期収益が優先されるプレッシャーが増す。とりわけ安全性研究を存在意義の核に据えてきたAnthropicにとって、この圧力とどう向き合うかは大きな試練になりうる。 技術は間違いなく前進している。いま最も重要なのは、AIを単発の質疑応答ツールとして使う段階から、自律的に判断・実行・検証を繰り返すエージェント的な仕組みを組織に埋め込む段階へとシフトすることだ。IPOによる資金調達がその方向への投資を加速させるなら、それ自体は歓迎すべきことだと思っている。 日本企業にとって危ういのは、このニュースを「海外の大きな話」として距離を置いてしまうことだ。生成AIが産業インフラになる速度は、多くの経営者が想定しているより格段に速い。「まだ様子見」のポジションを取り続けることのリスクは、今年後半からさらに高まっていく。 出典: この記事は Why Anthropic and OpenAI want to go public の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが生み出すサイバー脅威の議論は以前からあった。しかし今回は話が違う。Anthropicが社内で「Mythos」と呼ぶ次世代モデルの詳細が、誤って公開されてしまったドキュメントを通じて外部に漏れ出し、「サイバーセキュリティにおける分水嶺（ウォーターシェッド）」という表現を専門家が口にするほどの反響を呼んでいる。 何が漏れたのか Anthropic社の未公開ブログ投稿がFortune誌によって報じられ、その内容に業界が色めき立った。同社の説明によれば、漏洩はコンテンツ管理システムの「人為的ミス」によるもの。ただし内容そのものは否定していない。 文書には「Mythosは現時点で他のいかなるAIモデルよりもサイバー能力で大幅に先行しており、防御側の取り組みをはるかに上回るペースで脆弱性を悪用できる次世代モデルの波を予兆するものだ」と記されていた。 リリースは2026年第2四半期が見込まれており、Anthropicは一部の組織に先行テストへのアクセスを許可。「迫り来るAI主導の悪用に対し、自組織のシステムを強化する」目的とされている。また米政府当局者にも非公式の警告を行っているとAxiosが報じている。 AIエージェントが「攻撃者」になるとき これまでのAIを使った攻撃は、人間ハッカーが使うツールの一つとしてAIを活用するものだった。だが「AIエージェント」の登場はその前提を壊す。 エージェントとは、人間の指示を待たずに自律的にタスクを実行するAIのことだ。脆弱性のスキャン、悪用コードの生成、攻撃の実行という一連の流れを、人間が介在しないままループで繰り返せるとしたら——単独のエージェントが数百人の人間ハッカーより素早く、しつこく動き続けることになる。 ネットワーキング企業Cato Networksの創業者・CEOであるシュロモ・クレイマー氏はCNNに「エージェント型攻撃者が来る。これはサイバーセキュリティの歴史における転換点だ」と語った。 OpenAIも昨年12月、自社の次期モデルについて「高い」サイバーセキュリティリスクをもたらすと公式に警告しており、こうした流れは一社だけの話ではない。 すでに現実化している「AI活用型攻撃」 理論の話だけではない。2026年1月、技術的なスキルが限られたロシア語圏のサイバー犯罪者が複数のAIツールを組み合わせ、55カ国以上で人気のファイアウォールソフトを実行する600台超のデバイスをハッキングした事例をAmazon Web Servicesのセキュリティチームが報告している。 AWSによれば、この攻撃者は「限られた技術能力にもかかわらず、生成AIサービスを使って攻撃の全フェーズにわたって既知の手法を実装・スケールさせた」という。複数のAIモデルが組み合わせて使われた点も注目に値する。 AI活用型攻撃が「高度なハッカー限定」ではなく、スキルの低い攻撃者の「能力増幅装置」になっているという現実が、ここに示されている。 「人間が消える」わけではない ただし、現時点では万能ではないことも専門家は指摘する。サイバーセキュリティ企業Armadin社のエバン・ペーニャ氏によれば、高度なAIモデルは脆弱性のリサーチやエクスプロイトコードの開発には優れているが、「その組織にとって最も価値ある情報が何か」を判断するコンテキストは人間ハッカーに劣るという。 米政府に攻撃的サイバー能力を提供するTwenty社のジョー・リン氏は「AIが実行を担う一方で、その結果に責任を持つのは常に人間でなければならない」と述べており、少なくとも当面は「人間＋AI」のハイブリッドモデルが攻撃・防御の双方で続くとみられる。 実務への影響——日本のエンジニア・IT管理者が今すぐやるべきこと この状況を「海外の話」と見ていると危うい。日本企業も無縁ではなく、むしろ対応が遅れやすい環境だからこそ早期の準備が重要だ。 1. 脆弱性管理のサイクルを短縮する AIによる攻撃は脆弱性公開から悪用までの時間を著しく短縮する。「月次パッチ」では追いつかない場面が増える。CVEの監視自動化と優先順位付けに今すぐ投資を。 2. AIを防御側にも組み込む SIEM/SOARへのAI統合、異常検知の強化を検討する。攻撃者がAIを使うなら、守る側もAIで応戦するのが現実的な対策になる。 3. 「スキルの低い攻撃者」を甘く見ない AIによる能力増幅は、標的になるリスクの分布を変える。中小規模の組織も例外ではない。フィッシング・ソーシャルエンジニアリング訓練の見直しも合わせて行うべきだ。 4. ゼロトラスト原則の再確認 「入ってきた相手を信頼しない」という設計原則は、AI活用型攻撃が高速化する世界でより重要になる。ネットワークセグメンテーションや最小権限の実装を改めて点検したい。 筆者の見解 この話題で最も気になるのは、攻撃側が「エージェントのループ」を使い始めているという点だ。単発の指示・応答ではなく、エージェントが自律的に判断・実行・検証を繰り返す仕組みが攻撃に転用されれば、人間の反応速度では対応不可能な局面が出てくる。 逆に言えば、同じアーキテクチャを防御側にも導入しなければ非対称な戦いが続くということでもある。「AIエージェントを自律的にループさせる」技術は攻撃でも防御でも同じ原理で動く。防御側が先手を打って仕組み化できるかどうかが、これからの数年で明暗を分けるだろう。 AIによるサイバーリスクの高まりは、AIを「便利ツール」としてだけ捉えていた段階の終わりを意味する。脅威インテリジェンスとAIの組み合わせ、そして自律的に回り続ける防御エージェントの設計——これを「将来の課題」と先送りできる余裕は、もうないかもしれない。 出典: この記事は Anthropic’s next model could be a ‘watershed moment’ for cybersecurity. Experts say that could also be a concern の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIのトップ層がまた動いた。2026年4月、同社の組織再編が内部メモを通じて明らかになり、主要幹部3名が同時に役割を変えることが判明した。単なる人事ニュースに見えるが、その背景にはOpenAIが直面しているいくつかの構造的な課題が透けて見える。 何が起きたのか 今回の主な人事変動は3点。 Fidji Simo（CEO of AGI Deployment）が医療休暇へ 自己免疫神経系疾患（neuroimmune condition）のため、数週間の医療休暇を取ると本人が社内メモで発表。彼女の不在中は、OpenAI社長のGreg Brockmanが製品部門全体を統括する。スーパーアプリ開発を含むプロダクト戦略を一手に引き受けることになる。 Brad Lightcap（COO）が役割変更 COOを離れ、「特別プロジェクト」に専念する新ポジションへ移行。今後はSam Altman CEOに直接報告する体制に。COOの主業務はCRO（最高収益責任者）のDenise Dresserが引き継ぐ形となった。DresserはSalesforceでSlack CEOを務めた人物で、エンタープライズ領域に深い知見を持つ。 Kate Rouch（CMO）が退任 がん治療に専念するための退任。回復後はより限定的なスコープの役割で復帰する意向とのこと。暫定CMOとしてGary Briggsが就任する。 なぜこれが重要か この人事を表面だけ見ると「体調不良による一時的な交代」に映るが、文脈を加えると別の顔が浮かぶ。 2026年初頭、OpenAIは複数の逆風に晒されていた。米国防総省との新契約締結は社内外で物議を醸した。AI動画生成ツール「Sora」はリソース不足を理由に一時的に縮小。エンタープライズやコーディングツール分野での競合キャッチアップに追われ、広報責任者（CCO）のHannah Wongも1月に退任している。 そこに今回の3名同時変動。「組織の求心力がどこにあるか」という問いへの回答として、Greg BrockmanとDenise Dresserという2人への権限集中が図られた格好だ。特にBrockmanは、一度はOpenAIを離れた後に復帰した人物であり、Altman体制の核心的なビジョンを共有している。 もう一つ注目すべきは「AGI Deployment」というポジション名そのものだ。かつては「Applications担当CEO」だったSimoの肩書きが、いつの間にか「AGI Deployment担当CEO」に変わっている。OpenAIが製品戦略をAGIの実用展開として位置づけ始めた意図が読み取れる。 実務への影響——日本のIT現場への示唆 日本のエンタープライズでOpenAIのAPIやChatGPT Enterpriseを採用している組織にとって、今回の変動がすぐに影響を与えることはないだろう。しかし、以下の点は注視しておく価値がある。 Denise DresserのSlack CEO経験はエンタープライズ向けプロダクト強化に直結する可能性が高い。Slack同様の企業向けコミュニケーション統合が加速するかもしれない COO機能をCSO・CFO・CROに分散させた構造は、OpenAIが「プロダクト単体の企業」から「複合的なエンタープライズ企業」へと変容しようとしているサインとも読める Greg Brockmanがスーパーアプリ戦略を直接指揮する体制になったことで、ChatGPTアプリの方向性が大きく動く可能性がある。日本でも法人・個人ともにChatGPTを中心とした業務フローを組んでいる企業は多く、UIや機能の大幅な変更には備えておきたい 筆者の見解 このニュースが気になるのは、「OpenAIがどこへ向かおうとしているか」のヒントが見えるからだ。Sora縮小、国防総省契約問題、そして今回の幹部大移動——これだけのことが数ヶ月で起きているのに、巨大ユーザーベースを抱える組織としての推進力は衰えていない。それはそれで凄みがある。 「AGI Deployment」という肩書きを本気で使い始めた組織の重力は、AI業界全体に影響してくるだろう。競争は激化するほど技術者にとっては良いことだ。ガンガン戦ってほしい。 注目したいのは、OpenAIが今後どの方向にプロダクトを振るかだ。AIエージェントが自律的にタスクを遂行する世界に本気で舵を切るなら、エンタープライズ市場での存在感はさらに増す。Denise DresserのSlack CEO経験がそこにどう効いてくるか、楽しみに見守りたい。 出典: この記事は OpenAI’s AGI boss is taking a leave of absence の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AMDが支援するオープンソースプロジェクト「Lemonade」が、ローカルAI界隈で急速に注目を集めている。GitHubのスター数はすでに2,100超。「ローカルAIは無料で、オープンで、速く、プライベートであるべき」というコンセプトを掲げ、GPU・NPUの両方を活用する本格的なローカルLLMサーバーとして登場した。 Lemonadeとは何か LemonadeはAMDのRyzen AI環境を中心に設計された、ローカルPC向けのLLMサーバーだ。バックエンドはネイティブC++で書かれており、サービス本体はわずか2MBという驚異的な軽量さ。インストーラーが依存関係を自動セットアップし、概ね1分以内に起動できる設計になっている。 主な特徴 GPU・NPU自動認識: 搭載ハードウェアに応じて最適な依存関係を自動設定。RyzenのNPUにも対応 マルチエンジン: llama.cpp、Ryzen AI SW、FastFlowLMなど複数の推論エンジンに対応 複数モデルの同時実行: 用途に応じて複数のモデルを並走させられる OpenAI API互換: 既存のアプリやツールをほぼそのまま接続できる マルチモーダル対応: チャット・ビジョン・画像生成・音声認識・音声合成をAPIで統一提供 連携済みアプリも豊富で、Open WebUI、n8n、Continue（VS Code拡張）、OpenHands、Difyなど、開発者に馴染みのある主要ツールが名を連ねている。GitHub Copilotとの連携も記載されている点が目を引く。 NPUとは何か——Ryzen AIが持つ第3の演算ユニット 「NPU（Neural Processing Unit）」という言葉に聞き慣れない方も多いかもしれない。CPUがあらゆる処理を担い、GPUが並列演算を担うのに対し、NPUはAI推論に特化した専用演算器だ。AMDのRyzen AIシリーズ（Ryzen 8000番台以降）に搭載されており、低電力でAI処理をこなせるのが特徴。 これまでローカルLLMといえばGPUメモリの量がボトルネックだったが、NPUを活用することでバッテリー駆動のノートPCでも実用的なLLM推論が可能になる方向性が開けてきた。Lemonadeはこの流れに正面から乗っかったプロジェクトだ。 実務への影響——日本のエンジニア・IT管理者に何が変わるか プライバシー要件の厳しい現場に刺さる 医療・法務・金融など、データをクラウドに送れない業種でも、OpenAI API互換のローカルサーバーがあれば既存のAIアプリをそのままオンプレ運用に切り替えられる。LangChainやLlamaIndexで書いたコードのAPIエンドポイントをLocalhostに変えるだけ、というシナリオが現実的になる。 開発・検証コストを下げるローカルサンドボックス Claude APIやAzure OpenAIを呼びながら開発していると、テスト段階でもAPIコストがかさむ。Lemonadeをローカルに立ててOpenAI互換エンドポイントを生やしておけば、開発・デバッグ段階はコストゼロで回せる。本番だけクラウドモデルに切り替える構成も容易だ。 AIエージェント・ハーネスループの自前インフラとして n8nとの連携が明記されている点が特に面白い。ワークフロー自動化ツールと組み合わせて、完全ローカルのAIエージェントパイプラインを構築できる。クラウドに一切データを出さないまま、LLMが自律的にタスクを繰り返し実行するループを設計できるわけだ。 明日から試せる手順： Ryzen AI対応PCまたはNVIDIA GPU搭載PCにLemonadeをインストール http://localhost:8000 のOpenAI互換エンドポイントをお気に入りのAIツールに向ける Continue（VS Codeプラグイン）を接続してローカルコード補完環境を試す n8nと組み合わせてRAGパイプラインの試作を始める 筆者の見解 正直に言う。MetaのLlamaシリーズには期待していない。コスパで見ると中国勢（Qwen、DeepSeekなど）の方がはるかに上だし、ローカルLLM界のメインストリームはもうそちらにシフトしている。 その文脈でLemonadeを見ると、AMD自身がNPUを活かした推論スタックを本気で整備してきたという点が重要だ。これはハードウェアベンダーとしてのAMDが「Ryzen AIを買えばAIがすぐ動く体験」を本気で作りにきたサインである。IntelもNPUを搭載しているが、ソフトウェアエコシステムの整備速度ではAMDに軍配が上がりそうな雰囲気がある。 そして何より、ローカルLLMとハーネスループの組み合わせこそが今一番アツいフロンティアだ。エージェントが自律的にタスクを繰り返し実行するループを設計しようとしたとき、クラウドLLMでやると推論コストが積み上がって採算が合わなくなる。ローカルで推論コストゼロのモデルを動かし続けられるなら、ループを回しまくる設計が成立する。 もちろん、モデルの品質はクラウドの大規模モデルに及ばない。でも「ループを高速に何十回も回す」用途ではローカルモデルの速度・コストの優位性が品質差を上回るケースは確実にある。Lemonadeがそのインフラとして機能するなら、使わない手はない。 PCを買い替えるなら、今後はNPU搭載の有無を確認する時代に入った。Lemonadeのようなエコシステムが育ってくれば、それが購入基準の一つになるだろう。ガンガン試してほしい。 出典: この記事は Lemonade by AMD: a fast and open source local LLM server using GPU and NPU の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

あなたのMacにはすでにAIが入っている Apple Siliconを搭載したMacには、macOS Tahoe（macOS 26）からAppleが独自に開発した約30億パラメータのオンデバイスLLMが標準搭載されている。Siriの音声応答や「Writing Tools」の文章補助に使われているあのモデルだ。しかしAppleはこのモデルをFoundationModelsフレームワーク経由のSwift APIとしてしか公開しておらず、ターミナルから直接呼び出す手段も、HTTPエンドポイントも、シェルスクリプトで活用する方法も用意していなかった。 そこに登場したのが、OSSプロジェクトapfel（MIT ライセンス）だ。GitHubで1,100以上のスターを集めており、Hacker Newsでも600ポイント超の話題となっている。 apfelが提供する3つのインターフェース 1. UNIXコマンドラインツール 出典: この記事は Show HN: Apfel – The free AI already on your Mac の内容をもとに、筆者の見解を加えて独自に執筆したものです。

コード検索といえば長らく正規表現（regex）の独壇場だった。grep、そして高速化したripgrep（rg）——その系譜に真っ向から「オワコン宣言」を突きつけるツールが登場し、Hacker Newsで話題になっている。その名はfff（Fast File Finder）。作者はDmitro Kovalenkoで、「正規表現なし・ripgrepより最大100倍速」を謳う。 ffsとは何が違うのか fff最大の特徴は永続インデックス（Persistent Index）だ。ripgrepはクエリのたびにファイルシステムを全走査する。高速ではあるが、大規模リポジトリになるほどレイテンシが積み重なる。fffは非同期バックグラウンド処理でインデックスを構築・更新し、2回目以降の検索を劇的に高速化する。ベンチマークによればripgrepが6秒前後かかるクエリをほぼ瞬時に返せるという。 もう一つの柱がSmith-Watermanスコアリングだ。これはもともとDNA配列のローカルアラインメントに使われるバイオインフォマティクスのアルゴリズム。コード検索への応用により、タイポや文字の欠落があっても意図したシンボルを高精度で見つけられる。「useEfectと打ってもuseEffectがヒットする」ようなファジーマッチを、正規表現に頼らず実現している。 AIエージェントこそが本命ターゲット 重要なのは、このツールがAI エージェント向けに最適化されている点だ。リポジトリ名もfff.nvimで、Neovimとのインテグレーションを主眼に置いているが、README にはClaude Code・Codex・OpenCodeといったAIコーディングエージェントとの連携を明示している。 AIエージェントがコードを読む際のボトルネックは2つ——時間とトークン数だ。fffは「平均10%の実行時間削減・17%のトークン削減」をfff-aiモードで実現すると主張する。アクセス頻度、Gitステータス、ファイルサイズなどを加味したスマートなソートで、エージェントが最初に見るべきファイルを上位に並べる。 つまりfff は「人間が使う検索ツール」ではなく、「AIが使う検索ツール」として設計されている。この発想の転換が従来の類似ツールと一線を画す。 実務への影響 エンジニアへのヒント 現在のワークフロー評価から始める: rg/fzf で体感速度に不満があるなら試す価値あり。特にモノリポや大規模リポジトリで効果が大きい Neovim利用者は即導入候補: fff.nvimとして提供されており、Neovimとのインテグレーションが最も洗練されている AIエージェントの速度チューニングとして: Claude Codeなどのエージェントがファイル探索に詰まっている場合、fff連携でトークン・時間を節約できる可能性がある IT管理者・アーキテクトへのヒント コード検索の「永続インデックス」はセキュリティ上の注意点も伴う。インデックスファイルの保存先と権限管理は運用前に設計すること ripgrepはリアルタイム性（インデックス不要で最新状態を即座に検索）が強み。fffは繰り返し検索の高速化が強み。用途によって使い分けが現実的 筆者の見解 正直に言う。このツールが今すぐripgrepを置き換えるかといえば、そうは思わない。Hacker Newsのコメント欄でも「34倍という数字はどのベンチマーク条件?」「インデックスの鮮度保証は?」という疑問が相次いでいる。ベンチマーク競争は往々にして恣意的な条件設定になりがちで、鵜呑みにするのは危険だ。 ただ、着眼点は完全に正しい。 AIエージェントが自律的にコードを読み・修正し・検証するループを回す時代において、「ファイル検索のコスト」は無視できない摩擦になっている。人間なら多少遅くても慣れで済む話だが、エージェントが1日に数百回クエリを投げるなら話が違う。検索の遅延とトークン消費は、ハーネスループ全体のスループットに直撃する。 fff が主張する「AIエージェントのためのファイル検索」という方向性は、次の1〜2年で確実に主流になる。バイオインフォマティクスのアルゴリズムをコード検索に応用するという発想も面白い——シンボル名のファジーマッチはDNA配列マッチングと構造的に似ているという観察は鋭い。 ripgrepは当分死なない。正規表現は強力すぎる。だが「正規表現しか選択肢がない」という状況は確実に変わる。fffが標準になるかはともかく、この方向性をウォッチしておくことは必須だ。Claude Codeを使い倒している立場からも、エージェントの検索効率を上げる仕組みには今後もアンテナを張り続けたい。 出典: この記事は The future of code search is not regex – 100x faster than ripgrep の内容をもとに、筆者の見解を加えて独自に執筆したものです。

RAGは「それなりに動く」だけだった ドキュメント検索にRAG（Retrieval-Augmented Generation）を使っている開発チームは多い。でも正直なところ、RAGは「クエリに似たチャンクを引っ張ってくる」だけで、答えが複数ページにまたがっていたり、正確な構文が必要だったりすると途端に使い物にならなくなる。 ドキュメントツール「Mintlify」のエンジニアリングチームは、そのRAGの限界を正面から認めて捨てた。そして代わりにバーチャルファイルシステム（ChromaFs）を構築した。このアプローチがAIエージェント設計の考え方として非常に示唆に富んでいる。 エージェントはファイルシステムで育つ そもそも、なぜファイルシステムなのか。 AIエージェントが自律的にドキュメントを探索するとき、grep、cat、ls、find というUNIXの基本コマンドさえあれば事足りる。各ドキュメントページをファイル、各セクションをディレクトリとして扱えば、エージェントは自分で構造を辿りながら必要な情報を探し当てられる。これはRAGの「クエリ→チャンク返却」という受動的な仕組みとは根本的に違う。 エージェントが能動的に探索する——これがポイントだ。 本物のサンドボックスでは使い物にならなかった 「じゃあ本物のコンテナ環境を与えればいいじゃないか」と思うかもしれない。Mintlifyも最初はそのアプローチを試みた。Daytonaなどのサンドボックスを使ってGitHubリポジトリをクローンする方式だ。 しかし結果は散々だった。 P90起動時間：約46秒（ユーザーがローディングスピナーを眺め続ける時間） コスト試算：年間7万ドル超（月85万会話 × 1vCPU/2GiB RAM × 5分セッションの概算） フロントエンドで「ユーザーが待っている」状況で46秒は死刑宣告に等しい。インフラコストも非現実的だ。 ChromaFs：シェルの幻想を作り出す Mintlifyが取った解決策は「本物のファイルシステムは要らない、シェルの幻想を作ればいい」という発想の転換だった。 ChromaFsの仕組みはシンプルかつ巧妙だ： 既存のChromaDBを再利用: RAG向けにすでにインデックス・チャンク化されていたドキュメントDBをそのまま活用 just-bash（Vercel Labs製）上に構築: TypeScriptでbashを再実装したライブラリ。IFileSystemインターフェースをプラガブルに提供 UNIXコマンドをDBクエリに変換: grep → ChromaDBのメタデータクエリ、ls → インメモリのディレクトリツリー参照 ファイルツリーはgzip圧縮JSONで保持: __path_tree__という特殊ドキュメントとしてChromaに格納し、初期化時に展開 結果として達成したのが以下のパフォーマンス改善だ： 指標 サンドボックス方式 ChromaFs P90起動時間 約46秒 約100ms 1会話あたりコスト 約$0.0137 $0（DB再利用） 検索方式 ディスクスキャン DBメタデータクエリ 46秒が100ミリ秒に。460倍の高速化だ。 実務への影響——日本のエンジニアが今日から考えるべきこと 1. RAGの「とりあえず動く」で止まっていないか確認する 社内ドキュメント検索やナレッジベースにRAGを導入している企業は多い。しかし「チャンク返却」モデルの限界——複数ページにまたがる情報、正確な構文の取得——に直面しているなら、このアーキテクチャ転換は真剣に検討する価値がある。 2. エージェントに「探索する手段」を与える設計を意識する RAGは「教える」アーキテクチャ、ファイルシステムは「探索させる」アーキテクチャだ。AIエージェントに自律的な行動を求めるなら、ツールセット（grep/cat/ls相当の操作）を与える設計が本質的に合っている。 3. 既存インフラの再利用を先に考える Mintlifyの肝は「新しいインフラを作らず、すでにあるChromaDBを賢く再利用した」点だ。コスト削減の多くは新規投資ではなく既存資産の見直しから生まれる。 4. ユーザー体験が要件を決める 「46秒待てますか？」という問いに「待てない」と判断したからこそ、この設計変更が生まれた。技術選択はユーザー体験の要件から逆算すべきで、技術の都合をユーザーに押しつけてはいけない。 筆者の見解 この事例、正直かなりアツい。 いま一番面白いのはハーネスループの設計——エージェントが自律的に判断・実行・検証を繰り返す仕組みを作ること——なのだが、そのループを成立させるには「エージェントが探索できる環境」が不可欠だ。ChromaFsはまさにそれを実現している。 RAGは所詮「人間がクエリを投げてチャンクが返ってくる」受動的な仕組みで、エージェントが自律的にループを回す世界には根本的にミスマッチだ。Mintlifyはそれを正しく見抜いた。 「エージェントにはgrep、cat、ls、findで十分」という洞察も素晴らしい。複雑なツールチェーンを渡してエージェントを混乱させるより、UNIXの枯れた道具を仮想的に与えるほうが遥かにシンプルかつ強力——これは多くのエージェント設計にも応用できる考え方だ。 日本の現場でドキュメントAIを検討しているチームはいくつかいるだろうが、RAGを「とりあえず動く」で入れて満足しているところが大半だと思う。正直もったいない。技術的な優位性は「どう取ってくるか」ではなく「どう探索させるか」の設計にかかっている。ChromaFsのコード自体はオープンに公開されているので、まず読んで試してみることをガンガン勧める。 出典: この記事は We replaced RAG with a virtual filesystem for our AI documentation assistant の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが2026年3月24日、AI動画生成アプリ「Sora」の終了を発表した。アプリは4月26日、APIは9月24日に順次シャットダウンされる。ChatGPT以来最も注目されたプロダクトが、わずか6ヶ月で幕を下ろした理由は、技術の失敗でも競合の圧力でもない。経済的物理法則だ。 計算してみれば一目瞭然の惨状 Cantor Fitzgeraldのアナリスト、Deepak Mathivananが試算した数字が衝撃的だ。 1本の10秒動画の生成コスト: 約1.30ドル（H100 GPU 4基で約40分） ピーク時の推定コスト: 最大1日1,500万ドル Soraアプリの生涯累計収益: わずか210万ドル（6ヶ月分、全プラットフォーム合計） テキスト生成との比率: AI動画はテキストの160倍のコストがかかる構造 WSJが報じた実際の日次バーンレートは「わずか」100万ドルだが、これはOpenAIがスロットリングや品質制限を積極的にかけた後の数字だ。つまり「使えないように抑制してこの数字」。使わせれば使わせるほど赤字が膨らむ設計だった。 OpenAIのSora責任者であるBill Peebles氏が2025年11月にX（旧Twitter）に投稿した一文が全てを物語っている。 「経済性は現在、完全に持続不可能だ」 テック企業のエグゼクティブが自社プロダクトについてこれほど正直に書いた文章は珍しい。 ユーザーは動画を一度見て、二度と戻らなかった コスト構造だけではない。ユーザー行動のデータも壊滅的だった。 a16zのアナリスト、Olivia Mooreが公表したデータによれば、Soraのday-30リテンションは1%。対してTikTokは32%だ。ユーザーは動画を生成して「すごい」と思い、一度見て、二度と戻らなかった。新しいユーザーを獲得すればするほど赤字が加速する、最悪のユニットエコノミクスだ。 Disneyとの10億ドル契約も電話一本で終わり ドラマは財務だけじゃない。OpenAIはSoraシャットダウンの発表1時間前まで、Disneyに何も知らせていなかったとWSJが報じた。10億ドルの提携交渉が進行中だったにもかかわらず。契約は正式調印に至らないまま、電話一本で終わった。 AI動画スタートアップへの波及 Soraの撤退は、業界全体への警告でもある。 企業 財務状況 Runway EBITDAマイナス1億5,500万ドル Pika 8,000万ドル調達に対し収益750万ドル Kling ARR 2億4,000万ドル（利益非公開） 業界で最も健全に見えるKlingですら、収益性を公表できていない。「AI動画で黒字化に成功した企業」は2026年現在、存在しない。 実務への影響 企業のAI動画活用を検討しているIT担当者へ： API提供元の財務健全性を確認せよ: 今後、コスト構造が持続不可能なAI動画APIが次々と終了・価格改定を迫られる可能性が高い。本番プロダクションへの組み込みは慎重に。 ユースケースを絞り込め: 「なんとなく使える」より「ここでしか使えない」価値のある場面に限定する。プロモ動画の試作・内部資料のビジュアライゼーションなど、低頻度・高付加価値な用途に留める。 コスト意識の更新が必要: テキスト系AIとは桁違いのコスト構造を持つ。「AIだから安いはず」という前提は動画では全く通用しない。 代替手段も並行評価: RunwayやKling、Pika等の競合サービスも同様の構造的問題を抱えている。特定サービスへの依存リスクを考慮したマルチベンダー戦略が必要。 筆者の見解 Soraの終了について「OpenAIがまたやらかした」という論調を見かけるが、個人的にはちょっと違う見方をしている。これはOpenAIの失敗というより、AI動画という業態そのものが2026年時点では成立しないという話だ。Runwayも、Pikaも、Klingも、全員が同じ物理法則の下にいる。OpenAIはたまたま最初に「無理です」と手を挙げただけで、むしろ正直だった。 面白いのは、この構造的問題がテキスト系AIとの対比で際立つことだ。テキスト生成はすでにコスト曲線が急降下しており、黒字化が視野に入りつつある。一方、動画は160倍のコスト差がある。半導体の進化がどれほど速くても、この差を埋めるのに相当な年数がかかる。 もう一つ気になるのは、Copilotとの構造的な類似だ。「すごいと思って試したけど、2回目はない」というリテンション1%のパターン。これはSoraに限らず、「新機能として提供されるが実用性が薄いAI体験」全般に共通する問題だ。Microsoftが散々やってきたことと同じ轍を、OpenAIも踏んだ。 AIで本当に価値を出せる領域は、「一発のすごい生成体験」ではなく、繰り返し使われるループの中に組み込まれた自動化だと改めて確信する。エージェントが自律的に判断・実行・検証を繰り返すハーネスループの設計こそが、今投資すべき場所だ。一回見て感動するだけのプロダクトに1500万ドル/日は、どう転んでも割に合わない。 出典: この記事は A $20/month user costs OpenAI $65 in compute. AI video is a money furnace の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

NVIDIAがオープンモデル「Nemotron 3」ファミリーを発表した。Nano・Super・Ultraの3種構成で、エージェント型AIアプリケーションの構築に特化して設計されている。SuperとUltraは2026年前半にも提供開始予定だ。GPUの覇者がLLM本体にも本気で手を伸ばしてきた——その意味は小さくない。 Nemotron 3とは何者か NemotronはNVIDIAが独自開発・チューニングしたオープンLLMファミリーだ。今回の第3世代は3つのサイズで展開される。 Nemotron 3 Nano: エッジ・オンデバイス向けの軽量モデル。推論コストを極限まで下げながら実用精度を維持することを目標とする Nemotron 3 Super: バランス型。エンタープライズでのエージェント用途を想定 Nemotron 3 Ultra: フラッグシップ。ベンチマークではオープンソース最高水準を主張しており、クローズドモデルにも迫る性能を謳う ベースアーキテクチャにはLlama系をベースに独自のポストトレーニングとRLHFを重ねたものが採用されていると見られる。NVIDIAはモデル自体の提供と同時に、NIM（NVIDIA Inference Microservices）でのデプロイ最適化も提供し、「NVIDIA上で動かすと速い」エコシステムを一気通貫で押さえにきている。 エージェント向け設計という文脈 今回の発表で注目すべきは「エージェント型AIアプリ構築向けに設計」という一文だ。単に賢いチャットボットを作るためではなく、自律的に判断・行動・検証を繰り返すループ型エージェントの基盤として使うことを想定している。 ツール呼び出し（function calling）、複数エージェントの連携、長コンテキストでの推論といった能力が重点強化されているとされており、単発Q&Aではなく継続的なタスク遂行に向いた設計になっている。 Marvell社がNVLink Fusion経由でNVIDIAのエコシステムに参加したことも同時に発表されており、インフラ〜モデル〜アプリケーション全体をNVIDIAプラットフォームで完結させる戦略が着々と進んでいることがわかる。 実務への影響——日本のエンジニアはどう動くべきか Nemotron 3がオープンモデルである点は実務上の大きなメリットだ。以下のような活用シナリオが現実的になる。 1. 社内データを扱うエージェントの構築 クローズドAPIにデータを送れない用途（医療・法務・金融など）でも、オンプレやプライベートクラウド上でNemotron 3を動かせれば自律型エージェントの構築が現実的になる。 2. ハーネスループの基盤として使う コード生成→テスト実行→修正→再テストのような自律ループを回すエージェントには、高速・低コストな推論が欠かせない。Nano〜Superサイズは特にこの用途にフィットする可能性がある。 3. コスト試算の見直し APIコスト試算をOpenAIやAnthropicのみで行っている現場は、オープンモデルのセルフホスティングとのコスト比較を今のうちに始めるべきだ。規模が大きくなるほどオープンモデルが有利になるケースは多い。 筆者の見解 NVIDIAがモデル自体の競争に本格参入してきたことは評価するが、「エージェント向け設計」という言葉を額面通りに受け取るのはまだ早い。ベンチマーク数値はあくまで参考であり、実際のエージェントループ耐性——長時間タスク中の幻覚率、ツール呼び出しの安定性、多段指示への追従性——は実際に動かして検証しないとわからない。 とはいえ方向性は完全に正しい。今一番アツいテーマはまさにハーネスループだ。エージェントが自律的にループで動き続ける仕組みの設計こそ、2026年に最も投資すべき領域だと思っている。単発の「指示→応答」パターンは役割を終えつつある。「目的を渡せば自分で判断・実行・検証を繰り返す」という設計が本物のAI活用であり、その基盤モデルが複数プレイヤーから出てくることは業界全体にとってプラスだ。 NVIDIAの強みはハードウェアとの一体最適化にある。Nemotron 3をNIM経由でH100/H200上で動かせばトークンあたりのコストと速度が他の追随を許さないレベルになる可能性が高い。この「インフラ込みのパッケージ」こそNVIDIAが他のオープンモデル勢に対して持つ本質的な差別化だ。 AnthropicのClaude Code一択で走っている筆者としては、今すぐ乗り換える理由はないが、エージェントのサブコンポーネント——特にコスト最適化が必要な大量処理パート——にNemotron 3 Nanoを組み込むシナリオは近い将来に十分ありうると思っている。SuperとUltraのリリース後に改めて実測する価値はある。 出典: この記事は NVIDIA Debuts Nemotron 3 Family of Open Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindが2026年4月2日、オープンソースLLMシリーズの最新作「Gemma 4」を発表した。2B・4B・31B・26B-A4B（Mixture-of-Experts）の4モデルがApache 2.0ライセンスで公開され、いずれも画像・動画に対応したマルチモーダルモデルとして登場している。「パラメータ1バイトあたりの知能が史上最高」というGoogleの主張が本当なら、ローカルLLM界隈は一気に盛り上がる。 Gemma 4の技術的な特徴 「E2B」「E4B」——実効パラメータ数という新概念 小さい2モデルには「E2B」「E4B」という表記が使われている。「E」は「Effective（実効）」の意味で、Per-Layer Embeddings（PLE） という技術によるものだ。 通常のLLMはすべてのパラメータが推論計算に使われるが、PLEではデコーダー層ごとに小さな埋め込みテーブルを持たせ、推論時は「高速なルックアップ」で済ませる。テーブル自体は大きいが計算コストが極めて低い——だから「全パラメータ数」と「実効パラメータ数」が乖離する。オンデバイス展開向けのチューニングとして理にかなった設計だ。 マルチモーダルの広がり：画像・動画・音声すべて対応 全モデルが画像・動画をネイティブに処理でき、解像度も可変対応。OCRや図表理解が得意とされる。さらにE2BとE4BはネイティブAudio入力にも対応しており、音声認識・音声理解もモデル単体で扱える。 ただし現時点ではLM StudioやOllamaで音声入力を動かす方法は未確立で、ローカル実行での音声活用はまだ先になりそうだ。 LM Studioでの動作確認 Simon Willisonが実際にGGUF版で検証した結果： モデル ファイルサイズ 動作 E2B 4.41GB ○ 正常 E4B 6.33GB ○ 正常 26B-A4B 17.99GB ○ 正常 31B 19.89GB × ループ出力で破損 31BモデルはGGUFが壊れているようで、すべてのプロンプトに"---\n"を延々と返し続ける状態だった。大きいモデルほど初期リリースの品質ばらつきが出やすいのはローカルLLM界隈でよくある話だが、APIアクセスはAI Studioから可能になっているので、31Bを試したい場合はそちらが現実的だ。 実務への影響——ローカルLLM実用化の加速 Gemma 4が面白いのは「4.41GBのファイル1つで画像も動画も扱えるモデルが動く」という点だ。普通のPCのVRAMやメモリに収まる。 日本のエンジニアやIT管理者が明日から試せるポイントを整理する： 1. LM Studio経由でゼロコスト検証 E2B（4.41GB）・E4B（6.33GB）はLM StudioのGGUFで即動く。クラウドAPIへのアクセスなし、コストゼロで試せる。社内の機密ドキュメントOCRや図表解析の概念実証（PoC）に最適だ。 2. オフライン・エアギャップ環境への展開 Apache 2.0ライセンスかつローカル完結なので、金融・医療・製造業など外部通信が制限された環境でも使いやすい。従来はクラウドAPIなしでマルチモーダルを扱う手段が限られていたが、選択肢が広がった。 3. 26B-A4BのMoEアーキテクチャに注目 Mixture-of-Experts（MoE）は「推論時に全パラメータを使わず、担当の専門家サブネットワークだけを呼び出す」仕組みだ。26Bの規模感でありながら実効4Bレベルの計算コストで動く。コスト効率を重視する実務ユースケースにはこのモデルが主役になりそうだ。 筆者の見解 Googleの実務系AIには正直まだ様子見の姿勢だが、Gemma 4は注目に値する。「パラメータ効率」という研究方向は本物で、これはGoogleに限らず業界全体のホットテーマになっている。小さくても使えるモデルを作る競争は、ローカルLLMの実用化を直接加速させる。Gemma 4の登場は素直に歓迎したい。 気になるのは31BのGGUFがリリース直後に壊れていた点。「史上最高のパラメータ効率」を謳うリリースでモデルファイルが壊れているのはもったいない。とはいえコミュニティがすぐ修正するのもオープンソースの強みなので、致命的な問題ではない。こういう部分の品質を詰めていけば、GemmaシリーズはローカルLLMの有力な選択肢になるポテンシャルがある。 ローカルLLM派の人は今すぐLM Studioで26B-A4Bを試してほしい。17.99GBさえ積めるなら、ラップトップで動くマルチモーダルモデルとしてかなりおもしろい体験ができるはずだ。ガンガン使ってフィードバックを積み上げていくのが今の正しい動き方だと思っている。 出典: この記事は Gemma 4: Byte for byte, the most capable open models の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...