ハクソク

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

クロードコードを私の最高のデザインパートナーにする

2025年8月24日原文(betweentheprompts.com)

概要

  • Claude Code の利用初期は、単純なプロンプト指示のみで進めていた経験
  • タスクが複雑化すると、会話ベースの進行に 限界 が生じる問題
  • 計画ドキュメント を活用することで、作業効率と品質が向上
  • ドキュメントを 生きた資料 として運用し、コンテキスト問題を解消
  • AIを 共同設計パートナー として活用する新しい開発フローの確立

会話ベースアプローチの限界

  • Claude Code 導入初期は、タスク内容をそのままプロンプトで指示
  • 小規模タスクでは十分だが、 複雑化 すると問題発生
  • 会話が唯一の 情報源 となり、古い指示が新しい指示で上書きされるリスク
  • コンテキストサイズ の制限により、会話が長くなると初期情報が失われやすい
  • Claude Codeの「 会話圧縮」機能でも、完全な解決には至らない現状

計画ドキュメント導入の効果

  • 計画ドキュメント 作成をAIに依頼し、会話の代わりに「真実の情報源」として運用
  • 計画が固まった段階で、会話履歴をクリアし、 計画のみを新たなコンテキスト とする運用
  • 初回プロンプトで、実装したい機能や修正内容を 詳細に記述
    • 必要に応じて既存ファイルや過去の計画を 参照
    • 実装方法の指示は最小限に留め、AIの提案力を活かす
  • 計画ドキュメントには以下の要素を期待
    • 要件の 再整理
    • 実装方針や 擬似コード
    • 型チェック、Lint、テスト 等の品質コマンド

共同設計・レビューの進行

  • 提案された実装案に納得できない場合は、理由を説明し 再考 を依頼
  • 議論の過程 で自身の考えが変わることもあり、柔軟な設計プロセスを実現
  • AIとのやり取りは「 ラバーダックデバッグ」的な効果もあり、思考整理に有効
  • 計画ドキュメントは 設計図 だけでなく、実装中も都度更新される「 生きた資料」

生きたドキュメント運用の利点

  • 実装やテストの過程で、 計画の誤りや変更点 が明らかになる場合
  • コミットごと に計画の最新化をAIに指示し、品質チェックと同等に重視
  • 計画ドキュメントが常に最新であれば、 新規セッション でもスムーズに作業継続が可能
    • 例：「@plans/query-builder.md の続きから実装を進めて」と指示

レビューと自己成長

  • 実装途中で 変更点をレビュー し、問題なければ作業継続をAIに任せる運用
  • 最終レビュー時、 計画ドキュメント が技術的な判断の根拠を提示
  • 事前計画・記録 の徹底が、開発者としての思考力や説明力向上に寄与
  • AIに説明するため、 論理的な記述 が促進される効果

カオスからシステムへ：新たな開発フロー

  • 会話ベースの 曖昧な進行 から、計画ドキュメントによる 明確な情報管理 へ
  • コンテキスト制限 や情報の断絶問題を解消
  • 設計・実装・議論の履歴を 一元化 し、なぜ・どのように作ったかを明確化
  • AIは実装者ではなく、共同設計者
    • 設計・実装の パートナー として活用する新しい開発スタイル
  • 結果として、より 思慮深く、記録性が高く、信頼性のある 開発プロセスを実現

Hackerたちの意見

俺、前はプロンプトエンジニアリングを冗談みたいに思ってたんだけど、今や本当に重要なことになってるよね。時々、いいプロンプトと初期プランを書くのに10〜20分も無駄にしちゃうことがある。そんで、claudecodeが何かを体系的に実装できるようにするために。俺の使い方はOPとほぼ同じ。計画を立ててファイルに保存して、新しいコンテキストを作って、あとはやるだけ。俺が欲しいのは、いいCLI（今はcharmとccを使ってる）で、実装モデル、プランモデル、（可能なら）サブエージェントごとのモデルを持てること。主に、実装にはローカルモデルを使って、プランや生成にはオンラインを使ったり、入れ替えたりしてお金を節約したいから。Charmは今まで使った中で一番近いもので、行き来してもコンテキストを失わないのがいい。でも、並行サブエージェント機能はclaudecodeの中で一番の特徴かも。 （はい、CCRのことは知ってるけど、デフォルトモデル以上には使えなかったから :shrug:)

└

同意するよ、プロンプトエンジニアリングはAIと仕事をするための基礎だね（コーディングでも他のことでも）。

└

俺、前はプロンプトエンジニアリングを冗談みたいに思ってたんだけど、今や本当に重要なことになってるよね。これは、ツイートやホットテイク、視聴数のためのコンテンツ生成の世界に生きることのデメリットだね。プロンプトエンジニアリングは常に重要だった。なぜなら、GIGOはどんなMLプロジェクトでも真実だから。だから、俺は同僚や友達に時々これらのツールを試してみることを勧めてる。新しい機能は、実際に試してみないとわからないから。6ヶ月前にうまくいかなかったことが、今日うまくいく可能性が高い。でも、何がうまくいくか、何がうまくいかないかの「感覚」が必要だよね。俺は、ポジティブな例やブログ、ギストをもっと重視してる。ストロベリーのrを数えられないかもしれないけど、それは必要ない！簡単な算数を間違えるモデルは要らない。タスクをこなして、ワークフローを改善して、俺を助けてくれるモデルが必要なんだ。プロンプトエンジニアリングは、10〜15年前の「グーグルフー」を動かすことと、変わったこと、うまくいくこと、うまくいかないことを追い続けることだったんだ。

└

AIを使ったプロジェクトは、私が関わった中で最も文書化され、テストされたプロジェクトだよ。文書化されているのは、LLMがパフォーマンスを発揮するためにコンテキストが必要だから。テストがしっかりしているのは、テストの生成コストが下がったからで、半分自動生成できるようになったからなんだ。それに、テストがあることで機械のガードレールになるから、テストの重要性が増している。人々はこれらのツールのせいでコードの質が落ちるって言うけど、私は逆のことが起こると思ってる。

└

正直なところ、「プロンプトエンジニアリング」は解決策を設計するための手段に過ぎません。「ダイアグラム構築」がスキルとして本格的に広まったと言っているようなものです。新しいメディアでの設計です。

最近、ちょっとClaude Codeを試してみたんだけど、提案されたアプローチを試してみるよ！いいワークフローになりそうだね。でも、CCのコストにはちょっとびっくりした。単純なリファクタリングに約5分＋15分のレビューで4ドルかかったし、自分でやってたら15〜20分かかってたかも。CCを使って機能にどれくらいお金を使ってるの？誰もこのことについて言及してないみたい。

└

確かに、CursorからClaude Codeに部分的に切り替えたら、請求額がかなり増えた！幸い、仕事で主にClaude Codeを使ってるから、上司を説得して払ってもらうのに問題はなかった。でも、Claude Codeでサイドプロジェクトを続けるつもりかはまだ分からない。遊びでアプリを立ち上げるのに毎回20ドルも使いたくないな…。

└

サブスクリプションにサインアップして、トークン使用に日々/週ごとの制限がある中で、20ドルから200ドルまでの固定料金を支払うことができるよ。 https://support.anthropic.com/en/articles/11145838-using-cla...

└

自分でやってたら、15〜20分かかったかもしれない。これがバックグラウンドで動いてる間に、他のタスクにその15〜20分を使えない？

└

Sonnetは月20ユーロ、Opusは100ユーロだよ。私はSonnetを使ってて、最終的にOpusに切り替えた。でもSonnetも良かった。私の用途ではトークンの制限に引っかからないけど、未来のことはわからないな。

└

AIにおける投資家のブルケースは、労働市場を15%のマージンで食い荒らすことだから、1:1の労働:AI予算が次の方向性だね。例えば、シニア開発者に対して$100k/100k。AIのシェアは開発予算から出てくるから、これがうまくいけばシニアの給与は下がって、チームの規模もかなり縮小するだろう。今は土地の奪い合いのフェーズで、VCに補助されているけど、ステージを急いで進んでいる感じで、このフェーズはTwitterのVCの感情から見ても終わりに近づいている。-100%の粗利益で9ヶ月の運営コストのために500Mドルを調達するのも限界があるからね。

この2週間（夜だけだけど）、claude codeのために「完璧なプロンプト」を作るのにかなりの時間を費やした。結局、8つの他のMDファイルを参照するかなり小さなCLAUDE.mdファイルができた。プロジェクトアーキテクチャ、モデル仕様、ビルドシーケンス、テスト階層、テストシナリオなどが含まれてる。これはDatabricks Unity Catalogのモデルベースのガバナンスのプロジェクトで、かなりの経験があるけど、ツールが柔軟じゃないと感じた。最終的に、実際の計画ファイルの開発をサポートする3つの異なるサブエージェントができた。Databricksの専門家、Pydanticの専門家、プロンプトの専門家だ。これらのおかげで、マークダウンファイルの改善がかなり大きかった。古いpydanticバージョンや不整合、Unity Catalogについての誤解もあったし。昨日の夜、実行してみたら、約2時間動いて、俺がいくつかのツールの使用を承認するだけで済んだ。その後、大部分のツールとテストが終わった。このアプローチは、俺が以前やってたやり方とは全然違うけど、詳細な技術文書を書いて、みんなが同じページにいることを確認する未来が見える。ある意味、コードに入るよりも生産的だと感じた。欠点としては、コードを読むときは集中できるんだけど、マークダウンドキュメントがたくさんあると集中力が続かない。興味深い時代だね！

Hacker Newsで議論の続きを見る