AIの利用量を減らしたい。でも、指示を短くして品質や安全性が落ちるのは困る。
私も、自動化を増やすたびに長い指示を足していた。ログイン画面では止まる、会社アカウントを使わない、同じ記事を二度作らない、公開前に確認する。必要なルールだから、消すのが怖かった。
そこで、まず「何となく長い」ではなく、現在動いている自動化をbytesで測った。実際の課金トークン数は取得できないため、UTF-8の入力bytesを代理指標にした。
監査時点で動いていた自動化は5本。合計の指示文は11,739bytesだった。そのうち、夜間整理が4,217bytes、営業が2,610bytesで、2本だけが長文警告になっていた。
内容を確認すると、安全ルールではなく、別のrunbookに書いてある実行手順を指示文にも繰り返していた。そこで安定手順をrunbookへ一本化し、停止条件だけを指示文へ残した。
結果は、夜間整理が4,217→1,193bytes、営業が2,610→1,402bytes。2本合計で4,232bytes減った。この記事では、何を削り、何を絶対に残したのかを説明する。
先に「実課金トークンではない」と決めた
今回測れたのは、指示文のUTF-8 bytesだ。実際にモデルへ請求された入力トークン、キャッシュされたトークン、推論トークンの内訳ではない。
日本語は文字数とbytesが一致せず、bytesとトークン数も一致しない。そのため「4,232bytes減ったから、料金が何円下がった」とは言えない。
それでも代理指標としては使える。同じ測り方で変更前後を比較すれば、毎回必ず渡している文章がどれだけ短くなったかは分かる。
私が確認したのは次の三つだ。
- 起動時に毎回読む共通文書の合計bytes
- active automationごとの指示文bytes
- 詳細資料を必要な時だけ読む構成になっているか
共通文書は17,628bytesで、設定していた警告値25,000bytesより下だった。問題は共通文書全体ではなく、2本のautomationだけに偏っていた。
合計だけを見て全部を短くするのではなく、長い場所から理由を確認した。
削ったのは「同じ手順の二重記載」
夜間整理の自動化には、ChatGPT履歴取得、会社ログの境界、体験カード作成、ブログ・YouTube・Kindle別の候補選定、Obsidian更新、翌日のランキング反映まで書いていた。
しかし、その実行順とコマンドは専用runbookにも書いてある。指示文とrunbookの両方を更新しないと、片方だけ古くなる。
営業も同じだった。対象選定、重複除外、画像作成、送信前確認、送信結果不明時の停止まで、runbookと指示文の両方へ詳しく書いていた。
そこで役割を分けた。
| 置き場所 | 残す内容 |
|---|---|
| automation指示文 | 正本の場所、絶対に破ってはいけない境界、終了報告 |
| runbook | 実行順、コマンド、成果物、再開方法、細かな検証項目 |
| スクリプト | 件数、重複、版、ハッシュ、状態の決定論的な判定 |
| Obsidian | 当日の結果、未完了、次の再開地点 |
これで、毎回の指示文へコマンド一覧を貼り直す必要がなくなった。
重要なのは、「詳しいことは適当に判断して」という短縮にしないことだ。どのrunbookが正本か、どこまで実行するか、失敗した時にcommitしてよいかを短い指示文へ残した。
削らなかった安全ルール
トークンやbytesを減らすために、次の内容は消さなかった。
- ChatGPT取得は専用Chromeの背景タブだけを使う
- Brave、既存タブ、前面タブへ勝手に切り替えない
- ログイン、二段階認証、CAPTCHA、Cloudflareを突破しない
- 会社の生ログを個人環境へ移さない
- 会社由来の気づきは個人環境で再検証するまで公開しない
- ログの安全化や品質検査が失敗したらcheckpointを確定しない
- 営業メールは個人用の期待アカウントと送信専用権限を確認する
- 送信結果が不明なら再送しない
- 課金、広告、キャンペーン、削除を勝手に実行しない
これらは、runbookにも指示文にも意図的に残した。重複ではあるが、入口で読み落とすと外部影響が出るためだ。
省利用量の目標は、安全確認を減らすことではない。毎回変わらない長い手順説明を参照先へ移し、事故防止の停止線は入口に残すことだ。
5本すべてを同じ推論レベルにしなかった
現在の5本は、同じモデルを使いながら、仕事の重さで推論レベルを分けている。
- ブログ：medium
- YouTube：medium
- 営業：medium
- 夜間のログ整理と横断Goal：high
- Kindle：high
ブログやYouTubeも文章品質の判断は必要だが、候補選定、重複検査、媒体固有のrunbookがある。通常制作はmediumから始める。
夜間整理は、個人・会社ログの境界、複数媒体の候補競合、実績反映、未完了Goalの再開を一度に判断する。Kindleは長文、構成、重複、読者価値、提出前の多段階確認がある。そのためhighを残した。
単純な件数確認、ハッシュ照合、公開済み判定はAIへ考えさせず、Pythonで同じ結果を返すようにしている。
OpenAIのReasoning models公式ガイドでも、低いeffortは速度と少ないトークン利用を優先し、mediumは品質・信頼性と性能のバランス、highは複雑なデバッグや長期計画向けと説明されている。すべてをhighにするのではなく、工程の複雑さに合わせて選ぶ考え方と一致する。
指示文を短くする前に、処理をAIから外した
もっと効いたのは、文章を数行削ることより、AIを呼ばなくてよい処理を分けたことだ。
たとえば次はスクリプトで確認できる。
- 今日のブログ、YouTube、Kindleが出たか
- 記事の本文ハッシュが完成時と同じか
- WordPress側の元記事版が変わっていないか
- 同じ候補が別媒体ですでに使われたか
- ログが途中で切れていないか
- 会社ログのstatus receiptが未受領か期限内か
判定結果が正常なら、AIは記事や台本の制作だけを行う。異常がある時だけ、原因整理へ推論を使う。
この構成にすると、「何も起きていないか確認するために、毎回長いAI処理を走らせる」無駄を減らせる。
固定部分を前へ置く
APIを使う場合は、同じ長い指示を繰り返すなら順番も重要になる。
OpenAIのPrompt Caching公式ガイドでは、キャッシュは完全に一致するprefixで利用でき、固定の指示や例を前、変動する利用者固有の内容を後ろへ置くよう案内している。キャッシュの書き込み・読み込みトークンも計測できる。
今回のCodex automation監査では実際のcached tokensまで取得していないため、キャッシュ効果は成果として数えていない。ただし、runbookと固定境界を安定させ、日付や候補など変動情報を成果物側へ分離する構成は、将来API計測へ移す時にも扱いやすい。
自分の自動化で確認する順番
月初や大きな変更後は、次の順番で確認する。
- active automationの本数を数える
- 同じ目的のautomationが二つないか見る
- 指示文bytesを並べ、突出したものを探す
- 長い理由が安全境界か、手順の重複かを分ける
- 安定手順をrunbookへ移す
- アカウント、認証、会社情報、外部変更の停止線は残す
- 推論不要の判定をスクリプトへ移す
- 変更後にautomation一覧と回帰テストを確認する
今回、automationは5本のまま増やしていない。変更したのは既存2本の指示文だけだ。
変更後は、5本すべてでモデルと推論レベルの想定不一致がないこと、共通文書が容量基準内であることを確認した。
まとめ
AI自動化の利用量を減らす時、最初にモデルを弱くする必要はなかった。
- 実課金トークンが取れないため、入力bytesを代理指標にした
- active automation 5本のうち、長い2本だけを調べた
- 夜間整理を4,217→1,193bytesへ短縮した
- 営業を2,610→1,402bytesへ短縮した
- 2本合計で4,232bytes減らした
- 安定手順はrunbookへ、停止条件は入口へ残した
- 通常制作はmedium、複雑な横断処理と長文出版はhighを維持した
- 推論不要の件数・版・重複判定はスクリプトへ分離した
短い指示文が良いのではない。必要な安全性と品質を、最小の重複で毎回再現できる状態が良い。
今回の元テーマはKindle本『副業会社員のクラウドコスト削減術』にもつながる。この記事はAI自動化の入力指示に絞った。Vercel、Cloudflare、AWSなど実際のクラウド請求を見直す場合は、サービスごとの課金単位と公式ダッシュボードを別に確認してほしい。
※bytes削減量は入力指示文の比較であり、実際の請求トークン数や金額の削減を示すものではありません。
自動化のムダを別の角度から減らす
- 5時間おきの専用自動化を削除した記録では、処理回数ではなく役割の重複を減らしています。
- Macで後回しにしてよかった設定を決めた記録では、環境構築の範囲を絞った判断を確認できます。