ID:61887さん

## プロジェクト概要 - 重複した組織データの統合と、重複を生んでいた登録フローの刷新を一つのプロジェクトとして実施。 ## 技術スタック - PHP, Laravel／TypeScript, React - Node.js, Python／MySQL 8.0 - 法人番号API, Auth0, OpenSearch／AWS（RDS, SNS/SQS） ## 背景・課題 - 約3,000行の組織データのうち957行が同名の余剰レコード。同じ会社でも別組織となり、同僚をチャットに招待できない問題があった。 - 管理機能に統合処理は存在したが、統合対象の検出は手動だった。 ## 自分の役割と行動 - 法人番号APIによる候補照合と個別調査を実施。確定できない対象は除外し、CSレビュー済みリストのみ統合。 - 組織IDを持つテーブルと付け替え処理を突き合わせ、実データのある対応漏れを修正。検知テストをCIに追加。 - dry-runを既定とし、RDSスナップショットを取得。認証APIの負荷見積もり・ALBタイムアウトを計画に反映し、実行後は組織・アーカイブ・ユーザー件数を照合。 - 仮登録状態と既存組織への合流導線を設計・実装。データ統合後に入口を切り替え、登録経路を一本化。 ## 成果 - 重複していた約1,400組織を約500組織に集約。 - 統合処理の対応漏れをCIで検知し、登録フローを既存組織への合流を基本とする形へ変更。 ## 振り返り 既存データの修正と入口の変更を並行して進めた。実装の対応範囲だけでなく、負荷やタイムアウトなど実行計画の前提を検証する重要性を学んだ。

## プロジェクト概要 - 顧客のターゲット・USP（独自の強み）・ペルソナを分析し、ウェビナーのテーマと方針を提案。 - USP分析・競合調査・戦略設計の3段構成のワークフロー。 ## 技術スタック - OpenAI API, Mastra - TypeScript, Express - Langfuse（トレーシング） ## 背景・課題 - テーマ設計が顧客のノウハウに依存し、人手での分析から提案までに工数がかかっていた。 - 生成結果の評価基準と、出力の原因を後から追跡できる仕組みが必要だった。 ## 自分の役割と行動 - 実装担当者と仕様・方針を決定。自分は出力評価と品質改善を担当。 - マーケティング知見を持つ事業責任者へ早期から出力を共有し、フィードバックを反復的に収集。 - 指摘をプロンプト・参照データ・ワークフロー実行順の問題に切り分け、改善に反映。 - Langfuseのトレースをチームで整備し、プロンプト・入力コンテキスト・各エージェント出力を原因分析に活用。ルート単位のサンプリング率調整で観測コストにも対応。 ## 成果 - 顧客別のウェビナー方針を生成し、分析・提案業務を支援する機能を構築。 - 専門知識を持つ評価者のレビューとトレースを組み合わせ、出力の原因分析・改善を行える状態を整備。 ## 振り返り 評価者を早期に巻き込むことの重要性を学んだ。現時点ではトレーシングと人による評価・改善を実施しており、評価データセットと自動評価による回帰テストは今後の課題。