ChatGPTの各モード（Chat、work、Codex）を切り換えてブログ記事を作成する

2026年8月14日

私の場合、調べたい事項についてAIと質疑応答を繰り返し、複数の質疑応答（Q&A）を並べる順序を決めたり、記事に入れない質疑応答を決めたりしてブログ記事の大筋を作成しますが、ブログの記事作りに生成AIを使っていると、相談はしやすくても、その後の整理で困ることがあります。

会話が長くなり、記事に使いたい部分を探しにくい
ChatGPTとCodexの内容が別々の場所に残る
AIに全文をまとめ直させると、元の説明が変わることがある
どの素材を採用したのか、あとから確認しにくい

そこで、相談・保存・編集・組み立てを1つのAIに任せず、役割ごとに分け、ChatGPTの各モード（Chat、work、Codex）を切り換えながら記事を作成する方法を検討し実装しました。検討・実装には、ChatGPT-5.6 Solのモデルを使用しました。

注）本記事の内容は正確性を保証するものではない。

（2026年8月14日追記）YouTube動画を追加しました。　https://youtu.be/nW_ril-RQiI

ワークフロー全体像

今回構築したワークフローは、次の4つで成り立っています。

ChatGPT Chat：相談、構想、質疑応答
Codex：Q&A素材の収集、保存、差分同期、検証
Work：素材の要約、選別、記事構成、並び順の決定
Python：承認済み素材の機械的な結合と検証

ポイントは、AIが得意な「考える作業」と、プログラムが得意な「正確に扱う作業」を分けたことです。

なぜ4つに分けるのか

ChatGPT Chatは、考えを深める場所

記事のテーマについて相談し、質問と回答を重ねながら構想を育てる工程にはChatGPT Chatが向いています。

この段階では、最初から完成原稿を作ろうとしません。疑問点を掘り下げ、比較し、別の方法を検討しながら、記事の材料を増やしていきます。

ただし、会話が長くなるほど、そのまま記事として使うのは難しくなります。同じ説明が何度か登場したり、途中で採用しなかった案が残ったりするためです。

Codexは、素材を正確に扱う場所

Codexには、ChatGPTの共有リンクやCodex自身のQ&Aから、記事素材となるMarkdownを収集させます。
本記事では、1つの質疑応答（Q&A）を「MD」と呼んでいます。

ここで重要なのは、文章の良し悪しを判断させることではありません。Codexの役割は、次のような機械処理です。

新しいQ&Aだけを追加する
すでに保存済みのQ&Aを重複登録しない
既存の内容が変わっていたら勝手に上書きしない
出典とハッシュをmanifestへ記録する
保存後に文字数、UTF-8バイト数、SHA-256を検証する

この工程を独立させることで、「AIが要約した結果、元の説明が少し変わった」という問題を避けられます。

Workは、編集方針を決める場所

素材がそろったら、Workで記事フォルダを開きます。Workは複数のファイルを読み、重要な情報を整理して成果物へまとめる工程に向いています。OpenAIも、Chatでは対話による検討、Workではファイルや文脈から成果物を作る作業、Codexでは構築・テスト・修正を行うという使い分けを案内しています（OpenAI公式）。

今回の仕組みでは、Workがいきなり記事を書きません。まず各MDを短く要約し、ユーザーが不要な素材を指定します。その後、採用した素材だけでストーリーと順番を提案し、承認を得てから構成情報を保存します。

Pythonは、承認済みの内容を組み立てる場所

最終的な結合はAIではなくPythonに任せます。

Pythonは、承認済みのファイル順、見出し、接続文を読み、元MDを機械的に結合します。さらに、素材選択後にファイルが増えたり内容が変わったりしていないかを検査し、生成した下書きに元の素材が正しく入っているかをハッシュで確認します。

文章の判断はAI、原文の結合と検証はPython。この境界が、ワークフローを壊れにくくする中心です。

保存単位は「1セッション」ではなく「1記事」

当初は、ChatGPTやCodexのセッションごとに保存することも考えました。しかし、1本の記事には複数の会話や調査結果が混ざることがあります。

そこで、保存の中心を1記事＝1フォルダにしました。

Codex_QA_Archive/
└── article_YYYYMMDD_article-name/
    ├── 001.md
    ├── 002.md
    ├── 003.md
    ├── manifest.json
    ├── ARTICLE_BRIEF.md
    ├── WORK_BLOG_ARTICLE_TEMPLATE.md
    ├── tools/
    │   └── build_article.py
    └── article/
        ├── source_index.json
        ├── article_selection.json
        ├── article_plan.json
        ├── transitions.json
        ├── article_draft.md
        └── verification.txt

001.md、002.mdという番号は、記事内の掲載順ではありません。記事フォルダへ追加された順番です。実際の掲載順は、素材選択後にWorkで決めます。

ChatGPTとCodexの素材は同じフォルダへ入れる

ChatGPT由来のQ&AとCodex由来のQ&Aは、別々のフォルダへ分けません。同じ記事で使う素材なら、同じArticle Archiveへ保存します。

一方で、出典を失ってはいけません。出典はファイル名に含めず、manifest.jsonで管理します。

例えば、ChatGPT由来の素材には共有リンクの識別情報と会話内の位置、Codex由来の素材にはセッションIDとターンIDを記録します。あわせて、質問と回答のハッシュ、取得日時、検証方法も保持します。

この方法なら、ファイル名は単純な連番のまま、次の情報をあとから確認できます。

どのサービスの会話から取得したか
同じQ&Aを二重に保存していないか
元の内容が変わっていないか
どの程度の完全性検証を行ったか

記事を組み立てるときは、ChatGPT由来かCodex由来かではなく、内容に合う順番で自由に並べられます。

ChatGPT共有リンクは差分同期する

ChatGPTで記事について相談したら、共有内容を更新してリンクをコピーします。具体的には、下図にように、チャット画面の右上の「チャットを共有」をクリックし、「リンクをコピーする」をクリックして、リンクをクリップボードに保存する。
その後、Codexはクリップボードの共有リンクを読み、共有されたQ&Aと既存のmanifestを比較します。

初回は、取得できたQ&Aを001.mdから順に保存します。後日、同じチャットへ質問を追加した場合は、共有内容を更新して再び同期します。このとき、保存済みのQ&Aはスキップし、新しく増えたQ&Aだけを追加します。

共有ページのQ&A：1、2、3、4、5
保存済みのQ&A：1、2、3

同期結果：4、5だけを新規追加

同じ位置のQ&Aが以前と異なる内容になっていた場合は、既存ファイルを上書きせず停止させます。自動同期を便利にしつつ、過去の素材を静かに改変しないためです。

共有リンクを使う会話には、APIキー、パスワード、個人情報などの機密情報を含めない運用も重要です。

Workでは「選ぶ→並べる→承認する」の順で進める

Workで記事フォルダを開いたら、最初にWORK_BLOG_ARTICLE_TEMPLATE.mdとARTICLE_BRIEF.mdを読み込ませます。

WORK_BLOG_ARTICLE_TEMPLATE.mdには、毎回共通する編集手順を記載します。ARTICLE_BRIEF.mdには、今回の記事で何を伝えたいか、何を省くか、どの方向でまとめるかを記載します。

作業は次の順番です。

全MD（001.mdなどのQ&A）の内容を1〜2文で要約する
ユーザーが不要なMDを指定する
採用・除外結果を再表示する
ユーザーが選択内容を承認する
採用素材だけで記事ストーリーと順番を提案する
ユーザーが構成を承認する
見出しと最小限の接続文を保存する

素材はMDのファイル単位で除外でき、必要なら特定の行範囲だけを外すこともできます。元のMD自体は変更しません。

この承認工程を挟むことで、AIの最初の提案がそのまま確定することを防げます。記事に必要な判断はユーザーが行い、Workはその判断を構成ファイルへ落とし込みます。

構成情報は3つのJSONへ分けて保存する

Workで決めた内容は、本文へ直接書き込まず、役割の異なるJSONへ保存します。

article_selection.json

記事に採用するMD、除外するMD、部分除外する行範囲を記録します。選択時点のファイル一覧とSHA-256も保持するため、あとから素材が追加・変更された場合は古い選択として検出できます。

article_plan.json

承認済みの記事タイトル、MDの掲載順、章見出し、冒頭文、まとめ文を記録します。

transitions.json

隣り合うMDをつなぐための短い接続文を記録します。接続文は必要最小限にし、元MDの文章と混同しないよう分離します。

この3つを分けることで、「何を使うか」「どの順に置くか」「どうつなぐか」を個別に見直せます。

Pythonで下書きを生成し、元素材を検証する

構成が承認されたら、build_article.pyを実行します。

スクリプトは、まず現在の素材とarticle_selection.jsonに記録されたハッシュを比較します。素材選択後にMDが増減したり、内容が変わったりしていれば、STALEとして処理を中止します。

問題がなければ、article_plan.jsonの順番で元MDを読み、見出しとtransitions.jsonの接続文を加えてarticle_draft.mdを生成します。最後に、埋め込まれた各素材をバイト単位で再検証し、結果をverification.txtへ保存します。

素材選択時のハッシュ
        ↓ 照合
現在の元MD
        ↓ PASS
承認済み順序で結合
        ↓
article_draft.md
        ↓ 再検証
verification.txt

検証用下書きと公開記事は分ける

ここまでの仕組みで作られるarticle_draft.mdは、元Q&Aを壊さず結合した検証用の基礎原稿です。

ただし、Q&Aをそのまま並べると、公開記事としては次の問題が残ります。

「質問」「回答」「はい。」などの会話表現が入る
同じ結論が複数のQ&Aで繰り返される
検討途中の案と最終案が混在する
Q&Aごとの見出し階層が記事全体と合わない
チャット内だけで有効なリンクが残る

そのため、公開前に別ファイルへ編集版を作ります。検証用下書きは証拠として残し、公開版では重複の削除、説明順の整理、会話調の除去、見出しの統一を行います。

つまり、成果物を次の2層に分けます。

検証用基礎原稿：元Q&Aを保持したarticle_draft.md
公開記事用編集版：読者向けに再構成したMarkdown

公開記事を編集しても、元MDと検証用下書きは残るため、必要になればいつでも出典へ戻れます。

実際の記事作成手順

日常の運用は、次の流れになります。

set-article-archiveで記事フォルダを作成または選択する
ChatGPT Chatで記事テーマについて相談する
共有内容を更新し、共有リンクをコピーする
Codexでsync-chatgpt-qaを実行する
（共有リンクを使ってChatGPT Chatの各質疑応答（Q&A）の内容をそれぞれMDファイルに保存する）
必要に応じてCodex側のQ&Aも同じ記事フォルダへ追加する
Workで記事フォルダを開く
全MDの要約を確認し、不要素材をユーザーが指定する
Workが提案するストーリーと順番を確認する
承認後、構成JSONと接続文を保存する
Pythonで検証用のarticle_draft.mdを生成する
verification.txtがPASSであることを確認する
別ファイルとして公開記事用編集版を作る
公開前に事実関係、リンク、固有名詞、機密情報を最終確認する

ARTICLE_BRIEF.mdなどの準備はCodexへ任せられるため、ユーザーがFinderでファイルをコピーして名前を変更する必要はありません。ユーザーが担当するのは、記事の方向性、採用素材、構成、最終原稿の承認です。

Stream Deckで操作を簡単にする

このワークフローは、最終的にStream Deckから起動できるようにすると便利です。

基本ボタンは次の4つです。

ボタン	役割
記事フォルダ	新しいArticle Archiveを作る、または作業対象を選ぶ
ChatGPT同期	クリップボードの共有リンクから新しいQ&Aを追加する
Codex Q&A保存	Codex側のQ&Aを同じArticle Archiveへ追加する
記事作成を開始	Workで素材選択と構成作りを始める

すべてを無人で処理するのではなく、素材選択と構成承認では人間が判断する設計にします。Stream Deckのボタンは作業開始を簡単にする入口であり、承認まで自動化するものではありません。

（参考）モデルの選び方

モデルを選べる環境では、すべての工程に最も高性能な設定を使う必要はありません。

OpenAIの現行ガイダンスでは、GPT-5.6ファミリーについて、Solは高い能力を重視する処理、Terraは性能とコストのバランス、Lunaは効率と大量処理を重視する用途に位置づけられています。また、推論量はMediumをバランスのよい開始点とし、品質向上を測定できる難しい作業でHigh以上を検討する方針が示されています（OpenAI公式モデルガイダンス）。

このワークフローなら、次の考え方が分かりやすいでしょう。

作業	選び方の目安
普段の相談、要件整理	速度と深さのバランスを重視
全素材の分析、記事構成	高い判断力を優先
ファイル一覧、ハッシュ計算、JSON処理	モデルよりスクリプトの確実性を優先
公開原稿の最終レビュー	品質を重視し、必要なら推論量を上げる

重要なのはモデル名を固定することではなく、難しい判断にだけ計算資源を使い、決定的な処理はPythonへ任せることです。モデルや既定設定は更新されるため、公開時点の公式情報も確認してください。

まとめ

今回のブログ制作ワークフローでは、ChatGPT Chat、Codex、Work、Pythonを次のように分担させました。

ChatGPT Chatで考えを深める
Codexで素材を収集し、出典と完全性を管理する
Workで必要な素材と記事構成を決める
Pythonで承認済み素材を安全に結合・検証する
検証用下書きを残したまま、別の公開記事用編集版を作る

この構成の利点は、AIに文章作りを任せながら、元の会話と判断履歴を失わないことです。

相談の自由さ、編集の柔軟さ、機械処理の正確さを分けることで、長いチャットからでも、確認可能で再利用しやすいブログ記事を作れるようになります。

workで、記事作成要領の指示を柔軟に行うことができる。ChatGPT Chatでは、様々な記事作成方法を検討したが、最終的に採用しなかった方法も多いので、それらのQ&Aは除外して最終案が分かりやすように記事構成してとか、図解を入れたいので、図解作成指示文を追加してとかの注文をつけることができた。

また、workのレビューも有効だった。もともと、各Q&Aの内容が薄まらないようにそのままMDファイルに保存し、それらの順番を入れ替えて連結させただけの文章をレビューさせたので、Q&Aの形式表現に対する指摘箇所が多いのは当然なのだが、重複箇所の除去、ブログ記事に不要な会話的表現の除去、見出し階層の修正、参考リンクの番号の修正など、時間がかかる面倒な作業を任せることができる。

本記事は、本記事に記載の方法で公開記事用編集版を作成し、わずかな追記・修正を施したものです。

（参考）作成途中の成果物例（抜粋）

ChatGPT Chatが作成した、Codexへの指示書（抜粋）

Codexへの実装指示：チャットセッションのQ&A完全保存＋検証Skill

現在のCodexチャットセッションに含まれる「ユーザーの質問」と「それに対応するCodexの回答」を、Q&Aの1組ごとにMarkdownファイルとして外部SSDへ保存する仕組みを実装してください。

最終的には、Stream Deckの1つのボタンを押すことで、この処理を実行できるようにしたいです。

今回はまず、Codex側のSkill、必要なスクリプト、必要であればHooks等を実装し、Mac上で正常動作するところまで確認してください。

1. 最重要要件

この処理では、チャット内容の要約、言い換え、整形、省略、修正を絶対に行わないでください。

各Q&Aの内容は、元のチャットセッションに存在する文字列を、そのまま一字一句変更せず保存してください。

特に以下を変更しないでください。

改行
空行
Markdown記号

...

workが作成したMDの順番（抜粋）

どのQ&Aをどの順番で並べるかをworkが提案した。

推奨するMDの順番
015.md
完成した役割分担、全体フロー、作業順序、Stream Deck構成を最初に示す。

011.md
ChatGPT共有リンクからQ&Aを取得し、差分同期する入口を説明する。

012.md
「1記事＝1フォルダ」、ChatGPTとCodexの素材混在、manifestによる出典管理を詳しく説明する。

014.md
素材収集後の要約・選別・構成をWorkへ任せる理由を説明する。

...

workに記事案のレビューを依頼した際の回答（抜粋）

かなり多くの改善点が提案された。

優先して改善したい点

Q&Aの枠組みがそのまま残っている
各章に # Q&A 015、## 質問、## 回答 が入り、回答も「はい。」「私なら」から始まります。読者には元の会話履歴を読んでいる印象を与えます。
例：[article_draft.md (line 7)](/Volumes/TEKQPHYE748/Codex_QA_Archive/article_20260813_chatgpt-mode-switching-blog-writing/article/article_draft.md:7)
公開記事では、質問文とQ&A番号を外し、回答内容を説明文として再構成するのが自然です。
内容の重複がかなり多い
完全一致する段落はありませんが、意味上の重複が目立ちます。
015.mdだけで、役割分担、記事フォルダ、Work、Python、Stream Deck、差分同期まで一通り説明済み
012.mdで「1記事＝1フォルダ」と出典管理を再説明
014.mdでCodexとWorkの分担を再説明
016.mdで最終ワークフローと実行手順を再説明

...