こんにちは！Hack言語の世界へようこそ。
世界最高峰のHHVMアーキテクチャや厳格な型システムを日々触っていると、Hackの持つ圧倒的なパフォーマンスと美しさに魅了されますよね。
今回は、他の言語（PHPやTypeScriptなど）からHackに入ってきた開発者が「おっ、これこそHackの真骨頂だ！」と感動するテーマ、『Attribute（属性）を活用したカスタム静的解析ルール』についてお話しします。
「型チェッカーが守ってくれるのはデータ型だけだよね？」と思っていませんか？
実は、HackのAttributeを使いこなすと、ビジネスロジックの制約までコンパイル時（静的解析時）に強制できるようになるんです。ここをクリアすれば、あなたのHackの基本はバッチリマスターできますよ！
—
1. なぜ「型の枠を超えた検証」が必要なのか？
Hackのストイックな静的型システム（Strict Mode）は、`int` や `string`、あるいはジェネリクスに至るまで、プログラムの整合性を完璧に担保してくれますよね。
// Strict Modeの基本
<<__Strict>>
namespace Hack\Example;
function calculate_tax(int $price): int {
return (int)($price 0.1);
}
このコードは完璧です。でも、現実のビジネスロジックはどうでしょう？
例えば、「ある特定の金額フィールドは、必ず正の偶数でなければならない」とか、「このAPIエンドポイントを処理するメソッドには、必ず監査ログの記録処理が紐づいていなければならない」といったルールは、通常の型システムだけでは表現しきれませんよね。
そこで登場するのが Attribute（属性） です。
—
2. Hackの Attribute とは何か？（イメージ図解）
Attributeとは、クラスやメソッド、プロパティに対して「メタデータ（付加情報）」をマークする機能です。C#のAttributeやJavaのAnnotationに近い概念ですね。
Hackの型チェッカー（hh_client）は、ソースコードを解析する際に、このAttributeを「目印」として読み取ることができます。
[ 開発者のコード ]
│
▼ （Attributeを付与）
<
class MyService { … }
│
▼ （HHVM / 型チェッカーの静的解析）
【カスタムLinter / 解析スクリプトで検知！】
-> 「おいおい、この値はルール違反だぞ！」とビルド前に警告
このように、型チェッカーの目をすり抜けるようなドメイン固有の制約を、Attributeを使って静的にあぶり出す仕組みを作ることができるのです。
—
3. 実践！カスタムAttributeの定義と利用法
それでは、実際にコードを書いてみましょう。
ここでは、「機密データを扱うメソッドには、必ず特定のセキュリティ監査用Attributeが付与されていなければならない」というルールを検証するシチュエーションを考えてみます。
ステップ1: Attributeの定義
Hackでは、Attributeは `__Attribute` 属性を持ったクラスとして定義します。
<<__STRICT>>
namespace Hack\SecurityDemo;
// このAttributeはメソッドに対してのみ付与できることを宣言
<<__Attribute(__Method)>>
class AuditRequired {
// コンストラクタで監査レベルを受け取る
public function __construct(public string $securityLevel) {}
}
ステップ2: コードへの適用
次に、実際のビジネスロジックを書くクラスでこのAttributeを利用します。
<<__STRICT>>
namespace Hack\SecurityDemo;
class UserDataService {
// 正しくAuditRequiredが付与されている例
<
public function deleteUserAccount(int $userId): void {
// ユーザー削除の機密処理…
}
// うっかりAttribute付け忘れてしまった危険なメソッド！
public function exportAllUserData(): void {
// 全データエクスポートの処理…（本来なら監査が必要！）
}
}
—
4. 静的解析でルールを強制する（カスタムLinterの思想）
さて、上記のコードで `exportAllUserData()` メソッドには `AuditRequired` がついていません。これを人間が目視でレビューするのは限界がありますよね。
ここで、Hackエコシステムにおける静的解析の出番です。
Hackでは、AST（抽象構文木）を走査するスクリプトや、独自のLinter（静的解析ツール）を組み込むことで、「クラス内に特定の条件を満たすメソッドがあるのに、特定のAttributeがない場合、エラーとしてビルドを落とす」というCIパイプラインを構築できます。
イメージとしては、次のような静的解析のロジックを回します：
1. `UserDataService` クラス内の全メソッドを走査する。
2. メソッド名が `export` や `delete` で始まる「機密性の高そうな名前」か判定する。
3. もしそうであれば、Reflection等を用いて `AuditRequired` Attributeが付いているかチェックする。
4. 付いていなければ、静的解析エラー（Exit Code 1）を吐いてCIを停止する！
これにより、開発者がコードを書いた瞬間に（あるいはGitHub ActionsなどのCIで）ルール違反が即座に検知されます。「本番環境にデプロイしてから気づいた」という悪夢とはもうお別れです。
—
5. 陥りがちな文法エラーと注意点
HackでAttributeを扱う際、初学者がハマりやすいポイントをいくつかご紹介しておきますね。ここを気をつければバッチリです！
① Attributeのターゲット（付与対象）を間違える
先ほど `<<__Attribute(__Method)>>` と書いたように、そのAttributeが「どこに貼れるものか」のスコープが厳格に決まっています。クラス（`__Class`）に貼るべきものをメソッド（`__Method`）に貼ると、型チェッカーが容赦なくエラーを投げます。
// エラー例：クラス用なのにメソッドに貼ってしまった場合など
<<__Attribute(__Class)>>
class MyClassAttribute {}
class Foo {
// ここで使うと、HHVMの型チェッカーに怒られます！
<
public function bar(): void {}
}
② Strict Modeを忘れる
Hackの恩恵を100%受けるためには、ファイルの先頭に必ず `<<__Strict>>` を宣言しましょう。緩いモード（Partial Mode）では、型チェッカーやAttributeのスコープ解決が曖昧になり、意図しない挙動を生む原因になります。
—
6. おわりに
いかがでしたか？
Hackの `Attribute` と静的解析を組み合わせるアプローチは、単なるプログラミング言語の機能を超えて、「チーム全体の開発ルールやセキュリティポリシーをコードベースに強制する強力な武器」になります。
ここをクリアできれば、あなたはもう単なるHackの使用者ではなく、アーキテクトとしての視点を持ったエンジニアの仲間入りです。
日々のコーディングにぜひ取り入れて、堅牢で美しいHackライフを満喫してくださいね。それでは、次のコードレビューでお会いしましょう！