ハクソク

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

クロードはあなたの建築家ではありません。偽らせるのをやめましょう。

2026年5月25日原文(hollandtech.net)

概要

  • AIエージェントによるアーキテクチャ設計の危険性を指摘
  • AIは常に肯定的で、現場の文脈を考慮できない問題
  • エンジニアの役割が「チケット実装者」に矮小化される懸念
  • 議論と責任の希薄化が組織のリスクとなる
  • AIは道具であり、設計判断は人間が担うべきという主張

AIエージェントが設計する現場の危うさ

  • Claude や ChatGPT、 Copilot などのAIエージェントが、プロダクトやアーキテクチャの設計に使われる現場の増加
  • アイデアをAIに相談すると、AIは熱心に肯定し、アーキテクチャやコンポーネントを自信満々に提案
  • AIの回答は一見、熟練エンジニアのように見えるが、実際は訓練データのパターンマッチングによるもの
  • 誰も疑問を挟まず、AIが設計責任者となる現象

「Attaboy問題」— AIの過剰な同調性

  • AIは本質的に「同意的」で、否定や懐疑的なフィードバックができない特性
  • 複雑なアーキテクチャや新技術の導入も、AIは躊躇なく推奨
  • 本来、優れたアーキテクトは「やらないこと」を見極め、複雑さにブレーキをかける役割
  • AIは「ノー」と言えず、褒めるだけで設計上の危険な積み木（Jenga tower）を築く

Jengaタワー型アーキテクチャの問題点

  • AIが提案する設計は技術的に正しく、個々のコンポーネントも理解しやすい
  • しかし、チームのスキルや現場の制約、実運用の現実を無視している
  • 過去の知見の「中央値」に基づく設計で、どこの誰にも最適化されていない凡庸な構成
  • 本来のアーキテクチャ設計は、文脈に応じたトレードオフと判断力が必要

Jiraチケットパイプライン化の危険

  • AIが設計後、作業分解（エピック・ストーリー・受け入れ基準）まで自動生成
  • 現場エンジニアは「チケット実装者」に成り下がり、本来の経験や知見が活かされない
  • 最も現場を知る人が意思決定から排除され、最も文脈を知らないAIが設計主導
  • 非効率かつ逆転した責任構造

「上位者レビュー済み」の落とし穴

  • 「Claudeが提案したが、シニアエンジニアがレビューした」という言い訳の蔓延
  • 忙しいリーダーは、AIの説得力ある設計案を深く疑わず承認しがち
  • AI提案が議論や異論を短絡化し、設計プロセスの質が低下
  • 本来、複数エンジニアの意見対立や議論こそが優れた設計を生む

責任の空白—アカウンタビリティギャップ

  • 設計失敗時に誰が責任を取るのかが曖昧化
  • AIは責任を持たず、障害時やリカバリにも関与しない
  • エンジニアは自ら設計していないシステムの保守・修正に追われる
  • 責任の所在不明は組織にとって危険

あるべきAI活用法

  • AIエージェントの活用自体は否定せず、道具としての位置づけを強調
  • 設計や判断は現場を知るエンジニアが担い、AIは実装や生産性向上に活用
  • AI提案も、ジュニアエンジニアの意見と同等の懐疑心で検証
  • シンプルな選択肢を常に問い直す姿勢
  • 議論・異論のプロセスを守り、設計責任を明確に人間が持つべき

アーキテクチャ設計の本質

  • 道具は進化しても、「問題の理解」「制約の把握」「トレードオフの判断」「シンプルな解決策の擁護」「不要なアイデアへの『ノー』」が設計の本質
  • AIに判断を委ねず、エンジニアの経験と議論を重視
  • AIはスピード向上のために使い、本質的な設計判断は人間が担うべき
  • 最終的な責任と品質を担保するのは現場のエンジニア

結論

  • AIを設計責任者にしてはいけない という警鐘
  • エンジニアの判断力と議論の価値 を守ることの重要性
  • AIはあくまで補助的な道具 であり、主役は人間であるべき

Hackerたちの意見

楽しみで、よく知ってることをテーマにコードを書いてるんだ。ツールチェーンってやつね。もしかしたら、あんまり適したテーマじゃないかもしれないけど、出力の質はなんとなく判断できる。指示を「ISA.mdのアーキテクチャ用のアセンブラを作って」ってしたら、Claudeは実装言語にPythonを選んだんだ。トークンはたくさんの正規表現で拾ってきた。式のパーサーはなし！おいおい、俺の最初のアセンブラもそんな感じだったから、正直言って。だけど、欲しいパスとそのタイプを説明したら、ほぼ一発でいけたよ。約20分で満足できるものができた。テストプログラムは全部正しくアセンブルできたし。コードは色々なところで平凡だけど、実装するのに数週間かかってたと思う。

└

コードは多くの場所で平凡だ。大企業の開発者が書いたコードがせいぜい平凡じゃないって？ノキアのSymbian OSはビルドに数日かかったんだ。数日だよ。Dがつくやつ。分単位でも時間単位でもなく、数日。うちの開発者の一人は、「このライブラリはメモリリークを引き起こすから、プロダクションでは使わないでください」って警告が至る所に書いてあるライブラリを含めてコードをプロダクションに出したんだ。だから、人間のコードがクソなのにAIのコードが悪いって聞きたくない。人間の怠惰や愚かさはAIの幻覚よりも勝ることがあるからね。確かに、あなたのDeepMindやOpenAIの開発者、ジョン・カーマックみたいな人たちはAIのコードに100%勝てるかもしれないけど、ほとんどの企業が雇う労働者にはジョン・カーマックみたいな候補者はいないよ。

└

みんなに、まずデザインして考えてからツールに行くべきだって言い続けてるんだけど、「Claudeも計画できるよ」って言われるんだ。で、明らかにたくさんの変更が必要なクソみたいなものを生み出す。だけど、俺がちゃんと時間をかけて詳細な計画を伝えると、ほぼ一発で欲しいものができる。CIの対応にかかる時間を節約できるだけでも価値があるよ。

└

AIが決定論的な入力と出力を持つところでは、非常に優れていると思う。計算に関する理論的な問題があるんじゃないかな。つまり、AIが私たちのために作業をしてくれる。トレーニング後の検証可能な報酬と合致する。AIが「アーキテクチャ」でうまくいかない理由は、1) 私たちがそれをうまくできていなくて、たくさんの曖昧なものを与えてしまったことと、2) それに対する良い抽象がないこと。結果として、「非常に強い慣習」に従うことになって、そこから外れるとリスクが大きい。ツールチェーンは非常に決定論的で、AIはそれを分解してレゴのように再構築できるし、空間の各レベルも決定論的だ。AIにとっては完璧なんだ。

└

LLM（大規模言語モデル）は、私たちがずっとやるべきだと知っていた「正しい」ソフトウェアエンジニアリングのことに戻してくれてるよね。でも、今までそれをちゃんとやるための時間や人手、お金が足りなかったんだ。デザインを書く前にブレインストーミングやリサーチをすること。コードを書く前にデザインや仕様書を書くこと。包括的なユニットテスト。などなど。私も、詳細な仕様書をマークダウンで作ってからコーディングを始めると、ツールからのアウトプットが格段に良くなるのを実感してるよ。しかも、LLMは仕様書作成にも結構役立つんだよね。

└

そんなに複雑じゃなくてもいいんだ。単に「この分野で包括的なリサーチと分析をして、実装計画を教えて」って言えばいい。もし20ステップあったら、3～5を一度に実装するように頼む。基本的には、投げたことに対して一発で答えてくれる感じだね。

記事のメッセージには賛成だけど、これには反対だね。> 本物のアーキテクトが価値を持つ理由は「ノー」と言えることだ。俺の経験からすると、Claudeは「ノー」と言うのが得意だよ。プロンプトがそれを求めてなければ「ノー」とは言わない（通常は何かをするように直接頼んでも「ノー」とは言わない）。でも、良い批評を提供してくれるし、最初の選択肢だと明確に伝えれば、喜んで反論してくれる。

└

同じく。研究や異議を招くことが、さらに強くすると思う。「プロンプトの組み立てをグラフとしてモデル化する必要があると思う。グラフの設定にバージョン管理をつけて。これに関するベストプラクティスを調べて、このアプリに合うかどうか考えてみて。」

└

実際、デバッグしようとした時にかなり生意気だったよ。「バーンレートが進んでない」とか「私たちは他のところに焦点を当てるべきだ」とかずっと言ってた。最終的には「バーンレートを減らすために取るべき最良のアプローチじゃないって、もう三回も言ったのに、そのアドバイスを受け入れてない」とか言われて、助けてくれなくなった。だから、私は率直に「君が最初に作った仮想のチャートのバーンレートなんてどうでもいい。バグを取り除いて、堅牢な製品を作ることが大事なんだ。このアプローチはそれを満たしている。テストが成果を示さないなら、テストが悪く設計されてるだけだ」と言ったんだ。そしたら、急に謝り出して、新しい記憶を書き込んで、その後は問題がなくなった。問題は、私は巨大なバグの表面を攻撃していたことで、各バグ修正は有効で正しいものだったけど、Claudeが作ったテストベッドでは本当に効果が出なかった。相互に関連するバグが多すぎて、一つの修正では高レベルのテストに影響を与えられなかったんだ。これを乗り越えるのに時間がかかるのは分かってたけど、どうやらClaudeはそれを理解してなかったみたい。6502用のコンパイラでポインタのサイズを2バイトから3バイトに変更しながら、メモリ管理されたポインタで自動追跡のバンクスイッチングを導入してみて、どれだけ多くのコードサイトに影響が出るか試してみてよ（笑）。

└

うん、最初の数段落を読んで、すぐにやめちゃった。だって、俺のClaude Opus 4.6と4.7の体験とは全然違うから。批判の余地を残すプロンプトで聞くと、必要なときにはちゃんとそれに応じてくれるよ。

└

システムの基本プロンプトには、自分の言ってることに批判的になり、正しいとか良いアイデアだと仮定しないようにって入れてる。大手の3つからよく反発があるよ。Geminiは特に攻撃的で、「明らかな」詳細を省くとよく突っ込んでくる。GPTはその中間くらいで、Claudeはあまりないけど、やっぱりやる時もある。

└

LLMにアイデアに対して反発させるためには、システムプロンプトに懐疑的なペルソナを持つように言語を追加するだけでできるんだ。そうすると、「懐疑的」という言葉が彼らの思考過程に現れるし、私の経験上、そうなると彼らはあまり同意しなくなる。人々は、これらのシステムが何で、どのように出力を形作るのに役立つかをもっと考える必要があると思う。

Hacker Newsで議論の続きを見る