AI ペアプロ作法 ── 人とAIの協働── 役割分担、生成と評価の分離、検証責任

01ペアプログラミングとは何だったのか

まず、人どうしのペアプログラミングを正確に振り返ります。1990 年代の XP（＝エクストリーム・プログラミング、変化に強い開発のやり方）で広まった進め方で、一台の画面を二人で見ながらコードを書きます。片方が手を動かして書く役（＝ドライバー）、もう片方が全体を見て気づきを返す役（＝ナビゲーター）に分かれます。Williams と Kessler が 2002 年にまとめた整理によれば、この形の狙いは「速く打つ」ことではなく、書く側面と見張る側面を分け、間違いを早く見つけることにありました。

大事なのは、二人が同じ作業を二重にやっているわけではない、という点です。役割が違います。ドライバーは目の前の一行に集中し、ナビゲーターは「この設計で本当によいか」「見落としはないか」を一段引いて見ます。近い視点と遠い視点を同時に持てるから、一人で書くより欠陥が早く表に出る。ペアプロの本質は、この視点の分業にあります。

この整理は、そのまま人と AI の関係に置き換えられます。AI は速く手を動かせる書き手です。では人は、どの役を引き受けるべきか。答えを先に言えば、人はナビゲーターに回ります。今回は、その役割の中身を具体化していきます。

02AI との役割分担 ── 誰がドライバーか

人と AI がペアを組むとき、まず決めるのは役割です。素朴に考えれば「AI が速いのだから AI に任せ、人は確認するだけ」で済みそうに見えます。けれど実際の現場では、状況しだいで握るべき役が入れ替わります。次の三つの型に整理しました。

三つに共通する原則は一つです。手を動かす役は移っても、最終的に判断する役は人が手放さない。AI をドライバーに置く型でも、ナビゲーターの席 ── 何が正しいかを決める席 ── は常に人が占めます。速度のために役割を渡すのはよい。けれど責任まで渡してはいけません。次章から、この「渡してよいもの」と「渡してはいけないもの」を切り分けます。

03生成 ≠ 評価 ── 書き手と審査役を分ける

ここが今回の芯です。生成（＝コードや文章を作る）と、評価（＝それが正しいか判定する）は、別の作業です。そして、この二つを同じ主体にまとめてはいけません。人どうしのレビューでも「書いた本人が自分のコードを承認する」のは避けます。書き手には、自分の作ったものを甘く見る偏りがあるからです。

AI では、この偏りが別の形で表れます。AI は「正しさ」ではなく「もっともらしさ」を最適化して出力します。読みやすく、それらしく、一見動きそうなコードを作る ── だからこそ、間違いが目立ちにくい。さらに厄介なのは、同じ AI に「このコードは正しいか」と尋ねると、自分の出力を肯定しがちだという点です。生成した本人が評価役を兼ねれば、審査は形だけになります。

だから作法はこうです。生成のパスと評価のパスを、別々に立てる。AI に書かせたコードは、別の系 ── 人のレビュー、独立したテスト、あるいは別に用意した検証手順 ── で確かめます。自分の出力を自分で検証させない。これは人のチームでも AI でも変わらない、レビューの一丁目一番地です。

04検証責任は、どこにあるのか

役割を分けても、最後に残る問いがあります。「AI が書いたコードが本番で事故を起こしたとき、責任は誰にあるのか」。ここは曖昧にできません。答えははっきりしています。検証の責任は、コードを世に出した人にあります。AI が書いたから、という理由で責任が薄まることはありません。

この原則は、製薬の資材審査と地続きです。生成 AI が作った販促資材でも、当てる物差しは人が作ったものと同じでした。「誰が作ったか」ではなく「何が書かれているか」で判断される ── コードもまったく同じで、「AI が書いたか人が書いたか」ではなく「そのコードが何をするか」で責任を負うのです。AI 製であることは、免罪符になりません。

05心理的安全性 ── AI に「わからない」と言わせる

ここで、人のチームの話を一つ挟みます。Edmondson が 1999 年に示した心理的安全性（＝間違いや疑問を、罰を恐れずに口に出せるチームの状態）という考え方です。彼女の研究では、報告される間違いの数が多いチームのほうが実際の成績が良い、という一見逆の結果が出ました。理由は単純で、間違いを隠さないチームだけが、間違いを直せるからです。

この考え方は、人と AI のペアにも効きます。人の側が「AI が出したものは正しいはず」と黙って受け入れれば、間違いは表に出ません。逆に、AI の出力へ「ここは怪しい」「根拠を示して」と気軽に疑問を投げられる関係を、人と道具のあいだにも作る。具体的には、AI に断定させず、不確かさを言わせる使い方をします。「この数値の出典は」「自信がない箇所はどこか」と問い、AI が「確証がない」と返せる余地を残す。

心理的安全性は、人どうしの空気の話に見えて、実は間違いを早く表に出す仕組みです。AI とのペアでも同じで、人が AI の出力を疑ってよい ── むしろ疑うのが仕事だ ── という前提をチームの作法として明文化しておくと、もっともらしい間違いが黙って通る確率は下がります。

06チームの作法 ── 四つの約束

ここまでの話を、日々回せる約束の形にまとめます。人と AI がペアを組むチームで、あらかじめ決めておくとよい四つです。どれも地味ですが、事故の多くはここを飛ばしたときに起きます。

四つに通底するのは、速度は道具に、判断は人にという分担です。単純な作業や下書きは AI に任せて速く回し、正しさ・安全性・規制適合の判断は人が握って離さない。人どうしのペアプロが「視点の分業」で欠陥を早く見つけたように、人と AI のペアも役割を分けることで、速さと確かさを同時に取りにいきます。

07まとめ ── 速さを、信頼を守るために使う

今回の要点を、もう一度たどります。ペアプログラミングの本質は、速く打つことではなく、書く視点と見張る視点を分けて間違いを早く見つけることでした。人と AI のペアでは、AI が速い書き手を務め、人が見張り役 ── ナビゲーター ── に回ります。手を動かす役は局面で渡し合ってよい。けれど何が正しいかを決める役は、人が手放さない。

三つの柱を置きました。第一に、生成と評価を分ける。もっともらしさを最適化する AI に自己採点させず、別の系で確かめる。第二に、検証責任は人にある。「AI が書いた」は免罪符にならず、「そのコードが何をするか」で責任を負う。第三に、心理的安全性 ── AI の出力を疑ってよいという前提を、チームの作法として明文化する。速く作れる力は、崩れやすい信頼を守るために使う。これが、人と AI の協働の芯です。

AI は、コードを速く・大量に書けるようにしました。大きな機会です。けれど同じ速度が、もっともらしい間違いを新しい規模で運んできます。速度を落として安全を買うのでも、安全を捨てて速度を取るのでもない。役割を分け、生成と評価を切り離し、検証責任を人に据える ── この三つで、速さと確かさは両立します。製薬の周辺でコードを書くなら、なおさらです。実行が成功したことと、中身が規制に適合していることは、別に確かめる。AI をペアの相棒として使いこなす鍵は、相棒に何を任せ、何を任せないかを、あらかじめ言葉にしておくことにあります。