本当にAIは「何のために何を開発するか」に踏み込めない？ AIは私の根本的な見落としを指摘してきた：及川卓也からエージェント時代の開発者たちへ（11）（2/2 ページ）

前回、「何を作るか、価値の見極めは人間が握っている」と書きました。今回は、自分を実験台にしてその言葉を確かめます。AIのPMツールに、私が実際に作って公開した製品を、ゼロから企画させてみたのです。結果は、想像していたより厳しいものでした。

[及川卓也，Tably株式会社]

　pm-skillsには、作成したPRD（製品要求仕様書）を敵対的に攻撃させる「/red-team-prd」というコマンドがあります。自分で作らせた仕様の弱点を、今度は自分で探させるわけです。その出力の筆頭に、こうありました。

　「セルフチェックという形式自体が、書籍の言う『独立したレビュー』の原則に反している。開発チームが自分の製品を自己申告で診断するのは、書籍が批判している利益相反と同じ構造だ」

　これは、AIが出荷済みのツールの構造的な欠陥を指摘してきたということです。しかもその欠陥は、私自身が原稿に書いておきながら、自分のツールでは見落としていたものでした。丸腰のAIがどうやっても気付けなかったことに、原稿一式を渡しただけで気付いたのです。

　原稿には、設計した本人が自分の設計を審査することの危うさを論じた章があります。航空機の安全認証で、FAA（米連邦航空局）が審査業務の一部をメーカーであるボーイングの社員に委任し、設計した側が自分の設計を審査する構図になっていた事例を引いたものです。AIはその章の該当箇所を行番号付きで引用しながら、「このツールが提供するチェックリストでツール自体を点検すれば、この章に基づく設問の答えはNoになる」とまで指摘してきました。

　productethics.jpは、チームが「自分で」チェックするツールです。私はそれを、倫理を他人に採点される心理的なハードルを下げる、良い設計だと考えていました。しかし、自己点検には自己弁護がついて回るという、まさに私が本の中で書いた構造的な弱点を、このツール自体が抱えていたのです。指摘を読んで、すぐには反論が思い付きませんでした。

　しかし、指摘に従ってセルフチェックという形式をやめようとは思いませんでした。倫理を他人に採点されるツールなど、現場は使ってくれないと容易に想像できるからです。正しいのに、そのままでは直せない。AIに仕事を奪われる、という話は散々読んできましたが、自分の出荷物の欠陥を、自分の書いた原稿を根拠に、逃げ場のない形で指摘されるのは、それとは全く別の感触でした。

安さと、遠慮のなさと、全部読むこと

　なぜAIは、作者の私が見落としていたものに気付けたのでしょうか。

　「AIは私より賢かった」と書けば話は派手になりますが、それは違うと思っています。自己点検には自己弁護がついて回るという原則を、私は自分の原稿に書いておきながら、セルフチェックツールの設計には適用していなかった。あの指摘が痛かったのは、中身が高度だったからではなく、この一点を正確に突かれたからです。指摘の中身そのものは、「セルフチェックのツールは自己レビューの罠（わな）に陥る」という、レビューの世界では定石に近い話です。腕のいい社外のレビュアーなら到達できたはずで、AI固有の洞察ではありません。

　AIにあって私になかったものは2つだけです。

　一つは、自己利益がないこと。私にとってあのツールは、自分で「考えて」「作って」「公開した」、思い入れのある製品です。その中心の形式（セルフチェック）を疑うことは、自分の判断を疑うことです。人は、自分の計画には構造的に甘くなります。AIには守るべき思い入れがないので、他人である私の計画を、私より遠慮なく審査できた。それだけのことです。私は自分の出荷物に、思い入れのない他人の目を一度も通していませんでした。AIが埋めたのは、その普通の抜けだった、とも言えます。

　もう一つは、原稿の全ページを同じ濃度で参照できることです。私は自分の原稿の内容を当然知っています。それでも、人間の記憶は、必要な場面で必要な原則を取り出してくれるとは限りません。AIは渡された原稿の全部を、いつでも引ける状態で持っています。

　この2つは、役割が違います。自己利益の不在は、丸腰のAIにもありました。それだけでは、あの見落としには気付けていない。気付けたのは原稿を渡したからで、気付いた上でためらわなかったのは、自己利益がないからです。

　この遠慮のなさには弱点もあります。AIが容赦なくなれたのは、審査対象が他人（私）の製品だったからです。AI自身の出力を同じ系統のAIに審査させれば、同じ死角を共有します。人間の社外レビュアーでも同じ指摘には届きます。ただし、ちゃんとお願いするには人件費がかかりますし、人間は遠慮することもあるし、原稿を隅々まで読んでくれるとは限りません。AIの取り柄は賢さではなく、低コストであることと、遠慮のなさと、目を皿のようにして全部読むことが可能なことだと思います。

飛躍の条件、渡せる形になった知見

　一言でまとめれば、「AIの出力の質は、渡す知見の濃さで決まる」となります。ただ、それだけなら、いまさら書く価値はありません。良いコンテキストを渡せば良い出力が返ることは、AIを使い込んでいる方ならとっくに体感しているはずですし、以前から「コンテキストエンジニアリング」という名前まで付いて、盛んに語られています。

　私が報告したかったのは、さらにその先です。一つは程度の話。濃い知見を渡されたAIは、その知見の作者に追い付くどころか、追い越して、作者本人の見落としまで指摘してきました。「文脈を渡せば良くなる」ことは知っていても、「渡した本人が上回られる」ところまでを覚悟している人は、少ないのではないでしょうか。私は覚悟していませんでした。

　もう一つは、この観察の限界です。今回AIがここまで走れたのは、渡した知見が理想的な形をしていたからです。書籍の原稿とは、1つの主題について言語化と構造化を極限まで済ませた、AIにとって最高の入力です。世の中のPMの仕事の大半は、こうはなっていません。現場で拾った違和感、言葉になっていない顧客の不満、関係者の間で割れたままの要件。例えばBtoBの業務システムの勘所が、ベテランの営業数人の頭の中にしかない、という現場の方が普通でしょう。素材がまだ言語化されていない領域で、AIが同じように走れるとは、今回の観察からは言えません。

　しかし、これは人間にとって安心材料ではないのです。裏返せば、こう言っているのと同じだからです。「あなたの領域の知見が言語化され、構造化された瞬間に、その知見の運用はAIに渡る。しかも今回の私のように、作者本人より徹底して運用されることすらある」。前回私は「回路をつなぐのは、トークンの量ではなく、組織の知だ」と書きました。AIへの投資が成果に結び付くかどうかを決める、あの回路のことです。今回の観察はその実証であると同時に、人間の側に残る仕事が「知見を作ること」にまで後退した、という厳しい続報でもあります。