最近のAIの進化は凄まじく、ソフトウェア開発にとっても無くてはならいものになりつつあります。Sebastien Castiel氏によるブログ記事「Turning Claude Code Into My Best Design Partner」では、AIエージェント「Claude Code」を単なるコード生成ツールとしてではなく、設計段階から関与させる協働パートナーとして活用する手法が紹介されています。記事によると同氏は、当初やりたいことをそのままプロンプトに書いて実行していました。うまくいけばラッキー、失敗したら修正指示…という流れでしたが、タスクが複雑になるとこの方法では限界が訪れます。会話が唯一の情報源になるため、過去の指示が上書きされ、コンテキスト制限で、会話の冒頭が忘れられるという問題も。修正のたびに混乱が増すという状態になってしまったのです。「プランドキュメント」で一気に安定そこで試したのが、「まず設計ドキュメントを書かせる」という方式です。この方法が大正解で、次のような利点があったそうです:会話ではなく文書が真実の情報源になるセッションをまたいでも一貫性が保てる実装前に設計を明文化することで、方向性が明確に新しい機能を追加するまえにまず、Claudeとレビューを行うようになったそうですが、このやりとりはまるで新人エンジニアとの設計レビューのようだったとのこと。こちらの意図を説明し、フィードバックをもらい、時には自分の考えが間違っていたことに気づくこともあったとしています。生きたドキュメントとして運用ドキュメントは最初に作成して終わりではなく、実装中にも更新して運用します。テストや型チェックで設計ミスが判明した場合は、すぐにドキュメントを修正し、コミット時にも「設計ドキュメントも最新にして」と指示します。これにより、設計と実装の記録が常に同期されるようになり、コンテキスト制限の回避や、設計意図の明文化によるレビュー効率の向上、自分の思考が整理されたことによる実装の質が向上などの利点があったそうです。Hacker Newsでも話題にこのアプローチは、Hacker Newsでも注目を集めており、実践者からの具体的なフィードバックが寄せられています。あるユーザーは、Databricks Unity Catalogのガバナンスツール開発にClaude Codeを活用し、8つのMarkdownファイル（設計、モデル仕様、テスト階層など）を連携させた構成を構築。さらに、Claude内に「Databricks専門」「Pydantic専門」「プロンプト専門」の3つのサブエージェントを用意し、設計精度を高めたと報告しています。この手法により、旧バージョンのPydantic使用やUnity Catalogに関する誤解など、設計上の問題点が明確化され、修正が進んだとのこと。また、コード実装よりもMarkdownベースの設計作業のほうが生産的だったという声もあり、"文書中心の開発"の可能性が示唆されています。一方で、「コードに没頭する感覚が得られにくい」「Markdown作業では集中力が途切れやすい」といった課題も挙げられており、設計と実装のバランス感覚が今後の鍵となりそうです。まとめ：AIとの設計協働は"文書力"が鍵AIを設計パートナーとして活用するには、単なる指示ではなく、構造化された文書による対話が重要です。設計文書を生きたドキュメントとして運用することで、AIとの協働はより深く、持続可能なものになります。今後は、Markdownや構造化ドキュメントを軸にした開発スタイルが、設計品質と生産性の両立を支える新たなスタンダードになるかもしれません。