# oh-my-piの互換性変更とvLLMの移行条件

> oh-my-pi v18.12.1の破壊的変更とv18.12.2の操作制御を確認する。vLLM v0.32.0のPython・CORS移行条件、llama.cppのCUDA融合、Anthropicの公益基金を整理し、更新前に確かめる互換性と発表段階の条件を切り分ける。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261019
Published: 2026-10-19T06:30:00+09:00
Category: ai-digest
Tags: ai-agent, software-engineering, llm-inference, local-inference, open-source, governance, anthropic

oh-my-piは、v18.12.1で`eval`とpi-tuiのAPIに破壊的変更を加え、締め切り直前のv18.12.2ではコンピューター操作の制御も更新した。vLLM v0.32.0もPythonの対応範囲とブラウザー接続の既定値を変更している。今日の更新判断では、機能の追加より先に、既存の呼び出し方と設定が通るかを確認したい。

以下は、10月18日06:30から19日06:30までのJSTを対象とする。oh-my-piとvLLMは互換性・既定動作の変更、llama.cppは特定構成に限った性能報告として読む。Anthropicの公益基金は独立した企業方針の発表であり、株主承認や取締役会の裁量を伴う。実装済みの変更と、条件付きの方針を同じ確度で扱わないことが、この号の判断軸になる。（[oh-my-pi v18.12.1](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1) / [v18.12.2](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.2) / [vLLM v0.32.0](https://github.com/vllm-project/vllm/releases/tag/v0.32.0) / [llama.cppの変更](https://github.com/ggml-org/llama.cpp/pull/30602) / [Anthropicの発表](https://www.anthropic.com/news/public-benefit-fund)）

## oh-my-pi v18.12.1のAPI変更とv18.12.2の操作制御

oh-my-pi v18.12.1では、[AI Agent](/guides/ai-agent)が最終回答を返した後、advisorの`concern`が届くと既定で実行を再開するようになった。`advisor.continueSeverity`で、再開させる最低深刻度を`nit`、`concern`、`blocker`から選べる。従来の待機動作を維持する場合は`blocker`を指定する。（[v18.12.1の変更履歴](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)）

TLS検査プロキシが圧縮アップロードを拒否する環境では、本文がJSONではないHTTP 400、403、415、またはContent-Encoding除去後にAnthropic APIが返す「request body is not valid JSON」を検出する。該当時は本文を非圧縮で再送し、そのホストへの圧縮を停止する。（[出典1](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)）

pi-coding-agentとpi-tuiには、直接APIを呼び出している拡張の修正が必要になる。言語を指定していた表示APIはファイルパスを渡す形へ移り、Ternが構文解析に使う文法を選ぶ。（[破壊的変更の一覧](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)）

| 対象 | 変更前 | v18.12.1以降 |
| --- | --- | --- |
| Python・JavaScriptの`eval` | `display()`を利用 | `print`へ置換。JavaScriptは`console.log`も利用可能。（[変更履歴](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)） |
| `numberedCode`・`readContentCode`・`nativeDiff` | 言語を渡す | ファイルの`path`を渡す。（[変更履歴](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)） |
| `describeGroupedOutput` | `lang`オプションで指定 | `lang`オプションを削除。（[変更履歴](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)） |

出力の表現自体は維持・拡張される。出力したDataFrameやSeriesは表、大きな辞書・リスト・オブジェクトはJSONツリー、MarkdownオブジェクトはMarkdownとして表示され、図や画像を出力すると結果に添付される。（[出力表示の変更](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)）

不具合修正には、ダウンロードしたWASM形式の文法でファイルを繰り返し解析した際のネイティブメモリ増加とクラッシュへの対処も含む。また、Kitty対応端末上でtmuxの`allow-passthrough`が無効な場合は、破棄される画像プロトコルを送信せず、SIXELまたはテキスト表示へ切り替える。（[修正内容](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)）

続くv18.12.2は、10月19日06:03 JSTに公開された。DeepSeekがツール呼び出し用トークンを本文として出力した場合の処理と、Ollamaでモデルを切り替えた際の会話履歴の容量見積もりを修正した。DeepSeek Search APIを使う検索エンジン`web/deepseek`も追加している。（[v18.12.2の変更履歴](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.2)）

> [!CAUTION] 背景操作から前面操作へ切り替わる条件
> v18.12.2の`computer.backgroundFallback`は`takeover`が既定で、背景で実行できないウィンドウ入力を前面操作として再実行し、その後フォーカスを返す。`refuse`を選ぶと、その入力とエージェント自身による前面操作要求を拒否する。作業中の画面を操作させたくない場合は、この設定を先に確認したい。（[設定の定義](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.2)）

**EastBraverの見立て:** 更新の確認点は、拡張APIの移行、最終回答後の再開条件、画面操作の許可範囲の三つに分かれる。版を上げるだけで従来の挙動が保たれるとは考えず、利用中の拡張と設定を組み合わせて[AI Agent評価](/guides/ai-agent-evaluation)の対象にしたい。（[APIと再開条件](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1) / [操作制御](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.2)）

- 出典: [oh-my-pi v18.12.1](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.1)（公式リリース、2026-10-18 08:14 JST） / [v18.12.2](https://github.com/can1357/oh-my-pi/releases/tag/v18.12.2)（公式リリース、2026-10-19 06:03 JST）

## vLLM v0.32.0はPython 3.10対応を終了しCORSの既定値を変更

vLLM v0.32.0は、Python 3.10のサポートを終了し、最低バージョンを3.11へ引き上げた。依存条件は`transformers>=5.16.1,<5.20.0`と`tokenizers>=0.23.2`。既存の推論環境では、モデルを読み込めるかだけでなく、Pythonと依存パッケージの組み合わせを確認する必要がある。（[公式リリースの依存条件と破壊的変更](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)）

Python・Rust両方のフロントエンドで、CORSの許可元の既定値を`*`から許可なしへ変更した。ブラウザーから別オリジンの推論APIを呼ぶ構成では、`--allowed-origins`を設定する。`max_tokens`もコンテキストウィンドウから事前に確保する値ではなく、出力の上限として扱うようになった。Responses APIの推論ストリームは、`response.reasoning_part.added/done`から、`part.type="reasoning_text"`を持つ`response.content_part.added/done`へ移行する。（[APIと既定値の変更](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)）

機能面では、構造化した状態に対して選択や採点を行う`POST /v1/systemone`を追加した。`hf`ツール・推論パーサーはチェックポイントの`response_template`を読み取り、それを備えたモデルでは個別のモデル専用パーサーが不要になる。修正項目には、チャットテンプレートのリソース枯渇、tokenizerの`max_token_id`、P2P ZMQソケット枯渇への対処も含まれる。（[新機能と修正一覧](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)）

> [!CAUTION] 性能更新と互換性確認を分ける
> CORS設定、Responses APIのイベント名、Pythonの対応範囲は、速度が改善しても呼び出し側を壊し得る変更だ。まず利用中の接続経路と依存条件を合わせ、その後に対象モデル・GPUでの性能を比較したい。（[移行条件の根拠](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)）

**EastBraverの見立て:** この版は単なる高速化更新ではない。[LLM](/guides/llm)を配信する実行基盤と、そのAPIを読むクライアントの両方を移行対象として扱うことが、更新時の見落としを減らす。（[判断の根拠](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)）

- 出典: [vLLM](https://github.com/vllm-project/vllm/releases/tag/v0.32.0)（公式リリース、2026-10-18 15:50 JST）

## llama.cpp b11721プレリリース、Qwen4expのCUDA融合を収録

llama.cpp b11721は、10月19日03:04 JST公開のプレリリースで、コミット`ff5a233`に対応する。Qwen4exp向けの`SCALE → SIGMOID → SCALE → hc_post`という処理列を、CUDAで融合する変更を収録した。（[b11721のリリース](https://github.com/ggml-org/llama.cpp/releases/tag/b11721) / [変更PR](https://github.com/ggml-org/llama.cpp/pull/30602)）

Vulkan向けの`HC_POST_GATE`融合をCUDAバックエンドへ移植したものだ。`hc_combine`が作る重みに対し、`dsv4_hc_post_f32`内でスケールとsigmoidを計算し、従来4カーネルだった処理列を1カーネルで実行する。（[実装の説明](https://github.com/ggml-org/llama.cpp/pull/30602)）

性能について、プルリクエスト投稿者は、RTX Pro 6000上でQwen4-nextを動かした場合にTGが約3％向上すると述べている。（[出典1](https://github.com/ggml-org/llama.cpp/pull/30602)）

> [!CAUTION] 約3％は特定構成での投稿者報告
> PR本文にはRTX Pro 6000とQwen4-nextの組み合わせが示されているが、再現用コマンドや詳細な測定条件は記載されていない。他のモデルやGPUで同じ向上が得られるとは判断できない。（[報告の範囲](https://github.com/ggml-org/llama.cpp/pull/30602)）

**EastBraverの見立て:** 約3％という性能材料は、RTX Pro 6000上のQwen4-nextにおける投稿者報告である。広範なCUDA高速化ではなく、この構成に近い場合の判断材料として読むべきだ。（[出典1](https://github.com/ggml-org/llama.cpp/pull/30602)）

- 出典: [llama.cpp](https://github.com/ggml-org/llama.cpp/releases/tag/b11721)（公式プレリリース、2026-10-19 03:04 JST）

## Anthropic、企業価値に連動する公益基金への株式拠出を発表

Anthropicは、株主承認を条件に、Anthropic Public Benefit Fundへ自社株式の5％を拠出すると発表した。設定した基準から企業価値が50％上昇するごとに、取締役会の裁量で2％を追加できる設計であり、自動的な追加拠出を約束するものではない。（[拠出条件の発表](https://www.anthropic.com/news/public-benefit-fund)）

基金はAnthropicが完全所有するLLCとして設立される。LLCが保有するAnthropic株式は、米国内外のロビー活動や政治献金には使わない。（[出典1](https://www.anthropic.com/news/public-benefit-fund)）

Anthropicが示した用途は確定済みの受益対象ではなく、従来型の非営利団体への大規模寄付や、特定の人々への直接給付といった将来の活用例である。（[出典1](https://www.anthropic.com/news/public-benefit-fund)）

> [!CAUTION] 拠出方針と資金配分の実行は別
> 同社は、基金の構造・ガバナンスと追加拠出の企業価値基準を今後数カ月以内に詳しく説明するとしている。今回の発表だけでは、具体的な受益者や配分の決定手続きを評価できない。（[今後の説明予定](https://www.anthropic.com/news/public-benefit-fund)）

**EastBraverの見立て:** 注目点は企業価値の上昇に応じて公益向け持分を増やせる設計だが、現時点では条件付きの方針である。社会還元の規模や実効性は、将来の承認、取締役会判断、ガバナンスの開示と分けて評価したい。（[判断の根拠](https://www.anthropic.com/news/public-benefit-fund)）

- 出典: [Anthropic](https://www.anthropic.com/news/public-benefit-fund)（公式発表、2026-10-19 01:49 JST。公式ページの公開時刻に基づく）