@hc_terashima(Kazuhiro Terashima)in

株式会社hautecouture

高性能モデルFableには不要！？AIエージェント用の「親切すぎる設定」が高性能モデルの邪魔になる

Last updated at 2026-07-06Posted at 2026-07-06

高性能モデルFableには不要！？AIエージェント用の「親切すぎる設定」が高性能モデルの邪魔

TL;DR

軽量モデルや低コストモデルでは、 詳細なルール、記憶検索、レビュー強制、手順化された skill はかなり効く 。
しかし高性能モデルでは、それらの足場が高性能モデルFableの 「探索・思考の自由度」を下げ、古い知見や過剰な手順に引っ張る ことがある
今回、ユーザーレベルの AI 設定を棚卸ししたところ、~/.agents を起点に Claude / Codex / Gemini へ共通ルールを配布する構成になっていた
有用だった設計は 「記憶を外部化すること」 だったが、問題になり得るのは 「常に思い出させること」 だった
高性能モデル向けには、 常時注入ではなく、段階的ロード、必要時 recall、根拠優先、設定の軽量モード が必要になる
2026年の AGENTS.md 評価研究でも、リポジトリ文脈ファイルは 一般には成功率を改善せず、推論コストを平均 20% 超増やす と報告されている
つまり問題は「設定ファイルが悪い」ではなく、 「always-on の文脈を増やしすぎると、賢いモデルほど真面目に従いすぎる」 ことにある
さらに、Fable のような高性能モデルを常時使うと使用量が先に枯渇するため、Sonnet / Opus へ適宜委任する 「モデル予算設計」 も必要になる

図のイメージは「全部入りの親切な設定が、今読むべきコードを見えにくくしている」状態だ。特定のアニメ作品やミームそのものではなく、日本アニメ風の比喩として生成した。

概要

AI コーディングエージェントを長く使っていると、最初は「もっと覚えていてほしい」「毎回同じ注意を守ってほしい」と感じる。そこでグローバルルール、memory、skill、hook、外部DB、レビュー用 wrapper などを整備して、優先順位のない情報が増えていく。

これは軽量モデルや低コストモデルにはよく効く。モデルが忘れやすいこと、判断がぶれやすいこと、手順を省略しがちなことを、外側の設定で補えるからだ。

一方で、高性能モデルを使うと見え方が変わる。モデル自身が十分に読解・探索・設計判断できる場合、過去に作った「補助輪」が、むしろ判断を狭めることがある。

この記事では、実際のユーザーレベル AI 設定を棚卸ししながら、なぜ「賢いモデルほど、既存の知見や superpower 的な設定が邪魔になる場合があるのか」を整理する。

この記事で一番言いたいこと: 設定を捨てる話ではない。 常時渡す情報を減らし、必要なときだけ取りに行かせる設計へ変える という棚卸しのススメだ。

ここでいう高性能モデルには、将来的なモデルや、この記事執筆時点で一部環境だけで使われているモデルも含める。特定モデルのベンチマーク比較ではなく、エージェント設定設計の話として扱う。

この記事の外部根拠

この記事は個人の WSL 環境の棚卸しを出発点にしているが、問題意識自体はかなり一般化してきている。

2026年7月時点で、主要な AI コーディングエージェントは「永続的なルール」「プロジェクト文脈」「memory」「skill」「hook」を持つ方向に進んでいる。

Claude Code は、CLAUDE.md と auto memory をセッション開始時に読み込む仕組みを公式 docs で説明している。ただし同じ docs では、CLAUDE.md と memory は強制設定ではなく context として扱われること、指示は具体的で簡潔なほど従われやすいこと、複数ステップの手順や一部領域だけに関係する内容は skill や path-scoped rule へ移すことも示している。
参考: How Claude remembers your project
Claude Code の skill docs では、CLAUDE.md と違って skill 本体は使うときだけロードされるため、長い参照資料を常時 context に置かなくてよい、と説明されている。
参考: Extend Claude with skills
Claude Code hooks は、セッション開始、turn ごと、tool call ごとなどの lifecycle で自動実行できる。これは安全制御には強いが、使い方次第では毎回 context に介入する面もある。
参考: Hooks reference
Codex は ~/.codex/AGENTS.md にグローバルな作業合意を書き、リポジトリやサブディレクトリの AGENTS.md / AGENTS.override.md と重ねる設計を公式 docs で説明している。デフォルトでは合算サイズにも上限がある。
参考: Custom instructions with AGENTS.md - Codex
AGENTS.md は、README とは別に AI coding agent 向けの指示を書くためのオープンな形式として広がっており、公式サイトでは 60k を超える open-source project で使われていると説明されている。
参考: AGENTS.md
Anthropic は context engineering を、system instructions、tools、MCP、外部データ、履歴など、モデルに渡る token 全体を管理する問題として整理している。
参考: Effective context engineering for AI agents

そして、単に「長い context はコストが高い」というだけでなく、品質にも効く。

Lost in the Middle は、長い context 内の関連情報の位置によって性能が大きく落ちること、特に中央付近の情報を安定して使えないことを示した。
参考: Lost in the Middle: How Language Models Use Long Contexts
Chroma の Context Rot は、入力長そのものを増やすだけでも性能が落ちることを、条件を制御した実験で示している。
参考: Context Rot: How Increasing Input Tokens Impacts LLM Performance
2026年2月提出、6月改訂の Evaluating AGENTS.md は、AGENTS.md のような repository-level context file を複数の coding agent / LLM で評価し、「一般には成功率を改善せず、推論コストを平均 20% 超増やす」と報告している。重要なのは、エージェントが指示を無視したのではなく、指示によって探索やテストが広がり、タスクが重くなる傾向が観測された点だ。
参考: Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
Anthropic の公開情報では、Claude Fable 5 は claude-fable-5 として API 利用でき、価格は入力 $10 / MTok、出力 $50 / MTok とされている。また 2026年7月1日の案内では、Pro / Max / Team / 一部 Enterprise では 2026年7月7日まで週次使用上限の 50% まで含まれ、その後は usage credits で利用する形になると説明されている。
参考: Claude Fable 5 and Claude Mythos 5 - Anthropic / Redeploying Claude Fable 5 - Anthropic

この外部情報から言えるのは、 「設定ファイルを書くな」ではない 。むしろ逆で、設定ファイル、memory、skill、hook は実務上かなり重要になっている。

ただし、 always-on にする情報と、必要時だけ呼ぶ情報を分けないと 、エージェントは古い前提や過剰な手順まで真面目に処理してしまう。同じように、 常時使うモデルと、必要時だけ呼ぶモデルも分けないと 、高性能モデルの利用枠や課金枠を先に使い切ってしまう。

棚卸しした設定

今回確認したのは、ユーザー環境に置かれている AI エージェント向けの設定群だ。

対象	役割	記事内での扱い
`~/.agents/`	Claude / Codex / Gemini 共通のルール原本	構成のみ説明
`~/.agents/rules/*.md`	core、memory、QA、account、Google Drive、運用ルール	内容を抽象化して紹介
`~/.agents/bin/*`	共有メモリ、レビュー、同期、Drive 操作用 helper	コマンド名のみ紹介
`~/.agents/generated/*`	Claude / Gemini 向け生成ファイル	生成方針のみ紹介
`~/.codex/skills/*`	Codex 向け skill	種類のみ紹介
`~/.claude/CLAUDE.md`	Claude 固有の強いグローバル規約	公開可能な設計だけ紹介
`~/.claude/settings.json`	Claude のモデル、hook、plugin 設定	秘密値を含まない範囲で紹介
`~/.claude/hooks/*`	session start / compact / stop / end の自動注入	挙動のみ紹介
`~/workspace/.agents`	workspace 側の共有設定	今回は該当ファイルなし

認証情報、アカウント名、顧客名、内部プロジェクト固有名、クラウドアカウント ID などは記事化しない。公開記事では「何を設定しているか」ではなく、「どの種類の足場がモデルの判断に影響するか」に絞る。

現行構成

現行構成は、ざっくりいうと次のようになっている。

~/.agents/
  rules/
    core.md
    memory.md
    qa.md
    account.md
    google-drive.md
    operations.md
  bin/
    agents-sync
    surreal-query.sh
    surrealdb-start.sh
    gemini-review.sh
    gdrive-file
  generated/
    CLAUDE-AGENTS.md
    GEMINI.md
    codex-skills/*

~/.claude/
  AGENTS.md        # ~/.agents から生成
  CLAUDE.md        # Claude 固有の強い規約
  settings.json    # hooks / plugins / model
  hooks/*.sh       # 記憶注入・再注入・セッション記録

~/.codex/
  skills/
    surrealdb-recall
    gemini-review
    google-drive-file-access
    agent-foundation-management

設計思想は明確だ。 各AIツールに別々のルールを書くのではなく、~/.agents/rules を原本にして、Claude、Codex、Gemini 向けに生成する という構成だ。

これはかなり合理的な構成だった。複数のAIを切り替えても、最低限の行動規範、記憶検索、レビュー方針、アカウント確認、Google Drive 操作方針を共有できる。

現在入っている主なルール

設定を機能別に見ると、次のようなものが入っていた。

分類	内容
基本行動	既存文脈を読む、検証可能な成果に変換する、最小検証を行う、不要な巻き戻しをしない
記憶	SurrealDB を共有メモリにし、非自明な作業前に過去知見を検索する
レビュー	Gemini CLI wrapper を標準の第三者レビューとして使う
アカウント安全	commit / push / issue / deploy / cloud 操作前に active account を確認する
Google Drive	Drive ファイルの読取・更新手順を helper に寄せる
運用	AI設定ファイル、skill、memory、schedule、tool の追加更新手順を決める
Claude 固有	セッション開始時の記憶注入、compact 前の再注入、一定回数ごとの重要ルール再注入
Codex 固有	memory、Gemini review、Google Drive、agent foundation を skill 化

Claude 側にはさらに強い規約がある。たとえば、作業前の SurrealDB recall、Gemini 合議、命令を検証可能ゴールへ変換するルール、上位モデルを PM、下位モデルを Worker として使うルールなどだ。

この構成は、 「AIをチームメンバーのように扱う」 ために作られている。忘れない、勝手に危険操作しない、同じ失敗を繰り返さない、過去の判断を参照する。実務上の痛みから生まれた設定だ。

なぜこの構成は有用だったか

軽量モデルや低コストモデルでは、この種の設定はかなり有用だ。

理由は単純で、軽量モデルは次のような弱さを持ちやすい。

作業前に過去文脈を探さない
すぐ一般論に逃げる
以前の判断と矛盾した提案をする
失敗ログから学ばず、同じ修正を繰り返す
重要な検証を省略する
issue や PR に曖昧な文章を書きがち
ツールやアカウントの切り替えを忘れる

この弱さに対して、設定ファイルは外骨格として働く。

たとえば、SurrealDB recall は「過去の判断を探せ」という習慣をモデルの外側に置く。Gemini review は「自分の判断を一度疑え」というプロセスを外側に置く。hook は「長いセッションで重要ルールを忘れる」という問題に対して、定期的にルールを再注入する。

つまり、低〜中性能モデルにとって設定ファイルは、 能力不足を補う実務的な scaffold だった。

公開情報で見る同じ問題意識

この方向は、公開されている実践知とも一致する。

たとえば Claude Code 公式 docs は、同じミスを繰り返す、コードレビューで捕まった、毎回同じ説明をしている、といった場合に CLAUDE.md へ書くことを勧めている。Cursor rules の解説記事でも、always、auto attached、agent requested、manual のように、ルールを適用タイミングで分ける運用が紹介されている。X でも 2026年に入ってから、AGENTS.md 評価論文への反応や、長すぎる CLAUDE.md を削る話、user-level CLAUDE.md で調査やコードベース探索を別 agent に逃がす話が継続的に流れている。

近い問題意識の公開投稿・記事:

これらは査読済み研究ではないので、この記事では「証拠」ではなく「現場の観測例」として扱う。強い根拠としては公式 docs と論文を使い、X や Reddit は、実践者の悩みがどこに集まっているかを見る材料に留める。

高性能モデルで何が逆効果になるか

ところが、高性能モデルでは同じ設定が違う振る舞いをする。

モデル自身が十分に読める、考えられる、探索できる、過去文脈との距離を判断できる場合、外側のルールが「助言」ではなく「先入観」になる。

AGENTS.md 評価研究の結果は、この直感とかなり相性がよい。失敗の形は 「エージェントがルールを無視する」ではなく、「ルールを読んだ結果、探索・テスト・tool use が広がり、タスク解決までの経路が重くなる」 だった。高性能モデルほど、雑なルールを無視してくれるとは限らない。むしろ強い instruction follower として、余計な制約まで律儀に満たそうとする。

ここだけ読む: 高性能モデルでは、ルールが「守られない」よりも、 余計なルールまで守られすぎる ことが問題になる。

今回の棚卸しで、特に逆効果になり得ると感じたのは次の点だ。

1. recall が「過去の正解」へのアンカーになる

過去知見を検索すること自体はよい。しかし、毎回 recall すると、モデルは現在のコードや仕様よりも、過去の記録を優先しやすくなる。

過去の知見は、当時の制約、当時のモデル性能、当時の実装状態に依存している。高性能モデルなら、現在のソースを読んでより良い設計に到達できる場面でも、古い knowledge が強い初期値になってしまう。

記憶は便利だが、記憶は現在の証拠ではない。 ここが recall 設計の分岐点になる。

この点は、長文 context の研究ともつながる。長い context window があっても、モデルがすべての情報を同じ重みで安定して使うとは限らない。古い memory が先頭や繰り返し注入位置に置かれると、現在のファイルより強い信号として扱われる可能性がある。

この絵でいう鎖付きの古いカードが、過去の knowledge や失敗ログだ。役に立つが、現在のコードより強く見えてしまうと判断を引っ張る。

2. superpower 的な手順が、モデルの探索を狭める

skill や superpower は、ある失敗を防ぐために作られる。たとえば「APIとフロントの整合性を見るときはこの順序で読む」「Issueを作る前にレビューする」といった手順だ。

これは初心者や軽量モデルには強い。しかし高性能モデルでは、タスクの形に応じてもっと短い経路や、逆にもっと広い調査が必要なことがある。

固定手順が強すぎると、モデルは 「このタスクは本当にその手順でよいのか」 を考える前に、手順をなぞる。

公式 docs 的にも、複数ステップの手順は常時ロードされる memory ではなく、必要時にロードされる skill に逃がす方が自然だ。つまり「手順を持つな」ではなく、「手順を常時 prompt に混ぜるな」という話になる。

固定レールに乗せるのではなく、分岐点で確認する観点リストとして使う。高性能モデルには、この距離感の方が合う。

3. 第三者レビュー強制が、判断の鮮度を落とす

Gemini review は実用的だった。特に issue 文面、設計レビュー、同じエラーの繰り返しでは効果がある。

ただし、高性能モデルがすでに十分な根拠を集めている場合、毎回の第三者レビューは摩擦になる。しかもレビュー側モデルが対象モデルより低性能な場合、レビューは品質向上ではなく、ノイズ追加になることがある。

「別モデルに聞く」は常に良いわけではない。 レビュー相手の能力、コンテキスト量、対象領域の理解度が低ければ、むしろ判断を曇らせる。

4. モデル階層ルールが古くなる

過去の設定では「上位モデル = PM、下位モデル = Worker」という役割分担が定義されていた。

これは当時は合理的だった。高いモデルに判断を任せ、安いモデルに探索や実装を任せる。

しかし、さらに高性能なモデルが登場すると、この前提が崩れる。高性能モデルが直接探索・実装・レビューまで一貫して行った方が、分業より品質が高い場合がある。逆に、下位モデルへ委譲することで、重要なニュアンスが落ちることもある。

モデル運用ルールは、モデル性能の進化とともに陳腐化する。 ここも定期棚卸しの対象になる。

5. hooks による再注入が、コンテキストを汚す

Claude 側には session start、pre-compact、stop、session end の hook がある。セッション開始時に最近の知見を出し、compact 前に重要情報を再注入し、一定回数ごとに重要ルールを思い出させる。

これは「長い会話でルールを忘れる」問題への対策だった。

ただし高性能モデルでは、毎回同じ行動規範が入ることで、 コンテキスト内の信号対雑音比が下がる。 モデルは本来読むべき現在のファイル、ユーザーの最新意図、実行結果よりも、繰り返し注入される古いルールに注意を割く可能性がある。

hook は、フォーマット、テスト、危険操作のブロック、通知のような決定的制御には向いている。一方で、判断を伴う「思い出し」や「助言」を hook で毎回注入する場合は、モデルの作業 context を汚していないかを観察した方がよい。

レビューも hook も悪ではない。ただし、今見るべき証拠の周囲に通知が増えすぎると、モデルは「何が一番重要か」を見失いやすくなる。

問題は「知識」ではなく「注入タイミング」

今回の気づきは、外部知識や設定ファイルが不要という話ではない。

むしろ逆で、AIエージェントには外部知識が必要だ。特に次の情報はモデル内に閉じ込めない方がよい。

過去の設計判断
失敗と再発防止
プロジェクト固有の制約
アカウントや環境の切り替え手順
公開前の機密チェック
レビュー履歴
運用上の約束

問題は、 それをいつ、どれだけ、どの強さでモデルに渡すか だ。

低性能モデルには、最初から多めに渡した方が安定する。高性能モデルには、最初は少なく渡し、必要になったら自分で取りに行かせる方がよい。

つまり、 設定設計はモデル性能に応じて変えるべき だ。

このミームが言っている「ちょうどいいくらい」が、この記事の結論に近い。AIエージェント設定は、少なすぎれば毎回同じ失敗をする。多すぎれば、現在の証拠よりも過去のルールが強くなる。高性能モデル向けには、全部盛りではなく、必要時に取り出せるくらいの量がちょうどよい。

改善方針

高性能モデル向けには、次のような設計がよさそうだ。

1. 常時注入から段階的ロードへ

すべてのルールを最初から読ませるのではなく、最初に渡すのは薄い原則だけにする。

棚に全部あることはよい。問題は、作業開始時に棚ごと机へ載せることだ。高性能モデルには、まず薄く始めて必要な箱だけ取り出させる。

Level 0: 最小原則
- 既存変更を壊さない
- 秘密を出さない
- 必要ならローカル文脈を読む
- 検証結果を報告する

Level 1: タスク別ルール
- GitHub issue を作るときだけ issue ルール
- Google Drive を触るときだけ Drive ルール
- AI設定を編集するときだけ foundation ルール

Level 2: 過去知見
- 既存判断が必要なときだけ SurrealDB recall
- 検索結果は「参考」と明示

高性能モデルには、最初から Level 2 まで積まない方がよい。 まずは Level 0 / Level 1 で足りるかを見る。

2. recall は「義務」ではなく「道具」にする

現行設定では、非自明な作業前に recall する設計になっている。これは安全だが重い。

高性能モデル向けには、次のように変えたい。

旧	新
非自明な作業では必ず recall	過去判断が成果に影響する場合に recall
memory を強い前提として扱う	memory は仮説として扱い、現行ファイルで検証する
tags / fulltext を毎回引く	必要な時だけ狭く引く
取得結果を文脈に混ぜる	判断に使った memory だけ要約して採用する

これだけで、古い知見へのアンカーをかなり減らせる。

3. レビューはモデル性能差を見て呼ぶ

第三者レビューは有効だが、常に呼べばよいものではない。

目安としては、次の条件を満たすときに呼ぶ。

公開される issue / PR / 記事など、後戻りコストが高い
セキュリティ、課金、データ破壊、公開挙動に関わる
同じエラーを繰り返している
自分より強い、または違う得意領域を持つモデルに聞ける
レビュー対象を十分に短く、自己完結にできる

逆に、現在のモデルが十分に強く、ローカル証拠も揃っている場合は、 レビューより実機検証を優先する 。

4. superpower は「ルート」ではなく「チェックリスト」にする

skill や superpower は、実行順序を固定するより、最後に漏れを確認するチェックリストとして使う方が高性能モデルに合う。

たとえば API 整合性チェックなら、最初から「この順序で読む」と縛るのではなく、モデルが自分で調査した後に、次のように使う。

このタスクで見落としやすい観点:
- API docs と実装の差分
- generated type を手で編集していないか
- enum / error code / status code の不一致
- テストで固定すべき契約

高性能モデルには、手順より観点を渡す方が効く。 手順化しすぎると、探索の幅が落ちる。

5. 設定に「軽量モード」と「厳格モード」を持たせる

モデルやタスクに応じて設定の強さを切り替える。

モード	対象	ルール
lightweight	高性能モデル、探索系、記事構想	最小原則 + 必要時ロード
standard	通常の実装、調査	現行に近いが recall は狭く
strict	deploy、issue、PR、クラウド、機密、破壊的操作	account確認、review、機密チェックを強制

すべてのタスクに strict を適用すると、賢いモデルの良さが消える。 strict は不可逆操作や公開物に寄せる。

6. Fable を常時使わず、Sonnet / Opus に委任する

今回の棚卸しで、もう一つ重要だったのは「設定の強さ」だけでなく「モデル使用量」も設計対象にすることだった。

高性能モデル Fable は、探索、設計判断、長期タスク、曖昧な要求の整理で強い。一方で、 常時 Fable を使うと、使用量が先に枯渇する。 さらに Fable が API 従量課金や usage credits 前提のモデルになっていくなら、全部を Fable で処理する構成は、品質以前に運用コストの面で持続しにくい。

そのため、モデル委任は「下位モデルに雑用を投げる」という古い固定階層ではなく、タスクのリスクと不確実性に応じて切り替える。

モデル	任せる仕事
Fable	重要な設計判断、曖昧な要求の分解、長期タスクの方針、最終判断
Opus	難しめの実装、深いレビュー、複数ファイルにまたがる調査、失敗原因の切り分け
Sonnet	通常実装、探索、要約、定型的な修正、下調べ、記事素材の整理

Fable は中央の決定装置として残し、探索や実装は別モデルへ流す。これは単なる節約ではなく、重要判断に高性能モデルの集中力を残すための設計だ。

この方針は、 Fable がサブスク内常時無料で使える前提ではなくなり、API 従量課金や usage credits を見据えるための実装 でもある。

つまり、高性能モデル向けの agent foundation は、次の二つを同時にやる必要がある。

context を常時盛りすぎない
Fable を常時使いすぎない

高性能モデルの価値は 「すべての token を最高級モデルで処理すること」ではなく、「判断が必要な局面で、必要な文脈だけを渡して使うこと」 にある。

7. ルールに根拠、期限、適用条件を持たせる

高性能モデル向けの設定では、ルール本文そのものよりも、ルールの「鮮度」と「適用条件」が重要になる。

たとえば、各ルールに次の metadata を持たせる。

Rule: API error format
Why: 2026-05-18 の本番障害で silent 200 が混入したため
Applies when: API response / error handling / OpenAPI を変更するとき
Source of truth: docs/api/error-format.md
Last validated: 2026-07-05
Expires or review: API v2 移行時に見直す
Strength: strict

これにより、モデルは 「これは常に守るべき原則なのか」「過去障害への一時対策なのか」「現行ファイルで再検証すべき仮説なのか」 を区別しやすくなる。

逆に、次のような情報は常時ルールから外す候補になる。

README、package.json、composer.json、Makefile、CI 設定から読める情報
lint / formatter / type checker が機械的に検出できる規約
すでに修正済みの一時的な workaround
あるモデル世代の弱点だけを補うために書いた手順
「丁寧に調べる」「慎重に作業する」のような、行動を重くするだけの抽象表現

残すべきなのは、コードから推測しにくく、誤ると高くつく情報だ。 それ以外は常時注入から外す候補になる。

非標準の build / test / deploy 手順
破壊的操作、課金、権限、公開範囲に関わる制約
過去に実際に事故った再発防止
プロジェクト固有の契約、API 互換性、公開仕様
ユーザーや組織の明示的な意思決定

設定棚卸しから得た判断

今回の構成で価値が高いまま残したいものは次の通り。

~/.agents を原本にして provider 別ファイルを生成する設計
SurrealDB に知見、成果物、レビューを分けて保存する設計
認証情報を設定原本に置かない方針
アカウント確認や機密チェックのような不可逆操作前の安全ルール
Google Drive など外部データ操作を helper に寄せる方針

一方で、高性能モデル向けに弱めたいものは次の通り。

毎タスクの自動 recall
過去知見を強い前提にする表現
Gemini review の過剰な強制
hook による周期的なルール再注入
「上位モデルはPM、下位モデルはWorker」という固定役割
superpower を実行ルートとして扱うこと

ここで重要なのは、 設定を捨てることではない。 設定を 「賢さの代替」から「賢さを邪魔しない補助」に変えること だ。

まとめ

AIエージェント設定は、軽量モデルでは能力不足を補う scaffold として有効だった
高性能モデルでは、同じ設定が過去知見へのアンカー、探索範囲の縮小、レビュー摩擦、コンテキスト汚染になることがある
問題は外部知識そのものではなく、常時注入と強制手順化にある
高性能モデル向けには、最小原則、必要時 recall、観点チェックリスト、軽量/厳格モードの切り替えがよい
Fable は判断が必要な場面に残し、Sonnet / Opus に探索・実装・レビューを委任することで、使用量枯渇と従量課金リスクを抑えられる
AI設定は一度作って終わりではなく、モデル性能の進化に合わせて棚卸しする必要がある

参考にしたローカル構成

公開できる範囲で、今回の棚卸し対象は以下。

~/.agents/rules/core.md
~/.agents/rules/memory.md
~/.agents/rules/qa.md
~/.agents/rules/account.md
~/.agents/rules/google-drive.md
~/.agents/rules/operations.md
~/.agents/bin/agents-sync
~/.claude/CLAUDE.md
~/.claude/settings.json
~/.claude/hooks/*.sh
~/.codex/config.toml
~/.codex/skills/*/SKILL.md

参考にした公開情報

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up