ID:83950さん

# プロジェクト経験概要 東京都市大学大学院 医用工学専攻における修士研究 「経験的モード分解を中心とした信号解析による胃電気活動の抽出」の 実装コードを整理・リファクタリングしてGitHubで公開したリポジトリ。 本研究は**優秀研究賞**（東京都市大学大学院 医用工学専攻）を受賞し、 **IEEE EMBC 2019（ベルリン）ポスター発表**および **生体医工学誌への論文掲載**（筆頭著者）を達成した研究の実装。 - **GitHub：** https://github.com/MasahiroTatsuta/egg-signal-analysis - **論文：** 辰田昌洋ら, 生体医工学, Vol.57, No.6, pp.198-205, 2019 --- # チーム情報 - **研究担当**：自身1名（筆頭著者として研究・実装を主導） - **指導教員**：京相 雅樹 准教授（現在は教授）（東京都市大学） - **学会発表**：国内外合計10件（すべて筆頭著者） --- # 開発・実装内容A：EGG数理モデルの構築と妥当性評価 ## 【概要】 EGGに含まれる雑音除去法の性能評価において、実測EGGを用いた正確な評価は 胃電気活動成分と雑音成分の分離が困難であるという課題があった。 そのため、Van der Pol方程式を用いた**EGG数理モデル**を提案し、 実測EGGとの類似性を時間領域・周波数領域の両面から定量評価した。 ## 【どのような機能の開発・実装か】 - Van der Pol方程式（RK45法）による胃電気活動数値解の生成 - 振幅制御パラメータ（α, β）の最適化による実測EGG模擬信号の生成 - χ²検定による振幅分布適合率、パワースペクトルRMSEによる周波数分布誤差評価 - 被験者4名の実測EGGとの比較検証 - 使用ライブラリ：`numpy` / `scipy` / `matplotlib` ## 【課題・問題点】 - 実測EGGには他臓器由来のアーチファクトが混在しており、 雑音除去法の正確な性能評価に実測信号を直接使用することが不適切だった - 胃電気活動は約0.05 Hz・100 μVという極めて低周波・微弱な信号であり、 数理モデルでの再現が技術的に困難だった ## 【打ち手・使用した技術】 - Van der Pol方程式を差分方程式に変換し、RK45法で数値シミュレーションを実施 - 尖度差—ピークPSD差平面による2次元評価でパラメータ最適値を特定 - バンドパスフィルタ（0.02〜0.15 Hz）による前処理を組み合わせた評価パイプラインを構築 ## 【成果】 - 全被験者（4名）の実測EGGに類似する数値解を生成可能なパラメータ最適値 （α=290〜350, β=2）を特定し、数理モデルの妥当性を実証 - 振幅分布適合率80〜100%、パワースペクトルRMSE 0.24〜0.37を達成 --- # 開発・実装内容B：EEMDによる胃電気活動抽出とパラメータ最適化 ## 【概要】 従来のバンドパスフィルタ（BPF）・経験的モード分解（EMD）では除去困難だった 胃電気活動周波数帯に重畳するアーチファクトに対し、 アンサンブル経験的モード分解（EEMD）を適用。 **EEMDのAWGNパラメータ（AWGNL）を手動グリッド探索で最適化**し、 BPF・EMDとの性能比較を定量的に実施した。 ## 【どのような機能の開発・実装か】 - EMD・EEMDによるIMF/eIMF抽出パイプラインの実装 - AWGNL（-10〜40 dBの範囲、2 dBステップ）の系統的探索による最適値決定 - パワースペクトルRMSE・瞬時周波数時間推移RMSE・2chコヒーレンスによる多指標評価 - ヒルベルト変換による瞬時周波数時間推移（瞬時位相の定性的評価を含む） - 使用ライブラリ：`numpy` / `scipy` / `PyEMD` / `matplotlib` ## 【課題・問題点】 - EEMDのAWGNパラメータの最適化は従来研究では実施されておらず、 Pythonライブラリのデフォルト値（AWGNL=12 dB）の適切性が未検証だった - モードミキシング（複数IMF間での周波数混合）がEMDの主要課題であり、 EEMDによる改善効果の定量的実証が必要だった ## 【打ち手・使用した技術】 - AWGNL=0〜6 dBの範囲でRMSEが最小となることを13通りのEGG数値解で検証 - EGG数値解・実測EGG双方での評価により結果の再現性を確認 - ウィルコクソンの符号順位検定（p<0.05）による統計的有意性の検証 ## 【成果】 - **AWGNL=4 dBが最適**であることを実証し、ライブラリデフォルト値（12 dB）より 高い雑音除去性能を達成（パワースペクトル相対RMSE：EEMD 0.550 vs BPF 1.00） - 瞬時周波数時間推移においてもEEMDが最小の相対標準偏差を達成 （BPF比で約75%削減） - EGG信号解析へのEEMD適用は国内初の試みであり、 生体医工学誌掲載・IEEE EMBC 2019発表（ベルリン）により国際的に成果を発信 - 本リポジトリはGeminiを活用してモダンなAPIでリファクタリングし、 再現性を担保したサンプルデータとともに公開

# プロジェクト経験概要 南海電気鉄道との合同プロジェクトとして、鉄輪線路・踏切を有する私鉄初の GoA2.5自動運転システム（ATO装置）の新規製品開発に従事。 認証機関による安全性審査（機能安全規格準拠）の通過を目標とした、 ソフトウェア基本設計・機能仕様設計を担当。 --- # チーム情報 - **チーム規模**：約15名（PL・ハードウェア仕様設計・ソフトウェア設計・営業） - **ソフトウェア担当**：4名 - **自身の役割**：ソフトウェアグループのメンバーとして、ソフトウェア基本設計・機能仕様設計を担当 - 仕様書作成はチーム定例でのレビューを受けながら、**ドキュメント全体の約3/4を自身が単独で作成**。 残りの一部は課長と分担。 --- # 開発・実装内容A：ATO機能のソフトウェア機能仕様設計 ## 【概要】 GoA2.5に対応したATO装置のソフトウェア機能仕様を、 認証機関の安全審査通過を見据えて設計・文書化した。 ## 【どのような機能の開発・実装か】 - 出発制御・停止制御・速度照査ロジックのソフトウェア仕様定義 - 定位置停車（TASC）制御のブレーキパターン生成仕様 - 速度制御予測曲線の設計仕様（加減速プロファイル含む） - 上記仕様を実装する子会社・派遣エンジニアへの仕様書の提供 （コーディング自体はアウトソース、**自身は設計・仕様定義が主担当**） ## 【課題・問題点】 - 鉄輪線路・踏切を有する環境への GoA2.5適用は国内私鉄初であり、 参照できる前例・規格適用事例が乏しかった。 - 認証機関への提出物として、制御フローの根拠・安全性を 第三者が追跡可能な形で文書化する必要があった。 - 仕様書作成の大部分を自身が担うことになり、ドキュメント品質と 進捗管理を同時にこなす必要があった。 ## 【打ち手・使用した技術】 - Word・Excel・draw.io を使い分け、フローチャートと仕様表を組み合わせた 可読性の高い仕様書フォーマットを自身で構築 - 出発制御・停止制御の状態遷移をVisioで視覚化し、 認証機関・社内レビュー双方での合意形成コストを削減 - チーム定例でのレビューサイクルを活用し、仕様の抜け漏れを早期に検出 ## 【成果】 - 認証機関との合意形成プロセスを円滑化し、スケジュール遵守に貢献 （定量的な短縮数値は計測外だが、審査対応の手戻りを抑制） - 自身退職後もプロジェクトが継続・進行しており、審査プロセスが 完遂に向かっていることを確認（＝引き継ぎ品質の担保） - 国内私鉄初GoA2.5 ATO製品の仕様設計という希少な開発経験を取得

# プロジェクト経験概要 既存の鉄道信号装置から出力されるバイナリログデータを解析・可視化する Python製業務効率化ツールを**1人で設計・開発**。 品質管理部門の分析業務における手作業・VBAベースの非効率なフローを Pythonによる自動化に置き換えることを目的とした社内ツール開発。 --- # チーム情報 - **開発担当**：自身1名（実質的にすべての設計・実装を単独で担当） - **要件定義**：課長・品質管理部門の担当社員からヒアリングして要件を整理 - **レビュー**：定期的な進捗報告の場に、品管部門以外のハードウェア系部署や 技術系役員も参加（社内横断的な可視性のある開発だった） --- # 開発・実装内容A：バイナリログのパース・CSV変換機能 ## 【概要】 鉄道会社ごとに異なる独自フォーマットのバイナリログを読み込み、 分析可能なCSV形式に変換するパイプラインを実装。 ## 【どのような機能の開発・実装か】 - 各鉄道会社固有のバイナリフォーマットに対応したパース処理の実装 - 変換後データに対するエラーコード抽出・時系列ソートなどの条件付き整形 - 使用ライブラリ：`numpy` / `pandas` ## 【課題・問題点】 - 鉄道会社ごとにバイナリフォーマットが異なり、 単純な継承ベースの設計では対応しきれない構造だった - 既存フローはVBAや手作業によるグラフ化が中心で、 処理に多大な工数がかかっていた ## 【打ち手・使用した技術】 - 継承の代わりに**委譲（コンポジション）パターン**を採用し、 フォーマットの差異を柔軟に吸収できる設計を自身で考案・実装 - pandas による条件フィルタリング・整形処理を構築し、 手作業で行っていたデータ加工を自動化 ## 【成果】 - ログ解析〜CSV出力までの処理時間を、手作業比で**約1/10程度に短縮** （感覚値ベース。VBA・手動グラフ化と比較した工数削減） --- # 開発・実装内容B：GUIアプリケーション化・異常可視化グラフ出力機能 ## 【概要】 変換済みデータを基に異常を可視化するグラフを画像ファイルとして出力する機能を実装。 さらに、非エンジニアである利用者の要望に応えるため、 tkinterによるGUIアプリケーションとしてまとめ、exeファイルとして配布。 ## 【どのような機能の開発・実装か】 - 時系列データの異常箇所をハイライト表示するグラフを画像ファイル（PNG）として出力 - tkinter を用いたGUIを自身で設計・実装し、 コードを介さず操作できるデスクトップアプリケーションとして仕上げた - PyInstallerなどでexeファイル化し、Python環境のない端末でも動作可能な形で配布 - 使用ライブラリ：`matplotlib` / `scikit-learn` / `tkinter` ## 【課題・問題点】 - ツールの利用者はベテラン分析社員（非エンジニア）であり、 CLIやスクリプト実行ではなくGUI操作が必須要件だった - 「異常がひと目でわかる」という品管ニーズを技術的な仕様に落とし込む 必要があった ## 【打ち手・使用した技術】 - tkinter でファイル選択・実行・結果確認を一画面で完結できるGUIを設計 - matplotlib による時系列グラフを構築し、 閾値逸脱箇所を色分け・マーキングで自動ハイライト - 非エンジニア向けの操作マニュアルを別途作成し、 ツール導入後の問い合わせコストを低減 ## 【成果】 - 品質管理部門（約5名）に導入され、ログ分析の起点となるグラフ化作業を自動化 - Python・GUIの知識がない利用者でもexeをダブルクリックするだけで 使用できる形に仕上げ、現場への導入障壁を排除 - Pythonによるデータ処理の実例を社内で示したことで、 部署内でのPython活用への関心を高めるきっかけとなった

# プロジェクト経験概要 南海電鉄GoA2.5プロジェクトの業務の合間に、**自発的な技術探求として** 既存ATS装置の試験ログデータを用いたMLモデルによるTASC制御最適化のPoCを **1人で設計・実装**。 SIL4領域への現時点でのML適用は現実的でないと認識した上で、 「現状のMLモデルがどこまで制御パラメータを再現できるか」を検証することが目的。 --- # チーム情報 - **担当**：自身1名（業務の空き時間を活用した自主的な取り組み） - 進捗報告のみ課長へ実施 --- # 開発・実装内容A：データ前処理・特徴量エンジニアリング ## 【概要】 南海電鉄ATS装置から出力される試験ログデータを分析基盤として整備し、 MLモデルへの入力に適した形に変換。 ## 【どのような機能の開発・実装か】 - 入力データ：速度・加速度・勾配の時系列データ（0.1秒刻み）、 閉塞区間名コード・駅区間コードなどの質的変数を含む多変数ログ - 相関分析による特徴量選択（制御パラメータへの寄与度が低い変数を除外） - 時系列データと質的変数を分離して前処理パイプラインを構築 - 使用ライブラリ：`numpy` / `pandas` / `scikit-learn` ## 【課題・問題点】 - 時系列的な連続性を持つセンサーデータと、 カテゴリカルな区間コード類が混在しており、 単一モデルでの扱いが困難だった ## 【打ち手・使用した技術】 - 相関分析で説明力の低い特徴量を事前に除外し、 モデルへの不要なノイズを低減 - 時系列・質的変数の性質の違いに応じてモデルを分離する方針を自身で設計 ## 【成果】 - 分析基盤として再利用可能なデータ前処理パイプラインを構築 --- # 開発・実装内容B：LSTM×LightGBMハイブリッドモデルの構築・評価 ## 【概要】 TASC制御最適化を最終目標として、まず速度予測をその中間ステップに位置づけ、 時系列モデル（LSTM）と勾配ブースティング（LightGBM）を組み合わせた ハイブリッドモデルを構築。Jupyter Notebookで評価・説明資料を作成。 ## 【どのような機能の開発・実装か】 - **目的変数**：0.1秒後（次ステップ）の車両速度（時系列回帰タスクとして定式化） - 予測速度列からTASC制御への必要ノッチ段数を逆算するアプローチを想定し、 速度予測をその中間ステップとして位置づけ - **LSTM**：速度・加速度・勾配の時系列データから次ステップの速度を予測 - **LightGBM**：閉塞区間・駅区間などの質的変数から速度予測への寄与を学習 - 両モデルの出力を統合する構成を自身で設計 - パラメータチューニング：グリッドサーチ・Optunaを併用 - 使用ライブラリ：`PyTorch` / `LightGBM` / `Optuna` / `scikit-learn` ## 【課題・問題点】 - 対象領域はSIL4（最高安全水準）であり、 MLモデルの出力を実システムに適用することは現実的でない - 前例となる研究・適用事例がほぼ存在せず、 モデル設計の判断を自身で下す必要があった ## 【打ち手・使用した技術】 - 実用化ではなく「現状のMLモデルがどこまで制御を再現できるか」という 検証目的に絞ることで、SIL4制約の中でも技術的な知見を得られる スコープを自身で設定 - グリッドサーチで粗い探索を行った後、Optunaで効率的な ハイパーパラメータ探索を実施 ## 【成果】 - TASC制御パラメータの傾向をMLモデルがある程度再現できることを確認 - 一方で、SIL4領域における説明可能性・保証の困難さという **MLの現実的な限界を技術的に把握**できた - 成果をJupyter Notebookにまとめ、社内への技術共有資料として提出 - 本PoCを通じてLSTM・LightGBM・Optunaの実務的な適用経験を獲得

# プロジェクト経験概要 SIGNATEの糖尿病発症予測コンペに参加し、 **Intermediateランクへの昇格**を達成。 8つの医療特徴量から糖尿病発症を予測する二値分類タスク。 --- # 使用技術 `Python` / `LightGBM` / `Optuna` / `AutoFeat` / `PyCaret` / `scikit-learn` --- # 工夫した点 医療データ特有の**ゼロインフレーション問題**に対処した。 `Insulin=0`などは実際のゼロではなく欠損を意味するため、 ゼロ以外のサブセットに対してKNN補完を適用することで ドメインを意識した前処理を実施（AUC約+0.008向上）。 また比較用ベースラインとしてPyCaret AutoMLを併用し、 LightGBM＋Optunaによる手動チューニングが AutoMLを上回ることを実験的に確認した。 --- # 成果 | 手法 | CV AUC | |---|---| | LightGBM ベースライン | 0.768 | | + KNN補完 | 0.779 | | + AutoFeat特徴量 | 0.791 | | + Optunaチューニング＋閾値最適化 | **0.797** | - SIGNATEランク：**Intermediate**へ昇格 - PyCaret（AUC 0.782）に対してLightGBM＋Optunaが上回ることを実証

# プロジェクト経験概要 SIGNATE Cup（SOTA Challenge）の旅行パッケージ購入予測コンペに参加。 顧客属性・営業接触データから購入有無を予測する二値分類タスク。 --- # 使用技術 `Python` / `LightGBM` / `CatBoost` / `Optuna` / `UMAP` / `AutoFeat` / `scikit-learn` --- # 工夫した点 通常は次元削減・可視化用途として使われるUMAPを、 **密度埋め込み座標を数値特徴量として追加入力する用途に転用**した。 densMAP=Trueにより局所密度情報を保持しながら、 n_neighbors（15/20/25/30）を探索して最適値（n=20）を特定。 これにより通常の表形式特徴量だけでは表現できない顧客セグメントの 多様体構造をモデルに学習させることができた。 また、AutoFeatによる多項式交差特徴量生成（約300個）に対して 相関フィルタリング（特徴量間|r|<0.9・目的変数との|r|>0.01）を適用し、 有用な特徴量約40個に絞り込んだ。 --- # 成果 | 手法 | CV AUC | |---|---| | LightGBM ベースライン | 0.698 | | + AutoFeat特徴量 | 0.721 | | + UMAP密度埋め込み | 0.736 | | + Optunaチューニング | **0.743** | - UMAP密度埋め込みの追加単体でAUC +0.015を達成 - UMAPを特徴量エンジニアリングに応用するアプローチを自ら考案・実装

# プロジェクト経験概要 GoのWebSocket処理性能をリアルタイム同期アプリケーションで検証することを目的に、 複数ユーザーが同時編集可能なリアルタイム共同作業カンボードアプリ **FlowDeck**を個人開発・本番デプロイ。 ポートフォリオとして、モダンなフルスタック構成を一人で設計・実装した。 - **GitHub：** https://github.com/MasahiroTatsuta/flowdeck - **デプロイURL：** https://flow-deck-gold.vercel.app/ --- # チーム情報 - **開発担当**：自身1名 - **期間**：集中開発（短期間でMVPをリリースすることを意識した開発） --- # 開発・実装内容A：Go/GinによるWebSocketサーバー・REST API設計 ## 【概要】 リアルタイム同期のコアとなるWebSocketサーバーをGoで実装。 複数ユーザーの同時接続・イベント配信を処理するバックエンドを設計・構築した。 ## 【どのような機能の開発・実装か】 - Go/Ginによる認証（JWT）・プロジェクト/タスク管理REST APIの実装 - WebSocket接続マネージャーの実装（ルーム管理・ブロードキャスト制御） - Upstash Redis Pub/Subを用いたタスク更新・カード移動・ユーザー参加退出 イベントの非同期配信 - DockerコンテナでNorthflankにデプロイし、スリープなしの常時起動を実現 ## 【課題・問題点】 - WebSocket経由のJSON通信において、フロントエンドとの データ構造の不一致によりイベントが正常に流れない問題が発生 - RenderはWebSocket常時接続との相性が悪く（スリープによる切断）、 無料枠で安定稼働できるホスティング先の選定が必要だった ## 【打ち手・使用した技術】 - GoとNext.js間のWebSocket通信で送受信するJSONの スキーマを明示的に定義し直すことで通信の安定化を実現 - Northflankを採用することでDockerコンテナの常時起動を確保し、 WebSocket接続の安定性を担保 - 使用技術：`Go` / `Gin` / `WebSocket` / `JWT` / `Docker` / `Northflank` ## 【成果】 - 複数ユーザーの同時接続によるリアルタイムイベント配信をミリ秒単位で実現 - Goの並行処理（goroutine）によるWebSocket処理性能を実証 --- # 開発・実装内容B：Next.js フロントエンド・インフラ設計 ## 【概要】 Next.js（App Router）を用いたフロントエンドを実装し、 マルチクラウド構成（Vercel / Northflank / Neon / Upstash）で本番デプロイ。 ## 【どのような機能の開発・実装か】 - Next.js（React）によるカンボードUIの実装（SSG/SSR併用） - Vercel Edge Networkによる高速静的配信 - Neon（サーバーレスPostgreSQL）によるユーザー・プロジェクト・タスク情報の永続化 - Upstash Redis Pub/Subによるリアルタイムイベント中継の設計 ## 【課題・問題点】 - フロントエンド（Vercel）・バックエンド（Northflank）・DB（Neon）・ キャッシュ（Upstash）をそれぞれ別サービスで運用するマルチクラウド構成において、 各サービス間の接続設定と環境変数管理が複雑化した ## 【打ち手・使用した技術】 - 各サービスの役割を明確に分離し、接続情報を環境変数で一元管理することで 構成の見通しを確保 - WebSocketのリアルタイム接続とHTTPS APIリクエストを適切に使い分ける フロントエンド設計を実装 - 使用技術：`Next.js` / `TypeScript` / `Vercel` / `Neon(PostgreSQL)` / `Upstash Redis` ## 【成果】 - フロントエンド・バックエンド・DB・リアルタイム通信基盤を すべて無料枠のマルチクラウド構成で本番稼働させることに成功 - Go/Gin + Next.js + Redis Pub/Subという モダンなリアルタイムアプリケーションのフルスタック実装経験を取得

# プロジェクト経験概要 MLエンジニアとして必要なTransformerアーキテクチャの実践習得を目的に、 工場設備の音響異常検知AIシステム**Factory Anomaly Detection**を個人開発・本番デプロイ。 MIMII Dataset（バルブ音響データ）を使用し、 ResNet18（CNN）とViT-Tiny（Vision Transformer）の完全対照実験を実施することで モデルアーキテクチャの構造的優位性を定量的に実証した。 - **GitHub：** https://github.com/MasahiroTatsuta/factory-anomaly-detection - **本番デモ：** https://masaroo-factory-anomaly-detection.hf.space/ --- # チーム情報 - **開発担当**：自身1名 - **期間**：約1週間（集中開発） --- # 開発・実装内容A：音響データ前処理・特徴量設計パイプライン ## 【概要】 極限ノイズ環境（SNR -6 dB）下での異常検知を実現するため、 生音声波形からメルスペクトログラムへの変換とMin-Max正規化を組み合わせた 前処理パイプラインを設計・実装した。 ## 【どのような機能の開発・実装か】 - Kaggle APIによるMIMIIデータセット（バルブ音響）のダウンロード・整備 - librosaによる音声→メルスペクトログラム変換 （STFT → power_to_dbによる対数変換でエネルギー変化を強調） - Min-Max正規化による動的スケーリング（勾配安定化のためのブレイクスルー） - 異常比率11.5%のクラス不均衡に対する損失関数の重み付け（異常ペナルティ7.7倍） - 使用ライブラリ：`librosa` / `numpy` / `PyTorch` ## 【課題・問題点】 - SNR -6 dBという極限ノイズ環境下で、マシンの個体差（ドメインシフト）が モデルの汎化性能を大きく損なう可能性があった - 異常データが全体の11.5%しかなく、単純な学習では正常サンプルへの 多数派バイアスが生じる ## 【打ち手・使用した技術】 - 対数メルスペクトログラムにMin-Max正規化を適用することで マシン個体差による振幅ばらつきを吸収し、モデル入力の品質を均一化 - CrossEntropyLoss（weight）で異常サンプルの損失を7.7倍に引き上げ、 クラス不均衡を構造的に補正 ## 【成果】 - 前処理パイプラインの設計がモデル性能の主要因となることを実証 （正規化なしでは精度が大幅に低下） --- # 開発・実装内容B：ResNet18 vs ViT-Tiny 完全対照実験・本番デプロイ ## 【概要】 単一モデルの精度追求ではなく、**完全同一条件下での対照実験**により CNNとVision Transformerの構造的差異を定量的に実証。 FastAPI + Streamlit + Dockerで本番システムとしてHugging Face Spacesにデプロイした。 ## 【どのような機能の開発・実装か】 - **ResNet18（Baseline CNN）**：局所特徴学習ベースのベースライン - **ViT-Tiny（提案手法）**：timmライブラリを使用、Self-Attentionによる スペクトログラム全体のグローバルパターン学習 - Stratified 3-Fold CVによるC-index最大化・AdamWオプティマイザ統一適用 - FastAPI（推論ロジック）とStreamlit（UI）を疎結合設計で分離 - DockerコンテナでHugging Face Spacesにデプロイ（CPU専用ランタイム最適化） - Lifespan起動時のtimm固有接頭辞（`vit.`）自動検知・重みキーマッピング機構を実装 - 使用技術：`PyTorch` / `timm` / `FastAPI` / `Streamlit` / `Docker` / `Hugging Face Spaces` ## 【課題・問題点】 - MLエンジニアとしての説得力を高めるには、精度を出すだけでなく 「なぜそのアーキテクチャが有効か」を定量的に示す必要があった - Colabで学習したモデル重みをHugging Face Spaces上のFastAPIで ロードする際、timmの名前空間キーの不一致によりエラーが発生した ## 【打ち手・使用した技術】 - 完全同一条件（同一損失関数・同一オプティマイザ・同一エポック）で ResNet18とViT-Tinyを競わせる対照実験を設計し、 アーキテクチャ起因の性能差を純粋に抽出 - Lifespan起動時に重みキーの接頭辞を自動検知・動的マッピングする ロバストなロード機構を自身で実装し、環境差異を吸収 ## 【成果】 | モデル | Accuracy | Recall（異常検知率） | ROC-AUC | |---|---|---|---| | ResNet18（Baseline） | 74.0% | 62.0% | 0.906 | | ViT-Tiny（提案手法） | **97.6%** | **96.7%** | **0.997** | - ViT-TinyのSelf-Attention機構が、CNNでは捉えられない ドメインをまたいだ異常の本質的パターンを学習することを定量的に実証 - FastAPI / Streamlit / Dockerによるプロダクトレベルの MLOpsエンドツーエンド実装経験を取得 - CPU専用ランタイムで動作する超軽量推論システムとして Hugging Face Spacesに本番デプロイ済み・現在稼働中

# プロジェクト経験概要 「誰が解約するか」ではなく「いつ解約するか」を予測する 生存分析×機械学習×BIダッシュボードを統合したデータサイエンスプロジェクト。 BigQuery公開データセット（thelook_ecommerce / 57,174名）を用いて、 認知行動的特徴量エンジニアリング・統計的因果推論・XGBoostによる非線形予測・ TableauによるリアルタイムアラートまでのE2Eパイプラインを1人で構築した。 - **GitHub：** https://github.com/MasahiroTatsuta/Neuro-Behavioral_Churn_Prediction__Subscription_Survival_Cockpit - **W&B実験ログ：** https://wandb.ai/tcumepapam3d2-personal-project/neuro-behavioral-churn-pipeline/ - **Tableauダッシュボード：** https://public.tableau.com/app/profile/masahiro.tatsuta/viz/Neuro-BehavioralChurnPredictionSubscriptionSurvivalCockpit/1 --- # チーム情報 - **開発担当**：自身1名 - **期間**：約1週間 --- # 開発・実装内容A：BigQuery SQLによる特徴量マート構築 ## 【概要】 BigQuery公開データセット（thelook_ecommerce）から、 初回購入後30日以内の行動ログをウィンドウ関数・CTEを駆使して集計し、 **認知行動的な観点から設計した独自特徴量マート**（57,174レコード）を構築した。 ## 【どのような機能の開発・実装か】 - CTE（共通テーブル式）8段構成のBigQuery SQLによる特徴量マート構築 - LAG/LEADウィンドウ関数によるセッション間隔・画面遷移密度の算出 - 生存分析ターゲット（tenure_days / is_churned）の定義 （最終アクティビティから90日以上経過＝解約） - 発達障害研究の知見を応用した認知行動プロキシ特徴量の独自設計 | 特徴量 | 内容 | |---|---| | first_day_burnout_ratio | 初日消費額÷30日総消費額（衝動性プロキシ） | | context_switch_density_mean | 画面遷移数÷滞在時間（注意散漫プロキシ） | | cart_add_velocity_mean | 商品閲覧→カート投入の平均秒数 | | session_interval_volatility_30d | セッション間隔の標準偏差（先延ばし傾向） | | cancel_return_rate_30d | キャンセル・返品率（後悔行動プロキシ） | | midnight_purchase_ratio | 深夜購入比率（衝動性プロキシ） | ## 【課題・問題点】 - ウィンドウ関数（LAG）をCTE内で直接ネストすると BigQueryでエラーが発生するため、段階的なCTE分解が必要だった - 静的属性（年齢・流入チャネル）だけでは入会後の行動変容を捉えられず、 解約の予兆を先行的に検知できなかった ## 【打ち手・使用した技術】 - LAGを含む集計を独立したCTE（session_intervals）に切り出すことで ネスト問題を回避し、クエリの安定稼働を実現 - 発達障害研究（ADHD特性）の知見を着想源に、 購買行動データから認知行動的特徴量を独自設計 - 使用技術：`BigQuery` / `SQL`（ウィンドウ関数・CTE・SAFE_DIVIDE） ## 【成果】 - 57,174名規模の特徴量マートを単一SQLで構築 - first_day_burnout_ratioが解約リスク上昇に最も強く寄与することを後続分析で確認 --- # 開発・実装内容B：Cox比例ハザードモデル×XGBoost生存分析・MLOpsパイプライン ## 【概要】 統計的因果推論（Cox比例ハザードモデル）で特徴量の因果構造を検証した上で、 XGBoost（survival:cox）による非線形予測を実施。 Weights & Biasesで実験を管理し、Tableauでリアルタイム解約アラートを実装した。 ## 【どのような機能の開発・実装か】 - VIFによる多重共線性検証・L2リッジ正則化付きCox比例ハザードモデルによる因果推論 - Kaplan-Meier生存曲線・Log-rank検定による群間差の統計的有意性検証 - XGBoost（objective=survival:cox）+ Stratified 3-Fold CV + Optunaによる ハイパーパラメータ最適化 - Weights & Biasesによる全実験履歴のトレーサビリティ管理 - Tableauによる解約アラートダッシュボード（スコア75%以上の顧客リスト自動抽出） - 使用技術：`Python` / `XGBoost` / `lifelines` / `Optuna` / `Weights & Biases` / `BigQuery` / `Tableau` ## 【課題・問題点】 - 従来の2値分類モデルでは「いつ解約するか」という時間軸が欠如しており、 LTV計算や介入タイミングの最適化が困難だった - first_day_burnout_ratioのVIFが15.76と高く、 多重共線性がCoxモデルの係数推定を不安定にする懸念があった ## 【打ち手・使用した技術】 - 生存分析（Cox + XGBoost survival:cox）を採用することで 「解約確率」ではなく「解約までの時間」を予測可能な構造に転換 - penalizer=0.1のL2リッジ正則化をCoxモデルに適用し、 多重共線性下でも安定した係数推定を実現 ## 【成果】 - **C-index：0.8732**（実務利用水準0.7を大きく上回る予測性能） - first_day_burnout_ratio（Hazard Ratio 1.61）が解約リスクを61%上昇させることを 因果推論・特徴量重要度の両面で一致して確認 - Cox因果推論とXGBoost予測の結果が一致したことで、 モデルの信頼性と解釈可能性を同時に担保 - W&B実験ログ・Tableauダッシュボードによる 再現性・可視化まで含めたE2Eパイプラインを構築