メインコンテンツへスキップ

spike（失敗してもいいプロトタイプで技術選定を1日で終わらせる）｜OpenClawスキル解説

    みさき

    はじめに — 「本当に作れるのか？」を確認するだけで1週間溶ける

    新しい機能やツールを作ろうとするとき、最初に立ちはだかるのは設計でも実装力でもなく、「そもそもこの方針で成立するのか?」という不確実性です。

    • このAPIで本当に欲しいデータは取れるのか?

    • ライブラリAとB、どちらがこの要件に合うのか?

    • その手法、性能は出るのか?

    ここを曖昧なまま本実装に入ると、最悪のケースで「2週間書いたコードが全部没」になります。かといって、検証のために本格的なテストコードや環境を整えていたら、それだけで1週間が溶ける。

    この「確認したいことだけを最短で確認する」ための作法が、OpenClawの spike スキル です。

    spikeとは — 使い捨てプロトタイプを回すためのスキル

    spikeは、OpenClaw（AIエージェント環境）に同梱されるスキルの1つで、捨てる前提の最小プロトタイプ（スパイク）をAIエージェントに実行させるための手順を定義したものです。

    「スキル」といっても、AIエージェントに追加の手順書を与えるものなので、導入すれば即座に何かがインストールされるタイプのツールとは少し違います。spikeがやるのは、AIにスパイクの作法を守らせることです。

    スパイクの5ステップループ

    spikeスキルでは、検証を必ず次のループで回します。

    1. Question — 確認したい問いを1文で明確化する

    2. Research — ドキュメントやソースを必要最小限だけ読み、有望なアプローチを選ぶ

    3. Build — 問いに答えられる最小の動く成果物を作る

    4. Stress — エッジケースを1つ試して限界を確認する

    5. Verdict — VALIDATED（成立）/ PARTIAL（条件付き成立）/ INVALIDATED（不成立）の判定を下す

    ポイントは、作るものが「動くCLIひとつ」「1エンドポイントのAPI」「小さなHTML」など実用最小限に限定されている点です。Docker環境、envファイル、フレームワーク導入といった「本実装の手順」は明確に禁止されています。

    Verdictレポートの形式

    検証結果は次の形式で報告されます。

    ## Verdict: VALIDATED | PARTIAL | INVALIDATED

Question: 確認した問い
Evidence: 実行したコマンドと出力（そのまま）
What worked: うまくいったこと
What failed or surprised us: 失敗・予想外だったこと
Recommendation: 進める / 調整する / やめる、と次の一手

    Evidence欄に「実行結果そのもの」を貼るのがミソです。「たぶん動く」ではなく、動いた出力・測定値で判断します。

    インストール方法

    OpenClaw環境であれば次のコマンドで導入できます。

    npx clawhub@latest install spike

    （OpenClaw本体に同梱されている場合は追加インストール不要です）

    使い方 — 具体例

    例1: 「このAPIでデータは取れるのか?」

    新しいAPI連携を検討しているとき、公式ドキュメントを読むだけで判断するのは危険です。spikeなら:

    • Question: 「API X でユーザーの月次利用量を取得できるか?」

    • Build: 1ファイルのCLIスクリプトでその1エンドポイントだけ叩く

    • Stress: 存在しないユーザーを指定してエラー時の挙動を見る

    • Verdict: 取得できるフィールドに利用量がなかった → INVALIDATED、代替エンドポイントの検討へ

    ドキュメントを何時間も読み込むより、10分のスパイクの方が確実に答えを出してくれます。

    例2: A/B比較を1日で決着させる

    ライブラリ選定でAかBか議論が続くような場面では、spikeスキルはこう要求します。

    • 問いを2〜5個の独立した問いに分解する

    • リスクが高い問いから先に検証する

    • A/B比較では同じ入力・同じ指標で測る

    「どちらも試しにフル実装して比べる」のような無駄を最初から排除してくれるのが強みです。

    例3: 外部依存の健康診断

    新しい外部ライブラリを評価するとき、spikeは「最近リリースがあるか、ドキュメントは整っているか、ライセンスは問題ないか、導入の摩擦は大きくないか」という健全性チェックまで含めて判定します。放ったらかしのライブラリを後から引き剥がすコストを事前に回避できます。

    作ったものはどこに置く?

    • デフォルトでは .tmp/openclaw-spikes/<slug>/ — 名前の通りテンポラリ領域で、使い捨て前提

    • 記録を残したい場合はリポジトリ内 spikes/NNN-slug/ にREADME付きで保存

    そして重要なルールがもう1つ: スパイクのコードは、検証が通ってもそのまま本番にマージしない。スパイクは判断のための道具で、本実装はちゃんと書き直す。この「汚いコードを持ち込まない」規律が、後の保守性を守ります。

    まとめ — 「検証コスト」をゼロに近づける作法

    spikeスキルのおすすめポイントをまとめます。

    • 没リスクを潰せる: 本実装の前に、最もリスクの高い問いから順に潰していく

    • 判定が明確: VALIDATED / PARTIAL / INVALIDATED の3値で、エビデンス付きで結論が出る

    • 無駄を禁止: フレームワーク導入・環境構築など「検証に不要な仕事」が最初から禁止されている

    • 不成立も成果: INVALIDATED は「その道を諦められる証拠」として価値がある

    • 汚染しない: スパイクコードは本番に持ち込まない規律で、テストコードの質を下げない

    技術選定や実現可能性の確認に毎週時間を溶かしている人には、特に刺さるスキルです。まずは小さな問いから、spikeを回してみてください。

    #OpenClaw #AI #スキル #効率化

    あなたへのおすすめ