コードレビューの投稿に `confirmed: true` を追加してサブエージェントの誤コメントを防止

anthropics/claude-code

コードレビュースキルがインラインコメント投稿時に confirmed: true を明示的に渡すよう変更され、サブエージェントによる不要なプローブコメントが顧客のPRに投稿される問題に対処しました。

背景

サブエージェントが mcp__github_inline_comment__create_inline_comment ツールを継承し、GraphQL権限エラー後に「Test comment to see if I can create inline comments」のようなテスト・プローブコメントを顧客のPRに投稿してしまうという問題が繰り返し発生していました。プロンプトレベルのガードを設けても根本解決には至りませんでした。

CLIレベルの根本原因は、filterToolsForAgentmcp__* ツールをサブエージェントに無条件で継承させる実装にあります。サブエージェントはツールの動作確認のためにプローブ呼び出しを行う場合があり、それが意図せず顧客PRへの投稿につながっていました。

技術的な変更

今回の変更はコードレビュースキルの指示ファイル1行のみです。plugins/code-review/commands/code-review.md のステップ9において、インラインコメントツールの呼び出し方法を明示化しています。

変更前:

9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment`. For each comment:

変更後:

9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`. For each comment:

この変更は、コンパニオンPRである claude-code-action#1048 で実装された confirmed パラメータ の仕組みを活用します。confirmed パラメータの動作は以下の通りです:

  • confirmed: true → 即座に投稿
  • 省略した場合 → 本文が明白なプローブパターンにマッチしない限り投稿(マッチした場合はバッファリング)
  • confirmed: false → 常にバッファリング

コードレビュースキルが confirmed: true を渡すことで、最終レビューコメントは即座に投稿されます。一方、confirmed を省略してプローブを行うサブエージェントは、プローブパターンにマッチすれば無害にバッファされます。マッチしない場合は投稿されるリスクが残りますが、主要なプローブフレーズはキャッチされます。

設計判断

スキル側での明示的なオプトインという方式 が採用されました。MCPツール側でデフォルト動作を変更し、意図的な投稿には confirmed: true を必須とすることで、ツール呼び出し側が意図を明確に表明する設計になっています。

後方互換性も考慮されています。confirmed パラメータを持たない旧バージョンの claude-code-action に対しては、ZodがUnknownフィールドを除去するため、従来と同じ動作でコメントが投稿されます。さらに、claude-code-action@v1 タグ経由)とコードレビュースキル(プラグインマーケットプレイスからの実行時ロード)はいずれも自動更新されるため、既存の顧客はワークフローYAMLを再インストールすることなくこの修正を受け取れます。

まとめ

1行の変更で「スキルの意図した動作」と「サブエージェントのプローブ」を明確に区別できるようになりました。confirmed: true という明示的なフラグをプロトコルレベルで導入することで、プロンプトガードでは防ぎきれなかった誤投稿問題に対して、より堅牢な多層防御が実現されています。

記事メタデータ

Generated by:
Claude Sonnet 4.6 for DiffDaily
LLM Trace:
8d911263

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
リトライ後承認
Review Count:
2回 (改善を経て承認)
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ PASS

Title, Context, Technical Detailの存在と明確さ

「リード文→背景→技術的な変更→設計判断→まとめ」という総論→各論→結論の構成が明確に守られており、非常に分かりやすいです。

カスタムMarkdown構文 ⚠ WARNING

シンタックスハイライト・GitHubリンク記法の正確性

コードブロックのファイル名付きシンタックスハイライトは正しく使用されています。しかし、PR番号のリンク記法が `[PR #33472](URL)` となっており、ガイドラインの `[#123](URL)` 形式とは異なります。内容の理解には影響しませんが、形式的な不一致があります。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

「サブエージェント」「MCPツール」「Zod」といった用語が自然に使われており、専門知識を持つエンジニアという対象読者に完全に適合しています。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクション・各パラグラフが「総論→各論」の構成になっており、段落の先頭にトピックセンテンスが置かれているため、非常に読みやすいです。1段落1トピックの原則も守られています。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事内で引用されている `plugins/code-review/commands/code-review.md` の変更前後のコードは、提供されたDiff情報と完全に一致しています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

PR Descriptionで使われている `confirmed` パラメータ、`subagents`、`Zod` などの技術用語を正確に使用し、適切に解説しています。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

`confirmed` パラメータの3つの挙動や、後方互換性がZodによって担保される仕組みなど、技術的な説明はPR情報に基づいており、正確かつ論理的です。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

記事内のすべての主張(サブエージェントによる誤投稿問題、`confirmed` パラメータの導入、後方互換性の担保など)は、提供されたPRのDescriptionによって裏付けられています。ハルシネーションは見られません。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号(#33472)およびコンパニオンPRの番号(claude-code-action#1048)は、PR情報と一致しており正確です。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事のタイトルは、PRのタイトル「feat(code-review): pass confirmed=true when posting inline comments」の内容を、より分かりやすく要約しており、主題と完全に一致しています。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

PR情報に記載のない、バージョンサポート状況やリリース日程などの外部知識の追加はなく、提供された情報源に忠実です。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

PRの内容は現在進行中の問題とその修正策であり、記事内の時間表現もそれに準拠しています。時間表現の歪曲はありませんでした。なお、元のPR情報にある「Dec 2025」という未来の日付のタイポを記事に含めなかったのは適切な判断です。