エンジニア2人とAIで進めるプロダクト開発 — 「開発プロセスの半分以上をAIが主導」という体制の実践
本文の状態
日本語全文を表示中
詳細モードで約22分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
CyberAgent Developers Blog
小売アプリ向け広告サービスにおいて、エンジニア2人とAIが協働し、開発プロセスの過半数をAIが主導する体制を実践。効率的なプロダクト開発を実現している。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
こんにちは！AI事業本部の協業リテールメディアdiv.において小売アプリ向けの広告サービスの開発をしている25新卒エンジニアの藤本隆晟（@fujiryu0202）です！ CyberAgentでは、職種を問わずAI活用を推進する文化があり、開発エージェント導入への年間4億円の投資や、社内でのAI活用状況の可視化などが積極的に行われています。ちなみに、私は先日この社内ランキングで、Claude Codeの利用実績が社内2位となりました（分母はマスクしてます）。この記事では、エンジニア2人体制でもエンジニア6人分くらいのアウトプットの量を出すための AI開発基盤の構築についてと、その活用法についてお話しします。
- 私たちの運用しているサービスと課題について
まず、私たちのサービスについて軽く紹介します。近年、リテールメディアという言葉がよく聞かれるようになりましたが、私たちは、小売メディア（小売がもつアプリ）において、商品理解をした上で購買に繋げるためのリワード型広告サービスを開発・運用しています。下記に過去に掲載されたサッポロドラッグストアとヤマダデンキに導入した際のプレスリリースを載せます。
このサービスでは、広告を配信するための配信サーバはもちろん、各小売のトンマナに合わせた広告を表示するアプリ内Webビュー、アプリに導入をするためのSDK実装、広告入稿するための管理画面、配信実績や小売POSデータを分析するための分析基盤、等々、バックエンド、フロントエンド、ネイティブ、データサイエンス領域 … と、とても多くの技術だったり、もっというと小売に対するドメイン知識だったりが求められるサービスになっています。
このサービスはリリース時はエンジニア6名、ビジネス3名でエンジニアのチーム体制だったのですが、現在ではエンジニア2名、ビジネス1名体制でサービスを運用しています。エンジニアに関しては僕と開発責任者の2人です。しかし、人数が減ったからといって実施する広告案件や施策が待ってくれるということもなく、開発速度は維持（なんなら現在立ち上げ期なのでもっと向上）していかないといけない状況をぶつけられました。そこで僕らが決断したのは、AIを単なる「補助ツール」として使うのをやめることでした。AIエージェントを自律的な「チームメンバー」として大量生産し、AI駆動の次世代開発基盤を構築する。 まだ誰も正解を持っていないこの領域で、僕たちが先導的に開拓してきた「2人で6人分実装する」ための戦術の過程を解説します。
ちなみに、今回の記事では主にClaude Codeでの話をするのですが、昨年12月初旬では 私たちの開発基盤はAI駆動？なにそれ？程度でした。しかし、1月末現在、リポジトリ内にはAIエージェントで利用する、Skillが37個、SubAgentが24個 と用途や担当領域別にAIが専門的な知識をつけるための仕組みを整えることができています。
- みなさんAI活用できてますか？
みなさんは、AIを使った開発でどのくらい効率が上がっていると感じていますか？僕自身、最初はAIを会話相手として利用することで簡単な修正をしてもらったり、少し煩雑な実装も依頼して違う部分を見つけたらまた依頼して… （N回ループ）みたいなことをやっていました。でも、今は開発のプロセスのほとんどをAIでやってもらうようになりました。自分たちのチームでは、AIを「主導者」そして人間は「監督」とする開発フローにすることで、AIを補助ツールとする開発からAIをフル活用した開発にシフトさせました。
僕は、AIを補助ツールとして使っていた頃から思っていたことがあり、それが
「AI使うことで自分でやるべき作業は減ったけど、これって効率化できてるんだっけ … ？」
ということです。おそらく世の中的に思われているAIを使った開発イメージは
実装タスクに対して、仕事が早く終わるようになる
ほとんど全部AIにやらせられるから人間の仕事が楽になる
という感じなのではないでしょうか。でも、それって本当でしょうか？僕自身は
実装タスクに対して、仕事が早く終わるようになる → 利用方法によっては業務効率は悪化
ほとんど全部AIにやらせられるから人間の仕事が楽になる → 実装効率を上げるには、むしろ集中力やコンテキストスイッチを頻繁に行う能力が求められるため楽になるわけではない
と考えています。僕自身、今回AI駆動開発に切り替える際に下記のような体験をしました …
今のAIを使った開発の社会的な現在地
読者の中には、AIを入れることで逆に仕事効率が落ちたと感じている人も少なくないと思います。
これは僕の感想なのですが、技術に特化して強いエンジニアほど、最初AIを使うまでのハードルとして、「自分でやるより効率が悪くなる」というのが浮かぶのではないかと思っています。たしかに、AIがプログラミング初学者の書くような意味のわからないコードを生成してこられても、それを修正する方が工数ですし、この気持ちもわかります。
大半のエンジニアはこの例に挙げたこと以外でも、さまざまな要因によって、AIはあくまで「補助ツール」のような使い方が現状多くなっているのではないでしょうか？この補助ツールに留まっている理由としては、2, 3年前と比較すると、当時では考えられないくらいAIが進歩し、日々のアップデートに追いつけてないというのももしかしたら要因に挙げられるかもしれません。（僕もまだまだAIど素人だと思っています）
最近ではSkillやSubAgent、さらには直近ではAgent Teamsなども登場し、まだこの開発業態にベストプラクティスがない中で、利用方法を模索している状況という方も多いと思います。それが故に、とりあえずAIの出してくる答えの精度を上げるためにSkillやSubAgentを導入まではいくものの、主導者は人間 の状態になっているプロダクトが多いのだと僕自身は考えています。
僕の考える AIを “活用” するための方法
では、どうやったら、AIを補助的なツールではなく、活用した開発にできるのか？僕自身の答えとしては下記の２点だと考えています。
前者については、今まで話してきたようなAIの補助ツール的な使い方においては、主導者はあくまで人間であり、方向性を途中途中で操作しているのは人間です。しかし、AIを活用させるためには、人間がするタスクは２つで 「意思決定」と「確認」となり、主導者ではなく監督的役割にシフトさせていく必要があると考えています。人間がやることは、「AIに最初インプットさせる情報・方向性の決定」、「AIが出す選択肢の中からの決定」、「AIが出すアウトプットの最終確認」といった、ネクストアクションに繋げるための決定と確認になります。具体的には下記のようなものが人間が行うものに該当すると思っています。
AIによるアウトプット生成過程での質問回答（意思決定）
AI出力物の簡単な確認 / 修正 要件定義書（ビジネス/技術）の確認
検証環境デプロイ前の最終PR確認
では逆にAIはというと、もともと人間がやっていた主導者となり、skillやsubagentを起動させて、監督が求めるアウトプットを出力するためのリーダを担います。これは、単に出力物を出すという補助的な使い方ではなく、生成過程での軌道修正も含めて、AIが主導するということです。最終形態としては、ここに人間は関与しないのが完全理想状態です。私が今回実装したAIを主導者とした開発ワークフローについては次章で説明します。
次に後者についてです。これはやることは難しいかもしれませんが考え方は単純で、人間が監督的な役割になることでいくつかのタスクを並列することができるようになるため、そこで業務効率をあげようという話です。AIが主導して実装することで、2章の内容で説明したように人間の仕事はもしかしたら楽になるかもしれませんが、現状のAIでは単一タスクでの実装効率は、多くの場合むしろ低下します。これは、実装するためのコンテキストをAIはあまり知らないため過去の実装内容だったり、ドキュメントだったりを調査するところからAIは開始し、実装計画をたて、ビジネス要件との整合性を確認して軌道修正し … のようにAIにやらせることでその過程が多くなってしまうため、１つ１つは人間より早いかもしれませんが、合計すると単純な実装ほど実装効率は悪くなっていきます。そのため、
いくつかの実装タスクを並列的に監督する
ランチ行っている間に実装させる
…というように、人間が別のことで動いている前提 が効率をあげるために必須になってきます。
もしかしたら今後のAI技術の進歩でまるでコンパイラでコードをコンパイルする感覚で実装したいものが実装できるような社会になるかもしれません。しかし、そのような時代になったとしても、AIがあるということに胡座をかかず、人間は監督としてAIを動かし、空いている時間で別のタスク・用事をこなすというAI活用スキルとしてずっと必要になると考えています。
- AI駆動開発ワークフロー
私たちの開発フローの全体像について
前章で「AIを主導者、人間を監督」にするという話をしました。では実際に、私たちはどのような開発フローを構築したのでしょうか？
まず、AI導入前後の変化を端的に示します。
人間がバックログに積まれたIssueを読み、具体の要件を頭の中で整理 → 特に影響範囲が大きかったり実装コストが高いものだったりはDesign Docに詳細をまとめる
Claude Codeに「〇〇を実装して」と会話ベースで依頼
出力が微妙なら修正を指示して…（N回ループ）
人間がPRを作成し、人間がレビュー
人間はIssueの概要として要件の概略を書くだけ（曖昧表現でOK）
AIが要件深掘り → 技術設計 → タスク分割 → 実装 → レビューまでを主導
人間は各フェーズの「確認」と「意思決定」のみ
このフローを支えているのが、SkillとSubAgentという2つの仕組みです。Claude Codeを使ったことがある方なら、CLAUDE.mdやカスタムスラッシュコマンドはご存知かもしれません。私たちはその先にある、AIがAIを起動・管理し、オーケストレーションする構造を構築しました。
Skill: AIがもつ専門性もしくは従うべき振る舞いを定義。「どの順番で何をすべきか」「品質基準は何点以上か」「失敗したらどうするか」を明文化したもの。
SubAgent: 特定の領域に特化した専門AIエージェント。Go実装担当、TypeScript実装担当、技術レビュー担当…など、人間のチームメンバーのように役割分担をしたもの。Skillを利用することも可能。
メインエージェントがSkillを用いてオーケストレーター（指揮者）としてSubAgentを起動・制御する構造になっており、これらを組み合わせることで「要件定義 → 技術設計 → タスク分割 → 実装 → レビュー」という開発フロー全体を自動化しています。以下、各フローを順番に解説していきます。
開発フロー1: ビジネス要件詳細の生成
すべての開発は「何を作るか」を明確にするところから始まります。従来であれば、エンジニアがIssueを読み解き、要件を整理し、設計を考え…という作業が必要でした。私たちのフローでは、この最初の一歩をAIに任せるところからスタートさせます。
私たちのプロダクトではバックログをLinearで管理しており、LinearのIssueを起点に実装を行います。そして、このフローで人間がやるのは、Linearに以下のテンプレートで要件の概略を記入することだけです。
[機能名] ## オーナー <!-- 誰がこの機能に責任を持つのかを記載 --> @名前 ## 背景 <!-- 1-3文で課題と目的を記述 --> ## やりたいこと | 機能概要 | 優先度（Must/Should/Could） | 備考 | |----------|---------------------------|------| ## やらないこと | 機能概要 | 除外理由 | |----------|----------| ## 誰が使うか <!-- 主要ユーザー --> ## As Is と To Be As Is: <!-- 1-3文で現状を記述 --> To Be: <!-- 1-3文で目指すべき状態を記述 --> ## 受け入れテスト項目 | テストID | シナリオ | Given（前提） | When（操作） | Then（結果） | 優先度 | |----------|---------|--------------|-------------|-------------|--------| | AC-001 | 正常系：〇〇 | ... | ... | ... | Must | | AC-002 | 異常系：〇〇 | ... | ... | ... | Must | ## 制約・前提条件 <!-- あれば -->
このテンプレートは「完璧に埋める」必要はありません。背景・やりたいこと・As Is/To Be あたりを数行書けば、AIが残りを深掘りしてくれます。受け入れテスト項目も、書けるところだけ書いておけば、AIが網羅的に補完します。
このLinear Issueを起点に、AIが以下のステップでビジネス要件定義書（BRD）を生成します。
Linear Issue取得: MCP連携でIssueの内容を自動取得
分析・深掘り: analyzer agentが要件を分析し、曖昧な点を人間に質問
BRD生成: generator agentが分析結果から要件定義書を生成
品質検証: validator agentがスコアリングし、基準未満なら自動修復
Skill・SubAgentの構成
このフローでは、1つのオーケストレーターSkillが3つの専門SubAgentを順次起動します。
Skill: creating-business-requirement（オーケストレーター） │ ├─ 1. SubAgent: business-requirement-analyzer │ 役割: Linear Issueの取得、要件の曖昧さ検出、質問ループ │ 出力: analysis_result.md（分析結果） │ ├─ 2. SubAgent: business-requirement-generator │ 役割: 分析結果からBRD生成、ユーザーレビュー │ 出力: business_requirements_definition.md（BRD） │ └─ 3. SubAgent: business-requirement-validator 役割: 10観点でスコアリング、80点未満なら自動修復（最大3回） 出力: validation_report.md（検証レポート）
「なぜ1つのAgentで全部やらせないのか？」と思う方もいるかもしれません。理由はコンテキスト分離です。1つのエージェントに全てやらせるとコンテキストが膨張してパフォーマンスが落ちます。専門エージェントに分割することで出力品質が安定し、途中で失敗しても該当フェーズだけやり直せます。
質問ループ — AskUserQuestionでAIが「聞いてくる」仕組み
analyzer agentの最大の特徴は質問ループです。これを実現しているのがClaude CodeのAskUserQuestionツールで、AIが処理の途中で人間に選択肢付きの質問を投げかけることができます。
analyzer agentは要件の曖昧な部分を検出すると、このツールで人間に質問を投げてきます。「このエッジケースの挙動はどうしますか？（A: エラーを返す / B: デフォルト値で処理）」「優先度が未指定の項目があります」「スコープ外とする機能はありますか？」 といったように、 不明点がなくなるまでループが継続します。
このAskUserQuestionツールの存在が、私たちのフローの根幹を支えています。AIは「言われたことをやる」だけでなく、「足りないことを聞いてくる」のです。人間がLinearに書いた概略（曖昧な状態）を、この質問ループを通じて詳細な仕様レベルまで詰めていきます。人間が「後で考えよう」と先送りしがちな部分を、AIが容赦なく突いてくるので、結果として網羅的で具体的な要件定義書が生成されます。
Linearで何を詰めるべきか — 「概要」から「仕様」へ
テンプレートは「完璧に埋めなくてよい」と書きましたが、以下の4点は意識的に詰めておくと後工程の品質が大きく変わります。
やりたいこと / やらないこと: Must/Should/Couldの優先度を必ず記入し、曖昧な表現を排除。Scope / Out of Scopeを明確にしておくことで、AIが「親切心」でスコープを広げてしまうのを防ぐ
受け入れテスト項目: Given-When-Then形式で正常系・異常系・境界値を網羅。タスクの完了条件はここで確定させる
As Is / To Be: 「現状：手動でCSVアップロード → 目標：APIで自動連携」のように差分が明確なレベルで記述
BRDはこの後のすべてのフェーズの入力データです。特に受け入れテスト項目はBRD → Design Doc → タスクファイル → TDD実装まで一気通貫で引き継がれるため、ここでの具体性がフロー全体の品質を左右します。最初の10分で要件を詰めることが、後の作業での手戻りを防ぎます。
要件整理にかかる人間の実作業が数時間 → 約10〜20分（質問回答+確認のみ）に短縮。要件の網羅性・具体性は人間だけで書くより向上し、フロー全体の手戻りが激減しました。
開発フロー2: 技術要件の生成 ~ PR粒度でのタスク分割
ビジネス要件が固まったら、次は「どう作るか」のフェーズです。ここでは、AIが実際のコードベースを読み込んだ上で技術設計を行い、さらにPR粒度の実装タスクに分割するところまで自動で進みます。
Design Doc生成のステップ
BRD解析 + コードベース分析（既存コードの調査・影響範囲特定）
モジュール別テスト計画の生成（TDD前提）
Design Doc生成（Mermaid図を含むアーキテクチャ設計）
品質検証（ビジネス要件充足・テスト項目・技術要件を重点レビュー）
Design DocのTODOセクション解析・依存関係分析
モジュール単位でPRタスク生成（Backend / Frontend等） // タスク分解粒度は調整可能にしている
品質検証 → 検証PASS後にLinear sub-issue自動作成
Skill・SubAgentの構成
このフェーズでは合計7つのSubAgentが動きます。Design Doc生成で4つ、タスク分割で3つです。
Skill: creating-tech-design-doc（オーケストレータースキル） │ ├─ 1. SubAgent: tech-design-doc-analyzer │ 役割: BRD解析 + コードベース分析 + 技術スタック特定 │ 特徴: リポジトリの実コードを読み込んで既存パターンを把握 │ ├─ 2. SubAgent: tech-design-doc-test-generator │ 役割: 影響モジュール別のTDDテスト計画を作成 │ ├─ 3. SubAgent: tech-design-doc-generator │ 役割: 分析結果 + テスト計画から Design Doc を生成 │ └─ 4. SubAgent: tech-design-doc-validator 役割: 10観点スコアリング + BRDとの整合性チェック + 自動修復 Skill: creating-pr-tasks（オーケストレータースキル） │ ├─ 1. SubAgent: pr-tasks-analyzer → Design Doc解析・依存関係分析 ├─ 2. SubAgent: pr-tasks-generator → タスクファイル生成 └─ 3. SubAgent: pr-tasks-validator → 9観点スコアリング + Linear sub-issue作成
コードベース分析 — AIが「コードを読んで設計する」
このフローで最も強力なのは、AIが既存のコードベースを実際に読み込んだ上で設計を行う点です。analyzer agentはリポジトリ内のコードを走査し、既存のアーキテクチャパターン・使用ライブラリ・命名規則を理解してから設計します。人間のエンジニアが「今のコードがどうなっているか」を調べてから設計するのと同じことを、AIが自動でやってくれるわけです。
タスクの自己完結性 — ファイルをインターフェースにする
PR粒度のタスク分割で最も重視したのは自己完結性です。各タスクファイルには、タスク概要・As is / To be・スキーマ定義・API仕様・テスト項目（Given-When-Then全文）・依存関係がすべて含まれます。Design Docを参照しなくても実装に着手できる状態です。
この「ファイルをインターフェースにする」という設計思想は、こちらの記事の考え方を参考にしています。エージェント間の連携を会話ではなくファイルの入出力で行うことで、各フェーズが疎結合になり、途中からのやり直しや並列実行が容易になります。
なぜここまで情報を詰め込むのか？次のフロー（実装フェーズ）で複数のタスクを別々のAIセッションが並列実行するからです。タスク間のコンテキスト依存をゼロにすることで、並列実装が成立します。
AIがコードベースを分析した上で設計するため、既存コードとの整合性が担保されます。またタスクの自己完結性により、並列実装がスムーズに回るようになります。
開発フロー3: ローカルでの実装 / レビューフロー
では、いよいよ実装フェーズです。ここが私たちのフローで最もエージェントが活躍するパートで、タスクファイルとDesign Docを入力に、AIがTDD（テスト駆動開発）で実装し、CIを通し、コードレビューまでを自動で完走します。
言語判定・エージェント選択（Go / Next.js / NestJS / Terraform等を自動判定）
TDD実装（RED→GREEN→REFACTOR）
CI実行（ローカルでCIが通るまで自動修正）
コード簡素化（code-simplifier agentの起動 → 再CI）
Tech Review + Spec Review（レビューエージェントの並列実行）
指摘対応ループ（両方80点以上かつCritical/Highレベルのレビューがなくなるまで修正→再レビュー）
Skill・SubAgentの構成
このフローの心臓部である working-implementation
Skill: working-implementation（オーケストレーター） │ ├─ 【PHASE 1: 実装】技術スタックに応じた実装SubAgentを自動選択 │ ├─ gopher （Go実装担当） │ ├─ nextjs-implementer （Next.js担当） │ ├─ nestjs-implementer （NestJS担当） │ ├─ react-implementer （React担当） │ ├─ aws-sre （Terraform/AWS担当） │ ├─ snowflake-sre （Terraform/Snowflake担当） │ ├─ sql-implementer （Snowflake SQL担当） │ └─ ui-implementer （UI実装担当） │ ├─ 【PHASE 1.5: リファクタ】CI成功後に必ず実行 │ └─ code-simplifier （コード簡素化担当） │ └─ 【PHASE 2: レビュー】2つのレビューを並列実行 ├─ code-tech-reviewer → 8観点でスコアリング └─ code-spec-reviewer → Design Docとの整合性を6観点で評価
開発原則をルール・スキルで定義する
AIに「いいコードを書け」と言っても、「いいコード」の基準は人によって異なります。私たちはこの曖昧さを排除するために、開発原則とその優先度をルールファイルやスキル定義に明文化しています。
開発原則の優先度体系（rules/cording.md より） P0（必須）: オッカムの剃刀 — 必要なしに存在を増やさない P1（デフォルト）: リーダブルコード、DRY原則 P2（推奨）: プログレッシブエンハンスメント P3（状況依存）: TDD/ベイビーステップ、デメテルの法則 # テストケース生成にはペアワイズ法を採用 # → 全組み合わせ（N×M）ではなく、2因子間の組み合わせで効率的にカバー
これらの原則がSkillやSubAgentの中で参照されることで、AIが「シンプルさを最優先にしつつ、読みやすいコードを書く」という判断を自律的に行えるようになります。
リファクタフェーズ — code-simplifierの重要性
実装フローの中で見落としがちですが、PHASE 1.5のリファクタフェーズは品質維持の要です。CIが通った後、code-simplifier agentが必ず実行されます。
code-simplifierは「機能を一切変えずに、コードの書き方だけを改善する」専門エージェントです。核となる原則は：
機能の保全: コードが何をするかは変えない。どうやるかだけを改善する
明確さの追求: 不要な複雑さ・冗長なコード・過度な抽象化を排除し
原文を表示
こんにちは！AI事業本部の協業リテールメディアdiv.において小売アプリ向けの広告サービスの開発をしている25新卒エンジニアの藤本隆晟（@fujiryu0202）です！ CyberAgentでは、職種を問わずAI活用を推進する文化があり、開発エージェント導入への年間4億円の投資や、社内でのAI活用状況の可視化などが積極的に行われています。ちなみに、私は先日この社内ランキングで、Claude Codeの利用実績が社内2位となりました（分母はマスクしてます）。この記事では、エンジニア2人体制でもエンジニア6人分くらいのアウトプットの量を出すための AI開発基盤の構築についてと、その活用法についてお話しします。
- 私たちの運用しているサービスと課題について
まず、私たちのサービスについて軽く紹介します。近年、リテールメディアという言葉がよく聞かれるようになりましたが、私たちは、小売メディア（小売がもつアプリ）において、商品理解をした上で購買に繋げるためのリワード型広告サービスを開発・運用しています。下記に過去に掲載されたサッポロドラッグストアとヤマダデンキに導入した際のプレスリリースを載せます。
このサービスでは、広告を配信するための配信サーバはもちろん、各小売のトンマナに合わせた広告を表示するアプリ内Webビュー、アプリに導入をするためのSDK実装、広告入稿するための管理画面、配信実績や小売POSデータを分析するための分析基盤、等々、バックエンド、フロントエンド、ネイティブ、データサイエンス領域 … と、とても多くの技術だったり、もっというと小売に対するドメイン知識だったりが求められるサービスになっています。
このサービスはリリース時はエンジニア6名、ビジネス3名でエンジニアのチーム体制だったのですが、現在ではエンジニア2名、ビジネス1名体制でサービスを運用しています。エンジニアに関しては僕と開発責任者の2人です。しかし、人数が減ったからといって実施する広告案件や施策が待ってくれるということもなく、開発速度は維持（なんなら現在立ち上げ期なのでもっと向上）していかないといけない状況をぶつけられました。そこで僕らが決断したのは、AIを単なる「補助ツール」として使うのをやめることでした。AIエージェントを自律的な「チームメンバー」として大量生産し、AI駆動の次世代開発基盤を構築する。 まだ誰も正解を持っていないこの領域で、僕たちが先導的に開拓してきた「2人で6人分実装する」ための戦術の過程を解説します。
ちなみに、今回の記事では主にClaude Codeでの話をするのですが、昨年12月初旬では 私たちの開発基盤はAI駆動？なにそれ？程度でした。しかし、1月末現在、リポジトリ内にはAIエージェントで利用する、Skillが37個、SubAgentが24個 と用途や担当領域別にAIが専門的な知識をつけるための仕組みを整えることができています。
- みなさんAI活用できてますか？
みなさんは、AIを使った開発でどのくらい効率が上がっていると感じていますか？僕自身、最初はAIを会話相手として利用することで簡単な修正をしてもらったり、少し煩雑な実装も依頼して違う部分を見つけたらまた依頼して… （N回ループ）みたいなことをやっていました。でも、今は開発のプロセスのほとんどをAIでやってもらうようになりました。自分たちのチームでは、AIを「主導者」そして人間は「監督」とする開発フローにすることで、AIを補助ツールとする開発からAIをフル活用した開発にシフトさせました。
僕は、AIを補助ツールとして使っていた頃から思っていたことがあり、それが
「AI使うことで自分でやるべき作業は減ったけど、これって効率化できてるんだっけ … ？」
ということです。おそらく世の中的に思われているAIを使った開発イメージは
実装タスクに対して、仕事が早く終わるようになる
ほとんど全部AIにやらせられるから人間の仕事が楽になる
という感じなのではないでしょうか。でも、それって本当でしょうか？僕自身は
実装タスクに対して、仕事が早く終わるようになる → 利用方法によっては業務効率は悪化
ほとんど全部AIにやらせられるから人間の仕事が楽になる → 実装効率を上げるには、むしろ集中力やコンテキストスイッチを頻繁に行う能力が求められるため楽になるわけではない
と考えています。僕自身、今回AI駆動開発に切り替える際に下記のような体験をしました …
今のAIを使った開発の社会的な現在地
読者の中には、AIを入れることで逆に仕事効率が落ちたと感じている人も少なくないと思います。
これは僕の感想なのですが、技術に特化して強いエンジニアほど、最初AIを使うまでのハードルとして、「自分でやるより効率が悪くなる」というのが浮かぶのではないかと思っています。たしかに、AIがプログラミング初学者の書くような意味のわからないコードを生成してこられても、それを修正する方が工数ですし、この気持ちもわかります。
大半のエンジニアはこの例に挙げたこと以外でも、さまざまな要因によって、AIはあくまで「補助ツール」のような使い方が現状多くなっているのではないでしょうか？この補助ツールに留まっている理由としては、2, 3年前と比較すると、当時では考えられないくらいAIが進歩し、日々のアップデートに追いつけてないというのももしかしたら要因に挙げられるかもしれません。（僕もまだまだAIど素人だと思っています）
最近ではSkillやSubAgent、さらには直近ではAgent Teamsなども登場し、まだこの開発業態にベストプラクティスがない中で、利用方法を模索している状況という方も多いと思います。それが故に、とりあえずAIの出してくる答えの精度を上げるためにSkillやSubAgentを導入まではいくものの、主導者は人間 の状態になっているプロダクトが多いのだと僕自身は考えています。
僕の考える AIを “活用” するための方法
では、どうやったら、AIを補助的なツールではなく、活用した開発にできるのか？僕自身の答えとしては下記の２点だと考えています。
前者については、今まで話してきたようなAIの補助ツール的な使い方においては、主導者はあくまで人間であり、方向性を途中途中で操作しているのは人間です。しかし、AIを活用させるためには、人間がするタスクは２つで 「意思決定」と「確認」となり、主導者ではなく監督的役割にシフトさせていく必要があると考えています。人間がやることは、「AIに最初インプットさせる情報・方向性の決定」、「AIが出す選択肢の中からの決定」、「AIが出すアウトプットの最終確認」といった、ネクストアクションに繋げるための決定と確認になります。具体的には下記のようなものが人間が行うものに該当すると思っています。
AIによるアウトプット生成過程での質問回答（意思決定）
AI出力物の簡単な確認 / 修正 要件定義書（ビジネス/技術）の確認
検証環境デプロイ前の最終PR確認
では逆にAIはというと、もともと人間がやっていた主導者となり、skillやsubagentを起動させて、監督が求めるアウトプットを出力するためのリーダを担います。これは、単に出力物を出すという補助的な使い方ではなく、生成過程での軌道修正も含めて、AIが主導するということです。最終形態としては、ここに人間は関与しないのが完全理想状態です。私が今回実装したAIを主導者とした開発ワークフローについては次章で説明します。
次に後者についてです。これはやることは難しいかもしれませんが考え方は単純で、人間が監督的な役割になることでいくつかのタスクを並列することができるようになるため、そこで業務効率をあげようという話です。AIが主導して実装することで、2章の内容で説明したように人間の仕事はもしかしたら楽になるかもしれませんが、現状のAIでは単一タスクでの実装効率は、多くの場合むしろ低下します。これは、実装するためのコンテキストをAIはあまり知らないため過去の実装内容だったり、ドキュメントだったりを調査するところからAIは開始し、実装計画をたて、ビジネス要件との整合性を確認して軌道修正し … のようにAIにやらせることでその過程が多くなってしまうため、１つ１つは人間より早いかもしれませんが、合計すると単純な実装ほど実装効率は悪くなっていきます。そのため、
いくつかの実装タスクを並列的に監督する
ランチ行っている間に実装させる
…というように、人間が別のことで動いている前提 が効率をあげるために必須になってきます。
もしかしたら今後のAI技術の進歩でまるでコンパイラでコードをコンパイルする感覚で実装したいものが実装できるような社会になるかもしれません。しかし、そのような時代になったとしても、AIがあるということに胡座をかかず、人間は監督としてAIを動かし、空いている時間で別のタスク・用事をこなすというAI活用スキルとしてずっと必要になると考えています。
- AI駆動開発ワークフロー
私たちの開発フローの全体像について
前章で「AIを主導者、人間を監督」にするという話をしました。では実際に、私たちはどのような開発フローを構築したのでしょうか？
まず、AI導入前後の変化を端的に示します。
人間がバックログに積まれたIssueを読み、具体の要件を頭の中で整理 → 特に影響範囲が大きかったり実装コストが高いものだったりはDesign Docに詳細をまとめる
Claude Codeに「〇〇を実装して」と会話ベースで依頼
出力が微妙なら修正を指示して…（N回ループ）
人間がPRを作成し、人間がレビュー
人間はIssueの概要として要件の概略を書くだけ（曖昧表現でOK）
AIが要件深掘り → 技術設計 → タスク分割 → 実装 → レビューまでを主導
人間は各フェーズの「確認」と「意思決定」のみ
このフローを支えているのが、SkillとSubAgentという2つの仕組みです。Claude Codeを使ったことがある方なら、CLAUDE.mdやカスタムスラッシュコマンドはご存知かもしれません。私たちはその先にある、AIがAIを起動・管理し、オーケストレーションする構造を構築しました。
Skill: AIがもつ専門性もしくは従うべき振る舞いを定義。「どの順番で何をすべきか」「品質基準は何点以上か」「失敗したらどうするか」を明文化したもの。
SubAgent: 特定の領域に特化した専門AIエージェント。Go実装担当、TypeScript実装担当、技術レビュー担当…など、人間のチームメンバーのように役割分担をしたもの。Skillを利用することも可能。
メインエージェントがSkillを用いてオーケストレーター（指揮者）としてSubAgentを起動・制御する構造になっており、これらを組み合わせることで「要件定義 → 技術設計 → タスク分割 → 実装 → レビュー」という開発フロー全体を自動化しています。以下、各フローを順番に解説していきます。
開発フロー1: ビジネス要件詳細の生成
すべての開発は「何を作るか」を明確にするところから始まります。従来であれば、エンジニアがIssueを読み解き、要件を整理し、設計を考え…という作業が必要でした。私たちのフローでは、この最初の一歩をAIに任せるところからスタートさせます。
私たちのプロダクトではバックログをLinearで管理しており、LinearのIssueを起点に実装を行います。そして、このフローで人間がやるのは、Linearに以下のテンプレートで要件の概略を記入することだけです。
[機能名] ## オーナー <!-- 誰がこの機能に責任を持つのかを記載 --> @名前 ## 背景 <!-- 1-3文で課題と目的を記述 --> ## やりたいこと | 機能概要 | 優先度（Must/Should/Could） | 備考 | |----------|---------------------------|------| ## やらないこと | 機能概要 | 除外理由 | |----------|----------| ## 誰が使うか <!-- 主要ユーザー --> ## As Is と To Be As Is: <!-- 1-3文で現状を記述 --> To Be: <!-- 1-3文で目指すべき状態を記述 --> ## 受け入れテスト項目 | テストID | シナリオ | Given（前提） | When（操作） | Then（結果） | 優先度 | |----------|---------|--------------|-------------|-------------|--------| | AC-001 | 正常系：〇〇 | ... | ... | ... | Must | | AC-002 | 異常系：〇〇 | ... | ... | ... | Must | ## 制約・前提条件 <!-- あれば -->
このテンプレートは「完璧に埋める」必要はありません。背景・やりたいこと・As Is/To Be あたりを数行書けば、AIが残りを深掘りしてくれます。受け入れテスト項目も、書けるところだけ書いておけば、AIが網羅的に補完します。
このLinear Issueを起点に、AIが以下のステップでビジネス要件定義書（BRD）を生成します。
Linear Issue取得: MCP連携でIssueの内容を自動取得
分析・深掘り: analyzer agentが要件を分析し、曖昧な点を人間に質問
BRD生成: generator agentが分析結果から要件定義書を生成
品質検証: validator agentがスコアリングし、基準未満なら自動修復
Skill・SubAgentの構成
このフローでは、1つのオーケストレーターSkillが3つの専門SubAgentを順次起動します。
Skill: creating-business-requirement（オーケストレーター） │ ├─ 1. SubAgent: business-requirement-analyzer │ 役割: Linear Issueの取得、要件の曖昧さ検出、質問ループ │ 出力: analysis_result.md（分析結果） │ ├─ 2. SubAgent: business-requirement-generator │ 役割: 分析結果からBRD生成、ユーザーレビュー │ 出力: business_requirements_definition.md（BRD） │ └─ 3. SubAgent: business-requirement-validator 役割: 10観点でスコアリング、80点未満なら自動修復（最大3回） 出力: validation_report.md（検証レポート）
「なぜ1つのAgentで全部やらせないのか？」と思う方もいるかもしれません。理由はコンテキスト分離です。1つのエージェントに全てやらせるとコンテキストが膨張してパフォーマンスが落ちます。専門エージェントに分割することで出力品質が安定し、途中で失敗しても該当フェーズだけやり直せます。
質問ループ — AskUserQuestionでAIが「聞いてくる」仕組み
analyzer agentの最大の特徴は質問ループです。これを実現しているのがClaude CodeのAskUserQuestionツールで、AIが処理の途中で人間に選択肢付きの質問を投げかけることができます。
analyzer agentは要件の曖昧な部分を検出すると、このツールで人間に質問を投げてきます。「このエッジケースの挙動はどうしますか？（A: エラーを返す / B: デフォルト値で処理）」「優先度が未指定の項目があります」「スコープ外とする機能はありますか？」 といったように、 不明点がなくなるまでループが継続します。
このAskUserQuestionツールの存在が、私たちのフローの根幹を支えています。AIは「言われたことをやる」だけでなく、「足りないことを聞いてくる」のです。人間がLinearに書いた概略（曖昧な状態）を、この質問ループを通じて詳細な仕様レベルまで詰めていきます。人間が「後で考えよう」と先送りしがちな部分を、AIが容赦なく突いてくるので、結果として網羅的で具体的な要件定義書が生成されます。
Linearで何を詰めるべきか — 「概要」から「仕様」へ
テンプレートは「完璧に埋めなくてよい」と書きましたが、以下の4点は意識的に詰めておくと後工程の品質が大きく変わります。
やりたいこと / やらないこと: Must/Should/Couldの優先度を必ず記入し、曖昧な表現を排除。Scope / Out of Scopeを明確にしておくことで、AIが「親切心」でスコープを広げてしまうのを防ぐ
受け入れテスト項目: Given-When-Then形式で正常系・異常系・境界値を網羅。タスクの完了条件はここで確定させる
As Is / To Be: 「現状：手動でCSVアップロード → 目標：APIで自動連携」のように差分が明確なレベルで記述
BRDはこの後のすべてのフェーズの入力データです。特に受け入れテスト項目はBRD → Design Doc → タスクファイル → TDD実装まで一気通貫で引き継がれるため、ここでの具体性がフロー全体の品質を左右します。最初の10分で要件を詰めることが、後の作業での手戻りを防ぎます。
要件整理にかかる人間の実作業が数時間 → 約10〜20分（質問回答+確認のみ）に短縮。要件の網羅性・具体性は人間だけで書くより向上し、フロー全体の手戻りが激減しました。
開発フロー2: 技術要件の生成 ~ PR粒度でのタスク分割
ビジネス要件が固まったら、次は「どう作るか」のフェーズです。ここでは、AIが実際のコードベースを読み込んだ上で技術設計を行い、さらにPR粒度の実装タスクに分割するところまで自動で進みます。
Design Doc生成のステップ
BRD解析 + コードベース分析（既存コードの調査・影響範囲特定）
モジュール別テスト計画の生成（TDD前提）
Design Doc生成（Mermaid図を含むアーキテクチャ設計）
品質検証（ビジネス要件充足・テスト項目・技術要件を重点レビュー）
Design DocのTODOセクション解析・依存関係分析
モジュール単位でPRタスク生成（Backend / Frontend等） // タスク分解粒度は調整可能にしている
品質検証 → 検証PASS後にLinear sub-issue自動作成
Skill・SubAgentの構成
このフェーズでは合計7つのSubAgentが動きます。Design Doc生成で4つ、タスク分割で3つです。
Skill: creating-tech-design-doc（オーケストレータースキル） │ ├─ 1. SubAgent: tech-design-doc-analyzer │ 役割: BRD解析 + コードベース分析 + 技術スタック特定 │ 特徴: リポジトリの実コードを読み込んで既存パターンを把握 │ ├─ 2. SubAgent: tech-design-doc-test-generator │ 役割: 影響モジュール別のTDDテスト計画を作成 │ ├─ 3. SubAgent: tech-design-doc-generator │ 役割: 分析結果 + テスト計画から Design Doc を生成 │ └─ 4. SubAgent: tech-design-doc-validator 役割: 10観点スコアリング + BRDとの整合性チェック + 自動修復 Skill: creating-pr-tasks（オーケストレータースキル） │ ├─ 1. SubAgent: pr-tasks-analyzer → Design Doc解析・依存関係分析 ├─ 2. SubAgent: pr-tasks-generator → タスクファイル生成 └─ 3. SubAgent: pr-tasks-validator → 9観点スコアリング + Linear sub-issue作成
コードベース分析 — AIが「コードを読んで設計する」
このフローで最も強力なのは、AIが既存のコードベースを実際に読み込んだ上で設計を行う点です。analyzer agentはリポジトリ内のコードを走査し、既存のアーキテクチャパターン・使用ライブラリ・命名規則を理解してから設計します。人間のエンジニアが「今のコードがどうなっているか」を調べてから設計するのと同じことを、AIが自動でやってくれるわけです。
タスクの自己完結性 — ファイルをインターフェースにする
PR粒度のタスク分割で最も重視したのは自己完結性です。各タスクファイルには、タスク概要・As is / To be・スキーマ定義・API仕様・テスト項目（Given-When-Then全文）・依存関係がすべて含まれます。Design Docを参照しなくても実装に着手できる状態です。
この「ファイルをインターフェースにする」という設計思想は、こちらの記事の考え方を参考にしています。エージェント間の連携を会話ではなくファイルの入出力で行うことで、各フェーズが疎結合になり、途中からのやり直しや並列実行が容易になります。
なぜここまで情報を詰め込むのか？次のフロー（実装フェーズ）で複数のタスクを別々のAIセッションが並列実行するからです。タスク間のコンテキスト依存をゼロにすることで、並列実装が成立します。
AIがコードベースを分析した上で設計するため、既存コードとの整合性が担保されます。またタスクの自己完結性により、並列実装がスムーズに回るようになります。
開発フロー3: ローカルでの実装 / レビューフロー
では、いよいよ実装フェーズです。ここが私たちのフローで最もエージェントが活躍するパートで、タスクファイルとDesign Docを入力に、AIがTDD（テスト駆動開発）で実装し、CIを通し、コードレビューまでを自動で完走します。
言語判定・エージェント選択（Go / Next.js / NestJS / Terraform等を自動判定）
TDD実装（RED→GREEN→REFACTOR）
CI実行（ローカルでCIが通るまで自動修正）
コード簡素化（code-simplifier agentの起動 → 再CI）
Tech Review + Spec Review（レビューエージェントの並列実行）
指摘対応ループ（両方80点以上かつCritical/Highレベルのレビューがなくなるまで修正→再レビュー）
Skill・SubAgentの構成
このフローの心臓部である working-implementation
Skill: working-implementation（オーケストレーター） │ ├─ 【PHASE 1: 実装】技術スタックに応じた実装SubAgentを自動選択 │ ├─ gopher （Go実装担当） │ ├─ nextjs-implementer （Next.js担当） │ ├─ nestjs-implementer （NestJS担当） │ ├─ react-implementer （React担当） │ ├─ aws-sre （Terraform/AWS担当） │ ├─ snowflake-sre （Terraform/Snowflake担当） │ ├─ sql-implementer （Snowflake SQL担当） │ └─ ui-implementer （UI実装担当） │ ├─ 【PHASE 1.5: リファクタ】CI成功後に必ず実行 │ └─ code-simplifier （コード簡素化担当） │ └─ 【PHASE 2: レビュー】2つのレビューを並列実行 ├─ code-tech-reviewer → 8観点でスコアリング └─ code-spec-reviewer → Design Docとの整合性を6観点で評価
開発原則をルール・スキルで定義する
AIに「いいコードを書け」と言っても、「いいコード」の基準は人によって異なります。私たちはこの曖昧さを排除するために、開発原則とその優先度をルールファイルやスキル定義に明文化しています。
開発原則の優先度体系（rules/cording.md より） P0（必須）: オッカムの剃刀 — 必要なしに存在を増やさない P1（デフォルト）: リーダブルコード、DRY原則 P2（推奨）: プログレッシブエンハンスメント P3（状況依存）: TDD/ベイビーステップ、デメテルの法則 # テストケース生成にはペアワイズ法を採用 # → 全組み合わせ（N×M）ではなく、2因子間の組み合わせで効率的にカバー
これらの原則がSkillやSubAgentの中で参照されることで、AIが「シンプルさを最優先にしつつ、読みやすいコードを書く」という判断を自律的に行えるようになります。
リファクタフェーズ — code-simplifierの重要性
実装フローの中で見落としがちですが、PHASE 1.5のリファクタフェーズは品質維持の要です。CIが通った後、code-simplifier agentが必ず実行されます。
code-simplifierは「機能を一切変えずに、コードの書き方だけを改善する」専門エージェントです。核となる原則は：
機能の保全: コードが何をするかは変えない。どうやるかだけを改善する
明確さの追求: 不要な複雑さ・冗長なコード・過度な抽象化を排除し
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み