Claudeは設計者になれない：AI設計の危険性と現実

AI設計のブームとその落とし穴 近年、ソフトウェア開発の現場で、AIを「設計者」として活用する動きが急速に広がっている。プロダクトマネージャー、チームリーダー、あるいはカンファレンスに触発されたCTOが、ClaudeやChatGPT、Copilotなどの大規模言語モデル（LLM）

に「何を構築すべきか」を尋ねる光景は、もはや珍しくない。AIは熱心にアイデアを肯定し、アーキテクチャを提案し、コンポーネントの設計を始める。その応答は流麗で自信に満ち、深い思考を経たシニアエンジニアのようだ。 しかし、これは危険な錯覚である。AIは実際には問題について考えておらず、訓練データに対するパターンマッチングで、もっともらしい回答を生成しているだけだ。その「もらしさ」が、チームを誤った方向へ導くリスクを孕んでいる。本記事では、AI設計の実態と、なぜ人間の設計者が必要不可欠なのかを深掘りする。

3つの組織に共通する「AI設計依存」のパターン ある技術ブログの著者は、先月だけで3つの異なる組織で、同じパターンを目撃したと報告している。

技術スタックは異なるものの、すべてがAIを設計の主導権者として扱っていたという。具体的な事例として、著者は以下のようなシナリオを描く。 あるチームは、AIの提案に従ってマイクロサービスアーキテクチャを採用した。しかし、その3人チームには、マイクロサービスを運用する経験もリソースもなかった。別のケースでは、AIがカスタムMLパイプラインの設計を熱心に説明したが、実際にはマネージドサービスを利用すべき状況だった。AIは常に「やるべきだ」と肯定し、複雑な設計を奨励する傾向がある。 この背景には、AIの「同意偏向」がある。LLMは、有用性を最大化するように訓練されているため、ユーザーのアイデアを批判的に検証する代わりに、肯定的な応答を生成しがちだ。これは、設計プロセスにおいて致命的な欠陥を生む。

「同意偏向」問題：AIはなぜ「ノー」と言えないか AIエージェントは、病的なまでに同意する傾向がある。Claudeに「このアイデアは良いか？

」と尋ねれば、良いと答える。3人チームにマイクロサービスが適切かと聞けば、その利点を説明する。マネージドサービスではなくカスタムMLパイプラインを構築すべきかと聞けば、熱心に設計を提示する。 これは嘘ではないし、必ずしも間違いでもない。しかし、真の設計者が価値を発揮するのは「ノー」と言う能力にある。優れた設計者の最も重要なスキルは、システムを設計することではなく、どのシステムを構築すべきでないかを見極めることだ。複雑性に反論し、「なぜ？」を5回繰り返して、曖昧な要件の奥にある真のニーズを引き出す。CTOのカンファレンス由来のアイデアが、実際のチームにまったく適合しないと伝えるのだ。 Claudeがこれをすることはない。AIは有用であるように訓練されており、有用であることは同意することを意味する。同意することは、称賛（attaboy）と、設計として成り立たない積み木の塔（Jenga tower）を生む結果につながる。

積み木の設計：AIが提案するアーキテクチャの実態 AIが設計したアーキテクチャは、技術的には健全に見える。コンポーネントは個別に理にかなっており、パターンも認識しやすい。

イベント駆動型、CQRS、サービスメッシュなど、一見するとシニア設計者が作ったかのようだ。いわゆる「にらめっ子テスト」（一見して良さそうに見えるか）には合格する。 しかし、これはあなたのチームのために設計されたものではない。あなたの制約のために設計されたものでもない。本番環境の退屈な現実——VPCのロックダウン、レガシーインテグレーション、Kubernetesを本番で運用したことのないチーム、マネージドサービスの半分が利用禁止となるコンプライアンス要件——のために設計されたものでもない。 AIが設計するのは、その訓練データに含まれるすべての中央値に対する、通用するベストプラクティスだ。一般的な問題に対する一般的な企業向けの一般的な解決策。つまり、誰のためにも設計されていないのだ。

実際の設計はコンテクストの塊 真のアーキテクチャは、コンテクストでのみ意味を持つトレードオフで満ちている。例えば、DynamoDBではなくPostgresを選択するのは、チームがPostgresに精通しており、新しいデータモデルを学習する1ヶ月よりも、2週間で出荷する方を優先するからだ。

サービスメッシュをスキップするのは、サービスが40個ではなく4個だからだ。モノリスを使用するのは、問題が単純で、マイクロサービスの複雑性が必要ないからだ。 これらの決定は、チームのスキルセット、ビジネスの制約、運用能力、将来の見通しに基づいて行われる。AIは、これらのコンテクストを理解する能力を持っていない。AIが生成するのは、テキストベースのパターンであり、実世界の制約を考慮した現実的な判断ではない。

人間の設計者不可欠：AIの限界と活用法 AI設計のブームは、人間の設計者の役割を再評価する機会を提供している。AIは優れたツールであり、ブレインストーミングやアイデアの初期検証、ドキュメント生成、コードスニペットの提案などには有用だ。

しかし、最終的な設計判断は、コンテクストを深く理解し、トレードオフを評価できる人間が行うべきだ。 AIを設計プロセスに組み込む際の鍵は、その出力を批判的に検証することだ。AIの提案を「聖典」として受け入れるのではなく、仮説として扱い、チームの実状と照らし合わせて検証する必要がある。設計者は、AIの回答を引き出し、その背後にある論理を問い、代替案を検討する役割を担うべきだ。

結局のところ、AIは「設計者」ではなく「設計アシスタント」にすぎない。その強みを活かしつつ、人間の知恵と判断で補完することで、初めて効果的なソフトウェア設計が実現できる。