生成AI

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIA が開発したマルチモーダル AI モデル「Nemotron 3 Nano Omni」が Oracle Cloud Infrastructure（OCI）のエンタープライズ AI プラットフォームで利用可能になった。動画・音声・画像・テキストを単一システムで推論できる完全オープンソースのモデルであり、これまで複数モデルを組み合わせていた複雑なパイプラインを一本化できる可能性がある。同タイミングで xAI の Grok 4.3 も OCI に追加されており、エンタープライズ向け AI の選択肢は着実に広がっている。 「つなぐ時代」から「統合する時代」へ Nemotron 3 Nano Omni の最大の特徴は「マルチモーダル統合」と「完全オープンソース」の組み合わせだ。 従来、マルチモーダル AI 処理を実現するには、音声認識・画像認識・テキスト処理のモデルをそれぞれ選定し、データの受け渡し処理を自前で実装する必要があった。このオーケストレーション層は見えにくいバグを生みやすく、保守コストも高くつく。 Nemotron 3 Nano Omni はこれらを単一モデルで処理できる。より自然な「見て・聞いて・読んで・答える」AI アプリケーションを、複雑な配管なしに構築できる点が実務では大きい。 加えて完全オープンソースであることで、商用 API を呼び出すだけでなく、自社データでのファインチューニングや専用 AI クラスターへのデプロイが選択できる。OCI の専用 AI クラスターとの組み合わせにより、データをどこに置き、どのように処理するかを組織が完全にコントロールできる構成が現実のものになる。 Grok 4.3 の OCI 展開も注目 同じタイミングで xAI の Grok 4.3 も OCI Enterprise AI に追加された。τ²-Bench Telecom で 98%、IFBench で 81% というベンチマーク性能を示し、100 万トークンのコンテキストウィンドウにも対応している。高度なロジック・数学・コーディング・多段階分析に強く、インテリジェンス対コスト比では同等クラスのフロンティアモデルより競争力があるとされる。用途によってはコスト効率の面で魅力的な選択肢になりうる。 日本直結の事例：SoftBank の主権 AI プラットフォーム 今回の発表の中で日本に特に関係が深いのが、SoftBank が OCI を使って国内主権クラウドプラットフォームを構築しているという事例だ。自社の生成 AI モデルと OCI Enterprise AI を組み合わせ、データをすべて国内のデータセンターに留めながら高度な AI 機能を提供する構成を実現している。 ...

AIの競争軸が、「どのモデルが賢いか」から「誰が企業の現場でAIを動かし切れるか」へと移行しつつある。OpenAIが2026年5月に設立を発表した「OpenAI Deployment Company」は、その象徴的な一手だ。Applied AIコンサルティング会社Tomoroの買収と40億ドル超の初期投資により、OpenAIはAPIプロバイダーという立場を超え、企業のAI導入を一気通貫で支援する体制へと踏み込んだ。 「モデルを売る」から「成果まで責任を持つ」へ これまでOpenAIのビジネスモデルの中心は、APIとChatGPTの提供だった。企業が実際の業務システムに組み込む際のアーキテクチャ設計、既存システムとの統合、セキュリティ・コンプライアンス対応、従業員トレーニング——これらは国内外のSIerやコンサルティングファームが担う領域とされてきた。 OpenAI Deployment Companyの設立は、そのポジションへの直接参入を意味する。Tomoroの買収によって、現場のAI実装経験を持つコンサルタントチームとノウハウを一括で獲得した形だ。単なる「AIツールの販売代理店」ではなく、成果にコミットするパートナーとしての役割を取りにいっている。 「PoC墓場」問題への構造的な回答 この動きの背景にある課題は明確だ。企業のAI導入が「実験止まり」「PoC墓場」に終わりやすいという現実である。 優れたモデルがあっても、既存データとの接続、権限管理、業務プロセスの再設計、そして何よりも「現場の人間がどう使うか」をデザインしなければ、生産性向上には結びつかない。40億ドル超という初期投資規模は、この支援業務が片手間のサービスではなく、戦略的なコアビジネスと位置づけられていることを示している。 競合との構図——「実装力」が次の勝負どころ 同様のDeployment Company構想を進める他社との競合は避けられない。また、Azureのインフラ基盤、M365のユーザーベース、そして広大なパートナーエコシステムを持つMicrosoftも、この「企業AI実装支援」の戦場における重要プレイヤーだ。 純粋なモデル性能の比較競争から、「誰が企業のAI化を成功に導けるか」という実力勝負へと、業界の競争軸が移りつつある。 日本のIT現場への影響 選択肢の変化 大手AIベンダー自身が実装支援を提供するようになることで、「モデル提供者」と「実装パートナー」の役割分担が解消されるケースが増える。これまで国内SIerが担っていた上流の実装設計に、直接圧力がかかることは避けられない。 国内SIer・コンサルへの影響 付加価値の再定義が急務だ。AIモデルの知識を持つだけでは差別化にならなくなる。業界固有の業務知識、法規制への対応、日本語環境特有の課題解決——こうした領域でいかに深い専門性を発揮できるかが問われる。 「本番化圧力」の高まり OpenAIのような企業が「成果まで責任を持つ」モデルで参入することで、PoC段階で止まっていた日本企業の取り組みに本番化を求める機運が高まる可能性がある。 明日から使えるヒント 自社のAI導入ロードマップを「モデル選定」ではなく「成果定義」から逆算して設計し直す ベンダーやSIerとの契約で「成果ベースの評価指標」を明示的に盛り込む OpenAI Deployment CompanyやAzure AI推進体制など、直接支援サービスの情報収集を今のうちに始める 筆者の見解 「企業のAI化を支援する」という言葉は以前から飛び交っていたが、それが現場で本当に機能していたかは怪しい。PoC（概念実証）を量産して「成功事例」として飾り立てながら、実際の業務フローで動いているAIは少ない——そんな状況が長く続いてきた。 大手AIベンダーが自ら実装責任を持つ形に踏み込んできたことで、この「PoC墓場」問題が解消に向かう可能性はある。ただし40億ドルの投資規模が示すように、当面はグローバル大企業向けの話から始まるだろう。中小規模の日本企業が直接の恩恵を受けられるまでには、もう少し時間がかかると見ている。 あらためてMicrosoftのポジションが気になる。Azureのインフラ、M365の膨大なユーザーベース、Copilotの展開力、そしてパートナーエコシステム——これだけの武器を持ちながら、「AI実装まで責任を持つ」という価値提案で存在感を発揮しきれているかというと、まだ磨きしろがある。とはいえ、Microsoftにはその力があるはずだ。ぜひ正面から勝負してほしいと思っている。 今後のAI市場における核心的な問いは、「どのモデルが最強か」ではなく、「誰がエージェントを設計し、企業の業務ループに組み込み、継続的に改善し続けられるか」だ。OpenAIの今回の動きは、その問いへの一つの明確な答えである。 出典: この記事は OpenAI Launches OpenAI Deployment Company with $4B+ Investment to Help Businesses Deploy AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIとの対話が「テキストのやり取り」から「電話の会話」へと変わろうとしている。元OpenAI最高技術責任者（CTO）のMira Murati氏が昨年設立したThinking Machines Labが、2026年5月に「インタラクションモデル（interaction models）」と称する新しいアーキテクチャを発表した。現時点では研究プレビューの段階だが、AIの対話設計に対する根本的な問い直しとして注目に値する。 ターンテイキング型AIの根本的な限界 現在のすべてのAIモデルは「ターンテイキング」方式で動作する。ユーザーが話す→AIが聞く→AIが応答する→ユーザーが聞く。文章チャットなら許容できるこのリズムも、音声対話では致命的な違和感になる。まるでボイスメールに吹き込んでいるような一方通行感——これは実装の問題ではなく、モデルのアーキテクチャに起因する構造的な制約だ。 フルデュプレックスとは何か 「フルデュプレックス（full duplex）」は送受信を同時に行う通信方式で、固定電話や携帯電話がその代表例だ。Thinking Machines Labはこの概念をAIモデルに持ち込み、ユーザーの入力を受け取りながら同時にレスポンスの生成を始めるアーキテクチャを構築している。 同社が発表したTML-Interaction-Smallは0.40秒での応答を実現しており、人間の自然な会話リズムとほぼ同等の速度とされる。同社の主張では、OpenAIやGoogleの比較可能なモデルより大幅に高速だという。最大の違いは「割り込み」が自然にできることだ。人間同士の会話では相手の発話途中で反応したり相槌を打ったりするが、現在のAIはそれを苦手としている。フルデュプレックスモデルはこの非同期性をアーキテクチャレベルでネイティブサポートする。 現時点での位置づけと注意点 重要な留意点として、これはあくまでリサーチプレビューであり、一般公開はされていない。今後数ヶ月以内に限定リサーチプレビューが始まり、本年中に広く公開される予定とのことだ。ベンチマーク数値は印象的だが、実際のユーザー体験がそれに見合うかどうかは、一般公開されて初めて評価できる。 実務への影響——日本のIT現場では何が変わるか 日本でも音声インターフェースへの関心は高まっており、コールセンターの自動化や会議議事録生成、社内ヘルプデスクの音声AIなど、実装が進む分野は多い。フルデュプレックス技術が実用レベルに達した場合、以下のような変化が期待できる。 コールセンターAI: ユーザーの発話を遮断せず、自然なやり取りが可能になる。現行システムの「お話が終わりましたら話しかけてください」という不自然な案内が不要になる。 会議支援: リアルタイムで「聞きながら」ファクトチェックや議事メモを生成できる。会話の文脈が切れないまま情報補完が進む体験は、現行のポーリング型AIとは質的に異なる。 教育・トレーニング: 相槌や間の取り方も含めた、より人間に近い学習体験が実現しやすい。語学学習や営業ロールプレイへの応用が期待できる。 なお、日本語の音声認識精度や文化的な「間」の扱いは英語前提モデルとは最適化の方向が異なる。国内での実用化には日本語特有のチューニングが別途必要になる点は意識しておきたい。 筆者の見解 AIエージェントの本質的な価値は「自律性」にある。ユーザーが発話するたびに処理を止めて待つ設計は、AIが人間のペースに従属するという前提を前提に組み込んでいる。フルデュプレックスはその制約を技術的に取り除く試みであり、方向性として非常に理にかなっている。 自律的なエージェントが判断・実行・検証を繰り返すループを設計する観点から見ると、インタラクションレイヤー自体が「ターンベース」のままでは本来の力を引き出しにくい。今回の発表はその問題に正面から向き合っている点で評価できる。 一方で、0.40秒という数値が印象的でも、会話の「文脈理解の深さ」や「割り込みのタイミングの適切さ」は数値には現れない。技術デモとプロダクトの間には常に大きな溝がある。Thinking Machines Labが「研究プレビュー」という段階を経てプロダクト化するアプローチは堅実で、そのプロセスを注視したい。 AIとの対話体験がどう設計されるか——それはエンジニアが考える以上にユーザーの信頼形成に直結する。フルデュプレックスが実用化されたとき、それが「本当に会話している」という感覚をもたらすかどうか、一利用者として楽しみに待っている。 出典: この記事は Thinking Machines wants to build an AI that actually listens while it talks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Apple Siliconを搭載したMacが広く普及した今、「ローカルでLLMをトレーニングしてみたい」と考えるエンジニアは少なくないはずだ。そんな挑戦に真正面から取り組んだブログ連載記事「Training an LLM in Swift」が、HackerNewsで大きな注目を集めている。ライブラリもフレームワークも使わず、純粋なSwiftコードでGPT-2互換モデルをトレーニングし、行列演算のスループットをGFlop/s（ギガフロップ）からTFlop/s（テラフロップ）——すなわち1000倍以上——へ引き上げた記録だ。 機械学習の心臓部：行列乗算とは何か LLMの学習は「フォワードパス（推論）」と「バックワードパス（誤差勾配計算・重み更新）」で構成される。この両フェーズで支配的な計算コストを占めるのが行列乗算（Matrix Multiplication）だ。数十億パラメータを持つ現代のLLMでは、1ステップのトレーニングで膨大な行列積が実行される。行列乗算を速くすることが、そのままLLMトレーニングの高速化に直結する。 本連載がベースラインとするのは、Andrej Karpathy氏が公開したllm.c（約1,000行のC言語によるGPT-2互換実装）だ。「Swiftで同じことをやって、C言語より速くしてやろう」という挑戦的なモチベーションが出発点となっている。 最適化の4段階：CPU→SIMD→AMX→GPU 記事では行列乗算の最適化を段階的に積み上げていく過程が丁寧に解説されている。 1. ナイーブ実装（GFlop/s台） 最初の三重ループによる実装はスカラー演算に依存しており、性能は低い。出発点として計測値を取り、改善幅を可視化するための基準となる。 2. SIMD（Single Instruction, Multiple Data） SwiftはSIMD型を標準サポートしている。一度の命令で複数の浮動小数点数を並列処理することでCPUの演算ユニットを効率的に活用でき、ナイーブ実装から大幅に性能が向上する。 3. AMX（Apple Matrix coprocessor） Apple Siliconに搭載されたAMXは、行列演算に特化した専用ユニットだ。公式ドキュメントはほぼ存在しないが、研究者やエンジニアの逆解析によりその活用法が知られるようになっている。AMXを使いこなすことで、SIMDをさらに大きく超える性能向上が得られる。 4. Metal（GPU） 最後の切り札がGPUだ。AppleのGPUプログラミングフレームワークMetalを使ったShaderコードも紹介されており、GPU並列演算によって最終的にTFlop/sという領域に到達する。 実務への影響：ローカルLLMの可能性が広がる この記事が示すのは単なる学術的な実験ではない。Apple Siliconを搭載したMac上で、現実的なコストでローカルLLMをトレーニングできるというポテンシャルだ。 日本のエンジニア・IT管理者にとって押さえておきたいポイントを整理する。 プライバシー・コンプライアンスへの対応: クラウドAPIへのデータ送信に制約がある業界（医療・金融・法務）では、ローカルでの推論やファインチューニングが重要な選択肢になる。Apple SiliconのMacはそのための現実的なプラットフォームになりうる フレームワークの内側を理解する価値: PyTorchやTensorFlowのような高レベルフレームワークは便利だが、内側で何が起きているかを知らないと性能の壁にぶつかった際に対処できない。「ライブラリなし実装」は学習コストが高いが、深い理解を得る最短ルートでもある Swiftの実力を再評価: iOSアプリ開発の言語というイメージが強いSwiftだが、システムプログラミング領域でもC言語と同等のパフォーマンスを達成できることをこの記事は実証している 筆者の見解 AIエージェントや生成AIの実装に深く関わっていると、「結局のところLLMの中で何が動いているか」という問いに向き合う機会が増えてくる。本記事のような「基礎から組み上げる」アプローチは、高レベルAPIを呼び出すだけの実装では得られない本質的な理解をもたらしてくれる。 Karpathyのllm.cが「何も隠さない実装」として広く支持されている理由も同じだ。抽象化のレイヤーを剥がして初めて、なぜ特定の設計判断が性能に効くのかが見えてくる。 日本のエンジニアコミュニティで気になるのは、次々と登場する新技術の「情報を追いかける」ことに忙しすぎて、「実際に手を動かして理解を深める」ことが後回しになりやすい傾向だ。本記事のような深掘りコンテンツこそ、積極的に手を動かして試す価値がある。情報の量を増やすよりも、一つの実装を深く理解する経験の方が、今の時代には圧倒的に価値が高いと考えている。 ローカルLLM、Apple Silicon最適化、Swiftシステムプログラミング——いずれも今後さらに注目度が上がる領域だ。次回以降の連載でAppleのフレームワーク群（Core ML、Metal Performance Shaders等）との比較評価が行われる予定とのことで、続きも楽しみにしている。 出典: この記事は Training an LLM in Swift, Part 1: Taking matrix mult from Gflop/s to Tflop/s の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AWS上でClaude Platformが一般提供（GA）を開始した。AWS IAMによる認証、CloudTrailによる監査ログ、AWSの統合請求という「エンタープライズ三点セット」をそのまま活用しながら、AIエージェント開発の最前線機能が使えるようになった。クラウドネイティブな企業にとって、AIエージェント本格導入の最大の壁が一つ取り除かれた形だ。 AWS統合で何が変わるか これまでAnthropicのAPIを企業で使う場合、IAMとは別の認証情報管理、独立した請求、そして監査ログの分断という課題があった。Claude Platform on AWSはこの課題を正面から解決する。 認証: AWS IAMポリシーで制御。既存のロール設計・権限管理がそのまま適用される 監査ログ: AWS CloudTrailに記録。セキュリティチームが普段使っているツールで追跡可能 請求: AWSの統合請求書に含まれ、既存のコミットメント（Reserved CapacityやSavings Plans等）の消化にも充当 これは単なる利便性の話ではない。大企業やパブリックセクターでは、「別のベンダーとの直接契約」「別の認証基盤」「別の監査証跡」というだけで導入が数ヶ月単位で止まることが珍しくない。その壁を取り払うインパクトは想像以上に大きい。 使える機能の全体像 Claude Platform on AWSで利用可能な主な機能は以下の通りだ。 機能 概要 Claude Managed Agents エージェントのビルド・スケール展開（ベータ） Advisor strategy エージェントにアドバイザーモデルを付与してインテリジェンスを強化（ベータ） Web search / Web fetch リアルタイムのWeb情報でコンテキストを補完 Code execution PythonコードをAPIコール内で直接実行・可視化 Files API 会話をまたいだドキュメント参照（ベータ） Skills ベストプラクティスを学習させて一貫した出力を実現（ベータ） MCP connector クライアントコード不要でリモートMCPサーバーに接続（ベータ） Prompt caching 繰り返しコンテキストのコスト・レイテンシ削減 Citations ソース文書に根拠を紐付けたレスポンス生成 Batch processing 大量の非同期ワークロード処理 利用可能モデルはClaude Opus 4.7、Sonnet 4.6、Haiku 4.5で、今後の新モデルもリリース当日から使えるという。 なお、Amazon Bedrockでも引き続きClaudeは利用可能だが、そちらはAWSがデータプロセッサーとなる構成だ。Claude Platform on AWSはAnthropicのネイティブAPIへのアクセス層がAWSになるという点で性格が異なる。データ処理の責任主体がどこにあるかは、コンプライアンス要件に応じて使い分けが必要になる。 Claude Managed AgentsとAdvisor strategyが示す方向性 今回の発表で特に注目したいのがClaude Managed Agentsだ。エージェントをスケールさせて「ビルドして展開する」という設計思想が明確に打ち出されている。 ...

Googleが「Gemini 3.1 Ultra」を発表した。最大200万トークンのコンテキストウィンドウを持ち、テキスト・画像・音声・動画のすべてをネイティブに扱える今年最大規模のモデルリリースだ。エンタープライズ向け長文脈処理において、業界の基準を大きく塗り替える可能性がある。 200万トークンとは何を意味するか 200万トークンという数字はピンと来にくいかもしれないが、実務に当てはめると感覚がつかみやすい。 文庫本に換算すると約2,000〜2,500ページ分に相当 企業の内部文書なら数百本の報告書を一度のプロンプトに詰め込める 1時間超の会議録音や長編動画も丸ごと1プロンプトで処理できる水準 従来のモデルは長い文書を扱う際、「チャンク分割」と呼ばれる分割処理が必要だった。文書をいくつかのブロックに切り出してAIに順番に読ませ、回答を統合する——という手間のかかる前処理が必要だったのだ。200万トークンのコンテキストはその制約を大幅に緩和する。 ネイティブマルチモーダルが何を変えるか 今回のリリースでもう一つ注目すべき点は、マルチモーダル処理が「ネイティブ」であることだ。 これまでの多くのマルチモーダルAIは、音声や画像を一度テキストに変換してからLLM（大規模言語モデル）が処理するパイプライン構造を採っていた。変換のたびに情報が落ちるリスクがあり、遅延も生じる。Gemini 3.1 Ultraはこの中間変換を排除し、テキスト・画像・音声・動画を「同じ土台の上で」処理できる設計になっているという。 実務への影響は大きい。たとえば： 設計図（画像）＋仕様書（テキスト）＋会議録（音声）を一度にインプットとして扱える 動画マニュアルを動画のまま分析し、テキスト手順書と照合できる 映像・音声証跡を含む監査業務の自動化が現実的なラインに近づく 実務への影響——日本のエンジニア・IT管理者にとっての意味 1. RAG設計の見直しが必要になるかもしれない コンテキストウィンドウが大きくなると、従来のRAG（Retrieval-Augmented Generation）設計が変わる。「必要な部分だけ検索して詰め込む」アーキテクチャは、全文をそのままコンテキストに入れられる場合には過剰設計になりうる。コスト・速度・精度のバランスを再評価するタイミングだ。 2. コスト構造を必ず確認する 200万トークンのコンテキストは強力だが、それだけAPIコストも高くなる。実際に利用する前に1リクエストあたりの単価と業務のトークン使用量を見積もり、ROI計算を済ませてから導入を判断してほしい。大きなコンテキスト＝大きなコスト、という前提で設計すること。 3. 長文処理が得意な業務ユースケースを洗い出す 法律・医療・製造業の技術文書、大規模プロジェクトの要件定義書、マルチメディアを含む監査ログ——これらは長文脈モデルの恩恵を受けやすい領域だ。社内でそういった業務の棚卸しをしてみると、活用可能性が見えてくる。 4. セキュリティ・データガバナンスの検討は必須 大量の社内文書をそのままクラウドAPIに送る構造になるため、機密情報の取り扱いルールと、どのデータをどのAPIに送ってよいかのガバナンス整備が前提条件になる。先に仕組みを作ってから使い始めること。 筆者の見解 コンテキストウィンドウの拡大競争は、ここ1〜2年で急速に加速してきた。数ヶ月前に「驚異的」と言われていた数字が、あっという間に当たり前になる。技術の進化ペースとしては正直、ついていくのが大変だ。 ただ、今回のGemini 3.1 Ultraについては「数字のインパクト」と「実務での実力」を分けて考える必要があると思っている。200万トークンというコンテキストの大きさは確かに業界最高水準の数字だ。しかし実際の現場で問われるのは、その広大なコンテキストの中から必要な情報を正確に抽出できるかどうか、つまり「Lost in the Middle」問題をどこまで克服しているか、だ。コンテキストが長くなればなるほど、モデルが文書の中盤に書かれた情報を読み落とす傾向があることは複数の研究で示されている。 また、ネイティブマルチモーダルの設計思想は評価できる。変換レイヤーを挟まないことで情報損失を減らすというアプローチは、エンジニアリング的に正しい方向性だと思う。 エンタープライズの観点では、「コンテキストが大きいAI」の登場は、これまで技術的制約によって諦めていた業務自動化の再検討を促すきっかけになる。特に法律・会計・製造業の複雑なドキュメント処理については、真剣に評価する価値がある。 AIを導入する側の企業に言いたいのは、発表スペックに踊らされず、自社の具体的なユースケースで評価してほしいということだ。モデルの優劣は一般的なベンチマークではなく、自社業務への適合度で決まる。情報を追うより、実際に使って成果を出す経験を積む——それが今のAI活用で最も正しい行動だと、筆者は一貫して考えている。 出典: この記事は Google Launches Gemini 3.1 Ultra with 2 Million Token Context Window の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国防総省（ペンタゴン）が、SpaceX、OpenAI、Google、Nvidia、Microsoft、AWS、そして複数のスタートアップと大規模なAI契約を締結した。軍を「AIファースト戦闘組織」へ変革するという宣言を伴うこの動きは、民間AI企業と防衛省の間で史上最大規模の正式提携となる。単なる政府調達の話ではない——AI産業全体が「実験フェーズ」から「実戦運用フェーズ」へ完全に移行したことを象徴する出来事だ。 「エージェントAIへの大転換（Agentic Pivot）」が始まった 今回の動きと同時期に開催されたIBM Think 2026カンファレンスのキーワードも「エージェントAI」だった。これは偶然ではない。2026年のAI業界全体で、共通したパラダイムシフトが起きている。 これまでのAIの主役は「生成AI」——テキストや画像を作り出すモデルだった。しかし今、産業の関心は「エージェントAI」へ移っている。エージェントAIとは、単に質問に答えるだけでなく、複数のステップからなるビジネスロジックを自律的に計画・実行するシステムだ。ツールを呼び出し、複数のプラットフォームをまたいで処理を完結させる。「副操縦士」ではなく、「自律的に動く実行者」である。 ペンタゴンが求めているのもまさにこれだ。戦場での意思決定支援、自律システムへの本格投資——確認ボタンを人間が押し続けるようなシステムでは、軍事的優位性を得られない。 「デリバリーギャップ」——AIを本当に価値に変えられている企業は3割だけ IBM Think 2026で示された数字が現実を物語っている。AIを収益成長の重要ドライバーとして位置付けている経営者は多いが、「組織全体で持続的な成果を出せている」と答えたのはわずか32%だ。 この「デリバリーギャップ」の原因はモデルの性能ではない。問題はスケール展開の難しさ——パイロットプロジェクトの成功を、組織全体のインパクトに転換できないことだ。 IBMはこれに対してEnterprise Advantage（エンタープライズ・アドバンテージ）というコンサルティングフレームワークを投入した。注目すべきは「Context Studio」と「Process Studio」の二つだ。 Context Studio: 組織固有のデータ構造にAIエージェントを根付かせ、精度と関連性を高める仕組み Process Studio: 何千もの標準業務手順書（SOP）からAIがロジックを抽出し、エージェント対応アーキテクチャに変換するツール 実際のクライアント案件では、1,400件の手順書を分析して1,000件以上の改善機会を特定し、18ヶ月で運用コスト25%削減を見込むという結果が出ている。 医療分野のProvidence社ではAI採用エージェントの導入で採用ステップの工数が90%削減、求人精度が70%向上。教育のPearson社ではAIによるスキル認定・評価を実用化した。 デジタル主権（Digital Sovereignty）という新たな必須要件 2026年のエンタープライズAI議論で急浮上しているのが「デジタル主権」の概念だ。クラウドの恩恵を享受しながら、自社の固有データとモデルウェイトのコントロールを手放さない——このバランスが企業にとって不可欠な条件になっている。 ServiceNowはこの文脈で「AIコントロールタワー」というポジショニングを打ち出した。レガシーシステム、クラウドアプリ、多様なAIエージェントを単一の管理画面から統合オーケストレーションする基盤だ。Accentureとの連携で300以上の事前構築済みAIエージェントスキルを提供し、「実験から事業変革の中核へ」という移行を支援する。 日本のエンジニア・IT管理者にとっての意味 「米軍の話は自分には関係ない」と思ったなら、少し立ち止まって考えてほしい。今回のペンタゴン契約が重要なのは、AIエージェントの実運用フェーズへの移行が、最も要求水準の高い顧客によって公式に確認されたからだ。 実務での活用ポイントを整理する。 1. 「デリバリーギャップ」の問題は他人事ではない 「AIを試してみた。なんとなく使えそう。でも全社展開には至っていない」——この状態は今の日本企業にとっても典型的だ。32%しかスケールできていないのは世界共通の課題。差をつけるには「パイロット成功後の展開設計」を最初から考えること。 2. 既存の業務手順書（SOP・マニュアル）は宝の山 Process Studioが示したように、紙や文書に眠っている業務ロジックはエージェントAIの燃料になる。「うちのマニュアルは多すぎて整理できない」という状況こそ、AIエージェントが最も力を発揮する環境だ。 3. デジタル主権の設計を後回しにしない どのデータをどのクラウドに渡すか、モデルウェイトは誰が管理するか——エンタープライズAI展開の前にこの設計を固めておかないと、後から取り返しのつかないリスクが生まれる。 4. 「エージェント間の相互運用性」に注目せよ 今まさに「エージェントインターネット」という概念が形になりつつある。複数のAIエージェントが協調して動く世界が標準になったとき、自社のシステムがそこに接続できるかどうかが勝敗を分ける。 筆者の見解 ペンタゴンがこれだけの規模でAI契約を結んだという事実は、エージェントAIが「まだ実証段階」というフェーズを完全に抜けたことを意味する。世界で最も厳しい要求水準を持つ顧客が「本番投入する」と判断したのだ。 私がここ数年ずっと注目しているのが「ハーネスループ」の概念だ——AIエージェントが自律的に判断・実行・検証を繰り返すループを設計すること。単発の指示に応答するだけのAIは、「副操縦士」の域を出ない。本当の価値は、目的を与えれば自分で動き続けるエージェントにある。今回のペンタゴン契約は、まさにその方向性に社会が全力で投資し始めた証拠だ。 一方で、日本のIT現場に目を向けると、「AIを使ってみた」から「AIが組織を動かしている」への移行が極めて遅い。大きな原因のひとつは、確認・承認を人間に求め続ける設計のツールでAIに触れてきた経験が多いことだ。そのような体験だけで「AIはこんなものか」と判断してしまうのは、あまりにもったいない。 統合プラットフォームで全体最適を取るというIBMやServiceNowのアプローチは、道の正中を歩く正しい方向だと思う。部分最適を積み重ねた先に待っているのは、複雑化したシステムと高騰するコストだ。エージェントAI時代の設計原則は「最初から統合を前提に作ること」——この転換を、今年中に自社の設計思想に組み込んでほしい。 AIが「仕組みを作る少数の人間」と「その仕組みを回すAI」という構造を現実にしつつある。この変化の速度に、日本の組織がいかに乗り遅れず対応できるかが、今後5年の競争力を決める。 出典: この記事は Pentagon Signs Landmark AI Agreements with SpaceX, OpenAI, Google, Nvidia and Others の内容をもとに、筆者の見解を加えて独自に執筆したものです。

5月19〜20日（米国時間）、カリフォルニア州マウンテンビューのショアライン・アンフィシアターでGoogleの年次開発者カンファレンス「Google I/O 2026」が開催される。すでに公開されているセッション一覧には、次世代Geminiモデルとプラットフォーム統合を予感させるキーワードが並んでおり、AIと開発者エコシステムの双方でひとつの節目になりそうだ。 Gemini 4：1000万トークン時代の幕開け？ Googleは「Gemini 4」という名称を公式には確認していないが、I/Oのセッション一覧には「次世代Gemini長文脈」に関連するタイトルが複数登場しており、現行モデルを大きく超える能力が示唆されている。 現行のGemini 3.1 Ultraは200万トークンのコンテキストウィンドウを持つ。それがさらに拡張され、最大1000万トークン規模になるという観測がある。1000万トークンとは、100万行超のコードを丸ごとAPIコールに乗せられるスケールだ。大規模エンタープライズのシステム全体を「一度に読ませる」ことが現実の選択肢になってくる。 マルチモーダルの扱い方にも注目したい。多くのモデルが音声・動画をいったんテキストに変換（トランスクリプション）してから処理するのに対し、次世代Geminiのセッション説明はネイティブな音声・動画処理を謳っている。変換なしでトーンや時間的情報を保持したまま扱えるとすれば、音声品質の評価や動画解析ユースケースで本物の差別化になりうる。 さらに「エージェント型コーディング」に絞ったセッションが3本設けられており、長期稼働するコードエージェント、マルチステップのソフトウェアエンジニアリングタスク、Google開発ツールとの統合がテーマになっている。エージェント型ワークフローが主戦場になりつつある業界全体のトレンドを、GoogleがI/Oという最大の舞台で正式に打ち出してくる形だ。 Android 17「Adaptive Everywhere」：スマホ・Chromebook・XRが一つに Android 17最大のニュースはOSのバージョンアップではなく、プラットフォームの統合だ。Android、Chrome OS、そしてGoogleのXR（拡張現実）基盤が単一コードベースへと統合される。Android 5.0 Lollipopがマテリアルデザインを導入して以来、最大規模のプラットフォーム刷新と言っても過言ではない。 開発者にとっての実際の意味 シングルターゲットビルド：Android 17対応アプリはスマートフォン・タブレット・Chromebook・XRヘッドセットすべてで動作する。フォームファクター別のビルド分岐が不要になる ChromebookのネイティブAndroid化：現在Androidアプリは互換レイヤー越しにChromebookで動いているが、そのレイヤーが消える。市場に出回るすべてのChromebookが正式なAndroidアプリのターゲットになる XRへの先行投資：Googleはまだ本格的なXRデバイスを市場に送り出していないが、Android 17はその基盤となる。今作ったAndroid 17対応アプリは、将来のXR対応を追加作業なしに得られる 移行については、Android 6.0のランタイムパーミッション導入以来で最も大きなAPI変更が見込まれる。I/Oでデベロッパープレビューが公開されたら、できるだけ早く確認しておくことを強くすすめる。 Flutter・Firebase・Google Playも大型アップデート Flutter、Firebase、Google Playの三本についても大規模なアップデートが予告されている。特にFlutterは、Android 17の統合プラットフォームと組み合わさることで「単一コードベースで全フォームファクターをカバー」という強みがいっそう際立つ。Flutterを技術スタックに採用しているチームは今回のI/Oを注意深く観察する価値がある。 実務への影響 エンタープライズ開発者・IT管理者へ Gemini 4の大規模コンテキストは、大量のレガシーコードを抱えるシステムのレビューや仕様理解に直接使えるポテンシャルを持つ。社内コードの量が多いほど恩恵を受けやすい Android 17のAPI変更はChromebookを大量展開している企業に影響が出る可能性がある。今から検証環境の準備とアプリ棚卸しを始めたい XR統合は現時点では未来への布石だが、製造・医療・教育分野でXR活用を検討している組織は、Androidプラットフォームをベースとしたロードマップを描く材料が増える 筆者の見解 今回のGoogle I/O 2026が注目を集めるのは、「AIとプラットフォームを一つの戦略の中に統合してきた」からだと感じている。 エージェント型AIによるコーディング支援は、今まさに業界全体が最も力を入れている領域だ。単発のコード補完から、長時間稼働して自律的にタスクを遂行するエージェントへ——この方向性は、AIが開発生産性を根本から変えるうえで正しいアプローチだと考えている。Googleがこの方向に本腰を入れてきたことは、業界の潮流が大きく動いていることを再確認させてくれる。 Android 17の統合プラットフォーム化も、全体最適の観点からは筋が通っている。フォームファクターごとにサイロ化されたコードベースを維持するのはコストも品質管理も重荷だ。ただし、APIの大幅変更は現場に相当な移行負担をもたらす。早めに情報を仕入れ、段階的に対応を進めることが肝心だ。 一方で、カンファレンスの発表と実際の製品の間には常にギャップがある。セッションリストから読み取れるのは現時点での予測に過ぎない。発表後にすぐ試せるよう、5月19日以降の開発者プレビューに注目しておきたい。 出典: この記事は Google I/O 2026: May 19-20 — Gemini 4, Android 17, What to Expect の内容をもとに、筆者の見解を加えて独自に執筆したものです。