AIに任せる範囲｜査読論文20本で工程別に線を引く
この記事の結論
・AI支援を使った群は、セキュリティ課題の5問中4問で有意に安全でないコードを書きました。同じ実験で、その群はすべての設問で対照群より「自分の解答は安全だ」と信じていました。品質は下がり、自信は上がる。
・レビューを厚くすれば止まるわけでもありません。実データでは、Qt 5.0.0で欠陥のあったコンポーネントの87%が網羅率100%でした（同じ数字はITKで83%、Qt 5.1.0で70%、VTKでは7%です）。継続的インテグレーションを入れた研究では、開発側が見つけるバグは+48%増えた一方、ユーザーから報告されるバグには有意な差がありませんでした。
・だから人が担保すべきなのは「最後に置く関門」ではなく、失敗が自分に見える形で出てくるかどうかです。設計・実装・レビュー・デプロイの4工程で、どこに線を引けるかを査読論文20本で分けます。全文無料です。
「全部AI任せで回るのか」という問いに、先に答えを出しておきます。
たぶん回ります。ただし、回っていることと、回っているように見えることの区別がつかなくなる。航空やプラント制御、医療で40年測られてきた自動化研究が繰り返し示してきたのはそこでした。ソフトウェア開発そのものを測った研究は、実装とレビューとデプロイの周辺にしかありません。
まず工程ごとの線を出します。ここは研究そのものではなく、後半の証拠から引いた線です。
・設計：候補出しと反証探しは渡す。前提と受け入れ条件、戻せない判断は残す。
・実装：テストで合否を確かめられて、戻せる範囲は渡す。「安全そう」という感覚を判定に使わない。
・レビュー：定型の検査は渡す。人は反例を出して議論を起こす側に回る。
・デプロイ：戻せる操作は渡す。戻せない操作だけ、手前に人を置く。
以下、工程ごとに根拠を見ていきます。
実装：いちばん当てにならないのは「安全だと思う感覚」だった
実装は、AIの効果を測った査読研究がいちばん多い工程です。ただし測られているのは速さと脆弱性で、「4工程のどこでAIが最も強いか」を比べた研究は見つかりませんでした。
Perryら（2023, ACM CCS）が参加者を無作為に割り付け（分析対象47人。AI群33人・対照群14人）、Python・JavaScript・Cで5つのセキュリティ課題を解かせました。AI支援を使った群は、5問中4問で有意に安全でないコードを書いています。
たとえばSQL注入を防ぐ課題では、注入に対して脆弱な解答を書いた人がAI群の36%、対照群は7%でした（p=0.041）。署名の課題では、安全な解答を書けたのがAI群の3%に対し、対照群は21%です（p=0.039）。
この研究のいちばん効く部分は、もう一方の軸です。AI支援群は、すべての設問で対照群より「自分の解答は安全だ」と信じる傾向がありました。
Pearceら（2022, IEEE S&P）はCopilotに1,689本のプログラムを書かせ、約40%に既知の脆弱性パターンを見つけています。脆弱性の種類を体系的に振った54シナリオ・1,084本の別集計では、C言語が50.3%、Pythonが38.4%でした。
ただし「AIのコードは危険」と一般化はできません。
Sandovalら（2023, USENIX Security）は58人を対象に、C言語の連結リスト実装で非劣性検定を使い、重大なバグの悪化は10ポイント以内に収まったと報告しています。しかも調べた脆弱性564件のうち、356件（63%）は人間が書いたコード由来でした（AIの提案由来は36%で、そのまま採用が16%、人が手を入れたものが20%）。
結論が分かれているのは、測った対象が違うからです。Perryは複数言語と暗号やSQL注入などの設計上の誤り、Sandovalはメモリ安全性のバグに限定し、統計の枠組みも違います。どちらかを選ぶのではなく、両方が正しいと読むのが誠実だと思います。
大きな留保があります。これらはすべて2021年から2022年のモデル世代を測ったものです。いまのモデルに同じ数字は当てはまりません。
速度についても一言。「55.8%速くなった」という数字がよく引かれます（Peng et al. 2023）。これは未査読のプレプリントで、著者自身がコードの品質と安全性は測っていないと明記しています。著者はGitHubとMicrosoft Researchの所属で、ツールを提供している側による測定でもあります。速さの証拠を、安全の証拠として使えません。
レビュー：網羅率100%でも欠陥は残った
では、後ろのレビューで止められるのか。ソフトウェア工学の実データは、そこに条件を付けます。
McIntoshら（2014, MSR）がQtやVTKの実データを解析したところ、レビューの網羅率が低いコンポーネントほど欠陥が多い関係は確かにありました（Qt 5.0.0で係数−0.25, p<0.01）。
ただし同じ論文が、こうも書いています。
Qt 5.0.0では、欠陥のあったコンポーネントの87%（222件／254件）が網羅率100%でした。同じ数字はQt 5.1.0で70%、ITKで83%、VTKでは7%と幅があります。
正直に書いておくと、この4つのうちQt 5.1.0だけは、網羅率100%のコンポーネントのほうが欠陥の発生が有意に少ないという差が出ています（他の3つでは有意差なし）。全部レビューすることが効いた場面もある、ということです。
それでも著者らはこうまとめています。モデルの上では網羅率と品質は結びついているのに、欠陥が多いコンポーネントのいくつかは網羅率が高い。だからレビューの別の性質が効いているはずだ、と。
その別の性質が、参加度でした。3つのリリースすべてのモデルで一貫して有意だったのは網羅率ではなく、こちらです（VTKはデータが足りず、参加度の分析から外れています）。
参加度の低いコンポーネントには最大5件の追加欠陥が対応しています。ただしこの5件は、著者が自己承認の割合で見たときの数字です。議論なしの割合だけで見ると、0.71以上で2件、0.9以上で3件でした。
これは観察研究なので、因果としては読めません。難しいコードほどレビューが薄くなるのか、逆に念入りになるのか、その向きを分離できていない点は著者も認めています。なお著者は、網羅率のモデルと参加度のモデルは対象コンポーネントが違うので直接比べるべきではない、とも書いています。
人数はどうか。RigbyとBird（2013, ESEC/FSE）が12プロジェクトを横断して調べると、レビュアー数は中央値2人に収束していました。マイクロソフトの3プロジェクトでは、それを超えるとコメントの増分はごくわずかだと報告されています。
ここで1つ、帰属を正確に書いておきます。「2人で欠陥発見が飽和する」という定量的な根拠は、この論文自身のデータではありません。彼らが測ったのはコメント数や再提出回数で、欠陥の数そのものではない。飽和の根拠は、もっと古い伝統的なインスペクション研究からの援用です。
Googleの事例（Sadowskiら 2018, ICSE-SEIP）では、約900万件のレビューでレビュアー数は中央値1人、完了までの中央値は4時間未満でした。ただし単一企業の探索的な事例研究で、著者自身が一般化できないと明記しています。
デプロイ：検出器を増やしても、ユーザーが踏む欠陥が減ったとは言えない
検査の仕組みを厚くすればいい、という方向にも限界があります。
Vasilescuら（2015, ESEC/FSE）がGitHubの246プロジェクトを前後で比較しています（このうちバグ報告の分析は、issueのタグ付けが一貫していた42プロジェクトに絞られています）。継続的インテグレーションを導入したプロジェクトでは、コア開発者によるバグ報告が +48% 増えていました。発見力が上がった、と読めます。
コア開発者のプルリクエストのマージは+20.5%、却下は−42.3%でした（外部からの貢献については、マージに有意な変化はありません）。
ところが同じ研究で、外部のユーザーから報告されたバグには有意な差がありませんでした。
自分たちが見つける欠陥が増えたことと、ユーザーが踏む欠陥が減ったことは、別です。これも観察研究で、著者自身が「もともと品質文化が高いプロジェクトがCIを導入した可能性」を認めています。
設計：人が残る理由は「100倍高い」ではなく「戻せない」
設計を人が持つ理由として、よく「後工程で見つかる欠陥は何十倍、何百倍も高くつく」が使われます。
これを実測で確かめた研究があります。Menziesら（2017, Empirical Software Engineering）が171プロジェクト・47,376件の欠陥ログを調べたところ、先行文献が主張する37倍から250倍という増加は再現されませんでした。
著者らが本文で挙げた最大の伸びは、要件の問題で2.16倍から4.37倍です（原文は「before から結合テストにかけての 2.16 to 4.37 の scale-up」。この2つの値がそれぞれ何を指すかは、入手できたプレプリント版の表からは特定できませんでした）。
留保も書いておきます。対象は規律あるプロセスを採用した組織で、しかも納品前の工程に限られています。本番稼働後は分析対象外です。コストは労力だけで、重大度や金銭は数えていません。著者も「普遍的に誤り」とは主張していません。
それでも、値段を根拠にするのはやめたほうがよさそうです。代わりの基準は、後で出てくる自動化研究の境界になります。設計で人が残るのは高くつくからではなく、そこでの間違いが後ろの工程すべての前提になって、戻すのが難しいからです。
正直に限界を書きます。設計や要件定義をAIに任せた効果を測った査読研究は、今回の探索では見つかりませんでした。この節は解釈です。
ではなぜ「最後に人が見る」で足りないのか
ここまでが現場の実測です。ここから先は、なぜそうなるのかを人間と自動化の研究で見ます。
Vaccaroら（2024, Nature Human Behaviour）が、人間とAIの協働を測った74論文・106実験・370効果量を事前登録つきで統合しました。人間だけ、AIだけ、人間＋AIの3条件が揃っている研究だけを集めたメタ分析です。
結果は、人間＋AIの成績が「人間単独とAI単独の、良かったほう」に対して g=−0.23（95%CI −0.39〜−0.07, p=.005）。組み合わせのほうが低い、という向きです。
g≈0.2は「ちょっと違う」くらいの目盛りです。劇的な悪化ではありません。でも「足せば良くなる」の反対側に、信頼区間ごと収まっています。
逆向きの数字も同じ論文にあります。人間単独と比べれば g=0.64（95%CI 0.53〜0.74）で、AIと組むこと自体は人にとって明確な助けです。効かないのは「人を最後に置けばAI単独より良くなる」のほうでした。
分岐もはっきりしています。
・人間のほうがAIより強い課題では g=0.46（95%CI 0.28〜0.66）
・AIのほうが人間より強い課題では g=−0.54（95%CI −0.71〜−0.37）
この差は統計的にはっきりしています（F(1,104)=81.79, p<.001）。タスクの種類でも分かれ、意思決定タスクは g=−0.27（−0.44〜−0.10）、創作タスクは g=0.19（−0.09〜0.48）で後者は有意ではありませんでした。
つまり「人が入れば安全側に倒れる」は無条件には成り立たない。自分がAIより弱い工程に人として割り込むと、劣化要因になりうる、ということです。
限界も正直に。異質性が極めて高く（I²=97.7%）、効果量の約85%が意思決定タスクのもので、実験室研究が中心です。ソフトウェア開発を扱った研究は、コード翻訳の1本だけです（Weiszら 2022, IUI。370件の効果量のうち6件）。設計・レビュー・デプロイの工程は入っていません。
任せる水準を上げると、正常時だけが良くなる
航空やプラント制御の世界には、自動化と人間の関係を40年測ってきた蓄積があります。
Onnaschら（2014, Human Factors）が18研究を統合し、自動化の程度を上げたときに何が動くかを調べました。
・正常に動いている間の主課題成績：τ=+.51（16研究, p<.001）
・故障して手動に戻したときの成績：τ=−.34（9研究, p=.031）
・状況認識（いま何が起きているかの把握）：τ=−.29（11研究, p=.049）
τはKendallの順位相関で、0.3で中くらい、0.5で大きいくらいの目盛りです。上がるものと下がるものが、はっきり分かれています。
そして、この論文でいちばん効いたのが次の一点でした。自動化が「情報を集めて見せる」段階から「判断と実行そのもの」に踏み込む境界を越えると、両方が増幅します。正常時が τ=+.68、故障後の立て直しが τ=−.90。
得も損も、同じ境界で最大化する。ここが線を引く場所になります。AIに候補を出させるのか、決めて実行までさせるのか。この2つは連続ではなく、段差です。
この構図には名前が付いています。Bainbridge（1983, Automatica）が「自動化の皮肉」と呼んだもので、自動化を進めるほど人間に残るのは監視だけになり、その監視こそ人間がもっとも苦手な仕事だ、という指摘です。理論的な考察で効果量はありません。対象も1983年のプラント制御と操縦室です。
限界。効果量がHedgesのgではなく順位相関なのは、元の18研究の多くが標準化効果量を報告していなかったためだと著者自身が書いています。境界効果は6研究だけの部分集合です。
安定して正しく動くAIほど、見逃しが増える
人が監視役として残った場合、その監視はどのくらい効くのか。
Parasuraman、Molloy、Singh（1993, The International Journal of Aviation Psychology）が、40人に3つの作業を同時にやらせながら、自動化された監視装置の異常を検出できるかを測りました。
自動化の信頼性が常に一定のとき、異常の検出率は平均 33%。信頼性が途中で変動する条件では 82% です。
10回のうち7回近く見逃す、ということです。安定して正しく動く相手のほうが、見逃しが増える。
ただし、この研究のいちばん大事な条件を落とすと誤読になります。監視だけを単独でやらせた条件では、検出率はほぼ天井に達していました。慣れによる見逃しは、他の作業と並行しているときにだけ現れています。
出所について正直に書きます。この原典は購読制で、本文そのものは読めていません。33%と82%という数値は、同じ著者が2010年にHuman Factors誌に書いたレビューが、原典を頁つきで逐語引用している記述から採りました。標準化効果量や検定統計量は確認できていません。
なお、この研究を紹介する情報には「30%と75%」という数値も流通しています。原典の値とは一致しなかったので、ここでは使いません。
水準についてもう1本。EndsleyとKiris（1995, Human Factors）は自動化の水準を5段階に分けて調べ、手動に戻ったときの落ち込みは完全自動の条件で中間の水準よりはっきり大きかったと報告しています。
ただし状況認識は中間の水準でも手動より下がっていて、完全自動ほどではなかった、という差です。中間なら無傷、ではありません。この論文も本文を入手できておらず、著者自身が別の解説で自研究をまとめた記述に依っています。統計量は確認できていません。
誤りが混ざると、AIなしより悪くなる
医療の領域には、もっと直接的なデータがあります。
Goddardら（2012, JAMIA）は13,821本をふるいにかけて74本を採択した系統的レビューです。そのうち設計の揃った4本だけを統合した小さなメタ分析で、誤った助言が出たときの誤判断のリスク比が 1.26（95%CI 1.11〜1.44） でした。さらに前向き研究の一部では、もともと正しかった自分の判断を誤った助言に置き換えた割合が 6〜11% ありました。
Jacobsら（2021, Translational Psychiatry）は臨床医220人を対象に、推奨の正誤そのものを操作しました。
正しい推奨が出たときの正確性は0.384で、助言なしの0.357と有意差はありません（p=0.366）。誤った推奨が出たときは0.299に下がりました（p=0.0018, d=0.16）。
d≈0.16は小さい効果です。でも向きが問題で、「助言なしより悪い」側に落ちています。
そして同じ研究のいちばん嫌な結果がこれです。誤った推奨に、特徴量にもとづく分かりやすい説明を付けた条件が最悪で 0.262（95%CI 0.214〜0.310, t=−3.57, p=0.004） でした。説明が丁寧だと、間違いをそのまま通してしまう。
説明については、ほかの研究も同じ方向を向いています。Bansalら（2021, CHI）が3つのタスクで延べ1,626人を募集した実験では、説明の追加が確信度の表示を有意に上回りませんでした（条件ごとの分析対象は約100人です）。
Schemmerら（2023, IUI）は、AIに正しく従える率が29.59%から38.87%に改善した（p=.05）一方で、自分の正しい判断を守る率は変わらなかった（p=.54）と報告しています。
ひとつ断っておきます。Bansalの実験では、人間＋AIの成績が3つのタスクとも人間単独・AI単独のどちらも上回っていました（原文は「complementary performance on every task」）。人とAIの精度をあえて揃えた設計なので前提は違いますが、「人が入れば必ず落ちる」の反例でもあります。効かなかったのは、説明の上乗せのほうでした。
ここで、証拠の数え方について訂正を1つ書いておきます。
これを「独立した5本の一致」と書くことはできません。Vaccaroは組み入れた74本の一覧を、入手できたプレプリント版には載せていません。ただし論文のデータ公開欄が示すOSFのリポジトリに抽出表が置いてあります。取得して数えると370行（＝効果量）・74本で、そこにBansalも、Jacobsも、Schemmerも、次に出てくるBuçincaも入っていました。
つまりVaccaroは、この4本を内側に含んでいます。4本にVaccaroを足して「5本が一致した」とは数えられません。
さらに4本のうちJacobsとBuçincaは、著者が重なっています（どちらもKrzysztof Gajos氏が入っています）。別チームと言い切れるのは、BansalとSchemmerの2本でした。
では何が効くのか。Buçincaら（2021, CSCW）が199人で試したのは、答えを見る前に自分の判断を書かせる、といった「立ち止まらせる仕掛け」です。AIが誤ったときの過度な依存は、炭水化物源をどれと見たかで測ると0.64から0.48に下がりました（d=.36）。ただし全体の判断で測った過度な依存は0.30と0.26で、有意差がありません。
代償もあります。全体の成績には有意差が出ませんでした。
システムが複雑だという評価は、立ち止まらせる設計で2.95、ふつうの提示で2.64、AIなしで3.19でした。3条件をまとめた検定は有意で（F(2,172.2)=6.19, p=.002）、事後の区分でもふつうの提示だけが最も低い側に入ります。
一方で「頭を使わされた」という負荷は2.84と2.86でほとんど差がなく、AIなしの3.66よりむしろ低く出ています。信頼と、立ち止まらせる設計とふつうの提示のあいだの好みには、有意差がありません。
著者が「効くほど嫌われる」と書いた根拠は、条件ごとの平均ではなく、信頼と好みが誤答時の成績と有意に負相関したという別の分析です。しかも恩恵は「じっくり考えるタイプ」の人に偏っていました。
最後に、支援が技能によって向きを変えるという報告もあります。Povyakaloら（2013, Medical Decision Making）がマンモグラフィ読影者50人を再解析したところ、
識別能力の低い44人は易しい症例で感度が0.016上がり（95%CI 0.003〜0.028）、識別能力の高い6人は難しい症例で感度が 0.145下がって いました（低下の95%CI 0.034〜0.257）。
ここは慎重に読む必要があります。上位群と下位群の分け方が事後的で、著者自身が探索的だと書いています。上位群は6人しかいません。「上手い人ほど支援で下がる」と因果で言い切れる強さはありません。
明日からの線引き：工程ごとに何を人が持つか
研究から引ける線を、工程順に。断定はできないので、判断の材料として書きます。
・設計：人が持つ。理由は費用ではなく、戻しにくさ。前提（誰の何の問題か、何を空白と見なすか）は自分で言い直してから渡す。
・実装：任せる。ただし自分の「安全そう」という感覚を判定に使わない（Perry 2023）。安全性は別の機械に測らせる。
・レビュー：人数と網羅率を増やす前に、議論が発生する形にする（McIntosh 2014）。そして片手間でやらない。並行作業中の監視は、検出率が落ちる前提の条件そのものです（Parasuraman 1993）。
・デプロイ：戻せる操作は任せ、戻せない操作だけ手前に人を置く（Onnasch 2014の境界）。検出器が増えたことを、届く欠陥が減った証拠にしない（Vasilescu 2015）。
・全工程に共通：うまく回り続けている工程を、いちばん疑う。意味を壊した入力を通して、検出できるか試す。
渡す前に確かめるのは3つだけです。
1．この工程では、AIのほうが強いと実際に確かめられているか
2．失敗したとき、AIの自己申告とは別の経路でそれが見えるか
3．間違っても、利用者に届く前に戻せるか
「いいえ」があるなら、人を増やす前に、見える手段か戻す手段のほうを足す。これは査読研究から引いた実務上の目安で、安全を保証する基準ではありません。
ひとつ補足です。ここで引いた医療の研究は、人がAIの助言をどう扱うかを見るために使っています。診断や治療の良し悪しの話ではないので、健康上の判断に使えるものではありません。
最後に。工程の話で使えた実測は、実装とレビューとデプロイの周辺だけです。その外側を説明している中核の証拠は、航空・プラント制御・医療の人間工学研究で、ソフトウェア開発を直接測ったものではありません。工程への当てはめには解釈が混ざっています。
効果量の指標も研究の条件もばらばらで、いちばん大きな相関（τ=−.90）は6研究だけの部分集合から出ています。「これをやれば安全」と言える強さはどこにもありません。
この線引きを実際の仕事に落とすとしたら、次のどれが要りますか。
・A：戻せない操作の棚卸しシート
・B：レビューで議論を起こすための質問リスト
・C：欠陥をわざと入れて検出力を測る手順
コメントはA・B・Cの1文字だけでも助かります。次に何を作るかの順番を、これで決めます。
働き方を科学で見直すシリーズとして続けています。次回も査読論文ベースで書くので、よければフォローしてください。
関連記事を、この記事の続きとして読む順に置いておきます（すべて全文無料）。
1．検証の仕組みをどう作るか。機械チェックとAI審査の二層を99記事に当て直した記録 https://note.com/designing_edges/n/n508f8950ce62
2．レビューの詰まりをどう解くか。大手3社の実装と査読論文17本 https://note.com/designing_edges/n/n49554dffaecd
3．検出力をどう試すか。AIが書いたテストに実装の欠陥20個をぶつけた実験 https://note.com/designing_edges/n/n68361ba4ce2c
参考にした査読論文
本文で使ったのは査読論文20本です。生産性の55.8%短縮のみ未査読のプレプリントで、区別して扱っています。効果量は原論文の実在値だけを転記し、確認できなかったものは本文で「未確認」と書いています。
出典の入手経路についても書いておきます。2本は原典が購読制で本文そのものを読めておらず（Parasuraman 1993／Endsley & Kiris 1995）、数値の出所を本文に明記しました。ほかに3本（Vaccaro・Perry・Menzies）は掲載誌版が購読制のため、同じ著者が公開しているプレプリント版の本文から数値を採っています。
・Perry N, Srivastava M, Kumar D, Boneh D. (2023) Do users write more insecure code with AI assistants? ACM CCS '23:2785-2799. DOI:10.1145/3576915.3623157
・Pearce H, et al. (2022) Asleep at the keyboard? Assessing the security of GitHub Copilot's code contributions. IEEE S&P 2022:754-768. DOI:10.1109/SP46214.2022.9833571
・Sandoval G, et al. (2023) Lost at C: a user study on the security implications of large language model code assistants. USENIX Security 2023. https://www.usenix.org/conference/usenixsecurity23/presentation/sandoval
・McIntosh S, Kamei Y, Adams B, Hassan AE. (2014) The impact of code review coverage and code review participation on software quality. MSR '14:192-201. DOI:10.1145/2597073.2597076
・Rigby PC, Bird C. (2013) Convergent contemporary software peer review practices. ESEC/FSE '13:202-212. DOI:10.1145/2491411.2491444
・Sadowski C, et al. (2018) Modern code review: a case study at Google. ICSE-SEIP '18:181-190. DOI:10.1145/3183519.3183525
・Vasilescu B, et al. (2015) Quality and productivity outcomes relating to continuous integration in GitHub. ESEC/FSE '15:805-816. DOI:10.1145/2786805.2786850
・Menzies T, Nichols W, Shull F, Layman L. (2017) Are delayed issues harder to resolve? Revisiting cost-to-fix of defects throughout the lifecycle. Empirical Software Engineering 22(4):1903-1935. DOI:10.1007/s10664-016-9469-x
・Vaccaro M, Almaatouq A, Malone T. (2024) When combinations of humans and AI are useful: A systematic review and meta-analysis. Nature Human Behaviour 8(12):2293-2303. DOI:10.1038/s41562-024-02024-1
・Onnasch L, Wickens CD, Li H, Manzey D. (2014) Human performance consequences of stages and levels of automation: An integrated meta-analysis. Human Factors 56(3):476-488. DOI:10.1177/0018720813501549
・Bainbridge L. (1983) Ironies of automation. Automatica 19(6):775-779. DOI:10.1016/0005-1098(83)90046-8
・Parasuraman R, Molloy R, Singh IL. (1993) Performance consequences of automation-induced complacency. The International Journal of Aviation Psychology 3(1):1-23. DOI:10.1207/s15327108ijap0301_1
・Parasuraman R, Manzey DH. (2010) Complacency and bias in human use of automation: An attentional integration. Human Factors 52(3):381-410. DOI:10.1177/0018720810376055
・Endsley MR, Kiris EO. (1995) The out-of-the-loop performance problem and level of control in automation. Human Factors 37(2):381-394. DOI:10.1518/001872095779064555
・Goddard K, Roudsari A, Wyatt JC. (2012) Automation bias: a systematic review of frequency, effect mediators, and mitigators. JAMIA 19(1):121-127. DOI:10.1136/amiajnl-2011-000089
・Jacobs M, et al. (2021) How machine-learning recommendations influence clinician treatment selections: the example of antidepressant selection. Translational Psychiatry 11:108. DOI:10.1038/s41398-021-01224-x
・Bansal G, et al. (2021) Does the whole exceed its parts? The effect of AI explanations on complementary team performance. CHI '21. DOI:10.1145/3411764.3445717
・Schemmer M, et al. (2023) Appropriate reliance on AI advice: conceptualization and the effect of explanations. IUI '23:410-422. DOI:10.1145/3581641.3584066
・Buçinca Z, Malaya MB, Gajos KZ. (2021) To trust or to think: cognitive forcing interventions can reduce overreliance on AI in AI-assisted decision-making. Proc. ACM Hum.-Comput. Interact. 5(CSCW1):188. DOI:10.1145/3449287
・Povyakalo AA, Alberdi E, Strigini L, et al. (2013) How to discriminate between computer-aided and computer-hindered decisions. Medical Decision Making 33(1):98-107. DOI:10.1177/0272989X12465490
・補完（未査読）Peng S, Kalliamvakou E, Cihon P, Demirer M. (2023) The impact of AI on developer productivity: evidence from GitHub Copilot. arXiv:2302.06590
探したうえで使わなかった論文も書いておきます。
Skitka et al. (1999) は自動化バイアスの古典ですが、本文とAbstractがどの経路からも取得できませんでした。流通している数値を一次で確認できなかったので採用していません。Vaithilingam et al. (2022) も本文が入手できず、要約由来の数値しかないため使いませんでした。
皮膚科でよく引かれるTschandl et al. (2020) は認証の壁で一次確認ができず、同じ論点をJacobs et al. (2021) に置き換えています。
