38. プロンプトで禁止しても3回再発した — 指示と機械検査の使い分け
この記事で分かること
プロンプトの禁止指示だけでは再発する問題を防ぎたいとき、機械検査へ切り替える判断基準が得られる。3回再発した事例から、揺らぎを許容できる指示と確実に止めるべき検査の使い分けを学べる。
関連ニュース
#2 AIエージェントチーム誕生1週間、朝の調査依頼がその日の深夜にMVPになっていた
AIエージェントチームの運用例から、調査依頼から試作までを1日で進める進め方が参考にできる。朝に依頼した調査が深夜にはMVP（試作品）として動いていた状況を示しており、自律的なタスク進行の目安になる。
Claude Codeの質問を「自由記述」から「選択肢」に変えさせる方法
Claude Codeの質問形式を自由記述から選択式に変えるプロンプトの書き方が分かる。候補を列挙して選ばせるよう形式を限定することで、回答のぶれを抑え、操作を簡潔にできる。
自己改善ループが3回死んでいた話 — 「復旧しました」を3回書いたAIエージェントの観測設計
AIエージェントが復旧を誤って報告し続ける問題を防ぐ観測設計が分かる。同じ「復旧しました」を繰り返した事例から、復旧判定の条件と観測項目を分けて設計する必要が読み取れる。
Kubernetes マニフェストレビューは「どこで評価するか」と「どう扱うか」を分けて設計する
レビュー運用の設計指針が得られる。評価する場所と結果の扱い方を分離することで、指摘の品質と運用負荷を調整しやすくなる。
実質、私は何もしていない — Claude CodeにGTDを組み込んだら、優秀なのはAIエージェントではなく「仕組み」だった
GTDを自動化する際の設計判断として、AIエージェントの性能より仕組みの方が重要だと分かる。Claude CodeにGTDを組み込んだ事例から、人間の介入を減らすために仕組み側へ持たせる要素を検討できる。
lint は PASS した。でも 1 行も読んでいなかった — 自作ゲートが嘘をつく 3 つの型
コード品質ゲートが通過しても見逃される問題の型が3つに整理され、チェック工程を補強する視点が得られる。lintだけで確認済みと判断せず、どの範囲を読んだかを担保する運用の判断材料になる。