Codex マークダウン編集の使い方｜注釈と修正依頼の手順

Codex マークダウン編集とは

Codex マークダウン編集とは、AI に文章を一括生成させるだけでなく、既存の .md ファイルを開き、人が内容を読みながら必要な箇所を直していく使い方を指す。README、設計メモ、利用手順、変更履歴などは、内容の正しさに加えて、見出しの粒度、リンク、コード例、表の整合性も重要になる。画面内で対象箇所を選べると、「この段落を短く」「この見出しだけ具体化して」と依頼範囲を限定でき、ファイル全体を渡すより意図が伝わりやすい。OpenAI の公式変更履歴では、2026年7月9日のデスクトップアプリ更新で Markdown とコードの直接編集、インライン注釈、選択内容の修正依頼が追加されたと案内されている（出典: Codex changelog）。

2026年7月9日の更新で変わった点

更新前も Codex に Markdown ファイルの作成や書き換えを頼むことはできたが、確認は会話の返答や外部エディタの差分に頼る場面が多かった。今回の更新では、開いた Markdown やコードを同じ画面で直接編集し、選択した内容について Codex へ修正を頼める。さらに行や範囲へ注釈を置けるため、「ここは断定を弱める」「この例は Windows 向けに変える」といったレビュー意図を、対象箇所と結び付けて渡しやすくなった。

直接入力・注釈・修正依頼の違い

誤字や句読点のように答えが明らかな変更は、人が直接入力したほうが速い。内容は正しいが読みづらい箇所には注釈を付け、何が問題かを記録すると、あとでまとめて見直せる。文章の再構成や説明の追加など、複数の書き方を検討したい箇所は、範囲を選んで Codex に修正を依頼するのが向く。この三つを区別すると、小さな修正まで毎回 AI に委ねたり、大きな変更を手作業で抱えたりせずに済む。

始める前に確認すること

マークダウン編集を始める前に、Codex が対象ファイルへ到達できる状態を整える。ChatGPT デスクトップアプリは Windows と macOS に対応し、チャット、プロジェクト、フォルダから作業場所を選べる。公式の案内では、Codex を使う場合は「New chat」から始め、必要なファイルや文脈を添えて望む結果を説明する流れが示されている（出典: ChatGPT desktop app）。ファイルを開けても、依頼の対象が別のフォルダなら編集できないため、最初の作業場所の選択が重要だ。

アプリと対象フォルダを確認する

まずデスクトップアプリを最新状態にし、Markdown ファイルを含むフォルダまたはプロジェクトを開く。複数のコピーがある場合は、更新したいファイルの場所と名前を先に確認する。たとえば docs/guide.md と archive/guide.md が同時に存在すると、ファイル名だけの指示では取り違えが起こりやすい。依頼文では作業場所からの相対パスを示し、「このファイルだけを対象にする」と範囲を固定すると安全だ。

保存前の状態を残しておく

文章を直す前に、現在の内容へ戻れる状態を確保しておく。Git で管理している文書なら変更前の状態が記録されているかを確認し、管理外のメモなら複製を用意する。直接編集は手軽だが、複数段落をまとめて置き換えたあとで元の表現が必要になることもある。特にリンク先、コマンド例、製品名を含む技術文書では、読みやすさの改善と同時に事実まで変わっていないか比較できる土台を残したい。

Codex でマークダウンを直接編集する手順

基本の流れは、ファイルを開く、対象を選ぶ、修正条件を伝える、提案を確認する、保存後に全体を読む、の五段階である。一度に文書全体を作り直すより、見出しまたは数段落ごとに進めるほうが差分を理解しやすい。とりわけ README や手順書にはコードブロックと相対リンクが混在するため、文章だけを自然にしてほしいのか、例まで更新してよいのかを先に区切ると失敗を減らせる。

Step 1: 対象の Markdown ファイルを開く

デスクトップアプリで作業するプロジェクトを選び、対象の .md ファイルを開く。似た名前のファイルがある場合は、画面に表示されたパスと先頭の見出しを見比べる。Codex には「docs/setup.md を開き、まだ変更せず構成だけ確認してください」と伝えるとよい。最初から編集を求めず、対象、見出し数、リンク数などを確認させれば、違うファイルへ変更を加える事故を避けられる。

Step 2: 直したい範囲を選択する

修正したい文、段落、コードブロックを画面上で選択する。対象が広すぎると、残したい説明まで短縮されたり、見出しの順序まで変わったりするため、まずは一つの論点に絞る。「この段落の意味は保ち、重複表現だけを削る」のように、保持条件と変更条件を一緒に伝えるのがコツだ。製品名、版番号、URL など変更してはいけない文字列があれば、それも依頼時に明記する。

Step 3: インライン注釈で意図を残す

すぐに修正案を決められない箇所は、インライン注釈で問題点を残す。注釈には「読者が前提知識を持たない」「前段と内容が重なる」「根拠 URL が必要」など、判断できる粒度の理由を書く。単に「わかりにくい」とだけ書くより、読み手と不足情報を示すほうが Codex の提案は具体的になる。複数人で確認する文書でも、対象行と指摘が結び付くため、どの文章への意見かを見失いにくい。

Step 4: 選択範囲の修正を依頼する

選択した文章に対して、目的、読者、長さ、残す情報を一文ずつ伝える。たとえば「初めて使う人向けに言い換える。150字以内にする。コマンドと URL は変えない」と指定すれば、文体だけでなく合格条件も明確になる。修正案が意図と違う場合は、文書全体をやり直させず、「二文目の断定だけ弱める」のように差分を小さくして再依頼する。小刻みな修正は、事実の混入や構造崩れの発見にも役立つ。

Step 5: 差分を確認して保存する

提案を受け取ったら、追加・削除された行を確認し、意味、書式、リンクの三点を点検する。Markdown は画面上で自然に見えても、見出し記号の数、コードフェンス、表の区切りが一文字欠けるだけで表示が崩れる。最後にファイル全体を先頭から読み、同じ用語が別表記になっていないか、選択外の段落が変わっていないかも確かめる。問題がなければ保存し、表示結果を確認して編集を終える。

修正依頼を具体的にする書き方

Codex への依頼は、抽象的な感想より確認可能な条件にすると安定する。「きれいにして」では、語調、長さ、構成のどれを変えるべきか判断できない。「対象読者は初めて CLI を使う人」「専門語には一文の説明を添える」「見出しとコード例は残す」のように、読み手、変更範囲、保持条件を分けて書くとよい。とくに技術文書では、自然な文章にすることと、技術的に正しいことを別の条件として示す必要がある。

誤字修正と文章整理を分けて頼む

誤字修正と段落の再構成を同時に頼むと、どの差分が必要な修正で、どれが提案による変更か判別しにくい。最初は「誤字、送り仮名、句読点だけを直し、表現は変えない」と依頼し、その確認後に「重複する二文を一文へまとめる」と進める。目的ごとに依頼を分ければ、望ましくない変更だけを戻しやすく、レビューする側も短時間で判断できる。

コードブロックとリンクを保護する

Markdown の技術文書では、説明文の中にコマンド、設定例、相対リンクが埋め込まれている。文章を短くする依頼でも、コードブロックの中身や URL まで書き換える必要はないことが多い。「本文だけを編集し、バッククォート内、リンク先、ファイルパスは変更しない」と指定すると、守る境界が明確になる。版番号や料金のように更新されやすい情報は、公式ページと照合してから確定する。

文書全体と選択範囲を使い分ける

見出しの並びや用語統一を確認するときは文書全体を見せる必要があるが、実際の書き換えは選択範囲へ限定できる。「全体を読んで重複箇所を指摘し、変更はまだ行わない」と先に頼み、修正候補を確認してから段落ごとに直すとよい。調査と編集を分けることで、Codex が良かれと思って広い範囲を変えるのを防ぎ、人が編集方針を保ったまま支援だけを得られる。

デスクトップアプリと CLI の違い

どちらも Markdown を作成・編集できるが、確認方法が異なる。デスクトップアプリは開いたファイルを視覚的に読み、選択範囲や注釈を起点に対話しやすい。CLI は作業フォルダ内の複数ファイルを検索し、決めた規則に沿ってまとめて変更する場面に向く。OpenAI の公式資料も、Codex CLI は作業フォルダのファイルを作成・編集できる一方、視覚的なファイルプレビューや注釈画面を持たないため、出力先と検証内容を報告させるよう勧めている（出典: Work with files）。

読みながら直すならデスクトップアプリ

文章のニュアンス、見出しの流れ、注釈への対応を一つずつ判断したいときはデスクトップアプリが扱いやすい。対象箇所を選んだ状態で修正を頼めるため、行番号を数えたり長い文章を貼り直したりする負担が減る。特に仕様書や README のように、人が意味を判断しながら完成度を上げる文書では、提案をその場で読み、直接入力と Codex の修正を交互に使える利点が大きい。

規則的な変更なら CLI

複数の Markdown に同じ見出しを追加する、古いリンクを一覧から探す、表記ゆれを候補として抽出するなど、範囲が広く規則が明確な作業は CLI が向く。ただし視覚的な注釈画面がないため、「変更したファイルを列挙する」「検証結果を報告する」「指定外のファイルは変えない」と依頼に含めたい。まとめて変更したあと、重要な文書だけをデスクトップアプリで読む組み合わせも現実的だ。

うまく編集できないときの確認点

修正依頼が通らないときは、能力不足と決めつける前に、対象、範囲、保存状態を切り分ける。別のコピーを開いている、選択が解除されている、依頼文の「残す条件」が足りない、といった小さなずれが多い。問題を一度に解決しようとせず、まず対象ファイルを特定し、次に一文だけで動作を試し、最後に長い段落へ広げると原因を見つけやすい。公式変更履歴で提供時期や更新内容を確認することも、古い版との違いを判断する助けになる。

ファイルが見つからない場合

対象ファイルが表示されない場合は、開いているプロジェクトと実際の保存場所が一致しているかを確認する。ファイル名だけでなく相対パスを伝え、Codex に親フォルダと先頭見出しを報告させると取り違えを減らせる。新しく作ったファイルが一覧へ反映されないときは、一度別の項目を開いて戻り、表示を更新する。それでも見つからなければ、同名ファイルの有無と拡張子を確認する。

選択外まで変更された場合

選択した段落より広い範囲が変わったときは、その提案を確定せず、変更条件を狭めてやり直す。「選択範囲以外は一文字も変更しない」「見出しは残す」「リンク先は維持する」のように境界を具体化する。文書全体の整合性を保つために周辺を直す提案が必要な場合もあるが、そのときは先に候補だけを説明させ、人が許可する範囲を選んでから編集へ進むとよい。

表示が崩れた場合

見出し、表、コードブロックの表示が崩れたら、内容より先に Markdown 記号を確認する。見出しの # と本文の間の空白、コードフェンスの開始と終了、表の列数、箇条書きの字下げが主な確認箇所だ。Codex には「内容を変えず、Markdown の構文エラーだけを指摘する」と頼み、指摘を見てから一箇所ずつ直す。構文と文章を同時に書き直さないことが、原因の切り分けにつながる。

まとめ

Codex マークダウン編集は、生成した文書を受け取るだけの機能ではなく、人が画面で読み、対象を選び、注釈を残しながら AI と推敲するための手段になった。2026年7月9日の更新で、デスクトップアプリ内の Markdown・コード直接編集、インライン注釈、選択内容への修正依頼が公式に加わったため、README や仕様書を詰める作業へ取り入れやすい。最初は一つのファイルと短い段落で試し、保持する文字列と変更範囲を明示し、差分と表示を確認してから保存するのが堅実だ。読むことを中心にするならデスクトップアプリ、規則的な横断変更なら CLI と使い分ければ、文章の品質と編集速度を両立しやすくなる。