推論コストは2年で激減｜それでもAI活用がうまくいかない会社の共通点【編集部考察】

AIツールはいくつも契約した。社員に聞けば「使っています」と返ってくる。なのに、仕事の進め方も、月次の数字も、1年前とほとんど変わっていない。

AI導入を進めてきた中小企業の経営者やDX（デジタルトランスフォーメーション）推進担当の方から、「活用がうまくいかない」という声をよく聞きます。

その一方で、AIを動かす推論コスト（AIが答えを1つ返すたびにかかる計算費用）は、この2年で激減しました。スタンフォード大学の調査によれば、その下げ幅は280分の1以下。「高いから使わない」という言い訳は、もう通用しません。ではなぜ、安く賢くなったAIが、成果に結びつかないのか。

本記事では、この推論コストの急落を入口に、価格でも性能でもない、成果を分けるもう1つの要素、「何を、どう任せるか」という使い手側の設計について考えます。

AIは、この2年で驚くほど安くなった

スタンフォード大学の研究機関HAIが公表している『AI Index 2025』という報告書に、よく引用される数字があります。ある知識テスト（MMLU）でGPT-3.5と同じ水準の成績を出すAIに問い合わせるコストが、2022年11月には100万トークンあたり約20ドルだったものが、2024年10月には約0.07ドルまで下がった、というものです。

およそ18ヶ月で、280分の1以上の低コスト化。処理する内容によって幅はありますが、AIの利用価格は、タスクによって年に9倍から900倍というペースで下がってきた、とも報告されています。

こうした値下がりの背景には、AIが動くしくみ自体の変化があります。対話型AIは、手元のパソコンではなく、事業者のデータセンターに置かれた大量のコンピューターで動いています。そのコンピューターを支える半導体のコストは年3割ほど下がり、消費電力あたりの処理能力は年4割ほど改善してきました。

加えて、少ない計算量で同じ仕事をこなせる小型のAIモデルが次々に登場したことも大きく関わっています。つまり、

これが価格急落の中身です。

安くなったこと自体は、歓迎すべき変化です。かつては費用対効果が見えずに見送っていた使い方も、いまは気軽に試せます。ただし問題は、その「気軽さ」が何を生んだか、です。

出典・参照：

• Research and Development｜The 2025 AI Index Report｜Stanford HAI

安くなって、いちばん増えたもの

この章では、コストの急落が企業の現場にもたらした、あまり語られない変化を指摘します。

価格が下がると、導入のハードルも下がります。「これだけ安いなら、とりあえず試してみよう」という判断がしやすくなる。ここまでは、よいことのように見えます。

しかし、多くの企業の現場で実際に増えたのは、成果ではなく、目的のあいまいなツールとアカウントでした。部署ごとに別々のAIサービスを契約し、担当者が個人で使い始めたぶんも足していくと、自社が何のAIをいくつ使っているのかを正確に説明できる人は、社内を見渡してもなかなか見つかりません。契約だけは済ませたのに、ほとんどログインされていないアカウントもたくさん生まれてしまいました。「安いから試す」という姿勢は、「試したまま放置する」という結果と、つねに背中合わせになってしまったのです。

注目したいのは、これは特定の企業の失敗談ではなく、どの企業でもよく見かける光景だ、ということです。ツールが安く手に入るほど、1つひとつを「何のために使うのか」と吟味する動機は弱くなります。

増えたツールの数は、AI活用が進んだ証拠にはなりません。むしろ、「安いから」以外の導入理由を説明できるツールが、どれだけあるか。そこが問われているのです。

価格が動いても、変わらない問い

AIが安くなっても、賢くなっても、変わらないことがあります。それは、「自社の業務のどこを、どこまでAIに任せるか」という判断です。

この判断には、いくつかの要素が含まれます。

これらは、モデルが新しくなっても自動的には決まりません。むしろ、選択肢が増えたぶん、決めることは難しくなっています。

下がったのは道具の値段であって、この設計にかかる、現場の業務を理解し、任せ方を決め、検証のしくみを作る手間は下がっていません。AI活用が停滞している企業は、「ツールが足りない」のではなく、この設計をしないまま、ツールだけを増やしているケースが少なくありません。

裏を返せば、設計さえできていれば、使うモデルが多少変わっても成果は揺らぎにくいということです。設計は、価格競争や性能競争の外にある、自社で持つべき資産なのです。

「相談しているだけ」は、使っていることになるのか

前章で見た「任せ方の設計」を日々のAIの使い方に置き換えると、いま自社は「相談」と「委任」のどちらに寄っているか、という問いになります。この2つは画面の前では似た操作に見えますが、組織の成果に効くかどうかという点では、まるで別物です。両者を切り分けて考えられるかどうかが、AI活用を個人の便利ツールで終わらせるか、業務の一部として根づかせるかを分けます。

「相談」は、便利でも個人の時短で終わりやすい

対話型AIに質問し、メールの下書きを作らせ、企画のたたき台を壁打ちする。こうした使い方は確かに便利で、多くの人の作業時間を実際に縮めています。ただ、その成果はほとんどの場合、使った本人の手元にとどまります。うまくいったプロンプトはその人のチャット履歴に眠ったままで、隣の同僚はまた一から同じ工夫をやり直し、担当者が異動すれば積み上げた勘どころも引き継がれずに消えます。

相談型の利用は、いわば「社員がそれぞれ優秀な外部アドバイザーを個人契約している」状態です。一人ひとりの生産性は上がっても、その上がり幅は業務の仕組みには残りません。だから、社員に聞けば全員が「AIを使っている」と答えるのに、部門の業務フローも月次の処理件数も去年と変わらない、という現象が起こります。個々の忙しさは増えているのに、成果の形は動いていないのです。

「委任」は、業務プロセスにAIの持ち場をつくること

もう一方の委任は、特定の業務プロセスの中に、AIの担当区間をはっきり決めて組み込むことです。どの入力を受け取り、何を出力し、その結果を誰がどう確認して次の工程へ渡すのか。そこまで決めて初めて、AIは「個人の相棒」から「業務の一部」に変わります。

委任の状態になっていれば、担当者が誰であっても処理は同じように流れます。ベテランが休んでも新人が入っても、AIの持ち場の品質はおおむね一定に保たれます。委任になじみやすいのは、判断の幅が狭く、繰り返し発生する区間です。

いずれも、AIが下ごしらえをして、最終的な判断と責任は人が引き取る形になります。この線引きこそが、前章で述べた「使い手側の設計」の具体的な中身です。相談の便利さがその場かぎりの「掛け捨て」だとすれば、委任の設計は成果が仕組みに残る「積立」だと言えます。

相談から委任へ、線をどこで越えるか

では、相談が中心のいまの状態から、委任へはどう進めればよいのでしょうか。手順そのものは、派手ではありません。

はじめに、いま社内で行われているAIの使い方を一度書き出し、それぞれを「相談」と「委任」に仕分けてみてください。多くの会社では、その大半が「相談」に入るはずです。まず、この偏りに気づくことが出発点になります。

次に、相談の中から委任へ引き上げる業務を1つだけ選びます。失敗しても影響が小さく、しかも繰り返し発生する業務がよいでしょう。選んだら、作業の手順を書き出し、AIに任せる範囲と人が確認する箇所を決め、間違いが出たときに誰が気づけるのかまで詰めていきます。

多くの現場は、この地味な工程を飛ばして「もっと賢いAIが出れば解決する」と考えます。しかし、相談を100回積み重ねても、それが委任に変わることはありません。両者を隔てているのは性能の差ではなく、設計があるかないかです。実際、委任まで進めた業務を1つでも持っている会社は、AIをめぐる社内の話題が「どのツールがよいか」から「どこを任せるか」へと移っていきます。

まとめ：安くなったのは道具、設計は自分でやる

AIの利用コストがこの2年で280分の1以下に下がったことで、企業がAIを使い始めるときの金銭的なハードルは、ほぼ消えました。もう、価格を理由にAIを避ける必要はありません。しかし、誰でもAIを試せるようになったことと、そのAIで実際に成果を出せることは、まったく別の話です。

成果を分けているのは、どのモデルを選ぶかでも、いくつツールを契約するかでもなく、「業務のどこを、どこまで、どう任せるか」という使い手側の設計です。そして、その設計にかかる手間だけは、いくら技術が進んでも安くなりません。

いまのAIは、どの主要モデルもすでに十分に賢く、十分に安くなっています。「このモデルを選んだ会社は成果を出し、あのモデルの会社は出せない」という性能差は、実務ではもう成果を左右しません。

だとすれば、いくつものAIを次々に乗り換えて試すよりも、使うモデルを1つに決めてしまい、空いた労力を任せ方の設計へ回すほうが賢明です。設計できた業務が1つでもあれば、そこを起点に仕事のやり方は確実に変わります。私がDX導入の現場で見てきた会社でも、成果の差を分けていたのはモデル選びではなく、この設計に手をつけたかどうかでした。

自社のAI利用を、あなたは「相談」として設計しましたか。それとも「委任」として設計しましたか。もしどちらとも答えられないなら、次に増やすべきものは、ツールではなく、その設計に充てる時間なのかもしれません。