基幹業務をAIエージェントに任せると何が起きるか｜従量課金の構造と正しい住み分け

スタートアップ界隈を見ていると、AIエージェントに業務を丸ごと任せる構想に飛びついている会社がいくつもあります。受注も、進捗管理も、請求も、AIが自律的に処理してくれる未来。魅力的に聞こえますし、技術的には一部すでに可能です。一方で、中小企業の現場からは、まだこの質問すら出てきません。だからこそ、検討が始まる前に書いておきたいことがあります。

先に立場を明かしておくと、私はAI否定派ではありません。むしろ当社（OneTrace)の業務システム開発は、AIをフルに活用することで成立しています。その当事者として言いたいのは、AIを使うか使わないかではなく、どこで使うかを間違えると、コスト構造ごと破綻し得る、ということです。この記事では、基幹業務の実行をAIエージェントに任せた場合に何が起きるかを、原価の構造から整理します。

「AIで開発する」と「AIが業務を実行する」は、別物です

まず、よく混同される2つを分けます。ひとつは、AIを使って業務システムを開発すること。データベースも画面も権限管理も普通のシステムとして作られ、AIのコストが掛かるのは開発時だけです。完成したシステムの運用に、AIの従量課金は基本的に発生しません。もうひとつは、業務の実行そのものをAIエージェントに任せること。受注のたび、ステータス更新のたび、請求のたびに、AIが考えて、データを参照して、判断して、処理する設計です。この場合、業務量に比例してAIの利用料が発生し続けます。

前者は安全寄り、後者は危険寄りです。世の中の「AIで業務自動化」という言葉は、この2つを区別せずに使われていることが多い。以降で問題にするのは後者、つまりAIエージェントを基幹業務のランタイムにする設計です。

原価構造の違い：DB処理はほぼゼロ円、AI推論は1件ごとに課金

通常の業務システムで「受注を1件登録する」という処理は、データベースへの書き込みと画面の操作で完結します。1件あたりの追加コストは事実上ゼロに近く、サーバー費用という固定費に吸収されます。1,000件処理しても10,000件処理しても、月のインフラコストはほぼ変わりません。これが、業務システムが「作ってしまえば安い」理由です。

AIエージェントに同じ処理をさせると、様子が変わります。エージェントは1件の処理のために、依頼内容を読み、過去の履歴やマスタを参照し、判断し、ツールを実行し、結果を確認します。この一つひとつがAIモデルへの呼び出しで、呼び出すたびにトークン単位の従量課金が発生する。主要なAI各社のAPIは、100万トークンあたり数ドルという単価で、入力にも出力にも課金されます。つまり、処理件数が増えるほど、そして1件あたりにAIが「考える」回数が増えるほど、費用が業務量に比例して積み上がる構造です。

思考実験：ドライバー10人の運送会社で試算する

具体的な規模感を掴むために、思考実験をします。ドライバー10人の運送会社で、受注、配車、運行指示、日報、納品確認、請求、ステータス更新といった基幹業務のイベントが、月に3,000回発生すると仮定します（1日あたり約140回。実際の件数は会社によって大きく異なるので、あくまで計算のための仮置きです）。この3,000回をすべてAIエージェントが実行する場合の、AI利用料だけを概算します。

単価には、執筆時点（2026年7月）で公表されている主要モデルの正式価格の一例として、入力100万トークンあたり3ドル・出力100万トークンあたり15ドル、為替は1ドル160円を置きます。1件の処理でAIが読む・書く量は設計によってまったく違うので、3つのパターンに分けます。

これはAIモデルの利用料だけの数字です。実際にはツール実行やログ、監視、エラー対応、開発保守の費用が乗り、サービスとして買うならさらに提供会社の利益が乗ります。逆方向では、プロンプトのキャッシュ割引や軽量モデルの選択で、数分の一まで下がる余地もあります。ただ、どれだけ最適化しても、ほぼゼロ円のDB処理との桁の差は埋まりません。注目してほしいのは金額そのものより、幅です。同じ「月3,000件」でも、AIにどこまで考えさせるかで月1.6万円と月81万円に分かれる。そして基幹業務をエージェントに丸ごと任せる設計は、必然的に表の下段に寄っていきます。1件の処理で何回AIが呼ばれるかは、リトライや例外で毎回ブレるため、月末まで正確な請求額が読めない。基幹業務に一番求められる「コストの予測可能性」が、構造的に手に入らないんです。もう一つ付け加えると、月81万円という数字は、事務スタッフの人件費一人分を優に超える水準です。省人化のために入れたAIが、人より高くつく。この逆転は、重い設計では普通に起こり得ます。

単価は、AI提供側が決める

もう一つの構造的なリスクは、単価の決定権が自社にないことです。これは仮定の話ではありません。執筆時点の直近でも、ある主要モデルは発表と同時に「導入価格は8月末まで、9月からは入力・出力とも5割高い正式価格に移行する」という日程を公表しています。さらに同モデルはトークンの数え方（トークナイザー）も新しくなり、同じ文章を処理するのに必要なトークン数が従来より約3割増えるケースがあるとされています。単価が上がり、消費量も増える。どちらも利用者側ではコントロールできません。

通常の業務システムなら、一度作った処理のコストが翌月から勝手に5割上がることはありません。しかし基幹業務のランタイムをAIに置いた会社は、AI提供側の価格改定が、そのまま自社の基幹業務の運営コストに直結します。事務員の人件費を削減するためにAIエージェントを入れたのに、単価改定と利用量の増加で、気づけば事務員数人分のコストを毎月AIに払っていた──この筋書きは、十分に起こり得ます。

ここで、逆方向の反論にも先回りしておきます。AIの単価は長期的には下がり続けており、いずれ推論コストは無視できるほど安くなる、という見方です。単価の下落トレンド自体は事実です。ただ、これは3つの理由で安心材料になりません。第一に、単価が下がっても、業務量に比例して課金され、金額が読めず、価格の決定権が外部にあるという構造は変わりません。第二に、実際の請求額は単価×消費量で決まり、モデルが高性能になるほど1タスクで読む量・考える量は増える傾向にあります。単価の下落を消費量の増加が食っていく構図は、先ほどのトークナイザーの件がそのまま示しています。第三に、もし本当に数年で劇的に安くなるのなら、なおさら、高いコストの今あえて基幹業務をエージェント化する理由がありません。安くなってから移行しても遅くないわけで、「将来安くなる」は今日の導入の根拠にはならないんです。

従量課金の外側にも、見えないコストがある

ここまで書いてきたのは、AIモデルの利用料、つまり従量課金の話です。ただ、エージェント導入の総コストを考えるなら、見積書に載りにくい費用が利用料の外側に少なくとも4つあります。

まず、接続の開発コスト。AIエージェントが仕事をするには、受注データ、顧客マスタ、請求情報といった自社のデータやシステムに接続できなければなりません。何を読ませ、何を触らせ、どこまでの権限を渡すか。この接続層の設計と開発には、普通のシステム開発と同じか、それ以上の工数がかかります。「エージェントを入れれば開発は要らなくなる」のではなく、エージェントを働かせるための開発が必要になる、というのが実態です。

次に、面倒を見続けるコスト。エージェントの挙動はプロンプトや設定の調整で変わり続けるので、期待通りに動かない箇所の調整、失敗の監視、ログの確認という運用が、導入後もずっと続きます。さらに見落とされがちなのが、モデルの世代交代です。AIモデルは数年単位で古いものが提供終了になり、新しいモデルに切り替えたとき、前とまったく同じ挙動をする保証はありません。切り替えのたびに、業務が正しく回るかの検証をやり直すことになる。前の章の話とつながりますが、単価だけでなく、モデルの寿命も提供側が決めるんです。

そして、データを整えるコスト。エージェントは、散らばったExcelや紙、担当者の頭の中にある情報のままでは働けません。AIに業務を任せる前提として、データが整理され、参照できる状態になっている必要があります。この話はAIにデータ集計を任せる前に整えておくべきことで詳しく書いた通りで、実はここが、中小企業にとって一番高いハードルです。

最後に、権限と安全の設計コスト。実行権限を持ったAIが誤操作したとき、影響はどこまで及ぶのか。誰の指示で何をしたかの操作ログをどう残すのか。業務データを外部のAIサービスに送ることについて、顧客や取引先にどう説明するのか。基幹業務に近づくほど、この設計は省略できません。これらは、AIエージェントが悪いという話ではありません。「利用料の従量課金」だけを見て導入判断をすると総コストを見誤る、という話です。通常のシステム開発で当たり前にやってきた設計・運用・保守が、エージェントでも別の形で必要になる。開発がゼロになるわけではないんです。

私はAIで開発している。それでも実行系をAIにしない理由

ここで、当社自身の作り方を正直に書きます。OneTraceの開発では、AIをフルに使っています。ただし役割は明確に分けています。クライアントへの課題ヒアリング、その会社の方向性や思想との擦り合わせ、要件定義は、人間が行います。仕様も基本的には人間が考え、迷うところはAIと壁打ちした上で、そのクライアントにとってベストな仕様を人間が最終判断する。そして、その仕様を実装するコードは、人間の具体的な指示のもとでAIが書きます。

つまり、考える工程ではAIを相棒として使い倒し、決める責任は人間が持ち、手を動かす工程はAIに任せる。この分業で、開発の速度とコストは劇的に変わりました。月額3万円からのフルオーダーメイドという当社の価格は、この作り方だから成立しています。

それでも、納品するシステムそのものは、従来型のデータベースと画面で作ります。運用にAIを組み込みすぎない。理由は、ここまで書いてきた通りです。基幹業務に必要なのは、同じ入力なら同じ結果が返る再現性、誰がいつ何をしたか追える監査性、そして来月の運用コストが読める固定性。決まりきった処理をAIに毎回考えさせることは、この3つを全部手放して、本来ほぼゼロ円のDB更新に推論コストを払い続けることを意味します。AIの使いどころとして、筋が悪い。この考え方は【第7回】AI時代に「責任を取れる人」の価値が上がる理由で書いた内容とも地続きです。

住み分け：基幹は専用システム、AIは補助層

AIを使わないという話ではありません。使う場所を選ぶという話です。整理すると、こうなります。

実務の感覚で言えば、中小企業に必要なAIは、業務を勝手に実行するエージェントではなく、システムに溜まったデータを前提に「今月の未請求案件をまとめて」「この顧客への督促文を書いて」と頼めるチャット型の補助で、ほとんど足ります。コスト面でも、チャット型の補助は費用が読めます。既製のAIチャットサービスを使うなら1人あたり月額数千円の固定料金ですし、自社のシステムにチャット機能を組み込む場合でも、AIが動くのは人が話しかけたときだけで、業務イベントの件数に紐づいて自動で回ることはありません。月額固定か、固定に近い小さな変動か。件数に比例して金額がブレるエージェント実行とは、費用の構造がまるで違います。土台となる業務の流れが専用システムで整っていれば、AIはその上で安全に働けます。逆に、業務の流れが整理されていない状態でAIエージェントだけ入れても、AIは会社ごとの例外だらけの運用を毎回推論で埋めることになり、コストと不安定さだけが膨らみます。工程単位でどこがAIに向くかの各論は、見積や受発注のAI自動化が、思ったほど楽にならない理由で書いています。

それでも、エージェントが向く場面はある

公平のために書いておくと、AIエージェントが合理的な場面もあります。件数が少なく、1件あたりの価値が大きく、手順が毎回違う探索的な仕事。たとえば市場調査、競合分析、複雑な資料の突き合わせのような業務です。月に数十回しか走らせないなら、1回数百円の推論コストは安い。さらに、実行結果を必ず人が確認するステップを挟み、月あたりの利用上限を設計できるなら、リスクは管理可能です。危ないのは件数の多い定型処理、つまり基幹業務そのものをエージェント化することであって、エージェントという技術自体ではありません。

AIエージェントのブームには、「AIが考えて処理してくれる」ことの魅力が先行して、基幹業務に本当に必要な再現性・監査性・コストの固定性が後回しになっている面があります。順番はこうです。まず業務の流れを専用システムで整える。その土台の上で、AIが本当に効く場所──要約、文面、検索、例外の下調べ──にだけAIを置く。AIに業務を丸投げするのではなく、AIを使う場所を間違えないこと。それが、AIで開発している当事者としての結論です。