TL;DR
- dev.toとQiitaの両方を見据えたMarkdown管理と自動投稿スクリプトで、AIエディタと組み合わせたアウトプット高速化を狙えます🚀
- Makefile経由のドラフト更新・公開フローで、Front Matterに集約した設定を使い回しつつヒューマンエラーを抑えられます。
- この記事で紹介するリポジトリはテンプレではなく一例なので、構造とフローを参考にしつつ自分仕様へ組み替えてください。
はじめに
AIエディタで記事を書き切りたい、AIに自分の文体を学ばせたい、公開までのリードタイムを短縮したい――そんなモチベーションを持つ人に向けて、私が試行錯誤したGitHubリポジトリ構成を紹介します📚
まずは参考リポジトリとしてhttps://github.com/tom-takeru/articlesを眺めてみてください。ここでは日本語記事をQiitaへ、英語記事をdev.toへ公開し分ける運用をベースにした実践例をまとめています。Qiitaには公式CLIもありますが今回は採用していません。また、dev.toには公式CLIが見当たりませんでした。
必要な要素だけをつまんで、自分のワークフローに合わせて気軽に組み替えてください。
対象読者
自分のAIエディタで記事執筆したい人
ローカルのMarkdownをAIエディタに読み込ませ、プロンプトドリブンで執筆と修正を回したい人に向けた構成です🖊️
AIに記事の書き方を覚えさせたい人
過去記事とドラフトを同じリポジトリに蓄積し、AIに文体や定番の構成を学習させたいニーズに応えます🧠
自分の記事をGitHubリポジトリで管理したい人
履歴管理や差分レビューを活用しながら記事制作を進めたい人にとって、Gitの履歴がそのまま記事のバージョンログになるメリットがあります🗂️
日本語も英語も効率よく出していきたい人
Qiitaとdev.toにワンセットで公開したい人が、言語別のファイルと自動化で二重管理の手間を減らしたいときのヒントになります🌍
リポジトリ全体像
https://github.com/tom-takeru/articlesの全体像を簡単に説明いたします。
-
content/en/とcontent/ja/で言語ごとにMarkdownを管理し、Front Matterのplatformで投稿先をコントロールする仕組みです🗃️ -
scripts/配下のTypeScriptがFront Matterを読み取り、dev.toやQiitaのAPIにドラフト／公開リクエストを送ります。 -
.posts-map.*.jsonでローカル記事とリモート記事のIDや公開状態を同期し、Makefileが差分を検知して必要な処理だけ実行します。
記事公開フロー
Step 1 記事を執筆する
自分の好きなエディタでAIを頼りにしながらMarkdownを書き進めます✍️
リポジトリに既存の記事が揃っていると文体や構成のヒントをその場で引き出せるので、プロンプトを投げつつテンポよく本文を整えてしまいましょう。日本語である程度記事に納得できるまで書いたらAIに翻訳を頼み、英語版も自分の目でレビューしておくと安心です。
Step 2 ドラフトをプラットフォームに作成/更新する
make draftでdev.to／Qiitaの下書きを作成または更新します🧪
PUBLISH_MODEは自動でdraftに固定されるので、誤って公開モードになる心配はありません。
画像を差し込みたい場合の手順
画像はQiitaでもdev.toでもAPIサポートがないようです。すこし面倒ですが、今回の運用の場合は以下の手順で画像を埋め込めます。
- 対象記事のドラフトを作成する（
make draft）。 - 各プラットフォームのドラフト編集画面で画像をアップロードする。
- 生成された画像URLをコピーし、ローカルのMarkdownに貼り付ける。
- 改めて
make draftを実行してリモートのドラフトを更新する。
Step 3 公開コマンドを走らせる
ブラッシュアップが完了したらmake publishを実行します🎯
既存ドラフトが存在しないと弾かれる仕様なので、誤公開のリスクを最小限に抑えられます。
Step 4 GitHubリポジトリのmainブランチに変更内容をマージする
ドラフトや公開の差分が期待どおりなら、作業ブランチにコミットしてプッシュしPRを作ります💾
CIが公開状況と、makeコマンド実行時の公開状況を記録した.posts-map.*.jsonをもとに現在の公開状況をAPIで取得してチェックします。これにより、ローカルでのコマンド実行忘れ（公開漏れ）を防いでくれます。
CIがpassしていれば、mainブランチへマージします。
詳細を知りたい方はhttps://github.com/tom-takeru/articlesのREADME.mdやソースコードを確認してください。
おわりに
AIエディタとGitHubリポジトリを組み合わせると、記事作成から公開までを「プロンプト→差分確認→コマンド数回」で回せるようになります。あとは自分の文体やワークフローに合わせてどこまでチューニングするかが勝負です。ここで紹介した構成をたたき台に、あなた専用のAI記事制作環境をじっくり育ててみてください🌱
余談
この記事はCodex Web x Codex CLIで書きました。Codex Webは私が今推しているOpenAI産のWeb上で並列で複数の仮想環境をそれぞれ用意して動いてくれるLLMコーディングアシスタントです🧰
記事も書いているのでもしよければ読んでください。Codexをフル活用して2日間で80個近くのプルリクエストを作った話