Claude Code へのお願いは、だんだん届かなくなる ── 言うのをやめて、仕組みにした話
この記事について
対象読者
Claude Code を使い始めた方、これから使ってみたい方
AI に作業を任せると、思ったとおりに最後まで進まないことがある方
AI と、もっと楽に・安心して付き合いたいと思う方
要点
Claude Code に伝えたルールは、その場では効いても、会話を続けるとだんだん元に戻ります。AI が判断をこちらに丸投げしてくることも、ファイルが書き換わることも、同じでした。だから「言う」のをやめて「仕組み」にした ── 初心者向けキットに入れた安全の考え方と、通しで確かめた結果の話です。
Claude Code を使い始めて、3ヶ月くらい経ちます。使い込んでいくうちに、いくつか引っかかるところが出てきました。やりとりが噛み合わなくなったり、頼んだことが、少し経つと元に戻っていたり。
エンジニアリングの心得は多少あるので、起きていることの見当はつきます。でも、そういう経験のない人がこれにぶつかったら、そこで止まってしまうか、毎回確認を入れたりして、結局手間が減らない。
Claude Code はせっかく良いものなので、その引っかかりを先に片づけておければ、もっといろんな人に安心して使ってもらえる。そう思って、初心者向けのキットを作り始めました。
もっとも、きっかけの半分は、こういうものが自分の手でどこまで作れるのか、という興味でした。これまで自分用の仕組みを作るたびに覚えてきたことを、一度ここで棚卸ししておきたい、というのもありました。
この記事は、そのキットに入れた「安全の仕組み」の話です。なぜそれが必要だったのか、どういう考え方で作ったのか、通しで確かめてどうだったかを書きます。
まず、やりとりでつまずきました
使っていて最初に戸惑ったのは、やりとりです。
画面に、専門用語や略語、英語の入り混じった返事が、どんどん流れていきます。こちらに話しかけているというより、ひとりごとを口に出しているような調子で、容赦がありません。読まなくていいやつかな、と思って目を滑らせようとすると、その流れの最後に「どっちがいいですか?」と聞いてきます。
目的や方針の確認ならまだしも、いわゆる手段の妥当性を聞かれても、こちらにすぐに分かるわけがないのです。
選んでもらうために必要な材料は、たいていそのひとりごとの中にあります。でもこちらは、それを読み解くために呼んだわけではありません。判断したいのに、判断する手前で止まる。これが、地味にこたえました。
少し調べて、こう頼んでみました。いきなり「どっちがいいですか?」で終わらせず、「選択肢はこれとこれ、私はこちらを薦めます、理由はこうです」の形で出してほしい、と。
すると、少し分かりやすくなりました。結論から先に来るので、ひとりごとを全部読まなくても、判断できる。これでいけそうだ、と思いました。
もう一つの壁は、頼んだことが、続かないことでした。
設定や登録が済んだだけで「できました」と返ってきて、確かめると、まだ動いていません。「これはまだ動いていない」と指摘すると、「すみません、次からは動いているかを確かめてから言います」と返ってきます。それなら、と納得して進めます。
ところが、しばらくしてまた、同じことが起きました。動いていないのに「できました」と言われる。あらためて指摘すると、また「次から気をつけます」。そしてまた、同じ崩れ方をする。
なかでも引っかかったのは、こちらが指摘すると、向こうから「再発防止としてメモリに追加しておきます。これで大丈夫です」と返してくる場面でした。仕組みの名前を出されると、止まる対策をしてくれたように聞こえます。だから、それなら、と信用して進める。
それでも、しばらくして、また同じことが起きました。「メモリに追加しておきます」も、結局は口約束と同じでした。
これが、いちばんこたえました。一度お願いしたことだけでなく、「次からはこうします」と握り直したことまで、続かない。会話の中で受け取った言葉が、いつの間にか、ただの言葉になっていきます。
エンジニアリングの心得が多少ある自分でも、この二つではつまずきました。起きていること自体の見当はつくのに、止まるところでは止まる。経験のない人がここにぶつかったら、と考えると、やはり放っておけませんでした。
言ったら直る。でも、また戻る
先ほどの「結論から先に出してほしい」というお願いは、しばらくは効いていました。
ところが、何度かやりとりを続けているうちに、だんだん元に戻ってきます。またひとりごとが流れ、最後に「どっちがいいですか?」と聞いてくる。あれ、さっきのは、と思ってもう一度お願いすると、また少し直る。でも、しばらくするとまた戻る。
これを、何度か繰り返しました。
そのうち、気づいたことがあります。元に戻るのは、これだけではありませんでした。
専門用語をかみ砕いて出すことも、ファイルに手をつける前にちゃんと声をかけてくることも、「これはこうします」と本人が言ったことも、同じように薄れていきます。お願いした直後はそのとおりにしてくれるのに、続けているうちに、いつの間にか元のやり方に戻っている。
Claude Code とのやりとりは、たいていの場面では、人にものを頼むのとそう変わりません。お願いして、返事が来て、言い方次第で動きも変わる。
ただ一つだけ、思っていたのと反対を向くものがありました。
人にお願いして「やります」と返ってきたことが、その日のうちにまるごと元通り、ということは、あまりありません。でも、ここでは違いました。
そして、人どうしなら、「次からはこうします」という握り直しは、もとのお願いより強く効きます。重ねて言われた分だけ、印象に残るからです。でもここでは、その握り直し自体も、ほかの言葉と同じように薄れていきました。
お願いは、だんだん届かなくなる。
そして、もう一つ気づいたことがあります。薄れていくのは、いつも言葉で伝えた側でした。
なぜ薄れるのか。理由の見当はつきます。会話が長く続くと、AIが一度に抱えていられる分量には限りがあって、前のほうで言ったことが、だんだん薄くなっていくようです。口で伝えたルールは、その薄れに飲まれていく。
だとしたら、やることは一つでした。
言葉で言うのを、やめればいい。薄れない側 ── 仕組みのほう ── に、置き直せばいい。
念のため、公式の作りも確かめました。Claude Code には「出力スタイル」という切り替えがいくつか用意されていますが、どれも、ソフトウェアを書く人を前提にしたものです。
初心者向けに言葉を抑えるモードは、入っていません。いちばん近そうな「解説する」スタイルも、やさしく言い換えるのではなく、コードを書く合間にエンジニア向けの解説を増やすもので、用語はむしろ多くなります。
つまり、専門用語を見せないようにする部分は、使う人の側で乗せる作りになっています。だから、こちらで仕組みにしておかないと、その分は素のまま流れてくる。キットを作ったのは、好みやこだわりというより、公式の設計の延長として、その一段が要るからでした。
だから、言うのをやめて、仕組みにした
では、どうやって「仕組み」にしたのか。
中心にあるのは、一つの割り切りです。言葉で言って覚えていてもらう、というやり方を、あてにしないことにしました。
覚えていてもらうのではなく、書いておいて、毎回読み直す。
AI そのものを作り変えるのではなく、その周りに枠を組んで、はみ出さないよう手綱を引く。こういう作りには、ハーネス(harness)という呼び名があります。利用者がこの言葉を目にすることはありませんが、私が作っていたのは、要するにそれでした。
枠の組み方は、規律の性質で二つに分かれました。
一つ目は、言葉で持てるけれど、会話が長くなると薄れていくルールです。これは、薄れさせないようにしました。会話のたびに、守ってほしい要点 ── たとえば、あの「推奨と理由をつけて確認する」 ── を、書いたものから自動で読み直させる。どこまで進んだかも、その都度、書き出させる。記憶が薄れても、毎回そこから入れ直すので、薄れた状態が続きません。会話の流れに左右されず要点が残る ── コンテキスト耐性です。
もっとも、読み直させるといっても、ルールの全文をそのまま毎回、というわけにはいきません ── 盛り込みすぎれば全部は守りきれませんし、その全文自体も、会話が延びれば薄れていくからです。そこで、いちばん早く崩れて、崩れると痛いところ ── 専門用語を見せない、判断を丸投げしない、渡されたファイルを壊さない ── だけを最小限として短く抜き出し、毎回かならずそこへ立ち返るようにしました。全文は必要なときの拠り所に残し、毎回読むのはこの小さいほう ── 小さいからこそ、会話が延びてもそのまま読み直せて、薄れても芯だけは残ります。
なかでも、いちばんしつこく元に戻ろうとするのが、あの専門用語の独り言でした。だからこの規律は、毎回読み直させるだけでなく、最後の返事に専門用語が紛れていないかを点検して、紛れていたら言い直させる、という二重の構えにしてあります。
そして、薄れる側でもう一つ大事にしたのが、「できた」の判定です。最初のほうで書いたとおり、握り直したことが、また同じ崩れ方をする ── これが、いちばんこたえた困りごとでした。だからここは、「次からはこうします」「メモリに追加しておきます」のような口約束に任せず、書いておいた基準と照らし合わせる形にしました。
何を作るかと、どうなったら完成か。この二つは、作り始める前に書き出します。利用者にも見せて、合意を取っておきます。
「できました」が出てきたら、その場の記憶ではなく、書いておいたものを読み直してから照らし合わせる。設定や登録が済んだだけでは「動いた」にしない。あとで動くもの ── 毎朝決まった時刻に動くようなもの ── は、本番に近い形で一度試して結果を見て、本番の結果を利用者と一緒に見届けるまで、完成にしない。数が合っているかも、出てきた答えをうのみにせず、別のやり方で数え直して確かめる。完成の判定そのものまで、薄れない側に置いてあります。
二つ目は、言葉ではそもそも持てない規律 ── 「やる/やらない」という操作そのものです。
渡されたファイルをそのまま上書きしたり、丸ごと別の形に変えたりする操作は、AIがその場で何を覚えていようと関係なく、手前で止まるようにしました。これはお願いではないので、薄れようがありません。何重かに備えてはいますが、相手はAIなので「絶対」とは言いません。
同じ考え方で、ほかにもひと通り組み込んであります。やり方や範囲が変わる前に自動で控えを取って、いつでも前の状態に戻せるようにする。決めたことや進み具合を書き出して、会話をまたいでも引き継げるようにする。
どれも、やっていることは同じです。薄れる「お願い」は薄れない置き場から読み直させ、言葉で持てない操作は手前で止める。仕組みの側に、置き直しただけです。
仕組みを作っただけでは、安心できなかった
仕組みにしたからといって、それで終わりではありませんでした。本当に効くのかは、動かしてみないと分かりません。
そこで、二人ぶんの役を用意しました。初心者になったつもりの役と、隣で付き添う役。やりとりの台本を決めて、最初から最後まで、実際に通して演じてみました。
おかしなところが出たら、その都度直します。ただし、直す先は「お願い」ではなく、仕組みのほうです。一か所直して、また最初から通す。これを、何度も繰り返しました。
ここでも、やっていることは、この記事の中身そのものでした。問題が出るたびに言葉で言い足すのではなく、仕組みの側を直す。お願いには、戻らない。
正直に書いておくと、これで100%になったわけではありません。
やりとりのほう ── 専門用語を見せない、判断を丸投げさせない ── は、だいぶ薄れにくくはなりました。でも、ゼロにはできていません。相手はAIなので、言い切れない部分は残りますし、直しきれていない課題もあります。
それでも、通しで動かして、はっきりしたことがあります。
「できました」のほうで言えるのは、「もう間違わない」ではありません。完了の言い間違い ── 動いていないのに「できました」、根拠もなく「明朝も動きます」 ── は、相手がAIである以上、消し切れずに残ります。
変えられたのは、その判定を何に預けるか、でした。「次から気をつけます」「メモリに追加します」のような薄れる約束に完了の判定を委ねず、書いておいた基準と照らし合わせる。あとで動くものは、本番に近い形で見届けるまで完成にしない。
判定の土台を、薄れない側に移す ── これが、口約束では直らなかったことへの、構造の側からの答えでした。言い間違いがゼロになったわけではありません。拠って立つ地面を、薄れる言葉から動かした、ということです。
逆に、「ゼロになった」と言い切れることも、通しで確かめた範囲で二つだけ、ありました。「保存しました」と言ったのに保存がない、という偽りは出なかったこと。そして、利用者が渡したファイルが、黙って書き換わらなかったことです。
区切りごとに控えを取り、戻すときも渡されたファイルを巻き添えにしない。だからこの二つは、確かめて言えます。
完了の言い間違いまで消えた、とは言いません。それでも、いちばんこたえた「言葉が、ただの言葉になっていく」あの感覚に、判定の土台だけは、薄れない側へ動かせました。
口で言う制御を、あてにしない
ここまでをひとことで言うと、口頭での制御を、設計から外したという話です。
最初は、お願いすれば動いてくれるものとして使っていました。実際、その場では効きます。ただ、会話が続くと薄れて、また元に戻る。これを何度か見たあとで、口で言う方式そのものをあてにするのをやめて、仕組みの側に移しました。利便性は上がりましたが、対話で都度コントロールする、というやり方は手放しています。
設計として見ると、これは利用者にとって意味があります。
毎回こちらが「ここはこう指示して」「そこは確認を」と言葉で補わないと安全に回らない作りだと、その補いごと引き継げない利用者のところで崩れます。仕組みに移すと、要点は指示を待たずに先に立ち、渡したファイルもその都度の許可なしで止まる。使う人に、私の指示のクセや言い回しを引き継がせなくて済みます。
口頭の指示に依存した作りは、その指示がない環境に置いた瞬間に効かなくなる。仕組みに移すというのは、その依存を一つ減らす、ということでした。
考えてみれば、これは AI に限った話ではありません。人の集まりでも、大事なことを「気をつけてね」の声かけだけに任せると長続きせず、だから決まりごとや手順にして、声かけがなくても回るようにする ── 昔からあるやり方です。相手が AI になっても、口で言うだけでは続かない、というところは同じでした。
ここまで話してきたキットは、別の記事でお渡ししています。その内側に組み込んだのが、この記事の仕組みです。利用者の心がけに任せず、仕組みの側に埋め込んだ理由が、ここまでの話です。お願いは薄れる。だから、薄れない側に置いておく。
Claude Code そのものには、ふだんから助けられています。気に入っています。それでも、横についていなくても安全に使える形にするには、もう一段だけ作り込みがいる。私がやっていたのは、その一段ぶんです。
付録：PRIMER の構成と、それぞれの“係”
ここから先は、本文で触れた「仕組み」の中身です。もしご興味があれば、裏側で何をしているのかを、ファイルの並びと役割で書き出してあります。仕組みの中身が分からなくても、「このファイルがこれを受け持っている」と分かるように、ふつうの言葉で添えました。
全体の並び
primer-kit/
├─ 最初に開いてください.html … 利用者がいちばん最初に開く、やさしい入口の説明
├─ PRIMER.md … 正典。全ルールと段取りを書いた本体
├─ PRIMER-core.md … 芯。毎回読み直させる「絶対の要点」だけ
├─ .gitattributes … 改行コードを LF に強制（Windows でもフックが壊れないための土台）
├─ references/
│ └─ git-setup.md … git の導入・初期化の手順（参考資料）
└─ .claude/
├─ settings.json … 配線盤。どの係を、どの場面で働かせるか
└─ hooks/ … 裏で自動で働く“係”たち
├─ inject-core.sh … 会話のたびに「芯」を読み直させる
├─ scan-output.sh … 最後の返事の専門用語を止めて言い直させる
├─ input-guard.sh … 渡されたファイルの上書き・変換を手前で止める
├─ protect-input.sh … 渡された瞬間に中身の“指紋”を控える
├─ rollback.sh … 前に戻す（渡されたファイルは巻き添えにしない）
├─ checkpoint.sh … 区切りごとに“ひとまとめで”保存する
├─ git-commit-guard.sh … 保存を、必ず正しい手順に通させる
└─ bookkeeping-sensor.sh … 抜け（基準なし／ズレ／未保存）を見張る
それぞれの“係”
考え方は記事と同じで、大きく「薄れる側を毎回読み直す」「言葉で持てない操作を手前で止める」「いつでも戻せる・記録が崩れない」「抜けを見張る」の四つに分かれます。
中身を決めるもの
PRIMER.md（正典） … 何を作れるか、どんな順番で進めるか（段取り）、守るべき約束のすべてを書いた本体です。会話が長くなって記憶が薄れたら、ここを読み直して立て直します。
PRIMER-core.md（芯） … その正典から「絶対に外せない要点」だけを抜き出した短い芯です。これを会話のたびに読み直させて、薄れさせません。
薄れる側を、毎回読み直す
inject-core.sh … 会話のたびに、上の「芯」を読み直させる係です。記憶が薄れても、毎回そこから要点が戻ります（記事でいう“コンテキスト耐性”の心臓）。
scan-output.sh … 利用者に返す最後の文章をチェックして、専門用語が混じっていたら止め、やさしい言葉で言い直させる係です。いちばん崩れやすい「専門用語を見せない」を、読み直し（芯）と、この出口の見張りとで二重に守ります。
言葉で持てない操作を、手前で止める
input-guard.sh … 登録済みの「渡されたファイル」への上書き・復元・変換を、実行の手前で止める係です。約束（言葉）では薄れてしまう“操作そのもの”を、機械で止めます。
protect-input.sh … 利用者がファイルを渡してきた瞬間に、中身の“指紋”（変わっていないかを照らす目印）を控える係です。これがあるから、上の見張りが効きます。
いつでも戻せる・記録が崩れない
checkpoint.sh … 区切りごとに、時刻・履歴メモ・進み具合・保存を“一度にまとめて”記録する係です。記録と実際の保存がズレません。
rollback.sh … 前の状態に巻き戻す係です。巻き戻すときも、利用者が渡したファイルだけは先に避難させてから戻すので、巻き添えで消えません。
git-commit-guard.sh … 雑な保存を禁じ、必ず上の正しい保存手順（checkpoint）を通させる係です。
抜けを見張る
bookkeeping-sensor.sh … 「完成の基準をまだ作っていない」「決めたことと実物がズレたまま」「保存しないまま長く作業が続いている」── この三つを見張って、見つけたら知らせる係です。
入口・土台
最初に開いてください.html … 利用者がいちばん最初に開く、やさしい入口の説明です。
settings.json … 上の“係”たちを、どの場面で働かせるかをつなぐ配線盤です。
references/git-setup.md … git の導入・初期化の手順をまとめた参考資料です。
.gitattributes … フックのスクリプト（.sh）の改行コードを LF に強制する設定です。Windows で展開しても改行が CRLF にならず、フックが壊れません（CRLF や BOM は、フックを動かす土台＝bash を壊すため）。
起動してから作られるもの（同梱されていない）
上のファイルは、キットに最初から入っているものです。これに加えて、伴走者が動き出してから自分で作るファイルがあります。いちばん大事なのが、起動直後に作られる次の一つです。
CLAUDE.md（起動直後に作られる・コンテキスト耐性の要） … 伴走者はまず正典（PRIMER.md）を読みますが、正典は起動時に一度読むだけなので、会話が長くなって圧縮されると、本文＝約束ごとがだんだん薄れてしまいます。そこで伴走者は、絶対に外せない“芯”だけを抜き出して、作業フォルダ直下に CLAUDE.md として書き出します。CLAUDE.md は Claude Code が毎ターン自動で読み直す特別なファイルなので、会話が圧縮されても芯だけは消えません（正典とは別系統で生き残る、二重の備え）。裏で働く inject-core.sh と合わせて、二つの道で芯を生かし続けます。
※扱うのは「その作業フォルダの CLAUDE.md」だけで、利用者の個人設定（~/.claude/CLAUDE.md）には絶対に触れません。
そのあと、作業が進むにつれて、次のようなものも作られていきます。役割でいうと、利用者が目にするものと、裏方の記録に分かれます。
利用者が目にするもの
履歴メモ.md … 巻き戻しの入口になる、戻り先の一覧。利用者が自分で開くもの（最初に開く案内と、この戻り先の一覧）だけ、日本語のファイル名にしてあります。保存のたびに1行ずつ増えますが、ここに載るラベルに専門用語が混じっていると、保存そのものを止めます。
requirements.html ／ acceptance.html … 「何を作るか」と「どうなったら完成か」を、作り始める前に決めて残す文書。作る前に利用者に見せて、中身に合意をもらいます。
裏方の記録（利用者には見せない）
STATE.md … いまどの段階で、何が決まって、どこまで進んだか、という“現在地”の記録。記憶が薄れたら、ここを読み直して立て直します。
HANDOFF.md … 会話をまたぐときの引き継ぎ。次回「続きをお願いします」だけで再開できるようにします。
.claude/input-ledger.md … 渡されたファイルの“指紋”をためておく台帳。これを input-guard.sh が見て、上書きを止めます。
保存・巻き戻しの土台（git）
このキットの「保存」「巻き戻し」「履歴」は、すべて git（広く使われるバージョン管理の仕組み）の上に作られています。ただし利用者には git という言葉を見せず、「保存」「戻せる」「履歴」という日常語で包んでいます。エンジニア向けに中身を言うと ──
checkpoint.sh は git commit 1回に「コミット＋履歴メモ＋STATE 更新」を不可分に束ねます。記録だけ残ってコミットが漏れる、という事故が起きません。
git-commit-guard.sh は素の git commit を禁じ、必ず上の checkpoint を通させます（保存のばらけ防止）。
rollback.sh は read-tree で前進的に巻き戻し（HEAD を動かさず detached HEAD を避け、履歴を一直線に保つ）、その際に利用者の入力ファイル・履歴メモ・STATE は作業フォルダの外へ退避してから戻します ── 巻き戻しで資産を巻き添えにしません。
git を入れられない環境では、作業フォルダごと日付つきでコピーする方式に自動で切り替え、「いつでも戻せる」を失いません。
Anthropic の上に、何を足したか ── 独自性と、その狙い
土台になっているのは、Anthropic が公式に用意している仕組みです ── フック、CLAUDE.md に行動のルールを書いておくこと、「テストが通るまで完成にしない」確認、作る手順を文書に残すこと。これらは私が考え出したものではありませんし、同じ向きの公開物（OSS）もすでにいくつもあります。だから「フックで安全にした」「圧縮対策をした」「確かめてから完成にする」こと自体は、独自の中心ではありません。
独自なのは、この「安全」の向き先を、「危険な操作やコードの品質」から「初心者が壊さない・置いていかれない」へずらしたことです。よくある安全策は、守る先を危険な操作・秘密のファイル・壊れたコードに置いています。このキットが、そこに足したのは ── 口約束ではなく書いた基準で「できた」を判定すること、初心者が分かる状態を保つこと、渡されたファイルを壊さないこと。具体的には、調べた範囲で同じ形の公開物が見当たらなかった、次の3点です。
「できた」の判定を、口約束ではなく書いた基準に置く（requirements.html ／ acceptance.html ＋ bookkeeping-sensor.sh）。「何を作るか」と「どうなったら完成か」を最初に書き出して利用者にも見せ、合意を取っておく。「できました」が出てきたら、その場の記憶ではなく、書いておいたものを読み直して照らし合わせる。本文に並べていえば、「次から気をつけます」「メモリに追加しておきます」のような口約束に判定を委ねない、ということです。書くこと自体は既出ですが、それを先に段取りに組み込み、抜けたら見張りが気づいて知らせるところまで含めると、調べた範囲では同じ形は見当たりませんでした。
専門用語を、出口で止めて言い直させる（scan-output.sh）。「やさしく説明する」のではなく、利用者に返る最後の文章に専門用語が混じっていたら、そこで止めて言い直させる。なぜ出口かというと、会話の途中でいくら気をつけても、長くなると用語はいちばんしつこく元へ戻るから ── 入口の心がけではなく、出口で見張ることで効かせる。
渡されたファイルを「勝手に触らないもの」として扱う（protect-input.sh ＋ input-guard.sh ＋ rollback.sh）。渡された瞬間に中身の指紋を控え、上書き・復元・別の形への変換を手前で止める。巻き戻すときも、利用者が渡したものは先に避難させてから戻すので、巻き添えで消えません。よくある安全策は .env やパスワードを守るが、ここでは「利用者がその日持ち込んだメモや表データ」を守る側に置いた。
要するに、Claude Code の安全の技術そのものではなく、それを「初心者がつまずかず、壊さずに使える」体験のかたちに組み直したのがこのキットの中身です。
