Claude Code完全入門と実践入門を両方読んで38歳が実装した『CLIベース開発リズム』3段階:プロンプト設計・サブエージェント・チーム導入の実務

Claude Code 2冊を読んでサイト構築した38歳検査員の実装記録

私は株式会社USを運営する38歳のNDT検査員で、2024年末から Claude Code を使って urisol.com と urinosuke.com の2サイトを実際に構築した。技術書は『Claude Code完全入門』と『実践Claude Code入門』の2冊を読み、ハンズオンと実務論点の両面から学んだ。

2冊を読んで分かったのは、Claude Code は「ツールとして使う段階」と「開発リズムとして回す段階」と「チームで回す段階」の3段階があるということ。私は現在、1段階目から2段階目への移行期にいる。この記事では、2冊から得た学びと実装の実務判断軸を整理する。

第1段階:ツール単体として使う — CLIベースの開発リズムを身体化する

『Claude Code完全入門』(技術評論社)は、CLI(コマンドラインインターフェース)ベースの開発リズムとハンズオンが軸の入門書。私はこの本を読んで、「コードを書く」と「Claude に指示する」の境界を意識的に曖昧にする感覚を掴んだ。

具体的には、urisol.com の Astro + Cloudflare 構築で以下の作業を Claude Code に任せた:

  • サイトマップ生成スクリプトの作成
  • OGP画像の自動生成ロジック(Playwright経由)
  • RSS/Atom フィードの出力設定
  • markdown frontmatter の一括検証スクリプト

これらはすべて「こういう機能が欲しい」と自然言語で伝えて、Claude が生成したコードをレビュー・微調整する流れで完成させた。この段階では、Claude Code は「コーディング補助ツール」として機能する。自分が書くよりも速く、エラーも少ない。ただし、生成されたコードの意図は自分で読み取る必要がある。

第1段階で重要なのは、「自分が何を作りたいか」を明確に言語化できるかという点。曖昧な指示では曖昧な出力しか返ってこない。私は『Webを支える技術』や『達人プログラマー』で学んだ設計原則(REST・DRY・直交性)を前提知識として持っていたため、指示の解像度を上げやすかった。

第2段階:プロンプト設計として回す — Claude.md とサブエージェント運用

『実践Claude Code入門』(技術評論社 エンジニア選書)は、チーム導入・Claude.md 運用・サブエージェント設計の実務論点がまとまった本。特に失敗事例の言語化が参考になった。

この本で学んだ核心は、Claude Code は「プロンプト設計」の段階に入ると開発リズムとして機能するということ。具体的には以下の3つの設計をプロジェクトルートに置く:

  1. Claude.md(プロジェクト全体の設計方針):技術スタック・ディレクトリ構造・命名規則・禁止事項を明記
  2. サブエージェント(特定タスク専用のプロンプト):例えば「ブログ記事生成用プロンプト」「OGP画像生成用プロンプト」など
  3. 事実台帳(推測禁止の根拠ファイル):例えば私の場合、「著者事実台帳」「読了書籍リスト」を用意して、記事生成時に必ず参照させている

この設計を入れると、Claude Code は「コンテキストを保持したまま継続的に判断する開発パートナー」になる。私は urinosuke.com のブログ記事自動生成で、この段階に到達しつつある。記事生成スクリプト(generate-post.py)は、毎回「著者事実台帳」と「読了書籍リスト」を読み込んで、事実と推測を区別しながら記事を生成する。

『LLMのプロンプトエンジニアリング』(オライリー・ジャパン)や『生成AIのプロンプトエンジニアリング』(同)で学んだ「コンテキスト設計」「Few-shot」「Chain-of-Thought」の概念が、この段階でそのまま使える。特に**「スカフォールディング(足場)」の概念**——AIに判断の枠組みを与えて、その中で自由に動かす設計——は、記事生成の品質を上げるのに直結した。

第3段階:チームで回す — 評価・監視・ガードレールの設計(未到達)

『実践Claude Code入門』の後半は、チーム導入時の論点に力点が置かれている。具体的には以下の3つ:

  1. 評価設計:生成されたコードの品質をどう測るか
  2. 監視設計:どこまで自動化し、どこで人間が介入するか
  3. ガードレール:やってはいけないことをどう防ぐか

この段階は、『実践 LLMアプリケーション開発』(オライリー・ジャパン)で扱われる「プロトタイプから本番運用への橋渡し」と重なる。私はまだこの段階には到達していないが、将来的に株式会社US の業務(検査報告書生成・見積書作成・契約書管理など)を内製ツール化する際には、この設計が必須になる。

特にガードレール設計——例えば「著者事実台帳にない書籍を記事で引用しない」「未達成目標を達成済みとして書かない」といった制約——は、現在の記事生成スクリプトで部分的に実装している。これをコード生成や業務ツールにも拡張する設計が、第3段階の核心だと理解している。

まとめ:Claude Code は段階的に深化する開発リズム

Claude Code を2冊読んで実装して分かったのは、「ツール→プロンプト設計→チーム運用」の3段階を意識的に設計すると、開発リズムとして機能するということ。私は現在、第1段階から第2段階への移行期にいる。

今後は、記事生成スクリプトの精度を上げながら、業務ツールの内製化に向けて第3段階の設計を試していく。Claude Code は「コードを書かせるツール」ではなく、**「開発リズムを設計するためのプロンプトエンジニアリング基盤」**として捉えると、実務での使い方が見えてくる。

参考

関連書籍

Claude Code完全入門

Amazonで見る

楽天で見る

CLIベースの開発リズムとハンズオンが軸。ツール単体として使う段階の基礎固めに有用。

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

Amazonで見る

楽天で見る

チーム導入・Claude.md 運用・サブエージェント設計の実務論点。失敗事例の言語化が参考になった。

LLMのプロンプトエンジニアリング

Amazonで見る

楽天で見る

GitHub Copilot設計者のプロンプト設計論。コンテキスト・スカフォールディング・テンプレート化の概念地図がClaude Code運用に応用できる。

← ブログ一覧へ戻る