--- type: other title: 2 検索・照会・操作 source: 自治体システム等標準化検討会 profile: mrlgss-doc/0.1 business_code: "001" version: "6.1" spec_date: 2026-03-25 --- # 2 検索・照会・操作 ## 2.1 検索 ### 2.1.1 検索機能 **【実装必須機能】** システム利用者（操作者ID単位）ごとに、一度検索ダイアログ等で設定した値（検索履歴）については、自動的にその設定値が、一定の件数保存されること。 また、それら検索履歴を選択することにより、同じ条件による再検索及び検索履歴を活用した新たな検索にも対応できること。 **【考え方・理由】** 業務効率化の観点から、検索パラメータの履歴保持は有効。 宛名番号、個人番号、氏名等は、既に個人が特定されている情報であるため設定値の保存は不要との考えもあり得るが、同一個人を別処理にて検索する際には、特定された検索キーであっても再検索できる方が業務効率化の観点には適していると考えられることから、設定値が保存される対象は限定しないこととした。 また、準構成員への意見照会において、保存数の上限を設定すべきであるとの意見があった。業務効率化の観点からは全ての履歴を保持する必要はなく直近の履歴で足りると考えられるが、適当な件数については各市区町村の処理数によって異なることから、一定の件数とした。 なお、権限、情報セキュリティ等の観点から、履歴保持は、システム利用者ごと（操作者ID単位）に実施できなければならない。 ### 2.1.2 検索文字入力 **【実装必須機能】** 日本人氏名及び旧氏の振り仮名並びに外国人氏名及び通称のフリガナ（「2検索・照会・操作」において「氏名の振り仮名等」という。）を登録している場合は、カタカナで入力及び検索できること。 以下のあいまい検索ができること。 ・清音、濁音、半濁音による違いを無視できること。 例　「ヂ」と「ジ」、「ズ」と「ヅ」、「ワ」と「ハ」、「ヴァ」と「バ」、「ヴィ」と「ビ」、「ヴ」と「ブ」、「オ」と「ヲ」、「ヒ」と「ピ」 ・拗音、促音の小文字と大文字による違いを無視できること。 例　「ッ」と「ツ」、「ャ」と「ヤ」、「ュ」と「ユ」、「ョ」と「ヨ」 ・氏名（外国人住民における「氏名（ローマ字）」及び「氏名（漢字）」を含む。）や氏名の振り仮名等で文字列一致検索（完全一致・部分一致）ができること。 ・名（氏名の名）のみの検索ができること。 ・氏と名との間のスペースを無視した検索ができること。 ・氏名の振り仮名等検索について、２文字目以降が「ウ」の場合で、その直前の文字が「オ段」の場合、「ウ」を「オ」に変換して検索できること。 ・長音の有無を無視できること。 ・入力ゆらぎ対応として、「ー（全角長音）」と「―（全角ダッシュ）」と「－（全角マイナス）」と「‐（全角ハイフン）」、「-（半角長音）」と「-（半角ハイフン、マイナス）」、「全角スペース」と「半角スペース」を区別せず検索条件として指定でき両方が該当として処理されること。 ・検索文字から、異体字や正字も包含した検索ができること。 　例：検索文字の例 「辺」で検索時は「邊」、「边」、「邉」、「𨘢」等、 「浜」で検索時は「濱」、「頻」、「濵」、「滨」等、 「藤」で検索時は「䕨」、「籘」、「籐」等が検索対象文字となる。 なお、一般市区町村においては、あいまい検索の機能として異体字検索は、標準オプション機能とする。 **【実装不可機能】** （株）や（有）等の記号を入力及び検索できること。 **【考え方・理由】** 氏名の振り仮名等を登録している場合は、清音・濁音のあいまい検索は、ニーズも高く、検索結果漏れをなくす観点からも重要と判断。 また、（株）や（有）等の記号は、法人名（税の宛名管理等）で用いられることはあるが、住民記録システムとしては不要であり、仮に必要であったとしても、外字としてではなく、「（\_株\_）」や「（\_有\_）」という形（３文字）で対応できることから、不要。 あいまい検索機能を提供することによって、清音、濁音、半濁音、ハイフン、長音、異体字等を区別しない検索を可能とするニーズが高いと判断。ただし、異体字検索については中核市レベルのニーズが高いのに対して、小規模市区町村におけるニーズは高くないとの準構成員からの意見を踏まえ、一般市区町村においては標準オプション機能とした。 ### 2.1.3 基本検索 **【実装必須機能】** 氏名（ローマ字・漢字を含む。）・旧氏・通称・氏名の振り仮名等・生年月日（西暦・和暦）・性別・続柄・住所・住所コード・方書・宛名番号・世帯番号・当該住民票を消除した事由・個人番号・住民票コード・住民種別（日本人、外国人）・在留カード番号・特別永住者証明書番号から検索できること。また、除票となった者の統合記載欄に含まれる、誤記があることが判明した場合の記録のうち、誤記修正後の記載である氏名・氏名の振り仮名等・生年月日について検索できること。 上記項目のうち空欄を許容している項目に関し、空欄を指定して検索できること。 指定都市においては、区からも検索できることとし、操作者の所属により管轄区を自動判定し、検索画面上の区を既定値として検索できること。なお、他区の選択も可能とすること。また、異動者一覧を表示している状態で、行政区単位の絞込みができること。 複数の条件を掛け合わせた検索や項目内の部分検索を実施できること。また、これらの検索で処理日等の項目で期間を指定して検索できること。 異動履歴の検索においては、氏名、旧氏、通称、氏名の振り仮名等、住所、住所コード、方書、住民票コード、個人番号及び在留カード番号等の番号については過去履歴を含めて検索し、対象者を特定できること。 検索文字選択のためのサポート機能が提供されていること。具体的には、手書き入力による文字選択等が想定されるが、具体的な実装方法は規定しない。 また、西暦と和暦はそれぞれ対応する年に置き換えられ検索がされること。 ※「検索」は、個人や世帯等を選択するため、画面から検索用項目を画面入力して、マッチするものを探す操作をいう。「照会」は、既に特定した個人や世帯等の詳細な情報について、データベースに問い合わせる操作をいう。 **【標準オプション機能】** 個人や世帯を検索、選択後、該当者の1.1.1（日本人住民データの管理）及び1.1.2（外国人住民のデータの管理）のデータをCSV形式で出力する機能を備えること。 **【実装不可機能】** 異動者一覧を表示している状態で、検索条件を加えての再検索（絞込み）ができること。 **【考え方・理由】** 中核市市長会ひな形に付記 旧氏、宛名番号、世帯番号、特別永住者証明書番号については、検索ニーズがあると判断した。 また、氏名（ローマ字・漢字を含む。）・旧氏・通称・氏名の振り仮名等を過去のものを含め横断的に検索できる氏名索引機能は、検索の効率化に有効。 分科会における議論の結果、交付請求者については、氏名はもちろん、郵便請求、第三者請求の区別も管理していない市区町村が多いため、検索キーとして不要。 「異動者一覧を表示している状態で、検索条件を加えての再検索（絞込み）ができること。」のような絞込み検索については、複数条件検索ができるのであれば不要。ただし、指定都市における行政区単位での絞込みは、区ごとに管轄が変わるため、作業の効率化のため実装必須機能とする。 また、「異動者一覧上で「氏名」「生年月日」「性別」「住所」「住所コード」「住民票コード」を確認できること。」、「異動者一覧から選択した住民の世帯状況が同一画面にて表示でき、世帯構成員・現住所が確認できること。」のような異動者一覧で確認できる必要がある項目については、画面についての機能であり、本仕様書には記載しない。 氏名のみならず住所についても過去のデータを横断的に検索するニーズが高いとの準構成員からの意見を踏まえ、追記。 空欄についての検索機能は、1.1.6（空欄）において空欄を許容している項目があることから機能として必要と整理した。 また、市区町村によっては、住民異動届に関する書類について、住民からの口頭の申出をもとに職員が作成を行う、いわゆる「書かない窓口」等を導入しているが、こうした、ペーパーレス化、書面主義の見直しを行う場合に住民データのCSV出力機能が有効との意見があったことから、標準オプション機能として整理した。 ## 2.2 照会 ### 2.2.1 異動履歴照会 **【実装必須機能】** 個人や世帯を特定した後に、1.2.1（異動履歴の管理）に規定する住民の異動履歴並びに通称の記載及び削除に関する事項を照会できること。 1.2.1（異動履歴の管理）に規定する項目を用いて住民の異動履歴を照会できること。 **【標準オプション機能】** 同一住民（再転入者等）を単位として複数の住民票・住民票の除票にわたって履歴を照会できること。その際、宛名番号による照会又は氏名、生年月日、性別及び住所（以下「４情報」という。）による照会のいずれにも対応できること。 **【考え方・理由】** 入力の経緯等の確認の際に、入力場所がすぐ把握できるようにするため、入力場所の履歴照会機能は必要。 届出日と処理日が異なる入力もあり、検索漏れを防ぐ必要があることから、どちらの日付でも照会を可能にする。 また、令第30条の17において、外国人住民については、通称の記載及び削除に関する事項が住民票の記載事項として定められており、婚姻等の身分行為による通称変更の申出等があった際に、これまでの通称の異動履歴を参照することが想定されるため、別途規定した。 ### 2.2.2 交付履歴照会 **【実装必須機能】** 個人を特定した後に、1.3.8（交付履歴の管理）に規定する証明書の交付履歴（20.1.1（住民票の写し）、20.1.3（住民票の写し（世帯連記式））、20.1.4（住民票の除票の写し）、20.1.2（住民票記載事項証明書・住民票除票記載事項証明書）、20.3.2（転出証明書）、20.3.3（転出証明書に準ずる証明書）、20.4.1（住民票コード通知票）、20.4.2（住民票コード変更通知票）及び20.4.3（住民票コード修正通知票）に関するもの）について、照会できること。 なお、照会に当たっては、1.3.8（交付履歴の管理）に規定する項目から行えること。 また、コンビニで交付された場合や広域交付住民票の場合も同様に照会できること。 **【考え方・理由】** 1.3.8（交付履歴の管理）に規定する交付履歴を照会する。 ### 2.2.3 文字コード照会等 **【実装必須機能】** 漢字文字の入力・照会については、拡大して入力・照会ができるとともに、文字コードの照会ができること。 **【標準オプション機能】** 転出証明書における二次元コードを読み取り、そこから得られた行政事務標準文字図形名から文字の照会ができること。 **【考え方・理由】** 戸籍上の文字との整合確認も行う実務上の要請から、当該機能は必要である。 OSの拡大鏡機能を使用することも考えられるが、OSが不確定で、拡大鏡機能を備えているとは限らないため、機能として必要。 単に文字イメージの拡大のみではなく、統一文字コード等の文字コードも確認できる方が良い。 また、転出証明書における二次元コードから行政事務標準文字図形名を取得できる機能を追加したことを踏まえ、行政事務標準文字図形名から文字の照会ができる機能を標準オプション機能とした。 ### 2.2.4 支援措置対象者照会 **【実装必須機能】** 照会した支援措置対象者（併せて支援を求める者を含む。）の住民票データを確認する場合において、支援措置期間中又は仮支援措置期間中である旨が明示的に確認でき、1.1.16（支援措置対象者管理）の支援措置のデータベースに連携して、当該データベースの支援措置対象者の詳細情報が確認できること。 **【考え方・理由】** 支援措置対象者を保護するため、支援措置対象者の相手方等に対して誤って支援措置対象者に係る住民基本台帳の一部の写しを閲覧させる又は住民票の写し等の証明書を交付することを防止するため、照会時に住民票データを確認する場合において表示する全ての画面において、支援措置対象者であることを容易に確認できる必要がある。 10.3（操作権限管理）において、利用者ごとの表示・閲覧項目及び実施処理の制御ができることとしており、各市区町村の支援措置に係る事務の実情に合わせて、データベースの閲覧権限や閲覧項目、閲覧を実施する際の処理等について、管理できるものである。 ## 2.3 操作 ### 2.3.1 処理画面 **【実装必須機能】** 異動処理中の画面では、該当する異動処理名称（「全部転入、一部転入、全部転出、一部転出、全全転居、全一転居、一全転居、一一転居」のように詳細に記載するか、「転入、転出、転居」のように簡易に記載するかは規定しない。）が表示されること。 **【考え方・理由】** 本項目は全体的には画面に関するものとして削除することも考えられるが、中核市市長会ひな形に位置づけられており、市区町村の関心も高い項目と考えられることから、標準として整理する。 「業務の流れに最適な画面遷移が行えること。」、「画面上で事務処理の流れが判別できること。」、「異動事由ごとに展開する業務画面を設定できること（住民票転入→国保資格取得→年金資格取得→介護資格取得）。」のような画面遷移や操作に関する項目は本仕様書では規定しない。 ### 2.3.2 キーボードのみの画面操作 **【標準オプション機能】** 端末のセキュリティを確保しながら、キーボードのみでも画面操作ができること。 **【考え方・理由】** キーボードのみの画面操作は、操作に成熟した職員の処理速度向上や職員の疲労度軽減のため、分科会における議論の結果、記載することとした。近年ではRPAで自動化する際、キーボード操作のコマンドを直接アプリケーションに送信することで、バックグラウンド処理で自動化が可能となるメリットもある。 本項目は全体的には画面・操作性に関するものとして削除することも考えられるが、市区町村によって業務に大きな影響を及ぼしかねない部分であることから記載している。ただし、キーボードのみでの画面操作が可能な機能を実装していれば、他の操作を否定するものではない。