はじめに
家族が亡くなると、死亡届、年金の停止、健康保険の資格喪失、相続の方法の判断、相続登記、相続税の申告など、数十件の手続きが待っています。さらに、期限のあるものも多く、どの手続きが必要かは、故人の保険・年金・財産によって変わります。
after-flowは、こうした手続きを、タスク管理とAIの支援で前に進めるためのWebアプリです。
2026年9月19日〜23日に開催されたハッカソン AI HACK に3人で参加して作りました。私はFrontendを担当し、チームメイトがBackendとAIを担当しました。
- リポジトリ：https://github.com/after-flow/after-flow
- 技術：TypeScript / React / Hono / Mastra / Firestore
- AIゲートウェイ：OrcaRouter
「自律化」のリスク
ハッカソンのテーマは 「業務を自律化するAIエージェント」 でした。
私たちは、遺族が手探りで進める死亡後の手続きを「業務」と捉え、手続きごとに必要な書類や手順を調べ、整理し、次にやることを示すところまでを、AIエージェントに任せることにしました。
一方で、この分野にはAIに任せるべきではない部分があります。
- 本人が決めなければいけない：相続の方法（相続するか、相続放棄するかなど）は、本人の意思で決める必要がある
- 資格者しかできない業務がある：他人に代わって相続登記の申請書類を作成できるのは司法書士など、相続税の申告書を作成できるのは税理士など、と法律で定められている
たとえば、AIが必要な書類を自動で作成したり、本人に代わってオンラインで申請・提出したりするところまで自律化すると、誤りが生じた場合の責任の所在があいまいになるうえ、手続きによっては資格制度や代理申請に関するルールに抵触する可能性があります。
そこでafter-flowでは、AIが「何をすべきか」を調べ、整理し、次のタスクを提示するところまでを自動化し、実際の判断や書類の確認・提出などは利用者自身が行う、という線を引きました。
アプリ紹介
本アプリでは、手続きを10段階に分け、ワークフローとして、いまどの段階にいて、何をすればいいのかが視覚的にわかりやすいデザインにしました。
画面構成
| 画面 | できること |
|---|---|
| 手続きの流れ | 手続き全体を段階ごとに上から順に見て、いまどの段階か確かめられる。段階ごとの、いちばん近い期限も分かる |
| やること | すべての手続きを期限の近い順に見られる。担当者で絞り込める |
| AIからの確認 | 書類からAIが読み取った内容を確かめられる。合っていればそのまま登録でき、必要なら修正もできる |
| 手続きの詳細 | 行き先・持ち物・手順・期限を確かめられ、済んだら記録できる。一部の手続きでは、自治体の窓口の情報をAIに調べてもらえる |
| 書類 | 死亡診断書や通帳などを写真やPDFで追加でき、AIが中身を読み取ってくれる |
| 財産・契約 | 財産・借金・契約、受け取れるお金をまとめて管理できる |
| 家族・相続人 | 相続人を登録でき、それぞれが選んだ相続の方法を記録できる |
| AIに相談 | 分からないことをAIに聞ける。画面の横（スマホでは下）に開くので、手続きの案内を見ながら相談できる |
AIが業務データに触れない設計
AI Serverを、業務データを持つBackendから切り離しました。
具体的には、次の3つのルールを設けました。
- 画面はAI Serverと直接やり取りせず、必ずBackendを通す
- AI Serverには、業務データのデータベースや書類の原本に触れる権限を渡さず、Backendが渡した情報だけを使う
- 業務データを書き換えるのはBackendだけで、AIの結果はBackendが確かめてから保存する
これらのルールはCIで自動チェックしており、たとえば画面のコードがAI Serverのコードを読み込んでいる場合や、AI Serverの起動設定にデータベースの接続情報が渡されている場合には、チェックが失敗する仕組みになっています。
このような構成にしたことで、AIが停止しても利用者は自分の案件を問題なく確認できます。また、AIのモデルを入れ替える場合も、データを守る仕組みそのものには影響が及びません。
2つのAIエージェント
判断の食い違いによる矛盾
手続きの種類ごとにエージェントを増やす方法もありますが、複数のエージェントがそれぞれ判断しながら作業を進めると、暗黙の前提が食い違い、結果に矛盾が生じる可能性があります。
そのためafter-flowでは、AIエージェントを以下の2つだけに限定しました。
- まとめる役：案件の状況を整理し、調べた結果をもとに利用者への案内を作る
- 調べる役：決められた公式サイトだけを読み、質問への答えを返す
これは、Cognitionの「Don't Build Multi-Agents」を参考にしたもので、案内内容を判断するエージェントを1つに集約することで、案内全体を通して「どの給付か」「誰が申請者か」といった前提を統一しています。
ハルシネーション
AIのハルシネーションによって、存在しないURLを出典として示したり、ページに書かれていない内容を、あたかも書かれているかのように答えたりすることがあります。
そこで調べる役には、回答ごとに読んだページの本文からの引用を付けさせ、プログラムで次のことを確認します。
- 出典のページを実際に取得しているか
- 引用が本文に本当に存在するか
- 質問内容にきちんと答えているか
さらに、まとめる役が作成した案内文についても、確認済みの引用と1件ずつ突き合わせます。引用で裏付けられない内容は案内に含めず、とりわけ金額や日数など、誤りが許されない情報については、本文で確認できた場合にのみ表示します。
このように、公式ページの本文と照合できた情報だけを案内に使うことで、ハルシネーションを抑制する設計になっています。
これから
- AIが公式サイトを調べる手続きの範囲を、現在の一部から広げる
- 手続きの選び方と期限の数え方のルールを専門家に確認してもらい、確定した期限として表示できるようにする
- 書類に載ったマイナンバーを見つけて隠す仕組みを入れる（方式を選定中）
- 本番用のログインを整えて公開する
おわりに
家族を亡くした直後は、悲しみの中で、慣れない手続きを期限に追われながら進めることになります。after-flow が目指したのは、その負担を「何をすればいいか」が分かる状態まで軽くすることでした。
一方で、相続の方法を決めることや、書類を確かめて出すことは、本人にしかできません。そこで、AIには調べる・整理する・次を示すところまでを任せ、判断と提出は人に残す、という線を仕組みで引きました。
最後に、開発の機会をくださった AI HACK 主催の高野雄希様、協賛企業のCyberACE様、ウィルオブテック様、OrcaRouter の皆さま、ありがとうございました。