
Kiro CLIのKnowledge managementを試してみた
はじめに
こんにちは、コンサルティング部の神野です。
最近、Kiro CLIのドキュメントを見ていたらKnowledge managementが追加されていることに気づきました。
ローカルのファイルやディレクトリをインデックス化して、チャットセッションを跨いで検索できるようになったみたいです。
面白そうで早速試してみました。
Knowledge management
Kiro CLIのナレッジ機能は、ローカルのファイルやディレクトリを永続的なナレッジベースとしてインデックス化し、チャットセッション内から検索できる機能です。
指定したディレクトリ内のファイルを再帰的にインデックス化し、インデックスのタイプも用途に応じて2種類(FastとBest)から選択可能で検索を実現できます。
またエージェントを切り分ければ、それぞれが分離したナレッジベースを持ちコンテキストを汚染することも回避可能です。
まさにローカルRAGですね。ローカルにあるデータを検索して回答を作成および、調査して欲しい際に役立ちそうな印象を受けました。ローカル内に大量にドキュメントがあるけど検索するのが面倒だな・・・と思った際にサクッと活用してみたいです。
インデックスタイプ:FastとBestの違い
FastとBestの2種類があると書きましたが、説明していきます。
Fast(キーワード検索 - BM25)
キーワードベースの高速検索です。メリットとしてキーワード検索のためインデックス化も早く検索結果の返却も早いです。
一方でデメリットとしては正確なキーワード一致が必要なところでしょうか。
ログファイルや設定ファイル、大規模コードベースの検索に向いていると記載がありました。
Best(セマンティック検索 - all-minilm-l6-v2)
AIモデルを使った意味ベースの検索です。
メリットとして文脈や意味を理解して対応するドキュメントを検索できるのは嬉しいポイントです。なので正確なキーワードでなくても関連するトピックを拾うことが期待できます。
一方でデメリットとしてはインデックス化に時間がかかる、CPUとメモリを多く消費するなどが挙げられます。こちらはドキュメントや研究資料の検索に向いていると記載がありました。
ちなみにall-minilm-l6-v2といったモデルを使ってベクトル化しているようです。
使い分けの目安
ドキュメントや論文などはBestが良さそうですね。一方で大量のデータを含んでいそうな、ログファイルやコードなどはFastを使うのが推奨されています。
ユースケースに応じてナレッジベースを細分化したりタイプを考えたいところです。
| ユースケース | 推奨タイプ |
|---|---|
| ログファイル、エラーメッセージ | Fast |
| 設定ファイル | Fast |
| 大規模コードベース | Fast |
| ドキュメント | Best |
| 研究論文 | Best |
実際にやってみる
それでは、実際にKnowledge managementを試してみます。
Knowledge managementの有効化
まずは設定でKnowledge managementを有効化します。
kiro-cli settings chat.enableKnowledge true
今回ナレッジにしたいレポジトリをPull
今回はサンプルとしてFastAPIのドキュメントをナレッジベースに加えてみることにします。
mkdir sample-knowledge-management
cd sample-knowledge-management
git clone https://github.com/fastapi/fastapi.git
プロジェクトをナレッジベースに追加
今回は手元のプロジェクトのドキュメントをインデックス化してみます。セマンティック検索を使いたいので --index-type Best を指定しました。
対象のフォルダは日本語ドキュメントが含まれているdocs/ja/docsとします。
# Kiroを起動
kiro-cli
# ナレッジベースを追加
/knowledge add --name "fastAPI-docs" --path fastapi/docs/ja/docs --index-type Best
今回は指定しませんが、特定のファイルを除外したい場合は、--exclude オプションを使います。
/knowledge add --name "my-codebase" --path /path/to/project --exclude "target/**" --exclude "node_modules/**" --index-type Fast
インデックス状態の確認
/knowledge show コマンドで、インデックス化の進捗を確認できます。
> /knowledge show
👤 Agent (kiro_default):
📂 fastAPI-docs (baa17fca)
/Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs
67 items • Best • 12/13 02:58
バックグラウンドでインデックス処理が走っている場合は、進捗状況とETAも表示されます。(対象ドキュメントが少なかったのか一瞬で終わったのでETAが表示されることはなかったです・・・)
検索してみる
インデックス化が完了したら、チャット内で自然言語で質問するだけでナレッジベースを検索してくれます。
検索プロンプト
「FastAPIの非同期実装のコツを教えてください、引用元ドキュメントも添えてください」
回答
回答全文
Searching knowledge base for: async await 非同期 asynchronous in context: baa17fca-1187-4250-a6bf-5baa17f7287e (using tool: knowledge)
✓ Found 5 results for query 'async await 非同期 asynchronous'
- Completed in 0.16s
Searching knowledge base for: async def database connection pool in context: baa17fca-1187-4250-a6bf-5baa17f7287e (using tool: knowledge)
✓ Found 5 results for query 'async def database connection pool'
- Completed in 0.20s
> FastAPIの非同期実装のコツについて、引用元ドキュメントと共に説明します。
## FastAPIの非同期実装のコツ
### 1. 基本的な使い分け
#### awaitを使うライブラリがある場合
python
@app.get('/')
async def read_results():
results = await some_library()
return results
#### awaitをサポートしていないライブラリの場合
python
@app.get('/')
def results():
results = some_library()
return results
引用元: /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/async.md
### 2. データベース接続での実装
#### 非同期データベースライブラリ使用時
python
import asyncpg
async def get_database():
return await asyncpg.connect("postgresql://...")
@app.get("/users/{user_id}")
async def read_user(user_id: int):
conn = await get_database()
user = await conn.fetchrow("SELECT * FROM users WHERE id = $1", user_id)
await conn.close()
return user
#### 同期データベースライブラリ使用時
python
import psycopg2
def get_database():
return psycopg2.connect("postgresql://...")
@app.get("/users/{user_id}")
def read_user(user_id: int):
conn = get_database()
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
user = cursor.fetchone()
conn.close()
return user
### 3. 依存関係での非同期実装
python
from fastapi import Depends
async def get_db_connection():
conn = await asyncpg.connect("postgresql://...")
try:
yield conn
finally:
await conn.close()
@app.get("/items/")
async def read_items(db = Depends(get_db_connection)):
items = await db.fetch("SELECT * FROM items")
return items
### 4. WebSocketでの非同期実装
python
from fastapi import WebSocket
@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
await websocket.accept()
while True:
data = await websocket.receive_text()
await websocket.send_text(f"Message: {data}")
引用元: /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/advanced/websockets.md
### 5. パフォーマンス最適化のコツ
#### I/Oバウンド操作にはasync defを使用
- データベースクエリ
- API呼び出し
- ファイル読み書き
#### CPUバウンド操作には通常のdefを使用
- 複雑な計算処理
- 画像処理
- 機械学習の推論
### 6. 実装時の注意点
#### 混在使用が可能
python
@app.get("/sync")
def sync_endpoint():
return {"message": "sync"}
@app.get("/async")
async def async_endpoint():
await asyncio.sleep(1)
return {"message": "async"}
#### エラーハンドリング
python
@app.get("/data")
async def get_data():
try:
result = await external_api_call()
return result
except Exception as e:
raise HTTPException(status_code=500, detail=str(e))
### 7. よくある間違い
#### ❌ 間違い: async def内で同期関数を直接呼び出し
python
@app.get("/bad")
async def bad_example():
# ブロッキング操作
time.sleep(1) # これは避ける
return {"message": "bad"}
#### ✅ 正しい: 非同期版を使用
python
@app.get("/good")
async def good_example():
await asyncio.sleep(1) # 非同期版を使用
return {"message": "good"}
引用元: /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/async.md
これらのコツを活用することで、FastAPIの非同期機能を最大限に活用し、高パフォーマンスなAPIを構築できます。
ドキュメント量が少ないのもあってか早く検索して回答を作成してくれました。
引用元も添えられていますが、データベース関連の処理では引用がないので聞いてみます。
回答全文
> データベース関連はどこから引用しましたか?
> 申し訳ありません。データベース関連のコード例(asyncpgやpsycopg2を使った例)
は、私が一般的な知識から作成したもので、提供された知識ベースからの直接的な引 用ではありませんでした。
知識ベースから実際に引用した内容は以下の部分のみです:
## 実際の引用元
引用元:
/Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/async.md
### 基本的な使い分けの部分:
python
# awaitを使うライブラリがある場合
@app.get('/')
async def read_results():
results = await some_library()
return results
# awaitをサポートしていないライブラリの場合
@app.get('/')
def results():
results = some_library()
return results
### データベースに関する記述:
│ データベース、API、ファイルシステムなどと通信し、await の使用をサポート
していないサードパーティライブラリ (現在のほとんどのデータベースライブラリに
当てはまります) を使用している場合、次の様に、単に def を使用して通常通り
path operation 関数 を宣言してください
WebSocketの例の引用元:
/Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/advanced/websockets.md
データベース接続プールや具体的なデータベースライブラリの実装例については、知
識ベースに含まれていませんでした。
この機能に限った話ではないかと思いますが、それっぽく回答してたので、引用していると思っていましたが注意が必要な箇所もありそうですね。
明確にドキュメントだけから回答したい場合はプロンプトなどで制御しておく必要がありそうです。完全な混入を防ぐことは難しいと思いますが、例えば、簡単な例で言うと「ドキュメント外の知識では回答を作成しないでください」と入れてみるなどですかね。
回答全文
> FastAPIの非同期実装のコツを教えてください、引用元ドキュメントも添えてください。ドキュメント外の知識では回答を作成しないでください。
Searching knowledge base for: FastAPI 非同期 async await 実装 コツ in context: baa17fca-1187-4250-a6bf-5baa17f7287e (using tool: knowledge)
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:
> t
✓ Found 5 results for query 'FastAPI 非同期 async await 実装 コツ'
- Completed in 0.38s
> FastAPIの非同期実装のコツについて、ドキュメントから以下の要点をお伝えします:
## 基本的な使い分け
awaitを使用するライブラリを使っている場合:
python
@app.get('/')
async def read_results():
results = await some_library()
return results
awaitをサポートしていないライブラリを使っている場合:
python
@app.get('/')
def results():
results = some_library()
return results
## 重要なコツ
1. async defとdefの混在が可能
- 必要に応じてdefとasync defを混在させることができ、FastAPIが適切に処理します
2. 迷った場合は通常のdefを使用
- よく分からない場合は、通常のdefを使用することが推奨されています
3. awaitはasync def内でのみ使用可能
- async defで定義された関数の内部でしかawaitは使用できません
## パフォーマンス最適化のポイント
I/Oバウンド操作(推奨:async def):
- ネットワーク通信
- データベース操作
- ファイル読み書き
- リモートAPI呼び出し
CPUバウンド操作(推奨:通常のdef):
- 複雑な数学計算
- 画像・音声処理
- 機械学習処理
## 技術的な詳細
- async defで定義された*path operation関数*を通常のdefで宣言すると、外部スレッドプールで実行されます
- ブロッキングI/Oを実行しない場合はasync defの使用が推奨されます
- FastAPIは両方の方式を適切に処理し、高いパフォーマンスを実現します
References:
[1] 並行処理と async / await - /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/async.md
[2] ベンチマーク - /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/benchmarks.md
[3] デプロイ - /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/deployment/index.md
[4] 環境変数 - /Users/xxx/sample-knowledge-management/fastapi/docs/ja/docs/environment-variables.md
ベストプラクティス・注意点
ドキュメントに記載されているベストプラクティスをいくつか紹介します。
ナレッジベースの整理
どのナレッジベースを使用するか判断しやすいように「docs」ではなく「api-documentation」のように具体的にするのが大事と記載があります。
また、--include と --exclude で関連ファイルに絞ってノイズを減らすことも大切です
ドキュメントを更新したら、/knowledge update で最新の状態に保つことが可能です。
効果的な検索のコツ
曖昧な表現は避けて自然言語で具体的に質問するがよいです。もしヒットしなければ、言い回しを変えてみましょう。
月並みですが大事なポイントですね。
大規模プロジェクトの管理
大きいものは目的に合わせて、分割したいですね。関心ごとで分離するのが良さそうです。個別ファイルではなくディレクトリ単位で追加、ビルド成果物は除外、(target/**, node_modules/**, .git/**)検索したい単位や用途に応じてサブディレクトリに分割することも検討したいですね。
パターンフィルタリング
デフォルトのパターンを設定しておくと便利です。不要なものは検索結果のノイズになるのでできるだけフィルタリングしておきたいですね。
kiro-cli settings knowledge.defaultIncludePatterns '["**/*.rs", "**/*.md"]'
kiro-cli settings knowledge.defaultExcludePatterns '["target/**", "node_modules/**"]'
対応ファイル
また対応しているファイルも下記となります。
下記以外の拡張子ファイルはインデックス化されないので注意です。
Text files: .txt, .log, .rtf, .tex, .rst
Markdown: .md, .markdown, .mdx
JSON: .json (treated as text for searchability)
Configuration: .ini, .conf, .cfg, .properties, .env
Data files: .csv, .tsv
Web formats: .svg (text-based)
Code files: .rs, .py, .js, .jsx, .ts, .tsx, .java, .c, .cpp, .h, .hpp, .go, .rb, .php, .swift, .kt, .kts, .cs, .sh, .bash, .zsh, .html, .htm, .xml, .css, .scss, .sass, .less, .sql, .yaml, .yml, .toml
Special files: Dockerfile, Makefile, LICENSE, CHANGELOG, README (files without extensions)
エージェントの分離
今回はデフォルトのエージェント上でナレッジベースを追加しましたが、ここにポコポコと追加していくとデータが混在して適切なナレッジベースで検索されない可能性があります。ナレッジベースを分離したい際は目的に合わせてカスタムエージェント機能を使って分離しましょう。
ナレッジベースはエージェント単位で作成される仕組みなっています。
~/.kiro/knowledge_bases/
├── kiro_cli_default/ # デフォルトのエージェント
│ ├── contexts.json
│ ├── context-id-1/
│ │ ├── data.json
│ │ └── bm25_data.json
│ └── context-id-2/
│ └── data.json
├── my-custom-agent_<code>/ # カスタムエージェント
│ ├── contexts.json
│ └── context-id-3/
│ └── data.json
なので、カスタムエージェントに切り替えると今まで追加したナレッジベースは表示されません。
# カスタムエージェントを指定
kiro-cli chat --agent operations-review
[operations-review] > /knowledge show
👤 Agent (operations-review):
<none>
エージェント単位で分離されていることが確認できました。こちらのエージェントに独自のナレッジベースを追加することも可能です。
おわりに
今回は、Kiro CLIのKnowledge managementを試してみました。
ローカルのファイルを簡単にインデックス化して、チャットセッション内からセマンティック検索できるのは便利ですね!
特にドキュメントが多いプロジェクトで、サクッとローカルで試したい時などに良さそうです。
便利になったシーンなどあればまたブログで紹介したく思います。精度とかも気になりますよね。
ただ現時点では実験的な機能なので破壊的な変更がある可能性は留意しておきたいです。
本記事が少しでも参考になりましたら幸いです。最後までご覧いただきありがとうございました!







