AIコーディングツールは「動くコード」を高速で書ける一方、設計の一貫性・セキュリティ・プロジェクト全体の文脈理解が構造的に苦手。国内調査では86%が生産性向上を実感する一方、67.1%が課題・不満も自覚している。本記事では苦手な5領域を、インフラエンジニア視点の具体的な対処法とセットで解説する。
「AIに任せたら一見動くのに、レビューすると設計が崩れている」——そんな経験はないだろうか。この記事を読むと、AIコーディングツールが構造的に苦手な5つの領域と、CLAUDE.mdやセキュリティチェックリストなど現場で効く対処法がわかる。
AIコーディングツールは本当に信頼できる？──86%が実感、でも約7割が不満
結論、AIは「補助」としては優秀だが「丸投げ」には向かない。国内調査では86%が生産性向上を実感する一方、67.1%（約7割）が課題・不満も抱えている。
内訳を見ると、問題の本質は「精度」よりも「意図とのズレ」にあることがわかる。
| 調査結果 | 割合 |
|---|---|
| 生産性向上を実感している | 86.0% |
| 何らかの課題・不満を自覚している | 67.1% |
| 意図しないコードが生成される | 54.9% |
| 提案コードの精度が低い | 37.2% |
| セキュリティ・ライセンスへの懸念 | 34.1% |
出典：キッカケクリエイション調べ（2025年11月・ITエンジニア437名／@IT報道）。ここから言えるのは 動くコード ≠ 正しいコード ≠ 安全なコード ということ。AIの出力は、レビューを前提に扱う必要がある。どのツールを選ぶかで迷っているなら、GitHub Copilot・Claude Code・Cursorの徹底比較も参考にしてほしい。
なぜAIは設計の一貫性を保てないのか？（苦手①）
AIは目の前の指示を最短で満たそうとするため、全体設計を侵食する。「局所最適」は得意でも「全体最適」を考慮できないからだ。
例えば「注文処理にメール通知を追加して」と頼むと、AIは OrderService に直接メール送信ロジックを埋め込む。動きはするが、責務が崩れて後から技術的負債になる。
ありがちな失敗
機能追加を繰り返すうちにOrderServiceが肥大化。テストもしづらくなり、気づけば「誰も触りたくないクラス」が完成している。
対策：設計ルールをCLAUDE.md / .cursorrulesに明文化する
「通知系は必ずNotificationService経由」のような制約をプロジェクトのルールファイルに書いておけば、AIはその境界を守って実装する。
AIが生成したコードはなぜ危険？セキュリティの落とし穴（苦手②）
AIは「セキュアであること」を明示しない限り考慮しない。Veracodeの調査（2026年3月更新）では、AI生成コードの約45%——ほぼ半数に脆弱性が含まれると報告されている。
典型的なのが、JWTの署名検証漏れ・入力値検証なし・CSP（コンテンツセキュリティポリシー）未設定といったWeb側の不備だ。
そしてインフラエンジニアとして見過ごせないのが IaCコードの危険な初期値。AIが生成したTerraformには、こんな地雷が頻出する。
AI生成IaCで頻出する危険設定
・セキュリティグループが 0.0.0.0/0 で全開放
・IAMロールに AdministratorAccess を付与
・S3バケットがパブリック設定のまま
こうしたstate管理やモジュール設計の落とし穴は、Terraformモジュール設計の失敗例とState管理でも詳しく触れている。対策はセキュリティチェックリストを必ずAIに渡すこと。「SGは最小権限」「IAMは必要なActionのみ」と前提を与えるだけで出力は大きく変わる。何をチェックすべきかを体系的に押さえておくと、レビューの精度が一段上がる。
Slopsquattingとは？AIが存在しないパッケージを作る問題（苦手③）
AIは平然と「存在しないパッケージ名」を提案する。これを悪用した新手のサプライチェーン攻撃が Slopsquatting だ。
仕組みはこうだ。AIがハルシネーションで架空のnpm/PyPIパッケージ名を生成し、攻撃者が同じ名前で悪意あるパッケージを公開、それと知らずインストールしてしまう——という流れで被害が広がる。実際、オープンソースのLLMは約21.7%の確率で架空のパッケージ名を生成し、その43%は同じ名前が繰り返し出現するという研究もある。攻撃者はこの予測可能性を先回りして悪用する。
対策：依存関係は必ず公式リポジトリで確認する
npm install や pip install の前に、パッケージの実在・ダウンロード数・メンテ状況をチェックする習慣をつける。lockファイルとSBOMの管理も有効だ。
AIはなぜプロジェクト全体を記憶できないのか？（苦手④）
AIはセッションをまたぐと直前の決定を忘れる。コンテキストウィンドウの制約上、大規模コードベース全体の整合性を保ち続けられない。
「前回はリポジトリパターンで統一したのに、今日は別の書き方を提案される」——これは記憶しているのではなく、毎回ゼロから推測しているために起きる現象だ。
対策：決定事項を外部ファイルに固定する
CLAUDE.md・.cursorrules・GitHub Copilot Instructions に設計方針やコーディング規約を書いておけば、毎セッション自動で読み込まれ「記憶」の代わりになる。トークン消費も抑えられて一石二鳥だ。
運用コストが気になる場合は、Claude Codeのトークンコスト削減設定術も合わせて確認しておくとよい。
AIに組織固有の判断を任せてはいけない理由（苦手⑤）
AIは一般論で答える。チーム規模・ビジネス戦略・組織の事情を踏まえた意思決定はできない。
「在庫管理と注文管理を分割すべき？」と聞けば、AIは教科書的な一般論を返す。だが正解はチームの人数や今後の事業計画に依存し、文脈なしには決められない。
設計は意思決定であり、責任を伴う行為だ。AIに責任は取れない以上、組織固有の判断は人間が握る必要がある。
対策：「AIに考えさせる範囲」と「人間が決める範囲」を線引きする
実装の選択肢出しやたたき台作成はAIに任せ、最終的なアーキテクチャ決定は人間が下す。役割を分けるだけで事故は大きく減る。
まとめ：AIが得意なタスク・苦手なタスクの仕分け
AIコーディングツールは「得意な仕事」に集中させ、苦手な領域は人間が補う。これが2026年現在の最適解だ。
| タスク | AIの信頼度 | 人間の関与 |
|---|---|---|
| 定型コード・ボイラープレート生成 | ◎ 高い | レビューのみ |
| テストコードの雛形作成 | ◯ そこそこ | 観点の追加 |
| アーキテクチャ設計 | △ 低い | 人間が主導 |
| セキュリティ設計 | △ 低い | 必ずチェック |
| 組織固有の意思決定 | × 不可 | 人間が決定 |
インフラエンジニアの実感として、AIは「手を速くする道具」であって「頭脳の代替」ではない。設計とセキュリティの最終判断は人間が握り、テスト・Lintの自動実行（ハーネスエンジニアリング）でAIの「よくない出荷」を止める。この役割分担ができれば、AIは強力な戦力になる。
まずはCLAUDE.mdを1枚用意することから始めてほしい。セキュアコーディングやAI活用を体系的に学びたいなら、実務に直結する講座で土台を固めるのが近道だ。
コメント