自治体向け試験手順書の書き方・作り方

行政AIヤマトにおいては「DX・情報」の「自治体システム書類作成」のボタンで、この仕様の通り、AI出力できます。

はじめに――試験手順書の結論

自治体向け試験手順書は、誰が実施しても同じ条件・同じ判定になる再現可能な検証台本です。ケース名と操作だけでなく、要件ID、前提条件、入力データ、操作、期待結果、合否基準、証跡、異常時処置、停止基準、データ復元を一体で記載します。結果を見てから期待値を変えられないよう、実施前にレビューと承認を行います。

自治体システムでは、表面的な画面動作だけでなく、住民の権利・給付・課税、個人情報、所属別権限、監査ログ、帳票、外部連携、障害時業務を確認します。自治体向け試験手順書の書き方では、正常系に加え、異常系、境界値、誤操作、権限外アクセス、重複処理、時刻・年度境界を具体的なケースに落とし込みます。

要点：「期待どおり」と書かず、画面表示、状態、件数、金額、ログ、通知、応答時間など、観測可能な期待値で合否を判定します。

想定読者

• 自治体の業務原課、情報政策部門、受入試験担当
• 受託者の試験実施者、確認者、試験管理者、開発担当
• セキュリティ、個人情報保護、データ移行、運用担当
• 外部接続先、共同利用団体、再委託先、監査担当

業務担当者が読める表現を基本にし、技術的な確認はログやDB、API結果として補います。略語、業務コード、状態値は用語集で定義します。操作担当と判定担当が異なる場合でも、同じ結果に到達できる粒度が必要です。

標準的な章立て

1. 文書情報、目的、対象、関連文書
2. 対象版、試験環境、構成、差異
3. 体制、役割、実施日時、連絡先
4. 共通前提、アカウント、ツール
5. 試験データ、個人情報、初期化
6. ケース一覧、要件トレーサビリティ
7. ケース別手順と期待結果
8. 証跡取得、命名、保管
9. 合否、欠陥登録、停止・再開基準
10. ロールバック、後処理、承認
11. 実績、差異、改訂履歴

1. 文書・版・対象を固定する

表紙に案件名、試験レベル、対象リリース、ビルド番号、環境、文書版、機密区分、作成・レビュー・承認者を記載します。試験中に対象版が変わった場合、どのケースを再実行するかを試験管理者が判断します。版の異なる結果を一つの合格率に混ぜません。

対象システム、自治体テナント、拠点、URL、アプリ版、DBスキーマ、外部接続先を識別します。URLやIPを記載する文書は公開範囲を制限します。本番と試験、自治体Aと自治体Bを画面色だけで区別せず、テナントID等を二者確認します。

関連する要件定義書、基本・詳細設計書、試験計画書、パラメータシート、業務マニュアルを版付きで参照します。期待値の根拠を追跡可能にし、複数文書で不一致があれば試験前に解消します。

2. ケース設計と識別

試験ケースIDは重複しない体系にします。業務・機能・レベルを識別できる例として、UAT-TAX-APPLY-001があります。IDは要件ID、欠陥ID、証跡ファイル名とひも付けます。

一つのケースは一つの主目的と判定を持たせます。長い業務シナリオは、途中状態を確認できるステップに分けます。ただし申請から決裁・通知までの一貫性を確かめるE2Eケースも別に用意します。

観点には、正常値、最小・最大・直前直後、必須・任意、不正形式、重複、同時更新、権限、状態遷移、取消・再申請、タイムアウトを含めます。自治体業務では年度末・年度初め、和暦、うるう日、転入転出、世帯変更、組織改編を検討します。

3. 前提条件の書き方

ケースごとに、利用者ロール、所属、データ状態、日時、前ケース依存、外部サービス状態を明記します。「ログイン済み」だけでは、誰がどの権限でログインしたか分かりません。

前提条件の例

対象版：release-2026.04.1 / build 1842
実施ロール：福祉担当（更新権限あり、他課閲覧権限なし）
試験データ：DATA-HH-014、4人世帯、申請状態「一時保存」
基準日時：2026-04-01 09:00 JST
外部連携：通知サービスのテスト環境は正常応答
初期状態確認：申請番号未採番、重複データ0件

前提を作るための操作も再現可能にします。前ケースの結果に依存させ過ぎると、一件の失敗で多数を実施できません。独立実施できるケースを優先し、連続シナリオは依存関係を明示します。

4. 試験データの作り方

データID、目的、入力値、期待値、生成方法、利用ケース、保管先、消去日を台帳化します。氏名や住所は明らかな架空値とし、偶然実在する情報と一致しにくい規則を使います。個人番号の形式を扱う場合も、実在番号や無断生成を避け、関係規程とテスト環境の制約に従います。

同値分割と境界値分析を使い、ゼロ、1、最大、最大+1、空白、NULL、全角・半角、外字、長音、サロゲートペアを確認します。日付では年度、月末、うるう日、和暦、タイムゾーン、夏時間が関係する外部連携を検討します。

本番個人情報を使う場合は例外として、承認番号、目的、最小範囲、抽出者、暗号化、授受、アクセス、マスキング、保管、消去を記載します。証跡への映込みを避けます。個人情報保護法、番号法、自治体の条例・規程、契約の最新版を担当部署と確認します。

5. 操作手順の書き方

一ステップに、操作と期待結果を対で記載します。画面操作は開始画面、メニュー、入力欄、値、ボタン、確認ダイアログを示します。APIはメソッド、テスト用エンドポイント、ヘッダー、入力、期待ステータス、レスポンススキーマを示します。秘密情報は本文に記載しません。

曖昧な「必要事項を入力」「正常に表示」を避けます。どの値を入力し、どの項目に何が表示され、データ状態やログがどう変わるかを明記します。操作順に番号を振り、期待結果にも同じ番号を付けます。

ケーステンプレート

6. 期待結果と合否

期待結果は、画面文言、状態コード、DB件数、金額、帳票、送信件数、監査ログ、応答時間等で定義します。計算結果は、対象システムとは独立した式や既承認の基準データから作ります。実結果を見て期待値を合わせることは禁止します。

複数の期待結果の一つでも必須項目が不一致なら不合格です。「概ね良好」ではなく、合格、不合格、実施不能、保留を区別します。実施不能は合格に数えず、原因、再実施条件、影響を記録します。

画面上正常でも、DB二重登録、外部送信失敗、監査ログ欠落があり得ます。重要ケースはUI、データ、連携、ログの複数層で確認します。ただし本番相当データベースへの直接照会は権限と負荷を管理します。

7. 自治体特有のケース

住民向けでは、オンライン申請の途中保存、本人確認、添付、決済、受付通知、取消、重複申請、期限切れを確認します。高齢者や障害者、外国人にも利用しやすい表示、キーボード操作、読み上げ、色だけに依存しない案内を確認します。

職員向けでは、所属・職位・兼務・代理・異動・退職に応じた最小権限を確認します。閲覧制限情報は検索結果、候補表示、CSV、帳票、ログ、URL直指定、APIのすべてで保護される必要があります。

帳票は、様式、改ページ、印字位置、外字、バーコード、PDFアクセシビリティ、プリンタ差を確認します。国・都道府県・金融機関等との連携では、文字コード、コード体系、再送、重複、順序逆転、タイムアウト、相手停止を試験します。

8. セキュリティ試験手順

認証ではロックアウト、多要素認証、パスワード再設定、セッション終了を確認します。認可ではロール、所属、テナント、直接URL/API、CSV出力を確認します。入力では不正形式や長大入力を安全な環境で試験します。

負荷試験や脆弱性試験は、許可された環境・時間・送信元で実施し、停止基準を定めます。外部サービスや本番へ無断でスキャンしません。発見した脆弱性と証跡は機密区分を上げ、必要最小限に共有します。

個人情報誤表示、他テナント参照、権限昇格を検知した場合は即時停止します。追加探索より証拠保全と影響限定を優先し、自治体のセキュリティ事故対応手順へ連携します。

9. 性能・障害・復旧手順

性能ケースには、同時利用者、シナリオ割合、データ量、ウォームアップ、測定時間、ネットワーク、期待値を記載します。平均だけでなくパーセンタイル、エラー率、資源使用率を測ります。個人情報を含むログを負荷ツールに残さないようにします。

障害試験は、プロセス停止、ノード障害、回線断、外部API遅延、ディスク逼迫等を承認済みの方法で再現します。停止操作自体が環境を壊さないことを検証し、ロールバック手順と監視連絡を用意します。

復旧試験では、バックアップ選択、復元、整合性、アプリ起動、業務確認までを行い、RTO・RPOを実測します。復元成功メッセージだけで合格にしません。障害注入は本番へ無承認で実施しないことが重要です。

10. 証跡の取得

証跡名は、ケースID、ステップ、日付、結果を含めます。画面、ログ、API結果、自動試験レポートの取得範囲を決め、改ざん防止された保管先に保存します。端末時刻とサーバー時刻、タイムゾーンを確認します。

スクリーンショットだけでは、操作対象や前後関係が分からないことがあります。対象版、URLの安全な範囲、ユーザーロール、時刻を記録します。個人情報、アクセストークン、Cookie、秘密鍵はマスキングします。マスキング前原本が必要なら、アクセスと保存期間を制限します。

実施者と確認者が結果へ電子署名または所定の承認を行います。証跡の欠落は再実施対象です。後日作った証跡を当日取得したものとして扱ってはいけません。

11. 欠陥登録と再試験

期待値と異なったら、ケースを不合格として欠陥IDを発行します。実結果、再現手順、環境、版、データID、証跡、住民・業務影響を記録します。個人情報を一般チケットに直接貼らず、制限保管した証跡を参照します。

修正後は同じケースを再実施し、変更影響範囲の回帰試験を行います。結果の上書きは禁止し、初回と再試験を別実績として残します。再現しない場合も欠陥を自動的に閉じず、ログ・頻度・監視を検討します。

12. 停止・再開・ロールバック

停止基準には、対象版相違、環境不安定、前提データ破損、重大欠陥、個人情報漏えいのおそれ、他システム影響、想定外高負荷、証跡取得不能を含めます。数値と判断者を可能な限り明記します。

停止時は追加操作を止め、時刻、ケース、ステップ、画面、ログを保全します。独断で再実行、再起動、データ修正をせず、試験管理者へ報告します。データ更新を伴う試験は、初期スナップショットや再作成手順でロールバックします。

再開には、原因と影響範囲の確認、環境復旧、代表ケース合格、管理者の承認が必要です。個人情報事故の疑いがある場合、通常の試験再開より事故対応を優先します。

13. 後処理と完了承認

ケース終了後に、作成データ、送信待ちキュー、メール、決済、ファイルを後処理します。次ケースへ影響しない初期状態を確認します。外部へ送信された試験通知の回収や宛先確認も必要です。

試験全体終了時は、試験アカウント・特権、FW例外、監視抑止、時刻変更、スタブ設定を解除します。個人情報を含む一時データと媒体を規程どおり消去し、必要なら消去証明を取得します。

最終的に、実施数、合格数、欠陥、未実施、残存リスク、証跡格納を集計し、自治体承認者が完了を判断します。合否に関わる手順変更は改訂履歴と承認を残します。

書き方のポイント

1. 操作と期待結果を同じ番号で対にする。
2. 「正常」を観測可能な値・状態に置き換える。
3. 要件、データ、証跡、欠陥へIDで追跡する。
4. 実在住民ではなく設計した架空データを使う。
5. UIだけでなくデータ、連携、ログを確認する。
6. 正常、異常、境界、権限、時間を網羅する。
7. ケースの独立性と初期化方法を確保する。
8. 停止・再開・ロールバックを具体化する。

重要事項

• 試験実施前に期待結果と合否基準を承認する。
• 対象版、環境、テナント、ロールを毎回確認する。
• 個人情報・秘密情報を入力や証跡へ不要に残さない。
• 個人情報誤表示や権限逸脱では即時停止する。
• 実施不能と合格を明確に区別する。
• 修正後は再試験と回帰試験を行う。
• 法令、標準、製品仕様は実施時点の最新版を確認する。

禁止事項

• 実結果に合わせた期待値の事後変更
• 未実施ケース、証跡不足ケースの合格扱い
• 本番個人情報の無承認コピー・持出し・期限超過保管
• 本番・外部システムへの無承認負荷試験や障害注入
• 他自治体・他所属の情報を必要以上に閲覧する試験
• エラー後の独断再実行、ログ上書き、証跡改変
• 共用IDで実施者を特定できない状態
• 秘密鍵、トークン、パスワードの手順書記載
• 停止基準に達した後の試験続行
• 古い仕様を最新版確認なしで期待値にすること

実務チェックリスト

作成・レビュー

• [ ] ケースIDと要件IDが対応
• [ ] 前提、入力、操作、期待結果が再現可能
• [ ] 正常・異常・境界・権限の観点がある
• [ ] 期待値の根拠が設計・要件にある
• [ ] 架空データと個人情報保護方法を確認
• [ ] 証跡の種類、命名、保管が明確
• [ ] 停止・再開・ロールバックを定義
• [ ] 自治体原課が業務期待値を確認

実施時

• [ ] 対象版・環境・ロールを記録
• [ ] 前提データの状態を確認
• [ ] 手順順序を守り実績を記録
• [ ] 各ステップの期待結果を確認
• [ ] 個人情報・秘密を証跡でマスキング
• [ ] 不一致を不合格として欠陥登録
• [ ] 想定外事象で停止し証拠保全
• [ ] 実施者・確認者・日時を記録

完了時

• [ ] 再試験と必要な回帰試験を実施
• [ ] 試験データと外部送信を後処理
• [ ] 暫定権限・設定・監視抑止を解除
• [ ] 証跡と欠陥のリンクを確認
• [ ] 未実施・保留・残存リスクを集計
• [ ] 個人情報を含む一時データを消去
• [ ] 自治体の完了承認を取得

テンプレート

# ○○試験手順書
文書番号／版／試験レベル／対象ビルド／承認
## 1. 目的・範囲・関連文書
## 2. 環境・体制・共通前提
## 3. データ・個人情報・初期化
## 4. ケース一覧・要件対応
## 5. ケース詳細
### ID／目的／前提／入力／操作／期待／証跡／後処理
## 6. 合否・欠陥・再試験
## 7. 停止・再開・ロールバック
## 8. 後処理・完了承認・改訂履歴

FAQ――自治体向け試験手順書の作り方

Q1. 一ケースに何ステップまで含めますか。

固定上限はありませんが、失敗箇所と判定を特定できる長さにします。長いE2Eシナリオは残しつつ、機能別ケースも用意します。

Q2. 「正常に処理されること」は期待結果になりますか。

不十分です。表示文言、状態、件数、金額、ログ、通知、応答時間を具体化します。第三者が同じ合否を判断できることが基準です。

Q3. ケース間でデータを使い回せますか。

可能ですが、依存と初期状態を明記します。失敗の連鎖や実施順制約を避けるため、重要ケースは独立データを推奨します。

Q4. 本番データは使えますか。

原則は合成・匿名化データです。例外利用には必要性、法的根拠、自治体承認、最小化、暗号化、アクセス、消去が必要です。

Q5. 画面キャプチャだけで証跡になりますか。

ケースによります。データ更新、外部連携、権限、監査ログは画面以外の証跡も必要です。対象版・時刻・ロールも記録します。

Q6. 不具合を見つけたら手順を続けますか。

停止基準に該当すれば直ちに止めます。該当しない場合も後続結果への影響を評価し、試験管理者が継続を判断します。

Q7. 自動試験の場合も手順書が必要ですか。

必要です。スクリプト版、入力、環境、期待値、実行方法、ログ、停止条件、再実行、結果確認を定義します。

Q8. 権限試験で他人のデータを使ってよいですか。

架空データを使います。やむを得ず本番相当情報を扱う場合は、承認された範囲で非表示を確認し、不要な閲覧や証跡化をしません。

Q9. 手順変更はその場で書き換えてよいですか。

試験管理者と必要な自治体承認を得て、変更理由、影響、版、再試験範囲を記録します。結果に合わせた期待値変更は禁止です。

Q10. AIで手順を作成できますか。

下書きや観点抽出には使えますが、個人情報・機密を未承認AIへ入力せず、要件・設計・公式仕様と照合します。生成された期待値を人が独立確認し、最新版の法令・仕様を確認します。

具体例：オンライン申請の一連試験

オンライン申請では、住民が入力を開始してから職員処理・通知までを一つの流れとして確認します。架空の申請者で、途中保存、再開、添付、本人確認、送信、受付通知、職員審査、差戻し、再提出、決裁、完了通知を実行します。各段階で画面だけでなく状態コード、時刻、通知宛先、監査ログを確認します。

差戻しでは、差戻し理由に庁内メモや他住民情報が出ないこと、住民が許可された項目だけ修正できることを確認します。同じ送信ボタンを連打した場合、通信切断後に再送した場合、ブラウザの戻る操作をした場合にも二重受付にならないことを試験します。

職員側では、担当外所属、閲覧のみ、承認者、代理者で同じ受付番号へアクセスし、許可・拒否が設計どおりであることを確認します。制限情報は画面、検索候補、CSV、帳票、通知、ログに漏れないことを確認します。最後に、申請者が取得できるデータと自治体に保存されるデータの保持・削除条件を確認します。

手順レビュー会の実施例

レビュー会では、原課が期待される業務結果、開発者が技術結果、セキュリティ担当が権限とログ、試験管理者が独立性と証跡を確認します。ケースを一件読み上げ、前提データを本当に作れるか、期待値は独立して算出できるか、実施後に元へ戻せるかを机上で追跡します。

指摘には、ケースID、ステップ、重要度、根拠、修正者、期限、再確認者を付けます。単なる表記修正と合否基準変更を分け、後者は自治体の再承認を得ます。レビュー後にケース件数だけが増え、要件への対応が外れていないか、トレーサビリティ表を再集計します。

実施記録の例

ケース：UAT-PORTAL-031／対象build 1842／実施者A・確認者B
前提：架空申請者DATA-031、未申請、通知先はテスト受信箱
10:02 操作1送信／受付番号T202600031を表示／期待一致／証跡S01
10:03 DB状態「受付」、重複0件／期待一致／証跡S02
10:04 通知1件、個人情報は規定範囲のみ／期待一致／証跡S03
10:06 監査ログに利用者・操作・時刻・結果／期待一致／証跡S04
判定：合格／後処理：データ削除、受信箱消去、削除ログE031

まとめ

自治体向け試験手順書の書き方で重要なのは、要件を再現可能な操作と客観的な期待結果に変換することです。対象版、架空データ、個人情報保護、承認、証跡、欠陥管理、停止基準、ロールバックをケースに組み込みます。自治体向け試験手順書の作り方を標準化すれば、担当者による判定差を減らし、検収と監査に耐える結果を残せます。実施時には、法令、政府ガイドライン、自治体規程、標準仕様、製品仕様の最新版を必ず確認してください。