kibi-mcp

意図をプロンプトで伝えましょう。Kibiがエージェントにそれを記憶させ、実装を証明します。

_{各ケースでKibiが報告する内容を簡略化したものです。}

Kibiは、エージェントを中心に設計された要件コンパイラー兼適用レイヤーです。自然言語で製品の意図を記述すると、エージェントが構造化された要件、シナリオ、テスト、意味的な事実、コードへのリンクを作成し、維持します。その後Kibiが、実装がその意図と一貫しているかを確認します。

受動的なメモリや検索システムとは異なり、Kibiはエージェントのワークフローに組み込まれるよう設計されています。エージェントがチケット、ボード、要件フォルダーを参照することを覚えておく必要はありません。Kibiのフック、ツール、検証ゲートが、関連する製品コンテキストを継続的に作業に反映します。

ドキュメント · クイックスタート · Kibi自身の健全性レポート

Kibi を選ぶ理由

プロジェクトに関する知識の大半は、プロンプト、チケット、コード、会話に散在しており、ほとんどの AI エージェントはいずれその一部を忘れてしまいます。Kibi はその知識を、強制力のあるブランチ単位のモデルに変換します。

• 人間は成果物ではなく意図を管理します — プロンプトが主要な作成インターフェースです。要件、シナリオ、テスト、事実、シンボルリンクの作成と発展という定型作業はエージェントが担い、人間は真の曖昧さやプロダクト上の判断を解決します。
• メモリには強制力があります — シンボルには要件の所有者が必要で、要件には完全な意味情報とシナリオが必要です。シナリオにはテストが必要で、証拠を伴うテストには最新の実行証拠が必要です。
• Prolog がドリフトを防ぎます — 型付きプロパティ、述語、安全なルールにより、決定論的なチェックで矛盾、根拠のない創作、不完全な意味情報を、プロジェクト知識として受け入れられる前に検出できます。
• E2E の動作を追跡できます — Kibi は、エンドツーエンドテストで実行された行だけでなく、テストが何を証明するのかを記録します。シンボルからその要件へ、またはテストから検証対象のシナリオや意図へとたどれます。
• ブランチを切り替えても意図が保たれます — 各 Git ブランチには独自の KB スナップショットがあるため、機能のコンテキストは分離された状態で保たれ、戻ったときにも利用できます。
• さまざまな言語で動作します — TypeScript と JavaScript のシンボル抽出機能を標準搭載しています。オプションの kibi-plugin-treesitter を追加すると、固定された WASM 文法を使って、Python、Go、Rust、Java、C#、PHP、C、C++、Bash、Ruby、Terraform/HCL のシンボルをオフラインで抽出できます。
• オプションの UI デザインガード（実験的） — kibi-plugin-ui は、React と Angular のコンポーネントが合意済みのデザインパターンに従うようにします。ピクセル、色、間隔はリンターに任せます。
• 知識をローカルに保ちます — KB の状態はリポジトリの .kb/ ディレクトリに保存されます。Kibi のパッケージは外部へのテレメトリーや分析データを一切送信しません。訪問数を計測するのはドキュメントサイトのみで、Cookie を使用しない Umami 分析を利用します。

クイックスタート

Kibi はコーディングエージェントがセットアップして操作することを想定しているため、推奨するインストール方法はコマンド一覧ではなくプロンプトです。Kibi には Node.js 22+ が必要です。SWI-Prolog は同梱されています。Linux（x64 または arm64、glibc 2.28+）および macOS（Apple シリコンまたは Intel）では、ほかにインストールするものはありません。Alpine/musl やネイティブの Windows（WSL を使用）など、その他のプラットフォームでは、SWI-Prolog 9.0+ をインストールし、swipl を PATH に追加してください（詳細）。

推奨：エージェントにセットアップを任せる。 Claude Code、Cursor、Codex、OpenCode、またはリポジトリ内でコマンドを実行できるコーディングエージェントに、次の内容を貼り付けてください。

Set up Kibi (https://github.com/Looted/kibi) in this repository, then bootstrap its knowledge base.

1. Install: confirm Node.js 22+ is available. With the package manager this repository already uses, add kibi-core, kibi-cli and kibi-mcp as dev dependencies. Do not skip optional dependencies; the bundled SWI-Prolog runtime is one.
2. Initialize: run every `kibi` command through the package manager's local runner (npm: `npm exec -- kibi <command>`). Run `kibi init`; if it reports a problem, run `kibi doctor` and fix what it names. If this platform has no bundled SWI-Prolog, tell me what to install and stop.
3. Connect: register the project-local `kibi-mcp` server for the agent host you are running in, following https://looted.github.io/kibi/guide/connect-an-agent.html. Prefer project-scoped configuration, and ask me before installing a plugin or changing global settings. Until the kb_* tools are visible to you, use Kibi's CLI JSON routes instead.
4. Bootstrap: run `kibi skills load kibi-bootstrap --format markdown` and follow that skill exactly. It starts by asking me where product intent lives outside the code (issue trackers, wikis, specs) and which sources to trust; read them through the connectors you have and cite them. Show me the complete plan and its hash, and write nothing until I approve it.
5. Verify: run `kibi check` and `kibi status`, fix anything they report, and summarize what was added. Do not commit; I will review the changes.

このあと、次のことが行われます。

1. セットアップ。 エージェントがパッケージをインストールし、kibi init を実行して、自身を Kibi に接続します。
2. ヒアリング。 製品の意図がすでにどこにあるか（Jira や YouTrack などの課題トラッカー、Wiki、仕様書）と、どの情報源を信頼するかを尋ねます。
3. 計画。 利用可能なコネクターを通じてそれらの情報源を読み込み、ブートストラップ計画を作成します。計画内のすべての要件には、その出典となったチケットまたはページが記載されます。情報源間で見つかった未解決の質問や矛盾は、要件にするのではなく、確認事項として示されます。
4. 承認。 計画とそのハッシュ値が表示されます。承認するまで、何も書き込まれません。
5. 適用と確認。 計画を適用して結果を検証したあと、受け入れ基準に基づくシナリオや、新しい要件に対する機械で検証可能な事実など、計画では書き込めなかった内容を補います。追加した内容も知らせてくれます。

その後は通常どおり、機能追加、修正、リファクタリングを依頼してください。エージェントが要件、シナリオ、テスト、コードのリンクをコードと連動させて保ちます。

npm install --save-dev kibi-core kibi-cli kibi-mcp
npm exec -- kibi init

アップグレード。 Kibi パッケージを更新したあと、kibi migrate を実行するか、エージェントに実行を依頼してください。変更内容が表示され、承認するまで適用されません。CLI リファレンスでは、各スキーマバージョンについて説明しています。

コーディングエージェントを接続する

上記のセットアッププロンプトで、この手順は完了します。手動で行う場合、すべてのクライアントで、同じプロジェクトローカルの kibi-mcp サーバー（npx --no-install kibi-mcp、stdio、作業ディレクトリ＝リポジトリ）を起動します。オプションのプラグインを追加すると、バンドルされたスキルやフックも利用できます。

claude plugin marketplace add Looted/kibi

claude plugin install kibi-claude@kibi

claude mcp add --scope project kibi -- npx --no-install kibi-mcp

{
  "mcpServers": {
    "kibi": {
      "command": "npx",
      "args": ["--no-install", "kibi-mcp"]
    }
  }
}

codex mcp add kibi -- npx --no-install kibi-mcp

codex plugin marketplace add Looted/kibi

{
  "mcp": {
    "kibi": {
      "type": "local",
      "enabled": true,
      "command": ["npx", "--no-install", "kibi-mcp"]
    }
  },
  "plugin": ["kibi-opencode"]
}

{
  "servers": {
    "kibi": {
      "type": "stdio",
      "command": "npx",
      "args": ["--no-install", "kibi-mcp"]
    }
  }
}

エージェントが利用できる機能

Kibi のスキルサブシステムには、エージェントに Kibi の使い方を教える6つのスキルがバンドルされています。そのため、長いシステムプロンプトを貼り付ける必要はありません。あとは少数の MCP ツールで対応できます。

• 平易な言葉で回答します。 「チェックアウトの丸め処理を規定しているものは？」と尋ねると、kb_search が現在の要件、それを裏付けるテストや決定事項、およびそれぞれに対する Kibi のチェック結果を返します。
• すべての変更をレビューします。 エージェントが変更したファイルに対して kb_check を実行すると、そのコードが実装する要件を引用し、どの要件にもカバーされていない新しいコードにフラグを立てます。
• 安全に書き込みます。 すべての書き込みは事前にプレビューでき、承認した計画は全体が適用されるか、まったく適用されないかのどちらかです。

「MCP リファレンス」には、すべてのツールが記載されています。汎用エージェントはエージェントのオンボーディングから始められます。

各保証の確かさを確認する

npm exec -- kibi report --open

kibi report は、1つのカバレッジスナップショットから、自己完結型の kibi-report/index.html と kibi-report/badge.svg を生成します。% tested は、現在のコードに対して新しいエンドツーエンドの証拠がある、現在の要件の割合です。レポートには、テスト済みの内容、証拠が不足している内容、矛盾している内容、古くなった内容が一覧表示されます。

すべての要件には証拠レベルも付与されるため、保証が裏付け以上に強く見えることはありません。証明済み（要件のすべての主張がすべてのケースで成り立ち、その主張を明記した exhaustive、typecheck、arithmetic、smt、rule、state_machine、regex、または source の証明契約に基づく新しい証明書で裏付けられており、別個のチェッカーが再検証します。主張は数値である必要はありません。権限ルール、すべてのメンバーに関するプロパティ、状態遷移、決して到達できない状態、必須フィールド、文字列形式はコードに照らして厳密に判定されます。また、source 証明では、Kibi がプロジェクト自体から読み取るルート、データベーススキーマ、設定、バリデーター、コード参照を検証します）、テスト済み（新しいエンドツーエンドのレシートが、リンクされたすべてのシナリオを網羅しています）、明言済み（担当者がその内容を保証していますが、現在それを検証するものはありません）、未検証（エージェントが記述し、担当者による承認がありません）。kibi coverage は要件ごとの evidenceLevel と、件数を示す summary.evidenceLevels を返します。レポートと kibi signoff では、確かさと並べて表示されます。証明の段階、証明書の証明種別については要件の証明、詳細についてはレポートの読み方をご覧ください。

ナレッジベース自体も同じ方法で検証されます。kibi check（エージェント向けの kb_check）は、要件に記述された事実に矛盾がないこと（プロパティごとにすべての事実を満たす値が1つ存在すること、各判断の結果が1つであること）と、保存されたルールが層化されていることを証明し、各回答の証明書を生成します。小規模な別個のチェッカーがその証明書を再検証します。また、ペアごとのチェックでは検出できない、複数の事実がそろったときだけ生じる矛盾も検出します。矛盾がある場合、一度にすべてが成り立つことのない最小の事実集合が返されます。比較できないものは未解決として報告され、整合しているとは決して扱われません。

変更を承認する前に、kibi signoff は追加、書き換え、または影響を受ける要件を、それぞれの確かさ、証明状態、証拠レベルとともに引用して表示します。また、kibi signoff --questions は、次に判断が必要な項目に番号を付け、それぞれが変更するルールと並べて表示します。エージェントはこの表示をプレーンな Markdown として返信に含めるため、チャットアプリや、メッセージングツール経由で返信するクラウドセッションなど、エージェントが文章を出力する場所であればどこでも表示できます。同じ内容は .kb/briefs/signoff/latest.html に自己完結型のページとして保存されます。Claude Code、Cursor、ZCode、OpenCode には /kibi-signoff コマンドが追加され、OpenCode ではカードとして表示され、VS Code ではパネルで開きます。また、エージェントフックはセッション中に要件が書き込まれると、承認ビューの表示を求めます。

GitHub Pages にレポートとクリック可能なバッジを公開するには、npm exec -- kibi init --github を実行してから、Settings → Pages → Source → GitHub Actions を有効にします。GitHub 統合ガイドでは、レポートのワークフロー、バッジのみの公開、Kibi 自身のファイルだけが競合した場合でもプルリクエストをマージ可能に保つCI ステップについて説明しています。シンボルの行位置はコミットされません。各 kibi sync がそれらを Git の無視対象キャッシュに生成するため、同じソースファイルを編集する2つのブランチが行位置をめぐって競合することはありません。

日常的な確認には、kibi status、kibi search、kibi gaps、kibi coverage、kibi check をCLI リファレンスでご覧ください。

仕組み

Kibi は、確率的な解釈と決定論的な検証を組み合わせます。

Human prompt
    |
    v
Agent updates code and product knowledge
    |
    v
Requirements + semantic facts/rules + scenarios + tests + symbol links
    |
    v
Prolog coherence checks + traceability gates + fresh E2E evidence
    |
    v
Tested result or explicit, repairable gaps

エージェントが、信頼できる真実として任意の Prolog を書くことはありません。型付きの事実、述語スキーマ、安全な論理表現を通じて作業します。Kibi は、それらのエンコーディングを検証してから、Prolog レイヤーが推論に使用します。

Kibi が適用すること

Kibi は、正規化されたトレーサビリティと証明の連鎖を維持します。

Requirement -> Scenario -> Test
     ^                       ^
     |                       |
 Production symbol     Executable test symbol

要件が単に文書化されるだけでなく、エンドツーエンドでテストされるようにするには、次の条件が必要です。

• すべての本番シンボルが、それによって実装される要件まで追跡できる必要があります。
• すべての規範的な要件条項は、型付きの事実としてモデル化するか、明示的に未解決のままにしておく必要があります。
• 要件はシナリオで定義し、テストでそれらのシナリオを検証する必要があります。現在の要件で禁止されていることを前提とする成功シナリオがあると、証明はブロックされます。
• 実行可能なテストシンボルは、実際に検証を行うコードを特定する必要があります。
• 証明を担う本番シンボルは、条件を満たすテストでカバーされている必要があります。また、コミット前フックにもフルチェックと同じルールが適用されます。
• エンドツーエンドの証拠は最新で、現在のコードスナップショットに紐付いている必要があります。これにより、CI と同じコミットのローカルチェックアウトで結果が一致します。

これにより、「このシンボルを担当する要件はどれか」「この E2E テストは実際に何を検証しているのか」「シナリオや最新の証拠が不足している要件はどれか」「現在有効な 2 つの要件が矛盾しているか」といった問いに、どちらの方向からも答えられます。コードカバレッジだけでは答えられません。コードカバレッジが示すのは、テストがどの行に触れたかであり、どの製品動作が検証されたかではありません。

安全レイヤーとしての Prolog

製品でユーザーロールが正確に 3 つ定義されているとします。その制約が厳密なプロパティまたは述語としてエンコードされていれば、エージェントが 4 つ目のロールをひそかに作り出し、それを確立された意図として扱うことはできません。Kibi は、矛盾や認可の欠落を決定論的に明らかにできます。

Kibi は、判断できなかった場合に「競合なし」と報告することはありません。数値制約は厳密に比較されます（「0 より大きい」と「0 に等しい」は矛盾します）。同じアクションに対する許可と拒否は矛盾し、Kibi がモデル化できないものは、問題なしとして通過させるのではなく、エージェントが確認できるよう未解決として報告されます。

Prolog は、元となる人間の意図が正しかったかどうかを判断しません。エンコードされた知識を検証し、Kibi は曖昧さ、オントロジーの欠落、根拠付けの不完全さ、証拠の古さを明示したままにします。それらを証明と見なすことはありません。

なぜ今これが可能なのか

従来のナレッジベースでは、専門家がオントロジーを設計し、形式論理を記述して、すべてのマッピングを手作業で維持する必要がありました。LLM によって、その作成工程にかかるコスト構造が変わり、Kibi と Prolog が規律をもたらします。

その結果、LLM の弱点である限られた記憶力、幻覚、コンテキストのずれ、そして従来はプロダクトオーナー、チケット管理システム、計画ボードに分散していた製品とコードのマッピングの喪失に対処するために、LLM の強みを活用できます。

Kibi がモデル化するもの

8 種類のエンティティ型があります：req、scenario、test、fact、adr、flag、event、symbol。モデル全体については、エンティティスキーマをご覧ください。

すべてのエンティティには、作成者（人またはエージェント）が記録されます。また、アドバイザリーチェックでは、人が承認していないエージェント作成の要件が一覧表示されます。

要件と ADR には、決定の確かさも示されます。firm ルールは人が明言したもので、その人の発言を参照し、エージェントは変更前に確認を求め、Kibi は黙って書き換えることを拒否します。default の選択は、証拠に基づいて見直すことができ、exploratory は推測であることを示します。置き換えには、その変更理由を必ず記載する必要があります。詳しくは、Kibi の仕組みをご覧ください。

パッケージ

プロジェクトに kibi-core、kibi-cli、kibi-mcp をインストールしてください。それ以外はすべてオプションです。

ドキュメント

ガイドとリファレンスは https://looted.github.io/kibi/ で公開されています。言語モデルは、ドキュメントインデックスから参照を開始できます。

• インストール — 同梱の SWI-Prolog ランタイム、パッケージマネージャー、プラグイン、検証
• Kibi の仕組みと証明の段階
• 要件の証明 — 証明コントラクト、kibi prove、レシート
• CLI リファレンスとMCP リファレンス
• エンティティスキーマと推論ルール
• アーキテクチャ — ストレージ、ブランチ分離、データフロー
• トラブルシューティング

ベータ版の状況

Kibi はベータ版で、実際のプロジェクトですぐに使用できます。公開インターフェースは 1.0 のリリース前に変更される可能性があるため、再現性が重要な場合はパッケージのバージョンを正確に固定してください。

Kibi は AGPL-3.0-or-later の下でライセンスされています。