Ninchi CLI & MCP
ターミナル、Git フック、CI ジョブ、または Cursor や Claude Code などの MCP 対応エディタから Ninchi チェックを実行できます。
各チェックは、提出された成果物に紐づく、示された理解のエビデンスを記録します。プログラムによるチェックはプルリクエスト検証とは別のエビデンス区分であり、潜在能力やコンピテンシーを測定するものではありません。
前提条件
Ninchi アカウント、対象組織のメンバーシップ、およびプログラム連携を有効にした組織管理者が必要です。
GitHub App をインストールしたのに組織が表示されない場合
GitHub App をインストールした GitHub アカウントで Ninchi にサインインしてください。組織は GitHub ID を通じてリンクされるため、その GitHub ID がないメールアドレス・パスワードのアカウントでは、インストール済みの組織を引き継げません。
- ダッシュボード URL の
/dashboard/orgs/に続くセグメントが組織 ID です。数値 ID(42)と組織の UUID 形式のパブリック ID のどちらも使用できます。新しいダッシュボード URL は UUID 形式ですが、既存設定の数値 ID も引き続き有効です。現在 CLI には組織一覧コマンドがありません。 - 組織管理者に、組織設定の Programmatic Checks (CLI & MCP) を開き、「Enable CLI & MCP check submission」を有効にしてもらいます。
- プログラムによるチェックのクォータは、開発者ごとの直近 30 日間に対するハード上限です。429 応答には次のチェックが利用可能になる時刻が含まれます。
| プラン | 開発者ごとのチェック数 | 期間 |
|---|---|---|
| Hobbyist / Free | 0 | 直近 30 日間 |
| Standard | 20 | 直近 30 日間 |
| Pro | 100 | 直近 30 日間 |
| Enterprise | 100+ | 直近 30 日間 |
インストールと実行ファイルの PATH
pipx は CLI を隔離された環境にインストールし、ninchi 実行ファイルを公開します。Ninchi CLI 0.2.0 は PyPI で公開されています。
検証済みの公開インストール
以下のコマンドは、非公開 Ninchi リポジトリにアクセスできないクリーンな pipx 環境から公開 PyPI に対して正常に動作することを確認済みです。
pipx install ninchi-clipipx アプリケーションをシェルの PATH に追加し、新しいシェルを開いて実行ファイルを確認します。
pipx ensurepath
# Close and reopen your shell, then verify:
command -v ninchi
ninchi --helpspawn ninchi ENOENT
エディタに「spawn ninchi ENOENT」と表示された場合、実行ファイルが見つかっていません。GUI エディタは対話シェルの PATH を引き継がないことがあります。ターミナルで command -v ninchi を実行し、その絶対パスを MCP の command に指定してください。
command -v ninchi
# Use the printed absolute path in your MCP configuration.認証
対話型ログインはデバイスフローを使用するため、ターミナルで Web サイトのパスワードを扱うことはありません。
ninchi login- CLI に確認 URL と XXXX-XXXX 形式の 8 文字コードが表示されます。
- URL を開いてサインインし、
/dashboard/deviceでコードを承認します。 - CLI は承認までポーリングし、発行された個人アクセストークンを保存します。
認証情報はファイルモード 0600 で ~/.config/ninchi/credentials に保存されます。NINCHI_CONFIG_DIR または XDG_CONFIG_HOME で保存場所を変更できます。
CI と手動作成トークン
export NINCHI_API_TOKEN="ninchi_pat_..."
export NINCHI_ORG_ID=42CI ではトークンを NINCHI_API_TOKEN として保存します。PAT の作成・失効は /dashboard/profile で行います。既定で checks:read と checks:write スコープを持ち、平文は一度だけ表示され、Ninchi 側では HMAC ダイジェストとして保存されます。失効後は直ちに利用できなくなります。
CLI コマンド
check コマンドは既定で作業ツリーの差分を使用します。必要に応じて別の入力元を 1 つだけ選択します。
# Working-tree diff (default)
ninchi check --org-id 42
# Other subject sources
git diff | ninchi check --stdin --org-id 42
ninchi check --staged --org-id 42
ninchi check --commit HEAD --org-id 42
ninchi check --file src/app.py --language python --org-id 42
# Reuse the org ID from your environment
export NINCHI_ORG_ID=42
ninchi check --staged
# Automation: answer non-interactively and emit JSON
ninchi check --staged \
--answer "$ANSWER" \
--actor agent_assisted \
--json
# Inspect an existing challenge
ninchi result CHALLENGE_ID
ninchi result CHALLENGE_ID --json
ninchi history --limit 20
ninchi history --limit 20 --json回答者の種別
- プロンプトで入力した回答は既定で human_attested です。
- --answer または非対話プロセスでは既定で agent_assisted です。
- --actor で human_attested、agent_assisted、agent_autonomous を明示できます。誰が回答を作成したかを正直に表す値を使用してください。
終了コード
0— チャレンジに合格1— チャレンジに不合格2— 処理中、または運用・認証・設定・API エラー
login は --timeout、--api-url、--json に対応します。check は --poll-interval と --timeout にも対応します。result にはチャレンジ ID を渡し、history では --limit を指定できます。--json はサブコマンドの後に置いてください。
Git フックと CI
同じコマンドを push 前や自動化内で実行できます。非対話の回答には、正確な回答者プロベナンスが必要です。
pre-push フック
#!/usr/bin/env bash
set -euo pipefail
base="${NINCHI_BASE_REF:-origin/main}"
git diff --patch "$base"...HEAD | ninchi check \
--stdin \
--org-id "${NINCHI_ORG_ID:?set NINCHI_ORG_ID}".git/hooks/pre-push として保存し、実行権限を付与します。人がターミナルで対話的に回答する場合は --answer を指定しません。
最小構成の GitHub Actions ジョブ
name: Ninchi check
on:
pull_request:
jobs:
ninchi:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pipx install ninchi-cli
- name: Submit Ninchi check and surface the challenge
run: |
git diff --patch origin/${{ github.base_ref }}...HEAD |
ninchi check --stdin --json | tee ninchi-challenge.json || true
env:
NINCHI_API_TOKEN: ${{ secrets.NINCHI_API_TOKEN }}
NINCHI_ORG_ID: ${{ vars.NINCHI_ORG_ID }}CLI は公開 PyPI から直接インストールします。認証情報はワークフローファイルではなく GitHub Secrets に保存してください。このジョブは意図的に提出までで止まります。--answer を指定しない場合、CLI はチャレンジの JSON を出力して終了コード 2 で終了します。回答は変更を作成した本人が行う必要があります。たとえば pre-push フックや MCP 対応エディタで対話的に回答してください。定型回答を CI に組み込まないでください。質問は提出ごとに生成され、回答時間はチャレンジが最初に表示された時点から始まります。
MCP サーバー
ninchi パッケージには、エージェント対応エディタ向けの stdio MCP サーバーが含まれます。最初に ninchi login で認証してください。
基本設定では実行ファイルの絶対パスを使用します。プレースホルダーを command -v ninchi の出力に置き換えてください。
{
"mcpServers": {
"ninchi": {
"command": "/absolute/path/from/command-v-ninchi",
"args": ["mcp"]
}
}
}エディタが ninchi を含む PATH を確実に引き継ぐ場合に限り、コマンド名だけを使用できます。
{
"mcpServers": {
"ninchi": {
"command": "ninchi",
"args": ["mcp"]
}
}
}| ツール | 用途 |
|---|---|
submit_check | 差分、コンテンツ、またはファイル領域を 1 つ提出し、質問生成を開始します。 |
get_challenge | 生成完了を待ちながら、作成された質問を取得します。 |
submit_answer | 必須の正確な actor 指定とともに回答を提出します。 |
get_result | 評価完了を待ちながら、スコアとフィードバックを取得します。 |
list_history | 認証中の開発者の最近のチャレンジを一覧表示します。 |
エージェント回答は組織ポリシーに従います
submit_answer では actor が必須です。組織ポリシーが blocked の場合、ツールは質問を人に渡し、その人自身の回答だけを human_attested として中継するよう案内します。recorded の場合、agent_assisted と agent_autonomous の回答が受理され、そのプロベナンスとともに保存されます。ポリシーを回避するために actor を変更してはいけません。
MCP の提出には client_attribution: "mcp:<client>" が付与されます。これは提出チャネルを示し、検出可能な範囲の下限として AI 作成分析に利用されますが、それだけで AI 支援があったと断定するものではありません。
エビデンスとスコアの扱い
プログラムによるチェックは origin="api" を使用し、別の低加重エビデンス区分として扱われます。保存された質問、回答、スコア、成果物の文脈、actor の申告、クライアント属性、タイムスタンプは、そのイベントに関する確認可能なエビデンスです。
スコアへの算入はオプトイン
既定では、プログラムによるチェックは Ninchi Score に算入されません。組織管理者は Programmatic Checks カードの「Count programmatic checks toward Ninchi Scores」を有効にできます。いずれの場合も、プルリクエストのエビデンスには影響しません。
トラブルシューティング
| 症状 | 対処方法 |
|---|---|
spawn ninchi ENOENT | エディタが実行ファイルを見つけられていません。pipx ensurepath を実行し、新しいシェルを開いて command -v ninchi を実行し、その絶対パスを MCP 設定に指定します。 |
403 "not enabled" | 組織管理者が Programmatic Checks (CLI & MCP) 設定カードの「Enable CLI & MCP check submission」を有効にする必要があります。 |
429 | 開発者ごとの直近 30 日間のクォータを使い切っています。応答に含まれる正確な UTC リセット時刻を確認してください。 |
403 agent answer | 組織がエージェント作成回答をブロックしています。質問を人に渡し、その人自身の言葉だけを human_attested として提出してください。 |
チャレンジの期限切れ | 回答時間は、準備済みチャレンジが最初に表示された時点から始まります。TTL は組織が設定し、既定値は 5 分です。 |
202 "generating" / "evaluating" | 質問生成と回答評価は非同期です。202 は正常な状態です。完了応答またはタイムアウトまで get_challenge または get_result をポーリングしてください。 |
解決しない場合は サポート にアクセスし、可能であれば応答の X-Request-ID を添えてください。