Top　　上へ　　目次



タグ情報



Ver.10で正式な機能に昇格しましたので、こちらのページも参照ください。
タグによるファイル管理



　多分、激しく意見は分かれる内容だと思いますので、気を悪くしないでください。
　特定の考え方を否定しているわけではなく、情報の分類法に関する考察に過ぎません。

　ウチでもチラホラと情報を小出しに漏洩してますけど、ファイルにタグを付けて管理すると言う方法を模索しています。
　X-Finderの作者さんも最近実装されたようですし、ちょっと思考をまとめるのにツラツラと綴ってみようと思います。



●タグをつける意味

　ファイルとフォルダの単位を利用して情報を取り扱うのが難しくなってきたと言われています。
　これはファイル名の付け方、フォルダ名の付け方、階層管理の方法を知らない、素人が増えたという側面もありますが、ファイル名という比較的短いセンテンスで名が体を表す限界を超える場合があるのは事実でもあります。
　MP3や、静止画のファイルでは現在も広く使われていますが、アーティスト名、発売日などでソートをかけたりというのは、わりと身近な例でしょう。
　分類と言う観点で言えば、この例のようなポップスやロックの両方を守備範囲にしているようなアーティストだと、扱いが複雑になってしまいます。

　例えば、ディレクトリ階層を使うなら、
音楽
┣ポップス
┃┗アーティスト名(A)
┃　┗発売日(1)
┗ロック
　┗アーティスト名(A)のシンボリックリンク
　　┗発売日(1と同じものです)

　こんな感じですかね。
　おそらく、ほとんどの人が、シンボリックリンクって何？となっちゃいますし、どうやって説明しても一般的とは言えません。
　むしろどっちが実体？というあたりで迷うことでしょう。

　まぁ、ディレクトリ管理は「運用段階に入ると構造を後から変更しにくい」「冗長性を持ちにくい」「存在の有無は探索してみないと分からない」「内容が似ているものを探す方法がない」と言ったキーワードもあるので、時間がある人は考えてみてください。
　タグでの管理方法は、これらの問題解決のアンチテーゼでもあり、また一つの方法論に過ぎないので、どちらが優れていると言った話ではありません。
　併用できれば、TPOで切り替えられるんじゃね？という安易な発想です。哲学的な単語使うと「ジンテーゼ」ですかね。
　ほら、キーボード＋マウス併用とか、MDI＋タブ制御併用とか、並べる系＋2画面分割とか、その辺の発想の延長です。

　もちろん、デメリットは「よりいっそう敷居の高いソフトになる」って事ですね。（苦笑）



●既存のタグによるファイル管理の弱点

・タグを付けたことを忘れる
　ファイル個別の属性を付与しているので、大量に付与しても一覧で見ることができません。
　タグの種類を増やしすぎて、どんなタグを付けていたか分からなくなりがちです。

・タグを付けるのが面倒くさい
　カメラなどが勝手に付与してくれるEXIF情報などなら手間がかかりませんが、「何を写したのか」といったコメントタグを片っ端から入力していくとか苦痛以外の何者でもありません。
　タグを付ける作業に疲れてしまい、つい画像鑑賞しちゃっていつの間にやらこんな時間に！・・・と現実逃避したくなるでしょう。

・適切なタグ付けのルールが確立されてない
　後から検索しやすいタグの付け方など解説してる記事も多々ありますが、ノウハウ的なものがあまり無く、俺様ルール的な紹介ばかりなんですよね。
　また、一度つけたタグは、後から変えにくいと言う弱点もあります。
　つまり現時点で、属人的であり、汎用性を持たせるのが難しいとものであると言えるでしょう。
　ルールを忘れちゃうと、タグの絞り込み検索が出来なくて、いっぱいタグ付けた意味ないじゃん！となるわけです。




●実際のタグ付けの利用方法

1.検索・分類のキーとして使用する
　pixivなどの画像サービスなどでの検索キーで使われてます。
　ファイルをアップロードする人が、どういうジャンルの画像なのかをあらかじめ登録してアップロードしているから実現できていると言えるでしょう。
　つまり、ユーザーさん側からしてみると「すでに勝手にタグが付けられてる状態」から作業を開始できるわけです。
　豊富なタグ情報が存在するという前提で、類似性の抽出や情報の取出し方法の多様性が確保できるわけです。

2.備忘録的にメモを付与する
　ファイルに対して、付箋紙を貼るような感覚でしょうか。
　編集中のファイル等に対して加工者などの情報を記すとか、一時的なメモ書きとしての使い方になります。
　また、この備忘録が共有できれば、ファイルに対しての説明などの用途にも使えます。

　最後まで読むと分かりますが、残念ながら二つの課題を満足させられる回答は用意できていません。



●タグの実現方法

　オリジナルファイルそのものにタグ情報を書き込む、オリジナルファイルの隠しエリアに情報を書き込む、完全に自前でタグ情報を管理するの3択になると思われます。

1.シェル情報の更新
　ファイルのプロパティの詳細や、詳細ウィンドウで編集可能なものです。
　実際のファイルのヘッダを、そのファイルのフォーマットのルールに従って書き込むので、オリジナルファイルとは別の加工されたファイルになります。
　ファイルそのものを編集するので、タグ付けできる上限数もないですし、持ち運んだ先での情報の保持は完璧です。
　しかしタグそのものの一覧性が皆無であるためタグの自身のメンテナンスが事実上不可能です、タグ情報を収集してデータベース化する、専用のソフトの出番になるでしょう。
　どんなタグ付けたっけ？て忘れちゃうって事ですね。
　またファイルの種類に可否が限定されるため利用方法に制限があり、ファイルフォーマットに縛られるため項目内容の自由度もありません。
　具体的には、JPEGにはタグを付与できますが、PNG,GIF,BMPには付与できないみたいな感じです。

2.副ストリーム
　「c:\test\hoge.txt:stream:$DATA」このようなファイル名の形式でファイルの読み書きができるモノでして、エクスプローラーなどから参照は一切できません。
　またいくらでもストリーム名を付けられるので、通常のファイルの裏にいくらでも情報が書き込めます。
　（実際にディスク容量を消費しますが、サイズ表示には現れません）
　そのため、悪用されることが多いですし、ディスクアクセスが多く速度面で不利な方式です。
　タグ付けできる上限数はなく、ファイルシステムがNTFSであれば、コピーや移動で失われることはありませんが、ファイルサーバーやNASでよく使用されるSAMBAや、多くの圧縮形式でサポートされていないので、いつの間にか情報が失われているという事故が頻繁に起こりえます。
　あと次世代フォーマットのReFSでサポート対象外なので、将来性も不安要因です。

3.独自タグ情報の保持
　完全にオリジナルのタグシステムを実装します。
　他のPCや、ファイルの受け渡しによるタグ情報の保持能力が皆無であるのが最大の弱点です。
　メンテナンス性や使い勝手などは理屈の上では実現可能だが、これは作り手しだいとなります。
　ただ、タグによるファイルの管理という手法自体がエクスプローラーに実装されていないため必要性が理解されることもないでしょうし、実装に手間がかかるだけに、そこまで要るか？という自問自答のジレンマがあって作り手を悩ませるでしょう。
　さらに、お手本となるべき「標準的な実装」と呼べるものが存在しないため、有効な利用方法まで考える必要があるのも高いハードルです。
　2番目に大きな弱点は、無制限にタグの数を設けるには相当な工夫が必要です。
　旧作の時点ですが、SQL Server（データベース）エンジンが無償配布されたときに、これ使ってタグ情報の管理をテスト実装しました。
　そういった大げさなものではなく、オンメモリ＋テキストベースなら数百件程度が使用メモリ的や速度的に上限になるでしょう。
　管理上限の上を望めばきりが無いですし、そのシステムを構築する匙加減の指標すらないわけで、実装自体がギャンブル行為なんです。


利用シーンシェル情報の更新副ストリーム独自タグ情報備考
一覧の可否××○ 付与したタグを一覧でまとめる
付与したタグの把握しやすさやメンテナンス性に影響する
検索の可否△(※1)
専用ソフトも別途ある		×
方法なし
実装するにしても遅い		△
作成の余地あり
作り手次第		 タグ付けの主目的の一つ
移動時のタグ保持○△(NTFSに限る、圧縮で失う)×(※2) ファイルを移動した時にタグ情報を保持できるか
情報共有しやすさ○
常に共有		△(NTFSに限る、圧縮で失う)×
共有不可		 情報共有というメリットに着目すれば、ファイル自体に情報が記載される方式が有利だが
「情報漏洩しやすさ」という情報共有のデメリットに着目すれば、優位性は逆転する
OS依存×
強く依存する(※3)
仕様の保証も無し		△
NTFS依存
ReFSで未対応で将来性の不安		○
依存しない		 OSに対する依存度が低い方が将来性への保証となる
ファイルの同一性の保証×
ファイルヘッダ書き換え
同一性が完全に失われる		△
使用するストリームの内容を更新
タイムスタンプ失う		○
破損無し		 タグを付ける前後で同じファイルであるか否か
対応可能拡張子×
情報ヘッダのあるファイル限定		○
制限無し		○
制限無し		 特定の拡張子を持つファイルのみの対応か
実装のしやすさ△
実装規模は最小(※4)		△
ちょっと大変		×
スゲェ面倒		 シェル方式の場合はMP3などのようにタグ情報にバージョン番号があるような物への正確な対処は無理だし破損の可能性すらある
副ストリームの場合は、影響を与えないストリーム名の調査が必要。
独自方式は調査不要だがフルスクラッチ
同一フォルダでの一覧性○
詳細のカラムに追加可		△
ツールチップのみ
速度犠牲		○
ツールチップ
アイコンオーバーレイ		 他の機能の速度に影響を与えないことが前提
複数の情報格納×
ファイルフォーマット依存		○
際限なしに増加可能		○
設計次第		 色分けタグを付けるとか、任意の表現手法が取れるか否か
※1
　ただし事前にインデックスサービスでインデックスの作成対象に含めておく必要がある。
※2
　CRC/MD5/SHA1などの一般的なハッシュ値を使って同一性を保持する方法もあるが、計算量が多すぎて速度的な制限で非現実的。
※3
　「タイトル」や「コメント」などは定義が公開されているが、肝心の「タグ」はインデックス番号がOSごとに異なるのでAs/RでもOSごとにテーブルを持っている。
　「タグ」は若いインデックス番号を持つが、少なくともXPでは分岐が必要となるし、将来も保証されない。
　（私が知らないだけだったらゴメンナサイ）



●で、おめーのタグの実現方法は結局どれよ？

　うん、まぁ、その、ぶっちゃけ、コア機能は3種類ともテスト実装してたりします。
　その結果、副ストリームを使った方式は、速度的な優位点を消してお釣りが出るくらいなので、実運用は厳しい感があります。
　いつの間にか属性情報が消えてるじゃん・・・みたいなトラブルも多くなりそうですしね。
　また、元ファイルを壊しちゃう上に、Office文書や標準化されたメディアファイルのみしか対応できない、シェル情報の更新というのも否定的な感触を抱いています。
　そのため、独自実装の方向を向いています。
　こちらはVer.5.7.0から使えるスクリプトですが興味のある方は、お試しください。
　動作確認用のサンプルスクリプト

　そうそう、せっかくなので副ストリームが勝手に使われる例を示しましょうか。
　上のダウンロードをIEとかFireFoxとか使ってダウンロードしたとします。
　ダウンロードしたフォルダからコマンドラインを開いて
　ダウンロードパス>notepad.exe tag_script.7z:Zone.Identifier
　と実行すると、こんな内容が開かれると思います。
----------------------
[ZoneTransfer]
ZoneId=3
----------------------
　3はネットワーク経由でファイルをローカルにコピーしてきたという識別番号です。


　一応、世のファイラー界でぐぐってみると、タグ付け可能なファイラーというのはFenrirFS、Mebiusboxさんが有名どころなのかな。
　スクリーンショットを見る限り、FenrirFSはタグに特化で系統が違うっぽいですが、Mebiusboxはウチと同じようなアプローチっぽく見えます。
　まぁ参考にする気は全くないんですが、先達としてライバル認定しておきますね。