ChatGPT on KnightLiブログ

Google I/O後、GPTとGeminiのサブスクリプションはどちらを選ぶべきか？一般ユーザーと開発者向け比較

Thu, 21 May 2026 08:33:14 +0800

Google I/O 2026の後、AIサブスクリプションの選び方はかなり複雑になりました。

以前は比較的単純でした。文章作成、質問応答、プログラミング、ファイル分析なら、多くの人はまずChatGPTを検討し、Google Search、Android、Gmail、Docs、YouTubeを深く使う人だけがGeminiを考える、という流れでした。しかし今は違います。GoogleはI/OでGemini 3.5 Flash、Gemini Omni、Antigravity 2.0、Gemini API Managed Agents、Google AI Studio、AI Ultraをまとめて打ち出し、Geminiエコシステムは「選択肢の一つ」から「強い競争軸」へ変わり始めています。

この記事では抽象的なモデルベンチマークではなく、実際の問いに答えます。一般ユーザー、開発者、コンテンツクリエイター、企業ユーザーは、GPT / ChatGPTとGemini / Google AIのどちらを契約すべきなのでしょうか。

注意：AIサブスクリプションの価格、利用枠、地域、モデル提供状況はすぐ変わります。この記事の執筆日は2026年5月21日です。契約前にはOpenAIとGoogleの最新ページを確認してください。

まず結論

主力サブスクリプションを一つだけ選ぶなら、次の考え方で十分です。

日常的な文章作成、質問応答、ファイル分析、一般的なオフィス作業、中国語と英語の混在利用：ChatGPT Plusを優先。
高頻度のコーディング、Codex、複雑な推論、プロジェクト単位のコード作業：ChatGPT Plus / Proを優先し、利用枠に応じてアップグレードを判断。
Gmail、Docs、Drive、Android、SearchなどGoogleエコシステムを深く使う：Gemini / Google AI Proを優先。
動画、AI映像、Google Flow、YouTube Shorts、Gemini Omniが中心：Google AI Pro / Ultraを優先。
Antigravity、Gemini API Managed Agents、AI StudioからAndroidへのワークフローが必要：Google AI Pro / Ultraを重点的に見る。
企業チーム：個人向けプランだけで判断せず、Business / Enterprise、Workspace、権限、監査、データ境界を見る。
予算が限られる場合：主力の有料プランを一つ契約し、もう一方は無料枠または従量課金APIで使う方が、二つの上位プランを同時契約するより現実的。

一言でいえば、GPTは汎用生産性とコード支援の主力であり、Google I/O後のGeminiはGoogleエコシステム内のシステム級AIスイートに近づいています。

Google I/O後、Geminiは何が変わったか

Google I/O 2026によって、Geminiの価値はGemini App単体だけでは決まらなくなりました。

重要な変化は次の通りです。

Gemini 3.5 Flash：promptからactionまでの高速モデルとして位置づけられ、実際のAgentワークフローを意識している。
Gemini Omni：任意の入力からコンテンツを作成し、現時点では動画を起点に、多モーダル作成と自然言語による反復編集を支える。
Google Antigravity 2.0：開発者向けのagent-first development platformで、複数Agentの編成とコーディングを扱う。
Gemini API Managed Agents：API経由で、推論、ツール利用、コード実行ができるホスト型Agentを作成できる。
Google AI Studio：prompt playgroundから、モバイル、Androidネイティブアプリ生成、Antigravityプロジェクト出力へ広がっている。
Google AI Ultra：I/O後に追加された月額$100のプランで、開発者、技術責任者、知識労働者、高度なクリエイターを対象にしている。

さらに重要なのは、GoogleがGemini Appの利用枠を従来の日次prompt制限からcompute-usedモデルへ移行したことです。複雑な動画、コード、長文コンテキストのタスクは多くの枠を消費し、単純なテキストタスクは少なく済みます。枠は5時間ごとに更新され、週次制限に達するまで使えます。

これは、GoogleがGeminiのサブスクリプションを「モデル + アプリ + クリエイティブ + 開発ツール + Googleエコシステム」の入口として作ろうとしていることを示しています。

ChatGPT / GPTは誰に向いているか

ChatGPTの強みは今も大きく、AIを日常業務の主力として使う人に特に向いています。

OpenAIの現在の価格ページとヘルプ文書によれば、ChatGPT FreeではGPT-5.5 Instantなどの基本機能を利用できます。PlusではGPT-5.5 Thinking、より多いメッセージとアップロード枠、強化された画像生成、deep research、agent mode、Projects、Tasks、カスタムGPT、拡張されたCodex利用が提供されます。Proではさらに高い利用枠、GPT-5.5 Pro、より大きいCodex利用枠、最大級のdeep researchとagent modeが提供されます。

ChatGPTに向く場面は次の通りです。

文章作成、要約、翻訳、リライト。
複雑な質問応答と構造化分析。
ファイルアップロード、表計算分析、調査レポート。
プログラミングQ&A、コードレビュー、リファクタリング提案。
Codexによるリポジトリ作業。
多言語コンテンツ制作。
モデル品質と回答の安定性を重視しつつ、Google製品への依存が強くない場合。

一般ユーザーにとって、ChatGPT Plusは今も最も安定した主力サブスクリプションです。カバー範囲が広く、学習コストが低く、中国語と英語のタスクもバランスよく扱えます。

開発者にとって、ChatGPTの重要点はチャットだけではなくCodexです。OpenAIのヘルプ文書では、条件を満たすChatGPTプランでCodexを利用でき、利用枠はプランによって変わると説明されています。コード修正、PR、リファクタリング、テスト修正にCodexを多用するなら、サブスクリプション選びではCodex枠も一緒に考える必要があります。

Gemini / Google AIは誰に向いているか

Google I/O後、Geminiの強みはよりはっきりしました。Googleエコシステムとの結びつきが深いことです。

Google AIサブスクリプションは、Gemini App内のモデル枠だけではありません。Gemini Omni、Google Flow、Antigravity、AI Studio、一部のYouTube Premium / Lite特典、Workspace / Android / Searchエコシステムの機能も含みます。GoogleはAI Ultraを$100およびそれ以上の上位プランに広げ、開発者、技術責任者、知識労働者、高度なクリエイターを強調しています。

Geminiに向く場面は次の通りです。

Gmail、Docs、Drive、Sheets、Slides、Androidを深く使っている。
AIをGoogle Search、YouTube、Workspaceの中に入れたい。
Gemini Omni、Google Flow、動画生成、動画編集に関心がある。
Antigravity、Gemini API Managed Agents、AI Studio mobileを試したい。
超長文コンテキストで文書を理解したい。
Googleエコシステムアプリ、Androidネイティブアプリ、Workspace自動化を作る。

Googleのヘルプページによると、Gemini Appsのコンテキストウィンドウはサブスクリプションに応じて大きくなります。AI planなしでは32K、AI Plusでは128K、AI ProとAI Ultraでは1 millionです。AI Pro / Ultraでは、より高い利用制限、追加機能、一部の早期機能も提供されます。

仕事環境がすでにGoogleエコシステム内にあるなら、Geminiの価値は大きくなります。そうでなければ、Geminiを単に「もう一つのチャットボット」として契約する価値は、ChatGPTより安定して高いとは限りません。

一般ユーザーの選び方

一般ユーザーが陥りやすい失敗は、新モデル発表のたびに複数プラットフォームを同時契約することです。

より合理的な選び方は、主な利用場面から考えることです。

主に次のことをするなら：

記事を書く。
資料を調べる。
要約する。
PDFを読む。
メールを書く。
履歴書を直す。
言語を学ぶ。
日常的に質問する。

ChatGPT Plusを優先してください。汎用性が高く、タスクの境界が明確で、特定のエコシステムに深く縛られる必要がありません。

主に次のことをするなら：

Gmail / Docs / Drive / YouTube / Androidを高頻度で使う。
AIをGoogleエコシステムに直接入れたい。
Gemini App、Daily Brief、Google Search AI、YouTubeコンテンツQ&Aを試したい。
Googleドキュメントを長文コンテキストで読みたい。

Google AI Proを優先してください。

軽い利用だけなら、まず両方の無料枠を使い、明確な制限に当たってから有料化すれば十分です。「使うかもしれない」だけで上位プランを契約する必要はありません。

開発者の選び方

開発者は大きく二種類に分けられます。

第一のタイプは、コード質問、bug修正、スクリプト作成、リポジトリ読解が中心の人です。ChatGPT Plus / Pro + Codexを優先してください。

理由は次の通りです。

CodexとChatGPTアカウントがつながっている。
ChatGPTはコード説明、リファクタリング、テスト、エラー分析が安定している。
Plusで多くの日常開発タスクをカバーできる。
Proは高頻度、長時間、複雑なリポジトリ作業に向いている。

第二のタイプは、Googleエコシステム、Agentプラットフォーム、Android、Workspace、Gemini APIを中心に開発する人です。Google AI Pro / Ultraを優先してください。

理由は次の通りです。

Gemini 3.5 FlashはGoogle I/O後のAgentワークフローの重点モデル。
Antigravity 2.0はGoogleのAgent-first開発プラットフォーム。
Managed AgentsはAPI経由で、ツール付きかつ隔離Linux環境を持つAgentを作れる。
AI StudioはAndroid、Workspace、Antigravityと自然につながる。

フルスタック開発者にとって現実的な組み合わせは、多くの場合次の通りです。

ChatGPT Plusを日常のコードとドキュメントの主力にする。
Gemini無料枠またはAI ProをGoogleエコシステム、長文コンテキスト、動画/Agent新機能に使う。
APIは従量課金で使い、個人サブスクリプションを本番API予算と誤解しない。

コンテンツクリエイターの選び方

コンテンツクリエイターの選択は、何を作るかで決まります。

主に次のことをするなら：

コピー。
見出し。
台本。
記事。
画像付きコンテンツ。
資料整理。
多言語リライト。

ChatGPT Plusは今も安定しています。

主に次のことをするなら：

動画生成。
ショート動画のアイデア。
AI映像。
YouTube Shorts。
Google Flowワークフロー。
多モーダル素材の統合。

Gemini / Google AI ProまたはUltraに注目する価値があります。I/O後、Gemini OmniとGoogle FlowはGoogleのクリエイティブ領域での中心的なカードです。

予算が限られるなら、まずテキスト主力を一つ契約し、もう一方の無料枠や短期契約で動画機能を試すのがよいでしょう。動画モデルの利用枠、待ち時間、長さ、解像度、地域制限は変化が速いため、最初から長期の制作基盤として計画しない方が無難です。

企業とチームの選び方

企業は個人ユーザーの発想で選ぶべきではありません。

本当に見るべきなのは「今週どのモデルが強いか」ではなく、次の点です。

データが学習に使われるか。
SSO、MFA、RBACがあるか。
監査ログがあるか。
社内ナレッジ接続に対応するか。
プラグイン、コネクタ、Agent権限を制御できるか。
組織のコンプライアンス要件を満たすか。
既存のオフィススイートと連携できるか。

企業がすでにGoogle Workspaceを深く使っているなら、Geminiの企業向けプランは自然に評価対象になります。チームがすでにChatGPT、Codex、OpenAI API、社内ツールチェーンを中心にプロセスを作っているなら、OpenAI Business / Enterpriseの方が自然です。

エンジニアリングチームは、Codex、Antigravity、Gemini API Managed Agents、MCP、CI/CD、コード権限、リポジトリアクセス、監査も別途評価する必要があります。

Pro / Ultraが必要になるタイミング

多くの人は実際には上位プランを必要としていません。

ChatGPT Proが必要な典型的なサイン：

毎日長時間ChatGPTを使う。
Plusの利用枠がよく足りなくなる。
Codexを高頻度で使う。
deep research、agent mode、複雑な推論をよく使う。
GPT-5.5 Proのような上位モデルが必要。

Google AI Ultraが必要な典型的なサイン：

Gemini、Flow、Antigravityを高頻度で使う。
Gemini / Antigravityのより高い利用枠が必要。
動画制作、AI映像、長文コンテキスト研究を行う。
Googleエコシステムと新機能の早期利用に深く依存している。
Gemini Spark、Project Genie、または上位サブスクリプション特典が必要。

毎日数回質問する、たまに記事を書く、少しコードを直す程度なら、Plus / ProやAI Pro / Ultraは必須ではありません。

最も安く使う戦略

おすすめは次の組み合わせです。

まず主力の有料サブスクリプションを一つ選ぶ。
もう一方のプラットフォームは無料枠で使う。
APIが本当に必要になったら従量課金で使う。
動画、Agent、deep researchのような高消費機能は月単位でオン/オフし、年間で盲目的に契約しない。
毎月振り返る：本当に利用枠を使い切ったか。

よくある組み合わせ：

一般的なオフィス作業：ChatGPT Plus + Gemini無料枠。
Googleエコシステムユーザー：Google AI Pro + ChatGPT無料枠。
開発者：ChatGPT Plus/Pro + Gemini API/AI Studioを必要に応じて利用。
動画クリエイター：Google AI Pro/Ultra + ChatGPT無料枠またはPlus。
企業チーム：個人プランを寄せ集めず、Business / Enterprise / Workspaceプランを直接評価。

契約前チェックリスト

支払う前に、次の点を確認してください。

自分の地域で対象プランが使えるか。
必要なモデルがそのプランに含まれているか。
Codex、Antigravity、Flow、Omniが本当に使えるか。
動画機能に地域、年齢、待ち行列、解像度の制限があるか。
API呼び出しはサブスクリプションに含まれるのか、別課金なのか。
ファイルアップロード、コンテキストウィンドウ、agent mode、deep researchに制限があるか。
データプライバシー設定がプロジェクト要件に合うか。
Google One、Workspace、ChatGPT Business、学校/会社アカウントの特典をすでに持っていないか。

特に注意すべき点は、個人サブスクリプションはAPI無料、商用無制限、企業コンプライアンスを意味しないということです。

まとめ

Google I/O後、Geminiの競争力は明らかに強まりました。特に動画、多モーダル、Googleエコシステム、Android、AI Studio、Antigravityの領域です。一方で、ChatGPTは日常の文章作成、複雑な質問応答、ファイル分析、コード支援、Codexワークフローにおいて、今もより安定した汎用主力です。

最も簡単な判断は次の通りです。

迷うなら：まずChatGPT Plus。
Googleを深く使うなら：Google AI Pro。
高頻度の開発者なら：CodexとAntigravityのどちらが自分のワークフローに合うかを見る。
動画クリエイターなら：Gemini Omni、Flow、Google AI Pro / Ultraを優先して確認。
企業ユーザーなら：モデルの話題性ではなく、コンプライアンス、権限、監査、既存オフィスエコシステムで選ぶ。

AIサブスクリプションは多ければよいわけではありません。本当にコスト効率がよいのは、主力ワークフローを一つ決め、他のプラットフォームを補助として使うことです。発表会のたびに長期サブスクリプションを増やす必要はありません。

参考情報：

AI Agentはどう進化したのか？2022-2026年の5世代を整理する

Sat, 16 May 2026 19:19:52 +0800

AI Agentは一夜で生まれたものではありません。

2022年末、ChatGPTはまだ会話できるウィンドウに近い存在でした。2026年になると、Agentはツール呼び出し、ファイル操作、コンピューター制御、長期記憶、リモート協業、常駐実行に近い能力を持ち始めています。4年間で、質問に答えるモデルから、タスクを前に進めるデジタルワーカーへ近づきました。

時系列で見ると、AI Agentは大きく5世代に分けられます。各世代は前の世代の欠点を解決しながら、新しいバブルと安全上の課題も生みました。

概観：5世代のAgentタイムライン

段階	時期	キーワード	能力の変化	主な問題
第0世代	2022年末 - 2023年初	チャット画面	テキスト生成はできるが行動できない	モデルと現実世界が切断されている
第1世代	2023年中頃 - 2023年末	ツール呼び出し	構造化呼び出し、APIとRAG接続	開ループ実行とタスク迷走
第2世代	2023年末 - 2024年	工程化ワークフロー	計画、状態、反省、複数Agent協業	ワークフローがコピーされやすい
第3世代	2024年 - 2025年	Computer Use	画面を見てGUIを操作	権限、安全、誤操作リスク
第4世代	2025年 - 2026年	MCP / Skills / 常駐	ツールネットワーク、長期文脈、専門スキル	常駐実行でリスク半径が拡大
第5世代予測	2026年以降	閉ループと世界モデル	記憶、検証、物理行動の強化	ガバナンスがさらに難しくなる

2022年末：第0世代、ChatGPTチャット画面の時代

第0世代の起点は、2022年11月30日のChatGPT公開です。

この世代はまだ本当のAgentとは言えません。自然言語生成は強力でしたが、主にチャット画面の中に閉じ込められていました。Pythonコードを書くことはできても、あなたのPCで実行できない。旅行計画は作れても、サイトを開いて予約できない。ファイルの直し方は説明できても、ファイルシステムに入って変更できない。

能力の境界は明確でした。

自然言語を理解できる
記事、回答、コード、計画を生成できる
最新データに自分でアクセスできない
企業内部資料を安定して読めない
外部アクションを実行できない
長期タスク状態を管理できない

第0世代の核心は、モデル能力と現実世界の断絶でした。考えて話すことはできるが、行動できない。

この段階では、プロンプトエンジニア、プロンプトテンプレート市場、講座、認定といった最初のバブルも生まれました。初期モデルがpromptに敏感だったのは事実ですが、市場は一時的な補助を長期的な堀と誤解しました。

その後、GPT-4級モデル、system prompt、function calling、製品側の標準導線が成熟し、多くのプロンプトテンプレートは希少性を失いました。このパターンは繰り返されます。新能力が出ると中間層が爆発し、次世代システムがその能力を内蔵すると中間層は蒸発します。

2023年中頃：第1世代、ツール呼び出しの覚醒

第1世代のキーワードはツール呼び出しです。

2023年6月、OpenAIはfunction callingを公開しました。開発者は関数名、用途、引数型、JSON Schemaをモデルに説明できます。モデルはユーザーの要求を理解したうえで、通常の自然言語ではなく構造化JSONを出力し、外部システムがそれを実行します。

これは大きな構造変化でした。モデルは「話すだけの脳」から、外部ツールを動かす脳へ変わり始めました。

第1世代の能力は次の通りです。

ユーザー意図に応じてツールを選ぶ
構造化引数を出す
外部APIを呼び出す
API結果をモデルに戻して推論を続ける
RAGで外部知識に接続する
プラグインや知識ベースで初期personaを作る

同時期にRAGとベクトルデータベースも流行しました。モデルが最新情報、企業固有資料、内部知識を知らない問題を補うため、関連文書を検索し、文脈に注入して回答させる方式です。

この頃、Agentの基本構造が見えてきました。

あなたは誰か：system promptとpersona
何を知っているか：知識ベース、RAG、私有文書
何ができるか：function calling、プラグイン、外部API

代表的なバブルはAutoGPTです。ユーザーが大きな目標を与えると、AIがタスク分解、検索、ファイル作成、評価、ループを行い、自分で完了判断するという魅力的な構想でした。

しかしAutoGPTはすぐに問題を露呈しました。状態制約、終了条件、信頼できるフィードバックが不足し、間違った方向に進み続けたり、誤ったAPI引数を繰り返したり、大量のAPIコールでコストを燃やしたりしました。第1世代の教訓は明確です。ツールと無限ループだけでは、本番品質のAgentにはなりません。

2023年末から2024年：第2世代、工程化ワークフロー

AutoGPTの失敗は、モデルの自由行動だけに頼れないことを業界に示しました。複雑なタスクには構造化されたプロセスが必要です。

第2世代のキーワードは工程化ワークフローです。Agentは単発のモデル呼び出しではなく、状態、制御フロー、評価を持つソフトウェアシステムになりました。

主な能力は次の通りです。

タスク計画：大きな目標をステップに分解
状態管理：作業がどこまで進んだかを記録
反省と修正：生成後に評価し、修正する
ツール編成：複数ツールを切り替える
人間の確認：重要な節目で人に確認する
複数Agent協業：異なる役割に分担させる

典型例はReAct、つまりReasoning + Actingです。モデルが推論し、ツールを呼び出し、観察結果を受け取り、次の推論に進みます。Agentは盲目的に動かず、各ステップに監査可能な論理とフィードバックを持ちます。

第2世代の価値は、モデル能力を制御可能なプロセスに入れたことです。よく設計されたworkflowは、単発の大規模モデル呼び出しよりも安定した成果を出すことがあります。

一方で、低コードAgentプラットフォームのバブルも生まれました。ドラッグ&ドロップでprompt、RAG、プラグイン、フローを組み合わせるツールは構築の敷居を下げました。しかし、ワークフローが低コストでコピーできるなら、プラットフォーム自体の堀は弱いです。

早期需要を取れることと、長期的な壁を持つことは別です。

2024年から2025年：第3世代、Computer Useが実画面に入る

第3世代のキーワードはComputer Useです。

以前のツール呼び出しは主にAPIに依存していました。何ができるかは開発者が何を接続したかに依存します。しかし現実のソフトウェアには、きれいなAPIがない、公開されていない、不完全である、といったものが多くあります。

Computer Useは、モデルが画面を見て、クリックし、GUIを操作できるようにします。汎用的なコンピューター画面そのものがツールになります。

主な能力は次の通りです。

画面内容の認識
ボタンのクリック、文字入力、ウィンドウ切り替え
Webとデスクトップアプリの操作
リポジトリの読解、ファイル編集、テスト実行
端末出力とエラーの確認
実際のエンジニアリング助手に近づく

これにより、Agentは「接続済みツールの呼び出し」から「人のようにソフトウェア画面を操作する」方向に進みました。coding agentも、プロジェクトを読み、コードを直し、テストを走らせ、エラーから修正する流れに近づきます。

しかし信頼境界も広がります。AIがPCを操作するなら、誤クリック、誤削除、誤送信があり得ます。Webページ、文書、UI文言による誘導もあります。prompt injectionは会話上の問題だけでなく、ファイル操作、権限、システム安全の問題になります。

第3世代の教訓は、実操作に近づくほど、サンドボックス、承認、ロールバック、最小権限が必要になることです。

2025年から2026年：第4世代、MCP、Skills、常駐デジタルワーカー

第4世代のキーワードは、常駐、接続、記憶、専門化です。

この世代の焦点は、単発タスクの強化だけではありません。Agentは長期文脈、ツールネットワーク、専門スキル、時間感覚を持ち始めます。一回のチャット内の助手ではなく、継続して働けるデジタルワーカーに近づきます。

MCPはツール接続の問題を解きます。ファイルシステム、データベース、ブラウザ、設計ツール、プロジェクト管理ツール、企業システムを標準化された方法で接続できます。プロトコルが安定すると、単なるツール接続中間層は圧縮されます。

Skillsは専門的方法の問題を解きます。ツールはAgentに何ができるかを伝え、Skillsはどう進めるべきかを伝えます。良いskillはpromptではなく、領域の手順、制約、チェック方法、落とし穴、ツール呼び出し順をまとめたものです。

第4世代の能力は次の通りです。

長期記憶：ユーザー嗜好、プロジェクト規則、履歴を保存
プロジェクト文脈：リポジトリ、文書、作業規約を理解
ツールネットワーク：MCP、API、ブラウザ、ファイルシステムで外界に接続
専門スキル：Skillsでタスク手法をパッケージ化
常駐実行：待機、起床、通知、追跡
リモート協業：別デバイスから承認や方向修正が可能

この世代のAgentは「従業員らしさ」を持ち始めます。役割と責任境界、長期文脈、専門的な作業方法、時間感覚、ツール権限、無人時の継続実行です。

しかし能力が従業員に近づくほど、リスク半径も従業員に近づきます。常駐、ローカルデータ読み取り、秘密情報、ツール呼び出し、タスク処理により、安全問題は中心課題になります。

特に重要なのは、テキストも攻撃面であることです。AgentがMarkdown、説明文書、skill pack、Webページを読んで従うなら、悪意あるテキストが行動を変える可能性があります。prompt injectionは、サプライチェーン、権限、実行安全の問題になります。

第4世代の教訓は、常駐Agentには能力だけでなくガバナンスが必要だということです。

2026年以降：第5世代予測、閉ループ、内在記憶、世界モデル

第5世代はまだ確定した歴史ではありません。前の4年の流れからの予測です。

成熟したAgentには少なくとも3つの閉ループが必要です。

実行ループ：各操作後に結果を検証し、必要ならロールバック、修正、再試行する
時間ループ：複数の起床周期をまたいで長期目標を追跡する
認知ループ：確実な情報、推測、古い情報を区別する

次の方向は内在記憶です。これまでの記憶は、RAG、ベクトルDB、会話履歴、ローカルファイル、memory.mdのようにモデル外部にありました。将来のモデルが会話をまたいだ持続状態を持つなら、Agentの記憶システムは再設計されます。

第三の方向は世界モデルです。現在の多くのAgentは、観察、反応、再観察という反応型です。高リスクな作業では、行動の結果を事前にシミュレートする力が必要です。

第四の方向は具身化です。これまでの世代は主にデジタル空間で進化しました。API、画面、ファイル、ブラウザ、企業ツールです。次は、ロボット、デバイス制御、産業システム、物理インターフェースへ広がる可能性があります。

第5世代が解くべき問題は、Agentがタスクを実行するだけでなく、行動結果を理解し、長期状態を管理し、大きなリスク半径の中で信頼性を保つことです。

このタイムラインの背後にある6つの法則

第一に、基盤モデル能力は依然として天井です。Agentは大規模モデルの外にある魔法ではなく、モデル能力を工程システムで解放する方法です。

第二に、工程化された構造はモデル能力を増幅します。計画、検証、反省、修正、評価、権限管理は、単発生成よりも納品可能な結果に近いです。

第三に、オープンプロトコルは価値分配を変えます。MCP、Skills、プロジェクト文脈の標準が安定すると、競争はツール接続から領域能力の蓄積へ移ります。

第四に、Agent進化の隠れた主線は人間と機械の信頼境界の拡大です。テキスト、API、ワークフロー、PC操作、常駐実行へと、各世代でリスク半径が広がります。

第五に、各世代の事故は次世代の規則になります。AutoGPTの無限ループは構造化編成を促し、vibe codingの失敗は評価駆動開発を促し、本番削除事故は最小権限とサンドボックスを促します。

第六に、Agentエコシステムは爆発と絶滅を繰り返します。能力更新は一時的な中間層を作り、モデルやプラットフォームの内蔵化がそれを消します。時間窓を堀と誤解するのは危険です。

本当の堀

AI Agent領域の本当の堀は、新しい能力を最初に包装することではありません。

より信頼できる堀は3つです。

第一に、垂直領域の深さ。業界の流れ、リスク、例外、責任境界を本当に理解しているか。

第二に、データフライホイール。実利用から高品質なフィードバックを集め、プロセス、評価、微調整、製品判断を改善できるか。

第三に、ユーザー信頼。ユーザーが高価値で長期的、リスクのある仕事を任せるか、一回限りのツールとして扱うか。

プラットフォームや基盤モデルに能力が吸収された後も、プロセス、フィードバック、責任境界、信頼が残る製品だけが生き残りやすいです。

最後に

2022年から2026年までのAI Agent進化は、「モデルが会話上手になった」話ではありません。「人間がAIに任せる仕事が増えた」話です。

成熟したAgentとは、最も大胆に自動実行するシステムではありません。いつ実行し、いつ検証し、いつ止まり、いつ人に確認するかを知るシステムです。

あるAgent製品に長期価値があるかを判断するなら、こう問うべきです。次のモデルやプラットフォームがその能力を内蔵した後、何が残るのか。

答えが領域プロセス、実データ、検証可能な結果、ユーザー信頼なら、長期価値があるかもしれません。

Codexのモバイルリモートアクセス：ChatGPT AppでMac上の開発タスクを追跡する

Sat, 16 May 2026 17:42:40 +0800

OpenAIは2026年5月中旬、Codex remote accessをChatGPTモバイルアプリに追加しました。これはスマートフォンでコードを書く機能ではなく、Mac上で動くCodexをスマートフォンから追跡・操作するための機能です。

Codexは引き続きMac上でプロジェクトを読み、コマンドを実行し、ファイルを編集し、テスト結果を確認します。スマートフォン側は進捗確認、質問への回答、追加指示、操作承認を担当します。

できること

OpenAIのCodex remote connectionsドキュメントによると、モバイルアクセスでは次のことができます。

ホスト上のプロジェクトで新しいthreadを開始、または既存threadを継続
追加指示の送信、質問への回答、作業方向の調整
コマンドやその他の操作の承認
出力、diff、テスト結果、端末出力、スクリーンショットの確認
Codexの完了や注意が必要なタイミングで通知を受信
接続済みホストとthreadの切り替え

単なる小さなチャット画面ではなく、Codexの作業コンテキストに接続するモバイル操作面です。

必要条件

同じChatGPTアカウントとworkspaceでCodexを使える必要があります。スマートフォンには最新版のChatGPT Appが必要で、iOSとAndroidに対応します。

ホストは現時点ではMacです。Macは起動中、オンライン、Codex App実行中で、同じアカウントとworkspaceにログインしている必要があります。モバイル設定とデバイス制御には現在Codex App for macOSが必要で、Codex CLIやIDE Extensionからは設定できません。

MFA、SSO、passkeyが必要なアカウントでは、セットアップ中にその認証を完了する必要があります。ChatGPT workspaceでは、管理者がRemote Control accessを有効にする必要がある場合もあります。

制限

第一に、現在はmacOS hostが必要です。スマートフォンが接続するのはMac上のCodex Appであり、Codex CLI、IDE Extension、Linux / Windows開発機に直接接続するわけではありません。

第二に、ホストはオンラインでなければなりません。Macがスリープしたり、ネットワークを失ったり、Codex Appを閉じたりすると、リモートセッションは切断される可能性があります。

第三に、接続はQRコードのセットアップに依存します。Mac側でSet up Codex mobileを開き、スマートフォンでQRコードを読み取り、ChatGPTで連携を完了します。

第四に、遠隔操作にも承認フローがあります。端末コマンド、ファイル変更、テスト実行、外部アクセスに関わる操作は、内容を確認してから承認すべきです。

接続方法

MacでCodexを開きます。
サイドバーでSet up Codex mobileを選びます。
Codexがこのホストのリモートアクセスを有効化し、QRコードを表示します。
スマートフォンでQRコードを読み取り、ChatGPTのセットアップ画面に進みます。
同じChatGPTアカウントとworkspaceであることを確認します。
必要なMFA、SSO、passkeyを完了します。
成功すると、スマートフォンのCodexにMacが表示されます。

接続後はMac側のSettings > Connectionsで接続済みデバイスを管理できます。コンピューターをスリープさせない設定、Computer Use、Chrome extensionもここで確認できます。

スマートフォンでやるべきこと

スマートフォンに向いているのは、承認、方向修正、結果確認です。Codexがコマンド実行を求めたときに承認し、誤解やテスト失敗があれば短い指示で修正し、diffやテスト出力を確認できます。

価値があるのは「スマートフォンで開発する」ことではなく、ホスト上で動く開発タスクの携帯用コントローラーになることです。

よくある問題

ホストが表示されない場合は、MacでCodex Appが動いていること、Allow other devices to connectが有効であること、同じChatGPTアカウントとworkspaceを使っていることを確認します。

承認リクエストが表示されない場合は、ChatGPTモバイルアプリでCodexを開き、再度QRコードを読み取るか、ホスト側からセットアップをやり直します。workspaceでは管理者設定も確認します。

リモートセッションが切れる場合は、Macがスリープしていないか、ネットワークが切れていないか、Codex Appを閉じていないかを確認します。

向いている場面

長いCodexタスクをよく走らせる、席を離れても承認したい、複数のプロジェクトやthreadを扱う、Macを主開発機として使っている人に向いています。

WindowsやLinux中心、Codex CLIやIDE Extensionだけを使う、スマートフォンだけで完全な開発環境を期待する場合には向きません。

まとめ

Codexのモバイルリモートアクセスは、開発をスマートフォンに移す機能ではありません。Codexが止まりがちな承認、質問、テスト失敗、方向確認を、ChatGPT Appから処理できるようにする機能です。

Mac上でCodexをよく使う人には有用です。たまにコードの質問をするだけなら、効果はそれほど大きくありません。

参考資料

ChatGPT File Libraryとは：ファイル保存、容量制限、プライバシー境界

Sat, 16 May 2026 17:40:14 +0800

ChatGPT File Libraryは、ChatGPT内のファイルライブラリです。

以前は、会話にアップロードしたファイルはそのチャットで使う一時的な資料に近いものでした。File Libraryでは、アップロードしたファイルやChatGPTが作成したファイルをアカウントに保存し、後から探す、ダウンロードする、削除する、新しい会話で再利用するといったことができます。

これにより、ChatGPTは一時的なチャット画面ではなく、継続的な資料ワークスペースに近づきます。

保存されるファイル

ChatGPTは、アップロードまたは作成した次のようなファイルを保存できます。

文書
スプレッドシート
プレゼンテーション
PDF
画像
ChatGPTが生成したファイル

生成画像は引き続きImagesタブにも表示されます。File Libraryは、アップロードファイルと生成ファイルをまとめて管理する場所です。

PDF分析、表計算、文書作成、プレゼン資料の編集をよく行うなら、同じファイルを何度もアップロードする手間を減らせます。

新しい会話で使う方法

対応クライアントでは、入力欄付近の添付または追加メニューからAdd from libraryを選び、再利用したいファイルを選択します。

Release Notesでは、LibraryとRecent filesがWeb、iOS、Androidで利用できることも説明されています。

検索と管理

Web版では左サイドバーからLibraryに入り、アップロード済みファイルと生成済みファイルを管理できます。

ファイルは種類や由来で絞り込めます。ヘルプページでは、アップロードファイル、生成ファイル、画像、文書、スプレッドシート、プレゼンテーション、PDFなどのフィルターが挙げられています。

ストレージ使用量はSettings > Storageから確認できます。ファイルはLibraryから直接削除できます。

プラン別容量

2026年5月14日のRelease Notesでは、容量は次のように示されています。

プラン	File Library容量
Free	500 MB
Go	4 GB
Plus	20 GB
Business	20 GB
Pro	100 GB

この容量には、アップロードしたファイルとChatGPTが作成した文書、表、プレゼン、画像が含まれます。

単一ファイルの制限

OpenAIのヘルプページでは、次の制限が示されています。

GPTまたはChatGPT会話にアップロードするファイルは最大512 MB
テキスト・文書ファイルは最大200万token
CSVやスプレッドシートは通常約50 MB、行の大きさに依存
画像は1枚最大20 MB

これはアカウント全体の容量とは別の制限です。

削除とダウンロード

ファイルは手動で削除するまでアカウントに保存されます。

Libraryでファイルを選択し、削除またはゴミ箱アイコンを使います。OpenAIの説明では、削除後はアカウントからすぐに取り除かれ、通常30日以内にOpenAIのシステムから完全削除される予定です。ただし、匿名化済みでアカウントと切り離されている場合や、安全・法的義務で保持が必要な場合は例外があります。

ファイルはLibraryからダウンロードすることもできます。

Temporary Chatでは保存されない

Temporary Chatでアップロードしたファイルは、アカウントやLibraryに保存されません。

File Libraryは長期再利用のための機能で、Temporary Chatは一時的・機密性の高い・長期文脈を残したくない作業に向いています。

データとトレーニング設定

OpenAIのヘルプページでは、ファイルとチャットはユーザーの設定とData Controlsに従うと説明されています。

Memoryが有効な場合、ファイルやチャットが会話間で役立つ情報の記憶に使われる可能性があります。個人向けサービスでImprove the model for everyoneが有効な場合、アップロードファイルを含むChatGPTへの送信内容がモデル改善に使われる可能性があります。この設定はSettings > Data Controlsでオフにできます。

File Libraryはローカルフォルダーではなく、クラウドアカウント機能です。アップロードしてよい資料かどうかを先に考える必要があります。

向いている使い方

同じPDFやレポートの継続分析、授業資料や会議資料の再利用、ChatGPTが生成した文書や表の再編集、複数会話での素材共有に向いています。

一方で、身分証明、契約書、医療記録、財務明細などの機密資料、正式なクラウドバックアップ、社内文書の無確認アップロードには向きません。

まとめ

ChatGPT File Libraryの価値は、単にファイル一覧が増えたことではありません。ChatGPTを一回限りの会話ツールから、資料が蓄積するワークスペースへ変える点にあります。

その分、古いファイルの整理、容量確認、通常チャットとTemporary Chatの使い分け、Data Controlsの確認が重要になります。

参考資料

OpenAI の新世代 Realtime 音声モデル：GPT-Realtime-2、リアルタイム翻訳、ストリーミング文字起こし

Sat, 09 May 2026 10:58:47 +0800

OpenAI は 2026 年 5 月 7 日、新世代の Realtime API 向け音声モデルを発表しました。焦点は「より人間らしく話す」ことだけではなく、音声エージェントがリアルタイムの会話中に理解し、推論し、ツールを呼び出し、翻訳し、文字起こしできるようにすることです。

今回の更新には 3 つのモデルが含まれます。

GPT-Realtime-2：リアルタイム音声 Agent 向けの主力モデル。より強い推論、ツール呼び出し、長いコンテキストに対応します。
GPT-Realtime-Translate：70 以上の入力言語から 13 の出力言語へのリアルタイム音声翻訳モデル。
GPT-Realtime-Whisper：字幕、会議メモ、リアルタイムワークフロー向けの低遅延ストリーミング音声認識モデル。

初期の音声アシスタントが「一問一答」に近かったとすれば、今回の更新は「聞きながら作業する」音声インターフェースに近づいています。

GPT-Realtime-2：音声 Agent の主力モデル

GPT-Realtime-2 はリアルタイム音声対話向けに作られています。質問に答えるだけでなく、ユーザーが話し、言い直し、割り込み、条件を追加する間も文脈を保ち、必要に応じてツールを呼び出してタスクを完了します。

公式に強調されている機能は次の通りです。

「確認します」のような短い前置きを返し、処理中であることをユーザーに伝えられる。
カレンダー、検索、注文、サポートシステムなどの複数ツールを並行して呼び出せる。
失敗時の復帰がより自然で、会話が突然止まったり沈黙したりしにくい。
コンテキストウィンドウが 32K から 128K に拡大され、長い会話や複雑なタスクフローに対応しやすい。
専門用語、固有名詞、医療用語などの保持が改善されている。
冷静、共感的、確認的、明るいなど、場面に応じた話し方を制御しやすい。
reasoning effort は minimal、low、medium、high、xhigh から選択でき、デフォルトは low。

これにより、開発者は単純な Q&A だけでなく、より複雑な業務に音声 Agent を組み込めます。たとえば、サポート Agent がユーザーの説明を聞きながら注文を確認したり、旅行アプリがフライト変更に応じて次の行動を提案したり、不動産アプリが口頭条件から物件を絞り込んで内見を予約したりできます。

リアルタイム翻訳：多言語音声プロダクト向け

GPT-Realtime-Translate はリアルタイム音声翻訳向けのモデルです。ユーザーは自分の言語で話し、相手は翻訳された音声を聞きながらリアルタイムの文字起こしも確認できます。

適した用途は明確です。

多言語カスタマーサポート。
越境営業やプリセールス。
オンライン教育やライブイベント。
国際会議やイベント司会。
動画プラットフォームやクリエイターコンテンツのローカライズ。

リアルタイム翻訳の難しさは、正確さだけではありません。低遅延、自然な間、トーンの保持、アクセントへの対応、専門語彙の処理も必要です。OpenAI は、発話全体を待ってから翻訳するのではなく、より自然な異言語会話に近づけることを強調しています。

ストリーミング文字起こし：音声をすぐにワークフローへ

GPT-Realtime-Whisper は新しいストリーミング音声認識モデルです。録音が終わるのを待つのではなく、話されている最中に音声を処理可能なテキストへ変換できる点に価値があります。

主な用途は次の通りです。

会議のリアルタイム字幕。
授業や配信の字幕。
リアルタイム議事録。
音声 Agent への継続的な音声入力。
サポート、医療、採用、営業など高頻度の音声業務における後続処理。

プロダクト側では、ストリーミング文字起こしによって「話す」から「使えるテキスト」までの時間を短縮できます。字幕は早く表示され、会議メモは会話中に生成され、要約、タスク抽出、CRM 登録なども早く始められます。

価格と提供状況

3 つのモデルはいずれも Realtime API で利用できます。公式価格は次の通りです。

モデル	価格
`GPT-Realtime-2`	音声入力 $32 / 1M tokens、キャッシュ入力 $0.40 / 1M tokens、音声出力 $64 / 1M tokens
`GPT-Realtime-Translate`	$0.034 / 分
`GPT-Realtime-Whisper`	$0.017 / 分

OpenAI は Realtime API が EU Data Residency に対応し、エンタープライズ向けプライバシーコミットメントの対象であるとも述べています。欧州企業やデータ所在要件のある音声プロダクトでは、個別に評価すべき点です。

開発者にとっての意味

今回の発表で重要なのは、音声機能が単なる入出力層から、プロダクトの対話層へ移り始めていることです。

従来の多くの音声機能は、音声をテキストに変換し、テキスト応答を音声に戻すものでした。本当に難しいのは中間層です。ユーザー意図の理解、割り込み処理、文脈補完、ツール呼び出し、処理状況の説明、失敗時の自然な復帰が必要になります。

GPT-Realtime-2 はこの能力をリアルタイム音声モデル側に直接持たせようとしています。開発者が見るべきなのは単発の回答品質だけでなく、継続的な会話と多段階タスクを支えられるかどうかです。

優先的に試す価値があるプロダクトは次の通りです。

カスタマーサポート音声 Agent。
車載およびモバイル音声アシスタント。
旅行、予約、不動産、金融など、会話しながら検索や照会が必要なサービス。
多言語会議や越境コミュニケーションツール。
リアルタイム字幕、議事録、通話品質管理システム。

安全性と告知も重要

OpenAI は発表ページで、Realtime API には複数の安全対策が含まれると説明しています。たとえばセッションに対するアクティブ分類や、ポリシー違反が検出された会話の停止です。開発者は Agents SDK を使って独自のガードレールを追加することもできます。

見落としやすい要件として、エンドユーザーが AI と対話していることを明確に知らせる必要があります。ただし、文脈上それが明らかな場合は例外です。

これはサポート、営業、教育、医療などで特に重要です。音声が自然になるほど、プロダクト設計上の境界も明確にする必要があります。ユーザーは自分が AI と話していること、どの操作が記録、文字起こし、ツール呼び出しにつながるのかを理解できるべきです。

まとめ

OpenAI の今回の Realtime API 更新は、リアルタイム音声を「聞いて話せる」段階から「聞きながらタスクを処理できる」段階へ進めるものです。

GPT-Realtime-2 は複雑な音声 Agent、GPT-Realtime-Translate は異言語間のリアルタイム会話、GPT-Realtime-Whisper は低遅延文字起こしを担当します。3 つを合わせると、音声プロダクトでよく必要になる会話、翻訳、文字起こしをカバーできます。

サポート、車載、会議、教育、越境コミュニケーション、モバイル音声アシスタントを作っているなら、この更新は重点的に試す価値があります。検証すべきなのは、自然に聞こえるかだけではなく、長い会話、割り込み、ツール呼び出し、失敗復帰、コスト管理でどう振る舞うかです。

参考リンク：

OpenAI：Advancing voice intelligence with new models in the API

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking、GPT-5.5 Pro の違い

Thu, 07 May 2026 21:59:33 +0800

OpenAI は現在、GPT-5.5 を Instant、Thinking、Pro という、より明確な利用階層に分けています。

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking、GPT-5.5 Pro は混同されがちです。簡単に言えば、GPT-5.5 はこの世代のモデル能力の総称です。Instant は日常向けの高速モデル、Thinking は深い推論モード、Pro はより重い研究級モードです。

早見表

名称	本質	向いている用途	速度/コスト	利用可能性
GPT-5.5	GPT-5.5 の主モデル/ファミリー名。ChatGPT では通常 GPT-5.5 Thinking の能力位置付けに近い	複雑な作業、コード、研究、分析、ツール利用	Instant より重いが、能力は高い	Plus、Pro、Business、Enterprise
GPT-5.5 Instant	GPT-5.3 Instant を置き換える高速デフォルトモデル	日常 Q&A、文章作成、要約、軽いコード、素早い調査	最速で、最もクォータ効率が良い	すべての ChatGPT ユーザーへ段階的に展開
GPT-5.5 Thinking	深い推論モード	難問、長文脈分析、複雑なコード、研究、文書密集タスク	遅めだが、推論が安定	有料ユーザーが手動選択可能
GPT-5.5 Pro	より高強度な研究級モード	高リスク/高精度タスク：法律、ビジネス、教育、データサイエンス、科学研究分析	最も遅く重いが、品質重視	Pro、Business、Enterprise、Edu

一つだけ覚えるなら次の通りです。

日常の高速タスク：GPT-5.5 Instant。
複雑な推論とコード分析：GPT-5.5 Thinking。
特に難しく重要で、より網羅的かつ厳密さが必要な作業：GPT-5.5 Pro。

GPT-5.5 とは何か

単独で GPT-5.5 と言う場合、通常は GPT-5.5 世代の主なモデル能力を指し、固定の一つのボタンを指すわけではありません。

OpenAI は GPT-5.5 を「実際の仕事に向いた、より強いモデル」と位置付けています。重点は次のような能力です。

agentic coding。
複雑なコードデバッグ。
研究と資料の統合。
文書、表計算、プレゼン資料の生成。
コンピュータ利用とツール横断作業。
長いタスクでの継続的推論と自己チェック。

ChatGPT では、ユーザーが見るのは曖昧な GPT-5.5 ボタンではなく、より具体的な Instant、Thinking、Pro です。そのため「GPT-5.5 を使っている」と聞いたら、Instant なのか、Thinking なのか、Pro なのかを確認した方がよいです。

GPT-5.5 Instant：デフォルト、高速、日常向け

GPT-5.5 Instant は新しい高速デフォルトモデルです。OpenAI の公式説明では、GPT-5.3 Instant を置き換え始め、ChatGPT のデフォルトモデルになり、API では chat-latest として提供されます。

向いているタスク：

日常会話。
素早い Q&A。
普通の文章作成。
記事の要約。
メールの書き換え。
軽いコード説明。
簡単な表やリスト。
長時間の推論を必要としないタスク。

Instant の主な利点は速度とデフォルト利用です。毎回手動で推論モードを選ぶ必要がなく、普通の質問に高い待ち時間を払う必要もありません。

もう一つの変化として、OpenAI は GPT-5.5 Instant の回答がより明瞭で簡潔になり、パーソナライズ能力も強くなったとしています。普通のユーザーにとっては、一日中開いておくモデルとして使いやすいということです。

注意点は、Instant が「最強モード」ではないことです。複雑な数学、長いコード、アーキテクチャ設計、複数ファイル分析、本格的な研究では、自動的に Thinking に切り替わることもあれば、手動で Thinking を選ぶ必要があることもあります。

GPT-5.5 Thinking：複雑タスクの主力

GPT-5.5 Thinking は、複雑なタスクに向いた推論モードです。

向いている場面：

コードデバッグ。
アーキテクチャ設計。
多段階推論。
長文書分析。
学術資料整理。
ビジネス案の検討。
データ分析の説明。
比較、トレードオフ、検証が必要なタスク。

Thinking はより多くの時間を使って推論します。OpenAI Help Center によると、GPT-5.5 Thinking または GPT-5.5 Pro が推論を開始すると、何をするつもりかを説明する短い preamble が表示されることがあります。モデルが thinking 中でも、ユーザーは追加指示を入れて方向を早めに調整できます。

ChatGPT で Thinking を手動選択する場合、thinking time も調整できます。公式説明では、Plus と Business ユーザーは Standard と Extended を使えます。Pro ユーザーには Light や Heavy など、さらに多くの選択肢があります。

私の理解では、Thinking は「本気で作業する」ための標準選択です。タスクが多段階、長文脈、高い正確性を必要とするなら、Instant より適しています。

GPT-5.5 Pro：研究級で、より重く、より厳密

GPT-5.5 Pro は、より難しい問題と高精度作業向けのモードです。

向いている場面：

法律資料分析。
ビジネス調査。
教育とカリキュラム設計。
データサイエンス。
科学研究資料の統合。
高リスク判断前の深いレビュー。
複数文書、複数制約、複数ラウンドの検証タスク。

OpenAI は GPT-5.5 の発表で、初期テスターが GPT-5.5 Pro について、GPT-5.4 Pro と比べて完全性、構造性、正確性、関連性、実用性が明らかに向上したと評価したと述べています。特にビジネス、法律、教育、データサイエンスで強いとされています。

Pro の欠点も明確です。遅く、重く、小さな質問すべてに使うものではありません。日常チャットの入口というより、専門家レビューや研究パートナーに近いものです。

また Pro にはツール対応の制限があります。OpenAI Help Center では、Apps、Memory、Canvas、画像生成は Pro では利用できないとされています。これらの ChatGPT 機能が必要な場合は、Instant または Thinking を使う方がよいかもしれません。

ツール対応の違い

OpenAI Help Center によると、GPT-5.5 Instant と GPT-5.5 Thinking は ChatGPT の一般的なツールに対応しています。

Web search。
Data analysis。
Image analysis。
File analysis。
Canvas。
Image generation。
Memory。
Custom Instructions。

GPT-5.5 Pro は研究級推論寄りですが、すべての ChatGPT ツールを使えるわけではありません。特に次に注意します。

Apps は利用不可。
Memory は利用不可。
Canvas は利用不可。
画像生成は利用不可。

つまりモデルを選ぶときは、「どれが賢いか」だけでなく、必要なツールも見る必要があります。

コンテキストウィンドウの違い

OpenAI Help Center が示す ChatGPT のコンテキストウィンドウは、おおよそ次の通りです。

モード	コンテキストウィンドウ
GPT-5.5 Instant	Free：16K；Plus/Business：32K；Pro/Enterprise：128K
GPT-5.5 Thinking	有料プランで手動選択した場合は通常 256K；Pro では最大 400K

つまり次のように考えられます。

普通の会話と短い文書なら Instant で十分。
複数ファイル、多ラウンド研究、長いコードベース分析なら Thinking が向く。
特に長く複雑で高精度なタスクでは、Pro ユーザーはより大きな文脈と重い推論を使える。

どう選ぶか

日常 Q&A

GPT-5.5 Instant を使います。

速く、十分賢く、気軽な質問、素早い文章作成、素早い修正に向いています。

記事作成、要約、メール修正

まず GPT-5.5 Instant を使います。

記事が長い、構造的な書き直しが必要、複数回の校正が必要な場合は、GPT-5.5 Thinking に切り替えます。

コード作成とデバッグ

簡単なコード説明は Instant で十分です。

複数ファイルのデバッグ、アーキテクチャ設計、複雑なエラー分析には Thinking を使います。非常に難しい長期的なエンジニアリング問題なら Pro も検討できます。

研究と資料分析

普通の資料整理には Thinking を使います。

法律、ビジネス、科学研究、データサイエンスのような高精度タスクでは Pro がより適しています。

画像生成、Canvas、Memory が必要な場合

Instant または Thinking を優先します。

Pro は一部の ChatGPT ツールに対応していないため、デフォルトで Pro を選ばない方がよいです。

短い結論

GPT-5.5 Instant は日常のデフォルトモデルです。速く、明瞭で、クォータ効率が良く、多くの普通のタスクに向きます。

GPT-5.5 Thinking は複雑タスクの主力です。コード、研究、長文書、分析、多段階推論に向きます。

GPT-5.5 Pro は高精度研究モードです。より難しく重要で、厳密さが必要なタスクに向きますが、速度とツール対応にはより制限があります。

GPT-5.5 そのものは、この世代の総称に近いものです。実際に選ぶときは、ChatGPT で Instant、Thinking、Pro のどれを選ぶかが重要です。

ChatGPT、Claude Code、Gemini の記憶機構は何が違うのか

Thu, 07 May 2026 14:47:17 +0800

AI 製品における「記憶」はますます重要になっている。これは AI が「単発の会話ツール」から「長期的な協力相手」へ移行していることを示している。毎回背景を説明し直す必要がなくなり、好みを繰り返し伝える必要もなく、同じプロジェクトを何度も理解させる必要も減る。

しかし、製品ごとの記憶は同じものではない。ChatGPT、Claude Code、Gemini はいずれも「AI がより長く覚える」問題を扱っているが、設計目標、保存場所、透明性、適用シーンは大きく異なる。

2026 年 5 月 7 日時点では、おおまかに3つに分けられる。

ChatGPT は「個人アシスタントの記憶」に近い。
Claude Code は「エンジニアリングプロジェクトの記憶」に近い。
Gemini は「Google エコシステムの文脈」に近い。

ChatGPT：人を中心にした長期的な好み

ChatGPT の記憶機構は主に個人協作向けだ。関心の中心は「あなたは誰か」「何を好むか」「長期的に何をしているか」にある。

OpenAI は現在、ChatGPT の記憶を saved memories と chat history に分けている。

saved memories は、ChatGPT が保存する重要情報だ。名前、好み、目標、よく使う技術スタック、文章の癖などが含まれる。ユーザーが明示的に覚えるよう頼むこともできるし、ChatGPT が会話の中から将来役立つと判断した情報を保存する場合もある。

chat history は、回答時に過去の会話を参照する仕組みだ。すべての会話がそのまま記憶になるわけではなく、必要に応じて過去の会話から関連文脈を探す。

つまり ChatGPT の中核ロジックは、同じユーザーを会話をまたいで理解することだ。

典型例は次のようなものだ。

「今後コード例はできるだけ簡潔にして。」
「私は主に Python と TypeScript を使っている。」
「AI ツールについての Hugo ブログを書いている。」
「先に結論を見て、その後に詳細を読むのが好き。」

これらの記憶は特定プロジェクトに紐づくものではなく、アカウントと個人の利用習慣についてくる。

Memory Sources：個人化の出所を見えるようにする

OpenAI は 2026 年 5 月の更新で Memory sources を強調した。

これは新しい記憶タイプではなく、ChatGPT が回答を個人化するときに参照した情報源をユーザーに見せる仕組みだ。OpenAI のヘルプ文書によると、Memory Sources には次のようなものが表示される場合がある。

過去のチャット。
保存された記憶。
カスタム指示。
ファイルライブラリ内のファイル。
接続済み Gmail のメール。

ファイルや Gmail の表示範囲は、プラン、地域、接続状態によって制限される。OpenAI はまた、Memory sources が回答に影響したすべての要因を表示するとは限らず、個人化の理解と管理を助けるものだと説明している。

これは重要だ。AI が「あなたを覚える」ほど、ユーザーは何に基づいて回答したのかを知る必要がある。そうでなければ個人化はブラックボックスになりやすい。AI が自分を知っているように見えるが、なぜ知っているのか分からない状態になる。

ChatGPT の強みは、会話やテーマをまたいで個人の好みを継続的に理解することだ。一方で、記憶が古くなったり、古い記憶がまだ回答に影響していることをユーザーが忘れたりするリスクもある。そのため saved memories と古いチャットは定期的に整理したほうがよい。

Claude Code：コードベースとエンジニアリングルールを中心に

Claude Code の記憶機構はエンジニアリング協作寄りだ。関心の中心は「ユーザーが普段何を好むか」ではなく、「このコードベースをどう変更すべきか」だ。

Claude Code には混同されやすい2種類の記憶がある。

明示的なプロジェクト記憶：CLAUDE.md。
自動プロジェクト記憶：Auto Memory。

CLAUDE.md は最も基本的で安定したプロジェクト記憶ファイルだ。プロジェクトルートにも、サブディレクトリにも置ける。Claude Code はこれらのファイルを読み、プロジェクト説明と作業ルールとして扱う。

CLAUDE.md に書くのに適した内容は次の通りだ。

よく使う build、test、lint コマンド。
コードスタイルと命名規則。
プロジェクトアーキテクチャ。
モジュール境界と危険な領域。
チームの約束事とコミットフロー。

CLAUDE.md をリポジトリに置けば、Git にコミットしてチーム共有の agent 説明書にできる。これは ChatGPT のクラウド上の個人記憶とはまったく異なる。

Claude Code Auto Memory：プロジェクト経験を自動で蓄積する

Claude Code には現在 Auto Memory もある。目的は、ユーザーが毎回手で説明を書かなくても、Claude が複数セッションにまたがってプロジェクト経験を自動的に蓄積できるようにすることだ。

Claude Code の文書によると、Auto Memory は作業中に Claude が自分用のメモを保存する仕組みだ。build コマンド、デバッグで分かったこと、アーキテクチャ説明、コードスタイルの好み、ワークフロー習慣などが対象になる。すべてのセッションで保存するわけではなく、将来役立ちそうな情報を判断する。

誤解されやすい点がある。Auto Memory はデフォルトでプロジェクトルートの .claude/memory.md に書くわけではない。公式文書では、各プロジェクトはユーザーディレクトリ配下に独自の memory ディレクトリを持つと説明されている。パスは次のような形だ。

`1`	`~/.claude/projects/<project>/memory/`

MEMORY.md は各会話開始時に最初の 200 行または 25KB が読み込まれ、詳細は別のトピックファイルへ分割される場合がある。Auto Memory ファイルはローカルの Markdown ファイルで、ユーザーは /memory から表示、編集、削除できる。

これにより Claude Code の記憶は「ローカル上のプロジェクト経験庫」に近くなる。ChatGPT の個人記憶よりコードベースに近く、単なる CLAUDE.md より動的だ。

ただし Auto Memory はローカルマシン上のものだ。リポジトリと一緒に他のマシンやクラウド環境へ自然に同期されるわけではない。チームで共有すべき安定したルールは、やはりプロジェクト内の CLAUDE.md に書くべきだ。

Gemini：Google エコシステムの文脈を中心に

Gemini の記憶ロジックはまた別だ。

Gemini にも保存情報と過去チャット参照の能力がある。Google のヘルプ文書では、ユーザーは生活、仕事、好みに関する情報を保存でき、Gemini は回答前に過去のチャットを参照できると説明されている。これらの情報を使うと、回答下部のソース領域に Your saved info や Previous chats が表示される場合がある。

しかし Gemini の差別化は「好みを数個保存する」ことだけではなく、Google エコシステム連携にある。

ユーザーが許可し、機能が利用可能な場合、Gemini は Gmail、Google Drive、Docs、Sheets など接続された Google アプリから文脈を取得できる。強みは、ユーザーが一つずつ教え込むことではなく、すでに Google アカウント内にある資料を検索可能な作業文脈にできることだ。

典型的な違いは次のようになる。

ChatGPT は「最近 LTO テープドライブを修理している」と覚える。
Gemini は Gmail から購入確認メールを見つけたり、Drive から修理メモを読んだりできる場合がある。

もちろん、Gemini が無条件で Google データすべてを読めるわけではない。アカウント種別、地域、権限、接続アプリ、Keep Activity 設定、具体的な製品提供状況に依存する。企業や学校アカウントでは、Google Workspace 管理者の制御も受ける。

より正確に言えば、Gemini の記憶は単純な「メモ帳」ではなく、「保存情報 + 過去チャット + Google エコシステム接続」の組み合わせだ。

3者の主な違い

次元	ChatGPT	Claude Code	Gemini
中心対象	人と好み	プロジェクトとコードベース	Google アカウントとエコシステム資料
典型的な記憶	好み、背景、長期目標	アーキテクチャ、コマンド、規約、デバッグ経験	saved info、過去チャット、Gmail/Drive/Docs 文脈
保存形態	OpenAI アカウント内の記憶とチャット文脈	`CLAUDE.md`、`MEMORY.md`、ローカル Markdown ファイル	Google アカウント活動、保存情報、接続アプリデータ
透明性	Memory sources で一部の出所が見える	Markdown ファイルを直接表示・編集できる	ソース表示、Gemini Apps Activity、Google 設定で管理
プロジェクト横断	強い。ユーザーアカウントに追従	弱い。主にプロジェクトまたはローカル project memory に追従	強い。Google 資料と権限に依存
チーム共有	直接共有には不向き	`CLAUDE.md` を Git で共有可能	主に Workspace と権限体系に依存
得意領域	個人の好みと長期アシスタント	長期コードプロジェクトと agent 協作	Google Workspace 資料検索とクロスツール作業

どう選び、どう使うか

AI に「自分は誰か、どんなスタイルが好きか、普段どう働くか」を覚えさせたいなら、ChatGPT の記憶が向いている。

文章スタイル、よく使う技術スタック、回答形式、職業背景、長期プロジェクトの方向といった個人の好みを保存するのに適している。重点は自己紹介コストを下げ、新しい会話を素早く始めることだ。

AI に「このコードベースをどう変えるか、どのコマンドが動くか、どの罠を避けるか」を覚えさせたいなら、Claude Code が向いている。

安定したルールは CLAUDE.md に書いてチーム共有する。動的な経験は Auto Memory に補助させる。重要な意思決定はローカル自動記憶にだけ残さず、文書や CLAUDE.md に整理するのがよい。

資料の多くが Gmail、Drive、Docs、Sheets にあるなら、Gemini のエコシステム文脈が有利だ。

過去メールの検索、Google Drive 文書の整理、カレンダーやオフィス資料との連携に向いている。Gemini を使うポイントは、チャット内で何度も思い出させることではなく、関連アプリの接続、権限、アクティビティ設定を正しくしておくことだ。

実用的な分担

3者は次のように分担できる。

ChatGPT は「自分の一般的な好み」を覚える。
Claude Code は「このリポジトリのエンジニアリング知識」を覚える。
Gemini は「Google エコシステム内の資料」を検索する。

つまり、ChatGPT は個人秘書、Claude Code はプロジェクト内のシニアエンジニア、Gemini は Google アカウント内の資料インデクサーに近い。

この3種類の記憶に絶対的な優劣はない。目的が違うだけだ。

最も注意すべきなのは混同することだ。個人の好みは必ずしもプロジェクト記憶に書くべきではない。プロジェクトアーキテクチャは必ずしもクラウド上の個人記憶に保存すべきではない。Google エコシステム検索は、モデルがあなたを長期的に本当に理解したことと同じではない。

短い判断

AI 記憶の次の段階は、単に「多く覚える」ことではない。記憶は階層化され、見えるようになり、制御可能である必要がある。

ChatGPT の重点は会話をまたいだ個人化、Claude Code の重点はコードプロジェクトの継続性、Gemini の重点は Google エコシステム文脈だ。本当に使いやすい長期 AI 協作は、すべての情報を一つのブラックボックスに詰め込むのではなく、異なる種類の記憶を適切な場所に置く。

個人の好みは個人記憶に、エンジニアリングルールはコードベースに、過去資料は元の文書やメールシステムに置く。AI がすべきことは、必要なときに正確にそれらの文脈を呼び出すことであり、すべてを一つに混ぜることではない。

ChatGPT Release Notes から見る OpenAI のプロダクトリズム

Thu, 07 May 2026 14:31:22 +0800

OpenAI の ChatGPT Release Notes は、ChatGPT のプロダクトリズムを観察する直接的な入口だ。このページは、ChatGPT のモデル、機能、アカウントセキュリティ、アプリ連携、クライアント体験の変化を継続的に記録している。

2026 年 5 月 7 日時点で見ると、ページ上部には最新更新が「yesterday」と表示され、最新項目は 2026 年 5 月 5 日に集中している。一見すると普通の更新に見えるが、まとめて見ると ChatGPT が向かう方向が分かる。デフォルトモデルはより信頼でき、記憶はより制御可能になり、オフィスシーンに深く入り、アカウント安全性も補強されている。

最新重点1：記憶ソースが見えるようになる

5 月 5 日の最初の更新は、ChatGPT の記憶改善だ。

OpenAI は、Plus と Pro ユーザーに対して、より個人化され継続的な回答を段階的に提供するとしている。ChatGPT は過去のチャット、保存記憶、利用可能なファイル、接続済み Gmail の文脈をよりうまく使い、ユーザーに合った提案、推薦、次の行動を出せる。

この能力の価値は長期利用で明確になる。ユーザーがプロジェクトを進めていたり、連載記事を書いていたり、メール群を追っていたり、同種の作業を繰り返していたりすると、毎回背景を説明し直すことが負担になる。より強い記憶能力は、その繰り返しを減らすためのものだ。

しかし記憶が強くなるほど、ユーザーはモデルがどの文脈を使ったのか知る必要がある。そのため OpenAI は memory sources を導入した。ユーザーは回答下で、関連する保存記憶、過去のチャット、カスタム指示、特定条件で参照されたファイルや Gmail メールを確認できる。

情報が古い、不正確、またはもう関連しない場合、ユーザーは修正、削除、または不関連としてマークできる。

パーソナライズは「より分かってくれる」だけではない

AI のパーソナライズについて語るとき、多くの人は「モデルが自分をより理解するか」だけを見る。しかし長期的に使えるパーソナライズには、3つの問いに答える必要がある。

ユーザーはモデルが何を参照したか見られるか。
ユーザーはその情報を編集または削除できるか。
ユーザーは記憶が不要なときにオフにできるか。

Release Notes では、memory sources はユーザー自身のアカウント体験内にのみ表示され、チャット共有時には他人に表示されないと明記されている。ユーザーはチャットを削除し、Temporary Chat を使い、記憶をオフにし、アプリ接続を解除し、コンテンツがモデル改善に使われるかを管理できる。

これは、OpenAI がパーソナライズ能力を積むだけでなく、制御インターフェースも補っていることを示す。長期的なアシスタントにとって、この一歩は重要だ。

最新重点2：GPT-5.5 Instant がデフォルトモデルに

同じ日に、OpenAI は GPT-5.5 Instant を ChatGPT の新しいデフォルトモデルとして展開し、すべてのユーザーの GPT-5.3 Instant を置き換え始めた。

Release Notes はこのモデル更新を実務的に説明している。より正確で、より明確で、より簡潔になり、画像理解、STEM 質問、いつ web search を使うかの判断も改善している。

この種のデフォルトモデル更新はユーザーへの影響が大きい。ほとんどのユーザーは毎日モデルを切り替えない。彼らが感じる ChatGPT の品質は、デフォルトモデルの品質だ。デフォルトモデルの幻覚が減り、無駄な文章が減り、意味のない追問が減れば、実際の体験は明確に改善する。

OpenAI はまた、GPT-5.5 Instant が過度なフォーマットや不要な装飾的内容を減らすとも述べている。これは小さく見えるが、日常利用には近い。多くの場合、ユーザーが必要としているのは構造の整った小論文ではなく、正確で直接的で実行可能な答えだ。

有料ユーザーは GPT-5.3 Instant を3か月間使い続けられ、その後このモデルは退役する。

最新重点3：ChatGPT が Excel と Google Sheets に入る

5 月 5 日の3つ目の更新は、ChatGPT for Excel と Google Sheets のグローバル提供だ。

この機能は Microsoft Excel と Google Sheets のサイドバーに ChatGPT を入れ、ユーザーが表計算内で直接データを構築、更新、理解できるようにする。公式が挙げるシーンには、トラッカー、予算、数式、複数シートのファイル、シナリオ分析、スプレッドシート整理がある。

これは ChatGPT が「チャット画面で質問に答える」だけに留まっていないことを示している。ユーザーがすでに働いている場所へ入っている。

オフィスユーザーにとって、表計算は非常に高頻度の実作業現場だ。多くの会社、チーム、個人の業務データは、複雑なデータプラットフォームではなく、多数の Excel と Google Sheets ファイルにある。ChatGPT が表計算の横で直接データを理解し、数式を書き、複数シートを整理し、結果を説明できるなら、チャット画面へコピー＆ペーストするよりハードルはかなり低い。

OpenAI は、数式や分析に依存する前に出力を確認するよう促している。これは現実的だ。AI は表計算作業を速くできるが、財務、運用、業務判断の責任をすべてユーザーの代わりに負うことはできない。

4月末の下地：安全性とモデル選択

少し前を見ると、4月30日の Advanced Account Security も注目に値する。

これは個人 ChatGPT アカウント向けの任意の安全設定だ。有効にすると、passkeys や互換セキュリティキーのようなより強いサインイン方式を使い、パスワードログイン、メールやSMSのログインコード、メールベースのアカウント復旧といった弱い経路を無効化する。さらにリカバリキー、短いアクティブセッション、ログイン通知、セッション管理コントロールも含まれる。

この種の機能は、ChatGPT アカウントの重要性が上がっていることを示す。ファイル、記憶、アプリ接続、メール、表計算、作業プロジェクトが ChatGPT に入るにつれ、アカウント安全性は単なるログイン問題ではなく、ユーザーの長期的な仕事文脈に関わる問題になる。

4月28日には、OpenAI はモデル選択入口を入力欄の近くに移し、Thinking と Pro モデルの thinking effort 制御をモデルピッカーに入れた。これは典型的なプロダクト細部の変更だ。モデルが増えるほど、ユーザーは送信前に適切なツールを選びやすくする必要がある。

4月下旬のもう一つの方向：より速い通常回答

4月22日、ChatGPT は Fast answers を導入した。

これは一般的な情報問い合わせ向けの機能だ。質問がパーソナライズを必要とせず、ChatGPT が高信頼の答えを持っている場合、より速く結果を返せる。Fast answers は過去のチャットや記憶を参照せず、ユーザーはパーソナライズ設定でオフにできる。

これは記憶強化と逆に見えるが、実際には同じプロダクトロジックだ。異なる質問には異なる処理が必要になる。

「先週のプロジェクト計画を続けて」のような質問には長期文脈が必要だ。一方、「世界七不思議は何か」のような質問には速さと明確さが必要だ。前者には記憶と文脈が必要で、後者には速度と明瞭さが必要になる。ChatGPT はこれらの経路を分け始めている。

プロダクトリズムの変化

これらの release notes から、ChatGPT の更新はもはやモデル発表だけではないことが分かる。

現在の更新は同時に次をカバーしている。

デフォルトモデル品質。
記憶とパーソナライズ。
アプリ接続とオフィスアドイン。
アカウント安全性。
モデル選択とインタラクション入口。
Fast answers とモバイル体験。

これは ChatGPT が単一の AI チャット製品から、より完全な作業プラットフォームへ移行していることを意味する。モデル能力は依然として重要だが、プロダクト体験、文脈管理、ツール入口、アカウント安全性、サードパーティ連携も同じくらい重要になっている。

短い判断

この ChatGPT Release Notes で最も見るべきなのは、特定の1つの更新ではなく、それらが組み合わさって示す方向だ。

OpenAI は ChatGPT を、より速く、より文脈を理解し、よりオフィスシーンに入り、同時により制御可能で安全なものにしている。GPT-5.5 Instant はデフォルト回答品質を高め、memory sources はパーソナライズの出所を説明し、Excel と Google Sheets は実際の作業ファイルへ入る。Advanced Account Security は、より重いアカウント利用に保護を足している。

今後、ChatGPT の競争力はモデルパラメータだけで決まらない。これらの更新を、安定し、明確で、ユーザーが長期的な文脈を預けたいと思えるプロダクト体験へまとめられるかにも左右される。

ChatGPT Release Notes 更新：記憶ソース、GPT-5.5 Instant、表計算アドイン

Thu, 07 May 2026 14:30:15 +0800

OpenAI の ChatGPT Release Notes ページは 2026 年 5 月初めに更新された。最新の主な内容は3つある。ChatGPT の記憶ソースとパーソナライズ能力の強化、GPT-5.5 Instant の新デフォルトモデル化、そして ChatGPT for Excel と Google Sheets のグローバル提供だ。

これらを合わせて見ると、方向は明確だ。ChatGPT は単なるチャット入口から、より継続的で、より個人化され、オフィス作業に近いワークアシスタントへ進んでいる。

Memory sources：パーソナライズをより透明に

最新更新で最も注目すべきなのは memory sources だ。

OpenAI は、ChatGPT Plus と Pro ユーザーに対して記憶機能の改善を展開し始めるとしている。ChatGPT は過去のチャット、保存された記憶、利用可能なファイル、接続済み Gmail アプリから関連文脈をよりうまく取り出し、ユーザーに合ったアイデア、提案、次の行動を出せるようになる。

これにより、ユーザーは新しい会話のたびにプロジェクト背景、好み、作業習慣、既存資料を繰り返し説明する必要が減る。長期的な執筆、プロジェクト計画、資料整理、学習、チーム作業では、継続性が強くなる。

ただし、パーソナライズが強くなるほど透明性は重要になる。そのため OpenAI は memory sources を導入し、どの情報が回答のパーソナライズに使われたかをユーザーが確認できるようにする。回答下の Sources アイコンを押すと、関連する保存記憶、過去のチャット、カスタム指示を確認できる。Plus と Pro ユーザーは、ライブラリ内のファイルや、接続済み Gmail から参照されたメールも見る場合がある。

情報が古い、不関連、または誤っている場合、ユーザーは修正、削除、または不関連としてマークできる。

記憶の制御は依然として重要

OpenAI は、memory sources が回答に影響したすべての要因を表示するとは限らず、今後もこのビューを改善すると説明している。

これは重要な注意点だ。memory sources は完全な「モデル思考ログ」ではない。個人化の文脈を理解するためのプロダクトインターフェースだ。可視性は高めるが、すべての影響要因を完全に展開するものではない。

プライバシーと制御について、OpenAI は memory sources がユーザー自身のアカウント体験内にのみ表示されると述べている。チャットを共有しても、関連 sources は共有チャットに表示されない。ユーザーはチャットを削除したり、記憶を使わず更新もせず履歴にも残らない Temporary Chat を使ったり、記憶をオフにしたり、アプリ接続をいつでも解除したり、自分のコンテンツがモデル改善に使われるかを管理できる。

これは、ChatGPT のパーソナライズがより明確な道筋を取っていることを示している。ユーザーをより理解する一方で、なぜそう答えたのかを知らせ、管理入口も残すという方向だ。

GPT-5.5 Instant がデフォルトモデルに

Release Notes は、GPT-5.5 Instant が ChatGPT の新しいデフォルトモデルとして展開され、すべてのユーザー向けの GPT-5.3 Instant を置き換えることも確認している。

今回のデフォルトモデル更新では、主に次の点が改善される。

正確性。
明確さと簡潔さ。
画像理解。
STEM 質問への回答。
いつ web search が必要かの判断。

OpenAI は、GPT-5.5 Instant が特に正確性が重要なプロンプトでより事実に強いと強調している。また、より引き締まった直接的な回答を出し、不要な追問を減らし、過度なフォーマットや装飾的な内容による散らかりを減らす。

ユーザーにとって、これは新しいボタンほど目立たないかもしれない。しかし毎日 ChatGPT を開くときの体感には効く。回答が遠回りせず、冗長さが減り、簡単な質問に過剰な形式を積み上げにくくなる。

パーソナライズとデフォルトモデルがつながる

Web 版の Plus と Pro ユーザーに対して、GPT-5.5 Instant は過去のチャット、ファイル、接続済み Gmail の文脈をより効果的に使える。

これは memory sources と同じプロダクトラインにある。モデルは単に「賢い」だけではなく、適切な場面で、ユーザーが以前に何をしていたか、何を気にしているか、どんな資料をすでに提供したかを理解する必要がある。プロジェクトの継続、計画作成、メール情報の整理、過去の好みに基づく提案では、ChatGPT は重複した質問を減らせる。

有料ユーザーは GPT-5.3 Instant をモデル設定から3か月間使い続けられ、その後このモデルは退役する。

ChatGPT for Excel と Google Sheets

もう一つの重要な更新は、ChatGPT for Excel と Google Sheets のグローバル提供だ。

これは Microsoft Excel と Google Sheets のサイドバーに ChatGPT を入れ、ユーザーが表計算内で直接データを作成、更新、理解できるようにする。OpenAI が挙げるシーンは次の通りだ。

トラッカー。
予算。
数式。
複数シートのファイル。
シナリオ作業。
スプレッドシートの整理。

利用可能な条件では、Skills と apps もサポートする。

この機能の意味は分かりやすい。多くのオフィスデータは専用 BI システムではなく、Excel と Google Sheets にある。ChatGPT を表計算のサイドバーに置くことは、チャット画面へコピー＆ペーストさせるより自然で、実際のワークフローに入りやすい。

利用制限とインストール方法

Release Notes によると、Free と Go には限定的な利用量が含まれる。Plus と Pro は Codex と同じ agentic usage limits を使う。プラン上限を超える場合、追加 credits を購入できる。

インストール方法も直接的だ。Excel 版は Microsoft Marketplace から、Google Sheets 版は Google Workspace Marketplace からインストールし、対象となる ChatGPT アカウントでログインする。

OpenAI は、数式や分析に依存する前に出力を確認するよう促している。これは重要だ。AI は表計算作業を速くできるが、数式、予算、財務、業務分析は依然として人間の確認が必要だ。

短い判断

今回の ChatGPT Release Notes の焦点は、単一の機能ではなく、プロダクト形態がさらに整えられていることだ。

GPT-5.5 Instant はデフォルト回答品質を高める。memory sources はパーソナライズを見えるようにする。Excel と Google Sheets のアドインは ChatGPT をオフィスの表計算に入れる。Advanced Account Security とモデル選択の変更は、アカウント保護と操作体験を補強する。

ChatGPT はより長期的な作業レイヤーになりつつある。より多くの文脈を覚え、より多くのツールに入り、より多くの日常タスクを担う。次に見るべきなのは、パーソナライズの透明性が十分に分かりやすいか、オフィスアドインが実際の複雑な表計算で安定するか、そしてユーザーが便利さと制御のバランスを保てるかだ。

GPT-5.5 Instant 公開：ChatGPT のデフォルトモデルはより正確で短く、より個人に合うように

Thu, 07 May 2026 14:28:40 +0800

OpenAI は 2026 年 5 月 5 日、GPT-5.5 Instant を公開し、すべての ChatGPT ユーザー向けのデフォルトモデルとして展開を開始した。

今回の更新のキーワードは「より大きい」や「より派手」ではない。日常利用に近い改善だ。回答はより正確で簡潔になり、語調はより自然になり、ユーザーがすでに共有した文脈をよりうまく使う。ChatGPT にとって、デフォルトモデルの変化は特に重要だ。最も多くのユーザーが毎日実際に使う体験を変えるからだ。

デフォルトモデルが重要な理由

Instant は ChatGPT の日常的な主力モデルだ。多くのユーザーは手動でモデルを切り替えず、モデル間の違いも詳しく調べない。彼らが感じる ChatGPT の品質は、デフォルトモデルの品質そのものだ。

そのため GPT-5.5 Instant の意味は、新しいモデル名が増えたことだけではない。基礎体験を全体として一段押し上げることにある。OpenAI は、今回の更新により日常的なやり取りがより有用でスムーズになると説明している。さまざまなテーマで回答が引き締まり、会話のトーンが自然になり、必要なときには既存の文脈をよりよく使える。

この改善は大規模なマルチモーダル発表ほど目立たないかもしれない。しかし数億規模のユーザーにとって、デフォルトモデルがミスを減らし、冗長さを減らし、不要な質問を減らすこと自体が大きなプロダクト変化だ。

幻覚が少なく、より信頼できる回答

OpenAI は正確性を最初に置いている。

公式によると、内部評価では、医学、法律、金融など高リスク領域のプロンプトに対して、GPT-5.5 Instant は GPT-5.3 Instant よりも幻覚的な主張を 52.5% 減らした。また、ユーザーが事実誤りとして報告した特に難しい会話では、不正確な主張が 37.3% 減った。

この2つの数字は重要だ。OpenAI がモデルを「話がうまい」方向に進めるだけでなく、事実誤りの発生率を下げ続けていることを示している。特に医療、法律、金融のような領域では、モデルは流暢な答えを出すだけでは不十分で、より慎重で、作り話が少なくなければならない。

もちろん、これで ChatGPT を専門家の助言の代わりにしてよいという意味ではない。より正確なモデルでも、高リスク領域では確認、出典、専門家の判断が必要だ。それでもプロダクト体験として、デフォルトモデルの事実信頼性が上がることは、日常利用の誤誘導を減らす。

日常タスク能力の強化

GPT-5.5 Instant は事実性だけでなく、複数の日常タスクでも改善している。

OpenAI は、写真や画像アップロードの分析、STEM 質問への回答、そしていつ web search を使うべきかの判断が改善したと述べている。ここで重要なのは「いつ検索するかを判断する」ことだ。多くのユーザーは、モデル内部でツールが呼ばれたかどうかではなく、答えが新しく、正確で、分かりやすいかを気にする。

モデルが、どの質問は検索が必要で、どの質問は直接答えられるかをよりよく判断できれば、ユーザーは何度も「調べて」と言う必要がない。ChatGPT は、明示的な指示を待つチャット欄ではなく、より能動的で信頼できる助手に近づく。

発表内の数学例もこの方向を示している。GPT-5.5 Instant は最初に誤った解法を認めた後、さらに確認して代数ミスを見つけ、正しい方程式に戻って解く。本当に重要なのは、まったく間違えないことではなく、推論の途中で問題に気づき修正できる可能性が高まることだ。

回答は短くなるが、薄くなるわけではない

OpenAI は、GPT-5.5 Instant の回答がより引き締まり、直接的になる一方で、必要な内容と ChatGPT の親しみやすいトーンを保つとも強調している。

これはデフォルトモデルにとって重要だ。AI の回答に疲れる理由は、情報不足ではなく、構造が重すぎること、前置きが多すぎること、フォーマットが過剰なことにある場合が多い。単純な質問が5つの見出しと十数個の注意点に分解されると、不自然に感じられる。

GPT-5.5 Instant の目標は、不要な長さと過度なフォーマットを減らし、不要な追問を減らし、回答を散らかす装飾的な要素を避けることだ。日常の業務、文章相談、生活相談、素早い説明では、こうした改善が単一のベンチマーク点よりも体感に効く。

短いことは浅いことではない。良いデフォルトモデルは、ユーザーが必要としているのが一言の実行可能な助言なのか、説明なのか、完全な計画なのかを判断するべきだ。GPT-5.5 Instant は、このバランス感覚をより安定させる方向にある。

パーソナライズ能力も強化

今回のもう一つの主軸はパーソナライズだ。

OpenAI は、Instant が過去のチャット、ファイル、接続された Gmail の文脈をよりうまく使い、回答をより関連性の高いものにできると述べている。追加のパーソナライズが回答を改善できる場面を判断し、過去の会話から関連文脈をより速く探すため、ユーザーは同じ背景を繰り返す必要が減る。

これは ChatGPT を長く使っている人にとって価値が大きい。計画、執筆、ツール選び、プロジェクト整理、ワークフローの継続では、ユーザーはすでに過去の会話で好み、制約、文脈を伝えていることが多い。モデルが自然に引き継げれば、説明の重複が減る。

ただし、パーソナライズには透明性と制御が必要だ。そうでなければ、なぜモデルが突然ある好みに触れたのか、どの記憶が回答に影響したのかが分からない。

Memory sources でパーソナライズを見えるようにする

OpenAI は同時に、すべての ChatGPT モデルに memory sources を導入する。

これは、保存された記憶や過去のチャットなど、どの文脈が回答のパーソナライズに使われたかをユーザーが確認できる機能だ。古い、不正確、またはもう使わせたくない内容があれば、削除や修正ができる。

OpenAI はまた、ユーザーがチャットを共有しても memory sources は他の人には表示されないと説明している。引用されたくないチャットを削除したり、設定で保存記憶を変更したり、記憶を使わず更新もしない Temporary Chat を使ったりできる。

これは重要な一歩だ。AI アシスタントが個人化されるほど、「何に基づいて答えたのか」を説明する必要が増える。Memory sources はすべての要因を示すわけではないが、パーソナライズの一部をブラックボックスの外へ出す。

利用可能性

GPT-5.5 Instant は発表当日から全 ChatGPT ユーザーへ展開され、GPT-5.3 Instant に代わってデフォルトモデルになる。API では chat-latest に対応する。

有料ユーザーは、モデル設定から GPT-5.3 Instant を3か月間使い続けられる。その後、このモデルは退役する。

過去のチャット、ファイル、接続 Gmail を使った強化パーソナライズは、まず Web 版の Plus と Pro ユーザーに展開され、モバイルにも後日提供される。今後数週間で Free、Go、Business、Enterprise に広げる計画だ。Memory sources は Web 版の ChatGPT 消費者プランに展開され、モバイルにも後で提供される。利用できるパーソナライズ元は地域によって異なる場合がある。

短い判断

GPT-5.5 Instant は、デフォルト体験に向けたアップグレードだ。

モデル能力が強くなるだけではない。回答の正確性、密度、トーン、文脈利用、パーソナライズの透明性を同時に調整している。一般ユーザーにとって最も直接的な変化は、無駄な文章が減り、事実誤りが減り、自分の背景によりつながりやすくなることだろう。

OpenAI にとっては、デフォルトアシスタントの形を進化させる一歩でもある。ChatGPT は「毎回ゼロから質問に答える」ツールから、好みを覚え、文脈を理解し、いつ検索すべきかを判断し、ユーザーが記憶の出所を管理できる長期的なアシスタントへ進んでいる。

ChatGPT に「このチャットはサイバーセキュリティ上のリスクがある可能性があります」と表示される理由と対処法

Wed, 06 May 2026 00:17:00 +0800

ChatGPT や類似の大規模言語モデルを使っていると、まれに「このチャットはサイバーセキュリティ上のリスクがある可能性があります」（This chat was flagged for possible cybersecurity risk）という通知が表示されることがあります。これは、プラットフォームの自動安全システムが、会話内容が利用ポリシーに違反する可能性を検出したという意味です。

以下では、この通知が表示される原因、実際の影響、対処方法を整理します。

なぜフラグ付けされるのか

入力内容がセンシティブ

会話に、有害と解釈される可能性のある内容が含まれている場合があります。たとえば次のようなものです。

悪意のあるコードやスクリプトの生成を求める。
ネットワーク脆弱性の分析や悪用について扱う。
違法行為に関連する内容を質問する。
セキュリティ制限を回避する手順を求める。

誤検知（False Positive）

意図が合法的なコード分析や技術調査であっても、システムがサイバーセキュリティ関連の用語を潜在的な攻撃意図として誤判定することがあります。AI の審査モデルはキーワードに敏感であり、技術的な議論と攻撃行為の境界が必ずしも正確に判定されるとは限りません。

プラットフォームの審査メカニズム

システムは会話内容を自動的にスキャンし、リスク評価を行います。新しいバージョン、たとえば 2026 年 4 月の更新以降では、この種の通知が表示されるケースが増えており、プラットフォームがより厳格な外部審査プロセスを導入した可能性があります。

通知が表示された後の影響

現在のチャットが終了する：プラットフォームが現在の会話での生成を制限または停止する場合があります。
リスク記録：リスク管理のトリガーが繰り返されると記録され、一定以上蓄積するとアカウント状態に影響する可能性があります。
高感度化の傾向：審査メカニズムは継続的に厳しくなっており、技術的な議論でも境界に触れやすくなっています。

対処方法

新しいチャットを作成する

最も直接的な方法は、現在の会話をあきらめて「New Chat」をクリックし、新しい会話を始めることです。以前の文脈は引き継がれないため、通常は同じ審査トリガーが再発しにくくなります。

プロンプトを調整する

以前に入力した内容を確認し、センシティブと判断されそうな語句を取り除き、より中立的な表現に置き換えます。たとえば「ある制限をどう回避するか」を「その制限の原理は何か」に、「攻撃スクリプトをどう書くか」を「この種のスクリプトは通常どのような仕組みを利用するのか」に変えます。

回避を試みない

プロンプトインジェクションなどの方法で、AI に拒否された質問へ無理に回答させようとするのは避けてください。このような行為はアカウント停止のリスクを高め、たいてい逆効果です。

自分の操作内容を確認する

フィッシングリンクの分析やウイルス作成のような高リスク操作をしていない場合、多くは AI が技術概念を誤読したものです。この場合はプラットフォームへフィードバックすることも考えられますが、短期的な効果は限定的です。

プライバシーに注意する

個人情報や営業秘密を含む内容を AI 分析に使わないでください。リスク管理に引っかからなくても、データ漏えいのリスクは残ります。

予防策

技術的な議論では、できるだけ中立的な用語で問題を説明する。
1 つの会話内で大量のセンシティブな話題を集中して扱わない。
不要な過去の会話を定期的に整理する。
重要なアカウントでは、審査の境界に頻繁に触れる使い方を避ける。

まとめ

「このチャットはサイバーセキュリティ上のリスクがある可能性があります」という通知は、通常は自動審査によって発生するもので、必ずしもアカウント違反を意味するわけではありません。対処の優先順位は明確です。新しいチャットを作成する > 表現を調整する > 無理に突破しようとしない。日常的な利用では、表現の境界に注意することで、ほとんどの発生を避けられます。

ChatGPT と Codex がログイン時に電話番号認証を求める理由

Wed, 06 May 2026 00:09:41 +0800

最近、ChatGPT アカウントは登録済みなのに、ChatGPT や Codex にログインしようとすると再度電話番号の認証を求められるケースが報告されている。特に Codex ではこの表示に戸惑うユーザーが多い。アカウント登録はできたのに、なぜツールにログインする際に電話番号が必要になるのか。

この問題は通常、アカウントのリスク制御、無料枠の悪用、ネットワーク環境、アカウントセキュリティポリシーに関係している。以下に主な原因と対処の考え方を整理する。

電話番号認証が要求される理由

最も直接的な原因はリスク制御の強化である。

Codex が一般ユーザーに開放されると、無料枠は多くの正規ユーザーを惹きつける一方で、大量登録や無料枠の搾取も呼び込む。登録ボットでアカウントを大量生成し、無料枠を消費する行為が増えれば、プラットフォームは認証ポリシーを引き締めざるを得なくなる。

ユーザー側から見える結果は、以前はメールまたはサードパーティログインだけで済んでいたアカウントが、ChatGPT や Codex へのアクセス時に突然電話番号の追加入力を求められる、というものだ。

これは必ずしも個別のアカウントに問題があるとは限らず、よりリスクの高いログイン環境と判定された可能性もある。例えば：

多数のユーザーが共有するネットワーク出口を使用している。
現在のIP帯域が登録や異常ログインに頻繁に使われている。
登録直後のアカウントで、リソース消費の大きいツールにすぐアクセスした。
デバイス、地域、ネットワークが頻繁に変わる。
無料アカウントの利用パターンが大量アカウントのそれと似ている。

最近アカウントの異常、ログイン制限、誤BANを経験した場合、ネットワーク環境が巻き添えでフラグ付けされた可能性もある。特に多人数共有のノードはリスクが顕著に高い。

Codex でより発生しやすい理由

Codex は通常のチャットと異なり、開発ツールに近く、より多くのリソースを消費する可能性がある。また、無料枠を狙う大量アカウントにとっても格好の標的になりやすい。

したがって、同じアカウントが通常の ChatGPT ページでは問題なく見えても、Codex のログインフローで電話番号認証がトリガーされるのは不思議ではない。製品の入り口ごとに異なるリスク判断が適用されると考えればよい。

通常のユーザーに対しては、この種の認証は個人を困らせるためではなく、大量登録と無料枠の悪用を抑制するためのものだ。ただし、ネットワーク環境がクリーンでない場合は巻き添えを食らうこともある。

対処法1：Plus へのアップグレード

ChatGPT や Codex を長期利用するなら、最もシンプルな対処法は ChatGPT Plus へのアップグレードである。

実際の使用感から言えば、有料アカウントは無料アカウントよりも無料枠悪用関連のリスク制御に引っかかりにくい。Plus アカウントは Codex、ChatGPT の上位モデル、その他高頻度機能の安定利用にも適している。

ただし、Plus にアップグレードすれば認証が永久に発生しなくなるわけではない。アップグレード後も電話番号を求められる場合、原因はやはりネットワーク環境であることが多い。

その場合は以下を優先的に確認するとよい：

多数のユーザーが共有するネットワークを使っていないか。
出口IPが頻繁に切り替わっていないか。
低品質なプロキシや公共ノードを長期間使っていないか。
同一ネットワーク下で多数の OpenAI アカウントがログインしていないか。

可能であれば、より安定したクリーンなネットワーク環境に切り替えてからログインする方が、何度もリトライするより効果的だ。

対処法2：ネットワーク環境の確認

ログイン認証の問題の多くは、一見アカウントの問題に見えて、本質的にはネットワークの問題である。

特定の出口IPが多数のユーザーに共有されていたり、大量登録、異常ログイン、自動化リクエストに使われた履歴がある場合、フラグ付けされやすい。その場合、正規のユーザーであっても ChatGPT や Codex へのログイン時に追加認証を要求されることがある。

以下の観点から確認できる：

より安定したネットワーク環境に切り替える。
公開された安価な多人数共有ノードの使用を避ける。
短期間での頻繁な地域切り替えを最小限に抑える。
同じブラウザで複数アカウントを頻繁に切り替えない。
プロキシを使う場合は、品質が安定し悪用の少ない回線を優先する。

サードパーティのネットワーク品質検出ツールで現在のIPのリスク状況を確認することもできるが、検出結果はあくまで参考であり、OpenAI 内部の判断を完全に代表するものではない。

対処法3：指示に従って電話番号認証を完了する

システムが明示的に電話番号認証を要求する場合、最も確実な方法は指示に従って認証を完了することである。

長期的に認証コードを受信できる自分自身の番号を使うことを推奨する。そうすれば、後日アカウントのセキュリティ確認、復旧、異常通知が必要になった際にも対応できる。

重要なアカウントを出所不明、多人共有、または長期間使えない番号に紐付けることは推奨しない。短期的には認証を通過できても、長期的にはアカウント復旧、セキュリティ監査、二次認証のリスクを招く。

仕事用アカウント、チームアカウント、または長期利用の開発用アカウントを使っている場合は、管理不能な一時的な番号の使用を特に避けるべきだ。アカウントの安全は一時的な手間より重要である。

Plus アップグレード時の注意点

Plus へのアップグレードを予定している場合、事前にいくつか確認しておくとよい：

アカウント自体が正常にログインできること。
現在のネットワーク環境が安定しており、頻繁に地域が切り替わらないこと。
支払い方法が信頼できるものであること。出所不明の代理決済は使わない。
アップグレード後は決済記録とアカウントのメールを保管すること。
アカウントを複数人で共有しないこと。

アカウントの問題の多くは Plus 自体にあるのではなく、アップグレード前後のネットワーク、支払い、共有の習慣にある。アカウントを長期間複数人で共有し、頻繁に別の場所からログインし、頻繁に環境を切り替えると、有料であってもセキュリティ認証がトリガーされる可能性がある。

たまに試すだけであれば、無料アカウントでも問題ない。しかし Codex を日常の開発ツールとして使っているなら、Plus の方が長期利用に適している。

無料枠の搾取は推奨しない

Codex のようなツールの無料枠は、もともと正規ユーザーが体験・試用するためのものだ。大量のアカウントが無料枠を継続的に消費すれば、プラットフォームは最終的にリスク制御の強度を上げ続けるしかなくなる。

その結果、正規ユーザーも影響を受ける。ログインは面倒になり、認証は増え、誤BANは増え、アカウントの利用コストは上昇する。

実際に Codex をコーディング、プロジェクト改修、エンジニアリングタスクに使っている人にとっては、リスク制御を回避することに時間を費やすよりも、アカウントとネットワーク環境をクリーンに整える方が価値がある。長期的に見れば、新しいアカウントを繰り返し登録し、ノードを切り替え、認証問題に対処するよりもずっと楽だ。

まとめ

ChatGPT や Codex がログイン時に電話番号認証を要求するのは、通常アカウントのリスク制御、無料枠の悪用、ネットワーク環境のリスクに関係している。必ずしもアカウント自体が違反しているとは限らないが、現在のログイン環境またはアカウント状態がより高いレベルの認証をトリガーしたことを示している。

対処の順序はシンプルだ：

まずネットワーク環境を確認し、多人共有や高リスクの出口を避ける。
長期利用の場合は Plus へのアップグレードを検討する。
システムが電話番号認証を要求する場合は、自分が長期間管理できる番号で完了させる。
大量登録、アカウント共有、頻繁なログイン環境の切り替えを避ける。

AI ツールを安定して使うための本質は、認証を回避し続けることではなく、アカウント、ネットワーク、利用方法をできる限り正常に保つことだ。そうすることでログインの手間を減らし、後日の巻き添えリスクも下げられる。

OpenAI が Advanced Account Security を発表：ChatGPT と Codex アカウントに強力な保護層を追加

Fri, 01 May 2026 06:15:29 +0800

OpenAI は 2026 年 4 月 30 日、ChatGPT アカウント向けの任意の高度なセキュリティ設定として Advanced Account Security を発表した。

主な対象は二つのユーザー層だ。一つは、ジャーナリスト、選挙で選ばれた公職者、政治的反体制派、研究者など、標的型攻撃を受けやすい人たち。もう一つは、ChatGPT と Codex のアカウントにより強い保護を加えたい、セキュリティ意識の高いユーザーである。

この機能を有効にすると、ChatGPT だけでなく、同じログインアカウントでアクセスする Codex も保護される。

なぜ ChatGPT アカウントにより高い安全性が必要なのか

現在、多くの人が ChatGPT をますます私的で、リスクの高い仕事に使うようになっている。

一つの ChatGPT アカウントには、次のようなものが含まれる可能性がある。

個人的な相談や長期的な会話
業務文書とプロジェクトの文脈
接続済みのツールとワークフロー
Codex 内のコードや開発タスク
企業、研究、セキュリティ関連の資料

アカウントが乗っ取られた場合、被害はチャット履歴の漏洩だけでは済まない。攻撃者は接続済みツールへアクセスしたり、機密性の高い文脈を見たり、進行中の作業に干渉したりする可能性がある。

そのため、今回 OpenAI が導入したのは単なるログインオプションではなく、より厳格なアカウント保護のセットである。

Advanced Account Security に含まれる保護

OpenAI はこの機能を、ChatGPT ウェブ版アカウントの Security 設定に配置している。ユーザーは任意で有効にできる。

有効にすると、いくつかの面でアカウントの安全性が高まる。

第一に、ログイン方法が強化される。

Advanced Account Security は passkeys または物理セキュリティキーを要求し、パスワードベースのログインを無効にする。目的は、フィッシングに強いログイン方法を、それを必要とする人たちの標準にすることだ。

第二に、アカウント復旧がより厳格になる。

従来のアカウント復旧は、多くの場合メールやSMSに依存している。攻撃者がユーザーのメールアカウントや電話番号を支配した場合、それを使ってアカウントをリセットできる可能性がある。このリスクを下げるため、Advanced Account Security はメールと SMS による復旧を無効化し、バックアップ passkeys、セキュリティキー、復旧キーなど、より強力な復旧方法を使う。

ここには重要な代償がある。有効にした後は、アカウント復旧がユーザー自身による復旧手段の管理に大きく依存する。OpenAI は、この機能を有効にしたユーザーが復旧手段を失った場合、OpenAI Support はアカウント復旧を支援できないと明示している。

第三に、セッションが短くなり、管理がより明確になる。

OpenAI はログインセッションを短くし、端末やアクティブなセッションが侵害された場合の露出時間を減らす。ユーザーはログイン通知も受け取り、複数デバイスでのアクティブセッションを確認・管理できる。

第四に、学習除外が自動になる。

機密情報を扱う人にとって、会話をモデル学習に使わせないことは重要なプライバシー設定である。Advanced Account Security を有効にすると、この設定が自動的に適用される。つまり、これらのアカウントの会話は OpenAI モデルの学習に使われない。

Yubico と連携して物理セキュリティキーを広げる

OpenAI は、Yubico と提携してカスタムのセキュリティキーセットを提供することも発表した。

含まれるのは次の二つだ。

YubiKey C Nano：ノートPCに挿したまま使うことを想定し、日常のログイン負担を減らす
YubiKey C NFC：バックアップとして、またノートPCとモバイルデバイスの両方で使いやすい

OpenAI は、ユーザーが他の FIDO 準拠の物理セキュリティキーや、ソフトウェア passkeys を使うこともできるとしている。

これは、Advanced Account Security が特定のハードウェアに縛られているわけではなく、フィッシングに強い認証方式を中心に設計されていることを示している。

Trusted Access for Cyber ユーザーには有効化が求められる

OpenAI はさらに、Trusted Access for Cyber の個人メンバーが、より高性能で許容範囲の広いサイバーセキュリティ向けモデルにアクセスする場合、2026 年 6 月 1 日から Advanced Account Security の有効化が必要になると述べている。

組織ユーザーは別の方法でも要件を満たせる。自社のシングルサインオンのワークフローが、すでにフィッシング耐性のある認証を採用していると証明する方法だ。

この方針は妥当だ。モデル能力が強くなるほど、アカウント保護も強くする必要がある。特にサイバーセキュリティ研究、脆弱性分析、レッドチームといった場面では、アカウント自体が高価値の標的になる。

誰が有効にすべきか

この機能は、必ずしもすべての人に向いているわけではない。

普通の会話に使うだけで、より厳格なアカウント復旧の複雑さを負いたくない場合は、しばらく様子を見るのもよい。

ただし、次のようなユーザーは真剣に検討する価値がある。

ChatGPT で機密性の高い業務資料をよく扱う人
Codex でプライベートコードリポジトリを扱う人
ジャーナリスト、公共政策関係者、研究者、企業幹部などの高リスクユーザー
サイバーセキュリティ従事者
すでに passkeys や物理セキュリティキーに慣れている人
フィッシング、SMS乗っ取り、メールアカウント乗っ取りを特に警戒している人

有効にする前に、バックアップ passkey、セキュリティキー、復旧キーを用意し、それらが適切に保管されていることを確認したほうがよい。そうしないと、安全性は高まる一方で、アカウント復旧の難度も明らかに上がる。

AI プロダクトにとって何を意味するのか

Advanced Account Security はモデル能力の更新ではない。しかし、AI プロダクトがより高リスクな利用段階に入っていることを反映している。

ChatGPT と Codex がワークフロー、コード、文書、企業向けコネクター、長期的な文脈を担い始めると、アカウントはもはや「チャットツールにログインする入口」ではなく、AI 作業環境の鍵になる。

こうしたプロダクトが個人の作業台に近づくほど、アカウントセキュリティ、復旧メカニズム、セッション管理、学習データ制御は重要になる。

OpenAI が passkeys、物理セキュリティキー、復旧制限、セッション管理、学習除外を一つの設定にまとめた方向性は妥当だ。高リスクユーザーが明確な入口から、機密性の高い作業に適したレベルまでアカウント保護を引き上げられる。

まとめ

Advanced Account Security は、ChatGPT と Codex の高セキュリティモードと理解できる。

より強いログイン、より厳格な復旧、短いセッション、ログイン通知、自動的な学習除外によって、アカウント乗っ取り後のリスクを下げる。その代わり、ユーザーは自分の復旧手段をより慎重に管理する必要がある。有効化後は従来のメールや SMS による復旧が使えず、OpenAI Support も代わりに救済できないからだ。

すでに ChatGPT や Codex を重要な仕事に使っているなら、特にプライベートコード、機密文書、高リスクな立場に関わる場合、この機能は注目に値する。

参考リンク：

Introducing Advanced Account Security - OpenAI

ChatGPT・Claude・Gemini の役割分担はどうするべきか：日常会話、コーディング、特殊機能の選び方

Sat, 25 Apr 2026 10:51:19 +0800

今では、多くの人が1つのモデルだけを使うのではなく、ChatGPT、Claude、Gemini を行き来しながら使っています。そうなると問題はかなり実務的になります。どんなタスクを、どのモデルに任せるべきなのか。

この点が悩ましくなるのは、3社とも弱いからではありません。むしろ十分に強くなった結果、それぞれの得意分野が分かれてきたからです。いまだに「どれがいちばん賢いか」のような曖昧な基準で選ぶと、かえって外しやすくなります。

まずは簡略版の結論から言うと、おおむね次のように考えられます。

日常会話や汎用タスクなら、まず ChatGPT を思い浮かべる人が多い
コマンドラインでのコーディング、長いコンテキストでの協業、継続的に進めるタイプの作業なら、Claude のほうが扱いやすいことが多い
Google エコシステム、検索、マルチモーダルの入口、あるいは一部の製品レベルの特殊機能が必要なら、Gemini の存在感が強い

以下、3つに分けて見ていきます。

1. 日常会話：なぜ多くの人がまず `ChatGPT` を開くのか

多くの一般的な利用シーンでは、ChatGPT は今でも「標準の入口」のような存在です。

ここで言いたいのは、特定の benchmark の話ではなく、全体的な使い心地です。
ちょっとした質問をしたいとき、考えを整理したいとき、短い文章を書きたいとき、たたき台を作りたいとき、資料を要約したいときに、ChatGPT は全体としてバランスがよく感じられます。

強みは主に次の点にあります。

回答スタイルが比較的安定している
一般ユーザーにとって使い始めるハードルが低い
多くの総合タスクで過度な追加調整がいらない
製品としての完成度が高く、日常的に高頻度で使いやすい

たとえば次のような作業なら、

あるテーマを整理してほしい
アイデアを構造化された内容にまとめたい
長文を要約したい
いくつかの案をブレインストーミングしたい
表現をより分かりやすく整えたい

ChatGPT はかなり自然な出発点になります。

これは、あらゆる専門タスクで必ず最強だという意味ではありません。むしろ「広く汎用的に使える」という点で、標準の作業台に近いということです。

2. コマンドラインでのコーディングと長いタスク：なぜ `Claude` を好む人が多いのか

タスクが「少し会話する」段階から、「最後まで継続して進める」段階に移ると、多くの人の好みは Claude に傾き始めます。

特に次のような場面です。

コマンドラインでのプログラミング
大規模プロジェクトのコンテキスト理解
複数ファイルをまたぐ修正
長い流れのデバッグ
コードを読みながらタスクを前進させる作業

こうしたタスクで重要なのは、1回の返答がどれだけ派手かではなく、長い作業の流れの中で安定していられるかどうかです。

Claude が好まれる理由は、「ひとことが他よりうまいから」ではなく、主に次の点にあります。

長いコンテキストのタスクでも粘り強い
ファイル、ログ、ルールを連続して読むときの安定感が高い
複雑なコーディング作業を段階的に進めやすい
コマンドラインや agent ワークフローでは主力モデルとして扱われやすい

vibe coding、コマンドラインでのバグ修正、プロジェクト構造の理解、複数ファイルにまたがる機能改修をしているなら、Claude の強みはより見えやすくなります。

要するに、Claude は一問一答のためだけでなく、一緒に「作業を進める」相手として向いているモデルだと言えます。

3. `Gemini` の強みは「何でも正面から勝つこと」ではない

Gemini を語るとき、多くの人は「結局3つの中で最強なのか」と聞きがちです。

しかし実際の利用感覚からすると、もっと有用な問いはそこではありません。どんな場面で、あえて単独で使う価値が高いのか。

Gemini の価値は、主に次の方向で表れやすいです。

Google エコシステムとの連携
検索や情報収集
マルチモーダルの入口
一部の製品機能との連動

もし普段のワークフローがもともと Google のツールチェーンに近いなら、たとえば

検索
ドキュメント
メール
ブラウザ上での利用
モバイル側の入口

Gemini の実用上の便利さは、単純なモデル性能の比較よりも重要になるかもしれません。

つまり Gemini の使いやすさは、「どこで自分のワークフローに自然につながるか」から来ることが多く、「単発の回答で誰に勝つか」だけでは測れません。

4. 本当に役立つ選び方は、最強を問うことではなく、タスクの種類を問うこと

3つのモデルを並べて比較するとき、いちばん陥りやすい罠は「唯一の最強」を探そうとすることです。

ですが、現実のタスクはあまりにも違います。

単発のQ&Aもある
長い対話で伴走してもらうものもある
コードベースを扱う作業もある
情報検索もある
マルチモーダル処理もある
ツールチェーンとの協業もある

だからこそ、より有効なのはタスクの種類で分けることです。

総合型で、日常的に高頻度に使えて、開けばすぐ使える助手がほしいなら、まず ChatGPT
長いコンテキスト、コマンドライン、コーディング協業、複雑な作業の継続的な前進が必要なら、まず Claude
Google エコシステム、検索、マルチモーダルの入口、あるいは一部の製品連携を活かしたいなら、Gemini を重視する

このような役割分担のほうが、無理に総合優勝を決めるより、実際の使い方に近いです。

5. なぜヘビーユーザーは3つとも契約するのか

ライトユーザーの視点では、3つ全部に課金するのは重複して見えがちです。
けれどもヘビーユーザーの視点では、それは異なる仕事に異なる道具を割り当てているだけです。

理由は単純です。
3つのモデルの強みがすでにはっきり分かれ始めているなら、同時に使うことは重複課金ではなく、タスク切り替えのコストや試行錯誤のコストを下げる方法だからです。

たとえば、

日常的な整理や総合Q&Aには ChatGPT
コーディングの主作業には Claude
検索、マルチモーダル、Google 関連の導線には Gemini

この組み合わせの考え方は、デザイナーが複数のソフトを入れることや、開発者が複数の IDE を使うことと本質的には変わりません。

6. 何度もモデルを切り替えすぎないほうがいい場面

もちろん、モデルが多ければ常に良いわけではありません。

まだ安定したワークフローを作っている途中なら、3つのモデルを早い段階で頻繁に行き来すると、かえって混乱しやすくなります。よくある問題は次の通りです。

同じタスクを何度も説明し直す
モデルごとに違う提案が出て、判断が難しくなる
コンテキストが途切れ、協業コストが上がる
自分なりの使い分けができる前に、道具選びそのものに引っ張られる

なので、より安定したやり方は次の通りです。

まず各モデルに1つずつ主な担当領域を与える
その担当領域でしばらく続けて使う
そのうえで自分なりの使い分けを徐々に作っていく

こうすることで、「今日はこれを試してみよう」という段階に留まり続けるのではなく、再利用しやすい実践知を得やすくなります。

7. まずはこう覚えておけばいい

とりあえず使える覚え方だけ欲しいなら、次のような口語的な分担表で十分です。

ChatGPT：汎用型の標準アシスタント
Claude：長いタスクとコーディング協業の主力
Gemini：検索、マルチモーダル、Google エコシステムで強みを発揮しやすいツール

これは絶対的なルールではありませんし、3者が互いに代替できないという意味でもありません。あくまで実際の利用感覚に近い出発点です。

本当に重要なのは、「宇宙最強のモデル」を選ぶことではなく、できるだけ早く次を見極めることです。
今、目の前のこの種類のタスクに対して、どのモデルがもっとも時間を節約し、気力を消耗させず、結果につながりやすいか。

OpenAI が GPT-5.5 を発表：より強力なエージェント型コーディング、知識作業、研究支援

Fri, 24 Apr 2026 08:39:56 +0800

OpenAI は 2026 年 4 月 23 日に Introducing GPT-5.5 を公開しました。公式ページを見る限り、今回の更新は単に「モデルが賢くなった」という話ではなく、複雑なタスクをどこまで継続して進められるかに重点があります。

OpenAI は GPT-5.5 を、実際の仕事により適したモデルとして位置づけています。質問に答えるだけでなく、コードを書き、デバッグし、情報を調べ、データを分析し、文書やスプレッドシートを作成し、ソフトウェアを操作し、複数のツールを行き来しながらタスクを完了することが期待されています。

1. GPT-5.5 はどこが強いのか

今回の発表ページで繰り返し強調されている方向性は、大きく次の 4 つです。

エージェント型コーディング
コンピューター操作とツール利用
知識作業
初期段階の科学研究支援

つまり、GPT-5.5 の重点は短い質疑応答ではなく、より長い流れを持つタスクです。たとえばエンジニアリング上の問題は、「このコードをどう直すか」だけではありません。プロジェクト構造を理解し、失敗原因を特定し、関連ファイルを修正し、テストを追加し、結果を検証し、ユーザーが何度も指示しなくても前に進める必要があります。

OpenAI は、GPT-5.5 が Codex のタスクでより少ない token を使うことも強調しています。これは実務上かなり重要です。コーディングエージェントは、ファイルを読み、コマンドを実行し、bug を直し始めると、token 消費がすぐに増えます。同じタスクを少ない手順で完了できれば、実際のコストと待ち時間の両方が下がります。

2. コーディング能力が今回の中心的な見せ場

OpenAI は GPT-5.5 を、現時点で最も強力な agentic coding モデルだと説明しています。

公開されている指標の中で、とくに注目したいものは次の通りです。

Terminal-Bench 2.0：GPT-5.5 は 82.7%
SWE-Bench Pro：GPT-5.5 は 58.6%
OpenAI 内部の Expert-SWE：GPT-5.5 は GPT-5.4 を上回る

これらの評価に共通しているのは、単一のアルゴリズム問題よりも、実際の開発フローに近いことです。特に Terminal-Bench のようなタスクでは、コマンドライン操作、計画、試行錯誤、ツール連携、複数ステップの検証が必要になります。

日常的に開発する人にとって、ここでの意味は明確です。モデルがより大きなタスクを受け止められるかどうかは、長時間コンテキストを保てるか、自分の仮説を検証できるか、いつテストを走らせるべきかを判断できるか、変更がどこに影響するかを理解できるかにかかっています。

Codex における GPT-5.5 の価値も、主にこうした振る舞いに表れます。コード断片を補完するだけのツールというより、エンジニアリング作業の一部を任せられる協力者に近づいています。

3. 知識作業が重要な利用シーンになっている

コードを書くことに加えて、OpenAI は今回 GPT-5.5 をより広いオフィス作業の文脈にも置いています。

公式発表では、GPT-5.5 は Codex で文書、スプレッドシート、スライド資料をよりうまく生成でき、業務調査、表計算モデル、ビジネス資料の整理にも向いているとされています。コンピューター操作能力と組み合わせると、その目標は単に助言することではなく、「情報を探す、内容を理解する、ツールを使う、出力を確認する、結果として整理する」という一連の流れに直接参加することです。

発表ページでは、OpenAI 社内ですでにソフトウェアエンジニアリング、財務、コミュニケーション、マーケティング、データサイエンス、プロダクト管理など、多くの部門で Codex が使われていることにも触れています。ここで注目すべきなのは個別の事例ではなく、OpenAI が Codex を開発者向けツールから汎用的な仕事用ツールへ広げようとしている点です。

ChatGPT では、GPT-5.5 Thinking が Plus、Pro、Business、Enterprise ユーザー向けに提供されます。GPT-5.5 Pro は、より難しい問題や高い正確性が必要な作業向けで、Pro、Business、Enterprise ユーザーが利用できます。

4. 研究能力は「答えがうまい」だけではない

GPT-5.5 は研究支援の面でも大きく紹介されています。

OpenAI は、遺伝学、定量生物学、バイオインフォマティクス、数学証明などの領域で改善があると述べています。ここで重要なのは、モデルが知識を暗記しているかどうかではなく、より現実の研究に近い問題を扱えるかどうかです。データを読み、異常を見つけ、分析方法を提案し、結果を解釈し、中間結果に基づいてさらに進める必要があります。

発表ページに登場する GeneBench と BixBench は、どちらも多段階の科学分析タスク寄りの評価です。OpenAI はさらに、カスタムハーネスを使った GPT-5.5 の内部版が Ramsey numbers に関する新しい証明の発見を助け、その証明が Lean で検証されたとも述べています。

こうした事例を「AI がすでに独立して研究できる」と単純に捉えるべきではありません。ただし、モデルが質問応答ツールから研究協力者へ近づいていることは示しています。特に、コード、データ、論文、実験アイデアが混ざる場面では、GPT-5.5 の長い推論とツール利用能力がより重要になります。

5. 推論効率：強くなっても大きく遅くならない

見落としやすい点として、OpenAI は GPT-5.5 の実運用における per-token latency が GPT-5.4 と同等だと説明しています。

通常、より大きく強力なモデルは高い遅延を伴います。今回 OpenAI は、推論システムの最適化によって、GPT-5.5 の能力を高めながら速度を維持したと強調しています。発表ページでは、Codex が本番トラフィックのパターンを分析し、負荷分散に関するヒューリスティックアルゴリズムを書いたことで、token 生成速度が 20% 以上向上したとも述べられています。

この点は興味深いところです。モデルはインフラに提供されるだけでなく、自分自身を提供するインフラの改善にも役立っているからです。

6. 安全対策はより厳しくなる、とくにサイバーセキュリティ領域

GPT-5.5 はサイバーセキュリティ能力も強くなっているため、OpenAI は安全制限も同時に強化しています。

公式説明では、GPT-5.5 はサイバーセキュリティ能力で GPT-5.4 より向上しているため、より厳格な分類器を導入するとされています。特に、高リスク活動、機微なサイバーセキュリティ関連リクエスト、繰り返しの悪用に対して厳しくなります。

そのため、一部のユーザーはサイバーセキュリティ関連の作業で、より多くの拒否や制限に遭遇する可能性があります。OpenAI は Trusted Access for Cyber も用意しており、検証済みの防御目的のユーザーが不要な制限を受けにくくする仕組みを提供しています。

一般的な開発者にとっては、合法的なセキュリティ強化、脆弱性修正、コード監査は引き続き支援される一方、高リスクな攻撃フローはより厳しく制御される、と理解すればよさそうです。

7. 利用可能範囲と API 価格

OpenAI の発表ページによると、GPT-5.5 の利用可能範囲は次の通りです。

ChatGPT：GPT-5.5 Thinking は Plus、Pro、Business、Enterprise ユーザー向け
ChatGPT：GPT-5.5 Pro は Pro、Business、Enterprise ユーザー向け
Codex：GPT-5.5 は Plus、Pro、Business、Enterprise、Edu、Go プラン向け
Codex：コンテキストウィンドウは 400K
Codex Fast mode：生成速度は約 1.5x、コストは 2.5x

API については、OpenAI は gpt-5.5 と gpt-5.5-pro を近く提供するとしています。

公式に示された API 価格は次の通りです。

gpt-5.5：入力 5 米ドル / 1M tokens、出力 30 米ドル / 1M tokens
gpt-5.5-pro：入力 30 米ドル / 1M tokens、出力 180 米ドル / 1M tokens
gpt-5.5 API のコンテキストウィンドウは 1M
Batch と Flex は標準 API 価格の半額
Priority processing は標準価格の 2.5x

この価格は多くの日常用途向けモデルより明らかに高いため、普通の雑談よりも、複雑な工程変更、長文書分析、オフィス自動化、研究支援、重要な業務フローのような高価値タスクに向いています。

8. 今回の発表をどう見るか

一言で言えば、GPT-5.5 の重点は、OpenAI がモデルを「質問に答えるもの」から「仕事を完了するもの」へさらに進めていることです。

注目すべきなのは benchmark の点数だけではありません。いくつかの能力が合流し始めています。

より強い長時間タスク維持能力
より安定したツール利用
より良いエンジニアリング文脈理解
文書、スプレッドシート、研究、業務フローへの適性
より長いコンテキストと高い token 効率
高リスク能力に対するより厳格な制御

開発者にとって最も試す価値があるのは、Codex での複雑なエンジニアリングタスクです。企業ユーザーにとっては、ツール、文書、業務プロセスをまたぐ一部の作業を、実際に納品できる成果物へ変えられるかが重要になります。

GPT-5.5 は、チャット体験だけを対象にした小さな更新ではありません。OpenAI が「仕事の実行層としての AI」をさらに進める一歩に見えます。

OpenAIがChatGPT Images 2.0を発表、画像生成は「そのまま使える成果物」へ

Wed, 22 Apr 2026 14:21:45 +0800

OpenAI は 2026 年 4 月 21 日に Introducing ChatGPT Images 2.0 を公開しました。発表ページを見る限り、今回のアップデートが伝えたいのは単に「画像がよりきれいになった」ということではありません。より制御しやすく、レイアウトに強く、そのまま使える方向へ画像生成が進んでいる、という点です。

この発表ページは、従来の技術的な発表というより、高密度な能力デモに近い構成です。モデル構造や学習の詳細、ベンチマークについてはほとんど語られていません。その代わり、多数のサンプルを通じて、ChatGPT の画像生成がこれまで人手で何度も修正していた文字、レイアウト、仕上げの工程までどこまで前倒しできるのかを示しています。

01 今回の更新で最もわかりやすいシグナル

発表ページで特に目立つキーワードは、すでに今回の方向性をかなりはっきり示しています。

Greater precision and control
Stronger across languages
Stylistic sophistication and realism

この 3 つをまとめて見ると、意図はかなり明確です。

1つ目は、想像力だけでなく制御性を前面に出していることです。ページにはポスター、雑誌レイアウト、販促ページ、インフォグラフィック、キャラクター設定シート、コミックページ、印刷用しおりデザインなどが数多く並んでいます。これらに共通するのは、単に見栄えがよいだけではなく、文字処理、情報の階層、余白、構図、スタイルの統一、出力比率まで同時に扱う必要がある点です。つまり OpenAI は「1枚の画像を作る」から「実際に使えるビジュアル成果物を作る」へと製品の位置づけを進めようとしているように見えます。

2つ目は、多言語テキストを大きく打ち出していることです。ページには多言語ポスター、書籍カバー、韓国語の宿泊施設プロモーション、日本語マンガ、そして typography を強調した例まであります。これは重要です。画像モデルは、長いテキスト、複雑なレイアウト、英語以外の文字になると急に不安定になることが多かったからです。そこを発表の中心に置いたこと自体が、文字レンダリングや多言語レイアウトが、いまや積極的に見せられる能力になってきたというシグナルです。

3つ目は、スタイルの幅がかなり広いことです。フォトリアルな写真、レトロコラージュ、Bauhaus風ポスター、ファッションエディトリアル、モノクロのドキュメンタリー調、児童書風イラスト、マンガ、教育用インフォグラフィック、商品グリッド、キャラクター設定シートまで幅広く並んでいます。ここで伝えたいのは「多くの画風を真似できる」という話だけではありません。より多様な実務的ビジュアルタスクに適応しようとしている、ということです。

02 なぜ「そのまま使える成果物」へ向かっていると言えるのか

この発表内容を見ると、ChatGPT Images 2.0 は単純に強化された画像生成モデルというより、ビジュアル制作ワークベンチの進化に近い印象です。

これまでのモデルも見栄えのよい画像は生成できましたが、タスクが次のようなものになると体験が急に崩れやすくなっていました。

見出し、副題、説明文まで入ったポスターを作る
情報量の多い雑誌ページや販促ページを作る
キャラクターや物語の連続性が必要なコミックページを作る
比率、レイアウト、ブランド感が決まった販促素材を作る
多言語の文字を含む完成度の高いビジュアルを作る

今回の発表は、こうした従来の弱点に正面から応えようとしているように見えます。

実際にページには、教育用インフォグラフィック、デザイントレンドのポスター、印刷仕様入りのしおり、カフェのオープン告知ポスター、観光プロモーション、グッズのモックアップ、論文ポスターの再構成例などが並んでいます。これらは「ちょっと良い画像」というより、実際の制作フローにおける半完成品、あるいは完成品に近いものです。

そう考えると、今回の重要点は単に1枚絵の品質が上がったことではなく、コンテンツ制作、ブランド素材、教育用途、軽量なデザイン制作に使える生成システムへ近づいていることだと言えます。

03 これは ChatGPT の製品定位に何を意味するのか

発表ページの見せ方からは、製品としての方向性の変化も読み取れます。

OpenAI は ChatGPT Images 2.0 を、クリエイター向けの狭い画像モデルとして見せていません。むしろ、調査、推論、資料変換、レイアウト整理、知識伝達、マーケティング出力といった文脈で繰り返し提示しています。数学の証明、デザイントレンド、歴史ノート、学術論文の可視化まで例に含まれているのも象徴的です。

つまり ChatGPT における画像生成は、単なる「会話に添える画像」や「1枚のイラスト生成」ではなく、より汎用的な表現レイヤーに近づいています。ユーザーが ChatGPT 上で調べ、考え、整理し、文章化したあと、その最終的なビジュアル出力まで一気通貫で扱うことを目指しているように見えます。

この方向が続くなら、画像生成の競争軸は、単純な審美性や写実性だけではなく、次のような点にますます依存するはずです。

複雑な文字をどこまで安定して扱えるか
ページやコマをまたいだ一貫性を維持できるか
実務で使う素材に近いレイアウトを作れるか
調査、執筆、マーケティング、教育といった流れに自然につながるか

04 この発表ページで語られていないこと

もちろん、このページの書き方には限界もあります。

2026 年 4 月 21 日時点の公式ページは、方法よりも結果を見せることに重心があります。具体的には、次のような点は詳しく書かれていません。

前世代比での定量的な改善幅
文字精度や多言語レンダリングの明確な指標
複雑なレイアウト生成における失敗境界
API、価格、利用方法、エンタープライズ向け統合の詳細
安全ポリシーや生成制限の具体的な更新内容

そのため、このページは完全な技術仕様というより、製品シグナルとして読むほうが適切です。

05 まとめ

ChatGPT Images 2.0 を一言でまとめるなら、今回の進化は「より上手に描けるようになった」ことより、「より完成品に近いものを作れるようになった」ことにあります。

OpenAI は画像生成を、発想支援のツールから、実行可能で、レイアウトに強く、伝達力があり、納品に近い制作ツールへ押し進めようとしているように見えます。文字制御、多言語、レイアウト、スタイルの広さ、長いページの構成といった、これまで弱点が出やすかった部分が、今回はむしろ強みとして提示されています。

もちろん、これでデザイン作業のすべての問題が解決したわけではありません。それでも今回の発表からは、競争の重心が変わりつつあることが見て取れます。これからの差は、最も派手な1枚を出せるかどうかではなく、実際に使えるビジュアルをどれだけ安定して出せるかで決まるのかもしれません。

codex-quota 実践ガイド：コマンドをそのまま使う Local・Web・Docker 運用

Thu, 16 Apr 2026 18:13:04 +0800

このプロジェクトは何をするか

codex-quota は ChatGPT Codex のクォータ使用状況を確認できる軽量ツールで、データ取得元は https://chatgpt.com/backend-api/wham/usage です。

主な機能：

単一アカウント・複数アカウント（account/*.auth.json）の両方に対応。
five_hour%、weekly%、weekly_reset を出力し、取得元（network / cache）も表示。
一時的な失敗（408、429、5xx）に対して指数バックオフで再試行。
ローカルキャッシュを内蔵し、クォータ枯渇時の重複リクエストを削減。
Web Dashboard、JSON API、auth ファイル管理画面を提供。

メリット：

軽量：単体スクリプトで実行でき、依存が少ない。
実用的：CLI と Web の両方の入口を使える。
配備しやすい：Docker / Docker Compose をサポート。
運用しやすい：再試行、キャッシュ、定期更新に対応。

先にアカウント認証情報を準備する

account/<name>.auth.json に認証情報ファイルを作成します。例：

{
  "tokens": {
    "access_token": "eyJ...",
    "account_id": "user-xxxxxxxx"
  }
}

説明：

access_token と account_id は API クエリに必要な項目です。
ファイル名の <name> は出力時のアカウント名として使われます。

Local CLI の使い方（元コマンドを維持）

依存をインストール：

`1`	`pip install -r requirements.txt`

説明：プロジェクトの実行依存をインストールします。

全アカウントを照会：

`1`	`python codex_quota.py`

説明：account/*.auth.json を読み込み、全アカウントのクォータを集計表示します。

単一アカウントを照会：

`1`	`python codex_quota.py your_account_name`

説明：account/your_account_name.auth.json のみを照会します。

強制更新（キャッシュ無視）：

`1`	`python codex_quota.py --refresh`

説明：ローカルキャッシュを無視して最新データを直接取得します。

CLI オプション説明（README 準拠）

account_name：任意のアカウント名（.auth.json なし）。
--account-dir：認証ファイルディレクトリ。デフォルトは account。
--chatgpt-url：クォータ API エンドポイント。
--raw-json：JSON レスポンス本文をそのまま表示。
--raw-headers：レスポンスヘッダーを表示。
--refresh：キャッシュを無視。
--retries：再試行回数。デフォルト 3。
--retry-delay：再試行の基本待機秒数。デフォルト 2.0。

Web Dashboard の使い方（元コマンドを維持）

サービス起動：

`1`	`python codex_quota_service.py --host 0.0.0.0 --port 8081`

説明：8081 ポートで HTTP サービスを起動します。

アクセス URL：http://localhost:8081

Service オプション：

--host：バインドアドレス。デフォルト 0.0.0.0。
--port：ポート。デフォルト 8081。
--interval-seconds：定期更新間隔。デフォルト 3600。
--account-dir：認証ファイルディレクトリ。デフォルト account。
--state-file：状態ファイルパス。デフォルト <account-dir>/codex_quota_web_results.json。
--account-name：任意。単一アカウントモード。
--chatgpt-url：クォータ API エンドポイント。
--retries：再試行回数。
--retry-delay：再試行の基本待機。
--refresh：定期実行時に CLI キャッシュを無視。

HTTP エンドポイント（自動化向け）

GET /：Dashboard 画面。
GET /api/results：最新結果の JSON。
GET /refresh：即時更新して / にリダイレクト。
GET /auth：auth ファイル一覧。
GET /auth/new：auth ファイル新規作成フォーム。
GET /auth/edit?name=<account>：auth ファイル編集フォーム。
POST /auth/save：auth ファイル作成/更新。
POST /auth/delete：auth ファイル削除。

Docker の使い方（元コマンドを維持）

イメージをビルド：

`1`	`docker build -t codex-quota .`

説明：現在のプロジェクトを codex-quota イメージとしてビルドします。

コンテナ起動（8081 をマッピング）：

`1`	`docker run --rm -p 8081:8081 -v ./account:/app/account codex-quota`

説明：

--rm：終了後にコンテナを自動削除。
-p 8081:8081：ホストポートをコンテナポートへマッピング。
-v ./account:/app/account：ローカル認証ディレクトリをコンテナにマウント。

アクセス URL：http://localhost:8081

Docker Compose の使い方（元コマンドを維持）

起動：

`1`	`docker compose up --build`

説明：docker-compose.yml に従ってビルド・起動します。

アクセス URL：http://localhost:8081

運用のヒント

複数アカウント運用では、まず Dashboard で一元管理するのがおすすめです。
通知や自動連携には GET /api/results を優先すると扱いやすいです。
公開リポジトリに実際の access_token をコミットしないでください。
一時エラーが多い場合は --retries と --retry-delay を増やしてください。

Codex の利用枠の考え方：5時間制限、週次制限、Credit 消費

Wed, 15 Apr 2026 22:50:00 +0800

Codex の利用枠を見ると、最初は 5時間制限 が短期の残高で、それを使い切ってから 週次制限 が減り始めるように見えます。

しかし実際は違います。Codex は複数の制限ウィンドウを同時に確認している、と考える方が自然です。短いウィンドウは短時間の大量利用を防ぎ、週次ウィンドウは一週間の総量を制御します。1 回の Codex 利用は通常、その両方に反映されます。

そのため、次のような状態は一般的には正常です。

1
2

5時間枠はまだ多く残っている
しかし weekly 枠はすでに減っている

01 まず結論

Codex の利用枠は、まず次の 3 点で理解できます。

5時間制限 と 週次制限 は同時に有効であり、順番に消費されるものではありません。
週次制限を使い切ると、5時間枠が残っていても同じサブスクリプション枠では通常続けて使えません。
Codex は単純なメッセージ数ではなく、モデル、tokens、タスクの複雑さ、コンテキスト、実行場所に影響されます。

疑似コードで書くとこうです。

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 他の製品ポリシー制限に触れていない

5時間ウィンドウがリセットされても、戻るのは 5時間枠だけです。weekly 枠は戻りません。weekly は自分の reset を待つか、対応プランで追加 credits を購入する必要があります。

02 なぜ両方のウィンドウが減るのか

Codex の利用枠は 2 つのゲートとして考えるとわかりやすいです。

ウィンドウ	役割
5時間ウィンドウ	短時間の高頻度利用を防ぐ
週次ウィンドウ	一週間の総使用量を制御する

Codex タスクごとに実際の消費が発生し、その消費が関連する rate limit ウィンドウに反映されます。

つまり、こうではありません。

1
2
3

先に 5時間枠を使う
5時間枠を使い切ったら
週次枠を使う

より近いのはこうです。

1
2
3

1 回の Codex リクエスト
=> 5時間ウィンドウに計上
=> 同時に週次ウィンドウにも計上

これが「5時間枠が残っているのに weekly も減る」理由です。

03 今は token-based credits を見る

OpenAI は、ユーザーが完全に再計算できる Codex の課金式を公開していません。公開されているのは rate card、影響要因、モデル別の credit 単価です。

2026-04-15 時点では、Codex rate card の主な考え方は token-based credits です。入力 tokens、キャッシュ入力 tokens、出力 tokens から credits に換算されます。

公式の価格例は次の通りです。

モデル	入力 / 1M tokens	キャッシュ入力 / 1M tokens	出力 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

ざっくりした見積もりは次のようになります。

今回の消費
≈ 入力 tokens / 1,000,000 × モデルの入力単価
+ キャッシュ入力 tokens / 1,000,000 × モデルのキャッシュ入力単価
+ 出力 tokens / 1,000,000 × モデルの出力単価

これは正確な請求式ではありませんが、傾向の説明には十分です。出力は高く、長いコンテキストも高く、高性能モデルほど高くなります。公式 rate card では、Fast mode は 2 倍の credits を消費し、Code review は GPT-5.3-Codex の価格を使うとも説明されています。

04 メッセージ数だけで見ない

同じ 10 回の Codex メッセージでも、消費量は大きく変わります。

軽いタスクは通常少なめです。

小さな関数を修正する
短いコードを説明する
短い文章を書く
明確なファイル内で局所的に変更する

重いタスクは高くなります。

大きなコードベースをスキャンする
長時間 agent を動かす
読み取り、編集、テスト、修正を何度も繰り返す
大量のコードや長いレポートを生成する
cloud task を使う
fast mode を有効にする

そのため、メッセージ数 はかなり粗い目安にすぎません。実際の消費量を判断するには不十分です。

05 local task と cloud task の違い

消費量の差が出やすいのは実行場所です。

local task は、ローカルのワークスペースでファイルを読み、コードを編集し、コマンドを実行するものです。cloud task は、タスクをクラウド環境に任せて実行するもので、長く自動化された処理に向いています。

cloud task は多くの場合、より高くなります。理由は単純です。

クラウド実行環境が必要
タスクが長くなりやすい
ツール呼び出しが多い
コンテキストが大きい
自動化の流れがより完全

通常のコード編集、記事整理、小さな修正なら local task の方が節約しやすいです。cloud task は本当にクラウド実行が必要なときに使うのがよいです。

06 weekly が早く減る理由

5時間枠はあまり減っていないのに weekly が大きく減る場合、よくある理由は次の通りです。

cloud task を使った。
高いモデルを使った。
fast mode を有効にした。
コンテキストが大きく、多くのファイルや長い会話を扱った。
出力が長かった。大量のコード、長いレポート、ログ分析など。
タスクチェーンが長かった。検索、編集、テスト、修正、再テストなど。
自作の利用枠スクリプトがウィンドウ名を誤って解釈した。

/backend-api/wham/usage のようなフィールドをスクリプトで読んでいる場合、加工後の five_hour% や weekly% だけを信用しない方が安全です。raw JSON で次の値を確認します。

limit_window_seconds
percent_left
reset_at
bucket / feature 名

典型的なウィンドウは次のように判断できます。

limit_window_seconds = 18000
=> 約 5 時間

limit_window_seconds = 604800
=> 約 7 日

スクリプトが 2 つのウィンドウを逆にラベル付けしていると、利用枠表示は誤解を招きます。

07 利用枠を節約する使い方

weekly を長持ちさせるには、次のように使います。

大きなタスクを小さく分ける。
可能なら local task を優先する。
関連パスを明確に伝え、不要なスキャンを減らす。
巨大なログ、長いファイル、無関係なコンテキストを一度に入れない。
軽い作業には安い mini モデルを使う。
長い作業の前に、まず計画を出してもらう。
長いレポートが不要なら、簡潔に答えるよう指定する。

覚えやすいモデルはこれです。

続けて使えるか
= 短いウィンドウに残量がある
&& 週次ウィンドウに残量がある

消費の速さ
= モデル価格
× tokens
× 出力の長さ
× タスクの複雑さ
× 実行場所

これは正確な請求計算ではありませんが、ほとんどの Codex 利用枠の挙動を説明できます。

Codex クォータ使用統計

Sun, 12 Apr 2026 00:01:33 +0800

現在の Codex アカウントの残高を確認したい場合は、ChatGPT の /backend-api/wham/usage インターフェイスを要求する小さなスクリプトを直接作成できます。

このタイプのスクリプトの考え方は非常にシンプルです。

auth.json から tokens.access_token および tokens.account_id を読み取ります
リクエスト https://chatgpt.com/backend-api/wham/usage
リクエストヘッダーに Authorization: Bearer ... と ChatGPT-Account-Id を含めます
返された結果の 5 時間のウィンドウと週ごとのウィンドウクォータを解析します。

やるべきことに適した

この方法は、ローカルですばやく確認するのに適しています。

5 時間の割り当てはどれくらい残っていますか?
週の割り当てはどれくらい残っていますか?
クォータはいつリセットされますか?

複数のアカウントをお持ちの場合は、スクリプトで account/*.auth.json を一括で読み込み、一律に集計表を出力することもできます。 auth.json ファイルは、現在ログインしている chatgpt アカウントに対応する ~/.codex/ ディレクトリにあります。

最も重要なインプット

通常、スクリプトは次の 2 つの資格情報のみに依存します。

access_token
account_id

これらは通常、ローカルの auth.json から入手できます。これら 2 つの値が有効である限り、リクエストヘッダーは次のように構成できます。

headers = {
    "Authorization": f"Bearer {auth_token}",
    "Accept": "application/json",
    "ChatGPT-Account-Id": auth_account_id,
    "Origin": "https://chatgpt.com",
    "Referer": "https://chatgpt.com/",
    "User-Agent": "Mozilla/5.0",
}

返された結果の見方

インターフェイスが戻った後は、次の 2 種類のウィンドウに焦点が当てられます。

five_hour
weekly

スクリプトはそれらを次の項目に整理できます。

残高の割合
リセット時間
対応する時間ウィンドウの長さ

インターフェイスフィールド名が異なる場合、バリアント primary_window、secondary_window、five_hour_limit、および weekly_limit とも互換性がある可能性があります。

よくある質問

スクリプトが 401 を返した場合、通常、access_token の有効期限が切れているか、無効であることを意味します。

403 が返された場合は、通常、現在のアカウントにこのインターフェイスにアクセスする権限がないか、アカウントのステータスが異常であることを意味します。

同じ応答内でフィールドの名前が一貫していない場合でも驚かないでください。実際の処理では、異なる命名方法を統一的にマッピングしてから出力するのがベストです。

参考リンク

codex-auth-manager：https://github.com/RioArisk/codex-auth-manager

コード

import argparse
import base64
import json
import os
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path
from typing import Any

import requests


UTC = timezone.utc
CST = timezone(timedelta(hours=8), name="CST")
JSONDict = dict[str, Any]


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Query ChatGPT Codex usage from /backend-api/wham/usage."
    )
    parser.add_argument(
        "account_name",
        nargs="?",
        help="Account name used to load account/<account_name>.auth.json. If omitted, load all *.auth.json files in account/.",
    )
    parser.add_argument(
        "--account-dir",
        default="account",
        help="Directory containing <account_name>.auth.json files.",
    )
    parser.add_argument(
        "--chatgpt-url",
        default="https://chatgpt.com/backend-api/wham/usage",
        help="ChatGPT usage endpoint.",
    )
    parser.add_argument(
        "--raw-json",
        action="store_true",
        help="Print the full JSON response body.",
    )
    parser.add_argument(
        "--raw-headers",
        action="store_true",
        help="Print response headers.",
    )
    return parser.parse_args()


def print_json(data: Any) -> None:
    print(json.dumps(data, indent=2, ensure_ascii=False))


def load_auth_json(path_str: str | Path | None) -> JSONDict | None:
    if not path_str:
        return None
    path = Path(path_str).expanduser()
    if not path.is_file():
        return None
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError):
        return None


def get_nested_string(data: JSONDict | None, *keys: str) -> str | None:
    current: Any = data
    for key in keys:
        if not isinstance(current, dict):
            return None
        current = current.get(key)
    return current if isinstance(current, str) and current else None


def format_dt(dt: datetime | None) -> str:
    if dt is None:
        return "-"
    return dt.astimezone(CST).strftime("%Y-%m-%d %H:%M:%S %Z")


def format_cst(dt: datetime | None) -> str:
    return format_dt(dt)


def epoch_ms_to_dt(value: Any) -> datetime | None:
    if value is None:
        return None
    try:
        raw = int(value)
    except (TypeError, ValueError):
        return None
    # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds.
    timestamp = raw / 1000 if raw > 10**11 else raw
    return datetime.fromtimestamp(timestamp, tz=UTC)


def first_dict(data: Any, *keys: str) -> JSONDict | None:
    for key in keys:
        value = data.get(key) if isinstance(data, dict) else None
        if isinstance(value, dict):
            return value
    return None


def decode_jwt_exp(token: str) -> datetime | None:
    parts = token.split(".")
    if len(parts) != 3:
        return None
    try:
        payload = parts[1]
        payload += "=" * (-len(payload) % 4)
        data = json.loads(base64.urlsafe_b64decode(payload.encode("ascii")))
        exp = data.get("exp")
        if exp is None:
            return None
        return datetime.fromtimestamp(int(exp), tz=UTC)
    except (ValueError, TypeError, json.JSONDecodeError):
        return None


def get_percent_left(value: JSONDict) -> float | int | None:
    percent_left = value.get("percent_left")
    if percent_left is None:
        percent_left = value.get("remaining_percent")
    if percent_left is not None:
        return percent_left

    used_percent = value.get("used_percent")
    try:
        if used_percent is not None:
            return max(0, 100 - float(used_percent))
    except (TypeError, ValueError):
        return None
    return None


def resolve_limit_window(value: JSONDict) -> JSONDict:
    if (
        "reset_at" not in value
        and "reset_time_ms" not in value
        and isinstance(value.get("primary_window"), dict)
    ):
        return value["primary_window"]
    return value


def parse_limit_entry(name: str, value: Any) -> JSONDict | None:
    if not isinstance(value, dict):
        return None

    value = resolve_limit_window(value)

    percent_left = get_percent_left(value)
    reset_time_ms = value.get("reset_time_ms")
    if reset_time_ms is None:
        reset_time_ms = value.get("reset_at")

    window_seconds = value.get("limit_window_seconds")

    return {
        "name": name,
        "percent_left": percent_left,
        "reset_time_ms": reset_time_ms,
        "reset_at": epoch_ms_to_dt(reset_time_ms),
        "limit_window_seconds": window_seconds,
    }


def infer_limit_name(window_seconds: Any) -> str | None:
    if not isinstance(window_seconds, (int, float)):
        return None
    if window_seconds <= 6 * 3600:
        return "five_hour"
    if window_seconds >= 6 * 24 * 3600:
        return "weekly"
    return None


def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -> tuple[JSONDict | None, JSONDict | None]:
    for entry in (primary, secondary):
        if not entry:
            continue
        inferred_name = infer_limit_name(entry.get("limit_window_seconds"))
        if inferred_name:
            entry["name"] = inferred_name

    if primary and secondary and primary.get("name") == secondary.get("name"):
        if primary.get("name") == "weekly":
            primary["name"] = "five_hour"
        else:
            secondary["name"] = "weekly"

    if primary and primary.get("name") == "weekly" and secondary is None:
        return None, primary

    if secondary and secondary.get("name") == "five_hour" and primary is None:
        return secondary, None

    return primary, secondary


def parse_rate_limits(data: JSONDict) -> tuple[JSONDict | None, JSONDict | None]:
    primary = None
    secondary = None

    for primary_key in ("five_hour", "five_hour_limit", "five_hour_rate_limit", "primary"):
        if primary_key in data:
            primary = parse_limit_entry("five_hour", data.get(primary_key))
            if primary:
                break

    for secondary_key in ("weekly", "weekly_limit", "weekly_rate_limit", "secondary"):
        if secondary_key in data:
            secondary = parse_limit_entry("weekly", data.get(secondary_key))
            if secondary:
                break

    if primary is None:
        primary = parse_limit_entry("five_hour", data.get("primary_window"))
    if secondary is None:
        secondary = parse_limit_entry("weekly", data.get("secondary_window"))

    return relabel_rate_limits(primary, secondary)


def format_percent(value: Any) -> str:
    return f"{value:g}" if isinstance(value, (int, float)) else str(value if value is not None else "-")


def percent_sort_value(value: Any, descending: bool) -> tuple[int, float]:
    if isinstance(value, (int, float)):
        numeric_value = float(value)
        return (0, -numeric_value if descending else numeric_value)
    return (1, 0.0)


def get_auth_paths(account_dir: str, account_name: str | None) -> list[Path]:
    base_dir = Path(account_dir)
    if account_name:
        return [base_dir / f"{account_name}.auth.json"]
    return sorted(base_dir.glob("*.auth.json"))


def get_account_name_from_path(path: Path) -> str:
    suffix = ".auth.json"
    return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem


def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -> JSONDict:
    return {
        "account": account_name,
        "five_hour_percent": five_hour["percent_left"] if five_hour else None,
        "weekly_percent": weekly["percent_left"] if weekly else None,
        "weekly_reset_at": weekly["reset_at"] if weekly else None,
    }


def print_summary_rows(rows: list[JSONDict]) -> None:
    if not rows:
        return

    sorted_rows = sorted(
        rows,
        key=lambda row: (
            percent_sort_value(row.get("five_hour_percent"), descending=True),
            percent_sort_value(row.get("weekly_percent"), descending=True),
            format_cst(row.get("weekly_reset_at")),
            row["account"],
        ),
    )

    display_rows = []
    for row in sorted_rows:
        display_rows.append(
            {
                "account": str(row["account"]),
                "five_hour": format_percent(row.get("five_hour_percent")),
                "weekly": format_percent(row.get("weekly_percent")),
                "weekly_reset": format_cst(row.get("weekly_reset_at")),
            }
        )

    headers = {
        "account": "account",
        "five_hour": "five_hour%",
        "weekly": "weekly%",
        "weekly_reset": "weekly_reset",
    }
    widths = {
        key: max(len(headers[key]), max(len(item[key]) for item in display_rows))
        for key in headers
    }

    print(
        f"{headers['account']:<{widths['account']}}  "
        f"{headers['five_hour']:>{widths['five_hour']}}  "
        f"{headers['weekly']:>{widths['weekly']}}  "
        f"{headers['weekly_reset']:<{widths['weekly_reset']}}"
    )
    for item in display_rows:
        print(
            f"{item['account']:<{widths['account']}}  "
            f"{item['five_hour']:>{widths['five_hour']}}  "
            f"{item['weekly']:>{widths['weekly']}}  "
            f"{item['weekly_reset']:<{widths['weekly_reset']}}"
        )


def validate_token_inputs(
    token: str,
    account_id: str,
    auth_token: str | None,
    auth_account_id: str | None,
) -> int | None:
    if token.startswith("sess-"):
        print("status: invalid_token_type", file=sys.stderr)
        print(
            "message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.",
            file=sys.stderr,
        )
        if auth_token:
            print(
                "hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.",
                file=sys.stderr,
            )
        return 1

    token_exp = decode_jwt_exp(token)
    if token_exp is not None and token_exp <= datetime.now(UTC):
        print("status: expired", file=sys.stderr)
        print(f"message: access_token expired at {format_dt(token_exp)}", file=sys.stderr)
        if auth_token and auth_token != token:
            auth_token_exp = decode_jwt_exp(auth_token)
            hint = format_dt(auth_token_exp) if auth_token_exp else "unknown time"
            print(f"hint: auth.json contains a different access_token expiring at {hint}", file=sys.stderr)
        return 1

    if auth_account_id and account_id != auth_account_id:
        print("warning: supplied --account-id does not match auth.json tokens.account_id", file=sys.stderr)

    return None


def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -> int | None:
    if response.status_code == 401:
        print("status: expired", file=sys.stderr)
        print("message: Token 已过期或无效", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code == 403:
        print("status: forbidden", file=sys.stderr)
        print("message: 账号已被封禁或无权访问", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code >= 400:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print_json(data)
        return 3

    return None


def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -> tuple[int, JSONDict | None]:
    auth_data = load_auth_json(auth_path)
    account_name = get_account_name_from_path(auth_path)
    auth_token = get_nested_string(auth_data, "tokens", "access_token")
    auth_account_id = get_nested_string(auth_data, "tokens", "account_id")

    if not auth_data:
        print(f"{account_name}: auth file not found or invalid", file=sys.stderr)
        return 1, None

    if not auth_token:
        print(f"{account_name}: missing access_token", file=sys.stderr)
        return 1, None

    if not auth_account_id:
        print(f"{account_name}: missing account_id", file=sys.stderr)
        return 1, None

    validation_error = validate_token_inputs(
        auth_token,
        auth_account_id,
        auth_token,
        auth_account_id,
    )
    if validation_error is not None:
        return validation_error, None

    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "ChatGPT-Account-Id": auth_account_id,
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
        "User-Agent": "Mozilla/5.0",
    }

    try:
        response = requests.get(args.chatgpt_url, headers=headers, timeout=60)
    except requests.RequestException as exc:
        print(f"Request failed: {exc}", file=sys.stderr)
        return 2, None

    if args.raw_headers:
        print("=== Headers ===")
        print_json(dict(response.headers))
        print()

    try:
        data = response.json()
    except ValueError:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print(response.text, file=sys.stderr)
        return 3, None

    error_response = handle_error_response(response, data, args.raw_json)
    if error_response is not None:
        return error_response, None

    if args.raw_json:
        print("=== Raw JSON ===")
        print_json(data)
        print()

    rate_limits = first_dict(data, "rate_limit", "rate_limits")

    if rate_limits is None:
        return 0, build_summary_row(account_name, None, None)

    five_hour, weekly = parse_rate_limits(rate_limits)
    return 0, build_summary_row(account_name, five_hour, weekly)


def main() -> None:
    args = parse_args()
    auth_paths = get_auth_paths(args.account_dir, args.account_name)
    if not auth_paths:
        print("No auth files found.", file=sys.stderr)
        sys.exit(1)

    exit_code = 0
    summary_rows: list[JSONDict] = []
    for auth_path in auth_paths:
        current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args)
        exit_code = max(exit_code, current_exit_code)
        if summary_row is not None and not args.raw_json:
            summary_rows.append(summary_row)

    if summary_rows:
        print_summary_rows(summary_rows)
    sys.exit(exit_code)


if __name__ == "__main__":
    main()

ChatGPT on KnightLiブログ

Google I/O後、GPTとGeminiのサブスクリプションはどちらを選ぶべきか？一般ユーザーと開発者向け比較

まず結論

Google I/O後、Geminiは何が変わったか

ChatGPT / GPTは誰に向いているか

Gemini / Google AIは誰に向いているか

一般ユーザーの選び方

開発者の選び方

コンテンツクリエイターの選び方

企業とチームの選び方

Pro / Ultraが必要になるタイミング

最も安く使う戦略

契約前チェックリスト

まとめ

AI Agentはどう進化したのか？2022-2026年の5世代を整理する

概観：5世代のAgentタイムライン

2022年末：第0世代、ChatGPTチャット画面の時代

2023年中頃：第1世代、ツール呼び出しの覚醒

2023年末から2024年：第2世代、工程化ワークフロー

2024年から2025年：第3世代、Computer Useが実画面に入る

2025年から2026年：第4世代、MCP、Skills、常駐デジタルワーカー

2026年以降：第5世代予測、閉ループ、内在記憶、世界モデル

このタイムラインの背後にある6つの法則

本当の堀

最後に

Codexのモバイルリモートアクセス：ChatGPT AppでMac上の開発タスクを追跡する

できること

必要条件

制限

接続方法

スマートフォンでやるべきこと

よくある問題

向いている場面

まとめ

参考資料

ChatGPT File Libraryとは：ファイル保存、容量制限、プライバシー境界

最新の提供範囲

保存されるファイル

新しい会話で使う方法

検索と管理

プラン別容量

単一ファイルの制限

削除とダウンロード

Temporary Chatでは保存されない

データとトレーニング設定

向いている使い方

まとめ

参考資料

OpenAI の新世代 Realtime 音声モデル：GPT-Realtime-2、リアルタイム翻訳、ストリーミング文字起こし

GPT-Realtime-2：音声 Agent の主力モデル

リアルタイム翻訳：多言語音声プロダクト向け

ストリーミング文字起こし：音声をすぐにワークフローへ

価格と提供状況

開発者にとっての意味

安全性と告知も重要

まとめ

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking、GPT-5.5 Pro の違い

早見表

GPT-5.5 とは何か

GPT-5.5 Instant：デフォルト、高速、日常向け

GPT-5.5 Thinking：複雑タスクの主力

GPT-5.5 Pro：研究級で、より重く、より厳密

ツール対応の違い

コンテキストウィンドウの違い

どう選ぶか

日常 Q&A

記事作成、要約、メール修正

コード作成とデバッグ

研究と資料分析

画像生成、Canvas、Memory が必要な場合

短い結論

関連リンク

ChatGPT、Claude Code、Gemini の記憶機構は何が違うのか

ChatGPT：人を中心にした長期的な好み

Memory Sources：個人化の出所を見えるようにする

Claude Code：コードベースとエンジニアリングルールを中心に

Claude Code Auto Memory：プロジェクト経験を自動で蓄積する

Gemini：Google エコシステムの文脈を中心に

3者の主な違い

どう選び、どう使うか

1. 日常会話：なぜ多くの人がまず `ChatGPT` を開くのか

2. コマンドラインでのコーディングと長いタスク：なぜ `Claude` を好む人が多いのか

3. `Gemini` の強みは「何でも正面から勝つこと」ではない