00:00
おはようございます。コーヒーか紅茶を片手に、 ちょっとリラックスして聞いていただければと思います。
えーと、リスナーの皆さんにちょっと想像してみてほしいんですが、 例えば、あなたがAIに巨大なコードベースのリアーキテクチャーとか、
複雑なデータ分析をお願いしたとしますよね。 はいはい、よくあるシチュエーションですね。
そうなんです。で、数秒後に、画面には見出しがきれいに整理されて、依存関係からテスト手順までが完璧にリスト化された50項目にも及ぶようなマークダウン形式の計画書がサッと出力されるわけです。
おー、いかにも賢そうな見た目のやつですね。
それを見た瞬間、「おっ、ちゃんと背景までわかってるなー。」って安心して、中身をろくに読まずに実行ボタンをターンと押しちゃうことありませんか?
あー、それは本当に耳が痛い話ですね。あの、完璧に見えるフォーマットって実はすごく極差なんですよ。
極差ですか。なんか、きれいに構造化されていると、無意識のうちにAIがこちらの意図を完全に理解してくれたって錯覚しちゃいますよね。
そうなんですよ。でも、今回の深掘りの一時資料になっている、2026年7月23日に公開された、とあるITエンジニアによる記事、
AIエージェント日地速報という記事なんですが、この著者はそこに強烈な警鐘を鳴らしているんです。
なるほど。本日のミッションはまさにそこですね。私たちが陥りがちな罠と、それを防ぐためにAIツールがどう進化しているのかを解き明かしていくという。
計画書の本当の役目というのは、私たちを安心させることではないんです。
AIが勝手に作り上げた前提条件のずれを、実作業に入る前に炙り出すためのものなんですよね。
前提条件のずれですか。なんか、AIのミスっていうと、単純なコードの文法エラーとか、ツールの使い方の間違いだと思いがちなんですけど。
実はそうじゃないんです。大半の致命的な失敗は、このシステムの最終的な利用者は誰かとか、何をもってこのタスクを完了とするのか、といった根幹のずれから起きるんです。
もし失敗したらどの状態まで切り戻すのか、みたいなところもですよね。
まさにそこです。ここが一度でもずれていれば、その後の作業手順がどれだけ完璧なコードで書かれていても、出来上がるものは全くハズレなものになってしまいますからね。
言われてみれば確かに、これって人間の仕事でも全く同じことが起きますよね。新しい社内ツールの企画書を作ってって頼んだら、ターゲット層が新入社員向けなのか、管理職向けなのかずれているのに。
なのに、表紙のデザインが綺麗だからって、上司がろくに中身も見ずに反抗してしまうような状態ですよね。
そうそう、まさにそれです。で、その危険性をシステムレベルで防ごうとしているのが、最新のAIエージェントたちの動きだということなんですよね。
ええ、その通りです。例えば、記事で最初に取り上げられているマヌスというツールは、7月22日にプランモード計画モードという新機能を公開しました。
03:06
計画モード、それは具体的にどういうものなんですか?
これはですね、実行前に必ずマークダウン形式の計画を出力して、プロセスを一時停止させる機能なんです。人間がその文章を直接エディカーで書き換えて承認しない限り、実際の作業は絶対に始まりません。
ちょっと待ってください。もし、私が50行あるAIの計画書を毎回隅から隅までチェックして、テキストエディターでちまちま赤ペンを入れないといけないなら、それってAIを使う意味がなくないですか?
ああ、確かにそう感じますよね。
はい。圧倒的なスピードで仕事を終わらせるというAIの最大のメリットを完全に殺している気がするんですが。
そのジレンマは、現場のエンジニアたちも痛いほど感じているんですよ。だからこそ、著者は記事の中で、全部の行を読むなと強調しているんです。
え、全部読まなくていいんですか?じゃあ、どこを見ればいいんでしょう?
人間が手を入れるべきなのは、ライブラリのバージョン指定とかAPIの呼び出し手順といった機械的な作業の部分ではありません。
先ほど言った誰向けかとか、完成の定義は何かという、AIが勝手に掘った一行の判断だけを探し出して直すんです。
ああ、なるほど。つまりリアクトのバージョンはこれを使ってみたいな細かい手順はスルーしていいと。
そうです。その代わりに、これは一般ユーザー向けじゃなくて、社内の経理担当向けだよっていう方向性の部分だけを書き換えるわけです。
それならできそうですね。でも簡単なタスクで毎回それをやるのもやっぱり面倒ですよね。
ええ、実務的には毎回使う必要はないんです。長者の基準も非常に合理的でして。
ほう、どんな基準ですか?
もしAIが失敗して、最初からやり直すことになったら30分以上かかりそうな重い仕事の時だけ、このプランモードをオンにする。それくらいの割り切りで十分だと分析していますね。
なるほど。失敗した時のリカバリーコストと計画をチェックする手間のトレードオフってことですね。
あの、マヌスのアプローチは単一のタスクならすごく利にかなっていると思うんですが。
はい、単一タスクならそうですね。
私が普段抱えているプロジェクトって、もっと複数のエージェントが裏でガチャガチャ動くような規模なんですよ。
一つのエージェントを手動で止めておけるならいいですが、複数のAIが連携し始めたら全部の計画をチェックするなんて不可能じゃないですか。
そこで直面するのが、エージェントの群れ、つまりスウォームをどう制御するかという問題ですね。
これに対する一つの回答が、クロードコードのバージョン2.1.21などのアップデートに現れています。
クロードコードですか。それはマヌスとは違うアプローチなんですか。
クロードコードの計画モードは、ターミナル上に読み取り専用で計画を出してきて、ユーザーは自分の使い慣れたVSコードなどのテキストエディターでそれを修正する形になります。
ただ、最も重要なのはその後の制限なんですよ。
制限ですか。それはどんな制限なんですか。
同時に動かすコエージェントの上限が、デフォルトで20に制限されたんです。
06:04
さらに、コエージェントがマゴエージェントを勝手に笛属させる機能が初期状態で無効化されました。
マゴエージェントの増殖を止めた。それって要するに、エージェントが勝手に思いっこで調べておいてって部下を作りまくるのを禁止したってことですよね。
そういうことです。それに加えて、設定した予算の上限に達した時点で、バックグラウンドのタスクも強制的に停止するようになっています。
なんでそんな厳しい制限を設けたんでしょうか。
背景にあるのは文脈の喪失とAPIコストの暴走ですね。
親エージェントが子を作り、子が孫を作っていくと、孫エージェントの段階ではそもそも何のためにこのコードを調げているのかという最初の前提が抜け落ちてしまうんです。
あー、伝言ゲームみたいになってハルシネーションを起こしちゃうわけですね。
ええ、結果として無関係なリポジトリを延々とスクレーピングし始めたりして、知らぬ間に莫大なクラウドリソースを消費してしまうことが多々あるんです。
AIの人数が増えれば賢くなるかと思いきや、ただ毎月のAPI利用量の請求書がとんでもなく跳ね上がるだけだと。
ははは、まさにそうです。
請求書を守るためのリミッターなんですね、それって。
そうなんですよ。だからこそ、計画の段階で何人に仕事を振るのかとか、予算はいくらかという制約を物理的に組み込んでおく必要があるわけです。
なるほど。クラウドコードは数や予算で暴走を抑え込むわけですね。
でも、数人のエージェントに絞ったとしても計画自体は完璧だったのに、いざ作業が始まったら盛大にシステムをぶっ壊すことってありますよね。
ありますね。実行フェーズのエラーは本当に怖いです。
そういうのはどう防ぐんですか?
それに対するアプローチが、アンチグラブティというツールのCLI 1.1.5のアップデートなんです。
これは、二段構えの防壁を張っています。
二段構えですか?
はい。まず、プランモードでプロジェクト全体の方向性を決める。
ここまでは他と同じなんですが、その後、実際にローカルのファイルを書き換える直前に、行単位の差分プレビューを出して、一旦プロセスを停止するんです。
ほう。
これがリクエストレビューモードというもので、デフォルトで備わっているんですよ。
ちょっと待ってください。設計図の段階で一回承認して、さらに実際のコードを書き込む直前、つまり現場でレンガを積む瞬間にもう一回、このレンガここに置いていいですか?って聞いてくるってことですか?
ええ、まさにそういうイメージです。
いやいや、それはいくらなんでも過保護過ぎませんか?人間側がロボットをマイクロマネジメントしているみたいで、逆にストレスが溜まりそうですけど。
確かに、毎回確認を求められるのは面倒に感じますよね。でもこれにはアーキテクチャ上の明確な理由があるんです。
どんな理由ですか?
システム開発において、最初の計画段階でどれだけアーキテクチャの方向性があっていたとしても、実際の作業でたった一行の環境変数の設定コードとか設定ファイルの名前を間違えて上書きしたり削除しただけで、システム全体が起動しなくなる事故って頻発するんですよ。
うわあ、それは想像しただけで胃が痛くなりますね。
そうなんですよ。5秒間の事前チェックをサボったせいで、壊れた環境を直すために3時間のロールバック作業が発生するなんてこともありますからね。
09:04
3時間ですか。それはきつい。
だからこそ、時間のかかる複雑な仕事であればあるほど、入り口である計画と出口であるファイル書き込み直前の両方で監視する方が、結果的な操作業時間は圧倒的に短くなるんです。
なるほど、そういうことですね。
さらに、アンチグラビキの最新版では、スラッシュFオートというコマンドでAIの思考の深さを選べたり、小エージェントごとにモデルを指定できるようになりました。
つまり、アーキテクチャの設計とかセキュリティに関わる重い部分は賢くて高いモデルに深く考えさせて、単純なテキストの置き換え作業なんかは軽くて早いモデルに振る、みたいなリソース配分ができるわけですね。
その通りです。急がば回れを単なる精神論ではなく、システムとして実装しているのが今のトレンドと言えますね。
計画を直すことや、実行前に止めることの重要性は痛いほど分かりました。ただ、ここからもう一つ疑問が出てくるんですが。
はい、何でしょう。
これだけ頻繁に計画をエディタで修正していると、今度は、あれ、見た前にこのエージェントの計画、何で書き換えたんだっけ?って、自分自身の修正理由を忘れてしまいそうなんです。
ああ、それはよくありますね。
人間側のバージョン管理の悪部というか、そういうのってどう対応すればいいんでしょうか。
素晴らしい着眼点です。まさにそこが今回の資料の後半で著者が最も強く警告しているポイントなんですよ。
そうなんですか?
ええ。ツールによっては、画面上に同じプラン、つまり計画という言葉が表示されていても、その裏側のアーキテクチャでの扱い方が全く違うんです。この違いを理解していないと、大惨事を引き起こします。
計画の扱い方が違う。具体的にどういうことでしょう。
例えば、プログラミングに特化したコーデックスのバージョン0.145.0を見てみましょう。
コーデックスでは、ユーザーがAIへのプロンプトを編集して計画を修正した際、元の会話を上書きして消すのではなく、別の枝、ブランチを作って歴史を残す仕組みになっています。
ブランチを作る。それってGitのバージョン管理みたいなものですか?
まさにそれです。なぜなら、なぜその前提を変更したのかという思考のプロセス自体が非常に重要なコンテクストだからです。
なるほど。
元の案を上書きしてしまうと、後から振り返った時に、AIが最初にどんな前提を置き、人間がそれをどういう意図で修正したのかという差分がわからなくなってしまいます。歴史を残すことで、思考のバージョン管理ができるわけです。
ああ、このバージョンでターゲット層を一般ユーザーから経理担当に変えたんだったな、という文脈が残るわけですね。それはすごく助かる機能ですね。
一方で、ジェンスパークのワークスペース6.0はどうでしょう?
こちらはユーザーの過去の検索履歴やプロジェクトのドキュメントが一つに統合された非常に強力な作業環境なんです。
ほうほう。
しかし、公式の発表を見る限り、マヌスやアンチグラビティのように、実行前に計画を人間が直接編集する工程や、確認するまで作業を止めるゲートの仕組みが明記されていないんですよ。
12:03
えっと、ちょっと待ってください。確認ゲートがないってことは、AIにこの機能を追加してって依頼したら、過去の別のプロジェクトの記憶とかが混ざった状態の計画のまま、いきねりコードを書き始めちゃう可能性があるってことですか?
アーキテクチャ上は、そういうリスクをはらんでますね。記憶が統合されているがゆえに、どの前提を引っ張ってきたのかがブラックボックスになりやすいんです。
それはちょっと怖いですね。
だから、著者は、ジェンスパークで複雑な仕事を頼むときは、いきなり実行させるのではなく、まず実行せずに計画だけを出力してとプロンプトで明示的に指示する必要があると言っています。
自分でブレーキをかけるんですね?
ええ。出てきた計画を手動でドキュメントに保存してから、次の実行ステップに進むという自衛が必要だと説いているんです。
ツール側が自動で止めてくれないなら、人間側で意図的にブレーキを踏むプロセスを作らないといけないんですね?計画を立ててくれますって書いてあるから安全だと思ったら、いきなり走り出しちゃうかもしれないと?
そうなんですよ。さらに他のアプローチとして、ヘルメスエージェントのバージョン2026年7月20の場合は、計画をドットヘルメススラッシュプランズという隠しホルダーにマークダウンファイルとして物理的に保存します。
物理的に保存するんですか?
ええ。これは案件の引き継ぎや別の日にお仕事を再開するときに、ファイルさえ渡せばコンテキストを復元できるので非常に有利です。
なるほど。それは便利そうですね。
ただし、保存しただけでは次の実行時のルールにはならないんです。次に依頼するときに、このフォルダーの計画ファイルを読んでから実行してねと明示的に指示する必要があります。
へえ。ファイルとして継続化されるけど、それを読み込ませるトリガーは人間が引かないといけないんですね。じゃあ、オープンソース界隈で最近よく聞くオープンクローはどうですか?
オープンクローのβ版のアップデートプランという機能はさらに軽量ですね。これはAIモデルがタスクをこなすための一時的なチェックリストにすぎないんです。
一時的なチェックリストですか?
はい。ヘルメスのようにファイルを永続的に保存したり、システムの設定を根本から書き換えたりするものではないんですよ。
つまり整理すると画面上に同じ計画と表示されていても、オープンクローのようにただの使い捨てのメモ帳だったり、ヘルメスのように物理的な設計図として保存されたりするわけですね。
そうです。
はたまたジェンスパークのように境界線が曖昧なまま実行されちゃうこともある。ツールによって私たちが計画という言葉に抱く重みが全然違うんですね。
その通りです。だからこそ、自分が使っているツールのアーキテクチャが計画をどこに置き、どう扱うのかを正確に把握しておくことが不可欠なんですよ。
なるほどな。
見た目のマークダウンが綺麗だからといって、これでAI全員に前提が完璧に伝わったと安心するのは、目隠しをして高速道路を走るようなものですから。
いやー、めちゃくちゃ解像度が上がりました。
ツールに振り回されるんじゃなくて、ツールの裏側にある設計思想を理解して使い分ける必要があると。
15:05
さて、あっという間に時間が来てしまいました。
今日、この膨大な資料から私たちが持ち帰るべき最大のアクションプランは何でしょうか。
記事の著者が最後に語っている結論が最も実用的ですね。
AIの計画書は全部読まなくていい。実行前にAIが勝手に掘った前提条件を一行だけ見つけて直す。これにつきます。
一行だけ直すですか。
ええ。例えば計画書に、全ファイルを対象に整理と書いてあったら、それをsrcフォルダ内のみ対象に直す。
なるほど。
新機能を追加するとなっていたら、既存のテストが通る範囲でと書き足す。
実行フェーズの細かい作業手順を20行書き直すよりも、入り口であるこの前提の一行を修正する方が、結果的にプロジェクト全体に圧倒的な効果をもたらすんです。
リカバリーコストを防ぐことができるわけですね。手順の修正ではなく、前提の修正、これがたった一行の魔法なんですね。
そうですね。
今朝のニュースレターのアップデート情報から、私たちがこれからの自動化時代にAIとどう向き合っていくべきかという大きなテーマまできれいにつながりました。
リスナーの皆さんは、次にAIが出してきた立派な計画書を見るとき、どこを最初に見ますか?ぜひ手順ではなく、一行目の前提をチェックしてみてください。
最後に一つ、少し視点を変えたお話をしてもいいですか?
もちろんです。お願いします。
私たちは、AIが勝手に間違った前提を作って、見当違いの計画書を出してくるとき、ついAIが勘違いしたとか、AIが間違えたと思いがちですよね。
確かに、そう思っちゃいますね。
でも実は、それって私たち自身の最初の指示、つまりプロンプトの出し方が曖昧だったことの鏡でもあるんですよ。
鏡ですか?
はい。私たちがAIの計画書に赤ペンを入れて直しているとき、実はシステムのダグを修正しているだけでなく、私たち自身の言語化できていなかった無意識の思い込みを修正しているのかもしれないんです。
自分は暗黙のうちにこういう条件を期待していたんだなと気づくわけです。
次にAIに仕事を頼むとき、あなた自身のどんな無意識やバイアスがAIの計画書に浮かび上がってくるか、少し自分自身の思考の癖を観察するつもりで計画書を眺めてみていかがでしょうか。
それはすごくハッとさせられる視点ですね。
AIのミスは自分自身の言葉足らずな部分や当たり前だと思い込んでいた前提を映し出している。
なんだか、AIをマネジメントすることが自分自身の思考をクリアにするトレーニングみたいに思えてきました。
本当にそうだと思います。
さて、本日の深掘りはここまでです。
ぜひ今日から全部読まずに、一行の前提を探すという視点でAIと付き合ってみてくださいね。
それではまた次回の深掘りでお会いしましょう。
良い一日を。
