画面分割の修正はすべてのテストに通った。直ったのはバグの半分だけだった。

作成：2026年10月12日 · 更新：2026年10月12日

Katto は長尺動画を縦型クリップに変換するサービスで、私がひとりで、開発の過程を公開しながら作っています。10月10日、画面分割の配置まわりのバグを直し、テストを通し、本番に出して、変更履歴に「修正済み」と書きました。ところがその日の夜、同じバグがまだ起きているのを見つけました。しかも、二度直したところで、画面分割そのものが良くなったわけではありませんでした。

画面分割は何のためにあるのか

ポッドキャストやインタビューは、たいてい引きの画で撮られています。テーブルを挟んで2人が座り、16:9 の画面の左右に1人ずつ。一方、縦型ショートは 9:16 です。中央を切り抜けば、映るのはテーブルだけで顔はどこにもありません。話している人を追いかければ、もう1人は返事をするたびに画面から消えてしまいます。

2人がある程度離れて座っている場合、Katto は別の方法をとります。1人ずつを囲む枠を切り出し、上下に重ねるのです。高さ半分のパネルが2枚で、2人の顔がずっと見えている。2人が話すショットに対する定番の解決策で、リフレームのページで説明しているのもこの仕組みです。

何がおかしかったのか

パネルにはそれぞれ幅があり、コードでは2つの枠が重ならないよう、その幅に上限を設けていました。この上限は2人のあいだの距離から計算していました。一見もっともらしいのですが、測っているものが間違っていました。

実際の例を挙げます。元動画の幅は 1920 ピクセル、2人の間隔は 1300 ピクセル。上限は 1235、パネル幅は 1214 だったので、上限は効きませんでした。そのあと各枠をそれぞれの人物の中心に合わせ、画面からはみ出した分を内側へ押し戻します。左の枠は右へ 358 ピクセル、右の枠は左へ 236 ピクセル動きました。つまり、お互いに近づく方向です。

1214 ピクセルの枠を2つ横に並べるには 2428 ピクセル必要です。画面の幅は 1920 しかありません。どう配置しようと、少なくとも 508 ピクセルは両方のパネルに同時に映ってしまいます。

画面上では、上のパネルの下端と下のパネルの上端に、同じ映像の帯が現れます。肩が2回、顔の半分が2回、ときには人物まるごとが2回映ります。

最初から出発点にすべきだったルールは1行で書けます。幅 W の枠2つが横に並ぶのは、2W が画面の幅以下のときだけ。2人のあいだの距離は関係ありません。

どのくらいの頻度で起きていたか

Katto がすでに納品した画面分割クリップを振り返り、保存されている配置情報から重なりを直接読み取りました。1つ目の枠の右端から2つ目の枠の左端を引いた値です。

そのうち 31% で重なりが出ていました。その内訳は次のとおりです。

重なり	割合	見え方
300 px 以上	18%	人物や上半身が二重に映る
150〜299 px	15%	内側の端に体の一部が映る
60〜149 px	36%	背景の帯が映る
60 px 未満	30%	まず気づかない

割合は四捨五入しているので、合計は 99 になります。ざっくり言うと、3分の1は目に見えず、3分の1はかすかに分かり、3分の1は明らかに壊れていました。最悪のケースが、先ほどの 508 ピクセルです。

実は最初に数えたときは 31% ではなく 23% でした。古いクリップの一部には存在しないフィールドを使って重なりを計算していたため、その行が何の警告もなく飛ばされていたのです。数字がそれらしく見えたので、危うくそのまま使うところでした。

修正と、それが通ったテスト

新しい上限は、あの1行のルールそのものです。各パネルは最大でも画面の半分、そして2つの枠は交差しようがない位置に置く。この上限が効くのは、元の配置が実際に重なっている場合だけです。初期のバージョンではすべてのケースで配置を計算し直しており、問題のなかったクリップのいくつかを1〜2ピクセルずらしていました。正常だったクリップに手を出す修正は、それ自体が2つ目のバグです。

次に検証です。保存済みのクリップをまとめて、修正なしと修正ありで再生成しました。重なっていなかったものはすべて完全に同一で、変わったのは重なっていたクリップだけでした。続いて実際の動画で新しくジョブを走らせたところ、画面分割クリップ 12 本のうち上限が効いたのが 3 本、重なりはゼロでした。

そこで本番に出し、変更履歴にも修正済みと書きました。

その日の夜

テスト用の動画をもう1本流しました。修正を有効にしたまま、1本のクリップに 44 ピクセルの重なりが出ました。

関数は2つあったのです。1つは典型的なケース、つまりテーブルで向かい合う2人を扱い、それぞれにアップの枠を割り当てます。もう1つは汎用の予備処理で、1つ目が引き受けなかったときに使われます。各フレームでいちばん左といちばん右の顔を取り、それを基準に分割します。どちらも画面分割クリップを生成し、それぞれ独自に枠の位置のペアを出します。そして両方に、ほぼ一字一句同じ欠陥がありました。私は1つ目を直して、2つ目は開いてすらいませんでした。

厄介なのは、証拠が十分に説得力があるように見えたことです。私の計測もテスト用のクリップ群も、2つのコード経路が混ざっていたのに、まったく気づいていませんでした。1つ目の修正だけでサンプルの大部分がきれいになったので、結果は完全に直ったように読めてしまった。保存済みの結果から取った計測で数えられるのは症状です。それを生み出している箇所がいくつあるかまでは教えてくれません。

2つ目の修正は、同じルールを2つ目の関数に入れることです。同じクリップ群で再生成すると、さらに 4 本が直りました。56、124、230、340 ピクセルあった重なりがすべてゼロになり、それ以外は何も動きませんでした。56 ピクセルのものは、朝の修正を素通りしていたクリップです。まさに漏れている現場を押さえた形です。

3つ目がないか確かめる

2回目の「修正済み」を書く前に、枠の位置を決めている箇所をコード全体から探しました。1か所ではなく4か所ありました。2つは先ほどの関数で、どちらも修正済みです。3つ目は、すでに見つけてある分割線をもとにパネルを作り、各パネルをその線の自分の側の幅に収めるので、構造上2つの枠が交差することはありません。4つ目は、3つ目が出した数値を受け渡しているだけです。

そのため今回の主張は、前より範囲を絞っています。10月10日以降にレンダリングされた画面分割は、画面の同じ部分を両方のパネルに映すことはありません。それより前にレンダリングされたクリップは、作られた時点の配置のままです。

まだ良くないところ

映像が二重に映らないのは最低ラインであって、良い画面分割ではありません。実際の動画で、いまも3つの問題が見えています。

パネルが中の人物に対して広すぎる。各パネルの大きさは、人物ではなく画面を基準に決めています。引きのスタジオ映像だと、人物がパネルの3分の1しか占めず、残りは背景のセットということがあります。半分空いたパネルが2枚あるより、きちんと構図の決まった1枚のほうが見栄えがいいこともある。画面分割をまだ他の種類のショットに広げていないのはこのためです。各パネルを人物に合わせて詰めるのが、次の作業です。

長めのクリップの中の短いやり取りは分割されない。判定はクリップ全体に対して行われます。1人が40秒話し、もう1人が5秒だけ割り込んだ場合、クリップは1つの構図のままで、返事は画面の外で起きることになります。

2人のショットなのに、そう認識されないことがある。判定のきっかけは顔の数です。横顔や遠くにいる人、暗い場所では、体の検出器は毎フレーム捉えている人物を顔の検出器が見落とすことがあり、そうなるとクリップは1つの構図に戻ってしまいます。

どれも映像を二重にするものではありません。ただ、これは「壊れていない画面分割」と「本当に良い画面分割」の差です。「修正済み」という言葉に両方を背負わせるより、正直にそう書いておきたいと思います。

今回の教訓

修正がうまくいったら、同じ出力を生む他の箇所を探す。バグを見つけた場所だけでなく、同じ種類の結果を出しうるすべての場所です。今回はフィールド名1つを検索するだけで済んだのに、私はそれを本番に出す前ではなく、出したあとに実行しました。

集計した数値では、修正が完全かどうかは分からない。数値は大きく下がりました。そして大きく下がったことこそが、探すのをやめさせてしまうのです。

黙って行を飛ばす指標は、エラーで止まる指標より悪い。フィールドが1つ欠けていただけで、警告ひとつなく 31% が 23% になりました。

代わりの指標ではなく、制約そのものから出発する。上限を2人の距離から作ったのは、その数値が手元にあったからです。本当の制約は画面の幅で、それも同じように手元にありました。

10月10日の変更履歴の記載（英語）は「修正済み」と書いていましたが、数時間早すぎました。いまは実際に起きたことをそのまま書いています。