ドキュメントメニュー
はじめに
ダッシュボードと分析
マネージドランナー
キャッシュ
チームと通知
請求とプラン
ヘルプ
Knowledge Base
ランブック、アーキテクチャのメモ、コンテキストドキュメントをアップロードして、AI推奨事項があなたのシステムの実際の動作を反映するようにします。

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はあなたのワークフローファイルと実行履歴だけから推論します
- 提案は一般的なCIパターンに従い、それはあなたのパターンではないかもしれません
- どのワークフローを積極的に触っても安全かを知る手段がありません
根拠あり
- 提案される変更は、あなたのキャッシュ、アーティファクト、命名の基準にとって自然なままです
- デプロイに不可欠なものの地図が、推奨事項がどれだけ積極的になれるかを変えます
- ランブックは、あなたのチームにとって "既知の問題" がどう見えるかをAIに教えます
その成果は Optimization Insights に現れます: エージェントは各ワークフローをあなたのKnowledge Baseをコンテキストとして分析するので、ここでアップロードするものが、そこで提案される内容を直接形づくります。
効果の高いアップロード#
良いアップロードとはどのようなものか#
洗練されたドキュメントは必要ありません。必要なのは決定を担うドキュメントです。うまく機能する具体的な形をいくつか挙げます(要件ではなく提案です):
- 不安定なパイプラインのランブック。CIに現れる通りにワークフローを名指しし、チームが "既知" とみなす失敗のシグネチャを説明し、受け入れられている回避策を述べます。
- デプロイマップ。どのワークフローが本番を制御し、どれが人によるレビューなしに決して変更してはならないかを列挙します。
- 慣習のドキュメント。キャッシュとアーティファクトの命名方法、そして重要なことに、なぜそれらのルールが存在するのかを明記します。
- アーキテクチャのメモ。部外者には推測できない関係を説明します: どのサービスが一緒にビルドされるか、何が何に依存するか、荷重を支える奇妙さがどこにあるか。
共通する筋: 何をするかだけでなく、なぜかを書き留めることです。AIはワークフローが何をするかはすでに見えます。見えないのは、その背後にある理由と制約です。
アップロード前の簡単なセルフチェック
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はまず確認を求め、削除は取り消せません。