ファインディにおけるマルチプロダクト横断の次世代ログプラットフォームの設計思想

クラウドネイティブ会議2026での登壇資料です。

https://kaigi.cloudnativedays.jp/sessions/3058/?from=timetable&day=day2

Transcript

1. ファインディにおけるマルチプロダクト横断 次世代ログプラットフォームの設計思想 CTO室 Platform開発チーム SRE 原 昂司 (kouzyun)
2. 目次 a g e n d a 1. ⾃⼰紹介 2. ファインディについて 3. SREチームの変遷とマルチプロダクト化 4. 横断ログ基盤の設計と全体像 5. ログ検索エージェントによる運⽤⾃律化 6. まとめ 2
3. ⾃⼰紹介 01 3
4. 原 昂司 / こうじゅん(@kouzyunJa) ファインディ(株) / CTO室 Platform開発チーム / SRE • 2024年12月ファンディにジョイン • Platform SREとして横断的なプロダクトの信頼性向上 • 主にインフラ基盤側を担当 • blog: kouzyun.dev • hobby: J-ROCK / 🎸 / 🏃 / ☕ • 最近、Proxmoxで自宅ラボつくった 自己紹介
5. ファインディについて 02 5
6. 会社概要 会社名 ファインディ株式会社 / Findy Inc. 代表取締役 ⼭⽥ 裕⼀朗 設⽴ 2014 年 2 ⽉ ※ 本格的な事業開始は2016年7⽉ 全従業員数 478 名 ※2026年1⽉時点 資本⾦ 19億9,692万円 ※ 資本準備⾦含む 住所 東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー 5階 事業許可番号 13-ユ-308478 サービス ‧IT/Webエンジニアの転職サービス「Findy」 ‧ハイスキルなフリーランスエンジニア紹介サービス「Findy Freelance」 ‧経営と開発現場をつなぐAI戦略⽀援SaaS「Findy Team+」 ‧開発ツールのレビューサイト「Findy Tools」 ‧テックカンファレンスのプラットフォーム「Findy Conference」 ‧顧客価値を追求する、AI時代の製品開発マネジメント「Findy Insights」等 投資家 グローバル‧ブレイン、ユナイテッド、SMBCベンチャーキャピタル、KDDI、 JA三井リース、みずほキャピタル、博報堂ＤＹベンチャーズ、Carbide Ventures、等 会社概要
7. 挑戦するエンジニアのプラットフォームをつくる。 テクノロジーによる社会変⾰の時代に最も必要なことは、エンジニアの可能性を拡げることです。 Findyは、アルゴリズムとヒューマニティの融合によって、 すべてのエンジニアが不安なく挑戦できる世界共通のプラットフォームをつくります。 個⼈のチャンスを⽣み出し、組織の⽣産性を向上させ、社会の⼈材資産を好循環させる。 エンジニアプラットフォームが、デジタル社会の発展を加速していきます。 ビジョン © Findy Inc. 7
8. © Findy Inc. ファインディが展開するエンジニアプラットフォーム サービス紹介 8 ファインディが展開するエンジニアプラットフォーム
9. 9 24万⼈ 3,700 社 登録企業数 会員登録数 ※ Findy 転職、Findy Freelance、Findy Team+、Findy Toolsの4サービス累計での会員登録数及び登録企業数です。 　 なお、1社又は1名の方が複数のサービスに登録している場合は、そのサービスの数に応じて複数のカウントをしています。 複数サービスの展開により、多くのエンジニアに⽀持されています
10. Findy Team+とは｜経営と現場をつなぐVertical AI 開発⽀援ツールのデータを活⽤し、3ステップでビジネス成果の改善を促進      1 可視化 開発ワークフローを可視化し 明確なインサイトを取得 2 AI分析 AIを活用して、開発効率と 開発者体験を最大化するための課 題を自動で特定 3 改善 データに基づいた意思決定で ビジネス成果を最大化 Claude Code GitHub Copilot Cursor Devin その他、多数... AIツール コード管理 プロジェクト管理 10
11. 11 Four Keys: 開発組織のデリバリー能⼒を可視化 「スピード」と「安定性」を定量化し、プロセスの改善点を⾒つける
12. 12 ファインディの技術選定
13. SREチームの変遷とマルチプロダクト化 03 13
14. SREチームのビジョン 14 SREの⽂化を組織全体に根付かせ、開発チームが⾃律的にSREを実践できるように⽀援する
16. 16 Platform SRE
17. Platform SRE と Embedded SRE の役割分担 Platform SRE • プロダクト横断‧共通基盤 • 標準化 • セキュリティ全体統制 • ⾃動化‧トイル削減 Embedded SRE • プロダクト特化‧固有課題 • 固有バグ対応 • パフォーマンスチューニング 17 隔週で定点観測会(SLO振り返り会)を開催して情報共有
18. チームの変遷：基盤整備からイネーブリングへ 18
19. • 新規プロダクトの複数⽴ち上げ • 既存プロダクトの拡張 • AI活⽤で開発スピード増加 → Platform SREの運⽤対象が増加 変遷の背景: プロダクト数の増加 19
20. 例えば、2025年は6サービスを並⾏整備 20 Findy Conference Findy AI+ Findy Team+ AIチャットボット Findy ID Findy Insights アーキテクチャ 壁打ちAI
21. プロダクトが増えると、⽐例して管理対象も増える • SLI/SLO、オブザーバビリティ • AWS/GitHub管理 • IAM / 権限設計 • コスト管理対象 • セキュリティ →プロダクト数は増えるがSREチームのメンバーはなかなか増えない。。。。 21
22. 社員数も100名以上増加 22 +100 1年で社員数が100名以上増加 アカウント申請・権限設定の対応が累積
23. 「2週間でStg/Prodを⽤意してほしい」依頼が複数並⾏ 23 「2週間でStg/Prodを用意してほしい」 • スピード重視の依頼が複数並行で発生 • 他タスクも同時に走っている • 新規プロダクト立ち上げのたびにSREが個別対応
24. 個別対応を積み上げると、Platform SREが運⽤ボトルネックになる • プロダクトごとに設定‧運⽤がばらつく • 調査のたびに前提確認が必要になる • 標準化されないまま運⽤知識が増えていく →Platform SREが毎回対応しなくても回る仕組みが必要 →留学制度やClaude Code SkillsのPlugin配布もこの⼀環 24
25. 25 [Claude Code Plugin] • 社内でよく使う構成を Terraform 汎⽤モジュールとして整備 • モジュールでのTerraform 記述⽀援SkillsをClaude Pluginで配布 [SRE 留学制度] • 新プロダクトのインフラ構築を開発メンバーが主体的に実⾏する • SLI/SLO、モジュール構成‧Plugin の説明ドキュメントを整備して渡す • 構築は開発メンバーがメイン、SRE はサポートに回る • もくもく会‧定点観測会(SLO振り返り会)で疑問を集中対応 Enabling 施策の例: Claude Code Plugin / SRE 留学制度
26. ログ運⽤も同じ構造 • ログはあるが、各プロダクトごとに独⾃の運⽤ • ログが保持期間切れで調査不可 • ログをDatadog Logsに寄せるとコストが重い →横断ログ基盤を、⾃律化‧Enablingを⽀援する設計で整備することに 26
27. 横断ログ基盤の設計と全体像 04 27
28. 横断ログ基盤の前提 28 ⽤途 • 障害‧エラーの原因調査 • プロダクト横断の傾向分析 → 多少のラグは許容 → 収集対象: アプリケーションログ (監査‧セキュリティログは    Security Lake で担保) 収集範囲 • AWS 対象外 • AWS 以外のクラウド (Google Cloud 等)
29. 運⽤負荷を上げない技術選定 [SREチームが抱え込まない設計] • 運⽤負荷を上げない、オーバースペックになりすぎない • 新プロダクトのログも簡単に取り込める • ⾃然⾔語で誰でも検索できる [検討した技術選択肢] • Grafana Loki (OSS セルフホスト): ⾃前運⽤が必要 • Datadog Logs: コストが重い 29
30. マネージド機能の組み合わせを採⽤ 30 収集 データレイク化 S3 Tables Integration 可視化‧検索 Grafana Athena Bedrock AgentCore CloudWatch Logs Centralization
31. 採⽤したログ基盤の全体構成 31
32. 収集: CloudWatch Logs Centralization 32
33. Centralization Rule の主要特徴 33 [Centralization Rule でできること] • Firehose / Lambda 不要でアカウント間の集約が完結 • アカウント単位でログ取り込み • 暗号化済みロググループも集約 • ソースアカウント側で個別の設定不要 [AWS Organizations による権限委譲] • Root アカウントから Logarchive アカウントへ権限委譲 (Delegated Administrator)により可能になる • 1つのルールで Organizations 全体に⾃動適⽤ [制約] • ルール作成後の新規ログのみ対象（過去ログは集約されない）
34. 新規プロダクトのアカウント追加時 34 集約ルールの scope に AccountId を追加するだけ • • • centralization_rule.tf resource "aws_observabilityadmin_centralization_rule_for_organization" "cwl" { rule { source { scope = join(" OR ", [ "AccountId = 'xxx'", "AccountId = 'yyy'", "AccountId = 'zzz'", "AccountId = 'new-account-id'", # 新規プロダクトアカウント ID追加 ]) } } }
35. データレイク化: S3 Tables Integration 35
36. データレイク化: S3 Tables Integration 36 [S3 Tables Integration の特徴] • Apache Iceberg 形式の構造化データレイクにできる • Athena / Iceberg 互換ツールから SQL でクエリ可能 • read-only (ユーザー書き込み不可、CloudWatch が⾃動投⼊)
37. 可視化: Athena / Grafana 37
38. 38 監査‧セキュリティログ基盤: Security Lake
39. 39 監査‧セキュリティログ基盤: Security Lake • 監査‧セキュリティ系 AWS ログ (CloudTrail / VPC Flow Logs / WAF / Route 53 等) を収集 • OCSF スキーマで標準化されたデータレイク (S3 + Iceberg) • マネージドで⾃動収集 • Athena から SQL で分析可能
40. ログ検索エージェント 05 40
41. ログ検索エージェントの背景 41 • ログ基盤の集約は完了 • Athena / Grafana での可視化‧分析は有識者なら可能 • 開発陣の SRE 領域への興味‧関⼼を広げ、⾃律化‧Enabling の起点としたい • そのために⾃然⾔語で検索できるようにしたい
42. 42 ログ検索エージェントの構成
43. 43 Bedrock AgentCore の採⽤理由 [検討した実装の選択肢] • DevOps Agent • Claude Code Skills / Plugin • Bedrock AgentCore
44. 44 Bedrock AgentCore の採⽤理由 [DevOps Agent] • S3 / S3 Tables への能動的なクエリが仕様上できない [Claude Code Skills / Plugin] • ローカルで実⾏者の AWS Profile が持つ IAM 権限に依存し、過剰な権限で 実⾏される懸念(ガードレールの整備をきちんとしたい)
45. 45 Bedrock AgentCore の採⽤理由 [Bedrock AgentCore を採⽤した理由] • Slack / Lambda から API として呼べる • 権限境界を IAM × Lake Formation で AWS 側に寄せられる • ログ検索を起点に運⽤エージェントとして機能拡張‧改善し続けられる
46. 46 ガードレール: SQL バリデーション × IAM × Lake Formation の三段構え
47. 47 「ログを消して」を Slack から依頼 ガードレール: SQL バリデーション × IAM × Lake Formation の三段構え
48. 48 活⽤シーン例 [SLO 振り返り会でのログ要約] [CloudTrail / WAF のセキュリティ調査] 作って終わりではなく、ちゃんと届ける
49. 49 今後の展望 [ガードレール強化] • hooks 機能強化 • AgentCore Identity でユーザー単位の認証‧監査 • Athena Workgroup でクエリスキャン量上限を⾃動制御 [機能拡張] • SLO 振り返り⽤サマリ⽣成の⾃動化 (Datadog MCP 連携 + 定期実⾏) • 社内ドキュメントの参照 (Bedrock Knowledge Bases) • 過去調査の⽂脈保持 (AgentCore Memory) • Slack アラート発報時の⾃動サマリ
50. まとめ 06 50
51. まとめ 51 • Platform SREの管理対象はプロダクト数に応じて増える • 個別対応を続けるとPlatform SREがボトルネックになる • 開発チームの⾃律⽀援 (Enabling) に注⼒ • ログ基盤は、開発チームの Enabling を⽀える基盤として設計 • ログ検索エージェントを起点に、運⽤⾃動化 (AIOps) の改善へ
53. 53 ご静聴ありがとうございました！