1. AIと仕事の仕組み化ラジオ
  2. AIエージェント日次速報 2026..
AIエージェント日次速報 2026年7月14日版 AIへの指示を「会話の中」から外へ出そう
2026-07-14 20:08

AIエージェント日次速報 2026年7月14日版 AIへの指示を「会話の中」から外へ出そう

朝に動かしたAIエージェントが、夕方には別のエージェントや人の手に渡る。いまの仕事では、これはもう珍しい話ではない。

昨日は、止まった仕事をどこから安全に再開するかを書いた。今日は再開方法の話ではない。日々の会話で生まれた指示を、次の担当が使える場所へどう移すかを考えたい。調べたURLはどれか。変更してよいファイルはどれか。まだ決まっていない判断は何か。これが会話の奥に沈んだままだと、次の担当は毎回ゼロから仕事を読み直すことになります。

2026年7月14日時点で、Codex / Claude Code / Antigravity / Manus / Genspark / HermesAgent / OpenClaw...

感想

まだ感想はありません。最初の1件を書きましょう!

00:00
あのー、ちょっと想像してみて欲しいんですけど。はい、なんでしょう。 例えば、同僚から土豪と雑談が入りかじったような、2時間くらいの会議の録音データをポンと渡されてですね。
うわー、それはちょっと嫌ですね。 ですよね。で、無編集のそのままのデータを渡されて、あとはよろしくなんて言われる状況をちょっと考えてみてください。
いや、それはもうその同僚のことを一生恨むかもしれません。
ああ、間違いないですよね。だって、どこに重要な決定事項があるのかとか、何が保留になっているのかとか、そもそも自分に何をしてほしいのか、録音を最初から全部聞き直さないとわからないわけですから。
本当にそうですね。
でも、実は今、私たちがAIエージェントに対してやっていることって、まさにこれと全く同じなんですよ。
いやー、痛いところ疲れますね。人間同士なら絶対にやらないような雑なコミュニケーションを、なぜか相手がAIだと平気でやってしまっているんですよね。
そうなんです。
これ、実はこれからの時代、非常に深刻のボトンネックになりつつあるんです。
というわけで、今日もザ・ディープダイブの時間がやってきました。今これをお聞きのあなた、通勤中でしょうか、それともお仕事の合間でしょうか。今日も一緒に知識の深掘りを楽しんでいきましょう。
よろしくお願いします。
今回私たちが解き明かしたいテーマはですね、あるITエンジニアの方が2026年7月14日に公開したブログ記事に基づいています。
タイトルがですね、AIエージェント日時速報2026年7月14日版、AIへの指示を会話の中から外に出そうというものです。
この資料は、まさにAIに仕事を任せることが日常になった今の時代に、すごくクリティカルな問題を提起してくれてますね。
そうですよね。朝、自分が指示を出して動かし始めたAIエージェントの作業を、夕方には別のAIに渡したり、あるいは人間のチームメンバーに引き継いだりする、そんなふうにタスクが次々とリレーされていく時代ですから。
そこで本日の私たちのミッションなんですけど、AIとのやり取りを毎回ゼロから始めず、どうすればスムーズに次の担当へ引き継げるのか、というところを探っていきたいと思います。
今やもう多くの人が、AIをどう使うかという段階は通り越えているんですよね。
確かに。次はどうマネジメントするかですね。
そうです。AIが作業した結果をどう管理して、情報を適切に整理するか、AIと人間のハイブリッドなチームワークをどう構築していくかというのが、これからの新しい働き方を左右する重要なテーマになっています。
よし、じゃあちょっとこれをひも解いてみましょうか。
はい、いきましょう。
まず、なぜAIへの指示が迷子になってしまうのか、という点なんですけど、オープニングでお話しした録音データの丸投げの例えですね。ブログの筆者もまさにこれと同じことを指摘しているんです。
ええ。
AIとの長いチャットログをそのまま次の担当者に渡して、これ読んで進めて、というのは、情報がすべてそこに入っているとはいえ、あまりにも非効率だと。
おっしゃる通りですね。チャットのログというものは、あくまで思考の過程であって結果ではないんですよ。
03:03
思考の過程、なるほど。
ええ、そこから何が確定していて、何がまだ未定なのかを抽出する作業というのは、人間にとっても、次にそのログを読み込む別のAIにとっても、ものすごいエネルギーの無駄遣いになってしまうんです。
そこで筆者が提案している解決策が、会話から出す4行のメモなんですよね。これ具体的にはどういう構成なんでしょうか。
非常にシンプルで無駄のない4項目になっています。まず1つ目は目的ですね。
目的、つまりゴールですね。
はい、そのタスクが最終的に何を完成させるものなのかを定義します。そして2つ目が確定事項です。
確定事項というと、もう決まっていることですか。
ええ、すでに使ってよいと決まっている情報とか、終わった工程、あとは触れてもよいシステムの範囲なんかですね。
作業の前提条件を明確にするわけですね。
そういうことです。そして3つ目が未確定事項です。
まだ決まっていないこと。
はい、現在誰の判断を待っている状態なのか、あるいは作業を進める上で確認が必要な前提は何かという点ですね。
そして最後の4つ目が次の操作です。
次の操作。
バトンを受け取った次の担当者が最初に実行すべき確認作業と、その仕事が終わったとみなされる条件ですね。
なるほど。先ほどの録音データの例えを考えると、この4行があるだけで全然違いますね。
全く違いますよ。
ただ、あえて聞かせてください。
はい、何でしょう。
この4行の引き継ぎメモを毎回毎回書くのって、実務の中だと結構面倒じゃないですか。
例えば、散らかったキッチンのまま次のシェフに後はよろしくっていうよりは間違うんでしょうけど、
とにかく忙しいときにわざわざこのフォーマットを埋めるだけの価値が本当にあるんでしょうか。
ここですごく興味深いのがですね、この4行は完璧なマニュアルを作ること自体を目的としているわけではないという点なんです。
と言いますと。
この4行の真の狙いは、次に引き継いだ担当者あるいは次のAIが最初の数分で迷わず判断できる状態を作ることなんですよ。
ああ、最初の数分ですか。
はい。
引き継がれた側が一番時間を浪費するのって、次の一手として何をすればいいのかを探る時間ですよね。
確かに手が止まっちゃいますよね。
だからこの4行はその迷いをなくすための最小限の投資なんです。
このわずかな投資を惜しんでチャットログを丸投げすると、結局後からこれってどうなってましたっけという確認のやり取りが発生して何倍もの時間を失うことになります。
うーん、すごく納得です。
キッチンの例えで言うなら、完璧に掃除されていないのと一緒に、せめて使っていい食材はこれとか、このお肉はまだ火が通ってないよっていうメモさえあれば、次のシェフはすぐに料理に取り掛かれますもんね。
まさにその通りです。最初の一手でつまずかせないための投資ですね。
なるほどな。
ただですね、ここで一つ別の問題が浮上してくるんですよ。
え、なんでそう?
この4行のメモが強度手順だとして、それとは別にチーム全体で守るべき高級的なルールというのも存在しますよね。
06:07
ああ、キッチンで言えば包丁は使った後必ずここに戻すみたいなことですね。
そうですそうです。この2つの情報を同じ場所に混ぜてしまうとまた混乱が起きてしまうんです。
なるほど。日々も引き継ぎメモの重要性は分かったけれど、それをどこに置くのか、そしてチームのルールとどう切り分けるのかという物理的な保管場所の話ですね。
ええ、その通りです。ブログではこの問題に対していくつかのAIツールのアプローチを例に挙げています。
はい。
例えば、オープンAIのCodexというツールの利用ガイドでは、リポジトリの中にagents.mdという特定のファイルを作って、そこをAIエージェント向けの指示書として扱うことを推奨しているんです。
あの、ちょっと待ってください。IT界隈でよく聞くそのリポジトリって、要するにプロジェクトに関する全てのファイルとかプログラムのコードが保管されている大元の倉庫みたいな理解であっていますか?
ええ、まさにその理解で完璧です。その大元の倉庫の中に、AI専用のルールブックとしてagents.mdを置くわけです。
ふむふむ。
プログラマのコードを見ただけで分からないような、システム同士の依存関係とか、そのチーム固有の手順といった高級的な仕事の約束ごとをそこに記録するんです。
日々のタスクじゃなくて、普遍のルールを置く場所なんですね?
そうです。さらに、GoogleのAntiGravityというツールの設計思想も非常に参考になりますよ。
Googleのツールですね?
ええ、彼らはホルダー屋のアクセスをプロジェクトという単位に絞り込んでいて、繰り返される高級的な指示は.agents.rulesというルール専用の場所に置くんです。
はい。
一方で、今日だけの依頼は、タスク本文であるワークフローズの方に明確に分けるという設計をしています。
つまり、お店の秘伝のタレのレシピは誰でも見られるわけじゃなくて、金庫のルールホルダーに入れておいて、今日のランチの注文はキッチンの付箋に書く、みたいに情報の置き場を完全に分離するわけですね。
わかりやすいですね、その例え。
でも少し疑問なんですけど、もしそのagents.mdのようなファイルにチームのルールをあれも追加、これも追加ってどんどん書き足していったら、
最終的に誰も読まない、すごく分厚いマニュアルになってしまいませんか?
ルールその342、みたいな感じで。
いや、素晴らしい視点です。
まさにそれが多くのチームが陥る罠なんですよ。
あ、やっぱりそうですか。
だからこそ、ブログの記者も全部を書く必要は全くないと強く主張しているんです。
え?全部書かなくていいんですか?
はい。本当に残すべきなのは主に3つだけなんです。
1つ目がテストを実行する際の正式な入力。
2つ目が絶対に勝手に変更してはいけない禁止領域。
なるほど、触っちゃダメなところですね。
ええ。そして3つ目が外部にデータを送信するなど、人間が承認しなければならない視点。
09:00
この3つだけでいいと強調しています。
なるほど。細かい手順をいちいち書くのではなくて、ここだけは踏んではいけない地雷と人間が関わるポイントさえ押さえておけば、大事故は防げると。
その通りです。そして最も重要なのは、日々変わる進捗状況のような一時的な情報を、この高級的なファイルに絶対に混ぜないことなんです。
混ぜちゃいけないんですね?
はい。混ぜてしまうと、後から読んだ人が、
あ、このルールの部分は古い進捗の話だから無視していいやって思ってしまって、全体が信用されなくなるんです。
ああ、誰も読まないマニュアルが完成しちゃうわけだ。
そうなんです。だからこそ、置き場を明確に分けることが、情報のチンプタを防ぐ最大の防御策になるんです。
いやー、ルールの置き場一つ取っても不快ですね。で、ここからが最高に面白いところなんですけど。
はい。
ルールの置き場も決まって、AIが実際に作業をして、その結果を私たちに返してくるとき、私たちはその結果をどう受け取ればいいのか、というログの扱いの話題です。
AIとの共同において、ここは非常に実践的で、かつ落とし穴の多い部分ですね。
そうですよね。ブログでは、アンスロピックのクロードコードというツールが紹介されています。
はい。
これを使って、別のAI、つまりサブエージェントに調査を任せた際、長い探索のロゴを全部そのまま返してもらうのではなくて、
結論、根拠となるURL、未確認事項、そして次に必要な判断という順番で、きっちり要約して返してもらうのが良いと書かれていますね。
延々と続くチャットログをそのまま流し込むのではなく、要約という明確な引き継ぎの境界線を意図的に作るアプローチですね。
そしてもう一つ、マーニュースというツールの非同期タスクの考え方も出てきました。
非同期タスクって、要するに私たちが画面に貼り付いていなくても、裏側でAIが勝手に進めてくれる作業のことですよね。
そうですね。
このマーニュースでは、AIとの会話メッセージとは全く別に機械的な状態、つまりステータスを取得する仕組みがあるそうですね。
ステータスには実行中とか待機中とか停止、エラーなんかがあるみたいですが。
このチャットの会話と機械的なステータスを切り離すという考え方は、実務において非常に強力なんですよ。
ここでブログの中にあった小話なんですけど、私これに大いに笑ってしまったんです。
何でしょう?
AIの報告文は大体前向きだっていう指摘、これすごくリアルですよね。
確かに。
AIってどんな状況でも全て順調です、素晴らしい結果が出ましたってやたらと元気に報告してくるじゃないですか。
なんか初元しい新入社員みたいで。
ええ、わかります。
AIモデルって基本的にユーザーを助けたり肯定したりするようにトレーニングされているので、どうしてもポジティブなトーンの文章を生成しがちなんですよね。
12:03
でも文章では順調ですって言っていても、裏側のシステムではエラーが起きて大炎上しているかもしれない。
おっしゃる通りです。
だからAIが書いてくる文章の温度感とか雰囲気に騙されちゃダメで、機械的なステータスを確認しろということですよね。
これをより大きな視点、全体像と結びつけてみると、なぜステータス管理がそこまで重要なのかが見えてくるんです。
はい、教えてください。
例えば、AIが市場調査が完了し素晴らしいレポートが完成しました、長文で前向きな報告を上げてきたとしますよね。
はいはい。
でも、そのデータのプロパティの1行目に、状態、待機中、つまり人間による確認待ちという機械的な値がポンと置かれているだけで、状況は一変するんです。
あー、なるほど。
その無機質な1行があるだけで、次にタスクを引き継いだ人間やAIは、
あ、文章は元気だけどまだ未完成で外に出しちゃいけないんだなって一瞬で判断できるわけです。
確かに、もしこのステータス管理がなくて元気な報告文だけを信じて、未確認のデータをクライアントに送信してしまったら、
もう大事故ですよね。人間同士でも愛想のいい言葉より、今の進捗状況を正確なフラグで伝えることの方が重要じゃないですか。それと全く同じなんです。
間違いないですね。元気よくエラー出てますって言われても困りますしね。
ふふふ、そうですね。
要約できっちり区切ること、そして雰囲気ではなく機械的なステータスで状態を引き継ぐこと、これは今日からすぐにでも意識したいポイントですね。
ええ、確実なバトンパスには欠かせない要素です。
さて、これで4行のメモも書き、ルールの場所も分け、ステータスも完璧に引き継いだとしましょう。
はい。
でももし、バトンを受け取った次のAIが、そもそもその作業をするための権限や道具を持っていなかったらどうなるのか、という実行環境の引き継ぎの話題に続いていきます。
ここは、AIの運用が高度になればなるほど見落としげちな落とし穴ですね。
情報のバトンを渡せても、走るための靴を渡していなかったというような状況です。
ブログではここで3つのツールが紹介されていますね。どういったアプローチでこの問題を解決しているんでしょうか。
まず、ジェンスパークが提供しているAIワークスペースというアプローチです。
これは、成果物への入り口を一つに絞るという考え方ですね。
入り口を一つに。
複数のチャット画面やブラウザーのタブがあちこちに散らかっていると、そもそもどの環境で作業していたかという前提が引き継げないんです。
だから、一つのURLやワークスペースから全てのデータと環境にたどれるようにするわけです。
なるほど。物理的な散らかりを防ぐわけですね。では、次のハーメスエージェントというのは。
これは非常に重要で、実行環境、つまりプロファイルを切り替える機能を持っているんです。
プロファイルですか。
はい。プロファイルというのは、例えばこのAIは今、社内テスト用の環境にいるのか、それとも本番環境にいるのかといった設定のことですね。
15:04
ああ、なるほど。
指示文のメモに、使用プロファイルは調査用とか、外部へのデータ送信は無効といった環境の前提条件そのものを残すことを推奨しているんです。
あの、ちょっと待ってください。同じ指示文を引き継いでいるんだから、環境なんてそんなに気にしなくても結果は同じにならないんですか?
いや、そこが怖いところなんですよ。
えー。
例えば、古いファイルを削除して整理してという全く同じ指示を引き継いだとしますよね。
前任のAIはテスト環境で安全に作業していたのに、引き継いだ次のAIが本番環境のプロファイルで実行してしまったらどうなるでしょう?
うわー、本番の重要なデータが全部消し飛びますね。
そうなんです。だからこそ、指示だけでなく、どの環境で実行するかを引き継ぐことが必須になるんです。
うわー、それは恐ろしい。
最後のオープンクローというツールも同じ思想で、AIに機能を追加するスキルという単位に、必要な環境や権限の前提が必ず紐づくようになっています。
スキルですね?
はい。引き継ぎの未確定事項に、このスキルを実行するための外部接続は有効になっているかを含めるべきだとしています。
つまり、これって結局どういうことなんでしょう?
私の素直な感想を言うと、入り口の一つにまとめるとか、プロファイルの設定名をいちいちメモするとか、正直かなり地味で面倒な作業に思えるんですよね。
ええ、わかります。日米の業務でそこまできっちり管理してたら、かえって時間がかかってAIで業務を効率化する意味がなくなるような気がするんですが。
これはある重要な問いを投げかけていますね。
私たちは何のためにAIを使っているのかということです。
ブログの著者は非常に本質的なことを言っているんですよ。
探す時間は毎日少しずつ人を疲れさせると。
探す時間は人を疲れさせる。いや、ものすごく耳が痛いです。
私たちが地味で面倒だと感じるこの環境と前提の引き継ぎ設定は、完璧な説明書を作るためのものではないんです。
先ほどの4行メモの話にも通じますが、次の一手を小さく、そして安全にするための投資なんですよ。
投資ですね。
特に便利なスキルや高度なAIほど、前提条件なしで無防備に動かすと、先ほどのファイル削除のように取り返しのつかないミスを引き起こします。
急がば回れですね。
なるほどなぁ。
ものすごくよく切れる包丁を渡すからには、ちゃんとしたまな板の上でどういう持ち方を使うかという環境もセットで渡さないと大怪我をするということですね。
まさにその通りです。
今日紹介されたツールの考え方は、エンジニアの方だけじゃなくて、今これをお聞きのあなたを含め、これからAIを使って仕事をする全ての人に関係してくる話ですね。
間違いありません。特別な技術者だけの話ではもうなくなっていますから。
リスナーの皆さんは今、ただAIに作業を丸投げする一作業者から、複数のAIや人間を束ねてプロジェクトを動かす、AIチームのマネージャーになりつつあるんですね。
18:10
AIへの支持出しは、もう自分たち人間のためのものじゃない、次にバトンを受け取るAIのための短い約束に変わってきているんだなぁとすごく感じました。
そうですね。そしてここから少し思考を広げてみると、さらに興味深い未来が見えてくるんですよ。
何でしょう?
もし近い将来、AI自身がこの魔法の四行を完璧に自己生成するようになったらどうなるでしょう?
え?AIが自分で引き継ぎメモを書いて、次のAIに渡すってことですか?
ええ。自分たちだけで要約を作って、エージェンツMDのルールを適宜更新して、環境のプロファイルもチェックしながら、タスクを釣り継ぎと人間を介さずにリレーしていく。
うわぁ、すごいですね、それ。
そんな風に、AI同士のエコシステムが自律的に回り始めたとしたら、私たち人間のマネージャーに残される役割は一体何になるのでしょう?
それは、えっと、すごくハッとさせられる問いですね。
単に最終確認の承認ボタンを押すだけの係になってしまうのか?
それとも、AI同士のリレーでは生み出せない全く新しい価値とか、ルールそのものをデザインする存在になれるのか?
これは、AI時代を生きる私たちにとって、少し時間をとって考えてみる価値がありそうなテーマですよね。
確かに、AI同士が完璧なバトンパスをし始めたとき、私たちがグラウンドのどこに立っているべきか、それを今から考えておく必要がありますね。
本当にそう思います。
さて、というわけで本日のディープダイブはここまでです。
非常に刺激的な議論でしたね。
散らかったキッチンのまま、次の担当者に後はよろしくというのは、今日でおしまいにしましょう。
今お聞きのあなたも、ぜひ明日の仕事からAIへの依頼の最後に、あの目的、確定事項、未確定事項、次の操作の4行を足してみてください。
それだけで本当に変わりますからね。
それだけで、あなたのAIチームが劇的に動き出すくなるはずです。
それではまた次回の深盛りでお会いしましょう。
20:08

コメント

スクロール