かつて、大きな電力会社で働いていたころ、稟議書というものを山ほど作りました。いわゆる、「お諮り文書」というものです。あのころ体で覚えたことが、ひとつあります。資料は、分厚いほど通る。
ペラ一枚で持っていくと「これだけ？」という顔をされる。同じ中身でも、参考資料や他社事例をぶ厚く挟んで持っていくと「よく調べたね」と言われて、すっと判子が並ぶ。中身が本当に動くかどうかとは、たぶん、あんまり関係ない。分厚さは、決裁する人を安心させるためのものなんですよね。しかも当時の筆者を含む同僚諸兄は、それを分かって、意図的に分厚ーいのをこさえていたと思います。……過去の話ですからね。
なぜこんな昔話から始めたかというと、いまエンジニアとして関わっている「AIエージェント開発」の現場で、あのときと同じ匂いをしょっちゅう嗅ぐからです。いちばん分厚くて、いちばん流暢なデモが、いちばん使われない。 それなのに私たちは、つい分厚いほう・流暢なほうに安心して、判子を押してしまう。あのころの決裁者と、たぶん同じ顔で。
（電力会社の元サラリーマンが、なぜAIエージェントの現場にいるのか——その回り道は自己紹介に書きました。書き手の素性が気になったら、どうぞ。）
「うちでもAIエージェントを作れます」――そう言い切る提案書が、いま日本中の会議室を埋め尽くしています。デモは滑らかに動く。画面の向こうでエージェントが質問にスラスラ答え、タスクをこなしていく。発注したくなる気持ちは、痛いほどわかります。でも、半年後にそのエージェントが現場で毎日使われているかと聞かれて、「はい」と即答できるプロジェクトは、正直、驚くほど少ない。
先に結論を言ってしまいます。この記事はあえて逆張りします。“AIエージェントを作れるコンサル”という言葉ほど、発注する側が警戒したほうがいいものはありません。 とはいえ、誤解しないでくださいね。「AIエージェントは使えない」という話ではないんです。むしろ逆で、ちゃんと設計すれば現場は確かに変わる。問題は技術力ではなく、もっと手前――発注から設計までの「組み立て方」にあります。
これから、ある架空の、でもどこにでもありそうなプロジェクトを一つ、最初から最後まで追いかけます。前半は「分厚い提案書を買ってしまった会社」がたどる末路。後半は「同じ会社が、地味なやり方に切り替えたら何が起きたか」。あなたの会社のいまのAIの話を、頭の片隅で重ねながら読んでもらえると、うれしいです。
分厚い提案書を買ってしまった会社の話
たとえば、こんなプロジェクトがあったとします。
中堅の機械メーカー。カスタマーサポート部門が、問い合わせ対応に追われています。そこへAIコンサルがやってきて、「問い合わせ対応AIエージェント」を提案する。デモは見事でした。チャット欄に「納期はいつですか」と打つと、エージェントが流暢に、丁寧に答える。役員たちは「おお」とどよめいて、その場でGOサインが出ました。
提案書は100ページありました。最新モデルの構成図、市場規模、競合事例、ロードマップ。プリントアウトすると、ちょっとした卒業論文……いや、電話帳くらいの厚みです。ずっしり。一見、すごーくしっかりして見える。
——ここで、さっきの稟議の話を思い出してください。この100ページに役員が感じた安心は、たぶん「中身が動く確信」ではなくて、「これだけ調べてあるなら大丈夫だろう」という、あの分厚さへの安心です。筆者が電力会社で味わっていた、あの感覚そのまんま。怖いのは、その安心が、本番では一円の役にも立たないことなんですよね。
さて、半年後。鳴り物入りで導入されたエージェントは——現場の、誰にも、使われていませんでした。マル無視です。
なぜか。デモで使われた質問は「よくある質問」ばかりだったんです。でも現場に来る本物の問い合わせは、例外だらけ。「先月の注文番号◯◯の件で、特殊梱包をお願いしていたはずなんですが」「前回クレームを入れた分の代替品、いつ届きますか」。こういう、過去の経緯と社内の事情がからんだ問い合わせに、エージェントは自信満々に間違える。
ここが、致命傷でした。自信満々に間違えるAIは、現場にとって、いないより厄介なんです。 担当者は結局すべてをダブルチェックするはめになる。「これなら自分でやったほうが早い」。そう気づいた瞬間に、エージェントは静かに見捨てられます。100ページのどこにも、「誰の」「どの業務の」「どの瞬間を」楽にするのか、具体的には書かれていなかった。書いてあったのは、立派な構想だけでした。
なぜ「動くデモ」は「使われる業務」にならないのか
デモと本番運用のあいだには、川どころか、谷があります。多くのプロジェクトは、この谷で落ちる。理由はわりと単純で、デモは「動くこと」を証明するために作られ、本番は「使われ続けること」を求められるから。求められているものが、最初から違うんですよね。
谷を生む原因は、だいたい次の3つに集約されます。
- 技術先行：最新モデルを使うこと自体が目的になって、「誰のどの仕事が楽になるのか」が後回しになる
- UX不在：エージェントの賢さばかりが語られて、人がそれをどう呼び出し、どう信頼し、どう直すのかが設計されていない
- 業務接続の欠落：既存の業務フロー・権限・データ・例外処理につながっておらず、現場の“最後の一歩”で詰まる
とくに見落とされがちなのが、2つ目です。
これ、実は仕事とは関係ないところで腹落ちした感覚がありまして。少し脱線させてください。筆者はスノボ好きと釣り好きが高じて長野に移住したクチで、スキマ時間にはリンゴやブドウを育てる果樹農家のお手伝いをしたりしながら暮らしています。あるとき、農園主さん（70代です）と「いやあ、人手が足りなくて」という話をしていて、短時間だけ働き手を集められる求人アプリ――最近よくある、空いた数時間にスポットで人を呼べるやつ――の存在が話題に出ました。便利そうじゃないですか。実際、よくできたアプリなんです。
でも、農園主さんには使えませんでした。スマホの細かい操作がそもそもつらい。応募者とのチャットのやりとり、本人確認、当日のドタキャンへの対応……一つひとつが、彼の手と段取りに馴染まない。そして果樹農家は全国的に高齢化が進んでいるので、これは彼ひとりの話じゃないんです。業界まるごとで、「便利なはずの道具」が現場に届いていない。
賢さとか、機能の多さの問題じゃないんですよね。「その人の手と、目と、段取りで、その場で本当に使えるか」のほうが、ずっと手前に立ちはだかる。
AIエージェントも、まったく同じです。現場の担当者の「手と目と段取り」に合っていなければ、どれだけ賢くても、誰も触らないボタンになる。世にあふれる「AIエージェント コンサル」の提案の多くは、この“現場の手”を一度も見ないまま、設計図だけを描いている。だから、流暢なのに使われないんです。 件のアプリは農家の方専用のアプリではなく、広い業種に対応できる設計だったと思います。しかし、「農業」はそのアプリの使い勝手のせいで図らずもこぼれ落ちていたのは明白でした。
さて、文句はこのへんにしておきましょう（このままだと、それこそ例の“無名評論家風”になってしまう）。大事なのは「で、どうするの」ですよね。ここから先は、さっきのメーカーが、もし最初から地味なやり方を選んでいたら何が起きたか、という話をします。
同じプロジェクトを、地味なやり方でやり直す
巻き戻しましょう。同じメーカー、同じ「問い合わせが多すぎる」という悩み。ただし今度は、モデルの話から始めません。順番に見ていきます。
ステップ0：モデルの話を、いったん全部やめる
最初にやるのは、どのモデルを使うかでも、アーキテクチャ図を描くことでもありません。「現場の一日」を、ただ観察することです。
筆者がAIエージェントの案件で最初にやるのは、たいていカスタマーサポートの席のうしろに座って、一日ぼーっと眺めることです。誰が、どのタイミングで、どんな問い合わせに、何分かけて、どこで手が止まっているのか。地味です。でも、これをやらずに作るのは、行ったこともない畑のために道具を選ぶようなもの。たいてい、的を外します。
ステップ1：いちばん効く「一点」だけを選ぶ
観察すると、見えてきます。問い合わせの中身は、実はわりときれいに分かれている。「配送状況の確認」みたいに、答えが定型的で量が多いものと、「クレームの経緯がからむ相談」みたいに、判断が要るけど量は少ないもの。
ここで、欲張らないことです。全部に答えるエージェントではなく、「配送状況の一次回答」という一点だけを狙う。あれもこれもできる賢い相棒、を最初から目指すほど、皮肉なことに、何にも使われないものが出来上がります。狭く始めるほど、確実に立てる。
ステップ2：人間が「どこで手綱を握るか」を設計する
ここがいちばん大事で、いちばん飛ばされる工程です。
「AIが自動で返信する」ではなく、「AIが下書きを作って、担当者がワンクリックで承認して送る」にします。AIは一次回答の文面を用意するところまで。送信ボタンを押すのは人間。担当者から見れば、ゼロから書く手間が消えて、確認と微修正だけになります。
そして、AIが「これは自信がない」と判断した問い合わせ（例外、クレーム、過去の経緯つき）は、自動で人間にエスカレーションする。自信満々に間違えさせない。 「わからないときは、わからないと言って人に渡す」。これを設計に組み込むだけで、現場の信頼はまるで変わります。さっきの“いないより厄介なAI”が、ここで“ちゃんと頼れる下働き”に変わるんです。
ステップ3：既存の仕組みに、無理なくつなぐ
配送状況を答えるには、配送管理システムの中を見にいく必要があります。だから、そこに接続する。どの担当者がどこまで見ていい権限なのか、例外のときは誰に渡すのか。地味な工程です。でも、この「つなぎ込み」をやらないと、エージェントは社内の現実から切り離された“賢いおもちゃ”のままで終わります。
ステップ4：狭く出して、「効いた」を一つ作ってから広げる
3週間後。「配送状況の一次回答」だけをやる、ものすごく地味なエージェントが動き始めます。派手さはありません。役員に見せても「え、これだけ？」と言われるかもしれない。昔の筆者の感覚でいえば、稟議には通しにくい“薄さ”です。
でも現場では、一次回答のほとんどをAIが下書きするようになって、担当者の手が目に見えて空いた。毎日、使われている。 ここで初めて、「次はこの問い合わせ種別も」と横に広げていきます。一点で「効いた」を作ってから広げる。これが、現場で生き残るエージェントの育て方です。
ビフォーアフター ― 何が変わったのか
同じプロジェクトの、ビフォーとアフターを並べてみます。
ビフォー：100ページの分厚い提案書。最新モデルを謳う流暢なデモ。役員は感動、現場は半年後に誰も使っていない。残ったのは、立派な構想と、見捨てられたエージェント。
アフター：提案書はA4で数枚。「対象業務（配送の一次回答）」「人間の介入点（承認とエスカレーション）」「接続先（配送システム）」「成功の測り方（担当者の処理時間）」しか書いていない。代わりに、地味だけど毎日使われるエージェントが、ちゃんと動いている。
卒業論文並みだった分厚い資料は数枚に縮んで、その代わりに、現場で本当に動くものが残りました。インクの無駄遣いが減って、仕事も減った。
差を生んだのは、モデルの性能ではありません。体験設計（どう使われるか）と、業務接続（どこに組み込まれるか）です。同じ基盤モデルを使っても、片方は「賢いけど使われないデモ」になり、もう片方は「地味だけど毎日使われる業務の一部」になる。分かれ道は、次の問いに最初から答えているかどうか、なんですよね。
- 誰の、どの業務の、どの瞬間を肩代わりするのか
- 人はどこで介入して、どこで承認して、どこで訂正するのか
- 間違えたとき、現場はどう気づいて、どうリカバリーできるのか
- 既存のツール・権限・データに、どう無理なくつなぐのか
これは「モデルを選ぶ」問題ではなくて、「体験と業務を設計する」問題です。だからAIエージェント開発は、モデルの議論から始めてはいけない。使う人の現実から始めるべきなんです。
発注する人へ ― 提案書の厚さの代わりに、何を見るか
最後に、これから「AIエージェントを作れます」という提案を受ける人へ。AIエージェント コンサルを名乗る相手を見極めるとき、見てほしいのは、デモの流暢さでも、提案書の厚さでもありません。たった一点です。
「うちの、誰の、どの仕事の、どの瞬間を楽にするんですか？」 と、聞いてみてください。ここに、具体的に・現場の言葉で答えられる相手は、たぶん信用できます。逆に、最新モデルの名前と市場規模の話に戻っていってしまう相手は……あの分厚い稟議書を、もう一度あなたに渡そうとしているのかもしれません。
派手なデモを作ること自体は、正直、それほど難しくないんです。難しいのは、半年後も現場で静かに使われ続けるものを残すこと。逆張りに聞こえるなら、それは業界がいかに“デモ”と“分厚さ”に最適化されてきたか、の裏返しでもあります。
「作れます」ではなく「使われ続けます」と言えるかどうか。発注先を選ぶ基準は、そこに置いていいと思います。あの日の筆者が、薄い資料でも胸を張れていたら、たぶんもっといい仕事ができたはずなので。
この記事は、ARCHECOが運営するメディア「アプリ戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。
