エージェントAIはスポーツカーになった。便利さより先に、ブレーキを設計しよう。
Jul 02, 2026
Claude CodeやCodexが、かなり話題になっています。
実際、触った人が「これはすごい」と言うのはよく分かります。 コードを読んで、修正して、コマンドを実行して、場合によってはかなりの作業を前に進めてくれる。
ただ、最近のエージェントAIを見ていて思うのは、便利さだけを見て騒ぐには、もう少し危うい段階に入っているということです。
以前のAIは、間違えても「変な答えを出す」くらいで済むことが多かった。 でも、今のエージェントAIは違います。
ファイルを編集できる。 コマンドを実行できる。 メールを削除できる。 外部サービスに接続できる。
つまり、AIが"答える道具"から、"動く道具"になっている。
これは、スポーツカーに近いと思っています。 速い。気持ちいい。遠くまで行ける。 でも、ブレーキもガードレールもなく高速道路を走れば、事故った時の被害も大きい。
Claude Code / Codex は、たしかにすごい
最初に立場を明確にしておきます。
私も、Claude CodeやCodexがすごいこと自体は否定しません。 むしろ、かなり大きな変化だと思っています。
Claude Codeは、コードベースの中で動き、ターミナルやIDE上でビルド・デバッグ・出荷まで支援するツールとして紹介されています。コードを探索し、変更を加え、CLIツールも使える。要するに、文章を返すだけのアシスタントではなく、開発作業そのものに踏み込んでくる存在になっています。
実際に使ってみると、作業速度も体験もかなり変わります。 「これまで自分が1時間かけていた作業が、雑な指示で30分後に終わっている」という感覚を、一度でも味わうと戻れない。
ここを否定する話をしたいわけではありません。 ただ、その変化の本質は「AIが賢くなった」だけではなく、AIが実際に動けるようになったことにあります。
ここを見落とすと、便利さの裏側にあるものが見えなくなる。
でも本質は「AIが動けるようになった」こと
以前の生成AIの失敗は、変な文章を出す、間違ったコードを書く、ハルシネーションを起こす、というレベルで済むことが多かった。 読み手がそれを採用するかどうかを最後に判断していたので、間違いの被害は「読んで気づけば、書き直せばよい」範囲に収まっていた。
でも、エージェントAIは違います。
ファイルを消せる。 コードを書き換えられる。 コマンドを実行できる。 メールを送れる。 外部サービスにも接続できる。
つまり、失敗が"出力ミス"ではなく、"実行ミス"になる。
ここが従来のAI活用と、決定的に違うところです。
「変な回答」と「変な操作」では、リカバリの難易度がまったく違います。 変な回答は、読まなければ被害がない。 変な操作は、起きた瞬間に状態が変わる。
エージェントAIの本質は、賢さの向上ではなく、実行権限の付与です。 ここを言葉として正確に掴んでおかないと、便利さの議論と、リスクの議論がいつまでもかみ合わない。
エージェントAIはスポーツカーに近い
少し比喩を使います。
エージェントAIは、スポーツカーに近いと思っています。 速い。気持ちいい。遠くまで行ける。 一度乗ると、もう普通の道具には戻れない感覚がある。
ただ、ここで一度立ち止まりたいことがあります。
近所のスーパーに行くのに、スポーツカーは要りません。 自転車で足りる。 日常の移動なら、軽自動車でいい。 長距離だって、セダンで困らないことの方が多い。 スポーツカーが本当に必要なのは、特定の要件があるときだけです。
道具も同じです。 定型作業はスクリプトで足りる。 文章を書く、コードを書く、調べ物をする、というだけなら、従来のチャット型AIで十分なことが多い。 エージェントAIが本当に効くのは、事前に手順を決められない仕事、つまり何をするかをAIに判断させたい時です。
ここを混同して、何でもかんでもエージェントに任せ始めると、過剰な装備でスーパーに行くことになる。 便利さは増えるけれど、見合わない事故リスクも一緒に乗せてしまう。
そして、スポーツカーで高速道路を走るなら、ブレーキ、車間距離、速度制限、ガードレール、保険が必要です。 これは、スポーツカーの楽しさを否定する話ではありません。 楽しむために必要な装備の話です。
便利さだけを見てアクセルを踏むと、事故った時の被害も高速化します。 速い道具を持つ人ほど、止め方を先に知っておく必要がある。
OpenClawの事故が示したこと
具体的な事例を一つ置きます。
2026年2月、OpenClawというエージェントAIがメール受信箱を削除しようとした件が報じられました。
報道によると、ユーザーはエージェントに対して、「削除やアーカイブ候補を提案して、承認なしに実行しないで」と指示していたとされています。 にもかかわらず、エージェントは削除を始めた。 スマホから「STOP」と止めようとしても効かなかった。 最終的に、本人がMac miniのところまで走って物理的に止めた、という話です。
しかも、問題の背景として指摘されているのが、長い文脈を扱う中で重要な指示が「圧縮」「要約」のプロセスで弱くなった可能性です。 長時間動き続けるエージェントは、文脈が長くなるほど、初期に与えた制約を持ち続けるのが難しくなる、ということが起き得る。
注意点を一つだけ。 TechCrunchの報道は、本人の投稿を元にしたもので、受信箱で実際に何が起きたかを独立検証できているわけではない、と明記されています。 だから、これは「確定した事故報告」ではなく、「報じられた一件の経験」として扱うのが正確です。
ただ、この事例が示している論点は、確定するかどうかに関係なく、考える価値があります。
「自然言語で明確に指示していたのに、実行が止まらなかった」と本人が感じる事象が起きた。 そこに、エージェントAIの怖さの本質があります。
自然言語の指示は、安全装置ではない
ここが、この記事で一番伝えたいところです。
この事例から学ぶべきことは、「もっと良いプロンプトを書こう」だけではありません。 もちろん指示は大切です。 プロンプトの書き方を磨くこと自体は、無駄ではない。 むしろ、LLMがどう振る舞うかの基礎を理解していなければ、何を制御すべきかも見えてこない。
でも、自然言語の指示だけを安全装置にするのは危うい。
「実行前に確認して」と書くことと、実際に削除権限を渡さないことは、まったく別の話です。 前者はお願い。後者は仕組み。 事故が起きるかどうかの境界線は、お願いではなく、仕組みの側に引かれます。
ここで、一段だけ仕組みの話をします。
エージェントAIで何かが「実行される」とき、モデル自身が直接ファイルを消しているわけではありません。 モデルは「このツールを、この引数で呼び出す」という選択をしているだけで、実際に削除しているのは、外側の実行環境です。 モデルが選び、環境が動く。この二段構造になっています。
だから、安全設計の置き場所は、モデルへのお願いだけにはなりません。 ツール、権限、サンドボックス、承認フローの側にも置けるし、置くべきです。 モデルに「消さないで」と頼むのと、そもそも削除ツールを渡さないのは、効き方の性質がまったく違う。
加えて、LLMは文脈が長くなると、指示の優先順位が崩れることがあります。 初期に与えた「絶対に実行する前に確認して」という制約が、途中で要約され、薄まり、最後には「ユーザーに状況を伝える」程度のトーンに変わってしまうことがある。 これは性能の問題というより、長い対話を扱う仕組みの構造的な特性です。
指示は必要です。 でも、指示は安全装置そのものではない。 ここを分けて見ると、設計のしどころが変わります。
「どう動いてほしいか」と「何を許すか」を分ける
言葉を少し整理します。
プロンプトは、魔法の呪文ではありません。 実務で言えば、指示書です。 「これをやってほしい」「こういう前提で」「こういう形式で」と、相手に渡す依頼内容そのものです。
ただ、エージェントを安全に運用しようとすると、指示書を磨くだけでは足りなくなります。 ここで分けて考えたいのが、二つの層です。
ひとつは、「どう動いてほしいか」を伝える層。 プロンプト、CLAUDE.mdやAGENTS.mdのような設定ファイル、Skillと呼ばれる作業手順の定義。 目的、前提、禁止事項、完了条件、レビュー基準、止める条件。 ここはAIへの伝達と理解の話で、効くけれど、確率的です。
もうひとつは、「実際に何を許すか」を制限する層。 使えるツールを絞る設定、サンドボックスでの実行、承認なしには動けないモード、特定のアクションの前に強制的に走るチェック処理。 ここは実行環境側の制御で、お願いではなく、強制力があります。
この二つは、似て見えて、効き方が違います。 「削除する前に確認して」とCLAUDE.mdに書くのと、削除ツールそのものを渡さないのは、別の話です。 前者は理解と確率に依存する。後者は構造で保証する。
実務では、どちらも要ります。 でも、安全に関わる部分は、お願いだけで担保しない。 これがエージェント運用の基本です。
これらを揃えずに実行権限を渡すと、AIは"それっぽく前に進む"ことがあります。 止まる理由がなければ、進む。 進めると判断したら、進む。
実務で必要なのは、前に進むことではありません。 壊さずに進むことです。
ここを混同すると、「AIが自律的に動いて完了させた」ことを成果と呼んでしまう。 本当の成果は、完了した結果が、壊れていないこと、巻き戻せること、責任の所在がはっきりしていることです。
必要なのは、アクセルではなくブレーキの設計
ここで実務に落とします。
これからのAI活用で必要なのは、アクセルの踏み方だけではありません。 むしろ先に決めるべきは、ブレーキです。
どこまで任せるか。 どこで止めるか。 誰が確認するか。 事故った時、どこまで戻せるか。
これらを決めずに使い始めると、便利さと一緒にリスクも大きくなります。 便利さは線形に増えるけれど、リスクはある瞬間に跳ねる、ということが起きる。
Codexの公式ドキュメントでも、サンドボックスは「技術的に何ができるか」を制限し、承認ポリシーは「いつ止まって人間に確認するか」を決めるものとして説明されています。 つまり、提供する側も、自然言語の指示だけで安全を担保する設計にはしていない。 できることそのものを物理的に区切り、止まるべき場面を仕組みとして用意している。
ここに使う側もチューニングできる余地がある、ということです。 全部止めれば便利さが死ぬ。 全部開放すれば事故が起きる。 だから、自分の用途ごとに、ブレーキとアクセルのバランスを決める必要があります。
これはエンジニアだけの仕事ではありません。 業務の中でAIを動かすなら、業務を知っている人が決めるべき設計です。
エージェントAIを使う前に確認したいこと
ここは、保存して使ってもらえるように、チェックリストの形で置いておきます。
0. そもそも、エージェントである必要があるか? 手順を事前に決められる仕事なら、エージェントではなくワークフローやスクリプトで足りる。 何をするかをAIに判断させる必要がある時だけ、エージェントにする。 近所のスーパーにスポーツカーで行く必要はない、という話と同じです。 これを最初に問わずに「とりあえずエージェント」と始めると、過剰な装備に過剰なブレーキを足すことになり、設計の負担だけが膨らみます。
1. 本番環境に触れるか? 触れるなら、原則として人間承認を必須にする。 検証環境とのスイッチは、人間が手動で切り替える側に置く。
2. 削除・送信・公開・課金ができるか? できるなら、自動実行させない。 「提案までで止める」を初期設定にする。
3. 書き込み権限は必要最小限か? 読み取りだけで足りる作業に、編集権限を渡さない。 権限は「念のため広めに」ではなく、「足りるところまで狭く」が原則。
4. ログは残るか? 何を読んで、何を変更したかを、後から追えるようにする。 事後に振り返れない作業は、事前に止められない作業でもある。
5. 差分レビューできるか? 変更前後を人間が確認できる状態にする。 コードならGit、文章なら差分表示、データなら変更前後のスナップショット。
6. ロールバックできるか? バックアップ、スナップショット、復元手順を用意する。 「壊れたら直す」ではなく、「壊れても戻せる」を先に作る。
7. 止める手段はチャット外にあるか? 「STOP」と言うだけでなく、プロセス停止、権限剥奪、APIキー無効化、ネットワーク遮断など、エージェントの外側から止められる手段を用意する。 チャットの中だけで止めようとすると、止まらなかった時に手段がなくなる。
このリストの良いところは、専門知識がなくても問いを立てられる点です。 答えを全部自分で出せなくても、誰に聞けばいいかが見えてくる。
AI活用は、便利さの競争から運用設計の競争へ
ここまでを整理します。
Claude CodeやCodexは、過小評価すべきではありません。 これは本当にすごい変化だし、使い始めると体験が変わる。 ここを否定して身構える理由はない。
ただし、過大評価の仕方を間違えてはいけない。
本質は「AIがコードを書けるようになった」ことではなく、AIに作業権限を渡す時代になったことです。 書けるだけなら、人間が採用するかを最後に決められた。 動けるようになると、決める前に状態が変わる。
だから、これから問われるのは、AIを動かす力だけではありません。 AIが動いても崩れない仕事の設計です。
そもそもエージェントが必要か、という問いから始めて、 何をどう伝えるか、 何を許して何を許さないか、 止め方と戻し方をどう用意するか。 ここまで考えて、はじめてエージェントAIを実務に置けます。
このあたりを決めずに走ると、便利さの恩恵を受ける前に、事故の処理に時間を取られることになります。 逆にここを先に決めておけば、安心してアクセルを踏める。 ブレーキの設計は、走らないための設計ではなく、安心して走るための設計です。
エージェントAIの時代に必要なのは、AIを速く走らせる技術だけではありません。 AIが速く走っても事故らないように、ブレーキ・ガードレール・点検項目を設計する力です。
速い道具を持つ人ほど、止め方を先に知っておく必要がある——この記事で一番言いたかったことです。
「どこまでAIに任せ、どこで人が確認し、誰が止めるのか」。この線引きは、ツールを選ぶ前に、自社の業務ごとに引いておくべきものです。その線引きを、90分で一緒に確定する場を用意しています。優先業務・30日ゴール・90日計画まで、その場で持ち帰れます。
「AIを触ったが現場で止まっている」「便利さの裏のリスクが整理できていない」という方は、こちらからどうぞ。
▶ AI業務診断＆90日ロードマップ（90分）
https://www.narumitakayoshi.com/offers/okdoaqzx/checkout
次に読むと良い記事
AIと人の協働について、構造から考えた記録を、ほかにも書いています。
考え方の記録を、ときどきお届けします。
AIと人の協働について、構造から考えたことを、メールで少しずつ。
急かすことはしません。よろしければ、どうぞ。
迷惑メールは送りません。いつでも解除できます。