Terminalって何？写真検索まわりでやったことの理解メモ
まず、Terminalって何？
Terminalは、Macに文字で命令するための画面。
普段はFinderでフォルダを開いたり、アプリをクリックしたりするけど、Terminalでは、
「このフォルダを見て」
「このプログラムを動かして」
「このサーバーを起動して」
みたいな命令を文字で直接Macに渡せる。
今日僕がやったのは、Terminalを使ってMacの中で写真検索用のAIプログラムを動かすための準備だった。
ただし、今後僕がTerminalを日常的に操作するのが目的ではない。
むしろ今日やったことのゴールは、
Terminalを裏側に隠して、僕はCodexに話すだけ
にすることだった。
今日なにを作ったのか
大きく言うと、
伊豆の記事に使える写真を、AIが意味で探せる仕組み
を1つ動かした。
今までは写真を探す時、
Finderを開く
フォルダを掘る
候補写真を自分で見る
コピーする
WordPress用に加工する
みたいな作業が必要だった。
今日作った流れでは、
僕「ID315に使える外壁修繕の写真ある？」
↓
Codexが検索
↓
「この3枚です」
↓
僕が選ぶ
までできるようになった。
local-image-searchって何？
今日使ったのが local-image-search。
これは写真の中身をAIで数値化しておいて、
「足場」
「ベランダ」
「家の外壁修繕」
みたいな意味から写真を探せるようにする仕組み。
ファイル名に「足場」と書いてなくても、画像を見た特徴から候補を探せる。
今回はいきなり全写真ではなく、
04_写真素材
にある47枚だけで試した。
この小さく試したのが重要。
embeddingって何をしたの？
今日Terminalで47枚に対してやった「embedding」は、
写真1枚1枚の内容を、AIが比較できる数字の並びに変換する作業
くらいに考えればいい。
写真自体を書き換えたわけではない。
たとえば、
足場が写っている
家が写っている
海が写っている
ベランダっぽい
みたいな画像の特徴を、AI検索できる形に変えた。
その結果、
「house exterior scaffolding renovation」
と検索した時に、実際の足場写真が上位に出た。
MLXとGPUって何だった？
最初Codexからこの処理を動かそうとしたら失敗した。
原因は、Codexの中からMacのGPUをうまく使えなかったこと。
そこで通常のTerminalから確認したら、
MLX OK
Device(gpu, 0)
と出た。
つまり、
Mac自体は正常。Codexの中から直接GPUを触る経路だけが制限されていた
ということ。
MLXはApple SiliconのGPUをAI処理に使うための仕組み。
だから今日途中でTerminalが必要だった。
じゃあ、なんで今はTerminalを開かなくていいの？
ここが今日いちばん大きいところ。
写真検索AIを、
127.0.0.1:8000
というMac内部だけの場所で動く小さなサーバーにした。
この「サーバー」は、インターネットへ公開するサイトではない。
自分のMacの中だけで、Codexから写真検索を頼むための窓口。
Codexはその窓口へ、
「足場の写真を検索して」
と問い合わせられる。
127.0.0.1って何？
これは、
このMac自身
という意味。
外のインターネットからアクセスする住所ではない。
だから今回の写真検索サーバーは、
Macの中だけで使う
構成になっている。
0.0.0.0のように外へ広く公開する設定にはしていない。
ここは安全上けっこう重要。
LaunchAgentって何をしたの？
最初は写真検索サーバーをTerminalから起動していた。
この状態だとTerminalを閉じると写真検索も止まる。
それでは僕は絶対使わなくなる。
だからMacの LaunchAgent という仕組みに、
ログインしたら裏で写真検索サーバーを動かしておいて
と登録した。
今は、
Terminalを開いていなくても
Codexから
写真検索できる
状態になった。
つまりLaunchAgentは、
Terminalで毎回「起動」する作業を僕の代わりにやってくれる係
と考えればいい。
今日、本当に便利になったところ
実際にID315で、
「修繕写真を探して」
とCodexに頼んだら、
意味検索
重複写真の除外
実画像確認
車のナンバーなど危険な写真を除外
候補を2〜3枚まで絞る
本文のどこに合うか判断
までAI側で進んだ。
僕はFinderを開いていない。
これはかなり大きい。
その後、WordPress用の写真も作れた
選んだ元写真から、Codex側で、
向き補正
長辺1600px
JPEG化
約359KBまで軽量化
GPS削除
EXIF削除
alt案作成
までできた。
元写真は変更していない。
公開用の別コピーだけ作った。
だから今後は、
写真を探す → 選ぶ → 公開用に加工する
ところまで、かなりAI側に任せられる可能性がある。
WordPressまわりはどうなる？
今後の理想はこう。
僕「この記事に写真入れたい」
↓
Codexが写真を検索
↓
候補3枚
↓
僕「これ」
↓
Codexが公開用コピー作成
↓
GPS・写り込み確認
↓
alt作成
↓
WordPressへアップロード・配置準備
↓
僕が最終確認
↓
Human Last Click
つまり僕が、
Finderからコピー
プレビューで変換
WordPressメディアライブラリを探す
altを考える
本文の場所を探す
みたいな作業を減らしていく。
僕が今後どう使えばいいの？
一番大事なのは、仕組みを意識しないこと。
今後は普通に、
「このID315に合う写真ある？」
「このトイレの記事に使える写真探して」
「ベランダ修理の写真ある？」
とCodexへ頼めばいい。
僕が、
local-image-search
embedding
LaunchAgent
8000番ポート
MLX
を普段意識する必要はない。
これらは全部裏側。
今は47枚しか検索できないの？
今は47枚。
でもこれは制限ではない。
今回、
04_写真素材
だけを小さく試したから47枚だった。
写真を追加してembeddingを更新すれば増やせる。
将来的には、
47 → 100 → 500 → もっと多く
もできる可能性がある。
ただし、いきなり全部を突っ込む必要はない。
まず実際の記事作業で使いながら、
「この47枚だと足りない」
となった時に広げればいい。
今後気をつけること
1. AI検索結果をそのまま信用しない
トイレ修繕検索では外壁写真が出た。
つまり意味検索は便利だけど完璧ではない。
だから、
AI検索 → Codexが実画像確認 → 本人が最終判断
の順番は残す。
2. 重複写真がある
同じ写真が複数フォルダにコピーされていて、検索結果に何回も出た。
Codexがハッシュで重複をまとめられたので、僕が整理する必要は今のところない。
重複整理を自分の仕事にしない。
3. 写真追加後は検索索引が古くなる
今は47枚分だけembedding済み。
新しい写真を追加しても、自動ではすぐ検索対象にならない。
今後本当に困ったら、
差分embedding自動化
を追加できる。
でもまだやらない。
必要になるまで増やさない。
4. LaunchAgentをむやみに触らない
現在、
com.masa.local-image-search-poc
というLaunchAgentが写真検索サーバーを動かしている。
普通に使えているなら触らなくていい。
もし写真検索が突然使えなくなったら、
「local-image-searchのhealth確認して」
とCodexに言えばいい。
僕がTerminalを開いて修理し始めない。
5. 写真公開判断は人間に残す
AIが、
GPSなし
ナンバーなし
人物なし
と言っても、
家の外観そのものを公開していいか
みたいな判断は僕がする。
AIは安全確認を補助。
最終公開判断は自分。
今日の設計で一番大事だったこと
今日やったのは、
写真をきれいに整理する仕組みを作った
ではない。
むしろ逆。
僕が写真整理をしなくても、AIが裏で探せるようにした
ということ。
昔作った写真索引は精密だったけど、僕自身が索引を開く必要があったから使わなくなった。
今回は、
僕が見るのは候補だけ。仕組みは裏側。
に変えた。
ここが一番大きい。
今の暫定運用
当面はこれでいい。
僕：普通にCodexへ写真を頼む
↓
Codex：local-image-searchで探す
↓
ダメなら04_写真素材を直接見る
↓
さらに足りなければ古い6月索引を見る
↓
候補最大3枚
↓
僕：選ぶ
↓
Codex：公開用コピー・安全確認・WordPress準備
↓
僕：Human Last Click
つまり僕の仕事は、
探すことではなく、最後に見ること。
これで使っていけばいい。
