AIエージェントの作り方｜想像ではなく実際の文面から作る

私はADHD（不注意や多動・衝動性に特徴がある発達障害）なので物をよく無くします。そこで玄関にラベルを貼りました。帰ってきたときに、手に持っているものをどこへ置くか、先に決めておきたかったからです。

鍵、財布、イヤホン、眼鏡拭き。棚のふちに、テープで4枚並べました。

ところが、実際に持って帰ってくるのは、そこに書いていないものばかりでした。傘、レシートの束、保育園からの紙、コンビニの袋。

そこでラベルを足しました。18枚になりました。それでも、置き場所が決まっているものは半分もありません。

同じような振り分けの問題は、AIを業務に組み込む場面でも起きます。AIエージェント（利用者の指示に応じて必要な処理を選び、実行する仕組み）を業務に組み込む会社が、ここ数年で一気に増えてきました。ただ、AIエージェントの作り方で最初に効いてくるのは、AIの中核となるモデルの選定でも、開発の土台となるフレームワークの選定でもありません。話しかけられた一文を、どの処理へ振り分けるかという、入り口の分岐です。

僕も、AIエージェントの入り口の分岐の作り方を外しました。採ったのは、来そうな言い回しを人が1本ずつ書き出し、文字列のパターンで入力を判定する正規表現というやり方です。分岐を27本並べ、34本まで増やし、最後にファイルごと消しています。

先に一行だけ置きます。AIエージェントを作るとき、利用者がどう話しかけてくるかを、人が想像で書き出してはいけません。 列挙できるのは、書いた人が思いつく言い方だけだからです。

今回話すプロジェクトは、水回りリフォームの現地調査アプリに、話しかけ欄を付けた

大企業と僕の会社の共創事業として、水回り専門のリフォーム会社が使う、現地調査アプリを立ち上げました。最小限の機能だけを先に作って現場に出す、MVP（必要最小限の機能で価値を確かめる製品）という進め方です。扱うのは、戸建てのユニットバス、洗面台、トイレの入れ替えです。

現地調査は、調査担当が1人で客先へ行きます。浴室、洗面所、トイレの順に、寸法と配管の位置と既存の型番を、写真つきで記録していきます。1軒あたり40分から60分。その場で概算の見積を出して、帰る前に、工事を頼む家の持ち主に見せます。現場では、この人を施主と呼びます。

作ったのは、その調査アプリの下に置いた、話しかけ欄です。項目を順に選ばせるのをやめて、「次へ」でも「ユニットバスを一段下げて」でも、思ったことを一文だけ入れれば通る、という欄にしました。調査担当は、手が濡れていたり、しゃがんでいたりして、画面を細かく触れない時間が長いからです。

話しかけ欄に来る言葉は、3種類に割れます。画面を進める指示（「次の箇所へ進んで」「ここは飛ばして」）。いま見ている設備についての質問（「この給湯器、まだ部品って出ますか」）。そして見積のやり直し（「ユニットバス、ひとつ下のグレードで出し直して」）です。

今日は、その振り分けをどう作って、どう外したか、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、正規表現で分岐を書いた

AIエージェントの作り方の教科書には、入り口の分岐について定石が書かれています。モデルを呼ばずに決められるものは、正規表現で即決する。 そのほうが速く、安く、結果がぶれないからです。

素直にそのとおり書きました。

次へ進む言い方を6本。飛ばす言い方を6本。戻る言い方を3本。見積のやり直しを疑う言い方を12本。合わせて27本の正規表現を並べ、どれにも当たらなかったものは質問として扱う、という作りです。

この27本は、ちゃんと動きました。「次へ」と打てば次の箇所へ進み、「スキップ」と打てば飛びます。モデルを呼んでいないので、返りは一瞬です。

調査アプリを社内で見せたときも、問題は出ませんでした。この段階では、教科書が正しいと思っていました。

② 現場で使ってもらったら、見積のやり直しが一度も始まらない

ところが、調査アプリを実際の現場の調査担当に使ってもらうと、様子が変わりました。

見積のやり直しが、一度も始まりません。調査担当が話しかけ欄に打ち込んでも、見積は作り直されず、ただの返事が出るだけです。

最初に疑ったのは、見積を作り直す側の処理でした。呼ばれてから中で失敗しているのだろう、と考えたからです。

処理の記録であるログを開くと、そもそも呼ばれていませんでした。入り口の時点で、質問の経路に流れていました。

そこで、見積のやり直しを疑う言い方を12本から19本に増やしました。「プランを変えて」の語順違い、「別の候補を出して」の言い回し。そのうえで、遠回しな頼み方まで足しています。雨や暑さの話、疲れたという体調の話、もっと短くという時間の話。施主が横にいる場で「安くして」とは言いにくい。だから、そういう言い方で見積を軽くしてくれと頼んでくるのではないか、と考えました。分岐は全部で34本になりました。

それでも、見積のやり直しは始まりませんでした。

③ 気づいたのは、拾えなかった一行をログに出したとき

増やしても動かないので、増やす手をいったん止めました。

代わりに、どのパターンにも当たらなかった入力を、そのまま書き出す一行をログに足しました。当たったときはどのパターンに当たったかを、当たらなかったときは入力の頭から60字を残します。

半日ぶんのログを開いて、当たらなかった側だけを読みました。

並んでいたのは、こういう文です。「みつもりやりなおして」。「ユニットバスやめて」。「おまかせで」。

漢字が1文字も無い入力があります。設備の名前に否定形をくっつけただけの口語があります。何をしてほしいのか書いていない、丸投げの一言があります。34本のどれにも、かすりもしていませんでした。

ここではっきりしました。増やす方向が、そもそも間違っていました。

④ 原因を1件に絞る

外した理由として思い当たることは、いくつもあります。テストに使った入力が綺麗すぎたこと、現場に出るのが遅かったこと、ログを最初から出していなかったこと。

ただ、原因を絞ると1件でした。

利用者がどう話しかけてくるかを、人が想像で書き出したこと。

列挙できるのは、書いた人が思いつく言い方だけです。ところが実際に来るのは、思いつかなかった言い方のほうです。27本でも34本でも、この関係は変わりません。数が足りなかったのではなく、列挙という方法が入り口に向いていませんでした。

⑤ 直したのは1箇所だけ

やったことは1件です。見積のやり直しの判定からだけ、正規表現を全部消しました。 19本が0本になっています。

代わりに、モデルが必要に応じて呼び出す「道具」を1つ渡しました。道具といっても実体は短い定義文で、「見積をやり直す」という名前と、呼ぶときに何を添えるかが書いてあるだけです。呼ぶかどうかは、モデルが決めます。呼べば見積の作り直しが走り、呼ばなければ普通の返事になります。

画面を進める指示の分岐は、そのまま残しました。「次へ」「スキップ」「戻る」は、言い方が有限だからです。

分岐のファイルは、81行から52行になりました。

この状態で同じ入力を流すと、「みつもりやりなおして」も「ユニットバスやめて」も「おまかせで」も、見積のやり直しとして拾われました。

⑥ あとで知った ── その渡し方には名前がついていました

しばらくして、ソフトウェアの設計について長く書いてきた Martin Fowler のサイトで、開発会社 Thoughtworks の技術者が寄せた実務記事を読み、手が止まりました。

Kiran Prakash が2025年5月に書いた、モデルに関数を呼ばせる話です。そこには、モデルは呼び出しを自分では実行せず、呼び出しの中身を説明するデータを作って、別のプログラムに渡すだけだ、と書かれていました。原文はこうです。「The LLM does not execute these calls directly, instead it creates a data structure that describes the call, passing that to a separate program for execution and further processing」。

僕が手探りでやったのは、まさにこれでした。名前は function calling、日本語では関数呼び出しと訳されています。同じ記事には、道具に付ける説明文が、その道具が何のためのものかをモデルに伝える、とも書かれていました。原文は「the description field provides extra context to help the LLM understand the function’s purpose」。

つまり、分岐は消えていませんでした。正規表現から、道具の説明文へ引っ越しただけです。

引っ越したのなら、移った先が効いているかどうかを確かめる方法が要ります。それも同じサイトにありました。Bharani Subramaniam と Martin Fowler が2025年2月に出した、生成AIのパターン集です。特定の仕事の文脈でモデルの応答を評価すること。それに Evals（評価）という名前が付いていました。原文は「Evaluate the responses of an LLM in the context of a specific task」です。

続けて書いてあるのは、Evalsでは結果を合格か不合格かの2択で見ない、ということです。合格とみなす基準値であるしきい値を置いて、前より下がっていないかを確かめる。 原文はこうです。「Unlike tests, they aren’t simple binary pass/fail results, instead we have to set thresholds, together with checks to ensure performance doesn’t decline」。

説明文は、書いて終わりではなく、測るものでした。新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

正規表現を消してから22日後、画面を進めるために残していた15本——次へ6本、飛ばす6本、戻る3本——も消しました。分岐のファイルは、52行まるごと削除しています。

いま入り口にあるのは、モデルへ渡す道具が3つだけです。見積をやり直す、いま見ている設備について調べる、画面を進める。どれを呼ぶかは、毎回モデルが決めます。

ただ、代償があります。3件書いておきます。

1件目。「次へ」の一言でも、モデルを1回呼ぶようになりました。 正規表現なら待ち時間ゼロで返っていたところに、通信と生成の時間が乗ります。速さと安さを、判断の幅と交換した形です。

2件目。分岐は消えず、説明文へ移りました。 3つの道具に付けた説明文を数えると、合わせて1,391字あります。52行のファイルが、1,391字の散文に置き換わった形です。

そして道具を3つにしてから17日後、散文になった副作用が出ました。「静かな給湯器ってないですか」という、調べてほしいだけの一言が、見積のやり直しへ流れていたのです。見積が丸ごと作り直され、関係のない設備が候補に混ざりました。

だから、説明文に境目を書き足しました。「見積をやり直す」は見積を作り直すとき専用で、近い製品のおすすめや在庫の質問は調べる側へ回す、と明記しています。

そのうえで、説明文に書き足した境目が効いたかどうかを、道具の選択結果で確かめました。現場から集めた入力を並べ、こちらが「これはこの道具を呼ぶ場面だ」と決めた正解（期待する振り分け）と、モデルが実際に選んだ道具が一致するかを数えました。比べる入力は、書き足したあとに現場から集まったぶんを足して、45件から54件に増やしています。一致は、45件中38件から、54件中54件になりました。 「静かな給湯器ってないですか」は5回中5回とも見積のやり直しに流れていたのが、6回中6回とも調べる側になっています。

3件目。利用者の一文だけでは、呼ぶ道具が決まらなくなりました。 「それも見積に入れて」と言われても、「それ」が何を指すのか分かりません。だから、会話の文脈として、直前のやり取りを毎回8件ぶん一緒に渡すようにしています。渡す量が増えれば、そのぶん費用も増えます。

⑧ 現場でAIエージェントを作るなら、この順番

入り口の分岐を決めるときに使っているのは、次の3つの問いです。

問い	はい	いいえ
言い方が有限か（ボタンの文言・決まった合図）	正規表現で即決する	モデルへ道具として渡す
間違えても誰かが気づくか（画面に出るか、黙って進むか）	そのまま任せる	人が確かめる一段を挟む
説明文を直したあと、測れるか	進めてよい	先に入力の一覧を作る

いちばん効くのは、3つ目の問いです。説明文は、人が普段使う言葉で書く自然言語なので、ある道具の説明文を直した瞬間に、説明文を直していない道具の判定まで動きます。 45件中38件だった一致が54件中54件になった一方で、書き足し方を誤れば逆へも同じだけ動きます。

だから、AIエージェントを作る順番は次の4件になります。

1件目、入り口の分岐を1つだけ選ぶ。全部を一度に道具へ移さない。

2件目、その分岐に来る入力を、実際に動いているアプリのログから集める。「みつもりやりなおして」は、机の上では出てきません。

3件目、道具の説明文を書き、集めた入力を流して、どの道具が選ばれたかを数える。ここで初めて、説明文が良いか悪いかを言えます。

4件目、説明文を直したら、同じ入力をもう一度流して、下がった項目が無いかを見る。合格と不合格ではなく、前回の数字と比べます。

この4件は、扱っているものには依存しません。浴室でも、部品でも、契約書でも同じです。

⑨ この作り方が効き続ける理由

モデルが賢くなっても、この順番は変わらないと考えています。

話しかけ方を決めているのは、モデルではなく利用者だからです。日本語を話す人の数だけ言い方があり、そこには漢字を打たない人も、否定形で頼む人も、丸投げする人もいます。列挙が追いつかないのは、モデルの性能の問題ではありません。27本を34本に増やしたときと同じことが、モデルを新しくしても起きます。

一方で、道具の説明文の効き方は、モデルを乗り換えると変わります。同じ説明文を渡しても、道具の選ばれ方が動きます。だから資産になるのは説明文そのものではなく、説明文を測るための入力の一覧のほうです。その一覧を1本作っておけば、乗り換えるたびに使い回せます。

この入り口の設計を実際の業務に落とす話は、AIエージェント開発のページに整理しています。作りかけのAIエージェントで、どこまでを正規表現で決めるか迷っている工程があれば、こちらからご相談ください。

玄関のラベルは、18枚とも剥がしました。棚に置いたのは、いちばん大きいカゴを1つだけです。

代わりに、カゴの横へ紙を貼りました。何を入れていいかを書いた紙です。

いま貼っているのは3枚目の紙で、いちばん下の行に「傘はここに入れない」と書き足したところです。

以上です。

▶ この記事のテーマを実務で相談する: AIエージェント開発