一人開発にチーム開発の知見を転用する
このブログ（urinosuke.com と urisol.com）は Claude Code で構築している。先月『Claude Code完全入門』でCLI操作を習得したあと、次に手に取ったのが『実践Claude Code入門——現場で活用するためのAIコーディングの思考法』だ。
本書は「チームで Claude Code を導入するときの失敗と対策」がテーマで、一見すると私のような一人開発者には関係ない内容に思える。だが読み進めると、チーム開発で課題になる「認識のズレ」「暗黙知の伝達漏れ」「レビュー品質のばらつき」は、一人開発でも時間をおいて自分が書いたコードを見返すときに同じように発生していることに気づいた。
本書の核心は「サブエージェント設計」「Claude.md による暗黙知の明文化」「失敗事例の言語化」の3点。これを一人開発に転用すると、「未来の自分」を別のチームメンバーとして扱う設計になる。以下、実際に導入した3つの適用例を記録する。
Claude.md でブログ運営のルールを外部化した
チーム開発では「このプロジェクトで Claude に何を任せ、何を人間が判断するか」を Claude.md に書いておくのが推奨されている。私はこれを自社ブログの記事生成スクリプトに転用した。
具体的には、以下のルールを Claude.md として外部ファイルに切り出している：
- 著者の実体験リスト（NDT検査歴20年・個人事業主+法人併営・兵庫県姫路市在住など）
- 書いてはいけないこと（未実施収入の事実化・未取得資格の達成化・製油所名の特定など）
- アフィリエイトリンクの運用方針（もしもアフィリエイト a_id 付きURL必須・素のAmazon直URL禁止）
- 読了書籍リスト（記事で引用してよい書籍はここから選ぶ）
以前はこれらのルールをプロンプトに直接書き込んでいたが、更新のたびにコード全体を読み直す必要があり、追加ルールを入れるときに既存部分との整合性を取るのが面倒だった。Claude.md として分離したことで、「ルール更新はこのファイルだけ見ればいい」状態になり、メンテナンスコストが下がった。
本書では「Claude.md は『チームの共通認識』を保存する場所」と説明されているが、一人開発では「過去の自分と未来の自分の共通認識」を保存する場所として機能する。
失敗事例を「禁止事項」として蓄積する設計にした
本書で最も参考になったのは「失敗事例の言語化」の章だ。チーム導入時に「Claude Code が意図しない出力をした事例」を記録し、それを次のプロンプトに反映する運用が紹介されている。
私はこれを記事生成スクリプトに適用した。具体的には、過去に出力された記事で「事実と異なる記述」「未読書籍の捏造紹介」「存在しないURLの参考リンク」が発生したときに、その内容を「書いてはいけないこと」リストに追加している。
例えば以前、記事中で「小規模企業共済のセーフティネット貸付」という記述が出力されたことがある。これは制度名の混同で、正確には「セーフティネット貸付は日本政策金融公庫の制度、小規模企業共済は中小機構の制度」で別物だ。この失敗を受けて、以下の禁止事項を追加した：
不正確な制度名・運営機関名を書かない。次の混同は頻発するため特に注意：
- 小規模企業共済 / 経営セーフティ共済（倒産防止共済） → 中小機構が運営
- セーフティネット貸付 → 日本政策金融公庫が運営（中小機構ではない）
この「失敗→明文化→次回抑止」のサイクルは、チーム開発の文脈では「レビュー指摘の再発防止」として説明されているが、一人開発では「自分が見落としやすいミスパターンの事前ブロック」として機能する。
レビュー基準を自動化して「未来の自分」に委ねた
本書では「チームメンバーごとにレビュー品質がばらつく問題」への対策として、「レビュー観点をチェックリスト化し、Claude にレビューさせる」運用が紹介されている。
私はこれを記事公開前のセルフレビューに転用した。記事生成後、以下の観点を Claude に投げて自動チェックさせている：
- 著者事実台帳と矛盾する記述がないか（年齢・NDT歴・資格取得状況など）
- 読了書籍リストにない書籍を引用していないか
- もしもアフィリエイトの a_id 付きURLになっているか（素のAmazon直URLは禁止）
- 参考URLが公式サイトのトップ階層に留まっているか（存在不明の深階層PDFを書いていないか）
以前は記事を書いたあと、数日おいて自分で読み直していたが、時間を空けても同じ見落としを繰り返すことがあった（特にURL形式のミスは視認しづらい）。チェックリストを外部化して Claude に任せることで、「未来の自分」のレビュー品質が安定した。
本書では「レビューの自動化はチームの属人性を下げる」と説明されているが、一人開発では「自分の見落としパターンを補完する仕組み」として作用する。
一人開発こそチーム開発の知見が効く
『実践Claude Code入門』を読んで得た最大の気づきは、「チーム開発の課題は時間軸をずらした一人開発でも同じように発生する」という点だ。
チームで問題になる「認識のズレ」は、一人開発では「過去の自分と現在の自分のズレ」として現れる。本書で紹介されている「Claude.md による暗黙知の外部化」「失敗事例の蓄積」「レビュー基準の自動化」は、すべて「未来の自分をチームメンバーとして扱う」設計に読み替えられる。
一人開発だからこそ、チーム開発の知見を転用する価値がある。本書はその転用方法を具体的に示してくれる一冊だった。
関連書籍
実践Claude Code入門——現場で活用するためのAIコーディングの思考法
チーム導入・Claude.md 運用・サブエージェント設計の実務論点がまとまっている。失敗事例の言語化が一人開発にも転用できる。
Claude Code完全入門
CLIベースの開発リズムとハンズオンが軸。『実践Claude Code入門』を読む前に、まずこちらでツール操作を習得しておくとスムーズ。