自治体告知文作成支援の事例で詰まる論点と進め方の実務ポイント
「来月の住民向けお知らせ、生成AIで下書きを作ってもらえないかと広報から相談が来たのですが、情シスとしてどう答えるべきでしょうか」——情報システム担当者に、広報課の職員から金曜夕方にこう電話が入る場面から話を始めます。電話の向こうでは、先週の告知文で窓口に問い合わせが続いたこと、来月分の掲載予定が二日に詰まっていること、制度改定のタイミングと重なって記述のリスクが読めないこと、という三つの事情が同時に動いています。生成AIで下書きさえ作れれば間に合うはずだ、という現場の期待と、個人情報や制度記載の誤りを出してはいけないという緊張感が、稟議前の論点整理を後回しにしたまま積み重なっていきます。自治体告知文作成支援の事例を情報システムの立場で読み直すと、ツール選定の前に、稟議に何を載せ、どの運用ルールで現場に返すかの組み立てに再現条件があることが見えてきます。本稿では抽象論で終わらせず、情報システム担当の視点で詰まりやすい論点と進め方の段取りを整理します。
つまずく課題の正体を言い換える
自治体告知文作成支援でつまずく場面は、「AIの出力品質が低い」という表現にまとめられがちですが、実際の現場で起きているのは少し別の話です。情報システム担当として事例を読み返すと、課題は大きく三層に分かれて現れます。
一層目は、情報の正確性に関する責任の所在が曖昧なことです。告知文には制度改定の日付、窓口の受付時間、対象者の範囲、提出書類の種類といった事実情報が並びます。生成AIの下書きに誤りが混ざっていた場合、誰がどの工程で正誤確認を担うかを事前に決めておかないと、公開直前のレビューで指摘が集中し、発信時期に遅れが出ます。
二層目は、表現の中立性と読み手への配慮です。自治体の告知文は、住民の年代、国籍、制度理解度の幅が広く、言い回し一つで窓口への問い合わせが増減します。AIが出す下書きは一般論としては自然でも、自治体特有の配慮観点——要配慮者への案内文の柔らかさや、差別的に読まれ得る表現の回避——を網羅しきれないことがあります。
三層目は、個人情報と非公開情報の取り扱いです。下書きを作る段階で具体名や案件番号を入力してしまうと、利用規約や契約条件次第で情報の取り扱いが想定外に広がる可能性があります。情報システム担当としては、入力時点で除外すべき情報を文章で明文化しない限り、後段の対策は後手に回り続けます。
課題をAIの品質に還元して語るより、責任の所在、表現配慮、情報の取り扱いの三層で語るほうが、稟議や現場説明の場で論点の地図を描きやすくなります。
詰まりの原因を情報システムの視点で分解する
課題の三層が見えたら、次は原因を情報システムの視点から分解します。原因は、ツール側、プロセス側、人側の三方向から見ると全体像がつかみやすくなります。
ツール側の原因は、入力と出力の境界が曖昧なまま運用に入っている点です。どの項目なら下書きに入力してよいか、どの項目は入力前にマスクするかのルールが文章化されていないと、担当者個人の判断に依存した運用になります。さらに、生成AIの利用規約や契約条件が、行政情報の取り扱いに対してどう解釈されるかの確認が後回しになっていると、公開直前の差し止めにつながりかねません。
プロセス側の原因は、下書きレビューの工程設計が現場任せになっている点です。誰が一次レビューを担い、誰が最終承認を出し、公開前にどのチェックリストで確認するかが揃っていないと、忙しい時期ほど工程が飛ばされます。告知文は一度公開すると訂正告知の手間が重くなるため、公開前の関門を厚めに取るほうが、全体としては短時間で回ります。
人側の原因は、広報担当者と情報システム担当者の間で、AI活用に対する期待値が揃っていないことです。広報側は時間短縮を期待し、情報システム側は安全性を優先したい。期待値が揃わないまま運用が始まると、広報は「情シスが止める」と捉え、情シスは「広報が踏み込みすぎる」と捉える、という構図になりがちです。原因を個人の姿勢に帰すのではなく、期待値の擦り合わせ工程が存在しなかった、という構造として扱うと、改善の打ち手が見えやすくなります。
業務特性は異なりますが、関連する観点として バックオフィス領域の生成AI活用事例 を並べて読むと、文書作成系業務で共通して起きやすい詰まりの輪郭が確認できます。
稟議で通せる解決アプローチを組み立てる
情報システム担当として稟議に載せるときは、技術的な解決策だけでなく、責任分担と運用ルールをセットで提示することが現実的です。稟議で通すために揃えたい項目は四つあります。
一つめは、対象業務の範囲と除外範囲を明示することです。当面の対象を「制度改定を伴わない定例告知」「住民向けイベント告知」「募集要項の下書き」のように具体的に列挙し、生活保護や相談窓口など要配慮テーマは当面除外する、といった線引きを先に決めます。範囲を明示すると、後段の議論が「どのリスクをどう抑えるか」に集中できます。
二つめは、入力前の除外ルールです。個人名、住所、口座情報、非公開の案件番号、未公表の日程といった、下書き段階で入力しない項目を一覧化します。情報システム担当としては、この一覧を広報だけでなく他部署にも共有できる形で残しておくと、横展開時の再整備を短縮できます。
三つめは、レビュー工程と承認者の固定です。下書き、一次校正、情報正確性チェック、最終承認の四段階を基本とし、各段階の担当と期限を運用ルールに明記します。段階を減らすとスピードは上がりますが、訂正告知のリスクが跳ね返ってくるため、公開前の関門を厚めに取る判断が実務的です。
四つめは、利用ログと振り返りの運用です。月次で、下書き件数、訂正が発生した件数、レビューで差し戻された論点を集計し、運用ルールの更新に反映します。稟議では「導入して終わり」ではなく、「導入後に運用ルールを改善し続ける」ことを明記しておくと、継続予算の根拠が揃います。
稟議で聞かれやすいセキュリティ質問に短く答えられるよう、情シス側で先に押さえておきたい前提としては、導入前に確認したいセキュリティ前提の整理 の論点が参考になります。社内運用で見落としやすい注意点をあらかじめ共有しておくと、稟議当日の追加質問で時間を取られにくくなります。
組織規模ごとの稟議の厚みや合意形成の進め方については、中堅企業における生成AI活用事例 の整理が、自治体と規模感の近い組織の参考として読めます。規模が近い事例から入ると、提示する判断材料の粒度を合わせやすくなります。
実務で動かすときの段取り
稟議が通った後は、情報システム担当が旗振り役となって運用を立ち上げます。段取りは、試行、拡張、定着の三段階に分けて進めると、途中で評価軸を見失わずに済みます。
試行段階では、対象を最も影響の小さい定例告知から始めます。期間は四週間を目安にし、対象件数、所要時間、差し戻し回数、訂正発生の有無を記録します。試行では「うまくいった」「うまくいかなかった」の両方を書き残し、差し戻し理由や修正観点を次の段階の運用ルールに反映します。
拡張段階では、対象業務を一つずつ増やします。同時に二つ増やすと効果の因果が混ざり、後の判断材料がぼやけます。拡張の順番は、広報以外に産業振興、福祉、教育など、告知文の性格が似た部署から始めると、運用ルールの差し替えが最小限で済みます。
定着段階では、月次レビューと運用ルールの改訂サイクルを仕組み化します。情報システム担当としては、四半期に一度、利用規約の改定や制度変更の影響を運用ルールに反映する定例を設けると、ルールの陳腐化を防げます。運用ルールの置き場は一箇所に集約し、改訂履歴を残す形式にしておくと、人事異動や組織再編があっても判断軸が引き継がれやすくなります。
運用の立ち上げと同時に、稟議資料の書式を整えておくと、横展開や継続予算の相談がスムーズに進みます。費用対効果の説明順や整理項目の目安については、AI導入の稟議書はどう作るかの整理項目と書き方 が参考になり、自治体向けの追加観点を足し込む形で使いやすくなります。
業務構造が異なる参考材料として、製造業のAI活用事例の全体像 を並べて読むと、現場業務と本社業務の間で運用ルールの粒度がどう変わるかという対比が確認できます。自治体の場合、窓口対応と内部事務で情報の扱いが異なるため、現場に近いルールほど具体的に、本社側のルールほど原則を短く示すというメリハリが効いてきます。
失敗しやすい落とし穴を先に潰す
事例を読み込むと、失敗しやすい落とし穴も共通して浮かび上がります。稟議の前に潰しておきたいものを四つ挙げます。
ひとつは、下書きのまま公開してしまう事故です。AIの出力を編集せずに転記した結果、制度の日付や金額が誤っていた、という事例が観察されます。公開前の関門を厚くするルールを先に決めるだけで、事故の発生率は下がります。
ふたつめは、利用規約や契約条件の確認を後回しにすることです。告知文の下書きに含まれる情報が、第三者提供や学習データへの混入の対象になる契約か、事前に確認しないと、後から制限が追加されて運用が止まります。情報システム担当としては、契約確認の記録を稟議資料に添付しておくと、後任への引き継ぎがスムーズになります。
みっつめは、広報以外の部署が独自に利用を始めることです。統一ルールがないまま各課で個別導入が進むと、同じ自治体の中で告知文の品質にばらつきが生まれます。全庁の運用ルールを早めに立て、各課にテンプレートとレビュー工程を共有するのが、情報システム担当の役割として実務的です。
よっつめは、導入直後の成果だけで評価を閉じることです。初期は物珍しさで利用が伸びるものの、三か月後には活用が偏りがちになります。月次と四半期のレビューで、「利用が続いているか」「訂正や問い合わせの傾向が変化していないか」を追い続ける必要があります。
抽象論にまとめず、これらの落とし穴を稟議資料と運用ルールに明記しておくと、導入後の軌道修正がしやすくなります。
よくある質問
AIで下書きした告知文は職員が書いた文書と同じ扱いでよいですか
公文書としての扱いは、最終承認者が責任を持つ運用であれば問題は生じにくいと考えられます。ただし、AIが補助したことを内部で記録しておくと、後から訂正や問い合わせが入ったときに経緯を追いやすくなります。制度や監査要件の詳細は、所管の法務担当に事前確認が必要です。
個人情報や未公表情報はどこまで入力してよいですか
原則として、入力時点で除外するのが安全です。匿名化や仮置き情報に置き換えたうえで下書きを作り、必要な固有情報は人の手で後から差し込む運用にすると、情報漏えいリスクを抑えられます。利用するサービスの契約条件と、自治体の情報セキュリティポリシーの整合を先に確認しておく必要があります。
内製と外部支援のどちらで進めるべきですか
利用規約の解釈、運用ルールの設計、レビュー工程の立ち上げまでを自庁で整える体力があれば内製が選べます。運用ルールの設計段階で詰まる場合は、論点整理の初期から外部の壁打ち相手を入れたほうが、導入後の運用が安定しやすくなります。
導入判断の論点を整理したい方へ
自治体告知文作成支援の導入を検討する段階で、範囲の線引き、入力前の除外ルール、レビュー工程、利用規約の解釈、月次レビューの運用が整理しきれていない状況でも、論点の棚卸しから壁打ちとしてご一緒できます。稟議に使える粒度まで落とし込みたい、運用ルールのひな形を叩きたい、他部署展開の順番を整えたい、といった切り口でも、ご状況に応じてご相談いただけます。最初から完成形を狙うより、小さな対象で一サイクル回し、振り返りを次の運用改訂に反映する進め方が、結果として定着までの時間を短くしやすくなります。
まとめ
自治体告知文作成支援の事例から読み取れるのは、AI出力の品質そのものよりも、責任の所在、入力前の除外ルール、レビュー工程、運用ログの四点を情報システムの立場で組み立てる段取りが、再現性に効くという点です。広報と情シスの期待値を揃え、稟議で提示する判断材料の粒度を合わせ、月次と四半期でルールを改訂していく積み上げ型の運用が、訂正告知のリスクを抑えながら発信スピードを維持する近道になります。抽象論にまとめず、対象範囲、除外ルール、レビュー段階、振り返り運用を具体的な文章として残しておくと、人事異動があっても判断軸が引き継がれます。
