『Claude Code完全入門』と『実践Claude Code入門』を読んで構築したurinosuke.com:CLI・Claude.md・失敗事例の3段階実装

なぜ2冊セットで読んだのか

2025年春、自分のブログサイトを構築する際に『Claude Code完全入門』(技術評論社)と『実践Claude Code入門』(同社・エンジニア選書)を続けて読んだ。1冊目がツール単体の使い方、2冊目がチーム導入・運用設計の実務論という構成で、両者を通読することで「個人開発でも使える設計原則」が見えてきた。

書籍は読んだだけでは意味がない。実際に手を動かして初めて「どこが分かっていなかったか」が浮かび上がる。この記事では、2冊を読んでから urinosuke.com を構築するまでの3段階——CLIベースの開発リズム、Claude.md による指示の定型化、失敗事例の言語化——を実装の手触りとともに記録する。

第1段階:CLIベースの開発リズムを身につける

『Claude Code完全入門』の核心は「ターミナルで完結する開発フロー」にある。GUIに頼らず、コマンド一発でファイル生成・編集・確認を回す習慣を作ることが、Claude Code を「単なる補助ツール」から「開発の主軸」に引き上げる鍵だった。

最初は戸惑った。これまでブラウザベースのエディタやWordPressのダッシュボードで記事を書いてきた身には、黒い画面で astro addgit commit を打つリズムが慣れない。しかし1週間ほど手を動かすうちに、「ファイル構造を直接触る感覚」が染み込んできた。

特に有効だったのは、書籍で紹介されていた「小さなコマンドを繰り返す」パターン。いきなり複雑な処理を書かず、lsでファイル一覧を確認し、catで中身を読み、echoでテスト出力する——この反復が、Claude Code に指示を出す際の「粒度感覚」を養った。ハンズオン形式で書かれた書籍の構成が、実装の足場として機能した。

第2段階:Claude.md で指示を定型化する

2冊目『実践Claude Code入門』で最も参考になったのは、Claude.md の運用設計だった。プロジェクトルートに .ai/claude.md を置き、繰り返し使う指示・制約・事実台帳をまとめておくことで、毎回同じ前提を説明する手間が消える。

このブログでは次の3つのファイルを用意した:

  • 著者事実台帳: 年齢・事業形態・資格・副業実績など「推測を許さない事実」を列挙
  • 読了書籍リスト: 記事で引用できる書籍のみを登録し、未読書籍の捏造を防ぐ
  • アフィリエイト運用ルール: Amazon・楽天のリンクテンプレートと運用基準

書籍では「チーム全体の共通理解を作る」文脈で Claude.md が語られていたが、個人開発でも効果は絶大だった。「自分が何を知っていて、何を知らないか」を言語化するプロセスが、プロンプト設計の精度を一段引き上げる。

特に「事実と推測を区別する」設計は、書籍で紹介されていた失敗事例——「AIが勝手に補完した情報を事実として記事に書いてしまった」——を未然に防ぐ仕組みとして機能している。制約を明文化することで、出力の信頼性が担保される。

第3段階:失敗事例を言語化して設計に反映する

『実践Claude Code入門』のもう一つの強みは、失敗事例の記述が丁寧なことだ。「こうすればうまくいく」だけでなく、「こうすると失敗する」が具体的に書かれており、それが実装時の判断基準になった。

自分の場合、次の3つの失敗を経験した:

  1. 未読書籍を記事で引用してしまった: 初期は「この本も読んだはず」という曖昧な記憶で書籍名を出し、後で「実際には読んでいない」と発覚。読了書籍リストの厳格化で防止
  2. 日付表現で矛盾が生じた: 「先週の現場で」「昨日の作業で」等の時系列表現を使ったが、記事は執筆日と公開日がズレるため文脈が崩壊。時系列断定を禁止ルール化
  3. 抽象化と具体化のバランス崩壊: 最初は「誰にでも分かるように」と抽象的に書きすぎて読者に刺さらず、次は固有名詞を出しすぎて機密情報に触れそうになった。書籍で紹介されていた「具体例は3つまで」「固有名詞は抽象化」の原則を採用

これらの失敗を Claude.md の「禁止事項」セクションに反映し、次の記事生成で同じミスを繰り返さない仕組みを作った。失敗を言語化して設計に組み込むプロセスが、書籍を読んだ後の「実装の質」を左右する。

書籍と実装の距離を縮める方法

2冊を通読して感じたのは、「書籍の知識」と「手を動かした実装」の間には、必ず「失敗と修正の反復」が挟まるということだ。書籍を読んだだけで「分かった気」になるのは簡単だが、実際にコードを書き、エラーに遭遇し、設計を見直すプロセスを経ないと、知識は定着しない。

このブログは、Claude Code を使って記事を自動生成する仕組みだが、その裏には「何を書いてはいけないか」「どの情報源を信頼するか」「どう失敗を防ぐか」という設計の積み重ねがある。書籍はその設計の骨格を与えてくれたが、肉付けは自分の試行錯誤でしかできなかった。

今後も新しい機能を追加するたびに、書籍に戻って「なぜこの設計なのか」を確認するサイクルを回していく。知識と実装の距離を縮めるのは、反復だけだ。

まとめ

『Claude Code完全入門』と『実践Claude Code入門』を読んで urinosuke.com を構築した3段階は、CLIベースの開発リズム・Claude.md による指示の定型化・失敗事例の言語化だった。書籍は設計の骨格を与えてくれるが、実装の肉付けは自分の試行錯誤でしかできない。知識と実装の距離を縮めるのは、反復だけだ。

関連書籍

Claude Code完全入門
Amazonで見る | 楽天で見る

実践Claude Code入門——現場で活用するためのAIコーディングの思考法
Amazonで見る | 楽天で見る

参考

← ブログ一覧へ戻る