なぜ、誰もが Opus 5.5 で作るモーショングラフィックスは、どれも似たような仕上がりになってしまうのでしょうか？
中央に大きく配置されたテキスト、どこかで見たグラデーション背景、すべての要素が順にフェードインし、最後にロゴがペタッと現れる……。

@N01ennn 氏の長文ポストを読んで、ようやく腑に落ちました。プロンプトそのものは全体のほんの一部に過ぎません。最終的な動画のクオリティを左右するのは、モデルの周囲を包む「ルール」「検証機構（センサー）」「実行ループ」の設計なのです。最近トレンドになっている「モーションデザイン」「ハーネスエンジニアリング（Harness Engineering）」「ループエンジニアリング（Loop Engineering）」は、本質的にすべて同じ構造を指しています。

引用元の投稿：https://x.com/i/status/2107826459804840072

構造を分解して解説します。

1. モーションはどうやって生まれているのか

Opusが出力しているのは動画ではなく「コード」です。任意の時刻 $t$ を受け取ると、その瞬間の完璧に決定論的なフレームを描画する draw(t) 関数を記述させています。ヘッドレスブラウザがこれをフレーム単位でキャプチャし、ffmpegがそれらの連番画像を1本のMP4動画として結合します。
各フレームの見た目は時刻 $t$ だけで決まり、同じフレームを何千回描画しても1ピクセルの狂いもなく同一の結果が得られるため、「自動テストによる機械検証」が可能になります。
これは同時に、Claude Codeのような「コマンドを実行できる環境」が必須であることを意味します。ブラウザのチャット窓にコードを出力させるだけでは、フレームの自動レンダリングも自己検証もできません。

2. ハーネス（Harness）：モデルを統制するルールとセンサー

マーティン・ファウラー氏のブログにある Birgitta Böckeler 氏のフレームワークが元になっており、大きく2つの柱で構成されます：

  • guide（事前ガイド）：生成前に課す制約条件。ルールファイル、デザインシステム、絵コンテ、ブランドアセット。
  • sensor（事後センサー）：生成後に走らせる自動検証。スクリプトによる決定論的チェック（フレームハッシュの一致、ループ境界の滑らかさ、ユニットテスト）に加え、モデル自身の視覚推論によるチェック（Opusに自身がレンダリングした連番サムネイルを見せて採点させる）。

不具合やダサい演出に遭遇するたびにルールファイルへ「禁止事項」を書き足していくことで、システムは使えば使うほど堅牢に育っていきます。

3. ループ（Loop）：合格点に達するまで自律的に回し続ける

この概念が注目され始めたのは今年6月頃のことです。ある論文の比喩が非常に的を射ています——「ハーネスがエンジンなら、ループはドライバーである」。
AIへの権限委譲の度合いによって、ループは4段階に分類されます：

  1. 人間が毎ラウンド出力を目視確認する
  2. 終了判定（ゴール条件）の判断をモデルに委ねる
  3. ループの起動タイミング自体を自動化する
  4. プロンプトの生成・改善すらもモデルに任せる

Claude Codeの /goal コマンドは第2段階に相当します。各ラウンドの終了時に軽量モデルが「完了基準を満たしたか」を判定し、未達成なら自動で修正を継続します（最大ラウンド数の上限設定も可能）。

4. すぐに真似できる4つの実践ステップ

  1. CLAUDE.md または AGENTS.md を書く：命名規則、デフォルトでやりがちな手抜き癖の禁止リスト、明確な「完了の定義（Definition of Done）」。
  2. 2重の検証センサーを設ける：ファイル変更時に即走る自動スクリプトと、独立したレビュー指示を与えたモデル自己検証。
  3. 明確なゴールで包み込む：機械判定できる客観的な終了条件 ＋ 最大ループ上限 ＋ 進捗がない場合の打ち切り条件。
  4. 同じ問題が2度起きたら「ルールとセンサー」を直す：その場のコードを手動修正して終わらせず、根本のルールファイルをアップデートする。

よくある失敗パターン：
モデル自身の「主観的な感覚」だけで修正を繰り返させても、品質はほとんど向上しません。テストやスキーマといった「客観的なハードバリデーション」と接続して初めて、劇的な品質向上が得られます。スクリプト化できる基準は、すべてスクリプトとして書き落としましょう。

5. なぜ Opus 5.5 なのか

公式ベンチマークによると、多くのタスクで最高水準に匹敵する実力を持ちながら、全体のAPIコストは従来のOpus 5より40%削減されています。コストが安いからこそ何度もループを回すことができ、画像認識（Vision）が強力だからこそ自分自身のレンダリング結果を正確に自己批評できるのです。

6. どんな用途に向いているか

UIのインタラクションデモ、キネティックタイポグラフィ、データの動的ビジュアライゼーション、プロダクトの機能解説動画などに抜群の威力を発揮します。EC事業者であれば、商品LPのアニメーション訴求や機能説明クリエイティブにそのまま即戦力として投入できます。
リアルな実写人物の動画を生成したい場合は、素直に動画生成専用モデルに任せるのが得策です。

もしあなたの CLAUDE.md に最初の「禁止項目」を書き加えるとしたら、何を禁止しますか？