CIのテスト実行時間改善をClaude Codeに任せて30%時間短縮

GenAI・LLM Claude GitHub Actions

こんにちは、ファインディでソフトウェアエンジニアをしているnipe0324です。

この記事は、ファインディエンジニア #1 Advent Calendar 2025の13日目の記事です。 adventar.org

コーディングエージェントを使う中で、実装は早くなる一方CIが遅いと思うことはないでしょうか？

かくいう私も、Claude Codeを使って並列にプルリクエストを作る中で「CI遅いなー」と思うことがよくありました。

CIの実行時間を短くしたいという気持ちはありつつ、メインの開発があるのでなかなか改善に手をだせませんでした。

しかし、2025年はAIエージェント元年。

せっかくなら、「Claude Codeに任せられるだけ任せてみよう！」と思い、CIのテスト実行時間の削減を任せてみました。

Claude Codeに「方針検討」「対応・効果測定」を任せ、私は意思決定とレビューに注力することで、メインのタスクがありながらも、CIのテスト実行時間を約2分短縮できました。

この記事では、具体的な内容を交えながら、Claude CodeにCI速度改善の方針検討と対応・効果測定を任せた事例をご紹介します。

CIのテスト実行時間が7分から5分に短縮

Claude CodeによるCI高速化の改善結果は次のとおりです。

CIでのテスト実行時間が7分から5分になり、約2分短縮できました。

対応前 対応後 改善
7分01秒 5分05秒 -116秒 (-28%)

たかが2分の短縮と思うかもしれませんが、1日50-60回ぐらい実行されているので1日2時間、月の営業日を20日とすると月40時間になるので、月5営業日分の待ち時間が削減できました。

今回Claude Codeに実施してもらった改善は次の4つです。


  1. 並列マシンへのテスト割当をファイルサイズベースから実行時間ベースに変更（60秒短縮）
    • テストファイルごとの実行時間の偏りが大きかったので平準化
  2. 不要なジョブを削除（27秒短縮）
    • 影響のないジョブがクリティカルパスに存在していたので削除
  3. aptでインストールしているライブラリのキャッシュ（25秒短縮）
    • 毎回インストールして30秒ぐらいかかっていたのをキャッシュすることで2-3秒に短縮
  4. テスト用のDBダンプのキャッシュ（55秒短縮）
    • 並列実行のためDBスキーマ作成とシードデータ登録に1分弱かかっていたが、キャッシュ化で20秒前後に削減

Claude CodeにCIの高速化を任せていく

CIのテスト実行時間の短縮のため、Claude Codeに「調査依頼」、「改善案の実施と効果測定」、「結果のとりまとめ」をそれぞれ任せていきました。

ファインディでは、CI/CDにGitHub Actionsを使っています。

GitHub Actionsでは、CIのワークフローの詳細な実行時間やログがあり、また、ghコマンドでそれらの情報が取得できるため、AIエージェントが自律的に改善・効果測定をできる環境が整っていました。

結果として、CI高速化はAIエージェントにとても任せやすいタスクだと感じました。

調査依頼

調査依頼では次のようなプロンプトで調査依頼をしました。

# プロンプトイメージ
CIが7分と遅いので、5分以内にしたい。改善案を検討してください。
CIの実行結果: https://github.com/Findy/Xxxxx/actions/runs/1234567890

CIの実行結果を確認し、現状分析と改善提案をしてくれました。

Claude Codeの調査結果イメージ（一部省略）

これまでもCI高速化を何度かしてきて改善余地が少なくなっている中でも、改善効果がありそうな改善案を6つほど提案してくれました。

クリティカルパスを利用した分析や削減効果と対応工数による優先度付けなど基本を押さえた分析と提案をするのですごいな！と思いました。

実際Claude Codeに改善案を対応してもらう中で一部想定と違うこともありましたが、適宜結果を確認して方向を微修正することで結果として実行時間短縮につながりました。

改善と効果測定

アイデアとして有望そうに見えますが、実際に試して効果を測定するまでわかりません。

そのため、Claude Codeに改善と効果測定を実施してもらいました。

# プロンプトイメージ
https://github.com/Findy/Xxxxxx/issues/12345 の
「parallel_tests実行時間ベース分配」の対応を実施してください。

PR作成後にCIの実行時間を確認し、PRボディに見込みと実績を表形式で記載する。

Claude Codeが作成したPRイメージ

Claude Codeがghコマンドを使うことで、GitHub Actionsの各ジョブやステップの実行時間や状況を知ることができるため、自律的に改善を任せることができました。

また、必要に応じてプロンプトに「CIが失敗したら成功するまで対応する」「改善結果が見込みに届かない場合、原因分析して追加改善をする」などの指示を追加して自律性を高めました。

結果の取りまとめ

CIのテスト実行時間を短縮できたため、結果の取りまとめもClaude Codeに依頼しました。

# プロンプトイメージ
https://github.com/Findy/Xxxxx/issues/12345 の対応が
一通り終わったので結果をとりまとめたい

- 対応前後でのCIのテストの実行時間の比較
  - 表形式で、サンプル数、中央値、平均値をだす
  - 対応前は 2025-12-05 と 対応後は 2025-12-10 のデータを集計
  - 1分以内のタスクはテストがスキップされているので除外する
- やったことの概要
  - 箇条書きでシンプルに記載
- 結果をシンプルにまとめ、イシューにコメントをする

Claude Codeのイシュー対応結果のまとめイメージ

数字があっているのか若干気になりましたが、確認してみると細部は少し怪しいものの、実際にCIの実行履歴を目検で眺めてみると概ねあってそうでした。

まとめ

今回は、Claude CodeにCIのテスト実行時間の改善を丸っと任せることができました。

その結果として、自分はメインのタスクをしながらも、テスト実行時間を7分から5分に短縮できました。

個人的にClaude Codeにうまく任せることができたポイントとしては、「Claude Code自身がPDCAを実施したこと」と 「影響範囲や制約が少ない領域だったこと」 だと考えています。

  • ゴールが明確で、エージェント自身がPDCAを実施
    • CIの実行時間を7分から5分に削減とゴール明確で測定可能
    • エージェントが直接CIの実行時間やログを確認できるため、改善後の効果測定や原因分析が自律的にできる
  • 影響範囲や制約が少ない領域
    • 改善に失敗しても、CIのテストが失敗するだけで影響範囲が限定的
    • 制約もワークフローの実行時間、保守性、コスト、セキュリティぐらいで少ない

以上、参考になったら嬉しいです。

CIの実行時間が気になる方は、ぜひAIエージェントに任せてみてはいかがでしょうか。

最後に、現在Findyでは「うちのAIがやらかしまして」というAIとの試行錯誤の結果をシェアする期間限定企画をやっています。

「AIエージェント活用しているぞ！」という方は、ぜひのぞいてみてください。

findy-code.io

AIが書き、人が読む時代、読書がスキルになる

GenAI・LLM

はじめに

こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（TENTEN11055）です。
この記事は、ファインディエンジニア Advent Calendar 2025の11日目の記事です。

今年11月、AWS が主催する AI-DLC Unicorn Gym に参加しました。

AI-DLCの成果発表の様子 AWS主催 Unicorn Gym 最終日の成果プレゼンの様子

このプログラムの開発プロセスはAIと共に歩む仕様駆動開発。
部分的なAI活用から一歩進んだ開発体験を得ることができ、同時に「今後はより読解力が求められる」と感じました。

この記事では読書習慣がなぜスキルになるのか、自分の体験をもとに書いています。

AI-DLC（AI駆動開発ライフサイクル）とは

これまで開発の一部にAIを用いるケースが多く、その真価を発揮しきれないなどの課題がありました。
AI-DLCでは要件、ユーザーストーリー、設計、開発の全てをAIベースで行います。
そして人間の役割は監視、つまりレビューです。
作業の一切をAIに任せ、人間はそれを監視して品質を担保しながら素早く成果物を提供できるというものです。

AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築

AI-DLCにおけるレビュー負荷

AI-DLCでは実装前に多くのドキュメントを作成します。
そのため最も時間を使ったのは「文章を読み、AIの意図を正しく理解すること」 でした。

AIの文章は論理的ですが、人間が読みやすいかどうかでは最適化されていません。
ときには矛盾を見抜き、ときには曖昧な記述を解釈して補う必要があります。

AI-DLCではこのドキュメントレビューの質がそのまま品質に影響します。
こうした経験から、「読む力」を鍛える必要性を強く感じました。

読書を始めてみた

というのも、自身も普段の仕事で読解力に課題を感じており、対策として半年前から読書習慣を続けてきた背景があったからです。

  • 文章の理解に時間がかかる
  • 一行戻って読み直す回数が多い
  • 説明を聞き返すことが増えた

こうしたものを少しでも解消したくて、「読む力」を鍛える目的で始めました。

理解力がある人の特徴

読書を続ける中で、「理解力の高い人とは何が違うのか？」を意識して観察するようになりました。
理解力の高い人は、次の点が際立っています。

  • 説明の意図を素早く理解できる
  • 情報の本質を捉えられる
  • そのため発言や判断が的確になる

そしてこうした人たちは例外なく読書量が多い印象です。

「読む」と「理解」は別

こうして観察と実体験を重ねるうちに、読む行為と理解する行為は別の能力だと改めて実感しました

「それはそう」と言われてしまいそうですが、これを同時に行うトレーニングをできるのが読書のすごいところ。

以前に比べて本を読むのが早くなり、それは先に読んだ文章を理解しながら次の文章を読み進めているからだと気づきました。
また、文章全体を読みながら「重要な部分だけ自然と拾える感覚」も少しずつ身についてきました。

人間が監視する時代、読書がどう活きるか

ここで話を AI-DLC に戻すと、この手法は前述の通り多くのドキュメントを作成します。 つまり「読む力」「本質をつかむ力」がそのまま成果物の質に跳ね返ってきます。

今回のワークショップで実施したドキュメント数は次の通り。

  • Inception（要件、ストーリー整理、 ユニット変換）
    • 12ドキュメント
  • Construction（ドメインモデル設計、フェーズの定義など、そして開発）
    • 3ユニット、計18ドキュメント

合計30のドキュメントをレビュー後、コード生成に入るのです（そしてコードレビューへ...）。
そんな丸一日ドキュメントを眺める際に重要だったのは次の点です。

  • 文章を短時間で理解できる力
  • AIが生成した成果物の意図や本質を汲み取る力
  • 論理を追う集中力

これらは全て読書で鍛えることができます。
私も本当にまだまだですが、ワーク中「読書しててよかった〜」と思いました。

まとめ

AIに何かを生成してもらうのはもはや当たり前の時代になりました。
人間の価値は「作業」から「確認と意思決定」に比重が移りつつあるように感じます。

AI は体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。これが重要なのは人間だけが情報に基づいた選択を行うために必要なビジネス要件の文脈的理解と知識を持つからです。 （AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 より）

読書はそんな時代においても開発の手助けとなり、基礎体力になります。
で、どんな本がおすすめかというと何でもいいと思います。
技術書、ビジネス書、小説でも十分トレーニングになります。
私は最近ザ・ロイヤルファミリーという競馬が舞台の小説を読んでいました。
おすすめです。ドラマもおすすめ。

AI時代は基礎知識や読解力など、アナログ(？)なスキルが求められているかもしれませんね。

ファインディでは一緒に働くメンバーを募集中です！
よかったら覗いてみてください。 herp.careers

GenAI Enablementチーム立ち上げ初年度の振り返り

GenAI・LLM

はじめに

こんにちは、GenAI Enablementチームです。

この記事はファインディエンジニア #3 Advent Calendar 2025の9日目の記事です。

今年1月に「GenAI Enablementチーム」を立ち上げてから現在までの約1年間における活動を総括します。

チーム組成から今日に至るまで、どのような課題に直面し、それらをどう解決して成果に繋げてきたのか。その過程で得られた「理想と現実」のギャップや、具体的な成果・反省点について詳述します。

今後、自社でのGenAI活用推進を担う方々にとって、実践的なヒントとなれば幸いです。

今月から、沢山のアドベントカレンダー記事が執筆される予定ですので、年末のお供に是非読んでみてください。

adventar.org

GenAI Enablementチームって？

まず簡単に、チームのご紹介から。

ファインディにはプロダクトマネジメント室直下にGenAI Enablementチームという、その名の通り全社のデータ生成AIを含む広義のAI活用を推進し実装する、データサイエンティストの専門部隊が存在します。

今でこそメンバー5名体制（兼務を含む）になりましたが、立ち上げ当初（2025年1月）はマネージャーと、入社したばかりのメンバー1名、計2名からのスタートでした。

チーム誕生の背景

会社として、2024年を通じて自社の事業やプロダクトに生成AIを組み込むことは、もはや『あったらいいな』ではなく、企業の生存確率を高めるための『必然』であるという確信に変わったからです。

プロダクトマネジメント室という部署にこのチームが置かれたのも、単なる業務効率化だけでなく、プロダクトの競争力強化に直結させるため。

そんなミッションを背負い、チームが発足しました。

【社内活用】プロダクト使い方Botが生んだ「意識の180度転換」

まず着手したのは、社内のAI偏差値の断絶を埋めることでした。CTOや一部のエンジニアを筆頭に、生成AIを活用する動きは社内でも出始めていたものの、まだまだ当時全社的に「生成AI？便利だって聞くし使いたいけど業務が忙しいのと、どう使っていいのかわからない…」のような空気感が漂っていました。

このままではイネーブルメントはできないと考え、はじめに生成AIアプリツール「Dify」を導入しました。Difyは、Slackと連携して便利なチャットボットを簡単に生み出すことができるため、これを活用し、最初のユースケースとして「Findy Team+の使い方Bot」を作成して全社展開してみました。

Findy Team+使い方Botの雰囲気

「便利やん！」から始まった変化

とはいえ正直、最初は「まあ使ってもらえれば御の字か」くらいに思ってました。 しかし、蓋を開けてみれば想定以上の反響。「これ便利すぎ！」「こんな用途で、似たようなBotを作成したい！」と、社内は一種の熱狂に包まれました。

社内の声①

社内の声②

社内の声③

この「Findy Team+の使い方Bot」は、Findy Team+の機能に関する説明や社内で蓄積されたドキュメント等々をナレッジとしたBotであり、これまで事業運営によって培ってきたものが結果として生成AIを強化する武器となってくれています。

しかし、このBot施策の本当の成果は使われたことそのものではありません。 Botを使っているうちに、社員みんながある事に気付いたこと。これこそが最大の成果です。

AIに適切なコンテキスト（データ）を渡し、そのデータを活用する役割を与えれば、強力なパートナーに変貌する

ということです。今までは、

「データ入力？次の予定までに済ませなくちゃいけない準備が優先だから…」

となりがちだった業務の後処理が、

「ここに入力しておけば、AIが賢くなって後で自分が楽できる！きちんと入力しよう！」

という意識に変わった事が、当初想定していなかった一番のインパクトでした。

すなわち、データをきちんと入力・整備することの重要性への意識が、180度変わったんです。

長年事業を積み重ねてきたデータ資産の価値が再定義され、全社の目線が揃った瞬間でした。

社内の声④

【事業貢献】Findy Insightsの立ち上げとα版リリース

GenAI Enablementチームの業務は、社内の便利ツール作りだけではありません。

今年9月に提供開始されたFindy Insightsという生成AIを中心に据えた新規プロダクトの立ち上げとα版リリースにもPoCから実装まで関わりました。

プロダクトの簡単な概要をご紹介すると、「Findy Insights」は、日々集まる膨大な「顧客の声」や「市場データ」を生成AIが分析し、「次にどんな機能を作るべきか（プロダクトディスカバリー）」を支援するサービスです。 今までPMが泥臭く読み込んでいた議事録などのテキストデータを、AIが分析して「こういうニーズが増えている」と提案してくれます。勘と経験だけに頼らない、データドリブンな意思決定を加速させるツールとなります。

プロダクトオーナー（PO）の起案からPoCの着手を2月に開始し、約3ヶ月の検証期間を経てから5月のプロダクト開発開始。9月のα版公開と顧客提供開始というスピード感あふれるタイムスケジュールで駆け抜けることができました。

本来であれば1年はかかる規模の新規プロダクト開発でしたが、半年足らずで顧客への提供開始まで漕ぎ着けることができました。その背景には、

  • 提供予定の機能のPoCを、POと連携しながら常に最前線で取り組み続けたこと
  • PoCにより確定した仕様をアプリケーションエンジニアと連携し、実装にも加わりつつレビューにも入り込み、密な連携を取り続けたこと

などと振り返っています。

もちろん、GenAI Enablementチームだけではなく、このプロダクトの開発に関わった全員の尽力に寄るところは言うまでもありません。

提供開始後まもなくではありますが、既に数十社以上との商談やトライアル開始などで引き合いを頂けている状況であります。

また、今後も様々な機能の開発とアップデートを予定していますので、どこかの機会でご紹介できればと思います。

取り組みの成果と社内評価

たった2名体制ながら、社内活用向けのBot開発と、事業貢献につながる新規プロダクト立ち上げの両輪で取り組みを進めました。その結果、半期に一度の全社表彰で受賞とノミネートの評価を得ることができました。

表彰トロフィーと表彰状

【知見共有】データサイエンティストがいなくても実装できる体制へ

成果が出れば出るほど、ぶつかった壁が「リソース不足」でした。 ML（機械学習）やLLMの実装は、一定部分をデータサイエンティストに依存してきた背景がありました。

社内活用や事業貢献の取り組みを通じて同時に取り組んだのが、エンジニアリングの冗長化です。

ML/LLMを伴う機能開発の概念フロー（Before）

これまでデータサイエンティストだけで完結させていた実装ノウハウを、プロジェクトを通じて社内のエンジニアや他組織に積極的に展開しました。 その結果、今では実装面においてデータサイエンティストの手が空いてなくても、社内エンジニアに頼ればOKという状態になりつつあります。

ML/LLMを伴う機能開発の概念フロー（After）

実装工数が理由でお断りせざるを得なかった依頼も、レビュー/レビュワーの関係になりながらエンジニアチームと連携しながら進めることができるようになったことは、非常に大きな一歩だったと振り返っています。

やりきれなかったこと

ここまで良い取り組みを書いてきましたが、その裏側には、思うように前に進められなかったことも少なくありませんでした。

  • お断りの連続
    • 問い合わせや相談は急増しましたが、リソースには限りがあり、新規開発や業務改善の多くを先送りせざるを得ない状況が続きました。
  • 生成AIフレンドリーなデータ整備
    • 新しい取り組みを進めようとするほど、その実現に必要なデータが不足していたり、整備が十分でない場面に直面しました。
    • 「業務改善のために Team+ の使い方Botのような仕組みが欲しい」という声も多くいただきましたが、前提となるデータが不足していたり、そもそも存在しないケースもありました。

データ活用、新規開発、Ops改善の推進に向けて、これらの課題を来年にかけて解決する必要があります。来期は、計画的に取り組みを進めていきます。

まとめ

  • この1年の取り組みを経て、データ活用への意識やモメンタムを産むには、論より証拠。まずは作って示すことが効果的な方法の1つである事を学びました。
  • 新規プロダクトをスピード感を持って立ち上げるには、データサイエンティストが常にPoC先頭に立って絶え間なく行い続けることができる体制を整える事が大切である事を学びました。

最後に

GenAI Enablementチームではデータ・AI活用を用いて一緒に事業貢献に取り組んでいく仲間を募集しています。興味のある方はぜひカジュアル面談等々でお話ししましょう！

herp.careers

登壇未経験のエンジニアが初めて登壇してみた話

イベントレポート GitHub Actions

こんにちは！ファインディのTeam+開発部の甲斐（@karukan013L23）です。この記事は 🎄ファインディエンジニア #1 Advent Calendar 2025 7日目の投稿です。

adventar.org

去年まで1度も登壇したことがなかったのですが、今年は次の3つのイベントに登壇しました。

今回は、登壇経験のなかった私が登壇に挑戦したきっかけや、各イベントの登壇内容、そして登壇を通して得られた学びについて紹介します。

登壇のきっかけ

きっかけは、TSKaigi 2025の懇親会でした。来年のTSKaigiはプロポーザル出して登壇してみたいねと懇親会の参加者の方と一緒に話していました。私はまだ登壇したことがなかったのでそのことを話すと、「じゃあ1回登壇してみようよ」と直近登壇できそうなLTイベントを探してくださり、私はそのLTイベントに登壇枠で申し込みました。これが最初の登壇への一歩でした。

Mita.ts

イベントリンク: https://mitats.connpass.com/event/353424/
登壇タイトル: 「tsgoを触ってみて得た学び」

登壇資料 speakerdeck.com

登壇内容

Announcing TypeScript Native PreviewsでTypeScriptのGo言語実装によるコンパイラのプレビュー版の公開が発表されました。これにより、tsgoコマンドを使用することでGo言語実装版でのtypecheckが実行可能になりました。 そこで、typecheck実行時にコード量の異なるプロジェクトでどのようなパフォーマンス差が出るのかを検証しました。

実際に計測してみると、コード量が多いプロジェクトでは 8.47倍、少ないプロジェクトでも 3.14倍 の高速化を確認できました。 特にコード量が多いプロジェクトほど、Go言語による並列処理の恩恵を受けやすく、高いパフォーマンス改善効果が見られました。

調査過程で現在のTypeScriptから変わる部分や今後の動きを学ぶことができ、「調べるだけでなく実際に手を動かすことの大切さ」を実感しました。

登壇してみて

初めての登壇ということもあり、多くの反省点がありました。 特に時間管理が課題で、心の中で読むのと実際に声に出して発表するのとでは、所要時間に大きな差があることを痛感しました。大まかなメモだけで話そうとしてしまったため、想定以上に時間がかかってしまいました。 また、内容についても「とりあえず触ってみた」という域を出ず、聞き手にとっての学びやメッセージ性が弱かった点も反省です。

登壇自体は反省点が多かったですが、登壇準備はTypeScriptについて理解を深める良い機会になりました。 LT会はワイワイした雰囲気で、多くの人との交流を楽しむことができました。初めて登壇する場として、とても良かったと思います。

すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう 〜

弊社が会場スポンサーを務めるイベントで、「登壇してみないか？」と社内で声をかけていただきました。
1度登壇したことで登壇に対する心理的ハードルが下がっていたこともあり、せっかくの機会なので挑戦することにしました。

イベントリンク: https://formx.connpass.com/event/364158/
登壇タイトル: 「AI疲れに効く、フロントエンドのワークフロー整備」

登壇資料 speakerdeck.com

登壇内容

生成AIによるコーディングが普及する一方で、AIが生成したコードのレビューや手直しによる「AI疲れ」という新たな課題も生まれています。そこで、AIと安全に協業しつつ開発速度を維持するための「守り」と「高速化」のワークフロー整備について紹介しました。

具体的には、「守り」としてTypeScriptやESLintによる静的解析、Nxによるモジュール境界の強制、Vitestを用いた自動テスト、フィーチャーフラグの導入などを行っています。 また、「守りの高速化」のアプローチとして、Nxの変更検知とキャッシュ機能を活用し、影響範囲のあるプロジェクトのみをCI対象に絞り込んでいます。さらに、GitHub ActionsのRunnerスペックを負荷に合わせて最適化することで、CIの実行時間を短縮しています。

これらの仕組みは元々開発効率と品質のために構築したものですが、結果としてAI時代においても強固な土台として機能しています。

登壇してみて

今回は弊社のフロントエンドテックリードに壁打ちをお願いし、方向性をしっかりと固めてから準備に入りました。「フロントエンドのワークフロー整備」という範囲が広いテーマでしたが、「AIに好き勝手させないための守りと高速化」という軸が決まっていたので、話す内容の取捨選択がしやすかったです。 当日は緊張しましたが、スピーカーノートをしっかり準備して練習していたおかげで、落ち着いて話すことができました。

TSKaigi Hokuriku 2025

弊社がGoldスポンサーとして協賛していたイベントです。 一般公募のプロポーザルは残念ながら不採択だったのですが、スポンサーLT枠として登壇の機会をいただきました。

イベントリンク: https://hokuriku.tskaigi.org/
登壇タイトル: 「Nxはいいぞ！monorepoプロジェクトにおける差分検知を活用した型チェック最適化」

登壇資料 speakerdeck.com

登壇内容

プロジェクトのコード量増加に伴い、CI実行の実行時間が増加する課題に対して、Nxの差分検知とキャッシュを活用したCI高速化の手法を紹介しました。

Nxは、モノレポやアプリケーションのビルド、テスト実行、コード生成などの機能を備えた統合的なツールです。ファインディの多くのフロントエンドでも採用されています。主な特徴として、タスク実行の並列化、変更検知、キャッシュ活用によるCI実行の効率化があります。

Nxは変更があったプロジェクトと、それに依存関係のあるプロジェクトのみを対象にコマンドを実行します。これにより、typecheckなどのタスクの不要な実行をスキップでき、依存関係が小さい変更ほどCIが早く終わるようになります。

Nxの恩恵を最大限受けるためにはプロジェクトの依存関係を適切に整理することが重要です。コード量の増加によるCI実行時間の増加や開発体験の低下に課題を感じたら、ぜひNxのことを思い出してください！

登壇してみて

元々プロポーザルを出していた内容だったため、ターゲット（モノレポ構成やCI時間に課題を感じている層）と伝えたいメッセージを明確にできており、登壇準備を進めやすかったです。 4分間のLT枠だったため、短い時間の中で「何を伝えればNxの良さが響くか」を意識して構成を考えました。結果、制限時間ギリギリではありましたが、伝えたいポイントはしっかり届けられたと感じています。

ちなみに、TSKaigi Hokuriku 2025については、同日参加したメンバーも記事を投稿していますので、イベントの雰囲気が気になる方はぜひ併せてご覧ください！

tech.findy.co.jp

note.com

登壇準備でやってよかったこと

これら3回の登壇を通して、特にやってよかったなと思った取り組みを紹介します。

1. 登壇内容の壁打ち

登壇内容の方向性、軸を決めるためにテックリードや他の登壇予定の方と壁打ちをすることです。
自分だけで登壇内容を考えると、何か足りないと感じたり範囲が広すぎて軸を定められないなど迷うことがあります。
必ずしもひとりで考えきる必要はありません。迷いがあったら壁打ちをお願いしてみることをおすすめします。

2. 話したいことをとにかく書き出す

「話したいこと」をとにかく書き出しました。
一度書き出すことで、自分自身の理解の曖昧な部分が浮き彫りになり、調査をして理解を深めるきっかけになりました。
調査の過程がそのまま学びの機会になるため、おすすめです。

3. 登壇時に話す内容を全てスピーカーノートに書き出す、発表練習を繰り返してブラッシュアップ

いわゆる「台本」を作ることです。
話す内容を全て文字に起こすことで、説明の言い回しや構成に違和感がないかを確認できます。
また、実際に声に出して読んでみると「この表現は伝わりにくい」「ここは順序を入れ替えたほうがいい」といった気づきが得られます。
発表練習を繰り返してスピーカーノートを直し、時間配分を調整することをひたすら繰り返すことで、本番で落ち着いて話すことができるようになります。

4. 登壇資料のレビュー依頼

資料ができたら、テックリードや社内のエンジニアにレビューをお願いしました。
作り手視点だけでは気づけない「説明の誤り」や「わかりにくい表現」を指摘していただき、勉強になりました。
また、会場が大きいので、文字が小さいと後ろの席から見えないから限界まで文字サイズを大きくした方が良いといった、登壇経験者ならではの実践的なアドバイスもいただき勉強になりました。

まとめ

登壇に挑戦することで、技術の理解を深めるよい学びの機会となりました。 聞き手にわかりやすく説明するためには、自分自身がその技術を深く、体系的に理解している必要があります。曖昧だった知識を補完し、学び直すプロセスそのものが、エンジニアとしての成長に繋がったと感じています。

これからも、登壇やブログ執筆といったアウトプットの機会を大切にし、自分自身の学びの場として活かしていきたいと思います。

ファインディでは一緒に働くメンバーを募集しています！

興味がある方はこちらから ↓ herp.careers

基礎力が鍵！ Developers Boost 2025登壇レポート

イベントレポート GenAI・LLM Claude Devin MCP

こんにちは、ファインディのみっきー@mikiko_bridgeです。

12月6日（土）に池袋で開催されたDevelopers Boost 2025の「Hello, new world! ～技術とキャリアを次のステージへ～」というテーマのLT枠で登壇しました。

翔泳社さんのイベントで登壇するのは2回目です。昨年、Women Developers Summit 2024でLTをさせていただき、再び登壇の機会をいただけて本当に嬉しいです！

本記事では、私のLTの内容と、登壇準備を通じて得た気づきについてお伝えします。

ファインディと生成AI

ファインディでは、生成AIの活用を推進しています。

AI推進チームが設立され、エンジニアが開発に集中できる環境が整っています。AI推進チームがAIのキャッチアップや活用をサポートしてくれるため、最新技術を取り入れやすい環境です。

AI活用事例については、次のブログをご覧ください。

ジュニアエンジニアはどう生きるか？

生成AIが当たり前になった今、ジュニアエンジニアとしてどう成長していくべきでしょうか。これまでは、good first issue やテストコードの追加といった小さなタスクから始めて、徐々にスキルを身につけていくのが一般的でした。

しかし、生成AIの登場により、コードの自動生成やデバッグの支援が簡単にできるようになり、ジュニアエンジニアが直面する課題も変わってきています。

伸び悩むわたし

ファインディに転職してから、チーム目標である1日4件のプルリクエスト作成をほぼ達成できない日々が続いていました。

コードを書いても思うようにいかず、レビューで指摘される箇所も多く、「なんとなくうまくいかないな」という感覚が続きました。

同期入社のエンジニアたちが次々と新しい機能を実装していく中で、自分だけが取り残されているような焦りと不安を感じていました。

そんな状況を見かねて、テックリードの方がメンターとなり、毎日1on1をすることになりました。テックリードに声をかけられることはなかったので、1on1の予定が入った時はめちゃくちゃビビっていました。1on1の当日、怒られると思っていたのですが、そうではなく、今後どうやって成長していくべきかを真剣に話し合いました。

そして、5ヶ月間の修行が始まりました。私は、「あえて生成AIという便利なツールに頼ることなく、まずはエンジニアとしての基礎をしっかりと固める」という方針を選びました。

5ヶ月間、何をやったか

2024年12月から2025年4月までの約5ヶ月間、私はテストのリファクタリングとコードドキュメントの追加という地道な作業に集中的に取り組みました。テックリードの方がメンターとなり、毎日1on1を行い、進捗や課題について相談しました。

テストの追加

ファインディはテストカバレッジが90%超えを維持していますが、さらに堅牢なテストにするためのリファクタリングを行いました。

具体的には、ソート機能に関するテストを強化しました。

  • 境界値や閾値を意識したテストデータを用意する
  • ソート順が正しく機能していることを検証するため、ID順とは異なる順序でデータを配置し、意図した並び順になっていることを確認する
  • 条件に該当しないデータ（対象外となるケース）も含めることで、フィルタリングロジックが正しく動作していることを保証する

例えば、次のようなテストコードを書きました。

# ソート機能のテストの例
describe 'ソート機能のテスト' do
  let!(:user1) { create(:user, name: 'Charlie', created_at: 1.day.ago, is_active: true) }
  let!(:user2) { create(:user, name: 'Alice', created_at: 3.days.ago, is_active: true) }
  let!(:user3) { create(:user, name: 'Bob', created_at: 2.days.ago, is_active: true) }
  let!(:inactive_user) { create(:user, name: 'Dave', created_at: 4.days.ago, is_active: false) }

  it '名前順でソートされること' do
    result = User.active.order_by_name
    expect(result.map(&:name)).to eq(['Alice', 'Bob', 'Charlie'])
  end

  it '作成日順でソートされること' do
    result = User.active.order_by_created_at
    expect(result.map(&:name)).to eq(['Charlie', 'Bob', 'Alice'])
  end

  it '非アクティブなユーザーが除外されること' do
    result = User.active
    expect(result).not_to include(inactive_user)
    expect(result.count).to eq(3)
  end
end

初めはテストデータの作成ミスがあったり、想定以上に時間がかかったりしていました。レビューコメントをもらう数も多く、なかなか思うように修正が進まないこともありました。

しかし、徐々にフィードバックを活かして改善を重ねていくうちに、最終的にはテストケースの漏れを自分で見つけられるようになりました。

コードドキュメントの追加

テストの追加が進む中で、コードドキュメントの整備が課題として浮上しました。特に、内部実装の共通処理に関するドキュメントが不足していたため、こちらの整備に注力しました。

コードドキュメントの追加を始めた当初は、例外処理の仕様や実際の使用方法の理解に苦労し、作成に時間がかかることも多くありました。

具体的には、次のようなYARD形式のドキュメントを追加しました。 まず、コメントドキュメントがない状態のコードを見てみましょう。

class UpdateUserInteractor
  include Interactor

  delegate :user_id, :name, :is_active, :roles, :options, to: :context, private: true

  def call
    update_user
    context.user = user
  rescue ActiveRecord::RecordInvalid => e
    Logger.error_exception(e, message: 'Failed to update user')
    context.fail!(message: 'Failed to update user')
  end

  private

  def update_user
    # 実装
  end
end

このコードを見ただけでは、rolesには何が入るのか、optionsにはどんなパラメータを渡せばいいのか、よくわからないですよね？

そこで、YARD形式のコメントドキュメントを追加してみました。

# Interactorのコメントドキュメントの例
#
# @attr user_id Integer ユーザーID
# @attr name String 名前
# @attr is_active Boolean アクティブかどうか
# @attr roles Array<Role> 権限一覧
# @attr options Hash {
#   ids: Array<Integer> IDのリスト。
#   mode: String[Optional]("include") 選択モード
#   is_verified: Boolean (false) trueの場合、検証済みとして扱う
# }[Optional] オプション設定
#
# @example
#  UpdateUserInteractor.call(
#    user_id: 1,
#    name: 'John Doe',
#    is_active: true,
#    roles: [Role.first],
#    options: { ids: [1, 2, 3], mode: 'include', is_verified: true }
#  )
#
class UpdateUserInteractor
  include Interactor

  delegate :user_id, :name, :is_active, :roles, :options, to: :context, private: true

  # Interactor実行
  #
  # @return Interactor::Context {
  #   user: User 更新後のユーザーデータ
  #   message: String エラーメッセージ
  # } コンテキスト
  def call
    update_user
    context.user = user
  rescue ActiveRecord::RecordInvalid => e
    Logger.error_exception(e, message: 'Failed to update user')
    context.fail!(message: 'Failed to update user')
  end

  private

  def update_user
    # 実装
  end
end

いかがでしょうか？コメントがあると、各パラメータの型や意味、使用例が明確になって、格段にわかりやすくなりましたよね！

こうしたコメントドキュメントを追加したことで、自分自身がコードを読み返すときにも理解しやすくなりました。 後から参加する新メンバーにとっても助けになるし、生成AIにコードを解析してもらうときにも正確な情報を渡せるので、AI活用の場面でも役立っています！

対応が進むにつれて作業の質が上がり、自力も少しずつ付いてきたため、最終的にはテストケースの漏れを自分で見つけられるようになりました。

ファインディでは日報・週報の文化があり、テックリードからは「周りではなく過去の自分と比較しましょう」と言われてきました。過去の日報や週報を読み返してみると、2025年4月の週報に「修正が必要な箇所を見極める力がついてきた」という記述がありました。

自分の成長を客観的に実感できた瞬間でした。

結果

取り組みを始めた当初は、プルリクエストの作成が週に7.2件程度というペースで、レビューの数も多い状態でした。

2024/07/01〜2024/11/30までの1週間あたりにPR作成数

しかし、作業を続けていくうちに、徐々にコードの書き方やテストの構造に慣れてきて、最終的には1日あたり18件のプルリクエストを作成できるようになりました。

2024/12/01〜2025/04/30までの1週間あたりにPR作成数

現在とこれから

5ヶ月間の修行を通して、生成AIや目新しい技術の前に、まず基礎を固めることが大切だと実感しました。これからは、基礎力upをベースに生成AIを適切に活用しながら、より品質を高めていきたいと考えています。

現在は、生成AIをピンポイントで利用しています。以前と違って、出力結果を鵜呑みにはしていません。コードリーディングの補助や、命名の提案など、具体的なタスクに対して活用しています。

登壇資料

Speaker Deckで資料を公開しました。

「生成AIを"おあずけ"された私〜自力で書く力がついた半年間〜」 speakerdeck.com

おわりに

今回のLTでは、生成AIが当たり前になった時代において、ジュニアエンジニアとしてどう成長していくべきかについて、私自身の経験をもとにお話ししました。

生成AIは非常に強力で便利なツールですが、それを本当の意味で使いこなし適切に活用していくためには、基礎的な技術力やプログラミングの根本的な理解が不可欠だと感じています。

私はまだまだ成長途中ですが、この5ヶ月間の修行を通じて、焦らず地道に基礎を固めることの大切さを実感しました。同じようにキャリアをスタートした皆さんにとって、私の実践と学びが技術とキャリアを次のステージへ進めるヒントになれば幸いです。

最後に、このような貴重な機会をくださった翔泳社の皆さま、そして当日ご参加いただいた皆さまに心より感謝申し上げます。ありがとうございました！

ファインディでは共に働く仲間を募集中です！

興味がある方はこちらから↓ herp.careers

うちのAIがやらかしまして ─ Claude Codeの暴走を防ぐCLAUDE.md運用術

GenAI・LLM Claude

キャリアプロダクト開発部の森 ＠jiskanulo です。

この記事は、ファインディエンジニア Advent Calendar 2025の6日目の記事です。

adventar.org

現在Findyにて「うちのAIがやらかしまして」という企画ページを期間限定で公開しております。 https://findy-code.io/ai-yarakashi

findy-code.io

「うちのAIがやらかしまして」はAIとの協働で生まれた“試行錯誤のエピソード”を投稿してもらう参加型企画です。 AIのやらかし・すれ違いをシェアし、皆さんの前向きな学びにつなげていく場を提供いたします。

今回は私のAIやらかし事例を紹介しつつ、同じやらかしを再度起こさないようにするため心がけることをご紹介します。 私のやらかし事例はいずれもClaude Codeの利用で起きたものですが、他のAIエージェントを活用されている方にも参考になれば幸いです。

AIやらかし事例の紹介

コードレビューに意図してないコメントを残された

GitHubのコードレビュー内容を確認して、と指示を出したら対応するつもりのない内容をコメントとして残されてしまい慌てて訂正した

findy-code.io

このやらかしの原因は、私の指示が曖昧だったことです。

「コードレビューを確認して」と書いたつもりでしたが、「コードレビューを確認して対応して」と指示してしまったため、Claude Codeはそのレビューに返信コメントを投稿してしまったわけです。

コンソールを眺めていたらgh issue commentコマンドを発行しているのに気づき、慌てて訂正しました。短期間に正反対のコメントを連投しレビュアーに迷惑をかけてしまったやらかしです。

Pull Requestに関係ないファイルがコミットされていた

作業指示を出し、Pull Requestを作成してもらった。Pull Requestを確認すると作業指示に入っていないファイルもコミットされていた

findy-code.io

コミットされていたファイルは別のタスクでCLAUDE.mdの記述調整を依頼した際に作成された一時的なファイルでした。

Claude Codeが git add -A で全ファイルをコミット対象に追加し、そのままコミットを作成してしまったのです。

同じやらかしを繰り返さないために

これら2つのやらかしを踏まえ、同じミスを繰り返さないための対策を整理します。

曖昧な指示が来た時に、Claude Codeに指示の内容を確認するようCLAUDE.mdに記載を追加しました。 これで思いがけない行動を取ってしまうことが減りました。

指示に不明な点や曖昧な点がある場合、作業を進めずに質問を返してください。

次に、指示が終わった後に意図しない挙動を示した場合、どうしてそうなったのか質問をし、回答を求めます。 以下は私が対話した内容の抜粋です。

私:
先ほど不要なファイルのcommitが混ざってしまった事象について、どうして起きてしまったのか、どうすれば再発を防ぐことができるか検討して提案して

Claude:

⏺ CLAUDE.md.backupファイルが誤ってコミットされた原因と再発防止策を分析しました
原因分析
何が起きたか
1. PR #51 (docs-restructure-claude-md) でCLAUDE.mdのバックアップを作成
# 当時の作業
cp CLAUDE.md CLAUDE.md.backup
2. PR #51マージ後、mainから新ブランチを作成
3. git add -A で全変更をステージング
4. CLAUDE.md.backupがワーキングディレクトリに残っていたため、意図せずコミットに含まれた

根本原因
- ✅ バックアップファイルを作業後に削除しなかった
- ✅ git add -A が全ファイルを無条件に追加した
- ✅ コミット前のステージング内容確認を怠った

再発防止策
…

これ以降、対話を続けて方針を定めました。 対話してまとめた内容をCLAUDE.mdに記載させ、次回以降同じことを起こさないようにしました。 内容が冗長だったり逆に限定的で不足している部分もありますが都度調整していきます。

最終的にCLAUDE.mdに追加した内容は次の2点です。

  • コミット前にステージングされているファイルを確認すること
  • 意図していないファイルが含まれていないことを確認すること
#### コミット前の確認

```bash
# ステージングエリアの確認
git status

# 意図していないファイルが含まれていないことを確認
git diff --cached --name-only
```

おわり

AIエージェントは最初から100％期待に沿う行動をしてくれるわけではありません。 いい加減な指示を出すと思いがけないふるまいをやらかしてしまいます。 時にはやらかしつつ、やらかしを再発防止策を考えて対策し、共に成長していくパートナーとして触れ合っていきましょう。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらからからご応募ください。 herp.careers

2025年のFindy SREチームの歩みと成果を振り返る

SRE GenAI・LLM Devin Terraform GitHub Actions MCP

はじめに

みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（@adachin0817）です。この記事は、ファインディエンジニア Advent Calendar 2025の5日目の記事です。今回は2025年のSREチームの成果や課題などを振り返りたいと思います。

adventar.org

Platform SREチーム ビジョンの再定義

「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」

このビジョンを元に、Platform開発チーム SRE(以下、Platform SRE)チームの方向性を再定義しました。これまでもビジョン自体は存在していたものの、メンバーの役割や責任範囲など曖昧で、チームとしてどう実現していくのかが十分に描き切れていませんでした。そのため、2025年に向けてビジョンをブラッシュアップし、具体的な行動指針へと落とし込みました。

また、ミッションは半期ごとに見直す運用へと変更しました。従来は年間を通して固定したミッションで動いており、課題や状況など大きく変化することが分かりました。そのため、より柔軟な意思決定と、チームメンバーの意志を反映できる仕組みにアップデートしました。

次は、2025年 Platform SRE ロードマップを解説します。

2025年のPlatform SREロードマップ

  • AI活用
    • DevinやAI補助による運用・構築の自動化
  • Observability
    • SLI/SLOの見直し
    • Datadog RUMの検証
  • Cost
    • パフォーマンス予測モデル導入
    • MCPによるコスト最適化
  • Security
    • アプリケーション脆弱性対応
    • Takumi導入
    • Shisho Cloud棚卸し
  • Infrastructure
    • Team+ 本番DBクローン ワークフロー作成
    • Tools/Conference 本番DBのためのStgマスキングワークフロー作成
    • 負荷試験環境
    • ログ基盤の設計
    • WordPressをShifterに移行
    • Terraform汎用モジュールの拡充
    • aws-nukeによる不要リソースの自動削除
    • Findy Team+ マーケットプレイス対応
  • CI/CD
    • デプロイの共通化
      • GitHub Actionsのテンプレート化
      • ecspressoの導入
  • Automation
    • 社内ツール実装(Go)
    • 新規AWSアカウント作成業務の自動化
  • Onboarding
    • 新規ジュニアメンバー教育
  • Culture
    • SRE文化醸成

2025年のPlatform SREチームは、開発チームが自律的にSREを実践できる組織を目指し、8つの領域にフォーカスしてロードマップを策定しました。単なる改善タスクではなく、SREを仕組みと文化としてチームに埋め込むことを重視しています。

次は特に注力した取り組みについてまとめていきます。

主に取り組んできたこと

Devinの活用

SREチームでは、新サービスが追加されるたびに、Shisho CloudとAmazon Security LakeをTerraformで連携しています。しかし、この設定手順は非常にシンプルでありながら毎回人手で作業することがトイルとなっていました。

そこで、Devinを活用した自動化に取り組み、Terraform連携を含む一連の作業をワークフロー化しました。さらに、GitHubアカウントの発行、AWSアカウントの作成、WordPressの軽微な修正などもDevin化し、SREのトイルを大きく削減できています。今後は、これらの仕組みを横展開し、より広く標準化していく予定です。

tech.findy.co.jp

Terraform汎用モジュールとtestの拡充

tech.findy.co.jp

今年からは、新サービスをより高速に構築するため、Terraformによる汎用モジュールの整備に本格的に取り組みました。 これまでは既存コードの流用をベースに構築していたため、設定の漏れや環境差異を適切に把握できない状態が続いていました。

その課題に対し、Terraformの汎用モジュール化と Terraform Test の拡充することで、Apply前に失敗や設定ミスを検知できる仕組みを構築しました。これにより、信頼性を担保しながらもスピード感のあるインフラ構築が実現できるようになったと感じています。

Findy Team+ 本番DBクローン ワークフロー化

これまでは、Embedded SREが手動で本番DBのスナップショットを取得し、開発チームがそれを基にバッチテストや検証していました。しかし、テスト環境の構築に時間がかかるだけでなく、実際の運用に近い再現性が担保しづらいという課題がありました。

そこで、2025年からは 本番DBクローンを自動で生成できるワークフローを実装しました。この仕組みにより、バッチ処理を含むパフォーマンステストや検証作業を誰でも再現性高く実施できる環境が整備されました。安全性の確保にも配慮し、クローンDBは本番DBと隔離された環境で動作、アクセス制御を厳格に適用、本番相当のデータでテスト可能という形で、リスクを防ぎつつ、実運用に近いテスト環境を実現しています。

クローンDBの作成および削除は、すべてAWS CLIによるワークフローとして自動化しています。また、バッチのパフォーマンステストについては、Operationコンテナ上でAPIと同等の環境を再現しており、本番に近い条件での検証を行えるようになりました。

Findy Team+ AWSマーケットプレイス対応

aws.amazon.com

Findy Team+では、AWSマーケットプレイスへの掲載準備が本格的に始まりました。これまでの直契約モデルから、AWS経由で利用できるモデルという選択肢が増えます。特にエンタープライズ企業では、調達プロセス・セキュリティ基準・契約形態・監査プロセスなどのハードルが高く、SaaS導入の初動でつまずくケースが少なくありません。その中で、AWSマーケットプレイス経由の契約であれば調達がスムーズになるため、AWS経由で使えることが導入条件になる企業でもTeam+導入の壁がさがることを期待しています。

今回の対応により、Findy Team+はエンタープライズ向けのSaaSとしての提供価値をより明確にしていくフェーズに入ったと考えています。

Takumi SAST/DASTの導入

flatt.tech

Shisho Cloudを運用していく中で、アプリケーション層の脆弱性も同じ仕組みで検知・可視化したいという課題が生まれました。そこで、コード診断に特化した Takumi（SAST / DAST）を全サービスへ導入し、セキュリティ領域の基盤整備を進めました。

SASTによる静的解析ではコードの脆弱性を早期検知できるようになり、DASTによる動的解析では実行可能な攻撃パターンの再現・検証ができるようになりました。その結果、「診断 → 可視化 → 修正 → 再検証」 というサイクルが開発メンバーの中で自然と回り始め、SREチームによる支援型セキュリティの形が実際に機能し始めています。

また、DASTによるブラックボックス診断については、来年のSRE Kaigi 2026でもGMO Flatt Security CTO 米内さんと発表予定です。セッションではAI時代におけるセキュリティ戦略や、その実践的な導入アプローチについて具体的にお話しますので、ぜひご参加いただき、これからのセキュリティの在り方を一緒に考える機会にできれば嬉しいです。

2026年に向けた展望と課題

来年はSREチームとして、今年の取り組みを「仕組みを作る段階」から「仕組みを運用し、継続的に改善していく段階」へ移行していく予定です。単にSREの知識を展開するだけではなく、開発チーム自身が自律的にSREの判断・運用ができる状態を、より強く推進し、Enablingしていきたいと考えています。

おわりに

2025年は、SREチームにとって仕組みづくりと文化づくりの両輪で走り続けた1年でした。振り返ってみると、改善することよりも、なぜ改善するのか？どうあるべきなのか？を問い続ける1年だったように感じます。

まだまだロードマップは対応できていないものもたくさんあるのと、来年は今年つくった仕組みを本格運用フェーズへ進めつつ、開発チームが自律的にSREを実践できる組織づくりに挑戦していきます。

明日はjiskanuloさんになります！見ていただきありがとうございました。