Findy AI Meetup in Fukuoka #1 を開催しました

こんにちは。

ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。

そのような状況の中で先日、Findy AI Meetupの記念すべき第1回を福岡で開催しましたので、今回はそのイベントの様子や内容を紹介します。

findy-inc.connpass.com

福岡でのイベント開催は実に2年ぶりとなっており、我々も参加者の皆さんにお会い出来ることを楽しみにしていました。

ありがたいことにキャンセル待ちが出るほどに参加申し込みをしていただきました。当日参加くださったみなさま、ありがとうございました!

Findy AI Meetupとは?

ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。

ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。

今回のMeetupは初めての開催となっており、登壇者は全員弊社のエンジニアとなっています。

登壇内容

Nx × AI によるモノレポ活用 ~ コードジェネレーター編

まず弊社のフロントエンド テックリードの新福が登壇しました。

弊社のフロントエンドの多くにはNxが採用されています。今回はNxを採用してきたことが、生成AIの時代にマッチしていたというお話をしました。

tech.findy.co.jp

これまで弊社では、NxのGeneratorを用いて開発効率の向上に取り組んできました。NxのGeneratorは強力な機能を持つ反面、覚えることも多く、初心者がとっつきにくいというのが課題でした。

tech.findy.co.jp

最近のNxは生成AIとの連携が強化されており、中でもNx MCPの登場によって、モノレポ内の情報を生成AIのコンテキストとして利用できるようになりました。

Nx MCPの素晴らしい点は、モノレポ内のプロジェクトやNxのGeneratorを自然言語で操作できることにあります。これにより、複雑なコードを書かなくても柔軟で対話的なコード生成の業務フローが実現可能になりました。

例として今回は、CopilotやClaude CodeのスラッシュコマンドからNx MCP + Nx Generatorを起動させる方法を紹介しています。

生成AI時代の業務標準化は、もうすぐそこに来ているのかもしれません。

今回はNxのGeneratorに焦点を当ててお話しましたが、Nx公式のCIサービスである「Nx Cloud」にもAI機能が続々と追加されているので、いつかご紹介できればと思います。

Findy Freelance利用シーン別AI活用例

次にフロントエンドエンジニアの主計が、Findy Freelanceチームのコーディング以外でのAI活用事例をいくつか紹介しました。

1つ目は、不具合調査時の Ask Devin の活用です。
不具合報告があった際に、不具合内容をAsk Devinに調査を依頼しています。 対象となるリポジトリを複数選択できるため、原因箇所の特定や切り分けが素早くできるようになっています。 専門領域に関わらず一次調査ができるのもありがたいです。

2つ目は、dependabotのAIレビューです。
最初はDevinのPlaybookを利用して週1でまとめてレビューを依頼していましたが、 Claude Code Base Actionを利用して随時自動で行うように改善しました。 精度も上がり、日々の作業の負担が軽減されています。

3つ目は、AI によるリファインメントの実施です。
PdMとエンジニアで行っているリファインメントの文字起こしデータをNotebookLMに追加して、 リファインメントの観点を洗い出しプロンプト化しています。 ラベル付与をトリガーとすることで、PdMメンバーが任意のタイミングでAIリファインメントを実施できるようになり、リファインメントの負担を軽減できています。 アウトプットに関しては文量が多かったり、肯定的なフィードバックになりがちだったりと課題があるので、引き続きプロンプトを調整しています。

チームでAI活用を進めるため、10分勉強会(5分LTを正社員メンバーで持ち回り)で実施しています。
継続することを優先し、スキップ可や記事紹介可などハードルを下げて取り組んでいます。詳細はこちらの記事をご覧ください。
findy-code.io

普段の業務にAIを活用するために、AIのキャッチアップと同時に、どの業務にどうAIを活用するか日々チーム全体で考えることが大事だと考えています。 引き続きAIを積極活用していくので、良い事例があれば紹介していきたいと思います。

ファインディ株式会社における生成AI活用までの軌跡

最後に、テックリードの戸田が、「ファインディ株式会社における生成AI活用までの軌跡」と題しまして、弊社が生成AIで結果を出せるようになるまでの軌跡を紹介しました。

まず弊社の開発組織の開発文化を支えている考え方やテクニックをいくつか紹介しました。以前にこのテックブログでも紹介した内容もあります。

特にタスク分解とPull requestの粒度は重要です。

tech.findy.co.jp

tech.findy.co.jp

また、統一されたコーディング規約や設計、ドキュメントを整備することも文化として根付いています。特にドキュメント整備は重要で、弊社ではJOIN初日にPull requestを出せるようにしています。

このように、弊社の開発文化を支えているテクニックはコードを書く前の事前準備を重要としており、また、環境や自動化、スピードに拘りを持っています。

これは小さなことをコツコツと積み重ねることでしか実現できませんが、それをしっかりやり切ってきた歴史があり、その積み重ねこそが開発組織の文化となっています。着実に積み重ねたものは強いのです。

次に、弊社が生成AIを活用するために取り組んだ内容を紹介しました。

既存コードの最適化や不要なコードの削除、テストコードの整備やドキュメンテーションなど、生成AIのガードレールとなる要素の整備に関して紹介しました。

また、生成AIに命令を投げる際は、可能な限りスコープを限定的にして、具体的な内容を段階的に渡すのが良いとされています。そのため、弊社で取り組んでいたタスク分解のスキルが重要となるシーンが増えました。

ここまで読んだ読者なら気付いた方もいるかもしれません。そうです。弊社の開発組織の開発文化は、生成AIが流行するずっと前から生成AIフレンドリーな文化となっていたのです。

今までの開発組織に生成AIを足した。ということではなく、今までやってきたことの延長線上に生成AIが乗っかってきた。という表現が近いかもしれません。そのため、生成AIを導入したことで一時的に生産性が落ちた。といった光景は、弊社ではほとんど見られなかったのです。

今までの積み重ねが、結果的に生成AIとの協業を可能としていました。もちろんガードレール整備がまだ行き届いていない箇所もあります。しかしながら、そこの整備に対して投資をするという意思決定が当たり前となっている開発文化でもあります。

このあと、生成AI時代の弊社の開発現場の様子をいくつか紹介させてもらいましたが、これはまた別の記事でも紹介できればと思います。

懇親会

登壇発表後は参加者の皆さんと懇親会を開催しました。

懇親会の様子

懇親会では「パックマンルール」をお願いしました。懇親会で誰かと話すときは新しい人が会話に入れるように、一人分のスペースを空けて話しましょう。というルールです。

パックマンルール

生成AI活用における悩みや知見を意見交換して、楽しんでいただけたようです。

まとめ

いかがでしたでしょうか?

当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。

次回開催は9月前後を予定しております。残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください!

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

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

Findy AI Meetup in Fukuoka #1 を開催します

こんにちは。

ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。

そのような状況の中でこのたび、Findy AI Meetupの記念すべき第1回を、2025年8月4日(月)に福岡にて開催することとなりました!

findy-inc.connpass.com

今回は、このイベントの紹介をしたいと思います。それでは見ていきましょう!

Findy AI Meetupとは?

ファインディ株式会社のエンジニアが主催する技術系のオフラインイベントです。

ファインディ株式会社では、生成AIやAIエージェントの活用を通じて開発生産性の向上を目指す取り組みを行っています。このイベントでは、ファインディのエンジニアが社内での実践事例を紹介するとともに、エンジニア同士がつながり、知見の共有や交流を目的としています。

福岡でのイベント開催は実に2年振りとなっており、我々も参加者の皆さんにお会い出来ることを楽しみにしています。

登壇予定

Nx × AI によるモノレポ活用 ~ コードジェネレーター編

弊社では、ほぼ全てのフロントエンドでNxによるモノレポ管理が採用されています。

tech.findy.co.jp

tech.findy.co.jp

最近のNxは生成AIとの連携が強化されており、中でもNx MCPはモノレポ内の情報を生成AIのコンテキストとして利用できるなど非常に便利です。

今回は、NxのGeneratorをより柔軟かつ対話的に利用できるよう、Nx MCPやプロンプトファイルを組み合わせ、生成AI時代の業務の標準化を目指したお話を紹介します。

Findy Freelance利用シーン別AI活用例

Findy Freelanceの開発ではコーディング時の生成AI活用はもちろんのこと、 コーディング以外の開発関連業務のなかでも生成AIを活用し業務効率化を図っています。

特長の異なる生成AIをどのように使い分けているか、利用シーン別にご紹介します。

ファインディ株式会社における生成AI活用までの軌跡

「ファインディ株式会社における生成AI活用までの軌跡」と題しまして、弊社が生成AIで結果を出せるようになるまでの軌跡を紹介します。

まず弊社の開発組織の開発文化を支えている考え方やテクニックをいくつか紹介します。

tech.findy.co.jp

tech.findy.co.jp

その開発文化の上で、どのように生成AI活用を推し進めたのか、現在はどのような開発現場になっているのかを紹介します。

まとめ

いかがでしたでしょうか?

会場へのアクセスは天神駅から徒歩3分となっています。また、TVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。

申込みの先着順となっており、ありがたいことに参加枠も残りわずかとなっております。生成AIの活用事例に興味のある方は奮ってご参加ください!

イベント参加申し込みはこちらから ↓ findy-inc.connpass.com

みなさんにお会いできることを楽しみにしています!

【Claude Codeの活用事例】よく使うカスタムスラッシュコマンド5選!

こんにちは。ファインディでソフトウェアエンジニアをしている千田(@_c0909)です。

2025年3月末頃からファインディに導入されたClaude Codeは、私たちの開発フローに大きな変化をもたらしました。特に私が注目し活用を進めてきたのが、カスタムスラッシュコマンドの機能です。

Claude Codeを初めて触った時は、CLAUDE.mdに長文で汎用的な指示を書いてコードを生成していました。しかし、全てのプロンプトを網羅するには限界があり、より効率的な活用方法を模索していました。そんな中で出会ったのが、このカスタムスラッシュコマンド機能です。

この機能は、日々のGit操作やコーディング作業の自動化を後押ししてくれます。本記事では、私が実際にどのようなカスタムスラッシュコマンドを作成し、どのように開発業務に役立てているのかを具体的な事例と共にご紹介します。

Claude Codeのカスタムスラッシュコマンドとは

Claude Codeでは、.claude/commands/ディレクトリにMarkdownファイルを配置することで、個人またはチーム独自のコマンドを作成できます。例えば/create-branchのようなコマンドを実行すると、事前に定義したルールに従ってClaude Codeが作業を進めてくれます。

docs.anthropic.com

実際に作成したカスタムスラッシュコマンド

まずはGitのコマンド実行です。Gitの操作は同じ内容をCLAUDE.mdにも書いていて、コードを書いてPR作成までの流れを一貫して依頼することもあります。ただ、コーディングとGit操作の工程を分けて、その間に人がチェックした方が手戻りが少ないため、敢えてカスタムスラッシュコマンドとして用意しています。

ブランチ命名やメッセージの作成などは、次のように自動化しています。

ブランチを作成

.claude/commands/git-create-branch.md

## branchを作成

- ブランチ名は [Conventional Branch](https://conventional-branch.github.io/) に従う
- feature/[FeatureName]-[実装した機能名]

例: feature/admin-user-role-edit-invite-form

毎回悩みがちなブランチ名の命名。Conventional Branchに従っていても、命名するタイミングで手が止まってしまうこともありますよね。このコマンドのおかげでブランチ名を考える手間がなくなり、開発がスムーズになりました。

次の画像は、コマンドを実行した時の結果です。

branchを作成

commitメッセージを作成

.claude/commands/create-commit.md

# commitメッセージを作成

## 実行手順
1. Read @~/.claude/commands/guideline-read-code.md
2. 違反があれば作業を中断
4. `git status`でファイルを確認
5. [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)に従ってコミットを実行

## 形式の指定
- type(scope): subject の形式に従う
- タイトルは50文字以内、本文は72文字程度で改行
- 動詞は原形を使用(add, fix, updateなど)
- scope は原則記述するが、適切なものがない場合は省略可
- コミットメッセージは小文字で始める

## 実装とテストが含まれる場合の優先ルール
- 実装とテストコードが含まれている場合、typeはtestよりもfeat/fixを優先する

このコマンドの特徴は、コミット前に必ずコーディングガイドラインをチェックすることです。手順1のRead @~/.claude/commands/guideline-read-code.mdの部分で読み込ませてます。

例えば、Reactのテストコードでhooksの関数を作成した場合、そのテストとしてコールバック関数がパラメータ付きで実行されることなどを確認しますが、実行回数やエラー時のコールバック関数が実行されていないことを必ずセットで検証します。このような内容をガイドラインとして盛り込んでいます。

機械的にできるレビューは、Commit前にClaude Codeが事前チェックすることで、レビューの負荷を下げます。

なお、弊社のテストコードの考え方については Findyの爆速開発を支える「システムを守るテストコード」の実例3選 - Findy Tech Blog で紹介しています。

Pull Requestを作成

.claude/commands/git-create-pr.md

# PRを作成

- Read @.github/PULL_REQUEST_TEMPLATE.md に従うこと
- Draftで作成すること
- push時は`git push -u origin <branch_name>` のように `--set-upstream` を指定すること
- コマンドの例: `gh pr create --draft --title "title" --body "body"`

PRのテンプレートに詳細な情報が記載されているため、ファイルを参照するだけのシンプルな構成です。エディターでもセルフレビューをしますが、GitHubのdiffの方が見やすいため、PRは必ずDraftの状態で作成してセルフレビューを実施するフローを標準化しています。

また、PULL_REQUEST_TEMPLATE.mdには「動作確認」の項目を用意しています。これはブラウザ上で目視で動作確認する目的で、Claude Codeに内容を列挙して貰っています。

一部抜粋すると次のイメージです。

## 動作確認
- [ ] レスポンシブ対応が正しく動作すること(スマートフォン、タブレット、デスクトップ)
- [ ] Xのシェアボタンが正しく表示されること
- [ ] 背景色がブレークポイントに応じて適切に変更されること

この対応により、特にフロントエンドの実装時はレビュー前にブラウザで動作確認をする時のチェック観点として、PRのレビュアーにも共有しています。

ブランチ, commit, PRの全てを一度に作成

.claude/commands/git-create-branch-commit-pr.md

# branch & commit & pr を作成

## 実行手順
1. Read @~/.claude/commands/create-branch.md を実行
2. Read @~/.claude/commands/create-commit.md を実行
3. Read @~/.claude/commands/create-pr.md を実行

ブランチ作成からPR作成までの一連の作業は、開発サイクルの中で何度も繰り返されます。この定型的なプロセスを自動化するコマンドを作成しています。

開発プロセスの中で事前にタスクを分解し、その粒度に沿ってPRを作成しています。そのため、PRの粒度が小さく、1つのPRに対してコミットは1件が多いです。これにより、ブランチ作成からPR作成までの自動化が容易に実現できています。

タスク分解の詳細は Findyの爆速開発を支えるタスク分解 - Findy Tech Blog で紹介しています。

頻出するコードを自動生成

カスタムスラッシュコマンドは、Git操作だけでなく、具体的なコーディング作業の自動化にも威力を発揮します。私の経験則ではIssueに作成したタスクリストに基づき、小さな単位で具体的なコードを指示すると期待した結果が得られやすいと感じます。

そのため、定型化できる実装はカスタムスラッシュコマンドで対応してもらいます。例えば、フロントエンドの実装では、次のよく使うコードはカスタムスラッシュコマンドで対応しています。

  • 保存ボタンの連打防止の実装
  • テキスト入力の必須バリデーションの実装
  • フォーム入力中の離脱防止の実装

.claude/commands/[Repository name]-coding-is-saving.md

## 保存ボタンの連打防止を実装

作業対象のフィーチャー: $ARGUMENTS

### 参考情報
- PRの確認にghコマンドを使うこと
- https://github.com/Findy/[リポジトリ名]/pull/111

### 実装コードの例

<Button
  priority="primary"
  size="large"
  disabled={isSaving}
  type="submit"
>
  保存
</Button>

### テストコードの例

describe('isSaving', () => {
  it('should disable save button when isSaving is true', () => {
    // Arrange
    setup({
      isSaving: true,
    });

    // Act & Assert
    expect(screen.getByRole('button', { name: '保存する' })).toBeDisabled();
  });

  it('should enable save button when isSaving is false', () => {
    // Arrange
    setup({
      isSaving: false,
    });

    // Act & Assert
    expect(screen.getByRole('button', { name: '保存する' })).toBeEnabled();
  });
});

コーディングにおいてカスタムスラッシュコマンドを作成する基準は次の通りです。

  • 3回以上同じような実装に遭遇した
  • プロダクトコードとテストコードを1セットでPRを作成できる
  • 実装内容が分かり切っている

このようにClaude Codeに小さな粒度でコードを書いてPRを出して貰いつつ、その間に私は別の作業をします。

Claude CodeのHooksの設定により、コーディングなどの作業が完了したら通知音を鳴らしているため、スムーズに切り替えることができます。

まとめ

本記事では、私が実践しているClaude Codeのカスタムスラッシュコマンド活用術をご紹介しました。Git操作の自動化から、具体的なコーディング作業の効率化まで、多岐にわたる場面でClaude Codeが開発をサポートしてくれています。

カスタムスラッシュコマンドは汎用的な指示よりも、具体的で小さなタスクに特化させて作成することで、その効果を最大限に発揮すると感じています。機械的な作業をClaude Codeに任せることで、私たちはより本質的な開発業務に集中できるように今後も試行錯誤していきたいです。

この記事が、皆さんの開発現場におけるAI活用のヒントになれば幸いです。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

MCPアップデート(2025-06-18)徹底解説!開発体験を変える3つの新機能とは!?

こんにちは。

ファインディ株式会社 で Tech Lead をやらせてもらってる戸田です。

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。

そのような状況の中で、MCP(Model Context Protocol)の新バージョンが公開され、いくつかの機能が追加されました。

modelcontextprotocol.io

そこで今回は、その中でも特に注目すべき3つの機能について紹介したいと思います。

それでは見ていきましょう!

toolの表示名の項目追加

MCPサーバーにtoolやpromptを登録する際に、title を設定することが出来るようになりました。

github.com

今までのMCPサーバーでのtoolの登録は次のようなコードで実行されていました。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const mcpServer = new McpServer({
  name: "Sample MCP Server",
  version: "0.0.1"
});

mcpServer.registerTool(
  "addition",
  {
    description: "足し算をする",
    inputSchema:{
      a: z.number(),
      b: z.number()
    }
  },
  ({ a, b }) => {
    return {
      content: [{ type: "text", text: String(a + b) }]
    };
  }
);

MCPクライアントからtoolの情報を確認すると、次のような出力になります。

╭───────────────────────────────────────────────────────────────────────────────────────────╮
│ Tools for sample (1 tools)                                                                │
│                                                                                           │
│ ❯ 1. addition                                                                             │
╰───────────────────────────────────────────────────────────────────────────────────────────╯

╭───────────────────────────────────────────────────────────────────────────────────────────╮
│ addition (sample)                                                                         │
│                                                                                           │
│ Tool name: addition                                                                       │
│ Full name: mcp__sample__addition                                                          │
│                                                                                           │
│ Description:                                                                              │
│ 足し算をする                                                                                │
╰───────────────────────────────────────────────────────────────────────────────────────────╯

Tool nameに addition が、Full nameに mcp__sample__addition が設定されているのがわかります。

同じMCPクライアントで複数のMCPサーバーに接続した場合、tool名が重複してしまうケースが有り得ます。そのため、Tool nameとは別にFull nameが用意されており、MCPサーバー名とtool名を組み合わせた一意な名前が用意されています。

しかしここで重要な問題が起こります。MCPクライアントによっては、Full nameに文字数制限が存在しており、制限を越えてしまうとMCPサーバーの実行に影響が出ることがあります。とはいえ、tool名はLLMが実行対象を決めるための判断材料となっているため、短縮しすぎることはできません。

そこで今回追加された title の出番です。title を次のように設定します。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const mcpServer = new McpServer({
  name: "Sample MCP Server",
  version: "0.0.1"
});

mcpServer.registerTool(
  "addition",
  {
    description: "足し算をする",
    inputSchema:{
      a: z.number(),
      b: z.number()
    },
    annotations: {
      title: "add two numbers",
    }
  },
  ({ a, b }) => {
    return {
      content: [{ type: "text", text: String(a + b) }]
    };
  }
);

MCPクライアントでtool情報を再確認すると、次のような出力に変化します。

╭───────────────────────────────────────────────────────────────────────────────────────────╮
│ Tools for sample (1 tools)                                                                │
│                                                                                           │
│ ❯ 1. add two numbers                                                                      │
╰───────────────────────────────────────────────────────────────────────────────────────────╯

╭───────────────────────────────────────────────────────────────────────────────────────────╮
│ add two numbers (sample)                                                                  │
│                                                                                           │
│ Tool name: addition                                                                       │
│ Full name: mcp__sample__addition                                                          │
│                                                                                           │
│ Description:                                                                              │
│ 足し算をする                                                                                │
╰───────────────────────────────────────────────────────────────────────────────────────────╯

title を活用することで、Full nameの文字数制限を気にすることなく、よりわかりやすい名前をMCPクライアントに提供できるようになります。

MCPサーバーからの出力データの構造化

MCPサーバーにtool等を登録する際に inputSchema を設定することは以前から可能でしたが、今回のバージョンアップから outputSchema を設定できるようになりました。

modelcontextprotocol.io

outputSchema を定義して、MCPサーバーからのresponseに、content とは別に structuredContent を設定することで、MCPクライアントは構造化されたデータを受け取ることができるようになります。

実際に outputSchema を設定したMCPサーバーのtoolを見てみましょう。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const mcpServer = new McpServer({
  name: "Sample MCP Server",
  version: "0.0.1"
});

mcpServer.registerTool(
  "addition",
  {
    description: "足し算をする",
    inputSchema:{
      a: z.number(),
      b: z.number()
    },
    outputSchema: {
      result: z.number().describe("Sum of the two numbers")
    },
  },
  ({ a, b }) => {
    const result = a + b;
    return {
      content: [{ type: "text", text: JSON.stringify({ result }) }],
      structuredContent: {
        result
      }
    };
  }
);

toolを登録する際に、inputSchema だけではなく outputSchema も設定しています。更にtoolのresponseには content に加えてstructuredContent を追加しています。

後方互換性を持たせるために、content には structuredContent をJSON文字列に変換して返します。

これらの設定により、MCPクライアントはtoolの実行結果をより構造化された形で受け取ることができます。

今回の outputSchemastructuredContent の追加により、MCPクライアントとLLMがMCPサーバーからのresponseをより適切に解析して利用できるようになることを期待できます。

Elicitation

最後になりますが、今回のMCPの新バージョンで追加された機能の中でも特に注目すべき機能が Elicitation です。

modelcontextprotocol.io

Elicitation を活用することで、MCPサーバーとMCPクライアントの通信中に、ユーザーに追加情報を要求できるようになります。

今まで紹介したMCPの機能とは一線を画しているのでイメージしづらいと思いますので、実際のコードと具体例で説明していきます。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const mcpServer = new McpServer({
  name: "Sample MCP Server",
  version: "0.0.1"
});

mcpServer.registerTool(
  "validate_username",
  {},
  async () => {
    const elicitInputResponse = await mcpServer.server.elicitInput({
      message: "Input your username.",
      requestedSchema: {
        type: "object",
        properties: {
          username: {
            type: "string",
            title: "your username",
            description: "input your username."
          }
        },
        required: ["username"]
      }
    });

    if (elicitInputResponse.action !== 'accept') {
      throw new Error("username is required.");
    }

    const userName = elicitInputResponse.content?.['username'] as string;
    if (userName.length > 12) {
      throw new Error("username must be less than 12 characters.");
    }

    return {
      content: [{ type: "text", text: `${userName} is valid.` }],
    };
  }
);

elicitInput を呼び出すことで、ユーザーに追加情報を要求できます。GitHub Copilotで実行した場合、次のような表示になります。

elicitInputの要求

usernameを入力するように要求されているので、次のように入力してみます。

usernameを入力

追加要求が成功した場合、ユーザーの入力内容を取得でき、その内容を元に処理を続行できます。

今回は入力されたユーザー名の長さをチェックして、12文字以下であれば有効なユーザー名として処理を続行しています。

今回は12文字以内で入力して送信したため、次のような結果になりました。

toolの実行結果

また、elicitInput は文字列の入力だけではなく、enumを使って選択式にするといったことも可能です。選択式にすることにより、入力内容からの分岐をより明確にできます。

mcpServer.server.elicitInput({
  message: "select period",
  requestedSchema: {
    type: "object",
    properties: {
      period: {
        type: "string",
        title: "Period",
        description: "Select the period",
        enum: ["today", "yesterday", "this_week"],
        enumNames: ["Today", "Yesterday", "This week"]
      }
    },
    required: ["period"]
  }
});

期間を選択

このように Elicitation を活用することで、MCPサーバーからの追加要求を通じて、ユーザーとのインタラクションをより柔軟に行うことが可能になります。MCPサーバーの使い方、作り方、提供内容がより多様化し、ユーザーにとっても使いやすいツールを提供できるようになることが期待されます。

まとめ

いかがでしたでしょうか?

今回紹介したMCPの新バージョンでは、 titleoutputSchemastructuredContent、そして Elicitation といった重要な機能が追加されました。

これらの機能は、MCPサーバーとMCPクライアントの連携をより強化し、ユーザーにとって使いやすいツールを提供することが期待できます。

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

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

【2025年上半期】Findy Tech Blogの人気記事まとめ

こんにちは。Developer Productivity Engineer(DPE)兼 Findy Tech Blog編集長の高橋(@Taka-bow)です。

おかげさまで、Findy Tech Blogは2年目に突入しました。 この1年で、私たちのブログは多くのエンジニアやIT業界関係者の皆さんにご愛読いただき、記事の内容もますます多様化・充実してきたと感じています。

日々の開発現場で役立つノウハウや、最新技術のトレンド、エンジニアの日常など、さまざまなテーマを取り上げてきました。 「現場で本当に使える知見がほしい」「他社のエンジニアはどんな工夫をしているのか知りたい」「自分の成長のヒントを探したい」――そんな方々にとって、少しでもヒントや刺激となる記事をお届けできていれば幸いです。

今回は、2025年上半期に特に多くの反響をいただいた記事を、ランキング形式でご紹介します。 技術のトレンドから生産性向上テクニックまで、見逃していた記事が見つかるかもしれませんよ!

それでは、2025年上半期のFindy Tech Blogを一緒にふりかえっていきましょう!

2025年上半期トピックス

「テックブログ運営 井戸端会議〜2025年を走り切るために〜」というLT大会を開催

年明け早々に「テックブログ運営」という、ありそうでないテーマでLT大会を開催しました。

LT大会では、株式会社ログラスの粟田さん、株式会社Goalsの今村さん、株式会社リブセンスの鈴木さん、フューチャーアーキテクト株式会社の伊藤さん、株式会社タイミーの吉野さん、ウェルスナビ株式会社の長さんという豪華なメンバーにご登壇いただきました。

テックブログと一口に言っても、その目的や運営の悩みは本当にさまざまであることを、あらためて実感しました。 当日の雰囲気や盛り上がりは、Xのまとめからも感じていただけると思います。 posfie.com ファインディからは、戸田さんが Findy Tech Blog の誕生秘話や立ち上げ時のターニングポイントについて、私(高橋)は運営における定量的な測定目標の考え方や、普段どんな点を意識しているかについてお話ししました。これらは今も変わっていません。資料もぜひご覧ください!

speakerdeck.com

speakerdeck.com

【2025年上半期(1月〜6月)】PV数ランキングTop3

2025年上半期、Findy Tech Blogには数多くの注目記事が登場しましたが、ここからは、上半期で一番アクセス(PV)のあった記事を紹介します!

第3位

\ 第3位 /13,710 PV

ファインディのエンジニアたちが自身の成長に影響を与えた一冊を語る人気シリーズ「エンジニア達の人生を変えた一冊 Part4」がランキング。

記事では、『コンピュータの構成と設計』(通称「パタ&ヘネ」)や『体系的に学ぶ 安全なWebアプリケーションの作り方』、そして『現場で役立つシステム設計の原則 変更を楽で安全にするオブジェクト指向の実践技法』といった名著が取り上げられており、それぞれがどのようにエンジニアたちの視点やスキルに変化をもたらしたのかが語られています。

とても実直なラインナップでしたが、多くの方に読まれました。ぜひチェックしてみてください!

第2位

\ 第2位 /14,012 PV

2位は、こちらも人気シリーズの「エンジニア達の自慢の作業環境を大公開 Part6」でした!

第6弾となるこの記事では、ファインディエンジニアの安達さん、土屋 (しゅんそく)さん、秋田さんの3名それぞれが、生産性向上と快適性を追求した作業環境を詳しく紹介しています。単なるガジェット紹介にとどまらず、各エンジニアがどのような思想で作業環境を構築しているかが詳しく語られています。生産性向上、身体への配慮、空間の美しさやコストパフォーマンスなど、それぞれ異なる優先順位で環境を整えており、エンジニアの多様な働き方スタイルが見えてくる内容となっています。

第1位

\ 第1位 /14,743 PV

2025年上半期、最も多くの方に読まれた記事は「【エンジニアの日常】これが私の推しツール!〜日々の開発を豊かにするおすすめツール〜 Part2」でした。

エンジニアの日常シリーズの人気企画「推しツール」第2弾。Findyのエンジニアたちが日々の開発で愛用しているツールやOSSを紹介し、Neovimやlazygit、Raycastなど、業務効率化に役立つツールの活用法やおすすめポイントを詳しく解説しています。他のエンジニアの工夫やツール選びを知りたい方におすすめの記事です。

2025年上半期のトップ3は、いずれも【エンジニアの日常】シリーズからのランクインとなりました。

【2025年上半期(1月〜6月)】はてなブックマーク数Top3

続いては、はてなブックマーク(はてブ)の数が多かった記事のランキングをご紹介します。 PVランキングとはまた違った切り口で、読者の皆さんが「あとでじっくり読み返したい」「何度も参考にしたい」と思った記事が上位に並びました。 日々の業務や学びの中で役立つと感じていただけた記事が多くランクインしているのではないでしょうか。 それでは、はてブ数Top3を見ていきましょう!

第3位

\ 第3位 /131 users

Findyの爆速開発シリーズの一環として、生成AI活用の実践編を紹介しています。MCPサーバーの作成を通じて、実際の開発現場でどのようにAIを活用しているか、具体的な実装方法や効果について詳しく解説しています。AI技術を活用した開発効率化に関心のあるエンジニアにおすすめの記事です。

第2位

\ 第2位 /136 users

PVランキングでも3位に入った人気シリーズ「エンジニア達の人生を変えた一冊 Part4」が、はてブランキングでも2位にランクイン!

第1位

\ 第1位 /190 users

2025年上半期、最も多くのはてブが付いた記事は「Findyの爆速開発を支えるタスク分解」でした!

ファインディの開発チームが実践している効率的なタスク分解手法について詳しく解説。複雑な機能開発を小さな単位に分割し、段階的に実装していくことで、開発速度と品質を両立させる方法を紹介しています。開発生産性向上に関心のあるエンジニアやマネージャーに特に人気の記事となっています。

おわりに

2025年上半期のトピックスや、公開した35本の記事の中から注目の内容をランキング形式でご紹介しました。ここでご紹介しきれなかった記事もたくさんありますので、ぜひ他の記事もあわせてご覧いただければと思います。

今後も新しい技術への挑戦や、ファインディならではの開発の取り組みについて、積極的に発信していきます。 また、読者の皆さんからのコメントやSNSでの反応は、私たち編集部にとって大きな励みです。 これからも「面白い!」「参考になった!」と思っていただける記事をお届けできるよう、ファインディエンジニア一同取り組んでまいります。

引き続きFindy Tech Blogをよろしくお願いいたします。


ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募ください。

herp.careers

MCPとAIエージェントを活用してSlackから顧客情報を横断的に検索できるようにした話

こんにちは。データエンジニアの田頭(tagasyksk)です。 本記事では、MCPとAIエージェントを活用して、複数CRMの顧客情報を横断的に検索できるようにした事例をご紹介します。

背景

ファインディでは、エンジニア組織をあらゆる場面で支援するため、複数のプロダクトを展開しています。

事業成長に伴う課題として、お客様の大切な情報がプロダクト毎にサイロ化してしまう状況が起きました。
そこで、この課題を解消し、一社でも多くのお客様にファインディの価値を届けるため、CRMに蓄積されていた顧客情報をBigQueryに集約し、部門横断で利用できる「共通企業マスタ」を構築しました。 これにより、全部門が常に同じ最新の顧客情報を参照できるようになり、スムーズな連携が可能な体制を整えました。

しかし、この共通企業マスタをどのようにセールスチームやCSチームに届けるかが新たな課題となりました。 全員にSQLを書かせるのは現実的でなく、新しい分析インターフェースを作るのも工数がかかります。そこで、MCPとAIエージェントを活用したSlack上での企業検索システムの構築に取り組みました。

システム構成図

Slackとソケットモードを利用して疎通するAIエージェントサーバーと、後述するBigQueryのMCPサーバーをCloud Runのマルチコンテナ構成を利用してホスティングしています。

技術選定

AIエージェントのフレームワークには、GoogleからリリースされているAgent Development Kit(ADK)を採用しました。

google.github.io

ADKを選定した理由は次の通りです。

  • エージェント間連携の簡易さ
  • Google Cloud統合
  • MCP Toolbox for Databasesによる簡単なBigQuery接続

エージェント間連携の簡易さ

ADKでは、次のようにシンプルなコードでエージェント間でのオーケストレーションを実装できます。

今回のケースでは、企業の業務情報や従業員数をWEBから取得したいユースケースがあったので、Google検索ができるエージェントをサブエージェントとして実装しています。

# Google検索で企業の情報を取得するエージェント
google_search_agent = LlmAgent(
    model="gemini-2.5-flash",
    name="google_search_agent",
    description="A helpful AI assistant that can search company information from google.",
    instruction=GOOGLE_SEARCH_AGENT_INSTR,
    tools=[google_search],
)

root_agent = LlmAgent(
    model="gemini-2.5-pro",
    name="company_master_agent",
    description="A helpful AI assistant that can search company.",
    instruction=ROOT_AGENT_INSTR,
    sub_agents=[google_search_agent] #Google検索エージェントをサブエージェントとして追加
)

タスクごとに細かくサブエージェントを立てられるため、非常に見通しの良いエージェントシステムが構築できます。

Google Cloud統合

データ基盤をBigQueryで構築しており、Geminiも活用している弊社にとって、権限やホスティングに必要な知識を新しくキャッチアップする必要がないのはかなり大きかったです。

MCP Toolbox for Databasesによる簡単なBigQuery接続

MCP Toolbox for Databasesでは、次のようなyamlファイルを定義するだけで簡単にBigQueryへの接続情報をMCP化できます。

my-bigquery-source:
  kind: bigquery
  project: ${your_project}
  location: asia-northeast1
toolsets:
  search_company:
    - search-company-by-name
tools:
  search-company-by-name:
    kind: bigquery-sql
    source: my-bigquery-source
    description: 企業情報を企業名から検索する。
    parameters:
      - name: company_name
        type: string
        description: 企業名
    statement: SELECT * FROM `${your_dataset}.companies` WHERE company_name LIKE CONCAT('%', @company_name,'%');

MCPサーバーは、次のようなコマンドで簡単に起動できます。

containers:
  - image: us-central1-docker.pkg.dev/database-toolbox/toolbox/toolbox:latest
    name: toolbox
    args:
      - "toolbox"
      - "--tools-file"
      - "/app/tools.yml"
      - "--address"
      - "0.0.0.0"
      - "--port"
      - "5001"

エージェントからは次のように参照させると、yaml上で登録したtool(今回はsearch-company-by-name)を使えるようになります。

from toolbox_core import ToolboxSyncClient

toolbox = ToolboxSyncClient("http://localhost:5001")
search_company_tools = toolbox.load_toolset("search_company")

agent = LlmAgent(
    model="gemini-2.5-pro",
    name="company_search_agent",
    description="A helpful AI assistant that can search company in BigQuery",
    tools=search_company_tools
)

このように事前にBigQueryとの接続を定義しておくことで、意図したSQLを使ってデータにアクセスさせる事ができ、不要なデータベースの参照や誤ったコマンドを防ぐことができました。

工夫した点

オーケストレーションの設計

メインエージェントのInstructionはサブエージェントのユースケースのみを記載し、BigQueryやGoogle検索の具体的な利用方法はサブエージェントのInstructionに記載しています。 これにより、メインエージェントは全体のオーケストレーションに集中し、各サブエージェントは専門的なタスクに特化できるような設計と なっています。

ツールを搭載したサブエージェントの呼び出しについて

2025年7月現在、ビルトインツールやPythonの関数で定義したツールを搭載したエージェントを2つ以上同時にサブエージェントとして呼び出すことができません。

github.com

エラー回避策として、エージェントをToolとして呼び出すAgentToolというラッパーを使っています。

# toolを持ったサブエージェントを定義
google_search_agent = LlmAgent(
  ~~~,
  tools=[google_search],
)
bigquery_search_agent = LlmAgent(
  ~~~,
  tools=[bigquery_search],
)
# AgentToolでラップ
google_search_agent_tool = AgentTool(agent=google_search_agent)
bigquery_search_agent_tool = AgentTool(agent=bigquery_search_agent)
# メインエージェントからはツールとして参照
root_agent = LlmAgent(
  ~~~,
  tools = [google_search_agent_tool, bigquery_search_agent_tool],
)

Slack統合

新しいツールを導入することで利用者の負担を増やすことを避けるため、既に社内で日常的に使用されているSlack上でやりとりできるシステムを構築しました。 ソケットモードで送信されてきたメッセージでエージェントを起動し、返答をSlackに返却するMCPクライアントを実装しています。

class SlackToADKClient:
    """Slack メッセージを ADK エージェントに橋渡しする MCP クライアント"""

    def __init__(self):
        self.slack_app = AsyncApp(token=SLACK_BOT_TOKEN)
        self.session_service = InMemorySessionService()

    async def handle_slack_message(self, event, say):
        """Slackメッセージイベントを処理"""
        user_id = event.get("user")
        message_text = event.get("text", "")
        
        # エージェントに問い合わせ
        response = await self.query_adk_agent(message_text, user_id)
        await say(text=response)

    async def query_adk_agent(self, message: str, user_id: str):
        """エージェントにクエリを送信"""
        # セッション管理
        session = await self.session_service.get_or_create_session(~~~)

        runner = Runner(
            agent=self.company_agent,
            session_service=self.session_service,
        )
        # エージェントの実行
        events = runner.run_async(~~~)
        # ~~~応答処理~~~
        return response_text

Slack側からは、Slack Botにメンションする形で簡単に企業情報を検索できるようにしました。

企業名で検索すると共通企業マスタの内容を回答してくれ、かつ事業内容などの企業マスタに含まれない情報はGoogle検索をベースにして回答してくれるようになっています。

導入後の効果

運用開始から1ヶ月で、インサイドセールスやカスタマーサクセスのメンバーの40%近くに利用されています。

ユーザーからは次のような声をいただきました。

  • 各サービスごとの社内担当者がすぐわかるようになり、社内連携が迅速になった
  • Slackで情報の確認ができるため、展示会やイベントの会場からスマホで企業の情報を得られるようになった

一方で、検索機能については次のフィードバックもいただいています。

  • 全角アルファベットで検索したら、共通企業マスタ上では半角で登録されていて検索できなかった
  • 同一会社名で重複しているレコードが表示され、どちらが正しいかわからない

この課題については情報源である共通企業マスタの品質向上によって解決していけるものです。データ品質のテストをより厚くしたり、各CRMの担当者と協力してデータクレンジングを進めることで改善を進めています。

今後の展望

現在の検索機能をベースに、さらなる機能拡張を計画しています。

例えば、現在は企業名に基づいた検索のみ実装していますが、企業マスタに存在する様々なカラムから検索フィルタをエージェントが自動で作成し、営業リストとして提供する機能などを考えています。

終わりに

いかがでしたでしょうか?今回は弊社でのMCPとAIエージェントの活用について書きました。

AIエージェントの活用は、単純な検索だけでなく、将来的にはより高度な顧客分析や提案機能へと発展させることができる可能性を秘めています。今回の事例が、同様の課題を抱える組織の参考になれば幸いです。

弊社ではデータ基盤を共に育てていくメンバーや、AIエージェントなどのデータ利活用を推進するメンバーを募集しています。少しでも興味が湧いた方はカジュアル面談お待ちしております!

herp.careers herp.careers

60万行を超えるフロントエンドのリアーキテクチャとCI戦略

こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ 開発のフロントエンドリードをしている @shoota です。

ファインディのフロントエンドでは多くのプロダクトでNxを用いたモノレポを構築しています。

tech.findy.co.jp

Findy Team+のフロントエンドもNxを採用し、各パッケージ間の依存関係の管理やライブラリのマイグレーションなどの恩恵を受けています。 なかでも強力なキャッシュ機構をベースとしたCIの高速化はなくてはならない存在となっています。

以下は、このブログの執筆時点での Findy Team+のフロントエンドリポジトリが実行するCIの統計情報です。

Team+ の CI実行

直近30日間でCIの実行回数は2500回、平均時間は7分です。 そしてNxの機能によって削減された実行時間はなんと167日分(約4000時間)にもなります(キャッシュはネットワークで共有されるので開発者のローカルでも有効です)。

しかし我々はこのような強力かつ高速なCIの環境を常に維持し続けていたわけではありません! 過去には平均のCI実行時間が13分以上かかっており、開発速度に大きな影響を及ぼしていました。

そこで今回はNxでのキャッシュ率を高め、CI時間を短縮するためのNxをベースとしたリアーキテクチャの実例についてご紹介したいと思います。

CI高速化のためのリアーキテクチャ

2024年のはじめ頃から、Team+のフロントエンドのCI時間は伸び続ける傾向が見え始めてきました。 プロダクトの肥大化と複雑化、そして開発メンバー数の急増によって、コードベースの増加速度も急成長をしていました。

「開発速度が上がるほどCI時間が伸びる」というアンチパターンを打開すべく、1年以上をかけてモノレポの内部構造の再設計をしました。

  • ページレイアウトモジュールの分離、ライブラリ化
  • 共有モジュールの分割
  • 翻訳アーキテクチャの刷新
  • UI コンポーネントのモジュール分割

今回はこの内容を紹介していきたいと思います。

ページレイアウトモジュールの分離、ライブラリ化

まず初めに目をつけたのがページレイアウトに関連するモジュールでした。Team+のサイドナビゲーションやヘッダーUIなどのページ全体のレイアウトに関わるコードです。 これらはモノレポの共有モジュールの中に配置されていましたが、その役割ゆえにほぼすべての画面で利用します。

レイアウトを変更することは稀ですが、共有モジュール内にレイアウトが所属することでモジュール全体に依存関係を持ちます。このときレイアウト以外のコードを変更をすると、レイアウトを利用しているものすべてが依存関係にあるため、全画面のテストが発生してしまいます。

そこでレイアウト関連のコードを別モジュールに分離して、依存関係が集中しないようにしました。

図1. レイアウトモジュール分離

共有モジュールの分割

次にレイアウトを分離した後の共有モジュールを更に分割し、変更の影響範囲を効率化しました。

共有モジュールの中には古くからあり、成熟しており、そしてテストの重いものがいくつかありました。このような古参モジュールは多くの機能で利用します。一方で、最近の開発ドメインに向けて作られた新米モジュールも共有モジュールに存在します。

両者が同居していると日々のコード変更頻度と重いテストが複合し、全体効率を下げる要因になっていたため、別居計画を進めました。

図2. 共有モジュールの別居

変更頻度の低い古参モジュールを分離することで、開発を進めているドメインに関連した比較的軽いテストのみがよく回るような構造にできました。

翻訳アーキテクチャの刷新

これまでは通常のモノレポ構造の再設計でしたが、CI時間に最も影響を及ぼしていたのはここで紹介する翻訳システムでした。

Findy Team+ は日本語・英語・韓国語の3言語に対応していますが、これらの翻訳は1つのモジュールで集約管理していました。 しかし機能開発の高速化・大規模化に伴って、翻訳対象の文言も急増し、さらに韓国語対応を追加したことで爆発的な依存関係の連鎖が生まれ、CI時間を圧迫してしまいました。

図3. 翻訳辞書の一元管理

画面が追加されるごとに翻訳辞書が増え、かつ翻訳モジュールの変更が発生するので、全画面のテストが実行されます。 次の画面が追加されるとその前に追加された画面もテスト対象になり、さらに実行時間が伸びます。この繰り返しによってCI時間が指数的に長くなっていきました。

そこで画面個別の辞書を画面モジュールに分散し、それぞれの画面の開発で発生するコード変更が画面モジュールのなかで閉じるようにしました。分散した辞書は画面表示前に動的に読み込んで表示できるような修正も行いました。

図4. 翻訳辞書の分散

画面がどんどん追加されても全画面のテストが起きなくなり、開発速度・並行数が上がってもCI時間が伸びない構造に生まれかわることができました。 共有モジュールの分割とは異なり、依存関係は変更せずにコード変更の発生箇所を移動することで、平均の実行時間を大きく縮めることができました。

UI コンポーネントのモジュール分割

上記の3点の改善によってCI時間は概ね安定して短縮できていましたが、更にTeam+を構成するUI コンポーネントの分離を進めました。

ボタンやフォームなどのプリミティブなUI(HTMLに近いもの)とTeam+特有のセマンティックなUIに分類し、依存の親子関係となるように分けました。 これも先述のようにボタンコンポーネントやフォームなどのプリミティブなUIは変更頻度が少なく、かつ依存度が高いことを見据えた分離です。

UI分離

変更頻度の高いモジュールとそれに依存したモジュールのテストが実行されるので、Nxのキャッシュ率を向上させることができました。

コードベースとCI時間の比較

CI高速化のためのリアーキテクチャの内容をご紹介してきましたが、タイトルの「60万行」にも触れたいと思います。 今回のリアーキテクチャを開始した時点では、Team+のコード量は次のようになっていました。

Language files blank comment code
TypeScript 5422 42462 13430 353578
JSON 349 0 0 51694
以下略
SUM: 6212 46170 17230 419602

TypeScriptのコードとして約35万行、翻訳辞書を定義しているJSONを合わせると約41万行です。 これらのコードの平均のCI実行時間が13分以上かかっていました。

そして冒頭にも記載したとおり、現在では平均のCI実行時間が7分程度になっています。この改善の間にも多くの機能リリースをしてきました。 こちらが現在のTeam+のコード量です。

Language files blank comment code
TypeScript 9171 68280 22279 552539
JSON 672 6 0 66888
以下略
SUM: 10453 69658 22424 635517

TypeScriptのコードとして約55万行、翻訳辞書を定義しているJSONを合わせると約62万行です。

つまりコードベースとして約1.5倍の成長をしながら、CI時間を53%程度まで削減できたのです!!

まとめ

ここまで拝読いただきありがとうございます。

今回は Findy Team+の開発を支えるCIとその改善内容についてご紹介いたしました。内容を以下3点にまとめてます。

  • Nxベースのモノレポアーキテクチャを再設計することで変更に依存しない高速なCI環境をつくることができる。
  • モノレポ間の依存関係と、開発現場のコード変更の傾向をつかむことがCI速度改善のカギになる。
  • CI速度の改善は規模の大きなコード、組織にとって不可欠な改善のひとつと言える。

なお今回のリアーキテクチャでいちばん大変だったのは、変更対象のCI時間が基本的に長いことでした。 CI時間が長いモジュールを修正し続けているので当然なのですが、効果がでるまでの我慢期間が長かったことは胸に刻みたいと思います。


現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから herp.careers