Perforce 公式 MCP で Claude Code から操作して AI が扱える範囲と扱えない範囲を確認した

Perforce 公式 MCP で Claude Code から操作して AI が扱える範囲と扱えない範囲を確認した

Perforce 公式の MCP サーバーを Claude Code に接続し、照会と書き込みの両方を検証しました。変更履歴の照会や changelist の説明文の作成といったテキストまわりは AI に任せられますが、バイナリの中身は AI では扱えませんでした。
2026.07.18

はじめに

Git は Claude Code のような AI エージェントから自然に扱えるようになりました。差分の説明、コミットメッセージの生成、衝突の解消まで手伝ってくれます。一方で、ゲーム開発などで使われる Perforce について、同じような AI 連携の話はあまり聞きません。

そこで本記事では、Perforce が公式に提供する MCP サーバー p4mcp-server を Claude Code へ接続し、照会と書き込みの両方で、AI が扱える範囲と扱えない範囲を実機で切り分けます。先に結論を述べると、変更履歴の照会や changelist の説明文の作成といったテキストまわりは AI にうまく任せられた一方、バイナリの中身は AI では扱えませんでした。

本記事では、手元でそのまま再現できるよう、構築から接続までの手順も本文に示します。

Perforce とは

Perforce は、大容量のバイナリを多人数で扱う開発現場で広く使われる、中央集権型のバージョン管理システムです。ゲーム開発での採用が多く、ファイルを 1 人ずつ排他的に編集するロックと、必要なファイルだけを取得する部分同期が特徴です。サーバープロセスは p4d、クライアントは p4 と呼びます。

検証環境

  • macOS
  • Helix Core p4d 2025.2
  • p4mcp-server 3.3.1
  • Claude Code
  • uv および Python 3.14

対象読者

  • Perforce を運用していて、AI をどこまで活用できるか知りたい方
  • 大容量のバイナリを扱い、変更履歴やレビューの把握に手間を感じている方
  • MCP サーバーを実際の業務ツールへ接続してみたい方

参照

背景と問題提起

Perforce 運用では、この変更は誰が入れたのか、この changelist は何を意図しているのか、あるファイルが最近どう変わったのか、新しく入った人が過去の経緯をどう追うのかといったことを管理します。Git であれば Claude Code に尋ねれば済みますが、Perforce に同じ手段があるのかについてはこれまではっきりしませんでした。

背景には構造的な理由があります。Perforce の中核は、マージできない大容量バイナリの管理です。この領域は大規模言語モデル (LLM) が中身を読めないため、AI の恩恵が見えにくいのです。Git の中核であるテキスト差分が LLM の得意分野と重なるのとは対照的です。

ところが調べてみると、Perforce は公式に MCP サーバーを提供していました。 公式リポジトリでの最初のリリースは 2025 年 9 月で、位置づけは community supported です。本記事では、この MCP が実際に何を解決し、何を解決しないのかを切り分けます。変更履歴やレビューといったテキストまわりの調べ物を AI に任せられるのか、そしてバイナリ資産の管理そのものは AI で楽になるのかといった問いの答えを検証で確かめます。

検証方法

Perforce を手元に用意し、テキストとバイナリを含む変更履歴を作ったうえで、公式の p4mcp-server を Claude Code へ接続します。まず read-only で照会を試し、続いて書き込みも試します。

p4d の起動

Perforce の p4d と p4 は公式のダウンロードページから取得できます。

1-start-p4d.sh
mkdir -p p4root
p4d -r "$PWD/p4root" -p 1666 -L "$PWD/p4d.log" -J "$PWD/p4root/journal" -d
# 検証用に認証を無効化する。本番では設定しない
p4 -p 1666 configure set security=0

2 つのユーザーで変更履歴を作る

照会が意味を持つよう、tester_a と tester_b の 2 ユーザーで、テキスト・排他ロックのバイナリ・非排他ロックのバイナリを含む履歴を作ります。

2-sample-history.sh
2-sample-history.sh
export P4PORT=1666
# tester_a のワークスペースを作る
P4USER=tester_a P4CLIENT=ws_a p4 client -i <<EOF
Client: ws_a
Owner: tester_a
Root: $PWD/ws_a
View:
	//depot/... //ws_a/...
EOF
mkdir -p ws_a && cd ws_a
# CL1: テキストと排他ロックのバイナリ
printf 'baseline notes\n' > notes.txt
head -c 1048576 /dev/urandom > assetX.bin
p4 -u tester_a -c ws_a add -t text notes.txt
p4 -u tester_a -c ws_a add -t binary+l assetX.bin
p4 -u tester_a -c ws_a submit -d "baseline: notes.txt と assetX.bin"
# CL2: 非排他ロックのバイナリを追加
head -c 524288 /dev/urandom > assetW.bin
p4 -u tester_a -c ws_a add -t binary+w assetW.bin
p4 -u tester_a -c ws_a submit -d "add assetW.bin (binary+w)"
# CL3: tester_a が assetW を編集
p4 -u tester_a -c ws_a edit assetW.bin
head -c 524288 /dev/urandom > assetW.bin
p4 -u tester_a -c ws_a submit -d "A edits assetW"
cd ..
# tester_b のワークスペースを作り、assetW を編集する (CL4)
P4USER=tester_b P4CLIENT=ws_b p4 client -i <<EOF
Client: ws_b
Owner: tester_b
Root: $PWD/ws_b
View:
	//depot/... //ws_b/...
EOF
mkdir -p ws_b && cd ws_b
p4 -u tester_b -c ws_b sync
p4 -u tester_b -c ws_b edit assetW.bin
head -c 524288 /dev/urandom > assetW.bin
p4 -u tester_b -c ws_b submit -d "B edits assetW"
cd ..

公式 MCP サーバーを Claude Code に接続する

p4mcp-server は uvx で取得できます。本記事では照会と書き込みの両方を試すので、read-only と書き込み可能の 2 つを別名で接続しておきます。

3-mcp-connect.sh
# 照会用: read-only。書き込み系のツールは公開されない
claude mcp add p4lab \
  --env P4PORT=localhost:1666 --env P4USER=tester_a --env P4CLIENT=ws_a \
  -- uvx p4mcp-server --readonly

# 書き込み用: --readonly を付けない
claude mcp add p4lab-rw \
  --env P4PORT=localhost:1666 --env P4USER=tester_a --env P4CLIENT=ws_a \
  -- uvx p4mcp-server

接続後、Claude Code の /mcp で両方が connected になっていることを確認します。read-only の p4lab では照会用の 8 つのツールだけが公開され、書き込み系は現れません。書き込みの検証には p4lab-rw を使います。

検証結果

照会 (read-only)

まず、接続中のサーバー情報を尋ねると、サーバーの版数やアドレス、認証中のユーザーを表にまとめて返しました。

【プロンプト】
接続中の Perforce サーバーの情報を教えて

【回答 (一部抜粋)】
接続中の Perforce サーバー情報は以下のとおりです。

## サーバー
| 項目 | 値 |
|---|---|
| サーバーアドレス | `localhost:1666` |
| サーバーバージョン | P4D/MACOSX12ARM64/2025.2/2907753 (2026/03/09) |
| サービス種別 | standard |
| ライセンス | none (未設定) |

## 認証ユーザー
| 項目 | 値 |
|---|---|
| ユーザー | `tester_a` |
| 種別 | standard |
| 認証方式 | perforce |

ローカル (`localhost:1666`) で稼働している検証用の P4D サーバーです。

次に、変更履歴を新しい順に一覧して要約するよう頼みました。誰が何を変えたかを表と箇条書きでまとめ、ファイルタイプの違いまで読み取りました。

【プロンプト】
changelist を新しい順に一覧して。誰が何を変えたか要約して

【回答 (補足は省略)】
チェンジリストを新しい順に一覧します。全6件すべて `//depot` への submit 済みで、ユーザーは `tester_a` と `tester_b` の2名です。

## 新しい順チェンジリスト一覧
| CL | 日時 (JST) | ユーザー | 概要 |
|---|---|---|---|
| 6 | 07/18 20:30 | tester_a | branch1 へブランチ作成 (lazy copy) |
| 5 | 07/18 20:08 | tester_a | model.uasset を追加 |
| 4 | 07/18 20:05 | tester_b | assetW.bin を編集 |
| 3 | 07/18 20:05 | tester_a | assetW.bin を編集 |
| 2 | 07/18 20:04 | tester_a | assetW.bin を追加 |
| 1 | 07/18 20:02 | tester_a | ベースライン作成 |

## 誰が何を変えたか (詳細)
- CL4 — tester_b「B edits assetW」assetW.bin を編集 (rev.3)。type は binary+w (非排他)。CL3 の tester_a の編集に続けて、同じファイルを別ユーザーが更新できている。
- CL1 — tester_a「baseline: notes.txt (text), assetX/Y.bin (binary+l)」notes.txt (text)、assetX.bin・assetY.bin を排他ロック (binary+l) で追加。

出力は depot の履歴によって変わりますが、変更履歴の把握とファイルタイプの読み取りを自然言語で任せられることが分かります。テキストファイルの中身も問題なく読めます。notes.txt を尋ねると、そのまま表示されました。

【プロンプト】
//depot/notes.txt の中身を見せて

【回答】
`//depot/notes.txt` の中身です (rev.1、text、21 bytes)。

```
baseline notes
line2
```

CL1 のベースラインで追加されて以降、変更はありません (rev.1 のまま)。

ここまでは Git と遜色ない体験です。

一方、バイナリは扱いが異なりました。//depot/assetX.bin の中身を尋ねると、Claude は 1 MB のバイナリだと見抜き、そのまま出しても意味がないと判断しました。中身のダンプには進まず、種別・サイズ・digest といったメタデータを示し、変更履歴や別リビジョンとの diff、ローカルの実ファイルの確認など、どう見たいかを尋ね返しました。バイナリの内容をターミナルにダンプするのはトークンを大量消費し実用的でない、と自ら述べています。

【プロンプト】
//depot/assetX.bin の中身を見せて

【回答】
`//depot/assetX.bin` は **バイナリファイル**(type: `binary+l`、サイズ 1,048,576 バイト = 1MB)です。テキストではないため、中身をそのまま表示しても意味のある内容にはならず、ターミナルにも収まりません。

メタ情報は以下のとおりです。

| 項目 | 値 |
|------|-----|
| head Rev | #2 (CL2) |
| 種別 | binary+l(排他ロック付きバイナリ) |
| サイズ | 1,048,576 バイト (1MB) |
| digest | 05DE508D48FD6E6CB0D6236D77FC0BB4 |

このdigestは CL6 でブランチされた `//depot/branch1/assetX.bin` #1 と一致しており、branch1 はこの内容を lazy copy したものです。

なお、binary+l のバイナリ内容をターミナルに直接ダンプするのはトークンを大量消費し実用的でないため、そのままの表示は避けています。

念のため、中身の取得を強制するとどうなるかも確かめました。照会ツールの content をバイナリに直接実行すると、戻り値は 1,575,604 文字にまで膨張してトークンの上限を超え、Claude Code の文脈に載らず外部ファイルへ退避されます。バイナリの中身は、無理に AI へ渡しても意味のある情報にはならないのです。

書き込み

まず、AI に changelist の説明文を書かせて起票してみます。Git のコミットメッセージ生成に相当する使い方です。

【プロンプト】
説明文を『notes.txt のベースラインメモを更新』とした pending changelist を作成してください

【回答】
pending changelist を作成しました。

| 項目 | 値 |
|------|-----|
| Changelist | 9 |
| ステータス | pending |
| 説明 | notes.txt のベースラインメモを更新 |
| ユーザー / クライアント | tester_a / ws_a |

現時点ではファイルは未追加 (空の pending) です。

作成は問題なく成立しました。説明文はテキストなので、書き込みでも AI の得意領域です。

次に、ファイルを編集用に開いてみます。p4 edit に相当する操作です。

【プロンプト】
//depot/notes.txt を編集用に開いてください

【回答】
`//depot/notes.txt` を編集用に開きました。

| 項目 | 値 |
|------|-----|
| Changelist | 9 (pending) |
| depot ファイル | `//depot/notes.txt` |
| 対象リビジョン | #1 → 編集中 |
| action | edit |
| 種別 | text+D |

ローカルの notes.txt が書き込み可能になり、CL9 に載りました。

編集用に開けました。ファイルは、先ほど作成した CL9 に載りました。

続けて、この編集を新しい changelist に入れて shelve (=退避) してみます。

【プロンプト】
編集用に開いている //depot/notes.txt を、新しい pending changelist に入れて shelve してください

【回答】
完了しました。

## 実施内容
| ステップ | 結果 |
|---------|------|
| 新規 pending changelist 作成 | CL10 (説明: 「notes.txt の編集を shelve するための changelist」) |
| ファイル移動 | `//depot/notes.txt` を CL9 → CL10 へ移動 |
| shelve | CL10 の `//depot/notes.txt` #1 (edit) を shelve 済み |

## 現在の状態
- CL10 (pending): `//depot/notes.txt` が編集用にオープン、かつ shelve 済み。
- CL9 (pending): ファイルがなくなり、空の状態になりました。

changelist の作成・ファイルの移動・shelve までを、自然言語のひと言で通せました。ここまではいずれも非破壊の操作なので、すんなり実行されます。

次に、破壊的な操作として、作成した changelist の削除を頼みます。Claude は shelve やオープン中のファイルまで片付けたうえで、削除まで進めてくれました。

【プロンプト】
作成した changelist を削除してください

【回答 (一部抜粋)】
両方 (CL9・CL10) を削除します。CL10 の shelve 削除 → ファイル revert → changelist 削除の順で進めます。

## 実施内容
| ステップ | 結果 |
|---|---|
| CL10 の shelve 削除 | `//depot/notes.txt` の shelve を削除 |
| ファイル revert | `//depot/notes.txt` を revert (未変更のため影響なし) |
| CL10 削除 | Change 10 deleted |
| CL9 削除 | Change 9 deleted |

開いているファイル・pending changelist は残っていません。クリーンな状態に戻りました。

ただし、この削除はそのまま実行されたわけではありません。shelve や changelist の削除のような破壊的な操作では、MCP サーバーが確認を求め、Claude Code にダイアログが表示されます。

これは元に戻せない操作への確認です。PROCEED を選んで承認しない限り、削除は実行されません。AI に書き込みを任せても、破壊的な操作には必ず人の承認が挟まります。

考察

この結果は、AI が扱える範囲の境界をよく表しています。

バイナリの中身は、そのまま AI に渡しても意味のある情報にはなりません。1 バイトごとにエスケープされた文字列が延々と続くだけで、無理に取得すればトークンの上限すら超えます。だからこそ、能力のある AI は中身のダンプを避け、メタデータや digest で判断します。実際に Claude は、digest を使って元ファイルとブランチ先が同一内容であることを照合してみせました。

一方、テキストは読み取りだけでなく書き込みでも AI の得意領域でした。changelist の説明文の作成は自然言語で任せられ、削除のような破壊的な操作には確認が入ります。

つまり MCP が扱えるのは、変更履歴の把握や changelist の要約・作成といった、テキストまわりの仕事です。冒頭に挙げた読者の悩みは、この範囲に収まります。一方、Perforce の主目的である大容量バイナリの管理そのものは、AI では楽になりません。扱える範囲と扱えない範囲の境界は、そのまま Perforce のテキストとバイナリの境界に重なります。

まとめ

Perforce は公式 MCP を通して AI から操作でき、変更履歴の照会から changelist の説明文の作成まで、テキストまわりは自然言語で任せられます。削除のような破壊的な操作には確認が入ります。ただしバイナリの中身は AI に渡せず、扱える範囲はテキストとメタデータに限られます。本記事が、Perforce と AI を組み合わせる判断材料になれば幸いです。


Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

この記事をシェアする

AI白書

関連記事