ID:83519さん

## プロジェクト概要 マーケティング施策で利用する機械学習モデルの運用基盤において、Vertex AIのメモリ上限がボトルネックとなりジョブ失敗が発生していた課題を解消するため、BigQuery ML(BQML)への移行を主導。推論処理をBigQuery側の計算リソースで完結させる構成へ再設計した。 ## チーム情報 - 自身：データエンジニア／リーダー - チーム規模：全4名 - 期間：2025年12月〜現在 - 連携：データサイエンティスト（既存モデルの提供元） ## 開発・実装内容 【概要】 Vertex AIで運用していた推論基盤を、メモリ上限に依存しにくいBQMLベースの構成へ移行。学習〜推論フローをBigQuery上で完結させるアーキテクチャを自身が設計・実装。 【課題・問題点】 データサイエンティストが作成したモデルをVertex AI Pipelinesに組み込み、定期推論を実行していたが、学習時に大量データをメモリ上へ読み込む設計だったため、データ量の増加とともにメモリ上限がボトルネックとなり、処理の途中でジョブが失敗する状態になっていた。 【打ち手・使用した技術】 既存構成の課題を整理したうえで、Vertex AIとBQMLの機能差分・コスト・運用負荷を比較評価し、推論処理をBigQueryの計算リソースで完結させる移行方針を策定。ローカルメモリに依存する処理をBQMLへ寄せることで、メモリ上限に縛られないアーキテクチャへ再設計した。パイプラインにはDataformを採用し、モデル学習・推論フローをSQLベースで実装・運用できる形に落とし込んだ。

## プロジェクト経験概要 BigQueryのコスト・スロット・クエリ状況の把握が特定メンバーのExcel管理に依存しており、定例時にしか閲覧できず集計工数も発生していた課題を解消するため、Lookerを用いた可視化ダッシュボードを構築。チームへのドキュメントも整備し、運用体制を確立した。 ## チーム情報 - 自身：データエンジニア（要件定義〜運用まで1人で担当） - 期間：2026年1月〜2026年3月（3ヶ月） ## 開発・実装内容 【概要】 BigQueryの利用状況（コスト・スロット消費・クエリ問題）をプロジェクト別・ユーザー別に可視化するLookerダッシュボードを自身が設計・構築。 【課題・問題点】 利用状況の集計は特定メンバーが管理するExcelで行われており、定例会議の場でしか閲覧できない状態だった。集計作業にも定期的な工数がかかっており、コスト増加や問題のあるクエリをリアルタイムで検知できなかった。 【打ち手・使用した技術】 `INFORMATION_SCHEMA.JOBS_BY_*`を基にBigQueryでコスト・スロット・クエリ実行状況を集計するビューを作成し、LookerのデータソースとしてBigQueryに接続。各GCPプロジェクト別・ユーザー別のコスト推移を時系列で確認できるダッシュボードを構築し、誰でもいつでもブラウザから参照できるようにした。特にユーザーごとのコスト遷移を可視化することで、高コストクエリの発生源を個人単位で特定できる設計とした。

## プロジェクト経験概要 社内規定の新設に伴い、個人情報保護法への対応として、BigQuery上のデータレイヤー全体をリアーキテクチャ。個人情報の分類基準、仮名加工処理の実装方針、アクセス制御の設計を主導し、実装フェーズへの移行まで推進した。 ## チーム情報 - 自身：データエンジニア兼プロジェクトマネージャ（設計・調整の主担当） - 関連部署：コンプライアンス部・法務部・IT部（各部署の担当者と個別調整） - 期間：6ヶ月以内 ## 開発・実装内容 【概要】 個人情報・仮名加工情報などの情報重要度区分に対応したBigQueryのデータセット構造やポリシーを設計。 【課題・問題点】 既存のデータレイヤーでは個人情報と非個人情報が同一データセットに混在しており、保護が必要なデータの特定・管理が困難な状態だった。また、法務・コンプライアンス部との共通認識がなく、どのデータが規制対象になるかの判断基準も曖昧だった。 【打ち手・使用した技術】 自身が主導して個人情報の分類定義ドキュメントを作成し、コンプライアンス部など複数部門と合意形成。その分類に基づき、BigQueryのデータセットをレイヤー（生データ・仮名加工済み）と個人情報区分の2軸で再設計した。分析用途でのデータ活用を止めずに、個人情報を含むデータを安全に扱うため、個人情報区分ごとにデータセットを分離し、利用者の権限に応じて参照可能範囲を制御できるようにした。

## プロジェクト概要 Dataformのワークフローを複数環境・複数バージョンで管理するためのリリースアプリケーションをPythonで開発。GitLabのタグをトリガーにバージョン管理とデプロイを自動化し、手動リリース作業の属人化を解消した。 ## チーム情報 - 自身：データエンジニア（設計・実装・ドキュメント整備の主担当） - チームメンバー：複数名（運用引き継ぎ対象） - 期間：3ヶ月以内 ## 開発・実装内容 【概要】 GitLabタグをトリガーに、対象環境・バージョンに応じたDataformワークフローを自動デプロイするPythonアプリケーションを自身が主担当として開発。 【課題・問題点】 複数環境に複数バージョンのワークフローが混在しており、どの環境にどのバージョンをデプロイするかの判断とオペレーションが手動・属人的になっていた。デプロイミスのリスクと運用負荷が問題だった。 【打ち手・使用した技術】 GitLabのタグ命名規則からデプロイ先環境とバージョンを解析するロジックをPythonで実装。Dataform APIを呼び出してワークフローのコンパイル設定を環境変数ごとに切り替え、対象環境へデプロイする仕組みを構築した。

## プロジェクト概要 クエリ増加によるBigQueryのコスト・パフォーマンス悪化を受け、利用状況を定量的に把握するためのログ収集・集計基盤をDataform＋BigQueryで構築。標準では6ヶ月までしか参照できないクエリログを長期保持できる設計とし、複数プロジェクトにまたがる横断分析と長期トレンドの把握を可能にした。 # チーム情報 - 自身：データエンジニア担当（要件定義〜運用まで主担当） - 期間：3ヶ月以内 ## 開発・実装内容 【概要】 BigQueryの`INFORMATION_SCHEMA.JOBS_BY_*`ビューのデータを定期的にスナップショットとして保存し、6ヶ月超の長期保持を実現するテーブルを構築。 【課題・問題点】 `INFORMATION_SCHEMA.JOBS_BY_*`ビューは標準で過去180日分しか参照できないため、四半期・年次での傾向分析や季節変動の把握ができなかった。また、ビューへの直接クエリはスキャン量が多くコストが高い問題もあった。 【打ち手・使用した技術】 Dataformのワークフローで日次バッチを組み、`JOBS_BY_PROJECT`から必要なカラムを抽出してスナップショットテーブルに追記する設計を自身が実装。パーティションとクラスタリングを設定してクエリコストを最適化した。

# プロジェクト経験概要 データカタログツールの導入に向けて、Google Data CatalogとInformatica CDGCの比較評価・PoCを実施。機能・運用性の観点から評価し、Informatica CDGCを選定。BigQueryのデータ修正フローに対応した登録手順を標準化し、メタデータ管理の属人化解消を図った。 # チーム情報 - 自身：メンバー（PoC・比較評価・ドキュメント整備の担当） - 期間：半年以内 # 開発・実装内容A：ツール比較評価とPoC 【概要】 Google Data CatalogとInformatica CDGCを対象に、導入目的に照らした比較評価とPoC検証を自身がメンバーとして実施。 【課題・問題点】 データ定義やテーブルの仕様がドキュメント化されておらず、分析担当者がテーブルの意味・用途を把握するために都度エンジニアへ確認が必要な状態だった。データカタログ導入によるセルフサービス化を目指したが、ツールの選定基準が定まっていなかった。 【打ち手・使用した技術】 評価軸として①BigQueryとのメタデータ自動収集②検索性・UI③API連携の柔軟性④運用コストを設定し、両ツールで実際にBigQueryのデータセットを連携させるPoCを実施。自動収集できるメタデータの範囲、手動登録が必要な項目、検索UXの差異を比較し、評価結果をまとめてステークホルダーへ報告した。

## プロジェクト経験概要 従来のBigQuery上のSQL変換処理はクエリ間の依存関係が明示されず、実行順序の管理が属人化し、障害時のリトライ範囲特定も困難だった。GCP環境へのDataform導入を通じてELT処理の依存関係を管理し、保守性・信頼性を向上させた。要件定義から運用整備まで一貫してリードした。 ## チーム情報 - 自身：プロジェクトリーダー - メンバー4名 - 期間：半年以内 # 開発・実装内容 【概要】 3ツールを比較評価し、主導してDataformを選定。 【課題・問題点】 セキュリティ要件・チームの学習コストを満たすツールを選ぶ必要があったが、選定基準が定義されていなかった。また、テーブル同士の依存関係を定義できていなかった。 【打ち手・使用した技術】 Dataformは無料・SQLで開発できる点で他ツールより優位と判断し選定した。他ツールは追加コストや同一命名テーブル・ビューの作成が難しい点で除外した。

不良品検出を行う外観検査のためのデータパイプライン構築（PoC）を実施。仕様設計・要件定義から開発・テストまでを行い、主にプロジェクトマネジメント、バックエンド、インフラを担当。学習データと機械学習モデルのアップロード機能やモデルの再学習の自動化を構築した。

AIプロジェクトの実行ノウハウや開発したモジュール、学習用データなどを流通可能かつ拡張可能にするAIコラボレーション開発プラットフォームの新規構築に参画。追加開発フェーズにおいてバックエンド（Rails）、フロントエンド（Next.js）、AWSインフラを担当し、EC2の選定や負荷試験を実施。Terraformでインフラをコード管理し複数環境へのデプロイを可能にしたほか、Dockerを用いて動的に数百の環境を作成する機能を追加した。