総務省の自治体デジタル・トランスフォーメーション（DX）推進計画【第4.0版】（2025年3月28日）は、7つある重点取組事項の筆頭に「自治体フロントヤード改革の推進」を置いています。フロントヤードとは住民との接点を指し、同計画はこれを「オンライン申請、『書かないワンストップ窓口』等、住民との接点の多様化・充実化やデータ対応の徹底など」と定義しています。

同じ計画は、現状についてこう記しています。「これまで自治体における窓口業務改革は、個別ツールの導入等にとどまり、業務フローの見直し（BPR）、全体最適化、住民との接点の多様化やデータ対応の徹底が不十分であるケースがある」。ツールは入ったが、データとしての対応が足りていないという認識です。目標として、フロントヤード改革に取り組んでいる自治体数を2026年度末で300自治体とすることが掲げられています。

この課題は自治体に限りません。公益法人、外郭団体、業界団体、NPOといった組織でも、問い合わせ対応と情報発信が少人数に集中し、記録が残らないまま回っている状況をよく目にします。この記事では、公共性の高い組織がHubSpotで何をどう設計すべきかを、一般財団法人日本自動車研究所と特定非営利活動法人ピースウィンズ・ジャパンの事例とあわせて整理します。

なぜ公共・非営利のサイト運用は、少数の担当者に集中するのか？

自治体、公益法人、業界団体、NPO。組織の形は違っても、ウェブサイトの運用が1〜2名に集中している点は共通しています。そしてその担当者は、サイト運用だけを担当しているわけではありません。問い合わせ対応、セミナー運営、資料作成を兼ねているのが通常です。

この状況で更新頻度が落ちるのは、担当者の意欲の問題ではありません。更新の手間が構造的に大きいことが原因です。

もう一つの要因は、公開前の確認工程です。公共性の高い組織では、掲載内容について上長や関係部署の確認を経る必要があります。確認の往復がメールと添付ファイルで行われていると、1本の記事を公開するまでに数週間かかります。この工程を短縮せずにCMSだけを新しくしても、更新頻度は変わりません。私たちが支援に入る際は、編集機能の改善とあわせて、確認を誰がどの順で行うかの整理も同時に進めています。

HTMLを書かないと編集できない仕組みが、担当者を固定する

従来型のCMSでは、文字の差し替え程度しかできず、レイアウトを変えるにはHTMLの知識が必要になることがあります。この状態では、編集できる人が限られます。限られた人に作業が集中し、その人が忙しくなると更新が止まります。更新作業を仕組みで減らす考え方はHubSpotワークフローとはも参考になります。

解決策は、編集できる人を増やすことです。そのためには、コーディングなしで編集できるテンプレートとモジュールを用意する必要があります。研修で人を育てるより、仕組みの側で必要な知識を下げるほうが確実です。

更新が止まると、情報発信の優先度がさらに下がる

数か月に1回しか更新しないサイトは、見られません。見られないサイトは、更新する意味が感じられなくなります。この循環に入ると、サイトは存在するだけの状態になります。

逆に、更新が容易になると発信の頻度が上がり、流入が増え、発信の意味が実感できるようになります。後述する日本自動車研究所の事例では、CMSの移行後にオーガニック流入が2倍以上に増え、それまで数か月に1回だった更新を月1回に引き上げる方針に変わりました。

「自治体フロントヤード改革」は、住民接点に何を求めているのか？

自治体DX推進計画【第4.0版】は、重点取組事項の第1項目にフロントヤード改革を置いています。注目すべきは、この改革が窓口のデジタル化だけを指していない点です。計画の注記では「住民との接点の多様化・充実化やデータ対応の徹底など」と定義されています。

同計画は、これまでの窓口業務改革について「個別ツールの導入等にとどまり、業務フローの見直し（BPR）、全体最適化、住民との接点の多様化やデータ対応の徹底が不十分であるケースがある」と指摘しています。ツールを入れたことと、データとして扱えるようになったことは別だという認識です。

オンライン申請を入れても、住民の情報は残らない

オンライン申請システムを導入すると、申請の処理は効率化されます。しかし、申請の前後にある問い合わせや相談は、システムの外にあります。電話で受けた質問、窓口で聞かれた内容は、担当者のメモに残るだけです。

住民との接点を多様化するという方針を実現するなら、申請という手続きの外側にある接点を記録する仕組みが必要になります。これは、民間企業におけるCRMと同じ構造の課題です。部門間で情報が分断される構造については組織のサイロ化を解消するデータ設計で扱っています。

計画の対象期間は2026年3月まで

第4.0版の対象期間は2021年1月から2026年3月までとされています。本記事の執筆時点（2026年10月）ではこの期間を過ぎており、令和8年度以降の取扱いについては総務省で検討が進められています。最新の方針は総務省・自治体DXの推進のページで確認してください。

ただし、計画期間が終わっても課題が消えるわけではありません。接点のデータ化という論点は、計画の有無にかかわらず残ります。

問い合わせの記録は、何から始めるのか？

公共性の高い組織では、同じ質問が繰り返し寄せられます。手続きの方法、必要書類、受付期間。これらに毎回個別に回答していると、担当者の時間が消えていきます。

最初に手を付けるべきは、問い合わせの分類です。過去3か月分の問い合わせを分類するだけで、上位5つの質問が全体の何割を占めるかが見えます。多くの組織で、上位の数項目が半分以上を占めます。

チケットとして記録し、分類を集計する

HubSpotでは問い合わせをチケットとして記録できます。問い合わせ区分をプロパティとして持たせれば、カスタムレポートビルダーで区分別の件数と対応時間を集計できます。

この集計が出ると、どの情報をサイトに載せるべきかが決まります。問い合わせが多い項目ほど、情報が足りていない項目です。勘で記事を書くより、問い合わせの実績から決めるほうが確実です。

上位の質問については、回答をサイトに掲載したうえで、問い合わせへの返信でもそのページを案内する運用にしてください。同じ内容を毎回書くことがなくなり、掲載したページが読まれているかもデータで確認できます。対応の状況を関係者で共有する場合は、ダッシュボードに区分別の件数を並べておくと、会議のたびに集計する作業がなくなります。

記録の負荷を、最初から下げておく

すべての問い合わせを詳細に記録しようとすると、記録自体が負担になり続きません。最初は、区分と件数だけで十分です。内容の詳細は、後から必要になった項目だけ追加してください。

メールで届く問い合わせは、受信トレイ連携で自動的に記録できます。電話の問い合わせは手入力になりますが、区分の選択だけなら数秒で済みます。

対応が複数日にまたがる案件では、次に何をすべきかをタスクとして残してください。担当者が不在の日に別の職員が引き継ぐ場面で、記録の有無が対応の質を分けます。公共性の高い組織では、同じ相手に別の職員が異なる説明をすることが信頼の問題に直結します。

会員・寄付者・利用者を持つ団体は、何を設計すべきか？

業界団体、公益法人、NPOには、会員や寄付者という継続的な関係を持つ相手がいます。この関係の管理は、一般企業の顧客管理と似ていますが、いくつか違いがあります。

最も大きな違いは、金銭のやり取りが関係の中心ではないことです。会費を払っているから会員なのではなく、理念に共感しているから会員でいる。この前提に立つと、必要なのは請求管理ではなく、活動の成果をどう伝えるかという設計になります。

支援・参加の履歴を、金額以外も含めて持つ

寄付額だけを記録していると、金額の大小でしか関係を測れなくなります。イベントへの参加、ボランティアとしての活動、情報の拡散。こうした関わり方も、重要な関係の指標です。

HubSpotでは、これらをプロパティや関連付けとして記録できます。金額だけでない関わりが見えると、感謝の伝え方も変わります。

関係の段階はライフサイクルステージとして定義しておくと、組織内で同じ言葉で話せるようになります。「関心を持った人」「一度参加した人」「継続して支援している人」を区別できれば、送る情報も変えられます。全員に同じ案内を送ると、継続支援者にとっては既知の内容が繰り返し届くことになります。

閲覧だけの職員に、ライセンス費用をかけない

非営利組織では、予算の制約が民間企業より厳しいことが通常です。全職員に編集権限のライセンスを配ると費用が膨らみます。HubSpotでは、閲覧のみの利用について追加費用がかからない設定があります。ピースウィンズ・ジャパンの事例でも、この点が導入の決め手のひとつになっています（同団体が確認した時点の条件です。費用体系は改定されることがあるため、契約前に最新の情報をご確認ください）。

編集する人を限定し、情報を見る人を広げる。この構成なら、費用を抑えながら組織内での情報共有は進みます。

セキュリティ要件と、SaaSの利用はどう両立するのか？

公共性の高い組織ほど、セキュリティに関する説明責任が重くなります。そしてこの責任感が、かえって古いシステムを使い続ける理由になることがあります。「現行のシステムで動いているものを変えるリスク」を重く見るためです。

しかし、自前で運用しているCMSには、脆弱性が見つかったときに誰がどう対処するかという問題が常にあります。対処方針が明確でなければ、脆弱性を抱えたまま運用せざるを得ない期間が生じます。

対策の責任を、どこに置くかという選択

SaaSを利用するという判断は、セキュリティ対策の実施主体を提供事業者に移すという選択でもあります。サーバーやソフトウェアのインストールが不要になり、バージョンの更新も提供側で行われます。

日本自動車研究所JNXセンターの事例では、以前使用していたCMSについて「脆弱性が見つかった場合の対処方針が明確でなく、状況次第では脆弱性を内在した状態で運用せざるを得なかった」という課題がありました。サプライチェーンの参加者にセキュリティの重要性を伝える立場として、この状態での運用継続は望ましくないという判断から、CMSの移行が始まっています。

アクセス権限は、移行と同時に設計する

SaaSに移行したからといって、誰でも自由にアクセスしてよいわけではありません。データの管理についてはセキュリティを重視し、権限の振り分けを行う必要があります。HubSpotではユーザー権限とチームで、閲覧・編集できる範囲を分けられます。

組織の情報セキュリティポリシーとの整合は、導入前に確認してください。外部のクラウドサービス利用に関する規程がある場合、審査に必要な資料を事前に揃えておくと検討が滞りません。HubSpotのセキュリティに関する情報は公式のセキュリティページで公開されています。

公共・非営利領域のHubSpot活用事例

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、公益法人やNPOの支援も行っています。以下は公開許諾をいただいた2組織の事例です。いずれも営利企業ではなく、少人数の体制で運用している点が共通しています。

2組織が選んだ構成は対照的です。一方はウェブサイトの基盤そのものを移行し、もう一方は既存の基幹システムを残したまま接点側だけを足しました。

JNXセンター（日本自動車研究所）：セキュリティを理由にしたCMS移行

一般財団法人日本自動車研究所（JARI）は、自動車に関する総合的な研究を行う公益法人の試験研究機関です。2000年10月より、自動車業界向けの電子商取引基盤「JNX事業」を展開しており、2025年3月時点で2,300社以上の企業にサービスを提供しています。

同事業を運営するJNXセンターでは、ウェブサイトの運用を2名が担当していました。当時のCMSはHTMLの知識がないと自由に編集できず、テキストの差し替えや文字サイズの調整程度しか対応できない状態でした。更新の手間が負担となり、数か月に1回まとめて更新する流れになっていました。

移行の決め手となったのはセキュリティです。旧CMSは脆弱性が見つかった場合の対処方針が明確でなく、サプライチェーンの参加者にセキュリティの重要性を伝える立場として望ましくないという判断がありました。SaaS型のCMSであれば、サーバーやソフトウェアのインストールが不要で、セキュリティ対策も提供側で実施されます。

リニューアル後、ウェブサイトへのアクセスが増加し、特にオーガニック流入は2倍以上に増えました。汎用的なテンプレートとモジュールを用意したことで、コーディングなしで誰でも編集できる環境が整い、更新頻度を月1回へ引き上げる方針に変わっています（日本自動車研究所の事例）。

ピースウィンズ・ジャパン：基幹は残し、接点だけを足す

特定非営利活動法人ピースウィンズ・ジャパンは、世界各地の人道危機に対して活動を展開する国際NGOです。災害や紛争、貧困といった社会課題の解決に取り組んでいます。

同法人の課題は、CRMにSalesforce、MAにHubSpotという構成で、仕様の違いを踏まえた設計が難しかったことです。加えて、コーディングなどの技術領域を担う人材が2名しかおらず、「私がいないとマーケティング施策を実行できない」という属人化が生じていました。

ツール選定では複数の製品を比較しています。既存のSalesforceとの親和性を考えれば同社のMAが有力でしたが、専門知識のないメンバーでも使えなければ属人化は解消しないという判断から、社内用の活用マニュアルを作れるかどうかをトライアルで検証しました。結果として、HubSpotが選ばれています。

基幹システムや決済システムの移行は困難だったため、既存のシステムを残したままHubSpotを連携させる構成に落ち着きました。この取り組みにより、コンタクト数6万件増と業務効率化を実現しています（ピースウィンズ・ジャパンの事例）。

全面移行を前提にすると、基幹システムの制約で検討が止まります。接点側だけを切り出して載せる構成は、現実的な選択肢になります。

既存の基幹システムとは、どう連携させるのか？

公共・非営利の組織には、長年使っている基幹システムがあります。会計、会員管理、申請処理。これらを移行するのは、予算の面でも手続きの面でも容易ではありません。

どの情報をどこが正とするかの整理はSSOT（信頼できる唯一の情報源）で扱っています。前提として、全面移行は目指さないでください。基幹システムは残し、接点側（問い合わせ、情報発信、イベント運営）だけをCRMに載せる構成で、実務上の効果は得られます。

どの情報をどちら向きに流すかを決める

連携の設計で最初に決めるのは、各項目の正をどちらに置くかです。会員の在籍状況や会費の納入実績は基幹システムが正、問い合わせ履歴やイベント参加はCRMが正。この線引きを明確にし、双方向に書き込む項目を作らないことが、同期の衝突を防ぐ唯一の方法です。

既製の連携が使えるかは、先にアプリ連携を確認してください。対応がない場合はプライベートアプリ経由のAPI連携になります。取り込んだデータの重複は重複レコードの管理で統合し、全体の状態はデータ品質コマンドセンターで点検します。

連携を後回しにして、先に運用を始める

システム連携の設計には時間がかかります。連携が完成してから運用を始めようとすると、半年以上何も変わりません。初期は手作業での取り込みで構いません。インポートを月1回実行する運用でも、記録が残り始めます。

自動化すべきかどうかは、手作業の頻度と件数で判断してください。月1回のインポートで足りるなら、自動化の投資は不要です。

最初の90日は、どこから着手すべきか？

公共・非営利の組織では、予算の確保と内部の承認に時間がかかります。この前提を踏まえると、最初から大きな構想を立てるより、現在の予算の範囲で始められる領域を選ぶほうが現実的です。

着手の候補として勧めているのは、ウェブサイトの更新体制か、問い合わせの記録のどちらかです。いずれも既存の業務を置き換えるのではなく、今ある負荷を下げる方向の取り組みであるため、組織内の合意を得やすくなります。

最初の30日：現状の負荷を数字にする

サイト更新に月何時間かかっているか、問い合わせが月何件あり、そのうち何割が同じ質問か。この数字を出すことから始めてください。公共組織では、投資の必要性を説明する際にこの種の実績値が求められます。

数字がないまま「効率化のために導入したい」と提案しても、承認は通りません。現状の負荷を測ることが、最初の作業になります。

測り方は厳密でなくて構いません。1週間、担当者が作業時間を記録するだけでも、月あたりの概算は出せます。問い合わせ件数は、過去のメールと電話の記録から数えられます。正確さより、根拠のある数字が存在することのほうが、説明の場面では効きます。

31〜90日：小さく始めて実績を作る

2か月目に、限定した範囲で運用を始めます。サイトの一部のページだけ、あるいは特定の種類の問い合わせだけ。全体を一度に変えようとせず、効果を測れる範囲に絞ってください。

3か月目に、最初に測った数字と比較します。更新にかかる時間が減ったか、同じ質問への対応が減ったか。この比較ができる状態を作っておくと、次年度の予算要求で使える材料になります。

よくある質問

Q1. 自治体の情報セキュリティポリシー上、外部クラウドの利用に制約があります。導入は可能ですか？

自治体の情報セキュリティポリシーは団体ごとに定められており、扱う情報の区分によって利用できるサービスの条件が異なります。住民の個人情報を扱う業務系と、情報発信や問い合わせ対応の領域では、要求される水準が異なることが通常です。まずは自組織のポリシーで、どの区分の情報であれば外部サービスを利用できるかを確認してください。判断は情報セキュリティ担当部門が行う必要があります。

Q2. 予算の確保に1年かかります。それでも検討する意味はありますか？

あります。むしろ、予算要求に必要な材料を集める期間として使ってください。現状の作業時間、問い合わせ件数、サイトの更新頻度。これらの実績値がないと、要求の根拠が作れません。検討期間中にこの測定を済ませておけば、予算が付いた時点ですぐ着手できます。

Q3. 職員の異動が頻繁にあります。運用が引き継げるか不安です。

引き継ぎを前提とした設計にしてください。具体的には、特定の職員しか編集できない状態を作らないこと、設定の変更履歴が残ること、操作手順が文書化されていることの3点です。ピースウィンズ・ジャパンの事例では、ツール選定の段階で「社内用の活用マニュアルを作れるかどうか」をトライアルで検証しています。この観点は、異動の多い組織ほど重要になります。

Q4. 住民や会員の個人情報をクラウドに置くことに抵抗があります。

すべての情報を載せる必要はありません。問い合わせの区分と対応状況だけを記録し、個人を特定する情報は最小限にとどめる運用も可能です。どこまで載せるかは、組織の規程と扱う情報の性質で判断してください。載せる範囲を絞ることで、審査のハードルも下がります。

Q5. 業界団体ですが、会員企業向けの情報提供に使えますか？

使えます。会員限定の情報を提供する場合、会員登録を必須とする非公開コンテンツの機能で、登録者だけが閲覧できるページを作れます。会員企業の担当者がどの情報を見ているかも記録されるため、次に提供すべき情報の判断材料になります。

Q6. 調達手続き上、特定製品を指定した仕様書は作れません。

多くの組織で同じ制約があります。実務的には、必要な機能要件を列挙した仕様書を作成する形になります。この場合、要件の書き方が重要です。「CMS機能を有すること」だけでは、現在と同じ課題を抱えた製品が選ばれる可能性があります。「HTMLの知識なしに編集できること」「脆弱性対応が提供事業者により実施されること」といった、課題から導いた要件にしてください。

Q7. NPOですが、費用を抑えて始める方法はありますか？

利用する機能を絞ることで、初期の費用は抑えられます。閲覧のみの利用者には追加費用がかからない設定もあります。ただし、条件は改定されることがあるため、契約前に最新の料金情報を確認してください。また、非営利団体向けの条件が設定されている製品もあるため、問い合わせの段階で確認することを勧めます。

Q8. 導入の効果を、議会や理事会にどう説明すればよいですか？

作業時間の削減と、接点の増加の2軸で説明するのが実務的です。前者は職員の工数として数字にでき、後者はアクセス数や問い合わせ対応件数として示せます。日本自動車研究所の事例では、オーガニック流入が2倍以上に増えたという結果が出ています。導入前の数字を測っておくことが、説明の前提になります。

自治体DX推進計画が指摘する「データ対応の徹底が不十分」という状況は、自治体に限らず公共性の高い組織に共通します。問い合わせは受けているが記録されていない、サイトはあるが更新できる人が限られている。この状態を変えるのに、組織の全面的なシステム刷新は必要ありません。接点の部分だけを切り出し、記録が残る状態にすることから始められます。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、公益法人・業界団体・NPOのウェブサイト基盤と顧客データ設計を支援しています。セキュリティ要件の整理や調達手続きを前提とした進め方を含めて、お問い合わせフォームからご相談ください。

最終更新日: 2026年10月23日（掲載している計画・統計・製品仕様は同日時点のものです。自治体DX推進計画の令和8年度以降の取扱いは総務省で検討が進められています。HubSpotの料金体系・機能・エディション要件は変更される可能性があるため、導入前に最新の公式情報をご確認ください）