Findy AI Meetup in Fukuoka #2 参加レポート
2025年9月7日、福岡で開催されたオフラインイベント「Findy AI Meetup in Fukuoka #2」に参加してきました。
参加者は30名ほど。
（第1回が好評だったので、わずか1ヶ月で第2回が開催されたみたいです。嬉しいですね。)
2回目の参加となる今回は、「AI×プロダクト開発 AI活用の、その先へ」というテーマで、より実践的で深い内容が展開されました。
（個人的な）前回からの流れ
第1回は、
- 「Nx × AI によるモノレポ活用」
- 「Findy Freelance利用シーン別AI活用例」
- 「ファインディ株式会社における生成AI活用までの軌跡」
の3本立てでした。
AIが真価を発揮するためには、コーディング規約の統一、ドキュメントの整備、振る舞いを定義するテストコードといった「人間にとってフレンドリーな開発環境」が不可欠 だということを痛感し、以下の記事を書きました。
懇親会では、テックリードの方（@starfish0206 ）から 「MCPは廃れない。学ぶ価値があるよ！」 という熱い言葉をいただき、私もMCPを活用して業務にセキュアなドキュメントRAGを導入してみました。
前回の経験を活かして、色々と業務で実践してみていた最中だったので、今回の第2回はうってつけでした。
というわけで参加レポートです。
セッション1: カスタムインストラクション＆スラッシュコマンドの実践知
資料：
9割のエンジニアがAIを使う時代
@puku0x さんのセッションは、約9割のエンジニアがAIツールを業務で利用しているという統計から始まりました。
FindyではGitHub Copilot、Claude Code、ChatGPT、Gemini、Devin、Kiro、Cursor、Junieなど多様なツールが導入されており、特にGitHub CopilotとClaude Codeの利用者が多いとのこと。
カスタムインストラクションの書き方のコツ
カスタムインストラクションとは、生成AIのコンテキストとして渡す文章のこと。
copilot-instructions.md、CLAUDE.md、AGENTS.mdなど、ツールによって名前は様々ですが、本質は同じです。
効果的な書き方の3つのポイント
1. 簡潔に書く
- 長い文章より箇条書き
- 複雑な表現を避ける
2. 複雑な条件より大量のサンプル
- お手本となるコードを丸ごとコピペするだけでも効果あり
- 生成AIは確率論的な動きをすると捉える
- 「必ず〜」「〜のみ」「重要」などのキーワードで制御可能
- とにかく思いつく限りサンプルを書く（←たいせつ）
- サンプル数が多いほど勝手なことをしにくくなる
3. 英語的な表現を意識する（英語で書く必要はない）
- 曖昧な表現を避ける
- 主語や目的語を省略しない
- 「〜してください」より「〜する」「〜しない」
英語的な表現、というのは面白いですね。
applyToによる賢い適用範囲制御
GitHub Copilotの特徴として、applyToによる適用範囲の絞り込みが可能です。
---
applyTo: '**/*.jsx,**/*.tsx'
description: Reactコンポーネントのグッドプラクティス
---
これにより、ファイル毎にコンテキストを切り替えることが可能。
ただし現在はAskモードでのみ動作確認されているとのこと。
今後のAgentモード対応に期待です。
実例）コミットメッセージの自動生成
実際に使っているコミットメッセージ生成の設定を詳しく紹介してくれました。Conventional Commitsに従って、typeとscopeを自動判定させる例です
---
applyTo: '**'
description: 'コミットメッセージの生成'
---
コミットメッセージは[Conventional Commits]に従って記述する
## type（必須）
- `feat`: 新機能や既存機能の変更
- `fix`: バグ修正
- `docs`: ドキュメントのみの変更（*.mdを追加、変更した場合）
- `test`: テスト追加・修正（*.spec.*を追加、変更した場合）
## scope（任意）
- ディレクトリ名が`package.json`の時: `deps`
- ディレクトリ名が`.github/**`の時: `github`
- ディレクトリ名が`apps/frontend/**`の時: `frontend-app`
## コミットメッセージの例
feat(frontend-feature-xxx): add social login
fix(frontend-feature-xxx): fix validation
docs(*): update README.md
これを設定することで、適切なコミットメッセージが自動生成されるようになります。
カスタムスラッシュコマンドの活用
再利用可能なプロンプトを/コマンド名で呼び出す機能。定型作業の自動化に最適です。
実例1: マージ済みブランチの削除
---
mode: 'agent'
model: GPT-4.1
tools: ['runCommands']
description: 'Remove merged branches'
---
ローカルの作業ブランチのうち、マージ済みのものを削除します
## 手順
## 1. マージ済みブランチの確認
git branch --merged|egrep -v '\*|develop|master|main'
## 2. マージ済みブランチの削除
git branch --merged|egrep -v '\*|develop|master|main'|xargs git branch -D
実例2: PR自動作成（かなり高度）
- 現在の状態確認
- ステージされた変更から適切なブランチ名を決定
- lint/typecheck/testの実行
- コミットメッセージの自動生成
- PRの作成（タイトルは日本語、コミットメッセージは英語）
メタな使い方：Claude CodeにClaude Codeの設定をさせる
これは面白い発想でした。
↓デスクトップ通知の有効化をClaude Code自身にやらせるスラッシュコマンド
---
description: デスクトップ通知の有効化
---
Claude Code の通知を設定します。
macOS のみ対応しています
## スクリプトエディタの通知設定を開く
open "x-apple.systempreferences:com.apple.Notifications-Settings?id=com.apple.ScriptEditor2"
## ローカル設定を更新する
"hooks": {
"Notification": [{
"matcher": "",
"hooks": [{
"type": "command",
"command": "osascript -e 'display notification \"Claude Codeが許可を求めています 💬\" with title \"Claude Code\" subtitle \"確認待ち\" sound name \"Glass\"'"
}]
}]
}
運用上の工夫
Claude CodeとGitHub Copilot両対応で提供する
- GitHub Copilot側をマスタとして管理
- Claude Codeから
@path/to/fileでプロンプトファイル参照 - プロンプトの二重管理を避ける
生成AIの利用を前提としたREADMEの見直し
- 従来の人間向けドキュメントから、AI＋人間向けへ
- サンプルコードを豊富に含める
- 明確で具体的な指示を記載
感想
弊開発部ではちょうどcopilotの知見を集めていたところだったのでうってつけでした。
（applyToでファイル毎にコンテキストを切り替えられるという知見を早速共有しました）
claude codeに自分のセットアップをさせる、というのも面白いですね。
セッション2: Context as Codeで荒馬を乗りこなす
資料：なし（後日公開かも）
手書きのメモを元にレポートを書きます。
生成AIという荒馬の危険性
松尾宏介さん（楽天カード）のセッションの最初で示された
「電話が1億人に普及するのに82年、ChatGPTはたった2か月。」
という統計が面白かったです。
この速度感の中で、私たちは新しい開発の形を模索しており、まさに「我々はとんでもない時代にエンジニアをしている」わけです。
しかし、（我々エンジニアが特に知っているように）生成AIには危険が潜んでいます。
- ハルシネーション：もっともらしい嘘をつく
- 冪等性がない：同じ入力でも異なる出力
-
カタストロフィ：
rm -rf /を実行されたり、gitの履歴が全部消されたという実例
正しい準備とは何か
「AIを使えば生産性上がる？」そうではない。
「正しく準備をしたうえでAIを使えば生産性は上がる」。
では、正しい準備とは？
1. Diataxisフレームワークによるドキュメント体系化
- 解説：概念や背景を説明
- ガイド：特定のゴールへの道筋
- チュートリアル：手順を追って学習
- リファレンス：技術的な詳細情報
この4つに整理することで、別プロダクトの開発者でも必要な情報を見つけられる。
2. Single Source of Truth（SSOT）の徹底
- 情報源を1つに統一
- Gemini、Codex、Copilotで別のソースを見ないように
- 情報の流れを追跡可能にする
この 「情報源を統一する」 というのは@puku0x さんの発表と似通ったものを感じますね。
AIガバナンスの3つの課題
Gartnerも注目している（←経営層に響く魔法の言葉！）AIガバナンスの課題
- 透明性の確保：AIの判断プロセスを理解可能に
- 法令順守の効率化：コンプライアンスの自動チェック
- 信頼性と説明責任：誰が責任を持つのか
V字モデルで考える成長戦略
(ここのV字モデルの画像は資料が公開され次第追記します。)
「エンジニアがAIを育てて、AIがエンジニアを育てる」という言葉が印象的でした。
AIフレンドリーなチーム作りは小さな実験と学びの積み上げ。
V字の底から登っていくイメージで、少しずつ改善を重ねていく。
感想
弊PJのドキュメントを見返すと、一つのMarkdownファイルに「システムの背景説明」「環境構築手順」「API仕様」「トラブルシューティング」が全部混在しています。
これをDiataxis(発音が難しい)で整理すれば、AIも人間も 必要な情報にすぐアクセスできるのがかなり良いなと思いました。
セッション3: MCPという革命的プロトコルの実践事例
資料：
Findyの驚くべきMCP内製化戦略
発表者の@starfish0206 さんは、MCP公式のTypeScript SDKを利用して、Nxでmonorepo化することで社内MCPサーバーを量産する環境を整備していました。
なんと3日間で10個のMCPサーバー、30個のtoolを実装して社内エンジニアに配布したそうです。
（この開発速度には驚きました。）
具体的な活用事例として紹介されたものをいくつか詳しく見ていきます。
1. Figmaデータの自動分析
- Figma MCPでデザインデータを取得
- 守るべきデザインルールのプロンプトを動的に生成
- デザインデータとルールをLLMに食わせて分析
- 共通Componentとの差分チェックも自動化
ここで重要なのは 「MCPとLLMの責務を分けて運用する」 こと。
MCPはデータ取得と加工まで、分析・解析はLLMの役割という明確な切り分けです。
2. エンジニア教育への応用
- GitHubのAPIを実行してメンティーのPR一覧を取得
- レビュー内容と評価基準をLLMに食わせて自動評価
- GitHub Copilotの利用統計をmermaid記法で可視化
3. 開発フローの自動化
- GitHub MCPでissueからタスクを洗い出し
- コード修正を行い、lint/typecheck/testを通す
- PR作成まで自動化（PR概要文もLLMが生成）
- Sentry MCPで不具合を検知して自動修正PRまで作成
4. リポジトリを跨いだ参照
- Filesystem MCPを使って別リポジトリを参照
- バックエンドとフロントエンドのリポジトリが分かれている場合に有効
- 権限を与えるフォルダを指定できるので安全
管理画面をMCPで置き換える←賢すぎる
最も印象的だったのは「local MCP server for administrator pc」という発想です。
管理者用の画面を作るのではなく、ローカルMCPで管理者用機能を自然言語で提供するというアプローチ。
画面を作ると：
- UIデザインが必要
- フロントエンド実装が必要
- データ通信の設計が必要
- 認証・認可の実装が必要
時間がかかりすぎます。
MCPなら：
- 自然言語でCRUD操作が可能
- 画面なしでデータ操作を提供
- 初期開発・運用コストを最小限に
- Elicitation機能で「本当に実行しますか？」の確認も可能
このElicitationというのは、mcpサーバーが対話中にクライアントを介してユーザーに追加情報を要求する 機能です。
毎回Yes,Noを聞いてくれるので、気づいたらぶっ壊れていた、ということが無くなるわけですね。
Findy AI+というプロダクトへの実装
FindyさんはMCPを実際のプロダクト「Findy AI+」に組み込んでいました。
GitHub連携・プロンプト指示で生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。
リモートMCPサーバーとして提供することで、ユーザーは画面操作なしに自然言語で分析ができる。
ただし、「MCPという概念がまだ浸透していない」「MCPの設定からサポートが必要」という課題も共有されていました。
（「IT介護」 というパワーワード）
感想
弊社でも、社内ツールの管理画面作成で苦労している実例を耳にします。
（画面作るのめんどくさすぎるので、結局Excelで運用しがち）
自然言語で、しかもセキュアに操作できるMCPのアプローチはかなり理にかなっているなと思いました。
あと、「MCPは（HTTPのように）プロトコルだから廃れない」というのは本当にそう。
betする価値があります。
懇親会
セッション後の懇親会では、TVCM記念ノベルティをいただきながら、他の参加者と意見交換しました。
印象的だったのは、ある参加者から聞いた
「うちの会社でも最初はAI懐疑派が多かったけど、小さな成功体験を積み重ねることで、今では積極的に使うようになった。
大事なのは、最初から完璧を求めないこと」
という話でした。スモールステップの大事さですね...。
また、別の方からは、
「MCPの設定で苦労したけど、一度動き始めると開発速度が劇的に変わった。投資する価値は絶対にある」
などの話も聞けました。
こういった生の声を聞けるのも、オフラインイベントの醍醐味です。
おわりに
社内ではMCPという概念を説明するところから始めなければならず、設定のサポートも必要なのが現実です。
しかし、これは過渡期の現象だと思います。
（私は若いので体験していませんが、）かつてGitを導入する時も、CIを導入する時も、同じような抵抗や苦労があったのではないかと思います。
でも今では、それらなしの開発は考えられません。
AIツールも、MCPも、きっとそうなると思います。
自分自身がAIやMCP活用の先駆者となり、その知見を社内に還元していくことで、「AIと共に成長する組織文化」を醸成していきたいです。
第3回があればまた参加させていただこうと思います。
これからもQiitaで発信していくので、気になったらぜひいいね・フォローお願いします！