社内の勉強会(WG)では、毎回AI業界の新しい動きを持ち寄り、それが開発の現場や企業のAI活用にどう影響するかを話し合っています。今回は、その中から中小企業の経営者・担当者の方や開発者の方に役立ちそうな話題を3つに絞ってご紹介します。
- すべてに最上位モデルを使わない「適材適所」のモデル選び
- 大規模モデルと判断特化型の小型モデルを組み合わせる「ハイブリッド構成」
- 安全にAIを使うための開発環境と「仕様書駆動開発」
1. すべてに最上位モデルを使う必要はない
WGでまず話題になったのは、「ミドルレンジモデル」と呼ばれる中位クラスのAIモデルの進化です。ひと世代前の最上位モデルに近い精度を、より低いコストで出せるモデルが各社から登場している、という話が共有されました。
これまで「難しい作業は最上位モデルでないと無理」と考えられていた仕事の多くが、中位クラスのモデルでも代替できるようになりつつあります。そのため、あらゆる業務に一律で最上位モデルを使うやり方は、費用の面で効率が悪くなってきています。
使い分けと定期的な見直し
WGでは、次のような考え方が大切だという結論になりました。
- 日常的な定型業務には中位クラスのモデルを使う:難しい判断や高度な生成が必要な場面だけ上位モデルを使います。
- ルーティングの仕組みを検討する:ルーティングとは、依頼内容(プロンプト)の複雑さを判定し、自動で最適なモデルに振り分ける仕組みのことです。OpenRouterのようなサービスにも、こうした考え方が見られます。
- 使うモデルを定期的に見直す:モデルの価格や性能は短い期間で大きく変わります。一度決めたら終わりではなく、見直しを社内の決まった手順にしておくことが重要です。
AIの利用料が気になっている企業ほど、「どの仕事にどのモデルを使っているか」を一度棚卸ししてみる価値があります。
2. 「考えるAI」と「判断するAI」を組み合わせる
次に話題になったのが、長い文章は書かず、あらかじめ決めた選択肢の中から答えを1つだけ返すことに特化した、小型の言語モデル(SLM:Small Language Model)です。
たとえば「赤・青・黄のどれか」「スパムの可能性は0%・50%・100%のどれか」のように、選択肢を提示しておくと、その中から決まった値だけを返します。プログラムでいう分岐(Switch-Case文)のような働きをするイメージです。長文を生成しないぶんモデルを非常に小さくでき、一般的なPCでも素早く応答できること、手元のPCで少量のデータを使って短時間で専用モデルに調整(ファインチューニング)できることがWGで話題になりました。
ハイブリッドAIアーキテクチャという考え方
WGでは、これを従来の大規模モデルと組み合わせる「ハイブリッドAIアーキテクチャ」が、今後の設計の潮流になるのではないかと議論しました。
- 思考層:大規模言語モデル(LLM)が、複雑な文章の生成や考える作業を担当します。
- 制御層:判断特化型の小型モデルが、プログラムのIF文や分岐に直接組み込まれ、即座に判断を返します。
大きなモデル1つですべてを処理すると、応答が遅くなったり、コストが高くなったり、ハルシネーション(もっともらしい誤った回答)や出力の揺らぎが起きたりすることがあります。一方、決まった選択肢しか返さない小型モデルは出力がぶれにくく、プログラムの中に部品として組み込みやすいという利点があります。「考える部分」と「判断する部分」を分けて設計することは、システムをAIで作るときの有力な選択肢になりそうです。
能動型AIと「人間の最終承認」
関連して、メールや予定を裏で確認し、「忘れている予定はないか」などを自分から知らせてくれる常駐型・能動型のAIエージェントの話題も出ました。WGで注目したのは、AIが判断の候補を準備し、最終的な可否は人間に委ねるという設計です。これは「Human-in-the-Loop(人間が最終承認する仕組み)」と呼ばれ、AIの暴走リスクを抑えながら便利さを高める安全設計として参考になります。業務にAIエージェントを取り入れる際も、どこで人間が確認するかを最初に決めておくことが大切です。
3. 安全にAIを使うための環境づくり
3つ目は、AIを業務で使う際の安全面の話です。
シャドーAI対策
シャドーAIとは、会社が承認していないAIツールを社員が独自に使ってしまうことです。機密のソースコードや情報が外部に流れるリスクがあります。WGでは、開発の現場で無承認のAIツールの直接利用を禁止し、その代わりにデータの流出やモデル学習への利用が行われない、企業として承認したクラウド環境(例としてAWS Bedrock)を用意する、という対策が話題になりました。「禁止するだけ」ではなく「安全に使える代わりの環境を用意する」という点がポイントです。
仕様書駆動開発
あわせて話題になったのが、AWS Kiroという開発環境が掲げる「仕様書(スペック)駆動開発」という考え方です。内部で使うAIモデルを選べる開発環境で、次のような流れを目指すものとして紹介されました。
- 仕様書を起点に、AIがコードを半自動で生成する
- コードを修正・変更すると、それに合わせて仕様書やテストコードも同期して更新される
従来は「人間が仕様書を書き、それを見てコードを書く」流れが一般的で、開発が進むうちに仕様書が実態と合わなくなる(形骸化する)ことがよくありました。仕様書とコードを常に同期させる考え方は、設計の品質を保つための新しいアプローチとして期待されています。
AIにコードを読ませると、見落としに気づけることも
WGでは、MCP(Model Context Protocol:AIと外部ツールやデータをつなぐための共通の仕組み)を使って、AIとGitHubを連携させ、リポジトリ内のドキュメントやソースコードを読み込ませる検証の話も共有されました。AIは資産の構成を解析しただけでなく、「リポジトリ内に環境設定ファイル(.env)が含まれているので、セキュリティ上の整理が必要」と指摘したそうです。.envには接続情報などの重要な設定が入ることが多いため、こうした確認にAIを活用するのは、安全対策の面でも有効だと感じました。
まとめ
今回のWGを通じて見えてきたのは、「一番高性能なAIを何にでも使う」時代から、「目的に合わせてAIを使い分け、組み合わせ、安全な環境で使う」時代へと移りつつあるということです。
- 定型業務は中位クラスのモデルに任せ、使うモデルは定期的に見直す
- 「考える」大規模モデルと「判断する」小型モデルを分けて設計する
- AIエージェントには人間の最終承認を組み込む
- シャドーAIは禁止だけでなく、安全な代替環境を用意して防ぐ
当社では今後も勉強会で得た知見をもとに、AIを安全かつ費用対効果よく活用する方法を発信していきます。
技術ブログのほかの記事

