DISPATCH №0731 / 2026-07-31 / MORNING EDITION / 07 ITEMS / BUILD 20260731.0739 / LIVE / CURATED BY 泉水亮介
VCB News & Post Headline
JST · 07:39 · THU
MORNING DISPATCH · THURSDAY · JULY 31, 2026

2026.07.31

OpenAI · ベンチマークはモデルだけを測っていない · Cursor · Devin 07 ITEMS · READ 5 min
📰 モデル運用・自己改善 / @OPENAI(公式) / NEWS

OpenAI が GPT-5.6 Sol に自分自身を最適化させた — サービングコスト20%減

OpenAI が GPT-5.6 Sol に自分自身を最適化させた — サービングコスト20%減

デプロイ済みの GPT-5.6 Sol を「自分自身の実行効率を上げる」作業に適用した結果を OpenAI 公式が公開した。本番 GPU カーネルの改善でサービングコストが20%下がり、投機的デコーディング(speculative decoding)の改善でトークン生成効率が15%以上向上した。@OpenAIDevs も同日、Codex で GPT-5.6 Sol を使って自社インフラとパフォーマンスを最適化したと報告している。

キーポイント

  • 本番 GPU カーネルの改善でサービングコスト20%減
  • 投機的デコーディングの改善でトークン生成効率が15%以上向上
  • OpenAI は「これらの最適化はスタック全体で複利に効き、コスト×知能カーブのあらゆる地点で最も高性能なモデルを解放する」と位置づけ
  • Codex 側でも同じ手法で自社インフラとパフォーマンスを最適化したと @OpenAIDevs が報告
  • 「自己改善」が研究テーマではなく本番の原価低減として報告されたのが今回の新しさ
  • ⚠️ 改善率はいずれも OpenAI 自身の測定で第三者検証なし。値下げに直結するかは非言及
モデルが自分の推論基盤を速くするという構図が、研究の話ではなく本番の原価低減として初めて数字つきで報告された。推論コストが下がれば、これまで採算が合わなかったループ運用や常時稼働エージェントの前提が変わる。
📰 ハーネス設計・エージェント運用 / @OPENAI(公式・5連スレッド) / NEWS

ベンチマークはモデルだけを測っていない — API 設定2つでスコア3倍・出力トークン1/6

ベンチマークはモデルだけを測っていない — API 設定2つでスコア3倍・出力トークン1/6

数学の未解決問題を解いた GPT-5.6 Sol が、なぜ2Dパズルゲームのベンチマーク ARC-AGI-3 で苦戦するのかを OpenAI 自身が調査した。原因はモデルではなくハーネスで、標準ハーネスは1手ごとに推論を破棄し、コンテキストが埋まると過去の行動から捨てていたため、モデルは毎回ゼロからやり直していた。Responses API で実装し直し、設定を2つ有効化したところ公開セットのスコアが188%上昇し、出力トークンは6分の1になった。

キーポイント

  • 標準ハーネスの問題は2つ — 1手ごとに推論を破棄/コンテキストが埋まると過去の行動を捨てる。結果「モデルは毎回やり直していた」
  • 有効化したのは Retained reasoning(推論の保持)と Context compaction(コンテキストの圧縮)の2つだけ
  • 公開セットでスコア188%上昇(約3倍)、同時に出力トークンは6分の1。強くなり、かつ安くなった
  • OpenAI の結論は「evals がモデルを単体で測ることはめったにない。API 設定・ハーネス設計・プロンプトという、見えにくい選択の束も一緒に測っている」
  • 長時間動くエージェントでは「推論を保持しコンテキストを圧縮することで、モデルは既に学んだことの上に積み上げられる」
  • ⚠️ 公開セットでの自社測定。他モデル・他ベンチへの一般化は示されていない
「うちのエージェントの成績が悪いのはモデルのせい」という診断を、モデル提供者自身が真っ向から否定した。モデルを乗り換える前に、推論を保持しているか・コンテキストをどう畳んでいるかを見直すほうが効く可能性がある。
📰 開発ツール / @CURSOR_AI(公式) / NEWS

Cursor が iPad に対応 — エージェントの作成・レビュー・マージがモバイルで完結

Cursor が iPad に対応 — エージェントの作成・レビュー・マージがモバイルで完結

Cursor が iPad アプリを提供開始した。「iPhone 版の全機能を、エージェントと作業するためのより広い画面で」という位置づけで、どこからでも作成・レビュー・マージができる。iPhone / iPad の両方に、整理用の inbox と、コメント・チェック・承認まで含めて PR 全体をカバーするレビュー体験が新たに加わった。

キーポイント

  • iPad 対応。「iPhone の全機能を、エージェントと作業するためのより広い画面で」
  • どこからでも作成・レビュー・マージができる
  • iPhone / iPad 共通の新機能① inbox(整理用の受信箱)
  • iPhone / iPad 共通の新機能② PR 全体をカバーするレビュー体験(コメント・チェック・承認を含む)
  • モバイル側の役割が「コードを書く道具」から「走らせたエージェントの結果を確認して取り込む窓口」に寄った
  • ⚠️ 対応プランや無料枠の扱いは投稿に非記載
クラウドで走るエージェントが前提になると、人間の仕事は書くことより「確認して取り込むこと」に移る。その窓口が手元の端末に来たことで、待ち時間が実質的に消える。
📰 開発ツール / @COGNITION(公式) / NEWS

Devin が GitHub の Stacked PR にネイティブ対応 — 巨大 PR を自動で分割

Devin が GitHub の Stacked PR にネイティブ対応 — 巨大 PR を自動で分割

Cognition が Devin の GitHub Stacked PR 対応を発表した。大きな変更をレビュー可能な小さい diff に分割し、スタックをまたいでコメントに対応・修正し、下流の変更を自動でリベースする。従来も指示すればスタックド PR は作れたが、この動作がデフォルト化した点が変化にあたる。

キーポイント

  • ①大きな変更をレビュー可能な小さい diff に分割する
  • ②スタックをまたいでコメントに対応・修正する
  • ③下流の変更を自動でリベースする
  • 従来も指示すれば作れたが、ユーザーが指示しなくても適切な粒度に分解する動作がデフォルト化した
  • レビュー往復のたびに人が手で下流をリベースし直す手間が消える
  • ⚠️ 分割粒度の妥当性は実運用での評価待ち。GitHub 以外のホスティングへの対応は非言及
エージェントに大きなタスクを任せると PR が巨大化してレビュー不能になる、というのがエージェント開発の最大の詰まりどころだった。生成の速さではなく、レビューの通しやすさに手が入った点が実務的に効く。
💼 AI×ビジネス活用 / @KAJIKENT(梶谷健人) / NEWS

〈知見〉「Claude Code を配って生産性は上がったのに、事業の数字が変わらない」

〈知見〉「Claude Code を配って生産性は上がったのに、事業の数字が変わらない」

梶谷健人が「社員に Claude Code を配って生産性は上がったのに、事業の数字は変わらない。次は何をしたら良いか?」という相談を多くの経営者から受けていると報告した。論点は「個人のタスク効率化を終えたあと、次に何をどうすればいいのか」。同じ問題は Sierra の Neil Rahilly も「セッション数やツール呼び出し数は活動であって成果ではない」という形で言語化しており、日米で同時に同じ診断が出ている。

キーポイント

  • 相談の中身は「個人のタスク効率化を終えたあと、次に何をどうすればいいのか」
  • ツールの配布は活動指標を確実に動かすが、事業指標は別に設計しないと動かない
  • 同型の指摘(Sierra / @neilrahilly): 「チームは tokenmaxx して見栄えのいい採用グラフを作り上げることができてしまう——下流では何も良くなっていないのに」
  • 対処の型は3ステップ — ①導入前に現状のサイクルタイムを1つだけ測る(商談の決着日数/一次解決率/レビュー滞留時間のどれか)②活動指標で習慣化を確認する ③同じ指標を再測して差分を見る
  • ①を飛ばすと後から比較できないのが最大の落とし穴
  • ⚠️ note 本文は月額メンバーシップ限定でフレームワーク・数字・事例は未確認。ここで扱うのは公開されている問題設定と、対になる海外事例まで
AI 導入の次の壁が「配ったのに数字が動かない」であることが、日米で同時に言語化され始めた。導入提案を書く側は、最初から「何が変わったら成功か」を1行入れておかないと数か月後に詰む。
🧠 コンテキストエンジニアリング / @KENN(KENN EJIMA) / BOOKMARK

AI 向けドキュメントは4層構造にする — 概要 html > 詳細 md > テスト > コード

AI 向けドキュメントは4層構造にする — 概要 html > 詳細 md > テスト > コード

「人間向けの短いドキュメントだけで AI は問題なく働けるか、それとも人間用と AI 用を分けるべきか」という問いに、Kenn Ejima が「分ける」と即答した。根拠は「推論トークンが知能を上限なくスケールさせるのは既知の事実なので AI 用のメモは必須」。さらに運用フローと、層が食い違ったときにどれを信じるかの序列まで具体化している。

キーポイント

  • 結論は分ける。人間向けの短いドキュメントと AI 向けの長いドキュメントを両方持つ
  • ライフサイクル: プランは md → 実装が終わると仕様書に昇格 → そこから人間用サマリー html を生成
  • html は css と js をコロケートしつつ分離し、html 単体はトークン効率重視にする(読むたびのトークンを無駄にしないため)
  • 序列は 概要仕様(html) > 詳細仕様(md) > テスト > コード で、下に行くほど truthy
  • 使い方: 仕様書 vs 実装ならコードが正しい/テスト vs 仕様書ならテスト。覚え方は「一番読みやすい層が一番嘘をつきやすい」
  • ⚠️ 個人の運用知見で定量検証なし。二重管理は md→html の生成が自動化されている前提(手で二重に書くと必ず片方が腐る)
エージェントを増やすほど「同じことについて複数の記述がある」状態になる。衝突時の優先順位を先に決めておかないと、腐った仕様書を根拠に動いているコードを壊す事故が起きる。
💼 AI×ビジネス活用 / @NEILRAHILLY(SIERRA / X ARTICLE) / BOOKMARK

〈知見〉役割別エージェントを4体作って失敗し、1体に戻した — Sierra の5つの学び

〈知見〉役割別エージェントを4体作って失敗し、1体に戻した — Sierra の5つの学び

AI エージェント企業 Sierra が、全社員向け社内エージェント「Pinecone」を内製する中で得た知見を5点にまとめている。サポート・データ分析・エンジニア・営業の4体に分けたが実践で失敗し、窓口を1体に統合した。600人以上・75,000セッション超が稼働し、PR の70%がここを通る規模で運用されている。

キーポイント

  • ①エージェントは単数に集約する — 役割別4体は失敗。理由は記憶負荷ではなく構造で「最も重要な仕事はチーム内ではなくチーム横断で起きる」。統合後は1ハンドル・1 URL・途切れない1スレッド
  • ②リアクティブでなくプロアクティブ — webhook 発火・タスク着地・レビュー到着でエージェント側からファーストパスを書く。「通知を増やすのではなく、未完成のまま届く仕事を減らす」
  • ③ボトルネックは知能ではなくビジネスコンテキスト — フロンティアモデルはすでに十分賢く、制約は自社固有の文脈側に移った
  • 権限は「利用者の権限を継承」で解く — MCP Gateway が各社員のアクセス権を継承し、全ツール呼び出しでポリシー強制・顧客データ隔離・監査証跡
  • ④エージェントが UI、システムオブレコードがバックエンド — GitHub / Salesforce / Linear は置き換えず横断レイヤーに徹する。「デッキを締めて」と頼めばデッキ自体が更新されて返る
  • ⑤活動量ではなく成果 — 「持続的な優位は基盤モデルの所有ではなく、コンテキスト・ワークフロー・ルーティング層の所有」とも明言
  • ⚠️ 自社ブログの自己申告で統合前後の定量比較はなし。「5倍」の測定方法も非提示
「部署ごとに AI を入れる」提案は直感的に通りやすいが、最も価値のある仕事は部署をまたぐところで起きる。実際に分けて失敗した会社の記録は、導入設計の初手を決める材料になる。
📄 PDFをダウンロード 🧵 X スレッドで読む