実績

EU DSA、EU TCOR、UK OSA、NY S895、ブラジルECA、インドIT Rulesなど、増加する規制の波がそれぞれ詳細かつ一貫性のあるローカライズ済み透明性レポートを要求しています。Robloxの従来のアプローチは手動であり、規制の増加に伴うスケールが困難でした。

• 7以上の国際規制に関する透明性レポートの戦略立案と製造をリード。
• 反復可能かつ監査可能なレポーティングサイクルのため、バージョン管理されたモジュラーなプロダクショングレードSQLクエリ群を執筆。
• 外部監査に先立ってシステムをスケールアップ・将来対応させるため、Product Compliance統合データモデルと自動レポーティングパイプラインを設計中。
• チームの生産性向上と手動工数削減のためのAI活用イニシアチブをリード中。

10以上の規制コンプライアンス要件（レポート、RFI、リスク評価、訴訟対応）に対応するプロダクショングレードのSQLとPythonを構築するには、通常1サイクルあたり3〜6週間のエンジニアリング工数を要していました。急速に拡大する規制ポートフォリオと少数精鋭のチーム体制では、そのペースは現実的ではありませんでした。

• Cursorエージェントを用いた人間介在型（Human-in-the-Loop）のAIコーディングワークフローにおいて、PMかつ第一起草者として主導。
• 10以上の規制要件にわたって7,000行以上のプロダクションコード（SQL + Python）を生成。データエンジニアとデータサイエンティストは主要執筆者ではなくコードレビュアーとして参画。
• 構造化された開発パイプラインを設計：クエリ・スキーマコンテキスト → AIによるSQL生成 → 人間によるコードレビュー・承認 → 反復的改善 → 本番Pythonパイプライン構築。
• PMとエンジニアリングのフィードバックループを短縮し、迅速なイテレーションを実現するとともに、クロスファンクショナルなスケジュール調整のボトルネックを解消。

Privacy Sandbox Working Group（エンジニア・PM・コンプライアンス担当者900名以上）は、アクセス制限されたリポジトリに散在する12,000件以上の文書に埋もれていました。情報検索が深刻なボトルネックとなり、開発・規制対応・戦略立案を遅滞させていましたが、コーパスの機密性から汎用検索ツールの利用は不可能でした。

• v1・v2設計文書の単独執筆者として、構想から動作プロトタイプまでを主導。
• 組織横断でステークホルダーにヒアリングしてペインポイントを診断し、エンドツーエンドのシステムを設計：Webフロントエンド、Agent Studioによるバックエンド、LLMにGemini 2.5 Pro、12,000件以上の文書をインデックスしたベクターデータベース。
• 2つの動作モードを実装：（1）コーパスに基づく出典付きRAG専門Q&A、（2）ユーザーが提供した変更説明からD&I Criteria Assessmentの初稿を自動生成するコンプライアンスワークフロー特化モード。
• システムプロンプトの執筆、技術要件・アクセス制御・リスク軽減策（幻覚対策、必須人間レビューなど）の定義。
• Privacy Sandbox TPgM AIハッカソンにてプレゼン。上級ディレクターより「時間節約と規制対応品質向上における潜在的インパクトを解放した」としてスポットボーナスを受賞。

Privacy Sandbox法務チームは、毎週数時間をかけてバグレポートとリンク先文書を手動で精査し、法的レビューダイジェストを作成していました。このプロセスは低速・不安定であり、Privacy Sandbox全体のコンプライアンス監視のボトルネックとなっていました。

• エンドツーエンド自動化ソリューションの単独執筆者兼開発者。
• 法務チームとの直接対話を通じてワークフロー・判断基準・各サブチームの「質の高いアウトプット」の定義を把握。
• 3段階パイプラインを設計：SQL（F1）で関連バグデータを抽出 → Python（Colab）でオーケストレーション → TextMiner経由でGemini LLMが処理。
• 複雑な認知タスクを実行する多段階プロンプトを構築：リンク先文書の要約、CMA規制コミットメントに対する主要リスクの特定、法務3サブチーム（Product・Competition・Privacy）それぞれに対するレビュー種別（「レビュー必須」vs「FYI参照」）の分類。

英国競争・市場局（CMA）との法的コミットメントに基づく義務的成果物である四半期Monitoring Trustee（MT）コンプライアンスレポートは、手動で作成されていました。このプロセスは四半期あたり60〜80人時間を要し、高リスク・エラー多発・非文書化の状態で、5〜6人の属人的な単一障害点に依存していました。監査可能性もなく、主要指標の日次把握もできない状況でした。

• 単独執筆者兼実装者。当初このプロジェクトをスコープした3名のSWEは、ソフトウェアエンジニアにしか構築できないと考えており、TPMが挑戦することに懐疑的でした。
• エンドツーエンドのシステムアーキテクチャを設計：複数の社内データソース（Teamgraph、生システムログ、非標準インポート）からデータを取得するETLパイプライン、複雑なデータ処理、LLMエンリッチメント、自動レポート生成。
• 3つのワーキンググループ（PSWG・NWG・AWG）にわたってデータを抽出・処理・エンリッチするSQL群を実行するPLXワークフローを設計。動的なレポーティング期間算出とGoogle Sheetsへのエクスポートも実装。
• 保守性・監査可能性・単一障害点の排除のため、バージョン管理とモジュラーなクエリ設計を実装。
• 主要な国際祝日をまたぎながらスケジュール前倒しで納品。

重大なコンプライアンスギャップが存在していました：Privacy Sandbox組織（500名超）の従業員がGoogleのCMAコミットメント上の基本要件であるPrivacy Sandbox Working Group（PSWG）に未加入の状態でした。非コンプライアント者を特定・通知・追跡する自動メカニズムは存在していませんでした。

• コンプライアンスギャップを自発的に特定――完全な自己主導であり、アサインされた業務ではありませんでした。
• SQLを用いて従業員のレポーティングチェーンとPSWGグループメンバーシップデータをクロスリファレンスする自動検知システムを設計。
• 非コンプライアント者とその上司に自動でメール通知し、解消まで追跡するAppsScript通知システムを構築。

Legal Content Policy & Standardsチームは、ケース管理とトレンド分析のために数千件の法的削除申請の要点を迅速に把握する必要がありました。この規模での手動レビューは不可能であり、自動ケース要約は主要管理ダッシュボードへの機能追加要望のトップでしたが、スケーラブルな解決策は存在していませんでした。

• 設計文書・ユーザーガイドの執筆者、および完全自動ワークフローの主実装者。
• LCPSチームと直接協議し、要件を定義するとともに、ケース要約が業務でどのように活用されるかのニュアンスを把握。
• SQLMinerを用いてデータベース環境内で直接大規模LLM推論を実行する革新的なパイプラインを設計――機密性の高いケースデータを中間システムに書き出すことなく、真に産業規模の運用を実現。
• ケーステーブルの構造化データをLLMに供給するRAGパターンのプロンプトを構築し、すべての対象ケースにわたって簡潔・正確・一貫した書式のサマリーを生成。
• AIサマリーをチームの主要PLX管理ダッシュボードにオンデマンド機能として直接表示。

法務オペレーションチームは法的削除申請を手動で処理していました――複数の社内ツールにわたるケースバイケースのレビューが必要なワークフローです。8,400件以上のケースバックログが蓄積し、継続的な件数（数万件）の規模では、ヘッドカウントに見合った手動処理が不可能な状況でした。

• 8,400件以上のケースからなる即時バックログを処理するnode.js PoC自動化スクリプトを構築し、完全なソリューションへ投資する前にアプローチの有効性を実証。
• ブラウザ自動化で法的削除申請を大規模に処理するプロダクション用Chrome拡張機能の開発をリード――従来は手動操作を要していたマルチツールワークフローを自動化。
• エンジニアリングチームと連携し、PoCからプロダクション対応ツールへと昇華。
• シニアPMから納品速度とチーム稼働能力への貢献の両方で高く評価。