「みなづちAI」はリンクフリーです。リンクを行う場合の許可や連絡は不要です。引用する際は、引用元の明記と該当ページへのリンクをお願いします。
AIニュース10選【8/24】テキサスが止めたのは送電網接続、新モデルはゼロほか
みなづちです。
2026年8月24日時点で押さえておきたいAIニュースを、重要度順に10件まとめました。
今回は、テキサス州知事が全米放送の番組でデータセンターの一時停止を語り、その中身が州の公式文書と食い違っていること、OpenAIの渉外トップが「終わらないサイバー攻撃」への備えを英ガーディアンの取材で語ったこと、そしてこの24時間に主要ラボからの新しい対話モデルが1本も出なかったことが大きなテーマです。
本記事では、以下のポイントから解説します。
- テキサス州が止めたのは「建設」なのか「送電網への接続」なのか
- OpenAI幹部の警告は公式発表なのか、取材で語られたものなのか
- Rayの任意コード実行の修正が、CVE番号なしで140項目のどこに置かれていたのか
- 「バグ修正」と書かれた更新で、実際には何の判定処理が消えたのか
- 日本企業3社が見せた、AIの使いどころの現在地
なお本日は、日本時間8月23日7時20分から8月24日7時17分までの24時間から選んでいます。10の角度から調べています。
先に3つ、お断りをしておきます。1つ目は、この24時間に主要ラボからの新しい対話モデルの発表が1本もなかったことです。OpenAI・Google・Anthropic・Meta・xAI・Mistralと中国勢の主要ラボのいずれからも公開はありませんでした。根拠は本文の総括と末尾の注記に書いています。
2つ目は、10本のうち6本が「発表の言葉」と「原典に書いてあること」でずれていたことです。今日はそのずれ自体が読みどころになりました。誇張ではなく、一次情報を開いた結果としてそうなっています。
3つ目は、日本発が3本入っていることです。うち2本は同じ媒体の同じ筆者が同じイベントから書いた記事で、同じ朝に公開されました。その事情も本文に書いています。見出しの日付は日本時間です。ドル建ての金額は1ドル160円で換算しています。
目次
今日の10本は新モデルがゼロ。テキサス州の「停止」は何を止めたのか
まず結論からお伝えすると、この24時間に主要ラボからの新しい対話モデルは1本も出ていません。動いたのは、AIを動かす電気と法律、そしてAIを呼ぶ側の設定でした。
いちばん大きいのが①です。テキサス州のグレッグ・アボット知事が、ABCの日曜討論番組で「新規データセンターが州内の運用に加わることに一時停止をかけた」と語りました。ただし州の公式文書が求めているのはERCOTの系統接続手続きを進める全案件の包括監査で、止まっているのは送電網への接続であって建設そのものではありません。
②はOpenAIの動きです。渉外トップのクリス・レヘイン氏が、オープンソースモデルを使った「継続的で執拗な」サイバー攻撃への備えを警告し、全米一律の法律を求めました。これはOpenAIの公式発表ではなく、英ガーディアンの取材記事です。
③は手を動かす人向けです。分散処理基盤のRayが2.58.0で任意コード実行と認証バイパスを修正しました。ただし140項目ある変更履歴の中の1行ずつで、CVE番号は付いていません。
④⑤⑥は、AIを呼ぶ側の設定が動いた3本です。④はGitHub Copilot CLIの先行版がGrok 4.6の「xhigh」推論に対応、⑤はClineの「バグ修正」でMCPツールの自動承認が全ツールに広がりました。⑥はClaude Codeの2.1.241が出ましたが、公表された変更は2バージョン連続で1行だけです。
⑦⑧⑨は日本発です。⑦はカインズが投稿サイトに入れたAIサポート、⑧はニトリホールディングスが、分析用テーブルが2,600本を超える基盤で、説明欄の作文によって会話型分析を実現した話、⑨はネイティブキャンプのレッスン字幕です。⑩はBoson AIが、公開7データセットの平均で公式結果表の最良値を上回る自己申告値を持ちながら、提出を自分で取り下げた話です。
筆者の視点：テキサスもClineも、原典を開くと話が変わった3点
10本を横断して、3つ引っかかった点があります。
番組の「一時停止」と、州の文書の「接続申請の停止」
①のアボット知事は番組で「I have pressed pause on any new data center being able to join the operations in the state of Texas.」と述べました。聞き手のジョナサン・カール氏はこれを「a moratorium on data center construction」と言い換えています。
ところがテキサス州知事府の公式リリース（8月6日）が明文化しているのは「pause all pending data center interconnection requests」で、対象はERCOTの送電網への接続申請です。しかも同じ番組でアボット氏自身が、着工に州の承認は要らないのが現行法だと説明しています。
止まっているのは建設ではなく、電気をつなぐ順番待ちの列でした。日本の報道で「建設一時停止」とだけ見かけたら、原典が番組発言なのか州の文書なのかを確かめる価値があります。
「バグ修正」と書かれた更新で、既定の挙動が動いていた
⑤のClineは、v4.1.15のリリースノートにMCPサーバーのトグルに関する修正1項目しか書いていません。その1項目は「全MCPツール呼び出しを自動承認する」と明記していますが、見出しは「Fixed」です。そして差分を追うと、個別のツールごとに自動承認するかどうかを判定していた処理が丸ごと削除されており、設定画面に残る個別チェックが効かなくなることまではリリースノートに書かれていません。
結果として、このトグルをオンにしている人は、接続中のMCPサーバーの全ツールが確認なしで実行される状態になります。便利になったとも、歯止めが外れたとも読めます。
⑥のClaude Codeも同じ形です。2.1.241の変更履歴は「Bug fixes and reliability improvements」の1行だけで、2.1.240も同じ1行でした。何が直ったのかは、利用者側からは分かりません。
数字を持っていた側が、順位を主張しなかった
⑩のBoson AIは、英語音声認識の平均WERで3.81という自己申告値を出しました。同じ7つの公開データセットの平均でみた公式結果表の最良値は4.06なので、数字だけ見れば上回っています。ただし公式ランキングが既定で使う平均には、非公開データをscriptedとconversationalの2つに集計した列も入り、そこにOrzeの成績はありません。
それでも同社は提出したプルリクエストを自分で閉じ、その約2分後にモデルカードへ「The system must not be assigned or presented with an official leaderboard placement or rank.」と書き加えました。理由は、3モデルの合議という構成がランキングの対象外だからです。
数字を持っている側が自分で下げるのは、あまり見ない動きでした。③でRayの重大な修正が1行に埋もれていたのと、方向は逆です。
①テキサス州知事がABC番組でデータセンターの一時停止を説明（8月23日）
テキサス州のグレッグ・アボット知事が、ABCの日曜討論番組「This Week」に出演し、データセンターへの規制について語りました。トランスクリプトの公開は日本時間8月23日22時25分です。
番組で挙げた4条件に、地域の同意は入っていない
アボット氏の発言は明快です。「I have pressed pause on any new data center being able to join the operations in the state of Texas.」。
続けて「During that pause, I have set guidelines and guardrails that all data centers have to comply with.」と述べ、条件を「Number one」から「Number four」まで数え上げます。
4つの中身は、水の使用量を申告し必要な地域から取らないこと、テキサスの送電網から必要な電力を取らないこと、消費者の電気料金を実際に下げること、そして近隣住宅地や農村コミュニティを乱さないことです。最後の1つの原文は「Number four, they need to make sure that they are not disturbing neighborhoods or rural communities.」。
ここで注意が要ります。「地域の同意」は、この4つには入っていません。アボット氏は別の質疑で「if you’re a data center and you want to operate in Texas, you have to first get the approval of those in local communities.」と述べていますが、番号を振った4条件の外側の発言です。
そして州知事府がこの件で出したリリースを6月10日から8月18日までさかのぼって読んだ範囲では、地域の同意を義務づける要件は見当たりませんでした。最も近い表現は「近隣の土地所有者とコミュニティへの影響を減らす方策を示すこと」で、同意の取得とは別物です。
州の文書が止めているのは、送電網への接続申請だった
番組の言い方と州の文書の書き方には差があります。テキサス州知事府が8月6日に出したリリースの原文は「Building on those standards, Governor Abbott also directed the PUCT and ERCOT to pause all pending data center interconnection requests until each project undergoes and successfully completes ERCOT’s comprehensive audit.」。
止めているのは係属中の系統接続申請で、解除の条件はERCOTの包括監査を各案件が終えることです。期間の定めはありません。
背景の数字も公開されています。8月3日のリリースによれば、ERCOTが審査中の接続申請は474ギガワットを超え、これはテキサスの記録的ピーク需要の5倍以上。しかも新規の電力接続申請の約90%がデータセンターです。
一方で、番組内で聞き手のカール氏はこれを「Now he has put in place a moratorium on data center construction.」と説明し、VTRでは記者のエリザベス・シュルツェ氏が「Putting a freeze on new data center projects as the state audits them for energy, water usage and tax incentives.」と紹介しています。番組の言い方のほうが広く取れる表現です。
アボット氏自身は、番組で建設と接続を区別しています。ニューヨーク・タイムズが報じたとしてカール氏が挙げた「One massive power plant for a Meta data center approved in 20 days, another in just three days, and another in two days.」という指摘に対し、「to actually begin the data center, they don’t need to get approval from the State of Texas, which is the way the law currently works」と返しています。
AI大手8社の順守表明が社名入りリリースに並んだ
この一時停止には前史があります。州知事府のリリースをたどると、6月10日にPUC委員長とERCOT最高経営責任者に宛てた書簡が起点で、8月3日の書簡がERCOTの接続手続きを進む全案件の包括監査を新規承認より先に行うよう指示し、8月6日のリリースがその指示を係属中の接続申請の停止と言い直した、という順序でした。法的形式は知事令ではなく、書簡と指示として説明されています。
そして8月10日から18日にかけて、OpenAI、Meta、Google、Microsoft、Amazon、Anthropic、Oracle、CoreWeaveが順守を表明したことが、州知事府の社名入りリリースとして次々に公表されています。
ただし州知事府が8月6日に出したQTSに関するリリースが、Amazonは書簡を送って州の標準を受け入れると表明したこと、Googleは州の標準を歓迎し州幹部と協働すると表明したことを、先に書いています。
同じリリースは、シェブロンがマイクロソフトのデータセンター向けにテキサスで発電所を建てる計画も州の標準に適合する例として挙げています（表明したのはシェブロン側です）。AIの主要各社が、州の条件を受け入れる側に回った形です。
政治の文脈も濃く出ています。番組では「The non-partisan Cook Political Report, which rates elections across the country, this week rated the Texas Senate race a toss-up」と紹介され、中間選挙が近いことが繰り返し語られました。
番組と同じ日にABCが出した関連記事によれば、7月のFox News調査では自分の地域へのデータセンター建設に反対する登録有権者が70%とされています。
トランプ大統領の反応もVTRで流れました。「For Texas to say no to data centers is a mistake in the sense that it could be bigger than oil.」。ただしこの発言がいつどこで行われたかは、トランスクリプトに書かれていません。
所感：止まったのは工事ではなく、電気をつなぐ順番だった
読んでいていちばん引っかかったのは、番組と公式文書で「何が止まったか」がずれていることです。番組を見た人は建設が止まったと受け取り、文書を読んだ人は接続の列が止まったと受け取ります。
どちらも嘘ではありません。ただ、投資や雇用の判断に使うなら差は大きいと思います。着工には州の承認が要らないと知事本人が言っているので、更地に建てること自体は止まっていません。
実務で効くのは、どの案件がいまERCOTの列に並んでいるかのほうだと思います。工期に影響が出るとすれば、監査が長引いた案件から順になります。
②OpenAI渉外トップが持続的なサイバー攻撃を警告、全米一律の法律を要求（8月23日）
OpenAIの最高グローバル渉外責任者クリス・レヘイン氏が、英ガーディアンの取材に応じました。記事の公開は日本時間8月23日17時00分、最終更新は8月24日4時00分です。
「終わらない攻撃」が来る、という警告の中身
記事の見出しは「’We are hitting a different chapter’: OpenAI leader warns of threat of ‘persistent’ AI cyber-attacks」です。
副見出しは「Chris Lehane tells Guardian of need to implement new safety standards as critics say AI firms acting ‘recklessly’」。
レヘイン氏の警告の中心はこの一文です。「People are going to be able to access these open-source models and be able to have ongoing, persistent attacks on you, and you’re going to need to have really superior models to fend them off and defend [yourself],」。
誰でも手に入るオープンソースモデルを使って、継続的で終わらない攻撃が仕掛けられるようになる。防ぐには本当に優れたモデルが要るという趣旨です。しかも記事は、そうしたモデルの多くが中国で開発され、OpenAIのような企業が作る最先端のクローズドモデルに数か月しか遅れていないとレヘイン氏が説明したと書いています。
続く一文には諦めに近い響きがあります。「That’s not necessarily going to make the public feel great about things. It is just the reality of where we’re going.」。
求めているのは全米一律の法律で、そこに開発停止を組み込む
レヘイン氏が求める制度も具体的です。原文は「among the reasons why I think it’s absolutely imperative that this country passes a national law that creates mandatory required safety standards, and within that the pause element would be inherent and endemic to that process」。
全米一律の法律で義務的な安全基準を作り、その中に開発の一時停止という要素を組み込むという設計です。運用のイメージも述べられています。「You would not be able to release or deploy models unless you’re proving and guaranteeing a level of safety before they get out into the public,」。
順序についても「I think you have to have a national version here in the US and from there, you can create an international version, because I do think, ultimately, you’re going to need some type of an international structure here.」と、米国版が先で国際版が後だと明示しています。
時期の見通しは条件付きです。「The window where you could see legislation happening is potentially in the first part of next year, when a new Congress comes in,」。
なお記事本文には「federal」という語が1回も出てきません。レヘイン氏が使っているのは「a national law」で、日本語の「連邦法」は意味としては近いものの逐語ではありません。
これは公式発表ではなく、取材で語られたもの
読むときに区別が要るのはここです。この記事はOpenAIのプレスリリースではなく、ガーディアンのロバート・ブース記者による取材記事です。記事自身が副見出しで「Chris Lehane tells Guardian…」と書き、本文にも「He spoke to the Guardian after…」とあります。
OpenAI側の公式掲載も探しました。openai.comの渉外セクションのインデックスページを取得すると、最新の掲載はページ表示で8月18日付の1本（RSSのpubDateでは日本時間8月19日4時の公開）で、ページ全体に「Lehane」という文字列は1回も出てきません。
ニュースのRSSフィードも1,143件を全走査しましたが、最新の公開日は8月20日で、8月21日から23日付の投稿は1件もありませんでした。
ガーディアンの記事も、OpenAIが「on Tuesday」（記事の公開日から数えると8月18日）に一部のフロンティアモデルの訓練を止めたと発表したことに触れています。
その発表にあたるOpenAI自身の8月18日の文書には「This included a two-week pause in reinforcement learning (RL) training on our latest models intended for deployment while we further hardened and red-teamed our research environments and expanded the coverage of our monitoring systems.」とあり、配備予定モデルの強化学習を2週間止めたことが書かれています。ただし「2週間」という数字はガーディアンの記事には出てきません。
批判側の声も同じ記事に載っています。英政府のAI Security Instituteで創設時のディレクターを務めたAIを専門とする大学教授のデイビッド・クルーガー氏は、AI企業の安全性への姿勢を「terrible」「unconscionable」と評したうえで、「They are being really reckless and increasingly taking their hands off the wheel,」と述べ、「We’ve just seen what happens when you do that.」と続けています。
同じ記事には、2024年にOpenAIを辞めたダニエル・ココタジロ氏も登場し、最前線の研究所の指導者たちは「painted the world into a corner」（世界を袋小路に追い込んだ）と述べています。
同氏が設立した非営利団体は、無制限のAI進歩が人類絶滅の確率を10〜30%にすると警告しているとされています。
所感：公式発表と取材記事は、同じ重さで扱えない
この記事の中身自体は重いと思います。オープンソースモデルで攻撃が自動化され、途切れなく続くという話は、企業のセキュリティ担当だけの問題ではありません。
引っかかったのは受け取られ方のほうです。渉外トップの発言ではありますが、openai.comの渉外セクションのインデックスとニュースのRSSを見た範囲に、対応する掲載はありませんでした。取材で語られた内容と、社として文書化された内容は、後から確認できるかどうかが違います。
読者としてできるのは、二要素認証のような基本を今日のうちに埋めることだと思います。攻撃が機械的で網羅的になるほど、基本の穴から順に踏まれます。
③Rayが任意コード実行と認証バイパスを修正、CVE番号は付かず（8月23日）
AIの分散処理でよく使われるRayが、2.58.0を公開しました。日本時間8月23日14時42分のGitHubリリースで、PyPIへの配布は同日13時45分に始まっています。
修正は2件、ただし140項目の変更履歴に1行ずつ
セキュリティに関わる修正は2件です。1件目の原文は「Fix an RCE where read_lance or nested pickle objects could execute arbitrary code (#64881)」。Ray Dataでの読み取り経由で任意のコードが実行される問題です。
2件目は「Fix the Serve replica ASGIService bypassing token authentication (#65189)」。Ray Serveのレプリカが内部で立てるサーバーが、トークン認証を素通りしていたという内容です。
問題は載り方でした。2.58.0のリリース本文には箇条書きが140項目あり、この2件はそれぞれ1行ずつです。Ray Dataの修正6項目の1つ目、Ray Serveの修正2項目の1つ目に置かれています。
冒頭のハイライトに挙がっている5項目は、キャッシュを考慮したルーティングやDelta Lakeへの書き出しなどの機能追加で、この2件のセキュリティ修正は入っていません。5項目のうち1つはgVisorでタスクとアクターを隔離する実験的なサンドボックス機能ですが、これも新機能であって今回の脆弱性の修正ではありません。
危険の中身はコード側の警告文で確認できます。「This file contains columns stored as ‘ray.data.arrow_pickled_object’: {pickle_cols}. Reading these columns requires unpickling, which can execute arbitrary code and is unsafe with untrusted files.」。信頼できないファイルを読むだけで任意コードが走るという説明です。
CVE番号は付いていない。過去のCISA指定案件とは別件
数え直して分かったことがあります。この2件にCVE番号は付いていません。
リリース本文全体を固定文字列で検索すると、CVEが出てくるのは1行だけで、それは同梱依存の更新に付いたCVE-2026-54512とCVE-2026-54513です。どちらもjackson-databindを2.18.8へ上げたことに伴うもので、今回の2件とは関係ありません。
GitHubのセキュリティアドバイザリ側も確認しました。Rayのリポジトリで公開済みのアドバイザリは4件で、read_lanceやASGIServiceを扱うものはありません。アドバイザリデータベースを検索しても該当は0件でした。
したがって公式に宣言された影響バージョン範囲も、深刻度の格付けも、この2件については、2.58.0のリリース本文・Rayのセキュリティアドバイザリ4件・GitHubアドバイザリデータベースを見た範囲では確認できませんでした。
混同を避けたい点があります。2026年8月17日に米CISAの既知悪用脆弱性カタログへ追加されたRayの脆弱性はCVE-2025-62593で、DNSリバインディングを使うもの、修正版は2.52.0でした。今回の2.58.0のリリース本文には、CVE-2025-62593への言及が1回もありません。生HTML全体を検索しても出てきませんでした。別の話です。
効くのは特定の使い方だけ。逆に危険を戻すスイッチもある
自分に関係あるかを切り分ける材料も原典にあります。
任意コード実行のほうは、Ray Dataで自分の管理外にあるデータセットを読む場合が対象です。Parquetの最上位に置かれたpickle列は2.56.0の時点ですでに塞がれており、2.58.0で新しくなったのはread_lanceにも同じ守りを広げたことと、入れ子になった型を再帰的に見るようにしたことの2点です。今回はじめて塞がれたわけではありません。
注意したいのは、環境変数RAY_DATA_AUTOLOAD_PICKLE_OBJECT_SCALARを1に設定すると、この守りが無効になる点です。
エラーメッセージ自身が、読み取り元を信頼するなら設定してよいと案内し、Rayクラスタでは全ワーカーノードに（runtime_env経由などで）設定する必要があるとも書いています。runtime_envの指定やDockerfile、Kubernetesのマニフェストにこの名前が書き残っていないか、探しておく価値があります。
認証バイパスのほうは、トークン認証を有効にしているクラスタが対象です。Rayではトークン認証は既定で無効なので、既定のまま使っている環境では認証の素通りそのものは起きません。ただしこの修正はTLSにも及んでいて、RAY_USE_TLSを有効にしているクラスタでも、この内部サーバーはその設定を見ずに平文のまま立っていました。
差分では、認証インターセプタ付きのサーバー生成と、RAY_USE_TLSを見るポート追加の両方に差し替えられています。裏を返すと2.58.0より前の該当環境では、レプリカのポートに届く相手からの呼び出しが認証を経ずに通っていたことになります。この内部サーバーが保護されない状態で立っていたのは2.54.0以降でした。
所感：重い修正が、機能追加の列に埋もれる形
引っかかったのは、扱いの軽さです。任意コード実行と認証バイパスという言葉の重さに対して、載り方は140項目の中の1行ずつでした。
CVE番号が付いていないので、脆弱性情報を自動で追う仕組みには引っかかりません。使っている人が変更履歴を最後まで読むか、依存更新のたびに差分を見る運用でないと、気づかないまま通り過ぎます。
切り分けの軸は、信頼できない相手のデータをRay Dataで読んでいるか、トークン認証を有効にしているかの2つです。読み取り経路をread_lanceだけだと思って見送ると外します。どちらも該当しないなら急ぎではありませんが、当たるなら今日の作業に入れる価値があると思いました。
④Copilot CLIの先行版がGrok 4.6のxhigh推論に対応（8月23日）
GitHubのコマンドライン版Copilotに、xAIのGrok 4.6をより深く考えさせる設定が入りました。日本時間8月23日23時46分の公開です。
変更は4項目、そのうち1行が今回の目玉
リリース本文は短く、追加1項目、改善2項目、修正1項目の計4項目だけです。今回の目玉はその追加の1行で、原文は「Add xhigh reasoning effort support for Grok 4.6」。
推論の努力の度合いを指定する設定に、xhighという段階がGrok 4.6向けに加わった、という内容です。対象はGrok 4.6のみで、他のモデルへの追加には触れていません。
コマンドリファレンスの5段階では、「xhigh」の上に「max」がある
調べ直して分かったことがあります。コマンドリファレンスが並べる段階の中では、xhighは最上位ではありません。
序列はGitHub Docsの「GitHub Copilot CLI command reference」に明記されています。原文は「Set the reasoning effort level (low, medium, high, xhigh, max). max is the highest-depth tier for Anthropic models.」。
低いほうからlow・medium・high・xhigh・maxの5段階で、xhighは4番目です。最上位のmaxはAnthropic系モデル向けの最深段だと説明されています。なおCopilot CLIリファレンスは目次ページの下に複数のページがある構成で、目次ページと対応モデル一覧のページには「xhigh」が0件でした。私が最初に見ていたのはその目次ページです。
CLIでの指定方法も同じリファレンスに載っています。起動オプションは「–effort=LEVEL」または「–reasoning-effort=LEVEL」、設定ディレクトリのリファレンスでは項目名が「effortLevel」（既定値は”medium”）で、取り得る値として挙がっているのは”low”・”medium”・”high”・”xhigh”の4つで、コマンドリファレンスにある”max”はこちらには載っていません。リリース本文に書かれていないだけで、名前だけが先に出た状態ではありませんでした。
安定版ではないので、普通に入れても降ってこない
実務で効くのは提供チャンネルの話です。1.0.81-8は先行版で、安定版ではありません。
npmの配布タグを見ると、通常のインストール先である最新版は1.0.80のままで、1.0.81-8には先行版用のタグが付いています。GitHub側でも、最新リリースへのリンクは1.0.80に向いています。つまり普通にインストールしても、この機能は入りません。
安定版の1.0.80がnpmに公開されたのは日本時間8月14日11時30分（GitHubのリリース公開は同日11時28分）で、そこから9日間、安定版は据え置きです。その間に1.0.81系の先行版が0から8まで9本出ています。
Grok 4.6そのものを使える条件も別にあります。GitHubのドキュメントによれば、使えるのはPro、Pro+、Max、Business、Enterpriseの有料5プランで、無料版と学生向けは対象外です。BusinessとEnterpriseでは管理者がGrok 4.6のポリシーを有効にしないと選べず、既定はオフです。
この既定オフは、GitHub Docsではなくgithub.blogの8月14日のチェンジログが「The policy is off by default.」と明記しています。会社のアカウントを使っている人は、CLIを更新しただけでは選べないことがあります。
なお設定ディレクトリのリファレンスは「Higher levels use more compute.」（レベルを上げるほど計算量が増える）とだけ書いています。xhighにするとAIクレジットの消費がどう変わるのかは、コマンドリファレンスと設定ディレクトリのリファレンスを検索した範囲では書かれていませんでした（対応モデル一覧のページには、推論を高くするとトークンが増えて消費するクレジットも増える、という一般的な記述だけがあります）。
所感：指定の仕方は載っている。分からないのは費用のほう
新しい設定が入ったこと自体はいい話だと思います。難しい問題にはより長く考えさせたい、という要求は素直です。
どう指定するのか、他のレベルとどう違うのかは、GitHub Docsのコマンドリファレンスと設定ディレクトリのリファレンスに書かれています。分からないのは費用のほうで、xhighにするとAIクレジットの消費がどれだけ増えるのかは、これらのページとリリース本文を検索した範囲では見当たりませんでした。費用の見当がつかないまま常用するのは避けたい段階だと感じました。
仕事で使うなら、GitHub自身が最新リリースを1.0.80に向けている点を見て、今回は見送るのが無難だと思います。
⑤Clineの「バグ修正」でMCPの自動承認が全ツールに広がった（8月24日）
AIコーディング支援のClineが、日本時間8月23日19時11分にv4.1.14を、8月24日4時56分にv4.1.15を公開しました。安定版は後者です。この2本には、リリースノートの見え方と中身が離れている箇所があります。
モデル一覧は31件増、Claude Fable 5は前から載っていた
まずv4.1.14です。リリースノートはモデルカタログの刷新を挙げ、新しく入るものとしてClaude Fable 5、Vertex上のGrok 4.6、DeepSeek V4 Flashなどを列挙しています。
実際に前版と差分を取ると、次のようになりました。登録プロバイダは180で変わらず、モデルの登録数は5,461件から5,492件へ、差し引き31件の増加です。内訳は追加38件が16プロバイダ、削除7件が2プロバイダでした。
ここで注意が要ります。Claude Fable 5は、前版のv4.1.13の時点ですでにカタログに載っていました。32件のエントリが27のプロバイダ経由で登録されており、Anthropic直の設定はv4.1.13とv4.1.14で1文字も変わっていません。
今回新しく増えたのは、Google CloudのVertex AI経由の1件だけです。Anthropicの公式ドキュメントによればFable 5のGoogle Cloud提供は6月9日に始まっているので、Clineのカタログが約2か月半遅れて追いついた形になります。この記事の対象24時間に、AnthropicがFable 5について何かを発表したわけではありません。
同じくリリースノートにある「Grok 4.6 on Vertex」も、ClineのVertexプロバイダにGrokが入ったという意味ではありません。実体は別のゲートウェイ経由の登録で、ClineのVertexプロバイダに登録されている28件のモデルにGrokは1件も含まれていません。
このカタログの刷新自体、v4.1.14の手柄ではありませんでした。中身は日本時間8月23日8時58分に出たSDKに入っており、同じものがデスクトップ版とコマンドライン版にも載っています。
v4.1.15の1行の裏で、個別許可の判定が丸ごと消えた
こちらが今日の本題です。v4.1.15のリリースノートは修正1項目だけで、MCPサーバーを使うトグルが個別に許可済みのツールにしか効かなかった不具合を直した、という内容です。
MCPは、AIを外部のツールやデータにつなぐための共通規格です。Clineには操作を自動で承認する設定があり、その中に「MCPサーバーを使う」というトグルがあります。このトグルは、Clineの既定値では最初からオンです。
差分を追うと、直し方が分かります。ツールごとに自動承認の対象かどうかを判定していた処理が、丸ごと削除されていました。
結果として何が起きるか。このトグルをオンにしていると、接続中のMCPサーバーの全ツール呼び出しが、確認なしで実行される状態になります。以前あった「このツールだけ自動承認」という個別のチェックは、承認の判定から外されました。設定画面のチェックボックス自体はv4.1.15にも残っていますが、オンでもオフでも結果は変わりません。
便利になったとも読めますし、歯止めが1段外れたとも読めます。どちらの評価をするにせよ、リリースノートの唯一の修正項目は「Auto-approve every MCP tool call while the “Use MCP servers” toggle is on.」と書き出し、「it now governs all MCP tools on its own.」と結んでいるので、全ツールが対象になること自体は明記されています。
書かれていないのは、個別指定に戻す方法と、設定画面に残る個別チェックが効かなくなることです。v4.1.15のリリースページ本文は、SDKバンドル経由で届くという前置きの1文と、この修正1項目だけです。
なお、v4.1.14に話を戻すと、そのモデルカタログ刷新を運んだSDK 0.0.78のリリースノートは、既定モデルが変わるプロバイダとして6つ（DeepSeek、Crof、CrossModel、Eden AI、Kilo、NanoGPT）を名指ししています。
ただし設定ファイルをv4.1.13とv4.1.14で比べると、実際に既定モデルが変わったのは11プロバイダでした。名前が挙がっているのはその一部です。
所感：確認を求める回数が減るのは、静かな変更ではない
MCPのツールは、ファイルを触るものも外部に送るものもあります。全部まとめて確認なしになるというのは、使い勝手の話であると同時に、事故の起き方が変わる話でもあります。
引っかかったのは、挙動が変わったのに、利用者に届く手がかりが変更履歴の1行しかないことです。設定画面に残る個別チェックが飾りになったことは、そこからは読み取れません。
しかもこの「MCPサーバーを使う」トグルは、Clineの既定でオンです。設定に触った記憶がない人ほど対象になるので、MCPサーバーをつないでいるなら今日いちど設定画面を開いて、接続中のサーバーを棚卸ししておくとよさそうです。
⑥Claude Code 2.1.241の変更履歴は2版連続で1行だけ（8月23日）
Claude Codeのv2.1.241が公開されました。日本時間8月23日8時58分にnpmへ、その53分43秒後の9時52分にGitHubのリリースとして出ています。
「バグ修正と信頼性の改善」の1行しかない
変更履歴の中身は、これだけです。原文は「Bug fixes and reliability improvements」。箇条書き1項目で終わっています。
GitHubのリリースページも同じでした。本文は見出し1つと箇条書き1つだけで、変更履歴には無い詳細がGitHub側にある、という構造にはなっていません。関連するissue番号もリンクも本文中にありません。
前日の2.1.240も、まったく同じ1行でした。2バージョン続けて中身が公表されていないことになります。
一方で、その前は違いました。2.1.239は59項目あります。前回この記事で扱った8月18日の2.1.234は51項目でした。2.1.235から2.1.241までの7バージョンで合計154項目あるので、直近2バージョンを除く5本に152項目が集まっている計算になります。直近30バージョンの箇条書き数を数えると、中央値は22.5項目でした。
ここは誤解しないよう書いておきます。この1行の書き方は、今回から始まったものではありません。変更履歴の全文を検索すると同じ1行は8回出てきて、最も古いものは日本時間6月5日公開の2.1.165です。2か月半前から断続的に現れる書き方で、連続した例も6月にありました。運用が変わったわけではないということです。
安定版チャンネルは10バージョン前で止まっている
実務で効くのは配布チャンネルの話です。npmの配布タグを見ると、最新版と次期版は2.1.241を指していますが、安定版は2.1.231のままでした。
2.1.231が公開されたのは8月13日なので、安定版と最新版の差は10バージョン、時間にして9日15時間あります。公式ドキュメントは安定版をおおむね1週間前のものと説明しているので、今はそれより開いていることになります。
既定のチャンネルは最新版のほうです。自動更新を有効にしてネイティブ版を使っている人には、中身の分からない更新がすでに降りている可能性が高いことになります。設定画面の自動更新チャンネル、または設定ファイルの該当項目で確認できます。なお公式ドキュメントによれば、最新版から安定版へ切り替えるときは、いま入っている版に留まるか、その場で降格を許すかを選ぶ画面が出ます。
なおHomebrewやWinGet、apt系のパッケージ経由で入れている場合は既定では自動更新されないと公式ドキュメントに書かれています。ただしHomebrewとWinGetについては、環境変数を1にすればClaude Code自身が更新コマンドを走らせるという案内も同じページにあり、手動固定なのはapt・dnf・apkのほうです。2.1.241が自動で入るのは、ネイティブ版など自動更新の経路に限られます。
書かれていないことも整理しておく
原典に無いことも、対象を絞って書いておきます。
変更履歴の2.1.241の節と、GitHubリリースの本文divを確認した範囲では、直った不具合の中身、セキュリティ修正かどうか、CVE番号、脆弱性への言及のいずれも書かれていません。なぜ1行なのかの説明も、安定版が2.1.231に留まっている理由も、同じ2か所には見当たりませんでした。
日本語版のリリースノートもありません。docs.claude.comの日本語のリリースノートのページ（/ja/release-notes/claude-code）はGitHub上の英語版CHANGELOG.mdへ転送され、日本語の変更履歴のページ（/ja/docs/claude-code/changelog）も転送先で出てくるのは英語のままの変更履歴でした。この2つのURLを開いた範囲では、日本語で読める版はありません。
所感：中身が分からない更新を受け取るかどうかの選択
毎日のように更新が来る道具で、2バージョン続けて中身が公表されないのは落ち着かない感じがします。ただ、記録を数え直すと同じ書き方は6月から8回あって、今回だけの話ではありませんでした。
実際に選択できるのはチャンネルのほうだと思います。中身の分からない更新を避けたいなら安定版に切り替えられますが、その安定版は今日の時点で10バージョン、9日以上前のものです。切り替え時に現在の版へ留まるか降格を許すかは選べます。
新機能に追いつくことと、変更の中身が分かることは、今のところ両立していません。どちらを取るかを一度決めておくのがよさそうです。
⑦カインズがくらシェアにAI投稿サポート、人に書かせる3つのポイント（8月24日）
ホームセンターのカインズが、くらしのアイデアを共有するサイト「くらシェア」に、投稿文の作成を助けるAI機能を入れています。ITmediaビジネスオンラインが日本時間8月24日7時5分に公開した記事で分かりました。
全部書かせず、3つだけ人に入力してもらう
設計の考え方は、AIに丸投げしないことにあります。記事に引用されたカインズの田伏洋介氏（デジタル推進本部 デジタルサービス開発部 部長）の言葉は「機械的な代筆ではなく、お客さま自身の工夫の種を生かしたまま、お客さまの言葉で他の方に伝わる形に整える。言語化を伴走してくれるような仕組みが必要だった」。
そのために用意されたのが3つの入力です。記事の箇条書きをそのまま引くと、こうなります。
- 目的の選択：「お悩み解決」「意外な裏技」など、投稿するアイデアの型を選択肢から選ぶ。これにより、くらシェアのコンセプトから外れることはほぼなくなったという
- 雰囲気の調整：文章のトーンを「フォーマル」「フレンドリー」などから選べるようにし、投稿者の感覚に近づける。生成AI感が和らぐ効果もあった
- 独自の工夫：最も伝えたいポイントを自分で書いてもらう。ここに投稿者の声が最も反映される
記事の地の文は、この3つを「ユーザーに『3つのポイント』を入力してもらうことで、精度を保つ仕組みにした。」と説明しています。節の見出しは「ユーザー独自の『私の声』を残す3つの工夫」です。
「AIらしさを消す」は要件、効果は「和らぐ」まで
ここは正確に書いておきたい部分です。記事の見出しは「口コミ増やしたい、でも“AIが書いた感”は抑えめに……カインズ、『自社商品の投稿』促すAI機能どう開発した？」で、「抑えめに」であって「消す」とは書いていません。
「消す」という語が出てくるのは、開発の要件を述べた1文だけです。「投稿のハードルは下げつつ、ユーザーが思い浮かべている『自分の声』の納得感を損なってはならない。入力は簡単に、生成AIらしさは消す。この両立が必須要件だった。」。
一方、3つの入力の効果としては、2つ目の「雰囲気の調整」に「生成AI感が和らぐ効果もあった」と書かれているにとどまります。要件としては「消す」、実際の効果としては「和らぐ」という書き分けです。
調整には手間もかかったようです。田伏氏は「最初、あの丁寧過ぎる文章を見たときは『大丈夫かな』と思った。粘り強く調整し、最終的にはちょうどいいバランスになった」と語っています。
サイト上の案内文は「最短1分で投稿完了！ AIが投稿案を作成」です。リリース後の変化を扱った最終節に効果として挙がっているのは「単に投稿数が増えるだけではなく、文章の質自体が上がって、利用シーンが目に浮かぶような投稿が増えた」という田伏氏の発言と、AI検索の出力結果やGoogle Discoverに投稿が載るケースも出てきたという地の文です。増加率や件数といった効果の数値は、記事本文には出てきません。
この記事は8月24日の発表ではない
日付の扱いに注意が要ります。8月24日はITmediaの記事公開日で、カインズの発表日ではありません。
記事は冒頭、目次の直前で取材元を明示しています。「本記事は、グーグル・クラウド・ジャパンが主催したイベント『Google Cloud Next Tokyo』（7月30～31日開催）の講演セッションから『生成AIで実現するtoCサイトのリッチ化。カインズが挑む顧客体験の進化』を取材したもの。」。
ITmediaの記事に書かれているのはイベントの会期（7月30～31日）までで、講演日そのものは出てきません。登壇したシステムサポートが2026年7月1日付で自社サイトに出した告知によれば、このスポンサーセッションは7月30日14時00分から14時30分（Room7）でした。ITmediaの記事本文によれば、開発を担ったシステムサポートの福田仁史氏も登壇し、講演の締めくくりを務めています。
AI投稿サポートの提供開始日は、記事本文に書かれていません。カインズのニュースリリース一覧を確認した範囲でも、この機能に対応する発表は見つかりませんでした。開発費と投稿数の増加率も、記事には出てきません。一方で使っている道具は明示されています。
土台になっているのは、システムサポート（石川県金沢市）が開発した生成AIサービス「GEN-STEP」で、モデルは米Googleの「Gemini」。Google Cloudのマネージドサービス上に構成し、生成結果などの利用履歴はBigQueryに蓄積すると書かれています。
なおこの記事はITmediaの会員限定です。原典を読むには登録が要ります。
所感：AIに全部書かせない、という型が持ち帰れる
面白いと思ったのは、AIに書かせる範囲を先に狭めていることです。型を選ばせ、トーンを選ばせ、いちばん言いたいことだけ自分の言葉で書かせる。そこからAIが整える。
丸投げして出てきた文章を直すより、はじめから人の一言を核に置くほうが、書いた本人の納得感が残ります。これは企業のサイトに限らず、自分のレビューや社内の報告にもそのまま応用できる型だと思います。
トーンの指定が「生成AI感が和らぐ効果もあった」という副次的な位置づけなのも、正直で好ましく読めました。
⑧ニトリHDが説明欄の作文で会話型分析を実現、分析用テーブルは2,600本超（8月24日）
ニトリホールディングスが、社内の誰でも自然言語でデータを聞けるようにした取り組みが記事になりました。ITmediaビジネスオンラインが日本時間8月24日7時10分に公開した、7月30日から31日に開かれたイベントの講演セッションの取材記事です。8月24日は記事の公開日で、ニトリHDの発表日ではありません。⑦のカインズの記事と同じ筆者が、同じイベントの別セッションを取材して、同じ朝に公開しています。
詰まったのは技術ではなく、社内でしか通じない名前
同社がデータ分析基盤の検討を始めたのは2021年で、BigQueryを使った基盤は2022年後半に動き出しました。5カ年計画で整備を進めた結果、分析用の主要なテーブルだけで2,600本を超えています。
それでも壁がありました。記事に引かれた同社の小林桂氏の言葉は「データ分析ができる環境を提供できても、使いこなせるかどうかは別問題」です。
具体例が分かりやすいので、そのまま引きます。「例えば、既存システムから引き継いだカラム（列）名の『DELVTO_CRP_KBN』は『納品先会社区分』を指す。英語と日本語が混ざった社内の命名規則によるもので、AIには読み取れない。同種のテーブルが2600本積み上がり、時間がたつほど『何のために作ったのか』という文脈が欠落していく。」。
AIが読めなかったのは、社内でしか通じない名前でした。
解決策は、テーブルの説明欄を作文することだった
対処の方法は拍子抜けするほど地味です。記事の地の文は「対策方法は単純だった。テーブルのプロパティにある『説明』の欄に、欠落した文脈をひたすら記述したのである。」と書いています。
書き方も具体的です。「データサイエンティスト、アプリ開発者、業務ユーザーなど異なる立場の視点で、Wikipediaの記事を整備するようなイメージで書き込んだ。」。さらに「同じ要領で個々のカラムにも説明を付け、テーブル間の関係性や質問の前提となる補足情報、検索を安定させる問い合わせの見本も用意した。」とあります。
同社独自の用語も同じやり方で埋めました。「例えば、ニトリ独自の『伝票種別』であれば『レジでの決済』『注文・取り寄せ』『キャンセル』といった各コードの意味まで記述し、その用語をテーブルやカラムにまとめて関連付けた。」。
その結果できるようになったのが、自然言語での問い合わせです。記事が挙げる例の1つは「赤羽店の先週の寝具分類の売上高と売上高前年比を、中分類単位で出して」で、記事はさらに難しい例として「マットレスプロテクターと敷布団の同日併売実績を抽出して」も挙げています。BIツールの探索機能を「会話型分析」に置き換え、社員が言葉で伝えるとAIがSQLを生成してデータを取り出す仕組みにしています。
なお同じ記事でも、1ページ目の冒頭では「対話型分析」と表記されています。2ページ目の該当節と講演スライドの表記が「会話型分析」なので、本記事は後者に合わせています。
小林氏は講演の締めくくりでこう強調したと記事は書いています。「やったことは、データの説明を作文したことだけ。IT技術を持つ限られた人にしかできないことではない」。
「抽出はAI、分析は人」という線の引き方
考え方の芯もはっきりしています。記事の表現は「BIツールの置き換えを支えたのが『抽出はAI、分析は人』という考え方だ。」。
小林氏は「欲しいデータの取得はAIに任せ、人はその結果を使って十分に時間をかけ、分析と仮説検証に注力すべきだ」と述べています。取り出すところまでをAIに任せ、意味を考えるのは人が引き受ける、という分担です。
始め方の助言も具体的でした。「プロパティに記述する方法であればAIが確実に拾ってくれる。最初は『説明』に何でも書いてしまえばよい」。全社のデータを網羅する必要はなく、重要度の高い上位5つ程度でも効果は確認できるとしています。
書かれていないことも整理しておきます。記事の1ページ目と2ページ目の全文を検索した範囲では、生成AIのモデル名も、置き換え前後のBIツールの製品名も出てきません。
記事の本文で同社が使う製品として名指しされているのは、Google CloudとBigQueryの2つだけです。この2つ以外に本文に出てくる製品・サービスの固有名は、説明の書き方のたとえとして1度だけ出てくる「Wikipedia」でした（取材元として挙げられたイベント名「Google Cloud Next Tokyo」と、写真クレジットの「ゲッティイメージズ」は数えていません）。
分析時間の短縮率、利用者数、費用の金額も同じ2ページに記載がありません。効果は言葉で語られています。
なお講演スライドの画像には、社内用語や区分値のラベルを「Knowledge Catalog」の「用語集」で整備し、BigQueryのテーブルやカラムに関連付けたという説明が出てきますが、これは画像の中だけで、記事の本文には一度も登場しません。この記事も会員限定です。
所感：新しい道具より先に、説明欄を埋める番だった
読んでいて意外だったのは、解決策に新しい製品名が出てこないことです。やったのはテーブルとカラムの説明欄を埋める作業でした。
社内の略語や独自コードが読めないのは、たぶんどの会社でも同じだと思います。AIに聞ける環境を作ったのに使われない、という話を聞いたとき、原因はモデルではなく説明の不在かもしれません。
上位5つ程度から始めればよいという助言も、手をつけやすくて良かったです。全社を一気に整備する計画を立てて止まるより、よく使う5本から作文するほうが早そうです。
⑨ネイティブキャンプが講師の英語をリアルタイムで文字表示（8月23日）
オンライン英会話のネイティブキャンプが、レッスン中に講師の発話を文字にして画面に出す「字幕機能」を発表しました。プレスリリースの配信は日本時間8月23日16時です。
ボタン1つで出したり消したりできる
機能の説明は簡潔です。原文は「レッスン中の講師の発話をリアルタイムでテキスト化し、画面上に表示する『字幕機能』をリリースいたしました。」。
切り替え方も書かれています。「字幕の表示・非表示は、講師ビデオ下部の『字幕』ボタンからワンタッチで切り替えることができ、レッスン中に何度でも変更可能です。」。
使い分けの想定も示されています。「聞き取りが難しいときには字幕を表示して内容を確認し、リスニング力を鍛えたいときには字幕を非表示にするなど、ユーザー自身の英語レベルや学習目的、その時々のレッスン状況に合わせて活用することが可能です。」。
聞き取れなかった一言だけ確認して、また消す。そういう使い方ができる作りです。
出るのは英語のままで、日本語訳は出ない
ここは読者が取り違えやすいところです。字幕として画面に出るのは、講師の英語をそのまま文字にしたもので、日本語訳ではありません。リリースに掲載されたスマートフォン版とパソコン版の画面写真でも、表示されているのは英語です。
同社の公式FAQは、日本語訳の字幕について自社独自の機能としては提供していないと明記しています。日本語も見たい場合は、Google Chromeの標準機能（自動字幕起こしとリアルタイム翻訳）を使う案内になっています。
このChromeの標準機能を使う方法はGoogle Chrome限定で、Safari・Firefox・Edgeなど他のブラウザでは使えないとFAQは書いています。字幕機能そのものの対応ブラウザは、このプレスリリースと、公式FAQを「字幕」で検索して出てくる2件（No.619とNo.634）を読んだ範囲では書かれていません。
精度についても限定が付いています。「※本機能は、AIによる音声認識を活用した自動字幕表示機能です。発話内容が必ずしも正確にテキスト化されるとは限らないため、聞き取りを補助する機能としてご活用ください。」。
表示の速さにも但し書きがあります。「※ご利用のネットワーク環境、端末、ブラウザなどによっては、字幕の表示に数秒程度のタイムラグが生じる場合があります。」。リアルタイムとはいえ、数秒のずれは想定されています。
8月23日は発表日で、提供開始日ではない
日付についても正確に書いておきます。8月23日はプレスリリースの配信日で、機能の提供開始日ではありません。
リリース本文は「リリースいたしました」という完了形だけで、提供開始日の記載がありません。一方、同社の公式FAQでこの機能を説明する記事は7月23日に公開されています。少なくとも7月下旬には使える状態だった可能性があります。
対象範囲も、リリース本文からは絞り込めませんでした。プレスリリースのページ全文を検索した範囲では、対象のレッスン形式、対応する端末やアプリ、対象プラン、追加料金の有無、使っている音声認識の提供元のいずれも書かれていません。「AIによる音声認識」という記述にとどまります。
同社の規模はリリースに出ています。講師は15,000名以上、教材は32,000以上、累計レッスン数は8,000万回超で、講師の出身国は140か国を超えるとされています。
所感：聞き取れなかった一言だけ、拾いに行ける
英会話のレッスンで困るのは、聞き返すのが気まずくて流してしまう瞬間だと思います。ボタンを押せば講師の発話がその場で文字になり、押し直せば消える。この往復ができるのは学習の設計としてよくできています。
日本語訳が出ないのも、この機能の目的からすると素直だと感じました。訳が出ると読んで理解した気になりますが、英語のまま文字で見るなら、音と綴りを結び直す作業になります。
対象プランや追加料金の有無は、プレスリリースのページ全文を検索した範囲では書かれていませんでした。まずは自分のアカウントで「字幕」ボタンが出るかを確かめるところからになります。
⑩Boson AIが自己申告の数字を残したまま順位の申請を取り下げ（8月24日）
英語の音声認識で、基準にする1つのモデルの書き起こしを、残る2つのモデルが同じ直しで一致したときだけ書き換える仕組みが公開されました。Boson AIがHugging Faceに出した「Orze-ASR-3Way」です。公開は日本時間8月23日9時6分、そして取り下げは翌8月24日3時2分でした。
公開7データセットの平均で、結果表の最良値を上回る数字を自分で出した
まず数字から見ます。自己申告の平均WERは3.81です。WERは音声認識の誤り率で、低いほど良い数値になります。
比較対象も確認しました。Open ASR Leaderboardの現行の公開結果表には65機種が載っており、同じ7つの公開データセットの平均でみた最良値は4.06です。
ただしランキングが既定で表示する平均は、この7つに、非公開データを「scripted」「conversational」の2つに集計した列を加えた9項目で計算されます。集計元はAppenとDataoceanAIの非公開データセット11本です。数字だけ並べれば、今回の3.81のほうが良いことになります。
中身は3つのモデルの合議です。原文は「Orze-ASR-3Way is a three-checkpoint composite (ensemble) for English ASR. It is not a standalone checkpoint.」。合計パラメータは96.4億で、3つのモデルを順番に走らせる構成です。
そのぶん速度は大きく落ちています。この合議の処理速度は29.66という指標値で、基準に据えたモデル単体が自らのモデルカードで示す74.01の4割ほどしかありません。単体では4.33だった平均WERを3.81まで下げるために、実行時間を大きく払う設計です。
提出したプルリクエストを、約18時間後に自分で閉じた
経過が細かく残っています。モデルの公開は日本時間8月23日9時6分、ランキングへの登録を求めるプルリクエストを出したのがその3分後の9時9分でした。
ただし、後戻りの兆しは早い段階からありました。提出の約1時間20分後には、運営のメンバーを名指しして「3つのモデルの合議であって単体のモデルではない」と自ら開示し、数値は自己評価でベンチマークに合わせ込んだものだと断ったうえで、非公開データセットでの検証にも応じられると添えたコメントを出しています。
流れが変わったのはその後です。日本時間8月24日3時2分、提出者自身がプルリクエストを閉じました。理由として書かれた原文は「Withdrawn because composite/ensemble systems are not eligible for this leaderboard.」。合議型の仕組みはこのランキングの対象外だから、という説明です。
取り下げの約2分半後、ランキング用の成績申告ファイル（.eval_results/open_asr_leaderboard.yaml）も、Hugging Face側のモデルのリポジトリから自ら削除しています。
モデルカードに「順位を与えてはならない」と書いた
現在のモデルカードには、資格に関する節が加わっています。原文はこうです。「This repository is a research and reproduction artifact, not an eligible Open ASR Leaderboard submission. Orze-ASR-3Way combines three checkpoints, and the leaderboard does not allow composite/ensemble systems.」。
続けて、いちばん踏み込んだ一文が来ます。「The system must not be assigned or presented with an official leaderboard placement or rank.」。公式の順位を与えたり、順位付きで紹介したりしてはならないという書き方です。
数字の性質についても自分で限定しています。「The results below are self-evaluated, benchmark-fitted development measurements only.」。
公開テストセットの点数を、候補選びやデコード設定の調整そのものに使ったとも明記しており、「The public results were actively used in system selection and should not be interpreted as a blind-test comparison.」と書いています。
一方で、経過を美化しないよう書いておきます。公開初版のモデルカードには、この資格に関する断り書きが一切ありませんでした。約16時間半後の版でようやく審査待ちという説明が入り、その1時間半後に取り下げに至っています。最初から潔かったのではなく、段階的な自己修正でした。
なお合議型を禁じる規定そのものは、ランキング側の説明文や提出用のひな形を確認した範囲では見当たりませんでした。対象外だと述べているのは提出者側です。それでも、モデルカードの3つの版（公開初版・中間版・現行版）すべてを固定文字列で検索した範囲では、順位や「最高」を主張する記述は1件も出てきませんでした。
所感：その数字を誰が測ったのかを、出した側が自分で書き足していた
ベンチマークの数字は、良いほど大きく掲げられるのが普通だと思います。今回はその逆でした。
しかもモデルカードには、その数字が自己評価であること、公開スコアを見ながら調整した結果であることまで書いてあります。つまり読み手が過大評価しないための材料を、出した側が自分で並べています。
精度をうたう資料を読むとき、その数字を誰が測ったのかを見る癖をつけておくと外しにくくなります。今回はその見分け方の教材として、よくできた例だと思いました。
10本を貫く流れ：発表の言葉と、原典に書いてあることの距離
10本を並べて最初に気づくのは、この24時間に主要ラボからの新しい対話モデルの発表が1本もなかったことです。代わりに並んだのは、AIの外側にあるものと、AIを呼ぶ側の設定でした。
AIの外側が動いたのが2本あります。①はテキサス州の電気、②は米国の法律の話です。どちらもモデルの性能とは関係ないところで、AIの置かれ方が変わろうとしています。
AIを呼ぶ側の設定が動いたのが3本です。④はGrokをより深く考えさせる指定、⑤はMCPツールの自動承認、⑥は更新チャンネルの選択。使う側が触れる範囲の話が続きました。
日本発が3本で、⑦⑧は同じ媒体の同じ筆者が同じイベントから書いた2本、⑨は独立した発表です。⑦は社外向け、⑧は社内向け、⑨は消費者向けと、AIを置く場所がきれいに分かれています。
そして今日いちばんはっきりしていたのは、発表の言葉と、原典に書いてあることの距離でした。①は番組で「新設の一時停止」、州の文書では「接続申請の停止」。⑤は「バグ修正」の1行の裏で判定処理が消えていました。
⑦は見出しが「抑えめに」で要件が「消す」、⑨は「字幕」でも日本語訳は出ません。③は任意コード実行の修正が140項目の1行に埋もれ、⑩は数字を持っている側が順位を辞退しました。
どれも嘘ではありません。ただ、一次情報を開くと話の形が変わります。今日の10本は、そのことが揃って出た日でした。
まとめ：テキサスからBoson AIまで、8月24日の10本
2026年8月24日のAIニュース10選を、1行ずつ振り返ります。
- ①テキサス州アボット知事がABC「This Week」でデータセンターの一時停止を説明。ただし州の公式文書が止めているのは送電網への接続申請で、建設ではない
- ②OpenAI渉外トップのレヘイン氏が、オープンソースモデルによる終わらないサイバー攻撃を警告し、全米一律の法律を要求。公式発表ではなく英ガーディアンの取材記事
- ③Rayが2.58.0で任意コード実行と認証バイパスを修正。ただし140項目の変更履歴に1行ずつで、この2件にCVE番号は付いていない
- ④Copilot CLIの先行版がGrok 4.6のxhigh推論に対応。安定版は1.0.80のままで、普通にインストールしても入らない
- ⑤Clineの「バグ修正」1行の裏で、MCPツールの個別許可の判定が丸ごと消えた。トグルがオンなら全ツールが確認なしで実行される
- ⑥Claude Codeの2.1.241は変更履歴が1行だけで、前日の2.1.240も同じ。安定版チャンネルは10バージョン前の2.1.231で止まっている
- ⑦カインズがくらシェアにAI投稿サポート。型・トーン・言いたいことの3つだけ人に入力させ、AIに全部書かせない設計。講演は7月30日で、8月24日は記事の公開日
- ⑧ニトリHDが分析用テーブル2,600本超の基盤で、説明欄の作文によって会話型分析を実現。新しい製品ではなく「説明の作文」が解決策だった。8月24日は記事の公開日で、企業側の発表日ではない
- ⑨ネイティブキャンプが講師の英語をリアルタイムで文字表示する字幕機能を発表。出るのは英語のままで日本語訳は出ず、8月23日は配信日で提供開始日ではない
- ⑩Boson AIが公開7データセットの平均で公式結果表の最良値を上回る自己申告値を出しながら、合議型は対象外だとして提出を自ら取り下げた。モデルカードには順位を与えるなと明記している
とくに取り違えやすい点を、3つ挙げておきます。
- ①を「テキサスでデータセンターの建設が止まった」と読むと外します。州知事府の8月6日のリリースが止めているのは係属中の系統接続申請で、解除の条件はERCOTの監査完了です。着工に州の承認は要らないと知事自身が番組で述べています
- ②を「OpenAIが発表した」と読むと外します。これは英ガーディアンの取材記事です。openai.comの渉外セクションのインデックスとニュースRSSを確認しましたが、対応する公式掲載は見当たりませんでした
- ③を8月17日にCISAが指定したRayの脆弱性と混ぜると外します。そちらはCVE-2025-62593で修正版は2.52.0です。今回の2件は別で、2.58.0のリリース本文にCVE-2025-62593への言及は1回もありません
今日の10本は、新しいモデルが出なかった代わりに、発表の言葉と原典の距離が揃って見えた日でした。
気になったニュースがあれば、原典を1つだけ開いてみてください。見出しで受け取った形と違っていることが、思ったより多くあります。
よくある質問（FAQ）
Q1. テキサスでAIデータセンターの建設は止まったのですか。
建設そのものは止まっていません。テキサス州知事府が8月6日に出したリリースが明文化しているのは「pause all pending data center interconnection requests」で、対象はERCOTの送電網への接続申請です。解除の条件は各案件がERCOTの包括監査を終えることで、期間の定めはありません。番組ではアボット知事が「新規データセンターが州内の運用に加わることに一時停止をかけた」と語り、聞き手のジョナサン・カール氏がそれを「a moratorium on data center construction」と言い換えていますが、知事自身が同じ番組で、着工には州の承認が要らないのが現行法だと説明しています。なお番組で挙げられた4条件に「地域の同意」は含まれておらず、州知事府がこの件で出したリリースを6月10日から8月18日までさかのぼって私が読んだ範囲でも、同意を義務づける要件は見当たりませんでした。背景としては、ERCOTが審査中の接続申請が474ギガワットを超え、その約90%がデータセンターであることが8月3日のリリースに書かれています。
Q2. Rayを使っています。今日すぐ更新すべきですか。
使い方によります。今回の2.58.0で直った任意コード実行は、Ray Dataで自分の管理外にあるデータセットを読む場合が対象です。社外から提供されたデータや共有バケットを読んでいるなら、更新を今日の作業に入れる価値があります。もう1件の認証バイパスは、トークン認証を有効にしているクラスタが対象で、Rayでは既定が無効なので、既定のまま使っているなら認証の素通りそのものは起きません。ただし同じ修正はTLSにも及んでいて、RAY_USE_TLSを有効にしているクラスタでも、この内部サーバーはその設定を見ずに平文のまま立っていました。あわせて確認したいのが、pickle列の読み込みを許可する環境変数RAY_DATA_AUTOLOAD_PICKLE_OBJECT_SCALARを1にしていないかどうかです。設定していると2.58.0でも従来どおり読み込まれます。Rayクラスタでは全ワーカーノードに設定する必要があるとエラーメッセージ自身が書いているので、runtime_envの指定、Dockerfile、Kubernetesのマニフェストまで含めてこの名前を探しておくと安全です。なおこの2件にCVE番号は付いておらず、GitHubのセキュリティアドバイザリにも該当がありません。脆弱性情報を自動で追う仕組みには引っかからないので、変更履歴を自分で見る必要があります。
Q3. Clineを使っています。何か設定を見直す必要がありますか。
自動承認の設定を一度開くことをおすすめします。v4.1.15から、MCPサーバーを使うトグルがオンになっていると、接続中のサーバーの全ツール呼び出しが確認なしで実行されます。このトグルはClineの既定でオンなので、設定を触っていない人も対象です。以前あった「このツールだけ自動承認する」という個別のチェックは、承認の判定から外されました。設定画面のチェックボックス自体はv4.1.15にも残っていますが、オンでもオフでも結果は変わりません。リリースノートは全ツールが対象になること自体は書いていますが、個別指定に戻す方法は書かれていません。トグルをオフにするか、接続しているMCPサーバーを棚卸しするのが今日できる対処です。MCPのツールにはファイルを操作するものも外部に送信するものもあるので、全部まとめて確認なしになる状態は把握しておく価値があります。なお安定版はv4.1.15で、モデル一覧の更新もこれに含まれています。
筆者より
前回の記事から6日空きました。今回は直近24時間、日本時間8月23日7時20分から8月24日7時17分までを対象にしています。米太平洋時間では8月22日（土）15時20分から8月23日（日）15時17分にあたる時間帯で、企業の発表は少ない窓でした。
今日いちばん時間を使ったのは、選んだ10本を一次情報で確かめ直す作業でした。結果として、下調べの段階で有力に見えていた2本を落としています。
1本目はOllamaの0.33.0です。更新の一覧に新しい版が出ていたので、Claude Desktopとの連携が入った正式版が公開されたと判断しかけました。ところがリリースページを開くと404で、タグの一覧にも正式版の「v0.33.0」はありませんでした（あるのは「v0.33.0-rc0」から「rc2」までの先行タグだけです）。更新フィードにだけ下書きが漏れていた状態でした。存在しないリリースの内容を引用しかけたということです。
2本目はllama.cppの開発元が公開した中国発モデルの量子化版です。窓の内側に公開されたのは事実でしたが、公開から半日でダウンロードが0件、いいねが1件でした。実体が薄いと判断して落としています。
窓や裏取りの基準で見送ったものも3つあります。1つ目はOpenAIによるGPT-5.6 SolのAPI値下げです。読者に効く話ですが、公式Xの投稿時刻が日本時間8月22日4時34分で、48時間まで広げても窓に入りませんでした。
2つ目はオランダの個人データ保護当局がUberに科した8億2,499万ユーロの制裁金です。ドライバーのアカウントを完全に自動で停止したことがGDPRの自動意思決定の禁止に触れたという内容で、AIに業務判断をさせる企業には重い話でした。ただし発表は8月21日で、窓の内側にあるのは英語圏メディアの後追い記事だけでした。
3つ目はHugging Faceが130億ドル超（1ドル160円換算で約2兆800億円）の評価額で売却を検討しているという報道です。名前の知られた企業で金額も大きいのですが、根拠が匿名情報源による単独報道で、当事者の公式サイトを確認した範囲では対応する発表が見当たりませんでした。裏が取れないものは落とすという基準で見送りました。
⑦と⑧については、編成上の判断を書いておきます。この2本は同じ媒体の同じ筆者が、同じイベントの別のセッションを取材して、同じ朝に公開した記事です。片方に絞る案もありましたが、社外向けと社内向けでAIの置き場所が対照的だったので両方入れました。講演日は、どちらの記事にも書かれていません（両記事とも会期の「7月30～31日開催」までです）。⑦については登壇したシステムサポートの告知（7月1日付）に7月30日14時00分からと出ていましたが、⑧の講演がイベント2日間のどちらだったかは分かりませんでした。どちらも8月24日は記事の公開日です。
このほか、Cloudflareのシンガポール拠点で48分間の障害があったこと、愛知県西尾市役所が少人数の対話型AI研修を始めたこと、教育AIサミット2026の開催レポートが公開されたことなども窓内で確認しましたが、10本には届きませんでした。
事実関係の誤りや新しい情報にお気づきの点があれば、コメント欄で教えてください。
参考資料
- ABC News「This Week」トランスクリプト（2026年8月23日放送分）および同日の関連記事（アボット知事の一時停止に関する発言、番号を振った4条件、地域の同意に関する別発言、事業者への批判、トランプ大統領のVTR発言、ニューヨーク・タイムズ報道としてカール氏が引用した承認日数、Cook Political Reportによるテキサス上院選の評価、7月のFox News調査で自分の地域へのデータセンター建設に反対する登録有権者が70%とされていること、収録が8月21日に州知事公邸で行われたこと、速記録である旨の断り書き、番組全文にERCOT・執行命令・一時停止の開始日の記載が0件で、解除の条件として語られているのは「standardsへの適合」であり州文書の「ERCOTの包括監査の完了」は出てこないことを確認）
- テキサス州知事府のニュースリリース（6月10日のPUC委員長とERCOT最高経営責任者宛の書簡、8月3日の包括監査の指示、8月6日の「pause all pending data center interconnection requests」の明文、審査中の接続申請が474ギガワット超でその約90%がデータセンターであること、州の公式標準が5項目であること、8月10日から18日にかけてOpenAI・Meta・Google・Microsoft・Amazon・Anthropic・Oracle・CoreWeaveが順守を表明した社名入りリリースが出ていること（AmazonとGoogleの反応、およびシェブロンによるマイクロソフト向け発電所計画が8月6日のリリースにも記載があること）、6月10日から8月18日までさかのぼって読んだ範囲の本文に地域の同意を義務づける要件と執行命令の語が無いことを確認。なおPUCTとERCOTの各サイトはcurlに対して403を返し、命令書と市場通知の実物は確認できていない）
- The Guardian「’We are hitting a different chapter’: OpenAI leader warns of threat of ‘persistent’ AI cyber-attacks」（ロバート・ブース記者による取材記事。公開が日本時間8月23日17時0分27秒であること、レヘイン氏の肩書き、オープンソースモデルによる継続的攻撃への警告の逐語、全米一律の法律と義務的な安全基準の要求、米国版から国際版へという順序、立法の時期の見通し、記事本文にfederalの語が0件であること、「reckless」という批判の発言者がクルーガー氏であること、ココタジロ氏が昨年設立した団体による絶滅確率10〜30%の記述を確認）／OpenAI公式（渉外セクションのインデックスとニュースRSSを取得し、レヘイン氏の当該発言に対応する掲載が見当たらないこと、8月18日の文書に配備予定モデルの強化学習を2週間止めた記述があること、その「2週間」がガーディアン記事には出てこないことを確認）
- GitHub ray-project/ray のリリース ray-2.58.0、PR #64881とPR #65189の差分、同リポジトリのソース（python/ray/data/_internal/object_extensions/arrow.py、python/ray/data/_internal/datasource/parquet_datasource.py、python/ray/serve/_private/replica.py を ray-2.52.0 から ray-2.58.0 までの各タグで確認）、同リポジトリのセキュリティアドバイザリ、GitHubアドバイザリデータベース、PyPI、米CISAの既知悪用脆弱性カタログ（リリース公開が日本時間8月23日14時42分8秒であること、任意コード実行と認証バイパスの修正の逐語とPR番号、変更履歴の箇条書きが140項目でこの2件が1行ずつであること、ハイライト5項目にセキュリティが含まれないこと、この2件にCVE番号が付いておらずアドバイザリにも該当が無いこと、本文中のCVE2件がjackson-databindの更新に付随するものであること、CVE-2025-62593への言及が本文にも生HTMLにも0件であること、pickle列の読み込みを許可する環境変数の存在、内部サーバーが保護されない状態が2.54.0以降であることを確認）
- GitHub github/copilot-cli のリリース v1.0.81-8、npmレジストリ、GitHub Docsの対応モデル一覧とCopilot CLIリファレンス、github.blogのチェンジログ（公開が日本時間8月23日23時46分であること、リリース本文が4項目であること、「Add xhigh reasoning effort support for Grok 4.6」の逐語、配布タグの最新が1.0.80で先行版が1.0.81-8であること、安定版が8月14日から据え置きで先行版が9本出ていること、Grok 4.6が有料5プラン対象で組織では管理者の有効化が要ること、Copilot CLIリファレンスの「CLI command reference」に「–effort=LEVEL, –reasoning-effort=LEVEL」と段階「low, medium, high, xhigh, max」が載りmaxがAnthropic系モデル向けの最深段と説明されていること、「CLI configuration directory」に設定項目effortLevelの値として”xhigh”が載っていること、一方でxhighのクレジット倍率はこれらのページにもリリース本文にも書かれていないこと、リファレンスの目次ページと対応モデル一覧のページにはxhighの語が0件であることを確認）
- GitHub cline/cline のリリース v4.1.14 と v4.1.15、同リポジトリのモデルカタログと設定ファイルの差分、npmレジストリ、AnthropicのClaude Fable 5の提供状況に関する公式ドキュメント（両版の公開時刻、登録プロバイダが180で変わらずモデル登録数が5,461件から5,492件へ増えたこと、追加38件と削除7件の内訳、Claude Fable 5が前版から27プロバイダで登録済みで今回の追加がVertex経由の1件のみであること、Anthropic直の設定が前版と同一であること、リリースノートの「Grok 4.6 on Vertex」がClineのVertexプロバイダではないこと、v4.1.15でツールごとの自動承認判定が削除されていること、v4.1.13からv4.1.14で既定モデルが変わったのが11プロバイダで、SDK 0.0.78のリリースノートの名指しは6つであること、v4.1.14とv4.1.15では設定ファイルに差分が無いことを確認）
- GitHub anthropics/claude-code のリリース v2.1.241 と CHANGELOG.md、npmレジストリ、Claude Code公式ドキュメント（npm公開が日本時間8月23日8時58分33秒でGitHubリリースが9時52分16秒であること、2.1.241と2.1.240の変更履歴がいずれも1項目であること、2.1.239が59項目で8月18日の2.1.234が51項目であること、同じ1行の書き方が全体で8回あり最古が6月5日公開の2.1.165であること、配布タグの安定版が2.1.231で最新が2.1.241であること、2.1.231の公開が8月13日であること、パッケージ管理ツール経由では自動更新されないこと、変更の中身とCVE番号が当該2か所に書かれていないことを確認）
- ITmedia ビジネスオンライン「口コミ増やしたい、でも“AIが書いた感”は抑えめに……カインズ、『自社商品の投稿』促すAI機能どう開発した？」（公開が日本時間8月24日7時5分であること、3つの入力ポイントの逐語、田伏氏の発言、必須要件を述べた一文で「生成AIらしさは消す」と書かれていること、サイト上の案内文、取材元がGoogle Cloud Next Tokyoの講演セッション「生成AIで実現するtoCサイトのリッチ化。カインズが挑む顧客体験の進化」であること（記事に書かれているのはイベント会期の「7月30～31日開催」までで、講演日そのものの記載はないこと）、開発元がシステムサポートの「GEN-STEP」でモデルがGoogleの「Gemini」であること、提供開始日・開発費・投稿数の増加率が本文に書かれていないこと、会員限定記事であることを確認）／株式会社システムサポートのお知らせ「「Google Cloud Next Tokyo ’26」 カインズ様とのスポンサーセッション登壇のお知らせ」（2026年7月1日付。スポンサーセッションが2026年7月30日（木）14時00分〜14時30分・Room7であることを確認）／カインズ公式サイト（くらシェアのサービス開始が2024年9月18日であること、ニュースリリース一覧に当該機能の発表が見当たらないことを確認）
- ITmedia ビジネスオンライン「『社内用語』がAI分析を邪魔する……ニトリが“力技”で解決 『赤羽店の寝具の売上高を出して』可能にできたワケ」（公開が日本時間8月24日7時10分であること、小林桂氏の発言の逐語、分析用テーブルが2,600本超であること、2021年の検討開始と2022年後半の稼働、社内命名規則のカラム名の例、説明欄への記述という対処法、伝票種別のコードの整備例、「抽出はAI、分析は人」という考え方、上位5つ程度から始めればよいという助言、本文で名指しされている製品がGoogle CloudとBigQueryの2つだけであること、生成AIのモデル名とBI製品名と定量的な効果が2ページのどこにも書かれていないこと、Knowledge Catalogの語が講演スライドの画像にのみ出ることを確認。⑦の記事と筆者と取材元が一致することも確認）
- PR TIMES 株式会社ネイティブキャンプのプレスリリース「『聞き取れない』をその場でサポート。ネイティブキャンプ、講師の発話をリアルタイムで文字表示する『字幕機能』をリリース」および同社公式FAQ（配信が日本時間8月23日16時であること、字幕の切り替え方と使い分けの想定の逐語、精度と遅延に関する2つの注記の逐語、講師15,000名以上・教材32,000以上・累計レッスン8,000万回超という規模、提供開始日がリリース本文に書かれていないこと、公式FAQの当該記事が7月23日公開であること、日本語訳の字幕を自社独自の機能として提供していないと公式FAQが明記していること、対象レッスン形式・対応端末・対象プラン・追加料金・音声認識の提供元がリリース本文に書かれていないことを確認）
- Hugging Face の bosonai/Orze-ASR-3Way のモデルカード（現行版・公開初版・中間版の3版）とAPI、huggingface/open_asr_leaderboard のプルリクエスト206番と同リポジトリの説明文および提出用ひな形、Open ASR Leaderboardの公開結果データ（モデル公開が日本時間8月23日9時6分でプルリクエストの提出が9時9分、取り下げが8月24日3時2分30秒、成績申告ファイルの削除が3時5分8秒であること、自己申告の平均WERが3.81で公開結果65機種の最良値が4.06であること、3モデル合議で合計96.4億パラメータであること、処理速度の指標が29.66で、基準に据えたbosonai/Qwen3-ASR-1.7B-hf-orzeのモデルカードが示す単体の値が74.01であること（公開結果表にある819.67はその基となるQwen/Qwen3-ASR-1.7B-hfの値で、合議の部品そのものではないこと）、資格に関する記述と「順位を与えてはならない」の逐語、自己評価であることと公開スコアを選定に使ったことの明記、公開初版には資格の断り書きが無かったこと、3版すべてに1位や最高に相当する主張が0件であること、合議型を禁じる明文規定がランキング側の説明文と提出用ひな形には見当たらないことを確認）
この記事が気に入ったら
フォローしてね！
お気軽にコメントどうぞ