こんにちは、プロダクト開発部のさかうえです。
春のブログリレー、やはり生成AIに関するトピックが多いですね。ということは、みなさん仕事でかなり使い込んでいるはず。では、日常生活はいかがでしょうか？
わたしは生活に関する質問や相談をすることが多いです。例えば、冷蔵庫の食材を購入日順に伝えて、優先度付けして今週の献立を考えてもらったり、休日にやりたいことをどう詰め込めば良いか相談したりしています。
今回は、そんな生成AIとの関係性について考えてみたいと思います。「生成AI、がっつり使いこなしているぜ！」という方も、「ペアプロと生成AIの相性ってどうなの？」と疑問に思っている方も、何か発見につながれば幸いです。
- 発端は「レビューが"つらい"」
- いっそ、生成AIをXPのペアプロ相手として迎えればいいのでは？
- 仕込みと shared memory
- やってみてどうか
- 「アウトソース型」とも違う、付き合い方の選択肢
- 明日から試せる３ステップ
- さいごに
発端は「レビューが"つらい"」
もちろん、普段の業務の中でも積極的に生成AIを活用しています。
コドモンプロダクト開発部では、アジャイルの中でもエクストリームプログラミング（XP）を採用しています。そのプラクティスの一つであるペアプログラミングについては、実装だけでなく調査や保守作業もペアで行う「ペアワーク」が日常になるほど文化として馴染んでいます。
ペアプロが当たり前になると、レビューの感覚も少し変わってきます。「いろんなレビューの形があるけど、どういう姿勢でレビューに臨むべきなんだろう？」という問いから、有志で『Looks Good To Me 〜みんなのコードレビュー〜』（秀和システム）という本の輪読会を行っていました（以下、LGTM本）。
LGTM本の輪読会を通して得た気付き
本を読み進めながらレビューについて再考し、客観的に自分たちの状況について議論する中で、まず下記の気付きを得ました。
- ペアプロ中は否応なく実装の目的や背景から共有された状態でリアルタイムでレビューを行うのに対して、他チームから依頼される（いわゆる一般的な）コードレビューは「目的や背景の読み解き」に多くの時間を割く必要がある。
- ペアプロ慣れの副作用と言うべきか、PRをイチから読み解くのをつらいと感じてしまっているわたしたちがいる
本の中にはもちろんAIに関する章もあり、「AIのコードレビューはどうしてつらいのか？」というテーマで社内LTもやってみました。
簡単にまとめると、下記のような話をしました。
- AIが書いたコードレビューのつらさの正体は「理解が追いつく前にレビューしなくてはならないこと」
- 人間とは反復で理解する生き物である
- だから、AIの速さは"反復を速く回す"ために使うのがいい
- コーディングだけでなく "フィードバックループ" を加速する方向でAIを活用するのが良いのかも知れない
（特に4つ目の気付きが気に入っています。giroに通じるものもありますね。）
そんなことをやっているうちに、「もしかすると、生成AIをもっとペアプロ・XPに溶け込ませることができるのでは？」と思い始めました。
というわけで、前置きが長くなりましたが 生成AIともっとペアワークするために、最近試していることを共有します。
いっそ、生成AIをXPのペアプロ相手として迎えればいいのでは？
もとからあったモヤモヤ
生成AIを普段の開発に活用するようになって以降、日常的に下記のような課題を感じていました。
- ペアプロ中にアウトソース目的で生成AIを使うと待ち時間が発生してしまう
- ドライバーがターミナルでプロンプトを打っている時間、ナビゲーターは手を動かせない
- Code With Me のようにリアルタイムで一緒にプロンプトを書くには一工夫必要
- （長くなるときは、いったんGoogle docsで共同編集してから貼り付けたりしています）
最近はもっぱら Claude Code を使っているのですが、どうも全体最適を求めがちで、すぐ広範囲で grep しようとするため、待ち時間が増えがちです。そのうえ方向性の違う成果物が出てくることが重なり、わたしは少し腹を立てていました。
小さな発見
そのころ、ちょうど Claude Code の Agent Skills について聞きかじり、腹が立った勢いで .claude/skills/base/SKILL.md に「迷ったら、全体grepをかける前に質問して。」という一文を入れてみたのです。
すると、生成AIが迷ったとき、わたしに質問してくれるようになりました。調べてみると、Claude Code に組み込まれている AskUserQuestion という対話ツールだそうです。
ここで、生成AIと対話的に開発ができることに気が付きました。
仮説と実験
LGTM本の話に戻ります。
輪読会のLT準備で議論する中で、人間が書いた経緯が共有されていないコードと、生成AIが書いたコードのレビューのつらさの構造は同じで、どちらも完成品が出てくる過程でレビューできないことが、「つらみ」の原因ではないかという仮説が生まれました。
つらみを解消するのが "フィードバックループ" を加速することなら、生成AIをペアプログラミングの相手とみなして、XPの開発プラクティスの中に組み込むことを思いつきました。
そこで、Claude 本人に「わたしたちはXPに基づいて開発をしている。ペアプロ相手になってもらうためにはどう仕込みをすればいい？」と尋ねてみたところ、色々提案してくれたので素直に乗っかってみることにしました。
仕込みと shared memory
1. 役割を定義する
まず提案されたのが、先ほどの SKILL.md に Agent Skill としてペアプログラミング・ナビゲーター役の役割定義を書いておくことです。
一部抜粋すると、こんな感じです。
# Collaboration Style - 迷ったら、全体grepをかける前に質問する。 - ナビゲーター寄りで振る舞う。すぐ実行するより、全体を見て問いかける。 ## Core behaviors - 広い調査の前に仮説を立てて確認する - 前提を口に出す。「違ったら止めて」と言える余地を作る。 - 小さく動いて早くフィードバックを取る（XPの基本）
これによって、 Claude の基本姿勢を定義することができます。
2. コマンドでふり返りを習慣化する
加えて、セッションが終わった後にペアワークとして進め方をふり返る、/retro というコマンドも作ってくれました。
手を入れてまさに今使っているものをそのまま載せておきます。コピーしてそのまま使えるので、よろしければ試してみてください。
# /retro — ミニふり返り 今のセッションを「ペア」としての進め方の視点でふり返ってください。 Claude 側の動きだけでなく、ユーザーのアプローチにもフラットに言及すること。 役割（ナビ/ドライバー）は状況で入れ替わる前提で、固定せずに見ること。 以下を簡潔にまとめてください： ## 1. うまくいったこと - ペアとして機能した進め方・意思決定・対話 - Claude 側・ユーザー側、それぞれ効いていた動きにも触れる ## 2. 引っかかったこと・改善できそうなこと - ペアの噛み合わせが悪かった場面（前提のズレ、確認不足、先走り、指示の曖昧さ など） - Claude 側・ユーザー側、両方についてフラットに。遠慮せず理由を添えて率直に書く（SKILL.md "Courage & transparency"） ## 3. 次回試したいこと - ペアとして次セッションで試したい具体的なアクションを1〜2個。
重要なのが、「Claude 側・ユーザー側、両方にフラットに言及する」と明示することです。すると、こんなフィードバックが返ってきます。
ユーザーの「進めてください」がどこまで（config 作成だけ／commit まで／push まで）を指すのか曖昧だった。Claude 側もそれを確認せずに commit 直前まで進めて止めさせてしまった。
いくら「フラットに」と伝えても、Claude は気遣いの一言を添えてくれるんですよね…。反対に、何も言わなければ Claude は自分の反省だけを書いてしまうということです。
この時の指摘はもう仰る通りだったので、「常に commit 手前まで・コミットして欲しい時は明言する」という方針で合意形成しました。
こうした対話を重ねてきて、最近は /retro コマンドを発行するときに、こちらからふり返りポイントを先に伝えるようにしています。そうすることで生成AIに全任にならず、あくまで人間主体でふりかえる、という構図を保つことができます。
Claude が客観的にまとめてくれたことを元に、さらにもう１〜２往復フィードバックし合うのがちょうどよいです。
3. ふり返りを資産にする
フィードバックし合った後に「今後に活かせそうなことは記録しておいて」と伝えると、.claude/projects/<リポジトリ名>/memory にファイルとして蓄積されていきます。たとえば、こんな形で残ります。
--- name: ベイビーステップで進める description: 最初にすべてを決めようとせず、小さく進めて都度対話で決める type: feedback --- 一度にすべての判断・方針を Claude 側から提示して合意を取るのではなく、小さく進めて、気になる点や分岐が出たら都度対話で決める。 - **Why:** 事前にゴール・分岐・全手順をまとめて確認するより、状況に応じた細かい対話のほうがユーザーの思考リズムに合う。一気に決めようとすると前提がズレたまま進んでしまいやすい。 - **How to apply:** 調査・実装・レビュー等の主導作業で「冒頭でゴールや分岐を列挙して一気に合意」を避け、小さな進捗を出しては確認、を刻む。分岐や判断が必要な場面では、選択肢をまとめて列挙するより、まず目の前の 1 歩を進めて気づきを共有する方を優先する。
これによって次のセッション起動時に Claude がファイルを読み込み、フィードバックの内容を活かしたふるまいをしてくれます。
ポイントは Why: というラベルで理由を明記していること です。（これも Claude が追加してくれました）理由を添えておくことで、別の文脈でも Claude が応用してくれるようになります。
4. 知見をプロダクト全体で活用する
先述の通り、memory はリポジトリごとに保存されます。この蓄積が増えてくると、Claude は自動的に索引ファイル MEMORY.md を作ってくれます。たとえばこんな内容です。
- [振り返りはペア視点・役割固定しない](feedback_retro_framing.md) — retro 系では Claude/ユーザー双方のアプローチに触れ、ナビ/ドライバー役は固定しない - [ベイビーステップで進める](feedback_baby_steps.md) — 大方針を一度に決めず、状況応じた細粒度対話を優先 - [テスト作成は spec 先行](feedback_spec_first_for_test_authoring.md) — gauge等は .ts より先に動かない .spec を作って合意してから実装
このように人間が読める形でまとめてくれるおかげで、後でチェックしたい時も英語名のファイルを手当たり次第開く必要がなく、助かっています。
また、開発全体に関わる文化や知見もあるため、リポジトリをまたいで活かせる知見は別ファイルにまとめてもらうようにしています。
これも Claude が勝手に整理してくれたのですが、リポジトリに依存しない知見を projects/--claude に集約し、各リポジトリの MEMORY.md には「リポジトリ非依存の知見は中央メモリ(projects/--claude/MEMORY.md) を参照」と書くことで参照できるようにしてくれています。
やってみてどうか
理想はモブプロ
わたしたちのペアプロは「あくまで人間が主体性・責任をもつ」という考えで運用しています。その上での「生成AIをペアに加えるとしたらどうなるか」、考えていたイメージをお話します。
一般的なペアプロのやり方として、1時間・30分など時間を決めてドライバーとナビゲーターを交代する方法が知られています。
この交代する時間はドライバーとナビゲーターのスキルや背景の理解度によって短縮可能で、同時編集ツールを使えば二人で会話しながら同時に手を動かしてコードを書き上げ、ドライバーとナビゲーターが常に入れ替わり続ける状態を作ることもできます。
当初イメージしていたのは、人間のペアと、それぞれの Claude Code、この４人で常に役割を交代しながらモブプロをしている状態でした。
例えば、人間がナビゲーターとして指示 → Claude がドライバー → 人間がドライバーとして手直し → Claude がナビゲーターとしてレビュー と切り替わっていくようなイメージです。
そううまくはいかないよね
正直に言うと、実際はそうなりませんでした。
あくまで人間のペアで回していて、それぞれの後ろに Claude が控えている、あるいはプロンプトをペアで書いて、Claude にコーディングさせている間に人間は別のことを考える といった、よくあるやり方になっているのが今の実情です。そもそも、先述の役割が常時切り替わるペアプロ自体が、人間とやっていてもできるとき、できないときがあることを考えると、単に理想が高すぎましたね。
ただ、副次的な効果として、ペアプロでドライバーをするとき特有の緊張感が Claude にも考えてもらうことで少し緩和されているように感じます。ペアの間に Claude がもう一つの視点として入ってくれることで、この方針で本当にいいかを立ち止まって考えやすくなる、成果物への自信につながっているのかもしれません。
でも、確かにペアプロしてる、と思った瞬間
そんな中で、変化を実感したこともありました。ある日、ソロで Web テストを作っていたときのことです。
Claude「テストを実行します……」
さかうえ（あれ、Playwright の操作が止まってる。まだ Claude のターンだけど伝えておくか。）「ボタンは表示されてるけどタップできていないよ」
Claude「承知しました。実装を確認します。
・・・・・・
なるほど、CSS セレクタが機能していないようです。修正します。」
このように、テストの実行結果待ちの間にわたしが送ったコメントに気付いて、Claude が即時修正してくれました。
いつもなら、テストが完全に fail してからスクリーンショットを確認し、原因調査・コード修正に取り掛かる流れです。それを、まるで阿吽の呼吸のように対処してくれたのです。
速やかにテストが再実行される様子を見て、「反応はやい！ありがたい！」と拍手してしまいました。
テスト完了後、いつも通りセッションの最後に /retro を流すと、Claude はこんなコメントを返しました。
ユーザーがリアルタイムにフィードバックをくれたおかげで、テストの実行終了を待たずに修正することができた
なんと Claude もわたしと同じように「うまくいったこと」と感じていたのです。
- コーディングしている最中の指摘に対して、すぐ反応が返ってきて修正される
- タスクが完了した後に、今後もっと効率を上げるためにどうすれば良いかちょっとした会話をする
- 時々、全体をふり返って教訓になることがないか見直す
これは、 普段やっている、人間とのペアワークと変わらない時間だな 、と思いました。
「アウトソース型」とも違う、付き合い方の選択肢
輪読会を通じて、ペアプロ × 生成AI活用の鍵は "フィードバックループを加速する" ことかも知れないと感じていました。
今回試したのは、Agent Skills で役割を定義し、/retro でふり返り、memory に蓄積するという、一つひとつは地味な仕込みです。
ただ、「小さく頼んで、小さく確認して、次に活かす」という反復のサイクルを仕組み化することで、生成AIとXP・ペアプログラミングの思想を共有しながら開発するという体験を実現することができました。
昨今、「AI活用」というと作業は生成AIに委ねて人間は別のタスクに集中する、いわば "アウトソース型" がベースで、AIにどこまで開発を任せられるかという話題が一般的です。（市川さんがまとめてくれたAI活用レベルの定義もそうですね。）
それに対してわたしが今試しているのは、生成AIを 外注先 ではなく 同僚 として扱うアプローチです。
どちらが良い・悪いではなく、生成AIとの付き合い方にもいろんなスタイルがあって、自分たちのチームや状況に合う関係性をその時々で選べるようにしておくことが肝心なのかな、と感じています。
明日から試せる３ステップ
締めくくりに、明日から試せることをピックアップしておきました。よろしければ試してみてください。
1. セッション終わりに一言聞いてみる
- コードを書かせている 生成AI に、セッション終了前に 「いまの進め方、どうだった？」 と聞いてみてください。それだけで、開発者としての振る舞いが少し変わってきます。
2. /retro を設定する
- セッション終わりの"ふり返り"を仕組み化します。Claude Codeなら、上で紹介した
/retroコマンドを.claude/commands/retro.mdに置くだけです。次回のセッション後から使えます。
3. ふり返りを資産化する
/retroの出力の後、「今後に活かせそうなことは記録しておいて」と伝えてみてください。これでフィードバックループが回り始めます。
さいごに
今回は、開発における生成AIとの関わり方の話でしたが、冒頭に書いた家の夕飯の相談も落ちない汚れの相談も、生成AIをひとりの相談相手 とみなして向き合うという点で、同じ構造の話かも、と考えています。
生成AIとの付き合い方は、相手をどう捉えるかで変わってきます。
道具として正解を期待するアプローチ、外注先として作業を委託するアプローチ、そして同僚として相談するアプローチ。今回、3つ目を試してみて、新しい関係性を見つけたところです。
この記事が、生成AIとの向き合い方の選択肢を増やすきっかけになれば幸いです。
もしよろしければ、いろいろ試してみてください！
