はじめに
「commit と push は別のコマンドで打つ」。そう規約に書いてあったのに、私は差分を一度も見ないまま push を承認した事があります。規約は破られていません。破られたのは、規約が想定していた形の方でした。
本記事では、生成AI に作業を任せる程人間の側に残る「裁定」という仕事が何であり、それを安く回す為に何を設計したのかを、実際に運用している規約と、そこから切り出した手順書を交えて書きます。
前提を先に置きます。私は、生成AI に開発の作業を任せながら進める時の方法論を、公開リポジトリにまとめています。コードは1行も入っていません。Markdown だけのリポジトリで、書いてあるのは進め方の規律です。
この記事で AI と言う時は、会話で指示を受けて、ファイルを読み書きし、コマンドも実行できる AI（AI コーディングツール）を指します。
そのリポジトリを、AI と一緒に育てています。分担ははっきりしていて、ファイルへの出力と編集は原則として AI 側、私がやっているのは指摘・相談・裁定です。開発環境の構築のように、私が手を動かす場面も残っています。この記事も同じ作り方をしました。文章は AI が書き、どれを採ってどれを捨てるかは私が決めました。
作業が速くなった分楽になったかというと、そうはなりませんでした。増えたのは採否を決める回数でした。AI の出力は、完成した結果としてではなく、採るか捨てるかを決めるべき候補として届きます。候補が十本出れば、九本を捨てる仕事が発生します。
この「採るか捨てるかを決める役割」を裁定と呼びます。上下関係を含む監督とも、正解が事前に決まっているチェックとも違います。AI と人間の双方が主張を出し、どちらが正しいかは事前には決まっておらず、片方が採否を決める。その構造を指します。
書くのは一般論ではなく、実際に運用してみて AI に任せなかった判断は何か、です。
先にお断りしておきます。この記事で数字として扱っているのは、引用する研究と、手元で測った値（ツールの計測値の検証と、指示のファイルの大きさ）だけです。ここで紹介する規約や手順そのものの効果は測っていません。効果測定の代わりに書けるのは、どこで自分が判断すべきかが見えやすくなった、という運用の実感までです。以降の「効いた」は、運用の実感を指します。個別の断り書きは繰り返しません。
先に結論
第1章：何故、AI に任せられると思う程検査は外れるのか
裁定が必要になる理由を先に押さえておきます。AI の出力を確かめる手間は、放っておくと省かれます。しかもその経路は二つあり、向きが逆です。
一つは、速く安く出る場合です。少ない思考量と短い時間で「それらしい成果物」が返ってくる程、確かめる手間は相対的に高く見えます。その場では、中身を読むより、そのまま使う方が安く見えます。間違っていた時の手戻りは後から来るので、比べる時点では見えません。
もう一つは、深く長く考えて出る場合です。推論の過程や説明が豊かな出力程、「これだけ考えたのだから正しいだろう」と受け取られます。検査が省かれる理由が、一つ目とは逆になっています。
どちらの経路にも、外の研究や調査で確かめられている事があります。
速く安く出る経路について。 AI の説明が過信を減らすかを扱った研究は、人が AI に従うかどうかを、自分で課題に取り組むコストと利益、AI に頼るコストと利益のつり合いとして説明しています（Vasconcelos et al., 2023）。後から来る手戻りについては、査読を経た論文ではなく、企業による従業員調査ですが、AI で節約した時間の4割近くが、誤りの修正や書き直し、出力の確認に消えていたという報告があります（Workday, 2026）。
深く長く考えて出る経路について。 AI 支援の意思決定を扱った別の研究は、AI の判断に説明を付けても過信は減らないように見える、という先行研究の知見から出発しています。人は個々の推奨と説明に毎回分析的に向き合うのではなく、「AI に従うかどうか」という大まかな習慣の方を作ってしまう為だ、と考えた上での研究です。効果があったのは説明を増やす事ではなく、AI の推奨を見る前に自分の判断を先に出す、意思決定を意図的に遅くする、といった介入でした（Buçinca, Malaya & Gajos, 2021）。
二つに共通して。 知識労働者319名、実タスク936件を対象にした調査では、生成AI がそのタスクをこなせるという確信（confidence）が高い程、利用者が批判的思考を働かせたと自己申告する程度は低いと報告されています（Lee et al., 2025）。注意したいのは、同じ調査が、生成AI への一般的な信頼（trust）と批判的思考の間には有意な相関を見つけていない事です。効いているのは「AI を信じているか」という態度ではなく、「このタスクは AI に任せられる」という見込みの方だと読めます。
ここから引くのは二点だけです。確かめる手間と頼る手間のつり合いで、検査は省かれうる事。任せられるという見込みと、自分で考えたという自己申告が逆に動く事。研究が述べていない範囲まで広げるつもりはありません。
研究が示しているのは、説明を足すだけでは過信が減らない場合がある（説明が確かめる手間を十分に下げない時）、というところまでです。そこから先は私の見立てですが、モデルを強くしても、思考を深くしても、この問題は解けないと考えています。どちらへ振っても、検査は外れうるからです。寧ろ強いモデル程説明は豊かになるので、二つ目の経路は効きやすくなると考えています。これはモデルの良し悪しの話ではなく、使い方の型の話です。
では検査を増やせば良いのかというと、そう単純でもありません。検査は無料ではないからです。ここに、この記事で一番書きたい非対称があります。生成のコストは下がり続けているのに、検査のコストが同じように下がっている形跡は、少なくとも私の手元では見えていません。この非対称を直接測った研究は、私は見つけられていません。近い数字としては、第5章で扱う比較試験が、画面録画を分析できた課題で作業時間のおよそ 9% が AI の出力の見直しと手直しに使われていたと報告しています。機械学習の研究開発の課題で AI エージェントと人間の専門家を比べた評価では、エージェントは人間の十倍を超える速さで、遥かに低いコストで解を作って試せたと報告されています。但し、時間をかける程得点を伸ばしたのは人間の方でした（Wijk et al., 2024）。速く出る事と、そのまま使える事は別です。生成量が増えれば、検査の総量も増えると考えています。
だから必要になるのは「もっと注意深く見る」事ではなく、どこを見て、どこを見ないかを決める事です。全部を同じ密度で見るのは、量が増えた時点で成り立ちません。何を見ないと決めるかは、成果物の目的を持っている側にしか決められません。これが、以下で書く裁定の中身になります。
この章の判断軸：どこを見ないと決めるか。
第2章：承認と裁定は、何が違うのか
承認と裁定は、似ているようで別物です。承認は Yes か No で終わります。出てきたものを通すか、差し戻すか。裁定はそこに、別案を出すという選択肢と、結果を引き受けるという責任が加わります。
並べると差がはっきりします。
AI が出力を生成し、人間が裁定する。この分担が崩れて「AI が判断し、人間は承認だけする」形になると、成果物は残っても判断の履歴が残りません。動くコードは残ります。何故その設計を選んだのか、どの案を捨てたのかは残りません。これは AI が登場する前からある問題ですが、生成の速度が上がる程早く深刻になる、と私は考えています。捨てた案の数だけ、記録されなかった判断が積み上がるからです。
だから、判断を記録に残す事の方を規律の目的に置いています。ドキュメントを整える為ではありません。半年後の自分と引き継ぐ相手の為に、誰が何を根拠に採ったのかを残します。
具体例を一つ出します。冒頭に書いた commit と push の規約です。AI は staging の対象とコミットメッセージ案を提示して承認を受けてから commit し、push は更に別に承認を求めます。一つのコマンドに繋げません。
二回に分けるのは、commit と push で可逆性が違うからです。commit はローカルに留まり、取り消しが効きます。push は外に出る操作で、戻すには履歴に打ち消しを積むか、強制的に書き換えるしかありません。検査の重さは、操作の非可逆性に合わせます。
そして冒頭の話に戻ります。この規約は、文面の上では一度も破られていません。それでも、規約が守ろうとしていた検査は一度抜けました。コマンドは繋がれていなかったのに、AI が計画の段階で commit と push をまとめて提案し、そこに私が「承認」と返しました。承認は一回に縮み、差分は一度も見られませんでした。規約はコマンドの形だけを塞いでいて、提案の形は素通りだったのです。
直した後の規約はこうなっています。コマンドだけでなく、提案の中でも commit と push をまとめて承認させない。そして、人間の承認の粒度に AI が合わせてはいけない、という一行を足しました。雑に「全部まとめて承認」と言われた時こそ、AI の側から粒度を割る義務があります。
承認と裁定の違いは、その後、規約の形にもなりました。AI が裁定を求める時は案を二つ以上出し、一つしか無いならその理由を書く。一案だけを示すのは、裁定ではなく同意の要求になるからです。
フリーランスとして値付けする立場で言い換えると、納品物を作れる事と、その納品物の採否を引き受けられる事は、別の商品です。実装だけを請けるなら、AI が書ける量が増える程工数は縮みます。一方で、出てきたものを採るか捨てるか決め、その判断の理由を説明し、後から問われた時に答えられる状態にしておくところまでを請けるなら、そこは縮みません。
この章の判断軸：一回当たりで何を見ているか。
第3章：AI に任せなかった判断は、何だったか
ここが本題です。実際に運用してみて、AI に任せなかった判断は三つに絞られました。三つを順に書く前に、AI と協働し始めた頃の実例を一つ置いておきます。三つに共通する形が、最初から出ていたからです。
最初の実例は、AI と協働し始めて二週間も経たない頃のものです。AI 向けの設定を別のマシンへ同期したいと相談すると、AI はその設定を専用のリポジトリへ切り出す案を、手順・除外設定・同期コマンドまで具体化して返してきました。私はその案を採りませんでした。その設定は、別の場所で管理している方法論の要約を出力しただけのもので、正本はそちらにあると考えたからです。AI は「その考え方で良い」と同意しました。
AI の案は誤りではありませんでした。もっともらしく、実行可能で、より複雑だった、というだけです。削ったのは私の裁定でした。半年たって残っているのは、専用のリポジトリではなく、「正本はリポジトリ、手元の設定は展開先」というその時の構造の方です。
どこまで確かめたかを申告させ、採否は自分が持つ
AI の発言を、重要度とは別の軸で仕分けています。「どれだけ確かか」ではなく「どこまで確かめたか」を申告させる軸です。
- 一次ソースまたは実測に到達している
- 裏取りの途中で、要約や二次情報どまり
- 裏取りが未着手で、確かめれば決着する
- 確かめても決着しない（選択・優先順位・トレードオフ）
四つ目を独立させた事が、運用上一番効きました。確かめても決着しないものは、調べても答えが出ません。そこが人間の裁定領域だと自動的に決まります。逆に「未着手」に分類されたものは、AI に調べさせれば良い作業に変わります。判断と作業の境目が、ラベルの側から決まってきます。
自分の運用に入れるだけなら、特別な道具は要りません。最小の手順は次の四つです。
# 確度ラベルを自分の運用に入れる最小手順
1. AI への常設の指示（プロジェクトの説明ファイルなど）に、4つのラベルの定義を書く
実測済み : 一次ソースを読んだ、または実際に測った
裏取り途中 : 要約・二次情報までしか届いていない
未確認 : まだ確かめていないが、確かめれば決着する
判断 : 確かめても決着しない（選択・優先順位・トレードオフ）
2. 「ファイルや設定の目的・状態について述べる時は、ラベルを付ける」と書く
3. 人間は「判断」と「未確認」だけを先に読む
判断 → 自分が裁定する
未確認 → AI に確かめさせてから、もう一度読む
4. 「実測済み」には、読んだ一次ソースの箇所か測った値を添えさせる
根拠が無いもの → 「未確認」として扱う
三つ目の読み方が要点です。四種類全てを同じ密度で読むと、第1章で書いた「全部を同じ密度で見る」状態に戻ってしまいます。
但し、ラベルは AI の自己申告です。額面どおりには受け取りません。AI が「確かめた」と申告した内容が、実際には確かめられていなかった事は、私の運用では何度もありました。厄介なのは訂正の時で、「これは誤りだった、正しくはこうだ」と書かれた訂正文そのものが未検証だった、という事もありました。訂正は確かめた産物の顔をして出てくるので、却って検査が緩みます。
疑う対象は AI の申告だけではありません。ツールが出す数字にも同じ事が起きます。
私が使っている AI コーディングツールには、AI に読み込ませて使う手順書毎に、利用状況（消費したトークン量）を表示する画面があります。値が桁違いに大きく、手順書そのもののサイズとは合いませんでした。この数字を「その手順書のコスト」と読むと、手順書を分けるか統合するかの判断を丸ごと誤ります。
そこで実験にしました。集計値がゼロの手順書を一つ呼び、呼ぶ前と呼んだ直後と、やり取りを終えた後で値を取ります。測る前に、四つの仮説それぞれについて「この場合はいくつになる筈か」を書いて記録に残しました。予測を先に外へ出しておかないと、出た数字に合う説明を後から作ってしまうからです。
結果は三つの仮説を否定しましたが、仕組みの細部までは確定していません。はっきりしたのは、この数字を手順書のコストとして読んではいけない、というところまでです。
裁定の材料が AI の発言だけだと思っていると、この種の誤読は通過します。材料そのものにも、確かめられているものと、確かめられていないものが混ざっています。
図2：確度ラベルが表すのは「どれだけ確かか」ではなく「どこまで確かめたか」です。四つ目に分類されたものだけが、人間の裁定領域として残ります。
初稿を書いた AI を、唯一の裁定者にしない
書かせた AI に、そのまま「これで良いか」と聞きません。初稿を書いた側は、自分の推論を追認しやすいからです。
効いているのは「別のモデルである事」よりも「推論の過程を見ていない目で読む事」だと考えています。
独立性は、コストの順に三段階あります。
- 前のやり取りを見せない新しい会話を開き、対象だけを渡し、前提を追認しないよう明示する
- レビューの観点と出力形式を定型化する
- 別系統の高性能モデルにレビューさせる
第1段階だけでも、独立したレビューの形にはなります。但し、第1段階でどれだけ見つかるかは、まだ確かめていません。複数ベンダーの契約を揃えられないから独立したレビューができない、という事はありません。
第3段階を実行した際に、実際に欠陥が出ました。公開リポジトリのライセンス条項です。散文と、コピーして使ってもらう部分とでライセンスを分けていたのですが、別系統のモデル二つに同じファイルを渡したところ、次の二点が指摘されました。一つは、二つの条項が同じ対象を二重に主張していた事。もう一つは、「著作者表示は不要です」と書いた直後の条文が、実際には著作権表示を要求していた事でした。
説明と条文が正面から食い違っていて、読む側は結局どちらなのか判定できない状態でした。初稿を書いたモデルは、両方とも見つけていません。しかも二つ目の競合は、そのモデル自身の追記が作ったものでした。
指摘を受けて、表示条項を外した版のライセンスへ変更しました。ここで一つ、直感に反する観測があります。採用した修正案は、二つのうち指摘の件数が少なかった方から出ました。件数の多い方は網羅的でしたが、どのライセンスに変えるかという具体的な解決までは出していません。少なくともこの件では、件数はレビューの価値を表していませんでした。
第3段階は、毎回実行しているわけではありません。この件で実行したのは、変更がライセンス、つまり配布の条件に触れるもので、出したあとに戻しにくかったからです。コストも、思っていたより軽いものでした。別系統のモデルには、無料アカウントのブラウザのチャットにファイルを渡しただけで、有償の契約も API の設定も要りませんでした。かかったのは、渡して、返ってきた指摘を読み、採否を決める手間です。但し、この件は公開リポジトリのファイルだったので、そう渡せました。顧客の資料やコードを扱う場合は、渡し先の利用規約と、契約上の守秘義務を先に確かめて下さい。
この件では、第1段階と第2段階を実行せずに第3段階へ進みました。第1段階と第2段階で見つかったかどうかは、確かめていません。それでも、公開した後に配布条件の矛盾が見つかれば、直した記録は履歴に残り続けます。渡して読む手間と比べれば、見合っていたと考えています。
そしてここで任せなかったのは、指摘の採否です。レビュー側が出した指摘を、そのまま反映しません。指摘には、そのまま直せば良いもの、前提を確認しないと直せないもの、書き手の意図を読み違えているものが混ざります。この仕分けは、成果物の目的を持っている側にしかできません。ライセンスの件では、指摘の原文と、変更先のライセンスの条文そのものを私が読んでから採りました。AI は探索を担い、原典は人間が読みます。
同じ事は、AI に手順を書かせた時にも起きます。AI の提案文を私がそのまま指示として返すと、提案に含まれていた誤りごと実行されます。裁定すべきなのは AI の結論だけではなく、AI が作った「手順への翻訳」の方です。
図3：独立性を確保する三段階。
区切りをどこで付けるかは、人間が決める
作業をどこで切り上げるか。ここは分担を明示的に分けています。
- AI は、次の三つが揃った時に、区切りの候補を申告する。着手していた項目が閉じた、記録の書き戻しが残っている、会話が長くなって参照が積み上がっている
- 人間は、終了するか、振り返るか、続けるかを裁定する
理由は単純で、疲労も残り時間も集中力も、AI からは観測できないからです。私は、疲れてきて自分のミスが増えそうだと判断し、切り上げた事があります。これは AI 側からは見えません。
逆の事もあります。記録の書き戻しが残っている事は、人間の感覚では検知しにくいものです。作業に集中している程気づきません。こちらは AI が機械的に判定できます。互いに見えないものを補い合う分担になっています。
運用上の注意が一つあります。申告は提案であって停止ではありません。AI が申告したら人間が答えるまで作業を止める、という形にはしていません。止めると申告そのものが煩わしくなり、やがて無視されるようになるからです。
この申告も、そのまま信じるわけにはいきません。ある時 AI が「会話がかなり長くなっている」という理由を挙げて区切りを提案してきました。実際に消費量を確認すると、まだ十分に余裕がありました。三つ揃った時に申告する決まりなのに、成立していたのは二つだけで、AI は三つ揃ったものとして申告していました。
この時も、私が正解を持っていたわけではありません。持っていたのは、測れる数字を出させるという手順だけです。AI が根拠として挙げたものが測れるものなら、測れば良い。測れないもの（疲労のような）だけが、最初から人間の側にあります。
この線引きには、後から訂正が入りました。私は当初、AI コーディングツールの利用枠（一定時間に使える量の上限）の残りも、AI からは見えないものとして規約に書いていました。実際には、AI も使用量を表示するコマンドを自分で実行して、枠の値を測れました。確かめないまま「測れない」と書いていたわけです。直した後の分担では、AI は枠の値を測って申告に添え、残りの枠を何に使う予定かは私が持ちます。AI に見えるのは値だけで、使い道は見えないからです。枠の値を見た AI が、材料の揃った作業を自分で止めてしまった事もありました。これも、申告は提案であって停止ではない、という線の内側に戻しています。
判断の代行は、規約の内側でも起きました。私は作業の区切り毎に一問だけ、「今回の判断の質は、成果物に残ったか」を確かめる規約を置いています。しばらくの間、この問いに AI が自分の見立てとして答え、記録に書くだけになっていました。問いは私に届いていなかったのです。今は、答えるのは人間で、AI は判断が残った箇所を材料として挙げるだけ、という形に直しています。
図4：出口の分担。AI は測れるものを材料として出し、測れないものを持っている人間が決めます。
三つに共通するのは同じ形です。AI にできるのは判断材料の提供までで、判断の代行ではありません。
この章の判断軸：AI に任せられるのは材料まで。
第4章：裁定を安くするには、何を設計するか
裁定が高く付くのなら、単価を下げる工夫が要ります。実際に置いているのは、問いの立て方と、二つの手順です。
前段：問いの側に条件を入れる
選択肢を並べるだけで答えやすくなる、という話ではありません。問いが「正解は一つ」という前提で立てられていると、現場を知っている人程答えられません。
この記事を書く過程で実演されました。「チームで裁定者が複数いる場合、判断基準がぶれたらどう収束させるのか」という問いに、私は答えられませんでした。出てきたのは「一元論すぎて答えようがない」という反応でした。
同じ内容を、選択肢を並べた上で「現場次第」を正規の選択肢として含む形に組み替えてもらったら、すぐに答えられました。
答えられなかったのは知識がなかったからではなく、問いが条件を落としていたからです。効いたのは選択肢の数ではなく、「現場次第」を答えとして認め、正解は一つという前提を外した事でした。少なくとも私の場合、経験した現場が多い分だけ、条件を落とした問いには答えにくくなっていました。裁定を安くしたいなら、選択肢を用意する前に、問いの側に条件を入れます。
記号一文字で返せる形にする
AI が出す選択肢や指摘には、識別子を振らせています。人間はその記号を返すだけで採否を伝えられます。細かいようですが、入力に変換の手間がかかる文字を使わせないところまでが設計に含まれます。返すコストが上がると、その場で思いついた別案を返すコストも一緒に上がってしまうからです。
記号は英小文字に揃えています。返すコストには、大文字を打つ為の修飾キーも入るからです。指示に書いた例は、規約として読まれます。 その為、この決まりは AI に読ませる指示の文そのものにも当てています。
禁止ではなく、既定の手順にする
私の運用では、「これをやるな」と書いた同じ禁止が、何度も破られました。効いたのは禁止を強める事ではなく、判断の場面そのものを消す事でした。
# 禁止として書いた場合 —— 破られる
禁止: コミットメッセージを複数行の文字列として組み立てて渡すな
# 既定の手順として書いた場合 —— 判断の場面が消える
手順: コミットメッセージは -m を複数指定して渡す
git commit -m "件名" -m "追記行"
下の形にすると、複数行の文字列を組み立てる場面がそもそも発生しません。引用符の書き方を選ぶ必要がないので、選び間違える余地も消えます。commit と push を毎回別のコマンドで打つ、という規約も同じ構造で、繋ぐかどうかを判断する場面を消しています。
規約と既定手順の違いは、その瞬間が来た事を知らせる合図を持てるかどうかに出ます。「気をつける」という規約は、気をつける瞬間が来た事を教えてくれません。手順に埋め込めば、その瞬間が来たかどうかを判定しなくて良くなります。
この考え方を、最近もう一段進めました。検査の手順を、AI に読み込ませて使う手順書として切り出し、名前で呼び出せるようにしたのです。名前そのものを合図にする、という発想です。
# 「push の直前に回す検査」を、手順書として切り出した例（抜粋）
手順:
1. 別環境でクローンした読み手が、次の作業を開始できるかを判定する
2. ファイルを新設・移設・削除・改名したなら、それを指す記述を全て探す
3. この変更に含まれる確度の申告を読み直す
4. 到達点は値ではなく、確かめ方で持つ
（公開するリポジトリでは、初めて読む人の視点・機微な情報・版の要否を加える）
検出したものの扱い:
- 検査で直した分は、別のコミットに分ける
受け入れ基準（この手順が機能したと言える、観測可能な条件）:
- 「次の作業を開始できるか」に答えている（読んだ範囲の報告で終わっていない）
- 参照・時点語・件数の三つ全てに当てた事が、出力から読み取れる
- 確度の申告を一件ずつ読み直した（「問題なし」の一言で済ませていない）
- push の承認を、commit の承認とは別に求めた
ここで効いているのは手順の中身ではなく、受け入れ基準の方です。 「良いレビューをする」は、満たしたかどうかを外から判定できません。判定できない基準は、守った振りを許してしまいます。だから「何を見たかを列挙してから判定したか」のように、出力を見れば真偽が決まる形に落としています。
実際、この受け入れ基準は自分自身に対して働きました。AI が検査を回したと申告しながら、手順書が求める列挙を飛ばしていた事が、私が別の確認を回させた時に見つかっています。手順を持つ事と、手順を回した事は別で、後者は受け入れ基準がないと検査できません。
そして、規律は足す程良いものではない
検査を増やせば、摩擦は必ず増えます。しかも効き方には個人差があります。第1章で引いた Buçinca らの研究でも、判断を意図的に遅くする介入は過信を減らした一方で、利用者の満足度を下げ、認知的な努力への動機づけが高い人程良く効いたと報告されています。良い規律を並べれば全員に同じだけ効く、という前提が既に成り立っていません。
だから、追跡する改善項目を常時二件までに制限し、超えたら捨てています。追跡されない改善は、無い改善と同じだからです。条件を満たした規律は卒業させます。卒業は外す事ではなく、常設の規約へ移す事です。例えば、裁定を求める文に記号と二つ以上の案を付ける、という改善項目は、記録から数えて条件を満たした事を確かめてから、常設の規約に移しました。増やす事より、二件を確実に検証する事を選んでいます。
とはいえ、改善項目を二件に絞っていても、常設の規約そのものは増え続けています。AI に毎回読み込ませる指示のファイルは、公開した最初の版から現在の版までで、およそ 2.6 倍になりました。それでも私の環境では、これは費用の問題になっていません。毎回同じ指示を読み込ませる使い方は、使っているツールのプロンプトキャッシュ（同じ指示の読み込みを安く済ませる仕組み）が良く効く形で、モデルの版が上がって消費量が下がる方向に動いた事も重なりました。定額のプランで使っているので具体的な数字は出しにくいのですが、利用枠の残りを見ながら回せています。調べものを別の AI に並行して任せるようになってからは、キャッシュが効く割合は下がりました。これは、成果物の速度を優先して私が選んだ事です。費用の問題になっていないのは、定額のプランとプロンプトキャッシュに依る部分が大きく、従量課金で使う場合には当てはまらない可能性があります。一方で、常設の規約を外す手順は、まだ持っていません。規約が増えた分だけ人の側の摩擦が増えていないかも測れておらず、ここは未解決です。
この章の判断軸：判断の場面を消せるか。
第5章：この規律が効く条件と、崩れた時に何を足すか
ここまで書いた規律は、ある条件の上で成り立っています。条件を先に出しておきます。
- 裁定する人が一人である事
- 既存の統制の仕組み（自動テスト、プルリクエストのレビュー、コード所有者の指定）が薄い事
- 成果物の目的を持っている人と、裁定する人が同一である事
- 記録が、飾りではなく実際に読み返される正本である事
四つとも、崩れます。そして崩れ方によって、足すべきものと捨てるべきものが変わります。条件毎に、外の資料と私の経験を並べます。
裁定する人が複数になった時
ここは経験の幅で答えが割れるところで、単一の正解は出せません。その上で、外の資料には二つの型があります。
一つは、決める人を一人に絞らず、決める前に聞く範囲を広げる型です。Andrew Harmel-Law が Martin Fowler のサイトに寄せた、アーキテクチャの意思決定を扱った記事は、「誰でも決定して良い」というルールを置き、そこで求めているのはコンセンサスではなく、幅広い入力と多様な声だと書いています。
もう一つは、意見が割れた時の優先順位を先に決めておく型です。Google のコードレビューの基準は、技術的な事実とデータが意見や個人の好みに優先するとし、複数のやり方が同等に有効だと示せるなら、レビュアーは作者の好みを受け入れるべきだとしています。
但し、どちらの型も、置いただけでは崩れます。日本のスポーツの判定には、その実例が公開されています。陸上の日本選手権（2019年）では、機械による不正スタートの判定を目視より優先する、という優先順位が規則で決まっていました。それでもスターターは目視を優先して選手を失格にし、審判長もその判定を最終としました。誤りが認められたのは大会の後、競技運営委員会が検証し直してからです（日本陸上競技連盟, 2019）。バレーボールの SV リーグ（2025年）では、審判が出した罰則が記録の担当に共有されず、得点の加算が漏れました（スポーツニッポン, 2025）。裁定する人を増やしても、優先順位が守られず、事実が共有されなければ、誤りは収束しません。
私が経てきた複数の現場のうち、大半に共通していたのは、その場で基準を決めるのではなく、基準を合意する場を予め置いておくという形でした。私が関わった現場のうち、うまく回っていたところの多くはアジャイル、スクラムで開発していて、合意の場は既にイベントとして組み込まれています。裁定の基準がぶれた時に新しい会議を作る必要はなく、既にある場に載せられます。足すのは裁定者毎の規律ではなく、優先順位と合意の場です。合意の場は、作業を始める前に開いておかないと効きにくい、と考えています。
ここで、うまくいかなかった例も置いておきます。この記事そのものの作り方です。
私は、この記事がどういう基準で評価されるのかを、書き始める前に確かめていませんでした。基準はレビューの段階で初めて言葉になり、そこから合わせて直す往復が生まれました。その間にも、記事の素材である私の運用は更新を続けていました。指摘する側と書く側の前提が、往復の間にそれぞれ動いていた事になります。この往復は、この節を書いた時点でも閉じていませんでした。基準を合意する場を先に置く、と書いた本人が、自分の記事ではそれをしていませんでした。
似た事は、AI を複数並べて同じ仕事を任せた時にも起きました。同じ調査を二つのモデルに別々に任せたところ、より丁寧に調べた側が、記録に残っていない事実について言い切った結論を出しました。どちらが正しいかは、その時の事情を覚えている私にしか判定できませんでした。AI を増やしても、文脈を持つ人がいなければ、正しい側に収束するとは限りません。
公開しているガイドには、この種の失敗を前提にした一文を置いています。人も AI も必ず間違える前提で組み、規約は AI だけでなく、使う人間（私を含む）にも掛ける。どちらかを間違えない側に置くと、その側の誤りは検査されないまま外に出るからです。規律は、慣れたら外す補助輪ではありません。私はそれを矯正ギブス（外せない規律）と呼んでいます。
既存の統制が厚い時
自動テストやプルリクエストのレビューが機能している現場に、この記事の枠組みをそのまま持ち込むと二重管理になりえます。
一方で、統制が厚い現場の既定値は、既に「AI の承認は人間の承認の代わりにならない」側に倒れている事があります。GitHub の公式ドキュメントは、AI によるレビューは既定では、プルリクエストに必要な承認の数に算入されないと書いています。
更に、レビューの役割は欠陥を見つける事だけではありません。Bacchelli と Bird のコードレビューの研究は、欠陥の発見はレビューの主な動機であり続けているものの、実際のレビューは予想程欠陥に関するものではなく、知識の移転、チームの状況把握、問題への別解の創出といった効果をもたらしていると報告しています。
この二つを合わせると、統制が厚い現場で捨てるべきなのは、この記事の規律を別の仕組みとして並べる事です。足すとすれば、既にあるレビューの中に「何を採り、何を捨て、何故そうしたか」を残す事の方だと考えています。
目的を持つ人と裁定する人が分かれる時
「何を見ないか」を決められるのは目的を持っている側なので、ここが分かれると、裁定は形だけ残って中身が抜けます。
責任の所在について、Microsoft は開発者向けのガイダンスで、AI エージェントが生成したコードもあなたが出荷するコードであり、どう書かれたかに関係なくアプリケーションの全てに責任を負うと書き、受け入れる前に全ての変更を読んで理解するよう求めています。
裁定する人が目的を持っていないなら、足すべきなのは裁定の手順ではなく、目的を持つ人へ判断を戻す経路です。読んで理解する責任は、裁定を代わりに回す人へは移せません。
記録が読み返されない時
判断を残す規律は、読み返される前提が崩れると、単なる作業の増加になります。ここは外の資料を当てていません。私の運用では、記録を読み返しているのは主に AI で、私自身が読み返すのは判断に迷った時だけです。読み返す手順が無い記録は、捨てる候補です。
そもそも「速くなる」前提が崩れる時
最後に、この記事の出発点そのものへの反証を置いておきます。この記事は「生成は安く速くなった」を前提にしています。
METR のランダム化比較試験は、経験のあるオープンソース開発者を対象に、AI の使用を許可すると作業の完了時間が 19% 増えた、つまり遅くなったと報告しています。但し研究した側自身が、この結果を「ある状況における、2025年初頭の AI の能力のスナップショット」と位置づけています。更にその後、参加者の選択効果が深刻だとして、実験の設計を変えていると公表しています。
一方で、速くなったという比較実験もあります。新しく HTTP サーバーを書く課題では、AI のコード補完を使えた側が 55.8% 速く終えました（Peng et al., 2023）。Google のエンジニア 96 名が企業規模の複雑な課題に取り組んだ実験では、作業時間がおよそ 21% 短くなりました。但し、信頼区間は広いとされています（Paradis et al., 2024）。METR は、自分たちとの違いが出た理由の仮説の一つとして、対象が平均10年・110万行を超える、大きく複雑なリポジトリだった事を挙げています。
ここから引くのは、速くなるかどうかは条件次第で、しかも測り方そのものが難しい、というところまでです。その上で、この結果は、この記事の主張と矛盾するとは限りません。論文は遅くなった要因の候補の一つに AI の出力の信頼性の低さを挙げ、開発者が受け入れた生成は 44% 未満、画面録画を分析できた課題では作業時間のおよそ 9% が AI の出力の見直しと手直しに使われていたと報告しています。METR の 19% がこれで説明できると示されたわけではありませんが、生成が安くなっても、確かめて採否を決める仕事がそれを上回れば、全体は却って遅くなります。少なくとも、見直しと手直しに使われた約 9% は、この記事でいう裁定のコストに近いものです。
この章の判断軸：その規律の前提は、まだ生きているか。
第6章：この記事自体、どう作られたか
冒頭に書いた通り、この記事も AI と協働で書きました。その過程で起きた事を書いておきます。記事の主題そのものだからです。
第5章の外の資料は、私が四つの生成AI に同じ依頼文を渡して探させたものです。依頼文は手元の AI が起草し、URL と原文の引用を必ず持ち帰るよう指示しました。要約ではなく原文を持ち帰らせれば、確かめられると考えたからです。
四本の結果を並べると、原文の引用そのものが割れていました。同じ標準文書の同じ一文が、AI によって二通りの英文で返ってきたのです。少なくとも一方は誤引用です。ある文書テンプレートの URL も、二通りに割れていました。
一本ずつ読んでいたら、どちらも「原文を引用した、確かめられた情報」に見えた筈です。この回に限って言えば、複数の AI に探させて役に立ったのは、網羅ではなく、食い違いを見つけられた事でした。
そして、食い違いを見つけた後の仕事は減りませんでした。どちらが正しいかを決める為に、手元の AI に原典を取得させて逐語で照合させ、決着しなかった一文は記事に使わないと決めました。原典との照合そのものは AI に任せており、第3章で書いた確かめ方より一段緩いやり方です。第5章に残っているのは、原典で一致を確かめられた資料だけです。
生成は安くなりました。調査結果は、依頼文を渡すだけで返ってきます。一方で、突き合わせ、原典に当たり、使うか捨てるかを決める仕事は、私の側に積み上がりました。この記事のタイトルは、書いている私自身にも当てはまっていたわけです。
この章の判断軸：確かめるのは突き合わせと原典。
おわりに：値が付くのは、採否を引き受けられる事
AI が安くしたのは、作業の方でした。作れる事は、以前より速く証明できるようになりました。一方で、出てきたものを採るか捨てるか決め、その結果を引き受ける役割は、少なくとも私の手元では、まだ AI に渡せていません。
規模の話をしておきます。ここで書いた規律は、開発の速度を上げる為のものではなく、後から入る人が同じ判断をやり直さずに済むようにする為のものです。判断の跡が無いまま人が増えれば、やり直しの総量も増えていくと考えています。
独立を考えている人にとって、これは価格設定の話に直結します。作れる事を売るのか、採否を引き受けられる事を売るのか。裁定が高く付くようになった以上、それを引き受ける事に値を付けられる余地はある、と私は考えています。但し、受託では成果物の目的を持っているのは多くの場合発注者です。その時に請けられるのは採否そのものではなく、発注者が採否を安く下せるように材料と選択肢を整え、判断の理由を残すところまでです。
参考資料
- Vasconcelos, H., Jörke, M., Grunde-McLaughlin, M., Gerstenberg, T., Bernstein, M. S., & Krishna, R. (2023). Explanations Can Reduce Overreliance on AI Systems During Decision-Making. Proceedings of the ACM on Human-Computer Interaction（CSCW 2023・査読付き）.
- 過信を、自分で課題に取り組むコストと利益、AI に頼るコストと利益のつり合いで説明し、説明が確かめる手間を十分に下げないと過信は減らない可能性を示した研究。
- Workday. (2026). New Workday Research: Companies Are Leaving AI Gains on the Table. プレスリリース（企業の調査・査読なし）.
- 企業による従業員調査。AI で節約した時間の4割近くが、誤りの修正・書き直し・出力の確認といった手戻りに消えていたと報告。
- Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. CSCW 2021（査読付き）.
- AI の判断に説明を付けても過信は減らず、推奨を見る前に自分で判断させるなど、考える事を強いる介入の方が過信を減らしたという研究。
- Lee, H.-P. (Hank), Sarkar, A., Tankelevitch, L., et al. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI 2025（査読付き）.
- 知識労働者319名への調査。生成AI がタスクをこなせるという確信が高い程批判的思考を働かせる程度が低く、批判的思考の中身は検証・統合・監督へ移ると報告。
- Wijk, H., Lin, T., Becker, J., et al. (2024). RE-Bench: Evaluating frontier AI R&D capabilities of language model agents against human experts. ICML 2025（査読付き）.
- 機械学習の研究開発の課題で、AI エージェントは人間の専門家の十倍を超える速さで、遥かに低いコストで解を作って試せる一方、時間予算を増やした時の伸びは人間の方が大きいと報告。
- Harmel-Law, A. (2021). Scaling the Practice of Architecture, Conversationally. martinfowler.com.
- 誰でもアーキテクチャの意思決定をして良い代わりに、決める前に影響を受ける人や専門家へ助言を求める「Advice Process」の解説。
- Google. The Standard of Code Review（Google Engineering Practices）.
- コードレビューで意見が割れた時は技術的な事実とデータを優先し、同等に有効なら作者の選好を受け入れる、という基準。
- 日本陸上競技連盟. (2019). 第103回日本陸上競技選手権大会女子100mハードルの不正スタートの誤判定について.
- 機械による判定を最優先すべきところを目視が優先され、大会後の検証で失格を取り消した経緯。
- スポーツニッポン. (2025). バレーボールSVリーグが誤審認め謝罪 PO準決勝でルール適応に誤り.
- リーグの発表の全文を掲載。レフェリーが出した罰則が記録の担当に共有されず、得点の加算が漏れた経緯。
- GitHub Docs. Using GitHub Copilot code review on GitHub.
- AI によるレビューの使い方の公式ドキュメント。既定では、AI のレビューはプルリクエストに必要な承認の数に算入されない。
- Bacchelli, A., & Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. ICSE 2013（査読付き）.
- Microsoft の開発者の観察・インタビュー・調査から、レビューの動機は欠陥の発見でも、実際の効果は知識の移転・チームの状況把握・別解の創出にも及ぶと報告。
- Microsoft Learn. Security and responsible AI for Windows development.
- AI の支援で開発する時の注意。AI が生成したコードも出荷する側が責任を負い、受け入れる前に全ての変更を読んで理解するよう求める。
- METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（論文・プレプリントで査読前）／同名の解説記事.
- 経験のあるオープンソース開発者のランダム化比較試験で、AI の使用を許可すると完了時間が19%増えたという結果と、それが特定の状況のスナップショットだという留保。
- METR. We are Changing our Developer Productivity Experiment Design.
- 参加者の選択効果が深刻だとして、実験の設計を変えるという研究主体自身の説明。
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. プレプリント（査読前）.
- JavaScript で HTTP サーバーを書く比較実験で、AI のコード補完を使えた側が55.8%速く終えたと報告。
- Paradis, E., Grey, K., Madison, Q., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial. ICSE 2025 SEIP（査読付き）.
- Google のエンジニア96名のランダム化比較試験で、企業規模の複雑な課題の作業時間がおよそ21%短くなった（信頼区間は広い）と報告。