A/Bテスト結果：oh-my-claudecodeフックはClaude Codeのパフォーマンスに最小限の影響しか示さず

実験の設定と方法論

ある開発者が、oh-my-claudecodeの動的フックがClaude Codeのパフォーマンスに与える影響を評価するため、シンプルなA/Bテストを実施しました。この実験ではClaude Sonnet 4.6を使用し、同じコーディングタスクを合計6回実行：OMCフックONで3回、OMCフックOFFで3回行いました。すべての実行で同一のプロンプト、セッションフロー、マシン環境を使用しました。

タスクは、単一の継続セッションでMarkdownエディターを一から構築し、アプリの実装、テストの作成と実行、バグ・セキュリティ・アクセシビリティ問題のレビューと修正、そして再度テストを実行するという内容でした。目標は完璧なコードを生成することではなく、フックがClaudeの動作に意味のある変化をもたらすかどうかを測定することでした。

主な結果

• コード品質：同一スコア（OFFもONも15.0/20）
• 総コスト：文字通り同じ（両条件とも$5.56）
• 総トークン数：フックONでわずかに低い（6.48M vs OFF 6.76M）
• 実時間：フックONの方が平均的に速い（1,673秒 vs OFF 2,152秒）
• ツール呼び出し：フックONでわずかに少ない（37.0回 vs OFF 40.7回）

注目すべき観察事項

SessionStartフックは、最初のプロンプトでキャッシュ読み取りトークンを大幅に増加させました：フックONで424K、フックOFFで195K（117%増）。しかし、この追加コンテキストは、この特定のタスクにおいてより良い出力にはつながりませんでした。興味深いことに、プロンプト3までには、フックOFFの方がフックONよりも多くのキャッシュ読み取りを使用していました。

実験のリポジトリはhttps://github.com/ej31/omc-hook-experimentで公開されています。

開発者の考察

開発者は、動的フックは単一セッションのコーディングタスクにおいて「魔法の高品質コードボタン」ではないと結論付けました。Claudeは静的指示でも十分に機能するためです。フックに関連する利点は、通常の実行間の変動に埋もれるほど小さく見えます。より大きな一定のオーバーヘッドは、動的フックの動作だけでなく、OMCの静的フットプリント（MCPツール定義、スキル、エージェントカタログ）から生じている可能性があります。

重要な点として、この実験はフックの動作のみをテストしており、より広範なOMCエコシステムが大規模なマルチセッションワークフローで有用かどうかは検証していません。開発者は、oh-my-claudecodeを完全に削除し、ClaudeにSnakeゲームを一から構築させることで、さらなるテストを計画しています。