生成AIで書く・回すテストと、生成AIと一緒に進めるチーム運営

こんにちは！エンジニアの倉本です。

先日、同じチームの岸本が「開発チームで生成AI活用をするための取り組みやGoバックエンド開発環境の紹介」という記事を公開しました。モノレポのルールを Skills に分割して必要なものだけをロードする、git worktree で作業を並列化する、クリーンアーキテクチャ + sqlc / Connect RPC / google/wire / mockery といった自動生成スタックで「決定的なコード生成」を効かせる、そうした工夫で「生成AIに書かせる範囲」を構造的に絞り込む、という話が中心でした。

その記事の最後では、「これらは別記事で順次紹介していく予定です」と、続きのネタをいくつか予告していました。

フロントエンドの操作も含めたプロダクト全体の機能テスト・シナリオテスト計画の生成AIによる生成
フロントエンド E2E にスクリーンショット撮影を埋め込み、Notion CLI を用いて Notion DB やタスクページにアップロードして、画面カタログ生成・レビューまで持っていく Skill の作成
Notion で管理されているプロジェクト・タスクとの連携、チーム運営での Claude 活用

今回はその続きとして、私が以下の2つを紹介します。

生成AIを前提にしたテストの作り方・回し方
生成AIと一緒に進めるチーム運営

前回の「生成範囲を構造的に絞る」という考え方を、コードの外側、つまりテストの品質管理と企画・設計のプロセスにまで広げてみた、という話です。

生成AI前提で書いて回すテスト
横断的な企画・設計とチーム運用を、生成AIと一緒に進める
おわりに

生成AI前提で書いて回すテスト

「テストの整合性」を人手で保つことの限界

私のチームのプロダクトは、フロントエンド・バックエンド・E2E テストを一貫して開発できるようモノレポで構成しています（このあたりは前回の記事の通りです）。

開発が生成AIで加速するのは良いことなのですが、加速すると今度はテスト側が追いつかなくなります。

画面が増える・UI が変わるたびに、テスト観点とテストケースを書き直す
どの画面のどの挙動が、自動テストでカバーされていて、どこが手動確認頼みなのかを把握し続ける
「この画面、結局どんな見た目だっけ？」を確認できる画面カタログをメンテし続ける

これを少人数のチームで、人手だけで最新に保つのは正直かなり厳しいです。一方で、ここはまさに生成AIが得意な「量をさばく」領域でもあります。そこで、テストまわりも生成AI前提で組み直していきました。

画面カタログをどう維持するか

最初に紹介したいのが、画面カタログの話です。

私のチームでは、プロダクトの全画面を Notion のデータベース（以下「Notion 画面一覧 DB」）で管理しています。各画面に対して URL パス・画面名・スクリーンショットを持たせ、テスト観点やエラー一覧との関連付けの起点にしています。

ただ、この手の画面カタログは作るのも維持するのも本当に大変です。画面が1つ増えるたびにスクリーンショットを撮り直し、台帳に行を足し、関連を張り直す、という作業が延々と発生します。気づくと実装と乖離していて、誰も見なくなる、というのはあるあるだと思います。

そこで、ここを生成AIに丸ごと任せられる形にしました。sync-screen-list というコマンド（Claude Code の slash command / skill）を用意して、次のことを一気通貫でやらせています。

フロントエンドのルート定義（TanStack Router のファイルベースルーティング）と Notion 画面一覧 DB を突き合わせ、差分（新規画面・名称変更・削除候補）を検出する
新規画面については Notion 画面一覧 DB にページを追加する
その画面のスクリーンショットを撮るための E2E を用意して走らせ、撮れた画像を Notion ページに添付する
（スクショ用とは別に）その画面の操作と挙動を検証する E2E を生成する（シナリオまで生成AIに書かせる）
E2E 環境を起動して、生成したテストを1回実行し、pass / fail を検証する

ポイントは、画面に更新が入ったときの維持コストです。新しい画面が増えても、UI が変わっても、E2E を生成AIに書かせ、撮影したスクリーンショットの Notion へのアップロードまでまとめてお願いできる。「画面カタログは人手で維持するもの」という前提が、生成AI前提だと普通に変わってくるな、というのが個人的に一番おもしろかったところです。

スクリーンショットの撮影は専用の E2E を別に持っていて、sync-screen-list はそれを内部で呼び出して新規画面のぶんだけ撮ります。1画面で複数パターンを見せたいケースも、パターンごとの撮影用 E2E を生成AIに任せれば量産でき、台帳に並ぶスクショの質もむしろ上げやすくなりました。

Notion CLI にたどり着くまで

さらっと「スクリーンショットを Notion に添付する」と書きましたが、ここがなかなかの鬼門でした。

やりたかったのは「生成AIに撮らせた画像を、そのまま Notion の画面ページに添付させる」ことです。ところが、Notion 公式の MCP には、少なくとも私が探した範囲では、ファイルのアップロードに相当する口が見当たりませんでした（2026年6月現在）。フィルタ・ソート付きの DB クエリや、ページネーションを跨いだ全件取得あたりも、MCP だけだと痒いところに手が届きません。

困っていろいろ漁っていたら、Notion 公式が公開している skills リポジトリの notion-cli スキルの定義ファイルに、ntn という CLI の紹介がしれっと載っているのに気づきました。これが npm に publish されている Notion の CLI で、ファイルのアップロードも一通りの API 呼び出しもできます。当時は公式ドキュメントに見当たらず skills の中で見つけた格好でしたが、今は公式ドキュメントも整備されています。

結局、ふだんのページ作成・更新・検索は MCP に任せ、MCP では実現しにくい構造化クエリ・全件取得・ファイル操作だけ ntn に降ろす、という使い分けに落ち着きました。スクショの添付も、後述する「テスト仕様の全件エクスポート」も、この CLI が土台になっています。

機能テスト仕様書をどう整備するか

画面カタログが整うと、次はテスト観点とテスト仕様書です。

私のチームでは、テストを「機能テスト（画面単体で検証できるもの）」と「シナリオテスト（画面をまたぐフロー全体）」に分け、それぞれについて〈観点表 → 仕様書 → 実施記録〉の3層を Notion で管理しています。とくに機能テストの観点には、「画面表示・レイアウト」「正常系の操作・遷移」「入力バリデーション」「エラーハンドリング」「セキュリティ」……といったカテゴリ体系（数十カテゴリ）を持たせていて、全カテゴリを網羅できているかをチェックできるようにしています。

ここで生成AIにやってもらうのは、

対象画面の実装（フロントエンドのルートやコンポーネント）を読む
カテゴリ体系に照らして、その画面で確認すべき観点を、正常系・異常系・境界値で列挙する
観点をグルーピングして、事前準備・手順・期待値を持つテスト仕様書の形に落とす

という流れです。観点の追加 → 観点のレビュー → 仕様書の作成 → 仕様書のレビュー、と生成とレビューを別のコマンドに分けて運用しています。

人手だと書ききるのがしんどい量を一気に書けるのが、ここで生成AIに任せる一番のうまみだと思っています。網羅性のチェックも、該当する観点が無いカテゴリには「ここは対象外、理由はこれ」と書かせておくと、抜けに気づきやすくなります。

仕様書を書かせるときには、レビューのルールもかなり細かく決めてあります。たとえば、

仕様書は実装コードを読まない人（手動でテストする人）が読むものなので、コンポーネント名・関数名・内部定数のような実装内部の情報を仕様名や手順に書かない
- ModalXxxが開き ではなく モーダルが開き
- MAX_REDIRECT_DEPTH=3 ではなく 4段階以上ネストされたURLでは取得されない
エラーメッセージは「エラーが出る」ではなく、実際に表示される見出しと本文のテキストをそのまま期待値に書く
手順 N に対して期待値 N が対応するように番号を揃える

こうしたルールを言語化してスキルに載せておくと、生成AIの出力が安定します。

フロント E2E（Playwright）の自動生成

E2E テストも生成AIに書かせています。

実際の E2E はだいたいこんな雰囲気です。以下のコードは同意画面で「同意ボタンを連打しても、送信リクエストは1回だけになる」ことを確認するテストの例です。

test("同意画面で同意ボタンを連打しても同意送信は1回だけになる", async ({ page }) => {
  const watcher = watchConsoleErrors(page);

  // 認証フローを開始し、共通ステップでログインまで済ませて同意画面の手前まで進める
  await steps_StartAuthFlow(page);
  await steps_SignIn(page, TEST_USER);

  await test.step("同意ボタンを連打しても送信リクエストは1回だけになることを確認", async () => {
    await page.waitForURL("**/consent**", { timeout: TIMEOUT.NAVIGATION });
    const requestCount = await countRequestsDuringAction(
      page,
      SUBMIT_CONSENT_ENDPOINT_PATH,
      async () => {
        await clickRapidly(consentPage(page).agreeButton, RAPID_CLICK_COUNT);
        await page.waitForURL("**/callback**", { timeout: TIMEOUT.NAVIGATION });
      },
    );
    expect(requestCount).toBe(1);
  });

  watcher.assertNoErrors();
});

steps_StartAuthFlow（認証フローの開始）や steps_SignIn（ログイン）のように、画面をまたぐ一連の操作を共通ステップとして部品化してあるので、生成AIは「どの部品を、どんな順序で組んで、最後に何を assert するか」に集中できます。この例なら、ログインまでは共通ステップに任せ、本題の「同意ボタン連打 → 送信は1回だけ」の検証に集中する、という具合です。

E2E 生成で意識しているのは、生成AIに発明させすぎないことです。sync-screen-list での E2E 自動生成では、

正常系（画面遷移 + 主要ラベルの確認 + 主要操作 + 遷移先の確認）は必ず1つは PASS する形で書かせる
異常系・境界値は、同じカテゴリの既存テストに「お手本となる技法」（たとえば API レスポンスを書き換えてエラー UI を出す、など）が無い場合は、無理に書かず test.skip + TODO で残させる
テスト基盤（共通ヘルパー・シードデータ・fixture）への新規追加は生成AIに禁止する

というルールにしています。手本のない技法を生成AIに一から書かせると、それっぽいけれど微妙に間違ったテストを量産しがちなので、原則「お手本がある範囲だけ任せる」という線引きにしています。

テスト仕様を見直すときの3段ガード

テスト仕様を大量に見直すときは、Notion を生成AIに直接ガチャガチャ更新させるのではなく、次の3段に分けています。

エクスポート（read-only）: ntn で Notion の仕様データをローカルにエクスポートする（バックアップも兼ねる）
機械監査: ローカルのデータに対してスクリプトで監査をかけ、「ここはこう直すべき」という変更候補のマニフェストを作る
適用（apply）: マニフェストを人間がレビューし、承認した範囲だけ Notion に反映する

3段に分ける狙いはシンプルで、生成AIが生成するのはあくまで候補に留め、Notion への実際の書き込みは人間が確定する、という線を引くためです。削除・アーカイブ・関連の解除・大幅な統合のような後戻りしにくい操作は、候補の列挙までで止めて自動実行はしません。

うまくいっていないところ

ここまで威勢よく書いてきましたが、正直うまくいっていない部分もあるので、そこも書いておきます。

まず、二重管理になりました。自動テストで担保済みの項目まで Notion に機能仕様として持ってしまい、「コード（E2E）」と「Notion（仕様書）」で二重に抱えています。打鍵時は View でフィルタした手動確認ぶんだけを見ていて、自動担保ぶんはほぼ見返していないのが実態です。ここまで Notion に持つ必要はなかったかも、というのが率直なところですが、この棚卸しで「本当に人間が手で確認すべき項目」を絞れたのは収穫でした。

次に、トークンを大量に消費します。機能テストの観点・仕様の生成はとにかくトークンを食います。Claude Max 20x プランを使っていても、レートリミットに当たったことが何度かありました。「生成AIならいくらでも書ける」とはいえ、コストはしっかりかかります。

最後に、仕様のリビジョン管理は作ったものの、効果は未知数です。仕様書には「仕様の本文（手順・期待値など）から算出したハッシュ」と「リビジョン番号」を持たせていて、本文が変わったらリビジョンを上げ、過去のテスト実施記録が「どのリビジョンに対して行われたか」を辿れるようにしています。仕組みとしては作ったものの、これをずっとメンテし続けられるのか、本当に効果に見合うのかは、正直まだ分かっていません。

横断的な企画・設計とチーム運用を、生成AIと一緒に進める

ここからは「チーム運営での生成AI活用」の話です。

といっても、大げさな仕組みを整えた、という話ではありません。主に私が、企画や設計を考えるときにとりあえずやっている進め方と、その先のチームの運用への繋ぎ方の紹介、くらいの温度感で読んでください。

なぜ「横断的な視点」が要るのか

前提として、私のチームが見ている領域は、認証・個人情報まわりの基盤、モバイルアプリ、Web、それらを支える共通基盤……と、機能が複数のリポジトリ・プロダクトにまたがっています。

そのため、1つの企画を考えるときでも、「アプリ側ではどう見えるか」「基盤側のスキーマや API はどうなるか」「Web 側の表示は」を同時に考えないと、設計が成立しません。実装フェーズに入ってから「あ、これアプリ側の都合で無理だ」と気づくと手戻りが大きい。だから、企画・設計の段階から横断的な視点を入れておきたい、という動機があります。

とはいえ、各プロダクトの現状コードを1人で全部把握するのは難しい。そこで生成AIに手伝ってもらっています。

設計を手伝う subagent たち

私のチームの開発ワークスペースには、プロダクトごとの「expert」subagent を定義してあります。アプリ担当・基盤担当・Web 担当……というように、それぞれの subagent が、起動されると対象リポジトリを動的に読みに行って現状の実装を調べ、「この論点について、今のコードはこうなっている」と報告してくれます。コードを SoT（信頼できる情報源）として扱い、人間の思い込みではなく実装ベースで設計するためです。

加えて、PM（プロダクトマネージャー）視点の subagent と法務視点の subagent も用意してあります。これらにはチームやプロダクトの文脈（スコープの考え方・優先度・リスク・法令まわりの前提）を別ファイルに切り出して持たせてあるので、起動するだけでその文脈を踏まえたレビューが返ってきます。

横断的な企画を1人で抱え込まず、役割の違う subagent と分担する、というのが基本の進め方です。PRD（要件ドキュメント）や Design Doc（技術設計ドキュメント）を書くワークフローの中で、こうした subagent を呼び出しています。

multi-reviewer-sync による多視点レビュー

設計の第1ドラフトができたら、multi-reviewer-sync というスキルを使って、複数の subagent を1メッセージで並列に起動してレビューさせます。

ポイントは、全員に同じ評価フォーマットで返させることです。各レビュアーには、

推奨案（どの案を推すか、または「このドラフトを承認 / 要修正」）
Pros（メリット、なるべく根拠付きで）
Cons（リスク・懸念、影響範囲と発生確度を添えて）
Open Questions（確定前に誰に何を聞けば解決するか）
必須施策（この案を採るなら絶対に外せない要件）

という5項目を、この順で返すよう指示します。フォーマットを固定してあるので、返ってきた結果を1枚の比較表にまとめられます。たとえば、こんな具合です。

Reviewer	推奨案	Top 1 Pros	Top 1 Cons
アプリ expert	案 B	既存の仕組みの拡張で済む	旧バージョンの考慮が必要
基盤 expert	案 B	既存 API に追加で完結	マイグレーションが要る
PM	案 B	デッドラインに最も近い	スコープが少し広い
法務	案 B	同意フローの観点で問題なし	ログ保管期間の確認が必要

論争になりそうな決定・後戻りしにくい決定・法務がからむ決定の前に、こうやって複数の視点を一気に集められるのが効きます。

ルールに沿った起票から実装へ

私のチームには、プロジェクト・タスク管理の共通ルールがドキュメントとして明文化されています。「アイデア → プロジェクト → タスク」の3レイヤーや、2週間スプリントでの進め方などです。ルールが言語化されていると、人だけでなく生成AIも同じ前提で動けます。

そこで、この運用まわりの事務作業も生成AIに手伝ってもらっています。具体的には、

ざっくりした思いつきや要望を、アイデアとして起票する
やる理由とスコープが固まったものを、プロジェクト／タスクに昇格させる
タスクのテンプレート・プロパティ・アイコン・対象領域（どのプロダクトの話か）を、ルールに沿って自動でセットする
Design Doc から実装タスクを切り出して分解する

このあたりを、チームのルールを読み込ませた skill（コマンド）として用意しておき、生成AIに下書きさせています。ルールを skill に落としておくと、生成AIが起票してもボードの体裁が揃い、「形式を整える」手間が消えます。

設計が決まってタスクに分解できたら、あとは実装に流していきます。PR のタイトルに Notion タスク ID を含めると、その PR が Notion のタスクと自動で紐づき、PR を作るとタスクが「進行中」に、レビュアーを設定すると「レビュー中」にと、GitHub 側の動きが Notion 側のステータスへ反映されます。企画のドキュメントから実装の PR までが1本の線で繋がるので、「この PR は何のための作業だっけ」を後から辿りやすくなります。

ここでも、生成AIがやるのは起票・分解・プロパティの候補出しまで。どの案を採るか・担当や優先度・スコープの確定は人が決めます。ワークスペースの原則にも「提案はするが、決定はしない」という一文を置いています。

おわりに

今回は、前回の記事の続きとして、

生成AI前提のテスト: 画面カタログの自動メンテ、観点・仕様・E2E の量産、そして「候補生成 → 人間レビュー → 反映」の3段ガード
生成AIと一緒に進めるチーム運営: プロダクト expert / PM / 法務の subagent を並列レビューに回し、チームのルールに沿った起票・タスク化まで生成AIに任せて、企画から実装までを地続きにする仕組み

を紹介しました。前回がコードの話だったのに対して、今回はその外側のテストとチーム運営の話でした。

正直に言うと、これが正解なのかは、ずっと分かっていません。二重管理になってしまった部分もありますし、頑張って作った仕組みを結局そこまで使いこなせていない、ということもあります。数ヶ月後には、まったく違うやり方をしている可能性も十分にあると思っています。

一方で、モデルはこれからも賢くなっていくので、「いずれ任せられるようになる」前提で、今のうちにあえて任せてみる・作り込んでみる、という張り方もアリなのかもしれない、とも思っています。試行錯誤の途中ですが、うまくいったこともうまくいかなかったことも含めて、何かの参考になれば嬉しいです。

レバレジーズ株式会社様が運営するフリーランスHubにて、弊社の「POCKETSIGN Tech Blog」をご紹介いただきました。記事は以下よりご覧ください。

ご紹介記事：スキルアップやキャッチアップにつながる！注目のITブログ・メディアまとめその3