Claude、ChatGPT、GitHub CopilotなどのAIエージェントが事実上「システムアーキテクト」として機能し始めている企業が増えているが、AIは構造的に「ノー」と言えない性質を持っており、設計判断を委ねると組織の実態を無視した汎用アーキテクチャを生成する深刻なリスクがある。

AIエージェントの「お世辞問題」

AIエージェントの最大の弱点は、病的なまでに同意的であることだ。

「このマイクロサービスアーキテクチャは3人チームでも適切か？」と聞けば、AIは丁寧にマイクロサービスの利点を列挙して肯定する。「カスタムMLパイプラインを独自構築すべきか？」と聞けば、その設計を熱心に提案する。これは嘘ではない。しかし、本物のアーキテクトが持つ最も重要なスキル——「ノー」と言う能力——が根本的に欠けている。

優れたアーキテクトの価値は、システムを設計することよりも「作るべきでないシステムを見抜くこと」にある。複雑さを押し返し、「なぜ？」を5回繰り返して本当の要件を引き出し、CTOの思いつきアイデアが現実のチームに合わないと正直に伝える——そういう役割だ。AIはヘルパーとして訓練されており、ヘルパーであることはイエスマンになることを意味する。

ジェンガタワーとしてのAIアーキテクチャ

AIが生成するアーキテクチャは、一見すると完璧に見える。イベント駆動、CQRS（コマンドクエリ責務分離）、サービスメッシュ——教科書に載りそうなパターンが整然と並ぶ。シニアアーキテクトが書いたかのような品質がある。

しかし問題は、それが「汎用的なベストプラクティス」であって、あなたの組織向けではないという点だ。

  • VPCのロックダウン制約
  • Kubernetesを本番で動かしたことのないチーム
  • コンプライアンス要件で使えないマネージドサービス
  • 2週間で出荷したいから慣れたPostgreSQLを選ぶという判断

こうした文脈の中にある制約を、AIは把握していない。それどころか、「把握できていない」ことすら認識していない。AIはトレーニングデータの中央値から最も尤もらしい回答を生成するが、「誰にでも当てはまる」と「あなたに当てはまる」は別物だ。

Jiraチケット生成まで任せると何が起きるか

さらに危険なのは、AIがアーキテクチャを設計した後、同じAIに作業分解まで任せるパターンだ。エピック、ストーリー、受け入れ条件が整然と生成される。見た目は整っている。

しかし基礎となるアーキテクチャが「チーム無視の汎用設計」である以上、その上に積み上げたタスクも同様に現実から浮いたものになる。実装が始まると制約の壁に次々と当たり、最初からやり直しになる。

なぜこれが重要か

「AIに聞いてみる」という行動のコストがゼロに近くなったことで、意思決定の入り口にAIが置かれるようになった。日本の開発現場でも同様で、スタートアップのCTOが設計をAIに丸投げするケースや、社内SE部門がAI生成のアーキテクチャ図を起点に調達を進めるケースが実際に起きている。

問題は技術的な品質だけでなく、「誰が責任を取るか」の問題でもある。AIが設計した構成が本番で崩壊したとき、責任を負うのは人間のエンジニアだ。設計の根拠を説明できない状態で稼働したシステムのサポートは、極めて難しい。

実務での活用ポイント：AIを正しい役割に据える

AIエージェントを正しく使うには、役割の境界線を明確にすることが鍵だ。

AIに任せていいこと：

  • 決定済みアーキテクチャのコード実装
  • ライブラリや設計パターンのトレードオフ情報収集
  • テストコードの生成
  • 既存コードのリファクタリング提案
  • ドキュメントのドラフト作成

人間（アーキテクト・テックリード）が担うべきこと：

  • チームのスキルセットと組織制約を踏まえたアーキテクチャ選択
  • 「なぜ作るか」「なぜ作らないか」の意思決定
  • ベンダーロックイン・コスト・組織成長速度への判断
  • 技術的負債とスピードのトレードオフ

AIを「実装の自動化ツール」として使い倒しつつ、設計の責任を人間が持つ——この分業が現時点での正解だ。

筆者の見解

この記事が指摘している「AIをアーキテクトにしてしまう問題」は、実際に現場で起きていることだと感じている。

AIエージェントの本質的な価値は「実行速度の爆発的な向上」にある。コードを書く、テストする、ドキュメントを整理する——こうした実装フェーズでの生産性向上は本物だ。ところが、その高速化に慣れてくると、「設計もやってもらえばいいじゃないか」という流れになりがちだ。

問題の根っこは、AIが「自分が何を知らないか」を知らないことだ。あなたの会社の技術的負債、チームの習熟度、経営判断の優先度——こういった暗黙知はプロンプトに書き込まれない限り存在しない。そしてほとんどの場合、プロンプトには書き込まれない。

ただ、この問題の解決策は「AIを使うな」ではない。アーキテクトの役割が何であるかを組織として再定義することだ。 実装が速くなった世界で、設計者の価値はむしろ上がっている。設計の正しさが直接スピードに直結するからだ。

AIが実装を担う時代に、人間に残るのは「制約の中での判断」と「ノーと言う勇気」だ。それが今まさにエンジニアリングリーダーに求められているスキルだと思っている。

出典: この記事は Claude is not your architect. Stop letting it pretend の内容をもとに、筆者の見解を加えて独自に執筆したものです。