※この記事は2026年9月時点の、自分のCodex・Obsidian運用について書いたものです。
※指示を減らす前後で、速度や利用枠を同条件比較した性能検証ではありません。
※本文中の文字数とテスト件数は、2026年9月16日に保存した自分の実装・検証記録を基にしています。
少し前に、AIが進化した後も、古いモデル向けに増やした細かい指示を残し続けてよいのか、と書きました。
スキルを増やしすぎると、関係のない場面で呼ばれるかもしれない。
長い説明を毎回読ませると、本当に必要な指示が埋もれるかもしれない。
新しいモデルが自分で判断できる範囲まで、過去の手順で縛っているかもしれない。
前回の記事では、そこを今後の課題として残していました。
その後、実際に自分の環境の AGENTS.md とSkill、日課automationの指示を整理しました。
結果から言うと、確かに入口はかなり短くなりました。
ただし、やったことは単純なルール削除ではありません。
毎回読む必要がある情報と、必要な時だけ読めばよい詳細を分けた。
今回いちばん大きかったのは、そこでした。
AGENTS.mdとSkillの入口を実際に短くした
今回の整理では、まずワークスペース全体で読む AGENTS.md を見直しました。
変更前は5,995文字。
変更後は3,415文字。
約43％短くなりました。
次に、個人で使っている16個のSkillについて、AIが一覧から用途を判断するためのdescriptionを見直しました。
合計6,053文字あった説明を、2,858文字まで短縮しました。こちらは約53％減です。
さらに、毎日の文字起こし収集と整理に使っている二つのautomationも、指示を短くしました。
- 2,903文字から739文字
- 1,964文字から625文字
数字だけを見ると、かなり削ったように見えます。
ただ、目的は短い指示を作ることではありませんでした。
どのSkillを使うのか。
どの作業を担当するのか。
何をしてはいけないのか。
AIが最初に判断するための入口から、そこで毎回読む必要のない細部を外すことが目的でした。
詳細は消さず、必要な時だけ読む場所へ移した
今回、特に慎重に扱ったのは、安全や公開範囲に関するルールです。
たとえば、公開、削除、課金、認証情報、投資判断、privateな素材の扱いは、AIが賢くなったから消してよい話ではありません。
ブログでも、ネタ探し、下書き、公開前の仕上げ、WordPressへの投稿では、必要な確認が違います。
そこで、入口には役割と境界を残し、細かな手順は条件付きのreferenceへ分けました。
記事候補を探す時だけ読む資料。
UP版を作る時だけ読む資料。
タグを決める時だけ読む資料。
こうしておけば、関係のない作業で全部を読む必要はありません。
面白かったのは、入口は短くなった一方で、referenceまで含めた手順の総量は、変更前より463文字増えていたことです。
つまり今回は、単純なダイエットではありません。
情報を消したのではなく、常時読み込む情報と、必要になった時に読む情報へ置き直した。
「AIへの指示を減らす」と聞くと、細かいルールを捨ててAIへ丸投げする話に見えます。
実際にやってみると、自分の環境ではむしろ逆でした。
守る境界は残す。
詳しい手順も捨てない。
ただし、全部を毎回同じ重さで読ませない。
この分け方の方が重要でした。
まずは壊していないことを確認した
指示を短くした直後に確認したかったのは、便利になったかより、既存の動作を壊していないかでした。
今回の変更後には、次の確認を行いました。
- 日課処理のfocused unittest：22件通過
- ブログ素材探索の回帰テスト：2件通過
- インストール済みSkillの公式構造検証：16個すべて通過
- 反映対象ファイルのハッシュ一致を確認
- automationのスケジュール、モデル、宛先が変わっていないことを再確認
これで、指示を短くしたから即座に成功した、とまでは言えません。
ただ、少なくとも構造を壊し、安全境界や既存設定を落としたまま進めたわけではないことは確認できました。
修正後の日課は3日連続で最後まで動いた
構造テストだけでは、実際の運用で動くかは分かりません。
そこで、修正後の日課がどう動いたかも確認しました。
9月16日は、13件を要求し、12件を取得・要約しました。最終監査と、別の作業先へ渡したことを示すreceiptまで完了しています。
9月17日は、最初の収集が全件失敗しました。
ここで同じ処理を無条件に何度も起動するのではなく、失敗結果を残したうえで、決めていたrecovery経路へ進みました。再実行後は13件を取得・要約し、最終監査とreceiptまで完了しました。
9月18日は、16件を要求し、15件を取得・要約して完了しています。
3日間とも、収集しただけでは終わっていません。
収集。
要約。
最終監査。
引き渡しの完了確認。
ここまで一巡しました。
特に9月17日の結果は、自分にとって重要でした。
毎回読む指示を減らしても、失敗した時に同じ処理を重複起動しないことや、失敗をなかったことにせず回復経路へ進むルールは残っていたからです。
短くした後に通常時だけ動いたのではなく、失敗時の分岐も一度は機能しました。
まだ「短くした方が速い」とは言えない
一方で、今回の結果から言えないこともあります。
変更前と変更後で、同じ入力、同じモデル、同じ作業量を使った比較はしていません。
そのため、次のような結論はまだ出せません。
- トークン消費がどれだけ減ったか
- 利用枠が長持ちするようになったか
- 作業時間が短くなったか
- Skillの自動選択が正確になったか
- 出力品質が上がったか
修正後に3日間動いたことは、主要な運用が直ちに壊れなかった証拠にはなります。
しかし、それだけで改善効果まで証明したことにはなりません。
今後は、同じ種類の作業で、呼ばれたSkill、修正回数、所要時間、利用量を比較する必要があります。
今回の記事は、最適化の成功報告というより、指示を減らす時に何を削り、何を残したか、その後も運用が続いたかの記録です。
AIが賢くなっても、境界まで曖昧にしない
モデルが進化すると、細かい手順を書かなくても、以前より意図を読んで動ける場面は増えていくと思います。
だからといって、すべてのルールが古くなるわけではありません。
どう実装するかはAIへ任せやすくなる。
何を公開してよいかは残す。
どう要約するかは任せやすくなる。
何をprivateとして扱うかは残す。
失敗からどう直すかは任せやすくなる。
無断で削除や課金をしない境界は残す。
細かい手順と、守るべき境界は同じものではありません。
今回の整理で、自分の中でもそこが少し見えやすくなりました。
AIへ任せる範囲を増やすなら、ルールをすべて消すのではなく、AIが判断してよい部分と、人間が固定しておく境界を分ける。
そのうえで、必要な詳しい手順は、必要な時にだけ読める場所へ置く。
自分の環境では、この形が今のところ一番しっくりきています。
まとめ
AIが賢くなった後も、過去に作った指示を足し続けるだけでは、関係のない手順まで毎回読ませることになります。
そこで今回、AGENTS.md、Skillの入口、日課automationの指示を実際に整理しました。
入口は短くなりました。
ただし、安全ルールや詳しい手順をまとめて捨てたわけではありません。
毎回読む必要がある役割と境界を入口に残し、詳しい手順は必要時だけ読むreferenceへ移しました。
修正後の日課は3日連続で最後まで動き、一度は収集失敗からの回復経路も機能しました。
まだ、速度や利用枠が改善したとは言えません。
それでも、今回の結果から一つだけ言えることがあります。
AIへの指示を減らすとは、ルールを雑に捨てることではなく、AIがいつ何を読むかを整理することなのかもしれません。
コメント