nomArmy

Name: nomArmy
Author: rayson-tech

ローカル

nomarmy.dev開発ツール41 週間前に更新

リポジトリ公式サイト

nomArmy について

nomArmyは、コーディングアシスタント向けにサンドボックス内のコーディングワーカーを調整し、コミット前に変更を独立して検証します。新しいサンドボックスでのテスト、変更を戻して行う再テスト、シークレットスキャンを実施します。

主な機能

01サンドボックス内のワーカーへのタスク委任
02差分の確認と新しいサンドボックスでのテスト再実行
03変更を戻してテストの検出力を確認
04シークレットのスキャンとテスト回避の検出
05検証済みの変更を別ブランチにコミット
06ワーカーなしでの検証実行

活用シーン

01受け入れ条件を添えてバグ修正を委任
02ワーカーを起動せずブランチのテストを確認
03レビューとマージ前に機能変更を検証
04ワーカーの変更に含まれるシークレットや弱められたテストを検出

MCP 対応

READMEではReasonプラグインにMCPサーバーが含まれると述べていますが、nomArmyがMCPを提供または利用するとは記載されていません。

設定

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

mcp.json · 共通設定

{
  "mcpServers": {
    "rayson-tech-nomarmy": {
      "command": "npx",
      "args": [
        "-y",
        "nomarmy"
      ]
    }
  }
}

起動コマンドnpx -y nomarmy

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

パッケージ

npmnomarmy0.1.0-beta.14stdio

ツール

掲載時のツール一覧 · 1 週間前に更新

パラメーター	型	必須	説明
mode	enum	いいえ	verify：worker とモデルのトークンを使わず、必須の検証プロファイルを実行します。base_ref はブランチまたはコミットを選択します（デフォルトは現在の HEAD）。task は短い記録用ラベル、agent/model は未使用、army_role はラベルのみです。implement：分離された worktree で編集し、有効なレポートを受けてからコーディネーターがコミットします。scout：読み取り専用の調査です。すべての調査結果に [path:start-end] を引用として付け、nomArmy はベースコミットと照合して確認した後、引用された行を添付します。decompose：読み取り専用です。広範な目標について、1 回の worker ターンですべてを行うのではなく、相互に独立し、証拠に基づく 2 件以上のサブタスク分割案を提示します。自動ディスパッチは決して行われません。提案は scout の調査結果と同様にレビューされ、コーディネーターが別途ディスパッチを呼び出し、採用するサブタスクを選択します。scout \| implement \| decompose \| verify
task	string	はい	implement：worker が達成すべき目標であり、実行すべき編集内容ではありません。scout：リポジトリから回答する質問です。decompose：分割案を提示する対象となる広範な目標です。
agent	string	いいえ	オペレーターの agents.yml に登録された agent を名前で指定して実行します（例："codex"、"grok"、"local"）：ローカルモデル、従量課金の api key、または個人サブスクリプションです。agent と army_role を省略するとローカルモデルを使用します。不明な名前は拒否され、フォールバックは行われません。army_role とは併用できません。サブスクリプション型 agent には on_behalf_of も必要です。
model	string	いいえ	ジョブの agent（api またはサブスクリプション型 agent）で実行するモデルです。例："gpt-6-sol"。ロールのモデルと agent の既定モデルを上書きします。ロールのモデルが "auto" の場合、または agent に既定モデルがない場合は必須です。`army` ツールで各 agent のモデルを一覧表示できます。ローカル agent では `nomarmy model` がモデルを設定するため、指定すると拒否されます。
report	enum	いいえ	worker が返せるレポートの詳細度です。agent のティアによる上限があります：brief（ローカル規模の短いレポート）、standard（既定値）、full（上限：implement は約 2k tokens、scout は約 4k tokens）。api またはサブスクリプション型 scout は調査結果が主目的のため、既定値は full です。それ以外のジョブの既定値は standard です。レポートはあなた自身のコンテキストに入り、その後の各ターンで再読み込みされます。上限が調整済みのローカルモデルには影響しません。brief \| standard \| full
run_id	string	いいえ	このジョブが属する /feature 実行（run_start から取得）。参加時に実行の制限（ジョブ数、api 支出、時間）が適用され、ベンダーの使用量上限エラーにより実行で一時停止された agent は拒否されます。完了したジョブは実行に記録されます。
stakes	enum	いいえ	implement：作業の難易度とは別に、ミスがどれほどの損害につながるかを指定します。セキュリティやアクセス制御、個人データまたはテナントデータ、データ損失、金銭、取り消せない変更に関わる場合は high にします。この場合、検証プロファイルが必須となり、リバートチェックを無効にできず、独立レビュー（別ベンダーの scout が reviews: <job id> を指定するか、別ベンダーの judge が実施）を受けるまで、常にレビューが必要な状態になります。認証の 1 行変更でも、作業は簡単でリスクは高い場合があります。normal \| high
reviews	string	いいえ	scout：この scout が独立レビューするジョブ ID です。レビューはそのジョブに記録されます（nomarmy stats では、独立レビューの有無を含む高リスクジョブが表示されます）。ジョブの worker とは異なるベンダーを使用してください。
base_ref	string	いいえ
criteria	array	いいえ	implement：このジョブが提供する acceptance/*.yml の契約 ID。
evidence	string	いいえ	implement 専用：すでに確認済みの事実（例：repo_evidence で確認した内容）のみを記載します。worker が信頼して再導出する必要のない、正確なシグネチャ、呼び出し箇所、行範囲、既存の動作などです。すでに把握している内容の探索に worker 自身のコンテキスト予算を費やすのを防ぎます。明確な目標や受け入れ基準の代わりにはなりません。
refactor	boolean	いいえ	implement：動作を維持する変更（コードの移動または再構成）を指定します。nomArmy は検証プロファイルの合格を要求し、テストファイルが追加、変更、削除されている場合はコミットを拒否します。既存のテストが変更なしで通ることが、動作が変わっていない証拠になります。リファクタリングを元に戻せば動作するコードに戻り、常にテストに通るため、リバート確認はスキップされます。動作を変えるタスクではテストの変更が必要となるため、リファクタリングとしては通りません。
army_role	string	いいえ	army ロール（例："sr-dev"、"security-analyst"）で振り分けます。nomArmy は、このリポジトリがそのロールに割り当てたエージェントで実行し、ブリーフの先頭にロールの説明を記載します。まず `army` ツールを呼び出して、このリポジトリのロールを確認してください。agent とは相互排他です。ロールのエージェントがサブスクリプションの場合は on_behalf_of を追加してください。それ以外の場合は無視されます。
reasoning	enum	いいえ	worker モデルに渡す思考レベル：off、minimal、low、medium、high、xhigh、adaptive、max、ultra（高いレベルはベンダーが提供する場合のみ使用できます。例：Codex モデルの xhigh。モデルが対応していないレベルは、最も近い対応レベルに一度だけフォールバックします）。高いレベルほど、サブスクリプションの使用量上限を速く消費します。ローカルモデルでは、そのモデルが思考に対応している場合に有効になります（NOMARMY_MODEL_THINKING）。api または subscription エージェントでは、エージェント独自の `thinking` 設定に従います（false = off、固定レベル = 常にそのレベル）。実測結果に基づき、デフォルトは high ではなく medium です。同一のチケットで gpt-oss-20b は high で 318s、ツール呼び出し 21 回、失敗 4 回でしたが、medium では 62s、呼び出し 9 回、失敗 0 回でした。high でも回答は改善せず、試行錯誤が増えました。別の自由形式タスクでは、Qwen3.6-27B は high で完全にタイムアウトしました（630s、出力なし）が、medium では成功しました。考えるほど役立つはずという理由で、デフォルトを high に上げないでください。これまでのテストでは、悪影響かタイムアウトしか起きていません。medium で一度失敗し、原因が思考不足（フォーマットや範囲の問題ではなく、根本原因の誤り）と明確に見られる場合にのみ high を検討してください。off \| minimal \| low \| medium \| high \| xhigh \| adaptive \| max \| ultra
worker_id	string	いいえ
acceptance	array	いいえ	implement：worker が満たすべき受け入れ基準。scout：完全な回答で網羅すべき点。decompose：適切な分割が守るべき制約。
on_behalf_of	string	いいえ	ジョブのエージェントがサブスクリプションの場合は必須です。agents.yml に記載されたそのエージェントの所有者と完全に一致する必要があり、一致しなければ nomArmy はジョブを拒否します。自己申告の表明であり、独立して確認された本人確認ではありません。nomArmy には現在、呼び出し元の ID 境界がないため、保証されるのは明示的で監査可能な意図と、不一致または省略時の確実な拒否であり、呼び出し元の暗号学的な証明ではありません。ローカルまたは api エージェントでは無視されます。
verification	string	いいえ	検証プロファイル名（例：quick、standard、browser）。意味は nomArmy が定義し、実行も nomArmy が担当します。scout では無視されます。
continue_from	string	いいえ	implement 専用：保留されている未コミットの implement ジョブ（作業途中、ブロック中、または検証失敗）の job id。このジョブで未完了の作業を仕上げます。新しい worktree は、そのジョブの base から変更を含んだ状態で作成されるため、ブリーフには修正内容だけを記載します。元の変更を含む作業全体をまとめて検証し、コミットします。worker のファイルを自分で修正すると未検証のまま反映されるため、代わりにこの項目を使用してください。base_ref は指定しないでください。
commit_subject	string	いいえ	implement：nomArmy が worker ブランチに作成するコミットの件名。例："Keep held-back tables in the list_tables cache"。デフォルトはタスクの最初の文です。本文は worker の NOTE で、job id がトレーラーとして付加されます。
timeout_seconds	integer	いいえ	デフォルトは 600 です。review scout（`reviews` を指定したもの、または review フェーズの army ロール）は 1200 です。実際のセキュリティレビューでは 10 分間読み続けた後に打ち切られたためです。
verify_regression	boolean	いいえ	implement 専用：diff が `verification` に合格し、本番ファイルに触れている場合、その本番ファイルだけを一時的にリバートし、同じ検証プロファイルを再実行します（修正なしでは失敗する想定です）。その後、ファイルを復元します。再実行しても合格する場合、この回帰を検出できるテストがないことを示します。worker の報告にかかわらず結果は NEEDS_REVIEW に格下げされ、完了として黙ってコミットされることはありません。これは、誤った理由で検証プロファイルが合格するケースを検出する唯一の仕組みです（テスト選択フラグが変更ファイル自体のテストを誤って除外すると、実際に成功した正当なグリーン実行に見えますが、diff はテストされていません。終了コードの確認だけではこの違いを検出できません）。`verification` が設定されている場合、この抜け穴こそ nomArmy が信頼境界で塞ぐとする箇所であるため、デフォルトで有効です。`false` を明示すると、実行時間が倍増するコスト（数千のテストがあるリポジトリでは重要な場合があります）を省略できますが、そのリスクを受け入れることになります。`verification` プロファイルがない場合は効果がありません。再実行するものがないためです。scout では無視されます。
confirm_over_limit	boolean	いいえ	到達した使用量上限を上書きします。confirm_over_limit: true を指定して再送信する前に、General はオペレーターに確認する必要があります。または、別のエージェントにジョブを送ります。nomArmy がこの項目を自ら設定することはありません。

詳細

すべてのバイトを検証。 🍪

nomarmy.dev · ドキュメント · スポンサーになる

コーディングアシスタントが計画し、サンドボックス化されたワーカーが実装します。nomArmyが検証するまでは、何も完了したことにはなりません。

AI コーディングワーカーは自信満々です。「完了しました。すべてのテストに合格しました」というのは主張であり、証拠ではありません。nomArmyを使うと、コーディングアシスタント（Claude Code、Codex、Cursor）から「noms」と呼ばれるワーカーに作業を任せられます。そして、コミットする前に、実際の差分、新しいサンドボックスで実行したテスト、そのテストが変更を実際に検出できるかどうかのチェック、シークレットスキャンをすべて独自に検証します。

要点

用意するもの： Git、Node 24.16+（または26.1+）、Podman、Claude Code、Codex、またはCursorをインストールし、サインインしてください。macOSでは、Podmanに8 GiBを割り当ててください：brew install podman && podman machine init --memory 8192 && podman machine start。 Windowsでは、WSL2上のエンジンに対応しています。Windowsのセットアップに従ってください。
インストールしてセットアップする：
```
npm install -g nomarmy
cd your-project
nomarmy setup
```
nomarmy setupはプレイブックです。チェックリストを表示し、毎回「はい」と答えると次の手順を実行します：
```
✓ Where models run: hosted
✓ Installed: OpenClaw 2026.10.3
→ Agents: add a hosted agent
  Roles: add an agent first
  This repo: configure this project
  Check: verify the installation
Run `nomarmy agents add` now? [Y/n]
```
いつでも中断できます。nomarmy setupを実行すれば、前回の続きから再開できます。すべての手順を詳しく確認したいですか？ セットアップ例：Claude Code、Codex、APIキーでは、コマンドごとに説明しています。
使ってみる： プロジェクトでClaude Codeを再起動し、テストのある小さなバグを1つ修正するためにnomArmyを使うよう依頼してください。うまくいったら、/feature <what you want built>を試してください。

プラグインを使いたいですか？手順2の後、Claude Codeユーザーはnomarmy connectの代わりに/plugin marketplace add rayson-tech/nomarmyと/plugin install nomarmy@nomarmyを実行できます。Codexにも対応しています（プラグイン）。

問題が発生した場合は、nomarmy doctorでマシンをチェックし、nomarmy healthでnomArmyが実行するすべての項目をチェックできます。後でアップグレードする場合は、nomarmy updateを実行してください。

すべてのバイトが検証される仕組み

コーディングアシスタントのGeneralが、タスク、受け入れ基準、そしてそれを証明するテストを含むジョブを指示します。
nomArmyはブランチからgitワークツリーを作成し、ネットワークもホストの認証情報も使えないPodmanサンドボックスでnomを実行します。（例外が1つあります。Claudeのサブスクリプションについては、セキュリティ態勢をご覧ください。）
nomは編集とテストの実行を行い、STATUS、TESTS、NOT_DONE、NOTEの4行のレポートを最後に出します。
nomArmyはそのレポートを申告として扱い、証拠を独自に確認します。
- nomの説明ではなく、gitから実際の差分を読み取ります
- 新しいサンドボックスで検証プロファイルを実行します
- 本番コードの変更を元に戻してテストを再実行します。変更を戻してもテストが通るなら何も証明されていないため、コミットせずレビューに回します
- シークレットをブロックし、テストを通すために加えられた変更（新たなスキップ、スタブ化されたインポート）や、どこからも呼び出されないコードにフラグを立てます
その後に限り、nom自身のブランチにコミットします。あなたのブランチにはマージしません。レビューと統合は、Generalとあなたが引き続き担当します。

検証に失敗した場合は、例外なく失敗のままです。レポートの形式が不正でも、自動的に失敗になるわけではありません。リポジトリに変更があれば、nomArmyが独自に検証し、作業を復旧できる場合があります。また、検査を省略するかどうかはGeneralが決めることではありません。リポジトリの.nomarmy.ymlポリシー（新しいリポジトリではデフォルトで有効）により、すべてのジョブで検証と変更を戻すチェックが必須になります。

確認内容の表示。 /featureの実行が完了すると、Generalはプルリクエスト向けの「Verified by nomArmy」ブロックを受け取ります。そこには、「完了、テスト合格」という申告のうち何件が検証を通過したか、nomArmyが何件を検出し、その理由は何か、さらに変更を戻すと失敗する新しいテストが表示されます。nomarmy stats --shareを実行すると、任意の期間について同じ情報が表示され、nomarmy stats --badgeを実行すると、nomArmy | 78 claims checked · 11 caughtのようなREADMEバッジが書き込まれます。すべての数値は検証済みの記録に基づいています。

ビルドせずにチェックする場合は無料です。mode: verifyを指定すると、ワーカーもモデルのトークンも使わずに、任意のブランチに対して検証プロファイルを実行します。

さらに詳しくチェックしたい場合は？ 3つのオプションのバリデーターで、さらに踏み込んだチェックを行えます。いずれもレビュー用フラグを追加するだけです。ミューテーションテスト（テストによって変更行を特定できるか）、Jev（スカウトの引用が調査結果を裏付けているか、レポートが差分と一致しているか。TypeSafe、または自分のマシン上の互換サーバーで動作します）、モデルジャッジ（受け入れ基準、弱体化されたテスト）があります。

作業の実行場所

エージェントは、ジョブの実行場所を指定します。API キー、ご自身の Claude、ChatGPT、Muse Code、Grok のサブスクリプション（または別の OpenClaw プロバイダー）、あるいは llama.cpp 上のローカルモデルを選べます。
チームは、どのエージェントがどの役割を担うかを指定します。シニア開発者とジュニア開発者が構築し、セキュリティアナリストとデータアーキテクトがレビューし、PM が計画を確認し、PO が受け入れます。
**/feature**は、計画から構築、レビュー、受け入れまで、機能全体を一貫して実行し、マージできるブランチを用意します。
ハーネスを使うと、各リポジトリに適したサンドボックスを利用できます。Go、Rust、Python、Node（複数の言語が混在するリポジトリも対応）、Playwright によるブラウザテスト、モックログインサーバーのような偽サービスも、すべてオフラインで実行できます。ハーネスの追加でコアコードに手を加える必要はありません。

得られるのは、安くなる作業ではなく、信用を前提とせずに済む作業です。 委任にも、説明とレビューのためにジェネラルのトークンが必要です。原因がすでに特定されている小さなチケットでは、バグを直接修正する場合と比べて、ジェネラルのトークン消費量が4～8倍になることを測定しました。修正に必要なコンテキストが約150行になると損益分岐点に達します（測定結果）。大きなチケット、並行作業、そしてエージェントの言うことをそのまま信頼してしまいそうな作業では、導入効果があります。

GPU またはメモリに余裕のある Mac をお持ちですか？ nomarmy setupで「ローカルモデル」を選ぶと、トークンごとの料金がかからず、コードも外部に送られません。ただし、ハードウェア、電力、速度というコストがかかります。nomarmy sizingで、実行可能なモデルを確認できます。共有モデルサーバーも利用できます。

Rayson Technologies が開発・保守しています。これはベータ版（0.1.0-beta）です。設定はアップグレード後も引き継がれます（設定の互換性を参照）。

ドキュメント


インストール	あらゆるセットアップ方法：ホステッド（API キーとサブスクリプション）、macOS 上のローカルモデル、Linux、エンジンを WSL2 で実行する Windows、DGX Spark、共有モデルサーバー、Bedrock
セットアップ例	Claude Code、Codex、API キーを使った、コマンドごとの手順
エージェントとチーム	ジョブの実行場所、各担当の役割、使用制限、エージェントの選び方
`/feature`の実行	機能全体の実行と、nomArmy の動作の確認方法
リポジトリ	`.nomarmy.yml`、検証、依存関係、プライベートレジストリ、nomArmy によるチェック内容
バリデーター	オプションの追加チェック：ミューテーションテスト、Jev、モデルによる判定
ハーネス	エコシステムレジストリ、検出、ネットワークレベル、要件
設定	設定項目、ローカルモデルの切り替え、サイズの確認、アドミッション
リファレンス	すべての CLI コマンドと MCP ツール
セキュリティ方針	サンドボックスによって制限される内容と、唯一の例外
よくある質問	役割ごとに適したモデル、モデルの切り替え、使用制限
トラブルシューティング	症状と対処方法

セキュリティ

nom には、Podman サンドボックス内の書き込み可能な git worktree 以外、何も与えません。ネットワークも、ホストの認証情報も、Podman ソケットもありません。モデルへの呼び出しはすべてお使いのマシン上の OpenClaw が行い、サンドボックス内から呼び出すことはありません。検証では、ネットワークの段階を一段ずつ上げられます（プライベートネットワーク上の偽サービスから始め、テスト用テナント向けに承認した許可リストへ進みます）。ただし、nom が network none を離れることはありません。例外は Claude のサブスクリプションです。Claude のツールはお使いのマシン上で実行されるため、許可されない限り nomArmy は Claude でのビルドジョブを拒否します。nom に本番環境の認証情報、デプロイアクセス、SSH キーを渡さないでください。詳細はセキュリティ方針をご覧ください。脆弱性の報告はSECURITY.mdをご利用ください。

ステータス

機能	ステータス
検証の中核機能：worktree、nomArmy が管理する git、独立した検証、リバートチェック、失敗した worktree の保持	動作確認済み、エンドツーエンドテスト済み
`mode: verify`、シークレットスキャン（secretlint、厳格にブロック）、テスト回避策と未接続コードのチェック	ユニットテストおよび実環境でテスト済み。ヒューリスティクスはレビュー用のフラグです
Scout モードと decompose モード、`auto_union`	ユニットテストおよび実環境でテスト済み
エージェント：API キー	xAI で実環境で検証済み。他のプロバイダーは OpenClaw の文書化されたインターフェースに合わせて実装済み
エージェント：サブスクリプション	ChatGPT（Codex）と Muse Code はサンドボックス内で実環境検証済み。Claude も実環境で検証済みですが、そのツールはホスト上で実行されます（デフォルトでは Scout とレビューのみ）
ローカル（llama.cpp）および Bedrock プロファイル	動作確認済み
army と `/feature`	nomArmy 自体と自社製品で日常的に使用：2026年9月18日から10月10日までに783件のジョブを実施（測定結果）
ハーネス：Go、Rust、Python、Node、混在リポジトリ、Playwright、偽サービス	オフラインで実環境検証済み
プライベートレジストリと検証専用ネットワークの許可リスト	実環境で検証済み。それぞれ独立したセキュリティレビューに合格
バリデーター：ミューテーションテスト、Jev、モデルジャッジ	ユニットテストおよび実環境でテスト済み。Jev とジャッジは実際のジョブ記録で評価済み
`nomarmy stats`	実際のジョブ記録を使って手作業で作成したレポートと照合済み

委任が効果を発揮する場面とそうでない場面を含め、実際の実行から得られた知見はdocs/findings.mdにまとめています。

既知の制限事項

Claude のサブスクリプションはサンドボックス化されていません。 ツールはお使いのマシンで実行されるため、allow_host_tools: true を設定しない限り、これを使うジョブの実行は拒否されます。セキュリティ態勢をご覧ください。
独自の Compose サービスはまだ起動されません。 Compose ファイル内の実際のデータベースを必要とする検証プロファイル（environment: basic 以上）は、データベースなしで実行する代わりに not_run を報告します（また、Compose パーサーは YAML アンカーを解決しません）。モックログインサーバーなど、ハーネスによるフェイクサービスは実行されます。
プライベートレジストリは、Poetry と Yarn Berry にはまだ対応していません。 Poetry では、認証情報を使ったインストール時にパッケージのコードが実行されないことを保証できず、Yarn Berry は .npmrc を読み込みません。uv、pip のホイール、npm、pnpm、Yarn Classic、bun は利用できます。プライベートレジストリをご覧ください。
ベンダーが掲載していても利用を拒否するモデルは、テスト呼び出しを使ってディスパッチ時に検出されます。 エージェントで一度も動作したことのないモデルを使う最初のジョブでは、1 トークンのテスト呼び出しのため数秒待機します。拒否（ChatGPT プランでの gpt-6-sol など）はジョブのコストにならないよう報告され、記録されます。テスト呼び出しで結論が出ない場合（タイムアウト）は、ジョブを続行します。
Claude サブスクリプションのトークン数は、OpenClaw には最終的な応答しか見えないため、Claude CLI 独自のセッションログから取得します。合計にはキャッシュの読み取りと書き込みが含まれます。
テスト回避の検出はフラグであり、判定ではありません。 正当な新しいスキップもフラグが付けられます。
デプロイ時の失敗については、ご自身でチェックを用意する必要があります。 ユニットテストでは検出できない問題のチェックを追加するをご覧ください。
同一ホスト上のサンドボックス：MCP サーバー、OpenClaw、各ジョブのサンドボックスはすべて、コーディネーターと同じマシンで実行されます。モデルだけは別の場所に配置できます。

詳細

docs/findings.md：実際の実行から得られた知見。
docs/experiments：これらの知見の裏付けとなる、測定結果を含むレポート。
policies：スカウトとレビュー担当者の行動を監督する方法。
CONTRIBUTING.md、SECURITY.md、CODE_OF_CONDUCT.md。

設定変数は NOMARMY_* です。従来の RAYSON_* 変数は、読み込み時に一度だけ変換され、非推奨の警告が表示されます。

Apache 2.0 の下でライセンスされています。

Markdown 対応

ログインしてコメント

MCP は初めてですか？

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

入門ガイドを読む

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

nomArmy

nomArmy について

主な機能

活用シーン

MCP 対応

設定

ツール

詳細

要点

すべてのバイトが検証される仕組み

作業の実行場所

ドキュメント

セキュリティ

ステータス

既知の制限事項

詳細

コメント

MCP は初めてですか？

MCP（Model Context Protocol）とは？

MCP サーバーとクライアントの違いは？

ローカルとリモート、どちらを選ぶべき？

Claude や Cursor にサーバーを導入するには？

掲載プロジェクトは審査されていますか？「認証済み」とは？

自分のプロジェクトが掲載されています。どう申請できますか？