AIとファイル整理を考えたら、「保存先」の設計が変わった

ファイルを自動で整理する仕組みを、ChatGPTと相談した。途中で私が伝えたのは、なるべくシステム化して、何でもかんでもLLMに任せる流れにはしたくないということだった。

高性能なAPIは使いたい。でも、同じ判断を毎回AIに尋ねる仕組みにはしたくない。そこから、Paperless-ngxとルールを中心に、必要なときだけAIへ相談する案ができた。

私はその方向に納得した。ただ、使う場面を考えると、まだ二つの前提が引っかかった。操作する入口と、ファイルの保存先だ。

これは完成したアプリの紹介ではない。何を作りたいかが、提案への違和感からはっきりした設計の記録だ。

1. まず、AIへ頼まなくてよい処理を決める

例えば、PDFに正しいタイトル情報が入っていれば、まず取り出す。定型的な書類なら、発行元・日付・種類から規則で名前を作る。分類が繰り返し出てくるなら、確認済みのルールを使う。

Paperlessには、キーワードや正規表現などの照合と、既存の分類から学ぶ仕組みがある。生成LLMを使う機能とは別なので、できるところから活用したい。Paperless公式の分類説明

タイトルが分からない資料や、候補が競合する文書だけ、LLM APIに判断を頼む。「APIを使いたい」と「全部APIへ送りたい」は別の希望だった。

この振り分けも、AI自身が言う「自信があります」だけで決めない。必要な情報が取れたか、候補が競合していないか、処理側で確かめる。どのくらい呼び出しを減らせるかは、これから実際の文書で検証する。

2. AIツールを開かなくても使いたい

最初の案では、AGI Cockpitが全体を統括する前提になっていた。私はそこに違和感があった。

AGI Cockpitから使えてほしい。Codexから自然言語でも頼みたい。ただ、普通のアプリを開き、フォルダを選んで実行する使い方もできてよいと思った。

そこで、整理エンジンを独立させ、専用UI・Codex・AGI Cockpitを対等な入口にすることにした。入口が違っても、対象範囲、整理案、実行、停止、履歴の扱いは共通にする。

自然言語で依頼する場合も、その場でAIが好きにファイルを動かすのではなく、同じエンジンに依頼する。MCPなどによる接続は、今後の実装候補だ。

普段の画面は簡単でいい。整理するフォルダ、探索する場所、整理案を作るボタン、停止、履歴。細かな命名規則やモデルの設定は、必要なときに開ければいい。

3. 「保存先は一つ」という前提がおかしかった

そのUI案に、「保存先フォルダ」という欄があった。

私は「保存先が指定されているのが違和感があった」と伝えた。ダウンロードフォルダには、いろいろな種類のファイルが入る。それらが一つの保存先にまとまるとは思わない。ファイルごとに、いろいろなフォルダへ振り分けたい。

例えば、研究用の論文、領収書、旅行の写真。入口が同じでも、次に使う場所は違う。

修正後は、整理対象とは別に、「振り分け先の探索範囲」を複数登録する設計になった。PCのドキュメント、写真のフォルダ、NASの整理済みフォルダ。その範囲から、各ファイルに合う場所を探す。

これは私の実ファイル一覧ではなく、設計例だ。フォルダ名だけで決めず、中にある文書の特徴や過去の整理履歴も手がかりにする。

登録範囲の外へ勝手に動かさない。合う場所がなければ新規フォルダを提案し、分からなければ「要確認」に残す。

ここで欲しいものがはっきりした。名前が整うだけでは足りない。自分の整理体系を生かして、次に使いやすい場所へ置く仕組みが欲しかった。

4. Paperlessに任せる範囲も分ける

Paperlessを使う方針は維持した。OCRや文書管理を、初めから自作しなくて済むのは魅力だ。APIもあるので、独立アプリから連携を考えられる。Paperless公式API

ただし、Paperlessが取り込んで管理する文書と、PC・NASの一般フォルダを同じ扱いにはしない。管理領域を外から直接改名・移動すると、Paperlessがファイルを見失う。そこは正式な機能やAPIを通して扱う。公式の保存パス説明

一般フォルダの整理は、独立したエンジンが担当する。文字抽出も対象形式に合わせて別途用意する。PaperlessにAI提案を適用するワークフローがあることと、任意のフォルダをその場所で整理できることは分けて考える。AI提案ワークフローの公式リリース

実行前には、変更前後の名前と場所を見て確認する。同名ファイルを勝手に上書きせず、重複らしさだけで削除しない。停止後にどこまで終わったか分かり、戻す操作もできるようにしたい。

この流れはまだ構想だ。停止ボタンや履歴を置くだけで、安全な実行と復元が完成するわけではない。

5. EmbeddingGemma 2とJevは、必要になった場所へ

私は、EmbeddingGemma 2とJevも、後から組み込める前提にしてほしいと頼んだ。標準では無効でいい。役割と交換口を先に考えておきたい。

EmbeddingGemma 2は、意味の近い配置候補を探す場所へ。 文書やフォルダの特徴を数値で表し、似た候補を探すために使う。候補が近いことと、配置先が正しいことは別だ。Google公式のモデル説明

Jevは、絞った候補を比較・評価する場所へ。 TypeSafe AIは、文章生成とは異なる、限定された判断を返すモデルとして説明している。ファイルを動かす部分まで任せるわけではない。Jev公式の説明

どちらも、この構想での精度は未検証だ。Jevは英語を主に学習しており、日本語を含む他言語でも同じ品質とはされていない。自分の文書で試してから使う。言語とモデル更新の公式説明

更新時は、同じ代表文書で旧版と新版を比べる。モデルの版を履歴に残し、埋め込みを替えたら索引の互換性を確認する。新しいモデルが出るたびに、アプリ全体を作り替える負担を減らしたい。

6. 使う場面を考えると、設計の問いが変わる

最後の修正を見て、私は「今後もはじめからそれくらい考えたもので提案してほしい」と伝えた。

簡単な画面にすることと、目的を狭めることは違う。「保存先」という欄一つに、ファイルを一つの場所へ集める前提が入っていた。実際の使い方を考えたことで、その前提を直せた。

これから作るなら、まず対象と探索範囲、整理案、実行・停止・復元を固めたい。ルールで処理できない場面が見えてから、必要なAIを加える。APIへ送る文書の範囲と、提供者の保存条件も確認する。

今回できたのは、動くアプリや精度の実績ではない。何を自動化し、どこで判断し、どこに置くのか。その設計を、自分が使う場面から考え直せたことだ。