8月3日、TechTargetが「Rethink the AI stack: Why lean open architecture is the answer」と題した記事を公開した。巨大モデルへのAPI依存を脱却し、リーンなオープンアーキテクチャでAIコストの削減とデータ主権の確保を両立する戦略が論じられている。
「メールの仕分けにロケット科学者を雇っている」問題
多くの企業が現在、900億パラメータ級の巨大モデルに単純タスクを処理させ、高額なAPI料金を払い続けている。記事はこの状況を「ロケット科学者に朝のメール仕分けをさせているようなもの」と表現する。
背景には、ここ数年で大規模言語モデルへのAPIアクセスが一気に民主化されたことがある。OpenAI・Anthropic・Googleといったプロバイダーが強力なモデルをAPI経由で提供し、多くの企業がその利便性に乗っかる形でAI活用を進めてきた。しかしこのアプローチは「モデルの能力」ではなく「APIへの依存」を深める構造になっており、コスト・セキュリティ・ベンダーロックインの三重苦として顕在化しつつある。さらに、EUのAI法（EU AI Act）をはじめとするデータローカライゼーション規制の強化が、外部APIへの機密データ送信にブレーキをかけ始めている点も見逃せない。
この問題に一石を投じたのが、Thinking Machines Labが公開した**Inkling-Smallだ。総パラメータ数276億ながら、1回の推論で使うアクティブパラメータはわずか120億という設計で、Artificial Analysis Intelligence Indexでスコア40**を記録している。このスコアは、GPT-4oやClaude 3.5 Sonnetといった旗艦クラスのモデル群が集中するレンジと同等水準にあり、「小型モデルは精度で劣る」という従来の前提を覆す数値として記事は取り上げている。
記事の核心はInkling-Smallの紹介ではなく、「どんなアーキテクチャでAIを組むか」という設計思想の転換にある。
データを外に出すな――オンプレ・プライベートクラウド回帰の論理
従来の企業AIアーキテクチャは、自社の機密データを外部クラウドのAPIエンドポイントに送り続ける構造だった。120億アクティブパラメータのモデルであれば、プライベートクラウドやオンプレミスのデータセンターで十分に動作する。データをクラウドに送るのではなく、計算をデータのそばに置く発想への転換だ。
具体的なメリットとして記事は以下を挙げる：
- モデルのアップグレードとポータビリティ：Tinker（Thinking Machines Labが提供するモデルのファインチューニング・デプロイを支援するプラットフォーム）などを通じてアップグレードサイクルを自社管理できる。ドメイン特化ファインチューニング（LoRA）の適用や、サードパーティAPIの変更で下流アプリケーションが壊れる心配なしにモデルを差し替えられる。
- エアギャップ環境での自律動作：金融・医療などの規制業種では、外部ネットワーク通信なしに決定論的なパフォーマンスを得られる。
「フランケンシュタインアーキテクチャ」を避けろ
音声転写モデル、ビジョンモデル、LLM、コーディングモデルを組み合わせた構成を、記事は「フランケンシュタインアーキテクチャ」と呼ぶ。APIホップが増えるほどレイテンシが上がり、コストが膨らみ、セキュリティ上の攻撃面も広がる。
記事が示す具体例が興味深い。自動車保険の事故申請を処理するシナリオでは、従来アーキテクチャだと音声・写真・警察の調書をそれぞれ別サービスに投げていた。ネイティブマルチモーダルなモデルを単一パイプラインで動かせば、音声・画像・文書を一括処理し、証言と物的証拠の矛盾を検出して構造化した推奨を生成する――しかも機密顧客データは社内ネットワークの外に出ない。
オープンウェイトの逆説：主権を得れば責任も負う
自社ネットワーク内にオープンウェイトモデルを持ち込むことで、運用上のすべての責任が自チームに移る。モデルがハルシネーションを起こしても、プロンプトインジェクション攻撃を受けても、不正なマイクロサービス呼び出しを実行しても、「クラウドベンダーのせい」にはできない。
記事が提示するセキュリティ対策は実践的だ：
- 決定論的な実行ガードレール：LLMに直接DBへの書き込みをさせない。モデルはアクションを「提案」し、決定論的なマイクロサービスがパーミッションを検証してから実行する。
- 入力のサニタイズとサンドボックス：取り込むすべてのドキュメント・音声・プロンプトを「信頼できない入力」として扱い、プロンプトインジェクション攻撃を防ぐ。モデルが生成したコードはサンドボックス化されたマイクロVMコンテナ内でのみ実行する。
- ゲートウェイ経由のモデル差し替え：LiteLLMやvLLMなどの統一ゲートウェイレイヤーで内部開発者APIを標準化する。アプリロジックとモデルウェイトを分離することで、Inkling-Small・Llama・カスタムウェイト間の切り替えが下流アプリケーションを壊さずに行える。
CIO向け90日アクションプラン
記事は具体的なロードマップも示す：
- 1〜30日目：ワークロードの計算コスト監査。単純なルーティング、エージェントコーディング、深い推論に分類し、1Mトークン出力あたり$4以上のコストを払っているタスクのうち、**$1.20程度のモデルで同等精度が出るもの**を特定する。この価格差は記事内でInkling-Smallと旗艦モデルの比較例として示されているものであり、各ベンダーの最新料金は公式ページで要確認だ。
- 60日目：実行分離とゲートウェイレイヤーの実装。モデル推論とバックエンド実行を厳密に分離する。
- 90日目：可変コンピューティングのアーキテクチャ設計。動的ルーティングレイヤーで、本当に必要なタスクにだけ「思考時間（テスト時計算）」を割り当てる。
大規模モデルへのアクセス競争が第一フェーズだとすれば、次のフェーズはより賢いアーキテクチャを組めるかどうかで決まる、というのが記事の結論だ。どのモデルを選ぶかより、どう組むかが問われている。
詳細はRethink the AI stack: Why lean open architecture is the answerを参照していただきたい。
