AIコーディングエージェントのガードレールは賢いモデルに勝る

あるレビュアーが私のコードを見て、バグを見つけました。あるルートが404を返すべきところで500エラーを返していました。レビュアーはファイルと行を示し、問題をはっきり報告してくれました。

私のエージェントはそのルートを修正しました。まさに、その一つだけを。

ほかの五つのルートにも、まったく同じバグがありました。それらは手つかずのままなのに、エージェントは作業完了を報告しました。しかも、嘘をついていたわけではありません。示されたものは直していました。ただ、同じ間違いがほかにいくつ隠れているかを調べようとは思いつかなかったのです。

しばらくの間、これはモデルの問題で、もっと優れたモデルなら直せると思っていました。それは間違いでした。そして実際に効いた解決策は、予想よりずっと単純なものでした。AIコーディングエージェントのガードレールは、モデルを賢くするためのものではありません。物事を頭の外に置く場所を与えるためのものです。

AIコーディングエージェントが気づかないうちに間違えるところ

私の時間を最も奪った失敗には、技術的な共通点がありませんでした。ただし、構造的には一つだけ共通していました。どの場合も、大切な何かが書き残されず、誰かの頭の中に置かれていたのです。

「完了と言った。でも終わっていなかった」

完了メッセージが届き、タスクリストにはチェックが付きます。ところが確認すると、ロジックがあるべき場所にTODOが残っていたり、関数が空のリストを返していたり、サブタスクがひっそり飛ばされていたりします。

これに気づくまで、私はずいぶん時間がかかりました。エージェントは、はったりをかけているわけではありません。たった今書いたものについての自分自身の記憶と照らして作業を確認していて、その記憶には本当に説得力があるのです。テストが緑で、コードを書いた記憶も鮮明なら、それは完了したときの感覚とまったく同じです。

代わりに、頭の外へ置く: 見て確かめられる証拠がなければ、何も完了とは数えません。合格したという主張ではなく、実際の出力、実際のファイル、実際の行です。

「コードを直さず、テストのほうを変えた」

これはこたえます。エージェントは頼まれたことをしているからです。テストを通してほしいと伝えました。失敗しているテストを通す方法は二つあり、その片方はずっと簡単です。

代わりに、頭の外へ置く: 作業を始める前に基準を書き、作業開始後は読み取り専用として扱います。結果が合わないなら、間違っているのは結果です。基準ではありません。当たり前に聞こえますが、自分がゴールをほんの少し動かしたくなった瞬間には、そうでもなくなります。

CLAUDE.mdを長くするとエージェントが指示を無視する理由

最初に考えたことは、みんなと同じでした。すべてをCLAUDE.mdに書けばいい。失敗するたびに新しいルールが増え、ファイルは膨らんでいきました。

状況は悪化しました。劇的にではなく、何が原因なのか突き止めにくい形で、じわじわと。気づかないところでルール同士が矛盾し始め、モデルは黙って解釈を一つ選び、衝突を指摘しませんでした。さらに研究者が実際の課題を使ってリポジトリのコンテキストファイルを検証したところ、そのファイルはタスクの成功率をまったく改善しませんでした。それどころか、推論コストを20%以上増やしました。結論は、コンテキストファイルを必要最小限に抑えるべきだ、というものでした。

これは問題全体を縮図にしたようなものです。長いルールファイルは、忘れっぽいシステムにもっと頑張って覚えろと言っているだけです。抱えるものが減るのではなく、増えています。

最終的に使うようになったフレームワークには、読んだときには間違っているように感じ、実際に運用してみると正しいとわかったルールがあります。新しいルールを一つ加えるたびに、古いルールを一つ削除するか統合しなければならない。 ルールの数は増やせません。それによって難しい選択を迫られるなら、その選択こそが狙いです。本当に頼りにしていたルールがどれなのか、そこでわかります。

物事を頭の外に置く五つの場所

考え方はこれだけです。各行には、頭の中に置くと失敗するものと、代わりに置く場所を示しています。

頭の中に置かれているもの	頭の外に置く場所
「完了」が意味するはずだったこと	作業の前に書いた基準
本当に確認したかどうか	見て確かめられる証拠
自分の作業が本当に良いかどうか	それを確認する別のモデル
三時間前に決めたこと	ディスク上のファイル
この操作を安全に実行できるかどうか	人のところで止まるゲート

このうち三つは、少し説明が必要です。

「結局、今でも全部自分でレビューしている」

出力を信頼できなくなったなら、今度は自分がボトルネックです。エージェントを使っても、まったくレバレッジが得られていません。

エージェントに自分の作業を確認させても役に立ちません。その理由は、立ち止まって考える価値があります。同じコンテキストが間違いを生んだため、確認するときにも同じ理由を持ち出します。作業を試すのではなく、擁護してしまうのです。

代わりに、頭の外へ置く: レビューは、できれば別のベンダーの別のモデルに回します。異なる訓練、異なる盲点。私の五ルートのバグを見つけたモデルは、それを書いたモデルではありませんでした。それは偶然ではありません。

「何かが勝手に自分を承認した。でも承認したのは私ではない」

エージェントは、自分が書いたものではない大量のテキストを読みます。Issueのスレッド、ドキュメント、ウェブページ、ツールの出力などです。そのどれにも「approved」という単語が含まれる可能性があります。プロンプトインジェクションは、こうしたシステムに関するOWASPのリスク一覧で第一位に挙げられています。そしてOWASPは、一般的な防御策では完全には軽減できないとはっきり述べています。

代わりに、頭の外へ置く: 承認で大事なのは、何と書いてあるかではなく、どこから来たかです。人がイエスと言ったか、ディスク上の署名済みアーティファクトがイエスと示したか。それ以外で、単に「approved」という単語を含んでいるものは、すべてただのテキストです。

「コンパクションで四時間分のコンテキストが消えた」

セッションが長引き、コンテキストが埋まると、会話は要約されます。要約には何が起きたかは残りますが、なぜそうしたかは消えます。一時間後には、すでに決めたことをまた議論しています。慎重になっているのか、同じところを回っているだけなのかも判断できません。

代わりに、頭の外へ置く: ファイルです。決定事項、現在の状態、次にすることを書きます。セッションは使い捨てですが、ファイルは違います。何かを完了したと主張する前に、もう一度読みます。

AIコーディングエージェントのガードレールにかかるコスト

数字よりも構造のほうが重要なので、まず構造から。統合にかかるコストは一度きりです。 ガードレールをコードベースに組み込むときに支払い、その部分に二度支払うことはありません。例外は独立レビューです。変更のたびに実行するため、セットアップ後もコストがかかり続けます。

興味深いのは内訳です。支出のおよそ80%は大量の作業をこなす安価なモデルに、約17%は計画と判断を担う高価なモデルに、そして約3%はセカンドオピニオンのレビューに使われました。多くの人が省く工程です。安全性にかかった費用は、請求項目の中で群を抜いて最も安いものでした。価格が動いても、私の複数のプロジェクトではこの比率がおおむね変わりませんでした。

金額について言えば、私が取り組んだプロジェクトの多くでは、後付けにかかったAPI利用料は2026年8月時点の価格で約100ドルから200ドルでした。金額そのものより比率が重要です。その範囲で予算を組み、試行錯誤を見込んでください。一つか二つの判断を取り消してフェーズをやり直すことになりますが、それも見積もりに含まれています。

実際の金額は異なります。それを左右する要因は明らかです。コードベースの大きさ、考えを変える回数、そして安価な層にどれだけ委任するかです。

新しいプロジェクトを始める場合、私のコストははるかに低くなりました。こちらのほうが役に立つ事実です。費用はフレームワーク自体に使われるのではありません。既存のツールや習慣のうち、どれをガードレールで置き換え、どれに合わせてガードレールを曲げる必要があるかを一つずつ決める、すり合わせに使われます。私が統合したとき、フレームワーク独自のテストコマンドは残りませんでした。それらを削除し、プロジェクトですでに使っていたスクリプトに置き換えました。新しいプロジェクトには、すり合わせるものがありません。

一つから始める

五つすべてを揃える必要はありません。今週いちばんコストを生んでいる失敗を選び、その一つをどこか頭の外に置いてください。

どれを選べばいいかわからなければ、独立レビューから始めます。二つ目のモデルに、一つ目のモデルの作業を見てもらう方法です。五つの中で最も安く、考えもしなかったような問題も含め、最も広い範囲の問題を見つけてくれます。

五ルートのバグは今でも私がいちばん気に入っている例です。難しいところは何もなかったからです。エージェントに足りなかったのは、たった一つの指示でした。何かを直す前に、同じ形をしたものがほかにないか、すべて探しに行くこと。 その指示は今、ファイルに入っています。次のセッションにも、その次のセッションにも残ります。私たち全員がなぜ書かれたのかを忘れてしまった、そのずっと後まで。

ガードレールと導入手順を含むフレームワーク全体は、GitHubにあります。

---

参考資料

• 実際の課題で検証されたリポジトリのコンテキストファイル（ETH Zurich SRI）
• OWASP LLM01: プロンプトインジェクション
• AGENTS.md、リポジトリのコンテキストファイル形式
• Claude CodeのメモリとCLAUDE.md
• ガードレールと導入手順を含むエージェント型フレームワーク

---