deckedit.com の OCR を約 24 時間壊してしまいました。申し訳ありません。
2026 年 4 月 19 日または 20 日にデッキを変換しようとして失敗または停止したように見えた方へ — 何が起きたか、なぜもっと早く気づけなかったか、そして同じ形で再発しないよう何を変えたかをお伝えします。
何が起きたか
2026 年 4 月 19–20 日の約 24 時間、deckedit.com のスライド認識ステップが大半のユーザーで失敗しました。アップロードはエラーになるか、止まったように見える状態でした。サイト自体は正常に読み込まれていましたが、スライドからテキストを読み取る部分が壊れていました。
私のデータは危険にさらされましたか？
いいえ。DeckEdit は完全にブラウザ内で動作し、あなたのファイルがどこかへアップロードされることはありません。今回の障害はブラウザ内エンジンの起動エラーで、データがサーバーに届いたことは一度もありません — そもそも届かない設計だからです。
原因
GPU で動く OCR は 2026 年 1 月から本番サイトで稼働しており、何か月も問題なく動いてきました。昨日、私は約十一時間かけて、エンジンのエラー報告をもっと正直にする作業に取り組んでいました — 問題が起きたときにより分かりやすいメッセージを出すこと、ワンクリックで CPU モードに切り替えられるボタンを追加すること、そして本当の失敗を覆い隠してしまう可能性のあるリトライ処理を取り除くことです。これらの変更は意図したとおりに機能しました。しかし同時に、私が予想していなかったことも起きてしまいました。「覆い隠し」を取り払ったことで、エンジンの「バックグラウンドのヘルパー内で起動するモード」と、本番サイトが 1 月からずっと頼ってきた小さな補助コードとの間にあった潜在的な矛盾が、表に出てきてしまったのです。この矛盾は三ヶ月のあいだ静かに存在し続けていて、ユーザーから見える形で表面化したことは一度もありませんでした。私が「正直さ」のために加えた変更が、その隠れ場所を取り払ってしまいました。サイト自体は普通に読み込まれていたものの、エンジンが起動を完了できず、認識も失敗してしまったのです。
なぜ 24 時間気づかなかったか
開発プレビューでは変更をテストして、動作していました。問題は、今回の矛盾に関わっている小さな補助コードが、プレビュー環境では意図的にスキップされている、という点です — 開発を速く保つため、1 月からずっとそうしてあります。つまり私のプレビューは、本番サイトより構造的にシンプルな起動経路を走っており、失敗する経路には初めから近づかない仕組みになっていたのです。「プレビューで動く」ことは事実でしたが、この種類の変更については何の根拠にもなっていませんでした。これは私の落ち度です。
修正された内容
ブラウザ内エンジンに対して、本番サイトでも、よりシンプルなメインスレッド起動を使うように指示しました — プレビューでずっと問題なく動いていたのと同じ起動経路です。GPU OCR は復旧しました:GPU をサポートする端末ではスライド 1 枚あたり数秒です。ページを読み込んだ直後の最初の 1 枚だけは、GPU がシェーダーをコンパイルするために 1〜3 秒ほどカクつくことがあります。それ以降のスライドはすべて全速で動きます。GPU をサポートしない端末では OCR は CPU にフォールバックして遅くなります — これはハードウェア側の制約で、ソフトウェアでは解決できない部分です。
同じ形で再発しないために変えたこと
今後、ブラウザ内エンジンの起動の仕方に触れる変更 — 起動モード、GPU の初期化、そしてプレビューで意図的にスキップされている補助コードまわりの変更を含みます — は、プレビューだけでなく本番サイト(deckedit.com)で実際に確認できて初めて「完了」とみなします。この種類の変更について「プレビューで動く」はもう根拠として扱いません。このルールを自分の作業ノートに書き込み、忘れないようにしました。
ありがとうございます
今日再び試してくださり、うまくいったなら、もう一度のチャンスをくださってありがとうございます。4 月 19 日または 20 日に諦めた方 — お気持ちは理解できます。本当に申し訳ありません。このツールは無料ですが、あなたの時間はそうではありません。その時間の一部を私が無駄にしてしまいました。
— Keith Li、DeckEdit を作っている人