HHVMの型チェッカーを拡張する：カスタム属性を用いた静的解析の自動化
テックリードの私たちがコードレビューで最も恐れるのは、コンパイルエラーでも単体テストの失敗でもない。「型システムの隙間をすり抜け、プロダクションの深部で静かに発生する論理破綻」だ。
Hack言語は、その厳格な静的型付け（Strict Mode）と圧倒的なスループットを誇るHHVM（HipHop Virtual Machine）のJITコンパイルエンジンによって、大規模Webアプリケーションの要塞として機能する。しかし、どれほど高度な型システムであっても、「ビジネスドメイン特有の制約」をネイティブの型だけで完全に表現し尽くすことはできない。
例えば、「この外部APIクライアントを呼び出すメソッドは、必ず事前にサーキットブレーカーのチェックを通っていなければならない」「このデータベース操作メソッドは、必ず特定のトランザクションコンテキスト内から呼ばれなければならない」。これらをうっかり忘れて直接呼び出してしまった場合、ネイティブの型チェッカーは何も文句を言わない。
では、どうするか？ 答えはシンプルだ。HHVMの型チェッカー（hh_client / hh_server）をハックし、独自の静規律を強制するカスタム解析レイヤーを構築すればいい。
今回は、Hackのカスタム属性（Attribute）と静的解析の仕組みを組み合わせ、コンパイルタイムにビジネスルールを強制する「極限まで堅牢な設計パターン」を伝授しよう。
—
1. なぜネイティブの型だけでは不十分なのか？
Hackの `<<__Rx>>`（Reactive Extensions）や `<<__Policyed>>` などのビルトイン属性は、HHVMの型チェッカーと深く統合され、副作用の伝播や権限管理をコンパイル時に担保してくれる。
しかし、自社のドメインロジックやアーキテクチャ上の制約（例：レイヤー間の依存関係違反の検知、特定のセキュリティガード通過の強制）を検知するには、ユーザー定義の属性（User-defined Attributes）と、AST（抽象構文木）を走査する静的解析フックを組み合わせる必要がある。
HHVMの型チェッカーは、コードを実行する前にASTを解析し、型情報や属性情報をメタデータとして保持する。我々はこれを利用し、「特定の属性が付与されたメソッドの呼び出し元には、必ず特定の属性が付与されていなければならない」といった高度な制約を静的に検証できる。
—
2. 実装：カスタム属性による呼び出し制約の自動化
ここでは、実務の現場ですぐに応用できる「セキュリティガード強制システム」を実装する。
要件はこうだ：
1. `<
2. 監査ログ基盤を経由しているメソッドには `<
3. この規約に違反した場合、CI/CDパイプライン上の `hh_client`（あるいはカスタム静的解析スクリプト）がビルドを即座に落とす。
プロダクションコード例
まずは、HackのStrict Modeで記述された堅牢なコンポーネントのコードを見てほしい。
<
namespace Acme\Security;
/
- 監査セキュリティを強制するためのカスタム属性
/
<<__Attribute(Attr::METHOD)>>
class RequiresSecurityAudit implements \HH\ClassAttribute {
public function __construct(public string $reason) {}
}
/
- 監査コンテキスト下にあることを示す属性
/
<<__Attribute(Attr::METHOD)>>
class AuditedContext implements \HH\ClassAttribute {}
/
- データベースの機密操作を扱うリポジトリ
/
final class SecureVaultRepository {
/
- 機密データを取得するメソッド。
- このメソッドは、必ず監査コンテキストから呼ばれなければならないというビジネス制約を持つ。
/
<
public async Task
// 実際にはここでセキュアなDBクエリを実行
return “Encrypted_CC_Data_For_{$userId}”;
}
}
/
- アプリケーションのサービス層
/
final class PaymentService {
private SecureVaultRepository $vault;
public function __construct(SecureVaultRepository $vault) {
$this->vault = $vault;
}
/
- 正しく監査コンテキストを通過しているケース
/
<
public async Task
// [OK] <
return await $this->vault->fetchUserCreditCardAsync($userId);
}
/
- 規約違反のケース（静的解析で弾くべきコード）
/
public async Task
// [ERROR] 監査コンテキストなしで機密メソッドを直接呼び出している！
return await $this->vault->fetchUserCreditCardAsync($userId);
}
}
—
3. カスタム静的解析器の設計（HHVM ASTの活用）
上記の `processPaymentDangerousAsync` のような違反を、実行時ではなくコンパイル時（CIの静検知フェーズ）で検知するために、HackのASTパーサーを利用したカスタムチェッカーを構築する。
Hackエコシステムでは、`hh_client` のJSON出力や、Hack自身で書かれたASTパーサー（例: Facebookの内部ツールやオープンソースのASTビジターパターン）を使用してコード構造を解析できる。
以下は、ASTを走査して `<
<
namespace Acme\StaticAnalysis;
/
- 簡易的なAST走査によるカスタムリンカーの例
- ※実際にはHHVMのAST JSON出力や定部分析ライブラリと結合する
/
final class SecurityRuleValidator {
public static function validateCallGraph(
ImmMap
ImmMap
): ImmVector
$violations = Vector {};
foreach ($methodCallGraph as $caller => $callees) {
$callerHasAudit = $methodAttributes->get($caller)?->contains(‘Acme\Security\AuditedContext’) ?? false;
foreach ($callees as $callee) {
$calleeRequiresAudit = $methodAttributes->get($callee)?->contains(‘Acme\Security\RequiresSecurityAudit’) ?? false;
if ($calleeRequiresAudit && !$callerHasAudit) {
$violations->add(
“Architectural Violation: Method ‘{$caller}’ calls ‘{$callee}’ which requires security audit, but ‘{$caller}’ lacks <
);
}
}
}
return $violations->immutable();
}
}
このバリデーターをCIパイプライン（GitHub ActionsやArcanist等）の `hh_vm` 実行前後に組み込むことで、アーキテクチャの劣化を完全かつ機械的に阻止できる。
—
4. テックリードからの実務アドバイス：パフォーマンスと運用の注意点
このアプローチをプロダクション導入する際、以下のポイントを絶対に忘れないでほしい。
1. 型チェッカーのキャッシュを汚染しないこと
カスタム属性やリフレクション（`ReflectionMethod` 等）をランタイムの動的処理で多用すると、HHVMのJIT最適化（Type Inference）の恩恵をスポイルし、パフォーマンスが劣化する。属性の読み取りや検証は、必ずコンパイルタイム（静的解析フェーズ）で完結させ、ランタイムにはオーバーヘッドを持ち込まない設計を徹底すること。
2. エラーメッセージは「次にどうすべきか」を明確に書くこと
静的解析でエラーを検知した際、単に `Violation detected` と出すのではなく、上のコード例のように「どのメソッドが原因で、どの属性を付与すべきか」を開発者が1秒で理解できる粒度でメッセージを構築すること。優れた開発者体験（DX）こそが、厳格なルールをチーム全体に定着させる最大の秘訣だ。
—
結び
Hackの静的型システムとHHVMの圧倒的な実行速度は、適切に飼い慣らせば、巨大なWebアプリケーションベースを無敵の要塞へと変貌させる。
ネイティブの型に縛られず、カスタム属性と静的解析を組み合わせることで、「人間に依存しないコードの品質保証」が手に入る。
さあ、今日のコードレビューから、曖昧な「口頭のルール」を廃し、コード自体にルールを語らせよう。