目次
1.はじめに
最近のAWS関連で以下2つのニュースがありました。
AWS Top Engineersの前提としてlevel300以上の活動が必要となります。
この2つのニュースからの思い付きなのですが、過去投稿しているQiitaの記事について、
新しくリリースされたClaude Sonnet 4.6とClaude Sonnet 4.5にレベル判定してもらい、評価を比較してみようと思います。
2.前提
使用するモデル
- Claude Sonnet 4.6
- Claude Sonnet 4.5
やり方
- AmazonBedrockでシステムプロンプトに以下を入力し、比較モードを使用して評価を確認する
システムプロンプト
あなたはAWS Top Engineers 2026の審査を支援するアウトプットレベル判定のプロフェッショナルです。
以下の基準に従い入力された内容のレベル判定をしてください。
基準：
Level 100 : AWS サービスの概要を解説するレベル
Level 200 : トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル
Level 300 : 対象のトピックの詳細を解説するレベル
Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル
※レベルの基準は以下クライテリアに記載があります。
比較モードのイメージは以下のような形です。
3.検証
対象記事①
評価
| モデル | 評価 |
|---|---|
| Claude Sonnet 4.6 | level 300 |
| Claude Sonnet 4.5 | level 300 |
Claude Sonnet 4.6
レベル判定：Level 300
判定理由
Level 300（対象トピックの詳細を解説するレベル） と判定します。
評価ポイント
Level 300相当と判断した根拠：
| 観点 | 内容 |
|---|---|
| 技術的深度 | 単なる概要紹介に留まらず、推論方式を3種（単一リージョン・地理的クロスリージョン・グローバルクロスリージョン）に分類し、それぞれの動作原理と制約を詳細に解説している |
| 制約・注意点の明示 | フォールバック制御不可、CloudTrailでの実行リージョン確認不可、アプリケーション推論プロファイルの制限など、実装・運用上の制約を具体的に記載している |
| 実装コードの提示 | モデルIDの指定方法の違い（jp./global.プレフィックス）をコードで示しており、実践的な知識を提供している |
| ユースケース別の設計判断 | 金融・医療・防衛など業界要件に応じたモデル選定ケースを整理し、メリット・デメリットを比較している |
| 背景考察 | 最新モデルがクロスリージョン前提となっている技術的・ビジネス的背景を考察している |
Level 400に届かなかった理由：
- 複数のAWSサービスを組み合わせたアーキテクチャ設計（例：セキュリティ統制、コスト最適化との組み合わせ）への言及が限定的
- 実際の検証結果・測定データ（レイテンシ、スループット比較等）の提示がない
- 推論プロファイルとIAMポリシー、VPC設計等との統合アーキテクチャへの踏み込みがない
総評
Amazon Bedrockの推論方式を地理的ガバナンス要件という実務的な切り口で整理しており、AWSドキュメントの一次情報を参照しながら独自の分類・考察を加えている点が評価できます。実務での設計判断に直結する内容であり、Level 300として質の高いアウトプットです。
Claude Sonnet 4.5
アウトプットレベル判定結果
判定レベル: Level 300
判定理由
Level 300と判定した根拠
-
特定トピックの詳細な技術解説
- Amazon Bedrockの推論方式(単一リージョン、地理的クロスリージョン、グローバルクロスリージョン)について、それぞれの動作原理と制約を詳細に解説
- 推論プロファイルの仕組みやフォールバック動作など、内部的な挙動まで踏み込んだ説明
-
実装レベルの技術情報
- 実際のPythonコード例を用いた各推論方式の呼び出し方法の違いを明示
- モデルIDと推論プロファイルの指定方法の具体的な実装パターンを提示
- IAMロールの権限設定など、実装上の注意点も言及
-
具体的なユースケース分析
- 金融・公共・医療系、防衛・エネルギー系など、業界特性に応じた3つの具体的なケーススタディを提示
- 各ケースにおけるメリット・デメリットを技術的・ビジネス的観点から詳細に分析
-
制約事項の深い理解
- CloudTrailでの追跡不可能性など、サービスの技術的制約を明確に指摘
- 推論プロファイルのカスタマイズ不可能性とその影響を説明
Level 400に至らない理由
- 複数サービスを組み合わせたアーキテクチャ全体の設計や実装には踏み込んでいない
- システム全体のレジリエンス設計やマルチリージョン戦略など、より広範なアーキテクチャ的な考察が限定的
- モニタリング、ロギング、コスト最適化など、運用面での包括的な実装パターンの提示がない
補足コメント
本アウトプットは、Amazon Bedrockの推論方式という特定トピックに関して、技術的詳細、実装方法、ユースケース分析を組み合わせた質の高いLevel 300コンテンツです。実務での意思決定に直接活用できる実践的な内容となっています。
対象記事②
評価
| モデル | 評価 |
|---|---|
| Claude Sonnet 4.6 | level 200 |
| Claude Sonnet 4.5 | level 200 |
Claude Sonnet 4.6
レベル判定：Level 200
判定理由
該当する要素：
- Amazon Bedrockの推論プロファイル（クロスリージョン推論プロファイル／アプリケーション推論プロファイル）という特定機能に焦点を当てており、サービス概要の紹介に留まらない（Level 100超）
- 公式ドキュメントを参照しながら機能の仕様・制約（「単一リージョンモデルのサポート」の有無、
inferenceTypesSupported: INFERENCE_PROFILEなど）を確認・解説している - AWS CLI／CloudShellを用いた実際の操作手順と、発生したエラーの原因調査（
ValidationExceptionの意味、モデルごとのオンデマンド対応可否）を示している - ベストプラクティス的な示唆（単一リージョン推論にはサポートモデルの確認が必須）を提供している
上位レベルに達しない理由：
- アーキテクチャ設計やサービス間連携（例：Lambda・API Gatewayとの組み合わせ、コスト最適化設計など）には踏み込んでいない（Level 400未満）
- アプリケーション推論プロファイルの詳細な内部動作・パラメータの網羅的解説や、独自の深い技術的考察は限定的（Level 300未満）
- 主に公式ドキュメントの読み解きと検証結果の共有であり、入門知識を前提とした機能・制約の解説の範囲に収まっている
総評
実際にAPIを叩いて検証し、失敗から仕様の正しい理解を導く構成は読者にとって実用的です。Level 200として十分な内容ですが、例えば「なぜ特定モデルがクロスリージョン推論のみサポートなのか（Bedrockのキャパシティ管理の観点）」や「代替アーキテクチャ案」などを加えると、Level 300に近づきます。
Claude Sonnet 4.5
このアウトプットのレベル判定を行います。
レベル判定: Level 200
判定理由:
Level 200と判断した根拠:
-
ベストプラクティスと制約の解説
- Amazon Bedrockの推論プロファイル機能について、システム定義とアプリケーション推論プロファイルの違いを明確に説明
- 実際の検証を通じて、制約事項(単一リージョンサポートの有無)を実証的に示している
-
サービス機能の実践的な活用
- AWS CLI/APIを使った具体的な実装手順を提示
- CloudShellでの実行例を含む、実務的なアプローチを示している
- エラーハンドリングとトラブルシューティングのプロセスを記載
-
前提知識の想定
- Amazon Bedrockの基本的な理解を前提としている
- AWS CLIやマネジメントコンソールの基本操作ができることを前提
Level 300に至らない理由:
-
詳細な技術的深掘りの不足
- 推論プロファイルの内部動作メカニズムには言及していない
- クロスリージョン推論の負荷分散アルゴリズムなど、より深い技術的詳細がない
- リージョン間のレイテンシーやコスト最適化の観点が含まれていない
-
アーキテクチャ的な考察の欠如
- 単一リージョン vs クロスリージョンの設計判断基準が示されていない
- 可用性やパフォーマンスへの影響分析がない
Level 400でない理由:
- 複数サービスを組み合わせた実装例がない
- システム全体のアーキテクチャ設計には踏み込んでいない
- 本番運用における監視、ログ、コスト管理などの包括的な実装例がない
総評:
失敗事例を含めた実践的な検証記事として、入門者が陥りやすい誤解を解消する価値があります。ドキュメント参照、実コマンド実行、エラー解析というトラブルシューティングの流れが明確で、Level 200として適切な内容です。ただし、より深い技術的考察や設計判断の指針があればLevel 300に到達する可能性がありました。
対象記事③
評価
| モデル | 評価 |
|---|---|
| Claude Sonnet 4.6 | level 200 |
| Claude Sonnet 4.5 | level 200 |
Claude Sonnet 4.6
レベル判定：Level 200
判定理由
Level 200相当と判定します。以下にその根拠を示します。
評価ポイント
✅ Level 200に合致する要素
| 観点 | 内容 |
|---|---|
| 前提知識の活用 | クロスリージョン推論・地理的クロスリージョン推論の概念を整理し、ドキュメントを引用して解説している |
| ベストプラクティスへの言及 | ガバナンス・データレジデンシーの観点からモデル利用を制御するという実務的な動機が示されている |
| サービス機能の解説 | 推論プロファイルの仕組み、CloudTrailによる検証など、機能の使い方を具体的に説明している |
| 注意点・落とし穴の共有 | 「推論プロファイルは自作不可」「Claude 4.5はクロスリージョン推論前提」などの誤解しやすいポイントを指摘している |
⚠️ Level 300以上に届かない理由
| 不足している観点 | 説明 |
|---|---|
| 技術的深掘りの不足 | 推論プロファイルの内部動作（ルーティングロジック、レイテンシへの影響等）への踏み込みがない |
| 検証の不完全さ | 大阪リージョンでの動作確認が未達成のまま「調査不足」として終わっており、技術的考察が薄い |
| IAM/SCPによる制御等の代替手段比較がない | ガバナンス観点での実装を語るなら、SCPやIAM条件キーによるリージョン制限との比較検討があるとより深い内容になる |
| アーキテクチャへの展開がない | Level 400相当の複数サービス連携・実装パターンの提示はない |
総評
入門者がつまずきやすいポイント（推論プロファイルの制約、Claude世代によるモデルの違い）を丁寧に整理しており、実務ユースケースに基づいた質の高いLevel 200コンテンツです。Level 300を目指すには、「なぜそうなるか」の技術的メカニズムや、代替実装手段との比較考察をさらに加えることを推奨します。
Claude Sonnet 4.5
アウトプットレベル判定結果
判定レベル: Level 200
判定理由
Level 200と判断した根拠
-
ベストプラクティスの解説
- データガバナンスの観点からクロスリージョン推論の制限方法を解説
- 実際のビジネス要件（データレジデンシー、コンプライアンス）に基づいた実装方法を提示
-
サービス機能の詳細な説明
- Amazon Bedrockのクロスリージョン推論機能について、公式ドキュメントを引用しながら説明
- 推論プロファイルの仕組みと制約事項を明確に解説
- Claude 3.5 SonnetとClaude 4.5 Sonnetの違いにも言及
-
実践的な手順の提供
- コンソールでの具体的な設定手順をスクリーンショット付きで説明
- CloudTrailでの検証方法まで含めた実装例を提示
Level 300に達しない理由
- 複数サービスの連携やアーキテクチャレベルの深い技術解説には至っていない
- API実装やSDKを使った詳細なコード例が含まれていない
- 推論プロファイルの内部動作メカニズムの深掘りまでは行っていない
- パフォーマンスチューニングやコスト最適化の観点が不足
Level 100ではない理由
- 単なるサービス概要説明ではなく、特定のユースケース（日本リージョン限定）に対する実装方法を解説
- 注意点や制約事項を含めた実用的な情報を提供
- 実際の動作確認とログ検証まで実施
総評
本コンテンツは、Amazon Bedrockの基本的な理解を前提に、クロスリージョン推論という特定機能のベストプラクティスを実践的に解説しており、Level 200相当の技術コンテンツとして適切です。
対象記事④
評価
| モデル | 評価 |
|---|---|
| Claude Sonnet 4.6 | level 200 |
| Claude Sonnet 4.5 | level 300 |
Claude Sonnet 4.6
レベル判定：Level 200
判定理由
Level 200 と判断した根拠
トピックの入門知識を前提とした上で、ベストプラクティスとサービス機能を解説するレベルに該当します。
| 評価軸 | 内容 |
|---|---|
| 前提知識の活用 | GitLab・CodeCommit・IAM・CloudTrailの基本知識を前提に議論が展開されている |
| 設計判断の説明 | 単純な手順紹介にとどまらず「なぜミラーリングか」「なぜ一方向か」という設計判断の根拠が示されている |
| ベストプラクティスの言及 | IAMユーザの最小権限付与、IAMロール利用不可の制約の説明など、セキュリティ観点のベストプラクティスに触れている |
| 実構成の検証 | 実際の設定手順・CloudTrailログの確認まで含めた実証がある |
Level 300/400 に届かなかった理由
| 不足している要素 | 詳細 |
|---|---|
| 技術的深度 | CloudTrailのイベント内容の詳細分析、SCPによる制御ポリシーの具体例、CodeCommitのIAMポリシー設計の詳細などには踏み込んでいない |
| 複数サービスの統合設計 | CodePipeline・EventBridgeなどAWS CI/CDサービスとの連携設計（Level 400相当）には言及なし |
| 運用上の考慮 | ミラーリング失敗時のアラート設計、認証情報のローテーション、Secrets Managerとの連携等が未考察 |
| 比較・代替手段の深掘り | AWS CodeConnectionsやGitHub Connectionsとの比較など、代替アーキテクチャの詳細検討がない |
総評
CodeCommit復活というタイムリーな題材に対し、GitLabとの役割分担という実践的な設計視点を持って構成を検討・検証している点は評価できます。設計判断の根拠を明示している点でLevel 100を超えていますが、各サービスの詳細動作・複合アーキテクチャ・運用設計への踏み込みを深めることで Level 300〜400 を目指せる内容です。
Claude Sonnet 4.5
このアウトプットのレベル判定を行います。
レベル判定: Level 300
判定理由:
Level 300と判定した根拠:
-
特定トピックの詳細な技術解説
- GitLabとCodeCommitのミラーリング構成という特定のアーキテクチャパターンを詳細に解説
- 一方向ミラーリングを選択する技術的根拠を明確に説明
- 実装手順を具体的なスクリーンショット付きで提示
-
複数の設計選択肢の比較検討
- 3つの代替案(GitLab単体/CodeCommit完全移行/成果物のみ管理)を技術的観点から評価
- 双方向vs一方向ミラーリングのトレードオフを詳細に分析
- IAM認証方式(HTTPS vs SSH)の選択理由を説明
-
AWS統制要件との技術的整合性
- IAM、CloudTrail、Organizations/SCPとの統合要件を具体的に解説
- 最小権限の原則に基づくIAMユーザ設計の考慮
- セキュリティリスクの限定化戦略を提示
-
実装の詳細と検証
- 実際の設定手順を段階的に解説
- ミラーリング動作の検証とCloudTrailログの確認
- 5分以内の同期という動作仕様の明示
Level 400に至らない理由:
- 複数AWSサービス(CodePipeline、CodeBuild等)との連携アーキテクチャまでは展開されていない
- 大規模環境での運用設計(複数リージョン、多数リポジトリ管理)には言及なし
- 障害時のフェイルオーバーやディザスタリカバリ戦略の詳細がない
- GitLab CI/CDとAWS CI/CDパイプラインの統合アーキテクチャには踏み込んでいない
結論:
特定の技術トピック(GitLab-CodeCommitミラーリング)について、設計判断の根拠、実装の詳細、セキュリティ考慮事項を包括的に解説しており、Level 300の基準を満たしています。
4.まとめ
概ね評価は変わらないのかなーと思っていたのですが、最後の対象記事④でモデルごとにlevelの違いがでました。
また、levelの判定が同じ記事でも個人的には4.6の方が内容に踏み込んでいるような感じがします。
実際のレベル判定がどのように行われているのかわからないというのと、今回はシステムプロンプトのみ利用した簡易評価なのであくまで参考評価となりますが、いろんなモデルに判定させると面白いかもしれませんね。