いま起きていること：AIは「作業が大きくなる」と急にポンコツになる
「AIに頼んだら、最初はうまくいったのに、直す量が増えたとたんボロボロになった」。心当たり、ありませんか。
実はこれ、あなたの指示が下手なせいだけではないんです。海外の開発チームが公開した数字では、一度の指示だけで20個以上のファイルを正しく直せる確率は 1〜20%。ほぼ運まかせです。
今回紹介するのは、その確率を 70% まで引き上げると説明されている無料の道具箱「Context Engineering Kit」。GitHub のスター1.5k、フォーク153、コミット410回の実在プロジェクトです。Claude Code なら、たった1行貼るだけで使えます。
（2026年9月時点の情報。成功率などの数字は、開発元がリポジトリの説明文で公表しているものです。第三者機関による検証結果ではありません）
なぜ「まとめてお願い」すると失敗するのか
AI に仕事を頼むとき、多くの人は一発で全部お願いします。これを「一度きりの指示」と呼びます。
開発元が公開した比較表を見てください。「何個のファイルを直させたか」で、正しく仕上がる確率がどう変わるかを並べたものです。
| やり方 | 1〜3ファイル | 4〜10 | 10〜20 | 20以上 | 追加でかかる文字量 |
|---|---|---|---|---|---|
| 一度きりの指示 | 60〜80% | 30〜50% | 5〜30% | 1〜20% | 0 |
/reflect（自己点検） |
68〜91% | 49〜71% | 13〜41% | 1〜30% | 1k〜3k |
/reflect + /memorize（点検＋記憶） |
79〜87% | 60〜79% | 34〜42% | 5〜30% | 2k〜5k |
/do-and-judge（審判役をつける） |
90% | 83% | 60% | 30% | 1.5〜3倍 |
/do-in-steps（小分けにする） |
92% | 90% | 71% | 50% | 3〜5倍 |
/plan-task + /implement-task（計画→実装） |
94% | 93% | 85% | 70% | 5〜20倍 |
注目してほしいのは、いちばん上の行の右端です。20ファイル以上を一気に直させると、成功率は最悪 1%。100回に1回しか当たらない計算になります。
なぜこうなるのか。開発元は「話が長くなるほど AI の品質は急激に落ちる」と説明しています。たとえるなら、長い会議です。最初に決めたことを、3時間後にはみんな忘れている。AI も同じで、これまでの話の流れが長くなると、最初の約束を取りこぼします。
そして表のいちばん下。計画を立ててから実装させると、20ファイル以上でも 70%。同じ AI、同じモデルなのに、頼み方だけで70倍の差がつくということです。
Context Engineering Kit って、結局なに？
正式名称は NeoLabHQ/context-engineering-kit。「コンテキストエンジニアリング」（＝かんたんに言うと「AI に渡す情報を、うまく整える工夫」）のやり方を集めた道具箱です。
作ったのは NeoLab という会社。「自社の開発者が毎日使ってきたプロンプトがベース」で、そこに論文や質の高いプロジェクトから取り入れたものを足した、と説明されています。
対応しているのは Claude Code、OpenCode、Cursor、Antigravity など。中身は「プラグイン」（＝あとから足せる追加機能）の形で分かれていて、必要なものだけ入れられます。
開発元が挙げている特徴は6つです。
- かんたん：他に何かを入れる必要がない。自動で使われるスキルと、名前を見れば用途が分かるコマンドだけ
- 文字量が少ない：長い説明文をダラダラ足すのではなく、命令型のスキルと AI の分身（サブエージェント）を組み合わせて、余計な情報でいっぱいにしない
- 1点集中：プラグインごとに「ここを良くする」が決まっている
- バラ売り：必要なプラグインだけ入る。入れたプラグインの分だけが読み込まれる
- 裏付けあり：定評あるテストや研究で確かめられた手法がベース
- 共通ルールに準拠：スキルは agentskills.io（＝スキルの書き方を決めた共通ルール）に沿っている。設計書を作る SDD プラグインは Arc42（＝設計書の書き方の型）に沿っている
入れ方は1行。ただし「入れただけ」では何も起きない
ここが最初の落とし穴です。順番に見ていきます。
Claude Code の場合
まず、お店（マーケットプレイス）を追加します。
/plugin marketplace add NeoLabHQ/context-engineering-kit
ここで終わりだと思っている人がとても多いです。 説明文にはっきり書いてあります。これは「全部のプラグインを選べる状態にするだけ」で、AI の分身もスキルも、まだ一切読み込まれていません。
棚に商品が並んだだけ。カゴに入れていない状態です。
次に、使いたいものを個別に入れます。最初の1つとして紹介されているのが reflexion です。
/plugin install reflexion@NeoLabHQ/context-engineering-kit
入れたプラグインの分だけが読み込まれる仕組みなので、あれこれ入れすぎない方がいいです。
Claude Code 以外の場合
- Gemini CLI：
gemini extensions install https://github.com/NeoLabHQ/context-engineering-kit - Antigravity CLI：
agy plugin install https://github.com/NeoLabHQ/context-engineering-kit/antigravity（Gemini CLI は不要） - Cursor / Codex / OpenCode など：
npx skills add NeoLabHQ/context-engineering-kit - 別の入れ方：
npx openskills install NeoLabHQ/context-engineering-kitのあとnpx openskills sync
中級者向けの注意を3つ。 ここを知らないと損します。
1つ目。Gemini CLI と Antigravity CLI は、全プラグインをまとめて一括で入れます。Claude Code のような「1つずつ選ぶ」ができません。説明文にも「残念ながら対応していない」と書かれています。対処法も書いてあって、入れたあとに要らないスキルと分身を自分で消す。放っておくと、使わない指示文がずっと読み込まれ続けます。
2つ目。npx skills で入れる方法は、AI の分身（サブエージェント）に対応していません。各ツールが独自の形式を使っているためです。説明文自身が「この入れ方では本来の性能は出ない」と認めています。分身を使う仕組みが売りなので、ここは大きい差です。
3つ目。後で出てくる「自動で点検を走らせる仕掛け」を使うには bun が必要です。ただし、コマンドを手で打つ分には bun は要りません。
今日から効く最小の一歩：/reflect と /memorize
いきなり全部やろうとすると挫折します。まずは reflexion プラグインの2コマンドだけ覚えてください。
説明文にある使い方は、こういう流れです。
> claude "implement user authentication"
（ログイン機能ができる）
> /reflect
（結果を自分で分析して、改善案を出す。
明らかにおかしい所はその場で直す。
細かい所は「こうしたら?」と提案してくる）
> fix the issues
（直させる）
> /memorize
（うまくいった直し方を、このプロジェクトの記憶に保存する）
もうひとつ、時短のワザも紹介されています。最初のお願いの文に「then reflect」と足しておくと、実装が終わった瞬間に点検が自動で始まります（これが bun の要る仕掛けです）。
/memorize がなぜ効くのか。表をもう一度見てください。/reflect だけだと4〜10ファイルで49〜71%。/memorize を足すと60〜79%になります。同じミスを二度としなくなるからです。
たとえるなら、料理のレシピ帳です。1回目に「火が強すぎて焦げた」と気づく。それをメモに書いておけば、2回目からは焦がさない。書かなければ、毎回焦がします。
コピペで使える点検プロンプト
プラグインを入れなくても、この考え方だけなら今すぐ真似できます。実装が終わった直後に、そのまま貼ってください。
いま実装したコードを、第三者になったつもりで点検してください。 まず、私が最初に出した依頼文をもう一度読み直してください。 そのうえで次の5項目を0〜10点で採点し、点数の根拠を1行ずつ書いてください。 1 取りこぼし：依頼文にあるのに実装されていない機能はないか 2 事実確認：使ったライブラリ名・関数名・設定値を、実際にファイルを開いて確かめたか 3 影響範囲：この変更で壊れるかもしれない既存の機能を、全部あげたか 4 エラー処理：入力が空・0・想定外のとき、どう動くか決まっているか 5 読みやすさ：3か月後に他人が読んで意味が分かるか 採点が終わったら、7点未満の項目だけを、いますぐ直してください。 直したあとに、何をどう直したかを箇条書きで報告してください。 推測で書いた部分があれば「ここは推測です」と正直に書いてください。 **点数が低かった項目ごとの打ち手**を1行ずつ置いておきます。ここまでセットで使ってください。 - 1（取りこぼし）が低い → 依頼文を「〜ができていればOK」という箇条書きに書き直して、もう一度渡す - 2（事実確認）が低い → 「該当ファイルを開いて、その中身を引用してから答えて」と条件を足す - 3（影響範囲）が低い → 実装の前に「変更するファイルを使っている場所を全部検索して一覧にして」と頼む - 4（エラー処理）が低い → 空・0・null・上限値の4パターンのテストを、実装より先に書かせる - 5（読みやすさ）が低い → 「1ファイル200行を超えたら分ける」を最初のルール文に入れておく
業種別の穴埋め例①：EC の在庫発注
いま実装した在庫発注の機能を、第三者になったつもりで点検してください。 次の5項目を0〜10点で採点し、根拠を1行ずつ書いてください。 1 取りこぼし：発注点の設定・発注数の計算・発注履歴の保存、この3つは全部あるか 2 事実確認：在庫テーブルの列名と単位（個か箱か）を、実際のスキーマを開いて確かめたか 3 影響範囲：在庫数を書き換える処理を他にも使っている画面を、全部あげたか 4 エラー処理：在庫が0のとき、マイナスになったとき、同じ商品に同時に2件の発注が来たとき、どうなるか 5 読みやすさ：発注数の計算式を、コードを読まない担当者にも説明できる形で書いたか 7点未満の項目だけ、いますぐ直してください。直した内容を箇条書きで報告してください。
業種別の穴埋め例②：問い合わせの一次対応
いま実装した問い合わせ対応の機能を、第三者になったつもりで点検してください。 次の5項目を0〜10点で採点し、根拠を1行ずつ書いてください。 1 取りこぼし：自動で返す条件・人間に引き継ぐ条件・履歴の保存、この3つは全部あるか 2 事実確認：回答に使うFAQの元データが実際にどこにあるか、ファイルを開いて確かめたか 3 影響範囲：問い合わせデータを読み書きしている他の機能を、全部あげたか 4 エラー処理：本文が空のとき、極端に長いとき、答えが見つからないとき、どう返すか 5 読みやすさ：「人間に引き継ぐ条件」が、運用担当者が読んで判断できる形で書いてあるか 7点未満の項目だけ、いますぐ直してください。直した内容を箇条書きで報告してください。
どこまでコストを払うかで選ぶ、4段階
reflexion で慣れたら、次はもっと強い方法に進みます。ただし コストが跳ね上がる ので、ここは冷静に選んでください。
表の「追加でかかる文字量」の列がそれです。/reflect は1k〜3k文字ぶんの上乗せ。ところが計画→実装のやり方は 5〜20倍。20倍ということは、1回100円だった作業が2000円になるということです。
判断の目安はシンプルです。直すファイルの数で決めます。
- 1〜3ファイル → 一度きりの指示で60〜80%。ダメなら
/reflectを足す - 4〜10ファイル →
/reflect+/memorizeで60〜79%。/do-and-judgeなら83% - 10〜20ファイル →
/do-in-steps（小分け）で71% - 20ファイル以上 → 計画→実装に分けて70%。ここはケチると確実に失敗します
開発元が「最初に試すならこれ」と挙げているのは Subagent-Driven Development と Spec-Driven Development（SDD） の2つです。
この2つがどう育ってきたかも、公開されている更新履歴から分かります。
- v2.0.0：SDD をゼロから作り直し。「実際の本番プロジェクトで99%のケースで動くコードを生成できる」と記載（開発元自身の主張です）
- v2.1.0：SDD の分身が、DDD プラグインの品質ルールを持つように
- v2.2.0：Subagent-Driven Development が、SDD を凝縮した版として動くように。meta-judge と judge という2種類の審判役の分身を使い、実装と同時に仕様を作る。DDD プラグインには Clean Architecture・DDD・SOLID・関数型といった設計の作法（＝コードの整理整頓のお作法）が例つきで入り、コードを書くときに自動で足される
- v3.0.0：AMP と Hermes に対応。Tech Stack プラグインが、AI が TypeScript のファイルを読み書きするときに 自動で TypeScript の作法を差し込む ように
- v3.1.0：SDD が生むコードの品質をさらに改善。開発者役の分身に DDD/SOLID のルールを埋め込み、さらに専用の code-reviewer（点検役）の分身を追加。関数型とオブジェクト指向の作法に加えて、Muda（ムダ）分析（＝トヨタ生産方式のムダ取り）を当てて、コードの複雑さと重複を減らす
v3.0.0 の Tech Stack は地味ですが、実は一番おいしいかもしれません。「TypeScript の書き方を毎回指示する」手間が消えるからです。
日本の読者は、これをどう真似るか
海外の道具をそのまま入れる必要は、実はありません。考え方だけ持ち帰るのが、いちばん費用対効果が高いです。
真似ポイント1：「点検」を工程として組み込む
いちばん効くのはこれです。実装が終わったら、必ずもう一度 AI に見直させる。上のプロンプトを貼るだけで、追加費用はほぼゼロ。数字の上でも、1〜3ファイルなら60〜80%が68〜91%に上がります。
真似ポイント2：日本語の「学びメモ」を1枚作る
/memorize の正体は、要するに プロジェクト専用のメモ帳 です。Claude Code なら CLAUDE.md がその役割を果たします。
やることは簡単。同じ失敗を2回されたら、その日のうちに1行足す。
- 日付は必ず日本時間で扱う。UTCのまま表示しない
- Supabase のクエリは必ずクエリビルダーを使う。生SQLは書かない
- 1ファイルが200行を超えたら分割する
これだけで、AI は同じ穴に落ちなくなります。海外のプラグインを入れなくてもできます。
真似ポイント3：大きい仕事は「先に文章にする」
20ファイル以上を一気に頼むと成功率1〜20%。この数字を見たら、やることは1つです。
実装の前に、まず仕様を文章で書かせる。 その文章を自分で読んで直す。直した文章を渡して、初めて実装させる。これだけで70%圏内に入ります。SDD がやっていることを、手作業でやるイメージです。
真似ポイント4：入れたプラグインは、定期的に減らす
とくに Gemini CLI と Antigravity CLI を使う人。一括で入るぶん、使っていないスキルが溜まります。月に1回、「今月一度も使わなかったもの」を消してください。読み込む文字量が減れば、そのぶん本題に使える余裕が増えます。
まとめ：今日・1週間・1か月で何をするか
AI が大きな作業で失敗するのは、あなたのせいではありません。頼み方の構造の問題です。そして構造は、今日から変えられます。
今日やること（15分）
- この記事の「実装のあとの自己点検用」プロンプトを、メモアプリに保存する
- 次に AI に実装を頼んだら、終わった直後にそれを貼る
- 7点未満の項目だけ直させて、直った実感を確かめる
1週間でやること
- Claude Code を使っているなら
/plugin marketplace add NeoLabHQ/context-engineering-kitを実行する - そのあと 必ず
/plugin install reflexion@NeoLabHQ/context-engineering-kitまで進む（追加だけでは何も読み込まれません） /reflect→ 直す →/memorizeを、実際の作業で3回まわす- 同じ失敗が2回出たものを
CLAUDE.mdに日本語で1行足す
1か月でやること
- 10ファイル以上を触る作業では「仕様を先に文章化してから実装」を必ずやる
- Subagent-Driven Development か Spec-Driven Development を試し、コストと精度の割に合うかを自分の案件で判断する
- TypeScript を書くなら Tech Stack プラグインを入れて、作法の指示を毎回書く手間を消す
- 使っていないスキルと分身を消して、読み込む文字量をダイエットする
大事なのは、全部を一度に入れないこと。まず /reflect だけ。効果を体で感じてから、次に進んでください。
