# Knowledge Base

> ランブック、アーキテクチャのメモ、コンテキストドキュメントをアップロードして、AI推奨事項があなたのシステムの実際の動作を反映するようにします。

Source: https://latchkey.dev/ja/documentation/knowledge-base

## Summary

- AI推奨事項の根拠とするために、ランブック、アーキテクチャドキュメント、慣習(`.md`、`.yaml`、`.yml`、`.txt`、`.json`、最大500KB)をアップロードします。
- 監視中のリポジトリは自分自身をインデックス化します: README、docsフォルダー、ワークフローファイル、その他のCI設定。
- CI/CDの知識を厳選した **System** ライブラリが標準で含まれています。読み取り専用です。
- より良い根拠は、あなたのシステムの実際の動作を尊重する推奨事項につながります。

**Knowledge Base** ページでは、ワークフローファイルには見えないコンテキストをLatchkeyのAIに与えられます: ランブック、アーキテクチャドキュメント、デプロイの慣習、命名基準、そしてエンジニアがCIへの変更を提案する前に知っておきたいその他すべてです。

## 仕組み

監視を有効にすると監視中のリポジトリは自動的にインデックス化されるので、AIはすでにあなたのワークフローのレイアウトを把握しています。Knowledge Baseはそれを超えるすべてのためのものです。

## 自動でインデックス化されるもの

リポジトリで監視を有効にすると、Latchkeyはそのドキュメントを自分でインデックス化します:

- `README.md`、`CONTRIBUTING.md`、および `SECURITY.md` や `CHANGELOG.md` などのルートレベルのドキュメント。
- `docs/`、`doc/`、`documentation/` フォルダー内のMarkdown。
- GitHub Actions のワークフローファイル。
- `CODEOWNERS` に加えて、イシューとPRのテンプレート。
- CircleCI、Jenkins、Travis、GitLab CI、Bitbucket Pipelines、Azure Pipelines を含む他システムのCI設定。

変更のないファイルは再インデックス時にスキップされるので、繰り返し作業なしにインデックスは最新に保たれます。誰も何もアップロードしなくても、AIはあなたの実際のワークフローとドキュメントを把握します。

## 組み込みの System ライブラリ

Latchkeyは、言語、フレームワーク、CI/CDツール、ランナーパターンをカバーする、CI/CDの知識を厳選したライブラリも同梱しています。これらのドキュメントは **System** バッジ付きでテーブルに表示され、読み取り専用で削除できません。実用的な効果: あなたが何かをアップロードする前から、初日から推奨事項はしっかりと根拠を持っています。

## ドキュメントのアップロード

**Upload Document** をクリックして自分のものを追加します。内容を直接入力または貼り付けるか、ドラッグ＆ドロップまたは参照でファイルを読み込みます。各ドキュメントにはタイトル(最大200文字)と内容が必要で、入力中に文字数がライブで表示されます。受け付けるファイルタイプは `.md`、`.yaml`、`.yml`、`.txt`、`.json` で、1ドキュメントあたり最大500KBです。ダイアログは、何かが保存される前にサポートされていないタイプや大きすぎるファイルをフラグします。

## 根拠が推奨事項をどう変えるか

腕の良い請負業者からの助言と、あなたのコードベースで1年働いたエンジニアからの助言の違いだと考えてください。どちらもあなたのワークフローファイルを読めますが、どのパイプラインがデプロイに不可欠か、どの失敗が既知の問題か、なぜキャッシュが今のように設定されているかを知っているのは片方だけです。

その成果は、[AI Insight](/documentation/optimization-insights) を含むLatchkeyのAIサーフェス全体に現れます: ここでアップロードするものは、Latchkeyが推論の拠り所とするグラウンドトゥルースの一部になるため、提案される内容があなたのシステムの実際の動き方を尊重したものになります。

## 効果の高いアップロード

- **インシデントのランブック** 最も不安定なパイプラインのプレイブックは、あなたにとって "既知の問題" がどう見えるかをAIに教えます。
- **デプロイに不可欠なものの地図** どのワークフローがデプロイに不可欠かを記したドキュメントは、推奨事項がどれだけ積極的になれるかを変えます。
- **慣習** キャッシュ、アーティファクト、命名の社内基準は、提案される変更をあなたのチームにとって自然なものに保ちます。

### 良いアップロードとはどのようなものか

洗練されたドキュメントは必要ありません。必要なのは決定を担うドキュメントです。うまく機能する具体的な形をいくつか挙げます(要件ではなく提案です):

- **不安定なパイプラインのランブック**。CIに現れる通りにワークフローを名指しし、チームが "既知" とみなす失敗のシグネチャを説明し、受け入れられている回避策を述べます。
- **デプロイマップ**。どのワークフローが本番を制御し、どれが人によるレビューなしに決して変更してはならないかを列挙します。
- **慣習のドキュメント**。キャッシュとアーティファクトの命名方法、そして重要なことに、なぜそれらのルールが存在するのかを明記します。
- **アーキテクチャのメモ**。部外者には推測できない関係を説明します: どのサービスが一緒にビルドされるか、何が何に依存するか、荷重を支える奇妙さがどこにあるか。

共通する筋: 何をするかだけでなく、**なぜ**かを書き留めることです。AIはワークフローが何をするかはすでに見えます。見えないのは、その背後にある理由と制約です。

**アップロード前の簡単なセルフチェック**
- [ ] 最新である: 古いドキュメントは、以前どう動いていたかにAIの根拠を置いてしまう
- [ ] CIに現れる通りにワークフローとリポジトリを名指ししている
- [ ] 各ルールが何であるかだけでなく、なぜ存在するかを説明している
- [ ] 何が改善できるかだけでなく、何を変えてはならないかを述べている

## AIが把握している内容を見る

インデックス化された各ドキュメントは、タイトル、ソースバッジ、パス、インデックス化時刻とともにソート可能なテーブルに表示されます。サマリー行はドキュメント数、表現されているリポジトリ数、最も最近のインデックス化がいつ実行されたかを示します。テーブルは1ページ10ドキュメントでページ分割され、全画面ビューを備え、ソースフィルターが一覧を1つのスライスに絞り込みます: All Sources、README、Workflow、Docs、Manual、または System。

| ソースバッジ | 何を示すか |
| --- | --- |
| README | リポジトリのREADMEファイル |
| Workflow | GitHub Actions のワークフローファイル |
| Docs | リポジトリのドキュメントフォルダー由来のMarkdown |
| Manual | あなたのチームがアップロードしたドキュメント |
| System | Latchkeyの厳選されたCI/CDライブラリ(読み取り専用) |

System以外のドキュメントは、その行から削除できます。Latchkeyはまず確認を求め、削除は取り消せません。

> **自己修復も安全に読み取ります**
> [自己修復](/documentation/self-healing)のランナーが修正を割り出すとき、制限され、レート制限され、監査されたクエリチャネルを通じてLatchkeyの厳選された知識を参照します。修復が知識検索を待って停滞することは決してなく、あなたのナレッジベースがビルド環境に露出することも決してありません。

### ナレッジベースにアップロードできるファイル形式は?

Markdown、YAML、プレーンテキスト、JSON (`.md`、`.yaml`、`.yml`、`.txt`、`.json`) で、1 ファイル 500KB までです。ランブック、アーキテクチャのメモ、チームの規約は、リポジトリ自体には残らない意思決定を含むため、最も効果の高いアップロードです。

### 動作させるには何かアップロードが必要ですか?

不要です。監視対象のリポジトリは自動的にインデックスされ、README、ドキュメントフォルダ、ワークフローファイル、その他の CI 設定が対象になります。さらに CI/CD の知識をまとめた読み取り専用の System ライブラリが標準で付属します。アップロードはその基盤に自社の文脈を追加するものです。

### グラウンディングは実際に何を変えますか?

推奨内容が自社のシステムの実態に沿うかどうかが変わります。ランブックがなければモデルは一般的な CI の慣行から推論しますが、あれば、あえて通常と違う方法を採った理由となる制約も考慮できます。それが「適用できる提案」と「却下する提案」の違いです。

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt