ハクソク

世界を動かす技術を、日本語で。

「Claude」とのリアルコードの出荷に関するフィールドノート

2025年6月8日原文(diwank.space)

概要

AI支援開発 による生産性向上の本質と具体的手法を解説。 Julep 社での実践例や Claude 活用ノウハウを紹介。 テスト記述の重要性 とAI任せにしすぎるリスクを強調。 AI活用の3モード （ドラフター・ペアプロ・バリデータ）の使い分けを解説。 大規模開発での ガードレール やドキュメント整備の意義を論述。

Vibe Codingは「雰囲気」だけではない—実践的AI開発ガイド

  • AI支援開発 で本当に生産性10倍を実現するための具体的なノウハウ
    • 単なる「魔法」ではなく、AIの強みを活かし弱点を補う実践
  • Julep 社での運用例
    • Claude を使い、本番コードを日々リリースするための体制
    • CLAUDE.mdテンプレートやコミット戦略、失敗防止のガードレール
  • テスト記述の神聖性
    • AI時代でも「自分でテストを書く」ことの重要性
    • テストを怠ると深夜のデバッグ地獄に陥るリスク
  • AI支援開発の3つのモード
    • AIファーストドラフター：初期実装生成、設計やアーキテクチャに集中
    • AIペアプログラマー：アイデアの相互作用、詳細の肉付け
    • AIバリデータ：バグ検出や改善提案、疲れ知らずのコードレビュー
  • 良い開発習慣の必然性
    • AIによる混乱を防ぐため、徹底した開発プロセスやルールの重要性
    • 厳格なチームはデプロイ頻度46倍、デプロイ速度440倍の実績

「Vibe Coding」誕生の背景と進化

  • Andrej Karpathy による「vibe-coding」ツイートが話題に
    • AIにコードを書かせて自分は「雰囲気で」過ごすという開発者の夢
  • Anthropic Sonnet 3.7 や Claude Code の登場で現実味を帯びる
    • 従来のCursorも存在したが、Claudeで本格的な「vibe-coding」体験が可能に
  • Julep 社のAIワークフローオーケストレーション事例
    • 歴史的経緯や技術的負債を含む大規模バックエンド
    • Claudeの利用には明確なガードレールが必須

Vibe-Codingの本質と3つの姿勢

  • CHOP（Chat-Oriented Programming） という新たな開発パラダイム
    • Steve Yeggeによる命名、「AIと会話しながらコードを生み出す」手法
  • 従来型コーディング ：彫刻家のように一行ずつ手作業
  • Vibe-coding ：指揮者のようにAIを導く、全体設計・意思決定は人間が担う
  • 3つのモード
    • AIファーストドラフター ：初期実装生成、設計重視
    • AIペアプログラマー ：共同作業、アイデアの相互作用
    • AIバリデータ ：コードレビュー、バグ検出やリファクタ提案
  • 開発者の役割の変化
    • ライターからエディターへ
    • システム・ユーザー・ビジネス文脈は人間が把握する必要

Vibe-Codingの実践フレームワーク

  • モード1：Playground（実験場）
    • 週末のハック、個人スクリプト、PoC用
    • ドキュメントやガードレールなし、AIが80-90%生成
    • 超高速プロトタイプ開発が可能だが、本番利用は非推奨
  • モード2：ペアプログラミング
    • 5,000行未満のプロジェクトや小規模サービス向け
    • CLAUDE.md によるプロジェクト独自のドキュメント整備
      • 共通コマンド、コアファイル、コードスタイル、テスト手順等を明記
      • プロジェクト独自のパターンや禁止事項も記載
    • アンカーコメント（AIDEV-NOTE等） でAIと人間双方へ知識共有
      • 例：AIDEV-NOTE: このコンポーネントは仮想スクロールを維持すること
      • 修正時は必ず既存アンカーの確認・更新が必要
  • モード3：本番/モノレポスケール
    • 大規模コードベースや本番環境、バグが損失につながる場面
    • Vibe-codingはこの規模ではまだ発展途上、分割統治が有効
    • 明確な境界とドキュメンテーション が不可欠
      • API契約、バージョン管理、変更時の移行計画などを厳格に管理
      • Claudeによる「改善」で本番クライアントを壊すリスク防止

まとめ：AI時代の開発者に求められるもの

  • AI支援開発 は「雰囲気」だけでなく、 厳格な習慣とガードレール が成功の鍵
  • テスト記述・ドキュメント整備・明確な境界設定 が不可欠
  • AIの力を引き出すのは、優れた人間の指揮と編集
  • Vibe-coding は今後ますます進化、だが良いエンジニアリング原則は普遍

Hackerたちの意見

AIエージェントの面白いところは、ずっと重要だと分かっていたプロセスを構築する手助けをしてくれるところだよね。でも、システムを出荷する時には優先されないことが多かったんだ。AIが何かをやることに対して不安を感じるなら、それはその何かの体系的な検証に投資する必要があるっていうサインだと思う。リンクの例で言えば、チームはデータ移行の検証とバリデーションのためのシステムを構築できる。これで、ある種の変更をAIの領域に移すことができるんだ。技術的負債についてのあいまいな話よりも、外部に説明しやすくて定量化もしやすいよね。

└

確かに。驚くほど効果的だった面白いトリックは、Claude Codeに「コードベースを見て、何か混乱することや変なことがあったら、AIDEV-QUESTION: ... というコメントを残してくれ。そうすればそのコードを文書化したり改善したりできるから」と頼むことだね。コードベースで忘れられていた本当に厄介なことを見つけたよ。

└

同意するよ。僕の直感では、ボイラープレートの相対的なコストが下がるにつれて、受け入れテストやプロパティテスト、さらには形式的検証のような高い抽象レベルの検証ツールを使うかもしれないと思ってる。

著者です：正直言って、最近はクロードコードに関する投稿が山ほどあるのは知ってる。でも、いくつかのポイントは共有する価値があると思ったんだ。例えば、Anchor Comments [1]は本当に効果的だったよ。—— # CLAUDE.md ### Anchor comments コードベースの中で適切な場所に特別なフォーマットのコメントを追加して、自分用のインライン知識として簡単にgrepできるようにしよう。 - 適切なプレフィックスとしてAIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:を使ってね。 - 重要: ファイルをスキャンする前に、まず既存のAIDEV-…をgrepしてみて。 - タスクが終わったら、関連するアンカーを更新しよう。 - ファイルやコードの一部が以下のいずれかに該当する場合は、必ず関連するアンカーコメントを追加してね： * 複雑すぎる、または * 非常に重要、または * バグの可能性がある —— [1]: https://diwank.space/field-notes-from-shipping-real-code-wit...

└

正直な質問だけど、投稿の中で人間が書いた部分と機械が書いた部分の割合って大体どれくらい？

└

Q: テストが人間だけによって書かれることをどうやって確保してるの？基本的には名誉制度ってこと？

└

ネガティブなコメントに対する対比として… LLMをたまに使う経験豊富なエンジニアとして、実際のプロジェクトでの使い方を見られてすごく感謝してるよ。なんでみんなネガティブなのか分からないけど、君はプロジェクトの構造について適切なところで詳しく話してただけじゃん。全然自己宣伝には見えないよ。君の投稿は、僕のワークフローにもっとLLMを活用しようってモチベーションを与えてくれてる。*: 彼らには僕のプロジェクトの鍵は渡さないけど、特定のタスクを完了させるのには大成功してる。

└

いい投稿だね。AIペアプログラミングにはまだ不慣れだけど（Aiderを使ってる）、20年のコーディング経験があるから、今後の展開が見えてきたよ。君が言う通り、今こそこの技術を流れに取り入れるべき時だね。もしまだやってないなら。HNの投稿がしばらく埋もれてたことについても… [1] AIを使ってコードを書く手助けをする記事が、AIを使って書かれたことで埋もれちゃうのはちょっと皮肉だね :D [1]: https://news.ycombinator.com/item?id=44214437

└

素晴らしい記事をありがとう。LLMをスケールで正しく使うために必要な情報だね。君はLLMがテストに触れるべきではないと言ってたね。その後、500以上のエンドポイントを4時間でリファクタリングする例を挙げてた。これはすごい！この4時間にはテストのリファクタリングも含まれてたのかな、それともプロンプトの時間だけだったのかな？

└

この投稿を書くのにClaude Codeを使ったの？僕は自分の文章の100%を使ってるよ。マークダウンファイルのエージェント編集がめっちゃ良くて、claude.aiのアーティファクトやchatgpt.comのキャンバスよりもずっと使いやすいからね。これを使うと、深いリサーチや他のファイルを今書いてるドキュメントに統合することができるんだ。

└

どこかで、AIによってテストが更新されたらPRを却下するって言ってたけど、どうやってそれがAIによって生成されたのか更新されたのか分かるの？記事からは、それを追加するのはgitのコミットメッセージの慣習だってことしか分からなかったけど、それもコミットレベルの話だよね。

└

いろんな投稿があるけど、これはすごく実用的で、試してみて改善できそうなシステムを教えてくれた。感謝！時間をかけて書いてくれてありがとう。一つ知りたかったのは、こういうワークフローと「aider」の使い方の違いなんだ。もしその点について何か意見があれば、教えてほしいな。

Hacker Newsで議論の続きを見る