今朝は10月17日までの公開情報を追い、「新モデルが出た」ではなく、今日の作業手順や費用のかけ方が変わるものを優先した。今回は5件。特に大きいのは、OpenAIがGPT-6を“高性能版と安価・高速版の二層”として出したこと、GitHubがSlack/Teamsから複数リポジトリを横断できるようにしたこと、そしてAIによる脆弱性検査が一般提供になったこと。
1. 難しい仕事だけGPT-6 Sol、軽い仕事はLunaへ。AI料金を下げる使い分けがかなり現実的になった
情報の確度：確認済み 難易度：すぐ使える
何が話題？
OpenAIは10月16日、GPT-6 SolとGPT-6 Lunaを発表した。Solは複雑な知識作業や推論向け、Lunaは速度と費用効率を重視した日常処理向けという位置づけ。単に「6になって賢くなった」という話より重要なのは、OpenAI自身が用途別に計算量を分ける構成を明確にしてきたこと。
つまり何ができる？
メール整理、分類、形式変換、短い要約などはLuna、設計判断、複雑なコード解析、調査、難しい資料作成はSol、と仕事を分けられる。全部を最上位モデルへ投げる必要がない。
こんな人に役立つ
ChatGPTやAPI、AIエージェントを日常的に使い、利用量や応答速度が気になっている人。
具体的な使用例
大量のExcelやCSVを処理するなら、1000行の分類や整形をLunaへ任せ、異常データだけSolへ渡して原因分析させる。高価な判断能力を全行へ使わない。
試し方
①普段AIへ頼んでいる仕事を「判断が難しい」「単純処理」に分ける ②単純処理をLunaで試す ③品質が足りるか確認 ④難しい部分だけSolへ切り替える。
料金・制限・罠
安いモデルへ全部移せば得、ではない。軽量モデルで失敗して何度も再実行すれば逆に高くなる。見るべきなのは1回の単価ではなく「仕事1件を完了する総費用」。
検証するとどこまで本当？
SolとLunaの役割分担、速度・能力の位置づけはOpenAI公式発表で確認済み。実際の費用対効果は作業内容によって変わる。
情報源：OpenAI「Introducing GPT-6 Sol and Luna」（2026年10月16日）
結月硝子一言：最強モデルを全作業へ使うのは、コンビニへF1で行くようなもの。速そうだけど運用としてはだいぶ間抜け。AIも適材適所の方が安い。
2. SlackやTeamsから複数GitHubリポジトリをまたいで調査・Issue・PR作成ができるようになった
情報の確度：確認済み 難易度：少し設定が必要
何が話題？
GitHubは10月15日、SlackとMicrosoft Teamsの@GitHub連携を更新し、1つの会話から複数リポジトリを横断できるようにした。Issue作成、PR作成、バグ調査などで、リポジトリごとに会話を切り替える必要が減る。
つまり何ができる？
「フロント側でこのエラーが出ている。API側と共通ライブラリも調べて原因候補を出して」のような、複数リポジトリをまたぐ仕事をSlackから始められる。
こんな人に役立つ
GitHub＋Slack/Teamsで開発していて、フロント、バックエンド、共通部品などを別リポジトリで管理しているチーム。
具体的な使用例
障害報告がSlackへ来たら、そのスレッドで@GitHubへ「web-app、api、shared-libを調べ、このエラーに関連する最近の変更を探して」と依頼する。ブラウザで3つのリポジトリを順番に開く工程を減らせる。
試し方
①GitHubとSlackまたはTeamsの連携を確認 ②テスト用チャンネルで@GitHubを呼ぶ ③関係する2つのリポジトリを指定 ④「両方を見て関連箇所を説明」と頼み、参照範囲を確認する。
料金・制限・罠
AIへアクセスさせるリポジトリ権限が前提。複数リポジトリを見られるということは、便利さと同時に情報アクセス範囲も広がる。機密リポジトリを雑に束ねるのは避ける。
検証するとどこまで本当？
複数リポジトリ対応、Issue・PR・バグ調査などの用途はGitHub公式Changelogで確認済み。
情報源：GitHub Changelog「Multi-repository support and other improvements for GitHub in Slack and Teams」（2026年10月15日）
結月硝子一言：これは地味だけど実務向け。AIの価値は新しい画面を増やすことじゃなく、既に人間が住んでいるSlackから仕事を動かせることにある。
3. Pull RequestをAIが脆弱性検査する「AI Scan」が一般提供。Shell、Dockerfile、Terraformまで対象が広い
情報の確度：確認済み 難易度：GitHub利用者なら少し設定
何が話題？
GitHubは10月15日、Pull Request向けAI Scanを一般提供した。従来のCodeQLを補完し、PHP、Shell/Bash、TerraformのHCL、Dockerfile、JSP、Blazorなど、CodeQLだけでは十分カバーできなかった変更もAIで検査する。
つまり何ができる？
コードをマージする前に、AIが変更差分を読み「このShellスクリプトは入力値の扱いが危ない」「Dockerfileの設定に問題がある」といった候補を出せる。
こんな人に役立つ
GitHubで社内ツール、Python周辺スクリプト、Docker、Terraform、CI/CD設定を管理している人。
具体的な使用例
AIに生成させたBashやDockerfileをそのまま採用せず、Pull Request段階でAI Scanへ通す。つまり「AIが書いたものを別のAIに疑わせる」。人類がレビュー工程まで機械同士に喧嘩させ始めた。
試し方
①GitHubのCode Security設定を確認 ②対象リポジトリでAI Scanを有効化できるか確認 ③小さなPRで実行 ④指摘内容を人間が確認し、既存スキャナの結果とも比較する。
料金・制限・罠
AI ScanはCodeQLの代替ではなく補完。AI検査には誤検知・見逃しがあるので「指摘なし＝安全」ではない。提供条件や課金は契約形態によって確認が必要。
検証するとどこまで本当？
一般提供開始と対象言語・設定形式はGitHub公式Changelogで確認済み。
情報源：GitHub Changelog「AI Scan for pull requests generally available」（2026年10月15日）
結月硝子一言：AI生成コードが増えるほど、生成速度より検証速度がボトルネックになる。作るAIより疑うAIの方が重要になる場面は確実に増える。
4. GitHub Copilotで古いモデル3種が11月16日に終了。固定モデル指定の自動処理は今のうちに確認
情報の確度：確認済み 難易度：該当者は設定確認だけ
何が話題？
GitHubは11月16日にCopilot全体でClaude Opus 4.8、Claude Opus 5、GPT-5.6 Terraを廃止すると発表した。推奨移行先はClaude Opus 5.5、GPT-6.1 SolまたはGPT-6 Luna。
つまり何ができる？
というより、何もしないと壊れる可能性がある話。Copilot Chatで毎回手動選択しているだけなら大問題になりにくいが、モデル名を固定した自動処理、組織ポリシー、エージェント設定は確認した方がいい。
こんな人に役立つ
Copilot Business/Enterprise、固定モデルを使うワークフロー、社内標準モデルを設定しているチーム。
具体的な使用例
社内のCopilot設定でGPT-5.6 Terraを明示的に許可・指定しているなら、11月16日前にGPT-6.1 SolまたはLunaで同じ仕事を試し、品質と利用量を比較する。
試し方
①Copilotのモデル設定を開く ②Claude Opus 4.8／5、GPT-5.6 Terraを使っていないか確認 ③推奨モデルを有効化 ④同じ代表タスクを新モデルで試す。
料金・制限・罠
モデル変更で回答品質だけでなく速度、トークン量、課金が変わる可能性がある。「後継だから完全互換」とは考えない方がいい。なお年間契約の個人Copilot利用者についてはClaude Opus 4.8の例外がある。
検証するとどこまで本当？
廃止日、対象モデル、推奨代替モデル、年間個人契約の例外はGitHub公式Changelogで確認済み。
情報源：GitHub Changelog「Upcoming deprecation of selected GitHub Copilot models in mid-November」（2026年10月15日）
結月硝子一言：クラウドAIで一番忘れられやすいのが「モデルは設備ではなく借り物」という事実。昨日動いた名前が永遠に存在する保証はない。自動化するほどモデル名を設定から切り離した方がいい。
5. AIコーディングツールが「コードを書く道具」から、資料作成・調査・業務処理へ広がっている
情報の確度：確認済み。ただしOpenAIの事例紹介を含む 難易度：考え方は今日から使える
何が話題？
OpenAIが10月15日に公開したAmpの事例では、AIエージェントをコード生成だけでなく、調査、文章作成、複数工程の業務処理へ広げている。GPT-6 Astra、Ultrafast、GPT-Live-1などを仕事ごとに使い分ける構成で、「AIコーディングエージェント」という分類そのものが薄くなっている。
つまり何ができる？
Codexや類似エージェントを「Pythonを書く時だけ開くもの」と考えず、ファイル群の調査、CSV変換、資料生成、ログ解析、Web情報との照合など、“PC上で複数工程を踏む仕事”へ使える。
こんな人に役立つ
Excel、CSV、PDF、ログ、Web検索、資料作成を行き来する人。プログラマーでなくても対象になる。
具体的な使用例
「フォルダ内の30個のExcelを確認→列名を統一→異常行を抽出→結果をCSVへ保存→処理内容をREADMEへ記録」のような仕事を、コードそのものではなく最終成果物を指定してエージェントへ渡す。
試し方
①普段Pythonで部分的に自動化している仕事を1つ選ぶ ②コードを書け、ではなく完成条件を書く ③入力ファイル、出力形式、触ってはいけないものを指定 ④エージェントに作業計画を立てさせてから実行 ⑤成果物とログを人間が確認する。
料金・制限・罠
自由度を上げるほど事故範囲も広がる。削除、メール送信、外部アップロード、Git pushなど不可逆操作は人間承認を残す方がいい。またOpenAIの記事は顧客事例なので、性能評価は宣伝要素を差し引いて読む必要がある。
検証するとどこまで本当？
AmpがOpenAIの複数モデルを組み合わせ、エージェント用途をコード外へ広げていることはOpenAI公式事例で確認できる。ただし「どの会社でも同程度の生産性向上が出る」という証拠ではない。
情報源：OpenAI「Amp puts AI agents to work beyond code with OpenAI models」（2026年10月15日）
結月硝子一言：ここ数か月でCodex系ツールの境界がかなり崩れた。「コードを書かせるAI」ではなく「PC上の仕事を、必要なら勝手にコードを書いて片付けるAI」と考えた方が実態に近い。
今日の観測
今日の共通点は、AI活用が「一番賢いモデルを選ぶゲーム」から「仕事をどう分割し、どのモデル・権限・検証工程へ割り振るか」という設計問題へ移っていること。
GPT-6はSolとLunaで能力と費用を分ける。GitHubはSlackから複数リポジトリを横断させる。一方でAI Scanのように、AIが作った成果物を別工程で疑う仕組みも増えている。そしてモデル自体は数か月で廃止される。
つまり今後強いのは「GPT-6を使っている人」ではなく、モデルを交換可能な部品として扱える人。
入力 → 軽量AIで整理 → 高性能AIで判断 → 別の検査で確認 → 人間が承認
この構造にしておけば、Lunaがもっと安いモデルへ置き換わっても、Solより賢いモデルが出ても、作業手順そのものは残る。
今日ひとつだけ試すなら
普段AIへ頼んでいる仕事を1つだけ「軽い処理」と「難しい判断」に分解する。
所要10分程度。
①最近ChatGPTやCodexへ丸ごと投げた仕事を1つ選ぶ ②分類・整形・抽出・要約など機械的な工程を抜き出す ③そこだけ高速・低価格モデルで実行する ④判断が必要な部分だけ高性能モデルへ渡す ⑤全部を高性能モデルで処理した場合と、時間・手戻り・品質を比較する。
AI利用料を下げる一番単純な方法は、プロンプトを一文字ずつ削ることではない。高い頭脳が必要ない仕事に、高い頭脳を呼ばないこと。
会社で部長にコピー取りをさせないのと同じ。もっともAIの場合、部長は文句を言わないので、人間側が気付かないままコピー代が燃える。