〜Identify / Evaluate / Optimizeで、本番で使えるAIを選ぶ〜

はじめに

本記事は、AWS Summit Japan 2026で発表された
「生成AIモデルを選ぶ技術 -モデル選択のフレームワーク-」
（小林 大樹氏 / アマゾン ウェブサービス ジャパン合同会社）の内容をもとに、生成AIモデル選定のポイントを実務向けに整理したものです。

生成AIのモデル選定では、モデル単体の性能だけで判断しないことが重要です。
実際の業務では、文脈、ツール、評価データ、運用条件まで含めて使い勝手が決まります。

そのため本記事では、Identify / Evaluate / Optimize の3ステップで、
「本番で使えるAIをどう選ぶか」をまとめます。

注意
本記事はAWS Summit Japan 2026 の 生成 AI モデルを選ぶ技術 – モデル選択のフレームワーク – の内容をもとにした非公式の日本語要約であり、すべての著作権・知的財産権はAWSに帰属します。

忙しい方用まとめ

• 生成AIモデル選定は、Identify / Evaluate / Optimize の3ステップで考える
• 候補選定では、モダリティ・ベンチマーク・モデル固有の強みを見る
• 評価では、自社データのゴールデンデータセットで正確性・手順・コスト・安全性を確認する
• 最適化では、ファインチューニング・キャッシュ・推論サービス階層を使い分ける
• 本番で使えるAIにするには、モデル単体ではなく運用全体を設計することが重要

まず全体像を3ステップで押さえる

Step	目的	具体的に見ること
Identify	候補を絞る	モダリティ、ベンチマーク、モデル固有の強み
Evaluate	自社データで確かめる	正確性、手順、コスト、レイテンシー、安全性
Optimize	本番向けに整える	ファインチューニング、キャッシュ、推論サービス階層

この流れのよいところは、単に「良さそうなモデルを探す」のではなく、業務要件に沿って候補を絞り、実データで確かめ、運用できる形に整えるところまで含めて考えられる点です。

生成AIモデル選定が難しくなっている理由

今は選択肢が非常に多いです。
オープンウェイトモデル、フロンティアモデル、マルチモーダル対応モデル、推論特化モデルなど、比較対象は幅広く、ユースケースによって見るべきポイントも変わります。

一方で、現場では次のような課題が起こりがちです。

• どのモデルが自社のユースケースに合うかがわからない
• 何を基準に比較すればよいかわからない
• 評価に時間がかかりすぎて、新モデルの登場に追いつけない
• 結局、知名度の高いモデルをなんとなく選んでしまう

つまり、選択肢が多いこと自体が意思決定の難しさになっているのです。

事例：不正取引調査エージェント

セッションでは、金融機関の不正取引調査を例に説明していました。
毎日大量のアラートが上がり、アナリストがトランザクションログや関連文書を一件ずつ確認して判断している。これをAIで効率化したい、というユースケースです。

要件は大きく3つでした。

• 構造化データと非構造化データの両方を扱えること
• 正確で簡潔な調査サマリーを作れること
• 大量トークンを処理できるよう、コスト最適化できること

このような業務では、単に「文章がうまいモデル」では不十分です。
業務に必要な入力を扱えるか、期待する精度が出るか、そして本番のトラフィックに耐えられるかまで見る必要があります。

Step 1：Identify — 候補モデルを絞る

最初のステップは、候補モデルの特定です。
ここでは大きく3つの観点で絞り込んでいきます。

1. モダリティで絞る

まずは、モデルが扱える入力・出力の種類を見ます。
今回のユースケースでは、扱うのはトランザクションログとドキュメント、つまりテキスト中心です。

そのため、画像生成や音声合成のようなモデルは候補から外します。

2. ベンチマークで絞る

次に、サードパーティのベンチマークを使って比較します。
ここで重要なのは、総合スコアだけを見るのではなく、自分のユースケースに近い指標を見ることです。

たとえばこの事例では、次のような観点が重視されていました。

• 長文読解・長文推論に強いか
• 要約品質が高いか
• ドキュメントからの情報抽出が正確か
• エージェント的なタスクに向いているか

ベンチマークはあくまで候補を絞るための材料であり、最終判断は自社データで行います。

3. モデル固有の強みを見る

最後に、そのモデル特有の強みを見ます。たとえば、

• 複雑な推論が得意か
• ツールを使い分けるエージェント用途に強いか
• ファインチューニングなどのカスタマイズが可能か

といった点です。

この3つを踏まえた結果、候補はかなり絞られます。
セッションでは最終的に、Claude Sonnet 4.5、OpenAI gpt-oss 20b、DeepSeek V3.1 が候補として挙がっていました。

Identifyの比較表を作ると、判断が再利用しやすくなる

候補を選ぶ段階では、文章で説明するだけでなく、比較表に落とすと実務で使いやすくなります。

モデル候補	対応モダリティ	長文処理	ツール利用	微調整可否	運用形態	採用判断
Claude Sonnet 4.5	テキスト / マルチモーダル	強い	あり	要確認	API	長文要約と推論のバランスがよい
OpenAI gpt-oss 20b	テキスト	要確認	あり	あり	オープンウェイト	カスタマイズ余地が大きい
DeepSeek V3.1	テキスト	要確認	あり	要確認	API / 自前運用	コストや推論性能の比較対象

※ 実際には、価格、レイテンシー、ライセンス、社内ホスティング要件も併記すると、より判断しやすくなります。

Step 2：Evaluate — 自社データで評価する

候補を絞ったら、次は評価です。
ここで重要なのは、「良さそう」ではなく、自社の業務で本当に使えるかを確認することです。

そのために使うのが、ゴールデンデータセットです。
これは、人間が「この質問に対する正解はこれ」と保証した、質問と回答のペアです。

これを使えば、同じプロンプトを複数モデルに投げて、どれだけ正解に近いかを比較できます。
つまり、自社業務に特化した評価基準を持てるわけです。

ゴールデンデータセット作成には課題がある

ただし、ここが一番大変です。

• 網羅的なケースを作りづらい
• 人間が作ると似たパターンに偏りやすい
• 正解の確認に時間がかかる

そこで紹介されていたのが、人間とAIの役割分担です。

AIを使って評価データをスケールさせる

セッションでは、マルチエージェントを使ってゴールデンデータセットを作る方法が紹介されていました。

1. ユーザーシミュレーターエージェント

不正取引調査員のペルソナを与え、現場で実際に出そうな質問を大量生成します。

2. タスクエージェント

その質問に対し、データベース検索や各種ツールを使って回答を組み立てます。

3. 批評エージェント

人間が定めた採点基準に沿って、回答をレビューします。
合格した質問・回答ペアだけがゴールデンデータセットとして保存されます。

この仕組みのポイントは、人間が細かいデータ作成作業を全部やるのではなく、判断基準そのものを作る側に回ることです。
これにより、評価データの作成をスケールしつつ、専門家の負担を抑えられます。

何を評価するのか

評価では大きく2種類のメトリクスを見ます。

1. 運用メトリクス

本番で回るかどうかを見る指標です。

• コスト
• レイテンシー
• スループット
• エラー率 など

モデルが賢くても、高すぎる・遅すぎる・負荷に弱いなら本番では使えません。
特に大規模トークンを扱う業務では、少しの差が大きなコスト差になります。

2. 出力品質のメトリクス

出力品質を見る指標です。

• 正確性
• スタイルや読みやすさ
• 安全性や責任あるAIかどうか
• 自社KPIに直結するカスタムメトリクス

たとえば不正取引調査なら、「問い合わせから人間の最終判断までにかかる時間」がKPIになります。
これにより、AI導入が実際に業務効率化に寄与しているかを測れます。

評価方法は1つではない

評価には複数の手法があります。

• プログラマティック評価：正解・不正解が明確なタスク向け
• 人間による評価：ニュアンスや専門性の高い判断向け
• LLM-as-a-Judge：高性能なモデルに採点役を担ってもらう方法

特に LLM-as-a-Judge は、自動化しつつ一定の評価品質を目指せる点が魅力です。
ただし、最終出力だけでなく、正しい手順でツールを使ったかも見る必要があります。

たとえば、結論は合っていても、途中で必要なデータベース検索を飛ばしていたら、本当の意味で正しいとは言えません。
そのため、ゴールデンデータセットには「正解回答」だけでなく「期待する手順」も含めることで、エージェントの振る舞いまで評価できるようにします。

Step 2の補足：エージェントの評価では「手順」も見る

ここがこのセッションの中でも特に重要なポイントでした。

通常のモデル評価では、質問と正解回答があれば十分です。
しかし、AIエージェントでは、最終出力だけでなく、そこに至るまでの手順が正しいかも重要です。

たとえば、最終的な回答が合っていたとしても、

• 本来必要なツールを呼んでいない
• 確認すべきデータソースを見ていない
• 手順を飛ばして偶然正解にたどり着いている

というケースがあります。
このような場合、出力だけを見て「正しい」と判定してしまうと危険です。

そこで、ゴールデンデータセットに expectedTrajectory（期待する手順） を追加し、
どのツールをどの順番で使うべきかまで評価できるようにします。

これにより、結果だけではなくプロセスも含めて採点できるようになります。

Step 3：Optimize — 本番向けに最適化する

評価で候補を絞ったら、最後は最適化です。
ここでは主に3つの手法がありました。

1. ファインチューニング

オープンウェイトモデルを自社データで調整します。
専門用語が多い業務や、回答の型を揃えたいケースでは特に有効です。

2. プロンプトキャッシング

毎回同じシステムプロンプトや長文ドキュメント、ツール定義などを再利用します。
これにより、コスト削減とレイテンシー改善ができます。

3. 推論サービス階層の使い分け

すべてのリクエストに同じ速度・同じコストをかける必要はありません。
重要な処理は高速な階層、そこまで急がない処理は安価な階層に回すことで、全体のコストを抑えられます。

要するに、すべてを最高性能のモデルに寄せるのではなく、役割に応じて使い分けるのがポイントです。

実際の成果

この不正取引調査エージェントでは、ファインチューニングで専門性を高め、キャッシュや推論サービス階層でコストを最適化した結果、
1日5億トークンから50億トークンへ10倍にスケールしながら、本番コストを80%削減できた と紹介されていました。

つまり、モデル選定フレームワークは単なる比較手法ではなく、業務インパクトに直結する運用設計そのものだと言えます。

Optimizeでやっていたこと

セッション内の最適化は、主に次の3つです。

• ファインチューニング
  オープンウェイトモデルを不正取引調査の用語やケースで調整し、精度を向上

• プロンプトキャッシング
  繰り返し参照される長文コンテキストをキャッシュして、コストとレイテンシーを削減

• 推論サービス階層の活用
  重要な処理は高速階層、遅延を許容できる処理は安価な階層に回して最適化

この3つを組み合わせることで、精度を落とさずに、本番コストを大きく下げることができます。

まとめ

生成AIモデルは、「最強の1つ」を探すより、業務に合う形で選び、評価し、最適化し続けることが重要です。

今回のフレームワークをまとめると、次の通りです。

• Identify で候補を絞る
• Evaluate で自社データに照らして確かめる
• Optimize で本番に耐える形に仕上げる

そして、この流れは一度きりではありません。
新しいモデルが出るたびに、同じ型で見直せるようにしておくことが大切です。

本当に必要なのは、単に賢いモデルではなく、業務文脈に接続されたAIを継続的に選び直せる仕組みです。
その意味で、この3ステップのフレームワークは、生成AIを本番活用するための実践的な指針になるはずです。

AIエージェント導入を検討している方へ

私たちナレッジコミュニケーションでは、構想の整理からナレッジ設計、認証連携、実装、運用改善まで、Amazon Bedrock をベースに、社内で使い続けられるAIエージェント体制をお手伝いしています。

▼ AIエージェント導入・構築支援サービス | Amazon Bedrock

「何から始めればいいかわからない」という方もご相談は無料ですので、お気軽にお問い合わせください。