もし自分が明日死んだら、誰がそれに気づくのか？
ふとそんなことを考えたことはないだろうか。
SNSでは毎日のように誰かの投稿が流れてくる。でも、ある日突然その人の投稿が途絶えたとき、あなたはそれに気づけるだろうか。そして、気づいたとして——確かめる方法はあるだろうか。
この問いに対する答えとして、moshimo.（もしも）という生存確認サービスを作った。
サービスURL: https://moshimoapp.com
自己紹介
はじめまして。本業はほぼ管理業務をしているSEです。
日々の仕事はExcelとメール、会議の調整がメイン。コードを書く時間は業務中にはほぼない。「自分はエンジニアなのか？」と自問する日々を過ごしていた。
そんな中、1年半前にこのサービスのアイデアを思いついた。「孤独死をテクノロジーで防げないか」「デジタル時代の"もしも"に備えるサービスがあれば」と。ただ、本業の合間にゼロからWebサービスを作る時間も技術力もなかった。
転機はClaude Codeとの出会いだった。
「これなら自分でも作れるかもしれない」——その直感を信じて開発を始めてから、約1ヶ月でリリースにこぎつけた。この記事では、その全過程を包み隠さず書いていく。
moshimo. とは
moshimo. は、「あの人、生きてるかな？」という不安を安全に解消するための生存確認サービスだ。
コンセプトは「生存確認を"管理"から"繋がり"へ」。監視カメラやセンサーのような管理的アプローチではなく、人と人との信頼関係をベースに生存確認を行う。
3つのロール
moshimo. には3つのロール（役割）がある。
| ロール | 役割 | 費用 |
|---|---|---|
| 利用者（Subject） | "預ける人"。バディや遺言を設定し、最終的な生存拒否権（Aliveボタン）を持つ | 基本無料 |
| 証人（Buddy） | "証人"。利用者の生死を報告する。逝去確定時に遺言を受け取る | 0円〜 |
| 確認者（Inquirer） | "確認する人"。有料で生存確認を依頼し、「生存」か「逝去」の事実のみを受け取る | 1,000円〜 |
ポイントは確認者には「生きているか、亡くなったか」の事実しか伝わらないこと。個人情報は一切漏れない設計になっている。
主要機能
-
生存照会: 確認者
が有料で安否確認を依頼。バディに通知が届き、報告を元に判定 - Aliveボタン: 利用者本人が「生きてます」とワンタップで証明できる（誤判定防止の最後の砦）
- 遺言機能: バディごとに個別のメッセージを設定。逝去確定時にメールで自動送信
- バディ・パス: 1,980円でバディ枠+10名拡張。特急報告チケット1枚付き
- 3つのバディ招待方式: メール招待・グループ招待リンク・バディコード
なぜ作ったのか
原体験——友人の突然死を半年後に知った
このサービスを作ろうと思ったきっかけは、大学時代の友人が突然亡くなったことだった。
ある日を境に、その友人からの連絡がぱったりと途絶えた。LINEを送っても既読がつかない。でも、社会人になれば連絡が途切れることなんて珍しくない。「忙しいんだろう」と思っていた。
結果的に、亡くなったことを知ったのは半年後だった。 しかも、葬儀も全て終わった後に、偶然の経路で知った。
考えてみれば当然だ。遺族は故人の交友関係を全ては把握していない。地元が違えば話も広まってこない。スマホにはパスワードがかかっていて、連絡先も見られない。
「あの人、最近どうしてるんだろう」と思ったとき、それを確かめる手段がない。
この経験がずっと引っかかっていた。1年半、頭の中で「こういうサービスがあれば」と温め続けた。
社会課題としての「孤独死」
自分の体験は特殊なケースではない。日本では年間約6.8万人が孤独死しているとされる。高齢者だけの問題ではない。単身世帯の増加とともに、30〜50代の突然死・孤独死も増えている。
デジタル時代になり、「物理的に近くにいないけど繋がっている」関係が増えた。SNSで毎日やりとりしている友人が、実は隣の県に住んでいることも珍しくない。そんな関係において、相手の安否を確認する手段はあまりにも乏しい。
遺族は故人のSNSアカウントにアクセスできない。スマホのパスワードも知らない。故人がオンラインで誰と繋がっていたかを把握する術がない。結果として、訃報が届くべき人に届かない。
既存サービスとの違い
生存確認系のサービスは存在するが、その多くは「センサー設置」「定期的な安否確認電話」など、管理的・監視的なアプローチだ。
moshimo. は違う。人と人の信頼関係を軸にしている。
- センサーもカメラも不要
- 定期的な報告義務もない（日常を邪魔しない）
- 「もしもの時」にだけ機能する——普段は存在を忘れていい
「普段は意識しないけど、もしもの時にちゃんと機能する」。それがmoshimo. のコンセプトだ。
Claude Code × 開発の実態
ここからがこの記事のメインコンテンツだ。管理業務SEが、Claude Codeを使って1ヶ月でどうやってWebサービスをリリースしたのか。
Claude Codeに何をやらせたか
結論から言うと、ほぼ全部だ。
PRD（プロダクト要件定義書）の作成
まず最初にやったのは、頭の中にあったアイデアをClaude Codeに伝えて、PRDを一緒に作ること。「こういうサービスを作りたい」という雑なイメージを投げると、ロール定義、機能一覧、セキュリティ要件まで体系的にまとめてくれた。
最終的にPRDはv9.0まで改訂を重ねた。Claude Codeと壁打ちしながら要件を詰めていく過程は、一人で仕様書を書くよりも圧倒的に早く、かつ抜け漏れが少なかった。
ADR（設計判断記録）の作成
moshimo. の開発では、ADR（Architecture Decision Record） を11件作成した。
docs/adr/
├── 0001-tech-stack-selection.md # 技術スタック選定
├── 0002-directory-structure.md # ディレクトリ構造
├── 0003-encryption-strategy.md # 暗号化戦略
├── 0004-will-encryption-architecture.md # 遺言暗号化アーキテクチャ
├── 0005-will-disclosure-flow.md # 遺言開示フロー
├── 0006-notification-strategy.md # 通知戦略
├── 0007-cron-execution-strategy.md # Cron実行戦略
├── 0008-mutual-buddy-consent-model.md # 相互バディ同意モデル
├── 0009-group-buddy-invite.md # グループ招待
├── 0010-buddy-pass-stackable.md # バディ・パス（スタッカブル）
└── 0011-buddy-code-alternative-pairing.md # バディコード
「なぜその技術を選んだのか」「なぜその設計にしたのか」を記録し続けた。これは個人開発だからこそやってよかったことの一つ。1ヶ月後に「なんでこうしたんだっけ？」と迷わずに済む。
Claude Codeは決定の記録だけでなく、棄却した代替案とその理由まで書いてくれるので、後から振り返ったときの価値が非常に高い。
実装
フロントエンドからバックエンド、DB設計、RLSポリシー、Stripe連携、メール送信まで、コードの大部分をClaude Codeが書いた。
具体的な開発の流れはこうだ：
- PRDの該当セクションを指示として与える
- Claude Codeが実装する
- 自分がレビューして、修正点を指示する
- Claude Codeが修正する
- 動作確認して次へ
人間の自分がやったことは、要件定義・レビュー・最終判断・動作確認だ。
Claude Codeで特に助かった場面
1. RLSポリシーの設計（全テーブル分）
moshimo. は「死」を扱うサービスだ。他人の生死情報が漏洩することは絶対にあってはならない。
そのため、全テーブルにRow Level Security（RLS）を適用している。Supabaseの全テーブルそれぞれに、「誰が」「どのデータに」「どの操作を」許可するかを定義した。
RLSポリシーの設計は、SQLの知識だけでなく、ビジネスロジックの深い理解が必要になる。Claude Codeは、PRDのロール定義を理解した上で、適切なポリシーを生成してくれた。
ただし、ここで重要な教訓がある。Claude Codeが生成したRLSポリシーにも穴があった（後述の「苦労した点」で詳しく書く）。
2. Stripe Webhookの実装
決済→バディ通知→猶予期間開始→Cron判定→遺言送信、という一連のフローは、正直かなり複雑だ。
特にStripe Webhookのcheckout.session.completedイベントを受けて、照会の種類（通常照会 or 特急報告）に応じた処理を分岐し、猶予期間をDBに書き込む部分は、Claude Codeなしでは相当な時間がかかったと思う。
3. 執行確定ロジック
moshimo. の核となるロジックがこれだ。
$$V_{final} = (B_{report} \ge 1) \land (S_{subject} = \text{Silence}) \land (T_{grace} = \text{Expired})$$
- B_report >= 1: バディが1名以上「逝去」を報告している
- S_subject = Silence: 利用者本人がAliveボタンを押していない
- T_grace = Expired: 猶予期間が満了している
この3条件が全て揃った時のみ、執行が確定する。一つでも欠ければ執行されない。
// 執行判定のイメージ（擬似コード）
// 1. 猶予期間が満了した照会を取得（status + 時刻でフィルタ → 冪等性保証）
// 2. 有効な逝去報告が1件以上あるかチェック
// 3. 条件が揃えば executed、揃わなければ alive_confirmed に更新
const hasActiveReport = await checkDeceasedReports(subjectId)
if (hasActiveReport) {
await executeInquiry(inquiry) // 執行確定 → 遺言自動送信
} else {
await confirmAlive(inquiry) // 生存確認
}
このロジックのポイントは冪等性だ。Cronジョブが複数回走っても同じ結果になるよう、ステータスチェックで二重処理を防いでいる。
Claude Codeの限界・苦労した点
万能ではない。正直に書いておく。
「死」を理解しきれない
Claude Codeは技術的には優秀だが、「死を扱うサービスで何が危険か」の感覚は人間ほど鋭くない。
例えば、Server ActionのautoApplyBuddyPairing関数でuserIdを引数として受け取る実装をClaude Codeが書いた。技術的には動く。しかし、'use server'ファイルからexportされた関数はクライアントから呼び出し可能なので、任意のuserIdでなりすまし証人申請ができるセキュリティ脆弱性だった。
生存確認サービスでなりすまし証人が可能ということは、他人を「死んだ」ことにできるということだ。技術的なバグの重大度と、ビジネスとしての重大度は全く異なる。
コンテキストの喪失
長い会話が続くと、最初に伝えたPRDの内容やADRの決定事項を「忘れる」ことがある。結果として、過去に棄却した設計を再提案してきたり、ADRと矛盾する実装を書いたりする。
対策としては、ADRを頻繁に参照させることと、一つの会話を長くしすぎないことが有効だった。
微妙なUI表現
「死」を扱うUIは、技術的な正しさとは別の感覚が求められる。
- ボタンの文言一つで印象が大きく変わる
- 色使い、余白、トーンに細心の注意が必要
- 「不安を煽らず、でも軽すぎない」バランス
この領域はClaude Codeに任せきりにはできなかった。最終的なUI/UXの判断は人間の仕事だ。
技術スタック
構成
┌─────────────────────────────────────────┐
│ Vercel (Hosting) │
│ ┌───────────────────────────────────┐ │
│ │ Next.js 16 (App Router) │ │
│ │ TypeScript / React 19 │ │
│ │ Tailwind CSS v4 + shadcn/ui │ │
│ └──────────┬────────────────────────┘ │
│ │ │
│ ┌──────────▼──────┐ ┌──────────────┐ │
│ │ Supabase │ │ Stripe │ │
│ │ - Postgres │ │ - Checkout │ │
│ │ - Auth (RLS) │ │ - Webhook │ │
│ │ - Realtime │ │ │ │
│ └─────────────────┘ └──────────────┘ │
│ │
│ ┌─────────────────┐ ┌──────────────┐ │
│ │ Resend │ │ Upstash Redis│ │
│ │ - 通知メール │ │ - Rate Limit │ │
│ │ - 遺言配信 │ │ │ │
│ └─────────────────┘ └──────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ microCMS │ │
│ │ - ブログ/お知らせ│ │
│ └─────────────────┘ │
└─────────────────────────────────────────┘
選定理由（個人開発で持続可能な技術選定）
| 技術 | 選定理由 |
|---|---|
| Next.js 16 (App Router) | Server Actionsにより API Routes を最小化。サーバー/クライアントの境界が明確 |
| Supabase | RLSによるDB層アクセス制御が生存確認サービスのセキュリティ要件に適合。Auth・Realtime一体化 |
| Stripe | 照会の有料化により「いたずら防止フィルタ」として機能。Webhook連携が堅牢 |
| Tailwind v4 + shadcn/ui | 「静謐で信頼感のあるUI」を素早く実装。カスタムカラーパレットの定義が容易 |
| Resend | メール到達率が高く、API がシンプル。遺言の自動配信に使用 |
| microCMS | ブログ・お知らせなどのコンテンツ管理。ヘッドレスCMSで運用負荷を最小化 |
| Upstash Redis | サーバーレス環境対応のレートリミッター。Vercelとの相性が良い |
| Vercel | Next.jsのデプロイに最適。Cronジョブ（執行判定の定期実行）もサポート |
運用コスト（MVP段階）
| サービス | 費用 |
|---|---|
| Vercel | $20/月（Proプラン） |
| Supabase | $0（Freeプラン） |
| Stripe | 決済手数料のみ（3.6%） |
| Resend | $0（月100通まで無料） |
| microCMS | $0（Hobbyプラン） |
| Upstash Redis | $0（Freeプラン） |
| 合計 | 約$20/月 |
個人開発において維持コストを低く抑えることは、サービスを続けられるかどうかの生命線だ。Vercel Pro以外は無料枠で収まっており、月$20程度なら個人でも十分に継続可能なラインだと思う。
セキュリティ設計
「死」を扱うからこそ、セキュリティには個人開発のレベルを超えた注意を払った。
遺言の暗号化（AES-256-GCM）
遺言データはサーバーサイドでAES-256-GCMにより暗号化して保存している。
// 暗号化処理のイメージ（簡略化）
export async function encryptWillContent(plaintext: string): Promise<string> {
const key = await getEncryptionKey() // 環境変数から256bit鍵を取得
const iv = crypto.getRandomValues(new Uint8Array(12)) // 96bit IV（GCM推奨）
const ciphertext = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv },
key,
new TextEncoder().encode(plaintext)
)
// IV + 暗号文を base64 エンコードして保存
return formatForStorage(iv, ciphertext)
}
暗号化前の平文データとの後方互換性も確保しており、マイグレーション時に既存データが壊れない設計にした。
実は、当初はクライアントサイド暗号化（パスフレーズ方式）で「運営も読めない」ゼロナレッジ設計だった。しかし、以下の理由で断念した：
- バディごとに異なる遺言を設定する要件が追加 → パスフレーズ管理が複雑化
- バディがパスフレーズを忘れると遺言が永久に読めない → 「確実に届く」が最優先
- パスフレーズ設定UIが「死」を強調しすぎる → ブランドコンセプトに反する
この判断はADR 0003に記録した。現在は、執行確定と同時にバディのメールアドレスに遺言を自動送信する方式を採用している。バディは生存しているため、メールの到達性が高く、遺族への橋渡し役を担う設計だ。
設計を変えた理由と棄却した代替案を残しておくことは、個人開発でも（むしろ個人開発だからこそ）重要だ。
全テーブルRLS
Supabaseの全テーブル全てにRow Level Security（RLS）を適用している。
例えば、遺言テーブル（wills）には：
- Subject本人だけがCRUD可能
- 宛先のバディだけがSELECT可能
- 他人は存在すら見えない
というポリシーが設定されている。
執行確定ロジック（誤判定防止）
最も慎重に設計した部分がここだ。「生きている人を死んだことにする」ことは絶対にあってはならない。
$$V_{final} = (B_{report} \ge 1) \land (S_{subject} = \text{Silence}) \land (T_{grace} = \text{Expired})$$
3つの独立した条件が全て真にならないと執行されない。特に：
- Aliveボタン: 利用者本人が1タップで「生きてます」と証明できる。押した瞬間、全ての逝去報告が無効化される
- 猶予期間: 最低48時間〜最大720時間（30日）を利用者自身が設定できる。デフォルトは72時間
「本当に亡くなったのか」を時間をかけて確認する仕組みだ。
苦労した点・失敗談
「死」を扱うUIデザインの難しさ
これが一番苦労した。
「逝去が確定しました」というメッセージ一つとっても、文言のトーン、フォントの大きさ、色、余白——全てが印象を左右する。重すぎると使うのが怖くなるし、軽すぎると不謹慎になる。
moshimo. のデザインコンセプトは「静謐・信頼・迅速」。派手な装飾を排し、必要な情報を落ち着いたトーンで伝える設計にした。
セキュリティレビューで見つかった脆弱性たち
開発中に発見・修正した主なセキュリティ問題：
| 問題 | 深刻度 | 内容 |
|---|---|---|
| RLSの書き込み条件漏れ | Critical | UPDATEポリシーの書き込み条件が未定義で、権限フラグの自己書き換えが可能だった |
| Server Actionの認証不備 | High | 外部から呼び出し可能な関数がユーザーIDを引数で受け取り、なりすましが可能だった |
| CSPの緩和設定 | High | XSS防御のためのCSPが、開発時の緩和設定のまま残っていた |
| レートリミットの実装ミス | High | サーバーレス環境でインメモリ実装が機能しない問題 |
| リダイレクト先の検証不足 | Medium | OAuth後のリダイレクト先が未検証で、フィッシングに悪用可能だった |
| 検索入力のサニタイズ不備 | Medium | ワイルドカード文字の未エスケープによる情報列挙の可能性 |
特に「RLSの書き込み条件漏れ」は冷や汗ものだった。RLSポリシーの読み取り条件（USING句）は書いていたが、書き込み条件（WITH CHECK句）を書き忘れていた。これにより、認証済みユーザーが権限フラグを自己書き換えできる状態だった。
教訓: RLSのUPDATEポリシーには、読み取り条件だけでなく書き込み条件も必ず定義すること。
法的要件への対応
「死」を扱うサービスは法的にもデリケートだ。以下の対応が必要だった：
- 特定商取引法に基づく表記: 照会の有料化に伴い必須
- 利用規約: 遺言の法的効力がないこと、返金不可の条件、バディ選定の注意喚起
- プライバシーポリシー: 遺言データの保存・開示条件、運営が技術的に復号可能であること
- 遺言の免責: 「moshimo. の遺言は法的遺言書ではない」ことの明示
Claude Codeに任せすぎて起きた問題
暗号化戦略の変更（ADR 0003）を行った際、Claude Codeに実装を任せたが、ADRの更新を忘れた。結果として、設計ドキュメント（ADR）が「暗号化を廃止して平文保存」と書いてあるのに、実装はAES-256-GCM暗号化を再導入している——という矛盾が発生した。
Claude Codeは「今何をすべきか」には強いが、「過去の決定との整合性」を自発的にチェックする力は弱い。ドキュメントの一貫性は人間が責任を持つべきだと学んだ。
学んだこと
Claude Code時代の個人開発で大切だと思ったことを5つ。
1. PRDを最初に書け
Claude Codeに「なんかいい感じのサービス作って」では動かない。何を作るのか、誰のために、なぜ作るのかを言語化してから渡すことで、出力の品質が劇的に変わる。
PRDは完璧でなくていい。Claude Codeと壁打ちしながら育てていくのが最も効率的だった。
2. ADRを残せ
「なぜその設計にしたのか」を記録すること。個人開発では「全部自分の頭の中にある」と思いがちだが、1ヶ月も経てば忘れる。特にClaude Codeとの開発では、AIが提案した設計判断の根拠を記録しておかないと、後から変更する際に「なぜこうなっているのか」がわからなくなる。
3. セキュリティレビューは別の目で
Claude Codeが書いたコードをClaude Code自身にレビューさせても、同じ盲点を見逃す可能性がある。別のコンテキスト（別の会話セッション）で、セキュリティに特化したレビューを行うことで、実際に複数のCritical脆弱性を発見できた。
4. 「管理業務SE」でもプロダクトは作れる
本業でコードを書いていなくても、要件定義力とレビュー力があれば、Claude Codeと組み合わせてプロダクトは作れる。
むしろ管理業務で培った「要件の整理」「リスクの洗い出し」「ステークホルダー間の調整」といったスキルは、プロダクト開発において思った以上に活きた。
5. 最後はドメイン知識
「死」を扱うサービスの仕様は、技術だけでは決められない。猶予期間は何時間が適切か、遺言はどのタイミングで届けるべきか、UIのトーンはどうあるべきか——これらは全てドメイン知識と倫理的判断が必要だ。
AIはツールであり、最終判断は人間がする。当たり前のようで、Claude Code時代だからこそ改めて強調したい。
おわりに
1年半温めたアイデアを、Claude Codeの力を借りて1ヶ月でリリースできた。管理業務ばかりのSEでも、プロダクトは作れる。
moshimo. はまだMVP段階だ。これからユーザーの声を聞きながら、改善を続けていく。
サービスURL: https://moshimoapp.com
フィードバック、バグ報告、感想——何でも歓迎です。
X: @k_hori7
この記事が、個人開発を考えている誰かの背中を押すきっかけになれば嬉しい。
アイデアと適切なツールがあれば、社会課題に挑むプロダクトを誰でも作れる時代になったようだ。