5/25 のアップデート

Microsoft Research が Webwright を公開：2026年5月24日、Microsoft Research が「ターミナルネイティブ」な Web エージェント枠組み Webwright を発表した。クリック軌跡を逐一たどる従来の Web 自動化を「再利用可能な Playwright スクリプト」に置き換え、3 モジュール／約 1,000 行のシンプルな単一エージェントループで構成されている。GPT-5.4 を組み合わせた構成で、長時間タスクのベンチマーク「Odysseys」を 60.1%（ベース GPT-5.4 単体は 33.5%）、Online-Mind2Web を 86.7% で通過し、オープンソースなハーネスとしては当時最高の AutoEval スコアを記録。「複雑なオーケストレーションより、ツール側（再利用可能スクリプト）を太らせる」という設計指針は、本記事で触れた「道具箱を賢くする」考え方の実証例にあたる。

先月までの Web エージェントといえば、「ブラウザ上をクリックしながら目的地まで案内する」という逐次操作が主流でした。ページが変わるたびにモデルが判断し直すので、長めのタスクは途中で詰まることが多く、実用デモは短い操作しか見せられない状態でした。GPT-5.4 だけでベンチマーク Odysseys を 33.5% しか通過できない、というのが現状の数字です。今回、Microsoft Research が「クリック」ではなく「再利用スクリプト」でタスクをこなす設計を持ち込み、同じベースモデルで 60.1% まで引き上げました。

「Web 上の作業を AI に任せる」という実験が、本番運用を見据えた話になってきます。フォーム入力・データ収集・定型操作のような業務は、Webwright 系の設計が整えば社内ツールへの組み込みが現実的に。逆に、この段階では長時間・高度な判断が絡むタスクはまだ怪しく、エンジニアが監視しながら使うフェーズです。「エージェントで自動化してみたい」チームには、設計思想の参考に一読する価値があります。

Cerebras が 1T パラメータの Kimi K2.6（Moonshot AI 開発）で 981 トークン/秒を計測。次点 GPU クラウド比 6.7 倍速を独立第三者が検証したと発表。多 GPU 分割が必須な GPU クラウドに対し、Cerebras CS-3 のウェハスケール 1 チップで全モデルを保持できる構造優位を強調しており、ウェハスケール ASIC が「巨大モデル推論」で具体的な数値勝負に乗ってきたことを示している

ここ 2 年、Cerebras は「ウェハ 1 枚がチップ」という特異な構造を売りにしてきましたが、「超高速だが、どのモデルで何トークン/秒か」という具体的な数字を出す機会が限られていました。Llama 系の中規模モデルでの速度比較はあったものの、1T パラメータ級の巨大モデルで独立機関が速度を検証した例はほとんどなかった状態です。GPU クラウドが巨大モデルを複数 GPU に分割して動かすのに対し、Cerebras は 1 チップに収めるアーキテクチャが強みですが、その差が数字になったのは今回が初めてに近いです。

巨大モデルを使いたいが応答速度がネックになっている、というチームには選択肢が増えます。981 トークン/秒というのは、会話 AI をリアルタイムに使う用途でもストレスが出にくい水準です。ただし Cerebras は専用 API 経由での提供で、モデルのカスタマイズ・ファインチューニングは自由にできるわけではない点に注意。あくまで「速く推論を回したい」という用途向けの数字です。GPU クラウドと同じ感覚でモデルを組み込みたいチームには、まだ壁があります。

Google が「Dart & Flutter Agent Skills」を公開：2026年5月24日、Google は Dart 言語と Flutter フレームワーク向けの最新ベストプラクティスを AI コーディングエージェントに渡す Skills セットを公開した。SDK ベンダー自身が Skills を配布する動きで、「公式が推す書き方」をエージェントが安定して再現できる環境が増えつつある。フレームワーク選定時の「AI との相性」が、今後より明示的な判断材料になる兆候。

半年前まで、Flutter で AI コーディングを使うと「古い API を平気で使ってくる」「deprecated なウィジェットを出してくる」という声が多く、AI の提案を一度疑ってから使う手間が常についていました。コミュニティが非公式ルール集を書くことで対処していましたが、「どれが最新で正しいか」は開発者それぞれが判断する必要がありました。今回、Google 自身が公式 Skills を配布することで、AI が参照するルールの出典が公式になります。

Flutter を使っているエンジニアには、AI の提案に乗っかる判断が少しラクになります。「これ本当に最新の書き方?」と毎回確認していた手間が一段減るはずです。フレームワーク選定フェーズにいる PM や開発チームには「Google がどこまで AI サポートに踏み込んでいるか」が選定基準として浮上するのが注目点です。逆に、Dart / Flutter 以外のスタックで動いているチームには今日の話は関係薄めです。

Skills は「フックでルール強制」へ進化中：開発者コミュニティでは「Claude Code に毎回ルールを伝えるのではなく、フック（hooks）で機械的に強制する」というパターンが広がりつつある。Skills とフックは補完関係で、Skills が「どう書くか」を言語化し、フックが「逸脱したらブロック」する。AI コーディングが「お願い」から「ガードレール込みのワークフロー」に重心を移しつつある段階。

ここ半年、Claude Code や Cursor を使う開発者が「毎回同じルールを書き直している」という話は頻出でした。Skills を使えば一度登録したルールを AI が参照するようになりましたが、AI が従わなかったときに止める手段がなく、「参考程度」の扱いになりがちでした。フックは Claude Code の仕組みで、特定のアクションに反応して外部コマンドを走らせられますが、「ルール逸脱のブロック」用途での活用が広がってきたのは最近の流れです。

チームで AI コーディングを使っている場合、「AI が勝手にやらかす」リスクを仕組みで封じる選択肢が増えます。コードレビューで毎回指摘されていたような定形ミスを、フックでそもそも提出させない設定が現実的になります。「AI が不安で全レビュー必須」という状態から、「特定パターンはフックでブロック、それ以外はレビュー」に切り替えられると、エンジニアの集中力の使い方が変わります。逆に個人開発でゆるく使っている人には、ここまでの設計は過剰かもしれないです。