生成AI

Amazonが社内でAI利用状況をスコアリングし従業員間でランキング表示していた「AIリーダーボード」を廃止した。スコアを上げることが目的化し、本来の生産性向上から外れた使い方が横行したためだ。 なぜAIリーダーボードを導入したのか 企業がAI活用を推進する際、「どれだけAIを使っているか」を可視化・競争させる手法は一見合理的に見える。Amazonもその発想から、社内AIツールの使用状況をスコアリングしてランキング表示するシステムを導入した。目標は明快で、AI活用の底上げと組織全体の生産性向上だ。 何が問題になったか ところが、リーダーボードはすぐに逆効果を生み出した。従業員たちはスコアを稼ぐために意味のない形でAIを使い始めた。本当に効果的な活用かどうかにかかわらず、数字を上げることが目的になってしまったのだ。 これは組織心理学でいう「グッドハートの法則」の典型例だ——「指標が目標になった瞬間、それは良い指標ではなくなる」。AIの場合、「プロンプト送信回数」「トークン消費量」といった量的データは測定しやすい反面、本来の成果（品質向上・業務効率化）との乖離が生じやすい。Amazonはこの問題を認識し、スコアランキングの仕組みそのものを廃止する判断を下した。 実務への影響——日本企業はAI活用KPIをどう設計すべきか この件は日本のIT現場にとっても対岸の火事ではない。多くの日本企業が「AI活用率の向上」を重点目標に掲げており、似たような指標設計を検討中のところも少なくない。 避けるべきKPI設計 AIツールのログイン回数・送信回数によるランキング トークン消費量や使用時間の可視化競争 「AIを使ったかどうか」のみを問うバイナリな評価 検討すべきKPI設計 AIを活用した業務の成果物品質（コードレビュー通過率、ドキュメント品質スコア等） 業務完了にかかった時間の変化（AI活用前後の比較） 従業員自身がAI活用の効果を報告する定性サーベイと定量指標の組み合わせ 重要なのは「AIを使ったという行為」ではなく「AIを使って何が良くなったか」を測ることだ。AI活用の底上げには動機付けと仕組みの両方が必要であり、「使わなくていい」という免罪符を与えると形骸化する。組織としてAIで効果を出した事例を共有し、「こう使えば成果が出る」という実践的なパスを示すことが本質だ。 筆者の見解 Amazonのこの判断は正しい。数字のランキングで競わせるアプローチが機能しないことは、少し考えれば予想できた範囲だ。一方で、「AI活用度を組織的に上げたい」という問題意識自体は正しい方向であり、指標設計の失敗と目的の正しさは切り分けて考えるべきだろう。 今の時代、エンジニアがAIを積極的に活用しないこと自体がリスクだと思っている。AIを使いこなせる人とそうでない人の生産性差は今後さらに広がっていく。だからこそ、組織としてAI活用を後押しする仕組みは必要だし、「使わなくてもいい」という空気を作ることは避けるべきだ。 ただし手段として「リーダーボードで競わせる」のは最悪の方法だった。人間は計測された指標をハックする生き物だ。スコアが目的になった瞬間に仕組みは壊れる。正しいアプローチは、「使えばこう成果が出る」という体験を組織内で設計・共有すること。AIを使った方が明らかに楽で速くて良い成果が出る——そういう状況を先に作ることが、KPI設定よりも優先されるべきことだろう。数字は後からついてくる。まず成功体験を設計せよ、というのがAmazonの失敗から学べる最大の教訓だ。 出典: この記事は Amazon scraps AI leaderboard to stop workers chasing usage scores の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropic、Mistral、Google DeepMind、Metaの4社が2026年5月18〜24日の5日間に、それぞれ異なるAIスタートアップを取得した。いずれも「M&A」とは公表されず、タレントディールや技術ライセンスとして構造化されている点が特徴だ。 1週間で4件——見逃されていた「集約の波」 各社の取引を整理する。 Anthropic → Stainless（SDKインフラ、$300M超）: OpenAPI仕様から自動でSDKを生成するインフラ企業。OpenAI・Google・Cloudflareも依存していた。買収後、Stainlessのホスト型サービスは終了予定。Anthropicが欲しかったのは「開発者がAI APIと対話する仕組みを設計する技術力」であり、製品そのものではない。 Mistral → Emmi AI（物理シミュレーションAI）: ウィーン発のスタートアップで、計算流体力学や熱伝達を従来のFEM（有限要素法）ソフトウェアなしでシミュレートする物理考慮型AIを開発。30名超の応用物理研究者チームを獲得し、欧州産業AI市場への展開を強化する。 Google DeepMind → Contextual AI（$80〜90Mのライセンス構造）: 合併として分類されることを避けるための構造化ライセンス契約として締結。チーム全員を実質的にDeepMindへ移籍させる形を取った。 Meta → Dreamer（アクワイハイヤー）: 詳細は非公表だが、チームの技術力を取り込む形での取得とされる。 これらは個別のニュースとして散在したが、同週に4件が重なったことは偶然ではなく、業界構造の変化を示すシグナルだ。 数字で見る「集約」の実態 2026年5月18〜24日週のAI資金調達全体は$353億（約5.3兆円）に達したが、そのほぼ全額はAnthropicの$300億調達（バリュエーション$9,000億）が占める。これを除いた60件の合計は$53億にとどまり、前週比で70%減となっている。 指標 5/18〜24 5/11〜17 変化 件数 61件 84件 −27% 合計 $353億 $228億 +55% 中央値 $2,100万 $1,460万 +44% 最大除く合計 $53億 $178億 −70% 件数は減少し、最大ラウンドを除いた資本量も大幅に縮小している。成長資本が「広く薄く」ではなく、特定のフロンティアラボへ集中している構造が鮮明だ。 「タレントディール」構造が独禁回避の標準手法に Stainlessの事例が示すように、フロンティアラボはすでに「$300M規模なら既存バリュエーションの誤差範囲」という規模に達している。この非対称性が生み出すのは、資金力で買収を加速する一方、形式上M&Aと見なされないよう巧みに構造化するという手法の標準化だ。 Contextual AIのケースでは、$80〜90Mのライセンス契約という枠組みで実質的な人員移籍を実現した。欧州・米国の規制当局がAI市場の集約に対して厳しい目を向け始めている中、こうした「規制の隙間を使う構造設計」が業界全体に広まっている。 日本のエンジニア・IT管理者への実務的示唆 1. 採用した技術スタックの「買収リスク」を常に評価する Stainlessの事例では、OpenAIやGoogleが依存していたSDKインフラが突然サービス終了となる。自社システムが依存するOSSライブラリや外部SDKを提供する企業が買収された場合、継続性を確認するプロセスが必要だ。 2. Mistralの産業AI展開は日本製造業への波及を意識せよ Emmi AIが持つ物理シミュレーションAIの技術は、製造・設計工程のデジタルツイン化に直結する。FEMソフトウェアのライセンスコストに悩む日本の中堅製造業にとって、Mistralのエンタープライズ展開がどこまで日本市場に来るかは注目に値する。 3. 企業内AIツール調達では「買収後の継続性」を契約条件に含める AI業界のM&A加速期においては、今使っているSaaSや開発ツールが数ヶ月後に別の企業の傘下に入っている可能性が常にある。調達・契約段階で、サービス廃止時の移行条項を検討することが現実的な対策だ。 筆者の見解 今回の「5日間4件」という出来事を個別ニュースとして消費してしまうと、重要なトレンドを見落とす。これはフロンティアラボが「内製より買収が速くて安い」という判断を実行フェーズに移したことを意味する。特定の能力ギャップを埋めるために億単位の支出を即断できる体力が、ごく一部のプレイヤーに集中しつつある。 Stainlessの買収で筆者が注目するのは「$300Mを超えるSDKインフラ企業を買ってホスト型サービスを終了させる」という判断の合理性だ。開発者エコシステムの設計力そのものを取り込むために、製品の継続性を切り捨てている。これは「ユーザーへの影響より自社戦略を優先する」という行動の証左でもあり、どのラボの技術に乗っかるかを選ぶ際の判断材料にすべきだ。 Microsoftはこの週に大型買収を発表していない。だが、$900億規模のAnthropicと同じ土俵でM&Aを競うのではなく、すでに手中にある膨大なエンタープライズ資産（Teams・M365・Azure）を通じたエージェントAIの展開こそが、Microsoftらしい戦い方のはずだ。資金力勝負ではなく、エコシステム統合の深度で勝負できる立場にある。その強みを生かし切る展開を期待したい。 AI業界は「誰でも参加できるオープンな競争」から「資本力とエコシステムを持つ者が独占する構造」へと移行しつつある。この変化に無自覚のまま「とりあえず使えるAIサービスを導入」するだけの企業は、気がつけば特定プレイヤーへの依存度が取り返しのつかないレベルに達していることになる。今こそ、技術選定を戦略的に行う時だ。 出典: この記事は Four labs, four acquisitions in five days: the consolidation signal hiding in plain sight の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Anthropicが「Claude Managed Agents」に2つの新機能を追加した。エージェントのツール実行環境を自社インフラ上に構築できる「セルフホストサンドボックス」がパブリックベータとなり、社内ネットワーク内のプライベートMCPサーバーへ安全に接続できる「MCPトンネル」もリサーチプレビューとして登場した。機密データを一切外部に出さずにAIエージェントを本格活用したいエンタープライズ企業にとって、待望のアップデートだ。 セルフホストサンドボックス：エージェントの「手」を自社管理下に AIエージェントがコードを実行したりファイルを操作したりするサンドボックス環境を、自社インフラまたは信頼済みのマネージドプロバイダー（Cloudflare・Daytona・Modal・Vercel）上に置けるようになった。 アーキテクチャの分離がポイントだ。文脈管理やエラー回復を担う「エージェントループ」はAnthropicのインフラに残るが、ツールを実際に動かす部分だけが自社の管理下に移動する。この設計により： 機密ファイルやリポジトリがAnthropicのサーバーに届かない 既存の社内ネットワークポリシーや監査ログがそのまま適用される CPUやメモリなどのコンピューティングリソースを自社でチューニングできる 実例として、機関投資家向けAIプラットフォームのRogoはManaged AgentsとVercel Sandboxを組み合わせ、独自の財務データを扱うアナリストエージェントを構築中だ。マーケティングデザインツールを開発するAmplitudeも、Cloudflareとの組み合わせでより細かい可観測性と制御を実現しているという。 MCPトンネル：社内ネットワークを「穴を開けずに」つなぐ MCPトンネルは、外部からアクセスできない社内ネットワーク上のMCPサーバーへ、エージェントが接続するための仕組みだ。従来なら社内リソースをAIエージェントに使わせるには、パブリックエンドポイントの公開やファイアウォールの穴開けが必要だった。 MCPトンネルの設計は逆転の発想だ。社内に軽量なゲートウェイを1台置き、アウトバウンド接続を1本張るだけで済む。インバウンドのポート開放は不要で、通信はエンドツーエンドで暗号化される。Claude ConsoleからAdmin権限で設定管理できるため、運用面のハードルも低い。 社内データベース、プライベートAPI、ナレッジベース、チケットシステムなど、これまで「外部AIには渡せない」とされてきたリソースが、エージェントのツールとして利用可能になる。Managed AgentsとMessages API両方でサポートされているため、既存のAPI利用者も取り入れやすい。 実務への影響 セキュリティ担当者の視点：AIエージェントの活用をセキュリティリスクを理由に制限してきた組織でも、既存のセキュリティ境界を壊さずに導入できる選択肢が生まれた。「クラウドAIへの外部送信を認めていない」という制約を、システム設計で解決できるのは大きな前進だ。 エンジニア・アーキテクトの視点：MCPトンネルは特に実用的だ。VPNや複雑なネットワーク設定なしに、既存の社内ツールをそのままAIエージェントのツールとして公開できる。社内システムへのアクセスをMCPサーバーとして実装しておけば、エージェントが自律的に横断利用できる基盤ができあがる。 コスト設計の視点：Vercel・Cloudflare・Modalなどのマネージドプロバイダーを使えば、自前でKubernetesクラスターを組む必要がなく、初期投資を最小化できる。サブ秒単位の起動時間と数十万並列サンドボックスに対応するModalのような選択肢もある。 筆者の見解 AIエージェントが本格的にエンタープライズに入っていくためには、「データをどこで処理するか」という問いに答えられる設計が不可欠だった。今回のアップデートは、その問いへの一つの明確な回答だ。 特に注目したいのは、設計の方向性がよく考えられている点だ。エージェントループをAnthropicが管理し続けながら、ツール実行環境だけを切り離して自社の管理下に置く——この分離は、セキュリティと運用の両立として理にかなっている。全部自社でホストするよりも現実的だし、全部クラウドに任せるよりもセキュリティ要件に応えやすい。 自律的に判断・実行・検証を繰り返すハーネスループ型のAIエージェントが実業務に入っていくためには、こうした「信頼できる境界の中で動ける」アーキテクチャが土台として必要だ。MCPトンネルが「社内のあらゆるシステムをエージェントのツールにできる」可能性を開く点は、今後の発展が楽しみなところだ。 日本企業の文脈で考えると、厳格な情報セキュリティポリシーを持つ金融・医療・製造業などの業種で、AIエージェント活用の「現実解」として真剣に検討できるレベルになってきた。「AIは外部にデータを送るから使えない」という理由での先送りが、一つ崩れ始めている。 出典: この記事は New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが社内エンジニアに展開していたAnthropicのClaude Codeのライセンスを大幅に削減し、GitHub Copilot CLIへの移行を促していることが明らかになった。同時期にUberでもAIコーディングツールの2026年予算がわずか4ヶ月で底をついたと報告されており、「AIは人件費より安い」という前提に疑問符が付き始めている。 Claude Codeの社内展開から削減まで、わずか6ヶ月 Microsoftは約6ヶ月前、数千人のエンジニア・デザイナー・プロジェクトマネージャーを対象にClaude Codeの利用を推進し、ツールは急速に社内に広まったとされる。しかしThe Vergeなどの報道によれば、Microsoft社内ではClaude Codeのライセンスの大部分を削減し、代替としてGitHub Copilot CLIへの移行が指示されているという。 ただし注意すべき点がある。この変更はAnthropicとのビジネス上の提携全体を見直すものではない。MicrosoftはAnthropicとの多額の「Foundry」契約を維持しており、顧客向けClaudeモデルへのアクセスも継続される。あくまで社内利用のスケールを絞ったという変更だ。 UberでもCTO自ら証言——2026年AI予算が4月に枯渇 同様の問題はUberでも起きている。CTOのPraveen Neppalli Naga氏が4月に「AIコーディングツールの2026年予算をすでに使い切った」と発言した。社内でAI活用の競争を促すインセンティブを設定した結果、想定を超えた勢いで予算が消化されたとされる。「使え」と煽りすぎた結果、コストが爆発したというパターンだ。 「採用より高コスト」という不都合な数字 Goldman Sachsはエージェント型AIによるトークン消費が2030年までに24倍に膨らみ、月あたり120京トークンに達すると予測している。一方でGartnerのアナリストWill Sommer氏は「コモディティトークンの価格低下を、フロンティアモデルの民主化と混同すべきではない」と警告する。NVIDIAのBryan Catanzaro氏も「私のチームではコンピューティングのコストが人件費をはるかに超えている」と発言している。 先進的なAIモデルほど1タスクあたりのトークン消費が多くなるため、単純に「AIで自動化→人件費削減→ROIプラス」という計算が成り立たないケースが増えている。 実務への影響——「インフラ投資」として予算設計する時代へ 今後の企業AI活用では以下のポイントが重要になる： 使い道を絞る: すべての業務にAIを投入しても自動的にROIは出ない。繰り返し処理・大量調査・ドラフト生成など効果が出やすいタスクに集中投資する 利用量の上限設計: Uberの事例のように、インセンティブ設計を誤ると予算枯渇を招く。利用量モニタリングとコスト上限（キャップ）の設定は必須 トークン消費の可視化: どの作業・どのモデルでどれだけ消費しているかを把握し、費用対効果の分析に組み込む AIを「人員削減の代替」ではなく「生産性の乗数」として位置づける: 代替ではなく増幅という視点の方が、ROI計算もより現実的になる 筆者の見解 AIのコストが思ったより高い——この事実は業界全体が正直に向き合うべき話だ。「AIを導入すればコスト削減できる」という単純なメッセージで経営層を動かしてきた企業は、今まさにこのギャップに直面している。 Microsoftがコスト管理の観点からClaude Codeの社内展開を縮小した判断は、経営的には理解できる。とはいえ、コスト圧力が「より低い性能のツールへの移行」という形に落着するのはもったいない。Microsoftにはエンジニアリング力もインフラも揃っているのだから、コストを抑えながらも優れたAI体験を提供できる仕組みを作れるはずだ。「どの作業にどのレベルのAIを当てるか」を設計できるポテンシャルが、Microsoftには間違いなくある。 大企業が「とにかく使ってみる」フェーズから「ROIを見ながら使い方を設計する」フェーズへ移行しているのは、ある意味で健全な成熟と言える。AIは万能薬ではない。適切なタスクに適切な規模で当てる「設計力」こそが、これからの企業AI活用の勝負どころになるだろう。 出典: この記事は Microsoft data suggests using AI is more expensive than hiring people の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フォルクスワーゲンの車両連携サービス「Volkswagen Connect」に対応したHome Assistant向けサードパーティ統合「homeassistant-volkswagencarnet」が、2026年5月27日ごろから突然ログイン不能になる障害が相次いで報告されている。原因はVolkswagenがAPI認証にOAuth 2.0の「クライアントアサーション（client assertion）」を要求する仕様変更を実施したことにあると見られており、公式アプリは引き続き正常に動作する一方、サードパーティの連携が実質的にシャットアウトされた形だ。 クライアントアサーションとは何か クライアントアサーションとは、OAuth 2.0認証フロー（RFC 7521）において、クライアントアプリが自身の正当性を「署名付きJWT（JSON Web Token）」で証明する仕組みだ。 通常のOAuth認証では、クライアントIDとクライアントシークレット（パスワード相当）をサーバーに送るだけで済む。しかしクライアントアサーション方式では、クライアントが事前に登録した秘密鍵でJWTに署名し、その署名を検証できる登録済み公開鍵がサーバー側に存在しなければ認証が通らない。 つまり「Volkswagenが正式に認定したアプリ」以外はログイン自体ができなくなる。VolkswagenのAndroidアプリや公式Webブラウザ経由のログインは問題なく動作しているため、Volkswagenが意図的に非公式クライアントを排除する変更を行ったと考えるのが自然だ。 Home Assistantとvolkswagencarnetの背景 Home Assistantは世界で最も広く使われているオープンソースのスマートホームプラットフォームだ。Volkswagen Connect APIに対応したインテグレーション「homeassistant-volkswagencarnet」はGitHubで500スター以上を獲得しており、世界中のフォルクスワーゲンオーナーが車の位置情報確認・ドアロック状態モニタリング・EV充電状態管理などをホームオートメーションに組み込んできた。今回の変更により、こうした自動化シナリオが一切動作しなくなった。 自動車メーカーとオープンAPIの緊張関係 この問題は、コネクテッドカー領域で繰り返される「メーカーによるAPI制限」の最新事例だ。制限の背景として考えられる理由は複数ある。 セキュリティ上の懸念: 未審査のサードパーティアプリが車両制御APIにアクセスすることのリスク 利用規約の遵守: 車両データの商用利用・再配布を防ぐ目的 責任の所在: 非公式クライアント経由の操作でトラブルが起きた際の責任問題 ビジネス戦略: 自社エコシステムへの囲い込み 一方でHome Assistantコミュニティを中心に「自分が所有する車のデータに自分がアクセスする権利がなぜ制限されるのか」という批判が上がっている。EUでは近年、自動車データへの利用者アクセス権を保護する議論も進んでおり、今後の規制動向が注目される。 日本のエンジニア・IT管理者への影響 日本においても、コネクテッドカーとスマートホームの連携に取り組むエンジニアやホームオートメーション愛好家は増えている。今回のVWの事例は以下の観点で参考になる。 1. 非公式APIへの依存リスク管理 公式に公開されていないAPIは、メーカーの一方的な仕様変更で突然使えなくなる。個人利用は許容範囲でも、業務システムへの組み込みには事前のリスク評価が不可欠だ。 2. OAuth 2.0最新仕様の把握 クライアントアサーション方式はOAuth 2.0のベストカレントプラクティス（RFC 9101）として推奨されている。認証基盤の設計・評価に携わるエンジニアは動向を押さえておきたい。 3. コネクテッドカー×スマートホーム統合の設計指針 EVの充電タイマーを在宅検知と連動させる、出発時刻に合わせてエアコンを制御するといったシナリオへの需要は今後も高まる。公式SDKや認定パートナープログラムの活用を前提とした設計が現実的な選択となる。 筆者の見解 今回のVolkswagenの判断は、セキュリティの観点からは理解できる部分もある。署名なしのクライアント認証はリスクをはらんでおり、車両制御APIへの未審査アクセスを放置するのは責任ある対応とは言えない。 ただ、「禁止」だけが解ではないとも思う。Home Assistantのようなオープンソースコミュニティが生み出す活用事例は、ユーザー体験の向上という点でメーカーにとっても本来プラスのはずだ。公式の認定パートナープログラムやサードパーティ向けOAuth 2.0クライアント登録窓口を設けることで、セキュリティを担保しながらエコシステムを育てることは十分に可能ではないか。 「禁止で解決」は短期的には楽な選択だが、ユーザーは抜け道を探すか、より開かれた別のブランドを選ぶかのどちらかだ。コネクテッドカー市場では今後「車のソフトウェア体験」がますます購買動機になっていく。自社エコシステムだけに閉じた戦略は、長い目で見てVolkswagen自身にとってもったいない選択肢になりかねないと感じる。ユーザーを信頼し、安全に使える公式の仕組みを提供するアプローチに期待したい。 出典: この記事は Volkswagen blocks Home Assistant by requiring client assertion の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングエージェントのオーケストレーション基盤「Coder Agents」が、企業の自社インフラ上でAIコーディングワークフローを実行できるプラットフォームを発表した。クラウドサービスに依存せず、コードやデータを外部に送信することなくエージェントベースの開発環境を構築できる点が最大の特徴だ。 Coder Agentsとは何か Coder Agentsは、モデル非依存（model-agnostic）のAIエージェント実行基盤として設計されている。特定のAIモデルやクラウドプロバイダーに縛られることなく、組織が独自のインフラ上でAIコーディングエージェントを運用できる点が他のツールと一線を画す。 従来のAIコーディングツールの多くは、特定のモデルプロバイダーとのAPI接続を前提としており、コードや開発コンテキストがクラウドを経由する構造になっている。Coder Agentsはこの「エージェントツールとモデルプロバイダーの密結合」を意図的に切り離し、インフラ層とAIモデル層を独立させたアーキテクチャを採用している。 何ができるのか 主な機能は以下のとおりだ： 会話インターフェースとAPI: コード記述・テスト生成・プルリクエスト作成などをフォアグラウンド・バックグラウンドで実行 集中管理: モデルアクセス・プロンプト管理・実行ポリシー・オブザーバビリティを一元化 CI/CD統合: GitHub Actions・Slack・その他パイプラインとのネイティブ連携 既存ツールとの共存: Claude Code・Cursor・Codexなど既存ワークフローからの段階的移行をサポート Coder CEOのRob Whiteleyは「エージェントを作ること自体は難しくない。本当の複雑さは、モデル・ツール・リポジトリ・依存関係・コンテキスト・ガードレールを適切に管理しながら、エージェントを安全かつ確実に動かし続けることにある」と述べている。 競合との違い 同カテゴリとしてCursor Agentsもセルフホストクラウドエージェントをサポートしており、分離された仮想マシン上でコードのクローン・環境構築・テスト・プッシュまでの一連作業を自動実行する。Coder Agentsとは設計の優先事項が異なるが、「自律的なバックグラウンド実行」というトレンドは共通している。モデル非依存のAIコントロールプレーンとしてはTrueFoundryやFiddlerなども選択肢に挙がる。 実務への影響 規制産業での採用が現実的に これまでAIコーディングツールの活用を断念してきた、コードの外部送信が許可されない金融・医療・官公庁などの業界にとって、セルフホスト対応は大きな転換点になりうる。設計書や仕様書を含むコンテキストを社内に閉じたまま、エージェントのメリットを享受できるようになる。 エンジニアが明日から考えるべきこと 段階的な移行を設計する: 既存のClaude Code・Cursorワークフローを即座に置き換える必要はない。並行運用しながら組織のガバナンス要件を整理するステップから始めるのが現実的 CI/CDへの組み込みを試す: GitHub ActionsとのAPIネイティブ連携を活用し、プルリクエスト生成やテスト自動化をパイプラインに統合することで、エージェントの「自律ループ」設計の第一歩を踏み出せる コストを試算する: セルフホストはクラウドAPIコストを削減できる反面、実行環境の運用コストが発生する。チームのインフラ管理スキルと規模感に応じた試算が必要 筆者の見解 「エージェントを作ることより、動かし続けることが難しい」というCoderのCEOの言葉は、エージェント開発の本質を突いている。コードを1回動かすだけでなく、エージェントが自律的にループし続ける仕組みを設計する——この視点こそ、今もっとも重要なエンジニアリング課題だと感じている。 セルフホスト対応という方針自体は正しい。クラウドサービスへの依存がエンタープライズ採用の最大の壁であり続けてきた事情を考えれば、「インフラとモデルの分離」というアーキテクチャ上の決断は筋が通っている。 一方で、モデル非依存・ベンダー非依存を謳うプラットフォームが乱立し始めている現状は、選択肢の多さが逆に判断コストを上げるリスクも孕んでいる。自社のセキュリティ要件・既存ツール・チームのスキルセットを冷静に棚卸しし、「今どの層を標準化すべきか」を組織単位で整理しておく時期に来ている。 AIコーディングエージェントのオーケストレーション基盤は、しばらく群雄割拠の状態が続くだろう。そのなかで「セルフホスト×モデル非依存×既存ツールとの共存」を軸に据えたCoder Agentsの方向性は、エンタープライズ需要に沿ったものだ。実際の運用安定性と、ガードレール機能の成熟度を注視していきたい。 出典: この記事は Coder Agents Enable Running AI Coding Workflows on Self-Hosted Infrastructure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Alibaba CloudのQwenチームは2026年5月20日、自律エージェントタスクに特化した大規模言語モデル「Qwen3.7-Max」を発表した。コーディング、オフィス自動化、長時間タスクの連続実行を主要ユースケースとして設計されており、人間の介入なしに最大35時間にわたる自律実行を実証している。 Qwen3.7-Maxとは何か Qwen3.7-Maxは、従来のチャット型AIから「計画→推論→実行」を自律的にこなすエージェント型AIへのパラダイムシフトを体現するモデルだ。Alibaba Cloud Model Studio経由でAPI提供されており、複数のエージェントフレームワークとの連携をサポートしている。 注目すべきは対応フレームワークの顔ぶれだ。AnthropicのClaude Code、OpenClaw、そしてQwen Code（自社製）が明示的にサポートされている。このことは、Qwen3.7-Maxが単体で完結するモデルというより、既存のエージェントハーネスのバックエンドとして組み込まれることを前提とした設計思想を示している。 ビジョン入力に対応したコンパニオンモデル「Qwen3.7-Plus」も同時リリースされており、スクリーンショットや図表を含むワークフローへの応用が期待される。 性能ベンチマーク Qwenチームが公表した数値は以下の通りだ。 コーディング系 SWE-Pro: 60.6 SWE-Multilingual: 78.3 Terminal Bench 2.0-Terminus: 69.7 推論系 GPQA Diamond: 92.4 HMMT 2026 Feb: 97.1 エージェント系 MCP-Mark: 60.8 MCP-Atlas: 76.4 Artificial Analysis Intelligence Index: 56.6 コーディング・推論の両分野でトップクラスのスコアを記録している。SWE系のスコアは実際のGitHubリポジトリ規模のコード変更タスクへの実用性を示す指標として、業界で参照されているものだ。ただし、これらはQwenチーム自身による発表数値であり、独立した第三者検証が追って求められる。 35時間自律実行という実証 最も注目すべきは、カーネル最適化タスクにおける35時間・1,000回超のツール呼び出しという実証結果だ。この実行によりリファレンス実装比10倍の速度向上を達成したとQwenチームは述べている。 従来のAIモデルは数分〜数十分のタスク処理が現実的な上限だった。35時間という継続実行時間は、ソフトウェア開発における複雑な最適化や大規模リファクタリングといった、人間エンジニアが数日かけて取り組む種類のタスクに踏み込んでいることを意味する。 Model Context Protocol（MCP）の活用により、コードエディタ・ターミナル・ファイルシステム・外部サービスを統合した複雑なワークフローを単一のエージェントループで処理するアーキテクチャが実現されている。 実務への影響 コーディング業務への応用 SWE系のベンチマーク結果から判断すると、バグ修正・機能実装・リファクタリングといった実務レベルの作業に実用的な水準に達している可能性がある。Claude Codeのハーネスとの連携がサポートされているため、既存の開発環境にバックエンドとして組み込む形での試用が技術的に可能だ。 MCP連携によるオフィス自動化 MCPサポートにより、メール処理・ドキュメント生成・データ集計といったオフィス業務の自動化パイプラインをエージェント主導で構築できる。Microsoft 365を基盤とする環境でも、Graph APIをMCPツールとして組み込んだ自律エージェントの構築に応用できるアーキテクチャだ。 エンタープライズ導入の現実的なハードル Alibaba Cloud Model Studioを通じた提供となるため、日本企業が採用する場合はデータ主権・コンプライアンス・セキュリティ審査が必要になる。金融・医療・製造業で機密情報を扱うワークフローへの適用は慎重な評価が求められる。まずは社外秘情報を含まない開発系ワークフローでの検証から始めるのが現実的な進め方だろう。 筆者の見解 Qwen3.7-Maxの発表で筆者が最も注目したのは、「35時間自律実行」という数字そのものよりも、Claude Codeのハーネスとの連携を明示的にサポートしている設計方針だ。 これは偶然ではない。AIエージェントの世界では今、モデルとハーネスが分離し、「どんなループを設計するか」というハーネス側の設計こそが競争優位になるフェーズに入っている。Qwen3.7-Maxが「自前のハーネスを使え」ではなく「実績あるハーネスに載せてくれ」という姿勢を取っているのは、理にかなった戦略だと思う。 長時間の自律実行が標準になっていく中で、エンジニアに求められるスキルは変わる。「AIに指示を出し続ける」ではなく、「どんなループを設計し、どんな成功条件と停止条件を定義するか」という設計力の方が、プロンプトの巧みさよりも重要になる。35時間動き続けるエージェントを「どう評価し、どこで止めるか」を決める能力が問われる時代はすぐそこまで来ている。 日本のIT現場ではAIエージェントの自律実行に対する不安感が依然として強い。頻繁な人間確認を挟みたいという心理は理解できるが、設計段階での安全性の作り込みと適切なログ・ロールバック機構が本来の解答であって、人間介入の頻度を増やすことは解答にならない。Qwen3.7-Maxのような自律特化型モデルが複数登場してきたことは、この方向性が正しいことの傍証でもある。 モデルの優劣はベンチマーク競争の中で常に動く。今エンジニアが磨くべきなのは「何をさせるか」よりも「どう動かし、どう検証し、どう止めるか」の設計力だ。 出典: この記事は Qwen3.7-Max: New AI Model Designed for Autonomous Agent Tasks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AnthropicはClaude Opus 4.8を発表した。同価格帯でFast Modeのコストを従来の3分の1に引き下げ、処理速度を2.5倍に高めながら、主要ベンチマークでも顕著な改善を実現している。 Opus 4.8の主な変更点 Fast Modeが大幅なコスト削減を達成 Opus 4.8の最大の注目点はFast Modeの刷新だ。同性能クラスのモデルと比べてFast Modeのコストを3分の1に抑えつつ、処理速度は2.5倍を達成している。エージェントワークロードや大量バッチ処理を日常的に回している現場にとって、これはかなり現実的なインパクトになる。 ベンチマークスコアの改善 定量的な改善も数字に表れている。 指標 Opus 4.7 Opus 4.8 変化 マルチタスク推論スコア 54.7% 57.9% +3.2pt Knowledge Workスコア 1753 1890 +137pt マルチタスク推論は複数の知識領域を同時に扱う複合的な問い合わせへの応答精度を示し、Knowledge Workスコアは実務的な知識作業全般でのパフォーマンスを表す。どちらも実業務に直結する指標であり、この水準の改善は無視できない。 価格据え置きでフロンティア水準を引き上げ 注目すべきは、価格帯を変えずにこれだけの改善を実現した点だ。AIモデル市場ではここ数ヶ月コストパフォーマンス競争が激化しているが、Opus 4.8はその文脈で「同じ予算でより賢く、より速く」を実現した。 実務への影響 AIエージェント・自動化ワークフローへの恩恵が大きい Fast Modeのコスト削減は、単発の会話ユースケースよりもエージェントパイプラインで効果が大きい。ループ駆動で大量のサブタスクを回す構成では、1リクエストあたりのコスト差が積み重なって月次コストに直接響く。 具体的な恩恵が期待できる用途としては以下が挙げられる。 バッチ処理・夜間ジョブ: コスト上限内でより多くのタスクを処理できる エージェントループ: 自律的に判断・実行を繰り返すハーネス型の構成でコスト効率が改善 RAGパイプライン: 大量ドキュメントの要約・分類フローで費用対効果が向上 Knowledge Workスコアの改善は「複雑な実務タスク」に効く Knowledge Workスコアの+137pt改善は、レポート作成・複数資料の統合・調査・要約といった「頭を使う作業」全般のクオリティ向上を意味する。コーディング支援だけでなく、ビジネスアナリスト的な作業でもその恩恵を受けるユーザーが増えそうだ。 APIコストの再試算を推奨 Opus 4.8への移行を検討しているチームは、現行のOpus利用状況を棚卸ししてFast Mode比率と月次コストを再計算することをお勧めする。特にFast Modeを積極的に使っている構成では、同じ予算でカバーできるスループットが大きく変わる可能性がある。 筆者の見解 Anthropicはモデルの更新ペースを落とさず、価格据え置きでのパフォーマンス改善というサイクルを維持している。Fast Modeのコスト削減は「フロンティアモデルを使いたいが予算がネック」という現場の声に対する、現実的な回答だと思う。 マルチタスク推論スコアの改善は、AIエージェント設計の文脈で「複数ツールを自律的に使い分けながら複雑なタスクを遂行させる」という用途に直結する。ループ駆動でエージェントを自律稼働させる構成を試みているチームには、アップグレードの効果を実際のワークロードで検証する価値がある。 一方で、ベンチマーク数値の改善が実際のユースケースでどう体感されるかは、使い方の設計次第だ。スコアが上がったという情報を追いかけるだけで終わらせず、自分たちの現場のワークロードで手を動かして確認することの方が、AIを道具として使いこなす上では遠回りに見えて一番の近道だと考えている。 出典: この記事は Anthropic upgrades Claude with new Opus 4.8 model, here’s what’s new の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIコーディングエージェントに全面移行したエンジニアが「もうコードを書かない」と宣言するエッセイが、2026年5月にHacker Newsで話題を集めた。関数1つ、バグ修正1件も自分では書かず、設計とレビューに集中するスタイルへ移行した経緯と、その先に見えた「コーディングの本質」を率直に綴った内容だ。 「編集画面を開いた瞬間、面白い部分は終わっていた」 著者は18年のキャリアを持つエンジニアで、splitキーボードとnvimにこだわり、スケーラブルな分散システムの構築にも携わってきた。現在はenum社でAIエージェントを活用した開発を推進しており、自身のブログから複雑なプロダクション実装まで、コードの生成はすべてエージェントに委ねている。 著者が気づいたのは「自分が本当に楽しんでいたのはタイピングではなかった」という事実だ。 このシステムは何をすべきか 障害発生時にどう振る舞うべきか どこに複雑さを集約すべきか 正しい抽象化の境界はどこか これらの意思決定にこそ知的な楽しさがあった。コードを書く作業は、その決定を現実に翻訳するための「繰り返し作業」であり、同じパターン、同じインポート、同じリトライループを何千回と打ち込む筋肉記憶に過ぎなかったと振り返る。 AIエージェント移行後の「本当の仕事」 著者が今やっていることは次の通りだ。 設計とアーキテクチャ: スケーラブルなリコンサイラーパターンの設計、データの置き場所の判断、次に解くべき本質的な問題の特定。 コードレビューと品質管理: エージェントが出力したコードを精査し、問題のある抽象化パターンや「偽のテストカバレッジ」を見抜く。AIへの移行後、以前よりも「読むコードの量」が増えたと著者は言う。自分でタイピングする代わりに、エージェントの出力を常に読んでいるからだ。 意思決定の明確化: 何をプリミティブとして定義し、何を合成で表現するか。この判断軸はAIには委ねられない。 著者はこう結論づける。「スキルとして重要なのはセンス（taste）だ。設計が悪いと気づけるか、崩壊寸前の前提を見抜けるか、何にこだわり何を手放すかを知っているか。これは何も変わっていない。むしろより重要になっている」。 日本のIT現場への影響 この話は海外のハイエンドエンジニアだけの話ではない。GitHub Copilot・Claude Code・Cursor等のAIコーディングエージェントは既に日本のエンジニアにも広く手が届く段階にある。 問題は「使うかどうか」ではなく、「どの仕事をAIに任せ、どこに人間の判断を集中させるか」という役割設計だ。 エンジニアリングリード・IT管理者へのポイント: コードを書く時間の削減 ≠ 仕事量の削減: 設計・判断・レビューに使える時間が増えることを意味する コードレビュー力が核心スキルになる: AIが生成したコードの品質を判断できるかどうかが、今後の差別化ポイントになる 採用・評価基準の見直しが必要: 「何が実装できるか」より「何を設計・判断できるか」への転換 AIを「使わない」ことそのものがリスク: 現時点でAIコーディングエージェントを積極的に活用しないエンジニアは、生産性の面で大きなハンデを背負うことになる 筆者の見解 このエッセイが示しているのは、AIエージェントが「コードを書く量」を変えるだけでなく、「誰が何の仕事をするか」という職責の定義そのものを変えているという事実だ。 著者が言う「センス」──設計の良し悪しを判断する力、テストが実質的かを見極める力──は、今後むしろ希少で価値ある能力になる。コードを書けるエンジニアは増えても、「エージェントの出力をレビューして本質的な問題を発見できる」エンジニアは簡単には増えない。 「仕組みを設計できる少数の人間が判断し、AIがそれを回す」というモデルへの移行は、もはや議論の段階ではない。問題は、日本のIT組織がこの変化を表面的な「ツール導入」として処理するか、それとも「誰が何を判断するか」という職責の再設計として捉えるかだ。 AIエージェントを正しく使いこなすことは、単に生産性を上げるだけでなく、エンジニアが本来やりたかった「面白い部分」──設計の意思決定──に集中できる環境を作ることでもある。組織としてその環境を整備することが、今もっとも重要な技術的意思決定のひとつだと考える。 出典: この記事は Going full AI engineer, not touching code anymore の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAのCEOジェンセン・ファン氏が、AIエージェント専用CPU「Vera」によって2000億ドル（約30兆円）規模の全く新しい市場を開拓できると宣言した。2026年5月の決算説明会で語ったもので、同社が従来手がけてこなかったCPU市場への本格参入を示す発言として業界の注目を集めている。 GPUの王者がCPUに踏み込む理由 NVIDIAといえばGPUの覇者だ。生成AIブームを背景に四半期ごとに記録を更新し続け、今回の決算でも売上高816億ドルと過去最高を更新、次四半期は910億ドルを見込むと発表した。そのNVIDIAが今、なぜCPUに力を入れるのか。 ファン氏の説明はシンプルかつ明快だ。 「AIモデルの『思考』部分はGPUが担う。しかしエージェントが実際にタスクを実行する部分はCPUで動く」 つまり、生成AIの推論フェーズはGPUが主役だが、エージェントが自律的に動き回り、ツールを呼び出し、作業を遂行するフェーズではCPUが主役になる、という構造的な認識だ。 Vera CPUとは何か 「Vera」は2026年3月に発表されたNVIDIA初の本格的なアーキテクチャを持つAI専用CPUだ。単体販売のほか、次世代GPU「Rubin」とのバンドル販売も行われる。 従来のクラウド向けCPUは「コア」数を増やして複数アプリの並行処理を最適化する設計思想で作られてきた。IntelやAMDが長年この路線を磨いてきた領域だ。 Veraはその設計思想を根本から変えている。トークン処理速度を最優先に最適化した構造を持ち、エージェントがテキスト・コード・ツール呼び出し結果を次々と処理するワークロードに特化している。ファン氏はこれを「世界初のエージェントAI向けに専用設計されたCPU」と位置づけた。 「今年だけで200億ドル」という数字の重み 重要なのは、これが単なる将来予測ではないという点だ。ファン氏は2026年の時点で既にVera CPU単体で200億ドルの販売実績があると明かした。 発表から数ヶ月でこの規模に達しているとすれば、主要ハイパースケーラーとシステムメーカーの全てがVeraの展開に向けたパートナーシップを結んでいるというファン氏の発言と整合する。 もっとも、競合の動きも激しい。Amazon Web Servicesは自社開発AIチップ（CPU・GPU両方）に関してMetaと大型契約を結んだことを発表しており、AWS CEOのアンディ・ジャシー氏はNVIDIA製チップと同等以上の性能を自社で実現できると明言している。Intel、AMDも黙ってはいない。 「数十億のエージェントが数十億のVeraを使う」 ファン氏のビジョンはさらに大きい。 「世界には10億人の人間ユーザーがいる。私の感覚では、世界は数十億のエージェントを持つ方向に向かう。それらのエージェントは全てツールを使い、そのツールは今日の私たちがPCを使うのと同じように、エージェント専用のPCになっていく」 この予測が正しければ、CPUの需要は人間のPC需要をはるかに凌駕する規模で爆発することになる。「だから私たちはもっと多くのCPUが必要になる」というファン氏の言葉は、NVIDIAがGPU一本足打法から脱却し、エージェント時代の計算基盤全体を掌握しようとしている戦略を端的に示している。 実務への影響：日本のエンジニア・IT管理者が知っておくべきこと インフラ調達の判断軸が変わる クラウド上でAIエージェントを本格運用する企業は、GPUインスタンスだけでなく、エージェント実行層に最適化されたCPUインスタンスの選択肢を今後意識する必要がある。AWS、Azure、GCPがVeraベースのインスタンスを提供し始めた時点で、ワークロードの分離設計（推論はGPU、エージェント実行はVera CPU）が標準的なアーキテクチャになりうる。 コスト試算の前提が変わる GPUインスタンスはコスト高の象徴だが、エージェントの実行フェーズをCPU最適化インスタンスに移せれば、コスト構造が大きく改善する可能性がある。エージェントの設計段階から「どのフェーズをどの計算資源で動かすか」を意識するアーキテクチャ思考が求められる。 オンプレミス・エッジの文脈でも要注目 ファン氏が「エージェント専用のPC」と表現したように、将来的にはエッジ・オンプレでのエージェント実行基盤としてVeraが登場する可能性もある。製造業・金融など、クラウドに全データを出せない業種での展開が現実味を帯びてくる。 筆者の見解 ジェンセン・ファン氏の「ハイプマン」ぶりは有名だが、彼の場合は有言実行の歴史がある。今回の発言も、既に200億ドルという具体的な販売実績を伴っている点で単なる見通しとは次元が異なる。 個人的に興味深いのは、この発表がエージェントの構造をGPUとCPUという計算資源の分業として明確に定義した点だ。「AIエージェントが自律的にループで動き続ける仕組み」を設計する上で、「思考」と「実行」を分けて考えることは理にかなっている。エージェントが100回ツールを呼び出して作業を完遂するとき、そのループのほとんどはGPUを使わない。この事実に最初に適切なハードウェアを当てたのがNVIDIAだ、ということになる。 競合としてAWSやIntelが挙げられているが、NVIDIAの強みはソフトウェアスタック（CUDA等）との統合にある。ハードウェア単体の性能比較だけでは語れない部分が大きい。 エージェントAIが「次のフロンティア」であることは間違いない。その計算基盤を誰が握るかという争いは、今まさに始まったばかりだ。日本のエンジニアにとっては、クラウドベンダーがどのチップを採用するかを注視しながら、エージェントのアーキテクチャ設計力を今のうちに磨いておくことが、最も実践的な対応策になる。 出典: この記事は Jensen Huang says he’s found a ‘brand new’ $200B market for Nvidia の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのAI検索機能「AI Overviews」やチャットボット「Gemini」が、巧妙に細工されたウェブページを通じて偽情報を拡散させられていたことが、BBC記者の調査によって明らかになった。GoogleはポリシーをアップデートしてAIポイズニングへの対策を強化しているが、専門家は依然として「現状では操作されていると思って利用すること」と警告する。 なぜAIは簡単に騙されるのか 通常、AIチャットボットは学習データをもとに回答を生成するが、ChatGPTやClaude、GoogleのAI製品の一部は「リアルタイムでウェブを検索してから回答する」機能を持っている。この仕組みが悪用された。 SEOとAI検索の専門家によると、AIツールは特定の1つのウェブページやSNS投稿の内容をそのまま拾い上げることが多い。つまり、うまく作り込んだブログ記事を1本公開するだけで、AI検索の回答を意図的に操作できてしまう。これが「AIポイズニング」と呼ばれる手口だ。 BBC記者がGoogle・ChatGPTを20分で騙した実験 BBC記者のトーマス・ジャーマン氏は、自身のウェブサイトに「ホットドッグ早食い世界チャンピオン」を称する記事を掲載した。翌日には、ChatGPTやGoogleのAIが世界中に向けて同氏を「世界チャンピオン」として紹介し始めたという。 笑い話のような実験だが、同様の手口は深刻な場面でも使われていた。調査では、医療サプリメントの健康上の懸念を否定する偽情報や、退職資金に関する金融情報をGoogleのAIに語らせることにも成功しており、こうした操作が「広範かつ組織的なレベル」で行われていることが確認されている。 Googleのポリシー更新と現状 この調査報道や研究者たちの指摘を受け、Googleはスパム対策ポリシーをAI検索機能に適用する形でポリシーを更新した。ただし同社は「以前から継続的に取り組んできた内容の明確化にすぎない」と説明しており、新たな抜本対策というよりは既存姿勢の再確認という側面が強い。 実際、記事執筆時点でも同じ手口でGoogle検索が操作されている事例が確認されており、完全な解決には至っていない。 「10個のリンク」から「1つの正解」への構造的変化 この問題の本質を突いているのが、SEOコンサルタントのリリー・レイ氏の指摘だ。 「かつてGoogleは10個のリンクを提示し、ユーザーが自分でリサーチしていた。AIは1つの答えを出す。額面通りに受け取りやすくなってしまった」 AI検索への移行は、情報収集の構造を根本から変えつつある。複数の情報源を比較検討するプロセスが失われ、ユーザーは「AIが選んだ1つの答え」を受け取るだけになる。この変化は、偽情報が拡散したときの影響範囲を以前より格段に広げる。 日本のエンジニア・IT管理者への実務ポイント 今すぐ取り入れられる対策： AI検索結果を「一次情報」として扱わない: 投資・医療・セキュリティなど重要な判断にはAI検索結果だけを使わず、公式ドキュメントや信頼できる情報源でクロスチェックする 社内AIガイドラインへの明記: 「リアルタイム検索を使うAIツールの回答は検証が必要」という一文を利用ポリシーに追加することを検討する 自社情報の流通モニタリング: 自社製品・サービスに関する誤情報がAI検索で流通していないか定期的に確認する習慣を持つ ウェブ検索オフのモードを活用: 機密性や信頼性が重要な作業では、インターネット参照なしのモードを選択する 筆者の見解 今回の問題は「AIが賢くなりすぎた」ことが原因ではなく、「AIが外部情報をどう取り込むか」というアーキテクチャ設計の課題だ。検索エンジンのスパム対策は長年の歴史があり、Googleはそのノウハウを積み重ねてきた。AI Overviewsへの対応もその延長線上にあり、時間をかけて洗練されていくとは思う。 ただ、見逃せないのはユーザー側に求められるリテラシーのハードルが上がっている点だ。「複数リンクから自分で判断する」プロセスが消え、「AIが提示する1つの答え」をそのまま受け取る文化が定着すれば、誤情報の影響は以前より広範に及ぶ。 技術的な防御策の整備と並行して、組織・教育の場で「AIの回答を批判的に検証する」習慣を育てることが急務だ。ツールを使いこなすとは、出力を無批判に信頼することではない。AIを正しく使いこなすためのリテラシー教育は、エンジニアだけでなくビジネスユーザー全員に必要な時代になっている。 出典: この記事は Google’s AI is being manipulated. The search giant is quietly fighting back の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月、元Google CEO エリック・シュミット氏が米アリゾナ大学の卒業式スピーチでAIの可能性を称賛したところ、数千人の学生から大ブーイングを受けた。同様の光景は全米複数の大学で相次ぎ、テクノロジー業界の「AI楽観論」と、これから就職市場に飛び込む若者世代の「雇用への危機感」が、正面衝突した卒業シーズンとなった。 何が起きたか シュミット氏はアリゾナ大学の式典で、テクノロジーが人類の「知識の大聖堂」を築いてきた歴史を語りつつ、AIを「ロケット船の座席」と形容し、「自分ひとりではこなせなかった仕事をAIエージェントのチームに任せられる」と語りかけた。会場からのブーイングが激しくなると、シュミット氏は一度スピーチを中断し「皆さんの気持ちはわかる。その恐れは合理的だ」と認めながらも、「それでもAIが世界を変えていく。その舵を取るのはあなたたちだ」とメッセージを変えなかった。 ユニバーサル・フロリダ大学では不動産会社副社長のグロリア・コールフィールド氏が「AIは次の産業革命だ」と発言して嘲笑を浴び、ミドル・テネシー州立大学では音楽プロデューサーのスコット・ボルチェッタ氏が「AIは今この瞬間も制作を書き換えている。受け入れろ（deal with it）」と学生の反発を一蹴する場面もあった。 なぜ学生たちは怒ったのか 背景には具体的な数字がある。Microsoftの幹部は「AIが今後12〜18ヶ月以内にすべてのホワイトカラー職を代替する」と発言しており、一方で米国企業経営者を対象にした調査では「AIによる生産性向上を実感している」と答えた割合は低迷している。 学生たちにとって、これはキャリアが始まる前から「ゲームのルールが変わった」と宣告されている状況だ。「夢を持って4年間学んできたのに、入社前から代替されると言われる」という感情が爆発したとも読める。 AIが雇用に与える影響について確かな答えはまだ誰にも出せていない。しかし「過去の技術革命もそうだった」という過去形の慰めと、「だから大丈夫だ」という短絡的な着地点は、具体的なスキルロードマップを持たない学生には響かない。 実務への影響——日本のIT現場でも他人事ではない 日本においても、同様の構図は静かに進行している。企業はAI活用を推進しながら、現場の若手に「何をどう学び直せばいいか」を明確に示せていない組織が多い。 IT管理者・エンジニアが今すぐ取り組めることとして、以下の視点が有効だ。 1. 「禁止」ではなく「使いこなす仕組み」を整備する AIを制限するアプローチは必ず失敗する。正規ルートで安全に使えるツールを提供し、公式チャネルが最も便利な状態をつくることが先決だ。 2. AIの「活用量」ではなく「成果」で評価軸を設計する トークン消費量や操作頻度で競わせるような数字KPIは本質を外す。「AIを使いながら何を達成できたか」という成果指標に置き換える設計が求められる。 3. 若手エンジニアへのスキルロードマップを明示する 「AIを使いこなせる人材」が何を学べばいいかを組織として定義し、その学習を支援する環境を作る。漠然とした「AI時代に備えよ」では不安を煽るだけで行動につながらない。 4. 自律エージェントを体験させる AIを「副操縦士（コパイロット）」として使う体験だけでは、AIの本質的な価値は伝わりにくい。目的を与えると自律的にタスクを実行するエージェント型の活用を体験させることで、若手の認識は大きく変わる。 筆者の見解 学生たちのブーイングは感情的な反発ではなく、むしろ合理的なシグナルだと思う。「AIを使え」という号令だけが飛んで、「どう使えばキャリアが守られるか」「どう使えば成長できるか」という具体的な道筋が示されない。そのギャップへの不満が、卒業式という晴れ舞台で爆発したのだろう。 問題は、登壇した経営者たちのメッセージが「AIは来る、備えよ」の一点張りで止まっていたことにある。変化の波が大きければ大きいほど、「どう泳ぐか」を一緒に考えてくれるリーダーシップが求められる。「deal with it（受け入れろ）」の一言で締める姿勢は、世代間の信頼を損なうだけだ。 日本でも、AI導入を推進する立場の人間は同じ問いに向き合う必要がある。AIが仕事を奪うのではなく、AIをうまく使いこなせる人間が、使いこなせない人間の仕事を引き受けていく——この現実を正直に伝えつつ、その「使いこなし方」を組織として支援することが、真のリーダーシップだと思う。 恐れを「合理的だ」と認めたシュミット氏の一言は正直だった。あとは、その恐れに対して具体的に何をするかを語れるかどうかが問われている。 出典: この記事は College students drown out AI-praising commencement speeches with boos の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SQLiteプロジェクトが公式リポジトリに「AGENTS.md」ファイルを追加し、AIエージェントからのコード提出を明確に拒否する方針を文書化した。一方で再現可能なテストケースを伴うバグ報告は受け入れるという、AIとのかかわり方を明示している。 AGENTS.mdとは何か AGENTS.mdは、AIエージェントがコードベースを操作する際のルールや期待値を記述したファイルだ。CONTRIBUTINGやREADMEと同様に、AIツールがリポジトリを読んだときに参照するためのものとして、近年GitHubを中心に普及しつつある。 AIエージェントをOSSリポジトリにポイントして自律的にIssueやPRを作成させる開発者が急増しており、各プロジェクトがAI向けの指針を明示する流れが生まれている。SQLiteもその文脈でこのファイルを追加した。 SQLiteの立場：コードは拒否、バグ報告は受け入れ SQLiteのAGENTS.mdで特に注目される方針は以下の2点だ。 コード提出は原則拒否: SQLiteはPRのパブリックドメイン化に関する法的合意・書類なしではプルリクエストを受け付けない。AIエージェントによるコードは受け付けない。ただし、人間の開発者がPoCとして確認するため、簡潔かつ明快なPRをレビューすることはある。 バグ報告は条件付きで受け入れ: 再現可能なテストケースを含むバグ報告は受け入れる。修正の可能性を示すパッチやPRはドキュメント目的で歓迎する。 さらに直近のコミットでは「AIエージェントのコードは（現時点では）受け付けない」という文章から「現時点では」という留保を削除し、コミットメッセージに「Strengthen the statement about not accepting agentic code（AIコード不受け入れの表明を強化）」と記して方針を明確化した。 フォーラムに何が起きていたのか この背景には、SQLiteフォーラムへのAI生成バグ報告の殺到がある。品質にばらつきのあるAI生成のバグ報告が大量に投稿され、プロジェクト創設者であるD. Richard Hippが対応に追われる状況となった。 結果としてSQLiteは、AI由来のバグ報告を集約するための「SQLite Bug Forum」を別途設立。Hippはそこに集まった報告を精力的に確認し、対応できるものにはコミットで応えている。 実務への影響——日本のエンジニアが知っておくべきこと AIエージェントを使った開発では、エージェントが自律的にIssueを立てたりPRを投げたりする場面が増えている。SQLiteのような重要なOSSが明確な拒否方針を示したことで、同様の方針を採用するプロジェクトが今後増える可能性がある。実務上の対応ポイントを整理する。 AGENTS.mdを事前確認する: エージェントをOSSリポジトリにポイントする前に、AGENTS.mdの有無と内容を確認する習慣をつける。無視してPRを投げると関係が悪化するリスクがある バグ発見・テスト生成に集中させる: AIエージェントに修正コードを書かせるより、再現テストを書かせてから人間がレビューする流れが、OSSへの貢献として受け入れられやすい 法的クリアランスも忘れずに: SQLiteのようにCLAやパブリックドメイン移譲を求めるプロジェクトでは、AIが生成したコードの著作権帰属が問題になりうる。エージェントを使った貢献では法的整理が先決だ 筆者の見解 SQLiteのこの判断は、AIエージェント時代のOSS運営の現実を象徴している。 メンテナが処理しきれないほどのAI生成バグ報告が殺到し、専用フォーラムに分離せざるを得なかった——これはAIエージェントの普及が予想より早く「量」の問題を引き起こした事例だ。品質を守るために「アジェンティックコードは受け付けない」と明言したことは、小さなコアチームで30年以上高品質なコードベースを維持してきたSQLiteらしい判断だと思う。 興味深いのは「バグ報告は受け入れる」という線引きだ。人間のレビュアーだけでは難しいスケールでコードをスキャンしてバグを発見し、再現テストを伴って報告する——AIエージェントがここで価値を発揮できると判断したのは筋が通っている。実際、D. Richard Hippが対応に追われながらもコミットを重ねているのは、有用な報告が含まれていたからだろう。 「現時点では」という留保を削除して方針を強化したことは、当面は方針変更の意思がないことを示す。ただし、AIがコードの品質や法的クリアランスの問題を解決できるようになれば、こうした方針が見直される余地はあるはずだ。今は「AIが書いた」だけで品質を保証できない現状がある。エンジニアとしては、ツールに自律的に動かせる範囲をしっかり設計する重要性を改めて考えさせられる事例だ。 出典: この記事は sqlite AGENTS.md の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIのサム・アルトマンCEOとAnthropicのダリオ・アモダイCEOが、AIによるホワイトカラー雇用への近期的な影響について「以前の予測はかなり間違っていた」と公式に認め、AIを「職の破壊者」ではなく「生産性乗数（Productivity Multiplier）」として再定義する姿勢を明確にした。 両CEOは何を「間違っていた」と認めたのか 両社のトップはこれまで、AIが近い将来にわたって大規模なホワイトカラー雇用の代替を引き起こすという見通しを積極的に語ってきた。特にアルトマン氏は「AIは多くの知識労働者の仕事を変える」という発言で注目を集めてきた。 しかし2026年5月の最新発言では、この予測の前提が現実と大きく異なっていたことを率直に認めた。現時点でのAIは「人間の仕事を奪う代替者」というより、「人間の能力を底上げする増幅器」として機能しているというのが、現在の両社の公式見解だ。 「生産性乗数」への転換が持つ三つの意味 このフレーミング変化は、単なる言葉の問題ではない。 技術的な現実の反映　現在のAIは多くのタスクを自動化できるが、エンドツーエンドで人間の業務を完全代替するには依然として壁が多い。判断・交渉・信頼関係の構築といった要素は、現時点のAIが最も苦手とする領域だ。「破壊者」という予測は、技術の現在地を過大評価していた部分がある。 エンタープライズ市場への訴求　「仕事を奪う」と言い続けることは、規制リスクや大企業顧客の導入障壁を生む。「生産性を高める」というポジショニングの方が、CHRO（最高人事責任者）や取締役会への訴求力が格段に高い。ビジネス的に合理的な言い換えでもある。 IPOとの連動　OpenAIは近くIPOを控えており、機関投資家や規制当局に対して「責任あるAI」を示す必要がある。Anthropicも大型調達ラウンドを継続中だ。このタイミングでのポジショニング変化が偶然でないことは、冷静に見ておく必要がある。 日本のIT現場への実務インパクト AI導入の目的を再設定する好機　「AIで職を削減する」を目的にするのではなく、「現有のチームがより高い価値を生み出す」ための仕組みとしてAIを位置づけるアプローチが、現実的かつ社内調整しやすい方向性だ。両CEOの発言は、この方向性に改めてお墨付きを与えた形でもある。 エンジニアのアウトプット格差が拡大する　生産性乗数としてのAIは、活用するエンジニアとしないエンジニアの間にアウトプット格差を生む。コーディングエージェントを積極活用することで、従来の3〜5倍の速度で開発を進める事例は国内外で増えている。「まだ様子見」という判断は、今や積極的な不作為に近い。 KPIと評価制度の見直しが急務　「AIを使っているか」だけをKPIにするのは安直だが、AIをうまく活用しながら成果を出すための仕組みづくりと動機付けは組織として不可欠だ。「使わなくてもいい」という風潮が広がると、使わない言い訳を組織全体に与えてしまう。 筆者の見解 率直な言い直しを公の場でできる姿勢は、技術リーダーとして評価できる。ただ、「生産性乗数」というフレーミングには注意が必要だ。このロジックは「AIを入れれば自動的に生産性が上がる」という誤解を招きやすい。 現実はもう少し根本的だ。AIが本当の威力を発揮するのは、人間が「確認・承認を求め続ける設計」から解放されたときだ。目標を与えれば自律的にタスクを遂行し、自分で判断・実行・検証をループし続けるエージェントの設計こそが、組織の生産性を桁違いに変える。そのループを回し続けられる「仕組みを設計できる人」が少数いれば、多くのルーティンワークはAIが担えるようになる。 「AIは職を奪わない、生産性を高めるだけ」という安心感を強調しすぎると、変革のスピードを見誤る。日本企業に必要なのは安心感ではなく、「どう仕組みを設計するか」の具体的な取り組みだ。両CEOの今回の発言が、その検討を先送りする口実にならないよう願っている。 「AIを使う vs 使わない」という二項対立の時代は終わりつつある。「どう使うか」を組織として定義し、支援する体制を整えた企業が、これからの3〜5年で大きく差をつけるだろう。 出典: この記事は AI Dispatch May 27, 2026: OpenAI & Anthropic CEOs Walk Back AI Job Loss Predictions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年4月、.NET向けAIエージェント構築フレームワーク「Microsoft Agent Framework」のバージョン1.0を正式リリースした。単純な単一エージェントから複雑なマルチエージェントワークフローまで対応する本番運用向けSDKで、.NET開発者がAIエージェントを組み込む際の公式な基盤として位置づけられている。 AIエージェントとは何か——チャットボットとの本質的な違い チャットボットは「入力→モデル→出力」という単純なパイプラインだ。一方、AIエージェントには自律性がある。タスクを推論し、どのツールを使うべきかを自ら判断し、ツールを呼び出して結果を評価し、次のアクションを決定する。これをすべて、開発者が明示的な手順書を書くことなく実現できる。 端的に言えば、「同僚に質問する」のがチャットボットで、「同僚にToDoリストを渡して任せる」のがエージェントだ。 .NET向けAI構成要素シリーズの第3の柱 Agent Frameworkは、Microsoftが段階的に整備してきた.NET向けAIシリーズの集大成として位置づけられる。 Part 1: MEAI（Microsoft Extensions for AI）— LLMと対話する統一インターフェース Part 2: VectorData — セマンティック検索とRAGパターン Part 3: Agent Framework — ツール連携・メモリ管理・マルチエージェント協調 Agent FrameworkはMEAIのIChatClientの上に構築されており、既存のMEAI資産をそのまま活用できる。対応プロバイダーはAzure OpenAI、OpenAI、GitHub Models、Microsoft Foundryに加え、FoundryLocalやOllamaなどのローカルモデルにも対応する。 最小構成での実装——3行で動くエージェント パッケージのインストールは1コマンドだ： 出典: この記事は Microsoft Agent Framework: Building Blocks for AI Part 3 — .NET Blog の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleはGoogle I/O 2026において、テキスト・画像・音声・動画の任意の組み合わせを入力・出力できる新モデルファミリー「Gemini Omni Flash」を発表するとともに、AIエージェントプラットフォーム「Antigravity 2.0」を単独サービスとして正式公開した。 Google I/O 2026：規模感から見えるAI覇権レース サンダー・ピチャイCEOは基調講演の冒頭で、現状を示す6つの数字を提示した。 月間処理トークン数: 3.2京（3.2×10の15乗）トークン——前年比7倍 Geminiアプリ月間アクティブユーザー: 9億人（前四半期比2倍以上） AI Overviews（Search）月間利用者: 25億人 AI Mode（Search）月間利用者: 10億人（1年でゼロから達成） Googleモデルを利用する開発者数: 850万人/月 SynthIDウォーターマーク適用数: 1,000億件超 これらの数字はGoogleが「エージェント時代はすでに到来した」と位置づけていることの根拠として提示された。 Gemini Omni Flash：「任意入力→任意出力」を実現する新モデルファミリー Gemini Omni Flashは、テキスト・画像・音声・動画のどの組み合わせでも入力として受け取り、同様にどのモダリティでも出力できる、初のフルマルチモーダルモデルファミリーだ。 従来のマルチモーダルモデルは「テキスト＋画像の入力→テキスト出力」など、特定の組み合わせに限定されることが多かった。Gemini Omni Flashはこの制約を取り払い、任意のモダリティを「入力の束」として受け取り、要求に応じた任意のモダリティで出力する設計になっている。 同時に、Gemini 3.5 FlashがGA（一般提供）に移行した。モデルIDはgemini-3.5-flashとなり、GeminiアプリおよびSearch AI Modeのデフォルトモデルとして採用された。Gemini 3.5 Proは2026年6月にロールアウト予定。 注目すべきは、従来の「Proモデルを先行公開し、後からFlashを提供」という歴史的な慣行を逆転させた点だ。Flashを先に安定版として提供する「Flash-first戦略」は、コスト曲線の行き先についてのGoogleの明確な意思表示と読める。 Antigravity 2.0：エージェントハーネスがプラットフォームになった 今回の発表の中でエンジニアが最も注目すべき変化は、Antigravity 2.0の独立したプラットフォームとしての公開だ。 Antigravity 2.0はデスクトップアプリ・CLI・SDKの3面から構成され、開発者がGoogleのAIエージェントを自律的に動かすための基盤となる。ユーザー向けにはGemini Sparkという24時間365日稼働のパーソナルエージェントとして提供される。 この2つは同じ「Antigravityハーネス」の上に乗っている——開発者向けと一般ユーザー向けを一枚のプラットフォームで統一する設計だ。なお、Gemini CLIは2026年6月18日にサンセット予定。Pro/Ultraユーザーはこの日までにAntigravity 2.0への移行が必要になる。 サブスクリプション料金の変更 AI Ultraサブスクリプションは月額$250から$200に引き下げられた（Pro比20倍の利用枠、Spark完全アクセス、Antigravity 2.0の優先枠）。また新たに月額$100の開発者向けエントリーティアが追加された（Pro比5倍の利用枠、20TB Drive）。 ChatGPT Pro（$200/月）やClaude Max（$100〜$200/月）と価格帯が重なっており、上位ユーザー向けのプレミアム争いが可視化された形だ。 Anthropicの同日対抗策：自己ホスト型サンドボックスとMCPトンネル I/O 2026の開催と同じ日、AnthropicはロンドンでCode with Claude Londonを開催し、二つの機能を発表した。 自己ホスト型サンドボックス（パブリックベータ）：Cloudflare、Daytona、Modal、Vercelが初日からプロバイダとして参加 MCPトンネル（リサーチプレビュー）：ローカル環境のMCPサーバーをクラウドエージェントから安全に接続する仕組み さらに同日、Andrej Karpathy氏がAnthropicに参加した。 ...

トランプ政権が、GPT-4やClaudeなどの最先端AIモデルのリリース前に政府審査を義務づける行政命令の検討を開始したことが明らかになった。就任直後の「規制撤廃・迅速革新」路線から一転する政策変更であり、NSA（国家安全保障局）の関与可能性も浮上している。 「規制なし路線」から一転した背景 トランプ政権は2025年初頭、バイデン前政権が定めたAI安全に関する行政命令を撤回し、「過剰規制を排除してイノベーションを加速する」という方針を明確に打ち出した。この転換により、AI企業は自由度の高い開発環境を享受できると期待されていた。 しかし、最新の報道によれば、ホワイトハウスはこの方針の見直しに動いている。フロンティアAIモデル（現時点での人間の能力に匹敵・超越する最先端モデル）のリリース前に政府レビューを義務付ける行政命令の策定が検討されているという。 NSAが民間AIモデルをテストする可能性 今回の報道で特に注目すべきは、NSAが自発的なAIモデルテストに関与する可能性が浮上している点だ。NSAはサイバーセキュリティや暗号技術での長年の実績を持つ機関であり、その関与は以下を意味する。 悪意ある利用への脆弱性評価: サイバー攻撃支援や情報操作への利用可能性の検証 国家安全保障上のリスク評価: 敵対勢力による悪用シナリオの洗い出し 官民連携ガバナンスの確立: 民間AIと政府セキュリティ機関の協調モデルの整備 当面は「自発的」参加が想定されているが、将来的な義務化への布石との見方が業界では強い。 フロンティアAIとは何か 「フロンティアAI」とはGPT-4やClaudeのような現時点での最先端AIモデルを指す業界用語だ。広範な能力を持ち、一部の領域では人間の専門家を超えるパフォーマンスを示している。その潜在的リスクの大きさから、EU AI法をはじめ、国際的な規制議論の中心に置かれてきた。 実務への影響 日本のエンジニアやIT管理者にとって、この政策転換が示す含意は小さくない。 短期的な動向（6〜12ヶ月）: OpenAI・Anthropic・GoogleなどのAIサービスのリリーススケジュールが変化する可能性がある 新機能の公開遅延や、地域別の機能制限が発生するシナリオを想定しておく必要がある 中長期的な影響: EU AI法に続き、米国でもAIガバナンスの国際標準化が加速する可能性がある 社内AI活用ポリシーを策定する際の参考事例として活用できる 「政府がテスト済み」のモデルが信頼性の指標となる時代が来るかもしれない 実務での活用ポイント: AIサービスの棚卸し: 社内で利用しているAIサービスをリスト化し、各サービスのセキュリティポリシーを把握しておく マルチベンダー戦略の検討: 特定サービスへの依存を避け、政策変化に柔軟に対応できる体制を整える 情報源の確保: 米NIST（国立標準技術研究所）やホワイトハウスAI Officeの発表を定期的にウォッチする 筆者の見解 「規制なし・イノベーション優先」と「安全性重視」の二項対立で議論されがちだが、実態はもう少し複雑だ。 フロンティアAIのリリース前審査という方向性そのものは、一定の合理性がある。モデルの能力が急速に向上している今、「出してから考える」では社会的リスクに対処できないケースが確実に増えている。NSAのような機関が安全評価に関わること自体は、健全なガバナンスの一形態として機能しうる。 一方で、懸念もある。審査プロセスの設計次第で、イノベーションの速度と多様性が大きく変わるからだ。過剰に厳格な事前審査は、スタートアップや中小規模の研究者がモデルを世に出すコストを跳ね上げ、大企業優位の構造を固定化するリスクがある。「安全のため」という大義名分が競争制限に転用される事例は歴史上いくらでもある。 日本にとって重要なのは、米国の動きが国際基準の雛形になりやすいという点だ。「何が変わったか」を追いかけるだけでなく、「自分たちの組織はどう動くか」を今のうちに考えておくことが、変化への先手を打つことになる。情報を追い続けることよりも、自分たちが実際に使いながら判断基準を磨く経験を積む方が、今の時代の正しいアクションだと感じている。 出典: この記事は U.S. ramps up frontier AI testing as White House pivots toward safety | Axios の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleは2026年5月のGoogle I/Oにおいて、常時稼働型のパーソナルAIエージェント「Gemini Spark」を発表した。翌週よりGoogle AI Ultraサブスクライバー向けに米国での展開を開始するとしており、AIアシスタントの概念を大きく塗り替える可能性がある製品として注目を集めている。 Gemini Sparkとは何か Gemini Sparkは、従来の「呼びかけたら答えるアシスタント」とは設計思想が根本的に異なる。ユーザーが何かを尋ねるのを待つのではなく、24時間365日常にアクティブな状態でユーザーのデジタルライフを能動的に管理する「アクティブパートナー」として設計されている。 Googleが強調するのは「自律性」だ。カレンダー、メール、タスク、ドキュメントといったデジタルな行動を横断的に把握し、ユーザーが意識しなくても必要な処理を先回りして行う。たとえば、重要なメールに対して下書き返信を自動作成したり、会議の前に関連資料をまとめて提示したりといった動作が想定されている。 従来のAIアシスタントとの決定的な違い 受動型 vs 能動型 これまでのAIアシスタントは基本的に「問いかけ→応答」の受動的なモデルだった。ユーザーが何も言わなければ何もしない。これに対しGemini Sparkは、ユーザーの状況を継続的に監視し、自律的に判断・行動するモデルを採用している。 継続的なコンテキスト保持 常時稼働という特性により、過去の会話・行動・設定を長期にわたって記憶し続ける。「先週話していたあの件」を自然に引き継げるため、毎回コンテキストをゼロから説明し直す手間が不要になる。 デジタルライフ全体の統合管理 GmailやGoogleカレンダー、Google Driveなど、Googleエコシステム全体と深く統合されることで、単一アプリの枠を超えた横断的な管理が可能になる。 展開計画と利用条件 現時点では米国のGoogle AI Ultraサブスクライバーに限定した先行展開となる。Google AI UltraはGoogleの最上位AIサブスクリプションプランであり、月額料金は日本円換算で数千円規模とされている（現時点では日本での提供時期・価格は未発表）。 日本向けの展開については公式なタイムラインは示されていないが、Googleの過去のロールアウトパターンを見ると、米国先行から数ヶ月以内にグローバル展開が始まるケースが多い。日本語対応の品質も展開時期の重要な決定要因になるだろう。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンジニアの視点 Gemini Sparkが示すアーキテクチャは、自律型AIエージェントの設計パターンとして参考になる。「常時稼働」「状態の継続保持」「プロアクティブな行動」という3要素は、企業内のAI活用システムを設計する際の重要なヒントになる。 Google Workspace APIを活用してGemini Sparkと連携するカスタムワークフローの構築も、今後の開発案件として視野に入ってくるだろう。 IT管理者の視点 企業利用においては、「常時稼働AIエージェントに何を許可するか」というガバナンスの問題が新たに浮上する。メールの自動返信、スケジュールの自動調整、ドキュメントの自動処理——これらをどこまでAIに委ねるかは、各組織のポリシー策定が必要になる。 Google Workspaceの管理コンソールでどのような制御オプションが提供されるかを早期に把握し、展開前にポリシーを整備しておくことを推奨する。 一般ビジネスユーザーの視点 Googleエコシステム（Gmail・カレンダー・Drive・Meet）を日常的に使っているユーザーにとっては、情報の断片化が解消されることへの期待は大きい。ただし、AIが「先回りして動く」設計には慣れが必要であり、想定外の自動処理が発生するリスクもゼロではない。 筆者の見解 Gemini Sparkが目指している方向性——自律的に動き続けるエージェント——は、AIが本来あるべき姿に近い。「聞かれたら答える副操縦士」ではなく「自分で判断して動くエージェント」こそが、AI活用の本質的な価値を引き出せる。この設計思想は評価できる。 ただし「できること」と「実際に使えるか」は別の話だ。常時稼働エージェントは、精度が中途半端だと誤操作のリスクが受動型AIより格段に高くなる。メールを誤送信したり、カレンダーを勝手に書き換えたりする体験を一度でもすれば、ユーザーの信頼は一気に失われる。Googleにはこの点での高い完成度が求められる。 日本での実用という観点では、英語圏と比べて日本語対応の品質が劣化しやすいことは過去の経験から注意が必要だ。米国での展開結果と日本語品質の評価を見極めた上で、企業導入の判断を下すのが現実的なアプローチだろう。 自律型AIエージェントの波は確実に来ている。Gemini Sparkを含め、各社がこのパラダイムに本格投資し始めている今こそ、自社でのAIエージェント活用をどう設計するかを真剣に考える時期だ。 出典: この記事は Gemini Spark: Google’s always-on personal AI agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オープンソースの定番HTTPライブラリcurlのクリエイターDaniel Stenbergが、AIツールを活用したセキュリティ研究者たちによる「前例のない量と質のセキュリティレポート」が殺到しており、プロジェクトチームが極限の負荷にさらされていると自身のブログで公表した。 セキュリティレポートの実態：「1日1件超」が新常態に Stenbergによると、2026年現在のセキュリティレポート受信件数は2024年比で4〜5倍、2025年比でも2倍のペースに達しており、平均すると1日1件以上のペースで新規レポートが届く状態だという。 特筆すべきはその質の高さだ。従来の脆弱性報告は簡潔なものが多かったが、AI支援によるレポートは「非常に詳細で長文」になっているという。これは、AIが脆弱性の再現手順・影響範囲・修正提案までを自動的に生成・補完するようになった結果だ。 Stenbergは「妻が初めて、私の仕事時間とワークライフバランスについて懸念を口にした」と個人的なトレードオフについても率直に触れており、メンテナとしての精神的・時間的コストが著しく増大している現実を明かしている。 良いニュース：curlの堅牢性は証明されている 一方でポジティブな側面もある。大量のレポートが届く中でも、発見された脆弱性の深刻度は総じて低い。 curlチームの分析によると、直近数年間に発見されたすべての脆弱性は「LOW」または「MEDIUM」評価に留まっており、「HIGH」以上の深刻な脆弱性は2023年10月のCVEを最後に報告されていない。長年の継続的なメンテナンスによって高い品質を維持しているコードベースが、大量のAIスキャンに晒されてもその品質を証明し続けているとも言える。 実務への影響：依存ライブラリ管理とOSSの持続可能性 企業のIT部門が今すぐ取るべきアクション curlは世界中のシステムに組み込まれた最重要インフラの一つだ。Windowsにも標準搭載されており、AzureをはじめとするクラウドサービスからIoT機器まで広く使われている。curlで起きていることは、他のOSSライブラリでも近い将来同様に起きる可能性が高い。 依存ライブラリの脆弱性監視を自動化する：GitHub DependabotやSBOM（ソフトウェア部品表）管理ツールを活用し、curlを含むコアライブラリのCVE情報を継続的にトラッキングする体制を整える OSSメンテナへの還元を検討する：自社製品・サービスが依存するOSSプロジェクトへのスポンサーシップや、脆弱性修正へのコントリビューションを社内の検討テーマとして位置づける AI支援セキュリティスキャンを自社にも適用する：外部研究者がcurlに適用しているのと同様のAI活用アプローチを自社システムのセキュリティレビューに取り込む AI活用セキュリティ研究の「光と影」 今回の状況はAI活用の光と影を同時に見せている。AIが脆弱性発見を民主化し、セキュリティ研究の質を劇的に向上させた。これは紛れもなく前進だ。しかし同時に、人間のメンテナへの負荷集中という「新しい形の構造的問題」を生み出している。 筆者の見解 AIがセキュリティ研究の質と量を同時に引き上げているという事実は、率直に言って期待通りの展開だ。こういう形でAIの実力が出てくるのは自然だし、curlのように長年磨き込まれたコードベースが大量のスキャンの中でもLow/Medium止まりという結果を出しているのは、OSSコミュニティの底力を改めて感じさせる。 ただ、今回の件で気になるのはメンテナへの負荷集中問題だ。世界的なOSSメンテナが「妻に仕事時間を心配された」と書かなければならない状況は、AI活用の恩恵をコミュニティ全体で受けながらコストはメンテナ個人が負担するという構造的な歪みを示している。 AIによる自動セキュリティスキャンを活用している企業や研究者は、その成果として出てくるレポートをOSSプロジェクトに投げっぱなしにするのではなく、修正コントリビューションやスポンサーシップという形で還元するサイクルを意識すべきだろう。 日本のIT現場では、多くの企業がcurlに依存した製品・サービスを運用しながら、メンテナの状況をほぼ把握していない。OSSへの依存をリスクとして認識し、何らかの形でコミュニティに貢献する文化を育てることは、長期的には自社のセキュリティ態勢の強化にも直結する。AI活用の加速とOSSコミュニティの持続可能性は、これからのIT業界が正面から向き合うべき重要テーマになっていくはずだ。 出典: この記事は The pressure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが2026年のI/O開発者会議で検索体験を根本から刷新し、従来の青リンク一覧をAIエージェントに置き換えると発表した直後、プライバシー重視の検索エンジン「DuckDuckGo」のアプリインストール数が最大30.5%急増した。ユーザーが「AIを押しつけられる」と反発した結果だ。 Google検索の「AIエージェント化」とは何が変わったか Google I/O 2026で発表されたSearch刷新の核心は、クエリへの回答・タスク実行・バックグラウンド監視をAIエージェントが担う形への全面移行だ。これまでのGoogle検索が「情報への道案内」だったのに対し、新しい形では「AIが代わりに答えを出す」体験が前提となる。 AI Overview（AI概要機能）は以前から存在していたが、今回の刷新でその比重がさらに高まった。ユーザーが「AIを使いたくない」と思っても、オプトアウト手段が事実上ない設計が批判を集めている。 試しに「disregard」という単語でGoogle検索してみると、AIが文脈を読み違えた回答を前面に出すケースが報告されており、シンプルな辞書引きすら複雑になっているとの声も上がっている。 DuckDuckGoはどう動いたか DuckDuckGo CEOのGabriel Weinberg氏は「GoogleはオプトアウトなしでAIを強制供給している。結果として検索品質は向上ではなく低下している」と明言し、ユーザーがAIの量を自分でコントロールできる場所を提供すると宣言した。 同社の統計によると、5月20日〜25日の週次比では平均18.1%増のインストール増を記録。5月25日のピーク時には30.5%増に達した。iOSに限ると平均33%増、ピーク時には69.9%増という驚異的な数字だ。 AI機能をすべてオフにする専用URL（noai.duckduckgo.com）へのアクセスも、週次比で平均22.7%増加した。 興味深いのは、DuckDuckGo自身もAI製品「Duck.ai」を提供している点だ。Anthropic Claude 4.5 Haiku、Meta Llama 4 Scout、Mistral Small 3 24B、OpenAI GPT-5 miniなど主要モデルへのアクセスを無料で提供しつつ、IPアドレスの除去・30日以内の会話削除・学習データへの非使用を徹底している。 DuckDuckGoのCCPO Kamyl Bazbaz氏は「人々はただ選択肢が欲しいだけ」と端的に表現した。 日本のエンジニア・IT管理者への実務的影響 企業のブラウザポリシー見直しのタイミング Google検索のAIエージェント化は、企業端末の検索体験にも影響する。特に情報漏洩リスクに敏感な組織では、AIエージェントがクエリを処理・記録する可能性について改めて確認が必要だ。デフォルトの検索エンジン設定やプロキシ経由のフィルタリングポリシーを見直す良い機会といえる。 AI Overview の精度問題と業務利用の注意点 AI Overviewは高度な専門的クエリよりも、一般的な質問への回答精度が高い傾向にある。技術的なトラブルシューティングや仕様確認で検索を使う場合、AIが生成した概要を鵜呑みにせず、必ず一次ソース（公式ドキュメント・GitHub・Stack Overflow）を確認する運用を徹底したい。 DuckDuckGo Duck.ai の実用性 Duck.aiはアカウント不要でClaudeやGPTにアクセスできるプライバシー重視のAIチャットだ。社内規定でChatGPTやClaude.aiのアカウント登録が制限されている環境でも、DuckDuckGo経由であればIPアドレス除去・非学習の条件で利用できる可能性がある。ただし利用前に自社のセキュリティポリシーとの整合性確認は必須だ。 筆者の見解 今回の反発が示しているのは、AIの強制的な導入がいかにユーザーの反感を生むかという、非常にシンプルな教訓だ。 「禁止ではなく安全に使える仕組みを」というのが筆者の基本スタンスだが、それはユーザー側にも当てはまる。「使う仕組み」を強制するのではなく、「使いたい人が使える仕組み」を提供することが本筋だ。Googleが今回失ったのはまさにこの「選択の余地」であり、DuckDuckGoが受け皿になったのは必然とも言える。 AIを積極的に活用することは今の時代に不可欠だと強く思っている。だからこそ、「AIを使わせたい」あまりに選択肢を奪う設計は逆効果だと指摘したい。ユーザーが自発的にAIの価値を体験できる環境を整えることと、AIを強制することはまったく別の話だ。 DuckDuckGoが示した「AI機能はオプション、プライバシーはデフォルト」という設計思想は、企業のAIツール導入戦略にも参考になる。ユーザーに主導権を渡しながらAIの良さを体感させる設計こそが、長期的な定着につながる。 Googleほどの力があれば、ユーザーが「選んで使いたい」と思えるAI検索を実現できるはずだ。強制でしか普及させられないとすれば、それはプロダクトとしてもったいない。ユーザーの信頼を取り戻す設計への転換を期待したい。 出典: この記事は DuckDuckGo installs are up 30% as users reject being ‘force-fed’ Google’s AI Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。