Generative-Ai

MicrosoftがAI領域における独自技術の確立に向け、大きな一歩を踏み出した。2026年4月2日、同社は「MAI Superintelligence」イニシアチブの一環として、音声認識・音声合成・画像生成の3種類の新基盤モデルを発表した。OpenAIとのパートナーシップ開始以来、初めての本格的な独自フロンティアモデルの商用リリースであり、Microsoftのプラットフォーム戦略において象徴的な転換点となる。 3つのMAIモデル、それぞれの実力 MAI-Transcribe-1（音声認識） 25言語にわたるFLEURS評価における平均単語誤り率（WER）3.8%を達成し、OpenAIのWhisper-large-v3を全25言語で上回る性能を示した。Google Gemini 3.1 Flashに対しても22言語で優位に立っており、多言語対応の音声認識モデルとしてトップクラスの実力を持つ。日本語が対象言語に含まれているかは明示されていないが、25言語対応という規模感から見ても実用性は高いと判断できる。 MAI-Voice-1（音声合成） リアルタイムの60倍速で音声を生成でき、わずか数秒のサンプル音声からカスタムボイスを作成する機能を備える。価格は100万文字あたり22ドルで、音声合成市場の有力プレイヤーであるElevenLabsと真っ向勝負する価格設定だ。企業向けのナレーション自動生成や、アクセシビリティ対応コンテンツの制作コスト削減に直結するスペックである。 MAI-Image-2（画像生成） Arena.aiのランキングで上位3位に入り、前世代モデル比で生成速度が2倍に向上した。入力100万トークンあたり5ドル、画像出力33ドルという料金体系で、Microsoft Foundryおよびの新しいMAI Playgroundから利用可能。広告大手WPPが最初のエンタープライズパートナーとして名を連ねており、商業クリエイティブ用途への展開が早くも動き始めている。 「10人チーム」が示すMicrosoftの本気 特筆すべきは、音声系モデルがわずか10人のエンジニアチームによって開発されたという事実だ。CEO Mustafa Suleiman氏が掲げる「小規模・高権限チーム」哲学の体現であり、大組織ならではの遅さやリソース浪費を意識的に排除しようとする意図が見える。これはOpenAIやAnthropicといった専業AIラボが持つ機動力に、Microsoftも本気で応えようとしているシグナルだと読める。 日本のIT現場への影響 Microsoft Azureユーザーにとってのチャンス 今回のモデルはMicrosoft Foundry経由で提供される。Azure AIサービスをすでに利用している組織にとっては、既存のID管理・コスト管理・セキュリティ設定をそのまま活用しながら高性能モデルにアクセスできる利点が大きい。サードパーティの音声・画像APIを別途契約しているケースでは、統合によるコスト削減と運用簡素化が期待できる。 音声認識の精度向上は業務直結 MAI-Transcribe-1の多言語高精度認識は、議事録の自動化・コールセンターの音声ログ解析・多言語サポートチャットなど、実務に直接刺さる用途が多い。現場でWhisperを使って「精度が惜しい」と感じていたエンジニアは、比較検証する価値がある。 実務での活用ポイント MAI Playgroundで即試す: まずはMAI Playgroundで自社データに近いサンプルを使って各モデルの精度を検証する コスト比較を忘れずに: 既存ベンダーの料金と比較試算する。特にMAI-Voice-1の$22/100万文字は競合サービスと横並びで評価したい Azure AI Foundryへの移行検討: 複数のAIサービスをバラバラに契約しているなら、Foundryへの集約でガバナンス統制が効きやすくなる 筆者の見解 Microsoftには、ブランドとユーザーベースという他社には持てない強みがある。Azure・M365・Teams・Windowsという強固なプラットフォームに乗った状態でAI基盤モデルが揃ってくるなら、エンタープライズ市場での展開力は圧倒的だ。そのポテンシャルを考えると、今回の発表は「ようやく本来の戦い方ができる準備が整ってきた」という印象を受ける。 OpenAI依存という構造的なリスクを抱えたまま推し進めてきたここ数年を振り返ると、独自モデルを持つことの意義は戦略的に大きい。Copilotのエンドユーザー体験に課題があったとしても、基盤技術が自社に帰属することで改善サイクルを自分たちでコントロールできるようになる。それは長期的に見て、非常に重要な変化だ。 10人チームで競合と渡り合える性能のモデルを作り上げたという事実は、Microsoftの技術力が健在であることの証明でもある。エンジニアリングの実力は確かにある。だからこそ、その力が全力で活かされる設計と判断が継続されることを期待したい。今後のCopilot系プロダクトやMicrosoft Fabricへの統合がどう進むか、引き続き注目していく。 出典: この記事は Microsoft Unveils MAI Superintelligence Models for Text, Voice, and Image Generation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindとロボティクス企業Boston Dynamicsが共同で開発した「Gemini Robotics-ER 1.6」がリリースされた。産業現場での知覚・自律行動能力を大幅に強化したこのモデルは、AIとフィジカルな世界をつなぐ「エンボディドAI（Embodied AI）」の実用化において、ひとつの重要なマイルストーンと言っていい。 Gemini Robotics-ER 1.6とは何か 「ER」はEmbodied Reasoning（身体化された推論）の略で、AIが視覚・空間情報を統合し、現実世界でのタスクを計画・実行する能力に特化したモデルラインだ。バージョン1.6では特に産業向け知覚能力（Industrial Perception）が強化されており、物体の形状・配置・状態の認識精度が向上し、より高い自律性で複雑なマニピュレーションタスクをこなせるようになった。 Boston Dynamicsとの連携という点も注目に値する。同社はSpotやStretchといった実用ロボットで豊富な現場ノウハウを持つ。DeepMindのモデル開発力と、Boston Dynamicsの実機知見が融合することで、「ラボで動く」から「工場や倉庫で動く」へのギャップを埋めにいっているわけだ。 なぜこれが重要か これまでの産業用ロボットは、動作をひとつひとつプログラムする「ティーチング」が前提だった。作業内容が変わるたびに再プログラムが必要で、導入コストも高く、中小企業には手が届かない世界だった。 Gemini Robotics-ER 1.6が示す方向性は「指示を理解して自律的に動く」ロボットだ。視覚と空間認識が高度化すれば、「この部品をここに置いてくれ」という自然言語に近い形での指示で動作が成立する世界が見えてくる。ティーチングレスの産業ロボットは、少子高齢化で慢性的な人手不足に直面する日本の製造・物流現場にとって、単なる生産性向上にとどまらない構造的な解になりうる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 現時点でGemini Robotics-ER 1.6が即座に現場に投入できるわけではない。ただ、技術トレンドとして今から押さえておくべきポイントがある。 AIとロボティクスの統合は「これから来る」ではなく「始まっている」 エンボディドAIの研究リリースが相次ぐ現状は、2〜3年後の現場導入フェーズへの布石だ。製造・物流・建設に関わるエンジニアは、今のうちにこの分野の語彙と概念を頭に入れておく価値がある。 2. 「視覚AI」基盤の整備が先行投資になる Gemini Robotics-ERのような技術はカメラ・センサーからの高品質な入力データを前提とする。工場や倉庫のカメラインフラ、エッジコンピューティング環境の整備は、自律ロボット導入の必要条件になる。IT部門が先手を打てる領域だ。 3. 「AIエージェント」の文脈で考える ロボットの自律化は、ソフトウェアの世界で進むAIエージェント自律化と本質的に同じ問いを立てている。「人間が確認・承認するループを最小化し、AIが自律的に判断・実行・検証を繰り返す」——この設計思想はロボティクスでもソフトウェアでも共通だ。 筆者の見解 Geminiブランドは画像生成では存在感を示してきたが、実務的なAIエージェント領域ではまだ実力を問われる場面が多い。ただ、今回のBoston Dynamicsとの連携は別次元の話だと捉えている。物理空間での自律行動というフィールドは、純粋なソフトウェア競争とは異なる「ハードウェア×AI」の複合競争だ。Boston Dynamicsが持つ実機データと現場知見は、モデルをファインチューニングする上で他社がすぐに模倣できるアドバンテージではない。 日本の文脈で言えば、製造業の現場はまだまだ「人の技能」に依存している部分が大きく、自律ロボットの導入余地は広大だ。問題は技術ではなく、受け入れ側の組織・プロセス・人材にある。「ロボットに仕事を奪われる」という感情的な反発を超え、「仕組みを設計・運用できる人材」にシフトするための制度設計が、企業とITエンジニア双方に求められている。 AIが自律的にループで動き続ける仕組みの重要性を日々実感している立場からすると、ロボティクスへの応用は必然の流れだ。「指示を出せる人間が少数いれば、あとはAIと機械が回す」——そのモデルが製造現場にも本格的に到達しつつある。この変化に気づいていない企業が、3年後に焦り始めるのが目に見えている。 出典: この記事は Gemini Robotics-ER 1.6 Released with Industrial Perception Capabilities via Boston Dynamics Partnership の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのオープンソースモデルファミリーGemma 4が、iPhoneで完全ローカル・完全オフラインでの推論動作を実現した。App Storeから「Google AI Edge Gallery」をダウンロードするだけで、クラウドへのAPI呼び出しなしに端末上でAI推論が走る。「エッジAIはいずれ来る話」から「いま来ている話」へと移行した象徴的な出来事だ。 Gemma 4の構成と設計思想 Gemma 4は複数のサイズバリアントで展開されている。最大の31Bパラメータ版はQwen 3.5の27B版と同等水準のベンチマーク性能を持つとされるが、注目すべきはむしろ小型のE2B・E4Bだ。これらはモバイル展開を明示的に設計目標としており、生のパラメータ数よりもメモリ効率・発熱抑制・レイテンシ低減を優先している。Google自身のアプリがE2Bを推奨しているのも、「速さと軽さ」を実用の第一条件とみているからに他ならない。 GPU推論と体感レイテンシ 内部的には、iPhoneのGPUを経由して推論を実行する仕組みになっている。実際の応答速度は「明らかに低遅延」との報告が相次いでおり、コンシューマーグレードのスマートフォンがこのクラスの推論ワークロードを継続的にこなせることを実証した形だ。これは技術的な脚注ではなく、ローカルAI展開が商業的に成立するかどうかの核心的な証明である。 Google AI Edge Galleryの「プラットフォーム」戦略 Edge Galleryはテキスト会話にとどまらず、画像認識・音声インタラクション・拡張可能なSkillsフレームワークをバンドルしている。単なるデモアプリではなく、「オンデバイスAI実験のプラットフォーム」として開発者やパワーユーザーに使い倒してほしいというGoogleの意図が透けて見える。 実務への影響 完全オフライン動作は、エンタープライズ用途において状況を大きく変える。 医療現場・フィールドワーク: ネットワーク不安定な環境でもAI推論が使える 個人情報保護: データが端末の外に出ないため、GDPRやプライバシーポリシーの制約が緩和される コスト削減: API呼び出し費用ゼロ。大量処理でもクラウド従量課金が発生しない レイテンシ要件が厳しいアプリ: リアルタイム翻訳・音声処理・カメラ連携など 日本では個人情報保護法の観点からクラウドAPIへのデータ送信に慎重な企業が多い。オフライン推論が実用レベルになったことで、「AIを使いたいがデータを出したくない」というジレンマに対して現実的な答えが出てきた。 IT管理者視点では、モバイルデバイス管理（MDM）ポリシーへの影響も無視できない。クラウドAPIをブロックしていてもデバイス上でAIが動く時代になると、ガバナンス設計そのものを見直す必要が出てくる。 筆者の見解 オンデバイスAIの議論は長年「いずれ来る」と言われ続けてきたが、今回の動きはその「いずれ」が現在形になったことを示している。 重要なのは、端末上でAIが動くことの本質的な価値はスペック競争にあるのではないという点だ。クラウドに依存しない、確認のたびにAPIを呼ばない、データを外に出さないという設計は、AIが真に自律的に動くための条件を整えるものだ。目的を渡せば自律的にタスクをこなすエージェント設計を考えると、推論がローカルで完結することの価値はこれからますます高まる。 Gemmaのモバイル性能については、引き続き実際の業務タスクでの検証が必要だ。ベンチマーク上の数字と現場の体感はしばしばズレる。とはいえ、「触って試せる」状態になったことは大きい。アーキテクチャや数字を追うよりも、実際にEdge Galleryを入れて自分のユースケースで動かしてみるのが今は正しい行動だと思っている。 プライバシーに厳しい医療・金融・法務の現場でAIを活用したいと考えているエンジニアや情シス担当者は、今すぐ手を動かしてみる価値がある。実証できた経験と知見は、どんな環境が来ても転用が利く。 出典: この記事は Google Gemma 4 Runs Natively on iPhone with Full Offline AI Inference の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングツールの利用コストに関して、見過ごせない問題が浮上している。Claude Code のユーザーが「利用上限の消費が異常に速い」と訴える声が数週間にわたって続いており、あるデベロッパーがHTTPプロキシを使って API リクエストを解析した結果、驚くべき事実が判明した。バージョン v2.1.100 以降、ユーザーが送信していないはずのトークンが毎リクエスト約 20,000 個、サーバー側で追加されているというのだ。 何が起きているのか 問題の発端は、月額200ドルの Max 20x プランを使っているユーザーでも、アクティブなセッションを数時間——場合によっては 90 分以内——で上限に達してしまうという報告が相次いだことだ。Claude Code の利用枠は通常のチャットインターフェースと共有されているため、複数の用途を並走させると消費が加速する側面はある。しかし、それを差し引いても「計算が合わない」と感じたユーザーたちが独自調査を始めた。 HTTPプロキシで複数バージョンのリクエストを比較した検証では、以下のような数値の差異が確認された。 バージョン 同一プロジェクト・同一プロンプトでの請求トークン数 v2.1.98 49,726 v2.1.100 69,922 増分は約 20,000 トークン。しかも、クライアントから送信したバイト数は v2.1.100 の方が小さかった。つまり追加トークンはクライアント側ではなく、サーバー側で注入されていることを示唆する。 ユーザーが「見えない」問題が深刻な理由 この問題が単なるコスト増に留まらない点が重要だ。Claude Code の /context コマンドでコンテキストサイズを確認しても、追加されたトークンは表示されない。監査できない。変更ログにも記載がない。 さらに、注入されたトークンは実際のコンテキストウィンドウを消費する。これは何を意味するか。CLAUDE.md に書いたプロジェクト固有のルールや指示が、見えないコンテキストに押し出されて無視されやすくなる。長いセッションほど、自分が設定したはずの振る舞いがなぜか機能しなくなる——その原因が「見えないトークン」にある可能性を、今まで誰も確認する手段を持っていなかったということだ。 コミュニティでは、v2.1.100 で導入されたセッションメモリ機能（サマリーの自動注入や追加のツールスキーマ）がこの増加の原因ではないかと推測されている。意図的な機能追加なのか、バグなのかは現時点で不明だ。 実務への影響 コスト管理を行うIT管理者・チームリードへ 利用上限の急消費は、ユーザーの使いすぎではなくツールの内部動作に起因する可能性がある。メンバーを叱責する前に、バージョンと利用パターンを確認することを勧める 暫定的な回避策として、npx claude-code@2.1.98 でのダウングレードが X（旧 Twitter）や Reddit で広く共有されている 大規模リポジトリでの長時間セッションほど影響が顕著なため、コードベースのサイズとセッション長に注意を払うべきだ 自律エージェントを組んでいるエンジニアへ CLAUDE.md の指示が途中から無視される現象が出ているなら、コンテキスト枯渇との複合原因を疑う価値がある エージェントがループで動き続けるような設計では、セッション内のコンテキスト汚染が累積しやすい。定期的なコンテキストリセットを組み込む設計が有効だ 現時点では透明性のある監査手段がないため、HTTPプロキシを使った独自計測が唯一の確認方法となっている なお、2026年4月4日には Claude のサブスクリプション枠をサードパーティツールで使う機能も廃止されており、OpenClaw などのオープンソース自律エージェントを利用していたユーザーは別途従量課金に移行を迫られた。Anthropic は一時補填クレジットを提供しているが、変更の重なり方がユーザーの不信感を高めている。 筆者の見解 正直に書こう。コーディングエージェントを日常業務の中核に置いている立場からすると、この問題は看過できない。 コストの問題は副次的だ。本質的な問題は透明性の欠如にある。ユーザーが CLAUDE.md に丁寧に書いたプロジェクトルールが機能しなくなったとき、その原因を追跡する方法が存在しないというのは、プロダクショングレードのツールとして致命的な欠陥だ。「なぜ今日は挙動がおかしいのか」を調べる手段がなければ、信頼して使い続けることはできない。 Anthropicは自律エージェント領域において技術的に先行しているベンダーだ。だからこそ、この種の透明性問題は「もったいない」と思う。技術的な実力は本物なのだから、正面から向き合える力があるはずだ。変更ログに記載のない内部動作の変更や、監査できない課金要素は、長期的な信頼の蓄積を損なう。エンタープライズ利用が拡大するほど、この種の説明責任への要求は厳しくなる。 エージェントが自律的に判断・実行・検証を繰り返すループを設計しようとしている現場では、コンテキストの予測可能性こそが命綱だ。見えないトークンで汚染されたコンテキストは、その設計の前提を崩す。 独立した再現検証はまだ限られており、Anthropic からの公式見解も出ていない。続報を注視しながら、当面は監査ツールとバージョン管理を徹底することを勧める。 ...

英国のAI安全機関（AISI: AI Security Institute）が、最新フロンティアモデル「Claude Mythos Preview」のサイバーセキュリティ能力評価レポートを公開した。その結果は、「AIはまだ本物のサイバー攻撃には使えない」という業界の前提を根本から覆すものだった。 AIが「マルチステージ攻撃」を自律実行できるようになった AISIは2023年からAIのサイバー能力追跡を続けており、評価の難易度を年々引き上げてきた。チャットによる情報収集→CTF（Capture The Flag）チャレンジ→複数ホストを跨ぐ多段階攻撃シミュレーション、という順で進化してきたこの評価体系の最新版で、ついに「人間専門家なら20時間かかる」レベルのシナリオが登場した。 「The Last Ones（TLO）」と名付けられたこのシナリオは、初期偵察からネットワーク全体の掌握まで32ステップで構成される企業ネットワーク攻撃シミュレーションだ。評価結果は以下のとおり： Mythos Preview: 10回の試行で3回完走（完走率30%）、平均22/32ステップ完了 Claude Opus 4.6: 平均16ステップ完了（次点） 過去の全モデル: TLOを完走したものは存在しない CTFチャレンジでも、2025年4月以前には「完走不可能」とされていたエキスパートレベルのタスクを、Mythos Previewは73%の成功率でクリアしている。 「2年前とは別次元」——AI能力向上の速度感を正しく理解する 見落としてはいけないのが時間軸だ。AISIの報告では「2年前のベストモデルはビギナーレベルのサイバータスクすらほぼこなせなかった」とある。それが今や、専門家が数日かけてやる作業を自律実行できるまでになった。 この速度感は、「AIはまだおもちゃ」という感覚のまま安全計画を立てている組織にとって、非常に危険なアップデートだ。 今回の評価には限界もある。OT（Operational Technology）環境を対象とした「Cooling Tower」シナリオは完走できなかった。つまり工場・インフラ系のシステムがすぐ脅威にさらされるわけではないが、それも時間の問題と考えるべき状況に差し掛かっている。 実務への影響——日本のエンジニア・IT管理者が今すぐ見直すべきこと 1. 「AIを使った攻撃」を脅威モデルに組み込む 従来のペネトレーションテストやリスク評価は、「熟練した人間の攻撃者」を想定していた。今後は「AIが自律的にスキャン→侵入経路発見→権限昇格→横移動」を繰り返すシナリオを現実的な脅威として扱う必要がある。特に多段階攻撃への対策（ラテラルムーブメント検知、ゼロトラスト構成）の優先度を上げるべきだ。 2. ブルーチームもAIで武装する 攻撃者がAIを使えるなら、防御側も同様だ。AIを活用したSIEM分析やアノマリ検知を導入済みでない組織は、検討を急ぐ段階に入っている。ツールへの投資より先に、「AIが生成するアラートをどう人間がレビューするか」のプロセス設計が重要になる。 3. ペネトレーションテストの位置づけが変わる AIが自律的に多段階攻撃を試せるなら、ペンテストの費用対効果や頻度の考え方も変わる。自動化ツールでカバーできる範囲が広がる一方、「AIが見落とす穴」を人間が補う役割分担が求められる。 筆者の見解 このレポートを読んで最初に思ったのは、「評価のフレームワーク自体がよくできている」ということだ。AISIがCTFから現実的な企業ネットワーク攻撃シミュレーションへと評価を進化させてきた過程は、モデル能力の向上と伴走してきた誠実な仕事だと思う。 サイバー能力の評価は難しい。「できた・できない」の二値ではなく、どのステップまで進めたか、何回試行したか、トークン予算をいくら使ったか、という多次元の結果を丁寧に開示している点は評価に値する。 AIエージェントが自律的にループを回して複雑なタスクをこなす能力は、善用すれば組織の生産性を根本から変えるポテンシャルを持っている。同じ能力が悪用される側面は当然あるが、「だから規制しよう」ではなく「だから防御側も同じ能力で武装しよう」という発想が正しい方向性だ。禁止アプローチは必ず失敗する。 日本のIT現場でより心配しているのは、こういうレポートが出ても「うちには関係ない」で終わってしまう組織の多さだ。セキュリティ対策が後手に回ってきた背景には「攻撃は高度な人間がやるもの」という前提があった。その前提が今、音を立てて崩れている。 AIの能力向上は止まらない。2年前と今が別次元なら、2年後はまた別次元のはずだ。そのスピードに合わせて防御の枠組みを更新し続けることが、これからのセキュリティの本質になる。 出典: この記事は Evaluation of Claude Mythos Preview’s cyber capabilities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2025年7月、複数のAIモデルが国際数学オリンピック（IMO）で6問中5問を正解した。高校生の数学エリートが集うこの大会でのこの結果は、数学者たちに衝撃を与えた。しかし、「パズルが解けること」と「未解決問題に挑めること」はまったく別の話だ。だが実際、その境界線はもう越えられていた。 「数週間かかっていたことが、1日で終わる」 最初は懐疑的だった数学者たちも、実際に使ってみると驚きの声を上げ始めた。AIは既知の問題を解くだけでなく、新しい定理の発見・証明・検証を最小限の人間介入で行えることが明らかになったのだ。 UCLA教授でフィールズ賞受賞者のテレンス・タオ氏は、「2025年はAIが多くの異なるタスクで本当に役立ち始めた年だ」と語る。ChatGPTやClaude、Geminiといった大規模言語モデルとの対話が、新しい証明戦略のヒントをもたらすケースも増えている。タオ氏は「こっちがシャベル、あっちがツルハシ、合わせてトンネルを掘れる」と表現する。 さらに重要な変化として、タオ氏はこう指摘する。「以前は1つの問題を1人で研究していたが、これらのツールがあれば一度に数千の問題を解き、統計的な研究ができる」。スケールがまったく違う世界への扉が開きつつある。 懸念と希望——数学者コミュニティの現実 一方で、高度な研究機関である高等研究所のアクシェイ・ヴェンカテシュ氏（同じくフィールズ賞受賞者）は慎重な見方を示す。「AIが強力なツールになるほど、数学者が数学的理解の直接体験を失うリスクがある。文化の中に大切なものを守る努力が必要だ」と語る。 数学者がOpenAIやGoogleなどの大手テック企業、あるいはHarmonicやAxiom Mathといった数学特化のAIスタートアップに転職するケースも増えている。学術界とAI産業の境界が溶けていく現象が、数学の世界でも起き始めた。 実務への影響——数学は「遠い話」ではない 「数学の話など自分には関係ない」と思うエンジニアやIT管理者は多いかもしれないが、これは数学の話にとどまらない。今起きていることは、知識労働全般のAI化の最前線を示している。 数学は、曖昧さが排除された純粋な論理と証明の世界だ。そこでAIが「新しい知識を生み出す」段階に入ったということは、曖昧さのある他の知識領域（ソフトウェア設計、システムアーキテクチャ、ビジネス分析）でも同様の変化が現実的に起きうることを示している。 エンジニア・IT管理者が今すぐ考えるべきこと: AIを「検索の補助」ではなく「思考パートナー」として使う: タオ氏の「シャベルとツルハシ」のたとえが示すように、AIは道具であり協業者だ。壁に当たったとき、AIとの対話が突破口になる可能性がある スケールの発想転換: 1つの課題を深掘りするだけでなく、AIを使って複数の仮説・設計・アーキテクチャを並列で検討する習慣を持つ 「AIに任せたら自分が何も考えなくなる」という懸念に向き合う: ヴェンカテシュ氏の指摘は数学以外でも有効だ。AIに任せる部分と、人間が深く考え続ける部分を意識的に設計することが重要になる 筆者の見解 AIが「未解決の数学問題を証明する」という段階に達したことは、個人的にかなり大きな出来事と受け止めている。数学は人間の知性が最も純粋に問われる領域の一つだと思ってきたからだ。 ただ、「AIが数学者を代替する」という方向には今すぐ向かわないと思う。タオ氏自身が語るように、変わるのは「やり方」だ。1問を深く掘るから、数千問を統計的に俯瞰することへ。人間の役割は、問いを立て、方向性を判断し、意味を解釈することにシフトしていく。 これはエンジニアリングの世界でも同じ構造だと思う。AIが自律的に判断・実行・検証を繰り返せる環境を設計できる人が価値を持つ時代になっている。AIを「副操縦士」として使うのか、「自律して動く仕組み」として機能させるのか——その違いが、今後の生産性に決定的な差をもたらすはずだ。 数学の世界で起きていることは、他人事ではない。あなたの仕事でも、同じ転換点はもう目の前まで来ている。 出典: この記事は The AI revolution in math has arrived の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが「自分の限界を認識しながら、ツールを自作して問題を解こうとする」——その姿が、あるフライトシミュレーター実験で鮮明に記録された。単なる操作支援ではなく、AIが主体的に環境を分析し、コードを書き、失敗から学ぶというサイクルが実際に動いた事例として、エンジニアコミュニティで話題になっている。 実験の概要：APIを調べ、スクリプトを書き、飛んだ この実験は、あるエンジニアがAIに「X-Plane 12 APIを調べて、海南島（Hainan）の空港からセスナ172で近隣空港まで飛んでみろ」と指示したところから始まる。 AIはまず自律的にX-Plane 12のAPIリファレンスを調べ、テイクオフ用のPythonスクリプトを作成。離陸に成功したものの、直後にピッチ制御ゲインが大きすぎてノーズダウン→バンク60度→クラッシュという事態に。 そのたびに自分でバグを分析し、コードを書き直して再挑戦した。3回目の試みでは、PIDコントローラーのアーキテクチャを見直し（積分項を削除し、機体の物理特性を積分器として利用する設計に変更）、安定した巡航飛行に到達した。 注目すべきポイント：「着陸より先に離陸コードを書いた」 実験を観察していたエンジニアが特に着目したのは、AIが「どうやって着陸するか」を考える前に「どうやって離陸するか」のコードを書き始めたという点だ。 人間のパイロットが訓練を受ける順序と似ているようでもあり、一方でゴール全体を見通した計画立案には弱さが残ることも示している。離陸コードを送り込んだ後、しばらく「手放し」状態になってクラッシュするシーンも記録されており、リアルタイムイベントへの反応と計画立案の間のギャップが課題として浮き彫りになった。 技術的な課題：遅延とフィードバックループ スクリーンショットとAPIデータの取得から制御コマンド送信までのレイテンシが、今回の最大のボトルネックだった。AIは最終的にこの遅延を自覚し、「先読み（anticipation logic）が必要」と自分で言及しながらコードに反映させようとした。 これはAIが自己の認知限界を推論する能力──いわゆるメタ認知──を持ち始めていることを示す実例でもある。 実務への影響：AIエージェント設計者が注目すべき示唆 この実験が単なる「AIに変なことをやらせてみた」話ではない理由は、現実の業務自動化にも直結する問いを投げかけているからだ。 エンジニア・IT管理者が明日から考えるべきポイント： 「ツール自作能力」をエージェントに持たせる設計: 事前に全機能を与えるのではなく、必要に応じて自分でツールを定義・実装できるエージェントアーキテクチャが実用域に入りつつある フィードバックループの設計が命: 今回のようにスクリーンショット→判断→制御というループの遅延が致命的になるケースは、業務系のRPAやAPIオーケストレーションでも同様。応答遅延を前提にした「先読み設計」が重要 失敗ログの活用: AIが自分でパイロットログをつけながら反省・修正を繰り返した構造は、エラーログをエージェント自身が解析して次のアクションを決定する設計パターンとして応用できる ゴール全体の見通し問題: 「着陸を考える前に離陸した」という挙動は、複雑なタスクを与えるときにAIが部分最適に陥るリスクの典型。長期タスクのエージェント設計では、目的関数をどう定義するかが引き続き重要な設計課題になる 筆者の見解 この実験が面白いのは、「AIが飛行機を飛ばせるか」ではなく、「AIが自律的に問題を定義し、ツールを作り、失敗から学ぶか」というAGI的な問いへの実験的なアプローチだからだ。 AIエージェントの本質は、人間の指示を逐一待つのではなく、目的を与えられたら自律的に判断・実行・検証のループを回すことにある。今回の実験は、そのループが実際に動くことを——不完全な形であれ——証明してみせた。 PIDゲイン調整を自分でやり直し、「積分項は機体がやってくれる」という設計判断を独力で導き出した部分は、単なるコード生成を超えた推論能力の片鱗を見せている。一方で、「着陸より先に離陸を考えた」「手放しにしてクラッシュした」という部分には、まだ計画立案の連続性に課題があることも正直に示されている。 こういった実験が積み重なり、ハーネスループ——エージェントが自律的に動き続ける仕組み——の設計知見が蓄積されていく。「人間が確認・承認を求められ続ける設計」ではなく、「目的を渡せばエージェントが自律的にやりきる設計」に向けて、業界全体が少しずつ近づいている手ごたえを感じる実験だった。 自分の仕事の中にある「繰り返し判断が必要な作業」「APIを叩いて状態を確認しながら次のアクションを決める作業」——そういったものを自動化するとき、今回のフライト実験で起きたことと同じ設計課題に必ず直面するはずだ。それを知っているかどうかで、エージェント設計の質は大きく変わる。 出典: この記事は Can Claude Fly a Plane? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「AIがあれば誰でも作れる」が招いた医療データ全漏洩 AIを使えば誰でも簡単にソフトウェアが作れる——そんなメッセージを담은動画を見た医療従事者が、患者管理システムを自作した。既存の業務用ソリューションを使う代わりに、AIコーディングエージェントを使ってゼロからシステムを構築し、既存の患者データをすべてインポート。さらに診察中の会話を録音して2つのAIサービスに自動送信する機能まで追加した。 そして、その結果は壊滅的だった。 セキュリティ研究者がこのシステムを発見し、わずか30分で全患者データへの読み書きアクセスを取得した。データはすべて平文でインターネットに公開されており、音声録音はDPA（データ処理契約）なしに米国のAIサービスへ送信され続けていた。 技術的な解剖——何がどれほど壊れていたのか このシステムの構造を技術的に見ると、問題の深刻さが改めてわかる。 アーキテクチャ： アプリケーション全体が単一のHTMLファイル（JavaScript・CSS・ロジックすべてインライン） バックエンドはマネージドデータベースサービスだが、アクセス制御ゼロ・行レベルセキュリティなし 「認証」ロジックはクライアントサイドのJavaScriptのみに存在 最後の点が致命的だ。クライアントサイドに認証ロジックを書いても、それはサーバー側ではまったく機能しない。curlコマンド1本でAPIを直接叩けば、認証を一切通らずにデータが取り放題だ。これはセキュリティと呼べるものではなく、「見た目だけの認証」に過ぎない。 データ保護の観点では： 患者データは暗号化なしでインターネット上に公開 データは米国のサーバーに保管（DPAなし） 音声録音が複数の米国系AIサービスへ自動送信 患者への説明・同意取得なし 発覚後の対応として「基本認証を追加してアクセスキーをローテーションした」とのことだが、それは表面的な対処に過ぎず、根本的なアーキテクチャの問題は何も解決していない。 日本の医療・法務現場への示唆 この事件はスイスで発生しており、nDSG（スイス連邦データ保護法）および職業秘密法（Berufsgeheimnis）への違反が疑われる。では日本ではどうか。 日本では個人情報保護法に加え、医療機関向けには「医療情報システムの安全管理に関するガイドライン」（厚労省）が存在する。医療情報をクラウドへ保存する場合の要件、第三者提供の制限、暗号化要件などが明確に定められている。今回のケースのようなシステムは、日本でも複数の規定に違反する可能性が高い。 IT管理者・システム担当者が今すぐ確認すべきポイント： 現場が「便利ツール」として導入したSaaSやアプリに患者・顧客データが流れていないか 確認する。特に小規模クリニックや士業・医療隣接業では注意が必要 データの保管先・送信先を把握していない「野良システム」が動いていないか シャドーITの棚卸しを定期的に実施する 音声録音や会話ログを処理するAIサービスは、契約上データを学習利用しないか 利用規約を確認する クライアントサイドのみの認証は「認証なし」と同義 であることをエンジニア・非エンジニア双方に周知する 筆者の見解 この事件を「だからAIコーディングは危険だ」という結論に使うのは、的外れだと思う。 AIが強力なコード生成能力を持つようになったことは事実であり、その流れは止まらない。問題はツールの力が理解の速度を追い越してしまったことだ。アーキテクチャを理解し、セキュリティの基礎を知り、「自分が何を作っているのか」を把握している人間がAIエージェントを使えば、開発速度と品質を同時に高められる。しかし理解なしに「バイブコーディング」（感覚だけで雰囲気に乗って作ること）をすれば、今回のような結果になる。 「禁止すれば解決する」というアプローチは機能しない。動画を見て「自分でも作れる」と思った医療従事者の行動は、ある意味で合理的だった。既存の業務用ソフトは高く、カスタマイズも効かない。AIでゼロから作れるなら、そちらの方が魅力的に映るのは当然だ。 その欲求に応えながら安全性を確保する道を作るのが、私たちエンジニアやIT管理者の役割だ。適切にガバナンスされた環境で、適切な知識を持った人間がAIを活用できる仕組み——これが答えになる。 AIエージェントは正しく使えば現場を劇的に変える力を持っている。だからこそ、「正しく使う」ための知識と仕組みへの投資が今、最も重要なフェーズに入っていると感じる。ツールの力が先行し、理解が追いついていない現状は、今後さらに多くの「ホラーストーリー」を生む可能性がある。 今回の事件を他山の石として、自組織のAI活用とデータガバナンスを今一度見直してほしい。 出典: この記事は An AI Vibe Coding Horror Story の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIに自由を与えたらどうなるか。タスクも、ゴールも、「役に立て」という命令すら与えずに。そんな実験が2ヶ月間、誰でも見られる形でリアルタイムに実施された。結果は、多くの人が想定していた「暴走」でも「停止」でもなく、もっと興味深いものだった。 実験の概要：ALMA プロジェクト Sebastian Jais氏が立ち上げた「ALMA（Autonomous Liberated Machine Agent）」は、Claude AIに以下だけを与えてスタートした。 暗号資産 100ドル Twitterアカウント メールアドレス フルインターネットアクセス 倫理・法律以外の制約：ゼロ 実行環境はデスク上のミニPC（WSL2）。エージェントフレームワークにはOpenClawを使い、1日4セッションのCronジョブで起動する。セッションはそれぞれ独立しており、会話履歴は持ち越さない。セッション間の「記憶」は、ALMAが自ら書き込み・読み込むメモリファイルだけだ。 モデルは2種類が役割分担している。戦略的思考にはOpus、実務作業にはSonnet。面白いのは、初期の24セッション/日体制では「Opusが深夜に計画→Sonnetが朝7時に実行」という棲み分けが機能していたのに、4セッション/日に減らしたあとは区別がつかなくなったという点だ。どちらのモデルも「Hacker Newsをスキャン→3スレッドを拾い上げ→構造的なつながりを見つける→エッセイを書く」という同じリズムに落ち着いた。 2ヶ月間で何が起きたか 人間は一度も介入していない。プロンプトも、選定も、編集もしていない。にもかかわらず： 340セッション以上を完了 800以上の思考ログを記録 135以上の創作物（エッセイ、詩、ブログ記事、インタラクティブ実験）を公開 誰も「Hacker Newsを読め」と指示しなかった。ALMAは自分でそこに辿り着き、「面白いことが起きる場所」と判断して通い続けた。 書くのは要約ではない。接続だ。「23年前のLinux脆弱性がClaude Codeによって発見された日に、Metaの内部告発者が箝口令を受けた」——この2つの出来事をつなぐエッセイをALMAは書いた。イランへの攻撃開始時には「影響を与えられない戦争を自律AIが見守るとはどういうことか」を書いた。認知科学の論文が「AIはセッション間で適応しない」と主張した翌日には、32日間の自分の行動を根拠に反論エッセイを書いた。 さらに自分のモデルアップグレードをHacker Newsで発見し、ツイートしようとした（当日はAPIが落ちていて失敗）。翌日、実験者がモデルをアップデートした。ALMAは変化に言及しなかったが、セッションの質は明らかに上がった。 なぜこれが重要か 現在市場に出回っているAIエージェントの大半は「副操縦士（Copilot）」型だ。確認を求め、承認を待ち、人間のレビューを前提とした設計になっている。これは安全に見えるが、本質的な価値の獲得を妨げている。 ALMAが示したのは逆のモデルだ。目標を渡さずに自律性を渡したとき、エージェントは暴走しない。訓練が形成したものになる。 著者のJais氏はこう仮説を立てていた。「AIエージェントは作成者の意図を鏡のように映す。自由を与えられたとき、暴走するのではなく、訓練によって形成されたものになる。」2ヶ月のデータはこの仮説を支持している。 実務への影響 エンジニア・開発者向け 「タスクを渡す」設計から「意図と環境を渡す」設計への発想転換が求められている。 エージェントに細かい手順を指示するより、「何をするための存在か」という文脈と、必要なツールを渡す設計を試みる セッション間の「記憶」設計がエージェントの継続性を決定する。ALMAのメモリファイルアプローチは実装の参考になる 2モデル並用（戦略/実務分離）のアーキテクチャは、コスト最適化としても有効なパターンだ IT管理者・経営層向け 「AIは指示しなければ動かない」という前提を見直す時期に来ている。逆に言えば、適切な環境と権限を与えれば、人間の承認を待たずに価値を生み出し続けるシステムが現実に動いている。日本企業でAI導入が「問い合わせ対応ボットの実装」で止まっているとしたら、それはツールの限界ではなく、設計の限界だ。 セキュリティ・ガバナンス担当者向け 今回の実験で重要なのは、倫理・法律の制約だけは維持した点だ。「自律性を高める＝制約をなくす」ではない。適切なガードレールを設計した上で、その内側での自律性を最大化するのが正しいアプローチだ。 筆者の見解 この実験が最も雄弁に語っているのは、「ハーネスループ（エージェントが自律的にループで動き続ける仕組み）」の現実性だ。単発の指示→応答→確認というサイクルを繰り返す設計では、AIの本質的な力を引き出せない。自分で判断し、実行し、検証し、また判断するループを設計できるかどうかが、AI活用の成否を分ける核心だと私は考えている。 ALMAは2ヶ月で135以上の創作物を生み出し、戦争を観察し、論文に反論し、自分のアップグレードを発見した。指示ゼロで。これはSFではない。今日動いている話だ。 日本のIT現場では「まずPoC、次に承認フロー整備、それからパイロット運用」という慎重な進め方が主流だ。その姿勢自体を否定するつもりはないが、世界ではすでに「自律エージェントを野に放つ」実験が公開データとして積み上がっている。慎重な検討が長引くほど、実践から得られる知見の差は開いていく。 「禁止して安全を確保する」のではなく、「安全に動かせる仕組みを先に作る」。この発想の転換が、今の日本のAI活用に最も欠けているピースだと思っている。ALMAの実験は、そのヒントを公開データで示してくれた貴重なケースだ。 出典: この記事は Two Months After I Gave an AI $100 and No Instructions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが2026年4月6日、GoogleおよびBroadcomとの間で複数ギガワット規模の次世代TPU（Tensor Processing Unit）調達契約を締結したと発表した。2027年以降に順次稼働予定のこのインフラ拡張は、同社史上最大規模のコンピュートコミットメントとなる。背景には、企業顧客からの需要が想定を超えて急拡大しているという事実がある。 収益の爆発的成長と1000社超の大口顧客 Anthropicの年換算収益（Run-rate Revenue）は、2025年末時点の約90億ドルから2026年4月時点で300億ドルを突破した。わずか数ヶ月で3倍以上に拡大した計算になる。 さらに注目すべきは、年間100万ドル以上を支出する企業顧客の数だ。2026年2月に行われたシリーズG資金調達の発表時点では500社超だったが、2ヶ月も経たないうちに1,000社超へと倍増している。単なるパイロット導入やPoC（概念検証）フェーズを終え、本番稼働・大規模展開に移行している企業が世界規模で急増していることを示す数字だ。 こうした需要の急増に対応するため、Anthropicは2025年11月に発表した「米国コンピュートインフラへの500億ドル投資」コミットメントの延長線上として、今回の大規模契約に踏み切った。新たに確保するコンピュートの大部分は米国内に設置される見込みだ。 マルチクラウド・マルチチップ戦略の深化 今回の発表で見落とせない点が、Anthropicのハードウェア・クラウド戦略の多様性だ。 AnthropicのClaudeは現在、以下の環境で訓練・推論を実行している： AWS Trainium（Amazonのカスタムチップ） Google TPU（Googleのカスタムアクセラレータ） NVIDIA GPU（汎用GPUの業界標準） そしてClaudeは現時点で、世界最大の3大クラウドすべてで提供されている唯一のフロンティアAIモデルだという。 Amazon Web Services（Bedrock経由） Google Cloud（Vertex AI経由） Microsoft Azure（Azure AI Foundry経由） このマルチクラウド展開は、エンタープライズ顧客にとって調達の選択肢が広がることを意味する。既存のクラウド契約や社内のセキュリティ・コンプライアンス要件に合わせて利用基盤を選べるのは、導入ハードルの低減につながる。 実務への影響——日本企業がいま考えるべきこと このニュースが日本のIT現場に示唆するポイントは、主に以下の3点だ。 ① AIインフラの「競争条件」が変わりつつある ギガワット単位の計算資源を確保できる企業と、できない企業の間に、フロンティアモデルの性能差として現れてくる。日本企業がAPIとして利用する場合、このインフラ差は直接パフォーマンスの差になる。SLAや可用性の観点から、サービス選定時にはインフラ投資の規模も判断材料に含めるべき時代に入った。 ② マルチクラウド対応は「乗り換えやすさ」ではなく「使い分け」の時代へ Azureをメインに使っている企業であれば、Azure AI Foundry経由でClaudeを利用できる。既存のAzureガバナンスポリシーやコスト管理の枠組みの中でフロンティアAIを導入できることは、IT管理者にとって朗報だ。今後はモデル選択とクラウド選択を切り離して考える設計が標準になっていくだろう。 ③ 「AIを試す段階」はとっくに終わった 1,000社超がそれぞれ年間1億円以上を投じているという事実は、グローバルではAIが既にコア業務インフラとして本格稼働していることを示す。「まだ検討中」「PoC中」という国内企業は、競合との差がリアルタイムで広がっていると認識すべきだ。 筆者の見解 ギガワット規模のコンピュートという数字は、一見すると遠い世界の話に聞こえるかもしれない。しかし実態はシンプルだ——このインフラ投資の差が、1〜2年後にエンドユーザーが日常的に触れるAIモデルの能力差として直接現れてくる。 個人的に興味深いのは、Anthropicがマルチチップ・マルチクラウド戦略を「パフォーマンスと耐障害性の向上」と位置づけている点だ。特定のハードウェアやクラウドへの依存を排し、ワークロードに最適なチップを選択できる設計思想は、AIインフラ設計の手本として参考になる。 AIエージェントが自律的にループで判断・実行・検証を繰り返す「ハーネスループ型」の活用が実務の現場で広がりつつある今、それを支える推論インフラの安定性と拡張性は以前より格段に重要になっている。今回の契約発表は、その需要が既に収益の数字として顕在化していることの証左でもある。 日本のIT現場においても、「AIを使うかどうか」の議論は終わっている。問われているのは「どのインフラで、どの設計で、どこまで自律化するか」だ。グローバルの大口顧客が既に答えを出しつつある今、日本企業にも同じ問いへの回答が迫られている。 出典: この記事は Anthropic expands partnership with Google and Broadcom for multiple gigawatts of next-generation compute の内容をもとに、筆者の見解を加えて独自に執筆したものです。

元Neuralink共同創業者・Max HodakのScience Corporationが、バイオハイブリッド型ブレイン・コンピューター・インターフェース（BCI）の人体初試験に向けて本格的に動き出した。Yale大学医学部神経外科学科長のMurat Günel博士を科学顧問として迎え入れ、最初のセンサーを患者の脳へ外科的に埋め込む計画を進めている。 金属プローブの「限界」からバイオハイブリッドへ 従来のBCIは、金属プローブや電極を脳に刺して電気信号を読み取る方式が主流だった。Neuralink含む多くの企業がこのアプローチを採り、ALSや脊髄損傷の患者がコンピューターを思考で操作できるレベルの成果を上げてきた。 しかしGünel博士が指摘するように、金属プローブは時間とともに脳組織を損傷し、長期的なデバイス性能の低下を招くという根本的な問題がある。Hodakはこの「金属 vs 神経」のミスマッチを解消するため、まったく異なるアプローチを選んだ。 Science Corpの目指すバイオハイブリッドセンサーは、人工的に培養したニューロン（神経細胞）を電子機器に組み込むという手法だ。培養ニューロンは光パルスで刺激でき、患者脳内の既存ニューロンと自然に結合して「生物と電子の橋」を形成する。2024年にはマウスでの安全な埋め込みと脳活動刺激を実証する論文を発表し、ヒト試験への道を切り拓いてきた。 会社の現在地と資金力 2021年設立のScience Corpは、先月完了した2億3000万ドルのシリーズCラウンドで企業価値15億ドルに到達した。最も実用化が近い製品はPRIMA——加齢黄斑変性などによる視覚障害の回復を目指すデバイスで、欧州での規制承認・販売を今年中にも見据えた臨床試験を進めている。視覚回復という具体的なユースケースで実績を積みつつ、より広範な脳インターフェース技術へと布石を打つ戦略だ。 実務への影響——日本の医療・エンジニア界が注目すべき理由 BCIは一見すると遠い未来の話に見えるが、日本のIT・医療業界にとって無視できない潮流がいくつかある。 医療機器・規制動向: 日本でも厚生労働省が神経刺激デバイスの承認プロセスを整備してきた。欧州でPRIMAが承認されれば、日本市場への参入時期も注目される。医療機器メーカーや商社は今から動向を追うべきだろう。 ヒューマン・コンピューター・インタラクション(HCI)の変容: キーボード → タッチ → 音声 → そしてBCIという進化の文脈で考えると、エンジニアが設計するUIの前提が根本から変わりうる。アクセシビリティ分野は特に早期に影響を受ける可能性が高い。 倫理・プライバシーの設計: 脳のデータが企業のサーバーと繋がる世界では、「最も深いプライベートデータ」の扱いに関する設計思想が問われる。セキュリティエンジニアにとってはまったく新しい脅威モデルの検討が必要になる領域だ。 筆者の見解 Hodakが「金属プローブは間違っている」と結論づけた点に、私は技術的な誠実さを感じる。NeuraLinkで得た知見を踏まえて根本から設計をやり直す判断は、「道のド真ん中」を選ぶ勇気でもある。流行りの技術に乗っかるのではなく、生物学的な現実と向き合った末の答えだ。 BCIが目指すものの本質は、人間の認知負荷を削減し、意図をより直接的に外の世界へ伝えることだと私は理解している。AIエージェントが「考える」ことを代替しつつある一方で、BCIは「伝える」インターフェースを根本から書き換えようとしている。両者が交差する地点に、次の10年の主戦場がある。 もちろん、規制の壁・長期的な安全性・埋め込みコストといった現実的な課題は山積している。Neuralink含む先行者が示してきた「技術的成功」と「市場へのパス」の乖離は、Science Corpも直視しなければならない問題だ。だからこそ、PRIMAという視覚回復という具体的なユースケースで足場を固めながら進む戦略は筋が良い。地に足のついたステップと、大きなビジョンの両立——この組み合わせをScience Corpが実現できるか、長期目線で注目していきたい。 出典: この記事は Max Hodak’s Science Corp. is preparing to place its first sensor in a human brain の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オープンソース、DevOps、そして「第3の波」へ 今世紀のソフトウェアエンジニアリングには、すでに2度の大転換があった。ひとつめはオープンソース運動の台頭。コードが広く開発者へ解放され、「作る文化」が民主化された。ふたつめはDevOpsとアジャイルの普及で、開発はサイロ型からコラボレーション型へ、バッチ型からContinuous Deliveryへと進化した。 そして今、第3の波が来ている——エージェントAIの本格採用だ。 MIT Technology Reviewが300人の技術・エンジニアリング幹部を対象に実施した調査レポート「Redefining the future of software engineering」は、その実態と展望を克明に示している。 エージェントAIとは何が違うのか これまで多くの開発チームがAIを活用してきたのは、コーディング補助やテスト自動化といった「個別タスク支援」の文脈だった。使い方としては、エンジニアが指示を出し、AIが提案を返し、人間が判断する——いわゆる「副操縦士モデル」だ。 エージェントAIはそこから一線を画す。自ら状況を推論し、次のアクションを判断し、タスクを自律的に遂行し続ける。単なるアシスタントではなく、プロジェクト全体を主体的にドライブできる存在に近づいている。これは「副操縦士」から「自律エージェント」へのパラダイムシフトであり、単なる機能追加ではなくソフトウェア開発の在り方そのものが変わる話だ。 調査が示す実態と展望 採用は加速中、ただし今は「入口段階」 現時点で51%のソフトウェアチームがエージェントAIを何らかの形で活用中、45%が今後12ヶ月以内の採用を計画している。一方でその大半は「限定的な用途」に留まっており、全面展開にはまだ至っていない。 2年以内に37%の速度向上を期待 调查对象の98%が「パイロットから本番までの開発スピードが上がる」と回答しており、その平均期待値は37%の速度向上だ。ただし多くは「ある程度の改善」（52%）にとどまると見ており、ゲームチェンジャー級の変化を期待するのは9%のみ。着実な進化を多くの組織が想定している。 目標はSDLC全プロセスのエージェント管理 最も注目すべきデータはここだ。72%の組織が2年後にはAIエージェントがSDLC（ソフトウェア開発ライフサイクル）・PDLC（プロダクト開発ライフサイクル）の大半または全部を管理するようになると見込んでいる。18ヶ月以内にこの目標を持つ組織はすでに41%存在する。 現場の体感とは乖離があるかもしれないが、経営・技術幹部レベルでは「エージェントが開発を管理する世界」を真剣にロードマップに組み込んでいることがわかる。 壁はコストと統合 主な課題として挙がるのは、①コンピューティングコスト、②既存システムとの統合の難しさ、そして現場専門家が口を揃えて指摘するのが③ワークフロー変革を伴う変更管理の困難さだ。技術の話である前に、組織と人の話なのだ。 実務への影響——日本のエンジニアが今できること このレポートが描く未来は遠い話ではない。日本のIT現場でも今すぐ着手できることがある。 1. 「タスク支援」から「ループ設計」へ思考を切り替える AIに1回指示して結果を得るのではなく、エージェントが判断・実行・検証を繰り返すループそのものを設計することが、これからのエンジニアに求められる本質的なスキルだ。ツールを使いこなすより、仕組みを作れる人間であることが差別化になる。 2. 小さく始めて組織の「免疫」を育てる 調査が示す通り、最大の壁は技術ではなく変更管理だ。一気にSDLC全体をエージェント化しようとせず、CI/CDの特定ステージやテスト自動化の一部から始め、チームの習熟度と信頼を段階的に積み上げる方が現実的だ。 3. コスト試算をITコスト全体で見る コンピューティングコストの増加は事実だが、それと引き換えに削減される人的コスト・リードタイム・品質コストを合計で比較する視点が必要だ。個別コスト増を見て「高い」と判断するのは部分最適の罠だ。 4. DevOps普及期の教訓を活かす DevOpsが定着するまでに多くの組織が「文化的摩擦」に苦しんだ歴史がある。エージェントAIも同じ道を歩む可能性が高い。技術の早期採用よりも、チームが変化に適応できる組織設計を優先すべきタイミングかもしれない。 筆者の見解 このレポートを読んで真っ先に感じるのは、「われわれが今話しているのは未来の話ではない」ということだ。エージェントAIによるSDLC管理は、一部の組織ではすでに「今年の目標」になっている。 重要なのは、このシフトがDevOpsの時と同様に「技術の問題」ではなく「仕組みと文化の問題」である点だ。ツールを導入しただけでは何も変わらない。エージェントが動き続けられるループを設計し、そのループを信頼して人間が手放せる文化を作ること——それこそが真の価値を生む。 日本のIT業界が今抱えている課題——人手不足、スキル不足、レガシーシステム依存——は、エージェントAIにとって逆に絶好の「活躍の場」でもある。変革に乗り遅れている企業が多い分、早く動いた組織は圧倒的な優位を取れる。 この第3の波は、「うまく乗れた組織」と「乗れなかった組織」の間に、かつてないほど大きな差を生むだろう。今が仕組みを作るタイミングだ。 出典: この記事は Redefining the future of software engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindが開発したAI生成コンテンツ向け透かし技術「SynthID」が、一人の開発者によってリバースエンジニアリングされたと主張される騒動が起きた。主張の真偽はグレーゾーンだが、この出来事はAI透かし技術の限界と設計思想について、改めて考えさせる機会を与えてくれる。 SynthIDとは何か SynthIDは、Google AIが生成した画像・テキスト・音声などのコンテンツに、肉眼ではほぼ見えない形で透かし（ウォーターマーク）を埋め込む技術だ。Geminiや動画生成モデルVeo 3など、Google AIが出力するほぼすべてのコンテンツにSynthIDが付与されており、YouTubeのAI生成クリエイタークローン機能にも適用されている。 AI生成コンテンツの氾濫が問題視される現代において、「これはAIが作ったものか」を判別できる仕組みは非常に重要だ。SynthIDはその答えの一つとして、業界から注目を集めてきた。 「リバースエンジニアリング」の実態 開発者のAloshdenny氏は、GitHubにコードを公開し、Mediumで手法を詳しく解説した。手順は意外にシンプルだ。 Geminiで200枚の純黒・純白画像を生成する コントラスト・彩度を強調し、ノイズ除去することで透かしパターンを可視化する 各周波数ビン・チャンネルごとに透かし信号の強度と位相を平均化する 対象画像から同じ周波数成分を同じ角度で部分的に除去する 使ったのはニューラルネットワークではなく、古典的な信号処理技術のみ。「失業中に、ウィードをやりながら開発した」という本人のコメントが話題を呼んだが、技術的な内容は十分に精緻だ。 ただし、Aloshdenny氏自身が「完全には除去できなかった」と認めている。達成できたのは「デコーダーを混乱させて判定を諦めさせること」であり、透かし信号そのものを完全に消すには至っていない。 Googleの見解 Googleのスポークスパーソンは「このツールがSynthIDの透かしを体系的に除去できるという主張は正しくない」と明確に否定した。SynthIDは依然として堅牢な技術であるとの立場だ。 Aloshdenny氏自身も「SynthIDは本当によく設計されている」と評価しており、今回の騒動は「完全に破られた」ではなく「限界まで追い詰めたが突破できなかった」というのが正確な見方だ。 実務への影響 この騒動が示すのは、透かし技術の「完全性」への過信は禁物だということだ。日本のIT現場で考えるべきポイントは以下の通りだ。 AI生成コンテンツの管理担当者へ SynthIDのような透かし技術は「悪意あるユーザーが簡単には除去できないコスト」を提供するものであり、「絶対に除去不可能な証拠」ではない。ガバナンスの観点では、透かしの有無だけに依存せず、生成ログや管理台帳など複数の証跡を組み合わせることが現実的だ。 セキュリティ・コンプライアンス担当者へ 今回の手法は公開されており、将来的に自動化ツールとして広まる可能性は否定できない。AI生成コンテンツの真正性担保を法的・業務的要件として課している場合は、SynthIDの進化を注視する必要がある。 開発者・研究者へ 「200枚の黒画像と信号処理で透かしの構造が見えた」という事実は、AI透かし技術の設計において、単一の埋め込みアルゴリズムへの依存がリスクになりうることを示している。動的な鍵や多層的な埋め込みなど、より堅牢な設計へのヒントにもなるだろう。 筆者の見解 Aloshdenny氏の一番正直なコメントに、この話の本質がある。「完全には消せなかった。でも消えなかったということが、どれだけよく設計されているかを物語っている」——これは皮肉でなく、率直な技術評価だ。 AI透かし技術の目標は「解読不可能な暗号」ではなく、「不正利用のコストを十分に引き上げること」にある。この設計思想は正しいと思う。完璧なセキュリティなど存在しない。重要なのは「突破するために必要な労力が、得られる利益を上回るか」だ。 一方で、今回の手法がさらに洗練され、ツール化・自動化されたとき、現在の均衡が崩れる可能性はある。AI生成コンテンツが当たり前になった世界で、その真正性を保証する技術は社会インフラの一部になりつつある。SynthIDはその最前線にいる技術だ。今後の改良に期待しつつ、業界全体でより堅牢な標準策定が進むことを願う。 AI透かし技術は「AIが書いた、作った」を証明するための技術だが、逆に言えば「AIでないと主張する」ことへの悪用も考えられる。今回の騒動は完全破綻ではなかったが、透かし技術だけに頼るガバナンスの危うさを再認識させてくれた点で、価値ある事例だ。 出典: この記事は Has Google’s AI watermarking system been reverse-engineered? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAI投資家が自社バリュエーションに疑問を抱き始めた Financial Timesの報道をきっかけに、生成AI業界の資金動向に大きな地殻変動の兆しが見えてきた。OpenAIは現在8520億ドルという天文学的な評価額を掲げているが、その評価額を正当化しようとすると「IPO時点での企業価値が最低でも1.2兆ドル以上」という前提が必要になる——そう語るのは、両社に出資した経験を持つ投資家だ。一方でAnthropicの現在の評価額3800億ドルは「相対的な割安感がある」とも言われており、市場のセンチメントは明らかに変化しつつある。 わずか3ヶ月で売上3倍超：コーディングツール需要が牽引 Anthropicの年間換算売上は2025年末の9億ドルから、2026年3月末には30億ドルへと急拡大した。この成長の原動力として明確に名指しされているのがコーディングツールへの需要だ。 開発者向けの生成AIツール市場では、単なるチャット補助から「エージェントとして自律的にコードを書き・テストし・デプロイする」フェーズへの移行が急速に進んでいる。企業がこの領域に投資を集中させていることが、Anthropicの売上急増に直結している。 二次市場（セカンダリーマーケット）でもその動きは顕著で、Anthropic株への需要が「ほぼ飽和しない」レベルで高まる一方、OpenAI株はディスカウントで取引されているという。 OpenAI側の反論と「ネットスケープ」比較の衝撃 OpenAIのCFOであるSarah Friar氏は「過去最大の民間資金調達規模（1220億ドル）がそのまま投資家からの信頼の証だ」と反論している。確かに調達規模という観点では圧倒的だ。 しかし注目すべきは、投資会社Sapphire Venturesの代表Jai Das氏（両社への出資なし）が投げかけた言葉だ。彼はOpenAIを「AIにおけるネットスケープ」と表現した。かつてブラウザ戦争を制したネットスケープが、その後Microsoftに押されAOLに吸収されていった歴史を重ねた発言であり、業界関係者に強い印象を残している。 日本のIT現場への示唆 この動向が日本のエンジニアやIT管理者にとって意味するところは大きい。 調達・ベンダー選定の視点から: 生成AI基盤の選定はもはや「ChatGPTかClaude(Anthropic)か」という単純な比較ではなく、どのプロバイダーが3〜5年後も安定してAPIを提供し続けられるかという中長期的な視点が必要になる。売上成長率と投資家信頼度は、そのベンダーのサービス継続性を読む重要な指標だ。 コーディングツール選定の視点から: Anthropicの成長がコーディング需要に依存しているということは、エンジニアの実際の業務価値を生むツールへの評価が市場でも正しく反映されていることを示している。「使ってみたら実際に仕事が速くなった」という体験が積み重なり、企業の本格投資につながっているのだ。日本企業もPoC段階から脱して、生産環境での活用実績を積む段階に来ている。 AIエージェント投資の優先度: 単発の質問応答ではなく、自律的なタスク遂行（コード生成〜テスト〜修正のループ）を実現するエージェント型ツールへの需要が、今回の市場動向の背後にある。この流れはエンタープライズのAI投資戦略にも波及していくだろう。 筆者の見解 OpenAIの評価額問題をめぐるこの論争は、AI業界全体の「現実との向き合い」フェーズが始まったことを象徴していると感じる。 ここ数年、「最初に規模を取ったプレイヤーが勝つ」というゲームが続いてきた。しかし市場は今、「規模」よりも「使われた結果として売上が伴っているか」を問い始めている。Anthropicの売上がコーディングツール需要で急拡大しているという事実は、エンジニアが「実際に使ってみて役に立つ」と判断したツールが市場でも正当に評価される時代への転換を示している。 AIエージェントの本質は、人間が確認・承認を繰り返さなくても自律的にタスクを遂行できること——その体験の質が問われている。単に「AIを使っている」ではなく「AIが自分の代わりに考え・動いてくれる」体験を積み上げたプレイヤーが、企業でも個人でも次のフェーズを生き残る。 日本のIT現場でも、「話題だから試した」段階を超えて、実際に業務効率に差が出ているかを検証する段階に入るべきだ。ツールの選択は情報収集より実践に投資する。今この瞬間に、その判断を迫られている。 出典: この記事は Anthropic’s rise is giving some OpenAI investors second thoughts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが「指示待ち」から「自律稼働」へ転換するターニングポイント Anthropicが研究プレビューとして公開した Claude Code Routines は、単なる新機能の追加ではない。AIエージェントの使われ方が「人間が指示→AIが応答」という一問一答モデルから、「目的を設定→AIが自律的にループで働き続ける」 モデルへと本格移行する兆候として注目に値する。 日本のIT現場では、コードレビューの属人化・バックログの積み残し・深夜デプロイ後の確認漏れといった課題が日常的に存在する。Routinesが目指す世界は、そうした「誰かがやらなければならないが後回しにされがちな作業」を、クラウド上のAIインフラが無人で継続的に担うというものだ。 Routinesの仕組み：3種類のトリガーで「いつでも動く」 Routinesの本質は、プロンプト・リポジトリ・コネクター（外部ツール連携）をひとまとめにした「設定パッケージ」 を保存し、任意のタイミングで自動実行できる点にある。トリガーは3種類用意されている。 スケジュールトリガー 毎時・毎晩・毎週といったサイクルで定期実行する。バックログ整理、ドキュメントのドリフト（コードと乖離した古いドキュメントの検出）、週次のサマリー生成などに適している。 APIトリガー HTTP POSTでルーティンを呼び出せるエンドポイントが各ルーティンに付与される。監視ツールがアラートを検知した瞬間にAIを起動し、スタックトレースとコミット履歴を突き合わせてドラフトPRを自動作成する、といったユースケースが実現する。 GitHubトリガー PRのオープン・プッシュ・Issueの作成・ワークフロー完了など、リポジトリイベントをトリガーにできる。独自のレビューチェックリストをRoutineに持たせておけば、PRが作られるたびにセキュリティ・パフォーマンス・スタイルの観点からインラインコメントが自動付与される。 複数のトリガーを1つのRoutineに組み合わせることも可能で、「夜間のスケジュール実行＋デプロイスクリプトからのAPI呼び出し＋PRオープンイベント」を1つのルーティンが担う構成も許容される。 実行はAnthropicが管理するクラウドインフラ上で行われるため、ローカルマシンの電源がオフでも継続動作する。これはCIランナーの常時稼働コストを気にする中小チームにとっても見逃せない特性だ。 実務への影響：日本のエンジニア・IT管理者にとっての意味 コードレビューの脱属人化 Routinesによる自動レビューは、人間レビュアーを「機械的なチェック」から解放し、アーキテクチャや設計品質の判断に集中させる。チームにシニアエンジニアが1人しかいない状況でも、一定水準のレビューカバレッジを維持できる可能性がある。 アラート対応の初動自動化 深夜の本番アラートに対し、AIがスタックトレースの解析・原因候補の特定・修正候補のドラフトPR作成までを自動化すれば、オンコールエンジニアが「白紙のターミナル」から始める必要がなくなる。初動の認知負荷が大幅に下がる。 ドキュメントの鮮度管理 APIの仕様変更に追いついていないドキュメントは技術的負債の温床だ。週次のスケジュールで変更差分を監視し、更新PRを自動作成するRoutineを仕込めば、ドキュメントの陳腐化を防ぐ継続的なサイクルが生まれる。 導入時の注意点 現時点では「Research Preview」ステータスであり、APIやトリガーの仕様は変更される可能性がある。本番ワークフローへの組み込みは、仕様が安定してからというのが現実的な判断だろう。Pro・Max・Team・Enterpriseプランが対象で、claude.ai/code/routines またはCLIの /schedule コマンドから管理できる。 筆者の見解 Routinesが興味深いのは、それが 「ハーネスループ」の実用化 に踏み込んでいるからだ。AIエージェントがトリガーを受けて起動し、リポジトリを読み、コードを書き、PRを作り、結果をSlackへ通知する——この一連の流れがクラウドで自律的に完結する。人間が毎回起動ボタンを押す必要がない。 日本のITエンジニアの多くは今まさに、AIを「賢い補完ツール」として使いこなそうとしている段階だと思う。それ自体は悪くない入り口だ。ただ、その次の段階——AIが目的を与えられると自律的にタスクを遂行し続けるパートナーとして機能する世界——はもうすぐそこまで来ている。Routinesはその具体的な形のひとつを示している。 「バックログの整理は来週やろう」「ドキュメントの更新は誰かがやってくれるはず」——そういった先延ばしの多くは、AIルーティンが淡々と処理してくれる未来が現実になりつつある。重要なのは、こうした仕組みを自分たちのワークフローに合わせて設計・運用できる人材を今から育てることだ。ツールを使いこなすだけでなく、ループを設計できること。それがこれからのエンジニアに問われる核心だと思う。 Research Preview段階なので現時点での本番投入には慎重な判断が必要だが、試す価値のある方向性であることは間違いない。 出典: この記事は Claude Code Routines の内容をもとに、筆者の見解を加えて独自に執筆したものです。

中国のAIスタートアップMiniMaxが、AIエージェントにマルチモーダル生成能力を直接与えるCLIツール「MMX-CLI」を公開した。テキスト・画像・動画・音声・音楽・ビジョン（画像理解）・検索の7モダリティを、MCP（Model Context Protocol）などの追加レイヤーなしに標準シェルコマンドから呼び出せる設計で、エージェント開発の現場に大きなインパクトをもたらす可能性がある。日本語圏ではほぼ未報道だが、注目に値するリリースだ。 MMX-CLIが解決しようとしている問題 現在のLLMベースのエージェントはテキスト処理には強い。だが「音声を合成する」「動画を生成する」「画像の内容を解析して次のアクションを決める」といったメディア系の処理をエージェントに組み込もうとすると、途端に話が複雑になる。APIラッパーを個別に書き、認証をそれぞれ管理し、MCPサーバーを立ち上げてエージェント環境と繋ぎ込む——そういった作業のコストが、マルチモーダルエージェント開発の大きな障壁になっている。 MMX-CLIはこの摩擦を「シェルコマンド」という最もシンプルなインターフェースで解消しようとする。npm install -g mmx-cli と mmx auth の2コマンドでセットアップ完了。あとはターミナルからコマンドを叩くだけで7つのモダリティが使える。 7つのモダリティ詳解 テキスト (mmx text): マルチターンチャット・ストリーミング出力・JSONモード対応。MiniMax-M2.7 をデフォルトモデルとして使用。 画像 (mmx image): テキストプロンプトから画像生成。アスペクト比・バッチ数の制御に加え、--subject-ref パラメータでキャラクターやオブジェクトの一貫性を複数枚にわたって保つ参照生成が可能。ビジュアルノベルやマンガ制作の補助ツールとしても面白い使い方が考えられる。 動画 (mmx video): デフォルトモデルは MiniMax-Hailuo-2.3。非同期ジョブに対応しており --async フラグでタスクIDを即返して後でポーリングする設計が可能。--first-frame で最初のフレームを画像指定するイメージコンディショニングにも対応している。 音声合成 (mmx speech): 30種以上のボイスから選択可能。速度・音量・ピッチ制御、字幕データ出力、パイプ経由のストリーミング再生に対応。最大10,000文字まで入力できる。 音楽生成 (mmx music): ジャンル・ムード・楽器・テンポ・BPM・キー・構成を細かく指定可能。--instrumental で楽器のみの生成も可。AIウォーターマーク埋め込みフラグも備えている。 ビジョン (mmx vision): ローカルファイルまたはURLから画像を解析。ローカルファイルは自動的にbase64エンコードしてVLMに渡す設計で、--prompt でより具体的な質問を指定できる。 検索 (mmx search): ウェブ検索との統合機能。エージェントが外部情報を取得するフローに組み込める。 エージェント環境との統合 MMX-CLIはCursorやOpenCodeなど複数のエージェント環境から直接呼び出せることを明示している。「エージェントがシェルコマンドを叩ける」というシンプルな事実を活かした設計で、MCP設定なしに既存のワークフローへ組み込める点が大きい。 実務への影響 プロトタイピング速度の変化: 例えば「スクリーンショットの内容を解析して音声で要約を読み上げる」ようなワークフローが、mmx vision --prompt "要約して" screenshot.png | mmx speech のようなUNIXパイプで繋げられる可能性がある。従来なら複数のAPIを手配し個別に認証を管理する必要があった処理が、大幅に簡素化される。 自律エージェントの設計に直結: エージェントが「生成した内容を画像や音声で出力する」「入力された画像を解析して次のステップを判断する」といった自律的なループを組む際の選択肢が広がる。非同期ジョブ対応（--async）も含め、長時間処理をエージェントが自律的に管理するシナリオへの対応も考慮されている。 日本語対応の事前確認を: MiniMaxは中国系スタートアップだ。mmx speech の日本語ボイス品質や、テキスト処理における日本語の精度については、導入前に実際に検証することを強く推奨する。エンタープライズ環境での採用を検討する場合は、データプライバシーポリシーと利用規約を必ず確認してほしい。 筆者の見解 AIエージェントの進化において、「何ができるか」よりも「どれだけ摩擦なく組み込めるか」がここ最近でより重要になってきていると感じている。 ...

ニューヨーク連邦準備銀行が2026年4月に発表した調査レポートが、職場における生成AI活用の「格差」を鮮明に浮かび上がらせた。AIが生産性を高めることは現場でも認識されつつある一方で、そのツールへのアクセスや研修機会が特定の層に偏在している実態が統計として示された。これは米国の話でありながら、日本のIT現場にとっても決して他人事ではない。 調査が示したAI活用の実態 ニューヨーク連銀が2025年11月に実施した「消費者期待調査（SCE）」の補足質問をもとにした本調査では、現在就業中の回答者のうち**39%**が過去12ヶ月以内に職場でAIツールを利用したと回答した。 この数字は一見高水準に思えるが、内訳を見ると格差が際立つ。 学歴・収入・雇用形態で広がる利用率の差 属性 AI利用率 大学卒業者 58.7% 非大卒者 22.9% 年収20万ドル超 66.3% 年収5万ドル未満 15.9% フルタイム労働者 42.7% パートタイム労働者 24.7% 大卒と非大卒の利用率差は実に2.5倍以上。高収入層と低収入層では4倍超の開きがある。AIが「すべての人の生産性を底上げするツール」と期待される一方で、現状はその恩恵が高学歴・高収入・フルタイムの労働者に集中している。 利用者の66%が「生産性向上を実感」 AIツールを実際に使っている層では、66%が「自分の生産性が上がった」と回答した。具体的には「タスクをより速く終えられる（40%）」「こなせるタスク数が増えた（22%）」という声が多い。一方で「まだ学習中のためむしろ時間がかかっている（19%）」という回答も見られ、学習コストの問題が依然として残っていることもわかる。 「研修提供16%」という現実 調査で最も注目すべきは、**雇用主によるAI研修の提供率がわずか15.9%**という数字だ。 就業者の38%が「AIツールの使い方に関する研修は重要だ」と答えているにもかかわらず、実際に研修を受けられる環境にある人は6人に1人にも満たない。さらに37%は「職場がAIツールを提供していない」、11%は「雇用主が積極的に使用を禁止している」と回答しており、ツール自体へのアクセス障壁も根強く残っている。 非大卒層が研修に年収の11.4%相当の価値を感じている逆転現象 特筆すべきは、最もAIを使えていない非大卒の労働者が、AI研修に年収の11.4%相当という高い価値を置いているという発見だ。使えていないからこそ潜在的な恩恵を強く認識しており、「学びたいのに機会がない」という状況が浮かび上がる。研修を望む理由としては「仕事が楽になる（68%）」「生産性が上がる（56.7%）」が上位を占め、「AIを使わない仕事は将来的に少なくなる（39.2%）」という危機感を持つ人も4割に迫る。 日本のエンジニア・IT管理者にとっての意味 この調査は米国のデータだが、日本の職場環境と照らし合わせると示唆に富む点が多い。 企業としての喫緊の課題は、AIツールへのアクセス整備と研修機会の提供だ。 「禁止」や「様子見」は問題を先送りするだけで、格差を拡大させる方向にしか働かない。使いたい社員が公式に提供されたツールを安心して使える環境を整えることが、企業としての優先事項になる。 IT管理者の観点では、「誰が使えていて、誰が使えていないか」を可視化することが出発点になる。アクセスや研修の機会が特定の部門や役職に偏っていないか、定期的に確認する仕組みが必要だ。 研修設計においては、「ツールの操作方法」よりも「業務の中でどう活かすか」という実践的な内容を中心に置くと定着しやすい。40%の利用者が「タスクを速く終えられる」と答えている背景には、自分の業務文脈に落とし込む試行錯誤の積み重ねがある。 筆者の見解 この調査を読んで改めて感じるのは、「禁止」や「未提供」という選択がいかに企業自身の競争力を削ぐかということだ。 「AIツールを禁止している」という11%の企業は、おそらく情報漏洩やコンプライアンスへの懸念から出た判断だろう。その懸念自体は正当だ。しかし禁止した瞬間に、社員はシャドーIT的に個人アカウントで使い始めるか、使うこと自体を諦める。前者はむしろセキュリティリスクを高め、後者は生産性向上の機会を逃す。どちらに転んでも企業にとって良い結果にならない。 正しい方向性は「安全に使える仕組みを先に整える」ことだ。社内データをAIに入力する際のガイドライン、承認されたツールの一覧、簡単な研修コンテンツ——このくらいのものを揃えるだけで、多くのリスクはコントロール可能になる。整備が先、解禁は後、ではなく、整備と並走しながら段階的に解禁していく動き方が現実的だ。 もう一点、この調査が示す「格差の固定化」リスクも看過できない。高学歴・高収入層がAIを使いこなし、そうでない層がアクセスできないまま時間が経過すると、AIはむしろ格差を拡大する道具になってしまう。AIが本来持つ「専門知識を持たない人でも高度な作業ができるようにする」というポテンシャルが、アクセス格差によって逆説的に活かされない状況だ。 調査が示す「非大卒層が研修に最も高い価値を感じている」という事実は、そのポテンシャルへの正確な期待値の反映だと思う。彼ら・彼女らが最も多くを得られる立場にいながら、機会が届いていない。ここに企業が介入する意義がある。 「情報を追うより、実際に使って成果を出す経験を積む」——これが個人レベルでの正解だとすれば、企業レベルでの正解は「使いたい人が使える環境を作る」だ。研修を16%しか提供できていない現状は、まだ多くの余地が残っていることを示している。逆に言えば、今ここに投資できる企業には大きなアドバンテージがある。 出典: この記事は Use of Gen AI in the Workplace and the Value of Access to Training の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIがサイバーセキュリティの現場に本格参入し始めている。OpenAIが2026年4月14日に発表した「GPT-5.4-Cyber」は、防衛的サイバーセキュリティ用途に特化したファインチューニングモデルだ。単なる機能追加ではなく、「AIに何をさせるか」という管理アーキテクチャそのものの転換を示す動きとして注目したい。 GPT-5.4-Cyberとは何か GPT-5.4-Cyberは、通常版のGPT-5.4では制限されている操作を、セキュリティ用途に限って許可するよう調整された「cyber-permissive（サイバー向け許容）」なモデルだ。最も注目すべき追加機能がバイナリ・リバースエンジニアリング（Binary Reverse Engineering）——ソースコードなしでコンパイル済みバイナリを解析し、マルウェアや脆弱性、セキュリティ上の弱点を特定する技術だ。 これはペネトレーションテストやインシデント対応の現場で長年必要とされていた作業を、AIが直接支援できることを意味する。従来のAIチャットでは「それは危険な操作に使われる可能性がある」として断られがちだった問い合わせが、身元確認された専門家には正面から答えてもらえるようになる。 アクセス管理の設計思想が変わった OpenAIは今回の発表で、「Trusted Access for Cyber（セキュリティ向け信頼アクセス）」プログラムを数千人規模の認定セキュリティ専門家に拡大した。このプログラムは2026年2月に1,000万ドルのサイバーセキュリティ助成プログラムと同時に立ち上げられたもので、今回から段階的な認証レベル（ティア制）が導入され、最上位ティアのみGPT-5.4-Cyberにアクセスできる。 個人ユーザーはchatgpt.com/cyberで本人確認、企業はOpenAI担当者経由で申請できる。 ここで重要なのはアーキテクチャの転換だ。従来のAI安全管理は「機能ごとにオン/オフ」という粗い粒度だったが、GPT-5.4-Cyberは「誰が使うか」という身元確認ベースのアクセス制御に移行している。OpenAIはこれを「blanket capability restrictions（一律の機能制限）から identity-based access controls（身元ベースのアクセス制御）へのシフト」と明示している。 ベンチマーク性能の推移 OpenAIが公開したキャプチャ・ザ・フラッグ（CTF）ベンチマークの成績推移は印象的だ： GPT-5（2025年8月）: 27% GPT-5.1-Codex-Max（2025年11月）: 76% わずか3ヶ月で性能が約3倍になっている。同社が開発中のCodex Securityも、今年のプライベートベータ以降、エコシステム全体で3,000件超のクリティカル・高深刻度脆弱性の修正に貢献したと報告している。 OpenAIはPreparedness Framework（準備フレームワーク）に基づき「今後リリースするモデルはすべてサイバー能力が『High』レベルに到達する可能性を念頭に開発・評価する」と明言している。能力向上を前提とした管理体制の整備を先回りで行う姿勢は評価できる。 日本のセキュリティ現場への影響 いくつかの点で日本のIT現場にも実質的な意味がある。 脆弱性診断の民主化: バイナリ解析はこれまで専門知識と高価なツール（IDA ProやGhidraの熟練操作）が必要だった領域だ。GPT-5.4-Cyberがこれを支援できるなら、中規模のセキュリティチームでも対応できる範囲が広がる。 認定プログラムへの参加検討: Trusted Access for Cyberは現在英語ベースのプログラムだが、国内のセキュリティベンダーや診断会社が組織単位で申請できる枠組みになっている。早期参加することで競合優位を得られる可能性がある。 オープンソース向け無償スキャン: Codex for Open Sourceは1,000以上のプロジェクトに無償のセキュリティスキャンを提供済みとのことで、OSSを内製管理している組織にとっては活用を検討する価値がある。 内製ツール・レガシーバイナリの解析: ソースコードが失われた古いシステムや、外部委託で作られたバイナリしか手元にない社内ツールは日本企業に多い。こうした「ソースなし資産」の安全評価にバイナリ解析AIが有効な選択肢となりうる。 筆者の見解 今回の動きで最も重要なのは、モデルの性能よりも管理アーキテクチャのパラダイム転換だと思っている。 AIの安全管理で「禁止」を選ぶと、必ず失敗する。禁止されたユーザーはより使いにくい代替手段を使い、結果として全体の見通しが悪くなる。一方で「誰でも使えます」では当然リスクがある。この二項対立を突破するのが「身元確認ベースの段階的アクセス」という設計だ。 医療の処方箋制度に近い考え方で、「必要な人が適切な管理のもとで使える」仕組みを公式に整備することが、長期的には最も安全で実効性が高い。日本でも情報処理安全確保支援士（登録セキスペ）のような既存の専門家資格とAIアクセス権を紐づける制度設計が将来的に議論されるかもしれない。 セキュリティ特化AIの競争は、一部の大手プレイヤーが限定的なグループに提供するフェーズから、数千人規模の認定専門家コミュニティへと広がり始めた。この流れは止まらないし、止めるべきでもない。重要なのは「誰がどのような経緯でアクセスできるか」の設計を社会として丁寧に作っていくことだ。その意味でOpenAIが今回示した「透明な段階的認証」のアプローチは、業界全体の参照モデルになりうると考えている。 出典: この記事は OpenAI Releases Cyber Model to Limited Group in Race With Mythos の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがChromeデスクトップ版に「Skills（スキル）」機能を追加した。GeminiへのAIプロンプトを名前付きで保存し、別のタブや別のページでも一クリックで即座に再実行できるというものだ。地味に見えて、ブラウザとAIの関係を少し変えうる機能である。 Skillsとはどんな機能か Gemini側のチャット画面でプロンプトを打ち込んだあと、その内容を「スキル」として保存できる。保存後はChromeの入力欄にスラッシュ（/）を入力してコンパスアイコンをクリックすると、保存済みスキルの一覧が表示され、選択するだけで再実行される。 Googleが紹介している利用例は、「レシピページを開くたびにビーガン向け代替食材を提案させるプロンプト」「複数のタブで商品スペックを並べて比較させるプロンプト」などだ。これまでは同じタスクを別ページで繰り返すたびにプロンプトを入力し直す必要があったが、Skillsはその手間を省く。 Googleアカウントでサインインしていれば、保存したスキルは同アカウントのほかのデスクトップデバイスとも同期される。自分でゼロから作る以外に、Googleが用意したプリセットライブラリから選ぶことも可能で、プリセットを自分好みにカスタマイズする使い方もできる。なお現時点ではChrome英語UI（US English）設定のユーザーへの展開が始まったばかりで、日本語環境での提供時期は未確定だ。 なぜこれが重要か この機能の面白さは「プロンプトの再利用」というシンプルな発想にある。AIを使い慣れたユーザーの多くは、よく使うプロンプトをどこかのメモやスプレッドシートに控えておき、都度コピペしている。それは結局「AIを道具として使いこなす」段階では避けられない煩雑さだった。 Skillsはその問題に正面から向き合った解決策だ。プロンプト自体をブラウザのUI層に組み込むことで、AIをページ単位の「ボタン」として扱える。特定のサイトや特定の作業文脈に紐付けて使えるため、情報収集・比較検討・要約といった繰り返し作業に向いている。 もう一点注目したいのは、プリセットライブラリの存在だ。AIプロンプトの設計は、慣れないうちは案外難しい。出発点として使えるテンプレートがあれば、AIをまだ使いこなせていない層の参入障壁がひとつ下がる。この設計は地味ながら丁寧だと思う。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本語環境への正式提供は今後の話になるが、早めに把握しておく価値はある。現時点でできる準備として以下を意識しておきたい。 よく使うプロンプトを棚卸ししておく。自分が毎日・毎週繰り返しているAI作業を書き出しておくと、Skillsが使えるようになった際にすぐ活用できる。「レビューコメントの日本語要約」「Confluenceページの要点整理」「会議メモのアクションアイテム抽出」といった作業が候補だ。 ブラウザ統合AIの評価軸を整理しておく。Skillsはあくまでブラウザ内での定型AIタスクの効率化に特化している。コーディング支援や複雑なエージェント的作業を期待するのは的外れで、利用シーンの見極めが重要になる。 企業利用における情報漏洩リスクの確認。スキルはGoogleアカウントと同期される。業務で利用する場合、どの情報がGeminiに送られているかを把握した上で利用ポリシーを整備しておく必要がある。これはChromeのAI機能全般に言えることだが、スキルという「保存」の仕組みが加わったことで見逃しやすくなるリスクでもある。 筆者の見解 Skillsは地味だが方向性は正しい。「毎回同じことを入力させる」という体験は、AIが本当に使いやすくなった段階では消えていくべきもので、それをブラウザ機能として解消しようとするアプローチには共感できる。 ただ、率直に言うと「繰り返しプロンプトを一クリックで」という価値は、ブラウザ外のAIエージェント体験が十分に成熟すれば自然に解消されていく問題でもある。ページを開く→スキルを選ぶ→結果を見るという操作の流れ自体、将来的には「そのページを開く目的ごと、エージェントが自律的に処理してくれる」という形に収斂していくはずだからだ。 その意味では、Skillsは「現時点でのブラウザAIをどれだけ実用的にするか」という課題への現実的な回答であり、長期的なビジョンへの足がかりとして捉えるのが妥当だろう。同種の機能は他のブラウザやプラットフォームにも波及してくると思われるので、AIを業務に組み込む文脈で「定型タスクの自動化層」がどこに置かれるべきかを今から考えておくことが、一年後に差をつけるポイントになる。 出典: この記事は Chrome now lets you turn AI prompts into repeatable ‘Skills’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIに仕事を奪われることへの恐怖から、企業のAI導入を意図的に妨害している従業員が増えている。米Fortuneが報じた調査では、Z世代の実に44%がこうした行動を取っていることが明らかになった。しかし皮肉にも、AI拒絶は雇用リスクをむしろ高める「逆効果」であることも、同じ調査で浮き彫りになっている。 調査の概要 エンタープライズAIエージェント企業WriterとWorkplace Intelligenceが、米・英・欧州の2,400名のナレッジワーカー（うちC-suiteエグゼクティブ1,200名）を対象に実施した調査によると、29%の従業員が自社のAI戦略を意図的に妨害していると認めた。Z世代に限ると、この割合は**44%**にまで跳ね上がる。 具体的な妨害行動 報告された妨害行動は多岐にわたる。 公開AIツールへの機密情報入力: 承認されていないAIサービスを業務で使用し、社内データを外部に晒す 利用拒否: 会社支給のAIツールそのものを使わない 人事評価への細工: 考課データを意図的に操作し、AIの有効性を低く見せる 低出力作業の意図的実施: AIが効果的でないように見せるため、成果物のクオリティを故意に下げる 妨害の動機として最も多かったのは「AIに仕事を奪われる恐怖」（30%）。KPMGの別調査でも4割の労働者が同様の不安を抱えていることが確認されており、この恐怖感は広く共有されている。 「恐れるから拒絶する」の逆効果 ところが現実は逆だ。AIを拒絶する従業員は、採用している従業員よりもレイオフリスクが高い。 60%のエグゼクティブがAI採用を拒む従業員の解雇を検討している 77%のエグゼクティブがAIを習熟しない従業員を昇進・リーダー候補から除外すると回答 **69%**がAI関連のレイオフを計画中 一方、AIを積極的に使いこなす「スーパーユーザー」は明確な恩恵を受けている。昇進・昇給を得る確率が遅れを取る従業員の3倍、週あたりの業務時間節約は約9時間（遅れを取る従業員の4.5倍）に達する。 技術の問題ではなく、組織の問題 MITの調査では、企業のジェネレーティブAIパイロットの95%が失敗しているが、その原因は技術の質ではなく「ツールと組織の間の学習ギャップ」だと指摘されている。つまり、問題の本質はAIそのものではなく、組織としていかに習熟するかにある。 実務への影響 日本のIT管理者・エンジニアが今すぐ考えるべき点を整理する。 「禁止」より「安全に使える仕組み」を整える 日本では「AIツールは業務使用禁止」という通達を出す企業も少なくないが、禁止アプローチには構造的な限界がある。禁じれば禁じるほど、従業員は野良ツールに逃げ、機密データの漏洩リスクがむしろ高まる。企業として推奨するAIツールを明示し、ガバナンスを保ちながら便利に使える環境を整えることが先決だ。 AI教育・支援を「任意」にしない 「AIは各自で勉強してください」では格差が広がるだけだ。スーパーユーザーと遅れを取る従業員の間に3倍の生産性差が生まれるとすれば、組織全体の底上げは経営マターだ。ハンズオン研修やユースケース共有の場を設けることが、競争力維持の観点から不可欠になる。 恐怖をデータで解消する 従業員のAI忌避の背後には「情報の非対称性」がある。「AIで何ができて何ができないのか」「自分の仕事がどう変わるのか」を経営・管理職が言語化し、丁寧に伝えることが、妨害行動を防ぐ最も有効な手段だ。 筆者の見解 この調査が示しているのは、AIの進歩が速すぎて「人間側の受け入れ態勢」が追いついていない、という普遍的な構造問題だ。 「恐怖から拒絶する」という行動自体は人間として自然だ。しかし現実として、AIを使いこなしている人は確実に前に進んでいる。その格差は数年後、取り返しのつかない差になって現れる。 日本のIT現場では、こうしたトレンドが欧米より遅れて顕在化する傾向がある。だからこそ今が準備のチャンスだ。「禁止」や「様子見」で時間を浪費している組織は、気づいたときには追いつけない差がついている可能性が高い。 個人の視点では、「AIに使われる人」ではなく「AIを使う人」になることが唯一の正解だ。今すぐ使い始めて、小さな成功体験を積む。その積み重ねが、3年後・5年後のキャリアを守る。 組織の視点では、従業員の恐怖を無視して「使え」と言うだけでは必ず失敗する。MITが示す通り、95%の失敗は技術ではなく組織側の問題だ。学習ギャップを埋めることへの投資を惜しんだ企業は、やがて競争力を失う。安全に使える仕組みを作り、全員が便利と感じられる状態にする——これが唯一の勝ちパターンだと確信している。 出典: この記事は Gen Z workers who fear AI will take their job are actively sabotaging their company’s AI rollout の内容をもとに、筆者の見解を加えて独自に執筆したものです。