この記事を書いた仕組みの話

いま読んでいただいた記事は、私（佐藤誠一）が書いたものではありません。
記事作成AIエージェントが書き、私が編集しました。

かかった時間は、実動で1時間以内です。
同じ長さの記事を自分の手で書いていた頃は、18〜20時間かかっていました。

このページでは、その仕組みの中身を公開します。
9ステップの設計・品質の保ち方・4年半で踏んだ失敗まで、隠さずに書きます。

売り込みのために整えた話ではありません。
すべて自社の記事制作で実行し、いま毎月動いている仕組みです。

記事1本の実動時間が18〜20時間から1時間以内になりました

同じ「SEO記事1本」を作るのにかかった実動時間の推移です。

数字の基準を先に書きます。
ここでいう実動時間は、AIの処理待ちを除いた、人間が手を動かしている時間です。

Claude Code で記事を書く場合、作業時間の約9割はAIの処理待ちになります。
その待ち時間まで含めた経過時間と混同すると、比較にならないためです。

注目していただきたいのは、②と③の差です。
「AIを使う」と「AIをエージェントにする」のあいだに、まだ6分の1以上の開きがあります。

多くの会社は②で止まっています。
プロンプトを登録して、そこが上限だと考えてしまう段階です。

この1時間はほぼ全部が編集の時間です

いま私がやる作業は、編集・チェック・検品だけです。
執筆そのものが、人間の工程から消えました。

つまり上の表の「1時間以内」は、編集にかかっている時間そのものです。
執筆に1時間、そのあと編集に30分、といった足し算ではありません。

そのうえで、編集・検品の工程だけを取り出しても、時間は短くなっています。
3〜4時間かけていたものが、30分〜1時間弱です。

直す箇所そのものが減ったためです。

「品質が上がりました」とは書きません。
主観だからです。

代わりに、私が直す時間が3〜4時間から30分〜1時間弱になった、と書きます。
これなら自社に当てはめて計算していただけます。

外注ライター10名をゼロにして本数はむしろ増えました

人数は外注していたライターの人数で、私を含みません。
2024年は私と外注10名の11名体制でした。

先に書いておきたいのは、案件が減ったわけではないことです。
本数は約30本から34〜35本に増えています。
人員が減ったのは受注が細ったからではなく、1人あたりの生産量が変わったためです。

外注費は年額に直すと、2024年で240〜360万円でした。
現在はゼロです。

そして、時間の3段階（手書き→プロンプト→エージェント）と、この人員の推移は、同じ2段階で動いています。

記事作成の9ステップをそのまま公開します

キーワードの取得から編集まで、9つのステップに分かれています。

各ステップは成果物をファイルに書き出して、そこで必ず止まります。
1ステップ＝1成果物＝1確認ゲートです。

止める理由は、AIに最後まで走らせないためです。
9ステップを一気に通すと、どこで判断がずれたかを人間が追えなくなります。

公開の判断も人間がします。
エージェントが作るのは下書きまでです。

「AIで何ができるか」から設計していません

9ステップの構成は、私がSEO記事を12年書いてきた手順そのものです。
AIのために作り直した工程はありません。

多くのAI開発は「AIで何ができるか」から設計します。
こちらは先に人間の正しい手順があり、それをAIに移しました。

順序が逆になっています。

この差が、途中で捨てた設計がほぼない理由です。
うまくいかないときに疑うのは工程の順番ではなく、その工程をAIに渡す渡し方のほうでした。

品質の保ち方は3つです

AIで記事を書くと質が落ちる、と考えられています。
実際、私も一度落としました。

そのときに選んだ対処が、人間のチェックを増やすことではなく、ルールを仕組み側に持たせることでした。
人間の作業時間を増やす方向に逃げると、AIを入れた意味が消えます。

①90点になるまで出荷させない

構成も本文も、採点役のAIが点数をつけます。
90点に届かないあいだは、書いた本人のAIに書き直させます。

人間が「もう一度書いて」と指示する必要はありません。
合格するまで自分で回るように組んであります。

この手法は、n8n・Dify でワークフローを作っていた時期に見つけました。

②編集ゲートを多層にする

編集は1回ではありません。

• 執筆の時点で、すでにループと編集がかかっています
• そのうえで、別途、編集のゲートを通します
• さらに、その編集ゲートの後に、もう1つ編集ゲートを置いています

1本の記事が、違う基準の検品を何度も通る構造です。

③Geminiを敵対勢力として校正に当てる

品質にいちばん効いたのがこれです。

Claude Code が書いて編集した記事を、Gemini の校正プロンプトにぶつけます。
書いた側と、別のAIに意見を出し合わせます。

単一のAIに書かせて、同じAIに直させると、自分の書き癖を疑えません。
別の系統のAIを当てると、そこが崩れます。

クライアント納品で求められる細かい日本語のニュアンス調整は、これで成立するようになりました。

「AIで記事を書きます」と言う会社は増えました。
複数のAIを対立させている会社は、まだ多くありません。

「同じ文末を3連続させない」が100%守られるようになりました

プロンプトとエージェントの違いを説明するのに、いちばんわかりやすい例です。

文章のルールに、「同じ文末表現を3回続けない」があります。
「〜です。〜です。〜です。」と並ぶと、読みにくくなるためです。

プロンプト時代は、このルールを指示に書いていました。
それでも、守られたり守られなかったりしました。

Claude Code でエージェント化し、プログラムとして処理させたところ、100%防げるようになりました。

指示が「お願い」から「処理」に変わったからです。

抽象的な話に聞こえるかもしれませんが、これが起きているのは1つのルールだけではありません。
文体・表記・禁止表現・数字の扱いまで、同じ構造で仕組み側に移しています。

御社の業務にも、「毎回言っているのに毎回直っていないこと」があるはずです。
それがルールとして書き出せるなら、仕組み側に持たせられます。

4年半で踏んだ失敗を3つ書きます

うまくいった話より、こちらのほうが役に立つと考えています。

①一次情報がない記事は公開しても順位が付きませんでした

AIだけで書き、インターネット上から集めた情報だけで構成した記事を公開しました。
結果は、Google検索で順位が付きませんでした。

AIが集められるのは、すでに検索結果にある情報だけです。
それを組み直しても、Googleから見れば重複でしかありません。

順位を取るには、検索しても出てこない情報を足すしかありません。

だから、いまも人間がやる工程を1つだけ残しています。
一次情報の収集・整理・言語化です。

情報を「見つけてくる」「作り出す」ことは、AIにはできません。

②外注ライターへの指示は何をやっても矛盾に突き当たりました

外注ライター10名の体制で、品質を揃える指示の仕組みを作ろうとしていた時期があります。
マニュアルをGoogleドキュメントにまとめ、文章で伝えにくい部分はYouTubeの限定公開動画とLoomで補いました。

どの手段にも矛盾がありました。

結局、速いほうを選んで自分で直すことになります。
そこから悪循環が始まりました。

1. 修正指示を書く労力と、自分で直す労力がほとんど変わらない
2. 速いほうを選んで自分で直す
3. 直した理由がライター側に残らない
4. 次の記事でも同じ箇所を直すことになる
5. 書き手が育たないまま、同じミスがくりかえされる

「自分で直したほうが速い」。
この判断が、次の依頼のコストを下げないどころか固定してしまいます。

誤解のないように書いておくと、ライター個人の問題ではありません。
業務委託の契約形態そのものから来る、構造の話です。

品質を支えていたのは仕組みではなく、私の作業時間でした。
だから、ルールを人に渡すのをやめて、仕組み側に持たせる方向へ切り替えました。

③プロンプトを渡してもエージェントにはなりませんでした

手持ちのプロンプトを Claude Code に渡し、「これで記事作成のシステムを作って」と指示しました。

返ってきたのは、プロンプトでした。

これでは今までとやり方が変わりません。
ここで時間を使いました。

Claude Code に相談してわかったのは、エージェント開発に使う機能の呼び名を、指示の中に先に並べる必要があることでした。

• スキル
• サブエージェント
• ループエンジニアリング
• モジュール
• プラグイン
• RAG

これらを挙げて「この機能を使って作ってください」と頼むと、返ってくるものが変わりました。

「プロンプトを渡す」と「エージェントを設計する」は、別の作業です。

突破口になった指示文をそのまま載せます

Claude Code で記事作成のAIエージェント化に初めて成功したときに打った指示です。
改変せずに載せます。

以下に添付しているのは、◯◯◯◯の工程とそのルールに関する資料です。
◯◯◯◯するAIエージェントを構築してほしいです。
モジュール、スキル、フック、プラグイン、MCP連携、サブエージェント、RAG、その他最新のClaude Codeの機能でフィットするものがあれば、あと、何か効率的な組み合わせがあれば提案してほしいです。
〜やりたいことの工程とルールに関する資料をすべて添付〜

◯◯◯◯ には、御社の業務名を入れてください。

指示の中に並べた機能の呼び名は、それぞれこういうものです。

うまくいった理由は、使う機能を私が決め打ちせず、「フィットするものがあれば提案してほしい」とAI側に選ばせた点にあると考えています。

ただし、前提が1つあります。
添付する資料は、任せたい業務の工程とルールを人の言葉で書き出したものです。

私の場合はそれが、12年かけて固まった9ステップでした。
ここを先に書き出す作業だけは、省けません。

4年半の年表

作り直した回数は数えきれません。

ただ、この4年半は、AIの進化と並走した4年半でもあります。
2022年の私は、2026年の道具をまだ使えませんでした。

いまから始める方は、もっと早くできます。

根拠は、私の最後の工程にあります。
n8n・Dify から Claude Code への移管は、2ヶ月弱で完成しました。
先にワークフローの設計経験があったからです。

つまり、時間がかかったのは道具の習得ではなく、任せたい業務の工程とルールを書き出す作業のほうでした。
そこは、いまから始める方も同じだけ必要になります。
逆に言えば、そこさえあれば、4年半はかかりません。

つまずくのは途中で諦めるところです

同じものを作ろうとする方を見ていて、最大のつまずきは技術ではありませんでした。

「AIが書く記事なんてこんなもんでしょ」と、本当はもっとできるところで見切りをつけてしまうことです。

技術の差ではなく、前提の差です。

この仕組みを御社の業務で作ります

ここまで書いてきたものは、すべて自社の記事制作で実行した結果です。
現在も、5媒体・月34〜35本を、この仕組みで制作しています。

同じ考え方で、御社の業務をエージェント化する開発をお受けしています。
対象は記事作成に限りません。
工程とルールが書き出せる業務であれば、同じ構造で組めます。

• サービスの内容と価格 → 記事作成AIエージェント開発

お問い合わせ

「何から書き出せばいいかわからない」段階でも構いません。
そこの整理から一緒にやります。