Kiro-CLIで生成したClaude Opus 4.5のコードを、Sonnet 4.5 / Haiku 4.5と比較検証してみた
前回の記事では、Amazon Linux 2023環境にKiro-CLIを導入し、無料のBuilders IDでClaude Opus 4.5が利用可能になったことを確認しました。
今回はその続きとして、「Opus 4.5は実際にどのようなコードを書くのか」を検証しました。
以前、Q DeveloperとClaude 3.5 Sonnet / Haikuを使って「テトリス風ゲーム」を作成させ、そのコード品質を比較する検証を行いました。
回は同じプロンプトを Claude Opus 4.5 に投げ、生成されたコードを、前回作成されたコード（Haiku 4.5版、Sonnet 4.5版）との比較・分析を行いました。
検証条件
- プロンプト:
AWSをテーマにしたテトリスゲームを作りたいです。HTML/CSS/JavaScript（ライブラリ不使用）で開発してください。
テーマの詳細:
ブロック（テトリミノ）は、EC2やS3などAWSサービスのイメージカラーを使ってください。
背景はAWSコンソールのようなデザインにしてください。
ゲームの仕様:
スコア、レベル、次のブロックを表示するUIをください。
操作はキーボードの矢印キー（左右移動、回転）、スペースバー（ハードドロップ）で行えるようにしてください。
ゲームオーバーの表示も実装してください。
コードの形式:
index.html, style.css, script.js の3つのファイルに分けてコードを生成してください。
テトリスゲームのコード生成の所要時間を測定し、コード生成が完了した後、最後に報告してください。
- 実行環境: Kiro-CLI (v1.20.1) on Amazon Linux 2023
- モデル: claude-opus-4.5 (via AWS Builders ID Free Tier)
実装の比較分析
3つのモデルが生成したコードを「アーキテクチャ」「ロジック」「機能・デザイン」の3点で、比較・分析しました。
1. アーキテクチャの設計思想
各モデルで明確に設計思想が異なりました。
| モデル | 設計スタイル | 特徴 |
|---|---|---|
| Haiku 4.5 | 完全なOOP | すべてを Game クラスにカプセル化。状態管理が厳格。 |
| Sonnet 4.5 | 関数型 + オブジェクト | クラス不使用。純粋関数とオブジェクトリテラルで構成。軽量。 |
| Opus 4.5 | ハイブリッド | 状態はグローバル、部品（Piece）のみクラス化。実用性重視。 |
Opus 4.5の実装（ハイブリッド）:
Opusは「完全にクラス化する手間」と「すべてグローバルにする乱雑さ」の中間を選択しました。
Piece クラスを作成しつつ、盤面（Board）はグローバル変数として扱う設計は、小規模な単一ファイルのスクリプトとしては可読性と保守性のバランスが良い判断と言えます。
// Opus 4.5: グローバル変数とクラスのハイブリッド
let board = Array(ROWS).fill().map(() => Array(COLS).fill(0)); // 盤面はグローバル
class Piece { // ロジックを持つ部品はクラス化
constructor(type) {
this.type = type;
this.shape = SHAPES[type];
// ...
}
}
2. ゲームロジックの堅牢性
最も差が出たのが、移動時の衝突判定ロジックです。
- Haiku 4.5: 移動後に判定し、衝突していたら戻す実装。JSON変換によるディープコピーを多用しており、パフォーマンス面に懸念あり。
- Sonnet 4.5: 引数
offsetX, offsetYを受け取り、移動先の座標を事前チェックする実装（最も効率的）。 - Opus 4.5: 自己完結型の判定と戻り値による制御。
Opusの実装は、move() メソッドが成功可否（boolean）を返す点が特徴的です。これにより、呼び出し元（ゲームループ）での制御が非常に直感的になっています。
// Opus 4.5の実装: 戻り値で成功/失敗を返す
move(dx, dy) {
this.x += dx;
this.y += dy;
// 移動してみてダメならロールバックして false を返す
if (this.collides()) {
this.x -= dx;
this.y -= dy;
return false;
}
return true; // 移動成功
}
3. 機能とUXへの配慮
「テトリス風ゲーム」という曖昧な要件に対し、どこまで気を利かせた実装をしてくるかを確認しました。
- Opus 4.5:
- 〇 ソフトドロップ実装: 唯一、下矢印キー（
ArrowDown）での高速落下に対応していました。 - 〇 即時描画: キー入力イベント内で
drawBoard()を呼び出すため、操作のレスポンスが良いです。 - 〇 デザイン: フォントに
Amazon Emberを指定するなど、最も「AWSっぽさ」を意識したデザインでした。
- 〇 ソフトドロップ実装: 唯一、下矢印キー（
- Haiku 4.5:
- 〇 レスポンシブ: スマホレイアウトに対応していましたが、ゲームオーバー後のループ制御にバグがありました。
- Sonnet 4.5:
- 〇 配色: 7種類のミノ全てに異なるAWSサービスカラー（Lambda=Green, S3=Blue等）を割り当てるこだわりが見られました。
Opus 4.5 の性能考察
今回の比較から見えてきた Claude Opus 4.5 のコーディング特性は以下の通りです。
- 「仕様の隙間」を埋める提案力:
指示に含まれていない「ソフトドロップ」の実装や、APIとしての戻り値設計など、「ユーザーが本来求めているであろう完成形」を想像して補完する能力が高いです。 - 実用的なアーキテクチャ選定:
典型的なOOP（Haiku）でも、シンプルな関数型（Sonnet）でもなく、「小規模なゲームアプリとして最もメンテナンスしやすい構造」を一発で出力しました。
まとめと今後の課題
今回の検証において、Opus 4.5 はUXと保守性を両立した質の高いコードを生成することを確認しました。
なお、今回の比較・分析作業においては、その比較の観点整理やコードの特性分析の補助として Gemini 3.0 を利用しています。
しかし、今回の比較には一点、留意すべき環境差があります。
- Haiku 4.5 / Sonnet 4.5: 前回の検証において Proライセンス（有償） 環境で実行
- Opus 4.5: 今回 Builders ID（無料・実験的サポート） 環境で実行
これらは「異なる土俵」での評価となっており、無料枠特有の制限（スループットや隠れたパラメータ調整など）が結果に影響を与えている可能性も否定できません。本来のポテンシャルを出し切れていない可能性もあれば、逆に実験版として特別に調整されている可能性もあります。
今回の結果のみから Kiro の Opus 4.5の完全な実力を断定するのは時期尚早です。今後、IAM Identity Center連携（Proライセンス）でのOpus 4.5サポートが開始された暁には、同一条件下で、より適切なプロンプトでの追試験も実施してみたいと思います。
