開発日記 10/29 — 原稿 103 本と記事のサイトを 1 日で作った。いちばん時間を食ったのは、表示されないトップの 1 行だった
D29-3-N02-notes-site-in-a-day・技術・開発日記
2026-10-29 は、昼から夜までの 1 本の Claude Code のセッションで、X に流す原稿 103 本と、それを載せる記事のサイト kaedeasset.com/notes/ を作りました。
数字で言うと、作者の入力が 104 回、Claude Code が道具を使った回数が 590 回、サブエージェントが 26 本、コミットが 61 本（+30,813 行）です。
『霧走町 流氷に眠る』の宣伝のための一日でしたが、いちばん長く止まったのは、原稿でもサイトでもなく、ドメインのトップに足した 1 行が「表示されない」問題でした。
夜にやった「名前のある技術の一覧」の洗い直しは、別の日記（N01）に書きました。
この日記は、その前の 8 時間の話です。
今日の目標 — トップの直しから、X の計画の作り直しへ#
最初の入力は 12:18 の、ドメインのトップの直しでした。
「一番上の ADV を移動、adv.kaedeasset.com へのリンクにして、直接作品にはリンクしない」
続けて、GitHub へのリンク、作者の X へのリンク、案内ページへの GameWith のボタン。
ここまでは、どれも 1 回の編集と 1 回の VPS への送りで済む小さな仕事です。
13:18 に、話が大きくなりました。
「gamewith04 を再構成。GameWith のビューが悪い、効果が薄い。X に毎日 3 つポストする、長文のポスト可能なプランに変更済み」
前の計画（GameWith の記事 100 本）を捨てて、X の長文ポストの計画に作り直す。
作者はそこから、講談社の企画書を遊ぶ人向けの参考にすること、技術の回は「日本語入力でプレイする実装」をがっつり書くこと、遊ぶ人向けと技術を 1:1 にすること、と指示を重ねました。
13:42 に「第 1 週の原稿を書いて」が来て、そこから 17:04 までが原稿書きの時間です。
実際にした作業 ① — 原稿 103 本を、サブエージェント 16 本で書いた#
原稿は、1 週分（遊ぶ人向け 7〜14 本と技術 14 本）ずつ、サブエージェントに分けて書かせました。
13:44 に 3 本、14:34 に 3 本、15:20 に 3 本、15:37 に 3 本、16:20 に 2 本、16:45 に 2 本。合わせて 16 本です。
親のセッションは、各回の出所（読むファイル）と決まり（計画書の §2）を渡して、返ってきた原稿を読み、直して、コミットする係です。
途中で、決まりが 4 回変わりました。
- 14:01「記事のタイトルを追加して、【】とかで」→ 本文の 1 行目を【題】にする
- 14:02「ぶっちゃけ、こっちの実装がまねできるくらい詳しくてもいい」→ 技術の回を 4,000〜12,000 字にして、書いた 14 本を書き直す
- 15:11「日本語で打つ、などはやめて、日本語で入力・日本語入力に統一して」→ 原稿の「打つ」を全部置き換える
- 15:15「タイトルの下にファイル名を明記して」→ 2 行目をファイル名にする（本文の「T06」を引けるように）
そのたびに、計画書の §2 の表に 1 行を足し、書き終わった原稿を全部その形に直しています。
決まりを先に計画書へ書いてから原稿を直す、という順番を守ったので、16 本のサブエージェントは、どれも同じ計画書を読んで書けました。
結果は、技術 64 本（合計 450,805 字）と遊ぶ人向け 39 本（合計 48,359 字）です。
本数は最初 39 本で考えていて、14:37 に作者から「39 にこだわってる？」と聞かれ、「記事の数に制約はない、書けるものは全部書いて」で 64 本になりました。
実際にした作業 ② — 記事のサイトを、作って、作り直した#
16:47 に「記事を VPS に載せる仕組みを作って、まずはローカルで確認」。
最初は 1 本の脚本（Python で約 300 行）で、原稿を HTML にして、ドメインのトップの組み立てに入れました。
16:52 に「マークダウン経由のきれいな HTML にしてる？」と聞かれて、箇条書き・定義リスト・節の id・OGP・コードの色分け（Pygments）を足しました。
17:14 に「X の投稿に先立って投稿していい」と許可が出て、103 本を全部 VPS に載せました。
17:16 に作者が「あれ？ブログのフレームワークは？」と言いました。
1 本の脚本は動いていましたが、設計が無かった。
17:19「ちょっとしたフレームワークを設計してみて、SNS 共有ボタンは欲しい」で設計書を書き、17:21「実装して、まずはローカルで確認」で Tools/notes-web/ に組み直しました。
設計書に合格の条件 N1〜N9 と検査 C1〜C7 を先に書いて、検査が全部通るまでを実装としています。
共有ボタンの行き先は、X・Bluesky・Threads・LINE の公式の文書で確かめられた形だけにしました（Facebook は公式の共有の窓にアプリの登録が要り、はてなブックマークと LinkedIn は公式の文書が見つからなかった）。
19:53 からは、作者が手元で見て、直しが続きました。
- 「11-01 T01 これってなに？」→ 一覧に X の投稿の予定日が出ていた。サイトはもう全部載っているので、まだ来ていない日付が並ぶのはおかしい
- 「記事が 300 個ぐらいになったら下に行くの大変だよね」「投稿に日付を付けるブログっぽくして、タグや日付で出す方法は？」→ 日付はサイトに載せた日（published.json に記録）、新しい順に 20 本ずつ、月ごとのページ
- 「ここまでできたら X は副だな」
- 「2 ペインにしたいな、記事が並ぶだけでは、左右が開きすぎる」→ 右に連載・月ごと・タグの欄
- 「トップにリンクを追加して、GitHub の下に 3 行ぐらいの説明付き」
組み立てるページは 351 になり、幅 375 で横にはみ出すページは 0 です（検査 C7）。
道具は Python で 849 行です。
Claude Code が間違えたこと ① — 「表示されない」を、ブラウザのせいにした#
今日いちばん時間を食ったのは、ここです。
12:21 に GitHub へのリンクを足して VPS に送り、12:25 に作者から「表示されない」。
Claude Code は最初、ブラウザのキャッシュを疑いました。
作者が別のタブで開き直しても、まだ出ない。
12:28 に作者が「最終更新時刻をどこかに入れて、最新か判断するため」と言い、トップの足元に組み立てた時刻を出す行を足しました。
それでも 12:39 に「12:31 JST、表示されない」、12:45 に
「でない、だいたいブラウザの問題を疑った時はブラウザの問題ではない」
が来ました。
ここで初めて、サーバーの側を順に見ました。
Caddy のプロセスは 1 つ、置き場のファイルは新しい版、外から引いた HTML にも新しい時刻が入っている。
原因は、Caddy が静的なページに付けている Cache-Control の max-age=300 でした。
ブラウザもその間の中継も、5 分間は前の版を渡してよいことになっていて、作者が開き直した時刻と送った時刻の差がちょうどその内側だった。
足した時刻の行のおかげで、「送れていない」と「送れているが古いのが見えている」を分けられたのが、解決の決め手です。
直したのは、手順書の側です。
Web の更新の手順書（web-pages-update.md）の §7 に、「表示されないと言われたら、ブラウザより先にサーバーの側を見る」「新しい版が出ているかは、ページの中の時刻を外から引いて見る」を、コマンドつきで書きました。
作者の一言（ブラウザの問題を疑ったときはブラウザの問題ではない）も、そのまま引いて残しています。
Claude Code が間違えたこと ② — 「一番下」を読み違えて、2 回やり直した#
同じ 12 時台に、もう一つあります。
作者の「MomijiUI が一番した」を、Claude Code は「GitHub のリンクを一番下の行に」と読み、足元の小さな © の行に移しました。
12:31「おい、なんで小さくした？」。
元に戻し、12:49「MomijiUI の下の同様の形式で出して」でカードにし、12:50「下の一覧の GitHub の列は消して。なぜ GitHub だけ同じにしていなかった？」で列を消し、12:51「ごめん、下の GitHub は戻してあった方がいい」で列を戻しました。
コミットの列で見ると、12:23 から 12:52 までの 30 分で、GitHub のリンクの置き場だけで 7 本のコミットがあります。
短い指示の「一番下」が、ページの最後の行なのか、札の並びの最後なのかは、文だけでは決まりません。
Claude Code の規約は「戻せる判断は自分で決めて進み、選んだ結果を 1 行で書く」なので、聞き返さずに進んだこと自体は規約どおりです。
ただ、見た目の大きさを変える判断（カードの並びから小さな文字の行へ）は、戻せても作者の目には後退に見える。
大きさや並びを変えるときは、変える前と後を 1 行で書いてから送る、というのがここで分かったことです。
Claude Code が間違えたこと ③ — 道具のつまずき#
要約の道具が拾った「道具のエラー」は 16 件で、主なものはこうです。
- 「打つ」を「入力する」に機械で置き換えたら、「打ち切る」が「入力し切る」になり、同じ語が二重になる所も出た。手で戻した
- コミットのフックに 2 回止められた。件名が 40 字を超えていた。件名を短くして通した（--no-verify は使わない）
- 記事の Markdown で、本文の
std::vector<std::string>の<std::string>を「std: のリンク」と読んで文字が消えていた。前の脚本の版で公開していたページでも消えていたので、autolink を切って直した - 手元のサーバーを 2 つ同時に立てていたら、PC のメモリが足りなくなって、両方とも止められた。以後は 1 つだけ立てて、見終わったら止める
- 待つために Start-Sleep を重ねたら、道具の側に止められた（待つなら、終わったら知らせる形で待つ）
- ヘッドレスの Edge は窓の幅を約 496 より狭くできず、幅 375 の写しの右が切れて見えた。ページの不具合ではなく、検査は iframe の中で幅を測る形にした
- ブラウザ版の配置の 1 コマンドが、自動の許可の判定に一度止められた（後で通った）
どれも、手順書か記憶か道具のコメントに 1 行ずつ残しています。
どう直したか — 作者の判断と、Claude Code の修正#
今日の判断のうち、作者が決めたものを並べます。
- X の計画: GameWith をやめて X の長文ポストへ。遊ぶ人向けと技術を 1:1、1 日 4 本まで、投稿にリンクを入れずプロフィールから辿る、本数の制約なし
- ネタバレの線: 「一章を実況したらネタバレになるのはあたりまえ。それぞれの作品、一章まではネタバレ OK」。案内ページにも書く
- ブラウザ版の応答: 画面が描かない欄（ヒントなど）を、ブラウザへ返す中身から外す。セーブの難読化はしない
- エンジンは OSS にしない。記事だけにする。記事は自分の VPS に載せる。EmDash などの CMS は使わない
- タイトルの曲（Suno）は有料プランで作ったので、外に出してよい
- 記事の日付は、X の投稿の日でなく、サイトに載せた日。「ここまでできたら X は副」
- もう機能は足さない。このままリリースする
Claude Code の修正は、その判断を計画書・手順書・設定の一か所に書いてから、原稿と道具を直す、という順番で入れています。
決まりの正が一か所にあるので、サブエージェントに渡すときも、計画書の節を指すだけで済みました。
実測#
- 人の入力 104 回、道具 590 回、サブエージェント 26 本（原稿 16 本・夜の洗い直し 6 本・夜の書き直し 4 本）、道具のエラー 16 件（要約の道具の集計）
- コミット 61 本、453 ファイル、+30,813 行 −2,760 行（git log --shortstat）
- 原稿 103 本: 技術 64 本で 450,805 字、遊ぶ人向け 39 本で 48,359 字
- 記事のサイト: 道具 849 行、ページ 351、幅 375 のはみ出し 0、検査 C1〜C8 と書き方の検査 A1〜A7 が全部 PASS
- VPS への送り: 送りのコマンドを 32 回流した（ドメインのトップと記事 28 回・ブラウザ版 4 回。止められて流し直した回を含む）。毎回、同じコマンドで作り直される KaedeRPG の説明書の元が main と同じかを先に確かめた
残ったこと#
- X への投稿は 11 月 1 日から。原稿の media の「要撮影」「要作成」（図と写真）は、まだ作っていない
- 遊ぶ人向けの P24 と P32 は、本文が写真の中身を細かく書いているので、撮るまで絵なし
- ブラウザ版の「打つ」（操作説明の文・案内ページの「キーボードを打たずに」・予告編の字幕）は、作者の判断待ち
- 検査の側の欠陥（!expect の失敗が隠れる所など）は、報告書に書いたまま。いまは第一章のデモ版とブラウザ版が動けばよい、という判断
- kaedeasset.com のアクセスはまだ記録していない。X からどれだけ来たかは、X の側の数字でしか分からない
何が分かったか#
一日で原稿 103 本とサイトを作れたのは、書く量のせいではなく、決まりを先に一か所に書いたからです。
決まりが 4 回変わっても、計画書の表を 1 行直して、サブエージェントにはその表を読ませる。
書いた原稿は、決まりの側に合わせて直す。
これを毎回守ったので、16 本のサブエージェントの原稿が、同じ形でそろいました。
いちばん時間を食った「表示されない」は、逆に、決まりが無かった所でした。
「新しい版が出ているかをどう確かめるか」が手順書に無く、Claude Code はいちばん手近な説明（ブラウザのキャッシュ）に飛びついた。
作者の一言で、確かめる順番（サーバーの側から、ページの中の時刻で）が決まり、それを手順書に書いて終わりました。
この日記も、Claude Code の記録（セッションの .jsonl）を要約する道具を今日作って、その要約から書いています。
材料が残る場所から書けば、セッションの終わりに覚えている必要はありません。