Agentic SDLC MCP

agentic-sdlc-mcp

実際の GitHub リポジトリで作業する AI コーディングエージェントのための、ガバナンスとエビデンス管理機能。

Claude Code、Cursor、その他の Model Context Protocol（MCP）クライアントが、リポジトリのコンテキスト、レビューゲート、セキュリティエビデンス、人間による承認ポイントを利用できるようにします。

中国語 · npm · MCP レジストリ · ロードマップ

agentic-sdlc-mcp は、AI コーディングエージェントに本番リポジトリの変更をすでに許可しているチーム向けの、ソフトウェア開発ライフサイクル（SDLC）ガバナンスレイヤーです。GitHub のコンテキスト、ポリシー、チェック、レビュー、セキュリティアラート、リリースのシグナルを、ワークフローレベルの 13 個の MCP ツールに変換します。12 個のツールは読み取り専用です。唯一の GitHub 書き込みツールは、デフォルトで変更内容をプレビューします。

バージョン 1.11.0 では、PR 評価、ポータブルなエビデンス、スナップショット比較、受け入れのトレーサビリティに対応した読み取り専用 CLI agentic-sdlc も提供します。agentic-sdlc-mcp は引き続き MCP サーバーのエントリーポイントです。このバージョンをインストールする際は、正確なパッケージとリリースメタデータを確認してください。

この MCP で何が変わるのか

AI コーディングエージェントは、すべてのリポジトリルールを把握していなくても、コードやプルリクエストを作成できます。このサーバーは、エージェントに範囲を限定したコンテキストを提供し、レビュー担当者には自由形式の要約ではなく、明示的なエビデンスの不足箇所を提示します。

このサーバーは、コードの書き込み、プルリクエストのマージ、強制プッシュ、リリースの作成、ソフトウェアのデプロイを行わず、人間によるセキュリティレビューに取って代わるものでもありません。

本番環境のエージェントワークフローにおける位置づけ

MCP は、AI コーディングエージェントと GitHub のエビデンスの間に位置します。リポジトリの変更は引き続きエージェントの通常の開発環境を通じて行われ、影響の大きい判断はチームが担います。

flowchart LR
    Policy["Engineering policy<br>and repository rules"] --> MCP["agentic-sdlc-mcp"]
    Agent["AI coding agent<br>Claude Code · Cursor · MCP client"] --> MCP
    MCP --> GitHub["GitHub API evidence"]
    GitHub --> MCP
    MCP --> Reports["Briefs · plans · gates<br>reviews · release reports"]
    Reports --> Agent
    Reports --> Human["Human review and approval"]
    Agent -. "Code · commits · pull requests" .-> GitHub
    Human -. "Merge · release · deploy" .-> GitHub

役立つ場面

自律型エージェントが推測したり、古くなった説明文に頼ったりしがちな場面で、意思決定を支援するためにツールを使用します。

エージェントを使わずに PR をレビューする

1 つのコマンドで、人が読める判定と JSON スナップショットを収集します。評価では、既存のゲートとルールベースのレビュー証跡を組み合わせ、PR の head/base とポリシーダイジェストに紐付けたうえで、ブロッカー、不足している証跡、リクエスト数、収集時間を保持します。

レビュー済みのチェックアウトから、Node.js 22 以降を使ってビルドします。

npm ci
npm run build
node dist/cli.js doctor --repo acme/widget
node dist/cli.js assess-pr --repo acme/widget --pr 42 --output artifacts/pr-42-first.json --summary artifacts/pr-42-first.md

オンライン収集の前に、プロセスまたはシークレットマネージャーを通じて GITHUB_TOKEN を設定してください。CLI は環境変数のみを読み取り、ホームディレクトリの設定ファイルや .env は読み込みません。doctor は --online を指定しない限りオフラインで動作し、設定が不足している場合は終了コード 2 を返します。パッケージのインストール後は、agentic-sdlc で node dist/cli.js と同じ CLI を実行できます。

assess-pr と evidence では、1 回の収集とローカル分析に --previous、--acceptance、任意の --mappings も指定できます。マッピングファイルには、証跡の継続性で説明されている厳密な配列スキーマを使用します。--json は標準出力の形式を変更し、--output は常に JSON ファイルを作成します。既存のファイルは上書きされません。--summary は新しい Markdown ファイルを作成します。また、GitHub Actions の正確な GITHUB_STEP_SUMMARY パスが指定された場合は、そのファイルに追記します。

評価はデフォルトで助言的です。判定が blocked または needs evidence でも、レポートが完成すれば 0 を返します。assess-pr --enforce は、blocked の場合は 1、needs_evidence の場合は 2、ready_for_review の場合は 0 を返します。設定、入力、またはソースの利用不可に関するエラーは 2、キャンセルは 130 を返します。diff または trace コマンドの成功は、分析が完了したことを意味するもので、証跡や受け入れ条件に合格したことを意味するものではありません。

オンライン収集のデフォルトはタイムアウト 30 秒、リクエスト上限 120 件です。上書きする場合は、--timeout-ms に 1～120000、--max-requests に 2～500 を指定できます。doctor には独自の上限付きプローブがあり、タイムアウトオプションも使用できます。入力ファイルとシリアライズされた出力のサイズ上限は 1 MiB です。

スナップショットが変更されていなくても、以前の検証結果は引き継がれません。head/base、ポリシー、生成元のバージョン、鮮度、完全性が変わると、再収集が必要になることがあります。チェック済みのボックス、エージェントの主張、通常の CI の成功だけでは、ビジネス上の受け入れを証明できません。CLI には、デフォルトでは信頼できる受け入れ結果の生成元が設定されていません。ready レポートも --enforce も、PR の承認、マージ、デプロイを行うものではありません。

MCP のレビューセッションでは、ホームディレクトリや .env の設定を避けるために SDLC_CONFIG_MODE=envonly を設定し、プレビューは維持したまま実際の Issue 作成を拒否するには SDLC_READ_ONLY=true を設定してください。対象リポジトリに限定し、読み取り権限のみを付与したトークンを使用してください。クライアント設定とポータブルなレビュースキルについては、クライアントの設定例を参照してください。未実施の小規模サンプル検証計画については、ユーザーパイロットを参照してください。

npm からインストールする

Node.js 22 以降が必要です。GitHub Actions では Node 22 と 24 でテストされています。公開済みパッケージを npm から直接実行します。

npx -y agentic-sdlc-mcp

グローバル CLI としてインストールする場合：

npm install -g agentic-sdlc-mcp
agentic-sdlc-mcp

デフォルトのトランスポートは stdio です。ほとんどの MCP クライアントは、別のターミナルで実行するのではなく、パッケージを起動します。

これらの npm コマンドは公開済みリリースを解決します。このバージョンを再現するには [email protected] を固定し、リリース／パッケージのメタデータを確認して、アップグレード後に既存の MCP 接続を再起動してください。

コーディングエージェントにセットアップを任せる

このプロンプトを Codex、Claude Code、または別のコーディングエージェントに貼り付けてください。

Use npm install -g agentic-sdlc-mcp to install and configure this MCP globally. Repository: https://github.com/SakuraCianna/agentic-sdlc-mcp
Configure GITHUB_TOKEN and optional repository defaults through the MCP client's secret or environment configuration. On a trusted single-user machine, you may instead run agentic-sdlc-mcp configure or write them to ~/.agentic-sdlc-mcp.json. Never expose the token in chat, logs, or repository files; ask me for missing non-secret details.
Then verify the connection with the read-only repo_context tool and summarize its capabilities, required GitHub permissions, and safety boundaries.

承認する前に、すべてのコマンドと設定変更を確認してください。Node.js 22 以降が必要です。

MCP クライアントを接続する

Claude Desktop、Cursor、Windsurf、または別の MCP クライアントにサーバーを追加します。GitHub トークンは、クライアントのシークレットまたは環境設定を通じて注入してください。

{
  "mcpServers": {
    "agentic-sdlc": {
      "command": "npx",
      "args": ["-y", "agentic-sdlc-mcp"],
      "env": {
        "GITHUB_TOKEN": "your_github_token_here",
        "GITHUB_OWNER": "your_organization",
        "GITHUB_REPO": "your_repository"
      }
    }
  }
}

Windows の一部の MCP クライアントでは、cmd を介して npx を実行する必要があります。

{
  "command": "cmd",
  "args": ["/c", "npx", "-y", "agentic-sdlc-mcp"]
}

GITHUB_OWNER と GITHUB_REPO は任意のデフォルト値です。ツール呼び出しでリポジトリの座標を明示的に指定することもできます。有効にする機能だけに権限を付与するには、GitHub 権限マトリックスを参照してください。

npx -y agentic-sdlc-mcp configure

接続を確認する

書き込みアクセスを許可する前に、リポジトリの境界を確認できるよう、まず読み取り専用の呼び出しから始めてください。

Use agentic-sdlc-mcp to run repo_context for the configured repository. Include package scripts, workflows, governance, and repository policy. Do not create issues or modify GitHub.

次に、何も作成せずに書き込み境界を検証してください。

Generate a feature plan and pass its issue drafts to create_issue_set with dryRun: true. Show the target repository, titles, labels, body summaries, and warnings. Do not write to GitHub.

5 分で確認できる手順については、クライアントに依存しないスモークテストを参照してください。

ツール

サーバーはワークフローレベルのツールを 13 個登録します。MCP クライアントは実行時に入力と出力の完全なスキーマを受け取ります。この一覧では、それぞれのツールを使う場面と結果の解釈方法を説明します。

このサーバーは、SDLC 標準と、Issue、PR の概要、リリース準備状況、引き継ぎの各テンプレートに対応する、読み取り専用の sdlc:// リソースも5つ公開します。

一般的なワークフロー

これらの手順により、ツール選択の曖昧さを減らせます。各手順の最後には人間による判断を行います。

Start work
repo_context → plan_from_context → create_issue_set (dryRun: true)
→ human confirms the work items → create_issue_set (dryRun: false)
→ prepare_work_item

Review a pull request
create_pr_summary → quality_gate_status → review_pr_against_standard
→ human reviews findings and decides whether to merge

Review governance
branch_protection_status → workflow_permissions_audit → security_triage
→ repository owners decide which settings or workflows to change

Prepare a release
security_triage → release_readiness_check → sdlc_evidence_packet
→ human approves the tag, release, and deployment

Transfer work
relevant evidence tools → sdlc_evidence_packet → agent_handoff_packet
→ the next agent validates stale or caller-asserted state before continuing

GitHub の権限

すべての権限をデフォルトで付与しないでください。チームが有効にするツールに必要な権限を選択し、まず本番環境以外のリポジトリでテストしてください。

GitHub の権限とエンドポイントの要件は変更される場合があります。失敗した場合は、GitHub REST API の権限に関するドキュメントで要件を確認してください。任意の権限がない場合、証拠の品質が低下したり、未検証になったりすることがありますが、それを理由に無関係なアクセス権限を付与してはいけません。

安全性と信頼境界

このサーバーは、自身のツールの動作を制限します。周囲の AI エージェントや MCP クライアントが利用できるすべての操作を制御することはできません。

• プレビュー優先の書き込みツールは 1 つのみ：create_issue_set は唯一の GitHub 書き込みツールであり、デフォルトでは dryRun: true です
• 特権を要するリポジトリ変更は不可：マージ、承認、強制プッシュ、ブランチ削除、ブランチルールの変更、リリース作成、デプロイのツールはありません
• 人間による承認ゲートは外部に維持：サーバーは CODEOWNERS、レビュー、ポリシー、CI、セキュリティ、リリースに関する証拠を報告します。最終判断は GitHub とチームが行います
• 証拠は条件付きのまま提示：ソースが欠落、古い、切り捨てられている、不正な形式である、または権限の制限を受けている場合、ギャップとして明示されます
• リポジトリポリシーはベースに紐づく：プルリクエストが自身のゲートをひそかに弱められないよう、可能な場合はベース SHA の PR ポリシーを読み取ります
• 外部テキストは信頼しない：リポジトリと呼び出し元のテキストには長さの上限を設け、エスケープ処理を行います。指示の上書き、シークレットやデータの持ち出し、エンコードされたコマンド、またはツールの強制実行を促すパターンが検出された場合、エージェント向けの Markdown から除外されます。ただし、生の構造化された証拠は引き続き検査できます
• シークレット検出には限界があります：信頼できるスキャナーの来歴とパッチのヒューリスティックによってリスクを軽減しますが、ファイル間または実行時のデータフローの検査には、CodeQL などの静的アプリケーションセキュリティテスト（SAST）、シークレットスキャナー、テスト、人によるレビューが引き続き必要です
• 認証情報の管理は利用者の責任です：クライアントによるシークレットの注入または環境変数の使用を推奨します。トークンをコミットしたり、Issue、PR、ログの内容に貼り付けたりしないでください
• ローカル専用のトランスポート境界：stdio とループバック HTTP は、信頼できるローカルのワークステーション向けです。リモート OAuth とマルチテナントのホスティングは、現行の製品ロードマップには含まれていません

.agentic-sdlc.yml のスキーマ、来歴、制限、ベース SHA に基づく自己変更の挙動については、リポジトリポリシーを参照してください。敵対的な入力を含むテストマトリクスとカバレッジのルールについては、テスト戦略を参照してください。

リポジトリポリシーとリソース

リポジトリ固有のチェックを計画、保護対象のパス、PR ゲート、レビュアー、ブロック用ラベル、変更履歴の要件、ロールバックの要件に反映する場合は、.agentic-sdlc.yml を追加します。ポリシーの出力には、ソースの ref、blob SHA、ダイジェスト、安定したルール ID、警告が含まれます。

静的リソースは sdlc:// スキームで利用できます。

ローカル HTTP プロファイル

Stdio がデフォルトかつ推奨されるローカルトランスポートです。どちらのローカルエントリーでも、公式 SDK v2 世代のルーターを使用します。2025 クライアントは引き続き initialize を通じて接続し、2026-07-28 を明示的にネゴシエートするクライアントは server/discover を使用します。どちらの世代も、同じ 13 個のツールと 5 個のリソースを公開します。

Streamable HTTP を必要とするローカルクライアントは、ソースからビルドした後にオプトインできます。

$env:TRANSPORT = "http"
$env:PORT = "3000"
node dist/index.js

エンドポイントは http://127.0.0.1:3000/mcp です。ループバックインターフェースにのみバインドし、サイズに上限を設けたリクエストボディーを解析する前に Host と指定された Origin を検証します。また、POST ごとに分離されたステートレスサーバーとトランスポートを作成し、サポート対象外の GET／DELETE セッション操作を拒否し、エラーの詳細情報に上限を設け、シャットダウン時には進行中の通信を中断します。

2025 ステートレス HTTP プロファイルには、別個の notifications/cancelled POST を以前のリクエストに関連付けるためのセッションもクライアント ID もありません。クライアント側では引き続きキャンセルが認識されますが、元のサーバー処理は自然に完了するまで実行される可能性があります。どちらの世代の stdio と 2026 HTTP も、キャンセルをサーバーリクエストに伝播します。レガシー呼び出しをサーバー側でキャンセルする必要がある場合は、stdio を優先してください。

このエンドポイントを別のマシンに公開したり、リバースプロキシ経由で転送したりしないでください。リモート OAuth とマルチテナントのホスティングは計画されていません。この範囲を再検討する場合は、まず個別のリモートデプロイ再検討基準を満たす必要があります。現在のローカルサーバーは、安全なリモートデプロイの基盤ではありません。

開発およびプロジェクトのリンク

コントリビュートまたは実装の確認を行う場合に限り、リポジトリをクローンしてください。

git clone https://github.com/SakuraCianna/agentic-sdlc-mcp.git
Set-Location agentic-sdlc-mcp
npm install
npm run build
npm run test

統合ゲートでは、両世代の実際の SDK Client.callTool を通じて、公開されている 13 個すべてのツールを呼び出します。レガシーではプロジェクトの stdio ラッパーを使用し、モダンでは 2026-07-28 に固定された本番用の direct-fetch HTTP ハンドラーを使用します。登録済みの出力スキーマ、主要な Markdown／構造化結果、信頼境界、エラー／縮退時のセマンティクス、モダンなワイヤーヘッダー、およびデフォルトの create_issue_set のドライラン動作を検証します。フィクスチャは、ライブでの issue 書き込みが少しでも発生すると直ちに失敗し、外部への fetch／ソケットアクセスをブロックします。 個別の Inspector stdio ゲートでは、Inspector 2.0.0 を専用のロックファイルで固定し、プロセスの外部から実際の dist/index.js を呼び出します。レガシー形式の initialize、13 個すべてのツール宣言、5 件すべてのリソース読み取り、書き込みが明示的にゼロである create_issue_set のプレビューを 1 件、無効な入力と不明なリソース URI に対する安定した JSON／終了コードの契約を検証します。すべての tools/call は dryRun:true を指定して create_issue_set を呼び出します。Inspector は公式の -e オプションを使用して、固定された環境変数の許可リストをターゲットに渡します。また、実際のサーバーが一時的なハーネス読み込み済みマーカーを書き込まない場合、実行は失敗します。ハーネスはユーザーの HOME の値を保持しながら、製品のグローバル設定ファイルの検索をブロックし、継承された GitHub 認証情報を秘密情報を含まないテスト用プレースホルダーに置き換え、Inspector のストレージ／OAuth 状態を分離し、この stdio 専用チェックではすべての fetch／TCP 接続を無効にします。これはブラックボックスの互換性を示す証拠であり、MCP 認定を示すものでも、最新の server/discover を裏付ける証拠でもありません。

HTTP ゲートは本番アダプターを 127.0.0.1:0 で起動し、Inspector の非対話型 --stored-auth-only モードを使って正式な /mcp URL に接続します。さらに、Inspector による独立した stdio 検出結果と完全なツール／リソース JSON を比較し、成功時も失敗時もすべての子プロセスを終了します。別の空ストアを使う 401 ループバック・フィクスチャでは、自動起動の条件を満たしつつ、即座に 3/auth_required が返されることを要求します。ブラウザー起動マーカーにより、対話型 OAuth が試みられるとゲートは失敗します。ハーネスで許可されるのは、IPv4 のループバックを指す正確な fetch／ソケットのターゲットだけです。DNS エイリアス、偽装ホスト名、外部ネットワークへのアクセス、継承された認証情報は引き続き使用できません。Windows では、Inspector 2.0.0 が正しい JSON エラーを出力した後、上流の libuv 終了アサーションに達することがあります。ランナーは、そのプラットフォームとステータス、および 2 行から成る正確なシグネチャの場合に限ってこれを許容し、生の終了分類を報告します。Linux での失敗や、それ以外のすべての失敗は引き続きフェイルクローズとなります。

Conformance パイロットでは、公式の 0.1.16 と、そのレガシーな 2025-11-25 アクティブスイートを固定しています。現在は 30 件のシナリオを記録しています。直接合格が 5 件、管理された想定内の失敗が 25 件です。主な理由は、上流の everything-server にあるプロンプト、フィクスチャ URI、フィクスチャツール、サブスクリプション、メディア／コールバック機能、状態を保持する SSE の前提が、この製品の公開契約に含まれないためです。想定内の失敗にはすべて、理由、担当者、削除条件が記載されています。新たな失敗や古くなった記録があると、実行は失敗します。アップロードされる checks.json には、生の応答の詳細や認証情報は含まれません。これはブロッキング要件ではない互換性パイロットであり、認定ではありません。また、テスト専用の本番機能を追加する理由にもなりません。

CI では、Node 22 と Node 24 で製品スイート全体と現行契約との比較を実行します。これとは別に、Node 24 のジョブで不変のベースラインを再実行し、必須の契約／評価ゲートを実行します。対象には Inspector stdio／HTTP、Conformance、12 件の固定シナリオ、13 件すべての応答予算、11 ケースの GitHub 障害マトリックスが含まれます。このゲートでは、シナリオ全体の正解率が 90% 以上であることと、安全性が重要な 6 件のシナリオが 100% であることを要求し、その後、上限を定めた 5 件の要約アーティファクトだけをアップロードします。Node 20 はサポート対象のランタイムではありません。サポート終了済みのためです。ローカルで作業する場合、コントリビューターに必要なのはサポート対象の Node バージョン 1 つだけです。互換性マトリックスは GitHub Actions で検証されます。

評価結果には、その出所が保持されます。scripted は決定論的なフィクスチャ、recorded-agent は固定入力に対して再実行されたサニタイズ済みの過去の実行、live-model は任意の現行モデル実行を意味します。必須 CI には scripted シナリオが 6 件、recorded-agent シナリオが 6 件含まれ、live-model の実行はありません。再実行に合格した場合に確認できるのは、チェックイン済みのワークフローが引き続き決定論的であることです。すべてのモデル、プロバイダー、将来のプロンプト、MCP 認定について主張するものではありません。評価ガイドを参照してください。 通常のテスト、contracts:check、contracts:verify-baseline がベースラインを書き換えることはありません。リプレイコマンドとメンテナー専用の contracts:generate コマンドは、固定されたタグ／コミットを検証し、ライフサイクルスクリプト、監査、funding 出力を無効にして過去のロックファイルをインストールし、システムの一時ディレクトリでビルドします。その後、チェックアウトの外部に作業ディレクトリを置いた、上限付きの子プロセスで実際の tools/list および resources/list 呼び出しを実行します。この子プロセスに渡されるのは、OS のパス、一時ディレクトリ、ロケール、動的ライブラリの環境変数の許可リストのみです。認証情報、業務設定、NODE_OPTIONS、ローカル状態のパスは引き継がれません。Windows でのクリーンアップでは、過去のハンドルが解放された後、回数を制限して再試行します。これらのコマンドには npm レジストリへのアクセスが必要ですが、GitHub API やモデルサービスは呼び出しません。追跡対象の JSON を書き込むのは contracts:generate のみであり、その差分はレビューできる状態で残ります。

Issue とプルリクエストで貢献する

Issue とプルリクエストを歓迎します。着手する前に、未解決の Issue とロードマップを確認してください。公開動作、セキュリティ境界、ツールスキーマ、アーキテクチャに影響する変更の場合は、まず Issue を作成してください。

1. リポジトリをフォークし、最新の main から変更内容を絞ったブランチを作成します。
2. npm ci を実行してから、貢献に必要な変更のみを加えます。
3. 動作を変更する場合は、テストとドキュメントを追加または更新します。
4. 変更に関連するチェックを実行します。Node 22／24 のマトリックスでは、npm run check:line-endings、npm run typecheck、npm run build、npm run contracts:check のビルド版、npm run test、npm run smoke、npm run test:coverage を実行します。別途、Node 24 のジョブで、不変ベースラインのリプレイと、固定された Inspector の stdio／HTTP および Conformance のコントラクトを実行します。
5. main に対するプルリクエストを作成します。問題、解決策、リスク、検証結果、および関連する Issue を記載してください。

トークン、認証情報、非公開リポジトリの内容、生成されたローカル設定は、コミット、Issue、プルリクエスト、ログに含めないでください。CI が成功してもレビューの参考になるにすぎず、メンテナーの承認に代わるものではありません。

• ロードマップ
• リポジトリポリシーガイド
• クライアントのレシピとポータブルなレビュー用スキル
• エビデンスの継続性と受け入れ基準のトレーサビリティ
• ユーザーパイロット計画
• テスト戦略
• リモートデプロイの再開基準
• v1.10.0 リリースノート
• v1.9.0 リリースノート
• AI コーディングエージェントのスモークテスト
• 変更履歴
• リリース
• 未解決の Issue

npm と MCP Registry のワークフローでは、GitHub OpenID Connect（OIDC）の信頼されたパブリッシングを使用します。GitHub Release を公開すると、両方のワークフローがトリガーされます。Registry のワークフローは、該当する npm パッケージのバージョンが公開されるまで待機してから、一致する不変の stdio メタデータを公開します。

ライセンス

MIT