【テクニカル・上級編】Hackの『Attribute』を活用したカスタム静的解析ルールの作成 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hackを掌握する極限の知見：User Attributesと型チェッカーの境界線を突破するカスタム静的解析

世の多くのプログラマは、静的型チェッカーを「バグを早期発見するための便利なLinter」程度に捉えている。だが、HHVM（HipHop Virtual Machine）の底流を支えるHack言語の真のポテンシャルは、そのような表層的なものではない。厳格な静的型付け（`<<__Strict>>`）と、AST（抽象構文木）レベルで動作する型チェッカーの協調動作こそが、この言語の核心だ。

今回は、HackのUser Attributes（ユーザー定義属性）を起点とし、標準の型チェッカーの枠組みを拡張して「独自のビジネスロジック制約」をコンパイル時（正確には型チェック時）に強制する極限のアーキテクチャを解説する。

汎用的なツールに頼るな。型システムは自らハックし、支配するものだ。

—

1. HHVMとTypecheckerの内部メカニズム：Attributeの正体

HHVMのパイプラインにおいて、Hackのコードはまず `hh_server` が管理する型チェッカー（Typechecker）によって精査される。この型チェッカーはデーモンとして常駐し、ファイルシステム変更をインクリメンタルに検知してASTを再構築、型推論と制約伝播（Constraint Propagation）を一瞬で行う。

ここで重要になるのが User Attributes だ。`<<__EntryPoint>>`, `<<__Override>>`, `<<__ConsistentConstruct>>` といった言語組み込みの属性は、単なるメタデータではない。これらはHHVMのバイトコード生成（`hhbc`）および型チェッカーに対する「静的解析のトリガー」として機能している。

我々が定義するカスタム属性もまた、型チェッカーに対して特定の制約や振る舞いを強制するための強力なフックとなり得る。

なぜランタイムではなく静的解析なのか？

動的言語の残滓を引きずるPHPerは、属性（PHP 8のAttributesなど）をリフレクションを用いて実行時に評価しがちだ。しかし、ランタイムでのリフレクションはメモリを消費し、バイトコードのキャッシュ効率を悪化させ、何より「バグが本番環境に到達するのを許す」という致命的な怠慢を生む。

真のエンジニアは、型チェッカーのフェーズで不整合を完全に粉砕する。

—

2. 実装：ドメイン固有の制約を強制するカスタムAttribute

例として、金融システムや高スループットな決済基盤を想像してほしい。ここでは「特定の機密データを扱うメソッドには、必ず監査ロギングのラッパーが適用されていること」「特定の機密フィールドへの直接アクセスは、認可レイヤのコンテキスト内でのみ許可されること」を、型チェッカーに保証させたいとする。

これを実現するカスタムAttributeと、それを検証するカスタム静的解析の設計を見ていこう。

ステップ1: 属性の定義

Hackでは、`<<__Attribute>>` メタ属性を付与したクラス（またはインターフェース）として属性を定義する。

namespace HackEngine\Security\Attributes;

この属性が付与されたクラスやメソッドは、
静的解析レイヤで厳格なセキュリティ監査の対象となる。

/
<<__Attribute( // 使用可能なターゲットを制限する（クラス、メソッド、プロパティ） Shapes::to_array( \HH\AttributeTarget::CLASS | \HH\AttributeTarget::METHOD | \HH\AttributeTarget::PROPERTY ) )>
final class AuditedSecurityBoundary {
public function __construct(
public string $riskLevel = ‘HIGH’,
public bool $requireMFA = true,
) {}
}

ステップ2: ビジネスロジックへの適用

次に、実際のコードベースでこの属性を要塞のように配置する。

namespace HackEngine\Domain\Payment;

use namespace HackEngine\Security\Attributes;

<>
final class PaymentProcessor {

public function __as_strict_type(float $amount): void {
// 決済処理のコアロジック
}

<>
public function refund(string $transactionId): bool {
// 返金処理
return true;
}
}

—

3. 型チェッカーの限界を超える：カスタム静的解析パイプラインの統合

標準の `hh_client` は組み込みのルールしか検証しないが、HHVMエコシステムでは、ASTをJSON形式でエクスポートする機能（`hh_client –dump-ast`）や、カスタムLinter/Static Analyzerを統合するためのAPIが用意されている。

シニアエンジニアとして取るべきアプローチは、CI/CDパイプラインまたは `hh_client` の拡張として動作するASTウォーカーを構築し、以下の不変条件（Invariants）を数学的に証明することだ。

1. `<>` が付与されたメソッドを呼び出す側も、適切な認可コンテキスト（例: `<>`）の中に存在しなければならない。
2. `riskLevel === ‘CRITICAL’` のメソッド内では、未検証のプリミティブ型（`string` など）の直接代入を禁止し、Value Objectへのラップを強制する。

以下は、その検証ロジックの概念を具現化したAST解析スクリプト（Hack製）の骨子である。

namespace HackEngine\Tooling;

HHVMのAST出力を走査し、カスタムAttributeの整合性を検証する静的解析エンジン

/
final class SecurityConstraintValidator {

public static function analyzeFile(string $astJsonPath): void {
$astData = \json_decode(\file_get_contents($astJsonPath), true);

// ASTの根からノードを走査
self::walkAst($astData);
}

private static mixed function walkAst(dict $node): void {
$kind = $node[‘kind’] ?? ”;

// メソッド定義ノードの解析
if ($kind === ‘Method’) {
self::validateMethodSecurityBoundary($node);
}

// 子ノードの再帰的走査
foreach ($node as $value) {
if ($value is dict<_, _>) {
self::walkAst($value);
} else if ($value is vec<_>) {
foreach ($value as $item) {
if ($item is dict<_, _>) {
self::walkAst($item);
}
}
}
}
}

private static function validateMethodSecurityBoundary(dict $methodNode): void {
$attributes = $methodNode[‘attributes’] ?? vec[];
$hasCriticalBoundary = false;

foreach ($attributes as $attr) {
$name = $attr[‘name’][‘name’] ?? ”;
if ($name === ‘HackEngine\\Security\\Attributes\\AuditedSecurityBoundary’) {
// 引数のパースと検証
$hasCriticalBoundary = true;
// ここでリクエストされた riskLevel や requireMFA の値を抽出し、
// アーキテクチャ上の制約を満たしているか検証する
}
}

if ($hasCriticalBoundary) {
// 例: クラス側にも特定のセキュリティ親クラスが継承されているかチェック
// 違反していれば即座にexitコード非ゼロでビルドをクラッシュさせる
}
}
}

—

4. メモリ最適化とHHVMランタイムへの影響

「このようなカスタム検証を導入することで、ランタイムのパフォーマンスが落ちるのではないか？」という懸念を持つ者がいるならば、それは無知の証左だ。

User Attributesは、HHVMのバイナリシリアライゼーション（RepoAuthoritative モード）において、コンパイル時にメタデータテーブルへ最適化されて格納される。つまり：

実行時のオーバーヘッドはゼロである（動的なリフレクションを使わない限り）。
型チェッカーと静的解析レイヤはビルドパイプライン（CI）の段階で完結するため、本番環境のJITコンパイラ（LLVMベースのTC – Translation Cache）には一切影響を与えない。

極限までチューニングされたHHVMのメモリ空間において、不要な動的メタデータチェックを排除し、すべての安全性をコンパイル時にコンパイル済みバイトコードへと焼き込む。これこそが、Hack言語を採用する最大の存在理由なのだ。

—

5. 結び：型システムを飼い慣らせ

型チェッカーは神ではない。だが、我々アーキテクトが適切なAttributeと静的解析ルールを与えることで、型チェッカーは「組織の誰も破ることのでえない鉄のセキュリティ防壁」へと変貌する。

動的言語の悪癖を断ち切り、Hackの静的型システムの深淵をグリグリとえぐり尽くせ。コードを書くのではない。コンパイルエラーという名の法律をデザインするのだ。