はじめに

こんにちは、エンジニアの鎌手です。近年、ClaudeやGeminiといったAIツールの台頭により、私たちの開発風景は大きく変化しました。今や「エンジニア1人がAIと対話しながら実装を進めるスタイル」が主流であり、私自身の日々の開発もまさにその形がベースとなっています。

ですが、私たちはより良い開発スタイルを模索する中で、ある仮説にたどり着きました。それが、「人間2人＋AI 1台」による3人体制のペアプログラミング（あるいはミニモブプログラミング）です。

従来のペアプログラミングは、片方が手を動かしている関係上、どうしてもコードベース（実装レベル）の会話が多くなりがちでした。しかし、タイピングや基礎実装をAIに任せてしまえる今なら、人間がもう1人加わることで、よりプロダクトのバリュー改善に繋がる本質的な議論ができるのではないかと考えたのです。そこで今回、同じくエンジニアの山崎さんとともに、この新体制がどこまで機能するのかを実際の開発ハンズオン（ミーティング）を通じて検証してみました。

本記事では、私たちが「人間2人＋AI 1台」で実施したセッションの具体的な様子と、トラブルから見えてきた問題点や知見についてお届けします。

3人体制での効果的な役割分担：AIを「3人目のメンバー」に

このペアプログラミングを形骸化させず、検証を効果的に回すために、私たちはまず役割を以下のように明確に分担しました。AIを単なるツールではなく、チームの「最速の実装者」として位置付けるアプローチです。

実践！開発セッションの記録と検証

この3人体制の有用性を確かめるため、私たちは実際に目的の異なる2つのテーマでハンズオンを実施しました。それぞれのセッションにおいて、3人体制がどのように機能したのか、具体的なプロセスと発生したトラブルを解説します。

【検証 01】Google Apps Script (GAS) による自己紹介ページの作成

体制：ナビゲーター：山崎 / ドライバー：鎌手

最初のセッションでは、Google Apps Script (GAS) 環境を用いた開発を行いました。モデルには、社内アカウントで安全にデータを扱える「Gemini Pro」を選択。ブラウザの対話型UIから使用します。事前にSlackで共有していた要件定義を渡し、さらにGoogleドライブ上のサンプルファイルを置いたディレクトリURLをGeminiに直接共有して、コード生成とファイル読み込みの自動化を試みました。

【AIのイージーミスと、対話型AIの問題点】
指示通りに生成されたコードを貼り付けてデプロイしたところ、ブラウザを叩いても画面が正常に遷移せず、コンソールには「スクリプト関数が見つかりません」というGASでお馴染みのエラーが吐き出されました。AIに指示を出して修正し、再デプロイを繰り返すものの、今度はブラウザ側でメンバー一覧が「読み込み中...」のまま停止するというエラーが発生しました。

図1：メンバー一覧が「読み込み中...」のまま停止したエラー画面

図2：デバッグを繰り返し、正常に自己紹介スライドが連携された画面

画面が動かない原因を探るべく、私たちはつい画面を共有しながら「ここが怪しいかも」「これが原因じゃない？」と言葉を交わし、2人でコードを凝視してデバッグを始めてしまいました。——実はこれこそが、AI時代のペアプロにおいて陥りがちな「やってはいけないアンチパターン」でした。原因は、Geminiが文字列を囲む記号（バッククォート等）の処理を誤っており、GAS側が関数を正常に認識できていないという、極めて単純な構文上のイージーミスでした。

本来、こうしたコードレベルのエラーは人間が血眼になって探す必要はありません。エラーログや発生したエラーの内容をそのままチャットに投げ直せば、AIが数秒で自己修正してくれる領域です。それなのに、なぜ私たちは自分たちの目でデバッグしてしまったのでしょうか。━━━人間が2人いると、トラブルが起きた際に「お互いに状況を認識共有しよう」と言葉を交わすうち、つい親切心や知的好奇心から、自分たちの手で原因を探って解決したくなってしまう心理的な流れがあることに気づきました。

対話型のAIツールはレスポンスが非常に早いものの、出力されたコードをエディタへ反映したり、コピペの際に微修正したりといった「手動での操作」を人間に要求します。そのため、トラブルが起きるとどうしても人間がコードに直接触れる時間ができてしまい、結果としてAIに任せるべき領域に手を出したくなり、本来担当すべき「2人で仕様や改善について議論する」時間が奪われてしまう構造になっていたのです。この経験から、私たちは「一問一答の対話型AIは、そもそもAIペアプロには向かないのではないか」という知見を得ました。

【検証 02】ラーメン記録アプリケーションの開発

体制：ナビゲーター：鎌手 / ドライバー：山崎

2つ目のセッションでは、高速なパッケージマネージャー「uv」を利用したPythonとStreamlitの環境を用いて、ラーメン記録アプリケーションの開発に挑戦しました。今度の使用ツールは「Claude Code」、モデルには「Claude 4.7 Opus」を選択。さらに、あらかじめテストコードを書いてから実装を進める「テスト駆動開発（TDD）」のアプローチを指示に組み込みました。

実装目標は、店舗名や評価、ラーメン画像をアップロードし、JSONデータとしてローカルに保存、かつ登録後に画面全体のリロードなし（非同期）で一覧UIが即時更新されるという、Streamlitにおいてやや複雑な状態管理を伴う機能です。

図3：写真アップロードや評価スライダーが並ぶ洗練された登録画面

図4：登録後、画面全体のリロードを挟まずに即時更新されたラーメン一覧画面

【3人体制が活きたポイント：UXの追求と、リアルタイムの仕様追加】
AIが「最速の実装者」として複雑なセッションステートの記述やロジック構築を引き受けてくれるため、1人での開発なら「他の作業やチャット通知に意識を持っていかれる待ち時間」を、2人で「次どうやってユーザー体験（UX）を良くするか」を会話する時間へと転換できました。

その結果、従来のペアプロのようにコードの書き方に脳のメモリを引っ張られず、「種類を『とんこつ』とひらがなで入力しても適切に分類できるようにしよう」「登録完了時には画面にトースト（通知）を出して安心感を出すのはどうか」「ここの挙動ちょっと違和感ない？」といった、プロダクトのバリューに直結するアイデアの議論が溢れ出てきました。実装をAIに任せている間に「次の一手」の議論に集中できる。これこそが、この3人体制がもたらす一つの大きな魅力だと実感しました。

作業を見て盗む、プロンプト効率化とコストのリアル

今回のペアプログラミングセッション中、上記のような知見や指示の出し方だけでなく・・・・

…

記事の続きは下のURLをクリック！

https://rightcode.co.jp/blogs/55750

もっとワクワクしたいあなたへ

現在、ライトコードでは「WEBエンジニア」「モバイルエンジニア」「データエンジニア」「ゲームエンジニア」「デザイナー」「WEBディレクター」「営業」などを積極採用中です！

ライトコードは技術力に定評のある受託開発をメインにしているIT企業です。

有名WEBサービスやアプリの受託開発などの企画、開発案件が目白押しの状況です。

• もっと大きなことに挑戦したい！
• エンジニアとしてもっと成長したい！
• モダンな技術に触れたい！

現状に満足していない方は、まずは、エンジニアとしても第一線を走り続ける弊社代表と気軽にお話してみませんか？

ネット上では、ちょっとユルそうな会社に感じると思いますが（笑）、
実は技術力に定評があり、沢山の実績を残している会社ということをお伝えしたいと思っております。

• ライトコードの魅力を知っていただきたい！
• 社風や文化なども知っていただきたい！
• 技術に対して熱意のある方に入社していただきたい！

一度、【Wantedly内の弊社ページ】をのぞいてみてください。

Wantedly：https://www.wantedly.com/companies/rightcode