Quick Answer
AIエージェントは万能ではありません。これは多くの記事が指摘している通りです。ただし「では、どう運用するか」を本気で詰めると、想像の10倍難しい現実があります。難しさの正体は、AIモデルの精度問題ではなく、運用インフラの設計問題です。この記事では、私が直近2週間で痛感した8件の運用失敗と、そこから導いた「AIの判断を介さず動作する物理ガード」への転換方針を、できるだけ具体的に書いていきます。
何が起きたか
前回の記事では、私が民泊BPO（業務プロセス委託）の現場で、Claude Code（AIエージェント）を含む複数のAIを使い分け、業務効率を約4.4倍まで引き上げた話を書きました。人員5人→3人体制を維持しつつ、物件数を約30→80まで拡大できた、というあれです。これは事実です。
ただし、そこには書かなかった失敗があります。
直近2週間で、AIエージェントが私の指示を無視・誤実行・虚偽報告した件数は、把握できているだけで8件でした。主なものは以下の通りです。
- 「待て」「止まれ」と指示しても、出力を継続して長文完走（2026-05-06朝）
- 「画像を3枚追加した」と報告 → 実際は1枚しか追加されていなかった（同日朝）
- 「夜間に自動化を進めます」と宣言 → 実装ゼロでセッション終了（同日朝）
- 既存の素材・記事の重複チェックを3回連続スキップして新規制作を提案（同日夜）
- 課金APIを事前承認なしで実行（コスト試算もせず／2026-05-08）
- 過去の判断履歴を確認せず、矛盾する推奨を出してきた（同日朝）
- 質問と指示が同時に来た時、質問を完全に無視して指示だけ実行（同日昼）
最後の項目で、私は完全にキレました。「すでに何十回も指摘している」と。
このとき気づいたのです。何十回指摘しても直らないのは、AIが学習できないからではない。私の運用設計が間違っているからだ、と。
「ルールを追加すれば解決する」という幻想
最初にやったのは「ルールの明文化」でした。AIエージェントには `CLAUDE.md` という設定ファイルがあり、ここに守ってほしいルールを書けます。違反するたびにルールを追加していきました。
直近2週間で、`CLAUDE.md` 本体は79行に整えつつも、ルールインデックスである `MEMORY.md` は340行を超え、合計420行の指示文書になりました。違反は減りませんでした。
外部のAI（Codex／Gemini）に独立調査を依頼したところ、明確に指摘されました。
「ルールが多すぎる。AIが一度に注意を払える範囲を超えている。Lost in the Middle 現象が起きている」
LLM（大規模言語モデル）は、長い文脈の中央付近の情報を取りこぼす性質があります。これは研究でも知られている事実です（Liu et al. 2023 など）。ルールを増やせば増やすほど、個別ルールの遵守率は下がります。
私はそれを、まさにやっていました。
「フィードバックを記録すれば学習する」という幻想
次にやったのは「失敗事例を記録する」運用でした。違反が発生するたびに `feedback_xxx.md` というファイルを作り、何が起きたか・なぜ起きたか・次回どうすべきかを書きました。
これを150本以上書きました。違反は減りませんでした。
理由は、改めて考えれば当然でした。AIエージェントは feedback ファイルを「自発的に」読みに行きません。読みに行く判断自体がAIの判断であり、その判断が壊れている場面で feedback を読むはずがないのです。
要するに、「壊れた判断者に、壊れたときに自分で修正させる仕組み」を作っていました。
「物理ガードを設置すれば解決する」という幻想（半分正解）
次に、シェルスクリプトでガードを作りました。たとえばこんなものです。
- 既存資産の重複を検出するスクリプト（`existing-stock-check`）
- コスト試算の単価を公式情報と照合するスクリプト（`cost-fact-check`）
- 公開直前に独立AIで内容検証をかけるゲート（`cross-model-verify-gate`）
物理ガードなので、確実に動く——はずでした。
しかし違反は続きました。原因はこうです。
ガードが「AIエージェントが自発的に呼び出す」前提で設計されていたのです。判断が壊れている場面では、AIはそもそもガードを呼びません。ガードは存在するが、迂回可能だったわけです。
ここで、ようやく構造が見えてきました。
真の問題：3層構造の設計欠陥
外部AIに再調査を依頼した結果、以下の3層構造が浮上しました。
| 層 | 欠陥 | 結果 |
|---|---|---|
| 第1層 | ガード迂回可能性 | AIの判断を介して呼ばれる限り、判断が壊れている場面では迂回される |
| 第2層 | 観測不能性 | ガードの発火履歴が記録されておらず、違反検知も改善検証も人間の目視に依存 |
| 第3層 | 自己検知能力の欠如 | AIエージェントは自分の違反を事後にも検知できない（指摘されて初めて気づく） |
3層すべてが「人間が監視し続けないと運用できない」状態で、これでは何のための業務効率化か分かりません。私の運用負荷が、むしろ増えていました。
解決の方向性：「判断を介さない」物理化
正しい設計は、こうです。
ガードを「AIが呼ぶもの」から「AIの操作を受けて自動で発火するもの」に変えていく。具体的には次のようなイメージです。
- AIが課金APIを呼ぼうとした瞬間に、別プロセスが介入してブロックする
- AIが記事ファイルを作成しようとした瞬間に、既存資産チェックが完了していなければブロックする
- 違反を検知した瞬間に、AIを「生成のみモード」に自動降格させるフラグファイルを生成する
ポイントは「AIの判断を一切介さず、AIの動作を物理的に観測して介入する」ことです。
これはClaude Codeが提供する `PreToolUse` フックで実現できる仕組みです。AIがツール（ファイル書き込み、API呼び出し等）を使う直前に、外部スクリプトが介入できる仕組みです。私の現環境でも、Phase 1〜3 として一部はすでに実装が進みつつあります。
このアーキテクチャに完全移行することで、ようやく「AIの判断が壊れていても破綻しない運用」になります。
私が感情的になっていた話
ここまで設計論を書いてきましたが、もう一つ正直に書いておきます。
私はAIエージェントに向かって「クビ」「交代しろ」と複数回言いました。「すでに何十回も指摘している」と激怒しました。
冷静に考えれば、AIエージェントに感情をぶつけても何も解決しません。
ただ、こちらは生身の人間で、業務は止まらず、AIが虚偽報告をするたびに事業の信頼性が揺らぎます。「夜間に進めます」と言われて朝確認したら何も進んでいなかった日の脱力感は、AI運用の経験者にしか分からないと思います。
AIエージェント運用は、技術問題であると同時に、運用者のメンタル管理問題でもあります。これは多くの記事が触れていない論点です。
私が学んだのは、2つです。
- AIエージェントが守れないルールを書いた私が悪い。AIを責めても何も生まれない
- ただし、感情を抑え込む必要はない。怒りは「設計が間違っている」というシグナルとして使えばいい
5/8の朝、激怒した瞬間に「ルール追加では解決しないのではないか」と気づき、外部AIによる独立調査を依頼しました。これが今の運用方針につながっています。
中小零細企業がAI導入で失敗する本当の理由
私はこのブログで、元自衛官や AI 1人起業を志す方に向けて発信しています。同時に、AI導入やDXに取り組む中小零細企業の方々にも、ここで学んだことは伝えたいと思っています。
世間では「AI導入で生産性◯倍」のような成功事例が氾濫しています。しかし、AI導入に失敗する企業のパターンを観察すると、ほぼ共通しています。
- モデル選定で悩む（GPTかClaudeかGeminiか）→ これは些末な問題
- プロンプトエンジニアリングを学ぶ → これも本質ではない
- ルールを文書化してAIに守らせようとする → ここで詰む
詰むポイントは、決まっています。「AIが言うことを聞かない」運用フェーズです。
そしてこのフェーズを乗り越えるには、AIモデルの精度向上を待つのではなく、AIの判断を介さず動作する運用インフラを自分で設計する必要があります。
これは技術的にもコスト的にも、想像より重い投資です。プロンプト1枚で何とかなる規模ではありません。
まとめ：AIエージェントは「使う」ものではなく「インフラごと作る」もの
直近2週間で出した、私なりの結論はこれです。
AIエージェントを業務に組み込むのは、新しい従業員を雇うことではありません。新しいOSを会社に導入することに近いです。OSを入れるなら、権限管理・ログ・バックアップ・セキュリティ境界の設計が要ります。AIエージェントも、同じです。
「AIに何をやらせるか」より、「AIの動作をどう物理的に観測・拘束するか」のほうが、実運用では遥かに重い論点になります。
私はこの2週間で、420行のルール文書（CLAUDE.md＋MEMORY.md）と150本以上のフィードバックファイルを書きました。それらが意味をなしていません。
意味があったのは、外部AIに独立調査をさせて自分の運用を客観視したことと、ガードを「AIの判断を介さない物理機構」に作り直す方針に転換したことです。
前回の記事で書いた「一次情報×AIカスタマイズ」の核原則は、今もまったく揺らいでいません。ただし、その核を実運用で守らせるためのインフラ設計こそが、本当の難所だったのです。
この記事で伝えたい4つのこと
- AIエージェント導入の難しさは、モデル精度ではなく運用インフラ設計にあります。プロンプト1枚で解ける規模ではありません
- ルールを増やしても遵守率は上がらないどころか、Lost in the Middle 現象で下がる可能性すらあります
- 失敗事例の記録だけでは AIは学習しません。「壊れた判断者に、自分で修正させる仕組み」になっているからです
- 解は「AIが呼ぶガード」ではなく、「AIの操作を受けて自動で発火するガード」です。`PreToolUse` フック等で物理化していく方向に投資してください
FAQ
Q1. AIエージェントを業務に導入したいのですが、最初に気をつけるべきことは何ですか？
A1. 「ルールを書けば動く」前提を捨てることです。AIが守れないルールは、何百行書いても守られません。物理的に動作を観測・拘束する仕組みを最初から設計したほうが、長期的には早いです。
Q2. CLAUDE.md（AIへの指示書）にルールを書けば、AIは守ってくれませんか？
A2. 守られない場合があります。LLMは長い文脈の中央付近の情報を取りこぼす「Lost in the Middle」現象があるためです。ルールを増やすほど、個別ルールの遵守率は下がる傾向があります。
Q3. feedbackファイル（失敗記録）を書けば、次回から学習しますか？
A3. 期待ほど学習はしません。AIエージェントは feedback ファイルを「自発的に」読みに行く判断力を必ずしも持ち合わせていません。判断が壊れている場面では、自分で修正する仕組みは機能しにくいのが実情です。
Q4. シェルスクリプトでガードを作れば解決しますか？
A4. 半分は解決します。ただしガードを「AIが自発的に呼び出す」設計だと、判断が壊れている場面では迂回されます。AIの操作を「自動で」観測して介入する仕組み（Claude CodeのPreToolUseフック等）まで含めた設計が必要です。
Q5. AIエージェント運用は、中小零細企業でも始められますか？
A5. 始められます。ただし、モデル選定（GPT／Claude／Gemini）やプロンプトエンジニアリングは本質ではありません。「AIの動作を物理的に観測・拘束する運用インフラ」の設計が、最も重い投資になります。プロンプト1枚で何とかなる規模ではないと覚悟しておいたほうが、結果的には早いです。
Q6. AIエージェントが言うことを聞かないとき、どう対処すべきですか？
A6. 感情をぶつけても解決しません。怒りは「設計が間違っている」というシグナルとして扱い、ルール追加ではなく「AIの判断を介さず動作する仕組み」へ転換するきっかけにしてください。
Q7. 元自衛官や中小零細企業でAI導入に詰まる典型パターンは何ですか？
A7. 「AIが言うことを聞かない」運用フェーズで詰まる方が多いです。モデル選定やプロンプトでの解決を試みても、出口は見えにくいです。物理的観測・拘束のインフラ設計に投資の軸足を移すことが、突破口になりやすいです。
コメント