2025年のFindy SREチームの歩みと成果を振り返る

はじめに

みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（@adachin0817）です。この記事は、ファインディエンジニア Advent Calendar 2025の5日目の記事です。今回は2025年のSREチームの成果や課題などを振り返りたいと思います。

adventar.org

Platform SREチーム ビジョンの再定義

「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」

このビジョンを元に、Platform開発チーム SRE(以下、Platform SRE)チームの方向性を再定義しました。これまでもビジョン自体は存在していたものの、メンバーの役割や責任範囲など曖昧で、チームとしてどう実現していくのかが十分に描き切れていませんでした。そのため、2025年に向けてビジョンをブラッシュアップし、具体的な行動指針へと落とし込みました。

また、ミッションは半期ごとに見直す運用へと変更しました。従来は年間を通して固定したミッションで動いており、課題や状況など大きく変化することが分かりました。そのため、より柔軟な意思決定と、チームメンバーの意志を反映できる仕組みにアップデートしました。

次は、2025年 Platform SRE ロードマップを解説します。

2025年のPlatform SREロードマップ

• AI活用
  • DevinやAI補助による運用・構築の自動化
• Observability
  • SLI/SLOの見直し
  • Datadog RUMの検証
• Cost
  • パフォーマンス予測モデル導入
  • MCPによるコスト最適化
• Security
  • アプリケーション脆弱性対応
  • Takumi導入
  • Shisho Cloud棚卸し
• Infrastructure
  • Team+ 本番DBクローン ワークフロー作成
  • 負荷試験環境
  • ログ基盤の設計
  • WordPressをShifterに移行
  • Terraform汎用モジュールの拡充
  • Findy Team+ マーケットプレイス対応
• CI/CD
  • デプロイの共通化
    • GitHub Actionsのテンプレート化
    • ecspressoの導入
• Automation
  • 社内ツール実装(Go)
  • 新規AWSアカウント作成業務の自動化
• Onboarding
  • 新規ジュニアメンバー教育
• Culture
  • SRE文化醸成

2025年のPlatform SREチームは、開発チームが自律的にSREを実践できる組織を目指し、8つの領域にフォーカスしてロードマップを策定しました。単なる改善タスクではなく、SREを仕組みと文化としてチームに埋め込むことを重視しています。

次は特に注力した取り組みについてまとめていきます。

主に取り組んできたこと

Devinの活用

SREチームでは、新サービスが追加されるたびに、Shisho CloudとAmazon Security LakeをTerraformで連携しています。しかし、この設定手順は非常にシンプルでありながら毎回人手で作業することがトイルとなっていました。

そこで、Devinを活用した自動化に取り組み、Terraform連携を含む一連の作業をワークフロー化しました。さらに、GitHubアカウントの発行、AWSアカウントの作成、WordPressの軽微な修正などもDevin化し、SREのトイルを大きく削減できています。今後は、これらの仕組みを横展開し、より広く標準化していく予定です。

tech.findy.co.jp

Terraform汎用モジュールとtestの拡充

tech.findy.co.jp

今年からは、新サービスをより高速に構築するため、Terraformによる汎用モジュールの整備に本格的に取り組みました。 これまでは既存コードの流用をベースに構築していたため、設定の漏れや環境差異を適切に把握できない状態が続いていました。

その課題に対し、Terraformの汎用モジュール化と Terraform Test の拡充することで、Apply前に失敗や設定ミスを検知できる仕組みを構築しました。これにより、信頼性を担保しながらもスピード感のあるインフラ構築が実現できるようになったと感じています。

Findy Team+ 本番DBクローン ワークフロー化

これまでは、Embedded SREが手動で本番DBのスナップショットを取得し、開発チームがそれを基にバッチテストや検証していました。しかし、テスト環境の構築に時間がかかるだけでなく、実際の運用に近い再現性が担保しづらいという課題がありました。

そこで、2025年からは 本番DBクローンを自動で生成できるワークフローを実装しました。この仕組みにより、バッチ処理を含むパフォーマンステストや検証作業を誰でも再現性高く実施できる環境が整備されました。安全性の確保にも配慮し、クローンDBは本番DBと隔離された環境で動作、アクセス制御を厳格に適用、本番相当のデータでテスト可能という形で、リスクを防ぎつつ、実運用に近いテスト環境を実現しています。

クローンDBの作成および削除は、すべてAWS CLIによるワークフローとして自動化しています。また、バッチのパフォーマンステストについては、Operationコンテナ上でAPIと同等の環境を再現しており、本番に近い条件での検証を行えるようになりました。

Findy Team+ AWSマーケットプレイス対応

aws.amazon.com

Findy Team+では、AWSマーケットプレイスへの掲載準備が本格的に始まりました。これまでの直契約モデルから、AWS経由で利用できるモデルという選択肢が増えます。特にエンタープライズ企業では、調達プロセス・セキュリティ基準・契約形態・監査プロセスなどのハードルが高く、SaaS導入の初動でつまずくケースが少なくありません。その中で、AWSマーケットプレイス経由の契約であれば調達がスムーズになるため、AWS経由で使えることが導入条件になる企業でもTeam+導入の壁がさがることを期待しています。

今回の対応により、Findy Team+はエンタープライズ向けのSaaSとしての提供価値をより明確にしていくフェーズに入ったと考えています。

Takumi SAST/DASTの導入

flatt.tech

Shisho Cloudを運用していく中で、アプリケーション層の脆弱性も同じ仕組みで検知・可視化したいという課題が生まれました。そこで、コード診断に特化した Takumi（SAST / DAST）を全サービスへ導入し、セキュリティ領域の基盤整備を進めました。

SASTによる静的解析ではコードの脆弱性を早期検知できるようになり、DASTによる動的解析では実行可能な攻撃パターンの再現・検証ができるようになりました。その結果、「診断 → 可視化 → 修正 → 再検証」 というサイクルが開発メンバーの中で自然と回り始め、SREチームによる支援型セキュリティの形が実際に機能し始めています。

また、DASTによるブラックボックス診断については、来年のSRE Kaigi 2026でもGMO Flatt Security CTO 米内さんと発表予定です。セッションではAI時代におけるセキュリティ戦略や、その実践的な導入アプローチについて具体的にお話しますので、ぜひご参加いただき、これからのセキュリティの在り方を一緒に考える機会にできれば嬉しいです。

／#srekaigi 協賛します！
＼

GMO Flatt SecurityはSRE Kaigi 2026にダイヤモンドスポンサーとして協賛いたします！

ファインディSRE 安達様 @adachin0817 と弊社CTO 米内 @lmt_swallow によるスポンサーセッションも予定しています！

ぜひお越しください💁🏻‍♂️https://t.co/HvZtuL7rBL

— GMO Flatt Security株式会社 (@flatt_security) 2025年11月12日

2026年に向けた展望と課題

来年はSREチームとして、今年の取り組みを「仕組みを作る段階」から「仕組みを運用し、継続的に改善していく段階」へ移行していく予定です。単にSREの知識を展開するだけではなく、開発チーム自身が自律的にSREの判断・運用ができる状態を、より強く推進し、Enablingしていきたいと考えています。

おわりに

2025年は、SREチームにとって仕組みづくりと文化づくりの両輪で走り続けた1年でした。振り返ってみると、改善することよりも、なぜ改善するのか？どうあるべきなのか？を問い続ける1年だったように感じます。

まだまだロードマップは対応できていないものもたくさんあるのと、来年は今年つくった仕組みを本格運用フェーズへ進めつつ、開発チームが自律的にSREを実践できる組織づくりに挑戦していきます。

明日はjiskanuloさんになります！見ていただきありがとうございました。

なぜデザインシステムをコードで管理するのか

こんにちは、ファインディCTOの佐藤(@ma3tk)です。この記事は、ファインディエンジニア #1 Advent Calendar 2025とファインディデザインチーム Advent Calendar 2025の4日目の記事です。

先日、Findy AI+という新規プロダクトのデザインシステムを1から設計しました。

片手間ながら1人で2〜3週間かけてベースの設計を仕上げた結果、これからのデザインシステムは「コードで管理すること」が不可欠だという思いが強くなりました。

なお、Figmaとコードの関係性の変化やAI時代における開発フローの変化など、関連するテーマは多くありますが、今回は「なぜコードで管理するのか」という背景を中心にお伝えします。

ユーザーと同じ環境でものを見る

デザインツールと実装環境の違い

従来のワークフローでは、Figmaなどのデザインツールでデザインを作り、実装はそれに追従する形でした。Figmaは優れたデザインツールですが、そこで見ている画面と、ユーザーが実際に触るプロダクトは異なる環境です。

デザイナーが意図した色やスペーシングが実装段階で微妙にズレることもあります。また、レスポンシブ対応で想定外の挙動が起きることもあります。デザイン時と実装時での乖離は、デザインツールと実装環境の違いから生まれる課題です。

例えば、ボタンの角丸が場所によって4pxだったり8pxだったり、余白が16pxと20pxで混在したりといった問題です。Figmaでは統一されているように見えても、実装では微妙に異なる値が使われることもあるでしょう。

これは、デザインツールと実装環境という2つの異なる場所で管理しようとすることの難しさです。

プロダクト開発に関わるメンバーが最も注目すべきは、プロトタイピングの画面ではなく、ユーザーが触る実際の画面だと考えます。

コードで管理する最大の価値

「ユーザーと同じ環境で、ものを見ることができる」

これがコード管理における最大の価値だと思います。

コードをマスターにすることで、実装された状態が常に正しい状態となります。

どれだけデザインツールで美しく見えていても、ブラウザで崩れていたら意味がありません。コードをマスターにすることで、デザイナーとエンジニアが「ユーザーが見ているもの」を直接触りながら改善できるようになります。

FigmaプラグインのToken StudioやCode Connectを使えば、コードで定義したトークンをFigmaに反映できます。つまり、Figmaでのデザイン作業は今まで通り行いながら、真実の情報源(Single Source of Truth)はコードに置くことができるのです。

効率化の話だけではなく、ユーザー体験の品質そのものに関わる問題だと捉えられます。

型の力で強制できる

無理やり実装を防ぐ仕組み

Findy AI+の設計で最も意識したのは、「デザインシステムから逸脱できない仕組み」を作ることです。

テーマを作った後、実際にデザインシステムを適用させようとすると、無理やり実装しがちです。css=やstyle=のような直接スタイルを当てる方法を使ってしまうケースです。

一度この逃げ道を許すと、デザインシステムは形骸化します。「急いでいるから今回だけ直接スタイルを当てよう」が積み重なり、気づけば誰も使わないものになってしまいます。

コードだからこそ実現できる強制力

Findy AI+では、Chakra UIをベースにデザインを行っています。Chakra UIのStrict Tokenモードを導入し、ESLintのルールを整えました。さらに、CLAUDE.mdとClaude Skillsでルールを明文化し仕組みを整え、生成AIにもデザインシステムを守らせるようにしました。

すると、エンジニアは必ずデザインシステムで定義されたトークンやコンポーネントを使わざるを得ない状況になります。例えば、直接スタイルを当てようとすると、Lintエラーが出てしまいます。

この強制力があることで、デザインシステムを形骸化させない鍵になると考えています。そして、この仕組みは今後デザインツールでできるようになるかもしれませんが、現在はまだ実現できません。コードで管理するからこそ、型の力で強制できます。

デザインされたものを一からコンポーネントとして実装するには多大な設計が必要です。しかし、Findy AI+では最初からデザインシステムをコードで定義し、逸脱できない仕組みを整えてきました。その結果、開発者が迷わずに実装でき、ルールが統一しつづけられる環境を作りました。

最初から徹底できる

後付けでは浸透しない

デザインシステムの導入で最も難しいのは、浸透させることです。

すでに動いているプロダクトに後からデザインシステムを導入しようとすると、既存のコードとの整合性を取る作業が膨大になります。そして、その移行期間中は「デザインシステムを使っている部分」と「使っていない部分」が混在し、一貫性が失われます。

既存のプロダクトでも徐々にデザインシステムを適用していっていますが、浸透するまでに時間がかかります。デザインとしての一貫性がない状態からのスタートだったり、エンジニアがコンポーネントを置き換える作業が必要だったりと、後付けの導入には多くの障壁があります。

AI時代の開発スピードに対応する

AI時代の開発スピードを考えると、後から統一する時間的余裕はありません。

最初に型を作り、デザインシステムを稼働させながら作ることがAI時代の作り方だと考えています。

Findy AI+では、プロダクト開発の初期段階からデザインシステムをコードとして定義し、そこから逸脱できない仕組みを整えました。この「最初から徹底」を実現するには、コードで管理することが不可欠です。

デザインをコード管理することは必要不可欠

Findy AI+でのデザインシステム設計を通じて、「なぜコードで管理することが不可欠なのか」を改めて実感しました。

ここまでを改めてまとめると、コードで管理すべき理由は大きく3つです。

1. ユーザーと同じ環境でものを見ることができること
2. 型の力で逸脱を防ぐ仕組みが作れること
3. プロダクト開発の初期段階から徹底して効率を上げられること

デザイナーとエンジニアの両者が、デザインシステムの重要性を理解し、そして「コードで管理すること」の価値を理解していただけたら幸いです。

Figma Schemaが示す方向性

ちょうど先日、Figmaが「Schema」というイベントで発表した内容がこの考え方と合致していました。

Figmaの方針として、デザインシステムを「AIが読み取りやすいルールブック」として整備する方向に舵を切っています。Code Connect UIでFigmaコンポーネントとGitHub上のコードを紐付ける機能が発表されました。Figma MCP ServerでAIツールからFigmaデータを参照しやすくする機能も登場しています。VariablesのエクスポートでFigma変数をコードへ持っていきやすくなるなど、「FigmaデータとコードをつなぐAI前提の機能」が続々と出てきています。

この流れは、本記事で述べた「コードで管理する」という考え方を後押ししてくれるものだと感じています。Figmaは引き続き強力なデザインツールとしてプロトタイピングに活用しながら、ユーザーが見る実コードに主眼を置くことが大事だなと改めて思いました。

なお、今回は「Why」を中心にお伝えしましたが、FigmaとCode Connectの連携方法、Token Studioの活用、Storybookでの運用など、具体的な「How」についても今後記事にしていきたいと思います。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味がある方はこちらから ↓

careers.findy.co.jp

TSKaigi Hokuriku 2025 に参加・登壇しました

こんにちは！ファインディのTeam+開発部の大石（@bicstone）、甲斐（@karukan013L23）です。先日、ファインディは2025年11月23日に石川県金沢市で開催された「TSKaigi Hokuriku 2025」に協賛しました。

今回は、Findy Conferenceメンバー、DevRelメンバー、Team+開発エンジニアの6名で参加しました。
本記事ではTSKaigi Hokuriku 2025において印象深かったセッションの紹介や、登壇・ブース出展などの活動内容を紹介します。

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

adventar.org

TSKaigi Hokuriku 2025について

TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。
石川県金沢市のホテル金沢にて、2025年11月23日に開催されました。

hokuriku.tskaigi.org

印象深かったセッション

興味深いセッションが多くありましたが、その中でも特に印象に深かった4つのセッションを紹介します。

TypeScript 6.0で非推奨化されるオプションたち

hokuriku.tskaigi.org

TypeScript 6.0は7.0に向けた準備としての側面が大きいバージョンであり、機能追加というよりメンテナンス性向上のための仕様の整理とパフォーマンス改善に重きを置かれていることについて学びました。
target: es5へのトランスパイルやmoduleResolution: classicなど、非推奨になるオプションを見ると今の開発では使われなくなりつつあるものが多く、現代の環境に合わせた変更となっています。こうして廃止されていくオプションを見ていると、TypeScriptとその周辺環境の移り変わりの歴史を垣間見ることができ面白かったです。

非推奨になるもの以外に、alwaysStrictやtypes、rootDirなどデフォルトの動作が変更になるものがあるため、移行する際は注意が必要です。
非推奨となるオプションが廃止されるTypeScript 6.5までまだ猶予はありますが、徐々に対応を進めていきたいです。

tsc --init の設計思想の変化とその背景を追う - “教育的”アプローチから実用性重視への転換

hokuriku.tskaigi.org 元々tsc --initで生成されるtsconfig.jsonは全てのオプションと大量のコメントが出力されていましたが、これらがどう見直されたかについて学びました。
ES Modulesを推進したいのにCommonJSの設定がデフォルトになっていたり、テキストの壁と表現されるほどの大量のコメントアウトされたオプションが表示されるなどの課題がありました。
新しい方針ではコメントアウトされたオプションを削減し、必要最小限かつ推奨される設定のみを含むシンプルな設定に変更されました。

こちらのIssueでtsc --initのアップデートに関する議論されています。手元で新しいtsconfig.jsonを確認しつつIssueを覗いてみると面白そうです。

アルゴリズムの専門家と挑むフロントエンド実装 − 複雑なロジックを支える設計とパフォーマンス最適化

hokuriku.tskaigi.org

今回初の取り組みであるチーム発表のセッションです。チーム発表は、同じプロジェクト・チームでの取り組みを、異なる立場・役割の2名がそれぞれの視点から語る形式となっていました。本セッションはアルゴリズムの専門家とフロントエンドエンジニアの組み合わせの登壇となっていました。
それぞれの専門性を活かしつつ、共同資産として活用するためのWebAssemblyの採用は興味深かったです。WebAssemblyとJavaScriptのメモリ構造の違いや、ロジックをWebAssemblyとフロントエンドのどちらで実装するかの判断軸など、それぞれの立場からのお話を聞くことができました。

次回以降チーム発表のセッションがあるかは分かりませんが、面白い形式だったので次回以降も枠があると嬉しいです。

Welcome to the “Fantasy Land” 🧚 − 代数的構造をめぐる冒険 −

hokuriku.tskaigi.org

このセッションでは、プログラミングにおける代数的構造とFantasy Landという仕様について紹介されました。代数的構造とは、集合と演算に対してどのようなルールを満たすのか定めるものです。
具体的な例を挙げると、統合律（どの順序で演算しても結果が変わらないという法則）と単位元律（単位元eと演算しても、元の要素aの値が変わらないという法則）を満たすと、モノイドという代数的構造になります。

統合律
a・(b・c) = (a・b)・c

単位元律
a・e = e・a = a

TypeScriptで表現すると、次のような実装になります。

// T: モノイドの要素の型
interface Monoid<T> {
  // 単位元（e）を返すメソッド
  mempty: () => T;
  // 二項演算（•）を行うメソッド
  mappend: (x: T, y: T) => T;
}

// 2. 文字列モノイドの実装 (単位元: ""、演算: +)
const StringMonoid: Monoid<string> = {
  mempty: () => "",
  mappend: (x, y) => x + y,
};

Fantasy Landは、プログラミングで頻出する代数的構造を体系化し、満たすべきルールをまとめた仕様です。TypeScriptのPromise型とResult型を例に共通の構造を探索していき、Fantasy Landで定義されたChainの仕様に抽象化していく過程は、普段とは違った視点でコードの構造を見ることができ面白かったです。

Fantasy Land自体はClassの利用を前提としているためすぐに活用することは難しいですが、より良い構造を探索するために代数的構造を活用するという視点はとても参考になりました。

登壇

ファインディからはCfP枠より大石、スポンサーLT枠より甲斐が登壇しました。それぞれの発表内容を紹介します。

大石: TS 5.9 で使えるようになった import defer でパフォーマンス最適化を実現する

speakerdeck.com

TypeScript 5.9で利用可能となる新機能「import defer」を用いたパフォーマンス最適化について解説しました。

TC39 Stage 3の提案であるこの機能は、モジュールの「取得・解析」を即座に行う一方で、トップレベルの「評価（実行）」を実際にプロパティにアクセスする瞬間まで遅延させるものです。これにより、従来の動的import（dynamic import）のように非同期処理（Promise）を扱う複雑さを避けつつ、同期的な構文のままで初期ロード時のCPUコスト（TBT）を削減できる利点があります。

具体的な活用例として、モーダルのような「ユーザー操作時に初めて必要となる機能」の評価を遅らせるパターンを紹介しました。また、利用にはtsconfig.jsonの設定変更が必要であり、現時点でランタイムやバンドラは実験的な対応にとどまる点にも言及しつつ、2026年に向けた未来のパフォーマンス改善を一緒に考えようと呼びかけました。

甲斐: Nxはいいぞ！ monorepoプロジェクトにおける 差分検知を活用した型チェック最適化

speakerdeck.com

Nxを活用したmonorepoプロジェクトにおけるCI実行時間の最適化について解説しました。「CIの実行時間が長すぎて辛い」という多くの開発者が抱える悩みに対して、Nxを用いた解決策を紹介しています。
Nxは、モノレポやアプリケーションのビルド、テスト実行、コード生成などの機能を備えた統合的なツールです。ファインディの多くのフロントエンドでも採用されています。主な特徴として、タスク実行の並列化、変更検知、キャッシュ活用によるCI実行の効率化があります。

Nxは変更があったプロジェクトと、それに依存関係のあるプロジェクトのみを対象にコマンドを実行します。これにより、typecheckなどのタスクの不要な実行をスキップでき、依存関係が小さい変更ほどCIが早く終わるようになります。
Nxの恩恵を最大限受けるためにはプロジェクトの依存関係を適切に整理することが重要です。コード量の増加によるCI実行時間の増加や開発体験の低下に課題を感じたら、ぜひNxのことを思い出してください！

ファインディの活動

ファインディはゴールドスポンサーとして協賛し、DrinkUpイベントの開催、ブース出展、Findy Conferenceによるイベント管理という形で支援しました。

DrinkUpイベント

DrinkUpイベントの集合写真

ファインディはスポンサーとして、カンファレンス開催前日にDrinkUpイベントを開催しました。
20名もの方に参加いただき、一緒にTypeScript愛を語り合うことができました！

良い雰囲気で進められ、当日に向けてお互いに熱量を高め合うことができたと思います。また、初対面の方々が顔見知りになり、当日の交流がスムーズになったといった声もいただき、よい機会を作ることができたと感じています。

最後には恒例のじゃんけん大会をし、限定ノベルティをプレゼント。当選した方は翌日着用して会場に来てくださいました。

ブース出展

ブース出展の様子

当日はスポンサーとしてブース出展をしました。
今回は、TSKaigiにちなんでTypeScriptに関する課題文が登場するタイピングゲームをご用意しました。

文言や称号は大石、甲斐をはじめとしたファインディのエンジニアで考案したものになります。称号はすべてダジャレにしていたり、課題文には様々なネタを仕込ませていたのですが、楽しんでいただけましたでしょうか？

称号の一覧

難易度を高めにしていたのですが、何度も挑戦していただくなど、前向きに臨んでいただき嬉しく思います。
称号 Lv.5 "型のカタリスト" を達成された方もいらっしゃり、大変盛り上がりました。

多くの方にプレイ・シェアをしていただきありがとうございました！

Findy Conferenceによるイベント管理

今回のTSKaigi Hokuriku 2025においては、イベント管理プラットフォームとしてFindy Conferenceを採用いただきました。
参加者の皆様からも申込、受付の体験が良いと好評をいただきました。オンライン配信も問題なくサポートできました。
TSKaigiをイベント管理プラットフォームとしての立場からも支援できたことを嬉しく思います。

さいごに

TSKaigiはとても暖かい素敵なコミュニティで、いち参加者としても多くの学びと交流の機会を得ることができました。
カンファレンスの開催にあたりご尽力いただいた、運営スタッフの皆様、関係者の皆様、登壇者の皆様に感謝申し上げます。

お知らせ

同日に参加したDevRelメンバーからも記事を投稿していますので、ぜひご覧ください！

note.com

ファインディでは一緒に働くメンバーを募集しています！

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

Anthropicの招待制イベントで登壇してきた話──Ben Mannが語ったAGIの定義とエージェントの本質

こんにちは、ファインディCTOの佐藤(@ma3tk)です。

今回は、Anthropicの招待制イベント「AI Founder Salon」に参加し、登壇する機会をいただきました。

このイベントには、Anthropic共同創業者のBen Mann氏やAnthropicの社員の方々が来日していました。ぜひお話を聞いてみたいと思い参加を決めたのですが、そのタイミングで運営の方から「Fireside Chat（パネルディスカッション）形式での登壇をしてみないか」という打診があり、登壇させていただきました。

本記事では、Ben氏の発表に加え、私自身がパネルディスカッションで登壇した内容も含めてお伝えしたいと思います。

Ben氏が語った、生成AIの未来

Anthropic Ben Mann氏のセッション

Ben Mann氏はAnthropicの共同創業者であり、Fireside Chatで約1時間にわたって生成AIの未来について語ってくれました。その中で印象的だった3つのポイントをお伝えします。

AGIの定義は経済の50%をAIが担うこと

生成AIの未来について、Ben氏が話していた中で最も印象的だったのは、AGIの定義についてでした。

AGIが来ると言われている状況ではありますが、彼はAGIになったかどうかを判断する方法として「経済的チューリングテスト」という考え方を示していました。

これは、「あなたが仕事のために誰かを雇って、3ヶ月間働いてもらう。その相手が人間かAIか判別できない状況になる。そして、経済全体の50%の仕事がAIに置き換わったら、それがAGIである」というお話でした。数年以内にAGIが実現するだろう、というのが彼の予測でした。

特に印象的だったこととして、健康問題の解決や老化の逆転など、人類のあらゆる問題を解決する可能性が高いと話していたことです。半信半疑ではありますが、非常にワクワクするお話でした。

エージェントの本質：ツールを持った言語モデル

AIエージェントの本質についても話がありました。彼の定義はシンプルで、「ツールを持った言語モデル」というものでした。

その中で最も重要なのは、コンテキストへのアクセスであるとのことです。世の中にはたくさんのドキュメントがあります。例えば、Google Docs、SharePoint、社内システムなど、さまざまなシステムへアクセスできる言語モデルになっていく必要があります。

この「多様なシステムに、安全かつ一貫した方法でつなぎにいく」という要件に対して、この1年で登場したMCP（Model Context Protocol）という概念は、標準化を行いながらコンテキストへのアクセスを実現することを目指しています。AnthropicもMCPの開発に取り組んでおり、将来的には多くのシステムがMCPに対応していくことを期待しているそうです。

継続的学習とスキル機能

3つ目は、継続的な学習とスキル機能についてです。

パネルの中で、「AIを使う時に、毎日初めて接するような状態では作業を続けられない」と彼は言っていました。その中で Claude Skills は、継続的に学習していく上での第一歩になる機能だと紹介されていました。Claude Skills とは、カスタム指示や知識を記憶させることができる機能です。

例えば企業において、ブランディングガイドラインをドキュメントとして生成することで、デザインシステムを自分たちのプロダクトに合わせていくことができます。

また、自分たちのプロダクトの設計思想を形にしていくことで、AIが自動的にスキルを生成できるようになります。Ben氏は「3〜6ヶ月ほどで、より自動化が進むのではないか」と見立てていました。人間の役割としては、AIに対してコーチングを行うようになっていくことが見えます。

私が登壇で話した「開発速度」と「UI/UX設計」

パネルディスカッション

パネルディスカッションでは、私もファインディでのClaude活用について話す機会をいただきました。大きく2つのことをお伝えしました。

開発速度の向上と、その課題

まず開発速度の向上についてです。Claude Codeを使うことでプルリクエストの数が増加し、部分的に開発生産性が上がっているメンバーもいます。

一方で、大きな課題も見えてきました。AIが作るものは、どうしても部分最適になりがちだということです。

これはプロダクトやプロジェクトのコンテキスト、私たちの思想といった要素を十分に埋め込めていないために起こることでもあります。やり取りを重ねるうちに重要な前提が会話の外へ押し出され、限られたトークン量の中で考えるほど、もともと意図していたアイデアを十分に活かし切れなくなってしまいます。

また、別タスクの会話や古い仕様の断片などが混入すると、プロダクト固有の前提が抜け落ち、結果として期待しない動作につながることもあります。

そこで、AIが作ったものを検証していく「守り」が大事になってきます。ユニットテストを書くこと、Lintツールを使うこと、そのうえでCI/CDとして守りのチェックを回すことです。これらの仕組みによってプロダクトそのものが常に安全に保たれ、AIによって意図しない方向へ進んでしまったコードを本番環境へデプロイせずに済みます。

早い段階でバグや違和感に気づける仕組みを整えていくことが大事だと考えています。

AI時代におけるUIの提供の仕方とUX設計

もう1つお話ししたのは、AI時代におけるUIの提供についてです。

テキストボックスを作ってチャット形式で入力するというUIはよく見かけますが、多くのユーザーにとって非常に難しいUIだと考えています。テキストですべて解決できるのは一部のユーザーだけです。

そうではなく、プロダクト提供者側から準備したいくつかの選択肢から選んでもらうことを実現する。ワークフローにAIを組み込んでいくことで、より便利に日々のルーティンワークをクリアにできるのではないかと思っています。

こうした設計思想こそが、その会社のプロダクトが存在する意味になってくるのではないでしょうか。

これからも、先を見続ける

今回のイベントを通じて、人間のこれからの役割について明確になったと感じています。

すでに多くの会社でAIの活用は始まっていますが、1つ1つの業務がAIワークフローに置き換わるという現象が起きています。Anthropicのような先進的な企業においては、ほとんどの簡単な業務がAIに置き換わっている状況になっているかもしれません。

では、そういった状況の先に何が来るのかを考えてみました。「自分たちの思想をクリアにし、相手が人であれAIであれ、その考えを落とし込んでいく。その結果として、AIを使ってものを作っていくという状況を作ること」が大事になってくると感じました。

創造性を発揮できる環境で、アイディアを出し続け、ブラッシュアップすることが求められてくると思います。Ben氏が語った「コーチング」と同様に、人と人のつながりやマネジメントという領域の重要性も高まっていくと考えています。

Anthropicからの招待に改めて感謝しつつ、これからAIが当たり前に使える環境を整えていくとともに、整え切った後に来る時代を見据えていきます。

また、ファインディではAI時代を一緒に切り抜けていけるようなメンバーを募集中です。

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

Terraform x Devinで実現するユーザー管理の自動化

こんにちは。

ファインディのPlatform開発チームでSREを担当している大矢です。

私たちのチームでは現在、SREのトイル削減を目指して様々な施策に取り組んでいます。今回はその1つとして、AIエージェント「Devin」を活用したユーザー管理の自動化についてご紹介します。

今回のお話

ファインディではクラウドサービスのユーザー管理の一部をPlatform開発チームが担当しています。具体的にはAWSのユーザー作成、グループへの追加、GitHubのOrganizationへのユーザーの招待などが該当します。

2025年12月現在、AWSのユーザーとグループはTerraformによるIaC管理に加え、Slackのワークフローを利用した申請受付からDevinによるPull Request(以下、PR)作成まで自動化を実現しています。

本記事では、かつて手動で行われていた管理フローがどのような課題を抱え、Terraform x Devinの導入によってどう改善されたのか、その経緯と改善内容についてお話しします。

本記事で触れること

• ユーザー管理自動化までの経緯と課題感
• なぜDevinを採用したのか
• IaC x Devinの実装内容とメリット

本記事で触れないこと

• Terraformコードの詳細な実装
• Devinのセットアップに関する細かい技術仕様

自動化までの歩み

AWSユーザー管理の手段は、組織の成長に合わせて次のように変わってきました。

1. 手動管理期: 情シスがマネジメントコンソールから手動で作成
2. IaC導入期: 申請者またはSREメンバーがPRを作成
3. AIエージェント導入期: DevinによるPR作成の自動化

1. 手動管理期

かつては、情シスがユーザー追加の依頼を受け、AWSマネジメントコンソールから手動でIAMユーザーを作成していました。転機となったのはファインディのAWSアカウント構成を見直すタイミングです。ユーザー管理をIAM Identity Centerへ移行し、これを機にTerraformによるIaC管理を開始しました。

2. Iac導入期

IaC化により、ユーザー管理はソースコードベースでおこなわれるようになりました。フローとしては、申請者がSlackのワークフローからの申請と、Terraformのリポジトリへ申請の内容に基づいたPRを作成するという形です。

ユーザーが作成されるまでの流れは次のとおりです。申請者がTerraformの構造を理解する必要はなく、所定のYAMLに所定のフォーマットを追加するだけです。

これにより、ユーザー管理の透明性は向上しましたが、運用を続ける中で新たな課題が浮き彫りになりました。

• 非エンジニア対応の負荷: エンジニアであれば自分でPRを作成できるが、非エンジニアの場合はGit操作が難しく、SREメンバーが代行してPRを作成する必要があった
• コンテキストスイッチの発生: 社員数の増加に伴い、特に月末月初にはユーザー追加申請が集中する。1件あたりの作業時間は短くても、申請内容の確認、Git操作、PR作成、レビュー依頼といった作業が五月雨式に発生することで、本来の業務が頻繁に中断されていた

「作業自体は単純だが、頻度が高く集中力を削ぐ」。これはまさにSREが削減すべき「トイル」そのものでした。

3. AIエージェント導入期

これらの課題から、「ユーザー追加業務は定型化された繰り返し作業であり、人間が手を動かす必要はない」という結論に至りました。そこで、自律的にタスクをこなせるAIエージェント「Devin」にこの業務を任せることにしました。

やったこと

具体的な実装例として、AWSユーザー追加におけるDevinの設定とフローを紹介します。

1. Devinのセットアップ

Machineのセットアップをおこないます。Devin導入当初、KnowledgeやPlaybookは使用できず、Repo Noteに次のような自然言語による指示を記述しました。

- ユーザーの追加
  - ユーザーの情報は以下のファイルで管理している
    - <ユーザー管理ファイルへのPATH>
  - ユーザーを追加する際は、以下の4項目が必要
    - display_name
    - email
    - user_name
    - group
  - 前述の4項目には以下の情報を入れる
    - display_name はAWSのユーザのコンソールに表示される名前
    - email はユーザのメールアドレス
    - user_name はAWSのユーザの名前
    - group はAWSのユーザが登録されるグループ名
  - ユーザーを追加する際は、display_nameをアルファベット順で並べる
- ユーザーの削除
  - 対象となる項目はユーザー追加時と同じ
  - 下記のユーザーを管理するファイルからAWSユーザーを削除
    - <ユーザー管理ファイルへのPATH>
- PRのコミットメッセージのタイトルはConventional Commitsに従うこと
  - ユーザーの追加、削除、変更は`chore: `とする
- 申請者をPRのAssigneesに設定して
  - 申請者はSlackのIDだが、次のリポジトリにGitHubのIDとのマップがあるので、それに従い変換して
    - <SlackとGitHubのIDをマップしたファイルへのPATH>
  - 申請者のGitHubユーザーが特定できなかった場合、PRにコメントを残して
- 処理は必ずPRを作成するところまで完了させて

上記のとおり、しっかり構造化されていない状態でもほぼ期待どおりに動きます。まずは実践するとよいでしょう。

2. Slackワークフローの整備

Devinを操作するためのインターフェースとして、専用のチャンネルとSlackワークフローを用意しました。 エンジニアだけでなく非エンジニアも利用するため、CLIツールなどではなく、誰もが使い慣れたSlackを入り口にすることが重要でした。

Slackワークフローには次の入力項目を設けています。(抜粋)

項目	設定・入力内容
変更種別	追加、変更、削除から選択
表示名(ローマ字の氏名)	ローマ字の氏名
メールアドレス	申請対象者のメールアドレス
グループ	事前に作成したグループ名
特記事項	イレギュラーな要望など

このワークフローから投稿された内容をトリガーに、Devin（@devin）がメンションされ、指示通りにコードを修正してPRを作成します。

セットアップを終えて

DevinとSlackの設定を終えた後は、次のフローでAWSユーザーの申請をおこないます。

DevinとSlackのセットアップは、初めて触る状態からでも半日もかからず完了しました。導入後は人間が対応する時間を少なくとも半分以下に削減でき、セットアップにかけた時間を大きく上回る効果を得られました。まずは小規模な定型業務から試してみることをお勧めします。

なぜDevinなのか

AIによるコーディング支援ツールは多々ありますが、なぜDevinを選んだのか。その理由は主に2点あります。

1. 非エンジニアでも利用可能なインターフェース

例えばClaude CodeのようなCLIベースのツールも強力ですが、非エンジニアが利用するにはハードルが高いです。「Slackでフォームに入力するだけ」という体験を提供するためには、Slackと統合しやすく、自律的にGit操作まで完結できるDevinが最適でした。

2. AIならではの柔軟性

定型的なスクリプト処理では、例外的なケース(例: 1回の申請で2名以上追加したい場合)へ対応するため条件分岐の実装コストがかかります。

Devinの場合、ワークフローの「特記事項」に自然言語で注釈を入れるだけで、よしなに判断して処理してくれます。この「人間の曖昧な指示を汲み取れる柔軟性」は、運用コストを下げる上で非常に大きなメリットです。

今後の展望

現在はAWSやGitHubのユーザー管理だけでなく、次のような領域にもDevinの活用を広げています。

• 新規AWSアカウント作成時に発生する初期設定(繰り返し作業)
• WordPressの簡単な文言変更
• DNSレコードの登録

私たちのチームでは、単純な自動化ではなくSRE x AIという視点を強く持ち、トイル削減と全社的な運用改善を推進していきます。

おわりに

今回は、ファインディで実践しているTerraformとDevinを組み合わせたユーザー管理の自動化についてご紹介しました。 「誰でもできる作業」をAIに任せることで、SREが「人間にしかできない価値ある活動」に集中できる環境作りを、これからも進めていきます。

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

herp.careers

【エンジニアの学び旅】基本情報技術者試験の学習で変わった仕事の進め方

こんにちは、Findy Conferenceを開発しているsontixyou(@sontixyou)です。

普段はWebアプリケーションのフロントエンドとバックエンドの開発を担当しています。

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

今回はエンジニアの学び旅 Part1として、基本情報技術者試験の学習を通して、仕事の進め方がどのように変わったのかを紹介します。

基礎力をつけるきっかけ

新規プロダクトを0 → 1でフロントエンドとバックエンドをほぼ私1人で作ることになりました。

しかし、私は基本情報技術者試験相当の知識を知らないため、テックリードとシステム設計の話をしていても、話を理解できず、先に進まないことがありました。

開発が進む中で、プロジェクトマネジメントに支障が出て、リリース日が後ろにずれこんでいました。

振り返り会において、弊社のテックリードから自分のエンジニアスキルの基礎力が足りていないとフィードバックをもらいました。

基礎力の中でも特に次の点が不足していました。

• プロジェクトマネジメント
• Webサービスを開発するための基礎知識

今まで開発業務に全力投球していたツケが回ってきました。

指摘された点については、基本情報技術者試験相当の知識があれば、当たり前に知っていることです。

プロジェクトマネジメントにおける伸びしろ

私は仕様が不明確だったり、仕事を進める中で調整に時間がかかりそうなタスクを後回しで、すぐ着手できるものから手をつけていました。

また、調整に時間がかかると見込んでいたタスクを着手したときには、自分の見積もりより時間がかかるタスクでした。

さらに、プロジェクトマネジメントにおけるクリティカルパスという単語を知りませんでした。

Webサービスの基礎知識の伸びしろ

エンドポイントの設計やレスポンスのステータスの理解が足りていませんでした。

例えば、MDNのHTTP response status codesをもとに、正しいレスポンスのステータスをAPIから返せていませんでした。

これらの壁を超えるために、まずは基本情報技術者試験の内容を学ぶことにしました。

ただし、参考書を勉強するだけでも良かったのですが、基本情報技術者試験を合格することを目標の一部にしました。

なぜなら、基本情報技術者は一度合格すると永久に使える国家資格です。さらに、資格の更新が必要ないことも魅力であるためです。

基礎知識を学ぶ

基本情報技術者相当の知識を学ぶ

徹底攻略 基本情報技術者教科書 令和7年度を読むことにしました。

その頃、テックリードが毎週、基本情報技術者試験の内容を解説してくれる回がありました。

受け身だと全然身にならないので、途中回から教科書を全部読んだうえで参加しました。そのおかげで、自分で学習した内容を復習しながら、参加していました。

試験に合格するために、基本情報技術者専門の過去問道場サイトにある直近5年間分の過去問をひたすら繰り返し解くことにしました。

1ヶ月半くらい勉強して、無事に基本情報技術者試験に合格しました！

Webサービスの基礎知識を学ぶ

基本情報技術者試験だけでは、Webサービスの基礎知識を身につけることが難しいため、Webを支える技術とMDNで公開されているWebについてのドキュメントも並行して読み進めました。

Webの基礎知識を学ぶことを通して、REST APIの設計やレスポンスのステータスコードについて理解が深まりました。

自分の中で変わったこと

プロジェクトマネジメントで変わったこと

クリティカルパスを意識しながら、機能開発を進めるようになりました。

新しい機能開発の設計や実装を始める前に、まずは仕様が不明確な点を洗い出し、不明確な仕様を決めにいくことや関係者と話し合うことを優先するようになりました。

仕様が確定するまでに時間がかかる場合、その間にできる他のタスクを進めることで、全体のスケジュールを守ることができるようになりました。

基礎力をつけるための取り組み

基礎知識を身につけることを重視して、技術書を選ぶようにしています。 最近読んだ本は次の通りです。

www.shoeisha.co.jp

今までは、流行っている技術を追いかけたり、ほかのフレームワークや言語を試していました。 現在は、最新のトレンドなどは情報収集のみを行い、基礎力をつけることに注力しています。

また、学んだことを自分のものとするために、手をたくさん動かすようにしています。

プライベートや実務でのシステム設計や実装をやっていると、本を読んだだけでは出てこなかった疑問が出てきます。

それを解決するために、周辺知識を学ぶ必要が出てくるため、そこから更に深掘って学んでいくようにしています。

ただし、疑問を解決するため度に新しい知識を学んでいくことは終わりが見えないため、区切りをつけることも大事です。

おわりに

エンジニア4年目で基礎力の不足に気づき、基本情報技術者試験を通して、自分のスキルを伸ばせました。

もし自分と同じように、開発業務に全力投球してきて基礎知識に不安を感じているエンジニアがいたら、基本情報技術者試験の学習をおすすめします。

資格取得が目的ではなく、体系的に基礎を学び直すきっかけとして活用してほしいです。

基礎知識の学習に終わりはありませんが、1つずつ積み重ねていくことで、確実にエンジニアとしての基礎力が強くなっていくと信じています。

---

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

JSConf JP 2025 でスポンサー登壇をしてきました

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

11月16日にグラントウキョウサウスタワーにて開催されたJSConf JP 2025でスポンサーセッションに登壇してきました。 今回はJSConfの雰囲気や登壇内容についてご紹介したいと思います。

jsconf.jp

会場へ出発！

普段は青森県でフルリモートとして働いているので、当日の早朝の新幹線に乗って会場に向かいました。 会場は東京駅直通のグラントウキョウサウスタワーということで、新幹線降車から直接向かうことができたのはとても嬉しかったです。

様々なイベントで勝手に連れ回してもらっている自分のアクリルスタンドも連れて、ワクワクしながらいざ東京へ！

自分のアクスタと東北新幹線

会場到着

颯爽と東京駅の改札をでて、普段はあまり出ることのない八重洲側出口を若干ウロウロしながら無事にサウスタワーに到着しました。 会場が44階にあることは新幹線内で履修済みだったので余裕の表情で受付を済ませていざ会場へ！！

ふおおおおおおおおおおお！ すんごい高い！すんごい高いよ！！！

44階の凄さをわからせるエレベーター

なんとか余裕の表情をキープして会場に入りました。

ノベルティのTシャツをもらいウキウキです。オフラインイベント独特の空気を身体中に吸い込んでいました。

いただいたノベルティTシャツ

ブースや発表の聴講

自分の出番は17:30からとまだまだ時間がかなり合ったので、他のスポンサー企業様のブースや、セッションの聴講に向かいました。

わかっていたことではあるのですが、改めて、JSConfの発表はどれも濃い...。 TC39やJSの歴史の話などその辺ではそうそう聞くことができない濃度の話題がポンポンでてきていました。

JSConf JPの前身である東京Node学園の初期にも参加させてもらっていましたが、オーガナイザーの古川氏の思想と哲学がびっちりと詰め込まれたイベント内容になっていました。 ファインディでもインタビュー記事を掲載させていただいたのでこちらもご紹介しておきます。

findy-code.io

個人的に興味を惹かれたのはbunのスタックトレース実装に関する @__sosukesuzuki さんの発表でした。 東京Node学園もNode.jsの内部エンジンやノンブロッキングIO、イベントループの話題がかなりの盛り上がりがありましたが、15年以上の時をこえてJS エンジンの話が聞けるとは思いもよりませんでした。

前日はYAPCにいらっしゃったはずなのに、こんなに興味深い話ができるなんてすごい...。

speakerdeck.com

スポンサーセッション登壇

最終確認

いよいよ登壇時間も近づいてきたのでお伝えしたいことのコアを確認しながら最終確認をしつつ、ブース裏で待機しました。 今回の持ち時間がおよそ30分でして、自分の発表経験のなかでもかなり長いので伝え漏れだけは避けたいという気持ち。

出番が近づいて急に集中しだす金髪

登壇たのしい！！

いよいよと登壇時間になったのでヌルヌルっと登壇者席に入り込み、無事に発表してきました。

speakerdeck.com

今回は巨大なJS/TSソースをモノレポ管理しているなかでのモジュール設計とその思想、CIとの関連について発表しました。

2分程度の余白をもたせて発表の準備をしっかりしてきたのですが、話が進むにつれて楽しくなってきてしまい、いろいろと付け足しながら進めたので時間はギリギリでした。

会場で聞いてくださったみなさんも集中して聞いてくださり、Xの投稿などもしてくださって感謝です。

オフラインの登壇たのしいな！！！

おわりに

スポンサーブースではいろいろと見知った方も来てくださり、弊社のノベルティを喜んでくださる姿がとても嬉しかったです。

ファインディではさまざまなイベントの主催・企画をしていますが、JSConf JPのように特定言語のコミュニティがつくるイベントはまた違う雰囲気があって刺激的でした。

いろいろな言語や技術レイヤーのみなさんとつながり、エンジニアリングを楽しんでいけるといいなぁと思えた、幸せな一日になりました。

---

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