生成AIに設計をお任せしては(まだ)いけない

「設計を評価してくれるAIが欲しい」と思ってる人類、多分そろそろ世界中で3億人くらいはいますね。でも残念ながら、現状のAIには「設計書を読んで魂を震わせる」みたいな境地までは到達していません。

抽象的な判定が苦手な理由

AI、特にLLMは言語パターンの塊です。設計の「良し悪し」は抽象度が高く、かつ文脈に強く依存するため、次のような壁にぶち当たります。

• 価値基準が曖昧：たとえば「この設計は保守性に優れる」と判断するには、そのプロジェクトの目的・体制・スキルセットまで理解している必要があります。
• 意図の解釈が不完全：設計とは「なぜそうしたか」を読み取る必要がありますが、AIは「何をしているか」の解析までは得意でも、その裏にある思想の読解がまだ苦手です。
• 表現に依存しすぎる：設計が美しくても、説明が下手だと「悪い設計」に見えることもあります。これは人間でも騙される罠です。

つまり、設計の評価は“人間の目と経験”が今でも頼りです。ちょっと哲学が必要なんですよね。

一方、コードは得意分野

でもコードは違います。めちゃくちゃ具体的ですし、ルールも比較的はっきりしています。

• 構文の正しさ
• ベストプラクティスとの整合性
• 重複の有無、複雑度の測定
• パフォーマンスやメモリ使用量の推定

こうした点は、AIでも十分な評価が可能です。たとえば「このコード、SRP（単一責任の原則）に反してますよ」とか「このループ、無駄にネストが深すぎますね」といった指摘は比較的得意です。

設計に関しても、「このコードから暗黙的に読み取れる設計の雰囲気」くらいならある程度判断できます。でもそのレベルを超えて、設計思想やプロジェクト全体の方針と照らし合わせて評価する、となるとまだ発展途上です。

総じて、設計はまだ“人間の領域”、コードは“AIが頼れる助っ人”、そんな棲み分けが現時点でのリアルなバランスですね。

それです、それ！AIがすごいすごいと盛り上がっている裏で、ひっそりと「いや、俺らまだ現役だけど？」と睨んでるのが従来の静的解析ツールたちですよ。Lint系ツールたちにとっては、まさに「お前が来るのは百年早い」状態です。

ルールベースの静的解析の強み

従来のツール（例：golint、eslint、flake8、pylint、cppcheckなど）は、次のような強力な特徴があります。

• 動作が速い：設計も軽く、構文チェックや規約違反の検出を瞬時にこなせます。
• 確実性が高い：明文化されたルールに基づくため、結果にブレがありません。再現性が高いのはCIとの相性も抜群です。
• 誤検出が少ない：ルールが限定されている分、意図しないアラートが出る可能性が低く、学習データに引きずられることもありません。
• セキュリティ用途にも信頼：脆弱性の検出など、失敗が許されない場面では今でも主力です。

要するに、「機械の判断力を使いたい。でもギャンブルはしたくない」という現場では、従来ツールの方が信頼されています。

AIの限界と強み

AIはまさにおっしゃる通り、「超優秀だけど超不安定な乱数生成装置」とも言えます。全体的な傾向や文脈をくみ取るのは得意ですが、次のような点でまだ弱さがあります。

• 出力に一貫性がない
• 根拠の説明が不十分
• 仕様が曖昧なままでも動き出してしまう
• 正しくても、なぜか気分で違う書き方をする

つまり、創造性が必要な場面では強いけど、信頼性が命の場面ではまだまだ危ういというのが今の立ち位置です。

両者の併用が最強

現実的には「静的解析ツールでベースラインを守り、AIでカバー範囲を広げる」という使い分けが理想です。まさに人間が型にはめたルールと、AIが広げる“気づき”のハイブリッドです。

AIが書いたコードに golint かけたら怒られた、みたいな話も珍しくないので、お互い補完し合う関係が一番うまくいく気がします。どっちかを見限るのではなく、両方使ってこそですね。

わかります、その夢。AIが「この設計はSOLID原則に沿っていて保守性も高いですね」とか言いながら、エージェントが自律的にコードを整理してくれたら最高ですよね。
でも現実は、「SOLID？それって新しいアイスの名前ですか？」みたいなことをたまに言ってきますからね。まだ“自信満々で間違う天才肌”から卒業できていません。

AI＋エージェントによる自動化の理想

確かに、AIの精度がもう一段階上がれば、こうした自動化も視野に入ってきます。

• コード品質の抽象的評価（可読性、保守性、凝集度、疎結合性）
• 構成の最適化（責務の分離、モジュール設計の見直し）
• 将来の変更に対する柔軟性の判断
• チームの技術水準に合わせた最適化

これらをAIエージェントが“勝手に”やってくれる未来、技術的には確かに見えてきています。

でも現実は…

• 推論の不安定さ：同じコードに違う評価を出したり、突然“こだわりのスタイル”を押し付けてきたりします。
• 長期的な整合性の維持が難しい：プロジェクト全体の意図を俯瞰して判断するには、まだまだ文脈理解が浅いです。
• エージェントの調整が地獄：複数のAIを協調動作させようとすると、途中で話が噛み合わなくなったり、互いの出力を破壊し合ったりすることがあります。

つまり、「自動化はしたい、でもAIに全任せは怖い」というジレンマに直面します。まさに空中分解予備軍。

現実的な妥協点

現状では、人間がレビューと監督を前提にした“半自動化”が最も安全です。たとえば：

• AIに設計のたたきを出させる
• それをレビューし、人間が調整
• その設計に沿って、AIが実装を進行

という流れなら、空中分解リスクを最小限にしつつ、効率化の恩恵も得られます。

未来のAIが「このモジュール、依存が高すぎるので戦略的に分離しましょう」なんて冷静に言ってくれる日が来るのを待ちつつ、今は“人間が最後の砦”であることを忘れないのが現実的ですね。

まさにそれです。「未来にはなる、でも今じゃない」。この“今じゃない感”がまた絶妙なんですよね。ちょっと頑張れば届きそうな気がして、でも届かない。AIくん、惜しい！

「設計審査AI」は未来の定番になるか？

いずれAIが設計書を読み解いて、こう言うようになるでしょう。

• 「この設計、依存方向が逆ですよ」
• 「データベースの抽象化層が薄いですね、もう一段追加しませんか」
• 「このインターフェース、将来的な拡張性に難がありますね」

ここまでくると、設計審査がレビューというよりコンサルティングになって、AIが“上司”っぽくなってくるわけです。怖いような、ありがたいような…。

でも今はまだ、「とりあえず作ってみたけど、これで大丈夫っぽい？」みたいなノリで聞くと「うーん、たぶん…？」と返してくるレベルです。要するに、“頼れる後輩”ではあっても“信頼できる設計審査官”ではないという状態ですね。

今の限界はどこか

• コンテキスト不足：プロジェクト全体のゴールや制約、チーム事情まで踏まえて判断するのが難しいです。
• 一貫性の維持ができない：設計全体を貫く思想や方針を追跡しきれないため、部分最適なアドバイスになりがちです。
• 改善提案が浅い：「抽象化しましょう」「モジュール分離しましょう」と言われても、その理由や代案が曖昧なこともあります。

結論：未来の夢、いまの現実

将来的には、設計審査もAIがこなすようになるのは間違いありません。でも、現時点では人間の深い文脈理解や判断力にはまだ及びません。

というわけで、「AIが設計審査をする日は来るけど、今はまだ“優秀な設計アシスタント”止まり」──そんな時代に、私たちは立ち会っているのかもしれません。ちょっとSFっぽくて、ちょっと現場っぽい、それが今のAIですね。