☺️
生成AIと「チケット駆動」で作るAPI開発 ~ 俺、プログラミングを辞めるってよ ~

shiraji
2025/04/30に公開
 想定読者ソフトウェア開発チームに属している人
AI活用に関心がある人

 はじめにはじめまして。知ってる人はお久しぶりです。

最近めっきりアウトプットがなくなった、これでようやくzenn初投稿、Ubieのしらじです。
ところで話変わるんですが、Nintendo Switch 2が出るようですね。

 近況とPHRチーム2024年末くらいにシステム開発で利用できるAI Agent(以降、AI Agent)が爆発的に認知され、一気に開発の現場に浸透してきました。

各社、個人ブログで活用事例がいっぱい出ているし、一開発者として、ついにこの時代が来たか・・・！と考えたものでした。
https://zenn.dev/p/ubie_dev



ここ半年のUbieのアウトプットもすさまじい・・・
自分は現在PHR(Personal Health Record)チームに所属しています。

PHRとは患者の健康履歴を保存して、各種システムに適切な形で渡すという社内のバックエンドシステムです。

データの性質上、複数サービスから利用されていますし、自分が関わっているからバイアスかかってはいますが、社内でも重要なシステムの一つだと思っています。
https://herp.careers/v1/ubiehr/0k_zjwd1u9nh

(興味ある人はこちらへどうぞ。応募する時にしらじのブログに感動したとお伝えください)
PHRチームはここ最近まで複数の大型のプロジェクトが平行で走っていて、結構ドタバタな状況だったのですが、一ヶ月くらい前にようやくいろいろ片付いて、じゃあ一気にごぼう抜きしましょうか！🤗と本腰を入れて、AI Agentを利用した開発体制に作っていくことにしました。

 PHRチームの課題Ubieは本当に多くのシステムが動いていて、どうしても、リソースをPHRだけに割くことができません。でもUbieは健康を扱うサービスを複数運営している以上、ユーザの健康履歴を持っているPHRに関して、やりたいことは今も将来的にもたくさんあります。
他にも社内外のいろんなデータ連携案件があるのですが、基本的に
外部連携 = 生活者の情報が入ってくる = PHRチームの責務
って感じになっているので、多種多様なプロジェクトがどんどん立ち上がっていきます。
PHRは複数サービスからデータもAPIも利用されています。

そのため、PoC的にサクッと作って、ユーザに使われなかったら、さっさと下げる。という感じでやってしまうと、もし把握できてないデータの利用があった場合、その場で障害を発生してしまう可能性があります。

しっかりとモデリングをして、APIの設計をして、将来的に変更しても互換性を保たせるよう考慮しつつ、慎重に開発を進めていく必要があります。

(必要に応じて、負債を積んででも開発速度を選ぶこともあります。)
リソースが少ない + 慎重な開発 = どうしても開発速度が出ない
PoCでガンガン回している他のチームから見たらかなり遅いPHRチーム。データをPHRに入れるのは時間がかかるから後回しにしようみたいな風潮ができていました。このままで良い訳がないと。少ないリソースで開発速度を上げるためになにかしら動く必要があると考えていました。

 方針決めまず最初に行ったのは生成AIやAI Agentをどのように活用するのかを検討しました。

全く使わないのか、開発のサポートとして使うのか、それとも開発の主体として使うのか。

最近の流れである 新しいモデルが出る -> 驚く -> 翌月 -> 新しいモデルが出る -> 驚く という状況を踏まえると、数年後(ひょっとしたら数カ月後)には人間には生成AIより早く正確にコードを書くことが難しくなると判断しました。
このスライドが個人的にすごく好きで許可も取らずに勝手に唐突に紹介するのですが
やっぱりエンジニアに許された特別な時間は終わるんだと。
UbieのValueには All In - 慣性を捨て、大きな未来に賭けよう というものがあります[1]。

開発の主体はAI Agentにまかせて、開発者が助手席に座るというスタイルに移行しようと心に決めました。
ちなみに話が逸れるのですが、この決断をするときの相談相手は社内用の生成AI Webアプリケーション「Dev Genius」(略してDevG)です。Ubie社内で利用できる業務支援ツールです[2]。さらに話を逸らすのですが、このツールは社内で使わない日がない。さくっとリリースしてDevGを止めてしまったら、slackでそこら中から障害報告が上がってくる。自社サービスの中で一番速く障害報告があがってくるだろう、というスーパー重要なツールです。いつもありがとう！

 どう主体になってもらうか？決意したはいいものの、AI Agentに頼む〜！と念じていればすべて終わるなんてことはないので、どうタスクを譲るか？をまず考える必要がありました。

そのために自分たちが今までどのように開発しているかを振り返りました。
自分たちは、

チケットを作成し、

チケットの内容を埋め、

チケットを見積もり、

チケットの優先度を決め、

チケットの内容に沿って開発をしています
つまり自分たちはチケット駆動で開発をしている訳です。(あくまで理想として)チケットにそのタスクのすべてが記載されている訳です😉
ということは
チケット = プロンプト
と考えたらどうだろうか？と。AI Agentにチケットを渡せば、そのまま開発できるのではないか？と考えました。

実験としてすでに詳細が書いてあったチケットをコピペして渡してみるとあら不思議！AI Agentはそのままある程度形にしてくれました。もしやったことがない人は手元にあるAI Agentでやってみてください。よくわからない方向にいったりもしますが、ある程度は作ってくれます。

 人間のレベル上げ開発タスクの移譲を進めつつ人間を振り返ってみると、PHRチームは業務で生成AIを使う機会が少なかったため、DevGもそうなのですがAI Agentも全然使いこなせていませんでした。

そこで、人間のほうのレベルも上げるため、なにかスクラムで改善できないか？と再度DevGに相談してみました。
さらにDevGと壁打ちをした結果、 プロンプトのテスト という概念が出てきました。
確かにチームにはプロンプト力が足らない、チームのスキルの底上げが必須だと思ったので、プロンプトテスト時間を毎日30分取り、チーム内で生成AIを使った開発を進めていくことにしました。
試しに1週間やってみると、チーム内で知らない知見がボロボロ出てくるし、ペアプロ(ペアプロンプト)することで一気にチームのスキルが上がりました。

ちなみに朝のデイリーから30分ほど時間を取ってもらっているのですが、いつもみんな時間気にせずに続けてしまって、おなかがすくまでチームでペアプロしています。一ヶ月経過した今もやってます。

これをはじめた頃は、本当にびっくりするほど想定外のことばかりAgentが始めてしまって、おいおいおいーって感じになっていたのですが、やればやるほどプロンプトが洗練されていって、最近はほぼ一発で動くものが作れるようになっています。

 ペアプロ(ペアプロンプト)でやってることペアプロでやってることはよくある振り返りです。KPTです。
前日の開発業務中に新しく学んだこと
前日の開発業務中にうまくいかなかったこと
どう改善していくか？
のような感じで、プロンプトにフォーカスしたKPTをします。
その後、プロンプトのテストの時間です。一人の画面を共有し、プロンプトで開発タスクを実際に依頼して、AI Agentが思ったようなアウトプットを出し始めるか？を確認します。

問題がある場合は、全員でどのように改善すべきか？を話し合い、問題なく進みそうであれば、一旦そのプロンプトは放置して、別の人の画面を共有し、別のタスクをAI Agentに投げつける。これを繰り返していました。

 今はどうなってる？1,2週間やっていけば、ある程度チームに知見もスキルもたまったので、開発体制に生成AIを組み込んでいきました。

まだまだ改善余地があるし、このフローが始まって日が浅いので、来週にはいくつか変更してるかもですが、ふんわりまとめると今はこんな感じで開発をしています。
人間がしているのは、DevGに依頼して、JIRAにコピペして、AI AgentにMCP経由で投げつけて、実装が終わるまでラーメン食ってるだけです。以降順番に説明していきます。

 チケット生成最初に生成AIにやってもらっているのは、チケットの生成です。DevGにはプロンプトを社内共有する仕組みがあります。[3]

共有プロンプトの一つにチケットを特定のフォーマットに生成してくれるものがあります。いちいちDevGを開くのが面倒なので、slackに必要な情報をざっくり書いて、Slackのreactionでキックすることで、slack上でチケットを作ります。[4]
実際のチケット情報などを公開するのは難しいので、このブログ用に右手親指の長さ登録APIを作ってみます。



このメッセージにJIRAのチケットを生成するreactionをつける


与えた情報が薄いので要らない情報が入ってるけど、形にはなってる
これをJIRAにコピペします。
MCP writeに関してJIRAにコピペします はすべてを台無しにする一行w

本来はMCPでwriteしたいのですが、現状、懸念点があり、未整備。今Q中にはできるようになってると思う。

 見積もりスクラムガイドには数年前に見積もりって言葉が消えたと聞いたのですが、PHRチームではチケットの見積もりをまだしていて、それによって優先度を決めています。ただ精緻に見てるわけではなく、雑にとりあえずざっくりどれくらいか？くらいの見積もりしかしていません。チケット完了後振り返りもしていません。その最低限でもチケットをみんなで読み込んで、認識揃えて、ポーカーして〜ってやっていくと結構時間がかかります。
そこで、これを生成AIにまずたたき台を作ってもらい、認識の齟齬の確認だけにしてしまいます。
UbieではCursorやGitHub Copilotを使えます[5]。CursorやGitHub Copilotを開き、そのJIRAチケットをMCP経由で取得し、チケットの見積もりを依頼します [6] [7]。これをDevGではなく、エディタでやっているのは、エディタであれば、簡単に関連するファイルをcontextに入れることができるからです(DevGの開発お願いします![8] )
依頼はこんな感じで出しています。
https://[JIRAのURL]/xxx-yyyy このチケットのストーリーポイントを振ってください。理由も知りたいです。

https://[JIRAのURL]/xxx-zzzz このチケットがストーリーポイント2です。2はだいたい1日くらいでできるイメージです。
これをAI Agentに指示すれば、こんな感じのアウトプットが出てきます。
他にも大きなファイルのリファクタリングタスクも見積もりしてもらいました。


このスクショにあるファイルA, ファイルB はかなり大きなファイルなのですが、このファイル2つをcontextに入れずに見積もりをさせるとストーリーポイント3というアウトプットになります。

見積もり依頼投げる前にできる限り関係ありそうなファイルや条件などを提供するとより正確な値を見積もってくれます。
これをたたき台にして、人間がストーリーポイントを決めます。基本的に齟齬がないか？くらいでサクッと進めてしまいます。

 チケットの詳細作成チケットの詳細もエディタに埋めてもらいます。
チケット作成用のプロンプトを作りました。数百行あるし、このファイルを参考に〜とか、この処理、メソッドを読み込んでーとか、このような処理を書く〜などほぼ外に出せない内容なので、ここでは割愛させてもらいますが、ざっくりまとめると以下の4つのサブチケットを作成してもらっています。
* GraphQLスキーマの実装
* ドメインモデルの実装
* GraphQLリゾルバの実装
* テストの実装
実際にGraphQLスキーマの実装のサブチケットを作成してもらうとこんな感じ。
同じようなチケットがそれぞれのタスクで作成されます。

 開発依頼すべてのチケットの準備ができたので、あとは実装してもらうだけです。

サブチケットを一個づつ、実装してもらいます。
https://[JIRAのURL]/xxx-xxxx このチケットの実装をしてください。
https://[JIRAのURL]/xxx-yyyy が親チケットです。
https://[JIRAのURL]/xxx-xxxy, https://[JIRAのURL]/xxx-xxxz は実装済です。
テーブル名は smoking_period です。
完了チェックリストは実装後に必ず確認してください。
事前準備は実装前に必ず確認して、ファイルを読み込んでください。
話いきなりそれますが、本来やりたいのは
https://[JIRAのURL]/xxx-yyyy が親チケットです。
サブチケットを順番に実装してください
という依頼です。実はこれで単純なGet系のAPIでは事足りるのですが、CRUD系のAPIの場合、サブチケットの3つ目あたりから挙動がおかしくなって、どっかに飛んでいくことがあります。つまり再現性がなくなります。必要な部分の再現性がないプロンプトは悪なので、今のところはこのプロンプトではダメだという判断をしています。新しいmodelの登場を待つしかない状況です。
で、実際に問題なく、開発が終わるとこんな感じのPRが飛んできます。

(途中で止まったりする場合は、gitのコミット、PRの作成などの依頼をしますが、基本全部agentにやってもらいました。)
このPRをチームでレビューして、QAして、リリースします。

(つまり人間が唯一やれることである責任だけ押し付けられることになります)

 結果これまでに生成AIを活用し、4つのAPIを人間のコード記述なしでリリースしました。

微修正してリリースされたものを含めると結構な数のAPIがリリースされています。

2週間以上経過した今でもペアプロンプトを毎日1時間くらいやっていますが、それでも開発速度が上がっているように見えるし、SPを生成AIを使う前提で振って、生成AIなしと同じ速度での開発ができています。
実際にこのフローをやり始めた3月くらいから今までのベロシティレポートです。緑の棒が実際に完了したタスク量です。中にいる自分が見ても開発速度は落ちてないように見えるし、今後人間のレベルがより上がれば、開発速度もかなり上がると考えています。

 チケットの必要性に関してよく考えるとチケット必要ないのではないか？AI Agentに方針作ってもらい、そのセッションでそのまま開発しちゃっていいのではないか？と考えると思います。自分もでした。
しかしこれは自分たちのチームではチケットを生成するメリットがあまりに多いので、このフローで今のところ良いという判断をしました。
チケットに書き出すメリットとして:
複数人がチケットを確認して、着手前に内容をレビューできる
着手が遅れたとしても、後日チケットを見れば何を実装するかがわかる
チケットが詳細に記載があるので、他チームや業務委託メンバーにチケットを渡して、実装してもらうことができる
プロンプトがしっかり長めに書かれるので、並列で実装ができる(三並列余裕で開発できる。チケット作成しつつ、別チケットの実装とかもできる)
agentが今なにを実装しているのか理解しやすい。おかしな方向に行ったときに戻りやすい。
AI Agentもコンテキストいっぱいにつめこんで、多くのタスクを依頼すると、重要なことを忘れてしまったり、おかしな方向に進みやすいです。チケットを細かく切ることで、AI Agentにも都度重要項目を思い出させることができるし、その実装タスクを再現性高く実行してくれます。

 今の課題いろいろうまくいってるように見えますが、まだ課題があります。
タスクを細分化しても、現状では高価な特定のモデルでしか期待通りのアウトプットが得られていない
安価でアウトプットの良いモデルが登場するのを待つ以外なにもできない（「某会長みたいに1時間動いて、あとは祈るだけみたいなね」のような状態）
プロンプトチューニングを諦めると割り切る判断が難しい
無駄にどんどん時間を溶かしてしまう。新しいモデルが出たらワンパンな可能性もあるため、ある程度割り切らないといけない。


 まとめチケット = プロンプト
これを基本に置いて、今自分が関わっているチームでの開発体制ががらっと変わったよという話でした。
まだまだ人間がやってる部分も多いし、複雑なコンテキストが絡むようなときは人間を主体にして、AI Agentにはサポートに回ってもらうこともありますが、単純なCRUDのAPI開発であれば、サクッと渡せるところまで来ました。
開発者としてまだ引退はできないですが、コーディングをゴリゴリしていくってより若干POよりの立ち位置にシフトしている印象があります。今後もこの流れは加速するだろうし、仕事はプログラミングです！と言うのはそろそろできなくなってきたなーって時代の流れを感じます。

脚注
https://www.notion.so/ubie-inc/Ubie-1d76bbd4e00f809bb282d93ce1552063?pvs=4#1d76bbd4e00f81c8a92bca99c20336ae Ubieのカルチャーガイドです ↩︎
https://zenn.dev/ubie_dev/articles/ee95c03794f47f 第1回 社内用生成AI Webアプリケーションをどのように作っているか 連載予告編 ↩︎
https://zenn.dev/ubie_dev/articles/e70422c9dad644 第2回 プロンプトを再利用する、プリセットストアと共有機能 ↩︎
https://zenn.dev/ubie_dev/articles/6680c44737048d 第4回 Slackから生成AIを呼び出せるようにする ↩︎
https://zenn.dev/ubie_dev/articles/2c474a1c5f71a8 Ubie、Cursor Business導入しました！40名超の開発者で実感するAI開発支援の力強さ ↩︎
https://note.com/guchey/n/n773a2efd78cf プロダクト開発に必要なもの全部繋げたらCursorが最強のプロダクトマネージャーになった ↩︎
https://zenn.dev/ubie_dev/articles/f927aaff02d618 社内デザインシステムをMCPサーバー化したらUI実装が爆速になった ↩︎
https://herp.careers/v1/ubiehr/_oeH0lYReImI プロダクトエンジニア（生成AI） ↩︎