「AIを使う」から、「AIを使い続ける」へ① | 問われるコストの設計
*AI駆動開発 **自社の知見·技術*
AIを開発の現場で使い続けるために、今考えるべきこと
AI活用における、新たな課題
AIを開発現場で使うこと自体は、もう珍しくなくなりました。CursorやClaude Code、GitHub Copilotを日常的に使うチームもあれば、Agentを自社で組み、要件整理や実装、テスト、ドキュメント作成まで任せ始めている会社もあります。
少なくとも、「AIは実務で使えるのか」という議論は終わりつつあります。便利ですし、うまく使えば開発のスピードも変わる。私たち自身、そう感じています。
一方で、利用がPoCを越えて日常業務に入ってくると、別の問題が見えてきます。
「これを使い続けたら、いくらかかるのだろう？」
PoCの段階では、それほど気にならなかったかもしれません。
利用者も限られ、期間も短いからです。
しかし、対象プロジェクトが増え、複数のAgentが並列で動き、毎日のようにモデルを呼び出すようになると、AIの利用料は「試行のための費用」ではなく、継続的な運用コストになります。
ここで考えたいのは、「AIは高いから使わない」という話ではありません。便利で、使えるからこそ、企業として無理なく使い続ける方法を考える必要が出てきた、ということです。
AIのコスト、見えていますか？
たとえば、一件の要件整理をAgentに任せたとします。最終的には、きれいな成果物が一つ返ってきます。
では、その成果物を作るまでに、Agentはモデルを何回呼び出したでしょうか。何回調べ直し、何回やり直したでしょうか。そのうち、最終成果に結びつかなかった試行はどの程度あったでしょうか。
企業の実行基盤上で複数のAgentが動くようになると、この「途中で何が起きたか」がコストを左右します。ところが実際の管理では、最後に「今月のAI利用料は○○万円でした」と合計額だけが見えていることも少なくありません。
これでは、金額が増えた理由が分かりません。
利用者が増えたのか？
特定の工程で再実行が増えたのか？
特定のメンバーやAgentに利用が偏ったのか？
必要以上に高性能なモデルを使っていたのか？
月次の請求を見て「少し増えた」と感じているうちに、四半期で集計すると予算枠を超えていた。AIの利用が広がると、こうしたことが起こり得ます。問題は金額が増えたことだけではありません。なぜ増えたのかを説明できなければ、次の四半期の予算も組みにくいことです。
請求額は見えていても、コストの構造は見えていない。AIの利用が広がるほど、この差は大きくなります。
高性能なモデルを使えばよい、でもない
コストを考えると、「では安いモデルを使えばいい」という話になりがちです。しかし、これも単純ではありません。
要件の矛盾を見つけたり、設計をレビューしたりする仕事では、推論の精度が重要です。ここで価格だけを理由にモデルを落とし、手戻りが増えれば、結果として総コストが上がることもあります。
一方、コードの整形や定型的なドキュメント作成まで、常に最上位モデルで処理する必要があるのか？という疑問もあります。
つまり、モデルの価格だけを比べても答えは出ません。どの仕事に、どの程度の能力を持つモデルを使うか。その組み合わせを考える必要があります。
難しいのは、一度「全部、最新の高性能モデルで」という運用が定着すると、あとから見直しにくくなることです。「高いモデルだから品質が保たれている」という理解が組織内にできてしまえば、軽量モデルへの切り替えは単なる技術判断ではなくなります。
AIの経済性は、調達価格の問題というより、使い方の設計に近いのです。
従来のIT予算と違うところ
もう一つ厄介なのは、AIには「動くほど費用が増える」という性質があることです。
Agentが動けばモデル呼び出しが発生する。利用者が増えれば実行回数も増える。プロンプトや参照する文書が長くなればトークンも増える。モデルの価格改定や切り替えもあります。
月次の利用料を積み上げれば、四半期ではどの程度になるのか。その実績をもとに次年度の予算や3年TCOをどう見積もるのか。発注側にも受託側にも、これまでとは違う難しさがあります。
「AIを導入するのにいくらかかるか」だけでは足りません。「使われるようになったとき、いくらかかるか」まで考えなければ、運用予算は組みにくくなります。
FinOpsを後から足しても、できることは限られる
コストが気になり始めると、まず利用量を可視化したくなります。トークン数、APIの実行回数、モデル別の利用額、ユーザー別の内訳。こうした数字を見ることは必要です。
ただ、数字が見えることと、コストを設計できることは同じではありません。
なぜなら、AIのコストのかなりの部分は、その前に行った設計判断から生まれているからです。
どのタスクにどのモデルを使うのか。
どこで人が確認するのか。
Agentにどこまで自律的に動かせるのか。
どの程度の知識を事前に与えるのか。
どこまでログを残すのか。
これらを決めれば、モデルの呼び出し回数やトークン量、再実行の回数、並列実行の規模も変わります。設計をそのままにして、後からダッシュボードだけを追加しても、「高いことは分かった。では何を変えるのか」というところで止まってしまいます。
だからAIのFinOpsは、利用料を後から削る活動だけでは足りません。AIをどう使うかを決める段階から、コストを一つの設計条件として入れておく必要があります。
補足：FinOpsとは？
FinOps（Financial Operations）は、クラウドなどのITコストを可視化し、技術・財務・事業の関係者が協力しながら、コストと事業価値のバランスを継続的に改善していく考え方です。
AIでも、モデル利用料やトークン消費量を把握し、無駄な利用を減らすという考え方が広がっています。ただ、本稿でいう「AI FinOps」は、そこからもう一歩踏み込みます。
使った後にコストを見るだけではなく、AIをどう使えば経済的に運用できるのかを、最初から設計する。モデルの選び方やAgentの動かし方、人が介入する場所まで含めて考える。それが、ここでいうAI FinOpsです。
品質、安全、統制、継続性。そして経済性
企業でAI Agentを運用するとき、これまでは品質、安全、統制、継続性といった観点が重視されてきました。どれも欠かせません。
ただ、本格運用に入るなら、ここに「経済性」も加えるべきだと考えています。
経済性とは、単に安くすることではありません。必要な品質を保ち、安全や統制を損なわず、運用を続けられる範囲で、投入するコストと得られる価値を成立させることです。
品質を上げるために常に高性能なモデルを使えば、コストは上がります。承認を増やせば安全性や統制は高まりますが、人の時間がかかります。コストだけを切り詰めれば、品質や継続性にしわ寄せが出るかもしれません。
どれか一つを最大化するのではなく、案件や工程に応じてバランスを取る。私たちは、この経済性まで含めてAI運用を設計する考え方を、広い意味での「AI FinOps」と捉えています。
前々回のInsightで扱った可再現性・可監査性・可説明性・可換性・可継承性も、知識や設定を整備して初めて成立します。経済性も同じで、運用が始まってから付け足すのではなく、設計の中に置く必要があります。
「使い続けられるAI」を、仕組みとして支える
ここまでのことを、現場の努力だけで続けるのは簡単ではありません。
どのAgentが、どのモデルを使い、どのくらいコストを使ったのか。仕事の内容に応じてモデルを使い分けられるか。必要なところでは人が確認し、それ以外はAgentに任せられるか。そして、品質だけでなくコストの変化にも早く気づけるか。
こうしたことが、AIを動かす仕組みの中で自然にできることが重要だと私たちは考えています。
私たちが開発しているLight Forgeも、まさにその考え方から作っています。単に「AIを動かすための基盤」ではなく、企業がAIを無理なく使い続けるための基盤にする。
利用状況やコストが見え、仕事に合わせてモデルを選べ、人とAIの役割分担を調整できる。AIの利用が広がっても、品質とコストの両方を見ながら運用を変えていける。そういう仕組みがあれば、AI FinOpsは月末の集計作業ではなく、日々の運用そのものになります。
AIが便利であることは、もう分かっています。これから企業に必要になるのは、その便利さを一時的なものにせず、経営的にも持続できる形にすることではないでしょうか。
次回：AIのコストを、どこで設計するのか
では、実際には何を設計すればよいのでしょうか。
次回は、モデルの選択、自律度と人の介入、Agentの並列実行、知識基盤への投資という四つの論点から、品質を落とさずに経済性を成立させる方法を考えます。
会社概要
会社名：株式会社イー・ビジネス
所在地：〒105-6405 東京都港区虎ノ門1丁目17番1号 虎ノ門ヒルズビジネスタワー5階
設立：2007年6月12日
社員数：333名（2026年2月現在）
コーポレートサイト：https://www.e-business.co.jp/
