microsoft

2026年版 XIAO nRF52840でnRF Snifferを動かす はじめに BLE（Bluetooth Low Energy）の無線パケットは、Wiresharkと安価なBLE対応マイコンボードをスニファにしてキャプチャできます。 スニファ（Sniffer）とは、通信を傍受してパケットを観察・解析するためのツールです。 BLEスニファを使えば、BLE機器が送信する無線パケットを、通信相手として接続せずに確認できます。 BLEを使った電子工作だけでなく、組込み機器の開発や簡易的な通信トラブルの解析にも役立つので、おすすめです。 Nordic Semiconductorが提供する nRF Sniffer for Bluetooth LE を利用すれば、対応するnRF52シリーズのデバイスをBLEスニファとして使用できます。 今回は、Nordic SemiconductorのnRF52840を搭載した、技適取得済みの Seeed Studio XIAO nRF52840 を使用します。 XIAOを選ぶ理由は、次の3点です。 技適取得済みの製品である：日本国内で入手できるBLE対応マイコンボード 安価で入手しやすい：自作の無線キーボードなどでもよく使われている 小型で扱いやすい：USB接続のBLEスニファとして手軽に利用できる 本記事ではXIAO nRF52840（無印）を使用します。XIAO nRF52840 Plusも旧バージョンは動作していますが、今回のSnifferファームウェア 5.0.0 の動作確認は無印で行いました。 XIAOでnRF Snifferを動かす方法はこちらのQiita記事でも紹介されていますが、現在はファームウェアの配布方法が変わっています。 本記事では、2026年11月時点で取得できる nRF Sniffer 5.0.0 を使用し、Nordic公式のnRF Utilによるファームウェア取得から、UF2形式への変換、Wiresharkでの動作確認までを紹介します。あわせて、BINからUF2への変換が必要な理由や、フラッシュメモリの配置アドレスについても解説します。 なお、使用するのはNordic純正のnRF52840 Dongle用ファームウェアであって、XIAO向けの公式ファームウェアではありません。 使用環境 項目 内容 OS Windows 11 シェル PowerShell Python 3.11.6 ボード XIAO nRF52840（無印） 対象ボード XIAO nRF52840 / XIAO nRF52840 Plus nRF Util 8.1.1 nRF Util BLE Sniffer 0.22.0 Snifferファームウェア 5.0.0 UF2変換 Microsoft uf2conv.py パケット解析 Wireshark XIAO nRF52840には、USB経由でUF2ファイルを書き込めるブートローダが搭載されています。今回は、この仕組みを利用してSnifferファームウェアを書き込みます。 1. nRF Utilのインストール 以前は、Nordic SemiconductorがnRF Snifferを独立したツールとして配布していましたが、現在は配布方法が変更されています。 そのため、以前のQiita記事で紹介されているファームウェアの取得手順は、現在ではそのまま利用できません。 今回は、nRF Snifferのファームウェアを取得するために、nRF Utilを使用します。 nRF Utilは、Nordic Semiconductorが提供するコマンドラインユーティリティです。 nRF Utilの入手 公式サイトからWindows版をダウンロードします。 nordicsemi.com ダウンロードした nrfutil.exe を任意のディレクトリに配置し、そのディレクトリをPATHに追加します。 例えば、次の場所に配置した場合です。 C:\tools\nrfutil\nrfutil.exe PowerShellで一時的にPATHを追加するには、次のようにします。 (今後もnrfutilを使うなら、恒久的にPATHを通しましょう) $env:PATH = "C:\tools\nrfutil;$env:PATH" これは現在のPowerShellセッションだけに有効な設定です。 動作確認します。 nrfutil --version 私が確認した環境では、以下のバージョンでした。 nrfutil 8.1.1 次の手順では、このnRF Utilを使って、XIAOに書き込むためのSnifferファームウェアを取得します。 2. BLE Snifferコマンドのインストール nRF Utilは、必要な機能をコマンド単位で追加する仕組みになっています。 まず、利用可能なコマンドを確認します。 nrfutil search 続いて、BLE Snifferコマンドをインストールします。この操作で、Snifferファームウェアも取得されます。 nrfutil install ble-sniffer インストール済みのコマンドを確認します。 nrfutil list 今回使用したBLE Snifferのバージョンは0.22.0です。 Command Version ble-sniffer 0.22.0 device 2.15.7 3. Snifferファームウェアの取得 BLE Snifferコマンドをインストールすると、Sniffer用ファームウェアも配置されます。 Windowsの標準的なインストール先は次のとおりです。 C:\Users<ユーザ名>.nrfutil\share\nrfutil-ble-sniffer\firmware PowerShellで確認します。 Get-ChildItem "$HOME.nrfutil\share\nrfutil-ble-sniffer\firmware" 今回取得できたファイルは以下の4つです。 sniffer_nrf52833dk_nrf52833_5.0.0.hex sniffer_nrf52840dk_nrf52840_5.0.0.hex sniffer_nrf52840dongle_nrf52840_5.0.0.zip sniffer_nrf52dk_nrf52832_5.0.0.hex 今回は、nRF52840 Dongle（PCA10059）用のZIPファイル に含まれるファームウェアを、XIAO nRF52840で書き込めるUF2形式に変換します。 sniffer_nrf52840dongle_nrf52840_5.0.0.zip UF2変換用BINファイルの取得 まず、作業ディレクトリを作成して移動します。 (ここでは作業ディレクトリはworkとしました) New-Item -ItemType Directory -Path ".\work" -Force Set-Location ".\work" 続いて、SnifferファームウェアのZIPファイルを展開します。展開先のディレクトリ名は sniffer_5.0.0 としました。展開には、PowerShell標準の Expand-Archive コマンドを使用します。 Expand-Archive -Path "$HOME.nrfutil\share\nrfutil-ble-sniffer\firmware\sniffer_nrf52840dongle_nrf52840_5.0.0.zip" -DestinationPath ".\sniffer_5.0.0" 展開すると、作業ディレクトリは次の構成になります。 work/ └── sniffer_5.0.0/ ├── manifest.json ├── sniffer_nrf52840dongle_nrf52840.bin └── sniffer_nrf52840dongle_nrf52840.dat sniffer_nrf52840dongle_nrf52840.binを、XIAO nRF52840に書き込めるUF2形式に変換します。 4. BINからUF2への変換 uf2conv.pyの取得 変換には、Microsoftが公開しているPython製のUF2変換ツールを使用します。 github.com/microsoft/uf2/tree/master/utils 実行にはPython 3が必要です。今回の検証ではPython 3.11.6を使用しました。 以下の2ファイルをダウンロードし、作業ディレクトリ work に配置します。 uf2conv.py uf2families.json 前項で展開したSnifferファームウェアも含め、作業ディレクトリは次の構成になります。 work/ ├── uf2conv.py ├── uf2families.json └── sniffer_5.0.0/ ├── manifest.json ├── sniffer_nrf52840dongle_nrf52840.bin └── sniffer_nrf52840dongle_nrf52840.dat UF2への変換 引き続き、PowerShellで作業ディレクトリ work から以下を実行します。 python .\uf2conv.py .\sniffer_5.0.0\sniffer_nrf52840dongle_nrf52840.bin --base 0x1000 --family 0xADA52840 --convert --output .\sniffer_5.0.0\flash.uf2 実行結果： Converted to uf2, output size: 164864, start address: 0x1000 Wrote 164864 bytes to .\sniffer_5.0.0\flash.uf2 flash.uf2が生成されれば変換完了です。 補足：BINからUF2への変換について BINファイルには、フラッシュメモリ上の配置アドレス情報が含まれていません。一方、UF2ファイルには書き込み先アドレスが含まれるため、変換時に配置開始アドレスを指定します。 今回使用したオプションは以下のとおりです。 オプション 意味 --base 0x1000 BINデータの配置開始アドレス --family 0xADA52840 nRF52840のUF2 Family ID --convert UF2形式に変換 --output 出力先ファイル --base で指定した 0x1000は、nRF52840 Dongleで使用される、フラッシュメモリ先頭の4KBをMBR用に確保したメモリ配置に対応するアドレスです。 今回のSnifferファームウェア5.0.0も、このアドレスを指定してUF2に変換し、XIAO nRF52840で正常に動作することを確認しました。 5. XIAO nRF52840への書き込み XIAO nRF52840をUSBでPCに接続し、リセットボタンを素早く2回押してUF2ブートローダモードに移行します。 ブートローダモードになると、USBストレージとして認識されます。 今回使用したXIAO nRF52840（無印）では、ドライブ名がXIAO-SENSEと表示されました。Senseモデルではありませんが、このドライブ名でも問題ありません。 生成したflash.uf2をUSBドライブへコピーします。 Copy-Item ".\sniffer_5.0.0\flash.uf2" "E:\" ※ E:\は例です。実際に認識されたUSBドライブのドライブ文字に置き換えてください。 書き込みが完了すると、XIAOは自動的に再起動します。 今回のSnifferファームウェア5.0.0でも、XIAO nRF52840で正常に動作することを確認しました。 6. WiresharkでBLEパケットをキャプチャする nRF UtilのBLE Snifferには、Wiresharkとの連携機能があります。 Wiresharkの外部キャプチャ機能（extcap）を設定するため、PowerShellで次のコマンドを実行します。 nrfutil ble-sniffer bootstrap --only ble 設定後、XIAO nRF52840をPCに接続し、Wiresharkを起動します。 Wiresharkのキャプチャインタフェース一覧に、nRF Sniffer for Bluetooth LEが表示されます。 <img src="/images/xiao-nrf52840-sniffer/wireshark-sniffer-detected.png" alt="WiresharkでnRF Snifferを認識" width="800"> このインタフェースをダブルクリックすると、BLEパケットのキャプチャが開始されます。 <img src="/images/xiao-nrf52840-sniffer/wireshark-capture.png" alt="WiresharkによるBLEパケットのキャプチャ結果" width="800"> 今回、Snifferファームウェア5.0.0を使用したXIAO nRF52840で、WiresharkによるBLEパケットのキャプチャが正常に動作することを確認しました。 まとめ Nordic公式のnRF Utilを使ってBLE Snifferファームウェア5.0.0を取得し、XIAO nRF52840で動作させる方法を紹介しました。 nRF52840 Dongle用のBINファイルをMicrosoftのuf2conv.pyでUF2形式に変換することで、XIAO nRF52840に書き込むことができます。 Wiresharkとの連携も問題なく、実際にBLEパケットをキャプチャできることを確認しました。 安価なマイコンボードで手軽にBLE通信を観察できるので、電子工作や組込み機器の開発に活用してみてください。 参考資料 Nordic Semiconductor — nRF Util Nordic Developer Academy — nRF Sniffer for Bluetooth LE Nordic — Sniffer firmware files Microsoft — UF2 / uf2conv.py 参考にした既存記事（Qiita）

Playwright再入門：Claude Codeでテストを残し、増やし、GitHub Actionsで回し、MCP・CLIと使い分ける Claude Code で画面を作っていて、ブラウザを動かすテストをまだ持っていないなら、この記事はその入口です。 Playwright（ブラウザを自動で動かす Microsoft の OSS）で書かせて残したテストは、AI なしで1秒前後で回ります。画面が変わると赤くなり、止まった所まで出ます。 AI に頼むのは、テストを書く・直すときと、テストの無い画面をその場で見るときだけで足ります。 テストを残す・増やす・GitHub Actions で回す・MCP と CLI で見させる、の4つを1画面の小さなアプリで順に試します。どの段にも公開サンプルがあります。 ! この記事の内容は動画（全4本）でも解説しています。下は1本目です。 目次：目的から各回を選ぶ 目的から、見たい回へ飛んでください。 テストを作って保つ #1 テストを1本書かせて残す：画面が変わると AI なしで赤くなる #2 Test Agents で増やす：計画を絞って書かせ、6本の赤を1行で直させる 人が走らせなくても回す #3 GitHub Actions で回す：push だけでテストが走り、トレースで原因が分かる テスト以外の使い方を選ぶ #4 MCP と CLI：同じ確認を4通りで比べ、残すか見させるかを選ぶ 前提と試した環境 要る物は次のとおりです。 Node.js（公式の導入ページの要件は「latest 22.x, 24.x or 26.x」） Claude Code（#1・#2・#4） GitHub のアカウント（#3） 確認環境と、試していないこと #1・#2・#4 は、Linux arm64・Node.js 22.22.1・Playwright 1.64.0 で試しました。 回 確認日 試した環境 #1 2026-10-10 Chrome for Testing 156・Claude Code 2.1.296 #2 2026-10-11 Claude Code 2.1.296 #3 2026-10-18 GitHub Actions の ubuntu-24.04 ランナー（手元は Linux） #4 2026-10-18 Chrome なし・画面なし・Claude Code 2.1.302 秒数は途中の許可を聞かれない auto mode の値で、頼むたびに変わります。Mac と Windows では試していません。#4 は本体同梱の npx playwright mcp だけで、@playwright/mcp@latest と Chrome のある端末は試していません。 #1 テストを1本書かせて残す：画面が変わると AI なしで赤くなる Playwright には 1.56 から Playwright Test Agents が入っています。計画を書く planner、テストを書く generator、失敗したテストを直す healer の3つです。Claude Code からはサブエージェントとして呼べます。私が試したかったのは、AI の確認を使い捨てにせず、テストとして残す形です。 実験台の「買い物メモ」。品物を足してチェックすると、下の「残り N 品」が減る サンプルでテスト1本を走らせる zun-tools/playwright-sample は、設定まで済ませた完成形です。 git clone zun-tools/playwright-sample cd playwright-sample npm install npx playwright install chromium npx playwright test 1 passed になります。走ったテストの全文です。 tests/shopping.spec.js // @ts-check import { test, expect } from '@playwright/test'; test('品物を足してチェックすると、残りが減る', async ({ page }) => { await page.goto('/'); await page.getByLabel('品物').fill('牛乳'); await page.getByRole('button', { name: '追加' }).click(); await page.getByLabel('品物').fill('卵'); await page.getByRole('button', { name: '追加' }).click(); await expect(page.getByRole('listitem')).toHaveCount(2); await expect(page.getByRole('status')).toHaveText('残り 2 品'); await page.getByRole('checkbox', { name: '牛乳' }).check(); await expect(page.getByRole('status')).toHaveText('残り 1 品'); }); 操作は fill・click・check、確かめは expect です。 空のフォルダに2コマンドで入れ、設定を足す npm init playwright@latest -- --quiet --browser=chromium --lang=js --no-examples npx playwright init-agents --loop=claude 2つ目で .claude/agents/ に3つのエージェントが、.mcp.json に MCP サーバ（playwright-test）が入ります。サンプルの index.html を置き、設定に3か所足します。 playwright.config.js（足した所） reporter: [['list'], ['html', { open: 'never' }]], use: { baseURL: 'localhost', }, webServer: { command: 'npx http-server -p 8080 -s .', url: 'localhost', reuseExistingServer: true, }, tests/seed.spec.ts の // generate code here. は、await page.goto('/'); に替えます。seed は、エージェントが最初に走らせるテストです。設定を足さずに頼んだ回は、generator がページを開けず、画面を操作しないままテストを書きました。 generator を名指しして書かせる フォルダで claude を開くと MCP サーバを使うか聞かれます。カーソルは最初「Continue without using this MCP server」にあります。上へ2回動かし、「Use this MCP server」を選びます。 playwright-test-generator エージェントを使って、買い物メモ(index.html)のテストを書いて。計画書は無いので、品物を2つ足して、チェックすると残りが減ることを確かめるテストにして generator はブラウザで操作を通してから、テストを1本書き出しました（51秒〜1分3秒・4回）。読んで合っていれば、そのまま残します。名指しせず「テストを書いて」と頼んだ回は、サブエージェントが使われませんでした。 ボタン名を変えて、AI なしで走らせる index.html のボタン名を「追加」から「入れる」に変え、npx playwright test だけを打ちます。 ✘ 2 …s/shopping-memo/add-and-check-items.spec.ts:7:7 › 買い物メモ › 品物を2つ追加してチェックすると残りが減る (30.0s) Error: locator.click: Test timeout of 30000ms exceeded. Call log: - waiting for getByRole('button', { name: '追加' }) 赤になるまで30秒かかりました。Playwright は操作できるまで待ち、テスト1本の時間切れ（既定30秒）で赤にします。use に actionTimeout: 5000 を足すと、5.1〜5.3秒で赤になりました（既定では30.0〜30.1秒・各3回）。 止まった瞬間の画面は、トレースで見られます。 npx playwright test --trace on npx playwright show-report actionTimeout: 5000 で走らせたトレースの一部。「追加」を探して5秒待った Click が赤。そのときのページのボタンは「入れる」 healer にテストを直させる ボタン名をわざと変えたのなら、直すのはテストの側です。 テストが失敗してる。playwright-test-healer エージェントで直して テストのボタン名2か所が「入れる」に変わり、再実行は緑でした（42〜58秒・4回）。コメントに古い「追加」が残った回もあります。アプリの1行を消して頼んだ別の日の1回（2026-10-09・Claude Code 2.1.295）は、test.fixme を足して止まりました。スキップは結果の上では緑に見えるので、直した後も読みます。 #2 Test Agents で増やす：計画を絞って書かせ、6本の赤を1行で直させる #1 の設定を済ませた所から始めます。増やした後の状態は zun-tools/playwright-agents-sample にあり、AI なしで赤まで試せます。 planner に計画を5つまで書かせる playwright-test-planner エージェントで、買い物メモのテスト計画を作って。seed は tests/seed.spec.ts。tests/shopping.spec.js にテストが1本あるので、それと同じ筋書きは除いて、大事な順に5つまで 約1分で specs/ に日本語の計画（Markdown）ができました。テストを書く前に、何を確かめるかを読めます。絞らずに頼むと、21 と 23 シナリオでした（2回）。 generator に計画から書かせる playwright-test-generator エージェントで、specs/shopping-memo.plan.md の計画からテストを書いて 計画の1項目がテスト1本になり、5本で2分半〜3分半でした。AI なしで走らせると 7 passed、約1秒です。手書きの1本と seed を足した7本になります。緑になったら、計画とテストをコミットしておきます。 表示を1か所変えると、6本がまとめて赤 表示を「残り 1 / 2 品」に変えます。playwright-agents-sample の display-change.patch を git apply すると当たります。自分で変えるなら、index.html の次の3行です。 index.html - <p id="left" role="status">残り 0 品</p> - <p id="left" role="status">残り 0 / 0 品</p> function updateLeft() { const n = list.querySelectorAll('input[type=checkbox]:not(:checked)').length; - left.textContent = 残り ${n} 品; - const all = list.querySelectorAll('input[type=checkbox]').length; - left.textContent = 残り ${n} / ${all} 品; } 緑は seed だけ。「残り」を確かめる6本が、1本あたり5秒ちょっとで赤 エラーには Expected: "残り 0 品" と Received: "残り 0 / 0 品"、テストの行番号が出ます。1本が5秒ちょっとで赤になるのは、expect が既定で5秒まで待つからです。 1行頼んで直させ、差分を読む テストが失敗してる。playwright-test-healer エージェントで直して 約1分で、テスト6ファイルの期待値が新しい表示に直りました。index.html は触られず、再実行は 7 passed です（2回）。 全体の数が行ごとに違うので、一括の置き換えでは書けない 赤にして期待と実際を言葉で出すまでが Playwright で、直したのは Claude Code です。 計画は古いまま残る。 直した後も specs/ は旧表示のままでした。「計画（specs/）も今の表示に合わせて直して」と頼むと、19〜31秒で直りました（3回） アプリ側の変更が戻されることがある。 アプリを壊して頼んだ4回で、テストを壊れた値に合わせた回は0回でした。ただし3回は、聞かれないまま未コミットの変更が元に戻され、1回は戻してよいか聞いて止まりました。頼む前にコミットしておけば、git diff で取り返せます #3 GitHub Actions で回す：push だけでテストが走り、トレースで原因が分かる 打ち忘れた日も赤が出るよう、push のたびに GitHub Actions で走らせます。サンプル zun-tools/playwright-ci は、#1 のサンプルに package-lock.json と workflow を足した物です。雛形からは、Chromium だけ入れ、アクションの版を v6 に上げました。 .github/workflows/playwright.yml name: Playwright Tests on: push: branches: [ main, master ] pull_request: branches: [ main, master ] jobs: test: timeout-minutes: 60 runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: lts/* - name: Install dependencies run: npm ci - name: Install Playwright Browsers run: npx playwright install --with-deps chromium - name: Run Playwright tests run: npx playwright test - uses: actions/upload-artifact@v6 if: ${{ !cancelled() }} with: name: playwright-report path: playwright-report/ retention-days: 30 自分のリポへ push して緑を見る git clone zun-tools/playwright-ci cd playwright-ci npm ci gh repo create <自分の名前>/playwright-ci --public git remote set-url origin github.com<自分の名前>/playwright-ci.git git push Actions のタブに緑が付きます。push から緑まで55秒と38秒でした。ubuntu-latest は 2026-10-19 から Ubuntu 26.04 へ順に移る、と GitHub が告知しています。ubuntu-26.04 を指定しても、緑2回・赤1回で同じ形でした。 ボタン名を変え、テストを打たずに push する index.html のボタン名を「入れる」に変えて、そのまま push します。 git commit -am "ボタン名を変える" git push テストのコマンドは打たず、push から130秒で ✗ が付きました。 Actions の一覧。ボタン名を変えたコミットだけが ✗ になり、戻すと緑に戻った 赤が長いのは、CI では再試行が2回入る（retries: process.env.CI ? 2 : 0）からです。30秒待つ赤が3回続きます。gh run view <番号> --log-failed でも、待っていた操作とテストの8行目が出ます。 知らせは設定しだいです。試し用の公開リポでは、失敗のときだけ通知とメールの両方が届きました（2026-10-11）。サンプルの上の赤では、メールは届いていません（2026-10-18）。 自分のリポで受け取るなら、Settings → Notifications の Actions の欄で Email を確かめます。一覧の ✗ は、知らせが無くても残ります。 レポートを落とし、再試行1回目のタブからトレースを開く gh run list gh run download <番号> -n playwright-report -D ci-report npx playwright show-report ci-report -D を付けないと gh run download は失敗します。 失敗したテストのページには Run・Retry #1・Retry #2 の3つのタブがあり、トレースは Retry #1 にだけあります（雛形の trace: 'on-first-retry'）。 最初の Run のタブにはトレースが無い。Retry #1 を開く GitHub の上で走ったテストの、止まった瞬間の画面。ボタンは「入れる」になっている うっかりならボタン名を戻し、わざとならテストを直します。レポートには画面がそのまま写るので、秘密の入る画面は扱いに気をつけてください。 #4 MCP と CLI：同じ確認を4通りで比べ、残すか見させるかを選ぶ Playwright の README は、使い道に「テスト・スクリプト・AI エージェントの道具」の3つを挙げています。AI 向けには、本体に MCP サーバと CLI（playwright-cli）が入っています。同じ確認を4通りでやって並べました。確認は「牛乳と卵を足し、牛乳にチェックすると『残り 1 品』になるか」です。サンプルは zun-tools/playwright-scripts-sample です。 git clone zun-tools/playwright-scripts-sample cd playwright-scripts-sample npm install npx playwright install chromium npm run serve # 別の端末で開いたままにする テストとスクリプト：先に書いた物を AI なしで走らせる 1通り目は npx playwright test で、#1 と同じテスト1本です。2通り目は、テストの枠と expect を外した12行のスクリプトです。 scripts/check.mjs // 買い物メモの定型確認（テストランナーを使わない Playwright ライブラリのスクリプト） import { chromium } from 'playwright'; const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto('localhost'); for (const name of ['牛乳', '卵']) { await page.getByLabel('品物').fill(name); await page.getByRole('button', { name: '追加' }).click(); } await page.getByRole('checkbox', { name: '牛乳' }).check(); console.log(await page.getByRole('status').textContent()); await browser.close(); node scripts/check.mjs は、合否ではなく読んだ表示（「残り 1 品」）を出します。スクショや PDF にも同じ書き方が使えます。 MCP と CLI：何も書かずに AI に見させる 既定では手元の Chrome を使いますが、Chrome の無い Linux では入れ方を案内されて止まりました。そこで Playwright が入れた Chromium を指しました。MCP は flag を2つ、CLI はサンプルの .playwright/cli.config.json で指しています。 MCP（Chrome の無い Linux で足した形） claude mcp add --scope project playwright -- npx playwright mcp --headless --executable-path <Chromium の場所> CLI（使い方を教えるスキルをフォルダに入れる） npx playwright cli install --skills <Chromium の場所> は、npx playwright install --dry-run chromium の「Install location」の下の chrome-linux*/chrome です。 公式の説明では、1.62 から MCP サーバと playwright-cli は本体に同梱されています。 頼む文は次のとおりです。MCP のときは、最後の1文を「ブラウザの操作には playwright MCP のツールを使うこと。」に変えます。 localhost の買い物メモで、品物「牛乳」と「卵」を追加してから「牛乳」にチェックを入れると、画面の表示が「残り 1 品」になるか確かめてください。最後に「はい／いいえ」と根拠を1行で答えてください。ブラウザの操作には playwright-cli（このフォルダでは npx playwright cli）を使うこと。 CLI で頼んだ1回目。スキルを読んでからコマンドを打ち、28秒で「はい」と答えた 答えは4回とも「はい」でした。MCP は道具を1つずつ呼び、CLI はスキルを読んでからコマンドをまとめて打ちます。 4通りを並べて選ぶ npm run serve のページは開いたままにしました。AI の2つは1回ごとに Claude Code を開き直し、「AI の往復」は道具やコマンドを呼んだ回数です。 やり方 先に書く物 出る物 かかった時間 AI の往復 テスト テスト1本 合否（1 passed） 0.92・0.87秒 0回 スクリプト 12行 読んだ表示「残り 1 品」 0.43・0.41秒 0回 MCP なし 「はい」と根拠 18・25秒 6・7回 CLI なし 「はい」と根拠 28・26秒 5・6回 表の秒数は、ほかの作業が走っていないときの値です。選ぶ基準は桁の差で、残す2つは1秒かからず AI 0回。見させる2つは、頼むたびに20秒前後かかります。 MCP と CLI の間は、速さでは選びません。公式は、playwright-cli は Claude Code などのコーディングエージェントに向き、MCP は状態を持ち続ける長い作業に向くと書いています。 使い所は、表から次のように選べます。 明日も同じ確認をする → テストに残す。2回目も1秒かからず、変わったら赤で知らせる 確かめではない作業（PDF・定型の入力） → スクリプト テストのまだ無い画面を、いま一度だけ見る → AI に見させる。Claude Code なら、まず CLI 見させた確認を何度も使う → テストへ移す（#1 の generator） まとめ generator は操作を通してテストを書き、残したテストは AI なしで回る。画面が変わると止まった所を出して赤になる（既定30秒・actionTimeout で約5秒） 計画を絞って書かせればテストは増え、6本の赤も1行の頼みで直る。頼む前にコミットし、後で差分と計画を読む workflow を足せば push のたびに走り、赤は約2分で ✗ になる。トレースは再試行1回目のタブにある MCP と CLI は書かずに見させる道具で、毎回時間がかかる。繰り返す確認はテストに残す まずは #1 のサンプルで緑を見て、「追加」を「入れる」に変えてもう一度走らせてください。 動画で見たい方はこちら（全4本）: #1 テストを書かせて残す #2 Test Agents で増やし、直させる #3 GitHub Actions で回す #4 MCP と CLI を使い分ける 参考リンク microsoft/playwright（公式リポジトリ） Playwright 公式 docs: Playwright Test Agents Playwright 公式 docs: Installation Playwright 公式 docs: Locators Playwright 公式 docs: Auto-waiting Playwright 公式 docs: Timeouts Playwright 公式 docs: Trace viewer Playwright 公式 docs: Continuous Integration Playwright 公式 docs: Trace viewer intro Playwright 公式 docs: Library Playwright 公式 docs: Getting started - MCP Playwright 公式 docs: Getting started - CLI GitHub Docs: GitHub Actions の料金 GitHub Docs: Actions の通知の受け取り方 Claude Code 公式 docs: Permission modes

VS Code 拡張の Marketplace 公開を承認付きのまま PAT なしで自動化した 検証環境: GitHub Actions（ubuntu-latest） @vscode/vsce 4.1.0 対象: vscode-line-ref-copy（Marketplace） 変更: PR #45 背景 自作の VS Code 拡張を Marketplace に出している。v0.1.0〜0.1.2 は VSIX を作って、Marketplace の管理画面にドラッグ＆ドロップで上げていた。 この手作業をやめたい、というのが出発点だ。 公開をわざと手動にしていた理由もある。リポジトリのリリース方針（release.md）で「公開は毎回 kyto が承認する」と決めていた。だから publish 用のワークフローは置かず、自動化は Issue #6（Open VSX / VS Code Marketplace への公開検討）の先送り扱いにしていた。 認証についても release.md に「PAT で公開する。長期の Marketplace PAT は 2026-12-01 に廃止予定と Microsoft が告知している」と書いていた。公式ドキュメントでも、Azure DevOps のグローバル PAT は 2026-12-01 に廃止とされている。 結論 承認を残すために手動にする必要はなかった。GitHub の environment に Required reviewers を付ければ、毎回の承認と自動化を両立できる。 Marketplace の Trusted Publishing（vsce publish --oidc）を使えば、PAT もシークレットもリポジトリに置かずに GitHub Actions から公開できる。 --oidc は vsce 4.0.0 では使えず、4.1.0 に上げたら通った。 ポリシーにはワークフローのファイル名まで登録するので、ファイル名は固定。private リポジトリだとポリシー作成から 48 時間以内に初回実行が必要なので、作るタイミングにも気をつける。 v0.1.3 をこの仕組みで初めて公開し、ワークフローは成功した（2026-10-29 15:23 JST 起動）。 旅路 承認ゲートは environment で作れる 手動にしていたのは「人が承認してから出す」を守るためだった。 でも GitHub Actions の environment に Required reviewers を設定すれば、その environment を使うジョブは承認されるまで始まらない。承認は残したまま、アップロードの手作業だけを消せる。 Marketplace 側の設定 publisher の管理画面 → Trusted Publishing → Create で、次を登録する。 Repository owner: kyto64 Repository: vscode-line-ref-copy Workflow: publish.yml Environment: release ワークフローのファイル名がポリシーに入るので、後から名前を変えないこと。publish.yml の先頭にもその旨をコメントで書いた。 公式ドキュメントによると、private リポジトリの場合はポリシー作成から 48 時間以内に設定したワークフローを走らせる必要がある。最初のトークン交換が成功すると、ポリシーが恒久的に有効になる。 今回は次の version（v0.1.3）の準備ができてからポリシーを作った。 GitHub 側の設定 Settings → Environments に release を作り、Required reviewers に自分（kyto64）を入れる。 タグを打っても、承認するまで公開ジョブは止まる。 ワークフロー 要点だけ書く。 on: push: tags: ["v*"] workflow_dispatch: inputs: tag: required: true permissions: contents: read jobs: publish: environment: release permissions: contents: read id-token: write steps: refs/tags/<tag> を checkout（persist-credentials: false） lint → テスト（xvfb-run）→ compile package.json の version とタグの一致、Marketplace に同じ version が無いことを確認 - run: npx @vscode/vsce publish --oidc 権限はトップレベルが contents: read だけ。id-token: write は publish ジョブだけに付ける。 タグ（refs/tags/<tag>）を checkout する。ブランチの HEAD からは公開しない。タグが無ければ落ちる。 package.json の version とタグ名が違えば落とす。 Marketplace に同じ version がすでにあれば落とす。vsce publish 自体も同じ version では失敗するが、その前に止める。 concurrency（cancel-in-progress: false）で同時に公開が走らないようにする。 vsce のバージョンで詰まる 最初は vsce 4.0.0 のままで、--oidc に対応していなかった。4.1.0 に上げて解決した。 devDependencies で 4.1.0 に固定している。 リリースの流れ version と CHANGELOG.md を更新した PR をマージする。 GitHub Release を作り、v0.1.3 タグを push する。 Publish ワークフローが起動し、release environment の承認待ちで止まる。 自分で承認する。 Marketplace に公開される。 v0.1.3 は 2026-10-29 15:23 JST に起動し、承認後の 15:30 JST ごろに公開まで終わった。 備考 今回は Marketplace のみ。Open VSX は namespace 未作成なので後回し。 手動で VSIX を作って上げる手順は、フォールバックとして残している。 個人開発の private リポジトリでは、この方法はそのまま使えない。GitHub Free / Pro / Team だと Required reviewers は public リポジトリでしか使えない。 実装は AI 開発ボット経由で、公開前の承認だけ自分でやっている。 参考 Publishing Extensions（VS Code Extension API） Publish Visual Studio Marketplace extensions securely with Trusted Publishing（Microsoft for Developers） Retirement of Global Personal Access Tokens in Azure DevOps（Sprint 270 Update） microsoft/vscode-vsce: Trusted publishing vsce v4.1.0 リリース Deployments and environments（GitHub Docs）

GraphRAG論文を実装目線で読む：事前要約とGlobal Searchの境界 GraphRAGを実装目線で読むと、気になるのはグラフの形だけでなく、質問前に何を作り、質問時に何をモデルへ渡すのかです。 この記事では、Darren EdgeらのFrom Local to Global: A GraphRAG Approach to Query-Focused Summarization v2とMicrosoftの公式資料を基に、この境界を整理します。原論文の中心であるGlobal Searchと、公式実装のLocal Searchを区別して扱います。 RAG（検索した外部情報を生成モデルの回答に使う方法）の基本は、ブログのRAGと外部知識の解説を参照してください。以下は資料読解による技術メモで、ライブラリの実行や性能測定はしていません。 通常のRAGとの違いを架空の案件資料から追う説明や、用語ごとの図解は、ブログのGraphRAG解説にまとめています。ここでは中間成果物と検索処理の設計に焦点を当てます。 検索上位の文章は、資料全体の代表とは限らない 「案件Aの担当者は誰か」なら、該当する文章を取得する構成が自然です。一方、「全案件に共通する遅延要因は何か」では、質問に似た文章を上位から取得しても、別の種類の要因が抜ける可能性があります。 GraphRAGの原論文が扱うのは、このような資料全体の理解を要する質問です。関連性だけで選んだ断片に依存せず、関係のまとまりから事前に作った要約を回答の材料にします。 ただし、比較対象は原論文のベクトル検索によるRAGです。複数回の検索や多様性を考慮した取得など、あらゆるRAG構成に対する優位性を示したものではありません。 中間成果物を、役割ごとに分けて読む Microsoftの標準的な索引作成処理は、LLM（大規模言語モデル）で対象や関係を抽出し、そのまとまりを要約します。以下は、公式のDataflowを読むために整理した表です。列名や保存形式を固定する実装仕様ではありません。 成果物 主に保持するもの 設計上、確認したい点 Text units 分割した元の文章 元資料の位置へ戻れるか Entities 人物・組織などの対象と説明 表記違いや同名対象をどう扱うか Relationships 対象間の関係と説明 元資料に記載された関係か、抽出時の誤りか Communities 関係の密な対象のまとまりと階層 分類の粒度が用途に合うか Community reports まとまりごとの内容を整理した要約 元の説明や重要な例外が落ちていないか コミュニティは、元ファイルを部署別に分類したものとは限りません。グラフ上の対象をまとめるため、一つの資料から複数のまとまりに関係する情報が得られることもあります。 原論文と公式資料の概念を基に独自作成した架空例です。実際の検出結果ではなく、階層構造も省略しています。 この区別は更新処理を考えるときにも役立ちます。元資料を修正したら、その文章だけでなく、影響を受けた対象の説明や要約まで古くなり得ます。具体的にどこまで再計算するかは実装によりますが、元資料と派生した情報の対応を追えることを評価項目にしたいところです。 なお、現行資料ではClaims（資料中の主張）の抽出は任意です。論文の概念図に登場するものを、すべての設定で必須の処理だと解釈しないようにします。 Global Search：事前要約と部分回答は別の成果物 Global Searchでは、指定した階層のコミュニティレポートを利用します。概念上の流れは次のとおりです。 レポート集合を、処理できる長さの要約群へ分割する。 各要約群と同じ質問をモデルへ渡し、質問に対する部分回答を作る。 有用性を評価して内容を絞り込み、最終回答の文脈に収める。 選んだ部分回答を使って全体の回答を生成する。 これはMap-Reduce（分割処理した結果を統合する方法）の構成です。実装では、要約群を作る処理、部分回答の生成、選別、最終生成を分けて読むと、どこで情報が落ちたかを追いやすくなります。 原論文と公式Global Searchを基にした独自模式図です。各部分回答には、同じ質問と異なる要約群の両方が入力されます。 事前要約は資料を整理したもので、部分回答は今回の質問に依存します。そのため、質問を変えると部分回答も変わりますが、資料・抽出設定・要約設定が同じなら事前要約を再利用する設計ができます。 ここで注意したいのは、グラフ全体をそのまま最終生成モデルへ渡すわけではないことです。レポートの分割、部分回答の選別、最終文脈の長さという段階ごとの制約があります。情報を広く扱うための構成でも、全事実が回答に残る保証はありません。 公式資料では、細かな階層のレポートほど詳細な回答につながり得る一方、レポート数に応じて処理時間やモデル利用量が増える可能性を説明しています。公式Global Search Local Searchとの違いは、取得の入口にもある Local Searchは、質問と意味の近いエンティティを入口にし、関連する対象・関係・元の文章などを集めます。Global Searchの処理を、対象の数だけ少なくしたものと考えると、この違いを見落とします。公式Local Search 比較軸 Local Search Global Search 入口 質問に関連する対象 指定階層のコミュニティレポート 主な文脈 対象の関係情報と関連文章など 要約群から作る部分回答 向く質問の例 特定の案件に関わる部署と役割 案件群全体で繰り返される課題 確認したい失敗 入口となる対象の取り違え 要約・選別での重要論点の脱落 GraphRAGでも意味の近さによる検索は使われます。「ベクトル検索かグラフか」の二択より、どの情報を入口に、何を組み合わせるかを見るほうが設計を理解しやすいと感じます。 評価では、グラフなしの全体要約も比較する 原論文v2は、ニュースとポッドキャストの二つの資料群に対して、LLMで作った各125問の全体理解を問う質問を使っています。包括性と多様性ではベクトルRAGに対する改善を報告していますが、簡潔で直接的な回答ではベクトルRAGが優位でした。 さらに、グラフを作らず元の文章を分割して要約・統合する方法も比較しています。この比較は、全体を扱った効果と、グラフを使った効果を考えるうえで重要です。 自分の用途で試すなら、以下の比較を置きたいと考えます。これは筆者の評価案です。 比較対象 確かめたいこと 負担・弱点 関連文章を取得するRAG 小範囲の根拠で答えられるか 全体の論点が抜ける可能性 元文章の分割要約と統合 グラフなしでも全体質問に答えられるか 質問ごとに広い文章範囲を処理する負担 GraphRAGのGlobal Search 事前要約の再利用と回答品質が両立するか 抽出・要約の準備と更新管理 評価点も一つにまとめず、根拠との一致、論点の取りこぼし、応答時間、初回準備、資料更新時の負担を分けます。包括性の評価が高いことを、そのまま事実の正確性や捏造率の改善とは扱えません。原論文も一般化や捏造率の比較に追加検証が必要だとしています。原論文v2・評価と限界 所感：モデルの前に、文脈を作る処理を設計する この論文で参考になるのは、全体を問う質問のために、検索時に渡す文脈を事前処理から設計している点です。グラフを作っただけで回答が良くなるというより、関係をまとめた要約を、質問ごとの部分回答へ変換する構成に意味があります。 採用判断では、その構成が手元の質問に必要かを確かめたいです。担当者や日付を取り出す用途と、複数資料を横断する調査では、比較すべき品質も許容できる負担も変わります。 実装を利用する場合、公式READMEは索引作成が高コストになり得るため、小さく始めるよう案内しています。また、2026年9月14日の確認時点では保守中心の方針が記載されており、新機能追加や新しいプルリクエストの受け付けは行わないとされています。Microsoftが正式にサポートする製品ではないことも明記されています。Microsoft GraphRAG公式リポジトリ 参考資料 Darren Edgeほか：From Local to Global: A GraphRAG Approach to Query-Focused Summarization v2（CC BY 4.0） Microsoft GraphRAG：Dataflow Microsoft GraphRAG：Global Search Microsoft GraphRAG：Local Search Microsoft GraphRAG：公式リポジトリ

SciPhi-Chat: Training a Spatial Audio Agent for Question Answering, Dialogue, and Tool Use Spatial audio question answering requires associating sound identities with locations and reasoning about their relations. This paper introduces SciPhi-Chat, a spatial audio agent that answers questions, conducts multi-turn dialogue, and calls tools on first-order ambisonic recordings. The accompanying MASU benchmark contains 12,000 samples across 42 task categories, the widest task coverage of any spatial model, with real recordings and simulated audio scenes. SciPhi-Chat achieves a score of 44.9%, 7.4 percentage points above the previous state-of-the-art. On the external ASA-Bench, SciPhi-Chat achieves 74.5% azimuth and 60.0% elevation accuracy, the highest among locally evaluated models. Removing reasoning supervision reduces ASA-Bench accuracy by 17.4 percentage points. All materials will be released via microsoft/sciphi-chat

GeoFaham: Domain-Specialized Multi-Agent Geospatial Analytics for Disaster Response Real-world geospatial decision support requires more than single-step retrieval or code generation. Disaster-response questions often involve multi-source workflows that combine spatial databases, map-derived features, satellite imagery, raster products, and reusable geospatial artifacts, where correctness depends on preserving spatial scope, temporal context, and intermediate execution state. While large language models and coding agents offer a promising interface for such workflows, they struggle with geospatial-specific failure modes, including handling large artifacts, selecting the wrong evidence source, losing spatial or temporal metadata, and applying invalid geometric operations. We introduce GeoFaham, a domain-specialized multi-agent system for geospatial disaster analytics. GeoFaham decomposes workflows into specialist agents for vector operations, map feature retrieval, imagery discovery, and raster analysis, coordinated by an Orchestrator with a dual-ledger control loop for dependency-aware planning, progress tracking, validation, and replanning. To support artifact-centric collaboration, GeoFaham uses a Response Store that persists full geospatial outputs and typed metadata outside the LLM context window while agents exchange compact identifiers and summaries. We also introduce GeoFaham-Bench, a 40-task benchmark grounded in 17 real-world disaster records, designed to evaluate multi-step geospatial reasoning, cross-source integration, raster-vector computation, artifact generation, and recovery under non-rigid ground truth. We evaluate GeoFaham on GeoFaham-Bench against strong general-purpose coding-agent baselines, including Codex, Claude Code, and OpenCode. GeoFaham achieves the best overall performance, scoring 0.940 versus the next-best 0.879, while using 7.5 times fewer tokens. Our code and benchmark are publicly available at microsoft/GeoFaham.

Crop Mapping Evaluation under Sampling Bias Government agencies use crop maps to estimate production, monitor food security, and set agricultural policy. These crop maps are usually validated against field labels, but these labels are rarely a random sample of the area the map covers. Field teams tend to label parcels near roads and skip ones that are small or hard to reach, so performance measured on held-out labels mainly describes the places they visited. We call the difference between this reported performance and performance over the whole mapped region the deployment performance gap. To estimate performance over the whole region, we use a weighted form of prediction-powered inference (PPI). The classifier's predictions on unlabeled points across the region give a first estimate, and its errors on the labeled points correct that estimate, with more weight on labels from under-sampled conditions. We test this in five European regions where crop registers label every declared parcel, so the true performance is known. Simulating six documented collection practices there produces gaps of up to 0.20 macro-F1. On the collection rule that creates the largest gap in each region, 5 km block cross-validation still overestimates macro-F1 by as much as 0.18, while PPI with weights estimated from satellite embeddings reduces the largest error across regions to 0.07. Importance-weighted cross-validation with the same weights does almost as well, so most of the improvement comes from the weights themselves. We also apply the method to three Kenyan datasets that have no region-wide reference labels. For a roadside dataset collected with helmet-mounted cameras, the estimated macro-F1 falls from 0.93 under random cross-validation to 0.61, although the correction relies on a small number of heavily weighted labels. Our code is available at microsoft/pappi. Comments: 17 pages, 4 figures, 5 tables. Code: microsoft/PaPPI

.NET 8・.NET 9のサポート終了は2026年11月10日｜同日終了の理由と.NET 10への移行ガイド Microsoftは標準期間サポート（STS）の期間を18か月から24か月に延長しました。その結果、.NET 9は.NET 8と同じ2026年11月10日にサポートが終了します。本記事では、その理由と.NET 10へのアップグレード方法を解説します。 .NET 9のサポートは2026年11月10日に終了します。.NET 8も同じ日です。残りは3週間を切りました。.NET 8は2023年11月14日にリリースされた長期サポート（LTS）版、.NET 9はその1年後の2024年11月12日にリリースされた標準期間サポート（STS）版です。この2つが同じ日にサポート終了を迎えます。誤植ではありません。11月10日以降にサポートされるバージョンは.NET 10で、LTSとして2028年11月14日までサポートされます。 2026年11月10日に.NET 8と.NET 9で何が終わるのか？ 終わるのはサービシング（保守提供）です。.NET BlogでRahul Bhandari氏が公表した告知によると、Microsoftは.NET 8と.NET 9に対する「サービシング更新、セキュリティ修正、技術サポート」を終了します。 アプリケーションは引き続き動作します。自動でアンインストールされることもありません。ランタイム、SDK、コンテナイメージもダウンロードできます。ただし、今後は修正が提供されなくなります。 11月10日はパッチ・チューズデーでもあります。Microsoftによると、既知の重大な問題がある場合に限り、.NET 8と.NET 9は同日に最後の更新を1回ずつ受け取る可能性があります。それ以降は、ランタイム、ASP.NET Core、基底クラスライブラリ（BCL）に影響する新たなCVEはすべて自己責任で対処することになります。 本記事執筆時点の最新パッチは8.0.32と9.0.21で、どちらも2026年10月13日にリリースされています。これらを適用していない場合は、期限を迎える前から対応が遅れている状態です。 ツール面にも影響があります。今後のVisual Studio 2022のサービシング更新で、.NET 8と.NET 9のコンポーネントがサポート終了として扱われるようになります。Visual Studioは更新時に、サポート終了のコンポーネントの削除を提案します。ビルドエージェントでこの設定を事前に確認しておきましょう。 なぜ.NET 9は.NET 8と同じ日にサポートが終わるのか？ .NET 9のサポート期間中に、MicrosoftがSTSのライフサイクルを変更したためです。 旧ポリシーでは、STSのサポート期間は18か月でした。これは次のリリースから6か月後にあたります。.NET 9は2026年5月12日にサポートが終了する予定でした。 2025年9月16日、.NET BlogでJamshed Damkewala氏が、STSリリースのサポート期間を24か月に延長すると発表しました。.NET 9から適用されます。LTSは従来どおり3年です。これにより、.NET 9のサポート終了日は2026年5月12日から2026年11月10日に移り、.NET 8の終了日とちょうど重なりました。 STSを24か月に延ばしたことで、STSリリースの終了日は直前のLTSリリースと同じになります。STS版の依存関係を使っていても、LTS版アプリと同じ日にサポートが終わる形です。なお、.NET Aspireのようなアウトオブバンド（OOB）コンポーネントは独自のライフサイクルを持つため、別途確認が必要です。 実際の問題を解消する、妥当な見直しだと私は考えています。一方で、副作用として2つのリリースが同じ日にサポートカレンダーから外れることになりました。.NET 9の終了を2026年5月と見込んで計画していた方は、6か月の猶予が増えていたことに気づいていないかもしれません。 この構造は今後も繰り返されます。偶数番号のLTSは11月にリリースされ、3年間サポートされます。奇数番号のSTSは翌年の11月にリリースされ、新ポリシーでは2年間サポートされます。どちらも同じ11月に終了します。.NET 10と.NET 11も、2028年11月に同じ日にサポートが終わると私は見ています。今回は例外ではなく、これからの標準パターンです。 各.NETバージョンのサポート状況は？ 出典: .NET and .NET Core Support Policy（2026年10月19日時点） どのバージョンにアップグレードすべきか？ .NET 10です。 現行のLTSリリースで、2028年11月14日までサポートされます。24か月のSTSポリシーのもとでは、.NET 11を待っても猶予は延びません。得られるのは、同じ月にサポートが終わると私が見ている、より新しいリリースだけです。 .NET 9をお使いなら、.NET 10へは1バージョン上げるだけで、多くの場合は小規模な変更で済みます。.NET 8をお使いなら、2リリース分の破壊的変更をまたぐため、工数を多めに見込んでください。ASP.NET Coreアプリは、ASP.NET Core 9から10への移行ガイドも確認しておきましょう。 最も単純な場合、アップグレードは各プロジェクトファイルの1行の変更です。 net10.0 ただし、この1行で済むことはまれです。実際の作業は次のような部分に生じます。 - 互換リリースが必要なNuGetパッケージ - 古いSDKを固定しているglobal.json - mcr.microsoft.com/dotnet/aspnet:8.0を参照しているDockerfile - 新しいランタイムのインストールが必要なCI/CDパイプラインとホスティング環境 自社で運用していても開発はしていないサードパーティ製アプリケーションについては、ベンダーに.NET 10対応版のリリースを問い合わせてください。 GitHub Copilotで.NET 10にアップグレードするには？ .NET Upgrade Assistantは使いません。Microsoftのドキュメントでは、「.NET Upgrade Assistant is officially deprecated.」と明記されています。サポート終了の告知にはまだリンクが残っていて紛らわしいのですが、このツールは後継に置き換えられています。 後継はGitHub Copilot upgrade agentです。ソースコードとプラグインはmicrosoft/upgrade-agent-pluginsにあります。Mika Dumont氏がModernize .NET Anywhere with GitHub Copilotで使い方を解説しています。 作業は3つの段階で進みます。各段階の成果物はリポジトリの.github/upgrades/配下にMarkdownファイルとして出力されるので、レビューやコミットが可能です。 1. 評価（Assess）: プロジェクトと依存関係を調べ、assessment.mdを出力します。破壊的変更、API互換性の問題、非推奨パターンが一覧化されます。 2. 計画（Plan）: plan.mdを出力します。アップグレード戦略、依存関係の順序、リスクが記載されます。 3. 実行（Execute）: 計画をtasks.mdのタスクに分割して順に実行し、作業単位ごとにGitコミットを作成します。検証やロールバックを段階的に行えます。 利用できる環境は4つあります。普段使っているものを選んでください。 - Visual Studio: Visual Studio 2026、またはVisual Studio 2022 17.14.16以降で、ソリューションエクスプローラーのソリューションまたはプロジェクトを右クリックし、Modernizeを選択します。 - VS Code: GitHub Copilot upgrade extensionをインストールし、Copilot ChatのエージェントピッカーでUpgradeを選択します。 - GitHub Copilot CLI: 次のコマンドを実行します。 /plugin marketplace add microsoft/upgrade-agent-plugins /plugin install upgrade-agent@upgrade-agent-plugins /agent Upgradeを選び、「upgrade my solution to .NET 10」のように指示します。 - GitHub: Copilotクラウドエージェントとして追加すると、プルリクエストを自動で作成できます。手順はクラウドエージェントのREADMEを参照してください。この方法には、クラウドエージェントが使える有料のCopilotプランと、リポジトリへの書き込み権限が必要です。 どの方法を選ぶにしても、次の点をおすすめします。 - 最初は、モノリスではなく小さなライブラリやサービスから始めましょう。自社のコードベースでエージェントがどこでつまずくかを把握できます。 - 大規模なコードでは、ガイドモード（Guided）を使いましょう。「pause」でガイドモードに、「continue」で自動モードに戻せます。 - 最後にまとめてではなく、コミットごとにテストスイート全体を実行しましょう。タスクごとにコミットされるため、コストを抑えられます。 - 完了後は、次のコマンドで結果を確認しましょう。 dotnet --list-runtimes dotnet list package --outdated 大規模なレガシーソリューションでは、エージェントが自力で最後までやり遂げられるとは限りません。大きなアプリで処理が止まるという初期ユーザーの報告もあり、Microsoftがリポジトリでフィードバックを集めています。移行の全工程ではなく、非常に速い初回パスとして使ってください。 2026年11月10日までに.NET 8・.NET 9からアップグレードできない場合は？ その場合は、運用中のバージョンにパッチを提供してくれる存在が必要です。 HeroDevsのNever-Ending Support（NES）for .NETは、.NET 6、.NET 8、.NET 9をそのまま置き換えられる、安全なドロップイン代替です。ランタイム、ASP.NET、Entity Framework、.NET SDK、WPF、WinFormsを対象とし、NES for .NET Containersを使えばコンテナイメージもカバーします。コードの変更は不要です。 HeroDevsは.NET Security Groupのメンバーです。そのため、.NETに影響する脆弱性の事前開示を受け、MicrosoftのパッチTuesdayのリリースと同時に、EOLバージョン向けの修正済みビルドを提供できます。 これは仮定の話ではありません。.NET 6は2024年11月12日のサポート終了以来、HeroDevsがパッチを提供し続けています。System.Net.MailのSMTPインジェクションの脆弱性であるCVE-2026-32178では、.NET 6に上流の修正が提供されませんでしたが、NESのお客様には修正が提供されました。2026年11月11日からは、.NET 8と.NET 9もこの対象に加わります。 NESは.NET 10への移行の代わりにはなりません。移行のスケジュールを、パッチ・チューズデーではなく、エンジニアリングチームが決められるようになるということです。 よくある質問（FAQ） .NET 8と.NET 9のサポートが終了するのは正確にいつですか？ どちらも2026年11月10日です。この日はパッチ・チューズデーで、既知の重大な問題がある場合に限り、Microsoftが各バージョンに最後の更新を1回提供する可能性があります。 .NET 9は2026年5月にサポート終了の予定ではなかったですか？ はい、旧ポリシー（STS 18か月）では2026年5月12日でした。Microsoftが2025年9月16日にSTSを24か月に延長し（.NET 9から適用）、終了日が2026年11月10日に移りました。 .NET 8や.NET 9のアプリケーションは動かなくなりますか？ いいえ、引き続き動作します。ただし、Microsoftからのセキュリティ修正、バグ修正、技術サポートは提供されなくなります。 .NET Upgrade Assistantはまだサポートされていますか？ いいえ。MicrosoftはGitHub Copilot upgrade agentに置き換える形で非推奨としました。後継はVisual Studio 2026とVisual Studio 2022 17.14.16以降に付属し、VS Code、Copilot CLI、GitHubでも利用できます。 .NET 10ではなく.NET 11を待つべきですか？ いいえ。.NET 11はSTSリリースで、24か月ポリシーのもとでは.NET 10と同じ2028年11月ごろにサポートが終了する見込みです。.NET 10はすでに利用でき、より安全な移行先です。 HeroDevsは11月10日以降も.NET 9をサポートしますか？ はい。NES for .NETは、.NET 6、.NET 8、.NET 9をカバーします。 11月10日の期限までにアップグレードが間に合わない場合 .NET 10への移行が2026年11月10日に間に合わないアプリケーションについては、NES for .NETが.NET 6、8、9にパッチを提供し続け、監査対応も維持します。その間に、慌てず適切に移行を進められます。保証範囲についてはHeroDevsにお問い合わせください(日本語で対応可能です）。 --- お問い合わせ 本記事の内容やHeroDevsのソリューション（NES等）について、日本語でのお問い合わせに対応しています。お気軽にHeroDevsお問い合わせページからご連絡ください。 --- 原文: herodevs.com （出典: herodevs.com）

Microsoft.UI.Reactorを学習する Microsoft.UI.Reactorとは Microsoft.UI.Reactor は、C#で WinUI アプリを宣言的に作る実験的なフレームワークです。 ※2026/11/01時点で 0.1.0-preview.16 版です。 試す プロジェクトを作成する winget install Microsoft.WinAppCli winapp new -t reactor -n Kashin777.UI.Reactor cd Kashin777.UI.Reactor 構成 !image.png csproj(抜粋) <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <!-- Windows GUI アプリとしてビルド --> <OutputType>WinExe</OutputType> <!-- .NET 10 と Windows SDK 10.0.26100.0 を対象にする --> <TargetFramework>net10.0-windows10.0.26100.0</TargetFramework> <!-- サポートする Windows の最低バージョン --> <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion> <SupportedOSPlatformVersion>10.0.17763.0</SupportedOSPlatformVersion> <!-- WinUI アプリとしてビルドし、MSIX のビルド機能を有効にする --> <UseWinUI>true</UseWinUI> <EnableMsixTooling>true</EnableMsixTooling> <!-- C# の基本設定 --> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <!-- Windows アプリのビルドに必要なパッケージ --> <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="*" /> <PackageReference Include="Microsoft.WindowsAppSDK" Version="*" /> <PackageReference Include="Microsoft.Windows.SDK.BuildTools.WinApp" Version="*" /> <!-- Microsoft.UI.Reactor --> <PackageReference Include="Microsoft.UI.Reactor" Version="0.1.0-preview.16" /> </ItemGroup> </Project> App.cs using Microsoft.UI.Reactor; using Microsoft.UI.Reactor.Core; using Microsoft.UI.Reactor.Layout; using Microsoft.UI.Xaml; using Microsoft.UI.Xaml.Controls; using static Microsoft.UI.Reactor.Factories; // To learn more about Reactor, the Reactor project structure, and more about // our project templates, see: https://github.com/microsoft/microsoft-ui-reactor ReactorApp.Run<App>("Kashin777.UI.Reactor"); class App : Component { public override Element Render() { var titleBar = TitleBar("Kashin777.UI.Reactor") .Flex(shrink: 0); // This is the main content area of your application. // Add your UI elements here. var content = Border(Empty()).Flex(grow: 1, basis: 0); return FlexColumn(titleBar, content) .Backdrop(BackdropKind.Mica); } } とりあえず実行 dotnet run !image.png 画面を実装する 公式ドキュメントのCounter Example に従い、App.cs を修正してみます。 public override Element Render() { var titleBar = TitleBar("Kashin777.UI.Reactor") .Flex(shrink: 0); var (count, setCount) = UseState(0); // countプロパティとsetterを作成 var content = VStack(spacing: 12, // Vertical StackElement TextBlock($"Count: {count}").FontSize(20).SemiBold(), // element[0] TextBlock HStack(spacing : 8, // element[1] Horizontal StackElement Button("- 1", () => setCount(count - 1)), // 1デクリメント Button("Reset", () => setCount(0)), // リセット Button("+ 1", () => setCount(count + 1)) // 1インクリメント ) ).Padding(24); return FlexColumn(titleBar, content) .Backdrop(BackdropKind.Mica); } dotnet run !image.png 基礎 フック フック インタラクティブなUIには必ず状態が必要です。Reactorでは、状態はUseState時間とともに変化する値を管理するための主要なフックです。 コンポーネントは複数回呼び出すことができUseState、各呼び出しは独立した値を追跡します。 var (count, setCount) = UseState(0); var (firstName, setFirstName) = UseState(""); var (fontSize, setFontSize) = UseState(16.0); | フック | 戻り値 | 目的 | |--|--|--| | UseState | (T value, Action<T> set) | リアクティブな状態 — set 時に再レンダリングされます。 | | UseReducer | (T value, Action<Func<T,T>> update) または (TState, Action<TAction>) | 関数型または Redux スタイルの更新。 | | UseEffect | void | コミット後の副作用。Func<Action> オーバーロードを使用すると、次のエフェクトの実行前およびアンマウント時にクリーンアップが実行されます。 | | UseMemo | T | 計算結果のキャッシュ。依存項目のいずれかが不等となった場合に再実行されます。 | | UseRef | Ref<T>（mutable .Current 付き） | 変更時でも再レンダリングを行わずに、レンダリング間を通じて状態を保持します。 | | UseCallback | Action | レンダリング間を通じて安定したデリゲート識別子。 | | UseContext | T | 周囲の Context 値を読み取ります。 | | UseObservable | T | 追跡対象の INotifyPropertyChanged ソースが変更を発生させた際に再レンダリングを行います。 | | UseExternalStore | TSnapshot | subscribe/getSnapshot ストアを Reactor にブリッジし、スナップショットが変更された場合にのみ再レンダリングします。 | | UseResource | AsyncValue<T> | キャッシュされた非同期読み取り（「非同期リソース」を参照）。 | | UsePersisted | (T, Action<T>) | プロセス内のアンマウント/リマウント後も存続する UseState — メモリ内、終了時にクリアされます（「永続性」を参照）。 | レイアウト レイアウト | 要素 | 目的 | |--|--| | VStack | 縦積み（上から下へ子要素を配置） | HStack | 水平スタック（左から右へ） | Grid | 行/列グリッド（比例サイズ） | ScrollView | オーバーフローコンテンツ用のスクロール可能なラッパー | Border | 背景、角丸、ストローク付きコンテナ コントロール コントロールカタログ | カテゴリ | 中身は？ | |--|--| | フォーム | テキスト入力、ピッカー、ボタン、検証プリミティブ | | コレクション | リスト、グリッド、仮想化リスト、リピーター | | テキストとメディア | 見出し、リッチテキスト、画像、メディアプレーヤー | | ステータスと情報 | 進捗状況、情報バー、バッジ、指導のヒント | | レイアウトとコンテナ | スタック、グリッド、境界線、スクロールホスト、ペイン | | ナビゲーション | ナビゲーションビュー、フレーム、タブ、パンくずリスト、ピボット | | 図形とアイコン | 長方形、楕円、線、パス、アイコンのソース | | ダイアログとフライアウト | コンテンツダイアログ、メニューフライアウト、コマンドバーフライアウト | | データシステム | DataGrid、列、データソース、ページング | | チャート作成 | 線グラフ、棒グラフ、面積グラフ、円グラフ、力グラフ | ホットリロード ホットリード dotnet watch run アプリを起動したまま、ボタンのラベルを変更して保存したら PS C:\Users\Kashin777\source2\repos\Kashin777.UI.Reactor> dotnet watch run dotnet watch 🔥 Hot reload enabled. For a list of supported edits, see https://aka.ms/dotnet/hot-reload. dotnet watch 💡 Press Ctrl+R to restart. 復元が完了しました (0.0 秒) 0.1 秒後に 成功しました をビルド info NETSDK1057: プレビュー版の .NET を使用しています。https://aka.ms/dotnet-support-policy をご覧ください Kashin777.UI.Reactor net10.0-windows10.0.26100.0 win-x64 成功しました (0.4秒) → bin\Debug\net10.0-windows10.0.26100.0\win-x64\Kashin777.UI.Reactor.dll 0.5 秒後に 成功しました をビルド dotnet watch ⌚ Loading projects ... dotnet watch ⌚ Loaded 1 project(s) in 0.5s. C:\Users\Kashin777\source2\repos\Kashin777.UI.Reactor\Properties\launchSettings.json からの起動設定を使用中... ⠼ Launching packaged application... ✅ 43A37F59-B43C-4C5A-9E09-1DE873E18ECA_1z32rh13vfry6 launched (PID: 22536) dotnet watch ⌚ File updated: .\App.cs dotnet watch ⚠ [Kashin777.UI.Reactor (net10.0-windows10.0.26100.0)] Further changes won't be applied to this process. ドキュメントに従い dotnet watch run で起動したのですが、App.cs の変更は検知されるもののリロードされず...

u know i completely forgot i ever wrote this comment. what the hell TypeScript#33304