- Authors
- Name
- Youngju Kim
- @fjvbn20031
うまく使う、が空っぽな理由
道具をうまく使う、という言い方はそれ自体には情報がありません。何を委ねたのか、結果が正しいかをどう確かめたのか、誤っていたとき何へ戻ったのかが抜けているからです。この三つが無い状態では、うまくやったのと運が良かったのを区別できません。
だからこの回は道具の話をしません。どの製品がどの製品より良いという話は半年で古び、古びないのは働き方です。扱うのは三つです。どこまで委ねるかを決める基準、返ってきた結果を判定する手順、そしてその二つを省いたときの損です。
線を引くのは難易度ではなく検証費用です
よくある基準は、易しいものは委ね、難しいものは自分でやる、というものです。このシリーズの判別式で見ると、その基準は軸を取り違えています。委譲の可否を決めるのは作る費用ではなく判定する費用です。
三つ当ててみると直観がいくつかひっくり返ります。
- 厄介な正規表現を一つ: 作るのは面倒で判定は安い。例を十個当てれば正しいか分かります。委ねやすい側です。
- 設定値を一つ変える: 作るのはほぼ無料で判定は高くなりえます。誤った値は本番で数週間後に出ます。
- データ移行スクリプト: 作るのは簡単に見え、戻すのは難しい。判定費用は事実上の最大です。
三つめが要点です。戻せない作業は、生成がどれだけ安くても委譲の候補ではありません。戻せるかどうかは難易度と何の関係もなく、だから難易度で線を引くとちょうどこの枡で事故が起きます。
委ねる前に書く四行
基準を実際の作業に当てる方法は単純です。委ねる前に四行を書きます。
例 — 委譲カードの四行
委ねる: 決済失敗のリトライ処理の下書き
判定方法: 既存の結合テスト + 二重請求のシナリオ3件を自分で追加
戻し方: フィーチャーフラグの裏で動作。切れば以前の経路へ戻る
委ねない: リトライ上限と冪等キーの設計。誤ると金が二度出る
書くのに二分かかります。値打ちは二行目と四行目にあります。判定方法が書けないなら、その作業はまだ委ねる準備ができていません。委ねないが空なら、たいてい境界を引いていません。
返ってきた結果を判定する手順
結果の扱いで最もよくある失敗は、読む順序です。結果を先に読むと、人はその結果を基準に自分の期待を作り直します。結果がもっともらしいほど、この上書きは強くなります。
順序を変えます。開く前に期待を三行書きます。どのファイルが変わるべきか、どの境界条件が扱われるべきか、何が変わってはいけないか。それから結果を開いて突き合わせます。一覧に無かった変更が、最初の質問になります。
二つめは、通過を根拠にしないことです。第4回で、緑はそれ自体では何も意味しないと書きました。ここではなおさらです。成果物とそれを検査するテストを同じところから受け取れば、判定される対象と判定する基準が同じ出所から出ます。境界条件は最低一つ、手で入れる必要があります。
三つめは、説明を求めつつ証拠として数えないことです。なぜこうしたのかへの滑らかな答えはいつでも出てきますし、滑らかさと正確さの相関は弱い。説明はどこを確かめるかを決めるのに使い、確認そのものは実行とログで行います。
むしろ遅くなる場所
体感はこの領域でとくに当てになりません。METRが2025年7月に公開した無作為化対照試験がその例です。自分のオープンソースのリポジトリに慣れた開発者16名が246件の課題に取り組み、課題ごとにAIツールの使用可否が無作為に割り当てられました。使用が許された側は19パーセント長くかかり、参加者は事前に24パーセント速くなると予想し、事後にも20パーセント速くなったと信じていました。
一般化してはいけません。著者たち自身が、これは大半の開発者が遅くなるという証拠ではなく、別の環境やより熟達した使い方には当てはまらないかもしれないと明記しています。標本は16名です。ただし条件が一つ目を引きます。参加者は自分が長く扱ったリポジトリで、品質基準の高い状態で働いていました。検証費用がもともと高い環境だったということです。
Stack Overflowが2025年に公開した開発者調査も同じ方向を指します。最大の不満として、ほぼ正しいが正確ではない解答を挙げた回答が66パーセント、45.2パーセントが生成されたコードのデバッグに時間がかかると答えました。正確さについては、ある程度以上不信という回答が45.7パーセントで、信頼するという32.7パーセントより多い。調査は体感の記録であって成果の測定ではないので、読めるのは人々がどこに時間を使っていると報告しているか、までです。
ここから繰り返し現れるパターンを整理すると四つです。検証費用の高い領域で委譲を増やすこと、ほぼ正しい結果を直す時間を過小評価すること、理解を飛ばして入れたコードが数か月後にデバッグ対象として戻ってくること、そして生産量がチームのレビュー容量を超えることです。最後の一つが最も静かに進みます。
まだ定まっていないこと
正直に書けば、この領域で確かなことは多くありません。確かなのは二つです。生成の費用が大きく下がったこと、そして検証の費用は一緒には下がらなかったことです。
残りは開いています。どの種類の作業で純益が出るのか、熟達が積もれば結果がひっくり返るのか、組織の水準で何が変わるのかは、まだ答えが定まっていません。この場で確信に満ちた文を売る側は、たいてい何かを売っているか、怖がらせています。
だから個人にできる最も合理的なことは、自分の記録を持つことです。自分の作業については標本が自分自身であり、その標本は他人の平均より自分に対して正確です。
手を動かす
今週委ねた作業を三つ選び、それぞれについて結果が正しいか確かめるのに実際に何分使ったかを書いてみてください。作る時間ではなく判定する時間です。この数字が自分の委譲の線を教えてくれます。作るより判定に時間がかかった作業があるなら、その種類は次から自分でやったほうが速い。
- ハーネスエンジニアリングRPG — モデルを固定入力として置き、その周りの道具・停止条件・権限・評価者を設計する27のシナリオです。弱い評価者がその下すべての上限になることをデブリーフで確かめられます。この記事の判定手順と同じ構造です。
- 論理トレーニング — 必要条件と十分条件を分け、他人の論証を正確に再構成する練習です。もっともらしい説明を証拠として数えない訓練に最も近い。
通じない場合も書いておきます。いま学んでいる領域では、この基準を逆に使う必要があります。判定が安く委ねてよい作業でも、それが自分が今身につけようとしている技術なら、自分でやるほうがよい。第3回で書いたとおり、読む練習も書く練習も自然には生まれず、委譲はその機会を真っ先に持っていきます。
続けて読む
- このブログの関連記事: AI コーディングツールとうまく働くための5つの習慣
高いまま残る技術シリーズ
参考資料
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 2025-07-10 — 開発者16名・課題246件の無作為化対照試験、19パーセントの遅れ、事前予想24パーセント短縮、事後の体感20パーセント短縮、そしてこれが大半の開発者に一般化しないという著者たちの明示的な但し書きがここから来ています。2026-08-15閲覧。
- Stack Overflow Developer Survey 2025 — AI — ほぼ正しい解答66パーセント、デバッグ時間の増加45.2パーセント、正確さへの不信45.7パーセント対信頼32.7パーセント。2026-08-15閲覧。
- 委譲カードの四行、判定手順の三段階、遅くなる四つのパターンは上記資料にあるものではなく、この記事でまとめたものです。