ハクソク

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

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

352日前原文(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」の使い方の違いなんだ。もしその点について何か意見があれば、教えてほしいな。

数日前に、個人プロジェクトでこのクロードコードを試してみることにしたんだ。すごく効率的だけど、めちゃくちゃ高い。1日で10ドル以上使っちゃったよ。でも、これは避けられないと思う。AIの支配者に税金を払わないと、仕事を続けられない気がする。

└

アンスロピックがクロードコンソールとクロードコードをバンドルした$100と$200のマックスサブスクリプションを発表する前は、年間$2,000を見てたんだけど、今は上がってる。5時間ごとの制限はあるけど、ログイン/コマンドでメーター制のAPIに戻すこともできるし、犬の散歩に行くこともできる。月$100で十分やっていけてるよ。

└

これについて考えてたんだ。すごく安い国の開発者たちは、月額がClaudeよりもまだ安いから、魅力的な選択肢として残るのかな。

いくつかの考え： - コードベースでLLMのプロンプトや仕様を整理するもっとエレガントな方法はないのかな？CLAUDE.md、SPEC.mds、AIDEVコメントはすぐにごちゃごちゃになりそう。 - 最近の「バイブコーディング」の定義って何？元々のカーパシーの引用、つまりカウボーイモードのことだと思ってたけど、今は「バイブコーディング」がLLMのワークフロー全般を指すキャッチオールのクリックベイトになってるみたい。（正直、この「クロードでリアルコードを出荷する」ってタイトルは悪くないけど） - 誰かのLLMに送る前にコードを難読化することってある？

└
  • コードベースでLLMのプロンプトや仕様を整理するもっとエレガントな方法はないのかな？CLAUDE.md、SPEC.mds、AIDEVコメントはすぐにごちゃごちゃになりそう。 そうだね、コメントがどんどん積み重なっていくよね。今、コメントを自動的に小さなビジュアルインジケーターに変えるVSCodeの拡張機能を作ってるんだ。 > - 最近の「バイブコーディング」の定義って何？元々のカーパシーの引用、つまりカウボーイモードのことだと思ってたけど、今は「バイブコーディング」がLLMのワークフロー全般を指すキャッチオールのクリックベイトになってるみたい。（正直、この「クロードでリアルコードを出荷する」ってタイトルは悪くないけど） 誰に聞くかによると思うけど、私にとっては万能薬ではなくて、問題にぶつかることが多かったよ（3.7ソネットとコーデックスは約60%の成功率だけど、オーパス4は実際にかなり良い）。 > - 誰かのLLMに送る前にコードを難読化することってある？この場合、最初から全部オープンソースだったけど、考えるべき良いポイントだね。

モデル特有のコメントが多くて視覚的にノイズが多いね。もしくは、ここにある例だけかもしれないけど。でも人間としては、CLAUDE.mdファイルは好きだな。開発者の思考過程や選択についてのドキュメントみたいでいい感じ。これって、開発者が作業中にLLMチャットを開いている旧スタイルのコードベースより速いのかな？学習曲線が上がる気がする。ここにあるコードはあまり親しみやすく見えないね。

とても興味深いね。これらのアイデアをCLAUDE.mdファイルに使わせてもらうよ。 > AI支援開発における最も直感に反する教訓の一つは、トークンを節約するためにコンテキストをケチると、実際にはもっとコストがかかることだ。 最近考えてたことに似てるけど、大きなプロジェクトや複雑なコードの場合、Claude OpusとClaude Sonnetの間には大きな違いを感じるよ。Sonnetは時々、全く実を結ばないアイデアに時間を無駄にしたり、逆に悪化させたりすることがあるから、AnthropicがMaxサブスクリプションの人たちにOpusとSonnetを区別しない方が良いんじゃないかと思う。SonnetはOpusが2、3回でできることを10〜20回もかかるみたいだから、結局Sonnetに強制的に移行させるのはもっとコストがかかる気がする。

└

そうそう、マックスのサブスクリプションは2つのティアがあって、$100でプロの5倍のトークンがもらえる（プロはsonentだけだし）。$200だと20倍になるよ。トークンの計算はちょっと面倒で、今はあんまり簡単じゃないね。それに「ハイブリッド」モードもあって、opusを使って、トークンが20%残ったらsonnetに切り替わるんだ。

これを書いてくれてありがとう。HNの多くのソフトウェア開発者は、LLMにソフトウェア開発のコントロールを委ねることに対して、いろんな理由で葛藤してるよ。特に、厳密に計画された形式的な手法よりも、構造がなく探求的に感じるからね。LLMが問題解決を早めてくれる良い中間地点があると思う。結果を最適化することに焦点を当てて、問題を解決することに夢中になりすぎないようにしたいんだ。実装の詳細に気を取られていると、私たちが本当に達成したい目標を見失っちゃうことが多いからね。

└

まさにその通り！これらは新しいレバーだと思ってる。まだちょっと錆びてるけど、たまに後ろから噛みついてくることもある。でも、学ぶ価値はあるし、何よりも役立つツールに進化させるために使いたいよね。だらしないエンジニアリングの言い訳にするんじゃなくて。

君のドキュメンテーションのヒントを読んで（感謝してるよ）、AI特有のラベルを付ける必要はないと思う！‘CLAUDE.md’は‘CONVENTIONS.md’でも全然良さそうだし、‘AI’へのコメントは‘READER’へのコメントでもいいと思う。:) 特に不慣れな貢献者としては、どんなコードベースでもそんなコメントがあったら嬉しいな。

└

OPじゃないけど、実際にはClaudeに役立つコメントは人間に役立つものとはかなり違うことが多いよ。人間には、一般的に「なぜ」を重視するんだ。人間用のスタイルガイドは約100行で、「入力の1つを変更する場合に限り、関数名の最後に！を追加する」みたいな行がある。Claude用のスタイルガイドは約500行あって、同じようなセクションには「これをやって、これをやらないで」みたいな多くの例が必要なんだ。

一番上の2.3MBの画像、Wi-Fiでもコメディのように遅く読み込まれたよ。

いい投稿だね。ただ、ちょっと違うなと思うのは、>「絶対にAIにテストを書かせるな。」って部分かな。今はAIがすべてのテストを書いてるけど、ちゃんと見直してるよ。特に新しいコードの場合、自動で動かすためにはAIにテストを書かせる必要があるんだ。AIにテストを書くように指示して、合格するまで止めないようにしてる。コードを実装してる間に、テストが意味を持ってるか、重要なケースをカバーしてるかを確認しながら見直すことが多いよ。もし不十分な場合は、もっとケースを追加する。