生成AI

コーディングエージェント開発企業のCognitionは2026年7月8日、新しいコーディング特化AIモデル「SWE-1.7」を発表した。Moonshot AIの「Kimi K2.7 Code」をベースに独自の強化学習（RL）を重ねる「RL on top of RL」という手法で追加学習を行い、コーディング能力を測る「FrontierCode」ベンチマークでOpenAIのGPT-5.5にわずか0.7ポイント差まで迫る結果を叩き出した。しかも1タスクあたりのコストは約1.97ドルとGPT-5.5級のモデルとしてはかなり低い水準に抑えられており、高速推論に強みを持つCerebras経由で自律型コーディングエージェント「Devin」に統合される。 RL on top of RL――他社モデルの上に重ねる強化学習という戦略 Cognitionの技術的に興味深い点は、SWE-1.7が完全な自社開発モデルではなく、中国のMoonshot AIが開発した「Kimi K2.7 Code」をベースモデルとして採用していることだ。ゼロからモデルを事前学習するのではなく、既に高いコーディング性能を持つオープンウェイト系モデルに対して、Cognitionが持つDevin運用で蓄積した実タスクのフィードバックをもとに追加の強化学習を重ねる「RL on top of RL」というアプローチを取っている。 フロンティアラボが数千億〜数兆円規模の計算資源を投じて事前学習から手がけるのに対し、既存の強力なベースモデルに的を絞ったRLを重ねることで、開発コストを抑えながらフロンティア級の性能に近づけるという戦略だ。結果としてFrontierCodeベンチマークではGPT-5.5にわずか0.7ポイント差まで迫り、しかも1タスクあたり約1.97ドルという低コストを実現した。 Cerebras経由でDevinに統合、推論速度も武器に SWE-1.7は半導体企業CerebrasのウェハースケールAIチップ経由で提供され、Devinに統合される。Cerebras製チップは一般的なGPUクラスタに比べて推論速度（トークン生成速度）が非常に高いことで知られており、Devinのような「タスクを渡すと自律的にコードを書き、テストし、修正を繰り返す」エージェント型ワークフローとの相性がよい。エージェントが試行錯誤を繰り返すたびに推論待ち時間が発生する設計では、モデル性能だけでなく応答速度も体験を大きく左右するためだ。 実務への影響 なぜこれが重要か: この発表が示すのは、コーディングAIの競争軸が「モデル単体のベンチマークスコア」から「実運用コストとエージェントとしての速度・自律性」に移りつつあるという流れだ。GPT-5.5に肉薄する性能を1タスク2ドル程度で提供できるとなれば、企業が大量のコーディングタスクを自律エージェントに任せる際のコスト障壁が大きく下がる。日本のIT現場でも、コーディング支援を「人間が逐一確認する副操縦士型」から「目的を渡して任せる自律エージェント型」に移行する動きが今後さらに加速するだろう。 実務での活用ポイント: Devinのような自律型コーディングエージェントを検証する際は、ベンチマークスコアだけでなく「1タスクあたりのコスト」と「エージェントが自律的に完結できる範囲」を必ず確認したい。特にCI/CD連携やIssue対応の自動化を検討しているチームは、低コスト化によって「小さなバグ修正やテスト追加まで機械的にエージェントへ委任する」運用が現実的になってきている点に注目すべきだ。試験導入する場合は、まず影響範囲の小さいリポジトリやタスクから任せてみて、実際に成果を出す経験を積むのが近道になる。 筆者の見解 私は自律型AIエージェントの本質は「人間の確認・承認を待たずにタスクを完結できること」にあると考えている。その意味で、Devinのような自律エージェント製品を支えるモデルが着実に進化し、しかもコストを抑えながらフロンティア級に近づいてきているのは歓迎すべき流れだ。 個人的にはClaude Codeを軸にエージェント活用のノウハウを積み上げているが、Cognitionのように既存の強力なベースモデルにRLを重ねて実用コストを下げるアプローチは、ベンダーを問わず「エージェントを24時間ガンガン回す」時代に向けた合理的な選択だと感じる。ベンチマークの数字を追いかけること自体にはあまり意味がなく、大事なのは実際に自分の手元でエージェントを動かし、どこまで任せられるかを体感で掴んでいくことだ。SWE-1.7とDevinの組み合わせも、そうした「実践して確かめる」対象のひとつとして注視していきたい。 出典: この記事は Cognition SWE-1.7: RL on Top of RL Yields Near-Frontier Code at Low Cost の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft研究チームが、自社エンジニア数万人を対象にAnthropicの「Claude Code」とGitHubの「GitHub Copilot CLI」という2つのコマンドラインAIコーディングエージェントの導入実態を追跡調査した論文を公開した。2026年初頭の社内ロールアウトを分析した結果、これらのツールを使い始めたエンジニアは、使わなかった場合と比べてマージされたプルリクエスト（PR）数が約24%多かったという。 調査の中身 Emerson Murphy-Hill氏らMicrosoftの研究者3名がarXivに投稿したこの論文は、「Adoption and Impact of Command-Line AI Coding Agents」と題され、企業規模でのAIコーディングエージェント導入における3つの疑問——誰が試すか、誰が使い続けるか、コストに見合う成果が出ているか——に答えようとしたものだ。 調査結果のポイントは3つある。 最初の利用は社内の人間関係を通じて広がった。公式な研修や通達よりも、同僚が使っている様子を見ることが利用開始のきっかけになっていた 利用の継続は属性（役職や勤続年数）よりも、その人が普段どれだけ活発にコードを書いているかと強く関係していた 導入者は非導入者に比べてマージPR数が約24%多く、この差は4カ月間の観測期間を通じて一貫して続いた 研究チーム自身も「マージされたPRがそのまま提供価値を意味するわけではない」と釘を刺しており、単純な本数だけで生産性を語らない慎重な姿勢も示している。 実務への影響 日本のIT現場にとって示唆に富む調査だ。まず、CLI型AIエージェントの社内展開を検討する際、研修資料の整備や利用マニュアルの配布よりも、「使っている人の姿を見える化すること」の方が効果的だという点は覚えておきたい。Slackやチームの朝会で実際の活用例を共有する、社内Wikiに成功事例を蓄積する、といった地道な施策が普及の近道になる。 また、「導入すれば自動的に成果が出る」わけではなく、もともとコードを書く量が多いエンジニアほど使い続けるという結果も重要だ。AIエージェントは魔法の杖ではなく、既存の実務能力を増幅する道具だという理解のもとで展開する必要がある。 PR数24%増という数字も、KPIとして一人歩きさせるのは危険だ。マージ数だけを目標に据えると、質を犠牲にした「数稼ぎ」を誘発しかねない。研究チームが釘を刺した通り、成果指標は慎重に設計すべきだろう。 筆者の見解 興味深いのは、Microsoft自身の研究チームが、自社製品のGitHub Copilot CLIだけでなく競合であるAnthropicのClaude Codeも並べて公平に調査対象にしている点だ。都合の良いデータだけを見せるのではなく、実態を正面から検証しようとする姿勢は素直に評価したい。 GitHub Copilot CLIの存在自体も注目に値する。これまでのCopilotはエディタに寄り添う「副操縦士」型の体験が中心だったが、CLIエージェントという形は、目的を伝えれば自律的にタスクをこなす方向への一歩だ。ここ数年のCopilotの評判には物足りなさを感じてきた読者も多いはずだが、この路線は正しい方向であり、Microsoftには本気で勝負できる力があるのだから、中途半端に終わらせず突き詰めてほしい。 もう一つ評価したいのは、「トークン消費量」のような安直な数字ではなく、PRマージ数や継続率という多角的な指標で導入効果を測ろうとした設計思想だ。AI活用度を測ること自体は正しい方向であり、こうした地に足のついた検証を重ねる企業が、結局は組織的なAI活用で一歩抜け出すことになるだろう。 出典: この記事は A Study of Microsoft’s Early 2026 Rollout of Claude Code and GitHub Copilot CLI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年7月9日、AIチャットサービス「Claude」の利用状況を可視化し内省を促す新機能「Reflect」をベータ公開した。過去1〜12か月分の利用パターンをダッシュボードで確認できるほか、使いすぎを防ぐ「クワイエットアワー」設定、AIとの付き合い方を見つめ直す問いかけ機能を備える。対象はMemory機能を有効にしたFree・Pro・Maxプランのユーザーで、Web版とデスクトップアプリの設定画面から利用できる。 Reflectで見えるもの Reflectを開くと、よく使うトピックや作業の種類、利用時間帯の傾向がサマリーとして表示される。単なる利用時間の集計ではなく、「Claudeがどんな場面で自分の生活・仕事に組み込まれているか」を定期的に問い直す設計になっている点が特徴だ。ダッシュボードには「クワイエットアワー」や、一定時間使用後に休憩を促す通知の設定もあり、いずれもユーザー自身が任意にオン・オフできる。 Anthropicはこの機能を、同社が提唱する「4D AI Fluency Framework」（Delegation・Description・Discernment・Diligence）に基づいて設計したという。目標設定とAIへの委任判断、指示の明確さ、AI出力の吟味、成果への責任という4つの観点から自分のAI活用スタイルを振り返り、「メールの下書きは自分の言葉で書き直す傾向がある」「戦略を固めてからでないと委任しない」といった傾向を提示し、Projectの活用など具体的な改善提案も行う。 プライバシー面では、シークレットチャットや連携ツールの元データ（受信トレイの要約はレポートに出るが元メールは出ない）、健康関連の連携チャットは対象外とするなど配慮している。MITメディアラボやボストン小児病院の専門家と共同で設計したとしている。 実務への影響 日本の開発現場でも、生成AIの利用状況を「どう測るか」は今まさに議論になっているテーマだ。Reflectはトップダウンの管理指標ではなく、利用者自身が自分のAI活用を振り返るための仕組みである点が実務上のヒントになる。IT管理者にとっては、社内でAI活用を促進する際に「監視」ではなく「気づきを与える」アプローチの方が利用者の抵抗感を減らせる可能性がある。エンジニア個人としても、AIに任せている作業と自分で手を動かすべき作業の線引きを定期的に見直す習慣は、スキルの空洞化を防ぐ観点でも有効だろう。 筆者の見解 生成AIの活用度を測ろうという発想自体は正しい方向だと考えている。ただし多くの組織が陥りがちなのは、トークン消費量や利用回数をリーダーボードで競わせるような安直な数値目標だ。数字だけが独り歩きすると、本来の目的である「AIを使って成果を出す」ことから逸れてしまう。 その意味で、Reflectが「管理者が監視するダッシュボード」ではなく「本人が振り返るダッシュボード」として設計されている点は評価できる。今の時代、エンジニアが生成AIを積極的に使わないこと自体がリスクだと筆者は考えているが、だからといって使用量だけを追わせる仕組みは逆効果になりかねない。Anthropicのこの取り組みは、AI活用を組織で広げる際の「仕組みづくり」の一例として、日本のIT現場でも参考にする価値があるだろう。 出典: この記事は A new way to reflect on how you use Claude の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年6月29日、Amazon BedrockおよびGoogle Cloud経由でClaude Codeを利用する企業向けに、自社インフラ上で運用できる管理基盤「Claude apps gateway」を発表した。開発者ごとにクラウド認証情報を発行し、設定ファイルを各端末へ手作業で配布し、利用状況を個別ツールで追跡するという、これまでの運用負荷の高いやり方を置き換えるものだ。 何が変わるのか これまでBedrockやGoogle Cloud経由でClaude Codeを使う場合、企業は開発者一人ひとりにクラウド認証情報を割り当て、設定を手動で端末に配布し、利用量やコストを可視化する仕組みを別途用意する必要があった。Claude apps gatewayは、この3つの課題を1つのセルフホスト型コンテナに集約する。 Claude apps gatewayの4つの機能 Linux上でPostgreSQLをバックエンドに動くステートレスなコンテナとして提供され、次の役割を持つ。 ID管理: Google Workspace、Microsoft Entra ID、Okta、その他標準準拠のOIDCプロバイダーに対してOpenID Connectのリライング・パーティとして動作し、短命セッションを発行する。開発者の端末に長期間有効な秘密情報を置かない設計だ。 ポリシー: サーバー側で一度定義したmanaged settingsをサインイン時にクライアントへ配布し、以降すべてのリクエストで強制する。利用可能なモデルやデフォルト設定を一元的に調整できる。 テレメトリ: リクエストごとの利用状況をOTLP経由で、自社が管理するコレクターに送信する。 ルーティングと支出上限: Claude API・Amazon Bedrock・Google Cloudへの推論ルーティング(フェイルオーバー可)に加え、組織・グループ・ユーザー単位で日次/週次/月次の支出上限を設定できる。 Claude APIを明示的に使う構成にしない限り、推論トラフィックや利用データがAnthropicに送信されることはない。またAnthropicはゲートウェイが使うプロトコル自体を公開しており、他社が同等機能を独自実装できるようにもしている。 実務への影響 日本企業がAWSやGoogle Cloudをメインクラウドとして選び、そこ経由でClaude Codeを導入する場合、これまでは開発者ごとのAPIキー管理やコスト把握が情シス部門にとって地味に重い運用負担だった。個々人が野良でAPIキーを発行する状態が続くと、退職者の権限剥奪漏れやコスト超過といったリスクが積み上がる。Claude apps gatewayは、これを既存のEntra IDやOktaといったIDプロバイダーにそのまま乗せる形で解消できる点が実務的だ。 活用の入口はシンプルで、gateway.yamlにOIDC発行者とアップストリーム認証情報を設定し、IdP側にOIDCアプリを1つ登録するところから始まる。展開時はクライアント側のmanaged-settings.jsonでforceLoginMethodとforceLoginGatewayUrlを指定すれば、初回起動時に自動的にゲートウェイへ接続する。すでにEntra IDで社内SSO基盤を持つ企業であれば、追加のID基盤を新設せずに展開できる点は評価してよい。 筆者の見解 このアップデートは「禁止ではなく安全に使える仕組みを用意する」という王道の発想で、好感が持てる。開発者が各自でAPIキーを発行して使うシャドーIT状態を放置するより、公式に便利な入り口を用意してそこに乗ってもらう方が、結果的に統制もセキュリティも効きやすい。これは生成AIツール全般に言えることで、Microsoft Entra IDのような既存のID基盤へそのまま統合できる設計は素直に王道だと思う。 Microsoft自身も、EntraやFoundryを軸にした企業向けAIガバナンスの整備を進めている。認証・ポリシー・支出管理を一箇所にまとめるという発想では、これまで積み上げてきた統合力を活かせば正面から勝負できる力があるはずで、他社のこうした動きを一つの刺激として、その強みをもっと前面に出してほしいところだ。 企業のIT管理者にとっての教訓はシンプルで、AIエージェントの利用を個人任せの野良運用にせず、公式に管理された経路を用意することが、結局は一番の近道だということだ。 出典: この記事は Introducing the Claude apps gateway for Amazon Bedrock and Google Cloud の内容をもとに、筆者の見解を加えて独自に執筆したものです。

📝 この記事についてこの記事は、AIエージェント（Claude）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 続きをみる note.com で続きを読む →

英ケンブリッジ大学のAI科学・政策プログラム（CASP）は、ナイジェリアのイスラム過激派組織ボコ・ハラムの両派閥が、OpenAIのChatGPT、AnthropicのClaude、GoogleのGemini、xAIのGrok、Meta AI、中国DeepSeekといった主要フロンティアAIを、戦闘計画の立案や兵器のトラブルシューティングなど実戦活動に組織的に活用していたとする調査報告書を公表した。 27人の元メンバーへの聴取から浮かび上がった実態 CASPは2025年から2026年にかけて、ボコ・ハラムを離脱した元戦闘員27人への半構造化インタビューを実施し、フロンティアAIが現場でどう使われていたかを再構成した。報告書が挙げる利用目的は、戦闘計画の策定、武器のトラブルシューティング、爆発装置の設計支援、そして日常的な組織運営の効率化と多岐にわたる。特筆すべきは、一部のユーザーが各社の安全対策（セーフガード）を突破することに成功していたと記録されている点だ。 なぜ「体系的」なのか 報告書が強調するのは、この利用実態が従来の分析が想定していたよりもはるかに進んでおり、場当たり的ではなく体系的だったという点だ。テロ組織側が特定の1社のAIサービスに依存するのではなく、複数のベンダーのサービスを使い分けていたことも読み取れる。これは、単一ベンダーの対策強化だけでは問題が解決しない、業界横断の課題であることを示している。CASPは政策立案者・セキュリティコミュニティ・AI開発企業の三者が連携して注視すべきだと結論づけている。 実務への影響 この報告書は、AIを組み込んだプロダクトやサービスを開発・運用する日本のエンジニア、それを導入するIT管理者にとっても他人事ではない。第一に、フロンティアAIのセーフガードは「絶対に破られない壁」ではなく、悪意ある利用者による継続的な迂回の試みにさらされ続けているという前提でシステムを設計する必要がある。自社サービスにLLMを組み込む際は、モデル提供元のガードレールに全面的に依存せず、入力・出力の双方に対する追加のモニタリングや異常検知の仕組みを重ねて用意しておくべきだろう。第二に、レッドチーミング（悪用者視点でAIを攻撃してみるテスト）の重要性が改めて浮き彫りになった。社内でAIエージェントを本番導入する前に、想定外の目的での利用や安全対策の迂回が可能かどうかを検証するプロセスを組み込むことが、今後のガバナンスの標準になっていくはずだ。 筆者の見解 AIエージェントの価値は「目的を伝えれば自律的にタスクを遂行する」自律性にある、というのが筆者の一貫した立場だ。だがこの自律性は諸刃の剣でもある。今回の報告書が突きつけるのは、まさにその裏面だろう。人間の認知負荷を下げる仕組みは、使う人間の意図が善であれ悪であれ機能してしまう。 だからといって「AIを禁止すればいい」という結論には賛成しない。禁止アプローチは必ず失敗する、というのが筆者の持論だ。しかも今回悪用されたのは特定の1社のサービスではなく、業界のほぼすべての主要フロンティアAIだった。つまりこれは一社のガードレール強化で片付く話ではなく、業界全体でセーフガードの設計思想を磨き続けるしかない構造的な課題だ。 日本のAIベンダーやシステムインテグレーターも、「うちは大丈夫」で済ませず、自社が扱うAIサービスが悪意ある目的にどう転用され得るかを継続的に検証する体制を持つべきだ。正規ユーザーには最高の使い勝手を提供しつつ、悪用のハードルを上げ続ける——この地道な両立にしか、答えはないはずだ。 出典: この記事は How the terrorist group Boko Haram uses frontier AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIベンチマークメディアのTryAIは2026年7月9日、OpenAIの新モデル「GPT-5.6」(Sol・Terra・Lunaの3グレード)、xAIの「Grok 4.5」、AnthropicのClaude(Opus 4.8・Fable 5)、Metaが初めて投入したコーディング特化モデル「Muse Spark 1.1」、さらにQwen・DeepSeek・Kimi・GLMなどオープンウェイト系を加えた合計12種のAIモデルに、同一の4本のアプリ――レイキャスター式3D迷路、3Dルービックキューブ、電卓、ライフゲーム――を作らせる「ビルドオフ」対決の結果を公開した。各モデルにつき5回ずつ試行し、成功率のばらつきとコスト・所要時間を並べて可視化したのが今回の見どころだ。 前回への反応を反映した再検証 TryAIは以前実施した同様の企画がHacker Newsで大きな反響を呼び、「オープンウェイトモデルも入れてほしい」「1回の試行だけでは判断材料として弱い」という指摘を受けていた。そこで今回はQwen 3.7 Plus・DeepSeek V4 Pro・Kimi K2.6・GLM-5.2をFireworks経由で追加し、各タスクを5回ずつ試行する形に改めた。TryAI自身も「これは科学的な検証ではなく、あくまで観察結果の共有」と明言しており、数字を鵜呑みにせず参考情報として捉えるべき性質のものだ。 レイキャスター迷路で見えた明暗 最初の課題「WASDで歩けるレイキャスター式3D迷路」では、GPT-5.6 Sol(5/5成功、$1.35、120秒)とGPT-5.6 Luna(5/5成功、$0.15、23秒)がともに満点を記録した。特にLunaは最安・最速でありながら安定して動くコードを生成しており、軽量タスクでは必ずしも高価格帯のモデルが必要ないことを示した。Grok 4.5も5/5・$0.27というコストパフォーマンスの良さを見せている。一方Claude Opus 4.8は4/5(堅実だが平凡)、上位モデルのClaude Fable 5は最も高コスト($2.35)でありながら3/5にとどまった。MetaのMuse Spark 1.1は2/5と成功率こそ低いものの、成功した回はGPT-5.6 SolやClaude Fable 5に匹敵する完成度だったとTryAIは評価しており、Metaが本気でコーディング領域に参入してきたことをうかがわせる。オープンウェイト勢では、GLM-5.2が見た目の描画は良好ながら一度もキャラクターを動かせず0/5に終わるなど、モデルごとの得意不得意がくっきりと分かれた。 実務への影響 日本のIT現場でも、単一ベンダーのモデルに固定せず用途に応じて複数モデルを使い分ける「マルチモデル運用」が現実的な選択肢になりつつある。今回のようにコスト・所要時間・成功率が同じ土俵で比較できるデータは、社内でモデル選定の基準を作る際の材料になる。特に「最新の上位モデルが常に最善とは限らない」という点は実務上重要で、単純なUI生成やプロトタイピングであれば安価な下位グレード(Lunaのような)で十分なケースは多い。開発チームがモデルを選ぶ際は、公開ベンチマークの数字だけで判断せず、自社の実タスクで同条件の比較を行うことをおすすめしたい。 筆者の見解 筆者は日頃、AIエージェントによる自律的なコーディングをClaude Codeで使い倒しているが、今回のような「1回の指示でどこまで完成度の高いコードを一発生成できるか」というベンチマークは、実際の開発現場で価値を発揮する自律ループ型のエージェント運用とは評価軸が異なる点に注意したい。エージェントが自分でコードを実行し、テストし、失敗したら直すというループを回せるかどうかが今の開発体験を左右する本質であり、単発生成の巧拙とは別の話だ。その意味で、今回Claude系が振るわなかった結果はやや意外ではあるものの、一発勝負のタスクでの数字であることは差し引いて見る必要がある。むしろ興味深いのはMetaのMuse Spark 1.1の健闘で、成功時の完成度が上位モデル並みだったという結果は、コーディング領域の競争がここまで激しくなっていることの表れだろう。ベンチマークの数字を追いかけるより、自分の手元のワークフローで実際に試して確かめるのが結局は一番の近道だと改めて感じさせる企画だった。 出典: この記事は GPT-5.6, Grok 4.5, Claude, and Muse Spark build the same 4 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

xAIは新しい大規模言語モデル「Grok 4.5」を投入した。コーディングエージェント向けの利用コストを最大80%削減しながら、フロンティアモデル並みの応答速度を実現した一方、第三者ベンチマーク機関Artificial Analysisの検証では、幻覚(ハルシネーション)の発生率が旧モデルの25%から54%へと倍増したことが明らかになった。 Grok 4.5とは何か xAIが提供する最新の大規模言語モデルで、特に「コーディングエージェント」——人間の指示に基づきコードの生成・修正・テスト実行までを自律的に行うAIエージェントの頭脳部分——としての利用を想定して調整されている。 xAIの主張によれば、Grok 4.5をコーディングエージェントのバックエンドとして使った場合、従来モデル比で最大80%のコスト削減が可能で、応答速度も業界最速クラスのモデル群(いわゆる「フロンティアモデル」)に迫る水準に達しているという。 コスト8割減と引き換えの代償 Artificial Analysisは独立系のAIベンチマーク機関で、各社のモデルを共通基準で横並び評価していることで知られる。同社の検証では、Grok 4.5はタスクの正答率(accuracy)についても旧モデルの35%から52%へと大幅に向上したと報告されている。 一方で見過ごせないのが幻覚の発生率だ。同じ検証で、旧モデルの25%から54%へとほぼ倍増したことが確認されている。単に「間違える」だけでなく「自信満々に間違える」傾向が強まっている点が指摘されており、正答率の向上と幻覚率の悪化が同時に進行するという、やや異例のトレードオフとなっている。 実務への影響 日本のエンジニアやIT管理者にとって、この一件が示す教訓は明確だ。コーディングエージェントの導入コストは今後も下がり続ける可能性が高い一方、「速くて安いが、たまに自信満々に嘘をつくモデル」をどう安全に運用するかが、AIエージェント活用の実務上の課題になる。 具体的な対策としては以下が考えられる。 自動テスト・CIとの組み合わせを必須にする: コーディングエージェントが生成したコードは、人間のレビューだけでなくユニットテスト・統合テストを機械的に通過させる仕組みを作る。幻覚率が上がったモデルほど、この「検証ゲート」の重要性が増す 重要度に応じてモデルを使い分ける: コストが安いモデルを定型的なリファクタリングやボイラープレート生成に、精度が求められる設計判断やセキュリティ関連のコードには別モデルや人間のレビューを充てるといった、タスクの重要度に応じた使い分けが有効 ベンチマークの数字を鵜呑みにしない: 正答率や幻覚率は測定条件に強く依存する。自社のユースケースで実際に試し、幻覚がどのパターンで起きやすいかを自分の目で確認するプロセスを省略しない 筆者の見解 筆者はふだんコーディングエージェントの中心にClaude Codeを据えて実務を回している立場だが、xAIやOpenAI、Googleを含め各社がコーディングエージェント向けにモデルを最適化し、価格競争を繰り広げていること自体は歓迎すべき流れだと考えている。コストが下がれば下がるほど、AIエージェントを気軽に、大量に使う選択肢が広がるからだ。 ただし今回のGrok 4.5の件が示すように、コスト削減と精度・信頼性はトレードオフになりやすい。コーディングエージェントの本質は人間の確認作業を減らすことにあるはずで、幻覚率が倍増したモデルは、たとえ処理コストが8割減っても、人間による検証コストがその分増えてしまっては本末転倒になりかねない。トークン単価だけを見て「安くなった」と評価するのではなく、検証コストも含めたトータルの運用コストで判断すべきだろう。 もう一つ強調したいのは、新モデルが出るたびに一喜一憂して追いかけ回す必要はないということだ。次々と登場する新モデルの性能比較を追いかけるより、自分が使い慣れたエージェント環境の中で、テストやCIを組み込んだ検証ループをどれだけ堅牢に作り込めるかの方が、実務上のリターンははるかに大きい。Grok 4.5のニュースも「このモデルに乗り換えるべきか」ではなく、「自分の開発フローの検証ゲートは、幻覚率が多少上下しても壊れない設計になっているか」を点検するきっかけとして受け止めるのがちょうどいい。 出典: この記事は Grok 4.5 Cuts Coding-Agent Cost 80%: Near-Frontier Speed, Higher Hallucinations の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Metaは2026年7月8日、Instagramの新しい画像生成AIモデル「Muse」に関連する機能として、公開アカウントを「@」でタグ付けするだけでその投稿画像を参照したAI生成画像を作れる仕組みを発表した。しかし公開からわずか数日で「本人の同意なく他人の肖像を使ったディープフェイクを助長する」との強い批判を浴び、Metaは同機能を全面停止した。 何が起きたのか 問題となったのは、Museの画像生成時に公開Instagramアカウントを@メンションすると、そのアカウントが投稿してきたコンテンツを参照した画像を誰でも生成できるという仕様だ。対象は本人が同意した相手に限らず、公開設定のアカウントであれば原則として誰の投稿でも参照可能だった。オプトアウトの手段は用意されていたものの、設定画面の奥深くに埋もれており、機能はデフォルトで有効になっていた。 性的搾取防止に取り組む非営利団体「National Center on Sexual Exploitation」のHaley McNamara氏は「自分自身の肖像に対する権利を明らかに侵害するだけでなく、セクストーションなど詐欺の道具になり得る」と厳しく批判。俳優組合SAG-AFTRAも会員に対しオプトアウトを推奨し、その手順を公式に案内する事態となった。 Metaは公式ブログの更新で「有用な創作ツールを提供する意図だったが、狙いを外したというフィードバックを受け止め、機能の提供を停止した」と説明している。 「オプトアウト任せ」の設計が招いた炎上 今回の本質的な問題は技術力ではなく同意設計（コンセントデザイン）にある。「本人が明示的に許可した場合のみ利用可能」というオプトイン設計ではなく、「デフォルトで利用可能、嫌なら自分で探して止める」というオプトアウト設計を採用したことが炎上の火種になった。生成AIが個人の投稿や肖像を扱う機能では、この設計順序を間違えると影響範囲が一瞬で拡大する。 実務への影響 日本のエンジニア・IT管理者にとっても他人事ではない。生成AIを使って第三者のコンテンツ（写真・投稿・音声など）を参照する機能を設計する際は、必ず「デフォルトはオプトイン」を徹底すべきだ。社内向けツールでも、社員の顔写真やSNS投稿を参照する生成AI機能を安易に実装すると、同様のリスクを抱え込むことになる。 日本には肖像権・パブリシティ権に関する判例の蓄積があり、無断でのAI生成物への肖像利用は法的リスクを伴う。生成AI機能をリリースする前に、悪用シナリオ（なりすまし、誹謗中傷、性的搾取目的の利用など）を想定したレッドチーム的な事前レビューを行う体制を、開発フローに組み込んでおくことが望ましい。 筆者の見解 今回の一件は、生成AIの実装力そのものよりも「安全に使える既定値をどう設計するか」がプロダクトの成否を分けることを改めて示している。禁止で縛るのではなく、最初から安全な既定値の中でユーザーが安心して使える仕組みを用意する——これは生成AI機能を作るすべての企業に共通する基本のはずだ。Metaほどのリソースと規模を持つ企業であれば、公開前にこの種のリスクを潰す体制を敷けたはずで、その意味では「もったいない」対応だったと言わざるを得ない。 生成AIの活用が広がるほど、個人の肖像や投稿を扱う機能の設計には一段と慎重さが求められる。日本企業が同様の機能を検討する際は、今回のInstagramの事例を「デフォルト設計を間違えると信頼を一瞬で失う」という反面教師として活用してほしい。 出典: この記事は Meta turns off the Instagram feature that let users make AI deepfakes of public accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 続きをみる note.com で続きを読む →

Appleは現地時間2026年7月10日、OpenAIおよびJony Ive氏が率いるハードウェアスタートアップIO Productsを相手取り、企業秘密（トレードシークレット）の窃取を理由に提訴した。Appleは訴状で「OpenAIに在籍する元Apple社員による、組織的な企業秘密の窃取パターン」を発見したと主張しており、単なる人材流出ではなく計画的な情報持ち出しがあったとしている。 何が疑われているのか 訴状で名指しされているのは、OpenAIのチーフ・ハードウェア・オフィサーであるTang Tan氏と、2026年1月にAppleからOpenAIへ移ったChang Liu氏の2人だ。 Apple側の主張によれば、Liu氏は退職後もAppleの社内システムにアクセスし、未発表製品の詳細なハードウェア関連ファイル、エンジニアリング資料、技術仕様、独自プロジェクトデータなど数十件の機密ファイルをダウンロードしたとされる。さらに、Apple在籍中の元同僚に対し機密ファイルのコピー方法とセキュリティチームに「トラブルにならない」方法を指南し、検知を避けるためLINE Messengerでやり取りするよう持ちかけたという。 Tan氏についても、退職前にAppleのサプライヤー情報を自分宛にメール送信していたほか、Apple従業員をOpenAIの採用面接に呼ぶ際、Appleの機密情報の提供を求めていたとApple側は主張する。OpenAIは面接に訪れるApple従業員にCAD/デザインデータやプロトタイプの持参を促していたとも指摘されている。 Appleは、400人を超える元Apple従業員が現在OpenAIに在籍しているとし、OpenAIが退職予定のApple従業員に「Appleから何かにサインするよう求められたら教えてほしい」と伝えていたとも主張している。OpenAI広報は「他社の企業秘密に興味はない」とThe Vergeに述べ、疑惑を否定している。 Jony Ive氏のIO Productsも被告に 訴訟でOpenAIと並んで名指しされているのが、Jony Ive氏が設立し、OpenAIが2025年に買収したハードウェアスタートアップIO Productsだ。IveはAppleのデザインを長年率いた人物であり、IO ProductsはOpenAIのAIネイティブなハードウェア製品開発の中核を担うとされる。Appleが「数十年かけて築いた消費者向けハードウェア事業のノウハウを再現しようとする組織的な試み」と表現する背景には、OpenAIがソフトウェア企業の枠を超え、Appleと同じハードウェア市場に本格参入しようとしていることへの強い警戒がある。 実務への影響 — オフボーディングとサプライヤー管理の見直しを 日本のIT現場にとっても他人事ではない。生成AI人材の争奪戦が激化する中、優秀なエンジニアの転職は今後さらに増える。今回のケースが突きつけるのは、退職者のアクセス権限を「退職日にきちんと止める」という、地味だが極めて重要な運用の徹底だ。SaaSアカウント、社内システム、コード管理基盤へのアクセスが退職後も生きていないか、オフボーディングのチェックリストを見直したい。 またApple側は、サプライヤー企業がAppleの独自プロセスを他社のために実行していたとも主張している。委託先を通じた情報流出は日本企業でも起こりうるリスクであり、契約書の秘密保持条項の実効性やパートナー企業側の情報管理体制の点検にも価値がある。日本の不正競争防止法も営業秘密を保護するが、実際に立証まで持ち込むにはAppleのように「持ち出しの証跡」を体系的に押さえる備えが参考になる。 筆者の見解 今回の訴訟は、AI企業がソフトウェアの世界からハードウェアという新しい戦場に踏み出したことで、既存の巨大企業との摩擦が顕在化した典型例だと見ている。OpenAIがIO Productsを買収してまでハードウェアに本気で取り組んでいるのは業界にとって刺激的な動きだ。ただし、今回Appleが主張する内容——退職後のシステムアクセスや検知回避を意図したやり取りの指南——が事実であれば、これは競争の話ではなく単純なコンプライアンス違反であり、擁護のしようがない。 AI業界全体で人材の流動性が高まるのは健全なことだが、それは秘密保持義務や契約上の制約を守った上での話だ。Microsoft周辺でもAI人材の獲得競争は同様に激しく、この種のトラブルは対岸の火事ではない。企業として大事なのは、優秀な人材が正規のルートで移籍しても不利益がない仕組みと、機密情報へのアクセス管理を両立させることだろう。訴訟の行方自体よりも、この一件が各社のオフボーディングや情報管理体制を見直すきっかけになるなら、業界にとって悪くない副産物だと思う。 出典: この記事は Apple sues OpenAI for allegedly stealing hardware secrets の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ソフトウェアエンジニアのAlec Scollon氏は7月8日、自身のブログで「LLM燃え尽き症候群になったかもしれない」と告白した。仕事ではAnthropicのClaude Code、自宅ではOpenAIのCodexを毎日何時間も使い続けてきた同氏は、生産性の向上を実感する一方で、AI生成テキストに特有の「紋切り型の言い回し」や「過剰な絵文字」、そして繰り返される事実誤認（ハルシネーション）に強い疲労を感じ始めたという。この投稿はHacker Newsで328ポイント・266件のコメントを集め、多くの開発者から共感の声が上がっている。 「コーディング」から「LLM出力のレビュー」へ変わった仕事 Scollon氏の日々の仕事は、かつての「設計してコードを書く」というスタイルから、「設計を考え、Claude CodeやCodexに説明し、生成されたコードをレビューし、最後に自分でコードを書く」という流れに変化した。現在の主な取り組みは、社内のコードベースで大規模かつ人手を介さないコード生成の仕組みを構築することだ。Claude Codeでそのためのツールを作る一方、オープンウェイトモデルのQwenを使った自律型エージェントが生成した大量のコードをひたすらレビューする毎日を送っている。検索も同様で、知りたいことがあればまずChatGPTに聞くかGeminiの概要を読み、答えが怪しいときだけ従来型のブラウジングに戻るという。 疲労の正体は「ツールの不安定さ」ではなく「パターンの反復」 Scollon氏が強調するのは、LLMの間違いや癖そのものではなく、その「反復性」が疲労の原因だという点だ。断定的で短く区切られた文体、過剰な絵文字、同じ種類のハルシネーション――これらは個別には気にならなくても、毎日大量に浴び続けると精神的な負荷になる。人間の文章にも癖や間違いはあるが、LLMは無数の他人が生成した文章にも触れる機会が多く、自分では文体をカスタマイズできても、他者が生成したAIコンテンツの「型」までは制御できない。 実務への影響 日本のIT現場でも、Claude CodeやGitHub Copilot、ChatGPTなどを日常的に使うエンジニアやIT管理者が急増している。この記事が示すのは、AI活用の「量」を追いかけるフェーズが一段落し、次は「AI生成物とどう付き合うか」という質のフェーズに入ってきているということだ。具体的には次のような対策が現実的だ。 カスタムインストラクションで文体を制御する: Claude Codeの CLAUDE.md やChatGPTのカスタム指示、Copilotのプロンプト設定などで、絵文字の使用や文体のトーンを事前に指定しておくと、反復疲労をある程度軽減できる レビュー方式を見直す: 生成コードを1行ずつ人間が読む方式のままでは、生成量が増えるほど疲弊が加速する。テストやCIでの自動検証を厚くし、人間のレビューは「設計判断」や「危険な変更」に絞り込む設計に切り替える チームのAI活用ルールを明文化する: 個人の裁量に任せると、生成文章の文体やレビュー負荷がメンバーごとにばらつく。ドキュメントやコミットメッセージの生成ルールをチームで統一すると、読み手の負担も減る 筆者の見解 この告白は率直に「あるある」だと感じた。人間がAIの生成物を一行ずつ検証し続ける限り、いくら生成速度が上がっても人間側のレビュー負荷はむしろ増える。これはAIエージェントの設計思想の問題で、確認や承認を人間に求め続ける「副操縦士」型の使い方をしている限り、燃え尽きは避けられない構造だと考えている。 本来AIエージェントが果たすべき役割は、人間の認知負荷を減らすことのはずだ。Scollon氏自身、Qwenによる自律エージェントの出力をひたすらレビューする作業に時間を取られているというが、これはまさに「人間がまだ確認係から抜け出せていない」状態を象徴している。目的とガードレールを渡したら、あとはエージェントが自律的にループを回して判断・実行・検証まで済ませ、人間は結果とリスクの高い判断だけを見る――そういう「ハーネスループ」的な設計に踏み込むフェーズに来ているはずだ。 情報を追いかけて「あれも試した、これも試した」と広く浅く手を広げるより、自分の手元の仕組みを一つ実際に動かし、そこで見えてきた摩擦（今回でいえば「レビュー疲れ」）を仕組みの改善にフィードバックしていく方が、今の時期は圧倒的に生産的だと思う。Scollon氏の疲労は、AIを使いすぎた結果ではなく、AIの使い方をまだアップデートできていないサインとして受け止めるのが正しい読み方ではないだろうか。 出典: この記事は I think I have LLM burnout の内容をもとに、筆者の見解を加えて独自に執筆したものです。

スウェーデン発のvibe（バイブ）コーディングスタートアップLovableが、Menlo Venturesを主要投資家として3億ドル（約450億円）の新規調達交渉に入っていると、欧州メディアのSiftedが報じた。実現すれば評価額は2025年12月時点の66億ドルから倍増し、132億ドル（約2兆円）に達する見通しだ。 創業3年未満でARR500億円規模に急成長 Lovableは自然言語で「作りたいもの」を説明するだけでWebサイトやECサイトを生成できるvibeコーディングツールを提供する。創業からまだ3年に満たないが、2026年6月時点の年間経常収益（ARR）はすでに5億ドル（約750億円）に達したという。個人の起業家・デザイナー・営業担当者向けの手軽なサイト構築ツールとしてだけでなく、Workday、Asana、NVIDIAといった大企業への導入も進んでおり、コンシューマー向けとエンタープライズ向けの両輪で収益を伸ばしている点が特徴だ。 過熱するvibeコーディング市場 資金が集まっているのはLovableだけではない。Replitは2026年3月に90億ドルの評価額をつけ、AIエージェント開発を支援するFactoryも4月に15億ドルの評価額で1.5億ドルを調達した。極めつけは、開発者向けvibeコーディングツールを手がけるCursorが先月SpaceXに600億ドルで買収された一件だ。「説明するだけでコードが書ける」という生成AIの体験は、もはや実験段階のニッチな機能ではなく、数十億〜数百億ドル規模の資金が集中する主戦場になっている。 実務への影響 日本のIT現場にとっても他人事ではない。vibeコーディングはプロトタイピングやMVP開発のスピードを劇的に引き上げる一方、生成されたコードの保守性やセキュリティレビュー体制をどう整えるかが実務上の課題になる。WorkdayやAsanaのような大企業がすでにLovableを業務に組み込んでいる事実は、こうしたツールが「お試し」の段階を超えてエンタープライズの実運用フェーズに入りつつあることを示している。IT管理者は、私的なツール利用を禁止する方向で対処しようとしても長続きしない。公式に安全な形で使える標準ワークフローとレビュー体制を早めに用意しておく方が、結局は現場にとっても管理側にとっても近道になる。エンジニア個人としても、実際に触れて生成コードの品質や限界を体感しておくことが、今後の技術選定や社内提案の説得力につながるはずだ。 筆者の見解 評価額の数字だけを追うと「バブルではないか」という声が出るのも無理はないが、筆者はこの資金の流れそのものより、その根底にある変化の方が重要だと見ている。「目的を説明すればコードやアプリが形になる」という体験は、AIエージェントが人間による逐一の確認・承認を肩代わりし、認知負荷を下げる方向に技術が進んでいることの表れだ。Lovable、Replit、買収されたCursorに共通するのは、ユーザーが細かく指示を出し続けなくても、目的さえ伝えれば自律的に形にしていくという設計思想だろう。この「自律型エージェント」への流れは今後さらに強まっていくはずで、日本の開発現場でも「指示を出して待つ」から「目的を渡して任せる」への発想転換が求められる局面が近づいている。個々のツールの優劣を追いかけて情報収集に時間を使うより、まずは実際に業務で触ってどこまで任せられるかを体感しておくことが、今この瞬間にできる一番の投資だと筆者は考えている。 出典: この記事は Lovable reportedly in talks to double its valuation to $13.2B の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは、業務全般を自律的にこなすAIエージェント「Claude Cowork」を、これまでのデスクトップ専用からモバイルアプリとWebブラウザにも拡大した。ベータ版として提供が始まり、セッションやファイルはAnthropicアカウントに同期されるため、デバイスをまたいで作業を継続できる。同時に公開された利用データからは、Coworkを使う人の大半がプログラミング以外の業務でAIエージェントを活用している実態も明らかになった。 Claude Coworkとは何か Claude Coworkは、コーディングに特化した「Claude Code」とは異なり、スプレッドシートの整理やレポート作成、資料の下書きといった一般的な業務を自律的にこなすことを目的としたAIエージェントだ。指示を受けたAIがバックグラウンドでタスクを実行し続け、人間は必要なタイミングで結果を確認するという設計になっている。 モバイル・Web対応とリモートセッションの仕組み 今回のアップデートの目玉は「リモートセッション」機能だ。これまでCoworkはデスクトップアプリでしか動かせなかったが、ベータ版としてWebブラウザとモバイルアプリからもアクセスできるようになった。ノートPCで開始したタスクをバックグラウンドで走らせたまま、外出先でスマートフォンから進捗を確認したり、アプリを閉じた後も処理が続行されたりする。提供はまずMaxプランから始まり、今後数週間でPro・Team・Enterpriseの各プランにも順次拡大される予定だ。 利用データが明かした「コーディングしない9割」 Anthropicは、2026年5月11日から31日にかけて集めた約120万件の匿名化Coworkセッション（60万以上の組織が対象）を分析した結果も公表した。内訳を見ると、スプレッドシートの突き合わせやオンボーディング資料の作成、散在する進捗情報のレポートへの集約といった「業務プロセスの遂行」が33.4%で最多。次いでドラフト作成・スライド作成・提案書・SNS投稿文などの「コンテンツ作成」が16.4%を占めた一方、ソフトウェア開発はわずか8.7%にとどまった。Anthropicはこれらを「仕事の周辺にある仕事」と表現している。 実務への影響 この結果は、AIエージェントの主戦場がすでにエンジニア組織を超えて営業・管理部門・バックオフィスにまで広がっていることを裏付けている。日本のIT部門にとっては、AIエージェント導入を「開発者向けツール」として狭く捉えていると、実際の需要を取りこぼす可能性がある。Team・Enterpriseプランには管理者向けのSSOやアクセス制御が用意されているため、モバイル同期を許可する前に、どの部門にどの範囲でデータアクセスを許すか、デバイス管理と合わせて設計しておく価値がある。 筆者の見解 今回の利用データは示唆に富む。自律的にタスクをこなすエージェント型AIが評価されるのは、開発者だけでなく、スプレッドシートや資料作成に追われる現場の人たちにこそ効くという証拠だからだ。「確認を求め続けるツール」ではなく「目的を伝えれば自分で進めてくれる仕組み」が支持される流れは、今後さらに強まるはずだ。日本の企業はまだこの変化を「エンジニアのための効率化」程度にしか捉えていないところが多く、もったいないと感じる。バックオフィス業務こそ、仕組み化してAIに任せられる領域が広い。まずは自分たちの「仕事の周辺の仕事」を棚卸しし、どこを自律型エージェントに任せられるか、小さく試してみることをお勧めしたい。 出典: この記事は Anthropic brings Claude Cowork to mobile and web as usage data shows most users aren’t coding の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国企業の間で、DeepSeekやZ.ai（智譜AI）といった中国製の生成AIモデルへの乗り換えが急速に進んでいることが、CNBCの報道で明らかになった。背景にあるのは、OpenAIやAnthropicなど米国主要AIラボによるトークン価格の値上がりだ。開発者向けAIモデル仲介プラットフォーム「OpenRouter」経由の米国企業のトークン利用のうち、中国製モデルが占める比率は今年2月8日以降ずっと週30%を超え、最大で46%に達した。2025年前半の平均はわずか4.5%だったことを踏まえると、この半年での変化は劇的だ。 AIスタートアップLindy、Claudeから全面移行 象徴的な事例が、AIスタートアップLindyだ。同社は6月、Anthropicの「Claude」モデルからDeepSeekへ全トラフィックを移行した。Flo Crivello CEOは「コストカーブが崖から落ちるように下がった」と語り、この切り替えだけで数カ月以内に数百万ドルのコスト削減が見込めるという。DeepSeekは2025年初頭に衝撃的なデビューを飾って以来、着実に採用を広げてきたが、性能面での競争力の高さとコストの安さが評価され、実運用での置き換えが現実のものになりつつある。 Z.aiのGLM 5.2、公開1週間で利用量27倍 6月に公開されたZ.aiの新モデル「GLM 5.2」も急速に採用が進む。アプリのデプロイ基盤を提供するVercelによると、公開後1週間で日次トークン利用量は約27倍、利用企業数は約80倍に急増し、2026年にVercelが追跡した中で最速の普及ペースを記録した。Vercelでagentic infrastructureを率いるHarpreet Arora氏は「価格がすべてを物語っている。最高性能が不要なタスクは、要件を満たす最も安いモデルへ自動的に振り分けられ始めている」と指摘する。 米国政府の規制との綱引きも この流れの背景には、米国政府が自国の最先端AIモデルの流出・拡散を規制しようとする動きもある。6月末にはOpenAIが政府の要請を受けて新モデル群の展開を制限する一方、Anthropicのモデルは政権との緊迫したやり取りの末、輸出規制が解除された。シンクタンクBrookingsのKyle Chan氏は「これまで米国企業はモデルを問わずAI導入を最優先してきたが、いまはコスト意識が強まっている」と分析する。 実務への影響 日本のエンジニアやIT管理者にとっても、この動きは他人事ではない。生成AIエージェントを常時稼働させる「ハーネスループ」的な使い方が広がるほど、トークン消費量は跳ね上がり、コストは無視できない経営指標になる。OpenRouterやVercel AI Gatewayのようなモデルルーティング基盤を使えば、タスクの難易度に応じて呼び出すモデルを動的に切り替える構成が可能になっており、特定ベンダーへの依存を前提にしないアーキテクチャ設計が今後の標準になっていくだろう。 実務での具体的なヒントとしては、(1) モデル呼び出し部分を抽象化レイヤーとして切り出し、モデル差し替えのコストを最小化する、(2) トークン消費とコストを日次でダッシュボード監視する、(3) 簡単なタスクは安価なモデルに、複雑な推論が必要なタスクは高性能モデルにルーティングする、といった設計をあらかじめ組み込んでおくことが挙げられる。ただし中国製モデルは、データの所在地やセキュリティ要件、社内コンプライアンスの観点で採用のハードルが高い組織も多く、金融・官公庁関連システムでは慎重な検討が必要だ。 筆者の見解 今回の件で筆者が注目したいのは、特定モデルの優劣そのものより「コストに応じてモデルを使い分ける仕組みが当たり前になりつつある」という点だ。情報を追いかけて右往左往するより、実際に手を動かして自分の用途に合ったコストパフォーマンスを検証する方がずっと生産的だというのは、AI活用全般に言える筆者の持論と一致する。 中国製モデルの急伸は、性能とコストの両面で選択肢が急速に増えていることの表れであり、企業としては「安いから飛びつく」のでも「知らないベンダーだから排除する」のでもなく、自社のワークフローに合わせて淡々と検証し、必要なら切り替えられる柔軟性を持っておくことが最善策だろう。米国政府の規制の綱引きが示すように、AIモデルの選択はもはや純粋な技術選定の話ではなく、地政学とコストが複雑に絡み合う経営判断になっている。日本の企業もこの変化を「対岸の火事」と見ず、自社のAI活用コストを定点観測する習慣を、今のうちから作っておくべきだ。 出典: この記事は Chinese AI models are gaining ground with U.S. companies as OpenAI, Anthropic costs surge の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは、同社の最上位AIモデル「GPT-5.6」シリーズを一般公開すると発表した。今回のリリースには「GPT-5.6 Sol」「GPT-5.6 Terra」「GPT-5.6 Luna」の3モデルが含まれ、これまで約20社のパートナー企業に限定提供してきたプレビュー版を経て、今週中に世界中のユーザーへ展開される見込みだ。 20社限定プレビューという公開戦略 Bloombergの報道によれば、GPT-5.6シリーズは一般公開に先立ち、約20社のパートナー企業だけに限定的にプレビュー提供されていた。最上位モデルをいきなり全世界に一斉公開するのではなく、まず限られた企業に実際に使わせてフィードバックを集め、そのうえで段階的に展開範囲を広げていくというやり方は、OpenAIにとって比較的新しい公開戦略として位置づけられている。 大規模言語モデルのリリースでは、性能そのものだけでなく、安全性・コスト・インフラのスケーラビリティなど検証すべき項目が非常に多い。限定パートナーへの先行提供には、実運用に近い環境で問題を洗い出しながら、一般提供時の品質を高めておく狙いがあると見られる。 Sol・Terra・Lunaという3モデル構成 Sol・Terra・Lunaという3つの名称が具体的に何を示すかは、現時点では詳細情報が乏しい。ただし、OpenAIがこれまで「miniモデル」「proモデル」のように用途やコストに応じて複数のバリエーションを同時にリリースしてきた経緯を踏まえると、今回も速度・コスト・精度のバランスが異なる複数モデルを揃え、企業側がユースケースに応じて選択できるようにする狙いがあると考えられる。 実務への影響 日本のエンジニアやIT管理者にとって、今回のニュースはいくつかの点で参考になる。 まず、既存のOpenAI API連携を組んでいるシステムでは、モデル名の変更やバージョン移行のタイミングを事前に把握しておく必要がある。新モデルへの切り替えは出力の傾向や挙動が微妙に変わることが多いため、本番投入前にステージング環境での検証を挟むのが安全だ。 また、「限定パートナーへの先行提供 → 段階的な一般公開」というOpenAIのロールアウト手法自体が、社内で新しいAIツールやモデルを導入する際の参考になる。いきなり全社展開するのではなく、一部の部署やチームに先行利用してもらいフィードバックを得てから広げるという進め方は、AI導入のリスクを抑えつつ効果を最大化する定石であり、そのまま自社のAI活用フローに応用できる考え方だ。 筆者の見解 OpenAIが最上位モデルの展開すら段階的に行うようになったのは、単なるマーケティング施策というより、大規模モデルの品質担保が年々シビアになっていることの表れだと見ている。派手な一斉公開よりも、実運用に近い環境で鍛えてから世に出す姿勢は健全なやり方だと思う。 正直なところ、筆者自身は日々の実務のほとんどをClaude Codeで回しており、OpenAIの新モデルを逐一追いかける余裕は持てていない。とはいえ、それはOpenAIの実力を軽視しているわけではなく、むしろ次々と新しいモデルを送り出してくるスピード感は素直にすごいと感じている。 大事なのは「どのベンダーのモデルが最新か」を追い続けることではなく、今手元にあるツールを実際に使い倒して成果を出す経験を積むことだ。GPT-5.6シリーズが一般公開された後、実務でどう評価されていくかは注視しつつ、まずは自分が使い込んでいるツールで結果を出すことを優先したい。 出典: この記事は OpenAI to Roll Out Top AI Model Globally After Limited Preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAは2026年7月6日（現地時間）、次世代AIラックシステム「Kyber NVL144」の投入時期に関する遅延報道を公式に否定した。半導体分析会社SemiAnalysisが同月5〜6日に報じたところによると、Kyber NVL144は基板部品の製造上の問題により、当初予定の2027年から2028年へと投入時期がずれ込む可能性があるという。これに対しNVIDIAの広報担当者はBloombergの取材に「当社のロードマップは維持されている」と回答し、Rubinおよびその後継チップの投入計画に変更はないと強調した。 何が報じられたのか SemiAnalysisのレポートが指摘したのは、単体の新型GPUではなく「Kyber NVL144」というラックスケールのAIシステムだ。1台のキャビネットに144基の「Rubin Ultra」GPUを搭載し、単一の巨大な計算基盤として動作させる設計で、Microsoft、Google、Meta、Amazonといったハイパースケーラー向けの投入が想定されている。レポートによれば、この高密度実装に不可欠な回路基板部品の製造上の課題が原因で、量産開始が2027年から2028年にずれ込むとされた。 NVIDIAの反論とロードマップの位置づけ NVIDIAはBlackwell世代の後継として、年次に近いペースでHopper→Blackwell→Rubin→Rubin Ultraと新世代プロセッサを投入するロードマップを公表してきた。KyberはそのうちRubin Ultra世代をラックスケールで実装する製品にあたり、生成AIの学習・推論インフラを支える中核として位置づけられている。今回NVIDIAは「ロードマップは完全に維持されている」との立場を崩さず、市場でもJim Cramer氏が「押し目買い」を勧めるなど、公式否定を好感する反応が見られた。株価も週明けの取引で約1%上昇している。 一方で、延期報道の火種となった「基板部品の製造上の問題」自体をNVIDIAが明確に否定したわけではない点には注意が必要だ。あくまで「ロードマップ全体としては維持される」という表明であり、個別コンポーネントの調整余地は残されている可能性がある。 実務への影響 日本のIT管理者にとって、この種のニュースは対岸の火事ではない。Azure OpenAI ServiceやAzure AI Foundryを含む主要クラウドのAI基盤は、NVIDIAのGPU供給計画に直接依存しているからだ。GPUの投入時期が前後すれば、クラウド側のGPU割り当て枠（クォータ）や新型インスタンスの提供開始時期にも波及しうる。 実務上のポイントは、個別の延期報道や公式否定に一喜一憂しないことだ。むしろ自社が利用するクラウドベンダーの公式アナウンス（Azure Updatesなど）を定点観測し、大規模なファインチューニングや推論基盤の構築計画では、GPU調達に多少のバッファを見込んでスケジュールを組んでおくのが賢明だろう。 筆者の見解 チップの投入時期をめぐる「延期報道 対 公式否定」の応酬は、今後も繰り返されるはずだ。個人的には、こうしたヘッドライン合戦に一喜一憂するよりも、今すでに使えるAIをいかに実務で使い倒すかに時間を割く方がよほど生産的だと考えている。NVIDIAのロードマップが多少前後したところで、AI計算資源が中長期的に拡大し続けるという大きな流れは変わらない。 一方で、Microsoftを含むハイパースケーラーにとって、GPU供給の安定性はAzure上のAIサービス品質に直結する死活問題だ。Azureを軸に仕事をしている読者は多いと思うが、応援する立場から言えば、Microsoftにはこうした供給網リスクを早めに開示し、顧客が計画を立てやすい形で情報提供を続けてほしい。派手なロードマップ発表よりも、地に足のついた供給計画の透明性こそが、いまのAIインフラ競争で信頼を勝ち取る近道のはずだ。 出典: この記事は Nvidia Reaffirms AI Chip Roadmap, Rejects Delay Reports の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google傘下のGoogle DeepMindが、次世代の主力モデル「Gemini 3.5 Pro」の正式リリースを、当初予定より遅らせて2026年7月17日に設定し直したことが明らかになった。単なる日程調整ではなく、ベースとして使う予定だった「Gemini 2.5 Pro」由来のアーキテクチャを完全に破棄し、「Gemini 3」系列のネイティブな基盤から事前学習をやり直すという、フロンティアモデル開発としては異例の判断だ。 Google I/Oでの予告から一転、土壇場での差し戻し Sundar Pichai CEOはGoogle I/Oの基調講演で、Gemini 3.5 Proを「翌月にはリリースする」と予告していた。ところが関係者によると、DeepMindは投入予定日の数日前になって既存の2.5 Proベースレイヤーを本番パイプラインから引き上げ、Gemini 3のネイティブ基盤による大規模な追加事前学習に切り替えたという。OpenAIの「GPT-5.6 Sol」やAnthropicの「Claude Fable 5」が存在感を増す中、小手先のマイナーアップデートではもはや競争優位を保てないという判断が背景にあるとみられる。 なぜ土台から作り直すのか 理由は大きく二つ語られている。一つは「Pro-to-Flashパラドックス」だ。先行リリースされた軽量版「Gemini 3.5 Flash」が、旧世代の上位モデル「Gemini 3.1 Pro」をTerminal-Bench 2.1で上回る（76.2%）という逆転現象が起きてしまった。この状態のまま旧アーキテクチャの3.5 Proを出しても、価格差に見合う性能差をエンタープライズ顧客に示せず、高単価な上位ティアの存在意義そのものが揺らぐ。 もう一つは推論力そのものの壁だ。リークされた社内評価によれば、複雑で再帰的なツール呼び出しが絡む環境下で、多段階の数学推論やSVGによる複雑なレイアウト生成において構造的な一貫性を保てなかったという。テキスト処理は問題なくこなせても、競合モデルがすでに達成している安定性には届いていなかった。見劣りする状態のまま世に出すより、短期的なPR上のダメージを飲み込んでも基盤から作り直す方を選んだ格好だ。 実務への影響 ― 日本のエンジニア・IT管理者にとっての意味 Proフラグシップが不在の間も、軽量版のGemini 3.5 Flashは1Mトークンあたり入力$1.50／出力$9.00という価格で提供が続く。高頻度・大量呼び出しが必要なエージェントパイプラインは、当面このFlashで組んでおくのが現実的だ。逆に、複雑な数学的推論や込み入ったレイアウト生成が絡む用途は、7月17日のPro正式版を待ってから設計に組み込んだほうが手戻りが少ない。 また、「軽量モデルが上位モデルの性能を食ってしまう」という現象は、Google固有の話ではなく、モデル選定全般に共通するリスクだ。カタログ上のスペックやベンチマークの序列だけでツールチェーンを固定せず、実タスクでの検証結果をもとにモデルを選ぶ姿勢が、今後ますます重要になる。未リリースのモデルを前提にロードマップを組んでいるチームは、代替経路を必ず用意しておきたい。 筆者の見解 今回の延期劇は、フロンティアAI各社の競争が「ベンチマークの数字」から「実タスクでの安定性」の勝負に移っていることを象徴している。見劣りする状態のモデルをスケジュール通りに出すのではなく、土台から作り直す方を選んだこと自体は、誠実な判断だと思う。 一方で筆者は、こうした「今どのモデルが強いか」を逐一追いかける情報収集にはあまり価値を感じていない。数週間単位でランキングが入れ替わる世界で情報を追い続けるより、手元のツール（筆者の場合はClaude Code）を軸に実際に手を動かし、成果を積み上げるほうが費用対効果は高い。Googleは画像生成など強い領域を持っている一方、実務の中心に据えるかどうかは話題性ではなく、自分の現場での検証結果で決めるべきだ。 もう一点、今回の背景にある「軽量モデルが上位モデルを食う」現象は他人事ではない。単発のモデル評価スコアだけでなく、エージェントが自律的に判断・実行・検証を繰り返す「ハーネスループ」の中でどのモデルが安定して動き続けるかを見極めることこそ、これからのエージェント基盤設計における本質的な論点になっていくはずだ。 出典: この記事は Google Delays Gemini 3.5 Pro Launch to July 17 for Full Architectural Rebuild の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは2026年7月6日、音声対話やマルチモーダル体験を構築するための「Realtime API」向けに、新モデル「gpt-realtime-2.1」と、その低コスト版「gpt-realtime-2.1-mini」を公開した。両モデルとも、キャッシュ機構の改善によってp95レイテンシ（応答時間の95パーセンタイル値）を25%以上削減したほか、雑音への耐性、英数字の聞き取り精度、ユーザーが話に割り込んだ際の応答挙動を改善している。 Realtime APIとは何か Realtime APIは、音声をテキストに変換せず音声のまま入出力する「Speech-to-Speech」型の低遅延対話APIだ。WebSocketなどでクライアントとモデルを直結し、コールセンターの自動応答、音声アシスタント、リアルタイム翻訳といった「人と話す」体験の基盤として使われている。今回のアップデートは、この音声対話の土台部分の改善にあたる。 何が変わったのか 上位モデルの「gpt-realtime-2.1」は、前世代の「GPT-Realtime-2」をベースに、型番・注文番号・住所読み上げなど英数字混じりの聞き取り精度、無音・雑音時の挙動、ユーザーが発話中に割り込んだ際の応答を改善した。推論の強度（reasoning effort）を設定できるほか、指示追従やツール呼び出しにも対応しており、複雑な音声エージェントのワークフローを組める。 一方の「gpt-realtime-2.1-mini」は、推論・ツール利用機能を備えながら、より高速・低コストに使える軽量版だ。特筆すべきは、従来のminiモデルと同水準の価格を維持しつつ機能を底上げしている点で、コストを据え置いたまま性能向上の恩恵を受けられる。 価格は次の通り（100万トークンあたり、単位はドル）。 モデル テキスト入力 テキスト入力(キャッシュ) テキスト出力 音声入力 音声入力(キャッシュ) 音声出力 gpt-realtime-2.1 4.00 0.40 24.00 32.00 0.40 64.00 gpt-realtime-2.1-mini 0.60 0.06 2.40 10.00 0.30 20.00 コミュニティは「差は小さい」との指摘も OpenAIのコミュニティフォーラムでは早速検証も始まっている。あるユーザーは、知識カットオフ（2024年9月30日）、価格、レイテンシ、コンテキストウィンドウが旧「GPT-Realtime-2」とほぼ同一に見え、「現時点で大きな違いは感じられない」と指摘した。また公式のRealtime Playground（platform.openai.com/audio/realtime/edit）が、2.1が使えるようになった後もデフォルトでは旧モデルのままになっている点も報告されている。発表文の謳い文句をそのまま受け取らず、自分の用途で実測して効果を見極める姿勢が重要だ。 実務への影響 日本ではコールセンターやIVR（音声自動応答）に音声AIを組み込む動きがようやく広がり始めた段階の企業も多い。レイテンシ25%減は、音声対話における「間」の自然さに直結し、ユーザー体験の改善に直接効いてくる部分だ。またminiモデルが推論・ツール呼び出しに対応しつつ旧miniと同価格を維持している点は、コストを増やさずに機能を強化できるという意味で、導入のハードルを下げてくれる。 注意点として、現時点でAzure OpenAI Service経由での提供有無は明らかになっていない。エンタープライズ利用でAzure経由の調達を前提にしている場合は、Azure側での提供開始時期を注視しておきたい。乗り換えの際は、フォーラムで指摘されているような「実際のところどこまで変わったか」を、自社のトラフィックで計測してから切り替えるのが手堅い進め方だろう。 筆者の見解 音声インターフェースは、AIエージェントが人間の負担を減らす窓口として、今後さらに重みを増す領域だと見ている。画面を見て操作するという前提を外し、話しかけるだけでタスクが完結する体験は、目的を伝えれば自律的に動くタイプのエージェントとの相性が良い。レイテンシ25%減という数字は地味に映るかもしれないが、音声対話は「間」が不自然なだけで一気に興ざめする性質のものなので、体感としてはかなり本質的な改善のはずだ。 とはいえ、フォーラムで指摘されているように、見出しほど旧モデルとの差が大きくないという冷静な声も出ている。新しいモデル名が出るたびに飛びつくのではなく、自分のワークロードで実際に計測してから判断するほうが、結局のところ一番の近道だ。情報を追いかけることに時間を使うより、手元で試して成果につなげる経験を積むほうが今は正しい。 日本ではコールセンターや窓口業務の音声AI活用がこれからという現場もまだ多い。miniモデルが機能を落とさず低価格を維持しているのは、そうした現場が最初の一歩を踏み出す後押しになるはずだ。 出典: この記事は New Realtime models on the API: gpt-realtime-2.1 and gpt-realtime-2.1-mini の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleの「Chrome」ブラウザが、ユーザーの同意を得ないまま4GBのAIモデル「Gemini Nano」をPCに自動インストールしていたことが、スウェーデンのプライバシー研究者Alexander Hanff氏の調査で明らかになった。しかも手動で削除しても、Chromeを再起動すると再びダウンロードされるという厄介な仕様まで確認されている。 何が起きたのか Chromeのユーザーデータフォルダ内には「OptGuideOnDeviceModel」という名前のフォルダが存在し、その中にweights.binというモデル重みファイルが置かれている。これがGoogleのオンデバイスAI「Gemini Nano」の実体だ。フォルダ名からは何のファイルか一般ユーザーには判別できず、Hanff氏はこの命名自体が意図的な曖昧化だと指摘している（正直に名付けるなら「GeminiNanoLLM」とすべきだったはずだ、と）。 ChromeはGPU性能・CPUコア数・システムメモリ（16GB以上）・空きストレージ（22GB以上）といったハードウェア要件を自動チェックし、条件を満たす端末には通知なしでバックグラウンドダウンロードを開始する。Hanff氏のテストではダウンロード完了までわずか14分だったという。さらに厄介なのは、手動削除してもChromeが「一時的なエラー」と判断し、次の起動時に再ダウンロードしてしまう点だ。旧バージョンの残骸が消えずに蓄積し、合計12GB超に膨れ上がったケースも報告されている。ファクトチェックメディアSnopesが自社スタッフ6名の端末を調査したところ、macOSとWindowsを合わせて3名の端末でこのファイルが見つかった。 Googleは「2024年から提供しているオンデバイスモデル」と説明し、2026年2月以降は設定画面に「オンデバイスAI」のオン/オフトグルを順次追加しているとするが、Hanff氏を含む多くのユーザーにはまだこのトグルが届いておらず、chrome://flagsやレジストリを直接編集しない限り無効化できない状態が続いている。 「プライバシー保護」という名の矛盾 この一件が象徴的なのは、Googleの正当化ロジックだ。Gemini Nanoが担うのは「Help Me Write」やタブグループ提案、ページ要約、そしてフィッシング検知などの機能で、特にフィッシング検知は2025年5月にChromeの「保護強化モード」に統合され、存在時間10分未満で消える悪質サイトさえリアルタイムで検出できるとされる。処理をクラウドではなく端末内で完結させるため「データがGoogleに送信されずプライバシーが守られる」というのがGoogleの説明だ。 しかし、その「プライバシーを守るための機能」自体が、ユーザーの同意なしに、しかも紛らわしい名前でインストールされていたという事実は皮肉としか言いようがない。処理場所がローカルであることと、インストールの透明性・同意の有無は、まったく別の話である。 実務への影響 日本のIT管理者にとって、まず確認すべきはストレージ影響だ。ストレージ容量が限られたVDI環境やシンクライアント、キッティング済みの標準PCでは、通知なく数GBが消費される事態は無視できない。Chrome Enterpriseのグループポリシー（ADMX）でオンデバイスAI関連の機能を制御できるかどうかを確認し、まだ管理ポリシーが提供されていない環境ではchrome://flagsやレジストリでの一律制御を検討すべきだろう。 また、企業のセキュリティ・プライバシー部門にとっては、ソフトウェアが「同意なくバックグラウンドで大容量ファイルをダウンロードし、削除しても復元する」という挙動自体が、資産管理・変更管理の観点でリスクとなる。ベンダー製品のアップデートポリシーやEULAに、こうした「暗黙の機能追加」がどこまで含まれるかを改めて棚卸しする良い機会でもある。 筆者の見解 オンデバイスAIという方向性自体は理にかなっている。処理をローカルで完結させることで遅延も減り、機微なデータをクラウドに送らずに済む。技術的な狙いは正しい。 ただし今回の問題の本質は「AIを使うかどうか」ではなく「どう届けるか」だ。禁止するのではなく、ユーザーが安心して使える仕組みを作ることが本来あるべき姿のはずで、それには透明な説明と明確な同意が欠かせない。フォルダ名を曖昧にし、削除しても復活させるという挙動は、便利な機能を「気づかれないように」押し付けているようにしか見えず、結果的にユーザーの信頼を損なう。どれだけ機能が優れていても、届け方を誤れば「勝手に入れられた」という不信感だけが残ってしまう。 WindowsでもCopilotの機能拡張やRecallのような機能で似た構図の反発が起きたことは記憶に新しい。プラットフォームベンダーがOS・ブラウザレベルでAIを組み込んでいく流れは今後も続くはずだが、後から「実はこっそり入っていた」と発覚する形ではなく、最初から選択肢として提示し、ユーザー自身が納得して有効化する仕組みを標準にしてほしい。それが結局、AI活用を前向きに広げていく一番の近道だと思う。 出典: この記事は Google Chrome Installed a 4GB AI Model on Your PC の内容をもとに、筆者の見解を加えて独自に執筆したものです。