AIモデルの使い分けの判断基準：役割別の目安・スキルへのモデル固定・判定特化モデルの使いどころ

この記事で分かること

• 最新モデルを役割別にどう使い分けているか（動画内の個人的な印象ベース）
• スキルにモデルを固定する理由と、アドバイザー構成の考え方
• 構造化データを返す判定特化モデルの使いどころと注意点

※ 元動画は自動字幕から起こしており、モデル名・サービス名に誤認識の可能性があります。確信が持てない名称は一般名詞に置き換えています。評価はベンチマークではなく、出演者の使用感です。

前提：この記事が扱う範囲

• 動画は毎月恒例の「最新 AI」についての座談で、収録は9月28日と述べられています。
• 話題の中心は Fable 5.1、Opus 5.5、Astra の3モデルと、判定特化の高速モデルです。
• 以下は「こう使っている」「こういう印象がある」という発言の整理です。ご自身の環境で検証してから取り入れてください。

1. 役割別の使い分けの目安

動画内で語られた印象を表にまとめます。

モデル	向いていると語られた用途	補足
Fable 5.1	CTO業務・PM業務。プロジェクト参加直後に Git などの情報をまとめて渡し、全体を把握したい場面	処理の重さやコストとのバランスが論点
Opus 5.5	SE・設計寄りの作業。普段の作業の基本	気にしなければ全部 Opus でもよい、という話も出た
Astra	UI/UX、3D、グラフィック系。コンピュータ操作	高価で、コスパは悪いという評価

Astra を使う価値があると語られた場面

• 3D 表現：自社サイトのトップ画面の地球の 3D を、ほぼ一発の指示で作れたという例がありました。
• コンピュータ操作：ブラウザやアプリの操作が以前より自然になったという評価です。動画編集ソフトの操作もできたものの、遅く完璧ではないとのことでした。
• デザインツール連携：デザインツールの画面上のコメントを読み、該当箇所を切り抜く操作までできるようになったと述べられています。
• 翻訳：日本語サイトを英語版にする際、会社の強みを逆算して英語ネイティブに違和感のない表現にしてくれた、という使い方が挙がりました。

逆に、高価なモデルが不要な場面

• 多くの業務は、より安価なモデルで十分だという意見がありました。
• コンピュータ操作については、別ベンダーのモデルの方が安定するという声もありました。Claude 系は、指示と違うプレビュー画面で勝手に操作して失敗するという例が挙げられています。
• スマホアプリのアニメーションや UI は ChatGPT 系に任せている、という話もありました。

判断チェックリスト

• その作業は本当に高価なモデルでないとできないか
• 安価なモデルで試して、品質差が許容範囲か
• 速度（業務時間が伸びないか）とコストのどちらを優先するか
• 操作系の作業は、複数ベンダーのモデルで比べたか

2. 複数モデルを組み合わせる運用

動画内では次のような構成が紹介されました。

• 作業系は Opus に任せ、考える部分や返答だけ Fable にする。これをチーム全員で同じ環境にそろえる。
• ツール側に「アドバイザー」という仕組みがあり、Fable を指定すると、Opus が困ったときだけ Fable を呼び出す。

スキルにはモデルを固定する

スキルは使うモデルに依存するため、作るときにモデルを固定しているとのことです。スキル内で使うモデルを指定できるという説明でした。

1. スキルを作る時点で、使うモデルを決める
2. スキル側にモデルを明記して固定する
3. （補足）モデルが更新されたら、スキルが想定どおり動くか見直す

3 は動画の発言ではなく一般的な運用上の補足です。

3. 判定特化モデルの使いどころ

動画では、構造化データを高速に返す判定特化のモデル（字幕上は「ジェブ」と聞こえる表記）が話題でした。名称は確証がないため、ここでは「判定特化モデル」と呼びます。

評価されていた点

• 通常の LLM はテキストで想定外の形式が返ってきてエラーになることがあるが、構造化データで返るため扱いやすい。
• 確率付きで結果が返る。
• 速い（1秒を切る速さという発言もありました）。
• 出演者の一人は、ほぼ全部のスキルに組み込んだと述べています。

使い方の例

• 迷惑メールの仕分け：メールの内容と、選択肢となるカテゴリ一覧を渡し、その中から選ばせる。真偽値で返させる使い方もある。
• コンピュータ操作の高速化：HTML を渡してボタンの位置などを一瞬で解析させ、操作を速くする。
• 大量のエージェントによる事前検証：数百体のエージェントに解析させ、ユーザーに見せる前に A/B テスト相当のことを試す、というニュースが紹介されました。判定特化モデルを入れるとさらに高速になるという話です。実際の世の中の反応と一致するかは、動画内でも疑問が出ていました。

注意点

• 現状は画像を渡せないため、画像はテキスト化する必要がある。
• 裏側でどのモデルを使っているか不明なため、出演者の一人はまだ導入しておらず、大手が同様のものを出してから使う姿勢でした。

導入前のチェックリスト

• 分類の選択肢（カテゴリ）を、自分たちで明確に定義できるか
• 出力形式が固定されていると助かる処理か
• 入力が画像ではなくテキストか、テキスト化できるか
• 提供元の実態が不明でも、差し替えられる設計になっているか

4. 乗り換え前提で考える

• 大手が同種のものを出すまで3週間かかるとしても、便利なものはすぐ入れるという考え方が紹介されました。
• 出演者はこれを、新しいカードが出たらデッキに入れる感覚にたとえていました。
• 見方を変えると、モデルは入れ替わる前提でスキルを設計することが重要になります。

5. 動画の見立て：AIがコモディティ化した後に残るもの

• 速さ・安さ・能力はすでに高い水準に達し、驚きの幅は減ったという見方でした。ただし、まだ進化の余地はあるとも述べられています。
• 以前は「一つの工程に責任を持つ」という考え方が語られましたが、今は細かな工程は AI に任せる前提になってきている、という話が出ました。
• 一方、人間のレビューも完全には信用できないので、AI のほうがましな場面もあるという意見がありました。
• 数学の未解決問題の話題では、AI が解いたとしても、それを正しいと担保して検証するのは人間で、そこに限界が残るという論点が出ました。

実務に引き寄せると、モデルの選定、スキルの設計、出力の検証基準づくりといった領域が、エンジニアの力量が出る部分だと言えそうです。

この記事は YouTube チャンネル「エンジニアファースト」の動画の内容を、記事として再構成したものです。
https://www.youtube.com/watch?v=Tq0sDZ_sGTw