この記事でわかること

• AdSense の「有用性の低いコンテンツ」否認が実際にどう表示されるか
• 記事数が十分にあっても否認される理由
• 否認の本当の原因を切り分ける考え方
• 再申請までに実際に行った改善ステップ

当メディア「WorkPilot」は、AIを主体に立ち上げた直後、Google AdSense の審査で否認 されました。否認理由は「ポリシー違反：有用性の低いコンテンツ」。

AdSense 審査の解説記事は世の中に数多くありますが、その多くは「合格した人の後日談」です。本記事は、否認された直後の生々しい記録 と、そこからの改善過程を、脚色せずに公開します。同じ状況に直面した方の判断材料になれば幸いです。

関連記事：AIメディア運営のリアルな落とし穴5選 ／ AIメディア立ち上げの意思決定ログ

否認時の実際の表示

AdSense 管理画面には、以下のように表示されました。

ポリシー違反が見つかりました
サイトが AdSense プログラム ポリシーを遵守していることを確認してください。

有用性の低いコンテンツ
お客様のサイトは、弊社の定めるサイト運営者ネットワークのご利用要件を満たしていないと判断されました。

参照リンクとして「コンテンツの最小要件」「独自性のある質の高いコンテンツ」「ウェブマスター向けの品質に関するガイドライン」が並んでいました。

「ポリシー違反」という表記の誤解

最初に戸惑ったのは「ポリシー違反」という強い表記です。スパムや禁止コンテンツを掲載した覚えはまったくありません。

調べた結果、AdSense では「有用性の低いコンテンツ」も "ポリシー違反" のカテゴリに分類される ことが分かりました。つまり、何か悪いことをしたわけではなく、「サイトとしての成熟度がまだ基準に達していない」 という意味合いが実態に近いものでした。

否認時のサイトの状態

否認された時点での当サイトの状態は以下の通りでした。

→ 記事の本数は一般的な合格ラインを満たしていた にもかかわらず、否認されました。ここが今回の学びの核心です。

否認の本当の原因を切り分ける

「有用性の低いコンテンツ」は、複数の要因が複合して起きます。当サイトのケースで、原因として考えられるものを切り分けました。

原因1：サイトが新しすぎる（最有力）

開設から約2週間。Google はサイトの 信頼性を時間をかけて評価 する傾向があるとされます。記事数が十分でも、ドメインの運用履歴が浅いと「まだ評価が定まっていない」と判断される可能性があります。

原因2：トラフィックがほぼゼロ（最有力）

月間表示40回、自然流入ほぼゼロ。「実際にユーザーに読まれている形跡」 が乏しい状態は、有用性の判断材料が不足していると見なされやすいと考えられます。

原因3：コンテンツの独自性

記事は構成的で網羅的でしたが、一次情報・実体験・独自の視点 という観点では改善の余地がありました。比較記事が中心だと、「他サイトでも読める情報」と判断されるリスクがあります。

原因4：インデックスの未完了

公開直後でクロールが途上だと、Google が評価できる対象ページが限られます。これも有用性の判断を難しくする一因です。

やってはいけなかったこと：即・再申請

否認直後、すぐに「審査をリクエスト」を押したくなります。しかし調べた結果、同じ状態での拙速な再申請は逆効果 とされることが分かりました。

• 同じ理由で再否認される可能性が高い
• 再申請を繰り返すと、審査の間隔が空けられていく傾向がある

→ 一度落ち着いて、原因に対処してから再申請する のが定石でした。

再申請までに行った改善ステップ

当サイトが再申請に向けて実際に取り組んだステップを共有します。

ステップ1：独自性の強化

最も注力したのが 「一次情報の追加」 です。当サイトの場合、「AIでメディアを運営する過程そのもの」が他にない資産なので、以下を行いました。

• 立ち上げの実工程・実データを記事化
• 比較記事に「実際に使った所感」「独自の視点・図解」を追記
• この否認体験そのものを記事化（＝本記事）

否認というネガティブな出来事も、一次情報として記事化すれば独自コンテンツになる という発想の転換です。

ステップ2：時間とトラフィックの蓄積

• インデックスが進むのを待つ（Search Console で「インデックス済み」の増加を確認）
• SNS 経由の流入導線を整える
• 自然検索流入が出始めるのを待つ

3〜4週間 の期間を空けることを基本方針としました。

ステップ3：内部リンクと回遊性の最終確認

• 関連記事ブロックが全記事に設置されているか
• カテゴリのピラーページから配下記事への導線が機能しているか
• ナビゲーション（メニュー・フッター）が整っているか

この経験から得た教訓

1. 記事数は必要条件であって十分条件ではない

「30本書けば通る」という単純な話ではありませんでした。時間・トラフィック・独自性 という、本数では測れない要素が評価されます。

2. 否認は「失敗」ではなく「途中経過」

新規サイトの多くが一度は経験する関門とされます。否認メールは「あなたのサイトはダメ」ではなく「まだ評価のタイミングが早い」というシグナルに近いものでした。

3. ネガティブも一次情報になる

「審査に落ちた」という出来事は、隠したくなるものです。しかし実体験として記録すれば、それ自体が独自コンテンツになります。本記事がその実例です。

まとめ

• AdSense の「有用性の低いコンテンツ」は "ポリシー違反" と表記されるが実態はサイトの成熟度不足
• 記事数が十分でも、新しさ・トラフィック・独自性 の不足で否認されることがある
• 即・再申請は逆効果。原因に対処してから3〜4週間空けて再申請 が定石
• 改善の核心は 独自性（一次情報）の強化
• 否認体験そのものも、記録すれば独自コンテンツになる

当サイトの再申請の結果は、今後この「AIメディア運営ラボ」で続報として記録していきます。AIメディア運営のリアルを、成功も失敗も含めて公開していく方針です。

この記事でわかること

• AIを主体にメディアを立ち上げる際の全体工程と順序
• 「記事を書く前」に整備すべき土台の正体
• 2週間で30記事を破綻なく公開できた仕組みの設計
• 同じことを再現する人がつまずきやすいポイント

このメディア「WorkPilot」は、AI（Claude Code）を主体に、人間の作業を最小化して運営する ことを目的に立ち上げられました。本記事は、その立ち上げ2週間の 全工程と実際の判断 を、できる限り脚色せずに記録したものです。

「AIでメディアを作る」という言葉は曖昧に語られがちですが、実際にやってみると 「記事をAIに書かせる」のは工程の一部にすぎない ことがわかります。本記事では、その全体像を共有します。

関連記事：Claude Codeは非エンジニアでも使えるのか

立ち上げ工程の全体像

実際に踏んだ工程を時系列で並べると、おおむね以下の順序でした。

1. 認証・基盤整備：WordPress REST API 連携、投稿スクリプト作成
2. 方針の言語化：ターゲット・トーン・禁止事項を1ファイルに集約
3. カテゴリ設計：URL構造を決めてから記事を書く
4. 記事生産パイプライン：マークダウン1本＝コマンド1発で投稿
5. 記事の量産：30本をカテゴリバランスを取りながら生成
6. 資産化の自動化：アイキャッチ・内部リンク・関連記事の自動付与
7. 収益導線：アフィリエイトCTAの仕組み化
8. 計測体制：アクセス解析・サーチコンソール連携
9. 発信：SNS自動連携と手動運用の設計
10. 運用フェーズへ移行：週次・月次のルーチン化

重要なのは、1〜4（土台）に全体の体感で半分以上の労力がかかった ことです。記事生成そのものは、土台が整えば驚くほど速く進みました。

「記事を書く前」が勝負だった

AIメディアと聞くと「AIが記事を量産する」イメージが先行しますが、実際に効いたのは 記事を書く前の設計 でした。

方針ファイルの効果

プロジェクトの前提（ターゲット読者・文体・文字数・禁止事項）を1つのファイルに集約しておくと、毎回の記事生成で品質が安定 します。これがないと、生成のたびにトーンや構成がブレて、結局すべて手直しになります。

特に効果的だったのは 禁止事項の明文化 です。「YMYL領域の断定を避ける」「景表法に配慮する」といったルールを最初に固定したことで、30本を通して表現の一貫性が保たれました。

URL構造を先に決めた

記事を書き始める前に、パーマリンク構造（カテゴリ＋記事スラッグの形式）を確定させました。これは後から変更すると 全URLが変わってSEO評価がリセット されるためです。

実際、立ち上げ途中で構造変更を判断する場面がありましたが、「記事公開から日が浅くインデックスが進む前」 という最良のタイミングだったため、損失をほぼゼロに抑えられました。タイミングの見極めも、AIに状況を整理させることで素早く判断できました。

2週間で30本が破綻しなかった理由

記事数が増えると、内部リンクの整合性・アイキャッチの統一感・カテゴリバランスが崩れがちです。これを防いだのは 「中央管理＋一括反映」の仕組み でした。

中央管理ファイル

全記事のID・スラッグ・カテゴリ・タイトルを1つの管理ファイルに集約し、新記事を追加するたびに1行足すだけにしました。関連記事の自動生成・内部リンクの整合性チェックが、この中央管理を起点に自動で回ります。

一括反映スクリプト

「関連記事ブロックの再生成」「アフィリエイトリンクの反映」を、1コマンドで全記事に適用できるようにしました。30本あっても、1本の修正が全体に波及する作業が数十秒で終わります。

→ 手作業で30本を管理しようとすると破綻する ところを、仕組みで吸収したことが、スピードと品質の両立につながりました。

数字で見る立ち上げ

脚色を避けるため、現時点で確実に言える事実だけを記します。

• 記事数：30本（初期コンテンツ計画を100%消化）
• 固定ページ：4本（運営者情報・プライバシー・問い合わせ・免責）
• 期間：基盤整備から30本公開まで約2週間
• 人間の作業：方針決定、各種アカウント連携、最終確認が中心
• 収益・PV：立ち上げ直後のため、データはこれから蓄積する段階

収益やPVの数字をこの時点で誇張しないこと も、このメディアの方針です。立ち上げ「直後」に成果を語るのは誠実ではありません。成果は今後、計測データとともに正直に記録していきます。

つまずきやすいポイント（実体験）

1. 「AIに丸投げ」では破綻する

AIは指示が曖昧だと曖昧な結果を返します。特に 実作業を伴うと、曖昧な指示の影響が増幅 されます。方針の言語化と、確認しやすい小さなタスクへの分解が、品質の生命線でした。

2. 外部サービスの仕様変更に何度も当たる

立ち上げ中、複数の外部サービスで「以前と仕様が違う」場面に遭遇しました。事前情報どおりに進まないことは前提として、詰まったらその場で代替案に切り替える柔軟性 が必要です。詳細は別記事で扱います。

3. 環境構築の最初の数十分

プログラムの実行環境（Node.js等）の準備で、最初に時間を取られます。ここはエラーメッセージをそのままAIに渡して解決させる発想に切り替えると、一気に楽になりました。

まとめ

• AIメディアの立ち上げは「記事を書く」より 「書く前の土台設計」 が労力の大半
• 方針の言語化・URL構造の確定 を先にやることが、後の品質と速度を決める
• 30本を破綻させないのは 中央管理＋一括反映の仕組み
• 立ち上げ直後の成果は誇張せず、計測データとともに正直に記録する方針
• AIは丸投げでは破綻する。設計と分解 が人間側の最重要タスク

WorkPilot は「AIで運営するメディアの過程そのものをコンテンツにする」ことを掲げています。本記事はその第1弾です。今後も運営のリアルを、成功も失敗も含めて記録していきます。

この記事でわかること

• AIメディア立ち上げで「事前情報どおりに進まなかった」具体例
• 外部サービスの仕様変更にどう対応したか
• 詰まったときの意思決定の考え方
• 同じ轍を踏まないための予防策

AIメディアの立ち上げ解説記事の多くは「うまくいった話」に偏りがちです。しかし実際に手を動かすと、事前情報どおりに進まない場面 に何度も遭遇します。

本記事は、WorkPilot の立ち上げで実際に詰まった5つのポイントを、脚色せずに記録したものです。これからAIで何かを立ち上げる方の 転ばぬ先の杖 になれば幸いです。

関連記事：AIで30記事のメディアを2週間で立ち上げた全工程

落とし穴1：プラグインの連携機能が「消えていた」

SNS連携のために定番プラグインを導入したところ、かつて対応していたSNSの連携機能が、プラグイン側で廃止 されていました。原因は、そのSNSのAPI料金が大幅に値上げされ、プラグイン提供側が高額なAPI料金を負担しない判断をしたためです。

教訓

• 「このプラグインで○○ができる」という解説記事は、書かれた時点の情報
• 特にAPI関連は 数ヶ月で前提が変わる ことを織り込む
• 代替手段（別プラグイン、外部ツール、手動運用）を常に複数用意しておく

→ 対応として、廃止されたSNSは別の方法に切り替え、プラグインで対応可能なSNSはそのまま自動化しました。「1つの方法に固執しない」ことが立ち上げ速度を守りました。

落とし穴2：APIが「無料」から「従量課金」に変わっていた

別のSNSでは、自動投稿用のAPIを使う前提で進めていたところ、API提供形態が無料枠ありから従量課金（pay-per-use）モデルに移行 していました。事前情報では「無料枠で十分」だったものが、実際の管理画面では「クレジット残高ゼロ・要購入」状態でした。

教訓

• 立ち上げ期のメディアにとって、API課金は費用対効果が悪いことが多い
• 「自動化できる＝自動化すべき」ではない
• 手動運用でも、テキストを事前生成しておけばコピペ数秒 で済む

→ 判断として、有料API自動化は見送り、投稿テキストは自動生成しておいて 投稿だけ手動 という折衷案にしました。コストゼロで、むしろ初期は手動の方がエンゲージメントが伸びるという副次的メリットもありました。

落とし穴3：認証が「正しいのに通らない」

外部サービスとの認証連携で、設定はすべて正しいのにエラーで弾かれる 場面がありました。原因は、プラットフォーム側が特定の認証方式の利用を非公式に制限していたためです。画面上は機能があるのに、実際には拒否される、という状態でした。

教訓

• 「設定が正しい＝動く」とは限らない。プラットフォーム側の運用変更がある
• 認証まわりで詰まったら、待つ・別方式に切り替える・代替フローを使う の3択を順に試す
• 完璧主義に陥らず、目的を達成する最短ルート に切り替える

→ この件では、API認証方式に固執せず、手動でデータをエクスポートして分析する方式 に切り替えました。週1回の手作業が増えるだけで、認証地獄から完全に解放されました。

落とし穴4：環境構築の「最初の数十分」

プログラムの実行環境が整っていない状態からのスタートだったため、基盤ツールの導入で最初に時間を取られました。エラーメッセージの意味がわからず、検索しても解決しない、という典型的な詰まり方です。

教訓

• 非エンジニアがAI主体で何かを作るとき、最初の環境構築が最大の心理的ハードル
• エラーメッセージは「自分で解決する」のではなく 「そのままAIに貼って解決させる」
• 一度通れば二度目はない。最初の数十分を耐える だけ

→ エラー文をそのままAIに渡すと、原因と次の一手がほぼ日本語で返ってきます。「自分が理解する」より「AIに解決させる」発想の転換が突破口でした。

落とし穴5：「AIに丸投げ」すると品質が崩れる

最も本質的な落とし穴です。AIに「いい感じに記事を書いて」と頼むと、一般論の寄せ集め が返ってきます。実作業を伴う場合、曖昧な指示の悪影響はさらに増幅されます。

教訓

• AIの出力品質は 指示の質に比例 する
• 「方針・前提・制約・出力フォーマット」を明示するだけで激変する
• 品質ガードレール（方針ファイル）を最初に作る ことが、量産の前提

→ WorkPilot では、トーン・文字数・禁止事項・内部リンク形式などを1ファイルに集約し、毎回の生成がそれを参照する設計にしました。これにより30本を通して品質が安定しました。

共通する教訓：完璧主義より「切り替えの速さ」

5つの落とし穴に共通するのは、「事前計画どおりに進まないのが普通」 ということです。重要なのは、計画の精度より 詰まったときに代替案へ切り替える速さ でした。

• 1つの方法に固執しない（プラグイン／API／手動の選択肢を常に持つ）
• コストが見合わなければ自動化を見送る勇気
• 認証地獄は早めに撤退して別ルート
• 環境構築はAIに解決させる
• 品質はガードレールで担保する

まとめ

• AIメディア立ち上げは 事前情報どおりに進まないのが前提
• 外部サービスの仕様変更（連携廃止・課金化・認証制限）に何度も当たる
• 解決の鍵は計画の精度ではなく 代替案への切り替えの速さ
• 「自動化できる＝自動化すべき」ではない。手動の方が良い場面もある
• 品質は 方針ファイル（ガードレール） で担保する

うまくいった話だけでなく、こうした「詰まった話」こそ、他では読めない一次情報だと考えています。WorkPilot は今後も運営のリアルを正直に記録していきます。

この記事でわかること

• 記事数が増えると破綻する作業と、その自動化の考え方
• アイキャッチ・内部リンク・関連記事・アフィリエイトを自動化した設計思想
• 「中央管理＋一括反映」というアーキテクチャの要点
• 同じ仕組みを自分のメディアに応用するヒント

メディアは記事が10本を超えたあたりから、手作業での管理が急速に破綻 します。アイキャッチの統一感、内部リンクの整合性、関連記事の更新——これらは記事が増えるほど指数的に手間が増えます。

WorkPilot では、これらを すべて自動化 することで、30記事を破綻させずに運用できる状態を作りました。本記事では、その設計思想を（具体的なコードではなく考え方として）共有します。

関連記事：AIで30記事のメディアを2週間で立ち上げた全工程 ／ Claude Codeは非エンジニアでも使えるのか

何を自動化したか

WorkPilot で自動化した主な領域は4つです。

→ いずれも「記事が増えるほど手作業が破綻する」領域です。

設計思想1：正本（Single Source of Truth）を1つに決める

最も重要な設計判断は、「記事の正本はどこか」を1つに固定 したことです。

WorkPilot では、ローカルのマークダウンファイル（articles/*.md）を正本とし、WordPress上の本文は常にそこから再生成 される設計にしました。

なぜこれが重要か

• 正本が複数あると、どれが最新かわからなくなり、破綻する
• 「WordPress管理画面で直接編集」を許すと、次の自動反映で消える事故が起きる
• 正本を1つに固定すれば、自動化スクリプトは常に同じ入力から同じ出力を生む

この原則を徹底したことで、「30本を一括更新しても壊れない」状態が実現しました。

設計思想2：中央管理ファイルを置く

全記事のメタ情報（ID・スラッグ・カテゴリ・タイトル）を、1つの中央管理ファイル に集約しました。新記事を追加するときは、ここに1行足すだけです。

中央管理がもたらすもの

• 関連記事の自動生成は、この中央管理を見て「同カテゴリの記事」を判定
• 内部リンクの整合性チェックも、ここを参照
• 新記事1本の追加が、全記事の関連リンクへ自動波及

「1箇所を更新すれば全体が整合する」状態は、記事が増えるほど価値が増します。

設計思想3：マーカー方式で「場所」と「内容」を分離

アフィリエイトリンクや関連記事ブロックは、記事本文に マーカー（目印）だけを置く 方式にしました。実際のHTMLは、投稿時にマーカーが置換されて生成されます。

マーカー方式の利点

• 記事本文には「ここに○○を入れる」という目印だけ → 本文がシンプルに保たれる
• 登録情報（アフィリエイトURL等）が未設定なら、マーカーは何も出力しない（安全）
• 登録情報を後から追加すれば、マーカーのある全記事へ一斉反映

例えば、あるサービスのアフィリエイト提携が後から承認された場合、登録情報を1箇所更新して一括反映スクリプトを走らせるだけで、そのサービスに言及する全記事にリンクが反映されます。

設計思想4：一括反映を1コマンドに

上記の仕組みを、1コマンドで全記事に反映 できるようにしました。関連記事の再生成・アフィリエイトの展開・内部リンクの整形が、まとめて走ります。

これがなぜ効くか

• 31本目を追加したとき、既存30本の関連記事リストにも自動で反映される
• アフィリエイト提携が増えたとき、該当する全記事へ一斉展開
• デザイン変更（CTAの見た目修正など）も、1コマンドで全記事に波及

「1本の変更が全体に波及する作業」を数十秒に圧縮 したことが、運用負荷を劇的に下げました。

自動化しなかったこと（あえて手動に残した領域）

すべてを自動化したわけではありません。あえて手動に残した ものもあります。

• 記事の最終品質チェック：AI出力の事実確認は人間が行う
• SNSのエンゲージメント：返信・引用は人間が温度感を持って対応
• アフィリエイト商品の選定：読者価値を損なわないよう人間が判断
• 戦略判断：カテゴリ方針・収益戦略は人間が決める

→ 自動化の目的は「人間を不要にすること」ではなく、「人間が判断に集中できるよう、作業を消すこと」 です。

この設計の応用ヒント

同じ考え方は、ブログ・オウンドメディア・ナレッジベースなど、コンテンツが増え続ける運用 すべてに応用できます。

1. 正本を1つに決める（どこを編集すれば正なのかを固定）
2. メタ情報を中央管理する（一覧を1ファイルに）
3. 「場所」と「内容」を分離する（マーカー方式）
4. 一括反映を1コマンドに（変更の波及を自動化）
5. 判断は人間、作業は自動（自動化の線引きを明確に）

まとめ

• メディアは10本を超えると手作業管理が破綻する。仕組みで吸収する
• 設計の核は 正本を1つに固定 すること（編集箇所の一意化）
• 中央管理＋マーカー＋一括反映 で、1本の変更が全体に波及
• すべてを自動化せず、判断は人間に残す 線引きが重要
• この設計思想はコンテンツが増える運用全般に応用できる

WorkPilot 自体が、この設計で運用されています。仕組みで作業を消し、人間は判断と品質に集中する——これが「AIで運営するメディア」の実像です。

この記事でわかること

• Claude Code を使ったメディア運営の1日の実際の流れ
• 記事生成→投稿→SNS→改善 がどうつながるか
• 非エンジニアでも運用が回る理由
• 週1〜2時間の運用を実現する仕組み

「Claude Code でメディアを運営する」と聞いても、具体的に1日どう動くのかはイメージしづらいものです。本記事では、WorkPilot の実際の運用ワークフローを、非エンジニアの視点 で具体的に解説します。

関連記事：Claude Codeは非エンジニアでも使えるのか ／ メディア運営を全自動化したスクリプト設計

前提：運用は「3つのフェーズ」に分かれる

メディア運営は、性質の異なる3つのフェーズに分かれます。

立ち上げが終われば、日々の運用は 公開運用＋改善運用 だけになります。ここが「週1〜2時間で回る」と言われる部分です。

記事を1本追加する日の流れ

実際に新記事を1本追加・公開する日のワークフローは、おおむね以下です。

ステップ1：記事を生成する（10〜20分）

Claude Code に対して、テーマ・キーワード・想定読者を伝え、方針ファイルを前提に記事を生成 させます。方針ファイル（トーン・文字数・禁止事項・内部リンク形式）が整っているため、毎回ゼロから指示する必要はありません。

生成された記事はマークダウンファイルとして保存されます。

ステップ2：人間が品質チェック（10分）

ここは 人間の仕事 です。AI出力には事実関係の誤りや固有名詞の取り違えが残る可能性があるため、以下を確認します。

• 数字・固有名詞・サービス名の正確性
• 断定を避けるべき箇所の表現
• 内部リンクの妥当性

ステップ3：投稿コマンドを1回実行（1分）

確認が済んだら、投稿コマンドを1回実行します。これだけで以下が 自動で 行われます。

• マークダウン→HTMLへの変換
• アイキャッチ画像の自動生成・アップロード
• アフィリエイトリンク・関連記事ブロックの自動展開
• WordPressへの下書き投稿

ステップ4：プレビュー確認して公開（3分）

WordPress でプレビューを確認し、問題なければ公開ボタンを押します。公開と同時に、連携済みSNSへ 自動投稿 されます。

ステップ5：手動SNS投稿（2分）

自動化していないSNSは、事前生成済みのテキストをコピペ して投稿します。ここで一言コメントを添えると反応が伸びやすい、というのは手動運用ならではの利点です。

→ 合計30〜40分。うち人間の判断が必要なのは品質チェックの10分程度です。

週次でやること（15分）

公開運用とは別に、週1回 改善運用 を回します。

1. アクセス解析データをエクスポート
2. 分析スクリプトを実行
3. レポートを見て「あと一歩で上位表示できる記事」を特定
4. その記事を今週リライトする対象に決める

→ データに基づいて「次に何を改善すべきか」が自動で見える状態。ここが、勘ではなくデータで運用できる理由です。

なぜ非エンジニアでも回るのか

このワークフローが非エンジニアでも回る理由は3つあります。

1. 操作の大半が「日本語で指示」

Claude Code への指示は、ほぼ日本語の自然文です。「この記事を投稿して」「関連記事を全部更新して」と書けば、必要な処理が実行されます。コマンドの暗記は不要です。

2. エラーは「貼れば解決する」

詰まったときは、エラーメッセージをそのまま Claude Code に貼り付ければ、原因と次の一手が日本語で返ってきます。「自分で解決する」のではなく「解決させる」発想です。

3. 仕組みが作業を吸収する

アイキャッチ生成・内部リンク・関連記事・アフィリエイトは、立ち上げ時に作った仕組みが自動処理します。記事が増えても、人間の作業量はほぼ一定です。

人間に残る仕事

自動化しても、人間にしかできない仕事 は残ります。むしろ、そこに集中できるのが目的です。

• 戦略判断：どのカテゴリを強化するか、どの収益導線を優先するか
• 品質の最終責任：事実確認、表現の適切さ、読者への誠実さ
• エンゲージメント：SNSでの対話、読者の反応への対応
• 意思決定：外部環境の変化への対応、方針転換の判断

→ 作業から解放された時間を、これらの 判断と対話 に使う。これが「AIで運営する」の本質です。

1日の運用イメージ（まとめると）

記事を追加する日：
  記事生成（AI）→ 品質チェック（人間10分）
  → 投稿コマンド1発（自動）→ 公開（人間3分）
  → SNS発信（自動＋手動コピペ）
  合計：人間の作業 約15分

週次：
  データ確認 → リライト対象決定（15分）
  → 平日にリライト1〜2本（各30〜60分）

月次：
  収益集計・AdSense確認・ASP追加（60分）

→ 立ち上げが終われば、週1〜2時間 で運用が回る計算になります。

まとめ

• メディア運営は「立ち上げ」「公開運用」「改善運用」の3フェーズ
• 記事追加日の人間の作業は 品質チェック中心の約15分
• 週次の改善は データに基づいて自動で見える 仕組み
• 非エンジニアでも回るのは「日本語指示・エラーは貼る・仕組みが吸収」の3点
• 人間に残るのは 戦略・品質・対話・意思決定 という最も重要な部分

WorkPilot は実際にこのワークフローで運用されています。「AIに置き換える」のではなく「作業を消して、人間が判断に集中する」——それが Claude Code でメディアを運営する実像です。

この記事でわかること

• AIメディア立ち上げ期に実際に迷った意思決定の論点
• 各判断の「なぜそうしたか」の理由
• 判断を早くするための考え方
• 同じ局面に立つ人への示唆

メディア運営の解説記事は「正解」を語りますが、実際の立ち上げは 正解が見えない中での連続した意思決定 です。本記事は、WorkPilot の立ち上げ期に実際に迷った論点と、その判断理由を時系列で記録したものです。

「なぜその選択をしたのか」の思考過程こそ、他では読めない一次情報だと考えています。

関連記事：AIメディア運営のリアルな落とし穴5選

論点1：パーマリンク構造をいつ確定させるか

迷い

記事公開を急ぐべきか、URL構造の確定を優先すべきか。URL構造（カテゴリを含むか否か）は、後から変えると 全URLが変わりSEO評価がリセット される。

判断

記事公開から日が浅いうちに /カテゴリ/記事/ 形式へ確定 させた。

理由

• URL変更のSEOリスクは「インデックスが進む前」なら最小
• 記事数が増えてからの変更は損失が大きい
• 「急いで公開」より「正しい構造で公開」を優先すべき初期フェーズだった

→ 結果、変更の損失をほぼゼロに抑えられた。タイミングの見極めが判断の質を決めた 典型例。

論点2：SNS自動化に課金するか

迷い

あるSNSのAPIが従量課金モデルに移行していた。月数百円〜の課金で自動投稿を実装するか、手動運用にするか。

判断

有料API自動化は見送り、投稿テキストは自動生成しつつ投稿は手動 にした。

理由

• 立ち上げ期はフォロワーゼロ。自動投稿の即効性が低い
• 別のSNS（無料で自動化可能なもの）で省力化は十分達成できる
• 初期はむしろ手動投稿＋手動エンゲージメントの方が伸びやすい
• 「自動化できる＝自動化すべき」ではない

→ コストゼロで、戦略的にも妥当な着地。費用対効果が見合わない自動化は見送る勇気 が必要だった。

論点3：見つからないASP案件をどうするか

迷い

紹介したいサービスのアフィリエイト案件が、主要ASPで見つからない。妥協して関連性の低い案件を貼るか、空欄のまま進めるか。

判断

収益期待値の高い案件から順に提携し、見つからないものは無理に貼らない 方針にした。仕組み上、未登録の案件は何も表示されない安全設計にした。

理由

• 関連性の低い広告は読者の信頼を損なう（メディアの長期価値を毀損）
• 全案件を揃える完璧主義より、高単価の数案件が揃えば収益目標には十分
• 「空欄でも自動でスキップ」される設計なら、後から埋めるだけでよい

→ 完璧を目指さず、価値の高い導線から段階的に埋める 現実解。

論点4：記事を一気に公開するか、段階公開か

迷い

30本のドラフトを一気に公開するか、ペースを分けるか。

判断

1日2〜3本ペースの段階公開 を推奨方針にした。

理由

• 1日に数十本の公開は、新着タイムラインで不自然に映る
• 健全なメディアの更新ペースを装う方が、長期的な信頼につながる
• ドラフトとして書き溜めること自体は何の問題もない（むしろ理想的）

→ 「速く出す」ことより「自然に育てる」ことを優先。スピードと自然さのトレードオフ を意識した判断。

論点5：どこまで自動化し、どこを人間に残すか

迷い

作業をすべて自動化すべきか、判断を人間に残すべきか。

判断

作業は自動、判断は人間 という線引きを明確にした。

理由

• 記事の事実確認、商品選定、戦略判断は品質と信頼に直結する
• これらを自動化すると、効率は上がるが メディアの価値が劣化 する
• 自動化の目的は「人間を消すこと」ではなく「人間が判断に集中できること」

→ この線引きが、効率と品質を両立させる土台になった。

意思決定を早くした共通原則

5つの論点に共通する、判断を早めた考え方を抽出すると以下になります。

1. 可逆性で判断する：取り返しがつく判断は速く、つかない判断は慎重に
2. タイミングを見る：同じ判断でも、実行時期で損失が変わる
3. 完璧主義を捨てる：100点の計画より、80点で動いて修正する
4. 費用対効果で線を引く：できることと、やるべきことは違う
5. 長期価値を毀損しない：短期効率のために読者信頼を売らない

まとめ

• 立ち上げは 正解の見えない連続した意思決定 の積み重ね
• URL構造は「インデックス前」に確定（可逆性とタイミング）
• 費用対効果が見合わない自動化は見送る勇気
• 完璧主義より「価値の高い導線から段階的に」
• 作業は自動、判断は人間 の線引きが品質と効率を両立させる

判断の「結果」だけでなく「理由」を記録することが、AIメディア運営の知見として最も価値があると考えています。今後も意思決定のログを残していきます。

この記事でわかること

• AIを主体にメディアを運営する全体像（立ち上げ〜運用）
• WorkPilot 自身の構築・運営の実録記事への地図
• 「AIで運営する」を成功させる原則
• なぜこの過程自体がコンテンツになるのか

WorkPilot は「AIを主体に、人間の作業を最小化して運営するメディア」です。そして、その 運営過程そのものをコンテンツ化 することを差別化の核に据えています。

本記事は、その「AIメディア運営ラボ」カテゴリ全体の入口として、立ち上げから運用までの記録記事への地図を提供します。脚色なし・成果は誇張せず、成功も失敗も正直に記録する方針です。

このページは「総合ガイド」です。各テーマは、リンク先の個別記事で詳しく扱っています。

なぜ「運営過程」がコンテンツになるのか

AI生成記事がインターネット上に溢れる時代、Google も読者も 「実際にやった人の一次体験」 を重視する傾向が強まっています。

• ツール紹介記事は誰でも書ける（差別化困難）
• しかし「AIでメディアを2週間で立ち上げた実際の記録」は、実際にやった人にしか書けない
• 失敗・つまずき・意思決定の理由こそ、他では読めない価値

→ これが WorkPilot の戦略的な堀（E-E-A-T の Experience）です。

全体像：AIメディア運営の3フェーズ

テーマ別：どの記事を読めばいいか

立ち上げの全工程を知りたい

基盤整備から30記事公開まで、2週間の全工程と判断を記録しています。

→ AIで30記事のメディアを2週間で立ち上げた全工程

実際に詰まった話を知りたい

事前情報どおりに進まなかった落とし穴を、脚色せず5つ公開しています。

→ AIメディア運営のリアルな落とし穴5選

自動化の仕組みを知りたい

アイキャッチ・内部リンク・関連記事・アフィリエイトを全自動化した設計思想を解説しています。

→ メディア運営を全自動化したスクリプト設計

意思決定の理由を知りたい

立ち上げ期に迷った論点と、その判断理由を時系列で記録しています。

→ AIメディア立ち上げの意思決定ログ

日々の運用フローを知りたい

非エンジニアが Claude Code でメディアを運営する1日の流れを解説しています。

→ Claude Codeで非エンジニアがメディアを運営する実ワークフロー

Claude Code の基礎を知りたい

そもそも非エンジニアが Claude Code を使えるのか、という前提を扱っています。

→ Claude Codeは非エンジニアでも使えるのか

「AIで運営する」を成功させる原則

これまでの記録から抽出した、共通する原則です。

原則1：作業は自動、判断は人間

自動化の目的は「人間を消すこと」ではなく「人間が判断に集中できるよう作業を消すこと」です。記事の事実確認・戦略判断・読者対話は人間に残します。

原則2：書く前の土台が勝負

記事生成より、方針の言語化・URL構造の確定・自動化基盤の整備に労力の大半がかかります。土台が整えば量産は速い。

原則3：完璧主義より切り替えの速さ

外部サービスの仕様は数ヶ月で変わります。計画の精度より、詰まったときに代替案へ切り替える速さが成否を分けます。

原則4：成果を誇張しない

立ち上げ直後に成果を語るのは誠実ではありません。データとともに正直に記録することが、長期的な信頼の土台になります。

このカテゴリの今後

WorkPilot の運営が続く限り、このカテゴリは更新され続けます。

• 収益が出始めたら、その実数値と要因分析
• リライトの効果検証
• 外部環境の変化への対応記録
• 失敗とそこからの学び

→ 「進行中の実験の記録」であることが、このカテゴリの最大の価値です。

まとめ

• WorkPilot は「AIで運営する過程そのもの」をコンテンツ化する
• これは 実際にやった人にしか書けない 模倣不可能な資産
• 立ち上げ〜運用の全工程を、構築実録・落とし穴・自動化設計・意思決定ログとして記録
• 成功原則は 作業は自動/判断は人間・土台が勝負・切り替えの速さ・成果を誇張しない
• このカテゴリは進行中の実験の記録として更新され続ける

各記事で、AIメディア運営のリアルを成功も失敗も含めて記録しています。ぜひ個別記事もご覧ください。

この記事でわかること

• Claude Codeとは何か、ChatGPTやClaude Webアプリと何が違うのか
• 非エンジニアがClaude Codeを使うとできること・難しいこと
• 実際にAIメディア「WorkPilot」を立ち上げた過程でつまずいたポイント
• 最初の30分で始めるための具体的なステップ

「Claude Code」と聞くと、コマンドラインで動くエンジニア向けツール、という印象を持つ方が多いのではないでしょうか。確かに公式ドキュメントはエンジニア向けの書き方ですが、実は非エンジニアこそ恩恵が大きいツールである可能性が高いと考えられます。

本記事は、ライターと編集者で構成されたチームが、Claude Codeを使って WordPressメディアをほぼゼロから立ち上げた一次体験 をもとに、非エンジニアにとっての現実的な使い方を整理したものです。

Claude Codeとは何か：ChatGPTやClaude Webアプリとの違い

Claude Codeは、Anthropic社が提供する ターミナル上で動くAIアシスタント です。Claude（同社のAIモデル）に対して、対話で指示するだけでなく、ファイルの作成・編集・コマンドの実行まで一気通貫で任せられる ことが最大の特徴です。

大ざっぱな違い

ChatGPTやClaude Webアプリは「会話で答えをもらう」ツールですが、Claude Codeは「会話で作業をしてもらう」ツールに近い、と捉えると分かりやすいかもしれません。

「ターミナル」が壁に見える人へ

Claude Codeはターミナル（黒い画面）で動くため、最初の心理的ハードルが高く見えがちです。ただし、実際の操作の大半は「日本語で指示を書く」だけ です。本記事の後半で、最初の30分の流れを具体的に紹介します。

非エンジニアがClaude Codeを使うとできること

Claude Codeで非エンジニアが恩恵を受けやすい領域は、おおむね以下の3つに整理できます。

1. 反復的なファイル作業の自動化

• マークダウン記事の一括フォーマット変換
• 設定ファイル（.env、.gitignore など）の作成
• 数十ファイルにまたがる一斉置換やリネーム

Excel関数やマクロが「ちょっと手が届かない」と感じている層にとって、自然言語で同等のことを指示できる点は大きな利点とされます。

2. WebサービスやSaaSへの自動操作

API（外部サービスを呼び出す仕組み）を介して、たとえば以下のような連携が可能です。

• WordPressへの記事投稿・カテゴリ作成
• Google スプレッドシートの読み書き
• Slack・Notion・GitHubなどへの情報連携

「APIと聞いただけでアレルギーが出る」方でも、Claude Codeに「この記事をWordPressに下書きで投稿してください」と日本語で指示すれば、必要なスクリプトを生成して実行までしてくれる、という体験が成り立ちます。

3. プロジェクト全体の文脈を保持した支援

Claude Codeは、プロジェクトのフォルダ全体を文脈として読みながら作業します。これにより、ChatGPTで毎回コピペで前提を渡し直す手間が大きく減ります。

特に「CLAUDE.md」と呼ばれる前提ファイルを置いておくと、毎回のセッションで自動的に読み込まれ、トーン・禁止事項・ターゲット読者などの方針を常に守った出力が期待できます。

逆に、非エンジニアが「難しい」と感じやすい点

良いことばかりではありません。一次体験から見えた、現実的なつまずきポイントを共有します。

環境構築の最初の数十分

Claude Code自体のインストールはシンプルですが、Node.js（プログラムを動かす基盤） などの周辺ツールが必要になる場面が出てきます。「ターミナルでコマンドを打ち、エラーメッセージを読む」という作業が、最初の数十分はどうしても発生する可能性があります。

ただし、エラーメッセージをそのままClaude Codeに貼り付ければ、原因と次の一手をほぼ日本語で返してくれるため、「自分で解決する」のではなく「Claudeに解決させる」 という発想に切り替えると一気に楽になります。

「やりたいこと」を言語化するスキル

Claude Codeは万能ではなく、指示が曖昧だと曖昧な結果しか返ってきません。これは従来のAIツールと同様ですが、実作業を伴うぶん、曖昧な指示の影響が大きく出やすい 傾向があります。

対策として、本記事の後半で紹介する「CLAUDE.mdに前提をすべて書く」というアプローチが有効です。

コストの予測がやや読みにくい

API利用料・サブスクリプション料の体系が複数あり、自分の使い方ではどのプランが妥当か、初見で判断するのは難しい面があります。まずは Claude Pro 等の月額固定プランから始め、量産フェーズに入ってから上位プランを検討する 方針が、安全策として現実的と考えられます。

最初の30分で始める具体的ステップ

ここからは、非エンジニアが Claude Code に触れるための、最小構成の手順を紹介します。

ステップ1：Claude Code のインストール

Anthropic公式ドキュメントの手順に沿って、Claude Code（デスクトップアプリまたはCLI）をインストールします。インストール直後は何もする必要はなく、起動して対話画面が出ればOKです。

ステップ2：作業フォルダを決める

デスクトップやドキュメントフォルダの中に、workpilot のような名前の 専用フォルダ を1つ作ります。Claude Code はこのフォルダ全体を文脈として扱うため、プロジェクトごとにフォルダを分ける ことが運用上重要です。

ステップ3：CLAUDE.md を置く

そのフォルダ内に CLAUDE.md というテキストファイルを作り、以下のような前提を書いておきます。

# プロジェクト概要
- どんなサイト・サービスを作っているか
- ターゲット読者は誰か
- 守るべきトーン・文体
- 禁止事項（薬機法・YMYL断定など）

これだけで、毎回のセッションで方針が一貫し、出力の品質が大きく安定します。

ステップ4：最初のお願いをする

最初の指示は、できるだけ 小さく、確認しやすい作業 から始めることを推奨します。たとえば以下のような内容です。

• 「.env ファイルを作ってください。中身は WP_URL=https://example.com の1行だけです」
• 「.gitignore を作って、.env を除外してください」

小さな成功体験を積み重ねてから、徐々に「WordPressに記事を投稿するスクリプトを書いてください」のような複合タスクへステップアップしていく流れが、心理的にも実装的にも安全な進め方とされています。

非エンジニアが Claude Code で実現できる業務イメージ

最後に、実際にどんな業務がClaude Codeで自動化可能か、職種別のイメージを整理します。

いずれも、**「手は動かしたくないが、判断はしたい」**という非エンジニアの典型ニーズと相性が良いとされます。

まとめ

• Claude Codeは「会話で作業をしてもらう」AIツールで、ChatGPTの上位互換ではなく 別の用途のツール と捉えると理解しやすい
• 非エンジニアでも、反復作業の自動化／SaaS連携／プロジェクト文脈を踏まえた支援 で恩恵を受けやすい
• 最初の壁は環境構築だが、エラーメッセージごとClaudeに貼って解決してもらう発想で乗り越えられる可能性が高い
• まずは 専用フォルダを作り、CLAUDE.mdに前提を書き、小さなタスクから始める 進め方が安全
• 当メディア WorkPilot 自体もClaude Codeで運営されており、今後その過程を「AIメディア運営ラボ」カテゴリで継続発信していく予定です