AI で記事づくりは何が楽になるか：EmDashラボの制作をエージェントで回して分かった、人に残す仕事

「AI を使えばメディア運用が楽になる」と聞いても、何がどこまで楽になるのかは見えにくいものです。記事を丸ごと AI に書かせて、そのまま公開してよいのか。品質や信用は落ちないのか。オウンドメディアを始めたい会社ほど、ここで止まります。

先に答えを書きます。EmDashラボでは、調べる・書く・図を描く・形式を確かめる・CMS（ホームページの更新システム）に下書きを入れる、までを AI エージェントに任せています。書いた事実が正しいかは、書いた担当とは別の AI エージェントが、出典や検証データと照らし合わせて確かめます。人に残しているのは、何を書くかを決めることと、公開するかを決めることです。 この記事も、その流れで AI エージェントが調査と執筆を行い、担当者の指示を受けて公開しました。以下は、その流れを手の内ごと公開する記録です。

何を、いつ、どうやって確かめたか

• 対象：EmDashラボの記事制作の仕組み一式。このサイト（EmDash 0.30 系で運用）のリポジトリにある、制作手順の文書、チェックの道具、CMS への投入の道具です。
• 日付：2026年10月15日。この日に、新しいシリーズ 10 本を同じ仕組みで並行して制作しました。この記事はその 1 本です。
• 方法：手順書と道具の中身を読み、チェックの道具を実際に走らせて、何を止め、何を止めないかを記録しました。EmDash 側の仕組み（AI 用の接続口、権限、AI 向けの手引き）は、公式ドキュメントで確かめました。
• 範囲外：人がかけた時間は計っていません。EmDash の AI 機能の性能比較もしていません。

記事 1 本を、8 つの工程に分けて回している

EmDashラボの記事は、次の 8 つの工程で作っています。

今回の 10 本のシリーズは、さらに役割を分けました。まず、統括役の AI エージェントが 10 本の企画と共通の指示書を作りました。次に、記事ごとに別の AI エージェントが調査と執筆を担当しました。各担当は自分の記事のフォルダしか触らず、本番への投入もしません。キービジュアル（記事の扉絵）の生成、OGP の描き出し、表示確認、本番への投入は、統括役が最後にまとめて行いました。10 本が同じ CMS に同時に書き込んで衝突しないようにするためです。公開は 2026年10月15日、担当者の指示を受けて、統括役が投入の道具で行いました。

AI が迷わないように、決まりごとを文書で渡している

AI エージェントは、指示が曖昧だと、もっともらしい方向に勝手に進みます。そこで、判断の材料をすべて文書にして、作業の場所に置いています。

• 制作の手順書：工程の順番、記事の項目（タイトル、要約、OGP の文言など）、使ってよい書式、やってはいけないこと（本番で公開しない、削除しない、秘密情報を書かない）。
• 媒体の決まり：読者は誰か、カテゴリは何か、タイトルの型、画像の配色。
• 文体の決まり：一文の長さ、専門用語の言い換え、「〜と思います」を使わない、数字には根拠を添える、など。
• 公開前のチェックリスト：事実と出典、読者目線、表示、メタ情報。
• 手本の記事：解説記事と検証記事を 1 本ずつ。「この水準で」と言葉で説明するより、見本を見せたほうが揃います。

文書は 3 段に重ねています。サイト全体の開発の決まり、記事制作の共通の決まり、媒体ごとの決まりの順で読み込まれ、矛盾したら媒体側を優先します。同じ仕組みで別の媒体を増やすときは、媒体ごとのフォルダ（決まりの文書と設定ファイル）を 1 組足せば、手順と道具はそのまま使えます。

この「AI 向けの手順書を作業場所に置く」やり方は、EmDash 自体も前提にしています。EmDash で新しくサイトを作ると、AI 向けの手引き（エージェントスキル）が最初から同梱されます。サイトの作り方、追加機能の作り方、操作用の道具の使い方の 3 つです。公式ドキュメントを AI が検索するための窓口も公開されていて、AI が古い知識で書き間違えるのを減らせます。

機械で止められる間違いは、公開前のチェックが止める

工程 4 のチェックは、AI が書いた原稿を機械的に確かめる道具です。本番への投入の前に必ず走り、誤りが 1 件でもあれば投入そのものが止まります。実際に走らせて、何を止めるかを確かめました。

誤りとして止めるもの

• タイトル、要約、カテゴリ、OGP の文言などの必須項目の抜け
• OGP の主題が 3 行を超える、1 行が長すぎる
• 本文の画像の欠落、図の説明（alt）の抜け
• 末尾の出典の節がない、出典に URL がない
• 使わないと決めた言葉（読者に向けない自称、制作者の立場での言い回し、読者に通じない専門用語など）

注意として知らせるもの

• タイトルや要約の文字数が目安から外れている
• 図のキャプションがない、挿し図が 1 枚もない
• リンク先が開けない（リンクの確認を指定したとき）

雛形のままの原稿にかけると、誤り 9 件、注意 1 件で止まりました。完成した原稿で、図の説明を 1 つ消す、出典の節を消す、言い換えると決めた専門用語を 1 語足す、をそれぞれ試すと、どれも誤りとして止まりました。

止まり方は文字どおりです。この記事を書いている途中、禁止した自称を「例」として本文に挙げただけで、チェックは誤りを出しました。文脈は見ず、言葉があるかだけを見ています。誤検出は人が言い回しを変えて直します。

一方で、このチェックが 止めないもの もはっきりしています。出典の URL が書いてあれば、その出典が本文の主張を本当に裏付けているかは見ません。数字が正しいか、言い過ぎていないか、読者に役立つかも判定しません。試しに、本文に「制作時間が 90% 短くなった」という根拠のない一文を足しても、チェックは何も言いませんでした。中身の正しさは、書いた担当とは別の AI エージェントが、出典や検証データと照らし合わせて確かめます。

AI に渡す権限は、EmDash の仕組みで狭くできる

AI に CMS を触らせるとき、いちばん気になるのは「どこまで触れるのか」です。EmDash には、そのための仕組みが標準で用意されています（公式ドキュメントで確認）。

• AI 用の接続口（MCP サーバー）：AI の助手から、記事の作成・更新・下書きと公開版の比較などを行うための窓口です。標準で有効になっています。
• 操作用の道具（CLI）：記事やスキーマ（記事の項目の定義）を、画面を開かずに操作する道具です。
• 鍵（API トークン）と権限の範囲：AI に渡す鍵ごとに、「記事を読むだけ」「記事を書ける」「項目の定義を変えられる」「サイトの設定を変えられる」などの範囲を絞れます。鍵は作成時に一度だけ表示され、漏れたら管理画面から無効にできます。
• 利用者の役割：鍵の権限は、その鍵を持つ利用者の役割の範囲を超えません。役割の一つ「寄稿者（Contributor）」は、下書きを作れても、公開はできません。

EmDashラボの本番への投入は、この鍵を使っています。投入の道具は、本番には既定で下書きとして入れます。公開まで進めるのは、人が「公開して」と指示したときだけです。公開の指示がなければ、すでに公開済みの記事を直すときも、公開中の版はそのままで、改訂の下書きが入ります。

正直に書くと、今の鍵は記事を書く権限を含んでいて、EmDash の仕組み上は公開もできます。権限の範囲の一覧では、下書きの作成と公開が同じ「記事を書ける」に入っているからです。「公開するかは人が決める」という線は、道具の既定と手順書の約束で守っています。より固く守るなら、AI 用に寄稿者の役割の利用者を作り、その利用者の鍵を渡す方法があります。役割で公開ができなくなるので、AI が手順書を読み違えても公開まで進みません。ただし 1.2.0 では、寄稿者が自分の下書きを保存し直せない不具合があります。修正は次の版で入る予定で、詳しくは書く人が増えても回るかに書きました。

権限が狭いことで助かった場面もあります。EmDashラボを立ち上げた翌朝、署名（記事の書き手名）を設定する作業が、管理者の権限がない鍵では管理画面向けの経路を使えず失敗しました。管理者の鍵を渡すのではなく、記事を書ける権限で使える AI 用の接続口の経路に切り替えて解決しました。権限を広げずに済む経路を探すのも、人が決める仕事です。

正直に書くと、任せすぎると間違いも速く増える

AI で速くなるのは、正しい作業だけではありません。間違いも同じ速さで増えます。実際にあった例を書きます。

今回の 10 本は、公開した後に、書いた担当とは別の AI エージェントでファクトチェックをかけました。料金の条件の書き落とし、図と検証データの食い違い、確かめていないことの断定など、直すべき箇所が約 30 件見つかり、直しました。たとえば次のようなものです。

• 画像変換の無料枠を、Workers の有料プランに含まれる枠と取り違えていた。
• 図に並べた項目の数が、本文の表と合っていなかった。
• 確かめていない機能を「入っている」と書いていた。

どれも、形式のチェックでは止まらない種類の誤りです。EmDashラボの手順書では、出典を制作ノートに URL 付きで残すこと、確かめていないことは「確かめていない」と書くことを決まりにしています。後から別の担当が出典を開いて照らし合わせられるようにするためです。

ほかにも、運用して分かった限界があります。

• 出典が付いていても、正しいとは限らない。 上の例のように、書いた担当が出典や検証データを読み違えることがあります。だから、書いた担当とは別のエージェントに照らし合わせさせています。
• 決まりを足すほど、文書の手入れが要る。 手順書と実際の道具がずれると、AI はずれたまま進みます。道具を変えたら手順書も直す、という保守の手間は消えません。
• かかった時間は計り切れていない。 この記事の場合、AI エージェントの作業は、雛形の作成から調査、図版、チェックを通すまで、時計の上で 1 時間かかっていません。一方で、人が企画と公開の判断にかける時間はまだ記録していないため、全体でどれだけ楽になったかは数字で示せません。

「AI が書いた記事は信用できない」という感覚は、もっともです。だからこの記事では、AI と人で作っていることを隠さずに書きました。信用の根拠は、書き手が人か AI かではありません。出典をたどれること、確かめた範囲が書いてあること、間違いを直した記録が残っていることです。EmDashラボの記事は、その 3 つを満たすことを公開の条件にしています。

どんな会社に向いているか

この進め方が合うのは、次のような会社です。

• 月に何本かの記事を出したいが、書き手が足りない
• 書く内容の専門性は社内にあり、最後の確認は自分たちでできる
• 公開前に人が読む時間を、毎回確保できる

反対に、確認する人を置けないなら、AI に記事を任せるのはまだ早いと考えます。また、ここで紹介した流れの多くは EmDash でなくても組めます。WordPress にも外部から記事を投稿する仕組み（REST API とアプリケーションパスワード）があります。EmDash の利点は、AI 用の接続口と、権限と役割で範囲を絞る仕組みが最初から揃っていて、追加の開発なしにこの線引きを作れる点です。

まずは、今の記事づくりの工程を書き出し、「人が決めること」に印を付けてみてください。印のない工程が、AI に任せられる候補です。EmDash で、AI と人の分担まで含めたメディアの仕組みを作りたい場合は、EmDashでつくるWebサイト制作からご相談ください。

参考（一次情報）

• AI Tools（EmDash 公式ドキュメント：AI 用の接続口、役割ごとにできること）https://docs.emdashcms.com/guides/ai-tools/
• MCP Server Reference（EmDash 公式ドキュメント：権限の範囲の一覧、道具ごとに必要な権限）https://docs.emdashcms.com/reference/mcp-server/
• CLI Reference（EmDash 公式ドキュメント：操作用の道具と認証）https://docs.emdashcms.com/reference/cli/
• Agent Skills（EmDash 公式ドキュメント：AI 向けの手引き）https://docs.emdashcms.com/agent-skills/
• EmDash Docs MCP（EmDash 公式ドキュメント：AI が公式ドキュメントを検索する窓口）https://docs.emdashcms.com/docs-mcp/
• Manage secrets and keys（EmDash 公式ドキュメント：鍵の保存方法と無効化）https://docs.emdashcms.com/deployment/secrets/
• WordPress REST API Handbook（WordPress.org）https://developer.wordpress.org/rest-api/
• Application Passwords: Integration Guide（WordPress.org、2020年11月5日）https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/
• EmDashラボの制作手順、チェックの道具、各記事の制作ノート（更新履歴）は、このサイトのリポジトリで確認しました（2026年10月15日）。