© Findy Inc. 2025.08.20 すごくすごい。フロントエンドミートアップ AI疲れに効く、 フロントエンドのワークフロー整備 1 甲斐 和基 ファインディ株式会社 フロントエンドエンジニア @karukan029 

© Findy Inc. ファインディが展開するエンジニアプラットフォーム サービス紹介 ToC / ToB 正社員エンジニアの採⽤ 約12万⼈のエンジニアと880社以上のテッ ク企業をマッチング。 マッチングサービス フリーランスエンジニアの採⽤ 5万⼈以上のフリーランスエンジニアの成 功報酬型の⼈材紹介サービス。 外国籍エンジニアの採⽤ インドを中⼼とした海外のハイスキルエン ジニアと⽇本企業をマッチング。 SaaS / ToB エンジニア組織の⾒える化 GitHubやJiraを解析し、エンジニア組織の ⾒える化と⽣産性向上をサポート。 組織分析SaaS ToC / ToB 開発ツールのレビューサイト 実際に利⽤している企業の声を元に、開発 ツールの導⼊や検討に必要な情報を集約。 企業の技術選定をサポート。 開発ツールメディア ※ 各種数値は、2024年6月時点のFindy転職、Findy Freelance、Findy Team+、Findy Globalの4サービスの累計での社数及び登録者数です。 
 　 なお、1社又は1名の方が複数のサービスに登録している場合は、そのサービスの数に応じて複数のカウントをしています。 β版 2 

© Findy Inc. 3 AI疲れしていませんか？ 

© Findy Inc. 4 AI疲れしていませんか？ ● AIがコード書いてもいいけど散らかさないで ○ コードを書くという楽しい部分をAIがやっている ○ こちらが想定しているレベルのコードを出⼒してくれるまで四苦⼋苦 ● AIが⽣成したものが正しいか最終的に評価するのは⼈ ○ 読まないといけないものが汚いと⼈が⾟い ● AIに好き勝⼿させないための仕組みの整備が重要 ○ 機械的にチェックできるものは仕組みでカバーしたい ○ 守りと⾼速化を両⽴したい 

© Findy Inc. 5 AI疲れしていませんか？ ● 前提 ○ ⽣成AIを活⽤するために新たに環境整備した話ではありません ○ 今まで実施していた環境整備の取り組みの内、⽣成AI活⽤するようになって特に役⽴っているも のを紹介しています 

© Findy Inc. 6 守りと⾼速化を両⽴するための ワークフロー 

© Findy Inc. 7 「守り」の仕組み 

© Findy Inc. 「守り」の仕組み 8 ● 静的解析 ● ⾃動テスト ● フィーチャーフラグ 

© Findy Inc. 静的解析 9 TypeScript ● 型チェックによる静的解析 ESLint‧Stylelint ● コード解析によってルールに沿ったコードであることを静的解析 Prettier ● コードをルールに沿ってフォーマット pre-commitのタイミングでチェック、コードを⾃動修正 ● ルールに従ったコードのみコミット ● 不要なCIの実⾏を防ぐ 

© Findy Inc. 静的解析 10 モジュール境界の強制 ● Findy Team+のフロントエンドは、Nxを使⽤したモノレポ構成になっている ○ Nx：モノレポやアプリケーションのビルド、テストの実⾏、コード⽣成などの機能を備えた統合 的なツール ○ 内部に100以上のモジュールを持つモノレポ構成であり、複雑性が⾼い ■ 循環参照（循環依存）が発⽣しないよう注意する必要がある ● Nxが提供している @nx/enforce-module-boundaries ルールで制御 ○ プロジェクトの設定でタグを指定することができる ○ プロジェクトに設定したタグに依存可能なタグを定義することで、依存の⽅向性を定義すること ができる 

© Findy Inc. 静的解析 11 設定の例 libs/components (type:ui) → libs/utils (type:util) の依存は許可され、逆⽅向の依存は許可されない 

© Findy Inc. 12 ⾃動テスト ● Unit、Integration テスト ○ Vitest ○ Testing Library ● E2Eテスト ○ Playwright ● VRT（Visual Regression Testing） ○ storycap+reg-suit ○ UIコンポーネントの意図しない⾒た⽬の変化を⾃動検知 

© Findy Inc. 13 ⾃動テスト ● 期待する振る舞いをテストコードで保証する ○ AIは仕様があっているか判断するためにもテストコードは重要 ■ 期待値を明確にできる ■ テストが失敗する=仕様通りでないとAIが判断できる ● 修正時の影響範囲を予測しやすくする ○ 影響あればテストコードが落ちる ○ テストがちゃんとしていればコードの質が⾼くなくてもマージしても問題ない 

© Findy Inc. 14 フィーチャーフラグ ● コードを書き換えることなく特定の機能を有効化‧無効化できる仕組み ● ユーザーに影響がでないように本番環境にコードを反映することができる ○ 開発途中の状態のコードもデプロイできる ○ コンフリクトが発⽣しづらくなる ○ ⽣成AIの活⽤により、Pull Request数が増加するとマージする回数も増加するため、コンフリク トが発⽣しづらくなるメリットをより享受しやすくなる 

© Findy Inc. 15 「守り」の⾼速化 

© Findy Inc. 16 キャッシュ活⽤によるCIの⾼速化 Nxのキャッシュ活⽤によるCIの⾼速化 ● 変更があったプロジェクトと依存関係のあるプロジェクトのみをCIの対象にする ○ 依存関係がないプロジェクトはスキップする ○ 依存関係が⼩さいPRほどCIが早く終わる ○ PRを適切な粒度に保つことがCIの⾼速化にも結びつく構成 ● 依存関係を適切に整理し、アーキテクチャをメンテナンスすることでキャッシュの恩恵を最⼤限受ける ことができる ○ キャッシュをうまく活⽤できるようにプロジェクトの構成も継続的に改善している 

© Findy Inc. 17 CI環境の最適化 負荷に合わせてスペックを最適化 ● GitHub Actionsのrunnerのスペックを最適化する ○ 依存するプロジェクト数に応じて、Larger runnerを使⽤ ■ 負荷が⾼い時だけスペックを上げる ● 現在のGitHub Actionsには、変更の規模や負荷に応じて動的にランナーを切り替える機能がない ○ Nxを使⽤して、影響を受けるプロジェクトの数を取得 ○ プロジェクト数に応じてランナーを切り替える 

© Findy Inc. 18 CI環境の最適化 負荷に合わせてスペックを最適化 

© Findy Inc. 19 まとめ 

© Findy Inc. 20 まとめ ● これらの取り組みは元々、品質を保ちながらスピード感を持って開発するための取り組み ○ 今までの積み重ねの結果が、AIと協業するための⼟台となっている ● ⽣成AIを活⽤するために整備するというより、今までと変わらず品質の⾼いコードを安全に⾼速にリ リースし続けるための環境整備が重要 ○ 品質を保ちながら⾼速にリリースできる環境整備は、⼈にとってもAIにとっても重要 

© Findy Inc. 21 ご清聴ありがとうございました