GA4のGeminiを活用した新機能「Ask Advisor」（旧 Analytics Advisor）について検証します。

1. はじめに こんにちは、スタンバイでデータエンジニアを担当している権藤です。 私が所属する Data Platform Group では、データ基盤の開発・運用・保守を担当しています。 今回はデータ基盤の移行について、計画〜実行までの過程を紹介していきます。 2. 移行の背景と計画 移行前のアーキテクチャの問題点 当時開発・運用していたデータ基盤について様々な課題が発生したため、リプレイスすべきだろうという話が挙がりました。 (以下、旧データ基盤と呼びます) 旧データ基盤の構成図は以下になります。 移行前のアーキテクチャ図 代表的な技術スタックは以下です。 スタンバイのサービスは AWS 上に構築されているため、技術スタックも AWS のものをメインで用いています。 ストレージ: S3 データカタログ: Glue Data Catalog ETL 処理: Glue Job (PySpark) 集計処理: Athena オーケストレーション: Amazon Managed Workflows for Apache Airflow (MWAA) BI ツールなど: Redash、Looker Studio 課題は山積みだったのですが、闇雲に「モダンデータスタックを使ってイケてるシステムに作り変えたい」とするのは危険と考え、まずデータ基盤が抱えている課題を1つ1つ洗い出していくことにしました。 課題の可視化・細分化を行うにあたり、実施したものが以下になります。 データマネジメント成熟度アセスメント データ基盤利用者へのアンケート データマネジメント成熟度アセスメントの実施 データマネジメント成熟度アセスメント (Data Management Maturity Assessment、以下 DMMA と呼びます) とは、 DMBOK2 で以下のように定義されています。 組織内で実施されているデータ関連業務に対してランク付けする方法。データマネジメントの現状とそれが組織に与える影響を明らかにする。 DMBOK2 で定義されているデータマネジメントの知識領域を大分類として合計 77 個の質問項目を用意し、それぞれ5段階評価を付けてその平均スコアをレーダーチャートにするという手法をとりました。 DMMAスコア これらの質問へはデータマネジメントに関わるメンバー、今回だとデータエンジニアが回答しました。 実務とデータマネジメントの知識領域との双方を把握していないと回答自体が難しく、また実行可能な改善計画を立てるため、データエンジニアを中心に実施しました。 DMMA 実施によって、以下の改善効果を得ることができました。 知識領域ごとの強み・弱みが明らかになる 定期的な DMMA の実施により、データマネジメントの成熟度を測ることができる データ基盤利用者へのアンケートの実施 先述の DMMA の実施は主に開発者 (データエンジニア) を対象としたものでしたが、こちらは利用者を対象としたものです。 開発者からは見えない視点での評価・意見を拾うことが目的です。 アンケートの質問項目は、回答者のハードルを下げるために極力選択式としました。(別途、自由記述の質問項目も設けています) 質問の一例は以下になります。 主な利用目的は？ よく利用する周辺ツールは？ よく利用するデータは？ 現在のデータ基盤に対する満足度は？ データ基盤について現在直面している問題は？ アンケートの実施によって、利用者の課題感・要望が明らかになりました。 具体例を以下に示します。 様々なデータを同じデータ基盤上で扱いたい (複数のデータを統一の SQL で参照したい) データの関係性がわかりにくい (データリネージュ・メタデータの不足) KPI の計算式を統一したい (分析者によって SQL の記述方法が異なるため統一したい) データの欠損が一部あり、分析がしづらい (データ品質の不足) 重点課題の設定 これら2つの調査結果を統合し、データマネジメントの観点で整理した結果、解決すべき「5つの重点課題」とその解決ソリューションを定義しました。 1. 非効率なデータ統合 GA4やSalesforceなど、事業上重要とみなされているデータが基盤に取り込まれておらず、社内にデータが散在（サイロ化）している。 現在の S3 + Athena 構成では新しいデータの追加に作り込みが必要で、気軽に追加できないため、データ利活用者が複数のシステムをまたいで手作業でデータを結合するなどの無用な工数が発生している。 2. ER 図の欠如 テーブル間の関係性（キーの結合やレコードの対応関係）を直感的に表現するER図が提供されていない。 そのため、データ基盤の利用者にとってテーブル同士の関係が分かりにくく、データ活用の障害となっている。 3. 不完全なデータリネージ テーブル間の派生関係（どのテーブルから何が作られたか）を示すリネージは提供されているが、完全なものではない。 S3 + Athena 構成ではデータ変換の自由度が高すぎてプロセスが統制されていないため、一部でリネージが取得できなくなっている。 4. 部署や担当者ごとの KPI 計算の不一致 事業上の主要なKPI（セッション数など）の計算式や条件が、部署や担当者ごとに異なってしまう問題が発生している。 これはデータのサイロ化を招くだけでなく、利用者が「正しいSQLの書き方が分からない」という悩みにもつながっている。 5. データ品質テストの不足 データ品質のテストがごく一部でしか行われておらず、不備があっても長い間気づけないリスクがある。 実際に過去、カラム内容の不備が数週間発見されず機械学習モデルに影響を与えた事例もあり、基盤に対する利用者の信頼を損なう要因となっている。 課題解決方針 アセスメントとアンケートによって特定された5つの重点課題に対し、私たちは単なる部分最適ではなく、データ基盤のアーキテクチャ全体を見直す形で以下のような解決方針を策定しました。 1. 効率的なデータ統合 外部データ連携に強みを持つモダンなDWH製品の導入と併せ、Fivetran や Airbyte などのデータ統合ツールを活用する。 これにより、GA4やSalesforceなどのサイロ化されたデータを、最小限の開発工数で一元管理できる仕組みの構築を目指す。 2. ER 図の自動提供 手動によるドキュメント運用の限界を打破するため、dbt などのデータモデリングツールを導入する。 コード（DDL）からER図を自動的に生成・更新し続ける仕組み（dbterdなど）をパイプラインに組み込み、データの認知コストを下げる。 3. 完全なデータリネージの確立 データ変換プロセスをすべて dbt 配下に集約してフローを統制し、データの変遷をトレース可能な環境を構築する。 4. ビジネスロジック （KPI） の共通化 データと利用者の間に dbt Semantic Layer などの「セマンティックレイヤー」を導入する。 部署ごとに散在していたKPIの計算ロジックを一箇所にコードとして集約し、全社で「信頼できる唯一のソース（SSOT）」を参照できる状態を確立する。 5. データ品質テストの自動化 サイレントなデータ不備による信頼低下や下流への悪影響を防ぐため、dbt のテスト機能をパイプラインの実行フローに組み込む。 重要なテーブルやカラムに対する「非nullチェック」や「一意性チェック」を自動化し、異常を早期発見できる体制を整える。 3. 技術選定 前章の課題解決策として「dbt」という単語が何度か登場しましたが、本章ではなぜ数あるツールの中から dbt を選んだのか、そしてその実行基盤（DWH）としてなぜ Databricks を選定したのか、その詳細なプロセスを記載します。 dbt の採用 dbt とは Data Build Tool の略で、DWH 上でのデータ変換（Transform）を SQL で管理するツールです。 https://www.getdbt.com/ SELECT 文を記述するだけで変換処理をモジュール化でき、テストによるデータ品質の自動検証、ドキュメントの自動生成、テーブル間のリネージ追跡といった機能を標準で備えています。 解決すべき5つの課題の多くが「データ変換とガバナンス」に集中していたため、以下の理由から dbt の採用を早期に決定しました。 ELT アーキテクチャへのシフトによる工数削減 従来の Glue Job (PySpark) を中心とした複雑な ETL から、SQL を中心とした ELT アーキテクチャへ転換した。これにより、複雑な Spark コードのメンテナンスから解放され、学習コストを抑えつつ開発スピードを最大化できる エコシステムの成熟度とポータビリティ 主要な DWH との Adapter が公式・コミュニティ双方で活発に開発されており、将来的なインフラの変化にも柔軟に対応できる信頼性を評価した。 「データ品質」と「リネージ」の標準装備 DMMA で特に低スコアだったデータ品質とリネージの課題に対し、dbt test による自動検証や、プロジェクト構造から自動生成されるデータリネージ機能が決定打となった。 ビジネスロジックの一元管理 dbt Semantic Layer 等の活用により、部署間で散在していた KPI 計算ロジックを統合し、「信頼できる唯一のソース（SSOT）」を構築できる点を重視した。 DWH 製品の選定：検証プロセスと結果 dbt を導入するためには、当時の構成（S3 + Athena）では公式な Adapter サポートが不十分でした。 （※ 現在は dbt Labs による公式サポートが提供されています。） dbt のポテンシャルをフルに引き出し、データマネジメントを Phase 2 以上へ進めるためには、実行基盤となる DWH 自体の刷新が不可避であるという結論に至りました。 dbt を導入する土台となる DWH の選定にあたっては、候補となる複数の主要な DWH 製品の中から最終候補を2製品に絞り込み、実際のワークロードを用いた PoC（概念実証）を実施しました。 検証の進め方 今回の PoC では、単なる機能比較に留まらず、エンジニアによる技術検証と利用者による UI 評価の両面からスコアリングを行いました。 主な検証項目と評価 以下の観点でスコアリングを行いました。 具体的には、以下の 6 項目を重点的に検証しました。 検証カテゴリ 検証内容（一例） 評価結果の要約 コスト クエリ実行、インスタンス起動の費用 Databricks が優位。同一シナリオにおいて、他の競合製品よりも低コストで実行可能であることを確認。 データロード S3 からのデータロード・外部テーブル参照 いずれの製品も容易だが、Databricks は S3 上のデータを直接参照・管理する親和性が高い。 開発体験 SQL / Python の記述、デバッグのしやすさ 競合製品は SQL 中心で洗練されている一方、Databricks はノートブックによる Python / SQL の混在開発に強みを持つ。 エコシステム dbt 連携の安定性、周辺ツールとの接続 いずれの製品も dbt との親和性は極めて高い。 ガバナンス カタログ、権限管理、リネージの自動化 Databricks の Unity Catalog による一元管理と、自動生成されるリネージを高く評価。 AI / 機械学習 生成 AI 連携、ノートブックの AI 補助 Databricks が充実。AI アシスタントや Genie 等の機能が豊富。 総合判断 PoC での定量・定性的な検証を経て、最終的に Databricks の採用を決定しました。 以下の3点を評価しました。 1. オープンなデータ管理とポータビリティ Databricks は S3 上に Delta Lake（オープンフォーマット） でデータを保持します。 特定ベンダーの独自ストレージにロックインされず、他の AWS サービスからも直接データを活用できるオープン性が、弊社の将来的なアーキテクチャの柔軟性に合致しました。 2. コストパフォーマンスの良さ 大規模なログデータを扱う弊社のワークロードにおいて、インフラコストの効率性は重要な検討材料の1つでした。 PoCにおける検証の結果、同一の集計処理シナリオにおいて、比較対象とした製品よりも Databricks の方が約 3 割ほどコンピューティング費用を抑えて実行できる見込みであることが分かりました。 中長期的なデータ量の増加を考慮した際、このコスト効率の良さは好ましい要素となりました。 3. AI 活用とデータ活用の民主化 検証項目の1つであった「AI 機能」において、Databricks の進化の速さを実感しました。 特に自然言語でデータ探索が可能な Databricks Genie 等の機能は、データエンジニアの工数を削減しつつ、非エンジニアが自律的に分析を行える「データの民主化」を加速させると感じました。 4. 移行後のアーキテクチャ Databricks 移行後の構成図は以下のようになりました。 (以下、新データ基盤と呼びます) 移行後のアーキテクチャ図 技術スタックも以下のようになり、ストレージ以外は全て変化しています。 ストレージ: S3 データカタログ: Unity Catalog ELT 処理: dbt × Databricks SQL オーケストレーション: Databricks Lakeflow Jobs BI ツールなど: Databricks Dashboard これにより、先に挙げた5つの重点課題に対する具体的なソリューションを用意できるようになりました。 課題解決方針 具体的なソリューション 1. 効率的なデータ統合 Databricks のマネージドコネクタの利用 2. ER 図の自動提供 dbterd や Databricks の Constraints による外部キーの設定 3. 完全なデータリネージの確立 dbt による高度なリネージ機能 4. ビジネスロジック （KPI） の共通化 dbt Semantic Layer や Databricks metric view 5. データ品質テストの自動化 dbt の Data Test や Databricks の Anomaly detection その他、データエンジニア視点での変化も挙げておきます。 メダリオンアーキテクチャ を採用。Bronze・Silver・Gold の各レイヤーでの責務境界を明確にした データフォーマットに Delta Lake を採用。Liquid クラスタリングによるクエリパフォーマンスの最適化や、スキーマエボリューションによりスキーマ変更の運用コストが大幅に削減された オーケストレーションに Lakeflow Jobs を採用。Airflow ほどの柔軟性はないがシンプルにまとまっており、Terraform での管理が可能になった 5. データ利用側の移行プロセスと工夫 結論から申し上げますと、開発よりもこちらの移行作業のほうが大変だったと感じています。 今回の移行対象は、利用シーンで大きく 2 つのパターンに分けられました。 他システムからのデータ基盤参照箇所の切り替え ダッシュボード内のデータソースの切り替え 前者はコード管理されているので特定は容易でしたが、後者は範囲が膨大であったため、社内の全部署へのヒアリングが必要となりました。 長期的なスケジュールを組むことが予想されたため、以下のような段取りで進めることにしました。 旧データ基盤の利用状況を全て一覧化する 利用状況から各部署にヒアリングを行い、移行完了に必要な作業工数を見積もる 新旧データ基盤の並行稼働期間を決める (= 旧データ基盤の停止時期を決める) 旧データ基盤の停止期限までに移行してもらう 旧データ基盤の処理を停止し、エラーが発生しないことを確認する 基本的には愚直に進めるしかなかったのですが、少しでも効率化を図るために 4.の工程を AI を用いて短縮化させる工夫をしました。 具体的には「Athena SQL -> Databricks SQL に変換するツール」を作成し、社内ホスティングの web アプリケーションとして公開しました。 実はこのツールは我々データエンジニアではなくアナリストが有志で作ってくれたもので、そのほか様々な協力があって移行をスムーズに進めることができています。 6. 改善効果 新データ基盤への移行はまだ途中段階で、より重要度の高いデータから順に進めています。 5つの重点課題の解決状況 全ての課題が解決済みというわけではありませんが、新データ基盤への移行により、それぞれの課題に対応するための土台・準備が整いました。 課題 状況 1. 非効率なデータ統合 🔧 導入基盤が整備済み 2. ER 図の欠如 🔧 導入基盤が整備済み 3. 不完全なデータリネージ ✅ 解決済み 4. KPI 計算の不一致 🔧 導入基盤が整備済み 5. データ品質テストの不足 🔧 導入基盤が整備済み 課題 1 と 3 については、現時点で改善が進んでいる部分があるため、以下に補足します。 1. 非効率なデータ統合 当初は Fivetran や Airbyte などのデータ統合ツールの活用を計画していましたが、移行期間中に Databricks の Lakeflow Connect が登場し、採用方針をマネージドコネクタへ切り替えました。 Lakeflow Connect 本体の機能活用に向けた基盤が整っています。 3. 不完全なデータリネージ dbt 導入により、テーブル間の依存関係がリネージとして自動的に可視化されるようになりました。 旧データ基盤では、「テーブル C の処理はテーブル A と B のデータが出来上がってからでないと実行できない」といった依存関係を Airflow の ExternalTaskSensor で個別に管理しており、テーブルの増加とともに運用が困難になっていました。 dbt のリネージ機能により、こうした依存関係の管理・把握が大幅に改善されました。 また、Databricks の Unity Catalog のリネージ機能 を活用することで、テーブル・カラム単位でのデータの流れを Databricks の UI 上で視覚的に確認することも可能になりました。 利用者・エンジニアの声 弊社での Databricks の採用は初めてであり、当初は利用者からの戸惑いの問い合わせも多かったですが、徐々にうれしいコメントをもらえるようになってきました。 データ基盤利用者からの声 生成 AI 機能 (Genie) が便利。クエリやダッシュボードを自分で作ってくれる Notebook を用いた調査・検証作業が楽になった。結果の共有もスムーズに行える データの問題調査がしやすくなった。Genie がテーブルの中身を自ら探索・分析してくれるため、原因の特定までの時間が大幅に短縮できる データエンジニアからの声 テーブル追加等の開発時の学習コストが下がった。より多くのエンジニアが開発可能になり、レビューアの負担も軽くなった dbt のリネージ機能が便利。データ異常発生時の影響範囲が明確になり、復旧オペレーションも楽になった ダッシュボードなどの機能が Databricks に集約され、管理の手間が減った 7. まとめ 今回の移行プロジェクトにおいて、筆者は初期の課題設定の工程がキーだったと考えています。 当初は「データ基盤を作り変える」という手段が先行していましたが、一度立ち止まって徹底的に背景を深堀りしていき、 開発者視点だけでなく利用者視点での意見も取り入れ、アンケート結果をスコアリングして優先順位を付けて取り組んでいくことの重要性を体感できました。 スタンバイのプロダクトや組織について詳しく知りたい方は、お気軽にご相談ください。 www.wantedly.com

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 生成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ウインドウで1タスクずつ進めるのではなく、複数ウインドウ・ペインで同時にAIへ委任するスタイルになったため、並列委任しやすい場所として、ターミナル＋tmuxのような構成に自然と寄せていく流れになっています。IDEの役割はコードを書く場から、広域に渡るコードリーディングや理解を深める場へとシフトしています。 このレベル 2を支えるのが、要件構造化＆Issue自動生成のSkillです。次の6ステップで動きます。 要件理解 ─ インタラクティブな質問で曖昧さを解消 コード探索 ─ 並列の探索Agentが複数観点で同時調査 要件明確化 ─ 不足情報を補完してスコープを定義 設計提案 ─ 実装方針のドラフトを生成 タスク分解 ─ 実装単位に分解（粒度判定Skill連携） Issue作成 ─ Sub Issue／relationshipを含む構造化Issue このSkillで生成したIssueは累計3000以上にのぼり、親Issue（Feature）→子Issue（DB層→API層など）が blocked_by の依存関係付きで自動構成されます。 例えば「ユーザー通知機能の追加」という親Issueに対し、「#1 DB層：通知テーブル追加」「#2 POST API追加」「#3 DELETE API追加」のような子Issueが、依存関係込みで一気に並ぶイメージです。 実装フェーズでは、これを「Issue × Worktree × Agent」の並列モデルで走らせています。Team Lead Agentが blocked_by に従ってLayerごとにWorker Agentを起動・同期し、同じLayer内はworktreeを切ってWorker Agentが完全並列で実装する。Layer 0でDB層が完了したら、Layer 1のPOST／DELETE APIを2つのworktreeで同時に進める、といった動かし方ができます。 この並列モデルの詳細は次の記事で解説しています。 tech.findy.co.jp コードレビューの分担も、レベル 2では明示的に再定義しています。 担当 レビュー領域 AI コード規約・命名、型定義、テストコード・テストケース 人間 ビジネスロジックの要件適合、アーキテクチャや設計、データベース構造、明確なセキュリティリスク 視点はコードそのものから抽象的なところに寄せていきます。 結果として、レベル 2の導入後、1人あたりのPR作成数は前年比で1.5倍を超えました。AIフレンドリーな「設計図（タスク分解＋構造化Issue）」を誰でも作れる状態になり、作りたいものを再現性高くアウトプットできるようになった、というのがその答えです。 レベル 3：AIで価値を生み出す レベル 2まで進むと、開発スピードに対する次のボトルネックが見えてきます。「何を作るか」の上流が詰まり、せっかく整えた実装力を活かしきれない状態です。 具体的には、要件の実現可能性を調査できるのがエンジニアだけになっていたり、システムとプロダクトの概念が離れていて、お互いを十分知らないまま施策や検証が進んでしまったりします。 レベル 3の目的は、要件定義（PdM領域）とQA領域というAIで代替しづらいとされてきた領域に、AIで踏み込むことです。 レベル 3の起点になるのが 現状把握 です。現状把握の対象は広い範囲に及びます。コードベース・Google Analytics・プロダクト文書・GitHub Issues／PR・Datadog・各種KPIなど、必要なコンテキストは多岐にわたります。 まず要件定義では、これらを毎回手動で集めるのは現実的ではないため、専門Agentチームが各ソースから必要な分だけ自動収集する仕組みを組みました。 ファインディの要件定義Skillでは、7つの専門Agentが並列で動きます。 目的・成果分析 ─ WHY／WHAT仮説の自律生成 データ・コンテキスト収集 ─ GitHub Issues・Notionから数値収集 プロダクト文書抽出 ─ docs／配下のKPI・ポリシーを抽出 コードベース分析 ─ リポジトリの制約・パターンを分析 スコープ分割 ─ MVPと拡張項目に分割 技術的実現可能性評価 ─ 解決アプローチの実現可能性を評価 アクセス解析データ収集 ─ Google Analyticsから自動収集 これらのAgentがAgentTeamsとして並列で稼働し、お互い会話しながら必要な情報を集めて分析します。 ユーザーは分析結果を修正・補足し、最後にAIが構造化＆品質チェックしてGitHub Issueとして出力します。ユーザー操作は入力・レビュー・承認の3回のみで、それ以外はAIが自律的に進める設計です。出力されたWHY／WHAT構造化済みIssueは、そのままレベル 2のIssue自動分解Skillに連携できます。 もう1つの挑戦がQA領域です。ユーザビリティ・アクセシビリティ・UI／UXといった非機能要件のテストはAI単独では難しいため、AIで代替しづらい領域です。ファインディは「代替」ではなく「支援」、つまりAIがQAエンジニアの判断を最大化する形を仮説にしています。 次にQA領域は3つのSkillで一気通貫にしました。仕様ソース（Issue／Figma／Notion）を入力に、次の流れで進みます。 QA観点抽出：観点を自動抽出してQA観点mdを出力 QAテストケース生成：観点→ステップ／期待結果／前提条件に展開してMarkdown＋CSV化 QA自動実行：Playwright MCP経由でClaude Codeから直接ブラウザを操作し、Pass／Failとスクリーンショット付きのレポートを出力 QA観点抽出では、仕様分析／画面構造・UX探索／影響範囲判定の3つのAgentが並列で動き、観点設計のたたき台を数分で生成します。 テストケース生成では、観点→具体ケースへの落とし込みにかかる工数が数時間から数分に短縮されました。生成されたQAリストは、認証・認可／入力バリデーション／表示・UI／ファイル操作／外部連携／メール送信の6軸で共通基準と照合し、観点漏れ・粒度のばらつきを検出します。 人間が集中すべきは、ユーザビリティ評価、例外シナリオ、クライアント要件の確認といった「判断が必要な領域」です。反復可能なケースはAIが淡々と実行し、失敗時はスクリーンショット付きレポートで原因特定が速くなりました。 まとめ AI活用のレベルをレベル 1（速く作る）／レベル 2（正しく作る）／レベル 3（必要なものを作る）と分けてきましたが、最大の主張は、これらは「どれか1つ」ではなく段階的に積み上げて初めて成立する、ということです。 そして、ここで強調したいのが 順番を間違えない ことです。土台が弱いと、ガードレールもAI Skillも成果を出せません。ファインディが踏んだ順番は次の4段でした。 裏返すと、AIエージェントを入れる前にやっておくべきことは、AI以前から変わっていません。統一規約、テストコード、PR粒度、レビューなどの開発文化といった 基本の徹底 こそがAI活用における大前提です。 AI時代の本丸は、「速く作る」ではなく、「正しく作る」「必要なものを作る」への段階的越境です。あなたの組織が今どのレベルにいるか、そして次のレベルへ進むためにどの土台が弱いかを確認する目安として、このロードマップが役立てば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers