AI File Sorter レビュー: ローカル視覚LLMでファイル名を書き換えるC++デスクトップアプリの実力と境界
Cross-platform desktop application for content-aware file organization and renaming. Supports local and remote LLMs, preview-based workflows, and fully user-controlled changes.
ひと目でわかる
- これは何？
- 画像・文書・メディアの内容を読み取り、カテゴリ分類とリネーム案を提示するクロスプラットフォームアプリ。承認前に一切変更しない設計と、AGPL-3.0 の帰結を整理する。
- 誰に向いている？
- 大量の写真やスキャン文書が NAS や外付けドライブに溜まり、ファイル名が IMG_xxxx のままで検索できない人には向く。ローカルモデルで完結させたい用途ほど設計意図に合う。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に C++ です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AI File Sorter が埋めるのは「ファイル名が内容を語らない」という穴
デジカメやスマートフォンが付ける IMG_2048.jpg という名前は、撮影順序しか伝えない。README は、これを clouds_over_lake.jpg のような説明的な名前へ変える例を挙げている。対象は画像だけでなく、対応文書ファイルのテキスト内容、そして音声・動画ファイルに埋め込まれたメタデータ（年、アーティスト、アルバム、タイトル）である。メタデータが揃っていれば 2024_artist_album_title.mp3 のような案が出る。想定ユーザーは、Downloads、外付けドライブ、NAS といった場所が散らかった個人や小規模チームで、レビュー、アーカイブ、長期保管のために後から探しやすくしたい人だ。ルールベースの一括リネームツールとの違いは、ファイル名、ファイル種別、フォルダ文脈、過去の分類結果を組み合わせてカテゴリを提案する点にある。固定ルールだけに頼らず、任意の whitelist、直近の類似結果、ユーザーが承認したレビュー判断を混ぜることで、時間が経っても分類の一貫性を保とうとする。
処理の流れ: 解析、提案、レビュー、適用の4段階
README の How It Works は4段階で説明されている。フォルダまたはドライブを指定し、選択したローカルまたはリモートのモデルでファイル（該当する場合は画像内容も）を解析し、カテゴリとリネーム案を生成し、変更前にユーザーがレビューして調整する。重要なのは、この順序が UI の構造そのものだという点だ。解析中は進捗ダイアログが出て、完了後に review table が表示され、確定して初めてフォルダ作成とファイル移動が走る。カテゴリには任意でサブカテゴリも付く。画像解析は組み込みの視覚 LLM バックエンドでローカルに実行でき、プラットフォームロゴとして Vulkan、CUDA、Apple Metal が README に並んでいる。つまり推論の実行経路は GPU バックエンドに依存する。文書はテキスト LLM、音声・動画はメタデータ抽出という別の経路を通る。同じ「整理」という結果に対して、入力の種類ごとに手段が分かれている設計だ。
分類モードと whitelist、キャッシュが効く仕組み
README には categorization modes、category language selection、category whitelists という節がある。分類モードが複数用意されていること、カテゴリ名の言語を選べること、whitelist で許可するカテゴリを絞れることが読み取れる。whitelist は、AI が毎回違う語をひねり出すのを防ぐための装置だと解釈できる。たとえば写真フォルダで「Travel」「Vacation」「Trip」が混在すると検索時に困るが、許可語を先に決めておけば揺れを抑えられる。さらに categorization cache and learned behavior という節があり、過去の結果と承認済みの判断が次回以降の提案に影響する。ここは README の記述が薄く、キャッシュがどの単位で無効化されるのか、モデルを切り替えたときに再利用されるのかは読み取れない。運用で効かせたいなら、実際に同じフォルダを2回解析して提案が安定するかを自分で確かめる必要がある。ドキュメントだけでは判断できない領域だ。
導入: 配布チャネルと最初にやるべき小さな検証
入手経路は README に複数ある。SourceForge のダウンロードボタン、Microsoft Store のリンク、そして filesorter.app のダウンロード統計バッジ。Linux、macOS、Windows それぞれのインストール節が用意されている。初回はフルアーカイブやドライブ全体ではなく、小さなテストフォルダから始めるよう README 自身が Safe First Run の節で勧めている。具体的には Downloads、スクリーンショット、写真、文書から 20〜50 件を一時フォルダにコピーし、解析を走らせ、何も適用する前に review table を点検する。取り消したい場合は Edit -> Undo last run で直前の実行を戻せる。リモートモデルを使う場合は OpenAI API キー、Gemini API キー、またはカスタムの OpenAI 互換 API を設定する節がある。ローカルモデルならファイル、ファイル名、画像、メタデータは端末内に留まり、テレメトリは送信されないと README は述べている。ネット接続が要るのはリモートモデルを選んだときだけだ。
System compatibility check という前提条件の壁
このアプリは GPU バックエンドに依存するため、README に System compatibility check と Requirements の節が置かれている。スクリーンショットにも macOS 上の compatibility benchmark ダイアログが含まれている。つまり、インストールしただけで動く保証はなく、まず自分の環境で視覚 LLM が動くかを判定する手順が挟まる。ここは見落としやすい。CPU だけで完結する軽量なリネームツールを期待していると、Vulkan、CUDA、Metal のいずれかが要求される時点で前提が崩れる。また、視覚 LLM には required visual LLM files という節があり、モデル本体のファイルを別途用意する必要があると読める。モデルの入手と配置はユーザーの作業だ。対応形式も無制限ではなく、supported document formats と supported audio/video formats という節で明示的に列挙されている。対象外の形式は解析されない。導入判断の前に、自分のファイル群がこの一覧に入っているかを確認すべきだ。
向かない場面: 無人バッチと、AGPL-3.0 を避けたい組み込み
このアプリの中心はレビュー表による人間の承認だ。README は「no move or rename happens until you approve it」と明言している。裏を返せば、承認を挟まず大量ファイルを一気に処理する用途には向かない。サーバー上で夜間に何万件も捌くようなワークフローを求めているなら、CLI で完結する別のツールのほうが素直だ。ライセンスも制約になる。AGPL-3.0 はネットワーク越しに利用させる改変版にもソース公開を求める条項を含む。自社サービスに組み込んで配布する、あるいはホスト型で提供する場合、この条件が製品設計に影響する。ここでは法的助言はできないので、実際の組み込みを検討するなら法務確認が要る。もう一点、README の記述からは複数ユーザーでの同時利用やサーバー運用の想定は読み取れない。あくまでデスクトップアプリとして設計されている。
代替手段との違い: ルールベースのリネーマーと何が変わるか
比較対象として分かりやすいのは、正規表現や EXIF 日時で機械的にリネームするツール、たとえば ExifTool のようなメタデータ操作系だ。ExifTool は撮影日時や GPS、カメラ機種といった構造化メタデータを確実に取り出し、テンプレートに流し込む。速く、決定的で、内容を解釈しない。AI File Sorter は逆で、画像の中身や文書のテキストをモデルに読ませて意味のある名前を生成する。決定的ではない代わりに、メタデータを持たないスクリーンショットやスキャン PDF にも名前を付けられる。この差は大きい。撮影日時ベースの整理で足りるなら ExifTool のほうが速く、検証も容易だ。内容に基づく命名が要るなら AI File Sorter の出番になる。両者は排他ではなく、メタデータがある写真は ExifTool、ない画像は AI File Sorter、という分担も成立する。どちらを選ぶかは、ファイル名に何を残したいかで決まる。
メンテナンス費用とライセンスの帰結
リポジトリは C++ で書かれ、デフォルトブランチは main、最終 push は 2026-09-09。直近では v1.9.0 が 2026-08-05、v1.9.1 が 2026-08-06、v1.9.2 が 2026-08-14 と、短期間に続けてリリースされている。この間隔は活発な修正を示す一方、1.9.x 系で細かな変更が続いていることも意味する。追従コストを見積もるなら、リリースノートを追って自分のワークフローに影響する変更を拾う作業が要る。ライセンスは AGPL-3.0。個人が自分の端末で使う分には通常のソフトウェア利用と変わらないが、改変して配布する、あるいはネットワークサービスとして提供する場合はソース公開の義務が生じうる。社内利用でも、他システムへ組み込む形にするなら条件を確認したい。ソースからビルドする場合、C++ と GPU バックエンドのビルド環境、そして視覚 LLM 用のモデルファイルの入手が別途必要になる。バイナリ配布を使うほうが導入の手数は少ない。
編集部の結論
大量の写真やスキャン文書が NAS や外付けドライブに溜まり、ファイル名が IMG_xxxx のままで検索できない人には向く。ローカルモデルで完結させたい用途ほど設計意図に合う。逆に、サーバー上の数百万ファイルを無人でバッチ処理したい場合や、AGPL-3.0 の伝播を避けたいクローズド製品への組み込みは避けるべきだ。導入前に確認すべきは、自分の GPU が Vulkan、CUDA、Metal のどれで動くか、対象ファイル形式が README の対応表に入っているか、そして Edit -> Undo last run が自分の運用でどこまで戻せるかである。まず 20〜50 件のテストフォルダで review table を確認し、カテゴリ名が自分の分類語彙と一致するかを見る。一致しなければ、後述のカテゴリ whitelist を先に整える。
コミュニティノート