AIは判断に、コードは計算に——18分のエージェントが85秒になった理由

毎月の報告書や週次のまとめをAIに任せるとき、数字の集計と、その数字についての考察を、まとめて頼んでいないでしょうか。

この二つは、分けて考えられます。合計や前月比は、決めた手順で出す。その結果をどう読むかを、AIと一緒に考える。

ある広告運用エージェントの事例では、決まった計算をコードに移し、不要なAIの呼び出しを減らしたところ、処理が18分から85秒に縮みました。^［1］

この記事では、自分の作業のどこに線を引けばよいかという見方と、一つの工程から試し、結果を確かめる手順をお渡しします。

決まった処理はコードに、解釈や提案はAIに

AIに仕事を任せるとき、どこまでをAIに任せ、どこからを別の仕組みにするのか。

私は、次のように分けて考えています。

決めたルールどおりに繰り返す仕事は、コードに。状況を読み、解釈や提案を組み立てる仕事は、AIに。その提案を採用し、実行するかは、人が決めます。

ここでいう「決まった処理」には、足し算や増減率だけでなく、比較する期間をそろえる、決めた条件で分類する、数字を照合する、といった作業も含みます。

繰り返し行う集計や、ルールが決まっている分類ほど、この切り分けを試す価値があります。三つの役割を、仕事の受け渡し順に示します。

この分け方では、コードが出した結果をAIへ渡し、AIの提案を人が引き受けるかどうかを決めます。速さだけでなく、どこを確かめればよいかも見えやすくなります。

計算を切り出すと、AIが読むものも、考えることも変わりました

LangChainという会社が、自社の広告運用のために作ったエージェントの話です。Google AdsやMeta Adsなど、複数の広告媒体の成績を毎週まとめ、社内のチャットツールであるSlackで質問にも答えます。公式記事と、プログラムや設計が公開されているリポジトリを確認しました。^{［1］［2］}

初期版は、モデルがキャンペーン、キーワード、商談の明細を読み込み、支出の合計や週ごとの比較まで、モデル自身が計算していました。

同社の記事によれば、固定したテストデータで測ったところ、1回のレポート処理で約390万の入力トークンを消費しました。これは、AIが読み込む情報の処理量を数えたものです。実行時間は1,112秒、約18分。費用は3ドルを少し超えていたそうです。^［1］

改善後は、コードがデータを取得し、比較する期間をそろえ、合計と増減を計算し、固定のルールを適用するようにしました。モデルが担うのは、その結果から証拠をつなぎ合わせ、変化の理由を考え、次の施策を提案する仕事です。あわせて、不要なAIの呼び出しも減らしています。^［1］

渡すのは、数字だけではありません。公開リポジトリには、集計結果とともに、出典・対象期間・データの不足など、解釈に必要な前提もモデルへ渡すと書かれています。^［2］

同社は、こうした改善によって、初期のレポート処理が約13倍の速さになり、費用は約40分の1になったと報告しています。実行時間は、18分から85秒へ縮みました。^［1］

私が注目したのは、モデルの性能の高さよりも、仕事の分け方です。

AIが毎回考え直さなくてよい仕事を、先に切り出した。

その分、AIは結果を読み、意味を考える仕事に集中できるようになった。私は、この設計の変化に意味があると思いました。

できることと、向いていることは、別です

私は前の仕事で、製造業向けの3Dプリンタ事業に携わっていました。

3Dプリンタの強みとして現場で見ていたのは、自由な形状の一点物を作れることでした。ただ、私が担当していた量産の案件では、精度・再現性・単価を求めると、金型を起こした射出成形のほうが適していました。

一時期は「3Dプリンタが製造業を置き換える」というような語られ方もしていましたが、私が見ていた現場で進んだのは、置き換えというより、住み分けでした。

自由に対応できる道具と、決めたものを繰り返し作る仕組みは、使いどころが違う。

いま、AIエージェントの周りで起きていることも、同じ構造に見えます。

言葉や文脈のあいまいさを読み解き、その場の状況を解釈するところには、AIを使う。決まった手順で集計し、同じ条件を繰り返し適用するところには、コードを使う。どちらか一方に全部を任せるより、仕事に合わせて分けるほうが自然です。

もう一つ、製造業の経験から重ねられることがあります。

金型は、人が一度、時間をかけて設計し、あとは機械がその型どおりに動きます。今回の事例も、計算のロジックや固定のルールを先にコードへ置き、その結果をどう読むかを、AIに考えさせていました。

AIに全部任せることの反対は、AIを使わないことではありません。先に、型を作ることです。

以前、「新型AIは、カタログではなくテストベンチで選ぶ」という記事で、モデルを上げる前に、指示に欠けている前提を補うことについて書きました。

あのときは、指示の話でした。今回は、仕事の分け方の話です。「先に整える」という、根っこにある考え方は同じだと思っています。

私自身も、月次レポートで同じ分け方をしています

顧客向けの月次動向レポートでは、資料を集め、採用し、分類する部分を、AIのその場の判断に任せていません。

どの項目を採用するか、どのテーマに置くかは、あらかじめ決めた条件に従って処理しています。そのつど判断を挟まないので、保存してある同じ元データに、同じルールを適用すれば、採用項目・分類・集計結果を再現できます。

AIが文章の解釈や構成を担うのは、その先です。

全体を通した要点と、各テーマの実務への示唆を、AIの下書きと私自身の手で書きます。このとき、AIには集計結果だけでなく、対象期間・出典・データの抜けの有無といった、解釈に必要な前提もあわせて渡しています。

出来上がったレポートは、コードで元データと出力の項目を突き合わせます。件数が合っているか。採用した項目が、出力にもすべて残っているか。内部でだけ使う用語が紛れ込んでいないか。

最後に、私自身が読みます。内容が正確か、解釈に無理がないか、自分の言葉として自然に伝わるかを確認します。

集める・数える・照合する部分を、決めたルールで処理しているからこそ、私は顧客に、その部分には「再現性がある」と言えます。

そのうえで、何を要点として伝え、どんな示唆を添えるかは、私が確認して仕上げます。同じものを再現する仕事と、その意味を考えて伝える仕事を、分けているということです。

まず一度試すなら

仕組み全体を、いきなり作り直す必要はありません。次の一件だけで試せます。

1. いまAIにまとめて任せている作業を、一つ選びます。
   毎月の報告書や、週次の集計など、繰り返しているものが選びやすいと思います。
2. その作業の工程を、紙に書き出します。
   資料を集める、期間をそろえる、合計する、前月と比べる、変化を解釈する、文章にする、といった単位に分けます。
3. 各工程に印をつけます。
   「決めたルールどおりに繰り返せる」なら計算。「文脈を読んで解釈や提案を組み立てる」なら判断。ここでいう計算には、固定のルールによる分類や照合も含めます。
4. 「計算」の工程を一つだけ、コードか表計算の関数に置き換えます。
   プログラムが書けなくても、入力するデータと欲しい計算結果を示して、AIに道具を作らせる方法があります。毎回計算させるのではなく、繰り返し使う式やプログラムを作ってもらう、という頼み方です。
5. AIには、計算結果と、その前提を渡します。
   対象期間や出典、データの抜けなどを添えて、解釈や提案を書かせます。提案を採用するかどうかは、自分で確認して決めます。

確認するのは、次の三つです。

まず、あらかじめ答えが分かっている小さなデータで、計算が正しいかを確かめます。同じ入力から、同じ数字が出ることも確認します。同じ答えが出ることだけでなく、その答えが合っていることを見るためです。

次に、AIが書いた文章の数字・単位・増減の向きが、計算結果と一致しているかを確認します。計算表が「20％増」でも、文章に「20％減」と書かれていたら、そのままでは使えません。

最後に、必要な考察や提案が抜けていないことを確かめたうえで、置き換える前と後の時間・費用を比べます。 AIへ渡す情報量がどう変わったかも見ます。速くなっても、必要な内容が失われていたら、分け方を見直します。

一つの工程を切り出し、計算と文章を照合し、負担がどう変わったかを確かめる。ここまでなら、次の報告書から試せます。

もう少し詳しく知りたい方へ——担当の範囲と、終わり方も決める

LangChainの公式記事には、計算の分担以外にも、設計を見直して改善した例が書かれています。

一つは、保存先の衝突です。

媒体ごとに作業を分担する二つのサブエージェントが、同じ場所へレポートを書き込み、同じ「完了」の印を共有していました。片方が先に終わると、もう片方がその状態を自分の完了と誤認し、レポートを作らないまま止まることがあったそうです。

修正は、媒体ごとに保存先と完了状態を分けることでした。^［1］

もう一つは、確認を終えられず、処理を繰り返す問題です。

あるサブエージェントは、自分が作ったPDFの生成に成功したかを判断できず、ファイルを確認し続けて、大量のトークンを消費しました。最後には、PDFを一から作り直そうとしたそうです。

修正後は、渡すツールを「資料を読む・計算する・PDFを生成する」の三つに絞り、PDF生成の処理が成功した時点で、その担当の仕事を完了とするようにしました。^［1］

何を任せるかだけでなく、どこに結果を置き、何をもって終わりとするかまで、先に決める。

私は、この二つも、仕事の分け方の話として読みました。

外部への変更にも、区切りがあります。広告設定の変更案は、Slackの承認画面に現在値と変更案を並べて表示します。権限のある人が内容を確認・編集して承認したあとに、コードが変更を適用し、反映されたかを確認する流れです。^［1］

分析して提案するところまでと、その提案を実行するところ。ここも、一続きの「AIにおまかせ」にはしていません。

適用範囲と、確かめていないこと

LangChainの実行時間・トークン数・費用は、同社が自社の環境で計測し、報告したものです。私が同じ仕組みを動かして、再現した数字ではありません。

私自身の実例は、一種類の月次レポート作業での話です。複数のエージェントを並列で動かす仕組みは、まだ運用していません。

また、分類のように、計算と判断の境目がはっきりしない工程もあります。私が行っているのは、まず固定のルールで分け、そこから外れたものを人が見る、という順番です。

分類という名前だからコードに任せるのではなく、その分類の条件を、先に決められるかを見る。境目が見えにくいときは、そこから確かめると、任せられる範囲が見えてきます。

いまAIに任せている作業で、決まった手順で処理できる部分と、考える必要がある部分は、分かれていますか。

分かれていないなら、一つの集計から切り出してみる。その前後を比べると、どこに時間がかかっていたのか、何をAIと考えたいのかが、少し見えやすくなると思います。

自分の仕事のどこにその線を引けばよいか。QAIラウンドテーブルでは、工程を一緒に書き出し、計算と判断を仕分けるところからご一緒できます。