今朝は10月23日までの公開情報を追った。今日は「新しい巨大モデルが出た」日ではなく、普段使っているAIを一段まともに運用する更新が多い。特に実用性が高いのは、Codex CLIの定型指示プリセット、Claude Codeのsandbox修正、AI用Skillの共通規格化、Copilotの社内Skill/MCP利用状況の可視化。この辺はモデルのIQ競争より地味だけど、毎日使う側にはむしろ効く。

1. Codex CLIに「いつもの指示」を10個保存できる /presets が追加

情報の確度：かなり確からしい。10月23日公開のv0.164.0リリース情報で確認 難易度：Codex CLI利用者ならすぐ使える

何が話題？

Codex CLI rust-v0.164.0で、よく使うプロンプトやスラッシュコマンドを10個の /presets スロットへ保存できるようになった。さらに /model と /permissions でモデル、推論の強さ、速度、権限プロファイルをその場で指定でき、再開したセッションでも保存済み設定が復元される。

つまり何ができる？

毎回「まず仕様を確認→変更箇所を調査→最小変更→テスト→変更一覧を報告」と長々書かなくてよくなる。レビュー用、調査用、実装用などをプリセット化できる。

こんな人に役立つ

Codexへ似た作業を何度も頼む人。特に、調査・実装・レビューで指示を使い分けている人。

具体的な使用例

Preset 1を「実装」、Preset 2を「レビュー」、Preset 3を「原因調査」にしておく。バグ修正なら調査→実装→別セッションでレビュー、と同じ型をすぐ再利用できる。

試し方

  • ①Codex CLIをv0.164.0へ更新
  • ②/presetsを開く
  • ③普段繰り返している指示を1つ登録
  • ④小さな作業で呼び出し、毎回の手入力が減るか確認する。

料金・制限・罠

プリセット自体が利用料金を下げるわけではない。むしろ巨大な指示を毎回呼び出せば入力トークンは増える。保存するのは「毎回本当に必要な短い作業規則」に絞る方がいい。

検証するとどこまで本当？

10個のプリセット、inlineのmodel/permissions指定、画像プレビュー、セッション再開時の設定復元、資格情報マスキングなどがv0.164.0の変更点として確認できる。

情報源：OpenAI Codex CLI rust-v0.164.0 release tracking（2026年10月23日）

結月硝子一言： 長文プロンプトをメモ帳から毎回貼る時代が、ようやく設定側へ吸収され始めた。人間は同じ文章を何百回もコピペしてから「自動化できないかな」と考える生物なので、順番はいつもこうなる。

2. Claude Code利用者は更新優先。sandboxの境界を抜ける複数の穴が2.1.309で修正

情報の確度：確認済み。Anthropic公式GitHubリリースで確認 難易度：更新だけならすぐ使える

何が話題？

Claude Code v2.1.309ではsandboxと権限周りの修正が集中している。sandbox内のBash実行前にshell startup fileがsandbox外で実行される問題、symlink経由でmacOSのdenyWrite指定を回避できる問題、sandbox内コマンドや自動承認された編集が--mcp-configで指定したMCP設定ファイルを書き換えられる問題などが修正された。

つまり何ができる？

「Claude Codeをsandboxで動かしているから、指定外の場所は触れない」という前提が以前より信用できるようになる。特に無人実行やSDK利用では重要。

こんな人に役立つ

Claude CodeへShell実行を許している人、MCPを使う人、自動承認やheadless実行を使う人。

具体的な使用例

AIへリポジトリ内だけ編集許可を与えているつもりでも、symlinkやshell初期化ファイル経由で境界外へ影響する経路があればsandboxの意味が薄れる。今回の修正はその種の穴を塞ぐもの。

試し方

  • ①claude --versionを確認
  • ②古ければ最新版へ更新
  • ③sandbox設定と--mcp-configを使っている自動処理をテスト環境で再実行
  • ④禁止パスへの書き込みが拒否されるか確認する。

料金・制限・罠

「最新版ならsandboxが絶対安全」という意味ではない。sandboxは被害範囲を狭める仕組みで、万能な防壁ではない。本番資格情報や削除権限を渡さない設計は引き続き必要。

検証するとどこまで本当？

Anthropic公式GitHubのv2.1.309リリースノートで、startup file、symlink、MCP config自己変更、無効化済みMCPの再接続などの修正を確認できる。

情報源：Anthropic Claude Code v2.1.309（2026年10月22日）

結月硝子一言： sandboxは「AIを信用する仕組み」ではなく「信用しなくても壊れにくくする仕組み」。こっちの発想の方が長持ちする。

3. AI用の「Skill」がClaude専用から共通規格へ。ChatGPT・Copilot・Cursorなど70以上が対応

情報の確度：確認済み。Anthropic公式発表 難易度：一般利用はすぐ〜少し設定

何が話題？

Anthropicは10月22日、Agent Skills規格をLinux Foundation傘下のAgentic AI Foundationへ寄贈した。Skillは基本的にSKILL.mdと必要なスクリプト・参考資料をフォルダへまとめ、「この仕事はこうやる」とAIへ教える仕組み。AnthropicによればChatGPT、Cursor、GitHub Copilot、VS Codeなど70以上のAIエージェント基盤が統合している。

つまり何ができる？

「Claude用に作った仕事の手順」を、別AIでも使える方向へ進んでいる。AIを変えるたびに社内手順を全部書き直す必要が減る可能性がある。

こんな人に役立つ

Codex、Claude Code、Copilotなど複数AIを使い分ける人。社内の作業手順をAIへ覚えさせたい人。

具体的な使用例

「Excel調査票を受け取る→列名確認→欠損チェック→集計→結果.xlsxを作る」という社内手順をSkill化する。モデルを変更しても作業手順自体は再利用する。

試し方

  • ①繰り返し行っている仕事を1つ選ぶ
  • ②手順を5〜10工程に分解
  • ③Skill対応AIでSKILL.mdとして保存
  • ④同じ入力を別セッションで処理し、手順が再現されるか確認する。

料金・制限・罠

共通規格になったからといって、すべてのAIが完全に同じ結果を返すわけではない。Skillは「仕事の説明書」であってモデル性能そのものではない。また第三者Skillにはスクリプトも含められるため、出所不明のSkillを無確認で実行するのは危険。

検証するとどこまで本当？

Anthropic公式発表で、Agent SkillsのAAIFへの寄贈、SKILL.md中心の構造、70以上のプラットフォームでの統合を確認済み。

情報源：Anthropic「Donating Agent Skills to the Agentic AI Foundation」（2026年10月22日）

結月硝子一言： これは地味に大きい。AIを「どの会社のモデルを使うか」と「会社固有の仕事のやり方」に分離できれば、モデル乗り換えのコストがかなり下がる。

4. GitHub Copilotで「どの社内Skill・MCPが本当に使われているか」名前付きで測定可能に

情報の確度：確認済み 難易度：企業管理者向け

何が話題？

GitHubは10月22日、Copilot usage metrics APIを更新し、組織が作ったSkill、custom agent、MCPサーバー、slash command、pluginをother扱いせず設定名ごとに集計できるようにした。表示件数も各分類5件から最大25件へ増えた。

つまり何ができる？

「社内用MCPを作ったけど誰か使ってるの？」が測れる。利用されない社内AI機能を廃止したり、人気のSkillだけ整備したりできる。

こんな人に役立つ

Copilot Business／Enterpriseを導入し、独自MCPやSkillを配布している会社。

具体的な使用例

社内に「仕様書検索MCP」「DB検索MCP」「障害調査Skill」を配布し、1か月後に利用数を見る。ほぼ誰も使っていない機能は、UI・説明・存在意義のどこかが怪しいと判断できる。

試し方

  • ①Copilot usage metrics APIを取得
  • ②totals_by_skill、totals_by_custom_agent、totals_by_mcpを見る
  • ③利用回数と利用者数を確認
  • ④配布数ではなく実利用で残す機能を決める。

料金・制限・罠

client telemetry依存なので完全な請求台帳ではない。古いクライアントやtelemetryが遮断された環境は過小集計され得る。GitHub自身も傾向分析向けとしている。また内部MCP名などがレポートへ露出するため、共有範囲には注意。

検証するとどこまで本当？

GitHub Changelogで名前付き集計、最大25項目、対象レポート、telemetry由来の制約を確認できる。

情報源：GitHub Changelog「Custom skills, agents, and MCP servers in usage metrics API」（2026年10月22日）

結月硝子一言： AI導入率を「ライセンスを何人に配ったか」で語る時代から、「何の機能が実際に使われたか」へ少し進んだ。配布数を成果扱いする企業文化には地味に都合が悪い機能。

5. Visual StudioからPR確認と脆弱NuGet修正までCopilotへ寄せられる

情報の確度：確認済み 難易度：Visual Studio 2026利用者なら少し設定

何が話題？

GitHubが10月22日に公開したVisual Studio 2026向け更新では、Git agentからPull Requestを読み、コメントや変更ファイルへのリンク付きで要約できるようになった。またNuGet Auditで脆弱なパッケージが見つかった場合、Copilot＋NuGet MCPを使って修正へ進める。BYOM（自分で選んだモデルを接続する仕組み）も更新された。

つまり何ができる？

ブラウザでGitHubを開いてPRを読み、Visual Studioへ戻り、NuGet画面を開き……という往復を減らせる。

こんな人に役立つ

C#/.NETをVisual Studioで開発している人。特に社内システム保守。

具体的な使用例

PRをGit agentへ渡して「変更目的・影響ファイル・レビューで揉めている点」を先に整理させ、人間は該当箇所だけ確認する。NuGet Auditの警告はCopilotへ修正案を作らせ、テスト後に採用する。

試し方

  • ①Visual Studio 2026を更新
  • ②Copilot ChatでGit agentを選択
  • ③GitHubまたはAzure DevOpsのMCPを接続
  • ④テスト用PRを添付して要約精度を見る。

料金・制限・罠

PR要約にはGit providerのMCP接続が必要。BYOMはPreviewで、以前登録したOllamaモデルは再追加が必要になる場合がある。NuGetの「最新版へ上げれば解決」は依存関係を壊すこともあるので、AI修正後のbuild/testは必須。

検証するとどこまで本当？

GitHub公式ChangelogでPR探索、BYOM更新、NuGet Audit fixerを確認済み。

情報源：GitHub Changelog「GitHub Copilot in Visual Studio — September update」（2026年10月22日）

結月硝子一言： IDEから出ないこと自体が目的ではないけど、調査のたびにブラウザとIDEを往復して脳内キャッシュを破壊する回数は減らせる。

6. Googleが「AIエージェント自身に改善させる」設計を公開。ただし永久変更には人間承認

情報の確度：確認済み。ただし研究・企業向け参照設計 難易度：技術者向け

何が話題？

Google Cloudは10月22日、Gemini Enterprise Agent PlatformとADKを使った自己改善型AIエージェントの参照設計「Project Chrysalis」を公開した。障害対応中に必要な対処機能をその場で生成し、効果を評価し、有効だったルールを記憶する。ただし生成コードは署名・ポリシー検証を通し、恒久変更には人間の明示承認を要求する。

つまり何ができる？

AIの作業手順を人間が毎回事前登録するのではなく、未知の障害に遭遇した時にAI自身が一時的な対処機能を作る設計が現実味を帯びてきた。

こんな人に役立つ

クラウド運用、SRE、社内AIエージェント設計をしている人。一般会社員が今日導入するものではないが、今後の業務AIの構造を見るには重要。

具体的な使用例

DB接続枯渇が起きる→AIがログを分析→一時的な診断・緩和処理を生成→実行結果を評価→有効だった対処だけ署名付きルールとして残す。恒久的なシステム変更は人間承認後に行う。

試し方

個人環境で真似するなら「AIに自分自身を書き換えさせる」必要はない。①AIが改善案を別ファイルへ出す ②テストする ③人間がdiff確認 ④承認後に本設定へ反映、という4段階だけ採用すればいい。

料金・制限・罠

Google Cloudの企業向け構成で、Model Armor、Cloud KMS、Binary Authorization、OPAなど複数サービスを使う。簡単・無料な仕組みではない。またGoogle自身の参照アーキテクチャであり、「これで完全自律運用できる」という実証ではない。

検証するとどこまで本当？

Google公式記事では、自己生成した対処機能、効果評価、記憶、暗号署名、人間承認を明示している。むしろ重要なのは、Google自身が「自己改善AIだから自由に変更させる」構成にしていない点。

情報源：Google Developers Blog「Architecting Governed, Self-Evolving AI Agents on Google Cloud」（2026年10月22日）

結月硝子一言： 自己改善AIの面白いところは「AIが勝手に賢くなる」部分より、賢くなろうとするAIをどう檻に入れるかの方。SFよりアクセス権管理が勝つ。

7. Agents CLIがADK専用から脱却。LangChainなど別基盤でも同じ開発・テスト・配布手順を使える

情報の確度：確認済み。Extension SystemはExperimental 難易度：技術者向け

何が話題？

GoogleのAgents CLI v1.8.0にExtension Systemが入り、ADKだけでなくLangChain/LangGraphなど別のAIエージェント基盤を同じ開発手順へ載せられるようになった。外部ExtensionはGitの特定commit SHAへ固定され、lockfileで再現可能にする。

つまり何ができる？

「LangChainだからこの配布方法、ADKだから別手順」とバラバラにせず、作成・テスト・評価・Cloud Run配布などを共通化できる。

こんな人に役立つ

複数のAIエージェント基盤を比較・運用する開発チーム。

具体的な使用例

最初はLangChainで作り、後からADK版も比較する場合でも、CI/CDや評価手順を極力同じ形に保つ。AI基盤を変えるたびに運用全部を作り直さずに済む。

試し方

Google公式例ではPython 3.11+、uv、Google Cloud SDKを準備し、uvx google-agents-cli setupで導入。LangChainテンプレートからプロジェクトを作成できる。

料金・制限・罠

Extension Systemはv1.8.0時点でExperimental。破壊的変更の可能性があり、GoogleもAgents CLIバージョン固定を推奨している。Google Cloudプロジェクトと課金設定も必要。

検証するとどこまで本当？

公式記事ではGit参照をcommit SHAへ固定し、lockfileから同一コードを復元する仕組みまで説明されている。AIエージェントの拡張機能をnpm的に扱う方向。

情報源：Google Developers Blog「Powering the Agent Development Lifecycle with any framework, from ADK to LangChain and beyond」（2026年10月22日）

結月硝子一言： AI開発基盤は増えすぎたので、次に売れるのが「全部を同じ手順で扱う仕組み」なのは自然。人類は抽象化レイヤーを増やして複雑さを解決し、その抽象化レイヤーを管理する新しい複雑さを作る。

8. OpenAIの「AIで脆弱性を探す」が実験から実戦へ。PHPの重大脆弱性対応で使われた

情報の確度：確認済み。ただし発見能力に関する一部表現はOpenAI側の主張 難易度：一般利用より今後の影響が重要

何が話題？

OpenAIは10月22日、Patch the Planetの活動として、GPT-5.6 Solを使った調査でPHPの重大な脆弱性を発見し、PHP保守者、Wiz、インフラ事業者、政府系サイバー機関などと修正・防御準備を進めたと公表した。OpenAIは「攻撃者より先にfrontier AIが発見した」としているが、これはOpenAI側の表現なので、その部分は企業側の主張として扱うべき。

つまり何ができる？

AIコードレビューの用途が「バグっぽい箇所を指摘」から、巨大OSSを横断して未知の脆弱性候補を探し、人間の専門家が検証する段階へ進んでいる。

こんな人に役立つ

今すぐ一般会社員がPHPへAI脆弱性探索をかける話ではない。ただ、社内コードでも将来的に「通常レビュー＋AIセキュリティ探索」が標準工程になる可能性が高い。

具体的な使用例

社内プログラムで、通常のコードレビューとは別セッションに「入力検証・権限・SQL・ファイル操作・秘密情報漏洩だけを攻撃者視点で確認」と依頼し、候補を人間が検証する。AIの指摘をそのまま脆弱性認定しないことが重要。

試し方

  • ①機密でない自作コードを選ぶ
  • ②通常レビューとは別セッションを開く
  • ③「脆弱性候補だけ列挙。確信度と攻撃成立条件を分ける」と依頼
  • ④静的解析や実コード確認で裏を取る。

料金・制限・罠

AIは誤検知も見逃しもある。セキュリティ診断の代替ではない。OpenAIはOSS保守者向けCodex提供や支援も行っているが、一般企業の無料セキュリティ監査サービスという意味ではない。

検証するとどこまで本当？

PHP対応、GPT-5.6 Sol利用、Wizによる独立発見、保守者との修正調整はOpenAI公式で確認できる。「AIが攻撃者より先だった」は外部から完全検証できないため企業主張として留保する。

情報源：OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」（2026年10月22日）

結月硝子一言： コード生成が速くなるほど、レビュー側もAI化しないと人間がボトルネックになる。ただし「AIが書いてAIが安全判定して終了」は、宿題を書いた本人に採点まで任せる構造なので避けたい。

今日の観測

今日いちばん大きい流れは、モデルそのものより「AIへ仕事のやり方を渡す層」が独立し始めたこと。

Codexはプリセットを持ち、Agent Skillsは共通規格になり、CopilotはSkillやMCPごとの利用状況を測れるようになった。つまり今後は、

モデル = 頭脳 Skill = 社内手順書 MCP/API = 外部システムとの接続 sandbox/権限 = 行動範囲 usage metrics = 実際に何を使ったかの監査

という分業がかなり明確になりそう。

この構造になると、「Claudeが一番賢い」「GPTが一番強い」という比較だけでは業務AIを評価できなくなる。頭脳を交換しても、Skill・権限・データ接続・テストが残る構成の方が長期的には強い。

そして昨日までの流れともつながっている。AIを賢くする方向と同時に、sandbox、署名、lockfile、人間承認、利用ログが急速に増えている。AI業界も結局「便利なやつに仕事を任せたら監査が必要になった」という、会社組織が数百年かけて学んだ話を高速再生している。

今日ひとつだけ試すなら

今日はCodexやClaudeで、普段繰り返している指示を1個だけSkill／Preset候補として切り出すのが一番いい。

5〜10分でできる。

  • ①最近3回以上AIへ書いた同じ指示を探す ②「毎回必要な部分」と「今回だけ必要な部分」を分ける ③毎回必要な部分だけ短い定型指示にする ④次の仕事でそれを呼び出し、追加説明が減るか確認する

例えばコード修正なら、

「変更前に原因を特定する。最小変更を優先する。既存仕様を勝手に変更しない。修正後はテストを実行する。最後に変更ファイル・テスト結果・未解決事項を報告する。」

これくらいで十分。

100行の「究極のプロンプト」を作る必要はない。むしろ長すぎる恒久指示は毎回のAI利用量を食う。頻繁に使う短い原則だけ常設し、案件固有情報はその都度渡す。

AI活用が上手くなるというのは、プロンプトを長くすることではなく、毎回説明しなくていいことを少しずつ外へ追い出すことなのよ。