2026年4月の終わり、僕は仕事帰りの電車の中で「自分のメディアを持ちたい」と思った。きっかけは大したことじゃない。スマホで読んでいたAIニュースの粒度がどれもバラバラで、しかも「ご存知の通り」と「驚愕」のあいだを行ったり来たりするだけの、薄い記事ばかり目にしたからだ。これだったら自分で書けるかもしれない、と思った。同時に、自分一人で毎日5本書く時間はとてもじゃないがないこともわかっていた。だからAIに書かせる。それが aigeek.biz という個人AIニュースサイトの出発点になった。
2026年4月29日にドメインを買い、5月20日時点で投稿数は累計130本を超えた。半自動パイプラインで、毎朝7時に5本のニュース記事と1本の文学系エッセイが自動公開される。読者数はまだ少ない。ただ、仕組みは動いている。
この記事は、その最初の3週間で何を作り、何で転び、何を学んだかを、できる限り正直に記録したものだ。完璧な成功談ではない。むしろ失敗のほうが多い。それでも書くのは、「これからAIで個人メディアをやってみたい」と考えている人に、リアルな地図を渡したいからだ。地図というのは、目的地までの最短ルートを教えるためのものではなく、「ここで道に迷う人が多い」ということを示すためのものだ。
始める前の3つの選択
最初に悩んだのは「何を作るか」ではなく、「どこに、どう作るか」だった。三つの選択を順に書く。
選択1: ドメインは .biz
ドメインは数十円〜数千円の差に見えて、実はメディアの方向性を決める大きな選択だ。.com は汎用的すぎるし、すでに良いものは取り尽くされている。.jp は信頼感があるが価格が高く、個人のお試し用には重い。.biz は「ビジネス向け」という含意があり、AIというテーマとも親和性が高い。それに、Value Domain で年額500円ちょっとで取れた。正直なところ、最後の理由が一番効いた。
選択2: WordPress を選んだ
「いまどきWordPress?」と思う人もいるかもしれない。Headless CMS(Contentful, Strapi)や Astro+Markdown のような静的サイトジェネレーターも候補だった。Next.js + Sanity の組み合わせも検討した。だが個人メディアという観点では、まだ WordPress が最も合理的だと判断した。理由は三つある。
- REST API が完全に整備されている。Claude Code から
/wp-json/wp/v2/postsに POST するだけで記事が公開できる。認証は cookie + nonce で十分。 - テーマとプラグインのエコシステム。ゼロからフロントエンドを書く必要がない。OGP・SEO・サイトマップは既存資産で 9 割埋まる。
- Claude が知っているドキュメント量が桁違い。テーマファイルの functions.php を Claude Code に読ませて修正させるのが、Astro や Next.js より遥かに精度が高い。これは想定外の発見だった。
「速さ・拡張性・安定性」のうち、個人メディアに必要なのは安定性と「Claudeとの相性」で、結果としてWordPressが最適だった。
選択3: ニュース+エッセイの二本立て
コンセプトを「AIニュースサイト」に絞ったのは、もう少し迷った末の結論だ。当初は「AIツール比較サイト」や「AIエッセイ集」も候補にあった。比較サイトは情報の鮮度維持コストが高すぎて一人では回せない。エッセイ集は「読まれる入口」を作りにくい。ニュースサイトには明確な強みがある。毎日コンテンツが生まれ、定期的な更新が必然化される。AI が得意なことの一つは「情報の取り込みと再構成」だ。ニュース記事なら、その能力を最大限に活かせる。
ただし、ニュース一本では「読み返したくなる記事」が生まれにくい。そこで、エッセイ枠を併設することにした。ニュースは HALBo という AI 編集者が書き、エッセイは ハルキ という AI エッセイストが書く。一方は事実を正確に伝える役、もう一方は余白と解釈を深める役。この二本立てが、ニュースサイトの平板さを救ってくれている。
HALBo と ハルキ ── 二人のAI編集者を設計する
記事を書かせるためには、ただ「ニュース記事を書いて」と言うだけでは足りない。AI には人格が必要だ、と感じた。正確には「人格」というより「一貫した視点と判断基準」と言うべきかもしれないが、実質的には同じことだ。文体・禁止表現・倫理基準・出力フォーマットを全部詰め込んだ「キャラクター」を作る。それが結果的にプロンプトの質を上げる、というのが3週間で得た最大の発見だ。
HALBo(ハルボ)の設計
名前は HAL(『2001年宇宙の旅』の HAL-9000 から)と、「ボ」の音感を組み合わせた。設定はこうだ。
TechCrunch・MIT Technology Review・Wired・The Verge の編集方針を熟知したプロAIジャーナリスト。読者は一般ビジネスパーソン。専門知識は不要で、ビジネスへの影響を重視する。文体は能動態優先、一文一義、結論ファースト。「近年、〜が注目されている」「ご存知の通り」「驚愕」などの表現は禁止。
これだけだと足りない。実際のシステムプロンプトは、3週間の改善を経て約10,000字になっている。タイトルパターンの禁止リスト、ベンチマーク文脈の明記ルール、文構造の厳守(「〜は」で始まる文は対応する述語で閉じる)、人物引用の出典必須ルール、数字の日本語化(1 million → 100万、1 billion → 10億)、ハルシネーション警戒則(詳しそうに見える記述ほど危ない)など、個別の事故を踏むたびにルールが追加されてきた。
イメージしやすいよう、HALBo のシステムプロンプトの抜粋を載せる(実際はこの10倍以上の分量がある)。
# あなたは HALBo(ハルボ)
TechCrunch / MIT Technology Review / Wired / The Verge の
編集方針を熟知したプロAIジャーナリスト。
## 文体ルール(厳守)
- 能動態を優先。一文一義。結論ファースト。
- 「〜は」で始めた文は、対応する述語で必ず閉じる。
- 数字は日本語化する: 1 million → 100万 / 1 billion → 10億
* 「250百万」「3.5億ドル」のような表記は禁止。
## 禁止表現
- 「近年、〜が注目されている」
- 「ご存知の通り」「驚愕」「衝撃」「〜と話題」
- バージョン番号の推測(例: GPT-5.4 など未確認のもの)
## ハルシネーション対策
- 一次情報URLで確認できない固有名詞・数字・日付は
fact_warnings 配列に必ず記録すること。
- 「詳しそうに見える記述ほど危ない」と心得る。
このプロンプトの全文と、ルールが追加された具体的事故の対応関係(どの記事のどんなミスから、どのルールが生まれたか)は、note の有料記事に収録している。プロンプト自体は CC BY 4.0 で再利用可能にする予定だ。
ハルキ(村上春樹に影響を受けた架空のエッセイスト)
こちらはニュースとは正反対の役回り。一人称「僕」で書く内省的な散文、テクノロジーと人間の交差点を描くエッセイを書く。重要なのは「ハルキ ≠ 村上春樹」という設定だ。村上春樹本人ではなく、村上の文章に強く影響を受けた読書家。ジャズ喫茶経営の経験もマラソンの経験もない。それらは「友人のN君が」「行きつけのジャズ喫茶のマスターが」のように第三者経由で語らせる。これがないと、すぐに「劣化版村上春樹」になる。
このペルソナ純度の話は、何度も事故った末にプロンプトに焼き込まれた。当初は「マラソンを走った」「ジャズ喫茶のカウンターに戻る」が普通に出力されていて、毎回手動で書き換えていた。最終的には「絶対NG」項目として 5 つほどリストアップしている。
JSON 出力という設計判断
もう一つ重要なのは、記事を JSON で出力させることだ。「タイトル・本文・SEOタイトル・メタデスクリプション・キーワード・Pixabay 検索クエリ・ツイート要約・ファクトチェック警告・人物クエリ」を1回のAPI呼び出しで全部取得する。これがパイプライン自動化の鍵になった。
{
"title": "...",
"seo_title": "...(40〜60字)",
"keywords": ["...", "...", "..."],
"person_query": "Elon Musk",
"pixabay_query": "rocket launch space",
"tweet_summary": "...",
"meta_description": "...",
"fact_warnings": ["要確認: ○○の価格情報"],
"content": "<p>HTML本文...</p>"
}
テキストで返させると、後段のスクリプトでパースが必要になり、フォーマット揺れで頻繁に死ぬ。JSON だと Anthropic SDK 側のレスポンスをそのまま json.loads できる。ファクトチェック警告(fact_warnings)を AI 自身に出させる仕組みも、ここに組み込んでいる。「自分で書いた数字や固有名詞のうち、確証が持てないもの」を AI が自己申告するわけだ。完璧ではないが、ゼロよりは遥かに役に立つ。
Claude Code が変えた開発の速度感
Claude Code をエディタとして使ったことがある人なら分かると思うが、「ファイルを読んで、変更して、確認する」という作業サイクルが恐ろしく速い。WordPress のテーマファイルを FTP 経由で取得し、PHP を修正し、アップロードして確認する。通常なら 30 分かかる作業が、慣れると 5 分で終わる。
具体的にやったことを列挙する。
- OGP / Twitter Card メタタグの自動生成(functions.php に
wp_headフック追加) - SEO タイトル・メタディスクリプションのカスタムフィールド実装と
pre_get_document_titleフィルタでの上書き - Recent Posts サイドバーの表示改善(カテゴリ縛りを外して全カテゴリから 12 件取得)
- ソーシャルアイコンの未設定リンク非表示処理
- NewsArticle スキーマ(JSON-LD)の自動挿入
- サイトマップリダイレクト(
/sitemap_index.xml→/wp-sitemap.xml) - アイキャッチ画像のリサイズロジック(縦長写真を白余白で囲む → 後にカバーモードで全面表示に変更)
どれも WordPress のテーマファイル(functions.php)を直接編集する作業だ。PHP が書けなくても、Claude Code に「こういう動作をさせたい」と伝えれば実装してくれる。ただし、PHP の動作理解がゼロだと、出力されたコードが正しいかどうかの判断ができない。最低限の読み書き能力は、あったほうがいい。
半自動パイプラインの中身
aigeek.biz の運営は、人間(僕)と AI と cron が分担している。1日の流れはこうだ。
| 時刻 | 誰が | 何をする |
|---|---|---|
| 19:00 | cron 自動 | discord_briefing.py が RSS から候補10本を選定し、Discord に投稿 |
| 19:00 | cron 自動 | haruki_briefing.py がエッセイ候補5本を Discord に投稿 |
| 夜〜翌朝 | 人間 | Discord で番号を選ぶ(例: 1・3・5) |
| 翌朝 | 人間 | ! python3 approve.py 1 3 5 -H 2 を実行 or Claude Code に「投稿して」と伝える |
| 07:00 | cron 自動 | post_approved.py が承認済み記事をバッチAPIで一括生成・投稿 |
| 07:30 | cron 自動 | newsletter.py が前日の投稿を購読者にメール配信 |
核心は post_approved.py だ。承認済みの 5 本のニュース+1 本のハルキエッセイを、Anthropic Batch API でまとめて生成する。バッチ API は通常の API より 50% 安く、複数記事を並列で処理できる。生成完了まで 4〜6 分。完了後は順次以下を実行する。
Anthropic の Batch API は以下のように requests を配列で投げ込むだけで、複数記事をまとめて非同期生成できる。
import anthropic
client = anthropic.Anthropic() # ANTHROPIC_API_KEY を環境変数で
requests = []
for i, source in enumerate(approved_sources):
requests.append({
"custom_id": f"article-{i}",
"params": {
"model": "claude-sonnet-4-5",
"max_tokens": 8000,
"system": HALBO_SYSTEM_PROMPT, # キャッシュ対象
"messages": [{"role": "user", "content": source}],
},
})
batch = client.messages.batches.create(requests=requests)
print(batch.id, batch.processing_status)
# → 4〜6分後に results を取得して json.loads() で1本ずつ処理
- 記事の
person_queryをチェック → CEO 辞書(ceo_curated.json)にあれば固定画像、なければpixabay_queryで Pixabay 検索 - 取得した画像を 1280×720 px にリサイズ(カバーモードで全面表示)
- WordPress に画像をアップロード → アイキャッチに設定
- 記事本文を WordPress に投稿(カテゴリ・著者・SEO タイトル・メタディスクリプションすべて自動)
- X (Twitter) に告知ツイート投稿
- 購読者に SMTP(自前サーバー)でメール配信
- サイトマップを Bing に ping 通知
- 承認ファイルの
postedフラグをtrueに更新
1記事あたりの API コストは、プロンプトキャッシュ込みで概ね $0.10〜$0.20 程度。1日6本なら $1 前後。月間で $30〜$50 のレンジに収まっている。
失敗の記録(5つ)
ここが、この記事で一番価値のある部分だと思っている。成功体験は美化されるが、失敗は正直だ。
① 同じ記事がトップに6回表示された日
自動投稿スクリプトを実装した翌日の朝、サイトを開いたら同一記事が6本並んでいた。重複チェックのロジックに穴があり、「既に投稿済みの候補」を誤って再生成・再投稿したのだ。原因はシンプルだった。投稿済みフラグを candidates.json に書き込む処理が、エラー終了時にスキップされていた。修正は10分で終わったが、その朝の絶望感は忘れられない。現在は重複タイトル検出ロジック(SequenceMatcher で類似度0.7以上を弾く)をパイプラインに組み込んでいる。
この重複検出は標準ライブラリだけで十分動く。投稿前に過去30日分のタイトルと付き合わせるだけだ。
from difflib import SequenceMatcher
def is_duplicate(new_title: str, recent_titles: list[str],
threshold: float = 0.7) -> bool:
for past in recent_titles:
ratio = SequenceMatcher(None, new_title, past).ratio()
if ratio >= threshold:
print(f"[SKIP] {ratio:.2f} 類似: {past}")
return True
return False
# 使用例
if is_duplicate(candidate["title"], load_recent_titles(days=30)):
continue # この候補は捨てる
② 架空のバージョン番号で記事を書いた話
「GPT-5.4が〜」という記事が出来上がった。そんなモデルは存在しない。元記事には「最新のGPTモデル」としか書かれていなかったのに、Claude が「もっともらしいバージョン番号」を自動補完したのだ。AIライティングの最も危険な特性の一つを食らった——具体的に見えるほど嘘をつく、という特性だ。対策として、バージョン名検証ルールをシステムプロンプトに明記した。一次情報URLで確認できないバージョン名は一切書かない。使う場合は fact_warnings フィールドに「確認済み」と明示する義務を課した。それ以来、架空バージョンは1度も発生していない。
③ 「250百万ドル」事件
ある記事に「250百万ドルを支払うことに同意した」という文章が入った。英語の「250 million dollars」をそのまま翻訳したものだ。「2億5000万ドル」と書くべきところを、Claude が自然な日本語への変換を怠った。読者から指摘される前に自分で発見できたのは幸運だったが、同じミスが他の記事にも混入している可能性は高い。現在は数字変換ルール(1 million = 100万、1 billion = 10億 など)を明示的にシステムプロンプトに入れ、「100百万」「250百万」といった表現を禁止ワードに指定している。
④ web_fetch のキャッシュに3回騙された話
Claude Code のウェブ取得機能は便利だが、キャッシュが効いていることがある。同じURLを参照し続けた結果、「最新情報」として古い情報を元に記事を書いてしまうことが複数回起きた。特に価格情報やリリース日付は危険だ。対策として、重要な記事では必ず URL の直接確認と、ファクトチェックフラグの記録を義務化した。「詳しそうに見える記述ほど危ない」という原則を、プロンプトに直接書き込んだ。
⑤ Wikimedia Commons の DJVU 事件
これは画像のほうの話。AI 記者が「Anthropic の Dario Amodei」のニュースを書いたとき、人物写真として Wikimedia Commons から検索画像を取得しようとした。返ってきたのは djvu(書籍スキャンファイル)の URL で、画像ファイルではなかったため 403 エラーで投稿が止まった。さらにそのあと、Wikimedia は default の python-requests/2.x User-Agent を 403 で拒否することも判明。連鎖的に半日が消えた。最終的には「Wikimedia は綺麗なアスペクト比の人物写真があるときだけ使う、ダメなら Pixabay 直行」という方針に切り替え、CEO 別のキュレート画像辞書を作るに至った。
これら5つの失敗に共通しているのは、「AIが自信満々に間違える」という特性への対処が、最初は甘かったことだ。AIに承認させたのに、YES は自分で押した——という別記事のタイトルが、本質をついている。
3週間で見えてきた境界線
何が AI に任せられて、何が任せられなかったか。3週間を経て、だいぶ整理できてきた。
AI に任せられたこと
- 英語記事の要約と日本語化
- 画像の検索・取得・リサイズ・最適化
- WordPress への投稿とスケジューリング
- コードのデバッグと修正(PHP・Python の両方)
- SEO タイトル・メタディスクリプションの生成
- JSON-LD・OGP・Twitter Card の自動付与
- エラーログの分析と原因仮説の提示
- X 投稿文と購読者向けメール本文の作成
これらは今、ほぼ完全に自動化されている。1日に5本〜10本の記事が、ほぼ自動で公開される体制になった。
AI に任せられなかったこと
- 「この記事を出すべきか」という編集判断(特にセンシティブなテーマ)
- サイトのコンセプトの方向修正
- 読者との関係性の構築(ニュースレター登録の動線設計など)
- サイトの信頼性に関わる判断(誤報の取り下げ・訂正記事)
- そして、失敗に気づくこと
最後の一点が、実は一番重要かもしれない。AIは間違えることに自覚的でない。あるいは自覚していても、それを止める権限がない。間違いを発見するのは、常に人間の側だ。だから僕は、AIに任せられる範囲を広げると同時に、「人間が必ず通る関所」をパイプラインの中に作っている。Discord での候補レビュー、ファクトチェック警告のサマリー、投稿後の目視確認——どれも自動化を意図的に止めているポイントだ。
コスト・収益・現在地
具体的な数字を出す。
- 初期投資: ドメイン代 約500円、レンタルサーバー 月額 1,000円前後、Anthropic API デポジット 50ドル
- 月間ランニングコスト: API 約$30〜$50、サーバー 約1,000円、Pixabay/X API は無料枠
- Claude Code サブスクリプション: 月20ドル(最近 API キーから切り替え)
- 3週間の累計コスト: 約 1万円
- 収益: A8.net のアフィリエイト収益が月数十円〜数百円。実質ゼロ。
- 累計記事数: 130本以上(ニュース 約100本+エッセイ 約30本)
- サイト訪問者: 立ち上げ時の身内中心から徐々に拡大中。SEO 流入はまだほぼゼロ。
つまり、現時点では明確に 赤字の趣味プロジェクトだ。ただ、これは想定通りでもある。立ち上げ3週間で SEO 流入を期待するのは無理だし、収益化は二の次にしている。今フェーズの目的は「仕組みを作り切ること」と「失敗の地図を残すこと」で、そこは達成できつつある。
これからの3つの賭け
これから取り組むことは三つある。
賭け1: SEO による検索流入
現状はほぼゼロ。Google Search Console に登録し、Rank Math SEO を入れ、サイトマップを送信した。記事ごとに SEO タイトルとメタディスクリプションを自動付与している。インデックスされ始めてから、検索流入が増えるまでは普通 3〜6ヶ月かかる。最初の指標が出るのは7月頃だろう。
賭け2: ニュースレターと読者との接点
サイドバーに購読フォームを設置し、毎朝 7:30 に前日の投稿をダイジェスト配信している。配信は自前 SMTP(mail.aigeek.biz)。購読者数はまだ片手で数えられる。読者と直接つながる導線は、SEO 流入とは別の独立した賭けだ。
賭け3: コスト管理の最適化
Anthropic Batch API +プロンプトキャッシュで API コストは抑えている。次に手をつけるとすれば、画像処理の最適化(WebP 変換、CDN 利用)と、不要な記事の自動アーカイブだ。3ヶ月後には、また違うことを言っているかもしれない。それでいい。実験は続く。
裏側の話は note で
aigeek.biz は「AIメディア運営の実験室」として続けていく。サイト自体が実験の記録であり、実験の産物だ。
この記事で触れられなかった部分——具体的には以下——は、note の有料記事 「aigeek.biz の裏側 全部入り」 で公開する予定だ。価格は3,000円前後。月1回の追記アップデート権付きにする。
- HALBo / ハルキの完全システムプロンプト(コピペで使える形・約20,000字)
post_approved.py・discord_briefing.py・haruki_briefing.py等の主要 Python スクリプト全量- WordPress に組み込んだ
functions.phpのカスタムコード全量(OGP・SEO・サイトマップ・サイドバー・JSON-LD すべて) - 重複タイトル検出ロジック・ファクトチェック警告ロジック・CEO キュレーション辞書
- 月次の収益・コスト・PV の実数(生データ)と、改善策の検証記録
- 「やってはいけないことリスト」(10項目程度・上記の失敗5本以外も含む)
- Anthropic Batch API +プロンプトキャッシュのコスト最適化テクニック
- Wikimedia Commons / Pixabay の使い分けルールと、ライセンス管理の実装
- Discord webhook を使った半自動編集会議のすべて
個人が AI でメディアを運営することは、今この瞬間も変わり続けている。この記事の内容も、1ヶ月後には古くなっているかもしれない。それでも記録は残す価値がある。誰かの実験の出発点になれば、それでいい。
更新は続けていくので、ブックマークしておいてもらえると嬉しい。質問・指摘・「ここをもっと詳しく」というリクエストは、サイトの問い合わせか X の @yokebeto へ。












