Tech News JP

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

学術論文の執筆は、AIがもっとも「代替しにくい」とされてきた知的作業のひとつだ。文献の網羅的調査、引用の正確性確保、論理的一貫性のチェック——こうした工程は時間と専門知識の双方を要求し、多くの研究者が「もっとも消耗する」部分として挙げる。そこに、13のAIエージェントが連携して研究の全工程を支援するプラグインが登場した。 Academic Research Skills（ARS）とは ARSは、AIコーディング支援プラットフォーム「Claude Code」向けのプラグインとして公開された学術研究支援スイートだ。論文の構成計画から文献レビュー、引用検証、スタイル調整、品質チェックまで、投稿直前までの全工程をカバーする。 インストールは30秒で完了し、/ars-planコマンドを実行すると、ソクラテス式の対話形式で論文の章立てを整理できる。文献レビューでは Semantic Scholar API を活用してリアルタイムに引用の実在性を検証する機能も搭載。筆者の過去論文を学習して文体を再現する「スタイルキャリブレーション」も備えており、15,000語の論文一本を仕上げるコストは4〜6ドル程度と試算されている。 設計哲学：「AIはコパイロット、パイロットではない」 このツールの最も重要な特徴は、その設計哲学にある。開発者は明確に「論文をAIに書かせるツールではない」と述べている。 AIが担うのは、文献の探索、引用フォーマット整形、データ検証、論理的一貫性のチェックといった「脳を酷使するが知的創造性は低い作業」だ。「何を問うか」「どの手法を選ぶか」「データが何を意味するか」「I argue that の後を書く」——これらは人間が担当する領域として明確に区別されている。 この姿勢の背景には、Nature誌掲載のLuら（2026年）の研究がある。完全自律型のAI研究システム「The AI Scientist」がトップMLカンファレンスのワークショップで査読を通過したという成果は確かに画期的だ。しかし同論文の「Limitations」セクションでは自律化の落とし穴も正直に列挙されている——実装バグ、結果のハルシネーション、バグを「洞察」として再解釈するframe-lock、引用ハルシネーション。完全自動化は現段階では品質保証の穴が多すぎる。 ARSはこの教訓から「人間研究者＋AI」の組み合わせがどちら単体よりも失敗率が低いと判断し、各ステージに「整合性ゲート」を設けている。7モードのブロッキングチェックリストが自動で走り、偽陰性率・偽陽性率すら計測できるキャリブレーションモードも持つ。 実務への影響 日本の研究環境でも、この種のツールが与えるインパクトは小さくない。 大学・研究機関の研究者にとっては、文献調査の時間短縮が直接的なメリットだ。特に分野横断的な研究や系統的レビュー（PRISMA）が求められる場合、人手による網羅性の確保は困難を極める。13エージェントの協調動作は、こうした横断的調査を自動化しながら人間が最終判断を下すフローを整備する。 企業のR&D部門においても、技術報告書や特許調査の初稿作成にこのアプローチは応用できる。スタイルキャリブレーションは社内文書の文体統一にも転用可能だろう。 一方、研究倫理の観点では注意が必要だ。ARSは「AIを使ったことを隠すツールではない」と明言しているが、各機関の規定との整合性確認は利用者の責任となる。特に投稿先ジャーナルのAI利用ポリシーは2024〜2026年にかけて急速に整備されており、事前確認は必須だ。 筆者の見解 自律型AIと人間の役割分担の議論は、学術研究の世界でも本格化してきた。注目すべきは、ARSの設計者が「完全自動化の失敗リスト」を正面から引用して、あえてそこを攻略しないと決断した点だ。これは技術的な限界の受け入れではなく、現時点でのベストな設計判断だと思う。 AIエージェントが自律的にループし続けて仕事を完遂する設計は、確かに魅力的だ。しかし学術研究のように、誤った前提が論文全体を崩壊させるようなドメインでは、各ステージに人間の判断ポイントを挟む設計の方が現実的に機能する。ハルシネーションひとつで査読却下になるリスクを考えれば、「任せきり」より「任せつつ確認する」設計が理にかなっている。 どの分野のワークフローにAIを組み込む際も、「自動化する部分」と「人間が判断する部分」の境界線設計こそが、ツールの成否を分ける。ARSはその設計の模範例として、研究者以外のエンジニアにとっても参考になる一作だ。 出典: この記事は Academic Research Skills for Claude Code の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2024年末、ドイツ史上最大規模のサイバー犯罪マーケットプレイス「Crimenetwork」が当局に摘発された。ところがその数日後、新たな管理者が同名の新インフラを立ち上げ復活。しかし今回、法執行機関の対応は以前より格段に速かった。この事案は、ダークウェブ犯罪インフラの「不死性」と、それに対抗する国際連携の進化を同時に示す好例だ。 Crimenetworkとはどんな存在だったか 2012年から運営されていたCrimenetworkは、登録ユーザー10万人を抱えるドイツ最大のオンライン犯罪市場だった。不正アクセスツール、盗まれた認証情報、各種違法物質、フィッシングサービスなど、サイバー犯罪に必要な「素材」がワンストップで揃う闇のマーケットとして機能していた。 2024年12月、フランクフルト検察庁、サイバー犯罪対策中央局（ZIT）、連邦刑事警察局（BKA）の合同作戦によってプラットフォームが押収され、管理者の一人が逮捕。2026年3月には元の運営者に懲役7年10カ月と1000万ユーロ超の没収命令が下された（未確定）。 驚異の「数日リブート」と即時再摘発 問題はその後だ。旧版の摘発から「数日」というあり得ないスピードで、別の人物が新しいインフラを構築し、同じ名称で再出発した。新版は短期間で22,000人のユーザーと100社以上のベンダーを獲得し、少なくとも360万ユーロ（約6億円）の収益を上げたとされる。 今回の再摘発では、欧州逮捕状（European Arrest Warrant）が活用され、スペイン・マヨルカで35歳のドイツ人男性が特殊部隊によって身柄を確保された。押収資産は約19万4,000ユーロ（約3,200万円）。さらに大量のユーザーデータとトランザクション履歴が取得されており、この情報をもとにした連鎖的な捜査が進むとみられる。 なぜこれが重要か——「インフラ摘発」の限界と進化 犯罪マーケットプレイスは、本質的にソフトウェアとデータの組み合わせだ。物理的な拠点を必要としないため、サーバーを変えれば数日で復活できる。AlphaBay、Hansa、Hydraなど、歴代の大型摘発の後にも「後継」が現れてきた歴史がある。 一方で今回注目すべきは、法執行機関側の対応速度と国際連携の精度が明らかに向上している点だ。新版がわずか数カ月で解体されたのは、BKAが旧版から入手したデータと捜査ネットワークを即座に転用できたからだと考えられる。ダークウェブ上でも「前歴情報」は残る。 実務への影響——日本企業のデータは今も取引されている こうした市場の存在は、遠い海外の話ではない。 認証情報の流出確認を習慣化する: 日本企業の社員アカウントやVPN認証情報が、こうした市場で売買されているケースは珍しくない。Have I Been Pwned などのサービスや、セキュリティベンダーが提供するダークウェブモニタリング機能を活用し、自社ドメインの認証情報流出を定期的に確認することが基本的な衛生管理として機能する。 「摘発されれば安全」ではない: Crimenetworkの再起動が示すように、特定のマーケットが消えても代替はすぐ現れる。特定の脅威プラットフォームの消滅に安堵するのではなく、「盗まれた認証情報が流通することを前提とした」多層防御の設計が求められる。 NHI（Non-Human Identity）管理の重要性: サービスアカウント、APIキー、自動化スクリプトの認証情報も取引対象だ。これらは人間のアカウントより見落とされやすく、かつ検知が遅れる。NHIのライフサイクル管理と最小権限原則の徹底は、この種の脅威に対する実効性の高い対策となる。 Just-In-Timeアクセスの導入: 常時有効な特権アカウントは、流出した場合の被害が最大化する。アクセスを必要なときだけ付与し、使用後は自動的に失効させる仕組みが、盗まれた認証情報の悪用を大幅に抑止する。 筆者の見解 今回の事案で印象的なのは、犯罪側の「再起動速度」よりも、当局側が「次の管理者」に対しても即座に動けた点だ。旧版の摘発時に取得したデータと捜査基盤が、新バージョンへの対応をここまで加速させた。法執行機関のサイバー犯罪対応は、インフラ戦争としての性格を強めている。 もっとも、根本的な構造——犯罪サービスへの需要と、匿名インフラの低コスト構築可能性——は変わっていない。個別マーケットの摘発は必要だが、それだけで犯罪エコシステム全体を止めることはできない。 日本の企業セキュリティの観点では、「こういうマーケットが存在し、自社のデータが流通している可能性がある」という現実認識から出発することが大事だ。セキュリティを「禁止と制限」で固めるアプローチは限界があり、流出を前提とした検知・対応の仕組み作りにシフトする時機はとっくに来ている。ダークウェブの犯罪インフラが数日で再起動できるなら、こちらの検知・対応体制も同じ速度で機能しなければ意味がない。 出典: この記事は Police shut down reboot of Crimenetwork marketplace, arrest admin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google広告の「公式に見えるスポンサー枠」と、AIサービスの「共有チャット機能」という2つの信頼されたインフラを組み合わせた、新たなマルバタイジングキャンペーンが確認された。ターゲットはmacOSユーザー。「正規URLが表示されていれば安全」という直感がもはや機能しない現実を、あらためて突きつける事例だ。 攻撃の仕組み：2段階の「信頼の借用」 今回の攻撃は、セキュリティエンジニアのBerk Albayrak氏（Trendyol Group）が発見し、BleepingComputerが追跡・検証した。構造はシンプルだが、その巧妙さは際立っている。 第1段階：Google広告で入口を偽装する 「Claude mac download」などのキーワードを検索すると、スポンサー広告として正規のAIサービスドメインが表示される。しかしクリックすると、攻撃者が用意した共有チャットページへ誘導される。表示URLと遷移先が異なるという、マルバタイジングの古典的な手口だ。 第2段階：本物のプラットフォーム上に罠を仕掛ける 誘導先がフィッシングサイトではなく、正規のAIサービス上の「共有チャット」ページという点が今回の核心だ。攻撃者は「公式インストールガイド」を装ったチャットを作成・公開し、ユーザーにTerminalを開かせて悪意あるコマンドを貼り付けさせる。URLバーには本物のドメインが表示されているため、ブラウザの警告もユーザーの目視確認も機能しない。 マルウェアの動作：洗練された標的選別 実行されたシェルスクリプトは、単純な感染ツールではなく、かなり作り込まれた設計を持つ。 CIS地域の除外: キーボードロケールを確認し、ロシア語・CIS地域設定の場合は即座に終了（cis_blocked ステータスを静かに送信） 被害者プロファイリング: 外部IPアドレス、ホスト名、OSバージョン、キーボードロケールを収集して攻撃者サーバーへ送信 ポリモーフィック配信: リクエストごとに異なる難読化ペイロードを返し、ハッシュベースの検知を無効化 メモリ実行: スクリプトはメモリ上で動作し、ディスク痕跡を最小化 osascript 利用: macOS標準のスクリプトエンジンを経由してリモートコード実行を実現 最終的な目的は MacSync インフォスティーラー の実行であり、ブラウザの認証情報・Cookie・macOSキーチェーンの内容が外部へ持ち出される。 実務への影響 IT管理者が取るべき対策 企業内でMacを使う社員が「業務ツールをGoogle検索でダウンロードする」という行動パターンは日常的だ。今回の攻撃は公式ドメインの表示と正規プラットフォームの信頼を二重に利用しており、ユーザー教育だけでは限界がある。以下を組み合わせた多層防御が現実解だ。 MDMによるエンドポイント管理: 管理外アプリのインストールを制限し、Terminalの使用ポリシーを整備する GateKeeper・Notarizationの確認: macOS標準のセキュリティポリシーが正しく機能しているか定期確認を DNSフィルタリング: 既知の不審ドメインへの通信をネットワーク層でブロック EDRの振る舞い検知: シグネチャベースでは検知できないポリモーフィック型には、振る舞い検知が有効 エンジニアが持つべき習慣 「ドキュメントに書いてあるコマンドをTerminalに貼り付ける」という行為そのものが攻撃ベクターになりえる時代だ。特に以下のパターンは立ち止まって確認したい。 curl | bash 形式のワンライナー Base64エンコードされたコマンド 見慣れないドメインへのアクセスを含むスクリプト 筆者の見解 この攻撃の完成度には正直、舌を巻く。自前でフィッシングサイトを用意するのではなく、信頼されたプラットフォームの正規機能を踏み台にするという発想は、現代のゼロトラスト的思考と皮肉にも呼応している——悪い意味で。 「URLが本物ならば安全」という直感は今やほとんど機能しない。ネットワーク層やURL評価だけでなく、コマンドの内容そのものを検証する層が必要な時代に入っている。ゼロトラストの本質は「何も信頼しない」ではなく「すべてを継続的に検証する」ことだが、今回の事例はその原則をエンドユーザーの操作レベルにまで適用しなければならないことを示している。 macOSは「Windowsより安全」というイメージが根強いが、インフォスティーラーをはじめとするMac向けマルウェアの洗練度は近年急速に上がっている。日本のIT現場でもMacの業務利用が増えている中、「Macだから大丈夫」という油断は禁物だ。 AIツールが急速に普及し、「AIサービスのインストール方法を検索する」という行動パターン自体が攻撃者に狙われるようになった。新しいツールが登場するたびに、攻撃者もその普及曲線に乗って仕掛けてくる。インフラ面の対策を進めながら、地道にユーザー啓発も続けていく——それが現時点での現実的な答えだ。「今動いているから大丈夫」が通用しないのは、セキュリティの世界では昔から変わらない真実である。 出典: この記事は Hackers abuse Google ads, Claude.ai chats to push Mac malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Copilot+ PCという規格が登場して以来、「本当にAI処理性能が変わるのか」と疑問を持ってきたエンジニアは多いはずだ。GEEKOMが2026年版としてアップデートしたミニPC「A9 Max 2026 Edition」は、そんな懐疑派をも振り向かせる可能性を秘めた製品だ。86 TOPS（毎秒兆回演算）というNPU性能を、ペットボトルほどのサイズに詰め込んだ。 Copilot+ PCとは何か——40 TOPSの壁を大きく超えた Microsoftが定めたCopilot+ PC認定の最低要件はNPU性能40 TOPSだ。GEEKOM A9 Max 2026 Editionはその倍以上となる86 TOPSを達成している。搭載するのはAMDのRyzen AIプロセッサーで、CPUとGPU、そして専用NPUが統合されたSoC（System on Chip）構成だ。 NPUがなぜ重要か。従来のAI処理はCPUかGPUに頼っていたが、専用回路であるNPUは電力効率が桁違いによい。バッテリー駆動のノートPCでAI機能を常時使っても熱暴走しないのはNPUの恩恵だ。ミニPCの場合は熱設計の余裕が大きいとはいえ、専用NPUによる処理オフロードはファン回転数の抑制にも寄与する。 Red Dot受賞の「デザイン」——機能美か、それとも飾りか 本機はRed Dot Design Award 2026を受賞している。ミニPCにデザイン賞が与えられることは珍しくないが、実際のところ業務用途では「ディスプレイの裏にマウントして見えなくなる」ケースが大半だ。ただ、Red Dot受賞が示すのは見た目の美しさだけではない。放熱設計・ポート配置・組み立て精度といった工業設計全体の評価でもある。この点は実用性に直結する。 ポート構成は現代の業務要件を満たす水準で、USB4対応のType-Cポートが含まれているため、Thunderbolt対応の外部ディスプレイや高速ストレージとの接続も問題ない。 実務での活用ポイント ① 小規模拠点・工場・受付端末としての採用 ミニPCの最大の強みはTCO（総所有コスト）の低さではなく、設置自由度にある。スペースの限られた工場の制御盤近くや、ホテルのフロントカウンター下、会議室のディスプレイ背面といった場所に収まる。Copilot+ PC要件を満たしているため、Windows 11の「Recall」「Cocreator」といったAI機能を将来的にフルで使える下地がある。 ② 開発・検証用マシンとしての価値 ローカルLLM（小規模言語モデル）の推論をNPUにオフロードして試験する用途に適している。86 TOPSあれば、Microsoft Phi-4のような比較的軽量なモデルをそこそこのスピードで動かせる。クラウドAPIのコスト検証の前段階として、ローカルで動作確認する開発フローとの相性がよい。 ③ IT管理者視点：展開・管理の標準化 WindowsのAutopilot展開と組み合わせれば、初期セットアップをほぼゼロタッチで完結できる。同一型番で統一すればドライバー管理が簡単になる。中小企業のPC調達でCopilot+ PC認定済みの選択肢が増えることは、将来のAI機能導入に向けたハードウェア基盤整備として評価できる。 筆者の見解 Copilot+ PCという規格そのものは正しい方向だと思っている。「AI機能のためにハードウェア要件を明確に定義する」アプローチは、ユーザーが「どれを買えばいいか分からない」問題を解消する手立てになる。かつてIntel「Evo」の認定プログラムが薄型軽量ノートの品質底上げに貢献したのと同じ役割を、Copilot+はAI PCで担おうとしている。 ただし率直に言えば、現時点でCopilot+ PCの「AI機能」がエンドユーザーの日常業務を劇的に変えている場面には、まだほとんど出会えていない。Recallは段階的な展開が続いており、多くのユーザーには「NPUが速い」と言われてもピンとこないのが実情だ。 GEEKOM A9 Max 2026 Editionの86 TOPSは、その意味でスペックシート上の数字として終わらせてしまうにはもったいない。Microsoftが本来やろうとしていた「ローカルAI処理で常時稼働するパーソナルアシスタント」が現実になったとき、このクラスのハードウェアが真価を発揮する。 ミニPCという形態は、日本の「スペースファースト」な職場環境に特に向いている。物理的に小さいことへの評価が他国より高い市場で、Copilot+ 認定のミニPCが選択肢として増えてきたこと自体は歓迎したい。問題はハードウェアではなく、そのスペックを活かすソフトウェアとサービスが追いついてくるかだ。そこに期待しながら、引き続き注目していきたい。 出典: この記事は GEEKOM A9 Max 2026 Edition review: a tiny but powerful AI Mini PC with 86 TOPS の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

The Vergeのエマ・ロス記者が2026年5月10日に報じたところによると、ニュースレタープラットフォームの草分けである「Substack」から、GhostやBeehiivといった新興プラットフォームへのクリエイター移行が新たな局面を迎えている。かつては独立系ライターの登竜門として脚光を浴びたSubstackだが、その収益モデルへの不満が蓄積し、有力パブリケーションが相次いでプラットフォームを離れている。 「Substack税」とは何か——10%課金が重くのしかかる構造 Substackのビジネスモデルは、クリエイターの有料購読収益から10%を徴収するというシンプルなものだ。小規模なうちはさほど問題にならないが、購読者数が増えて月額収益が膨らむほど、この10%が経営を圧迫する「税」として機能し始める。 NBA専門パブリケーション「The Rose Garden Report」を運営するショーン・ハイキン氏がThe Vergeに語ったところによると、昨年4月にSubstackからGhost（＋アドオンのOutpost）へ移行した結果、年間費用が4,968ドルから2,052ドルへと約58%削減された。さらに購読者数は2024年末比で22%増を達成している。ハイキン氏は「招聘した新規タレントとして取り上げてもらえる間は成長できたが、その期間が終わると完全に放置された」と、Substackのプロモーション構造への不満も率直に語っている。 大学スポーツ専門ニュースレター「Extra Points」（購読者71,000人）を運営するマット・ブラウン氏は2021年にSubstackを去り、現在はBeehiivを利用。Beehiivでの年間費用は約3,000ドルだが、「今の規模のままSubstackにいたら年間25,000ドル以上を支払っていたはず」と語り、8倍以上のコスト格差が生じていたと指摘する。 移行先プラットフォームの実態——Ghost、Beehiiv、Passportとは The Vergeのレポートによれば、クリエイターの移行先として名前が挙がっているのは主に以下の3つだ。 GhostはオープンソースのCMSで、自己ホスティングも可能なセルフサービス型。収益の何割かを徴収するモデルではなく、月額・年額の固定料金体系を採用している。規模が大きくなるほどコスト優位が鮮明になる。 Beehiivはニュースレター特化の新興プラットフォームで、広告ネットワーク機能を内包するのが特徴。固定料金モデルにより、大規模パブリケーションほどSubstackとの差が開く。 エンタメ業界パブリケーション「The Ankler」はSubstackを離れ、WordPressを運営するAutomatticとStratecheryのベン・トンプソン氏が共同開発した新プラットフォーム「Passport」へ移行した。「ニュースレターを超えた統合メディア企業への転換を象徴する決断」とJanice MinおよびRichard Rushfieldの両氏はブログで説明している。 The Vergeはさらに、「Culture Study」のアン・ヘレン・ピーターセン氏がPatreonへ移行し「段階的にenshittification（サービスの質的劣化）が進んだプラットフォームには居たくなかった」と発言したことを伝えており、The BulwarkやMehdi HasanのZeteo、Emily SundbergのFeed Meも移行を「静かに検討している」と報じている。 日本市場での注目点 日本ではnote.comが独立系クリエイターの有料購読プラットフォームとして広く定着しており、Substackと類似した手数料モデルを採用している。Ghost・Beehiivの国内認知度はまだ低いが、英語圏向けニュースレターを運営する日本人クリエイターや、規模が拡大してきたコンテンツビジネスを展開するライターにとっては、コスト構造の見直し候補として検討する価値がある。 Ghostは日本語コンテンツにも対応しており、独自ドメインでの運営が可能な点も魅力だ。一方で、Substackが持つディスカバリー（新規読者獲得）機能は移行先では弱まるため、既存の読者基盤がある程度確立してからの移行が現実的と言えるだろう。 筆者の見解 プラットフォームが「仲介者として価値を提供する段階」から「コストとしてのしかかる段階」へと転じるのは、多くのSaaSサービスで繰り返されてきたパターンだ。Substackは創業初期の「スター発掘・育成」機能で差別化していたが、クリエイターのプラットフォーム依存が薄れるとたんに課金モデルが重荷へ変わる——という構造的な問題を最初から内包していた。 インフラ選定の文脈で言えば、「フルマネージドサービスで立ち上げ、スケールしたらコスト構造をコントロールできる環境へ移行する」判断と本質的に同じ構造だ。規模が大きくなるほど固定費型プラットフォームへ移行する経済合理性は明確になる。Substackのネットワーク効果を享受しながら成長し、閾値を超えたら自社ドメインとコスト構造を自分でコントロールする——これは合理的な判断の積み重ねと見るべきだろう。 コンテンツクリエイターにとって真に価値ある資産は、プラットフォームへの従属ではなく読者との直接関係だ。プラットフォームは変わる。メールアドレスのリストは自分のものであり続ける。今回の移行ラッシュは、その原則を再確認させる動きでもある。 出典: この記事は Writers are fleeing the Substack Tax の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが2026年5月10日に報じたところによると、Appleの次期macOS 27では新デザイン言語「Liquid Glass」の「slight redesign（小規模な再設計）」が予定されているという。情報源はBloombergのMark Gurman記者で、一部にあった完全撤廃を求める声をよそに、AppleはLiquid Glassを維持しつつ改良を加える方針であることが明らかになった。正式発表はWWDC 2026（6月8日開幕）で行われる見通しだ。 なぜこの動きが注目されるか Liquid GlassはAppleが2025年に導入した大規模なUI刷新で、ガラス様の透過表現を全面採用した意欲的なデザイン言語だった。しかしリリース後からテキストの可読性低下、アプリ間の見た目の一貫性のなさ、デスクトップやノートPCの大画面への不自然な適用といった問題が相次いで報告されている。 Gurman氏がEngadget経由で伝えた核心的な指摘は、「Liquid GlassはOLEDディスプレイを念頭に設計された」という点だ。iPhoneの有機ELパネルでは美しく表現できる透過エフェクトが、現行のMacに多いLCDパネル上では意図しないシャドウや透明度の問題として現れてしまっている——これが根本的な原因だという。 Gurman報道の主なポイント Engadgetが伝えたGurman氏の報告によると、macOS 27での変更は以下を中心に行われる予定だ。 シャドウと透明度の問題を修正: LCDパネル環境での表示崩れに直接対処 文字可読性の向上: リストや文字量の多い画面でのLiquid Glass表現を調整 デザインチームの当初意図に近い仕上がりへ: Gurman氏は「Appleのデザインチームが最初から意図していた外観を実現するもの」と説明しており、現行の問題は「ソフトウェアエンジニアリングチームの実装が完全に仕上がっていなかったことが原因」と位置づけている なお先行する形で、iOS 26.1・iPadOS 26.1・macOS 26.1では既にインターフェースをより不透明にする「フロスト」オプションが追加されており、今回のmacOS 27での改良はその延長線上にある取り組みとなる。 ハードウェア面では、今年中に登場が期待されるOLEDタッチスクリーン搭載MacBookが実現すれば、Liquid GlassはOLEDのメリットを活かした「本来の姿」で表示されるとも伝えられている。 日本市場での注目点 macOS 27の正式発表はWWDC 2026（6月8日）で行われる見通しで、日本でも同時期に詳細が明らかになるはずだ。現行macOS 26でLiquid Glassの視認性に不満を感じているユーザーは、このアップデートを待つ価値がある。 OLEDタッチスクリーン搭載MacBookについては、日本での発売時期や価格は現時点で未公開だが、実現すればMacのUI体験が根本から変わる可能性がある。注意しておきたいのは、LCDモデルを使い続けるユーザーとOLEDモデルに移行するユーザーとでは、同じmacOSでも視覚体験が大きく異なるという新たな状況が生まれる点だ。Liquid Glassの「完成形」をフルに享受するには、ハードウェアの世代交代も視野に入れておく必要があるかもしれない。 筆者の見解 Liquid Glassをめぐる一連の流れは、ソフトウェアと対応ハードウェアの整合性がいかに重要かを示す典型例だ。OLED前提で設計されたUIをLCDが主力のプラットフォームに投入した結果、意図していなかった見た目の問題が生じた——この事実をApple自身が「実装が完全に仕上がっていなかった」という形で事実上認めていることは、素直に受け止めるべき情報だ。 Gurman氏の「デザインチームが本来意図していた姿」という表現が興味深い。つまり現在のLiquid Glassは、設計者の理想にまだ届いていない状態ということになる。macOS 27での改良と、OLEDタッチスクリーンMacBookの組み合わせによって初めて、Liquid Glassは構想通りの「完成形」に近づくのかもしれない。 実務でMacを日常的に使う立場からすると、デザイン言語の先進性よりも読みやすさ・使いやすさの方が優先度が高い。その意味でmacOS 27での改良は「当然の軌道修正」であり、歓迎すべき変化だ。Appleにはこれからも大胆なデザイン変革を続けてほしいが、ハードウェアとソフトウェアの足並みをそろえた上で「本当に完成したもの」を届けることへの期待を、今回の件で改めて感じた。 出典: この記事は Liquid Glass tweaks are reportedly coming in the next macOS の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleが次期OSでSafariに大幅な利便性向上をもたらす可能性が浮上した。Engadgetが2026年5月10日に伝えたところによると、Bloomberg記者のMark Gurman氏が「SafariにOrganize Tabsという新機能が追加される」と報じている。 Organize Tabsとは何か Gurman氏の報道によれば、「Organize Tabs」はiOS 27・iPadOS 27・macOS 27で初登場する予定の機能で、開いているSafariタブを自動的にグループ化する。ユーザーは自動整理と手動整理を選択できるため、従来のタブ管理フローを維持したいユーザーにも配慮された設計になっているという。 注目すべきは、Appleがこの機能に「Apple Intelligence」ラベルを付けない方針だと報じられている点だ。何らかの形でAIが活用されているにもかかわらず、あえてAI機能として前面に押し出さない姿勢は、Appleが「見えないAI」戦略を継続していることを示唆する。 2021年のタブグループから続く進化 この機能は、Safari 15（2021年）で導入された「タブグループ」の延長線上に位置づけられる。タブグループは手動でグループを作成・整理する機能だったが、Organize Tabsによってそのプロセスが自動化されるかたちになる。 Gurman氏によれば、この機能の初お披露目はWWDC26（2026年6月8日開幕）になる見込みだ。 海外レビューのポイント——Chromeには2年遅れ EngadgetのJackson Chen記者は、Googleが2024年1月にChromeへ同様の機能「Organize Similar Tabs」をジェネレーティブAI機能として実装済みであることを指摘している。Appleはかねてよりライバルと比較してAI関連機能の追加が遅いと評されており、今回もChromeから約2年遅れとなる。 とはいえ、Appleの特徴としてエコシステム全体での一体感のある体験が挙げられる。Mac・iPhone・iPadすべてで同期された状態でタブ整理が動作することへの期待感は大きい。 日本市場での注目点 iOS 27・macOS 27は2026年秋に正式リリースが見込まれており、日本でも同時期にアップデートとして無償提供される予定だ。Safariは国内でもiPhone・Macユーザーを中心に広く利用されており、特にタブを大量に開きっぱなしにするユーザー層には恩恵が大きい。 競合として意識すべきはGoogle ChromeとMicrosoft Edgeだ。Edgeも同様のタブ整理支援機能を実装しており、Appleがどこまで使い勝手で差別化できるかが焦点になる。なお、Apple Intelligenceの国内展開状況が依然として限定的な点は考慮が必要で、Organize Tabs自体はAIラベル非付与とはいえ、同機能がどのOSバージョン・言語環境で動作するかは正式発表を待ちたい。 筆者の見解 Appleが「Apple Intelligence」ブランドを冠さずにAI的な機能を実装しようとしている点は興味深い。使い勝手の改善と、AIラベルへの慎重な姿勢を両立させようとするバランス感覚は、Appleらしいアプローチといえる。 ただし、Chromeが2024年1月に実装した機能を2026年秋に出してくる時間軸は、率直に言って遅い。タブ整理という「地味だが確実に生産性を上げる」領域でChromeに先行を許したことは、同種のユーザーをEdgeやChromeに引き止める要因になってきた可能性がある。 一方で、Appleの強みはエコシステムの深い統合にある。MacとiPhoneでタブ状態が完全に同期された状態で自動整理が働くなら、単体機能の比較では測れない価値が生まれる。WWDC26での詳細発表を見て、その統合度合いを判断したい。 ブラウザのタブ管理は、情報洪水の時代における「認知負荷をいかに下げるか」という問いに直結する。AIがその整理を担う方向性は正しく、どのプラットフォームがその体験を最もスムーズに提供できるかの競争はまだ始まったばかりだ。 出典: この記事は Safari’s latest trick could be automatically organizing your tabs into groups の内容をもとに、筆者の見解を加えて独自に執筆したものです。

General Motors（GM）が自社のコネクテッドサービス「OnStar」を通じて収集した顧客の走行データを、ユーザーの同意なくデータブローカーへ販売していた問題で、カリフォルニア州との間で1,275万ドル（約19億円）の民事制裁金支払いに合意したことをEngadgetが報じた。同州司法長官ロブ・ボンタ氏が主導した訴訟の決着であり、2024年にThe New York Timesが暴いた一連のスキャンダルに区切りがついた形だ。 何が問題だったのか——OnStarデータの知られざる流れ OnStarはGMが提供するコネクテッドカーサービスで、緊急通報・車両診断・盗難追跡などの機能を持つ。問題となったのは、このサービスを通じてGMが収集していた顧客データだ。 Engadgetの報道によれば、GMが収集・販売したデータには以下が含まれる： 氏名・連絡先情報 位置情報（ジオロケーション） 運転行動データ（急加速・急ブレーキ・速度超過などのパターン） このデータはVerisk AnalyticsとLexisNexis Risk Solutionsという2社のデータブローカーへ販売され、さらに自動車保険会社へ転売された。保険会社はこの走行スコアをもとに保険料を引き上げることができる構造だった。 和解の主な内容 カリフォルニア州との和解で定められた条件は以下の通り： 1,275万ドルの民事制裁金支払い 5年間、消費者情報機関（Consumer Reporting Agency）への走行データ販売を禁止 180日以内に保有する走行データを削除（顧客の明示的な同意がある場合を除く） OnStar経由のデータ収集リスクを評価するプライバシープログラムの策定および司法省等への報告義務 なお、カリフォルニア州では保険会社が走行データを保険料算定に使用することを法律で禁じているため、同州の消費者は直接的な保険料引き上げ被害を免れていた可能性が高い。それでも、無断でのデータ販売自体がプライバシー侵害に当たるとして訴訟が提起された。今回のカリフォルニア州との和解に先立ち、GMはすでにFTCとの和解も成立させており、複数の法的決着が相次いでいる。 日本市場での注目点 日本ではGM車の販売台数は限定的だが、コネクテッドカー全般のデータ取り扱いという観点では日本市場も無縁ではない。 トヨタ・ホンダ・日産をはじめとする国内メーカーも、コネクティッドサービスを通じて膨大な走行データを収集している。日本では改正個人情報保護法が適用されるが、「第三者提供への同意」の取り方や、サービス利用規約の奥深くに埋め込まれた同意条項の問題は日本も例外ではない。2022年施行の改正個人情報保護法では「個人関連情報」の第三者提供規制が強化されており、今回のGMのケースは、コネクテッドカーのデータガバナンスがいかに重要かを示す教科書的な事例となりそうだ。 筆者の見解 今回のGM事件が示すのは、「データを集められるからといって、集めた全てを好き放題に活用してよい時代は終わった」という現実だ。 車の走行データは、どこへ行ったか・いつ行ったか・どんな運転をするかという、生活様式そのものを映し出す。このデータが保険料や信用評価に直結するとなれば、ユーザーが「知らないうちに評価されていた」という状況は看過できない。 問いたいのは、データの最小化原則（Data Minimization）を最初から設計に組み込んでいたかという点だ。カリフォルニア州司法長官ボンタ氏は和解声明で「データ最小化の重要性」を強調しているが、これはシステム設計段階からの根本的な問題でもある。「データは資産」という発想が優先されるあまり、ユーザーのプライバシーを後回しにしたビジネスモデルは、長期的には信頼を失い重大な法的リスクを抱えることになる。約19億円の制裁金は、そのコストの一端に過ぎない。 日本の自動車・IT業界も、コネクテッドカー時代の「データ倫理」を本格的に議論すべきタイミングに来ている。利用規約に同意させれば何でも許されるという発想から、「そもそも集める必要があるか」「集めた後どう守るか」を問い直す文化へのシフトが求められる。 出典: この記事は GM agrees to pay $12.75 million to settle California lawsuit over misuse of customers’ driving data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

大規模言語モデル（LLM）の推論コストを語るとき、避けて通れないのが「KVキャッシュ」の問題だ。GoogleがICLR 2026で発表したTurboQuantアルゴリズムは、このボトルネックに正面から挑んだ研究として注目を集めている。日本語メディアではほぼ取り上げられていないが、AI推論インフラに関わるエンジニアは確実に押さえておきたいブレークスルーだ。 KVキャッシュとは何か——なぜこれがボトルネックになるのか LLMがテキストを生成する際、各トークンの処理に必要な「Key」と「Value」の中間表現をキャッシュとして保持する仕組みがある。これが「KVキャッシュ」だ。会話が長くなるほど、あるいはコンテキストウィンドウが大きいモデルを使うほど、このキャッシュが膨大なGPUメモリを消費する。 現代のLLMサービスでは、GPUメモリの大部分がモデルの重み（パラメータ）ではなくKVキャッシュに消費されるケースも珍しくない。大量リクエストをさばく本番環境では、このメモリ消費がスループットを直接制約する。「もっと長い文脈を扱いたい」「もっと多くの同時リクエストを処理したい」——その要求の前に、KVキャッシュの壁が立ちはだかる。 TurboQuantの狙い——量子化で賢く圧縮する TurboQuantが採用するアプローチは「量子化（Quantization）」だ。通常、KVキャッシュはfloat16（16ビット浮動小数点）で保持されるが、これをより低ビット精度で表現することでメモリ使用量を削減する。 単純な低ビット量子化は精度劣化を招く。TurboQuantの貢献は、モデル出力の品質を維持しながらKVキャッシュのメモリオーバーヘッドを大幅削減するアルゴリズムを実現した点にある。ICLR 2026という機械学習のトップカンファレンスで発表された事実が、その技術的厳密さを裏付けている。 推論コストへの直接的な影響 この技術が実用化されると、何が変わるのか。端的に言えば「同じGPUでより多くを処理できるようになる」ことだ。 スループット向上: 同一GPUメモリ内に保持できるKVキャッシュが増え、同時リクエスト数の上限が引き上がる コンテキスト長の実質拡大: 限られたメモリで長い会話や大きなドキュメントを扱えるようになる インフラコスト削減: 同等の処理性能をより少ないGPUで実現できれば、クラウドコストが直接下がる APIの単価低下はユーザーにとっての恩恵だが、プロバイダー側のマージンを圧迫する。KVキャッシュ最適化は、このコスト構造に対する根本的なアプローチだ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 現時点ではTurboQuantは研究段階だが、Google DeepMindの成果はGeminiシリーズへの組み込みを通じて実用化されることが多い。Vertex AI経由でこの恩恵を受ける可能性がある。 また、自社でLLMを運用する組織（オンプレミスやプライベートクラウド環境）にとっては、オープンソースの推論エンジン（vLLM、SGLang等）へのKVキャッシュ量子化の実装状況を継続的に追う価値がある。 今すぐできること 現行の推論サービスでバッチサイズとコンテキスト長のトレードオフを計測・記録しておく。量子化最適化が入ったときの効果測定の基準を今のうちに持っておくと、導入判断が格段に楽になる 中期的に注目すること vLLMやHugging Face TGIなどのOSSへのTurboQuant実装の動向をウォッチする クラウドAPIの料金変動と、その背景にある技術的理由を理解することでベンダー選定の判断精度が上がる 筆者の見解 「AIがコードを書く時代、コストの意味が変わった」——つい先日こんなことを投稿したが、TurboQuantの発表はまさにそれを体現している。 AIを使うコストが下がることで、これまで経済的に成立しなかったユースケースが次々と現実になる。特に複数ステップにわたって自律的に動き続けるエージェント型のシステムにとって、KVキャッシュのコスト問題は本質的な制約だった。長い文脈を維持しながら繰り返し判断・実行するループを回し続けるには、メモリとコストの問題を避けては通れない。TurboQuantはその制約を正面から緩和する技術だ。 研究の世界で証明されたことが実用化されるまでにはタイムラグがある。しかし方向性は明確だ。推論コストは下がり続け、より長いコンテキスト、より多くの同時実行が当たり前になる。日本のIT現場で「AIはまだ高い」「GPUが足りない」という声は今もある。それは今日の話であって、明日の話ではない。こういった基盤技術の積み重ねが、AIを実業務でフル活用できる環境をじわじわと、しかし確実に整えつつある。 情報を追いかけることより、今使えるものを最大限に使い倒す姿勢で臨んでほしい。ただし、インフラを担う立場の人間が技術の潮目を読み違えると組織全体が影響を受ける。TurboQuantのような研究動向は、実務判断の「根拠」として押さえておく価値がある。 出典: この記事は Google TurboQuant Algorithm Reduces KV Cache Memory Overhead Unveiled at ICLR 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティコミュニティには長らく2つの文化が共存してきた。AIの台頭はその両方を、同時に、根底から揺さぶっている。Linux界で最近発生した「Copy Fail」脆弱性をめぐる一連の出来事は、その変化を象徴する出来事だった。 2つの脆弱性開示文化とは何か セキュリティの世界には、大きく分けて2つのアプローチが存在する。 「協調的開示（Coordinated Disclosure）」文化は、おそらく最も広く使われているアプローチだ。脆弱性を発見したら、まず非公開でメンテナに報告し、通常90日の修正猶予を与える。修正が完成した時点で初めて脆弱性の詳細が公開される。ユーザーが修正を適用する機会を確保しながら情報を管理するという考え方だ。 「バグはバグ（Bugs are Bugs）」文化は、Linuxカーネルコミュニティで特に根強い。脆弱性を特別扱いせず、通常のバグ修正と同じように公開リポジトリで速やかに修正する。変更量が膨大なため、攻撃者が重要な修正コミットに気づく前にパッチが普及する可能性を期待する戦略だ。 この2つは対立するようでいて、それぞれの前提が成立する限りは合理的な選択肢だった。 Copy Fail脆弱性が示した転換点 今回の「Copy Fail」脆弱性では、研究者のHyunwoo Kimが発見した脆弱性を非公開のLinuxセキュリティエンジニアリストへ共有し、静かに修正をオープンに反映する「バグはバグ」方式を採った。意図は、修正コードが公開されてもそれが深刻な脆弱性への対処だと気づかれないよう「埋める」ことだった。 だが、Kimが報告してからわずか9時間後、別の研究者Kuan-Ting Chenが独自に同じ脆弱性を発見・報告した。エンバーゴ（情報の一時封鎖）はほぼ意味をなさなかった。 なぜAIは両方の文化を壊すのか 「バグはバグ」文化の崩壊：かつては膨大なコミット量がノイズになり、攻撃者が重要なセキュリティ修正を探し当てるのは困難だった。今はAIがコミット単位で「これはセキュリティパッチか？」を自動判定できる。シグナルとノイズの比率が劇的に改善され、静かに修正を「埋める」戦略はもはや通用しない。 「協調的開示」文化の崩壊：90日のエンバーゴ期間は「同じ脆弱性を誰かが独立発見する可能性が低い」という前提で成立していた。AIを使った脆弱性スキャンが世界中で走っている今、9時間で独立発見されるケースが現実に起きている。エンバーゴ期間は、悪意ある攻撃者と善意の防御者が同じ情報を持てないまま過ぎる「リスク期間」になりかねない。 浮上する「超短期エンバーゴ」という解 元記事の筆者は、「非常に短いエンバーゴ」を暫定的な解として提案している。数日単位ではなく、数時間〜1日単位のエンバーゴを標準化し、さらに短縮していく方向性だ。 逆説的なことに、AIは攻撃者だけでなく防御者のスピードも上げる。かつては「短すぎて意味がない」と言われた超短期エンバーゴでも、AIによる自動パッチ配布・検証のパイプラインが整えば、実用的な時間内に多くのシステムへ適用が完了する可能性がある。 実務への影響——日本のエンジニア・IT管理者はどう動くか パッチ適用サイクルの抜本的な見直しが急務。「月次パッチ」「四半期レビュー」という運用は、脆弱性の公開から悪用開始までの時間が縮小している現実と完全にミスマッチになりつつある。重大度に応じた段階的なパッチ適用フロー（CVSS 9以上は24時間以内適用、など）を設計しておくことが重要だ。 コミット監視パイプラインの整備。OSS依存ライブラリのコミット変更を自動監視し、セキュリティ関連の変更を検知する仕組みを持つことが、これからのサプライチェーンセキュリティの基本動作になる。GitHub ActionsやDependabotを超えた、より積極的な監視設計を検討する段階だ。 「エンバーゴ情報の受信者リスト」への参加を検討。大規模なOSSを利用する組織は、Linux Kernel Security ListやCVE報告先リストへの参加資格要件を把握しておくと、超短期エンバーゴ時代でも早期情報を受け取れる立場になれる。 筆者の見解 セキュリティの世界で「慣行」と呼ばれてきたものが、テクノロジーの変化で一気に時代遅れになる——これは今に始まった話ではないが、AIが関わると変化のスピードが桁違いだ。 注目すべきは、攻撃者と防御者が同じツールを使っているという構造的な変化だ。これはゼロサムゲームのように見えるが、本質的には「スピード」という軸での競争に収束する。パッチを出してから適用されるまでの時間、脆弱性が発見されてから修正されるまでの時間——この「窓」をどれだけ小さくできるかが、組織のセキュリティ成熟度の新しい指標になるはずだ。 90日エンバーゴは「人間の処理速度」に合わせて設計された慣行だ。AIが防御側の処理を加速できるなら、慣行そのものを人間のペースから切り離して再設計する発想の転換が必要だろう。エンバーゴの「何日か」を議論するより、「AIを前提とした開示フローをゼロから設計する」という姿勢が、業界全体に求められている。 日本では脆弱性対応が依然として組織内の意思決定の遅さに引きずられるケースが多い。技術的な問題だけでなく、「誰が決めるか」「何日待てるか」というプロセス設計を今のうちに見直しておくことが、次の大きな脆弱性への備えになる。 出典: この記事は AI is breaking two vulnerability cultures の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIによるコード生成が当たり前になった今、エンジニアの生産性は劇的に向上している。しかし「コードを書くコスト」が下がるとき、別のコストが静かに積み上がっているとしたら？2000年代のオフショア開発ブームが残した教訓が、今まさに繰り返されようとしている。 コードが安くなると、コストは消えない 2000年代初頭、オフショア開発の波が世界を席巻した。トーマス・フリードマンが「フラット化する世界」を説き、米国のエンジニアが自分の仕事を心配していた時代。ある米国の医療記録転記サービス会社での経験が、今回の考察の原点だ。 オフショアチームのエンジニアは優秀だった。コードの品質も高かった。しかし必然的に、「なぜそう作ったか」という文脈が地球の裏側に残ったまま、保守責任だけがこちらに移ってくる瞬間があった。知識は「どこか」に存在した。ただ、必要なときに、必要な場所になかっただけだ。 AI生成コードは「意図」をどこにも残さない 今起きていることはその再演だが、構造的に一段深刻だ。 オフショア開発時代、知識は人間の頭の中にあった。バンガロールのエンジニアが意図を理解していた。伝達は難しくても、理解はどこかに存在した。 AI生成コードには、その人間がいない。コードは文法的に正しく、テストを通過し、出荷されるかもしれない。しかし「なぜこう作ったか」を知っている人間が、最初から存在しない。コミットされた瞬間、意図は宙に浮く。 経済学的に見れば、これは「インプットが安くなると、価値はその補完物にシフトする」という原則の再現だ。コード生成が安くなった今、価値がシフトしているのは「理解」だ。コードを安全に変更できる理解、プレッシャー下でデバッグできる理解、次の担当者に「なぜ」を説明できる理解。 実務での活用ポイント 日本のエンジニア・IT管理者がすぐに取り入れられる対策を整理する。 レビューの目的を変える: AI生成コードのレビューは「バグ探し」だけではもはや不十分だ。「この実装の意図は把握できるか」「半年後に自分が変更できるか」をレビュー項目に加える。 意図をコメントに残す役割分担を明示する: AIに「実装」は任せても、「なぜこのアプローチを選んだか」の記録は人間が書く。この分担をチームで明示的に決めておくだけで、後の混乱を大きく減らせる。 計測指標を見直す: 「コード行数」「PRのマージ速度」だけで生産性を測るのは危険だ。「理解可能なコードベースの維持」を明示的なエンジニアリング目標として設定することを検討してほしい。 AIをドキュメント生成にも使う逆転の発想: AIはコード生成だけでなく、既存コードの意図の文書化にも有効だ。「このコードは何をしているか、なぜこう設計されているか」をAIに分析させ、人間がそれをレビュー・修正する使い方は、今すぐ導入できる。 筆者の見解 AIを使い倒している立場から正直に言えば、この指摘は刺さる。 AIが生成するコードは「平均的に優秀」だ。動く。テストを通る。スピードは圧倒的だ。しかし「動くコード」と「理解できるコード」は別物であり、その差がじわじわと技術的負債として蓄積する。 オフショア時代に賢明な組織が学んだ教訓は「分散開発をやめる」ではなかった。共有コンテキストへの意図的な投資、コードレビュー、相互理解の構築という「遅い仕事」を大切にした組織が生き残った。今われわれに必要なのも、まったく同じことだ。 AIエージェントが自律的に動き続ける世界が本格化したとき、そのエージェントが生成するコードのコンテキストをどう維持するか——これは今から設計しておくべき問いだ。コードが安くなった分だけ、理解に投資する余力が生まれるはずだ。その余力を理解の向上に使うか、ただ出力量を増やすだけに使うか。そこに、この時代を生き残る組織とそうでない組織の分かれ目がある。 出典: この記事は What we lost the last time code got cheap の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Edgeがエンタープライズユーザー向けにパスキー（Passkey）のクロスデバイス同期機能を提供開始する。個人向けのパスワードレス認証は以前から整備が進んでいたが、企業環境における「複数デバイス対応」という壁がようやく崩れる。フィッシング耐性が高く、利便性も損なわない次世代認証が、いよいよ職場レベルで普及フェーズに入ろうとしている。 パスキーとは何か、なぜ今重要か パスキーはFIDO2/WebAuthn規格に基づく認証方式で、公開鍵暗号を使ってパスワードを完全に置き換える。ユーザーはPINや生体認証（指紋・顔認証）でデバイスをアンロックするだけでログインが完了し、パスワードそのものをサーバーに送ることはない。 最大の特徴はフィッシング耐性だ。パスキーは登録されたドメインに厳密に紐付いており、偽サイトには一切反応しない。「それっぽいURLに騙されてパスワードを入力してしまった」という攻撃シナリオがそもそも成立しなくなる。これは理論上の話ではなく、設計レベルで攻撃ベクターを潰しているという意味で根本的な解決策だ。 Enterprise向けクロスデバイス同期の何が変わるのか 個人ユーザー向けにはすでにパスキー同期の仕組みが存在していた。問題は企業環境特有の複雑さだ。 複数のPCを使い回すシーン（共有端末、フロア変更、出張など） 新デバイスへの移行時に毎回パスキーを再登録する手間 IT管理者による一元的なポリシー適用の難しさ これらが障壁となり、企業レベルのパスワードレス移行は思うように進んでこなかった。EdgeのEnterprise向けパスキー同期はこのギャップを埋める。MicrosoftアカウントまたはEntra ID（旧Azure AD）に紐付けた形でパスキーを同期させることで、社員がデバイスを変えても再登録なしでシームレスにログインできるようになる。 実務への影響——IT管理者・エンジニアへのヒント IT管理者へ： IntuneやGroup Policy経由でパスキー使用を強制するポリシー設計が現実的になる段階に来ている パスワードリセット対応のヘルプデスクコストが大幅に削減できる可能性がある MFAとの組み合わせを段階的移行計画として整理しておくとスムーズ エンジニアへ： 社内Webアプリ側もWebAuthn対応が必要。未対応のレガシーシステムのリストアップを今から始めるべき Entra IDのパスワードレス認証ポリシーと組み合わせることで効果が倍増する Edgeを標準ブラウザとして管理している環境なら、追加コストなしで恩恵を受けられる 筆者の見解 この機能は正しい方向への投資だと評価している。ゼロトラストの文脈で言えば、「デバイスを信頼するのではなく、アイデンティティを信頼する」という原則とパスキーは完璧に整合している。VPNで社内ネットワークに繋いでいれば安全、という旧来のセキュリティモデルはもう限界を超えている。パスワードという人間側の弱点を「設計として排除する」アプローチは理にかなっている。 「禁止ではなく、安全に使える仕組みを」という観点でも、パスキーは優れた答えだ。複雑なパスワードポリシーを従業員に強制するより、そもそもパスワードを使わせない設計の方が、セキュリティと利便性を同時に高められる。IT部門が「禁止のガードレール」を増やすのではなく、「便利で安全な公式の道」を整備する発想と一致している。 MicrosoftがEntra IDとEdgeのエコシステムを一体で強化しているのは評価できる——あとは、その強さをユーザーが実感できる形で届けきれるかどうかだ。パスワードレス移行は技術的には準備が整ってきた。残るボトルネックは、組織側の移行計画と現場への浸透だろう。今がその計画を本気で立てる時期だと思う。 出典: この記事は Microsoft Edge is finally bringing passkey syncing to enterprise users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

パスワードの終わりが、静かに始まっている Microsoftが「World Password Day（世界パスワードデー）」に合わせて、パスワードレスサインインとパスキー（Passkey）の採用を強力に推し進めている。「パスワードはもう十分ではない」という同社のメッセージは、単なるマーケティングではなく、現実の脅威状況を直視した宣言だ。フィッシング、クレデンシャルスタッフィング、ブルートフォース——これらの攻撃の大部分がパスワードを起点としている。そのパスワードをゲームから外すことが、認証セキュリティの根本的な改善につながる。 パスキーとは何か——仕組みをざっくり理解する パスキーはFIDO2/WebAuthn標準に基づく認証技術で、ざっくり言えば「公開鍵暗号を使ったパスワード不要のログイン」だ。 ユーザーがパスキーを登録すると、デバイス側に秘密鍵、サービス側に公開鍵が保存される。ログイン時は、デバイスの生体認証（顔・指紋）やPINで秘密鍵を使った署名を生成し、サービス側がそれを公開鍵で検証する。この仕組みには二つの大きなメリットがある。 フィッシング耐性: 秘密鍵はデバイスの外に出ないため、偽サイトに誘導されても認証情報を盗まれない。 サーバー漏洩リスクの排除: サービス側に保存されるのは公開鍵のみ。仮にデータベースが漏洩しても、攻撃者は何もできない。 MicrosoftはすでにMicrosoftアカウントへのパスキーサポートを実装しており、今回の発表はその普及加速と、エコシステム全体でのパスワードレス推進を意図したものだ。 Microsoftが今これを推す背景 World Password Dayは毎年5月の最初の木曜日に設定されているが、ここ数年で各社のスタンスが「パスワードを強化しよう」から「パスワードをなくそう」へと明らかにシフトしている。 Apple、Google、Microsoftの三社がFIDOアライアンスを通じてパスキーの相互運用性を推進してきた結果、主要なOS・ブラウザでのサポートが揃いつつある。iCloud Keychain、Google パスワードマネージャー、Windows Helloいずれもパスキーを扱える環境が整っている。 インフラが揃ったいま、Microsoftが「普及のアクセル」を踏むタイミングとして今年のWorld Password Dayを選んだのは、ある意味必然的な流れだ。 日本企業・IT管理者が今すぐ確認すべきこと パスキー推進の波は、日本のエンタープライズ環境にも確実に押し寄せてくる。特に以下の点を早急に確認しておきたい。 Entra ID（Azure AD）のパスワードレスポリシー確認 Microsoft Entra IDはFIDO2セキュリティキーやWindows Helloによるパスワードレス認証をすでにサポートしている。認証方式ポリシーでパスキー（FIDO2）が有効になっているか確認し、パイロット展開を検討する価値がある。 条件付きアクセスとの組み合わせ パスキー単体でなく、条件付きアクセスポリシーと組み合わせることで「デバイス準拠 × フィッシング耐性のある認証」という二重の保証が得られる。ゼロトラストアーキテクチャの観点からも、これが現時点でのベストプラクティスだ。 ユーザー教育の準備 技術的な移行より、ユーザーへの説明が実は一番のハードル。「指紋やPINでログインできる」という体験の良さを先に伝えることで、抵抗感を大幅に下げられる。 レガシーアプリのプロトコル対応確認 Basic認証やNTLM認証に依存した古いアプリがある場合、パスワードレス移行の障害になる。棚卸しを先に済ませておくことが重要だ。 筆者の見解 セキュリティの話は得意分野ではないが、このトピックは別だ——パスキーはゼロトラストの文脈で語るべき、構造的に正しいアプローチだと思う。 VPNで境界を守るという発想がすでに時代遅れであるように、「強いパスワード＋MFA」で終わりという発想もそろそろ限界に来ている。パスキーはフィッシング耐性という点で、従来のMFAより一段上の保証を与えてくれる。これは「より複雑なパスワードルール」ではなく、ゲームのルールそのものを変える話だ。 Microsoftがこの方向で本気を出しているのは、素直に評価したい。Entra IDのパスワードレス機能は実際に使えるレベルに仕上がっており、エンタープライズ向けの展開フローも整備されてきている。「やる力はある」ということは証明されつつある。 問題は普及スピードだ。日本の大企業の現場では、FIDO2対応のセキュリティキー購入の稟議、レガシーシステムの改修、ヘルプデスクへの問い合わせ増加への対応——そういったコストが積み重なって「まだパスワードでいい」という判断が続きやすい。 だが、これは「いつかやる」ではなく「どこまで先送りできるか」の問いに変わりつつある。フィッシング攻撃が年々巧妙化し、AIを使った標的型攻撃が当たり前になる時代に、パスワードを守り続けることのコストは静かに上昇し続けている。 移行の第一歩として、まず自社のMicrosoftアカウントと個人のスマートフォンでパスキーを試してみることをお勧めする。技術を自分で体験してから導入を検討する、それが一番の近道だ。 出典: この記事は Microsoft says passwords are no longer enough as it pushes passkeys の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsエンジニアなら一度は使ったことがあるはずの「Sysinternals」が、大規模なアップデートを受けた。新しいトラブルシューティング機能の追加、操作性の改善、そしてLinuxサポートの拡充が一気に実施された。地味なアップデートに聞こえるかもしれないが、日々の現場診断に関わる話として、しっかり押さえておきたい内容だ。 Sysinternalsとは何者か Sysinternalsは、Mark RussinovichとBryce Cogswell両氏が1990年代に開発した、Windowsの内部動作を可視化するためのユーティリティ群だ。Microsoftが2006年に買収して以降も、実質的にMark Russinovich（現Microsoftテクニカルフェロー）が継続的に保守している。Process Explorer、Process Monitor（Procmon）、Autoruns、TCPView、Sysmonなど30本以上のツールで構成されており、Windowsプラットフォームのトラブルシューティングや、セキュリティフォレンジックの現場で長年使われ続けている定番中の定番だ。 今回の主な更新内容 新しいトラブルシューティング機能 各ツールに、これまでの診断作業でよくあった「もう一歩踏み込みたい」という要望に応える形で機能が追加された。プロセスとリソースの相関分析、イベントのフィルタリング精度向上など、現場での調査効率を直接底上げする改善が中心だ。 Linux対応の本格化 特筆すべきはLinuxサポートの拡充だ。ProcmonやProcDumpのLinux版はすでに存在していたが、今回の更新でその対応範囲と精度がさらに向上した。Windowsだけを監視すれば良かった時代はとうに終わり、Azure上のLinux VM、WSL2環境、コンテナなどが混在するハイブリッド構成が当たり前になっている今、同じツールセットとメンタルモデルでLinuxも診断できる意義は大きい。 操作性の改善 UIの使い勝手も手が入った。大量のイベントが流れる現場で、いかにノイズを減らして本質的な情報を掴むかという視点での改善で、長時間の調査セッションでの疲労軽減に直結する。 実務への影響：日本のエンジニアが知っておくべきこと Sysmonの活用が改めて重要に Sysinternalsの中でセキュリティ用途に特化したSysmon（System Monitor）は、エンドポイントの詳細なイベントログをWindowsイベントログに記録する。SIEMやMicrosoft Sentinelと組み合わせることで、ゼロトラスト環境における振る舞い検知の精度が格段に上がる。今回の更新でSysmonもブラッシュアップされているなら、導入済み環境でのバージョン更新は早めに検討したい。 Linux診断をSysinternalsで統一できるメリット WindowsエンジニアがLinuxのトラブル対応を求められるケースは増えている。Linuxネイティブのstraceやlsofを覚え直すのは現実的ではない場面で、Procmon for Linuxのような使い慣れたインターフェースで診断できるのは実務的なメリットだ。 Autorunsとセキュリティ運用 Autorunsはマルウェアの永続化ポイントを可視化する用途でも使われる。インシデント対応の初動確認ツールとして組み込んでいるセキュリティチームも多い。更新版では疑わしいエントリの特定精度が上がっている可能性があり、インシデントレスポンス手順書に組み込んでいる場合は動作確認を行っておくと良い。 ライセンスは無料、でも管理は必要 Sysinternalsツールは無料で使えるが、組織として利用する際は使用許諾条件の確認と、バージョン管理の仕組みを整えておくことが望ましい。更新のタイミングで全端末への展開が揃っていないと、診断結果の比較に支障が出る。 筆者の見解 Sysinternalsは、Microsoftが持つ「職人的な技術資産」の代表格だと思っている。華やかなAIデモや大型サービス発表とは全く異なるポジションだが、実際の現場で使い続けられているツールの重みは別格だ。Mark Russinovichというエンジニアが、MicrosoftフェローになってもなおSysinternalsを磨き続けているのは、正直なところ頭が下がる。 Linuxサポートの拡充という方向性は正しい。クラウド時代のインフラはWindowsだけでは到底完結しない。ここでWindowsツールを「Windows専用」のままにしておかず、Linux環境にも展開してきたことは、エンタープライズの現実に向き合った判断だ。この姿勢は素直に評価したい。 ただ、正直に言うと「もっとできるはず」という気持ちもある。ハイブリッド環境の診断ツールとして、Windows・Linux・コンテナを統一的に可視化するプラットフォームへと発展させる余地はまだ十分にある。Sysinternalsには、そこまで届くポテンシャルがあると思っているからこそ、次の一手に期待している。 Windowsプラットフォームへの依存が薄れつつある今だからこそ、こういった地に足のついたツール群を丁寧に育て続けることには意味がある。使い続けてきたエンジニアとして、この更新は素直に歓迎したい。 出典: この記事は Sysinternals tools receive major updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows ドライバー開発の現場に、待望のアップデートが届いた。Microsoft が Windows Driver Kit（WDK）の最新リリースで、Visual Studio 2026 の本番環境向け正式サポートを宣言した。地味に見えて、ドライバー開発者にとっては非常に重要なニュースだ。 WDK と Visual Studio 2026 の正式対応とは Windows Driver Kit（WDK）は、Windows デバイスドライバーを開発するために必要な開発キットだ。ハードウェアベンダーやドライバー開発者は、このWDKとVisual Studioを組み合わせて使うことが基本となる。 これまでVisual Studio 2026はリリースから時間が浅く、WDKとの組み合わせは試験的サポートやプレビュー段階にとどまっていた。今回の更新でようやく本番環境での使用が公式に認められたことになる。 今回のアップデートの主なポイントは以下の通りだ。 Visual Studio 2026 の本番サポート: 正式なプロダクション環境でのドライバー開発が可能に ワークフロー安定性の向上: ビルドプロセスやデバッグ環境の信頼性が改善 最新開発環境への追従: VS 2026 の新機能を活用したドライバー開発が正式対応 実務への影響 ハードウェアベンダーへの影響 日本国内でも多くのプリンターメーカー、産業機器メーカー、周辺機器ベンダーが Windows ドライバーの開発・保守を行っている。これまでVisual Studio 2026への移行を控えていた開発チームも、今回の正式サポート宣言を受けて移行計画を立てやすくなった。 注意点として、WDKはVisual Studioのバージョンと密接に結びついているため、開発環境の一括アップグレードを検討する際は WDK のバージョンとの整合性を必ず確認してほしい。バージョンの食い違いはビルドエラーや予期しない動作につながる。 CI/CD パイプラインへの組み込み ドライバー開発においても CI/CD パイプラインは一般化しつつある。今回のワークフロー安定性の改善は、ビルドサーバー環境での自動ビルド・テストをより確実に行えることを意味する。GitHub Actions や Azure Pipelines でドライバービルドを自動化しているチームは、最新WDKとVS 2026の組み合わせへの移行を具体的に検討する価値がある。 旧バージョンからの移行タイミング Visual Studio 2022 で長らく安定した環境を維持してきたチームも多いだろう。今回の正式サポートは移行の「号砲」となるが、急ぐ必要はない。ドライバー開発は品質と安定性が命であり、移行は本番デプロイの前に十分な検証期間を設けることを強く推奨する。 筆者の見解 正直に言えば、WDKのアップデートは「地味なニュース」に見える。派手なAI機能の発表とは無縁の、職人的な開発ツールの話だ。 しかし筆者はこういったアップデートこそ、Microsoftのプラットフォームとしての強さの源泉だと考えている。Windows エコシステムが30年以上にわたって広大なハードウェアとの互換性を維持してこられたのは、こうした地道な開発者サポートの積み重ねがあったからだ。 ドライバー開発のような低レイヤーの世界は、一度壊れると全体に影響が波及する。だからこそMicrosoftは慎重にサポートサイクルを管理し、「本番環境への正式対応」という言葉に重みを持たせている。この姿勢は変わらず評価したい。 最近のMicrosoftを見ていると派手な発表が多い一方で、こうした地に足のついた開発者サポートも変わらず続けられている。エコシステムを長期的に健全に保つ上で、こういった堅実な取り組みは非常に重要だ。ドライバー開発者の皆さんは今回のリリースノートをしっかり確認し、計画的な移行を進めてほしい。 出典: この記事は Microsoft announces official support for Visual Studio 2026 with latest WDK release の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月、AIコーディングエージェントとして広く使われているClaude Codeに、高深刻度（CVSS v4: 7.7）の脆弱性 CVE-2026-39861 が報告・修正された。シンボリックリンク（symlink）を巧みに悪用することでサンドボックスの外側に任意のファイルを書き込める、という技巧的な攻撃経路だ。AIエージェントを業務に組み込む動きが急加速する今、このケースは業界全体にとって重要な教訓を含んでいる。 脆弱性の仕組み：「組み合わせの妙」が生んだ穴 サンドボックスとは、プログラムの実行範囲を限定してファイルシステムへの意図しない操作を防ぐセキュリティ機構だ。AIエージェントは任意のコードを実行できる性質上、このサンドボックスが安全性の要となる。 今回の脆弱性は、単純なバグではなく「2つの権限の組み合わせ」から生まれた。 サンドボックス内プロセスが、ワークスペース外を指すシンボリックリンクをワークスペース内に作成できた サンドボックス外の本体プロセスが、そのリンクを経由してファイルを書き込もうとすると、リンク先（ワークスペース外）への書き込みが発生した 単独では不可能でも、組み合わせると可能——これが「脱出」の本質だ サンドボックス設計においては、「単体で不可能」なだけでは不十分で、「組み合わせても不可能」という水準まで担保しなければならない。今回はその「組み合わせの穴」が見落とされていた。 攻撃の現実性：プロンプトインジェクションがトリガー この脆弱性の悪用には前提条件がある。プロンプトインジェクションによって、悪意あるコンテンツをコンテキストウィンドウに注入し、サンドボックスコードの実行を誘発させる必要があった。 プロンプトインジェクションとは、AIモデルへの入力に悪意ある指示を混入させ、意図しない動作を引き起こす攻撃手法だ。リポジトリ内の悪意ある設定ファイル、外部APIからの不審なレスポンス、参照先ウェブページに仕込まれた命令文などが攻撃ベクタとなりうる。 CVSS v4のメトリクスは「Attack Vector: Network」「Attack Complexity: Low」「Privileges Required: None」「User Interaction: Passive」と評価されており、ネットワーク経由・特権不要・受動的なユーザー操作で成立する点が「High」評価の主因だ。 対応状況：自動更新で多くのユーザーはすでに保護済み 項目 内容 影響バージョン @anthropic-ai/claude-code 2.1.64未満 修正バージョン 2.1.64 自動更新ユーザー 修正版が自動適用済み 手動管理ユーザー npm install -g @anthropic-ai/claude-code で更新が必要 発見（4月20日）から修正リリース（4月27日）まで約1週間という対応速度は、セキュリティ上の対応として適切なサイクルといえる。HackerOneを通じた責任ある開示（Responsible Disclosure）のプロセスが機能した好例だ。 実務への影響：エンジニア・IT管理者への具体的アクション 即時対応 AIコーディングエージェントを手動管理している環境では、バージョン確認と更新を最優先で実施する CI/CDパイプラインや自動化フローでエージェントを使用している場合は特に注意が必要だ 組織的な取り組み 「ワークスペース外への書き込み」を監視するファイルシステム監視（inotify等）の導入を検討する 外部リポジトリのクローンや不審なAPIレスポンスを直接エージェントに渡す設計は見直す（プロンプトインジェクション対策） エージェントが実行するコードの権限を最小限に絞る「最小権限の原則」を徹底する ベンダーが提供するセキュリティアドバイザリ（GitHub Advisory Database等）を定期購読する仕組みを整える 筆者の見解 今回の脆弱性で興味深いのは、「シンボリックリンク」という数十年来のUNIXの基礎概念が、最先端のAIエージェントのサンドボックスを突破する手段になったという点だ。新しいテクノロジーが古典的な攻撃手法に対して無防備になるパターンは、セキュリティの歴史で繰り返されてきた。 AIコーディングエージェントが「自律的にコードを書き・実行する」存在である以上、サンドボックスの堅牢性はシステム設計の根幹に置かれるべき要素だ。今回の脆弱性は「サンドボックス内外のプロセス間でシンボリックリンクが共有されるリスク」というアーキテクチャレベルの課題を示しており、単なるバグ修正ではなく設計の再点検を促すものだと捉えるべきだろう。 もう一点、見逃せないのがプロンプトインジェクションが「攻撃のトリガー」として機能した点だ。エージェントが外部コンテンツ（リポジトリ、API、ウェブページ等）を読み込む設計では、そのコンテンツに悪意ある指示が含まれる可能性を常に考慮しなければならない。これはもはやモデルの賢さの問題ではなく、セキュリティアーキテクチャの問題だ。 AIエージェントが開発現場に普及していく流れは加速する一方だ。だからこそ「エージェントセキュリティ」を新たな専門領域として業界全体で確立していく必要がある。今回のような脆弱性の発見・開示・修正のサイクルが公開されることで、業界全体のセキュリティ水準が底上げされていく。開発者もユーザーも、その健全なエコシステムを一緒に育てていく責任がある。 出典: この記事は Claude Code CVE-2026-39861:sandbox escape via symlink の内容をもとに、筆者の見解を加えて独自に執筆したものです。

海外の技術コミュニティで「AIを使ってコードを書くことは絶対にしない」という宣言が話題を呼んでいる。Hacker Newsで65ポイントを獲得し80件のコメントが集まったこの主張は、AI活用が当たり前になりつつある今だからこそ、私たちに本質的な問いを投げかけている。 主張の核心：なぜAIコーディングを拒否するのか 著者の立場は単純な「技術嫌い」ではない。コードを書くという行為そのものに宿る価値を守りたいという、強い職人意識から来ている。 主な論点はこうだ。 理解のないコードは負債になる: AIが生成したコードでも、理解していなければバグに直面したとき自力で解決できない 書くことで思考が整理される: コーディングは問題解決のプロセスそのものであり、AIに委託することは思考の一部を手放すことになる スキルの維持と職人の矜持: 長年磨いてきたコーディング能力をショートカットによって錆びさせたくない これはプロとして真剣に考え抜いた上での立場表明であり、単なる変化拒否ではない。 なぜ今、この主張が注目されるのか AIコーディングツールの普及が急速に進む中、このような反論が注目されるのは必然とも言える。背景にはいくつかの構造的な懸念がある。 スキルの二極化が実際に始まっている: AIを使いこなしてアウトプットを大幅に増やすエンジニアと、AIへの依存が進んで基礎力が落ちていくエンジニアの分岐が、現場レベルで起き始めている。この懸念は根拠のないものではない。 「動くコード」と「理解しているコード」の乖離: AIが生成するコードは文法的に正しく、一見動作する。しかし本番環境の複雑な条件下でどう振る舞うか、セキュリティ上の考慮が十分かどうかは、理解していなければ判断できない。 コードレビューの形骸化リスク: チーム全員がAIでコードを書くようになると、誰もそのコードを深く理解していない状態が生まれうる。これはリスク管理の観点から深刻な問題だ。 実務での活用ポイント 日本のエンジニアはどう向き合えばいいか。 1. 「生成させて、理解して、使う」のサイクルを守る AIに生成させたコードを無批判に貼り付けるのは確かに危険だ。しかし「生成 → 読解 → 改変 → 理解」というサイクルを守れば、良いコードのサンプルを素早く参照できる学習ツールにもなる。重要なのは「理解してから使う」という姿勢だ。 2. 中核の設計はエンジニア自身が考える アーキテクチャの決定、データモデルの設計、セキュリティの考慮――これらは自分の頭で考える必要がある領域だ。AIはここでも補助ツールとして使えるが、最終的な判断と理解は人間が持つ必要がある。 3. 未経験領域への足がかりとして使う 全く触れたことのない言語やフレームワークを探索する際、AIは非常に強力だ。生成されたコードを読み解くことで、新しい技術を素早く理解するための「スタートアップコスト」を大幅に下げられる。 4. テストとドキュメントから始める 理解が薄い状態でAIにコードを書かせるリスクが心配なら、まずテストやドキュメントの補助から試すのが現実的だ。リスクが低く、効果が高い領域だ。 筆者の見解 率直に言う。「AIでコードを絶対に書かない」という立場は、誠実な職人意識から来るものとして尊重できる。しかし同じ立場を2年後も維持できる人は少ないだろう。 より本質的に言えば、AIによる支援を「副操縦士」として使うか、「自律して動くエージェント」として使うかで話は全く変わってくる。前者の使い方――AIに一行ずつコード補完させて自分が書いた気になって進む――これは著者が批判する対象に近い。確かに「理解の薄いコード」が溜まっていく危険がある。 しかし後者の使い方――「このシステムを設計してテストまで通せ」という目的を与え、エンジニアはアーキテクチャ判断と成果物のレビューに集中する――これは全く別の話だ。エンジニアの役割は「コードを書く人」から「システムを設計・判断・検証する人」に移行する。これはスキルの喪失ではなく、スキルの高度化だ。 日本のIT現場では、この移行に気づいていない現場がまだ多い。「AIにコードを書かせていいの？」という議論の段階で止まっている間に、世界では「AIエージェントが自律的にシステムを改善し続ける仕組み」の設計競争が始まっている。 「AIでコードを書かない」という宣言の背後にある問い――「エンジニアの本質的価値とは何か」――は、真剣に向き合うべき問いだ。その答えは、コードを一行一行自分の手で書くことではなく、より高い抽象度で技術を設計・判断できる能力にある。その能力を磨くための手段として、AIをどう使うかが、これからのエンジニアに問われている。 出典: この記事は I Will Never Use AI to Code の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MetaがAIを全社的に展開するなか、従業員の間で不満と疲弊が広がっているとNew York Timesが報じた。パフォーマンスレビューへのAI活用、コーディング業務への生成AI組み込み、そして「もっとAIを使え」という会社からの圧力——多くのエンジニアや社員が、自分の仕事の意義そのものを問い直しているという。 これは「Meta固有の問題」では決してない。AIを「経営判断として義務化する」組織と、「使いたくなる仕組みを作る」組織の間にある本質的な差を、この事例は鮮明に浮き彫りにしている。 なぜ「AI全面導入」が社員を苦しめるのか 上から押し付けられたAIは、使う人間の体験を劣化させることが多い。理由はシンプルだ。AIが「自分の仕事を奪うもの」「評価の物差しを変えるもの」として登場すると、人間の防衛反応が働く。作業効率が上がるどころか、心理的なコストが上乗せされる。 Metaの場合、パフォーマンスレビューにAIが絡むという報道は特に象徴的だ。人事評価のような「自分の将来に直結する領域」にAIが入ってくると、社員はAIを協力者ではなく監視者として見るようになる。信頼関係の構築どころか、不信の植え付けだ。 「強制」ではなく「自然に使いたくなる設計」が鍵 筆者が一貫して主張してきたのは、「禁止より安全に使える仕組みを作れ」というアプローチだ。これはAI導入でも変わらない。「使わせる」のではなく、「使うと明らかに楽になる」状況を先に作ることが正しい順序だ。 優れたAI活用組織には共通点がある。ツールの選択権を現場に残す、小さな成功体験から広げていく、評価指標をアウトプットに据えて手段を縛らない——こうした設計が、社員の自発的な活用を生む。強制で得た「使用率」は虚数だ。 実務への影響：日本企業が学べること 日本企業でも「AIを使うよう義務化した」という話が増えてきた。しかし義務化と活用は別物だ。「とりあえず全社展開しました」という状態では、Metaが今直面している問題と同じ轍を踏む。 IT管理者・AI推進担当者へのアドバイスを整理する。 小さなユースケースで実績を積む: 全社一括展開より、特定のチームで「これは使える」という体験を積み重ねるほうが定着率が高い 評価制度とAI使用を切り離す: AIの利用状況を人事評価と絡めることは避ける。最悪の場合、形式的な利用やデータの歪曲を生む 現場の声を定期的に拾う仕組みを作る: AI疲弊のサインは早期に検知できる。定期的な匿名フィードバック収集を仕組みとして組み込む 管理職が率先して「楽しそうに」使う: 「AIを使え」という指示より、リーダー自身が生産性向上を体験している様子を見せることが最大の動機づけになる 筆者の見解 Metaのこの事態について、技術力そのものより「組織設計」の部分に問題の核心があると見ている。多くの優秀なエンジニアを抱える会社が、「AI導入＝トップダウンで義務化」という最もプリミティブな手法に落ち着いてしまうのは、もったいない。 AIの本質的な価値は、「人間の認知負荷を削減し、より創造的な仕事に集中できる状態を作る」ことだと思っている。AIが人間を評価・監視するツールとして機能し始めた瞬間に、その価値は損なわれる。自律的に仕事を進める「エージェント」として使いこなせてこそ、本当の意味での生産性向上が得られる。「副操縦士」として補助させるだけ、あるいは「管理ツール」として使うだけでは、コストに見合った成果は出ない。 企業規模が大きくなるほど、トップの「AI推進」の号令が現場では「監視強化」と受け取られやすい。これは意図と受け取り方のギャップであり、設計の問題だ。 日本のIT現場にとって、このMetaの事例は反面教師として極めて有益だ。「AIで会社を変えたい」と考える経営者・推進担当者は、Metaが今直面している課題をスタート地点として認識してほしい。技術を導入することより、人間がその技術と健全に共存できる仕組みを設計することのほうが、何倍も難しく、何倍も重要だ。 出典: この記事は Meta’s embrace of AI is making its employees miserable の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年5月に展開を予定しているOutlook（新バージョン）およびOutlook Classicの新機能群が明らかになった。今回の更新では、新旧Outlook間の移行時に長らく課題となっていたカレンダー機能の互換性問題が大幅に改善されるほか、チームのカレンダーをナビゲーションペインで一覧できる機能など、日常業務の効率化に直結するアップデートが揃っている。 6つの新機能を詳しく見る 1. オートマップされたカレンダーのサポート 新OutlookにおけるオートマップカレンダーのサポートはMicrosoft 365ロードマップに2024年から掲載されていたが、複数回の延期を経て今月ようやく一般展開が始まる。 Exchange環境では管理者が共有カレンダーやリソースカレンダーを他のメールボックスに自動追加（オートマップ）する設定が広く使われている。Outlook Classicではこれが当然のように機能していたが、新Outlookへ切り替えた途端にそれらのカレンダーが消えてしまうという問題が報告されており、移行を躊躇する大きな理由のひとつになっていた。この問題が解消されることで、組織内の移行促進に弾みがつく可能性がある。 2. ナビゲーションペインへのチームメイトカレンダー自動表示 新Outlookの左ナビゲーションペインに、同僚・部下・上司のカレンダーが自動的に表示されるようになる。同一組織内のアカウントであればMicrosoft以外のアカウントでも機能するとされており、「メールを書きながら相手の空き時間を即座に確認する」という実務フローがよりスムーズになる。まずWebクライアントから展開開始となる。 3. カレンダーグループ・イベントの複数選択 Outlook Classicでは当然使えていたカレンダーグループの複数選択機能が、新Outlookでも利用可能になる。カレンダーの一括選択・解除に加え、カレンダー上での複数イベント選択（開く・コピー＆ペースト・削除・カテゴリ設定）も対応する。「新Outlookに切り替えたら使えていた機能が消えた」というフラストレーションを抱えているユーザーには待望の対応だ。 4. 非連続日付の選択 カレンダーのミニ月表示でShiftキークリックやCtrlキークリックによる非連続日付選択が可能になる。特定の複数日をまとめて指定してアクションを取る操作が直感的に行えるようになる。こちらはWebクライアントへの展開となる。 5. Outlook ClassicへのCopilotインサイト展開 新Outlookではすでに利用可能だった「メール本文内のテキストを選択してCopilotに質問する」機能が、Outlook Classicにも展開される。まだ新Outlookへの移行が完了していない環境でも、AI支援機能を段階的に体験できるようになる。 6. メールのソート機能強化・カレンダーイベント表示形式の追加 メール検索時に活用できるソート機能の強化と、カレンダーイベントの新しい表示フォーマットの追加も予定されている。詳細な仕様は月内に公開される見込みだ。 実務への影響：日本のIT現場で押さえておくべきこと 移行評価を再開するタイミングかもしれない 日本企業のExchange環境では、会議室やプロジェクトチームの共有カレンダーをオートマップで配布している組織は多い。これが新Outlookで機能しないことはヘルプデスクへの問い合わせ増加や、移行計画の先送りを招いてきた。今月のアップデートでこれが解消されるなら、新Outlookへの移行評価を再開する現実的な理由が生まれる。 チームカレンダー機能とプライバシー設定の整備 ナビゲーションペインへのチームメイトカレンダー自動表示は、マネージャーや人事担当者が特に恩恵を受けるだろう。一方で、自動表示されることで意図しない情報が見えてしまうリスクもある。カレンダーの共有設定（空き時間のみ公開か詳細まで公開かのレベル）を組織として整備しておくことが前提条件となる。展開前に設定ポリシーを確認しておきたい。 ClassicとNewの共存期間を意識した計画を CopilotインサイトをClassicへ追加展開する動きは、まだ移行していないユーザーへの配慮とも取れる。ただし「ClassicでもAI機能が使えるなら移行しなくていい」という誤解を生まないよう、組織としての移行ロードマップと期限を明確にしておくことが重要だ。新Outlookの機能が今後も充実していく以上、Classicの延命は限界がある。 筆者の見解 今回のアップデートは、派手さはないが実用性の高い内容が揃っている、というのが率直な印象だ。 オートマップカレンダーの問題は2024年にロードマップへ掲載されてから2年近く放置されてきた。この機能の不在が新Outlook移行の足かせになっていた現場は少なくないはずで、「なぜもっと早く対応できなかったのか」という思いは正直ある。とはいえ、ようやく解消されることは素直に歓迎したい。 Microsoftの強みは、OutlookとTeams、Exchange、Entra IDを含むエコシステム全体の統合にある。チームメイトカレンダーの自動表示は、その統合の恩恵をより自然な形でユーザーに届けようとする方向性の表れだと思う。単体機能の競争ではなく、「チームで使うから価値が出る」という体験を積み重ねていく姿勢は、Microsoftが持つべき本来の強みそのものだ。 Copilotインサイトについては、機能としての有用性は認める。ただし、AIの支援機能は使いどころと使い方が合えばこそ価値が出る。「展開したから使われる」ではなく、組織として「何のためにこの機能を活用するか」を考えてから導入することを勧めたい。 今月のアップデートを機に新Outlookへの移行評価を再開する価値は十分にある。ただし「できるから切り替える」ではなく、「組織の使い方に合っているかを検証してから切り替える」という順番を崩さないようにしたい。Outlookは業務の中心にあるツールだけに、慎重さと前向きさの両方が求められる判断だ。 出典: この記事は Microsoft confirms new features coming to Outlook and Outlook Classic in May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。