こんにちは。
ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。
現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。
GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。
そのような状況の中で先日、Findy AI Meetupの記念すべき第1回を、2025年8月4日(月)に福岡にて開催致しました！
そのイベントで ファインディ株式会社における生成AI活用までの軌跡 と題しまして登壇しました。
そこで今回は、イベントに参加出来なかった方向けに、登壇資料をなぞりながら弊社が生成AIを活用できるようになるまでの道のりを紹介します。
ファインディの開発文化
まずは弊社の開発組織の文化を紹介します。
以前紹介したタスク分解。これは 弊社にJOINしてくれたエンジニアが最初に覚えるスキル です。
また、以前紹介したPull requestの粒度も重要です。適切な粒度でPull requestを作成することで、レビュワー、レビュイーの両者に対して優しいPull requestとなり、開発リズムを整えることが出来ます。
適切な粒度を知るためにも、タスク分解のスキルは必須となっています。
テストコードとCI/CDを整備することも重要です。
テストコードがあることで、実装コードを変更した際に、既存の振る舞いに影響がないことを保証することが出来ます。また、テストコードを読むことで、そのアプリケーションの正しい振る舞いを知ることが出来ます。
CI/CDは特に速度と自動化に拘っています。
Pull requestの粒度が比較的細かいため、作成数が多くなります。作成数が多い中でCIが遅い場合、CIの速度がボトルネックとなり、開発スピード全体が遅くなってしまいます。そこで弊社では、キャッシュや並列実行などを駆使してCIの高速化を図っています。
統一されたコード規約と設計、ドキュメンテーションも重要です。弊社では「新しいメンバーがJOIN初日にPull requestを作成することが出来る」ということを目指してREADMEの整備を行っており、都度内容の見直しをしています。
このようにファインディの開発文化は、 開発に着手する前の事前準備を重要としている ことが分かるかと思います。
1つ1つはとても小さなことです。しかし、それらをこの5年間でしっかりとやり切ってきました。それらの積み重ねが開発組織の文化となっています。
僕もテックリードとなり、弊社の開発組織も5年前は10人も満たなかったのが、今では50人を超える規模となっています。
この規模になると、僕の目が行き届いていないチームも出てきています。
しかし、彼らは僕のいないところでも、今回紹介した 「開発に着手する前の準備」を怠っておらず、新メンバーに開発文化の継承を継続する ことが出来ています。
着実に積み重ねたものは強い ということを皆が証明してくれました。
生成AI活用のための事前準備
さて、ここからが本題ですが、ここまで読んでくださった読者のみなさんの中には既に勘付いている方もいるかと思います。
そうです。 ここまで紹介した内容はどれも、生成AIを活用するために必要なこと なのです！
タスク分解は生成AIに明示的に指示を出す時に特に重要 です。Issueやプロンプトに階層構造で明確なステップを記述することで、生成AIが理解しやすいタスクを作成できます。
適切な粒度のPull requestを生成AIに例として提示することで、 余計な内容を学習することなく同じような修正を任せる ことが出来ます。
テストコードとCI/CDは生成AI時代に重要度が更に増しています。 生成AIが修正内容の方向性を外れないためのガードレールとなるからです。 生成AIがコードを修正した後に、その内容が合っているのか、間違っているのかを生成AI自身が判断するための基準となる のです。
統一されたコード規約と設計、ドキュメンテーションは、生成AIがコンテキストを理解するうえで最も重要なリソースの1つです。これらの内容がバラついてしまうと、生成AIが正解を導くことが難しくなってしまいます。
ファインディではこれらのことを、生成AI活用が開発の現場に広まる前から取り組んでいました。 生成AIを開発に足したのではなく、生成AIが今までの開発フローに乗っかってきた。というイメージが近いかもしれません。
生成AIを活用するために新しく何かをした。ということではなく、人が開発しやすくなるように整備を進めていた結果、生成AIフレンドリーな環境、文化になっていた ということです。
もちろん、全ての内容を完璧に整えられているわけではありません。まだ道半ばの箇所もあります。しかし、それらに対して 時間やコストを掛けて整備を進めることが当たり前という考えを、開発組織だけではなく経営陣含めて全社で共通認識として持っている ことが、弊社の文化だと言えるでしょう。
生成AI時代のファインディの開発現場
ここまでで、弊社が生成AIを活用出来ている理由を説明しました。
ここからは、実際にどんなシーンで活用しているかを紹介します。
テックブログの壁打ち
執筆やアウトプットの経験がないメンバーが、いきなりテックブログの記事を執筆するのはハードルが高いものです。
そこで弊社CTOが作ったのが壁打ちbotです。Slackのメッセージでbotとインタラクティブにやり取りして、執筆内容を壁打ちをしてくれます。
書きたい、伝えたい内容をbotと壁打ちしていくと、最終的にテックブログの記事の草案を出力してくれます。草案を元に記事を執筆できる環境を整えることで、テックブログの執筆に対するハードルを下げることに成功しました。
大事なこととして、AIで書かれた文章をそのままブログ記事にしてしまうと本人の持つ「味」が損なわれてしまいます。そのため、あくまで骨子を作ることまでに限定し、自分の手で書いてもらうことが望ましいです。
また、テックブログの記事を書き終わってタイトルに悩まされる経験をした読者の方もいると思います。そういったケースの場合、ChatGPTとタイトル案の壁打ちを行うこともあります。
この場合、生成AIに執筆内容を渡して、タイトル案を複数個出してもらうと良いです。
その中で気になるキーワードが出てきたら、そのキーワードを使うという条件を追加して新たにタイトル案を複数出してもらいます。この作業を繰り返すと、最終的に良い感じのタイトルが出てきます。テックブログの記事のタイトルに悩んだ時に試してみてください。
小さいタスクはDevinにお任せ
一括置換や軽微なリファクタといったタスクはDevinにお任せしています。
実際にDevinに依頼してPull requestを自動作成する仕組みを作ったことで、 個人のアウトプットが1.5倍 になったという実例もあります。
また、DevinでTerraformのコードを変更してPull requestを作成する仕組みも用意しています。
Slackのワークフローを用意して、Devinへの依頼を定型化します。そこからAWSのリソースへの権限追加や、構成変更などをDevinが自動でPull requestを作成します。
作成されたPull requestをSREチームがレビューし、問題なければmergeしてTerraformのapplyが実行されるようになっています。
Slackのワークフローを変更依頼のスタート地点としており、人間が介入するのはレビューとmergeのタイミングだけとなっています。このようにワークフローを定型化できる作業はDevinに任せています。
この話はまた別のタイミングで出来たらと思います。お楽しみに！
AI Agentで自律的かつ並列に開発
弊社では主にClaude Code ActionやGitHub Copilot Coding Agentを活用しています。
GitHubのIssueに要件とタスクを記載して、それをAI Agentに渡してPull requestの作成まで自動化しています。
そしてここでも タスク分解のスキルが大いに生きます。 AI Agentに依頼するタスクは明確なステップ階層で渡すと精度が上がります。
実際にClaude CodeやKiroが自身でタスクを出すときも、明確なステップ階層で出してきます。タスク分解に慣れていない方は、まずClaude CodeやKiroにタスクを出してもらい、そこから修正して正しいタスク出しを経験していくと良いと思います。
Model Context Protocol
弊社ではMCP(Model Context Protocol)の有用性に一早く気づき、検証を進めてきました。
tech.findy.co.jp tech.findy.co.jp
MCPを内製で作成できるように環境を整備した他、業務効率化だけに留まらず、 新規プロダクトでの導入 も行っています。
後述にはなりますが、 次回開催するイベントで私がMCPをテーマに登壇する予定 です。福岡でのオフラインイベントになりますが、気になる方は是非ご参加ください。
カスタムスラッシュコマンド
Claude Codeの機能で、頻繁に使うプロンプトを定義できます。
Nxのmigrateを自動で実行するものや、GitHubのIssueを取得して、タスク分解から実装、Pull requestまで自動化するものなど、多岐に渡って用意しています。
特に有用だと感じたのは、ローカル環境の環境構築を自動化するカスタムコマンドです。今まではREADMEの内容を元に各自実行して環境構築をしていましたが、カスタムコマンドで自動化することで、環境構築に対するハードルが落ちました。
次の例は、Pythonのプロジェクトの環境構築をするカスタムコマンドの例です。
# Local環境の環境構築 - brew install uv - mise install - brew install mkcert - mkcert -install - mkcert -cert-file localhost.pem -key-file localhost-key.pem localhost 0.0.0.0 - uv sync --frozen - cp .env.sample .env.local - docker compose up -d db mailpit - python -m alembic upgrade head - python -m pytest
今まではREADMEに環境構築の手順を書いていましたが、メンテナンスが行き届いていなかったり、意図しない場面で詰まることがありました。
ですが、Claude Codeのカスタムコマンドで環境構築することで、 意図しない場面で詰まっても、Claude Codeが原因を突き止めて、軌道修正しながら環境構築を完了する ことが出来ます。
まとめ
いかがでしたでしょうか？
長年の小さな改善の積み重ねが、現在の開発組織の文化を作りあげました。 その結果、生成AIと自然に協働できる AIフレンドリーな組織文化 となっていたのです。
生成AIとの協働は1日にして成らず。 事前準備や環境、ガードレールの整備など、 小さな積み重ねを続けることが重要 です。 人が開発しやすくすることは、結果的に生成AIのガードレール整備に繋がる のです。
生成AIを使ってみたけど、思っていた結果が出ないと感じているのであれば、まずは目の前の小さなことや、足元の整理に着手することをオススメします。
登壇資料の方も是非ご覧になってください。
最後になりますが、このたび 2025年9月8日(月)にFindy AI Meetup in Fukuoka #2の開催が決定 しました！
会場へのアクセスは天神駅から徒歩3分となっています。また、TVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。
僕も運営、登壇者として参加予定です。是非イベントに足を運んでいただき、懇親会でAI談義に花を咲かせましょう。
申込みの先着順となっておりますので、気になっている方は早めにお申し込みいただくことをおすすめします。生成AIの活用事例に興味のある方は奮ってご参加ください！
みなさんにお会いできることを楽しみにしています！
現在、ファインディでは一緒に働くメンバーを募集中です。
興味がある方はこちらから ↓ herp.careers
