この記事でやること
- Claudeのチャットに渡っているGitNest用ツールを、curlとjqで一覧にして確かめる
- 「Needs your approval」に並んだカードを、種類ごとにどこを見てから承認するか整理する
- 承認しても実行されなかったときに、何が起きたのかを読み分ける
接続の作り方やリポジトリをプロジェクトに入れる手順は済んでいる前提です。ここで扱うのは、提案が届いてから承認するまでの部分です。
前提・環境
- ClaudeのチャットがosFoundryのコネクタにつながり、接続が「Connected.」になっている
- 対象のGitNestリポジトリが、接続の入っているプロジェクトに属している
- 手元に
curlとjqがある - 記事中のリポジトリ名、ID、コミットは表示例
Claudeから見えているツールを確認する
osFoundryのMCPエンドポイントの tools/list は、認証なしで叩けます。GitNest関連だけを抜き出して、読み取り専用かどうかと必須の引数を並べます。
curl -s -X POST https://api.osfoundry.io/api/v1/external-mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
| jq -r '.result.tools[]
| select(.name | test("gitnest"))
| [.name, (.annotations.readOnlyHint | tostring), (.inputSchema.required | join(","))]
| @tsv'
2026-11-06に叩いた結果です。
read_gitnest_repository true repository_id
search_gitnest_code true repository_id,query
list_gitnest_work true repository_id,kind
read_gitnest_work true repository_id,kind,item_id
list_gitnest_saved_results true repository_id
propose_gitnest_work false repository_id,title,idempotency_key
propose_gitnest_change_set false repository_id,title,items,idempotency_key
propose_gitnest_server_composition false repository_id,change_set_id,expected_change_set_version,idempotency_key
propose_gitnest_file_import false repository_id,branch,message,files,idempotency_key
propose_gitnest_check_rerun false repository_id,change_set_id,check_name,expected_change_set_version,expected_composition_oid,idempotency_key
list_gitnest_checks true repository_id,change_set_id
propose_gitnest_native_publication false repository_id,change_set_id,expected_change_set_version,expected_composition_oid,idempotency_key
propose_gitnest_provider_publication false repository_id,change_set_id,expected_change_set_version,expected_composition_oid,idempotency_key
ここで確認しておきたいのは次の3点です。
- 書き込み系はすべて
propose_で始まる。リポジトリへ直接コミットやpushをするツールは一覧にない -
propose_の7個はどれもidempotency_keyが必須 - チェンジセットを対象にするものほど、
expected_change_set_versionやexpected_composition_oidを必須に持つ
スコープと openWorldHint も同じやり方で見られます。jqの部分だけ差し替えます。
... | jq -r '.result.tools[]
| select(.name | test("gitnest"))
| [.name, (.annotations.openWorldHint | tostring), (.securitySchemes[0].scopes | join(","))]
| @tsv'
読み取りの6個は osfoundry:read、propose_ の7個は osfoundry:write でした。openWorldHint が true なのは propose_gitnest_native_publication と propose_gitnest_provider_publication の2つだけです。この2つは、承認されるとプルリクエストという形で提案の外に結果が残ります。publicationのカードをほかより丁寧に見る理由は、ここにもあります。
1つのツールの中身まで見たいときは、名前で絞って全体を出します。ファイルのコミットを例にします。
... | jq '.result.tools[]
| select(.name == "propose_gitnest_file_import")
| {description,
files: .inputSchema.properties.files | {minItems, maxItems},
idempotency_key: .inputSchema.properties.idempotency_key}'
{
"description": "Prepare up to 20 UTF-8 files (200 KB total) for a native GitNest repository branch. The owner reviews every file and approves the commit in osFoundry. Repository GitNest must be enabled.",
"files": { "minItems": 1, "maxItems": 20 },
"idempotency_key": { "type": "string", "minLength": 8, "maxLength": 128 }
}
説明文の動詞は「Prepare」で、コミットを承認するのはオーナーだと書いてあります。idempotency_key は8文字以上が必要です。カードに並ぶファイルが最大20個に収まっているのは、ここで決まっているからです。
この一覧はサーバー全体のものです。実際にClaudeが呼べるのは、このうち接続のToolsでオンになっているものだけです。鍵アイコン → Connected で接続を選び、Toolsのチェックリストと見比べます。リストでは、ツール名のアンダースコアがスペースになって並んでいます。
頼むときに一言添えておくこと
カードを読みやすくするには、頼む段階でClaudeに順番を指定しておくのが手っ取り早いです。そのまま貼れる形にしておきます。
osFoundryのdemo-apiで作業して。
1. 先に read_gitnest_repository でデフォルトブランチを確認する
2. 既存のコードは search_gitnest_code で必要な箇所だけ探す
3. 変更は propose_ のツールで提案だけ出す。何をどのブランチに出したかを最後に一覧にする
4. チェンジセットを対象にするときは、直前に list_gitnest_work と list_gitnest_checks で
バージョンと合成コミットを読み、その値で提案する
3つ目の一覧があると、チャットの返事と「Needs your approval」のカードを1対1で突き合わせられます。4つ目は、カードに載るバージョンとコミットを、Claudeが読んだばかりの値にするためです。古い値で出された提案は、承認の時点で照合に通りません。
search_gitnest_code の説明には「Binary files and full file contents are excluded.」とあり、返るのは上限付きの行の抜粋です。新しいファイルを足すだけなら抜粋で足りますが、既存ファイルの書き換えを頼むなら、いまの中身をチャットに貼っておきます。
カードの種類ごとに見るところ
提案が届くと、ヘッダーに通知が出て、接続のパネルの「Needs your approval」にカードが並びます。Claudeが「用意しました」と言った時点では、まだ何も書き込まれていません。
表示例:「Needs your approval」に届いたGitNestの公開提案
ファイルのコミット(Commit GitNest files)
- 「Commit to branch」のブランチ名が意図どおりか
- 折りたたまれた「Review all proposed files」を開いて、全ファイルの中身を読んだか
- ファイル数と容量は最大20個、合計200KBまで。UTF-8のテキストだけ
既存ファイルの書き換えなら、とくに丁寧に見ます。カードに並ぶのは提案されたファイルの全文なので、元の内容から消えた行がないかを読み比べます。
タスク(Create GitNest work)
タイトルと優先度を見ます。承認するとTodoとGitNestのワークアイテムができるだけで、コードには触れません。
チェンジセットの作成・合成(Create GitNest draft change set / Compose GitNest change set)
作成は保存済みの実行結果からドラフトを作るだけで、合成も公開もしません。合成のカードには「Change set: … · expected version N」が出ます。いまGitNestで見えているバージョンと同じかを、「Review change set before approving」のリンクから確かめます。
チェックの再実行(Retry GitNest check)
対象のチェック名と「Reviewed commit」を見ます。再キューされるのは、そのバージョンとコミットに対する終了済みのチェック1つだけです。
プルリクエスト(Publish GitNest pull request / Open a draft GitHub or GitLab pull request)
- バージョンとコミットが、レビューしたものと一致しているか
- カードに添えられた「承認すると何が起きるか」の1行を読んだか
ネイティブ版は公開用ブランチを作ってGitNest内でPRを開きます。プロバイダ版は、osFoundryで連携した自分のアカウントで、そのチェンジセット専用のブランチだけをpushしてドラフトPRを開きます。どちらもマージはしません。
承認したのに実行されなかったとき
承認の時点で、osFoundryは条件をもう一度確かめます。条件を満たさない提案は実行されず、それは意図した動きです。原因はだいたい次のどれかです。
| 状況 | 何が起きているか | やること |
|---|---|---|
| 提案を出したあとでチェンジセットが合成し直された | カードのバージョンやコミットが最新ではない | Claudeに読み直させて、新しいバージョンで提案を出し直してもらう |
| カードに出ていた期限を過ぎた | 提案が期限切れになっている | 同じ依頼をもう一度Claudeに頼む |
| リポジトリが接続のプロジェクトから外れた | 接続から対象が見えなくなっている | リポジトリのProjectセクションで所属を確認する |
| 自分のリポジトリ権限が変わった | 承認できるのは権限を持っている間だけ | GitNest側の権限を確認する |
| publicationで必須チェックが通っていない | リスクポリシー・必須チェック・ターゲットブランチの確認で止まる | チェックの状態を list_gitnest_checks で見てから出し直す |
古くなった提案を通さないのは、自分がレビューしたバージョンとコミットを承認するためです。クリックした時点の最新版を、見ないまま承認することにはなりません。
よくある疑問
同じ依頼のカードが2枚並ぶことはありますか
propose_ のツールはどれも idempotency_key を取ります。返事が途切れてClaudeが同じ呼び出しを繰り返しても、2件目の依頼にはなりません。
Claudeにプルリクエストの準備まではさせたくありません
接続のToolsで propose gitnest native publication と propose gitnest provider publication のチェックを外し、Save toolsを押します。外したツールはClaudeが提案すること自体ができなくなります。残したツールの提案にも、これまでどおり承認が要ります。
Claude Codeから使うとツール名はどう見えますか
同じサーバーを osfoundry という名前で追加していれば、mcp__osfoundry__propose_gitnest_file_import のように見えます。カードの内容と承認の流れはチャットの場合と同じです。
GitHubやGitLabのトークンはClaudeに渡りますか
渡りません。プロバイダのPRは、承認した時点でosFoundryに連携済みのアカウントを使います。pushされるのはそのチェンジセットのブランチだけです。
デプロイまで進むことはありますか
提案が行き着く先は、最大でもプルリクエストです。マージと、それをきっかけに動くものは、GitNestかプロバイダ側で自分が決めます。
まとめ
-
tools/listをjqで見れば、Claudeの書き込みがすべてpropose_経由になっていることを手元で確かめられる - 承認前に見るのは、ブランチ、ファイルの全文、チェンジセットのバージョンとコミット
- 実行されなかった提案は、読み直して出し直せばよい
GitNest側のclone・push・アクセストークンの扱いはGitNestの機能ページにまとまっています。コネクタは素のMCPなので、ほかのMCPクライアントからも同じ一覧が見えます。
