※本記事はプロモーションを含みます。
AIコーディングは、使い慣れるほど便利になります。Claude CodeやCodexに作業を頼むと、関連するファイルを読み、変更案を考え、実際の修正まで進めてくれます。
一方で、便利になるほど別の怖さも出てきました。AIが間違えることだけではなく、どこまで見て、何を根拠に判断し、どこを変更したのかを自分が追えなくなることです。
私がガードレールを置くようになったのは、AIを疑い続けるためではありません。人間が最後に確認できる範囲へ、AIの作業を収めるためです。
この記事では、作業範囲を限定しなかったことで困った経験をもとに、CodexやClaude Codeを使うときに私が見ているポイントをまとめます。あわせて、長い会話の扱い方や、CLAUDE.mdとAGENTS.mdに残しているルールについても整理します。
作業範囲を限定しなかったことで、関係ない場所まで見に行ってしまった
私がガードレールの必要性を強く感じたのは、AIがコードを壊したからではありません。もっと地味ですが、後から確認するのがかなり面倒になるずれがありました。
作業範囲を限定しないまま依頼したことで、AIが別のプロジェクト側で定義していたMCPやデータストア系のツールまで見に行き、その情報を含めた状態で回答や実装を進めてしまったことがあります。今回の作業とは関係のないフォルダを見に行ったこともありました。
ここで困ったのは、重大な障害が起きたことでも、外部に何かが出たと確認されたことでもありません。AIが何を根拠に判断したのか、どの情報が混ざったのかを、後から追う必要が出てきたことです。
本来頼みたかった修正よりも、確認しなければならない範囲のほうが広くなってしまいました。
AIの作業が速くても、参照する範囲や変更できる範囲が広すぎると、人間側の確認が追いつきません。これは「AIが危険だった」というより、任せる範囲を決めていなかった私の運用の問題でした。
それ以降は、最初からすべてを見せるのではなく、対象ディレクトリ、変更してよいファイル、触らないフォルダ、確認してから進めてほしい操作を分けるようにしています。
AIの作業を必要以上に狭くしたいわけではありません。後から自分で追える範囲に収めるための線引きです。
Codexでコード修正を任せるときに見ているポイント
Codexにコード修正を任せるとき、私が最初に見るのは、コードの上手さではありません。
どの範囲を読んだのか。頼んだ問題から外れていないか。なぜその変更をしたのか説明できるか。まずは、そこを見ています。
たとえば、小さな表示崩れを直したいだけなのに、デザイン全体や関係のないコンポーネントまで整え始めることがあります。説明を読むと改善に見えても、変更が広がれば、それだけ確認する場所も増えます。
私が主に確認しているのは、次の4つです。
- 対象範囲: 頼んだファイルや機能から、変更がはみ出していないか
- 変更理由: なぜその変更が必要なのか説明できるか
- 影響範囲: ほかの画面や処理に影響しないか
- 検証内容: テスト、表示確認、差分確認のうち、何を行ったか
差分を見るときは、変更された行数だけでは判断しません。
変更が少なくても、共通関数に手を入れていれば影響は広くなることがあります。反対に、変更量が多くても、文言や表示の整理だけであれば、確認する内容は比較的わかりやすい場合があります。
そのため、「どれだけ変えたか」よりも、「なぜ変えたのか」と「どこまで影響するのか」を追うようにしています。
AIの説明がきれいでも、検証が薄い場合は、そのまま採用しません。確認できなかったことがあるなら、それも明記してもらいます。
最後に反映するかどうかは、AIが自信を持っているかではなく、私が確認できた材料で決めたいからです。
Claude CodeやCodexに作業を頼む前に決めていること
Claude CodeやCodexは、会話だけで使うAIよりも、実際の作業場所に近いところまで入ってきます。
だからこそ、私は依頼内容だけでなく、「作業が終わったあとに何を見るか」も先に決めるようにしています。
作業前に整理しているのは、主に次の5つです。
- 触ってよい範囲: 対象ファイル、対象フォルダ、対象機能
- 触らない範囲: 関係のないプロジェクト、公開設定、重要な設定ファイル
- 確認してから進める操作: 削除、ファイル移動、外部サービスに関わる操作
- 完了条件: テスト、表示確認、差分確認、本文確認など
- 採用判断: 最終的に反映するかどうかは私が決める
毎回、細かい条件を長く書いているわけではありません。ただ、この軸がないまま作業を始めると、終わったあとに何を確認すればよいのかがわからなくなります。
確認ルールは、AIを縛るためのものというより、人間側が見る場所を先に決めるためのメモです。
作業後になってから「どこを見ればよいのだろう」と探すより、最初に確認場所を決めておいたほうが、私は落ち着いて差分を見られます。
特に慎重に扱っているのは、公開済みの記事、収益に関わる導線、設定ファイル、削除や移動、外部サービスに影響する操作です。
AIが実行できるかどうかだけではなく、自分が変更内容と影響を確認できるかどうかで、任せる範囲を決めています。
長い会話に情報を詰め込みすぎないようにした
コンテキスト管理については、何か具体的なトラブルが起きたことをきっかけに見直したわけではありません。
私が気にしているのは、長い会話を続けるほどトークンの消費が増え、AIの利用上限に早く達しやすくなることです。
最初は、前回の会話や関係しそうな情報を、できるだけ多く引き継いだほうが安心だと思っていました。
過去に決めたことも、途中で試した案も、参考になりそうなファイルも、全部渡したほうがAIは状況を理解しやすいと考えていたからです。
ただ、情報が多ければ多いほど、安定するとは限りません。
長い会話には、すでに使わなくなった前提や、途中で捨てた案も残ります。それらを抱えたまま作業を続けると、AIだけでなく、私自身も「どれが今の前提だったか」と迷いやすくなります。
これは深刻な失敗を防ぐための対策というより、作業単位と利用上限を守るための整理です。
長い会話を続けること自体が悪いとは思っていません。ただ、必要な前提と、もう使わない前提を分けないまま続けると、作業が重くなりやすいと感じています。
今は、前回の会話をそのまま引き継ぐのではなく、今回の目的、対象範囲、守るルール、完了条件だけを短く切り出すようにしています。
必要な情報が出てきたら、その時点で追加します。最初からすべてを入れないほうが、AIに頼む作業も、自分が確認する作業も軽くなりました。
CLAUDE.mdとAGENTS.mdには、あとから読めるためのルールを残す
AIにコードを書かせる量が増えるほど、動くだけではなく、あとから読める状態を保つためのルールが必要になります。
最初は、動くものが出てくるだけでも助かります。ただ、あとで修正する前提で考えると、速く作れることと、変更内容を説明しやすいことは別でした。
私が特に見ているのは、変数名、コメント、処理のまとまり、変更理由です。
AIが書いたコードでも、その後に読み、直し、運用するのは人間です。自分でも読みづらいコードを積み上げてしまうと、次の修正のたびに、また調査から始めることになります。
私は、Claude Codeを使うプロジェクトではCLAUDE.md、Codexを使うプロジェクトではAGENTS.mdに、継続して守りたい作業前提を残しています。
毎回の依頼をすべて書いておく場所ではなく、何度も繰り返したくない共通ルールを置く場所という扱いです。
最初から細かいコーディングの好みを大量に書く必要はないと思っています。まずは、あとから自分で読める状態を保つための最低限のルールだけにしています。
たとえば、次のような内容です。
- 一つの処理を大きくしすぎない
- 変数名は役割がわかるものにする
- 変更が必要な理由を説明する
- 確認できなかったことを隠さない
- 頼まれていない範囲まで変更しない
ただし、ルールが増えすぎると、今度はAIも人間も読み切れなくなります。
そのため、共通して使うルールは短く残し、その作業だけに必要な条件は、依頼文や作業メモに分けています。
この分け方にしておくと、AIに任せる量が増えても、確認するときの土台を残しやすくなります。
ガードレールは、人間の最終確認を機能させるために置く
AIコーディングを安全に使うというと、AIを強く疑い、できることを制限する話に見えるかもしれません。
私の感覚では、少し違います。
AIを疑い続けるというより、人間が最後に確認できる単位へ作業を収めることが大切だと考えています。
対象範囲を限定する。触らない場所を決める。長い会話に情報を詰め込みすぎない。差分と検証内容を見てから採用する。
どれも、AIの能力を弱めるために行っているわけではありません。AIに任せた作業を、最後に自分が判断できる形へ戻すための工夫です。
ガードレールを置いたからといって、AIコーディングが完全に安全になるわけではありません。想定していなかった変更が入る可能性もありますし、自分が見落とす可能性も残ります。
それでも、作業範囲を区切っておけば、少なくとも確認する場所を絞りやすくなります。
私にとってガードレールは、AIの自由度を奪うものではなく、どこまでなら作業を渡せるのかを考えるための土台です。線引きがあることで、以前よりも落ち着いてAIに修正を頼めるようになりました。
Claude Codeを使い始めるときに決めたことや、最初の依頼で渡している内容については、Claude Codeの使い方で最初に決めておきたいことで整理しています。
最初に何を渡すかを決め、その次に、どこまで任せるかを決める。
私はこの順番で整理することで、AIコーディングに感じていた怖さを、少しずつ扱える形に変えています。
AIに任せる前に、最低限の仕組みや使い方を動画で確認したい人は、Udemyで「生成AI」「ChatGPT」「Python」「AI活用」などの入門講座を探してみるのも一つです。講座を選ぶときは、レベル、更新日、レビュー、価格を自分の目的に合わせて確認してください。
