行政書士事務所向け案件管理システム開発の完全ガイド

行政書士事務所向け案件管理システムは、案件・書類・期限を一元的に管理する仕組みです。方式は、業務種別、事務所の規模、既存データや連携範囲に応じて選びます。

行政書士特有の事件簿、許認可更新、預かり書類、補正対応を踏まえて書いています。情報は2026年時点のものです。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

行政書士事務所向け案件管理システムの概要

行政書士事務所向け案件管理システムは、依頼の受付から更新までを一案件として記録する仕組みです。書類回収、申請、補正の記録も、その案件の中にまとめて残せます。顧客名簿やタスク一覧だけの道具とは違い、業務の流れ全体を一つの案件として扱う点が特徴です。さらに、案件の現在地と次の作業を誰もが確認できるようにし、期限漏れや二重入力を減らす業務基盤になります。

一般的な顧客管理やタスク管理との違い

一般的なCRMは顧客との接点や営業活動に強く、タスク管理ツールは担当者と期限の管理に向いています。

行政書士業務では、建設業許可、産業廃棄物収集運搬業、宅建業免許、在留資格、会社設立、相続で必要な情報がそれぞれ異なります。

案件管理システムでは、業務種別ごとの必須項目や申請先、受付番号、補正履歴、預かり書類、成果物を案件に結び付けて記録できます。

事務所の規模で変わる導入効果

1人事務所では、代表者の記憶や個人のExcelに頼らず、外出先からでも案件の状況を確認できる点が効果になります。5〜20人程度の事務所では、特に、不在時の引き継ぎや未処理案件の把握、標準チェックリストの共有が大切です。さらに、複数拠点や大規模法人になると、拠点別・担当者別の売上集計や権限管理、監査ログ、業務品質の比較も検討の対象に入ります。

ポイント

依頼から入金、更新までを一案件として記録できるかが、判断の目安です。顧客名簿やタスク表だけで足りるかは、この点で比べると判断の材料がそろいます。

行政書士事務所向け案件管理システムの種類と選び方

方式は4つに分けられ、クラウドサービスとパッケージ（買い切り型を含む）、ローコード、個別開発があります。

選ぶときは、事務所の人数や業務種別の多さ、既存データ量を基準にします。さらに、帳票や会計との連携、将来の拠点数も見ておきます。

早く始めたい事務所に向くクラウド型SaaS

クラウド型SaaSは、サーバーやバックアップの準備が少なく、数日から1か月程度で始めやすい方式です。さらに、複数人で同時に確認でき、アップデートや法改正対応を提供者側に任せやすい点も利点です。

一方で、標準機能に業務を合わせる必要があります。独自の事件簿項目や特殊帳票が多い場合は、運用で吸収できる範囲かどうかを確かめます。

パッケージ・ローコード・スクラッチの使い分け

方式ごとの特徴と、導入前に確かめておきたい条件を並べます。

パッケージ：月額を抑えやすく、決まった端末で運用しやすい方式です。
運用条件：OSへの依存やリモート利用の可否を確かめます。複数人編集、バックアップ、法改正時の更新費用も対象です。
ローコード：顧客と案件の管理、期限、チェックリストを比較的短い期間で調整できます。権限や添付、帳票、プラグインを今後も使い続けられるよう設計します。
スクラッチ：独自の業務や、会計・電子申請・顧客ポータルとの連携に向いた方式です。費用と成否は、要件定義と保守体制で大きく左右されます。

ポイント

事務所の人数や業務の多さ、既存データ量、会計や帳票との連携、将来の拠点数で方式を絞ります。早く始めたいか、独自業務に合わせたいかで、候補の方向が変わります。

必要な機能と行政書士特有の要件

必要な記録を案件ごとに集めると、確認先がまとまります。

実務に合うかは、機能一覧だけでは判断しにくいものです。そこで、実案件を一つ取り上げ、相談から完了までの入力や帳票、期限通知を一つの流れとしてたどります。

案件・書類・期限を一つの流れで扱う機能

顧客・法人・担当者の台帳と案件を結び付け、受任日や業務種別、申請先などを同じ案件にまとめます。

案件の状態は、実際の流れに合わせて設定します。相談、受任、書類回収、書類作成と進み、申請、補正、許可・完了、請求、入金へと続きます。

こうして状態を管理しておくと、状態変更時の通知や、滞留日数が一定を超えた案件の一覧表示によって、代表者が担当者に個別に聞いて回る時間を減らせます。

事件簿・請求・入金の連携

顧客台帳と請求書を別々に入力すると、名前や住所、金額の転記ミスが起こります。そのため、案件の受任内容や報酬額、立替金、請求日、入金日は、同じ案件から確認できる構成が望まれます。

預かり書類と成果物：同じ案件の中から見られるようにしておきます。
帳票：案件データから作れば、入力と確認の手間を減らせます。

請求書や領収書、委任状の作成機能があっても、「事件簿要件に対応」という表示は判断材料の一つにとどまります。事務所の業務範囲と記録方法に合うかは、行政書士自身が確かめます。

電子申請との連携の範囲

電子申請を使う場合は、申請先や受付番号などの申請情報から、処理状況、補正依頼、公文書、電子納付までを案件管理の側に記録します。

e-Gov公式サイトで利用できる件数は、2026年6月30日時点で、厚生労働省2,835件、国土交通省978件、経済産業省255件、総務省119件です（出典：e-Gov電子申請公式、2026年6月30日現在）。

電子申請の対応状況は、業務ごとに同じとは限りません。そのため、対象となる手続と運用上の例外を洗い出し、連携の要件を決めておきます。

行政書士事務所向け案件管理システム開発の進め方

実案件で試した後に、テストと移行の確認へ進みます。

開発は、業務とデータの整理から始めます。期限漏れや二重入力など、経営上の損失が大きい課題から段階的に解決します。ただし、全業務を最初からデジタル化しようとすると、費用も確認項目も膨らみます。

▶ 詳細はこちら：行政書士事務所向け案件管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

企画と要件定義での現状の棚卸し

要件定義では、情報の保管場所と業務の流れを順に洗い出し、必要な内容を具体的に決めていきます。

Excel、紙の事件簿、共有フォルダ、メール、チャット、会計ソフトなどの保管場所を一覧にします。
業務種別ごとに、案件の開始・完了条件、担当者、必要書類、期限、例外処理を整理します。
共通項目と業務別項目を分けます。
機能の名前ではなく、「誰が、いつ、何を見て、何を判断するか」の形で要件を書きます。
期限の管理は、許可期限の180日前、90日前、30日前に担当者と所長へ通知する形で定義し、未対応の場合は一覧の上位に表示します。

建設業許可と在留資格では書類や期限が異なるため、業務ごとの違いを要件の段階で拾っておく必要があります。

要件を具体化すると、既製品で足りる部分と、個別に開発する部分の境界がはっきりします。

MVPから始める設計・開発

初回は必要な機能に絞り、実案件で試したうえで、追加開発を判断します。初回の対象には、必要書類チェック、権限、検索、バックアップも含みます。試す際は、個人情報をマスキングするか、担当者を限定した検証環境を使います。

顧客台帳、案件登録、状態、期限の管理を初回に優先します。
MVP（Minimum Viable Product）として、3〜5件の実案件で試験運用します。
会計連携、顧客ポータル、電子申請API、生成AIによる書類確認は、業務が定着してから追加します。

e-Gov電子申請APIでは、処理状況や公文書、電子納付情報、通知などを取得できます（出典：e-Gov Developer公式API仕様、2026年8月確認）。

ただし、API連携があっても、すべての手続を自動化できるとは限りません。そのため、対象手続ごとに検証しておきます。

テスト・移行・リリースの確認

テストとデータ移行は、受入条件と対象範囲を分けて確かめます。データ移行は、既存の台帳をそのまま取り込めば済む作業ではありません。

書類不足や担当者の休み、複数回の補正、期限変更、請求後の入金遅れを、テストの対象にします。
事件簿の出力、帳票金額、通知先、権限、操作ログ、バックアップからの復旧も、受入条件に含めます。
顧客名の表記揺れや重複・終了案件、古い住所、日付形式、添付ファイルの対応関係を洗い出します。
移行対象と保管のみの対象を分けたうえで、件数や誤りの修正方法、照合期間、CSVなどによる全データの持ち出しを、契約前に決めておきます。

費用相場と2年間の総額の試算

費用は、標準機能を使うか、業務に合わせて作るかによって変わります。

行政書士向けに限った公的な市場統計は、確認できません。

次の金額は、公開料金と類似業務システムの開発費をもとにした目安です。利用人数や移行、帳票数、連携数、保守範囲によって変わります。

▶ 詳細はこちら：行政書士事務所向け案件管理システム開発の見積相場や費用/コスト/値段について

方式別の初期費用・月額・開発期間

方式別の費用と期間は、あくまで目安です。要件定義を省いた安価な見積もりには、特に注意が必要です。

クラウドSaaS：初期費用は0〜10万円、月額は1人あたり3,000〜10,000円で、導入は数日から1か月です。
パッケージ：費用は5万〜100万円で、保守や法改正対応は別途です。導入には2週間〜2か月かかります。
ローコード：費用は50万〜300万円程度で、期間は1〜4か月程度を見込みます。
個別開発：費用は300万〜1,500万円程度です。大規模な基盤では、1,500万円を超える場合もあります。

公開料金を使った2年間の試算

ここでは、公開料金を市場平均ではなく一つの価格例として使い、2年間の総額を試算します。

この料金例は、初期費用30,000円です。利用者が6名以上の場合は1人月額2,980円、1〜5名の場合は4,980円（税込）です（出典：行政書士向けクラウドサービス公式料金ページ、2026年8月確認）。

1人事務所：30,000円＋4,980円×24か月で149,520円です。
5人事務所：30,000円＋4,980円×5人×24か月で627,600円です。
6人事務所：30,000円＋2,980円×6人×24か月で459,120円です。

移行や初期設定、研修、帳票調整、解約時の返却費は、別途かかる場合もあります。

比べるときは、初期費用と24か月分で揃えて見ます。

個別開発で膨らみやすい費用

工程ごとに費用を分けて見ると、見積もりの抜けに気づけます。

要件定義：50万〜150万円です。
画面・DB設計：50万〜200万円です。
製造・テスト：300万〜900万円です。
移行・教育・導入：50万〜250万円程度です。

台帳、期限、帳票だけであれば、300万〜700万円に収まる可能性があります。一方で、電子申請や会計、ポータル、文書管理、監査ログ、AI支援まで一体化すると、1,000万円を超えやすくなります。

全機能を初期に入れない方法は、有効な選択肢です。ただし、権限やデータ構造、持ち出し、バックアップ、ログは、初期設計に含めておく必要があります。機能と将来の変更余地を分けて優先順位を付け、その内容を見積書に記載してもらいます。

ポイント

判断の目安は、利用人数や移行、帳票数、連携数、保守範囲をそろえて見積もりを比べることです。初期費用に加えて2年間の総額で比べると、差が見えてきます。

開発会社/ベンダーの選び方

開発会社を見る際は、知名度や機能数だけでなく、行政書士業務への理解、導入後の支援、データ持ち出しの可否を確かめます。完成品か個別開発かによって、比較の対象や契約上の注意点も異なります。

行政書士業務への理解と実績

自事務所の主要業務に近い画面や導入事例があるかを見ます。対象は、建設業許可、産廃、宅建業、在留資格、会社設立、相続などです。

見るべき点は、機能名の有無ではなく、実務上の操作に対応できるかです。

更新通知：更新前に複数回の通知を設定できるか。
書類不足：担当者へ差し戻せるか。
補正履歴：補正の履歴を残せるか。
書類区分：預かり書類と成果物を分けて管理できるか。

公開事例がない場合は、守秘義務に配慮した匿名の事例を求め、課題や対応範囲、導入後の運用について聞きます。

実案件を使ったデモと受入条件

無料デモや提案会では、一般的なサンプルではなく、匿名化した実案件を使ってもらいます。

相談から受任、本人確認書類回収、申請書作成、補正、許可までを一つの流れとし、請求、入金、次回更新まで操作します。
担当者の確認画面を使い、スマートフォンでの利用や検索速度、添付の閲覧、通知を、スタッフにも確かめてもらいます。
要件定義書や画面・データ設計書、テスト仕様書、操作手順書、復旧手順がそろうかを確かめます。ソースコードや設定情報の扱いも、あわせて見ます。
追加開発の単価や法改正対応、障害時の連絡、終了時の返却・削除、再委託先の管理を、見積書と契約書に記載してもらいます。

同じ質問票による複数候補の比較

候補には同じ質問票を渡し、次の観点で比べます。

業務適合：事件簿項目の検証方法と業務別の期限ルール。
情報管理：機微なファイル、CSV全件返却、AI入力情報の学習利用。
支援体制：移行支援、研修、法改正対応、障害復旧目標。
回答形式：各候補の回答を、同じ比較表にまとめます。

比較表には、初期費用と月額、2年総額を書きます。移行・保守費、期間、改修可否、人数も記載します。権限や監査ログ、バックアップ、データ出力、サポート時間もそろえておくと、比べやすくなります。

機能数よりも、入力が続けられるか、期限と書類がつながっているか、担当者が変わっても業務が止まらないかで評価します。

▶ 詳細はこちら：行政書士事務所向け案件管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：行政書士事務所向け案件管理システム開発の発注/外注/依頼/委託方法について

ポイント

行政書士業務への理解や導入後の支援、データ持ち出しを、同じ質問票で比べて選ぶのが目安です。自事務所の実案件を使ったデモで、必須業務を通せるかも判断の材料になります。

セキュリティ・個人情報・生成AIの安全な扱い

保管時と復旧時の両方を運用に含めます。

本人確認書類や戸籍、登記事項証明書、在留・財産・相続の情報は、漏えいしたときの影響が大きい情報です。設置の形態にかかわらず、まず権限や認証、暗号化を確かめます。さらに、操作ログやバックアップ、復旧、委託先の管理、職員教育も見ておきます。

権限・バックアップ・ログの運用設計

管理者、所長、担当者、事務補助者、閲覧のみの区分ごとに、閲覧と操作の範囲を分けます。退職者は即時に停止できるか、重要ファイルのダウンロードや削除は記録されるか、二段階認証は使えるかも確かめます。

バックアップの世代数や別環境への保管、復旧テストの時期、想定復旧時間も決めておきます。

漏えい時の連絡と判断の手順

個人情報保護委員会は、要配慮個人情報、財産的被害のおそれ、不正アクセス、本人が1,000人を超える漏えい等を、報告が必要な場合として示しています（出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」、2026年8月確認）。対象の情報によって判断は変わります。そのため、提供者からの連絡期限や責任者、事実確認、影響範囲、本人通知や関係機関への報告を含めた手順を整えておきます。

生成AIの補助利用と最終判断

生成AIは、書類の不足候補の洗い出しや面談メモの要約、期限候補の抽出など、確認作業の補助に使えます。

個人情報を入力する場合は、学習への利用の有無や保存期間、第三者提供、削除の方法、アクセス権を確かめます。必要に応じて匿名化もします。

生成AIの出力は、申請書や法的判断にそのまま使わず、行政書士が原資料と照合する運用を規程に定めます。

ポイント

扱う情報の重さに応じて、権限や認証、ログ、バックアップ、委託先の管理を一体で決められているかが、判断の目安です。漏えい時の連絡手順まで決めてあるかも、判断の材料になります。

導入後の定着と効果測定

導入の失敗は、機能の不足だけでなく、入力ルールの未整備や二重入力、一部の人が使わないこと、例外案件の別管理でも起こります。

リリースの時点で完璧を目指すより、入力する情報を絞って毎日の業務に組み込むほうが、定着につながります。

入力責任者と例外処理

入力ルールと例外への対応は、担当者と判断者を決めて運用します。

責任者：登録者、顧客情報の変更承認者、書類を受け取ったときに更新する項目、補正時の状態を決めます。
入力基準：選択肢や必須項目、命名規則、期限の基準日をそろえ、標準化しておきます。
例外対応：急ぎの案件や委任範囲の変更、複数申請の並行などについて、種類と判断者を記録します。

例外の扱いは、月1回見直します。迷ったときは、実案件の登録例と相談先をまとめた短い手順書が役立ちます。

期限・書類・時間のKPI

導入前の1か月を基準に、業務時間や処理状況の変化を追っていきます。

案件と書類：完了日数、期限超過、補正回数、書類不備率。
作業時間：二重入力、不在時の引き継ぎ、月次請求作成にかかる時間。
変化の記録：期限超過が月8件から月2件、請求作成が週6時間から週3時間など。

改善が見られない場合は、入力項目や通知の多さ、例外の別管理を確かめます。月次の運用会議で候補を1〜2件に絞ります。

設定の変更、研修、業務ルールの変更のうち、どれで解決するかを決めておくと、現場に負担をかけずに運用を育てられます。

よくある質問（FAQ）

導入前によく寄せられる疑問に、順に答えます。最適な方法は、事務所の業務種別や扱う情報、人数、既存データによって変わるため、自社の条件に置き換えて検討してください。

1人事務所でも案件管理システムは必要ですか？

必要性はあります。ただし、最初から個別開発する必要はありません。期限や書類、顧客情報、請求をまとめ、外出先から確認できるクラウド型であれば、負担を抑えやすくなります。

案件数や業務種別が増え、標準機能で例外を管理できなくなった時点で、ローコードや個別開発を検討します。

クラウドに個人情報を保存しても大丈夫ですか？

クラウドが危険で、自社のPCなら安全だとは、一概には言えません。二段階認証や権限の分離、暗号化、監査ログ、バックアップ、復旧テストを確かめます。

委託先の管理や漏えい時の連絡体制、事務所側のパスワード管理、職員教育も整えておきます。

マイナンバーや要配慮個人情報を扱う場合は、保存する範囲とアクセスする人を必要最小限にします。契約や社内規程とも照らし合わせます。

過去のExcelや紙の台帳は移行できますか？

移行できるかどうかは、ファイル形式や項目の対応、重複、添付ファイルの量で決まります。移行は、現行案件や更新の予定がある顧客、期限が残る許認可などから始めます。

終了した案件は、検索できる形に整えて保管する方法もあります。移行の前後で件数を照合し、サンプルを確認するとともに、修正の担当者と原本の保存期間を決めます。

既製品と個別開発はどちらを選ぶべきですか？

案件管理や期限通知、書類管理、請求、事件簿といった標準的な機能で足りるなら、既製品やクラウド型を先に比べます。

業務種別が多く、独自帳票や会計・電子申請との連携、拠点をまたぐ権限が必要な場合は、ローコードや個別開発が候補になります。

どちらの場合も、実案件のデモで必須の業務を通せるかを確かめます。そのうえで、データの持ち出しや2年間の総額、導入後の負担を見て決めます。

まとめ

このガイドで押さえる要点

案件管理システムは、顧客や書類、期限などの情報を、申請から入金、事件簿までを含む一つの業務データとして扱います。

方式は、クラウドSaaS、パッケージ、ローコード、スクラッチの中から、事務所の規模と業務の複雑さに応じて選びます。

最初に取り組むべきこと

大切なのは、高機能な製品を選ぶことだけではありません。日々の入力が続き、期限と書類がつながり、引き継ぎやデータの持ち出しができる仕組みを選ぶことです。

現行業務を洗い出し、期限漏れや書類不備、二重入力、請求作成などの課題を数字で捉えます。
3〜5件の実案件デモ、2年間の総額、移行と保守、セキュリティ、生成AIの扱いを、同じ基準で比べます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。