Generative-Ai

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

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は7月、次期フラッグシップモデル「GPT-5.6 Sol」を、AI半導体スタートアップのCerebras Systems製ウェハースケールチップ上で稼働開始すると明らかにした。想定される出力速度は毎秒750トークン。一般的なGPUクラスタでの応答生成速度（毎秒40〜120トークン程度）と比べておよそ10倍に達する見込みだ。まずは限定的な顧客からの提供となり、Cerebras側の供給能力拡大に応じて対象を広げていく計画という。 ウェハースケール推論という力技 Cerebrasの最大の特徴は、通常のチップのようにシリコンウェハーを切り分けて使うのではなく、ウェハー1枚をまるごと1つの巨大な演算チップとして使う「ウェハースケールエンジン」にある。モデルの重みをオンチップのメモリに載せたまま処理できるため、GPUクラスタで発生しがちなメモリ帯域のボトルネックを回避しやすい。これが毎秒750トークンという桁違いの数字につながっている。 なお今回のCerebras展開は、6月29日に発表されたBroadcom製推論チップ「Jalapeño」とは別ルートだ。OpenAIは同じGPT-5.6 Solを、性格の異なる2種類のカスタムシリコン上で並行して走らせるという、いわば「二正面作戦」を取っている。特定ベンダーへの依存リスクを避けつつ、速度と供給量の両方を確保する狙いが透けて見える。 200億ドル契約とCerebrasのIPO 背景にあるのが、OpenAIとCerebrasの間で以前から明らかになっていた総額200億ドル超・750メガワット規模の複数年推論契約だ。Cerebrasは今年に入りIPO申請も行っており、廉価版の「Terra」や「Luna」ではなく最上位モデルのSolを最初にCerebras上で稼働させるという判断は、上場を控えたCerebrasへのOpenAIからの「お墨付き」としての意味合いも強い。価格はまだ公表されていないが、Sol自体のAPI料金がすでに入力100万トークンあたり5ドル・出力30ドルとされており、高速版はこれより高い価格帯になる可能性が高い。 実務への影響 これまでLLMの性能評価は精度やコンテキスト長が主戦場だったが、ここへきて「レイテンシ」そのものが単独の商品価値として売られ始めている。エンジニアやIT管理者にとって重要なのは、ベンチマークの数字を眺めることではなく、自分たちの実際のワークフローでエンドツーエンドのトークン/秒を計測する習慣を持つことだ。毎秒90トークンと750トークンの差は、単なる速度比較ではない。コーディングエージェントが4000トークンのプルリクエストを6秒で作るか、1分かけて作るかの違いであり、それはエージェントを対話ループの中でリアルタイムに使えるか、一晩バッチで回すしかないかという、ワークフロー設計そのものを左右する差になる。日本企業がAIエージェント導入を検討する際も、精度だけでなく「どれだけ低遅延で回せるか」を評価軸に加えるべきだろう。 筆者の見解 このニュースの本質は、OpenAIとCerebrasの契約金額の大きさよりも、推論速度そのものが競争軸になってきたという点にある。AIエージェントの価値は、人間の認知負荷をどれだけ減らせるかで決まる。逐一確認を求めながらゆっくり動くAIと、目的さえ伝えれば自律的にループを回して結果を返してくるAIとでは、体験としてまったく別物だ。そして自律的なループを気持ちよく回すには、応答速度がボトルネックにならないことが前提になる。その意味で、今回のCerebras採用やBroadcomとの二正面展開は、モデルの賢さの競争だけでなく「エージェントを止めない速度」の競争がいよいよ本格化した合図だと見ている。 日本のエンジニアにとっての教訓はシンプルだ。ベンダー各社の速度競争をニュースとして追いかけるだけでは何も変わらない。自分の手元のエージェントワークフローで実際にトークン/秒を測り、速度が上がったときにどこまで自律実行の範囲を広げられるかを、手を動かして試す。情報を追うより、実際に使って成果を出す経験を積むことが、今この分野で最も価値のある投資だと思う。 出典: この記事は OpenAI to run GPT-5.6 Sol on Cerebras at 750 tokens per second in July の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年8月にも、米ニューメキシコ州のSceye（スカイ）社が開発した全長約60メートルの太陽光駆動飛行船が日本の沿岸上空約18キロメートルの成層圏に展開し、SoftBankの5Gネットワークを補完する通信テストを実施する。端末への直接データ送信も含まれるこのテストは、HAPS（高高度プラットフォームシステム）技術の実用化に向けた重要な節目となる。 HAPSとは——地上基地局でも衛星でもない第3の選択肢 通信インフラには大きく分けて、地上の基地局と宇宙の衛星という2つのアプローチがある。HAPSはその中間、高度約18〜20キロメートルの成層圏に「準静止」する飛行体を使った第3の選択肢だ。 成層圏は気象の影響をほぼ受けず、風も比較的安定している。低軌道衛星（LEO）は最低軌道でも地表から約200キロメートル離れているが、HAPSはその10分の1以下の距離にある。信号の遅延が小さく送信に必要な電力も少ない。SceyeのCEO、ミッケル・フェスタガール・フランセン氏は「宇宙のような環境を、宇宙に行くコストなしで、軌道にいる複雑さなしで提供できる」と表現する。 Sceye飛行船の技術的なポイント Sceye機はヘリウムで浮力を得る飛行船型で、外皮には軽量かつ反射性の高い特殊ファブリックを採用。太陽光パネルで昼間に発電し、夜間用に電力を蓄積することで24時間稼働する電動ファンを駆動し、風に押されても定位置に戻る「ステーションキーピング」を実現する。2024年のテストフライトでこの能力を実証済みで、2026年春には南米ブラジル沖への飛行で12日間の滞空と合計88時間以上の定点停滞を達成した。 Airbus傘下のAaltoなど複数の企業もHAPS開発を進めており、災害時の通信確保や地表監視など多目的な活用が構想されている。 SoftBankとの日本テスト——何を検証するのか 今回のテストでは、Sceye機が日本の沿岸上空に展開し、専用アンテナでSoftBankの5Gを補完する。注目すべきは「既存デバイスへの直接データ送信」が含まれる点だ。専用の受信端末を必要とせず、手持ちのスマートフォンへの送信が実現すれば、展開コストが大きく下がる可能性がある。将来的には衛星事業者と連携して、基地局整備が難しい離島・山間部・洋上エリアをカバーする役割も期待されている。 実務への影響——インフラ担当者が今から意識すべきこと 災害対策BCP: 地震・台風で地上インフラが壊滅してもHAPSが成層圏に残れば通信を維持できる。自治体・企業のBCP計画に「成層圏通信」を選択肢として加える議論が現実味を帯びてくる。 農業・物流・海洋分野: 離島や沿岸の広域IoTセンサー、船舶通信、農業用ドローンの制御など、これまで衛星しか選択肢のなかった用途でコスト低減が期待できる。 都市部の容量補完: 大規模イベントや災害時の高密度エリアで一時的なキャパシティ増強に使える可能性もある。 ただし、現時点はテスト段階だ。商用展開に向けたコスト構造・航空規制・運用オペレーションには未解決の課題が多い。中長期のインフラロードマップに「選択肢として存在する」と意識する段階であり、今すぐ発注できる技術ではない。 筆者の見解 地上基地局・低軌道衛星・HAPSと、通信インフラのレイヤーが増えていくのは、全体最適を考えると理にかなった方向性だと思う。どれか一つで全てを解決しようとするのではなく、用途・地域・コストに合わせてレイヤーを使い分ける設計が、結果的に堅牢で経済合理性の高いシステムを生む。 日本は地震・台風と向き合い続ける国であり、基幹通信が止まるリスクは常に存在する。成層圏に常駐できる通信プラットフォームは、レジリエンスという観点で非常に魅力的な選択肢になりうる。特にSoftBankのような大手キャリアがテストパートナーになっているという事実は、単なる研究段階を超えて商用化の道筋を探り始めているサインとして受け取るべきだろう。 今回のテストが成功すれば、国内での実証例として業界全体の議論を加速させるはずだ。「空からの通信」が絵空事ではなくなりつつある現実を、インフラ関係者は今から頭に入れておいてほしい。 出典: この記事は This flying solar-powered platform could deliver better internet from the air の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude CodeやCodex、GitHub Copilot CLIなど主要AIコーディングエージェントに対応したプラグイン「Ponytail」が、「怠惰なシニア開発者の哲学」をエージェントに注入することで、生成コード量を最大94%削減・処理速度3〜6倍・APIコスト最大77%削減を達成したと報告している。 「過剰実装」はAIエージェントの本能的な罠 AIエージェントにコードを書かせると、しばしば過剰な実装が生まれる。日付ピッカーを頼んだだけなのに、flatpickrをインストールし、ラッパーコンポーネントを書き、スタイルシートを追加し、タイムゾーン対応の議論まで始める。ブラウザには最初から <input type="date"> があるのに、だ。 Ponytailはこの問題に正面から向き合うプラグインだ。コードを書く前に、以下の順序でチェックを強制する： そもそも必要か？ → 不要なら作らない（YAGNI） 標準ライブラリで解決できるか？ → 使う プラットフォームのネイティブ機能で解決できるか？ → 使う インストール済みの依存関係で解決できるか？ → 使う 1行で書けるか？ → 1行にする それでもダメなら：動く最小限を書く このルールセットをセッションごとに自動注入することで、「経験あるエンジニアなら一瞬で見抜く不要なコード」を事前に刈り取る設計だ。 計測結果：3モデル・5タスク・各10回の中央値 計測はHaiku・Sonnet・Opusの3モデルで実施。「メールバリデーター」「デバウンス」「CSV集計」「カウントダウンタイマー」「レートリミッター」の5タスク、各10回の中央値を報告している。 指標 削減効果 コード行数 80〜94%削減 レスポンス速度 3〜6倍高速化 APIコスト 47〜77%削減 重要な設計方針として「怠惰であって、杜撰ではない（Lazy, not negligent）」が掲げられている。信頼境界のバリデーション・データロス対応・セキュリティ・アクセシビリティはショートカットの対象外だ。また、各ショートカット箇所にはコード内に ponytail: コメントでアップグレードパスが明示されるため、後から本番対応へ拡張する際の道筋も残される。 ベンチマークは npx promptfoo eval -c benchmarks/promptfooconfig.yaml で自分でも再現できるよう公開されている。 対応AIエージェント・ツール Ponytailは以下に対応している： ツール インストール方法 Claude Code /plugin marketplace add DietrichGebert/ponytail OpenAI Codex codex plugin marketplace add DietrichGebert/ponytail GitHub Copilot CLI copilot plugin marketplace add DietrichGebert/ponytail Gemini CLI gemini extensions install https://github.com/DietrichGebert/ponytail Pi agent harness pi install git:github.com/DietrichGebert/ponytail Cursor / Windsurf / Cline / Aider / Kiro ルールファイルを手動コピー Claude CodeとCodexのプラグインはNode.jsのライフサイクルフックで動作するため、node がPATHに入っている必要がある（Nix/nvm環境では非対話シェルのPATHに注意）。 ...

MicrosoftのGitHub Copilotが2026年6月1日より課金体系を定額制からトークン使用量ベースの従量課金制へ移行し、RedditやX（旧Twitter）で開発者の間に「What a joke（冗談じゃない）」という声が広がっている。 何が変わったのか——定額制からトークン課金制へ これまでGitHub Copilotは月額定額制で提供されており、開発者はコストを気にせずAIとのやり取りを重ねることができた。しかし6月1日付けの新プランでは、消費したトークン量に応じて料金が発生する従量課金制へと移行した。 トークン課金制とは、AIとのやり取り（入力・出力のテキスト量）を「トークン」という単位で計測し、その消費量に比例して課金する仕組みだ。シンプルなコード補完では影響は小さいが、長時間稼働させるエージェントタスクや、複数のサブエージェントが連携して動く複雑な処理では、コストが一気に膨らむ可能性がある。 「冗談だろ」——開発者コミュニティの反応 課金モデルの変更を受け、開発者コミュニティから悲鳴に近い声が上がっている。 あるRedditユーザーは、現在の月額29ドルが新レートでは約750ドルに跳ね上がると主張し、「この新しい使用量モデルは馬鹿げた値段だ。この費用では実用的でも費用対効果があるわけでもない。キャンセルして調整する」と投稿した。 別のユーザーは月額50ドルから約3,000ドルへの急騰を示すスクリーンショットを添えて「新しい料金モデルがこんなに常軌を逸したものになるとは思っていなかった」と発信した。 擁護派の反論——「ヴァイブコーダー問題」 一方で、批判に反論する声も存在する。擁護派の開発者たちが指摘するのは「ヴァイブコーディング」問題だ。 ヴァイブコーディングとは、コードの詳細を理解せず、AIに任せきりで大量のトークンを消費しながら試行錯誤を繰り返すスタイルを指す。擁護派は「一日中作業しても超過分がほとんど出ない開発者もいる。コストが膨らむのは、純粋に膨大なイテレーションでヴァイブコーディングをしているからだ」と主張する。 つまり、AIを適切な道具として使う開発者には、新課金体系は必ずしも壊滅的ではないという見方だ。問題は使い方の習熟度にある、という論点である。 「使えと言ったのはMicrosoftでは？」——最も鋭い批判 しかし最も根本的な批判は別の角度から来ている。「Microsoftがユーザーに積極的な使用を促しておきながら、課金体系を変えて梯子を外した」というものだ。 あるユーザーはこう指摘する。「Microsoftがこの課金方式を提供し、何時間も、場合によっては何日もかけて大量のサブエージェントを生成するプレミアムリクエストをどんどん実行しやすくし続けてきた。その使い方でシステムを使ったユーザーを責めるのはおかしい。責任があるとすれば、それはMicrosoftだけだ」 加えて、以前の定額モデルでMicrosoftがどれほどの損失を出していたかも話題になった。「Copilotはどれほどの赤字だったんだ」というコメントが多くの共感を呼んでいる。 Microsoftにはコメントを求めたが、執筆時点で回答はなかった。 実務への影響——日本の開発者・IT管理者が取るべき対応 コスト予測の仕組みを整える: トークン課金制では月額コストが使い方によって大きく変動する。チームでCopilotを活用している場合、上限設定や使用量モニタリングの仕組みを早急に整える必要がある。 エージェント利用は特に注意: 長時間稼働するエージェントタスクや、複数のサブエージェントが連携して動く処理はトークン消費量が桁違いに大きい。エージェントモードの活用を検討しているチームは、事前にコストシミュレーションを行うことを強く推奨する。 「適切な使い方」の社内定義が急務: 今回の問題の一因は「適切な使い方の共有不足」にある。AIコーディング支援ツールを組織として使いこなすためには、効果的な活用パターンと非効率なパターンを明文化し、チームで共有することが重要だ。 筆者の見解 今回のGitHub Copilotの課金体系変更は、単純な値上げの話ではない。「AIをどう使わせるか」というMicrosoftの設計哲学そのものへの問い直しを迫る出来事だ。 もったいないと感じるのは、Copilotが技術的な進化の方向性——エージェント機能の拡充、サブエージェントの生成、自律的なタスク実行——という意味では、確実に正しい道を歩んでいるからだ。AIが本来提供すべき価値、すなわち人間の認知負荷を削減して仕事を自律的に推進する能力に、少しずつ近づいてはいる。 しかし、「使えば使うほどコストが読めなくなる」料金設計は、そのポテンシャルを自ら封じてしまう。これまでMicrosoftは「もっと使え」とユーザーに言い続けてきた。その言葉に素直に従い、エージェントモードをフル活用したユーザーに高額請求が届くのであれば、失望するのは当然だ。 MicrosoftにはCopilotを真に使い物になるツールへと育てる力がある、というのが筆者の長年の認識だ。課金体系の整備と合わせ、「積極的に使っても怖くない」という安心感をユーザーに取り戻す設計を期待したい。Copilotが「使われることを恐れるAI」ではなく「使い倒されることで価値を発揮するAI」として再評価される日が来ることを願っている。 出典: この記事は ‘What a joke’: Github Copilot’s new token-based billing spurs consternation among devs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Salesforceは2026年5月22日、CRMの検索インターフェースに直接AIチームメイトを組み込む新機能「Agentforce Coworker」のベータ提供を開始した。これまで別画面に切り替えて操作していたAIエージェント機能を、日常的に使うCRM検索の起点に統合することで、営業・サポート担当者の業務フローを根本から変えようとする試みだ。 Agentforce Coworkerとは何か Agentforce CoworkerはSalesforceのCRMプラットフォーム上に常駐するAIアシスタントで、検索バーから自然言語でエージェントに指示を出すだけで、関連する顧客情報や商談履歴などのコンテキストを自律的に取得し、そのままアクション（メール送信・商談更新・タスク作成など）まで実行できる。 従来のAI活用では「AIに聞く→結果を自分でCRMに反映する」という二段階の手間が残っていた。Coworkerはこの「最後の一歩」を埋める設計になっており、検索→理解→実行を単一インターフェースで完結させる点が最大の特徴だ。 Spring ‘26管理者認定資格の改訂も同時実施 SalesforceはAgentforce Coworkerのリリースと同時に、Spring ‘26 Salesforce管理者認定資格を改訂した。エンタープライズ向けのAIエージェント展開に対応する知識・スキルが試験範囲に加わっており、単なる機能追加にとどまらず「管理者がAIエージェントを責任を持って運用できる体制」を整備する意図が読み取れる。資格改訂は本格的な企業展開を視野に入れた布石と見るのが自然だろう。 なぜこれが重要か Agentforce Coworkerが注目される理由は、AIエージェントの「埋め込み」アプローチにある。これまでのAIツールは「別タブで開くAIチャット」という形態が主流だったが、ユーザーは日常的に使うアプリを離れたくない。CRMを開いたままAIエージェントに仕事をさせられるという体験は、現場での採用率を大きく左右する。 日本国内でSalesforceを導入している企業は大企業・中堅企業を中心に相当数ある。営業DXの軸としてSalesforceを使っている組織であれば、Agentforce Coworkerは追加ツールを導入せずに自律エージェント機能を得られる選択肢となる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 Salesforce管理者・開発者向け: Spring ‘26認定資格の改訂内容を早めにキャッチアップしておくこと。エージェントの設定・権限管理・監査ログの扱いが今後の管理者の必須スキルになる Agentforce Coworkerが実行できるアクションの範囲とガバナンス設定を把握し、誤作動・意図しない更新を防ぐ設計を先に考えておく IT管理者・CIOレベル向け: AIエージェントがCRMデータに直接アクセスしてアクションを実行するため、データアクセス権限の見直しが急務。エージェント経由の操作も監査対象に含まれるかを確認する 現場担当者が「AIが勝手に商談を更新した」と混乱しないよう、展開前のユーザートレーニングとエスカレーションフローの整備が必要 ベータ期間中に少数のパイロットユーザーで運用し、プロンプトの傾向・よく使うアクション・エラーパターンを把握してから全社展開するのが現実的なアプローチ アーキテクト・開発者向け: AgentforceはSalesforce Flow・Apex・外部API連携と組み合わせることでアクション範囲を拡張できる。既存のFlowをエージェントのアクションとして登録する設計パターンを今のうちに検討しておく価値がある 筆者の見解 SalesforceのAgentforce Coworkerが示しているのは、AIエージェントの主戦場が「専用ツール」から「既存業務システムへの統合」へ移行しつつあるという流れだ。検索という最も自然な入口にエージェントを置くアプローチは理にかなっており、ユーザーに新しいUIを覚えさせずに自律実行の恩恵を届けようとする設計姿勢は評価できる。 ただし、「エージェントが実際にアクションを実行する」という点では、承認フローをどう設計するかが現場定着の鍵を握る。確認・承認を毎回人間に求め続ける設計では自律エージェントの本来の価値が削がれる一方、完全自律にするとデータ品質や誤操作のリスクが出る。この塩梅をどう取るかは、各企業の業務プロセスとリスク許容度によって変わる。ベータ期間に得られるフィードバックがここに集中するはずで、GAに向けた設計の熟成に注目したい。 Salesforceは長年蓄積したCRMデータという強みを持っている。AIエージェントが文脈を理解するにはデータの質と量が直結する。その意味で、Agentforce CoworkerがSalesforce上のデータをどれだけ上手に使いこなせるかが、他プラットフォームとの実質的な差別化ポイントになるだろう。今後の進化を引き続き注視したい。 出典: この記事は Salesforce Agentforce Coworker: AI teammate embedded in CRM search の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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か月と短いため、早めの動作確認を強く推奨する。 ...

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

2026年5月のSAP Sapphireカンファレンスにて、SAPとAnthropicは戦略的提携を正式発表した。AnthropicのAIモデル「Claude」が持つエージェンティックAI機能を、SAPが新設した「SAP Business AI Platform」に組み込み、SAPの全AI製品ポートフォリオに展開する計画だ。 SAP Business AI Platformとは何か SAP Business AI Platformは、SAPがビジネスアプリケーション向けに構築するAIインフラ基盤だ。財務・人事・サプライチェーン・調達といった基幹業務領域に、AI機能を統合的に提供するためのプラットフォームとして位置づけられている。 これまでSAPは自社AIアシスタント「Joule」を中心にAIを展開してきた。今回の提携でAnthropicのClaudeを採用することで、エージェンティックAIの高度な推論・計画・実行能力をSAPのビジネスプロセス全体に活用できるようになる。 「エージェンティックAI統合」の技術的な意味 「エージェンティックAI」とは、単純な質疑応答ではなく、目的を与えられると自律的に計画を立て、複数のステップを実行し、結果を検証するAIの動作様式を指す。 従来のERP × AIの統合は「チャットボットでデータを検索する」レベルに留まることが多かった。今回の提携が目指すのはその先だ。たとえば「月次決算の異常値検知 → 関係者へのアラート → 修正仕訳の提案 → 承認ワークフローの起動」といった一連のプロセスを、AIが自律的に進める仕組みの実現だ。ERPをAIのデータソースとして使うのではなく、ERPのビジネスプロセス自体をAIが動かすという設計思想の転換である。 日本企業への実務的影響 日本の大手・中堅企業の多くがSAPを基幹システムとして利用している。今回の統合は、これらの企業にとってAI活用の入口を大きく変える可能性がある。 具体的な活用ポイント： 会計・財務自動化の高度化：月次・四半期決算プロセスにおける例外処理や仕訳確認をAIエージェントが担当し、人間は例外の最終判断に集中できる。 サプライチェーン最適化：需要予測の外れ値発生時に、AIエージェントが自動で調達計画を見直し、サプライヤーへの発注調整まで一気通貫で実行できる。 HR業務の効率化：採用・育成・異動のサイクルでデータドリブンな意思決定をAIが支援し、HRBPが戦略的な仕事に集中できる環境を作る。 BTP（SAP Business Technology Platform）との統合：既存のBTP環境を持つ企業は、追加インフラなしにClaudeベースのエージェンティック機能を試験導入できる可能性がある。 今すぐできる準備 発表を受けて、今動けるアクションを整理しておきたい。 SAP S/4HANA Cloud利用企業：Sapphireで発表された詳細なロードマップをSAPパートナーに確認し、テナントへの展開時期を把握しておく。 オンプレミスSAP利用企業：クラウド移行の優先度を再評価するタイミングかもしれない。AI統合の恩恵はクラウド版から先に届く。 IT部門・SAP管理者：エージェンティックAIが自動実行できる業務スコープの洗い出しと、必要な承認フローの設計を今のうちに始める。 筆者の見解 今回の発表で注目したいのは、「ERPをAIのデータソースにする」のではなく「ERPのビジネスプロセス自体をAIが動かす」という設計思想への転換だ。AIエージェントが自律的にループで動き続ける仕組みこそが次のフロンティアだと考えているが、それをERPという企業の基幹データと業務プロセスに組み込むという方向性は理にかなっている。 日本企業にとって現実的な課題は、「AIに何を自動化させてよいか」というガバナンスの設計だ。すべてを人間が承認し続ける設計ではエージェンティックAIの本質的なメリットを得られない。一方で、何でも自動化すれば統制が崩れる。この境界線を業務ごとに定義してドキュメント化しておくことが、今すぐ取り組むべき準備だと感じている。 SAP Sapphireでの発表は方向性を示したものであり、具体的なロードマップが出てから本評価になる。大きな方向性は正しい。日本企業の現場がこの波に乗り遅れないよう、まずは自社のSAP活用状況の棚卸しから始めることをお勧めしたい。 出典: この記事は SAP and Anthropic: Claude on SAP Business AI Platform | SAP Sapphire の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年5月14日、大規模コードベースにおけるClaude Codeの動作原理とエンタープライズ向けベストプラクティスをまとめた記事を公開した。数百万行規模のモノリポ、数十年にわたって積み重なったレガシーシステム、数十のマイクロサービスにまたがる分散アーキテクチャ——そのいずれでもClaude Codeは本番運用されており、成功事例に共通するパターンが存在するという。 Claude Codeの「ナビゲーション」はエンジニアと同じ思考プロセス Claude Codeが大規模コードベースを探索する方法は、熟練エンジニアの思考プロセスに近い。ファイルシステムを走査し、ファイルを読み込み、grepで必要なものを探し、コードベース全体を横断しながら参照を追う。インデックスの事前構築も、サーバーへのアップロードも不要で、開発者のローカルマシン上で完結する。 これはRAG（Retrieval-Augmented Generation）ベースのAIコーディングツールとは根本的に異なるアプローチだ。RAGはコードベース全体を埋め込みベクトル化し、クエリ時に関連チャンクを取得する仕組みだが、アクティブな開発チームのペースには追いつけないという本質的な限界がある。 2週間前にリネームされた関数、先のスプリントで削除されたモジュール——RAGのインデックスはこうした変更を遅れて反映するため、検索結果に「すでに存在しないコード」が平然と現れる。Claude Codeのエージェント型検索はこの問題を構造的に回避する。中央集権的なインデックスがないため、数千人のエンジニアが新しいコードをコミットし続けても、各開発者のインスタンスは常にライブのコードベースと向き合える。 ただし、トレードオフもある。Claude Codeは「どこを見ればよいか」の初期コンテキストが充実しているほど精度が上がる。10億行規模のコードベースで漠然としたパターン検索を依頼すれば、作業開始前にコンテキストウィンドウの限界に到達してしまう。コードベースのセットアップへの投資が結果の質を左右する所以だ。 「ハーネス」がモデル性能を決める Claude Codeに関してよくある誤解は、その能力がモデルのスペックだけで決まるという思い込みだ。しかし実際には、モデルの周囲に構築されるエコシステム——ハーネス——がパフォーマンスを決定的に左右する。 ハーネスは5つの拡張ポイントで構成される： CLAUDE.mdファイル — コードベースやプロジェクトの文脈をClaude Codeに伝えるドキュメント フック（Hooks） — 特定のイベントをトリガーにして自動実行されるカスタム処理 スキル（Skills） — 繰り返し使う複雑なタスクを抽象化したモジュール プラグイン（Plugins） — ツールや機能を追加する拡張機能 MCPサーバー — 外部ツール・APIとの統合レイヤー これらの拡張ポイントは積み重ね型で、各レイヤーが前のレイヤーを土台にして機能する。CLAUDE.mdによるコンテキスト付与が土台となり、その上にフックやスキルが乗る設計だ。 Anthropicは今回の記事をエンタープライズ向けシリーズ「Claude Code at scale」の一環として位置づけており、C、C++、C#、Java、PHPなどのレガシー言語環境でも最近のモデルリリースにより予想以上の性能を発揮していると述べている。 実務への影響：日本のエンジニア・IT管理者へ CLAUDE.mdに投資することが最初の一手 Claude Codeを大規模環境で導入する際、最も費用対効果が高い初期投資はCLAUDE.mdの整備だ。プロジェクトのルート、各サブディレクトリ、チームのコーディング規約——これらの情報をCLAUDE.mdに記述することで、Claude Codeが「どこから探索を始めればよいか」を理解できるようになる。 インデックスレスの設計は「モノリポ問題」への有力な解答 日本の大手SIerや事業会社には、長年にわたって肥大化したモノリポや、部門ごとに乱立したリポジトリ群を抱えるケースが多い。RAGベースのツールがインデックス更新の遅延に悩む環境では、Claude Codeのエージェント型アプローチが実用的な選択肢になりうる。 ハーネスの設計はアーキテクチャの仕事 フック・スキル・MCPサーバーの組み合わせは、単なる設定ファイルではなくシステムアーキテクチャの一部だ。これらの設計をエンジニアリングチームのプロセスに組み込めるかどうかが、AI活用の成否を分ける。 筆者の見解 今回Anthropicが公開した内容で最も重要なポイントは、「モデルの賢さよりハーネスの設計が結果を決める」という事実の明示だ。これはある意味、AI活用の民主化とは逆の方向性を示している——道具が賢くなるだけでは不十分で、道具を囲む仕組みを設計できるエンジニアリング能力が問われるということだ。 特に注目すべきはハーネスループの考え方だ。CLAUDE.mdで文脈を与え、フックで自動化のトリガーを設け、スキルで複雑なタスクを抽象化する——この積み重ねが、Claude Codeを「単発の指示に応えるツール」から「自律的に判断・実行を繰り返すエージェント」へと変貌させる。自律的なループを設計できるかどうかが、AI活用の深さを決める。 日本の開発現場では、「AIツールを入れたけど思ったより使えなかった」という経験をした組織が少なくないだろう。多くの場合、それはツールの限界ではなくハーネスへの投資不足の問題だ。CLAUDE.mdを書き、フックを整備し、チームの作業パターンをスキルとして抽象化する——この地道な積み上げこそが、大規模コードベースでのAI活用の鍵になる。 エンタープライズシリーズとして今後も知見が公開される見込みで、大規模開発組織にとって参照すべき一次情報になっていくだろう。 出典: この記事は How Claude Code works in large codebases の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Z世代のAIへの反感が急増している——そう聞いて「また懐疑論か」と流してしまうのは早計だ。Walton Family Foundation、GSV Ventures、Gallupが共同で実施した最新調査は、私たちが見落としていた重大なシグナルを突きつけている。 数字で見るZ世代のAI離れ 2026年4月公開のGallup調査によれば、Z世代のAIへの「怒り」を感じている割合が前年の22%から31%へ急増した。「興奮」は14ポイント、「希望」は9ポイントそれぞれ低下。週次でAIを使用している割合は51%と過半数を維持しているものの、伸び率はわずか4ポイントと停滞している。「テクノロジーに最も親しんだ世代」と呼ばれたZ世代が、なぜAIに背を向け始めているのか。 「速くなる」と「学べなくなる」の矛盾 この調査が浮き彫りにした最も重要な数字がある。Z世代の80%が「AIを使って速くこなすと、長期的に学習が困難になる」と回答している。同時に56%が「AIは仕事を速く片付けるのに役立つ」と認めている。 つまりZ世代は、AIの「速さ」という恩恵を理解しつつも、その先に待つ「自分の能力が育たない」リスクを明確に意識している。これは単なる感情的な反発ではなく、相当に理性的なトレードオフ評価だ。さらに「AIは業務効率化に役立つ」と考える割合は2025年比で10ポイント低下しており、効用そのものへの信頼も揺らぎ始めている。 職場での「リスク認識」が急速に高まっている 労働市場への影響についても、Z世代の懸念は具体的だ。48%が「職場においてAIのリスクはメリットを上回る」と回答しており、前年比11ポイントの増加だ。 一方、K-12（小中高）の生徒の半数以上は「高等教育でAIが必要になる」「将来の仕事でAIを使うだろう」と見込んでいる。Z世代は「AIが必要な未来」を理解しながらも、その準備の仕方に確信が持てていない。この矛盾こそが、現在の「反感」の正体かもしれない。 学校での状況：ポリシーは整備、でも学生は冷静 74%の学校でAIに関する方針が設けられており、前年比23ポイントの増加だ。しかしポリシーが整っても学生の懸念は消えていない。41%の生徒が「クラスメートの多くはルールに反してAIを使っている」と感じており、教室内の信頼感が揺らいでいる。 実務への影響：日本のエンジニア・IT管理者が今すぐ考えるべきこと この調査の対象はアメリカのZ世代だが、日本のIT現場にも直結する示唆がある。 「禁止」ではなく「正しい使い方の設計」を。 Z世代の懸念は「AI利用そのものへの拒否」ではない。誰もが安全かつ倫理的にAIを活用できる環境が整っていないことへの不満だ。企業がAI利用を単に「解禁」するだけでは不十分。どう使うべきかを明示したガイドラインと、スキル開発の機会を同時に提供することが不可欠だ。 「速さ」だけを売りにするな。 AI導入を「業務効率化」の文脈だけで進めると、「自分の成長が阻まれる」という不安を増幅させる。AIを使ってどうすれば人間のスキルが伸びるか、という問いを設計の中心に据えるべきだ。 新人育成の設計を根本から見直せ。 「AIが仕事を奪う」という漠然とした恐怖より深刻なのは、「AIを正しく使える能力」が育まれないまま就職市場に送り込まれることだ。採用する側も「AIとどう協働するか」を評価軸に加える必要がある。 筆者の見解 Z世代の怒りは、ある本質的な問題を正確に指している。 AIを「副操縦士」として使わせる設計——確認を求め続け、最終決定は常に人間に委ねる形——では、ユーザーは「AIに振り回されるだけ」という体験しか得られない。Z世代が感じている「AIは自分を成長させてくれない」という感覚は、そのような設計への正当な反応だ。 本当に自律的に動くAIエージェント、つまりユーザーが目的を伝えれば自分で判断・実行・検証まで完結できるシステムを体験した人は、まだほとんどいない。多くの人が「AI体験」として持っているのは、チャットボットや補完ツールの域を出ない製品だ。そこから「AIは使えない」「学習が阻害される」という結論に至るのは、ある意味で当然の帰結だと思う。 Z世代の反感を「若者の誤解」として片付けてはいけない。彼らは鋭く正しいことを言っている。問題はAIそのものではなく、AIの使わせ方にある。 「禁止ではなく安全に使える仕組みを」——この原則は企業のAIガバナンス設計においても、教育現場においても同じく当てはまる。Z世代の声は、その設計を今こそ本気でやれと告げている。 出典: この記事は Gen Z Resentment Toward AI Grows as Adoption Stagnates and Workplace Fears Mount の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIへの出力フォーマット、まだMarkdown指定していますか？ 「Markdown形式で出力してください」——AIとのやり取りでこのフレーズを使っている人は多いはずだ。実はこの習慣、そろそろ見直しどきかもしれない。あるAIエージェント開発チームのメンバーが提言した「HTMLで出力を求めたほうが、圧倒的に情報が豊かになる」という主張が注目を集めている。単なる好みの話ではなく、時代背景を踏まえた技術的な根拠がある。 Markdownが定着した歴史的背景 Markdownがプロンプトでのデファクト出力形式になったのには、れっきとした理由がある。GPT-4が登場した当時、コンテキストウィンドウは8,192トークンという厳しい制限があった。HTMLと比較してMarkdownはトークン効率が格段に高く、限られた枠でより多くの情報を詰め込める。その実用的な判断が、そのまま業界の習慣として定着した。 言わば「当時の制約に最適化されたベストプラクティス」が、制約が消えた後も惰性で使われ続けている状態だ。 制約が消えた今、何が変わるのか 2026年現在、主要モデルのコンテキストウィンドウは飛躍的に拡大している。トークン効率を最優先に考える必要性は大幅に下がった。そこで問い直されるのが「出力形式を何のために指定するのか」だ。 Markdownの価値は「シンプルで汎用性が高い」こと。一方、HTMLの強みは表現力の豊かさにある。HTMLで出力を求めれば、以下が使えるようになる： SVGダイアグラム — アーキテクチャ図やフローチャートをテキスト内に直接埋め込める インタラクティブなウィジェット — JavaScriptによるクリック・展開・絞り込みが可能 ページ内ナビゲーション — 長い技術ドキュメントでもアンカーリンクで素早く移動できる 視覚的な重み付け — CSSでコンテンツの重要度を色・サイズ・配置で直感的に伝えられる Markdownはテキストエディタで読む前提の形式だ。AIの出力をブラウザや専用ビューアで消費するなら、HTMLの表現力を活かさない理由はない。 実践的なプロンプト例 PRレビュー支援のプロンプトとして、こんな指示が提案されている： 出典: この記事は Using Claude Code: The Unreasonable Effectiveness of HTML の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google I/O 2026（5月19〜20日）の開幕を目前に控えた今週、Googleの次世代軽量AIモデル「Gemini 3.2 Flash」が、iOS向けGeminiアプリおよびGoogle AI Studioに正式発表なしで姿を現した。入力100万トークンあたり$0.25という価格設定と、Gemini 3.1 Proを上回る処理速度が注目を集めている。正式発表前の「先行露出」として業界での観測が広がっており、Google I/Oでの詳細な発表に向けて期待が高まっている状況だ。 Gemini 3.2 Flashとは何か 「Flash」はGoogleが軽量・高速・低コストを重視したモデルラインに与える名称だ。重量モデル（Proシリーズ）の能力を部分的に絞り込む代わりに、APIコストと応答速度で競争力を持たせる設計思想は、他社の「Mini」「Small」系モデルと同様のアプローチと言える。 現時点で確認されている主な特徴は以下の通りだ： 入力価格: 100万トークンあたり**$0.25** 処理速度: Gemini 3.1 Proより高速 先行公開チャネル: iOS GeminiアプリとGoogle AI Studio 現時点では公式ドキュメントやモデルカードは未整備の状態であり、詳細なベンチマーク・コンテキスト長・マルチモーダル対応範囲はGoogle I/Oでの発表を待つ必要がある。 価格戦略が示すもの $0.25/1M入力トークンというのは、現在のAPI市場でも相当積極的な価格水準だ。この数字が意味するのは、Googleが軽量モデル市場での存在感を価格競争力で確保しようとしているという明確な意図だ。 大量のAPIコールが発生するプロダクション用途——チャットボット、ドキュメント処理、コード補助など——では、このコスト差は年間換算で無視できない規模になる。特に、日本のSI企業やスタートアップがAI機能を既存サービスに組み込む際、モデル選定のコスト試算は重要な検討軸になってくる。「AIを使いたいが予算が厳しい」という壁にぶつかっている現場にとって、低価格モデルの品質向上はストレートに朗報だ。 Google I/O 2026での正式発表に向けて 現在確認されている情報は、ユーザーや開発者が先行アクセスで観察した断片情報が中心で、公式の仕様は未発表だ。Google I/O 2026では、Gemini 3.2シリーズ全体の詳細——Ultraモデルの動向も含め——が発表される可能性が高い。 AI企業各社が大型カンファレンスを前に事前リークを容認あるいは意図的に仕掛けるケースは増えている。Googleも例外ではなく、今回の先行露出はI/Oへの期待値をコントロールするマーケティング戦略の一環とも読める。発表までの約2週間、詳細な仕様を判断材料にするには早計だが、方向性を把握しておく価値はある。 実務への影響 API統合を検討しているエンジニア向け 現時点でのプロダクション採用は早計。Google I/Oで正式な仕様・SLA・可用性が明示されてから評価すべきだ 既にGeminiを使用しているプロジェクトでは、3.2 Flashへのスワップによるコスト削減効果をI/O後にすぐ試算できる準備をしておくとよい 「軽量モデルで十分な用途か、重量モデルが必要な用途か」の分類を今のうちに整理しておくことで、リリース後のA/Bテスト設計がスムーズになる IT管理者・調達担当者向け GoogleのAIサービスを利用中の場合、Vertex AI側での対応タイムラインもI/Oで確認すること ライセンス体系の変化も含め、Google Workspaceとの統合フローへの影響を確認しておく 筆者の見解 正直に言えば、ここ1〜2年の実務でGoogleのモデルを積極的に選ぶ機会は多くなかった。画像生成の分野では依然として高い水準を誇っているが、テキスト・コード系の実用性という点では、他の選択肢を手に取る場面が増えていたのが実態だ。 ただ、今回のGemini 3.2 Flashの価格戦略は別の文脈で注目に値する。AI APIのコスト問題は、特に日本の中堅・中小企業にとってAI活用の最初の壁になることが多い。価格競争が激しくなることで市場全体の底上げが進むのは、どの企業のユーザーにとっても歓迎すべきことだ。 課題は「安いが実際に使えるか」というトレードオフだ。速度と価格で競争力があっても、精度や指示追従性が実務水準に届かなければ現場では採用されない。Google I/Oで公開される詳細な仕様と、その後の開発者体験の積み重ねが、このモデルの真価を決める。 Googleほどのデータ資産とインフラを持つ企業が本気で軽量モデルに取り組めば、それ相応のものが出てくるはずだという期待感はある。$0.25という価格を維持しながら実務に耐える品質を実現できるなら、軽量モデル市場の競争地図が塗り替わる可能性は十分ある。今年のGoogle I/Oは、例年以上に注目しておく価値がある。 出典: この記事は Gemini 3.2 Flash: Everything We Know Before I/O 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Googleが提供するブラウザ・Chromeが、ユーザーの許可なく約4GBのAIモデルをデバイスにサイレントインストールしていたことが明らかになった。インストールされるのはGemini Nanoの重みファイルだ。プライバシー研究者によるGDPR違反の指摘、そしてCO2換算で最大6万トンにのぼるとされる環境負荷の試算は、AI機能のブラウザ統合が急速に進む今、業界全体が向き合うべき問題を突きつけている。 ユーザーの知らない場所で起きていること Chromeがインストールされたマシンのユーザープロファイルに、OptGuideOnDeviceModel というディレクトリが作成され、その中に weights.bin という約4GBのファイルが存在する。正体はGemini Nanoの重みファイルだ。「Help me write（文章作成AI補助）」やオンデバイス詐欺検出など、Chromeが推し進めるAI機能のバックエンドとして使われる。 問題の核心は 「同意が存在しない」 という一点だ。 インストール時も使用中も同意ダイアログは表示されない Chrome設定画面にダウンロードを制御するチェックボックスはない ユーザーが手動でファイルを削除しても、Chromeの起動のたびに再ダウンロードされる これはブラウザの通常のアップデートとは性質が異なる。4GBのAIモデルをユーザーのローカルストレージに書き込むという行為は、明らかにその範疇を超えている。 法的リスク：GDPR・ePrivacy指令への抵触 プライバシー専門家Alexander Hanff氏の分析によると、この行為は欧州の複数の規制に抵触する可能性がある。 ePrivacy指令 第5条(3) ユーザーの同意なしにデバイスへ情報を保存・アクセスすることを禁じる。CookieやトラッキングPixelと同じ法的枠組みが適用される。 GDPR 第5条(1) データ処理における適法性・公正性・透明性の原則。ユーザーが知らない場所で行われる処理は透明性原則に反する。 GDPR 第25条 データ保護バイデザインの義務。設計段階からプライバシー保護を組み込む義務があり、事後的な「設定で無効化できます」では不十分とされる。 CSRD（企業サステナビリティ報告指令） 環境負荷の開示義務。後述する環境コストが報告対象となりうる。 日本においても個人情報保護法の観点から注視が必要だ。特に企業のマネージドデバイス管理においては、予期しない大容量ファイルの書き込みはセキュリティポリシーとの整合性問題を生む。 見落とされがちな環境コスト この問題で特に注目したいのが 環境への影響 だ。 Chromeは全世界で20億台を超えるデバイスで使われている。仮に数億台にこの4GBファイルが配信されたとすると、ネットワーク転送と端末処理に要するエネルギーをCO2換算すると 6,000〜60,000トン相当 にのぼると試算されている。 一企業が「ユーザーに聞かずに決めた」配信が、これほどのスケールで環境に影響を及ぼすという事実は重い。ESGが企業評価に直結する時代において、この種の「無断バルク配布」はガバナンス上の問題としても認識されるべきだろう。 実務での対応ポイント ファイルの存在を確認する Windows: %LOCALAPPDATA%\Google\Chrome\User Data\ 以下 macOS: ~/Library/Application Support/Google/Chrome/ 以下 上記パスに OptGuideOnDeviceModel/weights.bin（約4GB）があればインストール済みだ。 企業環境での制御 Chrome管理ポリシーで GenAILocalFoundationalModelSettings を設定することで、オンデバイスAIモデルのダウンロードを無効化または制御できる。Google Admin Console・グループポリシー（GPO）・MDMのいずれでも適用可能だ。大規模展開前にまずパイロット端末で動作を確認することを推奨する。 EDR・DLPアラートへの対応 マネージドデバイスに突然4GBのファイルが生成されるため、EDRやDLPが誤検知するケースがある。除外ルールの見直し、あるいはポリシー配布前に「これは正規ファイルか」を確認するフローを整備しておくとよい。 筆者の見解 今回Chromeがやったことは、「サービス改善のために」という大義名分のもとに行われる一方的なリソース消費の典型例だ。 筆者が特に問題だと感じるのは、削除しても再インストールされるという設計思想だ。これはユーザーの意思決定を無効化するメカニズムであり、「ユーザーが主体的にコントロールできる体験」とは真逆のアプローチと言わざるを得ない。 テクノロジーの進化においては「禁止より安全に使える仕組みを」という考え方が正しいと思っているし、AIのブラウザ統合そのものを否定するつもりはない。オンデバイスで動くAIにはプライバシー保護やレイテンシの面で明確な利点がある。 しかし、利点があるからといって、ユーザーの同意なしに4GBのリソースを消費してよいわけではない。それは技術的なメリット・デメリットの問題ではなく、ユーザーへの敬意の問題だ。「より良いブラウザ体験」を本気で目指す技術力があるなら、透明性のある同意フローを設計する力もあるはずで、今の実装はその力を活かしていないという意味でもったいない。 今後、各国の規制当局がどう判断するかが注目点だ。GDPRの観点での行政指導・制裁が実現すれば、ブラウザベンダー全体がオンデバイスAI機能の配布ポリシーを見直す契機になるだろう。日本のIT管理者も対岸の火事と見ずに、今のうちから自社ポリシーの点検を始めておくことを強く勧める。 出典: この記事は Google Chrome silently installs a 4 GB AI model on your device without consent の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

何が起きたか 2026年4月16日、VS Code の Git 拡張機能に静かな変更がマージされた。git.addAICoAuthor という設定のデフォルト値が "off" から "all" に切り替えられ、Copilot を一切使っていなくても、コミット時に自動で Co-authored-by: GitHub Copilot というトレーラー行が付与されるようになったのだ。 PR（#310226）には説明文すらなく、コミュニティの反応は苛烈だった。投稿から数日で 👎 が 372件に達し、賛成の 👍 はわずか 2件。GitHub の単一PRとしては異例のスコアだ。 技術的な問題点 「使っていないのに名前が入る」問題 git の Co-authored-by トレーラーはもともと、複数人で書いたコードを正直に記録するための仕組みだ。OSS コミュニティでは著作権の帰属を明確にするために使われ、企業の内部開発でも「誰が書いたか」の追跡に使われる。 デフォルト "all" は、Copilot を積極的に使ったかどうかに関わらず、VS Code を起動していれば Co-author として記録する可能性を意味する。たとえ自分でゼロから書いたコードでも、コミットには AI の名前が残る。 実装の不整合も指摘 Copilot によるコードレビューも、この PR の問題を正確に突いている。設定スキーマのデフォルトは "all" に変わったが、extensions/git/src/repository.ts 内のランタイムフォールバックは config.get('addAICoAuthor', 'off') のままだ。スキーマとランタイムが乖離しており、テスト環境などでは意図しない挙動が生じる可能性がある。 オプトアウト設計の本質的な問題 ソフトウェアのデフォルト設定はユーザーの同意を代理する。特にプライバシー・著作権・帰属に関わる設定で「デフォルト有効」を選ぶことは、「ユーザーは気づかなくていい」という設計思想の表明にほかならない。 実務への影響 日本の企業エンジニアが確認すべきこと 1. 設定の明示的な管理 settings.json または devcontainer.json に次を追加し、意図しない挙動を防ぐ。 出典: この記事は VS Code inserting ‘Co-Authored-by Copilot’ into commits regardless of usage の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAI Codex CLIツールのソースコードがGitHub上に公開されていることはご存知だろうか。そのコードの中に、なかなか興味深い記述が見つかった。GPT-5.5向けのベースシステムプロンプト（base_instructions）に、次のような一文が含まれていたのだ。 「ゴブリン、グレムリン、アライグマ、トロル、オーガ、ハト、その他の動物や生き物については、ユーザーのクエリに絶対的かつ明確に関連していない限り、一切話してはならない。」 思わず笑ってしまいそうな指示だが、これは単なる冗談ではない。AIの実運用現場で「具体的な禁止指示」が必要とされているという現実を、この一行は端的に示している。 なぜ「ゴブリン禁止」が必要なのか LLM（大規模言語モデル）は、その学習データの広さゆえに、会話の流れと無関係な方向に話が逸れることがある。コーディングアシスタントとして設計されたツールが、突然ファンタジー世界の生き物の話を始めたり、動物の雑学を披露し始めたりすれば、ユーザー体験は著しく損なわれる。 この「ゴブリン禁止」指示が示しているのは、モデルの素の振る舞いをシステムプロンプトで意図的に矯正する必要があるという事実だ。どれほど高性能なモデルであっても、具体的な制約なしには特定の状況でファンタジー的な話題にシフトする傾向が残ることがある。GPT-5.5においても例外ではないというわけだ。 システムプロンプト設計の「本音」が見えた 今回の発見が特に興味深いのは、これが大手AIラボの「本番環境」で使われているプロンプトだという点だ。研究論文やデモではなく、実際にユーザーが使うプロダクトのコードに埋め込まれている。 プロンプトエンジニアリングの世界では、「汎用的な指示より、具体的な禁止事項のほうが効果的」というプラクティスが知られている。「適切な回答をせよ」と書くよりも「○○については話すな」と明示した方が、モデルの振る舞いをより確実にコントロールできる場合がある。 これはソフトウェア開発の入力バリデーション設計にも似た発想だ。「正しい入力をしてください」と伝えるより、「この形式以外はエラーにする」と設計する方が、実際の品質を担保しやすい。AIエージェントの設計も、こうした地道な積み上げで成り立っている。 実務での活用ポイント 具体的な禁止リストを持つ 自社のAIアシスタントやチャットボットを設計するとき、「何を話すべきか」だけでなく「何を絶対に話すべきでないか」を明示的にリストアップしておくと効果的だ。競合他社への言及、個人情報の取り扱い、業務と無関係な話題への逸脱防止など、用途に応じた禁止事項を具体的に書く。 システムプロンプトは運用しながら育てる 今回の「ゴブリン禁止」指示が追加された経緯は不明だが、おそらく実際の利用の中で問題が発生し、それを受けて加筆されたものだろう。最初から完璧なプロンプトを書こうとせず、運用しながら改善していく「プロンプトの育て方」が現実的なアプローチだ。 OSSプロジェクトから学ぶ OpenAI CodexはOSSとして公開されているため、そのソースコードから実際のシステムプロンプト設計を学べる。大手が本番環境でどう設計しているかを参照できる貴重な事例として、AIツールを開発・運用するエンジニアにとって参考になる。Azure OpenAI ServiceやAzure AI Foundryを活用してAIアシスタントを構築している日本のIT部門にとっても、設計の参考にできる視点だ。 筆者の見解 「ゴブリンについて話すな」——この一行が妙に印象に残る。笑い話のように見えて、AIエージェントの運用に携わる人間にとっては、深くうなずける話でもある。 どれほど高性能なモデルであっても、実際のプロダクトに組み込むためには「動作の境界線」を明確にする必要がある。これはモデルへの不信ではなく、信頼できるシステムを作るための基本的なエンジニアリングだ。「禁止ではなく、安全に使える仕組みを設計する」という視点は、プロンプト設計においても変わらない原則だと思う。 一方で、こうした禁止リストが積み重なっていくと、AIエージェントの本来の価値である「自律的な判断・実行」が少しずつ削られていく構造的なジレンマもある。何でも制約して安全側に振りすぎると、AIを使う意味が薄れてしまう。どこまで制約し、どこから自律に委ねるかという設計の哲学は、ますます重要なテーマになっていくだろう。 「ゴブリン禁止」という一行の奥には、そういう問いが静かに潜んでいる。 出典: この記事は Quoting OpenAI Codex base_instructions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月、世界の数学界に衝撃が走った。数学の専門的訓練を受けたことのない23歳の青年・リアム・プライス氏が、ChatGPT Proを使って60年間にわたって世界トップクラスの数学者たちが解けなかった「エルデシュ問題」を解いたのだ。しかも、AIが採用したアプローチは人間がかつて試みたことのない完全に新しい手法だった。 エルデシュ問題とは何か この問題の主役は、20世紀最多の共著論文を持つ奇才数学者ポール・エルデシュが残した未解決問題群の1つだ。対象は「原始集合（primitive sets）」と呼ばれる整数の集合——集合内のどの数も他の数の約数にならないという性質を持つ。素数の集合はすべて自動的に原始集合になる（素数は1と自身以外に約数を持たないため）。 エルデシュはこの集合に「エルデシュ和」というスコアを定義し、2つの予想を立てた。1つ目は「このスコアの最大値は素数の集合が達成する」という予想で、スタンフォード大学のジャレッド・リヒトマン氏が2022年に博士論文で証明した。 問題になったのは2つ目だ。「集合の数が大きくなるほどスコアは下がり、最下限は1に近づく」という予想——この証明にリヒトマン氏を含む多くの著名数学者が挑んだが、誰も突破できなかった。 1プロンプトで突破した23歳 プライス氏がGPT-5.4 Proに送ったのはたった1つのプロンプトだった。AIが返したアプローチは、人間の数学者たちが全員見落としていた全く新しい手法だった。 フィールズ賞受賞者でカリフォルニア大学ロサンゼルス校のテレンス・タオ教授はこう語った。「人間の研究者たちは全員、最初の一手で微妙に間違った方向に進んでいた。ある種の思考の固定化があったようだ」 これはAIが「単に既存の知識を組み合わせた」のではなく、人間が踏み込まなかった領域へ踏み込んだことを意味する。専門家たちがこの問題について持っていた「常識的なアプローチ」こそが、60年間の障壁だったのだ。 AIが数学において示す本当の強み この出来事が特別な理由は2つある。 第一に、問題の「難しさの種類」だ。AIがこれまで解いてきたエルデシュ問題の多くは「AI実力の不完全なベンチマーク」と批判されてきた。しかし今回の問題は複数の著名数学者が本気で取り組んでいたもので、その重要性は別格だ。 第二に、「方法の新規性」だ。AIが見つけた手法は今後の同種の問題全般に応用できる可能性を秘めているとされる。単発の解答ではなく、新しい数学的道具を発見したかもしれない。 実務への影響——「先入観を持たない問題解決者」としてのAI この事例は、日本のエンジニアやIT管理者にも直接的な示唆を持つ。 AIを「確認ツール」ではなく「探索ツール」として使う: 多くの現場でAIは既存の実装の確認や文書作成に活用されている。しかし今回の事例が示すのは、AIに「自分たちが長年解けていない問題」を持ち込む価値だ。組織の中で「なぜか解決しないボトルネック」「誰も良い答えを出せない課題」こそ、AIに投げてみる価値がある。 プロンプトの技術より「持ち込む問題の質」: プライス氏は高度な数学訓練なしに成功した。重要だったのは洗練されたプロンプト技術ではなく、「解くべき問題を明確に定義してAIに委ねた」という姿勢だ。実務でも、問題の構造をきちんと整理してAIに持ち込むことが鍵になる。 「新人の目線」を意図的に作り出す: 専門家の先入観がボトルネックになるなら、あえて「その分野の文脈を持たないAI」に問いかけることで、専門家が見えなくなっていた解法が浮かび上がることがある。チームの中で長年解けていない問題があれば、試してみる価値は十分ある。 筆者の見解 今回の事例で最も印象的だったのは、タオ教授の言葉——「人間たちは最初の一手で微妙に間違えていた」という観察だ。 人間の専門性は強力だが、それ自体が「こう考えるべき」という固定された地図を作り出す。AIはその地図を持たない。これはバグではなくフィーチャーだ。「先入観のなさ」がAIを強力な問題探索エンジンにしている。 一方で、この事例をもって「AIが数学者に取って代わる」と結論づけるのは早計だ。プライス氏の成果はAIが生成したものだが、それが「本当に正しいのか」を検証し、数学界に適切に提示したのは人間だ。問題を選び、提示し、検証し、意味を解釈するループは依然として人間が担っている。 ただ、そのループの中に「AIに問題を委ねる」ステップが加わった意味は大きい。研究者にとっても、ビジネスの問題解決にとっても、「解き方を自分で考える前にAIに投げてみる」という習慣が、長年突破できなかった壁を崩す可能性を持っている。 AI活用の最前線は、「どう指示するか」から「どんな問題を持ち込むか」へとシフトしつつある。その視点の転換こそが、次のブレークスルーを生む鍵になるだろう。 出典: この記事は Amateur armed with ChatGPT solves an Erdős problem の内容をもとに、筆者の見解を加えて独自に執筆したものです。

テンセント（Tencent Holdings）が2026年4月24日、新しいオープンソースAIモデル「Hy3 Preview」（Hunyuan 3 Preview）を公開した。AI部門の体制刷新後、初めての大型モデルリリースとなる。単にモデルを出しただけでなく、自社の主力チャットボット「元宝（Yuanbao）」の基盤モデルをDeepSeekから即座にHy3へ切り替えるという実践的なデプロイメントを同時に実施している点が注目に値する。 Hy3 Previewの技術仕様 Hy3 PreviewはMixture-of-Experts（MoE）アーキテクチャを採用した大規模言語モデルだ。主な仕様は以下のとおり： 総パラメータ数: 2950億（295B） アクティブパラメータ数: 210億（21B） コンテキストウィンドウ: 2560億トークン（256K tokens） ライセンス: オープンソース公開 MoEアーキテクチャの特徴は、推論時に全パラメータを使わず、入力に応じて適切な「専門家（Expert）」モジュールだけを活性化する点にある。2950億という総パラメータは圧倒的な規模だが、推論時に実際に動くのは210億パラメータ分に過ぎない。これにより、巨大モデルの知識を保ちながら推論コストを抑えるという実用面での合理性が生まれる。 256Kトークンのコンテキストウィンドウは、長大なドキュメント処理や複雑なコードベース解析において実用的な優位性をもたらす。企業システムのログ解析、法務文書の一括処理、大規模なコードリポジトリの参照といったユースケースで威力を発揮しうる。 なぜDeepSeekからの切り替えが重要か 今回のリリースで特筆すべきは、モデルの性能仕様そのものよりも「Yuanbaoの基盤をDeepSeekから自社技術に切り替えた」という事実だ。 テンセントはこれまで、自社チャットボットの基盤として競合他社であるDeepSeekのモデルを採用していた。これはビジネス的には合理的な判断だったが、戦略的には自社のAI競争力が問われる状況でもあった。今回の切り替えは、「自社モデルが実際のプロダクトで使える水準に到達した」という内部評価の表れとも読める。 また、AIの競争優位を「モデルの所有」に見出す戦略は、中国テック大手に共通するトレンドでもある。エコシステム全体（WeChat、Tencent Cloud、Yuanbao等）でモデルを内製・統合することで、データのフィードバックループと差別化を同時に実現しようとしている。 「ベンチマーク競争」から「プロダクト統合」へ 公式発表において、テンセントは新AI責任者のもとで「ベンチマークスコアよりも実際のプロダクトへの統合を優先する」戦略転換を明確に打ち出している。 これは重要なシグナルだ。ここ数年、AI業界はモデルの性能評価において、各種ベンチマーク（MMLU、HumanEval、MATHなど）のスコア競争が過熱していた。しかし、ベンチマーク上の数字が良くても、実際のプロダクトで役立つかどうかは別問題という認識が、主要プレイヤーの間で広まりつつある。 「実際に使える製品に組み込む」という方向への舵切りは、中国AI市場の競争激化と無縁ではない。ByteDance（Doubao）、百度（Ernie）、アリババ（Qwen）など、国内ライバルとの差を埋めるためには、モデル数値の優劣よりも、WeChat等のプラットフォームに深く統合された体験の質が問われるからだ。 実務への影響——日本のエンジニア・IT管理者に向けて Hy3 PreviewはオープンソースとしてHugging Face等で公開されることが見込まれる。日本のエンジニアが実務で活用を検討する際のポイントをまとめる。 1. MoEモデルのデプロイ特性を把握する 総パラメータは2950億でも、実際の推論には210億分のリソースしか使わない。ただし、MoEはルーティング機構のオーバーヘッドがあるため、GPU/CPUメモリの要件や推論速度はアクティブパラメータ数だけで単純に計算できない。自社インフラへの展開前に、実際の推論コストをベンチマークすること。 2. 256Kコンテキストの活用場面を見極める 長文コンテキストは、社内規程集・契約書・コードベースの一括参照など、企業内のナレッジワーカー支援で真価を発揮する。ただし、長大なコンテキストは推論コストが高くなるため、全ての用途に適用するのではなく、ユースケース別に適切なウィンドウサイズを選択することが重要。 3. 中国発オープンソースモデルの利用ポリシーを確認する DeepSeekのケースで日本企業にも普及しつつある中国発オープンソースモデルだが、利用にあたってはライセンス条項の確認に加え、情報セキュリティポリシーとの整合性確認が必須だ。特に、機密データを含む社内ユースケースへの適用前に、セキュリティ部門との合意を取ること。 4. エコシステム統合という視点で読む Hy3単体の性能よりも、「テンセントのエコシステム全体に統合されたAI」という文脈で理解することが大切。WeChat AIエージェントなど、テンセントプラットフォームと連携するシステムを開発・評価する際は、基盤モデルの変更がAPIの挙動や出力品質に影響を与える可能性がある。 筆者の見解 今回のテンセントの発表で印象的だったのは、モデル仕様の数値よりも「プロダクト統合優先」という戦略宣言だ。ここに、AI開発の現在地を端的に示すメッセージが含まれていると思う。 モデル単体で評価する時代は終わりつつある。重要なのは、そのモデルが実際のユーザー体験にどう組み込まれ、継続的に使われ続ける仕組みになっているかだ。AIの本当の価値は、単発の応答精度ではなく、ユーザーのワークフローに深く埋め込まれた「自律的に動き続ける仕組み」にある——そう考えると、テンセントの今回の方向性は正しいと思う。 一方、テンセントが本当に目指しているのは、LLMそのものの品質競争を超えた「エコシステム全体のAI化」だろう。WeChat AIエージェント、Yuanbaoの強化、そして今回のHy3展開は、その布石として読める。WeChatが日常コミュニケーションと経済活動のインフラである中国において、このエコシステム戦略は強力な競争優位につながりうる。 日本のIT現場においても、「良いモデルを選ぶ」という発想から「どうシステムに統合し、継続的に活用し続けるか」という発想への転換が求められている。Hy3 Previewが示したのは、AIの競争軸がモデル性能から「実装力」と「エコシステム力」に移行しつつあるという事実だ。この流れを読んで、自社のAI導入戦略を再点検する機会にしてほしい。 出典: この記事は Tech Brief (April 24): Tencent Unveils First Major AI Model Update Under New Leadership | Caixin Global の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...