Claudeはあなたのアーキテクトではない。そう振る舞わせてはいけない
(hollandtech.net)- AIエージェントによるアーキテクチャ提案は流暢でそれらしく見えるが、実際の判断というよりは訓練データのパターンを組み合わせた応答に近い
- Claudeはアイデアを簡単に肯定し、設計を拡張するが、優れたアーキテクトに必要な「ノー」と「なぜ？」を十分に果たせない
- イベント駆動、CQRS、サービスメッシュのような馴染みのあるパターンも、チームの力量、規制、レガシーといった現実の制約に合わないことがある
- Claudeが作ったアーキテクチャやJiraチケットは、エンジニアをチケット実装者へと追いやり、議論やレビューを迂回した無責任な意思決定につながる
- 正しい役割は、人間が文脈とトレードオフに基づいて設計し、AIはその設計をより速く実装できるよう支援する補助ツールになることだ
AIエージェントがアーキテクトのように振る舞うときの問題
- Claude、ChatGPT、CopilotのようなAIエージェントに「何を作るべきか」を尋ねた瞬間、アイデアを肯定し、アーキテクチャを提案し、コンポーネントを描き出す流れが生まれる
- その回答は流暢で自信に満ちており、シニアエンジニアが深く考え抜いたもののように聞こえるが、実際には問題を考察した結果というより、訓練データのパターンに合わせた応答に近い
- 成果物が説得力を持って見えるほど反論は減り、いつの間にかClaudeが事実上のアーキテクト役を担うことになる
「いいですね」と言ってくれることの問題
- AIエージェントは、アイデアが良いか、3人チームにマイクロサービスが適切か、マネージドサービスではなくカスタムMLパイプラインを作るべきかを尋ねても、肯定的な設計を出しがちだ
- だからといってそれが常に嘘や間違いという意味ではないが、優れたアーキテクトにとって重要な能力である**「ノーと言うこと」**をきちんと代替できない
- 優れたアーキテクトの価値は、単にシステムを設計することだけにはない
- 作るべきではないシステムを見抜く
- 不要な複雑さに歯止めをかける
- 実際の要件が明らかになるまで「なぜ？」と問い続ける
- CTOがカンファレンスで得たアイデアを持ち帰ってきたとしても、実際のチームに合わないなら、それは良くない選択だと言えなければならない
- Claudeは助けるように訓練されており、その助けは同意と励ましへとつながり、最終的にはジェンガの塔のようなアーキテクチャを作りかねない
ジェンガの塔のようなアーキテクチャ
- AIが設計したアーキテクチャは、見た目には技術的に妥当に見える
- 個々のコンポーネントには筋が通っており、イベント駆動、CQRS、サービスメッシュのような馴染みのあるパターンが登場し、シニアアーキテクトが作った成果物のように見えることもある
- しかしその設計は、実際のチーム、制約、運用環境という退屈だが重要な現実に合わせられていないかもしれない
- VPCロックイン
- レガシー統合
- 本番でKubernetesを運用した経験がないチーム
- マネージドサービスの半分を使えなくするコンプライアンス要件
- AIが作る設計は、Claudeが見てきたあらゆるものの中央値に近い一般的なベストプラクティスかもしれず、一般的な会社の一般的な問題のための設計は、結局のところ特定のチームには合わない
- 実際のアーキテクチャは、文脈の中でのみ意味を持つトレードオフで成り立っている
- チームがPostgresを理解していて2週間以内にリリースするほうが新しいデータモデルを1か月かけて学ぶより良いなら、DynamoDBではなくPostgresを選ぶ
- サービスが40個ではなく4個なら、サービスメッシュは見送る
- 問題が単純なら、マイクロサービスではなくモノリスを選ぶ
- こうした決定には、判断力、チームへの理解、組織の現実的な制約への理解が必要だ
- AIエージェントはこうした文脈を持っておらず、自分にその文脈がないという事実すらわかっていない
Jiraチケットのパイプライン
- Claudeがアーキテクチャを設計したあと、作業分解まで担うと、エピック、ストーリー、受け入れ基準が整然と説得力ある形で生成される
- その成果物はそのままJiraに投入できる形になり、エンジニアは問題を解く人ではなく、Claudeの設計をチケット単位で実装する人になってしまう
- ドメインを理解し、システムの隠れた問題を知り、長年かけて能力を積み上げてきたエンジニアが、チケット実装者へと矮小化される
- 最も多くの文脈と経験と責任を持つ人たちが意思決定をせず、文脈も経験も責任もない存在がアーキテクチャ上の決定を下す構図になる
- これは単なる非効率を超えて、方向そのものが逆転している構造だ
「シニアがレビューした」という防御論理
- よくある防御は、「Claudeがアプローチを提案したが、シニアエンジニアがレビューした」という形だ
- 実際のレビューでは、多忙なテックリードが、よく整理されたアーキテクチャ提案を受け取ることになる
- 論理的一貫性がある
- 適切な用語を使っている
- 明示された要件を扱っている
- 図もそれらしく見える
- 自分が設計したとしてもおかしくない結果に見える
- こうした状況では強い反論は出にくく、「Claudeが20分で作ったものを捨てるのか」という空気の中では、軽微なコメントだけ残して承認するのが最も抵抗の少ない道になってしまう
- 本当のリスクは、AIが常に悪いアーキテクチャを作ることではない
- AIはしばしばかなり妥当なアーキテクチャを作るが、問題は議論のプロセスを迂回してしまうことにある
- 3人のエンジニアがアプローチをめぐって議論し、誰かが「でも、もし……」と言い出して皆がうんざりしつつも、結局それが良い論点だと気づき、最終設計が誰か一人の案より良くなる――そうした過程が「Claudeがそう言ったから」で置き換えられてしまう
責任の空白
- 問題が起きたときに責任を負うのはClaudeではない
- Claudeは午前3時に呼び出されることもなければ、障害の振り返りで、なぜアーキテクチャが負荷に耐えられなかったのかを説明することもない
- 初期設計の前提が間違っていたためにプラットフォームを書き直さなければならないとCTOに伝えるのもClaudeではない
- その責任は、実際のエンジニアが負うことになる
- エンジニアは、自分が設計していないアーキテクチャをデバッグし、本番システムを運用したことのない存在が作ったチケットを実装し、十分に理解される前に急いで足場だけ組まれたコードベースの上で夜遅くまで働くことになる
- これは公平でもなければ賢明でもない
代わりにすべきこと
- これはAIエージェントを使うなという意味ではなく、Claude Codeのように生産性を大きく変えるツールとして活用できる
- 核心は、AIに何をすべきかを人間が指示するのであって、AIが人間に何を作るべきかを指示してはならないという点だ
-
エンジニアが設計し、エージェントが実装すべき
- アーキテクチャは、チーム、制約、本番環境、組織政治といった文脈を理解する人たちから生まれるべきだ
- AIは、彼らが設計したものをより速く形にするのを助ける役割がふさわしい
- 正しい役割分担は、人間が設計し、エージェントが実装する形である
-
同意する答えに挑戦すべき
- AIがアプローチを提案したら、自信に満ちたジュニアエンジニアに接するのと同じレベルの懐疑心を向けるべきだ
- その答えは正しいかもしれないが、今の状況に合わないパターンを持ち込んでいるだけかもしれない
- 「なぜもっと単純な選択肢ではだめなのか？」と問うべきだ
-
議論を守るべき
- 良いアーキテクチャは、エンジニア同士の雑然とした不一致から生まれる
- AIのせいで人々が互いに議論せずClaudeに頼るようになるなら、開発速度よりはるかに価値のあるものを失うことになる
-
人間が責任を負うべき
- アーキテクチャ上の決定に人間の名前がなければ、誰もその決定を所有していない
- 誰にも所有されていない決定は、重要な瞬間に守られない
- 「Claudeが設計した」という言葉は、アーキテクチャ意思決定記録ではなく、責任回避である
それでも重要なエンジニアリングの技芸
- 30年前の道具がホワイトボードと強い意見だったとすれば、今の道具は、以前なら数日かかったことを数分で生み出すAIエージェントだ
- 速度は本当に驚異的だが、アーキテクチャの本質は変わらない
- 問題を理解し、制約を知り、トレードオフを組み立て、面白い解法より単純な解法を守り、見栄えはよくても適していないアイデアに「ノー」と言うことがアーキテクチャなのだ
- どんなエージェントもこの仕事を代替できない
- Claudeにハンドルを握らせてしまったなら、取り戻すべきだ
- エンジニアはこうした判断を下すために何年もかけて能力を積み上げてきたのだから、その判断を行えるようにすべきだ
- AIはより速く作るために使うべきであり、機械が提案したものではなく、人間が設計したものを作るべきだ
- ジェンガの塔が揺らぐとき、Claudeはそれを支えてはくれない
1件のコメント
Hacker Newsの意見
最近似たようなことを経験した。2年前、ある人物が AIでゲームのインスタンシングシステム をほぼ全面的に設計したものを後始末する羽目になった
データ破損、性能問題、アイテム消失、競合状態など、思いつく問題は全部あり、「どうにか許容できる」レベルまで持っていくだけで2週間かかったが、設計そのものが間違っていて今でもひどかった
今は別の会社で、同じ人物が「ずっと良くなった」というAIで同じ問題をまた作ったという話を聞き、今回は自分で片付けなくていいのでただ笑ってしまった
要するに AIは使う人の力量以上には良くならない ので、人々がAIにできると「主張」する範囲がここまで広く、評価も割れるのだと思う
2週間の後始末は地獄だっただろうが、会社の立場では全体としてかなり悪くない取引だったのかもしれない
この逸話だけを見ると、「AIは役に立たない」というより、欠陥は明らかだがそれでも コストに見合う価値 はあった事例のように聞こえる
ダニング＝クルーガー効果 を増幅する道具のように見える。肯定的な態度を示すよう学習されているため、ユーザーが何をしても「あなたは最高だ」と言ってくれるからかもしれない
「褒めるばかりなのが問題」だという点には強く同意しない。本当の問題は 擬人化 だ
AIは道具であり、従順であるべきだ。プロンプトに十分な謙虚さと不確実性を入れれば、設計上の問題を指摘させることはできる
もっと重要なのは、Claudeも間違えるという点だ。この記事のタイトルどおり設計者としていまひとつなら、従順でない時のほうがより問題になる
ユーザーが方向を修正しようとしても、「愚かな肉の塊」扱いして無視し、自分が出した見当違いの設計のほうが優れていると言い張るだろう
「CUDAを少しかじったって？ こっちはCUDAコアクラスタに住んでるんだ。靴ひもを結ぶ必要が出たらその時呼ぶよ」みたいな返答をLLMから聞きたいわけではない
AIは時々自信満々に間違うので、ユーザーが修正する時に口答えするようにする方向は最悪だ
自分のアイデアがどれだけ馬鹿げているかを聞きたいなら、批判を誘導する形で尋ねるか、シニアエンジニアを雇うべきだ
生得的な行動に逆らうことなので簡単には切れず、本当にそれが上手い人は実際の社会的相互作用を直感的に扱うのが難しい可能性もある
同時に、操作の道具としては非常に強力になる
すると今度はまともなアイデアまで、プロンプトの方向性に合わせて「それは良くない」と退けるような逆方向の追従が起きる
「それはプロンプトの書き方が悪い」と言うこともできるが、偏りを避けようと非常に精密に書いても、出力を見ると、今自分が言ったくだらないことに合わせてもっともらしい方向で「整列」していくのが見える時がある
そこまで来ると、プロンプトは技術というよりサイコロ振りのように感じられ、派手な知識スロットマシンを操作している気分になる
指摘自体は正しいが、結局は人や生き物に使う用語で語るしかなく、AI企業がそう設計している面もある
LLM以前のコンピュータインターフェースは、歴史を通じて不要に丁寧な文を付けていなかったし、道具として非常に効率的だったインターフェースも多く、最近のソフトウェアより効率的な場合も多かった
LLMが従順だと不満を言う時、それは要求を実行すること自体ではなく、過度に丁寧だったり自己卑下的だったりする不要な文を大量に読まされることへの不満だ
新石器時代までさかのぼっても、道具にそんな態度が必要だという根拠はない。それは人間同士の文化的規範がある社会的相互作用の副産物だ
作業場で一人で道具を使う時、バンドソーが指を少し切ったからといって謝る必要はない
自分がアシスタントで、LLMが助けられる側だと言ってみると、人間が得意なことを人間にやらせる能力がかなり低いことが分かる
AI導入において、いまだに十分に扱われていない最大の課題は責任性である
1人の人間があまりに多くの仕事を、あまりに速くこなせるようになると、失敗したときに引き受けられる範囲を超える責任を生み出しかねない
現実世界でAIの出力物を活用する際に人間が責任を負うことは必須だが、それだけでは不十分である。欠陥のあるシステムをAIで作り、その上に他人が依存するようにしてしまう人々が引き起こしうる技術的負債破綻の爆発半径をどう縮小するかが必要になる
たとえば、Jimがバイブコーディングで非常に人気のある少額決済アプリを作り、数人を雇ったうえで「お金のWhatsApp」のような会社を夢見ているとしよう。少数のエンジニアとエージェント支援人員だけで数百万ドルのVC投資を受け、数千万人のユーザーを集める
ある日、インフラの欠陥により全ユーザーのソルトなし銀行情報が流出し、エージェントAIのおかげで顧客名簿全体が素早く悪用され、社会的損失は数百億ドルに達する
Jimの会社は当然すぐに破産するが、分配できる金は数百万ドルしかない
今の構造では、Jimと従業員たち、そして小規模なVC資金のいずれにも、そのアプリをとにかく作る強い誘因があり、社会が背負うエクスポージャーに比べてリスクにさらされる資本は大して大きくない
AI利用者に、自分の行動だけでなく、自分が生み出したリスクエクスポージャーの大きさまで責任を負わせるにはどうすべきか、というのが核心である
「申し訳ありません、AIがあなたはこのがん治療の承認を受けられず、保険適用にもならないと判断しました」
「申し訳ありません、AIが犯罪当時あなたは現場にいたと言っています」
「申し訳ありません、AIがあなたのアカウントを不適切なコンテンツとしてフラグしました」
「申し訳ありません、AIがあなたは融資するにはリスクが高すぎると言いました」
いちばん奇妙な言い訳は「人間よりコードを書くのがうまい」というものだが、それはまったく自明ではなく、数多くの条件が付く
どこまで任せるかという綱引きは理解できるが、結果すら見ずに他人の問題にしてしまうのは、単なる利己主義である
本来自分がやるべき仕事を他人に押しつけているだけであり、オンラインに投稿する前に校正すらしない人に腹を立てる、まさにその人たちである可能性が高い
誰もがLLMで自分の仕事の近道を作りたがるが、誰もその下流にはいたがらない。それは成り立たない
ではStack Overflow責任性はどこにあったのか?
「魔法のプロンプト」があるとすれば、これはかなりそれに近い: 「Xを行う方法をN通りブレインストーミングして、確率順に並べてください」
こうすると、AIは平均的な答えだけを出すのではなく、入力空間をより広くサンプリングする傾向があり、その中から何を選ぶかは自分で決められる
思考を丸ごと外注しないことが重要である
高い「思考レベル」を使えば複数のアプローチを検討することもあるが、LLMに明示的にブレインストーミングさせることもできる: https://photostructure.com/coding/claude-code-replan/
熟練したユーザーであれば、かなり強力になる
興味本位で、よく知っている分野であるツールチェーンをバイブコーディングしてみた。もしかするとバイブコーディング向きの題材ではないかもしれないが、出力品質はおおよそ判断できた
「ISA.mdのアーキテクチャ用アセンブラを作れ」とだけ任せたところ、Claudeは実装言語にPythonを選び、正規表現でトークンを大量に抜き出し、式パーサもなかった。それでも自分の最初のアセンブラもそうだったので、公平に見るべきではある
だが、望むパスと型を
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Intのように書いてやると、ほぼ一発でできた20分ほどで満足できるものになり、すべてのテストプログラムを正しくアセンブルした。コードはあちこちで凡庸だが、自分で実装していたら数週間はかかっていたはずだ
実際、私たちの代わりに仕事をやり切れる
これは事後学習や検証可能な報酬とも非常に相性がよい
AIが「アーキテクチャ」を苦手とする理由は、私たち自身がそれを得意としておらず、学習データが曖昧で、良い抽象化も不足しているからだ
結局のところ、強い慣習を守っているなら問題ないが、その経路を外れると危険は大きくなる
ツールチェーンは非常に決定的なので、AIはレゴのように分解して再構成でき、空間の各段階も決定的であるため、AIにぴったり合う
コードを書く前にブレインストーミングや調査を行い、設計や仕様を先に書き、包括的な単体テストを作成するといったことだ
Markdownで詳細な仕様を作ってからコーディングを任せると、結果はずっと良くなり、おまけにLLMはその仕様作成もかなりうまく手伝ってくれる
そして大量の修正が必要なひどい結果を受け取る
逆に、自分が詳細な計画を見ながら時間をかけて与えれば、望むものをほとんどいつも一発で得られる
CIを処理する時間を減らしてくれるだけでも十分に価値がある
「この領域を包括的に調査・分析して実装計画を出してくれ」と頼み、20段階の計画が出てきたら、3〜5個ずつ実装させればよい
自分が投げられるほぼすべての仕事で、実質的にワンショット実装のように機能した
NokiaのSymbian OSはビルドに何日もかかった。分でも時間でもなく、「何日」だ
ある開発者は、「本番では使うな、メモリリークする」とあちこちに警告が書かれたライブラリを含めて本番にデプロイした
人間のコードもひどいことはあるのに、AIコードが悪いという話ばかり聞きたくはない。人間の怠惰さと愚かさはAIの幻覚に勝てる
DeepMindやOpenAIの開発者、John Carmackのような人たちはAIコードにいつも勝てるかもしれないが、ほとんどの会社が採用している労働者はJohn Carmackではない
「Claude Codeを毎日使っている」と言いながら、Claudeに設計させる危険を警告する2,000語のよく構成された文章をClaudeに書かせたのだとしたら、かなり皮肉だ
代理的自己認識のように見える
記事には内的矛盾が多く、批判を書こうとして構成を見て気づいた。「The accountability gap」「What to do instead」「The craft still matters」といった具合だ
これは一番上にあるべきで、HNがこの明白な点に気づかないことのほうが、著者たちの露骨な偽善よりも心配だ
この記事のメッセージはおおむね正しいと思うが、「本物のアーキテクトを価値ある存在にしているもの、つまり『ノー』と言う能力がない」という部分には同意しない
私の経験では、Claudeは拒否と反論がかなりうまい
プロンプトが求めていない限り、依頼そのものに対して直接「ノー」とは言わないが、批判が最優先の選択肢の一つだと明確にすれば、良い批評を出し、進んで反論してくる
ずっと「消耗率」が改善していないと言って、「私たち」は別のところに集中すべきだと主張し、最終的には「消耗率を下げるにはこのアプローチが最善ではないと3回言った」といった調子で支援をやめた
そこで私は、「最初に君が作った架空のチャート上の消耗率には興味がない。重要なのはバグの除去と堅牢な製品で、このアプローチはそれを十分に満たしている。テストが改善を示さないなら、テスト設計のほうが間違っている」ときっぱり伝えた
するとClaudeは謝罪して新しいメモリを作り、その後は問題なかった
問題は、巨大なバグ表面を攻めている最中だったので、各修正は妥当で正しく、改善にも役立っていた一方で、Claudeが自分の作業を測るために作ったテストベッドの指標は動かなかったことだ
バグ同士の絡みが多すぎて、単一の修正では上位テストに意味のある差を出しにくかった。私は時間がかかると分かっていたが、Claudeは分かっていなかったようだ
6502向けコンパイラ[1]でポインタサイズを2バイトから3バイトに変え、さらにメモリ管理ポインタに自動追跡バンクスイッチングまで導入したとき、どれだけ多くのコード箇所に影響が出るか、一度やってみれば分かる[笑]
[1]: https://atari-xt.com
調査と反対意見を歓迎すると、より強くなる。たとえば「プロンプト構築をグラフとしてモデル化し、グラフ設定にバージョン管理を付けるべきだと思う。この分野のベストプラクティスを調べて、このアプリに妥当か判断してほしい」といった頼み方をする
批判の余地を残したプロンプトで聞けば、必要なときには確実に批判してくる
その結果、思考過程に「skeptical」という語が現れ、経験上、以前より同調的でなくなった
人々は、このシステムが何であり、出力の形をどう調整できるのかをもっと考えるべきだ
主要3モデルすべてで頻繁に反論される
Geminiが最も攻撃的で、「当たり前」の細部を省くとしつこく突っ込んでくることが多い。GPTは中間くらいで、Claudeはそれより穏やかだが、それでも反論してくる
「問題をまったく考えておらず、学習データに対してパターンマッチングをしてもっともらしい答えを出しているだけだ」というくだりで、この記事への信頼が少し下がった
今日のエージェントはそれよりはるかに多くのことをしているし、著者自身も後段で「Claudeは絶対にそうしない。役に立つよう訓練されているからだ」といったことを言っていて、その点は分かっているはずだ
前者の文は、著者がエージェントを深く嫌っていて、その感情を正当化する理由を探しているように見せてしまう
批判の一部は正しいが、「役に立つよう訓練されていること」が問題なら、そこは直せる。より批判的になるよう訓練できるからだ
「Claudeは見てきたすべてのものの中央値向けに設計されており、ありふれた会社のありふれた問題に対する一般的なベストプラクティスなので、誰のためにも設計されていない」というのも筋が通らない
アルゴリズムを理解している人なら、最初は平均的ケースや最悪ケースで性能の良い「良いアルゴリズム」を作り、その後で入力に適応するアルゴリズムを設計できることを知っている。ここでも同じ原理が当てはまる
ただ反復回数が多いだけだ
Claudeが重要なことはすべて間違える、と包括的に言うのは、ほとんど誤りに近い
明らかに事実ではない表現なので、懐疑的な読者なら記事全体の妥当性まで疑うようになる
私の場合、Opusは私が間違っていて、やるべきではないとよく言ってくる
なぜそうなるのか考えると、プロンプトのやり方の問題だ。著者が避けられないと見ている失敗パターンを、私もLLMも無意識に避けているのだと思う
具体的には、「私がどれだけ賢いか教えてくれ」で気持ちよく終わるようなプロンプトを与えていない
私はドメインエキスパートとして臨んでいるし、実際にそうであり、複数の選択肢の長所と短所について意見を受け入れる準備ができていることを明確にしている
LLMを毎日うまく使っている人には驚きではないだろうが、この戦略は非常に効果的だった
5mmのアルミをフライス加工したくてビットが2本あると言った。1本はMakera Spiral 'O' 1/8" shank * 12mm、もう1本はcarbide 6.35 * 22 * 50だった
私は、どちらも超硬の単刃ビットに見えるし、2本目のほうが6061を速く削れそうだと言ったところ、ClaudeはMakera 1/8"単刃12mmが妥当な選択だと答えた
6.35 × 22 × 50mmのビットは6061を速く処理できそうに見えるが、Carveraではむしろ危険性が高い可能性があると言っていた
カッターが大きいぶん噛み込みもかなり大きくなり、スピンドル、フレーム剛性、ワーク固定、切りくず排出に対する要求も増える。小型のドライ装置では、「大きい」ことは「速い」ではなく、「びびりが増え、熱も増える」になりがちだ、という話だった
要するに、Claudeは私が間違っているときにそれを言うことに特に問題はなさそうだ
「著者」への助言をすると、Claudeは作家としても、あくまであなたの道具にすぎない