Codexに同じ手順を毎回説明していないか
Codexを使っていると、同じような作業を何度も頼む場面があります。
ビルドする。テストする。SQLiteの状態を見る。差分を確認する。生成物を同期する。公開前チェックを流す。こうした作業を毎回チャットで説明していると、時間もかかり、会話のトークンも使います。
そこで有効なのが、よく使う処理を .sh にしておくことです。
これは「シェル化すれば何でも速くなる」という話ではありません。人間が毎回説明していた定型作業を、実行可能な手順としてプロジェクト側に残すという話です。
AIに毎回同じ説明をするのではなく、作業の入口をファイルにしておく。そうすると、Codexは手順の解釈ではなく、実行と結果確認に集中しやすくなります。
毎回説明している作業はスクリプト化の候補
Codexに同じ説明を何度もしているなら、その作業はスクリプト化を考えてよいです。
たとえば、公開前に必ず流す検証があります。サイトマップを確認する。差分チェックをする。記事インデックスを同期する。最新記事数を確認する。リンク切れを見つける。こうした手順を毎回自然文で説明すると、説明漏れや解釈のズレが起きます。
一方で、scripts/preflight.sh のようなファイルにまとめておけば、Codexには「preflightを流して」と言うだけで済みます。
手順はチャットの中ではなく、リポジトリの中に残ります。次の作業でも、別のセッションでも、同じ確認を再現できます。
トークン消費も減らせる
Codexとの会話では、指示文、過去の文脈、コマンド出力、説明がすべてトークンとして扱われます。
毎回長い手順を書くと、それだけでトークンを使います。さらに、Codexが手順を読み取り、コマンドを組み立て、確認結果を説明するためにも文脈を使います。
スクリプト化しておけば、指示は短くなります。
scripts/preflight.shこの一行で済むなら、毎回「この順番で確認して、最後にこの数字を見て」と説明する必要がありません。
ただし、出力が長すぎるスクリプトは逆効果です。Codexに使わせるなら、結果は短く、判断しやすく出すべきです。成功、失敗、注意点、詳細ログの場所だけを出すようにすると、人間にもAIにも読みやすくなります。
速くなる理由は、AIが迷わなくなるから
.sh 化で作業が速くなるのは、AIそのものが賢くなるからではありません。
迷う余地が減るからです。
自然文で頼むと、Codexは毎回、どのコマンドを使うか、どの順番で実行するか、どのパスを見るか、どこまで確認するかを判断します。これが悪いわけではありませんが、定型作業まで毎回判断させるのは効率がよくありません。
スクリプトにしておけば、パス、順番、確認項目、終了条件を固定できます。Codexはその手順を実行し、結果を見ればよくなります。
AIに考えさせるべきところと、考えさせなくてよいところを分ける。.sh 化は、そのための実務的な方法です。
運用知識をプロジェクト側に残せる
よく使う手順には、その人や会社の運用知識が入っています。
どのDBを先に見るのか。どの同期を最後に流すのか。どのファイルは触らないのか。どの出力なら正常なのか。どのエラーなら止めるべきなのか。
こうした知識を毎回チャットで説明していると、どこかで漏れます。セッションが変われば、前提も抜けます。
.sh にしておけば、運用知識を実行可能な形で残せます。READMEに書くだけでなく、実際に動く手順として置けるのが強いところです。
これは単なる時短ではありません。作業の属人性を減らし、再現性を上げる方法です。
危険な処理は分ける
便利だからといって、すべてを一つのスクリプトにまとめるのは危険です。
削除、上書き、DB一括更新、外部送信、公開、push、本番反映のような処理は、間違ったタイミングで実行すると影響が大きくなります。
確認用、生成用、検証用、公開用は分けた方が安全です。
たとえば、状態を見るだけの check.sh、公開前確認の preflight.sh、生成処理の build.sh、push前の最終確認をする verify.sh のように、役割を分けます。
特に危険な処理は、実行前に確認を入れるか、別スクリプトとして明確に分離しておくべきです。AIに実行させるからこそ、安全な入口を作る必要があります。
出力は短く、判断しやすくする
Codex向けのスクリプトでは、出力も大切です。
大量のログをそのまま出すと、読む量が増えます。人間も疲れますし、Codexのトークンも使います。
良い出力は、短く、状態が分かり、次の判断につながるものです。
OK: sitemap valid
OK: diff check passed
OK: content index synced
WARN: 2 unstaged filesこのくらい整理されていれば、何が通っていて、何を見るべきかがすぐ分かります。
詳細が必要な場合はログファイルに残し、画面には要約だけを出す形が使いやすいです。AIに読ませる出力は、人間にとっても読みやすい方がいいです。
Codex時代の作業入口になる
プロジェクトにCodex向けのスクリプトがあると、作業開始が速くなります。
新しいセッションで何を確認するか。どの順番で検証するか。どのコマンドが正しいか。どの数字を見れば完了と言えるか。こうした情報がスクリプトに入っていれば、Codexは迷いにくくなります。
AI時代の開発では、READMEだけでは足りない場面があります。人間が読む説明に加えて、AIが実行できる手順を置いておくことが重要になります。
Codexに毎回説明するのではなく、Codexがすぐ動ける入口をプロジェクト側に用意する。これが、作業速度と再現性を上げる現実的な方法です。
まとめ
Codexの作業を速くするには、よく使う処理を .sh 化しておくと効果があります。
毎回同じ手順をチャットで説明するより、スクリプトにしておけば、指示が短くなり、実行漏れが減り、トークン消費も抑えやすくなります。
大切なのは、何でも自動化することではありません。人間が毎回説明していた定型作業を、実行可能な手順として残すことです。
確認、ビルド、テスト、同期、公開前チェックはスクリプト化しやすい領域です。一方で、削除、上書き、push、本番反映のような危険な処理は分けて扱う必要があります。
Codexを速く使うコツは、AIに毎回考えさせる作業を減らすことです。よく使う手順を .sh に残し、人間の運用知識をプロジェクト側に置いておく。そうすれば、Codexは作業そのものに集中しやすくなります。