【スキルあり】768枚のイベント写真を、20分で「251枚のセレクト」と「67枚のハイライト」に分けた話
イベント撮影は楽しい。しんどいのは、撮ってる最中じゃない。 僕の場合、地獄はいつも終わったあとに来る。
シャッターを切ってるあいだはいい。 登壇者の表情、会場の空気、質疑応答の一瞬、集合写真、廊下での立ち話。 「ここに熱があった」って、あとで見た人に伝わるように、とにかく撮る。撮る。撮りまくる。
問題はそのあとだ。
フォルダを開くと、似たような写真が何百枚も並んでいる。 半目。 微妙なブレ。 資料しか写ってないカット。 同じ登壇者、同じ構図が延々と続く回。
でもその中に、ちゃんと「これは残すべき」ってカットも埋まっている。
そして主催側は、だいたいこう言ってくる。
「良いやつだけ送ってください」
……いや、その「良いやつ」を選ぶのが一番しんどいんだけど。
今回、その工程をかなり楽にしてくれたのが select-photos-skill という、Codex用の写真選定スキルだった。 実はこれ、自分で作ったやつだったりする。
結果だけ先に言うと、768枚のイベントスナップから、約20分で「アルバム用251枚」「ダイジェスト用67枚」まで整理できた。
正直、マジで楽だった。 自分で作ったものが、自分をちゃんと助けてくれる。これ、地味に嬉しい。
select-photos-skill って何なのか
まず断っておきたいんだけど、これは「写真を全自動で完璧に選んでくれる魔法のAI」として作ったわけじゃない。
そんなものを期待して触ると、たぶんがっかりする。
中身はかなり地味というか、現実的に作ったつもりだ。
写真フォルダを渡すと、Codexが決められた手順を踏んでいく。 作業用のコピーを作る。 コンタクトシートを作る。 明るさ・コントラスト・シャープネスの簡易指標を出す。 目つぶりや低シャープネス候補を確認用にまとめる。 最後に「アルバム用」と「ダイジェスト用」の2種類に分けて、納品フォルダとZIPを作る。
READMEにも、このスキルは写真そのものを加工するものじゃなくて、選定の流れ・確認シート・判断基準・成果物を揃えるためのものだ、と書いている。(GitHub)
つまり、Codexに「いい感じに選んで」って丸投げできるように作ったわけじゃない。 写真選定っていう曖昧な仕事を、Codexが再現できる工程に変換する。そういう設計にした。
ここは自分の中でも、けっこう意識した区別だった。
何を作ってくれるのか
このスキルが作るセレクトは、大きく2種類ある。
ひとつは album_select。 イベント全体の流れを残すための、広めのセレクトだ。 会場の雰囲気、登壇、質疑応答、参加者同士の交流、集合写真。 「その日、そこで何が起きていたか」を後から追えるように、というつもりで作った。
もうひとつは digest_highlights。 こっちはさらに絞った代表カット。 SNS投稿、告知、イベントレポートの冒頭とか、共有用のダイジェストに使いやすい写真を優先するように作った。
この2種類を標準の成果物にする、というのもREADMEに書いた。(GitHub)
今回、768枚のJPGから出た結果はこうだった。
album_select：251枚 digest_highlights：67枚
251枚は、イベント全体をちゃんと見返せる広さのセレクト。 67枚は、SNSやレポートですぐ使える代表カット。
イベントスナップの納品としては、かなり実用的な分け方になったと思う。
実際に何をやったのか
今回の素材は、講演イベントのスナップ写真だった。
フォルダをCodexに渡すと、まず対象フォルダ内の写真数を確認してくれた。 JPGで768枚。
……うん、まあ知ってた。知ってたけど、数字で見るとやっぱりちょっと引く。
そこから先は、元の写真には一切手を触れず、作業用のコピーを作って、撮影順に並んだコンタクトシートを生成してくれる。 コンタクトシートっていうのは、要は複数の写真を一覧で見られる確認用のシートのこと。
これがあると、1枚ずつ開かなくても、イベント全体の流れが見える。
僕が見た限りだと、だいたいこんな感じだった。
序盤:受付、会場装飾、集合、導入、講師登壇、会場を引いたカット、参加者の反応。
中盤:資料画面が強く出るカットと、講師の身振りが大きいカットが混在。
後半:参加者同士の対話や、女性登壇者のパートが入ってきて、会場の温度が上がってくる。
こういう「流れ」を見ながら選んでくれるのは、地味だけどかなり大きい。
シャープな写真を機械的に上から選ぶだけだと、イベント写真としてはむしろ弱くなる。 会場の引き絵、参加者の反応、登壇者とスライドが同時に見える一枚、交流の場面。 このへんは単体で見ると地味なんだけど、レポートには絶対に必要なやつだ。
実際、今回も「資料の文字が読めるかどうか」より、「イベント感があるかどうか」を優先した場面が何度かあった。
選定基準は「画質」だけじゃない
このスキルを作るとき、選ぶ基準をちゃんと固定しておいてよかったと思う。
優先順位は、ざっくりこう。
場面のカバレッジ
表情
構図
技術的な品質
重複排除
つまり、まずイベント全体の流れが残っているかを見る。 次に表情や会話の空気を見る。 そのうえで構図やピント、ブレ、露出、目つぶりをチェックする。 最後に、似た写真を減らす。
この優先順位は、READMEにも同じ順番で書いた。シャープネススコアだけで機械的に落とすのは、意図的にやらないようにしている。(GitHub)
これ、地味だけど設計時にかなり悩んだポイントだった。
写真選定をAIに任せようとすると、つい「シャープネスが高いもの」「顔がはっきり写ってるもの」だけを残したくなる。 気持ちはわかる。わかるんだけど、イベント写真ではそれをやると普通に失敗する。
たとえば会場全体の引き絵は、シャープネス的には弱く出ることがある。 スライド前に立つ登壇者のカットも、背景の白い壁のせいで数値的には弱く見えたりする。 でもそれが、イベントの文脈を説明するのに必要な一枚なら、残す価値はある。
だから、数値で自動選別するツールじゃなくて、数値を補助線として使いながら、最終的には文脈で選ぶための道具にしたかった。
技術的にはどうなってるのか
中身は、大きく4層で作った。
1. ルーティング層
「写真フォルダ」「イベントスナップ」「アルバム選定」「ハイライト選定」みたいな依頼が来たときに、Codexがこのスキルを使うように、SKILL.mdにルーティングの条件を書いた。 静止画の選定なのに、間違って動画分析用のワークフローに流れてしまわないようにも、気をつけて書いたつもりだ。
2. 作業規約層
元の写真には触らない。 編集しない。 色補正しない。 トリミングしない。 納品フォルダには無加工のコピーだけを置く。
このルールは、かなり固く決めた。 SKILL.mdにも、元ファイルを変更しないこと、編集・トリミング・色補正・元ファイル破壊をしないことを、はっきり書いた。
正直に言うと、たぶん技術的には、ここにレタッチや色補正、トリミングまで足すこともできると思う。 露出を整えて、色味を揃えて、構図を切り出して……そこまでやれば、もっと「完成品」に近いものが自動で出てくるはずだ。
でも、そこはあえて作らなかった。
なんというか、自分の手でやった仕事だ、って言いたい気持ちがある。 レタッチって、地味にしんどい作業なんだけど、同時にわりと楽しい作業でもあって。 この一枚をどう見せるか、どこまで持ち上げるか、どこで止めるか。 そこを完全にAIに渡すのは、ちょっと寂しい。
まだちょっとだけ人間の仕事、残しといてくれよ。
……とはいえ、選ぶところまでやってくれるだけで、正直かなり助かってる。 一番しんどかった「見続ける」の部分がなくなっただけで、もう十分ありがたい。
だから、「勝手に元ファイルをいじられたら怖い」というより、そもそも自分でそう作った、という話に近い。 安心して作業を任せられるのは、そのおかげだと思う。
3. 画像解析補助層
ここはPythonとPillowを使って、コンタクトシートや品質指標を作る層。 OpenCVがあれば顔検出に使うし、なければ中央クロップでeye review(目元確認用シート)を作るように設計した。
必須の依存はPythonとPillowだけにして、OpenCVは任意にした。無くてもワークフロー自体は止まらない。
ここで出てくる情報は、たとえばこんな感じ。
明るさ
コントラスト
シャープネスの簡易指標
画像サイズ
ファイルサイズ
低シャープネス候補
顔・目元確認用シート
ただし、これはあくまで最終判断じゃない。 「怪しい写真を拾うための補助線」くらいの立ち位置で設計した。
4. 納品物生成層
最後に photo_selection_manifest.json をもとに、album_select と digest_highlights のフォルダを作って、ZIP化する。
成果物としてコンタクトシート、photo_metrics.json、低シャープネスレビュー、eye review、manifest、レポート、納品フォルダ、ZIPが出るように設計した。
今回も、最終的に無加工コピーの納品フォルダとZIPを作るところまで、ちゃんと動いてくれた。
今回、特に助かったところ
一番助かったのは、迷う作業がちゃんと分解されたことだと思う。
普通に写真を選んでると、頭の中でこういう判断を全部同時にやっている。
「これブレてないか」 「似たような写真、多すぎないか」 「この人の表情、こっちのほうがいいか」 「会場の空気、ちゃんと残ってるか」 「SNSに使える代表カットはどれか」 「レポート用には、どれが説明的か」 「集合写真で目つぶってる人、いないか」
これを全部、フォルダの中で1枚ずつ人間がやるのは、正直かなり重い。
でもこのスキルを使うと、まず全体のコンタクトシートが出てくる。 低シャープネス候補が出てくる。 目元確認用のシートが出てくる。 選定方針が固定される。 album_select と digest_highlights に分かれる。 最後に manifest と納品ZIPが残る。
つまり作業が、「気合で見る」から「工程として進める」に変わる。
これは思っていたよりずっと大きい。
実際のセレクトでは、どう判断したか
今回のイベントは、序盤に同じ講師の話してるカットがかなり連続していた。
全部残すと、見る側が疲れる。 かといって削りすぎると、イベントの流れそのものが消える。
だからCodexは、アルバム用には手の形・視線・画角が違うカットを残して、ダイジェスト用では講師単独と会場の引き絵を少数に絞る、という方針で進めてくれた。
中盤は、資料画面が強く写るカットと、講師の身振りが大きいカットが混在していた。
ここは資料の文字が読めることより、イベント感を優先した。 会場・講師・参加者が同時に見える一枚のほうが、レポートやSNSでは結局使いやすいからだ。
後半は、参加者同士の対話や、女性登壇者のパートに良いカットが多かった。 このあたりは会場の温度がそのまま出ているので、ダイジェスト候補として厚めに残した。
最初のダイジェスト候補は、81枚あった。
……で、これがまた絶妙に多い。 代表カットとしては、ちょっと広すぎる枚数だ。 なので最終的には、67枚まで絞った。
この「一回広く拾って、あとで使える枚数まで絞る」という流れが、思っていたより実務的だった。
人間の仕事、なくなるんじゃないの
このスキルを使ってみて思ったのは、「AIが写真家を置き換える」って話では、たぶんない、ということだ。
むしろ逆だと思う。
──ここでちょっと真顔になるんだけど。
写真家や編集者が普段、頭の中で無意識にやっている判断を、AIが扱える工程として切り出す。 そのうえで、人間はより上位の判断に集中する。
どの場面を残すべきか。 どの表情が、そのイベントらしいか。 どの写真が、主催者の伝えたい空気に合っているか。 どこまで重複を許すか。 どの写真は記録として必要で、どの写真はSNSの1枚目に耐えるか。
ここはまだ、人間の編集判断が要る。というか、要ると思う。
でも、そこに辿り着くまでの「ひたすら似た写真を見続ける時間」は、かなり削れる。
昔、こういう選別を全部Lightroomの星マークだけでやってた時期があって、あれはあれで俺なりのルールを作ってたんだけど、正直しんどかった。夜中に1000枚近い写真をひたすら見て、★をつけて、寝落ちして、朝起きたらどこまでやったか忘れてる。そんなことを真剣にやってた。
話を戻すと、その「ひたすら見る」部分がごっそり減っただけで、精神衛生的にはだいぶ違う。
注意点もある
当然だけど、これで全部終わり、じゃない。
特にイベント写真の場合、公開前のプライバシーレビューは必須だと思っている。
参加者の顔、名札、機密情報が写り込んだスライドやホワイトボード、顔出し許諾が取れているかわからない参加者。 READMEにも、実イベントの写真を公開する前には人間によるプライバシーレビューが必要だと書いている。
AIが選んでくれたからといって、そのまま公開していいわけじゃない。
参加者の顔・名札・スライド内の機密情報だけは、公開前にちゃんとぼかす。 このひと手間を省くと、あとで面倒なことになるのは、だいたい自分だ。
ここは人間が責任を持つべきところだと思う。
まとめ
今回の select-photos-skill は、かなり実用的だった。
768枚のイベントスナップを、20分ほどで、
アルバム用251枚 ダイジェスト用67枚
まで整理できた。
しかも、ただ枚数を減らしただけじゃなくて、
作業コピー
コンタクトシート
品質指標
低シャープネス確認
目元確認
選定manifest
納品フォルダ
ZIP
まで、一連の流れとして残った。
これは単なる「AIで写真を選ぶ」って話じゃなくて、写真選定っていう曖昧で重い作業を、ワークフローとして外に出す、という感覚に近いと思う。
AI時代に大事なのは、たぶん「全部AIにやらせる」ことじゃない。
自分が普段やっている判断を分解して、AIに支えてもらえる形にすること。 そのうえで、人間は最後の編集判断、文脈判断、責任ある公開判断に集中すること。 あとはまあ、単純に楽しい部分は、自分の手元に残しておくこと。
イベント撮影をやってる人なら、この「終わったあとの地獄」は、わりと分かってもらえると思う。
撮影が終わって、フォルダに700枚以上の写真があって、そこから「良いやつだけ」を選ばないといけない。 あの時間が、ほんの少しだけ、未来になった気がする。
select-photos-skill、GitHubで公開してる。 イベント写真の選定とキュレーションのためのCodexスキル。(GitHub)
興味あったら覗いてみて。
次はもっと枚数の多いイベントで試してみるつもりでいる。 レタッチ機能は……まぁあったらいいよね。
