bkit — Context EngineeringでClaude Codeを“正しく”使う
2025年12月、私はbkamp.aiというサービスをリリースしました。
- 11個のマイクロサービス
- Next.jsベースのポータル
- AWS EKS + GitOps (ArgoCD)
- Terraformインフラ
そしてこれらすべてをわずか9日で本番環境に載せました。
開発者は私ひとりで、
AIにはClaude Codeを使いました。
この記事は「速く作った」という話ではありません
多くのAI開発事例は、次のように説明されます。
- 「AIでN日で作った」
- 「プロンプトをうまく書けばいい」
しかし実際に9日間開発して感じたことは、まったく別のものでした。
AIがコードを書くのが上手いのは事実です。
しかし何を書くべきかはAIが決めるわけではありません。
それを決めるのは結局、次のものです。
- 設計
- ルール
- 作業単位
- 検証方法
私はこれをContext Engineeringと定義しました。
Context Engineeringとは何か
簡単に言えば、
プロンプトをうまく書くことではなく、
AIが働く環境そのものを設計すること
です。
たとえば、
- 先に設計書を作る
- 作業単位を文書基準で分ける
- 結果を検証するルールを作る
- 再現可能なサイクルを作る
つまり、
AIは「執筆者」ではなく、
定義済みコンテキストをレンダリングするエンジンになります
bkampで実際に行った方法
1. Day 0 — コードを書く前にルールを作る
最初のコミットにはコードがありませんでした。
代わりに次のものを作りました。
.claude/CLAUDE.md(約150行)- 要件文書
- 戦略文書
ここには次の内容が定義されています。
- PDCAサイクル (Plan → Do → Check → Act)
- すべての成果物は人間が検証
- 企画は日本語、コードは英語、コミットは日本語
- 作業単位と進め方
この100行ほどのルールが、その後のすべての開発を決定しました。
2. 作業単位は「機能」ではなく「文書」
通常は次のように依頼します。
- 「チャット機能を作って」
しかし実際には次のように進めました。
- 「文書7の3.2節を実装して」
この違いは非常に大きいです。
AIの立場から見ると、
- 機能 → 解釈が必要（不確実性）
- 文書 → そのまま実装（決定的）
結果として、
出力のばらつきがほとんど消えます
3. 1日 = 1つのPDCAサイクル
開発はこのように進みます。
- Plan (設計)
- Do (実装)
- Check (Gap分析)
- Act (修正)
そしてこのサイクルを日単位で繰り返します。
この方法の利点は、
- コンテキストが常に最新状態に保たれる
- 作業範囲が明確
- AIが「今何をすべきか」を明確に理解できる
4. チェックポイントを打ち、大胆に作り直す
4日目にはフロントエンドを全面的に再構成しました。
しかしその前に必ず行うことがあります。
- ロールバック可能なチェックポイントを作成
こうすることで、
失敗しても安全
→ 大胆な構造変更が可能
5. インフラは最後にまとめて接続する
8日目の1日で、
- Terraform
- Kubernetes
- CI/CD
- ArgoCD
を一気に接続しました。
これが可能だった理由は単純です。
それ以前にすべての構造がすでに整列していたからです
ここから得た核心的なパターン
この9日間で繰り返されたパターンは次のとおりです。
- まずルールを定義する
- まず設計を作る
- 文書を基準に作業する
- PDCAサイクルで反復する
- チェックポイントを作る
- 不一致は文書で解決する
- コードは最後
では、これを継続して維持できるのか？
ここで問題が生じます。
この方法は強力ですが、
人間が継続的に維持するにはあまりにも大変です
- ルールをずっと覚えておかなければならず
- 文書を常に合わせ続けなければならず
- 毎回PDCAを守らなければなりません
そこで作ったのがbkitです。
bkitとは何か
bkitはClaude Codeプラグインです。
しかし単なるツールではありません。
bkampで使った作業方式を、
そのままシステム化したものです
最も重要な概念: PDCA = 状態機械
bkitではPDCAを次のように実装しました。
- 状態: plan, design, do, check, act など
- 遷移: 状態間の移動ルール
- ガード: 条件チェック
たとえば、
- 設計と実装の一致率が90%以上 → 通過
- そうでなければ → 自動で修正ループを実行
つまり、
「レビュー → 修正」が自動で繰り返されます
Context Engineeringをシステム化した構造
bkitは次の要素で構成されています。
- Skills (ドメイン知識)
- Agents (役割ベースの振る舞い)
- PDCA状態機械
- Context注入システム
- Quality Gate (検証)
- Audit Log (記録)
- Feedback Loop (自動反復)
これを一文でまとめると、
AIを使うのではなく、
AIが働くシステムを作る
結果
この方法で得られた結果は次のとおりです。
- Claude Code 79バージョン連続互換
- 4,000+ テスト、失敗 0
- 200+ CI検証ルール
- DocsとCodeの完全同期
結論
これはAIがより賢くなったという話ではありません。
人間の作業が前倒しされたという話です
- 設計が先
- ルールが先
- 検証が先
その次に、
- AIが実行し
- システムが検証し
- 人間が承認します
TL;DR
- プロンプトだけでは限界がある
- Context Engineeringが核心だ
- AIは執筆者ではなくレンダラーだ
- ワークフローはモデルより重要だ
リンク
この方法について意見やフィードバックがあれば、本当に歓迎します。
まだコメントはありません。