こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 DevEx（開発者体験）の認知度はわずか4.9%。この数字もまた、日本の開発現場が直面する課題の一つであり、同時に大きな伸びしろを示しています。 前回の記事 では、Visual SourceSafe 15.8%という数字から見える技術格差と、AI時代に広がる生産性格差について取り上げました。今回は、その技術格差の背景にあるDevExに焦点を当て、日本の開発者が本当に求めているものを考察します。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 DevExとは何か 日々の仕事の「体感」に着目する DevExが提唱された背景 DevEx認知度4.9%が示す日本の現状 開発生産性指標の認知度と活用度 なぜDevExは日本で知られていないのか CI/CDとドキュメンテーションに見る課題 阻害要因をDevExの視点で読み解く まとめ お知らせ DevExとは何か 日々の仕事の「体感」に着目する DevEx（Developer Experience）とは、開発者がソフトウェア開発で得る体験の質を指します。開発者満足度調査とは異なり、開発生産性に直結する「体感」に着目する点が特徴です。 たとえば、次のような場面を思い浮かべてください。 ビルドやテストの結果を待っている時間 必要な情報がどこにあるか分からず探し回る手間 会議の合間で集中が途切れる感覚 コードレビューの返答がなかなか来ない状況 複雑なコードを読み解くのに消耗する時間 これらは開発者なら誰しも覚えがある場面ですが、DevExはこの「体感」を改善可能な課題として扱います。 2023年に発表された論文「 DevEx: What Actually Drives Productivity 」（著者：Abi Noda、Margaret-Anne Storey、Nicole Forsgren（DORA創設者）、Michaela Greiler）では、DevExを構成する3つの中核的な次元が提唱されています。 https://dl.acm.org/cms/attachment/html/10.1145/3595878/assets/html/noda1.png DevExの3つの次元 次元 説明 例 Feedback Loops（フィードバックループ） 開発者が行動に対する応答を受け取る速度と質 ビルド時間、テスト実行時間、コードレビューの待ち時間 Cognitive Load（認知負荷） タスク遂行に必要な精神的処理量 ドキュメントの質、コードの複雑さ、ツールの習得難易度 Flow State（フロー状態） 完全に集中して作業に没頭できる状態 中断の頻度、会議の多さ、自律性の度合い 冒頭で挙げた場面は、この3次元に対応しています。 ビルドやテストの結果を待っている時間 → フィードバックループ 必要な情報がどこにあるか分からず探し回る手間 → 認知負荷 会議の合間で集中が途切れる感覚 → フロー状態 コードレビューの返答がなかなか来ない状況 → フィードバックループ 複雑なコードを読み解くのに消耗する時間 → 認知負荷 3次元フレームワークについては、過去の記事でも詳しく解説しています。興味のある方はあわせてご覧ください。 DevExが提唱された背景 DevEx論文の著者には、DORAの創設者であるNicole Forsgren氏が名を連ねています。DORA指標は組織レベルのデリバリーパフォーマンスを測定できますが、個々の開発者が日々の業務で何に困っているかは見えません。DevExは、この視点を補う「開発者中心のアプローチ」として提唱されました。 加えて、DevExに取り組むことは、開発者が所属する組織全体の力を引き上げることにもつながります。 【エンジニアの採用・定着】開発環境や働きやすさは、エンジニアが職場を選ぶ際の判断材料の一つです。DevExの改善は、人材の採用や定着にも影響します。 【生産性との関連性】前述のDevEx論文では、開発者が良い体験をしている組織ほど、実際の開発生産性も高いと報告されています。DevExは「開発者を甘やかす」のではなく、組織のパフォーマンスを最大化するための投資です。 DevEx認知度4.9%が示す日本の現状 開発生産性指標の認知度と活用度 エンジニアの採用競争力にも、組織の生産性向上にも直結するDevEx。しかし日本での認知度はわずか4.9%です。開発者が日々抱える課題を解決するフレームワークが、ほとんど知られていません。 調査では25種類の開発生産性指標について認知度と活用度を調べています。何が知られていて、何が知られていないのか。その差が、日本の開発現場の現状を映し出しています。 開発生産性指標の認知度・活用度（全25指標） 指標 認知度 活用率 バグの数 58.1% 31.8% 残業時間 53.3% 21.9% コードの行数 52.9% 22.9% タスクの完了数（スプリントの達成率に含まれることもある） 48.1% 30.1% テストカバレッジ 34.1% 18.2% バグ修正のスピード（修正にかかる時間） 27.7% 9.9% 顧客からのフィードバック 26.1% 10.9% コミット数 24.7% 6.9% タスクの割り当て数（アサインされた数と完了した数の比率） 23.7% 9.9% コードレビュー効率（レビューに要する時間や改善の質など） 20.3% 10.2% ベロシティ（ストーリーポイントの消化速度） 17.7% 7.1% 平均復旧時間（MTTR – Mean Time to Recovery）（単独計測） 15.7% 3.6% デプロイ頻度（単独計測） 13.9% 3.4% チームの幸福度（eNPSなど） 11.3% 4.5% 変更リードタイム（単独計測） 10.0% 3.1% 技術的負債の定量評価（コードの複雑性などを数値化） 7.8% 2.8% コードのリワーク率（修正が必要になったコードの割合） 6.5% 2.9% プルリクエストサイクルタイム（PRの作成からマージまでの時間） 6.0% 1.6% デベロッパーエクスペリエンス（DevEx） 4.9% 2.1% 変更失敗率（単独計測） 4.6% 1.8% Flow Metrics（開発プロセス全体の流れを可視化する指標） 4.4% 1.9% Four Keys / DORAメトリクス（変更リードタイム、デプロイ頻度、デプロイ失敗時の復旧までの時間、変更失敗率） 4.3% 2.4% PSP（Personal Software Process） 3.9% 1.8% SPACEフレームワーク（開発者の満足度、パフォーマンス、コラボレーションなど） 3.8% 1.8% DX Core 4™（DORA、SPACE、DevExを統合したフレームワーク） 3.1% 1.3% 知らない / 聞いたことがない 14.0% 18.2% その他（具体的に） 0.1% 0.1% （N=798） 上位4指標（バグの数、残業時間、コードの行数、タスク完了数）は認知度50%前後で、いずれもアウトプットを直接カウントする指標です。これらは測定しやすい反面、開発者が日々感じている「ビルドが遅い」「情報が見つからない」「集中できない」といった体験とは直接結びつきません。 一方、DevExの認知度は4.9%に留まっています。開発者の体験を改善すれば生産性が上がるという考え方は、まだ日本では広まっていないようです。 興味深いのは、DORA指標を構成する「デプロイ頻度」「変更リードタイム」「平均復旧時間（MTTR）」「変更失敗率」の認知度です。個別指標としては4.6%〜15.7%の認知度があるにもかかわらず、「Four Keys / DORAメトリクス」というフレームワーク名の認知度は4.3%に留まっています。指標は知っていても、体系化されたフレームワークとしては認識されていないのかもしれません。 なぜDevExは日本で知られていないのか 先ほどの表を見ると、認知度の高い指標には共通点があります。「バグの数」「残業時間」「コードの行数」「タスク完了数」はいずれも数えやすく、報告しやすい指標です。一方、DevExが扱う「ビルドを待つストレス」「情報を探す手間」「集中が途切れる感覚」は、数値化しにくく、経営層への説明も難しい。測れないものは改善対象になりにくいのかもしれません。 もう一つ考えられるのは、開発手法との相性です。調査では、ウォーターフォール開発が36.8%、開発手法が「よくわからない」が18.2%で、合わせて55%を占めました。DevExはアジャイルやDevOpsの反復的な開発と親和性が高く、フィードバックを素早く得て改善を繰り返す文化が前提にあります。半数以上の開発現場では、そもそもDevExが機能する土壌がない可能性があります。 加えて、日本の産業構造も影響しているかもしれません。受託開発では「納品」がゴールになりやすく、開発者の体験は顧客への請求項目に含まれません。自社プロダクト開発と比べ、DevExへの投資が正当化されにくい構造があると考えられます。 CI/CDとドキュメンテーションに見る課題 DevExが知られていないということは、開発者の体験を改善するという発想自体が広まっていないことを意味します。その影響は、開発基盤の満足度に表れています。第4回でも取り上げたデータをDevExの視点で見直してみます。 開発基盤の満足度とDevExの対応 項目 満足度 DevExの次元 CI/CDパイプライン 14.2% フィードバックループ ドキュメンテーション 17.5% 認知負荷 タスク管理システム 18.2% 認知負荷 コードレビュープロセス 19.2% フィードバックループ 開発環境整備 24.7% 認知負荷 （N=798、「満足」「やや満足」の合計） CI/CDパイプラインの満足度14.2%は、ビルドやテストの結果を待たされている開発者が多いことを示唆しています。これはDevExの「フィードバックループ」の課題です。 一方、ドキュメンテーションの満足度17.5%は、新メンバーのオンボーディングに時間がかかったり、「あの人に聞かないと分からない」状態が続いたりする形で現れます。これはDevExの「認知負荷」そのものであり、開発者が本来のコーディングに集中できない状況を生んでいます。 阻害要因をDevExの視点で読み解く 開発基盤だけでなく、開発現場で日常的に挙がる「困りごと」にも、DevExの課題は潜んでいます。第3回で取り上げた「開発生産性を阻害する要因」をDevExの視点で整理すると、次のような対応関係が見えてきます。 阻害要因 回答率 DevExの次元 影響 不明確な要件 53.5% 認知負荷 何を作るべきか分からず、確認や手戻りに時間を取られる 会議が多い 38.7% フロー状態 集中できる時間が確保できない コミュニケーションの問題 33.6% フィードバックループ 必要な情報が適時に得られない 技術的負債 30.5% 認知負荷 複雑なコードの理解に時間がかかる 日本の開発現場が抱える課題の多くはDevExの問題として捉えられます（影響はDevExだけに留まりませんが）。「不明確な要件」と「技術的負債」は認知負荷を高め、「コミュニケーションの問題」はフィードバックループを遅らせ、「会議が多い」はフロー状態を妨げます。 まとめ 今回は、DevExの認知度4.9%という数字から、日本の開発現場の現状を読み解きました。従来型指標（バグの数、残業時間など）が50%以上の認知度を持つ一方で、開発者の体験に着目するDevExは浸透していません。 CI/CDパイプラインの満足度14.2%、ドキュメンテーションの満足度17.5%という数字は、フィードバックループや認知負荷に課題があることを示しています。また、「不明確な要件」「会議が多い」といった阻害要因も、DevExの3次元で整理すると改善の糸口が見えてきます。 認知度の低さは、裏を返せば伸びしろの大きさです。開発者の体験を改善することが、結果として組織のパフォーマンス向上につながります。 次回は「なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策」をお届けします。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの 第6回、なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策 数値化への懸念と向き合う方法 第7回、生産性向上を阻む組織の壁 ── 37.8%が未着手の深刻な理由 経営層を説得する具体的な方法 第8回、既存システムから次世代への変革 ── 日本の開発現場が立つ分岐点 品質文化を強みに変える改革のロードマップ お知らせ 「 Development Productivity Conference 2026 」が2026年7月22日〜23日に開催されます。継続的デリバリー（CD）の先駆者であり『継続的デリバリーのソフトウェア工学』著者のDave Farley氏が初来日。日本からはテスト駆動開発の第一人者・和田卓人氏が登壇します。 prtimes.jp ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは、ファインディのPlatform開発チームでSREを担当している原（ こうじゅん ）です。 2025年は、ファインディにとって新規サービスリリースが相次ぐ年でした。 Platform開発チーム(以降、SREチーム)では、この1年間で6つのサービスのインフラ環境を構築してきました。 スピード感を持った環境構築を実現するために、私たちがどのような工夫を行ったのか、今回はTerraformの汎用モジュールを活用した取り組みについてお話しします。 はじめに 2025年、6つのサービスをリリース スピード感のある環境構築で直面した課題 Terraformでの汎用モジュールの導入 Network、Container、Databaseなど、様々なパッケージを整備 モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組み 汎用モジュールで解決した課題 Terraformのplanは成功するけどApplyはコケる問題 まとめ 2025年、6つのサービスをリリース 2025年、SREチームでは次のサービスのインフラ環境を構築しました。 Findy Conference Findy AI+ Findy Team+ AIチャットボット Findy ID Findy Insights アーキテクチャ壁打ちAI by Findy Tools これらのサービスは、それぞれStaging環境やProduction環境といった複数の環境が必要であり、SREチームとしては短期間で多数の環境構築を実施する必要がありました。 スピード感のある環境構築で直面した課題 新規サービスのリリースラッシュの中で、私たちは次のような課題に直面しました。 サービス開発はスピード感を持って行われており、インフラ環境の構築にも「2週間でStaging環境とProduction環境を用意してほしい」といった依頼も珍しくありません。サービスリリースのタイミングが重なると、複数の環境構築依頼が同時に舞い込むこともあります。 SREチームは環境構築だけに専念できるわけではなく、既存サービスの運用改善、障害対応、セキュリティ対応なども並行して進める必要があります。 2025年当時、SREチームのメンバーは4名でした。この人数で、これだけのサービスリリースに対応するのは容易ではありませんでした。 Terraformでの汎用モジュールの導入 これらの課題を解決するために、ファインディのプロダクトで頻繁に利用するAWSリソース（ECS、ALB、RDS、VPCなど）を、再利用可能なTerraformモジュールとして整備しました。 これらを「汎用モジュール」と呼んでいます。 汎用モジュールの目的は、次の2点です。 スピード: 環境構築にかかる時間を大幅に短縮する 品質: 標準化されたモジュールを使うことで、設定ミスを減らし、品質を担保する 汎用モジュールは、HCP Terraform（旧Terraform Cloud）のプライベートレジストリに登録しています。これにより、チーム内で簡単にモジュールを共有・再利用できるようになりました。 Network、Container、Databaseなど、様々なパッケージを整備 汎用モジュールは、リソースの機能ごとにパッケージを分けて整備しています。 例えば次のようなカテゴリーに分けています。 Network: VPC、サブネット、ルートテーブル、NATゲートウェイなど Container: ECS、Fargate、ALB、タスク定義など Database: RDS、Aurora、パラメータグループなど その他、必要に応じてモジュールを追加 モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組み 汎用モジュールを使えば、必要なパラメーター（プロジェクト名、環境名、リソースサイズなど）を指定するだけで、標準化された環境が立ち上がります。 例えば、次のようなイメージです。 module "database" { source = "app.terraform.io/Findy/findy-XXXX-platform/aws//modules/database" version = "X.XX" environment = "staging" engine_type = "postgresql" db_parameter_group_name = "sre-staging" instance_class = "db.t4g.medium" number_of_instances = 2 preferred_backup_window = "20:05-20:35" service_name = "sre-sandbox" } このように、モジュールを組み合わせることで、複雑なインフラ環境を短時間で構築できます。 汎用モジュールで解決した課題 汎用モジュールの導入により、品質が担保されてスピード感のある構築が可能になりました。 汎用モジュールを使うことで、モジュール内の構成ならProduction環境とStaging環境を含めても最短3日で完了できるようになりました。 またパラメーターを指定するだけで環境が立ち上がるので、新しいメンバーでもすぐに戦力になれる仕組みを作ることができました。 Terraformのplanは成功するけどApplyはコケる問題 汎用モジュールの導入で大きな成果が得られた一方、汎用モジュールから呼び出した構成でTerraformのplanは成功するけどApplyはコケるという問題も発生しました。 この問題は、構築スピードの低下につながるため、Terraform Testを導入して対処しました。 詳細については、次の記事で詳しく紹介していますので、ぜひご覧ください。 tech.findy.co.jp まとめ 2025年、SREチームは多数のインフラ環境を構築しました。その裏側で、Terraformの汎用モジュールを活用することで、スピード感と品質を両立した環境構築を実現しました。 汎用モジュールの導入により、SREチームの環境構築はスピードアップしましたが、まだまだ改善の余地があります。 現在は、SREチームが主体となってインフラ環境を構築していますが、今後は開発チームが主体となって容易にインフラ構築できるPlatformを作りたいと考えています。 これにより、開発チームがより自律的にサービスをリリースできるようになり、SREチームはより注力すべきタスクに集中できるようになります。いわゆるPlatform Engineeringの取り組みを進めていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 2012年にサポート終了したVisual SourceSafeが、いまだに利用率2位。この調査結果に私はとても驚きました。 前回の記事 では、開発生産性を阻む「組織の3大課題」として、要件定義、会議、コミュニケーションの問題を取り上げました。今回は、それらと深く関わる技術環境の世代差と、AI時代における影響を考えます。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 ソースコード管理ツールの利用状況 意外と多かったVisual SourceSafe AI時代に広がるソースコード管理ツールの影響 AI開発支援ツールとGit連携 ツールの差がAI活用の差になる CI/CDパイプラインへの低い満足度 なぜ従来型ツールから移行しないのか 開発プロセスの認識の課題 まとめ お知らせ ソースコード管理ツールの利用状況 意外と多かったVisual SourceSafe 今回の調査で、ソースコード管理ツールの利用状況を調べてみたのですが、私はVisual SourceSafeをアンケート回答の選択肢に入れるかどうか、最後まで悩みました。さすがにもう使われていないだろうと思い込んでいたからです。 それは、大きな間違いでした。 ソースコード管理ツールの利用状況 順位 ツール名 利用率 回答者数 備考 1位 GitHub 30.5% 243名 Gitベース 2位 Visual SourceSafe 15.8% 126名 2012年サポート終了 3位 Subversion 13.7% 109名 集中型VCS 4位 Azure DevOps (Repos) 8.4% 67名 Gitベース 5位 GitLab 8.0% 64名 Gitベース 6位 CVS 3.6% 29名 2008年開発終了 7位 TFVC 2.4% 19名 従来型 8位 Bitbucket 1.8% 14名 Gitベース 9位 Gitea 1.6% 13名 Gitベース 9位 SourceForge 1.6% 13名 ホスティング 11位 Perforce (Helix Core) 1.3% 10名 大規模向け 12位 Mercurial 0.4% 3名 分散型VCS - その他 11.0% 88名 - （N=798、単一回答） GitHubが1位であることは予想通りでしたが、Visual SourceSafeが2位に入っていたのです。 Subversion（13.7%）、CVS（3.6%）を加えると、約3割の組織が従来型のバージョン管理システムを使用しています。 AI時代に広がるソースコード管理ツールの影響 AI開発支援ツールとGit連携 2023年以降、AI開発支援ツールが急速に普及しました。 GitHub Copilot、Cursor、Claude Code、Devin、Clineなど、いずれもGitベースのワークフローを前提に設計されています。そのため、従来型ツールの環境ではこれらのツールを十分に活用できません。 AIがコードベース全体を把握できず、提案の精度が下がる（リポジトリ連携機能） 変更履歴や差分を活用したコード生成ができない（diff/commit統合） コードレビューやタスク管理の自動化が使えない（PR自動作成、イシュー管理） DevinやClineなどAIエージェント系ツールは、コード補完にとどまらず、プルリクエスト作成、コードレビュー、イシュー管理まで自動化します。これらはGitHub/GitLabのAPIを前提としているため、旧来のバージョン管理では活用できません。 このツール環境の差は、どのような影響をもたらすのでしょうか。 ツールの差がAI活用の差になる GitHub社の調査によると、Copilot利用者は特定のタスク（HTTPサーバー実装）において、非利用者より 55%速く完了した と報告されています。日常業務すべてで同じ効果が出るとは限りませんが、無視できない差です。 Visual SourceSafe（15.8%）とSubversion（13.7%）を合わせると約3割の組織が、こうしたAI開発支援ツールを十分に活用できない環境にあります。このようなツール環境の違いが、将来の生産性格差につながっていく可能性があります。 つまり、AI活用の有無が開発速度に影響する可能性があります。 CI/CDパイプラインへの低い満足度 次のグラフは、満足度が50%を下回った項目を抜粋したものです。 開発基盤の満足度（全7項目が50%未満、ワースト順） 項目 満足度 CI/CDパイプライン 14.2% ドキュメンテーション 17.5% タスク管理システム 18.2% コードレビュープロセス 19.2% 開発環境整備 24.7% チーム内意思決定 34.1% チーム内コミュニケーション 37.1% （N=798） CI/CDパイプラインの満足度はわずか14.2%で、最も低い結果となりました。 この低さは、ソースコード管理ツールの選択と無関係ではないと思います。現在主流のCI/CDツールはGitベースのバージョン管理を前提としており、Visual SourceSafeやSubversionとシームレスに連携することが難しいからです。 なぜ従来型ツールから移行しないのか 従来型ツールを使い続ける組織には、それぞれの事情があると考えられます。 基幹システムや業務システムとの連携が従来型ツール前提で構築されている 過去の履歴データ、ワークフロー、ビルドスクリプト等の移行に膨大な工数がかかる 長年使い続けたツールに習熟したメンバーが多く、再教育コストが高い 「動いているものは触るな」という保守的な判断が優先される ウォーターフォール型ではリリース頻度が低く、Gitベースのワークフローの恩恵を感じにくい 大規模組織ほど、これらの要因が重なり移行が難しくなります。 とはいえ、全面移行にはリスクが伴います。履歴データの損失、一時的な生産性低下、デリバリー遅延、メンバーの抵抗などです。一方で、現状維持にも見えないコストがあります。セキュリティリスクの増大、新しい技術との統合困難、採用市場での不利など、これらは時間とともに大きくなっていきます。 具体的な移行のロードマップは、最終回（第8回）で取り上げます。 開発プロセスの認識の課題 ソースコード管理ツールの選択は、組織の開発プロセスに対する認識とも関連しています。調査からは、開発プロセスの認識にも課題が見えてきます。 開発フレームワークの認識状況 開発フレームワーク 回答率 回答者数 ウォーターフォール 36.8% 294名 よくわからない 18.2% 145名 ウォーターフォールとアジャイルのハイブリッド 13.2% 105名 【アジャイル開発】決まったフレームワークはない 13.2% 105名 【アジャイル開発】スクラム 6.8% 54名 【アジャイル開発】XPのプロセス 3.8% 30名 【アジャイル開発】大規模スクラム：LeSS 2.4% 19名 【アジャイル開発】大規模スクラム：SAFe 1.3% 10名 【アジャイル開発】大規模スクラム：Nexus 1.3% 10名 【アジャイル開発】大規模スクラム：Scrum@Scale 0.8% 6名 【アジャイル開発】大規模スクラム：その他 0.8% 6名 リーン 0.4% 3名 カンバン 0.3% 2名 その他 1.0% 8名 （N=798） なんと、約5人に1人（18.2%）が自分の組織がどんな開発フレームワークを使っているか「よくわからない」と回答しています。 開発フレームワークを十分に理解できていないということは、 なぜそのプロセスで開発しているのか どのような改善が可能なのか 自分の役割がプロセス全体のどこに位置するのか こうしたことが把握しづらくなります。 この問題は、第3回で取り上げた「不明確な要件」の問題とも関連しています。開発プロセスが明文化・共有されていない組織では、要件定義も曖昧になりがちだと思われます。 まとめ 798名の調査から見えてきたのは、日本の開発現場における技術環境の世代差です。Visual SourceSafeが15.8%、Subversionが13.7%と、約3割の組織が従来型ツールを使い続けています。CI/CDパイプラインの満足度は14.2%にとどまり、18.2%は自組織の開発手法を「よくわからない」と答えました。 AI時代において、このツール環境の差はさらに広がっていくでしょう。最新のAI開発支援ツールはGitベースのワークフローを前提としているからです。ただし、ツールを入れ替えるだけでは解決しません。技術基盤の刷新と組織文化の変革、両方が必要です。 次回は「 なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 」をお届けします。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの 第6回、なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策 数値化への懸念と向き合う方法 第7回、生産性向上を阻む組織の壁 ── 37.8%が未着手の深刻な理由 経営層を説得する具体的な方法 第8回、既存システムから次世代への変革 ── 日本の開発現場が立つ分岐点 品質文化を強みに変える改革のロードマップ お知らせ 「 Development Productivity Conference 2026 」が2026年7月22日〜23日に開催されます。継続的デリバリー（CD）の先駆者であり『継続的デリバリーのソフトウェア工学』著者のDave Farley氏が初来日。日本からはテスト駆動開発の第一人者・和田卓人氏が登壇します。 prtimes.jp ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 2025年はSpec Driven DevelopmentやAI-DLCなどといった新しい開発手法が注目を集める年になりました。 ファインディでも新しい開発手法への取り組みを進めており、その一環として要件定義、設計、タスク分解、Issue作成までのフローを自動化しました。 そこで今回は、自動化したフローの内容と仕組みを実現したカスタムコマンドについて紹介します。 それでは見ていきましょう！ 背景と課題 既存の開発手法の検討 解決策: AIフレンドリーなIssue カスタムコマンドの仕組み 概要とフロー ステップ1: 要件の理解 ステップ2: コードベースの探索 ステップ3: 要件の明確化 ステップ4: 設計 ステップ5: タスク分解 ステップ6: Issue作成 カスタムコマンド作成のコツ まとめ 採用情報 背景と課題 機能追加の要件から、設計、タスク分解、Issue作成までを行う必要があります。これらを生成AIに任せたいところですが、必要とされる事前知識が多くハードルが高いという課題がありました。 システム全体を把握できていないと適切な設計が難しいケースもあります。また、生成AIに対して効果的な依頼を作成するには明確で簡潔なステップ構造にすることが重要です。 つまり明確な要件を定義して、 生成AIが正しい方法と手順を理解して実行できる ように、 設計図や指示書をAIフレンドリーな形で用意する必要があった のです。 既存の開発手法の検討 2025年はSpec Driven DevelopmentやKiroといった新しい開発手法が注目を集めました。これらは要件定義から実装まで一貫した自動化を目指すアプローチです。 私たちもこれらの手法を検討しましたが、タスク分解とPull requestの粒度に対する考え方に課題を感じました。 Spec Driven Developmentでは、システム全体の仕様を詳細に定義してから実装に進みます。これは大規模な機能開発や新規プロジェクトでは有効ですが、仕様の粒度やSpec/Taskの部分が大きくなりがちです。その結果、実装を進めると大きな変更を含むPull requestが作られることになり、コードレビューの負担が増大する傾向があります。 どちらにも利点がありますが、私たちはレビューの品質とチーム全体の開発速度を重視して、 タスク分解と粒度に重点を置いたアプローチが必要 だと考えました。 解決策: AIフレンドリーなIssue この課題を解決するため、 システムの現状を把握して、必要な要件をタスク分解してIssueに切り出すカスタムコマンド を構築しました。 重要なのは、 Pull requestとタスクの粒度を維持しつつ、生成AIが理解しやすく精度の高いIssueを自動生成する ことです。この一連の流れをカスタムコマンドで自動化しました。 Issueが作成されたら、その内容や手順が正しいのかどうかチェックして、問題なければ そのまま生成AIに渡して実装を進めてもらう ようになります。 カスタムコマンドの仕組み 概要とフロー 今回紹介するカスタムコマンドは要件とコードベースを元に、要件の明確化、設計、タスク分解、Issue作成までを自動化します。 特徴的なのはインタラクティブな形式を採用している点です。曖昧な部分や不明点があれば、その都度生成AIが質問を投げかけてきます。人間は質問に答えながら生成AIとの対話を通じて要件を明確化していきます。 このプロセスを経て、生成AIが設計を行い、タスク分解を実施し、最終的にGitHubのIssueを自動で作成します。人間が行うのは作成されたIssueのレビューだけです。 Issueのレビューが完了したら、そのIssueをそのまま生成AIに渡して実装を進めてもらいます。Pull requestの粒度を意識した形でIssueが作成されるため、後続のコードレビューの負担も軽減されます。 このカスタムコマンドの全体フローは次のようなイメージです。 これら全てのフローを実行するために必要なカスタムコマンドやSkill、Sub Agentを社内Pluginとして開発組織全体に展開しています。 ステップ1: 要件の理解 まずは実現したい要件を生成AIが理解するところから始めます。このステップのフローは次のようなイメージです。 カスタムコマンドを実行して実現したい要件をパラメータ経由で伝えます。この段階では要件がある程度曖昧でも問題ありません。 ❯ /plugin:feature-breakdown 複数ユーザーの新規登録を一括で実行する機能を追加したい ⏺ I'll help you break down the bulk user registration feature into implementation tasks and create GitHub issues. Let me start by creating a TODO list for all phases. ⏺ Phase 1: 要件の理解 初期リクエスト: 複数ユーザーの新規登録を一括で実行する機能を追加したい 要件の中に曖昧な内容があれば生成AIが確認のための質問を投げかけてきます。対話を通じて徐々に要件を明確にしていきます。 今回は追加したい機能を具体的にするために生成AIから幾つかの質問が投げかけられました。解答を選択式にすることで、スムーズに要件を明確化できます。 この機能について、以下の点を明確にさせてください。 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ← ☐ 対象ユーザー ☐ 入力形式 ☐ 認証フロー ☐ エラー処理 ✔ Submit → この一括登録機能は誰が使うことを想定していますか？ ❯ 1. 管理者（AdminUser）のみが使用 管理画面から管理者が実行する機能として実装。一般ユーザーは使用できない。 2. 組織の管理者（Org内の特定ロール） 組織内の権限を持つユーザーが自組織のメンバーを一括登録できる。 3. 一般ユーザーも使用可能 全ユーザーが利用可能な機能として実装。 4. Type something. 解答を選択式にするためにClaude CodeのToolの AskUserQuestion を利用するようにプロンプトに明記すると便利です。 AskUserQuestion は情報を収集または曖昧さを明確にするために、ユーザーに複数選択肢の質問をします。 一通りの質問に回答すると生成AIが要件を整理してくれます。ここまでの選択で要件を理解することができました。認識にズレがなければこのまま次のステップに進みます。何かしらに誤りがあった場合、この段階で軌道修正もできます。 ⏺ User answered Claude's questions: ⎿ · この一括登録機能は誰が使うことを想定していますか？ → 管理者（AdminUser）のみが使用 · ユーザーデータの入力形式はどのようなものを想定していますか？ → CSV/TSVファイルのアップロード · 登録時のユーザー認証フローはどうしますか？ → 確認メール送信（既存フロー準拠） · 登録処理中のエラーハンドリングはどうしますか？ → 部分成功を許可 ⏺ ありがとうございます。要件を整理します。 ⏺ 理解した要件 機能: 複数ユーザーの新規登録を一括で実行する機能 要件の詳細: - 対象ユーザー: 管理者（AdminUser）のみが使用可能 - 入力形式: CSV/TSVファイルのアップロード（email, name, org_id等のカラム） - 認証フロー: 確認メール送信（既存の単一ユーザー登録フローと同じ） - エラー処理: 部分成功を許可（成功したユーザーは登録、失敗したユーザーはエラーレポートで返す） ステップ2: コードベースの探索 次に、要件を実現させるために既存のコードベースがどうなっているのかを理解する必要があります。 次のようなフローでコードベースを探索していきます。 既存のコードベースを理解するため、 Claude Codeの公式Pluginであるfeature-dev にある code-explorerエージェント を活用します。このエージェントはプロジェクトの構造やパターンを自動的に分析して実装に必要な情報を収集します。feature-devプラグインをインストールするだけでcode-explorerエージェントを利用できるようになります。 要件を分割して複数のcode-explorerエージェントを並列で起動します。各エージェントが特定の観点からコードベースを探索して必要な情報を収集します。 ⏺ Phase 2: コードベースの探索 既存のコードとパターンを理解するため、複数のcode-explorerエージェントを並列で起動します。 Running 3 feature-dev:code-explorer agents… (ctrl+o to expand) ├─ Explore user registration architecture · 12 tool uses · 29.1k tokens │ ⎿ Search: **/models/admin*.py ├─ Explore admin API patterns · 12 tool uses · 27.6k tokens │ ⎿ Read: main.py └─ Explore CSV and file handling · 10 tool uses · 17.0k tokens ⎿ Search: **/api/routes/**/*.py ctrl+b to run in background ⏺ Excellent! Now let me read the critical files identified by the code-explorer agents to deepen my understanding. ⏺ Read(src/api/routes/user/users.py) ⎿ Read 60 lines ⏺ Read(src/api/routes/user/users.py) ⎿ Read 60 lines ⏺ Read(src/api/routes/admin/orgs.py) ⎿ Read 70 lines ⏺ Read(src/api/routes/user/orgs/teams.py) ⎿ Read 60 lines ⏺ Read(src/services/email/email_service.py) ⎿ Read 132 lines 今回は複数のユーザー登録を一括で実行する機能を追加したいので、既存のユーザー登録処理や管理者用APIのパターン、CSVファイルの取り扱い方法などを中心にコードベースを探索しているようです。 要件を実現させるために必要なコードベースの情報が揃ったようなので、次のステップに進みます。 ステップ3: 要件の明確化 次は入力した要件とコードベースの情報を元に、要件を更に明確化していきます。 既存コードと要件を精査して曖昧な内容が残っていれば、追加で質問が投げかけられます。対話を繰り返すことで実装に必要な情報を揃えていきます。 ⏺ Phase 3: 明確化のための質問 コードベースの調査結果から、以下の点について確認させてください。 ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ☐ CSV Columns CSVファイルにはどのような情報を含めますか？ ❯ 1. 必須情報：メール、名前、ロール (Recommended) email, first_name, last_name, roleの4カラム。GitHubアカウントはオプション 2. 必須情報：メールと名前のみ email, first_name, last_nameの3カラム。ロールはデフォルトでmember 3. メールアドレスのみ emailの1カラムだけ。他の情報は後から追加 4. Type something. このステップではエラーハンドリングやエッジケースなど、細かい点についての要件を明確化します。 ⏺ Phase 3: 明確化のための質問 コードベースの調査結果から、以下の点について確認させてください。 ⏺ User answered Claude's questions: ⎿ · CSVファイルにはどのような情報を含めますか？ → 必須情報：メール、名前、ロール (Recommended) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ☐ Duplicate Emails 既存ユーザー（同じメールアドレス）がいた場合、どう処理しますか？ ❯ 1. スキップして結果に記録 (Recommended) 既存ユーザーは登録せず、skipped_emailsリストとして返す 2. エラーとして返す 既存ユーザーがいたらエラー情報を返し、その行を登録しない 3. 情報を更新する 既存ユーザーの名前やロールをCSVの値で更新 4. Type something. ここまでで要件と既存コードの変更内容が明確化されました。次のステップで設計に進みます。 ステップ4: 設計 設計フェーズでは、 Claude Codeの公式Pluginであるfeature-dev にある code-architectエージェント を活用します。 このエージェントは設計方針を提案してくれます。開発者は提案された選択肢の中からプロジェクトに最適な実装方針を選ぶことができます。この選択により実装の方向性が確定します。 設計に関するフローは次のようなイメージになります。 今回は最小構成、クリーンアーキテクチャ、実用的バランスの3つのアプローチでcode-architectエージェントを並行稼働して最適な設計方針を提案してもらいました。 ⏺ Phase 4: アーキテクチャ設計 それでは、3つの異なるアプローチでアーキテクチャ設計を行います。 ⏺ Running 3 feature-dev:code-architect agents… (ctrl+o to expand) ├─ Design minimal change approach · 3 tool uses · 10.1k tokens │ ⎿ Search: send_invite_user_email ├─ Design clean architecture approach · 4 tool uses · 10.1k tokens │ ⎿ Search: src/services/**/*.py └─ Design pragmatic balance approach · 0 tool uses ⎿ Initializing… ctrl+b to run in background ⏺ 3 feature-dev:code-architect agents finished (ctrl+o to expand) ├─ Design minimal change approach · 20 tool uses · 25.2k tokens │ ⎿ Done ├─ Design clean architecture approach · 26 tool uses · 41.0k tokens │ ⎿ Done └─ Design pragmatic balance approach · 0 tool uses ⎿ Done ⏺ Perfect! Now I have three comprehensive architecture designs. Let me present them to the user for selection. ⏺ 3つのアーキテクチャアプローチが完成しました。それぞれの特徴を整理してご提案します。 3つのアプローチ比較 1. 最小変更アプローチ (Minimal Change) 特徴: - CSV処理をルートハンドラに直接実装（約150行の単一ファイル） - 既存パターンを最大限活用（teams.pyの部分成功パターン） - 新規作成ファイル: 2個（エンドポイント + テスト） メリット: - 最速で実装可能（2 PR、~650行） - シンプルで理解しやすい - 既存コードとの整合性が高い デメリット: - ルートハンドラが長くなる（~150行） - CSV処理ロジックの再利用が困難 - 将来の拡張（Excel対応など）に追加実装が必要 タスク数: 2個 --- 2. クリーンアーキテクチャアプローチ (Clean Architecture) 特徴: - サービス層を導入して責務を分離 - Parser（CSV解析） - Validator（バリデーション） - UserImportService（オーケストレーション） - 新規作成ファイル: 7個 メリット: - 将来の拡張が容易（Excel, JSON対応） - テストが容易（各層を独立してテスト可能） - ビジネスロジックの再利用性が高い - 保守性が高い デメリット: - 初期実装に時間がかかる（6 PR、~730行） - 抽象化により複雑さが増す - シンプルなCSV処理に対してはオーバーエンジニアリングの可能性 タスク数: 6個 --- 3. 実用的バランスアプローチ (Pragmatic Balance) 特徴: - サービス層を導入するが、Parser/Validatorは分離しない - UserImportServiceで一元管理 - 新規作成ファイル: 5個 メリット: - 適度な抽象化で保守性を確保 - 実装速度とコード品質のバランスが取れている - 将来の拡張もある程度対応可能 デメリット: - クリーンアーキテクチャほどの柔軟性はない - 最小変更アプローチほどシンプルではない タスク数: 5個 --- ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ☐ Approach どの実装アプローチを採用しますか？ 1. 実用的バランス (Recommended) 開発速度と品質のバランス。サービス層を導入しつつもシンプルさを維持。タスク数: 5個 2. 最小変更 最速で実装。ルートハンドラに直接実装。既存パターンを最大限活用。タスク数: 2個 ❯ 3. クリーンアーキテクチャ 保守性と拡張性を重視。Parser/Validatorを分離し、将来の複数フォーマット対応を考慮。タスク数: 6個 4. Type something. 様々な設計方針ごとにメリット、デメリットなどが提示されます。要件やプロジェクトの方針にもよりますが、今回はクリーンアーキテクチャを選択します。設計方針が決まったので次のタスク分解のステップに進みます。 ステップ5: タスク分解 確定した設計方針を元に実装に必要なタスクを洗い出して分解します。 今回のカスタムコマンドで特に重要なのは、Pull requestやIssueの粒度を考慮することです。今回のカスタムコマンドの調整により、レビューしやすく適切な粒度でマージしやすい最適な粒度に分解してくれます。 Pull requestやIssueの粒度に関するガイドラインはSkillに切り出しています。 Sub AgentやSkillに切り出すことにより、タスク分解の品質を継続的に改善できるだけでなく、カスタムコマンドの一連の流れのコンテキストを適切に管理できるようになります。 今回はクリーンアーキテクチャを選択しており、最初に各種共通処理の作成とリファクタを行い、その後にAPIを追加するというタスクの分け方になっているようです。 ⏺ 承知しました。クリーンアーキテクチャアプローチで進めます。 それでは Phase 5 に進んで、task-breakdown Skillを使ってタスク分解を評価・調整します。 ⏺ Skill(task-breakdown) ⎿ Successfully loaded skill ⏺ Task Breakdown Skillがロードされました。それでは、Phase 4で得たクリーンアーキテクチャアプローチのタスク分解を評価します。 code-architectが提案したタスク分解 以下は、クリーンアーキテクチャアプローチで提案された6つのタスクです： Task 1: [Data] ドメインモデルの追加 - 変更ファイル: - CREATE: src/services/user_import/models.py - CREATE: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_models.py - 概要: ImportRow, ValidationError, CreatedUser, ImportResult モデルを作成 - 依存関係: なし Task 2: [Logic] CSVパーサーの実装 - 変更ファイル: - CREATE: src/services/user_import/parser.py - MODIFY: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_parser.py - 概要: CSVParserインターフェースとDefaultCSVParserを実装 - 依存関係: Task 1（ImportRowモデルが必要） Task 3: [Logic] バリデーターの実装 - 変更ファイル: - CREATE: src/services/user_import/validator.py - MODIFY: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_validator.py - 概要: UserDataValidator（ビジネスルール検証）を実装 - 依存関係: Task 1（ImportRow, ValidationErrorモデルが必要） Task 4: [Logic] ユーザーインポートサービスの実装 - 変更ファイル: - CREATE: src/services/user_import/user_import_service.py - MODIFY: src/services/user_import/__init__.py - CREATE: tests/services/user_import/test_user_import_service.py - 概要: UserImportService（オーケストレーション層）とメール連携 - 依存関係: Task 1, 2, 3（すべてのコンポーネントが必要） Task 5: [API] 管理者用一括登録エンドポイント - 変更ファイル: - CREATE: src/api/routes/admin/user_import.py - MODIFY: main.py - CREATE: tests/api/routes/admin/test_user_import.py - 概要: POST /api/v1/admin/users/import エンドポイントの実装 - 依存関係: Task 1, 2, 3, 4（サービス層全体が必要） --- Task Breakdown Skillによる評価 1. タスクの粒度チェック Task 1: ドメインモデル - ファイル数: 3個 ✅ (理想的) - 行数: ~80行 ✅ (適切) - 評価: 適切なサイズ Task 2: CSVパーサー - ファイル数: 3個 ✅ (理想的) - 行数: ~100行 ✅ (適切) - 評価: 適切なサイズ Task 3: バリデーター - ファイル数: 3個 ✅ (理想的) - 行数: ~120行 ✅ (適切) - 評価: 適切なサイズ Task 4: ユーザーインポートサービス - ファイル数: 3個 ✅ (理想的) - 行数: ~180行 ✅ (適切) - 評価: 許容範囲だが、メール連携部分を分離できる可能性あり Task 5: APIエンドポイント - ファイル数: 3個 ✅ (理想的) - 行数: ~100行 ✅ (適切) - 評価: 適切なサイズ 2. 密結合の識別 ✅ 密結合が適切に保たれているもの: - Task 1: モデル定義 + テスト （実装とテストが同一PR） - Task 2: Parser実装 + テスト （実装とテストが同一PR） - Task 3: Validator実装 + テスト （実装とテストが同一PR） - Task 4: Service実装 + テスト （実装とテストが同一PR） - Task 5: APIエンドポイント + ルーティング + テスト （API完全性が保たれている） ❌ 潜在的な密結合の問題: なし 3. 独立性の検証 独立してrevertできるか？ - Task 1: ✅ 他のタスクに影響なし（モデルのみ） - Task 2: ✅ Task 1に依存するが、独立して削除可能 - Task 3: ✅ Task 1に依存するが、独立して削除可能 - Task 4: ⚠️ Task 2, 3に依存するため、revert時は順序が重要 - Task 5: ✅ Task 4に依存するが、独立して削除可能（ルーター登録を削除するだけ） 各PRマージ後、アプリケーションは正常動作するか？ - Task 1マージ後: ✅ モデルのみ追加、既存機能に影響なし - Task 2マージ後: ✅ パーサーのみ追加、既存機能に影響なし - Task 3マージ後: ✅ バリデーターのみ追加、既存機能に影響なし - Task 4マージ後: ✅ サービス層のみ追加、APIエンドポイントがないため既存機能に影響なし - Task 5マージ後: ✅ 新規エンドポイント追加、既存機能に影響なし 4. 依存関係の整理 Task 1 (モデル) ├── Task 2 (Parser) ← Task 1に依存 └── Task 3 (Validator) ← Task 1に依存 └── Task 4 (Service) ← Task 2, 3に依存 └── Task 5 (API) ← Task 4に依存 並列実装可能なタスク: - Task 2とTask 3は並列実装可能（どちらもTask 1にのみ依存） 5. 推奨事項 現在のタスク分解は非常に良好です。以下の理由から、このまま進めることを推奨します： 良い点: 1. ✅ 各タスクのサイズが適切（3-10ファイル、100-200行） 2. ✅ 実装とテストが密結合として同一PRに含まれている 3. ✅ 各タスクが独立してrevert可能 4. ✅ 依存関係が明確で、並列実装の余地もある 5. ✅ 各PRマージ後もアプリケーションは正常動作する 最終判断: 現在のタスク分解をそのまま採用 --- ここまでで要件を正しい方法と手順で実現するために必要な準備が整いました。最後のステップをこれらを元にIssueを作成していきます。 ステップ6: Issue作成 最後のステップで、分解したタスクを元にGitHubのIssueを自動で作成します。 作成前には確認ステップを踏み、認識がズレていないか最終チェックを行います。問題がなければ、そのままIssueを作成してSub Issueの紐付けとrelationshipの設定まで完了させます。 これにより親Issueと子Issueが適切に構造化された状態で、すぐに実装に取り掛かれるようになります。 GitHubのIssueを作成する処理もSub Agentに切り出しています。Issueを作成するために必要な情報量が多く、すぐにコンテキストが肥大化してしまうからです。 そのためIssue作成専用のSub Agentを用意して必要な情報だけ渡してIssueを作成する形にしています。 ⏺ Phase 7: GitHub Issueの作成 github-issue-creator agentを起動してGitHub issueを作成します。 ⏺ plugin:github-issue-creator(Create GitHub issues) ⎿ Done (25 tool uses · 117.1k tokens · 8m 35s) ⏺ ✅ Feature Breakdown 完了！ GitHub Issueの作成が完了しました。以下が作成されたIssueです。 📋 親Issue #1 - Feature: 複数ユーザーの一括登録機能 https://github.com/Findy/Example/issues/1 📦 子Issue（実装タスク） 1. #2 - [Data] ドメインモデルの追加 + テスト https://github.com/Findy/Example/issues/2 依存関係: なし 2. #3 - [Logic] CSVパーサーの実装 + テスト https://github.com/Findy/Example/issues/3 依存関係: #2 3. #4 - [Logic] バリデーターの実装 + テスト https://github.com/Findy/Example/issues/4 依存関係: #2 4. #5 - [Logic] ユーザーインポートサービスの実装 + テスト https://github.com/Findy/Example/issues/5 依存関係: #2, #3, #4 5. #6 - [API] 管理者用一括登録エンドポイント + テスト https://github.com/Findy/Example/issues/6 依存関係: #5 --- 📊 Issue構造 📋 #1 Feature: 複数ユーザーの一括登録機能 ├── 📦 #2 [Data] ドメインモデルの追加 + テスト │ ├── ⚙️ #3 [Logic] CSVパーサーの実装 + テスト │ └── ⚙️ #4 [Logic] バリデーターの実装 + テスト │ └── ⚙️ #5 [Logic] ユーザーインポートサービスの実装 + テスト │ └── 🔌 #6 [API] 管理者用一括登録エンドポイント + テスト --- 🎯 次のステップ 1. 実装開始: #2から順番に実装してください 2. 並列実装可能: #3と#4は#2完了後、並列で実装可能です 3. 進捗管理: 親Issue #1で全体の進捗を確認できます 4. PRの作成: 各Issueごとに1つのPRを作成してください --- 📝 設計サマリー 採用アーキテクチャ: クリーンアーキテクチャ - Parser層（CSV解析） - Validator層（ビジネスルール検証） - Service層（オーケストレーション） - API層（HTTPハンドリング） 主な技術要素: - CSVパース: Python標準ライブラリ csv.DictReader - バリデーション: Pydantic + カスタムロジック - トランザクション: ユーザー単位のコミット - メール送信: 既存のEmailService再利用 - エラー処理: 部分成功パターン 受入基準: - テストカバレッジ90%以上 - 各PRは3-10ファイル、200-500行の変更 - すべてのPRは独立してrevert可能 Feature Breakdown コマンドの全フェーズが完了しました！ これで要件の策定から適切な粒度でのIssue作成までの一連の流れが完了しました。Issueの内容をチームでレビューして、実装を生成AIに任せましょう。適切な粒度でタスクが分解されているので、Pull requestの粒度も適切になり、レビューの負担が大幅に軽減されます。 カスタムコマンド作成のコツ 様々な開発タスクを効率化するためには必要な情報を用意する必要があります。その結果、コンテキストが肥大化してしまい精度が一気に落ちてしまうことがよくあります。 まずは一通りの流れをカスタムコマンドで作成して、内容やスコープに応じてSkillやSub Agentに切り出していくのが良いです。特定の知識やガイドラインなどはSkillに切り出しましょう。メインのコンテキストには不要で結果のみ必要な情報を扱う場合はSub Agentに切り出すのが良いです。 いかにしてコンテキストを最小限に保つかがコツです。 カスタムコマンドに限らず、 コンテキストが肥大化すると生成AIの精度は一気に落ちてしまいます。 必要な情報だけを適切に渡して維持し続けることが、生成AIを活用する上で非常に重要です。 まとめ 今回紹介したカスタムコマンドは、誰でも高品質で適切な粒度のAIフレンドリーなIssueを作成できるようにするものです。 生成AIを活用した開発では、生成AIが理解しやすい形で要件と設計を伝えることが重要です。要件定義から設計、タスク分解、Issue作成までのフローを自動化することで、開発者はより本質的な開発業務に集中できるようになります。生成AIとの協業による開発スタイルは、今後ますます重要になっていくでしょう。 最後になりますが、このたび 2026年2月18日(水)にFindy AI Meetup in Fukuoka #4の開催が決定 しました！ findy-inc.connpass.com 会場へのアクセスは天神駅から徒歩3分となっています。またTVCM公開記念ノベルティや、イベント後半には懇親タイムもご用意しています。 申込みの先着順となっておりますので、気になっている方は早めにお申し込みいただくことをおすすめします。生成AIの活用事例に興味のある方は奮ってご参加ください！ みなさんにお会いできることを楽しみにしています！ 採用情報 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 弊社でも例に漏れず、生成AIを活用して開発効率の向上に取り組んでいます。その中でFindy Team+で開発組織の生産性をチェックしていたところ、Pull requestの質が落ちているのでは？という仮説が浮かび上がりました。 今回は仮説が浮かんできた経緯と、その対策として導入したセルフレビューの仕組みについて紹介します。 それでは見ていきましょう！ 思っていたよりPull requestの数が増えていなかった 理解しないままレビュー依頼を出していた AIでセルフレビューを支援する仕組みを導入 まとめ 思っていたよりPull requestの数が増えていなかった 稼働人数は昨年比で1.5倍程度増えており、それと比例する形でPull requestの作成数も単純に1.5倍に増えていました。この図から、人数の増加とPull request作成数が概ね比例していることが分かります。 しかし、1人あたりのPull requestの作成数は、昨年とほぼ変わらずでした。この図を見ると、人数が増えても1人あたりのPull request作成数はほぼフラットであることが分かります。 生成AIにPull requestを作成してもらうのであれば、1人あたりの作成数も伸びて、増えた人数以上に総数も伸びるはずでは？ここが疑問ポイントでした。 Pull requestの数が多ければ必ずしも良いわけではありませんが、AIを導入しても1人あたりの数値が伸びていないということは、どこかしらに問題があるはずです。 Pull requestの作成数だけでは判断することが出来ないので、他の数値に目を向けてみました。すると、各種リードタイムが昨年比で悪化していることがわかりました。 その中でも私が特に目を付けたのが「レビューからApproveまでの平均時間」です。この数値が昨年比で平均約20分近くも伸びていたのです。 更に「平均コメント数」と「平均レビュー数」にも目を付けました。こちらも昨年比で30%近くも増えていたのです。 これらの数値の変化から、1つの仮説が浮かび上がりました。それは「レビューで指摘された内容の対応で各種リードタイムが伸びており、マージまでの時間が伸びて結果的にPull requestの作成数が伸びていないのでは？」ということです。 この仮説を一言で言うと、「作成されているPull requestの質が落ちているのでは？」と言い換えることもできます。仮説を整理できたので、その仮説が正しいのかどうかを検証することにしました。 理解しないままレビュー依頼を出していた AIが作成したPull requestを幾つか確認してみたところ、確かにセルフレビューである程度防げるような指摘が多く見受けられました。 例えばAIが次のようなテストコードを追加しているシーンがありました。 import { render, screen } from '@testing-library/react' ; it ( 'should render with isHiddenTitle' , () => { render(< HogeComponent isHiddenTitle />); expect ( screen .queryByText( "Title" )).not.toBeInTheDocument(); } ); 一見特に問題なさそうなテストコードですが、仮にテキストが常に非表示になっている状態だった場合、このテストコードは常に成功してしまいます。つまり、テストコードとしての意味を成していないのです。 特定の条件下で「表示されないこと」を守りたいのあれば、その条件下以外で「表示される」ことも同時に守る必要があります。この変更に対してはリードクラスのエンジニアからレビューで指摘が入り、次のようなテストコードになりました。 import { render, screen } from '@testing-library/react' ; it ( 'should render' , () => { render(< HogeComponent />); expect ( screen .getByText( "Title" )).toBeInTheDocument(); } ); it ( 'should render with isHiddenTitle' , () => { render(< HogeComponent isHiddenTitle />); expect ( screen .queryByText( "Title" )).not.toBeInTheDocument(); } ); このテストコードで文言が表示されること、特定の条件下のみで表示されないことの両方を守ることができるようになりました。 このように、AIが出力したコードを依頼主が理解しないままレビュー依頼を出しているケースが少なからず見受けられました。そしてそれらをレビューするリードクラスのエンジニアのレビュー負担が上がっており、結果的にマージまでのリードタイムが伸びている。という状態に陥っていたのです。 これらの多くは難しい問題点ではなく、セルフレビューの時点で気づくことが出来るような内容が大半でした。 AIが出力したコードの責任は人間にあります。 レビュー依頼を出す前に、まずセルフレビューをして、早い段階で問題点に気付けるように仕組みを作ることにしました。 AIでセルフレビューを支援する仕組みを導入 自動でレビューをしてくれるサービスも利用したのですが、汎用的な内容でのレビューなのでドメイン知識や個人の癖などを考慮出来ておらず、指摘内容としても薄いものが多く、レビュー依頼する前のセルフチェックという意味合いでは不十分でした。 そこで、自分自身にカスタマイズされたセルフレビューのチェックリストを作成する仕組みを内製することにしました。 流れとしてはこうです。 まず直近数カ月で自分が作ったPull requestの一覧を取得します。そのPull requestに対して作成されたレビューコメントを全て取得します。それらレビューコメントの全てをLLMに渡して、どういう内容や傾向で自分自身が指摘されているのかを分析後にチェックリストを作成します。 作成されたチェックリストに沿って、Claude Codeにセルフレビューしてもらいます。 一連の流れはこのようになります。 このシーケンス図から、チェックリストの生成からセルフレビュー、修正の反映までが一連のフローとして自動化されていることが読み取れます。 この一連の流れを全て自動で行うカスタムコマンドを作成し、Pluginsに入れて社内に展開しました。 チェックリストを更新するカスタムコマンドと、そのチェックリストを使ってセルフレビューを実行するカスタムコマンドは分けています。チェックリストは定期的に更新すれば良いので、セルフレビューの度に更新する必要はないからです。 まずチェックリストを作成するコマンドを実行して、次のようなファイルが出力されます。 # Self-Review Checklist for hoge このチェックリストは、過去3ヶ月間（2025年9月30日〜2025年11月26日）にマージされたPRとレビューコメントを分析して作成されました。 ## 🧪 テストコード ### アサーションの品質 - [ ] ` toEqual ` の代わりに ` toStrictEqual ` を使用しているか - より厳密な型チェックのため - [ ] テストケースは実装の意図を正確に検証しているか - [ ] スナップショットテストは適切に使用されているか ### テストの網羅性 - [ ] 主要な機能パスはすべてカバーされているか - [ ] エラーハンドリングのテストは含まれているか - [ ] エッジケースを考慮しているか ## 🎨 UI/UX 設計 ### アクセシビリティ - [ ] aria-label は適切に設定されているか - [ ] キーボード操作に対応しているか - [ ] カラーコントラストは十分か ## 🎯 コミットメッセージ ### Conventional Commits - [ ] プロジェクトのコミットメッセージ規約に従っているか - [ ] 適切な type を使用しているか（feat, fix, refactor, chore, etc.） - [ ] scope は正しく指定されているか --- **最終更新日**: 2025-11-28 **分析期間**: 2025-09-30 〜 2025-11-26 次にセルフレビューのコマンドを実行します。出力されたチェックリストの内容に沿って、変更箇所をレビューしてもらいます。実際の出力例は次のようになります。 > 変更箇所に対して、`self-review-check-list.md` の内容を元にレビューしてください ⏺ 変更箇所をレビューするために、まず self-review-check-list.md の内容を確認します。 ⏺ Search(pattern: "**/self-review-check-list.md") ⎿ Found 1 file (ctrl+o to expand) ⏺ Read(self-review-check-list.md) ⎿ Read 33 lines ⏺ Read(packages/feature-server/src/clients/github/github-client.spec.ts) ⎿ Read 863 lines ⏺ self-review-check-list.md の内容に基づいて、変更ファイルのレビューを実施しました。 レビュー結果 ✅ コード品質 命名の明確さ - 関数名や変数名が実際の動作を正確に表現しています - ドメイン用語（GitHub API関連）を正しく使用しています ✅ テストコード テストの網羅性 - 各関数に対して以下のテストケースを網羅しています： - すべてのパラメータを指定した成功ケース - 必須パラメータのみの成功ケース - エラーケース - toStrictEqual を使用してオブジェクト全体の検証を適切に行っています テスト依存関係 - 不要なテスト依存関係は追加されていません - プロジェクト標準のテストライブラリのみを使用しています ✅ プロジェクト固有のルール - TypeScript Deep Dive のスタイルガイドに従っています - ファイル名がケバブケース（github-client.spec.ts）になっています ⚠️ 改善提案 テストアサーションの統一性 packages/feature-server/src/clients/github/github-client.spec.ts:307 expect(response.data).toEqual(mockData); 他のテストケースでは toStrictEqual を使用していますが、ここだけ toEqual を使用しています。toStrictEqual に変更することを推奨します： expect(response.data).toStrictEqual(mockData); toStrictEqual は toEqual よりも厳密なチェック（undefined プロパティも検証）を行うため、より堅牢なテストになります。 --- 全体的に非常に高品質なテストコードです。上記の1点のみ修正すれば、チェックリストのすべての項目を満たしま す。 テストコードを変更した場合のセルフレビュー例ですが、コード品質やテストコード、プロジェクト固有のルールに関しては基本的にクリアしていましたが、改善提案として1点のみ指摘がありました。 このレビュー結果を元に、修正も自動で行ってもらいましょう。続いてプロンプトを実行します。 > レビュー結果を元に、変更箇所を修正してください ⏺ レビュー結果に基づいて修正します。 ⏺ Update(packages/feature-server/src/clients/github/github-client.spec.ts) ⎿ Updated packages/feature-server/src/clients/github/github-client.spec.ts with 1 addition and 1 removal 304 } 305 ); 306 expect(response.status).toBe(HttpStatusCode.OK); 307 - expect(response.data).toEqual(mockData); 307 + expect(response.data).toStrictEqual(mockData); 308 }); 309 310 it('fetch data with only required params', async () => { ⏺ 修正が完了しました。 修正内容 packages/feature-server/src/clients/github/github-client.spec.ts:307 変更前: expect(response.data).toEqual(mockData); 変更後: expect(response.data).toStrictEqual(mockData); この修正により、テストアサーションが統一され、すべてのテストケースで toStrictEqual を使用するようになりました。toStrictEqual は toEqual よりも厳密なチェック（undefined プロパティも検証）を行うため、より堅牢なテストになります。 これで self-review-check-list.md のすべての項目を満たすコードになりました。 この仕組みにより、定期的にチェックリストのファイルを更新することによって、セルフレビューの精度を上げ続けることが可能となります。 まとめ 今回はジュニアエンジニアがAIを使ってPull requestを作成した場合に、セルフレビューでのチェックが甘くなり、レビュワーの負担が上がっているといったケースでした。 「AIに使われる」のではなく、「AIを使う」ためにも、AIが出力したコードを理解することが必要不可欠です。AIが出力したコードの責任は人間にあります。自分自身の責任を果たす意味でも、生成AI時代のセルフレビューが持つ意味合いは、これまで以上に重要になってくるでしょう。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。 ファインディ株式会社でFindy AI+の開発をしているdanです。 Findy AI+ではLLMを活用した分析機能を提供しています。 分析対象は個人・チーム・組織と幅広く、データ量に応じて分析に時間がかかることがあります。分析が完了するまで画面に何も表示されないと、ユーザーは処理が進んでいるのか分からず、待ち時間が長く感じられてしまいます。 この課題を解消するため、LLM分析結果の表示にストリーミング出力を導入しました。 今回は、実装内容とどの程度待ち時間が改善されたのかについてお話しします。 Findy AI+とは ストリーミング対応前は何が問題だった？ 当初の設計 分析結果を見るのにどのくらいの時間を要していたのか どのように対応を進めたか ストリーミング対応の設計 肝となる実装の全体像 LangChainの astream() メソッド FastAPIでのストリーミング実装 ストリーミングレスポンスの生成 SSE（Server-Sent Events）の仕組み フロントエンドでの受信処理 ストリーミング対応後に得られた効果 おわりに Findy AI+とは Findy AI+ は、GitHub連携やプロンプト指示を通じて生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。 人と生成AIの協働を後押しし、開発組織の変革をサポートします。 Claude Code、GitHub Copilot、Codex、Devinなど様々なAIツールの利活用を横断的に分析しており、分析基盤にはLangChainを採用しています。また、日報やチーム分析などの機能でもLLMを活用しています。 LLM分析に使用するプロンプト調整についても記事を公開していますので、よかったらご覧ください。 tech.findy.co.jp ストリーミング対応前は何が問題だった？ 当初の設計 分析結果を見るのにどのくらいの時間を要していたのか 冒頭で述べた通り、Findy AI+では個人・チーム・組織と幅広いデータを分析対象としています。 分析に必要なデータ作成のAPIを例にあげます。 @ router.post ( "/api/v1/hoge" ) def create_hoge ( request: CreateHogeRequest, db: Session = Depends(get_db), ): # 1. データ取得 hoge = get_hoge(db, request.hoge_id) # 2. LLM呼び出し（全レスポンス待ち） client = Anthropic(api_key= "xxx" ) message = client.messages.create( model= "claude-sonnet-4-20250514" , max_tokens= 4096 , messages=[{ "role" : "user" , "content" : f "分析して: {hoge.content}" }], ) analysis_result = message.content[ 0 ].text # 3. 分析結果保存 save_analysis(db, hoge.id, analysis_result) # 4. レスポンス返却 return { "id" : hoge.id, "analysis" : analysis_result} やっていることは次の2つです。 LLM分析を行い完了後に分析結果を保存 フロントへデータを返す APIを呼び出してみると平均して30~40秒ほど時間がかかっていることが分かりました。 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 7341 100 6673 100 668 193 19 0:00:35 0:00:34 0:00:01 2059 実行してから分析結果を見るのに30~40秒程度かかるほど、遅すぎて使いものにならない状態でした。 どのように対応を進めたか ストリーミング対応の設計 新たに作成したストリーミングのAPIは下記の通りです。 肝となる実装の全体像 ストリーミング対応したサンプルコードは下記になります。 @ router.post ( "/api/v1/hoge/analysis/streaming" ) async def create_hoge_analysis_streaming ( request: AnalysisRequest, db: Session = Depends(get_db), ): # 1. データ取得 hoge = get_hoge(db, request.hoge_id) # 2. LangChainエージェント作成 agent = ChatAnthropic( model= "claude-sonnet-4-20250514" , anthropic_api_key= "xxx" , max_tokens= 4096 , ) # 3. StreamingResponse返却 return StreamingResponse( generate_streaming_response(agent, hoge, db), media_type= "text/event-stream" , ) async def generate_streaming_response ( agent: ChatAnthropic, hoge: Hoge, db: Session, ) -> AsyncGenerator[ str , None ]: """SSE形式でストリーミングレスポンスを生成""" accumulated_content = "" messages = [HumanMessage(content=f "分析して: {hoge.content}" )] # チャンクごとに送信 async for chunk in agent.astream(messages): if chunk.content: accumulated_content += chunk.content data = json.dumps({ "type" : "content" , "content" : chunk.content}) yield f "data: {data} \n\n " # 完了後にDB保存 save_analysis(db, hoge.id, accumulated_content) # 完了イベント送信 data = json.dumps({ "type" : "complete" , "content" : accumulated_content}) yield f "data: {data} \n\n " やっていることは次の2つです。 分析結果がチャンクで返ってくるので、そのままフロントに渡す 分析完了後に分析結果を保存・フロントに返す どのように分析結果をチャンク（断片したテキスト）形式で受け取るのかについて説明します。 これは、LangChainのストリーミングメソッドを使用することで実現可能です。 LangChainの astream() メソッド async for chunk in agent.astream(messages): print (chunk.content) # "Find" → "y AI+" → "AI利活用" のように少しずつ届く astream() は非同期ジェネレータを返し、LLM APIからのレスポンスをチャンク単位で受信できます。 通常の invoke() との違いは全文が返らないことです。 # invoke(): 全文が返るまで待つ result = agent.invoke(messages) # 数秒〜数十秒ブロック # astream(): チャンクごとに即座に処理できる async for chunk in agent.astream(messages): # 即座に開始 process(chunk.content) FastAPIでのストリーミング実装 @ router.post ( "/api/v1/hoge/analysis/streaming" ) async def create_hoge_analysis_streaming (request: AnalysisRequest): hoge = get_hoge(request.hoge_id) agent = ChatAnthropic(model= "claude-sonnet-4-20250514" , ...) return StreamingResponse( generate_streaming_response(agent, hoge), media_type= "text/event-stream" , ) StreamingResponse に非同期ジェネレータを渡すことで、yield するたびにクライアントへデータが送信されます。 ストリーミングレスポンスの生成 async def generate_streaming_response (agent, hoge) -> AsyncGenerator[ str , None ]: accumulated_content = "" messages = [HumanMessage(content=f "分析して: {hoge.content}" )] # チャンクごとにフロントへ送信 async for chunk in agent.astream(messages): if chunk.content: accumulated_content += chunk.content data = json.dumps({ "type" : "content" , "content" : chunk.content}) yield f "data: {data} \n\n " # 完了後にDB保存 & 完了イベント送信 save_analysis(hoge.id, accumulated_content) data = json.dumps({ "type" : "complete" , "content" : accumulated_content}) yield f "data: {data} \n\n " accumulated_content で全文を蓄積しDB保存の準備を行います yield f"data: {data}\n\n" でSSE形式でフロントへ送信することでストリーミング対応を行います SSE（Server-Sent Events）の仕組み StreamingResponse で media_type="text/event-stream" を指定することで、SSE形式でデータを送信できます。 SSEでは data: {JSON}\n\n という形式でイベントを送信します。クライアントはこのイベントを受信するたびに画面を更新できるため、LLMの出力をリアルタイムで表示できます。 data: {"type": "content", "content": "Findy "}\n\n data: {"type": "content", "content": "AI+では"}\n\n data: {"type": "content", "content": "..."}\n\n data: {"type": "complete", "content": "Findy AI+では..."}\n\n フロントエンドでの受信処理 フロントエンドでは fetch の ReadableStream を使ってストリーミングデータを受信します。 const response = await fetch ( '/api/v1/hoge/analysis/streaming' , { method : 'POST' , body : JSON . stringify ( { hoge_id : 123 } ), } ); const reader = response. body .getReader(); const decoder = new TextDecoder (); while ( true ) { const { done , value } = await reader.read(); if (done) break ; const chunk = decoder. decode (value); // "data: {...}\n\n" 形式のイベントをパース const events = chunk. split ( ' \n\n ' ). filter ( e => e. startsWith ( 'data: ' )); for ( const event of events) { const data = JSON . parse (event. replace ( 'data: ' , '' )); if (data. type === 'content' ) { // チャンクを画面に追加表示 appendText(data.content); } else if (data. type === 'complete' ) { // 完了処理 } } } このように、サーバー側でチャンクを yield するたびにフロントエンドで受信・表示することで、ユーザーは分析結果をリアルタイムで確認できます。 ストリーミング対応後に得られた効果 画面遷移から3秒程度で読み始めることができるので非常に使い勝手が良くなりました。 おわりに ストリーミング対応をしたことで分析に使用するデータ量が多くても逐一分析結果が表示されるようになりました。 LangChainを使用したストリーミング対応について少しでも参考になれば幸いです。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご応募ください。 herp.careers

こんにちは、Findy Freelanceでフロントエンドエンジニアをしている主計（かずえ）です。 この記事は、 ファインディエンジニア #3 Advent Calendar 2025 の25日目の記事です。 adventar.org Dependabotが作成するPRの対応、皆さんはどのように運用していますか？依存パッケージの更新は地味ながら継続的に発生する作業で、特に少人数チームでは対応工数の比率が無視できません。 この記事では、私たちのチームがDependabot PR対応を手動運用からDevin、そしてClaude Code Actionへと段階的に改善してきた過程を紹介します。それぞれのアプローチで得られた知見と、最終的にClaude Code Actionに落ち着いた理由をお伝えします。 Dependabot PRの対応フローを効率化したい方、AIツールを活用したコードレビューの自動化に興味がある方の参考になれば幸いです。2025年の変遷を書いているのでDependabot PRのAIレビューをこれから実施したい場合はClaude Code Actionのセクションを中心に見ていただければと思います。 手動時代 フロー 課題 Devinへ移行 Playbookとは SlackからPlaybookを呼び出して実行 承認時 非承認時 良かった点 運用していく中で見えてきたこと Claude Code Actionへ移行 bot作成PRでは動作しないためClaude Code Base Actionを利用 allowed_botsでClaude Code Actionへ移行 各CI完了後にレビューを実施 現在のフロー 承認時 非承認時 効果 注意点 ANTHROPIC_API_KEYはDependabot用のSecretに設定 WebFetchの不安定さ まとめ 手動時代 フロー Dependabot PRへの対応は、次のような流れで行っていました。 Dependabotが作成したPRを確認する CIの実行結果を待ち、成功・失敗を確認する 更新されたパッケージのリリースノートを確認し、Breaking Changesがないか調べる CIが失敗している場合は原因を調査し、必要に応じてコードを修正する 問題がなければレビューを行う マージする 一見シンプルなフローですが、実際に運用してみると様々な課題があります。 課題 まず、コンテキストスイッチのコストが大きいという問題がありました。Dependabot PRを順番にマージしていくと、他のPRとコンフリクトが発生してrebaseが必要になります。CIの実行を待っている間に別の作業を始め、CIが完了したら戻ってきて次のPRを処理する、という流れで作業が細切れになりがちでした。 リリースノートの確認も手間のかかる作業でした。Breaking Changesは基本的にCIが失敗するので気付けますが、稀にruntimeで問題が発覚することがあります。そのため、念のためリリースノートを確認してからマージするようにしていました。 また、人によってマージの判断基準にズレがあるという問題もありました。あるメンバーはCIが通っていればすぐにマージし、別のメンバーはリリースノートを細かく確認してからマージするといった具合です。リリースノートを確認するというルールは作れば防げますが、どれくらい詳細に確認するかなど個人の感覚に依存してしまいます。 少人数チームでは、こうした定型作業の工数比率が相対的に高くなります。週に数時間をDependabot PR対応に費やしていると、本来注力すべき開発作業に割ける時間が減ってしまいます。 Devinへ移行 こうした課題を解決するため、導入済みだったDevinのPlaybookをDependabot PRのレビューに活用してみることにしました。 Playbookとは DevinにはPlaybookという機能があります。これは繰り返し行うタスクの手順を定義しておき、再利用できる仕組みです。「Dependabot PRをレビューする」というPlaybookを作成しておけば、毎回同じ手順でレビューを実行できます。 次のような形でPlaybookに記載して繰り返し利用しておりました。 SlackからPlaybookを呼び出して実行 DevinはSlackと連携できるため、Slackから直接Playbookを呼び出すことができます。 「@Devin playbook:!hoge」とメンションするだけで、定義したPlaybookが実行される仕組みです。 レビューが実施されると各PRにコメントを残してくれます。 承認時 非承認時 良かった点 Devinを導入して良かった点は、1つのアクションで各PRのレビュー依頼が完結することでした。Slackでメンションするだけでレビューが始まるため、Devinの作業が完了した後は、各PRについたレビューを確認し、マージするだけで済むようになりました。 運用していく中で見えてきたこと 複数のDependabot PRが同時に作成された場合、一部のPRが漏れてしまうケースがありました。また、すでにレビュー済みのPRを再度レビューしてしまうこともありました。 これらはDevin自体の問題ではなく、1回の依頼で複数PRをまとめて処理させていた運用方法に起因する課題でした。DevinにはAPIが提供されているため、GitHub ActionsからPRごとにDevin APIを呼び出す仕組みを作れば解決できる課題と考えました。 Claude Code Actionへ移行 GitHub ActionsからDevin APIを呼び出す仕組みの構築を検討していたところ、Claude Code Actionがリリースされました。 Claude Code Actionは、名前の通りGitHub Actions上でClaude Codeを実行できるActionです。PRの作成やコメントをトリガーにして、自動でコードレビューやタスクの実行ができます。 PRごとにワークフローが実行されるため、「このPRに対してレビューを行う」というスコープが明確になります。公式のGitHub Actionとして提供されていることと、AIモデルを選択できることが決め手となり、Claude Code Actionへ移行することとしました。 bot作成PRでは動作しないためClaude Code Base Actionを利用 導入当初、Claude Code ActionにはDependabotのようなbotが作成したPRでは実行できないという制約がありました。 この制約を回避するため、Claude Code Base Actionを利用することにしました。Base Actionはbot作成のPRでも動作させることができ、機能的にもClaude Code Actionと同等のことができます。 allowed_botsでClaude Code Actionへ移行 その後、Claude Code Actionに allowed_bots オプションが追加されました。これにより、Dependabotが作成したPRでもClaude Code Actionを実行できるようになりました。 Claude Code Base Actionからの移行を行った理由は、機能的な差はほとんどないものの、他のCIワークフローとの一貫性を保つためでした。チーム内で複数のActionを使い分けるよりも、統一した方がメンテナンス性が高くなります。 各CI完了後にレビューを実施 Claude Code Base Actionのワークフローはlint、test、typecheckなどのCIジョブが完了した後にClaude Code Base Actionを実行するようにしました。そうすることで、CIの結果を踏まえたレビューができます。 CIの流れは次のようなイメージです。 jobs: test: ...(省略)... lint: ...(省略)... typecheck: ...(省略)... claude-review-for-dependabot-pr: name: Claude Review for Dependabot PR # `always()`を指定しCIが失敗しても実行 if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' && always() }} # 各CIの結果が欲しいので終了してから実行 needs: [test, lint, typecheck] ...(省略)... steps: - name: Checkout repository uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 - name: Claude Review for Dependabot PR uses: anthropics/claude-code-action@f0c8eb29807907de7f5412d04afceb5e24817127 # v1.0.23 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} github_token: ${{ github.token }} show_full_output: false #デバッグしたいときはshow_full_outputをtrueにして確認 allowed_bots: dependabot claude_args: | --allowedTools "View,GlobTool,GrepTool,BatchTool,Bash(gh auth status),Bash(gh pr view:*),Bash(gh run list:*),Bash(gh pr comment:*),Bash(gh pr review:*),Bash(gh pr diff:*),Bash(gh pr checks:*),Bash(gh run view:*),Bash(gh release view:*),Bash(git log:*),Bash(git status:*),Bash(git diff:*)" --model claude-opus-4-5-20251101 prompt: | （プロンプト例は下記に記載） プロンプト例 ## 命令 CI実行中のDependabotのプルリクエスト #${{ github.event.pull_request.number }} を評価しマージして問題ないか判断してください ## 手順 1. プルリクエストを確認（gh pr view ${{ github.event.pull_request.number }}） 2. package.jsonとpackage-lock.jsonの差分を確認 3. バージョン差分から公式リリースノートとGitHubのリリースを確認しライブラリの変更内容を把握（gh release view） 4. test, lint, typecheckの実行結果を確認（gh pr checks ${{ github.event.pull_request.number }}） 5. test, lint, typecheckが失敗していた場合、ログを確認（gh run view） 6. 既存コードや他ライブラリのバージョンとの整合性を確認 7. 変更内容を評価しフォーマットに沿ってプルリクエストにレビューコメント（日本語）を1件投稿 ## フォーマット ``` # {ライブラリ名} x.x.x -> x.x.x ## 評価結果 ✅ 承認 / ⚠️ 確認が必要 / ❌ 要対応 / etc... ## ライブラリの変更内容 - 変更内容1 - 変更内容2 ## リスク、注意事項 - リスク1 - リスク2 ## 必要な対応 - 対応1 - 対応2 ``` ## 注意事項 - 承認する場合：`gh pr review {プルリクエスト番号} --approve --body "{BODY}"` - 承認しない場合：`gh pr comment {プルリクエスト番号} --body "{BODY}"` - 実行時に足りない権限があった場合はコメント ## 追加確認項目 - Breaking Changesの有無 - セキュリティ脆弱性の修正状況 - 他の依存関係への影響 他のCIジョブの完了を待ってからActionを実行することで、CIが失敗している場合は「なぜ失敗したか」の分析をさせることができます。失敗ログから原因を特定し、次に取るべきアクションをPRコメントとして残すことができます。 対応すべきことがわかれば対応時の工数感がわかりすぐ取り掛かるかタスクとして積んでおくかの判断がしやすいです。 現在のフロー DependabotがPRを作成する lint、test、typecheckのCIジョブが実行される CIジョブ完了後、Claude Code Actionが実行される Claude Code Actionが更新内容の要約、リリースノートの重要ポイント、CI失敗時の原因分析と修正提案をPRコメントとして残す 人間がコメントを確認し、最終判断を行う 問題なければマージする 人間が行う作業は「Claude Code Actionのコメントを確認して最終判断する」ことに集中できるようになりました。 承認時 非承認時 効果 この改善により、Dependabot PR対応にかかる工数が週あたり約30分〜1時間削減されました。 削減される主な内訳としては、リリース内容の確認と対応要否の調査にかかる時間です。 必要な対応が出力されるのですぐ対応するかタスクとして積むかの判断がしやすくなったのは良かったと感じます。 また、レビューの観点がプロンプトで統一されているため、属人性が低下しました。誰が対応しても同じ基準でレビューが行われます。 コンテキストスイッチのコストも低下しました。コンフリクトしたPRは自動でrebaseと再レビューがされるため、自分の切りがいいタイミングでマージするだけで済むようになりました。 注意点 ANTHROPIC_API_KEYはDependabot用のSecretに設定 ANTHROPIC_API_KEY はGitHub ActionsのSecretsだけでなく、Dependabot側のSecretsにも設定する必要があります。Dependabotが作成したPRでは、通常のRepository Secretsにアクセスできないためです。 設定場所は https://github.com/{Org}/{Repo}/settings/secrets/dependabot です。これを忘れると、Dependabot PRでClaude Code Actionが動作しません。 WebFetchの不安定さ 当初、リリースノートの取得にWebFetch機能を使っていましたが、フリーズすることがありました。（2025年11月ごろ） 対策として、外部情報の取得は gh コマンドを使う方針に変更しました。GitHub CLIを使ってリリース情報を取得する方が安定性と再現性が高く、トラブルが減りました。 Claude Code側でWebFetchがフリーズするissueがいくつかあります。 show_full_output を有効化してもログが表示されないため直接的な原因は掴めていませんが、現状では gh コマンドで必要な情報は取得できているので allowedTools から WebFetch は一時的に除外しています。 github.com まとめ Dependabot PR対応を手動運用からDevin、そしてClaude Code Actionへと改善してきた過程を紹介しました。 定期的に発生する作業は自動化すると効果が大きいです。特にDependabot PRのような「PRごとに自動でトリガーされる」タイプのタスクには、GitHub Actionsと連携するClaude Code Actionが適していました。 今後の課題としては、Claude Code ActionがApproveしたPRを自動マージする仕組みの導入を検討しています。現在nxを利用したモノレポで運用しており、ユニットテストやVRTは各アプリで整備できています。ただし、管理画面など一部のアプリではE2Eテストが未整備のため、まだ自動マージには踏み切れていません。E2Eテストを拡充し、自動マージしても安全という確信を持てる体制を整えていきたいと考えています。 上記のように、AIのガードレール整備が重要なのでテスト等をしっかりやっていくことは今後さらに重要になってくると再認識しました。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

この記事は「 ファインディエンジニア #1 Advent Calendar 2025 」の24日目の記事です。 沢山のアドベントカレンダー記事が執筆されていますので、年末のお供に是非読んでみてください。 adventar.org はじめに ソフトウェアエンジニアの 土屋(@shunsock) です。私の所属するデータソリューションチームでは、ファインディ全体のデータ活用を推進するためのデータ基盤を構築しています。 今回、我々はデータ基盤のRDSとBigQueryのテーブル同期システム (EL Pipeline) のリプレースを行い、 DuckDBを本番導入 しました。本稿では、活用に至った経緯と実際に組みこむにあたる課題、および成果を紹介します。 はじめに ファインディにおけるテーブル同期システムの立ち位置 リプレイスの背景 補足 技術選定 Datastream DuckDB Datastream, DuckDB両採用の理由 システム設計 概要 CLIを挟む理由 GitHub Actionsからの起動にした理由 複数のRDSを転送する 開発運用と成果 開発・運用してみた感想 可読性と拡張性が高い とはいえまだまだ新興のソフトウェア まとめ ファインディにおけるテーブル同期システムの立ち位置 ファインディでは、ウェブアプリケーションをAWS上のECSとRDS、データ基盤をGoogle CloudのBigQueryで作成しています。 このような構成を取っているため、AWSのRDSとGoogle CloudのBigQueryを同期してテーブルを最新にする必要があります。 次の図は、Findy Tools事業部における、現在のデータフローの概念図です。AWS上に存在するRDSのデータをBigQueryに転送していることが分かります。 リプレイスの背景 弊社では従来、OSSのEL(Extract Load) ツール  Embulk  をECSに載せて長期間運用していました。弊社で利用しているRDBMSやデータウェアハウスに対応している他、社内に知見を持った方が在籍しているためです。 しかし、近年では、 Embulkのエコシステムのレガシー化や 長期的なメンテナが不足 が課題 となっています。特に、 将来のメンテナンスが不透明な点は、セキュリティインシデントに繋がりかねない ため危惧していました。 また、 Embulkの起動の遅さも課題 にしていました。我々はBigQueryプラグインなどを利用していたため、JVM上でさらにJRuby VMを立ちあげます。このような構成は テーブル同期の遅さに繋がり、ECSの課金額を増やす要因 となっていました。 このように、システムを堅牢にすることと処理スピード向上による料金のコストダウンが今回のプロジェクトの目的でした。 補足 Embulkのメンテナーの方も 「オープンソース・プロジェクトのたたみ方」 というブログ記事で脆弱性について次のように述べています。 おそらくいくつかの攻撃は既に成功していて、私たちのソフトウェア・サプライチェーンには、悪意のあるコードがとっくに入り込んでいる、と認識しておくべきでしょう。 技術選定 Datastream, Spark, その他 ELTツールなど、複数の移行先候補がありました。その中で、データ規模に応じて次の2つから選定することにしました。 Datastream: ニアリアルタイムでの更新が欲しい場合や大規模データの場合 DuckDB: 小規模データの場合 Datastream Datastream は Google Cloudが提供するサーバーレスのCDC (Change Data Capture), Replicationツールです。 CDCは、あるソースのシステムを監視し、そのシステムに対する操作をニアリアルタイムで、ターゲットとなるシステムに反映する仕組みのことです。これによりAWSのRDSに対する変更を即座にBigQueryに反映可能です。 DuckDB DuckDB は高速なアナリティカルデータベースです。s3などのストレージサービスに出力されたログ分析やファイルフォーマットの変換、wasmによるフロントエンドでの活用など広い用途で活用されています。 接続先や出力フォーマットが非常に豊富な他、C++製のマルチスレッドランタイムにより、高速に動作する点が魅力です。 次の写真はDuckDBのPoC時に行なったベンチマークです。小さなテーブルで転送を試したところ、 1.5倍程度の高速でした 。 ソフトウェア名称 平均 標準偏差 最速 最遅 Embulk 253秒 8秒 242秒 261秒 DuckBD 176秒 30秒 137秒 209秒 補足: 実際にパフォーマンステストを行ったときの様子 Datastream, DuckDB両採用の理由 今回のリプレイスでは、コスト最適化を軸に Datastream と DuckDB の2種類のアプローチを使い分ける構成を採用しました。 DatastreamはフルマネージドでサーバーレスなCDCサービスと強力です。一方で、ニアリアルタイム性が不要な小規模データに対しては機能過多となり、費用面でも割高になります。そこで、リアルタイム性を求めない領域では、より軽量でシンプルに扱えるDuckDBを使って同期を行う方針を取りました。 本記事の以降では、上記のうち、DuckDBによってどのようにテーブル同期システムを構築したか、開発運用で見えた知見を説明します。 システム設計 概要 次の画像は我々のDuckDBによるテーブル同期システムの概念図です。 次のように各種ソフトウェアが起動します。 GitHub Actionsの on_schedule でワークフローが起動 ワークフローがECS Fartate Taskを起動 Fargate Taskがコンテナランタイムを起動 コンテナランタイムの中でCLIアプリケーションが起動 CLIアプリケーションが引数と設定ファイルからSQLを生成 CLIアプリケーションがDuckDBでSQLを実行 CLIを挟む理由 DuckDBを直接起動しない理由は、1回の実行で1テーブルずつ送信できるようにするためと、SQLを直接書かずに設定ファイルをインターフェースにするためです。 実際のユーザーの入力インターフェースは次のようなYAMLです。 dataset_id : lake... table_name : table_name select_statement : "hoge, fuga, ..." GitHub Actionsからの起動にした理由 元々のワークフローはEventBridge Schedulerだったのですが、システム障害時にEventBridgeのcronを変更するなど運用負荷が重い状態でした。 DispatcherをGitHub Actionsにすることでボタン操作だけで検証可能にしました。 また、1テーブルずつの送信にしたので、ステージング環境での動作検証も簡単かつ軽量です。ユーザーは次のようなWorkflow Dispatchを起動するだけで動作検証が完了します。 複数のRDSを転送する 現在のFindy Tools事業部のワークフローを見ると分かる通り、複数のRDSを転送する必要がありました。そこで開発用スクリプトを汎用化して動的なビルドやawsコマンドの発火をしています。 開発運用と成果 開発は、私1人で1か月弱でしました。最初の1プロジェクトこそ時間がかかったものの、モノレポ構成にしたおかげで 従来1か月かかった新規データソースの追加が1週間程度になりました。 処理速度については、直列稼動から並列稼動へ変更となったため単純な比較は難しいのですが、 1テーブルあたり約30秒から約10秒に短縮 できました。 すでに他のメンバーからもプルリクエストが届いており、社内でも手応えのある反応を得ています。 開発・運用してみた感想 可読性と拡張性が高い 今回作成したCLIでは次のようなSQLを生成しています。高い拡張性や可読性が良いと改めて感じました。 INSTALL mysql; LOAD mysql; ATTACH '' AS mysqldb ( TYPE mysql); -- 環境変数から取ってくる CREATE TABLE users AS SELECT * FROM mysqldb.table_name; INSTALL bigquery FROM community; LOAD bigquery; ATTACH '' as bq ( TYPE bigquery); DROP TABLE IF EXISTS bq.lake__system_name.table_name; CREATE TABLE bq.lake__system_name.table_name AS SELECT * FROM table_name; DROP TABLE table_name; 拡張についても、次のCore Extensionsの他にCommunity Extensionsがあります。DB以外にもSpreadSheetなど幅広いツールが対応しているので、興味を持った方は確認してみると良いと思います。 duckdb.org とはいえまだまだ新興のソフトウェア DuckDBは新興のソフトウェアということもあり、普通にバグがあったりします。例えば次のIssueは、私がDuckDBのMySQLのプラグインのATTACH句に存在したバグを報告したものです。(既に解決済みです) github.com また、拡張によっては、サポートしているOSが限られていることがあります。私が作成した時期では、BigQuery拡張でarm64 linuxがサポートされておらず、Fargateをamd64で立てていました。なお、こちらも現在は対応しているようです。 github.com まとめ 今回の取り組みで、我々の テーブル同期システムはより高速、堅牢になりました。 さらに、ユーザーインターフェースが洗練され、 チームメンバーの利用しやすいソフトウェアとなりました。 データソリューションチームでは一緒に事業部横断データ基盤を作る仲間を募集しています。気になる方は是非次のフォームからカジュアル面談に応募してみてください!! herp.careers

こんにちは。 ファインディ株式会社でFindy AI+の開発をしているdanです。 今回は、プロンプトにどのようなデータや指示内容を与えるとLLMが誤った出力をしやすいのかについてお話しします。 プロンプトには何を書くべきで、何を書かないべきなのか。また、LLMに渡すデータはどのような形であるべきなのか。私自身が経験した実際の例をあげて解消までのアプローチ方法をご紹介します。 分析の精度をあげるにはここで紹介する内容では不十分ですが、入門編として参考になれば幸いです。 この記事はファインディエンジニア #3 Advent Calendar 2025 23日目の記事です。今月から、たくさんのアドベントカレンダー記事が執筆される予定ですので、ぜひ読んでみてください。 adventar.org Findy AI+とは 誤解していたプロンプト調整 良くない手法1: システムプロンプトにUTCから日本時間に変換する指示を与える 良くない手法2: 分析に使用するデータを加工する指示をシステムプロンプトに与える あるべき手法 システムプロンプトはどのような振る舞いで分析をしてほしいのかを書く 分析に使用するデータを加工してからLLMに渡す おわりに Findy AI+とは Findy AI+ は、GitHub連携やプロンプト指示を通じて生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。 人と生成AIの協働を後押しし、開発組織の変革をサポートします。 Claude Code、GitHub Copilot、Codex、Devinなど様々なAIツールの利活用を横断的に分析しており、分析基盤にはLangChainを採用しています。また、日報やチーム分析などの機能でもLLMを活用しています。 こうした特性から、Findy AI+ では「何をどう分析するか」を定義するためのプロンプトが、サービスの価値を左右する重要な要素となります。 誤解していたプロンプト調整 良くない手法1: システムプロンプトにUTCから日本時間に変換する指示を与える 初期のシステムプロンプトは次の通りです。 # System Prompt ## Overview You are expert of developer experience and developer productivity. Your Timezone is Asia/Tokyo (UTC+9). Your Language is Japanese. The Timezone for the creation datetime of the Pull request is UTC. 上記はすごくシンプルなシステムプロンプトです。 このコードでは次のことを書いています。 LLMがどのような役割を担うのか タイムゾーンはどこを使用するのか どの言語で出力するのか プルリクエストの作成日時がUTCであること このシステムプロンプトを使用してプロダクトから分析ツールを実行すると次のような出力結果になりました。 システムプロンプトには使用してほしいタイムゾーンがUTC+9(日本時間)であることと、LLM分析に使用するデータはUTCであることを明記しています。 その結果、LLMは分析中に与えられたUTCのデータをJSTに変換する推論処理を行う必要があり、意図しない日付のズレが発生しました。 良くない手法2: 分析に使用するデータを加工する指示をシステムプロンプトに与える ユーザーからの自由入力による追加分析を行うと実際とは異なる日時が分析結果として返ってきました。 そのため次のようにシステムプロンプトを調整しました。 # System Prompt ## Overview You are expert of developer experience and developer productivity. ## Current Date Today's date is {current _ date} (YYYY-MM-DD format in UTC timezone). When you see dates in the data provided, interpret them according to this current date. For example, if today is 2025-10-08 and the data shows "2025-10-06 to 2025-10-12", this is the current week, not a future or past week. Your Timezone is Asia/Tokyo (UTC+9). Your Language is Japanese. The Timezone for the creation datetime of the Pull request is UTC. このコードでは次のことを書いています。 LLMがどのような役割を担うのか 現在日時の明記 現在日時は明記されたものを使用し過去を参照しないこと タイムゾーンはどこを使用するのか どの言語で出力するのか プルリクエストの作成日時がUTCであること このシステムプロンプトを使用してPRの分析を行った後、「日曜日に稼働したりしてないよね？」と追加で質問しました。LLMはGitの活動ログから曜日を判定して回答しますが、次のような出力結果になりました。 実際の曜日とLLMが出力した曜日を比較すると、2025年11月17日は月曜日ですが日曜日で出力されてしまっていることが分かります。 システムプロンプトに現在日時の明記と過去を参照しない旨を明記しています。 また期間指定の範囲についても具体的に指示しています。 その結果LLMは現実と過去について言及されている部分で混乱し、誤った推論による出力ミスが起きてしまいました。 あるべき手法 システムプロンプトはどのような振る舞いで分析をしてほしいのかを書く システムプロンプトにデータの加工、時間変換など処理の具体的な内容を書いてしまうと上記で紹介したような誤った推論を誘発してしまう可能性が高いです。 そのため、役割・言語・フォーマットなどシンプルな内容で最低限のみ書くのが良いです。 最終的には次のようなシンプルなシステムプロンプトになりました。 # System Prompt ## Overview You are expert of developer experience and developer productivity. ## Current DateTime Current datetime is {current _ datetime _ jst} ## Important Rules - When data includes weekday information (e.g., "月曜日", "火曜日"), use it as-is. Do NOT recalculate weekdays yourself. Your Language is Japanese. このコードでは次のことを書いています。 LLMがどのような役割を担うのか 現在日時は変換済みのJSTで渡す 渡されたデータをそのまま使うよう指示する どの言語で出力するのか 分析に使用するデータを加工してからLLMに渡す 分析に使用するデータは、システムプロンプトへ渡す前に加工済みのものを用意した方が良いです。 システムプロンプトにUTCからUTC+9(日本時間)の変換をするように書くべきではありません。 LLMに渡すデータは変換済みのデータにしておきましょう。 例えば、PRのデータをLLMに渡す場合を見てみましょう。 GitHubのPR情報をAPIから取得する場合、日時に関するレスポンスはUTCで返ってきます。 次の手順で、LLMに渡すデータを変換し分析を行います。 ・GitHubのAPIから取得したPR作成日時をUTCからUTC+9(日本時間)に変換する def format_datetime_jst (pr_utc_datetime: str ) -> str : # UTCの日時文字列をJSTに変換 utc_dt = datetime.fromisoformat(pr_utc_datetime.replace( "Z" , "+00:00" )) jst_dt = utc_dt.astimezone(JST) # 曜日も付与してフォーマット weekday_jp = WEEKDAYS_JP[jst_dt.weekday()] return jst_dt.strftime(f "%Y/%m/%d ({weekday_jp}) %H:%M:%S UTC+9" ) # 実行例 format_datetime_jst( "2025-11-17T08:53:32Z" ) # => "2025/11/17 (月曜日) 17:53:32 UTC+9" ・変換したデータを分析コンテンツに格納する analysis_content = f """ # Pull Request Analysis - PR1 Created: {format_datetime_jst(pr1.get("created_at", ""))} - PR2 Created: {format_datetime_jst(pr2.get("created_at", ""))} - PR3 Created: {format_datetime_jst(pr3.get("created_at", ""))} """ ・分析コンテンツを使用してLLMに分析を依頼する llm.invoke([ # 「システムプロンプトはどのような振る舞いで分析をしてほしいのかを書く」で紹介したシステムプロンプト { "role" : "system" , "content" : system_prompt}, { "role" : "user" , "content" : analysis_content} ]) このように変換済みのデータをLLMに渡すことで、LLMが日時の計算や曜日の判定を行う必要がなくなり、誤った出力を防ぐことができます。 おわりに 今回は、LLMにデータ加工や時間変換を任せると誤った推論を誘発しやすいことをご紹介しました。システムプロンプトには役割や出力形式などシンプルな指示のみを書き、データはあらかじめ加工してから渡すことで、分析精度を向上させることができます。 プロンプトの書き方ひとつでLLMの出力は大きく変わります。この記事が、皆さんのLLM活用の参考になれば幸いです。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご応募ください。 herp.careers

こんにちは。 2025 年 9 月にファインディに入社し、 Platform 開発チームで SRE を担当している富田( @Cooking_ENG )です。 この記事は、 ファインディエンジニア #2 Advent Calendar 2025 の 23 日目の記事になります。 adventar.org 今回は、ファインディのサービスの１つである「 Findy Conference 」の インフラ環境の運用トイル を改善した話を紹介します。 Findy Conference とは Findy Conference とは、テックカンファレンスに特化したプラットフォームサービスです。 国内外のカンファレンスに関する情報・体験を一元化し、主催者・参加者・スポンサーをつなぐことで、テックカンファレンスの体験を最大化することを目指します。 参加者は関心のあるイベント情報や CFP（発表募集）、イベントのタイムテーブルを見逃さずに把握でき、主催者は集客や受付管理、データ活用といった運営にかかるコスト・工数を最小化できるようになります。 conference.findy-code.io Findy Conference のトラフィックの特徴 Findy Conference のトラフィックには、一般的な Web サービスとは異なる、カンファレンス特有の 瞬間的なスパイク が多く発生するという特徴があります。 特にスパイクが起こりやすいタイミングは次の 2 点でした。 受付が始まったタイミング セッションの始まりと終わりのタイミング このうち、特に負荷が高かったのが セッションの始まりと終わりのタイミング です。 原因は次のような、 オンライン配信におけるカンファレンス参加者の方々の動き によって起こるものでした。 セッション中は参加者の方々は配信セッションを視聴しているため、Findy Conference のポータルサイトなどにアクセスすることは少ない。 セッションが終了するタイミングで、次のセッションの配信場所やチャンネル切り替えを行うため、セッションを視聴していた方々が一斉に Findy Conference のポータルサイトにアクセス。 その結果、一気にアクセスが集中し、スパイクが発生！ この一連の流れにより、インフラに瞬間的な高負荷がかかっていました。 オートスケールが発動しない Findy Conference の環境は Amazon ECS と AWS Fargate (以降 ECS/Fargate) を使って構築しています。 ECS/Fargate であれば、オートスケールが発動するのではないか？という疑問を持つ方もいらっしゃると思います。実際に、Findy Conference の環境でも、CPU 使用率が設定している閾値を超えたらオートスケールが発動するように設定していました。 しかし、実際の運用では CPU 使用率が設定している閾値を超えてもオートスケールが発動せず、高負荷時にユーザー体験を維持できないリスクが生じていました。 オートスケールが発動しなかった原因は「アクセス集中が瞬間的すぎる」という点にありました。 短時間の高トラフィック・スパイクにより、オートスケールが発動に必要な時間を満たせず、新しいコンテナが立ち上がる前に CPU 使用率が下がってしまう Fargate の起動が少し遅いという特性も影響 結果として、カンファレンス中に上記のような瞬間的な高負荷がかかっても、 コンテナ数はスケールせず終わってしまう という状況でした。 （参考までに、こちらは過去のオブザーバビリティカンファレンスでの CPU グラフです。同時刻にオートスケールが発動していないことがわかります。） これまでのカンファレンス開催時の SRE の対応 上記の問題を回避するため、以前は「カンファレンス開催前に、Platform 開発チーム SRE メンバー(以降、SRE チーム)が AWS の Production 環境に入り、手動でコンテナ数を増やし、カンファレンス終了後にコンテナ数を元に戻す」という対応をしていました。 スパイク時の対策としては、当時はコンテナ台数を増やす以外に現実的な選択肢がなく、人手によるスケール対応に頼らざるを得ない状況でした。 この手動オペレーションは、次のようなトイルを生み出していました。 カンファレンス運営の方との連携が必須： カンファレンスが開催される日程共有の段階でコミュニケーションミスが発生した場合、急いで対応する必要がある。 ペアオペ作業のため 2 人分の工数が発生する： Production 環境で作業をするセンシティブな作業のため、ペアオペが必須となり、2 人分の時間が取られる。 複数環境の調整： フロントエンドとバックエンドなど、複数の環境で調整が必要なため、作業量、作業時間が多くなる。 オペレーション・リスク： そもそも Production 環境を手作業で触るので、作業ミスが発生するリスクがある。 実際、最近開催されたアーキテクチャカンファレンスでは、関連する複数環境のコンテナ調整に 2 時間近く要してしまいました。 カンファレンスが開催されるたびに、この手動作業の負荷が大きいと考え、トイルを抜本的に改善する必要があると判断しました。 GitHub Actions の workflow と AWS CLI で自動化 このトイルを撲滅すべく SRE 以外でも素早くコンテナ調整をできるようにするために、今回は AWS CLI と GitHub Actions の workflow_dispatch を組み合わせて、Production のマネジメントコンソールに入らなくても GitHub 上からコンテナ数を調整できるようにしました。 これにより、必要な権限を持ったユーザーが、安全かつ簡単にコンテナ調整を行えるようになりました。 コードの全体像 以下が、コンテナ数をスケールさせるための GitHub Actions のワークフロー全体像です。 scale-containers.yml name : Scale Containers run-name : Conference Scale Containers to ${{ github.event.inputs.container_count }} in ${{ github.event.inputs.environment }} on : workflow_dispatch : inputs : environment : type : environment required : true default : staging container_count : description : "containers_count" type : choice required : true options : - xx - yy - zz permissions : id-token : write contents : read jobs : scale-containers : runs-on : ubuntu-slim environment : ${{ github.event.inputs.environment }} steps : - uses : actions/checkout@v5 with : fetch-depth : 0 token : ${{ secrets.GITHUB_TOKEN }} - name : Configure AWS credentials uses : aws-actions/configure-aws-credentials@v5 with : role-to-assume : ${{ secrets.AWS_ROLE_ARN }} aws-region : ap-northeast-1 - name : Scale Backend ECS containers run : | CLUSTER_NAME="backend-${{ github.event.inputs.environment }} " SERVICE_NAME=" backend-${{ github.event.inputs.environment }} " echo "🔄 Scaling Backend containers to ${{ github.event.inputs.container_count }}" # 1. ECSサービスのDesired Countを更新 aws ecs update-service \ --cluster "$CLUSTER_NAME" \ --service "$SERVICE_NAME" \ --desired-count ${{ github.event.inputs.container_count }} # 2. オートスケールの最小キャパシティもワークフローでの設定値に合わせる aws application-autoscaling register-scalable-target \ --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id "service/$CLUSTER_NAME/$SERVICE_NAME" \ --min-capacity ${{ github.event.inputs.container_count }} \ --max-capacity [ xx ] echo "✅ Backend containers scaled successfully" - name : Scale Frontend ECS containers run : | CLUSTER_NAME="frontend-${{ github.event.inputs.environment }} " SERVICE_NAME=" frontend-${{ github.event.inputs.environment }} " echo "🔄 Scaling Frontend containers to ${{ github.event.inputs.container_count }}" aws ecs update-service \ --cluster "$CLUSTER_NAME" \ --service "$SERVICE_NAME" \ --desired-count ${{ github.event.inputs.container_count }} aws application-autoscaling register-scalable-target \ --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id "service/$CLUSTER_NAME/$SERVICE_NAME" \ --min-capacity ${{ github.event.inputs.container_count }} \ --max-capacity [ xx ] echo "✅ Frontend containers scaled successfully" ※実際のワークフローの画面です。 ワークフローの実装ポイント workflow_dispatch による手動実行 inputs で environment（環境名）と container_count（コンテナ数）を入力値として受け付けます。 container_count は choice にすることで、設定可能な値に制限を設け、誤入力を防いでいます。 コンテナ数と同時に最小コンテナ数の設定値も合わせる aws application-autoscaling register-scalable-target を実行し、オートスケールの --min-capacity もワークフローでの設定値に合わせるようにしています。この設定はコンテナ数を増やしても、オートスケールが最小キャパシティまでコンテナ数を減らしてしまう可能性を防ぐためです。 本ワークフローの導入により、Findy Conference のコンテナ調整は、誰でも GitHub Actions の画面から数クリックで実行できるようになり、SRE チームの負荷が軽減されました。また、既にカンファレンス開催に関わる複数の環境全てに横展開を完了しています。 この改善によって、SRE チームが約 2 時間かけて行っていたペアオペ作業は解消されました。 加えて、手動オペレーションのリスクも排除され、 必要な権限を持った開発者やカンファレンス担当者が安全にコンテナ調整を行える運用体制 を整えることができました。 おわりに 今回は Findy Conference のスパイクの起こりやすいトラフィック課題に対して、GitHub Actions と AWS CLI を用いて運用オペレーションを自動化・トイル削減した事例をご紹介しました。 トイル削減は SRE の永遠のテーマですが、エンジニアが気持ちよく開発に取り組める環境づくりや、安心して運用できる体制に繋がるため、これからも積極的に進めていきたいと思います。 最後までお読みいただきありがとうございました！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディのTeam+開発部でエンジニアをしている古田（ryu-furuta）です。 この記事は、 ファインディエンジニア #2 Advent Calendar 2025 の22日目の記事です。 はじめに 2025年下期、私は「DevとOpsを融合する」というミッションを掲げ、問い合わせやアラートといった運用業務の改善にAIをいくつか活用していきました。 この記事では、Claude Code GitHub ActionsやNotion MCPを使った運用業務改善の具体的な実装方法を紹介します。 また、効率化を実現した先に見えてきた「次にやるべきこと」についても共有します。 AIを活用した運用改善を検討している方や、改善施策を打っても成果が出ないと悩んでいる方に読んでいただけると幸いです。 はじめに 問い合わせやアラートに生じていた課題 Claude Code GitHub Actionsでアラートの初期調査コストを削減 Notionのデータベースで問い合わせのチケット管理とデータ蓄積 Notion MCPを使って過去事例の検索と自動調査 取り組みの成果 今後の取り組み：根本原因の特定と改善の仕組みづくり まとめ 問い合わせやアラートに生じていた課題 私が携わる 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

この記事は、 ファインディエンジニア #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つの施設に分散 シャトルバスとモノレールで会場間を移動 多数あるセッションカテゴリ 会場の様子 フリードリンクと軽食 Meal会場でのビュッフェ 厳重なセキュリティチェック EXPO会場 SWAG SPORTS FORUM セッション以外のサブイベント 5K Fun Run re:Play おわりに re:Inventの規模感 - ラスベガスの街が会場に 会場は6つの施設に分散 re:Inventの会場は次の6つに分散しており、それぞれが巨大な施設です。 Encore Wynn The Venetian (メイン会場) Caesars Forum MGM Grand 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

この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の21日目の記事です。 adventar.org はじめに こんにちは、ファインディのPlatform開発チームでSREを担当している原（ こうじゅん ）です。 2025年12月、ラスベガスで開催されたAWS re:Inventに参加してきました。re:InventはAWSが毎年開催する世界最大級のクラウドカンファレンスです。 今年は特にAI Agentを中心とした大きな変化を感じるイベントとなりました。 本記事では、私の体験したセッションを通じて見えてきたインフラ・運用の変化について、AIOps領域に焦点を当てて振り返りを書いていこうと思います。 会場の様子やセッション以外のイベントについてはまた別記事で書いていきます。 はじめに re:Invent 2025 今年の主要テーマの1つであるFrontier Agents AWS DevOps Agentとは ワークショップでの体験 その他の運用・インフラ領域で参考になるセッション Observability × AI 運用の文化とプラクティス インフラ基盤の進化 IAMポリシーの深掘り エンジニアに求められる姿勢 おわりに 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がグローバル規模で運用をどのように行っているのかが解説されました。 特に印象的だったのは、次のサイクルを継続的に回している点です。 Readiness : 障害が起きる前の状態づくり（アラーム、ダッシュボード、Runbook、オンコール体制の整備） Observability : ログ・メトリクス・トレースでの計測、SLOドリブンなモニタリング Incident Response : SOP（標準作業手順書）に従った対応、AIOpsによる障害分析 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

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 現在のソフトウェア開発の世界は、生成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とは Findy AI+ アルファ版: リモートMCPサーバーでの提供 ベータ版: チャットUIとMCP活用のAdmin機能 まとめ 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

こんにちは。 Findy Freelanceの開発チームでEMをしている中坪です。 この記事は、 ファインディエンジニア Advent Calendar 2025 の18日目の記事になります。 adventar.org 日々進化するAIや関連ツールをキャッチアップし、実務に活用することに苦労しているエンジニアの方も多いのではないでしょうか。 私たちは、チームでAIツールのキャッチアップを行う取り組みとして「10分勉強会」を実施しています。 本記事では、その取り組み内容について紹介します。 10分勉強会とは 発表内容の例 1. Sentry MCPとLog Analyzer with MCPを使った不具合調査 2. Gemini Canvasを使ったUIモックの作成と社内共有 3. Git Worktree Runnerの紹介 持続するための工夫 発表のスキップを許容する 発表資料は任意 厳密ではないテーマ設定 チーム内で開催する 開催時間を短くする 効果と反響 チームメンバーの声 チームAI活用率 メリット アウトプットによる知識の定着 AIのキャッチアップをチームで取り組める 聞いた内容をすぐに試せる デメリット 余談と「うちのAIがやらかしまして」の紹介 おわりに 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

はじめに みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（ @adachin0817 ）です。この記事は、 ファインディエンジニア Advent Calendar 2025 の18日目の記事です。今回はECS Express Modeをスピーディーに試してみたので、使ってみて分かったメリット・デメリットを中心にまとめていきたいと思います。 adventar.org はじめに ECS Express Modeとは Terraform terraform.tf iam.tf ecs.tf variables.tf Deploy 削除の挙動と懸念点について まとめ 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

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の17日目の記事です。 adventar.org 現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。 GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。 そんな中で先日、Claude Codeの新機能であるPluginsが公開されました。 そこで今回は、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

こんにちは、CTO室データソリューションチームでマネージャーをしている 開（hiracky16） です。 この記事は、 ファインディエンジニア #1 Advent Calendar 2025 の14日目の記事です。 adventar.org 先日、チームで半日ほど時間をとってワークショップ（オフサイトミーティング）を実施しました。今回は、そのプロセスの中で「生成AI（Gemini）をファシリテーター兼、壁打ち役として参加させる」という試みを行った話と、そこで決まった私たちの新しいミッション・ビジョンについて書きたいと思います。 データソリューションチームについて紹介 我々のチーム、データソリューションチームについて少し紹介すると現在は職能で言うとデータエンジニアのみが所属するチームで、現チーム体制になって約1年半が経過しました。横断組織でもあるため特定の事業の仕事に取り組むのではなく全事業のデータ活用に関する依頼に対応しながらデータ基盤を作っています。もともとはデータサイエンティストと一緒のチームでしたが、組織変更を経て、データサイエンティストやデータアナリストは事業部の方に所属となり今の形となりました。ファインディのエンジニアチームの構成は次のような形です。 ワークショップ開催の経緯 日々の業務としては、各部署のデータアナリストやサイエンティストの支援をしたり、データ活用の悩みを解決したり、全社横断の検索エージェント基盤を作ったり様々です。しかし、1年半走ってくる中で、マネージャーである私自身の中に、ある種の「モヤモヤ」が溜まっていました。 優先順位の悩ましさ ファインディでは4事業を展開している中で、事業ごとにデータ関連の仕事の相談を受けます。横断組織として複数の事業に関わる一方で、限られた人数の中で取り組むテーマに優先順位をつけながら進めています。さらに新規事業やプロダクトも控えており、今後は関わる事業やプロダクト、仕事の幅が広がる中で、より丁寧な判断が求められる場面も増えていくと考えています。 「具体的な」データ・AI戦略の言語化 優先順位に迷いながらでも現場は回っている状況ではある中で、中長期的な指針がより明確になることで、チームが同じ目的をこれまで以上に共有しやすくなると考えています。また普段は単一の事業やチームに最適な取り組みをするとよいことが多いですが、「ファインディとして」どうあるべきか？という全社視点をあらためて意識することの重要性も感じています。 データエンジニアの役割変化 生成AIの台頭により、これまでの「基盤を作って終わり」というスタイルに加えて、よりビジネス価値に踏み込んだ関わり方が求められるようになってきました。ファインディ主催のカンファレンス 「Data Engineering Summit 2025」 でも他社の事例を見聞きする中で、データエンジニアやデータ基盤の役割が変わりつつあることを改めて実感しました。自分がモデレーターを務めた「サイロ化解消のその先へ。ビジネス/データ、それぞれの視点で語るRevOps」というセッションでも、RevOpsという領域におけるデータエンジニアの新しい役割やキャリアについて話すことができました。 そんな危機感を感じ、チーム全員で一度立ち止まり、自分たちのミッションやビジョンを見直すタイミングだと思いました。ただ、私ひとりが悩んで決めたトップダウンの指針では十分ではありません。メンバー全員が腹落ちし、意欲的に働くための指針を作ること──それが今回のワークショップの目的でした。 準備 ワークショップを企画するにあたり、今回はGeminiを活用しました。 私自身過去ワークショップに参加したことはありましたが、主催するのは初めてです。準備や進行の面でうまくできるか不安がありました。また当時、課題感は言語化できていない曖昧な状態でした。 そこで、今回は次のようなフローで準備を進めました。 音声入力でひたすら喋る：現状の課題、チームの歴史、私の悩みなどを、脈絡なく音声入力でテキスト化 Geminiに投げ込む：その長文テキストをGeminiに渡し、「これらのコンテキストを踏まえて、半日のワークショップのアジェンダと、各パートの狙いを設計して」と依頼 壁打ちしてブラッシュアップ：Geminiから返ってきた案に対し、「ここはもっと発散させたい」「ここは収束させたい」と対話し、スライドの骨子を作成 結果、課題の言語化にも成功しましたし、ワークショップの準備も比較的時間をかけずに終えられたと思います。 実施 当日は、会議室を半日貸し切って付箋を使いながらワークを行いました。 1. 情報のインプット 役職や社歴に問わず文脈を共有した上でワークに入れるように情報のインプットパートを設けました。まずは開催に至った経緯を丁寧にメンバーに説明し、私が抱いた悩みをメンバーも感じているのかの確認やメンバー間で違和感や課題感を揃えるところから始めました。また入社時期もバラバラで、直近だと3ヶ月前に入社したメンバーもいたのでチームの成り立ちから現状に至るまでの歴史を振り返りました。次に会社や部署の指針やミッションをスライドに記述することで会社から求められていることを意識して話し合いできるようにしました。 「生成AIの進化によるデータエンジニアやデータ基盤に求められる役割」をDeep Researchでまとめてもらい、それらを斜め読みする時間も設けました。社内の仕事だけしていると個社最適なスキルになりがちなので、世の中一般的なデータエンジニアリングのスキルと比較しながら議論しました。以下Deep Researchの結果を簡単にまとめてもらったものです。 2. 存在意義のワーク：「もし自分たちが1年いなかったら？」 まず取り組んだのが、「もし私たちのチームが存在しなくて、過去1年間不在だったら会社はどうなるか？」という思考実験です。 「データ連携が止まって、数字がズレる」や「誰もデータ基盤のメンテナンスをしなくなって、コストが爆増やセキュリティへの対応が遅れる」といったリアルな痛みから、「ツールが統一できずに情報やノウハウが分断される」といった機会損失まで様々なことが考えられました。このワークを通して我々のチームが会社や他のチームから求められていること、つまりミッションを考える上での重要な要素を洗い出すことができました。 3. Will/Can/Mustでビジョンを描く 次に、3年後の未来像を「Will/Can/Must」のフレームワークで言語化しました。メンバー個々人のキャリア上のWillと会社のビジョンである「挑戦するエンジニアのプラットフォームをつくる。」とが重なる部分を見出してチームのビジョンにしたいと思いこのワークを実施しました。 以下私が書いたことを例です。 - Can（できること） - データエンジニアリングと Google Cloud チョットデキル - 採用活動 - Must（すべきこと） - A事業部のデータ基盤開発、運用 - マネージャーとしての調整業務 - Will（やりたいこと） - 全社のデータ活用を伴走し売上に貢献できるデータエンジニアになる 他のメンバーにも同じように書いてもらい、まずはメンバー間で一緒にできそうなことはないか探りました。そうすると「価値のあるデータ」や「売上に貢献できる」というエッセンスが得られました。 4. ミッション・ビジョンを考える 最終的に決まったミッションとバリューがこちらです。 Mission: 「データとエンジニアリングの力で、ファインディの知恵を結集し、意思決定を加速させる」 Vision: 「事業成長に並走できるデータxAI基盤を作る」 1~3のステップで得られた意見を元にチームでミッション・ビジョンを考えました。内容をGoogleスライドに書き込みながら進めていたためGeminiにそのまま添付し、ミッション・ビジョンの案を3つずつ考えてもらいました。あらかじめ4つの基準を考えており、「情熱が持てるか？」「会社のミッションと関連性はあるか？」「他のチームと比べてオリジナリティがあるか？」「シンプルで覚えやすいか？」をメンバーの主観で点数化しながら最終的に1つに決めました。 最後に言葉選びを我々のチームやファインディっぽく変更しました。例えば、会社のバリューに関連するワード「加速（スピード）」や「並走（チームワーク）」を使いました。「集結させる」のか「結集させる」のかで悩んだ際に「結集」には「力を合わせる」という意味合いがあるらしく採用しました。 振り返りとこれからの話 ワークショップを通じて、認識が揃ったことはもちろんですが、Geminiを議論に混ぜることで、より客観的にミッションやバリューを作る上で機能したことの気づきがありました。ある程度コンテキストを与えていたところはありますが、Geminiはより深い事情を知っているチームメンバーよりもいい意味で違った視点の意見を出してくれることが多かったです。またDeep Researchの結果を使って現代のデータエンジニア像をインプットできたのは客観的な視点で情報をまとめてくれたおかげです。 もちろん、Geminiは優秀な壁打ち相手でしたが、AIに頼り切るだけでは「メンバー全員が腹落ちし、意欲的に働くための指針を作る」という部分は達成できなかったように思います。最後に自分たちの手で細かい微調整をし、想いを込めていくプロセスこそが、今回のワークショップで必要だった作業だとわかりました。結果として、会社から求められていること（Mission）と、チームが成し遂げたいこと（Vision）が繋がり、「自分たちの言葉で決めた」という強い納得感のある指針が生まれました。 私たちデータソリューションチームはこの新しいミッション・ビジョンのもと、生成AI時代の新しいデータ基盤づくりに挑戦していきます。ファインディやデータソリューションチームのミッションに共感し、一緒にビジョンを叶えたい方、や我々チームの取り組みに興味を持ってくださった方はぜひ一度カジュアル面談でお話ししましょう！ herp.careers

こんにちは、ファインディでソフトウェアエンジニアをしている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つです。 並列マシンへのテスト割当をファイルサイズベースから実行時間ベースに変更（60秒短縮） テストファイルごとの実行時間の偏りが大きかったので平準化 不要なジョブを削除（27秒短縮） 影響のないジョブがクリティカルパスに存在していたので削除 aptでインストールしているライブラリのキャッシュ（25秒短縮） 毎回インストールして30秒ぐらいかかっていたのをキャッシュすることで2-3秒に短縮 テスト用の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

はじめに こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（ TENTEN11055 ）です。 この記事は、 ファインディエンジニア Advent Calendar 2025 の11日目の記事です。 今年11月、AWS が主催する AI-DLC Unicorn Gym に参加しました。 AWS主催 Unicorn Gym 最終日の成果プレゼンの様子 このプログラムの開発プロセスはAIと共に歩む仕様駆動開発。 部分的なAI活用から一歩進んだ開発体験を得ることができ、同時に「今後はより読解力が求められる」と感じました。 この記事では読書習慣がなぜスキルになるのか、自分の体験をもとに書いています。 はじめに AI-DLC（AI駆動開発ライフサイクル）とは AI-DLCにおけるレビュー負荷 読書を始めてみた 理解力がある人の特徴 「読む」と「理解」は別 人間が監視する時代、読書がどう活きるか まとめ 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