-
人材会社・SES企業向けAI学習プラットフォームを企画から公開まで単独で構築
【背景】
AIを導入したものの社内で使われないまま止まる、という課題に対して、学習と定着を支援するプラットフォームを構築しました。
【体制と役割】
体制は1名です。企画、画面設計、データベース設計、実装、独自ドメインでの公開まで単独で担当しています。
【実施したこと】
・学習コンテンツの管理と配信
・受講状況の管理
・認証と権限に応じた表示の出し分け
【最も苦労した点と、どう乗り越えたか】
教材を並べるだけでは使われない、という点です。
誰がどこまで進んだかを追える構成にし、学習が止まっていることに気づける形にしました。
【補足】
生成AIを実装に取り入れて構築しています。出力をそのまま使うのではなく、動作・表示・権限を確認したうえで反映しています。企画 / 画面設計 / データベース設計 / 権限設計（Row Level Security）/ React・TypeScript実装 / Supabase / 独自ドメインでの公開 / 生成AIを活用した実装
-
飲食店向けの勤怠・シフト管理システムを設計から本番公開まで単独で構築
【背景】
飲食店の現場業務が紙とチャットに分散しており、シフト調整と勤怠集計に毎月まとまった時間がかかっていました。
【体制と役割】
体制は1名です。要件の整理、画面設計、データベース設計、実装、公開まで単独で担当しました。規模は約36,000行です。
【実施したこと】
・スタッフ管理と採用フローの管理
・シフトの作成、希望収集、調整
・勤怠の打刻と集計
・権限に応じた表示の出し分け
【最も苦労した点と、どう乗り越えたか】
使うのが現場のスタッフであることです。機能を増やすと使われなくなるため、操作の分かりやすさを優先し、画面を絞りました。
また管理者と一般スタッフで見える情報を分け、権限の判定を画面側ではなくデータベース側で担保しました。画面だけで隠すと、直接アクセスされたときに防げないためです。
【補足】
生成AIを実装に取り入れて構築しています。出力をそのまま使うのではなく、動作・表示・権限を確認したうえで反映しています。要件整理 / 画面設計 / データベース設計 / 権限設計（Row Level Security）/ React・TypeScript実装 / Supabase / Vercel公開 / 生成AIを活用した実装
-
複数事業の数字を1画面に集約する経営ダッシュボードを単独で構築
【背景】
複数事業の売上・経費・Web流入・営業状況が社内に分散しており、月末まで着地が見えない状態でした。
【体制と役割】
体制は1名です。企画、画面設計、データベース設計、実装、外部API連携、本番公開まで単独で担当しました。
【実施したこと】
・事業別の売上・支出・利益の可視化
・Google Analytics Data API と Search Console API を接続し、流入・検索キーワードを自動取得
・数値変化に対する分析文を OpenAI API で生成
・営業ファネル（送信→返信→商談→提案→成約）の実数表示
【最も苦労した点と、どう乗り越えたか】
「未接続」と「実績ゼロ」の取り違えです。
データが繋がっていない指標を 0 と表示すると、「本当に0円だったのか」「データが無いだけなのか」を後から区別できず、経営判断を誤らせます。
そこで未接続の指標は 0 ではなく「—」で表示し、コード側にも架空の数値を置かない方針にしました。
また当初は財務数値をソースコードに記述していましたが、ビルド後のJSファイルから読み取れる状態であることに気づき、データベース側へ移して Row Level Security で経営層のみに限定しました。
【結果】
複数事業の数字と1画面で確認できる状態になり、営業システムの実績とも連携しています。
【補足】
生成AIを実装に取り入れて構築しています。出力をそのまま使うのではなく、動作・表示・権限を確認したうえで反映しています。要件整理 / 画面設計 / データベース設計 / 権限設計（Row Level Security）/ React・TypeScript実装 / Supabase / Google Analytics Data API / Search Console API / OpenAI API / Vercel公開 / 生成AIを活用した実装
-
自社の営業活動を一元化する営業管理システムを企画から本番公開まで単独で構築
【背景】
営業先がExcelに分散し、誰にいつ送ったかを追えない状態でした。同じ会社に二重で送るリスクと、配信停止を依頼された宛先へ再送してしまうリスクを抱えていました。
【体制と役割】
体制は1名です。企画、画面設計、データベース設計、実装、データ移行、本番公開、運用手順の文書化まですべて単独で担当しました。
【実施したこと】
・営業先管理、メール下書き生成、テンプレート管理
・営業先の承認とメール本文の承認を分けた二重承認フロー
・宛先や本文を変更すると承認が自動的に失効する仕組み
・送信キューと1分間隔の自動送信、送信履歴とKPI集計
・CSVからの営業先一括取り込み（重複判定・入力検証つき）
【最も苦労した点と、どう乗り越えたか】
誤送信の防止です。営業メールは一度誤った宛先へ送ると取り返しがつきません。
そこで、送信できる条件を14項目に分解し、1つでも欠ければ送信されない構成にしました。さらに送信可否の判定を、データベース・Google Apps Script・Edge Functionの3層に分散させています。どこか1つでも無効なら、たとえ承認済みでも送信されません。
全テーブルでRow Level Securityを有効化し、組織単位でデータを分離しました。広告・宣伝メールに義務づけられた表示（送信者名称・住所・受信拒否の通知先・問い合わせ先）が本文から欠落しない仕組みも入れています。
【データ移行】
Excelで管理していた過去の接触履歴591件、配信停止60件、営業先19件を、重複と表記ゆれを監査・分類したうえで移行しました。
【結果】
本番公開後、実際に自社の営業メール送信に使用しています。送信・承認・履歴・KPIが1画面で完結する状態になりました。
【補足】
生成AIを実装に取り入れて構築しています。出力をそのまま使うのではなく、動作・表示・権限まわりを確認したうえで反映しています。要件整理 / 画面設計 / データベース設計 / 権限設計（Row Level Security）/ React・TypeScript実装 / Supabase / Google Apps Script / 外部API連携 / Excelからのデータ移行 / Vercel公開 / 生成AIを活用した実装