0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIへの頼み方が正反対になった 失敗を自分で仕組みに変える自己拡張ナレッジベース

0
Posted at

Claude Code を1年以上、日々の開発で使ってきた。そのなかでここ最近いちばん変わったのが、AIへの頼み方だ。正反対になった。

以前は、コマンドを自分で選んで叩き、要件を箇条書きにして、「このスキルを使って」と名指ししていた。丁寧に指示しないと失敗する、と思っていたからだ。今は逆で、「commit」とか「これ進めといて」とか、一言だけ投げる。

それでも回るのは、失敗が、AI自身の手でルールに変わっていく仕組みを作ったからだ。この記事では、その中身と、そこに至るまでに頼み方がどう変わっていったのかを書いてみたいと思う。

先に用語だけ。ここで言う hook とは、Claude Code が決まったタイミング(セッションを開いた時・メッセージを送った時・応答が終わった時など)で自動実行する小さなスクリプトのことだ。これが今回の主役になる。

丁寧に頼んでも、同じミスが何度も戻ってくる

最初の頃のプロンプトはこんな調子だった。「やり残しを全部 issue にして。デザインはもっとリッチに、制限時間は15秒に」。手順も数値も、使うコマンドも、全部自分で指定する。それが正しい頼み方だと思っていた。

でも、同じミスが何度も戻ってきた。分かりやすい例がコミットだ。「マージまで進めて」と頼むと、AIが勝手に共同作者(Co-authored-by)のタグを付けてコミットする。指摘する。直る。数日後、別のセッションで、まったく同じことをやる。新しいセッションのAIは、前のセッションで私が同じ注意をしたことを知らないからだ。同じ小言を、私は何度も打っていた。

原因ははっきりしている。私の注意は、そのセッションの会話の中にしか残らない。新しいセッションが立ち上がると、AIはまっさらな状態から始まるので、前に同じことを何度言われたかを知らない。ミスの反省がセッションをまたいで蓄積しない、これが根っこだった。頼み方を丁寧にしても、一回きりで消える注意を毎回打ち直しているだけで、繰り返しは止まらなかった。

頼み方を反転させる 「なぜできなかったか」を説明させる

ある時から、頼み方を反対にした。丁寧に指示するのをやめて、雑に投げる。そして、できていなかったら原因を本人に説明させる。実際に私が送っていたのはこういうメッセージだ。

あなたは今回スキルを無視して進めましたか?なぜ失敗したのか分析してください。

原因を言わせたら、次にこう続ける。

今後こういうミスをしないように、恒久対応をしてから進めてください。新しく立ち上がったセッションが、以降こういうミスをしないように。

肝は最後の一文だ。「私が気をつける」ではなく、「次のセッションのAIが二度とやらないように、仕組みを直しておけ」。とはいえ、当時はこう頼んでも空振りだった。直した仕組みを置いておく先が無かったからだ。この落とし先を用意して初めて、この頼み方が効き始めた。それが以下の hooks になる。

全体像 文書ではなく、行動に割り込ませる

知識を「文書として置いておく」のをやめて、行動の瞬間に hook で割り込ませることにした。割り込みには強さの違う3種類がある。

種類 動くタイミング やること 強さ
読み込ませる セッション開始時 自分用メモの目次を丸ごと会話に載せる 弱い(載せるだけ・忘れられる)
止める 危ない操作の直前 まずい書き込みやコマンドを差し戻す 強い(行動を物理的に止める)
振り返らせる 応答が終わったあと 3ターンに1回「学びがあれば今書け」と迫る 中(定期的に問う)

そして、この記事でいちばん伝えたいのはここだ。「振り返らせる」で拾った失敗を、AI自身が1行のルールとして書き足し、次からその状況で自動的に注意が飛ぶようにできる。 新しい hook を人間が書き起こすのではなく、AIが自分でルールを増やしていく。だから、失敗するほど、仕組みのほうが少しずつ育っていく。図にすると、こんなイメージになる。

   雑に投げる(「commit」)
        │
        ▼
   AIがしくじる(余計なタグを付けてコミット)
        │
        ▼
   応答の終わり(3ターンに1回)、hook が「学びがあれば今書け」と迫る
        │
        ▼
   AIが原因を書き、ルールを1行追加する
        │
        ▼
   次に同じ状況 → こちらの一言に自動で割り込む
        │
        └──────►  次は雑に投げても、同じ失敗をしにくくなる

残りの節では、この各段が実際にどう書かれているのかを、順に見ていきたい。

実装① ルールを「コード」ではなく「データ」にする

このループの心臓は、ルールの持ち方だ。

以前は、新しいルールを増やすたびに専用の hook スクリプトを1本書いて、設定ファイルに配線していた。落とし穴は、hook の新規配線には私の承認が挟まること。hook はシェルコマンドをそのまま実行できるので、Claude Code は新しい hook を登録する前に必ず確認を出す。つまりAIが自分の判断だけではルールを足せない。「AIが自分を直す」ループが、人間の承認待ちで止まってしまう。

そこでルールをコードからデータに移した。rules.jsonl という1行1ルールのファイルに、当たり判定の正規表現(trigger)と、当たったときに出す指示(directive)だけを書く。

{"id":"共有文面の規律","trigger":"LINE|メール|文面|投稿|tweet","directive":"人に送る文面には裏取り済みのURLを添える。数値は確認せず断定しない。"}

こちらがメッセージを送るたびに、たった1本の hook がこのファイルを全部読んで、正規表現が当たった行の指示だけを会話に差し込む。中身はこれだけだ。

if printf '%s' "$prompt" | grep -Eiq -- "$trig"; then
  d="$(printf '%s' "$line" | jq -r '.directive')"
  out+="【${id}${d}"      # 当たった指示をAIに注入
fi

この形にした瞬間、「新しいルールを足す」が「JSONを1行足す」に変わった。rules.jsonl の追記は、AIがふだんやっているただのファイル編集と同じで、シェル実行が絡まないから承認の壁に当たらない。ループが止まらなくなったのは、ほぼこの一手のおかげだと思っている。なお、危ない操作を物理的にブロックする「止める」系は、これとは別に、承認して作った専用 hook が担っている。AIが自分で足せるのは、この rules.jsonl の“注意を促す”層までだ。

実装② 毎回、終わりに振り返らせる

「学びがあれば書け」と迫る hook は、AIの応答が3回終わるごとに、次のような文面を自動で差し込む(実際に使っている文面を短くしたもの)。3という数字に理論的な根拠はない。毎回だと出力が増えすぎ、間隔が空きすぎると直近の失敗を忘れる。試して落ち着いたのが3だった、というだけだ。

直近の作業を振り返れ。記録すべき学び(ミスの原因と再発防止・
新しい慣例)が出ていれば、"今" 該当ファイルに書け。
常時守らせたいルールは、散文でなく rules.jsonl に1行足して配線しろ。
本当に何も無ければ、何も書かず「記録対象なし」と言って終われ。

最後の一行が効いている。この一行を入れる前は、とくに学びの無い回でも「〇〇に気をつけるとよい」といった当たり障りのない一般論をAIが捻り出して、メモを汚していた。「無ければ書くな」を同じ文面に同居させてから、それが止まった。この振り返りが、さっきの「なぜ失敗したか分析して」を、私が毎回打たなくても自動で回してくれる部分だ。

実際にどう回ったか

面白いのは、この配線がきれいな設計ではなく、ほぼ全部失敗の後追いで生えていることだ。3つ挙げる。ただし「誰が配線したか」は同じではない。

雑に頼んだこと AIがしくじったこと 配線された恒久対応 配線したのは
「マージまで進めて」 コミットに AI の署名(共同作者タグ)を勝手に付ける コミットに AI の署名が混ざっていたら差し戻す hook AIが提案、私が承認
「Slackとメールを確認して」 私の作業メモを見ずに答えた(見る約束だった) 作業に入る前にメモを読ませる hook AIが提案、私が承認
「審査用のスクショを差し替えといて」 並び順がバラバラなのに「できました」と報告 「提出前に順番と枚数を点検してから完了と言う」ルール AIが rules.jsonl に自分で1行追加(承認なし)

前の2つは、AIが「こういう hook を足しましょう」と提案し、私が承認して入れた。hook を新しく作るには承認が要るからだ(実装①で触れた通り)。3つ目だけが違う。スクショの件で3回続けて直させたあと、AIが自分の反省を rules.jsonl に1行足した。私は承認すらしていない。ルールをデータにしたことで初めて、失敗から恒久対応までがAIの手の中で閉じた。ここがこの記事のコアだ。

まとめ

日々の頼み方を磨くのはやめた。プロンプトをどれだけ丁寧にしても、その注意はそのセッションの中だけで消えてしまう。効いたのは、失敗を仕組みに変える経路をあらかじめ作っておくことだった。雑に頼めるのは横着だからではなく、雑に頼んで失敗しても、その失敗が次のルールになると分かっているからだ。

同じように「毎回同じ小言を言っている」感覚があるなら、いちばん小さいところから試すといい。何度言っても効かない注意をひとつ選んで、それをセッション開始時か、メッセージ送信時に自動で差し込む hook に移してみる。文書に書いておくのと、行動の瞬間に差し込むのとで、効き方がどれだけ違うか。あとは失敗するたびに1行ずつ足していく。ただし、学びの無い回に無理やり書かせない歯止めだけは、忘れずに。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?