※本記事はプロモーションを含みます。
Claude CodeやCodexのように、AIが実際の作業まで進める道具を使うと、会話だけで使うAIとは少し感覚が変わります。
質問への回答を読むだけではありません。ファイルを確認し、変更案を作り、実際に修正した内容まで説明してくれます。
Claude CodeやCodexを安全に使うには、作業前に変更範囲を指定し、作業後に差分と動作を人間が確認できる状態にしておく必要があります。
私も、こうしたAI作業ツールを使うことで、小さな修正や整理を進めやすくなったと感じています。
一方で、作業が速くなるほど、使う側がどこで止めて、何を確認するのかを決めておかないと不安も増えます。
AIから自然な説明が返ってくると、それだけで作業が終わったような気持ちになります。しかし、説明が分かりやすいことと、変更内容が正しいことは別です。
そこで私は、Claude CodeやCodexに作業を頼むとき、依頼内容だけでなく確認ルールも先に決めておくようにしています。
細かい機能や操作方法ではなく、AIにどこまで任せ、どこから人間が確認するのか。その線引きを中心に整理します。
Claude Code・Codexに作業を頼む前に決める5つの確認項目
AI作業ツールを使うとき、最初に考えるのは「何をしてもらうか」だと思います。
ただ、私は「作業後に何を見るか」も、同じタイミングで決めておきたいと考えています。
たとえば、記事の表記をそろえる、コードの小さな修正を頼む、設定ファイルの内容を確認する。こうした作業はAIに頼みやすいものです。
その一方で、依頼しやすい作業ほど、終わったあとの確認が曖昧になりやすいとも感じます。
私は作業を頼む前に、次の5つを整理します。
| 確認項目 | 人間側で決めること |
|---|---|
| 触ってよい範囲 | 対象ファイルやフォルダ |
| 触らない範囲 | 公開済みデータや重要設定 |
| 変更差分 | 変更されたファイルと内容 |
| 実行結果 | テスト、表示、本文の通読 |
| 採用判断 | 変更を反映するかどうか |
最後の採用判断は、人間側に残します。
AIに作業を任せることと、出てきた結果をそのまま通すことは違います。これは、以前書いたAIに任せる作業と人間が確認する作業の分け方でも整理した考え方です。
確認ルールは、AIを疑い続けるためのものではありません。
自分が確認できる範囲を明確にし、その範囲では安心してAIに任せるためのものです。
AIに変更を任せる範囲と、触らせない範囲を分ける
AIに作業を頼む前に、まず決めておきたいのが作業範囲です。
どのファイルを見てよいのか。どのフォルダを変更してよいのか。公開済みの記事や設定に影響するのか。削除や移動のように、元へ戻しにくい操作が含まれていないか。
この範囲が曖昧だと、依頼した作業自体はできていても、自分が想定していなかった場所まで変更されることがあります。
作業前に決めることは、次のように分けています。
- 触ってよい範囲
- 触らない範囲
- 確認してから進める操作
- 完了条件
作業後に確認することも、同じタイミングで見えるようにしておきます。
- 変更されたファイル
- 変更差分
- テストや表示結果
- 既存機能への影響
- 採用するかどうか
作業前のメモに残すなら、次のくらい短くても十分です。
触ってよい範囲:
触らない範囲:
確認してから進める操作:
作業後に見るもの:
特に慎重に扱うのは、公開状態、収益に関係する導線、設定ファイル、ファイルの削除や移動、外部サービスへ影響する操作です。
こうした作業は、AIが実行できるかどうかではなく、自分が変更内容と影響を確認できるかどうかで判断します。
AIに作業を任せるときに怖いのは、間違いが起きることだけではありません。どこまで変わったのか分からないまま、次の作業へ進んでしまうことも不安です。
バイブコーディングで仕様メモが必要だと感じた経緯は、バイブコーディングで仕様メモを作った理由でも残しています。
今回の確認ルールも、基本的な考え方は同じです。「この範囲なら自分で確認できる」「ここに触れる場合は、作業を進める前に一度止める」。この線引きがあると、AIへ作業を頼むときの不安を少し減らせます。
Claude Code・Codexの説明だけでなく変更差分を確認する
Claude CodeやCodexのようなAI作業ツールは、作業後に変更内容を文章で説明してくれます。
何をしたのかを短時間で把握できるので、この説明は役に立ちます。ただし、私は説明だけを読んで作業完了とは判断しません。
説明を読んだあとに、実際の変更差分と影響範囲を確認します。
文章では「軽微な修正」と説明されていても、公開状態や設定に関係する場所へ触れているかもしれません。反対に、変更された行数が多くても、表記の一括整理など、内容への影響が小さい場合もあります。
AIの説明と、人間側で見ることは次のように分けています。
| AIの説明 | 人間の確認 |
|---|---|
| 軽微な修正です | どのファイルが変わり、既存の動作に影響しないかを見る |
| テストは通りました | 何を対象にしたテストなのか、想定した条件が含まれているかを見る |
差分を見るときは、行数だけではなく、次の点を確認します。
- どのファイルが変わったか
- 依頼した範囲だけが変更されているか
- 公開状態や設定に影響しないか
- 既存の動作が変わる可能性はないか
- なぜ必要な変更なのか、自分でも説明できるか
AIの説明は、確認を終わらせるためのものではなく、確認を始めるための手がかりとして使います。
まず説明を読み、どこが変わったのかを把握する。そのあと差分を見て、影響する範囲を考える。最後に、人間側で採用するかを決めます。
AIの説明が自然で分かりやすくなるほど、この順番は意識して残しておきたいところです。
コード・記事・設定ごとに作業結果を確認する
差分を確認したあとに見るのが、実際の作業結果です。
確認方法は作業によって変わりますが、AIの説明だけで完了にしない点は共通しています。
| 対象 | 確認すること |
|---|---|
| コード | テスト、エラー、画面表示 |
| ブログ記事 | 本文の通読、リンク、公開状態 |
| 設定ファイル | 変更差分、影響する機能、元に戻す方法 |
| ファイル操作 | 削除・移動の対象、バックアップの有無 |
たとえば、AIが「表示崩れを修正しました」と説明していても、実際の画面を見なければ直っているかは分かりません。
「文章の流れを整えました」と説明されても、本文を前から読まなければ、意味や体験内容まで自然につながっているかは確認できません。
「テストを実行しました」と書かれていても、自分が想定している条件まで確認できているとは限りません。
そのため、私は作業前に確認方法も決めておきます。
- どのコマンドやテストで確認するか
- どの画面を見るか
- どの文章を通読するか
- 何を確認できれば採用するか
- 何を確認できなければ止めるか
確認できない作業を、すべて避ける必要はないと思っています。ただし、確認できていないものは「問題ない」とは扱いません。
「たぶん大丈夫」と「実際に確認できた」は分けておきます。AIに任せる作業が増えるほど、この区別は大切になります。
確認で見つかった問題をAGENTS.mdや仕様メモに残す
AIへ作業を頼んでも、毎回想定どおりに進むとは限りません。
依頼した範囲より広い場所に触れた。出力の方向は合っていたものの、確認項目が足りなかった。自分が前提条件を書き忘れていた。
こうしたことは実際に起こります。その問題を会話の中だけで終わらせると、次の作業では同じ説明や修正を繰り返すことになります。
私は、うまくいかなかった条件をAGENTS.mdや作業前の仕様メモへ戻していくことが大切だと考えています。
たとえば、次のようなルールです。
- 公開済みの記事は、ユーザーの確認なしで変更しない
- 過去の資料は参考情報として扱い、勝手に書き換えない
- 変更後は、差分確認と表示確認をセットで行う
- 本文の自然さは、特定の言葉を機械的に探すだけでなく通読して確認する
- 案内先が整っていない導線へ、無理に読者を送らない
AGENTS.mdには、複数の作業で共通して守りたい前提を残します。一方で、今回の作業だけに必要な条件は仕様メモへ置きます。
共通ルールはAGENTS.mdへ、個別の条件は仕様メモへ戻す。
このように分けておくと、AIへの依頼内容だけでなく、あとから自分が作業を振り返るときにも確認しやすくなります。
AIコーディングの作業を確認するために必要な基礎知識
Claude CodeやCodexを使うと、コードをすべて自分で書かなくても、作業を進められる場面があります。
ただし、それは何も分からない状態で、すべて任せてもよいという意味ではありません。
AIの作業結果を確認するには、最低限の基礎があるほうが安心です。
たとえば、Gitの差分を見る方法、ファイル変更の影響範囲、テストや表示確認の意味、エラーが出たときに確認する場所などです。
こうした基礎があると、AIの説明を読んだときに、どこで一度止まるべきか判断しやすくなります。
Udemyのような動画講座も、基礎を確認する選択肢の一つです。
ただし、講座を見ればAIコーディングが必ずうまくいくわけでも、誰でも簡単に開発できるようになるわけでもありません。
私の中では、AIに任せる範囲を無条件に広げるためではなく、AIが行った作業を自分で確認できる範囲を増やすための学びという位置づけです。
Claude Code・Codexは人間が確認できる範囲から任せる
Claude CodeやCodexに作業を頼む前に、私が決めておきたいのは次の5つです。
- 触ってよい範囲
- 触らない範囲
- 変更後に見る差分
- 実行結果や表示の確認方法
- 最後に人間が採用を判断すること
確認ルールを決めたからといって、AIの間違いがなくなるわけではありません。
それでも、どこを見ればよいのか分からない状態のまま作業を受け取るより、確認しやすくなります。
AIが作業を速く進めてくれるほど、人間側は自分が見る場所を先に決めておく必要があります。
すべてを自分で抱えるためではありません。自分で確認できる範囲を残しながら、AIへ安心して任せられる作業を少しずつ増やしていくためです。
今回整理した確認項目は、AIへの作業依頼テンプレートにも残していく予定です。
Claude Codeを使い始めたときに詰まりやすかった点はClaude Codeで最初に詰まったポイント、Codexの作業結果を受け取るときの見方はCodexレビューの確認ポイントで整理しています。

