0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Spec駆動開発でkiroとペアオペをやってみた

Last updated at Posted at 2025-12-07

Day 6からコーディングエージェントであるkiroを導入してスペック駆動開発をやってみての感想を述べました。今回は実装経験の浅いauthをgolang(チュートリアルと簡単なコマンドラインツールしか作ったことない)をkiroとペアプロで開発してみます。
今回はAuthツールの中でもメトリクスの実装の一部を題材にペアプロの一部始終をお届けしたいと思います。

🧰下準備

Day7で記載しているように、kiroとペアプロするための事前準備としてタスクリストレベルに「人間」「AI」のタスク分けをするように頼んでいます。
これを行った上でPRを投げたい粒度でテストをKiroに作ってもらうことにしました。

🤝ペアプロのお願い

まず、新しいセッションで「フェーズ2の人間パートをこれから実装します。ペアプロでやりたいのでまずやるべきことを教えてください」とお願いします。そうするとタスクの一覧とやるべき進め方を聞いてくれます。
※ここでいうフェーズ2は、Auth Service の中でメトリクス周りを担当している部分です。

フェーズ2で実装すべきタスク
📋 タスク一覧
タスク 2: メトリクスモジュールの実装

ファイル: internal/metrics/metrics.go
Prometheusメトリクスの定義(HTTP、エラー、ビジネス)
タスク 2.1: メトリクスミドルウェアの実装

ファイル: internal/middleware/metrics.go
HTTPリクエストの自動計測
タスク 2.2: メトリクスハンドラーの実装

ファイル: internal/handler/metrics.go
/metrics エンドポイントの実装
タスク 2.4: Checkpoint - メトリクスの動作確認

テスト実行と動作確認
🎯 推奨する進め方
ステップ1: テストを確認

タスク2.3で生成されたテストコードを確認
どのような動作が期待されているかを理解
ステップ2: 実装を順番に進める

internal/metrics/metrics.go - メトリクスの定義
internal/middleware/metrics.go - ミドルウェア
internal/handler/metrics.go - ハンドラー
ステップ3: 各実装後にテスト実行

make test でテストを実行
失敗したテストを確認して修正
ステップ4: Checkpoint

すべてのテストが通ることを確認
/metrics エンドポイントの動作確認
💡 まず何をしますか?
以下から選んでください:

1. テストコードを一緒に確認する - 何を実装すべきか理解を深める
2. タスク2から実装を始める - internal/metrics/metrics.go の実装
3. 設計ドキュメントを確認する - プロパティの詳細を確認

確かに、このようなタスク分解は良いなと自分で思いました。一旦実装すべきコードのイメージを沸かせるためにテストコードを一緒に理解することから始めましょう。そうすると、以下のように返ってきました。

📊 テストから読み取れる実装要件
1. internal/metrics/metrics.go - メトリクスモジュール
テストから以下のメトリクスが必要だとわかります:

// 必要なメトリクス:
1. http_requests_total (CounterVec)
   - ラベル: service, method, path, status
   - 説明: HTTPリクエストの総数

2. http_request_duration_seconds (HistogramVec)
   - ラベル: service, method, path
   - バケット: [.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10]
   - 説明: HTTPリクエストのレイテンシ(秒)
実装すべき機能:

Prometheusレジストリの初期化
メトリクスの定義と登録
メトリクスへのアクセサー関数

💡ペアプロをKiroに依頼してみたいいところ

大きく分けて三つのいいところがありました。

  1. わからない単語があっても、調べる時間を待っていてくれる
  2. どれくらいAIが関われるのか、関わって欲しいのかの選択肢を与えてくれる
  3. 最終的に作って欲しい関数の雛形・型くらいまで考えてくれるので本当に初心者のうちには実装に集中できる

わからない単語があっても、調べる時間を待っていてくれる

これは知っているエンジニアが対面でペアプロする場合と比べて理解効率は対面の方が高いため一長一短ではあります。しかし、自分で調査するトレーニング特に1次情報に当たることを慣れていく練習やAIに知らないことを明かしても恥と感じない心理的安全性を考えると調べる時間を待ってくれるAIはトレーニングとして個人開発には有効なのかなと思います。タイパを考えると多分エンジニアに聞いた方が早い。

どれくらいAIが関われるのか、関わって欲しいのかの選択肢を与えてくれる

教師対生徒的なペアプロを行うということは、相手との関係性や、メンティの力量が試される部分だと思っています。そこで、「自分はOOまで関わることとxxまで関わることどっちもできます。どちらがいいですか?」と聞いてくれることは、こっちとしても助かるしこれが聞ける環境まで自分が後輩を育てるとなったらやれるようにしたいなというある意味模範になる質問なのかなと感心しました。

最終的に作って欲しい関数の雛形・型くらいまで考えてくれるので本当に初心者のうちには実装に集中できる

特に今回は慣れていないプログラミング言語で慣れていない実装を行うという普通はやるなと言われそうなチャレンジをしています。テストを先に書いてもらった以上テストコードに実装の関数名と型は合わせなければならず、自明に決まっている部分を先に埋めてくれるのは実はすごく助かりました。


🔧実装

実装はパッとみて実装方針が分からなければ、わかるところまでKiroに説明して残りを補ってもらい、必要に応じて写経するという方法を取りました。写経した部分に関しては分からないところが多かったということで公式情報やこの構文はどういう意味?と聞くことで知識を補うようにしています。結局実装の大部分を写経しました。それを通してMetricsってこういう構造体だったんだということがなんとなくわかり、それを踏まえて一次情報にあたることで、より理解を深められました。
今回の実装範囲のprometheusメトリクスの実装範囲については関数ごとに解説メモを明日のブログに記載しようと思います。

個人的には定型的なコーディングに関してはAIでもいいから写経して、基礎的な構文を体に叩き込むことが重要だと考えているので今回は意味を仮説立てながら写経して一次情報で答え合わせをするという方法を取りました。


🔮明日は?

明日は、今回実装した Prometheus メトリクス(CounterVec / HistogramVec) を丁寧に分解しながら、
「何を」「どう計測しているのか」を初心者目線でまとめていく予定です!📊🔥

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?