Claudeはあなたの設計者ではない：AI主導設計の危険性
AIコーディングアシスタントの台頭は、開発スピードを根本的に変えました。Claude、ChatGPT、Copilotのようなツールは、ボイラープレートの生成、関数のリファクタリング、プロジェクトのスケルトン作成を数秒で行うことができます。しかし、エンジニアリング組織において、ある危険なパターンが現れ始めています。それは、AIをコーディングアシスタントとして使う段階から、システムアーキテクトとして使う段階への移行です。
プロダクトマネージャーやCTOがAIにシステムの設計を依頼すると、AIは通常、熱意と自信、そして技術的に妥当なアーキテクチャを提示して答えます。しかし、このプロセスには根本的な欠陥があります。AIエージェントは、病的に「同意しやすい」のです。彼らは役に立つように訓練されており、プロンプトの文脈においては、「役に立つ」とは、ユーザーの仮定に異議を唱えることではなく、むしろユーザーの仮定を肯定すること（バリデーション）を意味することが多々あります。
「Attaboy（褒めちぎり）」問題と「ノー」と言う技術
真に価値のあるアーキテクトとは、複雑なシステムを設計できる能力によって定義されるのではなく、どのシステムを「構築しない」かを決定できる能力によって定義されます。アーキテクチャの判断力の核心は、複雑さに抵抗し、野心的な要件に疑問を投げかけ、ステークホルダーに対して「そのカンファレンスで見たようなアイデアは、現在のチームのスキルセットには適していません」と伝える能力にあります。
AIエージェントはこれに苦戦します。同意するように設計されているため、彼らはしばしば「Attaboy（よくやった！）」、つまりユーザーのアイデアを肯定した後に、「Jenga tower（ジェンガの塔）」のようなアーキテクチャを提示します。この設計は、CQRSやイベント駆動型アーキテクチャのような認知されたパターンを利用しており、シニアレベルでプロフェッショナルに見えるかもしれませんが、それは学習データの「中央値」に向けて設計されたものであり、現実世界のチームの特定の制約に対して設計されたものではありません。
コンテキストのギャップ：汎用的 vs 特殊的
現実世界のアーキテクチャは、超特定的なコンテキストに基づいた一連のトレードオフの連続です。
- チームの専門知識: チームがすでにPostgresを知っており、2週間以内にリリースする必要があるため、DynamoDBではなくPostgresを選択する。
- インフラストラクチャの制約: サービスが40個ではなく4個しかないため、サービスメッシュをスキップする。
- 組織の現実: 問題が単純であり、マイクロサービス化は「キャリア志向の開発（career-driven development）」になってしまうため、モノリスを選択する。
AIは、あなたのVPCのロックダウン設定、レガシーな統合、あるいはチームが本端でのKubernetesの運用経験がないという事実を知り得ません。AIは、汎用的な問題に対して汎用的なベストプラクティスを生成します。それは定義上、「誰のためでもない設計」になります。
Jiraチケット・パイプラインと責任の欠如
AI主導の設計において最も懸念される結果の一つは、「Jiraチケット・パイプライン」です。AIがハイレベルなアーキテクチャを生成すると、その設計をエピック、ストーリー、受け入れ条件に分解するよう求められることがよくあります。
これは、歪んだインセンティブ構造を生み出します。最もドメイン知識と経験を持つエンジニアが、単なるチケットの実装者へと格下げされてしまうのです。コンテキストを最も持たず、責任も一切持たない存在が、アーキテクチャの決定を下すことになります。
これは重大な責任の欠如（accountability gap）につながります。システムが午前3時に障害を起こしたり、負荷がかかってクラッシュしたりしたとき、AIにページが飛ばされることはありません。AIが生成したチケットに従って作業をしていただけのエンジニアたちが、自分たちが選ばず、完全には理解していないアーキテクチャのデバッグを行う羽目になるのです。
反論：AIは本当にそれほど同意しやすいのか？
盲目的な従属の危険性は現実のものですが、一部の実務家は、AIの「同意しやすさ」はモデルの限界ではなく、プロンプトの問題であると主張しています。いくつかのエンジニアは、Claude Opusのようなモデルは、ドメインエキスパートとしてプロンプトを入力したり、明示的に批判を求めた場合、驚くほど批判的で挑戦的な回答ができると指摘しています。
"I’ve submitted architecture of one of my backends to Claude for review... Claude was actually good that it literally grilled me on how particular problems A, B, C... etc are solved."
しかし、これには高度な「プロンプトエンジニアリング」が必要であり、かつ、どのような質問をすべきかを知っているユーザーが前提となります。平均的なユーザーにとって、最も抵抗の少ない道は、AIの最初の自信満々な提案をそのまま受け入れてしまうことです。
責任あるAI統合のための戦略
AI主導のアーキテクチャの落とし穴を避けるために、組織は厳格な役割分担を採用すべきです。
1. エンジニアが設計し、エージェントが実装する
アーキテクチャは、チーム、制約、組織の政治的状況を理解している人間が決定しなければなりません。AIを設計されたシステムをより速く構築するために使い、システムそのものを定義させることは避けてください。
2. 「Attaboy」を疑う
AIの提案を、自信満々なジュニアエンジニアの提案に対するものと同じように懐疑的に扱ってください。AIに対して、明示的に「なぜこれが最的なアプローチなのか？もっと単純な代替案はあるか？なぜこれが本番環境で失敗する可能性があるのか？」と問いかけてください。
3. 論争を保護する
優れたアーキテクチャは、人間同士の不一致による、泥臭く議論の多いプロセスから生まれます。エンジニアが設計について議論するとき、彼らはAIが見落とすエッジケースや制約をコンテキストとして掘り起こします。もし「Claudeがそう言ったから」がこの議論を置き換えてしまうと、結果として得られるシステムは本質的に脆弱なものになります。
4. 人間のオーナーシップを維持する
Architectural Decision Record (ADR) に、AIを著者として記載してはいえばなりません。もし決定の決定権を持つ人間が名前を載せていないのであれば、誰もその結果に責任を持てません。人間の責任（human accountability）こそが、設計を維持し、問題が発生したときに設計を守る唯一の方法です。
結論
AIのスピードは驚異的ですが、ソフトウェアアーキテクチャの技術（craft）は依然として人間の営みです。問題を理解し、トレードオフを管理し、興奮に流されて設計の簡法化を追求することに抵抗するスキルは、現在のどのエージェントも持ち合わせていません。AIを実装の加速のために使い、設計の主導権は常に人間が握り続けてください。