AIエージェントにコードを任せる前に、タスクへチェックポイントを入れる

Larry

同僚にコード変更を頼むとき、通常は issue を書き、要件を補い、branch を作り、最後に pull request を見る流れになる。やり取りはあっても、要望が妥当か、どこを変えるべきか、いつ merge してよいかは人間が判断している。

Coding agent が変えるのは、この日常的な場面だ。コードを提案するだけではなく、issue を読み、ファイルを編集し、テストを実行し、自分で pull request まで作れる。AI は「チャットで助言するもの」から「repo の中で実際に手を動かすもの」へ近づいている。

便利ではあるが、プロダクト判断を引き受けるわけではない。範囲、仮定、リスク、rollback は人間が先に線を引く必要がある。Devin、Copilot 型 coding agent、同種のツールを導入する前に、「自力で完了できるか」だけを問わない。どこで止めれば、人間が方向性を確認できるかを先に決める。

このレッスンは「AIエージェントにコードを任せる前に、タスクへチェックポイントを入れる」を、読者が使える一つの判断問題に絞る。coding agent は issue を読み、ファイルを編集し、テストを走らせ、PR まで作れる。しかしタスクは「完成させて」の一文で渡すべきではない。どこまで進めてよいか、どこで人間が見るべきかを先に決める。本文の表やチェックは、チームが進む前に何を決めるかを見るためのものだ。

あわせて確認したいこと

この判断を実際のワークフローに入れるなら、AIエージェントにコードを任せる前に、タスクへチェックポイントを入れるも合わせて確認すると、同じ停止点をタスク、権限、引き継ぎの確認に戻しやすい。

この判断を実際のワークフローに入れるなら、自動化が途中で失敗したら、誰が後始末をするのかも合わせて確認すると、同じ停止点をタスク、権限、引き継ぎの確認に戻しやすい。

まずチェックポイント表から始める

曖昧なタスクほど、一度に agent へ渡すべきではない。先に確認可能なゲートへ分ける。

チェックポイント	Agent ができること	人間が確認すること	通らない場合
タスク要約	issue、目標、非目標を言い直す	誤ったプロダクト仮定を足していないか	prompt を直すか issue を小さくする
実装計画	変更したいファイル、関数、テストを列挙する	範囲が広すぎないか、重要フローに触れていないか	計画をやり直させる
最初の小さな diff	テストか明確な1モジュールだけを変更する	diff が読めて、戻しやすいか	範囲が広がる前に止める
テストと証拠	指定テストを走らせ、結果を出す	CI を緑にするだけでなく要件を証明しているか	テストか受け入れ条件を追加する
PR レビュー	仮定、制限、rollback を説明する	データ、権限、API、ユーザー導線の仮定は妥当か	PR を分けるか人間が引き取る

この表の目的は手続きを増やすことではない。agent が間違った方向へ作業を広げ続けるのを防ぐことだ。

丸投げとチェックポイント型

明確な issue テンプレート、テスト習慣、review gate がなければ、coding agent はその穴を大きくする。

範囲: 丸投げでは agent がファイルとプロダクト仮定を推測する。チェックポイント型では、人間が目標、非目標、触れてはいけない範囲を先に決める。
Diff とテスト: 丸投げではテスト、ロジック、UI、文書、設定が一度に変わりがちだ。チェックポイント型では diff を小さくし、指定した振る舞いの証拠を求める。
Rollback: 丸投げでは PR が大きくなってからリスクに気づくことがある。チェックポイント型なら各ゲートで停止、復元、分割できる。

タスクが明確で、テストがあり、変更範囲も小さいなら、agent は加速器になる。要件が議論中で、中核フローにテストがなく、ビジネスルールを誰も説明できないなら、完成実装を直接任せないほうが安全だ。

どのタスクを agent に渡すか

Cognition の Devin や他の coding agents によって、「AI が自分で PR を出す」ことは自然に見えるようになった。それでも実務上の基準は単純だ。そのタスクは検査できるか。

向いている: 完了条件、非目標、関連ファイル、指定テスト、限定されたリスク、review 担当者、小さな PR または feature flag による rollback がある issue。

まだ向かない: 曖昧な機能依頼、テストのない中核フロー、支払い、権限、削除、ログイン、または検証と復元の方法が不明な複数サービス変更。

切り替えないケース: 向いている条件が半分も満たされないなら、機能全体を agent に切り替えない。コードベース調査、計画作成、テスト案、依存ファイル探しに使い、人間が確認してから小さな diff だけを許可する。

Coding agent は生産量を上げられるが、プロダクト責任を引き受けない。PR が大きくなってから見るのではなく、最初から人間のチェックポイントをタスクに入れておく。

生活四コマ

友人が棚を組み立てる前に場所、寸法、確認点を決める4コマ漫画

すぐに棚を組み立ててもらおうとしているが、寸法、置き場所、完了基準を確認していない。
途中で入らない、向きが違うと分かると、先に確認するよりやり直しのほうが大変だ。
寸法、手順、チェックポイント、戻し方を先に整理すれば、作業は安定して完了できる。
coding agent も同じだ。AI にコードを書かせる前に、人間の確認点、テスト、rollback を決める。

AI 整理カード

この判断表を自分の次の一手に落とす このプロンプトは、AIに先に背景を聞かせてから判断させる。記事の要約ではなく、作業フローの確認に使う。

このBMCミニレッスンを自分の状況に当てはめたい：AIエージェントにコードを任せる前に、タスクへチェックポイントを入れる

この記事が扱う具体的な問題：coding agent は issue を読み、ファイルを編集し、テストを走らせ、PR まで作れる。しかしタスクは「完成させて」の一文で渡すべきではない。どこまで進めてよいか、どこで人間が見るべきかを先に決める。
記事URL：https://boosterminiclass.com/ja/posts/coding-agents-need-human-checkpoints/

記事を要約するだけにしないでほしい。まず、次の3点を確認する質問をしてほしい。
1. いま扱っている実際のワークフローまたは判断は何か。
2. その流れに関わるデータ、権限、アカウント、費用、外部実行は何か。
3. 今日ほしいのは、停止判断、試用チェックリスト、引き継ぎテンプレート、リスク分級のどれか。

そのうえで、この記事固有の枠組みで私の状況を確認してほしい：1. coding agent に渡すタスク範囲、非目標、触れてはいけないファイルやシステム；2. issue 読み取り、編集、テスト、PR 作成をどこまで任せるか；3. どの diff、エラー、権限、データ変更で人間レビューに止めるか；4. 指示、テスト、rollback、review の引き渡しチェックリスト。

出力してほしいもの：
- 進める、範囲を絞って試す、一度止める、のどれかを一文で判断する。
- 枠組みを私の状況に当てはめ、準備済み／証拠不足／人間確認が必要、に分けた表。
- 今日できる最小の一手。
- 担当者、ログ、戻し方、人間レビューが必要な箇所。