作品 14
届出ナビ
引っ越し・結婚・相続など 20 のライフイベントについて、ヒアリングで必要な行政手続きを絞り、期限付きチェックリストにして完了まで導く
2課題
引っ越し、結婚、出産、相続。生活が変わるたびに何かを届け出なければならないが、何を、どこへ、いつまでに出すのかは当事者にはまず分からない。漏らせば過料や窓口への再訪問という実害が出る。既存の情報源は制度を並べるところで止まっており、自分の状況へ当てはめる作業は読み手の側に残されたままである。要るのは網羅された一覧ではなく、状況を聞き取って自分に必要な手続きだけを残し、期限つきの持ち物として手渡す仕組みだと考えた。
3要件・制約
体験の側の要件が先に決まった。入口で状況を聞き取り、回答に応じて候補を絞り、残ったものを期限つきのチェックリストとして返すこと。締切は目安ではなく管理の対象として扱い、厳しく見る設定も併せて置くこと。制度は自治体や年度によって変わるため、対象とするライフイベントは後から増やせる形にすること。実装では認証と権限の境界をデータベース側に置き、本番の応答にも防御の見出しを並べている。
4設計
画面の流れは、入口、ライフイベントの選択、聞き取りの案内役、個別化されたチェックリスト、手続きの詳細という順に固定した。聞き取りの回答はそのまま絞り込みの条件になり、チェックリストには期限と進み具合の指標を併置する。対象とするライフイベントは当初の数から途中で拡張しており、その広がりと定義の規模は本節末の計測に示す。
ライフイベント — 20 種(初期 8 → 2026-03-04 に拡張)1
DB — 99 CREATE TABLE(うちパーティション 18、基底 81)/ マイグレーション 12 ファイル2
6実装
言語モデルを使う機能は補助として広く配置した。要約、つまずきやすい点の提示、手続きどうしの比較、費用の助言、書類の確認、平易な言い換え、着手順の整理、窓口の案内、翻訳といった用途がそれぞれ独立した口として並ぶ。あわせて意味による検索と、逸脱を抑える枠を持たせた対話を置いた。呼び出しは特定の事業者へ直に繋がず、GitHub Models API という仲介する提供口を経由する形にしてある。挿絵は外部の素材を用い、枠の数を先に決めた表で管理している。
7性能対策
性能は事後の測定ではなく、出荷の関門として先に定義した。表示までの時間、操作への応答、画面のずれといった指標に上限を置き、初回に転送する量にも上限を敷いた上で、二回続けて超えたら調査するという運用規則まで文書へ書いている。実測は利用者側の計測値を集める部品を仕込んで取る。チェックリストの保存については、操作のたびに書き込む方式から、少し待ってまとめて書き込む方式へ変えた。指標そのものの数値は本稿では扱わない。
8結果
独自ドメインで本番稼働している。応答、健全性の確認口、サイト地図のいずれも外形から確認でき、防御の見出しも本番の応答に実在する。内訳は本節末の計測に示す。開発期間そのものは短いが、その間に第二回と第三回の監査、網羅的な点検、深層のコード確認を何巡も回した記録がコミット履歴へ完全な形で残っている。認証の判定を、Cookie の有無を見るだけの実装から、利用者の実体を取得して確かめる実装へ変更している。
稼働確認 — HTTP 200 / Vercel / X-Vercel-Cache HIT / sitemap 147 URL3
セキュリティヘッダ — 本番レスポンスに CSP・HSTS(preload)・X-Frame-Options DENY・Permissions-Policy を実在確認4
9検証で判明した注意点
継続的統合は存在しない。設定ディレクトリそのものが置かれていない。テストは書かれているが、この検証の環境では実行できず合否を確認していないため、通っていると読める書き方は取っていない。
公開しているのは本番の入口だけである。ソースの保管庫は非公開のままで、公開に向けた洗浄が済んでいない。
挿絵は第三者の素材であり、出典の明示が要る。
10AI 支援の関与
成果物の側には言語モデルを使う機能を多数組み込んでいる一方、開発工程における AI の関与を記した一次記述は資料に見当たらないため、本稿では反復的な自己監査の記録がコミット履歴に残っていることだけを事実として扱う。