グループウェアの文書管理はどこまで足りるか｜専用システムへ移す判断基準

社内規程も契約書も見積書も、グループウェアのファイル管理に入れてある。この状態のまま監査や税務調査を迎えられるかどうかを、機能単位で確かめていきます。この記事では容量・全文検索・版管理・保存年限・監査ログの5つについて、グループウェアが公式仕様としてどこまで持っているかを製品ドキュメントの実数で確認し、専用の文書管理システムへ切り出すべき条件を文書点数・法令要件・監査対応の3つで示します。両方を併用するときに二重投資にならない境界の引き方までが、この記事で扱う範囲です。

まとめ：グループウェアで足りる範囲と、専用システムへ切り出す3つの引き金

グループウェアの文書管理は、機能が抜けているのではありません。共有と回覧を速くする目的で設計されているため、上限の置き方が違うだけです。版は世代数の上限を超えると古いものから自動で消え、容量はテナント全体で分け合い、ログは運用記録として残ります。日々の共有だけなら、この設計で不足は出ません。

切り出す判断は3つの引き金で決めてください。法令で保存年限が決まった文書を入れ始めたとき、外部監査や税務調査で文書の提出を求められる立場になったとき、そして取引先と同じ文書を継続的にやり取りするようになったとき。どれか1つでも当てはまれば、文書の点数が少なくても専用システム側へ移す前提で設計を始めます。逆に3つのどれにも当てはまらず、扱う文書種別が10種類以下であれば、移行を急ぐ理由はありません。

グループウェア付属の文書管理機能で実際にできることと設計上の前提

最初に、事実と違う前提を潰しておきます。「グループウェアには版管理も全文検索も無い」という説明が比較記事には並びますが、製品の公式ドキュメントに当たると、どちらも実装されています。問題となるのは機能の有無ではなく、上限をどこに置いた設計なのかという点です。グループウェア自体の定義と選び方はグループウェアとは？機能・料金とクラウド型オンプレ型の違い、選び方を解説で整理しているため、ここでは文書機能だけを取り出して見ていきます。

世代数で古い版が消えるバージョン管理と、専用システムの版数上限の差

サイボウズのGaroonを例に取ります。クラウド版Garoonのファイルの一般設定には、バージョン管理で保持するファイルは世代単位で設定すると明記されており、新たにファイルが更新されると、指定した世代を超える古いファイルは削除されると書かれています。2世代に設定すれば「現在／1つ前／2つ前」の3本だけが残る形です。

対してMicrosoft LearnのSharePointの制限では、バージョンの上限は50,000のメジャーバージョンと511のマイナーバージョンと示されています。世代数は運用で調整できるとはいえ、桁が4つ違う設計です。

この差が効くのは、過去の版そのものを証拠として出す場面に限られます。品質文書の改訂履歴を10年分たどる、契約書の修正経緯を相手方と突き合わせる、といった要求が無いなら、5世代も残せば実務は回ります。世代数の設定を確認せずに運用している会社では、上限に達した時点で古い版が静かに消えている点だけ押さえてください。

添付ファイル本文まで届く全文検索の範囲と、条件では拾えない項目

全文検索も、入っています。クラウド版Garoonの検索の仕様によれば、全文検索に対応しているのはスペース・メッセージ・掲示板・ファイル管理・メールの5つで、添付ファイル名やファイルの内容も含めた検索ができると書かれています。ファイル名しか引っかからない、という理解は現行仕様と合いません。

足りないのは、キーワードではなく属性で絞る検索のほうです。取引先で絞り、金額の範囲を指定し、契約満了日でソートする。この形の検索は全文検索では代替できません。文書にメタデータの入力欄を持たせ、その項目で検索する仕組みが要ります。

ここは法令要件と直結します。国税庁の電子帳簿保存法一問一答（電子取引関係）の適用要件は、問26で検索機能の要件を3つ挙げています。取引年月日その他の日付・取引金額その他の主要な記録項目を検索条件に設定できること、日付または金額は範囲を指定して条件を設定できること、2以上の任意の記録項目を組み合わせて条件を設定できること。3つ目の組み合わせ条件が、全文検索では満たせない部分です。

1ファイルの上限とテナント全体の共有枠という2段の容量制限の効き方

容量の制限は2段構えで効いてきます。1ファイルあたりの上限と、契約全体で使える総量です。

Garoonの場合、システム管理者が選べる1ファイルあたりのサイズ制限は512KB・1MB・3MB・5MB・10MB・50MB・100MB・1024MBの8段階と公式ヘルプに列挙されています。総量側は、SharePointを含むMicrosoft 365で見ると、組織あたりの合計ストレージが1TBにライセンスあたり10GBを加えた値、1サイト（サイトコレクション）あたりの最大が25TBです。100ライセンスの会社なら1TB＋1TBで2TBという計算になります。

数値だけ見ると潤沢ですが、詰まるのは図面と動画、そしてスキャンした紙です。A1判の図面を300dpiでスキャンすれば1枚で数十MB、施工写真を含む竣工図書一式なら数GBに届きます。設計部門や製造部門がグループウェアへ図面を入れ始めた会社では、容量そのものより先に、1ファイルの上限にぶつかって分割保存が始まり、版の対応が取れなくなる順序で崩れていきます。

グループウェアと文書管理システムの機能差を5項目で並べた実務比較

5つの軸で並べると、どこまでが設定で吸収でき、どこからが製品の設計思想の違いなのかが見えてきます。比較表のあとで、差が大きい2軸を掘り下げます。

容量・検索・版管理・保存年限・監査ログの5軸で見た到達点の違い

下表は、各製品の公式ドキュメントに記載された仕様と、実務で求められる水準を突き合わせたものです。数値は本記事の執筆時点で公開されている仕様であり、プランや契約形態で変わります。

表の中で設定では埋まらないのは、保存年限と監査ログの2行です。容量は契約の追加で、検索は運用ルールである程度まで補えます。年限管理と証跡出力は、文書1件ごとに属性を持たせる仕組みが前提になるため、あとから運用でかぶせることができません。文書管理システム側の機能の全体像は文書管理システムとは？機能とメリット、ファイルサーバーとの違いと選び方を解説にまとめています。

保存年限の管理が最も差が出る箇所｜7年と10年の起算と自動廃棄

法人の帳簿書類の保存期間は法令で決まっています。国税庁のタックスアンサー No.5930 帳簿書類等の保存期間（令和7年4月1日現在法令等）は、帳簿と取引関係書類を、その事業年度の確定申告書の提出期限の翌日から7年間保存すると定めています。ただし青色申告書を提出した事業年度で欠損金額が生じた事業年度などは10年間です。棚卸表、貸借対照表、損益計算書、注文書、契約書、領収書がこの「書類」に含まれます。

ここで問題になるのが起算日です。作成日でも保存日でもなく、確定申告書の提出期限の翌日から数えます。グループウェアのファイル管理には保存年限という属性欄がないため、フォルダ名に年度を入れ、人の手で管理する形です。年度またぎの契約書や、決算期を変更した年度の書類は、この運用だと必ず取りこぼします。

文書管理システム側は、文書種別ごとに年限と起算基準を設定し、到来した文書を一覧化して廃棄申請へ回す機能を持ちます。文書の点数が増えるほど、この差が人手の作業量に跳ね返るという関係です。電子取引データに絞った要件と製品選定の考え方は電子帳簿保存法に対応する文書管理システムとは？要件と選び方・自社開発の判断で扱っています。

監査ログの保持期間とアクセス履歴の粒度で生じる説明責任の差の大きさ

比較記事でよく見る「グループウェアには監査ログがない」という説明も、現行仕様とは合いません。クラウド版Garoonのファイル管理のログには、ファイルのダウンロードが [download] file (hid, fid, file_name, title, version) という形式で記録されると明記されています。登録は create、更新は update、フォルダの完全削除は permanent delete として、誰がどのファイルのどの版に触れたかまで残る設計です。

差が出るのは、そのログを監査の証跡として取り出す工程のほうです。グループウェアのログはシステム管理画面から期間とアプリケーションを指定して取り出す運用ログであり、「この契約書に、いつ誰がアクセスしたか」を文書1件を主語にして提出する形にはなっていません。監査人が求めるのは後者です。

実務での線引きはこうなります。内部統制の整備状況を示す程度なら、グループウェアの操作ログをCSVで書き出して添付すれば通ります。金融庁検査や会計監査で特定文書の閲覧履歴を求められる立場であれば、文書単位で証跡を出せる仕組みが必要です。自社がどちらかは、監査法人や主幹官庁から過去に何を求められたかで判定できます。

グループウェアの文書管理で足りる会社の条件と、破綻が始まる規模

規模の目安を数値で持っておくと、移行の議論が「感覚の不便さ」から抜け出します。公式ドキュメントに書かれた上限値と、その手前で運用が詰まり始める水準は別物です。

文書点数が1万件を超えたあたりで起きる検索性と権限設計の詰まり

上限値そのものは十分に大きく取られています。SharePointの制限では、1つのライブラリに最大3,000万個のファイルとフォルダーを含められると記載されています。数だけ見れば、中堅企業の文書が入り切らないことはありません。

先に詰まるのは権限のほうです。同じドキュメントには、リストまたはライブラリ内のアイテムに対する一意のアクセス許可のサポートされる制限は50,000で、推奨される一般的な制限は5,000と書かれています。さらに、リスト・ライブラリ・フォルダーに100,000を超えるアイテムが含まれている場合、権限の継承を解除できないという点も制約です。部門ごと・プロジェクトごとに個別の権限を切っていく運用は、この推奨値5,000の手前で設計を作り直す必要が出てきます。

体感として運用が苦しくなるのは、文書が1万件を超えたあたりです。この規模になると、フォルダ階層を掘っても目的の文書に届かず、全文検索でヒットした200件から正本を選べなくなります。正本と参考資料を区別する属性が無いことが原因であり、フォルダ設計を組み替えても解決しません。

専用システムへ移すべき3つの引き金｜法令保存・監査対応・外部共有

点数ではなく、性質で決めたほうが判断は速くなります。次の3つが引き金です。

• 法令で保存年限が定められた文書を、グループウェアに入れ始めた（帳簿書類の7年・10年、建設業法の帳簿、医療・製薬の記録など）
• 外部監査、税務調査、官公庁の立入検査で、文書とその取り扱い履歴の提出を求められる立場になった
• 取引先や委託先と同じ文書を継続的にやり取りし、社外の相手に版を指定して渡す必要が出た

この3つを引き金に置く理由は、いずれも後戻りできないからです。文書点数は減らせますし、フォルダ設計は組み替えられます。しかし「保存年限が定められた文書を、年限管理の無い場所に入れてしまった」という事実は、後から属性を付け直す作業でしか解消できません。1件あたり数分の入力でも、5,000件あれば数百時間の工数になります。

併用が二重投資になる範囲と、保存先の境界をどこに引くかの決め方

全部を移す必要はありません。むしろ全面移行を選んだ会社ほど、現場が従来どおりグループウェアへ置き続けて二重管理になります。境界は文書の性質で引いてください。

グループウェアに残すのは、作成途中の資料、会議資料、部門内の連絡文書、更新頻度が高く保存年限のない文書です。専用システムへ移すのは、契約書、稟議の決裁済み文書、規程集、図面の正式版、法定保存文書。判断の軸は1つで、「その文書の最終版を、3年後に誰かが根拠として持ち出す可能性があるか」です。あるなら専用側、ないならグループウェア側に置きます。

この線引きを先に決めておくと、製品を2つ持つことが二重投資になりません。逆に境界を決めないまま両方を導入すると、同じ文書が2か所に存在し、どちらが正本か分からない状態になります。自社の文書種別に沿って境界を設計し、既存のグループウェアと連携させる進め方は文書管理システム開発でも相談を受けています。

グループウェアのまま据え置いてよい場面と、据え置きが実損に変わる分岐

ここは条件を付けて言い切ります。移行しないという判断は、正しい場面では正しい選択です。ただし据え置きが費用として跳ね返る分岐点があり、そこを越えると先送りするほど高くつきます。

移行の見送りを決めてよい3条件｜文書種別・保存年限・監査の有無

次の3条件を全部満たすなら、専用システムの導入は過剰です。扱う文書種別が10種類以下であること。法令で保存年限が定められた文書を電子のまま保存していない（紙の原本を別管理している）こと。外部監査と官公庁の立入検査の対象になっていないこと。

この規模なら、投資すべきはシステムではなく命名規則とフォルダ設計です。文書管理システムのライセンス費は小規模構成でも年間数十万円から、導入支援を含めれば初年度で数百万円に達します。年に数回しか探さない文書のために払う金額ではありません。

逆に言えば、3条件のうち1つでも崩れた時点で見送りの前提は失われます。特に多いのが、紙で保管していた契約書を電子化した途端に2条件目が崩れる型です。電子化の実行と同時に年限管理の置き場所を決めないと、スキャンしたPDFがグループウェアに積み上がっていきます。

移行が遅れた分だけ費用が増える理由｜移行時のメタデータ再入力の量

先送りのコストは、ライセンス費の節約分を上回ります。理由は移行作業の性質にあります。

グループウェアに置かれた文書には、文書種別・保存年限・起算日・機密区分・承認者といった属性が付いていません。専用システムへ移すときは、この属性を1件ずつ入力する必要があります。ファイル名から機械的に判定できるのはせいぜい日付と文書種別までで、起算日と承認者はファイルを開いて確認する作業になります。

1件あたり3分として、3,000件で150時間、10,000件で500時間。年間1,500件のペースで増える会社なら、移行を2年先送りするだけで作業量が150時間増える計算です。この工数は外注しても内製しても発生し、移行の直前に一度だけ発生します。だからこそ、引き金が引かれた時点で点数の少ないうちに動かすほうが安く済みます。

既存のグループウェアを残したまま文書管理だけ切り出す実装の進め方

移行の現実的な順序を示します。グループウェアの利用は止めません。

1. 直近1年に更新のあった文書だけを対象に、文書種別と保存年限の一覧を作る
2. 法定保存文書と決裁済み文書だけを先に専用システムへ移し、属性を入力する
3. グループウェア側の当該フォルダを読み取り専用にし、新規の保存先を専用システムへ切り替える
4. 移さなかった旧文書は、年限到来まで読み取り専用のまま据え置く

過去分を全部移そうとすると、属性入力の工数で止まります。手を付けるのは新規と直近分に限り、旧文書は凍結してそのまま年限を待たせるほうが早く立ち上がります。既存のグループウェアと認証を揃え、文書へのリンクを掲示板やメッセージから張れるようにしておけば、現場の操作は大きく変わりません。連携の設計を後回しにすると、画面を2つ開く運用になって定着が止まります。

よくある質問

グループウェアの文書管理について、導入検討の場でよく挙がる質問をまとめました。

グループウェアの文書管理機能だけで電子帳簿保存法に対応できますか？

電子取引データに限れば、対応できない部分が残ります。国税庁の一問一答が示す検索要件のうち、日付や金額の範囲指定と、2以上の記録項目を組み合わせた検索は、全文検索では満たせません。取引先・取引年月日・取引金額を属性として持たせ、その項目で絞り込める仕組みが要ります。ファイル名にこの3項目を規則的に含める運用で代替する方法もありますが、命名規則の徹底が前提になるため、取引件数が月に数十件を超えるなら専用システム側へ寄せたほうが確実です。

SharePointは文書管理システムとグループウェアのどちらに入りますか？

どちらとも言い切れない位置にあります。ファイルの保管・共有・権限管理という文書管理システムの中核機能を持つ一方、掲示板やチームサイトといったグループウェア寄りの機能も併せ持つためです。どちらに位置付けるかの判断を分けるのは、導入の仕方です。ライブラリに列を追加して文書種別や保存年限を属性として持たせ、保持ラベルで廃棄まで管理する設計にすれば文書管理システムとして機能します。フォルダに入れて共有するだけの使い方なら、容量の大きいファイル共有にとどまります。

グループウェアの文書管理と共有フォルダ（ファイルサーバー）はどう違いますか？

グループウェア側には、社外からの参照、コメントやワークフローとの連結、操作ログの記録という3点があります。共有フォルダはネットワーク内での高速なファイル入出力に向く一方、誰が閲覧したかの記録は既定では細かく残りません。ただし、保存年限の管理と属性検索が無い点は両者に共通します。共有フォルダからグループウェアへ移しても、法令保存の課題は解決しない点に注意してください。

移行の費用はどのくらい見ておけばよいですか？

ライセンス費と移行作業費を分けて見積もってください。ライセンス費は利用人数と保管容量で決まり、移行作業費は文書点数と属性入力の手間で決まります。後者は見落とされやすく、1件あたり3分として3,000件で150時間、10,000件で500時間という作業規模です。既存文書のうち何件を移すかを先に決めると、見積もりの幅が大きく縮みます。全件移行を前提にせず、直近分と法定保存文書に絞る方針を先に立てるのが費用面では有利です。

グループウェアの版管理で古いファイルが消えるのを防げますか？

設定である程度は防げます。Garoonの場合、バージョン管理の世代数はシステム管理者が上限値を設定し、実際の世代数は各ユーザーがファイル登録時に指定する仕組みです。上限を大きく取れば保持できる版は増えます。ただし世代数を増やすほどストレージを消費するため、テナント全体の容量と引き換えになります。改訂履歴そのものを証拠として残す必要がある文書は、世代数の調整で対処せず、全版を保持する仕組みへ移すほうが確実です。

関連記事

• 文書管理システムの比較｜クラウド・オンプレ・受託開発の選定基準を解説：専用システムへ移すと決めたあと、どの提供形態を選ぶかの基準を扱っています。
• 文書管理システムの費用相場｜料金体系と受託開発のコスト内訳を解説：移行費用の見積もりに必要な料金体系の内訳が分かります。
• グループウェア比較｜料金と最低ユーザー数、Microsoft 365との棲み分けで決める選定基準：グループウェア側を選び直す場合の料金と契約条件の見方を扱っています。