シニア開発者の34日間Claudeコードプロジェクト：堅実なエンジニアリングと重大な盲点

プロジェクト概要

35年以上の経験を持つシニア技術エグゼクティブ（VP Engineering、CIO、Head of Software Engineeringなどの役職）が、34日間にわたる単独プロジェクトでClaude Codeを使用しました。開発者はプロダクトオーナー、アーキテクター、チームリーダーを兼務し、Claudeがすべてのコードを書きました。

技術的成果

このプロジェクトは34日間で300以上のコミットを生成しました。ClaudeとChatGPTがそれぞれ独立してコードベースをレビューし、以下の点を発見しました：

• 関心の分離がしっかりしたクリーンなアーキテクチャ
• 良好なテストカバレッジ（272のテスト）
• 「プロジェクトの段階に対して例外的」と評される徹底的なドキュメント
• 「理想的ではなく、実装されている」アーキテクチャ

プロジェクト管理アプローチ

開発者はAIアシスタントを管理するための作業規則を記したCLAUDE-mdファイルを作成しました。内容は以下の通りです：

• コードを読まずに説明しない
• 許可なく進めない
• 修正前に診断する

この管理文書は、レビュアーから「私が見た中で最高のAIコーディングアシスタント管理文書の一つ」と呼ばれました。Claude Codeの管理は「非常に速く、非常に文字通りなジュニア開発者を管理しているよう」だと感じられました。

プロジェクト：文書変換パイプライン

このプロジェクトは、5つの段階からなる複雑な文書変換パイプラインでした：

1. ウェブページからコンテンツを抽出
2. コンテンツをサニタイズ
3. 構造化モデルに解析
4. アクセシブルなHTMLとしてレンダリング

当初のコンセプトは、開発者が自身のアプリに組み込めるCLIとライブラリでした。

重要な見落とし

開発者はFirefoxのReader Mode抽出エンジン（Readability.js）の存在を知っていましたが、「これはスタンドアロンライブラリとしても使えるのか？」と質問することはありませんでした。代わりに、ブラウザ機能としてのみ見ていました。この単純な質問で以下のことが明らかになったはずです：

• 難しい部分は既に解決済み
• 真の価値（タイポグラフィ、テーマ、アクセシブルな出力）は既存エンジンの上に構築されるブラウザ拡張機能になり得る

開発者自身のエンジニアリングルール「既存の解決策があるものは決して作らない」にもかかわらず、開発者もClaudeもこの代替アプローチを提示しませんでした。

ユーザーインターフェースの転換

ターゲットユーザー（保護者、教師、学生）はCLIやパイプラインを使えませんでした。開発者は最初にフィードバック用のシンプルなHTMLテストページを試しましたが、その後完全なウェブインターフェースを構築しました：

• 8日間で100以上のコミット
• 5つのテーマ
• レスポンシブデザイン
• ブランディングとデプロイメント

このインターフェースは単なるフィードバック手段ではなく、プロダクトそのものになりました。

テストインフラの拡張

このプロジェクトでは広範なテストインフラが開発されました：

• 16の品質指標を持つ評価ハーネス
• 4,000以上のウェブページに対するベンチマーク
• 比較パイプライン
• スクリーニングツール

累積効果として「製品コード1行に対してテストインフラ5行」という比率になりました。

開発者体験

開発者は次のように報告しています：「Claude Codeでの作業は、再びチームを管理しているようでした。問題を解決するためのブレインストーミング、アーキテクチャの決定、高速で物事がまとまっていくのを見ること。まるでジャスティスリーグが私のコードを書いているようでした。」

しかし、これは罠も生み出しました：「自分が正しい道を進んでいるかどうかについての不安がよぎるたびに、別の印象的なものを構築することでそれを押しのけることができました。作業の質自体が継続する正当化理由になりました。」

ユーザーフィードバックは34日間のうち30日目にのみ収集されました。