人の役割はどう変わるか──
設計し、監督し、責任を持つ

15.1なくなるもの、残るもの

第13章の13.4節では、佐藤さんの調査がある日どう進んだかを、時間の記録で追いました。全体で約3時間10分。そのうち、エージェントが動いていたのは約1時間40分、待ち時間が約50分、そして佐藤さん自身の時間は約40分でした。この40分の中身を、もう一度見てみましょう。

40分のうち、佐藤さんは一度も検索をしていません。記事を読み比べることも、表の枠を作ることも、要約の文章を書くこともしていません。調べる・書くという作業は、ほとんどエージェントに移りました。

代わりに佐藤さんがしたのは、次の4つです。

• 依頼を整える：「最近」の範囲や比べる項目など、頭の中の前提を文字にして渡した（9:00）。
• 判断する：D社の公式発表が見つからないという相談に、「空欄にして、その旨を書く」と答えた（11:20）。
• 確かめる：作業記録と成果物を読み、E社の行を出典と照らし合わせた（11:40〜）。
• 責任を持って出す：確かめた比較表と要約を、自分の名前で上司に提出した（12:10）。

どれも、エージェントには代われない部分です。依頼を整えるには、上司が何に使いたいのかを知っている必要があります。相談に答えるには、「確かさと網羅のどちらを取るか」を決める立場が要ります。確かめるには、何が正しいかを見分ける知識が要ります。そして、提出した表について問われたときに答えるのは、佐藤さんです。

第13章の「よくある誤解」で、人の手間は「なくなるのではなく形を変える」と書きました。この章では、その「形」を具体的に見ていきます。残った仕事は、量は少なくても、仕事全体の出来を左右する部分です。ここで手を抜けば、エージェントがどれほど速く動いても、成果物は信用できるものになりません。

15.2新しい4つの役割

残った仕事を整理すると、エージェントと働く人の役割は4つにまとめられます。設計する、頼む、監督する、責任を持つ、です。仕事の流れに沿って並べると、図15-2のようになります。

① 設計する──任せる前に、仕事の形を決める

1つめは、エージェントが動き出す前の設計です。仕事をどう分けるか（第6章）、どの道具をどの範囲で渡し、どこで止めるか（第8章）、どこで何を確かめるか（第11章）を決めます。第14章で見た「どの部分を任せ、どの部分を人がやるか」の仕分けも、ここに入ります。

設計は、毎回ゼロから行うものではありません。一度決めた設計は、同じ種類の仕事で使い回せます。ただし、うまくいかなかったときに直すのも設計の仕事です。図15-2の下を通る矢印は、そのことを表しています。

② 頼む──頭の中の前提を、机に置く

2つめは、依頼を整えることです。第12章で見た6つの要素（目標・背景・制約・判断基準・完了条件・報告のしかた）を、ふつうの言葉で書いて机に置きます。頭脳（言語モデル）は机にないことを知らないので、上司の意図や会社の事情を文字にできるのは、それを知っている人だけです。

③ 監督する──記録を読み、必要なら途中で止める

3つめは、エージェントが動いている間と、動き終わった後の監督です。第3章で見た作業記録を、方針の変更・繰り返し・完了の根拠の3か所に絞って読みます。人が介入できる時点は、始める前・途中・終わった後の3つでした。相談が来たら判断して答え、堂々巡りや思わぬ方針の変更に気づいたら、止めて指示を出し直します。

監督は、全部を見張ることではありません。第8章の承認疲れや、第11章の重点と抜き取りで見たとおり、見る所を絞るからこそ、1か所ずつを真剣に見られます。

④ 責任を持つ──自分の名前で出す

4つめは、成果物を自分の名前で外に出すことです。確かめた結果に納得して承認し、提出し、問われたら説明する。誤りが見つかったら直し、次に同じことが起きないよう設計に戻す。この役割は、次の15.3節で詳しく見ます。

4つの役割が加わると、時間の使い方はどう変わるのでしょうか。佐藤さんの仕事の「以前」と「エージェントを使うようになってから」を比べてみます。

表を縦に見ると、時間の重心が上から下へ移っていることが分かります。以前は「調べる」「書く」に時間の大半を使い、確かめるのは自分で作ったものの見直し程度でした。エージェントを使うようになると、上の2行はほとんどエージェントに移り、代わりに「依頼を整える」「確かめる」が、はっきりした仕事として現れます。そして最後の行、自分の名前で出すことは、どちらでも変わりません。

15.3責任は人に残る

佐藤さんが提出した比較表に、誤りがあったとします。たとえば、E社の行が似た社名の別会社の情報だったとしましょう（第9章 図9-2）。この誤りは、誰の責任でしょうか。

作ったのはエージェントです。けれども、責任を負うのはエージェントではなく、承認して提出した佐藤さんです。これは厳しい決まりごとというより、エージェントの仕組みから自然に出てくる結論です。

エージェントは責任を取れない

仕事で「責任を持つ」というとき、そこには少なくとも3つのことが含まれています。何が起きたかを説明すること、誤りを直すこと、同じことが起きないように手を打つことです。

エージェントは、このどれも自分では引き受けられません。説明を求めれば、それらしい説明の文章は書けます。しかし第9章で見たとおり、その文章も「確からしい続き」として作られたもので、事実の証拠にはなりません。直すことは、人が指示すればできますが、何を直すべきかを決めるのは人です。そして頭脳は使っている最中に学習しないので（第2章）、次に防ぐ手を打てるのは、権限・確かめ方・頼み方を直す人と仕組みの側だけです（第9章）。

人に仕事を頼んだ場合も、考え方は同じです。部下が作った資料をそのまま上司に出して誤りがあれば、「部下が作ったので」とは言えません。確かめて出した人が、その資料に責任を持ちます。エージェントは、その部下以上に、責任の担い手にはなれない存在です。

誰が何を承認したかを残す

責任を持つとは、すべての誤りを防げるという意味ではありません。確かめる仕組みを整えても、誤りがすり抜けることはあります（第11章）。大切なのは、すり抜けたときに、どこで何が起きたかを後からたどれることです。そのために残しておきたいのが、次の3つの記録です。

• 作業記録：エージェントが何を調べ、どこで方針を変え、何を根拠に完了としたか（第3章）。
• 出典と取得日：表の各行が、どの資料のどこから、いつ取られたか（第11章）。
• 承認の記録：誰が、いつ、何を見て承認したか。第8章で見た送信前の承認のように、そのとき見せられた情報ごと残しておくと、後から「何を見て判断したか」が分かります。

第8章の「もう一歩深く」では、エージェントが利用者自身のアカウントで動くと、記録の上で人とエージェントの区別がつかなくなる問題を見ました。責任の面からも、この区別は大切です。エージェントがしたことと、人が承認したことが分けて記録されていれば、「誰が何を決めたか」がはっきりします。

記録があると、何が違うのでしょうか。ここでは、第3章から追ってきた調査を例にします。この調査では、D社の行を業界ニュースの記事で埋め、提出の直前に「公式発表は未確認」という注記を加えました（第3章・第8章）。その比較表について、翌月の企画会議で佐藤さんが質問された場面を見てみましょう。

この場面で佐藤さんが答えられたのは、記憶力が良かったからではありません。作業記録と出典が残っていて、その場で開けたからです。記録がなければ、佐藤さんに言えるのは「エージェントがそう書いていました」だけだったでしょう。それでは部長は、表のどの行をどこまで信じてよいのか判断できません。

記録は、誤りが起きたときに原因を追うためだけのものではありません。誤りがないときにも、成果物の確かさを自分の言葉で説明するための足場になります。責任を持つとは、この説明ができる状態を保っておくことでもあるのです。

15.4確かめる力の土台は、仕事を知っていること

4つの役割のうち、監督することと責任を持つことには、共通の前提があります。成果物が正しいか、目的に合っているかを確かめられることです。では、確かめる力はどこから来るのでしょうか。

第11章で、確かめやすさを3つの段に分けました。段1（機械的に確かめられる）は、手順があれば誰にでもできます。段2（元の資料に当たれば確かめられる）も、資料の当たり方を知っていればできます。ところが、段3（人の判断が要る）は違います。第11章の確認の記録で、佐藤さんは比較表に「価格の列がない」ことに気づきました。どれほど丁寧に照合しても見つからない問題でした。気づけたのは、上司がこの表を次の企画の参考にしたいと知っていて、企画を考えるなら価格が要ることを、自分の仕事として分かっていたからです。

つまり、確かめる力の土台は、その仕事そのものを分かっていることです。何が普通で、何がおかしいか。どこで間違えやすいか。読む人は何を知りたいか。こうした感覚は、作業の手順書には書かれていません。

自分でやったことのない仕事は、確かめにくい

自分でやったことのない仕事は、確かめるのが難しくなります。たとえば、業界の事情を知らない人は、D社がふだんから公式発表をあまり出さない会社なのかどうかを知りません。ニュース記事で代用された行を見ても、「よくあることなのか、おかしなことなのか」を判断できません。エージェントの成果物は体裁が整っているので（第3章）、知識のない目には、どの行も同じように確かに見えてしまいます。

ここに、エージェントを使う職場ならではの難しさがあります。これまで多くの人は、調べる・まとめるといった下積みの作業を通じて、仕事の勘所を身につけてきました。その作業がエージェントに移ると、経験の浅い人が勘所を身につける機会が減ります。それなのに、いきなり「確かめる役」「監督する役」を任されることになります。確かめる力の元になる経験を積まないまま、確かめる側に立つのです。

学び方の工夫

この難しさに、決まった正解はありません。それでも、次のような工夫が考えられます。

• ときどき自分でもやる：たとえば5社のうち1社は自分で調べ、エージェントの結果と比べる。違いが出た所が、自分にとっても仕組みにとっても学びになります。
• 作業記録から進め方を学ぶ：記録の「方針を変えたところ」を読み、自分ならどうしたかを考える。エージェントの進め方は、良くも悪くも、仕事の進め方の見本になります。経験のある人と一緒に読めば、なお効果的です。
• 問題集づくりに参加する：第11章の問題集は、正解の分かった例題の集まりでした。「この仕事の正解は何か」「どこで間違えやすいか」を決める作業は、仕事を理解することそのものです。

どれも、エージェントに任せる時間を少し削って、人が仕事を知る時間に回す工夫です。目先では手間が増えるように見えます。しかし、確かめる力がなければ、任せること自体が危うくなります。

15.5組織として決めること

ここまでは、佐藤さん1人の役割を見てきました。しかし、エージェントを使う人がチームや部署に増えてくると、個人の心がけだけでは足りなくなります。誰かが権限を広く渡しすぎたり、機密を扱ってはいけない環境に会社の資料を入れたりすれば、その影響はチーム全体に及びます。そこで、組織として前もって決めておくことがあります。

表の5つは、どれも第2部で個人の工夫として扱ってきたことです。組織として決めるのは、それを人によってばらばらにしないためです。たとえば、佐藤さんが「送る道具は承認つき」と決めていても、隣の席の人が承認なしで使っていれば、チームとしての最悪の結果の天井は、いちばん緩い人の設定で決まってしまいます。

特に見落とされやすいのが、問題が起きたときの連絡と停止です。エージェントは、人よりずっと速くループを回します。誤った送信や書き換えが続いているとき、誰に知らせ、どうやって止めるかを探している間にも、被害は広がりえます。止め方を知っている人が1人しかいない、という状態も危ういものです。非常停止のボタンと同じで、ふだんは使わないからこそ、場所と使い方を全員が知っておく必要があります。

こうした決まりは、エージェントを使わせないための禁止の一覧ではありません。どこまでなら安心して任せてよいかがはっきりしていれば、一人ひとりは迷わずに使えます。決まりは、任せるための土台です。そして第8章で見たように、実績に応じて広げたり狭めたりしていくものでもあります。

15.6チームで育てる

第9章で、失敗から学ぶのは頭脳ではなく、人と仕組みだと述べました。頭脳は昨日の失敗を覚えていなくても、権限の設定、確かめる手順、依頼のひな形は覚えています。この考え方を、チームの単位に広げてみましょう。

失敗を型で共有する

佐藤さんのチームで、別のメンバーが似た調査をエージェントに頼んでいるとします。佐藤さんが経験したE社の取り違えは、そのメンバーにも起こりえます。けれども、その経験が佐藤さんの頭の中にだけあれば、チームの誰も防げません。

そこで、失敗を第9章の型で記録し、チームで共有します。記録する項目は、たとえば次のようなものです。

• 何が起きたか：E社の行が、似た社名の別会社の情報になりかけた。
• 型：目標の取り違えのうち、対象の取り違え。
• 兆候と気づいた場所：検索結果の上位に似た社名が出た。所在地と事業内容の照合で気づいた。
• 反映先：ひな形の「背景」に、社名の似た会社に注意する一文を足す。問題集に例題を加える。

「E社で変な情報を拾った」という出来事のまま伝えても、聞いた人は自分の仕事との関係が分かりません。型で伝えれば、「自分の調査にも、似た名前の会社はないか」と考えられます。

共有するときに大切なのは、失敗を責める場にしないことです。報告した人が責められるなら、誰も報告しなくなり、チームは同じ失敗を繰り返します。目的は、誰が悪いかを決めることではなく、仕組みのどこを直すかを決めることです。15.3節で見たとおり、責任を持つとは、説明し、直し、次に防ぐことでした。そのうち「次に防ぐ」は、チームで共有してはじめて大きな効果を持ちます。

ひな形と問題集を、チームの資産にする

第12章のひな形と、第11章の問題集も、個人の手元に置いておくのはもったいないものです。チームで共有すれば、新しく加わった人も、最初から育ったひな形で頼み、問題集で仕組みを確かめられます。

共有しないと起きるのが、属人化です。属人化とは、仕事のやり方や判断の勘所が特定の人の頭の中にしかなく、その人がいないと回らない状態のことです。エージェントの使い方が上手な人が1人いて、その人の依頼だけがうまくいく。その人が異動したとたん、チームの成果物の質が落ちる。これは、エージェントが登場する前からある属人化と、同じ問題です。

ひな形と問題集は、育て続けるものでもあります。失敗が起きたらひな形に一文を足し、問題集に例題を加える。効いていない注意書きは削る（第12章）。新しい頭脳に切り替えるときは、チームの問題集で新旧を比べる（第11章）。こうした手入れを誰か1人の善意に任せず、定期的なふりかえりの場などで仕組みにしておくと、続きやすくなります。

確認確認問題