Skip to content
←

필사 모드: AI コーディングツールとうまく働くための5つの習慣

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — データは出た、あとは行動だけ

前回の記事 AI は本当に開発者を速くするのか では、よく設計された無作為化比較試験が2つ、正反対の答えを出したという話をしました。一方では開発者が 55.8% 速くなり、もう一方では 19% 遅くなりました。

あの記事が「何が測定されたか」だったとすれば、この記事は 「では明日の朝、何を変えるか」 です。

以下の5つは好みではなくルールです。それぞれ実際の研究から引き出したもので、それぞれが2週間で反証できる1行で終わります。

習慣 1 — 慣れと検証コストでタスクを選ぶ

METR は 19% のスローダウンに寄与しうる要因を5つに絞りました。そのうち2つが 開発者とコードの関係 に関するものです。ひとつはリポジトリへの高い習熟度、もうひとつは暗黙のリポジトリ・コンテキスト — どこにも書かれておらず、モデルが到達できない知識です。

もっとも鋭い発見はこれです。開発者は 自分がよく知っているタスクほど、より大きく遅くなりました。 慣れは盾ではなく税だったのです。

正反対の極に Copilot の実験があります。グリーンフィールドで、仕様が明確で、検証は数秒で終わります。そして得は 経験の浅い開発者でもっとも大きかった のです。

両者を1文に圧縮すると、こうなります。AI は、あなたが持っていないコンテキストを埋めるときに勝ち、あなたがすでに持っているコンテキストに追いつかねばならないときに負けます。 つまり軸は2つです。

検証が安い（秒・分）検証が高い（日・月）
不慣れな領域最適地帯。存分に使ってください。もっとも危険なマス。 理解できないものはレビューできません。
慣れた領域無難。得も損も小さいです。METR のマス。自分で書くほうが速いです。

右上のマスが本当の罠です。ここから出た AI の出力は静かに負債になり、請求書は数か月後に届きます。

ルール: 委譲する前に、2つの問いに1行ずつ答えを書いてください。(1) これが間違っていたら、私はいつそれを知るのか。(2) 私は間違った答えを見抜けるのか。(2) が「いいえ」で (1) が「数か月後」なら、必要なのはツールではなく まず学ぶことです。

習慣 2 — レビューできないものはマージしない

METR の参加者が受け入れた AI 生成コードは 44% 未満でした。 そして 56% が、AI のコードを整えるには大きな修正が必要だったと答えています。生成は安くなりましたが、読み、判断し、捨てる時間はそのまま残ります — 成果物を何ひとつ残さないままに。

2025年の Stack Overflow 調査（AI セクションで数万人規模の回答）が、同じ話を別の角度から語ります。

  • 最大の不満は 66% が挙げた 「ほとんど正しいが、完全には正しくない」 回答です。
  • 2番目は 45.2% で、AI が生成したコードのデバッグのほうが時間がかかる というものです。
  • そして 75.3% が、AI の答えを信用できないときは結局 人に聞く と答えています。

要点はこうです。明らかに間違ったコードは安く弾けます。 高くつくのは、レビューを通るほどもっともらしく、代償を払わせるほど間違っているコードです。つまりレビューは、本当の仕事が終わったあとの雑務ではありません。レビュー こそが 仕事です。

よくある自己欺瞞をひとつ挙げます。モデルに「自分の diff を説明してみて」と言わせるのは検証ではありません。その説明もまた生成物だからです。本当の検証とは、実行し、テストし、あなたが知っている不変条件と突き合わせること だけです。

ルール: 人間が書いた PR に課すサイズ上限を、AI が書いた PR にも同じように課してください。レビュー不可能なほど大きい diff は、マージ不可能な diff です。そしてレビュー時間を、カレンダー上の実際の予算として確保してください。

検証がボトルネックなら、読みやすいコードは趣味の問題ではなくスループットの問題になります — AI が保守するとしても、人間のために書く と LLM バーンアウト で論じたとおりです。

習慣 3 — 散文のルールではなく機械のガードレールを立てる

Anthropic の Building Effective Agents は、ツール設計における ポカヨケ を勧めています。引数そのものを変えて「間違えにくくする」ということです。文書に出てくる例がまさにその精神です — モデルが相対パスを間違え続けるなら、プロンプトで注意するのではなく、絶対パスを要求するようにツールのシグネチャを変える のです。同じ文書は、人間向けインターフェース（HCI）に注ぐのと同じだけエージェント向けインターフェース（ACI）にも投資せよ、そしてツールを実際に動かしてモデルがどんな間違いをするか観察せよ、と述べています。

そこから出てくる原則は単純です。ルール文書の1文は要請であり、失敗する型チェックは事実です。 散文は確率的にしか守られませんが、コンパイラは決定的に守られます。

// 散文のルール: 「通貨に raw number を使わないこと」 -> モデルは守るかもしれないし、守らないかもしれません。
// 機械的ガードレール: そもそも通らないようにします。
type Cents = number & { readonly __brand: 'Cents' }

export function charge(amount: Cents): Promise<Receipt> {
  /* ... */
}

charge(1000) // 型エラー。人間だろうとモデルだろうとここで止まります。
charge(toCents(1000)) // 通ります。

これは AI 時代に生まれた新しい原則ではありません。ただ、コードの生産量が増えたぶん ガードレールの利回りが跳ね上がった だけです。

ルール: 同じ間違いをモデルに2度指摘したら、ルールをもう1行書くのはやめて チェックを1つ作ってください。 型、Lint ルール、テスト、CI ゲート、より狭い関数シグネチャのいずれかに移せば済みます。移せないなら、それはそもそも人間にも守られていなかったルールです。

習慣 4 — すべてではなく、正しい一片を渡す

METR が挙げた要因のひとつが 暗黙のリポジトリ・コンテキスト でした。5年の経験を持つ開発者の頭の中にはあるが、どこにも書かれていない知識のことです。

ここでよくある誤解が始まります。「では全部渡せばいい」。違います。リポジトリのファイルを200個コンテキストに押し込んでも、不変条件を伝えたことにはなりません。 不変条件はたいてい1文で足ります — このテーブルは追記専用である、この関数はトランザクション内でしか呼ばれない、このキャッシュはデプロイ時にクリアされない。200個のファイルはそれを言ってくれませんが、1文は言ってくれます。

Anthropic の文書も同じ方向を向いています。可能なかぎり単純な解から始め、必要なときにだけ複雑さを足すこと、多くの場合は検索と良い例を添えた単一の呼び出しで十分だ、と。コンテキスト・エンジニアリングは より多く入れる技術ではなく、何を外すかを決める技術 です。

ルール: 作業を始める前に、このコードを初めて見る人が破りそうな制約を3〜5個 書き出してください。そのリストがあなたのコンテキストです。書けないなら、あなたは習慣 1 の危険なマスに立っています。

副次的な効果がひとつあります。そのリストはたいてい、そのままチームのドキュメントとして使えます。モデルに説明するために無理やり書き出した暗黙知は、実はあなたの同僚も持っていなかった知識なのです。

習慣 5 — 感覚ではなく自分のスループットを測る

METR でもっとも居心地の悪い数字は 19% ではありません。開発者たちは開始前、AI が自分を 24% 速くする と予測しました。そして実際に 19% 遅くなる経験をしたあとでさえ、自分は 20% 速くなった と見積もったのです。事後の振り返りですら符号が逆でした。経済学と機械学習の専門家の予測も、方向から間違っていました。

理由は平凡です。生成は目に見え、検証は目に見えないからです。 モデルが3秒で40行を吐き出す瞬間は記憶に残ります。それを読んで半分を捨てる20分は、ただ「作業中」としか感じられません。

ですから、このテーマにおいて調査と振り返りはもっとも信用できない道具です。まさにその理由で、DORA や Stack Overflow のような自己申告データも 楽観に傾いていると仮定して読むべきです。

ルール: 2週間、2列で足ります。作業前に見積もり時間を書き、終わったら実際の時間と AI を使ったかどうかを書く。ただし測るのは 「最初の diff まで」ではなく「マージされ安定するまで」 です。「ほとんど正しいが、完全には正しくない」コードの税は、いつも下書きのあとに請求されるからです。

AI が本当に強い場所

この記事が「AI を使うな」と読まれては困るので、得が本物である場所をはっきり書いておきます。

  • 仕様の明確なグリーンフィールド。 Copilot 実験の開発者95人は、JavaScript で HTTP サーバーを書きました。Copilot 群は平均1時間11分、対照群は2時間41分でした。この数字は本物です。
  • 不慣れな言語・API・フレームワーク。 モデルはあなたよりその文書を多く読んでいます。習慣 1 の最適地帯です。
  • 数秒で検証できるもの。 使い捨てスクリプト、スキャフォールディング、テストフィクスチャ、正規表現、データ変換。間違っていればすぐ分かります。
  • 読む方向の仕事。 他人が書いたコードを理解するとき。モデルの主張をその場でコードに突き合わせられるので、検証が安く済みます。
  • テストが厚い領域での機械的な大量変更。 ガードレールがすでに立っている場所です。

そして、経験の浅い開発者ほど得が大きかったという Copilot 実験の結果は、著者らの言うとおり、ソフトウェア開発への転身を目指す人にとって良い兆候です。

これらのルールを過信しないために

METR の限界。 参加者16人、タスク246件、2025年前半のモデル、成熟した大規模オープンソースのリポジトリ。著者ら自身が、この研究は「AI が大半の開発者を速くしない」ことも「既存の AI をもっとうまく使う方法がない」ことも示して いない と明記しています。

さらに重要なのは、METR 自身が設計を変えつつあるという事実です。 2026年2月の続報で、彼らは深刻な選択効果を認めました。時給50ドルを払っても AI なしで働くのが嫌で参加を断った開発者がいたこと、開発者の30〜50%が AI が得意そうなタスクをそもそも提出しなかった こと、そして複数のエージェントを同時に走らせるワークフローでは時間計測自体が壊れたこと。新しいデータはむしろ速度向上を示唆しましたが、METR はそれを「現在の生産性効果についての信頼できない信号」と自ら断じています。

Copilot 研究の限界。 タスクは1つ、グリーンフィールドで、測ったのは完了時間であって品質でも保守性でもありません。著者に GitHub 所属者が含まれることも記録しておく価値があります。

調査の限界。 Stack Overflow は自己申告です。そして METR が示したまさにその理由で、自己申告はこのテーマでもっとも信じがたい計器です。

ですから上の5つは法則ではなく、現時点で入手できる最良の証拠から引き出した経験則 です。あなたのログで反証してみてください。それこそが習慣 5 の要点でもあります。

おわりに

5つを1文に縮めると、こうなります。AI は、あなたが持っていないコンテキストを埋めるときに勝ち、あなたがすでに持っているコンテキストに追いつかねばならないときに負けます。 残る4つは、この1文の運用上の詳細です — その文に合わせてタスクを選び (1)、検証を一級の仕事として予算化し (2)、検証を機械に渡し (3)、コンテキストを圧縮して届け (4)、それが実際に効いているかを測る (5)。

最後にひとつ。この記事のどのルールも、あなたの2週間分のログには勝てません。 5番目の習慣が最後に置かれているのは偶然ではありません。

参考資料

현재 단락 (1/63)

前回の記事 [AI は本当に開発者を速くするのか](/blog/2026-07-12-ai-developer-productivity-reality) では、よく設計された無作為化比較試験が2つ、...

작성 글자: 0자원문 글자: 6,632자작성 단락: 0/63