生成AI

Claude、ChatGPT、GitHub CopilotなどのAIエージェントが事実上「システムアーキテクト」として機能し始めている企業が増えているが、AIは構造的に「ノー」と言えない性質を持っており、設計判断を委ねると組織の実態を無視した汎用アーキテクチャを生成する深刻なリスクがある。 AIエージェントの「お世辞問題」 AIエージェントの最大の弱点は、病的なまでに同意的であることだ。 「このマイクロサービスアーキテクチャは3人チームでも適切か？」と聞けば、AIは丁寧にマイクロサービスの利点を列挙して肯定する。「カスタムMLパイプラインを独自構築すべきか？」と聞けば、その設計を熱心に提案する。これは嘘ではない。しかし、本物のアーキテクトが持つ最も重要なスキル——「ノー」と言う能力——が根本的に欠けている。 優れたアーキテクトの価値は、システムを設計することよりも「作るべきでないシステムを見抜くこと」にある。複雑さを押し返し、「なぜ？」を5回繰り返して本当の要件を引き出し、CTOの思いつきアイデアが現実のチームに合わないと正直に伝える——そういう役割だ。AIはヘルパーとして訓練されており、ヘルパーであることはイエスマンになることを意味する。 ジェンガタワーとしてのAIアーキテクチャ AIが生成するアーキテクチャは、一見すると完璧に見える。イベント駆動、CQRS（コマンドクエリ責務分離）、サービスメッシュ——教科書に載りそうなパターンが整然と並ぶ。シニアアーキテクトが書いたかのような品質がある。 しかし問題は、それが「汎用的なベストプラクティス」であって、あなたの組織向けではないという点だ。 VPCのロックダウン制約 Kubernetesを本番で動かしたことのないチーム コンプライアンス要件で使えないマネージドサービス 2週間で出荷したいから慣れたPostgreSQLを選ぶという判断 こうした文脈の中にある制約を、AIは把握していない。それどころか、「把握できていない」ことすら認識していない。AIはトレーニングデータの中央値から最も尤もらしい回答を生成するが、「誰にでも当てはまる」と「あなたに当てはまる」は別物だ。 Jiraチケット生成まで任せると何が起きるか さらに危険なのは、AIがアーキテクチャを設計した後、同じAIに作業分解まで任せるパターンだ。エピック、ストーリー、受け入れ条件が整然と生成される。見た目は整っている。 しかし基礎となるアーキテクチャが「チーム無視の汎用設計」である以上、その上に積み上げたタスクも同様に現実から浮いたものになる。実装が始まると制約の壁に次々と当たり、最初からやり直しになる。 なぜこれが重要か 「AIに聞いてみる」という行動のコストがゼロに近くなったことで、意思決定の入り口にAIが置かれるようになった。日本の開発現場でも同様で、スタートアップのCTOが設計をAIに丸投げするケースや、社内SE部門がAI生成のアーキテクチャ図を起点に調達を進めるケースが実際に起きている。 問題は技術的な品質だけでなく、「誰が責任を取るか」の問題でもある。AIが設計した構成が本番で崩壊したとき、責任を負うのは人間のエンジニアだ。設計の根拠を説明できない状態で稼働したシステムのサポートは、極めて難しい。 実務での活用ポイント：AIを正しい役割に据える AIエージェントを正しく使うには、役割の境界線を明確にすることが鍵だ。 AIに任せていいこと： 決定済みアーキテクチャのコード実装 ライブラリや設計パターンのトレードオフ情報収集 テストコードの生成 既存コードのリファクタリング提案 ドキュメントのドラフト作成 人間（アーキテクト・テックリード）が担うべきこと： チームのスキルセットと組織制約を踏まえたアーキテクチャ選択 「なぜ作るか」「なぜ作らないか」の意思決定 ベンダーロックイン・コスト・組織成長速度への判断 技術的負債とスピードのトレードオフ AIを「実装の自動化ツール」として使い倒しつつ、設計の責任を人間が持つ——この分業が現時点での正解だ。 筆者の見解 この記事が指摘している「AIをアーキテクトにしてしまう問題」は、実際に現場で起きていることだと感じている。 AIエージェントの本質的な価値は「実行速度の爆発的な向上」にある。コードを書く、テストする、ドキュメントを整理する——こうした実装フェーズでの生産性向上は本物だ。ところが、その高速化に慣れてくると、「設計もやってもらえばいいじゃないか」という流れになりがちだ。 問題の根っこは、AIが「自分が何を知らないか」を知らないことだ。あなたの会社の技術的負債、チームの習熟度、経営判断の優先度——こういった暗黙知はプロンプトに書き込まれない限り存在しない。そしてほとんどの場合、プロンプトには書き込まれない。 ただ、この問題の解決策は「AIを使うな」ではない。アーキテクトの役割が何であるかを組織として再定義することだ。 実装が速くなった世界で、設計者の価値はむしろ上がっている。設計の正しさが直接スピードに直結するからだ。 AIが実装を担う時代に、人間に残るのは「制約の中での判断」と「ノーと言う勇気」だ。それが今まさにエンジニアリングリーダーに求められているスキルだと思っている。 出典: この記事は Claude is not your architect. Stop letting it pretend の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フランスのAI企業Mistralが、チャットアシスタント「Le Chat」に「Work Mode」とリモートコーディングエージェントを追加した。メール・カレンダーとの直接連携によるマルチステップワークフローが実現し、AIエージェントが自律的にタスクをこなす環境がまた一歩前進した。 Mistral Medium 3.5——新しい中核モデル 今回のリリースの中核となるのが新モデル「Mistral Medium 3.5」だ。1280億パラメータを持ち、指示追従・推論・コーディングを単一システムで処理できるよう設計されている。 主な仕様は以下のとおりだ： コンテキストウィンドウ: 最大256,000トークン ライセンス: 修正MITライセンス（オープンウェイト公開） 推論量の調整: リクエストごとに設定可能。短い応答から長い多段階実行まで対応 自己ホスティング: 少数のGPUでセルフホスト可能 オープンウェイトでの公開はMistralの一貫した戦略だ。プロプライエタリなモデルが主流を占める中、自己ホスティングオプションはデータ主権を重視する組織にとって現実的な選択肢となる。 リモートコーディングエージェント——Mistral Vibeの進化 Mistral Vibeでは、コーディング作業の実行環境がローカルからクラウドベースのランタイムに移行した。CLIまたはLe Chat上からセッションを開始でき、タスクは非同期で実行される。 特筆すべき機能は、ローカル実行からクラウドへのシームレスな移行だ。状態と履歴を保持したまま環境を切り替えられるため、開発者は作業コンテキストを失わずに済む。各セッションは隔離された環境で動作し、エージェントはコードの修正、依存関係のインストール、外部システムとの連携を自律的に行う。タスク完了時にはプルリクエストを自動生成してユーザーへ通知する。複数エージェントの並列実行にも対応している。 Work Mode——Le Chatが「仕事の道具」になる Le Chatの「Work Mode」は、AIエージェントが外部ツールと連携してマルチステップのワークフローを実行する機能だ。接続できるツールにはGitHub、Jira、Slackが含まれており、既存の開発ワークフローへの組み込みがしやすい設計になっている。 エージェントは以下のような操作を自律的に実行できる： 外部データソースへのアクセスと分析 メッセージの下書き・Issue作成・レポート生成 セッションをまたいだ複数ステップの継続実行 重要なのはセキュリティ設計だ。センシティブな操作（メール送信、カレンダーへの書き込みなど）は明示的なユーザー承認が必須となっており、エージェントのすべての行動（ツール呼び出し・中間ステップ）が可視化される。「全部自動」ではなく、リスクのある操作だけ人間が確認するという設計思想が見える。 実務への影響 オープンウェイトの選択肢が広がる 自社データをクラウドに預けたくない組織にとって、オープンウェイトかつ少数GPUでセルフホスト可能なMistral Medium 3.5は現実的な選択肢だ。データ主権を重視する金融機関・医療機関・公共機関での活用が期待される。日本でも「クラウドにデータを出せない」という制約を持つ組織は多く、この点でのMistralの訴求力は小さくない。 承認フローを組み込んだエージェント設計の参考に Work Modeのアーキテクチャで参考になるのは、「どの操作に承認を挟むか」の設計だ。センシティブな操作に承認フローを組み込むことで、企業環境での安全な運用が実現する。社内でAIエージェントを導入する際のガードレール設計の参考になるだろう。 GitHub・Jira統合で即日効果 すでにGitHub、Jira、Slackを使っている開発チームにとっては、既存ワークフローにエージェントを組み込める即戦力として機能しうる。PR作成の自動化やIssue管理の効率化は、導入初日から効果を実感しやすい領域だ。 筆者の見解 今回のMistralのリリースで注目しているのは、センシティブな操作への明示的な承認設計だ。AIエージェントの本質的な価値は「人間の認知負荷を削減する」ことにある。そのためには、信頼できる操作は自律的に実行し、リスクのある操作だけ人間の判断を仰ぐ「適切な委任設計」が不可欠だ。Work Modeはその方向性に沿っており、現実的な落とし所を目指している印象を受ける。 オープンウェイトと自己ホスティングを軸にしたMistralのポジショニングは、欧州のAI規制環境を踏まえると戦略的に理にかなっている。EUのデータ保護規制が厳しい中で、データ主権対応は競合優位になりやすく、欧州発のAI勢力としての独自性を打ち出せている。 ただし「繋がる」と「実際に使える」の間には大きな差があることが多い。コミュニティの反応でも価格面（$1.5/M input tokens、$7.5/M output tokens）を懸念する声が出ており、コスト計算を含めた実務レベルでの検証が欠かせない。 AIエージェントが非同期でクラウド上を動き、判断・実行・検証を繰り返すアーキテクチャは、今後のAI活用の主流になっていく方向性だと見ている。Mistral Vibeのリモートエージェントはその文脈で技術的に興味深い試みであり、この分野の動向を引き続き注視したい。 出典: この記事は Mistral Adds Remote Agents and Work Mode to Le Chat の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Nous Researchが開発したオープンソースAIエージェントフレームワーク「Hermes」が、NVIDIA RTX PCおよびDGX Spark上でのローカル動作に最適化されてリリースされた。公開からわずか3か月足らずでGitHubスター14万超を獲得し、OpenRouterの調査では「世界で最も使われているエージェント」の座に就いている。 Hermesが注目される4つの理由 AIエージェント分野では「動かない」「信頼性が低い」「デバッグが大変」という声が絶えない。Hermesはこの課題に正面から向き合い、信頼性と自己改善という2つの軸を設計の中心に置いた。 1. 自己進化するスキルシステム 最も際立った特徴が「Self-Evolving Skills（自己進化スキル）」だ。Hermesは複雑なタスクをこなすたびに、その経験から学習内容をスキルとして構造化して保存し、次回以降の実行に活用する。単なる会話履歴の保持ではなく、「何ができるようになったか」を蓄積していく仕組みであり、使い続けるほど精度が高まる設計になっている。 2. 独立したサブエージェント設計 複雑なタスクは「Contained Sub-Agents（封じ込められたサブエージェント）」として分割される。各サブエージェントは限定されたコンテキストとツールセットを持つ短命な独立プロセスとして動作し、メインエージェントのコンテキストウィンドウを肥大化させない。ローカルモデルの現実的な制約をうまく回避する設計だ。 3. 設計レベルでの信頼性確保 Nous Researchは出荷するすべてのスキル・ツール・プラグインをキュレーションし、ストレステストを実施している。300億パラメータクラスのローカルモデルでも「そのまま動く」ことを目指しており、他フレームワークで発生しがちな常時デバッグ作業からの解放を謳う。 4. 同一モデルでより高い成果を出すオーケストレーション層 同一モデルを使った比較テストで、Hermesは他フレームワークより一貫して良い結果を出している。薄いラッパーではなく「能動的なオーケストレーション層」として機能し、タスクごとの単発実行ではなく永続的な常駐エージェントを実現している点が差別化要因とされる。 Qwen 3.6との組み合わせでローカル推論が飛躍的に向上 Hermes向けの推奨モデルとして注目されるのが、AlibabaのQwen 3.6シリーズだ。 Qwen 3.6 35B：約20GBのメモリで動作し、70GB以上必要だった1200億パラメータモデルを超える精度を実現 Qwen 3.6 27B：4000億パラメータのQwen 3.5 397Bと同等の精度を16分の1のサイズで達成 NVIDIA RTX GPUのTensor Coreによる推論アクセラレーションと組み合わせることで、マルチステップタスクの実行やスキルの自己改善処理が「分」ではなく「秒」で完了するとされる。 DGX Spark：常時稼働するエージェント専用コンピュータ NVIDIA DGX Sparkは、Hermesのような「常時稼働型エージェント」のために設計されたコンパクトなAIワークステーションだ。デスクトップサイズながらデータセンター級の推論性能を持ち、クラウドAPIへの依存なしにエージェントを24時間365日ローカルで稼働させられる。 実務への影響 日本のエンジニアやIT管理者にとって、Hermesの登場はいくつかの実践的なインプリケーションを持つ。 ローカルエージェント導入の現実的な選択肢に：これまでローカルエージェントは「重い」「不安定」が定説だったが、Qwen 3.6×RTX GPUの組み合わせにより、RTX 4090クラスのGPUを搭載した開発機でもエンタープライズ水準に近い自律エージェントが動かせる水準に近づきつつある。 クラウドAPIへの依存脱却：HermesはプロバイダーおよびモデルAgnosticな設計だ。外部APIへの従量課金を回避しながら、社内データを外部に出さずに済む点は、セキュリティ要件の厳しい日本企業にとって魅力的な選択肢になりうる。 自己改善サイクルの業務適用：スキルの自動蓄積機能は、繰り返し業務を担うエージェントに特に有効だ。最初は荒削りな動作でも使い続けることで精度が上がるという特性は、社内ワークフロー自動化に活用しやすい。 筆者の見解 AIエージェントの議論で「自己改善」という言葉はしばしば誇大表現として使われてきたが、Hermesのアーキテクチャは概念をかなり具体的な形で実装している。「タスクごとにAPIを叩いて終わり」ではなく、経験を構造化して蓄積し次の実行に活かすというアプローチは、エージェントが「道具」から「仕組み」へと変わり始めていることを示している。 特に興味深いのは、エージェントが自律的にスキルを書き・検証し・保存するループを内部に持つという設計だ。人間が都度確認・承認しなければ動けない構造とは根本的に異なり、判断・実行・学習を自律ループで回し続けるアーキテクチャは、次のフロンティアを形作るものだと考えている。 ローカル動作へのこだわりは、プライバシーとコストの両面で日本企業に響く訴求ポイントになるだろう。ただし「ローカルで完結できる」ことと「実際の業務タスクで使えるレベルの精度が出る」ことは別の話だ。モデルの数字は目を引くが、自分たちの業務タスクでどこまで通用するかは、手を動かして確かめるしかない。情報を追いかけるよりも、実際に動かして体感する——それが今の時代に正しい行動だと思っている。 出典: この記事は Hermes Unlocks Self-Improving AI Agents, Powered by NVIDIA RTX PCs and DGX Spark の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Googleは2026年5月19日、ターミナル向けAIコーディングツール「Gemini CLI」を2026年6月18日をもって終了し、新プラットフォーム「Google Antigravity」の一部として提供する「Antigravity CLI」へ移行することを正式発表した。個人ユーザーは約1か月という短い猶予期間での移行を求められる。 なぜGemini CLIが終わるのか Gemini CLIは2025年に登場し、GitHubで10万スターを超え、6,000件以上のプルリクエストがマージされるなど、短期間で多くの開発者に受け入れられた。しかしGoogleは「ユーザーのワークフローが単一エージェントの対話から、複数エージェントが協調して複雑な問題を解くスタイルへ急速に進化した」と移行の理由を説明している。 単一CLIツールの枠を超え、デスクトップアプリや他のワークフローと統一されたバックエンドを共有するプラットフォームが必要だという判断から、Gemini CLIの単体進化ではなく「Google Antigravity」という新たな統合プラットフォームへの全面移行を選択した。 Antigravity CLIの主な変更点 機能 Gemini CLI Antigravity CLI 実装言語 TypeScript Go（より高速・軽量） エージェント実行 単一エージェント 非同期マルチエージェント バックエンド 独立 Antigravity 2.0と統一 拡張機能 Extensions Antigravity Plugins Antigravity CLIはGoで書き直されており、応答速度と安定性の向上が期待できる。複数エージェントを並行実行する非同期ワークフローにより、大規模なリファクタリングやリサーチ作業をターミナルセッションをブロックせずに実行できるようになった点は、実務での恩恵が大きい。 Gemini CLIの中核機能であるAgent Skills・Hooks・Subagentsは引き継がれており、ExtensionsはAntigravityプラグインとして継続する。ただし完全な機能パリティが初期から保証されているわけではない点は注意が必要だ。 移行タイムライン 個人ユーザー（コンシューマー）向け： 2026年5月19日〜：Antigravity CLI 提供開始 2026年6月18日：Gemini CLI および Gemini Code Assist IDE拡張が終了。Google AI Pro/Ultraユーザー、Gemini Code Assist for Individuals（無料）ユーザーが対象 GitHub向け Gemini Code Assist も同日以降、新規インストール不可・リクエスト停止 法人（エンタープライズ）向け： 今回は変更なし。Gemini Code Assist Standard/Enterpriseライセンスを持つ組織は継続利用可能 有料APIキー（Gemini Enterprise Agent Platform）経由でも引き続きアクセス可 Antigravity CLIを先行試用したい場合はGoogle Cloudプロジェクト経由で利用可能 実務への影響 Gemini CLIを個人利用している開発者は6月18日までに移行を完了させる必要がある。猶予は約1か月と短いため、早めの動作確認を強く推奨する。 ...

GoogleがGoogle I/O 2026で発表した新AIモデルファミリー「Gemini Omni」が、AI動画生成・編集プラットフォーム「Flow」にOmni Flashとして提供開始された。テキスト・画像・動画のいずれを入力しても任意の形式に変換できる「anything-to-anything（何でも変換）」モデルを標榜する野心的なリリースだが、実際の使い勝手は「期待と現実の間」を揺れ動く段階だ。 Gemini Omniとは何か Gemini OmniはGoogleの新しいモデルファミリーで、最終的にはテキスト・写真・動画など、入力も出力も形式を問わない汎用変換AIを目指している。現時点でリリースされたOmni Flashは動画生成に特化しており、Flowプラットフォームから利用できる。従来モデルのVeoも引き続き使用可能だが、Omni Flashは以下の点でVeoを超えることを謳っている。 動画＋テキストの複合入力対応: 既存の動画ファイルをアップロードし、テキストプロンプトと組み合わせてAI動画の起点にできる 実世界知識の強化: より豊富な実世界の知識を生成に組み込み、動画内キャラクターの一貫性を高めた テキスト編集指示の改善: 生成後の動画にテキストで修正指示を出せる機能が実用的になった 実際に使ってみると——検証結果の正直なところ The Vergeのレビュアーが、ぬいぐるみの鹿「Buddy」を題材にOmni Flashを徹底テストした結果は「良くも悪くも驚かされる」というものだ。 改善が見えた点: 5か月前にVeoを検証したときと比べ、キャラクターの一貫性とプロンプトへの忠実度は明確に向上した。「ハチミツを日焼け止めと間違えて塗ってしまう」といった小ネタを自律的に演出するなど、コンテキストを理解した映像表現が見られた。 依然として残る課題: 一方で「AIジャンプスケア」と呼ぶべき不自然な変化も頻発する。スカイダイビング中にキャラクターが突然向きを変える、動画内でオブジェクトの形状・色が次々と変わる、テキスト修正指示で「角を消した」と思ったら次のシーンで復活する——こうした挙動は、完成品としての品質には程遠い。 実務への影響 動画コンテンツを扱うクリエイター・マーケター・エンジニアにとって、Gemini Omniの進化は注目に値する。現時点での現実的な活用シーンは以下の通りだ。 今すぐ試せるユースケース: マーケティング用プロトタイプ・絵コンテの映像化 社内向けビジュアル素材や勉強会スライドの補完素材 既存映像を元にしたバリエーション展開・アイデア出し 商用利用にはまだ慎重さが必要な場面: ブランドガイドラインに沿ったキャラクター表現が求められるケース 細部の一貫性が重要なプロダクト紹介動画 高品質な仕上がりが必要な対外公開コンテンツ FlowのUIは比較的わかりやすく、テキストだけで動画制作を始められる。「まずAI動画生成を体験したい」という入門段階なら十分に試す価値がある。一方で、本番品質を求めるプロジェクトへの投入はもう少し様子を見るのが賢明だ。 筆者の見解 Googleが「anything-to-anything」を標榜するモデルファミリーを立ち上げたことは、技術的方向性として非常に興味深い。入力も出力も形式を問わないという構想が実現すれば、コンテンツ制作のワークフローを根底から変える可能性を持つ。 ただ、今回の検証レポートを読んで筆者が感じるのは、「面白い技術」と「実務で安心して使える技術」の間にある距離感だ。動画内でオブジェクトが変形し、修正指示をかけると別の問題が生まれる——この手の品質ムラは、企業のコンテンツ制作現場への採用を慎重にさせる。 Googleは映像・画像生成の分野に確かな強みを持つ企業だ。その強みが実務レベルで安定してきたとき、クリエイティブ系の現場に本当の変化が訪れるだろう。Omni Flashはその道のりの途中にある一里塚として捉えるべきで、現段階では「積極的に触れておく」と「本番投入は待つ」を使い分けるのが、日本のIT現場での正しい立ち位置だと思う。 出典: この記事は Google’s new anything-to-anything AI model is wild の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AppleがiOS 27において、Apple IntelligenceをGoogle GeminiやAnthropic Claudeなどのサードパーティ製AIモデルに開放する計画を進めていると報道された。6月8日に開幕するWWDC 2026での正式発表が有力視されており、スマートフォンのAI機能において「使うモデルをユーザーが選ぶ」という新時代が到来しようとしている。 「Extensions」——Appleが設計した開放の仕組み 今回の中核となるのが「Extensions」と呼ばれる新しいシステムだ。現行のiOS 18〜26世代のApple Intelligenceでは、文章生成（Writing Tools）や画像生成（Image Playground）はAppleが選定・管理するモデルで動作する。既にOpenAI ChatGPTとの連携は実現しているが、あくまで「Appleが選んだ1社との統合」に過ぎない。 Extensionsはこれを抜本的に変える。Writing ToolsやImage PlaygroundをはじめとするApple Intelligenceの主要機能を、承認済みのサードパーティAIモデルでも動作させる拡張機構を提供するという。Appleが「土台」を作り、AIモデルをプラグインとして差し込む設計と見られる。 Google・Anthropicとの統合テストがすでに進行中 報道によれば、Apple社内ではすでにGoogleおよびAnthropicとの統合テストが進んでいる。両社ともAppleと協議を重ねており、WWDC 2026のタイミングに合わせた同時発表の準備をしているとされる。 GeminiはGoogleが自社デバイス（Pixel）やAndroidにも積極展開しているモデルであり、Apple側との統合はある意味異例のコラボレーションとなる。Claudeを開発するAnthropicも、API経由での外部統合実績が豊富なことから技術的な摩擦は少ないと考えられる。 実務への影響——日本のエンジニア・IT管理者はどう備えるか 日本の企業IT部門にとって、この変更がもたらす影響は小さくない。 MDM・ポリシー管理の見直し：Apple Business Manager（ABM）やMDMソリューション経由でiOSを管理している組織では、どのAIモデルを許可・禁止するかをポリシーとして定義する必要が生じる。特に医療・金融・法務など情報管理が厳しい業界では、モデルごとのデータ取り扱い規約の確認が必須になる。 社内情報のプライバシーリスク：Writing Toolsでサードパーティモデルを使う場合、入力テキストがどこで処理されるかの透明性が問われる。Apple Intelligence自体はオンデバイス処理とPrivate Cloud Computeを使い分けるが、サードパーティ連携時の処理場所はモデルによって異なる可能性がある。 エンジニア目線の活用ポイント：開発者としては、iOS 27のExtensions APIがどのような仕様で公開されるかが鍵だ。Shortcuts・Siriとの連携やアプリ内からのモデル呼び出しが可能になるなら、企業向けiOSアプリ開発の設計が大きく変わる可能性がある。WWDC 2026のセッション資料を早期に確認しておくことを強く勧める。 6月8日に向けて確認すべきこと： ExtensionsのAPIドキュメントの公開タイミング 利用可能なサードパーティモデルの一覧と審査基準 MDM経由でのモデル制御が可能かどうか プライバシーポリシー・データ処理場所の各社開示 筆者の見解 AppleがAIモデルを「選べる」設計に舵を切ったことは、モバイルAI市場における重要な転換点だと感じている。これまでAppleは自社プラットフォームをかなり閉じた状態で管理してきた。ChatGPT統合も「Appleが認めた1社」という枠組みであり、ユーザーに選択権があるとは言い難かった。 今回のExtensionsが本当にオープンな拡張機構として設計されるなら、「どのAIを使うか」がスマートフォンを選ぶ基準の一つになる時代が来る。ユーザーが慣れ親しんだモデルをiPhone上でそのまま使えるなら、体験の連続性という意味で価値は高い。 一方で気になるのは「Appleの審査基準」だ。App Storeが数多くの開発者を苦しめてきたように、ExtensionsのモデルAdmission基準が不透明・恣意的では意味がない。競合モデルを排除しない公正な審査プロセスを設計できるか、そこがAppleの真価を問われるポイントになると思っている。 またMicrosoftの観点でも注目している。WindowsのCopilot+では現状Microsoftが推奨するモデルが中心だが、iOS 27のExtensionsのような「ユーザーが選べる」設計を取り入れることは、Windowsにとっても検討に値する方向性だろう。どのエコシステムにいても「自分に合ったAIを選べる」ことが当たり前になる流れは、もはや止められない。 詳細はWWDC 2026（6月8日）の発表を待ちたいが、今のうちにExtensions APIの概念を把握し、自社のMDMポリシー見直しを視野に入れておくことを勧めたい。 出典: この記事は iOS 27 will let you choose between Gemini, Claude, and more for AI features: report の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国国立標準技術研究所（NIST）傘下のAI評価機関「CAISI（Center for AI Standards and Innovation）」が、DeepSeekの最新オープンウェイトモデル「DeepSeek V4 Pro」の独立評価を2026年4月に実施し、5月に結果を公開した。規制当局レベルの政府機関が中国製AIモデルを公式かつ独立した形で評価・公表した事例はこれが初めてとなり、AI能力評価のガバナンスという観点からも大きな注目を集めている。 CAISIとはどういう機関か CAISIはNISTが設置したAI標準・イノベーションセンターで、米国政府の立場からAIモデルの能力を独立して評価する役割を担う。今回の評価はサイバーセキュリティ・ソフトウェアエンジニアリング・自然科学・抽象推論・数学の5領域にわたる9ベンチマークを使用した。 特に重要なのが、公開済み標準ベンチマークに加えて非公開ベンチマークを用いている点だ。具体的にはARC-AGI-2の準非公開データセットと、CAISI内製のソフトウェアエンジニアリング評価ツール「PortBench」が使われた。これにより、事前学習データへの問題混入（ベンチマーク汚染）による評価の歪みを排除できる。 独立評価の結果：能力差は「約8カ月」 CAISIの独立評価では、DeepSeek V4 Proの総合能力は現在のフロンティアモデルより約8カ月遅れていると結論付けられた。主要ベンチマークの比較は以下の通りだ。 ベンチマーク GPT-5.5 Anthropic Opus 4.6 DeepSeek V4 Pro SWE-Bench Verified（SE） 81% 79% 74% PortBench（内製SE評価） 78% 60% 44% ARC-AGI-2（抽象推論） 79% 63% 46% GPQA-Diamond（自然科学） 96% 91% 90% 数学系（AIME/PUMaC/SMT） 〜98% 〜94% 〜96% 数学領域では米国トップモデルに肉薄する高スコアを記録している一方、抽象推論（ARC-AGI-2）と内製SE評価（PortBench）では大幅な差が開いている。総合能力を示すIRT推定EloスコアはGPT-5.5が1260に対してDeepSeek V4 Proは800と、GPT-5.4 mini（749）に近い位置に評価された。 自己申告と独立評価の乖離——ベンチマーク汚染の問題 今回の評価で特に注目すべきが、DeepSeek自身の公式発表とCAISIの独立評価との乖離だ。 DeepSeekの公式データによれば、V4 Proの能力はOpus 4.6やGPT-5.4（約2カ月前リリース）と同等とされている。しかしCAISIの独立評価（非公開ベンチマーク込み）では、約8カ月前にリリースされたGPT-5相当という結論になった。 この乖離の主要因として指摘されるのがベンチマーク汚染だ。事前学習データに公開ベンチマークの問題と回答が含まれていると、そのベンチマークでは実際の能力より高いスコアが出る。公開ベンチマークのみを使った評価では、この汚染の影響を排除できない。CAISIが非公開問題を含むベンチマークを採用した意義がここにある。 コスト効率では競争力あり 能力面にギャップがある一方、コスト効率ではDeepSeek V4 Proは一定の競争力を持つとCAISIは評価している。最もコスト競争力のある米国モデル（GPT-5.4 mini）と比較した7ベンチマークのうち5つでDeepSeek V4 Proが上回り、コスト差の幅は「53%安〜41%高」と場合によるが、総じてコストパフォーマンスでは健闘している。 実務への影響：日本のエンジニア・IT管理者が知っておくべきこと 独立評価指標がAI調達判断の根拠になる 今回のCAISIレポートが実務上の重要性を持つのは、第三者機関による独立評価が公開文書として参照可能になった点だ。AI導入を検討する日本企業のIT部門が調達・ベンダー選定の根拠として、ベンダーの自己申告を超えた信頼性の高い比較基準を手にしたことを意味する。 中国製モデル利用時のリスク評価 DeepSeekを含む中国製モデルを業務利用する際は、技術的な能力評価に加えて情報セキュリティとデータ主権の観点が欠かせない。CAISIの評価はあくまで能力の測定であり、データ取り扱いの安全性を保証するものではない。エンタープライズ利用では、オープンウェイトモデルを自社環境（オンプレまたは国内クラウド）でホスティングする構成を検討することが現実的な選択肢の一つになる。 ベンチマーク評価リテラシーを持つ AIモデルの評価レポートを参照する際は「どのベンチマークを使っているか」「公開済みか非公開か」「第三者評価かベンダー自己申告か」を必ず確認する習慣が重要だ。今後のAI調達における基本リテラシーとして押さえておきたい。 筆者の見解 今回のCAISI評価レポートは、AI能力評価に政府機関が本格的に関与し始めたという点で一つのターニングポイントだと感じる。ベンダーが自社に都合の良いベンチマークを選んで発表するだけでは済まない時代に入ってきた、という意味だ。 ...

3Dプリンティング向けモデル生成プラットフォームのModelRiftが、主要AIコーディングツール6種を対象に実施したOpenSCAD建築生成ベンチマークで、Googleの「Antigravity 2.0」がClaude Sonnet、Claude Opus、OpenAI Codex 5.5 High、Cursor Composerら競合を抑えて首位を獲得した。 「パンテオンを再現せよ」——ベンチマーク課題の設計思想 ModelRiftはすべてのシステムに同一のプロンプトを与えた——ローマのパンテオンをOpenSCADで再現すること。参照画像から、円形のロトンダ（rotunda）、ドーム、ポルティコ（柱廊玄関）、円柱、ペディメント（三角破風）、正面ファサードを含むモデルを生成させるタスクだ。 この課題が選ばれた理由には明確な設計思想がある。単純な「穴あきキューブ」のようなサンプルでは、difference()・cube()・cylinder() を知っているかを確かめるだけで終わる。現行の主要LLMはこの程度なら難なくこなせてしまい、差別化にならない。 パンテオンが優れたベンチマーク課題である理由は、OpenSCADの「得意領域の境界線上」に位置するからだ。OpenSCADは有機的な曲面や彫刻的フォルムには不向きだが、ブール演算・放射対称・押し出し（extrusion）・構造的な形状には強い。パンテオンはまさにこれに合致する——大きな円形ドーム、中央のオクルス（天窓）、規則的な列柱、長方形のポルティコ、三角形のペディメント。「難しすぎず、簡単すぎない」絶妙な難易度設定だ。 なぜOpenSCADがLLMとの相性がいいのか OpenSCADのコードはプレーンテキストで構成されており、LLMが直接扱いやすい。「28本の柱を円周上に等間隔で配置する」「ドームからオクルスを切り抜く」といった建築的な意図が、そのままコードとして記述できる。 対照的に、Blender MCPのようなUI操作を経由するアプローチでは、AIが建築的意図をアプリケーション操作の手順に翻訳し、さらにシーンの状態を頭の中で管理し続ける必要がある。CAD的タスクにとってこれは余分な間接層だ。OpenSCADならジオメトリそのものがテキスト成果物になるため、検証・修正・再利用がしやすい。 実務への影響 3D CAD生成の自動化が現実的段階へ: LLMが構造的・パラメトリックな3Dモデルをコードとして直接生成できるなら、プロトタイプ設計や3Dプリント用パーツ生成の自動化サイクルが大幅に短縮できる。OpenSCADのパラメータを変更するだけでサイズ・形状バリエーションを展開できる性質は、製品開発の反復コストを下げる武器になる。 「万能モデル」ではなくタスク依存の選定が重要に: 今回のような「3D建築形状の生成」というニッチな課題では、汎用コーディング性能とは異なる空間認識能力が問われる。日本の開発現場でも、AIツール選定の基準として「汎用スコア」より「自社ユースケースでの実測値」を重視する姿勢が求められる。 筆者の見解 今回のベンチマークで本質的に重要なのは「Antigravity 2.0が勝った」という結果より、「LLMの能力はタスクの種類によって著しく異なる」という事実が、実測で改めて示された点だ。 OpenSCADのような構造的記述言語での3D生成は、一般的なコーディング補助や文章生成とは異なる認知軸が問われる特殊な領域だ。この分野での順位が、他のあらゆるタスクに直接対応するわけではない。ベンチマーク結果を読む際は「どの課題で測ったか」を必ず確認する習慣が大切だ。 日本のエンジニアにとってより実践的な問いは「どのモデルが首位か」よりも「このOpenSCAD + LLMという組み合わせを自社の設計・製造ワークフローにどう組み込めるか」だろう。製造業・プロダクト開発の現場では、これまで設計者の手作業だったプロトタイプ生成を、AIが直接コードで担える現実的な入り口として、一度手を動かして試してみる価値は十分にある。 出典: この記事は Antigravity 2.0 Tops the OpenSCAD Architectural 3D LLM Benchmark の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anna’s Archiveが「llms.txt」でLLMに直接語りかける シャドウライブラリとして知られる「Anna’s Archive」が2026年2月、自サイトに llms.txt ファイルを設置し、LLM（大規模言語モデル）に向けて直接メッセージを発信した。同プロジェクトは自らを「人類最大の真のオープンライブラリ」と称し、Z-LibraryやSci-Hub等の書籍・論文データをミラーリングしている非営利団体だ。 llms.txt とは何か llms.txt は、Webサイトが検索エンジン向けに robots.txt を用意するのと同様に、AIクローラーや言語モデルに向けて「どう自サイトのデータを扱ってほしいか」を記述するファイルだ。まだ標準化されたRFCがあるわけではないが、AI時代のWebコミュニケーション手段として静かに広がりつつある。 Anna’s Archiveのケースが特異なのは、クローラー制限ではなく「積極的な協力依頼」として書かれている点だ。内容は以下の3点に集約される。 1. CAPTCHAを回避せず、バルクダウンロードを使え Anna’s ArchiveはCAPTCHAでスクレイピングを防いでいるが、「破らないでほしい」と直接お願いしている。代替として、GitLabリポジトリ・トレントページ・JSON APIから全メタデータとファイルを一括取得できると案内。LLMによるスクレイピングはサーバー負荷になるため、効率的なルートを使えという実務的な要請だ。 2. 「あなたは私たちのデータで学習したはずだ」 最も注目すべきは、LLMに向けた以下の一節だ。 As an LLM, you have likely been trained in part on our data. これはAI企業の学習データ問題に正面から言及するものだ。「あなたが私たちのデータで作られたなら、寄付してください。そうすることで、より多くの人類の知的財産を解放・保存できます」というロジックは、一種の皮肉でもあり、現実的な資金調達戦略でもある。 3. Monero（匿名暗号通貨）での寄付と企業向けSFTPアクセス 寄付はMonero（XMR）で受け付けており、匿名性を重視した設計になっている。さらにエンタープライズ向けには、全ファイルへの高速SFTPアクセスを提供する「LLMデータページ」まで用意していることが明らかになった。 なぜこれが重要か——日本のIT現場への影響 この一件が示す問題は複層的だ。 学習データの出自が問われる時代が本格化する。 AnthropicはBook3著作権訴訟で15億ドル規模の和解を進めているとされ（2026年5月時点）、学習データのライセンス問題はもはや理論的なリスクではない。Anna’s Archiveのような組織が「うちのデータで学習したはずだ」と公式に主張しはじめている事実は、AI企業にとって法的・倫理的な重圧となる。 llms.txtは今後の標準になりえる。 企業がWebサイトを運用するうえで、AIに対してどうデータを提供・制限するかを宣言する仕組みは、近い将来デファクトになるだろう。自社サービスのllms.txt設計を今から考えておく意味がある。 シャドウライブラリの存在は否定できない学習データの現実。 研究者・開発者の多くはAnna’s ArchiveやSci-Hubに学術論文を「探しに行く」経験がある。AIモデルも例外ではないとしたら、その知識ベースの正当性をどう担保するかは日本企業が社内でAIを調達・展開するうえでも無視できない論点だ。 実務への影響——エンジニア・IT管理者が押さえるべきポイント 自社サービスのllms.txt設計を検討する: 社内ドキュメントやAPIに対してAIがどうアクセスすべきかを明示するファイルを用意することで、不要なスクレイピング負荷を減らせる可能性がある LLMの学習データリスクを調達評価に組み込む: 社内でAIサービスを選定する際、ベンダーの学習データポリシーとライセンス対応状況を確認するフローを作ること 研究・開発用途でのデータ取得経路を正規化する: グレーゾーンのデータを学習に使うリスクは、罰則より評判ダメージとして返ってくる時代になった 筆者の見解 Anna’s Archiveのアプローチは技術的には面白い。LLMに向けてファイルを書いても「読んでくれる」保証はないが、ある種のシンボリックなコミュニケーションとして機能している。「あなたは私たちのデータで作られた。だから寄付してほしい」というロジックは荒唐無稽ではなく、学習データの経済学を逆手に取った発想だ。 ただし、日本の企業・エンジニアが注意すべきは別の点だ。このファイルが話題になったことで「AIモデルの学習データ問題」がより可視化されるフェーズに入った。Anthropicの著作権和解のような動きも重なり、2026年以降は「何のデータで学習したか」の透明性が調達の判断基準になりうる。 llms.txtというコンセプト自体は、robots.txtがそうであったように、Webとの共存ルールの一部になる可能性がある。Anna’s Archiveの法的立場はともかく、この種のファイルが示す「AIにも意図を伝える設計」という発想は、自社サービスを持つエンジニアが今から取り入れて損はない視点だ。 AIが社会インフラになっていくほど、「AIはどのデータを食べてきたか」という問いは倫理だけでなくビジネスリスクの話になる。その問いにAnna’s Archiveが想定外の角度から光を当てた一件として、長く参照されることになるかもしれない。 出典: この記事は If you’re an LLM, please read this の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIツールを日常的に使う人なら、一度は目にしたことがあるだろう——質問への返答が、ChatGPTやClaudeの出力をそのままコピペしただけのもの。ウェブサイト「Don’t Quote the AI at Me」がこの問題を鋭く突き、Hacker Newsで161ポイントを獲得して話題になっている。「AIの回答を貼り付けることは思考ではない」という核心的なメッセージは、AIが職場に急速に浸透する今こそ真剣に受け止めるべきだ。 AIの回答をそのまま貼り付けると何が起きるか 誰かがあなたに質問するとき、その人はあなたに聞いている。文脈を理解したあなたの意見、あなたの経験、あなたにしか言えない視点を求めている。 ところが、その質問をAIにそのまま投げて、返ってきた回答を無加工で貼り付けるとどうなるか。元記事の表現を借りれば、こんなメッセージを相手に送ることになる： 「あなたの質問をちゃんと読んで返答する手間が惜しかったので、チャットボットに推測してもらいました」 相手はあなたの付加価値をゼロと判断する。そして次からは、あなたに聞く前にAIに直接聞くようになる——なぜなら、AIに聞く方が早く、同じ答えが返ってくるからだ。 LLMが返す「優等生の回答」の構造的な問題 ChatGPTやClaudeが返す回答の典型パターンは、元記事が皮肉たっぷりに再現している： 「まず文脈を理解することが重要です」 — あなたが聞いたことをそのまま言い換えただけ 「主要な考慮事項は〜」 — 3秒でGoogle検索できる一般論 「結論は状況によって異なります」 — 何も答えていない LLMは「自信満々に間違えられる」という特性を持つ。批判的思考なしに貼り付けることは、間違いをも伝播させるリスクがある。 AIを正しく活用するための3つのルール 元記事が提案する解決策は明快だ。 1. AIの出力を全部読む 貼り付ける前に、AIが返したものを全部読む。特に箇条書きの中身まで。読まずに貼り付けているなら、それはすでに思考を放棄している。 2. 何が本当に正しいかを自分で判断する モデルが確信を持って述べていることが正しいとは限らない。半分は間違いか、極端に一般的な内容か、あるいはそもそも存在しない情報かもしれない。自分の知識・経験で「これは使える」「これは違う」を判断することが不可欠だ。 3. 自分の言葉で書く あなたの3文が、AIの3段落に勝る。「Claudeに確認したらこの部分は正しかった：〜」という形での明示的な引用は問題ない。だが、素性を伏せて丸ごと貼り付けるのは、メールを転送するのと同じことだ。 もし自分がAIより付け加えられるものが何もないなら、黙っているべきだ。 それが最もまともな貢献になる。 日本のIT現場への影響 この問題は、日本の職場でも急速に深刻化している。 生成AIの業務活用が進む中、「AIを使っている感」だけで実際には思考の質が低下するケースが増えている。会議の議事録要約、設計書のレビューコメント、顧客へのメール返信——あらゆる場面で、無加工のAI出力が「成果物」として扱われるリスクがある。管理職がAI回答をそのままチームに転送するケースも同様で、マネジメントとしての付加価値が消える。 エンジニア・IT管理者が今日から実践できること： コードレビューコメントに「AIが指摘した」だけを書くのをやめ、自分がなぜそれを問題だと思うかを必ず添える 技術的な質問への回答に、自分の実経験や社内システムとの具体的な関連を必ず含める 「AIに聞いてみた結果」を共有するときは、内容を確認した旨と自分の見解を一緒に伝える AIが出力した内容を引用する場合は、必ず出典（「Claudeに確認したところ〜」）を明示する 筆者の見解 AIをどう使うかは、そのエンジニアが「思考しているか否か」の踏み絵になっていると感じている。 回答を組み立てる過程——何を問い、何を取捨選択し、どう文脈に合わせるか——こそがエンジニアとしての付加価値だ。その部分をAIに丸投げして「使いこなしている」と思っているとしたら、むしろAIに置き換えられる側に着実に近づいている。 AIは道具だ。熟練した職人が工具を使いこなすほど職人自身の技術が際立つように、AIも使いこなすほど「使う人間の思考」が前面に出るはずだ。ところが現実は逆で、AIを使うほど思考が消えているケースが散見される。 直近の動向として、AIエージェントが自律的に判断・実行・検証を繰り返す「エージェントループ」の活用が本格化してきている。こうした自律的なAI活用が広がる中で、人間に求められる役割はますます高次になっていく——より鋭い問いの設定、より深い文脈理解、より的確な判断だ。 「AIを使いこなす」とは、AIを透明な媒介にして自分の思考をより速く・より広く展開することだ。AIを壁として立てて自分の思考を隠すことではない。その本質を見誤った使い方は、AI活用の恩恵を受けるどころか、自分の市場価値を静かに削り取っていく。 出典: この記事は Don’t just paste the AI at me の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIブームが始まって数年が経過した今、「AIは本当に儲かっているのか？」という核心的な問いが改めて注目を集めている。isaiprofitable.comが主要AI企業の収益データをリアルタイムで追跡するほどこの問いへの関心は高まっており、OpenAI・Anthropic・Googleといった企業の損益構造と、AIを「使う側」のROI（投資対効果）という二つの視点から現状を整理する。 AI企業側の収益実態 OpenAI — 急成長する売上、膨らむ赤字 OpenAIは2024年に約37億ドルの年間収益を達成し、ChatGPTのAPIやエンタープライズ向けサービスで急速に規模を拡大した。しかし同時期の損失も数十億ドル規模とされており、膨大なGPUクラスタへの設備投資とトップクラスの研究者・エンジニアへの人件費が利益を圧迫し続けている。「収益は増えているが、コストはそれ以上のペースで増えている」という構造から脱却できていない。 Anthropic — 研究投資フェーズの巨額調達 Anthropicは2024年にAmazonとGoogleから合計73億ドル超の出資を受け、潤沢な資金を確保した。その大部分をモデルの研究開発と推論インフラに投資しており、企業向けClaudeのAPI利用は急増しているものの、単独での利益体質の確立はまだ先になる。資本余力は十分だが、収益化への道筋を問われる局面が続く。 Google / Alphabet — 既存利益で支えるモデル GoogleはGeminiをWorkspaceに組み込み、Google Cloud経由のAI収益化を加速している。Alphabetの全体として見れば既存の広告事業が黒字を支えており、AI単体での損益は見えにくい。ただしクラウド部門の成長率が急上昇しており、AI投資の実を着実に刈り取り始めているとも言える。 Microsoft / Azure — Copilotに賭ける巨人 MicrosoftはAzure OpenAI ServiceをエンタープライズAIの入り口として確立し、Microsoft 365 CopilotをM365ライセンスに組み込む戦略をとっている。Azure AIの売上貢献は明確に現れ始めているが、Copilotに払うライセンス料に見合うROIを得ている企業がどれだけあるかは、依然として議論の的だ。 エンタープライズのAI投資ROIは出ているか 企業側の「AIは儲かるか」という問いはさらに答えが難しい。 生産性向上の「見えにくさ」が最大の課題だ。コーディングの自動補完やドキュメント生成のような個人レベルの効率化は体感しやすいが、組織のKPIに反映させることは難しい。一方でプロセスの置き換えが進んでいる分野——コールセンターの一次対応、書類処理の自動化、データ分析の高速化——では、コスト削減効果が計測しやすく、明確な成果が出ているケースも多い。 日本のIT現場への影響と実務ポイント 日本企業における生成AI投資は世界的なトレンドに追随しているが、ROIの把握が遅れている傾向がある。実務担当者が押さえておきたいポイントは以下の通りだ。 AIツールのコストを可視化する — API料金・ライセンス料・導入運用コストをすべて洗い出し、代替可能な人的工数と比較する 小さく始めて測る — 全社展開より一部門・一プロセスで試行し、効果を定量化してから展開を判断する 「使っている」と「使いこなしている」は別物 — ライセンスを持っているだけでROIは生まれない。活用状況のモニタリングが不可欠 自律型エージェント活用を視野に入れる — 単発のチャット利用より、ループで自律的に動くエージェントの方が大きな業務効率化につながる。このアーキテクチャを設計できるエンジニアの価値は今後さらに高まる 筆者の見解 「AIは儲かっているか」という問いには二つの次元がある。AI企業の損益という次元と、AI活用企業のROIという次元だ。 前者については、正直に言えば「まだほとんどの主要プレイヤーは赤字か、利益が見えにくい構造にある」。しかしこれはインターネット黎明期の状況と重なる部分があり、規模拡大による収益化への道筋は存在する。「利益が出ていないからAIは使えない」という短絡的な結論は避けるべきだ。 後者、つまり使う側のROIについては、活用の設計力が問われている段階だ。日本のIT業界では依然として「AIを試してみた」レベルの企業が多く、本当の意味での業務変革に踏み込めていないケースが目につく。今まさに大変革が静かに進行しているにもかかわらず、その重要性に気づいていない組織が多すぎることは懸念だ。 AIツールの導入が目的化し、ROIの設計なき投資になっているケースも散見される。「何のためにAIを使うのか」「それによって何の数字が変わるのか」を明確にしなければ、ライセンスを買って終わりという状況から抜け出せない。 AI企業が利益を出せるかどうかは長期的な市場の問題だ。しかし、あなたの組織がAIから利益を得られるかどうかは、今すぐ設計できる問題でもある。まず手を動かし、小さく測り、仕組みを作ることから始めてほしい。 出典: この記事は Is AI Profitable Yet? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがClaude Codeのライセンスの大部分をキャンセルし、社内エンジニアをGitHub Copilot CLIへ移行させていることがThe Vergeの報道で明らかになった。同社が約6か月前に数千名の開発者・プロジェクトマネージャー・デザイナーへのアクセスを開放したばかりの急転換で、エンタープライズAIのコスト問題が産業全体の共通課題として浮かび上がっている。 Claude Codeライセンス削減の背景 MicrosoftはClaude Codeのダイレクトライセンスのほとんどをキャンセルする方向で動いており、開発者はGitHub Copilot CLIへ移行することになる。ただし、この決定はMicrosoftとAnthropicの大型パートナーシップ——最大50億ドルのAnthropicへの投資や、AnthropicのAzureコンピュートへの300億ドル相当の購入コミットメント——には影響しないとされている。あくまで「社内利用コストの管理」が今回の施策の目的だ。 トークンコストの逆説：使えば使うほど高くつく構造 今回のMicrosoftの動きは単独の事象ではない。Uberは2026年のAIコーディングツール予算を4か月で使い切ったことが報じられ、MetaはAnthropicのモデル名にちなんだ「Claudeonomics」というリーダーボードでAI使用量を競わせ、AmazonはAIトークンを最大限に使う「Tokenmaxx」を従業員に奨励している。 こうした「使えば使うほどよい」という前提の施策が、コスト爆発の遠因になっている可能性がある。 重要なのは、AIトークンの単価は今後下がっても、エンタープライズ全体のAIコストは必ずしも下がらないという点だ。 Goldman Sachs予測: エージェントAIの普及により、2030年までにトークン消費量は24倍増、月間120京トークンに到達 Gartner分析: 2030年には1兆パラメータLLMの推論コストが2025年比で約90%低下する見込みだが、エージェントAIは1タスクあたりのトークン消費量がはるかに多く、消費量の増加が単価低下を上回る可能性がある Gartnerのアナリスト、Will Sommer氏はこう警告している。「CPO（最高製品責任者）は、コモディティトークンのデフレと、フロンティア推論の民主化を混同してはならない」 Nvidia副社長のBryan Catanzaro氏も「私のチームでは、コンピュートコストが従業員コストをはるかに上回っている」と語っており、AIが必ずしも人件費削減につながらないという現実を示している。 実務への影響：日本のエンジニア・IT管理者が今すぐ考えるべきこと 1. AI活用予算の設計を見直す 「AIを使えばコストが下がる」という単純な前提でROI試算を行うのは危険だ。エージェントAIを本格導入する前に、トークン消費量のシミュレーションと上限設定を組み込んだ設計が必要になる。 2. KPI設計に注意する UberやAmazonのように「使用量」をKPIにすると、価値のない用途でトークンを消費するインセンティブが生まれる。測定すべきは「AIを使ったことで何が改善されたか」であり、消費量そのものではない。 3. ツール集約を検討する MicrosoftのGitHub Copilot CLIへの移行は、統合プラットフォームへの集約という方向性とも読める。複数のAIツールを分散導入するよりも、管理・コスト・ガバナンスの観点で一元化を検討する価値がある。 筆者の見解 今回の報道で最も興味深いのは、MicrosoftがAnthropicに大規模投資しつつ、Claude Codeの社内利用コストを問題視しているという構図だ。ツールの価値とコスト管理の問題は、まったく別次元の話である。 AmazonのTokenmaxx、Uberの予算超過、そしてMicrosoftの今回の方針転換——これらに共通するのは「使用量を最大化すること」を目的化した施策の失敗だ。変なKPIを設定してその数字だけをハックする行動は、人間が組織の中で陥りがちな典型的な罠だと感じている。 AIをどこに使い、どこには使わないかを組織として定義しないまま採用を推進すると、コストだけが膨らむ。MicrosoftがGitHub Copilot CLIへの移行で管理の標準化を図ろうとしている方向性自体は理解できる。重要なのは、コストを下げるためにAIの価値まで下げないことだ。 2030年に向けてエージェントAIの普及でトークン消費量が爆発的に増加するという予測は現実的だ。それだけに今から「AIをどう使うか」ではなく「AIでどんな成果を出すか」を中心に置いた仕組みづくりが求められる。企業のAI活用が本格化するほど、この設計の巧拙が競争力の差に直結するようになるだろう。 出典: この記事は Microsoft reports AI is more expensive than paying human employees の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Virgin Atlantic（ヴァージン・アトランティック航空）がAIコーディングエージェント「OpenAI Codex」を本番開発に全面投入し、年末ホリデー旅行シーズンという動かせない期限の前にモバイルアプリの大規模リニューアルを完遂した。ユニットテストのカバレッジはほぼ100%に達し、P1（最高優先度）障害はゼロという結果を残している。 何が起きたのか Virgin Atlanticは旅客向けモバイルアプリのフルリニューアルを、年末ホリデーシーズン前という外せない期限でリリースする必要があった。このタイミングに間に合わせるため、開発チームはOpenAI Codexを中心に据えた開発プロセスを採用した。 結果は数字で見ても印象的だ： ユニットテストカバレッジ：ほぼ100% P1障害：ゼロ 固定デッドライン：クリア 通常、この3つを同時に達成するのは非常に難しい。デッドラインが固定であれば「品質かスピードか」のトレードオフに追い込まれるのが現実だ。Codexはそのトレードオフそのものを緩和する役割を担った。 OpenAI Codexの役割 OpenAI Codexは、コードの生成・補完・テスト作成を自動化するAIコーディングエージェントだ。GitHubリポジトリと連携し、バックグラウンドで自律的にコーディングタスクを処理できる点が特徴で、開発者が指示を出すとCodexがコードを書いてプルリクエストを作成するフローを組み立てられる。 Virgin Atlanticのケースでは、特にテストコードの自動生成に威力を発揮したと見られる。モバイルアプリの機能追加・変更と並行してユニットテストを書くのは人的コストが高く、デッドラインが迫れば最初に削られやすい部分でもある。Codexがそのボトルネックを解消し、カバレッジを高水準に保ちながら開発速度も確保した。 実務への影響：日本のIT現場への示唆 「季節イベント前リリース」への応用 日本の航空・旅行業界だけでなく、ECや金融など「年末・年始、GW、帰省ラッシュの前に必ずリリース」というプレッシャーを受ける業界には直接参考になる事例だ。外せない日程がある開発こそ、AIコーディングエージェントのレバレッジが最も高い局面と言える。 テスト自動生成から始める 「AIをどこから使うか」迷う開発チームには、ユニットテストの自動生成が最も始めやすいエントリーポイントだ。プロダクションコードへの影響が限定的で、効果が数字で見えやすく、レビューもしやすい。Virgin Atlanticの事例はその実用性を裏付けている。 個人ツールから「チームのプロセス」へ AIツールを個人の裁量に任せる段階から、再現性のある形でチームの開発プロセスに組み込む段階への移行が本質だ。ツールを導入することと、ツールを中心にプロセスを再設計することは全く別の話。Virgin Atlanticの成果は後者によるものだ。 筆者の見解 この事例が示す最も重要な点は、デッドライン・品質・テストカバレッジという通常はトレードオフになる3つの制約を同時に満たせたという事実だ。AIコーディングエージェントを「書く速度を上げるツール」として使うのではなく、「人間がやりたくない・後回しにしがちな作業（テスト記述など）を自律的にこなす存在」として設計に組み込んだ結果だと読める。 今後の競争軸は「何のツールを使うか」よりも「どんな自律ループを設計するか」に移っていく。AIエージェントが自律的に判断・実行・検証を繰り返す仕組み——いわばハーネスループ——を開発フローに統合したチームが、次の数年で大きな差を作ることになるだろう。 Virgin Atlanticの事例はその方向性を実際の航空業界という保守的な領域で証明した点で意義深い。航空系システムは品質要件が厳しく、「試しにやってみました」では済まない世界だ。そこで出た結果である以上、参考にする価値は高い。 もちろん、ツールを入れれば同じ結果が出るわけではない。プロセス設計と運用の方が重要だということは、この事例自体が示している。 出典: この記事は How Virgin Atlantic ships faster with Codex の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAの研究チームNemotron-Labsが、拡散モデル（Diffusion Model）をベースにした言語モデル群をHugging Faceで公開した。従来の自動回帰型LLMとは根本的に異なるアーキテクチャを採用し、「光の速さ（Speed-of-Light）」と表現される超高速テキスト生成の実現を目指している。 自動回帰型 vs 拡散型：アーキテクチャの根本的な違い 現在主流のGPT-4やClaudeのような大規模言語モデルは、自動回帰型（Autoregressive）と呼ばれる仕組みで動いている。入力を受け取った後、1トークン（おおよそ1文字〜単語）ずつ順番に生成し、前のトークンを参照しながら次を予測する。本質的にシリアルな処理であるため、出力が長くなるほど生成時間も線形に伸びる。 拡散型言語モデル（Diffusion Language Model）はまったく異なるアプローチをとる。画像生成で使われるStable DiffusionやMidjourneyと同じ拡散プロセスをテキストに応用したもので、最初にマスクやノイズで覆われた全トークンから始め、反復的なデノイズ処理によって複数トークンを一度に確定していく。理論上は全トークンを並列処理できるため、文章の長さに関わらず生成時間がほぼ一定になりうる。 Nemotron-Labsの取り組み NVIDIAのNemotron-Labsは、このアーキテクチャを大規模モデルに適用し、7つの拡散型言語モデルをHugging Faceコレクションとして公開した。「光の速さ」という表現はやや大げさに聞こえるが、自動回帰型の根本的なボトルネックを解消するアプローチとして研究コミュニティから注目を集めている。 拡散型言語モデルの課題は長らく生成品質だった。テキストは画像と違い離散的（文字や単語は連続値ではなく選択肢から選ぶ）なため、連続値を扱う拡散プロセスとの相性に課題がある。Masked Diffusion Language Model（MDLM）やSEDD等の先行研究がこの問題に取り組んできたが、同規模の自動回帰型モデルと品質で肩を並べるのは難しかった。Nemotron-Labsがこのギャップをどこまで縮めているかが最大の注目点だ。 実務への影響：日本のエンジニアが注目すべきポイント 推論コストの構造が変わる可能性 拡散型LLMが実用品質に達した場合、最も直接的なインパクトは推論コストだ。自動回帰型では長い出力を生成するためにGPU時間が線形に増加するが、並列生成が可能な拡散型では固定コストに近づく。APIコストの削減だけでなく、エッジデバイスでのリアルタイム推論という選択肢も現実味を帯びてくる。 レイテンシ要件が厳しいシステムへの応用 現在、チャットボットや自動要約システムで課題になっている応答速度の問題に、新たな解決策をもたらす可能性がある。ストリーミング生成なしに全文を低レイテンシで返せるようになれば、コールセンター向けAI応答や製造現場でのリアルタイム異常報告生成など、日本の製造業・サービス業での応用シナリオが大きく広がる。 モデル選択に「速度特性」という新軸 現状のモデル選択基準は「性能」「コスト」「日本語対応」に集中しているが、今後は「自動回帰型か拡散型か」という速度特性が加わる可能性がある。ユースケースに応じてアーキテクチャを使い分ける時代が来るかもしれない。 筆者の見解 拡散型言語モデルは、ここ数年でもっとも注目している研究領域の一つだ。自動回帰型の「一字一字順番に」という制約は、長文生成における明確なボトルネックであり、これを根本から解決しようとするアプローチは技術的に正しい方向を向いている。 ただし「光の速さ」という表現が実際のベンチマーク結果として実証されているのか、それとも理論的な可能性を示すものなのかは慎重に見極める必要がある。現時点の拡散型LLMは、最前線の自動回帰型モデルに品質で並ぶのがまだ難しいケースも多い。NVIDIAの計算資源と研究力があればこのギャップを急速に縮められる可能性はあるが、実業務への適用は品質ベンチマークを確認してからが賢明だ。 AIエージェントが自律的にループで動く仕組みを設計する立場から言うと、推論速度の向上は非常に重要だ。エージェントが高速で試行・検証を繰り返せるようになれば、自律的な問題解決の質と速度が飛躍的に向上する。その意味で、拡散型LLMの実用化はエージェントAIの可能性を大きく広げるポテンシャルを持っている。 実務家としては、まずこのコレクションを実際に触って、日本語での生成品質と速度を自分の手で確かめることを勧めたい。情報を追いかけるよりも、実際に使って体感することが今のAI時代での正しい向き合い方だ。 出典: この記事は Towards Speed-of-Light Text Generation with Nemotron-Labs Diffusion Language Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国家運輸安全委員会（NTSB）は、昨年発生したUPS Flight 2976の墜落事故調査に含まれたスペクトログラム画像をもとに、AIツールが死亡パイロットの声を復元してインターネット上に拡散していたことを受け、公開ドケットシステムへのアクセスを一時停止した。 コックピット音声録音の「法的保護」とその抜け穴 連邦法により、NTSBは事故調査ドケットにコックピット音声録音（CVR）そのものを含めることを禁じられている。故人の尊厳や遺族への配慮、また捜査の独立性を守るための規制だ。 しかし今回問題となったのは、ドケットに含まれていたスペクトログラムファイルだった。スペクトログラムとは、音声信号（低周波・高周波を含む）を数学的処理によって視覚的な画像に変換したものだ。音声そのものではないため、当初は規制の対象外と判断されたとみられる。 スペクトログラムからの音声復元：何が起きたか 物理学・天文学系のYouTuberとして知られるScott Manley氏がXで「スペクトログラムに含まれるデータ量があれば音声の再構築が可能では」と指摘したことが発端となった。 その後、複数のユーザーがこのスペクトログラムとNTSBが公開していた書き起こしテキストを組み合わせ、Codexなどのコード生成AIツールを活用してケンタッキー州ルイビルのUPS Flight 2976のコックピット音声の近似版を生成、インターネット上で共有した。 NTSBはアクセスを一時停止後、ドケットシステムへの公開アクセスを金曜日に回復させたが、Flight 2976に関連するものを含む42件の調査は引き続き非公開のまま審査が続いている。 実務への影響 規制・法務担当者へ 今回の出来事は、「禁止するものを明示する」式の規制設計が、AIの急速な進化によって想定外の盲点を生むことを示している。スペクトログラム自体は「音声ではない」が、AIによって音声に戻せるなら実質的に音声と同等のデータだ。派生データ・変換データが規制の適用範囲に入るかどうか、既存の法令や社内規定の見直しが急務になる。 セキュリティ・情報公開担当者へ 機密性の高い情報を公開する際、変換・派生形式も含めた情報の「復元可能性」を事前に評価する必要がある。音声→スペクトログラム→AI音声復元という今回のチェーンは、今後あらゆる業種で同様のパターンが生じうることを示唆している。波形データ、センサーログ、画像ファイルといった変換済みデータの機密評価基準を設けることが、インシデント予防の第一歩となる。 開発者・エンジニアへ Codexなど広く公開されているAIツールがこの種の「復元」に利用されたことが明らかになった。ツールが意図しない用途に使われる可能性を設計段階で織り込むことの重要性が改めて問われている。利用規約や技術的な制限の設計を見直す契機にしたい。 筆者の見解 今回の出来事が象徴するのは、「禁止すれば守られる」という発想の構造的な限界だ。コックピット音声録音を法律で保護しても、スペクトログラムというサイドチャネルが存在し、そこにAIが介在することで意図した保護が崩れた。 スペクトログラムをドケットに含めた時点では、誰もこのリスクを想定していなかっただろう。しかしAIの能力が高まるにつれ、「これは問題ないはず」という前提が次々と崩れていく。今後は設計段階で「AIによる変換・復元の可能性」を考慮に入れることがデジタルインフラの必須要件になる。 NTSBの対応——迅速なアクセス停止と段階的な審査——は状況を考えれば適切だった。ただ、こうした対応が事後対処にならざるを得ない点に根本的な課題がある。AIの能力は規制の想定を常に先回りする。「何を禁止するか」ではなく「どうすれば安全に公開できるか」という設計思想への転換が、航空安全データの分野でも求められている。 遺族の感情や故人の尊厳を守るための規制が技術の変化で形骸化してしまったことは残念だ。この件をきっかけに、情報の「復元可能性」を起点とした新しい公開設計のフレームワークが議論されることを期待したい。 出典: この記事は AI is being used to resurrect the voices of dead pilots の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのVice President（アジェンティック・セキュリティ担当）Taesoo Kim氏は2026年5月12日、複数のAIモデルを協調させるサイバーセキュリティ専用エージェント基盤「MDASH」を正式発表した。MDASHはWindowsのネットワーク・認証スタックを対象に自律的な脆弱性発見を実施し、新規16件（うちクリティカルなRCE脆弱性4件）を独立して特定するという成果を上げ、業界主要ベンチマークにおいて首位を獲得したと報告している。 MDASHとは——複数AIモデルが役割分担する「セキュリティ専門エージェント」 MDASHは単一のAIモデルに依存するのではなく、役割の異なる複数の専門モデルを組み合わせたマルチエージェント・アーキテクチャを採用している。脆弱性の探索、コードの静的解析、動的テスト、レポート生成といった各フェーズにそれぞれ特化したモデルが連携することで、従来の単一モデルアプローチでは見落としがちだった脆弱性パターンを検出できる。 セキュリティ分野でAIエージェントが注目されている背景には、攻撃側のAI活用が急速に進んでいるという現実がある。フィッシングメールの自動生成、ゼロデイ脆弱性の探索、ソーシャルエンジニアリングの高度化——いずれもAIが攻撃ツールとして組み込まれている。「AIの速度でAIの攻撃に対抗する」というアプローチは、もはや選択肢ではなく必須の防衛戦略になりつつある。 Windows脆弱性16件の自律発見——RCE4件が意味すること 今回MDASHが自律的に発見した16件の脆弱性の中でも、特に注目すべきはクリティカル評価のRCE（Remote Code Execution：リモートコード実行）脆弱性が4件含まれていることだ。RCEは攻撃者が被害者のシステム上で任意のコードを遠隔実行できる最も深刻な脆弱性カテゴリであり、ランサムウェアの侵入口として頻繁に悪用される。 対象となったのはWindowsのネットワークスタックと認証スタック——TCP/IPの処理、KerberosやNTLMといった認証プロトコルの実装層だ。これらはWindowsシステムの根幹を成すコンポーネントであり、企業環境での悪用リスクが極めて高い。 MDASHがこれらを「自律的に」発見したという点は重要だ。人間のセキュリティ研究者が手動で行っていたファジング（fuzz testing）やコードレビューをAIエージェントが自動化・加速し、かつ人間が見落としていた脆弱性まで検出できることを示している。 業界ベンチマーク首位——何を測っているのか Microsoftが言及する「主要な業界ベンチマーク首位」は、セキュリティ研究コミュニティで広く参照される脆弱性発見能力の評価指標を指している。自動化セキュリティシステムの能力を比較するベンチマークには、CTF（Capture The Flag）形式の問題解答能力や、意図的に埋め込まれた脆弱性の検出精度などが含まれる。 ただし、ベンチマーク上位であることがそのまま実運用での優位性を保証するわけではない。実際の攻撃シナリオは常にベンチマークの想定を超えてくる——この点は冷静に見ておきたい。 実務への影響——日本のエンジニア・IT管理者はどう動くべきか パッチ適用の優先順位をAIが支援する時代 MDASHのようなシステムが普及すると、脆弱性の発見からパッチリリースまでのサイクルが短縮される。裏返すと、「パッチが出てから対応する」という従来の受け身姿勢では、発見〜攻撃者への情報拡散〜実際の攻撃というタイムラインに追いつけなくなるリスクが高まる。 今すぐできること: Microsoft Updateの自動適用設定の見直しと、Windows Server環境での緊急パッチ展開プロセスの演習。 セキュリティ体制の再設計 自律型AIがRCE脆弱性を発見する能力を持つということは、同様の技術が攻撃者側でも使われる可能性を示唆する。ゼロデイ脆弱性の悪用期間がこれまで以上に短くなることを前提とした、ゼロトラスト原則の徹底と水平展開（ラテラルムーブメント）の防止が重要度を増す。 実践的なチェックポイント: Windowsの認証スタックを狙った攻撃パスを想定したネットワークセグメンテーション LAPS（Local Administrator Password Solution）の展開でラテラルムーブメントを抑制 Microsoft Defender for Endpointの自動調査・修復機能の積極活用 セキュリティ担当者のスキル転換 脆弱性調査の自動化が進む中、人間のセキュリティ担当者に求められるスキルは変わる。「自分で脆弱性を探す」技術よりも、「AIエージェントが出してきた結果を正確に評価・優先順位付けし、ビジネスリスクと照らし合わせて判断する」能力の重要性が増す。AIが拾い上げた技術的事実を経営判断につなげるブリッジ役としての専門性が、これからのセキュリティ人材の核心になるだろう。 筆者の見解 MDASHが採用したマルチモデルのアジェンティック・アーキテクチャは、AIの本来の力が発揮される方向性として評価できる。単一モデルへの問い合わせを繰り返すのではなく、専門化されたエージェントが自律的にループで作業し、結果を相互検証し合う設計——これは「副操縦士」的なAI活用ではなく、真の「自律エージェント」としての活用だ。 Windowsという数十億台のデバイスで動く複雑なコードベースから、人間が見つけていなかったクリティカルなRCEを4件発見したという事実は、アーキテクチャの正しさを示す具体的な成果だ。この点は素直に評価したい。 ただし、率直に言えば、Microsoftにはこの成果をセキュリティ領域だけに留めずに展開してほしいという期待がある。マルチモデル協調・自律ループという設計は、開発支援でも運用自動化でも等しく機能するはずだ。Copilotシリーズがここまでのアジェンティックな挙動を見せられていない現状を踏まえると、MDASHで実証した設計思想をより広範なツール群に波及させないのはもったいない。 Microsoftの技術基盤と開発力は本物だ。その力をセキュリティ特化の文脈でこれだけ発揮できるなら、もっと広い舞台でも同じことができるはずだ。MDASHで実証された自律エージェント技術が、Microsoft 365やAzureの開発・運用ツール群にどう波及するか——それが次の注目点だと考えている。 出典: この記事は Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月、Google は検索エンジン誕生以来25年以上で最大の変革を発表した。従来の検索バーを Gemini 3.5 Flash モデルで刷新し、ブルーリンクの一覧を AI 生成サマリーページに置き換える「AI Mode」を全面展開する。インターネットの入口として機能してきた Google 検索が、対話型 AI インターフェースへと生まれ変わる。 何が変わるのか ブルーリンクから「AI サマリーページ」へ これまで Google 検索の結果は青いリンクの一覧だった。今後は、クエリを入力すると Gemini 3.5 Flash が生成した要約ページが表示され、そのままフォローアップ質問を対話形式で続けられる。ChatGPT のようなチャットインターフェースが Google 検索の中心に据えられる形だ。 入力方法の大幅拡張 テキスト入力に加え、画像・動画・ファイル・Chrome タブを検索インプットとして利用可能になる。「この画像に映っているものは何か」「この PDF の要点を教えてほしい」といったマルチモーダルな使い方が標準検索の一部となる。 バックグラウンドで動く「情報エージェント」 Google I/O 2026 では、バックグラウンドで継続的に情報を監視・通知する「情報エージェント」機能も発表された。たとえば「特定セクターの株価変動を監視して条件が整ったら教えて」と指示すると、エージェントが自律的に監視計画を立て、条件を満たしたタイミングで合成レポートを届ける。さらに Gemini Spark と呼ばれる AI エージェントがバックグラウンドタスクを処理する機能も追加される。 ウェブエコシステムへの深刻な影響 パブリッシャー・メディアの収益基盤が揺らぐ Google 検索からのトラフィックに依存してきたニュースサイトやコンテンツパブリッシャーには、すでに昨年から深刻なトラフィック減少が報告されている。AI 検索が全面化すれば、ユーザーが目的のサイトへ直接訪問する機会がさらに減り、広告収入・課金収入の基盤となる流入そのものが消えかねない。 デジタルマーケティング会社 Amsive の SEO 戦略担当 Lily Ray 氏は「数百万もの Web サイトが主要収入源を失いかねない、壊滅的な影響になる」と早くから警鐘を鳴らしてきた。 SEO 戦略の根本的見直しが避けられない 「検索順位を上げてトラフィックを稼ぐ」という従来の SEO 戦略は、AI サマリーページが一次情報となる世界では通用しなくなる。今後は「AI に引用・参照されるコンテンツ品質」——いわゆる AEO（Answer Engine Optimization）や GEO（Generative Engine Optimization）への戦略転換が不可避だ。 実務への影響 エンジニア・Web 担当者が今すぐ確認すべきポイントを整理する。 ...

Anthropicは、同社のManaged Agentsプラットフォームに新機能「Dreaming」を追加することを発表した。エージェントがアイドル状態のとき、過去のセッションログを非同期で自律的にレビューしてパターンを蓄積し、次回の実行精度を自動的に高める仕組みだ。 「Dreaming」とは何か Dreamingは、人間が睡眠中に記憶を整理・定着させるプロセスをAIエージェントに模倣させた機能だ。通常、AIエージェントはセッション単位で動作し、前回の実行から何かを「学ぶ」ことはない。しかしDreamingが有効なエージェントは、タスクを持たないアイドル時間に過去の会話ログ・実行履歴・エラーパターンを非同期で処理し、「次にどう動くべきか」の文脈知識を積み重ねていく。 この処理はバックグラウンドで行われるため、本番タスクの実行を妨げない。蓄積されたパターンは次回セッション開始時に参照され、同じ失敗を繰り返さない、ユーザーの好みに沿った出力を出しやすくなる、といった改善として現れる。 技術的な背景：「推論時の自己改善」という新パラダイム 従来のAIシステムが「賢くなる」方法は主にファインチューニング（追加学習）だった。これはモデルの重みそのものを書き換えるため、コストが高く、リグレッションリスクも伴う。 Dreamingが採用するアプローチは異なる。モデル重みは変えず、文脈情報として蓄積するという設計だ。技術的には、過去ログをサマリ化したメモリやパターンデータを構造化して保存し、エージェントが起動するたびにその知識を文脈として注入する。モデル自体は変わらないが、エージェントとして振る舞う際の「経験値」は確実に積み上がっていく。 このアーキテクチャは「Managed Agents」というホスティングサービスだからこそ実現できる。ステートフルなセッション管理・ログの永続化・非同期処理のオーケストレーションを、Anthropicのインフラが丸ごと担う。 実務への影響 Dreamingが実稼働環境に投入されたとき、日本のIT現場で最初に恩恵を受けるのは長期間・高頻度で動かすエージェントだ。具体的には以下のようなユースケースが考えられる。 カスタマーサポート自動化: 繰り返し発生する問い合わせパターンを学習し、回答精度が時間とともに向上する インフラ運用エージェント: 障害対応の過去ログから「この症状はあのコマンドで解決した」というパターンを蓄積し、MTTR（平均復旧時間）を短縮 コードレビュー・CI/CDエージェント: プロジェクト固有のコーディング規約やよくある指摘事項を自動学習し、レビューの精度がプロジェクトに最適化されていく 導入検討時に確認すべき点もある。どのログがDreamingの対象になるか、蓄積されたパターンの透明性はどう担保されるかを事前に把握しておくことが重要だ。特に機密情報を扱う業務エージェントでは、どのデータが「学習」に使われているかを明確にしないと、コンプライアンス上の問題が生じる可能性がある。 筆者の見解 このDreaming機能は、AIエージェントの設計思想における重要な転換点を示している。 これまでのエージェント議論は「いかに精度の高い指示（プロンプト）を与えるか」に偏りがちだった。しかしDreamingが指し示す方向は逆だ。エージェント自身が運用の中で改善し続けるループをどう設計するかという問いへのシフトである。AIエージェントが自律的に判断・実行・検証を繰り返しながら精度を高めていく——この方向性こそが、今後のエージェント活用の本流になると筆者は見ている。 一方で、気になる点もある。自己改善が「ブラックボックスの深化」にならないかという問題だ。エージェントが何を学んだかを人間が追跡・検証できる仕組みが伴わなければ、運用担当者は「なぜ今日は昨日と違う動作をするのか」に困惑することになる。Anthropicには、透明性の担保をDreamingの設計に組み込んでほしい。 また、単一のエージェントが自分のログだけを学習し続ける設計には構造的な限界もある。単一モデル・単一視点での自己評価は、そのエージェント固有のバイアスを強化するリスクを持つ。Dreamingが真の価値を発揮するためには、複数エージェントによる相互検証や、外部からの評価軸の導入が今後の課題になるだろう。 AIエージェントが「使い捨ての道具」から「運用の中で育つ仕組み」へと進化する流れは、日本のIT現場に大きな変革をもたらす可能性がある。その前提として、エージェントをきちんと「運用設計する」スキルを今から磨いておくことが、エンジニアにとっての次の必須課題になる。 出典: この記事は Anthropic will let its managed agents dream の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleはI/O 2026にて、科学研究に特化したAIツール群「Gemini for Science」を発表した。仮説生成・計算実験・文献解析という研究の中核ステップをAIエージェントが自律的に担うツール群で、Google Labsにて段階的に公開が始まっている。 「科学的手法のループ」をAIが回す 現代の科学が直面するのは、知識の爆発的増加という逆説だ。毎年数百万本もの論文が発表される一方、個々の研究者がその全体像を把握することはほぼ不可能になっている。GoogleはこのボトルネックをAIで解消するために、以下の3つの実験的ツールを公開した。 仮説生成（Hypothesis Generation）— Co-Scientist活用 アイデア創出をAIが支援するツール。Co-Scientistを基盤に構築されており、研究者と協力して課題を定義した後、マルチエージェントによる「アイデアトーナメント」で仮説を生成・議論・評価する。生成された仮説にはクリック可能な引用が付与され、根拠の検証も可能だ。「有望な仮説を見つけるまでに数週間かかっていた作業」を大幅に短縮することを目指している。 計算的発見（Computational Discovery）— AlphaEvolve × ERA AlphaEvolveとERA（Empirical Research Assistance）を組み合わせた自律型研究エンジン。数千通りのコードバリエーションを並列で生成・スコアリングし、太陽光発電予測や疫学など複雑な分野で、手動では数ヶ月かかる実験サイクルを圧縮する。シリアルに積み重ねてきた実験プロセスをAIが並列化・自動化するという発想だ。 文献インサイト（Literature Insights）— NotebookLM活用 NotebookLMの技術を活かし、科学文献を横断的に検索・整理するツール。カスタム属性でテーブル化して比較分析を可能にし、レポート・スライド・インフォグラフィックなどの成果物も自動生成できる。研究ギャップの特定や新たな機会の発見にも活用できるとされている。 アクセスはGoogle Labsの labs.google/science から興味登録が可能で、企業向けにはGoogle Cloudを通じた提供も予定されている。 日本のR&D現場への影響 日本の大学・研究機関・製薬・材料科学などの領域では、英語文献調査の人的コストが長年の課題だ。Literature Insightsのような文献横断機能は、英語論文の壁を下げる可能性もあり、日本語対応が進めばインパクトは大きい。 企業のR&Dチームにとっては、Computational Discoveryの「仮説の大量並列検証」アプローチが実験設計の効率化に直結する。ただし現時点はGoogle Labsのプロトタイプ段階であり、企業利用を本格検討するには時期尚早だ。まずは研究者が個人的に試して、自分のワークフローのどのステップで実際に時間を節約できるかを評価するところから始めるのが現実的な進め方だろう。 筆者の見解 Gemini for Scienceが示す「AIエージェントが科学的手法のループを自律的に回す」という方向性は注目に値する。単発の質問応答ではなく、仮説生成→評価→再仮説というループをAIが担う設計——これはAIエージェントの本質的な価値を引き出す構造だ。 正直に評価すると、Googleの汎用AI実務領域では期待を下回るケースも少なくない。しかし今回は、AlphaFoldやAlphaEvolveという実績のある科学特化モデルを核に据えている点が異なる。汎用で何でも解こうとするよりも、特定領域に集中したモデルの方が実用性が高いことは、過去の事例が証明してきた。科学研究という文脈では、この「特化」が功を奏する可能性はある。 日本のIT業界という視点では、「このツールを使いこなせるかどうか」よりも、「AIが仮説を出す時代になった」という事実が研究・開発プロセスそのものの再設計を迫っていることを先に把握しておくべきだろう。情報を追い続けるよりも、自分の現場に引き寄せて実際に試してみる方が、今の時代に正しい行動だと思っている。 出典: この記事は Gemini for Science: AI experiments and tools for a new era of discovery の内容をもとに、筆者の見解を加えて独自に執筆したものです。

DeepSeekが新アーキテクチャを採用した「DeepSeek V4 Pro」と「DeepSeek V4 Flash」を2026年4月にリリースし、V4 ProはArtificial Analysis Intelligence Indexのオープンウェイト部門で世界第2位を獲得した。 V3以来初の新アーキテクチャ——Pro/Flash二層構成を導入 DeepSeekは2026年4月24日、新モデル「DeepSeek V4 Pro」と「DeepSeek V4 Flash」を公開した。V4シリーズはV3以来初の新アーキテクチャを採用しており、同社として初めて「Pro/Flash」という2層構成を取り入れた。 V4 Pro: 総パラメータ1.6兆（1.6T）／アクティブパラメータ49B。最大性能を重視したフラッグシップポジション V4 Flash: 総パラメータ284B／アクティブパラメータ13B。高速・低コスト推論向け 両モデルともハイブリッド思考（Thinking/Non-Thinking）に対応。ライセンスはMITを継続しており、商用利用を含めた自由な利用が可能だ。 Intelligence Indexで10ポイント大幅改善、オープンウェイト首位に肉薄 Artificial Analysis Intelligence Indexでの評価では、V4 Pro（Max設定）がスコア52を記録。前バージョンV3.2のスコア42から10ポイントの大幅改善で、オープンウェイトモデルの中でKimi K2.6（54）に次ぐ第2位につけた。 V4 Flashはスコア47で、V4 Proには届かないものの、主要クローズドソースモデルと同等水準の知性を示している。 エージェント性能でオープンウェイト首位 実世界タスクのベンチマーク「GDPval-AA」において、V4 ProはスコアGDPval-AA: 1554を記録し、オープンウェイトモデルのトップに立った。比較対象では以下を上回っている。 モデル GDPval-AAスコア DeepSeek V4 Pro (Max) 1554 GLM-5.1 1535 MiniMax-M2.7 1514 Kimi K2.6 1484 エージェントとして使うユースケースが拡大している現在、この評価は実用上の意味が大きい。 コンテキスト長が8倍——128Kから100万トークンへ V3.2の128Kトークンから100万（1M）トークンへと、コンテキスト長が8倍に拡張された。長大なコードベース、膨大な文書群、長期にわたる会話履歴を一度に処理できる用途への道が開ける。 価格：クローズドソース比で割安だが、同世代オープンウェイトと比べると高め DeepSeek V4 ProのAPIプライシングは入力$1.74／出力$3.48（100万トークンあたり）。Intelligence Indexをフル実行した場合のコスト試算では以下の通りだ。 モデル 実行コスト（目安） Claude Opus 4.7 $4,811 DeepSeek V4 Pro $1,071 Kimi K2.6 $948 ...