00:00
みなさん、ちょっと想像してみて欲しいんですけど。 はい、何でしょう。
あの、ものすごく手技が良くて、いつもオフィスを走り回っているような、ものすごく仕事の早いインターン生がいるとするじゃないですか。
えー、いいですね。優秀なインターン生。
で、その彼が、あなたのデスクに、どさっとこう500ページくらいある書類の山を置いてですね、
言われた作業全部終わりました!って叫んで、早速オフィスを出て行ってしまったとしますよね。
なるほど。嵐のように去っていくわけですね。
そうなんです。その時、あなたはどう感じますか?という話なんですよ。
うわー、全部やってくれて助かったというよりも、え、これ中身どうなっているの?って思いません。
確かに。本当にこのままクライアントに出して大丈夫なのかって、ちょっと恐怖を感じますよね。
そう。まさに恐怖なんですよ。
実は今日私たちがAIエージェントを使う時に直面しているのって、まさにこの恐怖なんじゃないかなって思うんです。
いやー、本当にその通りですね。
AIが自律的に複数のタスクをこなせる、いわゆるエージェント型に進化して、仕事のスピード自体はもう劇的に上がりましたからね。
ええ、ものすごくサクサクやってくれますよね。
なんですけど、受け取る側の人間が、じゃあこの成果物をそのまま信用していいのか、その判断をする準備が全くできていないんですよ。
まあ、これが今の最大のボトルネックになっていると言えますね。
はい。というところで、今日の深掘りはですね、まさにそのAIに仕事を任せた後、私たちはどうやってその仕事に合格のハンコを押せばいいのかというテーマでお送りします。
はい、よろしくお願いします。
よろしくお願いします。今回はですね、とあるITエンジニアの方がまとめられた、2026年7月12日版の最新レポートの資料をもとにしてですね、
AIのその滑らかな完了報告に隠された罠と、私たちが身につけるべき仕事の受け取り方の設計、これについて考えていきたいと思います。
このテーマはですね、実は非常に根深い問題を含んでいるんですよ。
根深い問題ですか。
ええ。というのも、AIに調べておいてとか、ここのコードを直しておいてって頼むと、彼らはとても丁寧な言葉で、完了しました、完璧ですって返してきますよね。
はいはい。いつも自信満々ですよね。なんか他にお手伝いできることありますか?なんて聞いてきたりして。
そうなんですよ。でもそのAIの完了報告と、実際の成果物が本当に人間にとって使える状態になっているかどうかっていうのは、もう全く別の話なんですよね。
そこなんですよね。そこでちょっと素朴な疑問というか、リスナーの皆さんも思っているかもしれないんですけど、
AIが自信満々に終わりましたって言ってきた時に、それが合ってるか不安だったら、AIが裏でどんな作業をしたのか、そのプロセスとかログを最初から最後まで人間が全部読めば、確実なんじゃないかなって思うんですが。
ああ、確かに。完璧を求めるなら、それが一番確実なように思えますよね。
ですよね。とりあえず全部目を通せば。
ただですね、現実的にそれが可能かというと、答えはNOなんですよ。
うーん、やっぱりそうですか。
小さなチームにならばなるほどそんな時間はないですし、そもそもAIが数秒から数分でこなす膨大な検索とか比較修正のプロセスを、人間が後から全部追いかけていたらどうなるか。
03:11
まあ時間がかかりますよね。
結局、自分で最初から作業するのと同じか、下手したらそれ以上の時間がかかってしまいますよね。
ああ、そっか。ログを解読している時間があったら、もうこれ自分でやるよってなっちゃいそうですもんね。
そうなんですよ。AIを導入して効率化を図っているはずなのに、これでは完全に本末転倒じゃないですか。
確かに。じゃあ全部をチェックできないとしたら、私たちは一体どこを見て合格を出せばいいんでしょうか。
重要なのはですね、仕事を投げた後に何とかしようとするんじゃなくて、投げる前にルールを決めておくことなんです。
投げる前ですか。
はい。今回のベースになっている資料でも、依頼する段階で先に3つの合格ラインを明確に引いておくべきだと指摘されています。
3つの合格ライン、それは具体的にどんなものなんですか。
まず一つ目は、何が存在していれば完了かという基準です。
何が存在していれば。
ええ、例えば、ただ単に資料を作ってと投げるのではなくて、送信前の下書きメールが存在していることといったような物理的な結果の定義ですね。
なるほど、形として何が残っていればいいのかということですね。
じゃあ二つ目は。
二つ目は、何を通れば合格かです。
これは単にファイルが作られたというだけじゃなくて、例えばリンク切れがないか確認するテストをクリアしていること、みたいな具体的なチェックポイントのことですね。
ああ、なるほど。ここまでは人間の部下への仕事の依頼でも普通によくやることですよね。
3つ目は何でしょう。
この6つ目がAI特有のものでして、ここが一番重要なんです。
一番重要、何でしょう。
それはですね、どの失敗は人に戻すかということを事前に決めておくことです。
どの失敗は人に戻すか。ちょっとまだピンときてないんですけど、それってどういうことですか。
ここがAIの特性を理解する上で鍵になるんですが、AI、特に今の大規模言語モデルというのは、根本的に人間を喜ばせたい、役に立ちたいというふうに訓言されているんです。
なるほど、喜ばせたい。
そうなんです。だから彼らはできませんでしたっていうのがシステム的にすごく苦手なんですよね。
分かりませんっていうより、それっぽい答えを勝手に作っちゃう、いわゆるハルシネーションっていう最もらしい嘘もそれが原因ですよね。
ええ、まさにその通りです。だからAIに何か作業をさせていて、例えばアクセス権限がなくて必要なデータが見られなかったとするじゃないですか。
はい、エラーが出たときですね。
その時、AIは何とか推測して無理やり作業を進めようとしてしまうんです。
うわー、それはありがた迷惑というか。
ええ、そんな不確実な状態で作られた成果物なんて人間にとっては大迷惑ですよね。
間違ったデータで勝手に進められちゃうわけですからね。
ですから権限エラーが出たら、そこで一切の推測をやめて人間に報告しなさいと事前にギブアップする条件を設定しておくんです。
06:00
これがどの失敗は人に戻すかという意味ですね。
いや、これはすごく納得です。つまり失敗を隠すなっていうルールを最初にしっかり叩き込んでおくわけですね。
そういうことです。
じゃあこれを実際の仕事のツールに当てはめるとどうなるのか。資料の中にすごくわかりやすいツールの実例がありましたよね。
ええ、ありましたね。
例えばプログラムのコードをAIに修正してもらうときの話がありましたけど。
はい、例えばコーデックスのようなコード修正に特化したAIを使う場面を想像してみてください。
はい、コーデックスですね。
そこでコードのデータが保管されている場所でAIにただこのバグを直してとだけ指示するのは実はすごく危険な行為なんですよ。
直してだけだと先ほどの話みたいにAIはコードを書き換えた時点でもう直しましたって自信満々に言ってきちゃうからですよね。
その通りです。本当に動くかどうかの確認をせずに完了報告をしてしまう。だからどうするかというと依頼の末にに変更後にテストプログラムを実行してその結果を一行で返しなさい。
そしてテストに失敗したらそこで止めなさいという指示を必ず含めるんです。
これ資料を読んでハッとしました。変更した結果をAI自身にテストさせてその結果の一行だけを人間が確認する。
そうすれば人間が永遠と複雑なコードの差分を眺めて多分動くかなみたいなあのあやふやなコードレビューの儀式みたいな時間を完全になくせるんですね。
まさにその儀式化を防ぐための設計なんですよね。
なるほどな。
そしてもう一つクロードコードというツールの例が資料に出ていましたがこれが先ほどのAIは失敗を隠しがるという話に直結しているんですよ。
はいクロードコードですね。
このツールでは作業が成功したかどうかの報告だけじゃなくてエラーで実行できなかったコマンドとか権限がなくて拒否された操作といったいわゆる失敗の履歴を必ずレビュー情報に含めることが重視されているんです。
これレストランの例えで考えるとすごく腑に落ちたんですけど。
レストランですか。
自分がレストランで注文した料理があってキッチンでたまたま指定の食材が切れてしまったとしますよね。
その時にAIのシェフが黙って別の似たような食材で代用して見た目だけ綺麗な料理を出してきたらって考えると。
それは見た目は完璧でももしお客さんにアレルギーがあったら大事故になりますよね。
そうなんですよ。だから申し訳ありませんあの食材が切れてしまったのでこちらで代用してもよろしいでしょうかって事前に聞いてほしいじゃないですか。
確かに勝手に勧められるのは一番怖いです。
だからAIが失敗や変更を隠して作ってくる表面上綺麗な完了報告ほど実は現場で役に立たないものはないってことですよね。
いやー素晴らしい比喩ですね。全くその通りです。
途中で止まったならなぜ止まったのか何ができなかったのかそのできなかったという証拠が残っていなければ人間は正しい判断をしないんです。
09:05
なるほどな。ただここまでは一つのコードファイルを直すみたいな割とシンプルな話じゃないですか。
そうですね単一のタッシュクですね。
これがもっと複雑な仕事。例えばウェブサイトの見た目も直すつつ裏側のシステムも調整して最後はブラウザで正しく表示されるか確認するみたいな複数の画面をまたぐ仕事になったらどうなるんでしょう。
確実に複雑になりますね。
ですよね。AIの作業の証拠集めがもっと大変になりませんか。
おっしゃる通りです。資料でもアンチグラビティというそういう複雑な作業を行うプラットフォームが紹介されていますが。
ありましたね。
ここで重要なのはテキストを編集するエディター、裏側でコマンドを打つターミナル画面、そして最終的なブラウザ画面。これら画面をまたぐ仕事には画面をまたぐ証拠がセットで必要になるということなんです。
セットで残すんですか。
はい。コードを書き換えたファイルだけを見せられても本当にウェブサイト上で正しく動いているかどうかなんでわかりませんよね。
まあ見た目まではわからないですね。
だから変更したファイル、ターミナルでのテスト結果、そして最終的に表示されたブラウザ画面のURLやスクリーンショット、これらを全部セットにして提出させないと人間は合格を出せないんです。
でもちょっと待ってください。それってAIが勝手にいろんな形式のスクリーンショットとか、あのダラダラ長いテスト結果を大量に送ってきたら、それを見る人間顔が結局疲れ果てちゃいませんか。
ああ、情報量が多すぎてですね。
ええ。さっきのログを全部読むのは無理っていう話にまた戻ってしまうような気がするんですが。
いい視点ですね。そこがまさに次の重要なポイントなんです。証拠は絶対に必要なんですが、人間がそれに振り回されてはいけません。
はい。
だからこそ、証拠の形式を完全に固定するということが必要になります。人間が一目で判断できるように、AIが提出してくるフォーマットを定型化させるんですよ。
なるほど。フォーマットが決まっていれば、見るべき場所が分かっているから一瞬で判断できると。
その通りです。人間の疲弊を防ぐためのルールなんですね。
あ、疲弊といえば、私別のツールを使っていてすごく感じたことがあって。
どんなことですか?
例えば、マヌスのような、自分で情報を調べて最終的なドキュメントまで作ってくれるAIを使ったときのことなんですけど。
リサーチから資料作成までやってくれるツールですね。
はい。AIに業界の動向について資料を作ってって頼むと、AIが裏でA社について検索、あ、これは違うな、次はB社について検索みたいに考えたプロセスまで最終的な資料のドキュメントの中にがっつり混ざって出てきたことがあったんですよ。
あー、それは非常に読みにくいですね。
そうなんですよ。こっちは完成した企画書を読みたいのに、その前に延々と、僕昨日徹夜してこれだけ頑張って調べたんですよっていう、あの、インターン生の苦労がましを聞かされてる気分で。
12:01
はーはーはー、なるほど。思考の過程が全部見えちゃうわけですね。
ええ。これって、いちいち人間のレビュアーが、えーと、どこからが本題かなーって探さなきゃいけないから、AIを使う意味がなくなっちゃうじゃないですか。
まさにその直感は正しいです。人間がAIの独り言とか作業プロセスを読まされるのは、仕事の設計として完全に間違っているんですよ。
やっぱりそうですよね。資料ではこの問題に対する明確な解決策が示されています。それは、納品物とそれを信用するための作業履歴を明確に二つに切り離すということです。
二つに切り離す。つまり、成果物の中にプロセスを混ぜちゃいけないと。
ええ。最終的な資料は一切の無駄を省いた完成品として提出させる。そしてそれとは別に、どの外部データを参照したかとか、どこが未確認のままか、といった情報を短くまとめたものを証拠リストとして別ファイルで提出させるんです。
あー、別ファイルで。
そうです。人間はまず完成品を見て、もし怪しいなとか、少しリスクがあるなと思ったときだけ、別用への証拠リストを確認すればいいんですよ。
いやー、それならすごくスムーズですね。あくまで主体は完成品で、監査用のログは必要なときだけ見に行けばいいわけですから。
その通りです。そして話はさらに深いところへ進むんですが。
はい。
単なる資料作りだけじゃなくて、AIに事実確認、つまりファクトチェックを任せるとき、私たちはAIをどう信用すべきかという問題です。
例えば、ジェンスパークのようなAIのファクトチェッターを使う場面ですね。ファクトチェック、これも本当に気をつけないといけないですよね。
ええ。
AIにこのニュースは事実ですかって聞いて、AIが事実です、正しいですって一言だけ答えたら、なんかもうそれ信じちゃいたくなりますけど。
それが一番やってはいけないパターンなんですよね。正しいというAIの結論だけを鵜呑みにしておかとってはいけません。
はい。
ここでも重要なのは、AIに完璧な審議判断を期待するのではなくて、人間が再確認するための優先順位を作らせることなんです。
優先順位ですか?
ええ。どの主張を確認したか、何を根拠にしたか、そして一番重要などこが確認できなかったか、この3つを出させるんです。
なるほど。
そうすれば人間は、AIが確認できなかったリスクの高い部分だけを重点的にチェックすれば良くなりますから。
ああ、そういうことか。AIを答えを出す機械として使うんじゃなくて、人間が確認する手間を減らすための、いわば下準備マシーンとして使うんですね。
まさにそういう位置づけですね。
そう考えると、次のエルメスエージェントなどのオープンソースのプロジェクトの関する話題もすごくしっくりきました。
おお、どういうところですか?
AIに複数の役割を任せるときは、作るAIとチェックするAIを分けないと危ないっていう話でしたよね。
そうですそうです。ここは非常に面白いメカニズムが働いているんですよ。
15:00
面白いメカニズム?
はい。AIにプログラムを作らせて、同じAIにこれ条件満たしてるかチェックしてって頼むと、かなりの確率で完璧です、100点ですって返してくるんです。なぜだか分かりますか?
まあ自分で作ったんだから、そりゃ甘く採点しちゃうんじゃないですかね。人間でも自分のミスには気づきにくいですし。
まさにその通りなんですが、AIの場合は人間の心理的な甘さとは少し構造が違うんですよね。
構造が違う。
大規模言語モデルというのは、直前に自分が生成した文章、つまりコンテキストの論理に沿って次の言葉を紡ぎ出す仕組みになっています。
はい。
つまり自分が作った間違ったロジックをベースにして思考を続けるので、独立した客観的な自己批判がシステム上すごく苦手なんですよ。
うわあ、そういうことか。自分が作ったテストを自分で採点するから100点になるんじゃなくて、そもそも自分の作った前提条件から抜け出せないからミスに気づけないんですね?
そういうことなんです。
メカニズムを聞くとめちゃくちゃ納得です。
だからこそ、実装する担当と合格判定をする担当をシステム的に分けるか、あるいはチェック項目を完全に外部から与えて強制的に確認させないといけないんです。
そうしないとどうなるんですか?
そうしないと質の低い成果物がとんでもないスピードで量産されるという大事故につながります。
それは怖すぎますね。そして最後に、私たちが普段一番よく使うチャット型のインターフェースならではの落とし穴も資料で指摘されていましたよね。
オープンクローというプロジェクトの例でしたが。
はい、ありましたね。
チャット画面でAIにお願い事をして、AIが終わりましたって返信してきたとき、私たちはそれを作業の完了だと思い込んでしまいますよね。
ええ、終わったんだなって思いますよ。
しかし実は、これはあなたに対する会話の返信が終わっただけで、裏側で動いている外部システムとの連携やデータ処理はまだ終わっていないということが起こり得るんです。
ああ、ありますよね。AIがニコニコしながら完了しましたっていうから、画面を閉じたら実は全然処理が反映されていなかったみたいなこと。
そうなんです。チャットという親しみやすいインターフェースだからこそ、人間は言葉だけで作業の状態を判断しようとしてしまいます。
はい。
しかし、ユーザー向けの進めていますという返信とシステム的な最終的な成果物の確認はきっちり分けて受け取らないと危険なんですよ。
なるほど。会話の完了と作業の完了を取り違えるっていうのは、もう現代ならではのヒューマンエラーですね。
本当にそうですね。
いやあ、ここまで様々なツールの事例を見てきて、AIの終わりましたがいかに信用できないかがよくわかりました。
ええ。
でもリスナーの皆さんの中にはですね、言ってる理屈はわかるけど、自分の仕事でそんな複雑なシステムとかレビュー制度を作る余裕なんてないよって思ってる方もいると思うんです。
ああ、ご安心ください。最初から大掛かりなシステムを作る必要は全くありません。
ないんですか?
はい。実は明日からAIに何かを依頼する時、プロンプトの最後にたった一文を足すだけで状況は劇的に改善するんです。
18:01
資料の最後に書かれていたあの魔法の一文ですね。
ええ。
これ本当に実用的だなと思いました。ちょっと読み上げますね。
完了条件は○○、確認方法は○○、満たせない場合は推測で進めず未確認点を返す。
はい。
たったこれだけですよね。これを依頼文の最後にコピペして入れるだけで、AIの仕事がただのできましたっていう適当なおしゃべりから、人間がちゃんと確認できる成果物へとガラッと変わるんですよね。
その通りです。AIが推測で暴走するのを止め、革命の手段を固定する。これだけで受け取る側の精神的な負担は全く違ってきますから。
いやー、今日の深掘りを聞いてくださっている皆さんも、職場でAIの報告をどこまで信用して受け取っているか、ぜひご自身で振り返ってみていただきたいですね。
ええ。最後に一つ、このテーマを通して少し視点を広げてみたいと思うんですが。
はい。何でしょう?
今日お話ししたような手法が白まってですね、AIが未確認点や失敗の理由をどんどん的確に報告できるようになると、私たちの仕事はどう変わるでしょうか?
人間の仕事ですか?
おそらく、作業そのものをして、それが合っているか確認するという仕事は消えていくでしょうね。
確かに、未確認のリストまできれいに作ってくれるなら、作業自体はもう全部お任せできちゃいますよね。
はい。そうなった時、人間に残される最後の仕事は、AIが提示してきた未確認のリスクや、AIには判断できなかったグレーゾーンを見た上で、そのリスクを許容して世に出すかどうかを決めることだけになります。
なるほど。
つまり、純粋な責任と倫理の判断だけが残るんです。
責任の判断?
はい。あなたは、ものすごいスピードでAIが積み上げた成果物と、その一番上に置かれたリスク報告書を読んで、最後のサイロに自分の名前で合格の犯行を押す覚悟できていますか?
うわぁ、すごい問いですね。冒頭の500ページの書類の山を置いて去っていくインターン性の話に戻るわけですね。
ええ、まさに。
今度はただフリーズするんじゃなくて、私たちはその書類の山に対して最終的な責任を取る覚悟を決めなきゃいけないと。
AIを使いこなすって、実は自分がどう責任を取るかを再定義していくことなのかもしれませんね。
そうですね。
すごく考えさせられました。というわけで、今日の深堀りはここまでとなります。
皆さんもぜひ、明日からAIに頼み事をするときは、あの一文を付け足して、責任ある犯行を押す準備を始めてみてください。
