非エンジニアのClaude作業台
ほかの場所:note(建設)建設のブログ低スペックPCでAIのブログポートフォリオ

2026-10-08

Claude に仕事を任せて起きた事故と、そこから作ったルール

私は建設DXの仕事をしながら、プログラミングの経験がないまま Claude Code(文章で頼むと、パソコンの中で作業までしてくれるAI)に仕事を任せています。自作のアプリ作り、動画編集の受注案件、案件への応募文の下書きまで、毎日いろいろ頼んでいます。

任せる量が増えるほど、事故も増えました。そのたびに「次はこうして」とルールを書き足してきたら、Claude が毎回読む指示書(CLAUDE.md というファイル)が育ち、ルールが生まれた場面の記録は57件になりました。

この記事では、その中から仕事に直接響いた4件と、ルールの書き方で分かったことを書きます。

事故1:「完了しました」が、完了していなかった

アプリの画面を直してもらったとき、Claude は検査を全部通して「完了しました」と報告しました。ところが実際にアプリを起動すると、途中でエラーが出て、直したはずの画面は1枚も作られていませんでした。

検査は「部品が正しく書けているか」を見ていて、「アプリを開いて、その画面が出るか」は見ていなかったのです。

作ったルール:実際の画面を見られなかった回は「完了」ではなく「未確認」と書く。

これだけで、報告の読み方が変わりました。「未確認」と書いてあれば、自分で開いて見ればいい。「完了」と書いてあるのに動かないのが、いちばん困ります。

事故2:空欄のまま、相手に届いた

受注案件の納品で、提出のメッセージを下書きしてもらいました。リンクを2つ貼る必要があり、1つがまだ用意できていなかったので、Claude はそこを <リンク> のまま残し、返事で「1か所空いています」と太字で教えてくれました。

私はそれを読んだつもりで、そのまま送信しました。相手には「完成動画:<リンク>」が届きました。そのサイトのメッセージは、送ったあとに直すことも消すこともできません。

作ったルール:埋まっていない場所が1つでも残るなら、入力欄に置かない。先に埋めるか、その行ごと消してから置く。

注意書きは、押せるボタンの前では役に立ちませんでした。人は目の前の「送信」を押します。だから、送ってはいけないものを入力欄に置かないようにしました。

事故3:頼んでいないものまで消えた

「テストで作ったものを全部消して」と頼んだときのことです。Claude は消す範囲を選択肢で聞いてくれたのですが、その選択肢の中に、私が頼んでいない「テスト案件のフォルダごと全部消す」が混ざっていました。私の答えも「道具の検証用のものだけ」と「全部」が食い違っていたのに、Claude は広いほうを取って消しました。

消えたのは、残しておくつもりだった別の編集データと書き出した動画で、合わせて4GBほどです。ごみ箱にも残っていませんでした。

作ったルール:消してよいかを問うのは「テストで作ったものか」の1つだけ。違うなら消さないし、消す選択肢にも出さない。答えが食い違ったら、消さずに聞き直す。

このルールを作ったあとにも、同じ型の事故がもう1回ありました。今度は、案件で使う素材を Claude が「一時ファイル」と呼んで消しました。消してはいけないものの一覧は作ってあったのに、先に別の呼び名を付けたことで、一覧の外に出てしまったのです。それからは「呼び名で判断しない。テストで作ったものかだけを問う」に絞りました。

事故4:Claude が付けた名前が、作業の向きを決めてしまった

動画編集の受注案件で、依頼は「無音のところをカットし、削除せずに編集点として残す」でした。

Claude は作業の途中で、カット済みのほうに「納品用」、カット前のほうに「確認用」という名前を付けました。依頼の文にはどちらの言葉も出てきません。それなのに、その名前が前提になり、字幕もエフェクトも全部「納品用」のほうに乗せていきました。

本当に大事だったのはカット前のほうでした。丸一日分の作業がやり直しになりました。

作ったルール:成果物の名前は、依頼の言葉から取る。「〜用」と付けたくなったら、そこに頼まれていない判断が入っているので、先に確かめる。

ルールを増やしても、事故は止まらなかった

ここまで読むと「ルールを書けば済む」と思うかもしれません。私もそう思っていました。

実際には、送る前に確かめることを書いたルールが、指示書の中の7か所に散っていた時期がありました。そのあいだ、7つとも働いていませんでした。Claude は指示書を毎回読んでいて、中身を「知って」います。それでも、行動の直前に自分から思い出してはくれませんでした。

そこで2つ変えました。

1つ目は、送る前に当てる確認を1つの表にまとめたことです。「何を見るか」と「引っかかったらどうするか」を1行ずつ並べ、返事を出す前にその表を上から当てさせています。いまは15行あります。

2つ目は、守れているかを機械に見張らせたことです。Claude Code には、返事を終える直前に自動で走る小さなプログラムを仕込めます。私の環境では、ファイルを変えた回なのに「完了」か「ここで止まってよい理由」のどちらも書いていなければ、返事を終わらせずに作業を続けさせています。

ルールの書き方で分かったこと

ルールと事故の記録は、分けて置く

最初は、ルールの横に「なぜこのルールができたか」を全部書いていました。指示書は長くなり、肝心のルールが埋もれました。

いまは、ルールだけを指示書に置き、事故の記録は別のファイル(事件簿と呼んでいます)に移しています。見出しを同じ文言にしておけば、「なぜこのルールがあるのか」を知りたいときに、見出しで探せば記録に飛べます。

「気をつける」ではなく「何を見るか」で書く

「慎重に消すこと」と書いても、何も変わりませんでした。「消す前に、テストで作ったものかを問う。違うなら消さない」と書くと、守られるようになりました。

Claude は、気をつけることはできません。決められたものを見ることはできます。

事故が起きたら、その場で記録の案を出させる

直して終わりにすると、同じ事故がまた起きます。いまは、事故が起きたら Claude のほうから「何が起きたか・なぜ起きたか・どこに何を書くか」の3つを出させ、文面まで案にしてもらっています。採るかどうかは私が決めます。

おわりに

AIに仕事を任せると、人間なら起きない種類の事故が起きます。ただ、その多くは「言われたとおりにやった」結果で、指示の側に穴がありました。

事故のたびに穴を1つずつふさいでいくと、任せられる範囲が少しずつ広がります。同じように Claude に仕事を任せている人の参考になればうれしいです。