AIコーディングツールのガバナンス設定、今週確認する3つの軸

「Claude CodeとCursor、両方使わせているけど、権限設定は誰が見ているんだっけ」。複数のAIコーディングツールを併用するチームで、こういう会話を耳にすることが増えました。ツールを1つに絞れていた時期は、設定もレビューも1か所で完結していました。ところが今は、エンジニアが好みでツールを使い分ける現場が普通になっています。

この2か月で、その状況に対する業界側の答えが立て続けに出ました。ServiceNowは2026年5月、複数のAIコーディングツールをまたいで統治する仕組みを発表しました。GitHubも6月に、外部製コーディングエージェントへのセキュリティ検証と、権限をすり抜ける設定への歯止めを相次いで追加しています。どちらも「使うのを止める」方向ではなく、使わせたまま管理下に置く方向の対応です。

僕はAIエージェントの動向を追う立場として、この2つの発表を個別のニュースとして流すつもりはありません。複数ツールを実際に運用しているチームがどう活かせるかという視点で整理してみます。今日から使える判断軸と、5項目のチェックリストまで落とし込みます。

AIコーディングツールのガバナンス強化が、この2か月で一気に進んだ理由

まず、何が起きたのかを一覧で押さえておきます。2026年5月、ServiceNowはKnowledge 2026という自社イベントを開きました。そこで、開発支援エージェント「Build Agent」をServiceNow Studio上で一般提供にすると発表しています。同時に、CursorやWindsurf、Claude Code、GitHub Copilotといった主要な外部AIコーディングツールも対象に加えました。これらのツールの内部からも、Build Agentの中核機能を呼び出せるように拡張しています。ServiceNow公式のプレスリリースでは、これを「governed by default」、つまり標準で統治された状態と表現しました。ツールをどれだけ増やしても、デプロイの承認や公開管理、アプリケーションのライフサイクル管理といった統治の仕組みが自動的に付いてくるという意味です。

あわせて、App Engine Management Center(AEMC、アプリの開発・公開状況を一元管理する管理画面)も動きがありました。これまで別料金だったこの機能を、追加費用なしで全顧客に開放しています。アプリ5個・管理対象の開発者15人までという上限つきですが、契約の相談をする前に統治された開発の効果を試せる設計です。

GitHubの動きも見逃せません。6月9日には、ClaudeやOpenAI Codexなど外部製のコーディングエージェントが書いたコードへのセキュリティ検証を一般提供にしています。CodeQLによる静的解析・依存関係分析・シークレットスキャンを標準で適用する内容です。GitHub Advanced Securityのライセンスがなくても使える点がポイントです。これまでGitHub Copilotのクラウドエージェントだけに提供していた検証を、他社製ツールにも広げた形になります。

ただし対象は限定的です。検証が自動で走るのは、GitHubのリポジトリ内で直接動作するエージェントの変更に限られます。IssueやPRの対応をエージェントに任せる「third-party coding agents」という連携の仕組み経由の場合が対象です。この連携自体はGitHub Docs上ではまだpublic preview(一般提供前の先行公開)段階です。開発者が手元のCLIやIDE拡張としてClaude CodeやCursorを使い、自分でコミットしてPRを作る普段の使い方があります。その使い方全般に、この検証が自動でかかるわけではありません。

さらに6月17日には、エンタープライズ管理設定に初めてのガバナンス機能を追加しました。GitHub Copilot CLIやVS Codeには、権限確認を自動でスキップしてしまう自動承認モードがあります。管理者が設定ファイルで指定すれば、この機能を組織全体で無効化できるようになりました。個々の開発者が便利さを優先して確認を飛ばす設定にしていても、管理者側で強制的に止められる仕組みです。

背景にあるのは、AIコーディングツールの導入自体は進んだ一方で、それを管理する仕組みが追いついていないという構造的なズレです。エンジニア個人が業務に合わせて好みのツールを使い始める状態は、もう珍しくありません。裁量に任せたままだと、誰がどのツールにどこまでの権限を与えているのか、管理者側が把握できなくなります。今回の2社の動きは、この管理の空白を埋めるタイミングが来たという業界側のシグナルだと僕は見ています。

ServiceNowとGitHub、狙っている場所は違います。ServiceNowが統治するのは、ServiceNowプラットフォーム上でのアプリ開発というレイヤーです。GitHubが統治するのは、GitHub上でのコード変更の検証というレイヤーです。同じ「AIコーディングツールのガバナンス」という言葉でくくれますが、扱っている対象そのものは別物だと理解しておく必要があります。共通しているのは、複数のAIコーディングツールが1つの開発現場に同居することを前提にした設計だという点です。1つのツールだけを想定した権限管理は、もう現実に追いついていません。

複数ツールを使うチームが、最初に決めるべき3つの判断軸

発表の中身を並べただけでは、自社の何を変えればいいのかは見えてきません。ここからは、実際に手を動かす際の判断軸を3つに絞ります。

1つ目は、チームが使っているAIコーディングツールの数です。Claude Codeだけ、あるいはCursorだけという単一ツール運用なら、そのツールの公式ドキュメントに沿った権限設定を1回見直せば済みます。ですが2つ以上を併用している場合、ツールごとに権限の粒度も確認方法も違うため、横断で見える管理画面や設定の有無が急に重要になります。今回のServiceNowの発表は、まさにこの複数ツール前提のチームに向けたものです。この境界線をどこに引くかは、以前AIエージェント運用、中小企業が権限設計で分ける3つの境界線でも整理しました。

たとえば、5人のエンジニアがそれぞれの好みでClaude Code、Cursor、GitHub Copilotを使い分けているチームを想像してください。1人がリポジトリの管理者を兼ねている場合、3種類のツールの権限設定をすべて自分の目で把握するのは現実的ではありません。ツールの種類が増えるほど、誰も見ていない設定が生まれる確率は上がっていきます。

2つ目は、権限確認を自動でスキップする設定を許可しているかどうかです。個人の検証環境で使う分には作業が速くなる便利な設定です。ですが組織のリポジトリに対して有効にしたままだと、意図しないコマンド実行や機密ファイルへのアクセスを止める手段がなくなります。GitHubが6月に追加した無効化設定は、この状態を放置している組織への対応そのものです。自社のチームでこの設定を確認したことがない場合、それ自体が優先度の高い課題だといえます。

3つ目は、外部製のAIエージェントが書いたコードに、社内製のコードと同じ検証が通っているかどうかです。ここでいう「外部製エージェント」とは、GitHubのリポジトリに接続してIssueやPRを直接担当する連携形態を指します。GitHubのセキュリティ検証は、Copilotのクラウドエージェントには最初から適用されていました。一方でClaude CodeやCodexをこの連携形態で使う場合、これまで検証の対象から漏れやすい状態だったのです。人間が書いたコードにはレビュープロセスがあっても、AIエージェントが生成したプルリクエストは動いたから良しで通ってしまう現場も少なくありません。なお、開発者が手元でClaude Codeを対話的に使い、人間が最終的にPRを作る通常の使い方は、この検証の対象には直接含まれない点に注意してください。

この3つの軸に自社を当てはめてみると、優先して手を付けるべき場所が自然と絞られます。ツール数が多く、自動承認モードの有無も把握できておらず、外部製エージェントのコードに検証が通っていない。この3つが重なっている組織ほど、次に紹介する設定を急いで確認する価値があります。

ServiceNowとGitHubが打った布石、学習コストを上げずに縛る設計

2つの発表に共通するもう1つの特徴は、開発者に新しい作業を増やさない設計になっている点です。

ServiceNowのBuild Agentは、開発者がCursorやClaude Codeといった使い慣れたツールの中で作業を続けられます。その裏側で、ServiceNowのプラットフォームの文脈と統治の仕組みが働く構成です。ツールを乗り換えたり、別の管理画面にログインし直したりする必要がありません。生成されたコードは、公開前に品質ゲートと照らし合わせて検証する自己修復型のテストの仕組みを通ります。人がレビューする前段階で、明らかな不具合をエージェント自身が検知して直す設計です。AEMCのフリーミアム提供も、既存の開発フローを止めずに、まず5個のアプリで統治の効果を確かめられるようにする狙いだと考えられます。

GitHubのセキュリティ検証も同じ思想です。開発者が何か新しい操作を覚える必要はありません。外部製エージェントが作ったプルリクエストに対して、CodeQLと依存関係分析、シークレットスキャンが自動で走るだけです。GitHub Advanced Securityの契約がなくても使える点は、中小規模のチームにとって特に価値があります。セキュリティ機能を使うために追加のライセンス交渉をする必要がなくなったからです。導入企業がClaude Codeをどう組織展開しているかは、Claude Code導入事例、みずほFGが40人で25本を並行開発でも紹介しました。

専任のセキュリティ担当者を置けない小規模なチームにとって、この設計は特にありがたいものです。誰かが常時レビューする体制を組まなくても、生成されたコードの水準を一定に保てる仕組みが、標準機能として最初から用意されているからです。人手を増やさずに検証の網だけを広げられる点は、リソースの限られたチームほど恩恵が大きいと感じています。

一方で、権限バイパスの無効化設定だけは、開発者ではなく管理者側が動かないと効果が出ません。設定ファイルに1行を追加するだけの作業ですが、その1行の存在を知らなければ、いつまでも自動承認モードが野放しになります。GitHub Docsの案内によれば、Agentsページ・AI controls欄で現在の設定状況を確認できます。まずは自社の設定が有効になっているかを見に行くところから始めてください。

今週中に確認する5つのガバナンスチェックリスト

ここまでの内容を、今週中に確認できる5項目に落とし込みます。

1つ目は、チームで使っているAIコーディングツールを全て書き出すことです。個人の裁量で導入したツールも含めて、社内で名前が挙がっていないツールがないかを確認します。棚卸しをしていないチームほど、実際に稼働しているツールの数が想定より多いものです。

2つ目は、GitHub Copilot CLIやVS Codeで自動承認モードが有効になっていないかを確認することです。AgentsページのAIコントロール欄で状況を見られます。有効になっている場合は、管理者権限でdisableBypassPermissionsModeを無効に設定し、組織全体に反映させます。設定は.github-privateリポジトリ内のcopilot/managed-settings.jsonで管理します。Copilot側が1時間ごとに再取得する仕組みのため、反映まで最大1時間程度かかる点も覚えておいてください。

3つ目は、Claude CodeやCodexをGitHub連携型(third-party coding agent)として使っているケースの確認です。Issue・PRを直接担当させている場合は、そのプルリクエストにセキュリティ検証が実際に適用されているかを直近の履歴で確認します。検証結果のバッジが表示されていない場合、設定が有効になっていない可能性があります。開発者が手元でClaude Codeを対話的に使い、人間がPRを作る通常の運用には、この検証は自動でかからない点も併せてチームに共有してください。

4つ目は、ServiceNow上でアプリを開発しているチームがあれば、AEMCのフリーミアム枠でデプロイ承認とリリース管理の仕組みを実際に動かしてみることです。5個のアプリという上限があるので、まずは重要度の高いアプリから試すのが現実的です。

5つ目は、ここまでの4項目を月1回のペースで見直すサイクルを決めることです。ガバナンスの設定は一度直して終わりではありません。新しいツールが増えるたびに、抜け穴も一緒に増えていきます。

チェックリストを運用する前に、陥りやすい2つの誤解

チェックリストを作った後、よくつまずくポイントが2つあります。

1つ目は、ガバナンスを強化すると開発が遅くなるという思い込みです。今回紹介した仕組みは、いずれも既存の作業フローに割り込む形ではなく、裏側で動く検証として設計されています。実際に速度が落ちるのは、検証を導入していないせいで問題が本番環境で発覚し、その対応に追われる場面です。手前で止める仕組みがある方が、トータルの手戻りは少なくなります。

2つ目は、設定を1回済ませれば安心だという油断です。GitHubの権限バイパス無効化も、ServiceNowのAEMCも、新しいツールやメンバーが加わるたびに再確認が必要な性質のものです。特に個人の裁量でツールを試す文化があるチームほど、棚卸しの間隔を空けすぎると、気づかないうちに未検証のツールが業務に食い込んでいることがあります。月1回の見直しサイクルを、カレンダーに先に入れてしまうくらいの運用が、結局は一番手堅いやり方だと感じています。

3つ目は、こうしたガバナンス機能を使うには追加コストがかかるという誤解です。GitHubのセキュリティ検証はAdvanced Securityの契約なしで使え、ServiceNowのAEMCも一定の上限までは無償で開放されています。まずは無償の範囲で自社の運用に合うかを確かめてから、必要に応じて契約を検討するという順番で十分間に合います。予算を確保してから動こうとして、その間に設定を放置してしまう方が、実際にはリスクが大きいと僕は考えています。

まとめ

複数のAIコーディングツールを併用する現場が当たり前になりました。この状況を受けて、ServiceNowとGitHubがそれぞれ2026年5月から6月にかけてガバナンス機能を強化しています。

• ServiceNow:Build Agentが主要AIコーディングツール内部からも呼び出せるように(2026年5月)。AEMCも全顧客に無償開放
• GitHub:外部製エージェントのコードにCodeQL・依存関係分析・シークレットスキャンを標準適用するセキュリティ検証がGA(2026年6月9日)
• GitHub:自動承認モードを組織側で強制無効化できる設定を追加(2026年6月17日)
• 判断軸:使用ツールの数、自動承認モードの有無、外部製エージェントへの検証適用状況の3つで自社の優先度を絞る
• 今週の1手:ツールの棚卸し、自動承認モードの確認、検証適用状況の確認、AEMCフリーミアムの試用、月1回の見直しサイクル設定

複数のツールを使い分けること自体は、悪いことではありません。むしろ、それぞれの現場に合ったツールを選べている証拠です。大事なのは、その状態を前提にした管理の仕組みを、後回しにしないことです。今週、まずはチームで使っているツールを書き出すところから始めてみてください。