Microsoft

DockerでPlaywrightのChromium Sandboxを有効化するためにはseccompプロファイルを作る必要がある はじめに Playwrightは、Node.jsなどからChromiumなどのWebブラウザを操作できる自動化ライブラリです。End-to-EndなWebテストに使われるほか、スクレイピングやクローリングなどでも使われます。 スクレイピングやクローリングなど、アクセス先のWebページが信頼できるとは言い切れない場合、Webブラウザ自体のセキュリティ機構であるChromium Sandboxの有効化が重要です。chromium.launch()のchromiumSandboxオプションを使いましょう。（デフォルトではfalseです。） import { chromium } from "playwright"; await using browser = await chromium.launch({ chromiumSandbox: true, }); DockerでchromiumSandboxを有効化するとエラーに Dockerコンテナ内で上記のコードを実行すると、（環境によりますがおそらく）Chromiumの起動に失敗します。これは、Chromium SandboxがLinuxのユーザー名前空間などの機能を利用するのに対して、Dockerのデフォルトのseccompプロファイルがそのためのシステムコールを制限しているためです。 seccomp（Secure Computing Mode）はLinuxカーネルのセキュリティ機能です。プロセスが実行できるシステムコールを制限し、プロセスがカーネルに対して実行できる操作を制御します。Dockerでは、コンテナのセキュリティを確保するためにデフォルトのseccompプロファイルが適用されます。このプロファイルは許可リスト方式になっており、明示的に許可されていないシステムコールは原則として拒否されます。 ChromiumがSandboxのためにユーザー名前空間を利用しようとした際にseccompによってシステムコールが拒否され、プロセスが異常終了するわけです。 Playwright公式のseccomp_profile.jsonには注意 PlaywrightのDockerについてのドキュメントでは、Chromium Sandboxを利用するためのPlaywright公式のseccompプロファイルが紹介されていますが、これは2020年7月のPR #3077で追加されて以降、一度も更新されておらずもう使えません。 ↓これすらSIGSEGVで失敗します。 docker container run --rm --security-opt seccomp=seccomp_profile.json alpine echo ok 現在利用しているDockerのデフォルトseccompプロファイルをベースに自分で作るとよいでしょう。リンク先より取得したJSONのトップレベルにあるsyscalls配列に以下の許可ルールを追加してください。 { "comment": "Allow create user namespaces", "names": [ "clone", "setns", "unshare" ], "action": "SCMP_ACT_ALLOW", "args": [], "includes": {}, "excludes": {} } その他 Playwrightのドキュメントでは、コンテナ内で非rootユーザーでWebブラウザを起動することも推奨されています。

LLMが改善したスキルは、別のLLMにも効く？ ローカル3系列でSkillOptを検証 はじめに こんにちは。株式会社SCIEN MLエンジニアの河合です。 モデルを更新したとき、以前のモデルに合わせて調整したプロンプトを、そのまま使っていませんか？ 時間をかけて調整したプロンプトは、モデルのバージョンアップや別モデルへの切り替え後も使い続けたいものです。ただ、以前のモデルで効果があった指示が、新しいモデルでも役立つとは限りません。 そこで調べたのが、あるLLMに合わせて調整したプロンプトは、別のLLMでも役立つのか？ という点です。モデルを切り替えるたびに指示を調整し直す必要があるなら、運用の仕方も変わります。 今回は、スキルをLLM自身に改善させるSkillOpt1を使いました。モデルの重みを変えず、実行結果を見ながらスキルを更新します。 SCIENでは以前、LLMによる自動プロンプト最適化を紹介しました。今回はそこから少し問いを変えて、改善したスキルを、更新元とは別のモデルに渡す実験です。 今回は、Qwen・Gemma・Mistralの3系列で最適化したスキルが、別のモデルでも役立つかをALFWorldで検証します。 仮説：同じ系列なら、スキルも引き継ぎやすい？ LLM研究では、QwenやGemmaのような系列をモデルファミリーとして扱います。同じ開発元や構造を持つモデルでは誤りが似る傾向2が、特定のファミリー内では画像キャプションの採点で互いの出力を好む傾向3が報告されています。 これらを手掛かりに、同じ系列のLLMどうしなら、最適化したスキルを転用したときに改善が出やすいのではないかと考えました。今回は、この仮説をALFWorldで検証します。 SkillOptとは SkillOpt1:1は、実行履歴と採点結果から、スキルへの追記・削除・置換の候補を作ります。編集量には上限を設け、採否判定用の問題（val）で評価が上がった候補を採用します。 今回動かした流れは、次の4段階です。 初期スキルを用意する。 全モデルで同じスキルを出発点にする。 タスクを解いて、失敗を集める。 trainの問題を実行し、失敗した実行履歴を編集の材料にする。 LLMに修正候補を作らせる。 タスクを実行したモデル自身に、注意事項の追記や書き換えを提案させる。 別の問題で比べて、採用する。 val成功数が現在のスキルを上回った場合だけ置き換える。同点や悪化なら現在のスキルを残す。 2〜4を最大4ラウンド繰り返し、最後に残った採用スキルを比較します。最後に提案された候補が、そのまま最終スキルになるわけではありません。 更新するのは、プロンプトに組み込むスキル部分です。タスク指示や出力形式のルールは固定し、モデルの重みも変更しません。 図1：SkillOpt全体フロー 実験：ALFWorldで6モデルにスキルを渡す ALFWorldは、部屋を移動し、物を探したり運んだりする環境です。今回はテキスト環境を使いました。モデルは観測文と、その時点で選べる操作の一覧を受け取り、次の操作を返します。画像をモデルに入力する実験ではありません。 図2：ALFWorld 出典：ALFWorld公式リポジトリの説明図 物を置く・洗う・温めるなど、6種類のタスクを評価しました。 比較したモデル Qwen・Gemma・Mistralの3系列、計6モデルを比較しました。 系列 使用モデル Qwen Qwen3.5-9B、Qwen3.5-27B、Qwen3.6-27B Gemma Gemma 4 12B、Gemma 4 31B Mistral Mistral Small 3.2-24B 比較したスキル条件 共通の公式初期スキルから更新元モデルごとに最適化し、固定したスキルを各利用先モデルで評価しました。更新の効果は、初期スキルからの成功数の差で見ます。 条件 使用したスキル スキルなし 追加スキルなし 初期スキル 全モデル共通の公式スキル Qwen更新 Qwen3.6-27Bで最適化 Gemma更新 Gemma 4 31Bで最適化 Mistral更新 Mistral Small 3.2-24Bで最適化 GPT公開 公式公開のGPT-5.5スキル GPT公開は、最適化条件が異なる参考条件です。 評価方法 train・val・testは各12問（6種別×2問）です。trainの実行履歴から編集候補を作り、val成功数が上がった場合だけ採用します。各更新元モデルで連続4ラウンド・1試行を行い、最終採用スキルをtestで比較しました。 結果：系列をまたいで効くことも、自分に戻して下がることもあった 6モデルにおけるスキル別のtest成功数 図3：破線は初期スキルの成功数、括弧はそこからの増減。各条件12問・1回。 GemmaのスキルでQwenが改善した Gemma 4 31Bが更新したスキルをQwen3.5-27Bに渡すと、9/12→11/12でした。初期スキルで失敗していた2問が成功に変わり、成功から失敗へ変わった問題はありませんでした。 一方、更新元モデルのGemma 4 31B自身では、初期スキルでも更新スキルでも10/12です。更新元モデルでのtest改善がなくても、別モデルでは成功が増える例がありました。 同じ系列への転用も一様ではなかった Qwen3.6-27Bの更新スキルは、Qwen3.5-27Bでは9/12→10/12、Qwen3.5-9Bでは6/12→5/12でした。同じQwen系列でも方向が分かれています。 Gemma 4 31Bの更新スキルも、同じ系列のGemma 4 12Bでは8/12→8/12です。今回の範囲では、同じ系列へ渡す方が一貫して有利、という傾向は確認できませんでした。 Mistralが作ったスキルは、Mistral自身よりQwenに効いた Mistral Small 3.2-24Bの更新スキルでは、Qwen3.5-9Bは6/12→8/12、Qwen3.6-27Bは8/12→9/12でした。一方、Mistral自身は2/12→1/12です。更新元モデル自身で改善しなくても、別の系列では成功数が増える例がありました。 最終スキルは、どう書き変わったのか 数字だけでは、何を改善したのかが見えません。そこで、実際の評価に使った最終採用スキルを、初期スキルと比べてみます。いずれも英語で書かれており、以下の説明は日本語での要約です。 Qwenは探索や操作の確認、Gemmaは状態の制約を具体化した 初期スキルは2,966文字で、6タスクの基本手順と、「探索済みの場所に戻らない」「選べる操作から選ぶ」といった注意事項があります。これを共通の出発点にすると、最終スキルは次のようになりました。 更新元モデル 採用回数 最終スキルの文字数 初期スキルからの主な変更 Qwen3.6-27B 3回 4,766 食品・掃除用品・食器ごとに探す場所の優先順を追加。現在地への再移動を避け、操作文字列を現在の一覧と照合する。1個ずつ運ぶ制約や、完了後に操作を続けない注意も追加 Gemma 4 31B 1回 3,378 操作一覧が毎回変わることを明記し、直近の一覧との照合を強調。2個目を取る前に1個目を目的地へ置くよう追記 Mistral Small 3.2-24B 1回 3,323 取得前に目標と同じ物か確認し、不確かなら調べる。容器を開けて確認する注意を再掲し、目標に必要がなければ閉め直さないよう追記 Qwen3.5-27B 0回 2,966 全候補が不採用となり、初期スキルから変更なし Gemmaのスキルには「2個目を取る前に1個目を置く」が追記されました。そのスキルを使ったQwen3.5-27Bでは、以前失敗していた「CDを2枚、金庫に入れる」に成功しました。 参考条件のGPT公開スキルは13,175文字で、探索済みの場所を記録し続ける方法、探索先を切り替える条件、2個目を取りに行くときの記憶の引き継ぎなどが詳しく書かれています。今回のローカル最適化とは条件が異なり、長さも揃えていません。Gemma 4 12Bでのtestは初期スキル8/12に対してGPT公開6/12だったので、詳しく長く書かれていれば、そのモデルでも役立つとは限りません。 「選べる操作から選ぶ」を、もう一段具体的にする Gemmaが書き換えた箇所を見ると、違いが分かりやすいです。初期スキルの「操作一覧から選ぶ」が、「直近の操作一覧を確認し、以前選べた操作を使い回さない」という注意に変わっています。 以下は原文の差分です。見出しを省き、長い行を文ごとに改行しています。 - Always pick an action from the admissible action list. Do not invent actions. - The list of available actions changes every step based on your location and state. - You MUST verify that your chosen action is present in the most recent admissible action list provided in the observation. - Never assume an action remains available from a previous step. 操作一覧を参照するルール自体は最初からありました。採用された編集は、いつの一覧を見るかまで明確にしています。最終スキルを読むと、成功数の変化だけでは分からない、注意事項の具体化が見えてきます。 ただし、スコアが上がったスキルも、読みやすく整形されるとは限りませんでした。Qwenでは表の途中に注記が入り、Mistralでは番号3と4の間に番号9が挿入されています。評価には、整形し直す前のスキルをそのまま使っています。 関連研究 モデル系列に関する研究では、PhyloLM4が出力の類似性からモデルの系譜を推定し、Correlated Errors in Large Language Models2:1が開発元や構造の共通性と、誤りの重なりの関係を調べています。MLLM-as-a-Judge Exhibits Model Preference Bias3:1は、画像キャプションの採点で、一部の系列内に互いの出力を好む傾向があることを報告しています。 スキルの転用については、SkillOpt1:2で、SpreadsheetBenchのGPT-5.4用スキルをmini・nanoへ渡し、スキルなしと比べた改善が報告されています。SkillLens5でも、同じスキルの効果が利用先モデルによって変わることが示されています。 やってみてわかったこと スキルの相性は、系列だけでは判断できなかった 本記事では「同じ系列のLLMどうしなら、スキルも転用しやすいのではないか」という仮説を置きました。しかし、同じQwen内でも改善と悪化が分かれ、異なる系列のGemmaやMistralのスキルがQwenに役立つ例もありました。 印象的だったのは、更新元モデル自身のtest成功数が増えなくても、転用先では増える場合があったことです。更新元での成績だけでは、他のモデルでの効果までは分かりません。 スキルを共有する範囲を系列名で決めるより、使いたいモデルで試してみる価値がありそうです。 当たり前に見える注意事項にも、具体化する余地があった Gemmaの編集は「操作一覧から選ぶ」を「直近の操作一覧と照合し、以前の操作を使い回さない」へ具体化していました。人間には似た指示に見えても、いつの情報を確認するかまで書くと、実行時に求める判断が明確になります。 また、「物を1個ずつ運ぶ」のような環境の制約は、特定の系列に限らない内容です。こうした注意点の明示が、系列をまたいだ改善に関わっている可能性もあります。スキルの長さだけでなく、どの前提や確認手順が具体化されたかを読むと、編集の意図を追いやすくなります。 更新を繰り返しても、毎回採用されるわけではなかった 4ラウンドの最適化で、Qwen3.6-27Bは3回、Gemma 4 31Bは1回の編集を採用しました。一方、Qwen3.5-27Bでは全候補が不採用となり、初期スキルがそのまま残りました。 SkillOptは、valで改善を確認できた編集だけを採用します。元のスキルを残すことも、最適化の結果の一つでした。スキルを自動で更新する仕組みを使うときも、現在の版を保存し、変更前後の結果から採否を決める流れが役立ちそうです。 終わりに 今回は、SkillOptで最適化したスキルをローカルLLMの3系列・6モデルで評価しました。異なる系列でも役立つ組み合わせがあり、同じ系列への転用が一貫して有利になる結果にはなりませんでした。 冒頭の問いに戻ると、以前のモデルに合わせて調整したスキルは、モデルを切り替えた後も再利用の候補になります。 使うモデルで効果を確かめ、その結果から引き継ぐか、最適化し直すかを判断する。今回の検証を通じて、スキルもモデルと組み合わせて評価しながら育てていくものだと感じました。 ここまでお読みいただき、ありがとうございました。 SCIENでは、一緒に技術検証と開発に取り組むエンジニアを募集しています。興味を持っていただけた方は、採用ページをご覧ください。 scieninc.jp 補足 実行設定 項目 設定 GPU NVIDIA RTX PRO 6000 Blackwell 96GB、1枚 推論環境 Ollama 0.32.6 重みの数値形式 全6モデルでBF16 思考モード 無効 temperature / seed 0 / 42を基準に固定 1問の上限 / 保持履歴 50操作 / 最大50操作 コンテキスト上限 131,072トークン 出力上限 タスク実行4,096、スキル編集8,192トークン ローカル最適化 更新元モデルごとに4ラウンド・1試行、slow/meta updateなし 採用条件 val成功数の厳密な改善。同点は不採用 成功判定 ALFWorldの目標達成判定 無効な操作 現在の操作一覧にない操作を出すと、その問題を即終了 Mistralには第三者のBF16 GGUF変換を使用しました（正規化テンソルはF32）。モデルごとのチャットテンプレートとスキル長は異なります。 各条件は1回の評価です。過去の保存結果と追加計測を統合し、重複条件を独立な再試行には数えていません。追加比較では既に結果を確認した固定testを使っていますが、test結果によるスキルの再編集は行っていません。 testの全数値 数値は12問中の成功数です。太字は初期スキルより成功数が多い条件です。全組み合わせを計測しています。 利用先モデル スキルなし 初期スキル Qwen更新 Gemma更新 Mistral更新 GPT公開 Qwen3.5-9B 5 6 5 6 8 7 Qwen3.5-27B 7 9 10 11 9 8 Qwen3.6-27B 6 8 9 9 9 8 Gemma 4 12B 3 8 8 8 8 6 Gemma 4 31B 7 10 10 10 10 10 Mistral Small 3.2-24B 2 2 3 2 1 2 valの全結果：採否判定時とは別の追加評価 固定したスキルをvalでも評価しました。valは候補の採否に使う既知の問題なので、未知問題への汎化とは区別します。 利用先モデル スキルなし 初期スキル Qwen更新 Gemma更新 Mistral更新 GPT公開 Qwen3.5-9B 3 4 5 4 4 7 Qwen3.5-27B 5 8 9 9 8 10 Qwen3.6-27B 7 7 11 9 8 6 Gemma 4 12B 2 3 8 6 4 6 Gemma 4 31B 6 9 11 10 10 10 Mistral Small 3.2-24B 1 1 3 2 3 3 例えばGemma 4 12BにGPT公開スキルを渡すと、valは3→6、testは8→6です。Qwen3.5-27Bでもvalは8→10、testは9→8でした。Mistral自身の更新スキルは、この再評価ではvalが1→3、testが2→1でした。 逆向きの例もあります。Mistral更新スキルをQwen3.5-9Bへ渡すと、valは4→4のまま、testは6→8でした。valが同じでもtestは変わるため、片方の結果だけで全体の効果を判断していません。 Qwen更新は、今回評価した6モデルすべてでvalが初期スキルを上回りました。一方、testで上回ったのは3モデルです。valへの適応、問題の難しさ、実行の揺らぎなどを切り分けてはいませんが、valの改善幅をそのまま汎化性能の改善幅に置き換えないようにしています。 4ラウンドの更新経過と採用回数 下表は、候補の採否を決めた時点の採用スキルのval成功数です。0ラウンドは初期スキルを表します。後からすべてのスキルを評価し直した上のval表とは別の記録です。 更新元モデル 0ラウンド 1ラウンド 2ラウンド 4ラウンド 採用回数 Qwen3.6-27B 7/12 9/12 9/12 11/12 3回 Gemma 4 31B 9/12 10/12 10/12 10/12 1回 Qwen3.5-27B 9/12 9/12 9/12 9/12 0回 Mistral Small 3.2-24B 2/12 3/12 3/12 3/12 1回 Qwen3.6-27Bでは3回の更新を採用しました。Gemma 4 31Bは最初の1回を採用し、2・4ラウンド目はtrainに失敗がなく候補を作らず、3ラウンド目は同点で不採用でした。 Qwen3.5-27Bは4つの候補がいずれもvalで8/12となり、初期スキルの9/12を上回らず不採用でした。最終採用スキルは初期スキルと同じです。なお、後の固定したスキルの評価では初期スキルが8/12となっています。 Mistralの候補valは順に3・2・2・3/12でした。最初だけ採用し、2・3回目は下回るため、4回目は同点のため不採用です。初期スキルの成功数は採否判定時が2/12、再評価が1/12であり、同じ測定値として混ぜていません。 4ラウンド回しても、4回改善するわけではありません。改善が確認できなければ元のスキルを残すことも、この最適化の一部です。 脚注 Yifan Yang et al. SkillOpt: Executive Strategy for Self-Evolving Agent Skills. arXiv 2026. ↩︎ ↩︎ ↩︎ Elliot Kim et al. Correlated Errors in Large Language Models. ICML 2025. ↩︎ ↩︎ Shuitsu Koyama et al. MLLM-as-a-Judge Exhibits Model Preference Bias. arXiv 2026. ↩︎ ↩︎ Nicolas Yax et al. PhyloLM: Inferring the Phylogeny of Large Language Models and Predicting their Performances in Benchmarks. ICLR 2025. ↩︎ Zisu Huang et al. From Raw Experience to Skill Consumption: A Systematic Study of Model-Generated Agent Skills. arXiv 2026. ↩︎

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

One thing I'm excited to have snuck into TypeScript 7.1 pre-RC is experimental Wasm support, both for wasip1 and the browser (and soon, vscode.dev). The entire TS 7.1 API works!. Sync, async, everything. Only _some_ Wasm executable surgery required! 😅 You can try it at npmjs.com.

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 の変更は検知されるもののリロードされず...