BYOK の現実チェック：今の Open Design で壊れる 5 つのこと

私たちは、Open Design が根本から BYOK であると人々に伝えてきました。それは今も本当です。BYOK デザインワークフローの種記事では、動く道筋を解説しています ── daemon を任意の OpenAI 互換エンドポイントに向け、キーを貼り付ければ完了です。大半のセットアップでは、それがすべてであり、これからもそれがすべてであり続けます。

しかし「BYOK」は単一の機能ではありません。それはチャットコンポーザー、finalize エンドポイント、モデルピッカー、CLI の起動経路、そして分析レイヤーにまで及ぶ契約です。それぞれが契約の壊れうる場所であり ── 現在、そのいくつかは私たちの公開トラッカーで未解決の issue になっています。過去 48 時間にユーザーから報告されたものです。

私たちは種記事を書いてそこで止めることもできました。代わりに、ここで正直に明かします：今週入ってきたスレッド、何が壊れるのか、なぜ壊れるのか、今日何をすべきか、そしてどの PR（あるいはロードマップの枠）がそれを修正しているのか。これらはどれも隠されていません。下にファイルされ、ラベルが付き、リンクされています ── そして金曜日のデッキ作成の最中に発見するより、私たちから読んでもらいたいのです。

約束 vs バグリスト

枠組みが重要です。なぜなら、安直な誤読は「BYOK は中途半端だ」だからです。そうではありません。下の 5 つはどれも「BYOK が動かない」というバグではありません。そのどれもが、私たちが所有するアダプター ── OpenAI 互換レイヤー、モデルピッカー、finalize 経路 ── と、私たちが所有しないもの：上流プロバイダーの CLI、彼らのパッケージングの選択、あるいはホストプラットフォームのプロセスモデル ── との境界に存在しています。

その境界こそが、あらゆるオープンソースの CLI オーケストレーターにおいて現実が宿る場所です。私たちは推論を実行せず、プロバイダーごとにフォークした CLI を出荷せず、エッジを滑らかにし（そしてこっそりトークンに課税し）するプロキシですべてを包んだりしません。その姿勢の代償は、プロバイダーの CLI が形を変えたり、Windows が macOS にはない制限を課したりすると、継ぎ目が見えてしまうことです。今週は、その継ぎ目のうち 5 つが一度に見えました。

5 つすべてを、入ってきた順に挙げます。

Gemini が「Finish Design」へ向かう途中で迷子になる

Issue #1619 — bug、open

症状

BYOK が Gemini 向けに設定されている。設定の接続テストは成功する。モデルピッカーは Gemini のモデルを返す。通常のチャットは動く ── 自分の Gemini キーに対して問題なく完全な会話を続けられる。ところがユーザーが Finish Design を押した瞬間、daemon は Anthropic 形式のエラーを投げます。まるで、どのプロバイダーと話していたのかを突然忘れたかのように。

なぜ起きるのか

スレッド上のメンテナーの返信がそれを裏づけています：通常の API モードのチャットは選択された Gemini BYOK プロバイダーを端から端まで尊重しますが、Finish Design はまだ Anthropic 互換の finalize 経路を超えて一般化されていません。それ以外のすべては、各上流の方言を話す方法を知っているプロバイダー認識プロキシを経由してルーティングされます。Finish Design はまだ、以前のリリースから残るハードコードされた Anthropic の finalize エンドポイントを通っています ── そのため、非 Anthropic 形式で届く Gemini のレスポンスがパーサーを躓かせるのです。

回避策

Gemini を Anthropic 互換プロバイダーの枠の下で OpenRouter 経由でルーティングします。すると Finish Design の経路は OpenRouter のシムから返ってくる Anthropic 形式のレスポンスを見て、正しく finalize します。1 ホップ余分にかかり、Gemini を直接呼ぶのではなく OpenRouter のルーティングに支払うことになりますが、今日時点で安定しており、すでに動いているチャット経路に触れることなく、壊れている唯一の経路をカバーします。

誰が修正しているか

Finish Design の一般化は現在 BYOK ロードマップ上で P1 になっています。PR はまだありません ── これは daemon チームが次に取り上げるもので、5 つの中で唯一、境界の不一致ではなく、私たちが完全に所有するコードの欠陥です。

Gemini 3 Flash がプロンプトが届く前に Windows で死ぬ

Issue #1611 — bug、open

症状

Gemini 3 Flash Preview は、Windows 上の Open Design 内で約 1.5 秒後に stdin: write EOF で失敗します ── プロンプトがモデルに届く前にです。Gemini 3 Pro はまったく同じインストールで問題なく動きます。そして直接の Gemini CLI（gemini --model gemini-3-flash-preview ...）は、GEMINI_CLI_TRUST_WORKSPACE=true が設定されていれば成功します。つまり、キーでもアカウントでも、CLI 単体でもありません。

なぜ起きるのか

診断には 2 段階かかりました。これらがどう解きほぐされるかの良い例なので示す価値があります。報告者のスクリーンショットの最初の読みは、上流の 429 RESOURCE_EXHAUSTED クォータエラーのように見えました。OD_GEMINI_3_FLASH_OK を stdout に書き出すクリーンな PowerShell の再現の後、絵が変わりました：モデルには到達でき、CLI は健全で、失敗はまさに Open Design → Gemini CLI の起動経路にあり、それは Windows 上の Flash バリアントに固有です。Pro は同じ起動経路を通って生き延びますが、Flash は生き延びません。

回避策

モデルピッカーで Gemini 3 Pro Preview を選びます。同じ起動経路を通り、動きます。別件として ── そしてこの部分はバグそのものより時間を食いました ── ~/.gemini/hooks/ を確認してください。遅い gsd-check-update.js フック（Hook execution error: Hook timed out after 60000ms）が、このユーザーのケースでは実行ごとにおよそ 104 秒のオーバーヘッドを加えていました。Flash の失敗とはまったく無関係に、です。いずれにせよ Gemini のフックは掃除してください。止まった更新チェックフックは、どんなエージェントも壊れているように感じさせます。

誰が修正しているか

Flash 固有かつ OD 側としてフラグが立てられています。調査は daemon の stdin 書き込み経路で進行中です ── write EOF は、daemon がプロンプトを書き終える前に子プロセスの stdin が閉じたことを示しているので、修正はその特定のバリアントがどう spawn されるかに宿ります。

DeepSeek TUI は Windows で 30 KB のプロンプト上限を持つ

Issue #1610 — bug、open

症状

Windows のパッケージビルドにおける DeepSeek ラッパー v0.8.33 では、長い合成プロンプトが 81397 > 30000 bytes で私たちの事前チェックガードに失敗します。ユーザーは何も間違っていません ── ただ十分にリッチなプロンプト（システムコンテキスト、デザインシステム、参照）を合成して 30 KB を超えただけです。

なぜ起きるのか

そのガードは意図的なもので、より悪いエラーからあなたを守っています。DeepSeek TUI アダプターは現在、プロンプトを位置引数のコマンドライン引数として送ります ── argv に縛られている ── そして Windows はコマンドライン全体を macOS や Linux よりはるかに低いところで上限を設けます。事前チェックがなければ、同じプロンプトは後でもっと深い spawn の中で、はるかに役に立たない ENAMETOOLONG エラーで失敗し、原因がプロンプトサイズだという手がかりは何も得られません。だから私たちは早めに失敗させ、その数値を名指しします。この issue が露わにした不一致はドキュメントにあります：高レベルのガイダンスは Windows の長プロンプトのフォールバックが広く適用されるかのように示唆していますが、DeepSeek TUI の経路にはまだそれがありません ── その転送はまだ stdin やプロンプトファイルではなく argv なのです。

回避策

Windows で DeepSeek TUI アダプターを使っているなら、合成プロンプトを 30 KB 未満に保つか、stdin ベースのアダプターに切り替えてください ── Claude Code、Codex、OpenCode はどれもプロンプトを stdin 経由で受け取り、同等の上限はありません。macOS と Linux ではこの issue はまったく噛みつきません。そこでの argv の上限は十分に高く、現実世界のプロンプトが到達しないのです。

誰が修正しているか

正しい修正は DeepSeek TUI アダプターのための stdin またはプロンプトファイルの転送で、これは argv の上限を完全に取り除き、stdin アダプターと足並みをそろえます。アダプターチームのキューで追跡されています。

OpenCode のローカル CLI テストがモデルのウォームアップ前にタイムアウトする

Issue #1603 — bug、priority:p0、open

症状

設定 → BYOK → OpenCode で、接続テストは確実に 45 秒でタイムアウトします。奇妙な点：ユーザーがまず OpenCode Desktop のターミナルを開いてそこでローカル LLM をアタッチすると、同じ Open Design のテストが次の試行で成功するのです。

なぜ起きるのか

その「まず Desktop ターミナルを開く」という細部が手がかりのすべてです。Open Design は実行中の OpenCode Desktop セッションにアタッチしません。設定のスモークテストでは、daemon は自前の新しい OpenCode CLI サブプロセスを spawn し、ok の応答を待ちます。コールドなローカルモデル ── まだメモリに読み込まれていないもの ── では、その最初の応答が 45 秒の予算より長くかかることがあります。モデルが何かに答えられるようになる前にディスクから読み出され、ウォームアップされるからです。Desktop ターミナルを開いて 1 つのプロンプトに答えさせると、daemon の新しいサブプロセスがすぐに恩恵を受けられる形で、モデルが OS キャッシュ内でウォームになります。だからこれは本当は OpenCode のバグではなく、ローカルモデルにとって間違っているコールドスタートのタイミングの仮定なのです。

回避策

Open Design で OpenCode をテストする前に、OpenCode Desktop を開き、ローカル LLM をアタッチし、1 つのプロンプトに答えさせてください。それから OD の接続テストを実行します ── モデルがウォームになり、応答が予算内に届きます。v0.7.0 以降、接続テストの予算は設定可能にもなっているので、ローカルモデルの読み込みが本当に遅い場合は、手作業でウォームアップする代わりにウィンドウを広げられます。

誰が修正しているか

daemon 側の修正は、ローカルモデルのアダプター専用の、より長い、あるいは設定可能なウォームアップウィンドウで、コールドなローカルモデルがホスト型 API と同じ時計で判定されないようにするものです。p0 で追跡されています ── 5 つの中で最高の優先度です。なぜなら、ローカルモデルのユーザーこそ BYOK が奉仕すべきまさにそのオーディエンスだからです。

パッケージ化された web アプリがプレーン HTTP 上での読み込みを拒否する

Issue #1620 — bug、open

症状

少し違うバグですが、同じ系統です。報告者はパッケージ化された web アプリを LAN IP 上でプレーン HTTP で実行しており、ページが読み込み時に例外を投げます ── 使える状態に決して到達しません。

なぜ起きるのか

PR #1428 の後、分析プロバイダーと PDF エクスポートの nonce が crypto.randomUUID() を直接呼び始め、安全な crypto API が利用できないときに優雅にフォールバックする PR #900 で導入された段階的なヘルパーをバイパスしました。Chromium は非セキュアコンテキストで crypto.randomUUID を公開しません ── そしてプレーン HTTP 上の素の LAN IP は、Chromium の定義によればセキュアコンテキストではありません。だから直接呼び出しが読み込み時に例外を投げ、ページもろとも落ちます。厳密には BYOK のバグではありませんが、まさに同じオーディエンスに噛みつきます：自前のインフラを動かす人々で、しばしばエアギャップされ、しばしばプレーン HTTP 上で動かしています。内部ツールのために証明書を立てるのは手間に見合わないからです。

回避策

web アプリを HTTPS 上、または localhost 上で提供してください。どちらも Chromium のセキュアコンテキスト要件を満たし ── localhost は証明書なしでもセキュアとして扱われます ── ページは通常どおり読み込まれます。手早い内部セットアップなら localhost がゼロコストの道筋で、LAN アクセスなら HTTPS 上の自己署名証明書が長持ちする道筋です。

誰が修正しているか

PR #1621 は残りの呼び出し箇所を PR #900 の段階的な UUID ヘルパー経由に戻すので、セキュアコンテキストのフォールバックが、すでに配線されていた場所だけでなく、再びどこでも適用されます。open でレビュー中です。

これが Open Design の BYOK について実際に語っていること

このリストを品質の判定ではなく、契約のマップとして読んでください。これら 5 つの issue のうち 4 つはアダプターの境界に座っています ── Gemini の CLI 起動経路、DeepSeek の argv に縛られた CLI 転送、OpenCode のコールドスタートの起動モデル、ホストプラットフォームのセキュアコンテキストのルール。5 つ目、Finish Design のものは、私たち自身の finalize エンドポイントにあり、1 リリース前に Anthropic 形式のレスポンスをハードコードして、まだ一般化していない場所です。それは私たちの責任です。他の 4 つは、自分が作っていないツールを尊重することへの税金です。

そしてそれが構造的な要点です。リバッジされたプロキシでないあらゆる BYOK システムは、結局ここに行き着きます。あなたは推論を所有する ── そして BYOK を失います、なぜなら今やトークンを買って値上げするのはあなただからです ── か、上流のツールを尊重してそのエッジを継承する：彼らの CLI、彼らのパッケージングの癖、それぞれが異なる扱いをするプラットフォームの制限を。私たちは意図的に 2 つ目の姿勢を選びましたし、また選ぶでしょう。その代償が、今週のように見える週です。daemon チームとアダプターチームが 2 日間で 5 つのサーフェスにわたって作業をファイルした週です。

そのトレードは今も正しいのです。macOS での Claude Code、Codex、Cursor、Gemini Pro、そして Linux での DeepSeek の動くセットアップ ── 私たちの実際のユーザーのおよそ 90% をカバーするマトリックス ── は今日きれいに動きます。プロキシ税もなく、あなたのトークンへのマージンもなく。上の 5 つのスレッドは、2026 年 5 月中旬におけるマトリックスの残り 10% がどう見えるかです：名指しされ、ファイルされ、それぞれ修正が進行中です。正直な継ぎ目は、請求がどこへ行くのかを隠す滑らかな表面に勝ります。

今日何を使うか（マトリックス）

これは上のセクションの実践版です ── 同じ 5 つの継ぎ目を、今すぐ手を伸ばして安全なものへとマッピングしたものです。✓ は経路がそのまま動くことを意味します。✗ はそれをブロックしている issue にリンクし、回避策は該当セクションにあります。

プロバイダー	macOS	Linux	Windows	Finish Design の経路
Claude Code（Sonnet / Opus）	✓	✓	✓	ネイティブ
Codex	✓	✓	✓	ネイティブ
Cursor（BYOK）	✓	✓	✓	ネイティブ
Gemini 3 Pro Preview	✓	✓	✓	OpenRouter シム（#1619）
Gemini 3 Flash Preview	✓	✓	✗（#1611）	OpenRouter シム（#1619）
DeepSeek（API）	✓	✓	✓	OpenRouter シム
DeepSeek TUI（長いプロンプト）	✓	✓	✗（#1610）	OpenRouter シム
OpenCode（ローカルモデル）	✓	✓	✓（先にウォーム、#1603）	該当なし

この表の読み方は 2 通り。あなたのスタックがすべて ✓ のブロックにあるなら ── Claude Code、Codex、Cursor、あるいは Gemini Pro ── きれいな経路にいて、上記の何もあなたの 1 日を変えません。✗ の行のどれかにいるなら、対応するセクションに、リンクされた修正が届くまで今日動かすための回避策があります。いずれにせよ、行が ✗ から ✓ に変わったときに通知が欲しければ、トラッカー上の BYOK ラベルを購読してください。

次に何をするか

Open Design のスキルライブラリは、これらすべての下にある動くレイヤーです ── 接続が健全になると BYOK アダプターが供給する、ファイル駆動の契約です。上の継ぎ目は、あなたのキーからモデルへ、そして戻ってくるバイトの受け渡しに関するものです。スキルは、モデルがそれを使って実際に何をするかです。スキルがモデルから何を消費し、何を気にしないのか ── これらのアダプターのエッジが出力を変えず、あなたがそこに到達できるかどうかだけを変える理由でもあります ── を見たければ、そのディレクトリが始めるのに適した場所です。

スキルライブラリを見る。

関連する読み物

• BYOK デザインワークフロー：自分のキーで Claude、Codex、Qwen を動かす — 元の BYOK の解説と、上の 5 つの継ぎ目がそのエッジに座っている動く経路
• なぜ Open Design を製品ではなくスキルレイヤーとして作ったのか — なぜ私たちが上流のツールをプロキシで包む代わりに尊重するのか、それがこれらの境界が存在する理由のすべて
• 31 のスキル、72 のシステム ── ライブラリの仕組み — 接続が健全になったとき、BYOK が実際に何に供給するか