AIを使えるようになれば、仕事の主導権も増える。そう考えたくなる。昨日まで手を出せなかった開発に踏み込める。知らない技術について説明を求め、その場で試すこともできる。できることが増えたという実感は、たしかにある。
ただ、仕事が進んでいることと、自分がその仕事を判断しながら進めていることは、いつも一緒とは限らない。
PROTHENTIAのCTO、CJとの対話で話題になったのは、AIを使い始めた後に現れる、このずれだった。導入に抵抗する人の話ではない。むしろ熱心に使っている人のそばで、何が起きているのか。
CJは、身近な現場に三つほどの関係が見える、と話した。この観察をもとに、三つの協働モードとして整理してみる。人間が構想と判断を担い、AIを部品として組み合わせる「指揮型」。CJ自身の使い方はこちらに近い。対話の往復によって、問いや構想そのものも変わっていく「共創型」。答えを求めるだけでなく、何を問うか、何をつくるかも一緒に探っていく関係だ。そして、自分の判断基準が曖昧なまま、AIの提案を受け入れていく「追随型」だ。
これは確立した分類でも、人のタイプを決めるものでもない。同じ人でも、得意な仕事と初めての開発では、協働のモードが変わることがある。指揮型と共創型に優劣をつける意図はないし、AIが先導しているだけで追随型とは限らない。自分なりの基準を持ち、必要なときに問い直せるか。仕事の中でできあがる関係を見ているのだ。
何を手放したのかが、見えない
AIに先導してもらうこと自体は、悪いことではない。入口から道順をすべて描ける人だけに任せるなら、未知の仕事に踏み込める人は増えない。問題は、道案内を頼むとき、何まで一緒に預けているのかにある。
コードを書くことを任せたのか。何をつくるかまで任せたのか。あるいは、できたものをよしとする判断まで、気づかないうちに任せたのか。
ここからは、今回の対話を受けて、もう一歩考えてみたい。
自分で判断するために、すべてのコードを自力で書ける必要があるのだろうか。実現したいことを決め、期待どおりに動いたかを確かめ、想定外なら立ち止まれる。その回路を持てるなら、実装の多くを任せながらでも、仕事に主体的に関われるはずだ。逆に、説明を理解したつもりでも、AIの提案に合わせて成功の基準を後から変えていたら、判断をどこで行ったのかは曖昧になる。
目的、判断基準、異常に気づく手がかり、保留や介入の機会。まずは、このどこかが仕事の流れから抜けていないかを見たい。人に能力がないと決めるより、確かめられる問いになる。
答えではなく、判断の跡を見せる
この問題を考える手がかりは、AIよりずっと前からある。
教育研究の「認知的徒弟制」は、専門家の頭の中で行われる判断を、学ぶ側から見えるようにするアプローチだ。Collinsらは1991年の論考で、専門家が考え方を実演し、学習者の取り組みを観察して助言し、難しい部分には支えを置き、習得に応じてその支えを減らしていく方法を論じた。
完成品だけを渡されても、途中のどこで迷い、何を根拠に選び、何を見て修正したのかはわからない。AIとの協働でも、答えを速く受け取れるほど、その途中が省かれやすいのではないか。
ただし、AIに思考を語らせれば、この問題が片づくわけではない。もっともらしい説明は、それが正しい判断だった証拠にはならない。必要なのは、内面を実況してもらうことよりも、目的に対してどんな選択肢を比べ、何を根拠に決め、どこで結果を確かめるかを、検討できる形で外に出すことだろう。
たとえば、最初はAIと一緒に成功条件を決める。次には、本人が先に条件を書いて、AIに抜けを指摘してもらう。慣れた部分は任せ、初めての条件が出てきたら支援を戻す。こうした変え方は考えられる。
認知的徒弟制は、LLMの利用を実験した研究ではない。この転用がうまくいくかは、これから確かめる必要がある。そして目標も、最後にはAIなしですべてできるようになること、と決める必要はない。何を委ね、どこを確かめればよいかを判断できる。そのための支援なら、使い続けてもよいはずだ。
納得の外に、確かめる場所をつくる
CJとの対話では、腹落ちしていないなら聞けばよいのに、なぜ聞かずに進んでしまうのか、という話も出た。
大切な問いだ。ただ、質問を増やすだけでは足りないかもしれない。AIの答えを同じAIに説明させ、その説明で安心する。会話は丁寧になっても、正しさを確かめる場所が会話の外にないまま、ということは起こりうる。
コーディング研究のTiCoderは、ここに別の接点をつくっている。AIがテストを提案し、人間が期待する動作と合っているかを確認する。そのテストを実行して、候補のコードを絞り込む。説明に納得するかだけでなく、入力に対して何が起きるべきかを、人間が判断する場面が入る。
2024年の論文には、15人の参加者が小さなPython課題に取り組むユーザー研究が含まれる。主にプログラミング経験のある参加者を対象に、特定の条件で正しいコードを見分ける成績の改善が見られた。ただし、これを初心者の成長や実業務の安全性の証明と読むことはできない。人が期待動作を取り違えたり、テストが重要な条件を取りこぼしたりする余地も残る。
それでも、設計上のヒントは具体的だ。人間にコード全体の理解を一度に求める代わりに、何が起きればよいかを判断できる単位へ、接点をつくり直す。そこで得られた実行結果を、次の判断へ返す。
説明を増やすことと、確かめる機会を増やすこと。その違いを、協働の環境に埋め込めないだろうか。
次に試すなら
たとえば、新しい仕事をAIに任せる前に、本人が期待する結果と、起きたら困ることを短く書く。そのうえでAIと確認の方法を考え、実行結果と比べる。確認の基準には、合意済みの仕様や既知の正しい例も使う。判断できない条件は、わからないまま通さず、保留する。食い違いが出たら、指示、実装、確かめ方のどこを見直すべきかを一緒に考える。次は少し違う条件で、支援の置き方を変えてみる。
これは、今回の対話から考えた試行案だ。うまくいくとわかった手順ではない。毎回立ち止まらせれば、単に仕事が重くなる可能性もある。よく知っている作業まで問い直し続けることが、自律なのでもない。
見るべきなのは、質問や介入の回数だけではないだろう。いつもと違う結果が出たときに気づけるか。必要なら止め、確かめ、方針を変えられるか。支援を受けることで、その判断ができる範囲は広がっているか。
AIが先に進めてくれることと、人が考えなくなることを、同じものにしない。その間を分ける仕事のつくり方があるのかもしれない。
入口を越えた先で必要になるのは、もっと賢いAIだけではなさそうだ。その賢さを借りながら、自分の判断も育っていく。そんな関係を、どう設計できるだろうか。