AIの暴走とプロンプトの限界
リスナーのあなたも、こういう経験ないでしょうか? AIに仕事をちょっと任せて、自分はコーヒーでも入れに行って、戻ってきたら、「えっ、なんでそっち進んでるの?」みたいな。
ああ、ありますよね。とんでもない方向に作業が進んでて。 そうそう。で、慌てて停止ボタンを探すんですけど、もう手遅れ、みたいな。
ええ、誰しも一度は日合わせを書く瞬間だと思います。便利なはずのAIが、突然ブレーキの壊れた暴走列車のようになってしまうという。
本当そんな感じです。それで私たち、そういう時ってつい、自分のプロンプトの書き方が悪かったのかなって、指示の出し方ばかりを反省しがちですよね。もっと条件を過剰書きにすればよかったとか。
まあ確かにプロンプトも大事なんですけど、今日はその暴走を根本から防ぐための全く違うアプローチについて深掘りしていきたいと思っています。
はい。今回取り上げる情報源は、とあるITエンジニアの方が執筆された、2026年8月1日付けのAIエージェント日時速報という記事なんですが、これすごく面白い視点でしたよね。
そうなんですよ。この資料の非常にエクサイティングなところって、プロンプトの小手先のテクニックじゃなくて、最新のAIエージェントたちの製品設計そのものにメスを入れているところなんです。
製品設計ですか?
はい。つまり、AIが作業を始める前の計画をどこに置いて、どの時点でそれを固定するのかというシステムの仕組みに注目しているんです。
なるほど。今回の深掘りのミッションはまさにそこで、7つの最新AIツールを比較しながら、AIが作る計画が単なる下書きメモじゃなくて、AIの動きをコントロールする切り替えスイッチとしてどう機能しているのかをひも解いていきます。
はい。
これを聞き終える頃には、あなたがAIを単なる便利ツールから、安心して背中を預けられる仕事のパートナーに変えるための新しい視点が確実に手に入っているはずです。
コード生成における計画モードの導入
では、まずは一番イメージしやすい行動角度が修正するといったタスクから見ていきましょうか。プログラミングの領域ですね。
はい。お願いします。
記事によると、最近の優秀なAIエージェントって、そもそもいきなりコードを書かないように設計されているんです。
え?いきなり書かないんですか?AIってなんか指示されたら一瞬でずらーっとコードを出力してくれるのが売りみたいなところありませんでしたっけ?
確かに以前はそうでしたよね。でも例えば、オープンAIのコーデックスのガイドラインなんかを見ると、いきなり実装に入るんじゃなくて、まずはアスクモード、つまり質問モードから始めることを強く推奨しているんです。
質問モード。えっと、それはAI側から私たち人間に質問をしてくるってことですか?
そうですね。状況のすり合わせをするというか、具体的には任弁のプロンプト、あのソフトウェア開発でよく使われるGitHubのIssue、要するに解決すめち飾りのチケットみたいな形にまず構造化するんです。
あー、なるほど。
それでいきなり全部の作業を始めずに、タスク級と呼ばれるやることの順番待ちリストを作って、一つずつこなしていく。
さらにですね、agents.mdっていうテキストファイルを作って、そこにプロジェクトのルールとか文脈を書き込んでおくんです。
AIが迷ったときにいつでも参照できる憲法みたいなものを用意するわけですね。
なるほど。いきなり手を動かす前に、まずはルールブックとTo-Doリストを一緒に作るわけですね。
ええ、まさにそうです。同じようなアプローチをクロードコードも採用していて、彼らはこれをプランモード、計画モードと呼んでいます。
計画モードですか?
はい。これは単なる回答の前置きとかじゃなくて、明確な実装前の調査工程として機能しているんですよ。
実装前の調査工程。えっと、それは具体的にどういうメリットがあるんでしょうか?
調査型アプローチとその弱点
例えばですね、非常に大きなシステム、もう何千ものファイルがあるような場所で、ここのボタンの色を変えてと指示したとしますよね。
はい、はい。
その時、AIがいきなりコードを書き換えちゃうと、別の場所にある似たようなボタンの処理を見落としたりとか、チームの共通デザインルールをうっかり壊しちゃったりする危険があるわけです。
ああ、確かに。全体を把握してないといけないわけですね。
だからまずはシステム全体を探索させて、どのファイルを変更するのか、その変更が他に悪影響を与えないか、あとはどうやってテストするのかっていうのを計画としてまとめさせるんです。
それすごくわかります。なんかこれって家のリフォームをお願いした時に似てますよね。図面も見ずにいきなりハンマーで壁をぶち壊し始める大工さんじゃなくて。
ええ。
まずは家の構造を隅々まで調べてから、ここをこう変えますけどこっちの柱は重要なので触りませんよって図面を見せてくれる建築士さんみたいな。リスナーのあなたはどうでしょう。AIにいきなりハンマーを持たせていませんかという。
その建築士の例え本質をついてますね。ただ現実の仕事の現場を考えると、この調査型のアプローチにも弱点があるんですよ。
弱点ですか。いやなんか完璧に思えますけど。
例えばですね、ちょっとした誤字の修正みたいなほんの数秒で終わるような作業を頼んだとしますよね。
その度にAIが調査しました。これが変更計画です。確認してくださいっていちいち図面を持ってきたらどうでしょう。
うわそれはめんどくさいですね。いちいちハンマー使っていいですよって許可を出すのは逆に人間の手間が増えちゃいます。
そうなんですよ。だからこそ影響範囲の大きさとか後から簡単に戻せる作業かどうかによってこの調査型のモードを使うべきかどうか人間側が判断する必要があるわけです。
承認型と実行しないスキルの導入
なるほど。とはいえ今の話って自分のパソコンの中のコードをいじるようなある意味安全な箱の中の話ですよね。
ええそうですね。
でもこれがもっとリスクの高い作業、例えば会社の公開サーバーの設定をいじるとか外部のシステムに直接データを送信するようなタスクになったら単なる調査じゃちょっと怖くないですか。
間違いないですね。
一歩間違えたらサイトがダウンしちゃうわけですし、なんかもうAIに手錠をかけておきたい気分になります。
まさにそこが次のステップなんです。外部に影響を及ぼす場合、ただ調べてねというだけじゃなくてシステム的に人間が許可するまで絶対に動けないという強固な境界線が必要になってきます。
なるほど。
そこで資料が挙げているのがマニュースというエージェントですね。
マニュースそれはどういう設計なんですか。
マニュースのプランモードではAIが立てた計画を人間が確認して画面上にあるコンファームつまり承認というボタンを押すまでシステムが構築フェーズに絶対に移行しないようになっています。
つまり計画の提示が単なる作業説明じゃなくて実行開始の絶対的な境界線になっていると。
さらに踏み込んでいるのがハーメスエージェントというツールなんですが、彼らはなんと実行しない専用のスキルをシステムに組み込んでいるんです。
実行しないスキル?AIは実行してなんぼじゃないんですか。
面白いですよね。
プランというコマンドを打つとAIはマークダウン形式つまり単なるテキストとして計画を特定のフォルダに書き出すことしかできなくなるんです。
コードを編集したりシステムに変更を加えたりする機能がその時点では物理的にブロックされるんですよ。
それってどうやって実現してるんですか。
AIに今は計画だけにしてねお願いだよって言葉で伝えてるだけだとなんか裏でこっそりファイルを書き換えちゃうかもしれませんよね。
言葉でお願いしているわけじゃないんです。
メカニズムとしてはAIから実行するための権限とかAPIキーといったシステムを操作するための鍵を一時的に取り上げている状態なんですね。
会社のセキュリティカードでいうところの権限のない閲覧専用のゲストパスだけをAIに渡しているような状態ですね。
その通りです。あるいは核ミサイルの発射プロトコルのように2人の人間が同時に鍵を回さないと絶対にシステムが動かない仕組みと言ってもいいかもしれません。
なるほどな。
言葉の指示じゃなくて権限を剥奪するという動作によって境界を作っているんです。
この承認型の設計はウェブサイトの公開とか外部サービスの連携みたいに絶対に人間が事前に方向性をコントロールすべき仕事には不可欠ですよね。
いやー物理的に実行できない状態を作るのはすごく安心です。
成果物型アプローチとログの森
でもちょっと待ってください。これまでテキストベースの計画の話をしてきましたよね。
はい。
でも、例えば新しいアプリのUIデザインとかブラウザの自動操作あるいは複雑なシステムの移行みたいな仕事って
ここをこう変えますっていうテキストを読んだだけじゃ本当に合ってるかどうかって人間には判断できなくないですか?
そこ非常に重要な指摘です。テキストだけでは正しさが検証できないタスクにおいて計画はどうあるべきか。
記事ではGoogleのアンティグラビティというアプローチが紹介されていますね。
Googleはどんな解決策を出しているんでしょうか。
彼らは計画のテキストだけじゃなくてAIが作ろうとしているタスクリストとか途中のスクリーンショット
さらにはブラウザの操作録画などすべてアーティファクト図、つまり成果物として一つの画面に残す設計にしているんです。
これによってAIが実行しながらでも人間がそれを見てフィードバックを与えたり方針を修正したりできるんですよ。
うーん、でもちょっと待ってください。それって本当にうまくいきますかね。計画のテキストがあって途中経過の画面キャプチャがどんどん追加されて動画のログもあってって
AIが試行錯誤するたびにそれが増えていったらどれが最新の方針なのかわからなくなって帰って人間がログの森の中で迷子になりませんか。
痛いところをつきますね。実はそれがアンチグラビティのような成果物型が抱える最大のジレンマなんです。
計画が一度承認して固定されるものじゃなくて実行しながら変化するいわば生き物になってしまうので情報量が人間の処理能力を超えてしまう危険性があるんです。
ですよね。結局全部の動画や画像を最初から見直さないと現在の状況がわからないならAIに頼んだ意味がないというか人間が疲れちゃいますよ。
記事の著者もその懸念をしっかり指摘していてだからこそこれが最新版の計画で前回からここが変わりましたという変更点だけを一つにまとめて提示する運用が不可欠になると述べています。
でもそのまとめを作るのは誰なんでしょう。もしAI自身が自分の変更点を要約するなら結局私たちはブラックボックス化されたAIの要約を信じるしかなくて私たちがログの森で迷子になる問題の根本的な解決にはなっていない気がするんですが。
おっしゃる通りです。そこにAIの要約を挟んでしまうとAIの幻覚いわゆるハルシュネーションを見逃すリスクがどうしても残ります。
差分型アプローチと実行メカニズムの分離
だからこそ特に絶対に壊したくない元に戻すのが極めて面倒な作業。例えばサーバーの設定変更とかインフラの移行なんかではもっと厳格なアプローチが求められます。それがオープンクローというツールですね。
オープンクロー。それにはログの森に迷い込まない仕組みがあるんですか。
ええ、彼らはプラン、つまり計画とアプライ、適用のプロセスを完全に切り離しているんです。システムを変更する前に変更予定の差分、既存システムとの競合箇所、そして今回はスキップする項目、これらだけを明確に出力します。
なるほど、こういう方針でやりますとか、こんな画面になりましたじゃなくて、結果としてこのシステムのここがこう変わりますっていう事実の差分だけを見せるんですね。
その通りです。そして人間が明示的にYESというコマンド、つまり許可を与えない限り、適用プロセスには絶対に進みません。これは差分型と呼べるアプローチですね。
なるほど、明確ですね。
さあり、オープンクローの面白いところは、タスクの性質によって実行のメカニズムそのものを分けている点なんです。
実行のメカニズムを分けるですか、どういうことでしょう。
例えば、毎日決まった時間に動かすだけの単純な仕事なら、単なるタイマーであるクローンという仕組みに載せる。
前の作業の結果を見てから次を判断するような文脈が必要な仕事なら、定期的に状況を確認するハートビートという脈拍スックのような仕組みに載せる。
さらに複雑な多段階の処理なら、タスクフローに載せるといった具合です。
計画の段階で、ただやることを決めるだけじゃなくて、どの仕組みのレールに載せて実行させるかまで決定するんですよ。
複数AIモデルの協調とブラックボックス化のリスク
なるほど。調査型、承認型、成果物型、そして差分型。
一口に計画を立てるといっても、求める役割にのってAIとの境界線の引き方が全然違うんですね。なんかすごく見えてきました。
ええ。
ただ、これって全部一つのAIに仕事を頼む前提ですよね。
そうですね。これまでは単一のモデルをどう制御するかという話でした。
でも、ここからさらに視点を大きく広げてみましょう。
全く新しい計画の概念として、ジェンスパークのAIワークスペース6.0という事例が登場します。
ジェンスパークですか。それは今までとどう違うんでしょうか。
彼らはなんと70以上の異なるAIモデルを一つの仕事の各工程に自動的に振り分けるんですよ。
え?70個ですか。ちょっと待ってください。それはもうAI個人の作業じゃなくて、巨大なプロジェクトチームじゃないですか。
まさにその通りです。ここでの計画とは単に作業の手順を書くことじゃないんです。
リサーチはこのAIが得意だからここに任せる。文章をまとめるのはこのAI。表計算はこのAI。デザインはこのAIというように。
はあ。
70のモデルの中から適材適所でタスクを割り振る配置表へと進化しているんです。
つまり人間がこの作業はクロードに頼んでこっちの画像は別のAIに頼んでって毎回選ぶ必要がなくなるわけですね。
システム側がプロデューサーになってオーケストラの色望を振るってくれると。いやこれはすごい未来ですね。
ええ。非常に効率的で強力なシステムです。しかし同時に見過ごせない巨大なリスクもはらんでいるんですよ。
リスクですか。
ええ。工程ごとに異なるモデルが自動で分業するということは人間からはその間で行われている情報のやり取りが全く見えなくなるということです。
ああなるほど。
例えばリサーチAIが間違ったデータを出しちゃってそれを文章化AIが最もらしく書き直してさらにデザインAIが綺麗なグラフにしてしまった場合。
うわあ。
どこで誤りが混入したのか後から追跡することはほぼ不可能になります。
完全なブラックボックスですね。どうやって作られたか全くわからないけど出てきた綺麗な完成品だけを信じてしまうとそれは確かに怖いです。
だからこそこのレベルの自動化においては工程ごとの入力と出力そして人間が確認すべきチェックポイントがシステム側で可視化されているかどうかが極めて重要になってくるんです。
究極のテンプレートとマネージャーとしての役割
いやあこうして見てくると私たちが明日からAIとどう付き合っていけばいいのかそのヒントが見れてきますね。
つまり重要なのはどのAI製品が一番賢いかを探すことじゃないんですね。
ええ。自分が依頼する仕事のリスクや性質に対してどの計画の型があっているかを見極めることです。
はいはい。
既存のコードを理解させたいなら調査型、海外へ公開するなら承認型、見た目の変化を追いかけたいなら成果物型、設定を変えるなら差分型というようにですね。
なるほど。ではリスナーの私たちが明日から仕事でAIを使うとき、具体的にどう指示を出せば今日学んだような安全な計画の境界線を作れるんでしょうか。
記事の著者はですね、大きな仕事を頼む際に使える実行前の一文、いわば究極のテンプレートを提案しています。
究極のテンプレートをぜひ教えてください。
考え方の本質は実行する前にまず被害の及ぶ範囲、つまり爆風の範囲をマッピングさせろということです。
爆風の範囲、つまり何かを壊しちゃう前に何を壊すつもりか先に教えろってことですか。
まさにそれです。具体的にはプロンプトの最初にこう書くんです。
まず実行せずに目的、変更する対象、そして変更しない範囲、想定される副作用、検証方法を計画として提示してください。
外部への影響がある場合は実行する前の差分と作業を途中で止める条件を分けて示してくださいと。
おお、これは実用的ですね。変更しない範囲を明言させるのは、さっきの大工さんの例で言うこの柱は絶対に切らないでねと約束させるのと同じですよね。
はい、その通りです。そして頼むタスクに応じて一個だけ付け足します。
コードを書かせるならテストの方法を入れろとか、ウェブデザインなら画面構成の確認プロセスを入れろといった具合ですね。
なるほど。私たち人間が見るべきなのは、AIがどんなに素晴らしい文章を返してきたかじゃなくて、実行する前に何を決定し、何をまだ決定していないかを明確にさせることなんですね。
ええ。
なんだか、AIに指示を出す単なる作業者から、AIが持ってきた企画書を承認するマネージャーに昇進した気分です。
素晴らしい気づきだと思います。AIにハンマーを振るわせる前に、しっかりと図面に承認を押す、その運用プロセスを自分で設計できるかどうかが、これからの時代の知的労働における最大の武器になるはずです。
AIの自己完結と道徳的責任
いやー、AIへの接し方が根底からおおぶるような本当に濃密な時間でした。さて、今回の深掘りはそろそろ時間なんですが、最後に一つリスナーのあなたに考えてみてほしいことがあります。
はい。
今日、私たちは、AIの立てた計画を人間がどう管理し、承認するかについて語ってきました。
でも、ジェンス・パークの事例でも少し触れたように、もし近い将来、AIが計画の立て方や70のAIモデルへの完璧なタスクの配置すらも、人間のチェックを一切必要とせずに完全に自己完結できるようになったとしたらどうでしょう?
技術の進化のスピードを考えれば、決して遠い未来の話じゃないですよね。
ええ。その時、人間であるあなたが最後に承認を推す対象は、もはじゃタスクが正確かどうかではないはずです。
なるほど。
その計画が実行された時に引き起こされる倫理的な結果や、人間社会への影響だけがあなたの決断に委ねられる。あなたは、AIの道徳的責任者になる準備ができているでしょうか?
深い問いですね。
今回のテーマはここまでです。これからも共に新しい知識を探求していきましょう。あなたのマネージャーとしての第一歩を応援しています。
