記事一覧
失敗・障害
この主題の公開記事を一覧で確認できます。各記事に、根拠の確認状況と未確認事項を示します。
- AI失敗事例・事故解剖大全AI事故はモデルが誤った瞬間だけを指すものではない。業務上の事故は、モデル・データ・ツール・製品制御・人間確認・通常のソフトウェア基盤の複数層を通って成立する。公開事例は各製品の現在の失敗率を示すものではなく、どの防護線が必要かを学ぶための事例として扱う。失敗・障害失敗・障害公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない
- AIレッドチーム／耐障害運用編プロンプトインジェクションやエージェント乗っ取りへの耐性は、モデル単体での拒絶ではなく、システムの封じ込めと復旧の問題として扱う。外部文書、Web、メール、RAG、コネクタ、MCP/ツールなどの信頼できない入力が、権限を持つアクションやデータと同じ意思決定ループに入ることを前提とし、最小権限、決定論的なポリシーと承認、サンドボックス/送出/機密情報の分離、モニタリング、停止/ロールバック、適応的なホールドアウト評価、無害な有用性、および未確認事項（不明）境界の維持を行う。失敗・障害失敗・障害公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない
- AIアンチパターン集AIアンチパターンは、特定技術を使うこと自体ではなく、有効な技術を責務や適用条件を無視して万能化するところから生じる。長いコンテキスト、RAG、Agent、会話記憶情報はいずれも有用だが、正本、権限、状態、検証、復旧まで一つの層へ背負わせると、性能・安全性・監査性・費用のどこかで破綻しやすい。技術名ではなく、責務分離と失敗包絡で診断する。失敗・障害失敗・障害公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない
- Coding Agentの依存関係のハルシネーション／Slopsquatting防御AIが生成した依存パッケージ名は導入候補として扱います。存在確認、正常なhash、出典・来歴、既知脆弱性scanのいずれも単独では安全性を保証しません。導入前の承認主体の識別と、実際に取得する成果物の主体の識別・bytesを結び付けて確認する運用が必要です。この運用は設計上の提案であり、特定製品の防御率を実証したものではありません。失敗・障害失敗・障害公式仕様のみ公式仕様のみ現行現行として扱う
- Agent-to-Agent／マルチエージェント編 — A2A v1.0、framework内引継ぎ/担当を分けたエージェント/複数工程の制御、MCPとの役割差を横断し、委譲・文脈・入力情報・主体の識別/認可・失敗伝播・人による確認・評価を別契約として整理する「マルチエージェントは、複数のAIを並べれば自動的に賢くなる仕組みではない。まず『どう接続するか』と『誰が仕事を割り振り、誰が最終判断を持つか』を分けて考える必要がある。A2Aは異なるエージェント同士が能力を発見し、taskや成果物を交換するための相互運用protocolであり、manager、引継ぎ、parallel 処理の流れなどの複数工程の制御方式そのものを決めない。MCPも別の層で、主にagentとツール/dataを接続する。さらに、仕事を別agentへ委譲したことは、そのagentへ利用者の権限や認証情報をそのまま渡してよいことを意味しない。文脈・入力情報、主体の識別、認可、human 承認、失敗・終了状態、監査を別々の契約として設計する。複数agentでは、重複作業、引継ぎ欠落、誤った終了判定、deadlockやresource contentionも起こり得るため、最終task成功率だけでなくcoordinationそのものを評価する。」失敗・障害失敗・障害公式仕様のみ公式仕様のみ現行現行として扱う