AI とのペアプログラミングは、人間の同僚と組むときと似ているようで勝手が違います。最大のコツは、ふたつの極端を避けること——仕事を読まずに「全部やっといて」と渡す丸投げと、出てきたコードを読まずにそのまま採用する丸呑みです。2026 年の AI コーディングは、指示を出すと数分〜数時間まとめて動く「エージェント」が主流になりました。一気に進む分、丸投げと丸呑みの代償も大きくなっています。この記事は、初めて AI と組む人でも今日から使える具体的な進め方を、図とともに整理します。
FIG.1 丸投げ＝読まずに任せる／丸呑み＝読まずに採用。どちらも「読む」が抜けている
01ふたつの失敗パターン
失敗の多くは、根っこをたどると次のどちらかに行き着きます。共通点は「人間が中身を読んでいない」こと。AI を navigator（方向を決める人間）と driver（コードを書く AI）のペアと考えると、navigator が地図を見ずに「あっちへ」と言い続けるのが丸投げ、driver の運転を確認せず助手席で寝てしまうのが丸呑みです。
| 丸投げ症候群 | 丸呑み症候群 |
|---|---|
| 「全部やっといて」と一度に頼む | 出てきたコードを読まずに採用する |
| ゴールや制約を伝えていない | 「動いた」だけで品質を確認しない |
| 起きること：仕様の取り違え、勝手な前提、頼んでいないリファクタ | 起きること：バグ、脆弱性、不要な依存追加、意味のないコメント |
2026 年はこの代償が見えやすくなりました。複数の調査で、AI が生成したコードの3〜5 割に何らかのセキュリティ上の問題が含まれると報告されています。丸呑みは「速いけれど、あとで高くつく」進め方になりがちです（具体的な数字は調査ごとに幅があり、状況によって変わります）。
02うまくいく進め方の原則
丸投げと丸呑みの反対は「小さく渡して、読んで、確かめる」。次の 5 つを習慣にすると、AI の速さを保ったまま事故を減らせます。
タスクを小さく分ける
「機能 X を全部実装」ではなく「① 型定義 → ② コア関数 → ③ エラーハンドリング → ④ テスト」と段階に割る。各段階で確認・修正できるので、ズレても傷が浅いうちに直せます。
コンテキストを共有する
このプロジェクトが何を目指し、なぜこの設計なのかを AI に伝える。Claude Code の CLAUDE.md や Cursor の Rules ファイルに書いておけば、毎回説明し直さずに前提を共有できます。
先に計画を話させる
実装の前に「まず計画を立てて。ファイル構成・データの流れ・考慮すべき例外を箇条書きで」と頼む。設計の段階なら、書き直しゼロで軌道修正できます。
コードを読む
採用するコードは全部読む。分からない箇所は「ここは何をしている？」と AI に説明させ、自分が理解できたものだけ採用します。読まずに通すと丸呑みに逆戻りします。
テストで担保する
AI はテストと相性が抜群。先にテストを書き「これが通るように実装して」と頼むと、AI 自身が失敗を見て直してくれます。テストがないと AI も自分も「本当に動くのか」を確かめられません。
FIG.2 大きく一発ではなく、小さい単位で①〜④を何周も回す
03頼み方のフレーズ集
同じ作業でも、頼み方しだいで結果が変わります。段階ごとに「型」を持っておくと、毎回考えずに丸投げ・丸呑みを避けられます。
計画段階
「機能 X を実装したい。まず計画を立てて。ファイル構成・データフロー・考慮すべき例外を箇条書きで」
実装段階
「計画 OK。まずファイル A だけ実装して。B と C には触らないで」と範囲を限定する。
確認段階
「このコードの問題点を 5 つ指摘して。なければ『ない』と返して」と自己点検させる。
テスト段階なら「このコードのテストを書いて。正常系・異常系・エッジケースを各 1 つ以上」。Claude Code には、まず読み取り専用で計画だけ立てるプランモードもあります。設計を詰め切ってから実行に移すほど、後戻りが減ります。ただし、変更内容を一文で言い切れるような小さな作業まで毎回計画させると、それはそれで遅くなります。計画が要るかどうかも、タスクの大きさで判断しましょう。
04避けたほうがよい依頼
次の言い方は、AI に「勝手に解釈してよい」という余白を与えてしまいます。丸投げの典型なので、ゴールと範囲を添えて言い換えます。
- 「いい感じに」 → 何をもって良しとするかが伝わらない。期待する挙動を一文添える。
- 「全部直して」 → 範囲が広すぎる。対象ファイルや対象の不具合を明示する。
- 「最適化して」 → 速度なのか可読性なのかメモリなのか不明。指標を決める。
- 「リファクタして」 → ゴールが曖昧。「この関数を 50 行以内に分割」のように到達点を示す。
05AI の「迷い」と「過信」を読み取る
AI は表情こそありませんが、出力に状態が表れます。サインを読めると、丸投げ・丸呑みのどちらに傾いているかを早めに察知できます。
| 迷っているサイン（＝情報不足） | 過信しているサイン（＝検証不足） |
|---|---|
| 「〜と思います」が頻発する | 動かさないまま「完成」と言う |
| 同じファイルを何度も読み直す | 使ったことのない API を堂々と呼ぶ |
| 仕様についての質問が増える | 存在しないライブラリ名を提案する |
| 対処：前提・制約・具体例を足す | 対処：「実際に動かして確認して」と要求する |
AI の品質は、モデルの賢さよりも 「人間がどこで読むか」 で決まる。
Review & Security
「動く」と「安全」は別物——とくに依存追加に注意
丸呑みで一番こわいのは、目に見えにくいセキュリティ事故です。2026 年に増えているのが、AI が実在しないライブラリ名を提案するケース。報告によっては、提案されるパッケージの 2 割ほどが架空だとされます。架空の名前を悪意ある第三者が先回りして本物として登録し、利用者が npm install や pip install で取り込んでしまう——という攻撃（俗にスロップスクワッティング）が現実に観測されています。
FIG.3 提案された依存は、入れる前に必ず「実在するか・配布元は正しいか」を確認
対策はシンプルです。知らないライブラリ名が出てきたら、入れる前に公式レジストリで実在と配布元を確かめる。AI 生成コードもレビュー対象として扱い、権限まわり・入力検証・秘密情報の扱いは人間が目を通す。料金やセキュリティの前提は変わりやすいので、断定せず一次情報で確認する姿勢を保ちましょう。
06セッション中の振り返り
エージェントは長く走るほど、最初の意図から少しずつズレることがあります。区切りで現在地を確認すると、迷子になりません。
- 30 分ごと：「ここまでの変更を要約して」——意図とのズレを早期に発見する。
- 1 時間ごと：「コミットしたい区切りはどこ？」——戻れる地点を作っておく。
- セッション終わり：「次にやる TODO を 5 つ挙げて」——次回の立ち上がりを速くする。
07チームと長期の習慣
個人の作法が固まったら、チームに広げると効果が増します。属人化を避け、AI 出力の品質を全員でそろえるのが狙いです。
- AI が生成したコードもレビュー必須。人間のコードと同じ基準で見る。
- プロジェクトの規約を
CLAUDE.mdや Rules に書き、全員の AI 出力の前提をそろえる。 - うまくいったプロンプトを記録し、定型作業はチーム共有の手順（スキル）にする。
- 悪い AI 生成例も共有し、チームの学習材料にする。
そして長期的には、毎日少しでも AI と一緒に手を動かすのが一番の上達法です。どんな頼み方だとうまくいき、どこで読むべきかという感覚は、回数を重ねるほど磨かれます。
08まとめ
AI ペアプロのコツは、煎じ詰めれば「小さく渡して、読んで、確かめる」。丸投げを避けるために計画と範囲を渡し、丸呑みを避けるためにコードを読みテストで担保する。この往復さえ保てば、エージェントが長く速く走る時代でも、品質と安全を手放さずに済みます。次は、既存のコードベースへ AI を導入するときのガードレール設計（権限・ログ・レビュー体制）へ進みましょう。
