# 完成したプロンプトはない。Claude Codeに任せて失敗するたびに増えていった「指示のルール」、全部見せます

> https://bookfactory.kr/board/news/20397
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-09T03:51:54.605Z

---

僕はジュニアのエンジニアで、実務の実装はほぼ全部Claude Codeにやらせています。

正直、速いです。自分で書くより圧倒的に速い。

ただ、失敗もしています。

## 「直しました」と言われたのに、直っていなかった話

ある日、直すべき箇所をClaude Codeに直させました。

「直しました」と返ってきた。でも確認すると、直すべき箇所が直っていなかった。

「直しました」という報告と、実際に直っているかどうかは別のことでした。

別の日には、提出用のコミットメッセージにAIが余計な一文を書いていました。

こういうことがあるたびに、AIに何をさせて何をさせないかを、ルールとして足していくようになりました。

## 実装の前に、4つを出させるようにした

今は、実装に入る前にこの4つを整理させてから、僕がOKを出す順番にしています。

- 何が原因か
- どのファイルを変更するか
- 変更による影響範囲
- 未確定事項

たったこれだけです。

でも、原因の理解がズレていれば、ここで分かる。「どのファイルを変更するか」に関係ないファイルが混ざっていれば、実装の前に止められる。「未確定事項」に「仕様がAともBとも読める」と書かれていれば、実装する前に自分で決められる。

## ただし、4項目だけがルールではない

ここからが本題です。

先に言っておくと、僕には「毎回コピペしている完成済みプロンプト」はありません。人のPRをレビューするときに使っている定型文が1つあるだけで、それ以外はその都度Claude Codeに指示しています。

代わりにあるのは、「これは先に出させる」「これはやらせない」「報告はこの形」というルールの束です。最初からあったわけじゃなくて、実務でAIに任せて困るたびに1つずつ足していきました。

有料部分に入っているのは、この4つです。

- 実際に使っている10個のルールを、「実装前に確認させること」「実装中に守らせること」「実装後に報告させること」の3つに分けて全部
- 人のPRをレビューするときに使っている定型文の実物と、各行をなぜ入れているのか
- それぞれのルールをなぜ入れているのか。失敗がきっかけで足したルールは、そのときの実体験も一緒に
- 各セクションのルールを、記事用にコピペできる指示文としてまとめたもの

最後の指示文は、僕が毎回貼っているものではなく、この記事のために整理したものです。ルールの文言はそのまま使えますが、それより「なぜこの行があるのか」を読んでもらった方が、自分の現場に合ったルールを作れると思います。

## はじめに：ルールの読み方

以下、ルールは「実際に使っている言い方」で書きます。失敗がきっかけで足したルールには、そのエピソードを「きっかけ」として書きます。それ以外のルールは、何を避けるためのものかだけ書きます。各セクションの最後にある「記事用にまとめた指示文」は、この記事のために整理したもので、僕が毎回貼っている文ではありません。

**출처:** [note 원문](https://note.com/ali_archive/n/nab97438b2e51)

*번역: Gemma 3(.44) 초벌 + 교정 검수*

[원문 보기](https://note.com/ali_archive/n/nab97438b2e51) | 출처: note.com