「AIを使う」から、「AIを使い続ける」へ③ | AI FinOpsを、経営と運用につなげる

*AI駆動開発 **自社の知見·技術*

AI FinOpsについて、Vol.01では、AIのコストが設計判断から生まれることを書きました。Vol.02では、モデル選択、人の介入、並列度、知識基盤という四つの設計を見ました。

次の課題は、その設計をどう運用するかです。設計は一度決めて終わりではありません。モデルは入れ替わり、価格体系も変わります。決めたときは最適だったやり方が、半年後もそうだとは限りません。案件ごとに事情も違います。

Vol.03で考えたいのは、この「決めたあと」です。何をどう見直し、発注側と受託側はそれぞれ何を確認するのか。
この点を考えていきます。

決めた設計は、いずれ古くなる

AIの世界では、モデルも価格も変わります。今日の最適解が、半年後も最適とは限りません。
問題は、モデルが変わるたびに何が起きるかです。モデルを入れ替えるのにコードの書き換えが要るなら、モデルの見直しそのものが開発案件になります。そうなると、現場は「動いているから触らない」を選びがちです。
大事なのは、どの工程にどのモデルを使うか、どこに人の確認を置くかを、設定として切り替えられることです。書き換えるのではなく、切り替える。この差が、見直しを続けられるかどうかを分けます。
案件によっても事情は違います。品質を最優先する案件もあれば、量をさばく案件もあります。AI FinOpsは、一つの正解を全社に押しつけるものではありません。条件が変わったときに、変えられることのほうが重要です。

モデルも変わる、利用量も変わる

AIは日々進化しています。それにつれて、モデルもトークン利用料金も変わります。今日の最適解が、半年後も最適とは限りません。そのたびにシステム全体を書き換えるのではなく、どの仕事にどのモデルを使うか、どこで人が確認するかを、運用側の設定として変えられるほうが現実的です。
案件によっても事情は違います。品質を最優先する案件もあれば、処理量が多く、単価が効いてくる案件もあります。AI FinOpsは、一つの正解を全社に押しつけるのではなく、条件に応じて調整できることが重要です。

モデルを再検討するための判断材料

設定として切り替えられることと、切り替えるべきだと判断できることは、別の話です。
どのプロジェクトの、どの工程で、どのAgentが、どのモデルを呼んだのか。その実行は、どの成果物につながったのか。誰の役割として動いたのか。ここまで結びついて初めて、コストは請求情報ではなく、設計を見直すためのデータになります。
そして、この記録が品質や統制の記録と別の場所にないことが大切です。同じ粒度で並べられれば、品質に問題がないのにコストだけ増えているのか、コストは低いが手戻りが増えているのかが分かります。片方だけを見て動くと、安くするために品質を落とす方向に進みやすくなります。

ちょうどよい点は、動かしながら探す

前回、人が確認する場所には濃淡が要る、という話をしました。ただ、その濃淡をどこに置けば正解なのかは、案件を始める前には分かりません。
人の確認を密にすれば、AIが道を外れたときの再実行は減ります。そのぶん人の時間を使います。粗くすれば逆になります。どちらが安くつくかは、案件の性質と、実際に走らせてみた結果で決まります。
だから、最初に決めた配置を後から組み替えられることが要ります。安全と経済性のちょうどよい点は、設計書の上で決め切るものではなく、案件ごとに動かしながら見つけるものです。
走らせている最中に手を入れられることも、同じ理由で要ります。途中で止めて方針を伝え直す。成果物を差し戻す。この工程は自分で書くと決めて引き取る。こうした操作が最初から用意されていれば、想定と違う方向に進んだときの損失を、その場で止められます。

リアルタイムでのコスト確認ー月末の請求書を待たない

コスト超過が月末の請求書で初めて分かるのでは、打てる手が限られます。
特定の工程で再実行が増えていないか。想定より高価なモデルの利用が続いていないか。並行して動く工程が増え、利用ペースが予算を上回っていないか。実行のたびに記録が積み上がっていれば、月末を待たずに見に行けます。そして、決めた費用の上限に達したものは、こちらから探しに行かなくても人に上がってきます。
もう一つ大事なのは、これを品質の監視と同じ場所でやることです。品質低下、逸脱、コスト超過。この三つを別々の仕組みで見ていると、コストの異常だけが後回しになります。同じ場所で検知できれば、「AI予算を使いすぎた」という月次の事後報告ではなく、「特定の工程で想定を超える再実行が起きている」というその場の検知に変わります。経済性の異常が、品質や安全の異常と同じ重みで意思決定に乗るということです。

Light Forgeで、これをどうつないでいるか

私たちが開発しているLight Forgeでも、この考え方を形にしようとしています。
・どのAgentが何をしているのかが見える
・役割ごとに使うモデルを割り当てられる
・人が確認する場所を、後付けの承認ではなく工程の部品として置ける
・決めた費用の上限を超えたものは、止まって人に上がってくる
ここまでは前回も触れました。
見直しという観点で効いてくるのは、これらが別々の管理ツールに分かれていないことです。同じ実行データの上に載っているから、設定を変えた結果が次の実行の記録に返ってきて、また次の判断の材料になります。実行のなかに、経済性の設計を溶かし込む。そうなって初めて、AI FinOpsは別の管理業務ではなく、普段の開発運用の一部になります。
Light Forgeが唯一の答えだとは考えていません。ただ、企業がAIを本格運用するなら、「AIを動かせる」だけでは足りず、「使い方を見直し続けられる」基盤が必要になる。私たちはそう考えています。

発注側が確認しておきたい3つのこと

まず、AI予算がどこまで分解して見えるかです。プロジェクト別、工程別、Agent別に見えるのか。その呼び出しが本題の作業だったのか、自己検証ややり直しだったのかまで分かるのか。「今月は○○万円でした」で終わらないことが重要です。
次に、TCO（総保有コスト）にAIの変動コストが入っているか。月次保守費だけを前提にすると、利用が広がったときの上振れを捉えにくくなります。
そして、AIを含むシステムの要件に、経済性を入れること。品質、セキュリティ、監査だけでなく、「どのように利用量を把握し、見直せるのか」まで調達時に確認する必要が出てきます。

受託側は、「AIを使っています」だけでは済まない

受託する側も、「AIを使っています」だけでは説明が足りなくなります。
どの工程で、どのモデルを、なぜ使ったのか。利用量やコストを成果物や工程と結びつけて説明できるか。モデル選択や人の介入、並列度を案件ごとに設計する方法が、個人の経験ではなく組織の方法論になっているか。
さらに、こうした経済性の設計自体を、提供価値としてどう扱うかという論点も出てきます。AI利用料を原価として転嫁するだけではなく、AIを経済的に運用するための設計そのものに価値があるからです。

「AIを使う」から、「AIを使い続ける」へ

AI駆動開発がPoCを抜け、毎日の仕事の中で動くようになると、経済性は脇役ではいられません。
ただ、この移行の中心にあるのは、より高精度なモデルでも、より賢いAgentでもありません。一度決めた使い方を、条件が変わるたびに見直せる状態にしておくこと。そこに尽きます。
AI FinOpsは、コスト削減術ではありません。AIの使い方を、経営的に成立する形へ調整し続けるための考え方です。
「AIを導入したか」ではなく、「AIを使い続けても成立するか」。AI駆動開発はもう技術論ではなく、運用をどう総合的に設計するかという経営課題になっています。

AI駆動開発は、ここから本番です

Light Forgeが唯一の答えだとは考えていません。ただ、私たちが目指しているのは、この総合設計を思想のままにしておかないことです。品質を守りながら、コストを賢く配分する。安全を担保しながら、統制コストを最適化する。継続性を維持しながら、経営的に成立する運用に仕上げる。どれも「気をつけましょう」では回りません。実行環境の中に機能として置かれて、初めて動き始めます。

この三部で書いてきたモデルの使い分け、人の介入、並列度、知識基盤、そして経済性の見直し。これらを別々のツールではなく、一つの実行環境の上でつなげていく。私たちが向かっている先はそこです。
そして、ここまで読んでいただいた方は、AI駆動開発を始めるための論点を、ほぼ手にしています。
何を売るのか。どこに人を置くのか。何にいくらかかり、どう見直すのか。この三つを持って始められるなら、それはPoCの試行ではなく、続けられる運用の出発点になります。

AI駆動開発はもう技術論ではなく、運用をどう総合的に設計するかという経営課題になっています。
AIが使えることは、もう分かっています。ここからは、使い続けられる形をどう組むかです。日本のIT・SI現場がその段階へ進むために、イー・ビジネスは設計思想と実装機能の両輪で伴走していきたいと考えています。

会社概要

会社名：株式会社イー・ビジネス
所在地：〒105-6405 東京都港区虎ノ門1丁目17番1号 虎ノ門ヒルズビジネスタワー5階
設立：2007年6月12日
社員数：333名（2026年2月現在）
コーポレートサイト：https://www.e-business.co.jp/