no_human

信頼できるAI コーディングファクトリー：

• コードを書く前に計画を作成します。チケットと、リポジトリ内で見つけた情報をもとに計画します。 計画に失敗した場合は、計画なしで作業していることをコーダーに伝えます。 変更が些細だと判断された場合は、設計上、コーダーには伝えずに計画を省略します。 ただし、省略したことは実行時のイベントストリームに記録されます。
• **敵対的レビューを実施します。**コーダーのトランスクリプトを一度も見ていない別のモデルに、「完了」を反証するよう指示します。ファイルと行を引用した合否チェックリストが得られます。数値による自己採点は行いません。
• **改ざんを検知します。**テストの削除、新たなスキップ、アサーションの恒真式への置き換えなどを、レビューゲートの実行前に機械的に検出します。そのうえで受け入れ基準に照らして正当化できなければ、処理を停止します。
• **修正でバグが直ったことを証明します。**根拠として提示されるテストは、マージベースでは失敗し、新しいツリーでは成功しなければなりません。再現ゲートで両方を実行します。 初期設定では Python のバグ修正に適用されます。repro_gate.mode: required を設定すると、あらゆる種類の変更に適用されます。
• **テストを実行します。**ローカルで実行し、必要に応じて CI でも実行します。テストコマンドが見つからなかったプルリクエストには、NOT RUN と明記されます。
• **誠実に停止します。**完了できない場合は停止し、その理由を伝えます。回答によって作業を進められる場合は具体的な質問をし、単に予算を使い切った場合は構造化された記録を残します。もっともらしい差分を捏造することはありません。

ゲートで検出された内容

no_human は no_human を開発しています。自らのボードで65日以上運用しましたが、以下の問題がプルリクエストに到達することはありませんでした。

• コーダーが完了とした1,709件の試行のうち505件が、ファイル名と行番号を示した合格／不合格チェックリストとともに、2つ目のモデルから差し戻されました。
• 44件の試行は、テストを削除または弱体化したため、レビューが実行される前に停止されました。
• 46件のバグ修正の証明は、証拠として提示されたテストが修正前のコードでも成功していたため、却下されました。

集計方法

インストール

1行でインストール（CLI＋ボード）

uv tool install no-human   # or: pipx install no-human — the wheel ships the board
nh init && nh doctor       # token, config, first repo; then prove the install is real

デスクトップアプリ

各リリースには、アーティファクトとともに SHA-256 が同梱されています。プラットフォームごとの注意事項と初回起動時の手順については、docs/quickstart.mdをご覧ください。

ソースからインストール

git clone https://github.com/no-human-ai/no_human.git && cd no_human
uv sync                 # installs the `nh` entry point into .venv
(cd web && npm install && npm run build)   # builds the board (cold first install can take minutes)
uv run nh init          # token, config, first repo (about 2 minutes)
uv run nh doctor        # verify the install is real before relying on it

ボードを使う場合、web のビルドは必須です。ソースチェックアウトには web/dist が含まれないため、ビルドしないと nh start は API のみを提供し、UI は表示されません。Python 3.12 以降、uv、git、およびボードのビルドに必要な npm を含む Node が必要です。

製品の特長

コードを書く前に計画を立てます チケットとリポジトリをもとに作成された、確認可能な受け入れ基準です。
独立したレビュアー コーディングエージェントのセッションを一切見ていない2つ目のモデルに、「完了」を反証するよう指示します。合格か不合格かを判定し、ブロッカーとなる指摘にはすべてファイルと行番号が示されます。
テスト結果をプルリクエストに表示します ローカルまたはCIで実行できます。テストコマンドが見つからない場合は、空欄ではなく未実行と表示されます。
改ざん防止機能 削除されたテスト、新たに追加されたスキップ、同語反復的なアサーションをレビュー前に検出します。正当な理由がなければ、試行は停止します。
修正によってバグが直ったことを証明します 証拠として提示するテストは、修正前のコードでは失敗し、修正後のコードでは合格しなければなりません。ゲートが両方を実行し、イベントログに判定が表示されます。
正直に作業を停止します あなたの確認が必要な場合は、推測せずに具体的な質問を1つ提示して待機します。
チケットトラッカーのチケットをボードで確認できます バックログからJiraまたはLinearのチケットを選択できます（monday.comのボードはポーリングされます）。各チケットは開始前に、あなたと一緒にスコープを定めます。

_{画像：デモ用の作業負荷を使った実際のボード。}

1つのタスクを実行する

引数なしでnhを実行するとシェルが開きます。レーン、リアルタイムのイベントログ、そして平易な英語でタスクを説明できる受付機能を利用できます。以下のコマンドはすべて引き続き使用できます。

nh                                   # the shell
nh start                             # board + worker on 127.0.0.1:8420
nh task add https://github.com/org/repo/issues/42 --repo ~/git/repo
nh status                            # needs-you / working / waiting / done
nh review <id>                       # the reviewer's evidence checklist
nh diff <id>                         # the diff it wants to ship
nh approve <id>                      # your approval squash-lands the PR (git.approve_identity)
nh reject <id> --reason "..."        # send it back with feedback

インテグレーション

no_human を現在お使いのトラッカーに接続すると、チケットがボードに取り込まれます。トラッカーのフィルターは設定ファイルに置かれ、タスク自体のテキストには入りません。また、通信エラーが発生してもプールがクラッシュするのではなく、ログに記録され、次のティックで再試行されます。

トラッカー	チケットの取り込み方法	設定するフィルター
Jira Cloud	REST search/jql でポーリング（HTTP Basic email:token）	integrations.jira.jql
Linear	GraphQL API でポーリング	integrations.linear.team_key + state_types + label
monday.com	GraphQL v2 でポーリング	integrations.monday.board_id + status_column + todo_labels

書き戻し（デフォルトではオフの write_back）を有効にすると、チケットはタスクとともに移動します。ステータスカテゴリ、タイプ、または指定したラベルに基づいて照合され、ハードコードされた遷移 ID は使われません。また、PR のリンクが追加されます。人間による対応が必要なタスクにはコメントが投稿されますが、ステータスは遷移しません。GitHub と GitLab の issue は URL からタスクとしてインポートされ、PR または MR はお使いのホスト上で作成されます。タスクで対応が必要な場合は、Slack と Teams にメッセージが届きます。Jenkins と CircleCI ではテストレイヤーを実行して、ループの続行を制御できます。各サービスのセットアップについては、 docs/adapters.md をご覧ください。

Jira のフローを最初から最後まで見る — Jira ボードから同期されたチケットの範囲を絞り込み、実装し、レビューに合格したプルリクエストとして届けるまでの流れです（すべての手順を含む動画をクリックして再生できます）。

▶️  デモ全編を再生 — Jira ボードからレビュー合格済み PR まで、1:33

GitHub Action

同じ敵対的レビュー機能と改ざん防止機能を、プルリクエストのチェックとして実行できます。一度きりの実行で、デーモンも ~/.no_human データベースも不要です。キューに登録する nh review CLI の経路も使いません。差分だけを判定します。ローカル実行とは異なり、lint、配線、型の証拠を収集せず、リポジトリの調査も行いません。file:line の引用を含む合否チェックリストのコメントを 1 件投稿します。このコメントは独自のマーカーで識別され、実行ごとに新しいコメントを作成するのではなく、既存のコメントが更新されます。このコメントでは、イベントのペイロードから取得したプルリクエスト作成者に @ メンションします（差分や PR のタイトル／本文から取得することはありません）。GitHub はコメントを作成する初回の実行では通知しますが、コメントをその場で編集する以降の実行では通知しません。コメントには、その実行がどちらのケースに当たるかが明記されます。

# .github/workflows/review-gate.yml
name: no_human review gate
on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}
      - uses: no-human-ai/[email protected] # a release tag; a reviewed SHA is stronger — see below
        with:
          credential: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ github.token }}

permissions.contents: read により、actions/checkout はこのリポジトリを読み取れます。Action が自身のコメントを投稿または更新できるのは、pull-requests: write の権限があるためです。どちらも、それ以上の広い権限を与えるものではありません。チェックアウト手順で ref: ${{ github.event.pull_request.head.sha }} を明示することも重要です。pull_request イベントでは、指定しないと actions/checkout は PR の実際の head ではなく、一時的なマージコミットをチェックアウトします。Action はディスク上にあるツリーをレビューし、それに対する行番号を引用するため、誤ったツリーのレビューは拒否されます。そのため、ここで ref: を省略すると、レビューの誤りが見過ごされるのではなく、対処可能な終了コード 2 で赤く失敗します。

この Action には、まだ v1 タグがありません。action.yml を含む最初のリリースタグは v0.2.4 であり、no-human-ai/[email protected] で指定できるため、上の例ではこのタグを固定しています。ただし、リリースタグは更新され続けるメジャーバージョンではなく、@main は直近に追加された内容を指します。レビュー済みのコミット SHA（no-human-ai/no_human@<sha>）を使うと、さらに強固です。ブランチは定義上移動し、タグも移動できるため、後からこのリポジトリに変更が加わっても、ワークフローの実行内容を変えられない指定方法は SHA だけです。この Action は、お客様の認証情報を使って実行されます。 credential には、Anthropic の認証情報をどちらの形式でも指定できます。ANTHROPIC_API_KEY（sk-ant-api...）または claude setup-token で発行した Claude サブスクリプションの OAuth トークン（sk-ant-oat...）を指定すると、プレフィックスから形式が自動検出されます。または、credential_mode: oauth／credential_mode: api_key で明示的に指定できます。どちらの形式を指定しても、レビュアーの実行前に、もう一方の認証情報の経路はジョブの環境から消去されます。また、値は読み取られた時点でログ上でマスクされます。

認証情報は必須であり、暗黙のフォールバックはありません。 secrets.ANTHROPIC_API_KEY（または credential に割り当てたシークレット）が空、未設定、あるいは auto モードでも Action が認識できない形式の場合、レビュアーや GitHub API 呼び出しが実行される前に、credential 入力と必要なシークレットの名前を示して、終了コード 2 で明確に失敗します。同じフェイルクローズのルールは、レビュアー自体でエラーが発生した場合や、モデル呼び出しが拒否された場合にも適用されます。その場合も終了コード 2 で終了します。認証情報またはレビュアーのエラー時に、Action が PASS を投稿したり、終了コード 0 で終了したりすることはありません。ただし、チェックが緑色でも、必ずしもゲートでコードがレビューされたとは限りません。フォークからのプルリクエストは終了コード 0 でスキップされ、レビュアーも呼び出されません（下記参照）。また、差分が空のプルリクエスト（レビュー対象がない場合）は、レビュアーや改ざんガードの呼び出しなしで、合成 PASS を投稿します。これを必須チェックにする場合は、どちらも承認ではなく「レビューされていない」として扱ってください。差分がレビュアーの単一ターンの上限を超える場合、切り詰めた先頭部分だけをレビューするのではなく、終了コード 2 で拒否されます。その場合にチェックが緑色になることはありません。max_files を減らすか、プルリクエストを分割してください。

フォークはレビューされず、スキップされます。 head がこのリポジトリではないプルリクエスト（すでに削除されたフォークからのものも含む）は、レビュアーにもモデルにも到達しません。シークレットにアクセスできるジョブで未検証の head に対してレビューコードを実行する代わりに、Action はコメントを投稿せずに説明を示して終了コード 0 で終了します。pull_request_target は、有効な認証情報があっても無条件で拒否されます（終了コード 2）。このトリガーは、フォークの head をシークレットを含むジョブに持ち込める形式だからです。

workflow_run もサポート対象のトリガーです。この場合、pull_request ペイロードではなく GitHub REST API を使って、プルリクエスト番号、head コミット、変更されたファイルを再構成します。このモードではチェックアウトされたリポジトリツリーがないため、改ざんガードは実行されません。投稿されるコメントでは、改ざんチェックが正常だったかのように示唆するのではなく、そのことを明示します。

Dependabot が作成したプルリクエストはフェイルクローズされ、終了コード 2 で失敗します。これはこの Action ではなく、GitHub の制限によるものです。 Dependabot が作成したプルリクエストの head は同じリポジトリであり、フォークではないため、上記のチェックでスキップされることはありません。しかし GitHub は、pull_request イベントで起動されたワークフローの実行に対し、プラットフォームレベルの保護として、リポジトリのシークレットを渡さず、GITHUB_TOKEN の権限を読み取り専用に変更します。これは、ロックファイルの更新に悪意あるインストールスクリプトを仕込み、シークレットを含むジョブで実行させることを防ぐためです。そのため、こうした実行では credential が空になり、この Action 独自のフェイルクローズのルール（上記参照）によって、不足しているシークレットを示す、対応可能なエラーとして終了コード 2 で失敗します。暗黙のスキップや誤った PASS にはなりません。このチェックを必須にして Dependabot の PR を緑色にしたい場合は、ブランチ保護ルールで Dependabot を除外するか、GitHub がボット起動のジョブに渡さないシークレットを必要とする他のチェックと同様に、メンテナーによる手動の再実行／承認が必要であることを受け入れてください。 コストはトークン数や時間ではなく、ファイル数によって上限が決まります。 max_files（デフォルトは 15）は、レビュアーに送信する変更ファイルの最大数を指定します。パス順に並べた先頭のファイルが対象となり、 コメントには、全体のうち実際にレビューされたファイル数が記載されます。 レビュアーは single_turn で実行されるため、問題なく完了する場合は上限内の差分に対するモデル呼び出しが1回、 失敗する場合は上限付きの反論パスが1回追加されることがあります。おおよその費用は、差分のサイズに応じて Anthropic の利用料が数セントから数十セント程度で、ローカルで nh review を1回実行する場合と同じような規模です。これは、ワークフローでイメージをキャッシュしない限り、 実行のたびにランナーが Docker イメージをビルドする一度限りのコスト（数十秒の GitHub ホストランナーの計算時間であり、モデルの利用料ではありません）とは別です。費用を抑えるには、 max_files を小さくするか、大きなプルリクエストを分割してください。

このアクションは、プルリクエストに対する独自のコメント1件以外について、マージ、プッシュ、承認、編集を 行うことはありません。これは単なる慣例ではなく、コードによって強制されています。GitHub API の呼び出しはすべて、 送信前に2つのエンドポイントの許可リスト（そのコメントスレッドの一覧取得／作成／更新）と照合されます。 チェックを失敗させずにコメントを残すには fail_on_findings: false を設定し、GitHub API を一切呼び出さずに 判定結果をジョブログ／サマリーに出力するには dry_run: true を設定してください。

既知の制限事項：「テストツリー全体」を対象とするという改ざんガードの説明は、 ASCII のテストファイル名に限られ、非 ASCII のファイル名には当てはまりません。 改ざんチェックは レビュアーに送信される max_files 制限付きの対象だけでなく、リポジトリ内のすべてのテストファイルを、 引用符で囲まない git ls-tree を使って走査します。そのため、名前に 非 ASCII バイトを含むテストファイルは、実際のパスではなく Git の C 引用形式の文字列（例： "r\303\251gression_test.py"）として一覧表示され、改ざんガードの変更前後の比較から気付かれないまま 除外されます。そのようなファイルを削除または弱体化しても、現時点では検出されません。このアクションが 差分を取得してレビューするファイルの一覧には、同等の問題は影響しません（レビュアーに渡すすべてのパスを明示的に 再引用して再検証するためです）。ただし、このアクションの対象範囲外であるため、基盤となる 改ざんチェックモジュールは変更しません。テストスイートに非 ASCII のテストファイル名がある場合は、 上流で修正されるまで、該当ファイルに対する改ざんガードはベストエフォートとして扱ってください。

既知の制限事項：2回の実行が競合した場合、またはプルリクエストにすでに 他のコメントが1,000件以上ある場合、コメントが重複することがあります。 このアクションは、PR のコメント一覧 （最大10ページ、各100件）から独自のコメントを探し、マーカーが付いたコメントのうち最も小さい ID のものを選びます。 間隔を空けずに開始された2回の実行は、一方がコメントを作成する前にどちらも一覧を取得することがあり、その場合は それぞれがコメントを作成します。後続の実行では、再び一覧を取得して最も小さい ID のマーカー付きコメントを見つけ、 それを更新するため、最終的にはどちらの実行も同じコメントに収束します。ただし、余分なコメントは削除されません。 同じ「一覧取得後に処理する」という隙間により、11ページ目以降にしか表示されないマーカー付きコメント（プルリクエストに 他のコメントがすでに1,000件以上ある場合）は、存在しないものとして扱われ、更新されずに新しいコメントが作成されます。 どちらも失敗が黙って発生するのではなく、許容され文書化された制限事項です。同じコミットに対して ワークフローが2回実行される可能性がある場合は、プルリクエストをキーとする concurrency: グループを追加して、実行を直列化してください。

MCP サーバー — 現在のエージェントから作業を依頼する

no_human は MCP（Model Context Protocol）サーバーを提供しています。公式の Python MCP SDK を基盤に構築された stdio ブリッジで、Claude Code、Cursor、その他の MCP クライアントからローカルの no_human に作業を依頼し、進捗を確認できます。

nh mcp-serve        # the MCP server, over stdio

ツールは 2 つだけです。

ツール	機能
task_add(title, description, repo_path)	タスクを登録します。no_human が計画を立て、変更を作成し、テストを実行して、2 つ目のモデルでレビューした後、プルリクエストを作成します。
task_status(task_id_or_external_id)	タスクの現在の状態（ステータス、試行回数、作成後の PR リンク）を返します。

接続先は自分の no_human（http://127.0.0.1:8420）のみです。認証は不要です。接続先が localhost であり、その間に当社のサービスが介在しないためです。Claude Code 向けには、同じサーバーをプラグインとして提供しています。このリポジトリ自体がプラグインマーケットプレイスなので、次の操作を行うと、セッションに 2 つのツールが表示されます。

/plugin marketplace add no-human-ai/no_human
/plugin install no-human@no-human-ai

その他の MCP クライアントでは、通常の stdio エントリを使用します。

// .mcp.json
{ "mcpServers": { "no_human": { "command": "nh", "args": ["mcp-serve"] } } }

プラグインには review-this-branch スキルも含まれています。このスキルは MCP サーバーも ~/.no_human も必要としません。1 回限りの CLI コマンド nh gate を実行し、Claude の認証情報を使って、フレッシュセッションの敵対的レビューと改ざん防止ガードを現在のブランチまたは GitHub プルリクエストに直接適用します。その後、合格／不合格を示す Markdown チェックリストを出力して終了します。インストールまたは実行されるのは nh CLI のみです。

nh gate                        # current branch vs. its merge base with origin's default branch
nh gate --pr <github-pr-url>   # a GitHub pull request's head vs. its merge base

ドキュメント

quickstart.md	各プラットフォームで、最初のタスクを実行するまで
configuration.md	すべての設定とデフォルト値
verification.md	ゲート、制限付きループ、制限事項
security.md	認証の境界、マージ禁止ルール、ガード
blockers.md	エスカレーション、起動監視、nh reply
adapters.md	受付、コンテキスト、VCS と CI のバックエンド
eval.md	ゴールデンセット、リプレイ評価、シャドーモード
CHANGELOG.md	リリースごとの変更内容

開発

uv sync
uv run pytest -q
uv run nh --help

イシューやプルリクエストを歓迎します。送信前に uv run pytest -q を実行してください。

no_human によってレビューを 1 サイクル省けた場合は、スターを付けていただけると、他の人が見つけやすくなります。

コミュニティ

質問、バグ報告、紹介したい実行例は、Discord に参加するか、r/no_human に投稿するか、GitHub issue を作成してください。

ライセンス

MIT — LICENSE を参照してください。ライセンスの対象はコードであり、名称ではありません。「no_human」とロゴの使用ポリシーについては TRADEMARK.md をご覧ください。ソースツリーにはない義務がバイナリのパッケージ化には伴います。詳細は THIRD-PARTY-NOTICES.md に記載されています。