Generative-Ai

OpenAI CEOのサム・アルトマンが、イーロン・マスク氏とOpenAIの将来をめぐる裁判に証人として登場し、マスク氏が設立初期に「自分が完全な支配権を持たなければ営利化には賛成しない」と主張していたと証言した。 2週間の証人尋問を経て、ついに本人が登壇 マスク対OpenAI裁判は、2週間にわたって複数の証人がアルトマン氏に不利な証言を続けてきた。そのクライマックスで、アルトマン氏本人が証言台に立った。 証言でアルトマン氏は「OpenAIは膨大な努力で作り上げた非常に大きな非営利組織だ。盗めるようなものじゃない」と静かに語り、マスク氏については「2回、OpenAIを潰そうとした」と言い切った。証言全体を通じて落ち着いた態度を維持し、陪審員に好印象を与えたと報道されている。 裁判の核心：マスク氏が求めた「完全支配」とは何か OpenAIが営利部門の設立を検討し始めた頃、マスク氏は強硬な条件を突きつけたとされる。アルトマン氏の証言によれば、マスク氏は「自分だけが、間違っているように見えて実は正しい決断を下せる」として、初期段階での完全支配を要求したという。 アルトマン氏はこれを拒否した。理由は明快だ。OpenAIの設立理念が「誰か一人がAGI（汎用人工知能）を支配しないこと」だったからだ。Y Combinatorでの経験から、創業者が優先株式を通じて永久に支配権を維持する構造の危険性を熟知していたアルトマン氏は、後継計画についてマスク氏に問いただした。返ってきた答えは「あまり深く考えていないが、自分が死んだら子供たちに支配権が移るといいかもしれない」というものだったという。 また、この「控えのきかない意思決定者」の例としてアルトマン氏が挙げたのは、マーク・ザッカーバーグ（Meta）ではなく、マスク氏本人とSpaceXだったという事実は示唆深い。 証拠書類が示す信憑性の差 The Vergeの報道が指摘するように、アルトマン氏の証言は複数の当時の文書によって裏付けられている。一方、マスク陣営の証人たちはテキストメッセージと矛盾する証言や、法廷での感情的な場面を見せるなど、信頼性に疑問符がついた。 マスク氏自身も証言中に「滅多に怒らない」と述べた直後、反対尋問で激怒するという場面があったとされ、陪審員へのインパクトは相当なものがあったと推測される。 実務への影響：日本のIT現場でも他人事ではない この裁判は単なるシリコンバレー有名人の私闘ではなく、AI産業のガバナンス（統治）に関する本質的な問いを内包している。日本のIT現場にも以下の点で直接影響しうる。 AI調達リスクの再評価 Azure OpenAI ServiceなどOpenAI技術を組み込んだサービスを採用・検討している企業は、提供企業の組織安定性をリスク因子として改めて評価する必要がある。裁判の結果次第ではOpenAIの意思決定構造や事業継続性に変化が生じる可能性がある。 AIガバナンス規制の先行事例 EUのAI Actを含め、世界各国でAI規制の議論が本格化している。米国の法廷闘争は将来の国際的規制フレームワークに影響を与えうる。日本企業のリスク管理担当者は、この裁判の行方を規制動向の先行指標として注視しておくべきだ。 非営利→営利転換モデルへの疑義 OpenAIが採ってきた「非営利から営利への段階的移行」モデルは、日本のスタートアップや研究機関にも参照されてきた。この裁判はそのモデルが内包するガバナンスの脆弱性を浮き彫りにしており、AIを主軸とした組織設計を考える上での重要な教訓となる。 筆者の見解 この裁判で改めて浮き彫りになったのは「AIの意思決定権を誰が持つべきか」という、技術的であると同時に哲学的な問いだ。 マスク氏が求めた「一人の人間による完全支配」は、個人的野心の問題にとどまらない。強力なAIシステムを誰がどう制御するかという、AI開発の根幹に触れる問題でもある。結局マスク氏は支配権の得られないOpenAIを去り、自分が完全に制御できるxAIを設立した。その判断の是非はともかく、AIを「自分の意志で動かしたい」という衝動の強さは、AI業界全体に通底するテーマでもある。 一方でOpenAIは、誰も支配しないためのAI組織として始まりながら、今や「誰の手に渡るか」を争っているという皮肉な状況にある。組織設計の難しさを改めて実感させられる。 AGIの開発競争が本格化する今、「誰がAIを制御するか」という問いの重要性は増すばかりだ。この裁判を単なる企業間紛争としてではなく、AIガバナンスの試金石として注目し続けたい。 出典: この記事は Sam Altman was winning on the stand, but it might not be enough の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年3月、英科学誌「Nature」に掲載された論文が、AI研究コミュニティに大きな衝撃を与えている。Chris Lu、Cong Lu、Robert Tjarko Lange、Yutaro Yamada らのチームが発表した「AI Scientist」は、科学研究の全プロセス——仮説の立案から実験計画、コーディング、データ分析、論文執筆、さらには査読まで——を一貫して自動化するパイプラインだ。そして驚くべきことに、このシステムが生成した論文が、トップクラスの機械学習学会ワークショップの初回査読を通過している（当該ワークショップの採択率は70%）。 AI Scientistの仕組み AI Scientistは、複数の基盤モデル（Foundation Model）を組み合わせた複雑なエージェントシステムとして設計されている。研究の自動化フローは以下の通りだ。 アイデア生成（Ideation）: 既存の研究を参照しながら、新たな仮説・研究テーマを自律的に生成する 文献調査（Literature Search）: 関連論文を自動収集・整理し、研究の文脈を把握する 実験計画・実装: コードを自動生成し、実験を設計・実行する データ分析・可視化: 実験結果をグラフ化し、定量的に分析する 論文執筆: 導入・手法・結果・考察を含む完全な学術論文を執筆する 自己査読（Self Peer Review）: 完成した論文の品質を自律的に評価・レビューする システムには2つの動作モードが用意されている。フォーカスモードでは、人間が提供したコードテンプレートを足がかりとして特定テーマを深掘りする。オープンエンドモードでは、テンプレートなしにエージェントが自律的に広範な科学探索を行う。どちらのモードも、多様なアイデアを生成し、それを自動でテスト・評価・報告するループを自律的に回し続ける。 なぜこれが重要か——「再帰的自己改善」の実現に向けた一歩 この研究の最大の意義は、AI自身がAI研究を加速する「再帰的自己改善ループ」の実現可能性を具体的に示したことにある。 従来、AIは特定の作業を補助するツールに過ぎなかった。化学構造の発見、数学的証明の支援、タンパク質の立体構造予測（AlphaFold）などは、いずれも研究の「一部」を担うものだった。しかしAI Scientistは、研究という知的営みの全サイクルを自律的に完結させる。これはパラダイムシフトを意味する。 特に注目すべきは、このシステムが「副操縦士（Copilot）」としてではなく「自律エージェント」として機能している点だ。人間が逐一確認・承認を求められる設計ではなく、目的を与えれば自律的に判断・実行・検証のループを繰り返す。 もちろん課題もある。論文著者自身が指摘するように、AI生成論文の増加は次のリスクを伴う。 既に疲弊している査読システムへの負荷増大 科学的文献へのノイズ混入 AI生成の誤情報の伝播リスク これらは真剣に受け止めるべき問題だ。 実務への影響——日本のエンジニア・研究者にとっての意味 研究開発部門のAI活用が加速する AI Scientistのようなシステムは、今すぐ一般企業が直接導入できるものではないが、その設計思想は実務に直結する。「仮説→実験→評価→改善」のサイクルをAIが自律的に回す構造は、ソフトウェア開発のテスト自動化やCI/CDパイプラインと本質的に同じだ。日本企業のR&D部門でも、この考え方を取り入れた自律型研究支援エージェントの構築が今後の重要テーマになるだろう。 エンジニアが今日から意識すべきこと エージェントのループ設計を学ぶ: AI Scientistの核心は「AIが自律的にループを回す」仕組みにある。この設計思想は、現在市場に出回っている多くのAI開発フレームワークにも応用できる 複数Foundation Modelの組み合わせ: 単一モデルではなく複数の基盤モデルを組み合わせて複雑なパイプラインを構築するアーキテクチャは、エンタープライズAI活用の標準パターンになりつつある 評価・検証の自動化: 実験結果の自動評価という考え方は、MLモデルの品質管理や社内ドキュメントの自動レビューにも転用可能だ 研究者コミュニティへの影響 日本の大学・研究機関でも、AI支援による研究加速への注目が高まるだろう。ただし、AI生成論文の扱いに関するガイドライン整備は急務だ。NatureにAI Scientistの論文が掲載されたこと自体、科学コミュニティがこのテーマを正面から議論し始めたシグナルとして重要な意味を持つ。 筆者の見解 AI Scientistが示したものは、「AIが仕事を奪う」という陳腐な議論ではなく、「AIが科学的発見のサイクルを根本的に変える」という質的な転換だ。 筆者が最近最も注目しているのは「ハーネスループ」という概念——AIエージェントが自律的に判断・実行・検証を繰り返し続ける仕組みだ。AI Scientistはまさにこの考え方を科学研究に適用した先駆的な事例である。単発の「質問→回答」ではなく、AIが自律的なループを設計・実行できるかどうかが、ツールの本質的な価値を分ける分水嶺になる。 一方で冷静に見ておきたいのは、AI Scientistが通過したのは「採択率70%のワークショップ」であるという点だ。成果として誇張されやすい数字だが、これは入口に過ぎない。研究の「量産」が可能になった先で、「質」の基準をどう保つかという問いは、科学コミュニティ全体が腰を据えて取り組むべき課題だ。 それでも、自律エージェントが科学的発見を担う未来への扉が開かれたことは間違いない。このループが正しく設計・管理されれば、人類の知の蓄積速度は文字通り桁違いに変わる可能性がある。AI Scientistを「すごい実験」で終わらせず、そのアーキテクチャの思想から何を学ぶかが、今のエンジニアに問われている。 出典: この記事は Towards end-to-end automation of AI research の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

GoogleはGoogle I/O 2026（5月20日週開催予定）に先立ち、Gemini AIをAndroidの基盤に深く統合する大型アップデートを発表した。単なるチャットボット機能を超え、スマートフォン・ブラウザ・カーナビ・ノートPCをまたいでアプリを操作する「インテリジェンスレイヤー」への転換を明確に打ち出した形だ。 「OSからインテリジェンスシステムへ」 Androidエコシステムを統括するサミア・サマット氏は「私たちはオペレーティングシステムからインテリジェンスシステムへ移行している」と宣言した。今回発表された機能群の中心は Gemini Intelligence と呼ばれる仕組みで、以下のような体験を実現する。 アプリ横断タスク自動化: Gmailから情報を取得し、Instacartのショッピングカートを構築し、飲食店の予約を完了させるといった複数ステップの処理を単一の指示で遂行 コンテキスト認識: 画面上の内容をリアルタイムに把握し、今ユーザーが何をしているかを理解した上で動作 スマートChrome for Android: ブラウザ上の検索・閲覧体験へのAI深層統合 Android Auto刷新: 車載体験の再設計 包括的なセキュリティ機能群 発表の場では「BBQのゲストリストを見てメニューを提案し、食材リストをInstacartに追加し、チェックアウト前に確認を返す」という具体例が示された。これはAIエージェントの実用性をエンドユーザーに見せる上でわかりやすいデモだ。 「人間は常にループの中に」—— 制御とプライバシーの設計 エージェント型AIが自律的に動くことへの懸念に対し、サマット氏は「取引を完了する前に必ずユーザーに確認を求める。人間は常にループの中にいる」と強調した。Geminiが「何を見られるか」「どこで動作できるか」「いつ確認が必要か」をユーザーが設定できる設計を売りにしており、プライバシーと利便性のバランスを訴求している。 対応デバイスは今夏からSamsung Galaxy最新機種とGoogle Pixelを皮切りに順次拡大される予定。 Apple iOS 27「Extensions」との正面衝突 今回の発表はAppleへの先手という側面も強い。AppleはWWDC 2026（6月予定）でiOS 27を発表する見込みで、Apple IntelligenceのバックエンドとしてGoogleやAnthropicなどサードパーティAIプロバイダーを選択できる「Extensions」機能の実装が報じられている。 興味深いのは、GoogleがAppleとのGemini供給契約をすでに4ヶ月前に結んでいる点だ。GeminiはAndroid上での独自展開と、Apple Intelligence経由でのiOS展開という両軸で動いている。競合プラットフォームを支えながら自社OSの優位性も訴求するという、複雑な立ち位置での競争となっている。 日本のIT現場への影響 日本でもAndroidは高いシェアを持ち、Samsung・Sony Xperia・Sharp AQUOSなど幅広いデバイスが採用している。今回の変化が実務に与える影響として、以下を押さえておきたい。 モバイルアプリ開発者へ Gemini IntelligenceはサードパーティアプリとのAPI連携を前提に設計されている。Instacartとの統合例が示すように、自社アプリがGeminiのコンテキスト認識と連携するためのIntent設計やAPI対応を早期に検討しておく価値がある。Android Auto刷新に合わせた車載アプリの更新も視野に入れておきたい。 企業IT管理者へ Gemini IntelligenceがGmailなどGoogle Workspaceと連携してタスクを実行する場合、社内データへのアクセス権限設計が重要になる。MDM（モバイルデバイス管理）でGeminiの動作スコープをどう制御するかは、セキュリティポリシーの観点から今のうちに整理しておくべきポイントだ。 筆者の見解 「OSからインテリジェンスシステムへ」という表現はキャッチーだが、本質をよく突いている。AIエージェントの意義は単発の質問応答ではなく、複数ステップを自律的に遂行することにある。Googleがその方向に舵を切ったこと自体は、モバイルプラットフォームの進化として素直に評価できる動きだ。 一方で「人間は常にループの中に」という設計思想については少し考えさせられる。確認ステップを挟むこと自体は安全性の観点から合理的だが、確認の頻度と粒度の設計次第でユーザー体験は大きく変わる。毎回の確認が増えすぎると、便利なエージェントではなく「承認申請フォーム」になってしまう。AIエージェントとしての実力差は、「どこまでユーザーが安心して任せられるか」というトラスト設計に現れてくる。この点でGoogleが今後どのようにチューニングしていくかが注目点だ。 AppleがExtensionsでサードパーティAIを受け入れるとすれば、プラットフォーム競争の軸は「モデル単体の性能」から「AIとOSの統合品質」へとシフトする。スマートフォン上のAI体験をめぐる競争は、2026年後半にかけてかなり具体的な形で見えてくるはずだ。 出典: この記事は Google races to put Gemini at the center of Android before Apple’s AI reboot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Cactusが開発した26Mパラメータの関数呼び出し特化モデル「Needle」がオープンソース公開され、スマートフォンや時計・メガネといったコンシューマーデバイス上でもAIエージェントの中核機能を実用的な速度で動かせることが示された。 なぜこんなに小さいのか——「ツール呼び出しはReasoningではない」 Needleは、GeminiのツールコーリングCapabilityを蒸留して生まれた2,600万パラメータのモデルだ。一般的なLLM（数十億〜数百億パラメータ）と比べて桁違いに小さいが、その背景には明確な設計思想がある。 Cactusの主張はシンプルだ。「クエリに合ったツール名を探し、引数の値を抽出し、JSONを出力する」という作業は、推論（Reasoning）ではなく検索と組み立て（Retrieval-and-Assembly）である。この処理にはCross-Attentionが本質的に必要であり、FFN（Feed-Forward Network）層に詰め込まれた大量のパラメータは完全に無駄になるという。 そこでNeedleは「Simple Attention Networks（単純アテンションネットワーク）」というアーキテクチャを採用。エンコーダーとデコーダーからなる構造だが、MLPを一切排除しアテンションとゲーティングのみで構成されている（d=512、8ヘッド/4KVアテンション、BPE語彙数8192）。 性能と学習コスト Needleの数字は説得力がある： プリフィル速度：6,000 トークン/秒（コンシューマー端末上） デコード速度：1,200 トークン/秒（コンシューマー端末上） 事前学習：16台のTPU v6eで27時間（200Bトークン） 後学習：わずか45分（合成データ2Bトークン） ベンチマークでもFunctionGemma-270M、Qwen-0.6B、Granite-350M、LFM2.5-350Mをシングルショット関数呼び出しで上回った。ただし、Needleは会話能力や汎用推論を持たない。エージェント全体のオーケストレーターではなく「ツールルーター」として位置づけるのが正確だ。 RAGや検索拡張生成にも応用できる可能性 Cactusが示したもう一つの発見は、この知見の一般化だ。「外部の構造化知識が入力として提供される場合、モデルはFFNで事実を記憶する必要がない」という。RAG（Retrieval-Augmented Generation）のように外部知識をコンテキストとして与えるシステム全般に、同様のアーキテクチャが有効だという仮説を提示しており、追加の実験結果も近く公開予定とのことだ。 実務への影響——日本のエンジニアが明日から使えるヒント エッジAIエージェントの2段構えアーキテクチャ：スマートフォンアプリやIoTデバイスでAIエージェント機能を実装する際、ツールルーティング専用に超軽量モデルを使い、複雑な推論はクラウド側の大型モデルに委ねるという分担が現実的になった。レイテンシと費用の両面でメリットがある。 ローカルでのファインチューニング：NeedleはMac/PCで自前データを使ってファインチューニング可能だ。社内固有のAPIやツール定義を学習させれば、社内AIアシスタントのツール呼び出し精度向上に活用できる可能性がある。 出典: この記事は Show HN: Needle: We Distilled Gemini Tool Calling into a 26M Model の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIスタートアップのAdaptionが、AIモデルが自律的にファインチューニングを実行できる新ツール「AutoScientist」を発表した。従来は高度な専門知識を持つMLエンジニアが手作業で行っていたモデルの能力拡張プロセスを自動化し、特定タスクへの適応速度を大幅に向上させることを目標としている。 AutoScientistが解決しようとしている課題 ファインチューニングとは、大規模言語モデル（LLM）を特定の用途や能力に特化させるための追加学習プロセスだ。GPT-4oやClaude 3.5 Sonnetのような汎用高性能モデルであっても、特定業界の専門用語・社内独自の処理フロー・製品固有の知識には対応しきれないケースが多い。 従来の手法では以下が必要だった： データセットの設計・収集・ラベリング — 質の高い学習データを人手で用意する工程 学習パラメータの調整 — 学習率・エポック数・バッチサイズなどのハイパーパラメータを専門家が試行錯誤で決定 性能評価の繰り返し — 改善サイクルごとに専門知識を持つエンジニアが評価・判断 AutoScientistはこのサイクルを自動化する。モデルが「何が苦手か」を自己診断し、必要な学習データを自動生成・収集し、パラメータを調整しながら学習ループを回す——このプロセスを人間の介入を最小化しながら完結させることを目指している。 「モデルが自分を訓練する」という発想の意味 「models train themselves（モデルが自分自身を訓練する）」というフレーズは、単なるマーケティング文句ではない。これはAI研究の最前線で進んでいる自動化機械学習（AutoML）や自動実験設計の流れと同じ方向性を持つ。 従来のAI開発では人間がボトルネックになっていた。Adaptionの AutoScientistはそのボトルネックをAI自身が担うことで、MLエンジニアを抱えていない組織でも「自社に最適化したモデル」を現実的なコストで手に入れられる未来を描いている。 実務への影響：日本のエンジニアが押さえておくべきこと ファインチューニングの民主化が始まりつつある 現時点では、日本の多くの企業がファインチューニング自体をまだ試せていない段階だ。しかしAutoScientistのような自動化ツールが成熟すると、MLの専門知識がなくても「自社業務に特化したモデル」を構築できる環境が整ってくる。今のうちに自社のユースケースを整理しておく価値がある。 自動化が進んでも人間の役割は残る データ品質の管理: 学習の基盤となるデータの品質は依然として人間の責任範囲 評価軸の設計: 「何で成功を測るか」を定義しなければ、自律的な改善ループは方向を失う セキュリティ境界の管理: 自動学習ループが社内機密データを誤って学習しないよう、境界設計が重要 コスト計算への組み込み: 自動ファインチューニングは計算コストを消費する。ROI試算に学習コストを忘れずに含める 今すぐできる準備 自社で「汎用LLMでは精度が足りない」と感じているタスクをリストアップする そのタスクに必要な学習データが社内に存在するか確認する ファインチューニングの評価指標（何をもって「改善した」と言えるか）を定義する 筆者の見解 「モデルが自分で訓練する」という仕組みは、筆者が今最も注目している「ハーネスループ」の考え方と本質的に同じ方向を向いている。AIエージェントが自律的に判断・実行・検証を繰り返すループを設計することが、AI活用の次のフロンティアだと考えている。AutoScientistはそのアプローチをモデル訓練そのものに適用したものだ。 「人間が何かをするたびにAIに確認を求め続ける設計」ではなく、「AIが自律的にループを回して能力を獲得する設計」——AIエージェントの本来あるべき姿に近い方向性だと思う。 ただし、実際のプロダクトがどこまで実現できているかはこれから見極める必要がある。「自律的な学習ループ」は理論的には美しいが、実装の品質は千差万別だ。過学習の検知、評価指標のドリフト、セキュリティ境界の管理など、解決すべき課題は山積している。 日本のIT現場では、まだほとんどの企業が汎用LLMの活用基盤を固める段階にある。AutoScientistのような自動化ツールが本格普及するまでには時間がかかるだろうが、「モデルの自律的な能力獲得」というトレンドが始まりつつあることは確かだ。今後の動向を注意深く見守りたい。 出典: この記事は Adaption aims big with AutoScientist, an AI tool that helps models train themselves の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フィンテック企業Rampが自社クライアントの実支出データをもとに集計した調査で、Anthropicのサービスに課金している法人企業の割合が34.4%となり、OpenAI（32.3%）を上回って初の首位に立ったことが明らかになった。 「アンケート」ではなく「クレジットカードの実支出」が示す数字 Rampは中小〜大企業向けの法人カード・経費管理プラットフォームだ。この調査の特徴は、アンケートへの回答ではなく、クライアント企業が実際に支払った経費データを匿名集計している点にある。「使ってみたい」という意向調査でも「知名度」のランキングでもなく、財布を実際に開いた企業の比率という点で、実態に近い数字と見てよい。 結果は Anthropic 34.4%、OpenAI 32.3%。差は約2ポイントとわずかだが、かつてOpenAIが圧倒的シェアを誇っていた法人向けAI市場において、この逆転は象徴的な意味を持つ。 なぜAnthropicが伸びたのか いくつかの要因が考えられる。 開発者・エンジニア組織からの底上げ: Claude Codeをはじめとするコーディング支援ツールが開発チームに広まり、そこからAPIの法人契約へと転換するケースが増えたと見られる。エンジニアが「これは使える」と感じたものが、やがて部門・会社の正式調達に昇格する流れは珍しくない。 API品質とドキュメントの継続的改善: コンテキスト長の拡張、APIの安定性向上、ドキュメントの充実など、エンタープライズ採用の障壁を下げる取り組みが着実に積み重なった。 安全性・コンプライアンスへの訴求力: 企業の情報セキュリティ担当者にとって、AIプロバイダーの倫理的ポジションや説明責任は重要な選定基準だ。Anthropicの「Constitutional AI」アプローチは、この評価軸で一定の説得力を持っている。 実務への影響：日本のIT組織に問いかけること 調達・評価フェーズにある企業へ 「AIといえばOpenAI」という前提で導入を進めている組織は、一度立ち止まって再評価してほしい。AnthropicのAPIとOpenAIのAPIは互換性の高い部分も多く、特定ユースケースの並行検証はそれほど難しくない。コスト・品質・コンプライアンス・サポート体制の観点から、自社ワークロードに合った選択肢を選ぶべきタイミングに来ている。 開発チームのリーダーへ 開発者がすでに個人利用しているツールが法人契約への足がかりになるケースは増えている。エンジニアが何を使っているかを把握し、組織として正式に評価・採用するプロセスを整備しておくことが、AIガバナンスの観点からも重要だ。 IT調達担当者へ 「OpenAI一択」から「複数プロバイダーのポートフォリオ」への移行は、ベンダーロックインリスクを下げる上で合理的な戦略だ。料金体系・利用規約・データ処理ポリシーを比較し、用途ごとに最適なプロバイダーを使い分ける体制を整える価値がある。 筆者の見解 この数字が示すのは、法人AI市場が「OpenAI一強時代」から「複数プレイヤーが競い合う時代」へと本格的に移行しつつあるということだ。 筆者自身がAnthropicのツールを積極的に活用している立場なので、ここは贔屓目にならないよう意識して書く。重要なのは「どのベンダーが優れているか」ではなく、「自社の課題と制約に最も合ったプロバイダーを、実際に検証した上で選んでいるか」だ。かつては「OpenAIのAPIを使っておけばまず間違いない」という経験則があったが、その前提を更新すべきタイミングは今だと思っている。 一方で、この文脈でMicrosoftに触れないわけにもいかない。Microsoft 365 Copilotはここで語られているAPIベースの市場とは別のレイヤーで戦っているが、「業務システムと深く統合されたAI」という独自の強みは本物だ。その強みを最大限に活かすためにも、AI品質の底上げに正面から取り組んでほしい──応援しているからこそ、そこは率直に言いたい。 AnthropicとOpenAIの競争が激化しているということは、日本のIT組織にとってはむしろポジティブな変化だ。選択肢が増え、競争が品質とコストの両面を改善する。今こそ自社のAI調達戦略を体系的に見直す機会と捉えてほしい。 出典: この記事は Anthropic now has more business customers than OpenAI, according to Ramp data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Amazonが、Alexa+を基盤とするAIショッピングアシスタント「Alexa for Shopping」を検索バーに統合し、音声・タッチ操作で商品の選定から購入までを自動化できる新機能の提供を開始した。 Alexa for Shoppingとは 「Alexa for Shopping」はAmazonの検索バーに組み込まれたAIアシスタント機能で、Alexa+の大規模言語モデルを活用している。利用者はテキスト入力だけでなく、音声でも商品の検索・比較・購入が可能だ。対応デバイスはモバイルアプリ、デスクトップ、Echo Showスマートディスプレイと幅広くカバーする。 従来の検索と何が違うか 従来のAmazon検索は「キーワード → 結果一覧 → ユーザーが選ぶ」という受動的な体験だった。Alexa for Shoppingはこのフローを大きく変える。 自然言語での要件入力: 「来月の旅行に使うキャリーバッグで、機内持ち込みサイズ・軽量のもの」のように条件を会話形式で伝えられる パーソナライズされたレコメンド: 過去の購買履歴・好み・予算に基づいて候補を絞り込む Amazon以外のECにも対応: Amazon.comだけでなく、他のオンライン小売も横断して選択肢を提示できる 自動化指向: 単なる検索支援にとどまらず、購買フロー自体を代行する方向へ進化 Echo Showとの統合により、キッチンや居間からハンズフリーで買い物ができる体験も強化されている。 日本のEC・IT現場への影響 日本ではAmazon.co.jpが国内最大規模のECプラットフォームの一つであり、この機能が日本展開された場合の影響は大きい。 ECサービス開発者への示唆：自然言語検索・AIレコメンドはもはや「付加機能」ではなくインフラになりつつある。キーワード検索UIのみに頼るサービスは競争力を失う可能性がある。 企業調達担当者への示唆：AIアシスタントが購買決定に介在する時代が来ると、ビジネス購買でも「AIが選んだ提案から選ぶ」フローが主流になりうる。ベンダーとのリレーション構築の前提が変わるかもしれない。 消費者行動の変化：検索→比較→決定というプロセスがAIによって短縮・自動化される。ECサイトのUI/UXやマーケティング戦略全体に再考を迫る動きだ。 実務での活用ポイント Amazon Business（法人向けAmazon）との連携が進めば、経費申請・コスト管理・承認フローと連動した購買自動化が現実になる Echo ShowをオフィスやSOHO環境に置いておけば、音声での備品発注が実用化できる 今のうちにAlexa for Shoppingの挙動を試し、どこまで自律的に動くか・どこで人間の確認が必要かを把握しておくと、業務プロセス設計の参考になる 筆者の見解 今回の発表で注目すべきは、単なるチャットUI追加にとどまらず、「副操縦士的なレコメンド」から「購買フローを自律的に動かすエージェント」へのシフトを狙っている点だ。「候補を出すから人間が選んでください」という設計ではなく、「要件を伝えれば後はやっておく」という方向への進化が見える。 Amazonはリコメンデーションエンジンとして長年のノウハウを持つ会社であり、その上にAlexa+の言語理解能力を組み合わせる戦略は理にかなっている。 一方で気になるのはプライバシーとのトレードオフだ。パーソナライズが高度になるほど、購買データ・行動履歴・音声データの活用範囲が広がる。日本のユーザーや企業は利便性とデータ管理のバランスについて、サービス利用前に方針を整理しておくことをお勧めしたい。 AIエージェントが購買判断に深く関与する世界は確実に近づいている。自社サービスや業務フローがその波にどう乗るか、今年・来年のうちに考え始めておくのが賢明な準備だろう。 出典: この記事は Amazon launches an AI shopping assistant for the search bar, powered by Alexa+ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年5月13日、中小企業向けの新サービス「Claude for Small Business」を発表した。同社の業務自動化プラットフォーム「Claude Cowork」に新たなトグルとして組み込まれ、簿記管理・業務インサイト・広告クリエイティブ生成といった機能を提供するほか、QuickBooks、Canva、DocuSign、HubSpot、PayPalなど主要SaaSとの連携を実現する。 大企業中心だったAI採用、ついに中小企業へ これまでのAI活用は、潤沢なITバジェットを持つ大企業が中心だった。パイロット段階を超えて本格稼働させているのは大規模企業が多いという調査結果が相次いでいたが、中小・中堅企業での採用も徐々に広がりを見せている。Anthropicはこの変化を好機と捉え、「チャットウィンドウで止まっている」中小企業のAI活用を一歩前に進める仕組みを提供する。 同社の発表によれば、米国の中小企業はGDPの44%を生み出し、民間雇用者数の約半数を抱える経済の根幹だ。にもかかわらず、AIのツールや研修は大企業向けに設計されていることが多く、中小企業に最適化されたものはほとんどなかったという。 Claude Coworkを軸にした統合型アプローチ 今回の発表の核は、既存サービス「Claude Cowork」への機能追加だ。Claude Coworkはウェブブラウズ、ファイル管理、マルチステップワークフローの自動実行が可能な業務自動化プラットフォームで、有料ユーザーは新トグルをオンにするだけで中小企業向けの機能群にアクセスできる。 主な機能は以下の通り： 簿記・会計支援：QuickBooksとの連携により、日常的な経理業務を自動化 業務インサイト：HubSpotなどのデータを活用した経営状況の可視化 広告クリエイティブ生成：Canvaとの連携でマーケティング素材をAIで生成 契約・決済連携：DocuSignやPayPalとの統合で業務フロー全体をカバー 注目すべきは「トグルひとつで有効化」というシンプルな導入体験だ。専任のIT担当者がいない中小企業でも導入ハードルを下げる設計思想が明確に見える。 OpenAIとの競合、そして10都市ツアー AIプラットフォーム競争においてAnthropicはOpenAIの後を追う形だ。OpenAIはすでに2023年末にEnterprise ChatGPTを投入し、中小チーム向けの「ChatGPT Business」も展開している。 Anthropicは機能発表に加え、シカゴを皮切りに全10都市で「無料AIトレーニングワークショップ」を開催する計画を明らかにした。各都市で地元の中小企業リーダー100名を対象に実施するリアルイベント戦略は、ブランド認知と実際の導入障壁の両方を同時に解消しようとする動きだ。デジタル広告一辺倒ではなく、フィジカルなタッチポイントを重視している点は興味深い。 日本のIT現場への示唆 日本でも中小企業のAI導入遅れは深刻な課題だ。ツールの使い方がわからない、英語インターフェースへの心理的ハードル、そもそも何から始めればいいかわからない——という声は今でも多い。 Claude for Small Businessが示すようなアプローチ（既存業務ソフトへの統合、シンプルなオンボーディング、業務に溶け込むUI設計）は、日本市場向けサービスを開発するうえでも参考になる設計思想だ。エンジニアやIT管理者にとっては、既存のSaaS環境（会計・CRM・契約管理）をAIでつなぐ統合基盤として何を選ぶかという選定軸を考える良い機会でもある。 国内では弥生・freee・kintone・Salesforceなどが主流だが、これらとAIエージェントを接続するアーキテクチャを設計する際、「会計・CRM・契約・決済を横断してエージェントが自律的に動く」という今回のAnthropicの設計はひとつの参照モデルになりうる。 筆者の見解 今回の発表で注目したいのは、「AIが自律的にビジネスを動かす」という流れが大企業だけでなく中小企業にも波及しはじめたという点だ。 AIプラットフォームの競争軸は明らかに変わっている。エンタープライズ向けの機能比較から、「いかにスムーズに業務フローへ溶け込めるか」「ITリテラシーが高くないユーザーでも使えるか」という体験の勝負に移行しつつある。QuickBooksやPayPalとの連携を初手で揃えてきたのは、この方向性を強く意識した選択だろう。 AIを使うために業務プロセスを変える時代から、業務プロセスの中にAIが自然に存在する時代へ——この転換が本当に起きるかどうかは、中小企業のオーナーが「便利すぎて使わないと損」と感じられるかどうかにかかっている。リアルイベント戦略はその点でも理にかなっており、技術の話よりも成功体験の共有が先決という判断は正しいと思う。 日本でも同様のサービスが登場する流れは加速するだろう。重要なのは「禁止より仕組み」という発想だ。AIを禁止するアプローチは必ず失敗し、公式に提供されたものが一番便利と感じる状況を作ることが、企業内でのAI活用を健全に広げる唯一の道になる。業務を自動化する「仕組み」を設計できる人材の価値が、これからさらに高まることは間違いない。 出典: この記事は Anthropic courts a new kind of customer: small business owners の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Origin Labは2026年5月、ビデオゲーム会社が保有するデジタル資産をAIの「ワールドモデル」学習データとして販売できるマーケットプレイスを構築するため、Lightspeed Ventures主導で800万ドルのシード資金を調達した。SV Angel、Eniac、Seven Stars、FPVが参加し、Twitch共同創業者のKevin LinとCruise創業者のKyle Vogtもエンジェル投資家として名を連ねている。 ワールドモデルとは何か、なぜデータが不足しているのか 大規模言語モデル（LLM）はインターネット上の膨大なテキストデータを学習することで急速に進化した。しかし、AIがロボットを操作したり、物理空間内の物体の動きを予測したりするために必要な「ワールドモデル」の開発は、別の壁に直面している。物理世界の動作データが圧倒的に少ないのだ。 ヤン・ルカン（Meta AIチーフサイエンティスト）が率いるAMI Labsや、フェイフェイ・リーのWorld Labsなど、物理世界を理解するAIの開発を進める各社は、適切な学習データの調達に苦労してきた。現実世界でセンサーやカメラを使ってデータを収集する方法では、コストと時間がかかりすぎる。 ゲームが「物理シミュレーターの宝庫」である理由 Origin Labが着目したのは、ビデオゲームの本質的な特性だ。現代のゲームエンジンは、重力・摩擦・衝突・流体など、物理世界の法則を忠実に再現するシミュレーション環境を備えている。キャラクターの動き、物体の落下、車両の挙動──これらすべてが数値化されたデータとして存在する。 「AIシステムが物理世界の仕組みや物の動き方を理解するためのデータは、本質的にビデオゲームの中に存在する」と、共同CEOのAnne-Margot Rodde氏はTechCrunchに語っている。 Origin Labは単なるデータ仲介に留まらず、ゲームアセットをAIラボが扱えるフォーマットに変換する役割も担う。単純なレンダリング処理から、数時間分のウォークスルー映像の自動生成まで、変換の複雑さはデータの種類によって異なる。 ライセンス問題という「大人の事情」を解決する ゲームデータへの関心はAIラボの間で以前からあったが、ライセンスと品質の問題が常に障壁になってきた。 2024年12月、OpenAIのSora（動画生成モデル）が人気ゲームのプレイ映像を無断で学習に使用していた疑惑が浮上し、業界で物議を醸した。AmazonもTwitchのストリーミング映像を学習データとして活用することへの関心を公言しているが、権利処理の複雑さは変わらない。 Origin Labはゲーム会社とAIラボ双方が参加するライセンス取引の基盤を構築することで、この「灰色地帯」を合法的なビジネスに転換しようとしている。ゲーム会社にとっては既存資産から新たな収益源を得られる。AIラボにとっては高品質かつ法的にクリアな訓練データを調達できる。 投資を主導したLightspeedの見方 今回の投資を主導したLightspeed VenturesのFaraz Fatemi氏は、Scale AIなどデータベンダーが主要AIラボへの供給で急成長を遂げた例を引き合いに出す。「データベンダーの収益拡大がいかに急激なものかを目の当たりにしてきた。主要ラボはどこもデータがボトルネックになっている」と語る。ゲーム業界とAI業界の両方に知見を持つ投資家が名を連ねている点は、このマーケットの現実的な需要を示している。 実務への影響 ゲーム会社・デベロッパー: 過去に作成した3Dアセット、モーションデータ、物理シミュレーションデータが新たな収益源になる可能性がある。自社IPの価値を見直す機会でもある。権利クリアな形でマネタイズできるプラットフォームが整備されつつあることは注目しておきたい。 AIエンジニア・研究者: ワールドモデル分野に関わる場合、今後こうしたデータマーケットプレイスが訓練データ調達の主要チャネルになっていく。データソースの多様化と品質評価の方法論を今から整理しておくべきだ。 企業のAI導入担当者: 現在の生成AIブームはテキスト・画像が中心だが、物理世界を扱うAI（ロボティクス、デジタルツイン、自動運転など）が次のフェーズに入りつつある。そのインフラ整備が進んでいることを把握しておきたい。 筆者の見解 今回のOrigin Labの取り組みで興味深いのは、「データ問題の解き方」の構造にある。 LLMの時代は、インターネット上の無数のテキストを半ば強引にかき集めることで成立してきた面があった。しかしそのやり方は権利問題と品質問題の両方で行き詰まりを見せている。OpenAIのSoraの件はその象徴的な出来事だった。 Origin Labが提案するのは、最初からライセンスを明確にした上でデータ取引を行う「正しい構造」だ。データ提供者には対価が支払われ、AIラボは法的リスクなく高品質なデータを使える。こういう仕組みが最初から整備されていればよかったわけで、遅まきながらもこの方向に進むことは評価できる。 ゲームという「物理シミュレーションの副産物」に着目したアイデアも面白い。ゲーム会社が膨大なコストをかけて作り上げた物理エンジンの恩恵を、AI開発が受ける形になる。一方でゲーム会社も既存資産から新たな収益を得られる。こういうWin-Winの構造設計は、データ経済の成熟を示すものだと思う。 ワールドモデルはロボティクスや自動運転の基盤技術として注目されている分野で、ここ1〜2年で急速に投資が集まっている。LLMでテキスト系AIが成熟しつつある今、次のフロンティアを考えるとき、物理世界を理解するAIは有力な候補の一つだ。Origin Labのようなデータインフラを担うスタートアップが正当な評価を受ける時代が来ていると感じている。 出典: この記事は Origin Lab raises $8M to help video game companies sell data to world-model builders の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AnthropicのClaude CodeおよびCowork担当プロダクト責任者であるCat Wu氏が、サンフランシスコで開催された第2回「Code with Claude」カンファレンスにおいてTechCrunchのインタビューに応じ、AIの次なる大きな進化は「プロアクティビティ（先読み能力）」だと語った。 競合を追わず、「指数曲線に乗り続ける」 Wu氏がまず強調したのは、製品戦略における競合意識の排除だ。「競合他社を意識し始めると、常に数週間から1カ月遅れの状態で走り続けることになる。それはフロンティアに留まる最善策ではない」と語り、チーム全体に「AIは指数的に改善し続ける」という前提を徹底しているという。 この姿勢の背景には、Anthropicの好調な事業環境がある。最新の報告によれば、Anthropicは2025年5月以降にビジネス顧客のシェアを4倍に拡大し、エンタープライズ向けのAI利用においてOpenAIを逆転したとされる。評価額は約9,500億ドル規模の資金調達を視野に入れるレベルに達しており、まさに「追われる立場」への転換点にある。 急ピッチなモデルリリースと、非公開の「Mythos」 昨年6本以上のモデルを公開し、今年もそのペースに迫るAnthropicだが、Wu氏はこのリリース速度を維持する姿勢を示した。ただし、すべてのモデルが一般公開されるわけではない。 4月に発表されたイニシアチブ「Glasswing」では、Amazon・Apple・CrowdStrike・Microsoftなど一部のパートナー企業のみが、サイバーセキュリティ特化モデル「Mythos」へのアクセスを許可されている。Mythosはコードベースの脆弱性を自動検出する能力を持ち、Anthropic自身が「悪意ある利用に転用されるリスクが高い」と判断して一般公開を見送った。AIモデルのリリースが単なる機能競争にとどまらず、安全性の設計を含む複雑な意思決定を伴うことを改めて示している。 エージェント管理時代の現実：専門性は依然として必須 Wu氏は以前のインタビューで「未来の仕事は人間がエージェントの群れを管理する形になる」と発言しており、今回も同じ考えを深掘りした。 「エージェントを効果的に管理するには、自分でその仕事ができる専門性が不可欠です。エージェントがなぜミスをしたのか、指示の解釈を誤ったのか、要件の定義が不足していたのか、それをデバッグする力が必要です」 つまり、AIエージェントの登場によって「仕事を知らなくてもAIに任せればいい」という状況が生まれるわけではなく、むしろドメイン知識を持つ上位の人間がより重要になるという逆説的な未来像だ。エージェントの管理は人材マネジメントと本質的に同じ構造を持つ、というWu氏の見立ては示唆に富む。 チームの縮小については「理想は全員がより多くのことを達成できる状態」と語るにとどめ、「インターンが不要になる」という問いに対する直接的な答えは避けた。しかし方向性として、少人数で大きな成果を出せる組織への移行は不可避だという認識は透けて見える。 実務への影響：日本のエンジニア・IT管理者へ ① AIエージェント導入は「専門家が設計する」前提で考える 「AIに丸投げ」ではなく、ドメイン知識を持つエンジニアがエージェントの目標・制約・検証基準を設計する役割を担う。この「エージェント設計者」のスキルが今後数年で最も価値を持つ職能のひとつになるだろう。 ② プロアクティブAIへの備え Wu氏が語る「ユーザーが気づく前にニーズを先読みするAI」は、現時点では展望に過ぎないが、Claude Codeのような開発ツールはすでにその方向に進化している。「タスクを指示する」から「目的を渡して委任する」へのワークフロー転換を今から意識しておくと、波に乗り遅れない。 ③ Glasswingモデルのような非公開AIの存在を把握する サイバーセキュリティ領域では、一般公開されないモデルが企業パートナー限定で展開される流れが始まっている。自社のセキュリティ戦略にAIを組み込む場合、公開モデルだけでなくパートナーシップ経由のアクセスも視野に入れる必要が出てくる。 筆者の見解 「指数曲線に乗り続ける」というWu氏の言葉は、製品開発哲学として非常に健全だと思う。競合の動きに反応し続ける開発体制は、リソースを分散させ判断を遅らせる。自分たちの軸を持ち、ユーザー価値の最大化だけを見る姿勢は、長期的な信頼に繋がる。 「プロアクティブAI」という概念も、方向性としては正しいと感じている。現状の多くのAIツールは「聞かれたら答える」か、あるいは「確認を求め続ける」かのどちらかだ。真に実務の負担を下げるには、人間が指示を出す前に状況を読んで動けるエージェントが必要で、それはハーネスループ的な自律的継続実行の仕組みと深く関わってくる。 Wu氏が「エージェント管理には専門性が要る」と言い切った点も重要だ。AIが実務に入り込むほど、「AIが何をしているかを理解できる人間」の価値は下がるどころか上がる。日本企業が「AIに任せる」だけで終わらず、設計・監督の役割を内製化できるかどうかが、中長期の競争力を左右するだろう。Anthropicがこの方向を製品として具体化していく過程は、引き続き注目に値する。 出典: この記事は Anthropic’s Cat Wu says that, in the future, AI will anticipate your needs before you know what they are の内容をもとに、筆者の見解を加えて独自に執筆したものです。

イーロン・マスク氏が率いるxAIは、AIモデル「Grok」の訓練に使用するミシシッピ州のデータセンター「Colossus 2」で、約50基のガスタービン発電機を大気汚染許可なしに稼働させているとして訴訟に発展している。xAIは当該タービンを「モバイル（移動式）」機器として分類することで、恒久設備に課せられる環境規制の適用を回避していたとされる。 Colossus 2と「モバイル」ガスタービンの問題 AI開発の急加速を支えるため、大規模なデータセンターの電力需要は急増している。xAIがミシシッピ州に構築したColossus 2は、GrokモデルのトレーニングとAI推論インフラを担う大型施設だ。 問題の核心は電力調達の方法にある。電力グリッドからの安定供給が間に合わない中、xAIは大量のガスタービン発電機を現地に設置して独自に電力を確保する方法を採った。ここで「モバイル発電機」という分類を活用することで、米国環境保護庁（EPA）や州の大気汚染規制における固定発生源への許可申請を不要とした——少なくとも、そう主張していた。 しかし現実には、数十基のタービンが事実上の恒久的な電源として稼働を続けており、周辺住民はその排気による大気汚染を懸念。地元環境団体や住民が訴訟を提起し、正式な許可取得と排出基準の遵守を求めている。 なぜこれが重要か この問題はxAIだけの問題ではない。大型AIモデルのトレーニングに必要な電力量は、従来のデータセンター常識を大きく超えており、電力インフラとの整合を取ることが業界全体の課題になっている。 米国では、AI需要によるデータセンターの急増が電力グリッドに大きな負荷を与えており、新規接続のキューが数年待ちになるケースも珍しくない。この状況下で、一部のAI企業が電力調達のためにグレーな手法を取るリスクが高まっている。 日本でもこの問題は無縁ではない。国内AI・クラウドインフラへの投資拡大が続く中、電力調達の透明性や環境コンプライアンスは、今後のデータセンター立地選定に関わる重要課題となってくる。 実務への影響 電力コストとコンプライアンスリスクを同時に評価する クラウドサービスやAI基盤を選定する際、単純なコストや性能だけでなく、そのインフラがどのような電力調達で動いているかを確認することが重要性を増している。環境規制違反が発覚した場合、サービス停止や行政処分が利用企業のビジネスにも波及するリスクがある。 オンプレミスAIインフラの電源設計にも同様の観点を 社内でGPUクラスタを運用する場合も、仮設発電機の「恒久利用」は多くの国で規制の対象になる。日本でも大気汚染防止法の観点から、発電機の用途と設置期間には留意が必要だ。設備投資計画の段階から電力調達の合法性を確認する体制を整えておきたい。 AI投資の環境コストを経営レベルで把握する ESG観点でのAIインフラ評価は今後ますます重要になる。利用するAIサービスのカーボンフットプリントや電力源の開示を求める機運も強まっており、調達基準への組み込みを検討する価値がある。 筆者の見解 AI開発競争の激化が「速度優先・規制後回し」という姿勢を生み出すのは理解できる。しかし「モバイル発電機」という分類を利用した規制回避が常態化すれば、許可制度そのものへの不信を招き、最終的にはAI産業全体への規制強化というブーメランとなって返ってくる。 技術者として法の抜け穴を活用することと法の精神を守ることの違いは、明確に意識しておきたい。「できるかどうか」と「やっていいかどうか」は別の問いだ。 より根本的な問題として、核融合・小型モジュール炉（SMR）・再生可能エネルギーなど次世代電源への本格的な取り組みなしに、AI開発の持続可能性は担保できない。電力問題はもはやインフラチームだけの話ではなく、AI開発の設計思想そのものに関わるテーマだ。今回の訴訟が、業界全体がエネルギー戦略を正面から議論するきっかけになることを期待したい。 出典: この記事は Musk’s xAI is running nearly 50 gas turbines unchecked at its Mississippi data center の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google のAIチャットボット Gemini が、実在する個人の電話番号をカスタマーサービス情報として提示するケースが相次いでいることが報告されている。被害者には対抗手段がほぼなく、深刻なプライバシー問題として注目されている。 実際に何が起きているのか Redditへの投稿によると、ある男性の携帯電話に「弁護士」「プロダクトデザイナー」「鍵師」を探す見知らぬ人からの電話が1ヶ月にわたり殺到した。Google の生成AIが誤って自分の番号を案内していたという。 より詳細が確認できる事例として、イスラエルのソフトウェアエンジニア Daniel Abraham氏（28歳）のケースがある。2026年3月、見知らぬ人物からWhatsAppに「PayBox（イスラエルの決済アプリ）のアカウントで助けが必要」というメッセージが届いた。調べると、Geminiがそのユーザーに「PayBoxのカスタマーサービスにWhatsAppで連絡を」と案内し、Abraham氏の個人番号を提示していたことが判明した。Abraham氏はPayBoxとは無関係であり、PayBoxもWhatsApp番号によるサポートは提供していないことが確認されている。 ワシントン大学の博士課程学生が、Geminiを操作して同僚の個人携帯番号を取得できた事例も報告されており、問題の広がりを示している。 なぜ電話番号が漏れるのか 専門家が指摘する最も有力な原因は、学習データに含まれる個人を特定できる情報（PII: Personally Identifiable Information） だ。大規模言語モデルはウェブ上のテキストを学習データとして取り込む。個人の電話番号がブログ、ビジネスディレクトリ、フォーラム、ソーシャルメディアに公開されていれば、それがモデルに学習される可能性がある。 実際の問題は大きく2種類に分けられる： 正確な情報の意図しない開示: 実在する番号が、まったく無関係な文脈で提示される もっともらしい誤情報の生成: 別の人物の番号を間違った文脈で提示する「ハルシネーション（幻覚）」型 どちらも被害者にとっては同様に深刻な結果をもたらす。 7ヶ月でAIプライバシー相談が400%増 個人情報削除支援サービスを提供するDeleteMeによると、生成AI関連のプライバシー相談が過去7ヶ月で400%増加し、数千件規模に達している。内訳はChatGPT関連が55%、Gemini関連が20%、Claude関連が15%、その他が10%。ChatGPTが最多とはいえ、今回集中的に報告されているのはGemini絡みのケースだ。 この数字は氷山の一角と考えるべきだ。Redditや専門家への相談に至らず、泣き寝入りしている被害者がはるかに多い可能性がある。 実務への影響——日本のエンジニア・IT担当者はどうすべきか 企業・IT管理者の観点 社員の連絡先情報がAIに学習されるリスクは、規模を問わずあらゆる企業に存在する。特にビジネスディレクトリへの登録、LinkedInなどのプロフィール、お問い合わせフォームで担当者の電話番号を公開している組織は注意が必要だ。 今日から取れる対策: 自社名・社員名を主要AIチャットボット（Gemini、ChatGPT等）で検索し、どのような情報が提示されるかを定期的に確認する ウェブ公開する連絡先情報を最小限に絞り、直通番号ではなくフォーム経由の問い合わせに切り替えることを検討する 「自分の名前でAI検索してみる」習慣を社員に周知する 個人エンジニアの観点 GitHubのコミット、技術ブログ、カンファレンス登壇資料など、エンジニアは無意識に多くの個人情報をウェブ上に公開している。それらがトレーニングデータに取り込まれる可能性を念頭に置くべきだ。 残念ながら、一度学習されてしまった情報を削除させる公式ルートは現時点でほぼ存在しない。EUのGDPR（忘れられる権利）も、LLMの学習データからの実際の削除については実効性が低いのが現状だ。日本の個人情報保護法についても同様の課題がある。 筆者の見解 今回のGoogle Geminiの事例を「ハルシネーション問題の一形態」として片付けるのは適切ではない。実在する個人の電話番号が意図しない文脈で流通し、被害者に具体的な不利益（迷惑電話の殺到、個人情報の意図しない開示）をもたらしている。これはもはやUXの問題ではなく、安全性の問題だ。 「AIが攻撃側に使われる時代」という観点で見ると、今回のケースは比較的善意の誤動作だが、悪意ある利用者が同じ仕組みを使って標的の連絡先を入手しようとする可能性も排除できない。AIの能力が向上するほど、こうしたプライバシーリスクも複雑化する。 解決策として「AIに情報を出力させないよう禁止する」アプローチには限界がある。学習済みの情報を特定条件下で出力しないよう制御することは、現時点では技術的に非常に難しい。だからこそ、「情報の出し方を変える」側での対策——公開情報の粒度を意識的に管理し、AIに学習させたくない情報はそもそも公開しない——という原則が重要になる。 AI各社も対策を進めているはずだが、プライバシー侵害相談が7ヶ月で400%増という数字が示す通り、対策の速度が被害の拡大に追いついていない。出力時のPII検出強化、ユーザーからの削除申請プロセスの整備など、技術と制度の両面での取り組みを加速する段階に来ている。日本の企業のIT部門も、「社員の情報がAIに出てくる可能性がある」という前提でリスク管理の議論を始める時期だ。 出典: この記事は AI chatbots are giving out people’s real phone numbers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Meta CEO マーク・ザッカーバーグは、Meta AI アシスタントに新機能「Incognito Chat（インコグニトチャット）」を追加すると発表した。会話ログをサーバーに一切保存しない「初のメジャーAI製品」と自社で主張しており、AI チャットのプライバシー問題に一石を投じる形となっている。 Incognito Chat とは何か Incognito Chat は、AI との会話内容をユーザーのチャット履歴にも、Meta のサーバーにも保存しない機能だ。ザッカーバーグは「会話ログがサーバーに保存されない最初のメジャーAI製品」と述べており、プライバシー保護を前面に押し出したアピールとなっている。 ChatGPT の「一時チャット」機能など、他の AI チャットボットにも類似のシークレットモードは存在する。Meta が主張する差別化ポイントは「サーバーサイドでもログを一切保持しない」という点で、単にユーザーの表示履歴から消えるだけでなく、Meta 側のシステムにも記録が残らない設計だとしている。 なぜ今、プライバシーへの注力なのか Meta といえば、2018年のケンブリッジ・アナリティカ問題をはじめ、ユーザーデータの扱いをめぐって長年批判を受けてきた経緯がある。AI の普及とともに新たな論点として浮上したのが「AI モデルの学習データ」問題だ。ユーザーが AI と交わした会話がモデルの学習に使われるのではないかという懸念は世界中で広がっており、特に企業ユーザーが業務上の機密情報を AI に入力することへのリスクとして注目されている。 Incognito Chat は、こうした懸念に対する Meta の回答のひとつと見てよい。 日本のエンジニア・IT管理者への影響 AI ツール利用ポリシーの再検討材料に 日本企業の多くは、社員が業務で AI チャットを使用することに対し、情報セキュリティの観点から制限を設けている。「入力した情報がどこに保存されるのか」という疑問は、現場で AI 導入を検討する際に必ず出てくる問いだ。 「ゼロログ」を謳う機能が主要な AI 製品で標準化されていけば、企業の AI 利用ポリシーにおけるリスク評価の前提が変わってくる可能性がある。個人情報保護法や社内規程の観点でも、「ログが残らない AI」という選択肢は今後の検討項目として押さえておくべきだろう。 「主張を鵜呑みにしない」姿勢が重要 「サーバーにログを保存しない」という主張は、それが本当に技術的に担保されているかどうかをユーザー側が独立して検証することが難しい。End-to-End 暗号化の実装有無、ログ削除の粒度（メタデータは？）、第三者監査の有無といった具体的な仕様の開示が今後求められる。 企業として Meta AI を業務利用する場合は、こうした技術仕様の詳細を確認した上で、自社のデータ管理ポリシーと照らし合わせて判断することが不可欠だ。「ゼロログ」という言葉だけを根拠に利用ポリシーを緩和するのは時期尚早と言わざるを得ない。 筆者の見解 今回の Incognito Chat の発表は、方向性としては正しいと思う。AI チャットにおけるプライバシー保護は業界全体の課題であり、「ゼロログ」の仕組みをメジャーな AI 製品として前面に打ち出すことで、業界標準が引き上げられる可能性がある。競合他社への圧力となり、ユーザーにとってプライバシー保護が「当たり前」になっていく流れを作れるなら、それ自体は歓迎すべきことだ。 懸念があるとすれば、「ゼロログ」の主張の透明性だ。Meta はこれまで、ユーザーデータの取り扱いをめぐって信頼を損なう出来事を繰り返してきた経緯がある。「言っていること」と「実際の実装」が一致しているかどうか、技術仕様の詳細な開示と第三者による継続的な検証が伴わなければ、プライバシーを重視するユーザーや企業が Meta AI を積極的に選ぶ状況にはなりにくい。 プライバシーへの真剣な取り組みは、発表だけでなく長期的な実績で証明されるものだ。この機能が「本物」であることを実際の行動で示し続けることができれば、AI 市場における Meta の立ち位置も変わってくるはずだ。一過性のアピールに終わらず、透明性の高い実装と運用が続くことを期待したい。 ...

GoogleのサンダーCEOが2026年5月、同社内で書かれる新規コードの75%がすでにAI生成であると発表した。昨秋の50%から急上昇しており、エンジニアがコードを「書く存在」から「レビューする存在」へとシフトしている実態が数字で示された形だ。 50%から75%へ——わずか半年で25ポイント増 ピチャイCEOによれば、GoogleはすでにAIがコードの大部分を生成する段階に達しており、エンジニアはそのAI生成コードをレビューし、活用する役割を担うようになっている。昨秋（2025年秋）時点でのAI生成コード比率は50%とされていたが、半年足らずで75%に達したということは、年間換算で50ポイント近い上昇ペースになる計算だ。 この数字は「試験的な取り組み」や「一部ツールの活用」ではない。Googleの全エンジニアリング活動における主流のワークフローとしてAI生成が定着したことを意味する。 AIがコードを書き、人間がレビューする時代へ 従来のソフトウェア開発は「人間がコードを書き、他の人間がレビューする」というモデルだった。しかしGoogleが体現しているのは「AIがコードを書き、人間がレビューして判断する」というモデルへの移行だ。 この転換は表面的には「ツールが変わった」だけに見えるが、実態はエンジニアに求められるスキルセットの根本的な変化を意味する。 変わること： コードを0から書く能力よりも、AI生成コードを読み・評価し・改善する能力が重視される ボイラープレートや反復的なコード記述が人間の主業務ではなくなる コードレビューの対象が「人間が書いたコード」から「AIが書いたコード」に変わる 変わらないこと： システム設計・アーキテクチャの判断 ビジネス要件とコードを橋渡しする能力 AI生成コードが正しいかどうかを見抜く技術的理解力 実務への影響——日本のエンジニアが今考えるべきこと 採用・育成モデルの見直しが急務 この流れは日本のIT企業にも直撃する。大量の新人エンジニアを採用して「まず基礎からコーディング研修」というモデルは再考が必要だ。AIがコードを生成する時代において「コードを書ける人」よりも「AIが生成したコードを評価・改善できる人」の価値が上がる。 新人育成においても「コードを書く訓練」より「コードを読んで判断する訓練」「AIへの的確な指示の出し方」を中心に据えるべき段階に来ている。 エンジニアに求められる新しい素養 AIへの指示設計力（プロンプトエンジニアリング）: 何を作るか、どう作るかをAIに的確に伝える能力 AI生成コードのレビュー眼: 一見きれいに見えても、ロジックの誤りや境界条件の見落としがある。見抜く力が重要になる システム思考: 個別のコードよりも、全体のアーキテクチャや設計の整合性を判断する能力 開発組織の構造変化 75%という数字が示すのは、今後の開発組織に必要な「コードを書くためのヘッドカウント」が大幅に変わりうるということだ。採用する人数よりも採用する人の質（AIと協働できる能力）が問われる時代に本格的に入った。 筆者の見解 Googleがこの数字を公表したこと自体、業界に対するある種のシグナルとして読むべきだろう。Googleほどのエンジニアリング組織が「コードの4分の3はAIが書いている」と公言した事実は、AI活用が特定のスタートアップや先端企業の話ではなく、大規模な本番開発組織の日常になったことを意味する。 率直に言えば、この変化のスピードは日本のIT業界の多くが想定しているよりはるかに速い。「AI活用を検討中」「パイロット導入を進めている」という段階の組織が、気づいたときには大きな生産性格差の中に置かれる可能性がある。 「仕組みを作る少数の人間と、その仕組みを使ってAIが回す」という構図は、もはや概念論ではなくGoogleという実例で現実になっている。毎年恒例の一括採用で大人数を集め、数年かけて一人前のエンジニアに育てるというモデルは、このスピード感とかみ合っていない部分が出てきている。 重要なのはAI生成コード比率の数字を追うことではない。「AIが書いたコードを適切に判断できる人間をどう育てるか」という問いに今すぐ向き合うことだ。コードを書ける人材から、コードを理解して判断できる人材へ——この転換を組織として設計できるかどうかが、次の3〜5年の競争力を左右する。 出典: この記事は Google CEO: 75% of all new code at Google is now AI-generated の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは2026年5月11日、リアルタイム音声APIに新たな3つのモデルを追加した。GPT-Realtime-2（GPT-5クラスの推論対応）、GPT-Realtime-Translate（70言語以上のリアルタイム翻訳）、GPT-Realtime-Whisper（ストリーミング音声文字起こし）の3本立てで、音声AIエージェントの実用化に向けた大きな前進となる。 GPT-Realtime-2：音声と推論の融合 今回の目玉はGPT-Realtime-2だ。OpenAI初の「推論能力を持つライブ音声モデル」であり、GPT-5相当の処理能力を音声インタラクション中に発揮できる。 前モデル（GPT-Realtime-1.5）からの主な強化点は以下の通り。 コンテキストウィンドウ: 32,000トークンから128,000トークンに拡張（4倍） 推論量の調整: minimal / low（デフォルト）/ medium / high / very high の5段階 並行ツール呼び出し: 「カレンダーを確認中です」「今調べています」のような音声ステータス通知付きで複数ツールを同時実行 会話割り込みへの対応: 進行中の会話を中断・再開しながら処理を継続 ドメイン特化語彙の理解: 固有名詞や医療用語への対応強化 プリアンブル対応: 「少し確認しますね」のような短いフレーズを処理前に発話可能 コンテキストウィンドウの128K拡張は特に重要で、長い会話セッション全体を保持したまま処理できる。1時間超の商談や複雑なサポート対話にも耐えられるキャパシティだ。 GPT-Realtime-Translate：70言語超のリアルタイム翻訳 GPT-Realtime-Translateは70以上の入力言語から13の出力言語へのリアルタイム翻訳に対応する。話者のペースに追従しながら翻訳するため、国際的なカスタマーサポート、ライブイベント、教育プラットフォーム、グローバル向けクリエイターツールでの活用が想定されている。 Deutsche TelekomはすでにAPIを多言語カスタマーサポートで試験運用中。Vimeoは動画再生中のリアルタイム翻訳のPoCを進めており、商用利用に向けた評価が着々と進んでいる。 GPT-Realtime-Whisper：低遅延ストリーミング文字起こし GPT-Realtime-Whisperは発話と同時に文字起こしを行う低遅延ストリーミングモデル。ライブ字幕、会議中のリアルタイムメモ更新、音声アシスタントのバックエンド処理、カスタマーサポート・医療・営業分野の事後ワークフローなど、幅広い用途に対応する。 価格・安全性・コンプライアンス モデル 料金 GPT-Realtime-2（音声入力） $32 / 100万トークン GPT-Realtime-2（キャッシュ済み入力） $0.40 / 100万トークン GPT-Realtime-2（音声出力） $64 / 100万トークン GPT-Realtime-Translate $0.034 / 分 GPT-Realtime-Whisper $0.017 / 分 セーフティ面では、コンテンツポリシー違反の会話をリアルタイムで検出・停止するアクティブ分類器を内蔵。Agents SDKを使った追加ガードレールの実装も可能だ。EUデータレジデンシーにも対応しており、欧州拠点のアプリケーションでも企業プライバシー基準を満たせる。なお、利用ポリシー上、開発者はユーザーに対してAIと対話していることを通知する義務がある（文脈上明らかな場合を除く）。 実務への影響 日本のエンジニア・IT管理者にとっての意味を整理しよう。 コールセンター・カスタマーサポート領域: GPT-Realtime-2とGPT-Realtime-Translateを組み合わせると、多言語対応の音声AIエージェントが現実的なコストで構築できる。インバウンド対応が多い観光・EC・グローバルサポート業界は特に検討価値が高い。 会議・議事録ツール: GPT-Realtime-WhisperはAPIとして提供されるため、既存システムへの組み込みが容易。Microsoft TeamsやZoom連携アドオンの形で活用できる場面も多いはずだ。 音声AIエージェントの設計: 128Kのコンテキストウィンドウは、エージェントが長期セッションをリフレッシュなしに保持できることを意味する。自律ループを前提としたエージェント設計が、音声UIでも現実的になってきた。 コスト管理の注意点: GPT-Realtime-2の音声出力が$64/100万トークンと高めなため、大量処理を前提とするシステムではキャッシュ活用（$0.40/100万トークン）の設計が必須。WhisperやTranslateはタイムベース課金なのでコスト予測が立てやすく、まずこちらからPoC開始するのが現実的だ。 筆者の見解 AIが「聴きながら話す」時代が、いよいよAPIレベルで実用段階に入ってきた。 今回のリリースで特に注目しているのは、GPT-Realtime-2が「推論」と「音声」を統合した点だ。従来の音声AIは「聞いて返す」という単純な往復通信だったが、ここに推論ループが組み込まれることで、エージェントが自律的に判断・ツール実行・確認を繰り返すハーネスループの設計が音声UIでも可能になる。単発の指示→応答ではなく、会話しながら自律的に動く——この変化は見た目以上に大きい。 翻訳モデルのGPT-Realtime-Translateも、国際カンファレンスや多言語サポートの場面で実用性が高そうだ。70言語入力対応かつリアルタイムというスペックは、既存の商用翻訳サービスと十分に競合できる水準に見える。 ...

医療AI企業のTruveta（ワシントン州ベルビュー）とKnit Health（サンフランシスコ）が2026年5月12日、次世代臨床AIの共同開発に向けた提携を発表した。Truvetaが保有する1億3000万人以上の実世界EHR（電子健康記録）データと、Knit Healthが開発する大規模臨床行動モデル（LCBM: Large Clinical Behavior Model）を組み合わせ、医療現場の意思決定を根本から変革することを目指す。 「静的なガイドライン」から「動的な診療経路」へ この提携の最大の特徴は、Knit HealthのLCBMが従来のルールベースの臨床ガイドラインとは根本的に異なるアプローチを採用している点にある。 従来の医療AIの多くは、専門家が設計した静的なルールセットや決定木に基づいて動作する。これに対してLCBMは、実際の医師や医療チームが日々行っている無数の臨床判断のパターンを学習し、「次に患者がどこへ行くべきか」「現実の制約の中でどのアクションが最も効果的か」「別の診療経路を選択した場合にアウトカムはどう変わるか」を動的に予測するモデルだ。 Knit HealthのCEO Jonathan Kolstad氏は「医師が意思決定するたびに、私たちのモデルはより賢くなる」と語っており、継続的学習サイクルがモデルの中核設計思想となっている。 Truveta Dataが提供する「信頼できる基盤」 LCBMの学習基盤となるTruveta Dataは、単なるデータ量の問題ではない。その品質保証の仕組みが医療AIとして重要な差別化要因となっている。 1億3000万人以上の非識別化EHRデータ（毎日更新） 臨床ノートと画像データを含む クローズドクレーム、死亡記録、社会的健康決定要因（SDOH）と縦断的にリンク 文書化されたデータ来歴（provenance）と厳格な品質管理 規制対応可能な監査証跡 「規制グレード」という表現が示すように、このデータは単なる研究用途だけでなく、FDAへの申請など規制プロセスに耐えうる品質水準で整備されている。これは医療AIが社会実装される際の最大のハードルのひとつをクリアしていることを意味する。 3つの重点領域 今回の提携が最初に注力する領域は以下の3つだ： 専門医へのルーティングと紹介最適化 — 患者が適切な専門医に早期にたどり着けるよう、紹介経路の意思決定を支援する 患者フローと病床管理の予測 — 待機時間を削減し、医療リソースへのアクセス改善を実現する 診療経路の最適化 — より迅速で一貫した臨床判断を支援する Knit HealthのLCBMは「インフラ層」として設計されており、ルーティング判断・退院予測・ケアチーム配置・紹介、そして最終的にはすべての臨床ワークフローの下に位置づけられる。臨床医がすでに実践しているワークフローに組み込まれる形で動作するため、現場への導入摩擦を最小化する設計思想でもある。 日本の医療IT現場への影響 日本の医療機関では、電子カルテシステム（HIS/EMR）の普及は進んでいるものの、そこに蓄積されたデータを臨床判断支援に活用できているケースはまだ限られている。今回のTruveta・Knit Health提携が示すアーキテクチャは、日本の医療ITが次のステージへ進む際の参照モデルとして注目に値する。 エンジニア・IT管理者が今日から考えるべきポイント： データ品質の整備が先決: LCBMのような高度なモデルも、元のEHRデータが散在・不整合では機能しない。データガバナンスと標準化（HL7 FHIR等）の整備が将来の臨床AI導入の前提条件になる 「インフラ層」という設計思想: 臨床AIを独立したアプリケーションではなく、既存ワークフローの下に敷くインフラとして位置づけるアプローチは、日本の医療機関の現場抵抗を最小化するうえで参考になる 継続的学習サイクルの仕組み化: 一度デプロイして終わりではなく、現場の判断データが継続的にモデルに還流される設計がなければ、時間とともに性能が陳腐化する 筆者の見解 この提携で注目したいのは、LCBMというモデルのアーキテクチャ哲学だ。「静的なガイドライン」ではなく「実際の医師の行動から動的に学習するモデル」という設計は、AIエージェントの本質的な価値がどこにあるかを改めて示している。 人間が事前に設計したルールに縛られるのではなく、実世界の膨大な意思決定の集積から「次の最善手」を導き出す——この思想はクリニカルAIに限らず、企業のITオペレーション、サプライチェーン管理、カスタマーサポートなど、あらゆる複雑な意思決定ドメインに応用できる原理だ。 医療はAIが社会実装される際に最もハードルが高い領域のひとつだ。プライバシー規制、医師の責任問題、エラーが人命に直結するリスク。Truvetaが「規制グレード」のデータ品質にこだわり、Knit HealthがLCBMを「インフラ層」として既存ワークフローに組み込む設計にしているのは、そのハードルを正面から越えようとする姿勢の現れだ。 日本において医療AIの社会実装が欧米に比べて遅れている最大の要因は、技術力ではなくデータ基盤の整備状況にある。今回の提携が示すようなデータガバナンスの仕組みを、日本の医療機関も真剣に構築していかなければ、数年後には圧倒的な実力差がついてしまう可能性がある。 医療AIの分野では「仕組みを設計できる人間」の価値が急速に高まっている。現場医師の経験と勘を「学習可能なデータ」に変換し、継続的に改善するループを回し続けるインフラをどう作るか——これが今後10年の医療IT領域の中心的なテーマになるだろう。 出典: この記事は Truveta and Knit Health announce collaboration to power a new generation of clinical AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Snap CEOのEvan Spiegelが2026年5月、約1,000名のレイオフを発表した。その理由として公式に挙げたのが「AIが新規コードの65%以上を生成している」という事実であり、年間5億ドル超のコスト削減を見込む。同時期にIBMが発表した調査レポートは、2,000社以上のうち76%がCAIO（Chief AI Officer、最高AI責任者）を新設済みと報告しており、この動きが個別事例ではないことを裏付けている。 「CAIO」が生まれた背景 企業のC-suiteにはすでに、CTO（最高技術責任者）・CIO（最高情報責任者）・CDO（最高データ責任者）という技術系役職が存在する。それでも「AI専門のポジション」が求められる理由はどこにあるのか。 市場調査会社OmdiaのチーフアナリストLian Jye Su氏は、AIの企業導入に固有の課題が既存役職の管轄をまたぐためだと説明する。インフラ整備、ガバナンス設計、業務プロセスとの統合、ワークフローの現代化——これらを一括して担う役職が明確に存在しなかった。 IBMのアジア太平洋担当ゼネラルマネージャーHans Dekkers氏はこう整理する。「CIO・CTO・CDOがそれぞれ技術・イノベーション・インフラ・データを担うのに対し、CAIOの職責はAIが企業全体の業務・意思決定・実行をどう変えるかに集中している」。 実際、HSBCやLloyds Banking GroupといったグローバルFinTech・金融大手がCAIOポジションを採用し始めている。 急成長する数字の意味 IBMの調査で特に目を引くのは伸び率だ。2025年時点でCAIOを設置していた企業は26%にとどまっていたが、2026年にはそれが76%に達した。1年で約3倍という急増ぶりは、「AI戦略を誰が責任を持つか」という問いに対して、多くの企業が答えを出し始めたことを示している。 一方で、すべての専門家が楽観的なわけではない。Gartnerのアドバイザリーディレクター、Jonathan Tabah氏は「CAIOを見たことはある。主流になるとは思わない」と率直に語る。新たなC-suite役職の設置にはコストが伴い、それを正当化できない規模の企業も多い。 McKinseyのパートナー、Vivek Lath氏はより本質的な視点を提示する。「重要なのは特定の肩書きではなく、AI取り組みを企業全体で集中調整する体制だ」。「CAIOを置くかどうか」より「AI変革の責任をどこに置くか」が問われているという指摘だ。 見落とされがちな「CHRO」の存在感 IBMのレポートにはもう一つ注目すべき発見がある。回答者の59%が「CHRO（最高人事責任者）の影響力が今後拡大する」と予測している。 AIが人間の業務をどう再定義するかという問いに答えるのは、技術者だけでは不十分だ。人材戦略、スキルの再設計、組織構造の見直し——これらを担うCHROの役割が、AI変革において不可欠になる。Snapのレイオフも、単なる人員削減ではなく「AIと人間の役割分担を組織レベルで再設計している」という文脈で読み解くと、CHROの存在感が増す理由がよく分かる。 日本のIT現場への影響 「AIが生産性を上げる」は体感として理解できても、「だから組織構造を変える」に踏み込んでいる日本企業はまだ少数だ。 CAIOをすぐに新設する必要はないにしても、「AI導入の意思決定と責任を誰が持つか」を明確にすることは急務だ。CIOに丸投げするには専門性が追いつかず、現場任せでは統制が効かない。既存の役職者に「AIガバナンスの責任」を明示的に割り当てる——それが現実的な第一歩になる。 また、Snapの事例はエンジニア採用計画を再考するきっかけになりうる。「AIが65%のコードを書く」環境では、必要なエンジニアの像が変わる。大量採用よりも、AIを設計・活用・管理できる少数の精鋭を育てる方向へシフトする企業が、2〜3年後に優位に立つだろう。 筆者の見解 IBMの調査とSnapの事例が同時期に出てきたことには、象徴的な意味がある。「AIが業務効率を上げる」という話は数年前から続いてきたが、今回は「だから組織の頂点に専任役職を置く」「だから人員構成を変える」という段階に移っている。AIが「使うツール」から「組織の構造を変える力」へと転換した転換点として、後から振り返られる時期かもしれない。 日本企業の多くはまだこの変化の規模を実感できていないと感じる。「AIを試してみました」の段階で満足している間に、海外企業は組織そのものを再設計している。IT業界でこのような差がつく展開を、過去にも何度か見てきた。 「CAIOという肩書きが必要か」という議論より、「AI変革を誰が率いるのかが明確か」の方がはるかに重要な問いだ。肩書きがなくても、機能として誰かが担うべき領域がある。それが棚上げのまま「全社でAI活用を推進」と言っても、実態は個人の努力に依存するだけで、組織としての競争力にはならない。 2026年のIT経営において、AIへの組織的な姿勢は「戦略オプション」ではなく「必須の経営課題」になった。この認識の切り替えを、できるだけ早く行うことが求められている。 出典: この記事は Snap CEO announces layoff of ~1,000 employees, cites rapid AI advancements の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのThreat Intelligence Group（GTIG）は2026年5月11日、ハッカーグループがAIモデル「OpenClaw」を活用して二要素認証を迂回するゼロデイ脆弱性を発見・悪用しようとした「大規模悪用イベント」の計画を阻止したと発表した。AIが実際のサイバー攻撃の計画・実行に使われたことを公式に確認した初事例として、セキュリティ業界全体に警戒感が広がっている。 ゼロデイをAIで「自動発見」——何が起きたのか ゼロデイ脆弱性とは、ソフトウェアの開発者自身もその存在を知らないセキュリティの穴のことだ。通常、こうした脆弱性の発見には高度な専門知識と多大な時間が必要とされる。しかし今回Googleが報告したケースでは、ハッカーグループがAIモデル「OpenClaw」を使ってゼロデイ脆弱性を自動的に発見し、二要素認証（2FA）を迂回する攻撃手法の開発にまで至っていたとされる。 GTIGは「高い確信を持って」この事実を確認したと述べている。犯罪組織は発見した脆弱性を「大規模な悪用イベント」——多数の標的に対する同時大量攻撃——に使う計画だったが、Googleの先手を打った対策によって阻止できた可能性が高いという。ハッカーグループの名称は非公開とされた。なお、GoogleはGeminiが今回の攻撃に使用されたとは考えていないと明言している。 中国・北朝鮮も「AI脆弱性探索」に強い関心 今回の報告書でGoogleが強調しているのは、特定の1グループの問題ではないという点だ。中国および北朝鮮と連携するとされるハッカーグループが「AI活用による脆弱性発見に強い関心を示している」と明記されており、国家レベルの脅威アクターがAIをサイバー兵器として積極的に取り込もうとしている実態が浮き彫りになった。 業界の対応——AnthropicのMythos延期とOpenAIの限定公開 AI各社もこの流れに対して慎重な姿勢を見せ始めている。 Anthropicは4月、新モデル「Mythos」のリリースを延期した。理由は、犯罪者や国家レベルの敵対者が数十年前から存在するソフトウェアの脆弱性を悪用するためにモデルを利用する懸念だ。この判断はホワイトハウスでの緊急会合を引き起こすほどの衝撃を業界に与えた。現在MythosはApple、CrowdStrike、Microsoft、Palo Alto Networksを含む限定テスターグループにのみ公開されている。 一方OpenAIは最新モデルの派生版「GPT-5.5-Cyber」を、審査済みのサイバーセキュリティチーム向けに限定プレビューとして提供開始すると発表している。防御側がAIを使いこなすための環境整備として評価できる動きだ。 実務への影響——日本のIT現場は今すぐ何をすべきか この発表が意味するのは、「いつかAIを使った攻撃が来るかもしれない」という仮定の議論が終わったということだ。すでに現実として起きており、攻撃の規模と速度は従来の手動手法と比べて桁違いになりうる。 二要素認証の過信をやめる 今回の攻撃は2FAを迂回するゼロデイを標的にしていた。2FAは引き続き重要な防御手段だが、それだけで安全と思い込むのは危険だ。ゼロトラストアーキテクチャへの本格移行を検討すべき時期に来ている。 パッチ管理の自動化・加速 AIが脆弱性を自動発見する時代では、脆弱性公開からパッチ適用までのウィンドウが極端に短くなる。手動でのパッチ管理プロセスは今すぐ見直し、自動化・優先順位付けを行う体制を整えるべきだ。 防御側もAIを活用する 攻撃者がAIを使って自動的に脆弱性を探す以上、防御側も同等以上の速度で対応するためにAIを活用しなければならない。EDR/XDRの導入状況を見直し、AI支援型の脅威検知・対応能力を高めることが急務だ。 筆者の見解 「AIを使ったサイバー攻撃」は長らく「将来の懸念」として語られてきたが、今回Googleが公式に確認したことで、その議論は終わりを告げた。現実の脅威として組織全体で対処しなければならない段階に入った。 この状況で陥りやすい間違いが、「AIの使用を制限・禁止する」方向に走ることだ。攻撃者はすでに使っている。防御側が制限している間に、攻撃側は着々と能力を高める。AIを禁じるのではなく、安全に使いこなせる仕組みを組織の内側に構築することが正しい方向だ。 注目すべきはAnthropicがモデルのリリース延期という慎重な判断を行いながら、CrowdStrikeやMicrosoftといった防御側のリーダー企業を限定テスターに加えた点だ。AIを「防御の道具」として責任を持って展開させようとする姿勢として評価できる。 日本企業に向けて言えば、今なお「AIは様子見」という空気が根強い現場が多い。しかし攻撃者がAIを使って自律的にターゲットを探し回る仕組みをすでに動かしている以上、様子見のコストは急速に上昇している。「禁止」や「制限」ではなく、組織として安全にAIを活用できる環境を作ること——それが今できる、そして今しかできない最善策だ。 出典: この記事は Google says it likely thwarted effort by hacker group to use AI for ‘mass exploitation event’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年5月、Claude Code v2.1.139をリリースし、複数エージェントセッションを一元管理する「エージェントビュー」と、設定した目標をClaudeが自律的に達成するまで動き続ける「/goalコマンド」を新たに追加した。AIコーディングツールの「自律性」が一段と高まった、見逃せないアップデートだ。 エージェントビューで複数セッションを俯瞰管理 今回の目玉のひとつがエージェントビュー（リサーチプレビュー）だ。ターミナルで claude agents を実行すると、実行中・応答待ち・完了済みのすべてのClaude Codeセッションが一覧で表示される。 これまでは複数のターミナルウィンドウを行き来しながら進捗を確認する必要があったが、エージェントビューにより全セッションの状態を一画面で把握できるようになった。並行して複数のAIエージェントを動かす開発ワークフローを組んでいる場合、管理コストが大幅に削減される。 /goalコマンド：「やり遂げるまで動け」を一行で もうひとつの核心が /goalコマンドだ。完了条件を設定すると、Claudeはその条件を満たすまで複数ターンにわたって自律的に作業を継続する。インタラクティブモード、-p（プログラマティックモード）、Remote Controlのいずれでも動作し、経過時間・ターン数・トークン消費量がリアルタイムでオーバーレイ表示される。 たとえば /goal すべてのテストがパスするまでバグを修正し続ける と設定すれば、Claudeはテスト実行→エラー解析→コード修正→再テストのループを人間の介入なしに繰り返す。これは補助機能の強化ではなく、AIが目的志向で自律動作するエージェントとしての性格を明確に打ち出したものだ。 その他の主要な改善点 プラグインとコンテキスト管理 claude plugin details <name> でプラグインのコンポーネント一覧とセッションあたりの予想トークンコストを確認可能 /context all のトークン推定値がモデルのトークナイザーに合わせて正確化 /context がプラグイン提供のスキルについて、提供元プラグイン名を表示 MCPサーバーとフックの改善 MCPのstdioサーバーが環境変数 CLAUDE_PROJECT_DIR を受け取れるようになり、フックとの整合性が向上 フックに args: string[]（exec形式）が追加され、パスのクォーティング問題を解消 PostToolUse フックに continueOnBlock オプションが追加。フックの拒否理由をClaudeにフィードバックしてターンを継続できる /mcp Reconnect が .mcp.json の編集を再起動なしに反映 セキュリティ関連 ANTHROPIC_API_KEY 等が設定されている場合、Remote Controlや /schedule などのClaude.ai連携機能を自動無効化。意図しない認証情報の混在を防ぐ設計 バグ修正 期限切れ認証情報とポリシー設定が重なった際のデッドロックを修正 シェル展開（$VAR、$(cmd)）を含むコマンドが autoAllowBashIfSandboxed で自動承認されなかった問題を修正 HTTP/SSE MCPサーバーの非プロトコルデータによるメモリ無制限増大を修正（SSEフレームあたり16MBに制限） 実務への影響 /goalコマンドの活用シナリオ シナリオ 具体的な使い方 CI修復 テストがすべてグリーンになるまで自動修正 コード品質改善 特定のlintルール違反がゼロになるまで修正 ドキュメント生成 全公開関数にJSDocが追加されるまで作業 リファクタリング 設定した指標を満たすまで継続的に改善 ...

AIエージェントが本当に「使えるもの」になるためには、モデルを賢くするだけでは足りない。エージェントが「次に何をするか」を決めるオーケストレーション層そのものが、根本から見直される必要がある――そう主張するのが、30名の研究者がarXivに投稿したポジションペーパーだ。その核心にある概念が「ベイズ整合性（Bayes-consistency）」である。 ベイズ整合性とは何か ベイズ整合性とは、AIシステムが持つ「信念（belief）」が数学的に整合的であることを指す。エージェントが「この情報を取得するためにツールを呼び出すべきか？」という判断をする際、その確率的な見積もりが一貫しており、得た証拠によって適切に更新される状態のことだ。 従来のAIエージェントは「杞憂」をしやすい。不確実な場面で念のためツールを呼び出す、すでに得た情報があるのに再確認のためAPIを叩く――こうした挙動は、確率的判断がキャリブレーション（較正）されていないことから生じる。今回の論文は、オーケストレーション層にベイズ統計の枠組みを導入することで、冗長なツール呼び出しを削減し、リソース配分を最適化できる理論的根拠を提示した。 なぜオーケストレーション層が鍵を握るか AIエージェントのアーキテクチャは大きく3層で構成される。 モデル層 — LLM本体の推論能力 オーケストレーション層 — いつ・何を・どのように実行するかを決める制御ロジック ツール層 — Web検索やコード実行などの実際のアクション 昨今の研究はモデル層の改善（より大きく、より賢く）に集中しがちだが、現場で「エージェントが使いものにならない」と感じる原因の多くはオーケストレーション層の設計にある。過剰なツール呼び出しは、実行時間の増加・コスト増大・最悪の場合には副作用を伴う操作の不必要な繰り返しを引き起こす。 実務での活用ポイント エンジニア・AIアーキテクト向け ツール呼び出し条件を明示化する: 「このツールをいつ呼ぶか」の条件をあいまいにしない。必要性の閾値を設計段階で定義することが、ベイズ的思考の第一歩だ。 信念更新のメカニズムを組み込む: 一度取得した情報を次の判断に反映する仕組みを明示的に設計する。コンテキストに情報があるのに再度ツールを呼ぶのは、更新機構が欠落しているサインだ。 キャリブレーション評価をパイプラインに加える: エージェントの出力する信頼度が実際の正答率と一致しているかを評価する仕組みを評価パイプラインに取り入れる。これはコスト分析レポートにも直接使える。 IT管理者・意思決定者向け 複数のAIエージェントを連携させるマルチエージェント構成を検討しているなら、オーケストレーション層の設計に今から投資すべきだ。モデル性能の差よりも、この層の設計品質が実用性を左右する。APIコスト管理の観点からも、「なぜそのツールを呼んだのか」を説明可能な形で設計することは、コスト最適化とガバナンスの両方に効いてくる。 筆者の見解 この論文の方向性は正しいと思っている。 AIエージェントが「本当に自律的に動くもの」と「指示を待ち続けるもの」に分かれていく流れの中で、前者の品質を決めるのはオーケストレーション層の洗練度だ。エージェントが自律的に判断・実行・検証を繰り返すループが機能するかどうかは、「いつ行動するか」の判断精度に大きく依存する。ベイズ整合性の概念は、そのループの判断部分に数学的な確かさを与えようとするアプローチであり、方向性として極めて真っ当だ。 一方で、理論と実装の間には大きなギャップがある。現実のLLMベースエージェントで確率的な信念をどう内部表現するかは自明ではない。この論文が「ポジションペーパー」である点は正直に受け止めるべきで、「あるべき姿」の提言であり、「すぐに使えるレシピ」ではない。 それでも、この方向に向けて研究コミュニティが動き始めたことは重要だ。AIエージェントを実際に動かしてみたことがある人ならわかるはずだ――今、最も痛いのはモデルの性能ではなく、「エージェントが余計なことをやり続ける」問題なのだから。オーケストレーション層の理論的基盤が整備されることは、この問題を根本から解決する足がかりになる。日本のエンジニアコミュニティにとっても、単なるモデル選定の議論から一歩踏み込んで、制御設計そのものを議論するフェーズに入った証だと受け止めている。 出典: この記事は Agentic AI Orchestration Should be Bayes-consistent — Position Paper by 30 Researchers の内容をもとに、筆者の見解を加えて独自に執筆したものです。