PdMがClaude Codeで開発フローを“ひとつなぎ“にした4ヶ月
SaaSのプロダクト開発フローを刷新。
オーケストレーションされたAIが、複数エージェントを動かしながら一気通貫で、仕様策定から開発を行い、開発生産性が爆上がりしました。
「祝祭で世界を動かす。」を掲げるTAIANで、All in One 婚礼システム「Oiwaii」のPdMをしている川平（@k_haruaki24）です。TAIANには、2023年12月に入社し、約1年間、フロントエンドエンジニアとしてOiwaiiの開発を担当してきました。その後、1人目PdMとしてプロダクト開発を推進しています。
2026年4月から約4ヶ月間、Claude（Claude Code）を使って、バラバラに存在していたAIエージェントを「ひとつなぎ」にするオーケストレーションの仕組みを作ってきました。
目的は、「プロダクト開発の生産性を3倍にする」こと。結果を先に書くと、3倍にはまだ届いていませんが、1人あたりのPR数は約2倍になりました。
この記事では、その過程の面白さと苦労を、書いていきます。
AIを日常的に利用していて、チームの開発生産性を上げたい。そんな思いを抱えているPdM、エンジニアにとって、AI時代のプロダクト開発のフローの仕組み作りの参考になれば、嬉しいです🙌
すべてはこの会話から始まった
プロダクト開発にもっとAIを組み込むことができれば、開発生産性を3倍以上にすることができるのでは？
以前からプロダクトチームでは、AIを取り入れることによって、開発の生産性が上がる仕組みづくりに取り組んできました。
例えば
Devinをいち早く取り入れ、開発の一部を担ってもらう
プロダクトチームへの問い合わせ工数を減らすために、Slackでメンションを付けるとプロダクトの仕様を回答してくれる仕組み
Claudeのskillsを作り、それぞれが開発スピードを上げるための工夫
これらにより、生産性は着実に上がっていました。
この頃、PdMチームでは、Claude Codeでプロトタイプ作成の効率化に取り組んでいました。今まで数週間かかっていたプロトタイプの実装が、1日で形にできるようになった。
プロトタイプとプロダクションのコードには大きな差がありますが、日々進化するAIをもっと組み込めば、プロダクトチームの開発フローが、大きく変わるはずだと感じていました。
PdMとなってから約1年半の間、ほとんど実装はしていませんでした。プロジェクトを進めるにあたり、現在のプロダクト開発を知るところから始めることにし、Oiwaiiの大機能を担当しました。フロントエンドだけでなく、バックエンド開発にも挑戦しました。
1年半前は、AIが実装時にコードをサジェストしてくれる程度で「凄いな」と感じていたフェーズでしたが、現在は、Claude Codeにプロンプトを投げると実装が進んでいくことに大きな変化を感じました。
プロダクト開発の生産性を3倍へ
まず、「プロダクト開発生産性を3倍にする」ための計画を立て、進めることにしました。
4月：開発プロセスのAI土台を作る
5月：各チームにおいて最適化するAIエージェントを構築する
6月：各AIエージェントの磨き込み、AIエージェントを社内公開する
7月：各AIエージェントをつなぎ、プロダクト開発のフローに組み込む
プロダクトチームで、AIエージェントを育てるために「Feed Forward」する専用のSlackチャンネルを作りました。振り返ると、ここからAIエージェントを使って開発生産性を上げる仕組みが動き始めました。
TAIANには「Feed Forward」というValueがあり、事業を前に進めるためにお互いに指摘し合う文化があります。
困っていたのは、工程の繋ぎ目だった
そもそも、何に課題があったのか？
これまでも、プロダクト開発を仕組み化するために、スクラム開発の導入などを進めてきました。
TAIANのスクラム開発の導入の経緯は、こちらの記事に記載しています。
スクラム開発を導入して、一定のスピードは出ていました。しかし、ありがたいことに契約していただいている顧客が増え、日々多くの要望をいただくようになりました。それぞれの要望がリリースされるまでには、多くの時間がかかっていました。
SalesやCSが商談、顧客定例で挙がった要望を整理して、要望リストに起票する。そこから背景や現状の課題を説明してもらい、PRDやバックログにするために仕様を決める。デザインチームに渡してデザインを作成してもらい、仕様とデザインをエンジニアに渡して実装する。これらのプロダクト開発フローの繋ぎの部分を手作業で、背景や意図をコミュニケーションを取りながら、コンテキストを渡していました。
コンテキストを渡す中で抜け落ちてしまうこともあり、
「あの機能ってどんな仕様でしたっけ？」
という会話などが発生し、それぞれでコミュニケーションを取ったり、Slackを探し回ることがありました。
AIで各工程を速くするだけでは、それぞれの工程で背景や意図を伝える作業は無くなりません。それぞれの工程の繋ぎ目でコンテキストが落ちないようにシームレスにつなぐ必要がありました。
5月は各チームでAIエージェントを育て始めた
要望収集領域
Slackで特定のメンションを指定するとスレッドの会話を読み取り要望リストを起票してくれるエージェントを作成しました。
要望が発生した「背景」、「現状の課題」、「叶えたいこと」など、優先順位を決めるための指標を色々と入力する項目があります。このエージェントは、それぞれの項目を適切に埋めて起票するところまで担ってくれます。
仕様策定領域
ブライダル業界のドメイン知識を組み込み、仕様を考えてくれるエージェントを作成しました。
業界標準の知識を持つエージェントと、顧客企業ごとの固有の事情を知るエージェントを議論させて、仕様の叩きを出す仕組みになっています。
そこにPdMの観点やエンジニアの観点を入れて、デザインに渡せる仕様の土台を作るところまでを担ってくれます。
デザイン領域
仕様をもとにドラフトのデザインをFigmaで作成してくれるエージェントを作成しました。
仕様の領域で作成したアウトプットを渡すと、デザインシステムに沿った画面のデザインがFigmaに出力されます。BeforeとAfterのデザインが作成されるようになっており、変更ポイントなどが視覚的に分かるようになっています。
エンジニア領域
これまでの情報をインプットにして、実装と実装レビューをするエージェントを作成しました。
Oiwaiiでは、Yagyu.jsというDDDを取り入れており、それらのルールを書き起こしていきました。
OiwaiiのYagyu.jsについては、こちらの記事に記載しています。
実装してレビューで見つかった改善ポイントをClaudeのskillsに書き起こす。それを実行して改善ポイントをひたすらアップデートするPDCAを回し続けました。その結果、ある程度のコード品質を担保したコードを実装、レビューしてくれるようになりました。
AIエージェントを育てるために作ったチャンネルには、改善のPR、上手く行った出力・失敗した出力などを頻繁に投稿するようにしました。エージェントを作って育てる過程が閉じていると、作った後も使ってもらえません。育てる段階から熱を保てる場所があることが重要だと感じています。
このままいけば、エージェントを育てることで開発生産性を3倍にすることが、見えた気がしました。
6月にぶつかった、skillsの壁
順調に見えた6月末、壁にぶつかりました。
skillsが増えるにつれて、AIの精度が落ち始めました。skillsやrulesが乱立し、どこに何を書けばいいか分からなくなる。内容の重複や、汎用性のない具体的すぎる記述が溜まり、エージェントが毎回読み込むコンテキストが肥大化していきました。AIを賢くするために書きためた指示書が、逆にAIの足を引っ張っていた。
そこで、skillsの「改善アップデート」に取り組みました。
計測
テレメトリで各skillの呼び出しを計測し、実際に使われているskillsを把握する
整理
実装とレビューで散らばっていた記述を一箇所にまとめる（SSoT化）
圧縮
具体的すぎる記述は抽象化して簡潔に書き直し、rulesは最小限に止める
削除
使われていないもの、重複しているものは思い切って削る
skillsやrulesは、書き足すことばかり考えていましたが、必要なのは「増やす」より「手入れ」でした。人間の組織のドキュメントと同じで、書く文化と同じくらい、削って整える手入れが必要でした。そして、計測していなければ「何を削っていいか」の判断自体ができなかったので、計測して整理することは大事な作業でした。
7月にAIエージェントを「ひとつなぎ」に
各エージェントが育った上で、エージェントを「ひとつなぎ」にすることで、既存のプロダクト開発フローを下記のようにアップデートしました。
Jiraのバックログを投げると、バックログ取得、論点の洗い出し、仕様策定、デザイン、実装、レビュー、PR作成までが一気に流れます。
各工程の節目でエージェントが「こういう方針で進めます」と問いかけてくるので、人間は方針を承認するだけになっています。
中規模のバックログを2本投げたところ、どちらも各工程のエージェントの問いかけに回答と承認をしているだけで、PRまで到達し、プレビュー環境で画面が動くところまで確認できました。
この2本は検証にとどめましたが、その後、同じフローで進めた別のバックログは、エンジニアの最終レビューを経てマージし、QAのテストも通り、実際にリリースしています。
エージェントの進む方向性がズレないように進めることが重要です。フェーズ0の段階でエージェントの問いかけに、方針を多角的に問い詰める「grill-me」という仕組みを組み込みました。
それぞれのフェーズで、エージェントからのアウトプットをきちんとエンジニアがレビューし、プロダクトの体験品質が損なわれないことを確認してから、次のフェーズに進むようにしています。
PR数は2倍になったが、3倍には届いていない
約4ヶ月のエージェント作成が終わって集計すると、1人あたりのPR数は約2倍になっていました。PR数は開発生産性の代理指標のひとつにすぎず、PRの粒度が変われば数字も変わります。今回は、チームの流れの変化を測る目安として、この数字を使っています。
ただ、この4ヶ月で本当に変わったと感じるのは、数字よりもチームの働き方です。
1. AIは「量産の道具」ではなく「品質の道具」として定着した
社内で最も使われたAIスキルの1位は、意外にもコード生成ではなくPR作成で、2位以下もレビュー系が並びました。チームはAIを「たくさん作るため」ではなく「品質を保ちながら流れを速くするため」に使っていた。これは設計したというより、使われ方を集計して分かったことで、大きな収穫でした。
2. レビューの量が増えたのに、人間の負荷は下がった
PRが増え、レビュー対象が増えましたが、人間のレビュー負荷は下がりました。AIのレビューで定型的な指摘を先に潰してくれるので、人間は設計や仕様の本質的な議論に集中できるようになりました。レビューエージェントの精度を上げながら拡充してきたことの成果でした。
3. 基盤を使う人の輪が広がった
AIエージェントの実装を進めるために、デザインシステムも導入し始めました。デザインシステムを使って機能を実装することで、ルールなどの仕組み化を進めることができました。さらに基盤としてチームで使うことで開発の生産性が上がることに繋がると感じています。
結果的に「開発生産性を3倍にする」ところには、まだ届いていません。ここからさらにAIエージェントの精度を高めていくことが必要であると考えています。
PdMの役割はどう変わるのか
顧客から「こういう機能が欲しい」と言われた時に、言葉通りに作るのか、背後の業務課題を深く知りにいき、別の解き方を提案するのか。エージェントに任せる部分が増え、生産性が上がるほど、人の判断はこの部分に集中していくと考えています。
この部分を間違えると、プロダクトに不要な機能が増えていきます。プロダクトが相対しているドメインの知識は、探しても出てこないことがほとんどです。私たちが婚礼のドメインをきちんと収集しておくことが、業務課題に対して最適な解き方を選べることに繋がります。
AIエージェントを使い、顧客に機能を早く提供できるようにはなりましたが、より一層、「何をどう作るのか」「何を作らないのか」を決めることは重要になったと感じています。
プロダクトチームへの感謝とこれから
今回のプロダクト開発フローをオーケストレーションする仕組みは、1人では構築することはできませんでした。それぞれの領域のエージェントをチームで作成できたからこそ、到達することができました。
それぞれが独立して動いていた頃より、ひとつなぎになってから面白さは一段増しました。Jiraのバックログを投げてPRが返ってくる体験は、一度味わうと後戻りできません。
しかし、怖さもあります。skillsは手入れを怠ると肥大化してAIを鈍らせる。ひとつなぎにしたことで、どこに改善の余地があるか見えづらくなる。そして、AIは普通に嘘をつきます。勝手に解釈を補って、存在しないことを伝えてくる。エージェントを育てる過程では、この点への注意が欠かせないと感じています。
現状では、エージェントがひとつなぎに動くようになった段階です。ここから各エージェントの精度を高め、プロダクト開発フローそのものも見直し続ける必要があると考えています。
TAIANでは一緒に働いてくださる方を募集しています！