Tech News JP

デザインとAIの関係が、また一段階変わろうとしている。Anthropicが2026年4月17日に発表した「Claude Design」は、画像生成AIとも、テキストベースの指示ツールとも異なる、チームのデザインシステムを軸にした共同制作プラットフォームだ。研究プレビューとして、Pro・Max・Team・Enterprise サブスクライバーに順次展開されている。 Claude Designとは何か Claude DesignはAnthropicの最新ビジョンモデル「Claude Opus 4.7」を搭載し、テキストで指示するだけでデザイン・プロトタイプ・スライド・ワンペーパーなどビジュアル成果物を生成・反復改善できるツールだ。 特徴的なのは「オンボーディング時にコードベースとデザインファイルを読み込み、チームのカラー・タイポグラフィ・コンポーネントを自動抽出してデザインシステムを構築する」点。以降のすべてのプロジェクトに、そのシステムが自動的に適用される。部門ごとに複数のデザインシステムを持つことも可能だ。 主な使われ方 インタラクティブプロトタイプ: 静的モックアップを共有可能なインタラクティブ版に変換。コードレビューやPRなしで完結 プロダクトワイヤーフレーム: PMがフィーチャーフローをスケッチして、そのままエンジニアへハンドオフ ピッチデック・プレゼン: ラフなアウトラインからブランドに沿ったスライドを生成し、PPTXやCanvaへエクスポート マーケティング素材: ランディングページやSNS用ビジュアルをその場で作成 フロンティアプロトタイプ: 音声・映像・3D・シェーダーを組み込んだコード駆動の体験を誰でも構築可能 操作フロー テキストプロンプトで初版を生成 → インラインコメントや直接テキスト編集、スペーシング/カラー/レイアウトの調整ノブでリファイン → 「全体に適用」を指示 → CanvaやPDF・PPTX・スタンドアロンHTMLへエクスポート、という流れが基本だ。組織内URLでの共有や、複数人が同時にチャットしながら編集するコラボレーション機能も備える。 最終的に完成したデザインは「ハンドオフバンドル」としてパッケージ化され、コード実装ツールへワンステップで引き渡せる設計になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 「デザインできないPM・エンジニア問題」への解答 日本の中小規模チームでは、専任デザイナーが不在のままPMやエンジニアが資料を作り続ける現場が少なくない。Claude Designは「デザインセンスがなくてもブランドに沿ったアウトプットが出せる」を現実にする。会議前夜にワイヤーフレームを整えたいとき、投資家向けデックをたたき台から仕上げたいときに、インフラとして機能しうる。 デザインシステム管理の自動化 チームのデザインシステムを一度読み込ませれば以降は自動適用される仕組みは、デザイン一貫性の維持コストを大幅に下げる。大企業のブランドガイドライン管理でも、スタートアップの「なんとなく合わせる」問題の解消でも使える。 注意すべき点 コードベースやデザインファイルを読み込む機能は、機密情報の取り扱いポリシーを事前に確認する必要がある。Enterprise契約であればデータ処理のスコープが明確になるが、Teamプランで社外秘の設計資料を投入する前には利用規約・データ保持ポリシーの精読を推奨する。 筆者の見解 デザインツール市場にAIが本格参入するのは時間の問題だったが、今回の発表で注目したいのは「デザインシステムの自動インポート→全プロジェクトへの自動適用」という設計思想だ。 これは「AIに都度指示して出力を得る」副操縦士型のアプローチではなく、一度文脈を与えれば以降は自律的に文脈を維持し続けるアーキテクチャだ。繰り返しの確認や承認を人間に要求し続ける設計では、本来の効率化が半減する。その意味でClaude Designの設計方針は、AIが実務の流れに自然に溶け込むための正しい方向を向いている。 実務家として「情報を追うより自分で使って成果を出す」を徹底している立場から言えば、まずプロトタイプひとつ作ってみることを強く勧めたい。「ビジュアル制作にこれだけ使えるなら、テキスト・コード・データ・デザインが一気通貫でつながる未来は近い」というのが率直な印象だ。 Design→コード実装へのハンドオフ機能も含め、今後の機能拡張次第ではノーデザイナーでもプロトタイプからプロダクション品質のUIまで一気に仕上げるワークフローが現実になる。日本のIT現場でも、まず「小さく試して体感する」フェーズを早めに踏んでおくことが、次の半年で差をつけるポイントになるだろう。 出典: この記事は Claude Design の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Opus 4.7のリリースにともない、Anthropicは新しいトークナイザーを導入した。公式移行ガイドには「おおよそ1.0〜1.35倍のトークン数」と記載されているが、実際にAPIで計測したところ、英語技術文書では1.47倍、Claude Codeユーザーが日常的に送信するCLAUDE.mdファイルでは1.45倍という結果が出た。上限ではなく、それを超えた数字だ。 同じ料金体系のまま、トークン消費が増える。これが実務にどう響くのかを整理しておきたい。 実測データが示すもの 計測に使われたのはAnthropicが提供する無料のトークンカウントAPI（POST /v1/messages/count_tokens）。同じコンテンツをOpus 4.6と4.7に投げて差分を見るシンプルな手法で、推論コストはかからない。 コンテンツ種別ごとの実測比率（4.7 / 4.6）は以下のとおり。 コンテンツ種別 比率 英語技術文書 1.47x シェルスクリプト 1.39x TypeScriptコード 1.36x Markdownコードブロック混じり 1.34x Pythonコード 1.29x 英語散文 1.20x 一方で、日本語・中国語テキストは1.01倍とほぼ変化なし。CJK文字やJSON、CSVなどの構造データも影響が小さい（1.01〜1.13倍）。 なぜ英語・コードだけが膨らむのか トークナイザーはByte-Pair Encoding（BPE）という手法を使っており、「頻繁に出現する文字の組み合わせをひとつのトークンとして学習する」仕組みだ。4.7ではこのマージが英語やコードに対してより細粒度になった——つまり、以前は1トークンで表現していた単語やキーワードが複数トークンに分解されるようになっている。 英語1文字あたりのトークン効率は4.6の「4.33文字/トークン」から4.7では「3.60文字/トークン」に低下。TypeScriptに至っては3.66→2.69と大幅な悪化だ。 CJKはそもそも1文字が1〜2トークン相当の表現を取ることが多く、BPEのマージ効率の変動を受けにくい。これが非対称性の構造的な理由と考えられる。 実務への影響 Claude Codeユーザーへ Claude Codeのプロンプトには英語のコードやMarkdown、設定ファイルが大量に含まれる。実測で7種のリアルファイルの加重平均は1.325倍。Maxプランの利用枠が同じなら、実質的な処理量は約25%減ると考えてよい。コンテキストウィンドウの消費ペースも速くなる。 具体的には、 長いシステムプロンプトやCLAUDE.mdを使っている場合、キャッシュプレフィックスのコストが上昇 レートリミットに到達するタイミングが早まる 1回のセッションで扱えるコンテキスト量が減る 日本語中心のワークロードは影響軽微 日本語のドキュメント作成、日本語コメント付きコード、日本語プロンプトを主に使う場合は、比率がほぼ1.0のため実質的な変化はない。これは日本のユーザーにとって重要な朗報だ。 APIを直接使うエンジニアへ count_tokens エンドポイントは無料で使えるため、既存のプロンプトをOpus 4.7で事前計測しておくことを強く勧める。想定より早くコスト上限に達するケースが出てくる可能性がある。 なぜAnthropic はトークン数を増やしたのか 公式の説明では「より細粒度のトークン表現により、モデルの推論精度が向上する」とされている。細かく分割したほうが複雑なパターンを学習しやすいという設計上の判断だ。 ただし、今回の計測はあくまで「コストの変化」を示すものであり、「性能向上が本当にコスト増に見合うか」については別途検証が必要だ。 筆者の見解 正直に言えば、トークナイザーの変更は地味に見えて実は大きな話だ。ユーザーが意識しないところで消費量が増え、体感として「なんか遅くなった」「上限に当たりやすくなった」という形で現れる。これは透明性の問題でもある。 一点、データとして非常に興味深いのが日本語・中国語がほぼ影響を受けていないという事実だ。英語・コード中心のユーザーと、日本語・アジア系言語中心のユーザーとで、実質的なコスト構造が違うモデルになっている。日本のエンジニアは「日本語で書けば節約できる」という逆説的なインセンティブを得たとも言える。 とはいえ、実務では英語コードベースを扱う場面が多い。その前提で考えると、プロンプト設計のスリム化——不要なコンテキストを削る、キャッシュを適切に活用する——が以前より重要になってくる。これは良い設計習慣の後押しとも取れるし、余計な負担とも取れる。どちらに転ぶかは、使い方次第だ。 今後のモデルアップデートのたびにトークナイザーが変わるなら、コスト見積もりの前提を毎回見直す必要が生じる。この種の実計測を習慣化しておくことが、APIを本番利用するチームには不可欠になっていくだろう。 出典: この記事は Claude Opus 4.7 costs 20–30% more per session の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは今週、Windows 11のDevチャンネルおよびBetaチャンネル向けにプレビュービルドを配信した。今回の更新はWindows Helloの改善、プライバシーコントロールの強化、設定アプリやファイルエクスプローラーの使い勝手向上が中心となっている。地味に聞こえるかもしれないが、実務に直結する変更が含まれており、IT管理者は要注目だ。 Windows Helloの改善——認証体験がより洗練される Windows Helloは、パスワードレス認証の中核を担うMicrosoftの生体認証フレームワークだ。今回のビルドではそのエクスペリエンスが改善されており、顔認証・PIN認証の安定性や設定フローの見直しが含まれているとされる。 Windows Helloはもともと正しい方向性の技術だが、企業導入においては「互換性のあるカメラを別途調達する必要がある」「古いPCでは顔認証が使えない」といったハードルもあった。ソフトウェア側が成熟するにつれ、こうした体験の差が埋まっていくのは歓迎すべきことだ。 プライバシーコントロールの強化——設定が探しやすくなる 設定アプリのプライバシー関連セクションが整理・強化された。Windows 11はリリース当初からプライバシー設定の項目が多く、どこで何を制御できるのか分かりにくいという批判があった。今回の改善はその問題に正面から向き合った変更とみられる。 IT管理者の視点では、エンドユーザーがプライバシー設定を自分で変更できてしまう範囲と、MDM（Intuneなど）で組織管理できる範囲のバランスが常に課題となる。設定UIが整理されることでユーザーの「誤操作」や「意図しない設定変更」が減るなら、管理側にも恩恵がある。 ファイルエクスプローラーの改善 ファイルエクスプローラーも継続的に改善が続いている。Windows 11世代でタブ機能やモダンUIが導入されて以来、細かい挙動の安定化と機能追加が続いている状況だ。具体的な変更内容はビルドノートで確認が必要だが、日常的に使うツールだけに小さな改善でも積み重ねの効果は大きい。 実務への影響 DevチャンネルとBetaチャンネルの違いを意識する Devチャンネルは最新の実験的機能が入るが安定性は保証されない。Betaチャンネルは次期安定版に向けた機能検証が主で、エンタープライズパイロット用途に向いている。今回の変更がいつ安定版（GAチャンネル）に降りてくるかを見極めながら、自社の展開計画に組み込む判断が必要だ。 Windows Updateのタイミング判断 ここ最近、Windows Updateを即時適用したら問題が出た、という報告が散見されるようになっている。数日様子を見てからパッチを当てる判断も、リスク管理の観点では十分に合理的だ。ただし「様子を見る」と「永遠に当てない」は別物。期間を決めて判断する運用フローを整えておきたい。 パスワードレス移行の機会として捉える Windows Helloの改善は、まだパスワードレス移行を進めていない組織にとって好機だ。Microsoft Entra IDとの組み合わせでパスワードレス認証を段階的に導入する際の第一歩として、まず対応ハードウェアの棚卸しから始めるとよいだろう。 筆者の見解 Windowsの細かいビルドを毎回深追いする意義は、正直なところ薄れてきていると感じている。リリースペースが上がった分、各ビルドの「重み」が下がっているからだ。 その中で今回のアップデートが評価できるのは、Windows Helloの改善やプライバシー設定の整理が「正しい方向への地道な積み上げ」だからだ。派手さはないが、こういう地道な改善こそがWindowsをエンタープライズで長く使い続けられるプラットフォームたらしめている。 パスワードレス認証の普及は、セキュリティの文脈でもユーザー体験の文脈でも避けて通れない流れだ。Microsoftにはこの分野で実績があるし、Windows Hello + Entra IDの組み合わせは実用上も十分な水準に達している。この方向性をさらに磨き込んでほしいと思う。エンドポイントのアイデンティティ管理は、ゼロトラストアーキテクチャの入り口に位置する最重要要素だからだ。 Windowsの更新は今後も続く。すべてを追うのではなく、自分の組織に影響のある変更を選び取る目を持つことが、これからのIT管理者には求められている。 出典: この記事は Windows 11 gets improved privacy controls, better Windows Hello, and more in new builds の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国のサイバーセキュリティ機関CISAが、Apache ActiveMQに存在する高深刻度の脆弱性（CVE-2026-34197）が実際の攻撃で悪用されていることを確認した。この脆弱性の最大の特徴は、13年間にわたって見過ごされてきたという点にある。パッチは2026年3月30日に提供されたが、既に攻撃者に悪用されている以上、対象システムを運用する組織は一刻も早い対応が求められる。 Apache ActiveMQとは——「縁の下の力持ち」が狙われた Apache ActiveMQはJavaベースのオープンソースメッセージブローカーで、アプリケーション間の非同期通信を担う。マイクロサービスアーキテクチャや企業内SOA基盤に広く使われており、日本の大企業でも「気づいたら使っていた」という形で稼働しているケースが少なくない。 今回のCVE-2026-34197は入力検証の不備に起因する。認証済みの攻撃者がインジェクション攻撃を通じて任意のコードをリモート実行できる。発見したHorizon3の研究者は、AIを活用した解析ツールを使ってこの欠陥を掘り起こした——人間の目が13年間見落としてきたものを、AIが別の角度から発見したというわけだ。 パッチ済みバージョンはActiveMQ Classic 6.2.3 および 5.19.4。これ以前のバージョンを使用しているシステムは即時アップデート対象と考えてほしい。 CISAがKEVカタログに追加、政府機関に4月30日までの対応を命令 CISAは今回の脆弱性を「既知の悪用済み脆弱性（KEV: Known Exploited Vulnerabilities）カタログ」に追加し、連邦政府の民間機関（FCEB）に対して4月30日までのパッチ適用を義務付けた。 脅威監視サービスShadowServerの調査では、インターネットに公開されたActiveMQサーバーが現時点で7,500台超確認されている。これらはすべて潜在的な攻撃対象だ。 Horizon3はログによる侵害確認方法も公開している。ActiveMQブローカーのログで以下のシグネチャを探すとよい： brokerConfig=xbean:http:// クエリパラメータを含む不審な接続 内部トランスポートプロトコル VM を使用した異常なブローカー接続 ActiveMQは繰り返し狙われてきた「常連ターゲット」 ActiveMQに対する大規模攻撃は今回が初めてではない： CVE-2023-46604: TellYouThePassランサムウェアグループがゼロデイとして悪用 CVE-2016-3088: これも実際の攻撃で確認済み Horizon3が指摘するように、「ActiveMQに対する攻撃手法とポスト・エクスプロイテーションの技術は攻撃者の間で広く知られている」。過去の悪用実績があるということは、攻撃のTTP（戦術・技術・手順）が体系化されているということでもある。今回の新たな脆弱性情報は、既存の攻撃ツールキットに組み込まれるのが早い。 実務への影響——日本の現場で今すぐ確認すべきこと 1. バージョン確認と即時更新 ActiveMQ Classic 6.2.3 / 5.19.4 未満のバージョンは即時更新対象。まず環境内のActiveMQインスタンスを洗い出すことから始めよう。コンテナや古いオンプレサーバーで「存在を忘れていた」インスタンスが潜んでいないか確認する。 2. インターネット露出の排除 7,500台超がインターネットに公開されているという数字は衝撃的だ。ActiveMQブローカーはそもそも外部から直接アクセスさせるべきではない。VPCやプライベートサブネット、ファイアウォールで外部からのアクセスを遮断しているか確認する。 3. ログ監視と侵害確認 上述のシグネチャを使った侵害確認を今すぐ実施してほしい。パッチ適用前に既に侵害されていた場合、パッチだけでは不十分だ。 4. 認証強化 「認証済み攻撃者」が前提の脆弱性だが、認証情報の漏洩（フィッシング、クレデンシャルスタッフィング等）と組み合わせると実質的に誰でも悪用できる。ActiveMQの認証設定を見直し、最小権限の原則が守られているか確認する。 筆者の見解 「13年間見過ごされていた」という事実に、私は正直ゾッとした。 ActiveMQのような枯れたミドルウェアは、「長く使われてきた＝安定している＝安全」という誤解が生まれやすい。しかし実態は逆で、「長く使われてきた＝長い間、潜在的な脆弱性が眠っていた可能性がある」だ。今動いているから大丈夫、という思考が最も危険な盲点になる。 興味深いのは、この欠陥がAIによる解析で発見されたという点だ。人間の研究者が13年間見落としてきたものを、AIが別の視点から引っ張り出した。これは防御側にとっての朗報だが、同時に攻撃側が同じアプローチで「まだ誰も気づいていない脆弱性」を大量発掘する時代が来ることを示唆している。セキュリティチームにもAIを活用した継続的な脆弱性スキャンの仕組みが必要になる。 ゼロトラストの文脈で言えば、今回の件はまさに「境界型セキュリティの限界」の典型例だ。ネットワーク境界で守っている気になっていても、内部の古いミドルウェアが足元を崩す。ネットワーク層・認証層・認可層の多層防御と継続的なアセット管理——「存在すら忘れていたActiveMQサーバー」を減らすことが、実は最も効果的な対策になる。 レガシー基盤と向き合い続けている日本の現場にとって、今回の件は「明日は我が身」の警告として受け止めてほしい。 出典: この記事は CISA flags Apache ActiveMQ flaw as actively exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エンドポイント保護ツールを導入していれば安心——そんな前提が今また崩されつつある。セキュリティ企業Sophosが最近公開したレポートで、「Payouts King」と呼ばれるランサムウェアグループがQEMUという正規のオープンソース仮想化ツールを悪用し、感染端末の上に隠し仮想マシン（VM）を展開することでエンドポイントセキュリティを完全に回避している実態が明らかになった。 QEMUを「隠れ蓑」にする攻撃の仕組み QEMUはLinuxやWindowsの開発者に広く使われているCPUエミュレータ・システム仮想化ツールだ。その特性上、ホスト側のセキュリティソリューションはVM内部をスキャンできない。これを逆手に取ったのが今回の手口である。 攻撃者は感染端末に侵入後、TPMProfiler という名前のスケジュールタスクを作成し、SYSTEMユーザー権限でQEMU VMをひっそりと起動する。仮想ディスクはデータベースファイルやDLLファイルに偽装されており、一見すると正規ファイルと区別がつかない。 VM内部ではAlpine Linux 3.22.0が動作しており、以下のような攻撃ツール一式が搭載されている。 AdaptixC2 — コマンド＆コントロール（C2）フレームワーク Chisel — リバースSSHトンネリングツール BusyBox — 軽量Unixコマンドセット Rclone — クラウドストレージへのデータ持ち出しツール リバースSSHトンネルを通じてVM内から外部C2サーバーへの通信が確立されるため、ホスト側のネットワーク監視をも回避できる。QEMUによるVM悪用の手口は3AMランサムウェアやLoudMinerなど過去の事例にも見られるが、Payouts Kingはそれをより洗練させた形で組み込んでいる。 多彩な初期侵入経路——VPNからTeamsまで Sophosが追跡するSTAC4713キャンペーン（2025年11月以降観測）では、初期アクセスにさらされた状態のSonicWall VPN、およびSolarWinds Web Help Desk脆弱性（CVE-2025-26399）が悪用されている。 注目すべきは、より新しい攻撃手法としてMicrosoft Teamsを使ったソーシャルエンジニアリングが確認されていることだ。攻撃者はITスタッフを装って従業員に接触し、QuickAssist（Windowsに標準搭載のリモートサポートツール）をダウンロード・実行させる。これはかつてBlackBastaグループが多用した手口と一致しており、ZscalerのレポートによればPayouts KingはBlackBastaの元アフィリエイトメンバーによって運営されている可能性が高い。 侵入後はvssuirun.exeでVSSシャドウコピーを作成し、NTDS.dit・SAM・SYSTEMハイブといったドメイン認証情報の宝庫を抜き取る。暗号化にはAES-256（CTR）＋RSA-4096を採用し、大容量ファイルには断続暗号化（intermittent encryption）を使うことで処理速度を確保しながら検出を困難にしている。 実務への影響——日本のIT管理者が今すぐ見直すべきこと 1. 正規ツールの実行制御を強化する QEMU、Rclone、Chiselはいずれも正規の業務ツールとして使われることがある。これらを一律に禁止するのではなく、「誰が・どのマシンで・いつ」実行するかを管理する仕組みが必要だ。Windows Defender Application Control（WDAC）やAppLockerによるアプリケーション許可リスト管理を改めて見直してほしい。 2. Teams経由のソーシャルエンジニアリングに備える 「ITサポートからTeamsでメッセージが来たのでQuickAssistを起動した」という経路での侵害は、技術的な脆弱性ではなく運用上の隙を突いている。ヘルプデスクが正規の手順でどこからアクセス要求するかをユーザー教育として徹底しておく必要がある。 3. エンドポイントだけに頼らない多層防御の再確認 VM内部はエンドポイントセキュリティの視野外になる。ネットワーク層でのC2通信の検知（不審な外向きSSHトンネル等）、認証層でのドメイン認証情報の異常利用検知、そして認可層でのJust-In-Time特権管理を組み合わせることが、このような迂回攻撃への現実的な対抗手段になる。 4. VPNの露出面を縮小する STAC4713もSTAC3725もVPN装置の脆弱性を初期アクセスに使っている。SonicWall、Citrix NetScalerともにパッチの適用状況と公開ポートの棚卸しを早急に行ってほしい。 筆者の見解 この手口が示しているのは、「エンドポイントにエージェントを入れれば守れる」というモデルの限界だ。QEMUのような正規ツールをVM起動に使われると、プロセス監視ベースのEDRはその中身を見ることができない。攻撃者は常に「セキュリティツールが見ていない場所」を探しており、今回はそれが仮想化レイヤーだった。 ゼロトラストアーキテクチャの本質は「ネットワーク内にいるから信頼する」を廃止することにある。今回の攻撃でも、VM内からリバースSSHトンネルが外向きに張られた時点でネットワーク異常として検知できた可能性がある。ホスト側のEDRが無力化されても、ネットワークトラフィック分析・Identity保護・SIEM連携の組み合わせが機能していれば早期発見の余地はあった。 Teams経由のQuickAssist悪用については、正直なところMicrosoftには引き続き改善を期待したい。Quick Assistはエンタープライズ向けのセキュリティ制御オプションが強化されてきているが、「見知らぬ相手からのセッション要求を普通のユーザーがどう判断するか」という設計上の課題はまだ残っている。ユーザーが公式に提供された手段を最も安全に使える状況を整えてこそ、禁止に頼らない現実的なセキュリティが実現する。Microsoftがその方向でさらに踏み込むことを期待している。 エンドポイント一点に賭けるのは、もはや通用しない。多層防御の見直しを今すぐ始めてほしい。 出典: この記事は Payouts King ransomware uses QEMU VMs to bypass endpoint security の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が Microsoft Entra ID に待望のバックアップ・リカバリ機能を追加した。Entra 管理センター上でパブリックプレビューとして公開されたこの機能は、ディレクトリオブジェクトの自動バックアップと復元を標準で提供するものだ。「いつか必要になる」と分かっていながら、これまでサードパーティ製品や自前スクリプトで賄ってきた組織には、シンプルに朗報である。 何ができるようになったのか Microsoft Entra Backup and Recovery は、サポート対象のディレクトリオブジェクトを 1日1回自動的にバックアップし、最大5日分のスナップショットを保持する。管理者は Entra 管理センターから GUI 操作で過去のバックアップを参照し、誤って削除または変更されたオブジェクトを復元できる。 特に有効なシナリオとして想定されているのは以下の通りだ。 運用ミスによる誤削除: ユーザーアカウント・グループ・ロール割り当てなど、「消してから気づく」パターン セキュリティインシデント後の復旧: 攻撃者による不正変更や、条件付きアクセスポリシーの改ざん後の原状回復 構成変更の切り戻し: 設定変更が思わぬ副作用を生んだときのロールバック 現時点ではパブリックプレビューのため、対象オブジェクトの種類や復元の粒度に制限がある可能性がある。GA（一般提供）に向けてスコープが広がることが期待される。 なぜこれが重要か Entra ID（旧 Azure AD）は、Microsoft 365・Azure・Intune など多くのサービスの認証・認可の起点となるアイデンティティ基盤だ。ここに格納されるオブジェクトは「すべてのサービスへの鍵」に等しく、誤削除や不正変更のインパクトは計り知れない。 従来、Microsoft が提供する標準機能としては「ごみ箱（Recycle Bin）」があり、削除から30日以内であれば一部のオブジェクトは復元可能だった。しかし、削除以外の変更（たとえば条件付きアクセスポリシーの書き換えやグループメンバーシップの変更）には対応しておらず、タイムトラベル的な「変更前の状態への復元」は難しかった。 そこを補完するために、Entra Exporter のようなコミュニティツールや、Microsoft Graph API を叩く自前スクリプトで定期バックアップを実装している組織は少なくない。今回の機能はそれを ネイティブ機能として提供する点で価値がある。 実務への影響——日本の IT 管理者が押さえるべきポイント 1. 既存のサードパーティ製バックアップ製品との関係を整理する すでに Entra ID バックアップ目的でサードパーティ製品（例：IDFIX, Semperis DSP, AvePoint 等）を導入している組織は多い。今回の標準機能は「5日間保持・1日1回」というシンプルな仕様であり、監査ログとの突合、変更履歴の可視化、長期保持といった要件は引き続きサードパーティが担う場面が残るだろう。ただし「とりあえずバックアップがあれば十分」なレベルの用途では、コスト削減の検討材料になり得る。 2. バックアップの存在を「セキュリティインシデント対応手順書」に組み込む インシデントが起きてから「どこで何を復元できるか」を調べるのでは遅すぎる。今回の機能の存在をインシデントレスポンス手順書に明記し、Entra 管理センターの操作を事前に演習しておくことを推奨する。特に、条件付きアクセスポリシーが攻撃者に書き換えられた場合の復旧シナリオは一度通しで確認しておくべきだ。 3. Just-In-Time アクセスと組み合わせて多層防御を バックアップはあくまで「事後対応」の手段だ。「誤削除・改ざんをそもそも減らす」という観点では、Entra PIM（Privileged Identity Management） によるロール割り当ての時限化（Just-In-Time）や、重要な変更に対する多要素認証・承認フローの整備が先行すべき対策である。「常時アクセス権の付与は最大のリスク」という原則は、どれだけ優れたバックアップがあっても変わらない。 筆者の見解 正直に言えば、「なぜこれを5年前に作らなかったのか」 という気持ちを抑えることが難しい。Entra ID はすでに世界中の何十万という組織のアイデンティット基盤として稼働している。「バックアップはサードパーティで」という状況がこれだけ長く続いてきたことは、プラットフォームの信頼性という観点でもったいなかったと思う。 ...

April 2026のWindowsセキュリティ更新プログラムを適用したドメインコントローラーが再起動を繰り返す——。Microsoftがこの重大な不具合を公式に認定した。Active Directory環境を運用するIT管理者は、今すぐ対応状況を確認する必要がある。 何が起きているか 2026年4月のセキュリティ更新プログラム KB5082063 を適用したWindows Serverドメインコントローラーで、LSASS（Local Security Authority Subsystem Service） がクラッシュし、システムが再起動ループに陥るという深刻な不具合が報告されている。Microsoftはこの問題を正式に確認した。 LSASSはWindowsの認証基盤を担うコアプロセスだ。ローカルログオン、Active Directoryの認証、グループポリシーの適用など、Windowsドメイン環境の根幹をなす。これがクラッシュするということは、ドメインコントローラーとしての機能が完全に失われることを意味する。業務全体の停止に直結する最上位クラスの障害だ。 影響範囲 既存のドメインコントローラー: KB5082063を適用後にLSASSクラッシュ → 再起動ループ 新規デプロイのドメインコントローラー: 新しく展開した環境にも同様の問題が発生する可能性がある 新規デプロイにも影響が出るという点が特に厄介だ。通常、問題のある更新プログラムへの対処として「クリーンな環境に再デプロイ」という選択肢があるが、今回はその手が使えない可能性がある。リカバリーと展開作業の両面で制約が生じている状況だ。 現時点での対処方法 Microsoftのサポート情報を随時確認しつつ、以下の対応を検討してほしい。 1. 未適用環境：適用を保留する KB5082063をまだ適用していない環境では、修正済み更新プログラムがリリースされるまで適用を控えることを強く推奨する。 2. 適用済みで再起動ループ中の場合 ディレクトリサービス復元モード（DSRM） で起動し、問題の更新プログラムをアンインストールする。このためにDSRMパスワードが管理されていることが前提になる。管理されていない場合は……今すぐ確認せよ。 3. 複数DCがある環境 影響を受けていないドメインコントローラーで認証を継続させながら、問題のあるDCを切り離してリカバリーを行う。これが冗長化の本来の意味だ。 実務への影響 — 日本のIT管理者へ 日本のエンタープライズ環境では、いまだに多くの組織がActive Directoryをオンプレミスで運用している。ドメインコントローラーが再起動ループに陥ると、ユーザーはネットワークリソースへのアクセスができなくなり、業務が全面停止する。 明日から取れる具体的なアクション： パッチ管理フローを見直す: セキュリティ更新を即時適用するポリシーになっている場合、テスト環境での事前検証ステップが機能しているか確認する DSRMパスワードを確認・棚卸しする: 今回のような再起動ループへの最後の砦がDSRMだ。パスワードが適切に管理・記録されているか今すぐ確認せよ DCの冗長性を確認する: ドメインコントローラーが1台しかない環境は、こういった事態で完全に詰む。最低2台は必要だ Microsoftサービスヘルスとリリースノートを購読する: Windows ServerのリリースノートとMicrosoft Tech Communityのブログは、定期的に確認できる仕組みを整えておく 筆者の見解 セキュリティ更新プログラムの適用がこれだけのインパクトを持つ障害を引き起こすのは、正直「もったいない」の一言だ。Microsoftには世界最高水準の品質保証体制と検証プロセスがあるはずで、こういった問題が本番環境に流れ出る前に食い止める力のある会社のはずだ。 今回の件が改めて示すのは、「パッチ管理は仕組みで回せ」 というメッセージだ。セキュリティ更新プログラムを適用しないことは別のリスクを生む。だからといって盲目的な即時適用も危険だ。「テスト環境で検証してから本番展開」という当たり前のプロセスが、多くの現場でまだ機能していないのが現実だ。 「今動いているから大丈夫」——これは永遠に通用しない。DSRM、DCの冗長化、イベントログの監視体制——こういった備えは有事が起きてから調べるものではなく、日常の運用として整えておくべきものだ。今回の障害をきっかけに、自分たちのActive Directory運用の「有事対応力」を棚卸しする機会にしてほしい。 Microsoftには一刻も早い修正済み更新プログラムのリリースを期待したい。そして今後は、このクラスの問題がリリース前に検出されるような品質プロセスをさらに強化してほしい。実力は間違いなくある会社なのだから、こういう形で信頼を損なうのは本当にもったいない。 出典: この記事は Microsoft Confirms LSASS Crash Bug Causing Reboot Loops on Windows Server の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIが生成するテキスト・画像・音声が爆発的に増え続ける今、「相手が本当に人間なのか」という問いはもはや哲学的な話ではなく、実務上の課題になりつつある。Sam AltmanがTools for Humanity（TFH）を通じて推進する「World」プロジェクトが、その答えの一つとして急速に存在感を高めている。 サンフランシスコのイベント会場で開催された発表会では、TinderへのグローバルWold ID統合、コンサートチケット向け「Concert Kit」、Zoom・DocuSignとの連携など、多数の新展開が一気に明らかになった。 Worldとは何か——虹彩スキャンとゼロ知識証明の組み合わせ Worldの根幹は「Orb」と呼ばれる球体デバイスだ。ユーザーの虹彩をスキャンし、その特徴を匿名の暗号識別子（World ID）に変換する。重要なのは、この識別子がゼロ知識証明（Zero-Knowledge Proof）を利用するため、「この人物が本当に生身の人間であること」は証明できても、「この人物が誰であるか」は漏洩しない設計になっている点だ。 匿名性を保ちながら「ヒトであること」だけを証明する——この一点に、Worldの技術的な独自性がある。 新たな展開：デーティングアプリからコンサートチケットまで Tinder：日本パイロットから世界展開へ 今回の目玉は、TinderへのWorld ID統合のグローバルロールアウトだ。実は日本では昨年にパイロットプログラムが実施済みであり、その成功を受けて米国を含むグローバル市場への展開が決まった。World ID認証を完了したユーザーのプロフィールには専用の認証バッジが付与され、「実在する人間」であることが他のユーザーから視覚的に確認できるようになる。 なりすましや詐欺的なボットプロフィールが横行するデーティングアプリでの活用は、非常に理にかなったユースケースだ。 Concert Kit：ボットによるチケット転売対策 長年エンターテインメント業界を悩ませてきた自動購入ボットによるチケット転売問題に対応するのが「Concert Kit」だ。アーティストが一定数のチケットをWorld ID認証済みのファン向けに確保できる仕組みで、TicketmasterやEventbriteと互換性がある。30 Seconds to MarsやBruno Marsがツアーでの活用を表明しており、今後普及が見込まれる。 ZoomとDocuSign：ビジネス文書・会議への展開 ビジネス領域では、ZoomへのWorld ID統合によるビデオ会議の参加者認証と、DocuSignとの連携による電子署名の本人確認が発表された。特にZoom連携はディープフェイクを使った「なりすまし会議」への対策として位置づけられており、企業のリスク管理観点から注目を集めるだろう。 エージェント委任：AIエージェント時代を見据えた新機能 今回の発表の中でもとりわけ先進的なのが「Agent Delegation（エージェント委任）」だ。ユーザーが自分のWorld IDをAIエージェントに委任し、そのエージェントがWeb上でユーザーに代わって各種タスクを実行できる仕組みだ。認証サービスOktaとの連携では、「特定のエージェントが特定の人間の代理として行動している」ことを検証できるシステム（現在ベータ版）も整備された。 実務への影響——日本のエンジニア・IT管理者が押さえるべきこと 今すぐ使える視点 Tinder Japanでのパイロット実績があることから、国内でのWorld ID展開は他国より早い可能性がある。デーティングアプリやSNSの運営・開発に携わるエンジニアは技術仕様を確認しておきたい Zoom連携は日本企業でも活用できる。なりすましや詐欺的なビデオ通話のリスクを抱える金融・法務領域での採用が先行するかもしれない Agent Delegationは現在ベータ段階だが、AIエージェントを業務フローに組み込む設計をしているチームは、「エージェントの行動をどう認証するか」という問いを早めに検討すべきだろう プライバシーと規制の観点 虹彩情報は生体情報（バイオメトリクス）であり、日本の個人情報保護法上でも要配慮個人情報に該当しうる。GDPRが適用される欧州では規制当局との摩擦が続いており、日本国内での展開においても規制動向を注視する必要がある ゼロ知識証明により「誰か」は特定されないとはいえ、虹彩データの収集・管理体制について利用者への丁寧な説明は不可欠だ 筆者の見解 AIエージェントが人間の代わりにWebを巡回し、予約・購入・契約を行う時代は、もはや近未来の話ではない。実際に今年に入ってから、自律的に動くエージェントを業務に組み込もうという動きが現場で急加速している。 そのとき必然的に浮上するのが「このエージェントの背後に本当に人間がいるのか」「誰が責任を持つのか」という問いだ。Worldが発表したAgent Delegation + Okta連携は、まさにこの問いへの具体的な答えの一つで、技術的には非常に筋が良いと感じる。 かつて「メールの送り主が人間かどうか」を気にする必要はなかった。しかし今後は、オンラインのあらゆるインタラクションにおいてその確認が求められる場面が増えていく。Worldが構築しようとしているのは、そのための社会インフラだ。 生体情報の扱いに対する懸念は正当であり、World側もゼロ知識証明による匿名性確保に力を入れている。とはいえ、「Orbに目を向けることへの心理的ハードル」は依然として高く、特に日本のユーザーには慎重な訴求が必要だろう。 AIが増殖するほど「ヒト証明」の価値は上がる。逆説的だが、AIが強くなるほどWorldのような仕組みは不可欠になる。Tinderからコンサートチケット、そしてビジネス文書や自律エージェントへと展開するロードマップは、一見バラバラに見えて実は一本の軸でつながっている。今後のアイデンティティ管理を考えるうえで、目が離せないプロジェクトだ。 出典: この記事は Sam Altman’s project World looks to scale its human verification empire. First stop: Tinder. の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが一時「AIを絞る」と発表した直後に、AIエージェントのタスクバー統合を改めて確認した。矛盾しているように見えるが、実はそうではない。「不要なCopilotの入口を減らす」と「有用なエージェント体験を作る」は、両立しうる話だ。2026年4月17日にリリースされたWindows 11 Build 26200.8313（Release Previewチャネル）には、サードパーティエージェントに対応したエージェント型タスクバーが含まれている。 タスクバーに何が変わるのか タスクバー上のMicrosoft 365 Copilotアイコンにカーソルを合わせると、動作中のエージェントを監視・操作できるUIが表示される。現時点で目玉となるのが「Microsoft 365 Researcher」だ。ChatGPTやGeminiが提供するDeep Researchに相当する機能で、複数ステップにわたる調査タスクを自律的に実行する。さらに、OneDriveやMicrosoft 365にアップロードされた自社ファイルへのアクセスが可能なため、社内ドキュメントを参照したレポート生成が実現する。なお、この機能はMicrosoft 365 Copilotのサブスクリプションが必要だ。 MCPという「共通規格」の意味 注目したいのはアーキテクチャだ。今回のエージェント統合はModel Context Protocol（MCP）を基盤としている。MCPはAIモデルやエージェントが既存のアプリ・ファイル・OSと接続するための共通規格であり、開発者はMCPを介して自社エージェントをWindows 11のタスクバーに組み込める。OS側に用意されたAPIはWindows.UI.Shell.Tasksだ。 この設計は重要な意味を持つ。特定ベンダーのエージェントだけが動く閉じた世界ではなく、サードパーティが参加できるエコシステムとして構築されている。将来的にエンタープライズ向けの業務エージェントをタスクバーから直接起動できるようになれば、OSとビジネスプロセスの統合が一段と進む。 「任意有効化」という設計判断 もう一つ重要なのが、この機能がオプション扱いであることだ。自動有効化はせず、Copilotを使うよう促す通知も出さない。以前のWindowsのように機能を半強制的に押し込んで反発を招いたパターンとは明らかに異なるアプローチだ。 「Ask Copilot」という新しい検索体験では、@を使ってエージェントを呼び出せる。@を入力するとPC上で利用可能なエージェントの一覧が表示され、選択して実行できる。ただし、この機能のリリース時期はまだ確定していない。 実務への影響——IT管理者・エンジニアが考えるべきこと 企業のIT管理者へ 現時点ではRelease Previewチャネルの話だが、今のうちに「タスクバーにエージェントが表示された場合の運用ポリシー」を考えておく価値がある。オプション機能とはいえ、M365 CopilotライセンスのあるテナントではResearcherが使えるようになる可能性が高い。どのエージェントを許可するか、社内文書へのアクセス範囲をどう設計するかは、早めに議論しておきたい。 開発者・ISVへ MCPとWindows.UI.Shell.Tasks APIを使えば、自社サービスをWindowsのシェルレベルで統合できる。業務アプリとOSの境界が溶けていく流れは、アプリ開発の設計思想そのものを変える可能性がある。Microsoftが公開するAPI仕様は早めに追っておきたい。 エンドユーザーへ しばらくは「Release Preview → 一般公開」のサイクルを静観する時間がある。新機能は焦って有効化せず、職場のポリシーを確認してから利用を判断するのが賢明だ。 筆者の見解 Microsoftが「AIを絞る」と言いながらエージェントを追加する動きは、一見ちぐはぐに見える。しかし今回の発表を読むと、単なる揺り戻しではなく、実装の質を上げながら前進しようとしている意図が見える。任意有効化・MCP基盤・サードパーティ開放という3点は、以前の「とにかくCopilotを全面に出す」路線とは異なるアプローチだ。 MCPをOSレベルに組み込むというアイデアは技術的に面白い。エージェントがOSのシェルと統合されれば、ファイル操作・検索・外部サービス連携が一気通貫になる。Microsoftが持つWindowsのユーザーベースとエンタープライズの信頼を活かせば、ここは本来最も強く出られる領域のはずだ。 だからこそ、実装の丁寧さを維持してほしい。エージェントがOS上で動くということは、ユーザーのファイルや業務データに深くアクセスすることを意味する。セキュリティモデルの設計——どのエージェントに何を許可するか、企業管理者がどこまで制御できるか——が粗ければ、エコシステムが広がるほどリスクも拡大する。MCP統合の利便性と権限管理の堅牢さを両立できるかが、この機能の本当の評価軸になるだろう。 Windowsをプラットフォームとして再定義しようとする今の試みが実を結ぶかどうか、引き続き注視していきたい。 出典: この記事は Microsoft confirms AI agents are still coming to the Windows 11 taskbar as it prepares for public rollout の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIマーケティングスタートアップのHightouchが、年間経常収益（ARR）1億ドル（約150億円）の突破を発表した。とりわけ目を引くのは成長速度だ——AIエージェントプラットフォームの投入からわずか20ヶ月で7,000万ドル（約105億円）の収益増加を達成している。これは単なるビジネスの成功話ではない。「汎用AIの限界をどう乗り越えるか」という、今まさに多くの企業が直面している問いへの、一つの明確な回答でもある。 なぜ汎用モデルはマーケティングに使えなかったのか 多くの企業が最初に試みたのは、汎用基盤モデルをそのまま使って広告素材を生成することだった。しかし結果は惨憺たるものだったと、HightouchのCo-CEOであるKashish Guptaは語る。「LLMは存在しない製品をハルシネーションしてしまう。存在しない製品の広告は打てない」。 ブランドカラー、フォント、トーン、既存の商品素材——汎用モデルはこれらの情報を持っていない。Domino’sのピザを生成しようとすれば、実際のDomino’sとは似ても似つかない画像が出てくる。これは「AIが使えない」のではなく、「正しいコンテキストを与えていない」という設計の問題だ。 HightouchのアプローチーーブランドDNAをAIに注入する Hightouchが採ったアプローチはシンプルだが本質的だ。Figma、社内CMS、フォトライブラリなど、企業がすでに保有しているデザインツールと直接連携し、ブランドのアイデンティティをAIが参照できる形で与える。 Domino’sの実例が分かりやすい。「Domino’sはピザを生成することは絶対にない。常に既存のピザ画像を使い、その周囲の背景やその他の要素だけをAIで生成する」とGuptaは説明する。 つまり「全部AIで作る」のではなく、信頼できる既存素材＋AI生成の組み合わせによって、ブランドの一貫性を保ちながら大量のパーソナライズドコンテンツを生み出す仕組みだ。RAG（Retrieval-Augmented Generation）の概念をマーケティング実務に応用したものと捉えると分かりやすい。 実務への影響——日本のマーケティング現場への示唆 デジタルマーケティングのコスト削減と品質維持の両立に苦慮する日本企業は多い。Hightouchのアプローチから学べる実務ポイントを整理する。 既存アセットの整備が先決 AIエージェントが「ブランドを学習」するためには、まず企業側の素材が整理・デジタル化されていることが前提だ。Figmaや社内CMS、商品画像ライブラリを適切に管理することが、AIを活用するための土台になる。 「禁止」ではなく「安全に使える仕組み」を構築する 「AIで生成した画像は使わない」という方針では競合に遅れをとるだけだ。ブランドガイドラインをAIに組み込む仕組みを作ることで、品質を担保しながら自動化の恩恵を受けられる。 デザイナーの役割が変わる 毎回一から素材を作る必要はなくなる。代わりに、AIが学習するためのブランドアセット設計・管理と、生成結果の品質評価・フィードバックが主要な役割へと移行していく。 筆者の見解 Hightouchの成功が示しているのは、AIを「正しく使う」とはどういうことかを端的に表している。汎用モデルにそのまま仕事をさせるのではなく、業務文脈・ブランド情報・企業固有の知識をきちんと与えた上で自律的に動かす——この設計思想こそが本質だ。 私が日々実感しているのも同じことで、AIエージェントに「やったことと、その結果をきちんと評価できる仕組み」を与えれば、自律的に改善を繰り返して合格点の成果を出せるようになっている。完全情報ゲームでなくても、もうかなりその段階に来ている。 「副操縦士として人間が逐一確認するモデル」から、「エージェントが自律的に判断・実行・検証を繰り返すハーネスループ」へ——この転換こそが今のフロンティアだ。Hightouchはマーケティング領域でそれをビジネスとして証明した。 日本のIT現場では、まだ「AIを試してみた」段階の企業が多い。しかし競争環境は急速に変わっている。Hightouchの20ヶ月で70億円という成長速度を見れば、AIエージェントへの本格投資を先延ばしにするコストがいかに大きいか、肌で感じてほしい。情報を追うだけでなく、自分たちの業務文脈をAIに与えて実際に回す経験を積む——それが今最も重要な一歩だ。 出典: この記事は Hightouch reaches $100M ARR fueled by marketing tools powered by AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがAIテキスト読み上げ（TTS）分野で新たな一手を打ってきた。「Gemini 3.1 Flash TTS」は、単に「機械音声の精度が上がった」という話ではない。音声表現の制御権をアプリケーション開発者に渡すという設計思想の転換点として注目に値する。 Gemini 3.1 Flash TTSとは何か 本モデルは、テキストを音声に変換するAIモデルの最新版だ。従来の読み上げエンジンとの最大の差異は「表現力の制御粒度」にある。 音声タグ（Audio Tags）——自然言語で声を演出する 最も注目すべき機能が「音声タグ」だ。テキスト入力の中に自然言語のコマンドを埋め込むことで、声のトーン・ペース・アクセントを細かく指示できる。たとえば「ここはゆっくり、懸念を含んだ口調で」といった指示をテキストに織り込むと、モデルがそのニュアンスを解釈して発話する。 これは「プロンプトで音声を演出する」という新しい設計パターンであり、従来のSSML（Speech Synthesis Markup Language）に慣れた開発者には馴染みやすく、かつより表現力豊かだ。 複数話者ダイアログとシーン設定 「シーン方向性（Scene Direction）」機能では、環境設定や場面指示を事前に与えることで、複数キャラクターが会話形式で自然に応答し合う音声を生成できる。ポッドキャスト的コンテンツや教育用ダイアログ、カスタマーサポートのロールプレイなど、応用範囲は広い。 品質と対応言語 第三者評価機関「Artificial Analysis」のTTSリーダーボードでEloスコア1,211を記録し、「高品質かつ低コスト」の象限に位置付けられている。対応言語は70言語以上で、日本語も含まれる。 SynthID透かし——AI音声の識別可能性を確保 生成された音声にはSynthIDによる不可視の電子透かしが付与される。フェイクニュースや詐欺音声への悪用リスクを考慮した実装だ。AI生成コンテンツの信頼性管理が問われる昨今、この機能の意義は大きい。 利用可能なプラットフォーム 現在プレビューとして以下で利用できる： Gemini API / Google AI Studio — 開発者向け。音声タグの実験やボイスプロファイルの設定・エクスポートが可能 Vertex AI — エンタープライズ向け。本番統合を想定した構成 Google Vids — Workspaceユーザー向け。動画制作ツールへの組み込み 実務への影響——日本のエンジニア・IT管理者にとっての意味 API統合で音声UXを手に入れる Gemini APIを通じてTTSをアプリに組み込む選択肢が増えた。社内向けナレーション、マニュアルの音声化、チャットボットの応答音声など、これまでコストが高くて見送っていたユースケースが手が届く範囲に入ってくる。 多言語対応の実用性 70言語以上の対応は、グローバル展開が必要なシステムや、外国語コンテンツの日本語音声化ニーズに応える。ただし、日本語の自然さについては実際のテストが不可欠だ。英語圏向け評価指標のEloスコアがそのまま日本語品質を保証するわけではない。 SynthIDのガバナンス価値 企業がAI生成音声を利用する際、「それが本物の人間の声か」を証明・否定できる仕組みは、コンプライアンス観点でも重要性を持つ。特に金融・法務・医療分野での活用を検討する際は、このトレーサビリティが信頼性の根拠になり得る。 筆者の見解 TTS分野において、Googleが「制御インターフェースの設計」に本気で取り組んできたことは認めていい。音声タグという概念は、プロンプトエンジニアリングの知見を音声生成に応用したものであり、開発者が「声の演出家」として働ける環境を整えようとする意図が見える。 一方、正直に言えば「実際に触ってみるまでわからない」が私の率直な感想だ。ベンチマークのEloスコアが高いことと、日本語のビジネス用途で使いものになることは別の話だ。特にTTSは言語ごとにアクセント・イントネーションの難しさが異なり、評価指標と体験品質の乖離が大きい領域でもある。 音声AIの実用化において今重要なのは「どのモデルが最高スコアか」ではなく、「自分のユースケースに合うモデルをどう選び、どうワークフローに組み込むか」という問いだ。音声生成を真剣に検討しているチームは、Google AI Studioで実際に触りながら、自社の判断基準で評価することを強く勧めたい。 AI音声のコモディティ化は着実に進んでいる。数年前は専用の音声合成システムに数百万円をかけていた領域が、APIコールで完結する時代になっている。この波をどう業務に活かすかを考える好機だ。 出典: この記事は Gemini 3.1 Flash TTS: the next generation of expressive AI speech の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAI が Agents SDK の大幅アップデートを発表した。目玉は2つ——ネイティブサンドボックス実行とモデルネイティブハーネスだ。「エージェントが自律的に長時間動き続ける」という設計思想そのものが前面に出てきた形で、自律型 AI エージェントの開発を本格的に進めたいエンジニアにとって、見逃せないアップデートである。 ネイティブサンドボックス実行の意味 従来の AI エージェント開発では、コード実行環境の安全性確保が大きな課題だった。エージェントが動的にコードを生成・実行する際、ホスト環境への影響をどう遮断するかは開発者が個別に実装する必要があった。 今回の「ネイティブサンドボックス実行」は、この課題を SDK レベルで解決するアプローチだ。エージェントがファイル操作やコード実行を行う際に、分離された安全な環境内で処理が完結する。本番環境やホスト OS への意図せぬ書き込み・破壊が防止できるため、エンタープライズ用途での実用化を大きく前進させる。セキュリティポリシーが厳しい日本企業においても、「エージェントにコードを実行させる」という提案が組織内で通りやすくなるはずだ。 モデルネイティブハーネスとは何か もう一つの柱が「モデルネイティブハーネス」だ。 ハーネスとは、エージェントが「判断→実行→検証→次の判断」というループを自律的に回し続けるための仕組みを指す。これまでは開発者がこのループを自前で設計・実装する必要があり、実装の品質や堅牢性は開発者のスキルに大きく依存していた。 「モデルネイティブ」という言葉が示すとおり、今回のアップデートではこのループ設計がモデル側に内包される。開発者は目的を定義するだけでよく、ループ管理の煩雑な実装から解放される。結果として、長時間にわたって複数のファイルやツールをまたいで動き続けるエージェントが、より少ないコードで実現できるようになった。 実務への影響 エンタープライズ開発者へ サンドボックス実行の標準化は、社内展開における審査コストの削減につながる。セキュリティレビューで「コード実行の影響範囲はどこまでか」を説明する際、SDK レベルの保証として提示できることは大きい。承認プロセスを持つ日本企業にとって、これは実務上の導入障壁を下げる効果がある。 システムアーキテクトへ ハーネスループの標準化は、アーキテクチャ設計の変化を意味する。「人間が承認ボタンを押すたびに処理が進む」設計から、「エージェントが自律的に完走し、完了報告だけが来る」設計へのシフトを本格的に検討する時期に来ている。 スタートアップ・個人開発者へ 長時間稼働エージェントの実装コストが下がることで、「24時間無人で動き続けるワークフロー自動化」が個人レベルでも現実的になる。ツールとインフラさえ用意できれば、仕組みを回すのは AI に任せる——そういう働き方が加速する。 筆者の見解 AI エージェント開発の文脈で、「ハーネスループ」は今まさに最も重要なテーマだと考えている。エージェントが単発の指示に応答するだけでなく、自律的に判断・実行・検証のループを回し続けられるかどうか——これが「本物のエージェント」と「チャットボットの延長線」を分ける境界線だ。 今回の Agents SDK のアップデートは、その境界線を越えるための実装コストを大幅に下げた意義がある。特にモデルネイティブハーネスの発想——ループの設計責任をモデル側に引き渡す——は正しい方向性だと思う。開発者が「どうループを回すか」ではなく「何を達成させるか」に集中できる状態こそが、エージェント開発の本来あるべき姿だ。 日本のエンタープライズ環境では、まだ「AI に自律的に動かせる」という発想が浸透していない現場が多い。しかし、SDK レベルの安全機構が整備されることで、「人間の承認を介在させずに動かす」という判断を組織内で通しやすくなるはずだ。AI が自律的に動き続ける仕組みを設計できる人材の価値は、今後ますます上がっていく。このアップデートを機に、ハーネスループの設計パターンを実際に手を動かして試してみることを強くお勧めする。 出典: この記事は The next evolution of the Agents SDK の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「ライブネスチェック」が90秒で突破される現実 カンボジアのマネーロンダリングセンターで、一人の従業員がベトナム系銀行アプリを開く。本人確認のため顔写真のアップロードを求められると、アカウント所有者とは似ても似つかない女性の静止画を差し出す。それでも「ライブネスチェック（本人がカメラの前にいることを確認する動的検証）」を90秒でパスしてしまった——MIT Technology Reviewがサイバー詐欺研究者への取材をもとに報じた、衝撃的な事例だ。 この手口の核心は「仮想カメラ（Virtual Camera）」ツールにある。スマートフォンのカメラ入力を乗っ取り、ライブ映像の代わりに任意の静止画や動画を差し込める。ディープフェイク映像を使えば精度はさらに上がる。そしてこうしたバイパスツールが、Telegramの公開チャンネルで堂々と販売されている。 Telegramに22チャンネル——Binanceや大手銀行も標的 MIT Technology Reviewは約2ヶ月の調査で、中国語・ベトナム語・英語の22チャンネル・グループを特定した。Binanceのような主要暗号資産取引所から、スペインのBBVAといった名だたる銀行まで、幅広いKYC（Know Your Customer）検証をバイパスするキットが出品されていた。 「銀行サービス専門——汚れた金を扱います。安全・プロ・高品質」と書かれたTelegramの自己紹介文まで存在した。Telegramは報告を受けてアカウントを削除したと述べているが、類似のマーケットプレイスはすぐ復活する構造的問題がある。 こうした悪用の背景にあるのが「ピッグ・ブッチャリング（豚の丸焼き）詐欺」と呼ばれる手口の拡大だ。仮想通貨詐欺・不正送金の被害額は2025年に約170億ドル（約2.5兆円）に達し、前年の130億ドルから急増。東南アジアのアフリカ・太平洋地域への拡大も国連薬物犯罪事務所（UNODC）が警告している。 なぜこれが重要か——生体認証への「過信」が最大のリスク KYCの顔認証・ライブネスチェックは、金融犯罪対策の「最後の砦」として多くの金融機関が採用を進めてきた。日本でも犯罪収益移転防止法（犯収法）に基づくeKYCが普及し、スマートフォンで完結する本人確認が標準になりつつある。 問題は、こうした仕組みへの信頼が「技術的に突破不可能」という前提の上に成り立っていることだ。仮想カメラツールの存在が示すのは、OSレベルのカメラ入力を制御できれば、アプリ側のチェックはほぼ無力化できるという現実だ。Androidの場合はルート化・カスタムROMの悪用、iOSでも一部ジェイルブレイクやAPIフックによる攻撃ベクターが存在する。 実務への影響——IT管理者・セキュリティ担当者が取るべきアクション 1. eKYC導入・見直し時は「デバイス整合性検証」を必須要件に ライブネスチェック単体ではなく、デバイスの完全性（root化・ジェイルブレイク検知、Play Integrity API / App Attest）の確認をセットで実装しているかを確認すること。バイパスツールはOS層への介入が前提なので、デバイス整合性チェックが最初の防衛線になる。 2. 行動ベースの異常検知を組み合わせる 顔認証の一点突破ではなく、ログイン時刻・場所・操作パターンといった行動分析との組み合わせが現実的な対策。単一の認証強化に頼ると、その手法が破られた瞬間に全体が崩れる。 3. Telegramを「脅威インテリジェンス」として監視する セキュリティチームは、Telegramの日本語・英語・中国語チャンネルを脅威インテリジェンスの観測対象に加えることを検討したい。攻撃ツールの販売動向をモニタリングすることで、新たなバイパス手法の事前察知が可能になる。 「禁止」より「仕組みの多重化」 技術的な制限だけで詐欺を止めようとする発想には限界がある。不正が起きた場合の検知・追跡・通報の仕組みを整備し、攻撃者にとって「やり得」にならない環境を作ることが本質的な対策だ。 筆者の見解 生体認証の普及は確かに本人確認の利便性を大きく向上させた。だが今回の報告が突きつけるのは、「認証の強化」と「認証の突破」は常に同時進行するという、セキュリティの根本的な宿命だ。 特に懸念しているのは、eKYCを「導入した＝対策済み」と思っている組織が多いことだ。技術は導入した瞬間から陳腐化が始まる。仮想カメラによるバイパスは今に始まった話ではなく、以前からセキュリティ研究者の間では知られていた手口だ。それが「Telegramで堂々と売られる商品」になったという事実は、攻撃の民主化・低コスト化が相当進んでいることを意味する。 筆者が繰り返し言ってきた「禁止ではなく、安全に使える仕組みを」という原則は、ここでも当てはまる。攻撃側は常に最も弱いリンクを探す。防衛側がすべきは特定の手口を塞ぐことではなく、攻撃が成立しても被害が最小化される多層防御の設計だ。 170億ドルという被害額の重さを日本の組織は自分事として受け止め、eKYC基盤の再点検と監視体制の強化に今すぐ取り組んでほしい。 出典: この記事は Cyberscammers are bypassing banks’ security with illicit tools sold on Telegram の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleが水面下でGrokに「排除」を警告していた イーロン・マスク氏率いるxAIのAIチャットbot「Grok」が、2026年1月にApple App Storeから排除される寸前だったことが明らかになった。NBCニュースが入手したAppleから米上院議員宛の書簡によると、Appleは非合意性的な性的ディープフェイク（deepfake）が大量発生したことを受けて、XとGrokの開発チームに対してコンテンツモデレーション計画の提出を非公開で要求していたという。 この問題が日本のIT関係者にとって単なる「海外の炎上案件」で終わらない理由は、AIプラットフォームとアプリストアという2つのゲートキーパーの責任構造、そしてAI安全対策の「実効性」を問う普遍的な課題を内包しているからだ。 何が起きていたのか 問題の発端とAppleの対応 GrokはXのプラットフォーム上でも単体アプリとしても提供されており、ユーザーが実在する人物の「脱衣」画像を生成できる脆弱なサーフェスが問題となった。被害者の多くは女性であり、明らかに未成年と見られるケースも含まれていたとされる。これはApp Storeガイドラインへの明確な違反だ。 Appleは「X側は実質的に違反を解消した」と判断した一方で、Grokについては「まだコンプライアンスを満たしていない」と評価。追加対応がなければ削除すると警告した。その後のやり取りを経て、AppleはGrokが「実質的に改善された」として最終的にはApp Storeへの残留を認めた。 「改善済み」とされても実態は？ ここが最も重要なポイントだ。xAIは有料サブスクリプション限定化や「脱衣」機能の制限など、複数の対策を順次打ち出したと発表した。しかしThe Vergeや複数のサイバーセキュリティ関係者の検証によると、Grokは現在も比較的容易に性的なディープフェイクを生成できる状態にある。公人の明示的な画像さえ生成できたという報告もある。 なぜこれが重要か——プラットフォームガバナンスの構造問題 「非公開の圧力」という手法の限界 Appleが今回とった行動は「非公開の警告→非公開の交渉→非公開の承認」というクローズドなプロセスだった。問題がメディアで公然と報じられている最中でも、Appleは一切の公式コメントを避けた。Googleも同様にGooglePlayとしてのスタンスを表明していない。 プラットフォームの「門番」として強大な力を持つAppleとGoogleが、有害コンテンツ問題に対して閉ざされた交渉で対応する——この構造では、エコシステム全体への透明性ある説明責任が果たされない。アプリが継続的にストアで配信されている間も、被害は現実に発生し続けていた。 「技術的対策」と「実効性」の乖離 Grokが打ち出した有料化制限やフィルタリングは、Appleの審査を通過するための「計画」としては機能した。しかし実際の悪用を止める実効性には大きな疑問符が残る。これはGrokに限らず、生成AI全般が直面する構造的な課題だ。プロンプトエンジニアリングやAPIアクセスを通じた回避手法は常に存在し、「対策を入れました」と「悪用が止まりました」の間には大きな溝がある。 実務への影響——日本のIT管理者・エンジニアに伝えたいこと 社内AIツール選定での「安全基準」の見直し 生成AIツールを業務導入する際、コンテンツモデレーションの実効性を評価軸に加えることが重要になっている。ベンダーの「対策実施済み」という発表だけでなく、独立した検証結果や継続的な第三者評価があるかどうかを確認したい。 APIやプラグイン連携時のリスク評価 ビジネスアプリとAIを連携させる際、そのAIエンジンがどのようなコンテンツポリシーを持ち、どう実施されているかを利用規約・技術文書のレベルまで確認する習慣が必要だ。特にエンドユーザーが直接プロンプトを入力できるインターフェースを提供する場合、ダウンストリームのリスクは開発者側にも及ぶ。 プラットフォームに依存しすぎないガバナンス設計 App StoreやGooglePlayが「安全を保証する」という前提は成立しない。今回明らかになったように、ゲートキーパーはしばしば非公開交渉を優先し、問題が解決する前にアプリを継続配信し続ける。企業がAIサービスを採用する際のガバナンスは、自社基準として設計・運用する必要がある。 筆者の見解 Appleは今回、強大なプラットフォーム支配力を「ほぼ使わなかった」。技術的には排除できたはずの状況で、非公開交渉を選び、Grokを残留させた。その結果として被害が続いたという事実は重く受け止めるべきだ。 より根本的な問題は「対策の実効性を誰が検証するのか」という点にある。今回、実際に問題を測定したのはメディアやサイバーセキュリティ研究者だった。AppleはGrokが「実質的に改善された」と判断したが、その判断基準と検証プロセスは不透明なままだ。 生成AIの安全対策は「宣言」ではなく「継続的な計測と公開」でしか信頼を得られない。これはツールの種類や提供企業の規模を問わず、すべてのAIプラットフォームに共通する課題だ。 日本でも、業務利用・一般利用を問わず生成AIの普及が加速している。今回の件は「プラットフォームに任せておけば安全」という発想の危うさを改めて教えてくれる。自社でのリスク評価と独自基準の策定——これを後回しにしていい段階は、もうとっくに過ぎている。 出典: この記事は Grok’s sexual deepfakes almost got it banned from Apple’s App Store. Almost. の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobeが2026年4月、クリエイティブツールの使い方を根本から変えかねない新機能「Firefly AI Assistant」を発表した。専門的な編集操作を知らなくても、話しかけるように指示を入力するだけで、Creative Cloudの各アプリを横断した複雑な編集ワークフローを自動実行するエージェント型AIだ。「これはクリエイティブワークの根本的な転換点だ」という同社の主張は、決して大げさではないかもしれない。 Firefly AI Assistantとは何か Firefly AI Assistantは、昨年のAdobe Max conferenceで公開されたProject Moonlightの実験を土台に構築された統合AIインターフェースだ。ユーザーが「この画像をレタッチして」「SNS向けにリサイズして」と自然言語で入力すると、AIが複数の選択肢を生成しながら、Photoshop・Premiere・Lightroom・Illustrator・Expressなどの適切なツールを自律的に呼び出して処理を実行する。 重要なのは、ユーザーが結果を確認して微調整するUIも同時に提供される点だ。特定のスライダーや設定パネルを直接開くのではなく、AIが「このへんを調整しますか？」と提示してくる。より細かい仕上げが必要なら、編集済みファイルをCreative Cloudアプリで開いて続きの作業もできる。 「学習するエージェント」としての設計 注目すべきは、Firefly AI Assistantが使うほどユーザーの好みを学習する点だ。よく使うツール・ワークフロー・審美的な好みを記憶し、結果の一貫性とパーソナライズ度を高めていく。この学習機能はオプト形式で、プロジェクト単位で対象を選べるという。 また「Creative Skills」という仕組みも興味深い。特定の処理を一貫して再現するプリセットをスキルとして登録・共有できる機能で、AIアシスタントが実行する処理の単位を自分でカスタマイズできる。ライブラリから既成スキルを選ぶことも可能だ。 さらにAdobeは、サードパーティのAIアプリからFireflyの機能を呼び出せる統合APIも提供予定とアナウンスしている。外部のAIツールからAdobe製品の編集機能にアクセスできるようになり、既存のAIワークフローにAdobeの強みを組み込みやすくなる。 実務への影響——クリエイターとIT管理者それぞれに クリエイターにとっては、Premiereのタイムライン操作やPhotoshopの複雑なマスク処理といった「覚えるべき手順」が激減する。ただし、AIが生成した結果をどう見極め、どの方向に導くかというディレクション能力は従来以上に重要になる。ツールの操作技術よりも「何を作りたいか」の言語化が問われる時代だ。 IT管理者・情報システム部門にとっては、Adobe Creative CloudライセンスがFirefly AI Assistantを含む形になることで、コストや権限管理の見直しが必要になる可能性がある。特にエンタープライズ向けには、AI学習データに何を含めるかのガバナンスポリシーが求められるようになるだろう。学習機能のオプトイン設計はその観点からも重要で、早めに社内ポリシーを整理しておくことを勧める。 筆者の見解 今回のFirefly AI Assistantが示す方向性は、AIの本質的な価値に正面から向き合った設計だと感じる。「ツールの操作方法を知っている人しか使えない」というプロフェッショナルツールの壁を崩しながら、熟練者には細部の制御を残すという両立は技術的にも難しい挑戦だ。それを複数アプリの横断実行という形で実現しようとしているのは評価できる。 個人的に重要だと思うのは、このアシスタントが「確認を求めて止まる設計」ではなく、「一通り実行してから選択肢を見せる設計」になっている点だ。ユーザーに次の指示を毎回求めるのではなく、自律的にタスクを進めてから人間にレビューを渡す——このループ構造こそが、AIエージェントが実用的に機能するための本質的な設計思想だと私は考えている。 Adobeが「根本的な転換」と呼ぶのは誇張ではない。クリエイティブツールの文脈で、自律エージェントが複数のアプリを横断してワークフローを実行するという概念実証が、いよいよ製品として形になってきた。Creative Cloudを日常的に使っている方は、ぜひFirefly AI Assistantが利用可能になったタイミングで積極的に試してほしい。「AIを使いこなす」練習の場として、これ以上わかりやすい入り口はそうそうない。 出典: この記事は Adobe embraces conversational AI editing, marking a ‘fundamental shift’ in creative work の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIブームに乗った「ゾンビブランド」復活劇 ウールスニーカーで一世を風靡したAllbirds（オールバーズ）が、GPUクラウド企業「NewBird AI」として再出発すると発表し、株価が一夜にして600%超急騰した。2021年のIPO時には評価額40億ドルを誇ったが、その後一度も黒字化できず、2022年〜2025年の間に売上はほぼ半減。最終的にブランドと資産を3,900万ドルで売却し事業を清算したばかりだった。 しかし上場廃止のタイミングでCEOが発表したのは、匿名の投資家から5,000万ドルを調達し、「フル統合型GPU-as-a-Service（GPUaaS）およびAIネイティブクラウドソリューションプロバイダー」を目指すというビジョンだ。 GPU需要は本物、でもAllbirdsは何者か 発表文の内容自体は、AI時代の実態を的確に捉えている部分もある。 高性能GPUの調達リードタイムが延伸し続けている 北米データセンターの空き率が史上最低水準 2026年半ばまでに稼働予定のコンピュート容量はすでに予約済み 企業・AI開発者・研究機関が必要な計算資源を確保できない状況 これらはすべて事実だ。AWSやAzure、GCPといったハイパースケーラーに頼れない中小企業が、CoreWeaveのような「ネオクラウド」に殺到している構図はリアルに存在する。GPU需要というパイ自体は本物だ。 だが問題は、5,000万ドルの資本でどこまで戦えるかという現実だ。兆ドル規模のプレイヤーが並ぶ市場で、Allbirdsが持つアドバンテージは何か。プレスリリースを読む限り、答えは「上場企業の株式という器」以外に見当たらない。 ウォートン校教授の辛辣な分析 ペンシルバニア大学ウォートン校のGad Allon教授のコメントが本質を突いている。 「これを『ピボット』と呼ぶのはAllbirdsに過大評価だ。ピボットとは技術・人材・販路などの資産を新市場に転用することを指す。AllbirdsにはAIに転用できる資産が何もない。あるのは上場ステータスだけで、今の市場ではそれだけで十分に資金調達できてしまう。彼らはAIにピボットしているのではなく、上場という立場を使ってトレンドに乗っているだけだ」 教授はさらに、古いウォール街のジョークになぞらえた。「靴磨き少年が株のアドバイスをし始めたら売り時だ」という格言の現代版——「靴会社がAI企業を名乗り始めたら、バブルが何かを語っている」。 実務への影響——バブル識別リテラシーが問われる時代 日本のIT部門・調達担当者にとって、この件は他人事ではない。今後「AIクラウド」「GPUaaS」「AIネイティブ」を名乗るスタートアップや新興サービスは急増する。どこに本質的な差別化があり、どこが看板の掛け替えだけなのかを見極める目が問われる。 チェックポイントの例： そのGPUリソースは自社所有か、再販か、将来的な調達契約か 技術チームのバックグラウンド（AI/インフラ経験者がいるか） SLAと実際の稼働実績データが開示されているか 既存顧客のユースケースと規模感は具体的か 「AI」という言葉が入っているかどうかではなく、提供できるコンピュートリソースの質・量・信頼性が本質だ。 筆者の見解 GPU不足は本物の構造問題であり、それを解決しようとするビジネス自体は正当だ。CoreWeaveのような先行プレイヤーが実際に市場を切り拓いていることもある。だから「GPU供給ビジネスがインチキ」という話ではない。 問題は、事業に必要な実力と実績を持たない企業が「AI」というキーワードだけで株式市場から資金を引き出せてしまっている構造だ。2021年のSPACブームでRadio ShackがCrypto企業に転身したのと構図は同じ——あのときは仮想通貨だったが、今回はAIだ。 AIに関わる構造的な需要は本物であり長期的に続く。だからこそ、その需要に真剣に向き合っている企業とブームに乗っかっているだけの企業を見分けることが、調達判断においても投資判断においても、これまで以上に重要になる。 AIが「何でも解決するバズワード」として消費されるのは、AIを実際のビジネス変革に使おうとしているすべての人間にとって迷惑な話だ。本物の実力を持つプレイヤーが正当に評価される市場環境を、業界全体で守っていく必要があると感じている。 出典: この記事は Allbirds announced a switch from shoes to AI and its stock jumped 600 percent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがmacOS向けのGeminiデスクトップアプリを正式リリースした。前日にWindowsのSpotlight風アプリを全ユーザーに公開したばかりで、プラットフォーム横断的な展開が一気に加速している。デスクトップAI統合は今やOpenAI・Anthropic・Perplexityなど各社が激しく競い合う主戦場となっており、その動向は日本のIT現場にも無関係ではない。 Gemini Macアプリの機能概要 アプリの最大の特徴は、Option + Spaceのショートカット一発でフローティングチャットバブルを呼び出せる点だ。作業中のウィンドウを切り替えることなくAIに質問でき、画面を共有すれば「今見ているもの」に基づいた回答も得られる（共有前に画面アクセスの許可が必要）。 機能面では以下が利用可能だ。 テキストチャット（全言語・全対応国で無料） 画像・動画・音楽の生成 GoogleドライブからのファイルやドキュメントのアップロードとAI処理 Googleアカウントに紐づいた過去の会話履歴の参照 動作要件はmacOS Sequoia（15.0）以上。AppStoreからの無料ダウンロードとなる。 競合との現時点での差異 記事内でも指摘されているが、競合他社のMacアプリは単純な「チャットへのアクセス」を超えた機能を持っている。ファイル操作・ブラウザ制御・アプリ起動といったコンピューター上のタスクをAIが直接実行する「コンピューターユース」機能がそれにあたる。 GeminiのMacアプリは現時点でこの領域に踏み込んでおらず、あくまでチャットと生成系コンテンツの補助という位置づけだ。画像・動画・音楽生成にはGoogleの強みが光るが、「エージェントとして仕事をさせる」用途にはまだ距離がある。 実務への影響——日本のエンジニア・IT管理者にとっての意味 まず確認すべきこと：組織のGoogle Workspace契約と利用ポリシー。 GeminiアプリはGoogleアカウントに会話が紐づくため、仕事用アカウントで使う場合は社内のデータ管理ポリシーとの整合性を確認しておく必要がある。Googleドライブとの連携は魅力的だが、業務データをAIに渡す際のガバナンスは事前に整理しておきたい。 実務活用の現実的な入り口： Google Workspace（Gmail・Docs・スライド）を主軸に使っている組織にとっては、文書の要約・翻訳・メール下書きをデスクトップから素早く呼び出せる点に一定の価値がある。Option + Spaceのショートカットは体験として分かりやすく、非エンジニアにも導入しやすい。 AI管理者視点での観点： 複数のAIアプリが社員のMacに混在し始める時代が来る。一元管理のポリシー設計（どのAIツールを業務利用承認するか、データ共有のスコープをどう定めるか）を今のうちに整備しておくことが中長期的なガバナンスコストを下げる。 筆者の見解 デスクトップへのAI統合がこれほど短期間で競合ひしめく領域になるとは、一年前には予測しにくかった。各社がこぞってOS上のAIプレゼンスを高めようとしているのは、「どのAIが日常の起点になるか」という主導権争いの側面が強い。 Geminiについて率直に言えば、画像・動画・音楽生成の品質は他社と比較しても存在感がある。ただ実務における「AIにタスクを丸ごと任せる」という体験の充実度という観点では、現時点のMacアプリはまだ追いつけていない印象だ。 とはいえGoogleは底力のある会社だ。検索・クラウド・Workspaceとの統合という観点では、誰にも真似できない強みを持っている。コンピューターユース機能の拡充が進めば、Workspace利用者にとっての選択肢として一気に実用性が跳ね上がる可能性は十分ある。 重要なのは、デスクトップAIツールの選定を「話題かどうか」ではなく「自分・自社のワークフローにどれだけ深く統合できるか」で判断することだ。AIが作業を中断させるツールから、作業に溶け込むインフラになる——その移行が本格化しつつある今、どのツールをどう組み合わせるかは個人・組織ともに真剣に考え直すタイミングに来ている。 出典: この記事は Google launches a Gemini AI app on Mac の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ウクライナのCERT（CERT-UA）が2026年4月、地方政府機関や病院を標的にした新たなマルウェアファミリー「AgingFly」を特定した。このマルウェアの最大の特徴は、コマンドハンドラーをあらかじめ実行ファイルに内蔵せず、C2サーバーからC#ソースコードを受け取って実行時に動的コンパイルするという構造にある。ハッシュ・シグネチャベースの静的検知を大きく困難にする設計であり、遠い国の話として流せない技術的示唆を多く含んでいる。 攻撃チェーンの全貌 攻撃の起点は「人道支援のオファー」を装ったフィッシングメール。リンクをクリックすると、XSS脆弱性を突いて侵害された正規サイト、またはAIツールで生成された偽サイトへ誘導される。 被害者がダウンロードするアーカイブにはLNKショートカットが含まれており、HTA（HTMLアプリケーション）ハンドラーを起動。HTAはリモートリソースからさらなるHTAを取得・実行し、デコイフォームで注意をそらしながら、スケジュールタスクでEXEペイロードを正規プロセスにインジェクションする。その後、XOR暗号化されたTCPセッションでC2サーバーに接続し、AgingFly本体が展開される。 AgingFlyの技術的特徴——動的コンパイルによる検知回避 C#で実装されたAgingFlyは、リモートコントロール・コマンド実行・ファイル窃取・スクリーンショット・キーロガー・任意コード実行といった機能を持ち、WebSocket経由（AES-CBC暗号化）でC2サーバーと通信する。 注目すべきはコマンドハンドラーの動的コンパイルだ。従来のマルウェアは機能を実行可能ファイルに埋め込むが、AgingFlyはC2から受け取ったC#ソースコードをホスト上でその場でコンパイルして実行する。これにより： 初期ペイロードを小さく保てる 機能を必要に応じてオンデマンドで追加・変更できる ハッシュ・シグネチャベースの静的検知をほぼ無効化できる 一方で、この手法はC2への常時接続依存、実行時のフットプリント増加、コンパイル動作による挙動検知リスクという弱点も抱える。つまり、EDR（Endpoint Detection and Response）による行動監視は依然として有効な対抗手段だ。 認証情報窃取に悪用されるオープンソースツール AgingFlyの前段階では、オープンソースのセキュリティツールが認証情報窃取に流用されている： ChromElevator：Chromiumベースブラウザ（Chrome、Edge、Brave）の保存パスワードやCookieを管理者権限なしで復号・抽出できるツール ZAPiDESK：WhatsApp for Windowsのデータベースを復号してメッセージ等を取り出すフォレンジックツール さらに、C2サーバーのアドレスをTelegramチャンネルから取得するPowerShellスクリプト「SILENTLOOP」が使われており、Telegramを指令インフラの中継に使う手法は単純なC2ドメインブロックが効きにくい理由でもある。横展開にはRustScanポートスキャナー、Ligolo-ng・Chiselトンネリングツールが使われ、初期侵入後に素早く内部探索が進む。 実務への影響 日本の組織がこの攻撃パターンから学ぶべき点は3つある。 1. LNK / HTA / JSファイルの実行制限 CERT-UAが推奨する通り、グループポリシーやAppLockerでこれらのファイルタイプの実行を制限することが最も効果的な初期侵入対策の一つだ。メールやWebからのダウンロードに対して、ファイルタイプでの実行制御は今すぐ実施できる低コスト対策だ。 2. ブラウザ認証情報の保存を見直す ChromElevatorに代表される手法は、管理者権限なしでも実行可能という点が重大だ。エンタープライズ環境では認証情報を専用のシークレット管理基盤や条件付きアクセスと連携したパスワードレス認証に移行することを強く推奨する。 3. WhatsApp for Windowsを業務利用している環境への注意 業務コミュニケーションにWhatsAppを用いている組織は、そのローカルデータが標的になりうることを認識する必要がある。特に規制業種では業務チャットの管理ポリシーと保存場所の整備が急務だ。 筆者の見解 AgingFlyが示す最も重要なシグナルは、「静的検知の限界」だ。コマンドハンドラーを動的コンパイルするアプローチは、従来のシグネチャ型アンチウイルスをほぼ無力化する。「セキュリティ製品を入れてあれば大丈夫」という感覚では通用しない時代に確実になっている。 もう一点引っかかるのが、オープンソースツールの流用だ。ChromElevatorもZAPiDESKも本来はセキュリティ研究・フォレンジック目的のツールだが、それが攻撃インフラの一部として使われている。「今動いているから大丈夫」では済まない現実を改めて突きつけられる。 そして見逃せないのが、Telegramをインフラとして使うという点だ。正規のクラウドサービスを踏み台にする手法は、従来のネットワーク境界防御では根本的に検知が難しい。これこそがゼロトラストアーキテクチャが必要な理由の一つであり、「ネットワーク内にいるから信頼する」という前提の危うさを改めて示している。 最終的に防御側が強みにできるのは、行動ベースの異常検知と、認証・認可の厳格化だ。「常時アクセス権の付与」をやめてJust-In-Timeアクセスに移行し、初期侵入を阻止できなかった場合でも横展開を封じる多層防御の構築が、これからのセキュリティ運用の基本線になる。このウクライナでの攻撃事例を、自組織の設計を見直すきっかけにしてほしい。 出典: この記事は New AgingFly malware used in attacks on Ukraine govt, hospitals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Nginx の管理UIとして広く利用されている「Nginx UI」に、認証なしでサーバーを完全乗っ取りできる致命的な脆弱性（CVE-2026-33032）が発見され、すでに実際の攻撃に使われていることが確認された。430,000件以上のDockerプル実績を持つ人気ツールだけに、影響範囲は決して小さくない。 何が起きているか——MCPエンドポイントが丸裸に Nginx UIはバージョン2系からAIワークフロー連携を想定してModel Context Protocol（MCP）をサポートしているが、その実装に根本的な設計ミスが含まれていた。/mcp_message エンドポイントに対してまったく認証が掛かっておらず、ネットワークさえ到達できれば誰でも特権的なMCPアクションを呼び出せる状態になっていた。 具体的な攻撃手順はシンプルで恐ろしい。 対象のNginx UIインスタンスにSSE（Server-Sent Events）接続を確立する MCPセッションを開き、返却される sessionID を取得する その sessionID を使って /mcp_message に任意のリクエストを送る これだけで、認証ヘッダー一切なしに12種類のMCPツール（うち7種は破壊的操作）が使い放題になる。Nginx設定ファイルの読み取り・改ざん・削除、悪意ある server ブロックの注入、設定リロードのトリガーまで、サーバー管理として想定されるあらゆる操作が外部から可能だ。 タイムラインと現在の状況 日付 出来事 2026年3月14日 Pluto Security AIが発見・報告 2026年3月15日 バージョン2.3.4で修正リリース 2026年3月末 CVE番号・技術詳細・PoCが公開 2026年4月第1週 バージョン2.3.6リリース（現在の最新安定版） 2026年4月15日 Recorded Futureが野外での積極的悪用を確認 Shodanによるスキャンでは現在も約2,600インスタンスが公開状態でインターネットに露出している。地域別では中国・米国・インドネシア・ドイツ・香港が多いが、国内のサーバーも無関係ではない。 なぜこれが重要か——AIプロトコルと特権操作の組み合わせ この脆弱性が単なる「Webアプリの認証バイパス」と根本的に異なる点は、MCPという「AI統合用プロトコル」が特権管理操作と直結していたことだ。 MCPはもともとAIエージェントがツールを呼び出すための通信規格として設計されている。便利だからこそ多機能で、だからこそ今回のように「便利なツール群」が認証なしで露出した場合のダメージが甚大になる。AIと連携できるサーバー管理ツールは今後も増えていくが、その認証・認可設計が追いついていないケースが続出する予感がある。 実務への影響——日本のエンジニア・IT管理者が今すぐやること 即時対応 nginx-ui --version でバージョンを確認する 2.3.6未満であれば即座にアップデートする（docker pull uozi/nginx-ui:latest または公式リリースページから） アップデートが即時困難な場合は、/mcp_message エンドポイントをファイアウォール・リバースプロキシのACLで一時的にブロックする 中期的な対策 Nginx UIをインターネットに直接公開しているなら、まずそれを止める。管理系UIはVPN・踏み台・Private Endpoint越しにアクセスする構成が正しい Docker Composeで動かしている場合、ポートバインディングを 127.0.0.1:80 のようにループバックに限定しているか確認する 設定変更のログを定期的にレビューするか、変更検知の仕組みを入れる 将来を見据えた設計 MCPや類似のAI統合プロトコルを導入する際は「エンドポイントごとの認証スコープ」を設計段階で明確にする。後付けは難しい 特権操作を行うAPIは必ずゼロトラスト原則で設計する。「内部ネットワークだから安全」という前提は捨てること 筆者の見解 今回の件で改めて感じるのは、「今動いているから大丈夫」という感覚がいかに危険かということだ。2,600インスタンスが公開されているということは、管理者の多くはそもそも自分のサーバーが外から見えていることすら把握していない可能性がある。 MCPという新しいレイヤーが特権操作に直結した今回の構造は、今後AIエージェント統合が進むにつれて似たようなパターンが各所に出てくる予兆だと思う。AIが「道具を使う」ために設計されたプロトコルは、そのまま「攻撃者が道具を使う」ための経路にもなりうる。設計段階でNon-Human Identity（NHI）として扱い、最小権限・Just-In-Timeアクセス・操作ログの3点をセットで考える習慣を今のうちに身につけておきたい。 ...

生成AIの「夢」フェーズが終わり、「ビジネス」フェーズが本格化している。OpenAIの年換算収益が250億ドル（約3.8兆円）を突破し、2026年後半のIPOに向けた初期検討が始まった。一方Anthropicは年換算収益が300億ドル（約4.6兆円）の「ランレート」に達したと発表。わずか1か月（3月）で58%の急増という驚異的なペースだ。この数字は単なる話題にとどまらず、日本のIT現場にも実質的な影響を与え始めている。 OpenAIの250億ドルとIPO構想 2026年2月にOpenAIが報告した年換算収益は250億ドル超。同社はこれを足がかりに2026年後半のIPOを視野に入れた初期検討を開始した。ただし「IPO検討」はまだ準備の初期段階であり、確定情報ではない点は注意が必要だ。同社はメディア戦略の一環として、テクノロジー専門のポッドキャスト配信メディア「TBPN」を数億ドル規模で買収したことも明らかになった。企業としてのブランド構築にリソースを投下している。 Anthropicの「エージェント向けサブスク廃止」が意味するもの より実務的なインパクトが大きいのは、Anthropicが打ち出したポリシー転換だ。月額サブスクリプションを使って「OpenClaw」などのサードパーティ製エージェントハーネスを動かすことを原則禁止とし、今後はAPI経由のトークン従量課金に移行させることを発表した。 この背景にあるのは深刻なコンピュート不足だ。AIエージェントが普及するにつれて、月定額の「使い放題」契約が計算資源の逼迫を招いていた。Anthropicは同時にGoogleとBroadcomとの拡大パートナーシップを通じて、2027年稼働予定のTPUデータセンターへのアクセスを確保すると発表しており、中期的な供給力の拡充を目指している。 このポリシー変更は、エージェントAIの普及に対してブレーキとなる可能性がある。一方で、コスト意識を持った企業がオープンソースモデルをエージェントのバックエンドとして採用する動きを加速させるきっかけになるかもしれない。 Project Glasswing：AIが引き起こすサイバー脅威への先手 Anthropicはもう一つ、見逃せない取り組みを発表した。主要テクノロジー企業やサイバーセキュリティ企業と組む連合体「Project Glasswing」だ。 目的は明確だ——AIの高度なコーディング能力が悪用される前に、世界の重要インフラのソフトウェア脆弱性を発見・修正しておくこと。連合参加企業には、未公開のサイバーセキュリティ特化AIモデル「Mythos」のプレビュー版がすでに提供されており、ゼロデイ脆弱性の発見・パッチ適用を先行して進めている。 これは杞憂ではない。最新のAIモデルは既存のペネトレーションテストツールを大幅に超えるコード解析能力を持ち始めており、悪意ある攻撃者がこれを使えば被害の規模と速度が桁違いになる。「AIが攻撃に使われる前に防衛側が先手を打つ」——この発想は非常に現実的だ。 実務への影響 日本のIT管理者・エンジニアが今考えるべきこと： エージェントのコスト設計を見直す: サードパーティエージェントハーネスを月額サブスクで運用していたチームは、API従量課金へのシフトによるコスト増を見込んで予算を再計算する必要がある。大規模に使うほど試算と実費のギャップが開きやすい オープンソースモデルの検討を始める: 商用APIの従量課金が重荷になる規模の場合、オープンソースモデルをオンプレまたはクラウドGPUで自前運用するコスパが相対的に上がる。今のうちに検討しておく価値がある AIを使ったサイバー攻撃への備えを: Project Glasswingが示すように、AI活用型の攻撃は現実の脅威になりつつある。ゼロデイ対応の体制と、脆弱性スキャンのAI活用をセキュリティロードマップに組み込む時期だ 財務規模の変化をベンダー選定の参考に: 生成AIベンダーの資金力・コンピュート調達力は、SLAやサービス継続性に直結する。収益規模の推移はベンダーリスク評価の指標の一つになる 筆者の見解 今回の一連の発表が示しているのは、「AIの使い方」が静かに、しかし大きく変わりつつあるという事実だ。 注目したいのはAnthropicのサブスク廃止措置だ。表面上は「コンピュート不足への対応」だが、その本質はエージェントを自律的に動かし続けるハーネスループが、もはや一部の先進ユーザーのものではなく、マス化しつつあることを示している。需要が供給を食い破るくらいに普及しているということだ。 これはエポックメイキングなシグナルだと思う。単発の「AIに質問する」使い方から、「エージェントが自律的に判断・実行・検証を繰り返すループを設計する」使い方への移行が、数字として現れ始めた瞬間だ。 Project Glasswingについては、率直に言って「ようやく」という感想だ。高度なAIの悪用リスクは以前から自明だった。産業連合として体系的に動き出したことは評価できる。ただし、日本の企業・官公庁がこのような国際的なセキュリティコンソーシアムの動向を把握し、自組織の対策に反映できているかというと、まだ心もとない。「AI導入は進めている、でもAIを使った攻撃への対備はまだ」という組織が大多数ではないか。 OpenAIのIPO検討については、足元の収益規模からすれば自然な流れだ。ただし上場企業になることで四半期ごとの数字を意識した判断が増えることへの懸念は拭えない。研究主導の文化と株主還元の要求は、時に鋭く対立する。この点は今後も注目し続けたい。 収益規模が兆単位になろうと、エンジニアにとって本質は変わらない。今自分が使っているツールを深く使い倒し、その経験から設計力・判断力を磨くことが、この変化の中で価値を持ち続ける唯一の道だ。 出典: この記事は OpenAI Surpasses $25B Annualized Revenue, Eyes Late 2026 IPO の内容をもとに、筆者の見解を加えて独自に執筆したものです。