「Claude 5」時代は余計な設定は削る

Anthropicの中の人が、7月末に以下のように書いていた。

削ったら劣化する、ではなく、削っても劣化しない。

理由は、モデルの判断力が上がったから。

以前は最悪の事態を避けるために強い制約が必要だったが、今はその多くを消して、判断に任せて良い、と。

しかも、Claude Codeを作ったBoris Cherny氏が、Opus 5公開直後のインタビューでこうも言っている（訳は以下同じ）。

過去のモデルに必要だった指示が、今のモデルには要らないかも知れないから、って理由で。

これまでとの違いを簡単に図にすると、こういうことになる。

作った本人が消せと言っているので、実際に削ってみた。

設定にコードの話はほとんど無い

まず、自分の環境から。

ObsidianのvaultをClaude Codeで扱っていて、あちこちに指示を書き溜めている。

眺めてみると、コーディングについて書かれた部分がほとんど無い。

書いてあるのは、日本語でどう返してほしいかと、ノートやファイルをどう扱うか。

元記事もインタビューも、コーディングが前提なので、効き方は違うかも知れないと思いつつ、作業に入る。

守られないから、足していた

最初に見つかったのが、矛盾。

どう返してほしいかについて、指示が3つに増えていた。

グローバル設定、プロジェクト設定、自動メモリ。

増えた経緯もハッキリしている。

書いてあるのに口調がちょくちょく変わるので、その都度こう返してほしいと指示する。

すると、既にある記述を直すのではなく、追加で書き足される。

それを繰り返した結果が3箇所。

しかも、簡潔に答えろ、と、丁寧に説明しろ、が別々の場所に入っている。

毎回この3つを突き合わせて、落とし所を探している状態だった。

口調程度でと、思われるかも知れないが、日常的にやり取りする中で、返答の口調というのは、快適さや効率に大きく関係する。

それがClaude 5になってから、口調がぶれること自体が無くなっている。

古いモデルの弱点を埋めるための積み上げが、そのまま残っていた。

解消の仕方は「どちらかを消す」ではない。

適用場面を書き足しただけ。

• 質問に答えるとき → 聞かれたことだけ。網羅列挙しない

• 作業の提案・ファイルを消す前 → 情報を省かず丁寧に

矛盾は、片方が間違っているのではなく、適用範囲が書かれていないだけ。

そういうことが、けっこう多い。

vaultの外も見てもらった

3箇所のうち、2箇所はvaultの中では無い。

グローバル設定と自動メモリは、Claude Code本体側にある。

なので、そちらも合わせて確認してほしいと頼む。

vault内のみの整理では、口調の指示は外に残ったままなので、それだけだと矛盾は解消できない。

範囲を広げたのは、日本語でやり取りしているから。

応答の調子や説明量が、そのまま成果物の質になる。

コードを書かせているだけなら、口調が多少ぶれても困らない。

日本語で使っているからこそ、出力スタイルの矛盾が問題になった。

同じ表が4箇所にあった

次が、重複。

同じフォルダ構成の表が、4箇所に複製されていた。

Claude Codeは、Obsidian以外にも、Zedで開いている仕事のプロジェクトなどでも使っている。

今回見たのはObsidianのvault内だけで、その中だけでこの数。

Claude CodeとCodexの両方で扱っているので、同じ内容を2セット持てば、当然そうなる。

おまけに、それぞれが「正本は別の場所にある」と注記しながら、全文をコピーしている。

コレが一番危ない。

正本は別にあると書いてあるので安心してしまうが、実際には同期されない。

事実、毎日書くノートへの追記手順が、設定ファイル側だけ古いまま放置されていた。

複製すると、正本となる片方だけが、更新される。

置き場所が増えるほど、こうなる確率は上がる。

定期的に見直す必要性を、改めて感じた部分でもある。

削るかどうかは「行数×頻度」

一律に削ったのかというと、そうではない。

Obsidian開発者のkepano氏が公開している「obsidian-skills」を5つ入れていて、そのうち1つは395行と長い。

これは触らず、更新の取り込みだけにした。

必要な時に読まれる便利なものだし、手を入れると次の更新が面倒になる。

自分で書いたものと、他人から借りたものは、扱いを変える。

そしてもうひとつ、判断基準がある。

設定ファイルは毎回読み込まれる。

だから何行書いてあるかが、そのまま毎回の消費になる。

対してスキルは、必要な時にしか開かれない。

同じ400行でも、削る価値がまったく違う。

削減対象は「行数」ではなく「行数×読み込まれる頻度」で選ぶ。

上記インタビューでも、同じ理由が挙げられている。

結果として、設定・定義ファイル全体で約1,700行が250行程度になった。

とはいえ、この数字自体はあまり重要ではない。

大半が重複の解消なので、実質は2セットを1セットにしただけ。

やり取りが簡潔に

削った結果、どうなったか？

元記事の評価軸は「コーディング評価に測定可能な劣化は無かった」。

コードは動くか動かないかで白黒がつくから、80%削っても劣化しなかったと数字で言える。

ノートの整理や調べものには、その判定基準が無い。

代わりに何が起きるかというと、「そうじゃなくて」と打ち直す回数として出てくる。

そして、こちらは明確に減った。

聞いたことに対して、目的の答えが返ってくるまでが短い。

削っても質は落ちない、どころではなく、辿り着くまでが速くなった。

理由は明らか。

矛盾した指示が3箇所にあれば、毎回それを突き合わせて、落とし所を探すことになる。

コードなら、結果が多少ぶれても、動けば正解。

しかし、日本語の応答では、結果がそのまま出力の調子になる。

聞いただけなのに長い説明が返ってきたり、逆に説明してほしい時に一行で終わったり。

そのたびに、打ち直すことになる。

矛盾を消したのは、判断を任せたというより、迷う理由を取り除いたということ。

上記インタビューでも、社内でシステムプロンプトを全部消す実験をした結果として、こう言っている。

以前の「/insights」コマンドで見直す、という投稿。

投稿時は、足りない指示を足して往復を減らした。

今回は、多すぎる指示を削って往復を減らしている。

正反対のアプローチで、同じ着地。

書いておく必要が無くなった

ここまでは、設定ファイル側の、問題の修正と削除。

削れた理由は、もうひとつある。

以前は、書いておかないと拾ってくれなかった。

だからフォルダの一覧を書き、決まりごとを書き写した。

Claude 5時代は、やり取りの中から推測して拾ってくれる。

ファイル作成時、内容に即したフォルダを提案し、そこに作成。

フォルダ名を並べた表は消し、置き場所に迷った時の判断基準だけ残す。

記録の扱いも変わった。

「学びが5件以上溜まったら設定に反映することを提案する」というルールを消したら、設定に転記する代わりに、記録そのものを読みに来るようになった。

あらかじめ書き写しておく工程が、不要になっている。

消して、使って、つまずいたら戻す

上記インタビューで、消した後の手順まで語られている。

まず消し、次に使う。

早めに戻してはいけない、とも。

モデルが本当にその指示を必要としているか、確認できるまで待つ。

先回りして書いておくのではなく、困ってから足す。

今のところ、削って困った所は出てない。

細かく書くほど逆効果

上記インタビューの中で、よくある失敗として挙げられていたのが、過剰に具体的な指示。

代わりに何をするか。

タスクと、守ってほしい範囲と、終わりの条件を伝えて、あとは任せる。

長年コードを書いてきた人ほどこの失敗をしやすい、とも言っている。

昔のシステム開発では、そう作るのが正しかったから。

同僚に頼むくらいの感覚で良い、というのが今の水準らしい。

削れば誰でも良くなる、訳ではない。

効いたのは、指示が多いからではなく、指示同士が衝突していたから。

矛盾が無ければ、量が多くても素直に動く。

ただ、細かく書き込んでいる設定ほど、いつ書いたものか分からなくなってしまっているのではないか？

実際、削ったもののいくつかは、今のモデルには必要の無いものだった。

増える仕組みそのものを止めた

最後にもうひとつ。

作業をしていて、承認の許可リストも同じように膨らんでいるのを見つけた。

こちらもスリム化していく予定なので、それはまた別で書く。

それとは別に、その日の最後に自分で書いたルールを見つけた。

やり取りの記録が5件以上溜まったら、設定ファイルへの反映を提案する、というもの。

記録は毎回溜まっていくので、放っておけば設定は増える一方になる。

そしてこの日、まさにそのルールが働いて、設定に足しませんか?と提案された。

丸一日削り続けた直後に。

もちろん足さずに、そのルール自体を消した。

削って2行減っただけ、と言えばそれまで。

しかし性質が違う。

それまでは、増えたものを削っていた。

この2行の削除は、増える仕組みそのものを止めている。

対処ではなく、予防。

モデルは賢くなり続ける

設定ファイルは、放っておくと増える。

承認するたびに記録が残り、溜まったら追加を検討するルールがあり、定期的に増えていく反面、削る手順が無い。

増える経路だけが用意され、減る経路が無い。

一方で、モデルは新しいものが出るたびに賢くなっている。

口調がぶれるから足した3つの指示も、ぶれなくなった時点で役目は終わっていた。

書いた当時は正しかったものが、そのまま残って足を引っ張る。

だから、新しいモデルが出たら設定も見直す。

作った本人が6か月ごとに消せと言っているのだから、それくらいの頻度でちょうど良い。

消してみて、困ったら戻す。

それだけで、毎日のやり取りが軽くなる。