会員アプリ
iOS · Android
青年部のメンバーが日常的に使うお知らせ、予定、予約、出席確認、祈りの課題、QT・聖書の閲覧。一つのExpoコードベースから両ストアに公開しました。
TypeScript · React Native · Expo
会員アプリ · iOS・Android
UP-Dream
つながりと振り返りから、次の小さな一歩へ。
出席確認、お知らせ、予定、スペース予約、祈りの課題、振り返り、聖書の閲覧をまとめた教会青年部向けのサービスです。会員アプリをiOSとAndroidで公開し、管理者Webと管理者アプリが共有するバックエンドまで一人で開発・運用しています。
開発のきっかけ
青年部室の予約はNaverカレンダー、連絡はKakaoTalkのオープンチャットと、情報が分散していました。お知らせ・予定・予約・出席・祈りの課題を一つのサービスにまとめ、在籍確認と管理者の承認を経て登録される仕組みにしました。
実際の利用状況
2025年12月1日から2026年11月3日まで、日曜の青年礼拝48回を対象に集計しました。
- 67.2%
- 48回中24回以上出席した定期出席者61名のうち41名が利用
- 49.1%
- 一度以上出席した青年114名のうち56名が登録
人数は重複なく数え、牧師とテスト用アカウントは除外しています。登録は必須情報の入力と規約への同意を完了したアカウントが対象です。出席はアプリに保存された記録をもとにしており、未入力の週は欠席として数えていません。
一つのサービス、四つの画面
管理業務は利用シーンに合わせてWebとネイティブアプリに分け、権限の判断はサーバーの一か所だけで行う設計にしました。
管理者Web
ブラウザ
机に向かって行う負荷の大きい業務を担当します。登録の承認、会員記録の管理、アカウント統合。2段階認証を使用しています。
TypeScript · React
管理者アプリ
iPhone · iPad
日曜の出席確認など、現場ですぐに行う業務を担当します。Face ID・Touch IDで確認し、サーバーが許可した操作だけを表示します。
Swift · SwiftUI
共通API
AWS ECS Fargate
三つのクライアントのセッション、権限、業務ルールを一か所で処理します。出席の変更はトランザクションで保存します。
TypeScript · PostgreSQL · S3
サービスのWebサイト、利用規約・プライバシーポリシー・児童の安全に関する方針、アプリ内のアカウント削除手続き、聖書本文の利用許諾も自分で運用・管理しています。
サービスのWebサイト公開デモ
デモを試す
公開デモアカウントで、アプリの主な画面をご覧いただけます。
ログイン手順
- App Storeからアプリをインストールします。会員アプリはGoogle Playからもインストールできます。
- ログイン画面で「데모 계정으로 로그인」（デモアカウントでログイン）を選択します。
- 下記のログインIDとパスワードを入力します。
おすすめの確認ポイント
- 感謝・黙想の記録を日付ごとに閲覧
- お知らせと予定を確認
公開デモアカウント
入力欄の内容を選択して、手動でコピーすることもできます。
複数の利用者で共有するサンプルデータです。他の利用者が内容を変更することがあり、変更内容が残る場合があります。個人情報や個人的な祈りの内容は入力しないでください。
アプリの画面
開発・検証用ビルドをデモデータで撮影した画面です。撮影日は各画像に記載しています。その後のApp Store版とは異なる場合があります。
スクリーンショットの出典
システムの構成
技術解説は2026年9月17日に確認したソースに基づきます。App Store版には、一部の変更がまだ含まれていない場合があります。
- 01React Native会員アプリ · React管理者Web · SwiftUI管理者アプリ
- 02認証と権限を確認するTypeScript API
- 03PostgreSQL · 非公開S3
会員アプリ、管理者Web、管理者アプリは同じバックエンドを共有しています。データベースの記録と利用許諾を得た聖書本文は、保存先とアクセス制御を分けています。
画面を支える設計判断
一時的な接続失敗からセッションを復元する
起動時に、一時的な接続失敗と無効な認証情報を区別します。通常の再取得では直前の有効な画面を維持し、アカウントや権限が変わった場合は古いデータを破棄して、遅れて届く応答も無効にします。
出欠の同時編集で競合を明確にする
出欠の保存時に想定バージョンを照合し、編集の競合を検出します。サーバーは処理用のロックを取得した後に権限を再確認し、記録・リビジョン・監査履歴をまとめて確定します。
最新の権限でデータを再取得する
リアルタイム通知は変更の発生だけを伝えます。実際の記録はAPIから取得し直すため、その時点の権限が適用されます。通知をまとめ、短いランダムな待ち時間を設けることで、重複したリクエストを抑えています。
UP-Dream
開発でのAI活用
AIとの働き方
- 要件は自分で決めます。ベータ版のフィードバックと運用で生じたニーズが出発点です。
- 範囲を決めます。変更してよい画面と、触れてはいけないロジックを先に定めます。
- 実装を任せます。範囲を定めたフロントエンドの実装と統合にClaude CodeとCodexを使います。
- 検証します。データと権限のルールに照らし、回帰テストとCIで確認します。
- AIが誤った箇所を記録し、自分で修正します。
- 難しい判断は任せません。アカウント、権限、同時実行、公開範囲は自分で決めます。
範囲を定めたフロントエンドの実装と統合作業にClaude CodeとCodexを活用しました。一般メンバー向け「信仰の庭」の更新では、Claude Codeが成長・ミッション画面の初期変更を担当し、Codexがホーム画面、共通テーマ、カレンダー、聖書閲覧の改善と統合時の確認を担当しました。
庭とミッションレターの静的なイラストはImageGenで制作しました。テキスト、ボタン、記録の表示、操作部分はReact Nativeの要素で実装しています。掲載画像は、それ以前の青年メンバー向け画面です。製品の要件と公開範囲は自分で決めています。
AIが誤った事例：管理者Webのアカウント統合
- 01状況
- 同じ青年部メンバーが異なるOAuth（例：KakaoとApple）でそれぞれログインし、アカウントが二つに分かれるケースが発生しました。このメンバーの在籍データにはすでに出席記録が蓄積されており、管理者Webで記録を失わずに統合する必要がありました。
- 02AIに任せた範囲
- 管理者Webのアカウント統合機能の実装をAIコーディングツールに任せました。
- 03何が失敗したか
- 同一人物と思われるアカウントを探すデータ探索までは動作しましたが、統合を実行してもアカウントはひとつにならず、出席記録が意図しないアカウントに残ってしまいました。
- 04原因
- AIの実装はOAuthアカウントを基準に、あるアカウントのデータを別のアカウントへ移す方式でした。しかし出席記録はログインアカウントではなく、在籍データに紐づいていました。データが実際にどこに紐づいているかを考慮していなかったため、アカウント情報だけが移り、出席記録は元の場所に残っていました。
- 05解決：基準軸を変える
- 統合の基準をログインアカウントから在籍データに移しました。在籍データを「一人の人物」を表す基準レコードとし、OAuthアカウントはその人物に紐づくログイン手段として統合しました。出席記録はもともと在籍データに紐づいているため、統合の過程で移動や書き換えが不要になりました。
- 06その後変えた作業方法
- アカウントや権限のように、一度誤ると元に戻しにくいコードは、AIが生成した結果をそのまま使わず、自分で修正・レビューしています。AIには範囲が明確な画面実装を任せ、データの同一性や権限に関わる判断は自分が担います。
聖書本文の利用許諾と配信
UP-Dreamで使用する韓国語聖書「개역개정」の著作権を確認し、利用許諾を得るための手続きを担当しました。プロジェクトのチェックリストには許諾の確認が記録されています。著作権はKorean Bible Societyに帰属し、関連書類は非公開で保管しています。
承認済みのメンバーに全66巻を提供しています。全文はアプリの配布物や公開リポジトリに含めず、非公開のAWS S3から認証付きAPIを通じて配信し、整合性を確認しています。アプリ内に著作権を表示し、アカウント別の一時キャッシュはログアウトやアカウント変更時に削除します。
技術解説コードと検証
技術解説には、ソースの責務分担、設計上の利点とコスト、日付を明記したテスト結果をまとめています。セッション復元、キャッシュの分離、同時書き込み、Androidの初回レイアウト時のクラッシュ修正などを扱っています。