AIやツールで運用業務を効率化した先に見えた次のステップ

こんにちは。ファインディのTeam+開発部でエンジニアをしている古田（ryu-furuta）です。
この記事は、ファインディエンジニア #2 Advent Calendar 2025の22日目の記事です。

はじめに

2025年下期、私は「DevとOpsを融合する」というミッションを掲げ、問い合わせやアラートといった運用業務の改善にAIをいくつか活用していきました。

この記事では、Claude Code GitHub ActionsやNotion MCPを使った運用業務改善の具体的な実装方法を紹介します。
また、効率化を実現した先に見えてきた「次にやるべきこと」についても共有します。

AIを活用した運用改善を検討している方や、改善施策を打っても成果が出ないと悩んでいる方に読んでいただけると幸いです。

問い合わせやアラートに生じていた課題

私が携わるFindy Team+はエンジニア増加による開発チームの細分化・多数の機能リリース・連携するサービスの増加といった変化の中にあります。これにより、問い合わせやアラートなどの機能開発以外の運用業務でも複数の課題が生じていました。

• 問い合わせ/アラートの数が増加して機能開発のボトルネックになっている
• 問い合わせ/アラートに関連した機能・実装のコンテキストを知らないため調査コストが高い
• 問い合わせのやりとりはSlackのスレッドで行っているためステータスが分かりにくい
• 問い合わせのデータが蓄積されないため対策や将来の改善に活かせない

こういった課題を解消すべくAIやツールを活用した改善をこの2025年下期で取り組みました。

Claude Code GitHub Actionsでアラートの初期調査コストを削減

アラート通知はこのようにSentryを経由してSlackへ通知されます。

これだけを見てもどういったエラーでどこで発生したのか分かりません。
そのため従来はSentryのイシュー詳細に遷移し、スタックトレースを確認したり、そこからエディタで関連コードを調査したり、まず 状況把握をするための初期調査コストが高い という問題がありました。

この問題の改善に用いたのがClaude Code GitHub Actionsです。
Claude Code GitHub Actionsは、GitHub ActionsのワークフローからClaude Codeを呼び出せる機能です。

SentryからGitHubのイシューを作成したら自動で次のようなプロンプトのコメントをClaudeにメンションします。

このissueのdescriptionに当リポジトリで発生したエラーが記述されています。
このissueのdescriptionにはSentryのissueのIDが記載されています。
mcp__sentry__get_sentry_issueで記載されたIDのissueの詳細情報を取得してください。
mcp__sentry__get_sentry_issueで取得した結果やエラー発生箇所・周辺ファイルを閲覧し、エラーの発生原因の調査結果をissueのコメントに記載してください。
可能であれば修正対応のプルリクエストを作成してください。
プルリクエストを作成する際は次の3ステップで実行してください：

- エラーに対する初期の対応案（ドラフト）を作成してください。
- そのドラフトに対して、どこが良くてどこが改善できるかをレビューしてください。
- レビュー結果をふまえて、より良い最終的な対応案を提示してください。

これによってClaude Code GitHub Actionsが起動し、自動でエラー発生箇所の周辺調査や状況整理、うまく噛み合えばClaudeが作ったプルリクエストをマージするだけで対応が完了する時もあります。

▼実際にClaudeが作成したコメント例

この取り組みによってアラート発生時の初期調査コストを削減することができました。ケースによっては数時間かかっていた調査が数分で状況把握できるようになり、調査開始までの心理的ハードルも下がっています。

Notionのデータベースで問い合わせのチケット管理とデータ蓄積

前述したようにFindy Team+では数年間に渡ってSlackワークフローでの問い合わせ起票を行ってきました。
問い合わせのコミュニケーションに関してはSlackで過不足無いのですが、複数問い合わせが並行するとやりとりを追うのが大変だったり、現在のタスクの状況が分からなくなる問題が度々発生していました。
また問い合わせはプロダクトの改善に繋がる貴重な情報なのにそのデータが蓄積されずフィードバックループを回すことが出来ない、というのも大きな課題でした。

これを一気に解消したのがNotionのデータベースです。

Slackのワークフローでの問い合わせ起票を全てNotion Formに移行し、フォーム送信と同時に問い合わせの情報がデータベースに蓄積されるようになりました。

またデータベースでもチケット管理を行うようにしました。
対応期限のカラムやいわゆる「To Do」「In Progress」「Done」といった値を持ったステータスのカラムを用意し、Zapierを使ってリマインドの機構を設けました。
例えば対応期限を超過してもステータスが「Done」になっていない場合、Slackで担当者へリマインド通知を飛ばすといった自動化も行いました。

▼対応期限超過のリマインドメッセージ

Notionのデータベースを用いることでステータス管理や情報の蓄積が可能になり、問い合わせが抱えていた複数の課題を一気に解消することができました。
また、データが蓄積されることで次に紹介する取り組みにも繋がりました。

Notion MCPを使って過去事例の検索と自動調査

問い合わせ起票時には起票するメンバーに問い合わせに関連した「画面機能」「連携サービス」「メトリクス」といった情報をデータベースに入力してもらうようにしています。
さらに問い合わせの対応が完了したらLLMに問い合わせのやりとりを要約してもらい、その内容もデータベースに保存しています。
これにより半自動的に問い合わせについての情報を拡充していくことができています。

そしてアプリケーションのリポジトリに次の内容のClaude Codeのスラッシュコマンドを作成しました。

---
description: Notion上の問い合わせDBから類似の問い合わせを検索し、原因を調査する
---

- $ARGUMENTSは `collection://***` の問い合わせデータベースの中の問い合わせ(ページ)です。
- notion-fetchを使って $ARGUMENTS の問い合わせ内容を確認してください。
  - $ARGUMENTS の問い合わせと類似の過去の問い合わせを `collection://***` のデータベースから検索してください。
  - 検索の際は`summary`,`detail`,`tag`の各プロパティから類似の問い合わせを検索してください。
- この検索結果から $ARGUMENTS の問い合わせを当リポジトリのコードから調査してください。
- 最終的に次の結果を出力してください。
  1. 類似の問い合わせが見つかったかどうか
  2. 類似の問い合わせが見つかった場合、その問い合わせIDと概要(summary)
  3. $ARGUMENTS の問い合わせの原因調査結果

このスラッシュコマンドは内部でNotion MCPのtoolを利用しています。
これにより過去の問い合わせ情報というコンテキストを持ちながらClaude Codeがより詳細にコード情報を調査することを可能にしています。

出力サンプルを本記事に掲載したいところですが、あまりにも詳細に情報を出力しすぎてしまうため残念ながらここでの掲載は控えさせていただきます。

ただ私自身何度かこのスラッシュコマンドを問い合わせに実行してみて過去に類似問い合わせがあると問い合わせの要因等をかなり詳細に調査してくれることを確認しています。
また過去に類似問い合わせが無いとしても、問い合わせに関連した周辺処理の概況を説明してくれるので全くコンテキストを把握していない機能の問い合わせの調査コストを軽減できていると感じています。

取り組みの成果

今回紹介した取り組みにより、次のような成果を得ることができました。

• 問い合わせやアラートの状況が可視化され、分析可能な基盤が整った
• AIによる初期調査で調査の効率化が実現し、状況把握までの時間を大幅に短縮できた
• チケット管理によりステータスが明確になり、対応漏れを防げるようになった

一方で、可視化や効率化を行うだけでは問い合わせやアラートの件数自体は減少しませんでした。
機能開発が進み、利用者数も増加している中での自然な傾向でもあります。
可視化や効率化は部分的に対応コストを下げるものであり、それだけでは件数を減らす根本的な解決にはなりません。

今後の取り組み：根本原因の特定と改善の仕組みづくり

蓄積された問い合わせデータやアラート傾向を分析し、頻出する問題の根本原因を特定していきます。
暫定対処ではなく恒久対応を行うことで、問い合わせやアラートの件数自体を減らすことを目指します。
たとえば、問い合わせデータを「画面機能」や「連携サービス」ごとに集計し、特定の領域に問い合わせが集中していないかを可視化します。
集中している領域があればUIの改善やドキュメントの拡充、場合によっては機能自体の見直しを検討します。

また、これまでは改善活動に対する明確な行動指針がなく、暫定対処に留まりがちでした。
今後はインセンティブの設計をしっかり行い、改善活動が継続して実施される仕組みを作ります。
具体的には、来期から私も機能開発チームに合流し、改善対応もミッションの一部として進めていきます。
運用業務の当事者として改善に取り組むことで、フィードバックループを確実に回していきます。

まとめ

2025年下期開始当初、自分は昨今のAIの潮流もあって「AIがあれば運用業務の全てを改善できる！」と意気込んでいました。
実際に取り組んだ結果、AIやツールを活用していくらかの問い合わせやアラート対応の「可視化」と「効率化」を実現しました。
しかしこれらは対応を効率化するものであり、件数を減らす根本解決ではありません。今後は蓄積したデータを活用して恒久対応に繋げ、問い合わせやアラートの根本原因を取り除いていきます。

引き続きAIを活用しつつ、改善活動が継続する仕組みを作りながら本質的な改善に挑戦していきます！

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

herp.careers

AWS re:Invent 2025 参加レポート - ラスベガスの街がAWSに染まる1週間を体験してきた

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

adventar.org

はじめに

こんにちは、ファインディのPlatform開発チームでSREを担当している原（こうじゅん）です。

2025年12月に、アメリカ・ラスベガスで開催されたAWS re:Inventに参加してきました。

re:Inventは毎年ラスベガスで開催されるAWSの世界最大のカンファレンスで、世界中からエンジニアが集まります。

この期間中、ラスベガスの街全体がre:Inventの会場となり、最新のAWSアップデート情報のリリースや技術セッションの他、EXPO、re:Playパーティー、5K Raceなど様々なアクティビティが用意されています。

本記事では、技術セッションの内容よりも、会場の雰囲気やサブイベント、現地での過ごし方を中心にお伝えします。

技術セッションの内容を中心とした内容は先日投稿した AWS re:Invent 2025 参加レポート - 参加して感じた、AIOpsの本格的な到来に記載しているので、ぜひこちらも合わせて御覧ください。

re:Inventの規模感 - ラスベガスの街が会場に

会場は6つの施設に分散

re:Inventの会場は次の6つに分散しており、それぞれが巨大な施設です。

1. Encore
2. Wynn
3. The Venetian (メイン会場)
4. Caesars Forum
5. MGM Grand
6. Mandalay Bay

上の地図を見ても縮尺がわかりにくいですが、実際に現地で歩いてみると想像以上の距離があります。

メイン会場であるThe VenetianからMGM Grand付近まで実際に歩いてみると約1時間ほどかかりました。

さらに、各会場内も広大で、イベント全体を通じてかなりの距離を歩くことになります。

シャトルバスとモノレールで会場間を移動

会場間の移動手段は、シャトルバスかモノレールが基本です。

シャトルバスもひっきりなしに運行されており、私は期間中ずっとシャトルバスを利用していました。

街中やホテル内の至るところでre:Inventのバッジを付けた参加者とすれ違います。

まさに「ラスベガスの街全体がre:Invent」という雰囲気でした。

多数あるセッションカテゴリ

この複数ある巨大な会場の中で、様々なセッションが同時並行で行われます。セッションの種類は次の通りです。

• Keynote: 基調講演
• Breakout Session: 技術・事例セッション
• Workshop: ハンズオン形式
• Chalk Talk: 小規模なディスカッション形式
• Game Day: チーム対抗の技術チャレンジ

セッション数が膨大なため、見たいセッションを探すだけでも一苦労です。

また、移動時間込みでセッションスケジュールを考える必要があります。

re:Invent 2025 MCP Serverというイベント情報を調査できるMCPもあり、私はこれを利用してスケジュールを組んでいました。

builder.aws.com

Keynoteで発表された新サービスのアップデートに関するセッションは[NEW LAUNCH]という形で新しく登場してきます。

そのため、気になるアップデートがあれば、事前に組んでいたスケジュールから変更したり、柔軟にスケジュールを変えていく必要があります。

私の参加したスケジュールは次の通りです。その他の時間は、会場移動やEXPOへの参加などしていました。

今回は、Keynoteで発表されたDevOpsエージェント関連のワークショップを運よく予約できたこともあり、ObservabilityやAIOps系のセッションが多めの構成になりました。

• Scaling observability with generative AI (ARC311)
• Behind the scenes: How AWS drives operational excellence & reliability (COP415)
• Amazon ECS observability patterns and design decisions (CNS351-R)
• Opening Keynote with Matt Garman (KEY001)
• A deep dive on IAM policy evaluation (SEC402-R1)
• Best practices for cost optimization with AWS Backup (STG328-R)
• The Future of Agentic AI is Here (KEY002)
• Unveiling Amazon ECS workloads with AWS observability and agentic AI (CNS413)
• [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent (DVT337-R1)
• Infrastructure Innovations (KEY004)
• A Special Closing Keynote with Dr. Werner Vogels (KEY005)

技術セッションの感想を中心とした内容は先日投稿した AWS re:Invent 2025 参加レポート - 参加して感じた、AIOpsの本格的な到来に記載しているので、こちらもよろしければ御覧ください。

会場の様子

ここからは、セッション以外の会場の様子やサブイベントについての体験談を書いていきたいと思います。

フリードリンクと軽食

各会場の廊下には、コーヒー、ドリンク、サンドイッチ、ドーナツ、バナナなどの軽食がおいてあり、自由に飲食できます。

特に制限もないため、私はここで簡単に朝食を済ませたり、セッション後にコーヒーを入れてホテルに持ち帰ったりしていました。

Meal会場でのビュッフェ

Meal会場ではビュッフェ形式の食事が提供されています。

イベント期間中は軽食とMeal会場の食事が用意されているため、イベント時間中は会場だけで出費なしで食事を賄うことは可能です。

会場や日にちによって出る料理が異なったりしてますが、注意点としてはLunchの時間が11:00 AM ~ 1:00 PMなど食事できる時間が限られていることです。セッションの時間と様子を見てLunchの時間を確保する必要があります。

厳重なセキュリティチェック

各会場の入口には、セキュリティゲートが設置されており、持ち物検査を受ける必要があります。

麻薬検知犬も多く見受けられ、日本のカンファレンスでは体験できない海外イベントならではの厳重さを感じました。

シャトルバスで会場間を移動した際も、別会場の入口でセキュリティチェックを受ける必要があります。

EXPO会場

企業ブース出展会場のEXPOも圧巻の広さでした。

多数の企業が出展しており、Datadogの滑り台やKiroのお化け屋敷など、ユニークな展示もありました。

また、アメリカらしいと感じたのは、ドネーション(寄付)コーナーが設置されているブースで、日本にない文化を感じました。

SWAG

EXPO会場や各ブースでSWAG(ノベルティグッズ)が配られており、Tシャツ、ステッカー、ボトルなど様々なグッズを集めることができます。

SWAGもサプライズ的に配布されたりすることがあり、Xで「〇〇でXXが配られた！」などの情報をみて初めて知るものもありました。

SPORTS FORUM

SPORTS FORUMは、スポーツとテクノロジーを組み合わせたエンタメエリアです。

F1のタイヤ交換ゲーム、バスケのゲーム、VRなど、多彩なアクティビティが用意されていました。

散策しているだけでも楽しめます。

セッション以外のサブイベント

ここからは、re:Inventのサブイベントをご紹介します。

5K Fun Run

イベント期間中に開催される5Kmのマラソンイベントです。

参加して完走すればメダルがもらえます。

6:00 AMから開始され朝早いイベントですが、ラスベガスの道路を走れる貴重な機会なので、体力に余裕があればぜひ参加してみてください。

re:Play

re:Invent後半、クロージングKeynoteの後に開催される公式パーティーがre:Playです。

DJによるライブパフォーマンスが行われ、会場の雰囲気はもはやカンファレンスというより野外フェスそのもの。

40フィート走や、巨大なロボットアームで廃車を持ち上げて落とすという、ユニークなアクティビティも用意されており、締めのエンジョイできる時間でした。

おわりに

技術セッションで最新のAWSサービスを学べたのはもちろんですが、会場の規模感やサブイベントの充実度、そして海外のエンジニアとの交流が、このイベントの大きな魅力だと感じました。

ワークショップで英語を使って会話したり、海外のエンジニアからファインディについてフィードバックをもらったりと、コミュニケーションを取ろうとした経験は貴重なものでした。

もっと技術的なディスカッションができるようになりたいという想いも強くなり、継続して英語を学習していきたいと思っています。

来年以降re:Inventへの参加を検討している方の参考になれば幸いです。

---

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

AWS re:Invent 2025 参加レポート - 参加して感じた、AIOpsの本格的な到来

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

はじめに

こんにちは、ファインディのPlatform開発チームでSREを担当している原（こうじゅん）です。

2025年12月、ラスベガスで開催されたAWS re:Inventに参加してきました。re:InventはAWSが毎年開催する世界最大級のクラウドカンファレンスです。

今年は特にAI Agentを中心とした大きな変化を感じるイベントとなりました。

本記事では、私の体験したセッションを通じて見えてきたインフラ・運用の変化について、AIOps領域に焦点を当てて振り返りを書いていこうと思います。

会場の様子やセッション以外のイベントについてはまた別記事で書いていきます。

re:Invent 2025

re:Inventは、ラスベガスの街全体が会場となる巨大なイベントです。

reinvent.awsevents.com

6つの会場で数多くのセッションが同時並行で開催され、世界中のエンジニアが集まります。

会場間の移動だけでも場所によれば徒歩だと約1時間かかることもあり、シャトルバスやモノレールで移動しながら1週間を過ごすことになります。

セッション以外にもEXPO、re:Playと呼ばれるパーティイベント、5k Raceなど様々なアクティビティが用意されており、まさにAWSの祭典という雰囲気でした。

今年の主要テーマの1つであるFrontier Agents

2025年のre:Inventで印象的だったのは、Frontier Agentsと呼ばれるAIエージェントにまつわる発表です。

Keynoteでは、Kiro Autonomous Agent、AWS DevOps Agent、AWS Security Agent、など、フロンティアエージェントと呼ばれるインフラ・運用領域に直接関わるAIエージェントが次々と発表されました。

これらは単なる「補助ツール」ではなく、「チームメイトとして成果を出すことを期待される存在」として位置づけられています。

その中の1つである私が体験してきたAWS DevOps Agentについて軽く触れていきたいと思います。

AWS DevOps Agentとは

AWS DevOps Agentは、運用チームの「チームメイト」として次のような役割を担います。

• Team Player: アラートやチケットに対応し、Slackなどのコラボレーションチャネルで知見を共有
• Telemetry Expert: メトリクス・ログ・トレースを横断的に分析。DatadogやNew Relicとも連携可能
• Pipeline Pro: GitHubやGitLabと連携して障害につながる変更を特定し、パイプライン改善を提案
• Application Context: アプリ構成やRunbookを理解した上で判断

aws.amazon.com

ワークショップでの体験

実際にDevOps Agentを使ったワークショップである [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent に参加し、次のような操作を体験しました。

• 障害発生中のAWSリソースを解析して根本原因を特定
• Dynatraceと連携させてオブザーバビリティデータを統合
• インシデント対応レポートと改善計画の自動生成

エージェントが「インシデントの根本原因を教えてくれる」だけでなく、「改善計画」まで説明してくれる点は、まさにチームメイトのような動きでした。

まだプレビュー版ではありますが、弊社でオブザーバビリティツールとして使用しているDatadogとの連携もできるのでぜひ取り入れていきたいと思いました。

その他の運用・インフラ領域で参考になるセッション

DevOps Agent以外にも、AIOpsに関連する運用・インフラ領域で参考になるセッションがいくつかありました。

Observability × AI

Scaling observability with generative AI (ARC311) では、Kiro CLI Agentを用いた自然言語操作によるオブザーバビリティの自動化が紹介されました。

障害が発生している環境に対して、Kiroがカスタムエージェントで解析した内容をもとにLambdaのコードを書き換えたり、リソース設定を変更したりするデモが印象的でした。

Unveiling Amazon ECS workloads with AWS observability and agentic AI (CNS413) では、ECSワークロードに対して生成AIを活用し、オブザーバビリティデータを自動分析するアプローチが紹介されました。

毎週30億タスクが実行され、新規コンテナ顧客の65%がECSを利用しているという事実を紹介してから、AWSのオブザーバビリティツール全体を整理した上で、ECS上でAIOpsエージェントを構築する際のベストプラクティスが紹介されました。

運用の文化とプラクティス

Behind the scenes: How AWS drives operational excellence & reliability (COP415) では、AWSがグローバル規模で運用をどのように行っているのかが解説されました。

特に印象的だったのは、次のサイクルを継続的に回している点です。

1. Readiness: 障害が起きる前の状態づくり（アラーム、ダッシュボード、Runbook、オンコール体制の整備）
2. Observability: ログ・メトリクス・トレースでの計測、SLOドリブンなモニタリング
3. Incident Response: SOP（標準作業手順書）に従った対応、AIOpsによる障害分析
4. Reviews: 定期的なダッシュボードレビューと改善活動

これらはSREのプラクティスと大きくは変わらないなと思いつつ、改めて運用フローを整理・定義していく重要性を認識しました。

インフラ基盤の進化

Infrastructure Innovations (KEY004) では、Graviton5やLambda Managed Instances、Amazon ConnectのAI対応など、AWSのインフラ技術の進化が語られました。

セキュリティ、可用性、弾力性、コスト、俊敏性といった軸で、どのような思想で設計・進化してきたのかが示されており、基盤レイヤの理解を深めることができました。

IAMポリシーの深掘り

A deep dive on IAM policy evaluation (SEC402-R1) では、IAMポリシーの評価ロジックが詳細に解説されました。

権限評価は単一のポリシーだけで決まるのではなく、Organization → Account → Role → Boundary → Session という複数レイヤをすべて通過して決まります。

また、すべてのPrincipalを対象にしたDenyに条件を付けることで、特定のロールだけを例外として許可するIAMポリシーの書き方なども紹介されており、セキュリティ設計の参考になりました。

AIがインフラ領域に組み込まれている中、ガードレールとしてのポリシーの整備も必要だと感じました。

エンジニアに求められる姿勢

また、クロージングKeynoteで、AWS CTOのWerner Vogels氏が語った言葉が印象に残っています。

「AIは自分の仕事を奪うのか？」という問いに対して、CTOは「多分ね……」と答えつつも、本質的な問いはそこではなく、「AIがあなたを時代遅れにするのか？」であると強調していました。

そして、その答えは、「あなたが進化し続ける限り、断じてノーだ」と。

私たちは今、AIによって時代が大きく動いている震源地に立っています。その中で重要なのは、次の姿勢です。

• Be Curious: 好奇心を持ち続けること
• Think in Systems: 複雑なシステム全体を捉える力
• Communicate: 良いアイデアを明確に伝える力
• Owner: 成果物に対して自ら責任を持つこと
• Polymath: 多才であり、学び続けること

AIはあくまでツールであり、仕事の主体は常に「あなた自身」である。

The work is yours, not the tool's

YOUR CURIOSITY + YOUR SKILLS = WORLD-CHANGING

このメッセージは、re:Inventの締めとしてとても印象に残りました。

おわりに

4日間のイベントを通して、技術的な知見が広がり、刺激的で濃い時間を過ごすことができました。

2026年は、AIOpsが本格的に実務に組み込まれていく年になると感じ、ファインディのPlatform開発チームでもよりAIOpsを組み込んでいく体制づくりを行っていければと思います。

---

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

Findy AI+の開発・運用を支えるMCP活用事例 ― AI Engineering Summit Tokyo 2025登壇レポート

こんにちは。

ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。

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

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

そんな中で先日、弊社主催でAI Engineering Summit Tokyo 2025が開催され、「Findy AI+の開発、運用におけるMCP活用事例」と題しまして登壇してきました。

ai-engineering-summit-tokyo.findy-tools.io

そこで今回は、登壇資料を元に、Findy AI+の開発でどのようにMCPを活用したか、その選択の背景と効果を振り返っていきます。特に、MVPでのリモートMCPサーバー活用と、Admin機能でのMCPサーバー実装という2つの事例から、MCPの実践的な活用パターンをお伝えします。

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

MCPとは

MCP（Model Context Protocol）は、アプリケーションが大規模言語モデル（LLM）に情報やツールへのアクセス方法を提供する、新しいオープンプロトコルです。

USB-Cが様々なデバイスを標準的な方法で接続するように、MCPはAIモデルを多様なデータソースやツールへつなぐための、標準化された方法を提供します。

詳しくは次の公式ドキュメントをご覧ください。

modelcontextprotocol.io

また先日、MCPがLinux Foundation傘下に新設されたAgentic AI Foundation (AAIF)に寄贈されるというニュースが発表されました。

www.anthropic.com

これにより、ベンダーに依存しない中立的な技術として管理されることになります、また、長期的な安定性と互換性が保証され、より安全に採用できる技術となるでしょう。まさに業界にとって不可欠な共有インフラとしての地位を確立しようとしていると言えるでしょう。

Findy AI+

Findy AI+はGitHub連携・プロンプト指示で生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。

生成AIやAIエージェントを活用するうえでの組織、個人の課題を解決するために開発されました。

jp.ai-plus.findy.io

アルファ版: リモートMCPサーバーでの提供

まずこのプロダクトのニーズが一定以上あるかどうか検証するためにMVPでアルファ版の開発を行いました。

この時、アルファ版ではリモートMCPサーバーでのサービス提供を実現しています。

リモートMCPサーバーで提供することで、画面を実装する工数をカットすることが出来た上、分析や解析をクライアント側のLLMに任せることが出来たため、エンジニア2人で1ヶ月程度での開発を実現することに成功しました。

リモートMCPサーバーの役割は、必要な情報を外部APIから取得して、LLMが分析しやすい形に加工して返すことです。

分析そのものはクライアントから接続しているLLMに任せます。 そのため、実行するプロンプトによって出力結果にバラつきが出ることを防ぐために、MCPサーバーからプロンプトを動的に生成して返す機能までを実装しました。

リモートMCPサーバーの詳細は別記事を参照すると、より理解が深まるかと思います。

tech.findy.co.jp

ベータ版: チャットUIとMCP活用のAdmin機能

アルファ版の提供により一定以上のニーズを確認出来たため、次にベータ版として画面UIからのチャット形式のインターフェースを提供することになりました。

更にサービス全体を管理するためのAdmin機能が必要となりました。そこでAdmin機能を画面UIではなく、ローカルMCPサーバーとして実装することにしました。Admin機能は管理者のみが使用し、利用頻度も高くないため、画面UIを作るよりもMCPで柔軟に操作できる方が効率的と判断しました。

MCPサーバーのtoolからバックエンドのサーバーのAdmin機能用のREST APIを実行してデータを取得して返すだけのシンプルな構成です。また、Admin機能用のAPIとユーザー側の機能用のAPIのendpointと認証を分けることで、セキュリティ面も考慮しています。

結果的に、画面ベースで開発した場合の見積もりが約1ヶ月程度の工数であったのに対し、MCPサーバーとして実装したことで約1週間程度の工数で実装が完了しました。

Admin機能を提供するMCPサーバーについては別記事を参照すると、より理解が深まるかと思います。

tech.findy.co.jp

まとめ

MCPの登場により、開発効率を上げるだけではなくデータへのアクセス手段の選択肢が広がりました。 今回のFindy AI+の事例では、MVP開発でリモートMCPサーバーを活用することで開発期間を大幅に短縮し、Admin機能ではMCPサーバーとして実装することで画面UIの開発工数を削減できました。それにより、価値提供の方法も変わってきています。

また、LLMや生成AIツールが変わっても、MCPはLLMや生成AIツールを選ばずに接続が出来ます。これにより長く使える知識、技術となっています。

ファインディは早期にMCPの検証を開始して、積み重ねを継続して、実用化にたどり着くことができました。

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

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

ECS Express Modeはインフラ構築をどこまで楽にしてくれるのか

はじめに

みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（@adachin0817）です。この記事は、ファインディエンジニア Advent Calendar 2025の18日目の記事です。今回はECS Express Modeをスピーディーに試してみたので、使ってみて分かったメリット・デメリットを中心にまとめていきたいと思います。

adventar.org

ECS Express Modeとは

• https://aws.amazon.com/jp/blogs/news/build-production-ready-applications-without-infrastructure-complexity-using-amazon-ecs-express-mode/

従来のECSを用いたインフラ構築では、ECSクラスターやタスク定義、サービスだけでなく、ロードバランサー、ターゲットグループ、セキュリティグループ、オートスケーリングなど、多数のリソースを個別に定義・管理する手間がありました。

公式ドキュメントによるとECS Express ModeはAPIを通じて、インフラのセットアップを全て、自動化できるようになりました。これにより、アプリケーション開発に集中できる環境を実現し、Amazon ECSを含む各リソースを設定できるため、必須項目はコンテナイメージのみで、シンプルさとスピードを飛躍的に向上させています。

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_express_gateway_service

Terraformではaws_ecs_express_gateway_serviceリソースが提供されているため、こちらを使って一連の流れを実装していきます。

Terraform

terraform.tf

ECS Express Modeは、Terraform AWS Providerのバージョン6.23から利用できるようになります。

terraform {
  required_version = ">= 1.14.2"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 6.26.0"
    }

  }

  cloud {
    organization = "hoge"

    workspaces {
      name = "hoge-ecs"
    }
  }
}

iam.tf

ECS Express Modeでは、主に2つのIAM ロールが必要になります。Task Execution Roleは、コンテナイメージのpullやCloudWatch Logsへの書き込みに使用され、Infrastructure Roleは、ECS Express Modeが各種リソースを作成・管理するために使用されます。

resource "aws_iam_role" "ecs_task_execution_role" {
  name = "test-service-task-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "ecs-tasks.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_task_execution_role_policy" {
  role       = aws_iam_role.ecs_task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

resource "aws_iam_role" "ecs_infrastructure_role" {
  name = "test-service-infrastructure-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "AllowAccessInfrastructureForECSExpressServices"
      Effect    = "Allow"
      Principal = { Service = "ecs.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_infrastructure_role_policy" {
  role       = aws_iam_role.ecs_infrastructure_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRoleforExpressGatewayServices"
}

ecs.tf

ECS Express Modeでは、中心となるリソースであるaws_ecs_express_gateway_serviceを通じて各種設定を制御します。ECSクラスター自体は別途定義する必要がありますが、サービス側ではコンテナイメージ指定（今回はNginx）、ログ設定、事前に作成したIAM ロール、ネットワーク、CPU・メモリ、スケーリング設定などをまとめて指定します。

ロードバランサーについては ALBとターゲットグループが自動的に作成・管理され、ACM証明書も自動発行される仕様となっていました。また、セキュリティグループもExpress Mode側で自動生成・管理されるため、Terraform側では差分検知を防ぐために、ignore_changesを指定する必要がありました。

※ネットワークはデフォルトVPCを参照しています。

resource "aws_ecs_cluster" "main" {
  name = var.cluster_name
}

resource "aws_ecs_express_gateway_service" "main" {
  cluster      = var.cluster_name
  service_name = var.service_name

  primary_container {
    image          = var.container_image
    container_port = var.container_port
    command        = var.command

    aws_logs_configuration {
      log_group         = aws_cloudwatch_log_group.ecs_service.name
      log_stream_prefix = var.service_name
    }
  }

  execution_role_arn      = aws_iam_role.ecs_task_execution_role.arn
  infrastructure_role_arn = aws_iam_role.ecs_infrastructure_role.arn

  network_configuration {
    subnets         = toset(["subnet-xxxxxx", "subnet-xxxxxx"])
    security_groups = toset([aws_security_group.tests_service.id])
  }

  cpu    = tostring(var.cpu)
  memory = tostring(var.memory)

  scaling_target {
    min_task_count            = var.min_capacity
    max_task_count            = var.max_capacity
    auto_scaling_metric       = "AVERAGE_CPU"
    auto_scaling_target_value = 60
  }

  health_check_path = var.health_check_path

  lifecycle {
    ignore_changes = [
      network_configuration[0].security_groups
    ]
  }
}

variables.tf

variable "cluster_name" {
  type        = string
  description = "The name of the ECS cluster"
  default     = "hoge-cluster"
}

variable "service_name" {
  type        = string
  description = "The name of the service"
  default     = "hoge-service"
}

variable "log_group" {
  type        = string
  description = "The name of the CloudWatch log group"
  default     = "/ecs/hoge-service"
}

variable "container_image" {
  type        = string
  description = "The container image to use for the service"
  default     = "nginx:latest"
}

variable "container_port" {
  type        = number
  description = "The port that the container listens on"
  default     = 80
}

variable "command" {
  type        = list(string)
  description = "The command to run in the container"
  default     = ["nginx", "-g", "daemon off;"]
}

variable "cpu" {
  type        = number
  description = "The number of CPU units to allocate"
  default     = 256
}

variable "memory" {
  type        = number
  description = "The amount of memory (in MiB) to allocate"
  default     = 512
}

variable "min_capacity" {
  type        = number
  description = "Minimum number of tasks"
  default     = 1
}

variable "max_capacity" {
  type        = number
  description = "Maximum number of tasks"
  default     = 10
}

variable "health_check_path" {
  type        = string
  description = "The path for health checks"
  default     = "/"
}

Deploy

デプロイはECSビルトインデプロイであるカナリアデプロイとなっており、アプリケーションURLにHTTPSでアクセスできるようになりました。

❯❯ curl -I https://xxx.ecs.ap-northeast-1.on.aws
HTTP/2 200 
server: nginx
date: Tue, 16 Dec 2025 02:30:25 GMT
content-type: text/html; charset=utf-8
content-length: 14
x-powered-by: Express

削除の挙動と懸念点について

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-delete-task.html

• The Amazon ECS cluster (if no other services are running)
• The Amazon ECS service, task definition, and any running tasks
• Service security group
• CloudWatch log group
• Metric alarm
• ACM Certificate
• The Application Load Balancer (if no other services are configured), target group, security group, listener, and listener rule
• Amazon EC2 Auto Scaling policy, scalable target

削除の挙動については、Terraformでdestroyを実行すればExpress Mode管理下のリソースがすべて削除される想定でした。しかし、実際にはALBやターゲットグループ、ACMが残存し、その後に手動削除と再apply を行った結果、同一サービス名のECSサービスがDraining 状態のままとなり、再作成できない問題に直面しました。

╷
│ Error: creating ECS (Elastic Container) Express Gateway Service
│ 
│   with aws_ecs_express_gateway_service.main,
│   on ecs.tf line 5, in resource "aws_ecs_express_gateway_service" "main":
│    5: resource "aws_ecs_express_gateway_service" "main" {
│ 
│ ID: "hoge-service"
│ Cause: operation error ECS: CreateExpressGatewayService, ,
│ InvalidParameterException: Unable to Start a service that is still Draining."

クラスター名を変更して再度applyし直したところ、applyは完了するものの、ロードバランサーが作成されない状態となりました。その結果、存在しないセキュリティグループを参照したままサービスが起動できず、結果としてサービスがデプロイされないままタイムアウトしない事象が発生しました。この挙動から、Terraformでの削除・再作成は、現時点で課題が残っていると感じています。

まとめ

ECS Express Modeは、App Runnerと比べても、インフラ構築の複雑さを大きく減らし、アプリケーションエンジニアでも素早く環境を立ち上げ、開発に集中できる体験を提供してくれる仕組みだと感じました。一方で、Terraformを前提とした運用ではまだ課題が残る印象もありますが、Platform SRE チームがこれまで整備してきた汎用モジュールの一部を、将来的に置き換えられる可能性も感じています。

今後はAWSサポートとも連携しながら挙動の整理を進め、どのユースケースで安全に使えるのかを見極めつつ、実運用に耐えうる形へ落とし込んでいく予定です。

最後まで、読んでいただきありがとうございました！

herp.careers

アウトプットで学ぶ。チームでAIをキャッチアップする10分勉強会

こんにちは。 Findy Freelanceの開発チームでEMをしている中坪です。 この記事は、ファインディエンジニア Advent Calendar 2025の18日目の記事になります。

adventar.org

日々進化するAIや関連ツールをキャッチアップし、実務に活用することに苦労しているエンジニアの方も多いのではないでしょうか。

私たちは、チームでAIツールのキャッチアップを行う取り組みとして「10分勉強会」を実施しています。 本記事では、その取り組み内容について紹介します。

10分勉強会とは

発表者が5分間で学んだことを発表し、残り5分で質疑応答を行う形式の勉強会です。

この勉強会の目的は次の3つです。

• メンバーが学んだことをチームメンバーに共有する機会を作る
• 発表からその人の仕事、興味、課題などを知り、相互理解を深める
• アウトプットのハードルを下げ、アウトプットの習慣をつける

Findy Freelance開発チームでは、週に2回、10分勉強会を実施しています。 1回につき1名が発表し、ローテーションで全員が発表する形をとっています。

2024年の2月頃に開始し、継続しています。

2025年1月以降は、基本テーマを「生成AI活用」に設定し、変化の激しいAIツールのキャッチアップに焦点を当てています。

過去の発表内容の一部です。

発表内容の例

過去の発表内容の例をいくつか簡単に紹介します。

1. Sentry MCPとLog Analyzer with MCPを使った不具合調査

AWSが提供するLog Analyzer with MCPを使った不具合調査の方法を紹介しました。 このMCPはCloudWatch Logsの検索と分析を行うことができ、Sentry MCPと組み合わせることで、エラーの概要と詳細なログを横断的に調査できます。

Sentryでエラーの概要を把握し、CloudWatch Logsで詳細なログを確認することで、Claude Code上で一貫した調査が可能になり、エラーの根本原因を効率的に特定できた事例が紹介されました。

2. Gemini Canvasを使ったUIモックの作成と社内共有

仕様検討時にUIイメージを共有する方法として、Gemini Canvasの活用事例が紹介されました。 Geminiのチャット欄でCanvas機能を有効化し、既存画面のキャプチャと簡単なプロンプトを渡すだけで、動きのあるUIモックを作成できます。

生成されたHTMLをGoogle Apps Scriptにデプロイし、公開範囲を組織内に限定することで、社内のGoogleアカウントを持つメンバーだけがアクセスできるURLとして共有できます。

静的なキャプチャでは伝わりにくいインタラクションも、実際に動かせるモックを使うことで、仕様の認識合わせを効率的に進められた事例が紹介されました。 V0のような専用ツールと比べて、ファインディの社内で導入されている標準ツールで利用できる点が利点です。

3. Git Worktree Runnerの紹介

CodeRabbitが公開しているGit Worktree Runner (GTR)を使った開発効率化の事例が紹介されました。 このツールは、Git worktreeの作成と管理を簡単にし、AIツールとの連携をスムーズにします。

コマンド一つでworktreeとブランチを同時に作成でき、エディター(VS CodeやCursorなど)やAI CLIツール(Claude Codeなど)の起動も自動化できます。 フック機能により、worktree作成時にnpm ciなどの初期化コマンドを自動実行できるため、ブランチを切り替えてすぐに開発を始められる環境が整います。

git worktreeの導入ハードルを下げ、複数のタスクを並行して進めやすくするツールとして活用事例が共有されました。

持続するための工夫

10分勉強会がメインとなる開発業務の妨げにならず、継続的に実施するために、次のような工夫をしています。

発表のスキップを許容する

業務が忙しい時期や準備が間に合わない場合は、当日開催前までに周知すればスキップできるようにしています。

基本的には開発業務を優先し、発表者が自身の負荷状況を考慮して調整できる運用にすることで、無理なく続けられる仕組みにしています。

発表資料は任意

発表資料の作成は必須ではありません。 Notionに簡単にまとめるだけでも良いですし、実際の操作を画面共有しながら説明する形でも、誰かの書いたブログ記事を紹介する形でもOKにしています。 資料作成のハードルを下げることで、発表しやすい環境を作っています。

厳密ではないテーマ設定

基本テーマは設けつつ、テーマ以外の内容でも発表可能にしています。

業務での取り組み、ドメイン知識の共有、最近読んだ技術書の紹介など、特にチームに共有したいことなどがあれば、テーマ外でも発表可能です。

チーム内で開催する

ファインディのエンジニア組織全体ではなく、Findy Freelance 開発チーム内で開催しています。

チーム内であれば、Findy Freelance固有のプロダクトや事業やドメイン知識に関する内容も共有しやすく、実務に直結した内容を扱いやすいです。

全体開催に比べると、対象者が限定されており、一定の前提知識も揃っているため、発表者もテーマ設定や内容を考えやすいと考えています。

開催時間を短くする

オープン、クローズを含めて15分程度で会が終わるようにしています。

チームメンバー全員参加であっても、15分程度であれば業務の時間を大きく割くことなく参加しやすいと考えています。

効果と反響

チームメンバーの声

チームメンバーにアンケートを実施したところ、次のような声がありました。

AIキャッチアップの助けになっていたり、発表内容が実務に役に立っていることがわかりました。

良かった点: 色々MCPを知ることができたこと。Claude Codeの使い方を知ることができたこと。

---

AIのキャッチアップは大変なので知らなかった変更や知見を知れた

---

CloudWatch Logsの検索mcpはかなりの頻度で利用しています

---

自身が仕様検討する機会が多く、認識合わせのためのUIモックが必要だと感じている中でGemini Canvasを用いた画面モックの発表があり、すぐに仕様のすり合わせで活用することができた。

また、5段階評価で「生成AIのキャッチアップに役立ちましたか？」という質問に対しては、平均4.4点という高評価を得られました。

チームAI活用率

勉強会だけの効果とは言い切れませんが、Findy Freelance開発チームではAIツールの活用率は高い値を維持しています。

Findy Team+のAI活用レポートをみると、2025/09/16 - 2025/12/15の期間のAI利用者率は100%、AI利用プルリクの割合も70%を超えています。

単月でみると、最も高い月で10月のAI利用プルリク割合は約90%に達しています。

アンケートの反応なども合わせて考えると、10分勉強会がAI活用の促進に一定寄与していると捉えています。

メリット

アウトプットによる知識の定着

人に説明することで、自分の理解が深まり、知識が定着しやすくなります。 自分ではわかっているつもりが、発表しようとすると、理解が不十分な部分に気づくことがあります。

そこを調べたり、説明の仕方を考えたりすることで、より深い理解につながります。 この勉強会において、一番恩恵を受けるのは発表者自身だと感じています。

AIのキャッチアップをチームで取り組める

AIや関連ツールは日々進化しており、個人でキャッチアップするのは大変です。 一方で、新しいものがでてきたときに、少し触ってみる、試してみるということも重要だと考えています。 触ってみないと実際にそのツールがどのように役立つかを理解するのは難しいからです。

勉強会を通じて、他のメンバーが試したツールや活用事例を知ることで、個人のキャッチアップの負荷を軽減することができると感じています。 週2回という頻度も、変化の激しいAIツールのキャッチアップには適していると考えています。

聞いた内容をすぐに試せる

前述の通り、チーム内で実施しているため、発表内容が実務に直結しやすいです。 また、導入されているツールや対象とするシステムや環境が共通していることも多いため、発表を聞いた後にすぐに試してみることができます。

例えば、普段開発しているリポジトリにClaude Codeのカスタムコマンドを導入したという発表があった場合、他のメンバーにとっても普段さわっているリポジトリになるため、すぐに試してみることができます。 環境構築の手間も少なく、マージ済みであれば、勉強会を聞きながらその場で試すことすら容易です。

デメリット

体系的に学びたい場合や、基礎を固めたい場合には向いていないと考えています。 テーマは発表者が自由に選べるため、どんな内容が発表されるかは事前にはわかりません。 特定のトピックスに偏る可能性もありえます。また、深い内容を扱うには5分では時間がたりません。

Findy Freelance開発チームでは、現状ではミドル以上のエンジニアが中心の構成になっているため、自主性に一定の期待ができることもあり、この形式が機能していると考えています。

余談と「うちのAIがやらかしまして」の紹介

余談になりますが、10分勉強会では、試してみたけどうまくいかなかった事例も共有されることがあります。

また、AIの進化が早すぎて、発表した内容が古くなってしまったり、バージョンアップにより使えなくなったりすることもありました。

この記事を読んでくれている方の中にも、AIがうまく動いてくれなかった経験がある方がいると思います。

現在、Findyでは「うちのAIがやらかしまして」というAIを使ったときのちょっと笑えるやらかし体験をシェアする期間限定企画を実施中です。

ちなみにですが、私はこの投稿が好きです。

実際に体験がある方はぜひシェアいただけると嬉しいです!

他の方の投稿をみるだけでも面白いと思いますので、ぜひのぞいてみてください!

おわりに

Findy Freelance開発チームでは、10分勉強会を通じて、変化の激しいAIツールのキャッチアップをチームで取り組んでいます。 2025年は生成AI活用に焦点を当てて取り組んでおり、チームメンバーからも好評を得ています。

これは今のチーム構成や文化に合っているからこそ機能している面もあると考えています。 継続することが目的ではなく、チームの構成や人数や課題に応じて、勉強会の形式や実施するかどうか振り返ることも重要です。

ただ、どのような形式であれ、変化の激しいAIの進化をチームで協力しつつ、楽しみながらキャッチアップすることは継続していきたいと考えています。

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

herp.careers

【Claude】Pluginsで簡単横展開 - 開発手法の標準化 -

こんにちは。

ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。

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

adventar.org

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

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

そんな中で先日、Claude Codeの新機能であるPluginsが公開されました。

そこで今回は、Pluginsの紹介と解説、作り方と利用方法を紹介したいと思います。

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

Pluginsとは

PluginsはCustom slash commands, Subagents, Hooks, Agent Skills、MCPサーバーを使用してClaude Codeを拡張できる便利な機能となっています。

また、marketplacesからPluginsをインストールして、事前に構築されたCustom slash commands, Subagents, Hooks, Agent Skills、MCPサーバーを利用できるようにもなります。

code.claude.com

一言で言うと、Claude Codeの各種設定や機能をPluginsとして事前に用意しておき、それらを簡単に横展開できるようにした仕組みです。

開発組織やチーム間で、開発手法やワークフローを標準化するのに非常に役立ちます。

作り方

必要なファイルと、展開したい各種Claude Codeの設定ファイルなどを用意するだけでPluginsを作成できます。

まずPluginsを管理するための新しいリポジトリをGitHub上に作成します。作成したリポジトリをLocal環境にcloneしましょう。今回は TestOrg/DevPlugins というリポジトリを作成したとします。

次にリポジトリのrootに .claude-plugin というディレクトリを作成し、その中に marketplace.json というファイルを新規で作成します。

{
  "name": "DevPlugins",
  "owner": {
    "name": "TestOrg Inc."
  },
  "plugins": [
    {
      "name": "development-plugin",
      "source": "./development-plugin",
      "description": "Development plugin for TestOrg Inc."
    }
  ]
}

次にリポジトリのrootに development-plugin/.claude-plugin というディレクトリを作成し、その中に plugin.json というファイルを新規で作成します。

{
  "name": "development-plugins",
  "description": "Development plugins for TestOrg",
  "version": "0.0.1",
  "author": {
    "name": "TestOrg Inc."
  }
}

これで DevPlugins というmarketplaceに development-plugin というPluginsが作成されました。

ここまで用意できれば、あとは展開したい各種Claude Codeの設定ファイルを development-plugin ディレクトリ以下に配置していくだけです。今回はCustom slash commandsを追加します。

---
description: Greet the user with a personalized message
---

# Hello Command

Greet the user warmly and ask how you can help them today. Make the greeting personal and encouraging.

全体の最小構成は次のようになります。

DevPlugins/
├── .claude-plugin/
│   └── marketplace.json
└── development-plugin/
  ├── .claude-plugin/
  │   └── plugin.json
  └── commands/
    └── hello.md

作成したファイルをGitHubのデフォルトブランチに push すれば Plugins の作成と展開は完了です。marketplace と Plugins の設定ファイルを作成し、展開したい各種Claude Codeの設定ファイルを配置するだけでシンプルに構築できることが分かると思います。

利用方法

作成したPluginsを利用する方法を説明します。

まずPluginsの登録先を追加します。Claudeのコンソールに入って、次のコマンドを実行します。

> /plugin marketplace add TestOrg/DevPlugins 

このコマンドにより、GitHub上のリポジトリをmarketplaceとして登録します。

次に、作成したPluginsを実際にインストールします。続いて次のコマンドを実行します。

> /plugin install development-plugin@DevPlugins

実行すると次のような出力が表示されるので Install now を選択します。

╭────────────────────────────────────────────────────────────╮
│ Plugin Details                                             │
│                                                            │
│ development-plugin                                         │
│                                                            │
│ Development plugin for TestOrg Inc.                        │
│                                                            │
│ Will install:                                              │
│ • Components will be discovered at installation            │
│                                                            │
│ > Install now                                              │
│   Back to plugin list                                      │
╰────────────────────────────────────────────────────────────╯

インストールが成功すると ✓ Installed development-plugin. Restart Claude Code to load new plugins. と表示されるので、Claude Codeを再起動します。

再起動すると、インストールしたPluginsが利用可能になります。実際に利用するには、次のようにコマンドを実行します。

> /development-plugin:hello

実行すると次のような出力が表示されました。Pluginsを正しくインストール出来たことが確認できます。

⏺ Hello! 👋 Welcome to DevPlugins

  I'm Claude Code, and I'm here to help you with anything related to this
  project. Whether you need to:

  - 🚀 Set up the development environment
  - 🔧 Build new features or fix bugs
  - 🧪 Write or run tests
  - 📊 Work with the database or migrations
  - 🤖 Integrate with Claude AI or GitHub APIs
  - 📝 Review code or create pull requests

  I'm ready to assist! I have full context of the project structure, authentication
  patterns, service architecture, and best practices for this codebase.

  What would you like to work on today?

まとめ

Pluginsを利用することで、開発組織やチーム間で開発手法やワークフローを簡単に標準化できるようになります。

弊社ではClaude Codeの共通の設定を自動で設定するCustom slash commandsや、Pull requestを作成するAgent Skillsなどを作成して開発組織全体に展開し、開発効率の向上に役立てています。実際に作成した Plugins の具体例紹介は、別の機会で改めてまとめたいと思います。

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

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