Coador

Coador

コードを読み始める前に、AI エージェントに Android プロジェクトの地図を渡します。

Coador は Android リポジトリをローカルで決定論的にスキャンします。LLM は使用せず、プロジェクトのアーキテクチャ、Gradle 設定、テスト基盤、UI セレクター、CI/CD、その他の価値の高いコンテキストを網羅した、構造化された根拠付きのナレッジベースを構築します。

エージェントはまずそのナレッジを照会し、タスクに必要なファイルだけを確認します。

コンテキストの取得を高速化。発見作業の繰り返しを削減。トークン使用量を低減。

Coador は Android リポジトリをローカルのナレッジベースに変換します。AI エージェントは、プロジェクト全体を何度も読み直して情報を再発見する代わりに、そのナレッジベースを照会できます。

Coador の基本的な考え方はシンプルです。スキャン自体には AI も LLM も使用しません。

Coador は Android プロジェクトを決定論的に分析し、開発やテストの自動化に最も役立つ情報を抽出して、構造化された形式で保存します。そこには、アーキテクチャのシグナル、Gradle 設定、モジュールと依存関係、テスト基盤、UI セレクター、ディープリンク、CI/CD、テストランナー、フィクスチャ、依存性注入のオーバーライド、その他のプロジェクトレベルの知識が含まれます。

その結果、AI エージェントは新しいタスクのたびに、大規模なリポジトリを一から調べ直す必要がなくなります。適切な Gradle ファイルを探したり、モジュール構成を再構築したり、テストフレームワークを特定したり、UI テストの構成を把握したりする作業が不要になります。

代わりに、エージェントはあらかじめ用意されたナレッジベースを照会し、そのとき必要なプロジェクトの部分に絞った簡潔な回答を取得できます。

これにより、リポジトリの調査を繰り返す手間を減らし、モデルのコンテキストに取り込む必要があるソースコードの量を抑え、不要なトークン消費を削減できます。

スキャナーで AI を使わない理由

Coador は、事実の抽出と AI による解釈を意図的に分離しています。

リポジトリは、専用の決定論的な検出器によってローカルでスキャンされます。これらの検出器はアーキテクチャの説明を生成せず、プロジェクトの設計を推測しようともしません。Coador が記録するのは、ソースファイル、Gradle 設定、またはリポジトリ構造によって裏付けられるシグナルだけです。

たとえば、次のように断定する代わりに、

このプロジェクトは Clean Architecture を使用しています。

Coador は、次のように報告することがあります。

domain、data、feature モジュールが見つかり、それらの間で確認された依存関係も特定されました。

エージェントは事前に生成された解釈ではなく根拠を受け取り、その根拠に基づいて自ら推論できます。

可能な限り、Coador は各検出結果の出典情報も保持します。具体的には、出典ファイルと正確なソース行、ファイル単位の観察結果、または設定済みの Gradle モデルから取得した値です。

仕組み

Coador は Android リポジトリをスキャンし、プロジェクトの構造化されたローカルプロファイルを作成します。分析対象は次の 9 つの主要領域です。

レイヤー	対象
プロジェクト概要	リポジトリの識別情報、構造、アプリケーション、UI のシグナル
Gradle とビルド	ビルドシステム、SDK、バリアント、タスク、設定
アーキテクチャ	DI、ネットワーク、永続化、ナビゲーション、状態、並行処理
モジュール	モジュールの一覧、種類、確認された依存関係
設定	環境、ビルド設定、リソース、シークレット、機能フラグ
依存関係	スタックごとにグループ化されたライブラリとバージョン
テスト	ユニットテストとインストルメンテーションテスト、ランナー、フィクスチャ、テストタスク
UI テスト	フレームワーク、画面オブジェクト、セレクター、ディープリンク、コンポーネント
CI/CD	パイプライン、デバイス、レポート、アーティファクト、再試行、通知

完全なカタログには現在 84 個の検出器が含まれており、 docs/detectors.md で生成されています。

得られた知識はローカルに保存され、開発者と AI ツールの両方が利用できます。開発者は CLI と、人が読みやすい Markdown ビューを利用できます。AI エージェントは MCP インターフェースを通じて、プロジェクト概要の読み取り、情報の検索、根拠となる情報を添えた個別セクションの取得ができます。

Android repository
        ↓
Coador scan
        ↓
structured local knowledge base
        ↓
AI agent queries only the information it needs
        ↓
agent opens specific source files only when required

Coador は 2 種類の調査結果を生成します。シグナルは、確認された機能とその根拠のサンプルを報告します。インベントリは、ディープリンク、エクスポートされたコンポーネント、UI テストのリテラルセレクターなど、収集した値を保持します。インベントリでは、文書化された収集範囲内での状態を complete、incomplete、unknown のいずれかとして示します。

デフォルトのスキャンではリポジトリ内のテキストを読み取り、Android のツールチェーンは必要ありません。オプションの --gradle パスでは、信頼できるプロジェクトの設定済みビルドを使って、規約プラグインで宣言されたバリアントなど、静的なテキストからは解決できない情報を取得します。各セクションには、情報源が heuristic か gradle かが示されます。

実用例

AI エージェントが新しい Android UI テストを追加する必要があるとします。

Coador がなければ、エージェントはまず次の点を調べる必要があるかもしれません。

• インストルメンテーションテストがどこに配置されているか。
• どのテストランナーが使われているか。
• 共通のベーステストがあるか。
• スクリーンオブジェクトやロボットがどのように構成されているか。
• プロジェクトで Espresso、Kaspresso、Compose のテストのどれが使われているか。
• テストで認証がどのように処理されているか。
• 既存のセレクターはどれか。
• テスト用の DI やフェイク依存関係が利用できるか。
• テストをローカルおよび CI でどのように実行するか。

大規模なリポジトリでは、実際の作業を始める前に何十ものファイルを調べて、これらの疑問に答える必要がある場合があります。

Coador を使えば、こうした情報の多くはすでに収集され、構造化されています。エージェントは必要なテストインフラストラクチャー、セレクター、CI 設定だけを検索し、実装に必要な少数の特定のソースファイルを開くことができます。

たとえば、エージェントを記録済みの Now in Android revision に接続して、次のように質問します。

あなた： このプロジェクトでインストルメンテーション UI テストを追加して実行するには、どうすればよいですか？

エージェント： テストは既存のアプリテストと並べて、 app/src/androidTest の下に配置します。Hilt と Compose の設定に従い、まず @HiltAndroidTest と HiltAndroidRule を使用し、その後で createAndroidComposeRule<MainActivity>() を使います。アプリでは NiaTestRunner が選択されており、これによって HiltTestApplication が起動します。共通のフェイクは @TestInstallIn を通じて本番用のバインディングを置き換えます。CI では、確認できたタスク ./gradlew connectedDemoDebugAndroidTest が実行されます。このタスクはソースに基づく参照情報であり、Gradle タスクの完全な一覧ではありません。

回答は簡潔ですが、各主張は、エージェントや開発者が確認できる証拠に結び付いています。

ローカルで検証可能

デフォルトでは、Coador はローカルで動作します。標準の分析に次のものは必要ありません。

• LLM。
• 埋め込みモデル。
• ベクターデータベース。
• 外部 API。
• Docker。
• リポジトリのソースコードを外部サービスにアップロードすること。

生成されるプロジェクトプロファイルは決定的です。同じリポジトリの状態とスキャン設定であれば、同じ構造化結果が生成されることが想定されています。そのため、このナレッジベースはプロジェクトと一緒に保持し、コードベースに合わせて更新し、他の生成済みプロジェクト成果物と同様に変更をレビューするのに適しています。

profile.json が機械可読な信頼できる唯一の情報源です。Markdown レイヤーは、そのプロファイルを人が参照するためのものです。正確なソース証拠には、リポジトリ相対パス、1 始まりの範囲、スナップショットダイジェストが含まれます。ファイルレベルおよび Gradle モデルの検出結果には、架空の行番号を付与せず、それぞれ固有の来歴形式を使用します。

ソースから導出された生成フィールドには、一般的なシークレットに対する共通のサニタイズが適用されます。ただし、サニタイズによって非公開の出力を安全に公開できると保証されるわけではありません。生成されたナレッジベースは、共有する前に確認してください。信頼境界の全容は SECURITY.md に記載されています。

Coador はスキャンしたプロジェクトからテレメトリーを収集しません。デフォルトのスキャンではネットワークにアクセスしません。パッケージのインストールと、明示的に要求された Gradle パスには、それぞれ独自のネットワークおよび信頼境界があります。

ソースコードの代替ではありません

Coador は、AI エージェントによるソースコードの確認をなくそうとするものではありません。目的は、リポジトリ全体を何度も広範囲に調べる作業をなくすことです。

エージェントが特定の機能を変更する必要がある場合は、引き続き該当する本番コードとテストのファイルを開きます。不要になるのは、全体的なアーキテクチャ、テストインフラ、Gradle の設定、CI ワークフローを毎回ゼロから再構築することです。

Coador は、プロジェクトの事前構築済みのマップとして機能します。コンパクトで、構造化され、ローカルにあり、ソースの証拠に裏付けられています。

このマップには明確な制限があります。

• デフォルトのパスでは、コンパイルではなくパターンマッチングを実行します。ヒューリスティックによる証拠が見つからなくても、その機能が存在しない証明にはなりません。
• 規約プラグイン、生成されたビルドロジック、動的に作成されるバリアントには、オプションの Gradle パスが必要になる場合があります。
• coador scan --gradle は対象ビルドの設定を実行するため、信頼できるプロジェクトでのみ使用してください。
• インベントリの完全性が適用されるのは、検出器に文書化されたソース範囲であり、実行時に存在し得るすべての値ではありません。
• メタデータの鮮度を確認する高速パスでは、パス、サイズ、変更時刻を意図的に保持したまま行われたコンテンツの変更は検出できません。その場合は --force を使用してください。
• Coador は、シンボルナビゲーション、セマンティック検索、ビルドツール、デバイス自動化を補完します。これらに取って代わるものではありません。

インストール

Coador には Python 3.11 以降が必要です。永続的にインストールせずにバージョン 0.1.0 を実行するには、uvx を使用します。

uvx --from coador==0.1.0 coador --version

現在のチェックアウトを使用するには、次のようにします。

git clone https://github.com/automaticqa/coador.git
cd coador
uv sync --all-extras
uv run coador --version

編集可能な pip インストールにも対応しています。

python -m pip install -e '.[dev]'

CLI

CLI では 6 つのコマンドを使用できます。

コマンド	目的
scan	ナレッジベースを構築または更新します
status	保存されたナレッジが最新かどうかを報告します
layers	9 つのナレッジレイヤーを一覧表示します
overview	1 画面に収まるプロジェクトマップを表示します
search	識別子を考慮した語彙ランキングでセクションを検索します
show	証拠とともに 1 つのレイヤーまたはセクションを読み取ります

Android リポジトリから基本的なワークフローを実行します。

coador scan
coador overview
coador search "where do the base URLs come from"
coador show 03_architecture di_framework

すべてのコマンドで --json を使用できます。--kb-dir を使用すると、生成された出力を Android のチェックアウトの外に保存できます。ソースメタデータを信頼できない場合は、coador scan --force を使用してください。JDK と Gradle ラッパーがある信頼できるプロジェクトでは、coador scan --gradle によって設定済みの Gradle モデルが追加されます。

デフォルトでは、生成されたナレッジは次の場所に保存されます。

.coador/
  .refresh.lock
  manifest.json
  profile.json
  layers/

スキャナーは Android のソースとビルド設定を読み取りますが、変更はしません。選択されたナレッジベースディレクトリにのみ書き込みを行い、対象リポジトリの .gitignore を編集することはありません。選択された保存先は、スキャンと鮮度フィンガープリントから除外されます。

チームがプロジェクトマップをレビュー可能にし、ローカルで再スキャンせずに利用できるようにしたい場合は、.coador/ ディレクトリをコミットできます。各レイヤーの `` マーカーより上にある手書きの Markdown は、更新後も保持されます。

MCP

coador mcp（coador-mcp としても利用可能）は、6 つの kb_* ツールと対応する kb:// リソースを使って、1 つのリポジトリを MCP stdio 経由で提供します。サーバーが無関係な作業ディレクトリを誤って参照しないよう、Android リポジトリを明示的に登録します。

codex mcp add coador -- uvx --from coador==0.1.0 coador mcp \
  --repo "/absolute/path/to/your/android/project"
codex mcp list

Android プロジェクトで Codex を開き、/mcp を使ってサーバーを確認してから、プロジェクトについて質問します。最初のプロンプトには次のようなものが役立ちます。

このプロジェクトにインストルメンテーションテストを追加するには、どのようにすればよいですか？ランナー、アプリケーション、確認済みのテストタスク、依存関係のオーバーライド、拡張するヘルパーまたはロボット、便利なセレクターを特定してください。各回答について、リポジトリ内の根拠を引用してください。

設定には COADOR_REPO と COADOR_KB_DIR も使用できます。信頼できるプロジェクト単位の設定、スペースを含むパス、複数のリポジトリ、Claude Code およびその他の MCP クライアントについては、docs/mcp.md を参照してください。

例

ネットワークや Android ツールチェーンを使わずに現在のプロファイルスキーマを確認するには、ローカルの合成例から始めてください。固定された Now in Android のウォークスルーでは、ダウンロードしたチェックアウトの外部で現在の CLI ビューを生成します。

git clone https://github.com/android/nowinandroid.git
git -C nowinandroid checkout 12f80da6518e161ed16a06a68e71fb8a873576d6
uvx --from coador==0.1.0 coador scan nowinandroid --kb-dir ../nowinandroid-coador
uvx --from coador==0.1.0 coador show 07_testing instrumentation_runner \
  nowinandroid --kb-dir ../nowinandroid-coador
uvx --from coador==0.1.0 coador show 07_testing test_tasks \
  nowinandroid --kb-dir ../nowinandroid-coador

関連する出力では、エビデンスと制限事項が区別されています。

$ coador show 07_testing instrumentation_runner nowinandroid --kb-dir ../nowinandroid-coador
Instrumentation Runner (instrumentation_runner)
Detected: Observed: runner: androidx.test.runner.AndroidJUnitRunner, com.google.samples.apps.nowinandroid.core.testing.NiaTestRunner
source: heuristic

  app/build.gradle.kts:38  testInstrumentationRunner = "com.google.samples.apps.nowinandroid.core.testing.NiaTestRunner"

  limitation: Static scanning cannot resolve runner configuration supplied only by convention plugins or generated build logic

エビデンスを重視したオンボーディングレシピでは、固定された3つの公開リポジトリを対象に、CI のインストルメンテーション、起動ターゲットとセレクター、Android Test Orchestrator による分離のウォークスルーを追加しています。

プロジェクトの状況

Coador 0.1.0 は初の一般公開リリースです（2026-09-17）。パッケージには、9つのレイヤーにわたる84個の検出器、ローカル CLI、MCP stdio サーバー、任意の Gradle プロービング、決定論的な JSON／Markdown 出力、エビデンスの来歴、インベントリのページネーション、鮮度チェック、破損した生成出力からの復旧機能が含まれています。

設定済みの CI マトリックスでは、Linux は Python 3.11～3.13、Windows／macOS は Python 3.12 を対象としています。ネットワークと実プロジェクトでの Gradle チェックは、引き続きオプトイン方式です。

開発を始めるには、次のコマンドを実行してください。

uv sync --all-extras
uv run pytest
uv run ruff check src tests
uv run ruff format --check src tests
uv run mypy
uv run python -m coador.registry --check
uv build

COADOR_INTEGRATION=1 uv run pytest -m slow を実行すると、固定された公開 Android リポジトリもクローンされます。Gradle のケースには、適切な Android／JDK ツールチェーンが必要です。コントリビューターは、コントリビューションのスタータータスクから始められます。任意の公開利用フィードバックは、docs/adoption.mdに記載されたプライバシーの境界に従います。

ライセンス

MIT。LICENSEを参照してください。