2026.09.23 DX

文書管理の分類方法｜分類軸の選び方とフォルダ階層・命名規則の設計手順

共有フォルダを開くと「2024年度」「新規フォルダ」「〇〇さん依頼分」が同じ階層に並んでいる。これは現場の怠慢ではなく、分類軸を決めないまま運用を始めた結果です。この記事では、ワリツケ式とツミアゲ式のどちらから着手するか、組織・業務プロセス・文書種別・年度のどれを第1階層に置くか、階層を何層で止めるか、名称と番号にどこまで意味を持たせるかを、Windowsのパス長制限や行政文書の標準例といった実測できる根拠から決めていきます。既存フォルダを移行するときの順序と凍結日の決め方も扱います。

まとめ：業務プロセス基準の分類軸と、3層で止めるフォルダ設計

分類軸に迷ったら業務プロセス別を第1階層に置いてください。組織別は改編のたびにパスが変わり、年度別は年度をまたぐ案件で文書が分断されます。業務の流れは組織図より寿命が長く、5年単位で見ても第1階層の作り直しが起きにくい構造です。推奨する並びは、業務プロセス、文書種別、年度の順になります。

階層の深さは3層で止めます。根拠は好みではなく上限値です。Windows APIのパス最大長はMAX_PATHとして260文字に定義されており、クラウドへ移行するとテナント名とライブラリ名が先頭に70文字前後加わります。日本語のフォルダ名を3層重ねてファイル名を付けると、その時点で230文字前後に達する計算になります。4層目を足す余地はほとんど残りません。

深さで足りない分は、階層ではなくメタデータで補います。判断の分かれ目は検索条件の軸数です。「取引先×契約種別×締結年」のように常時2軸以上で探す文書群はメタデータへ寄せ、1軸で足りる文書群はフォルダのまま置く。ただしメタデータの入力を必須化できない運用では未入力が積み上がるため、その場合は階層で押し切るほうが実務に耐えます。

文書管理の分類方法の全体像｜ワリツケ式とツミアゲ式の使い分け

実務で使われる分類の型は三つです。全社統一の分類表を先に作るワリツケ式、現物を見てグループ分けするツミアゲ式、階層ごとに両者を使い分けるハイブリッド式。どれが正しいかではなく、自社の文書量と主管部門の権限の強さで決まります。

ワリツケ式が機能する条件｜文書主管部門が全社分類を先に定義できる規模

総務や品質保証といった文書主管部門が全社共通の分類表を作り、各部門はその枠へ文書を流し込みます。決定は速く、数百人規模の企業でも1〜2か月で全社展開できます。

ただし機能する条件が三つあります。保存年限の決定権が主管部門にあること、部門固有の文書が全体の2割以下に収まること、分類表の改訂手続きが文書として定められていること。三つ目を欠いたまま始めると、枠に入らない文書が「その他」へ流れ込みます。文書管理規程で改訂手続きと承認者を先に定めておくと、この流入を止められます。失敗の兆候を把握する手がかりは数字です。「その他」配下のファイル比率が1割を超えたら、分類表の粒度が粗すぎるサインです。

ツミアゲ式で現物から積む手順｜棚卸し件数が数千件を超える場合の限界

現物を内容や形式でグループ分けし、下から分類を組み立てる方式です。現場の実態には合いますが、合議に時間がかかります。対象が数千件を超えると、分類の議論そのものが収束しなくなります。

打ち切り方を先に決めておいてください。1部門あたり更新頻度の上位100件だけをツミアゲの対象にし、残りはアーカイブ領域へ退避させる。この線引きをせずに全件を対象にした企業では、分類決定だけで半年以上かかり、その間に新規文書が旧フォルダへ積み上がる二重管理が発生します。全件を平等に扱わないことが、この方式を完走させる条件になります。

ハイブリッド式の分担｜上位2階層は全社統一・第3階層以下は部門裁量

上位の第1〜2階層を主管部門が固定し、第3階層以下を各部門の裁量に開く形です。全社横断の検索性と現場の適合性が両立し、実務では最も採用されています。

この境界線には副次的な効果があります。全社統一の範囲がそのままアクセス権の設計単位になるため、権限設計を分類設計と同時に終えられます。第2階層までを共通のグループ権限、第3階層以下を部門グループに割り当てる構成です。文書管理システムの機能とファイルサーバーとの違いを検討する段階でも、この境界がそのまま製品側のフォルダ権限へ移せるかが選定の判断材料になります。

分類軸の選定基準｜組織別・業務プロセス別・文書種別・年度別の適性

第1階層に何を置くかで、その後10年の運用コストが決まります。四つの軸を、第1階層としての適性と崩れる条件で並べます。

分類軸	第1階層への適性	崩れる条件
組織別	低い	組織改編・部署の統廃合
業務プロセス別	高い	業務プロセス自体の再設計
文書種別	中程度	種別をまたぐ案件単位の参照
年度別	低い	年度をまたぐ長期案件

適性が低い軸を使ってはいけないという話ではありません。第1階層に置くと崩れやすい、という意味です。組織別も年度別も、下位の階層なら無理なく機能します。

組織別分類が抱える組織改編リスク｜部署名をフォルダ名に入れない理由

部署名は改編で変わります。変わるとパスが変わり、デスクトップのショートカット、表計算の外部参照、手順書に貼られたリンクが一斉に切れます。3年に一度の改編でも、そのたびに全社のリンク切れを回収する作業が発生する計算です。

行政文書の標準例も同じ設計思想を取っています。内閣府がまとめた文書ファイル等の名称付与の標準化では、共有フォルダの階層構造と名称を保存期間表の大分類・中分類・小分類と一致させるとしており、組織名を階層の軸には置いていません。例外は人事・経理のように部門単位でアクセス権を厳格に切る文書群です。この場合だけは、権限境界と一致させる意味で組織別を上位に置く判断が成り立ちます。

業務プロセス別分類の設計手順｜受注から検収までの流れを軸にする方法

受注、設計、製造、検収、請求といった業務の流れを第1階層に置きます。プロセスは組織図より変化が遅く、部署が統合されても工程自体は残ります。

主要業務を5〜9個の工程に分ける
各工程で発生する文書を洗い出す
工程をまたいで参照される文書を特定する
それぞれの置き場所を1か所に確定する

三つ目で必ず迷います。見積書は営業が作り、製造も経理も見ます。判断基準を一つ決めてください。置き場所は「作成した工程」ではなく「保存年限を管理する工程」です。見積書の保存年限を経理が管理しているなら、置き場所は経理側の工程配下になります。作成者基準で置くと、年限が来ても誰も廃棄判断をしません。

文書種別・年度別を第何階層に置くか｜保存年限の単位から決める順序

年度を第1階層に置く設計は避けてください。年度をまたぐ長期案件で、同じ案件の文書が別々のフォルダへ分断されます。年度は最下層に置くのが扱いやすい配置です。

文書種別は年度の直上に置きます。保存年限が文書の種別に紐づくためです。会社法は会計帳簿を帳簿閉鎖の時から10年、法人税法は申告期限の翌日から7年と定めており、年限の単位は種別ごとに異なります。種別フォルダの下に年度フォルダを置けば、年限が来た年度フォルダを丸ごと廃棄対象として抽出することが可能です。逆順にすると、廃棄のたびに全年度を横断して種別を拾う作業が発生します。保存年限の決め方と規程への落とし込みを先に固めておくと、この並び順は自動的に決まります。

フォルダ階層の深さの上限｜パス長260文字から逆算する3層設計

階層の深さを「3〜4階層まで」と感覚で語る解説は多くありますが、根拠は実測できます。文字数の上限とアイテム数の上限、二つの壁から逆算します。

MAX_PATH 260文字が生む実害｜移行時に開けなくなるファイルの条件

Windows APIのパス最大長はMAX_PATHとして260文字に定義されています。ディレクトリを作る場合はさらに厳しく、8.3形式のファイル名を後から追加できる長さを残す必要があるため、ディレクトリ名はMAX_PATHから12を引いた248文字を超えられません。

Windows 10 バージョン1607以降はこの制限を外せますが、条件は二つあります。レジストリ値 LongPathsEnabled を1に設定すること、そしてアプリケーション側のマニフェストに longPathAware 要素が含まれていること。片方だけでは効きません。社内の業務アプリがマニフェストを更新していなければ、レジストリを変えても従来どおり260文字で頭打ちになります。実害が出るのは移行のときです。ファイルサーバーからクラウドへ移すと、先頭にテナント名とドキュメントライブラリ名が加わり、それまで開けていたファイルが閾値を超えて開けなくなります。

階層を3層で止める根拠｜パス長の配分と1フォルダ5万件の上限

配分を計算します。サーバー名と共有名で20文字前後、階層1つあたり日本語のフォルダ名で15〜20文字、ファイル名は日付と内容と版数を入れると40〜60文字。3層構成なら合計140文字前後に収まります。ここへクラウド移行時のプレフィックスが70〜90文字加わると、230文字台。4層目を足した時点で上限に触れます。

もう一つの壁がアイテム数です。MicrosoftはOneDriveとSharePointの制限事項で、共有するフォルダー内のアイテムをサブフォルダー込みで5万個まで、同期対象は合計30万個までを推奨上限としています。階層を浅くした反動で最下層に数万件を置く設計は、この上限に当たります。3層で止め、足りない分をメタデータで補う。この組み合わせが、両方の上限を同時に回避できる構成です。

命名規則と文書番号の付け方｜行政文書の標準例から移植できる要素

階層を浅くすると、ファイル名が担う情報量が増えます。命名規則は分類設計の一部として同時に決めてください。

名称に入れる要素と順序｜日付・内容・版数の並びと区切り文字の選択

並び順は日付、内容、版数の順にします。日付を先頭に置くとファイル一覧が時系列に並び、書式は8桁の数字（20260923）を使います。年月日をハイフンで区切る書式でも並びますが、区切り文字を混在させると検索で拾えなくなるため、社内で1種類に固定してください。区切りはアンダースコアかハイフンのどちらか一方に統一し、全角スペースは使いません。一部の業務アプリとURL変換で壊れます。

要素の決め方には行政の標準例がそのまま使えます。内閣府の資料は、内容と性質が類推可能となるよう過不足なく名称を設定すること、名称付与に統一性を持たせること、検索容易性のために複数のキーワードを入れつつ過度に長い名称を避けることを挙げています。避けるべき用語も具体的です。「〜文書」「〜書類」「〜ファイル」「〜綴り」「〜雑件」「〜関係資料」「その他〜」のような意味を持たない語、そして特定の担当者にしか通じない略称。版数は v01 形式の2桁で固定し、「最終版」「最終版2」は使わないでください。

保存期間と措置を名称に埋める方式｜行政の【小分類：30移】の応用

行政のフォルダ名は、保存期間と満了後の措置を記号で埋め込む設計になっています。30年保存で移管なら【小分類：30移】、5年保存で廃棄なら【小分類：05廃】、常用文書で移管なら【小分類：常移】。フォルダ名を見ただけで、いつ何をするかが判別できます。

民間へ移すなら【契約_10廃】【技術_05廃】のように、分類コードと年限と措置を組み合わせた形になります。効果は棚卸しのときに出ます。年限切れのフォルダを名称の文字列だけで抽出でき、一覧を作る手間がかかりません。ただし副作用があります。保存期間を変更するとフォルダ名も変わり、ショートカットが切れます。判断基準はこうです。年間の文書発生が数百件までならフォルダ名に埋める、それ以上の規模なら名称は固定して文書管理台帳の列で年限と廃棄予定日を管理する形に寄せてください。

フォルダ階層とメタデータ検索の使い分け｜寄せ先を決める判断基準

ここは玉虫色にせず言い切ります。分類体系はフォルダとメタデータのどちらか一方に寄せるべきで、両方に同じ情報を持たせる設計は必ず不整合を起こします。

メタデータ検索へ寄せる判断基準｜検索条件が2軸以上になる文書群

基準は検索条件の軸数です。常時2軸以上で探す文書群はメタデータへ寄せます。契約書を「取引先×契約種別×締結年」で探す運用なら、階層のどれか1つを第1階層に選んだ時点で、残り2軸の検索は全フォルダ走査になります。1軸で足りる文書群、たとえば議事録を開催日だけで探すなら、フォルダのままで支障ありません。

採用しないほうがよい場面も明示します。メタデータの入力を人手に任せ、登録者が月10人以上いて、入力の必須化ができない運用です。未入力のファイルは検索結果に出てこないため、フォルダ運用より発見性が下がります。入力を必須にできないなら階層で押し切ってください。必須化の可否は製品仕様に依存するため、文書管理システムの開発・導入を検討する段階で、登録フォームの必須項目設定と未入力時の保存拒否が可能かを確認しておくと判断を誤りません。

電子取引データを分類から外す判断｜検索要件3項目を索引で満たす形

電子帳簿保存法の電子取引データは、全社の分類体系に載せないでください。保存要件が別だからです。国税庁の電子帳簿保存法一問一答は検索機能の要件として、取引年月日その他の日付・取引金額・取引先を検索条件に設定できること、日付と金額は範囲を指定して条件を設定できること、二以上の記録項目を組み合わせて条件を設定できることを示しています。

フォルダ階層では、このうち範囲指定と組み合わせが満たせません。実務上の解は二つです。ファイル名へ日付・金額・取引先の3要素を入れて一覧の絞り込みで対応するか、索引簿を別に持って本体ファイルと紐づけるか。いずれにせよ保存場所は専用領域へ分離し、品質文書や技術文書と同居させない構成にします。ISO9001が求める文書化した情報の版管理とは要件の性質が違うため、同じ分類表で両方を満たそうとすると、どちらの要件も中途半端になります。

既存共有フォルダの棚卸しと移行順序｜凍結日を決める切り替え手順

新しい分類表ができても、既存フォルダの移行で失敗すると元に戻ります。順序と期限を先に決めてください。

棚卸しの実施順序と判断基準｜更新日2年超のファイル群の切り離し方

全件を新分類へ移す必要はありません。更新日で切り分けます。

全ファイルを更新日つきで一覧化する
2年以上更新のないファイルをアーカイブ領域へ退避する
残ったファイルだけを新分類へマッピングする
マッピングできないものを未分類として集計する

四つ目の件数が判断材料になります。未分類の比率が15%を超えたら、分類表の粒度が実態と合っていません。この段階で分類表へ戻るほうが、移行後に「その他」が膨らむより安く済みます。退避した領域は削除せず6か月間は残し、参照ログを取ってください。6か月間で一度も参照されなかった文書は、保存年限を確認したうえで廃棄申請に回せます。

旧フォルダの凍結日と並行運用｜読み取り専用に落とすまでの期間

凍結日を決めないと、二重運用が固定化します。新旧の両方に書き込める期間は2週間までとし、以後は旧フォルダを読み取り専用へ落としてください。この期間を1か月以上に延ばした事例では、旧フォルダ側に新規文書が作られ続け、移行そのものが振り出しに戻ります。

読み取り専用へ落とした後も、すぐには削除しません。保存年限の確認と、退避漏れの発見に時間が要るためです。目安は6か月から1年、参照が止まった時点で削除判断に進みます。分類設計と並行して既存文書の移行までを外部に任せる場合は、移行対象の件数と未分類率を見積もり時点で共有しておくと、作業量の認識がずれません。

よくある質問

分類方法の設計で実際に判断が止まりやすい論点を、五つに絞って答えます。

フォルダは何階層まで作るのが妥当ですか？

3層を基本とし、どうしても必要な場合だけ4層目を許容します。根拠はパス長です。Windows APIのMAX_PATHは260文字で、日本語のフォルダ名を3層とファイル名で140文字前後、クラウド移行時のプレフィックスで70〜90文字を消費します。4層目を足すと上限に触れ、移行時にファイルが開けなくなる事故が起きます。階層で表現しきれない分類軸は、メタデータかファイル名へ移してください。

部署名をフォルダ名に使ってはいけませんか？

第1階層に置く使い方だけを避けてください。組織改編でパスが変わり、ショートカットや外部参照が一斉に切れるためです。人事・経理のようにアクセス権を部門単位で厳格に切る文書群は例外で、権限境界と分類境界を一致させる意味があります。それ以外の文書は業務プロセスを第1階層に置き、部署名は必要ならファイル名の一要素として持たせる形が扱いやすくなります。

年度フォルダは第1階層と最下層のどちらに置くべきですか？

最下層です。第1階層に年度を置くと、年度をまたぐ長期案件の文書が別フォルダへ分断され、案件単位の参照ができなくなります。推奨する並びは業務プロセス、文書種別、年度の順です。この順序なら保存年限が種別ごとに揃うため、年限が来た年度フォルダを丸ごと廃棄対象として抽出できます。

既存のフォルダを一度に作り直しても問題ありませんか？

全件を一度に移す進め方は勧めません。更新日で切り分け、2年以上更新のないファイルをアーカイブへ退避してから、残りだけを新分類へ移してください。移行中は新旧の並行運用期間を2週間までに区切り、その後は旧フォルダを読み取り専用にします。期間を延ばすほど旧フォルダへの新規作成が続き、移行が完了しなくなります。

ファイル名に日付を入れる場合の書式はどれが無難ですか？

8桁の数字（20260923）を先頭に置く書式が扱いやすい形です。一覧が時系列に並び、文字列としての並び替えと日付順が一致します。区切り文字はアンダースコアかハイフンのどちらかに社内で固定し、混在させないでください。全角スペースと全角記号は、一部の業務アプリやURL変換で文字化けの原因になるため使いません。