専門用語が判断の場から人を外す
「そこは技術的な話なので」と言われて確認を諦めたことは、誰にでもあるはずです。専門用語は、判断の場から人を外すためにも使えます。
技術的な設計には専門知識が必要です。これは事実です。しかし判断の妥当性を確認する作業には、専門知識を必要としない部分があります。費用がいくらか、切り替えられるか、障害に気づけるか、誰が直せるか。この4点は業務側でも判断できます。
型1 ― 過剰なインフラ・過剰な基盤の売り込み
必要な構成より大きい設計が提案される型です。理由は必ずしも意図的ではなく、提案側が想定する規模と実際の規模がずれていることから生じます。
確認の順序を示します。表の第13章の判断順序に対応します。
| 順 | 確認すること | この確認で分かること |
|---|---|---|
| 1 | 想定している処理件数(月間・ピーク時) | 自社の実態と合っているか |
| 2 | 1件あたりの処理時間と費用 | 件数を掛けた総額 |
| 3 | 同時に使う利用者数 | 必要な処理能力 |
| 4 | この構成が必要になる件数の水準 | より小さい構成で足りる可能性 |
| 5 | 小さく始めて拡張する場合の追加費用 | 段階的に進める選択肢の有無 |
4番目と5番目が重要です。「この構成は月間何件から必要になりますか」という質問は、規模の妥当性を直接検証します。自社の件数がその水準に届いていない場合、より小さい構成から始める選択肢があります。
表の第13章で述べたとおり、クラウドAPIで始めて処理量が安定してから自社環境を検討する順序が費用面で有利になることが多いのです。逆順(最初に設備投資)は、処理量の見積もり誤りの影響が大きくなります。
型2 ― 運用基盤の必要性を規模と切り離して語る
モデルの管理・デプロイ・監視の基盤(表の第13章のMLOps/LLMOps)は、規模によって必要な水準が変わります。小規模な用途に大規模な基盤を導入すると、保守対象が増えるだけになります。
規模ごとに必要な水準を整理します。
| 規模 | 最低限必要なもの | 不要なことが多いもの |
|---|---|---|
| 1業務・月数千件 | 抽象化の層、ログ、費用上限、検証セット | 専用の基盤製品、自動デプロイ環境 |
| 数業務・月数万件 | 上記+回帰テストの自動実行、監視と通知 | 複数環境の並行運用 |
| 全社・月数十万件以上 | 上記+バージョン管理の仕組み、段階的な切り替え | ― |
1行目の4項目は規模に関わらず必要です。これらは製品を導入しなくても実装できます。抽象化の層は自社のコードで、ログは記録の設定で、費用上限は管理画面の設定で、検証セットはファイルで足ります。
確認は「この基盤を導入しない場合、何ができなくなりますか」です。答えが具体的であれば、その機能の必要性を自社で判断できます。
型3 ― コスト最適化を無視した「最新技術」推し
新しい技術や高性能なモデルを使う構成が、費用の検討を伴わずに提案される型です。
表の第13章に費用削減の手順があります。効果の大きい順に、モデルの振り分け、入力の削減、キャッシュ、上限と可視化。この順序が提案に反映されているかを確認します。
- 処理の種類でモデルを振り分けているか ― すべての処理を高性能モデルで行う構成は、費用の大部分を無駄にしている可能性があります。
- 入力を絞る設計になっているか ― 文書全体を毎回送る構成は、費用が入力量に比例します。
- 同じ処理の再計算を避ける仕組みがあるか ― 繰り返される質問や共通の前置きについて。
- 費用の上限が設定されているか ― 超えた場合の動作も含めて。
提案に1件あたりの費用の実測値がない場合、費用の見積もりは推計です。表の網羅版 第3章「主要AIサービス・モデルの比較」に見積もりの手順があります。実測した入出力の量から計算し、再試行・テスト・エラー分を1.2〜1.5倍で見込む。この計算がされていない提案は、稼働後に請求額が見積もりを上回ります。あわせて「月間の費用上限を設定できますか。超えた場合はどう動きますか」を確認してください。
型4 ― 可観測性と障害対応を省いた「動けばよい」提案
稼働後に必要になる仕組みが、初期の提案に含まれない型です。省かれやすい項目を挙げます。
- ログの記録項目 ― 入力・出力・使用モデルとバージョン・トークン数と費用・処理時間・人による修正。
- 異常の通知 ― 誰に、どういう条件で通知されるか。
- 失敗の受け皿 ― 処理できなかった案件がどこに溜まり、誰が気づくか。
- 品質の監視 ― 人による修正の割合の推移。
4番目が、AIを含む仕組みに特有の項目です。表の第13章で述べたとおり、コードを変えていないのに品質が変わるという性質があるため、この監視がないと精度の低下に気づく手段が利用者からの申告だけになります。
確認は次の2問です。いずれも専門知識を必要としません。
- 「品質が下がったとき、誰がどうやって気づきますか」
- 「処理できなかった案件は、どこに溜まって誰が気づきますか」
この2問に具体的に答えられない提案は、運用の設計を行っていません。
型5 ― 切り替えの余地を残さない構成を「統合の利点」として語る
第10章で扱った依存の問題を、設計の側から見ます。抽象化の層を挟まない構成は、実装が単純になる代わりに切り替えの費用が上がります。
この選択には正当な場合があります。試作段階、単発の用途、短期間で使い終わる処理では、抽象化の層は過剰です。問題は、継続的に使う仕組みでこの選択が説明されないことです。
確認は「モデルやサービスを変更する場合、どこを直すことになりますか」です。「1箇所です」と答えられる構成には抽象化の層があります。「呼び出している箇所すべてです」という答えであれば、切り替えの費用が呼び出し箇所の数に比例します。
二年目の十二月、朝凪精機はアストラム・データから受注入力の刷新の提案を受けました。構成図には運用の基盤製品がいくつも並び、AI推進室の瀬尾が説明できない言葉は14個ありました。十日に平文で説明してもらった席では、呼び出しを自社のコードで包む層を一枚挟めば、切り替えも記録も費用の集計も一か所で済むという助言も出ました。瀬尾が月に数千件という想定を伝え、「この運用の基盤は、月に何件くらいから必要になるものですか」と照会すると、翌朝、営業部長の間宮から、月間数十万件規模を想定した構成だという回答が届きました。結果として、運用の仕組みは月数千件の規模に合わせて包む層・ログ・費用の上限・二重処理の防止から始め、基盤製品は件数が増えた段階で再検討する方針にしました。照会に要したのはメール1往復でした。
この場面は網羅物語之巻 第9章「動くものと、使えるもの」に出てきます。
専門知識なしで確認できる4点
この章の確認質問を、業務側が使える形にまとめます。技術の妥当性ではなく、判断に必要な情報が示されているかを問う質問です。
- 費用 ― 1件あたりの実測費用はいくらか。月間の上限は設定できるか。この構成が必要になる件数の水準はどれだけか。
- 切り替え ― モデルやサービスを変更する場合、どこを直すことになるか。
- 気づける仕組み ― 品質が下がったとき、処理が失敗したとき、誰がどうやって気づくか。
- 直せる人 ― この構成を変更・復旧できる人は、社内に何人になるか。
4番目は事業継続の指標です(表の網羅版 第10章「事業継続・ベンダー依存リスク管理」)。社内に0人という答えであれば、規模を縮めるか、外部の保守を契約するか、社内で担える構成に変えるかの判断が必要になります。この判断は技術ではなく経営の判断です。