Codexマクロは使える?定型入力の再利用方法と注意点整理

Codexマクロは使える?定型入力の再利用方法と注意点整理

Codexで同じ依頼文を何度も入力する人は、「マクロ」を登録して一つのキーで呼び出せないかと考えます。2026年9月9日時点の公式資料では任意のマクロ機能を追加する説明はなく、定型入力は組み込みコマンド、指示ファイル、入力欄の編集を分けて考えるのが現実的です。直近の更新で入力履歴や取り消しも整ったため、できることとできないことを確かめ、壊れにくい再利用方法を整理します。

結論powered by Claude

Codexに任意の名前を付けたマクロを登録する公式機能は、現時点の公開資料では確認できません。スラッシュコマンドはCodexに組み込まれた操作であり、好きな名前のコマンドを追加する仕組みとは別です。まずOpenAIのスラッシュコマンド公式リファレンスで標準機能の範囲を確認します。

繰り返し使う依頼を安定させるには、入力欄へ貼り付ける短い定型文、プロジェクトの前提を共有するAGENTS.md、会話中の状態を変える標準コマンドを分けます。役割を混ぜなければ、マクロに似た便利さを得ながら、意図しない変更を呼び出す危険を抑えられます。

なぜ今確認するかというと、Codex 0.153.3でVimモードの取り消し・やり直しや入力履歴の改善が案内され、0.153.4ではAstraの表示と案内が修正されたからです。版の変化と入力の再利用を混同しないよう、公式リリース一覧を基準に確認します。

目次 (25)

Codexマクロとは何を指すのか

「Codexマクロ」という検索語には、長い依頼文を短い呼び出しで再利用したい、複数の操作を一つにまとめたい、同じ確認項目を毎回伝えたくない、という三つの願いが含まれます。しかしCodexでは、会話画面のコマンド、プロジェクトの指示、入力欄へ渡す文章、端末側のキー操作が別の層として動きます。最初にこの違いを分けないと、標準コマンドに名前を追加できると思い込んだり、指示ファイルへ書いた内容が過去の会話まで変えると期待したりしやすくなります。マクロという一語を、実際に必要な再利用の形へ言い換えることが出発点です。

Codexはコードを読む、変更案を作る、検証結果を説明するための開発用エージェントです。入力を短くできても、対象範囲や完了条件が曖昧なままだと、便利さより確認の負担が増えます。したがって、マクロのようなものを用意する場合も、短縮するのは定型部分だけにし、対象ファイル、変更してよい範囲、確認方法はその都度明示できる形に残すのが安全です。

任意の名前を持つマクロ登録は公式機能か

2026年9月9日にOpenAIの公式スラッシュコマンド資料を確認すると、用意されたコマンドを入力欄から呼び出す方法は説明されていますが、利用者が任意の名前を付けた新しいスラッシュコマンドを登録する手順は掲載されていません。つまり、/reviewのような組み込み操作を/my-reviewへ改名する機能がある、と断定することはできません。検索結果や古い記事で「カスタムマクロ」と呼ばれていても、標準機能と外部の入力補助を分けて読みます。詳しくはOpenAIのDeveloper commandsを参照してください。

この境界を知っておくと、存在しない設定項目を探し続けずに済みます。Codexの標準コマンドは、モデルの切り替えや状態の確認など、その場の会話を操作するための入口です。長いレビュー観点やプロジェクトの命名規則を埋め込む場所ではありません。そこに定型文を無理に押し込むより、標準コマンドと別の再利用方法を組み合わせた方が、更新後も役割を保ちやすくなります。

Vimモードの操作とマクロを混同しない

Codex 0.153.3の公式リリースには、Vimモードでuによる取り消しとCtrl+Rによるやり直しができ、貼り付けた内容を含む入力を保てる改善が記載されています。これは入力を編集し直すための機能であり、決まった依頼文を別名で呼び出すマクロとは違います。誤った文字を直したいときは編集機能、同じ文章を再利用したいときは定型文の保存、会話の状態を変えたいときは標準コマンド、と目的で分けると判断しやすくなります。出典はCodex 0.153.3の公式リリースです。

この違いは、入力の取り消しを「前回と同じ依頼を安全に再送する機能」と誤解しないためにも重要です。やり直しは入力欄の内容を戻す操作であって、対象ファイルや確認条件を記憶して新しい会話へ移すものではありません。長い依頼を再利用する場合は、文章を別に保存し、送信前に対象と完了条件を見直す流れを作ります。

なぜ今、Codexマクロを確認するのか

直近のCodexは、入力そのものと作業履歴の扱いが短い期間にも変わっています。公式リリース一覧では、0.153.3にVimモードの取り消し・やり直し、入力履歴、会話の再接続などが記載され、その後の0.153.4ではAstraをモデル選択欄で見つけやすくする修正が公開されています。さらに0.154.0-alpha.6のような先行版も並ぶため、記事や画面で見た「マクロ」が、入力編集の話なのか、会話操作の話なのか、外部ツールの話なのかを日付と版番号付きで判断する必要があります。

この変化は、定型入力を作る人にも関係します。入力欄の履歴や取り消しが改善されれば、長い依頼文を直す負担は減りますが、標準コマンドが増えたことを意味するわけではありません。版が上がったから任意のマクロ登録が使える、と決めつけず、公式リファレンスと手元の画面を別々に確認します。今の版を記録してから小さな読み取り依頼で試すと、入力の問題とモデル・クライアント側の差を切り分けられます。

0.153.3の入力改善が示すこと

0.153.3の変更は、入力中に間違えた文字を戻したい人、貼り付けた長い依頼を編集したい人、過去の入力と実行結果を見返したい人に関係します。これらはマクロを新しく登録する機能ではありませんが、定型文を使う前後の確認をしやすくします。たとえば保存しておいた依頼文を貼り付けたあと、対象パスだけを書き換え、送信前に余分な条件を取り除くといった作業が行いやすくなります。変更の範囲は公式リリース本文で確認します。

0.153.4と先行版を分けて見る

0.153.4はAstraの表示と案内に関する修正を含む安定版として掲載されています。一方、0.154.0-alpha.6は公式のリリース一覧で先行版と表示されています。入力補助の使い勝手を確かめたい場合でも、安定版と先行版を同じ条件として扱わないことが大切です。先行版で見つけた入力欄の挙動を普段の開発へそのまま広げず、版番号、OS、入力経路、結果を記録し、必要なら安定版の同じ操作と比べます。出典はOpenAI Codexの公式リリース一覧です。

「使える」と「登録できる」を分ける

外部のキーボード入力補助や端末の編集機能を使えば、長い文字列を短い操作で入力すること自体はできます。しかし、それはCodexがマクロを登録して実行する機能とは別です。入力補助は文字を渡すだけ、Codexは受け取った依頼を解釈するだけ、と責任範囲を分けます。外部の補助から送信まで一気に行う設定は、対象を間違えたときに確認する時間を失いやすいため、まず入力欄へ文字を入れるだけにし、送信は人が確認してから行う方が安全です。

定型入力を再利用する四つの方法

Codexマクロの代わりになる方法は、すべてを一つにまとめることではありません。すぐ使える短文は手元に保存し、プロジェクト全体の前提は指示ファイルへ置き、会話の状態変更は標準コマンドに任せます。入力経路を分けると、どの条件がどこから加わったのかを後から説明できます。次の順で、まず再利用したい内容の種類を決めてから設定します。

定型化の目的は、入力を短くすることそのものではなく、同じ確認品質を繰り返し得ることです。呼び出し前に対象を差し替え、送信前に条件を見直し、結果を読んでから次の操作へ進む流れまで含めて初めて、マクロの代わりになる仕組みとして役立ちます。

Step 1: まず短い定型文を保存する

一度に貼り付ける定型文は、目的、対象、変更範囲、確認方法の四項目を含む短い文章にします。たとえば「このファイルの例外処理を読み、変更案だけを示し、テストは実行せず、懸念点を三つ挙げる」のように、何をするかと何をしないかを明記します。ファイル名やブランチ名のように毎回変わる部分は空欄や置き換え記号にし、貼り付けた後に人が埋める形にすると、古い対象を誤って再利用しにくくなります。

保存場所は、個人のメモ、エディタのスニペット、パスワード管理とは別の安全な文章メモなど、内容を見直せる場所を選びます。定型文に機密性の高い文字列を直接入れず、作業対象や目的だけを記録します。呼び出し名を付けるなら、review-readonlytest-planのように行うことが分かる名前にし、短すぎて意味が曖昧な一文字のキーは避けます。

Step 2: 会話中は標準コマンドを使い分ける

モデル変更、状態確認、レビュー開始など、Codexに組み込まれた操作は標準のスラッシュコマンドから選びます。長い依頼文をそこへ詰め込むのではなく、標準コマンドで会話の状態を整え、その後に保存した定型文を入力する順番にします。たとえばレビューの前に現在のモデルや対象を確認し、定型文で「変更せずに指摘だけ」と指定すれば、操作の目的と依頼の内容が別々に見えます。

標準コマンドの一覧や説明は版によって増減する可能性があります。入力欄の候補に出ない名前を手で送信し続けるのではなく、現在の公式リファレンスと手元の候補を照合します。公式資料はCodex CLIのスラッシュコマンドにまとまっています。候補にない機能を「マクロ」と呼んで補うより、まず標準機能で目的が満たせるかを確かめます。

Step 3: 変わらない前提はAGENTS.mdへ分ける

毎回同じように守ってほしいプロジェクトの前提は、依頼文へ毎回貼るよりAGENTS.mdへ分ける方が管理しやすくなります。回答の言語、変更前に確認する項目、テストの方針、ファイルの扱いなど、複数の依頼に共通する内容が候補です。一方で、今日だけの対象パスや今回だけの納期を置く場所ではありません。共通のルールと案件ごとの指示を分けることで、定型文が古くなってもプロジェクトの基準を保ちやすくなります。

OpenAIの公式ガイドでは、AGENTS.mdをプロジェクトやユーザー単位の指示として扱う考え方が説明されています。どの場所のファイルが読まれるか、より近い場所の指示がどう影響するかは、導入前にAGENTS.md公式ガイドで確認します。登録した文章を呼び出すマクロと、作業時に常に参照される前提を同じものとして扱わないことがポイントです。

Step 4: 送信前の確認を一手入れる

定型入力が便利になるほど、古いパス、古いモデル名、終わった課題の条件が残る危険があります。貼り付けたら、対象フォルダー、変更可否、出力形式、確認方法の四点だけを目視します。変更を伴う依頼なら「まず計画と差分の説明だけ」と書き、読み取りだけでよい依頼なら「ファイルを書き換えない」と書きます。定型文を呼び出す操作と、依頼を送信する操作を分けるだけでも、意図しない作業を止めやすくなります。

確認結果は、依頼文そのものではなく、使った名前、対象、実行した日時、結果の要点だけを残します。毎回全文を保存すると古い条件が増え、どの文が効いたか分からなくなります。定型文を更新するときは、名前に版を付けるか変更日を添え、古い文をすぐ削除せず短期間だけ比較できる状態にします。

Windowsで定型入力を崩さず使う

Windowsでは、文字を正しく保存できていても、端末のコードページ、PowerShellの入出力、フォント、Codexへ渡る入力経路のどこかが合わないと、日本語の定型文が崩れて見えることがあります。Codexの問題と決めつける前に、メモ帳やエディタで保存した文字、PowerShellが表示する文字、Codexの入力欄に見える文字を順番に比べます。見た目が崩れているだけなのか、送信された文字列自体が変わっているのかを分けることが最も重要です。

Microsoft Learnは、PowerShellの版によって標準の文字コードや-Encodingの扱いが異なると説明しています。PowerShell 6以降の出力はUTF-8のBOMなしが基本ですが、Windows PowerShellではコマンドレットごとの既定値が一貫しません。定型文をファイルから読む場合は、保存時と読み込み時の文字コードを明示し、端末側の設定だけで直そうとしないようにします。出典はMicrosoft Learnの文字コード解説です。

Step 1: まず文字列そのものを確認する

最初はCodexを起動せず、日本語、半角記号、改行を含む短いテスト文を同じ入力経路へ渡します。保存したファイルをエディタで開き、文字が正しく見えるか、PowerShellで読み込んだときに欠落しないか、貼り付け先で記号にならないかを順番に見ます。日本語だけが崩れるならコードページやフォント、改行だけが崩れるなら入力経路や保存形式、特定の記号だけが欠けるならエスケープや貼り付け方式を疑います。

PowerShellでファイルを読む場合は、使用している版に合う-Encodingを指定します。たとえばUTF-8で保存した短いメモを読み、画面に同じ文が出るかを確認します。確認用の文章には実際のプロジェクト情報を入れず、再利用する定型文の構造だけを残します。テスト文が正しく表示されてから、実際の依頼文へ進むと原因を狭く保てます。

Get-Content -LiteralPath .\prompt-sample.txt -Encoding utf8

Step 2: コンソールのコードページを確認する

コマンドプロンプトや一部の端末では、現在のコードページをchcpで確認できます。Microsoftの公式資料では、引数なしのchcpが現在の番号を表示し、番号を指定すると新しいコードページを適用すると説明されています。UTF-8を使う場合でも、起動済みのプログラムが以前の設定を保持することがあるため、変更後に新しい端末とCodexを開き直して同じテスト文を試します。コードページを変えただけで全ての入力経路が同じになるわけではありません。

chcp
chcp 65001

chcp 65001を常に使えば必ず直る、と決めつけるのは避けます。端末のフォントが日本語の字形を持たなければ四角い記号になり、ファイル側が別の文字コードなら読み込み時に崩れます。表示、保存、読み込みの三つを同じテスト文で比べ、どの段階から差が出たかを記録します。詳しくはMicrosoft Learnのchcpリファレンスを確認してください。

Step 3: 貼り付けと入力を分けて試す

同じ定型文を、クリップボードから貼り付ける場合と、短く分割して手入力する場合で比べます。貼り付けだけが崩れるなら、クリップボードを経由するアプリや端末の変換が原因かもしれません。どちらも崩れるなら、保存ファイルや端末の表示設定を先に見ます。長い文章をいきなり試すと、どの文字が境目になったか分からなくなるため、最初は日本語、絵文字を含まない記号、改行を少量ずつ増やします。

Codex側で入力が欠ける場合は、文字化けと長さの問題を分けます。表示は読めるのに末尾だけ欠けるなら、端末の表示幅や入力欄の制限、貼り付け処理の可能性があります。文字が?や別の記号になるなら、変換前後の文字コードを確認します。原因が分かるまでは、短い定型文にして対象と完了条件を分けて入力する方が、失敗した依頼を繰り返さずに済みます。

マクロに向く依頼と向かない依頼

定型入力へ向くのは、目的と確認方法が何度使っても大きく変わらない作業です。読み取り、レビュー観点の列挙、テスト計画の下書き、変更前の確認項目などは文章にしやすく、毎回同じ骨格で呼び出せます。一方、対象の範囲が毎回違う大規模な変更、削除や公開を伴う操作、最新の契約や利用条件に依存する判断は、固定文だけに任せると古い前提が残ります。定型化の前に、変わらない部分と変える部分を分けます。

目的 定型入力にしやすい部分 毎回確認する部分
読み取り 観点、出力の見出し、禁止する変更 対象ファイル、期限、必要な深さ
レビュー 命名、例外、テスト、互換性の観点 差分の範囲、既知の制約、優先度
テスト計画 前提、成功条件、失敗時の記録方法 実行する環境、利用可能な時間、対象版
変更依頼 変更前の確認、差分の説明、検証の順番 書き換え可否、対象パス、戻す条件

向いている例は読み取りから始める

最初の定型文は、ファイルの読み取りと説明に絞るのが適しています。「この範囲を読み、問題候補を理由付きで示し、変更案は書かない」のように書けば、結果を見てから次の依頼を考えられます。読み取りだけなら、定型文の誤りがそのままファイル変更につながりにくく、対象指定や出力形式が適切かを落ち着いて確認できます。十分に試してから、必要な場合だけ変更依頼の定型文を別名で作ります。

変更依頼は固定文を短くする

変更を依頼する定型文では、実装の細部を長く決めるより、守る条件と確認の順番を明記します。「既存の公開インターフェースを変えない」「先に差分の方針を説明する」「変更後は指定した検査だけを行う」のように、判断の境界を短く書きます。実際のファイル名やバージョンを固定文へ埋め込まず、送信前に毎回差し替えます。これにより、別の案件へ古い対象を持ち込む事故を減らせます。

危険な操作は一つの呼び出しにまとめない

削除、広い範囲の置換、外部への送信など、結果を戻しにくい操作は、長い定型入力一つにまとめません。調査、計画、変更、確認を分け、各段階で出力を見てから次へ進めます。短い呼び出しで便利になるほど、何を省略したかが見えにくくなるためです。Codexが提案した内容を採用する前に、対象、差分、検証結果を人が確認できる形式を定型文へ含めると、速度と安全性のバランスを取りやすくなります。

うまくいかないときの切り分け

Codexマクロが使えないように見えるときは、登録機能の有無、入力文字の欠落、指示の適用範囲、版の違いを一度に疑わないことが大切です。まず「保存した文章を正しく呼び出せたか」を確認し、次に「Codexの入力欄へ同じ文字が届いたか」を見ます。その後で、標準コマンドの候補、AGENTS.mdの場所、現在のクライアント版を調べます。事実を層ごとに記録すれば、マクロという名前に引きずられず原因を狭められます。

文字が崩れたときは表示と内容を分ける

画面上の日本語が崩れていても、送信された内容が正しい場合があります。まず同じ定型文をメモ帳やエディタで開き、次にPowerShellで表示し、最後にCodexへ貼り付けます。各段階のスクリーンショットや短い結果を残し、「見た目だけの問題」と「実際の文字列の変化」を分けます。フォントの変更で直るなら文字コードを変えず、保存形式の変更で直るなら端末だけを変更しない、というように原因へ直接手を入れます。

標準コマンドが見つからないときは版を見る

入力欄で/を押しても期待する候補が出ない場合、名前の入力間違いだけでなく、使っている入口と版の違いを確認します。公式リファレンスにある名称でも、すべての画面で同じ表示になるとは限りません。codex --versionで版を記録し、現在の公式資料と照合したうえで、目的を定型文やAGENTS.mdへ移せるか考えます。候補にない名前を外部の短縮キーで呼び出しても、標準機能として登録されたことにはなりません。

指示が毎回変わるときは置き場所を見直す

定型文にプロジェクトの規則まで詰め込むと、案件ごとの対象指定と混ざって更新しにくくなります。反対に、AGENTS.mdへ今日だけの依頼を書けば、関係のない作業にも影響する可能性があります。複数の依頼に共通する前提、今回だけの対象、会話中だけの操作を三つに分け、短いテスト用の依頼で適用範囲を確認します。どの文章が効いたか説明できない状態なら、定型化の前に文を分割する方がよいでしょう。

Codexマクロの結論

Codexマクロを調べるときの結論は、任意の名前を付けたマクロ登録を前提にせず、再利用したい内容を役割ごとに分けることです。会話の状態変更は標準スラッシュコマンド、複数の依頼に共通する規則はAGENTS.md、その都度変わる対象と完了条件は保存した短い定型文へ置きます。入力履歴やVimモードの取り消しは定型文を編集しやすくする機能であり、任意の呼び出し名を追加する機能とは違います。

2026年9月9日時点では、0.153.3、0.153.4、0.154.0-alpha.6が異なる位置づけで公開されています。公式リリースと公式リファレンスを確認し、版番号、入力経路、対象範囲、結果を小さく記録してから自分の定型文を育てるのが確実です。Windowsで日本語が崩れる場合も、コードページだけを変えるのではなく、保存、読み込み、表示、貼り付けを同じテスト文で比べます。マクロという言葉を目的へ分解すれば、便利さを保ちながら、古い条件や意図しない変更を呼び込まずにCodexを使えます。

参考になったら ♡
Codexer Navi 編集部
@codexer_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。