GAS×Gemini APIで構築した「嘘をつかない」完全自律型SEOブログの全記録（月間100万PVへの挑戦）

はじめに：なぜ今、枯れた技術（GAS）でAI自動化システムを作ったのか？

トレンドのAIエージェント（Claude, Dify, Cursor等）が抱える罠とコスト問題

現在、X（旧Twitter）などのSNSを開けば、「Difyで完全自動化ブログを作った！」「ClaudeのComputer UseでPC操作を無人化！」といった景気の良い発信が溢れています。これらを見ると、まるで誰でも明日から簡単にAIの自動化工場を持てるように錯覚してしまいます。

しかし、いざ「月間100万PVを目指す商用レベル」のシステムを24時間365日、無人で安定稼働させようとすると、途端に分厚い壁が立ちはだかります。それが「環境構築の複雑さ（保守の地獄）」と「膨大なランニングコスト（固定費の重圧）」です。

1. 「環境構築の複雑さ」という罠：保守地獄のリアル

最新のAIエージェントフレームワーク（LangChainやDifyなど）を自分のPC上で少し動かすだけなら簡単です。しかし、私がやりたいのは「深夜3時にAIが勝手に起き出してブログを編集する」ことでした。 これを実現するためには、PCの電源を切っても動き続ける「クラウドサーバー（AWSやGCPなど）」を自前で契約し、構築しなければなりません。

具体的には、以下のような現象（地獄）に直面します。

• DockerやLinuxの壁： 「サーバーに環境をデプロイするだけで週末が潰れる」。黒い画面（ターミナル）と睨み合い、謎のネットワークエラーやメモリ不足によるサーバーダウン（Out of Memory）と戦う日々が始まります。

• バージョン依存関係の崩壊（依存地獄）： Pythonなどのプログラムは進化が早すぎます。ある日突然、裏側で使っているライブラリがアップデートされただけで、「昨日まで動いていたシステムが突然謎のエラーを吐いて全停止する」という現象が頻発します。

• データベース運用の重圧： AIが「過去にどんな記事を書いたか」を記憶させるために、ベクトルデータベース（Pineconeなど）やPostgreSQLを構築・保守する手間が発生します。

つまり、ブログの戦略を考える前に「インフラエンジニアとしての過酷な保守作業」に忙殺され、本来の目的を見失ってしまうのです。

2. 「膨大なランニングコスト」の罠：毎月3万円が消えていく現実

さらに重くのしかかるのが「お金」の問題です。 「AI APIは1トークン数円だから安い」というのは、人間が手動でたまに質問する時の話です。私が構築したシステムのように、「毎日数十件のキーワードを調べ、アドバイザーと相談し、30本の記事を書き、週末に統合して内部リンクを貼る」という絶え間ないループ（自律稼働）をさせると、APIの通信量は文字通り”桁違い”に膨れ上がります。

もしこれを、AWSサーバーと高性能なAIモデル（GPT-4oやClaude 3.5 Sonnetなど）の組み合わせで構築した場合、具体的に以下のようなコストが毎月かかり続けます。

• クラウドサーバー維持費（AWS EC2 + データベース等）： 月額 約5,000円〜10,000円

• 自律エージェントのAPI通信費（高頻度ループ）： 月額 約10,000円〜15,000円（※企画・相談・執筆・推敲・リライトの全工程を高品質モデルで回した場合）

• 外部ツール費用（有償のベクトルDBなど）： 月額 約5,000円

合計すると、「システムを息させているだけで、毎月2万〜3万円（年間約30万円以上）」という莫大な固定費が飛んでいきます。 ブログは立ち上げてから数ヶ月〜半年は収益がほぼゼロ（砂漠の時代）です。まだ1円も稼いでいないブログのために、毎月3万円の赤字を垂れ流し続けるプレッシャーに、大半の個人やスモールチームは耐えきれずにシステムを停止してしまいます。

サーバーレス＆ランニングコストほぼゼロ。GAS×Geminiの圧倒的コスパに気づいた瞬間

こうした「複雑さ」と「コスト」の壁に絶望しかけていた時、私が目をつけたのが、Googleが無償で提供しているGoogle Apps Script（GAS）でした。

GASは長年「スプレッドシートのマクロ」程度の認識をされがちですが、実はこれ、「Googleが保守管理を全てやってくれる、無料で使える24時間稼働のサーバーレス環境」なのです。Dockerの構築も、サーバー落ちの心配も、面倒なアップデート保守も一切不要。コードをコピペして「毎日朝8時に動かせ」と画面上で設定するだけで、完璧なインフラが手に入ります。

さらに、ここにGemini API（Flashモデル）を組み合わせた瞬間、点と点が繋がりました。GeminiのFlashモデルは異常なほど処理が軽く、大量の文字数を処理させてもコストは他社モデルの数分の一（月に数百円〜千円いくかどうか）です。 つまり、インフラ保守ゼロ、サーバー代ゼロ、API代は缶ジュース数本分。「毎月3万円かかる自律型コンテンツ工場を、実質ほぼ無料のランニングコストで稼働させるアーキテクチャ」がここに完成したのです。

本記事の目的（クローズドな環境だからこそ語れる、失敗と成功のリアルな裏側）

本記事は、このシステムをそのまま実践すれば誰でも強力な自律型メディアを持ててしまうため、あえて高価格のドキュメントとして公開します。単なる表面的な成功譚で終わらせるつもりはありません。

このシステムが今の「完全体」に至るまでには、AIがもっともらしい嘘（ハルシネーション）を吐き続けたり、WordPressのデータベースがバグを起こして記事が吹っ飛んだりと、泥臭い失敗と絶望の連続でした。

ここでは、私がどのようにしてAI特有の壁を突破し、SEOという冷酷な戦場で勝てるアーキテクチャに行き着いたのか。その思考のプロセスと「技術的なブレイクスルーの瞬間」や、実際にAIエージェントを「何時に何をさせているのか」を包み隠さず共有します。

第1章：AIブログ最大の壁「もっともらしい嘘（ハルシネーション）」との直面

「機械設計」という専門領域において、AIの知ったかぶりが致命傷になる理由

AIを使ってブログを書かせようとした初期、私が直面した最大の絶望は「記事の品質」でした。 私がターゲットとしているのは「機械設計」という極めて専門的でシビアな領域です。読者は現場で汗を流す現役のエンジニアであり、彼らが求めているのは「ボールねじの危険回転数の算出方法」や「サーボモーターの負荷イナーシャ比の適正値」といった、実務に直結する正確なノウハウです。

もしここで、AIが適当な計算式をでっち上げたり、物理法則を無視したパラメータを提示したりすればどうなるか。

読者は一瞬で「この記事は使い物にならない」と見切りをつけ、サイトの信頼は地に落ちます。Googleのアルゴリズム以前に、専門領域において「AIの知ったかぶり（ハルシネーション）」はサイトにとって致命傷なのです。

従来の「プロンプトエンジニアリング」だけでは品質が担保できない限界

当初、私はプロンプト（AIへの指示書）を必死にこねくり回していました。 「あなたは熟練の機械設計エンジニアです。正確な推力計算を行い、それを分かりやすくSEOに強い構成でブログ記事にしてください」 このように、ペルソナを与えて詳細なルールを書き込めば、AIは言うことを聞いてくれると信じていました。

しかし、結果は惨憺たるものでした。なぜAIはもっともらしい嘘をつくのか？ 例えば、画像生成AIが『噛み合わないデタラメな歯車』を描いてしまう現象を見たことがないでしょうか。実は、テキストAIのハルシネーションの根本的な原因もこれと全く同じなのです。

なぜ画像AIは「噛み合わない歯車」を描くのか？

• 物理モデル（構造）を理解していない: 画像AIは「歯車の形（ギザギザした丸）」は知っていますが、「歯が噛み合って交互に回転する」という運動学を知りません。これは、テキストAIが「足し算の記号（＋）」を知っていても、自前で計算プロセスを持たない限りデタラメな答えを出してしまうのと同じです。

• 表面的なピクセルの「確率配置」にすぎない: 画像AIは頭の中で3D CADを組み立ててから撮影しているわけではありません。「金属の筒（モーター）の隣には、ボルトの頭や謎の配線が描かれている確率が高い」という統計データに基づき、2Dキャンバス上にそれっぽいピクセル（テクスチャ）を貼り付けているだけです。

• 「もっともらしさ」への過剰適応: AIは「パッと見でそれっぽく見えること」に最適化されています。そのため、配管の行き先が壁に埋まっていようが、ボルトを回すための工具が入る隙間がなかろうが、AI自身はその機能的矛盾に気づくことができません。

出力される記事は、一見すると綺麗にまとまっているものの、肝心の計算式が間違っていたり、どこかの教科書から引っ張ってきたような薄っぺらい一般論の羅列だったりしたのです。実務で直面する「泥臭いトラブルシューティング」の熱量が全く感じられませんでした。

「専門的な計算」と「SEOライティング」を1つのAIに同時に求めることの危険性

なぜプロンプトを工夫してもダメなのか。エラーの原因を分析するうちに、私は生成AIの構造的な弱点に気づきました。

それは、「1回のAPIコール（1つのAI）に対して、『高度な論理的思考（計算・評価）』と『文脈の最適化（SEOライティング）』という2つの重いタスクを同時に処理させようとしている」ことでした。

人間でも同じです。「この複雑な構造計算を解いて、同時にそれをバズるWeb記事風に編集して」と頼まれれば、どちらかが疎かになります。

AIもまた、見出しの構成やHTMLタグの配置、SEOキーワードの散りばめ方にリソースを割かれるあまり、肝心の「物理計算の正確性」を維持できなくなっていたのです。

第2章：最大の技術的ブレイクスルー「アドバイザーAI」の分離アーキテクチャ

脳みそ（論理・計算）と手（清書・執筆）を完全に分けるという発想の転換

「1人のスーパーマン（単一のAI）に全てをやらせるから破綻するのだ」 そう気づいた私は、システムの設計思想を根本から覆しました。

システム開発の世界で言う「マイクロサービス化」のアプローチです。

ブログを書くという工程を、「脳みそ（技術的な答えを出す）」と「手（記事として清書する）」の2つの完全に独立したAIエージェントに分離することにしました。