ローカルPCに溜まったPDFや請求書、履歴書、作業ファイルを手作業で仕分けするのに疲れているエンジニアに向けた記事です。クラウドAPIに頼らず、ローカルで動くAIモデルでファイル分類を自動化する仕組みを整理します。
題材にするのは「SlothSort AI」という個人開発のファイル整理ツールです。PDF・DOCX・TXT・CSV・XLSXといった形式のファイルを読み込み、内容をAIに解析させて分類まで行うという、Streamlit（Pythonで手早くWebアプリの画面を作れるフレームワーク）製のローカルアプリです。クラウドAIのAPI課金やデータ送信を気にせず動かせる設計が特徴で、個人の開発ワークフロー自動化のヒントになる構成です。
何が注目に値するか
この仕組みの肝は「ファイルの中身をローカルAIに読ませて分類する」という一点に尽きます。
一般的なファイル整理ツールは、ファイル名や更新日時、拡張子といったメタデータだけで振り分けます。たとえば「請求書_2024.pdf」のようにファイル名が整っていれば機能しますが、「IMG_0231.pdf」のような名前だと手も足も出ません。
SlothSort AIはここでファイルの中身そのものを読み取り、文書の意味を理解したうえで分類先を提案します。内容ベースの分類は、ファイル名の命名規則に依存しないという点で実務的な価値があります。
もう一つの注目点は、AI処理をすべてローカル環境で完結させていることです。クラウドAPIを使う分類器であれば、ファイルを外部サーバーに送信する前提になりますが、このツールはOllama（ローカルPC上でLLMを動かすためのランタイム）経由でモデルを動かすため、ファイルの中身が外に出ません。
履歴書や財務記録、教育関連の書類など、機微な情報を含むファイルを扱う場面では、この「外に出さない」という設計判断がそのまま採用理由になり得ます。
技術的な仕組みを段階的に見る
処理の流れは次の7ステップで構成されています。
- フォルダ選択: ユーザーが整理対象のフォルダを指定する
- ファイルスキャン: 対応形式（PDF/DOCX/TXT/CSV/XLSX）のファイルを列挙する
- コンテンツ読み取り: 各形式に対応したライブラリでテキストを抽出する
- AI分類: 抽出したテキストをローカルLLMに渡し、カテゴリを推定させる
- 整理案の提示: 分類結果をユーザーに提案する
- ユーザーレビュー: 提案内容を確認・修正する
- ファイル移動: 承認された内容に沿ってファイルを整理する
ここで重要なのは、AIに「丸投げ」していない点です。AI分類のあとに必ずユーザーレビューのステップを挟んでいます。
AIコーディングツールのエージェント機能でよく語られる「人間の承認を挟むループ（human-in-the-loop）」と同じ考え方が、ファイル整理という地味なタスクにも応用されている形です。自動化と誤分類リスクのバランスを取る設計として参考になります。
ファイル形式ごとの読み取りには、それぞれ専用のPythonライブラリが使われています。PDFはPyPDF、DOCXはpython-docx、CSVは標準のCSVモジュール、XLSXはopenpyxlという組み合わせです。
この構成自体は目新しいものではなく、Python製のドキュメント処理ツールで広く使われている定番の組み合わせです。新しいのは、抽出したテキストを渡す先がクラウドAPIではなくローカルLLMである点です。
AIモデルには、Meta社が公開しているLlama 3.2の3Bパラメータ版（オープンウェイトモデル、モデルの重みが公開されており誰でもダウンロードして動かせるモデル）が使われています。3Bという数字はパラメータ数が約30億であることを示し、GPT-4クラスの大規模モデルに比べるとかなり軽量です。
軽量モデルを選ぶ理由は明快で、ローカルPC、特にGPUを積んでいない環境でも現実的な速度で推論できるようにするためです。Ollamaはこうした軽量モデルをコマンド一つで取得・起動できるツールとして、ローカルLLM活用の入り口になっています。
関連技術との比較で見えてくる位置づけ
クラウドAPI型のファイル分類（たとえばOpenAIのAPIやAnthropicのClaude APIを都度呼び出す方式）と比較すると、ローカルLLM方式には明確なトレードオフがあります。
精度や文脈理解の面では、クラウドの大規模モデルに軍配が上がる場面が多いはずです。3Bクラスのモデルは、複雑な文書の微妙なニュアンスまで捉えるのは得意分野ではありません。
一方で、API呼び出しのたびに発生する課金がなく、ネットワーク越しにファイル内容を送信しないという利点は小さくありません。社内のドキュメント管理ツールや、個人開発でのプロトタイピングでは、この割り切りが現実的な選択になる場面があります。
MCP（Model Context Protocol、AIモデルと外部ツール・データソースをつなぐための標準プロトコル）を使ったファイル連携と比べると、SlothSort AIの構成はもっと素朴です。MCPはAIアシスタント側からファイルシステムやAPIを動的に呼び出す仕組みですが、このツールはStreamlitアプリとOllamaが直接連携するシンプルな構成にとどまっています。
大規模なワークフロー自動化基盤を作るというより、「ローカルで完結する小さな自動化」を素早く組む題材として捉えるのが実情に近い見方です。
今日確認できること
自分の開発環境でも同種の仕組みを試せるか、以下の観点で確認してみてください。
- Ollamaのインストール状況:
ollama --versionでバージョンを確認し、未導入なら公式サイトからセットアップする - 動かせるモデルのサイズ: 手元のマシンのメモリ・GPU有無に応じて、3B前後の軽量モデル（Llama 3.2 3Bなど）から試す
- 対応ファイル形式の棚卸し: 自分が整理したいファイルがPDF/DOCX/TXT/CSV/XLSXでカバーされるか確認する
- 機微情報の有無: 履歴書や財務データなど、クラウドに送りたくないファイルがどれだけあるか整理する
Ollamaが手元にあれば、次のコマンドでモデルを取得し、ローカルで応答させるところまではすぐに確認できます。
ollama pull llama3.2:3b
ollama run llama3.2:3b "この文書は請求書・契約書・レポートのどれに近いですか: (ここにテキストを貼る)"この一行だけでも、ファイル分類の核となる「テキストを渡して分類ラベルを返す」という処理の感触がつかめます。ここに前述のPDF/DOCX読み取りライブラリを組み合わせれば、小規模な自動分類スクリプトの骨格ができあがります。
まとめ
ローカルAIによるファイル整理は、精度よりも「データを外に出さない」「API課金が発生しない」という制約条件から選ばれる構成です。
技術的には目新しい要素の組み合わせではなく、定番のPythonライブラリとOllama、軽量なオープンウェイトモデルを素直に繋いだ構成である点が、逆に再現しやすさにつながっています。
まずは手元で ollama pull と ollama run を試し、手持ちの文書を要約・分類させてみるところから始めるのが現実的な一歩です。
AI分類のあとに必ず人間のレビューを挟む設計も、業務でこの手の自動化を組み込む際の判断基準として覚えておく価値があります。