Skip to Content
Docs07. ケーススタディよくあるアンチパターン集(横断)
中級anti-patternsai-agent更新: 2026-07-05この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

よくあるアンチパターン集(横断)

この記事の目的

本ライブラリの各記事に分散しているアンチパターンのうち、特に頻度と被害が大きいものをライフサイクル順に一覧化し、設計レビュー・実装レビュー・振り返りの場でそのまま使えるようにします。各項目の詳細と処方箋は、リンク先の記事が正です。

対象読者

  • Agent プロジェクトの設計・コードレビューを行うエンジニア・テックリード
  • 「うちのプロジェクトが今どの罠にはまっているか」を短時間で棚卸ししたい人

前提知識

  • 特定の前提記事はありません。各項目のリンク先を必要に応じて参照してください
  • ライブラリ全体の地図は 学習ロードマップ を参照してください

本文

概要: アンチパターンの 3 つの共通根

個々の失敗は多様に見えますが、根をたどると多くが次の 3 つに行き着きます。

  1. 自律性をタダだと思う — 自律性はコスト・レイテンシ・不確実性・攻撃面で支払う「買い物」です。必要最小限に絞るという判断が抜けると、企画から運用まで全段階で罠が生まれます(Workflow 型 vs Agent 型の使い分け)
  2. 従来ソフトウェアの直感を持ち込む — 決定的なコードの直感(1 回テストすれば OK、変更の影響は局所的、エラーは例外で現れる)は、非決定的で非局所的な LLM には通用しません
  3. モデルへの指示を強制と混同する — プロンプトに書いた禁止・注意は「お願い」であり、コードで強制される制御(ガードレール)とは別物です

以下の一覧で自プロジェクトを点検するときも、個別の症状より「どの根から生えているか」を見ると、対策がまとまります。

詳細: 企画・設計段階

アンチパターンなぜ問題か処方箋
とりあえず Agent 化固定パイプラインで足りるタスクに自律性のコスト(不安定・高価・遅い)だけを支払う設計判断フローを通す(Workflow 型 vs Agent 型の使い分け)
自律性の上限を決めずに作り始める暴走時の影響範囲が見積もれない停止条件・ツール権限を最初に設計(AI Agent とは何か)
デモの成功率で本番投入を判断デモは成功しやすい入力に偏っており、実運用の分布とずれる投入前に評価設計(Agent 評価の基礎)
初手からマルチエージェント複数の Agent ループが、それぞれ独立したコンテキストを持って分担・協調する構成。複雑さ・コスト・デバッグ困難が先に来る。多くは単一 Agent で足りる単一で限界を確認してから分割(シングルエージェントとマルチエージェント)

詳細: 実装段階

アンチパターンなぜ問題か処方箋
ツール説明文が名前の言い換えだけいつ使う・使わないが伝わらず、誤用と不使用の両方が起きる用途・制約・形式例まで書く(ツール定義の設計)
「念のため」全ツールを常時渡す選択ミスとトークンコストが増え、攻撃面も広がるタスク種別ごとにツールセットを絞る(ツール使用)
停止条件がモデル任せだけ「完了」を出し損ねると無限ループ・コスト暴走最大ステップ数・タイムアウト・コスト上限をコード側に置く(Agent ループ)
プロンプトで直せない問題をプロンプトで直し続けるツール設計・アーキテクチャ起因の問題は指示の追加では直らず、プロンプトが肥大化する問題の切り分け表で原因の層を特定(Agent 向けプロンプト設計)
生のツールログをユーザーに流す読めない上に、内部データ・秘密情報の画面流出になるユーザー語彙への変換層を挟む(ストリーミングと Agent の UX 実装パターン)
フレームワークをデモの豪華さで選ぶ可観測性トレース・メトリクス・ログといった外部出力から、システム内部で何が起きたかを説明できる性質。Agent では技術メトリクスに加えて品質シグナルの設計が必要になる。・再開・保守というつらい部分はデモに映らない選定軸チェックリストで要件と照合(フレームワーク選定ガイド)

詳細: 評価段階

アンチパターンなぜ問題か処方箋
平均スコア 1 本で品質管理数値が動いても理由が分からず、行動につながらないケース単位の合格/不合格と失敗一覧を一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。に(Agent 評価の基礎)
検証なしで judge を信頼judge の誤判定に向かって本体が「最適化」されていく人手ラベルとの一致率を測ってから使う(LLM-as-a-Judge)
期待する軌跡との完全一致を要求正しい別解を不合格にし、変更のたびに大量に壊れる不変条件(安全性・マイルストーン・上限)だけを縛る(軌跡(trajectory)評価)
全ケースを E2E で毎 PR 実行コストと時間が破綻し、やがて誰も回さなくなるレイヤ分けとトリガ設計(回帰テストと CI 組み込み)

詳細: 運用段階

アンチパターンなぜ問題か処方箋
最終応答だけをログする「たまに変」を再現も分析もできないループの全ステップを構造化記録(可観測性とトレーシング)
月末の請求書でコストに気づく原因特定も対策もできないタスク単位の計測と日次アラート(コスト管理)
モデルをエイリアス参照で本番運用ベンダー側の更新で無告知に挙動が変わるスナップショットにピン留めし、更新は計画タスクに(バージョニング・デプロイ・モデル更新追従)
止める手段がデプロイしかない封じ込めまでの間、被害(コスト・誤操作)が進行し続ける粒度別のキルスイッチインシデント時にデプロイなしで Agent を止める・自律度を下げるための、事前に用意された停止手段。全停止・縮退・ツール単位の無効化など粒度を分けて設計する。を事前に用意・演習(インシデント対応)

詳細: セキュリティ

アンチパターンなぜ問題か処方箋
モデルの拒否を防御として当てにする安全学習は迂回されうる。保証ではない決定的な制御(権限・承認・ガード)を主防御に(Agent の脅威モデル概観)
プロンプトの禁止指示で「対策済み」指示はインジェクションで上書きされうる「お願い」コードで強制されるガードレールモデルの判断の外側でコードとして強制される制御。入力・出力・アクションの 3 層に配置し、プロンプトでの指示(お願い)と区別される。を実装(ガードレール、プロンプトインジェクション)
全権のサービスアカウントで Agent を動かす混乱した代理人問題。ユーザーが権限外のデータに Agent 経由で届くユーザー権限の継承と実装側の認可(ツール権限設計とサンドボックス)
致命的三重奏非公開データへのアクセス・信頼できないコンテンツへの接触・外部への送信能力の 3 つが 1 つの Agent に揃うと、データ持ち出しが構造的に可能になるという設計チェックの枠組み。を 1 つの Agent に揃える間接インジェクション 1 発でデータ持ち出しが構造的に可能になるどれか 1 つを外すか、送信前承認で断つ(データ漏えい対策)

設計判断: この一覧の使い方

  • 設計レビューの冒頭 10 分で、企画・設計段階とセキュリティの表を通します。この 2 つは後から直すコストが最も高い層です
  • 実装・評価・運用の表はフェーズゲート(実装完了時・投入前・運用開始 1 か月後)で見直します
  • 各項目は「発見したら該当記事のチェックリストへ飛ぶ」入口として使います。この一覧自体は診断用で、処方の詳細は各記事が正です

実務での注意点

アンチパターン

この記事自体がアンチパターン集のため、ここではこの一覧の使い方に関するメタなアンチパターンを挙げます。

チェックリスト

  • 設計レビューで企画・設計段階とセキュリティの表を通した
  • 該当したアンチパターンについて、リンク先記事のチェックリストで詳細を点検した
  • 「該当しない」と判断した項目に、理由を一言添えた
  • 投入前・運用開始後のフェーズゲートで再点検する予定が入っている

関連トピック

参考資料

TODO・未確認事項

なし

セクション概要ケーススタディ: 経費精算アシスタントの段階的 Agent 化