nyabicode
AI活用13 分で読めます

Opus 5 に替えた途端、AI が手順を飛ばし始めた ― 原因はルールの書き方ではなかった

Opus 5 に替えた日から、Claude Code が過去の決定を忘れ、決めた手順を飛ばすようになった。自分のルールの書き方が悪いと思って量を減らしたが、効かなかった。壊れていたのはルールではなく、その下の土台だった。

積み重なった細い線の層とその下を支える一本の帯、離れた下方に横たわるもう一本の線、右側に散らばる短い印を描いた抽象イラスト

Opus 5 に替えた日から、私の指示が通らなくなりました。過去に決めたことを忘れ、決めた手順を飛ばす。原因は自分のルールの書き方だと思って量を減らしましたが、効きませんでした。壊れていたのはルールではなく、その下にあった土台のほうでした。

Opus 5 に替えた日から、話が通じなくなった

Opus 5 という新しいモデルが出たので、さっそく自分の開発に使ってみました。私は Claude Code という AI 開発ツールで、為替や株のツールを個人で作っています。作業のやり方はドキュメントにまとめてあって、AI にはそれを読んでから動いてもらう、という運用です。

使い始めてすぐ、様子がおかしいことに気づきました。

それまで期待できたこと新しいモデルで起きたこと
過去に決めたことを踏まえて動く✗ 決定を忘れて、決め直そうとする
決めた手順どおりに締める✗ 手順を飛ばす
ドキュメントを読んでから作業する✗ 読めば分かることを、やらない
いまの状態を把握したうえで提案する✗ 提案してきたので許可したら「すでに実装されていました」

最後の行が、いちばん多く起きました。「次はこれをやりましょう」と提案してくるので「お願いします」と答えると、しばらくして「すでに実装されていました」と返ってくる。提案した時点で、自分が何を作り終えているかを把握できていないわけです。

決定的だったのは、セッションの締めくくりでした。私は作業の終わりに決まった手順を踏むことにしています。記録を残して、状態を実態に合わせて、まとめて保存する、という一連の流れです。手順書もあります。それが飛ばされたとき、はっきり分かりました。

これは、うっかりではない。ルールを読んで守る、ということ自体をしなくなっている。

気づいたぶんは、その場で指摘しました。ただ、これがまた地味に効きます。指摘のたびに会話は長くなり、AI の利用枠は指摘のぶんだけ削られていく。本来やりたかった作業に使えたはずの余力が、軌道修正に消えていきました。

そして、もっと嫌なことがあります。

最初の誤診 ― 「ルールが多すぎるせいだ」

原因をどこに求めたか。私が最初に疑ったのは、自分のルールの量でした。

長く使ううちに、ドキュメントは確実に増えていました。決めごとが積もり、手順書が増え、読ませるものが厚くなっていく。「これだけあれば、そりゃ読み飛ばすよな」と考えるのは自然でした。

そこで、やったことがこれです。

  1. ドキュメント全体を棚卸しした
  2. もう効いていない決めごとを見つけて畳んだ
  3. 常に読ませる部分をスリム化した

作業としては、まったく正しかったと思っています。実際、書類は読みやすくなりました。

ただし、目的だった症状には効きませんでした。 減らしても、手順は飛ばされる。過去の決定は、やはり忘れられる。

ここで「なぜ効かなかったのか」を二段階で考える必要がありました。

一段目は分かりやすい話です。量が問題ではなかったからです。読ませる文字数を減らしても、読んで守るという行動そのものが起きないなら、減らした意味はありません。

二段目が本題でした。私のルールは、そもそも単独で立っていなかったのです。

本当の原因 ― ルールが寄りかかっていた土台が痩せた

AI に指示を出すとき、効いている文章は自分が書いたものだけではありません。その手前に、AI 側があらかじめ持っている前提の文章があります。「作業の前に確認しなさい」「答えは整理して返しなさい」といった、いわば標準装備の心得です。

私のルールは、その上に積んでありました。「言われなくてもやること」があらかじめある前提で、「さらにこうしてほしい」と書いていたわけです。

そして新しいモデルでは、その標準装備が大きく削られたと報告されています。同じ症状を詳しく検証した 外部の記事 によれば、削減はおよそ 8 割。さらに「情報が揃ったなら、確認を待たずに行動してよい」という趣旨の指示が新しく入りました。私はこの削減幅を自分で計測したわけではありません。ただ、自分の環境で観測した崩れ方は、この報告とほとんど一致していました。

こう並べると、私が見ていた症状の説明がつきます。

私が見た症状土台の側で起きたこと
確認せずに実装が始まる「揃ったら行動してよい」が新しく入った
手順を飛ばす「決められた手順に従う」の前提が薄くなった
ドキュメントを読まない読んでから動く、が標準装備でなくなった

つまり、私のルールが壊れたのではありません。ルールが寄りかかっていた土台が抜けて、宙に浮いたのです。

支えが消えたとき、その上に積んだものは倒れる。倒れたほうを直しても、支えは戻らない。

そう分かると、ドキュメントを減らしても効かなかった理由がはっきりします。私は倒れたものを積み直していただけで、抜けた支えのほうには一度も手を触れていませんでした。

直し方① 「何を書くか」ではなく「いつ届くか」を変えた

先に断っておくと、ここから紹介する 2 つの対処は私が考えたものではありません。 症状を調べる過程でたどり着いた、さきほどの検証記事に書かれていた対処です。私がやったのは、それを自分のワークスペースへ持ち込んで、本当に効くのかを見届けたところまでです。

記事が示していた要点は単純でした。効かなくなったルールを強く書き直すのではなく、届く場所を変える。

それまで私のルールは、AI が作業前に読むドキュメントの中にありました。これは読みに行かないと目に入らない場所です。土台が元気なうちは、それでも守られていました。読んで守るのが標準装備だったからです。標準装備が抜けた今、同じ場所に置いておくのは、届かない前提で手紙を出し続けるようなものでした。

これを自分の環境に当てはめると、こうなります。

それまで変えた後
どこに書くか作業前に読むドキュメント私が発言するたび、その直後
いつ届くか読みに行ったとき毎回、必ず
どれくらい全ルール4 行だけ

Claude Code には フック(hooks)という、決まったタイミングで自動的に処理を挟み込む公式の仕組みがあります。私はそこに、私が何か話しかけるたび、AI がそれを読む直前に 4 行を差し込む設定を入れました。中身はこういうものです。

- ツール実行より先に、この発言への返答を本文で書く
- 質問・相談なら、回答して止まる(作業に入らない)
- 報告は見出しや表で構造化し、原因は 2 階層まで掘る
- 一度立てた区分や番号は、同じ作業のあいだ変えない

読み返すと、当たり前のことしか書いていません。当たり前のことが標準装備から抜けたので、当たり前のことを毎回言うようにした、というだけの話です。

自分で決めたのは、ここから先の運用の作法だけです。 ひとつは 4 行を上限にすること。毎回の発言に差し込む以上、長いほど毎回の負担になります。増やしたくなったら別の場所でやる、と決めました。もうひとつは、この仕組みが壊れても作業は止めないこと。安全装置のつもりが作業を止める障害物になったら本末転倒だからです。

差し込みが実際に何回起きたかは記録に残しています。

04 行が差し込まれた回数
41 回あたりの行数(上限)
0崩れてからの日数

直し方② 相手の文言を名指しで打ち消した

もうひとつも、同じ記事から借りた手です。こちらのほうが、正直あまり品のいいやり方ではありません。

新しい土台には「情報が揃ったなら確認を待たずに行動してよい」という趣旨の指示が入っている、と書きました。私のルールは逆で、「議論の途中では着手しない」です。真正面からぶつかっています。

私が最初に書いていたのは、一般的な優先順位の宣言でした。「向こうの指示と私のルールが矛盾したら、私のルールを優先すること」。これは効きませんでした。理由は考えれば当たり前で、どれとどれが矛盾しているのかを、その場で判断させているからです。判断を挟めば、判断は揺れます。

記事が採っていたのは、もっと直接的な方法でした。ぶつかっている向こう側の文章を、そのまま 4 つ引用して並べ、「この 4 つとぶつかったときは、こちらが勝つ」と名指しで書く。 真似してみると、今度は通りました。

曖昧に「私を優先して」と書くと負ける。相手の原文を引用して打ち消すと通る。

一般論は、矛盾の中では弱い。名指しは強い。これは私が見つけたことではなく、借りた手が自分の環境でも同じように効いた、という確認です。

現在地 ― 良くはなった。でも、まだ信じきれていない

崩れに気づいてから 2 週間が経ちました。正直なところを書きます。

対策の効果は、はっきりありました。 気のせいという程度ではなく、明確に良くなりました。確認せずに走り出すことは減り、報告は整理された形で返ってくるようになりました。

それでも、私はまだ元どおりには使っていません。

作業いま誰にやらせているか理由
設計・議論Fable 5(別のモデル)手順を守ったうえで精度が高い
実装Fable 5 の枠がある限り Fable 5本音を言えば、枠がある範囲は全部こちらに任せたい
実装(枠切れ時)Opus 5週の利用制限に当たったら戻る

つまり私がやっているのは、直したというより、余力のある範囲で別のモデルへ逃がしているという状態です。対策が効いたのは事実で、それでも信用は戻りきっていません。良くなった度合いと、任せられる度合いは、別のものでした。

そして最初に書いた不安は、いまも消えていません。気づかないまま過去の決定を無視して作られたものが、どこかに残っているかどうか。それを確かめる方法を、私はまだ持っていません。

モデルは道具ではなく、前提でした。前提が入れ替われば、その上に積んだものは全部いちど点検が要る。今回いちばん高くついた思い込みは、「自分の書いたルールは、自分の書いたとおりに効き続ける」というものでした。

同じ状況にいる人へ、ひとつだけ持ち帰るとしたら、これだと思います。指示は、強く書いたから通るのではありません。行動する瞬間に手元にあるから通ります。 私は 2 週間かけて、ようやくそこに手を触れました。

速く作れるほど、中身が分からなくなる確かめられないまま動いているものが増えていく、という同じ不安を扱った記事。

🐾 にゃびに聞く

シェアX でポストLINE

この記事が役に立ったら、投げ銭で応援してもらえるとうれしいです

応援する