ficus.life/仕事
目次▼

上司が判子を押すしかなくなったとき、権限はどこへ行くのか

1997年の組織の経済理論は、過負荷で判子を押すしかない上司から、実質的な権限が部下へ移ると予測した。その予測が置いていた前提は、生成AIの時代にも保たれるのか。レビューと説明責任と権力の研究を、証拠と推論を分けてたどる。

TOMOAKI··仕事

判子にあたる言葉は、英語にもある。rubber-stamp、ゴム印だ。中身を読まずに承認することを指す、少し見下した響きのある動詞である。この語が、1997年に経済学の主要誌に載った組織理論の論文の中で、ほとんど専門用語のように使われている。しかもその論文は、上司が判子を押すしかなくなる状態を、組織の病理としてではなく、ある意味で企業にとって最適な状態として描いている。

この記事で考えたいのは、生成AIによって部下の出力が、上司の確かめられる速さを超えたとしたら、承認という行為はどうなるのか、という問いだ。「超えたとしたら」と仮定で書くのには理由がある。出力が増えているという話はよく目にするが、どの職場でどれだけ増えたのかを信頼できる形で測った数字を、私は見つけられなかった。それに、2025年初めの道具では、AIを使えば速くなるという前提をそのまま置けないことを示した実験もある。

2025年、AIの評価を手がける研究機関METRが、ランダム化比較試験の結果を公開した。参加したのは経験を積んだオープンソース開発者16人で、自分が平均5年関わってきたリポジトリで課題をこなした。課題ごとにAIの使用を許すか禁じるかを無作為に割り当てたところ、AIを許した課題のほうが、完了までの時間が19%長かった。開発者たちは始める前に、24%短くなると予想していた。終えた後も、20%短くなったと見積もっていた。遅くなったのに、本人は速くなったと見積もっていたことになる。

この19%が、その後の道具でも同じだとは限らない。METRは2026年2月、より新しい道具で続けた実験の暫定値を出した。元の参加者では完了までの時間が18%短くなり(信頼区間はマイナス38%からプラス9%)、新しく集めた参加者では4%短くなった(マイナス15%からプラス9%)。ただ、AIなしで作業したくないという理由で参加を断る開発者が目立って増え、謝礼も下げたことから、METR自身がこの新しいデータを当てにならない合図だと書いている。METRは、この偏りが速さを小さく見せる向きに働くとみている。そのうえで、参加者との会話から、2026年初めには2025年初めの見積もりより速くなっている見込みが高いとみる。どれだけ速くなったのかについては、偏りがあるため、新しいデータはごく弱い証拠にしかならない、とも書いている。同じ実験の数字の全体と続報の詳しい経緯は、ポモドーロ・テクニックについての記事で書いた。ここで要るのは速さの向きではなく、本人の見積もりと測った時間がずれうる、という一点である。

2025年の結果は、出力が増えているという前提を支えるものではない。むしろ、量と進み具合は別物だと告げている。同じ論文は序論で、AIはコードの行数を増やせても、それが生産性の向上とは限らない、冗長だが機能は同じコードがありうるからだ、と注意している。とはいえ、この実験には承認の話につながる細部がある。感じ方と実際がずれていたのは、作業をした本人だった。作った本人ですら、速くなったのか遅くなったのかを見誤るのなら、それを受け取って判断する側は、何を手がかりにしているのだろうか。

以下では、確かめる側の限界を示す研究から始め、承認が組織で何をしてきたのかを説明責任の研究と組織の経済理論で確かめ、最後に、承認の中身が抜けたとき、承認する人の側に何が起こりうるかを考える。先に断っておくと、後の段になるほど証拠は薄くなる。どこまでが確かめられたことで、どこからが私のつなぎ合わせなのかを、段ごとに書き分けていきたい。

読む速さには上限がある

確かめる作業にかけられる時間には限りがある。当たり前の話だが、その限りがどのあたりにあるのかを示す数字は、思いのほか少ない。よく引かれるのは、コードレビューのツールを売るSmartBear社の数字だ。同社は自社サイトで、シスコシステムズの開発チームを対象にした自社の調査に基づくとして、一度にレビューするコードは200〜400行までにすべきで、400行を超えると欠陥を見つける力が落ちる、と書いている。読む速さについては、1時間に500行より速く読むと欠陥密度、つまり読んだコードあたりに見つかる欠陥の数が大きく下がる、としている。

扱いには注意が要る。これは査読を経た論文ではなく、ツールの販売元が、自社の調査として紹介しているものだ。速く読んだレビューで見つかった欠陥が少なかったという関係は、速く読んだから見落とした、とも読めるし、もともと欠陥の少ないコードだから速く読めた、とも読める。それでも、向きとしては多くの人の実感と合うだろう。知人の短い作文なら赤ペンを入れられても、厚い契約書を一晩で読めと言われれば、目は文字の上を滑っていく。

査読を経た研究のほうは、話がもう少し入り組んでいる。アルベルト・バッケリとクリスチャン・バードは2013年、マイクロソフトのコードレビューを調べた。17人の開発者を観察して面接し、873人のプログラマーと165人のマネージャーに質問紙調査を行い、さらにレビューのスレッド200本から570件のコメントを取り出して分類した。プログラマーもマネージャーも、レビューのいちばんの動機として欠陥を見つけることを挙げていた。ところが570件のうち、欠陥についてのコメントは78件、14%で、九つの分類のうち4番目にとどまった。最も多かったのは、より良い書き方、不要なコードの削除、読みやすさといった「コードの改善」で、165件、29%だった。欠陥のコメントにしても、多くはif文の条件式の誤りのような、局所的な論理の問題だった。

期待と結果がずれる理由として、著者らが挙げるのは理解である。なじみのないファイルのレビューには時間がかかるか、という質問に、回答したプログラマーの91%にあたる798人が「はい」と答えた。担当しているファイルを知っているレビュアーは違う種類のコメントをするか、という質問にも82%が「はい」と答えている。ある回答者は、知らないコードを理解するにはずっと時間がかかり、それでも理解は深くならない、と書いた。レビューで得たい成果のうち、最も深い理解を要するのは欠陥を見つけることだと、回答者たち自身が評価していた。理解が足りないとき、レビューは悪意や怠慢からではなく、理解しなくても書けるコメントの側へ流れていく。

生成AIが書いたものは、この意味で、誰にとっても「なじみのないファイル」に近いのかもしれない。書いた部下の頭の中にも、その文書やコードがなぜそうなっているのかの経緯が、以前ほどは残っていない可能性がある。これは推測にすぎない。ただ、次に見る調査には、この推測と無関係ではない手がかりが含まれている。

見ているつもりのずれ

2025年のMETRの論文には、AIの出力を確かめる手間についての数字もある。開発者たちが採用したAIの生成結果は、44%に満たなかった。画面録画で作業の中身を分けられた課題で見ると、AIを使ってよい課題では、作業時間のおよそ9%がAIの出力の確認と手直しに充てられていた。著者らによれば、受け入れなかった生成結果も、捨てる前に読み、試し、手を入れていることが多かった。これらの数字で遅れの理由を説明しようとした部分については、著者ら自身が推測的な証拠だと断っている。

対象になった開発者たちは、平均5年関わってきたリポジトリで、レビューの基準が高い環境に身を置いていた。確かめる力が高そうな人たちが、確かめやすい自分の領域で作業していたわけだ。にもかかわらず、自分が速くなったのか遅くなったのかの見積もりは外れた。上司が部下の出力を受け取る場面は、これより条件が悪いことが多いだろう。対象は自分の書いたものではなく、自分の専門の中心から少し外れていることもある。

ただし、この研究は査読前のプレプリントで、著者ら自身が、結果を一般化しすぎないようにと繰り返し断っている。対象は16人、使われたのは2025年初めのAIツール、場面はソフトウェア開発の一つの形にすぎない。上司による承認を測ったものでもない。

知識労働者全般については、カーネギーメロン大学とマイクロソフト・リサーチの研究者らが2025年に発表した調査がある。ハオピン・リーらは、仕事で生成AIを使っている知識労働者319人から、実際に使った936件の事例を集めた。事例ごとに批判的思考をしたかどうかを本人に尋ねて分析すると、その作業をAIがこなせると信じている度合いが高いほど、批判的思考をしたと答える傾向は弱かった。反対に、その作業を自分でこなせる自信や、AIの答えを評価できる自信が高い人ほど、批判的思考をしたと答えていた。

この調査で目を引くのは、批判的思考が消えるというより、置き場所を変えている点だ。情報を集める手間は減り、代わりに、AIの答えを確かめること、それを仕事に組み込むこと、作業全体の舵取り(論文の言葉では task stewardship)へと手間が移っていた。確かめることを妨げる事情として、319人のうち44人が時間の不足を挙げ、58人が、AIの答えを点検しようにもできないこと、たとえば分野の知識が足りず正しいかを判断できないことを挙げた。会社のマーケティングの文案をChatGPTで書いていたある回答者は、確認と書き直しはチームの別の担当がやる、と答えている。

最後の答えは、何気ないが重い。この回答者の職場では、別の担当が実際に確かめ、手を入れているという。それでも、書いた側の頭の中で、確かめる仕事が自分の外に置かれていることは分かる。SmartBear社のページにも、誰かほかの人が見落としを拾ってくれるだろうと考えて急いで読むことを戒める一文がある。書く側と確かめる側が、互いに相手を安全装置だと思っていたらどうなるか。確かめる工程は、両側に人が立っているのに誰も通らない廊下のようになる。

もっとも、この調査は自己申告の質問紙で、批判的思考を実際に測ったものではない。著者らも限界の節で、回答者が「AIを使う手間が減ったこと」と「批判的に考える手間が減ったこと」を取り違えていた例があったと書いている。示されたのは相関で、AIへの信頼が批判的思考を減らすという因果ではない。回答者は英語話者で、若く技術に慣れた人に偏っていたことも、著者ら自身が挙げている。

人と自動化の関係には、生成AIよりずっと前からの研究の蓄積がある。ラジャ・パラスラマンとディートリッヒ・マンジーは2010年の総説で、自動化への油断(complacency)と自動化バイアスについての実証研究をまとめた。要旨によれば、油断は、手作業が自動化された作業と注意を奪い合う、複数の作業を抱えた条件で起きる。初心者にも熟練者にも見られ、単純な練習では克服できない。もう一方の自動化バイアスは、判断支援が不完全なときに、見落とし(omission)と誤った実行(commission)の両方の誤りを生む。こちらも初心者と熟練者の両方に起き、訓練や指示では防げず、個人だけでなくチームの意思決定にも及ぶ。

熟練者にも起き、練習や訓練では簡単には防げない。この一点は、承認が粗くなることを上司の資質の問題として片づけたくなる気持ちに、歯止めをかける。もちろん、この総説が扱うのは自動化されたシステムや判断支援システムを使う場面で、部下の書類を読む上司ではない。ただ、ほかの仕事と並行しながら、たいていは正しい出力を見張る、という条件は、忙しい承認者の置かれた条件とよく似ている。

承認は誰に向けた説明なのか

承認が組織の中で何をしているのかを考えるには、説明責任の研究が手がかりになる。フィリップ・テトロック、リンダ・スキトカ、リチャード・ベトガーが1989年に発表した実験は、人が誰かに自分の判断を説明しなければならないとき、三つの異なるやり方で対処する、という予測を検証したものだ。要旨によれば、こうなる。(a) 相手の考えが分かっていて、過去の自分の表明に縛られていなければ、人は手間のかからない「受け入れられやすさ」の近道に頼り、自分の見解を相手の考えへ寄せる。(b) 相手の考えが分からず、過去の表明にも縛られていなければ、比較的柔軟に、いくつもの観点から考えようとする。先回りした自己批判である。(c) すでに肩入れしている立場について説明を求められると、心の努力の大半をその立場の正当化に注ぐ。防御的な補強と呼ばれる。実験の結果は、この三つの予測を支持した。

この枠組みを承認に当てはめるときに気をつけたいのは、誰がどの条件にいるかが、立場によって違うことだ。部下は、たいてい上司の好みを知っている。それなら (a) の近道に寄りやすい。生成AIは、相手に受け入れられそうな体裁の文書を手早く作るのが得意だから、この近道をさらに安くするかもしれない。承認する上司のほうは、その先の聴衆、つまりさらに上の上司や顧客の考えが分かっていなければ、(b) の自己批判に向かいうる。ただしそれは手間のかかるやり方で、時間がなければ選びにくい。そして、いったん判子を押した後で問題が見つかれば、承認した上司は、その案に肩入れした当事者になる。そこから先は (c) の、正当化に努力を注ぐ条件に入っていく。

念のために書いておくと、この当てはめは私のものである。テトロックらの実験は、説明を求められた個人がどう考えるかを調べたもので、組織の決裁を調べたものではない。私が読めたのは要旨までで、手続きの細部は確かめていない。ただ、三つの区別は一つのことをはっきりさせてくれる。承認は判断の質を上げる仕組みであると同時に、誰が誰に対して説明するのかを決める仕組みでもある。判子は、紙の上の中身についての判断である前に、何かあったときに説明する役を引き受けた、という印でもあるのだろう。

判子を押すことは、権限を手放すことだった

では、判子を押すしかなくなった上司は、権限を失ったのか。この問いにいちばん正面から答えているのが、冒頭で触れた経済学の論文だ。フィリップ・アギオンとジャン・ティロールは1997年、組織の中の権限を二つに分けた。公式の権限(formal authority)は、決める権利のこと。実質的な権限(real authority)は、決定を実際に左右する力のことで、これは誰が情報を持っているかで決まる。

モデルの骨組みは単純である。部下は手間をかけて候補の案を調べ、一つを上司に推す。上司も、どれだけ時間をかけて自分で調べるかを選ぶ。上司が自分で調べて中身を知っていれば、部下の推す案が自分の望む案と違うとき、それを覆す。知らなければ、部下の案に判子を押す。論文の言葉では、上司は「より悪い案を選ぶことを恐れて」部下の提案を rubber-stamp する。部下の推す案は上司の利益とある程度重なっていると期待できるので、何も知らずに自分で選ぶよりはましだからだ。このとき部下は、公式の権限を持たないまま、実質的な権限を持つ。

論文はすぐに例を挙げている。抱える仕事が多すぎて、一つひとつについて情報を集める時間のない上司は、実効的な支配を失い、望ましくない案の多くを、意図せずに承認することになる。過負荷は、公式の権限を上司の手元に残したまま、実質的な権限を部下へ移す経路なのである。話はそこで終わらない。部下の側から見ると、上司が覆さない見込みが高いほど、自分で調べる手間をかける甲斐がある。過負荷は上司の支配を弱める一方で、部下のイニシアチブを強める。

論文の後半で、二人は一人の上司が抱える部下の数、つまり管理範囲をモデルに加え、企業にとっては常に過負荷の状態にあることが最適だ、と結論している。部下のイニシアチブに報いることを、信頼できる形で約束するためだという。脚注の例が面白い。過負荷のところでは、部下の振る舞いが変わらないとすれば、部下を一人増やしたときの利益は負になる。だから上司としては、過負荷になるより、たとえばゴルフをして過ごすと約束したほうがよさそうに見える。だがゴルフをするという約束は、信頼できる約束にならない。過負荷のほうは信頼できる。過負荷は、イニシアチブを潰さないという信頼できるコミットメントだ、と二人は書く。

同じ論文では、決定が急を要するほど上司の確認は通り一遍になり、判子を押しやすくなることも導かれている。急ぐ決定を扱ったこのモデルでは、部下の案が上司の利益と重なる見込みが十分に高ければ、確かめもせずに判子を押すのが最適になる、という結果も出てくる。一方で二人は、繰り返しの関係の中で上司が「重要でない事柄には口を出さない」という評判を築き、自分から権限の行使を控える場合も取り上げている。そしてそれは判子を押すこととは別物だと、わざわざ括弧書きで区別している。

そう考えると、中身を読まない承認は、それだけでは病理と言えない。モデルの上では、上司が全部を確かめられないこと自体が、部下が自分で調べて工夫する動機を支えている。形だけの判子は、権限が消えたことを意味しない。権限が、書類の上と実際とで別々の場所に住むようになったことを意味する。判子を押すしかない上司は、権限を失ったというより、実質的な権限を部下へ渡していた。望ましくない案の多くを意図せず通すことになっても、過負荷そのものは、モデルの上では企業が選ぶ最適な状態である。公式の権限は手元に残っている。原典に沿って言えば、そうなる。

この理論が置いていた、もう一つの前提

アギオンとティロールの判子には、しかし成り立つための条件がある。判子を押すことが上司にとって合理的なのは、部下が実際に調べ、中身を知ったうえで案を推しているからだ。これはモデルの仮定から出てくる性質で、論文自身がはっきり書いている。候補の中には十分に悪い結果をもたらす案が必ずあるので、何も知らない部下は、特定の案を推すより、知らないと認めて何もしないよう勧めるほうを選ぶ。何も知らない上司も、自分から案を採ろうとはしない。だから、部下が案を持ってきたという事実そのものが、部下は調べた、という知らせになる。

生成AIは、この知らせの意味を変えるかもしれない。中身を調べていない部下でも、調べたように見える案を作れるとしたら、案があることと、誰かがその中身を知っていることとが、以前ほどは結びつかなくなる。上司は、部下が情報を持っていると見込んで判子を押す。部下は、上司か別の誰かが確かめると見込んで案を出す。この組み合わせを想像するのは、難しくない。そのとき、アギオンとティロールの言う実質的な権限は部下に移るのではなく、誰の手にも渡らないまま宙に浮く。

これは、モデルの仮定と最近の調査を私がつなげて立てた推論で、確かめた研究はない。アギオンとティロールのモデルでは、部下が情報を得るには手間がかかり、その手間をかけなければ何も分からないままだ。AIのように、調べずに推せる安い手段は想定されていない。それを想定に入れたら結論がどう変わるのかは、モデルを組み直してみなければ分からない。

反対の向きを示す観察もある。マヌエル・ホフマンらは、GitHubが上位のオープンソース開発者にCopilotを無料で提供した仕組みを利用し、提供の境目のすぐ上と下にいる開発者を比べた(回帰不連続デザイン)。著者にはハーバード・ビジネス・スクールの研究者のほか、マイクロソフトとGitHubの関係者も加わり、GitHubから資金面の支援を受けている。結果、Copilotを使えるようになった開発者は、活動に占めるコーディングの割合を5.4ポイント増やし、プロジェクト管理の割合を10ポイント、基準と比べて約25%減らした。ここでいうプロジェクト管理には、課題の掲示板でのやり取りや、寄せられたプルリクエストの体系的なレビューが含まれる。関わるリポジトリの協働者の数も、基準の22人に比べて17人ほど少なくなり、著者らはこれを、より自律的で協働の少ない働き方への移行と解釈している。効果は、相対的に能力の低い開発者でより大きかった。

出力が増えれば確かめる仕事も増える、という素朴な見通しとは、逆の向きである。AIは、部下が上司や仲間に尋ねていたことの一部を引き受け、調整やレビューの仕事そのものを減らすのかもしれない。著者らは、生成AIには組織の階層を平らにする可能性がある、とまで書いている。ただしこれは、上司と部下の関係のゆるいオープンソースという場での、上位の開発者についての観察で、論文は査読前のワーキングペーパーでもある。企業の中の決裁に同じことが起きるかどうかは、この研究からは言えない。

見張るだけになった人の地位

アギオンとティロールのモデルの上司は、自分の利益を計算する主体で、判子を押すことに痛みを感じない。現実の人間はそうはいかないかもしれない。この点で示唆に富むのが、心理学者リザンヌ・ベインブリッジが1983年に書いた「自動化の皮肉」である。この論文のうち見張りの難しさについての議論は、先に触れたポモドーロ・テクニックの記事で取り上げたので、ここでは別の箇所を読みたい。

工場や発電所のプロセス制御を論じる中で、ベインブリッジは、労働者の技能はその人の地位の大きな部分を占める、と書く。仕事が見張るだけのものに減らされて技能を要しなくなると、本人はそれをなかなか受け入れられない。そこから、技能を失った労働者が、仕事の中身ではもはや裏付けられない地位の、残された象徴として高い給与にこだわる、という釣り合わない賃金格差の皮肉が生まれる、と彼女は続ける。

ベインブリッジはもう一つ、見張り役の操作員が異常に気づいたら監督者を呼ぶ、という仕組みの穴も指摘している。監督者もまた、関係する知識を復習し、肝心の技能を練習していなければ、いざというときに引き継げない。異常のときに呼ばれて引き継ぐ側だという点で、承認する上司は、この監督者の位置に近い。確かめることをやめた上司は、やがて確かめる力そのものも失うのかもしれない。

地位や技能の裏付けを失った人がどう振る舞うかについては、権力の心理学に実験がある。ナサニエル・ファストとセリーナ・チェンは2009年、権力を持つ人が攻撃的になるのはどんなときかを、四つの研究で調べた。権力は、職場での実際の立場を尋ねる方法(研究1と4)、権力を持った経験を思い出させる方法(研究2)、実験室で役割を割り当てる方法(研究3)で扱われた。どの方法でも、権力は、自分には能力が足りないという本人の感覚と組み合わさったときに、攻撃性の高まりと結びついていた。共著者のチェンは大学の発表資料で、無能さだけでは攻撃性は生まれない、権力の大きな役割と、その役割に自分が見合わないのではという恐れが組み合わさったときに起きる、と説明している。

大学の発表資料と英国心理学会の研究紹介によれば、研究2では、クイズで間違えた相手に浴びせる騒音の大きさを選ばせた。研究3では、賞品のかかった知能テストを受ける架空の学生に、わざと難しいテストを割り当てるかどうかを見た。測ったのは客観的な能力ではなく、本人が自分をどう見ているかである。そして研究3と4では、リーダーシップの質問紙で優れた結果だったと伝えたり、自分にとって大切な価値について書かせたりして自己価値を補強すると、攻撃性の高まりは見られなくなった。

とはいえ、扱いは難しい。英国心理学会の紹介記事は、論理は筋が通っているが、示された証拠は予備的なものだ、と評している。研究3の参加者は学生で、権力を振るう相手は架空の学生だった。同じ研究室の外での追試は、私が探した範囲では見つからなかった。大学の発表資料によれば、著者らは論文の結びで、へつらいは自尊心を支えるとしても、無能な権力者を現実から遊離させ、最終的な失墜に手を貸しかねない、と皮肉まじりに書いている。

近い問いを、権力と地位を分けて扱った実験もある。ファスト、ニール・ハレヴィ、アダム・ガリンスキーが2012年に発表した研究で、スタンフォード大学経営大学院の紹介によれば、学生の参加者に、地位の高い「アイデアを出す役」か地位の低い「作業をする役」を割り当て、権力の有無と組み合わせたうえで、相手にやらせる課題を10の候補から選ばせた。権力は高いが地位は低い役に置かれた人は、ほかのどの組み合わせよりも、犬のように3回吠える、といった屈辱的な課題を相手に選んだ。こちらは1回の実験で、私は論文の本文を読めていない。

二つの研究が描く像は似ている。権力を持ちながら、それを裏付ける能力の感覚や周りからの敬意を欠くと、人は相手を貶めたり妨げたりする方向へ傾く、という像である。権力が大きいことだけでは、そうはならない。そしてベインブリッジの言う「仕事の中身では裏付けられなくなった地位」は、この条件と重なって見える。

見える、というところまでである。承認の中身が抜けた上司が、自分を無能だと感じるのかどうか。感じたとして、それがファストとチェンが実験で作り出した無能感と同じものなのかどうか。どちらも、誰も測っていない。AIの普及と上司の攻撃的な言動を結びつけて調べた研究も、私の探した範囲では見つからなかった。この節の話は、別々の研究を私がつないだ鎖であって、一続きに確かめられた因果ではない。それに、アギオンとティロールの見方に立てば、判子を押すことは上司の合理的な選択でもありうる。合理的な選択を本人が屈辱として経験するかどうかは、また別の問いだ。

どの段に証拠があり、どの段にないのか

たどってきた鎖を、段ごとに分けておく。部下の出力が確かめる速さを超えるかどうか、という最初の段は、仮定のままだ。METRの実験は、AIで速くなったという本人の見積もりが外れうることを示したが、出力が上司の処理能力を超えるほど増えたことを示したわけではない。ホフマンらの観察は、むしろ調整やレビューの仕事が減る向きを示していた。

確かめる質が落ちうる、という次の段には、間接の証拠がいくつかあり、向きはそろっている。理解の足りないレビューは表面的な指摘に寄る(バッケリとバード)。作った本人ですら、速くなったのか遅くなったのかを見誤る(METR)。AIを信頼する人ほど批判的に考えたと答えにくく、確認を他人の仕事と考える人もいる(リーら)。熟練者でも自動化に油断し、判断支援の誤りに引きずられる。後者は訓練や指示でも防げない(パラスラマンとマンジー)。どれも、上司の承認そのものや、AIの出力を確かめる人の確認の質を測ったものではない。

判子を押すしかなくなった上司から、実質的な権限が部下へ移る、という段は、アギオンとティロールのモデルの予測だ。経済理論としては筋が通っているが、AIのもとで確かめるのは、これから先の仕事になる。部下も中身を知らないまま案を出すなら権限は宙に浮く、という部分に至っては、私の推論でしかない。

承認が空洞化した上司が支配的な振る舞いで埋め合わせる、という最後の段は、いちばん証拠が薄い。権力と無能感、権力と低い地位の組み合わせについての実験はあるが、研究の数は限られ、独立の追試も見当たらない。承認の空洞化がその条件にあたるかどうかは、推測の域にとどまる。

上司はどうすべきか、という問いに、この記事は答えない。答えようとすれば、どの段の証拠に寄りかかるかを選ぶことになり、その選び方が、ここまで確かめてきた不確かさを覆い隠してしまう。代わりに、問いを一つだけ置いておく。アギオンとティロールのモデルでは、上司が判子を押すとき、権限は情報を持っている人のところへ行く。生成AIが書いた案に判子が押されるとき、その中身を知っている人は、組織の中のどこかにいるのだろうか。

出典

  • SmartBear Software. Best Practices for Code Review.(同社ウェブサイトのページ、2026年10月22日閲覧。コードレビューのツールを販売する会社による、自社調査の紹介で、査読を経た研究ではない)
  • Bacchelli, A., Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. Proceedings of the 35th International Conference on Software Engineering (ICSE), 712–721.
  • Becker, J., Rush, N., Barnes, B., Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089.(査読前のプレプリント。v2 を参照)
  • Becker, J., Rush, N., Cunningham, T., Rein, D., Mahamud, K. (2026). We are Changing our Developer Productivity Experiment Design. METR, 2026年2月24日. https://metr.org/blog/2026-02-24-uplift-update/(METR のウェブサイトの報告で、査読を経ていない)
  • Lee, H.-P., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3706598.3713778
  • Parasuraman, R., Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 52(3), 381–410.(要旨で確認)
  • Tetlock, P. E., Skitka, L., Boettger, R. (1989). Social and Cognitive Strategies for Coping with Accountability: Conformity, Complexity, and Bolstering. Journal of Personality and Social Psychology, 57(4), 632–640.(要旨で確認)
  • Aghion, P., Tirole, J. (1997). Formal and Real Authority in Organizations. Journal of Political Economy, 105(1), 1–29.
  • Hoffmann, M., Boysel, S., Nagle, F., Peng, S., Xu, K. (2024). Generative AI and the Nature of Work. Harvard Business School Working Paper 25-021/CESifo Working Paper 11479.(査読前のワーキングペーパー。CESifo 版を参照)
  • Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779.
  • Fast, N. J., Chen, S. (2009). When the Boss Feels Inadequate: Power, Incompetence, and Aggression. Psychological Science, 20(11), 1406–1413.(本文は未見。要旨と、下の二つの紹介で確認)
  • Anwar, Y. (2009). Bosses who feel inadequate can turn into bullies. UC Berkeley Press Release, 2009年10月13日.(二次情報)
  • Jarrett, C. (2009). Self-doubt turns bosses into bullies. BPS Research Digest, 2009年10月18日.(二次情報)
  • Fast, N. J., Halevy, N., Galinsky, A. D. (2012). The Destructive Nature of Power without Status. Journal of Experimental Social Psychology, 48(1), 391–394.(オンライン版は2011年。本文は未見。Stanford Graduate School of Business のウェブサイトの紹介による二次情報)
XはてなブックマークLINEFacebook