インストール
npx create-gaia@latest my-app誰に向いているか
GAIA は自らを "A serious harness for Claude Code" と説明しています。Claude Code のための本格的なエンジニアリングハーネスです。「書く前にきちんと考える」をプロセスとして固めます——コードの前にスペックを書く（Specs before code）、毎回のコミットに品質ゲートを設ける、毎回のマージに Code Audit Team による監査を入れる。次のような開発者に向いています。
- Claude Code で実際のソフトウェア開発を行い、すべての変更にスペックに基づく根拠を先に持ち、コミットは検証可能、マージは監査可能であることを求める開発者。一度の会話で検証されていないコードを生み出すためのものではありません。
- プロセスの制約を受け入れられる開発者。コミットの前には型チェック、lint、ユニットテストと Storybook テスト、Playwright E2E、開発サーバーのスモークテストを通過する必要があり、すべて合格してはじめてクリアになります。
- 実行要件を満たしていること。Node.js >= 22.22.0。
次の場合は不向きか、事前の確認が必要です。
- Claude Code を使わない環境。公式には Claude Code のハーネスとしてのみ説明されており、他の agent で使えるかは明示されていません。
- スペックやテストのプロセスなしに素早くスクリプトを生成したいだけの場面。スペックを先に書くことが求められるため、初期コストは高くなります。
- 汎用チャットや純粋な執筆支援を期待する場面。公式の説明はすべて開発プロセスの制約に関するもので、他の用途には言及していません。
- Node.js >= 22.22.0 以外に、公式は他の環境制限を列挙しておらず、システム互換性は確認できるまで未知とみなすべきです。
3 分で最初の試用を完了
推奨されるメイン経路は 1 本だけです。まず公式コマンドでプロジェクトを作成し、それから Claude Code の中でスペック作成をトリガーします。
前提：ローカルに Node.js >= 22.22.0 がインストールされており、Claude Code を使用できること。
インストール：ターミナルで実行します。
npx create-gaia@latest my-app
公式は、リポジトリを clone や fork するのではなく、この方法でプロジェクトを始めることを明確に求めています。コマンド内の my-app は新プロジェクトの名前です。最初の試用ではこの名前のままにして、既存ディレクトリとの混同を避けましょう。
タスクのトリガー：新規作成した my-app ディレクトリに入り、Claude Code で /gaia-spec と入力します。公式はこの操作を、ソクラテス式の問いかけ（Socratic discovery）を通じて不変の SPEC 成果物を作成するものと説明しています。つまり、いきなりドキュメントを生成するのではなく、要件について項目ごとに問いを重ね、あなたの回答を待ってから結論をスペックへと収束させます。副作用と確認ポイント：スペック成果物を生成し、一度生成されたら不変（immutable）です。そのため、質問に答える際は要件をよく確認してから締めくくりましょう。初回はこのまっさらなプロジェクトの中で行い、既存コードには触れないことをおすすめします。
成功のサイン：質問が終わり、生成された SPEC 成果物を手にしたら、スペック作成フローは完了です。途中で、完全な文章がすぐに出てくるのではなく、収束に向かう質問が何ラウンドも続くように見えたなら、それこそがこの操作の設計です。質問によって要件を明確にする仕組みです。
使用例
ケース 1：新規プロジェクトの着手前に要件を固定する。
シナリオ：新しいプロジェクトを始めようとしているが、口頭での要件が複数回の会話の中でブレ、回ごとに異なる実装方向になってしまうことが心配です。
きっかけ：npx create-gaia@latest my-app で作成したプロジェクトで、Claude Code に /gaia-spec を発行します。
過程と結果：agent はソクラテス式の問いかけで要件を項目ごとに明確にし、最終的に不変の SPEC 成果物を産出します。スペック先行がこのハーネスの動作方式であるため、この成果物がその後のコード作成前の一貫した基準になります。成果物は不変であり、生成前の質問セッションが唯一の確認ポイントです。回答する前に重要な意思決定を整理しておきましょう。SPEC 成果物のファイル名と保存場所は公式には明記されておらず、確認できる終点は「不変な成果物の生成」というステップです。
ケース 2：小さな変更をコミットし、コミット前の品質ゲートを体験する。 シナリオ：GAIA プロジェクト内のあるコードを修正し、コミットしようとしています。 きっかけ：普段どおりの流れでコミットを 1 回実行します。 過程と結果：コミットの前に品質ゲートが実行されます——型チェック（Typecheck）、lint、ユニットテストと Storybook テスト、Playwright E2E、開発サーバーのスモークテスト——すべて合格してはじめてコミットを続行でき、1 項目でも不合格ならコミットは完了しません。ゲートの全工程を観察しやすいよう、影響の小さい変更を選ぶのがおすすめです。ゲートには E2E とスモークテストが含まれ、実際に実行されるため、初回の実行は通常、ゲートのないコミットより時間がかかり、ローカル環境でも開発サーバーを起動できる必要があります。ゲートをスキップする方法が存在するかは、公式には説明されていません。
利用上の境界
- 実行環境：公式に確認されている要件は Node.js >= 22.22.0 のみで、それ以外のシステムレベルの制限は示されていません。使用前に環境を自身で確認してください。
- クライアント前提：GAIA は Claude Code 向けです。他の agent と組み合わせられるかは公式には明示されていません。
- 副作用と確認ポイント：
/gaia-specは不変の SPEC 成果物を生成し、生成前には質問による確認セッションがあります。コミットで起動するゲートは、テスト、E2E、開発サーバーのスモークテストを実際に実行します。 - ゲートの範囲：公式に列挙されている検査項目は、型チェック、lint、ユニットテストと Storybook テスト、Playwright E2E、開発サーバーのスモークテストです。それ以外の検査があるかは明示されていません。
- サンドボックス制限：公式には、サンドボックスルールが .env ファイル、鍵ファイルと証明書ファイル、認証情報名のファイル（block reads of .env files, key and certificate files, credential-named files）の読み取りをブロックすると明記されており、agent が機密性の高い認証情報に触れる機会を減らします。
- マージの制約：毎回のマージには Code Audit Team による監査が入ります。監査の具体的な成果物の形式と所要時間は公式には明示されていません。
- 未確認の事項：
/gaia-spec以外にどのような操作があるか、SPEC の保存場所、GUI の有無、対応言語の範囲は、いずれも公式ページには示されていません。プロジェクト内の実際の説明を参照してください。