Claudeで実際にコードをデプロイして得た実戦ノート

 (diwank.space)
77 ポイント 投稿者 GN⁺ 2025-06-09 | 7件のコメント | WhatsAppで共有
  • AIツールであるClaudeを実際のサービスに適用し、開発生産性を10倍向上させる現実的な達成方法と活用ノウハウを整理している
  • 「vibe-coding」は単なる流行ではない実践的な方法論であり、正しい開発習慣とインフラを整えればAIの強みを最大化し、弱みを補える
  • AIの役割を「草案作成者」「ペアプログラマー」「コードレビュアー」の3つのモードに明確に分け、それぞれの段階に応じたドキュメント化とガードレールが不可欠だとしている
  • 核心は、プロジェクトごとにCLAUDE.mdファイルを活用して、規約、アーキテクチャ、パターン、禁止事項などを明確に文書化し、コード内のanchor commentでAIを効果的にガイドすること
  • テストコードは必ず人間が作成すべきであり、AIがテスト・マイグレーション・セキュリティ・API契約・シークレットなどの重要領域を修正できないよう、境界を厳格に設定すべきだとしている
  • 適切な境界と習慣のもとでAIコーディングを導入したチームは、デプロイ頻度・安定性・開発速度をすべて大幅に改善でき、実運用のノウハウやパターン共有がAI開発文化の中核になりつつある

Vibe Coding Isn’t Just a Vibe

  • この記事は、AIを活用した新しいソフトウェア開発手法の現場ガイドであり、単なる使い方ではなく、実際に効果的なAI開発が成立する「理由」まで説明している
  • 神話のように語られてきた10倍の生産性向上も、AIの強みを最大化し弱みを補う実践的な習慣があってこそ可能であることを、実例を通して示している
  • 実際に稼働中のJulepのコードベースをもとに、CLAUDE.mdテンプレート、コミット戦略、運用上の災害を防ぐガードレールなど、実践的なインフラと運用ノウハウを公開している
  • とりわけテストコードは必ず自分で書くべきであり、AIに過度に依存すると深刻な障害やデバッグの悪夢を招きうる
  • AI開発には**3つのモード（草案作成、ペアプログラミング、レビュアー）**があり、状況に応じてAIに主導権を与えるか、人間が直接調整するかのリズムと原則が異なる
  • 核心となるメッセージは、良い開発習慣と境界があってこそAIは能力を増幅するということであり、実際の研究結果も「徹底した開発習慣を持つチームが、デプロイ速度と品質の両面で圧倒的に優位に立つ」ことを示している

なぜこの記事を書くことになったのか：ミーム（Meme）から実戦的方法論（Method）へ

  • AIにコードを書かせ、開発者は「雰囲気に乗るだけ」だという概念（「vibe-coding」）は、もともとAndrej Karpathyの冗談めいたツイートから始まった流行だった
  • 当時の開発者コミュニティは、「AIが代わりに働き、私たちはコーヒーでも飲んでいればいい」という究極のファンタジーとして笑い話にしていた
  • しかし、AnthropicのSonnet 3.7とClaude Codeの登場以後、この冗談は実際に可能な現実へと変わり始めた。Cursorのような既存ツールもあったが、Claude Codeは本当に「バイブコーディング」らしい感覚をもたらし始めた
  • 筆者が所属するJulepは、膨大なコードベース、多様な設計パターン、さらには技術的負債まで抱えている。コード品質とドキュメント化は徹底して維持しているが、各部分の意図や履歴を把握するだけでも数週間かかるほど複雑だ
  • Claudeをガードレールなしで使うと、やる気だけはあるインターンがあちこちでミスを犯すような混乱が起きる
  • この記事は、そうした試行錯誤や深夜3時のデバッグ、実際のサービス運用の中で生き残った本物の実践パターンとノウハウだけを整理して共有するものだ

バイブコーディング（Vibe-Coding）の本質

  • Steve YeggeがCHOP（Chat-Oriented Programming）という用語を作ったように、「バイブコーディング」はAIと対話しながらコードを完成させる新しい開発手法である
  • 伝統的なコーディングが大理石を彫刻するように1行ずつ慎重に作り上げる作業だとすれば、
    • バイブコーディングはオーケストラの指揮者に近く、AIは原石（基本的なコーディング能力）を提供する演奏者である
    • 開発者は全体の方向性と構造を設計し、AIがその流れに沿ってコードへ落とし込む
  • バイブコーディングの3つの姿勢（Postures）
    • 1. AIを草案作成者として活用する（First-Drafter）
      • アーキテクチャや設計に集中し、反復作業（CRUD、ボイラープレートなど）はAIが素早く生成する
      • 考える速度でコードを書くジュニアエンジニアがいるような感覚だが、継続的なガイドが必要
    • 2. AIとペアプログラミングする（Pair-Programmer）
      • 最も実用的で効果的なモード
      • 開発者とAIがアイデアをやり取りし、大枠は人が描き、詳細実装はAIが埋める
      • 豊富なプログラミング知識はあるが、実際のデプロイ経験がない同僚とペアを組むような感覚
    • 3. AIを検証者／コードレビュアーとして活用する（Validator）
      • 人が書いたコードをAIがレビューし、バグ・改善点・見落としたパターンを提案する
      • 決して疲れず、細部まで気を配るレビュアーの役割を果たす
  • 重要な洞察: 開発者の役割は「作家」から「編集者」へと移る。すべてのコードを自分で書く代わりに、AIが生み出した成果物をレビュー・修正・方向づけする。
  • ただし、全体アーキテクチャと文脈は人間が必ず主導しなければならず、AIは「百科事典的知識を持つインターン」にすぎず、私たちのサービスやビジネスの文脈は理解していない

バイブコーディング3つの実戦モード：フレームワーク

数か月の実験と実際のデプロイ事故を経て、バイブコーディングには、それぞれ異なるリズム、ガードレール、最適な用途を持つ3つのモードがある

  • モード1: Playground（実験／プロトタイプ／個人プロジェクト）

    • 使う場面: 週末ハック、個人スクリプト、PoC、思いつきのアイデア検証など
    • 特徴: 設計・文書・ガードレールなしで、AIがコードの80〜90%を書く。アイデアから成果物まで数分で到達するスピード
    • リスク: 本番サービスや重要コードには不向き。遊びや実験用途に限るべきで、エンジニアリング原則はむしろより重要になる

  • モード2: Pair Programming（実利用・小規模サービス）

    • 使う場面: 5,000行以下のプロジェクト、実ユーザーのいるサイドプロジェクト、デモ、小規模モジュールなど
    • 核心: プロジェクトの慣習・アーキテクチャ・パターン・テストガイドなどを**CLAUDE.md**で一度に明確に定義する
    • 利点: 新しい開発者をオンボーディングするように、Claudeへ一度説明するだけで一貫したコード生成が可能になる
    • 実践ポイント:
      • コードの各所にanchor comment（AIDEV-NOTE、AIDEV-TODO、AIDEV-QUESTION など）を入れて、Claudeが文脈を見失わないようにガイドする
      • こうしたコメントはAIと人間の双方が参照できる指針として機能し、CLAUDE.mdには管理基準や例まで明記する

  • モード3: Production/Monorepo Scale（大規模サービス）

    • 使う場面: 数十〜数百人規模の開発、実ユーザーのいる大規模サービス、1回のミスで大きな被害が発生しうる状況
    • 注意: 現時点（2025年6月）では、大規模な一括バイブコーディングはまだ完全にはスケールしない
    • 原則: 個別サービス／サブモジュール単位でバイブコーディングを導入することを推奨し、すべての統合ポイント（API・DBなど）に明確な境界とバージョン管理を設け、主要インターフェースやAPIには変更注意コメントを必須にする
    • 実践例:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • このような境界線がなければ、Claudeが勝手に改善を進めた結果、実際のサービス全体を壊しかねない
  • 結論: 大規模プロジェクトでは、バイブコーディングを段階的に、分離されたサービス単位で導入し、必ずドキュメント化・ガイドライン・レビューといった従来の原則を並行して運用してこそ、信頼性を確保できる

インフラ中心の持続可能なAI開発環境づくり

  • CLAUDE.md: AIと人間の両方のための単一の真実（The Single Source of Truth）

    • CLAUDE.md は、すべてのプロジェクトルール、アーキテクチャ、注意事項、コードスタイル、禁止対象、ドメイン用語集などを体系的に盛り込む「憲法」の役割を果たす
    • AIと新しいチームメンバーが共有する「知識の骨格」として機能し、具体的なガイドラインと禁止事項を例とともに手間をかけて管理する
    • 優れたCLAUDE.mdに投資するチームほど、より良い結果を生み出す
    • 私たちの本番 CLAUDE.md を参照
    • コードベースが大きくなるほどCLAUDE.mdだけでは不十分で、コードの各所に anchor comment（AIDEV-NOTE/TODO/QUESTION など）を置いてローカルコンテキストを明確に伝える必要がある
    • コードベースを都市にたとえるなら、anchor comment は AIと人間のどちらも道に迷わないようにする標識
    • こうしたコメントは単なるコード説明を超えて、「なぜ」このように動作するのかというストーリーを残す

  • Gitワークフロー、AIコードの体系的管理

    • AIによるコード生成速度が上がるほど、管理を誤ると git の履歴が汚染されるおそれがある
    • git worktree 方式 などでメインブランチから分離したAI実験用スペースを用意し、コードは自由に生成しつつ、記録は体系的に分離・管理する
    • コミットメッセージには AIの関与内容 を必ず明記し（[AI] タグの活用など）、レビューアが追加で注意深く確認できるようにする

不文律: テストコードは必ず人間が書く

  • AI支援開発で最も重要な原則: 「テストコードは絶対にAIに任せないこと」
  • テストは単に動作確認のためのコードではない
    • 実際の問題の文脈、エッジケースの認識、ビジネス要件の解釈、ドメインに対する人間の理解と経験が染み込んだ 実行可能な仕様 である
    • 速度と安定性のどちらも取りこぼさない優秀なチームは、まさにこのテストを徹底して人間が管理している
  • AIが自動生成したテストは表面的な経路（happy path）しか検証せず、予期しない重大な問題（例: メモリリークなど）を見落とす
  • 私たちのチームでは AIがテストファイルに手を加えた場合、PRは自動却下（例外なし）
  • テストはコードの仕様であり安全網であり、蓄積されたすべてのバグとエッジケースの知恵
  • 必ず人の手で作成し、AIが触れられないよう強力に保護しなければならない

スケールとコンテキスト管理: トークン経済とコンテキスト最適化

  • AIコード開発でよくあるミス:
    「トークン節約」のためにコンテキスト（プロンプト、要件、環境など）を最小化すると、かえって反復作業が増え、全体のトークン消費も増加する
  • 適切なコンテキストの提供が長期的にはより効率的
    • 「最小」ではなく 「関連性があり十分なコンテキスト」 を最初に与えることが重要
  • 悪い例: コンテキスト不足のプロンプト "Add caching to the user endpoint"
    • Claude は単純なインメモリキャッシュにし、無効化戦略やモニタリングがなく、マルチサーバーも考慮せず、キャッシュスタンピード対策もない
    • 結果として 3回以上の修正を繰り返し、合計で4倍以上のトークンを消費する
  • 良い例: コンテキストが豊富なプロンプト 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* エンドポイントのトラフィックは毎分5万 req、APIサーバー12台、データ変動は少ない  
* 既存のRedisインフラの場所、標準キー・パターン、Prometheusベースのメトリクス要件  
* キャッシュアサイドパターン、TTL 1時間、キャッシュスタンピード防止（確率的早期失効）  
* キャッシュガイド文書を参照
    • 最初から具体的なコンテキスト を提供することで、反復なしに正確な実装が可能になる
  • 結論:
    • 「トークンは良いツールへの投資だ」
    • あらかじめ十分なコンテキストを入れておけば、長期的には反復と修正が減り、コストを節約できる
  • 実践的なヒント: すべてのプロジェクトで、コード変更のたびに Claude にコードベースの変化と関連コンテキストを CLAUDE.md に更新するよう依頼する

セッション管理とコンテキスト汚染の防止

  • 作業ごとにClaudeセッションを新しく始める ことが重要
    • 1つの長い会話に複数の作業（例: DBマイグレーション、フロントエンドデザインなど）を混在させると、コンテキストが混ざって意図しない結果を招く
  • ルール: 1作業 = 1セッション、完了時に新しいセッションを開始
    • Claude の「メンタルモデル」を常にクリーンで集中した状態に保つ
    • まるで生の鶏肉用と野菜用のまな板を分けて使うようにコンテキストを分離する

実践事例: エラー処理構造の転換

  • 実際に 500+ エンドポイントにおける ad-hoc なエラー処理方式を 構造化されたエラー階層（hierarchy） に置き換えた事例を紹介
  • 人間（アーキテクト）が事前に中核設計（SPEC.md/要件/エラー分類）を書き、Claudeが実際の大量コード変換（機械的作業）の実行役 を担う方式
  • アーキテクチャ原則と具体的な仕様、設計文書の例示・概念導出 -> AIへの明確な作業指示 -> 正確に4時間以内で全体のリファクタリングを完了した経験

AI時代のリーダーシップと組織文化

  • シニアエンジニアの役割は 自らコードを書くことから、知識のキュレーション・境界設定・AIと人間の両方を導くことへ と進化する
  • リーン（Lean）マネジメント、継続的デプロイなど現代的な開発文化は、AI協業の管理においてもそのまま重要である

  • 新規入社者オンボーディングチェックリスト（人間 + AI協業の分離）

    • 1週目: 基礎固め
      • チームのCLAUDE.md（共通/サービス別）を読む
      • 開発環境をセットアップする
      • 最初のPRを提出する（100%自分でコーディング、AI禁止）
    • 2週目: AI協業の実習
      • Claudeにチームテンプレートを適用し、設定する
      • 「おもちゃ問題」をAIと一緒に解く
      • プロンプトパターンを練習する
      • AI支援による最初のPR（メンター/シニアと一緒に）
    • 3週目: 独立した実務
      • AI支援で主要機能を開発・デプロイする
      • 同僚のAIコードに対して自らテストを書く
      • コードレビューセッションを1回主導する

透明な文化を築く : AI活用の積極的な公開

  • すべてのAI活用コミットには、以下のように コミットメッセージタグ で明確に表示する 
    feat: add Redis caching to user service \[AI]  
# \[AI] - 50%以上をAIが生成, \[AI-minor] - 50%未満, \[AI-review] - レビューのみにAIを使用  
# AIがキャッシュ/クライアントコードを作成し、キャッシュキー設計/テスト/検証は人間が担当
  • 効果
    1. レビューアがAIコードに特別な注意を払える
    2. デバッグ時にコードの出所を把握しやすい
    3. AI利用に対する恥や隠蔽の文化をなくし、「責任を持ってAIを使う」というチーム文化を確立する
  • 誰もが気兼ねなくAIを活用し、高い成果を出す文化に貢献できるよう、積極的な公開と文化的な仕組みが重要

Claudeの禁止事項: AIはここには絶対に手を出してはいけない

  • テストファイル/データベースマイグレーション/セキュリティの中核コード/API契約（バージョン管理なし）/環境設定およびシークレット などは、AIの自動化を絶対に使用してはならない
  • ミスの等級別（フォーマット・依存関係からビジネス中核領域のデータ破壊まで）に区分し、高リスク領域には追加の強制ガードレールを適用することを強調
  • AIのミスのリスク等級（Hierarchy of AI Mistakes）
    • Level 1: 面倒だが致命的ではない
      • フォーマットエラー（リンターで検出される）
      • 冗長なコード（後でリファクタリング）
      • 非効率なアルゴリズム（プロファイリング時に発見）
    • Level 2: コストの高いエラー
      • 内部API互換性の破壊（チームでの調整が必要）
      • 既存パターンの変更（混乱を招く）
      • 不要な依存関係の追加（コードの肥大化）
    • Level 3: キャリアに致命的（Career-Limiting）
      • テスト結果を合わせるためにテスト自体を修正する
      • API契約の破壊
      • シークレット/個人情報の流出
      • データマイグレーションの破損
    • ミスのレベルに応じてガードレールの水準も変えるべきであり、Level 3のミスはキャリアにも重大な脅威となる

開発の未来: これからの変化と方向性

  • 2025年現在、AI支援開発は思春期の若者のように強力だが、まだぎこちなく粗削り
  • しかし、成長曲線は明確に「加速」している
  • 優れたドキュメンテーション（Documentation）は、AI時代のDevOps実装における中核インフラ
    • ドキュメントはもはや「参考資料」を超え、人間の意図とAIの実行の間にある直接的な「インターフェース」
    • 高成果チームは、テストと同じくらい CLAUDE.md などのドキュメント管理を徹底している

  • 今後予想される変化

    • コード全体の文脈を理解するAI
      • ファイル単位ではなく、サービス/システムレベルまで把握
    • セッション・プロジェクトをまたぐ持続的メモリ
      • 会話と作業コンテキストを長期的に記憶・活用
    • 積極的に改善提案を行うAI
      • 依頼がなくても問題点・改善点を先回りして診断
    • チームごとのパターン・好みを学習するAI
      • 組織固有のスタイル/慣習に合ったコードを自動生成
  • しかし、基本は変わらない:
    • 方向を定めるのは人間、実行とてこはAI
    • ツールがいくら強力になっても、私たちは依然として「ツールを使う人」である

結論: 今、ここで始めよう

  • ここまで読んだなら、期待と同時に少しの不安も感じているはず
    • その反応は正常で、AI支援開発は強力だが「意図的で体系的な実践」が必須

  • 今日すぐ実践できるアクションプラン

    • 今日
      • 1. 現在のプロジェクトに CLAUDE.md ファイルを作る
      • 2. 自分が最も複雑だと思うコードに anchor comment を3つ直接追加する
      • 3. 明確な境界（ガイド）の下でAI支援機能を1つ試す
    • 今週
      • 1. チーム単位でAIコミットメッセージのルールを作る
      • 2. ジュニア開発者と一緒にAIコーディングセッションを1回実施する
      • 3. AIが作ったコードについて自分でテストコードを書く
    • 今月
      • 1. AI導入前後のデプロイ頻度の変化を測定する
      • 2. チーム内の反復作業向けプロンプトパターンライブラリを構築する
      • 3. チーム全体でAI協業のレトロスペクティブミーティングを行う
  • 核心は「今すぐ、小さく、慎重に、しかし必ず始める」こと
  • この流れを早くマスターした開発者は、より賢いからではなく、
    • より早く始め、より多く失敗しながら学んだから
  • ソフトウェアデプロイの成果は、そのまま組織の成果を左右する
    • 速度と品質が競争力である時代、AI支援開発は選択ではなく「必須の能力」
    • ただし、正しい方法で取り組まなければならない
  • バイブコーディングは冗談のように聞こえるが、
    • 人間の能力を増幅する真剣な開発手法
    • ツールとパターンはすでに十分に整っている
    • 今や、誰がオーケストラを指揮するのか、誰が一人ですべての楽器を演奏するのかを選ぶ時だ

実践資料とおすすめリソース

関連記事

7件のコメント

 
softychoco 2025-06-16

今日書いた投稿が、その内容とかなり近い視点ですね。
結局のところ、AIを通じて生産性を高め、低下した安定性を引き上げるような組織構造へと変えていくことが核心でした。

https://softycho.co/57
 
kimjoin2 2025-06-09

AIの助けを借りるコーディングを意味する vibeコーディング の vibe がどういう意図なのか、いまだによく分からない。
雰囲気？ 感覚？ 相性？ AIとの関連もないし、
トゥントゥントゥン・サフール級に文脈なく感じられる。
 
analogstar 2025-06-11

ナムウィキによると
「バイブコーディング(Vibe Coding)とは、開発者が生成AIの助けを借りてコードを作成する行為を指す新語で、プログラミングを行う際に事前の厳密な論理や設計に基づくのではなく、直感や感覚に依存するという意味から『バイブ』コーディングという名前が付いた」とのことです。笑
 
hohemian 2025-06-09

頭を空っぽにして、流れに身を任せましょう。
すべてのロジックはAIが組んでくれます。
Tabキーを連打するだけです！
 
secret3056 2025-06-09

> look and feel👀🎵🎷。理解しようとせずに🧠 感じてください！😊

同じ感じですよね
 
humblebee 2025-06-09

ああ、そうなんですか？ 私は聞いた瞬間にぴんと来ましたが……
そう言われると、最近は非開発職の人でもよく理解している「ハードコーディング(hard-coding)」という用語を思い出します。
この言葉も、最初は単語そのものだけでは何を意味するのか分かりにくいですが、開発を学んでいくうちに、結局それが何を意味し、どんな意図なのかをみんながよく理解している、そういう「感覚」とでも言うのでしょうか。 はは
 
GN⁺ 2025-06-09
Hacker Newsの意見

  • 記事執筆者の立場としては、最近Claudeコード関連の記事があふれている状況の中で、私たちが見つけたいくつかの重要なポイント、特にAnchor Commentsには共有する価値があると判断して書き残したものです。
    Anchor Comments方式は、コードベースのあちこちに特殊フォーマットのコメントを残しておき、必要な知識をすぐにgrepして見つけられるようにする仕組みです。
    例として、AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:のようなプレフィックスを使います。
    ファイルを検索する前に、まず既存のAIDEV-…があるかを必ずgrepするというルールです。
    作業が終わったら、そのanchorを更新することが必須です。
    コードファイルやコード片が複雑すぎる場合、とても重要な場合、あるいはバグがありそうだと判断した場合には、必ずanchorコメントを残します。
    参考例はこちらで確認できます。

    • とても経験豊富なエンジニアとして、LLMは体系的にではなくたまに使う程度なのですが、実際のプロジェクトでLLMをどう本番投入しているのかを詳しく見られてかなり有益でした。
      他の人たちがなぜそこまで否定的なのか理解できない部分があります。
      自分のワークフローでもLLM活用度をもう少し高めてみたくなる体験でした。
      もちろんLLMがプロジェクトの鍵を握っていたわけではありませんが、特定の作業を任せて成功した例はかなり多い状況です。

    • 最近この手の記事は多いですが、これは実用性が高く、自分にも適用できそうなシステムのアイデアを示してくれました。
      aiderのようなツールを使う場合とこのワークフローの違いが気になります。もし著者の視点があれば聞いてみたいです。

    • 素晴らしい記事のおかげで、大規模なLLM活用法を理解するのに大いに役立ちました。
      「AIにはテストを絶対に触らせない」と言っていたのに、続いて500個を超えるエンドポイントのリファクタリングを4時間で処理したという点が印象的でした。
      この4時間にはテストのリファクタリングまで含まれているのか、それともプロンプトに費やした時間だけなのかが気になります。

    • テストがAIによって更新された場合はPRを却下するというルールに触れていましたが、実際にAIが生成または修正したとどうやって確認しているのか気になります。
      記事ではgitのコミットメッセージのルールで判別するとありましたが、これもコミット単位でしか機能しない状況ですよね。

    • 記事執筆にClaude Codeを使ったのか気になります。
      自分では最近、文章を100% Claude Codeで書いているのですが、Markdownファイルをエージェントが直接編集する効果が高く、claude.ai artifactsやchatgpt.com canvasよりずっと生産的だと感じています。
      そのおかげで、研究資料や関連ファイルを文書に深く統合するのがとても簡単になっています。

  • AIエージェントの面白い点は、普段は重要だと思っていても実際にはシステムのデプロイを前に優先順位が下がっていたプロセスを、本当に実行させるようになることです。
    AIが自分の代わりに何かをすることに不快感を覚える度合いを、「システム的な検証に時間を投資すべき指標」として活用するという裏技を使っています。
    リンク先のようにデータ移行の検証システムを構築すれば、関連するあらゆる変更も自然にAI活用の範囲に入れられます。
    抽象的な「技術的負債」の話より、こういう具体的な形のほうが外部に説明しやすい利点を感じます。

    • 本当にその通りだと共感しますが、私が見つけたもう一つの有用なトリックは、Claude Codeに「コードベースを見回して、わかりにくいところ、変なところ、直感に反するところがあればAIDEV-QUESTION:コメントを残してほしい」と頼む方法です。
      予想外に複雑で忘れられていたコードのおかげで、重要な箇所を再発見できた経験があります。

    • 直感的には、抽象度の高い検証ツール、たとえばacceptance test、property test、formal verificationなどをもっと頻繁に使うようになる可能性が高いと思います。
      LLM活用によってボイラープレートのコストが相対的にかなり下がった環境ですから。

  • 読みながら新しいことを学びました。
    最近Sonnet 4をCursorとWebで使ってみたのですが、何かを雑に処理したり、結果を誤解して報告したりすることが多くて困っています。
    しかもプログラミング以外の分野でも病的なくらい間違ったことを言う感じがあります。
    Anthropicのレポートで見た通り、「削除するぞ」のような警告も効果がなく、使用後にモバイルアプリでフィードバックが送れない問題まで経験しました。
    他の人たちはClaude関連の問題がないようですが、もしかして自分だけなのでしょうか。

    • 最近のアップデートでAIの能力を弱めすぎたような印象があります。
      3.5まではテキスト分析、要約、短文作成などの簡単な作業には十分でしたが、4以降は同じコンテキスト内で3〜4回以上まともに指示に従えない状況です。
      「簡潔にと言ったのになぜまた冗長に説明するのか」と聞くと、デフォルト設定のせいで命令を無視すると答え、「有害な情報」は最初から避けようとする傾向まで見せます。
      何度か論理的な穴を指摘すると、自分で信頼性が低いと認めることもあります。
      むしろ賢くなりすぎて問題が押し寄せたのかと思うほどで、Anthropicが間違った方向に進化させてしまったのなら残念です。

    • 上で言った問題は全部実際に経験した側です。
      Webではかなり具体的に依頼すると多少マシですが、それでも生成されたコードの半分にはまだ誤りが混じっています。

  • ドキュメント化のコツを読んで感じたのは、実はこうしたルールは必ずしもAIのためだけではなく、普通のコーディングにも適用できるということです。
    CLAUDE.mdの代わりにCONVENTIONS.md、AI向けコメントの代わりにREADER向けコメントを残しても同じように有用です。
    慣れていないコードベースに新しく貢献するとき、こういうコメントがあればかなりありがたい立場です。

    • aiderで実際に試してみたところ、かなりうまく動いた経験があります。
      飛行機を待ちながら、PDFビューアと描画機能まで入れたコードを30分で完成させたことがあります。

    • 元記事の著者ではありませんが、実際にはClaudeに役立つコメントと人間に役立つコメントではスタイルがかなり違います。
      人間向けのスタイルガイドは普通100行程度で、「inputを変更する関数には必ず!を付ける」といった簡単なルール中心です。
      Claude向けガイドは500行以上書いており、各ルールごとに「こうしろ、ああするな」という例をたくさん含めてようやく効果が出る感じです。

  • 記事を書いてくれてありがとう。
    多くの開発者が、LLMに仕事の統制権を一部渡すときに感じる不安や、従来の形式的で厳格な開発手法ではなく実験的あるいは非構造的なアプローチのように見えるという相反する悩みを抱えている点に共感します。
    それでも、LLMを活用してはるかに速いスピードで問題を解決しようとする「目標中心の最適化」が、実際に実現可能な中間地帯を作っているのだと思います。
    実装の細部に入り込みすぎて本来の目標を見失うことがよくありますが、LLM活用はそうしたミスを減らすのに役立つという考えです。

    • その通りです。
      私はLLMを未完成のレバーのようなものだと見ています。まだ粗くてミスも多いですが、学びながら使う価値は十分あります。
      ずさんなエンジニアリングを正当化する言い訳にしない範囲で、本当に使える道具へ進化させようとする努力が重要だという見方です。

  • 記事の一番上にある2.3MBの画像は、Wi‑Fi環境でも冗談みたいにとても遅く読み込まれました。

  • いくつか思ったことがあります。

    • LLM関連のプロンプトや仕様を、コードベース内でもっと洗練された形で整理する方法があるのか気になります。
      CLAUDE.md、SPEC.md、AIDEVコメントが増えてくると扱いづらくなりそうです。

    • 最近のvibe-codingの定義は何なのか気になります。
      Karpathyの言う「カウボーイモード」のようにコードを見ずにdiffを全部受け入れることから、最近ではLLMワークフロー全般を含む意味に変質したように見えます。

    • 他人のLLMにコードを送るとき、ソースコードの難読化をするのかも気になります。

    • コメントが増えると本当にすぐコードが複雑になるのは事実です。
      そのため、これを可視化してgutterに小さなインジケーターとして表示するVS Code拡張を自作しています。
      vibe-codingの意味は人によって違いますが、個人的には完璧な解決策ではなく、いろいろな問題に遭遇しました。
      3.7 SonnetとCodexは60%くらいの成果でしたが、Opus 4は実際かなり効率的だと感じました。
      コード難読化については、本文の例はもともと全部オープンソースなので大きな問題はありませんでした。

  • とても興味深く、自分のCLAUDE.mdファイルにも適用してみるつもりです。
    「トークンを節約しようとしてコンテキストを削るのは、かえって逆効果になる」というAI開発の逆説的な教訓に同意します。
    より大きなプロジェクトや複雑なコードでは、Claude OpusとSonnetの性能差が実際かなり大きく表れることを体感しています。
    Sonnetは、やらなくていい試みばかり繰り返して、むしろ状況を悪化させることがよくありました。
    結局、MaxサブスクのユーザーにとってOpusとSonnetをわざわざ区別する必要があるのだろうかと思います。
    Sonnetが10〜20回のやり取りを要するところを、Opusは2〜3回で終わらせることがあり、長期的にはむしろSonnetのほうがコストを押し上げる使い方になっています。

    • Maxサブスクには2つのティアがあり、$100はProの5倍のトークン、$200は20倍のトークンを提供します。
      トークン計算は簡単ではなく、ハイブリッドモードではOpusトークンが20%残るまではOpusを使い、その後Sonnetへ自動的に切り替わる仕組みです。

  • よく書かれた記事ですが、「テストは絶対にAIに任せるな」という部分には異論があります。
    私は最近、すべてのテストをAIに書かせて、自分で丁寧にレビューしています。
    新しいコードなら、AIにテストまで任せてこそ高い自律性が可能です。
    AIにテスト実装と通過を明確に指示し、そのうえでAIが開発している最中にすぐレビューし、不足しているテストケースは追加する形で運用しています。

  • 内容の大半には同意しますが、Claudeにテストやマイグレーションをまったく触らせない方針には賛成できません。
    テストを自分で書くのが一番嫌いな作業なので、LLMが最低限の草案だけでも作ってくれればかなり助かります。
    重要なのは、生成主体に関係なく最終的な所有権と責任は常に人間にあることです。
    メッセージのニュアンスからすると、著者はClaudeへの信頼が足りないか、あるいは社員がAIの成果物を無批判に受け入れないようにする意図が強いように見えます。
    もしくは、テストやマイグレーションに関する厳格なルールがなければ、本当にコードが壊れたりデータ損失が発生したりする現実的な可能性があると判断しているのだと思います。

    • それも一理ありますが、私の経験では大きな問題に遭遇したことがあります。
      1. 生成されたテストを後から人間が手で直すとき、本当に深刻な落とし穴が多くありました。
      2. Claudeは文脈をよく理解していないので、ほとんど何でもmock化してしまい、私たちのサービスやビルド環境から完全に乖離したテストをよく生成します。
      3. そしてさらに大きな問題は、チーム全体がテストに対してあまりに怠惰になることです。
        実際、本番環境でのバグは大きく増えました。