mcpField
D
DevTime

DevTime

ローカル
github.com開発ツール115 週間前に更新

DevTime について

DevTimeはソフトウェアリポジトリ向けのローカル優先の分析ツールです。コード、テスト、設定、記録された決定を根拠に主張を検証し、不確実性も示すため、開発者やレビュー担当者に適しています。コードを実行せず、AIも不要で、読み取り専用のMCPサーバーからコーディングエージェントに根拠付きの情報を渡せます。

主な機能

  1. 01コード、テスト、設定、文書のスキャン
  2. 02根拠と矛盾を示す主張の検証
  3. 03根拠の変更による主張の陳腐化を追跡
  4. 04ローカルの根拠に基づく差分リスク確認
  5. 05不確実性を減らすローカルな決定記録

活用シーン

  1. 01不慣れなリポジトリの機能実装を把握
  2. 02変更が既存の主張に与える影響を確認
  3. 03プロジェクトの挙動に関する決定を振り返る
  4. 04コーディングエージェントにリポジトリの文脈を提供

MCP 対応

DevTimeはstdio経由のローカルな読み取り専用MCPサーバーを提供し、概念の一覧、概念の説明、管理されたコンテキストパックの取得、主張の検証という4つのツールを公開します。返すのは根拠となるファイルパスのみで、書き込みツールはなく、ネットワークリスナーも起動しません。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"devtime": {
"command": "uvx",
"args": [
"devtime-ei"
]
}
}
}
起動コマンドuvx devtime-ei

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
pypidevtime-ei0.7.0

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

DevTime

DevTime は、リポジトリが実際に証明できることを検証します。

stripe/webhook.ts という名前のファイルは、リポジトリが Stripe の Webhook を処理している証拠のように見えます。しかし、実際には 404 を返すだけの ハンドラーかもしれません。DevTime は、リポジトリに関する記述を実装、テスト、 設定、記録された決定と照合し、何が裏付けられているか、何が矛盾しているか、 何が不足しているか、何が古くなっているかを報告します。

クラウド不要。テレメトリーなし。コード実行なし。AI 不要。

DevTime の検証デモ - 主張が SUPPORTED から CONTRADICTED、さらに STALE に変わる

動画をご覧になりたいですか?2 分間のデモを見る:DevTime が リポジトリをローカルでスキャンし、証拠に基づいて概念を説明し、不確実性を示し、リスクのある 差分を検出する様子と、裏付けのある決定によって理解が深まる様子をご覧いただけます。


DevTime を 60 秒で試す

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc verify

デモ用リポジトリでは、請求 Webhook の署名検証が SUPPORTED、JWT 認証が SUPPORTED、 ルートとテストの関連付けが WEAK と判定されます。テストがインポートしていない ルートが名前で示されます。自分のリポジトリを指定すると、結果が変わります:

cd your-repo
dtc init && dtc scan && dtc verify

PyPI の配布名は devtime-ei です。Python パッケージ名は引き続き devtime、 CLI コマンド名は引き続き dtc です。dtc demo init は小規模な静的サンプルリポジトリを ./devtime-demo-saas にコピーするため、このリポジトリをクローンせずに DevTime を試せます。

ソースから実行する
git clone https://github.com/Shakargy/devtime.git
cd devtime
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cd examples/demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

Windows PowerShell の場合:

git clone https://github.com/Shakargy/devtime.git
cd devtime
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e ".[dev]"
cd examples/demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

証拠に基づいて説明された「Billing Webhooks」が表示されます。裏付けのある主張、 ファイル参照、不確実性、Understanding Score、Understanding Debt が含まれます。

リスクレビューを試すには、まずローカルで変更を加えてから、次を実行します:

dtc risk --diff

リスク差分と裏付けのある決定の手順を含む、コピーしてすぐに実行できる完全な手順は DEMO_SCRIPT.md にあります。

主張を検証する(実験的)

主張とは、リポジトリに関する記述です。検証では、証拠で裏付けられない確信を示すことなく、 ステータスと根拠を提示して回答します。

Status: CONTRADICTED

Contradictions:
  - The billing webhook endpoint cannot verify signatures
    because it is a disabled stub.
      claimed:  pages/api/stripe/webhook.ts is named and routed
                as a billing webhook endpoint.
      observed: The handler's only behavior is a 404/501 response.
  • SUPPORTED - 必要な動作の証拠が現在のスキャンに存在します
  • WEAK - 対象となる箇所は存在しますが、証明に必要な証拠がありません
  • CONTRADICTED - 信頼できる証拠が主張と矛盾しており、両方が示されます
  • UNKNOWN - 対象となる箇所は存在しますが、責任を持って判定できるだけのカバレッジがありません
  • NOT_APPLICABLE - リポジトリに、この主張が対象とする箇所がありません

組み込みの主張は 4 種類です:ルートとテストの関連付け、管理者認可、請求 Webhook の署名、 JWT 認証です。dtc verify は、リポジトリで実際に検証できる内容を優先して示します。 該当するものがない場合は行き詰まらせるのではなく、主張を検証可能にするために何が必要かを 説明します。

正しさと鮮度は別々に扱います。検証済みの主張を支えるファイルが変更されると、主張は STALE になり、変更されたファイルが示されます。

変更をレビューするには、2 つのコミット間で主張を比較します:

dtc review --base origin/main

両コミットの分離されたスナップショットを使い、作業ツリーに触れることなく、変更によって 各主張に何が起きたか(回帰、新たに該当するようになった主張、成立していた主張に関する 証拠の変化)を報告します。GitHub Actions では、参考情報としてジョブのサマリーを出力します。

モデルの全容と制限については、VERIFICATION.md をご覧ください。

なぜこれが必要なのか

Git は何が変更されたかを記録しますが、その変更の背後にある理由は残しません。リポジトリに 戻ったとき、あるいは自分が書いていないリポジトリをレビューするとき、なぜその動作が存在するのか、 どの証拠がそれを裏付けているのか、何がまだ不確かなのかを再構築しなければならないことがよくあります。

DevTime は、証拠に基づくリポジトリの記憶を構築します。コードベースがコード、テスト、設定、 ルート、記録された決定から自らを説明するのを支援するローカルな層です。リポジトリが証拠をもって 裏付けられることと、同じくらい重要なこととして、まだ裏付けられないことを示します。

対象ユーザー

DevTime は、記憶ではなく証拠に基づいてリポジトリを理解する必要がある人向けです。

特に、次のような方に役立ちます。

  • なじみのないコードベースへの参加時に、機能がどのように実装されているかを理解する必要がある方。
  • プルリクエストをレビューするときに、ある動作を裏付ける証拠を確認したい方。
  • 数週間から数か月ぶりにプロジェクトに戻り、あるものが存在する理由を思い出せない方。
  • 設計上の決定が失われやすい、長期にわたって維持されているプロジェクトを保守している方。
  • 生成された要約ではなく、コードと記録された決定によってリポジトリの理解を裏付けたい方。

DevTime は、次のような疑問への回答に役立ちます。

  • このリポジトリは、ファイル名が示唆する内容を実際に証明できますか?
  • 認証は実際にはどこに実装されていますか?
  • Billing Webhooks の存在を証明するファイルはどれですか?
  • まだ不確かな点は何ですか?
  • この差分はリスクの高い概念に影響しましたか?
  • この動作を説明する決定は記録されていますか?

DevTime の機能

  • リポジトリに関する主張を検証し、ステータス、証拠、矛盾がある場合はその両側を報告します。
  • 情報の鮮度を追跡し、検証済みの主張も、その根拠となる証拠が変化すると古くなったことを示します。
  • ルート、テスト、設定、依存関係、ドキュメントから概念を検出します。
  • 主張をファイルやシグナルに結び付け、証拠に基づいて説明します。
  • 証拠が不足している、または弱い場合は、不確実性を明らかにします。
  • Understanding Score と Understanding Debt ラベルで理解度を評価します。
  • リスクの高い箇所に絞って差分をレビューし、助言となる指摘を提示します。これには、差分によって不安定になる検証済みの主張も含まれます。
  • 決定をローカルに記録し、コードによる裏付けがある場合は、決定の根拠によって不確実性を減らせるようにします。

対応する概念

検証の基盤には、ローカルに保存される証拠に裏付けられたメモリーを構築するスキャナーがあります。

DevTime のターミナルデモ - インストール、スキャンし、証拠に基づいてリポジトリを説明

DevTime は、対応する6つの概念ファミリーを検出します。任意のドメイン概念を検出する機能には、まだ対応していません。

  • 認証
  • Billing Webhooks
  • バックグラウンドジョブ
  • データエクスポート
  • 管理者権限
  • ファイルアップロード

現時点では、この6つ以外は対象範囲外です。LIMITATIONS.md を参照してください。

DevTime が行わないこと

  • コードを実行しません。
  • コードやデータをネットワーク経由で送信しません。
  • AI モデルを必要とせず、呼び出すこともありません。
  • 正確性や安全な変更を保証しません。
  • コードレビューやアーキテクチャ上の決定に代わるものではありません。
  • ドキュメント生成ツール、静的解析ツール、オブザーバビリティツール、生産性トラッカー、AI コーディングエージェントではありません。

信頼モデル

  • DevTime は、ローカルリポジトリのメモリーを .devtime/(ローカルの SQLite データベース)に保存します。
  • スキャン中にネットワークアクセスはありません。
  • スキャン中にコードを実行しません。
  • 無視対象のディレクトリはスキャン前に除外されます。無視対象のファイルやシークレットが証拠や主張になることはありません。
  • すべての主張を証拠に結び付ける必要があります。証拠のない主張はありません。
  • 証拠が弱い場合は、確信ではなく不確実性を示します。
  • 使用は決定を意味しません。依存関係が使われているからといって、誰かがその理由を決定したとは限りません。
  • リスクレビューはデフォルトで助言のみです。プルリクエストをブロックしません。

コマンド

コマンド目的
dtc initローカルの .devtime メモリを作成します。
dtc scan現在のリポジトリをスキャンし、証拠に裏付けられたシグナルを抽出します。
dtc concepts検出されたコンセプトを、信頼度と理解負債とともに一覧表示します。
dtc explain <concept>コンセプトについて、主張、証拠、信頼度、不確実性、理解負債を説明します。
dtc context <concept>エージェントまたは人間向けに、ガバナンスされたコンテキストパックを作成します。
dtc risk --diffローカルの証拠を使って、リスクのある変更がないか git diff を確認します(参考情報)。
dtc decision add不確実性を軽減できるローカルの決定記録を追加します。
dtc verify [claim]リポジトリに関する主張を、ステータス、矛盾、新しさの観点から証拠と照合します(実験的機能)。
dtc review --base <ref>2 つのコミット間の主張を比較し、変更による影響を報告します(参考情報)。

(次のコマンドも利用できます:dtc evidence、dtc debt、dtc status、dtc doctor --privacy、 dtc export、dtc reset、dtc mcp start。)

Python >= 3.11 と git が必要です。初回実行の手順とトラブルシューティングについては、 QUICKSTART.md をご覧ください。

コーディングエージェントでの使用(MCP)

コーディングエージェントは、リポジトリの記憶がない状態で毎回セッションを開始し、 自信満々に推測します。DevTime は、信頼できるメモリを提供します。リポジトリが証明できる 主張だけを返し、証明できない内容については不確実性を明示する、ローカルの読み取り専用 MCP サーバーです。

MCP サポート付きでインストールし、リポジトリをスキャンします。

pipx install "devtime-ei[mcp]"
cd your-repo
dtc init
dtc scan

Claude Code に DevTime を追加します。

claude mcp add devtime -- dtc mcp start

または、.mcp.json を読み込む任意の MCP クライアントで使用できます。

{
  "mcpServers": {
    "devtime": {
      "command": "dtc",
      "args": ["mcp", "start"]
    }
  }
}

エージェントは、4 つの読み取り専用ツールを利用できます:list_concepts、explain_concept、 get_context_pack(レビューなしで変更してはならないパス、実行するテスト、エージェント向けの ガイダンスを含む、ガバナンスされたコンテキスト)、および verify_claim(主張のステータス、 矛盾、証拠の不足をその都度計算し、保存しません)。ローカルの stdio のみで動作し、 ネットワークリスナーも書き込みツールもありません。ソースコードは返さず、証拠ファイルのパスのみを返します。

DevTime は、公式 MCP レジストリに io.github.Shakargy/devtime として登録されています。

インストール

推奨: pipx を使って PyPI からインストールすると、分離された環境で dtc コマンドを PATH から利用できます。

pipx install devtime-ei

または pip を使います。

pip install devtime-ei

PyPI のディストリビューション名は devtime-ei です。Python パッケージ名は引き続き devtime、 CLI コマンド名は引き続き dtc です。インストール後、dtc demo init を実行すると、 試用できるローカルのサンプルリポジトリが作成されます。

ソースから
git clone https://github.com/Shakargy/devtime.git
cd devtime
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

Windows PowerShell:

git clone https://github.com/Shakargy/devtime.git
cd devtime
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e ".[dev]"

出力例

$ dtc explain "Billing Webhooks"
Concept: Billing Webhooks

Supported claims:
  - Billing Webhooks is present and supported by behavior evidence.
    type: concept  confidence: 0.86  evidence: src/billing/stripe-webhook.ts, tests/stripe-signature.test.ts
  - Billing Webhooks has active route handling.
    type: behavior  confidence: 0.82  evidence: src/billing/stripe-webhook.ts
  - Billing Webhooks verifies webhook signatures.
    type: behavior  confidence: 0.85  evidence: src/billing/stripe-webhook.ts

Uncertainty:
  - No decision was found explaining key choices for Billing Webhooks.

Understanding Score: 58 / 100
Understanding Debt: medium
causes:
  - missing or uncorroborated decision evidence
  - no confirmed owner

Understanding Score は高いほど理解度が高く、Understanding Debt はラベル(低/中/高)であり、 同じ数値を表すものではありません。

実証

DevTime は examples/demo-saas と実際のリポジトリで動作します。Reality Validation 中に、実際の問題を検出し、そこから学習しました(Next.js App Router の見落とし、 汎用的な webhook システムに対する Billing Webhooks の誤検出、DB マイグレーションを Background Jobs の証拠として誤カウントしたことなど)。各問題をフィクスチャに追加したため、 ひそかに再発することはありません。

  • 実際の問題をフィクスチャに追加するにつれて、テスト数は 13 件から 88 件に増加しました。
  • 実際の 355 ファイルのリポジトリで、無視対象ディレクトリの刈り込み後、スキャン時間は約 27.3 秒から約 0.48 秒に短縮しました。

証拠の全容、変更前後の例、検証レポートは PROOF.md と reports/reality-validation/ にあります。

プライバシーと安全性

  • すべてローカルで実行され、スキャン中にマシンの外へデータが送信されることはありません。
  • スキャン中にコードを実行したり、ネットワークに接続したりすることはありません。
  • 設計上、シークレットと無視対象ファイルは証拠から除外されます(境界については dtc doctor --privacy で確認できます)。
  • dtc reset はローカルメモリを削除します。ソースコードが変更されることはありません。

既知の制限事項

DevTime はヒューリスティックなスキャナーであり、完全なコンパイラーやセマンティックアナライザーではありません。現在は、フィクスチャに似た TypeScript / Next.js / Express / FastAPI 形式のリポジトリで特に高い性能を発揮します。偽陽性や偽陰性が発生する可能性があります。Understanding Debt はプロダクトの指標であり、普遍的な客観的事実ではありません。

フレームワークの対応範囲、リスクレビューの対象範囲、意図的にまだ実装していない内容を含む全一覧は、LIMITATIONS.md をご覧ください。

ロードマップ

これは、大規模化よりも信頼性を重視する、初期段階のローカルファーストな V0 です。意図的にまだ実装していないものは、Git 履歴のシグナル、書き込み可能な MCP ツール、AI プロバイダー、UI、クラウド/チーム/エンタープライズ向け機能です。ROADMAP.md をご覧ください。

コントリビュート

最も価値のある貢献はフィクスチャです。これは、小規模なリポジトリのパターンに加え、期待される概念、許容される主張、禁止される主張、必要な不確実性をまとめたものです。DevTime がコードに対して誤った結果を出した場合、その誤った出力をフィクスチャに追加することで、同じ問題が再発しないようにできます。詳しくは CONTRIBUTING.md をご覧ください。

ライセンス

Apache License 2.0 の下でライセンスされています。LICENSE をご覧ください。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。