AI記事制作を自動化する前に、エンジニアが設計すべきこと

この記事は、Claude Code Skills や Codex の使い方を説明する手順書ではありません。

AIを使って記事制作を楽にしたいとき、最初に考えるべきなのは「どのコマンドで記事を書かせるか」ではなく、記事制作の判断基準をどこに置くかです。

AIに「このテーマで記事を書いて」と頼むだけでは、どうしても一般的な内容になりやすい。
その理由は、AIの文章力だけではなく、渡している文脈が足りないからです。

読者は誰なのか。
どの温度感で書くのか。
どの表現を避けるのか。
どこまで断定してよいのか。
過去にどんな記事を書いてきたのか。
どの状態なら公開してよいのか。

こうした判断基準が毎回チャットの中だけにあると、記事の品質は安定しません。
逆に、ルール・ナレッジ・レビュー観点・検証処理をリポジトリに置けば、AIに渡す文脈を継続的に改善できます。

この記事では、AI記事制作を「生成」ではなく「運用設計」として考えます。

AI記事制作で先に作るべきなのは生成コマンドではない

AI記事制作というと、まず「記事を書いてくれるコマンド」を作りたくなります。

たとえば、次のような流れです。

/article-write テーマ名

これで構成から本文まで出てくるなら便利です。
ただ、生成コマンドだけを先に作ると、結局は「それっぽいけれど、誰が書いても同じ記事」に寄りやすくなります。

理由は単純で、記事の良し悪しを判断する基準がまだ外に出ていないからです。

記事制作で本当に先に作るべきなのは、生成コマンドではなく、次のような情報を置く場所です。

• 記事の目的
• 想定読者
• 文体
• 禁止表現
• 構成ルール
• 引用方針
• レビュー観点
• 公開前チェック
• 過去記事から得た判断

このあたりが整理されていない状態でAIに記事を書かせても、出力はその場限りになります。

単発プロンプト運用と、リポジトリ運用の違いを整理するとこうなります。

観点	単発プロンプト運用	リポジトリ運用
指示	毎回書く	ファイルで再利用する
文脈	会話内に閉じる	リポジトリに残る
品質基準	人によってぶれる	ルールとして共有できる
改善履歴	追いにくい	Gitで差分を追える
チーム展開	難しい	共有しやすい

AIに毎回うまく説明するのではなく、AIが参照できる判断基準を育てる。
この発想に切り替えた方が、記事制作は安定しやすくなります。

AIに記事を書かせるだけでは、なぜ薄くなるのか

AIに記事を書かせて「悪くはないけれど、どこか薄い」と感じることがあります。

それは、AIに渡していない前提を、正確には扱えないからです。
不足した文脈をAIに補わせると、一般論や推測に寄りやすくなります。

テーマについての一般的な説明はできます。
ただし、そのブログがどんな立場で書いているのか、過去に何を扱ってきたのか、どこまで説明すれば読者にとって十分なのかは、別途渡す必要があります。

たとえば、同じ「AI記事制作」というテーマでも、読者によって書くべき内容は変わります。

• 非エンジニア向けなら、ツールの使い方を中心にする
• ライター向けなら、構成や文体の再現性を中心にする
• エンジニア向けなら、ルール管理・検証・リポジトリ運用を中心にする
• 企業メディア向けなら、レビュー責任や公開フローを中心にする

これを毎回プロンプトで説明するのは、手間がかかります。
さらに、説明の粒度が毎回変われば、出力も変わります。

だからこそ、記事制作では「AIに何を書かせるか」よりも先に、AIに何を前提として渡すかを設計する必要があります。

エンジニアが見るべきなのは記事生成ではなく制作基盤

エンジニアの視点で見ると、記事制作は1つの大きな作業ではなく、いくつかの工程に分けられます。

テーマ整理
↓
読者整理
↓
構成作成
↓
本文執筆
↓
レビュー
↓
MDX化
↓
検証
↓
公開

この全体を一気にAIへ任せると、どこで品質が落ちたのか分かりにくくなります。

逆に、工程を分けると、AIに任せやすい部分と、人間が見るべき部分を切り分けられます。

たとえば、frontmatterの不足チェック、画像パスの確認、禁止語チェック、リンク切れ確認、ビルド確認は自動化しやすい領域です。
一方で、主張の妥当性、読者にとって価値があるか、断定しすぎていないか、記事として読めるかは、人間が見るべき領域です。

AIを入れる価値は、全部を任せることではありません。
繰り返し発生する確認や、判断基準に沿った下処理を任せることで、人間が見るべき部分に時間を使えるようにすることです。

まず決めるべき5つの設計項目

AI記事制作をリポジトリ運用にするなら、最初に決めるべきことは5つあります。

1. 誰向けの記事を作るのか

読者が曖昧なままだと、AIの出力も曖昧になります。

「エンジニア向け」といっても、かなり幅があります。

• 個人ブログを書いているエンジニア
• 企業の技術ブログを運用しているエンジニア
• AIコーディングツールを使っているエンジニア
• MDXや静的サイト生成に慣れているWebエンジニア
• チームで記事制作を回したい開発者

この読者像が変わると、必要な説明も変わります。

今回のような記事では、AIツールの使い方そのものより、記事制作のルールをリポジトリに置いて運用したいエンジニアを想定した方が自然です。

2. どの工程をAIに任せるのか

AIに任せる工程は、先に決めておいた方がよいです。

たとえば、構成案のたたき台作成、本文の初稿、表現の重複チェック、MDX化、frontmatter確認などは任せやすい。
一方で、記事の結論や、公開してよいかの判断まで任せるのは避けた方が安全です。

「AIができるか」ではなく、「AIに任せても責任を持てるか」で考える必要があります。

3. どの情報をナレッジとして管理するのか

ナレッジベースには、過去記事だけを置けばよいわけではありません。

むしろ、過去記事をそのまま積むだけだと、過去の癖も一緒に再利用されます。

入れるなら、以下のように分けた方が扱いやすいです。

• 良い導入例
• 悪い導入例
• 避けたい表現
• よく使う言い回し
• 過去に直したポイント
• 失敗した構成
• 公開前レビューでよく出る指摘
• 読者に持ち帰ってほしい結論

重要なのは、記事そのものよりも、なぜその記事を良いと判断したのかです。

4. どこを自動チェックするのか

記事制作では、毎回同じミスが起きます。

frontmatterの不足、タグの不整合、画像パスの間違い、リンク切れ、見出し階層の崩れ、禁止語の混入。
このあたりは、人間が毎回目で見るより、スクリプトやCIでチェックした方が安定します。

GitHub Actions のworkflowは、リポジトリ内のYAMLファイルとして定義できる自動処理で、イベント・手動・スケジュールなどをきっかけに実行できます。記事制作でも、MDXの検証やビルド確認のような処理は、この考え方と相性がよいです。

5. 最終判断を誰がするのか

自動化しても、最後の判断は残ります。

AIが書いた文章が正しそうに見えても、読者にとって価値があるか、断定しすぎていないか、自分のブログの方針に合っているかは、人間が判断する必要があります。

特に個人ブログでは、記事の価値は情報だけで決まりません。
何を見て、どう考えたかが大事になります。

だから、最終判断まで自動化するより、判断しやすい状態まで整えることを目標にした方が現実的です。

リポジトリに何を置くか

記事制作を仕組み化するなら、最小構成はこのくらいで十分です。

content-workflow/
├── rules/
│   ├── writing-guide.md
│   ├── tone.md
│   ├── ng-words.md
│   └── review-checklist.md
├── knowledge/
│   ├── good-examples/
│   ├── bad-examples/
│   └── notes/
├── .claude/
│   └── skills/
│       ├── article-plan/
│       │   └── SKILL.md
│       ├── article-review/
│       │   └── SKILL.md
│       └── article-mdx/
│           └── SKILL.md
├── scripts/
│   ├── check-frontmatter.ts
│   ├── check-links.ts
│   └── check-ng-words.ts
└── posts/

この構成のポイントは、記事本文だけを管理していないことです。

rules/ には、執筆・レビューの判断基準を置きます。
knowledge/ には、過去記事やメモだけでなく、良い例・悪い例・判断理由を置きます。
.claude/skills/ には、繰り返し使う作業手順を置きます。
scripts/ には、人間が毎回見なくてよいチェックを置きます。
posts/ には、実際の記事を置きます。

GitHub README docs では、READMEはプロジェクトの有用性、使い方、期待値などを伝えるためのものとして説明されています。記事制作リポジトリでも、READMEや関連ドキュメントは「このプロジェクトでは何を良い記事とするか」を共有する場所として使えます。

ナレッジベースは過去記事置き場では足りない

AIに過去記事を読ませると、文体や構成の傾向をある程度寄せることはできます。

ただ、それだけでは十分ではありません。

過去記事をそのまま増やしていくと、良い癖だけでなく、悪い癖も残ります。
冗長な導入、似たような結論、便利すぎる言い回し、断定の強さ、説明不足。
これらも一緒に再利用される可能性があります。

そのため、ナレッジベースは「過去記事を置く場所」ではなく、編集判断を残す場所として扱った方がよいです。

たとえば、こう分けます。

knowledge/
├── good-examples/
│   └── 導入がうまくいった記事.md
├── bad-examples/
│   └── 説明が抽象的すぎた記事.md
└── notes/
    ├── 避けたい表現.md
    ├── 断定を弱める基準.md
    └── レビューでよく直すこと.md

AIに渡す材料は、多ければよいわけではありません。
整理されていないナレッジは、出力を安定させるより、むしろノイズになることがあります。

記事を書けば書くほど精度が上がる、というより、記事を書いたあとに判断を残すほど精度が上がると考えた方が近いです。

自動チェックできること、できないこと

記事制作の自動化では、できることとできないことを分けておく必要があります。

自動化しやすいこと	人間が見るべきこと
frontmatterの不足チェック	主張が妥当か
画像パスの確認	読者に価値があるか
禁止語・表記ゆれチェック	断定しすぎていないか
リンク切れ確認	記事として読めるか
ビルド確認	自分の運用思想と合っているか

自動チェックは、品質を保証するものではありません。
品質が落ちる前に、明らかなミスを止めるものです。

たとえば、MDXが壊れている、タグが存在しない、画像パスが間違っている、リンクが切れている。
こうした問題は、人間の編集判断以前の問題です。

ここを自動で潰せるようにしておくと、人間は記事の中身に集中できます。

一方で、「この記事は本当に読む価値があるか」は、自動チェックだけでは判断できません。
その判断までAIに寄せると、記事は整っているのに薄い、という状態になりやすいです。

Claude Code SkillsとCodexをどう使い分けるか

Claude Code Skills は、SKILL.md に手順を書き、必要に応じて /skill-name のように呼び出せる仕組みです。公式ドキュメントでは、同じ指示・チェックリスト・複数手順を何度も貼っている場合にSkill化する例が示されています。

また、Skillは SKILL.md だけでなく、テンプレート、例、スクリプトなどのsupporting filesを同じディレクトリに置けます。これは、記事制作においても「レビュー観点」「出力例」「検証スクリプト」を分けて管理する考え方と相性がよいです。

一方で、Codexは同じ仕組みとして扱うべきではありません。
Codex側には、AGENTS.md を読んでプロジェクト固有の指示や文脈を取り込む仕組みがあります。OpenAI Codex AGENTS.md guide では、Codexが作業前に AGENTS.md を読み、グローバルな指示とプロジェクト固有の指示を組み合わせる説明があります。

つまり、両者は「AIにプロジェクト固有の文脈を渡す」という点では近いですが、同じものではありません。

整理すると、こうなります。

役割	Claude Code Skills	Codex
定型手順の呼び出し	向いている	可能だが、同じ形とは限らない
記事構成レビュー	向いている	可能
MDX化	向いている	向いている
既存リポジトリの修正	可能	向いている
IssueからPR作成	補助的	向いている
CIエラー修正	可能	向いている
プロジェクト固有ルールの参照	.claude/skills や関連ファイルで管理しやすい	AGENTS.md や設定ファイルで管理する形が合う
完全な置き換え	しない	しない

この記事で重要なのは、どちらのツールが優れているかではありません。

大事なのは、ツールごとにルールの渡し方が違うということです。
だから、最初から特定ツールの操作に寄せるより、まずは記事制作の判断基準そのものを整理した方がよいです。

最初から自動入稿まで作らなくていい

記事制作を自動化しようとすると、最後までつなげたくなります。

構成を作る。
本文を書く。
レビューする。
MDX化する。
画像を入れる。
公開する。

この流れを全部自動化できると便利に見えます。
ただ、最初から自動入稿まで作る必要はありません。

むしろ、最初にやるべきなのは次の3つです。

1. 記事制作のルールをファイル化する
2. レビュー観点を固定する
3. 機械的に確認できる部分を自動チェックする

ここができていない状態で公開まで自動化すると、薄い記事を速く出すだけになりやすいです。

記事制作で本当に時間がかかるのは、単に文章を書くことではありません。
何を書くべきかを決めること。
どこまで言ってよいかを判断すること。
読者に何を持ち帰ってもらうかを絞ること。
この部分は、最後まで人間の判断として残ります。

自動化は、そこを消すためではなく、そこに集中するために使うものです。

まとめ: AIに記事を書かせる前に、記事制作のルールをリポジトリに置く

AI記事制作で最初に作るべきなのは、記事生成コマンドではありません。

先に作るべきなのは、記事の判断基準を置く場所です。

• 誰に向けて書くのか
• どの文体で書くのか
• 何を言うのか
• 何を言わないのか
• どの情報を根拠にするのか
• どこを自動チェックするのか
• 最後に誰が判断するのか

これらを会話の中だけに置くと、毎回ぶれます。
リポジトリに置けば、差分を追えます。
改善できます。
他の人とも共有できます。
AIにも再利用させやすくなります。

AIに記事を書かせる前に、記事制作のルールをリポジトリに置く。
この順番にすると、AIは単なる文章生成ツールではなく、制作基盤の一部として使いやすくなります。