Tech News JP

「署名されているから安全」という前提が崩れつつある 2026年4月、セキュリティ企業 Huntress の研究者たちが衝撃的なキャンペーンを詳報した。デジタル署名付きのアドウェアが、SYSTEM権限でウイルス対策製品を完全に無効化するペイロードを展開していたというものだ。被害は教育機関・公共インフラ・政府機関・医療機関を含む世界124か国、わずか1日で2万3,500台以上のエンドポイントが感染ホストとして観測された。 「PUP（Potentially Unwanted Program）だから大したことない」という甘い認識が、いかに危険かを突きつける事例だ。 手口の全体像——合法ツールを踏み台にした「サイレント侵害」 今回の攻撃の主役は、Dragon Boss Solutions LLC という企業が署名した一連の「ブラウザ」アプリだ。Chromstera、Chromnius、WorldWideWeb、Artificius Browserといった名称で流通しており、多くのセキュリティ製品からPUP扱いを受けていた。 表向きはブラウザとして動作しつつ、内部では Advanced Installer という商用パッケージングツールの自動更新機構を悪用している点が巧妙だ。正規ツールのアップデート機能を間借りすることで、セキュリティ製品の検知をすり抜けやすくしている。 侵害の流れ 更新チェック — 設定ファイルに埋め込まれた複数のフラグにより、ユーザー操作を一切必要とせずサイレント実行 偵察フェーズ — 管理者権限の有無、仮想マシン検出、インターネット接続確認、レジストリからのAV製品特定（Malwarebytes、Kaspersky、McAfee、ESETを明示的にターゲット） MSIペイロード展開 — Setup.msi をGIF画像に偽装して取得・実行。SYSTEM権限で動作 ClockRemoval.ps1 の投下 — AVサービスの停止・プロセス強制終了・インストールディレクトリの削除・レジストリ消去を実施 再インストール封鎖 — hostsファイルを改ざんしてAVベンダーのドメインを 0.0.0.0 にヌルルーティング。更新も再インストールも不能に 永続化 — システム起動時・ログオン時・30分ごとのタスクスケジューラ登録でAV除去を繰り返し実行 Opera、Chrome、Firefox、Edgeのインストーラーも標的にされているが、これはブラウザハイジャック機能への干渉を避けるためと分析されている。 なぜこれが重要か——「署名 ≠ 安全」を現場に刻め コード署名証明書は、ソフトウェアの「発行元の身元」を証明するものだ。しかしそれは「中身が安全である」ことを保証しない。今回の攻撃は、この前提の混同を意図的に突いている。 日本の組織でも、「署名済みだからインストール許可」という運用ルールを持っているケースは少なくない。AppLocker や Windows Defender Application Control（WDAC）の構成が甘ければ、署名の有無だけで制御を通過させてしまう。 PUPは「迷惑なだけで害はない」と軽視されがちだが、今回のケースはその出発点から最終的にAV完全無効化・ドメイン封鎖・SYSTEM権限の乗っ取りへと進展している。初期侵害の経路として「アドウェア」が使われる時代に入っていると認識しなければならない。 実務への影響——明日から使える対策ポイント 1. WDAC / AppLocker の証明書だけに頼らないポリシー設計 発行元証明書に加えて、ファイルハッシュ・製品名・バージョンの組み合わせで制御する構成に見直す。Intelligent Security Graph（ISG）との連携も有効だ。 2. 「PUP検知=即対処」の運用ルール化 SIEM/EDRの検知ルールでPUPアラートを「低優先度」に分類している場合、今すぐ見直す。アドウェアであっても高権限で動作している痕跡があれば最優先にエスカレートする。 3. hostsファイル・レジストリの変更監視 FIM（ファイル整合性監視）を有効にし、C:\Windows\System32\drivers\etc\hosts への書き込みをリアルタイムでアラートする。これは本攻撃の「再インストール封鎖」を早期発見する最も現実的な手段だ。 4. 定期的な「AV有効性確認」の自動化 ...

何が起きたか 2026年4月、WordPressプラグイン開発会社「EssentialPlugin」が提供する30本以上のプラグインに悪意のあるコードが仕込まれていたことが判明した。被害を受けたプラグインの総インストール数は数十万に達する。 発端は、マネージドWordPressホスティング「Anchor Hosting」の創業者Austin Ginderへの内部情報提供だった。調査を進めたところ、すべての汚染がEssentialPluginが6桁の金額（数百万円規模）で新オーナーに買収された2025年8月以降に遡ることが分かった。 バックドアは数ヶ月間、完全に沈黙していた。そして最近になって突如「活性化」し、外部のコマンド＆コントロール（C2）サーバーへ接続して wp-comments-posts.php（正規の wp-comments-post.php に似せた名前）を取得。このファイルがWordPressのコア設定ファイル wp-config.php にマルウェアを注入する仕組みだ。 攻撃の巧妙さ——3つのポイント 1. イーサリアムベースのC2アドレス解決 通常のマルウェアはIPアドレスやドメインをハードコードするが、本攻撃ではEthereumブロックチェーンを使ってC2サーバーのアドレスを動的に解決する。ブロックチェーンは書き換えが困難なため、C2インフラをブロックされにくい。インフラのテイクダウンへの耐性が高く、検出・無効化がきわめて難しい設計だ。 2. Googlebot専用のスパム配信 注入されたコードは、スパムリンク・リダイレクト・偽ページをGooglebot（Googleの検索クローラー）にしか表示しない。サイトオーナーが自分のサイトを開いても何も見えないため、被害に長期間気づけない。SEOの毀損と検索順位の下落として静かに被害が積み上がる。 3. 「時限式」サプライチェーン攻撃 買収直後にバックドアを仕込み、しばらく休眠させてから一斉に活性化する手法は近年増加傾向にある。オープンソースプロジェクトやSaaS系サービスの「買収」を入口にする攻撃は、従来のコード審査やウイルス対策では検知が難しい。 WordPress.orgの対応と残る課題 WordPress.orgは報告を受けて迅速に動き、問題プラグインのリポジトリへのアクセスを閉鎖。強制アップデートを配布してバックドアの通信経路を無効化した。 ただし「強制アップデートは wp-config.php の汚染を修復しない」とWordPress.orgは明示している。データベース接続情報など重要な設定が記載された wp-config.php が汚染されたままの場合、バックドアの通信が止まっても攻撃者はすでにサイト情報を取得済みの可能性がある。 また、マルウェアの潜伏場所が wp-comments-posts.php だけとは限らず、他のファイルにも潜んでいる可能性があることも警告されている。 実務への影響——日本のエンジニア・IT管理者がいまやるべきこと 即時確認 自社・顧客サイトでEssentialPlugin製品（旧称: WP Online Support）を使用していないか確認する 対象プラグインのリストはPatchStackの調査記事で公開されている wp-comments-posts.php（正規ファイルは wp-comments-post.php、末尾の s に注意）の有無を確認 wp-config.php の内容を直接確認し、不審なコードがないかチェック 中長期の対策 プラグインの購入・導入審査にサプライチェーンリスクの観点を加える: 「誰が所有しているか」「最近買収されていないか」をチェックするフローを設ける File Integrity Monitoring（FIM）の導入: wp-config.php などのコアファイルに対する変更をリアルタイム検知する仕組みを入れる 最小権限の原則: プラグインが持つファイル書き込み権限を必要最小限に絞る Webアプリケーションファイアウォール（WAF）: Googlebot偽装のアウトバウンド通信をブロックするルール整備 筆者の見解 この事件が示すのは、「コードの品質チェック」や「脆弱性スキャン」だけではもはや十分でないという現実だ。攻撃者は合法的な手段（プラグインの正規買収）でサプライチェーンに侵入し、時間をかけて信頼を積み上げてから攻撃を発動する。8ヶ月間の潜伏期間中、このバックドアはどんな静的解析にも引っかかりようがなかった。 C2アドレスの解決にイーサリアムブロックチェーンを使うアプローチは、インフラのテイクダウン耐性という観点で技術的に興味深い。今後、同様の手法が他の攻撃でも使われることは間違いなく、ネットワーク層での検知戦略の見直しが急務だ。 Non-Human Identity（NHI）の観点からも示唆が多い。WordPress環境ではプラグインがサーバー上のファイルを読み書きし、外部APIと通信し、データベースに接続する——これらはすべてNHIとして管理されるべき「アクセス権」だ。「インストールしたら終わり」ではなく、「このプラグインがどのリソースに対してどんな権限を持ち続けているか」を継続的に把握する仕組みが求められる。 WordPress自体を使うかどうかという選択論に持ち込むのは生産的ではない。現実的には、既存サイトの大半はWordPressで動いており、完全移行は現実的でない。だからこそ「禁止」ではなく「安全に使い続けるための仕組みを作る」という発想で、FIMの導入・権限の最小化・サプライチェーンの定期的な棚卸しを着実に進めることが今できる最善策だ。 すでに wp-config.php が書き換えられている場合、強制アップデートで「通信は止まった」状態でも、攻撃者がDB接続情報を入手済みである可能性を捨てられない。このケースではパスワードローテーションとログの精査を最優先で実施してほしい。 出典: この記事は WordPress plugin suite hacked to push malware to thousands of sites の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Snapが従業員の約16%にあたる1,000人以上のレイオフを発表し、同時に300の求人枠も閉鎖した。単なるコスト削減ではなく、「AIを活用した小規模チームがすでに大きな成果を出している」という手応えを組織再編の根拠に据えている点が、今回の動きをとりわけ注目すべきものにしている。 何が起きているのか Snapの発表によれば、今回の構造改革は同社にとってここ数年で最大規模のものだ。削減対象は開発・運営部門に広く及び、一方でAIエンジニアリングへの投資は強化される方向性が示されている。経営陣は「AIが武器になった今、組織の形そのものを変えなければ競争力を維持できない」というメッセージを明確に打ち出している。 注目すべきは、この発表が単なる業績不振による人員整理ではない点だ。Snap自身が「AIチームはすでに成果を出している」と述べており、これは「AI導入による生産性向上」が具体的な組織変更の根拠として機能し始めた、業界初期の事例のひとつといえる。 「少数精鋭×AI」が組織の標準形になる 従来のソフトウェア開発では、機能追加・品質保証・インフラ管理それぞれに専任チームを置くことが当然とされてきた。しかしAIがコード生成・テスト・インフラ管理の多くを担えるようになった今、「人間が担うべき作業の絶対量」が劇的に減少している。 Snapの事例が示すのは、その変化が理論ではなく実際の経営判断に反映される段階に入ったということだ。ソーシャルメディアという競争の激しい領域で、1,000人規模の削減と並行してAI投資を拡大するという判断は、経営層が「AIで代替できる仕事の範囲」を相当広く見積もっていることを示している。 実務への影響：日本のIT現場で何を考えるべきか この動きは日本のIT部門にとっても対岸の火事ではない。以下の点を今すぐ自組織に照らし合わせて考えてほしい。 1. 「人員数＝処理能力」の方程式を疑う プロジェクトが遅延した際に「人を増やす」判断が先に来るなら、一度立ち止まる価値がある。同じ課題をAIを活用した少人数チームで解決できないか検討してみてほしい。 2. 「仕組みを作れる人材」の価値が急騰する AIに指示を出し、自律的に動くパイプラインを設計・改善できる人材は、今後ますます希少かつ高価値になる。コードを書くだけでなく「AIを使って仕組みを動かす」スキルを身につけることが、キャリアにおける最重要投資のひとつだ。 3. 採用計画の前提を見直す 毎年一定数の新卒・中途を採用し続けるモデルが本当に最適かどうか、再検討する時期に来ている。採用数よりも「どんな仕組みを持った組織を作るか」を先に考える順序が、今の時代には合っている。 4. 既存メンバーのリスキリングを優先する Snapのような企業は「AIに置き換えられる役割を削減」している。一方で、AIを使いこなせる人材への需要は高まっている。既存メンバーをAI活用の担い手に育てる投資は、採用コストよりも即効性が高いケースが多い。 筆者の見解 Snapの今回の動きを見て、「ついにここまで来たか」という実感がある。AIが「補助ツール」から「組織設計の前提」に変わる転換点を、具体的な数字で目の当たりにしたような感覚だ。 正直に言えば、日本のIT業界では「AIで生産性が上がった話」は増えているのに、「組織の形を変えた」という話がまだほとんど出てこない。技術的には変革が起きているのに、組織・人事・採用の構造は10年前とほぼ同じという企業が多すぎる。Snapの事例はその矛盾を鋭く突きつけてくる。 「少数の仕組みを作れる人が、AIを使って大きな仕事を動かす」——これはもう未来の話ではなく、すでに起きていることだ。毎年同じ規模で新卒採用を繰り返し、頭数で課題を乗り越えようとするアプローチは、構造的なコスト競争力を失い続けるリスクがある。 とはいえ、大切なのは「AI導入で人を減らす」ことそのものではなく、「AIを活かした仕組みを作れる人材を組織の中心に置く」ことだ。削減ありきではなく、組織が何を実現したいかから逆算して役割と人員を設計する。Snapの判断が正しいかどうかは数年後に明らかになるが、「AIで何が変わるかを経営判断に組み込む必要がある」という問い自体は、すべてのIT組織が今すぐ向き合うべきものだと思っている。 出典: この記事は Snap cuts 16% workforce as it aggressively doubles down on AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11向けの累積アップデート KB5083769 および KB5082052 を適用した端末において、BitLockerのリカバリモードが誤って起動してしまう不具合を公式に認めた。影響範囲はWindows 11の全サポートバージョンにとどまらず、Windows 10およびWindows Serverにも及んでいる。 何が起きているのか BitLockerは、ディスク全体を暗号化してデータを保護するWindowsの機能だ。通常、ハードウェア構成の変更やTPMの状態変化など「何か重要なものが変わった」と検知したときにリカバリキーの入力を求める。今回のケースは、OSアップデートによって不適切にその条件が満たされたと誤認され、再起動後にいきなり回復キーの入力画面が表示されるという事象だ。 Microsoftの公式見解では、この問題はアップデートのインストールプロセスにおけるBitLockerとTPMの状態管理に起因するとされており、回避策の調査中としている。 なぜこれが重要か BitLockerのリカバリキーは、多くの企業環境でActive DirectoryやMicrosoft Entra IDに保管されている。IT管理者がいるならまだリカバリは可能だが、問題はエンドユーザーが一人で作業している時間帯や、出先・在宅勤務中にこの画面に遭遇したときだ。リカバリキーがどこにあるか分からないユーザーは、完全に作業不能になる。 さらに深刻なのはサーバー環境だ。Windows Serverに同様の問題が発生した場合、サービス停止に直結する。BitLockerを有効化しているサーバーで再起動後にリカバリ画面が出れば、物理的またはコンソールアクセスが必要になるケースもあり、クラウド仮想マシンでは対応がより複雑になる。 実務での対応ポイント 【IT管理者向け】 パッチの展開を一時停止する判断も正解: 問題が公式確認されている状況では、KB5083769・KB5082052の自動展開を保留にすること。Microsoftが修正済みパッチをリリースするまで待つのは立派なセキュリティ判断だ。 BitLockerリカバリキーの保管状況を今すぐ確認: Microsoft Entra IDまたはActive DirectoryにリカバリキーがエスクローされているかをPowerShellや管理コンソールで確認する。保管されていない端末が一台でもあれば、今すぐ対処が必要だ。 影響端末の洗い出し: 既に該当パッチを適用済みの端末リストを作成し、ヘルプデスクに「BitLockerリカバリ画面が出た場合の対応手順」を共有しておく。 サーバーへの適用は特に慎重に: 本番サーバーへの展開前に、テスト環境での検証を必ず実施すること。 【一般ユーザー向け】 もし再起動後にBitLockerのリカバリキー入力画面が出た場合は、焦らずIT部門に連絡する。 個人PCでBitLockerを有効にしている場合は、Microsoftアカウントのセキュリティページからリカバリキーをあらかじめ確認・保存しておくこと。 筆者の見解 Windowsのアップデートが端末を「文鎮化」しかねない問題は、残念ながら珍しい話ではなくなりつつある。今回はBitLockerという、まさにセキュリティの要である機能が誤動作するという点で、インパクトが大きい。 このような不具合が続くと、IT管理者の現場では「すぐに当てるべきか、様子を見るべきか」という判断がますます難しくなる。セキュリティパッチは速やかに適用することが原則だが、パッチそのものが別のリスクを生む状況では、テスト環境での検証フェーズを設けることが現実的な対応だ。「数日様子を見てから展開する」という判断は、臆病ではなく、リスク管理として正しい行動だと筆者は考えている。 Microsoftには、品質管理プロセスの強化を期待したい。これだけの規模のエコシステムを持ち、Windows Updateという強力な配布基盤があるのだから、その基盤の信頼性を守ることがすべての前提になる。セキュリティ機能を守るためのパッチが、セキュリティ機能を壊すという矛盾は、早期に解消されることを強く願っている。 修正パッチのリリース情報は、Microsoftの公式リリースノートおよびWindows Updateのサポートページで随時更新される予定だ。影響を受けた場合は公式情報を都度確認してほしい。 出典: この記事は Microsoft confirms Windows 11 KB5083769, KB5082052 wrongly forcing BitLocker recovery の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の物議を醸す機能「Recall」が、またも厳しい視線にさらされている。新たに公開されたツールにより、Recallが蓄積するスクリーンショットや入力データを容易に抽出できることが実証された。Microsoftは「設計上の欠陥はない」と主張するが、セキュリティ研究者コミュニティの反応は冷ややかだ。 Recallとは何か——おさらい Recallは、PCの操作履歴をスクリーンショットとして定期保存し、自然言語で「あのとき見ていたページ」を検索できるようにするWindows 11の機能だ。2024年に発表された当初から「スパイウェアそのものだ」「ローカルに個人情報が大量蓄積される」として批判を集め、リリースが延期。その後Copilot+ PC向けにオプトイン形式で段階的に提供が始まった。 Microsoftは再設計にあたり、データをTPM（Trusted Platform Module）で保護し、Windows Helloによる生体認証が必要な「Secure Enclave」内に保存すると説明してきた。この説明が今、改めて問われている。 何が明らかになったか 今回公開されたツールは、Recallが使用するSQLiteデータベースと蓄積されたスナップショット画像に対して、管理者権限またはRecallデータへのアクセス権を持つユーザーのコンテキストからアクセスし、内容を一括エクスポートできることを示した。 Microsoftの反論は「これは想定された動作範囲内であり、アクセス権を持つユーザーが自分のデータを読めるのは当然」というものだ。技術的には間違っていない。しかし批判の核心は別のところにある。 問題の本質は「データが存在すること」そのものだ。 マルウェアが管理者権限を奪取した場合、Recallのデータベースはそのまま「過去数週間〜数カ月の行動記録」として流出する 企業環境でエンドポイントが侵害されたとき、Recallが有効だったPCは被害範囲が格段に広がる可能性がある フィッシングやソーシャルエンジニアリングで一般ユーザーのアカウントが乗っ取られた場合も同様 Microsoftが「欠陥なし」と言うのは「鍵のかかった金庫に泥棒が入ったとき金庫を開けられるのは設計どおり」と言っているに等しい。議論がかみ合っていない。 企業・IT管理者が取るべき対応 Recallの現実的なリスク評価 環境 推奨 機密情報を扱う企業PC Recall無効化を強く推奨 医療・法務・金融 コンプライアンス要件次第では即時無効化必須 一般コンシューマー オプトイン前提なので、デフォルトは無効のはず 個人の趣味用途 リスクを理解した上で各自の判断 グループポリシーでの制御 Intune / グループポリシーで Turn off saving snapshots for Windows ポリシーを有効化すれば企業全体でRecallを無効にできる。Copilot+ PC対象機器が社内に増えてきた場合、今から構成を確認しておくことを推奨する。 エンドポイントセキュリティとの組み合わせ Recallを使用する場合でも、EDR（Endpoint Detection and Response）ソリューションによるプロセス監視を組み合わせることで、不審なDBアクセスを検知できる体制を整えるべきだ。「機能を禁止する」より「使える状態で安全に管理する」アプローチが長続きする。 筆者の見解 Recallはアイデア自体は面白い。「あのとき調べていた情報をもう一度」というニーズは確かに存在するし、ローカル処理でプライバシーを守るというコンセプトも正しい方向性だと思っている。 ただ、Microsoftがセキュリティ研究者の指摘に対して「想定内の動作」と繰り返すだけでは、ユーザーの信頼回復にはつながらない。今の時代、エンドポイントへの侵害を「起きないこと」として設計するのはもう通用しない。侵害されることを前提にしたデータの最小化設計——「侵害されてもRecallのデータが渡らない」アーキテクチャ——こそが必要なはずだ。 Microsoftにはそれを実現する技術力が十分にある。Plutonチップ、Windows Helloの多要素認証、Confidential Computingと、セキュリティの基盤技術は世界トップクラスだ。だからこそ、「設計上の欠陥はない」という守りの一点張りではなく、「こういう侵害シナリオに対してはこう対応する」という前向きな議論を期待したい。 Recallはまだ発展途上の機能だ。このまま不信感の中で死んでいくには、ポテンシャルがもったいない。 出典: この記事は Windows 11’s controversial Recall is under fire again, while Microsoft denies flaws の内容をもとに、筆者の見解を加えて独自に執筆したものです。

企業内でのAI利用が急拡大する中、IT部門が頭を抱えている問題が「シャドーAI」だ。Microsoftは、Microsoft Edgeブラウザに新たなグループポリシーを追加し、IT管理者が職場のAIアプリ利用をコントロールできる仕組みを整備する方針を明らかにした。 何が変わるのか この新機能により、IT管理者はEdge上で動作するAIアシスタントのアクセスをポリシーで制御できるようになる。具体的には、従業員が業務中に利用するAIアプリをCopilot in Edgeへ誘導したり、他のサードパーティAIアプリへのアクセスに制限をかけたりすることが可能になる。 ターゲットは明確だ。いわゆる「シャドーAI」——IT部門の承認を得ずに従業員が勝手に使い始める外部AIサービスを、ガバナンスの傘の下に収めることが目的だ。業務データが未審査のAIサービスに流れるリスクを、管理側のポリシーで封じ込めようとする動きである。 シャドーAI問題の現実 日本の企業でも、生成AIの業務利用は急速に広がっている。一方でセキュリティ・コンプライアンス担当者の悩みは深い。従業員がどのAIサービスに何のデータを入力しているか、実態を把握しきれていないケースがほとんどだからだ。 これは単なるポリシー違反の問題ではない。個人情報保護法・不正競争防止法・各種業法への抵触リスク、そして万が一のデータ漏洩時の責任所在の問題でもある。「禁止通達を出した」だけでは何も解決しないことは、過去のBYODやクラウド利用制限の歴史が証明している。 実務での活用ポイント 1. 「禁止」ではなく「統制」で設計する グループポリシーでAIアプリを一律ブロックするアプローチは、かえって業務非効率を生み、従業員が個人端末や個人回線で使い始めるという抜け道を生む。今回のEdgeポリシーのように「承認済みツールを優先表示・誘導する」設計の方が現実的かつ長期的に機能する。 2. Microsoft Entra ID + Conditional Accessとの組み合わせを検討 EdgeのAIポリシーは、既存のMicrosoft 365コンプライアンス基盤と連携させてこそ真価を発揮する。Conditional Accessによるデバイスコンプライアンス確認と合わせて設計することで、ゼロトラスト的な多層防御が実現する。 3. データ分類ポリシーとセットで運用する どのデータをAIに入力してよいか・よくないかを明文化し、MIPラベルなどの情報保護機能と組み合わせる。技術的な制御だけでなく、従業員への教育・啓発もセットで行うことが不可欠だ。 筆者の見解 このEdgeポリシー追加の方向性は、基本的に正しい。「禁止で封じ込める」のではなく、「承認済みツールを使いやすくすることで自然に誘導する」というアプローチは、ガバナンスの本来あるべき姿だ。シャドーAIを生む根本原因は「承認されたツールが不便だから」であることが多い。その意味で、IT管理者がコントロールできる土台を整備すること自体は歓迎したい。 ただし、正直に言えば、この仕組みが本当に機能するかどうかは、Copilot in Edgeが「使われたいと思われる品質」を持てるかどうかにかかっている。管理者がポリシーで誘導できたとしても、実際に業務で役立つ体験を提供できなければ、従業員は個人端末での利用に逃げるだけだ。 Microsoftにはプラットフォーム・ブランド・エンタープライズ信頼性という、他が簡単に真似できない強みがある。その総合力を活かして、ガバナンス基盤と実用性を両立した本物のAIアシスタント体験を実現できる力は十分にあるはずだ。「使わされている」ではなく「これが一番便利だから使っている」と従業員が思える状態を作ること——そこに向けて全力を注いでほしい。プラットフォームの整備は着実に進んでいる。あとは中身の勝負だ。 出典: この記事は Microsoft will allow IT admins to force Copilot in Edge over other AI apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azureのストレージコストを「考えずに」最適化できる時代が来た。Microsoftは2026年4月、Azure Blob StorageおよびData Lake Storageのスマートティア（Smart Tier） を正式リリース（GA）した。2025年11月のIgniteで公開プレビューが始まってから約5ヶ月、早くも本番利用可能な状態に到達している。 ストレージコストは「気づいたら積み上がっている」コストの代表格だ。日本のクラウド利用現場でも、「とりあえずホット層に全部入れてある」「ライフサイクルポリシーを書いたけど誰もメンテしていない」という構成は珍しくない。スマートティアはそこへのひとつの回答になる。 スマートティアとは何か スマートティアは、オブジェクトごとの最終アクセス時刻を継続的に評価し、3つの層を自動で行き来させるフルマネージドの機能だ。 状態 移行先 条件 頻繁にアクセス ホット アクセスがあれば即座に昇格 30日間アクセスなし クール 自動降格 さらに60日間アクセスなし コールド 自動降格 重要なのは、データが再びアクセスされた瞬間にホットへ即昇格し、ティアリングサイクルがリセットされる点だ。GetBlobやPutBlobといった読み書き操作がトリガーとなる一方、GetBlobPropertiesのようなメタデータ操作はサイクルに影響しない——この設計の細かさが実務では効いてくる。 公開プレビュー段階のデータとして、スマートティアで管理された容量の50%以上が自動的にクール・コールド層へ移行したと報告されている。Azure Data Explorer（ADX）での採用事例でも、クエリのホットデータは即座にアクセス可能なまま、低頻度データはコスト効率の良い層へ自動移動するという動作が確認されている。 有効化の方法 設定はシンプルに設計されている。 新規ストレージアカウント作成時 ゾーン冗長構成（ZRS）のストレージアカウントを作成する際、デフォルトアクセス層として「スマート」を選択するだけ。Azure PortalとAPIの両方から設定可能だ。 既存アカウントへの適用 ゾーン冗長が有効になっている既存アカウントであれば、BlobアクセスTierを「default」から「smart」へ切り替えるだけで有効化できる。 現時点でほぼすべてのゾーン対応パブリッククラウドリージョンで利用可能だ。Azure JapanリージョンもZRSをサポートしているため、対象範囲に入る。 実務への影響 ライフサイクルポリシーとの使い分けを整理する スマートティアはライフサイクル管理ポリシーの「代替」ではなく「補完」として位置づけるのが現実的だ。「N日後に削除」「アーカイブへの移動」といった明示的なルールはライフサイクルポリシーが引き続き担う。「アクセス頻度に応じた動的なティア移動」はスマートティアに任せる——この役割分担を意識した設計が求められる。 ZRS（ゾーン冗長）が前提条件 スマートティアはゾーン冗長（ZRS）構成のストレージアカウントでのみ有効だ。LRS（ローカル冗長）のみのアカウントでは利用できない。既存アカウントへの適用を検討する場合は、まず冗長性設定の確認が必要になる。 トランザクションコストへの注意 ティア移行には読み出しコストが発生する。ホット→クールは書き込みコスト、クール→ホットは読み出しコストが加算される仕組みだ。アクセスが不規則なデータセットでは、自動昇降格が頻繁に起きてトランザクション費用がかさむ可能性がある。稼働後1〜2ヶ月はコストモニタリングを欠かさないようにしたい。 Data Lake Storageにも対応 Azure Data Lake Storage Gen2での利用も正式サポートされた。Databricks、Synapse Analytics、Azure Data Explorerなどのビッグデータワークロードでもスマートティアが機能するため、データ基盤全体でのコスト最適化が現実的になる。 筆者の見解 ストレージの自動最適化という機能単体で見れば、これは素直に良い仕事だと思う。「使った分だけ払う」というクラウドの本来の約束に、ようやくストレージが追いついてきた感覚だ。 ライフサイクルポリシーは「設計時に正しいルールを書く」ことを前提とした仕組みだったが、現実のデータアクセスパターンは設計者の想定を裏切り続ける。スマートティアはその前提を取り払い、「観察して動かす」アプローチに切り替えている。この発想の転換は、インフラ管理の方向性として正しい。 Azureが今後目指すべきは、こういった「仕組みを作れば自動で最適化が回り続ける」機能をどれだけ積み上げられるか、だと思っている。管理者がパラメータを手で調整し続けるのではなく、意図を定義したらあとはプラットフォームが動く——そういうプラットフォームとしての成熟度が問われている。 スマートティアはその方向の一歩として評価できる。まず検証環境で有効化し、実際のアクセスパターンとコスト変化を数週間観察するところから始めてほしい。「50%がクール層へ移行した」という数字が自分の環境でどう再現されるか、試してみる価値は十分ある。 出典: この記事は Optimize object storage costs automatically with smart tier—now generally available の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windows 10のサポート終了期日「2026年10月14日」はIT管理者の間でも周知されてきた。しかし、実はそれよりも深刻な問題が同年に潜んでいる。Secure Boot証明書の失効だ。単なるソフトウェアライフサイクルの話ではなく、物理的に起動できなくなるリスクを孕むこの問題は、まだ十分に語られていないと感じる。 2026年10月のEOLとは何か MicrosoftはWindows 10を2015年にリリースした際、10年間のサポートを明言していた。2020年にメインストリームサポートが終了し、延長サポートは本来2025年まで——それをさらに1年延長して2026年10月までとなった経緯がある。 EOL以降は、リモートコード実行・権限昇格・情報窃取を可能にする脆弱性を含むいかなるセキュリティ更新も提供されない。OSとしての機能は動き続けるが、攻撃者にとっては「既知の穴が塞がれないまま放置されたターゲット」になる。 Secure Boot証明書失効：こちらの方が深刻かもしれない Windows 10が使用する Microsoft Corporation UEFI CA 2011 証明書は、2026年中に有効期限を迎える。Secure Bootはブートプロセスに信頼済み署名付きソフトウェアのみをロードさせる仕組みだが、この証明書が失効すると検証に失敗し、システムが起動不能になるか、Secure Boot自体を無効化せざるを得なくなる。 Secure Bootを無効化するということは、ブートキット攻撃（OSロード前にマルウェアが制御を奪う）に対して無防備になることを意味する。Microsoftが証明書を任意に延長できない理由は、暗号学的な設計上の制約と、定期的な証明書ローテーションというセキュリティベストプラクティスにある。これはMicrosoftが「やらない」のではなく「できない」話だ。 EOL後もパッチ未適用で使い続ける判断をする組織は多いが、Secure Boot失効はOSが動くかどうかという土台の問題であり、セキュリティリスクとは別の次元の話である。 Extended Security Updates（ESU）：コストと限界 移行が間に合わない組織向けに、MicrosoftはESUプログラムを提供する。コンシューマー向けは初年度30ドル/デバイスとされているが、エンタープライズ向けは年々倍増する設計だ——1年目約61ドル、2年目約122ドル、3年目約244ドル（2029年まで）という試算がある。 ESUがカバーするのは重要なセキュリティ脆弱性のみであり、機能更新・非セキュリティ修正・テクニカルサポートは含まれない。年次更新が必要で、2029年以降は完全終了となる。延命策ではあるが、根本的な解決にはならない。 実務への影響——日本のIT管理者が今すぐやるべきこと 1. 台数把握と証明書確認を急げ まずWindows 10端末の棚卸しが必要だ。Get-WmiObject Win32_OperatingSystem や Microsoft Entra・Intuneのデバイスレポートで把握する。Secure Boot有効化状況も msinfo32 や PowerShell で確認できる。 2. Windows 11移行可否の判定 TPM 2.0・Secure Boot対応・CPU要件を満たさない古い端末は「更新プログラムで上げる」ではなくハードウェア更新が必要になる。調達リードタイムを考えると、2026年10月は決して遠くない。 3. ESUの費用対効果を計算する どうしても移行できない端末はESUで繋ぐが、「とりあえずESUで延命」の積み重ねは結局コストを押し上げる。Windows 10延長サポートに費やすコストをWindows 11端末の調達予算に回す判断を今から経営層に説明しておくべきだ。 4. Secure Boot無効化だけは避けよ 「起動しなくなった」問題を解決するためにSecure Bootをオフにする対処は、攻撃面を大幅に広げる。カーネルドライバーの締め出しをはじめとするWindowsのセキュリティ強化はSecure Bootを前提に設計されている。 筆者の見解 Windows 10のEOLは「ずっと前からわかっていた話」だ。しかしSecure Boot証明書の失効という問題は、エンドユーザーやSMB規模のIT担当者にはほぼ伝わっていないと感じる。「OSが動いているから大丈夫」という感覚は、この問題の前では通用しない。 Microsoftが1年の延長サポートを加えたり、コンシューマー向けESUを設けたりと、移行の猶予を作ろうとしている姿勢は評価できる。ただ、Secure Boot証明書の失効リスクについては、もっとわかりやすく・大きな声で周知してほしかったというのが本音だ。MicrosoftはWindowsのセキュリティ基盤をここ数年着実に強化してきた。その成果を正しく活かすためにも、ユーザーが「動いているから問題ない」のまま取り残されない情報発信を期待したい。 IT管理者の皆さんには、単なる「EOLのリマインダー」としてではなく、Secure Boot証明書失効という具体的な技術的タイムリミットとして今回の問題を捉え直してほしい。対応は早ければ早いほど選択肢が広い。 出典: この記事は Windows 10 End of Support 2026: Secure Boot Expiry, ESU Costs, and Critical Security Risks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

「AIで一発解決」という幻想から目を覚ます MicrosoftのAzureチームが、エージェント型AIを活用したアプリケーションモダナイゼーション（近代化）の実情をまとめたドキュメントを公開した。AI全盛の2026年初頭においても、「クリックひとつでモダナイゼーション完了」という夢には程遠い——そんな現実が、数百件にわたる実案件の経験から浮かび上がってくる。 この記事は、技術的な詳細よりも「なぜモダナイゼーションは難しいのか」という根本的な問いに正面から向き合う内容だ。AIツールに飛びつく前に読むべき、実践的な知見が詰まっている。 なぜレガシーシステムは「触りにくい」のか 多くのレガシーアプリケーションは共通の問題を抱えている。 ドキュメントの欠如: 重要なビジネスロジックが、密結合・ハードウェア依存・何年も放置されたモノリシックなコードの奥深くに埋もれている 依存関係の脆弱性: 誰も覚えていない暗黙の前提が随所に潜む 周辺システムとの深い結合: この結合こそが「ミッションクリティカル」たる所以であり、同時に変更を極めてリスキーにしている ここで重要な整理がある。「モダナイゼーション」と一言で言っても、実態は2種類に分かれる。 マイグレーション（移行） は、ビジネスロジックだけでなく実装・インターフェース・運用モデルも含めて可能な限り保存するアプローチだ。一方、メインフレームやOT機器のようにハードウェアに縛られたシステムは、リアーキテクチャ（再設計・再実装） が正解になる。どちらを選ぶかを最初に明確にしないと、プロジェクトは途中で方向を見失う。 エージェント型AIの実力と限界 エージェント型AIは確かにモダナイゼーションにかかる時間を短縮できる。コードの静的解析、依存関係の可視化、テストケースの自動生成——これらの作業でAIは明らかに価値を発揮する。 しかしドキュメントが警告するのは、ベンダーの「80%精度」という主張を鵜呑みにするなという点だ。「2026年初頭でもまだジェネレーティブAIの時代だ」と明言されている。自社のコードベース、自社のリスクプロファイルで検証するまでは、すべての主張はマーケティングとして扱え——この姿勢は、現場のエンジニアが持つべき基本的な態度だろう。 実務への影響——日本のIT現場が意識すべきこと 日本の大企業では、SAP・ERPの刷新や基幹系マイグレーションが続々と動き出している。そこにAIエージェントを組み込もうという動きも出始めている。しかしこのドキュメントが示す教訓は、日本のIT現場に直接刺さる。 「ツールより先に組織設計」 モダナイゼーションが技術問題ではなく組織問題である以上、ベンダーのデモに感動する前に「誰がビジネスロジックの最終判断をするのか」を決めることが先決だ。AIがコードを解析しても、「このロジックに業務上の意味があるか」を判断できるのは人間しかいない（今のところ）。 「AIエージェントに任せていい部分と任せてはいけない部分を分ける」 コード変換・テスト生成・依存関係の可視化はAIが得意な領域。しかしビジネスルールの解釈、リスク判断、ステークホルダー調整は人間の仕事だ。この境界を曖昧にするとプロジェクトは迷走する。 「Azureプラットフォームの上でAIを選ぶ自由を使う」 Azure AI Foundryを通じてさまざまなモデルを活用できる現在、基盤としてのAzureを活かしつつ、特定の作業に最適なAIを選べる環境が整いつつある。Microsoft基盤を捨てる必要はない——その上で動かすAIを最適化する発想が現実的だ。 筆者の見解 「AIを使えばモダナイゼーションが楽になる」という空気が業界全体に漂っているが、このドキュメントはその幻想に冷水を浴びせる内容だ。率直に言って、こういう「実際はこれだけ大変なんですよ」という記事をMicrosoftが出すこと自体は評価したい。 ただ、日本のIT現場においては、そもそも「モダナイゼーションに着手できる状態」にすら到達していない組織が多い。ドキュメントが欠如し、担当者が退職し、システムの全体像を知っている人間が誰もいない——そういう状態で「AIエージェントを活用しましょう」と言っても、AIは解析する材料すら与えられない。 本質的な問題は、AIの使い方ではなく、長年にわたって技術的負債の可視化を怠ってきたことだ。レガシーシステムの価値と複雑さを正直に計測し、リアーキテクチャかマイグレーションかを判断する。そこにこそAIエージェントの本来の価値がある。「変換」ではなく「把握」のためにAIを使う、という順序を間違えないようにしたい。 標準的な構成を選び、ベンダー推奨の理由を理解し、自分の環境で検証してから判断する——この「道のド真ん中を歩く」姿勢が、AIの時代においても変わらず重要だと改めて感じさせられる内容だった。 出典: この記事は The Realities of Application Modernization with Agentic AI (Early 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIがインフラの自律運用を担う時代が、コスト面でも現実的な選択肢になってきた。Microsoftは2026年4月15日、Azure SRE Agentの新しい課金モデルを正式に適用開始した。アクティブフロー100万トークンあたりのAAU（Azure Agent Unit）消費量をベースにした従量課金制で、企業がAIエージェントに自律的なサイト信頼性エンジニアリング（SRE）を任せる際のコスト予測が格段に立てやすくなった。 Azure SRE Agentとは何か Azure SRE Agentは、障害検知・根本原因分析・自動回復といったSREの定型業務をAIエージェントが自律的に実行するサービスだ。従来、オンコール担当者が深夜に対応していたような作業の一部を、人間の介入なしに処理できる。アラート→診断→修復のサイクルを24時間稼働のNHI（Non-Human Identity）として回し続けるイメージに近い。 新課金モデルの仕組み 今回の変更の核心は「予測可能性」だ。AAUという単位は、エージェントが処理する「アクティブフロー」のトークン量に比例して消費される。これにより： 使った分だけ払う明確な従量課金 トークン消費量からコストの事前試算が可能 月額固定モデルにありがちな「使い切れない枠」「超過請求」の両方を回避 企業のFinOps担当者にとって、AIエージェントのコストをAzure Cost Managementで他のリソースと同じ粒度で管理できる点は大きい。 実務への影響 IT運用チームへの直接的な影響として、まず考えるべきは「何を任せて何を人間が持つか」の線引きだ。Azure SRE Agentが得意とするのは、手順が明確に定義できる繰り返し対応タスク。具体的には以下のような領域が現実的な導入候補になる： 既知の障害パターンへの自動対応（再起動・スケールアウト・フェイルオーバー） 異常検知後の一次トリアージと担当者へのエスカレーション 定期的なヘルスチェックと結果のレポーティング AAUベースの課金であれば、まず低頻度の自動対応タスクから試験導入し、効果とコストを測定しながら段階的に範囲を広げる「道のド真ん中」アプローチが取りやすい。いきなり全自動化を狙わず、人間の承認ステップを残しながら徐々に委譲範囲を広げることで、リスクを最小化しながら実績を積める。 Microsoft Entra IDとの統合も見逃せない。SREエージェントはNHIとして動作するため、誰がどのリソースにアクセスできるかの管理はEntra IDで統一できる。Just-In-Timeアクセスや条件付きアクセスポリシーをそのままエージェントにも適用できる設計になっており、セキュリティポリシーの適用漏れが起きにくい。 筆者の見解 「仕組みを回すのはAI、作るのは人間」という流れが着実に加速している。Azure SRE Agentのような自律エージェントは、その象徴的な存在だ。今回の課金モデル変更は地味に見えて、実は本番導入における最後のハードルの一つを取り除く意味を持つ。コストが予測できなければ、企業のシステム部門は稟議を通せない。それが通るようになるということは、今後12〜18ヶ月で導入事例が急増することを意味する。 「でも結局、障害の80%はAIが処理して、残り20%の複雑な問題だけ人間が対応する」という世界が現実になりつつある。それは決して悪い話ではなく、SREエンジニアが本当に難しい問題だけに集中できる環境が整うということだ。NHIとしてのエージェント管理を今から設計しておくことが、来たるべき「人間が必要な局面だけに集中する運用モデル」への準備になる。 Azureのプラットフォームとしての強みは、こういうエージェント基盤の整備にある。ここは正直に評価できる部分だ。自律SREはまだ発展途上だが、コスト構造が整ったことで「試せる企業」の裾野が広がる。まずは小さく始めて、実際の効果を測定することをお勧めする。 出典: この記事は Announcing a flexible, predictable billing model for Azure SRE Agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Exchange Online を使い続けているすべての組織に関係する話だ。Microsoft が Exchange Web Services（EWS）の完全廃止スケジュールを正式に発表し、カウントダウンが始まった。2027年5月の最終撤廃に向けて、2026年10月という「最初の壁」が迫っている。バックアップ製品、メールボックス移行ツール、社内開発のスクリプト——EWS に依存した仕組みを持つ組織は、今すぐ棚卸しを始める必要がある。 EWS とは何か、なぜ今廃止されるのか Exchange Web Services は約20年前に設計されたプロトコルだ。当時はオンプレミスの Exchange サーバーが主流で、ISV やサードパーティ開発者がメールボックスにアクセスする手段として事実上の標準となった。バックアップ製品、メールボックスのインポート・エクスポートユーティリティ、監査ツール——ありとあらゆる用途に EWS が使われてきた歴史がある。 しかし、クラウド時代のセキュリティ要件と照らし合わせると、EWS は設計思想そのものが古すぎる。Microsoft Graph API という現代的な代替手段が整備された今、20年前のプロトコルをクラウドサービスで維持し続けるコストとリスクは正当化できない、というのが Microsoft の判断だ。 廃止タイムライン：3つのフェーズを把握せよ 廃止は段階的に進む。整理すると以下のとおりだ。 2026年10月：EWS の無効化開始 テナントの EWSEnabled プロパティが True から False に変更され、EWS によるアクセスがブロックされる。ただしこのフェーズでは、管理者が設定を Null（デフォルト）または True に戻すことで EWS を再び有効化できる。完全に手を縛られるわけではない。 2027年4月1日：永続的な無効化の開始 この日から EWS の恒久的な無効化プロセスが始まる。数十万台に上る Exchange Online メールボックスサーバー全体への設定反映には時間がかかるため、プロセス自体は数週間かかる見込みだ。「4月1日以降は EWS が使えると思わないこと」と Microsoft は明言している。 2027年5月：完全撤廃完了 すべての Exchange Online サーバーから EWS が削除される。ここがゴールだ。 アローリストと EWSApplicationAccessPolicy の関係 2026年10月の無効化フェーズ前に、Microsoft は各テナントで実際に EWS を使っているアプリを観測してアローリスト（許可リスト）を自動生成する予定だ。このアローリストは既存の EWSApplicationAccessPolicy より優先される。 ...

MicrosoftはExchange Online PowerShellモジュールのConnect-ExchangeOnlineコマンドレットが持つCredentialパラメーターを、2026年6月に廃止することを発表した（MC1248389）。「また廃止か」と流し読みしてしまいそうな告知だが、バックグラウンドで動き続けている古いスクリプトを持つ組織にとっては見逃せない変更だ。 Credentialパラメーターとは何だったのか Credentialパラメーターはユーザー名とパスワードを格納したPSCredentialオブジェクトを受け取り、ROPC（Resource Owner Password Credentials）と呼ばれる認証フローでExchange Onlineに接続する仕組みだ。ROPCはOAuthの仕様上は存在するが、多要素認証（MFA）に対応していない。要するに「ユーザー名＋パスワードだけで認証する、昔ながらのやり方」をそのままスクリプトに持ち込んだ形態である。 MicrosoftのEntra IDトークン取得ライブラリであるMSAL（Microsoft Authentication Library）がすでにROPCのサポートを非推奨とした以上、それに依存するExchange Online PowerShellモジュールが追従するのは自然な流れだ。 どこに影響が出るか 対話セッションには実質的な影響はない。 管理者アカウントにはすでにMFAが設定されているはずであり、そもそもCredentialパラメーターを使って手動でログインするケースは稀だろう。 問題はバックグラウンドジョブだ。具体的には次のようなケースが該当する。 Windowsタスクスケジューラーから起動するPowerShellスクリプト 数年前に書かれ、メンテナンスがほとんど行われていない自動化スクリプト サービスアカウントのユーザー名＋パスワードをスクリプト内や別ファイルに保持しているもの こうしたスクリプトは、6月以降にMicrosoft側のサーバーコンポーネントがROPC対応を終了した段階でサイレントに壊れる可能性がある。エラーが出るならまだいい。最悪なのは「実行されているように見えて、実際には接続に失敗してスキップされている」状態だ。 移行先：Azure AutomationとマネージドID 推奨される移行先はAzure Automationのマネージドアイデンティティ（Managed Identity）を使ったRunbookだ。 比較項目 Windowsタスクスケジューラー Azure Automation + Managed Identity 認証方式 ユーザー名＋パスワード（ROPC） マネージドID（証明書不要） MFA対応 非対応 対応 シークレット管理 スクリプト内に埋め込みがち 不要（IDベース） 実行ログ ローカルイベントログ Azure Monitorで一元管理 コスト 無料（ただしWindowsサーバーが必要） 月500分まで無料、超過分は$0.002/分 Azure Automationの無料枠（月500分）は、典型的なExchange Online管理タスクであれば十分すぎる量だ。「Azureサブスクリプションが必要」「設定が複雑」という声はよく聞くが、一度慣れてしまえばタスクスケジューラーには戻りたくなくなる。 実務への影響——今すぐやること ステップ1: スクリプトの棚卸し 出典: この記事は Exchange Online PowerShell Dumps the Credential Parameter の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365のエコシステムを支える根幹インフラであるMicrosoft Graph APIに対し、複数のMicrosoft MVPがフィードバックフォーラムで正式に問題提起した。単なる不満の声ではなく、「このままでは開発者が壊れる」という切実な訴えだ。 Graph APIが抱える5つの構造問題 1. カバレッジの欠落と一貫性のなさ Microsoft Graphは当初「M365のあらゆるデータに一貫したAPIで触れる」という約束のもと設計された。しかし現実は厳しい。Exchange Onlineはメールボックス作成にGraph APIがなく、未だにPowerShell頼み。SharePoint OnlineのGraph APIは2022年に登場したが、それ以降ほとんど進化していない。TeamsのポリシーはSkype for Business時代の枠組みを引きずったままで、Graph APIが存在しない領域が多い。 2. 未ドキュメントAPIの横行 管理ポータルの裏側では、PowerShellにもGraphにも公開されていないAPIが静かに動いている。Microsoft XDRなどの重要ソリューションにはインターフェース自体が存在しない。エンジニアリングチームが「作り中」であることは理解できるが、主要な管理ポータルが未公開APIに依存したまま運用され続けているのは問題だ。 3. ベータAPIの「永久ベータ」化 AuditLogQuery APIはその象徴だ。Purviewの監査検索で実際に使われている非同期APIが、長期にわたってベータのままだ。テナント側はベータAPIを本番運用に組み込むことを避けたい。「いつ仕様が変わるかわからない」リスクを抱えながら開発することは非常に困難で、プロダクション昇格の見通しも示されていない。 4. PowerShell SDKのリソース不足 Microsoft Graph PowerShell SDKは新バージョンのたびに70万件以上ダウンロードされるほど利用されている。それでもSDKを担当するチームは極めて小規模で、報告されたバグが長期間放置されることが常態化している。需要と投資のアンバランスは明らかだ。 5. アセンブリ競合という開発者への嫌がらせ Exchange Online PowerShellモジュールとGraph PowerShell SDKを同一セッションでロードしようとすると、順番によってクラッシュする。「Exchange → Graph」はOKだが「Graph → Exchange」は失敗する。自動化スクリプトを書いている人間にとって、これは単純に業務を止める問題だ。 なぜこれが重要か Graph APIの整備不足は、単なる開発体験の問題ではない。自動化・ガバナンス・セキュリティ運用のすべてがAPIの質に直結する。Non-Human Identity（NHI）を活用した業務自動化を進めようとしても、APIが不完全では自動化できない領域が残り続ける。結局「人間が手でやる」フローが温存される。これは効率化の根幹に影響する話だ。 実務での活用ポイント ベータAPIの利用判断: 本番システムへのベータAPI組み込みは、プロダクション昇格のロードマップが明示されているものに限定する。Microsoftの公式フィードバックフォーラムでステータスを定期的に確認する習慣を PowerShell SDKのバージョン管理: アセンブリ競合を避けるため、Exchange Online管理スクリプトとGraph SDKを使うスクリプトは別セッション・別スクリプトとして明確に分離する Entra ID + Graph を組み合わせた自動化設計: APIが存在する領域は積極的にGraph経由で実装し、存在しない領域はPowerShell + マネージドIDの組み合わせで補完する設計を標準化しておく MVPフォーラムのモニタリング: 今回のような提言はMicrosoft Feedback Forumに公開されている。MS製品の動向を追う上でエンジニアブログ以上に生の情報が集まる場所なので、定期的に目を通すと良い 筆者の見解 Microsoftが「GraphはM365外部アクセスの標準ルート」と掲げながら、その整備に十分なリソースを割かないのは、正直もったいないと思う。Graphは単なるAPIではなく、自動化・セキュリティ・ガバナンスを束ねるプラットフォームの土台だ。ここが脆弱なままでは、いくら上のレイヤーで高度な機能を打ち出しても、運用現場での信頼は積み上がらない。 ...

Microsoft 365 の標準タスク管理ツール「Planner」に、AIエージェント機能が本格的に統合された。2026年3月、「Project Manager agent」として一部ユーザーに限定提供されていた機能が「Planner agent」と改称され、Microsoft 365 Copilot ライセンスを持つユーザーなら Planner の基本プランでも利用できるようになった。早ければ2026年5月初旬に一般提供（GA）が完了する見込みだ。 Planner Agent とは何か Planner Agent の役割は、タスクの「実行方法を提案する」ことだ。ユーザーは通常通りタスクを作成し、そこに Planner Agent をアサインするだけでよい。エージェントはバックグラウンドでタスクの詳細情報を解析し、数分後に「このタスクをどう進めるか」のステップバイステップな提案を生成して返す。 提案内容は Microsoft Loop コンポーネントとして格納される。これにより、プランのメンバー全員がリアルタイムで同時編集できる。Teams アプリまたはブラウザクライアントから確認・修正が可能で（現時点でモバイルクライアントは非対応）、情報が不十分だと感じたら何度でも再生成をリクエストできる。 処理の流れは以下のように進む: Queued（待機中） → タスクを AI 処理キューに投入 In Progress（処理中） → バックグラウンドで分析・提案生成 Ready（完了） → 担当者にメール通知＆Loop コンポーネントに提案が表示 タスクに付随する Task Chat 機能を使えば、生成された提案をチームで議論しながら精度を高めることもできる。 ライセンス変更の実務インパクト 今回の変更で重要なのは「ライセンス要件の緩和」だ。従来は Planner Premium（Project Plan 相当）が必要だったが、M365 Copilot ライセンスさえあれば Planner Basic でも利用可能になった。 日本企業では Planner を Teams と組み合わせて軽量なタスク管理として使っているケースが多い。Premium を契約せず Basic のまま運用している組織でも、M365 Copilot ライセンスを持つユーザーに AI 支援が届くようになったのは、実務上のインパクトが小さくない。 IT 管理者が確認すべきポイント: テナントのロールアウト状況を確認する: ターゲット リリーステナントでは 2026年3月末に展開済み。標準テナントは 5月初旬を目安に確認を Planner Agent の利用状況はアクティビティ タブで可視化: プランメンバー全員が AI 提案を参照できる設計なのでガバナンス上も把握しやすい Loop との連携を理解しておく: 提案は Loop コンポーネントとして保存される。Loop のアクセス権設定が Planner Agent の利用体験に影響する点に注意 実務での活用ポイント Planner Agent を有効活用するカギは「タスクの記述品質を上げること」に尽きる。「〇〇を対応する」のような曖昧な記述では、エージェントが生成できる提案も当然ぼんやりしたものになる。 ...

Googleが長年ユーザーから要望の多かった縦型タブ（Vertical Tabs）と、より賢くなったリーディングモードをChromeに実装することを発表した。一見地味なUI改善に見えるが、情報収集を日常的に行うエンジニアやIT管理者にとっては、作業効率を左右する実質的なアップデートだ。 縦型タブとは何か 従来のブラウザタブは画面上部に横並びで表示される。タブを大量に開くと、各タブのタイトルがほぼ見えなくなるという問題は、多くのヘビーユーザーが日々直面している現実だ。 縦型タブは、タブ一覧をサイドバーとして縦に並べる方式に切り替える。これにより： タイトルの視認性が飛躍的に向上：横に並べると潰れてしまうタイトルが、縦配置なら十分な幅で表示できる タブの整理・把握がしやすくなる：グループ化や折りたたみも行いやすく、タブ管理が格段に改善する ワイドスクリーンとの相性が良い：横幅の広いモニターでは、縦方向のサイドバーにタブを逃がすことでコンテンツ表示領域を有効活用できる スマートリーディングモードの進化 リーディングモードは、Webページから広告やナビゲーションなどの「ノイズ」を取り除き、本文だけをすっきりとした形式で表示する機能だ。今回の「スマート」版では、AIを活用してコンテンツの主要部分をより精度高く抽出し、長文記事や技術ドキュメントの可読性をさらに高める方向で改善が加えられているとされている。 特にエンジニアが英語の技術記事やドキュメントを読む場面では、余計なサイドバーやポップアップが消えるだけで集中力の維持に大きく貢献する。 実務への影響——日本のエンジニア・IT管理者にとっての意味 タブ管理の見直し 日常的に調査や情報収集を行うエンジニアは、気づけば30〜50タブを開いた状態になることも珍しくない。縦型タブへの切り替えは、そのカオスを整理する一手になりうる。特にデュアルモニター環境や大型ディスプレイを使っているなら、縦型タブの恩恵を受けやすい。 リーディングモードの業務活用 技術ドキュメントや英語記事を読む際に積極的に活用したい。翻訳ツールとの組み合わせも相性が良く、本文だけを抽出してから翻訳にかけると精度と可読性が上がるケースがある。 組織内のブラウザ管理 法人でChromeを管理している場合、新UIの展開タイミングや企業ポリシーへの影響を事前に確認しておくと安心だ。特にChrome Enterprise環境では、機能フラグや管理コンソールの設定で展開を制御できる場合がある。 筆者の見解 正直に言えば、縦型タブはすでに数年前から他のブラウザで実装済みの機能だ。ヘビーユーザーの間では「なぜChromeにはないのか」という声が長く続いていた。ようやく追いついてきたという印象は否めない。 とはいえ、Chromeのシェアを考えれば、この機能が「世界規模で当たり前になる」という意味合いは小さくない。縦型タブが普及することで、より多くの人がタブ管理に意識を向けるようになれば、情報整理の文化そのものが底上げされる可能性がある。 リーディングモードの強化は、AIを「派手な会話UI」としてではなく「黒子として情報品質を高める」方向に使うという点で、筆者は好意的に見ている。これは「道のド真ん中」のAI活用であり、ユーザーが意識せずに恩恵を受けられる形だ。こういうアプローチこそが、AIの実質的な普及を進める。 ブラウザ選択はあくまでユーザーの自由だが、今回のアップデートを機に「自分はどのブラウザのどの機能を本当に使っているか」を一度棚卸しする良いタイミングかもしれない。どのブラウザを選ぶにしても、意図された使い方をきちんと理解して使うことが、結局は一番効率の良い選択につながる。 出典: この記事は Chrome finally gets vertical tabs and a smarter reading mode の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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