こんにちは！HHVMとHack言語の深淵へようこそ。
今日は、他の言語からHackの世界に飛び込んできた開発者が、最初につまずきつつも「なるほど、これがHackの厳格さか！」と膝を打つポイント──Trait（トレイト）の型制約：`require extends` と `require implements`について、徹底的に解説していきますね。
「コードの重複をなくすためにTraitを作ったけれど、利用するクラス側で特定のメソッドやプロパティが存在している前提にしたい……でも、型チェッカーに怒られてしまう」
そんな悩みを抱えたことはありませんか？
大丈夫です。ここをクリアすれば、あなたもHackの静的型システムを掌の上で転がせるようになりますよ。さあ、一緒に本質を見ていきましょう！
—
1. なぜ「普通のTrait」では物足りないのか？
PHP由来の言語であるHackにおいて、Traitはコードの再利用性を高めるための強力な武器です。しかし、PHPのノリのまま自由奔放にTraitを書くと、厳格な静的型チェッカー（Typechecker）を持つHackの世界では、コンパイル時（型チェック時）に容赦なくエラーを叩きつけられます。
例えば、あるTraitの中で「このTraitを使うクラスは、必ず `ID()` メソッドを持っているはずだ」という前提でコードを書いたとしましょう。
<<__Strict>>
namespace Hack\Excellence;
trait LoggableTrait {
public function log(string $message): void {
// あれ？ $this に ID() なんてメソッド、本当に存在する？
// 型チェッカーは「保証できない！」と怒ります。
\printf(“[%s]: %s\n”, $this->getID(), $message);
}
}
このコードをHackの型チェッカーに通すと、次のようなエラーが発生します。
> The method `getID` is not defined on an object of type `LoggableTrait`（厳密には、この時点の `$this` はTrait自身であり、具体的なクラスの型が決まっていないため）。
「使う側で勝手に実装してよ」と言いたくなりますが、Hackの厳格モード（`<<__Strict>>`）は、「実行時になってメソッドがなくて焦るようなコードは、書いた時点でコンパイルエラーにする」という強い意志を持っています。
このジレンマを美しく、そして完全に解決するのが、今回主役となる `require extends` と `require implements` なんです。
—
2. 救世主登場：`require extends` と `require implements` の基本
Traitの中に「型制約（Type Constraints）」を設けることで、「このTraitを組み込みたいなら、特定のクラスを継承しているか、特定的インターフェースを実装していなければならない」という契約を強制できます。
概念図でイメージしてみましょう。
[ 契約のイメージ ]
Trait: LoggableTrait
└─ “私を使うなら、必ず BaseUser クラスを継承していてよね！” (require extends)
└─ “あるいは、Renderable インターフェースを実装していてよね！” (require implements)
▲
│ 結合 (use)
│
Concrete Class: AdminUser (条件クリア！)
それぞれの使い所を見ていきましょう。
`require extends`（クラスの継承制約）
Traitが、特定の親クラスの機能やプロパティに依存している場合に使います。
`require implements`（インターフェースの実装制約）
Traitが、特定のメソッドの存在だけを保証させたい場合（ダックタイピングではなく厳格な契約）に使います。
—
3. 実践！安全なミックスインをコードで体感する
それでは、実際に動く（そして型チェッカーが完璧に微笑む）コードを見てみましょう。ここでは、ユーザーのログ出力を担うTraitに型制約を組み込んでみます。
<<__Strict>>
namespace Hack\Excellence;
// 1. 基本となるインターフェース
interface HasIdentity {
public function getID(): int;
}
// 2. 基底クラス（必要に応じて）
abstract class UserBase implements HasIdentity {
protected string $name;
public function __construct(string $name) {
$this->name = $name;
}
}
// 3. 型制約を持ったTraitの定義
trait UserLoggerTrait {
// 【重要】このTraitを使うクラスは UserBase を継承していなければならない
require extends UserBase;
// 【重要】さらに HasIdentity も実装していなければならない
require implements HasIdentity;
public function logAction(string $action): void {
// 型チェッカーは、このクラスが確実に getID() を持ち、
// $this->name にアクセスできることを「知っている」ため、エラーになりません！
\printf(“User #%d (%s) executed: %s\n”, $this->getID(), $this->name, $action);
}
}
// 4. 制約を満たす具象クラス
class AdminUser extends UserBase implements HasIdentity {
use UserLoggerTrait; // ここでミックスイン！
public function getID(): int {
return 999; // 管理者のID
}
}
<<__EntryPoint>>
function main(): void {
$admin = new AdminUser(“Alice”);
$admin->logAction(“System Reboot”);
// 出力結果: User #999 (Alice) executed: System Reboot
}
このコードの美しさが分かりますか？
`UserLoggerTrait` の中では、具体的なクラスがどうなっているのか詳細を知らないにもかかわらず、`require` 構文によって「外側の世界（クラス側）が守るべき契約」をコンパイル時に完全に担保できています。
—
4. 陥りやすい文法エラーと、HHVMアーキテクチャの裏側
ここで、初学者がよくやってしまうミスと、それを型チェッカーがどう見ているかをご紹介しますね。
よくあるミス：制約を満たしていないクラスで `use` する
もし、`UserBase` を継承していない全く関係のないクラスで `UserLoggerTrait` を使おうとすると……？
class Guest {
use UserLoggerTrait; // ❌ エラー！ UserBase を継承していない
}
型チェッカーは容赦なくこう叫びます。
> Class `Guest` uses trait `UserLoggerTrait`, but does not extend required type `UserBase`.
この厳格さこそが、大規模なHHVMエコシステムにおいて、何百万行ものコードベースを安全にリファクタリングし続けられる秘密なんです。実行時エラー（`Call to a member function getID() on null` など）がプロダクション環境に到達する前に、IDEやCIの上で完全に潰しこまれるわけですね。
—
まとめ：Hackを使いこなすエンジニアへ
いかがでしたでしょうか？
- Trait単体では解決できない依存関係を、`require extends` / `require implements` で型安全に解決できること
- コンパイル時に契約を強制することで、実行時エラーを未然に防げること
この2点を押さえておけば、あなたの書くHackコードの安全性は劇的に跳ね上がります。
型チェッカーは、あなたを縛る窮屈な枷ではありません。複雑なシステムを泥臭さから守ってくれる、もっとも頼れる相棒です。この仕組みを味方につけて、洗練されたHackライフを存分に楽しんでくださいね！
それでは、次の知見でお会いしましょう。バッチリマスターできましたね！