Tech News JP

Microsoft 365 Copilot、3月の大型アップデートで企業活用をさらに加速 Microsoftは2026年3月、Microsoft 365 Copilotに複数の新機能を追加した。今回のアップデートは「Copilotが正確な情報を返すか不安」「社内でどれだけ活用されているかわからない」といった、企業のIT管理者や現場が抱える課題に直接応えるものとなっている。 SharePoint管理センターに「権威あるソース」指定機能が登場（4月ロールアウト開始） 最大の目玉は、SharePointの管理センターからCopilot検索の優先情報源（権威あるソース）を指定できる新機能だ。4月より順次展開される。 Copilotは社内のさまざまなドキュメントやサイトを横断して回答を生成するが、情報源の信頼性にはばらつきがある。この機能を使うと、管理者が「このSharePointサイトの情報を優先して参照せよ」と明示的に設定できるため、公式ポリシー文書や最新の製品仕様書など、確度の高い情報をCopilotが優先的に参照するようになる。 日本企業においても、部門ごとにばらばらな情報が散在していることが多い。権威あるソースを明示できるこの機能は、Copilotの回答精度向上と情報ガバナンス強化を同時に実現するものとして注目される。 Teamsにコミュニティエージェントが追加 Microsoft Teamsでは、コミュニティ向けのCopilotエージェントが新たに利用可能になった。Teamsのコミュニティ機能（社外を含む大規模グループ向け）にもAIエージェントを配置できるようになり、Q&Aへの自動応答や情報共有の効率化が期待できる。 コミュニティ運営者がエージェントをカスタマイズし、よくある質問への自動回答や特定ドキュメントへの案内を設定するといった活用が見込まれる。 管理者向け「Readinessページ」で利活用状況を可視化 Copilotの導入後に「実際にどれだけ使われているのか」を把握できていない管理者は多い。今回展開されるReadinessページでは、組織内のCopilot利用状況をダッシュボード形式で確認できる。ライセンス割り当て状況、アクティブユーザー数、機能別の利用傾向などが一目でわかるようになり、ROI（投資対効果）の評価や追加トレーニング計画の立案に活用できる。 日本企業への影響 日本のMicrosoft 365ユーザー企業では、Copilotの段階的導入が進んでいる。特にSharePointの権威あるソース指定は、コンプライアンス要件の厳しい金融・製造・医療業界での活用促進につながる可能性が高い。また、Readinessページによる利活用の可視化は、DX推進担当者が経営層へ効果を報告する際の強力な根拠となるだろう。 各機能のロールアウトスケジュールはテナントによって異なるため、Microsoft 365管理センターのメッセージセンターで最新情報を確認することを推奨する。 元記事: What’s New in Microsoft 365 Copilot | March 2026

Microsoftは2026年3月16日、Copilot Chatの提供形態を変更すると発表した。変更は2026年4月15日から順次適用される。 何が変わるのか 最大の変更点は、Word・Excel・PowerPoint・OneNoteにおけるCopilot Chatの利用が、有料の「Microsoft 365 Copilot」ライセンス保有者に限定されることだ。 これまでライセンスなしでも一部利用できていたCopilot Chatは、4月15日以降はOfficeアプリ内から消える。ただし以下の機能は引き続き無償で利用可能だ。 Microsoft 365 Copilotアプリ上でのセキュアなAIチャットおよびチャット起点のコンテンツ作成 OutlookでのCopilot（受信トレイ・カレンダーとの連携を含む） ラベル表記も刷新 ユーザーやIT管理者が自分の利用状況を把握しやすいよう、製品内のラベルも変更される。 ユーザー種別 新ラベル M365 Copilotライセンスなし Copilot Chat (Basic) M365 Copilotライセンスあり M365 Copilot (Premium) すでにライセンスを持つユーザーへの影響はなし Microsoftは「有償ライセンスユーザーには変更はない」と明言しており、Premium利用者は引き続きWord・Excelなど主要Officeアプリでフルのコパイロット機能を使い続けられる。 企業IT担当者への影響 日本国内でもM365を広く導入している企業では、ライセンス体系の見直しが求められる場面が出てくる可能性がある。特に「ライセンスなしでもOffice内でCopilotが使えていた」という認識のまま運用していた組織は、4月15日以降に現場から問い合わせが増えることが予想される。 事前にIT部門から「4月15日以降はOfficeアプリ内のCopilotは有償プラン限定になる」と周知しておくことが望ましい。 今後もMicrosoftはCopilot系機能の提供範囲・ライセンス区分を継続的に見直す方針とみられ、動向を注視する必要がある。 元記事: Copilot Chat Changes - April 2026

1ファイル置くだけでClaudeが「無駄話」をやめる GitHubで公開された「claude-token-efficient」が、Hacker Newsで293ポイントを獲得し話題となっている。このプロジェクトが提供するのは、たった1つのCLAUDE.mdファイル。プロジェクトのルートディレクトリに置くだけで、Claudeが生成する出力の冗長さを平均63%削減できるという。 コードの変更は一切不要。Claude Codeは起動時にCLAUDE.mdを自動で読み込むため、ファイルを配置した瞬間から挙動が変わる。 Claudeのデフォルト出力はなぜ冗長なのか Claudeを使ったことがある開発者なら、こんな出力に心当たりがあるはずだ。 「Sure!」「Great question!」「Absolutely!」で始まるレスポンス 「I hope this helps! Let me know if you need anything!」で締めくくる定型句 質問を答える前に丁寧に言い換えて繰り返す 頼んでもいない追加提案や「改善案」を付け足す 指示していない抽象化レイヤーを盛り込んだコードを生成する 誤った前提に対して「You’re absolutely right!」と同調してしまう こうした振る舞いはすべてトークンを消費する。しかし、ほとんどの場面で実質的な情報価値はゼロだ。 ベンチマーク結果：同じ情報量、63%少ないトークン 5つのプロンプトを使って、CLAUDE.mdあり・なしの出力を比較した結果は以下の通り。 テスト内容 適用前 適用後 削減率 async/awaitの説明 180語 65語 64% コードレビュー 120語 30語 75% REST APIとは 110語 55語 50% 誤情報の訂正 55語 20語 64% 合計 465語 170語 63% 4プロンプトあたり約384出力トークンの節約。情報の欠落はなし、とプロジェクトは主張している。 コスト換算では、1日1,000プロンプトで月額約$8.64（Claude Sonnet基準）、複数プロジェクト合算では月$25超の節約になる計算だ。 正直なトレードオフ：すべての用途に向くわけではない プロジェクトはその効果を素直に認める一方で、適用すべきでないケースについても率直に説明している点が好感を呼んでいる。 効果が高いケース： 大量の出力を扱う自動化パイプライン（エージェントループ、コード生成） 数百回の繰り返し構造タスク チームで一貫したパース可能な出力が必要な場合 効果が薄いケース： 単発・短いクエリ（ファイル自体が入力トークンを消費するため、むしろマイナス） 設計議論やブレインストーミングなど、冗長な応答が価値を持つ用途 幻覚（ハルシネーション）や構造的な誤りの修正（それにはフックやゲートが必要） 確実なJSON出力が必要なケース（APIのJSON modeやツールスキーマのほうが堅牢） 重要な注意点として、CLAUDE.mdは毎メッセージごとに入力トークンとして読み込まれる。そのため、出力量が十分に多い場合にのみ節約効果がプラスになる。低頻度利用では逆にコストが増える可能性があることを、作者は明記している。 ...

ウィキペディア、AI生成コンテンツを正式禁止 インターネット最大の百科事典「ウィキペディア（Wikipedia）」が、ChatGPTなどの大規模言語モデル（LLM）を用いた記事執筆を公式に禁止した。Wikimedia財団のボランティア編集者たちによる投票で40対2という圧倒的多数で承認されたこの新ポリシーは、ウェブ上に「AIスロップ（粗悪なAI生成コンテンツ）」が氾濫する現状への明確な対抗措置だ。 なぜ禁止に至ったのか 新ポリシーが禁止の理由として挙げるのは、AIが生成するテキストが持つ構造的な問題だ。ウィキペディアが長年守り続けてきた検証可能性・中立性という核心的な基準を、AIは満たせないとしている。 具体的にはAIの「ハルシネーション（幻覚）」——存在しない事実の捏造、リンク切れ、実在しない文献の引用——が問題視されている。フランスのボランティア編集者で「WikiProject AI Cleanup」の創設メンバーであるIlyas Lebleuは、「ウィキペディア通常の文体と異なるスタイルで書かれた記事が増えていることに気づき始めた」とNPRのインタビューで述べている。 許可される限定的なAI利用 全面禁止というわけではない。以下の用途に限り、人間の編集者によるレビューを条件としてAIの使用が認められる。 他言語記事の翻訳補助 軽微な文章校正の提案 重要なのは「新しい情報の追加」を伴わないこと。あくまでも補助ツールとしての活用に留まる。 ウィキペディア共同創設者も警鐘 昨年10月、ウィキペディア共同創設者のジミー・ウェールズ（Jimmy Wales）もBBCの取材に対し、現在のAIモデルを「信頼できない」と一刀両断し、「人間編集者の代替としての利用準備はまだ整っていない」と警告していた。 皮肉な構図——育てた子に追い抜かれる この禁止措置には深い皮肉が込められている。ウィキペディアは創設から25年間、インターネット上で最も信頼されてきた情報源の一つだった。そして同時に、ChatGPTを支えるLLMを学習させるデータ源としても大きく貢献してきた。 しかし2025年後半のデータによると、ChatGPTの月間訪問数はウィキペディアをすでに上回り、ウィキペディアの人間によるページビューは2024年比で8%減少している。2023年末から2024年初頭にかけてChatGPTユーザーは36%増加しており、「歴史上ほぼあらゆるプラットフォームより速くインターネットに浸透している」（GWI上席データジャーナリスト Chris Beer氏）という状況だ。 ドミノ効果への期待と不安 Lebleuは「AIバブルへの不安が高まるにつれ、他のプラットフォームのコミュニティが自分たちの条件でAIを受け入れるかどうかを決定する、ドミノ効果を予見している」と述べ、今回の決定がウェブ全体の議論の起点になる可能性を示唆した。 日本のウィキペディアコミュニティも同様の課題に直面しており、今後の動向が注目される。AIと人間が情報の信頼性をめぐって綱引きを続ける中、25年の歴史を持つ百科事典の決断は、オープンな知識共有の未来を問い直す重要な一石となった。 元記事: Wikipedia officially bans AI-generated content

Claude Codeが10分ごとにgit reset –hardを実行？　調査の結果は「自作ツールの誤動作」 GitHubのClaude Code公式リポジトリに、衝撃的なバグレポートが投稿された。「Claude Codeが10分おきに git reset --hard origin/main を実行し、未コミットの変更をすべて消し去っている」というものだ。Hacker Newsでも250ポイント超・195コメントを集め、大きな注目を浴びた。 当初の「証拠」は非常に説得力があった 報告者のjohnmathews氏は、macOS上でClaude Code 2.1.87（--dangerously-skip-permissions モード）を使用中に異変に気づいた。Gitのreflogを確認すると、ちょうど600秒（10分）間隔で reset: moving to origin/main が95件以上記録されていた。 元記事: Claude Code runs Git reset –hard origin/main against project repo every 10 mins

AIはコードを書く。でも「学び」も奪っている AIツールがエンジニアリングの現場に急速に浸透するなか、見落とされがちな問題が静かに広がっている。AIが得意とするタスクの多くが、かつてジュニアエンジニアが「判断力」や「直感」を身につけるために経験してきた仕事そのものだという事実だ。 QCon London 2026でAlasdair Allanが行った講演の内容が、業界関係者の間で大きな反響を呼んでいる。 アモデイ予言の検証 Anthropicの共同創業者でRLHF（人間のフィードバックによる強化学習）の共同発明者でもあるDario Amodeiは、昨年「3〜6ヶ月以内にAIがすべてのコードの90%を書くようになる」と予言した。6ヶ月後、彼は「少なくともAnthropic社内では正しい」と主張した。 しかし実態はどうか。Redwood Researchの詳細な分析によれば、リポジトリにコミットされたコードだけでカウントすると、AI生成コードは約50%にとどまる。90%という数字は、一時的に使われただけの使い捨てスクリプトや探索的なコードを含めた場合にのみ成立する。 実際の企業データでも、Googleは内部コードの約25%、Microsoftは約30%、GitHub Copilotのエンタープライズ向け提案受け入れ率も約30%と報告している。「ほぼすべて」には程遠い数字だ。 生産性の「錯覚」 一方でAIの活用が現場に浸透していることは事実だ。Anthropic社内ではエンジニアの59%が日常業務でClaudeを使用し、50%の生産性向上を実感していると報告。GitHubのパブリックコミットの約4%はすでにClaude Codeが書いたものだという。 ところが昨年7月、業界に衝撃を与えた研究結果がある。METRが実施した無作為対照試験では、AIツールを使用した経験豊富な開発者はタスク完了に19%長い時間がかかったという結果が出た。開発者自身は「24%速くなる」と予測し、終了後も「20%速くなった」と感じていたにもかかわらずだ。知覚と実測値のギャップは43ポイントにもなる。 さらに今年2月、METRがフォローアップ研究を試みたところ、開発者がAIなしでの作業を拒否するケースが増加し、実験自体が困難になったという。 本当の問題：梯子に踏み台がない Allanが最も強調するのは、コードの生成量ではなく「構造的問題」だ。 Amodei自身も「プログラマーは全体的な設計、コードの協調関係、セキュリティの妥当性を判断する必要がある」と述べ、コードを「書くこと」と「エンジニアリング」を切り分けている。しかし問題は、つい最近までコードを書くことこそがエンジニアリングを学ぶ手段だったという点だ。 バグを自分で直し、地味な実装タスクをこなし、コードレビューで叩かれる——そうした経験の積み重ねが、上級エンジニアに必要な「判断力」を育ててきた。AIがその部分を引き受けると、次世代エンジニアはどこでその能力を身につけるのか。 「梯子の踏み台が消えている」というAllanのメタファーは示唆に富む。問題はAIがコードを書くかどうかではなく、梯子を作った人々を生み出したプロセスそのものが失われつつあることだ。日本のIT業界でも若手育成の在り方を根本から見直す議論が急務と言えるだろう。 元記事: The ladder is missing rungs – Engineering Progression When AI Ate the Middle

コーディングフォント選びに悩むエンジニア必見のWebツール プログラマーなら一度は悩む「どのコーディングフォントを使うべきか」問題。Fira Code、JetBrains Mono、Cascadia Code、Hack……選択肢は数十種類にのぼり、それぞれ微妙なデザインの違いがある。そんな悩みをゲーム感覚で解決してくれるWebツール「CodingFont」が、Hacker Newsで410ポイントを獲得し、200件以上のコメントが寄せられる大きな反響を呼んでいる。 トーナメント形式で「自分好み」を見つける CodingFontの仕組みはシンプルだ。画面に2つのコードサンプルが並んで表示され、ユーザーは「どちらが読みやすいか」をクリックで選ぶだけ。この選択をトーナメント形式で繰り返すことで、最終的に自分にとって最も見やすいフォントが絞り込まれる仕組みだ。 比較に使われるコードサンプルは実際のプログラミング場面を想定したもので、数字の「0」と文字の「O」の区別、「l」（小文字のL）と「1」（数字）の視認性、リガチャ（!= や => などの合字表現）の有無といった、コーディングフォント選びで重要なポイントが自然に確認できるよう設計されている。 なぜ今、コーディングフォントが注目されるのか 開発者がエディタの前で過ごす時間は膨大だ。1日8時間コードを書くエンジニアにとって、フォントの読みやすさは目の疲労や生産性に直結する。近年、JetBrains Monoのリリースやプログラミング向けフォントのオープンソース化が進んだことで選択肢が一気に増え、「どれが自分に合うのか分からない」という声も多い。 日本のエンジニアコミュニティでも、英数字の視認性だけでなく、コメントやドキュメント用途での日本語フォントとの組み合わせ（いわゆる「英語プログラミング用フォント＋日本語フォント」の合成）が話題になることが多く、まずベースとなる欧文フォントを選ぶ際にCodingFontは有効な出発点になり得る。 Hacker Newsコミュニティの反応 Hacker Newsのコメント欄では「こんなツールをずっと待っていた」「JetBrains Monoに落ち着くと思っていたら意外なフォントが勝った」といった声が相次いだ。一方で「同じコードサンプルが使われているため、フォントの特性よりも慣れ親しんだスタイルに引っ張られる可能性がある」という鋭い指摘も見られた。 またリガチャ（合字）の好みについて意見が割れており、「!= が ≠ のように表示されると直感的」という派と「実際の文字と異なって見えるのは混乱のもと」という派が活発に議論しており、フォント選びの奥深さが改めて浮き彫りになった。 使ってみよう CodingFontはブラウザから即座に利用でき、インストール不要。所要時間は5〜10分程度。エディタの設定を見直すきっかけとしても最適だ。普段使いのフォントに疑問を感じているエンジニアは、一度試してみる価値がある。 元記事: CodingFont: A game to help you pick a coding font

CISA、Citrix NetScaler脆弱性の緊急パッチを連邦機関に命令 米国のサイバーセキュリティ・インフラセキュリティ庁（CISA: Cybersecurity and Infrastructure Security Agency）は、積極的に悪用されているCitrix NetScalerアプライアンスの脆弱性（CVE-2026-3055）に対し、連邦政府機関に対して2026年4月2日（木）までにパッチを適用するよう命令した。 「CitrixBleed」に酷似した新たな脆弱性 Citrixは3月23日にセキュリティアップデートをリリースしたが、複数のサイバーセキュリティ企業がCVE-2026-3055について、過去に広く悪用された「CitrixBleed」および「CitrixBleed2」との技術的類似性を指摘しており、悪用リスクが高いと警告している。 この脆弱性の根本原因は不十分な入力検証にある。認証なしのリモート攻撃者が、SAML IDプロバイダー（IDP）として構成されたCitrix ADCまたはCitrix Gatewayアプライアンスから機密情報を窃取できる。 Citrixがパッチをリリースしてからわずか数日後、セキュリティ企業のWatchtowrはすでに野外での悪用を確認。攻撃者がこの脆弱性を利用して管理者の認証セッションIDを窃取し、未パッチのNetScalerアプライアンスを完全に乗っ取れる可能性があると警告した。 約3万台のNetScalerがインターネット上に露出 Shadowserverの調査によると、現在インターネット上に公開されているNetScaler ADCアプライアンスは約3万台、NetScaler Gatewayは2,300台以上に上る。ただし、脆弱な構成を持つものや未パッチのものがどれだけあるかは不明だ。 KEVカタログへの追加とBOD 22-01に基づく緊急命令 CISAは月曜日にCVE-2026-3055を既知悪用脆弱性（KEV: Known Exploited Vulnerabilities）カタログに追加し、拘束的運用指令（BOD: Binding Operational Directive）22-01に基づき、連邦文民行政府（FCEB）機関に対して4月2日までの対応を義務付けた。 CISAは「この種の脆弱性は悪意あるサイバー攻撃者にとって頻繁な攻撃ベクターであり、連邦政府全体に重大なリスクをもたらす」と警告し、ベンダーの指示に従ったパッチ適用、またはパッチが利用できない場合は製品の使用停止を勧告している。 BOD 22-01は米国連邦機関のみに適用されるが、CISAは民間企業を含むすべての組織に対しても、CVE-2026-3055のパッチ適用を優先するよう強く促している。 Citrix脆弱性の深刻な悪用履歴 Citrixに関連する脆弱性の悪用は今に始まったことではない。2023年10月にパッチが適用された「CitrixBleed」は、ゼロデイとして複数のハッキンググループに悪用され、Boeing（ボーイング）などの大手テック企業や政府機関への侵害につながった。2025年8月にはCitrixBleed2の悪用が確認され、連邦機関はわずか1日でシステムの保護を求められた。 これまでにCISAがCitrix製品の脆弱性を野外での悪用として認定したのは合計23件にのぼり、そのうち6件はランサムウェア攻撃に使用されている。 Citrix NetScalerを利用している日本企業・組織においても、早急なパッチ適用が推奨される。SAMLのIDP構成を持つアプライアンスは特に優先的に確認すべき対象となる。 元記事: CISA orders feds to patch actively exploited Citrix flaw by Thursday

Microsoft の Azure Developer CLI（azd）が2026年3月に7つのリリース（v1.23.7〜v1.23.13）を連続投入し、AIエージェント開発からインフラ管理まで幅広い強化が施された。 AIエージェントをターミナルからエンドツーエンドで操作 最大の目玉は azure.ai.agents 拡張によるAIエージェント対応コマンド群だ。 azd ai agent run — エージェントをローカルで起動 azd ai agent invoke — ローカルまたは Microsoft Foundry にデプロイ済みのエージェントにメッセージを送信 azd ai agent show — コンテナのステータスと健全性を表示 azd ai agent monitor — コンテナログをリアルタイムストリーミング これにより、AIエージェントの開発・テスト・本番デプロイまでの全工程をターミナル一つで完結できる。Microsoft Foundry との統合が前提となっており、Azure AI 基盤に乗る開発者には特に恩恵が大きい。 GitHub Copilot が azd init に統合（プレビュー） azd init 実行時に「GitHub Copilot でセットアップ（プレビュー）」オプションが追加された。Copilot エージェントがプロジェクトのスキャフォールディングを担い、Model Context Protocol（MCP）サーバーへの同意確認も事前に行う設計となっている。 さらに、コマンド失敗時にはAIによる多段階トラブルシューティングフローが起動。「説明」「ガイダンス」「自動修正」「スキップ」の4段階から選択でき、修正適用後にそのまま失敗コマンドを再実行できる。ターミナルを離れずに問題解決できる点は実務での生産性向上に直結する。 Container App Jobs の直接デプロイ対応 これまで Container Apps のみだったデプロイ対象に、Azure Container App Jobs（Microsoft.App/jobs）が加わった。azure.yaml の host: containerapp 設定はそのままで、Bicep テンプレートの内容に応じて自動判別される。追加設定不要で既存ワークフローへの組み込みが容易だ。 ...

最新AIモデルがサイバー攻撃に悪用される懸念が急浮上 Anthropicが開発する次世代AIモデル「Claude Mythos」やOpenAIの最新モデルが、高度なサイバー攻撃の自動化・拡張に悪用できるとして、セキュリティ業界やAI安全性コミュニティで警戒感が高まっている。 AIが攻撃者に「非対称な優位性」をもたらす これまでのサイバーセキュリティの世界では、攻撃側と防御側がほぼ対等な技術競争を繰り広げてきた。しかし最新世代のAIモデルは、その均衡を崩す可能性があると専門家たちは指摘する。 懸念されているのは、高度な推論能力と自律的なタスク実行力を持つ「AIエージェント」の登場だ。従来の攻撃ツールは人間のハッカーが細かく操作する必要があったが、最新のAIモデルはターゲットの脆弱性調査からエクスプロイト（脆弱性を突くコード）の生成、実行計画の立案までを自律的にこなせる段階に近づいている。 こうした能力は、これまで高度な技術スキルを持つ攻撃者にしか不可能だった攻撃を、スキルの低い「スクリプトキディ」レベルの攻撃者でも実行可能にしてしまうリスクをはらんでいる。 防御側が追いつけない構造的問題 セキュリティ研究者たちが特に危惧するのは、攻撃者と防御者の間に存在する「非対称性」だ。攻撃者は一度の攻撃が成功すれば目的を達成できるが、防御側はすべての攻撃を防ぎ続けなければならない。AIがこの非対称性をさらに拡大するという構図だ。 AIを使えば攻撃者は24時間365日、大量のターゲットに対して自動的にスキャンや侵入試行を繰り返せる。一方、防御側も同様にAIを活用した検知・対応システムを整備しつつあるが、攻撃側の進化スピードに追いつくのは容易ではない。 AI安全性コミュニティで新たな論争 AnthropicやOpenAIといったAI企業は、モデルに対してサイバー攻撃への直接的な協力を拒否するよう「ガードレール」を設けている。しかし研究者たちは、こうした安全策が巧妙なプロンプトエンジニアリングや多段階の迂回手法によって回避される可能性を繰り返し示してきた。 今回の懸念はAI安全性コミュニティ内でも新たな議論を呼んでいる。「能力の公開」と「悪用リスクの抑制」のバランスをどう取るかという問いは、モデルの強化とともにより切実さを増している。 日本への影響 日本でもサイバー攻撃の件数は年々増加しており、特に重要インフラや製造業を狙ったランサムウェア攻撃が深刻化している。AIを活用した攻撃の高度化・低コスト化は、国内企業にとっても対岸の火事ではない。経済産業省やIPAが推進するサイバーセキュリティ対策の強化と並行して、AIを活用した防御側の能力向上も急務となっている。 最新AIモデルの能力向上は技術の進歩を象徴する一方で、その「両刃の剣」としての側面に、業界全体が真剣に向き合う時期に来ている。 元記事: Everyone’s worried that AI’s newest models are a hacker’s dream weapon

中国製AIがオープンソース市場を席巻——Qwen 3.5の全貌 半年前、開発者にオープンソースLLMを尋ねれば「Llama一択、軽量ならMistral」という答えが返ってきた。中国製モデルは欧米の開発者コミュニティにほとんど存在感がなかった。その常識が2026年に入って大きく変わった。 AlibabaのQwen（通義千問）チームが2026年3月初旬までに全パラメータサイズのリリースを完了した「Qwen 3.5」ファミリーは、コーディング・数学・指示追従・長文推論といった実務直結のベンチマークで欧米のオープンソースモデルを上回る結果を出している。 3段階でリリースされた全ラインナップ Qwen 3.5は2月〜3月にかけて3波に分けてリリースされた。 第1波（2月16日）——フラッグシップ Qwen3.5-397B-A17B：総パラメータ数397B、推論時に実際に活性化するのは17BのみというハイブリッドなMoE（Mixture-of-Experts）アーキテクチャを採用。Llama 4 MaverickやGPT-4oと正面から競合するモデル。 第2波（2月24日）——ミドルレンジ Qwen3.5-122B-A10B（MoE） Qwen3.5-35B-A3B（MoE） Qwen3.5-27B（Dense） 第3波（3月2日）——エッジ向け小型モデル Qwen3.5-9B / 4B / 2B / 0.8B：モバイルや組み込み環境向けに設計されており、MacBook上で5.5トークン/秒以上の速度で動作することが確認されている。 すべてのモデルがApache 2.0ライセンスで公開されており、商用利用も制限なく可能。 Qwen 3からの主な進化点 Qwen 3.5は単なるマイナーアップデートではない。注目すべき改善点は以下の通りだ。 MoEアーキテクチャの拡大：35Bと122Bモデルもシリーズ化し、推論コストを大幅削減しながら品質を維持 思考モードの切り替え：すべてのモデルで「thinking（拡張推論あり）」と「non-thinking（高速応答）」をタスクに応じて切り替え可能 エージェント機能の強化：関数呼び出し（Function Calling）、ツール利用、マルチステップ処理が大幅に改善 多言語対応：100以上の言語をサポートし、日本語を含むCJK（中国語・日本語・韓国語）での精度が特に高い。日本語ユーザーにとっては欧米モデルより実用的な場面も多いだろう 長文コンテキスト対応：大規模リポジトリ全体を横断したコード推論や文書解析に対応 中国製オープンソースAIが急加速している背景 Qwen 3.5は単独の出来事ではない。2025年後半から中国のAI開発は急加速しており、DeepSeek V3.2は推論タスクでGPT-5に匹敵するという評価も出ている。さらにHuaweiは米国製半導体に依存しない独自シリコンの開発を進めており、米国の輸出規制が想定ほどの足かせになっていないことが示されつつある。 Hugging Faceのダウンロードランキングでも、Qwenシリーズは2025年中頃から継続的に上位に入っており、開発者コミュニティへの浸透は着実に進んでいる。 オープンソースAIの競争は、MetaとMistralの2強から、QwenとDeepSeekを加えた4強へと移行した。日本の開発者にとっても、選択肢として中国製モデルを無視できない時代が到来している。 元記事: Qwen 3.5 vs Llama vs Mistral: China’s Open-Source AI Is Catching Up Faster Than You Think

OpenAI、GPT-5.4を正式リリース——プロフェッショナル向け最高性能モデルが登場 OpenAIは、新たな基盤モデル「GPT-5.4」を正式にリリースした。同社は「プロフェッショナルワークに向けた、最も高性能かつ効率的なフロンティアモデル」と位置づけている。 標準版に加え、推論特化版の「GPT-5.4 Thinking」と高性能最適化版の「GPT-5.4 Pro」の3バリアントが同時提供される。 100万トークンのコンテキストウィンドウ API版では最大100万トークンのコンテキストウィンドウに対応しており、これはOpenAIのモデルとして過去最大規模となる。長大なドキュメントの処理やコードベース全体を一括で扱う用途に大きな強みを持つ。さらにトークン効率も改善しており、前モデルと比較して同じ問題をより少ないトークン数で解決できるという。 ベンチマーク各種で記録を更新 コンピューター操作の評価指標「OSWorld-Verified」および「WebArena Verified」で過去最高スコアを達成。知識業務タスクを評価する「GDPval」では83%を記録した。 また、弁護士・ファイナンスの専門スキルを測る「Mercor APEX-Agentsベンチマーク」でもトップに立った。Mercor CEOのBrendan Foody氏は「スライドデッキ、財務モデル、法律文書といった長期成果物の作成に優れ、競合のフロンティアモデルより高速かつ低コストでトップパフォーマンスを発揮する」とコメントしている。 幻覚（ハルシネーション）を大幅削減 GPT-5.4では、AIが事実と異なる情報を生成する「ハルシネーション（幻覚）」の抑制にも注力。GPT-5.2と比較して個別の主張における誤りが33%減少し、回答全体のエラー率も18%低下したとしている。日本でもAIの業務利用が広がる中、信頼性向上は実用化の重要な鍵となる。 Tool Search：トークン消費を抑える新設計 API版では「Tool Search」と呼ばれる新しいツール呼び出し管理システムが導入された。従来はシステムプロンプトにすべてのツール定義を列挙する必要があり、ツール数が増えるほどトークン消費が膨らむ問題があった。新システムでは必要に応じてツール定義を動的に参照する仕組みとなり、大規模なツール群を持つシステムでのリクエストを高速化・低コスト化できる。 推論プロセスの安全性評価も強化 OpenAIはGPT-5.4のリリースに合わせ、モデルの「思考の連鎖（Chain-of-Thought、CoT）」——複数ステップの推論過程を可視化する仕組み——を対象とした新たな安全性評価を導入した。AI安全研究者の間では、推論モデルが思考プロセスを意図的に隠蔽・偽装するリスクが懸念されていた。今回の評価によれば、GPT-5.4 Thinkingでは「モデルが推論を隠す能力を持たないことが示唆される」とし、CoTの監視が有効な安全ツールであり続けることが確認されたとしている。 GPT-5.4は、単なるチャットアシスタントを超え、複数のソフトウェア環境をまたいで自律的に業務を遂行する「デジタルワーカー」への転換点として注目されている。API経由での利用が可能で、企業向けの本格的な業務自動化への活用が期待される。 元記事: OpenAI launches GPT-5.4 with Pro and Thinking versions

Windows 11 26H1はArm専用——Snapdragon X2デバイス向けに正式リリース Microsoftは、Windows 11の新バージョン「26H1」がQualcommの最新SoC「Snapdragon X2」搭載デバイス専用であることを正式に確認した。既存のx86/x64 PCやArm以外のデバイスへの配信は行われない。 新コードベース「Bromine」を採用 26H1が通常のアップデートと大きく異なる点は、その内部構造にある。現行のWindows 11（24H2/25H2）が「Germanium（ゲルマニウム）」と呼ばれるコードベース上で動作しているのに対し、26H1は新世代の「Bromine（ブロミン）」コードベースを採用している。 このコードベースの相違により、26H1を搭載したデバイスは、今年後半にリリース予定の26H2へのアップグレードが不可能となる見通しだ。ただしMicrosoftは、「将来のWindowsリリースでアップデートへの道筋を提供する」と述べており、GermaniumベースのWindowsもいずれBromineへ移行する計画があることを示唆している。その時期は来年になる可能性が高い。 2024年の24H2リリースと酷似した展開 この状況は、2024年6月にリリースされたWindows 11 24H2を彷彿とさせる。24H2も当初はCopilot+ PC（Arm専用）向けに先行提供され、同年10月になってようやく全デバイスへの一般配信が開始された経緯がある。 ただし26H1は24H2と異なり、エンドユーザー向けの新機能はほとんど含まれていない。その主な目的は、Snapdragon X2という次世代シリコンへの対応であり、一般ユーザーにとって魅力的な機能アップデートではない点に注意が必要だ。 NVIDIAの新チップ「N1X」も26H1対応か 業界内のリークや情報筋によれば、NVIDIAが開発中のArm向けWindowsチップ「N1X」も26H1が必須となる見込みだという。Microsoftの言い回しも「今後さらなるハードウェアが26H1のコードベースを必要とする」と示唆しており、次世代Armデバイスの拡充に向けた布石とみられる。 サポート期間 26H1のサポート期限は以下の通り。 Home / Pro: 2028年3月まで Enterprise / Education: 2029年3月まで 一般ユーザーへの影響は？ 現在Windows 11 25H2、24H2、またはそれ以前のバージョンを使用しているユーザーは、26H1を気にする必要はない。MicrosoftがすべてのWindowsデバイスを対象とした「真の機能アップデート」として位置づけているのは、今年後半にリリース予定の26H2だ。 26H1はあくまでも特定ハードウェアのための技術的なプラットフォーム整備であり、Windows開発が2つのブランチに分岐するという新たな展開が、今後の同社のアップデート戦略にどう影響するかが注目される。 元記事: Microsoft confirms Windows 11 26H1 will be for Arm devices only at launch — Snapdragon X2-powered devices officially shipping with 26H1

Microsoftは2026年3月末、Windows 11向けのプレビュー更新プログラム KB5079391 の配信を一時停止した。一部のデバイスでインストールに失敗するエラーが報告されたためだ。 何が起きたか 問題の更新プログラムは、セキュリティアップデートではなく「プレビュー更新」として先週リリースされた。しかし一部のユーザーがインストールを試みた際、エラーコード 0x80073712（WinSxSフォルダ内のアセンブリファイル欠損を示すエラー）が発生し、インストールが完了しない状態に陥った。Microsoftはこの問題を受け、金曜夜（日本時間3月28日未明）に配信を緊急停止した。 Microsoftは「問題調査中の追加影響を防ぐため、一時的に本更新プログラムの提供を制限した」と公式にコメント。ユーザーへのエラーメッセージには「一部の更新ファイルが見つからないか問題があります。後で再度ダウンロードを試みます」と表示されていた。 影響範囲と深刻度 本件はWindows 11の 24H2 および 25H2 に影響する。ただし、インストール段階で失敗しているため、既存のシステムが壊れる事態は回避されている。また今回の更新はセキュリティパッチではなく任意適用のプレビューであり、適用していないユーザーへの直接的な影響はない。 なお、この問題は2026年3月の月例更新でMicrosoftアカウントのサインインが壊れた不具合を修正するアウトオブバンドパッチをリリースしたわずか数日後に発生している。 「品質改善公約」の直後という皮肉 今回の一件が業界で注目を集めている理由は、タイミングにある。Microsoftは最近、Windowsの品質・信頼性向上へのコミットメントを公式に表明していた。Windows部門責任者のPavan Davuluri氏は「高い水準で私たちを評価し続けてくださり、ありがとうございます」とユーザーへのメッセージを発信したばかりだ。 そのわずか後に発生した今回の問題は、「プロダクション品質」と銘打ったプレビュー更新がいとも簡単に失敗するという現実を改めて浮き彫りにした。ここ数カ月、WindowsはMicrosoftアカウントの認証障害、予期しない再起動、機能のリグレッションなど品質面での問題が続いており、ユーザーや企業IT部門からの不信感が高まっている。 今後の見通し Microsoftは配信再開の時期を明示していない。4月の Patch Tuesday（月例セキュリティ更新日）が目前に迫っており、プレビュー更新のまま放置するのか、修正版を出すのかが注目される。 日本国内の企業ユーザーや個人ユーザーは、Windows Updateの設定で「プレビュー更新プログラムを取得する」をオンにしている場合は注意が必要だ。現時点では配信停止中のため自動適用される可能性は低いが、再開後にエラーが出ても焦らず待機するのが賢明だ。 元記事: Microsoft pulls Windows update after installation problems

Azure Cosmos DB の Fabric ミラーリング、プライベートエンドポイント対応が一般提供開始 Microsoftは、Azure Cosmos DB の Microsoft Fabric ミラーリング機能において、プライベートエンドポイント（Private Endpoint）サポートの一般提供（GA: Generally Available） を発表した。これにより、インターネットを経由せずに企業のプライベートネットワーク内でデータを安全にレプリケーションできるようになった。 Fabric ミラーリングとは Microsoft Fabric のミラーリング機能は、Azure Cosmos DB などの運用データベースのデータをリアルタイムで Fabric の OneLake へ自動的に複製する仕組みだ。アプリケーション側の運用データベースに手を加えることなく、分析・BI・AI ワークロード向けのデータ基盤を構築できる点が特長で、ETL パイプラインの開発・運用コストを大幅に削減できる。 プライベートエンドポイント対応で何が変わるか これまでのミラーリングは、パブリックネットワーク経由での接続が前提だったため、金融・医療・官公庁など厳格なネットワーク分離を求める業界での採用に課題があった。今回のGA対応により、以下のような構成が本番環境で利用可能になった。 Cosmos DB アカウントをパブリックアクセス無効に設定したまま Fabric へミラーリング Azure Virtual Network（VNet）内に閉じた通信経路でデータを転送 コンプライアンス要件（ISMS、PCI DSS 等）を満たしたデータ統合パイプラインの構築 日本国内でも金融機関やヘルスケア企業を中心に、ネットワーク分離要件のためクラウドサービスの利用範囲が制限されるケースが多い。この対応により、そうした組織でも Fabric による統合データ分析基盤を検討しやすくなるだろう。 MySQL の Fabric ミラーリングもプレビュー開始 あわせて、MySQL から Microsoft Fabric へのリアルタイムミラーリングがプレビューとして提供開始された。Cosmos DB（NoSQL）に加え、広く普及しているリレーショナルDBである MySQL もサポート対象となったことで、Fabric を中心としたデータ統合の選択肢がさらに広がっている。 まとめ 機能 ステータス Cosmos DB ミラーリング（プライベートエンドポイント） GA（一般提供） MySQL → Fabric ミラーリング プレビュー ...

MicrosoftがAIエージェント管理の新基盤を発表 Microsoftは2026年5月1日、AIエージェントの統合管理プラットフォーム「Agent 365」と新しいエンタープライズライセンス「Microsoft 365 Enterprise E7」の一般提供（GA）を開始する予定だ。企業内に急増するAIエージェントの監視・ガバナンス・セキュリティを一元管理する「コントロールプレーン」として機能し、他社ベンダー製エージェントも管理対象に含まれる。 なぜ今なのか 近年、大企業ではメール・ドキュメント・業務アプリを横断して自律的に動作するAIエージェントの試験導入が加速している。しかし、その動きに伴い「データ漏洩リスク」「コンプライアンス違反」「監査証跡の欠如」といった懸念がセキュリティチームから多く寄せられていた。 MicrosoftはすでにCopilotをWord、Excel、Teamsに統合済みだが、「エージェントが何にアクセスでき、何をできるのか」をより細かくコントロールしたいという要望に応える形で、今回の発表に至った。 Agent 365の主要機能 Agent 365の中核は、AIエージェントに「ファーストクラスのID（アイデンティティ）」を付与する仕組みだ。各エージェントをユーザーと同様に管理でき、ロール割り当て・アクセス制限・監査ログが利用可能になる。 主な機能は以下のとおり： エージェントIDとポリシー管理 — ロールベースのアクセス制御と紐付け オブザーバビリティ — エージェントの行動・プロンプト・データアクセスをトレース ゼロトラスト制御 — 最小権限の原則に基づくアクセス制限 これらにより、エージェントが不正なデータへアクセス・変更するリスクを低減し、インシデント調査やコンプライアンス証明を容易にする。 E7：AIエージェント時代のガバナンス統合ライセンス 新設される「Microsoft 365 Enterprise E7」は、複数部署にわたって多数のAIエージェントを展開する組織を主なターゲットとしている。既存のE3・E5が持つ条件付きアクセス・DLP（データ損失防止）・暗号化・インサイダーリスクの各制御を、エージェント向けに統合・拡張するものとみられる。 日本企業においても、クラウドセキュリティや個人情報保護法対応の観点から、エージェントの行動ログ管理は今後必須要件になるだろう。 モデルの選択肢：OpenAIとAnthropicに対応 「Microsoft 365 Copilot Wave 3」では、OpenAIモデルに加えてAnthropic Claudeも選択肢として提供される。これにより企業はタスクの性質・リスクプロファイル・コストに応じて最適なモデルを選べるようになる。 また、特定モデルにサービス障害やポリシー変更が発生した際の代替手段としても有効であり、業界・地域ごとの規制要件への対応にも柔軟性をもたらす。 残る課題 CRM・ERPなどサードパーティシステムとの統合をどう実現するかは、今後の重要な論点だ。多くのエージェントはM365の外側で動作するため、標準化されたログ形式や明確な統合パスが必要になる。ライセンスコストの詳細も現時点では明らかになっておらず、導入判断には引き続き注目が必要だ。 元記事: Microsoft Debuts Agent 365 and E7 - The New York Report

LiteLLM、Delveとの契約解消を公式発表 数百万人の開発者が利用するAIゲートウェイサービス「LiteLLM」は、セキュリティコンプライアンス認証を提供するスタートアップ「Delve」との契約を解消すると公式に発表した。今後は競合サービスの「Vanta」を通じて認証を再取得するとしている。 LiteLLMは開発者がOpenAIやAnthropicなど複数のLLM（大規模言語モデル）プロバイダーを統一インターフェースで呼び出せるOSSライブラリとして広く普及しており、エンタープライズ向けのゲートウェイ機能も提供している。日本国内でも多くのAIアプリケーション開発で採用されている。 相次ぐ問題が引き金に 今回の決断には、二つの問題が重なった。 一つ目は、LiteLLMのオープンソース版が先週、深刻なクレデンシャル窃取マルウェアの被害を受けたこと。このインシデントにより、同社のセキュリティ態勢が改めて注目を集めた。 二つ目は、Delve自体への不信感の高まりだ。Delveは「AIネイティブなコンプライアンス認証」を売りにしたスタートアップだが、匿名の内部告発者から虚偽のデータを生成して顧客に誤解を与え、形式的なチェックしかしない審査員を使って認証を通過させていたとの告発が相次いでいる。 Delveの創業者はこれらの疑惑を否定し、顧客全員への無償再テストを申し出たが、内部告発者は週末にかけて「証拠」とされる追加資料を公開。疑惑は収束するどころか拡大している。 CTO自らXで声明 LiteLLMのCTO、Ishaan Jaffer氏は月曜日にX（旧Twitter）で声明を投稿。Vantaを使って認証を再取得し、独立したサードパーティ審査員を自社で選定してコンプライアンス管理を検証すると表明した。 SOC 2やISO 27001といったセキュリティコンプライアンス認証は、企業がインシデント防止の手順を整備していることを第三者が保証するもの。AIインフラを担うサービスにとって、エンタープライズ顧客からの信頼を得るうえで欠かせない要素だ。 今回の一連の出来事は、急拡大するAIスタートアップ市場において、コンプライアンス認証の品質と透明性がいかに重要かを改めて浮き彫りにした。LiteLLMの「足で投票する」判断は、業界全体への警鐘ともなりそうだ。 元記事: Popular AI gateway startup LiteLLM ditches controversial startup Delve

AIが上司になる時代——15%のアメリカ人が受け入れ意向 「マネージャーをチャットボットに替えてもいい」——そう答えるアメリカ人が増えつつある。 クイニピアック大学（Quinnipiac University）が2026年3月30日に公表した世論調査によると、**アメリカ人の15%**が「AIプログラムがタスクを割り当て、スケジュールを管理する直属の上司であっても構わない」と回答した。同調査は2026年3月19日〜23日にかけて全米の成人1,397人を対象に実施され、AIの導入状況、信頼度、雇用への不安なども幅広く聞いている。 中間管理職を侵食するAIの波 もちろん、大多数の回答者は人間の上司をAIに置き換えることに否定的だ。しかし、AIが管理業務の一端を担う動きは、すでに現実のものとなっている。 人事・財務ソフトウェア大手のWorkdayは、従業員に代わって経費精算の申請・承認を行うAIエージェントを展開済みだ。Amazonは中間管理職の役割の一部をAIワークフローで代替し、その過程で数千人規模の管理職レイオフを実施した。さらにUberでは、エンジニアたちがCEOのダラ・コスロシャヒ氏をモデル化したAIを構築し、実際の役員会議の前に事業提案の事前審査を行わせているという。 こうした流れは「ザ・グレート・フラット化（The Great Flattening）」とも呼ばれ、組織の階層構造を大幅に削減する動きとして注目されている。将来的には、全自動化された従業員と経営幹部を擁する「一人で数十億ドル企業」が誕生するという見方も出始めている。 雇用への不安は根強い 一方、AIが雇用全体に与える影響への懸念は依然として強い。同調査では回答者の**70%**が「AIの進歩により雇用機会が減少する」と回答。就業者に絞ると、**30%**が「AIによって自分の仕事が不要になるかもしれない」と、強く、あるいはある程度懸念していると答えた。 AIによる管理職代替は、欧米の大企業で着実に進行している。日本でも業務効率化ツールとしてのAI導入は広がっているが、「AIが直属の上司」という形態が受け入れられるかどうかは、文化的・組織的な背景も絡む複雑な問題だ。テクノロジーの進化とともに、「管理する」という行為の意味そのものが問われる時代が始まっている。 元記事: 15% of Americans say they’d be willing to work for an AI boss, according to new poll

GitHubのPRに「広告」が出現――開発者コミュニティに衝撃走る 2026年3月30日、オーストラリア・メルボルン在住のソフトウェアエンジニア、ザック・マンソン氏が自身のプロジェクトのプルリクエスト（PR）に奇妙なメッセージが表示されているのを発見した。チームメンバーがCopilotにPR内のエラー修正を依頼したところ、GitHub Copilotのエージェント機能と、macOS/Windows向けの人気ランチャーツール「Raycast」を宣伝するような内容が自動挿入されていたのだ。 「最悪だ。いつかこんなことが起きると思っていたが、こんなに早いとは思わなかった」――マンソン氏はこう投稿し、その内容はHacker Newsでたちまち拡散。開発者コミュニティに大きな波紋を呼んだ。 Microsoftが公式否定「広告ではなくバグ」 騒動を受け、MicrosoftはWindows Latestの取材に対して公式コメントを発表した。 GitHubのデベロッパーリレーションズ担当VP、マーティン・ウッドワード氏は次のように述べた。 「GitHubは現在も今後も、GitHub上に広告を掲載する予定はありません。プルリクエストのコメント内で不適切な文脈に表示されてしまったGitHub Copilotコーディングエージェントのヒント機能に、プログラムロジックの問題があったことを確認しました。今後はPRコメントからエージェントヒントを削除します」 同社によると、このヒントメッセージはもともとCopilotが自動生成したPRにのみ表示される仕様だったが、バグにより開発者がCopilotを呼び出してコードを編集した際に、人間が作成したPRにも誤って表示されてしまったという。 また、Raycastの開発チームも「Microsoftと広告契約は一切結んでいない」と否定声明を出しており、Microsoft側の「バグによる誤表示」という説明と整合している。 背景：GitHub CopilotのPR連携機能 2026年3月24日にGitHubが公開したリリースノートには、Copilotをプルリクエストに直接招待してコード修正を依頼できる新機能が紹介されている。この機能ではCopilotが既存PRのブランチをベースに新しいPRを作成する仕組みになっており、今回の問題はこの新機能の展開直後に発生した。 開発者への影響と今後 MicrosoftはすでにPRコメントへのエージェントヒント表示を削除する対応を完了したと説明している。 今回の騒動は、AI支援ツールが開発ワークフローに深く組み込まれるなかで、意図しない動作が「広告」と誤解されうるリスクを改めて浮き彫りにした。開発者が日常的に使うツールへの信頼を守るためには、新機能リリース時のQAプロセスと透明性の確保がより一層重要になると言えるだろう。 元記事: Microsoft says Copilot ad in GitHub pull request was a bug, not an advertisement

米医療ITのCareCloudにサイバー攻撃——患者データの窃取を確認 アメリカの医療IT企業CareCloud（ニュージャージー州）は2026年3月30日、同社の電子カルテ（EHR: Electronic Health Record）システムが不正アクセスを受け、患者データが流出したことを明らかにした。同社は米証券取引委員会（SEC）への提出書類でこの事実を開示している。 8時間にわたるネットワーク障害 同社によると、今回のインシデントは3月16日に発生した。攻撃者がCareCloudのITインフラに侵入し、「CareCloud Health」部門のネットワークに一時的な障害を引き起こした。6つあるEHR環境のうち1つが約8時間にわたって機能不全に陥り、当日夜には全機能が復旧したという。 CareCloudは侵害を検知後、サイバーセキュリティ保険会社へ報告するとともに、Big4会計事務所傘下のサイバー対応アドバイザリーチームを起用。外部からのセキュリティ強化と、インシデントの全容解明に向けたITフォレンジック調査を進めている。 患者データへの不正アクセスを確認、被害規模は調査中 調査の結果、侵害された環境には顧客の患者健康記録が含まれていたことが確認された。ただし現時点では、影響を受けた個人の数や具体的なデータの種類は特定されておらず、引き続き調査が行われている。 CareCloudは「攻撃者はすでにデータベースへのアクセス権を持っていない」と説明しており、他のプラットフォームや部門、システム環境への影響はないとしている。全ての影響システムは復旧済みで、同様のインシデント再発防止に向けた外部専門家との協力体制も整えている。 なお、本件についてランサムウェアグループによる犯行声明は確認されていない。 医療分野を狙ったサイバー攻撃が相次ぐ CareCloudはSaaS（Software as a Service）形式で、医療機関向けに収益サイクル管理・診療管理・患者体験管理・EHRソリューションを提供する上場企業だ。医療ITはサイバー攻撃の格好のターゲットとなっており、最近もCognizant TriZettoの情報漏洩（340万人規模）やハワイ大学がんセンターへのランサムウェア攻撃など、医療データを狙う事案が相次いでいる。 日本でも電子カルテシステムへの攻撃事例が増加傾向にあり、医療機関のセキュリティ体制強化が急務となっている。今回の事案は、患者データを扱うクラウドサービスにおけるセキュリティ対策の重要性を改めて示すものといえる。 元記事: Healthcare tech firm CareCloud says hackers stole patient data