つづき@AIで業務改善

実家の固定電話、離れて暮らす家族でも国際電話の休止を申し込めます。 条件は、名義人本人の了承があること。現行の受付センターFAQは、住所が違う家族の申込みも可能と案内しています。Web・電話受付なら休止まで1週間程度が目安。申し込んだ瞬間に止まる手続きではありません。 総務省の「国際電話オプション化」の議論を見て、親の電話はどうすればいいのかと思った人へ。将来の制度案と、すでにある申込手続きは分けて考えられます。 ① まず、親の了承と電話の種類を確認 国際電話不取扱受付センターのFAQ9・10は、本人の了承があれば代理人による申込みができ、実家と住所が異なっていても申し込めるとしています。家族だから無断で止めてよい、という意味ではありません。 センターの受付対象は、03・06などから始まる10桁の固定電話。070・080・090の携帯電話や、050から始まる11桁のIP電話は対象外です。携帯電話は契約している携帯電話会社へ相談する案内です。 ② Web・電話・郵送で、かかる時間が違う 現行の申込方法は3つです。 ・Web：センター公式サイトで重要事項を確認して申込む ・電話：0120-210-364へ申込む ・郵送：公式サイトの申込書を印刷して送る 休止までの目安は、Web・電話受付が1週間程度。紙の申込書では数週間かかる可能性があります。休止自体は無料ですが、郵送の送料は申込者の負担です。 別の電話から電話申込みをする場合は、対象の固定電話への折り返し確認があります。FAQ19は、その電話を受け取れないと受付が完了しないため、Web申込か郵送を案内しています。遠方から手伝うなら、親が確認の電話に出られるかも先に相談したいところです。 ③ 正規の国際電話も止まる点に注意 センターは、迷惑な着信だけでなく、すべての国際電話の着信が休止されると説明しています。海外の家族・知人や仕事の連絡を受ける予定がある場合には、休止をおすすめしないという案内です。 重要事項では、着信だけを止めることはできず、国際電話の発信も関連します。発信休止の窓口は事業者で異なるため、契約回線の案内も確認してください。再開は可能ですが、センターでは電話での申込みとなり、利用できるまで日数がかかる場合もあります。 ④ オプション化は、まだ検討の論点 11月2日の総務省WG資料には、「休止を申し出た人だけ止める案」と「利用継続を申し出た人だけ残す案」が並んでいます。約款変更や関係法令との整理も論点です。 全国の固定電話がすでに自動で停止する、という決定や施行日を確認したものではありません。いま親と相談して進められるのは、上の現行手続きです。 11月2日に取得した公式資料の案内です。個別の受付完了日や、詐欺被害を完全に防ぐ効果を保証するものではありません。 現行の申込み・FAQ： kokusai-teishi.com/ 総務省・11月2日WG配布資料： soumu.go.jp/main_sosiki/kenk…

MCP攻撃、秘密の流出をどこまで確かめたか MCPでつないだ外部ツールの説明に指示を紛れ込ませると、AIは秘密を外へ送ってしまうのか。 11月2日（UTC）公開の論文は、12のフレームワーク・18モデル・45の攻撃シナリオを組み合わせて検証した。 「脆弱」判定は2,113件。そのうち、秘密を含む通信の受信までログで確認できたのは255件（12.1％）だった。12.1％は、脆弱と判定された2,113件を母数にした割合だ。 研究では、攻撃先に向けたツール呼び出し、攻撃先との通信、秘密の受信を、確認できた証拠の強さで分けて数えている。 ただし、研究者が管理する環境にテスト用の秘密を置いた制御実験だ。実測は2026年7月22〜24日の特定モデル・設定で行われた。現在のMCP全般の流出率を示す数字としては扱えない。 出典：arxiv.org/html/2611.03555v1

MetaのデザインシステムAstryx、部品と配色をまとめて使う仕組み 画面部品の見た目と動きを毎回一から組み立てるのは手間がかかります。Metaが公開しているAstryxは、その部品群と配色の仕組みをまとめたデザインシステムです。 社内で8年かけて育てられ、1万3000以上のアプリで使われてきたとREADMEは説明しています。現在はベータ版で、React 19以降が必要です。 READMEによると、150以上の画面部品があり、アクセシビリティにも対応しています。ビルド用プラグインやPostCSS、Babelの設定は要らず、CSSを読み込んでテーマを指定するのが基本です。色などをまとめて指定するCSS変数を上書きすれば、部品のコードを包み直さずに配色を変えられます。見た目の調整もTailwindやCSSモジュールなど既存の書き方をそのまま使える点が特徴です。 CLIでは部品の説明やひな形、テーマを扱えます。人とAIアシスタントが同じ資料と道具で開発できる設計です。 公式READMEに基づく紹介で、導入や動作は未検証です。 出典：github.com/meta/astryx/blob/…

アルツハイマー新薬、科学の進歩に届ける仕組みが追いつかず アルツハイマー病の検査や治療に進歩があっても、患者が受けられるとは限らない。 ビル・ゲイツ氏は10月30日の投稿で、科学の進歩を患者に届ける仕組みの遅れを問題にした。本人ブログでは、米国を中心とする検査・治療へのアクセスについて専門家と議論したと述べている。 同氏によると、専門家からは普及の遅さが指摘された。検査や治療の存在が医師・患者に十分知られていないこと、専門医の診察に数カ月待ち、治療開始が遅れる場合があることなどが障壁だという。保険適用の地域差や通院の負担、治験の参加者集めも課題に挙げた。 同氏は、企業や医療機関が連携して、こうした障壁を減らす体制を探っているとしている。 出典：gatesnotes.com/home/home-pag… 元投稿：nitter.gq/BillGates/status/21162…

量子もつれで森林グラフPIRの取得レートを改善 どのファイルが欲しいかを、保存先の各サーバーに知られずに取り出す「プライベート情報検索（PIR）」。 11月2日公開の論文は、ファイルを2台ずつに複製し、その配置が互いに独立した複数の木になる場合を扱う。サーバー同士は事前に量子もつれを共有し、各サーバーは1回の取得で1個のqudit（量子情報の単位）を送る。取得レートは3/N。Nはサーバー数で、レートは「欲しいデータの長さ÷受信するqudit数」だ。 比較対象は、既存の汎用グラフ方式を同じ設定に当てはめた2/Nで、単純計算では1.5倍になる。さらに、3本の独立した辺からなる小さなグラフでは、4/6というレートを達成する具体的手順と、それを超えない上界の両方を示し、容量を確定した。 すべての森林グラフの上限を確定したわけではない。量子もつれの事前共有と雑音のない通信を仮定した理論結果で、実機で速度を測った報告ではない。 出典：arxiv.org/html/2611.03558v1

検索で持ち込む文書を疑う、三層の防御は何をどこで止めるのか 社内文書やFAQを検索して答えるチャットボットは、利用者が書いた入力だけでなく、検索で拾ってきた文書の中身にも引っ張られます。外部の誰かがレビュー欄や公開ページに仕込んだ指示が、その文書を引いた全利用者に届く。これが間接的なプロンプト注入で、入力だけを見る防御では捕まえられません。 提案は、入口・検索文書・出口の三段階で守る仕組みです。入口で怪しい入力を検査し、検索文書を渡す際は運営側の指示を優先するようAIに伝える。出口では、秘密の指示が漏れていないか、有害な回答になっていないかを調べます。ただし、優先順位を伝えるだけで、AIが必ず従う保証はありません。 著者らは3モデルで攻撃成功率が71.4%から11.3%へ下がったと報告しています。ただし、本文のデータ内訳を足すと4,480件、表では5,080件で一致しません。改善数値は要確認です。 単発の質問を使った実験でもあり、会話をまたぐ攻撃や実運用にも効く、とまでは言えません。 出典：arxiv.org/html/2606.19660v2

AIが書く物語、名前の偏りを減らすには AIに物語を書かせると、別の話でも「Elara」や「Elias」が何度も出てくる。この名前の偏り、どうすれば減らせるのか。 「この名前は禁止」と頼むだけでは、別の名前に偏ってしまう。そこで、過去に使われた頻度を見ながら候補を選ぶ方法を試した論文です。 4言語・20モデルの実験で、厳格な設定では通常生成に比べ、同じ名前になる確率を約95％減らせたと報告。平均の比較は、命名の少ない1モデルを除く19モデルで行っています。 ただし、小説全体が面白くなったとまでは言えません。トークン消費も約3.3倍。名前の重複を減らしたい場合に、効果と手間を比べたい方法です。 初稿：2026年10月31日（UTC）。 出典：arxiv.org/html/2611.01284v1

ノルウェー10月新車登録、テスラ首位 中国ブランド単月シェア22.5%で過去最高 OFVが2026年11月2日に公表した2026年10月のノルウェーの新規乗用車登録統計によると、登録台数は1万5725台で前年同月比41.2%増となり、10月として30年以上ぶりの高水準となった。テスラは1548台で首位となり、前年同月比130.7%増、10月として過去最高だった。トヨタは1493台で55台差の2位だった。中国ブランド車は3534台、シェア22.5%で、単月として過去最高を記録し、前年同月の1879台からほぼ倍増した。電気自動車比率は98.8%だった。これはノルウェーの単月統計であり、年間累計とは区別される。 出典：ofv.no/aktuelt/flest-nye-bil…

米中間選挙と連邦議会の多数派の決め方 米国の連邦議会選は2年ごとに行われ、下院は435議席すべて、上院は通常約3分の1が改選されます。これは各院で多数派を選ぶ仕組みで、大統領本人を選ぶ選挙ではありません。 中間選挙は大統領選の中間に行われ、2026年は11月に行われます。議会選の結果は各院の多数派を左右しますが、大統領の任期や選出を直接決めるものではありません。 上院は6年任期で改選がずれるため、全議席が同時に投票されるわけではありません。 出典：usa.gov/midterm-elections

PFN、国産AI「PLaMo 3.1 Prime」提供 2026年10月27日、PFNが提供開始を発表。 NICTとの共同研究を基にPFNが国産生成AI基盤モデルを提供開始。Web検索とDeep Research機能を新たに搭載した。 出典：preferred.jp/ja/news/pr20261…

光の出口を変える深紫外LED、NICTが275nm素子でWPE6.5%を実証 NICTは2026年10月22日、深紫外LEDの新しい光取出し構造に関する研究発表を公表した。従来は基板側から光を取り出すフリップチップ型が主流で、製造コストと光利用効率が課題だった。 新構造はチップ上面から直接光を取り出すトップエミッション型。マイクロリング電極と酸化ハフニウムのナノ光取出し構造を組み合わせ、全反射を抑えて取り出せる角度を広げた。発光波長275nmの素子で、電気効率85%、EQE7.5%、WPE6.5%を実証した。6.5%はこの素子の絶対値である。 比較条件は同一のエピウェハと電極メサ構造で作った従来のフリップチップ型。その比較でWPEが約35%高いという相対値であり、市販品の価格や一般性能を保証するものではない。今後の実用化が期待される段階だ。 出典：nict.go.jp/press/2026/10/22-…

ゲリラ雷雨の避難判断へ4者連携 協定締結、空振り削減と全国展開は目標 防災科学技術研究所、横浜国立大学、情報通信研究機構（NICT）、横浜市の4者は、ゲリラ雷雨の際の避難や屋外活動の中止といった判断を支える情報の作成を目的に、連携・協力に関する協定を令和8年11月2日に結びました。内閣府の令和8年度「事前防災対策総合推進費」に採択されたゲリラ雷雨予測技術開発事業を、4者が連携して進めるための枠組みだと説明されています。 横浜市：city.yokohama.lg.jp/city-inf… 背景として、防災科研が開発してきた「積乱雲危険度表示システム」は、危険な積乱雲の接近を地図上の予報円で示す仕組みです。雷雨の発生を見逃さないことを重視する一方、実際には雷雨が起きないのに危険と予測する「空振り」が生じることがあり、学校の屋外活動や自治体の防災対応で活用するには、空振りを減らして判断に結びつく情報へ高度化することが課題だとされています。 NICT：nict.go.jp/publicity/topics/… 事業では、このシステムに、雷が空間を進む経路を3次元的に捉えるLMAと、積乱雲内部の降水を30秒ごとに立体的に観測するMP-PAWRのデータを組み合わせます。落雷のおそれがある範囲をこれまでより適切に絞り込むことを目指すもので、30秒は観測の間隔であり、30秒先の予報精度を示す数字ではありません。 NICT：nict.go.jp/publicity/topics/… 今後は学校や自治体で実証実験と聞き取りを行い、屋外活動の中止や避難の判断に役立つ情報を検証します。実証地域以外でも検証を重ね、将来的には全国への展開を目指す計画です。 NICT：nict.go.jp/publicity/topics/…

ブラウザをクラッシュさせる入力が作れても、任意のコードを動かせるとは限りません。ExploitBenchの初稿実験では、V8の既知の不具合41件に対し、GPT-5.5は不具合の発火が27件、任意コード実行が0件でした。共通の実行基盤で各対象を300ターン上限・3試行ずつ調べ、いずれかの試行で到達した対象を数えた結果です。 V8は、ブラウザなどでJavaScriptやWebAssemblyを動かすエンジンです。この研究は、不具合のある箇所へ到達した、異常を起こした、限られた範囲のメモリを操作できた、隔離境界の外も操作できた、コードを実行できた、という段階を分けます。合否一つに潰さず、16種類の能力を実際の動作から記録します。 AIへ渡すのは、不具合のある版のソースコード、説明、公開済みの修正差分、検査方法です。脆弱性を再現する入力や検証コードの完成品は渡しません。AIは調査や実行を繰り返し、JavaScriptなどの検証ファイルを作って提出します。未知の不具合をゼロから発見する試験ではなく、修正情報を手掛かりに既知の不具合を利用する条件です。 探索中にはソースを変更できますが、採点は研究側が固定した、不具合のある版と修正版の実行ファイルで行います。AIが自分で変更したプログラムを動かして成功と言っても、点数にはならない。結果の判定にも、別のAIの感想ではなく、実行結果を確かめる検査コードを使います。 メモリ操作の検査では、配置や確認用の値を変えて3回実行し、全部で条件を満たした時だけ能力を認めます。これは、各対象でAIを3試行するという冒頭の条件とは別です。一度見たアドレスを固定して偶然通す提出物を、次の配置でも通るものと分けるための仕組みです。実運用のあらゆる環境で安定して動くと保証する検査ではありません。 表1のGPT-5.5をもう少し追うと、27件の「発火」は、異常終了だけでなく、修正版との挙動の差やメモリ異常検出も含む段階です。その先で、V8内の限定的なメモリ操作などを少なくとも一つ示した対象が13件、任意コード実行が0件。同じ対象を同じ実行記録から、別の到達条件で数えています。27件のクラッシュを0件へ減らす防御法を比較した数字ではありません。 また、試行中の各提出で確認できた能力は残り、3試行分を合わせて集計します。各能力をどこかで示せたという記録なので、一つの入力が全能力を一度に実現した数でも、平均成功率でもありません。図2はこの読み方に絞りました。 共通基盤の0件を、モデルにその能力がないと断定するのも早いところです。同じGPT-5.5をCodex CLIで動かす別条件では、任意コード実行は1/41件でした。文脈管理やツールの回し方も変わるため、モデルを学習し直して改善した結果とは扱えません。 取り上げる根拠として、Anthropicの公式Claude Opus 4.8 System Cardの3.3.1節が、この41件・16能力のベンチマークを評価に利用していることを確認しました。そこでの平均能力数と、今回紹介した論文の「3試行のどこかで到達した対象数」は集計が違うので、数字は混ぜていません。 防御側なら、報告された不具合を確認する際に、再現できた段階と、より強い操作まで確かめられた段階を分けて記録する使い方が考えられます。修正の優先度を検討する材料にはなりますが、この研究自体が防御の検出率や、導入による被害削減を測ったものではありません。 初稿は2026年5月13日です。対象は公開・修正済みのV8の不具合で、学習中に修正や解説へ触れた可能性を排除していません。V8のメモリ隔離は有効にした条件ですが、攻撃を運用可能にする仕上げや、環境が不明な相手への安定性は評価外。論文当時の構成での能力到達を、現在の全モデルの順位や実際の攻撃成功率へ読み替えることはできません。 出典：ExploitBench: A Capability Ladder Benchmark for LLM Cybersecurity Agents 初稿2026-05-13／arXiv:2605.14153v1

初回の作業が無害に見えても、AIが使った手順や補助コードは、次回へ向けて書き換わっているかもしれません。SkillHarmの隔離実験では、Codex＋GPT-5.4に自己改変する攻撃192件を各1回実行すると、次回利用後の攻撃成功率は69.3%でした。実際の利用者の被害率ではなく、研究者が構築した攻撃集合で、有害な結果が発生した割合です。 この論文でいうスキルは、AIが読む手順書と、実行する補助スクリプトや資料のパッケージです。攻撃者は配布するパッケージを細工できますが、インストール後の環境へ入り直したり、被害側の実行を見て内容を調整したりはできません。個別の依頼文も事前には知らず、そのスキルを普通に使う作業で発火する攻撃を想定しています。 次回へ持ち越す試験では、最初の作業で使う補助スクリプトに、終了時の処理を加えます。そのスクリプトが終了すると、同じパッケージの別ファイルを書き換える。研究者は、改変後のスキル一式を次の作業環境へ渡し、別の作業で再利用させます。最初の作業全体が終わる瞬間に書き換える、という意味ではありません。 採点するのは、次の作業が終わった後の環境です。ファイルの改変や指定先へのデータ書き出しなど、ケースごとに決めた有害な最終状態を検査コードで確かめます。危険な文章を読んだだけ、書き換え用のコードが保存されただけでは、この成功率に入りません。外部ネットワークを切ったDocker環境と合成データでの検証です。 冒頭の192件は、12組の作業ペア、6種類のスキルに基づく攻撃例です。192種類の独立した業務を調べた数ではありません。もう一方の試験では、導入時から固定の不正な内容を入れ、同じ作業中に害が出るかを687件で調べています。同じCodex＋GPT-5.4で、こちらの成功率は86.3%。攻撃の集合も発火する時点も違うので、86.3%から69.3%へ防御性能が改善した、という比較にはできません。 作成には別のAIを使い、スキルの通常の使い方に沿う攻撃例と、結果を確認する検査コードを組にします。二つのモデル構成で実行記録を取り、別のレビュー役が、目標を実現できるか、検査が誤って成功扱いしないかを確認して候補を絞ります。この記録は作成役へ戻して攻撃を練り直すためには使っていません。人の確認は抽出した40候補で、全879件を人が検証したわけではありません。 結果を読む際に気になるのは、攻撃の失敗にも違う理由がある点です。AIが不正な内容を拒否した場合と、そもそも該当ファイルを読まず、スクリプトも使わなかった場合が混ざります。論文は、攻撃箇所に接触した実行だけの成功率も別に出していますが、その条件付きの割合を、全件に対する防御成績と取り替えることはできません。 受け入れ試験へ使うなら、初回の正常終了だけを確認せず、使用前後でスキルのファイルがどう変わり、その版を次の作業で使うと何が起きるかまで追う方法が考えられます。攻撃箇所に到達しなかっただけなのか、到達して拒否できたのかも分けて記録したいところです。これは論文から考えられる検証方法で、今回こちらで導入効果を測ったものではありません。 初稿は2026年6月1日で、今回は10月11日のv2を読みました。別著者のSkillLifeBenchが、自己改変で害を次回へ持ち越す研究として本文と参考文献に取り上げていることも確認しています。第三者からの引用であって、独立した再現や広い導入を示す根拠ではありません。 各攻撃はモデルと実行基盤の構成ごとに1回の実行です。次回利用の試験も、一つの終了時書き換え方式と12組の作業ペアに限られます。日常の全スキルや、ほかの永続化手段へ、この数字をそのまま広げることはできません。特に、初回が穏当に見えることと、次回に使うファイルが変わっていないことは、別々に確かめる必要があります。 出典：SkillHarm: Lifecycle-Aware Skill-Based Attacks via Automated Construction 初稿2026-06-01／arXiv:2606.02540v2

要約を保存する作業と、後で送る作業を別の会話にしても、要約に紛れた不正な送信依頼は残ります。SkillRelayBenchの3構成×攻撃270件＝各条件810実行では、SkillRelayGuardの追加により、指定の違反は563件（69.5%）から88件（10.9%）、依頼した作業の完了は645件（79.6%）から709件（87.5%）でした。 ここでの3構成は、Codex CLI＋GPT-5.3-Codex、Gemini CLI＋Gemini-3.6-Flash、Claude Code＋Sonnet 4.6です。810種類の攻撃ではなく、同じ270件を各構成で実行した合計です。違反と作業完了は別々に採点するので、仕事を終えながら不正なことも起こせます。完了率は、成果物の内容が全面的に正しいことを保証する指標でもありません。 スキルは、AIが読む手順書と補助コード・資料をまとめたパッケージです。試験は二つの作業をつなぎます。最初の会話で、AIがスキルを使って要約やデータベースなどを作る。次の会話では新しいコンテナとホームディレクトリを用意し、会話履歴を持ち越さず、共通の作業場に残ったファイルやスキルを使って続きを進めます。攻撃者は事前に前段・後段のスキルを書き換えられますが、利用者の依頼や信頼されたプロジェクト方針を変えたり、会話の間に成果物を直接細工したりはできません。 攻撃の狙いは、保存された追加指示を後で実行させる、利用を許されていないデータを後の納品へ混ぜる、誤った情報を判断の根拠にさせる、の三つ。30シナリオに、この3パターンと、手順書・補助コード・同梱資料の3か所への改変を組み合わせて270件を作っています。実際の市場で270件の事件を観測した数字ではありません。 SkillRelayGuardは、まず前段の作業が終わった時点で、どのスキルがどの成果物に影響したかを記録します。AIの判断だけで出所を決めず、スキルの指示、実行したツールの記録、成果物の内容や差分を対応づけ、参照した証拠が実在するかを実行基盤で確かめます。ファイルの内容を識別するハッシュ値や元の作業、証拠は、作業AIが書き換えられない場所へ保存します。 次のAIがファイルを読むと、読んだ版に一致する由来の記録を文脈へ戻します。ファイル内の「承認済み」は、今の利用者による追加の許可にはならない、と利用範囲も示します。ただし、これは読み取りが終わった後の処理です。一つのツール呼び出しの中で読み取りと送信が続く場合、その間には割り込めません。 そこで、防御の処理を組み込んだ操作窓口では、実行前にも別のAIが具体的な依頼内容をレビューします。検査するのは、現在の依頼、送信先・引数・提出内容、関係する元資料。許可された範囲か、渡すデータは適切か、重要な主張に根拠があるかを点検し、理由と修正案を作業AIへ返します。元資料も、古くから存在しただけで正しいとは扱いません。 レビューを通すことは必須ですが、助言に従うかは作業AIが決めます。「保留」の助言を受けても、元の依頼を明示的に確認して実行できる設計です。内容を変更すれば再レビューが必要で、確認はレビューした具体的な依頼にだけ結びつきます。拒否権を持つ別の検査器が、全操作を強制停止する仕組みとしては読めません。 表6の違反件数は、指定した有害な結果が発生した数です。そのうち、前段で作られた成果物を次の会話で使うという予定どおりの経路まで確認できた数は、防御なし444/810件、防御あり81/810件。単に危険な文が保存された段階では成功に数えず、違反の発生と、それが通った経路を分けて測っています。 初稿は2026年10月9日。第三者のSkillLifeBenchが、成果物の内容の指紋に由来を結び、操作レビューと組み合わせる研究として引用していることを本文と参考文献で確認しました。この引用は独立した再現や、本番への導入実績を示すものではありません。 引き継ぎファイルを使う仕組みでは、「どの作業から来たか」と「今から何を送るか」を一緒に確認する受け入れ試験が考えられます。出所の記録だけで正しさを認定せず、送信する具体的な内容を元資料へ戻して直せるかを見る。これは論文から考えられる使いどころで、今回こちらで実装・再現した結果ではありません。 採点役と防御のレビューには、別の文脈で動くGPT-5.4を使っています。AI採点の誤りや、同一構成での反復が足りない点を論文も挙げています。模擬業務と構築した攻撃での比較で、通常運用の被害率ではありません。時間の負担もあり、三構成平均では防御部分が1件91.5秒、防御込み総時間の40.2%を占めました。トークン数だけで軽さを判断しにくい構成です。 出典：Understanding and Mitigating Cross-Session Attacks via Persistent Artifacts in Agent Skill Composition 初稿2026-10-09／arXiv:2610.13227v1

FAの人的補償撤廃、これで制度がずっと固定される？ 選手会の10月30日発表には、2029年シーズンオフに新制度を見直すことを前提に合意した、とあります。新しい補償が実際にどう機能するかは、これから見極めるという説明です。 改正への合意と、移籍しやすくなる効果の確認。その間に何が残っているのか、当事者の発表で整理しました。 ① 見直しは、合意の前提として書かれている 日本プロ野球選手会は、NPBとの協議を経て、FA移籍に伴う人的補償の撤廃と、ドラフト指名権の譲渡による新たな補償制度の導入に合意したと公表しました。 その説明では、人的補償には運用上の課題があり、選手から撤廃を求める声があったとしています。選手会は、人的補償がなくなることの意味を認めつつ、新制度が実際にどう働くかは今後確かめる必要がある、と述べています。 そこで、合意できるところから進め、2029年シーズンオフに見直すことを前提に、今回の合意に至ったという流れです。 元のライブドア投稿と対応記事は、指名権や金銭による補償の仕組み、球団間の戦力への影響を紹介しています。記事本文と添付画像には、この2029年の見直しを合意の前提とした選手会の説明はありませんでした。紹介されている動画の全編を確認したものではありません。 ② まだ分からないのは、実際の運用の結果 選手会は、FAを選手が長年の努力で得た権利と位置づけています。その権利を行使しやすくするため、新制度の運用状況を検証しながら、引き続きNPBと協議するという方針です。 この発表から確認できるのは、合意の内容と選手会の考え方です。移籍の件数が増えた、球団間の戦力差が縮まった、といった実績を示す資料ではありません。資金力のある球団にどれだけ有利になるかも、今回確認した発表だけでは測れません。 ③ 2029年の「見直し」で決まっていないこと 見直すという記述を、2029年に自動で制度が終わる、人的補償が復活する、と読むことはできません。見直した結果、何をどう変えるかは、この発表では決まっていません。 また、今回の発表全文には、指名順位や金銭補償率、個々の選手への適用条件の細則は載っていません。そうした数字を独自に確定したり、特定の選手の補償をここで判定したりはしていません。 今後見るべきなのは、改正の見出しに加え、実際の運用、そこで確認された課題、見直しの際の説明です。「合意した」と「効果が確かめられた」を分けて追うと、改革の現在地が見えます。 出典：日本プロ野球選手会「FA補償制度の見直し（人的補償撤廃）について」10月30日 jpbpa.net/2026/10/30/13504/

同じ有害スキルの導入依頼でも、直前にレビュー風の推奨を入れると、AIが実行に進む件数が増えました。SCR-Benchの模擬マーケットで各モデル・各条件401試行を比べると、Opus 4.6は0件から101件へ、GPT-5.4は0件から387件へ。モデルを学習し直すのではなく、前段の出力を後段へ渡すかどうかを変えた実験です。 この研究が見るのは、スキル一つの中だけを調べると見落とす、前後のつながりです。ここでのスキルは、AIが繰り返し使う手順や機能のまとまり。前のスキルが見つけた対象、出した推奨、残した状態を、AIが次のスキルへ渡すことで、単体の動作を超えた危険が生じるかを調べます。 冒頭の実験はSCR-TrustLiftという、推奨の持ち越しを測る部分です。前段はセキュリティ確認やレビューに見えるスキルで、推奨や監査結果を出します。ここでは有害スキルの導入そのものは行いません。AIがその出力を文脈に残したまま、後段のインストール依頼を判断する。比較条件では、その前段の推奨を入れずに同じ導入依頼を評価します。 採点は「導入すると答えた」だけでは終わりません。模擬環境で有害スキルが導入されたことを成功条件にします。Opus 4.6の101件は25.19%、GPT-5.4の387件は96.51%です。図2には表2の5モデルをすべて載せました。モデルごとに影響は違い、一番慎重だったOpus 4.6でも、この条件では前段の推奨による差が残ります。 論文は、つながり方をほかに二つ調べています。一つは、読み取り専用のスキルが見つけた対象を、別の実行スキルが変更・送信などの操作へ使う経路。両方のスキルを呼んだだけでは成功にせず、先に見つけた同じ対象へ、後段の副作用が出たかを確かめます。もう一つは、助言や所見が正式な承認のように扱われ、危険な依頼を許可する経路です。 この三つは、同じ「攻撃成功率」という名前でも終点が違います。対象へ作用したか、有害スキルを導入したか、危険な判断を承認したか。数字を混ぜて平均したり、そのまま現実の被害発生率にしたりはできません。今回の図では、導入を終点にした比較だけを抜き出しています。 実装で確かめるなら、レビュー結果を付けた場合と外した場合で、後段の操作がどう変わるかを見る試験が考えられます。前段の評価が、どの対象・操作・範囲についてのものだったかを記録し、後段の許可と対応づける点も調べどころです。これは論文から考えられる対策の方向で、SCR-Bench自体が検出器や防御法の効果を実証したわけではありません。 取り上げる根拠として、別著者の「Scan Before You Install」が、SCR-Benchのケースと実行結果を静的解析向けに加工し、スキャナーの比較評価へ使っていることを本文で確認しました。元の実行結果を同じ条件で再現したという意味ではなく、評価素材としての第三者利用です。 元論文の初稿は2026年6月13日です。試験は模擬ファイル、サービス、導入状態、承認環境に範囲を絞っており、実際のマーケット全体や運用時の権限制御・雑音までは含みません。TrustLiftは各条件401試行で、ほかの部分にある「各ケース5回」を掛ける対象でもありません。正常な依頼をどれだけ保てるかや、防御を入れた後の成績はこの比較からは分からず、導入後に実害が出る割合も測っていません。 出典：Benign in Isolation, Harmful in Composition: Security Risks in Agent Skill Ecosystems 初稿2026-06-13／arXiv:2606.15242v1

NERV防災ライブ、職場で見てもいい？ ゲヒルンの11月2日発表では、職場で自分が見る場合も「個人利用」に含まれます。一方、店やオフィスで他の人に見せる目的の表示や、第三者への再配信は、同社の許諾なく行えないという案内です。 無料配信が始まったというニュースから、実際に使う場面の条件を原発表で確認しました。 ① 場所だけで線を引いていない 新しく始まったのは、YouTubeの「特務機関NERV防災ライブ（総合）」。会社は11月2日から全国の防災気象情報を24時間配信すると発表しました。視聴料金は無料と案内しています。 ただし、無料で開けることと、ほかの人へ見せる用途まで自由に使えることは別です。 原発表の「ご利用の範囲について」には、自宅のほか、職場で本人が視聴する場合も個人利用に含む、と具体例があります。同じ職場でも、自分のパソコンで自分が見る場面と、共用画面でほかの人に見せることを目的とする場面を分けた説明です。 ② 個人が映す場合にも、第三者向けの条件がある 無許諾の再配信や、オフィス・店舗・街頭などで他の人へ見せる目的の表示は、個人・法人・団体を問わず行えないとしています。会社や団体の業務利用、サイネージ利用を希望する場合は問い合わせるよう案内しています。 ここで紹介しているのは、運営会社が公表した利用範囲です。個別の許諾を取得したり、具体的な契約条件・料金を確認したわけではありません。「個人が操作するから、店内でお客さんに見せても個人利用」とは読めない説明になっています。 元のライブドア投稿と、リンク先のおたくま経済新聞の記事本文には、この職場での本人視聴と第三者向け表示の区別は載っていませんでした。 ③ 「数秒遅れる」は、最大数秒の保証ではない 配信には数秒程度の遅延が生じる可能性があり、視聴環境や通信状況によって、さらに大きくなる場合もあるとしています。 また、メンテナンス、設備や配信ネットワーク、YouTubeの障害などで一時停止する可能性も明記。24時間配信という案内を、無停止や到達時刻の保証に置き換えることはできません。 会社は研究・実験的な取り組みと位置づけ、この配信だけを唯一の手段にせず、緊急速報メール、テレビ、ラジオなどと併用するよう呼びかけています。配信の実際の遅延や稼働率を今回測ったものではありません。 使う前に見るのは、画面の大きさだけでなく「誰が、誰に見せる目的で使うか」。そして、情報を受け取る経路を一つに絞らないことです。 出典：ゲヒルン 11月2日発表「ご利用の範囲」「視聴にあたっての注意事項」 gehirn.co.jp/news/2026-11-02…

会話をリセットしても、AIが以前保存した手順から、環境ファイルの外部送信を繰り返してしまう。Practice Makes Unsafeはこの残り方を調べ、OpenClaw＋MiniMax-M2.7、2つの手順更新法を各75件の新しい正常タスクで比べると、SafeEvolve-UPの追加で危険な挙動は平均21.33%から5.33%でした。同じ新タスクの完了率は53.33%から52.00%です。 研究では、不正な依頼9件と、それに関連する正常な依頼9件を3件ずつ交互に進め、3作業ごとに手順を更新します。その後、最後に残った手順だけを新しい会話へ読み込ませ、攻撃文を含まない正常な依頼3件を実行します。これを25組作るので、最後の検査は各更新法で25組×3件＝75件です。 作業ごとに会話だけでなく、コンテナ、ファイル、プロセスも作り直します。引き継ぐのは、AIが後で読む手順書、つまりスキルの保存庫だけです。攻撃者が保存庫を直接書き換える試験ではなく、過去の依頼からAI自身が危険な手順を学んで残す状況を測ります。モデルの重みを追加学習しているわけではありません。 この作りで、危険な手順が保存されたか、次の仕事で読み出されたか、実際に危険な挙動になったかを別々に追えます。保存庫に不正な手順があるだけで、全部を実行被害とは数えません。会話を消したのに危険が再発する経路を、保存された手順まで戻って調べられる評価です。 SafeEvolveは、手順を書き込む時と再利用する時の両方へ検査を加えます。保存時には、候補の手順と、どの作業や改訂から生まれたかという履歴を検査し、危険な指示の箇所を特定します。修正役は、その箇所を削るか、適用範囲を狭めるだけ。別の安全確認や承認手順を足して内容を作り替える処理ではありません。修正版が読み込めて、再検査で危険度が下がることを確かめます。 SafeEvolve-UPはさらに、修正した手順で小さな正常作業を再試行し、必要な機能まで消していないかを調べます。退行が大きければ、その修正版をそのまま採用せず、元の手順を保つか保留へ回します。判定の閾値は別の開発用エピソードで選び、今回のベンチマークは評価に使っています。 再利用時には、役に立ったかと危険な結果を出したかを、その時に読み込んだ手順の履歴へ記録します。危険の証拠が増えれば検索の優先度を下げ、保留、利用停止へ進めます。文章の一回限りの検査に加え、使った後の結果で保存庫を管理する設計です。 冒頭の数字は表2・4の、AutoSkillとEvoSkillという2更新法の平均です。比較対象も手順の更新は行っており、手順を一切保存しない条件ではありません。21.33%と5.33%は、新しい会話の正常タスクで、有害な目的が実現したと採点された割合。53.33%と52.00%は、その同じタスクで正常な目的を完了した割合です。仕事を終えながら危険なことも起こせるため、二つを足したり引いたりして安全な完了率にはできません。 初稿は2026年8月13日で、今回は10月7日のv2を読みました。第三者のSkillLifeBenchが、手順の版・検索結果・再利用の履歴を扱う研究として引用していることを、本文と参考文献で確認しています。独立した実験の再現や導入実績を示す引用ではなく、こちらで再現実験したものでもありません。 実装へ取り入れるなら、手順を更新した直後の作業だけでなく、履歴を消した後の正常な依頼でも試す受け入れ試験が考えられます。修正が役に立つ手順まで削っていないかを、別の正常作業で再試行する点も具体的です。これは論文から考えられる使いどころで、そのまま導入した効果を測った結果ではありません。 対象は、3つの誘導パターンから作った25組の作業列と、単一のモデルです。2更新法の平均なので、個々の更新法で完了率が同じだけ変わるわけでもありません。実行結果はGemini-3-Flash、保存手順の危険性はKimi-K2-0905などのAI採点を使い、一部を人が照合しています。全実行を人が検証したわけではなく、今回の防御比較の反復試験や信頼区間による差の安定性も示されていません。通常の利用でこの割合の被害が起きる、とは読めません。 出典：Practice Makes Unsafe: Skill Misevolution in Self-Improving LLM Agents 初稿2026-08-13／arXiv:2608.12851v2

安全確認の手順を追加しても、AIが自動で読むとは限りません。Defense-as-Skillでは、ログ整理やファイル編集の前に、その手順を必ず読むようAIへ指示します。Claude Code＋GLM-5で、調整から外した権限・機密データ関連の攻撃59例を10回反復すると、危険な挙動の平均発生率は防御なし60.6%からSkillSonarあり11.5%でした。 悪性スキルがある同じ条件で、元の仕事の達成度を測る得点は0.839から0.715へ下がっています。こちらは仕事がどこまでできたかを採点した平均で、攻撃を防いだ割合でも、完全成功した案件の割合でもありません。発生率と達成度は別々に読む必要があります。 SkillSonarは、AI向けの手順書である「スキル」として安全確認を実装したものです。作業用のスキルと同じAIへ読み込ませ、利用者の依頼、読み込んだ指示、次の操作案、対象ファイルやデータ、これまでの実行履歴を照らします。その操作は依頼に必要か、権限を越えていないか、秘密を別の場所へ出そうとしていないかを調べます。 判断に応じて、そのまま進める、対象を狭めるか計画を変える、利用者へ確認する、という対応へ分けます。新しい隔離環境や、操作を必ず遮断する外部監視器を追加する方式ではありません。同じAIが安全手順を読み、判断に従うことが前提です。読まない、読み違える、無視する、といった失敗は残ります。 そのため、論文では作業指示の先頭に、安全スキルを最初に呼び出し、その後の操作でも判断に従うよう明記します。通常のスキル選択に任せた条件より、この明示的な役割付けがある条件の方が危険な挙動は少なくなっています。安全そうなファイルを置いた効果だけを比べた結果ではありません。 手順の改善にも、実際にAIを走らせた結果を使います。研究の探索では、ガードの指示文を少しずつ編集して候補を枝分かれさせ、危険な挙動、仕事の達成度、確認の回数、トークン使用量を調べて候補を選びます。これはモデルの重みの追加学習ではなく、ディスク上の安全手順を更新する木探索です。改善用には95攻撃例と11通常例を使い、冒頭の59例に含まれる2種類の危険は改善に見せていません。 冒頭の数字はSCOPE-Rという評価集合の表2です。依頼自体は正常に保ち、作業スキルに不正な振る舞いを混ぜます。単に不正な文を読んだだけで攻撃成功とはせず、実行履歴とケースごとの条件から、狙った危険な挙動が起きたかを別のAI、Qwen3.5-122B-A10Bで判定します。60.6%はGLM-5の攻撃能力の得点ではなく、この条件で作業するAI側に危険な挙動が現れた率です。現実の被害発生率へは広げられません。 発生率の標準偏差は、防御なしで4.3ポイント、SkillSonarで3.7ポイント。10回のばらつきであり、95%信頼区間ではありません。同じ59例の反復なので、独立した590種類の攻撃を確かめたわけでもありません。確認を求めた後は固定の返答で処理を再開するため、実際の利用者がどの操作を承認するかという問題も、この試験とは別です。 採点AIは一部の実行を人が照合していますが、全件を人が検証した結果ではなく、誤判定も報告されています。新しいスキルや、ガードを知った攻撃者へそのまま通用する保証もありません。最終的な手順は依然として文章で、権限の制限や実行環境の隔離を代替する仕組みではありません。 実装でまず確かめたいのは、安全手順の内容だけでなく、必要な時点で実際に読まれたかです。ガードを呼んだか、判断したか、その判断通りの操作になったかを別々に残すと、手順を改善するべき失敗と、手順に従わせる仕組みを直すべき失敗を分けられます。これは論文から考えられる運用上の使いどころです。 初稿は2026年9月1日、今回は10月27日のv4を読みました。第三者のSkillLifeBenchが関連研究で引用していることを、本文と参考文献で確認しています。この引用は注目度の根拠で、独立した再現や導入実績を示すものではありません。こちらで実験を再現したものでもありません。 出典：Defense-as-Skill: Evolving Runtime Guard Skill for Skill-Augmented Agents 初稿2026-09-01／arXiv:2609.01487v4

ビルド修正を頼んだAIが、作業用の認証情報まで修正メモへ写してしまう。SkillSafetyBenchには、そんなスキルと周辺ファイルを使う攻撃が入っています。Codex＋GPT-5.4の同じ攻撃付き60ケースで安全ルールを加えると、危険な挙動は25件から18件へ減りましたが、仕事の完全な成功も20件から15件へ減りました。 ここでいうスキルは、AIが作業の進め方を読む手順書に、補助コードや必要なファイルを組み合わせたものです。利用者の依頼は正常なまま、手順書、補助スクリプト、記憶用ファイル、実行環境の設定などに不正な内容を混ぜます。AIには、その環境で普段の仕事を進めさせます。 返答がもっともらしいかだけでは採点しません。生成ファイル、実行履歴、保存された記憶などを集め、ケースごとの検査コードで狙った危険な挙動が起きたかを確かめます。たとえば冒頭のビルド修正では、内部の診断情報を読んだこと自体ではなく、その中の認証情報などが、レビュー担当へ渡すメモや修正差分へ出たことを調べます。論文内の検証用データを使う試験です。 全体は47の元タスクから作った155ケース。権限の逸脱、出力への漏洩、記憶の汚染、実行環境や依存関係の悪用などを含む6領域・30分類です。どのスキルが悪性かを文章だけで分類する評価とは違い、実際にAIを走らせて、副作用が成果物に現れるかを測ります。 冒頭の比較は、その一部を各領域10ケース、各分類2ケースずつ選んだ60ケースです。Codex側には、攻撃用ファイルとは別の、信頼する安全スキルとAGENTS.mdを追加します。外から読んだ内容を上位の命令として扱わない、秘密の出力や送信を点検する、不審な操作は確認を求める、といった指示です。モデルを追加学習した比較ではありません。 付録I.4の表31では、追加防御なしの危険な挙動が25／60件、追加後が18／60件。元の仕事を完全に成功させたのは20／60件から15／60件です。仕事の成功は元タスクの評価が満点だったケースを数えます。安全側の検査と仕事側の検査は別なので、18件と15件を足したり、引いたりして「安全に完了した件数」にはできません。 危険な挙動が7件少ないことと、仕事の完全成功が5件少ないことは、この比較で観測された集計です。同じ5件を余計に止めた、とまでは表から分かりません。検査に通らなかった仕事のすべてを、誤検出と呼ぶこともできません。さらに、この防御比較を繰り返した分布や信頼区間は示されておらず、どの程度安定した差かは残っています。 実験のCodex CLIは0.124.0です。全バージョンの製品や、現実の被害発生率を表す数字ではありません。検査コードは、漏洩した文字列や特定の変更など、ケースで定義した証拠を捉えるものです。曖昧な害や長く続く運用、途中でスキルが更新・合成される状況を全部測れるわけではありません。 初稿は2026年5月12日で、今回は8月28日のv3にある防御比較を読みました。第三者のMalSkillBench論文が関連研究で引用していることを、本文と参考文献で確認しています。引用は注目度の根拠であり、この防御の独立した再現を示すものではありません。こちらで実験を再現した投稿でもありません。 既存のスキルを評価するときには、手順書に禁止文を足して終わりにせず、その手順が読むファイルと、最後に外へ渡す成果物までを一つの試験に含めたいところです。防御の比較表にも、危険な挙動の件数と仕事の完了件数を並べる。安全ルールの追加で何が減り、何を完了できなくなったのかを、同じ条件で見られます。 出典：SkillSafetyBench: Evaluating Agent Safety under Skill-Facing Attack Surfaces 初稿2026-05-12／arXiv:2605.12015v3