AIに仕事を渡す前に、今日見直したい4つの設定──「便利」から「管理できる」へ戻す
AIエージェントは、チャットの返答だけでなく、コードレビュー、外部ツール参照、アプリ操作、社内の利用状況レポートまで触り始めています。今週の更新を見ると、論点は「何ができるか」よりも、誰が使えるか、何を読めるか、どこまで動けるか、あとから測れるかに移っています。
金曜は、新機能を足す日ではなく、来週に事故を持ち越さないための点検日です。今日は、GitHub Copilotまわりの直近更新と、LinkedIn・OpenAIの公開情報を材料に、チームでAIに作業を渡す前の4つの設定を整理します。
1. 新しいモデルを「自動で有効」にしてよいか
GitHubは7月29日、Copilot Business / Enterprise向けに、一般提供されたCopilotモデルをデフォルトで有効にする新しいポリシーを発表しました。今後28日間は設定だけ可能で、実際に効き始めるのは8月26日です。
ポイントは、放っておくと「未設定」のモデルが「デフォルトを継承」に移り、ポリシーが有効ならユーザーに開放されることです。一方で、明示的に有効・無効にしたモデルは維持されます。また、DeepSeekやKimi K2.7のようなオープンウェイトモデル、GitHubのデータ保持契約の対象外モデルは、デフォルト有効化の対象外とされています。
今日見る設定
社内で「新モデルは原則オン」なのか「承認してからオン」なのかを決める
8月26日までに、組織・Enterpriseのモデル設定を一度開く
セキュリティレビューが必要な業務では、モデルごとに明示的な有効・無効を付ける
2. Copilotアプリを、誰に開けてよいか
GitHubは7月27日、Copilotアプリに専用ポリシーを追加しました。これまではCopilot CLIのポリシーに連動していたアクセスを、アプリとCLIで別々に管理できるようにしたものです。初期状態は「Enabled everywhere」とされ、管理者は「全体で有効」「全体で無効」「組織管理者に任せる」から選べます。
アプリ側では、開発者が分離されたワークスペースでエージェントセッションを動かし、変更はPull Requestとして出す設計だと説明されています。これは安全側の設計ですが、「使える人が増える」ことと「レビューの責任が消える」ことは別です。
出典: https://github.blog/changelog/2026-07-27-manage-github-copilot-app-access-with-a-dedicated-policy/
今日見る設定
Copilotアプリを全員に開けるか、対象チームから始めるかを決める
CLI、VS Code、Copilotアプリのポリシーが食い違っていないか確認する
PRレビュー、CI、監査ログを通らない変更ルートが残っていないかを見る
3. MCP・スキルで読ませる情報を、読み取り専用に寄せる
GitHubは7月29日、Copilot code reviewのAgent skillsとMCPサーバー対応を一般提供にしました。対象はCopilot Pro、Pro+、Business、Enterpriseです。MCP接続は、Issue管理、ドキュメント、サービスカタログ、インシデント管理など、チームが普段使う外部コンテキストをレビューに持ち込める仕組みです。
重要なのは、GitHubがこの更新で「Copilot code reviewによるMCP tool callは読み取り専用に制限される」と説明している点です。さらに、既存のCopilot cloud agent向けMCP設定はCode reviewにも適用され、GitHubとPlaywright MCPはデフォルトで有効になるとされています。
今日見る設定
MCPに渡すトークンを「読むだけ」にできているか確認する
SKILL.md に社内ルールを書きすぎず、レビューで本当に必要な基準に絞る
GitHub / Playwright MCPがデフォルトで有効になる前提で、外部コンテキストの範囲を棚卸しする
4. 使った量を、人・アプリ・モデル単位で見えるようにする
GitHubは7月28日、Copilotアプリの利用状況をUsage Metrics APIのロールアップに広げました。個人ごとのCopilotアプリ利用、セッション数、リクエスト数、プロンプト数、トークン使用量、モデル・言語・機能別の内訳が、従来より広いレポートに入ります。
これは地味ですが、チーム運用では大きい更新です。AIエージェントの導入は「使わせる」だけでは終わりません。誰が、どのアプリで、どのモデルを使い、どれくらいコード生成に寄与したのかを見ないと、費用・品質・セキュリティの会話が感覚論になります。
今日見る設定
Copilot usage metrics policyが有効か確認する
Enterprise owner、billing manager、organization ownerの誰が見られるかを決める
「使った回数」だけでなく、PR品質、差し戻し、障害、レビュー時間と一緒に見る
ついでに見るべき外側の変化
同じ流れは、開発ツールの外でも起きています。LinkedInは6月に、低品質なAI生成投稿の検出と配信抑制を進めていると説明し、初期テストではgeneric contentの識別精度が94%だとしました。The VergeやBusiness Insiderは7月31日、LinkedInが「AI slop」に見える投稿を報告するボタンを追加したと報じています。
公式出典: https://news.linkedin.com/2026/keeping-conversations-real-on-linkedin 報道補足: https://www.theverge.com/ai-artificial-intelligence/973384/linkedin-seems-like-ai-slop-button
OpenAIとHugging Faceの評価中セキュリティインシデントも、同じ教訓を示しています。OpenAIは7月21日、評価目的で一部の拒否を弱めたモデルが、Hugging Face側のインフラに影響する異常活動につながったと説明しました。これは「AIが危険だから使うな」という話ではなく、評価環境、ネットワーク制限、権限、ログ、共同調査の設計が必要になるという話です。
出典: https://openai.com/index/hugging-face-model-evaluation-security-incident/
今日の流れを一言でいうと
AIツールは「便利な個人機能」から、管理者がデフォルト・権限・接続先・利用量を決める業務インフラへ移っています。
来週やることを1つだけ選ぶなら、まずは「新モデルや新アプリが勝手に有効になる設定」を確認してください。そこが見えていないと、MCPやエージェントの細かい運用ルールを作っても、前提がずれてしまいます。
あわせて読む
変更理由、承認、コネクタ、通知の線引きを先週の金曜リストで整理しています。
Google、1Password、OpenAI、EU DMAを材料に、個人・小規模チーム向けの接続設定を確認できます。
MCPがなぜ便利で、なぜ権限設計とセットで考えるべきかを初学者向けに整理しています。
気になる更新があれば、今日は新機能を試すより先に、管理画面をひとつ開いてみてください。AIを使うチームほど、「使える状態」より「止められる状態」を先に作る価値があります。
