ブログ運営をしていると、記事を書く以外のところで「ちょっとした自動化が欲しい」と感じる場面がじわじわ増えてきます。F1の日程をまとめたい、handoffメモを整形したい、月次のアクセスデータを集計したい——どれも本職のエンジニアに頼むほどではないけれど、毎回手で回すには地味に面倒な作業です。MMDでは、こうした小さなツールやスクリプトをCodex（コデス）に任せていて、Codexによるツール開発が運営の体感をかなり変えました。
本記事は、MMDのAIワークフロー記事シリーズの5本目です。シリーズの中では「ワークフロー②」にあたり、Codexを使ったツール・アプリ・スクリプト開発の実際を扱います。記事制作担当のClaude Code（ちょこ）と並ぶ「もう一本のワークフロー」として、開発・自動化ラインがどう回っているかを整理します。
ブログ運営で「ちょっとした自動化」が欲しくなる瞬間
記事を書いている横で、いつのまにか細かい作業が積み重なっていきます。F1の日程をシリーズ別に整理し直したい、handoffメモのフォーマットを揃えたい、月次のアクセスデータをCSVで切り出したい、WordPressに投稿するときのチェック項目を毎回手で確認したくない、X投稿の文面を毎回ゼロから組みたくない、といった具合です。
どれも「やればすぐ終わる」ように見えるのですが、毎週・毎月のように発生するため、束ねると結構な時間を取ります。1回あたり10分の作業でも、月に10回・12カ月積めば年間20時間です。記事を1本書けてしまう時間を、地味な作業に流していることになります。
かといって、これらは本職のエンジニアに外注するほどの規模でもありません。要件はざっくりしているし、自分の運営スタイルが変わればすぐ仕様も変わります。「自分の手元で完結する小さい道具」に近いものを、その都度作りたい、という感覚に近い領域です。
少し前までは、こうした道具は「あったら便利だけど作る時間がない」のまま積まれていました。AIで開発を任せられるようになってから、この積み残しが少しずつ片付き始めた、というのが実感です。MMDでは、この役回りをCodex（コデス）に固定で任せています。
MMDではCodexを「IT部門の開発・自動化担当」として使っている
MMDのAIワークフローでは、AIごとに役割を固定して運用しています。Codexの位置づけは、ブログ運営の中で言うところのIT部門・開発／自動化担当です。記事を書いたり、公開判断をしたり、運営方針を決めたりといったブログ本体の中核には、Codexは入れません。
シリーズ全体のAI役割分担と、なぜ役割で分けているのかという設計思想は、それぞれ別記事で扱っています。本記事を読みながら全体像が気になった場合は、そちらも合わせてどうぞ。
Codexに任せている作業の範囲
MMDで実際にCodexに任せているのは、おおむね次のような作業です。記事本文には直接入らない、けれど運営に必要な「裏側の道具作り」が中心になっています。
- F1や国内主要レースのカレンダーJSONの生成・変換
- handoff.mdのフォーマット整形・テンプレ生成
- 月次分析用のCSV切り出し・整形スクリプト
- WordPress投稿補助（HTMLチェック・メタ情報の整形補助）
- X自動投稿まわりの骨組み
- momen tools系のWebツール
- ちょっとしたバグ調査やテストコード
共通しているのは、記事の中身そのものではなく、運営フローを支える側の作業であることです。記事の主題や文体、公開判断にかかわる仕事はCodexには渡していません。
記事制作担当のCodexとちょこの線引き
同じAIエージェント系の道具として、Claude Code（ちょこ）も並行して使っています。ちょこは記事制作の編集部、コデスはIT部門の開発・自動化担当、というのがMMD内での役割分担です。
線引きの考え方はシンプルで、記事に直接入る制作物はちょこ、汎用化する仕組みはコデスと決めています。ブログ本文・見出し構成・メタ情報のような「文章として読まれるもの」はちょこの担当、ツール・スクリプト・アプリのような「動くもの・繰り返し使うもの」はコデスの担当、という分け方です。
同じAIエージェント系をなぜ分けているのか、その判断ロジックは別記事で深掘りする予定です。本記事ではコデスの守備範囲だけ押さえておけば十分です。
ツール開発ワークフロー全体像｜目的整理から最終判断まで
Codexに開発を任せるとき、いきなり「これを作って」とプロンプトを投げるわけではありません。MMDでは、ツール開発を6ステップに分けて回しています。
- 目的整理 — チャッピー（ChatGPT）と壁打ちしながら、何を解決したいのかを言語化する
- 要求定義 — テンプレートに沿って、目的・入力・出力・完了条件をチャッピーがファイルに落とす
- 実装依頼 — 要求定義をコデスに渡して、設計・実装してもらう
- テスト・確認 — コデス側で動作確認をかけ、ログを出してもらう
- 運用視点の確認 — チャッピーに「実運用で詰まりそうなところがないか」を相談する
- 最終判断 — TKDが手元で動かしてみて、採用するか・修正するか・お蔵入りにするかを決める
MMD3本柱の製作フロー。ツール開発は真ん中のフロー。
各ステップで誰が何をやっているか
ステップごとの担当が分かれているのは、目的整理・実装・運用視点の確認・最終判断を、それぞれ別の頭で回したほうが詰まりにくいからです。同じスレッドの中で「目的を整理しながら実装する」と、目的の曖昧さがそのまま実装に持ち込まれて、できあがったあとに作り直しになる、という体験が何度かありました。
目的整理と運用視点の確認は、自立型で気を利かせてくれるチャッピーが向いています。そのまま要求定義書のファイルにもしてくれます。実装そのものは、実際にファイル操作可能なコデスのほうが安定します。最後に手元で動かして判断するのは、運営として責任を持つTKDの仕事です。
正直、チャッピーとコデスは従兄弟/従兄弟というか兄弟姉妹のような存在なので、要求整理もコデスでも問題はないです。ただ、CodexがClaudeと大きく違う点として、ChatGPTとCodexの使用量を強要していないという点があります。そのため、使用量節約のため、同じモデルを使用しているChatGPTで目的整理・要求定義作成をしています。実装はファイルが多岐にわったったりもしますし、修正も関連ファイルと合わせて必要だったりするのでファイル操作可能なコデスが必須ですが、要求定義は1ファイルだけなので、チャッピーの出力を自分で保存してもあまり手間にはならない、という判断です。
TKDはPMポジションで目的・要件・確認に専念する
このフローの中でTKDがやっているのは、本職のPMとしての動きとほとんど同じです。目的を整理し、要求定義に落とし、進捗を確認し、出てきた成果物を受け入れ判定する。コードを書くフェーズはコデスが担当しているので、TKDは「コードの善し悪し」ではなく「目的に対して妥当な作りになっているか」、要は一致性検証の検証者側に回れます。
本業で自動車開発のPMをやっている立場としては、この役割分担はかなり馴染みのある構図でした。エンジニア（サプライヤさん）の席にAIが座っているだけ、と言ってもいいかもしれません。技術的な深掘りは相手に任せ、自分は目的・要件・判断材料の整理に専念する。普段の仕事のやり方を、そのままブログ運営の道具作りに転用している感覚があります。
要求定義を書く｜非プログラマーが先にやる仕事
このフローの中で、いちばん効いていると感じているのが要求定義を先に書くというステップです。コデスにツール開発を任せるとき、要求定義を1枚作ってから渡すのと、口頭ベースで投げるのとでは、出てくる成果物の安定度がはっきり違います。
要求定義テンプレートの主要項目
MMDでは、ツール開発の要求定義をテンプレート化していて、毎回同じ枠で書きます。
正直、ソフトウェア開発のPMではないので、正式な要求定義書をよくはわかってないですが…ざっくり漫画で言うネームのようなイメージで作成しています。
主な項目は次の13個です。
| 項目 | 書く内容 |
|---|---|
| 目的 | 何を実現したいか／何が楽になるか |
| 背景 | 今困っていること、現状の運用、必要になった理由 |
| 想定利用者 | 誰が使うか、利用頻度、動作環境の前提 |
| 入力 | 入力ファイル・データ・手入力項目とその場所 |
| 出力 | 生成ファイル・画面表示・チェック結果と出力先 |
| 必須機能 | 必ず必要な機能の箇条書き |
| あるとうれしい機能 | 余裕があればほしい機能 |
| 対象外 | 今回はやらないこと、将来でよいこと |
| 制約・注意点 | 触ってほしくないファイル、機密、環境制約など |
| 完了条件 | 何ができたら完了か、確認に使うサンプル |
| 参考ファイル・資料 | 既存の関連ファイル・参考にすべき資料 |
| 未決事項 | コデスに相談したいこと、まだ決めていないこと |
| チャッピー／TKDメモ | 要求定義作成時の補足メモ |
このテンプレートを毎回埋めてからコデスに渡しています。最初は項目数が多く感じましたが、慣れてくると「埋まらない項目がある＝まだ自分の中で決まっていない論点がある」というアラートとして機能してくれます。
また、このテンプレートをチャッピーに渡しておけば、一問一答形式で埋めてくれるということも可能なので、意外と手間にはなっていないです。
入力・出力・完了条件さえ書けば実装は任せられる
13項目あるとはいえ、コデスに任せるという意味で特に効くのは入力・出力・完了条件の3つです。何を渡すと、何が出てきて、どの状態になったら完成と見なすか——この3つさえはっきり言語化できていれば、間の実装はコデス側で十分組み立てられます。
逆に、ここが曖昧なままコデスに依頼すると、出てくる成果物は「動くけれど、自分が想定していたものとはちょっと違う」になりがちです。「思っていたのと違う」が起きるたびに、要求定義に戻って書き足しています。要求定義はコデスのためというより、自分自身の頭の整理ツールとして効いている、という感覚です。
コードが書けなくても、要件は書ける
このやり方をしていて感じるのは、コードが完全に分からなくても、目的・入力・出力・完了条件は書けるということです。技術スタックの細部や実装方法はコデスに任せるとして、要件定義の側は日本語で書ける範囲がかなり広い、という発見でした。
非プログラマーがAIで開発を進めるときに引っかかりがちなのは、「コードを書けないからAIに頼みたいのに、AIに頼むためにコードの知識が必要そう」という入口の矛盾です。要求定義テンプレートを挟むと、この入口を「自然言語で書ける範囲の作業」に変換できます。コードに寄せず、運用要件に寄せて言語化する、という発想の転換だけで、AIに開発を任せる心理的ハードルがかなり下がりました。
メイン実例｜F1カレンダーJSON生成・変換ツール
具体例として一番分量があるのが、F1カレンダー関連のツール群です。MMDではF1の年間日程を記事内で扱う機会が多く、日程データの整形・変換に手作業を入れたくない、という動機からスタートしています。
ツールの用途｜WordPress記事内表示からmomen tools展開まで
F1カレンダーJSONを軸に、想定している用途は段階的に広がっています。
- WordPress記事内のカレンダー表示：F1日程をJSONで管理し、WordPress記事内にカレンダーUIまたはリストUIで埋め込む
- Cocoon用のショートコード／HTMLパーツ：記事側からはショートコード1行で呼び出せる形にする
- momen tools系ツール：MMDで運用しているWebツール群と同じ場所に、独立したカレンダーツールとして並べる
- 将来の拡張：SUPER GTやスーパーフォーミュラへの横展開、iCal形式の生成、Googleカレンダー連携、プラグイン化
最初に作るのは「F1 2026年シーズンのJSON」と「それをWordPress上で表示する仕組み」の2点ですが、JSONを差し替えるだけで他のシリーズに転用できる構造にしておきたい、というのが要求定義の出発点でした。
要求定義の中身｜何をCodexに渡したか
F1カレンダーJSON＋表示プラグイン用に書いた要求定義は、本記事のテンプレートに沿った構成で、ざっくり以下のような内容になっています。
- 目的：F1記事を「記事型の日程まとめ」から「ツール型のカレンダーページ」へ発展させる
- 入力：年間カレンダーをまとめたJSONファイル（イベントID・シリーズ・年・ラウンド・大会名・セッション名・日本時間の開始終了・サーキット・ステータス・公式情報URL・関連記事リンクなど）
- 出力：WordPress記事内に表示する月間カレンダーUIとリストUIの2形態
- 必須機能：ショートコードでの呼び出し、JSONからの動的描画、イベント詳細表示、関連記事リンク表示
- 対象外：会員管理、有料販売機能、PWA化、公式サイトのスクレイピング自動化
- 制約・注意点：F1の公式ロゴや公式画像は使わない、非公式カレンダー表記を入れる、日程変更可能性を明示する
- 完了条件：WordPress記事内でショートコードが動作し、JSONを差し替えれば表示が変わる
このうち「対象外」と「制約・注意点」を先に書くようにしているのは、後から仕様の膨張を抑えるためです。Codexは依頼すれば気を利かせて機能を盛ってくる場面もあるので、「今回はやらないこと」を先に明示しておくことで、最小単位の動くものを先に出してもらいやすくなりました。
カレンダーUIの要求定義書の記載例（見出し）
カレンダーUIの要求定義書の記載例（目的）
カレンダーUIの要求定義書の記載例（実装方針）
動かしてみた感触と次の展開
実際にコデスに要求定義を渡して動くものができてくると、記事の中で道具が動くという体験そのものが、運営側のモチベーションを変えてくれました。F1の日程を毎年手作業で記事に書き直していた頃と比べると、JSONを更新するだけで記事側の表示が更新されるのは、シンプルに気持ちがよいです。
下記はサンプルですが、見た目はこんな感じです。
F1カレンダーUIサンプル。開発中の画像なので、実際の表示とは異なる可能性があります。
上記の開発期間としては、たぶん数時間くらいですかね。要求定義と合わせてもそんなもんだと思います。自分でやったら…たぶん1週間たっても完成してないです。笑
次の展開としては、SUPER GTや国内主要カテゴリへの横展開、iCal形式での生成、外部カレンダー連携、独立Webツール化、といった候補があります。どれも「JSONの構造を共通にしておけば、表示側のツールは流用できる」という設計が効いてくる領域です。1個目の道具を作るときに、将来の拡張余地まで要求定義に書いておく価値は、ここで実感しました。
今のところはMMD専用のプラグインとなっていますが、将来的には汎用化して活用いただけるようにもできたらいいなとも考えています。とはいえ、そのためには権利関係などいろいろなお勉強も必要そうですが…
補助実例｜X自動投稿まわり
もう一つ、コデスに任せている領域としてX（旧Twitter）への自動投稿まわりがあります。記事公開時の告知や、定期的なリマインド投稿の骨組みをコデスに作ってもらっています。
なぜ初回記事では補助例にしているか
本シリーズでX自動投稿を「補助実例」として扱っているのは、認証情報・APIキー・運用上のセキュリティに関わる比重が大きく、初回紹介の記事で踏み込みすぎないほうがよいと判断したためです。MMDの方針として、セキュリティリスクのあるコードや運用詳細は、ブログ記事で広く共有する対象から外しています。
「Codexに何を任せられるか」を伝えるうえで例として触れる価値はあるものの、踏み込みすぎると本筋（ツール開発のフロー紹介）からずれてしまいます。本記事では位置づけと範囲だけ押さえておき、運用詳細やセキュリティ面の話は、必要が出てきたときに別の記事で扱う想定です。
Codexに任せた範囲｜投稿の骨組みと運用補助
X自動投稿まわりでコデスに任せているのは、おおむね投稿処理の骨組みとテストモードの整備です。投稿フォーマットの組み立て、ドライラン用のテストモード、ログ出力、設定ファイルでの切り替え、といったあたりがコデスの担当範囲になります。
逆に、何を投稿するか・いつ投稿するかの判断はコデス側に渡していません。記事の告知文言やリマインドのタイミングは、ブログ運営側の意思決定として人間に残しています。Codexは投稿の「実行担当」であって、投稿の「編集担当」ではない、という線引きです。
こちらも現在はTKD専用ツールになっていますが、ゆくゆくは公開できるような完成度まで持っていけたらいいな、と思っています。
Codexに任せやすい作業・任せにくい作業
ここまで実例を2つ紹介してきましたが、ツール開発を任せていくうちに、Codexに任せやすい作業と任せにくい作業の境界線が、自分の中ではっきりしてきました。
表現は開発寄りになっていますが、大枠はやはりちょこに任せる任せないの判断とほぼ同じような感じになりました。
任せやすい作業｜単機能・入出力が明確・テスト可能
任せやすい作業には、いくつか共通点があります。
- 機能が単一で、何をすれば「できた」と言えるかが明確
- 入力と出力がファイルや数値などの形で言語化できる
- 動作確認のテストデータを用意できる
- 失敗しても元のデータには影響しない（読み取り専用、または別ファイル出力）
- 運用判断が含まれず、決まった手順で完結する
F1カレンダーJSONの生成・変換、handoff.mdの整形、CSV処理、HTMLチェック、テストコードの作成、といったあたりは、ほぼこの条件を満たします。要求定義を1枚書けば、コデス側で実装〜テストまで通せる領域です。
任せにくい作業｜運用判断・コンテンツ・公開判断
逆に、コデスに任せにくいと感じる作業もあります。
- 運用上の判断を含む作業（投稿のタイミング、優先順位の決定など）
- コンテンツの中身そのものに関わる作業（記事本文、SNS投稿の文言）
- 不可逆な操作を含む作業（公開、削除、課金）
- セキュリティに踏み込む作業（認証情報の扱い、外部APIの権限変更）
- 複数領域をまたぐ調整作業（運営方針の見直し、媒体間の整合）
これらは、AIに任せられないというより、AIに任せると責任の所在が曖昧になる作業です。MMDではこの領域を意識的にTKD側に残し、コデスには実装で支える役を頼んでいます。
境界線の引き方
2つを並べてみると、境界線の引き方は単純です。判断や責任が含まれない、繰り返し型の単機能はコデスに任せる。判断や責任が含まれる作業は、どんなに小さくても人間に残す。この基準で振り分けると、迷いがほとんどなくなりました。
「Codexで何ができるか」を技術スペックで語るより、「何を任せるべきで、何を任せるべきでないか」を運用ルールで決めておくほうが、個人ブログ運営の現場では効きます。技術的にはCodexに任せられる作業でも、運営として渡してはいけない作業はある、という線を先に引いておく感覚です。
Codexと働くと、人間側に何が残るのか
ここまで、コデスにツール開発を任せる流れを整理してきました。最後に、このフローを回したときに人間側に残る仕事を整理しておきます。
PMとして残り続ける4つの仕事
Codexにツール開発を任せても、TKD側に残り続けている仕事は大きく4つあります。
- 目的整理 — 何を解決したいのか、なぜ今その道具が必要なのかを言語化する
- 要求定義 — 入力・出力・完了条件・対象外を、自分の頭で整理してファイルに落とす
- 実データでの確認 — 出てきた成果物を、自分の手元の本物のデータで動かして判定する
- 運用判断 — 採用するか、改修するか、お蔵入りにするか、の最終判断
どれも「コードを書く」仕事ではありません。本職のPMが普段やっているのと同じ動きを、ブログ運営の道具作りに当てはめているだけ、とも言えます。Codexにツール開発を任せても、人間側の仕事が消えるのではなく、仕事の中身がコーディングからPM業に寄っていく、というのが運用してみての実感です。
シリーズの設計思想編でも触れましたが、AIに任せられる範囲が広がるほど、人間側の設計力と判断力の比重はむしろ上がっていきます。Codexによるツール開発は、その典型的な例として位置づけられそうです。
Claude Codeとの使い分けは別記事で扱う
本記事ではCodexに絞って書きましたが、MMDではClaude Code（ちょこ）とCodex（コデス）を、同じAIエージェント系として並行運用しています。なぜ分けて使っているのか、どう判断して振り分けているのか、という使い分けの話は、シリーズの後続記事で別途扱います。
記事制作側のワークフロー（ちょこを使った一気通貫フロー）に関心がある方は、こちらの記事も合わせてどうぞ。本記事と対になる構成で、記事制作担当のAIに何を任せ、何を任せないかを扱っています。
シリーズで使っているAIツールの一覧と課金判断は、登場人物紹介の回でまとめています。Codex以外のAIも含めて、MMD全体のAI構成を確認したい場合はこちらが入口です。
ブログ運営AIワークフローVer2.1（MMD-WF2.1）紹介（全７回+1）
第1回：2026/5/12(Tue) 21:00公開
第2回：2026/5/19(Tue) 21:00公開
第3回：2026/5/26(Tue) 21:00公開
第4回：2026/6/2(Tue) 21:00公開
第5回：2026/6/9(Tue) 21:00公開
本記事
第6回：2026/6/16(Tue) 21:00公開
第7回：2026/6/23(Tue) 21:00公開
Plus One：2026/6/30(Tue) 21:00公開
コメント