『いい感じで』ではAIは動かない

全問正解でも、実行は始まらなかった。 数字は合っている。ファイルを作る力もある。 それでもAIは設計の話を続けたまま、目の前の仕事に着手しませんでした。

b-jamの今井です。

この記事に書いてあること

• AIが賢くなるほど道具の差だけでは勝負がつきにくくなっていること
• 「いい感じでお願いします」で実行が始まらない理由
• AIを動かすために最初に決めておきたい一言と一文

賢くなるほどAI同士の差が縮んでいる

GPT-5.6・Gemini 3.6・Opus 5を実務で比較しました。同じ素材と同じ正解を渡し、様式仕上げ・監査・振り分け・文章起草・長文処理で見ています。

個別の検証はGPT-5.6・Gemini 3.6・Opus 5の記事にまとめました。細かな得手不得手はあります。ただ経営や現場の視点で見るとどれを選んでも大差がつきにくいところまで来ています。

直近のOpus 5では、仕事の振り分けで5点満点中4.88点でした。40日分の記録から拾うべき数字も12個中12個を正しく拾えています。

もちろん万能ではありません。Opus 5は幅広い実務で使える一方、監査の最終裁定だけは1段厳格に倒れました。指摘の根拠は正しくても採用できるものを修正扱いにする。修正で済むものを却下する。弱点が消えたというより、弱点の場所が変わったと見るほうが実態に近そうです。

だからモデル選びを雑にしてよいわけではありません。ただ「どれが一番賢いか」に時間を使うだけでは、業務はまだ動かないんですよね。

それでも目の前で足が止まった実験

使ったのは業務向けの一般的なAIアシスタントで、b-jam自身のテナントで試しています。別の実験で、共有フォルダの在庫や仕入のファイルから月次集計表を作るようAIに頼みました。正解が分かっている題材を使い、依頼の仕方を変えて再現しています。

最初は「疑問点があればヒアリングして要件をまとめてから作って」と伝えました。するとAIは確認を重ね、設計案を出し、また次の質問へ進みました。丁寧ではあります。でも設計コンサルモードにとどまり続けます。

そこで「たぶん毎月同じ。いい感じでお願いします」と返しました。人同士なら「では進めます」となりそうな返事です。ところが実行は始まりませんでした。AIはさらに設計の話を続けたのです。

能力が足りなかったわけではありません。同じ実験では依頼の型を変えた3パターンすべてで最終出力が全問正解でした。表計算ファイルも作れています。できないAIを見ていたのではなくできるのに始めないAIを見ていました。

似た症状は以前の記事「AIの微妙な出力、実は聞き方次第」（「AIの微妙な出力、実は聞き方次第」）でも書きました。今回はそれを道具の性能でなく組織でAI活用を進めるときの構造の問題として、もう一段掘り下げます。

止まっていたのは精度でなく「実行の許可」だった

この実験で分かれたのは答えの正しさではありません。実行が始まるかどうかでした。

AIは「質問して」と言われれば質問します。「要件をまとめて」と言われれば設計の相談が続く。ここまで進んだら作り始めてよいという境界がないと親切に確認を続けることがあります。

つまりボトルネックは精度から実行の許可へ移っています。賢いAIを入れれば仕事が進むとは限りません。どの時点で考えるのを終え、何を合図に手を動かすのか。そこまで決めて初めて業務の流れになります。

「いい感じで」は要望の委任にはなっても実行の許可にはならなかった。この違いは小さく見えますが、現場では成果物が出るか出ないかを分けます。

b-jamも同じ壁にぶつかっていた

これはAIに限った話でもありません。b-jam自身の制作工程でも、ほぼ同じ失敗をしました。

記事を本文まで書いた後でテーマごと差し戻しになり、約2,300字の原稿を2稿分無駄にしました。書く力や文章の精度より前に、進め方の合意が抜けていたのです。正直これは痛かったです。

足りなかったのは「本文を書く前にアウトラインを確認する」という契約の一文でした。どこまで進んだら一度止めるのか。誰のOKで次へ進むのか。それが工程に入っていませんでした。

この記事は先にアウトラインを確認してから本文を書いています。自分を実験台にしてようやくAIへ求めている設計をb-jam自身も守るようになりました。偉そうなことは言えないなと思います。

効いたのはたった一言と一文だけだった

処方箋は複雑ではありません。実験で効いたのは次の2つでした。

1つ目は実行トリガーの一言です。

「◯月分を実際に作ってください」

設計の話から抜けられなかったやり取りも、この一言で実行へ進みました。「お願いします」だけで終えず、何を実際に作るのかまで動詞で伝えます。

2つ目は冒頭で交わす契約の一文です。

「要件が固まったら実行用の指示文を作って見せて。OKと言ったら実行して」

この一文があると「いい感じで」という生返事でもAIが残りの仕様を決めて実行用の指示文を見せました。人がOKを出した後に実行へ進みます。一度で動き出さないこともありました。そのときは「ファイルも作って」と一押しすれば進みました。

ここで大事なのは長いプロンプトを書くことではありません。要件整理と実行の間に見せる場所をつくり、OKを実行の合図にすることです。

見るのは1点だけです。AIがどのファイルを元に作ろうとしているか。AIは先回りで手元のファイルを探しに行くので、ここがずれていると計算は合っているのに中身だけ違う出力になります。

しかも見せてもらった指示文は、その場限りで消えません。次回も使える資産として残ります。

選ぶことより先に決めておくこと

以前の記事「AIの道具選びは本質じゃない」（「AIの道具選びは本質じゃない」）では、道具より業務から考える話を書きました。その考えは今も変わりません。

そこに今回もう1つ加えたいのが実行の設計です。どのAIを選ぶかより先に、どこまでAIに考えてもらうのか。どの成果物を作るのか。何を実行の合図にするのか。この3つを決めておく。モデルの差が縮むほど、こちらの設計が効いてきます。

一方で選ぶ場面がなくなるわけではありません。使える範囲や前提条件は製品ごとに違います。その点は、無料と有償の境界を整理した記事（「「無料でCopilotが使える」は半分だけ本当」）でも書いています。

まずは貴社の1つの業務で、実行の一言を一緒に設計しませんか。対象業務と今の進め方を伺い、AIが止まる境界を見つけます。