Claudeで発生した設計ミスリードの実例

─ AIはなぜ“正しそうに間違える”のか

はじめに

こんにちは。上乃木の野田です。

最近、Claude（Opus 4.7 MAX）を使って、Webアプリケーションの設計仕様を壁打ち（AIと議論）する機会がありました。

設計段階からAIを活用することで、思考の整理がしやすくなったり、選択肢を広げやすくなったりする場面は多いと感じています。実際、壁打ち相手としては非常に有用で、設計の初期検討を前に進めるうえで助かることも少なくありません。

一方で、実際にやり取りを進める中で、

「この提案は一見もっともらしいけれど、そのまま採用すると危ないのではないか」

と感じる場面がありました。

今回は、その中でも特に印象に残った2つの事例を整理しながら、なぜこのようなことが起きるのか、実務ではどのように向き合うべきかをまとめてみます。

本記事でお伝えしたいこと

今回の事例を通じて、あらためて感じたことは次の通りです。

• AIの提案は、一見すると妥当に見えることがある

• ただし、設計全体で見ると整合性が崩れている場合がある

• 特に、セキュリティやデータ保全の観点では、人間による確認が欠かせない

AIは非常に便利な支援ツールですが、出力結果をそのまま正解として扱うのは難しい場面がある、というのが今回の実感です。

事例①：root実行に関するミスリード

背景

バックアップ処理の実行方式を検討していた際に、AIから次のような趣旨の提案がありました。

システム管理作業はroot実行がLinuxの標準

この表現だけを見ると、いかにも一般的な運用知識のように見えます。

確認して分かったこと

ただ、あらためて整理してみると、この提案には注意が必要でした。

たしかに、歴史的な経緯としてroot実行が広く使われてきた場面はあります。実際にそのような運用がなされている現場は多いです。非上場企業になると特に多い印象です（上場している会社でも見かけたことあります）
しかし、それをそのまま現在のベストプラクティスとして扱ってよいかというと、そこは別の話です。

現在の運用やセキュリティの考え方では、最小権限の原則に沿って、必要な権限だけを与える構成が重視されることが多くなっています。その意味では、

• 歴史的な慣習

• 現在の推奨設計

が混ざってしまっていた、と見るのが自然だと思います。

この提案のどこが問題だったのか

今回のケースでは、AIが

「昔からよく使われてきたやり方」

を

「現在も推奨される標準的なやり方」

として提示していたように見えました。

このずれは小さく見えるかもしれませんが、実務では意外と見逃しにくいポイントです。特に、文章としては非常に自然に読めるため、忙しい場面ではそのまま受け入れてしまう可能性があります。

実務上はどう考えるべきか

このケースでは、より自然なのは次のような方針だと考えています。

• 専用ユーザーで実行する

• 必要最小限の権限に限定する

• systemdなどで実行主体を明示的に制御する

つまり、AIの提案自体が完全に意味不明だったわけではなく、言葉の強さに対して根拠の置き方がずれていた、という理解です。

事例②：復旧設計におけるデータ消失リスク

背景

次に、SSHロックアウト時の復旧方法を検討していたときの話です。

AIは、概ね次のような方向性を提案しました。

• SSHロックアウト時はPulumiで再構築する

• パスワード認証は無効化しても問題ない

これも、局所的に見ると合理的に見える提案でした。復旧方法を整理し、不要な認証経路を減らすという意味では、考え方自体は分かりやすいものです。

別観点から確認すると問題が見えた

ただ、この提案を既存の設計と照らし合わせると、見落とせない問題がありました。

既存設計では、セッション録画データがローカル保存であり、バックアップ対象に含まれていない前提になっていました。つまり、再構築を実行した場合、録画データが消えてしまう可能性があります。

この録画データは、単なる補助情報ではありません。例えば、

• 顧客対応の記録

• トラブル対応の経緯

• 後から確認したい証跡

といった、業務上重要な情報を含むことがあります。

そのため、復旧のつもりで再構築した結果、事業上重要なデータを失う設計になってしまうのは、かなり影響が大きいと考えられます。

この事例の本質

このケースで起きていたことを整理すると、次のようになります。

• 復旧経路を単純化していた

• その一方で、データ保全の観点が抜けていた

• 設計全体としての整合性確認が不足していた

つまり、ひとつひとつの説明は分かりやすくても、全体として見ると成立していなかった、ということです。

2つの事例に共通していたこと

今回の2件は内容こそ異なりますが、共通点はかなりはっきりしていました。

• どちらも局所的には筋が通って見える

• 文章としても自然で、違和感が少ない

• しかし、前提や周辺設計を確認すると問題が見えてくる

AIは不自然な間違い方をするのではなく、自然な文章のまま、設計上の重要な前提を外してくることがある。今回強く印象に残ったのはこの点でした。

なぜAIは設計を誤るのか

1. 局所最適になりやすい

AIは、その時点で与えられている文脈の中では、それなりに筋の通った答えを返してきます。逆に言うと、システム全体で本当に整合しているかまでは、別途確認が必要です。

2. 横断的な参照が弱い

設計書A、設計書B、運用ルール、障害時の復旧方針など、複数の資料をまたいで整合性を見る作業は、人間側で意識的に行わないと抜けやすいと感じました。

発生時の設計書の規模は全16章（16ファイル）合計418,915 文字でした。設計フェーズの適切なタイミングで、設計書を細分化したほうがよさそうだと思いました（人間の可読性は低くなりますが）

3. 強い表現が自然に混ざる

「標準」「推奨」「一貫性がある」といった表現は、文章として読むと説得力があります。ただし、こうした言葉が出てきたときほど、本当に根拠があるのかを確認したほうがよい場面もあります。

AI設計を実務で安全に使うための対策

1. AIの提案をそのまま採用しない

まずは「候補のひとつ」として受け取り、前提条件を人間が確認することが重要です。

2. 別の観点から見直す

• セキュリティ

• データ保全

• 運用性

• 障害時の影響

こうした観点を追加すると、局所的には正しく見えた提案の弱点が見えやすくなります。

3. 関連する設計を横断的に確認する

単独の会話だけではなく、関連ドキュメントや既存設計と照合することで、整合性の崩れに気づけることがあります。

4. 最悪ケースを想定する

「この設計が外れたときに、何が壊れるのか」を言語化してみると、判断の精度が上がりやすいと感じています。

まとめ

Claudeを含め、AIは設計支援のツールとして非常に有用です。初期検討、壁打ち、論点整理といった用途では、実務上かなり助かる場面があります。

ただし、その一方で、設計レビューをそのまま任せられるかというと、まだ慎重に見たほうがよいと感じています。

特に、

• 複数の設計領域が絡むケース

• 復旧やデータ保全が関係するケース

• 強い表現で方針が提示されるケース

では、人間が前提と影響範囲を確認することが欠かせません。

今回の2つの事例は、AIが使えないという話ではなく、AIをどの層で使い、どの層を人間が担保するか を考える材料になったと感じています。

おわりに

今後もAIを使った設計支援は広がっていくと思いますし、私自身も引き続き活用していくつもりです。

そのうえで、便利さだけを見るのではなく、

• どこまでを任せるか

• どこからを人間が検証するか

を明確にしておくことが、実務ではますます重要になりそうです。

今回の内容が、AIを設計やレビューに取り入れている方にとって、何かしらの参考になれば幸いです。