【ITニュース解説】Course Thumbnail Pipelines — 3 Moderation Gates Before Content-Aware Crop

ニュース記事は、eラーニングのプラットフォームで使われるコースのサムネイル画像を、どのように安全かつ効果的に生成・管理するかというテーマを扱っている。特に重要なのは、画像が公開される前に適切な審査（モデレーション）を通過していることを、確実に保証するシステムの構築方法である。

まず、サムネイル画像の生成において、最も重視すべき制約は「モデレーションを通過していない画像は、絶対に一般に公開されるサムネイルとして表示してはならない」という点だ。一般的に、画像のアスペクト比に合わせて切り抜いたり（クロップ）、サイズを変更したりする処理（リサイズ）は、モデレーションが行われた後に行われるべきである。もしモデレーションが後回しになると、未審査の不適切な画像が一時的であっても公開されてしまうリスクが生じる。そのため、リスクの低い安定した画像に対しては「固定リサイズ」をデフォルトの処理とし、画像の内容を考慮して賢く切り抜く「コンテンツアウェアなクロップ」は、モデレーションと画像内に重要な被写体があるかどうかのチェックが完了した後の、限定的なフォールバック（代替）手段として利用すべきだと筆者は主張している。これは、システムの挙動を予測可能にし、意図しない画像が公開される経路をなくすために不可欠な考え方である。具体的には、元画像が安全な余白を持ち、重要な被写体が安定した位置にある場合は固定リサイズを使い、そうでない場合にのみコンテンツアウェアクロップを使うべきだと述べられている。いずれの場合も、元画像をモデレーションにかけてから派生画像を生成し、判断に必要なデータが不足している場合は、公開を停止するというのが基本的な方針だ。

このパイプラインが変更されるきっかけとなった過去の事例が紹介されている。以前のシステムでは、販売者からアップロードされた画像は、すぐにサムネイルにリサイズされ、ウェブサイトに公開可能になっていた。モデレーションは、その画像が公開された後に非同期で行われていたのだ。ある時、画像がアップロードされてからわずか数秒でリサイズされ公開されたものの、モデレーションの判定が下されるまでに9秒かかっていた事例が発覚した。システム自体は正常に動作していたため、アラートは発動しなかったが、この9秒間、未審査の画像が公開されていたことになる。この経験から、「派生画像の生成も一種の公開行為である」という重要な教訓が導き出された。この教訓に基づき、システムは改良された。新しいシステムでは、派生画像の情報は早期に作成されるものの、実際に公開されるURLを受け取るためには、モデレーションの判定結果と元の画像のハッシュ値（内容が改ざんされていないことを確認する値）の両方が揃っていることが必須となった。これにより、モデレーションが完了するまでは、いかなる派生画像も公開されない仕組みが構築された。

このような厳格な管理は、一見するとシステムの処理能力を低下させるように思えるかもしれないが、計画的に設計すれば問題はない。例えば、ピーク時に毎秒40枚の画像がアップロードされ、それぞれ3種類のサイズに変換される場合、単純計算で毎秒120件の処理が必要になる。しかし、モデレーションの再試行や元の画像の差し替え、キャッシュミスなども考慮に入れると、処理要求はさらに増加する可能性がある。そのため、筆者は処理キューに対して4倍のバースト（一時的な急増）容量を予算化している。そして、承認された派生画像については、99.9%が60秒以内に利用可能になるというSLO（サービスレベル目標）を設定している。一方、拒否された画像や判断できない画像については、公開ゼロというさらに厳格なSLOが課せられている。これは、「モデレーションの状態は画像生成の入力であり、結果として生まれるものではない」というシンプルな不変の原則に基づいている。つまり、モデレーションが完了しない限り、画像生成の次のステップには進まないという順序が極めて重要なのである。

では、コースのサムネイルパイプラインは、クロップ方法を選ぶ前に何を測定すべきだろうか。重要なのは、どのような画像処理ライブラリを使うかではなく、どのような状況で失敗する可能性があるかを最初に考えることだ。例えば、画像を元の形を保ったまま特定の比率に収める「固定リサイズ」は、余白（レターボックス）ができてしまう可能性がある。縦長の講師の画像では左右に黒帯ができたり、ホワイトボードの文字が小さすぎて読めなくなったりするかもしれない。「中央クロップ」はアスペクト比に合わせて中央を切り抜くが、肝心の講師の顔が切れてしまう可能性もある。「セーリエンシー（視認性の高さ）モデル」という技術を使って画像内で目立つ部分を特定し、その部分を残すように切り抜く方法もあるが、顔は残ってもレッスンのタイトルが消えてしまうなど、検出器が成功と判断しても視覚的には失敗となるケースがある。

これらの失敗を防ぐために、元の画像ごとに、その寸法、向き、アルファチャネル（透明度）の有無、検出された顔やテキスト領域、そしてモデレーションの判定結果といった情報を記録しておくことが重要だ。元の画像は決して変更せず、派生画像にはどのような変換が適用されたか、目標とするアスペクト比、そして実際に切り抜かれて残った領域の情報を記録しておく。これにより、将来的にモデルやポリシーが更新されても、過去の不適切なサムネイルを再現して原因を調査できるようになる。

このような意思決定には、複雑な「賢い」メディア処理の説明よりも、小さく明確な決定表を用いるのが有効である。例えば、以下のような条件に基づいて変換方法を決定する。

• 安全な余白があり、目標のアスペクト比との差が10%以内であれば、「固定リサイズ（レターボックス付き）」を選択する。これは、元のコンテンツが失われないためだ。運用面では、エンコードされた寸法や向きを検証する。
• 顔やテキスト領域が切り抜かれてしまう場合は、「コンテンツアウェアクロップ」を選択し、保護すべき領域を中心に切り抜く。これにより、教育的な内容が保持される。この際、検出の信頼性を示すしきい値を設定し、監査記録を残すことが求められる。
• モデレーションが保留中、不足、または判断できない場合は、いかなる派生画像も生成しない。これは、不適切な画像の公開を未然に防ぐためであり、公開可能なURLではなく、未処理であることを示す状態を返す。
• アニメーションや未サポートの形式の場合は、隔離された（安全な）デコーダーを通して正規化し、解析処理やCPUへの負荷リスクを制限する。バイト数、フレーム数、ピクセル数に上限を設けることで、システム全体の安定性を保つ。

ここで述べられている「10%」という値は、あくまでポリシーの一例であり、万能の真実ではない。言語学習アプリのように縦長の講師の画像が多い場合は、異なる許容値を設定するだろう。重要なのは、このようなしきい値が明確にバージョン管理され、実際のコース画像のサンプルを使って評価されていることだ。

このような予防的な処理パスをGo言語で実装する場合のスケッチが示されている。このコードでは、ポリシーの決定部分（ChooseTransform関数）と、実際に公開を行う部分（Publish関数）が、画像エンコードなどの具体的な処理から分離されている。これにより、モデレーションサービスやクロップの実装が独立して変更されても、公開を制御するゲートの部分はシンプルでテスト可能な状態を保つことができる。ChooseTransform関数は、画像の状態（モデレーション結果、幅、高さ、顔やテキストの有無など）と目標のアスペクト比に基づいて、最適な変換モード（固定リサイズまたはコンテンツアウェアクロップ）を決定する。Publish関数は、モデレーション結果が「承認済み」である場合にのみ、画像を公開する処理を呼び出す。それ以外の「保留中」や「拒否済み」の画像は公開されない。

本番環境では、この公開ワーカーは、署名されたモデレーション記録をロードし、その記録のソースハッシュが対象の画像と一致することを確認した上で、画像エンコーダーを呼び出す。テストでは、古いハッシュ値、保留中のモデレーション結果、画像の向きを示すEXIF情報の回転、保護領域を切り取ってしまう目標アスペクト比など、さまざまなケースをカバーする必要がある。これらは特定のベンダーに依存しないポリシーに関するテストなので、将来的にシステムが移行しても再利用可能である。また、「コンテンツアウェア」なクロップ処理は、無限にリソースを消費しないよう、最大入力ピクセル数、デコーダーのタイムアウト、複数の候補がある場合の決定ルールなど、明確な境界と制限を設ける必要がある。これらの制限がないと、非常に大きな単一の画像アップロードが、通常の固定リサイズ処理を行うワーカープールを占有してしまい、サムネイルの可用性に関するSLOを破綻させるインシデントにつながる可能性がある。

次に、画像処理やモデレーションの機能を自社で「構築」するか、外部サービスを「購入」するかの判断基準について説明されている。外部のマネージドメディアAPI、ホスト型モデレーション分類器、自社ホスティングの画像処理スタックなど、選択肢はいくつかあるが、それぞれ異なるリスクとメリットがある。

• ホスト型画像変換サービスは、幅広いフォーマットやリサイズに対応していることが多いが、クロップの細かい挙動はサービスによって異なる。運用面での負荷は低いが、ポリシーの統合には手間がかかることがある。APIやレンディションのメタデータに依存するため、サービスへのロックインリスクがある。標準的なアスペクト比で十分な小規模なチームに適している。
• ホスト型モデレーションと自社内変換の組み合わせは、モデレーションポリシーの更新は迅速に行われ、クロップの制御は自社で保持できる。運用負荷は中程度で、二つの契約と一つのキューを管理する必要がある。モデレーションのスキーマやクォータに関するロックインリスクがあるが、モデレーションの品質やカバレッジを優先するチームに適している。
• 自社ホスティングのデコーダー、検出器、クロッパーは、しきい値の微調整や証拠の保持に関して最高の能力を持つ。しかし、パッチ適用、容量管理、モデルのドリフト（性能低下）など、運用負荷は非常に高い。プロバイダーへのロックインリスクは低いが、運用上の負担が大きい。規制対象の業界や大量の画像を扱うカタログに適している。

これらの選択肢を比較する際には、単に単価だけで判断すべきではない。関連する予算には、審査担当者の時間、再処理にかかる帯域幅、そして不適切なサムネイルが表示されてしまった場合のコストも含まれる。例えば、証拠が厳格に管理されたネットワーク内に保持される必要がある場合、ホスト型サービスは不適切な選択となる可能性があり、一方で、画像デコーダーのセキュリティ更新に対応できる人員がいない場合は、自社ホスティングは適していない。また、固定リサイズでも十分なクリック率や可読性が得られると、実際のデータサンプルが示している場合は、「スマート」なクロップによる新たな失敗モードを正当化する理由はないため、よりシンプルなパスに留まるべきである。サービス境界に関しても、自社の記録にソースハッシュ、ポリシーバージョン、クロップボックスを保持することで、将来的なサービス移行時のポータビリティが確保できる。APIの形だけで将来の移行コストを予測することは難しく、四半期ごとにデータをエクスポートして再実行するテストを行う方が、より確実な証拠となるだろう。

最後に、新機能のロールアウト（導入）、オブザーバビリティ（監視可能性）、そして終了基準について説明されている。まず、新しいサムネイル生成パイプラインを導入する際には、最初に「固定リサイズ」の機能を、機能フラグ（新機能を段階的に導入・切り替えできる仕組み）の背後でリリースする。その後、承認済みのコース画像から代表的なセットを選び、コンテンツアウェアクロップのブランチを通して再処理する。そして、保護領域の保持状況、モデレーションのカバレッジ、処理時間の95パーセンタイル（p95）、派生画像の可用性などを比較評価する。この際、単一の集計スコアだけで判断するのではなく、平均的なフレームが改善されても、特定の言語のキャプションが切り取られてしまうようなケースは、本番環境での機能低下と見なすべきである。

監視システムは、承認済み、拒否済み、保留中の画像数をそれぞれ分離して表示し、デコーダーの失敗とポリシーによる拒否を区別し、処理キューの経過時間とエンコーダーの処理遅延を監視する必要がある。そして、「承認されたモデレーション結果のない派生画像は公開しない」という、最も重要な公開に関する不変条件に対しては、直接アラートを出すべきだ。これは警告ではなく、即座に対応が必要なインシデントとして扱うべきである。また、インシデントレビューのために、学習者のデータが公開されないようアクセス制御を施した上で、切り抜き前後の画像ペアのサンプルを保存しておくことで、正確な切り抜きがどのように行われたかを詳細に調査できるようにする。

最終的な判断として、固定リサイズで画像の可読性やカバレッジの目標が達成できるのであれば、そこで満足すべきだ。もしそれができない場合に限り、コンテンツアウェアクロップは制限された例外として導入する価値がある。その際、モデレーションを再実行することなく、レターボックス出力に戻せるロールバックスイッチを用意しておくことが重要だ。これこそが、次にオンコール（緊急対応）を担当するエンジニアのために、運用手順書に記載すべき決定ルールとなる。