自治体向け文書管理システムの選び方｜公文書管理条例と電子決裁・LGWAN要件

自治体向け文書管理システムは、民間企業向けの製品と要件の出発点が違います。根拠になるのは公文書管理法そのものではなく、各団体が定めた公文書管理条例や文書管理規程です。さらに2026年4月1日には地方自治法第244条の6が施行され、サイバーセキュリティを確保するための方針を定めて公表することが義務になりました。この記事では、制度上の違い、起案から施行までの電子決裁に必要な機能の範囲、三層の対策とLGWAN・ガバメントクラウドを踏まえた配置先、基幹業務の標準化との関係、そして受託開発を選ぶ条件と見送る条件までを一次情報で整理します。

まとめ｜自治体向け文書管理システムの選定で先に固める三つの要件

結論から示します。自治体向け文書管理システムの選定で最初に固めるのは、次の三つです。第一に、自団体の文書管理規程にある決裁区分・保存期間表・簿冊分類を、そのまま設定値として写せるかどうか。第二に、起案から合議・決裁・施行・完結までの流れを、代決や後閲を含めて再現できるかどうか。第三に、庁内ネットワークのどのセグメントに置くかを、三層の対策のモデルと整合させて決められるかどうか。

この三つが決まらないまま製品比較の表を作っても、比較軸が空回りします。製品名の一覧は最後で構いません。

2026年度からは、要件の外側に新しい制約が加わりました。地方自治法第244条の6が2026年4月1日に施行され、議会および長その他の執行機関は、それぞれが管理する情報システムのサイバーセキュリティを確保するための方針を定め、公表する義務を負います。公表した方針と、調達する文書管理システムの監査ログやアクセス制御の仕様は整合していなければなりません。方針を先に固め、そこから逆算して仕様書を書く順序になります。

民間向け製品と自治体向け文書管理システムで要件が分かれる制度上の理由

「自治体向け」と銘打った製品が別カテゴリとして存在するのは、業界慣行の違いではなく、文書の管理義務を課す法令の構造が国の行政機関と地方公共団体とで異なるためです。

公文書管理法第34条が地方公共団体に課すのは努力義務という位置づけ

公文書等の管理に関する法律（平成21年法律第66号）の第34条は、地方公共団体について「この法律の趣旨にのっとり、その保有する文書の適正な管理に関して必要な施策を策定し、及びこれを実施するよう努めなければならない」と定めています。努力義務です。第5条の分類・名称・保存期間の設定も、第8条の保存期間満了後の移管または廃棄も、条文上の名宛人は行政機関の長であって、市区町村長ではありません。

ここを取り違えると、要件定義が根拠のない作文になります。求める機能の法的な根拠は、公文書管理法の条文ではなく、その趣旨を受けて各団体が制定した条例・規則・規程の側。提案書に「公文書管理法に準拠」とだけあれば、どの要件を自団体のどの規程で満たすのかを確認してください。

条例・規則・規程の三層構造から要件を引き出す文書管理規程の読み方

内閣府の地方公共団体における公文書管理の取組調査では、令和6年4月1日時点で全都道府県がルールを制定しており、うち条例の形式は19団体でした。市区町村は1,733団体（99%）が制定済み。同じ調査は令和8年4月1日を基準日とするものが2026年7月22日に公表されています。ルールが無い団体はほぼありません。問題は、その多くが条例ではなく規則・規程の階層に置かれている点です。

規則・規程は議決を経ずに改正できます。裏を返せば、規程改正のたびにシステムの設定変更が発生する構造。要件定義では、規程のどの条項がどの設定項目に対応するかを一覧にし、改正頻度の高い条項を洗い出しておくと後の保守が軽くなります。保存期間表と簿冊分類表は、初期データとして投入する前提でCSV化しておくのが実務的です。

情報公開請求と個人情報保護で必要になる文書ファイル管理簿の要件

自治体の文書管理には、民間には無い出口があります。情報公開請求への対応です。請求者が対象を特定できるよう保有文書の目録を整備・公表する団体が多く、その元データを文書管理システムから出力できるかが実務上の分かれ目。

確認すべき点は三つです。目録項目（分類、名称、作成年度、保存期間、満了日、媒体、所管課）を任意の組み合わせで抽出できるか。公開・非公開の別と不開示情報の該当条項を属性として持てるか。部分開示のためにマスキングした写しを、原本とは別バージョンとして紐づけられるか。三点目を備えない製品は珍しくないため、デモで実際の請求案件を想定して操作してもらうと差が出ます。

起案から施行・保存までの行政文書フローに対応する電子決裁機能の範囲

行政文書のライフサイクルは、民間の稟議とは工程の粒度が違います。汎用のワークフロー製品で埋めようとすると、運用でカバーする範囲が膨らみます。

起案・合議・決裁・施行という四工程と民間ワークフローの機能差

自治体の文書は、起案（原議の作成）、合議（関係課の同意）、決裁（専決権者の意思決定）、施行（浄書・公印・発送）の四工程を経て完結します。民間の稟議システムの承認ルートは、このうち決裁にしか対応していないことがある。差が出るのは合議と施行です。

合議は、単なる並列承認ではありません。合議先が「異議あり」とした場合に起案課へ差し戻し、修正のうえ再度合議に回す往復が発生し、その履歴が原議に残らなければならない。施行の側では、公印使用簿との連動、文書記号・番号の自動採番、発送簿への記録まで含めて管理する団体もあります。一般的な文書管理システムが備える機能の範囲は文書管理システムとは？機能とメリット、ファイルサーバーとの違いと選び方を解説で整理しました。自治体固有の工程は、そこに上乗せする差分だと捉えてください。

代決・後閲・専決区分をシステム側の設定に落とすときに詰まる項目

導入プロジェクトで最も設定に時間がかかるのが、決裁権限の表現。詰まりやすい項目を挙げます。

• 専決区分：同じ文書種別でも金額や案件区分で決裁者が変わる多段の条件分岐
• 代決：決裁者不在時に下位職が代わって決裁し、後日の後閲で追認する二段階の記録
• 兼務・充て職：一人の職員が複数の職位を持つ場合のルート判定
• 組織改編：年度替わりの課の統廃合に伴う未完結文書の引き継ぎ先

実装コストが跳ね上がるのは、専決区分の条件分岐と組織改編への追随。専決規程が細かい団体ほど、標準機能では表現しきれず個別開発に寄ります。要件定義の初期に条件を全パターン書き出し、分岐数を数えてください。三桁に届くなら、パッケージ標準での吸収は難しいと見たほうが見積もりの精度は上がります。

紙決裁との併存期間に決めておく原本の所在と押印の取り扱い基準

全庁一斉に電子決裁へ移る団体は少数です。多くは文書種別ごとに段階移行し、数年の併存期間を置きます。この期間の運用が曖昧だと、同じ案件の記録が紙と電子に分かれ、情報公開請求のときに探せなくなる。

決めておく事項は二つです。第一に、どの文書種別を電子で完結させ、どれを紙のまま扱うかの線引きを文書分類表の単位で明記すること。第二に、スキャン登録した場合に電子データと紙の原本のどちらを正本とするかを規程上で定義すること。「両方保管する」は判断の先送りです。正本を電子と決めたなら紙の廃棄基準まで書き、紙と決めたなら電子側は参照用と割り切る。この二択を先に済ませると、移行の設計が一段軽くなります。

三層の対策とLGWAN・ガバメントクラウドから決める文書管理基盤の配置先

機能要件が固まっても、置き場所が決まらなければ調達仕様は書けません。自治体のネットワークは三層の対策で分離され、文書管理システムは原則としてLGWAN接続系に置かれます。

αモデル・α′モデル・βモデルの違いと調達仕様に生じる接続制約

総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」は、2026年3月27日に改定され令和8年3月版となりました。三層の対策の枠組みは維持されたうえで、ネットワーク構成の選択肢が広がっています。αモデルは従来どおりの分離を保つ構成、α′モデルはLGWAN接続系からローカルブレイクアウトで特定のクラウドサービスへ直接アクセスする構成、βモデルは業務端末をインターネット接続系に置く構成です。

どのモデルを採るかで、調達仕様の書き方が変わります。αモデルの団体がインターネット経由のSaaS型を入れようとすると、画面転送やファイル無害化を挟むことになり、添付ファイルの取り回しに制約が出る。仕様書に「クラウド型」とだけ書かず、自団体のモデル名と接続経路を明記して、提案側に実現方式を書かせてください。

LGWAN-ASPとガバメントクラウドの選択で分かれる調達と運用の負担

LGWAN接続系で使えるクラウドサービスは、LGWAN-ASPとして登録されたものに限られます。登録の有無は提案の前提条件であり、製品選定の最初のフィルタ。一方、ガバメントクラウド上の環境を使う構成は、基幹業務の移行で整備した基盤を文書管理にも広げる形。

負担の性質が違います。LGWAN-ASPは選択肢が限られる代わりに、接続と運用の設計を提供者側が引き受けます。ガバメントクラウドは自由度が高い代わりに、アカウント管理、ネットワーク設計、コスト管理の責任が団体側に残る。情報システム課が数名という規模で後者を選ぶと、運用が回らなくなります。

配置先ごとに初期費用・運用体制・改修自由度を比べるための判断材料

三つの配置先を、調達で効いてくる三軸で並べます。

三軸は独立ではありません。改修自由度を取れば運用体制の負担が増え、運用を軽くすれば標準機能への譲歩が増えます。専決規程の分岐が多い団体ほど改修自由度の側に寄るため、庁内に保守要員を置けないなら、保守も外部に委託する前提で予算を組んでください。

2026年4月施行のサイバーセキュリティ方針義務が調達仕様に及ぼす影響

2026年度の調達から、仕様書に新しい前提が加わりました。地方自治法の改正です。

地方自治法第244条の6が求める方針の策定と公表という二つの行為

令和6年法律第65号による改正で地方自治法に第244条の6が新設され、附則第一条第二号の定めにより、この規定は令和8年4月1日から施行されています。第1項は、議会および長その他の執行機関に対し、それぞれが管理する情報システムの利用に当たってのサイバーセキュリティを確保するための方針を定め、これに基づき必要な措置を講じるよう義務づけるもの。第2項は方針を定めまたは変更したときの公表義務、第3項は総務大臣が策定・変更の指針を示す旨を定めます。

注意したいのは名宛人が「議会及び長その他の執行機関」と分かれている点です。教育委員会や選挙管理委員会もそれぞれ方針を持ちます。全庁共通のシステムを入れるなら、執行機関ごとに異なる要求水準を一つの設定で満たせるかを確認してください。

方針の公表義務を前提に文書管理システムへ書き込む監査ログ要件

方針が公表されると、その内容と実装のずれが外から見える状態になります。仕様に落とすなら、監査ログの要件を具体的な項目まで書き切ってください。閲覧・更新・削除・出力・権限変更のそれぞれについて、いつ・誰が・どの文書に対して行ったかを記録し、記録自体を管理者権限でも改変できない形で保持する。保持期間は、方針で定めたインシデント対応の遡及範囲より長く設定します。

ログを取っているだけでは足りません。誰が定期的に点検し異常をどう判定するかまで運用手順に書き、方針の記載と矛盾しないかを見ておく。自治体DXの全体像と推進体制の考え方は自治体DXとは？推進計画第5.1版の重点8項目と進め方を実務目線で解説にまとめてあります。

標準化20業務の対象外という位置づけと基幹システム連携で生じる改修

基幹業務システムの標準化が進むなかで、文書管理は別の扱いを受けます。この位置づけを踏まえずに調達時期を決めると、二重の改修費が発生します。

文書管理が標準化対象20業務に含まれない理由と調達時期のずれ

標準化の対象は、住民基本台帳や地方税など20の基幹業務です。文書管理、財務会計、公共施設予約といった内部管理系は対象に含まれず、従来どおり各団体の判断で調達します。原則の移行期限だった2025年度末は2026年3月に過ぎ、デジタル庁が2026年6月30日に更新した公表値では、全34,366システムのうち10,013システム（29.1%）が期限後の扱いとなる特定移行支援システムに位置づけられました。制度の全体像は自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説で扱っています。

対象外である以上、更改時期は団体が自由に決められます。ただし自由と、いつでもよいことは別。基幹業務の移行が続く期間に文書管理の更改を重ねると、情報システム課の要員が両方に取られ、どちらの要件定義も薄くなります。

標準準拠システム側の仕様変更が文書管理の連携部分に波及する経路

対象外だから影響を受けない、とはいきません。基幹業務と文書管理を連携させている団体では、標準準拠システムへの移行でインターフェース仕様が変わり、対象外システム側の改修が発生します。よくある連携は、税や国保で出力した帳票を文書管理へ自動登録する経路と、住民記録の異動情報を起案の宛先として参照する経路。

この改修費は、標準化に向けた財政支援の対象に含まれないことがあります。移行計画の段階で、標準準拠システムと接続している対象外システムを洗い出し、連携方式（ファイル連携かAPI連携か）と改修見込みを別枠で見積もっておいてください。

パッケージ・LGWAN-ASP・受託開発の三択と受託開発を見送る条件

ここからは判断を示します。三つの選択肢は横並びではありません。順序があります。

人口規模と年間文書量から見た三つの選択肢の損益分岐となる条件

まずLGWAN-ASPの標準機能で足りるかを検証し、足りなければパッケージの個別カスタマイズ、それでも埋まらない差分があるときにだけ受託開発を検討する。この順序を崩す理由はありません。人口数万規模の町村で、専決区分の分岐が数十に収まり連携が帳票登録だけなら、標準機能で完結します。

受託開発が現実的な選択になるのは、次の条件が重なったときです。専決区分の分岐が三桁に達し規程改正の頻度も高い、基幹業務や財務会計との双方向連携が複数ある、情報システム課に仕様を書ける職員が継続的に配置されている。三つ目が欠けると、開発したシステムを維持できません。一般的な比較軸は文書管理システムの比較｜クラウド・オンプレ・受託開発の選定基準を解説で整理しました。自治体では、そこに専決区分の複雑さと連携本数の二軸を足して判断します。

受託開発を選ばないほうがよい三つの場面と実際に起きる失敗の型

受託開発を見送るべき場面を、条件付きで明記します。第一に、情報システム課の専任職員が二名以下で、人事異動により数年ごとに全員が入れ替わる体制のとき。仕様を理解する人がいなくなり、改修のたびにベンダーへの依存が深まります。第二に、現行の文書管理規程が長年改正されず実際の運用と乖離しているとき。乖離した規程をそのままシステム化し、運用で回避策を重ねる結果になる。規程の見直しが先です。第三に、標準化移行が未完了で連携先の仕様が確定していないとき。確定前に作った連携部分は、ほぼ作り直しになります。

失敗の型は決まっています。標準機能に合わせる判断を避け、現行の紙の運用をすべて再現しようとして開発規模が膨らむ。稼働後に規程が改正され、改修見積もりが年間保守費を上回る。避け方は単純で、要件を規程に紐づけて棚卸しし、直せる項目は先に直しておくことです。一創では、文書管理規程と決裁区分の棚卸しから、標準パッケージで吸収できる範囲と個別に作る範囲の切り分けまで含めて文書管理システム開発を承っています。現行規程と専決区分の一覧をご用意のうえ、ご相談ください。

保存期間満了後の移管・廃棄と電子公文書の長期保存を決める実務手順

文書管理システムの価値は、捨てるときと残すときに出ます。ここの設計が甘い製品は、数年後に容量と検索性の両方で行き詰まります。

保存期間の設定から満了時の移管・廃棄までをシステムで回す手順

公文書管理法は国の行政機関に対して、行政文書を作成・取得した時点で分類・名称・保存期間・保存期間の満了する日を設定し（第5条第1項）、満了した文書ファイルは国立公文書館等へ移管するか廃棄しなければならない（第8条第1項）と定めています。地方公共団体はこの枠組みを、条例・規程で自団体向けに置き換えて運用する形。システムに落とすと、次の流れになります。

1. 起案時に文書分類を選ぶと、保存期間表から保存期間と満了日が自動で入る
2. 完結処理の時点で簿冊に編綴し、保存場所と媒体を記録する
3. 満了年度に廃棄候補の一覧を自動生成し、所管課と文書主管課で審査する
4. 歴史公文書に該当するものは移管、それ以外は廃棄として結果を台帳に残す

三番目の審査工程を省いて自動廃棄にすると、後から復元できない事故が起きます。実行前に一覧の承認記録を残す設計にしてください。

十年後も読める状態で残すための長期保存フォーマットの選定基準

三十年保存や永年保存の文書を電子で持つなら、フォーマットの選定が要件になります。基準は二つ。第一に、特定の製品が無くても内容を再現できる形式であること。長期保存が前提ならPDF/A系に変換して保存し、元のファイルは参照用として別に持つ構成が扱いやすい。第二に、真正性を担保する手段を決めておくこと。電子署名を付すなら有効期限を超えて検証できるようタイムスタンプの延長を運用に組み込み、それが難しければ改変できない保管領域と監査ログの組み合わせで担保する方式を規程に明記します。

移管先の公文書館がある団体では、受け渡し形式を先に確認しておくと手戻りが減ります。館側がフォルダ構造とメタデータのCSVを指定しているなら、その形式で出力できるかどうかは調達要件そのもの。

よくある質問

自治体の文書管理システムの検討でよく挙がる質問を、判断の材料になる形でまとめました。

自治体向け文書管理システムと民間向け製品は何が違いますか？

機能の中心が違います。民間向けは版管理・全文検索・権限管理といった保管と検索が中心。自治体向けはこれに加えて、起案・合議・決裁・施行という行政文書のフローを再現する電子決裁機能、専決区分や代決の表現、文書分類表と保存期間表に連動した簿冊管理、情報公開請求に応じる目録出力を備えます。汎用製品に別のワークフローを組み合わせる構成も取れますが、原議に決裁履歴が残らない設計になりやすい点に注意してください。

公文書管理法は自治体にも適用されるのですか？

第34条により、地方公共団体は同法の趣旨にのっとって必要な施策を策定し実施するよう努める、という努力義務が課されています。分類や保存期間の設定を定める第5条、移管・廃棄を定める第8条は、条文上は国の行政機関の長が名宛人。したがってシステム要件の直接の根拠は、自団体の公文書管理条例や文書管理規程になります。仕様書には「公文書管理法準拠」ではなく、自団体の規程の条項番号を書いてください。

クラウド型の文書管理サービスをLGWAN接続系から使えますか？

LGWAN接続系から使えるのは、LGWAN-ASPとして登録されたサービスに限られます。一般のインターネット向けSaaSをそのまま利用することはできません。α′モデルでローカルブレイクアウトの対象にしている場合や、βモデルで業務端末をインターネット接続系に置いている場合は条件が変わります。総務省のガイドラインは2026年3月27日改定の令和8年3月版が最新のため、自団体のポリシーがどのモデルに沿っているかを確認し、提案依頼書に接続経路を明記してください。

基幹業務システムの標準化が終わってから導入したほうがよいですか？

連携がある場合は、標準準拠システムの仕様が確定した後に文書管理の更改を置くほうが手戻りは少なくて済みます。移行の途中でインターフェース仕様が変わると連携部分の改修が発生し、その費用は標準化向けの財政支援に含まれないことがあるためです。連携が無く単独で使う構成なら、標準化の進捗と切り離して調達して差し支えありません。判断の分かれ目は、基幹業務システムとのデータ連携の有無。

導入にかかる期間と主な作業はどのくらいを見ておけばよいですか？

標準機能を中心とした構成でも、要件定義から本稼働までは半年から一年程度を見込む団体が多くなります。工期の大半を占めるのは製品の設定作業ではなく、文書分類表と保存期間表の整備、専決区分の棚卸し、既存の簿冊データの移行方針の決定。個別開発を伴えば設計と試験の期間が加わります。規程と分類表の整備に調達前から着手すると、全体を圧縮できます。

関連記事

• 電子帳簿保存法に対応する文書管理システムとは？要件と選び方・自社開発の判断【2026年時点】：民間側の保存要件と自治体の条例に基づく要件の違いを比べられます。
• 文書管理システムの導入事例｜製造・建設・医療の業種別プロセスと定着のポイント：業種ごとの定着策をまとめた記事で、庁内展開の進め方の参考になります。
• 自治体DXとは？推進計画第5.1版の重点8項目と進め方を実務目線で解説：文書管理の更改を自治体DX全体のどこに置くかを整理できます。