ハクソク

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

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

274日前原文(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時間動いて、俺がいくつかのツールの使用を承認するだけで済んだ。その後、大部分のツールとテストが終わった。このアプローチは、俺が以前やってたやり方とは全然違うけど、詳細な技術文書を書いて、みんなが同じページにいることを確認する未来が見える。ある意味、コードに入るよりも生産的だと感じた。欠点としては、コードを読むときは集中できるんだけど、マークダウンドキュメントがたくさんあると集中力が続かない。興味深い時代だね！

└

それがまさに私の問題なんだ。集中力がないのに生産性が上がってる感じがして、なんかおかしいけど、今のところはうまくいってる。長い目で見れば、これに対する解決策を見つける必要があるね。今のところ一番効果的なのは、同じプロジェクトの複数のリポジトリで、異なるタスクを解決するために複数のエージェントを動かすこと。そうすれば、常に承認作業が必要だから、なんとか集中できるんだ。大きなチームを持つプロジェクトマネージャーみたいな感じだね…本当に興味深い時代だ。

└

我々が全員いなくなった後も、スクラムマスターがほとんど忘れ去られた歴史的な好奇心として残る中で、謙虚で永遠のウォーターフォールモデルが残るだろう。

└

それはかなり新しいね。あなたの実験でエージェントを動かしているフレームワークは何？

└

最近、テスト駆動開発が強力だった理由に似たものを開発している気がします。TTDは、システムをまず設計することを強制しましたよね。コードを作りながらシステムをマッピングしていた過去とは違って。AI駆動の開発は、そんな感じがします。計画している領域をマッピングすることを強制されることで、コーディング自体は二の次になり、設計の決定を実装するためのボイラープレートに過ぎなくなります。AIはボイラープレートが得意ですからね！

└

最近は、製品の詳細やユーザージャーニーを声で記録して、製品の技術的なドキュメント作成プロセスを始めています。最小限のCLAUDE.md。ソフトウェア開発プロセスのためのGitHubベースのワークフローです。良いCIワークフローを生成するのに苦労しています。私のプレイブックはこちらです: https://nocodo.com/playbook/

AIツールを最適化しようとすることで、多くのエンジニアが良いコミュニケーションや期待設定の価値を発見しているのが面白い。10倍プログラマーのディーバ/自閉症のステレオタイプは見直しが必要だね。

私も最近このワークフローを発見して、すごく驚いてる。私の意見では、まずはClaudeにできるだけ低い要件を設定して、計画モードを自由に動かすことが鍵だと思う。売上指標のレポートを書く？「超思考関連の売上指標」と言えば、どれを優先するかのランキングをたくさん出してくれるし、足りないものを追加することもできる。次に、この機能用の新しいディレクトリを作って、計画をファイルに書き出すように頼む。そして実装計画を作成して、データベースから関連データを見つけて、それをどうクエリするかを書かせる。最後に、実装させてテストやエンドユーザードキュメントを書かせて、QAに送る。売上予測が必要？これは10年前には大きなチームが必要だったエンタープライズ機能だったけど、Claudeは午後のうちにDockerコンテナを実装する。今、ソフトウェアを見る目が変わったよ。以前はNDAや知的財産があって、企業はソースコードが漏れないようにすごく気を使ってた。でも今は状況が変わった。20年かけて開発した複雑なERPシステムがある？Claudeなら一瞬で再実装できるし、ドキュメントやテストも書いてくれる。まだ完璧には動かないかもしれないけど、進展は早いね。

私もReplitを使った経験があります。タスクや真実のソースとしてデザインドキュメントを使う必要がありますね。アプリのサイズが大きくなると、どんどん崩れていく感じがします。OpenAIでは、ChatGPTが遅くなって、チャットが反応しなくなることが多いです。ドキュメントを作って新しいチャットにインポートするようにすると、少し改善されます。人間的な視点から見ると、私たちも同じことをすべきだと思います。反省して、ドキュメントを作って、自分たちの「記憶」を作業用のデザインドキュメントに落とし込む。自分たちも、LLMも解放するために。

「最初に計画すれば、うまくいく」というアプローチが理解できないのは、彼らは以前どうやってやっていたのか?! 小さな機能以上のものでは、いつも自分が何をしているのか、なぜそれをしているのかを考えています。頭の中で考えたり、紙に書いたり、Confluenceのページやホワイトボードを使ったり。正直、よくわからないです。ソフトウェアエンジニアリングの80%は、何が必要で、どうやってそれを達成するかを考えることです。ステークホルダーと確認して、やりたいこととその理由を書き出します。リサーチもします。残りの20%がコーディングです。これが常にプロセスでした。適切な計画や目標の定義にAIは必要ありません。

└

私は通常、コーディングとデザインをもっと混ぜてやっています。何かをコーディングし始めて、しばらくそれを形作って改善していく感じですね。もちろん、ほとんどのことには、どうやって動くかの明確な方法があるので、それにあまり時間をかける必要はありません。

└

大きな開発チームで確立された文化がある場合はそうかもしれないけど、今はソロプロジェクトや小さなチーム、週末のサイドプロジェクト、個人ツールの制作、さくっとしたPOCコーディングなど、いろんな環境で開発が進んでるよね。すべてのソフトウェアが複雑な製品で、売ったり維持したりする必要があるわけじゃない。一番好きなのは、開発者として自分が必要なカスタムソフトウェアを作れることなんだよね。たとえ一回限りのタスクでも、他のユーザーやコーナーケースのことを気にせずに作れるのがいい。ほとんどの場合、開発プロセスはコーディングと発見のミックスで、コードのメンタルモデルをその場で更新していく感じ。ドキュメントや仕様書、テストから始まることはほとんどない。TDDに向いてるプロジェクトもあるけど、必要ないものもある。そういうケースでも、AIコーディングエージェントを使うことで状況が変わるんだよね。まずアイデアを説明して、仕様に落とし込んで、プロジェクトに関わると思うことを頭の中で言語化することが重要になってきた。今や、一番ホットなプログラミング言語は英語だね。

これがClaude Codeから良い機能を引き出す鍵です。最近、GPT-5 High（Cursor内）を使って計画を立て、それをClaude Codeに持っていって実装することで良い結果が出ています。コードベースで変更が予想される部分を最初にドキュメント化すれば、さらに15〜20%の効果が得られます。計画モデルに、どう動くか、アーキテクチャやパターンを記録させましょう。その後、この文脈で機能を計画すれば、より良いコードが得られます。また、ドキュメントや計画を見直したり、修正したり、手動で編集することも忘れずに。それが後々大きな利益をもたらします。

└

職場ではGoogle Workspaceを使っていて、Geminiは「学術スタイル」の文書作成が素晴らしいけど、CCに比べてコードを書くのはあまり得意じゃないと感じています。だから、Geminiに計画を詳しく書かせて、説明をできるだけ明確にするようにしています。それをCCに渡して、私のコードベースに変更を実装させています。これが新機能を作ったり、他の機能を大幅に改善するのに非常に効果的でした。ここ8週間でゼロから作り上げた製品が今、実際に運用されていて、クライアントにデモを行っています。自分の経験とその成果に大満足です。以前HNでも言ったように、私たちの既存のスタッフでこの作業の多くを自分たちでできたかもしれませんが、フロントエンドの作業はできませんでした。1年以上かかると思っていたことが、ほとんど2ヶ月でできてしまいました。機能が数時間ではなく、数秒で追加されるんです。CCには驚かされていますし、他の人たちが私の旅を反映しているのを実感させてくれるこれらの記事を読むのが大好きです。

こういうプロセスにフロントエンドデザインをうまく追加する方法を見つけた人いる？みんなが使ってる実装は、フロントエンドフレームワークへの曖昧な言及か、figmaの画像が含まれてることが多い。なんか統一感のあるデザインソリューションには感じられないんだよね。

これ、Visual Studio Code/ChatGPT5（プレビュー）を使ってる時と似てるな。{たぶん、GitHub Copilotのサブスクリプションで支払われてると思うけど、最近はちょっと不確かなんだよね} 非エージェントのLLMをコードに使ってみたけど、すぐに壊れたり、うまくいかなくなったりすることが多かった。LLMを使ってコードを作るエージェントモードは、私にとって大きな改善なんだ。Pythonプログラマーではないけど、新しいコードの山を作ってもらってて、過去一週間で達成したことにはかなり感心してる。終わったら、小さなLLMをエミュレートしたBitGridで動かしてみて、コードを理解しようと思ってる。全体のデザインを自分の思い通りに進めるために、いくつかの修正を加えながら、小さな探求のステップを踏んできた感じ。こういうエージェントを実際に使ったことで、「LLMがプログラミング仲間になる未来」に対して、かなり希望が持てるようになった。他にVisual Studio Code/ChatGPT5のコンボを使ってる人いる？