AIをギョームに適用しようとすると、必ず「このギョームはAIに向いてるのか？」という問いが出てきます。わかる、わかるよ。ずっとその問いをやってる。それで、向いてる向いてないを考えて、なんかやった気になって、結局どうすればいいのさという問いには答えられていなかった。

このあたりの判断基準が、自分の中でかなり曖昧だったんだよね。例えば、システム開発の上流工程へのAI適用は、AIが業務文脈を理解していないから難しいよね、学習コーパスが浅いしね。で、話がこれで終わる。それはそうなんだけど、そこで止まっても先に進めない。じゃぁ何をすればAIの恩恵にあずかれるのか。

こういうAI適用を色々考えていくと、問いは3つなんだと思う。「インプット整備」「出力検証」「合意形成の要否」。この3問を順番に通過すると、AIに委譲できるかどうかだけじゃなく、どのような形で委譲するかまで決まるんじゃなかろうか。

AIへの委譲を考える前提
インプット整備・出力検証・合意形成の3問
全体フロー
最後に

AIへの委譲を考える前提

委譲に関することを考え始めたとき、先人の整理が2つあって、どちらもすごく納得感があった。

ZOZOは「情報変換の方向」を軸に整理している。具体から抽象・同一レベルの変換であればAIに向き、抽象から具体への変換（組織事情・事業インパクト等の補完が必要なもの）はAIに難しい、という整理。

具体から抽象への変換は、複数の事例から共通項やパターンを抽出する作業です。たとえば障害報告から課題パターンを見つける、コード差分からレビュー観点を抽出する、仕様書から不足や矛盾を検出する作業はここに含まれます。AIの仕組みが力を発揮しやすい領域です。

同一レベルの変換は、ある形式の情報を別の形式に整形する作業です。Jiraチケットから設計書を作る、設計書から実装タスクを作る、Git diffからレビューコメントを作る作業がこれにあたります。入力と出力の対応が比較的明確であれば、AIに寄せやすい領域です。

一方、深津さんは「精度要求の構造」という別の軸を示している。完璧性を要求する仕事や、精度90％のステップが10個連鎖すると全体成功率が34％になるような長い連鎖ステップを要する仕事はAIに向かない、と。

ポイントは大きく2つあります。

完璧性を要求する仕事を、やってはいけない

ステップが長く連鎖する仕事も、やらせないほうがいい

読んで、そのとおりだと思った。でも、ぼくに次の手は出てこなかった。

この2軸は業務の性質を記述してはいるんだけど、設計者として何を整備すべきか、という問いには直結しない。AIへ委譲するために、自分は何を揃えなければならないんだろうか。

インプット整備・出力検証・合意形成の3問

Q1: AIに渡せるインプット（コンテキスト）を整備できるか？

上流工程でAIを使おうとすると、毎回「で、何の情報を渡せばいいんだっけ？」になる。要件定義書でいいのか。でもドメイン知識は？　ステークホルダーの関係性は？　業務分掌は？「必要だよな」と思いつつ、まとめられたものがどこにもない。そういう混乱が起きる。

wikipedia:Garbage in, garbage outというのは本当で、必要な情報が整備されていなければ、どれだけ精度の高いモデルを使っても出力の質は上がらない。

ただし、インプットが不足していても整備の余地はある。まず試みるべきなのは対話による外化。AIとの対話を通じて、当事者の中に暗黙知として眠っている判断材料を引き出せることがある。このあたりは以前のエントリで書いた。

対話で外化した内容は、仕様化（SDD）でさらに形式化できる。「仕様」とやらに落とし込むことで、AIが自律実行できる精度まで情報の密度を上げる。

でも、それでもやっぱり外化できないケースはある。情報が複数のステークホルダーに分散していたり、そもそも「作ってみないと分からない」情報（「このUIの使い心地はどうか」とか）は、対話ではどうにもならない。この場合はプロトタイピングを先にやって、そこで得た経験を新たな入力として与え直す。なので、対話→仕様化→プロトタイピングという順序で試すのが実態に近そう。

こうした変換手段をすべて試みてもインプットを整備できない場合、そのタスクはAI委譲のスコープ外にした方がいい。暗黙知がすべて言語化できるというナイーブな現実はない。社会はきびしい。

Q2: AIの出力を、人間なしに自動・体系的に検証できるか？

「これ、どうやって評価するんだ？」となる成果物がある。たとえば、システム機能の設計書が与えられて、それが何点か、みたいなことは言えない。言いにくい。あるいは、プロジェクト計画って、関係者の納得感以外に「これで良し」と言えるような基準を作りづらい。そういう成果物をAIに生成させると、良し悪しを判断できないまま採用することになる。Addy Osmaniはこれを「認知的降伏」と呼んでいる。人間が判断を手放した瞬間、理解負債はすごいスピードで積み上がり始める。

もちろん、手段はある。LLM-as-a-Judgeで別モデルに採点させる、評価スクリプトをCIに組み込む、BLEUやF1で数値判定する。多層の評価基準と多段の評価、これらをまとめて「ハーネス」として構築する。

ハーネスは精度問題への対策でもある。精度90％のステップが連鎖すると全体成功率が急落する問題は、ハーネスを挟み込むことで部分的に解消できる可能性がある。1発の精度が100％じゃなくても、検証と再生成の仕組みで精度を「作り出せる」。

でも、自動検証ができない場合、人間が検証者として介在しなければ出力の質を担保できない。したがってQ2が「不可」の場合は、AIとの「同期的」な協業として設計するしかない。生成がされるタイミングタイミングで、人間がフィードバックする。HITL (Human-in-the-Loop)だ。人間はモニタの前にいてAI様の出力を待つ。委譲対象外にはならない点がQ1との決定的な違いになる。

Q3: 合意形成・意思決定のため人間が介在しないと認知的降伏に陥るか？

AI生成物って、結局、なぜそうなったのか誰もわからなくなる。「なんかそれっぽいものができたけどなんで？」ってやつ。でもそれはAI以前の話だったりする。システムもそうで、なんでその設計判断になったのか・その実装になったのか、誰も言えなくなって、変更がリスクになる。だからADRを蓄積しようという話が増えている。判断と合意形成の過程こそが設計の本質なのかもしれない。俺たちはそれをカジュアルに捨てて、成果物だけ敬ってきた。

Mercariのpj-doubleは、全部を非同期のAI委譲で処理しようとした。結果、誰も合意していない自動生成物が量産されたという。上流の要件定義・設計フェーズの本質は「合意形成」にあって、情報変換のAgentic化だけではそこに届かない。

立ち返って考えてみると、従来の上流から下流までの開発フローにおいては、仕様・設計・方針に関する段階的な合意の積み重ねこそが、開発フローのチェックポイントとなって手戻りを防止する機能を果たしていたはずです。またこのプロセスの本当のボトルネックは、これらの合意形成を同じ時間・同じ場所に集まって同期的に行うステップです。pj-doubleは要件定義段階で、プロダクト仕様書や技術設計書を自動で生成することを目指していましたが、このような一次情報が創出される創造的な議論の場や、そこにおける合意形成などの本質的なプロセスがそのスコープから抜け落ちてしまっていました。つまり、上流工程において私たちがフォーカスすべきは、一次情報を組み合わせてプロダクト仕様書や技術設計書に変換するプロセスではなく、その一次情報そのものを生成するプロセスだったという反省です。

合意形成が本質の仕事は、非同期のAI委譲では届かない。そこは人間とAIとの同期的な協業として設計するしかない。pj-doubleの言い方を借りると、「AIと考える」（思考の拡張）と「AIと決める」（意思決定の記録）の2つに分けてデザインする、ということで。自分はこれを読んで、「そりゃそうだよな」と気付かされた。