情報システムのAX(AIトランスフォーメーション)戦略──生成AIのコストは「総額」ではなく「単価」で支配する

「AIのコストが想定を超えて増えている。経営から『削減しろ』と指示が来た」──情報システム部門で、この状況に直面している方は多いはずです。しかし、その指示への応え方を間違えると、コストではなく会社の成長を削ることになります。

結論を先に示します。

情報システムのAXとは、AIの単位コスト──1タスクあたりのコスト──を下げ続ける基盤を運営し、全社のAI活用の採算ラインを引き下げる変革のこと。目的関数は総額の削減ではなく、単価の支配である。単価が下がり続ける限り、総額の増加は会社の活動量の拡張を意味する。

本記事では、なぜ「総額削減」が誤った目標なのかを構造から整理し、単価を下げ続ける実務（AI FinOps）、日本の情シスだけが持つ「本当に削れるコスト」、そして情シスという部門の再定義までを解説します。

結論：目的関数は「総額削減」ではなく「単価の支配」
1. そのまま使える：役員への30秒回答
【誤解を正す】「AIコスト削減」が会社の成長を止める構造
日本の情シスが持つ「本当に削れるコスト」──外注費という変動費
1. 内製化の損益分岐が動いた
2. そのまま使える：内製化・外注継続の判断チェックリスト
コンテナが貿易を爆発させた──単価支配の歴史
単価を下げ続ける実務──AI FinOpsの5つのレバー
情シスは「限界費用エンジン」である
限界費用エンジンは「資産の器」でもある
内製化ロードマップは、人材転換ロードマップである
単価支配の罠
情報システムのAXに関するよくある質問
まとめ：単価を制する者が、拡張を制する
1. 一次資料・参考文献

結論：目的関数は「総額削減」ではなく「単価の支配」

改めて、本記事の結論です。

対象は、生成AI・AIエージェントを全社で使う企業の情報システム部門と、そのコストを評価する立場の方です。

そのまま使える：役員への30秒回答

「AIコストが増えているが大丈夫か」には、2つの数字でお答えします。第一に単価です。1タスクあたりのAIコストは計測しており、継続的に下げています。第二に総額です。総額の増加は、単価が下がった結果、これまで採算に乗らなかった業務にまでAIが使われるようになった──つまり会社の活動量が増えた──ことの反映です。管理すべきは総額の上限ではなく、単価の低下率です。無駄の削減は別途、即時に実行します。

【誤解を正す】「AIコスト削減」が会社の成長を止める構造

「AIコストを削減しろ」という指示は、一見まっとうです。しかし総額だけを見た削減は、構造的に会社の拡張を止めます。分解して確認しましょう。

AI総コスト＝活動量×タスク数×単価

AIの総コストは、3つの掛け算です。AIを使う業務の数（活動量）、業務あたりの処理回数（タスク数）、そして1タスクあたりのコスト（単価）。経営会議で見えるのは総額だけですが、動かせるレバーはこの3つで、それぞれ意味がまったく違います。

ジェボンズの請求書：単価が下がるほど、総額は増える

技術の単価が下がると、これまで採算に乗らなかった用途が次々と採算に乗り、利用の総量が増えて総支出はむしろ増える──経済学でジェボンズのパラドックスと呼ばれる、産業史で繰り返し観測されてきた現象です。AIでも同じことが起きます。1回の推論が安くなるほど、「その値段ならこの業務にも使おう」が増える。つまり、単価が下がっているのに総額が増えているなら、それは失敗ではなく、拡張が機能している兆候です。マーケティング部門が実験回数とコンテンツ供給量を拡張すれば（トップライン型のAX）、その請求書は情シスに届きます。届くべくして届いているのです。

総額に上限を課すと、何が起きるか

それでも総額キャップで管理すると、3つの副作用が出ます。第一に、拡張の配給制。部門間でAI利用枠の取り合いが始まり、採算の合う施策が予算名目で止まります。第二に、シャドーAIの再燃。正規ルートが割当制で窮屈になれば、現場は安い個人アカウントへ逃げます。第三に、機会損失。競合が単価低下を拡張に変えている間、自社だけ活動量を固定することになります。

削ってよいコストと、削ってはいけないコスト

もちろん、削るべきコストは実在します。同じ成果に対する無駄──重複した推論、定型作業への過剰スペックなモデルの使用、使われていないライセンス──は即削減の対象です。削ってはいけないのは、活動量の増加に由来する増分。この2つを区別する仕組みが、単価管理にほかなりません。

日本の情シスが持つ「本当に削れるコスト」──外注費という変動費

「人件費の削減は幻になりやすい」というのが、このシリーズで繰り返し述べてきた日本の条件です。人件費は従業員数でしか減らない固定費だからです。しかし情シスには、実際に減らせる特大の変動費があります。外注費です。

内製化の損益分岐が動いた

日本のIT産業の構造的な特徴は、IT人材の多くが事業会社ではなくベンダー側に所属していることです。その結果、システムの開発も保守も外部委託が前提になり、情シス予算の大半が外注費・SI委託費で占められてきました。ここにAIコーディングの実用化が直撃しています。要件定義から実装・テストまでの生産性が大きく変わり、「社内の少人数＋AI」で賄える領域が急拡大した。内製と外注の損益分岐点が、はっきりと内製側へ動いたのです。

レガシーシステムの問題──ドキュメントが残っておらず、有識者が退職し、改修のたびに高額な調査費用がかかる、いわゆる「2025年の崖」の宿題──にも同じことが言えます。AIによるコード解読・仕様の復元・移行支援は、崖の返済コストそのものを引き下げます（この構造問題の全体像はAXとは？AIトランスフォーメーションの定義とDXとの違いで解説しています）。

そのまま使える：内製化・外注継続の判断チェックリスト

すべてを内製にする話ではありません。次の観点で仕分けます。

変更頻度は高いか（高い→内製向き。外注の都度見積もりが最も高くつく領域）
自社の競争力に直結するか（直結する→内製向き。学習が社内に蓄積する）
仕様が社内に閉じているか（閉じている→内製向き）
継続的な保守が必要か（必要→内製またはAI併用で保守費圧縮）
安定稼働が最優先の基幹領域か（該当→外注継続も合理的）
ベンダー固有技術への依存度は高いか（高い→段階的に依存を下げる計画を）

要は、変更が速く競争力に近いものから内製へ。動きの遅い基幹は無理に引き取らない、という濃淡です。

コンテナが貿易を爆発させた──単価支配の歴史

「単価を下げると総量が解放される」ことにも、有名な歴史の前例があります。

20世紀半ばまで、海上輸送のコストの大半は港での積み替え作業でした。荷物の形がばらばらで、人手で一つずつ積み下ろしていたからです。そこに登場したのが、規格化された鉄の箱──海上コンテナです。どんな荷物も同じ箱に入れて同じ機械で扱えるようにした結果、荷役の単位コストは桁違いに下がり、船の停泊時間は劇的に短縮されました。そして何が起きたか。輸送業は縮小するどころか、世界の貿易総量が爆発的に増え、産業として拡大したのです。

規格が単価を下げ、単価が総量を解放する。AIにおけるこの「規格の箱」が、全社のAI利用を一本化するゲートウェイです。どの部門が、どのモデルを、どの業務で使っても、同じ箱を通る。だから測れる、最適化できる、差し替えられる。ゲートウェイは、社内のコンテナ規格なのです。

単価を下げ続ける実務──AI FinOpsの5つのレバー

クラウドのコスト管理実務は「FinOps」と呼ばれてきました。その対象がAIに広がった領域──AI FinOpsが、情シスの新しい中核業務です。レバーは5つあります。

レバー①：計測──単位コストを定義する

支配の第一歩は計測です。「1タスクあたり」を業務の言葉で定義してください。1問い合わせ処理あたり、1コンテンツ制作あたり、1実験あたり、1コミットあたり。利用を部門・用途別にタグ付けし、単価の推移をダッシュボードで見える化する。計測なくして支配なし、です。

レバー②：ルーティング──タスクの難度とモデルの格を合わせる

最大の無駄は、定型作業に最上位モデルを使うことです。タスクを難度で階層化し、モデルの階層と対応させます。

タスク階層	業務の例	使うモデルの階層
定型・大量	分類、情報抽出、一次要約	軽量モデル
標準	文章作成、コード補完、社内Q&A	中位モデル
高難度	複雑な推論、重要文書の作成、エージェントの統括	最上位モデル

モデル階層間の価格差はしばしば1〜2桁あります。この振り分け（ルーティング）をゲートウェイで自動化すれば、品質を落とさずに平均単価が大きく下がります。

例示：各社のモデル名称と料金は変化が速いため、本文では階層のみを示しています。振り分け設計の際は、必ず最新の料金表と性能評価を確認してください。

レバー③：キャッシュと再利用──同じ推論を二度買わない

同じ質問、同じ文脈への推論を毎回買うのは無駄です。プロンプトの共通部分のキャッシュ、頻出質問への回答の再利用、RAG（検索拡張生成）での共通コンテキストの管理で、重複支出を削ります。

レバー④：バッチと非同期──急がない処理は安い経路へ

すべての処理に即時性は要りません。夜間バッチで足りる集計・生成処理を、割安なバッチ経路や混雑時間外に回すだけで、単価は下がります。「いつまでに要るか」は、コスト設計の変数です。

レバー⑤：調達──定額・従量・自社ホストの使い分け

利用量が読める定常業務は定額プラン、変動の大きい業務は従量APIという使い分けが基本です。大量・定型の処理では、公開モデルの自社ホストが損益分岐を超える場合もあります（判断の枠組みは、AIセキュリティを主題にした関連記事のオープンソースAIの章で扱っています）。

なお、レバー①〜④の実装点はすべてゲートウェイです。セキュリティの出入口（データの経路統制）とコストの計測点は同じ場所にあり、一つの投資が二重に効きます。

情シスは「限界費用エンジン」である

ここまでの実務が意味するのは、情シスという部門の再定義です。

単価が1桁下がると、採算に乗る施策が1桁増えます。マーケティングが「これまでROIが合わなかったロングテール施策の解禁」を語れるのは、誰かが1タスクの単価を下げているからです。その誰かが情シスです。つまり情シスは、コストセンターではなく、全社の拡張の採算ラインを決める部門──言うなれば限界費用エンジンです。

経営への報告も、この因果で組み替えてください。「今月の削減額」ではなく、「単価の低下率→それによって採算ラインを越えた施策の数→各部門の実験数・供給量の増加→売上因子への波及」。単価から売上までの鎖を示せる情シスは、予算を「守る」立場から、投資を「提案する」立場に変わります。

限界費用エンジンは「資産の器」でもある

内製化には、コスト以外の副産物があります。無形資産の蓄積です。

外注中心の時代、開発の成果物や知見は契約とともにベンダー側に散っていました。内製×AIの時代は、コード、プロンプト資産、業務ワークフロー、RAGに蓄えたナレッジベースが、日々社内に積み上がります。これらは次の拡張の原資であると同時に、管理すべき資産です。

ここで知っておくべき接続が一つあります。営業秘密として法的な保護を受けるには、秘密として管理されている実態──アクセス制御、ログ、持ち出し制限といった「秘密管理性」──が要件になります。お気づきでしょうか。これは、ゲートウェイとデータ基盤ですでに設計してきた施策そのものです。つまり秘匿の局面では、セキュリティと知財は対極ではなく、同じ投資が二重に効く関係にあります。一方、あえて「公開して取る」局面──特許の出願や、AI検索に引用されるための情報公開──もあり、その攻守の裁定は経営の領分です。この知財の各論は、AIと知財を主題にした関連記事で扱う予定です。

実務面では、調達業務にも新しい確認項目が加わります。AIサービスの利用規約における出力の商用利用条件と権利の帰属、そして公開モデルを使う場合のライセンス確認です。

内製化ロードマップは、人材転換ロードマップである

最後に、外注費の削減で浮いたカネの話です。

マーケティングのAXでは「浮いた時間の行き先」が問題でした。情シスのAXでは「浮いたカネの行き先」が同じ構造で問われます。外注費の削減は実費なので、削減自体は本物です。しかし行き先を決めずに放置すれば、単年の利益に溶けて、基盤も人も育ちません。推奨は、削減額の一定割合を人材転換投資の原資として予算化することです。

そして、最初のリスキリング対象は情シス自身です。ベンダー管理と調達が中心だった役割は、プラットフォーム運営、AI FinOps、データと資産の基盤運営へ移ります。KPIには、内製化率・単価低下率と並べて、社内人材のスキル転換数を置いてください。転換の具体的な進め方は、AXとリスキリングを主題にした関連記事で扱う予定です。

単価支配の罠

誠実に、この戦略の落とし穴も書いておきます。

第一に、安さの追求が品質を壊すこと。安いモデルへの切り替えで失敗率や再作業が増えるなら、それは単価の偽装です。判断は常に、失敗・再作業・人の監督コストまで含めた実効単価で行ってください。

第二に、全面内製は誤答になりやすいこと。内製化は「守る主体が自社に移る」ことと引き換えです。基幹の安定領域まで無理に引き取る必要はありません。

第三に、FinOpsを承認制にしないこと。モデル利用の事前申請制は、審査の待ち行列と迂回を生みます。ルーティングと上限管理は仕組みで自動化し、人は例外だけを見る──統制の実効性は、ここでも「速い正規ルート」から生まれます（この設計思想は、AI活用ガイドラインを主題にした関連記事で詳述しています）。

情報システムのAXに関するよくある質問

Q1. 情報システムのAXとは何ですか？

Q2. 経営から「AIコストを削減しろ」と言われたら、どう応えるべきですか？

総額を「単価×活動量」に分解して報告してください。単価は継続的に下げていること、総額の増加は活動量の拡張の反映であることを示し、重複推論や過剰スペック利用などの純粋な無駄は即時に削減します。

Q3. 単位コストは何から計測すればよいですか？

利用量の大きい1〜2の用途から、「1タスクあたり」を業務の言葉で定義します（1問い合わせ処理、1コンテンツ、1コミットなど）。部門・用途別のタグ付けを整え、単価の推移を月次で追える状態を先に作ってください。

Q4. 内製化はどこから始めるべきですか？

変更頻度が高く、自社の競争力に直結する小さな領域からです。都度見積もりの外注が最も割高につく場所ほど、内製化の効果が出ます。安定稼働が最優先の基幹領域は、外注継続も合理的な選択です。

Q5. 安いモデルに切り替えて、品質は大丈夫ですか？

タスクの難度とモデルの階層を対応させれば、大半の定型・標準業務は問題ありません。ただし判断は、失敗率や再作業を含む実効単価で行い、階層をまたぐ切り替えには必ずテストを挟んでください。

Q6. AI FinOpsはどの部門が担うべきですか？

計測基盤と自動ルーティングは情報システム部門が持ち、単価KPIの管理は財務と共同で行う形が定着しやすい構造です。利用の可否を事前承認制にすることは、待ち行列と迂回を生むため推奨しません。

Q7. 情シスの人員や役割は、どう変わりますか？

ベンダー管理・調達中心の役割から、プラットフォーム運営・AI FinOps・データと無形資産の基盤運営へ移ります。人員の削減ではなく転換であり、外注費の削減額の一部を転換投資の原資に充てるのが現実的です。

まとめ：単価を制する者が、拡張を制する

総額の増加を恐れる必要はありません。誇るべきは単価の低下率です。ゲートウェイという社内のコンテナ規格で計測・最適化・差し替えを可能にし、外注費という本物の変動費を内製化で削り、その削減額を人材転換の原資に回す。情報システム部門は、コストセンターではなく、全社の拡張の採算ラインを決める限界費用エンジンです。本記事のタスク階層表と内製化チェックリストは、そのまま社内資料としてお使いください。