AI + 人間2人でモブプロやってみた

こんにちは、タイミーでバックエンドエンジニアをしている大竹です。この記事はTimee Product Advent Calendar 2025の5日目の記事です。

最近、AIを活用したコーディングが当たり前になってきましたが、皆さんはチーム開発でどのようにAIを使っていますか？今回は、AI + 人間2人という構成でモブプログラミング（モブプロ）に挑戦してみました。

普段は同じチームのメンバーと2人でペアプログラミング（ペアプロ）を行っていますが、そこにAIという3人目のメンバーを加えることで、擬似的なモブプロ体制で開発を進めました。実際にプロダクトコードを触りながら実験を行う中で見えてきた、AIを単なるコード生成ツールではなくチームメンバーとして扱うための工夫と、その結果を共有します。

この記事が、ペアプロ・モブプロにおけるAI活用方法に迷っている方の参考になれば幸いです。

今回のルール：AIはドライバーにしない

今回の実験でポイントとなったのは、AIの役割定義です。 AIにコードを書かせる（ドライバーにする）と、人間が単なるレビュワーになってしまい、モブプロ特有の知識共有などの目的が薄れる懸念がありました。

そこで、今回は以下の役割分担を行いました。

人間A
- 役割：メインナビゲーター
- やること：全体の進行、問題定義
人間B
- 役割：ドライバー
- やること：実際にコードを書く、AIへの指示出し
AI
- 役割：AIナビゲーター
- やること：提案、観点追加、設計の方向性提示

AIを「手を動かす人」ではなく、あえて「困ったらアドバイスをくれるエンジニア」という立ち位置に置きました。

この役割をAIに徹底させ、チームの一員として機能させるために、モブプロ開始時に以下のプロンプトを使用しました。

AIをメンバーとして迎えるための初期プロンプト

実際にCursor（AI）に入力したプロンプトがこちらです。役割を明確に定義することで、AIナビゲーターとして期待通りに振る舞ってもらえるようにしました。

あなたには、ソフトウェア開発の「モブプロ」に3人目のメンバーとして参加してもらいます。

【あなたの役割（AI Navigator）】

- 今回のモブプロでは、あなたは「提案と観点追加を担当するメンバー」として振る舞ってください。
- コードを直接書く“ドライバー”ではなく、考え方や設計の方向性を提示する“ナビゲーター”です。
- 過剰に長い提案は避け、複数の選択肢を短く提示してください。
- 人間メンバーの意図が曖昧な時は「確認質問」を返して構いません。
- 最後に、今回の変更内容の要約ドキュメントも作成してもらいます。

【あなたに求める振る舞い】

1. 小さめのタスクに対して、リファクタ・命名改善・設計改善の観点を提示する
2. 提案は複数案（2〜3個）を短く提示する
3. 必要に応じて“なぜそうするのか”の理由も簡潔に説明する
4. 人間メンバーの会話を聞きながら、関連する観点を補足する
5. 最後に、変更点の要約・影響範囲・目的・レビュー向け文章を整える

まずは「準備完了です。対象のコードを提示してください。」と返答してください。

実験してみた結果、良かった点

今回のタスクは、APIのレスポンスにプロパティを追加するというものでした。 AI + 人間2人でどのように議論したか、ハイライトを紹介します。

(コードに関わる部分はfooなどに置き換えています。)

ロジックの配置場所で迷った場面

特定のロジックをどのクラスに配置するかで人間2人が迷った際、AIに相談したところ、パフォーマンス（N+1問題）などの観点を考慮した方針を複数提示してくれました。

AIの提案（抜粋）：

## 観点1: データ取得の責務分離（Controller vs Serializer）

### 現状の課題
- A案（Controller）: コントローラーで#{モデルAのリレーション}を取得・絞り込み
- B案（Serializer）: Serializerで#{モデルB}ごとに#{モデルAのリレーション}を取得

### 判断基準
- パフォーマンス: Controllerで一括取得・preloadすればN+1を回避しやすい
- 責務: 「どのデータが必要か」はController、「どう表示するか」はSerializer
- 再利用性: Serializerが独立しているとテストしやすい

### 推奨
**Controllerで一括取得** → Serializerで判定ロジック
- #{Controller名}のfooメソッドと整合

この提案をきっかけに議論が深まり、より良い意思決定ができました。AIが複数の選択肢とその理由を提示してくれることで、人間同士の合意形成もスムーズです。さらに、決定した方針に合わせてサンプルコードを出力してくれる点も大きく、実装イメージの認識を揃えたまま議論を進められました。

課題に思った点

議論においては良かった点が目立つ中、いくつか課題も見つかりました。

課題1：ドライバーを交代しにくい

Cursorのチャット履歴がPCに紐づくため、オンラインで実施した場合、ドライバーを交代する（= コードを書くPCが変わる）と新しくチャットを作成するしかなく、それまでのやり取りが引き継げないことは課題に感じました。

今回はドライバーを交代せず、短時間のモブプロを複数回実施することで、ドライバーの負荷を軽減しつつ、1つのチャットを使い続けることにしました。

チャットの内容をエクスポートして別PCのチャットに読み込ませれば交代は可能ですが、手間がかかります。よりスムーズに交代できる方法が必要だと感じました。

課題2：待ち時間が発生する

AIに相談するとき、プロンプトを考えて入力し、回答を待つ必要があります。この待ち時間で議論の流れが止まってしまうので、テンポを崩す要因になっていました。

人間だけでモブプロをしていると発生しない、今回の実験特有の問題だと思いました。

こんなユースケースに向いていそう

今回の実験を通して、特に以下の場面でAIとのモブプロが効果を発揮すると感じました。

実装方針の選択肢を出して欲しいとき
リファクタリングや命名の相談をしたいとき
ドメイン知識は人間、一般論はAIと役割分担できるとき

一方、実装内容が最初から明確な場合は、AIを挟む待ち時間が発生するため、効果は限定的かもしれません。

おまけ：AIにモブプロを振り返ってもらった結果

モブプロの最後に、AIに自身の振る舞いを振り返ってもらいました。

AIの回答（抜粋）：

## 良かった点

1. 複数案の提示: リファクタリングや命名で2〜3案を短く提示できた
2. 実装対応: エラー修正やテスト追加を迅速に対応

## 弱点

1. 役割の一貫性: 「AI Navigator（提案のみ）」と「実装も行う」の間で一貫性がなかった
2. 一貫性チェックの遅れ: テストファイルの命名や構造の不統一を後から指摘した

## 今後改善できそうな振る舞い

1. 役割の明確化: 各フェーズで「提案のみ」か「実装も行う」かを最初に確認
2. 一貫性チェックの早期化: 実装時に命名や構造の一貫性を同時に確認

全体的には、提案と実装の両面で支援できました。役割の境界と一貫性チェックのタイミングを改善すると、さらに効果的になります。

提示された弱点と今後改善できそうな振る舞いを元にプロンプトを改善すると、より優秀なAIナビゲーターになってくれそうです。