今朝は10月19日までの公開情報を広く追い、一般的な会社員やエンジニアが「今日から何を変えられるか」を基準に6件へ絞った。今日の大きな流れは、AIそのものの賢さより「AIに何を見せ、どこまで触らせ、何円まで使わせるか」を外側から制御する仕組みが急速に整ってきたこと。便利さだけ先行していたエージェント界隈に、ようやく鍵と柵と電気メーターが付き始めた。

1. 10月22日からGitHub Copilotの新機能が「未設定なら自動で有効」になり得る。会社利用者は今日確認した方がいい

情報の確度：確認済み 難易度：管理者はすぐ確認／一般利用者は知識として重要

何が話題？

GitHubはCopilot Business／Enterprise向けに、新しい「Default policy for new features」を導入した。10月22日から、対象となる一般提供済みCopilot機能で管理者が明示設定していないものは、組織のグローバル既定値に従う。選択肢は Enabled、Disabled、Let organizations decide の3つ。明示的に有効・無効へ設定済みの項目は上書きされず、Preview機能は引き続きオプトイン。

つまり何ができる？

会社側は「新しいCopilot機能は基本ON」「基本OFF」「各組織に任せる」を一括指定できる。逆に言えば、何も考えずUnconfiguredのまま放置している会社では、10月22日以降に利用可能範囲が変わる可能性がある。

こんな人に役立つ

GitHub Copilot Business／Enterpriseを管理している人。MCP（AIと外部サービスをつなぐ共通規格）やCopilot Code Reviewを会社で使っているチームは特に確認価値が高い。

具体的な使用例

社内で「Copilot Chatは許可するが、MCPサーバー接続は個別審査」という運用をしているなら、グローバル既定値をDisabledへ寄せ、必要な機能だけ明示的に許可する。

試し方

① GitHub Enterprise／OrganizationのAI Controlsを開く ② CopilotのDefault policy for new featuresを確認 ③ Features & clients、Agents、MCP関連のUnconfigured項目を見る ④ 会社の意図と一致しているか確認する。

料金・制限・罠

これは便利機能というよりガバナンス変更。Preview機能まで勝手にONになるわけではない。また既に明示設定した項目は維持される。「10月22日に全機能が勝手に有効化される」という理解は誤り。

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

10月22日からの適用、3種類の既定値、明示設定の維持、Previewの扱いまでGitHub公式Changelogで確認済み。

情報源：GitHub Changelog「Default Enablement of Copilot features for Copilot Business and Enterprise」（2026年9月24日）

結月硝子一言：AI導入で地味に怖いのは新機能そのものより、「誰も設定していない」が設定として機能し始める瞬間。会社のセキュリティは往々にして、壮大な攻撃より未設定のプルダウンに負ける。

2. Codexが次に入力しそうな指示を予測。Proではベータ中の予測生成が利用枠を消費しない

情報の確度：確認済み 難易度：対象者ならすぐ使える

何が話題？

OpenAIのCodexデスクトップアプリにComposer predictionsがベータ導入された。Codexの回答後、「次にユーザーが送りそうな指示」を入力欄へ候補表示し、Tabで採用できる。採用しても自動送信はされず、編集してから送れる。

つまり何ができる？

「テストして」「そのエラーを直して」「READMEも更新して」のような、エージェント作業で何度も発生する小さな追指示を打つ回数を減らせる。

こんな人に役立つ

Codexデスクトップアプリを長時間使う個人ChatGPT Proユーザー。特にローカル／SSH環境で何往復も作業させる人。

具体的な使用例

CodexにPythonスクリプトを修正させた後、予測欄に「Run the tests and fix any failures」のような次工程が出ればTabで受け、内容を確認して送る。人間が工程監督として毎回同じ短文を打つ作業を削れる。

試し方

① 最新のCodexデスクトップアプリを使う ② GPT-6 AstraまたはGPT-6.1 Solのローカル／SSHスレッドを開く ③通常通り作業を依頼 ④回答後の入力欄に候補が出たらTabで採用し、必ず内容を読んでから送る。

料金・制限・罠

現時点では18歳以上の個人ChatGPT Proユーザー向けベータ。予測文の生成自体はベータ中、Codex利用上限やクレジットを消費しない。ただし採用後に実際に送信したメッセージとその処理は通常の利用量へ算入される。予測はデフォルトONで設定からOFF可能。

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

対象プラン、対応モデル、ローカル／SSH対応、予測生成がベータ中無料である点はOpenAI公式Release Notesで確認済み。

情報源：OpenAI ChatGPT Release Notes「Composer predictions in Codex」（2026年10月）

結月硝子一言：小機能だけど、エージェント作業では「AIが考える時間」より人間が毎回『次これ』と入力する摩擦が積み上がる。予測精度が高ければ、地味に効くタイプ。

3. AIエージェントにAPIキーそのものを渡さない。MCPとモデル接続を1か所で管理するOSSが実用段階に近づいている

情報の確度：確認済み。ただしpre-1.0のα版 難易度：技術者向け

何が話題？

TuskiraがApache 2.0で公開しているAI Agent Gatewayは、Claude Code、Cursor、VS Code、Codex CLIなどとMCPサーバー／LLMの間に「中継役」を置く。APIキーを各AIへ直接持たせず、Gateway側で資格情報を注入し、利用できる機能、呼び出し履歴、トークン量、推定費用を一元管理できる。

つまり何ができる？

Codex用、Claude Code用、Cursor用にAPIキーとMCP設定をコピーする構成から、「AIはGatewayだけ知っている。秘密鍵と権限はGatewayが持つ」構成へ変えられる。

こんな人に役立つ

複数AIエージェントへGitHub、Slack、DB、社内APIなどのMCPを接続している人。1人で試す段階より、複数端末・複数エージェントへ広がった時に効く。

具体的な使用例

Codexには「GitHubの読み取り＋テスト環境」、Claude Codeには「GitHub読み取り＋Issue作成」だけを許可し、同じ本番用資格情報はどちらにも直接渡さない。全呼び出しをGateway側で記録して、どのAIが何トークン使ったかも追う。

試し方

① GitHubのTuskira/ai-agent-gatewayを確認 ② Docker Composeでローカル起動 ③テスト用MCPを1個だけ登録 ④ CodexまたはClaude CodeのMCP接続先をGatewayへ変更 ⑤アクセスログと権限制御を確認する。本番資格情報ではなくテスト用キーから始める。

料金・制限・罠

OSS自体は無料だが、Docker等の実行環境と各LLM／APIの利用料は別。現在pre-1.0のα版でAPIや設定変更の可能性がある。デモ構成ではLLMやMCPの要求・応答本文をPostgreSQL等へ保存できるため、機密情報を扱うならログ本文保存設定も必ず確認する。

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

認証、資格情報注入、エージェント別の機能制限、OpenAI／Anthropic／Gemini／Bedrock対応、費用記録は公開GitHubリポジトリで確認できる。WindowsはWSL2経由で動作するとされるが未テスト扱い。

情報源：Tuskira AI Agent Gateway GitHub、Tuskira公式発表（2026年10月1日）

結月硝子一言：MCPが増えるほど「便利な接続一覧」がそのまま「漏れたら困る資格情報一覧」になる。AIごとに鍵を配るより、受付を一つ置く設計の方がまとも。

4. 「ファイルを読んだ後は外部送信禁止」まで設定できるStrands Box。単なるコンテナより一段細かい

情報の確度：確認済み／Developer Preview 難易度：技術者向け

何が話題？

AWSが10月7日にStrands BoxをApache 2.0のOSSとしてDeveloper Preview公開した。AIエージェントをOSレベルで隔離するだけでなく、Dogwoodというポリシー言語を使い、ファイル、Shell、Python、HTTP、MCP操作を「何をしたか」単位で許可・拒否できる。

つまり何ができる？

たとえば「customer-dataフォルダを読んだ後は外部HTTP通信を禁止」「Slack投稿は10分に3回まで」「削除操作は禁止」のように、AIの過去の行動まで含めて制約できる。

こんな人に役立つ

Codex、Claude系、LangChain、自作エージェントなどへShell・Python・MCP・ネット接続を渡している人。

具体的な使用例

障害調査AIにCloudWatchログ読み取りとSlack進捗投稿を許可する。ただしAWS環境の変更は禁止し、Slackへの投稿は10分に3回まで。さらにAPIキー本体はAI環境へ置かず、中継側で許可された通信にだけ付与する。

試し方

① Strands BoxのGitHub／Getting Startedを確認 ②本番ではなくローカルのテストエージェントをBox内で起動 ③削除禁止や通信先限定など単純なルールから設定 ④わざと禁止操作を依頼し、実際に拒否されることを確認する。

料金・制限・罠

OSSは無料だがDeveloper Preview。現状はmacOS中心で、他OS対応は今後拡張予定。ポリシーをLLMに書かせる機能も用意されているが、セキュリティルールをAIに書かせてそのまま信用するのは、鍵屋に鍵と住所を一緒に渡すようなものなので人間レビューは必要。

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

ファイル削除禁止、通信先制限、資格情報の外部注入、時間・回数に基づく制御などはAWS公式の実装例で確認できる。

情報源：AWS Open Source Blog「Introducing Strands Box: AI agent sandboxes powered by Dogwood」（2026年10月7日）

結月硝子一言：昨日までの「AIをサンドボックスに入れる」からさらに進んで、「箱の中でも何をしていいか」を外部ルールで縛る段階。エージェントが賢くなるほど、お願いベースの禁止事項は信用しない方がいい。

5. AIにShellを使わせる前に秘密情報を機械的に遮断。プロンプトで「APIキーを読まないで」より現実的

情報の確度：確認済み 難易度：少し設定が必要

何が話題？

GitGuardianのAI Hooksは、Claude Code、CodexなどAIコーディング環境のファイル読み取りやコマンド実行に介入し、秘密情報がモデルへ渡る前に検査する。9月25日の更新では、Claude Code、Codex、Mistral VibeでShellコマンドの出力に資格情報が混ざった場合、その出力をモデルから隠す処理が追加された。

つまり何ができる？

AIへ「環境を調べて」と頼んだ結果、コマンド出力にAPIキーやトークンが偶然含まれても、モデルへ送信される前に機械的に止められる場合がある。

こんな人に役立つ

CodexやClaude CodeへShell実行を許している人。特に.env、クラウド資格情報、GitHub tokenなどが開発PCに存在する環境。

具体的な使用例

Codexがデバッグ目的で環境変数や設定ファイルを読む際、秘密値を検出してモデルへの入力から遮断する。「AIへの指示文で禁止する」のではなく、AIの外側で止める。

試し方

① GitGuardian AI Hooksの対応環境を確認 ②テスト用のダミー秘密情報を置いた環境で導入 ③AIにファイル読取／Shell処理をさせる ④モデル側に値が届かず警告へ置換されるか確認する。本物のAPIキーでテストしない。

料金・制限・罠

ツールごとに遮断範囲が違う。GitGuardian自身も、MCPやその他の機能出力ではモデルまで届いてしまう環境があると明記している。またCodex等では生の出力がローカルのセッションファイルに残る場合がある。「モデルへ送られなかった＝PC上から秘密が消えた」ではない。

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

Claude Code／CodexでShell出力をモデルから遮断できる点と、環境ごとの限界はGitGuardian公式ドキュメントで確認済み。

情報源：GitGuardian Release Notes「AI Hooks keep leaked tool output away from the model」（2026年9月25日）

結月硝子一言：「秘密を読まないでね」とAIへ書くのは規則。「そもそも秘密を渡さない」は仕組み。セキュリティでは後者が圧倒的に強い。

6. GeminiからDropboxを直接検索・要約・整理できる。ただし日本ではまだ使えない

情報の確度：確認済み 難易度：対象地域ならすぐ使える／日本は現時点で待ち

何が話題？

DropboxとGoogle Geminiの接続機能では、GeminiからDropbox内のPDF、Word、表計算、プレゼン等を検索・要約・分析できるほか、ファイル／フォルダの移動・コピー・削除、共有リンク作成、Geminiの結果保存まで行える。Dropbox全プランが対象だが、初期提供は米国在住・18歳以上・個人Googleアカウント・英語・Gemini Web版という条件がある。

つまり何ができる？

Dropboxに資料を置いたまま、「先月の提案資料を探して要点をまとめる」「このプロジェクトの資料から会議メモを作る」とGeminiへ頼める。Gemini SparkではDropboxを資料源にしてGoogle Slides、Sheets、Gmail下書きへつなぐ複数工程も扱える。

こんな人に役立つ

Dropboxをファイル倉庫として使い、GeminiやGoogle Workspaceで成果物を作る人。ただし日本の個人ユーザーは現時点では対象外。

具体的な使用例

米国対象ユーザーなら「@Dropbox 最新の顧客提案資料を探し、重要ポイントを5つにまとめて」と入力し、その情報を基にGoogle Drive側の資料を作る。元ファイルをGoogle Driveへコピーする必要はない。

試し方

対象地域なら、①GeminiのSettings ②Personal Intelligence ③Connected apps ④Other ⑤DropboxをON ⑥@Dropboxを付けて指示する。日本では設定項目が出なくても異常ではない。

料金・制限・罠

Gemini Chat側のDropbox接続は米国の対象個人アカウントならDropboxの有料プランを必須としない。一方、Gemini SparkはGoogle AI Pro／Ultraが必要。Keep ActivityもONが条件。Geminiは権限のあるファイルしか参照できず、変更操作時には確認を求める。SparkはDropboxを常時監視する機能ではない。

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

対象地域、対象プラン、具体的な操作、Google Driveへ元ファイルを同期しない点までDropbox公式ヘルプで確認済み。

情報源：Dropbox Help「Gemini に Dropbox を接続する方法」（2026年9月23日更新）、Dropbox公式Gemini Integration

結月硝子一言：日本で今すぐ使えないのは残念だけど、方向性はかなり重要。AIへ毎回ファイルをアップロードする時代から、「普段の保管場所をAIが権限付きで参照する」時代へ移っている。

今日の観測

今日の6件は一見バラバラだけど、一本の線でつながっている。

これまでAI活用は「どのモデルが賢いか」が中心だった。今はその外側、つまり権限、秘密情報、費用、ログ、実行環境、接続先をどう管理するかへ競争軸が移り始めている。

特に重要なのは、AIへの指示とAIへの権限を分離すること。

「削除しないで」とプロンプトに書くのではなく削除権限を渡さない。「APIキーを読まないで」と頼むのではなくAIからキーを見えなくする。「Slackへ投稿しすぎないで」ではなく10分3回という制限を外側で強制する。

AIが十分賢くなった結果、次のボトルネックがモデル能力ではなく「人間側のシステム設計」になってきた。皮肉な話だけど、AIが進化するほど昔ながらの権限管理、ログ、最小権限、入力検査が重要になる。

今日ひとつだけ試すなら

今日は新しいサービスを契約するより、CodexやClaude Codeなど普段使っているAIが「何にアクセスできるか」を10分だけ棚卸しするのが一番いい。

① AIが読めるフォルダを確認する ② .env、SSH鍵、クラウド資格情報、GitHub tokenなどが同じ範囲にないか確認する ③ AIがShell、ブラウザ、MCP、GitHub書き込みを同時に使えるか確認する ④不要な権限を1つだけ外す。

理想は「AIを信用する」でも「AIを信用しない」でもない。間違えても困らない権限しか渡さないこと。

人間相手でもこの設計ができていれば、世の中の情報漏えい事故はもう少し少なかったはずなので、AIだけ特別に悪いわけでもない。