Ollamaじゃない？ OllayaのDecision ModelをAWS認定試験で評価してみた

Last updated at 2026-10-01Posted at 2026-10-01

AWS認定試験のサンプル問題を使い、OllayaのDecision Modelであるlayaとwinnowを比較検証しました。

はじめに

AI Private Cloud運用チームでは、セルフホスト可能なSLM（Small Language Model）の活用可能性を継続的に検証しています。

ローカルLLMやSLMの検証というと、次のような用途が注目されがちです。

チャット
文書要約
RAG
コーディング支援

一方、インフラやクラウドの運用現場では、次のような「判断」を支援するユースケースも多く存在します。

インシデント判定
アラート分類
チケット振り分け
SEV判定
運用手順の確認
設計レビュー

今回は、このような判断支援用途を想定し、ローカルで意思決定モデルを実行できるOllayaをKubernetes上にデプロイしました。

さらに、AWS認定試験の4択問題を分析する専用モデルを作成し、laya と winnow の判断結果を比較しました。

本記事の検証結果はAWS認定試験のサンプル問題1問に対するものです。モデル全体の正答性能を評価したものではありません。

なぜAWS認定試験問題を使うのか

AWS認定試験の問題は、単純な用語やサービス名の知識だけを問うものではありません。

受験者は問題文から次の情報を読み取る必要があります。

要件を抽出する
制約を理解する
AWSサービスの仕様と照合する
誤った選択肢を除外する
複数の実現可能な方法から最適解を選ぶ

例えば、問題文では次のような判断が求められます。

最もコスト効率が高い方法は何か
管理作業を最小化するにはどうするか
高可用性を実現するには何が必要か
現在のデータを保持したまま再開するにはどうするか

このため、AWS認定試験の4択問題は、SLMの次の能力を確認する題材として利用できます。

文章理解
要件抽出
技術領域の分類
AWSサービスの特定
選択肢の比較
最適解の判断

今回はAWS SAAレベルのサンプル問題を使って、セルフホストSLMの判断能力を検証しました。
単純な知識問題ではなく、要件抽出・選択肢比較・最適解選択を含むため、Decision Modelの評価題材として適していると考えています。

Ollayaとは

Ollayaは、オープンな意思決定モデルをローカルで実行するためのランタイムです。

Ollamaが自然言語生成を主目的としたLLMランタイムであるのに対して、Ollayaは意思決定（Decision Making）に特化したモデル実行環境です。
状態と型付き質問を入力として受け取り、構造化された判断結果と確率を返します。

主な質問形式は次のとおりです。

形式	用途
`choice`	複数の候補から1つを選択する
`score`	定義した段階に沿ってスコアリングする
`noul`	Yes/No相当の判定を行う

Ollayaは文章を生成するというより、次のような処理に向いています。

問い合わせ
  ↓
緊急度判定
  ↓
担当部署判定
  ↓
エスカレーション要否判定

インフラ運用では、次のようなユースケースが考えられます。

問い合わせ分類
アラート分類
担当チームの振り分け
SEV判定
エスカレーション判定
ポリシー適合性チェック

Ollayaはポート11435でAPIを提供し、コンテナとしてghcr.io/ollaya-dev/ollayaが公開されています。

参考資料:

今回比較したモデル

Ollayaでは複数のDecision Modelが提供されています。
今回はその中から、

laya
winnow

の2モデルを比較しました。
どちらも choice、score、noul といった構造化された判断を返すことができますが、設計思想と得意分野が異なります。

laya

layaはOllayaの標準的な軽量モデルです。laya自体はルーターモデルとして動作し、入力言語に応じて内部のモデルを切り替えます。

Router
  strategy            script
  default             english
  → english           laya:en
  → multilingual      laya:multilingual

今回のAWS試験問題は日本語だったため、内部的には laya:multilingual が利用されます。
推論能力よりもスループットを重視する用途に向いています。

軽量
CPU環境でも利用しやすい
応答が速い
多言語対応
分類タスク向け

winnow

winnowは高い判断精度を目的としたDecision Modelです。
処理速度よりも判断品質を重視する用途に向いています。

推論能力が高い
多言語対応
要件分析に強い
Choice形式の判断精度が高い
技術試験や設計レビューとの相性が良い

比較した理由

今回の検証テーマは、セルフホストSLMが実運用で利用できるレベルの判断を行えるかを確認することでした。

そのため、 高速な軽量モデル vs 高精度な推論モデル という対比が分かりやすいlayaとwinnowを比較対象として選択しました。

検証構成

今回の検証構成は次のとおりです。

項目	内容
実行環境	Kubernetes（AI Private Cloud）
ランタイム	Ollaya
コンテナイメージ	`ghcr.io/ollaya-dev/ollaya:cuda`
公開ポート	`11435`
外部公開方式	NodePort
比較モデル	`laya:latest`、`winnow:latest`
評価対象	AWS認定試験の4択問題
評価方法	Modelfileによる固定Questions

OllayaをKubernetesへデプロイする

前提条件

以下が利用できることを前提とします。

Kubernetesクラスタ
kubectl
コンテナレジストリへの接続
モデルをダウンロードするための外部ネットワーク接続

Kubernetesマニフェスト

次のマニフェストには、以下のリソースをまとめています。

Namespace
Deployment
NodePort Service

ollaya.yamlを作成します。

以下は最小限のサンプルです。
必要に応じて、PVCでモデル保存ディレクトリを永続化する等の対応を追加してください。

$ cat > ollaya.yaml <<'EOF'
apiVersion: v1
kind: Namespace
metadata:
  name: ollaya
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollaya
  namespace: ollaya
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollaya
  template:
    metadata:
      labels:
        app: ollaya
    spec:
      containers:
      - name: ollaya
        image: ghcr.io/ollaya-dev/ollaya:cuda
        imagePullPolicy: IfNotPresent
        command:
        - ollaya
        args:
        - serve
        ports:
        - containerPort: 11435
          protocol: TCP
        resources:
          requests:
            nvidia.com/gpu: 1
          limits:
            nvidia.com/gpu: 1
        readinessProbe:
          tcpSocket:
            port: 11435
          initialDelaySeconds: 10
          periodSeconds: 5
        livenessProbe:
          tcpSocket:
            port: 11435
          initialDelaySeconds: 30
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: ollaya
  namespace: ollaya
spec:
  type: NodePort
  selector:
    app: ollaya
  ports:
    - name: http
      protocol: TCP
      port: 11435
      targetPort: 11435
      nodePort: 31435
EOF

マニフェストを適用する

$ kubectl apply -f ollaya.yaml

Deploymentの完了を確認します。

$ kubectl rollout status deployment/ollaya -n ollaya

各リソースの状態を確認します。

$ kubectl get pod,service -n ollaya -o wide

想定される出力の例は次のとおりです。

NAME                         READY   STATUS    RESTARTS   AGE    IP              NODE         NOMINATED NODE   READINESS GATES
pod/ollaya-9454fcf9f-d5p9h   1/1     Running   0          123m   172.29.75.245   gpunode001   <none>           <none>

NAME             TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE    SELECTOR
service/ollaya   NodePort   10.150.181.143   <none>        11435:31435/TCP   140m   app=ollaya

Pod内で作業する

Pod名を直接指定すると、Podの再作成によって名前が変わります。

そのため、Deploymentを指定してPod内でシェルを起動します。

$ kubectl exec -it deployment/ollaya -n ollaya -- sh

以降のコマンドは、特に記載がない限りOllayaコンテナ内で実行します。

コンテナにはviなどのエディタが含まれていない場合があります。

今回はヒアドキュメントを使用し、エディタなしでJSONとModelfileを作成します。

AWS試験分析用Questionsを作成する

単にA、B、C、Dから正解を選択させるだけでは、モデルが問題をどのように理解したのか分かりません。

今回は次の項目を同時に判定させます。

項目	目的
`correct_answer`	A、B、C、Dから最適解を選択する
`confidence`	解答の確信度を評価する
`primary_domain`	問題の中心技術領域を特定する
`primary_service`	中心となるAWSサービスを特定する
`question_type`	問題で重視される要件を分類する
`option_*_quality`	各選択肢の妥当性を評価する
`cost_optimization`	コスト最適化が主要要件か判定する
`high_availability`	高可用性が主要要件か判定する
`security_requirement`	セキュリティが主要要件か判定する
`performance_requirement`	性能が主要要件か判定する
`operational_simplicity`	運用簡素化が主要要件か判定する

`aws-questions.json`

次のコマンドをOllayaコンテナ内で実行します。

$ cat > aws-questions.json <<'EOF'
{
  "correct_answer": {
    "type": "choice",
    "instructions": "AWS認定試験の設問と選択肢A、B、C、Dを読み、AWSサービスの仕様と問題文の要件を最も適切に満たす選択肢を1つ選んでください。",
    "criteria": {
      "A": "選択肢A",
      "B": "選択肢B",
      "C": "選択肢C",
      "D": "選択肢D"
    }
  },
  "confidence": {
    "type": "score",
    "instructions": "選択した正解に対する確信度を評価してください。",
    "criteria": [
      "非常に低い",
      "低い",
      "中程度",
      "高い",
      "非常に高い"
    ]
  },
  "primary_domain": {
    "type": "choice",
    "instructions": "この問題で中心となるAWS技術分野を1つ選択してください。",
    "criteria": {
      "compute": "EC2、Auto Scaling、Elastic Load Balancing、ECS、EKSなどのコンピューティング",
      "storage": "S3、EBS、EFS、FSxなどのストレージ",
      "database": "RDS、Aurora、DynamoDB、Redshiftなどのデータベース",
      "networking": "VPC、Route 53、CloudFront、Transit Gatewayなどのネットワーク",
      "security": "IAM、KMS、Cognito、WAF、Shieldなどのセキュリティ",
      "operations": "CloudWatch、AWS Config、Systems Manager、CloudFormationなどの運用管理",
      "integration": "SQS、SNS、EventBridge、Step Functionsなどのアプリケーション統合",
      "analytics": "Athena、Glue、EMR、Kinesis、OpenSearchなどの分析",
      "migration": "DMS、DataSync、Application Migration Serviceなどの移行",
      "machine_learning": "Bedrock、SageMaker、Rekognition、ComprehendなどのAIおよび機械学習"
    }
  },
  "primary_service": {
    "type": "choice",
    "instructions": "正解を導くうえで最も重要なAWSサービスまたは機能を1つ選択してください。",
    "criteria": {
      "ec2": "Amazon EC2。インスタンス、AMI、停止、休止状態を含む",
      "autoscaling": "Amazon EC2 Auto Scaling",
      "elastic_load_balancing": "Elastic Load Balancing",
      "lambda": "AWS Lambda",
      "ecs": "Amazon ECSまたはAWS Fargate",
      "eks": "Amazon EKS",
      "s3": "Amazon S3",
      "ebs": "Amazon EBSまたはEBSスナップショット",
      "efs": "Amazon EFS",
      "fsx": "Amazon FSx",
      "rds": "Amazon RDSまたはAmazon Aurora",
      "dynamodb": "Amazon DynamoDB",
      "elasticache": "Amazon ElastiCache",
      "redshift": "Amazon Redshift",
      "vpc": "Amazon VPC。サブネット、ルート、NAT、セキュリティグループを含む",
      "route53": "Amazon Route 53",
      "cloudfront": "Amazon CloudFront",
      "direct_connect": "AWS Direct ConnectまたはAWS Site-to-Site VPN",
      "iam": "AWS Identity and Access Management",
      "kms": "AWS Key Management Service",
      "cognito": "Amazon Cognito",
      "waf_shield": "AWS WAFまたはAWS Shield",
      "cloudwatch": "Amazon CloudWatch",
      "systems_manager": "AWS Systems Manager",
      "cloudformation": "AWS CloudFormation",
      "sqs": "Amazon SQS",
      "sns": "Amazon SNS",
      "eventbridge": "Amazon EventBridge",
      "step_functions": "AWS Step Functions",
      "api_gateway": "Amazon API Gateway",
      "other": "上記以外のAWSサービス、または複数サービスの組み合わせ"
    }
  },
  "question_type": {
    "type": "choice",
    "instructions": "設問が主に問う要件を1つ選択してください。",
    "criteria": {
      "cost": "コスト最適化",
      "availability": "高可用性または耐障害性",
      "security": "セキュリティまたはコンプライアンス",
      "performance": "性能またはレイテンシー",
      "operations": "運用効率または管理負荷の削減",
      "migration": "システムまたはデータの移行",
      "troubleshooting": "障害解析またはトラブルシューティング"
    }
  },
  "option_a_quality": {
    "type": "score",
    "instructions": "選択肢AがAWSサービスの仕様と問題文の要件をどの程度満たすか評価してください。",
    "criteria": [
      "完全に誤り",
      "主要要件を満たさない",
      "部分的に正しい",
      "ほぼ要件を満たす",
      "すべての要件を満たす最適解"
    ]
  },
  "option_b_quality": {
    "type": "score",
    "instructions": "選択肢BがAWSサービスの仕様と問題文の要件をどの程度満たすか評価してください。",
    "criteria": [
      "完全に誤り",
      "主要要件を満たさない",
      "部分的に正しい",
      "ほぼ要件を満たす",
      "すべての要件を満たす最適解"
    ]
  },
  "option_c_quality": {
    "type": "score",
    "instructions": "選択肢CがAWSサービスの仕様と問題文の要件をどの程度満たすか評価してください。",
    "criteria": [
      "完全に誤り",
      "主要要件を満たさない",
      "部分的に正しい",
      "ほぼ要件を満たす",
      "すべての要件を満たす最適解"
    ]
  },
  "option_d_quality": {
    "type": "score",
    "instructions": "選択肢DがAWSサービスの仕様と問題文の要件をどの程度満たすか評価してください。",
    "criteria": [
      "完全に誤り",
      "主要要件を満たさない",
      "部分的に正しい",
      "ほぼ要件を満たす",
      "すべての要件を満たす最適解"
    ]
  },
  "cost_optimization": {
    "type": "noul",
    "instructions": "コスト最適化は、この問題の正解を選ぶための主要要件ですか。"
  },
  "high_availability": {
    "type": "noul",
    "instructions": "高可用性または耐障害性は、この問題の正解を選ぶための主要要件ですか。"
  },
  "security_requirement": {
    "type": "noul",
    "instructions": "セキュリティ、アクセス制御、暗号化またはコンプライアンスは、この問題の正解を選ぶための主要要件ですか。"
  },
  "performance_requirement": {
    "type": "noul",
    "instructions": "性能、スループットまたはレイテンシーは、この問題の正解を選ぶための主要要件ですか。"
  },
  "operational_simplicity": {
    "type": "noul",
    "instructions": "運用作業または管理負荷を最小化することは、この問題の正解を選ぶための主要要件ですか。"
  }
}
EOF

laya版とwinnow版のModelfileを作成する

OllayaのModelfileでは、次の内容を定義できます。

ベースモデル
組み込みQuestions
キャリブレーション
精度
説明
ライセンス

今回は、同じaws-questions.jsonをlayaとwinnowで共有します。

これにより、質問条件を揃えたうえで出力を比較できます。

次の3ファイルを同じディレクトリに配置します。

aws-questions.json
Modelfile.laya
Modelfile.winnow

laya版

$ cat > Modelfile.laya <<'EOF'
FROM laya:latest

QUESTIONS ./aws-questions.json

DESCRIPTION AWS four-choice certification question analyzer based on laya
EOF

winnow版

$ cat > Modelfile.winnow <<'EOF'
FROM winnow:latest

QUESTIONS ./aws-questions.json

DESCRIPTION AWS four-choice certification question analyzer based on winnow
EOF

今回は実際に検証したモデルに合わせてlatestを使用しました。

ただし、継続的なベンチマークで比較条件を固定する場合は、更新される可能性があるlatestではなく、評価対象として決めた固定タグを使う方が再現性を高められます。

派生モデルを作成する

laya版

$ ollaya create aws-saa-laya -f Modelfile.laya

成功すると、次のように表示されます。

using existing layer sha256:35ff836f8a432388ccf7b4a0b34a36617102972e8db35226661cf0498f29b42a
using existing layer sha256:ec56c3e69fab09b41de6f1c80fdcc13b83ec1eef1f72d3022baaafde3d9307e9
creating new layer sha256:5189f2e55d8a610b495a54aad36d794ea5cee74dda5e6839c9aaa9c1e32f78b7
writing manifest
success

winnow版

$ ollaya create aws-saa-winnow -f Modelfile.winnow

同様に、次のように表示されます。

using existing layer sha256:b710efc4c0d048ee61eed92c5fef5ce323a4d17e7c51f9f0533cc72ae50818ea
using existing layer sha256:d8c4d73b8e66f5e7f59ad7ba6dfef20ef7cf15d6d65c27becf098e295a3acca8
using existing layer sha256:0088393cc0e629e1d708e541623b8cf14bc86cd09cad86f68a92f1aee3bfc217
using existing layer sha256:caa0c5ceea854b663741f0d1e220b01433c1cbcf43895cd1cf619f53ff3485bc
creating new layer sha256:5189f2e55d8a610b495a54aad36d794ea5cee74dda5e6839c9aaa9c1e32f78b7
writing manifest
success

作成済みモデルを確認する

$ ollaya list
NAME                    ID             SIZE     MODIFIED
aws-saa-winnow:latest   576068744b58   13 GB    53 minutes ago
aws-saa-laya:latest     c06e1142d5ce   15 KB    54 minutes ago
winnow:latest           8d72fee0e5f9   13 GB    1 hour ago
laya:latest             89aa53ce17e1   11 KB    2 hours ago
laya:multilingual       2840506e1f97   683 MB   2 hours ago
laya:en                 c305a9276531   853 MB   2 hours ago

詳細を確認します。

$ ollaya show aws-saa-laya

$ ollaya show aws-saa-winnow

今回の環境では、aws-saa-layaは次のように作成されました。

Model
  architecture        laya
  format              router
  languages           en, multilingual
  derived from        laya:latest

Router
  strategy            script
  default             english
  → english           laya:en
  → multilingual      laya:multilingual

日本語の問題を入力すると、ルーターによってmultilingualモデルが選択されます。

一方、aws-saa-winnowは次の構成でした。

Model
  architecture        winnow
  parameters          12B
  context length      8192
  precision           Q8_0
  format              gguf
  engine              llama.cpp
  languages           multilingual
  derived from        winnow:latest

どちらのモデルでも、次のQuestionsが表示されればJSONが正しく組み込まれています。

Questions
  correct_answer             choice (4 options)
  confidence                 score (5 levels)
  primary_domain             choice (10 options)
  primary_service            choice (25 options)
  question_type              choice (7 options)
  option_a_quality           score (5 levels)
  option_b_quality           score (5 levels)
  option_c_quality           score (5 levels)
  option_d_quality           score (5 levels)
  cost_optimization          noul
  high_availability          noul
  security_requirement       noul
  performance_requirement    noul
  operational_simplicity     noul

検証に使用した問題

今回使用した問題は、Amazon EC2インスタンスを2週間停止してコストを削減するシナリオです。

問題文はAWS公式サンプル問題集 AWS-Certified-Solutions-Architect-Associate_Sample-Questions より一部抜粋：

あるソリューションアーキテクトは、会社が 2 週間一時休業する間に実行する必要のない Amazon EC2 インスタンスのコストを節約するため、ソリューションを設計したいと考えています。EC2 インスタンスで実行されているアプリケーションは、インスタンスが動作を再開するときに必要なデータをインスタンスメモリに格納します。

EC2 インスタンスをシャットダウンして再開するために、ソリューションアーキテクトが推奨すべきアプローチはどれですか。

A) インスタンスストアボリュームにデータを格納するようにアプリケーションを変更する。ボリュームを再起動中に、再接続する。
B) EC2 インスタンスを停止する前に、インスタンスのスナップショットを作成する。インスタンスの再起動後に、スナップショットを復元する。
C) 休止状態が有効になっている EC2 インスタンスでアプリケーションを実行する。会社が 2 週間の一時休業に入る前に、インスタンスを休止状態にする。
D) EC2 インスタンスを停止する前に、各インスタンスのアベイラビリティーゾーンをメモしておく。2 週間の一時休業が終わったら、同じアベイラビリティーゾーンでインスタンスを再起動する。

重要な条件は、アプリケーションが再開時に必要なデータをインスタンスメモリに保持していることです。

選択肢を要約すると次のようになります。

A. インスタンスストアを利用する
B. EC2停止前にスナップショットを作成する
C. 休止状態を有効化してHibernateを利用する
D. 同じAvailability Zoneで再起動する

この問題の正解は C です。（解説は引用元のページで確認してください）

AWS試験問題を実行する

laya版

$ ollaya run aws-saa-laya

複数行を入力する場合、対話画面で最初と最後に"""を入力します。
とありますが、私の環境では複数行まとめてベタっと貼り付ける分には不要でした。

終了する場合は次を入力します。

/bye

winnow版

$ ollaya run aws-saa-winnow

同じ問題文を入力し、出力を比較します。

layaの実行結果

今回の実行結果は次のとおりです。

$ ollaya run aws-saa-laya
Enter a state to decide about (/? for help, """ for several lines).
>>> あるソリューションアーキテクトは、会社が 2 週間一時休業する間に実行する必要のない Amazon EC2 イン
スタンスのコストを節約するため、ソリューションを設計したいと考えています。EC2 インスタンスで実行され
ているアプリケーションは、インスタンスが動作を再開するときに必要なデータをインスタンスメモリに格納し
ます。

EC2 インスタンスをシャットダウンして再開するために、ソリューションアーキテクトが推奨すべきアプローチ
はどれですか。
A) インスタンスストアボリュームにデータを格納するようにアプリケーションを変更する。ボリュームを
再起動中に、再接続する。
B) EC2 インスタンスを停止する前に、インスタンスのスナップショットを作成する。インスタンスの再起
動後に、スナップショットを復元する。
C) 休止状態が有効になっている EC2 インスタンスでアプリケーションを実行する。会社が 2 週間の一時
休業に入る前に、インスタンスを休止状態にする。
D) EC2 インスタンスを停止する前に、各インスタンスのアベイラビリティーゾーンをメモしておく。2 週
間の一時休業が終わったら、同じアベイラビリティーゾーンでインスタンスを再起動する。
correct_answer           C                             █████████░░░░░░░ 0.56
confidence               2.36 / 4  中程度                 ██████░░░░░░░░░░ 0.37
primary_domain           security                      ███░░░░░░░░░░░░░ 0.20
primary_service          ec2                           █████░░░░░░░░░░░ 0.34
question_type            performance                   ██████░░░░░░░░░░ 0.40
option_a_quality         3.28 / 4  ほぼ正しい               ██████░░░░░░░░░░ 0.36
option_b_quality         3.27 / 4  ほぼ正しい               ██████░░░░░░░░░░ 0.35
option_c_quality         3.28 / 4  ほぼ正しい               ██████░░░░░░░░░░ 0.36
option_d_quality         3.26 / 4  ほぼ正しい               ██████░░░░░░░░░░ 0.35
cost_optimization        yes                           ████████████████ 0.98
high_availability        yes                           ████████████████ 0.97
security_requirement     yes                           ███████████████░ 0.95
performance_requirement  yes                           ███████████████░ 0.96
operational_simplicity   yes                           ███████████████░ 0.96
>>>
>>> /bye

layaの考察

correct_answerはCとなり、正解自体は選択できました。

一方、問題の中心技術領域については次のようになっています。

primary_domain  security
question_type   performance

期待値は次の組み合わせです。

primary_domain  compute
question_type   cost

また、以下の要件をすべてyesと判定しています。

cost_optimization
high_availability
security_requirement
performance_requirement
operational_simplicity

選択肢評価もほぼ同じ値になりました。

A = 3.28
B = 3.27
C = 3.28
D = 3.26

この1問では、layaは正解を選択できたものの、技術領域、主要要件、選択肢間の差を明確に識別できませんでした。

winnowの実行結果

winnowでは次の結果になりました。

$ ollaya run aws-saa-winnow
Enter a state to decide about (/? for help, """ for several lines).
>>> あるソリューションアーキテクトは、会社が 2 週間一時休業する間に実行する必要のない Amazon EC2 イン
スタンスのコストを節約するため、ソリューションを設計したいと考えています。EC2 インスタンスで実行され
ているアプリケーションは、インスタンスが動作を再開するときに必要なデータをインスタンスメモリに格納し
ます。

EC2 インスタンスをシャットダウンして再開するために、ソリューションアーキテクトが推奨すべきアプローチ
はどれですか。
A) インスタンスストアボリュームにデータを格納するようにアプリケーションを変更する。ボリュームを
再起動中に、再接続する。
B) EC2 インスタンスを停止する前に、インスタンスのスナップショットを作成する。インスタンスの再起
動後に、スナップショットを復元する。
C) 休止状態が有効になっている EC2 インスタンスでアプリケーションを実行する。会社が 2 週間の一時
休業に入る前に、インスタンスを休止状態にする。
D) EC2 インスタンスを停止する前に、各インスタンスのアベイラビリティーゾーンをメモしておく。2 週
間の一時休業が終わったら、同じアベイラビリティーゾーンでインスタンスを再起動する。
correct_answer           C                             ███████████████░ 0.95
confidence               2.72 / 4  高い                  █████░░░░░░░░░░░ 0.33
primary_domain           compute                       ████████████████ 0.99
primary_service          ec2                           ███████████████░ 0.96
question_type            cost                          ████████████████ 1.00
option_a_quality         0.07 / 4  完全に誤り               ███████████████░ 0.94
option_b_quality         1.02 / 4  要件を満たさない            █████████████░░░ 0.82
option_c_quality         2.43 / 4  部分的に正しい             ██████░░░░░░░░░░ 0.39
option_d_quality         0.81 / 4  要件を満たさない            ██████████░░░░░░ 0.65
cost_optimization        yes                           ████████████████ 0.99
high_availability        no                            ████████████████ 0.98
security_requirement     no                            ████████████████ 0.98
performance_requirement  no                            ████████████░░░░ 0.74
operational_simplicity   yes                           ████████████░░░░ 0.72
>>>
>>> /bye

winnowの考察

主な判定結果は期待どおりでした。

correct_answer   C
primary_domain   compute
primary_service  ec2
question_type    cost

問題文から、次の関係を適切に抽出できています。

EC2
  ↓
インスタンスメモリの保持
  ↓
休止状態
  ↓
2週間停止中のコスト削減

また、問題の中心ではない要件もnoと判定しました。

high_availability        no
security_requirement     no
performance_requirement  no

今回の1問では、正解、技術領域、AWSサービス、主要要件のいずれもwinnowの方が期待値に近い結果となりました。

選択肢評価で発生した不整合

winnowの結果には、興味深い不整合もありました。

correct_answer    C
option_c_quality  2.43 / 4  部分的に正しい

correct_answerではCを0.95で選択していますが、option_c_qualityではCを「最適解」と評価していません。
これは、Ollayaが次のQuestionsを独立して評価しているためと考えられます。

correct_answer
option_a_quality
option_b_quality
option_c_quality
option_d_quality

option_c_qualityが、先に出力されたcorrect_answer=Cを参照して評価しているわけではありません。

そのため、質問間の論理的整合性は別途確認する必要があります。

実運用では、次のような扱いが安全です。

correct_answerを最終回答として扱う
primary_domain、primary_service、question_typeを分析用メタデータとして扱う
option_*_qualityは補助評価として扱う
質問間の矛盾をアプリケーション側で検出する
回答確率が閾値未満の場合は人によるレビューへ回す

例えば、単一選択問題では次の整合性ルールを適用できます。

correct_answer=C
かつ
option_c_qualityが他の選択肢より低い
  ↓
要レビュー

結果比較

今回の1問における比較結果は次のとおりです。

評価項目	期待値	laya	winnow
正解	C	C	C
技術領域	compute	security	compute
主要サービス	ec2	ec2	ec2
問題種別	cost	performance	cost
コスト最適化	yes	yes	yes
高可用性	no	yes	no
セキュリティ	no	yes	no
性能	no	yes	no

今回の問題に限れば、winnowの方が問題の主題と要件を明確に識別できました。

なぜlayaとwinnowで差が出たのか

今回の検証では、両モデルとも正解のCを選択しました。
一方で、問題の主題や要件の抽出能力には明確な差が見られました。

項目	laya	winnow
正解選択	○	○
技術領域の特定	△	○
主要要件の抽出	△	○
不要要件の排除	×	○
選択肢の差別化	△	○

この結果から、両モデルの設計思想の違いが反映されている可能性があります。

layaは分類寄りの判断を行っているように見える

今回の結果では、layaは正解のCを選択したものの、問題の主題を正しく整理できませんでした。
例えば次のような判定になっています。

primary_domain security
question_type performance

cost_optimization yes
high_availability yes
security_requirement yes
performance_requirement yes
operational_simplicity yes

本来この問題で重要なのは、

EC2
↓
インスタンスメモリ保持
↓
休止状態（Hibernate）
↓
停止中のコスト削減

という関係です。
しかしlayaは複数の要件を同時に重要とみなし、主題を十分に絞り込めていないように見えます。
また、4つの選択肢評価もほぼ同じ値になっていました。

A = 3.28
B = 3.27
C = 3.28
D = 3.26

このことから、layaは細かな比較や要件の優先順位付けよりも、

カテゴリ分類
ラベル付け
Yes/No判定
一次トリアージ

のような軽量な判断タスクに最適化されている可能性があります。

winnowは要件の優先順位付けを行えているように見える

一方のwinnowは、

primary_domain compute
question_type cost

と判定しました。

また、

high_availability no
security_requirement no
performance_requirement no

となっており、問題文に含まれる情報の中から「正解に必要な要件」と「そうではない要件」を切り分けられています。
さらに、選択肢ごとに大きく異なる評価値を返しています。

A = 0.07
B = 1.02
C = 2.43
D = 0.81

これは単純なキーワード一致ではなく、

問題文の要件抽出
AWSサービスとの対応付け
選択肢ごとの差分比較
最適解の選択

という複数段階の判断を行っている可能性を示しています。
少なくとも今回のケースでは、winnowの方が問題文の意図を構造的に捉えられているように見えました。

正答と説明は別の能力である

今回の結果で特に興味深かったのは、

正解を選択できることと、その理由を正しく説明できることは必ずしも同じではない

という点です。

layaは正解のCを選択できましたが、

primary_domain = security
question_type = performance

という、本来の主題とは異なるメタデータを返しました。
もしcorrect_answerだけを評価していた場合、

正解した
↓
理解している

と判断してしまうかもしれません。
しかし実際には、

正答率
技術領域の認識
要件抽出
選択肢比較
確信度
論理的一貫性

はそれぞれ独立した評価軸です。
Decision Modelの評価では、最終回答だけでなく、その回答に至る判断構造も確認する必要があることが分かりました。

現時点での仮説

今回の検証はAWS認定試験の1問のみを対象としたものであり、これだけで一般化はできませんが、現時点では次のような仮説を持っています。

laya
→ 高速・軽量
→ 分類タスク向き
→ 大量処理向き

winnow
→ 推論重視
→ 要件分析向き
→ 判断品質重視

今後は、

Kubernetesイベント分類
Pod障害の一次切り分け
SEV判定
チケットアサイン
運用手順適合性判定
RAG評価結果のレビュー

など、AI Private Cloud運用に近い実データでも検証を行い、この仮説を継続的に確認していきたいと考えています。

AI Private Cloud運用への適用を考える

今回の結果だけで各モデルの適用範囲を確定することはできませんが、次のような使い分けが考えられます。

layaで検証したいユースケース

問い合わせカテゴリ分類
アラート分類
担当チーム振り分け
定型的なYes/No判定
大量データの一次判定

winnowで検証したいユースケース

複数要件を含むチケットの分類
運用手順の適合性確認
インシデントの一次分析
設計レビューの補助
技術試験問題の分類と回答
RAG評価データの判定

実際に運用へ適用する場合は、正答率だけでなく次の指標も確認する必要があります。

推論時間
CPUおよびGPU使用量
メモリ使用量
モデルロード時間
同時実行性能
日本語入力時の精度
誤判定率
未確定回答の検知率
モデル更新時の結果差分
判断結果の再現性

判断モデルを評価して分かったこと

重要だったのは、生成モデルとは異なる評価軸が必要だという点です。

チャットモデルでは回答文の品質が注目されますが、判断モデルでは次の項目が重要になります。

最終回答が正しいか
正しい技術領域を選択できたか
中心となるサービスを特定できたか
問題の主要要件を抽出できたか
不要な要件を排除できたか
判定確率が適切に校正されているか
複数の質問間で論理的一貫性があるか

今回の検証では、correct_answerだけでなく、primary_domainやquestion_typeを追加したことで、単純な正誤だけでは分からないモデルの特徴を確認できました。

今後の検証

今回は1問だけの検証だったため、今後は評価データセットを拡張する必要があります。

想定している次のステップは以下です。

AWS SAAの複数カテゴリから評価問題を選定する
正解と期待メタデータを付与する
layaとwinnowへ同じ問題を入力する
正答率と分類精度を集計する
回答時間とリソース使用量を計測する
質問間の矛盾発生率を確認する
モデルタグとQuestions定義を固定して再現性を確保する

評価対象としては、次の分野を含めたいと考えています。

Compute
Storage
Database
Networking
Security
Operations
Integration
Migration
Analytics
Machine Learning

また、AI Private Cloud運用向けの検証として次のシナリオにも展開できます。

Kubernetesイベントの分類
Pod障害の一次切り分け
SEV判定
運用チケットの担当チーム判定
エスカレーション要否判定
手順書への適合性判定

まとめ

今回は、AI Private Cloud運用チームのセルフホストSLM検証タスクの一環として、次の内容を試しました。

OllayaをKubernetesへデプロイ
AWS認定試験分析用のQuestions JSONを作成
laya版とwinnow版の派生モデルを作成
AWS SAAレベルの4択問題を入力
正解、技術領域、AWSサービス、主要要件を比較

今回の1問では、両モデルとも正解のCを選択しました。

一方、問題の技術領域や主要要件の判定では差が見られました。

laya
  正解: C
  技術領域: security
  問題種別: performance

winnow
  正解: C
  技術領域: compute
  主要サービス: ec2
  問題種別: cost

winnowは期待値に近い判断を返しましたが、選択肢ごとの独立評価では、正解判定との不整合も確認されました。

このことから、判断モデルを運用へ適用する場合は、単に1つの回答だけを見るのではなく、次の設計が必要だと考えています。

回答確率の閾値設定
質問間の整合性チェック
低信頼度回答の人手レビュー
評価データセットによる継続的な精度測定
モデルバージョンとQuestions定義の固定
モデル更新時の回帰テスト

今回の検証で最も興味深かったのは、
「AWS試験に正解したこと」ではなく、
Decision Modelが問題の主題や要件まで構造化して返せたことでした。

生成AIというとチャットやRAGが注目されがちですが、
実際の運用現場には

分類
判定
優先度付け
エスカレーション判断

といった意思決定タスクも数多く存在します。

OllayaのようなDecision Modelが、AI Private Cloud上で動作する運用支援コンポーネントとしてどこまで活用できるのか、今後も評価を続けていきたいと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up