Microsoft本社で見た、AI時代の企業変革｜外山 英幸 | ビズリーチ CTO
先日、シアトルのMicrosoft本社で、AI・エージェント・データ基盤に関する複数のセッションへ参加する機会があった。 単なる製品アップデートの共有ではない。 そこにあったのは、AIを導入する企業ではなく、AIを前提に企業そのものを書き換えようとしている姿だった。 そして同時に、なぜ日本企業の変革が難しいのか、なぜDXが必要なのか、その輪郭もより鮮明に見えてきた。 今回は番外編として、現地で感じたことを書いてみたい。 Microsoftは、AIツール企業ではなくなっていた多くの人にとってMicrosoftは、Office、Teams、Windows、Azureの会社だと思う。 もちろんそれは間違っていない。 ただ、現地で感じたのは、先進的なアメリカ企業は「使うかどうか」を議論しないということだった。 使うことは前提であり、その上でどう管理するかを設計している。 Microsoftは今、企
GitHubに機密情報をpushしてしまった日のために — 無効化、履歴除去、多層防御の組み立て方
はじめに GitHubに機密情報が混入してしまったとき、最初に取るべき行動は履歴削除ではありません。漏れたものが何なのかで対応の順序が大きく変わります。本記事では、GitHub Enterprise CloudやGitHub Enterprise Serverを前提に、機密情報の混入を止める仕組みと、混入してしまったあとに残存物を取り除くための作業を、コマンドが手元で再現できる粒度で整理します。 GitHub Docsの該当ページは、漏えいしたものが認証情報であれば、まず無効化やローテーションを行うべきだとしています。無効化できれば履歴の書き換えまで踏み込まなくてよい場合もあります。一方で、個人情報や顧客情報、秘密鍵、設定ファイル、社内URL、証明書のように、ローテーションができないか、残っていること自体が問題になるデータは、Git履歴やGitHub上のPR参照、キャッシュ、fork、cl
WSL2+Docker環境における、CVE-2026-31431 (Copy Fail) への対策メモ
【2026/05/09 追記】注意：まだ暫定対策は解除しないでください wsl --update を実行したところ、WSLの更新（2.7.3）が配信されていることを確認しました。 しかし、uname -r を確認する限りカーネルは 6.6.114.1 であり、リポジトリを見るとこれは2025年12月のリリースです。 時系列的に、本脆弱性（CVE-2026-31431）に対する修正パッチではありません。 https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-wsl-6.6.114.1 読者の皆様は、引き続き .wslconfig による暫定対策（module_blacklist=algif_aead）を維持してください。 公式の修正版が配信されるまで、引き続き状況を観測します。 $ wsl --updat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
