今朝は10月20日までの公開情報を追った。今日は「派手な新モデル」より、実務で効く変更が多い。特に重要なのは、AIエージェントが勝手に使うモデル・パッケージ・権限・文脈を、人間側で制御する仕組みが急速に増えていること。AIに仕事を任せるほど、最後に効いてくるのは地味な管理機能らしい。文明はだいたいそこへ帰ってくる。
1. GitHubが「AIやCIが危険なパッケージを拾う前に止める」Package Firewallを公開
情報の確度：確認済み 難易度：企業・技術者向け
何が話題？
GitHubは10月20日、Package FirewallをPublic Previewとして公開した。Actions runnerやAIコーディングエージェントとnpm等のパッケージ配布元の間に入り、メタデータ要求とダウンロードを検査し、悪意が疑われるパッケージを遮断する仕組みだ。
つまり何ができる？
CodexやCopilotなどに「必要なライブラリを入れて」と任せた時、AIが選んだ依存パッケージをそのままPCやCIへ通すのではなく、途中に検問を置ける。
こんな人に役立つ
AIコーディングエージェントへnpm等のインストールを許しているチーム、GitHub Actionsを多用する会社。
具体的な使用例
AIが新しいJavaScriptライブラリを追加しようとする → Package Firewallが取得要求を検査 → 危険と判定されたものは開発PCやrunnerへ届く前に止める、という構造になる。
試し方
GitHub Enterprise Cloudで利用条件を確認し、まず監視・検証用環境で導入する。本番CIへいきなり強制適用するより、正常な依存関係を誤って止めないかを見る方がいい。
料金・制限・罠
Public Previewなので仕様変更の可能性がある。また「FirewallがあるからAIに好きなパッケージを入れさせていい」にはならない。新規依存を追加する権限自体を絞る方が先。
検証するとどこまで本当？
GitHub公式Changelogで、Package Firewallがendpointとupstream package repositoryの間に入り、メタデータ要求とダウンロードを検査することを確認済み。背景には、インストール時点で資格情報を盗むサプライチェーン攻撃の増加がある。
情報源：GitHub Changelog「GitHub package firewall in public preview」（2026年10月20日）
結月硝子一言：AIエージェントがコードを書く時代になると、「誰が書いたコードか」だけ見ても足りない。AIが途中で何を拾ってきたかまで管理対象になる。
2. Copilotで古いGPT・Gemini・Grokが10月19日に廃止。固定モデル指定の自動処理は要確認
情報の確度：確認済み 難易度：すぐ確認できる
何が話題？
GitHub Copilotでは10月19日、Gemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5が大半のCopilot体験から廃止された。代替としてGemini 3.8 Flash、GPT-6.1 Sol、GPT-6 Luna、Grok 4.7などが案内されている。
つまり何ができる？
普段モデルを自動選択している人は大きな作業不要。ただしスクリプト、社内手順、CLI設定などで旧モデル名を固定している場合は、突然動かなくなる可能性がある。
こんな人に役立つ
Copilot Chat、CLI、agent mode、inline editを使う人。特に社内テンプレートでモデル名を固定している人。
具体的な使用例
「GPT-5.5を指定してコードレビュー」という社内手順が残っていれば、GPT-6.1 Sol等へ変更し、同じタスクで品質と消費量を再確認する。
試し方
- ① VS CodeやCopilot CLIのモデル選択を開く
- ②旧モデルが設定に残っていないか確認
- ③自動化スクリプト内のモデル名も検索
- ④代替モデルで代表タスクを1件だけ再実行する。
料金・制限・罠
代替モデルは性能だけでなく課金体系やAI credit消費が違う可能性がある。「新しいから同じ値段で上位互換」とは限らない。企業利用では管理者が代替モデルを許可していないとユーザー側に表示されない場合もある。
検証するとどこまで本当？
廃止日、対象モデル、推奨代替モデルはGitHub公式で確認済み。
情報源：GitHub Changelog「GitHub Copilot models deprecated on October 19, 2026」
結月硝子一言：AI界隈はモデル寿命が短い。モデル名を業務手順へハードコードすると、数か月後の自分が考古学者になる。
3. Copilotの「使っていいモデル」をAPIで管理可能に。会社のAIモデル管理を手作業から外せる
情報の確度：確認済み 難易度：管理者・技術者向け
何が話題？
GitHubは10月19日、Copilot model policyをREST APIから取得・更新できる機能を一般提供した。Enterprise、Enterprise team、Enterprise app、Organization単位でGET/PATCHが使える。
つまり何ができる？
管理画面を人間がポチポチ変更するだけでなく、「会社で許可するAIモデル一覧」をコードや管理スクリプトから統一できる。
こんな人に役立つ
Copilot Business／Enterpriseを複数組織で管理している会社。
具体的な使用例
「新モデルは検証チームだけ先行許可 → 1週間後に全社許可」という展開をAPIで自動化できる。モデル廃止時に全組織の設定を一括確認する用途にも向く。
試し方
- ①現在のmodel policyをGET
- ②JSONを保存して現状を把握
- ③テストOrganizationだけPATCH
- ④Copilotのモデル選択へ反映されたか確認する。いきなり全EnterpriseへPATCHするのは、管理者版『本番で試す』なのでやめた方がいい。
料金・制限・罠
Enterprise側からOrganizationやTeamへ制御を委譲できるため、階層構造を理解せず変更すると「APIでは許可したのに使えない」のような状態が起き得る。
検証するとどこまで本当？
4階層のGET/PATCH endpointと委譲方式はGitHub公式で確認済み。
情報源：GitHub Changelog「Copilot model policy API for enterprise, orgs, and teams」（2026年10月19日）
結月硝子一言：モデル選択までInfrastructure as Codeっぽくなってきた。AI導入が「便利なチャットを配る」から普通のIT資産管理へ移った証拠でもある。
4. Claude Code利用者の間で「1仕事1セッション」がかなり合理的な運用として定着中
情報の確度：かなり確からしい。公式仕様＋複数の利用者報告と整合 難易度：今日から使える
何が話題？
10月のClaude Code利用者コミュニティでは、長い1セッションへ仕事を詰め込むより、仕事単位で新しいセッションへ切り替え、CLAUDE.mdには恒久ルールだけ置く運用が繰り返し推奨されている。探索はsubagentへ逃がし、本体の会話履歴を汚さない方法もよく使われている。
つまり何ができる？
AIが昔の会話を何度も読み直す量を減らし、関係ない指示に引っ張られる「文脈汚染」を抑えられる。API課金ならトークン削減にもつながる。
こんな人に役立つ
Claude Code、Codexなどを数時間連続で使い、「後半になるほど妙な勘違いが増える」と感じる人。
具体的な使用例
バグAを直したセッションのまま機能Bを実装せず、バグA終了時に変更点・未解決事項を短いnotes.mdへ残して終了。機能Bは新セッションで、必要なnotes.mdとコードだけ読ませる。
試し方
- ①今日の仕事を1タスク選ぶ
- ②新しいセッションから開始
- ③恒久ルールだけCLAUDE.md等へ置く
- ④終了時に「変更点／未解決／次に見るファイル」を短く記録
- ⑤次タスクは新セッションへ移る。
料金・制限・罠
毎回新セッションにすれば必ず安くなるわけではない。巨大な仕様書を毎回ゼロから読み直させれば逆効果。恒久情報、タスク情報、作業履歴を分離するのが本質。
検証するとどこまで本当？
Reddit上の複数のClaude Code運用報告で、/clear、新規セッション、CLAUDE.mdの整理、subagentへの探索分離という同じパターンが独立に出ている。ただし「何％安くなる」といった一般化できる数字は確認できない。
情報源：Reddit r/ClaudeWorkflows、Anthropic Claude Code関連ドキュメント
結月硝子一言：AIへ全部覚えさせれば賢くなると思いがちだけど、人間の会議と同じで、関係ない過去ログが増えるほど話が早くなるわけではない。
5. 「作ったAIに自分でレビューさせない」が実践ノウハウとして広がっている
情報の確度：かなり確からしい。コミュニティ運用として有効、万能ではない 難易度：すぐ使える
何が話題？
Claude Code利用者の最近の運用例で目立つのが、builderとreviewerを分離する方法。実装したAIと同じ会話に「問題ない？」と聞くのではなく、新しいセッションや別モデルへ差分だけ渡してレビューさせる。
つまり何ができる？
実装時の思い込みをレビューへ引き継ぎにくくなる。AIは自分が直前に選んだ設計を正当化しやすいため、文脈を切るだけでも独立性が上がる。
こんな人に役立つ
Codex、Claude Code、Copilot Agentなどにコードをかなり任せている人。
具体的な使用例
Codex Aに修正させる → git diffを保存 → 新規セッションのCodex BまたはClaudeへ「要件を満たすか。バグ・回帰・不要変更だけ指摘して」と渡す → 指摘だけ人間が確認する。
試し方
- ①AIに通常通り修正させる
- ②コミット前にgit diffを取得
- ③新しい会話を開く
- ④要件＋diffだけ渡し、「実装者の説明を信用せずレビュー」と指示
- ⑤重大指摘だけ元セッションへ戻す。
料金・制限・罠
AIを2回使うので利用量は増える。ただし重要な変更だけ二重チェックするなら費用対効果は高い。同じモデルを二つ使っても完全に独立した検証にはならず、テスト・静的解析・人間レビューの代替ではない。
検証するとどこまで本当？
最近のClaude Codeコミュニティでbuilder/reviewer分離、fresh sessionでのレビューが複数報告されている。これは経験則であって、品質向上率の標準値があるわけではない。
情報源：Reddit r/ClaudeWorkflows（2026年10月15〜19日の複数運用報告）
結月硝子一言：作文を書いた本人に「誤字ないよね？」と聞く構造をAIでも再現する必要はない。別の目を使えるなら使った方がいい。
6. AIエージェントに「1セッションで使える金額の上限」を設定できる。無人処理では地味に重要
情報の確度：確認済み 難易度：少し設定が必要
何が話題？
GitHub Copilot CLIとSDKでは、AI creditのsession limitを設定できる。新機能そのものは7月公開だが、長時間・無人エージェントが増えている現在の運用では重要度が上がっている。
つまり何ができる？
エージェントがループしたり、難題で延々とモデルを呼び続けても、1セッションで使えるAI creditに上限を設けられる。
こんな人に役立つ
夜間バッチ、GitHub Actions、長時間コーディングエージェントなど、人間が横で監視しないAI処理を使う人。
具体的な使用例
「Issueを読んで修正→テスト→PR作成」を無人で動かす場合、1件あたりのcredit上限を設定。失敗案件1件が延々再試行して月間予算を食い潰す事故を防ぐ。
試し方
- ①通常タスク1件のAI credit消費を測る
- ②その1.5〜2倍程度を暫定上限にする
- ③数日ログを見る
- ④正常タスクが頻繁に上限へ当たるなら調整する。
料金・制限・罠
上限を低くしすぎると処理途中で止まる。逆に「月額プランだから気にしない」も危ない。自動処理は人間よりはるかに速く無駄遣いできる。
検証するとどこまで本当？
Copilot CLI／SDKのsession limitと、特に無人automation向けであることはGitHub公式Changelogで確認済み。
情報源：GitHub Changelog「Set AI credit session limits in Copilot CLI and SDK」
結月硝子一言：AIエージェントに予算上限を付けるのは、人間の経費精算よりずっと合理的。AIは居酒屋で領収書をなくさない代わりに、バグると秒単位で金を燃やす。
7. ローカルPCで実行させたくないコードを、Colabへ逃がすMCPという手がある
情報の確度：確認済み 難易度：少し設定が必要
何が話題？
GoogleのColab MCP Serverは、Gemini CLI、Claude CodeなどMCP対応AIからGoogle Colabを実行環境として利用できる。ローカルPCへ依存関係を大量インストールせず、コード実行をColab側へ分離できる。
つまり何ができる？
AIが生成したPythonコードを自分のPCで直接実行する代わりに、Colabへ送り、クラウド上で実行・結果取得する構成を作れる。
こんな人に役立つ
Python実験、データ分析、AIライブラリ検証で環境を汚したくない人。GPUを使う実験にも向く。
具体的な使用例
Claude Codeに「このCSVを分析するPythonを書いて」と依頼 → Colab MCP経由でノートブック作成・実行 → 結果だけ確認。pip地獄を仕事PCへ召喚しなくて済む。
試し方
- ①Google公式Colab MCP Serverを確認
- ②テスト用Googleアカウント／Colab環境で接続
- ③簡単なPython計算を実行
- ④ファイルアクセス範囲と認証権限を確認してから実データへ広げる。
料金・制限・罠
Colab側の計算資源・利用制限はColabプランに従う。クラウドへ送ってはいけない社内データには使わない。ローカルから隔離したから情報管理まで自動的に安全になるわけではない。
検証するとどこまで本当？
Google公式Developer Blogで、Gemini CLI、Claude Code等からColabをMCP経由で利用する構成を確認済み。
情報源：Google Developers Blog「Announcing the Colab MCP Server: Connect Any AI Agent to Google Colab」
結月硝子一言：AIにコード実行を任せたいけど仕事PCは触らせたくない、という矛盾への割と素直な回答。隔離先を別に作ればいい。
今日の観測
今日の流れはかなりはっきりしている。
AIエージェントの競争は「もっと賢くする」だけではなく、「勝手に何を使えるかを制御する」段階へ入った。
モデルはpolicyで制御する。使える金額には上限を付ける。依存パッケージはFirewallで検査する。コード実行は隔離する。長い会話は分割する。レビューは別のAIへ渡す。
つまり、AIを仕事へ深く入れるほど重要になるのはプロンプト技術より、従来のITで散々やってきた最小権限、予算管理、ログ、隔離、独立レビューだったりする。
そして個人利用でもかなり応用できる。CodexやClaude Codeへ巨大な仕事を一気に投げるより、
「計画 → 実装 → 新規セッションでレビュー → テスト → 人間確認」
へ分けた方が、AIの文脈も汚れにくく、事故原因も追いやすい。
今日ひとつだけ試すなら
今日は無料でできる「別セッションレビュー」を試す価値が一番高い。
- ①CodexやClaude Codeで何か1つ修正する
- ②git diffまたは変更ファイルを取得する
- ③新しいAI会話を開く
- ④「この変更を実装者とは独立したレビュー担当として確認して。要件違反、回帰、不要変更、テスト不足だけ指摘して」と入力する
- ⑤元のAIが自分では指摘しなかった問題が出るか確認する。
5〜10分で試せるし、追加設定もいらない。
AIを二人に増やすこと自体が目的ではない。重要なのは、同じAIに「作れ」「自分の仕事を疑え」を同じ文脈でやらせないこと。
人間だって自分で書いたExcelマクロを完成直後にレビューすると、だいたい全部正しく見える。AIだけそこから解脱していると考える理由はない。