DevinからClaude Code Actionsへ ── アカウント管理の自動化基盤を移行した判断とアーキテクチャ
こんにちは。ファインディのPlatform開発チーム（以降、SREチーム）でSREを担当している原（こうじゅん）です。 SREチームでは、AWSのユーザーとGitHubのアカウントの管理をTerraformで運用しています。Slackから申請が来たらTerraformのコードを書き換えてPRを出す、という作業を以前はDevinで自動化していました。 しかしDevinのアカウント利用形態が変わったことをきっかけに、この自動化基盤をClaude Code Actionsへ移行しました。同じようにAIツールでインフラ運用を自動化している方や、Claude Code Actionsの実践的な使い方を探している方に向けて、移行に至った判断理由と、移行後のアーキテクチャについて紹介します。 背景：Devinでアカウント管理を自動化していた 移行を決めた理由 移行後のアーキテクチャ triageジョブ：申請の振り分け routine-prジョブ：ファイル編集とPR作成 escalateジョブ：自動処理できない申請の通知 まとめ 背景：Devinでアカウント管理を自動化していた ファインディでは、GitHub Teamへのメンバー追加やチームの作成・廃止といったアカウント管理を、SREチームがTerraformで運用しています。 エンジニア・ビジネスサイド問わず、メンバーがSlackから申請を出すと、SREがTerraformのコードを手動で書き換えてPRを出し、レビュー・マージ後にapplyされる、という流れでした。毎回決まったパターンのYAML編集とPR作成を手作業でやるのは、典型的なトイルです。 このトイルを減らすために、Devinを使って自動化していました。Slackの申請内容をDevinに渡すと、Terraformリポジトリのコードを編集してPRを作ってくれる仕組みです。この取り組みの詳細は次の記事で紹介しています。 tech.findy.co.jp 移行を決めた理由 きっかけは、2026年4月1日のDevinのアップデートです。このアップデートでDevinアカウントを持たないユーザーはSlackのDevinスレッドに参加できなくなりました。 アカウントを持たない申請者が@Devinに返信してもDevinが反応せず、「動かない」というSREへの問い合わせが増えました。コンプライアンス上、全メンバーへのアカウント一律払い出しも現実的ではありません。そのため、Devinからの移行に踏み切りました。 移行先の選定にあたっては、次の3つを重視しました。 全メンバーが個人アカウントなしで使えること — Anthropic公式の@Claude（Claude in Slack）も検討しましたが、各ユーザーにClaude Codeのアカウントが必要で同じ問題を抱えて断念しました 申請者の体験を変えないこと — Slack Workflowのフォームはそのまま、バックエンドだけを差し替えます チームのツール統一 — 開発チーム全体がすでにClaude中心の開発体制になっており、自動化基盤もそれに合わせました この選定理由より、今回のアーキテクチャとなりました。 移行後のアーキテクチャ 移行後の全体構成は次のとおりです。 flowchart TD subgraph Slack["Slack （申請者の体験）"] F1["メンバー申請"] F2["チーム申請"] Thread[("申請者スレッド")] end subgraph GHA["GitHub Actions"] Triage["triage\n(Claude Code Action)\n整合性チェック・名前解決"] RoutinePR["routine-pr\n(Claude Code Action)\nファイル編集・PR作成"] Escalate["escalate\n自動処理不可を通知"] end SRE["SRE承認・マージ"] Apply["terraform apply"] F1 -->|workflow_dispatch| Triage F2 -->|workflow_dispatch| Triage Triage -->|routine| RoutinePR Triage -->|escalate| Escalate RoutinePR -->|PR作成| SRE RoutinePR -->|受付通知| Thread Escalate -->|エスカレ通知| Thread SRE -->|マージ| Apply Apply -->|完了通知| Thread classDef unchanged fill:#e6f4ea,stroke:#34a853,stroke-width:2px,color:#1b5e20; class F1,F2,Thread unchanged style Slack fill:#f1f8f4,stroke:#34a853,stroke-width:2px; Slack Workflowからの申請がGitHub Actionsのworkflow_dispatchをトリガーし、正常系ではtriageジョブとroutine-prジョブの2つのClaude Code Actionが順に処理する構成です。 ただし、Slack Workflow Builderから直接workflow_dispatchは呼べません。間にSlack Custom Function（Deno Slack SDK）を挟み、GitHub APIへの認証付き呼び出しを行っています。 api.slack.com sequenceDiagram participant WF as Slack Workflow Builder participant CF as Custom Function<br/>(Deno Slack SDK) participant GH as GitHub API WF->>CF: フォーム入力値を渡す CF->>CF: GitHub App秘密鍵でJWT署名 CF->>GH: JWT → Installation Access Token取得 GH-->>CF: Token返却 CF->>GH: workflow_dispatch（Token認証） GH-->>CF: 202 Accepted 申請者から見ればSlackのフォームに入力するという体験は変わっていませんが、裏側ではCustom FunctionがGitHub Appの認証（JWT署名 → Installation Access Token取得）を行い、workflow_dispatchを呼び出しています。 triageジョブ：申請の振り分け 最初のClaude Code Actionは、申請内容の整合性チェックと振り分けを担当します。 チーム名の名前解決（申請者が入力した表記ブレを、リポジトリ上の実際のディレクトリ名に解決する）、申請内容のバリデーション、そしてroutine（自動処理可能）かescalate（自動処理不可）かの判定を行います。 triageとPR作成を1つのジョブにまとめることもできますが、責務と権限を分離するためにあえて分けました。triageジョブは--max-turns 5と少ないターン数に制限し、使えるツールもReadとBash(ls:*)だけに絞っています。判定がおかしければPR作成に進まない安全弁にもなります。 判定結果はJSON Schemaで構造化出力させるので、後続のジョブが確実にパースできます。 claude_args: | --max-turns 5 --allowedTools Read,Bash(ls:*) --json-schema '{"type":"object","properties":{"verdict":{"type":"string","enum":["routine","escalate"]},...}}' routine-prジョブ：ファイル編集とPR作成 triageでroutineと判定された申請は、2つ目のClaude Code Actionが処理します。TerraformリポジトリのYAMLファイルを編集し、ブランチを切ってPRを作成するジョブです。 --max-turns 20とターン数を多めに確保し、ファイル編集やgit操作、PR作成に必要なツールを許可しています。 claude_args: | --max-turns 20 --allowedTools 'Read,Edit,Write,Bash(git checkout:*),Bash(git add:*),...,Bash(gh pr create:*)' PR作成後はSlackの申請スレッドに受付通知を送り、SREがレビュー・マージすればterraform applyが走って完了通知が届きます。 escalateジョブ：自動処理できない申請の通知 triageが自動処理できないと判断した申請は、Slackの申請スレッドにその旨が通知されます。Claude Code Actionは使わず、シェルスクリプトで通知を送るだけのシンプルなジョブです。 まとめ Devinのアカウント利用形態変更をきっかけに、アカウント管理の自動化基盤をClaude Code Actionsへ移行しました。Claude Code Actionをtriage（振り分け）とroutine-pr（PR作成）の2段階に分け、それぞれの責務と権限を絞った設計にしています。 現在、GitHubアカウント管理の移行は完了し、運用を開始しています。今後はAWSのユーザー管理なども移行を進めていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- SRE
- Terraform
- GitHub Actions
- 生成AI
Code w/ Claude Extended | Tokyo 参加レポート
ファインディの森（@jiskanulo）と西村（@sontixyou）です。 2026年6月11日に開催されたAnthropic主催のイベント「Code w/ Claude: Extended | Tokyo」に終日参加してきました。 claude.com 本記事はその参加レポートです。私たちがセッションを聴いてどう感じたか、セッションの内容をどう活かすかの感想も書いていきます。 Workshopで気になったセッション How we Claude Code Ship your first Managed Agent ドメインエキスパートがソフトウェアを作る What happens when domain experts can finally build The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark まとめ ファインディでは一緒に働く仲間を募集しています Workshopで気になったセッション 西村は主にAnthropicメンバーによるWorkshopへ参加しました。Anthropicが取り入れている設定や仕組みを弊社のプロダクト開発フローに適用できるかを意識して聴きました。 How we Claude Code claude.com Anthropicメンバーが実際に使っているClaude Codeのセットアップ方法を紹介するものです。 今回のイベントでのワークショップで説明された題材は次のリポジトリで公開されています。 github.com このセッションで最も印象に残ったのは「徹底インタビュー」と「HTML先行プロトタイプ」の2つです。 「徹底インタビュー」では、Claude Codeにインタビュアー役を担わせて要件を引き出します。 インタビューでは、つぎのインタビュープロンプトをClaude Codeに渡して、HTMLのプロトタイプを作るための要件を引き出す設計になっていました。 I want to build a bill-splitting app, can you help me brainstorm with me on who the audience is, and then interview me in-depth using the AskUserQuestion tool about what to build, focusing on pulling out any ambiguities to create a spec. 上記のプロンプトを実行し、Claude Codeとのやりとりを通して、要件の曖昧さを潰していき、SPEC.mdを作成する流れが紹介されました。要件の曖昧さを上流で潰すことで、実装のやり直しを減らすという設計思想です。 つぎに「HTML先行プロトタイプ」ではSPEC.mdをもとに、4つの異なるデザインを提案させて、HTMLのプロトタイプを作る流れが紹介されました。 Read ../phase-1-planning for its spec file, then help me figure out the overall design of this app. Explore 4 different designs, and create a set of HTML files with important screens for each. 上記のプロンプトを実行すると、つぎのHTMLのプロトタイプが出力されました。 Markdown形式でデザイン仕様を書き出すのではなく、クリックできるHTMLのプロトタイプを出力することで、見た瞬間に判断できます。 設計するタイミングで、Claude Codeとの認識合わせが視覚的にできることで、実装フェーズでのやり直しが少なくなり、トークン使用量の削減につながります。 また、既に運用しているサービスではデザインシステムといったデザイン基盤があれば、精度よくHTMLを出力できる可能性があります。それによって、新しい機能のデザインをするときの認識合わせがスムーズになりそうだと思いました。 Ship your first Managed Agent claude.com Claude Managed Agents（CMA）の全体像を、インシデントレスポンスのデモを通して整理するワークショップです。 このセッションで印象に残ったスライドが「The brain left the box」でした。 以前のアーキテクチャは、Agent loopとTool executionが同じコンテナの中に同居していました。Managed AgentsではAnthropicが管理する1つのサービスとして動き、ツール実行のSandboxはツールが必要なときだけオンデマンドで起動します。クライアントが切断されていてもループは動き続けるため、ローカルのターミナルを閉じてもセッションが止まりません。 これまで西村の開発環境のClaude Codeの使い方では、ローカルPCでClaude Codeを稼働させているため、プロンプトを入力しないとAIエージェントが動き出せませんでした。また、並列セッション数も最大8が限界でした。 Managed Agentsはこの2点を変えられると感じました。オンデマンドで非同期で動き続ける実行環境があれば、人間の合図を待たずに実装する用途が一気に現実的になります。 試したい用途として思い浮かんだのは、着手できていないイシューの開発・リファクタリング、そして人間が介在せずにPRをマージすることです。 最後の「自律マージ」には前提条件を考えなくてはいけません。最低限必要な前提条件を決めておかなければなりません。 例えば、テストカバレッジが一定基準を超えていること、テストの堅牢性が担保されていることなどです。 これらの前提条件を満たすための仕組みを整えることが、AIエージェントによる自律マージの実現に向けた重要なステップになると感じました。 ドメインエキスパートがソフトウェアを作る 森はFounder stageを中心に話を聞いていました。 いずれのセッションもドメインエキスパートの知識・決定が重要であることを話されていました。 いくつかご紹介します。 What happens when domain experts can finally build claude.com 登壇はクイーンズランド大学のJason Tangen教授。AIネイティブ時代のプロダクトは、汎用的な人材ではなく深いドメイン知識を持つ個人から生まれるという主張です。 「去年までソフトウェアを一行も書いたことがなかった」という彼が、6ヶ月で3つの本番アプリをデプロイしました。 登場したアプリはいずれも学生向けのもので、シラバス生成ツール（classbuild.ai）、法廷証言トレーニング（crosscoach.ai）、学生向け説明ツール、学生の顔と名前を覚えるゲームなど。 専門家の頭の中に眠っていたアイデアが、AIにより作るコストが下がり具現化できるようになりました。 最後に聴衆へ「あなたが何年も密かに欲しいと思っていた小さなツールは何ですか？」「チームの中で、実際にその仕事をやり続けてきた人は誰ですか？」と問いかけられました。 コードを書く能力ではなく、「何を作るべきか」を知っていることが大切なのだと感じました。 The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark claude.com 登壇者はGahee Seo氏。分類の誤りが金銭的損失に直結する貿易コンプライアンス領域で、ドメイン知識とClaudeの組み合わせが基盤モデル単体を超える優位を生むことを示します。 韓国からEUへの輸送など、さまざまな規制が複雑に絡み合う貿易の領域では、どんなAIモデルを使うかよりも専門家の判断フローをどう再現するかが優位を決めるとのことです。 最初のプロトタイプはSingle agentで1件の分類に6分かかっており、また、アウトプット精度にも課題があったとのことです。 課題を解決するために分類器を新しく訓練するのではなく、専門家が5段階で判断するワークフローを複製したという設計思想を発表してくれました。 入力が曖昧なまま処理が走らないようinput gateを設けたこと 全規制ルールをsystem promptに詰め込む設計をやめ、必要な文書を検索する Retrieval と出力結果を検証する Verifierという構想に転換 これらの対応をとりあげていました。さらにエージェントを役割ごとに分割することで30秒まで短縮しました。 アウトプットではなくワークフローを教える、という発言もありました。 期待する出力形式を示すのではなく、専門家がどういう順番で何を見て判断するかをシステム化する。職人芸をインフラに変える、という表現が使われていました。 まとめ 西村が午前に参加したAnthropicのワークショップ2つには、共通した問いがありました。 How we Claude CodeのHTMLプロトタイプは、実装前に人間の判断を前の工程に集約する仕組みです。Ship your first Managed Agentの非同期実行は、後工程での人間の介在を手放すための基盤です。 方向は逆に見えますが、根底にある問いは同じだと感じました。「人間はどこで関与すべきか」を先に設計する、という考え方です。その2点を組み合わせることで初めて、AIと人間の役割分担がきちんと設計できると思いました。 森の参加したセッションは「個人開発者・アーリーステージな創設者向け」という性格のものが多かったです。個人が専門知識を武器にプロダクトを作る事例が多く、それ自体は示唆に富んでいました。 どのセッションでも専門家の知識、決定が大事であるという主張を別の角度から語っていました。 一方で、チームでどう使っていくか・チームの中でどう成長していくかという話はありませんでした。 最近個人的に悶々としている「専門家がいない領域でどう専門性を担保するか」「専門家をどう育てるか、時間をかけるしかないのか」という問いには答えが見つからなかったので引き続き考え続けます。 ファインディでは一緒に働く仲間を募集しています ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 <iframe src="https://hatenablog-pa
- 生成AI
- Claude
「速く作る」から「正しく作る」へ ─ AI活用レベル3段階のロードマップ｜AI Engineering Summit Tokyo 2026 登壇レポート
こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 生成AIが開発現場に入り込んでから1年あまり。Claude CodeやGitHub Copilotなどのエージェント型ツールも一般的になってきました。 その一方で、「AIを導入したのに、思ったほど速くなっていない」「むしろレビューが大変になった」という声を、社内外でよく聞くようになりました。 そんな中で先日、弊社主催の「AI Engineering Summit Tokyo 2026」にて 「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革のロードマップと実行 ─ と題して登壇してきました。 ファインディ社内で1年強かけて見えてきた「AI導入の落とし穴」と、そこから組み立てた3段階のロードマップを共有する内容です。 ai-engineering-summit-tokyo.findy-tools.io この記事では登壇内容を振り返りつつ、AI導入の効果が伸び悩んでいる組織に向けて、ファインディがどのような順番で開発フローを作り変えてきたかを紹介します。 それでは見ていきましょう！ AIを入れたのに、アウトプットは伸びていなかった 「速く作る」だけでは限界がある AI活用レベル レベル 1：AIエージェントでコード生成 レベル 2：AIエージェントでモノを作る レベル 3：AIで価値を生み出す まとめ AIを入れたのに、アウトプットは伸びていなかった ファインディも同様に生成AIの本格活用を進め、Claude CodeやCodexなどのAIエージェントが日常的な開発フローに入り込んできました。社内の体感としては「1人あたりのPR作成数も増えていそうだし、開発のリードタイムも短くなっているはず」というものでした。 しかし、Findy Team+で1年分の数値を計測してみると、想像とは違う景色が見えてきました。 まずポジティブな変化として、PR作成総数は前年比で伸びていました。ただ、その内訳を見ると、稼働メンバー数が約1.5倍に増えていたことが大きく、1人あたりのPR作成数はほぼ横ばいだったのです。 さらに、レビュー開始からApproveまでの時間は前年比でおよそ20分延び、PR1本あたりの平均コメント数・レビュー数も約30%増えていました。AIによるコード生成が増えた一方で、レビュー側の負荷が確実に積み上がっていたわけです。 シニア層と若手層で傾向を分けて見ると、もう一段深い構造が見えてきました。AIの出力を読んで検証できるシニアメンバーはアウトプットが上がる一方、経験年数が浅いほどAI出力の合否判断に苦戦する傾向があり、結果としてレビュー側に判断の負荷が集中していました。 組織全体として、AIに使われている 状態に近かったとも言えます。「体感と事実がズレているかもしれない」と疑い、各種数値を可視化していたからこそ、実は「1人あたりのPR作成数は増えておらず、それどころかレビューの負荷が増えており、結果的に開発のリードタイムは長くなっていた」ことに気づくことができたのです。 「速く作る」だけでは限界がある 計測結果から見えてきたのは、「コードを書く速度が上がっても、ボトルネックがレビューに移り変わったために、全体のリードタイムは短くならなかった」、ということでした。 AIでコードを書くスピードは確かに上がります。一方で、内容を十分理解せずに生成するケースが増えると、PRの一貫性や正確性が落ちます。 指摘の量が増えると、リードクラスのレビュー時間が膨らみ、リードタイムが悪化します。最終的に、トータルのアウトプットはAI導入前とほぼ変わらない、という結果に着地します。 AIの成果物に対する確認や検証に時間がかかるようになり、レビューの負荷が増える。これがAI導入の落とし穴の一つです。そのため、AIの成果物の品質を再現性高く担保するための仕組みを整えることが必要になります。 そのために必要になるのが、「正しい作り方と手順」を仕組み化することです。馬を御する馬具（ハーネス）になぞらえ、AIの動きを暴走させず目的の方向へ導くための仕組みを整えることを ハーネスエンジニアリング と呼びます。 このハーネス化を、ファインディは 開発フロー改革 として進めてきました。具体的には、AI活用のレベルを3段階に分け、土台から段階的に積み上げていくロードマップを描いています。 AI活用レベル 開発フローを分解し、AIで何を肩代わりできるかをマッピングすると、3つのレベルが浮かび上がりました。 レベル 1：速く作る：コード変更とPR作成を中心に、AIで代替できる範囲を自動化する レベル 2：正しく作る：タスク分解とIssue作成までAIに任せ、「正しく作る」仕組みを整える レベル 3：必要なものを作る：要件定義やQAという「AIで代替しづらい」とされてきた領域に踏み込む ポイントは、「どれか1つを単独でやる」のではなく、Lv1 → Lv2 → Lv3 と段階的に積み上げて初めて効果が出るという点です。ここから各レベルを順に見ていきます。 レベル 1：AIエージェントでコード生成 レベル 1の目的は、コード変更とPull request作成までをAIエージェントに任せ、人間は本質的なレビューに集中することです。 このフェーズで真っ先に向き合う必要があるのは、「AIが出したコードの責任は誰にあるか」という問いです。 どれだけ自動化されても、AIが出力したコードの責任は人間にあります。品質と判断の最終責任は人間が引き受けることになります。 その前提の上で、レベル 1の工程を整理してみました。 コード変更とPull request作成はAIに全て任せることが出来ます。そしてレビューに関しては、コードの責任という観点から人間が行う必要があると考えていました。しかし、本当にそうなのか疑問に思いました。 自分自身がコードを書いてPull requestを作成していた頃を思い出してみてください。自分でコードを書いて、Pull requestを作成する。レビュー依頼を出す前にやっていたことがありました。セルフレビューです。 そしてセルフレビューで気づく内容と、実際に他のメンバーからもらうレビューの内容は観点や内容が違います。これを今回の開発フロー改革に当てはめました。 レビューをセルフレビューとレビューに分け、レベル 1ではセルフレビューまでをAIに任せることにしました。セルフレビューではコード変更そのものに対するレビュー、レビューでは人間が最終判断しないといけない内容にフォーカスしてレビューというように切り分けることにしました。 ここで重要なのは、AIを入れる前提として「AIと関係なく当たり前のこと」が揃っている必要がある、という点です。 アーキテクチャ・命名規則・型定義といったコード設計、十分なテストカバレッジ、一貫した設計パターン、そしてPRの適切な粒度・レビュー文化・タスク分解の習慣。 これらはAI以前から品質を保つために必須でしたが、AIエージェントが入ると一気に効いてきます。土台が弱いと、AIはその弱さを増幅する方向に働くからです。 ファインディがこの「土台」をどう積み上げてきたかは、次の記事で詳述しています。 tech.findy.co.jp その土台の上に、AIが参照するドキュメントとルールをガードレールとして整備します。 READMEやプロジェクトドキュメントで開発前提・アーキテクチャ・運用ルールを記述し、AGENT.mdやrulesでコード規約・命名規則・テスト方針をAIに自動参照させ、カスタムコマンドやプロンプトテンプレートで依頼タスクを規格化する。 この整備があって初めて、AIは使い物になるコードを出力してくれます。 ファインディではレベル 1を支える仕組みとして、Claude CodeのSkillを複数組み合わせています。代表的なものは次の通りです。 Pull request作成：typecheck／lint／test／buildといった品質チェックの自動実行、ブランチ命名規則の強制、Conventional Commitに沿ったコミット生成、PRテンプレートからのbody自動生成までを1コマンドで実行 Pull request作成前の自動セルフレビュー：セキュリティ／コード品質／規約準拠／Simplify観点／要件検証／チェックリスト照合の6観点で並列分析。信頼度の高い指摘のみを報告してノイズを抑制し、2026年4月時点で1500以上のPRで運用中 AI併用レビュー：Codex CLIを別系統として並行運用し、メインAIのレビューと統合してPRコメントに提示。AIの偏りに依存しない複眼チェックを実現 定期セルフレビュー自動化：平日の朝方にGitHub Actionsで起動し、直近1ヶ月変更されていない技術的負債となりうる既存コードに対して修正Pull requestを自動作成 チェックリスト自動更新：過去レビューコメントをGitHub APIで収集し、LLMで指摘パターンを分類してチェックリストへ反映。レビュアーの暗黙知をSkillに形式知として残す セルフレビュー周りの仕組みについては、それぞれ次の記事でも紹介しています。 tech.findy.co.jp tech.findy.co.jp これらは1リポジトリにSkill／Sub Agent／MCPとしてまとめており、Pluginとして運用することで /plugin install によるワンコマンド配布を実現しています。全員がcontributeできる構造にすることで、改善がそのまま組織全体に反映される回り方になっています。 レベル 2：AIエージェントでモノを作る レベル 1で「速く作る」の足回りが整うと、次にぶつかるのが「要件をどう実現するか」の手順自体がAIフレンドリーではない、という壁です。タスクの粒度や手順を誰も明示的に決めていないため、生成AIに何を渡せば精度よく動くかが属人化していました。 ここで必要になるのが、「作りたいもの（What）」と「作り方の設計図（How）」を分離して扱う発想です。 Whatをタスク分解の形でHowに落とし込み、それをAIに渡せば、AIはそのステップどおりに実装してくれます。そしてレビューでは、出来上がったコードよりも先に「作り方と実現方法が合っているか」を検証し、設計図のほうにフィードバックする。タスク分解の品質が、そのままアウトプットの品質を決める構造です。 このフェーズでは、AIとの関係性が「協働」から「委任」に変わります。 Vibe Codingが「AIは隣で並走するパートナー」だとすると、Agentic Workflowは「AIは自走する実行エージェントで、人間はその指揮者」になります。 任せる粒度も、1行〜1関数のレベルから、タスク／PR／フロー全体へと拡張されます。 Agentic Workflowの定義として4つの自律性を意識しています。 ゴール指向：「何を」を与え、「どう実現するか」はAIが組み立てる 計画と分解：大きなタスクをサブタスクに分けて順序付けて実行 ツール使用：ファイル・Skill・コマンド・検索・MCPを能動的に使う 自己検証ループ：テスト失敗→修正→再実行を自律的に繰り返す 興味深かったのは、AI委任の前提が変わると開発環境そのものが変わったことです。 2026年に入ってから、ファインディではコード生成のメインツールがIDEからターミナルへ変化しました。 1ウイン
- 生成AI
- GitHub
- QA
- テスト
- 開発生産性
Lookerとセマンティックレイヤーで作る会話分析の運用と評価
はじめに こんにちは。ファインディでデータエンジニアをしている開（@hiracky16）です。 今回はLookerに搭載されている会話分析機能を使って、ユーザーがより自律的にデータ抽出や分析ができるようにした話をします。セマンティックレイヤー（Explore）を会話分析に使用する設計や開発・テスト・評価までの運用のノウハウを紹介します。 会話分析（Conversational Analytics）は、Lookerに搭載されている機能で、自然言語で質問を投げるとエージェントが裏でクエリを組み立てて実行し、表やグラフを添えて答えてくれます。たとえば「1月から5月までのXXX数をUUベースで集計できますか？」と聞くと、次のように月別の集計結果とグラフが返ってきます。 はじめに 会話分析にセマンティックレイヤーを使う理由 セマンティックレイヤーを会話分析の入口にするメリット 参照先のデータを意味ある単位に限定できる コンテキストの肥大化を避けられる デメリット 運用 エージェント定義をGitで管理する 回答品質の評価 評価ケースを定義する 軸1: 回答テキストの品質をLLMで採点する 軸2: 発行されたクエリを決定論的に検証する フィードバックサイクルを回す 成果 まとめ 会話分析にセマンティックレイヤーを使う理由 以前公開したブログでは、Lookerを導入した背景や、登録ユーザーの7割がダッシュボードの作成・閲覧のために日々訪れていることを紹介しました。 tech.findy.co.jp tech.findy.co.jp これらの記事で触れたとおり、重要な指標や共通のディメンションは、セマンティックレイヤーへの集約を進めてきました。 集約した指標やディメンションを使ってダッシュボードを作り社内に展開していますが、「別の切り口で見たい」「集計ロジックを変えたい」といった要望に都度対応する運用となり、その工数が無視できなくなってきました。 一方で、会話ベースでデータ抽出・集計・分析ができるエージェントが世の中に広がってきました。私たちもGoogle製のADKを使って自作してみましたが、こちらもメンテナンスコストがかかります。さらに、全テーブルを対象にするため、SSoT（Single Source of Truth）が整っていない領域や、コンテキストが薄い領域では精度が出ず実用には届きませんでした。 ここで着目したのが、すでに集約を進めてきたセマンティックレイヤー（LookerのExplore）です。これを会話分析エージェントの入口に据えることで、ダッシュボード運用の工数と、自作エージェントのコンテキスト不足という両方の課題を解決できると考えました。全体像は次のとおりです。 flowchart LR subgraph DWH["データウェアハウス"] direction TB NOTE1[/"会社マスタが複数あり<br/>テーブル単位ではSSoTが曖昧"/] T1[fct_scouts<br/>送信済みスカウト] T2[fct_scout_replies<br/>スカウトへの返信] T3[fct_matches<br/>成立したマッチング] T4[dim_users<br/>ユーザー情報] C1[dim_companies_raw<br/>会社情報（raw）] C2[dim_company_master<br/>会社情報（master）] end subgraph SL["セマンティックレイヤー"] direction TB NOTE2[/"業務単位で集約し<br/>使う会社マスタもExploreで判断"/] E1["スカウトExplore<br/>送信数・返信率を定義"] E2["マッチングExplore<br/>成立件数・成立率を定義"] end T1 & T2 & T4 --> E1 T3 & T4 --> E2 C1 -->|スカウトはrawを使う| E1 C2 -->|マッチングはmasterを使う| E2 E1 --> A1[スカウト分析エージェント] E2 --> A2[マッチング分析エージェント] A1 & A2 --> U([利用者の質問]) 左側のデータウェアハウスには大量のテーブルが並び、どれを使えばよいか、指標をどう計算すればよいかはテーブル単位では自明ではありません。たとえば会社マスタがdim_companies_rawとdim_company_masterのように複数存在し、用途によってどちらを使うべきかが曖昧、といったこともあります。これをそのままエージェントに渡しても、うまく答えられないのは当然です。 そこで、Explore側で「スカウト」「マッチング」といった業務の単位にテーブルを集約し、送信数や成立率といった指標の定義まで含めて整えておきます。会社マスタのように複数の候補があるものも、Explore側でどちらを参照すべきかを判断します。たとえばスカウトExploreではdim_companies_rawを、マッチングExploreではdim_company_masterを使う、といった使い分けをExploreの定義として固定しておくわけです。エージェントは生のテーブルではなくこのExploreだけを見るので、何をどう集計すべきかが定まった状態で質問に答えられます。 セマンティックレイヤーを会話分析の入口にするメリット セマンティックレイヤーを入口に据えると、大きく2つのメリットがあります。 参照先のデータを意味ある単位に限定できる 1つのエージェントは1〜5個のExploreに紐づきます。エージェントが触れられるデータがExploreの範囲に限定されるためエージェントの役割がはっきりします。 また、SSoTが担保できていないテーブルであっても、Lookerから参照する形にすればExplore上でSSoTを表現できます。生のテーブルをそのまま渡すのではなく、Lookerというフィルタを通すことで、エージェントが扱うデータの意味を整えられます。ダッシュボードと会話分析で使用するExploreは同じなので、両者で数値が食い違うという事態も避けられます。 コンテキストの肥大化を避けられる 全テーブルをエージェントに渡そうとすると、コンテキストが膨れ上がり、かえって精度が落ちます。Exploreを入口にすれば、LookMLのdescriptionや指標定義がそのまま「正しい意味」のソースになり、必要な範囲のコンテキストだけを渡せます。 LookerはKnowledge Catalog(旧Dataplex)との連携も進んでおり、メタデータをカタログ側で一元管理できるようになってきています。 docs.cloud.google.com 今はLookMLのdescriptionにコンテキストを持たせていますが、今後はKnowledge Catalog側にも用語や定義を蓄積し、それをエージェントのコンテキストとして活かせるようになることを期待しています。 デメリット 一方で、当然ながら弱点もあります。複数のExploreをまたぐ横断分析やファネル分析は苦手です。たとえば、ファインディが主催するイベントへの参加やメディア閲覧といったイベントを起点に、実際に企業とのマッチングに至るまでの流れを追う、といった分析は守備範囲の外でした。それぞれのイベントが別々のExploreに分かれていると、エージェントはどちらか一方しか見られず、つながりを追えません。 そこで、ユーザーという意味のある単位でフェーズをまたいだデータを1行にまとめた累積ファクトを作り、Exploreとして用意することで対処しました。次のように、1行=1ユーザーで各フェーズの日付を横並びに持たせておきます。 user_key イベント参加日 メディア閲覧日 マッチング日 u_001 2026-04-01 2026-04-03 2026-04-20 u_002 2026-04-05 （なし） （なし） u_003 2026-04-10 2026-04-12 （なし） こうしておけば、1つのExploreの中で「イベント参加からマッチングまで到達した割合は？」といったファネルをたどれます。横断的な問いに答える必要があるものは、あらかじめこの形に整形しておき、エージェントからも参照できるようにしています。 運用 LookMLの開発方法は前述のブログで紹介しているので割愛し、今回はLooker会話分析に使うエージェントの開発・運用について説明します。 エージェント定義をGitで管理する 会話分析のエージェントは、Lookerの画面上からでも作成・編集できます。ただ、画面で直接編集すると、誰がいつ何を変えたのかが追えず、システムプロンプト（instructions）の変更履歴も残りません。 そこで、エージェントに必要な項目をYAMLファイルとして定義し、Gitで管理することにしました。1ファイルにエージェントのID、名前、参照するExplore（sources）、システムプロンプト（instructions）、そして後述する評価ケース（cases）をまとめています。 id: hogefugapiyo # 既存エージェントの更新用。新規作成時は省略 name: マッチング分析エージェント description: 企業と求職者のマッチング状況を分析するエージェントです。 code_interpreter: false # このエージェントが参照するExplore sources: - model: sample_recruiting explore: fct_matchings - model: sample_recruiting explore: fct_daily_snapshot_matchings # システムプロンプト instructions: | あなたはマッチング分析の専門アシスタントです。 LookerのExploreを使って、マッチングの成立件数・成立率・ セグメント別トレンドに関する質問に回答します。 ## 用語集 - マッチング: 企業と求職者の間で選考が始まった状態 - 成立率: マッチング成立件数 ÷ いいね件数 ... # 評価ケース（評価の章で後述） cases: - prompt: "今月のセグメント別のマッチング成立率は？" reference: "セグメントでグループ化し、成立件数をいいね件数で割った値を回答する" ExploreやYAMLが編集されると、Git
- Looker
- DWH
- GitHub Actions
- データ分析
- 生成AI
コミットからPR作成までのリードタイムを26%短縮 AI活用の「定着 × 成果」の測り方
こんにちは。ファインディ株式会社でアプリケーションエンジニアをしている西村です。 ファインディの開発組織ではここ1年ほど、Claude Codeを使った開発プロセスのSkill化を進めてきました。Issue生成やセルフレビュー、タスク分解といった作業をSkillにして、社内のClaude Code Pluginに追加するのが日常になっています。 ただ、便利なSkillを揃えて配っただけでは、それが開発フローの中でどれだけ使われ、成果につながっているかまではわかりません。 そこで今回は、開発組織内で配布したPluginやSkillの利用データをどう集め、どう見て、どう改善に回しているか、その考え方と運用を紹介します。 作成したSkillが使われ続けるかを見る 定着と成果を組み合わせて評価する 利用データから使われ方そのものを変える 定着と成果のデータをFindy AI+で可視化する まとめ 作成したSkillが使われ続けるかを見る 開発プロセスのSkill化については、これまでのテックブログでも何度か紹介してきました。 【Claude】Pluginsで簡単横展開 - 開発手法の標準化 - Findyの爆速開発を支えるAI×チェックリスト型セルフレビュー Findyの爆速開発を支えるAIによるタスク分解の粒度設計 繰り返す作業があればSkillとして作成し、社内のClaude Code Pluginへ追加する流れは今も続いています。 一方で、配ったSkillが日々の開発に定着するかどうかは別の話です。配布した当初は新しい取り組みに前向きなメンバーが使ってくれますが、その後も使い続けるとは限りません。Skillの数と種類は充実しているのに、実際に利用されているのは一部だけ、という状況が生まれます。 「作った」で満足せず、配ったあとも「使われているか」を継続的に見ていく必要があります。 定着と成果を組み合わせて評価する ファインディでは、Claude Codeの活用度や作成したSkillの利用状況を計測して可視化しています。集めたデータから、開発工程のどこでどのSkillが効いているかを見て、改善しつづけています。 データを見てみると、よく使われていても成果につながっていないSkillもあれば、利用回数は少なくても効きどころで使われて大きな効果を出しているSkillもあります。つまり、Skillの利用回数だけを成果とみなすと、この違いを見落とすことがわかりました。 そこで私たちは、Skillが定着しているかを測る指標と、成果への貢献を測る指標を組み合わせて評価することにしました。 定着を測る指標は、一定期間内にSkillがどれくらいの頻度で使われているか、つまり利用頻度です。 成果への貢献を測る指標は、Skillを使い始めた後にPRの作成からマージまでの時間といったリードタイム等が短縮したかです。 利用データから使われ方そのものを変える ファインディでは2026年3月に、セルフレビューSkillを導入しました（導入の経緯はこちらの記事で紹介しています）。ただ作成するだけでなく、ドッグフーディングして、AgentTeamに対応させたり、テストのカバレッジが十分かを見る観点を加えたりと、Skillの中身を改善してきました。 セルフレビューSkillは、変更したコードのバグを見つけたりテストの網羅性を高めたりする効果があり、組織全体での定着率を上げていきたいSkillです。 ただ、利用データを見て気づいたのは、改善すべきは中身だけではないということでした。導入直後の3月時点で月298回と一定の利用はあったものの、セルフレビューSkillを呼ぶかどうかは各メンバーの判断に委ねていました。そのため、エンジニア全員の開発フローに浸透するほどには使われていませんでした。 2026年3月時点のSkillの利用回数（左：アウトプット上位5名、右：組織全体96名）です。セルフレビューSkillの呼び出しは、アウトプット上位で117回、組織全体でも298回でした。 アウトプット上位 組織全体 そこで、Skillの使われ方そのものを変えました。SlackのPluginリリース告知チャンネルで使い方を周知し、あわせてPR作成Skillの中からセルフレビューSkillを呼び出すようにして、PRを作るときには必ずセルフレビューSkillを使用する環境に変えました。 その結果、セルフレビューSkillの呼び出しは、アウトプット上位で185回、組織全体で479回まで増えました。セルフレビューSkillが組織全体の標準的な動作として定着したことがわかります。 アウトプット上位 組織全体 さらに、導入前後でリードタイムを比べると、コミットからオープンまでの平均時間は22.2時間から16.3時間に縮みました。AIが書いたコードを人間がセルフレビューしていた手間を減らせたことが、短縮の一因だと考えています。 定着と成果のデータをFindy AI+で可視化する これまで紹介してきたSkillの呼び出し回数データは、Findy AI+の分析機能を使っています。Findy AI+ではClaude CodeのMonitoring機能を活用し、Skillやコマンドの実行ログを収集して、「どのSkillがいつ実行されたか」を一元的に追えるようにしています。 集めたログからは、Skillごとの呼び出し回数や、それが一部のメンバーに偏っているか組織全体に広がっているかといった定着の度合いが見えてきます。ここにTeam+のPR作成数やレビューのリードタイムといった成果指標を重ねると、定着と成果のデータが揃い、「どのSkillで、どの指標に効いているのか」を分析できます。 まとめ PluginやSkillは、配って終わりにすると少しずつ使われなくなっていきます。配ったあとも「使われているか」さらに「アウトプットの増加に貢献できているか」まで見て初めて、改善の打ち手が定まります。 もしすでにPluginやSkillを配っている方がいれば、まずは「どのSkillが、誰に、どれだけ使われているか」を1つでも数字で見えるようにするところから始めてみてください。配ったあとのデータがそろうと、次にどこへ手を入れるべきかが自然と見えてきます。 Findy AI+の分析機能については、Findy AI+の紹介ページもあわせてご覧ください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- 生成AI
- LLM
- 開発生産性
Lambda PDF生成を27倍高速化した話 — Puppeteerから@react-pdf/rendererへの移行レポート
こんにちは。Findy Freelance開発チームの久木田です。 今回は、社内で運用している支払明細書PDFの生成基盤を、Lambda + Puppeteerから@react-pdf/rendererへ全面的に移行した話を書きます。最終的に処理時間はP50（中央値）で約27倍速くなり、メモリ消費も実測で約1/4まで落とせました。 これまでのPDF生成基盤と課題 対症療法でしのいだ期間 根本対応を決めた3つの背景 技術選定: 戻れる順に試す 移行で押さえておきたい実装ポイント 設計と実装のキモ テンプレート構造 esbuildで橋渡し どう変わったか 学び これまでのPDF生成基盤と課題 現在、システムから発行しているPDFはいくつかありますが、本記事では一例として支払明細書PDFに絞って紹介します。ファインディからフリーランスエンジニアへの支払明細として月次で一括発行しているPDFです。 支払明細書PDFは1件あたり1ページで、支払先、支払者、明細表、特記事項、ファインディの社印を配置した構成です。情報量としては小規模ですが、月次でフリーランスエンジニア全員分を一括発行する必要があり、1回のバッチで数百件規模のPDFを並列生成していました。Rails側からParallelライブラリで並列にLambdaを呼び出す構成です。 このPDFは、AWS Lambda上でPuppeteerを起動し、EJSテンプレートから組み上げたHTMLをヘッドレスのChromiumでレンダリングしてPDF化する構成で動いていました。フロントエンド向けのHTML/CSSをそのまま流用できるため初期実装は速かったのですが、運用が進むにつれ次の課題が顕在化しました。 コールドスタートが重く、Chromiumバイナリの起動だけで5秒前後を消費していた 大量生成で /tmp が枯渇し、一括処理で複数のレンダリングを並走させると、エフェメラルストレージが先に尽きてエラー終了する タイムアウトやエラーが恒常化し、数百件規模の一括出力は途中で停止して再実行が必要になる ボトルネックはChromiumの不安定さでした。Chromium起動のたびにプロファイル・キャッシュ・ソケットファイルが /tmp 配下に生成され、browser.close() 後もディスク上に残存します。さらに、レンダリング中にChromiumがハングした場合は、一時ファイルを保持したままプロセスが停止します。その間にも新規リクエストでLambdaが起動するため、ウォームスタートで使い回されるインスタンスでは /tmp の残存ファイルが蓄積し、一定量を超えた時点で全体が停止してしまう挙動になっていました。 この蓄積に備えて、メモリと /tmp は常にバッファを含めて多めに割り当てる必要があり、1Lambdaあたり2-3GB相当の確保を継続していました。それでもハングと並列度のピークが重なる局面では詰まるため、設定値を引き上げては別の閾値で詰まるという状態が続いていました。 一括出力は今後数倍に増加する見込みであり、現状の構成のまま継続することは現実的ではありませんでした。 対症療法でしのいだ期間 課題を踏まえ、徐々に対策を施すことにしました。Lambdaのメモリ割り当て増、タイムアウト延長、エフェメラルストレージの拡張、並列度の調整など、設定値で吸収できそうな対策は一通りしました。短期的な改善にはなったものの、根本にあるのはChromiumをサーバーレス環境で動かすこと自体のコストと描画コストが入力規模に比例して伸びる構造です。設定の積み増しではレイテンシーもエラー率も思うように改善しませんでした。 根本対応を決めた3つの背景 根本対応に踏み切る判断は、次の3点が同時に揃った時点で下しました。 現状の課題: レイテンシーが悪化傾向、エラーも日次で観測される 将来の悪化見込み: 一括処理の件数は今後さらに増える計画があり、対症療法の余地がもう残っていない 対症療法の限界: 設定値の調整ではレイテンシーやエラー率の改善が頭打ちで、いずれの打ち手も効果が薄れてきた 課題が大きくなったため、対策を施しました。逆に言えば、どれか1つでも欠けていたら、もう少し対症療法を続けていたと思います。 技術選定: 戻れる順に試す 根本対応の方針として、大きく2案を比較しました。 A案: Lambdaを維持し、@react-pdf/rendererでProgrammaticにPDFを組み立てる B案: LambdaからECSなど別のランタイムへ移行する A案は、いまのLambda構成を保ったままPDF生成方式だけを差し替える案です。@react-pdf/rendererはJSXを書く感覚でPDFを組み立てるライブラリで、Chromiumのヘッドレスブラウザは利用しません。 react-pdf.org そもそも@react-pdf/rendererが候補に挙がったのは、ヘッドレスブラウザ以外でPDFを生成する方法を調べていたからです。継続的な利用料金が発生する外部サービスを使う選択肢は外し、OSSのプログラマティック生成ライブラリの中で、Reactと同じJSXで書ける@react-pdf/rendererを選びました。Reactはファインディの他プロダクトでも広く使われており、馴染みがあった点も決め手になりました。 B案はメモリやストレージの制約には強くなりますが、コスト構造が変わり、検証の立ち上げにも工数がかかります。Lambdaのタイムアウトに収まらない処理や、Chromiumの表現力（複雑なCSS・JavaScript描画など）をどうしても残したいケースではB案が候補ですが、今回のPDF生成はそのどちらにも当てはまりませんでした。 そのため、最終的には次の3つの理由からA案を選びました。 戻れる: Lambda構成のままPDF生成方式だけを差し替えるので、問題が出てもPuppeteer版に戻すことが容易 テスト可能: PDF生成ロジックがJSXで書けるため、単体テストや出力差分テストを書きやすい AIで移行コストが現実的になった: EJSテンプレートからJSXへの変換は、生成AIに任せられるレベルまで来ていた B案はA案が失敗した場合の代替案として残し、まずは戻れるA案を試すことにしました。 移行で押さえておきたい実装ポイント EJSからJSXへの書き換え自体は生成AIで一気に進められましたが、@react-pdf/rendererの実装スタイルに合わせるために事前に押さえておきたい点がいくつかありました。 @react-pdf/renderer v4はESM-onlyで、tscのCommonJS出力からは読み込めないため、esbuildを入れてESMをCJSにバンドルした 日本語フォントはFont.register()で明示的に登録しないと文字化けする Puppeteerのscale: 0.8相当が無いため、フォントサイズや余白を手で再計算した HTMLの<a>自動展開は再現されず、URL部分だけ<Link>化する小さなコンポーネントを自作した HTMLエスケープは自動化されていて、旧実装のエスケープ処理が不要になった（副産物） 特に大変だったのがJSXの空文字列の扱いです。{stringValue && (...)}と書くと、空文字列がchildとしてそのまま流れ込み、WARN Invalid '' string child outside <Text> componentが大量に出ます。Reactの文法としては正しいのですが、@react-pdf/rendererの<View> / <Page>配下では{!!stringValue && (...)}と明示的にboolean化する書き方に揃える必要があります。さまざまなデータでPDFを作成していく過程で警告ログが出ていることに気付き、該当箇所をまとめて修正しました。 設計と実装のキモ ここからは、@react-pdf/rendererをLambdaに載せていくときに考えた設計面のポイントを2つに分けてまとめます。 テンプレート構造 PDFそのものを1つのReactコンポーネントとして組み立てる構成にしました。リンクの自動展開のように共通で必要な要素は、専用の小さなコンポーネントとして切り出して再利用しています。 EJS時代は部分テンプレートをincludeで組み合わせる作りでしたが、JSXに移ってからはコンポーネントの組み合わせとして自然に再構成できました。 esbuildで橋渡し @react-pdf/renderer v4はESM-onlyですが、Lambda側はCommonJSで動かしています。tscの出力では直接読み込めなかったため、esbuildでESM→CJSのバンドルを作ってLambdaにデプロイする構成にしました。 // esbuild.config.js（抜粋） { entryPoints: ['src/index.ts'], bundle: true, platform: 'node', format: 'cjs', } 設定としてはシンプルですが、ここを通さないと依存関係の解決でつまずくことになるため注意が必要です。 どう変わったか 支払明細書PDFの一括作成処理について、移行前後をCloudWatchメトリクスで比較した実測値が次の通りです。表のP50 / P95 / P99は、実行時間を昇順に並べたときの中央値 / 95パーセンタイル / 99パーセンタイルを表します。 指標 Before After 倍率 実行時間 P50 約3,963 ms 約145 ms 約27倍高速 実行時間 P95 約4,707 ms 約212 ms 約22倍高速 実行時間 P99 約5,249 ms 約458 ms 約11倍高速 平均メモリ 約912 MB 約222 MB 約1/4 最大メモリ 約1,589 MB 約239 MB 約1/7 特に改善幅が大きいのはP50です。旧構成では実行時間そのものの遅さに加え、Puppeteer/Chromium由来のエラー（ブラウザの接続切れやハングなど）が起きると、一括処理の中で個別のPDF生成がLambdaのタイムアウトに到達し、リトライしても最後まで完成せずエラーとして残るケースがありました。表のP99の大きさにそれが現れています。移行後はこれらのエラー、エフェメラルストレージの逼迫、コールドスタートによる遅延がいずれも解消され、Lambda上での実行を意識する必要のない構成になっています。 学び 今回の移行で特に有効だったのは、判断軸として置いた「戻れる順に試す」です。Lambda構成を維持したままPDF生成方式だけを差し替えるA案は、もし行き詰まっても旧版のLambdaに切り戻す選択肢を残せました。ランタイムごと載せ替えるB案を最初に選んでいたら、検証のために抱えるリスクははるかに大きくなっていたはずです。 もうひとつは、生成AIの活用で技術選定の前提条件が変わったことです。A案はEJSテンプレートのJSXへの全件書き換えを伴います。AIなしで工数を見積もると、規模だけでA案は採用候補から外れていました。書き換えだけでなく、旧PDFと新PDFのレイアウト差分の特定と修正案の生成までAIに任せられたため、A案の工数は当初の想定より低く収まりました。 最後に、@react-pdf/rendererを使った所感をまとめます。 メリットとして大きかったのは、Lambdaの割り当てメモリを大幅に減らせたことと、ヘッドレスブラウザを使っていたころよりテストが格段に書きやすくなったことです。PDFをバッファのまま受け取って中身を検証できるので、ブラウザを起動しない軽量な統合テストをCI上でも組めるようになりました。 一方で、HTML/CSSではなく<View> <Text>といったPDF専用のプリミティブをFlexboxで組み立てる、React Native寄りのコンポーネントモデルです。HTML/CSSしか経験が無い場合は、最初は書き方に戸惑う場面もあると思います。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- AWS Lambda
- React
- esbuild
- 生成AI
Findy EventsのUIライブラリ選定 ― TamaguiからHeroUI Nativeへ乗り換えた理由と導入プロセス
こんにちは。Findyでモバイルアプリ開発を担当している加藤と主計です。 Findy初のモバイルアプリ「Findy Events」については、先日React Native選定の経緯と立ち上げの全体像を公開しました。 前記事ではUIライブラリ周りには深く踏み込めなかったので、今回はその続編です。UIライブラリの選定と実装パターンに絞ってお届けします。 具体的には、当初採用していたTamaguiからHeroUI Native + react-native-unistylesに乗り換えるまでの判断と、Wrapper Componentを軸にしたUI構築の進め方が中心です。 なお、本記事で題材にしているFindy Eventsは、App StoreとGoogle Playで公開しています。 Tamagui採用の背景 Tamaguiを使ってみて見えてきた課題 Android実機固有の挙動 Sheet表示直後のタップが効かない Sheet内のScrollViewでスクロールするとSheetが閉じる Expo SDK 54対応のタイミング HeroUI Native + react-native-unistylesに変更を決めた理由 β版採用のリスクとその対策方針 具体的なコード例 HeroUI NativeのWrapper Component react-native-unistylesとWrapper Componentを組み合わせたUI Componentの実装 まとめ Tamagui採用の背景 Findyのモバイルアプリ開発で、当初UIライブラリとして採用していたのはTamagui。 選定時の候補はgluestack-uiとTamaguiの2つで、最終的にTamaguiを選びました。 決め手となった理由は大きく3つあります。 1つ目は、ライブラリとしての信頼性と情報量です。 Tamaguiはv0.1.0が2021年3月にリリースされ、5年以上にわたって開発が続いているOSSです。 GitHubのスター数や提供されるComponent数の充実度から、本番プロダクトに採用しても大きく外さないと判断しました。歴史がある分、ネット上の記事も比較的多く、開発時の調査コストを抑えやすい点も後押し材料です。 2つ目は、iOSエンジニアとしての開発経験との親和性です。 iOS開発ではOSSとして提供されたUIをそのまま利用する、あるいは許容範囲で改変するアプローチが一般的で、Tamaguiはこのメンタルモデルに合致していました。 SwiftUIと同じ宣言的UIの思想を持ち、縦方向に並べるSwiftUIのVStackがTamaguiのYStackに対応するように、子要素を軸方向に積み上げてレイアウトを組み立てる考え方が共通している点も馴染みやすいポイントです。 一方のgluestack-uiは、shadcn/uiと同様にCLIでComponentのコードを自分のリポジトリに生成し、必要に応じて編集して使う方式を採っています。Tailwindライクなクラス指定と合わせて、モバイルエンジニア出身の自分にはやや取っ付きにくく感じました。 3つ目は、Propsベースで直感的にスタイリングできることです。 <Stack m="$2" p="$2" backgroundColor="$background">のように、Componentに対してProps経由でデザイントークンを直接当てられ、感覚としては昔ながらのCSSやSwiftUIのmodifierに近い書き味で扱えます。 デザイントークンによるテーマ管理でライト/ダークテーマの切り替えが容易な点も決め手になりました。 Tamaguiを使ってみて見えてきた課題 Tamaguiを採用してアプリを開発する中で、幾つか見えてきた課題もありました。HeroUI Nativeへの乗り換えを判断した背景でもあるため、ここで率直に共有します。 Android実機固有の挙動 iOSシミュレータやAndroidエミュレータでは問題ないものの、Android実機でのみ起きる挙動に幾つかぶつかりました。ここでは印象に残った2つのケースを、実コードと合わせて紹介します。 Sheet表示直後のタップが効かない メニューや確認ダイアログとしてSheetを表示した直後に、内部のボタンをタップしても反応しないことがありました。 最初はダブルタップが必要なのかと感じましたが、少し時間をおくと反応するため、UIアニメーションの完了までタップが受け付けられていないと推測しました。デフォルトのアニメーションは完了までに時間がかかり、その間タップを取りこぼしていたようです。 そこでSheetにanimation="200ms"のように短い時間のアニメーションを明示的に指定したところ、表示完了までの時間が短くなり、表示直後のタップにもすぐ反応するようになって解消しました。 <Sheet modal open={open} onOpenChange={setOpen} snapPoints={[50]} animation="200ms" // 明示しないとAndroid実機で表示直後のタップが効かない > <Sheet.Overlay /> <Sheet.Frame padding="$4"> <Button onPress={handleConfirm}>確定する</Button> </Sheet.Frame> </Sheet> Sheet内のScrollViewでスクロールするとSheetが閉じる 選択肢が多い項目を選ばせるUIとして、選択肢一覧をScrollViewで表示したSheetを出していたのですが、Pixel 10で動作確認していたところ、Sheet内をスクロールしようとするとそのままSheetごと閉じてしまう事象が発生しました。 該当箇所はおおよそ次のような構成です。 import { ScrollView } from "react-native"; import { Sheet } from "tamagui"; <Sheet modal open={open} onOpenChange={setOpen} snapPoints={[80]}> <Sheet.Overlay /> <Sheet.Frame> <ScrollView> {options.map((option) => ( <Option key={option.id} option={option} /> ))} </ScrollView> </Sheet.Frame> </Sheet> Sheet内のScrollViewでのスクロール操作が、Sheetを閉じるためのドラッグジェスチャと衝突しているのが原因と推測しています。 暫定対応としてSheet側にdisableDragを指定したところ、スクロール時にSheetが閉じる事象は解消されました。 <Sheet modal open={open} onOpenChange={setOpen} snapPoints={[80]} disableDrag // ドラッグでSheetを閉じる挙動を無効化し、ScrollViewのスクロールと衝突しないようにする > <Sheet.Overlay /> <Sheet.Frame> <ScrollView> {options.map</spa
- React Native
- CSS
- Expo
【エンジニアの日常】エンジニア達の人生を変えた一冊 Part7
こんにちは、ファインディでFindy Toolsの開発をしている本田です。 この記事は「エンジニア達の人生を変えた一冊」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。 Part7では、本田・加藤・山田の3名でお届けします。アジャイル開発との出会いになった本、iOSアーキテクチャ設計の答え合わせになった本、AI時代に再読して背筋が伸びた本。3冊それぞれ切り口は違いますが、いずれも自分の中の「開発の判断軸」を作り直してくれた一冊です。 それでは、さっそく紹介していきましょう。 RailsによるアジャイルWebアプリケーション開発 第4版 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ iOSアプリ設計パターン入門 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ 世界一流エンジニアの思考法 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ おわりに ■ 本田 / フルスタックエンジニア ■ ファインディでFindy Toolsの開発をしている本田です。 RailsによるアジャイルWebアプリケーション開発 第4版 RailsによるアジャイルWebアプリケーション開発 第4版作者:Sam Ruby,Dave Thomas,David Heinemeier Hanssonオーム社Amazon 本書は、原著「Agile Web Development with Rails」をもとに、Rails 3.1に対応する形で翻訳された一冊です。著者には、アジャイルソフトウェア開発宣言の起草者の一人であるDave Thomasと、Railsの作者であるDavid Heinemeier Hanssonが名を連ねています。アジャイルの源流とRailsの源流が、ひとつの本のなかに揃っているというのは、今振り返ってみると改めてすごい組み合わせだと感じます。 ちなみに、そのDave Thomasが、2026年6月17日・18日にファインディが主催するオンラインカンファレンス「エンジニアの役割の変化に向き合うConference 2026」に登壇予定です。本書の著者本人の話を聞ける機会でもあるので、興味のある方はぜひチェックしてみてください。 この本を読んだきっかけ 業界4年目の頃、私はC#でウォーターフォールの開発をしていました。仕様を固めて設計書を書き、それに沿って実装し、最後にまとめてテストとリリース。それが「開発」というものだと思っていました。 そんなときに、Railsを使った新しいプロジェクトが立ち上がりました。チームメンバーは全員、Railsも本格的なアジャイル開発も未経験で、何から始めればいいのか分からない状態でした。そこで、みんなでこの本を教科書にして、毎日お昼に少しずつ読書会をしながら進めることにしました。各自一章ずつ読んできて集まり、分からないところを話し合い、サンプルを動かしてみる。それを繰り返して、RubyやRailsを少しずつ自分たちのものにしていきました。 本を中心にしたチームの学びの時間は、いまでも当時を思い出すたびに頭に浮かぶ景色になっています。 本の内容 構成のおもしろさは、Depot（デポ）というオンラインショップの架空のプロジェクトを、章を追って少しずつ作り上げていく形式になっているところです。最初は商品一覧の表示だけ、次にカートをつけて、注文できるようにして、メール送信を加えて……というふうに、本一冊を通じて一つのアプリケーションがインクリメンタルに育っていきます。 機能ごとの章タイトルが「タスクA」「タスクB」と続く構成で、まるで開発の現場でユーザーストーリーをこなしていくかのような体験になっています。Railsの機能を学べると同時に、「動くものを少しずつ広げていく」開発スタイルそのものを擬似体験できるように設計されていて、書名どおりまさに「Railsによるアジャイル」を体現した本だと感じました。 この本から影響を受けた点/学んだ点 この本を読んで一番大きかったのは、開発の進め方そのものに対する自分の考え方が変わったことです。 それまでの私にとって、「仕様を固める」「設計を作る」「実装する」「テストする」は、それぞれが大きな塊として順番に並んでいるものでした。ところがこの本でDepotを作っていく体験は、まったく違いました。小さく動くものをまず作って、そこに機能を足し、動かしてみて、足りなければ調整して、また次の機能を足していく。短いサイクルで「動くもの」を中心に開発が進んでいく感覚は、当時の自分には完全に新しいものでした。 同じくらい衝撃的だったのは、Rubyという言語とRailsというフレームワークの書き心地そのものです。それまで書いていたコードと比べると、コードの量が圧倒的に少なくて、それでいて表現したいことがすっと書ける。フレームワークが規約として用意してくれている部分にうまく乗ると、書くべきものに集中できる。これも「開発って、こんなに違うものになるのか」という気づきでした。 「Webアプリケーションをアジャイルに作る」というのは、ツールやフレームワークだけの話ではなく、考え方と書き心地と進め方が一体になって初めて成立するものなのだと、サンプルアプリケーションを作りながら肌で理解できた気がします。 特に印象に残った部分 特に印象に残っているのは、Depotを章ごとに育てていく構成そのものです。 本の最初のほうで作ったDepotは、商品一覧を表示するだけのとてもシンプルなものです。それが章を進めるごとに少しずつ機能が増えていき、最後にはちゃんと注文ができてメールが届く、ひとつのアプリケーションになっている。途中で「これで動くようになった」「ここはこういう改善ができるのか」と、小さな達成感が積み重なっていく感覚は、技術書を読みながら得られる体験としてとても新鮮でした。 そして、それをチームで読書会として体験したことも大きかったです。お昼に集まって、一章ずつ進めて、分からないところは議論して、サンプルを動かしてみる。今思えば、これ自体が「短いサイクルで動くものを増やしていく」という本書で学ぼうとしていたスタイルを、学び方そのもののなかで実践していたのだと思います。本を読むという行為が、ただ知識を得る時間ではなく、チームで開発のスタイルそのものを共有する時間になっていました。 このような方におすすめ 日本語版は更新が止まっているため、今からRailsを学び始める人に第一の選択肢として薦める本ではないかもしれません。ただ、原著は今もアップデートが続いていて、最新版ではRailsの新しいバージョンに対応した内容で読むことができます。 pragprog.com 私個人としては、Railsとアジャイル開発の出会いをひとつの本でまるごと体験した原体験の本として、今でも特別な位置に置いています。AIで開発の速度や進め方が変わっていく今だからこそ、「小さく動くものを作って、フィードバックを得ながら育てていく」という当時学んだスタイルが、自分のなかでの開発の考え方の土台になっていることをあらためて感じます。 続いては、Tools開発でファインディ初のモバイルアプリ「Findy Events」を担当している加藤さんです。Clean Architectureを採用したプロダクトをリリースした直後に出会った、設計選定の「答え合わせ」になった一冊について語ってもらいました。 ■ 加藤 / モバイルエンジニア ■ ファインディ株式会社でモバイルエンジニアをやっている加藤です。ファインディ初のモバイルアプリ「Findy Events」を開発しています。 iOSアプリ設計パターン入門 peaks.cc ※現在はPEAKSの公式サイトで電子版のみ購入可能です。 私が紹介する「iOSアプリ設計パターン入門」は、iOSアプリのアーキテクチャを網羅的にまとめた書籍です。 この本を読んだきっかけ 当時の私はMVCのみの開発経験しかない中で、業務でClean Architectureに挑むことになりました。 手探りで設計を進め、なんとかリリースまで漕ぎ着けたものの、本当にこれで良かったのか、正しい形は何だったのかという確信は最後まで持てませんでした。 チーム内でClean Architectureに対する共通認識を取り切ることができず、QCDのDを優先して走り切った経緯もありました。そもそもClean Architectureを採用すべきだったのか、別のアーキテクチャの方が適していたのではないかという迷いも残っていました。 そんなタイミングで本書が発売され、自分の中の答え合わせをしたいという気持ちで手に取った一冊です。 本の内容 本書は冒頭で、一般的なアーキテクチャの歴史と構造を整理するところから始まります。 GUIアーキテクチャとシステムアーキテクチャの両面から解説されており、それぞれの位置づけがクリアになる構成です。 その上で、各アーキテクチャをiOSアプリにどう適用するかが具体例とともに示されています。 アーキテクチャの選定に関する考え方にも一定のページが割かれており、サンプルコードがGitHubで配布されているため、手を動かしながら理解を深められるのもありがたいポイントでした。 この本から影響を受けた点/学んだ点 一番大きかったのは、GUIアーキテクチャとシステムアーキテクチャは組み合わせて使うものだという視点を得られたことです。 それ以前の私は、この二つを同じレイヤーのものとして捉えており、MVCとClean Architectureを並べて比較するような考え方をしていました。 本書を読んでから、例えば、「MVPでGUIを構築しつつClean Architectureでシステム全体を整理する」といった組み合わせの発想ができるようになりました。 実際にその後の業務で「MVP + Clean Architecture」という形に取り組み、本書で得た視点を現場に持ち込めたのは大きな収穫でした。 特に印象に残った部分 第2部のまとめ「アーキテクチャの選定基準」に書かれていた次のような問いかけが、強く印象に残っています。 なんとしてでもClean Architectureを採用すべきでしょうか。 どんなアーキテクチャパターンを採用するとしても、そのパターンの経験があったり、パターンに精通していることが望ましいです。 アーキテクチャパターンが目的になっていないか これらは、当時の私の悩みに正面から答えてくれる内容でした。 Clean Architectureを採用したプロダクトをリリースした直後に本書を読んだこともあり、チームでパターンへの精通が揃わないまま走り切ってしまったことを、ページをめくるごとに痛感させられました。 本来であれば設計を選ぶ前に向き合うべきだった問いを、後追いで突きつけられている感覚です。 iOSに限らず、アーキテクチャ選定の場面では常に心に置いておくべき視点だと感じています。 長期的な開発・保守・運用まで見据えて選ぶことの大切さを、自身の反省と重ねて受け取った章でした。 このような方におすすめ これから、あるいは今まさにiOSアプリのアーキテクチャ設計に取り組むエンジニアにおすすめの一冊です。 iOSアプリのアーキテクチャを体系的にまとめた書籍は今でもそう多くないため、最初に手に取る一冊として機能すると思います。 また、iOSに限らずアーキテクチャの歴史や系譜に興味がある方にも価値のある内容です。 発売から7年近くが経つためTCAは扱われていませんが、TCAにつながるFluxの解説があり、現在のiOS開発の文脈でも参考になる部分は多く残っていると感じています。 最後は、事業推進でカンファレンスサービスを開発している山田さんです。山田さんが選んだのは、世界トップクラスのエンジニアの思考プロセスを言語化した一冊。AIコーディングエージェントが日常になった今だからこそ、再読の意味が増した本について語ってもらいました。 ■ 山田 / フルスタックエンジニア ■ ファインディ株式会社でフルス
- Rails
- iOS
- アジャイル
AI-DLCをClaude Skill化して「エンジニアの役割越境」を実現した話
はじめに こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（TENTEN11055）です。 普段はチームで Findy Context というプロダクトの開発に取り組んでいます。 prtimes.jp 2025年11月、AWS主催のAI-DLC Unicorn Gymに参加し、AI駆動開発の手法であるAI-DLCを実践しました。 学びはとても大きかった一方で、自分たちのチームにそのまま持ち込むには壁もあり、現場の実態に合わせて作り変える必要がありました。 Unicorn Gym参加時の様子はこちら。 tech.findy.co.jp AI-DLCはAIが作業を実行し、人間が監視と判断に集中する開発手法です。 要件・ストーリー・作業単位を整理するInception、設計・実装・テストを進めるConstruction、IaCやデプロイを担うOperationの3フェーズで構成され、AIが提案する成果物をチーム全員で検証しながら進めます。 チームではそのうち実装に関わるInceptionとConstructionの2フェーズを採用しました。 詳細は次の記事を参照ください。 aws.amazon.com この記事ではAI-DLCをClaude Skill化し、Epic制開発フローの中で要件整理からテストまでを一人のメンバーが一貫して担えるようにした取り組みを紹介します。 はじめに チームが抱える課題 担当領域越境の必要性 AI-DLCをそのまま取り入れる難しさ Epic制開発フローの導入 AI-DLCの2フェーズと付随する作業をClaude Skill化する 1. フォーマットのばらつきが改善 2. 横展開を容易にする 3. ツールを利用してよりシームレスな設計ができる 4. 付随するスキルの精度が上がり、人間の負担を下げる スキル運用後の効果とまとめ チームが抱える課題 これまではPMやデザイナー、QAエンジニアといった専任者と分業する形で開発してきましたが、チーム構成の変化により、エンジニア自身が担当領域を越境していく必要が出てきました。 担当領域越境の必要性 チームのフロントエンド専任者が一人のため、フロントの設計・実装を全て頼るわけにもいきません。 また4月末でQAエンジニアが別プロダクトへ異動となり、実装者のみでのテスト設計、ケース実装を担うことになりました。 さらに専任のPMも他プロダクトを兼務しており割ける時間が限られるため、要件整理など本来PMの領域だった部分にも開発者が踏み込んでいく必要があります。 これらを加味し、エンジニア一人一人が担当領域を広げる必要が出てきました。 AI-DLCをそのまま取り入れる難しさ そこで越境を支援する手段として、これまで個々人で自由に行なっていたAI-DLCをチームの開発フローとして取り入れることを検討しました。 しかしInceptionフェーズは関係者が集まって仕様を決めていくスタイルであり、その実施には一定の同期コストが発生します。 作りたい機能の具体が曖昧であればあるほど全員参加は効果的になりますが、Epicイシューが作成された段階で既に一定の解像度がある場合は、PMも含め全員で擦り合わせをすると、得られる解像度向上に対して投入する時間（チーム全体の同期コスト）の方が目立ってしまいます。 Epic制開発フローの導入 これらの課題を解決する一環としてチームではEpic制を導入しました。 こちらはVPoEのhamさんがFindy Team+開発で実施した個人アサインへのシフトに影響を受けています。 tech.findy.co.jp 各Epicにメンバーをアサインすることで要件整理から開発まで一貫して責任を持つようになり、ボトルネックも発生しづらくなります。 実際の運用としては、大まかに次の流れで開発を進めています。 Epic担当者はAI-DLCスキルを用いてInceptionドキュメントを作成する ワイヤーフレーム作成スキルに1のドキュメントを読み込ませ、HTMLでワイヤーを作成する 1と2を元にデザイナーとPMに確認をとる AI-DLCスキルでConstructionドキュメント、テスト設計、テストケースを実装する デザイン、実装、テスト 受け入れ確認、リリース チーム内ではこれらを用いたフローをAI-E-DLC (AI - Epic - Driven Development Life Cycle)と名付けており、今後も運用と改善を重ねていこうとしています。 ここからはこのフローの1と4で利用するAI-DLCスキルについて掘り下げていきます。 AI-DLCの2フェーズと付随する作業をClaude Skill化する 同じプロンプトを用いてドキュメントを作成しても、AIの成果物にはばらつきが生じる可能性があります。 そのためAI-DLCにおけるInceptionとConstructionのドキュメント生成をそれぞれスキル化し、潜在的な課題をいくつか改善することができました。 1. フォーマットのばらつきが改善 同じAI-DLCのプロンプトを使っても、書き手によって構成・粒度にばらつきが生じたり、必要な情報が抜けたりすることで、実装・テスト設計・レビューなどの工程でAIが読み取りにくいドキュメントが生まれていました。 この課題に対し、スキルで手順と出力フォーマットを固定し、誰が実行しても同じ骨格のドキュメントを出力できるようにしています。 ちなみにこのフォーマットの固定化が多くの改善の起点になっており、これなしでは後述の内容も実現しえませんでした。 2. 横展開を容易にする AI-DLCの手法を各メンバーが再現するには、フェーズ理解・プロンプト設計・観点整理の習熟が必要であり属人化しやすいものですが、スキル化により手順がガイドされるため、未経験者でも気軽に実践できる「型」として提供できます。 またFindy Contextが複数リポジトリで構成されるため、リポジトリ非依存で動くスキルにしています。 今まで各リポジトリに合わせたプロンプトを用意する必要がありましたが、どれにおいても同じスキルを呼べばOKな状態にしています。 汎用性の高いスキルにすることでどこでも誰でもAI-DLCに則ったドキュメントを作成できるようになりました。 3. ツールを利用してよりシームレスな設計ができる AIからの質問事項にはClaude CodeのAskUserQuestionツールを必ず利用させています。 InceptionではAIから人間への質問フェーズが存在し、ドキュメントに記載された質問に対し人間が回答を書き込むのが基本でした。 これに対し選択 or 自由回答という形式をとり回答候補を提示してもらうことで一から考えることがなくなるため、回答作業だけでなく脳の負担も軽減されました。 他にも一部の難易度の高い作業をAgentに任せるなど、場面に適した設定を共有できるのもスキル化の利点の一つです。 AskUserQuestionを利用した際のサンプル 4. 付随するスキルの精度が上がり、人間の負担を下げる フォーマットのばらつきが改善されたことにより、専用のテスト設計・ケース実装スキルとドキュメントレビュースキルも作成することができました。 テストをAIで用意する際、何を材料とするかが重要です。 もしコードを材料とした場合、そのコードが仕様に沿っていなければ誤ったテストとなってしまいます。 このテスト設計・作成スキルはInception・Constructionドキュメントを材料とし、エンジニア・PM・デザイナー間で認識が揃った仕様を前提とするため高い精度を出すことができます。 またドキュメントレビューに関してはAI-DLCの中で最も人間の負荷が高い作業です。 AI-DLCスキルで生成されるドキュメントは10ファイルを超え、全部均等にレビューしようとすると破綻します。 そこでレビュースキル側で、生成されたドキュメントを「核となるドキュメント（仕様の中核を担うもの）」と「補助となるドキュメント（核を支える補足）」に分類し、Epicイシューとも照らし合わせて齟齬や抜けがないかをチェックさせています。 これにより人間が熟読すべきドキュメントを明確にし、レビュー負荷を下げることができました。 スキル運用後の効果とまとめ 運用を始めて数日が経ちましたが、想像以上に強力なスキルとフローであると感じています。 チームの課題でもあった「役割の越境」に対して有効なアプローチとなり、これまで専任者（PM・デザイナー・QAエンジニアなど）に頼っていた作業の下地を実装者が担い、専任者はレビュー・判断に集中できるようになりました。 習熟度の壁を下げられたことも大きな成果で、スキル作成後に説明する場を設けなくても気づいた時には他メンバーが使っており、数日後にはスキルの改善PRも上げてくれていました。 レビューにおいてもAI-DLCを始めた頃によくあった「ドキュメントレビューしんどい...」という声は幸いまだ聞こえてきていません。 今回の取り組みはAI-DLCをそのまま導入するのではなく、チームの開発体制や課題に合わせて適応させる試みでした。 まだ運用を始めて間もないため改善の余地はありますが、その部分に誰もが参加できる間口を用意できるのもスキル化の利点かもしれません。 ファインディでは一緒に働くメンバーを募集中です！ よかったら覗いてみてください。 herp.careers
- 生成AI
- Claude
- プロダクト開発
- QA
Dev-Bizの壁を、可視化で越える — DevOpsDays Tokyo 2026 参加・登壇レポート
こんにちは、ファインディのCTO室でスタッフエンジニアを担当している及川(@rojoudotcom)です。 4月14日(火)〜16日(木)にDevOpsDays Tokyo 2026が開催されました。本記事は、スポンサー登壇者として参加してきたレポートです。 DevOpsDaysは、世界各地で開催されるエンジニア向けの国際カンファレンスです。 開発（Dev）と運用（Ops）の連携、自動化、組織文化、最新の事例やプラクティスを発表しています。日本ではDevOpsDays Tokyoとして、年に1回開かれています。 本記事では、開発組織の成果を経営層にどう伝えたらいいのかを悩まれている方や、AIを導入したのに成果が見えないと感じる方に向けて書きました。3日間のイベント参加を通じて改めて確信した「可視化は組織が動き出すための前提条件である」というメッセージを、登壇・基調講演・現地での会話の3つの角度から振り返ります。 開発組織は、経営から「見えない」 成果を見やすい形で可視化すれば、見える投資に変わる 経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 組織設計に意図を持つことで組織の活動が見える 成果を見る側に立って翻訳する 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 可視化がない改善は、AIに増幅されない 「可視化されてはじめて、人は動く」 おわりに 開発組織は、経営から「見えない」 DevOpsという言葉についてのおさらいですが、もともと「DevとOpsの壁を壊す」ことから始まりました。コンテナ、CI/CD、SREといった方法論が広まり、Dev-Ops間の景色が変わったと感じる方は多いと思います。 一方で、Devと経営(Biz)の間の壁は依然として高いままではないでしょうか。 開発部門が作るソフトウェアは形がなく、損益計算書には給与や販管費などの「費用」としてしか記録されません。経営層の関心は売上向上や費用削減にあるのに対して、開発の関心は製品開発におけるリリース頻度の向上やリードタイム削減にあります。お互いが重要だと思う指標が異なることが、すれ違いを生み続けていると考えています。 成果を見やすい形で可視化すれば、見える投資に変わる 今回の登壇では、ファインディ以前に在籍していた現場の事例を話しました。経営層から状況が見えないと言われていた開発組織を意図を持って再設計し、活動の良し悪しを計測したことで投資の判断ができる状態とした体験談です。 テーマは「Dev-Bizの壁をどう越えるか」。20分のスポンサーセッションで持ち時間は短かったものの、自分の問題意識を言語化する貴重な機会になりました。 経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 私が過去に在籍していたある企業の開発部門の話です。配属された開発部門は発足から20年が経つ自社サービスを担当しており、内製化を進めていたところでした。歴代の担当者は退職済みで、ドキュメントもなく、現場の判断は開発担当者の属人的なナレッジに委ねられていました。 エンジニアリングマネージャとして組織の状況を把握するために現場関係者にヒアリングを始めると、様々なことが見えてきました。 まず、組織のサイロ化が進む仕組みが見えてきました。開発に関わるメンバーはプロジェクトの終了と共に解散するため組織ナレッジが溜まりにくいこと、そして新機能開発チーム（Dev）と運用改善チーム（Ops）は分断されており、特にOpsチームに届けられる改善要求は、その背景が不透明なまま改修が行われていました。 次に、受け身の文化が根付いていました。歴史的に要求は事業部が作成し、開発側は要求を待つ立場だったためです。さらに、上位下達の関係性から、開発側からの提案や意見を出しづらい状況でした。 最後に、経営層からすると、PLやBSの数字以上に開発の状況が見えない状態が続いていて、それ以上踏み込めない状況が習慣化されていました。リソースをどこに集中すべきか、開発予算は適正なのかの判断ができない状況でした。 組織設計に意図を持つことで組織の活動が見える 見えない状態は、組織の設計に「なぜそうしたか」の意図がないことが原因です。最初の取り組みとしてTeam Topologiesで組織体制を再設計しました。すると、顧客の要望がどこからきてどこに流れていくのか（バリューストリーム）を見えるようになり、それぞれの開発チームの責任範囲やチーム間の関係性も明確になりました。 組織の枠組みが整ったところで次はチームの中身（マインドセットや運用ルール）です。アジャイル開発のスクラムフレームワークを導入し、自己管理化を進めていきました。チーム自身が開発案件の優先度や実現方法を話し合うようになりました。さらに、システム的観点から事業部の要望に対する逆提案が生まれるようになりました。 そして、新体制が動き出してきたところでFindy Team+を導入し、開発チームのリードタイムやボトルネックを可視化し、定量的なデータを取り始めました。半年後にはリードタイムが従来比8割短縮、デプロイ頻度も3割増加し、経営層に対しても改善を数字で示せるようになりました。 成果を見る側に立って翻訳する Four Keysによる開発活動の成果や、新機能が完成したときに得られるであろう期待される売上やコスト削減効果は重要な数字ではありますが、経営層が理解するにはもう一歩踏み込む必要があります。 例えば開発生産性が向上したことで稼働可能な人月が増えたと同等の効果と捉えれば、管理会計の項目のどこに増減の影響が生まれるのか。あるいは、リリース回数が増えたことで事業計画がどの程度短縮できるのか。こうした情報は決算書にも書けるような話題で、経営層にとって必要な情報です。 このように、投資判断を行う経営層の立場に立ち、開発の活動を翻訳して伝えることで、ようやく開発部門に対する投資判断の議論ができるようになりました。 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 以上、目の前の問題の直接解決ではなく、問題を生み出す構造（仕組み・文化・習慣）に目を向けて根本解決を促すストーリーでした。 さらに詳しい内容はスライドをご覧いただけるとうれしいです。 見えない開発現場を、見える投資に変える — Speaker Deck 可視化がない改善は、AIに増幅されない 「可視化が大事」とは言われ続けてきました。それでも今このテーマで登壇しようと思ったのは、AI時代に入って、その重要性が以前にも増して大きくなっていると感じていたからです。そして、その直感はカンファレンスの基調講演で裏付けられました。 Google CloudでDORA（DevOps Research and Assessment）プログラムを率いるNathen Harvey氏によれば、2025年の調査でAI採用率は90%に達したそうです（前年比＋14%）。 一方で、コード品質や個人の生産性は上がったものの、ソフトウェアデリバリーの安定性は悪化していました。Harvey氏はこの現象を踏まえて、AIの役割を「増幅器（amplifier）」と表現していました。良いシステムには良い結果を、悪いシステムには悪い結果を増幅するものという意味合いです。 この比喩がしっくり来たのは、増幅されるためにはまず「何が起きているか」が見えていなければならない、という当たり前の前提が浮かび上がるからです。 可視化されていないデータをAIに与えてもノイズを増幅するだけです。可視化されていない開発組織は、AIを入れても何が良くなったのか悪くなったのかすら判断できません。 AI採用は、可視化された土台の上ではじめて成果に結びつく 基調講演から受け取ったメッセージはそこに集約されていました。 そして、もう一つの基調講演でDevOpsムーブメントの礎を築いた一人であるAndrew Clay Shafer氏が残した「行動を変えるまでは、何も学んでいない」という一言も、同じことを別の角度から言っていると感じました。見えなければ学ぶことはできないですし、闇雲に行動することになります。それは学んでいないのと同じことです。 ここで触れた2つの基調講演のセッション情報は次のとおりです。 confengine.com confengine.com 「可視化されてはじめて、人は動く」 3日間で一番心に残ったのは、技術的な議論ではなく、夜の懇親会で交わした一つの会話でした。 懇親会で日本酒を参加者に勧めていたとき、たまたまDay1の基調講演スピーカーのNathen Harvey氏が近くにいました。興奮して握手を交わし自己紹介をすると、彼は「ファインディのプロダクトを見せて欲しい」とリクエストしてくれました。 その場でブース担当者を呼んで、開発生産性可視化のデモをしました。彼はそれを見終えた後、こう言いました。 可視化することで、ようやく人は動き出すんだよね。 自分の登壇で伝えたかったことも、基調講演で語られていたDORAの研究も、3日間で出会った人たちが共有していた問題意識も、この一文で言い表されていると感じました。 Four Keysのような生産性指標で内側の現在地を、DORAのような調査レポートで外側の方向性を捉え、両者のギャップを埋めていきます。 可視化はゴールではなく、組織が動き出すための出発点です。 Dev-Bizの壁を越えるにも、AIを増幅器として活かすにも、共通してまず見えていることが要ります。これが3日間を貫いていたメッセージでした。 翌日のスピーカーインタビューのアイスブレイクで「日本に来てどうですか？」と聞かれたHarvey氏が「ファインディに会えたことが思い出になった」と答えてくれたのは、嬉しいおまけでした。 おわりに 開発組織を率いるマネジメント層にとって、可視化は「あれば便利な機能」ではなく「動き出すための前提条件」だと、今回の3日間で改めて確信しました。当社は指標を計測するサービスを提供する側だからこそ、組織を歪ませない設計に責任があると、身が引き締まる思いです。 DevOpsDays Tokyoに参加することで、スピーカー同士、運営の方々、そして海外登壇者との繋がりをつくることができ、DevOps文化に貢献したい気持ちも高まりました。来年の開催も楽しみにしています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- DevOps
- 開発生産性
- Team Topologies
【ソフトウェア開発現代史】継続的デリバリーができない組織でAIは増幅器(amplifier)として空回りを生む 〜Dave Farley氏の来日に寄せて〜
ソフトウェア開発現代史年表Ver2.08 はじめに デリバリーは速ければよいのか 改めて、Four Keysは何を測っているのか 「デプロイ」と「リリース」の混同がFour Keysを遠ざける Dave Farley氏とは 『Continuous Delivery』(2010) は何を変えたか 二つの意味を持つ「リリース」 AI時代に、継続的デリバリーはなぜ重要になるのか AI駆動開発を空回りさせないために 【告知】AI DevEx Conference 2026 - Future of Development Productivity - おわりに はじめに こんにちは。テックブログ編集長の高橋（@Taka-bow）です。 冒頭に掲載した「ソフトウェア開発現代史年表Ver2.08」は、ソフトウェア開発の考え方がどのように変化してきたのかを、できるだけ一枚で見渡せるように整理したものです。 この年表の中に、2010年の『Continuous Delivery』があります（赤枠）。 Jez Humble（ジェズ・ハンブル）氏とDave Farley（デイビッド・ファーリー）氏によるこの本は、CI/CDやFour Keysを考えるうえで、出発点にあたる一冊です。 本記事では、この『Continuous Delivery』を起点とする流れを取り上げます。 生成AIによって、コードを書く速度は大きく上がりました。AI駆動開発という言葉も広がり、実装からデプロイまでの時間はますます短くなりました。 しかし、ソフトウェアを速く作れることと、価値あるものを継続的に届けられることは、同じではありません。 そこで今回は、Dave Farley氏の初来日に寄せて、AI駆動開発を機能させる土台としての継続的デリバリーに焦点を当てます。 Dave Farley氏が築いてきた継続的デリバリーとは何か、それがDORA Metricsとどうつながっているのか、そしてAI時代にこの思想がなぜいっそう重要になるのかを整理します。 デリバリーは速ければよいのか むかし、その場しのぎの言い訳や曖昧な返答を「蕎麦屋の出前じゃないんだから」とたしなめる言い回しがありました。そんな比喩が通じるほど、かつての出前（デリバリー）は「遅くて当てにならないもの」と見られていたのでしょう。 いまは違います。Uber Eatsやmenu、出前館のような専門サービスが増え、マクドナルドのように飲食店自身が届けてくれることも当たり前になりました。 「ピザのデリバリーは30分以内」。そんなイメージを持っている人も多いのではないでしょうか。速く届くこと自体が、ひとつの価値になっています。 しかし、30分で届いたピザでも、冷めきっていたり、注文と違うものが届いたりしたらどうでしょう。速く届いたかと、価値あるものが届いたかは、別の問いです。 ソフトウェアの「デリバリー」も同じです。 私たちエンジニアにとってのデリバリーといえば、CI/CDの「CD」、すなわちContinuous Delivery＝継続的デリバリーです。文字どおり、「ソフトウェアの価値」を「継続的」に「届ける」ことを指します。 近年は生成AIの登場によって、実装からデプロイまでの流れが目に見えて速くなっています。ソフトウェアの「デリバリー時間」が短くなっていることは、多くの現場で体感されているはずです。 ただし、速さはソフトウェアのデリバリーパフォーマンスの一面にとどまります。フードデリバリーと同じく、速く届くことと、価値あるものが届くことは別の話です。 この前提に立つと、Four Keysの見え方も少し変わってきます。 改めて、Four Keysは何を測っているのか ソフトウェア開発のデリバリーパフォーマンスを測る指標として、Four Keys、および現在のDORA Metricsが広く知られています。 これは、継続的デリバリー（Continuous Delivery）が重視してきたソフトウェアデリバリーの能力を、計測可能な指標として捉えようとするものです。DORA Metricsを理解することは、継続的デリバリーが目指すものを理解することに直結します。 一方で、お客様と話しているとこんな声をよく耳にします。 「我々にはFour Keysのような計測手法はしっくり来ません。なぜなら、アジャイルみたいに何度もリリースしたりしないんです」 この疑問を考える前に、まずDORAが現在「ソフトウェアデリバリーパフォーマンス」をどう捉えているかを整理しておきましょう。 DORAにおけるソフトウェアデリバリーパフォーマンスの構造 DORAは近年のレポートで、「ソフトウェアデリバリーパフォーマンス」を2つの軸に整理しています。 ひとつは「ソフトウェアデリバリースループット（software delivery throughput）」、つまり、スピードと効率性の軸です。次の3つで測ります。 変更リードタイム（change lead time） デプロイ頻度（deployment frequency） デプロイ失敗時の復旧までの時間（failed deployment recovery time） もうひとつは「ソフトウェアデリバリーの不安定性（software delivery instability）」、これは、品質と信頼性の逆指標（低いほど良い）です。次の2つで測ります。 変更時の障害率（change failure rate） やり直し率（rework rate） 旧来の「Four Keys」（2018年頃）はデプロイ頻度・変更リードタイム・変更時の障害率・サービス復旧時間の4指標でしたが、現在のDORAでは5指標を「スループット」と「不安定性」の2軸に整理し直しています。 この再整理は、DORAがソフトウェアデリバリーを単なる速さではなく、速さと不安定性の両面から捉えようとしていることを示しています。AI駆動開発によってコードの生成量や品質の傾向が大きく動くいま、この見方はますます重要になっています。 次に、これらの指標がSDLC（ソフトウェア開発ライフサイクル）上のどこに当てはまるのかを見てみましょう。 DORA MetricsがSDLC上のどこに当てはまるかを示した図 この図でまず見てほしいのは、デプロイとリリースの位置関係です。デプロイはSDLC上のひとつのフェーズであり、リリース（図中の▼）はそのあとに位置します。 DORA Metricsのうち、頻度として測るのはリリース回数ではなくデプロイ頻度です。ここを取り違えると、「リリース回数が少ない自分たちにはFour Keysは合わない」という違和感が生まれます。 実際、デプロイとリリースをひとまとまりのイベントとして扱う現場も少なくなく、歴史の長い組織ほど、その傾向が根強い印象です。 しかし、DORA Metricsが見ているのは「ユーザーに何回公開したか」ではなく、「変更をどれだけ継続的に本番へ届けられているか」です。図の中でリリースが何度も登場している理由は、後の章「二つの意味を持つ『リリース』」で詳しく扱います。（ここではまず、DORA Metricsは「リリース回数」ではなく、変更をどれだけ速く、安定して届けられているかを捉える指標だと押さえてください。） また、最近はAI駆動開発が広まるにつれて、こんな声も聞くようになりました。 「AI時代にFour Keysは合わないですよね」 この見方も、少し立ち止まって考える必要があります。 生成AIは、とりわけ実装・テストのフェーズを大きく速くします。さきほどの図で見たとおり、実装・テストはデプロイの手前にあります。ここが速くなれば、その変化は下流のデプロイや、DORA Metricsの「変更リードタイム」にも表れます。 もちろん、速くなるのは良い面だけではありません。 生成AIが出力したコードを鵜呑みにすれば、欠陥を見逃すリスクも高まります。その影響は、DORAがいう「ソフトウェアデリバリーの不安定性（software delivery instability）」（やり直し率や変更時の障害率）にも現れます。 つまり、生成AIはDORA Metricsを不要にするどころか、数値を大きく動かします。 だからこそ、DORA Metricsが何を測っていて、何を測っていないのかを理解する必要があります。その理解の出発点が、「デプロイ」と「リリース」の違いです。 次章では、Four Keysへの違和感を生みやすいこの混同を、もう少し丁寧にほどいていきます。 「デプロイ」と「リリース」の混同がFour Keysを遠ざける Four Keysへの戸惑いは、AIが現れるよりも前からあります。 その大きな理由のひとつが、「デプロイ」と「リリース」という二語の混同だと思っています。まずは、この二つを分けておきましょう。 デプロイ（Deployment） リリース（Release） 意味 コードや設定を本番環境に反映する作業 機能をユーザーが実際に使える状態にする判断 性質 機械的・技術的（自動化が可能） ビジネス判断（公開タイミングをコントロール） 頻度 高頻度（日次・時間単位もありうる） 機能ごと・公開戦略次第 ところが、多くの現場ではこの二つが切り離されず、ひとつの大きなイベントとして扱われています。デプロイもリリースも「めったに行わない重い作業」になっていれば、Four Keysが自分たちとは無縁に見えてしまうのも当然の感覚です。 たとえば、ゲートキーパー型のQAを置き、「リリース判定会議」を経て本番に出す流れです。この場合、現場の感覚としては「リリース判定会議 → デプロイ」の順序に見えます。 昔のリリース候補マイルストンも、何ヶ月もかけて次の段階へ進めていく形でした。 flowchart LR A["プレアルファ版<br/>(pre-α)"] --> B["アルファ版<br/>(α)"] --> C["ベータ版<br/>(β)"] --> D["リリース候補版<br/>(RC)"] --> E["ゴールドリリース版<br/>ゴールデンマスター版<br/>(GM)"] これは、ソフトウェアが物理パッケージで出荷されていた時代の名残でもあります。CD-ROMを焼き（書き込み）、紙のマニュアルを同梱して箱に詰める。バグが見つかればディスクの焼き直し、マニュアルにミスがあれば製本のやり直し⋯⋯手戻りは、時間とコストの両面で致命的なダメージでした。 しかし、時代は変わりました。高速なネットワーク、パワフルなPC、ストレージの大容量化、紙媒体の電子化⋯⋯やり方を過去のままにしておく理由は、もうありません。 それでもこの流れを前提にしていると、リリースとデプロイの適切なタイミング、順序、そして頻度の感覚は分からないままです。 この混同をほどき、「リリース」の二つの意味を分離する考え方を体系化したのが、Jez Humble氏とDave Farley氏です。 Humble氏はその後、DORAの設立メンバーとして、DORA Metricsの礎を築いていきました。今回は、もう一人の著者であるDave Farley氏にスポットを当てます。 Dave Farley氏とは Dave Farley氏は、継続的デリバリーを語るうえで避けて通れない人物です。 David(Dave) Farley(Image source: InfoQ.com) Jez Humble氏との共著『Continuous Delivery』（2010、Jolt Award受賞）は、CI/CD、デプロイメントパイプライン、デプロイとリリースの分離といった考え方を広め、現代のソフトウェアデリバリーの前提をつくった一冊です。単著『Modern Software Engineering』（2021）でも、ソフトウェア開発をエンジニアリングとして捉え直す考え方を示しています。 DORA Metricsも、この継続的デリバリーの思想と地続きにあります。つまりFarley氏は、「継続的デリバリーの本を書いた人」にとどまらず、現在のソフトウェアデリバリーの議論そのものに影響を与えてきた人物です。 Farley氏の言葉に重みがあるのは、実践の現場でも大きな仕事を残してきたからです。 低レイテンシシステムの分野では、Duke Awardを受賞したオープンソースプロジェクト「LMAX Disruptor」に貢献しています。並行処理や高スループットの設計を語る場面で、いまも参照され続ける仕事の一つです。 さらに、応答性や回復性、弾力性を重視する「リアクティブシステム」の考え方を示したReactive Manifestoの共同執筆者でもあります。 近年はYouTubeチャンネル「Modern Software Engineering」（旧名Continuous Delivery）の主宰者として、世界中のエンジニアに継続的デリバリーやモダン・ソフトウェアエンジニアリングの考え方を発信し続けてきました。チャンネル登録者数は26万人を超えています。 <cite cla
- デジタルトランスフォーメーション
- 生成AI
- アジャイル開発
TSKaigi 2026に協賛・参加しました 〜TypeScriptエコシステムのNative化を感じた注目セッション〜
こんにちは！ファインディの大石（@bicstone）、甲斐（@karukan013L23）、千田（@_c0909）です。先日、ファインディはベルサール羽田空港で開催された「TSKaigi 2026」に協賛しました。 今回はDevRelメンバーとフロントエンドエンジニア3名で参加し、ブース運営を行いました。本記事ではTSKaigi 2026において印象深かったセッションの紹介や登壇、ブース出展などの活動内容を紹介します。 ブースで実施したユーティリティ型アンケートの集計結果（480票）も後半で公開していますので、ぜひ最後までお読みください。 TSKaigi 2026について 印象深かったセッション 【大石】TS 7: How We Got There 【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？ 【大石】CfP登壇: TypeScript 6.0での型推論修正を追う ファインディの活動 アンケート結果 さいごに お知らせ TSKaigi 2026について TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。東京都大田区のベルサール羽田空港にて、2026年5月22日(金)〜23日(土)に開催されました。 2026.tskaigi.org 印象深かったセッション 興味深いセッションが多くありましたが、その中でも3名それぞれが印象に残ったセッションを紹介します。 【大石】TS 7: How We Got There 2026.tskaigi.org TypeScriptチームのJake Baileyさんによる、TypeScript 7をGo言語へ移植した経緯と成果についての基調講演です。 特に印象的だったのは、Goを採用した理由を体系的に知ることができた点です。 JavaScriptではスレッド間でオブジェクトを共有できず、async/awaitが関数全体に伝播してしまうため、並列化が困難でした。 Goのgoroutineを活かすことで、Parse・Bind・Emitの各フェーズを並列化し、Checkerも複数並べることで高速化を実現しています。 VS Code (Electron) のプロジェクトをtscとtsgoそれぞれで実行した際の所要時間とCPU使用率の差を見せていただいたデモでは、マルチスレッドの活用やCPU使用率の変化が一目で分かり、なぜ大幅な高速化を実現できたのか直感的に理解できました。 発表のなかで繰り返し強く呼びかけられていたのが、コミュニティからのフィードバックでした。「ぜひbetaやnightlyを試してほしい」「VS CodeのNative Preview拡張を入れてほしい」「クラッシュやコンパイル挙動の変化、特にAPIへの意見を送ってほしい」と呼びかけていました。 過去1年でコミュニティから1141件のIssueと1487件のマージ済みPRが寄せられ、テレメトリ経由のクラッシュ情報も含め、利用者からの報告が開発の方向性を支えていることが伝わってきました。 私たちのチームでは、すでにコミット時のフックでtsgoを試験的に採用しています。今後は開発フロー全体への導入を進めながら、検知した問題は積極的にフィードバックを送っていきたいです。 ファインディでも従来からOSSへのIssue起票やPull Requestの作成、メディア企画を通じた寄付などの形で支援を続けてきましたが、TypeScriptのように多くの利用者を抱えるプロジェクトでは、利用者一人ひとりの報告こそが大きな貢献になることを再認識しました。 これまで断片的にしか追えていなかったTypeScript 7について体系的に理解でき、とても学びの多い発表でした。社内にもぜひ共有していきたいと思います。 【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 2026.tskaigi.org Denoのmaguroさんによる、DenoのTypeScript基盤をtscからtsgoへ移行する取り組みについてのセッションです。 元々DenoはTypeScriptをフォークしたパッケージを使用し、Deno Rust側と必要な情報をやり取りし、Deno固有の概念をtscが解釈できるよう、tscにパッチを当てたものをDeno binaryの中に埋め込んでいました。 tsgoへの移行の最初のアプローチはtsgoをフォークし、Deno固有の概念をtsgoに渡せるようにするアプローチでした。 tsgoはDeno固有の概念をそのまま解決できないため、Deno Rust側で処理できるよう対応しています。LSP対応のコスト、フォークしたパッケージのメンテナンスコストが高く、現在はフォーク版ではなく公式のTypeScriptパッケージを利用するアプローチが試みられています。 TypeScript向けにDenoの依存と型をローカル生成することで、パッチを当てずにDeno固有の概念を解釈できる構成にしています。 特に印象的だったのは、DenoのWeb標準の哲学を少し曲げてでもTypeScriptで扱える形に寄せていった点です。Deno binaryの中→Deno binaryの外→Deno projectの外へTypeScriptパッケージが押し出されており、フォークによる運用コストの増加を避けつつ実行可能なアプローチをとっています。 型チェックを使用したい他のライブラリも同様にフォーク以外の選択肢を模索しており、方向性は同じだがそれぞれ異なるアプローチになっていることが興味深かったです。 普段Denoは使用していませんでしたが、現在の形に辿り着くまでにどのような意思決定があったかを見ていくことで、ここに至るまでの課題や意思決定ごとのトレードオフを学ぶことができ、現在の思想を理解する助けとなりました。 今後もツールチェーンやライブラリの意思決定の背景を学ぶ機会を定期的に設けていきたいなと思います。 【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？ 2026.tskaigi.org 株式会社うるるの藤田翔雅さんによる、OxlintがESLint / typescript-eslintをどこまで置き換えられるのかを整理したセッションです。 特に印象的だったのは、Type-Aware Linting（型情報を使ったLint）の有無でパフォーマンスが大きく変わる点をベンチマークで示していたことです。 型情報を使わない比較ではESLintの8.213秒に対しOxlintは0.304秒と約27倍速く、型情報を使うルールを有効にしてもESLintの16.121秒に対しOxlintは0.807秒と約20倍速いという結果でした。 型情報を使わないLintが構文解析だけで完結するのに対し、型情報を使うLintはプロジェクト全体の型グラフ構築（tsc/tsgo）を必要とするためボトルネックになる、という構造的な解説も理解の助けになりました。 導入判断についても踏み込んでおり、型情報を使わないLintであればOxlintは主要ルールを十分カバーしており移行は現実的である一方、oxlint-tsgolintによるType-Aware Lintingはまだ非安定版であること、カスタムルールを抱えるプロジェクトでは移行コストが上がることなど、現場目線のトレードオフが具体的に語られていました。 結論として、非Type-Aware LintingであればOxlintへの移行を推奨するというメッセージが明快でした。 私たちのチームでもESLint + Prettierを利用しており、CIの実行時間は継続的な課題です。すでにOxc系（Oxlint + Oxfmt）への移行を計画しており、既存のプロダクトはType-Aware Lintingに依存しない構成となっています。 本セッションの「非Type-Aware LintingならOxlint移行を推奨」という結論は私たちの状況に当てはまり、実際の移行計画に重ねて考える良い機会になりました。 【大石】CfP登壇: TypeScript 6.0での型推論修正を追う 当日のCfP枠では、大石が「プロパティの順序で型推論が壊れる!? TypeScript 6.0の修正からContext-Sensitivityの仕組みを追う」というタイトルで登壇しました。 プロパティの記述順序を入れ替えるだけで型推論が壊れる挙動を入口に、TypeScript 6.0でマージされたPRの中身まで踏み込んだ内容です。詳細は別記事にまとめていますので、あわせてご覧ください。 tech.findy.co.jp speakerdeck.com ファインディの活動 ファインディはGoldスポンサーとして協賛し、ブース出展という形で支援しました。 ブースでは「よく使うユーティリティ型」をテーマにしたアンケート企画を実施しました。普段の開発でよく使うユーティリティ型を選んでいただく内容で、2日間かけて多くの方に投票いただきました。 TSKaigi2026始まりました！入口すぐです！お待ちしております🌟#TSkaigi2026 #tskaigi pic.twitter.com/ecf1Zzok0V— いわさき@Findy DevRel (@iwasakitchen) 2026年5月22日 x.com アンケートの最終結果はこちらになります。たくさんの投票ありがとうございました。 TSKaigi 2026改めて2日間ご参加いただき、ありがとうございました！よく使うユーティリティの「型」は？の最終結果です！😊🎊#TSkaigi #TSkaigi2026 pic.twitter.com/0Nt4xun2bQ— いわさき@Findy DevRel (@iwasakitchen) 2026年5月23日 x.com アンケート結果 総数：480票 順位 ユーティリティ型 割合 票数 1位 Record<Keys, Type> 33.3% 160票 <td st
- TypeScript
- Go
- Rust
- Deno
- ESLint
経験1年のエンジニアでも、新規プロダクトのEmbedded SREに初挑戦できた理由 — 仕組みと個人の学習で踏み出す
はじめに こんにちは、ファインディ株式会社でエンジニアをしている中嶋（@nakayama__bird）です。現在は、新規プロダクトであるFindy Contextの開発に携わっています。 ファインディでは、これまでSREチームが担っていた新規プロダクトのクラウド環境の構築から監視体制の整備までを、プロダクト開発チーム主体で行う体制に切り替えました。 本記事では、私自身がFindy Contextの環境立ち上げを担当した経験を、アプリケーションエンジニアの視点で振り返ります。 経験の浅いエンジニアにとって、0→1のクラウド環境構築は不安の大きい領域です。「自分にできるのか」と思いながら着手した私が前に進めたのは、「SREチームが整えてくれた仕組み」と「自分で進めた学習」、その2つが揃っていたからでした。 それぞれがどう機能したかを、これから体験ベースでお伝えします。 はじめに Findy Contextとは 背景: なぜ開発チーム主体に切り替わったのか これまでの体制 直近の事情の変化 方針転換: 開発チームメインの立ち上げへ 着手前の筆者スペック 委譲のスコープと私が担当した範囲 AWSアカウント発行とインフラ構築基盤整備 インフラリソースの構築 デプロイと運用の整備 監視（Datadog）の整備 個人として取り組んだこと 今後の伸び代 自分側 仕組み側（汎用モジュール・テンプレートへの改善余地） まとめ Findy Contextとは Findy Contextは、ファインディが2026年4月にリリースしたAI駆動開発支援プロダクトです。 プロダクト開発で日々生まれる文脈（過去のPR、関連議論、意思決定の経緯）をAIが資産化し、開発の調整コストを削減することを目指しています。 Findy Contextが目指すのは、特定の個人に依存せず、少人数でも高い開発能力を維持できる組織運営です。 あちこちに散らばっていた判断のプロセスを蓄積していくことで、組織の経験を資産として再活用できる土台を作っていきます。 findy.co.jp このFindy Contextの本番運用基盤を、なぜSREチームではなく開発チームが主体で構築することになったのか。その背景から振り返ります。 背景: なぜ開発チーム主体に切り替わったのか これまでの体制 ファインディにはSREチームが存在し、共通インフラやプラットフォームの運用、汎用モジュール・テンプレートの整備、セキュリティ・コスト最適化など、全社横断の取り組みを担っています。 インフラはTerraformでコード管理されており、SREチームが提供する汎用モジュールやテンプレートもTerraformで書かれています。オブザーバビリティの基盤としてはDatadogを採用しています。 また、既存プロダクトでは、プロダクトの一部メンバーがEmbedded SREとして、次のような役割を担っています。 アプリケーション開発に必要なインフラの整備・管理 モニタリングの整備 SLOの振り返り 一方、新規プロダクトの立ち上げに関しては運用が異なっていました。 SREチームが環境を構築し、ある程度の運用準備を整えてからプロダクト開発チームに引き渡す形が基本でした。 直近の事情の変化 ここ1〜2年で、事業成長や生成AIの追い風もあり新規プロダクトの立ち上げ件数が大きく増えたことで、これまでの体制で支えられる範囲を超えつつありました。 一方で、SREチームの人員を急に増やすことは難しく、既存プロダクトの運用や全社横断の取り組みも並行して走り続けています。新規プロダクトすべての環境構築をSREチームが担う体制は、現実的に維持できなくなりつつありました。 方針転換: 開発チームメインの立ち上げへ そこで、新規プロダクトの立ち上げ〜運用フェーズを、プロダクト開発チームが主体となり、SREチームがイネーブリングを担う体制へと切り替わりました。 これは、「開発側にオーナーシップを置く」というEmbedded SREの発想を、新規プロダクトの立ち上げフェーズにも広げた形と言えます。 SREチームが整備した汎用モジュール・テンプレート・イネーブリング体制を活用して、開発チームが自分たちの責任で立ち上げる。Findy Contextの立ち上げは、この新方針の第一弾として位置付けられたプロジェクトでした。 着手前の筆者スペック 未経験からファインディに入社し、当時は経験1年のエンジニアでした。業務の中でAWSの一部サービスを使うことはあっても、新規プロダクトの基盤として複数のサービスを組み合わせて構築した経験はありませんでした。0→1のクラウド環境構築は今回が初めてです。 そんな中、Findy ContextのEmbedded SREとして配置されることになりました。 開発チーム主体で環境構築を進める新方針のもと、その構築をメインの担当者として進めてほしいと依頼されました。 着手当初はそもそも「何から手をつければいいのか」が分からない状態でした。設計の手順も、優先順位も、判断基準が自分の中にありませんでした。 委譲のスコープと私が担当した範囲 まず、SREチームと開発チームの担当範囲を整理しておきます。 領域 SREチームが担当 開発チームが担当 AWSアカウント Organizations管理 アカウントの発行、発行後の初期設定 インフラリソース（ネットワーク・アプリケーション基盤） 共通方針、汎用モジュール・TerraformのCI/CDテンプレートの整備 汎用モジュールを使ったリソース構築（足りないものは個別作成）、CI/CD設定 監視（Datadog） Datadogの管理 ダッシュボード・モニター作成、運用 開発チームが引き受けた範囲は、SREチームが整備してくれた仕組みを使って自分たちで構築する、という形でした。 今回のFindy Contextの環境構築は、約2ヶ月をかけて、主にSREチームが事前に分解してくれた作業を順に消化する流れで進めました。ここからは、その流れを4つのフェーズに分けて振り返ります。 AWSアカウント発行とインフラ構築基盤整備 最初のフェーズは、Findy Context用のAWSアカウントを作り、Terraformで管理する基盤を整える作業でした。次のようなタスクです。 新規AWSアカウントの作成 HCP TerraformへのProject作成 Terraform用のGitHub Actionsワークフロー作成 ファインディには、SREチームが整備した初期セットアップ用のテンプレートがあり、Terraform用リポジトリの初期化はこのテンプレートで一気に進められました。 CI/CD・Docker・Trivy・TFLintなど、新規プロダクトに必要な基盤が一式揃った状態でスタートできます。 それでも詰まったのは、GitHub ActionsからAWSへのOIDC認証の設定でした。 Identity ProviderやIAM Roleの信頼ポリシーといった、IAM周りのポリシー理解が必要になります。IAMポリシーの仕組みをこれまで触る機会がなく、何をどう書けば期待通りの認証が通るのかが最初は全く分かりませんでした。 乗り越え方は、既存プロダクトのTerraformリポジトリを参考に、動いている設定を「型」として読み解くことでした。 特に初期は、SREチームの方と毎日ペアで作業する時間を持ち、レクチャーを受けたり質問を重ねたりしながら、自分の中に手順のイメージを作っていきました。 インフラリソースの構築 ここからが、Findy Contextのインフラを実際に組み立てるフェーズです。約1ヶ月かけて、次のようなリソースを順に構築していきました。 ドメイン / DNS Zone / 証明書（ACM） ネットワーク（VPC・サブネット等） コンテナ関連（ECSなど） データベース関連（RDSなど） 認証（Cognito） 配信（CloudFront） ここで強く助けられたのが、SREチームが整備した汎用モジュールです。汎用モジュールの整備については、別の記事で詳しく紹介されています。 tech.findy.co.jp ネットワーク・コンテナ・データベースなど、アプリケーション開発で標準的に必要なリソースは汎用モジュールが用意されており、変数を指定するだけで適切な構成が組み上がります。 「ベストプラクティスを毎回ゼロから調べる」必要がない状態でスタートできることは、学習コストを大きく下げる効果がありました。 それでも詰まったポイントが2つありました。 1つ目は、汎用モジュールにないリソースの作り込みやレビューです。Findy Contextでは、まだ汎用モジュール化されていないリソースを複数扱う必要がありました。 作成だけでなくレビューも、構成のイメージが頭の中にないと判断が難しく苦労した部分でした。AWS公式ドキュメントに加え、Claudeを活用して疑問に思った箇所を一つずつ理解していくアプローチで進めました。 2つ目は、リポジトリ構成とリモートステートの設計です。新規のリソースを作成する際、AWSのサービスごとに細かくstateを分割しようとしていたところ、SREチームから「リモートステートを多用しすぎない設計」をお勧めされました。 stateを分けるほど依存関係が複雑化し、apply順や terraform_remote_state の管理コストが増えるためです。アプリケーションエンジニア側のみで進めていたら気付けなかった視点で、SREチームのレビューを受けながら進められた価値を強く感じました。 デプロイと運用の整備 インフラリソースが揃ったら、次はアプリケーションをデプロイし、運用できる状態にするフェーズです。デプロイ用ワークフローの作成、Operationコンテナ環境の整備、Cognitoとアプリケーションの繋ぎこみなどを進めました。 ここで助けになったのは、既存の他プロダクトでしっかり整備されていたCI/CDフローでした。 tech.findy.co.jp デプロイの流れもOperationコンテナの構成も、基本的に「ゼロから設計する」のではなく「動いているフローを参考にする」アプローチで進められたのです。 SREチームと既存プロダクトを担当するエンジニアの両方に相談しながら、Findy Contextの構成に合わせた設計を組み立てていきました。 監視（Datadog）の整備 環境構築のクローズ後、別途取り組んだのが監視体制の整備です。Datadogでのダッシュボード作成、モニター（アラート）設定、ログ・メトリクスの収集設計、エラー検知の整備などを進めました。 SREチームが整備したDatadog基盤のおかげで、「Datadog自体をどう使うか」は迷わずに進められました。 このフェーズで一番大きな気付きは、監視や可視化はインフラ側だけでは完結しないということです。 例えばログ・エラー検知の領域です。エラーを正しく追跡できるようにするには、アプリケーション側で例外ハンドリングの設定を見直す、ログの出し方を整える、といった作業が必要でした。 「Datadogでエラーが見えない」という現象の根本原因が、Datadogの設定ではなくアプリケーションコード側にあるケースがありました。 詰まったポイントは2つです。 1つ目は、アラートの閾値とチューニングです。「何を、どの値を超えたらアラートを出すべきか」は、各サービスや時期に応じて判断が必要で、最初は誤検知が頻発したり、逆に本来検知すべき異常を見逃したりしながら調整を重ねました。 2つ目は、ダッシュボード設計とアプリ側のログ整備です。「何を載せるか、載せないか」「どんなログをどう出せば後で追跡できるか」は、メトリクスやログの選定だけでなく、アプリケーションの実装と表裏一体でした。 SREチームや既存プロダクトを参考にしつつ、Findy Contextのコードにも並行して手を入れていきました。 監視整備は、「インフラだけ知っていればよい」という認識を一番大きく崩した経験でもありました。可視化の基盤として、アプリケーション側の知識が必要だと、身をもって学んだフェーズです。 個人として取り組んだこと ここまで「仕組みが整っていた」という話を中心にしてきましたが、それだけで踏み出せたかというと、そうではありません。仕組みを活かすには、自分側でも一定の準備が必要でした。 私が並行して取り組んだのは、AWS認定ソリューションアーキテクト アソシエイト（SAA）の取得でした。 試験勉強の中ではAWS公式の「AWS Hands-on for Beginners」も活用し、書籍だけでは身につきにくい「実際にコンソールを触ってリソースを作る」感覚も合わせて身につけました。 SAAを通して、実際の業務で使うサービスだけでなく、AWSの主要サービスとアーキテクチャパターンを体系的に学べたことで、知識の幅が広がりました。 例えばコスト最適化のように、業務で直接深掘りしていない領域でも、「ここはもう一歩改善できそう」という気付きを得られる引き出しが増えた感覚があります。 「環境が整っていれば誰でも自走できる」わけではなく、整った環境を活かすための準備として、自分の側に基礎知識のストックを作ることが、踏み出す上で大きな支えになりました。 今後の伸び代 今回の構築で見えてきた、自分側と仕組み側の伸びしろを書いておきます。 自分側 複数リポジトリにまたがるサービスならではのオブザーバビリティ設計です。 Findy Contextは複数リポジトリで構成されており、1リクエストが複数サービスを跨ぐ場合の追跡や、ログ・メトリクスの相関付けには、まだ改善の余地があります。 Datadog APMなどを活用しながら、どう設計していくかは今後の課題です。 仕組み側（汎用モジュール・テンプレートへの改善余地） ここまで書いてきたとおり、SREチームが整備してくれた汎用モジュールやテンプレートには、非常に大きな価値を感じています。その上で、実際に使ってみて感じた「もう一歩テンプレート化されると嬉しい」領域も挙げておきます。 初期セットアップ（AWSアカウントの発行 → OIDC認証 → Terraform / GitHub Actionsの初期構成）の部分は、想像以上に時間がかかった領域でした。 中核のリソース構築は汎用モジュールのおかげで早く進められた一方で、初期のアカウント・認証まわりは、まだ個別対応の比率が高めだと感じました。 ここがもう一段テンプレート化されると、次に立ち上げる新規プロダクトの初動はさらにスムーズになりそうです。 まとめ Findy Contextのクラウド環境立ち上げを通して、最も強く感じたのは、「仕組み」と「個人の学習」の両方が揃って初めて、経験1年のエンジニアでも0→1に踏み出せるということでした。 仕組み側（SREチーム）が整備してくれた汎用モジュール、テンプレート、既存プロダクトの参考実装、相談しやすいサポート体制など、これらが
- SRE
- Terraform
- AWS
- Datadog
- CI/CD
プロパティの順序で型推論が壊れる!? TypeScript6.0の修正からContext-Sensitivityの仕組みを追う
こんにちは。ファインディでフロントエンドエンジニアをしている大石（@bicstone）です。 2026年5月22日〜23日に開催されるTSKaigi 2026で、「プロパティの順序で型推論が壊れる!? TS6.0の修正からContext-Sensitivityの仕組みを追う」というタイトルで登壇します。本記事は10分のトーク内では時間の都合で端折った内容も含めた拡張版としてお届けします。 2026.tskaigi.org TypeScriptでオブジェクトリテラルにメソッドを書いたとき、プロパティの記述順序を入れ替えただけで型推論の結果が変わるとしたら、どう感じるでしょうか。「そんな不思議な挙動があるのか」「気になるけどTypeScript内部のソースコードは難しそうで自分には縁がない」と思った方もいるかもしれません。 この記事では、この不思議な挙動を入り口にしてTypeScriptコンパイラの中で何が起きているのかを1つのPRから追いながら解説します。 背景: プロパティの順序で型が変わる アロー関数なら問題ないのはなぜか Context-Sensitive Functionの考え方 推論の全体像 メソッド構文に隠れている暗黙のthisパラメータ 両方スキップで起こる順序依存の正体 今回の修正を読み解く binder.ts: ContainsThisフラグを立てる utilities.ts: hasContextSensitiveParametersの変更 checker.ts: Generator固有のエッジケース 修正前後の推論を比較する TypeScript 5.9 TypeScript 6.0 TypeScriptのコンパイラを読む最初の一歩 おわりに 参考資料 背景: プロパティの順序で型が変わる 次のtest関数を見てください。型パラメータTを持ち、2つのプロパティaとbを受け取ります。 function test<T>(options: { a: (c: T) => void; b: () => T; }) {} 次の2つの呼び出しは、プロパティの記述順序が違うだけです。しかし、TypeScript 5.9以前では、この2つの結果は異なります。 test({ b() { return 123 }, a(c) { return c } }); // c: number test({ a(c) { return c }, b() { return 123 } }); // c: unknown プロパティの順序を入れ替えただけでcの型がnumberからunknownに変わります。 手元で挙動を確認したい場合は、TypeScript Playgroundを開いてみてください。cをホバーするとunknownが表示されるはずです。 アロー関数なら問題ないのはなぜか 一方、同じコードをアロー関数で書き換えると、順序に関係なく推論が通ります。 // アロー関数は、どちらの順序でもc: number test({ a: (c) => { c }, b: () => 123 }); // c: number test({ b: () => 123, a: (c) => { c } }); // c: number メソッド構文では順序に依存するのに、アロー関数では依存しない。この差はどこから来るのでしょうか。 答えはTypeScriptの型推論パイプラインにおけるContext-Sensitive Functionという考え方にあります。 Context-Sensitive Functionの考え方 Context-Sensitive Functionとは、型注釈のないパラメータを持つ関数のことです。パラメータの型を決めるために、外部のコンテキストが必要になります。 // context-sensitive: (c) => c // cの型がわからない → 外部に依存 // context-sensitiveでない: (c: number) => c // cの型が明示されている () => 123 // パラメータがない TypeScriptの型推論において、context-sensitiveな関数は特別扱いされます。推論の過程で「後回し」にされるのです。 なぜ後回しにする必要があるのでしょうか。次のコードで考えてみます。 function callFunc<T>(callback: (x: T) => void, value: T) {} callFunc(x => x.toFixed(), 123); // ^ ^^^ // xの型を知りたい Tの情報源 callbackの引数xの型を決めるにはTが必要です。しかしTを推論するためにはcallbackの情報も必要です。鶏と卵の問題が発生します。 TypeScriptはこれを解決するために、context-sensitiveな関数（ここではcallback）をいったんスキップし、他の引数（ここでは123）から先にT = numberを推論します。その後、callbackに戻ってx: numberを確定させます。 推論の全体像 TypeScriptのジェネリック関数における型推論は、おおまかに次の流れで行われます。 引数を走査し、context-sensitiveな関数を特定する context-sensitiveな関数をスキップする 残りから型パラメータTを推論する 確定したTで後回しの関数のパラメータを型付けする ステップ2で全ての関数がスキップされてしまうとTを推論するソースがなくなります。その場合、TypeScriptはフォールバック処理に入り、左から右の順番で処理を試みます。 メソッド構文に隠れている暗黙のthisパラメータ メソッド構文で書かれた関数は、暗黙のthisパラメータを持ちます。 // メソッド構文 { a(c) { return c } } // ↓ TypeScriptの内部的な解釈 { a(this: ???, c: ???) { return c } } // ^^^^ 暗黙のthis → 型注釈なし → context-sensitive thisパラメータには型注釈がないため、TypeScriptはこの関数をcontext-sensitiveと判定します。thisを実際には使っていなくても、存在するだけでcontext-sensitiveになってしまいます。 一方、アロー関数はthisパラメータを持ちません。 // アロー関数 { a: (c) => c } // → this
- TypeScript
不要なレビューをAIにまかせてAIコーディングの環境改善を加速した
こんにちは。こんばんは。 Findy Team+ 開発のフロントエンドリードをしている @shoota です。 今回はフロントエンドからは少し離れ、AIによるプルリクエストのレビューシステムを作成した話を書きます。 Findy Team+フロントエンドの現状と課題 AIコーディング時代の新たな課題 AIによる自動レビュー（Approve）を作ろう 解決したい課題 レビューは大きく3種類ある 誰が使えるのか 何を判定するのか 判定のキモはTidy First?の分類 実装とポイント GitHub Actions Claude Code Actions ワークフローの変化とプロンプトの改善 実行コスト おわりに Findy Team+フロントエンドの現状と課題 過去のブログでも触れていますが、Findy Team+のフロントエンドは、非常に大きなモノレポで構成されています。 tech.findy.co.jp このため、CIの最適化・チューニングはもちろんのこと、コードベース全体の秩序の品質を維持するためにさまざまな工夫や制約をもって運用してきました。 AIコーディングが主流になってからは更にこれらを強化し、制約やルールの策定、ESLintやユニットテストなどのガードレール整備や強化をおよそ1年をかけて進めてきました。 （この内容については別で発表したいと思います） これらの投資とAIモデルの進化により、これまでバックエンドを中心に活動しているメンバーのフロントエンドの参入障壁を大きく下げることに成功しています。 現在では、AIが生成するコードの質は1年前から大きく向上していると体感しています。 AIコーディング時代の新たな課題 しかしここで新たな課題が生まれました。それは、「AIが真似すべきでないコードの修正や、それらを防ぐルールの導入のためのレビューコストが異常に高い」ということです。 AIの活用のためにコードを直し続ける活動は巨大なコードベースではかなりコストがある 技術的な障壁よりも単純な物量がつらく、対抗する手段がない ESLintのルールを1つ変更するだけでプルリクエストが大量に必要になる 特定のルールのちょっとした厳格化で25件のプルリクエストを作成 あたらしいルールを追加したときは150件のプルリクエストが必要になった 軽微な変更でも意味のある粒度で修正しなくてはレビューできないため、ひたすらに数を重ねる このような事象が定常的に発生しており、次のFindy Team+でのグラフでも確認できます。 大量のプルリクエストが発生する様子 Vitestの一部のassertionがdeprecatedになったことに対して、私が一人でClaude Codeを回し、1日に72件、2日で100件以上のプルリクエストを作成しました。 レビュー待ちが多く発生する割に、内容は関数の置き換えなのでレビュー価値が低いプルリクエストが大量に必要になったのです。 このような 「AIを利用して品質を維持するための整備が人間を苦しめている」 という状況は、近頃話題になっていたHustle Pornに近いのではないか？と考えました。 hustle porn 覚えた https://t.co/y3jpiLDL0x— Takuto Wada (@t_wada) 2026年4月13日 プルリクエストをたくさん書くことは素晴らしいですが、そこに意味のある粒度と価値が伴わなければなりません。 AIによる自動レビュー（Approve）を作ろう このような背景からレビュー負荷を可能な限り低減させ、ただしい怠惰を取り戻すために、AIレビューの仕組みを作成することにしました。 まずはやりたいことから全体の構想とコンセプトを決めていき、次のような内容になりました。 解決したい課題 プルリクエストを高速に作り続けることはむしろ歓迎すべき 課題の本質は「レビュープロセスが対ひとでしか機能していない」こと 人の時間をうばう 人のアクションを待つ 両者にメリットが少ない レビューは大きく3種類ある レビューする価値がないことを確認するレビュー。レビューというワークフローを実施しているだけであり、本質的なレビューはしていない。レビューワークフローに相乗りしている儀式のひとつ。 品質、プログラム観点としてのコードレビュー。いわゆる本質的なコードレビュー。 レビュー結果が反映されていることのレビュー。論点が絞られており、コードの内容がレビュー指摘に即して修正されているかを「確認する」だけの作業的な儀式。 今回は1. の「レビューする価値がないことを他者が保証する儀式」をAIにやらせることをゴールとします。 誰が使えるのか 初手はフロントエンドのレビュワーチームのみに絞る 最大リスクは、誤判定や手順のハックによるレビューのザル化 フロントレビュワーチームはセルフレビューで一定の品質担保ができている前提で考える 条件的に一般解放は想定するが、判定の成功率データがたまるまではリスクのほうが大きい 何を判定するのか 要はプルリクエストの分類器をつくる Claude CodeのReview (~$25) は必要がない 変更内容から人間がレビューする必要があるかどうか？を判定する 振る舞いが変わらない構造的なリファクタリング code generatorなどの既存の機械的なワークフローの結果も不要と判断する 判定のキモはTidy First?の分類 レビューの必要性を測る判定処理に、構造的なリファクタリングという概念を持ち込みました。 これは昨年の弊社のイベントでキーノートを務めていただいたKent Beck氏の書籍Tidy First?から引用した言葉です。 この書ではリファクタリングの分類が紹介されており、リファクタリングを効率的に進めるための作業を指します。 和訳では「整頓」と表現されています。 振る舞いの変化を伴わない、「コードの移動・分割」、「名前の変更」、「配置の変更」 プログラム（群）の凝集度に対するリファクタリングアプローチ これらの修正は人間が目で追うのは意外と面倒で、レビューコストが割に合わない 例）ファイル移動や統合、変数・関数のリネームor削除、関数統合・分離 www.oreilly.co.jp Tidy First?に関する考察は非常に多く議論されているので、Claude Codeに調査させながら「人間のレビューが不要」の定義を確定し、プロンプトに起こしていきました。 次に示すのがそのパターンの概要です。詳しい内容はぜひ書籍を確認していただけるとよいかと思います。 対象パターン（T1〜T14） T1: ファイル移動・リネーム T2: import整理・barrel export T3: 型定義の移動・分離 T4: コンポーネント・関数の分割・統合・抽出 T5: 変数・関数・propsのリネーム（テスト/モックへの機械的波及含む） T6: ESLint/Prettier修正 T7: 不要コード・ファイル削除 T8: 非推奨APIの機械的移行（1:1対応） T9: GraphQL codegen実行結果 T10: Nx generator実行結果 T11: ガード節への変換 T12: 説明変数・定数の導入 T13: Feature Flag名の追加 T14: コメントの追加・修正・削除 NGパターン（NG1〜NG7） 新条件分岐、新ビジネスロジック、API変更、状態管理変更、テスト追加、UI変更、設定値変更 実装とポイント 全体の要件が決まったのでここからは実装です。 GitHub Actions GitHub Actionsをランナーとし、プロンプトファイルを読み込んだうえでClaude Code Actionsに渡して実行、結果をパースしてレポートする非常にシンプルなフローです。 またFindy Team+はCI結果を送ってCIの実行分析ができるので、これも組み込んであります。 GitHub Actionsのフロー Claude Code Actions Claude Code Actionsの呼び出しのポイントは--max-turnsです。 これはClaude Codeが処理を何手まで行うかを制限するもので、変更ファイル数やそれらのファイルの関連性によって前後します。 - name: Classify PR changes id: claude uses: anthropics/claude-code-action@5d5c10a4f389689f992ea10bb14dcb6fcc83146d # v1.0.102 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} claude_args: '--max-turns 20' prompt: ${{ steps.prompt.outputs.content }} 何パターンかの構造的なリファクタリングのプルリクエストで試したところ〜15 turnsにおさまるようでしたが、余裕を見て20を設定しています。 これを設定しておくことでプロンプトの誤認や想定しない大きな差分で実行された場合でも「判定不能」で安全に終了するようにしています。 ワークフローの変化とプロンプトの改善 何度か試していくうちに、ひとつの気づきがありました。 これまでプルリクエストは 「人間が認知できる変更量」にサイジングするようにすべき でしたが、AIは機械的にこれを分析できるので「同じ作業なら差分が大きくても1つのプルリクエストにまとめる」ことができる、ということです。 そのため大きな差分でもApproveができるような負荷耐性をもたせる必要があります。 そこで変更ファイルが多い場合は変更そのものを見るのではなく、いくつかをサンプリングし、「diffのパターンが同一であるか？」をClaudeが確認するようにしています。 <!-- 追加したプロンプトの抜粋 --> ## 大規模 PR のフォールバック - **変更ファイル数が 30 ファイルを超える場合**: 同一パターンの変更が繰り返されるファイル群はサンプリング（代表的な数ファイルの確認）で判定してよい。サンプリングした旨と確認したファイルを注意事項に記載する - **サンプリング時は副作用の取り逃しに注意する**: ある T パターンを特定したら、**その波及先ファイル群（スナップショット、spec、モック、`index.ts` の re-export、import 更新 等）も必ず1件以上サンプリングに含め、元の T パターンとの対応を確認する**。波及先のファイルだけを単独で見ると NG に誤分類しやすい（例: T5 リネームのインラインスナップショット更新を NG5 と誤認）。波及元・波及先を**セットで**サンプリングすること （以下略） 実行コスト Claude CodeのReviewは 最大$25の費用が必要ですが、今回はプルリクエストの分類器なのでそこまでのコストがかかりません。 CIから実行したログからみると、1 runあたり、$0.20〜0.50で分類ができていました。 { "type": "result", "subtype": "success", "is_error": false, "duration_ms": 62472, "num_turns": 10, // Claude Codeの手数の実績値。最大20で絞ってある。 "total_cost_usd": 0.24731475000000003, // 約$0.25を消費 "permission_denials_count": 0 } おわりに プ
- GitHub Actions
- Claude
- リファクタリング
- 開発生産性
- 生成AI
イベント「事業成長に効かせるファインディ流データエンジニアリングの実践」開催レポート
こんにちは。ファインディ株式会社でデータエンジニアをしている開です。 2026年4月28日（火）に、データソリューションチーム主催の採用イベント「事業成長に効かせるファインディ流データエンジニアリングの実践」を開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の3本のセッションを参加できなかった方にもイメージが伝わるようにまとめます。 イベント開催の背景 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ セッション2: データモデリングを通して管理会計のオペレーションを再設計 セッション3: 社内で使われるLooker整備の進め方 まとめ イベント開催の背景 ファインディでは、既存4プロダクトに加えて、新たに4つのプロダクトをリリースし、エンジニアの皆さまへサービスを多角的に展開しています。会社規模の拡大とともに、扱うデータの量と種類は急速に広がってきました。 prtimes.jp 変化の激しい事業環境のなかで客観的な意思決定を支えるには、社内の情報流通をより活性化させる仕組みが欠かせません。私たちは、その土台を担うのがデータエンジニアリングだと考えています。 データソリューションチームは少数精鋭で推進してきましたが、事業成長のスピードに合わせてデータ基盤をさらにスケールさせるには、共に挑戦してくれる仲間の存在が不可欠です。今回のイベントは、ファインディがどのような課題に向き合い、どのような技術と組織で解いているかを直接お話しする機会としました。 セッションは3本立てで、データ基盤・データモデリング・BIの3つの観点からファインディのデータエンジニアリングをお話ししました。 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ 登壇者: 開 speakerdeck.com 事業拡大に合わせてデータ基盤をどうリアーキテクチャしているかを紹介しました。直近1年でデータソースは10倍、Google Cloudプロジェクトは6倍に増える一方、データエンジニアは3名のままで、認知コストと運用負荷が膨らんでいました。 これまでは事業＝ドメインとしたデータメッシュ的な構成で、技術選定も各チームに委ねていました。アジリティは出る一方で、ドメイン間の連携不足や技術のばらつき、作業重複が課題になっていました。 そこで、データメッシュの利点は残しつつ実装を見直し、Google Cloudプロジェクトの統合、IAMのデータセット単位での管理、dbt Platformへのオーケストレーション集約やマネージドサービスの活用を進めています。これによりマネージドサービスのAPIやMCPを用いてAIエージェントに運用を一部移譲することができています。作成したスキルやサブエージェントは以前テックブログで紹介したプラグインとしてチーム全体で使えるようにしています。 tech.findy.co.jp DataOpsの省力化が進む一方、コスト透明性の低下といった新しい課題も見え、FinOps体制の構築や、浮いた時間をデータ活用者との会話やイネーブリングに使っていくことを次のテーマにしています。 セッション2: データモデリングを通して管理会計のオペレーションを再設計 登壇者: 田頭さん speakerdeck.com 経営判断に直結する管理会計という業務領域に対して、データモデリングの観点からオペレーションを再設計した取り組みを紹介しました。 ファインディの管理会計は、長らくスプレッドシートを中心に回っていました。月次のたびに関数とピボットを手作業で組み直し、IMPORTRANGEやVLOOKUPで絡み合ったスプレッドシートのリネージは50件を超え、どこか1枚崩れると全体が連鎖して壊れる脆さを抱えていました。同じKPIが部署ごとに別ロジックで計算されて数字が合わない、月次締めに2〜3日かかって意思決定が後追いになる、といった状態も常態化していました。 再設計の起点に置いたのは、技術選定ではなく業務担当者へのヒアリングです。「計上組織」「補助科目」「配賦」「予算番号」といった専門用語が飛び交うなか、勘定元帳やマクロを眺めるだけでは掴めない集計粒度や分析軸を、経営管理部の担当者と何度もMTGを重ねて引き出していきました。書籍『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』のBEAM✲を参考に、誰が・何を・いつ・どこで集計したいのかを対話から輪郭化し、総勘定元帳を起点に売上・費用・原価を月次粒度のファクトとして整理しています。 実装は、会計データソースをGoogle DriveにアップロードしてTROCCOで取り込み、dbtで集計してLookerやスプレッドシートから参照する構成に落としています。これにより、ワンボタンで月次の実績値が揃い、想定外の科目も自動で検出できるようになりました。「どの数字が正しいか」を議論する場面はなくなり、月次締めの所要時間と数字の信頼性が同時に改善しています。 今後は、実績ファクトと同じ粒度で予算・見通しを取り込んだ予実分析の自動化や、整備済みのファクトを起点にAIエージェントが自然言語で会計分析を行える基盤への展開を進めています。 セッション3: 社内で使われるLooker整備の進め方 登壇者: 出相さん speakerdeck.com 社内で実際に使われるBIにするためにLookerをどのように整備してきたかを紹介しました。「ダッシュボードを作った瞬間がピークになって使われなくなる」「事業部からはデータ活用の入口が見えない」「スプレッドシート運用が属人化して限界が見えている」といった、よくある課題を出発点にしています。 ファインディでは、Lookerを意思決定にひも付くダッシュボードを定常的に見る場としてだけでなく、Exploreや会話分析でデータそのものを探索する場にすることを目指しています。ただし、最初はLookerを見に行く習慣もExploreの操作にも慣れていないため、進め方の工夫が欠かせません。 そこで、ヒアリングで課題を引き出す → 最低限の機能に絞って最初のダッシュボードを素早く提供する → 共有MTGで一緒に触りながら改善ループを回す → 利用が定着してからディメンショナルモデルやメタデータを整える、という4ステップで価値を積み上げてきました。完璧な設計よりも早い体験提供を優先し、苦労していたことから先に解消していくことを大切にしています。詳しい進め方は以前のテックブログでも紹介しています。 tech.findy.co.jp その結果、MAUは2026年1月から4月途中で約1.5倍、WAUは1月中旬から4月中旬で約2.6倍に成長しました。経営管理部からも「BigQueryやLookerを駆使したモニタリングが事業拡大に不可欠」というコメントが届くなど、Lookerが信頼できるデータソースとして社内に定着してきています。 まとめ 今回のイベントを通じて、ファインディがデータエンジニアリングをどのように事業に効かせようとしているかを、3つの異なる切り口でお伝えできたと思います。データ基盤・データモデリング・BIのいずれも、技術そのものよりも「事業や業務にどう接続するか」を軸に進めてきた取り組みです。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データエンジニアリングの力で事業成長を支える仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話しできるとうれしいです。 herp.careers
- Google Cloud
- dbt
- Looker
- データ基盤
- データ分析
コーディングをAIに任せても、エンジニアの仕事は減らなかった ― ほぼ一人で1か月、AI機能をリリースしてみて
こんにちは、ファインディでFindy Toolsの開発をしている本田です。 このたび、Findy Toolsの新機能として「アーキテクチャAI」をリリースしました。要件を入力するとAWSのアーキテクチャ図と設計の提案が生成される機能です。 findy.co.jp 今回の開発では、PM・仕様策定・スコープ定義・インフラ・FE/BE開発・テストまで、ほぼ一人で1か月で担当しました。そして、コーディングはほとんどClaude Codeに任せ、私自身はほぼコードを書いていません。 この記事では、そんな開発を進めるなかで分かったこと、難しかったこと、そして改めて実感したエンジニアの仕事について紹介します。 アーキテクチャAIについて 一人開発の全体像 エンジニアが価値とコストを自分で判断する 対話で判断の視野を広げる 動くもので共通認識を作る 自分の仕事は減らず、判断と意思決定の時間が増えた まとめ アーキテクチャAIについて 本題に入る前に、リリースした機能を軽く紹介させてください。 アーキテクチャAIは、Findy Toolsの中で提供している機能の1つで、「作りたいシステムの要件」を入力するとAWSを使った構成案とアーキテクチャ図、そして設計の考え方の解説がまとまった形で得られるものです。 ai-architecture.findy-tools.io アーキテクチャの設計はサービスの土台を決める工程で、経験や周辺知識の広さが問われる領域です。そうした知見を持った人に相談しづらい場面でも、構成の検討を前に進める助けになることを目指しています。 ここから先は、この機能を一人で1か月で作ったなかで気づいたことを中心に書いていきます。 一人開発の全体像 今回は、PMから開発、テスト、リリースまでを一人で担当しました。具体的には次のような範囲です。 プロダクトの方向性・優先順位の決定 仕様策定、スコープ定義 インフラの構築 フロントエンド・バックエンドの実装 テスト、リリース作業 開発のワークフローはシンプルで、だいたいこのサイクルを回していました。 GitHub Issueに「なぜ作るのか」「何を作るのか」を、PRDやユーザーストーリーの形で書く Claude CodeにIssueを渡して実装してもらう 自分は差分をレビューし、必要に応じて指示を出す 別チームのメンバーにレビューしてもらい、PRをマージする 実装の途中でも、作りたい背景やユーザーに届けたい価値に立ち戻って方針を調整することはよくありました。 仕様策定やUIのモック作成も、AIと壁打ちしながら進めていました。結果として、自分でコードを書いた量はごくわずかで、ほとんどの実装はClaude Codeが書いています。 一方で、「自分はほぼコードを書いていない」からといって仕事が少ないわけではありませんでした。むしろコーディング以外にやることが山ほどあるというのが実感です。 何を作るか、何を削るかの判断 仕様の細部に関する意思決定 技術選定 コードレビューと品質の担保 スケジュール管理とリリース計画 ここからは、この進め方で1か月やってみて感じたことを書いていきます。 エンジニアが価値とコストを自分で判断する 最も強く感じたのは、エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携わることの強みです。 今回は一人で担当していたので、事業やプロダクトの意図、技術的な実現可能性、実装コストが、すべて自分の頭の中に揃っていました。「ユーザー価値として外せない部分はどこか」「コストをかける価値があるのはどこか」を、自分の中でつなげて考えながら開発を進めることができます。 具体的には、開発の途中でアーキテクチャ図の描画ライブラリを切り替える判断をしたり、リリースの2週間前になってからSNSで共有されたときに見栄えの良い画像を生成する機能を追加する判断をしたりと、方針転換を素早く進められました。技術的に成立するかをClaude Codeで素早く検証しつつ、プロダクトとして本当に必要かを自分で判断できたことで、価値とコストの両取りを狙える選択肢を見つけやすくなっていました。 体制を一人にしたことが本質ではないと思っています。大事なのはやはり、作る側のエンジニアがユーザー価値や事業価値を理解したうえで、コストと価値のバランスを判断しながら開発に携われているかだと、今回の開発を通じて改めて感じました。 対話で判断の視野を広げる 意思決定が速いのは良いことですが、速ければ良いわけではありません。一つの視点だけで速く判断を続けていると、気づかないうちに筋の悪い方に流れてしまいます。 ここで効いてきたのが、一人で担当していても孤立はしていないという体制づくりでした。 開発中は、事業部長・PO・デザイナと定期的に相談・共有できる場を持ち、それ以外の場面でもいつでもコミュニケーションを取れるようにしていました。 プロダクトとして何を大事にしているか 事業としてこの機能にどういう期待があるか デザインとして譲れない部分はどこか こうした観点を継続的にすり合わせることで、自分一人では見えていなかったより良い選択肢を見つけやすくしていました。 自分の頭の中だけで判断すると、どうしても視野が狭くなります。そこに他の立場の視点が入ると、「他にもっと良い選び方はないか」という問い直しができます。スピード重視の体制であっても、というよりスピード重視だからこそ、チームとの対話は欠かせないと感じました。 動くもので共通認識を作る もう1つ強く感じたのが、速く見せられるもの・動くものを使って共通認識を作ることの効果です。これ自体は昔からよく言われる話ですが、AIの力でぐっとやりやすくなりました。 今回は、実プロダクトの開発を始める前に、別リポジトリでPoCアプリを作り、ステークホルダーやインタビューにご協力いただいた方に、実際に見たり触ったりしてもらう時間を取りました。 PoCアプリの画面。デザインは作り込まず、ユーザーに価値を体験してもらうことを優先した。 文章やスライドだけで議論すると、どうしても抽象的になり、認識のズレに気づきにくくなります。動くものがあると、「これは欲しい」「ここは期待と違う」というフィードバックが具体的に返ってくるだけでなく、「どういう価値が得られそうか」という部分でも共通認識を作りやすくなります。 PoCを見たり触ったりしてもらうなかで見えてきたのは次のようなことです。 ユーザーが本当に価値を感じるのはどの部分か 最初はあると便利そうに見えたが、実際はなくても困らない機能 技術的に見落としていた制約や、逆に想定より軽く実現できそうな部分 PoCで得られたこれらの情報が土台になって、本開発のスコープと方針が定まっていきました。AIで「仮に動くもの」を高速に作れるようになった強みを活かして、動くものを中心に仮説検証のサイクルを回せたことが、1か月という限られた期間のなかで特に効いたポイントだと思います。 自分の仕事は減らず、判断と意思決定の時間が増えた ここまで書いてきたことを踏まえて、改めて感じたのは少なくとも今回の自分の経験では、コーディングをAIに任せても、エンジニアとしてやることは減らなかったということです。むしろ、本質的な判断に集中する必要が出てきた感覚でした。 今回の開発で自分が時間を使っていたのは、次のような部分です。 この機能を作る意味は何か、誰のどんな課題を解くのか スコープをどこまで広げ、どこで切るか どの技術を選び、どの技術を見送るか 出てきたコードが本当に要件を満たしているか、将来の運用に耐えるか どれも、意思決定と判断の仕事です。コーディングそのものをAIに任せられるからこそ、こうした判断に集中できる時間が増えました。 AIと協業するなかで変わる部分と変わらない部分があり、「コードを書く時間」は確実に減りますが、「エンジニアリングを行う時間」は減らない、むしろ増えている感覚でした。 まとめ ほぼ一人で1か月かけてアーキテクチャAIをリリースしてみて、次のことが学びとして残りました。 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携われると、価値とコストの両取りを狙える選択肢を見つけやすい 速さだけを追うのではなく、複数の視点を対話で取り込んで選択肢を広げていく AIで仮の動くものを高速に作れるようになった強みを活かせば、短期間でも動くものを軸に仮説検証を回しやすい 少なくとも今回の自分の経験では、コーディングをAIに任せても仕事は減らず、判断と意思決定に集中する時間が増えた AIと一緒に開発する時代になっても、「何を作るか」「どう作るか」「なぜそれを選ぶか」を考え抜くことの大切さは変わらないなと、今回の開発を通じて改めて感じました。 アーキテクチャAIは次のページから触れます（Findy Toolsの会員登録が必要です）。ご興味のある方はぜひ試してみてください。 findy-tools.io ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- 生成AI
- プロダクト開発
- 開発生産性
RubyKaigi 2026で発表されたSpinelを触ってわかった「コンパイルが通っても動いているとは限らない」話
こんにちは。プロダクト開発部の森 @jiskanulo です。 2026年4月22日から24日までRubyKaigi 2026 Hakodateが開催されました。 rubykaigi.org 函館アリーナを3日間に渡って貸し切る大規模イベントの運営をしていただきましたスタッフの皆様に感謝を申し上げます。 ファインディ株式会社もPlatinumスポンサーとして協賛しました。 私もブースに立って出展やファインディ各サービスのご案内をさせていただきました。 お話しをしていただいた皆様にも重ねて感謝申し上げます。 ブースに立つ合間にセッションを聞いて自分でやれそうなことに思いを馳せたり、他社様のブースを回ってプロダクトのお話をしたり、昔の同僚や知人と再会したりと個人的にもいい刺激の多い3日間でした。 さて、4月24日、最後のセッションのMatzさんのキーノートにてRubyファイルをネイティブバイナリにコンパイルするSpinelが発表されました。 早速Spinelを使ってみた感想とつかいどころを記します。 Spinelとは 検証環境とセットアップ 動かしてみた Hello, World! eval / requireの挙動：エラーにならず無音で間違う eval は no-op に置き換わる require は文ごと消える 現時点での注意点 Spinelを使ってみる requireなしでJSONを扱う ハマりどころは個別に踏みに行く価値がある Spinelを試すときの判断基準 個人的所感 おまけ: Spinelの由来 おわり Spinelとは SpinelはRubyのAOT (Ahead-Of-Time) コンパイラです。 RubyソースコードをPrismでパースし、全プログラム型推論を行いCのコードに変換してネイティブバイナリを生成します。 パイプラインは次のとおりです。 Ruby → Prism → AST → 全プログラム型推論 → Cコード → ネイティブ実行ファイル リポジトリのREADMEによると、miniruby比で約11.6倍、Conway's Game of Lifeでは86.7倍という性能が示されています。 またバイナリサイズもmrubyを含めずに数十KBに収まるので容量が厳しい環境にも適用できるとのことです。 実体としての./spinelはPOSIX shell wrapperで、内部でspinel_parse → spinel_codegen → ccを直列に呼び出している、という作りです。 検証環境とセットアップ 検証は手元のmac環境で行いました。 4月24日公開直後にmacで動かそうとしたタイミングではmalloc.hが存在しないなどでエラーになったのでDockerでUbuntuのコンテナを起動して操作しましたが、現在は対応されています。 土日で函館観光しているうちにコントリビュートが進んでいますね。コントリビュートのチャンスですね。 mac build対応 https://github.com/matz/spinel/commit/4593581eb87cea45b59fb28b9dcf2cd75a9bcbab windows対応 https://github.com/matz/spinel/commit/1fe3136aa9bf834b5f37176faca7346503fb1446 環境は次のとおりです。 macOS (arm64) Apple Clang Spinel masterブランチ（2026-04-28時点） ビルドと実行の基本フローはシンプルです。 spinelをmakeし、spinelにrubyファイルをわたせば実行形式バイナリが出力されます。 make deps # 初回のみ: libprism 取得 make # spinel_parse / spinel_codegen / ランタイムをビルド ./spinel app.rb # Ruby → 実行形式（./app） ./app 動かしてみた Matzのキーノートとも被りますがサンプルコードを動かしてみました。 またキーノートで話があったとおりevalとrequireはサポートしていないとのことです。 eval, requireを使うと具体的にどうなるのかも試してみました。 Hello, World! 最小の動作確認はそのまま動きます。 # hello_world.rb puts "Hello, World!" ./spinel hello_world.rb ./hello_world # => Hello, World! eval / requireの挙動：エラーにならず無音で間違う 2026年4月28日の現時点ではコンパイル時にエラーにならず、warningも出ず、しかし実行すると無音で間違った出力を返すという挙動です。 具体的に2つのケースを見ていきます。 eval は no-op に置き換わる 次のRubyコードをSpinelでコンパイルして実行します。 # test_eval.rb code = "1 + 2" result = eval(code) puts result $ ./spinel ./tmp/jiska/samples/test_eval.rb ./tmp/jiska/samples/test_eval.rb -> test_eval 実行すると結果は0です。 $ ./test_eval 0 生成されたCのコードを見るとeval()の呼び出しがno-opに置き換わり、戻り値は型推論で決まったゼロ値（mrb_intのため0）になります。 const char *lv_code = "1 + 2"; mrb_int lv_result = 0; // mrb_int = int64_t typedef lv_code = "1 + 2"; lv_result = 0; // ← eval() 呼び出し自体が消滅、0 を代入するだけ printf("%lld\n", (long long)lv_result); mrb_int はmrubyのような」命名に見えますが lib/sp_runtime.h で int64_t のtypedefとして定義されたSpinelランタイムの整数型です。 https://github.com/matz/spinel/blob/64105ec86d08c9edc92c3d17bf059126ceaa15d3/lib/sp_runtime.h#L53 require は文ごと消える 次はrequire "json"とJSON.generateを使うケースです。 # test_require.rb require "json" puts JSON.generate({ name: "spinel", year: 2026 }) こちらも実行すると0になります！ $ ./spinel ./tmp/jiska/samples/test_require.rb ./tmp/jiska/samples/test_require.rb -> test_require $./test_require 0 requireの行は生成されたCのコード上で文ごと消えます。 続くJSON.generateもSpinelから見れば未定義メソッドであり、evalと同じくゼロ値を返す呼び出しに化けます。 最終的にputsには0が渡って表示される、という流れです。 現時点での注意点 現時点では「コンパイルが通った」「実行ファイルができた」「実行できた」の3点だけを見ていると間違った結果を吐いていることに気づけません。 Spinel向けにRubyを書くときはREADMEを都度確認することが重要です。 Spinelを使ってみる 次に実際のユースケースを想定してみます。 実例として、GitHubのPR一覧JSONを入力に取り、各PRのnumberとauthorを表示するスクリプトを書いてみました。 入力はARGV、stdinの優先順で受け取ります。 requireなしでJSONを扱う require "json"が使えないので標準のRegexpとString操作だけで処理を組む必要があります。 なお、ここで示すコードは正しいJSONパーサではありません。require "json"が使えないSpinelの制約下で、入れ子オブジェクトや},を含む文字列値が現れない、フラットな配列形式の固定データからnumberとauthorをアドホックに取り出す例として読んでください。本格的なJSON処理が必要な場合は、入れ子・エスケープなどで容易に壊れるため、この実装は使えません。 実際のRubyファイルは次のとおりです。 多少トリッキーなところは感じますが、こうした限定的な用途であれば、RegexpとStringの標準機能だけで実装できることがわかりました。 if ARGV.length > 0 input = ARGV[0] else input = readlines.join end records = input.split(/},/) results = [] records.each do |chunk| if chunk =~ /"number"\s*:\s*(\d+)/ num = $1 if chunk =~ /"author"\s*:\s*"([^"]+)"/ auth = $1 results << "##{num}<span class="sy
- Ruby
- コンパイラ
PluginをCIから呼び出す：Claude Code Pluginの一歩先の使い方
こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 Claude CodeのPluginを使うと、社内で育てたSkillやAgentを、組織のメンバーにまとめて配布できるようになります。ファインディでも、この仕組みでセルフレビュー用のSkillを開発組織全体に配り、各自がPull request作成前に呼び出す形で活用してきました。 この記事では、そこからさらに一歩踏み込んだ使い方として、PluginをGitHub Actionsから呼び出してCIで動かす取り組みを紹介します。具体的には、Pluginに含まれるセルフレビューSkillをCIから定期実行し、指摘内容を反映したPull requestを自動で生成する仕組みです。 Pluginの使い方というと「Skillを社内で共有して、各自がローカルで叩く」という一面が語られがちですが、同じPluginをCI基盤から起動するという選択肢をとると、Pluginで育てたSkillが個人の開発体験だけでなく、チーム全体のプロセスにも効いてきます。 PluginとセルフレビューのSkillについては次の記事を参照してください。 tech.findy.co.jp tech.findy.co.jp Pluginで配って各自に使ってもらう運用 PluginをCIから呼び出す 実際のWorkflowを読み解く トリガーとスコープ PluginをCIに引き込む 自動生成Pull requestにもCIを走らせるための GitHub App 1指摘1Pull requestに切り出す GitHub Actionsのmatrixを使って並列でPull requestを作る まとめ Pluginで配って各自に使ってもらう運用 まず、ファインディでのセルフレビューの流れを整理します。 社内の開発用Pluginには、セルフレビューSkillが含まれていて、Pull request作成前にローカルでPull request作成用のコマンドから呼び出されます。Pluginとして配布しているので、新しくジョインしたメンバーも、追加の手順なしに同じSkillを使える状態になっています。 このあたりの「Pluginで開発ナレッジを横展開する」話は、冒頭に貼った記事で詳しく紹介しているので、そちらをぜひご覧ください。 この運用は、個人の開発体験を底上げするうえで十分機能しています。この記事が公開された頃には実に1500個ものPull requestで実行されており、「最後の一押し」として働いてくれています。 PluginをCIから呼び出す この運用をベースに、さらにもう一歩踏み込んで、同じPluginをCIからも呼び出してみるというのが本記事のテーマです。 PluginはSkillやSub Agentなどの集まりなので、Pluginを参照できる実行環境さえ作れば、人間の代わりにCIから呼び出すこともできます。普段ローカルで走っているものと同じSkillを、anthropics/claude-code-action経由でGitHub Actionsから起動すれば、Skillを再実装することなくCI化できるわけです。 github.com 本記事では、この考え方の一例として、セルフレビューSkillを定期実行し、指摘事項ごとに別々のPull requestを自動生成するWorkflowを取り上げます。対象にするのは、既存コードのうち長期間触られていないファイルです。人間のレビューでは目が届きにくい箇所に対して、機械がレビューすることで技術的負債の蓄積を抑えるというねらいがあります。 具体的に組み上げたWorkflowは、2つのjobで動きます。 指摘抽出 job：Pluginのセルフレビュー用Skillを呼び出し、対象コードに対する指摘を抽出する。 修正Pull request作成 job（matrix）：指摘の件数を matrix strategy に展開し、指摘内容ごとに独立したjobを並列起動。各jobは新しい runner 上で指摘内容を1件だけ修正したのち、PluginのPull request作成SkillでPull requestを作成 結果として、朝出社すると改善Pull requestの候補が並んでいる状態になりました。ローカルで個人が手動実行するSkillと、CIから定期実行されるSkillが、同じPluginの中身を共有している——これが、Pluginの使い方をもう一段広げてくれるポイントでした。 この仕組み自体はセルフレビュー専用のものというより、「PluginをCIから起動する」というパターンの1つの応用です。同じ構造で、様々なSkillをCIに組み込めます。 実際のWorkflowを読み解く まずは、今回組み上げたWorkflowの全体像です。PluginのSkillをCIから呼び出して指摘、Pull requestを並列生成するという流れを一通り確認できます。 name: Scheduled Self Review on: schedule: - cron: '0 19 * * 0-4' # 平日 JST 04:00（UTC 19:00 Sun-Thu） workflow_dispatch: env: SELF_REVIEW_MAX_FINDINGS: "3" jobs: # --------------------------------------------------------------------------- # Job 1: findings 抽出 # セルフレビューSkillで stale files をレビューし、 # 指摘を findings.json として artifact 化。matrix 展開用の index も出力。 # --------------------------------------------------------------------------- extract-findings: runs-on: ubuntu-latest timeout-minutes: 30 outputs: finding_indices: ${{ steps.compute-matrix.outputs.finding_indices }} findings_count: ${{ steps.compute-matrix.outputs.findings_count }} steps: - id: app-token uses: actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v2.2.2 with: app-id: ${{ secrets.SELF_REVIEWER_APP_ID }} private-key: ${{ secrets.SELF_REVIEWER_APP_PRIVATE_KEY }} - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with: token: ${{ steps.app-token.outputs.token }} fetch-depth: 0 - name: Compute stale file list run: | git log --since="1 month ago" --name-only --pretty=format: origin/main \ | grep -v '^$' | sort -u > .stale-recent.txt git ls-files | sort > .stale-all.txt comm -23 .stale-all.txt .stale-recent.txt > .stale-files.txt - name: Clone plugin repository run: | git clone https://x-access-token:${{ secrets.PLUGIN_REPO_READ_TOKEN }}@github.com/your-org/plugin-repo.git /tmp/plugin-repo - name: Extract findings via self-reviewer uses: anthropics/claude-code-action@4e5d8b13ca281a6d163cdb287d8917b216e00d6f # v1.0.103 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} github_token: ${{ steps.app-token.outputs.token }} plugin_marketplaces: | /tmp/plugin-repo plugins: | example-dev-plugin@plugin-repo claude_args: >- --allowedTools Read --allowedTools Write --allowedTools "Skill(example-dev-plugin:<review-skill>)" --allowedTools "Skill(<review-skill&
- Claude Code
- GitHub Actions
- CI/CD
- 生成AI
RubyKaigi 2026 Day1 - 『Exploring RuboCop with MCP』を現地で聞いてきた
はじめに こんにちは。プロダクト開発部 転職開発チームでエンジニアリングマネージャーをしている松村(@shakemurasan)です。 2026-04-22(水)から2026-04-24(金)までの3日間開催されているRubyKaigi 2026に現地参加しています。 rubykaigi.org この記事は、Day1 13:00-13:30のkoicさんのセッション『Exploring RuboCop with MCP』について、事前準備編と当日編（セッション当日に残したメモと感想）を1本にまとめたものです。 事前準備編にはAIによる予想が含まれるため、実際のセッション内容と一致するとは限らない点をあらかじめ断っておきます。 はじめに 事前準備編 koicさんの人となり AIに予想させてみたら、本人告知で焦点が絞れた 本人おすすめの教材とPRを少し覗いた 当日編 前半: MCP Ruby SDKとStreamable HTTP 後半: この1年間の試行錯誤 結びへ: 決定性と非決定性、そしてElicitation 聴き終えて腹落ちしたこと おわりに 事前準備編 koicさんの人となり koicさんはRuboCopのトップコミッターで、2025年にはMCPの公式Ruby SDK (modelcontextprotocol/ruby-sdk) のメンテナーにも加わっています。 github.com そこまでの道のりはFindy Engineer Labの取材記事『365日欠かさずコミットを積む。なぜRuboCopコミッター伊藤浩一はOSSと向き合い続けるのか』と、直近のお話はご本人のブログ『MCPの公式Ruby SDKのメンテナーに加わった』で詳しく綴られています。 findy-code.io koic.hatenablog.com 個人的な話をすれば、私がRubyを書き始めて数年の頃、地域のRubyコミュニティで何度かkoicさんをお見かけし、ジュニア時代の自分に刺激をくれた方の一人でもあります。 AIに予想させてみたら、本人告知で焦点が絞れた セッションタイトルだけでは論点が見えにくかったので、実は事前に予習の材料として、AIにkoicさんの直近のPRやIssueをもとに内容を予想させていました。 返ってきたのは大きく3通りの案でした。 1つ目は、stdio実装とMCP primitives（tools / resources / prompts）の写像を中心に据える構成。 2つ目は、MCPのtool annotationとRuboCopのCop属性の対応を核に据える構成。 3つ目は、Streamable HTTPを軸に据え、組織運用論にまで広げていく構成。 いずれもkoicさんの公開PRやIssueから拾えそうな筋ではあり、最初は「なるほどこのどれかだろうな」と眺めていました。 その後、koicさんご本人が『RubyKaigi 2026に登壇します』で背景と予習の案内をすでに公開されていることに気づきました。 koic.hatenablog.com 本人告知で軸に置かれていたのは「RubyツールチェインへのAI時代の課題提起」で、Streamable HTTPは副題として明示されていました。 一方で、tool / resource / promptといった「よく溢れている情報」は深掘りしない、とも明言されています。 AIの予想と本人告知を観点ごとにまとめると、次の通りです。 観点 AIの予想 本人告知 中心軸 RuboCop実装詳細 / MCP primitivesの写像 RubyツールチェインへのAI時代の課題提起 Streamable HTTP 1案の中心、他2案では末尾に触れる程度 副題として明示、講演の大きなトピック tools / resources / prompts 写像の中心概念として扱う 「よく溢れている情報」として深掘りしない旨を明言 当たっていたのは「Streamable HTTPが主要トピックの1つ」と見立てていた点で、大きく外れたのは「tool / resource / promptを写像の中心概念として扱う」という方向性でした。 AIの予想は世に広く出回っている話題の重心に引っ張られやすく、本人が「あえて深掘りしない」と宣言していた領域こそがむしろ中心に置かれていた、というコントラストになります。 そのおかげで、当日聞きに行くべき焦点が一気に絞れました。 本人おすすめの教材とPRを少し覗いた 本人告知で紹介されていた教材のうち、RubyWorld Conference 2025でのkoicさんの登壇アーカイブに目を通しました。 「なぜstdioだけでは足りず、双方向のHTTP通信が必要なのか」という道筋が登壇の流れで追えるため、セッション前のウォームアップに助かりました。 当日編 本編は事前告知どおりの2部構成で、前半がMCP Ruby SDKの話、後半がRuboCop x MCPの話でした。 なお、当日のセッション資料は『Exploring RuboCop with MCP』としてすでに公開されています。 speakerdeck.com 以降は、現地で受け取った温度感の記録として読んでもらえればと思います。 前半: MCP Ruby SDKとStreamable HTTP Ruby SDKはもともとShopify社内で少人数のエンジニアが始めたもので、koicさん自身もRuboCopを念頭に早い段階から参画し、コミッターに招かれたのち、mcp gemとして公開された、という経緯が紹介されました。 MCPにはTier1〜3のランクが定義されていて、現在のRuby SDKはTier3。 Tier1を目指していく、と明確に宣言していました。 本題のtransportsの話では、規格としてstdioとStreamable HTTPの2つが並びます。 stdioの単純さはさらりと触れ、時間が割かれたのはStreamable HTTPのほうでした。 HTTPの規格のままで、WebSocketのような独自プロトコルに寄らずに双方向通信を成立させる。 実装はRackアプリケーションとして組んでおり、HTTPで叩かれたタイミングでMCPセッションIDを払い出してセッションを確立し、Queueを介してやり取りを何往復も成立させる。 1リクエスト1レスポンスではなく、1リクエストを起点にサーバー・クライアント間で通信が走る、という絵が丁寧に描かれていきます。 手を動かさないと実感が湧きにくい領域ですが、Rackの上に素直に乗っているという話を聞いた瞬間、普段触っているWeb技術の延長線上で捉えていい話なのだ、と急に距離が近く感じられました。 そして前半の締めでkoicさんが置いた次のようなニュアンスの一言が、個人的に一番刺さっています。 「AIになってガラッと変わったと思われるが、Linuxであるとか低レイヤの世界は何も変わっていなくて、我々はその上で開発をしているに過ぎない」 弊社でもたびたび話題に上がる「AIの台頭によりエンジニア自身にとってはむしろ基礎が大事になっていく」という考え方と一致しており、強く共感しました。 後半: この1年間の試行錯誤 後半はトーンが少し変わりました。 「1年間いろいろ試行錯誤してきたが、うまくいかなかったことが多かった。その話をします」とkoicさんが率直に切り出します。 成功譚ではなく、試行の経過と現在地の共有だ、というモードに切り替わりました。 最初のアイデアはシンプルで、RuboCopの結果をJSON構造でMCP化すればAIフレンドリーになって良いのではないか、というものでした。 しかし実際に手を動かしてみると、RuboCopはそもそも著名なgemなので、AI側もすでに相当学習していたように感じられた、と振り返ります。 わざわざMCPの皮を被せなくても、ある程度のことは既にできてしまう相手だった、ということです。 アイデアを広く募集して議論もしたものの、寄せられたものをそのまま実装して全員が喜ぶ機能になる自信は持てなかった、とも続きます。 結びへ: 決定性と非決定性、そしてElicitation そこから結びに向けて「RuboCopはこれまで、インプットに対して結果が一意に定まるものだった」と改めて位置づけ直されます。 「決定性こそがLinterとしての価値だった」という前提を言葉にしたうえで、そこに非決定性を持つLLMを組み合わせたら何ができるのか、と続きました。 具体例として並べられたのは、LLM側に委ねるSamplingと、ユーザーに聞き返すElicitationでした。 どちらもサーバーからクライアントに問い合わせを返せる仕組みですが、自分の耳に特に残ったのはElicitationのほうです。 ユーザーに対して定まったフォーマットの質問と回答フォームを返せる仕組みで、「この修正、どう進めたい？」と聞き返す余地をMCPの上で作れる、という話として置かれていました。 決定性のあるRuboCopの流れのなかに人間に問いを返すポイントを差し込み、そこを挟んだ非決定性を許容する。 決定性を捨てる話ではなく、どこで問いを立て、どこで非決定性を受け入れるかの設計の話として受け取りました。 この時私が思い出したのは、自チームでRuboCopのルール改廃を議論する時の話です。 一元的に適用するか悩ましいものが出てきたとき、その悩みには既存コードの暗黙的な規約、各エンジニアの思想や経験、copとして定義されているベストプラクティス、と様々な要素が絡んでいます。 これらは機械的に一意には定められないものです。 この統治過程にLLMが自然な形で介入し、対話を経てLinterに落とし込んでいくのはありそうな役割だと感じました。 (それをRuboCopの機能として提供されてユーザーが嬉しいかはさておき) ちなみにMCPの規格としてElicitationが発表された当時、弊社でも管理者向けのLocal MCP Serverにこれを組み込む事例があり、『生成AI時代のサービス運営管理 - MCP Server for Administratorの実践 -』（2025年9月16日公開）としてまとめられています。 tech.findy.co.jp 一方通行になりがちなMCPのやりとりに confirm / approveのステップを挟むという考え方は、koicさんが当日RuboCopの文脈で示したElicitationの位置づけとそのまま重なるものでした。 聴き終えて腹落ちしたこと 少なくともセッションの内容は「RuboCop x MCPのベストプラクティスがバシッと決まっている」わけではないということです。 むしろ、当事者として踏み抜いた人しか持ち得ない肌感を、苦労ごと公開してもらった30分だった、というのが近いと思います。 文字にするとシンプルですが、現場で聴講した皆さんにはkoicさんの試行錯誤と苦労が生々しく伝わっていたのではないかと思います。 現地参加する醍醐味をこういうところにも改めて感じました。 MCP化が思ったほど刺さらなかったこと、アイデアを集めても一意の答えに収束しないこと、Human in the Loopをどう設計するかが実装より先にあること。 どれも、ドキュメントや事例紹介を眺めていても掴めない、当事者として踏み抜かないと分からない種類の手触りです。 前半と後半を通して一本の線で繋がっていたのは、RubyツールチェインをAI時代にどう位置づけ直すかという問いだったように思います。 Streamable HTTPという具体的な技術基盤の話と、RuboCop x MCPと
- Ruby
- RuboCop
- MCP
- 生成AI
Findy初のモバイルアプリ開発におけるReact Nativeのリアル 〜技術選定の裏側と実践的OSS活用〜
こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 先日、「React Native Lunch Talk ～いま選ばれる理由とアプリの現在地～」にて、「新規サービス開発におけるReact Nativeのリアル〜技術選定の裏側と実践的OSS活用〜」というテーマで登壇しました。 本記事は、その発表内容を改めてテックブログとして書き起こしたものです。 発表では時間の都合で駆け足になった部分や、質疑応答で答えきれなかった論点もあったため、本記事ではそのあたりも含めて踏み込んで書いています。 背景：Findy Events β版の開発 前回の記事 でも少し触れましたが、昨年、Findy初のモバイルアプリ「Findy Events」をα版としてAndroidアプリのみリリースしました。 現在はα版から得た学びをもとにUI・UXをフルリニューアルし、技術カンファレンス向けのiOS/Androidアプリとしてβ版のリリースを目指して開発を進めています。 Findy Eventsが長期的に目指しているのは、「カンファレンスでの学びとつながりを、その場限りで終わらせず継続的な成長の資産に変える」ことです。 β版では、その第一歩として、カンファレンス当日の体験をスムーズにする次のような機能を提供予定です。 QRコードを提示してのチェックイン 予約済みセッションやタイムテーブルなど、カンファレンス情報の閲覧 カンファレンス前日やセッション開始前に届くリマインダーPush通知 本記事では、そんな新規モバイルアプリの立ち上げにあたって、なぜReact Nativeを選ぶに至ったのか、そしてOSS選定や実装で直面したリアルな所感について紹介します。 前回の記事 では技術選定の結論だけを紹介しましたが、本記事ではその判断に至るまでの比較過程やOSS選定の裏側までを踏み込んで書いています。 背景：Findy Events β版の開発 React Nativeの技術選定の背景 OSSモジュールの選定と活用事例 独自選定の事例1：Sign in with Apple 独自選定の事例2：UIライブラリ React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した OSS活用で感じたこと AI時代に、今からReact Nativeをやる意味 まとめ React Nativeの技術選定の背景 まず触れておきたいのは、「なぜ数ある選択肢の中からReact Nativeを選んだのか」という話です。 Findyにとって初のモバイルアプリ開発。しかも、技術選定を一から設計できる、エンジニア冥利に尽きる環境です。 ただ、自由度が高いということは、言い換えれば判断の重みも大きいということ。「モバイルアプリを開発する」と一言で言っても、その道筋はひとつではありません。 出発点として置いたのが、次の3つのアプローチの比較です。 最適な開発手法は、置かれた環境と考え方で変わる。これが私の基本スタンスです。 そして今回の前提は、「最小リソースで最速リリース」。この一点に照らして、まずCross Platformを選びました。 次に、Cross Platformの中から、国内外で実績が豊富なFlutterとReact Nativeの2つに絞って比較しました。 次の表は、iOSエンジニア出身である私の主観も踏まえて、2025年8月頃に整理したものです。 一見、表だけを見ればFlutterが優位に映ります。 正直なところ、私自身も最初はFlutterに馴染みを感じていました。 それでも最終的に選んだのは、React Nativeです。 決め手は、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」の掛け算。この2軸をかけ合わせることこそ、「最小リソースで最速リリース」という目標に最短で近づく道だと確信しました。 仮にFlutterを選べば、私だけでなく将来参画するメンバー全員に一定の立ち上げコストがのしかかります。特にモバイルエンジニア出身でないメンバーほど、負担は大きい。 対してReact Nativeなら、ReactとTypeScriptの素養を持つメンバーが多い今の組織にそのまま馴染みます。 自分さえ立ち上がってしまえば、その後の開発速度は中長期的に最も出せる。これが最終的な決め手です。 具体的に、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」についてですが、「組織のアセット」としては、 社内の優秀なWebフロントエンドエンジニアからReactやTypeScriptの知識提供、レビュー協力を得られる React製の既存プロダクトの設計思想やソースコードを参考にできる という期待感がありました。 また、「モバイルエンジニアとしての自身のナレッジ」として、 iOS/Androidのプラットフォーム特性への理解 プッシュ通知などのモバイル固有の課題への対応力 を活かすことができると考えていました。 「社内のWeb資産をどこまで活かすことができたのか？」という部分が気になる方もいらっしゃるかもしれません。結果としては、次の技術スタックのとおり、組織のアセットをフル活用することができました。 実は、アーキテクチャに関しても、既存のWebプロダクトをほぼ流用する形で開発しています。 つまり、設計思想や実装パターンまで踏み込んで参考にできるほど、React NativeはReactと親和性が高いということです。 OSSモジュールの選定と活用事例 続いて、OSSモジュールの選定についてです。 iOSエンジニア出身の私がReact Nativeに触れて最初に感じたのは、「とにかくOSSが豊富」ということ。 ただ、裏を返せば「多過ぎて、どれを選べば良いか迷う」という別の課題が立ち上がってきます。 そこで採った方針は、Expo公式ドキュメントを「羅針盤」として活用すること。 Expo公式ドキュメントは非常に充実していて、Expo公式モジュールはもちろん、推奨される3rd Party OSSも明記されています。第一候補をここに置くだけで、選定コストは大きく圧縮できるというわけです。 もちろん、これで100%をカバーできるわけではありません。その場合は、プロダクトのコンテキストに合わせて独自に選びます。 ここからは、その独自選定した2つのOSSを紹介します。 独自選定の事例1：Sign in with Apple モバイルアプリの認証では、GitHub・Google・Appleの3つのOAuth認証を新規に導入する方針を採りました。中でもSign in with Appleは、iOSの審査要件として必須の機能です。 そこで選定軸に据えたのは次の2点です。 審査で認証ボタンのデザインも厳格に確認されるため、iOS SDK標準のASAuthorizationAppleIDButtonを内部で利用していること iOSだけでなくAndroidでもSign in with Apple機能を提供できること Expo公式には expo-apple-authentication があるものの、Androidが対象外。今回は見送りました。 最終的に選んだのは、両OSに対応した react-native-apple-authentication です。 独自選定の事例2：UIライブラリ 冒頭で述べた通り、自社初のモバイルアプリということもあり、社内にモバイル用のデザイン資産はありません。「最小リソースで最速リリース」を実現するには、UIライブラリの活用が欠かせない要素になります。 選定軸に据えたのは次の2点です。 豊富なUIコンポーネントが提供されていること iOSエンジニア出身の自分にとって、学習コストが高すぎないこと 実はα版では Tamagui を採用していました。ただ、β版でUI・UXをフルリニューアルすることが決まり、より要件に合致するライブラリを改めて探すことに。 たどり着いたのが、選定軸2点をしっかり満たす HeroUI Native です。 ここで一つ頭を悩ませたのが、採用を決めた当時（2026年1〜2月頃）のHeroUI Nativeがまだβ版だったこと。利用によって課題が顕在化するリスクを抱えての判断になります（※現在はstable版が提供されています）。 そこで採った工夫が、「HeroUI NativeのWrapper Componentを実装し、画面側からは直接HeroUI Nativeに触れない構成」にすること。 影響範囲をWrapper層に閉じ込めておけば、将来の差し替えや仕様変更への耐性が確保できる。β版OSSを採用する際のリスクヘッジとして、有効な型の一つだと感じています。 React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した React Nativeを選んだ結果として率直に感じたのは、「AI時代と言えど立ち上がりにはそれなりに苦労した」ということ。 実は10年ほど前に少しだけReactに触れたことがあったのですが、React HooksやLifecycleに相当する考え方はほぼ初学者の状態。概念の再学習が必要でした。 また、TypeScriptも「Swiftと似て非なるもの」であることを痛感します。 型による安全性という思想は近いものの、asによるキャストやenumがベストプラクティスとしては非推奨とされている点など、Swift感覚で書くと足をすくわれる場面が少なくありません。 一方で、React Native自体に対するハードルはそれほど感じません。理由は次の2つです。 宣言的UIによるUI構築は、SwiftUIで経験していた プッシュ通知など、モバイル固有機能の仕組みそのものを理解していた LT会では「どうやってReact Nativeを勉強したか？」という質問もいただきました。取ったアプローチは、過去にSwiftで開発していた個人アプリをReact Nativeで書き直してみるというもの。 題材を一から考えずに済む上に、Swift版という答え合わせの対象がある状態で進められるため、SwiftUIとの共通点や差分を体感しながら学べます。 こうして実感できたのは、React Nativeを選んでも、モバイルエンジニアとしての経験や強みは十分に活かせるということです。 OSS活用で感じたこと OSS活用の面でも、幾つか印象的な気付きがあります。 1つは、OSSの更新速度の速さです。 React / React Native界隈は更新サイクルが早く、iOS Nativeとの文化の違いを肌で感じます。 加えて、脆弱性検知などのエコシステムが整っており、開発者体験として足かせになっていない点も心強いところです。 もう1つは、Expoの利便性への驚きです。 ExpoはReact Native界隈ではデファクトスタンダードと言える立場を確立しており、信頼性も高く、証明書やリリース周りといった「モバイルアプリ開発ならでは」の知識を手厚くカバーしてくれます。 これは、Webフロントエンドエンジニアがモバイルアプリ開発に参入するハードルを相当下げていると言って良いでしょう。 実際、Webフロントエンドエンジニアの方から「React Nativeって実際どうなの？」と聞かれた際は、Expoのおかげで「モバイルアプリ開発は想像以上に始めやすい」と答えることができています。 AI時代に、今からReact Nativeをやる意味 最後に登壇の中では時間の都合で踏み込めなかった論点について書いておきます。 それは、「AI時代に、今からReact Nativeをやることに意味はあるのか？」という問いです。 個人的には、少なくとも次の3点で意味があると考えています。 1つ目は、iOSとAndroidを同時に立ち上げる中で、OS間の差分に向き合う経験が積めることです。 Cross Platformと言えど、プッシュ通知や認証、OSの作法といった領域では差分が必ず顔を出します。 AIに任せれば書ける時代だからこそ、差分の勘所を自分の中に持っているかどうかが効いてくると考えています。 2つ目は、アーキテクチャ選定やOSS選定といった、プロダクトの土台を作る判断を経験できることです。 ゼロからモバイルアプリを立ち上げる機会はそう多くなく、「何を選んで、何を選ばなかったか」を
- React Native
- TypeScript
- モバイルアプリ開発
AI活用を推進するためにファインディが下した、1つの小さな決断
こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 「AI活用を推進したいが、思うように進まない」──この悩みを抱えているエンジニアの方は、少なくないのではないでしょうか。 ファインディも例外ではありませんでした。2025年の上半期までは、普段の業務をやりつつ片手間でAIのキャッチアップや社内展開を進めていました。 今回は、そこから潮目が変わるきっかけとなった決断と、その後1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの過程を紹介します。 同じようにAI活用の推進に手応えのなさを感じている方の参考になれば幸いです。 片手間で追いかける限界 1つの小さな決断 最初にやったこと：Findy Team+で現状を知る Claude Code Pluginsで展開を仕組み化する 継続的な浸透：毎日の通知と月一の共有 結果：PR作成数が前年比で約1.5倍に 振り返って気づいたこと まとめ 片手間で追いかける限界 2025年の上半期まで、ファインディの開発組織では興味と意欲のあるエンジニアが、普段のプロダクト開発と並行して、最新の動向をキャッチアップし、使えそうなツールを社内で共有していました。いわゆる"片手間"で進めるスタイルです。 最初のうちは、これでも回っていました。しかし、次第にこのやり方では追いつかなくなっていきました。 理由は単純で、AIのアップデートが多すぎたからです。 ほぼ毎日のようにアップデートが公開され、新しいエージェントや機能が登場する。上半期の半ばあたりから、キャッチアップに充てる時間がどうしても足りないという感覚が強くなっていきました。 努力で巻き返せるレベルの遅れではなく、物量的に両立が不可能な状態に近づいていました。 1つの小さな決断 この状況を動かすために取った1つの決断が、「AI推進だけを専任で担うポジションを作る」というものでした。 その人を普段のプロダクト開発業務から外し、AI推進そのものを業務にする。兼務で時間を増やすのではなく、業務から外して全振りするという発想への切り替えが、このポジションの本質です。 この判断の背景には、「全員が業務の10%をAI推進に充てるよりも、1人が100%を充てたほうが組織としての前進量は大きい」という確信がありました。 兼務スタイルで各自が少しずつ動く形では、日々のAIアップデートの速度には追いつかない。仮に追いついたとしても、それらを使ってアウトカムを出せるまでが遠すぎました。一方、1人が専任で全力でコミットできれば、情報の集約・検証・社内展開を最速のスピードで回せると判断しました。 AI推進ポジションのエンジニアの仕事は、AI活用と組織への展開そのもの。日々のプロダクト開発タスクは原則持たず、AI関連の動向調査・検証・社内展開・仕組み化に集中してもらう形にしました。 プロダクト開発の手を減らすことに対しては、当然ながら社内でも葛藤がありました。それでも踏み切れたのは、片手間で続けていた半年間を通して、兼務では絶対に追いつかないという確信があったからです。 最初にやったこと：Findy Team+で現状を知る 専任ポジションを置いてから最初に取り組んだのは、派手な施策やスキル作成などではなく現状把握でした。 組織全体のAI活用を推進するといっても、感覚だけで動くと認識のギャップが生まれます。そこで、Findy Team+を使ってチーム単位・メンバー単位でAI活用の度合いを可視化するところから始めました。 ここでわかったのは、想定していたよりAIの恩恵を受けられていない、という事実でした。 もう少し掘り下げると、チームや事業部ごとにAIの活用度合いに明確な差があり、同じ役割のエンジニアでも使っているスキル・エージェントにばらつきがあることが見えてきました。よく使えている人の工夫が、他のメンバーに自然には伝わっていない状態です。 組織として全員で底上げされているのではなく、一部の熱量の高いメンバーが先行している状態だった、というのが当時の姿でした。 Claude Code Pluginsで展開を仕組み化する 現状把握でわかったスキル・エージェントのばらつきを埋めるために選んだ打ち手が、Claude CodeのPlugins機能を使った社内展開です。 Plugins機能については以前の記事でも紹介しています。 tech.findy.co.jp Claude CodeのPluginsは、スキル・エージェント・カスタムコマンド・各種設定などを1つのパッケージとして配布できる仕組みです。AI推進のエンジニアが作成した開発用スキルなどをプラグインとしてインストール可能にしておけば、各メンバーが自分の環境でコマンド1つで使える状態になります。 この仕組みに乗せることで、便利なコマンドや開発標準化のスキルなどをそのまま開発組織全体に配布できるようになりました。新しく入ったメンバーも初日からファインディのAI活用の恩恵を受けられるようになっています。 実際に、ファインディの開発組織で運用しているスキル・エージェントの一部は、次の記事でも紹介しています。 tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp いずれも個人の工夫として始まったものを、プラグイン化して全員に配布できる形にしたものです。 継続的な浸透：毎日の通知と月一の共有 プラグインを配布するところまで作っても、更新を知ってもらえなければ次第に忘れられてしまいます。そこでファインディでは、配布の仕組みに加えて、更新が自然と目に入る状態を保つ工夫を並行して走らせています。 1つ目は、プラグインの更新内容をSlackの専用チャンネルに毎日通知する仕組みです。新しく追加されたスキルや、アップデートされたコマンドが翌日には目に入る状態にしておくことで、いつの間にか変わっていたではなく、今日こんな機能が追加されたという鮮度で情報が流通します。 2つ目は、月一のエンジニア定例のなかに、プラグインやAI活用の使い方を共有する時間を設けたことです。ドキュメントだけでは掴みきれないニュアンスやちょっとしたコツを口頭で流す場として、思った以上に機能しています。 プラグインという土台に加えて、通知と定例という継続的な露出。この組み合わせが、AI活用を一部のメンバーだけで閉じさせず、組織全体に浸透させる力になっています。 結果：PR作成数が前年比で約1.5倍に こうした取り組みを進めた結果、1人あたりのプルリクエスト作成数は前年比で約1.5倍になりました。 AI活用が進んだ実感というあいまいな言葉ではなく、開発のアウトプットそのものが定量的に伸びた、というのが大きなポイントです。 もちろん、プルリクエスト作成数は開発の速度やスタイルの指標の1つに過ぎません。それでも、組織としての変化が数字として見える状態になったこと自体が、AI活用のどこに投資すべきかを議論する大きな土台になりました。 振り返って気づいたこと 半年ほど取り組んで気づいたのは、専任を置いたから任せきる、では成り立たないということです。 専任1人ですべてを背負う構造にすると、その人自身がボトルネックとなってしまいます。専任の役割は、自分がすべてを実行することではなく、組織のAI活用を前に進めるための仕組みをつくること。 現場のエンジニア・マネージャーが自走するための土台を整え、みんなで良くしていくというスタンスが重要だと感じました。 まとめ ファインディのAI活用推進は、特別なツールや大がかりな制度改革ではなく、「AI推進だけを専任で担うポジションを作る」というシンプルで小さな意思決定から加速しました。 そこから専任が取り組んだのは、Findy Team+を使った現状把握、Claude Code Pluginsを使ったスキル・エージェントの社内展開、そしてSlack通知と月一定例による継続的な浸透。 いずれも派手さはありませんが、これらの積み重ねによって、1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの変化を生み出すことができました。 AI活用は一日にして成らず。小さな意思決定や地道な取り組みの積み重ねが、組織全体の大きな変化につながることを実感しています。 全員が10%ずつAI推進に充てるよりも、1人が100%を充てる。この発想の転換が、ファインディのAI活用を動かす原動力になっています。 AI活用が思うように進まないと感じている組織の責任者の方がいれば、制度や研修を考える前に、専任を置く（業務から外す）という選択肢を検討してみてください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- 生成AI
- 開発生産性
- 組織
- Claude
登壇スライドを30分で作る：Claude Codeで壁打ちからGoogle Slides生成までワークフロー化
こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディではClaude CodeのスキルやカスタムコマンドなどをPlugins経由で社内展開しています。 tech.findy.co.jp コードレビューやタスク分解といった開発業務の効率化が進む一方で、登壇準備はまだ手作業の割合が大きい領域です。話す内容を固めて、構成を考えて、スライドに落とし込んで、デザインを整えて……。発表の本質は「何を伝えるか」なのに、準備工程に時間を奪われがちです。 本記事では、この課題に対処するために社内Pluginsに作った登壇スライド生成スキルを紹介します。壁打ちによるコアメッセージの言語化からMarkdownスライド生成、Google Slidesへのエクスポートまでを一気通貫で行えるもので、壁打ちから完成まで30分で終わるようになりました。 登壇準備にかかる時間の内訳 NotebookLMを試して感じた限界 Claude Codeスキルという選択肢 ワークフローの全体像 壁打ちフェーズ：コアメッセージの言語化 テンプレート設計：発表時間から逆算するスライド枚数 Google Slides API テンプレートコピー方式 Markdownからスライドへの変換ルール デザインガイドラインの組み込み 70点の完成度で出す割り切り まとめ 登壇準備にかかる時間の内訳 登壇準備のどこに時間がかかっているかを振り返ると、スライドのデザインや配置よりも、その手前の工程が大きいことに気づきます。 前半は「何を話すか」の整理です。話したいことはぼんやりあるけれど、コアメッセージを一文にまとめるのが難しい。構成を決めても「この流れで聴衆に伝わるか？」と不安になって何度も組み替える。ここが一番時間を食います。 後半はスライドの作成とリハーサルです。ようやく構成が固まっても、今度はスライドツールを開いてフォーマットやデザインと格闘する。前半さえ効率化できれば、発表内容そのものの質を上げる時間に使えるはずだと考えました。 NotebookLMを試して感じた限界 最初に試したのはGoogleのNotebookLMでした。ソース資料を読み込ませてスライドを生成できる機能があり、期待して使ってみました。 ただ、実際に使ってみるといくつか壁がありました。出力がPDFや画像形式のため、生成後の編集が難しい点です。スライドの順番を入れ替えたい、テキストを修正したいといった基本的な操作ができず、結局ゼロから作り直す羽目になりました。 もう一つは、社内のスライドガイドラインに沿った出力が非常に難しかったことです。フォントやカラースキーム、ロゴの配置などは組織ごとにルールがあります。汎用的なAIツールではそこまで制御できず、ガイドラインに準拠させるための手作業が発生していました。 Claude Codeスキルという選択肢 これらの課題を踏まえて、Claude Codeのカスタムスキルとして登壇スライド生成ワークフローを自作しました。Claude Codeスキルを選んだ理由は、対話的なワークフローを自然に組めること、Markdownで中間出力できること、そしてAPIを叩いて外部サービスに連携できることの3点です。 開発したのは2つのスキルです。1つ目がMarkdownスライドの生成、2つ目がGoogle Slidesへの変換を担います。 ワークフローの全体像 スキルを実行すると、次の流れで処理が進みます。 参考URLやコードスニペットの収集（任意） 壁打ちでコアメッセージを言語化 タイトル・概要・発表時間の入力 テンプレートに基づく構成設計 Markdownスライドの生成 Google Slidesへのエクスポート（任意） 各フェーズを詳しく見ていきます。 壁打ちフェーズ：コアメッセージの言語化 このスキルで最も力を入れたのが壁打ちフェーズです。登壇準備で一番時間がかかるのは「何を伝えるか」を固める工程だからです。 スキルを起動すると、まず対象オーディエンス（テックリード、シニアエンジニア、EMなど）を選択します。次に「発表内容はすでに決まっていますか？」と聞かれ、「まだ漠然としている」を選ぶと壁打ちモードに入ります。 ? スライドに取り込みたいURLやコードスニペットはありますか？（任意） > なし ? 対象オーディエンスを教えてください（複数選択可） エンジニア系: ✔ テックリード ✔ シニアエンジニア マネジメント系: ✔ EM ? 発表内容はすでに決まっていますか？ > まだ漠然としている（一緒に考えたい） どんな発表をしたいですか？テーマや話したいこと、伝えたいことを 自由に教えてください。まだ漠然としていても大丈夫です。 壁打ちは次の順序で進みます。 コアメッセージの確定 — 「この発表で一番伝えたいこと」を1文に絞る 逆算による構成設計 — コアメッセージを結論として、聴衆が納得するために必要な情報を逆順に積み上げる タイトル・概要の決定 — 構成が固まった後に、コアメッセージが伝わるタイトルを考える ポイントは「逆算」というアプローチです。結論から遡って構成を組むことで、「話したいことを全部詰め込んだけど結局何が言いたいのかわからない」というよくある失敗を防ぎます。 実際のやり取りはこんな感じです。 > 生成AI時代のエンジニア育成について話したいんですけど、 まだ切り口が定まってなくて エンジニア育成×生成AIですね。テックリードやEM向けなので、 現場のリアルな課題感が求められます。 AI導入後に育成面で一番変化を感じたのはどこですか？ 学習速度、コードの質、それともチームの生産性でしょうか？ > AI導入後にシニアの生産性は上がったんですが、 若手のアウトプットの質がむしろ落ちていて。 AIの出力をそのまま使ってしまって、理解が追いついてない感じです なぜAIの出力をそのまま使ってしまい、理解が追いついていないと感じていますか？ > AIが出力したコードを理解せずにレビュー依頼するケースが増えていて、 結果的にリードタイムが悪化していることはわかった。 AI時代の今だからこそ原点回帰が必要。 なるほど。つまり「生成AI時代だからこそエンジニアの基礎力の価値が 上がっている。AIを"使う"側に立つには原点回帰が必要。」 ということを一番伝えたい、という理解で合っていますか？ > はい Claudeがコアメッセージを1文に言語化してくれるので、対話で壁打ちを進められます。コアメッセージが確定すると、逆算で構成を組んだうえでまとめを提示してくれます。 壁打ちの結果をまとめました！ タイトル案: 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 概要: 生成AIの導入でシニアの生産性は上がったが、若手のアウトプットの 質は低下していた。AIが出力したコードを理解せずにレビュー依頼する ケースが増え、結果的にリードタイムが悪化。基礎知識なきAI活用は 「AIに使われている」状態であり、今こそ原点回帰が必要だと気づいた 実体験を共有する。 コアメッセージ: 生成AI時代だからこそエンジニアの基礎力の価値が 上がっている。AIを"使う"側に立つには原点回帰が必要。 ? このまとめでスライド生成に進みますか？ > 進む テンプレート設計：発表時間から逆算するスライド枚数 スキルには3種類のテンプレートを用意しました。 standard — 20〜60分のカンファレンストーク向け。背景→本題→デモ→まとめの王道構成 lt — 5〜10分のLightning Talk向け。「結論ファースト」で1点突破 tutorial — 30〜40分のハンズオン向け。手順ごとに検証ステップを挟む 発表時間を選ぶと、テンプレートが自動選択されます。5分や10分ならLTテンプレート、15〜20分ならstandard、30分以上でハンズオン形式ならtutorialです。 スライド枚数は「1分1枚」を基準に算出しています。20分の発表なら15〜20枚。セクションごとの配分は、背景10〜15%、メインコンテンツ50〜60%、デモ15〜20%、まとめ・Q&Aで残りという割合で自動配分されます。 ? 発表時間を選択してください > 20分 テンプレート: standard（カンファレンストーク向け）を自動選択しました 目標スライド枚数: 15〜20枚 構成を設計しています... ? スライドに取り込みたいURLやコードスニペットはありますか？（任意） > https://tech.findy.co.jp/entry/2026/02/20/070000 URLの内容を取得しています... ✓ 取得完了: https://tech.findy.co.jp/entry/2026/02/20/070000 → 要点を抽出し、背景・メインコンテンツのセクションに反映します → 参考資料スライドにリンクを追加します Google Slides API Markdownで生成したスライドをGoogle Slidesに変換するスキルも開発しました。Google Slides APIを実行しており、OAuth2認証でユーザーのGoogleアカウントに紐づけています。 developers.google.com ? Google Slidesにエクスポートしますか？ > エクスポートする Google Slidesにエクスポートしています... ✓ エクスポートが完了しました URL: https://docs.google.com/presentation/d/1abc.../edit テンプレートコピー方式 今回は会社のスライドマスター（テンプレート）をGoogle Drive API経由でコピーし、そこにスライドを追加していく方式を採用しました。テンプレートには表紙・中扉・詳細ページのレイアウトが定義されており、Markdownの見出しレベルに応じて適切なレイアウトを選択します。 Markdownからスライドへの変換ルール Markdownのパース結果は、見出しレベルとボディの有無でスライドの種類を自動分類しています。 Markdownのパターン スライドの種類 デザイン # タイトル 表紙 背景画像あり ## 見出し + 本文あり 詳細ページ 背景画像あり ## 見出し のみ（本文なし） セクション区切り グレー背景 + 白文字 ##の中に###の小見出しが含まれる場合は、自動的にセクション区切り1枚 + 小見出しごとの詳細ページに展開します。たとえば「AI時代の到来と変化」の下に「変わったこと」「変わらなかったこと」の2つの###があれば、計3枚のスライドに分割されます。 デザインガイドラインの組み込み 会社指定のスライドガイドラインをスキルの定義ファイルに直接記述しています。フォントやカラーパレット、サイズといったルールをスキルの中で持ち、エクスポート時に各要素に適用します。 70点の完成度で出す割り切り 運用上、重要にしているのは「70点の完成度で一発出力し、残りは人間が仕上げる」という割り切りです。 AIが100点のスライドを作るのは現状難しいですし、目指す必要もないと考えています。スライドの完成度を70点から100点にするのは人間の感性が必要な部分です。逆に、0点から70点の工程（構成決め、テキスト配置、フォーマット統一）はAIの得意分野です。 この分業により最速で「壁打ち15分 + スライド生成5分 + 手動調整10分 = 30分」で登壇準備が完了するようになりました。 まとめ 今回紹介したスキルで作成されたスライドがこちらです。 登壇準備の工程をClaude Codeスキルで一気通貫にしたことで、壁打ちから完成まで30分程度で終わりました。 このスキルの価値は「スライドを自動生成すること」自体ではなく、「コアメッセージの言語化を対話で支援すること」にある点です。登壇準備で本当に時間がかかるのは構成やデザインではなく、「自分が何を伝えたいか」を整理する工程だったのだと、スキルを開発する過程で改めて実感しました。 登壇の機会があるエンジニアの方は、ぜひ挑戦してみてください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- Claude
- 生成AI
- エンジニア育成
Findy AI Meetup in Fukuoka #5 を開催しました — AI時代のエンジニア育成
こんにちは。ファインディ株式会社でテックリードマネージャーをしている戸田です。 2026年4月15日に、Findy AI Meetup in Fukuoka #5を福岡で開催しました。 今回のテーマは「AI×育成 AI時代のエンジニア育成」です。 この記事では、当日の登壇内容を振り返りながら、生成AI時代におけるエンジニア育成で私たちが直面した課題と、そこから見えてきた「変わらない大切なこと」を紹介します。 https://findy-inc.connpass.com/event/383906/findy-inc.connpass.com 当日参加くださったみなさま、ありがとうございました！ Findy AI Meetup in Fukuokaについて 登壇内容 新メンバーのために、シニアエンジニアが環境を作る時代 エンジニア以外のメンバーがPull requestを作るようになった Pull requestの品質が課題に AI時代のシニアエンジニアができること 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 生成AIでコードの作り方が変わった 現場で起きた逆説 AIに「使われる」のではなく「使う」 原点回帰 — 基礎力の価値が上がっている 明日から試せるアクション AIの出力を必ず検証する習慣をつける 基礎知識を体系的にインプットする 「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む まとめ Findy AI Meetup in Fukuokaについて Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。 生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。 福岡での開催は今回で5回目となりました。回を重ねるごとに参加者同士の顔なじみも増え、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。 登壇内容 新メンバーのために、シニアエンジニアが環境を作る時代 1つ目の登壇は、フロントエンドエンジニア/テックリードの新福が担当しました。 エンジニア以外のメンバーがPull requestを作るようになった 生成AIの普及により、エンジニア以外のメンバーでもコードを書けるようになりました。 ファインディでは、デザイナーがClaude Codeを使ってUIドキュメントを作成したり、PdMがCursorでモックを作成するといった事例を確認しています。 直近では、エンジニアがBizメンバー向けにNotion MCPを用いた求人票改善ツールを開発しました。 tech.findy.co.jp 実はこの話にはまだ続きがあります。しばらくすると、今度はBizメンバーが自分でプロンプトを修正し、エンジニアにPull requestを送るようになったのです。 コミットやPull requestの作り方を誰かに教わったわけではありません。AIチャットに聞きながら操作し、Pull requestを作り上げていました。AIチャットが開発の入口となる時代、その波は既にエンジニア以外のメンバーにも届いています。 Pull requestの品質が課題に 一方で、コミットメッセージのフォーマットや命名規則など、開発ルールを知らないまま作られたPull requestには品質面での課題がありました。レビュアーの負担が増え、指摘のたびに手戻りが発生するような事態は避けたいです。 この解決策としては、エージェントスキルの整備が有効と考えられます。 AIチャットから自然言語でエージェントスキルを呼び出すだけで、誰でも開発ルールに準拠したPull requestを作成できます。 AI時代のシニアエンジニアができること シニアエンジニアはこれまで、知識を言語化して伝えること、コードレビューによる品質担保、ペアプロでの指導といった形で、チームの品質と成長を支えてきました。 これらの役割は引き続き重要ですが、AI時代はそれに加えてカスタムインストラクションやエージェントスキルの整備などもシニアエンジニアの仕事になると思われます。 誰でも参加できる仕組みを作ることは、教える相手を選ばない育成インフラの構築につながります。入社1週目の新メンバーが初日からコントリビューションを体験し、「何を作りたいか」に集中できる環境を整えること——それがAI時代のシニアエンジニアの新しい役割となるかもしれません。 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 次にテックリードマネージャーの戸田が担当しました。 生成AIでコードの作り方が変わった 生成AIの登場によって、開発の進め方は大きく変わりました。「調べる→試す」だったプロセスが「AIに聞く→コピペ」に変わり、詰まる時間は激減しました。 基本的な知識がなくても動くコードが手軽に出せるようになった一方で、公式ドキュメントよりAIへの問い合わせが先になりがちで、「なぜ動くのか」を知らずに実装する機会が増えていました。 現場で起きた逆説 AI導入後、シニアエンジニアのアウトプット量は増えていました。しかし若手エンジニアについては逆の現象が起きていました。 Pull requestの質が落ち、AIが出力したコードを理解せずにレビュー依頼を出すケースが増えたのです。その結果レビューコメントが増え、レビュー負担が上昇し、リードタイムは悪化していました。 トータルで見ると、チーム全体の生産性はさほど変わっていなかったのです。「AIで効率化できた」という実感とのギャップがそこにはありました。 AIに「使われる」のではなく「使う」 この状況を整理すると、若手エンジニアの一部はAIに「使われている」状態でした。 AIが出力したコードが正しいかどうかを判断できず、間違いに気づかないままレビューを依頼する。ハルシネーションを見抜けず、誤った実装をしてしまう。AIに正しい指示を出せないから「作ってください」としか言えず、意図と異なるコードが出てくる。 「使う」状態はその逆です。自分の意図に沿ってAIを動かせる。正誤を判断できるから間違いをその場で弾ける。正しい指示が出せるから意図通りの出力が得られる。 この違いを分けるのは、エンジニアとしての基礎力です。 基礎知識がなければ、正誤判定も正しい指示もできません。動くものを作るレベルは「AIに使われている」状態であり、正しい方法と手順で作るレベルが「AIを使う」状態です。 原点回帰 — 基礎力の価値が上がっている 生成AI時代だからこそ、基礎力の価値はむしろ上がっています。基礎知識、座学、資格取得といった、一見すると地味な取り組みが重要性を増しているのです。 ファインディでは、基本情報技術者試験相当以上の資格を取得することを推奨しています。広く浅い基礎知識を体系的に習得できるという点で、コスパもタイパも高い学習方法です。合格した場合は受験料を会社が負担する制度も用意しています。 基礎力がつくとAIの出力に対する正誤判定の質とスピードが上がり、レビュー前のセルフチェックで問題を潰せるようになります。ハルシネーションを見抜けるようになり、「何かおかしい」と気づける感覚が身に付きます。 さらに、AIに正しい方法と手順で指示を出せるようになるため、レビューでの議論が設計やパフォーマンス、UI/UXといった本質的な内容になります。 今回の登壇と資料が皆さんの参考になると幸いです。 ■ 明日から試せるアクション ■ 明日から試せるアクション 登壇内容を踏まえて、明日から実践できることを整理しました。 AIの出力を必ず検証する習慣をつける AIが生成したコードをそのままコピペするのではなく、「このコードは何をしているか」「なぜこの実装なのか」を自分の言葉で説明できるか確認してからレビューに出しましょう。説明できないコードはレビューに出すべきではありません。 基礎知識を体系的にインプットする 基本情報技術者試験の教材は、ネットワーク、データベース、セキュリティ、アルゴリズムなど、開発の土台となる知識を広くカバーしています。資格取得そのものが目的ではなく、AIの出力を正しく評価するための「物差し」を手に入れることが目的です。 「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る すべてをAI経由にするのではなく、まず公式ドキュメントで基本を理解したうえでAIを活用する、という順序を意識するだけで、コードの理解度は大きく変わります。 チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む シニアエンジニアが持つ暗黙知を仕組みとして整備することで、新メンバーやエンジニア以外のメンバーでも開発ルールに準拠したPull requestを作れるようになります。「教える」から「仕組みで支える」への転換です。 まとめ 今回のFindy AI Meetup in Fukuoka #5では、AI時代のエンジニア育成というテーマで2つの登壇を行いました。 登壇を通じて伝えたかったのは、AI時代で環境は大きく変わったが、変わらないこともあるということです。 手を動かし、汗をかき、積み重ねた基礎と経験は絶対に裏切りません。同時に、シニアエンジニアがエージェントスキルやカスタムインストラクションといった仕組みを整備し、誰でも開発に参加できる環境を作ることも重要です。 AI時代だからこその原点回帰として、エンジニアとしての基礎力を鍛えていきましょう。 Findy AI Meetup in Fukuokaは今後も継続して開催していきます。福岡のエンジニアの皆さんとオフラインでつながれるこの場を、これからも大切にしていきたいと思っています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- 生成AI
- エンジニア育成
- オンボーディング