9月13日夜のキャッチアップは、AIと人間の付き合い方を2年間の実験で問う研究から始まる。夕方の帯ではAI業界の現場の不安を伝えるBBC報道を取り上げたが、夜は教育現場での実測データ、業界トップたちの監視体制を巡る合意、そして開発者向けツールのセキュリティ情報が並ぶ。LiteLLM旧版のMCP認証バイパスでは実際の悪用が確認されており、日本語圏では話題のClaude Codeプラグインの効果を42セルで測り直した検証記事も注目を集めた。

AIを禁止した学生が2年連続で最下位──法科大学院の2年間比較実験

The Decoderが伝えるところによると、ある法学教授が2年間をかけて、AIの利用を禁止するグループ、誘導なしでAIを使うグループ、構造化された訓練を受けたグループという3条件で学生の成績を比較する実験を行った。結果、AIを使わなかったグループは2年連続で最下位だったという。

注目したいのは研究者自身の言葉だ。同教授は「私は間違っていた」と記し、これまで「ガイドなしのAIは益より害が大きい」と考えていたことを明かした。AIそのものが学習を阻害するのではなく、使い方の設計次第で成果が変わる──そう読める結果として議論を呼びそうだ。

ただし、どのグループが最も良い成績を収めたのか、実験の規模や評価方法の詳細は、今回の収集データからは確認できていないため断定は避けたい。それでも「AI禁止」というシンプルな規制が、2年という期間と実測値の前で成果を示せなかったという事実は、教育現場のルールづくりを考えるうえで重い材料になりそうだ。

Altman・Musk・Hassabis氏がAmodei氏の「独立監視」要求を支持──OpenAIのIPOは2027年に

今日も続いたAI減速論議に、新たな展開が加わった。The Decoderによると、Sam Altman氏（OpenAI）、Elon Musk氏（xAI）、Demis Hassabis氏（Google DeepMind）が、AnthropicのDario Amodei CEOによるAI開発減速と独立した監視の導入を求める呼びかけを、少なくとも部分的に支持したという。

日中の報道では「競合も減速で合意」と伝えられたが、今回は業界を代表する3名が具体的に名を連ねた形だ。あわせてAltman氏は、安全性への懸念を理由にOpenAIのIPOを2027年に延期すると明言した。今朝の「IPO見送り」報道が、より具体的な形で裏付けられたことになる。

またFortuneのインタビューでAltman氏がAIの破滅リスクへの恐れについて語ったことも報じられている。発言の詳細は今回の収集データからは確認できていないが、業界トップがリスクを率直に語る姿勢を示し続けていること自体、ここ数日の流れを象徴している。

EUは「絶滅警告」にどう応えるか──Politicoが内部を報道

米国の業界関係者による警告が続くなか、規制側の動きも見えてくる。Politico Europeは「Keep calm and regulate on（冷静を保ち、規制を続ける）」と題する記事で、EUがAI絶滅リスクの警告にどう応答しているかを内部から報じている。

タイトルからは、EUが恐慌に流されず、既存の規制の枠組みを着実に運用していく姿勢が読み取れる。今週のAmodei氏の警告や業界の減速合意を受けて、規制当局が実際にどう動くのか。記事の詳細な内容は今回の収集データからは確認できていないが、業界側の「声」に対する規制側の「答え」として注目しておきたい報道だ。

LiteLLM旧版のMCP認証バイパス──「デタラメな鍵」で通過、悪用も確認済み

開発者向けの重要なセキュリティ情報も届いている。Qiitaの記事によると、LLMのAPIゲートウェイとして広く使われるLiteLLMの旧版において、MCP（Model Context Protocol）セッションの認証を迂回できる脆弱性が確認された。正しいAPIキーを持たない攻撃者が、任意のBearerトークンでMCPセッションを確立し、社内AIに接続されたMCPツールを呼べてしまうというものだ。

深刻なのは、米CISAが2026年9月2日にこの脆弱性を「実際の悪用が確認済み」として公告した点だ。概念上のリスクではなく、すでに動いている攻撃がある。MCP経由でファイル操作や外部サービス連携を許している環境では、影響の確認が急務となる。

対応としては最新版への更新が基本線だが、具体的な修正バージョンや回避策の詳細は今回の収集データからは確認できていない。LiteLLMを利用している場合は、公式の公告とリリースノートを直接確認してほしい。

エージェントスキルは「配布元とGitHubのdiff」を取ってから──Larkスキルで実演

コーディングエージェント用の「スキル」を導入するとき、配布元が渡してくるファイルと、公開リポジトリにあるファイルが同じものかを確認しているだろうか。Qiitaの記事は「確かめていない人がほとんどだと思う。私たちもそうでした」と切り出し、ByteDanceのLark（飛書）ドキュメント操作スキル「lark-doc」で実際にdiffを取ってみる実演を紹介している。

スキルはエージェントに与える指示やツール定義そのものなので、配布元と公開コードが食い違っているなら、何かが期待と違う動作をすることを意味する。npmパッケージやDockerイメージに対して当たり前になってきた「配布物の中身を検証する」作法の、AIエージェント版と言える。

今回のlark-docで実際にどのような差異が見つかり、それがどう扱われたのかは、収集データの範囲では確認できていない。ただ「スキル導入前にdiffを取る」という習慣を提案した点だけでも、エージェントを業務に組み込む多くの開発者に刺さる指摘だろう。

「diff行数54%減」の主張を3モデル42セルで再検証──ponytail、効果は9〜25%

日本語圏では、Claude Codeに「怠け者のシニア開発者のように書け」と教えるプラグイン「ponytail」の効果を実測したZennの検証記事が注目を集めている。同プラグインのREADMEは「diff行数54%減・コスト20%減」をうたっているが、筆者は自身の小さなExpressアプリと7本のチケットを使い、Haiku・Sonnet・Opusの3モデルで合計42セルをheadlessのClaude Codeで回して測り直した。

結果は9〜25%の削減にとどまり、しかも「減った分の大半は改行」だったという。コストが下がったのはOpusだけだったとのことで、READMEの数値をそのまま期待するのは難しそうだ。今週だけで11,730スターを増やしたという人気プラグインだけに、独立系の実測データが出たことの意義は小さくない。

ベンチマークの条件（アプリの規模、チケットの内容）によって結果は変わるはずで、この検証が「プラグインは無価値」を意味するわけではない。それでも「うたわれた効果を自分の環境で測って確かめる」という姿勢は、あらゆるAIツールの導入判断に通じる基本だと感じる。