曖昧さを質問に変える仕組みは、コードの外には敷かれていなかった

株式会社エクスプラザでAIアプリケーションエンジニアを務めるウンス氏は、自社のAI Workflow SaaS「Palma」の開発チームにinterview-dev-loopというスキルを組み込んだ経緯を公開している(出典)。導入前は、AIに何をどこまで調べさせるかをエンジニアごとに判断していて、同じタスクでも品質と速度にばらつきが出ていた。導入後、直近2ヶ月分のPRについて初回のCodexレビュー結果を集計すると、変更行数あたりの重大指摘スコアは72.3%減り、変更行数自体は4.6倍に増えていた。指摘が減ったのに変更量は増えている。

interview-dev-loopがやっているのは、実装に入る前にエージェントへ調査させ、疑問点を人間に質問し、計画を承認させてから実装に進める、という手順の自動化だ。ただし質問の対象は絞られている。ウンス氏は当初「曖昧な点は全部質問して」と指示していたが、これではエージェントの挙動がばらついた。そこで質問対象を、実装方向、検証、ロールアウト、データ処理、権限、UXのいずれかが変わりうる曖昧さに限定した。この基準に当てはまらない曖昧さは、エージェントが自分で判断して進む。結果として人間がやることは、質問に答える、計画を承認する、動作確認する、の3つだけになった。

役割分担で済む、と思いかけた

PRレビューツールParryを開発している立場から読むと、きれいな補完関係に見える。interview-dev-loopは実装より前の曖昧さを扱い、Parryの四軸(Why/Risk/Confidence/Context)は実装が終わったあとの曖昧さを扱う。前者が「書く前に聞くべきこと」を閉じた集合にして質問へ変え、後者が「書いたあとに確かめるべきこと」を閉じた集合にしてPRへ載せる。場所が違うだけで、発想は同じだ。ループの前半と後半にそれぞれ関所を置けば、ループ全体が人間の理解の中に収まる。そう考えたくなる。

だが、この記事の題材を選ぶ作業そのものが、その考えを一度崩した。

自分たちの選定作業で、集合の外にある見落としを拾った

今回、1週間分の記事の題材をAnswer Surfingの候補一覧から選ぶ際、「Cherny型エージェント分業環境の構築体験記事」という項目を候補に含めていた。この項目には、候補一覧の備考として「未検証(自己体験なので検証不要)」という自己申告が付いていた。しかし実際には、その分業環境はまだ構築されていない。自己体験として書けるはずの出来事が、まだ起きていなかった。

これはinterview-dev-loopの言う曖昧さの分類でいえば、検証に属する曖昧さだ。ウンス氏が実装方向、検証、ロールアウトなどに絞って質問対象を定義したのと同じ意味で、「この体験は実際に起きたのか」は質問すべき対象になる。ただし、コードの実装にはそれを拾う質問フェーズが敷かれているのに対して、記事の題材を選ぶ作業には敷かれていなかった。候補一覧の自己申告をそのまま信じて進みかけ、途中で気づいたユーザー本人の指摘によってようやく止まった。

曖昧さを拾う仕組みは、場所ではなく設計の有無で決まる

ここから言えるのは、PR前後の役割分担そのものではない。interview-dev-loopとParryの四軸が機能しているのは、どちらも曖昧さの種類をあらかじめ閉じた集合として定義し、それ以外は人間に聞かないと決めているからだ。実装方向、検証、ロールアウト、データ処理、権限、UXという6つの分類は、その集合の実例の一つにすぎない。ループの前半に置くか後半に置くかという配置の問題ではなく、対象となる作業のどこかに、この集合を定義した質問フェーズが実際に敷かれているかどうかが分かれ目になる。コードの実装にはそれがあった。記事の題材を選ぶ作業にはなかった。だから見落としが素通りした。

ウンス氏自身も、この先の課題として「人間が判断すべきところと、毎回止めなくていいところをきちんと考える」ことを挙げ、Notion、Slack、GitHubを定期的に監視する自律運用への拡張を検討中だと書いている。コードの外側にある監視対象にまで質問フェーズを広げようとすれば、実装方向やロールアウトといった今の6分類では足りない場面が出てくるはずだ。今回の見落としがまさにその一例だが、コードの外側にある曖昧さをどう分類し直せば同じ仕組みが機能するのかは、まだ答えが出ていない。