AIとの共同作業の起点は、完璧な指示ではなく最初の成果物である

Snapshot

AIとの共同作業は、完璧な指示を探すところから始まらない

たとえばAIに記事を書かせるとする。書き始める前に、読者、主張、構成、文体、分量をすべて決められれば話は早い。しかし実際には、最初の原稿を見てから「専門家向けすぎる」「結論を先に出したい」「この例は残したい」と気づくことが多い。画面設計やソフトウェア開発でも同じで、形になったものを見ることで、依頼者自身の希望が具体的になる。

ここで批判する「ポン出し」は、短い依頼文を使うことではない。条件が足りないまま一度だけAIに作らせ、返ってきた内容を確かめず、修正もせずに完成品として使う進め方である。代わりに勧めたいのは、完成品より小さな試作品を作り、それを見て、残す点と直す点を伝え、もう一度作る方法だ。

The Problem

目的を先に言い切ること自体が、難しい仕事がある

目的が明確な仕事とは、完成の判定方法まで決まっている仕事だ。たとえば「この表を指定の列順でCSVに変換する」なら、出力形式と照合すればよい。一方、「この企画を経営会議で通る資料にする」では、数字を重視するのか、リスクを先に示すのか、説明をどこまで短くするのかが最初から決まっているとは限らない。案を見た人の反応によって、完成条件そのものが具体化していく。

では、AIに質問させれば目的を明確にできるのか。研究を見る限り、それも自動的にはうまくいかない。Google DeepMindのQuestBenchは、問題を解くために必要な情報を一つだけ隠し、AIに「どの質問をすれば不足情報を得られるか」を選ばせる試験である。計算問題では高得点のモデルでも、論理問題と計画問題で正しい質問を選べた割合は40〜50%だった。答えを出す力と、答える前に何を確認すべきかを見抜く力は別だという結果である。

AmbiEntという別の研究でも、複数の意味に読める文をGPT-4が正しく整理できた割合は32%だった。つまり「曖昧ならAIが適切に聞き返してくれる」とは限らない。人間が目的を完全に説明できず、AIも最適な質問を必ず選べないなら、質問だけで目的を確定する方法には無理がある。

First Artifact

最初の成果物は、完成品ではなく判断材料にする

最初から記事全文を作る必要はない。見出しと冒頭の二段落だけでも、話の順番や難しさを判断できる。ソフトウェアなら全機能ではなく、典型的な入力を一つ処理するコードとテストを作る。デザインなら、色だけを変えた案ではなく、情報量や配置の考え方が異なる二案を出す。重要なのは、小さくても「近い」「違う」を判断できることだ。

AI Chainsの研究では、20人の参加者が、AIの仕事を複数の小さな処理に分けて中間結果を確認した。たとえば最終文だけを見るのではなく、材料の抽出、分類、文章化を別々に見る。参加者は複数の進め方を比較し、結果がおかしいときは、どの段階からずれたかを調べられた。研究では、この方法が最終成果の品質に加え、処理の見通しや自分で修正できる感覚も高めた。

PromptChainerの事例研究も、複雑な処理では途中の結果を見て、問題のある段階だけを直せる仕組みが必要だと報告している。これは大規模な性能試験ではないが、「長い指示を一度で成功させる」より「途中を見えるようにして直す」という設計の具体例になる。

画像生成でも似た結果がある。Google DeepMindの研究では、AIが理解した人物、物、関係などを編集可能な図として見せ、確認質問と一緒に修正できるようにした。

参加者の少なくとも90%がAIとその図を役立つと評価し、完成画像が依頼内容をどれだけ満たすかを測るVQAScoreも、一度だけ生成する方法より高かった。AIの解釈を見える形にすると、人間は誤解を完成後ではなく途中で直せる。

The Loop

対話の中心は、質問の往復ではなく成果物の往復である

役立つ対話は、AIが「本当の目的は何ですか」と繰り返す会話ではない。AIが仮の成果物を出し、人間がそれを見て、「導入は残す」「研究名の羅列は減らす」「読者が実行できる例を足す」のように差を具体化し、AIが次の版へ反映する会話である。人間は最初から正解を説明する必要がない。目の前の案に対して選択できればよい。

What Improves

対話で改善しやすいのは「希望に合うか」であり「事実か」ではない

「精度が上がる」という表現は、二つに分けた方が分かりやすい。一つは、文章の難しさ、構成、機能、見た目などが依頼者の希望に合うかという精度である。もう一つは、数字が正しいか、引用が原文と一致するか、コードに危険な動作がないかという正確性である。対話で前者は改善できるが、後者には資料確認やテストが必要だ。

コード生成のClarifyGPTは、曖昧な要件を確認してからコードを作ると、GPT-4のPass@1が改善したと報告した。Pass@1とは、最初に生成した一つのコードがテストに合格する割合である。TiCoderでは、15人のプログラマーが期待動作をテストとして示す方法を試し、生成コードが意図に合うかを判断しやすくなり、作業中の負担も軽くなった。

文章編集のR3は、人間がAIの修正案を採用したか却下したかを記録し、次の提案に反映する。たとえば、短くした文を人間が元に戻したなら、次の段落では同じ削り方を避ける。Self-Refineは、人間ではなくAI自身が出力を批評して直す方法だが、それでも一度だけ生成する方法を複数の課題で上回った。共通しているのは、最初の出力を最終回答にせず、評価結果を次の版へ渡している点である。

ただし、これらの研究は「AIと長く話せば、どんな内容も正しくなる」と証明したものではない。テストで正誤を判定できるコードや、比較評価できる文章・画像で、修正の効果を測った研究である。対話は希望を成果物へ伝える手段、検証は誤りを見つける手段、と役割を分ける必要がある。

Not Endless Chat

短い修正を勧めることは、会話を長く続けることではない

複数回の対話が役立つのは、毎回の指摘が具体的で、良くなったかを判定できる場合である。MINTという評価研究では、AIが道具の実行結果や文章による指摘を受け取ると成績が改善した。一方で、一度の回答が強いモデルが、複数回の対話でも強いとは限らなかった。会話回数ではなく、返す情報の質と判定方法が重要だと分かる。

長い会話には明確な失敗例もある。Microsoft Researchは、六種類の文章生成課題について20万件以上の模擬会話を調べ、複数回に分けて条件を伝えた場合の成績が、一度に条件を伝えた場合より平均39%低かったと報告した。AIは会話の早い段階で不足情報を推測し、完成版を急いで作り、その誤った前提を後の会話でも捨てにくかった。

DELEGATE-52は、長い文書をAIに何度も編集させる課題を調べた。指定した箇所を直している間に、離れた箇所の内容が気づかれないまま変わるなど、文書が静かに壊れる問題が確認された。文書が長く、操作回数が多いほど悪化した。会話が続いていること自体を、改善の証拠にしてはいけない。

実務では、一回の変更範囲を小さくし、いつでも前の版に戻せるようにする。数回ごとに現在の条件を短く書き直し、記事なら原資料、コードならテスト、デザインなら選んだ基準と照合する。「三回直して改善しなければ方針を見直す」のような終了条件も置く。Anthropicの公式解説も、処理の分割、途中確認、評価と修正、実行環境から得た事実、人間の確認地点、最大反復回数を組み合わせる方法を示している。

Scenarios

この方法が効くのは、途中の案を見て良し悪しを判断できる仕事である

反対に、入力と正解が決まっている仕事では、対話を増やさなくてよい。指定形式への変換、決まった項目の抽出、定型要約、十分な自動テストがある小さな修正などである。Anthropicも、単純な一回の処理で足りるなら、複雑な仕組みを加えない方がよいと説明している。

Design Implication

AIを前提にした共同作業とは、うまい指示文より、直し方を工程にすることだ

この流れはPDCAとして整理できる。ただし、最初のPlanは完成した計画ではなく、「非技術者向けの記事にする」といった仮の方針でよい。Doでは見出しと導入を作る。Checkでは人間が読みやすさを判断し、引用や数字を原資料と照合する。Actでは「研究の説明を日常例の後に置く」のように方針を更新し、次の小さなDoへ進む。

研究が「AI版PDCA」という手法を直接証明したわけではない。個別の研究で示された試作、途中確認、修正、検証を、一つの仕事の順序にまとめた考え方である。

人間の役割は、開始前に完全な仕様書を書くことでも、AIの文章を一文字ずつ直し続けることでもない。案を見て、何を残すか、何を変えるか、何を別に確かめるかを決めることだ。AIはその判断を受けて、次の案を作り、現在の条件を整理し、必要ならテスト項目や確認すべき資料の候補を出す。

Microsoftの人間とAIの対話に関する指針も、細かな単位で意見を返せること、誤りを簡単に直せること、AIが不確かなときは扱う範囲を狭めることを勧めている。人間を作業に残すとは、すべてを手作業に戻すことではない。人間が判断できる途中結果と、誤ったときに戻れる修正経路を残すことである。