プロジェクト概要
TikTok のオンライン広告における海外グロース事業ラインを支える、大規模なエンタープライズ向け Monorepo フロントエンドプロジェクトです。メディアアセット管理、財務精算、サプライヤー調達、データダッシュボードなど複数の業務領域をカバーしています。統一された技術アーキテクチャとエンジニアリング規約を採用し、複数の業務サブシステムの協調開発と独立デプロイを支えており、50+ のサブプロジェクト、100 万行規模のコードを管理しています。
私が担当するモジュールは 2 つのサブシステムにまたがっています。財務精算(契約管理、見積もり、精算書)と広告調達(要件の提出、承認フロー、評価タスク、広告調達フロー)です。
主な貢献
Web Worker によるマルチスレッド CSV 検証
CSV のフォーマット検証はもともとフロントエンドのメインスレッドで行われており、データ量が多いと UI が固まることがよくあった。Web Worker によるマルチスレッド計算の仕組みを導入して検証処理を別スレッドに移し、社内の Armor フレームワークで Web Worker を使う際の互換性の制約(Blob URL、Comlink、Module Worker)を解消。検証ルールは Yup + Regex で構築した Schema を採用し、再利用可能な共通ユーティリティとして抽象化。
この設計により、10 万件のデータで UI のフリーズ時間を 90% 削減
関数キャッシュユーティリティによるレンダリング性能の最適化
プロジェクトでは大規模フォームの開発を効率化するため、社内開発のフォームレンダリングエンジンを使用していた。このエンジンにはフォーム内容を抽象化した JS object を渡す必要があり、その中にはフォームの各フィールドを連動させる onChange などの関数も含まれる。
このエンジンの大きな性能上の欠陥は、フォームをレンダリングするたびに schema 全体を計算し直すことだった。フォームの内容が多く、しかも array 型の場合にはこの欠陥の弊害が顕著に増幅され、目に見える影響として UI 操作が固まり、フォームの生成を長時間待たされていた。
この問題を解決するため、
cache/cacheManyという 2 つの小さなユーティリティ関数を作成。React のuseMemoにならい、計算結果を Map にキャッシュする、または渡された引数を key として複数の Map に保存する仕組み。この小さな工夫とその他の一般的な最適化手法を組み合わせ、ページネーションなしで一度に 500 個のフォーム UI をレンダリングする画面で、Total Blocking Time (TBT) を 98% 削減
技術的なポイント
- 01
複雑なフォームインタラクションコンポーネントの開発
社内開発の JSON Schema 動的フォームレンダリングソリューションをベースに、カスケード選択、動的フィールド、条件付き表示などの複雑なケースを含む業務フォームのインタラクションコンポーネントを多数開発。設定駆動のフォームレンダリングを実現し、複雑な検証ルールとフィールド連動ロジックに対応
- 02
高精度な数値計算処理
財務や見積もりなどの業務シーンにおける JavaScript の浮動小数点精度の問題に対し、浮動小数点の精度計算の仕組みを実装
- 03
マイクロフロントエンドの統合
社内開発のフレームワークでサブアプリケーションの動的読み込みを実現し、業務モジュールのオンデマンド読み込みと独立した開発・デプロイに対応
- 04
国際化・多言語対応
社内開発のオンライン翻訳プラットフォームを通じて runtime に最新の翻訳ファイルを取得し、多言語対応と動的な更新を実現
- 05
LLM による契約書 AI 検証機能の開発
フルスタックの AI 検証システムを構築。マルチモーダルな大規模言語モデルで契約書を解析し、動的なルールに照らして 1 項目ずつ検証したうえで、提出をブロックするかどうかを判断。主なポイント:ルールはオンラインの設定プラットフォームで管理し、コードを変更せずにいつでも追加・変更・無効化が可能。ルールは強制ブロックと警告のみの 2 種類に分かれ、AI が高い確信度で不合格と判断した場合にのみブロックを発動。ユーザーは説明を記入して強制ブロックを却下でき、システムは結果を監査用に記録。DB 照会の Tool Call を実装し、SQL フィルター層で読み取り専用を担保したうえで、ルールに応じてモデルがシステムのデータを自由に取得できるようにした。ドキュメントを Markdown に変換する MCP を組み込み、PDF、Word、Excel などさまざまな形式の契約書をモデルが統一的に処理できるようにした
成果:毎週 6–7 件の契約書を検証し、毎月約 5 人日(person-day)の工数を削減
精度とコーパス:当初、モデルは構造の異なる契約書をうまく識別できなかった。そこで、よくある構造の契約書(誤りのある契約書の例と正しい契約書の例を含む)をコーパスに追加し、どのような記述がどのルールに対応することが多いかをモデルに示したことで、判断精度が徐々に向上。現在も最適化を継続中
評価(eval):prompt を変更する際は上記のコーパスでテストし、合格した場合のみリリース。社内開発で社内利用は無料のモデル(Doubao)を使用しており、モデルを変更したことはなく、金銭的コストを考慮する必要はない
追跡(tracing):モデルとの毎回の対話内容は Go でオンラインのログシステムに書き込まれ、そこから判断の根拠を追跡可能
レイテンシー対策:モデルのレイテンシーに対応するため、契約書の提出を同期処理から非同期処理に変更。ユーザーは提出後、平均約 5 分で通知を受け取り、ページに戻って結果を確認