記事工場をつくったら、90点の没記事が出てきた

工場は完成した。動かなくなったのは、私のほうだった

チャット履歴を放り込むと記事の草案が出てくる仕組みを作った。記事工場と呼んでいる。

作りきった。試運転もした。一本目の草案も出てきた。読みやすかったし、点数をつけるなら90点は出ていたと思う。

そのあと、一度も使っていない。

この記事は、その顛末である。工場の中身と指示文は、そのまま使えるので後半にまとめて残しておく。

発端：サイトが作れるなら、記事も任せられるのでは

そもそもこのサイトを作った理由には、趣味や考えを発信したいというのに加えて、いつかお金稼げないかなというカッコ悪いほうも混ざっている。最初の記事に書いたとおりで、ここは今も本心である。

そのうえサイト作りもAIに任せて出来てしまったので、欲が出た。これ、記事作りも一貫して任せられるのでは？ と、ラクする方向に考えが伸びた。

もう一つ理由がある。XでAI関連のフォローやイイネをしていると、巷で「AI驚き屋」と呼ばれているような、情報商材屋さんかなと思われる人や、この人何している人なんだろうと思えるような投稿が流れてくる。AIめっちゃやってます、稼げます、稼いでいます。そのなかに、note の有料記事をAIに書かせて稼いでいますという話をよく見かけた。

半信半疑ではあった。ただ、こんな簡単に（今思い返すと簡単だったのか怪しいけれど）サイトまで作れるなら行けるのでは、と思って、一回頼んでみることにした。

急いでいた事情もある。当時Fable5が7/7まで期間限定で解禁されていて、いつものごとくギリギリで動き出したため、期限が迫っているなかでの工場作りだった。

なお、期限はこのあとズルズル延長されて、意外と何回か作業させられた。急ぐ必要はあまりなかった。

GPTは「記事を書くAI」より先に「工場の型」を作れと言った

まず相棒のGPTに相談した。

fable5が使えるうちに記事が量産できる仕組みを骨だけでも作っておきたい。 チャットの履歴とかからいい感じに拾ってきて、テーマだし、草案、本文作成みたいなのをさくっとできるようなGPTsやエージェントみたいなのをfable5に作らせよう。

返ってきたのは、少しズラした提案だった。

今やるなら「記事を量産するAIそのもの」より先に、「記事工場の型」を作っておくのが良いです。

理由はこうだった。BIBIMBA WORKSはチャット履歴・失敗談・試行錯誤が原料なので、いきなり本文を書かせるより、原料から記事になるまでの工程を固定したほうが強い。

そしてもう一つ、強めの注意がついてきた。チャット履歴そのものをGit管理に入れるな。 個人情報・会社情報・家族情報・ローカルパスが混ざる可能性があるから、原料はローカルの非公開フォルダに置き、安全化されたMarkdownだけをリポジトリに入れる。

これは、この時点の私にはかなり効いた。直前に、まさにその手のもので痛い目を見ていたからである（サーバーとメールアドレスの話）。

珍しく、私から修正を出した

GPTが出してきた初版の指示文は、サイト本体のフォルダの中に素材置き場を作る前提になっていた。ここで珍しく、自分から修正を投げている。

今回のgitで管理しているようなフォルダではなくて新しくbibimbaworksの記事下書き用のフォルダを作ってもいいよ。でも、フォルダ分けるとこれまでの実装の履歴がなくなるから、今指定してるフォルダ内のサイトの情報以外のところに新しいフォルダを作って始めても良いかも

言い方は要領を得ていないが、要はサイト本体と素材置き場を別のフォルダに分けたいという話である。gitのトラウマからだと思う。

これは採用された。このシリーズで自分が出した修正としては、たぶんいちばん筋が良かった。

指示文を、校正させるようになった

この頃、別のチャットで試していたときもGPTの指示文にミスが目立つようになっていた。なので、投げる前に一度こう聞くようになった。

この指示で量産工場はできそう？ 完璧ならこの指示文で行きますが、もう一度もっと良い案がないか校正してみて

すると、5点ぶん足りていない箇所が出てきた。

1. 既存の運用ドキュメントと重複・矛盾しないようにする
2. 外部フォルダを作れなかった場合の代替動作を入れる
3. 生ログをGit管理へ入れない方針をさらに強くする
4. AIが勝手に記事本文を量産しすぎないようにする
5. コミットはするが、pushはしないと明記する

自分では中身の良し悪しが判断できないので、書いた本人に校正させる。 変な話だが、これがいちばん効いた。指示文を出す前にもう一往復させるだけなので、コストも安い。

工場を作らせたら、また個人メールが出てきた

出来上がった指示文をClaude Codeに渡して、実行してもらった。

工場自体は問題なく組み上がった。ただ、サマリーの2番目にこう書かれていた。

⚠️ 発見：change-log.md の過去エントリに個人メールアドレスの平文が残っており、再init後の新履歴のコミット内容にも含まれていました。

つまり、以前の記事で片づけたはずのメールアドレスが、別の場所に残っていた。最新のファイルはマスク済みだが、過去のコミットの中身には平文で残っている。しかも、そのコミットはすでにGitHubへpush済みだった。

ここは自分では気づけなかった。作業させたAIが自分で見つけて報告してきた形である。

対処は、GitHub側のリポジトリを一度削除して同名で作り直し、ローカルも .git を消して履歴を1コミットに平坦化する、というものだった。以前の記事でやったことを、もう一度やった。

記事を量産する仕組みを作りに来て、また黒い画面でGitの履歴を消していた。この作業の記録を読む

---

以下、工場の中身をそのまま置いておく

ここからは、実際に作った記事工場の構成をそのまま残す。同じようなものを作りたい人がいたら、たぶんこの通りにやれば動く。使わなくなった当人が言うのもなんだが、仕組みとしては素直に良い出来だった。

フォルダ構成

BIBIMBA_WORKS/
├─ bibimba-works/            ← Astroサイト本体。Git管理あり
└─ bibimba-content-factory/  ← 記事工場。Git管理しない
   ├─ README.md
   ├─ inbox/          チャット履歴・思いつきメモの一時置き場
   ├─ source-notes/   生ログから危険情報を抜いた素材メモ
   ├─ topic-cards/    記事候補カード
   ├─ outlines/       構成案
   ├─ drafts/         まだサイトに入れない草案
   ├─ reviewed/       安全チェック済み。サイトへ移せる候補
   └─ assets/         写真・スクショの候補

工場側には .git を作らない。GitHubにもpushしない。サイト本体の外側に置いてあるので、そもそもGitの管理対象に入らない。念のため、サイト本体の .gitignore には _private/ を保険として足してある。

工程

生ログ・チャット履歴
↓
Source Note（安全化済みの素材メモ）
↓
Topic Card（記事候補カード）
↓
Article Outline（構成案）
↓
Draft（draft: true のMarkdown草案）
↓
安全・公開前レビュー
↓
サイト本体へ

設計でいちばん効いていると思うのは、生ログを渡してよいのは最初の抽出段階だけという線引きだった。構成案から先には、安全化済みのメモしか流れない。

テンプレートの見出し

各段階のテンプレートは、見出しだけ決めてある。中身はそのつど埋める。

Source Note

## 元になった出来事
## いつ頃の話か
## 何をしようとしていたか
## 実際に起きたこと
## 詰まったこと
## うまくいったこと
## 失敗・勘違い
## 実測値・スクショ・写真
## 記事化できそうな視点
## まだ確認が必要なこと
## 公開してはいけない情報
## 安全化メモ
## AIに補完させてはいけないこと

Topic Card

## 仮タイトル
## カテゴリ
## ステータス
## この記事の問い
## 最初に言う結論
## 読者に役立つこと
## 自分にしか書けない一次情報
## 失敗供養ポイント
## 必要な写真・実測値
## 安全チェック
## 想定タグ
## 記事化優先度
## 次の作業

Article Outline

## 記事タイトル案
## この記事で答える問い
## 先に言う結論
## 想定読者
## 本文構成
### 1. 背景
### 2. 詰まったこと / やってみたこと
### 3. 原因・分かったこと
### 4. 解決方法 / 現時点の結論
### 5. 次回やること
### 6. 監督: ビビンバのひとこと
## 必要な写真
## 必要な実測値
## 書かないこと
## 公開前チェック

ステータスの値はこの4つ。

kousou: 構想中
shisaku: 試作中
unyou:  運用中
kuyou:  失敗供養

エージェント4種

各工程に、そのままAIに貼れるプロンプトを用意した。ここが工場の本体である。

A. ネタ抽出 — 生ログ・作業メモから記事候補を抜く。出力はTopic Card形式。

個人情報・会社情報・取引先情報を抜く／事実と推測を分ける／AIが勝手に成功談へ美化しない／失敗や迷いを価値として残す／体験していないことを書かない／不明点は [要確認]

B. 構成案 — Topic CardからOutlineを作る。

問い→答え／1記事1テーマ／数値や写真が足りない場合は [要確認]／SEO臭くしすぎない／実体験の記録感を残す

C. 草案作成 — OutlineからMarkdown草案を作る。

必ず draft: true／frontmatterを既存スキーマに合わせる／足りない情報は捏造せず [要確認]／表記統一／うますぎる文章にしない／記録感を残す

D. 安全・公開前レビュアー — 草案を公開前に見る。判定は 公開OK／要修正／公開不可 の3つ。

確認項目はこれ。

個人情報 / 会社情報 / 取引先情報 / 住所特定 / 家族情報
ローカルパス / メールアドレス / IPアドレス
写真・スクショの危険要素 / EXIF
AIの捏造 / 誇張表現 / draft状態
JSON-LDと本文の一致 / 表記揺れ / [要確認] の残り

出力させるのは、判定・修正箇所一覧・残すべき一次情報・削るべき危険情報・[要確認] の一覧。「残すべき一次情報」を出させるのがミソで、これがないとレビューが削る方向にしか働かない。

作業させるときに毎回付けた制約

Claude Codeに投げるときは、毎回これを添えていた。

- bibimba-works/ 側は触らない
- src/content/log/ にはまだ作らない
- Git commit / push はしない
- 不足情報は捏造せず [要確認] のまま残す
- ローカルパス、PCユーザー名、GitHubアカウント名、
  メールアドレス、noreplyアドレス完全表記、実IPは書かない

そして作業後に、変更したファイル一覧・npm run build の結果・git status・pushしていないこと、まで報告させる。ここまで書くと、暴走しても被害が工場の中で止まる。

---

試運転の一本目は、このチャット自身にした

工場ができたので、さっそく回してみることにした。

このチャットをclaudeに渡してこの作ったフロー回してみてもらう？

このサイトづくりは、はじめから記事にするつもりだった。だから第一号の原料は、この工場を作っているチャットそのものにしようと思った。

ところが止められた。このチャットにはローカルパス、GitHubアカウント名、noreplyアドレス、Git操作ログ、個人メールが入っていた話が全部含まれている。そのまま貼るのは危ない。

でもまて、じゃあチャットの情報ってどうやって渡したらよいのだろう。

どうやってチャットの情報を渡す？

答えは、GPT自身にこのチャットを安全化させて、素材メモの形にしてからClaudeへ渡す、というものだった。

伝書鳩では…。 AI同士の伝書鳩になった話

途中で、抽出用のプロンプト作りも足した

素材メモを作らせているうちに、思いついたことがある。文章が得意な（と自分が思っている）Claudeに、抽出用のプロンプトそのものを書かせたらいいのでは？

そこで、チャット履歴から事実・失敗・判断・感情・迷い・記事候補まで拾わせるプロンプトを作らせた。秘匿情報はマスクさせる。

出てきたものをGPTに見せて、2箇所だけ直させた。

• 長いチャットを分割して渡すとき、こちらが「ここまで。Source Noteを作成してください」と言うまで出力させない
• 例示に使っていたWindowsのローカルパスの表記をぼかす（危険ではないが、あとで危険文字列を検索するたびに引っかかるため）

上のほうは実用性が高い。長いチャットを何回かに分けて貼ると、AIは途中で勝手にまとめ始める。あれを止められる。

0→100をClaudeにやらせて、真面目なGPTに修正させている。 GPTに肩入れしているので、だいたいこの形になる。

カード5本、構成案1本、草案1本

素材メモをClaudeに渡すと、記事候補のカードが5本返ってきた。

このとき一つ、感心した判断がある。候補として渡した視点のうち一つを、Claudeが自分から見送っていた。

単体では「dev serverを立てて表示できた」だけで一次情報が薄いためです。

薄いネタを無理にカードにしない。そのうえで、その学びは他のカードに吸収してある、と説明までついていた。

そこから一本を選んで構成案を作らせ、構成案から草案を作らせた。私がやったのは、GPTが書いた指示文をClaudeに貼り、返ってきたサマリーをGPTに貼ることだけである。

はい、私は受け渡しているだけです。

レビュアーが「要修正」を出した。これは正常だった

工程の最後には、公開前レビューが入る。

判定は要修正だった。

これは失敗ではなく、想定どおりだった。事前にGPTからもこう言われていた。

最初から公開OKを狙わず、「何を埋めれば公開できるか」を洗い出すために使うのが良いです。

実際、指摘は具体的だった。frontmatterより前にHTMLコメントが置かれていて、このままサイトに移すと記事として認識されないこと。本文にある「リンク切れの確認」を実際にやった記録がどこにもなく、AIの捏造の可能性があること。3Dプリンターについて、まだ購入済みと確定していないのに既に使っている印象になっていること。

危険情報はゼロ、判定は要修正、埋めるべき項目は8件。

本文に行く前に止まる仕組みとして、ちゃんと機能していた。

そして工場は、引き継がれずに閉じた

このあたりでチャットが限界に近づいていたので、いつもどおり引き継ぎ文を作らせた。

これで記事工場V1が完成した。そして、一本目の草案が生まれた。

そして、引き継ぐことなく工場は幕を閉じた。

90点だった。それでも、しっくり来なかった

出てきた記事は、私がプロンプトを入れて、あとは任せるだけで出てきている。そう考えると90点以上出ているし、読みやすい。文章としては、たぶん自分が書くより整っている。

でも、内容が省略されていて、伝えたいことが微妙にズレてるかも？ と、ライターでもないのに思ってしまった。

構想としては、けっこう本気だった。最近はなんでもAIチャットを開きながら作業しているのだから、そのチャットを読み込ませて記事が作れれば最強じゃん。チャットからトピックを引っ張れば、無限にネタに困らないじゃん。そう思っていた。

なんだろう、何かが違ったんだよね。

当時はここまでしか言えなかった。

没記事は、直さずそのまま置いておく

出てきた一本は、直さないでそのまま展示することにした。

いま採用しているシリーズの記事と並べてみると、違いは目で見て分かる。

• 見出しが全部「なぜ〜か?」「どこで〜か?」の問い形式になっている。出来事を名指しする見出しではなく、章立てが先にあって、そこに内容を流し込んだ形になっている
• 固有名が消えている。 GPT・Claude・Claude Codeが「相談役」「作業役」に一般化されている
• 失敗が「不安になったこと1／2」という番号付きの項目に整理されている。「はじめから言っとけ」の類の言い回しは一つも入っていない

どれも、指示どおりではある。SEO臭くするな、体験していないことを書くな、危険情報を出すな——出した制約は全部守られている。守られたうえで、こうなった。

なお、没記事には「構築に2日、チャットのやり取りは60往復くらい」という数字が入っている。工程の途中でGPTからは「正確に数えないなら書くな」と言われていた箇所である。この数字は工場が生成した草案に書かれていたもので、自分で数えたわけではない。

今になって言葉にすると、量の問題だったと思う

書きながら気づいたことがある。

このサイトの立ち上げの経緯は、Gitの話まで並べてもまだ書き足りないくらい、伝えたいことがあった。Gitの件も、FIG.1の件も、伝書鳩の件も、それぞれ一本ぶんある。

それが、1枚に収まって、しかもさっぱり終わっている。

その時点で、私は全然伝えれてないな、となっていたのだと思う。しっくり来なかったのは文章の出来ではなく、たぶん量のほうだった。

答え合わせ：バンバン作っておけばよかったのかもしれない

結果として、工場は使っていない。記事も生まれていない。

今思えば、この90点で満足してバンバン記事を作っておけば、今頃もっと何かできていたかもしれない。90点の記事が20本あるサイトと、手書きで詰まりながら書いた記事が数本のサイトなら、前者のほうが読まれた可能性は普通にある。

そこは、まだ答えが出ていない。

そしてこのあと、記事を書く手そのものが止まる。次回はその話になる。