AIだけでWebサイトを0から作る手順｜非エンジニアが16日で165記事を公開した実録

結論：AIだけで作れる範囲と、人が必ず要る範囲

最初に結論を出します。0からサイトを作る全工程のうち、AIに任せきりにできる工程と、人が判断しないと破綻する工程は明確に分かれます。

工程	AIだけで完結するか	人が関与する内容
サーバー・ドメインの契約	できない	契約と支払い、管理画面の認証情報の取得
サイトの土台の実装（テーマ・テンプレート）	できる	方針の指示のみ。実装・デプロイはAI
記事の執筆	おおむねできる	テーマ選定と、事実の裏取り
固有名詞・数値・価格の記載	できない	公式の一次情報で全件確認
大量ページの検査・一括修正	できる	検査条件の指定のみ
公開の可否判断	できない	掲載責任は運営者にある
インデックス申請・計測	できる	APIの利用登録

つまり「作る」はAIに渡せますが、「事実であることを保証する」は渡せません。この記事の手順も、その前提で組み立てています。

16日間で実際にできたこと

手順を読む前に、この方法でどこまで到達できるかの目安を示します。すべて実測値です。

項目	実測値
期間	2026年7月11日〜7月26日（16日間）
体制	運営者1名（非エンジニア）＋ AIエージェント
公開した記事	165本（総文字数1,290,338字／1本平均7,820字）
人が出した指示	415回
AIが行った実操作	2,739回（指示1回あたり約6.6回）
並列で動いたサブエージェント	のべ172体
作られた運用ツール	Pythonスクリプト25本以上
インデックス登録率	65.5%→81.5%（7月20日→24日）
外部サービスへの追加支払い	0円（AI利用料と既存サーバー費を除く）

注目してほしいのは「指示1回あたり6.6回の実操作」という倍率です。人間は415回しか喋っていないのに、ファイル編集・コマンド実行・API呼び出しは2,739回発生しています。これがAI活用の生産性の正体であり、同時に曖昧な指示1回が6回分の間違った作業に化けるということでもあります。

ステップ0：着手前に決める3つのこと

いきなり「サイトを作って」と言い始めると、ほぼ確実に詰まります。実際の作業ログでも、初日は記事制作ではなく環境の取り決めに費やされています。決めるのは次の3つです。

①AIに触らせてよい範囲を決める

AIエージェントは既定ではファイル編集やコマンド実行のたびに承認を求めます。安全ですが、1日に数百回の操作をする運用では止まってばかりになります。かといって全面的に許可すると、想定外の場所を書き換えられます。

実際に採用したのは「自分の作業フォルダと設定フォルダの中は確認なしで編集してよい。それ以外を触るときは必ず確認する」という線引きです。この一文を最初に決めるかどうかで、以降の速度がまったく変わります。

②成果物の置き場所を1か所に固定する

AIは指示しないと作業ファイルをあちこちに作ります。数日で人間側が全体を把握できなくなるので、「成果物は必ずこのフォルダに置く」と決めてしまうのが安全です。あわせて、AIが出力したファイルは絶対パスで報告させるようにすると、探す時間がなくなります。

③認証情報の渡し方を決める

サーバーのFTP、WordPressのログイン、Google APIのキー。これらを毎回チャットに貼り付ける運用は続きません（そして貼った時点で漏洩リスクになります）。

この事例では認証情報を平文の設定ファイルに置き、スクリプトが自動で読む方式にしました。ファイルはバージョン管理から除外します。実務上はこれで摩擦がほぼゼロになりました。なお、途中でパスワードをチャットに貼ってしまった場面があり、その分は再発行しています。一度でも会話に流したものは無効化して作り直すのが原則です。

ステップ1：サイトの土台を用意する

WordPressか、静的サイトか

このサイトは当初、外注で作られた静的サイト（Next.js）とWordPressが同居した二重構造でした。最終的にはWordPressに一本化しています。理由は単純で、AIに運用させるならWordPressのほうが圧倒的に扱いやすいからです。

• REST APIで記事の作成・更新・公開・削除がすべて自動化できる
• 投稿タイプやカテゴリの追加が、テーマやプラグインの数十行で済む
• SEO系プラグインの設定もAPIやDB経由で操作できる

静的サイトでもAIは作れますが、「記事を1本追加する」たびにビルドとデプロイが必要になり、非エンジニアが運用を引き取りにくくなります。日々更新するメディアなら、CMSを土台にするほうが現実的です。

テーマは人が触らず、AIに直接編集させる

この事例では、テーマのPHPファイルはすべてAIがFTP経由で直接編集しています。人間がやったのはFTPの接続情報を一度渡しただけです。ヘッダーの改修、パンくずの構造化データ追加、記事一覧の並び順変更、投稿タイプの追加まで、すべてこの方式で処理しました。

ここで必ずやるべきなのが「編集前のファイルを必ずバックアップさせる」ことです。テーマのPHPは1文字間違えるとサイト全体が真っ白になります。この事例では、編集前にダウンロードして保管し、反映後にサイトの応答を確認する手順を毎回踏んでいます。

URL構造は最初に決める

最大の手戻りはURL構造の変更でした。メディアを/blog/配下からサイトのルートへ移す改修を途中で行ったため、全記事のURLが変わり、301リダイレクトの設定、内部リンクの一斉修正、サイトマップの再送信、インデックスの再申請が必要になりました。

後から変えると必ずこの作業が発生します。着手時に「記事は/<スラッグ>/」「ニュースは/news/<スラッグ>/」のように決めておくだけで、この工数はまるごと不要になります。

ステップ2：AIへの指示を設計する

415回の指示を振り返ると、手戻りが起きた指示と一発で通った指示にははっきりした差がありました。ここがAI制作でいちばん再現性のあるノウハウです。

手戻りが起きる指示

「いい感じにして」「整えて」のような評価基準の入っていない指示は、ほぼ確実に作り直しになりました。AIは必ず何らかの解釈を選び、実装まで走り切ってしまうためです。損失は指示1回分ではなく、その裏で走った数回分の実作業です。

一発で通る指示

精度が高かったのは禁止事項と完了条件が書かれた指示です。実例として、実在企業を紹介する記事群では「未確認の項目はゼロにする。確認できない項目は掲載しない。所在地が確認できた会社には地図を入れる」という形で、やらないことを先に決めた指示を出しています。この指示で作られた記事群は、後の全数検査でも大きな破綻が出ていません。

実務で効いたパターンは3つです。

• 参考物を渡す：「このページと同じ挙動で」と既存URLやスクリーンショットを渡す。言葉で説明するより精度が上がる
• 禁止事項を書く：「推測で埋めない」「他カテゴリの記事を混ぜない」など、越えてはいけない線を明示する
• 完了条件を検査可能にする：「全ページで該当0件になったら完了」のように、機械で判定できる形にする

毎回言わずに済むよう、ルールはファイルに書く

同じ注意を毎回口頭で言うのは非効率で、しかも言い忘れた回に事故が起きます。守らせたいルールは設定ファイルに書き、AIが毎回自動で読む状態にしておきます。

この事例で恒久ルールとしてファイルに書いているのは、たとえば次のようなものです。

• 公開する本文にMarkdown記法を残さず、必ずHTMLに変換する（見た目の破綻とAI生成らしさの両方を防ぐ）
• 関連記事や内部リンクは同一カテゴリ内で完結させ、件数が足りなくても他カテゴリで埋めない
• 成果物のパスは必ず絶対パスで報告する
• 外部の一次情報は公式ドメインで確認し、確認できないものは書かない

ルールは一度に完成しません。事故が起きるたびに1行ずつ追記していくのが現実的な運用です。この記事に出てくる失敗は、ほぼすべてが後からルールとしてファイルに書き足されています。

判断が割れるところは、AIに選択肢を出させる

実測で69回、AIのほうから「この判断はあなたがしてください」と選択肢を提示させています。曖昧な指示のままAIが独自解釈で突き進むより、この確認1回のほうがはるかに安く済みます。「迷ったら質問して」と最初に言っておくだけで実現できます。

ステップ3：記事を量産する

1本ずつ書かせない

記事は1本ずつ順番に書かせるのではなく、複数のエージェントに同時に書かせます。最も集中した日は1日でツール実行1,241回、全体の45%がこの1日に発生しました。人間の指示はその日102回です。

記事のフォーマットを先に固定する

量産の前に必ずやるべきなのが入稿フォーマットの固定です。この事例では、1本のHTMLファイルの先頭にタイトル・スラッグ・カテゴリ・抜粋をコメントで書き、本文を決まった目印で囲む形式に統一しました。

形式を決めておくと、次の3つが同時に手に入ります。

• 複数のエージェントが書いても出力の形がぶれない
• 投稿ツールがファイルを読むだけでタイトルもカテゴリも自動で入る（人がWordPressの管理画面に触らなくてよい）
• 後から機械検査ができる（見出しの構成、表の有無、リンク切れなどを一括で確認できる）

逆にフォーマットを決めずに書かせると、記事ごとに構成も見出しの粒度もばらばらになり、修正が全部手作業になります。量産の速度を決めるのは執筆スピードではなく、後工程を自動化できる形で出力させられるかどうかです。

同時に走らせる数には上限がある

地域別の記事21本を作ったとき、21体のエージェントを一度に起動して17体が停止しました。処理の上限に達したためです。各エージェントは執筆完了後に落ちたためファイル自体は残っていましたが、報告が返らないので状況把握に余計な時間がかかりました。

その後の運用で安定したのは3〜9体ずつのバッチです。改修作業でも10体で同じ現象が起きたため、並列数は10未満を上限にしています。「速く終わらせたいから全部同時に」は逆効果です。

手順が決まっている作業はスクリプトにする

「全記事のこの位置にこのHTMLを挿入する」のように判断が要らない作業は、エージェントに任せるより、AIにスクリプトを書かせて一括処理したほうが速く、確実で、安く済みます。

この事例で作られた運用ツールと実行回数を見ると、その効果がはっきり出ています。

ツール	役割	実行回数
FTP操作	サーバー構造の確認、テーマファイルの取得	64回
FTPアップロード	テーマの反映（サイズ照合つき）	24回
本文検証	書き換え後の記事が意図どおりかの機械チェック	22回
記事更新	公開済み記事の本文差し替え	17回
記事投稿	下書き作成（タイトル・カテゴリ・抜粋を自動抽出）	15回
インデックス申請	APIへのURL送信	14回
Search Console連携	URL検査・サイトマップ操作	13回

実行回数がそのまま再利用回数です。1回きりの作業ならAIに直接やらせ、2回以上やる作業はツールにする。この線引きがコストと事故率を同時に下げます。

ステップ4：AIが書いた事実を検証する

ここが本題です。AIは事実を捏造します。しかも、もっともらしい形式で捏造します。

実際に起きた捏造

実在企業を紹介する記事を書かせたとき、ある企業の料金プラン3種類がまるごと架空で生成されました。公式サイトに料金の記載がない企業だったにもかかわらず、相場から逆算したと思われる金額表が作られていたのです。同じ検査で、設立年の誤り、公式サイトに存在しない認定の記載、ガイドライン違反と受け取られかねない施策を実在企業の手法として書いた記述など、合計6件の問題が見つかりました。

これは「AIの精度が低い」という話ではありません。表を埋めろと指示されたAIは、埋まらないセルを空欄にするより、それらしい値を入れる方向に働くということです。検証工程を挟まずに公開していれば、実在企業に関する虚偽情報を掲載していたことになります。

検証させたAIも間違える

対策として別のエージェントに検証させましたが、検証側も誤りました。正しい設立年を「誤りだ」と指摘したり、製品サイト側に載っている料金を見落として「記載なし」と判定したりしています。AIの出力をAIに検査させる二段構えは有効ですが、それだけでは足りません。

結果として定めた4つのルール

1. 企業の所在地・料金・実績は、必ずその会社の公式ドメインで裏取りする。まとめサイトを根拠にしない
2. 確認できない項目は「公式サイトに記載なし」と書き、数を揃えるために推測で埋めない
3. 企業の自社公表値は「同社公表」と明示し、第三者が検証した事実と区別する
4. AIの指摘を反映する前に、その指摘自体を人間が一次情報で確認する

実測では、この16日間で外部サイトへのアクセスが101回・37ドメインに対して発生しています。その多くがこの裏取り工程です。AIで記事を量産するとき、実際にコストがかかるのは執筆ではなく検証だと考えたほうが現実に合います。

公開後は「全数」を機械検査する

目視のサンプルチェックでは、生成物に共通するパターンの不具合を見逃します。実例を挙げます。

地域別記事に埋め込んだ地図218個のうち、8記事で地図が1つだけ本来のセクションを飛び越え、次の見出しの下に配置されていました。運営者が1記事を見て気づいた時点では、それが1本だけの問題なのか全記事の問題なのかは分かりません。

このとき採った方法は、各地図のタイトル属性と直前の見出しの企業名を突き合わせ、一致しないものを抽出するスクリプトを書くことでした。21記事218個を数秒で検査でき、該当8件を特定して一括修正、修正後に同じ検査を再実行して0件を確認しています。

AIで大量生成したものは、AIで全数検査する。「1つ見つかったら、同じものが他にもある」と考えて全件を機械的に確かめるのが基本動作です。

ステップ5：公開してインデックスさせる

作っただけでは検索結果に出ません。この事例では、公開のたびに次を自動で回しています。

1. 記事を公開する（APIから状態を変更）
2. サイトマップに載っているかを確認する
3. インデックス申請のAPIにURLを送る
4. 数日後にURL検査APIで登録状況を取得し、前回との差分を出す

実測の推移は次のとおりです。記事を追加しながらの計測なので母数が増えていますが、登録率は改善しています。

日付	検査URL数	登録済み	登録率
7月20日	110	72	65.5%
7月21日	111	87	78.4%
7月23日	124	88	71.0%
7月24日	124	101	81.5%

7月23日に率が下がっているのは、新規記事を追加した直後で「検出済み – 未登録」の状態が増えたためです。公開直後の未登録は異常ではありません。重要なのは、この推移を毎回同じ方法で記録し、下がったときに原因を特定できる状態にしておくことです。

つまずきポイントと回避策

つまずき	何が起きるか	回避策
承認のたびに作業が止まる	数百回の操作が進まない	触ってよい範囲を最初に明文化する
環境依存のエラー	文字化け、シェルの構文差、パスの表記ゆれ	記事制作より先に環境を固める（実測でエラー79件の大半がこれ）
並列の上限	同時起動しすぎて大量に停止する	3〜9体のバッチに分ける
曖昧な指示	作り直しになる	禁止事項と完了条件を書く
事実の捏造	虚偽情報の公開につながる	固有名詞・数値は公式ドメインで全件裏取り
URL構造の後変更	301・内部リンク・再申請が芋づる式に発生	着手時にURLの形を決める
関連記事に無関係な記事が並ぶ	回遊が成立しない	「足りないなら埋めずに非表示」と明示する

費用：どこまで無料でやれるか

この16日間で新たに発生した外部サービスへの支払いは0円です（AIの利用料と、もともと契約していたレンタルサーバー代を除く）。具体的には次の方針で回しています。

• ニュースの収集は有料APIではなくRSS＋無料の実行環境で自動化する
• 地図の埋め込みはAPIキー不要の方式を使う
• 検索パフォーマンスやインデックス状況は、無料のGoogle公式APIの範囲で取得する
• 順位計測や競合分析のような継続的なデータ取得だけは、必要になった時点で有料ツールを検討する

AIを使うと、これまで有料ツールで代替していた定型作業（投稿、リンク検査、インデックス申請、レポート化）を自作スクリプトに置き換えられます。逆に、他社のデータを継続的に買う必要がある領域は自作では埋まりません。ここが有料ツールを使うかどうかの分かれ目です。

これから0から作る人のチェックリスト

1. AIに触らせてよい範囲を明文化する（フォルダ単位で決める）
2. 成果物の置き場所を1か所に固定し、絶対パスで報告させる
3. 認証情報は設定ファイルに置き、バージョン管理から除外する。会話に貼ったものは再発行する
4. URL構造を着手時に決める（後から変えると全工程に波及する）
5. テーマやテンプレートの編集前にバックアップを取らせる
6. 指示には禁止事項と完了条件を書く。「いい感じに」は使わない
7. 並列は10体未満。速さを求めて同時起動を増やさない
8. 2回以上やる作業はスクリプトにさせる
9. 固有名詞・数値・価格は公式ドメインで全件裏取りする
10. 公開後は全数を機械検査する。1件見つかったら同じ不具合が他にもあると考える

よくある質問

本当にコードを書かずにサイトを作れますか

作れます。この事例では運営者はコードを1行も書いていません。ただし「何をしたのか説明させ、納得できなければ止める」判断は必要です。完全に任せきりにすると、事実の捏造やURL構造の破壊に気づけません。読めなくてもよいので、報告を読んで違和感を拾う役割は残ります。

プログラミングの知識はどのくらい必要ですか

不要ですが、「何が起きたら危険か」の感覚はあったほうがよいです。具体的には、URLが変わる変更、公開状態を変える操作、外部に情報を送る操作の3つは、実行前に必ず内容を説明させてください。この3つ以外は失敗しても戻せます。

AIが書いた記事をそのまま公開してよいですか

推奨しません。この事例では実在企業の料金プランが架空で生成される事故が起きています。少なくとも固有名詞・数値・引用元の3点は、公式の一次情報で確認してから公開してください。

どのくらいの期間でサイトが形になりますか

この事例では、土台の整備に約1週間、記事量産と改修に約1週間でした。ただしボトルネックは執筆ではなく検証です。本数を追う場合は、検証をどこまで自動化できるかが実質的な上限を決めます。

WordPress以外でも同じ手順は使えますか

基本の流れ（権限の線引き、指示設計、並列の上限、全数検査）はそのまま使えます。ただし更新のたびにビルドとデプロイが必要な構成は、非エンジニアが運用を引き取りにくい点に注意してください。日々更新するメディアであれば、APIで記事を操作できるCMSを土台にするほうが現実的です。

まとめ

コードを書けない人間でも、AIエージェントに指示を出すだけで16日間で165本の記事と、それを運用する25本以上のツールを持つサイトを作れました。人間が出した指示は415回、その裏でAIは2,739回の実操作を行っています。

一方で、AIは実在企業の料金を捏造し、21体の同時起動は上限に当たって全滅し、公開後の記事には同じ形の配置ミスが8件残っていました。AIでサイトを作るというのは「作らせること」ではなく「検査し続けること」に近いというのが16日間の実感です。

これから始めるなら、上のチェックリストのうち少なくとも「触らせる範囲の明文化」「URL構造の先決め」「一次情報での裏取り」「公開後の全数検査」の4つを先に用意してください。この4つがあるだけで、この記事に書いた失敗のほとんどは回避できます。