本ガイドはこう作られた

《 Claude完全ガイド 目次へ 》

10秒でいうと

87ページ、20万字、図35枚。原稿も図も投稿もClaude Codeで回しました。
効いたのは速さではなく、静かに失敗する工程を止める仕組みのほうでした。

このガイドは、書かれている内容をそのまま使って作られています。制作の記録を残します。

数字

参照先の内訳は、開発者向けドキュメントが45件、サポート記事が44件、Claude Codeのドキュメントが41件、MCPの仕様が8件。モデル名も料金も機能の提供状況も、書く前に必ず開いています。

何を決めてから始めたか

書き始める前に、3つ決めました。

1. 図はスライド基準で作る。全図面を1920×1080で作り、Web用と書籍用はそこから書き出す。逆にすると、密度の高いWeb図を16:9に押し込むことになり、作り直しになります。

2. 記憶で書かない。モデル名・料金・上限・提供状況は、必ず公式を開く。確認した日と参照URLをページごとに記録する。

3. 用語を先に固める。訳語が揺れると本にしたとき目立つので、用語集を第1章より先に作りました。

この3つは、あとから変えると全ページに波及します。先に決めたのは正解でした。

効いたのは検査だった

いちばんの発見です。文章を速く書くことより、間違ったまま公開しない仕組みのほうが効きました。

投稿の前に、機械が次を見ています。落ちたら投稿されません。

• フロントマターの14項目がすべて埋まっているか
• ページ番号と公開先のURLが一致しているか
• 図の参照と画像の一覧が両方向で一致しているか
• 冒頭の要約が100字を超えていないか
• 必須の節があるか
• 未公開ページへのリンクが張られていないか
• 書式の規約を守っているか

すべて、実際にやらかしたことから来ています。

静かに失敗する工程を止めた

このプロジェクトを通しての主題です。エラーを出さずに失敗する工程が、いちばん高くつく。

例1：フォントが無言で置き換わった。

図の仕様書は「フォントが無いとエラーを出さずに別フォントへ置き換わる」と警戒していました。ところが、その仕様書が指定していたフォント名が、制作環境に存在しませんでした。

実測すると、指定したフォントが無い場合、終了コード0でPNGが出力され、等幅フォントに置換されてレイアウトが崩れていました。警告はstderrに出るだけです。

対策として、書き出し前に試し描画でフォントを確認し、書き出し後もstderrを見て、置換が起きていたら生成物を消して中断するようにしました。

教訓。仕様書に「これは危ない」と書いてあっても、仕様書自身がその罠を踏んでいないかは別の話。

例2：一括置換がテキストを壊した。

書式を直すために105箇所を正規表現で一括置換したところ、4行のテキストが壊れました。**A**と**B** のような行で、正規表現が「太字と太字のあいだ」を太字の中身と誤認したためです。

公開前に、太字のペアを構造として解析する別の方法で検算して、全件見つけて直しました。

教訓。同じ正規表現で確認しても意味がない。構造を解析する別の方法で検算する。

例3：図の下線バーが、静かにずれる形だった。

タイトルの下線バーを固定幅にしていたため、「最初の2文字だけ下線」に見えていました。Kayの指摘で気づきました。

さらに悪いのは、リファレンスをコピーしてタイトルだけ書き換えると、バーの幅が古いまま残ることです。書き出しは成功するので気づけません。文字の実寸を測る手段があると分かったので、幅が4pxを超えてずれたら中断する検査を入れました。

人は直らない、という前提

いちばん正直な話を書きます。

太字の先頭と末尾に約物を置かない。この規約を、第2章から第10章まで毎章破り続けました。回数は減っていません。

第5章に「同じ規約を2回破ったら、注意力の問題ではなく仕組みの問題」と書きましたが、仕組みにしたあとも、書く側は破り続けるというのが実態でした。

ただし、検査があることで、破ってもコストが「書き直す数分」に収まっています。

仕組みは、人を直すためではなく、人が直らないことを前提に置くもの。これがこのプロジェクトで得た、いちばん実感のある結論です。

途中で構成を変えた

第1章を公開したあと、外部のレビューを受けて構成を変えました。

冒頭に100字以内の要約を足し、まとめと重複していた節を廃止しました。検索から着地した読者に、先に答えを渡すためです。

11ページ分の手戻りで済みました。第2章を書いたあとなら19ページ、全部書いてからなら84ページです。

先に完璧を目指さず、早く公開したから安く済みました。第10章のNo.77で書いたことは、この経験から来ています。

何が速くなり、何が速くならなかったか

速くなったもの。

• 公式ドキュメントを読んで、要点を取り出す
• 図をSVGで作り、3系統に書き出す
• WordPressへの投稿、リンク化、メタ情報の反映
• 書式の検査と修正

速くならなかったもの。

• 何を書くかを決めること
• どの順番で説明するかを決めること
• 読んで「これは違う」と気づくこと
• 公開してよいと判断すること

判断は移りませんでした。このガイドで繰り返し書いてきたことが、制作でもそのまま当てはまりました。

使った機能

参考までに、実際に使ったものを挙げます。

• Claude Code（原稿、図、スクリプト、投稿）
• CLAUDE.md（文体、規約、フロントマターの定義）
• Web検索（公式情報の確認）
• 画像の読み取り（書き出したPNGを読み直しての目視確認）
• IDEとの併用（差分を見ながら直す）

サブエージェントもMCPも、このプロジェクトでは必須ではありませんでした。規模と性質によります。

やってみよう：自分の作業で、静かに失敗する工程を探す（5分）

繰り返している作業を1つ選んでください。制作でも事務でも構いません。

プロンプト
“`
次の作業手順について、「失敗したのに、その場では気づけない工程」を
挙げてください。

・エラーや警告が出ないまま、間違った結果が次に流れる箇所
・それぞれ、どうすれば気づけるようになるか
・人の注意力に頼らない対策だけを挙げてください

手順：（ここに書く）
“`

期待される結果：気づけない工程が挙がり、それぞれに機械的な対策が付く。確認する、で終わる対策が入っていない。

うまくいかないとき：「注意して見る」のような対策が出たら、指示が効いていません。そこが、このガイドで最も繰り返した話です。

関連ページ

• No.60 Webサイトとブログ運用 — 制作フローの詳細
• No.41 フックとプラグイン — 必ず走る処理
• No.77 個人開発：0から公開まで — 早く出して直す

まとめ

• 87ページ、20万字、図35枚。公式ページを延べ147件参照
• 効いたのは速さではなく、静かに失敗する工程を止める仕組み
• 仕組みは、人が直らないことを前提に置く
• 判断は移らなかった。何を書くか、公開してよいかは人が持つ

次に読む

用語集

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。