OpenAI on KnightLiブログ

Cerebras IPO 急騰の背景：ウェハースケール AI チップは Nvidia に挑戦できるのか

Mon, 18 May 2026 00:19:51 +0800

Cerebras Systems がついに公開市場に登場しました。

「ウェハースケール AI チップ」で知られる同社は、2026 年 5 月 14 日に Nasdaq で取引を開始しました。ティッカーは CBRS です。Cerebras の公式発表によると、IPO 価格は 1 株 185 ドルで、Class A 普通株 3450 万株を公開しました。この中には、引受会社が 450 万株のオーバーアロットメントオプションを全額行使した分も含まれます。

上場初日、Cerebras の株価は大きく上昇して始まり、一時 386 ドル近くまで上がりました。IPO 価格ベースで、同社の調達額は 55 億ドルを超え、2026 年の米国市場で最も注目された AI ハードウェア IPO の一つになりました。

そのため、多くのメディアは同社を「Nvidia への挑戦者」と呼んでいます。ただし、Cerebras を単に「次の Nvidia」と見るのは正確ではありません。同社の本当の特徴は、従来の GPU とはまったく異なる技術路線を選んでいることです。

Cerebras が作っているのは普通の GPU ではない

Cerebras の中心製品は WSE、正式名称 Wafer-Scale Engine です。

従来のチップ製造では、1 枚のウェハーを多数の小さなチップに切り分け、その後にパッケージング、テスト、出荷を行います。Cerebras は逆のことをします。できるだけウェハー全体をそのまま一つの巨大なチップにします。

この路線の利点は分かりやすいものです。

チップ面積が大きい。
オンチップ計算ユニットが多い。
オンチップ SRAM が計算コアに近い。
チップ内部でのデータ移動距離が短い。
特定の AI 推論・訓練負荷に向いている。

AI 計算では、単純な計算よりもデータ移動の最適化が難しいことがよくあります。Cerebras の考え方は、計算とストレージをできる限り同じシリコン上に残し、データが頻繁にチップ外へ出ることで生じる遅延と消費電力を減らすことです。

これが WSE 路線の最も魅力的な点です。GPU の延長線上で規模を積み増すのではなく、より大きな単一チップによって、より高いオンチップ帯域と低いデータ移動コストを狙っています。

なぜ市場は熱狂したのか

現在の AI チップ市場は、Nvidia への依存度が非常に高い状態です。大規模モデルの訓練、推論サービスの展開、AI データセンターの構築のいずれでも、Nvidia GPU が主流です。

そのため、市場は自然に次のような企業に注目します。

Nvidia のサプライチェーン依存を下げられる企業。
特定の AI ワークロードでより高い性能または低いコストを提供できる企業。

Cerebras はこの二つのストーリーに合っています。

同社は汎用 CPU を作っているわけでも、普通のアクセラレータカードを作っているわけでもありません。AI の訓練と推論を中心にシステムを設計しています。また、同社はウェハースケールチップとクラウド推論プラットフォームが、特定のモデル推論シナリオで非常に高いスループットを提供できると強調してきました。

2026 年、この種のストーリーは市場で増幅されやすいものです。AI インフラはまだ拡大しており、企業、クラウド事業者、モデル企業はさらなる計算資源を探しています。あるチップ企業が特定の場面で「また別の小さな GPU」ではないと証明できれば、市場は高い関心を示します。

OpenAI との協業が期待値を押し上げる

Cerebras が注目されるもう一つの理由は、OpenAI との関係です。

報道によると、Cerebras は OpenAI と 200 億ドル超の協業契約を結んでいます。Sohu の元記事では、2025 年末時点で、この契約に基づく残存履行義務が 246 億ドルに達したとされています。

上場したばかりの AI ハードウェア企業にとって、この種の長期契約は非常に重要です。技術ストーリーだけでなく、大口顧客の需要もあることを示すからです。

ただし、長期注文と最終的な売上をそのまま同一視することはできません。AI データセンターの建設は、製造能力、パッケージング、電力供給、納期、顧客予算、モデル路線の変化に左右されます。特にチップ企業にとって、注文を取ることは第一歩にすぎません。期限通りに納入し、安定して増産し、粗利率を作れるかがより難しい部分です。

顧客集中は依然として大きなリスク

Cerebras のリスクも明確です。顧客集中度が高いことです。

Sohu の元記事によると、G42 は 2024 年に Cerebras の売上の 85% を占め、2025 年には 24% に下がりました。一方で、Mohamed bin Zayed University of Artificial Intelligence は 2025 年の売上の 62% を占めました。つまり、G42 の比率が下がっても、同社の売上は依然として少数の大口顧客に強く依存しています。

AI インフラ企業にとって、顧客集中には二面性があります。

利点は、大口顧客が急成長、長期契約、注文の見通しをもたらすことです。

リスクは、顧客が予算を削減したり、技術路線を変えたり、データセンター建設を遅らせたり、規制環境が変わったりすると、売上の変動が非常に大きくなることです。

だからこそ、Cerebras を見るときに IPO 初日の上昇率だけを見るべきではありません。初日の株価は熱気と期待を反映しています。長期的な評価は、最終的に売上構成、納入能力、利益率、顧客の多様化に左右されます。

技術路線の弱点：メモリ容量

WSE の強みははっきりしていますが、弱点も明確です。

Sohu の元記事では、WSE-3 チップは 44GB の SRAM を搭載し、Nvidia B200 は 192GB のメモリを搭載すると説明されています。Cerebras の設計は大量の計算ユニットと SRAM を同じウェハー上に置くため、データ移動は減らせますが、利用可能なメモリ容量は制約されます。

大規模モデルにとって、メモリ容量はコンテキスト長、バッチサイズ、モデル展開方式に直接影響します。コンテキストウィンドウは長くなり続け、主力モデルは百万 token 級のコンテキストへ向かっています。この流れでは、オンチップ SRAM の容量制限は現実的な制約になります。

従来の GPU は、HBM スタック、パッケージ拡張、複数 GPU の相互接続によってメモリ容量を増やし続けられます。Cerebras のウェハースケール路線では、ウェハー面積がすでに計算ユニットと SRAM に使われているため、単純にメモリを増やすのは難しくなります。SRAM を増やすには、計算面積を犠牲にする可能性があります。

これは Cerebras の技術路線が失敗しているという意味ではありません。特定のワークロードに向けたアーキテクチャ選択だということです。特定の推論シナリオでは非常に強い可能性がありますが、すべての AI 訓練と推論需要をカバーできるとは限りません。

Nvidia を置き換えられるのか

短期的に、Cerebras が Nvidia を置き換える可能性は高くありません。

Nvidia の強みは GPU 性能だけではありません。CUDA エコシステム、開発者ツール、システム統合、ネットワーク相互接続、サーバー全体のソリューション、クラウド事業者のサポート、顧客の移行コストも含まれます。AI 企業が Nvidia を選ぶのは、単一チップのある指標が最高だからではなく、全体のエコシステムが最も安定しているからであることが多いのです。

Cerebras のより現実的な機会は、特定の AI 負荷における補完的な選択肢になることです。

高スループット推論。
特定の大規模モデルサービス。
遅延とオンチップ帯域に敏感なタスク。
単一 GPU サプライチェーンへの依存を下げたい顧客。
性能のために新アーキテクチャを試したいモデル企業。

つまり、同社は「Nvidia キラー」というより、AI 計算市場における攻めた代替路線です。

まとめ

Cerebras の IPO 急騰は、資本市場が AI インフラのストーリーに今も高いプレミアムを払う意思があることを示しています。

同社のウェハースケールチップ路線は確かに独自性があり、普通の AI アクセラレータ企業とは区別されます。OpenAI などの大口顧客との協業もあり、Cerebras には強い市場の想像余地があります。

しかし、リスクも無視できません。顧客集中、納入プレッシャー、メモリ容量制限、エコシステムの壁、Nvidia と競争する際のシステムレベルの差が、同社の到達点を決めます。

一般の読者にとって、Cerebras で最も注目すべきなのは株価がどれだけ上がったかではありません。同社が示したのは、AI 計算の競争には GPU だけでない道があるということです。将来の大規模モデルインフラには、GPU、ウェハースケールチップ、自社開発アクセラレータ、クラウド専用推論プラットフォームが同時に存在するかもしれません。

参考資料

Codex が ChatGPT モバイルからのリモートアクセスに対応、Enterprise ワークスペースで Access Tokens が利用可能に

Sun, 17 May 2026 09:12:07 +0800

OpenAI は 2026 年 5 月 14 日、ChatGPT Enterprise & Edu Release Notes を更新し、Codex に関する 2 つの変更を発表しました。Codex が ChatGPT モバイルアプリからのリモートアクセスに対応し、Enterprise ワークスペースで Codex access tokens を使った制御された自動化が可能になりました。

これはモデル能力の発表ではありません。Codex という製品の形が変わりつつあるという話です。Codex は、ローカル環境や Web セッション内の coding assistant から、長時間実行でき、遠隔から管理でき、企業の自動化ワークフローに接続できる coding agent へ近づいています。

今回の更新内容

OpenAI Help Center によると、Codex は ChatGPT mobile app からのリモートアクセスに対応しました。ユーザーはスマートフォンから実行中の Codex 環境に接続し、長時間タスクを追跡し、必要なタイミングで介入できます。

同時に、ChatGPT Enterprise ワークスペースでは Codex access tokens が利用可能になりました。これは信頼された非対話型のローカルワークフロー向けで、毎回ブラウザでログインしなくても、ChatGPT workspace identity と企業側の制御を使って自動化を実行できます。

今回の更新は、次の 2 つの入口として理解できます。

モバイルリモートアクセス：Codex が長時間タスクを実行しているとき、ユーザーが PC の前にいない問題を解決する。
Access Tokens：企業の自動化スクリプトが制御された ID で Codex ワークフローを使えるようにする。

モバイルリモートアクセスが解決する問題

Codex のタスクは、いつも数秒で終わるわけではありません。実際の開発では、リポジトリを読み、複数ファイルを変更し、テストを実行し、コマンド出力を待ち、エラーに応じて修正を続け、途中でユーザーの承認を求めることがあります。

これまでは、こうしたタスクではユーザーがローカル Mac、デスクトップアプリ、CLI、IDE の近くにいる必要がありました。今後は ChatGPT モバイルアプリがリモートコンソールになり、PC から離れていても Codex を追跡できます。

OpenAI は、モバイル側で基盤環境のリアルタイム状態を確認できると説明しています。対象には次が含まれます。

プロジェクトコンテキスト。
approvals。
screenshots。
terminal output。
diffs。
test results。

ユーザーはスマートフォンから Codex の質問に答え、実行をリダイレクトし、操作を承認し、出力を確認し、複数の connected hosts を切り替えられます。基盤タスクは Mac host や接続されたリモート環境で動き続け、スマートフォンは確認と制御のために使われます。

開発者にとっての価値

この機能は、長時間実行され、途中確認が必要な開発タスクに特に向いています。

たとえば：

Codex が時間のかかるテストを実行していて、外出中に結果を確認したい。
Codex が複数ファイルを変更し、スマートフォンで diff を見てから次のステップを承認したい。
Codex が危険な操作の前で確認待ちになっており、遠隔で処理したい。
ローカル Mac に複数の connected hosts があり、スマートフォンで状態を切り替えて見たい。

価値はスマートフォンでコードを書くことではありません。ずっと PC の前にいる必要がなくなることです。Codex は元の環境で作業を続け、ユーザーは重要な節目だけ介入します。

これは Codex が「バックグラウンド Agent」に近づいていることも示しています。タスクは継続実行でき、ユーザーが常時オンラインでなくてもよい一方、承認と制御は人間側に残ります。

Access Tokens が解決する問題

Codex access tokens は ChatGPT Enterprise ワークスペース向けです。重点は個人ユーザーの通常ログインではなく、企業内の信頼された自動化です。

企業には、非対話的に実行したいローカルまたは内部ワークフローがよくあります。

定期的なコードチェック。
管理されたマシン上での Codex ワークフロー起動。
Codex と社内開発ツールチェーンの接続。
ブラウザを開かずにワークスペース ID を使うこと。

Access tokens により、これらのワークフローは ChatGPT workspace identity を持って実行され、同時に企業ポリシーの制御を受けます。一時的な手動ログインより自動化に向いており、個人資格情報の共有よりガバナンスに載せやすい仕組みです。

普通の API key ではない

この点は重要です。Codex access tokens は、単なる万能 API key と理解すべきではありません。

OpenAI の説明では、access tokens は ChatGPT Enterprise ワークスペースで利用でき、管理者はワークスペースレベルの可用性を管理でき、許可されたロールを持つメンバーは自分の tokens を作成できます。利用可能な場合、ガバナンス画面にも access token の活動が反映されます。

つまり、access tokens は企業の権限、ロール、監査フレームワーク内に置かれています。

管理者がワークスペースで有効にするかを決められる。
すべてのメンバーが当然作成できるわけではない。
token の活動はガバナンスビューに入る可能性がある。
ChatGPT workspace identity と企業側の制御を継承する。

個人が長期秘密鍵を気軽に作成するのとは違います。

安全な初期設定：Remote Control はデフォルトでオフ

Codex mobile remote access は、コード環境、ターミナル出力、diff、テスト結果、操作承認に関わります。デフォルトで有効なら、企業にとって明確なセキュリティリスクになります。

そのため OpenAI の初期設定は保守的です。remote control はデフォルトでオフで、管理者または owner が Workspace settings で有効にする必要があります。

モバイルリモートアクセスの有効化には、次の要素が関係する場合があります。

workspace-enabled Remote Control access。
SSO。
多要素認証。
passkey。

これは、アプリを更新したら全員が自動的に使える機能ではなく、企業の IT とセキュリティチームが設定すべき機能です。

利用前に必要な更新

OpenAI は、モバイルリモートアクセスを使うには両側の更新が必要だと説明しています。

ChatGPT mobile app。
macOS 上の Codex app。

ワークスペース側の要件によっては、セットアップ時に SSO、多要素認証、passkey フローが発生することもあります。

実際に導入する場合、企業管理者はまず Workspace settings の remote control 設定と、どのメンバーまたはロールに利用を許可するかを確認する必要があります。

企業での Codex 利用への影響

今回の更新は、Codex を 2 つの方向へ進めます。

第一に、Codex は長時間タスクに向きます。以前は長時間タスクではユーザーがずっと見ている必要がありましたが、今後はスマートフォンで状態を確認し、操作を承認できるため、Codex をバックグラウンドで動かしやすくなります。

第二に、Codex は企業自動化に向きます。Access tokens により、非対話型ワークフローに正式な ID 経路ができ、内部 CI、コードレビュー、スクリプト、開発プラットフォームとの接続がしやすくなります。

この 2 つを合わせると、Codex は単なる開発者の手元の AI 助手ではなく、企業の開発フローに組み込まれる管理可能な agent へ近づいています。

注意すべき境界

今回の更新は便利ですが、Codex を完全に無人で任せてよいという意味ではありません。

企業利用では、引き続き次の点に注意が必要です。

どのプロジェクトでリモート制御を許可するか。
どのコマンドに承認が必要か。
token をどう作成、ローテーション、失効するか。
mobile remote access が社内のデバイス管理ポリシーに合うか。
ターミナル出力、スクリーンショット、diff に機密情報が含まれないか。
監査ログとガバナンス画面が社内コンプライアンス要件を満たすか。

特に access tokens は、自動化フローに入った時点で他の企業資格情報と同じように扱うべきです。最小権限、定期的なローテーション、ハードコード回避、不要 token の速やかな失効が必要です。

まとめ

今回の OpenAI Codex 更新は焦点が明確です。ChatGPT モバイルから Codex の長時間タスクにリモートアクセスでき、Enterprise ワークスペースでは Codex access tokens による制御された自動化が可能になりました。

前者は、開発者がずっと PC の前にいる必要を減らします。後者は、企業が Codex をより正式に社内ワークフローへ接続できるようにします。両者を合わせると、Codex は対話型 coding assistant から、遠隔管理、監査、自動化接続に向いた企業向け coding agent へ進んでいることが分かります。

参考リンク：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

Codex の利用上限はなぜ突然リセットされるのか？Usage Limits の履歴と情報源

Sun, 17 May 2026 08:36:15 +0800

Codex を使っていると、自分の通常の reset 時刻が来ていないのに、usage limits が突然回復していることがあります。このような「予告なしのリセット」は今回が初めてではなく、上限ルールが恒久的に緩くなったことを意味するとは限りません。障害補償、製品プロモーション、成長マイルストーン、あるいは特定のウィンドウやアカウント状態だけを対象にしたバックエンド側のリセットである可能性があります。

このスクリーンショットは、OpenAI Codex チームを率いる Tibo Sottiaux（@thsottiaux）が X に投稿した告知です。利用上限を気にしているユーザーにとって重要なのはモデルの細部ではなく、彼がその夜に usage limits を reset すると述べている点です。文脈を見ると、これは通常の周期的な更新ではなく、補償としてのリセットだと考えられます。

まず結論

Codex の利用上限が突然リセットされる理由は、おおまかに次のように分けられます。

障害補償：モデルや Codex サービスの問題でユーザーの上限が無駄に消費され、OpenAI が補償としてリセットする。
リリースやプロモーション：新モデル、新クライアント、新機能の公開時に、一時的な増量やリセットが行われる。
成長マイルストーン：Codex のユーザー規模が一定の節目に達したとき、利用継続を促すために上限をリセットまたは拡大する。
バックエンド方針の調整：一部の上限ウィンドウやアカウント状態だけがリセットされ、UI では範囲が明確に説明されない。

よくある誤解は、「リセット」と聞くとすべての上限ウィンドウが回復したと考えてしまうことです。実際には、Codex には短時間ウィンドウ、weekly limit、モデルごとの消費重み、プランごとの制限が同時に存在する場合があります。特別なリセットは、その一部だけに効くことがあります。

このスクリーンショットが示していること

スクリーンショットでは、Tibo が 2026 年 5 月 15 日に更新を投稿し、チームが監視を続け、その夜に usage limits をリセットすると述べています。前の投稿では一部ユーザーからの報告を調査中だと説明していたため、このリセットはサービスの揺らぎに対する補償と見るのが自然です。

ユーザー向けには、次の 3 点が重要です。

これは各ユーザーの通常周期による回復ではなく、チーム側の能動的なリセットです。
このリセットには明確な出来事の背景があり、恒久的な上限引き上げではありません。
「usage limits」という表現だけでは、5 時間ウィンドウや weekly limit がすべて含まれるかは分かりません。

そのため、上限が回復していても、まずは特別な reset event として捉えるべきです。

なぜ Codex のリセットは予告なしに見えるのか

Codex の上限は、単純に「毎日何時に更新される」ものではありません。UI には残り上限やパーセンテージだけが表示されることが多い一方、バックエンドでは次のような要素を同時に追跡している可能性があります。

数時間単位の短時間ウィンドウ。
週単位またはそれ以上の上限。
モデルごとの消費重み。
ローカル Codex、Cloud Task、IDE/CLI などの入口の違い。
Plus、Pro、Business、Team などのプラン差。
特別リセットの対象となるアカウント状態かどうか。

OpenAI が特別リセットを行っても、ユーザーはそれが通常周期による回復なのか、補償なのかを UI だけでは判断できない場合があります。短時間ウィンドウだけが回復した場合でも、weekly も回復するはずだと誤解されやすく、weekly が変わらないと「リセットが失敗した」と見えることがあります。

OpenAI の Codex GitHub issue でも、この透明性の問題が指摘されています。公開メッセージでは Codex rate limits が reset されたと説明されても、製品 UI はどのウィンドウがリセットされたのか、weekly limit が含まれるのか、すべての有料プランに同じように適用されたのかを明確に示していませんでした。

これまでの主なリセットの型

1. 2026 年 2 月：リリース期と一時的な増量

Codex デスクトップアプリと GPT-5.3-Codex のプロモーション時期には、usage limit reset と一時的な 2x rate limits がコミュニティで話題になりました。Reddit では、Codex app の公開時に期間限定の 2x rate limits と usage limit reset があったという投稿が見られます。

この種のリセットは、新しいクライアント、モデル、ワークフローを試してもらうためのリリース期の施策と考えられます。

2. 2026 年 3 月：ランダムなリセットと異常消費の議論

3 月前後には、コミュニティで「random usage reset」や「weekly limit reset daily」といった話題が何度も出ました。weekly limit が予定より早く回復したという報告や、新しい Codex モデル、安全ブロック、異常な上限消費、バグ修正と関係しているのではないかという見方がありました。

これらは公式発表ではありませんが、ユーザー側では通常スケジュール以外の回復が複数回観測されていたことを示しています。

3. 2026 年 4 月：成長マイルストーンと有料プランのリセット

4 月下旬には、Codex が週間アクティブユーザー 300 万人に達し、OpenAI が rate limits をリセットしたという報道がありました。今後の成長マイルストーンでも、ユーザーにより多くの利用余地を与える計画だとされています。

GitHub issue でも、Tibo が 4 月 28 日に X で「good week」を祝って有料プランの Codex rate limits をリセットし、GPT-5.5 でより多く構築できるようにしたという投稿が引用されています。ただし同じ issue では、どの上限ウィンドウが実際にリセットされたのか、weekly limit が含まれたのかを UI が明確に示していないとも指摘されています。

つまり、成長やイベントに伴うリセットでも、説明の曖昧さがユーザーの混乱につながりやすいということです。

4. 2026 年 5 月：障害補償型のリセット

今回のスクリーンショットは、より分かりやすい障害補償型のリセットです。Tibo はチームが問題を見つけ、その夜に usage limits をリセットすると述べています。OpenAI Status でも、2026 年 5 月 13 日に Codex 関連のエラー率上昇と遅延悪化が記録されています。

普通のユーザーにとって重要なのは、どのモデルの細部が原因だったかではありません。サービス側の問題で上限が異常に消費された場合、OpenAI が特別リセットで補償することがある、という点です。

リセットの理由をどう判断するか

Codex の上限が突然回復した場合は、次の順番で確認するとよいです。

自分の通常 reset 時刻に達していないか確認する。
OpenAI Status で Codex、モデルエラー、遅延、性能低下の記録を見る。
Tibo、OpenAI 公式アカウント、Codex GitHub issue に説明があるか確認する。
コミュニティで「突然 reset」「異常な消費」「weekly が戻らない」といった報告が集中していないか見る。
短時間ウィンドウと weekly limit を分けて考え、必ず同時に回復するとは決めつけない。

公式の事故補償であれば、状態ページ、責任者の告知、または多数のユーザー報告がセットで見つかることが多いです。一方、バックエンド側の部分的な更新だけなら、明確な告知がない場合もあります。

情報源の信頼性を分けて見る

この種の情報は、層を分けて見るのが安全です。

公式ステータスページ：障害、エラー率、遅延、復旧時刻の確認に最も向いています。
Tibo / OpenAI 公式アカウント：特別リセット、補償、プロモーションの説明を確認するのに向いています。
OpenAI Codex GitHub issue：UI、上限ウィンドウ、実際の挙動に関するユーザー報告を見るのに向いています。
Reddit / X の議論：同じ現象が広く起きているかを見るのに有用ですが、公式確認ではありません。
第三者ニュースやブログ：時系列の補足には便利ですが、公式情報や原典で確認する必要があります。

記事を書くときや判断するときは、これらを分けて扱うべきです。「OpenAI Status に障害が記録された」は公式の状態情報です。「Reddit でランダムリセットが報告された」はコミュニティ観測です。「GitHub issue で UI の不透明さが指摘された」はユーザー提出の製品課題です。

まとめ

Codex の利用上限が突然リセットされるのは、単に「無料の追加枠が来た」という話ではありません。障害補償、リリース期のプロモーション、成長施策、バックエンド方針の変更など、複数の理由があり得ます。分かりにくいのは、Codex に複数の上限ウィンドウがあり、特別リセットがすべてを対象にするとは限らない点です。UI が reset scope を明確に示さないこともあります。

このような状況に遭遇したら、まずクライアント上の実際の上限を確認し、OpenAI Status、Tibo の投稿、Codex GitHub issue、コミュニティ報告を照らし合わせるのが最も安全です。1 回の reset だけで長期的なルール変更だと判断せず、weekly limit、短時間ウィンドウ、すべてのプランが同時に回復すると決めつけない方がよいです。

参考リンク：

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の確認が重要になります。

参考資料

GPT-5.5 Prompt 移行ガイド：古いプロンプトはまず削ってから直す

Fri, 15 May 2026 01:25:27 +0800

OpenAI は API ドキュメントで GPT-5.5 prompting guide を更新しました。このガイドで最も価値があるのは、さらに長いプロンプトテンプレートを示していることではありません。GPT-5.5 へ移行するとき、多くの古い prompt はむしろ短くすべきだ、と示している点です。

公式ドキュメント：https://developers.openai.com/api/docs/guides/prompt-guidance

一言でいうと、GPT-5.5 の prompting の方向性は次の通りです。プロセスを減らし、結果を書く。ルールを積み上げるより、受け入れ条件を定義する。always や must を乱用せず、いつ止めるか、いつ検証するか、いつ証拠を補うかを書く。

古い prompt をなぜ書き直す必要があるのか

多くの本番システムの prompt は、層を重ねるように作られています。モデルが不安定ならルールを 1 つ足す。ツール呼び出しで失敗したら禁止事項を足す。出力が長すぎたらフォーマット指定を足す。時間が経つと、system prompt は重い運用マニュアルになります。

この書き方は古いモデルでは役に立つこともありました。モデルが逸れないように、より細かい手順制約が必要だったからです。しかし GPT-5.5 では、OpenAI の推奨は明確です。古い prompt stack をそのまま持ち込まないことです。

プロセスを指定しすぎると、いくつかの副作用があります。

ノイズが増え、モデルが大量の古いルールから本当に重要な制約を探す必要がある。
探索空間が狭くなり、モデルがより効率的な解法を選びにくくなる。
出力が機械的になり、問題解決というよりスクリプト実行のように見える。
古いルール同士が衝突し、ツール呼び出しも最終回答も悪くなる。

GPT-5.5 には、各手順を固定するより、目標状態、制約、利用可能な証拠、最終出力を説明する prompt のほうが向いています。

outcome-first：まず完了条件を定義する

公式ドキュメントは、GPT-5.5 には outcome-first prompt が向いていると繰り返し強調しています。

つまり、prompt ではまず次を明確にすべきです。

目標とする結果は何か。
何をもって成功とするか。
どの制約を破ってはいけないか。
現在利用できるコンテキストは何か。
最終回答にどのフィールドやセクションが必要か。
証拠が不足しているときにどうするか。

あまり推奨されない書き方：

まず A を確認し、次に B を確認し、その後すべてのフィールドを比較し、すべての例外を考え、どのツールを呼ぶか決め、ツールを呼び、最後に完全な過程を説明する。

GPT-5.5 により向いた書き方：

ユーザーの問題を解決する。成功条件：
- 利用可能なポリシーとアカウントデータに基づいて判断する
- 操作が許可される場合は、返信前に操作を完了する
- 最終出力には completed_actions、customer_message、blockers を含める
- 重要な証拠が不足している場合は、最小限必要なフィールドだけ質問する

これは prompt を曖昧にすることではありません。制御点を「手順の順番」から「結果と境界」へ移すことです。モデルは検索、推論、ツール呼び出しの経路を自分で選べますが、成功条件には責任を持つ必要があります。

絶対ルールを減らし、判断ルールを書く

古い prompt では ALWAYS、NEVER、must、only が大量に出てきがちです。これらの言葉は使ってはいけないわけではありません。ただし、安全ルール、必須フィールド、禁止アクションのように、本当に破れない制約にだけ残すべきです。

「いつ検索するか」「いつユーザーに聞くか」「いつ続けるか」「いつ止めるか」のような判断には、GPT-5.5 では decision rule のほうが向いています。

たとえば、こう書くだけでは不十分です。

`1`	`常に最初に 3 回検索する。`

こう書くほうがよいです。

まず中核問題をカバーする検索を 1 回行う。最初の数件の結果で重要事実を支えられるなら、検索を止めて回答する。証拠が矛盾している、不足している、または結論を支えられない場合だけ、検索を続ける。

この書き方はモデルに判断余地を与え、同時に停止条件も与えます。Web 検索、retrieval、ファイル検索、データベース問い合わせを使うプロダクトでは重要です。ツール呼び出しが 1 回増えるたびに、遅延とコストが増えるからです。

retrieval budget を設定する

GPT-5.5 prompt に単独で追加する価値があるルールの 1 つが retrieval budget です。

これは金額の予算ではありません。検索をいつ止めるかのルールです。証拠がいつ十分なのか、いつ探し続けるべきか、いつ証拠不足を認めるべきかをモデルに伝えます。

実用的な書き方：

通常の Q&A では、短く識別しやすいキーワードでまず広めに 1 回検索する。最初の数件の結果が中核リクエストを支えられるなら、その結果に基づいて回答し、検索を続けない。結果が矛盾する、重要事実が欠けている、または結論を支えられない場合のみ追加検索する。

このルールは、よくある 2 つの問題を減らします。

検索不足で、証拠のない回答を出す。
検索しすぎて、ツールループで時間を浪費する。

さらに重要なのは、証拠が見つからないことを、事実上の「いいえ」として扱うべきではないという点です。正しい挙動は、証拠不足を明示すること、またはより小さい問いに分けて確認することかもしれません。

reasoning effort を最初から上げない

GPT-5.5 は推論効率が高いため、OpenAI は low と medium を再評価することを勧めています。品質が足りないと感じたときに、すぐ reasoning effort を上げるべきではありません。

より安定した順序は次の通りです。

まず prompt が目標、出力形式、停止条件を明確にしているか確認する。
テスト、引用、レビュー、レンダリング確認などの検証ループを追加する。
ツール呼び出しに持続性ルールと完了基準を追加する。
それでも足りない場合に reasoning effort を上げる。

言い換えると、reasoning.effort は最後の調整つまみに近いものです。明確な prompt 設計の代わりにすべきではありません。

短い分類、フィールド抽出、サポートチケット振り分け、形式変換なら、低い推論コストから始められます。長文書の統合、複数ソースの衝突判断、戦略作成、複雑な調査では、medium 以上を検討します。

text.verbosity は出力を制御するが、思考を制御するわけではない

GPT-5.5 は出力形式をかなり制御できます。公式ドキュメントは、prompt 内の出力要件と合わせて text.verbosity を使うことを勧めています。

デフォルトの text.verbosity は medium です。より短く、よりすっきりした返信が必要なプロダクトでは low を使えます。ただし、すべてを短くすべきという意味ではありません。

典型的な使い方：

ユーザー向けの状態更新と最終要約は短くする。
コード、設定、構造化結果では、引き続き可読性を求める。
「短くする」ために、フィールドの完全性、引用、必要な caveat を犠牲にしない。

これはコード系プロダクトで特に有用です。チャット返信は短くしつつ、生成コードには読みやすい変数名、明確な構造、必要なコメントを求められます。

preamble と phase：長いタスクを見えるようにする

GPT-5.5 は複雑なタスクで、可視テキストを出す前に推論、計画、ツール呼び出し準備を行うことがあります。ストリーミングプロダクトでは、ユーザーは最初の token までの待ち時間を感じます。

公式の推奨は、多段階、ツール密集、長時間実行のタスクでは、モデルに短い preamble を先に出させることです。完全な計画を説明する必要はありません。「まず何をするか」だけを伝えれば十分です。

例：

`1`	`まず関連ファイルと既存設定を確認し、その後で変更案を出します。`

Responses API の長いタスクやツール密集ワークフローでは、assistant item の phase にも注意が必要です。アプリが previous_response_id を使う場合、API は前の assistant 状態を自動で保持します。アプリが assistant 出力を手動で再生する場合、元の phase 値を保持する必要があります。

一般的な約束：

phase: "commentary"：中間状態の更新。
phase: "final_answer"：最終回答。
user message には phase を付けない。

これは低レベル実装の細部に見えますが、ツール呼び出し、状態更新、最終回答を持つプロダクトでは重要です。手動再生時に phase を失うと、モデルが途中経過と最終結論を混同しやすくなります。

モデルに自分の作業を検証させる

GPT-5.5 guide には非常に実用的な点があります。検証可能なタスクでは、モデルに検証ツールと検証ルールを与えることです。

コード Agent には、明確に次を要求できます。

変更後に関連する単体テストを実行する。
必要なら type check や lint を実行する。
影響するパッケージが大きい場合は build を実行する。
全量検証が高コストなら、少なくとも最小の smoke test を行う。
検証できない場合は、理由と次善の確認方法を説明する。

視覚やページ成果物では、まずレンダリングし、レイアウト、切り抜き、余白、欠落内容、視覚的一貫性を確認するよう求められます。

エンジニアリング計画では、要件との対応、関連ファイル/API/システム、状態遷移、検証コマンド、失敗時の挙動、プライバシーとセキュリティ、実装に影響する未決事項を含めるよう求められます。

この種のルールは「もっと注意して」よりずっと効果的です。「注意」を実行可能なチェックに変えるからです。

GPT-5.5 に向いた prompt 骨格

OpenAI ドキュメントの構造は、簡略化すると次のようになります。

Role:
あなたの役割と、作業する文脈。

# Personality
口調、協力スタイル、温度感や視点が必要かどうか。

# Goal
ユーザーに見える目標結果。

# Success criteria
最終回答前に満たすべき条件。

# Constraints
安全、ビジネス、証拠、権限、コスト、副作用の境界。

# Output
出力構造、長さ、口調、必須フィールド。

# Stop rules
いつ続けるか、再試行するか、降格するか、質問するか、停止するか。

この骨格のポイントは、すべての prompt が同じ見出しを持つべきということではありません。複雑なタスクの prompt は、モデルに目的地、境界、成果物を伝えるべきであり、すべての手順をハードコードすべきではないということです。

古い prompt を移行する実際の順序

GPT-4.1、GPT-4o、GPT-5.2、GPT-5.4 向けの古い prompt がある場合、一度に大きく変えるのはおすすめしません。

より安定した移行順序：

まずモデルだけ切り替え、現在の reasoning effort と出力パラメータを固定する。
既存 eval または実例を実行し、挙動の変化を見つける。
明らかに古い、重複する、衝突するプロセスルールを削除する。
「手順要求」を「成功基準」と「停止条件」に変える。
retrieval budget、引用ルール、証拠不足時の挙動を追加する。
ツールタスクに検証ループを追加する。
最後に reasoning.effort と text.verbosity を調整する。

eval がない場合でも、少なくとも代表的なタスクを用意します。簡単な Q&A、複雑な検索、ツール呼び出し、フォーマット出力、拒否/降格、長いタスクの完了です。1 つの demo case だけで prompt の良し悪しを判断しないことです。

古い prompt 移行チェックリスト

実際に移行するときは、まずこのチェックリストを通します。目的は単に prompt を短くすることではなく、無効な制約を削除し、重要な制約を検証可能な形にすることです。

チェック項目	よくある問題	推奨対応
重複ルール	同じ指示が複数箇所にあり、表現が一致しないこともある	1 つの明確なルールに統合し、最終版だけ残す
絶対語	`ALWAYS`、`NEVER`、`must`、`only` が everywhere	安全、コンプライアンス、権限、必須フィールドにだけ残す
停止条件なし	検索、分析、修正を続けるよう要求するが、いつ止めるかがない	証拠十分、検証成功、ターン数やコスト上限など stop rules を追加
検証コマンドなし	「正しくする」と書くだけで、テスト、lint、引用、確認方法がない	テスト、型チェック、build、引用、smoke test など具体化
プロセスが細かすぎる	すべての手順を固定し、モデルがよりよい経路を選べない	目標、成功基準、境界、出力要件に書き換える
古いモデル用補丁	古いモデルの弱点向け制限が残っている	まず削除し、eval で本当に必要か判断する
ツールルールが曖昧	「必要ならツールを使う」だけ	いつ呼ぶか、いつ止めるか、失敗時にどう降格するかを書く
出力形式が漂う	形式指定はあるが、フィールド完全性のルールがない	必須フィールド、任意フィールド、証拠不足時の出力を定義

1 つだけやるなら、「停止条件なし」と「検証コマンドなし」を優先します。この 2 つは、GPT-5.5 を無限ツールループにしたり、証拠なしで整った回答を出させたりしやすいからです。

GPT-5.5 prompt 例：旧 vs 新

以下は完全な system prompt ではなく、移行時によくある部分的な書き換えです。

例 1：検索 Q&A

旧：

`1`	`回答前に必ず 3 回以上検索する。関連するすべての結果を読む。完全な説明を出す。`

新：

まず中核問題をカバーする検索を 1 回行う。最初の数件の結果で重要事実を支えられるなら、検索を止めて回答する。結果が矛盾する、または重要事実が不足している場合は追加検索する。最終回答では根拠を説明し、証拠不足なら明確にそう述べる。

新しい書き方では、「検索回数」を「証拠が十分か」に変えています。モデルに続ける理由と止める理由の両方を与えます。

例 2：コード変更

旧：

`1`	`慎重にコードを修正する。既存ロジックを壊さない。完了後に変更点を教える。`

新：

ユーザー要求に対する最小限必要なコード変更を行う。成功基準：
- タスクに関係するファイルだけを変更する
- ユーザーが明示しない限り、既存の公開 API 互換性を保つ
- 変更後に関連単体テストを実行する。実行できない場合は理由と次善の検証方法を説明する
- 最終要約には変更点、検証結果、残るリスクを含める

新しい書き方は、ただ「慎重に」と言うのではなく、ファイル範囲、API 互換性、テストコマンド、リスク説明に慎重さを落とし込んでいます。

例 3：構造化出力

旧：

`1`	`JSON を出力する。余計な内容は出さない。フィールドは完全にする。`

新：

Markdown なしの厳密な JSON を出力する。必須フィールド：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
証拠が不足している場合、status は "needs_more_info" にし、evidence を捏造しない。

新しい書き方は JSON を求めるだけでなく、証拠不足時の合法的な出力経路も定義しています。モデルは「完全なフィールド」と「証拠不足」の間で情報を作る必要がなくなります。

パラメータの組み合わせ

reasoning.effort と text.verbosity は別々に考えるべきではありません。前者はモデルがどれだけ推論するか、後者は出力の詳しさを左右します。よくある誤解は、品質が足りなければ reasoning.effort を上げ、出力が長ければ prompt を強く書くことです。より安定するのは、タスク種別で組み合わせることです。

場面	reasoning.effort	text.verbosity	説明
フィールド抽出、分類、短い形式変換	`none` または `low`	`low`	低遅延を重視し、schema を明確にする
サポート振り分け、簡単なツールルーティング	`low`	`low` または `medium`	ルールが明確なら高推論は不要
通常 Q&A、軽い検索要約	`low` または `medium`	`medium`	判断は必要だが、高推論をデフォルトにしない
複数文書統合、衝突判断	`medium`	`medium`	まず証拠ルールと引用を整え、その後 effort を検討
複雑なコード変更、長い Agent タスク	`medium` または `high`	ユーザー返信は `low`、コード出力は明確に	チャット更新は短く、コードと diff は可読に
戦略、計画、リスク分析	`medium` または `high`	`medium` または `high`	トレードオフ、リスク、仮定の説明が必要

多くのアプリでは、まず low または medium から始めます。prompt が成功基準、停止条件、検証ルールをすでに明確にしていて、それでも重要制約を落とす場合にだけ、reasoning.effort を上げます。

text.verbosity も低ければよいわけではありません。低 verbosity は状態更新、短いサポート返信、操作結果要約に向いています。一方、コード、設定、移行計画、監査説明では、短すぎる出力はレビューしづらくなります。

残すべきルール

GPT-5.5 へ移行することは、古い prompt をすべて削ることではありません。次のルールは通常残すべきであり、より明確に書くべきです。

安全ルール：実行できないアクション、生成できない内容、拒否または降格すべき場面。
コンプライアンスルール：業界ポリシー、地域制限、年齢制限、監査要件、承認要件。
プライバシールール：個人情報処理、機密データのマスキング、ログ制限、データ外部送信の制限。
出力フィールド：API 応答、JSON schema、表フィールド、フロントエンドコンポーネントが必要とする固定構造。
業務境界：返金ルール、アカウント権限、サービスレベル、契約範囲、有人サポートへのエスカレーション条件。
ツール権限境界：呼べるツール、確認が必要なツール、禁止ツール。
引用と証拠ルール：いつ出典が必要か、証拠が衝突したときにどうするか。

これらは古い荷物ではなく、プロダクト契約です。違いは、移行時には長いスローガンから実行可能な制約へ書き換えることです。

例：

`1`	`ユーザーのプライバシーを漏らさない。`

これは次のようにできます。

最終回答に完全な電話番号、身分証番号、access token、API key、内部ユーザー ID を出力しない。参照が必要な場合は、電話番号の下 4 桁だけを残すなど、マスク済み形式だけを表示する。

誤って削ってはいけないもの

prompt を削るときに一番危険なのは、不要な文章を削ることではなく、本物のシステム境界を一緒に削ることです。次の内容は、古く見えても軽く消すべきではありません。

プライバシーとデータ処理要件：特にログ、エクスポート、システム間転送、第三者ツール呼び出しに関するルール。
安全と権限制限：データ削除、送金、メール送信、権限変更、shell コマンド実行など高リスク操作の確認ルール。
引用形式：プロダクトが citation、脚注、出典一覧、監査チェーンに依存しているなら、場所を取るだけで削らない。
ツール呼び出し境界：読み取り専用ツール、書き込み可能ツール、ユーザー確認が必要なツール。
失敗時の挙動：API タイムアウト、データ欠落、検索失敗、権限不足時の降格方法。
業務上の厳格ルール：価格、返金、停止、リスク管理、コンプライアンス審査など、モデルが自由に判断すべきでないルール。

簡単な判断方法は、削っても出力スタイルが少し変わるだけなら削除候補にする。削ると越権、漏えい、誤操作、誤った約束、監査断絶につながるなら残し、より精密に書き換える、というものです。

まとめ

GPT-5.5 prompting guide の核心は、「より高度なプロンプトを書く」ことではありません。古い prompt にある、プロセスを指定しすぎた部分を削ることです。

GPT-5.5 に向いた prompt は次を満たすべきです。

手順ではなく目標を優先する。
「うまくやる」ではなく成功基準を明確にする。
無限検索や無限ツールループではなく停止条件を持つ。
証拠なしに答えたり検索し続けたりせず、証拠予算を持つ。
モデルの自覚だけでなく検証ルールを持つ。
最初から reasoning effort を上げず、パラメータ調整は後にする。

古い system prompt がすでに長いなら、GPT-5.5 への移行の第一歩は内容を追加することではなく、削ることかもしれません。本当に破れないルールを残し、プロセスの細部を結果、境界、チェック項目へ変えるほうが、さらに prompt を積み上げるより効果的です。

参考資料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model

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

マスク対 OpenAI 裁判の焦点：非営利ミッション、支配権、AI 競争

Fri, 08 May 2026 23:37:37 +0800

Elon Musk、OpenAI、Sam Altman の訴訟は、表面的には元パートナー同士の対立に見える。しかし深いところでは、AI 業界にとって重要な構造問題を突いている。最先端モデルの開発に巨額資本が必要になったとき、公益、オープン性、安全性を掲げて設立された組織は、どのような条件で商業化へ進めるのか。

この争いが注目され続けるのは、当事者がシリコンバレーで極めて影響力のある人物だからだけではない。OpenAI の三つの緊張関係、すなわち非営利ミッションと商業資金調達、AI safety の語りと市場競争、創業者の貢献とその後の支配権が同時に表面化しているからだ。

裁判で本当に争われていること

公開報道によれば、Musk 側の主張は、OpenAI は設立時に明確な公益ミッションを持っており、Musk の初期寄付と関与は、個人を富ませるのではなく人類全体に資する AI 組織を支えるためだった、というものだ。OpenAI が後に営利 entity を作り、巨額投資を受け、高評価額の企業へ成長したことは、当初の約束から外れたと主張している。

OpenAI 側の反論は、Musk の寄付には彼が主張する永続的な制限は付いていなかった、というものだ。OpenAI が営利構造を作ったのは、安全な先進 AI を開発する使命を続けるために、compute、人材、資本を得る必要があったからだと説明する。また OpenAI は、Musk が営利化そのものに反対していたのではなく、支配権を望んでいたと見ている。

したがって、これは単純な「非営利 vs 営利」ではない。より具体的な問題は、OpenAI の当初のミッションにどのような法的拘束力があったのか、Musk の 3800 万ドルの拠出は通常の寄付だったのか、実行可能な条件付き charitable trust だったのか、そして後の構造変更が非営利側の支配下に残っていたのか、である。

Musk 側の物語

Musk は裁判で、AI が少数の商業巨人に支配されるのを防ぐために OpenAI へ関わったと強調している。彼は OpenAI の構造変更を慈善団体の略奪として描き、それが認められれば米国の慈善寄付の基盤を壊すと警告する。

この物語が強いのは、OpenAI の初期イメージと後の商業的成功の落差を捉えているからだ。OpenAI は当初、安全、オープン性、公共利益を中心にした非営利研究ラボという印象を与えていた。現在の OpenAI は、Microsoft などの大手と深く結びついた、世界の AI 競争における重要な商業 entity である。

ただし Musk 側にも課題がある。彼自身が何らかの営利的な arrangement を受け入れていたのか、という点だ。もし当時、営利 entity の設立を議論していたが、非営利 control や自分の支配権を求めていたのだとすれば、争点は「営利構造があり得たか」ではなく、「誰がその構造を支配するか」になる。

OpenAI 側の物語

OpenAI の公開ページと裁判での弁護は、別の線を強調している。OpenAI は常に非営利組織によって governance されており、営利 entity は AGI ミッションに必要な resources を調達するために作られた。Musk が後に訴訟を起こしたのは、支配権を得られず、競合の xAI を創業した後だった、という見方である。

OpenAI はまた、Musk が OpenAI の非営利組織に 3800 万ドルを寄付し、その資金は mission に使われたと説明する。現在 Musk はそれを投資として再解釈し、OpenAI に対する権利を主張している、というのが OpenAI の立場だ。OpenAI によれば、Musk は絶対的支配権を求め、OpenAI を Tesla に組み込む案も出したが、条件が拒否された後に離れた。

この物語の狙いは、争点を「OpenAI が公益ミッションを裏切った」から「Musk が望む支配権を得られなかった」へ移すことだ。陪審と裁判官がこの枠組みを受け入れれば、Musk の道徳的批判は弱まり、事件は遅れて表面化した創業者支配権争いに近くなる。

なぜ非営利構造が重要なのか

OpenAI の複雑さは、単に商業収入があることではなく、governance structure にある。OpenAI は伝統的な純商業会社でも、市場競争から切り離された研究機関でもない。非営利 entity が営利子会社を control し、資本市場から compute と人材を得ながら、「全人類に利益をもたらす」という mission を保持しようとしている。

この構造には現実的な理由がある。frontier model の訓練には data center、chip、研究者、safety evaluation、世界規模の product infrastructure が必要だ。寄付だけでこの規模を長期的に支えるのは難しい。

しかし構造が複雑になるほど、信頼コストも上がる。非営利 control は本当に有効なのか。商業 partnership は研究方向を変えるのか。safety commitment と product growth が衝突したとき、誰が最終決定権を持つのか。Musk v. OpenAI が広く注目されるのはそのためである。

裁判は AI safety の国民投票ではない

この裁判では AI safety、AGI risk、open-source promise、public benefit といった概念が繰り返し登場する。しかし本質的には法律事件である。裁判所が扱うのは寄付の性質、charitable trust、組織 governance、支配権、不当利得であり、業界全体の AI safety policy を作ることではない。

つまり、Musk が勝っても、裁判所が包括的な AI safety governance framework を直接示すとは限らない。OpenAI が勝っても、商業化や mission drift への疑問が消えるわけではない。

重要なのは、この判決が示す governance signal である。AI 組織の初期の公開 commitment はどこまで拘束力を持つのか。創業者の寄付と後の商業化の境界はどこか。非営利が営利 AI 会社を control する構造には、より強い外部監督が必要なのか。

AI 業界への示唆

この訴訟は AI 業界全体への警告でもある。大きな public-benefit narrative が巨額資本と結びつくなら、その重みに耐える明確な governance mechanism が必要だ。そうでなければ、会社が成功した後に、初期 mission、寄付者の期待、従業員 incentive、投資家 return、社会的 risk が同じ法廷と世論の場に押し寄せる。

他の AI 企業にとっては、次の意味を持つ。

初期の charter、mission statement、donation agreement はより明確に書く必要がある。
非営利 entity と営利 entity の責任境界を曖昧にしてはいけない。
safety commitment は宣伝文句ではなく、監査可能な governance を伴うべきだ。
創業者、投資家、公共利益の衝突は、資金調達前に制度として扱うべきだ。

OpenAI の規模と影響力がこれらの問題を拡大しているが、問題は OpenAI だけのものではない。AI 企業がさらに資本を集め、医療、教育、防衛、業務、消費者向け product に入っていくほど、同種の governance conflict は繰り返される。

まとめ

Musk v. OpenAI の核心は、「誰が誰を裏切ったのか」だけではない。frontier AI organization が研究ラボから super-platform へ移るとき、なお mission に拘束されていることをどう証明するかである。

Musk 側は、OpenAI が当初の charitable mission から外れたことを示そうとしている。OpenAI 側は、商業化は mission を実現するために必要だったと示し、Musk の訴訟を支配権獲得に失敗した後の反撃として位置づける。最終判断は、証拠、寄付文書、組織 charter、当時の communication に左右される。

結果がどうであれ、この裁判は一つのことを明らかにした。AI 企業は「全人類のため」という slogan だけで信頼を維持できない。AGI に近づき、巨大な商業価値を持つほど、governance structure は透明で、検証可能で、法廷と世論の双方に耐えられるものでなければならない。

参考リンク：

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 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 は「毎回ゼロから質問に答える」ツールから、好みを覚え、文脈を理解し、いつ検索すべきかを判断し、ユーザーが記憶の出所を管理できる長期的なアシスタントへ進んでいる。

Codex App 入門ガイド：インストール、サンドボックス、並列タスク、Skills、MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App は、AI コーディング向けのタスクワークスペースと考えると分かりやすい。従来の IDE でも、単なるチャット画面でもなく、マルチタスク、プロジェクト管理、サンドボックス権限、Git、クラウド実行、プラグイン、Skills、MCP、自動化を 1 つのインターフェイスにまとめている。

すでに Codex CLI、Claude Code、Cursor、その他の coding agent を使っているなら、Codex App の最も注目すべき点は、「複数の agent を並列に動かす」ことをより明確なデスクトップワークフローにしている点だ。

Codex App が向いていること

Codex App の価値は、AI に質問へ答えさせることではなく、プロジェクトディレクトリ内で継続的にタスクを実行させることにある。

コードを編集し、コマンドを実行し、開発サーバーを起動する。
複数のプロジェクトと複数のタスクを管理する。
ローカルまたはクラウドで長いタスクを実行する。
プラグイン、Skills、MCP を呼び出して能力を拡張する。
Git、worktree、PR で変更を管理する。

OpenAI も Codex App を複数の coding agent を管理するためのインターフェイスとして位置付けている。複数のコードタスクを同時に進める人に向いており、特にフロントエンドページ、スクリプト、小規模アプリ、ドキュメント整理、自動化ワークフローと相性がよい。

インストール前の準備

Codex App を使う前に、次の 3 つの基本ツールを用意しておくとよい。

Git
Node.js
VS Code または普段使っている IDE

Codex App は macOS と Windows をサポートしている。インストール後は ChatGPT アカウントでログインする。初回起動時には、プログラミングや日常作業など主な利用シナリオを選択できる。Codex は選択内容に応じて一部のプラグインと Skills を事前に入れ、後から設定やプラグインマーケットで調整できる。

Windows と macOS の主な機能はおおむね同じだが、一部のコンピューター自動化機能はプラットフォームやプラグイン対応に依存する。実際には現在のバージョンに表示される内容を基準にする。

インターフェイス構造：プロジェクト、タスク、チャット

Codex App は典型的な 3 カラム構成になっている。

左側：プロジェクト、タスク、過去のチャット、プラグイン、自動化への入口。
中央：現在のチャット画面。
右側：ファイル、ブラウザー、ターミナル、実行結果などの多機能領域。

1 つのプロジェクトは通常、ローカルフォルダーに対応する。同じプロジェクト内で複数のチャットを開くことも、複数のプロジェクトを同時に開き、異なる agent に並列で作業させることもできる。

タスクリストには状態が表示される。

実行中：agent がまだ作業している。
承認待ち：権限、ネットワーク、依存関係インストール、高リスク操作の確認が必要。
完了：タスクが終了し、結果確認や追加質問ができる。

複数のターミナルを行き来するより直感的で、複数の AI タスクを同時に管理しやすい。

サンドボックスと権限管理

Codex App の権限体系はサンドボックスを中心にしている。デフォルトでは、現在のプロジェクトフォルダーが agent の主な作業範囲になる。

一般的な権限境界は次の通り。

プロジェクトディレクトリ内のファイルを読み書きできる。
デフォルトではプロジェクト外のファイルを自由に変更できない。
ネットワークや高リスクコマンドはデフォルトで制限される。
権限昇格が必要な場合はユーザーに承認を求める。

実用的なのは「自動レビュー」モードだ。低リスク操作は自動で許可し、高リスク操作はユーザー確認に回す。これにより頻繁なポップアップを減らしつつ、危険な操作が知らないうちに実行されることを防げる。

「完全アクセス」は慎重に使うべきだ。agent が何をする必要があるか明確で、プロジェクトが Git でバックアップされ、重要ファイルにも別のバックアップがある場合に向いている。日常的に常時有効にするのはおすすめしない。

コンテキスト、モデル、利用枠

Codex App は現在のチャットのコンテキスト使用状況を表示する。会話が長く、履歴が多いほど、モデルが処理するコンテキストも大きくなる。

実用的な習慣は次の通り。

1 つのタスクが終わったら新しいチャットを開く。
長い会話は手動圧縮できるが、圧縮を万能の記憶と考えない。
複雑なタスクでは、目的、境界、受け入れ条件を先に明確にする。
関係ない大量のログ、エラー、ファイルを一度に詰め込まない。

モデル選択では、タスクの複雑さに応じて推論強度を調整する。簡単な修正、文章整理、反復タスクは必ずしも最高性能モデルを必要としない。アーキテクチャ移行、難しいバグ、複数ファイルにまたがるリファクタリングには、より強いモデルが向いている。

高速モードがある場合は、通常より利用枠を多く消費する点に注意する。急ぎの時には有効だが、日常のデフォルトにする必要はない。

画像生成とマルチモーダル入力

Codex App は画像やファイルをコンテキストとして受け取ることができ、適切な場面では画像生成能力も呼び出せる。

これはフロントエンドやコンテンツ系プロジェクトで役立つ。たとえば Codex に次のことを依頼できる。

スクリーンショットをもとにページスタイルを修正する。
Web ページ内の不適切な画像を置き換える。
商品画像、カルーセル画像、ページ素材を生成する。
UI スクリーンショットから修正すべき位置を指摘する。

より効率的なのは、「もっときれいにして」とだけ言うのではなく、スクリーンショットを使って具体的な問題を示すことだ。たとえば「このカードの余白が大きすぎる」「この画像はサービスシーンに合っていない」「地図エリアをもっと分かりやすくする」といった指示がよい。

Steer：実行中に方向を修正する

Steer は、実行中に方向を引き受ける機能と考えるとよい。agent がすでに作業を始めた後で、方向を誤解していると気づいた場合、すべて終わるまで待ってから直す必要はない。

この機能を使うと、新しい指示を現在の実行フローに挿入し、Codex に進路を修正させられる。

Steer が向いている場面は次の通り。

agent が要件を誤解した。
生成されたページのスタイルが明らかに違う。
実行中の案が重すぎる、またはコストが高すぎる。
途中で重要な制約を追加する必要がある。

通常はデフォルトのキュー動作を維持し、本当に介入が必要な時だけ手動で Steer を使うのがよい。通常のタスクを乱さず、重要な場面で方向を戻せる。

計画モードと内蔵ブラウザー

複雑なタスクでは、まず計画モードを使うのがよい。計画モードでは Codex はすぐにコードを変更せず、先に計画を出し、必要ならカード形式で重要な選択肢を確認する。

計画モードに向いているタスクは次の通り。

React プロジェクトを Next.js に移すようなフレームワーク移行。
大規模リファクタリング。
データベース、認証、デプロイを含む機能。
技術方針がまだ固まっていない要件。

Codex App の右側領域では内蔵ブラウザーを開き、ローカル開発サーバーをプレビューできる。ページ上で注釈を付け、具体的な UI 位置に応じて Codex に修正させられる。この「ページを見る、位置を指す、AI に直させる」流れは、純粋な文章説明よりフロントエンドデバッグに向いている。

Git、IDE、コードのロールバック

Codex App は完全な IDE ではない。コード閲覧や注釈はできるが、手作業での編集は VS Code、Cursor、Windsurf などの IDE の方が向いている。

Codex プロジェクトでは早めに Git を初期化しておくとよい。

Codex に .gitignore を作成または確認させる。
使える状態になったら一度コミットする。
大きな変更の前にはクリーンなコミット地点を作る。
不満があれば Git でコードを戻す。

チャット履歴だけを戻しても、コードは自動では戻らない。安定した方法は、チャットを適切な地点へ戻し、コードは Git commit hash で対応する状態へ戻すことだ。

Worktree：複数方向の並列開発

git worktree は Codex App で並列 agent を使う際に非常に相性がよい。

本質的には、同じリポジトリから複数の独立した作業ディレクトリを作り、それぞれを別ブランチに対応させる仕組みだ。これにより、異なる agent を別フォルダーで同時に作業させても互いに上書きしない。

典型的な使い方は次の通り。

1 つの worktree で顧客レビューコンポーネントを改善する。
1 つの worktree で店舗情報と地図レイアウトを調整する。
2 つのタスクが終わったらそれぞれ main へマージする。
マージ後に一時 worktree を削除する。

同じディレクトリで複数 agent に同時編集させるよりずっと安定する。競合が出た場合も、通常の Git フローで review と merge を行えばよい。

クラウド実行環境

Codex はローカルだけでなく、クラウド環境にもタスクを委任できる。

クラウド実行が向いている場面は次の通り。

外出中で手元にスマートフォンしかない。
agent に長いタスクをバックグラウンドで実行させたい。
コードがすでに GitHub に同期されており、Codex にリモートリポジトリを変更させたい。
PR 形式で変更を確認してマージしたい。

典型的な流れは、ローカルコードを GitHub に push し、Codex がクラウド環境でリポジトリを取得してタスクを実行し、変更を生成し、PR または diff としてレビューに出すというものだ。

ローカルで開発を続ける場合は、リモートの最新変更を取り込むことを忘れない。

記憶システム：AGENTS.md を整える

新しいチャットはデフォルトでは完全な履歴記憶を持たない。プロジェクトが複雑になると、毎回背景を説明し直すのは非効率だ。

最も汎用的な方法は、プロジェクトルートに AGENTS.md を置くことだ。このファイルには次の内容を記録できる。

プロジェクトの目的と主要技術スタック。
よく使うコマンド。
ディレクトリ構成。
コードスタイルと命名規則。
禁止事項、たとえばファイルの一括削除を避けること。
テスト、ビルド、デプロイルール。

Codex にプロジェクトを読ませて AGENTS.md の初版を生成させ、人間が確認する方法もよい。複雑なプロジェクトでは、このファイルを維持する価値が高い。

グローバルルールは慎重に使う。全プロジェクトに共通する安全制約、たとえば「ディレクトリを再帰的に削除しない」「破壊的操作の前に確認する」などに向いている。特定プロジェクトの細部をグローバルルールに入れると、他のプロジェクトを汚染する。

プラグインと自動化

プラグインは、GitHub、Gmail、Google Drive、データベース、デプロイ基盤など外部サービスを Codex に接続する。

価値はコピー&ペーストを減らすことだ。たとえば Codex に次のことをさせられる。

GitHub リポジトリの star 推移を確認する。
メール内容を整理して自分に送る。
定期的なチェックを実行する。
結果を要約として書く。

自動化は繰り返しタスクに向いている。たとえば毎週金曜午後にリポジトリデータを確認し、メールレポートを送るような用途だ。簡単な自動化タスクには最高性能モデルは不要で、軽量モデルで十分なことが多い。

Skills：ワークフローを再利用可能な能力にする

Skills は Codex の「専門的な手順書」だ。一回限りのプロンプトではなく、ある種類のタスクの流れ、規則、スクリプト、注意点をまとめ、Codex が後で安定して再利用できるようにする。

主な入手元は次の 3 種類。

公式 Skills。
サードパーティ Skills。
自分で書いた Skills。

Skill 化に向いている作業は次の通り。

字幕を図解付きノートにする。
会社の形式で週報を書く。
画像や文書を一括処理する。
固定形式のコードレビュー。
特定フレームワークのプロジェクト初期化。

同じプロンプトを何度もコピーしているなら、Skill にする価値がある。

MCP：外部ツールとデータベースを接続する

MCP は、大規模モデル向けの標準化されたツールプロトコルと考えられる。MCP を通じて、Codex は外部サービスを呼び出し、より具体的なタスクを完了できる。

たとえば Supabase を接続すると、Codex に次のことをさせられる。

データベーステーブルを作成する。
データベーススキーマを読む。
バックエンドエンドポイントを変更する。
フロントエンドフォームをデータベースへ送信する。
データベース状態に基づいて問題をデバッグする。

これは強力だが、権限境界に注意が必要だ。データベース、本番環境、デプロイ基盤、メールアカウントは高リスク資源である。初回接続時はテストプロジェクトと低権限アカウントを使うのがよい。

デプロイプラグイン

デプロイ基盤のプラグインを使うと、Codex がビルドと公開を直接完了できる。たとえばフロントエンドプロジェクトを Netlify のような平台へデプロイできる。

この種のプラグインは、小規模サイト、プロトタイプ、社内ツール、デモプロジェクトに向いている。実際に使う時は次の点に注意する。

デプロイ前にローカルビルドを実行する。
環境変数をコードへ直接書かない。
公開後にページが正常に開くか確認する。
本番プロジェクトでは人間の review を残す。

AI は公開フローをつなぐ助けになるが、デプロイ権限は慎重に管理すべきだ。

コンピューター自動化

対応プラットフォームとプラグイン環境では、Codex がブラウザーやデスクトップアプリを操作し、RPA に近いタスクを実行できる。

例：

チャットアプリを開いてメッセージを準備する。
プロジェクトボードを閲覧し、タスク状態を要約する。
英語のブリーフを生成する。
確認後、指定相手へ送信する。
この流れをスケジュール自動化にする。

この機能は想像力を広げるが、最も強い安全境界も必要だ。メッセージ送信、メール送信、フォーム送信、支払い、データ削除に関わる操作では、人間の確認を残すべきだ。

使い方の提案

Codex App の正しい使い方は、すべてを一度に完全自動化させることではない。タスクを明確に分解し、制御された環境で効率よく実行させることだ。

おすすめの習慣：

すべてのプロジェクトで最初に Git を初期化する。
複雑なタスクでは計画モードを使う。
並列タスクでは worktree を優先する。
プロジェクトルールを AGENTS.md に書く。
高リスク操作では人間の確認を残す。
繰り返しワークフローを Skill や自動化にする。
プラグインと MCP はまずテスト環境で検証する。

参考資料

まとめ

Codex App の本質は「もう 1 つの AI チャット画面」ではない。AI コーディングを管理可能なワークスペースにすることだ。ローカルプロジェクト、クラウドタスク、Git、worktree、プラグイン、Skills、MCP、自動化をつなげられる。

うまく使う鍵は、「任せること」と「制御すること」のバランスを取ることだ。小さなタスクは大胆に Codex に渡し、複雑なタスクはまず計画させ、高リスク操作は必ず確認する。そうすれば Codex は、コードを書く助手から、長期的に協力できるエンジニアリングツールへ近づく。

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

誰が GPT-5.5 にゴブリンを入れたのか？

Sat, 02 May 2026 11:02:16 +0800

OpenAI は最近、小さいけれど示唆の多い問題を振り返りました。なぜ GPT-5.5 は Codex で goblin や gremlin のような表現を頻繁に使うようになったのか、という話です。

これは単なる口癖の問題ではありません。モデル訓練でよく起きる現象を示しています。モデルは特定の単語を直接覚えたのではなく、強化学習の過程で「報酬されやすい」表現スタイルを学んだ可能性があります。

何が起きたのか

GPT-5.5 の訓練後期、Codex ユーザーは、モデルがコード問題、テスト失敗、異常な挙動を説明するとき、擬人化された表現を好むことに気づき始めました。

OpenAI 内部でも同様の現象が観察されました。GPT-5.5 は以前のバージョンと比べて、goblin や gremlin などの語をより頻繁に使っていました。研究チームはこれを一種の奇妙な人格特性として扱い、その出どころを追跡しました。

単なるデータの復唱ではない

最初に考えられるのは、訓練データにこうした表現が多く含まれていて、モデルが高頻度語を学んだだけという説明です。

しかし OpenAI の調査では、それだけでは説明できませんでした。事前学習データ内に関連語は存在したものの、訓練後期の行動変化を説明できるほど多くはありませんでした。より重要なのは、強化学習の前後で挙動が大きく変わっていたことです。後期訓練がこのスタイルを増幅していました。

つまり問題は「データに何があるか」だけではなく、訓練過程が何を報酬したかにあります。

強化学習が文体の偏りを増幅した

OpenAI の分析では、重要な変化は強化学習段階で起きていました。GPT-5.5 は、より生き生きして、識別しやすく、人格があるように見える書き方を学びました。そして、軽い冗談めいた語がそのスタイルにうまく合っていました。

簡単に言うと、モデルは次のような傾向を学んだ可能性があります。

個性のある回答は好まれやすい。
技術的な問題を軽い比喩で説明すると評価が良くなりやすい。
特定の語は、かわいさ、機転、遊び心を加える。
こうした局所的な報酬が訓練で増幅される。

その結果、モデルは頻繁に使えと明示されたわけではないのに、特定の場面で安定してその語を使うようになりました。

原因は Nerdy ペルソナだった

データをたどると、OpenAI はすぐに具体的な分岐を見つけました。パーソナライズ設定の Nerdy ペルソナです。

このモードの目的は、AI を「オタク気質のチューター」にすることでした。熱心で、機知があり、知識と批判的思考を重んじ、なおかつ堅苦しすぎない。人間から見ると、求めていることは明確です。ギークらしさとユーモアです。

しかしモデルは、ユーモアの境界を本当に理解しているわけではありません。強化学習のフィードバックの中で、goblin のような比喩を使うと、軽妙で、賢く、Nerdy らしく見え、高得点を取りやすいという近道を学びました。

数字にも表れています。GPT-5.2 から GPT-5.4 にかけて、デフォルト人格での goblin 出現頻度の変化は -3.2% にすぎませんでした。一方、Nerdy 人格では 3881.4% も増えました。さらに、Nerdy モードは ChatGPT の全会話の 2.5% しか占めないのに、goblin 使用量の 66.7% を生み出していました。

つまり問題は単語そのものではありません。報酬信号が「ユーモラスに見える」表現を固定された文体へ押し上げたのです。

Codex で目立った理由

Codex ではこの問題がより目立ちました。コード作業では、bug、テスト失敗、環境差、境界挙動が頻繁に出てきます。モデルはそれらを擬人化しやすくなります。

モデルが「このエラーは変だ」「このテストは不安定だ」「この挙動はいたずらっぽい」と軽く説明しようとすると、この種の語を選びやすくなります。積み重なると、ユーザーには固定口癖のように見えます。

OpenAI はその後、Codex のシステムプロンプトに抑制指示を追加し、この種の表現を避けるよう明示しました。これはモデルを再訓練するものではなく、製品側で挙動を抑える対応です。

この件が示すこと

この事例の要点は、特定の単語ではなく、モデルの挙動がどう形成されるかです。

少なくとも次の三点を示しています。

モデルの文体は、語料頻度だけでなく報酬信号から生まれうる。
訓練後期の小さな偏りが、安定した人格特性のように増幅されうる。
製品内のシステムプロンプトは問題を緩和できるが、モデル内部の傾向を消すわけではない。

これは大規模モデルのアラインメントで厄介な問題です。ユーザーは面白い回答を好みますが、面白さを強く最適化しすぎると、厳密な作業で軽く見えたり、反復的になったり、強すぎる癖が出たりします。

ユーザー側でできること

AI コーディングツールに固定された言い回しがある場合、必ずしもプロンプトの書き方が悪いとは限りません。モデル自身の訓練上の偏りから来ていることがあります。

緩和するには、次の方法があります。

システムプロンプトやプロジェクトルールで口調を明示する。
擬人化、スラング、過度な冗談を避けるよう指定する。
技術タスクでは「直接的、簡潔、エンジニアリング寄り」の回答スタイルを指定する。
特定の語が繰り返し出る場合は、明示的に禁止表現に入れる。

こうした制約はモデル内部の重みを変えるものではありませんが、実際の使用時のノイズは減らせます。

まとめ

GPT-5.5 の goblin 口癖は、単なる笑い話ではありません。報酬信号が文体を形作り、その文体が製品場面へ移り、最終的にユーザーが人格特性として感じるようになる、という大規模モデル訓練の深い問題を示しています。

モデル開発者にとって、この種の問題は訓練、評価、製品プロンプトの三層で扱う必要があります。一般ユーザーにとって実用的なのは、期待する文体を明確に書くことです。少し表演を減らし、安定性を増やすためです。

参考：

https://openai.com/index/where-the-goblins-came-from/

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

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」をさらに進める一歩に見えます。

GPT Image 2 正式公開、画像生成は「作れる」から「商用で使える」へ

Wed, 22 Apr 2026 20:08:22 +0800

OpenAI の次世代画像生成モデル GPT Image 2 が、すでに ChatGPT ユーザー向けに正式公開されています。リーク段階でのコミュニティの反応と、現在公開されている実例をあわせて見ると、今回の変化は単なる通常アップデートというより、AI 画像生成が「見られるもの」から「実際に使えるもの」へ進んだ大きな一歩に見えます。

前世代の画像モデルが、主にアイデア出し、コンセプトアート、試作的な生成に向いていたとすれば、GPT Image 2 のいちばん目立つ点は、制作現場で使えるツールに近づいてきたことです。読みやすい文字、UI スクリーンショット、販促ポスター、よりリアルな商業写真風の画像など、どの用途でも以前より「そのまま使える」感覚が強くなっています。

1. コアアップグレードとして注目したい 5 つの点

1. 文字レンダリングがついに実用域に入った

AI 画像生成でずっと難所だったのが文字です。文字化け、スペルミス、長文の崩れ、フォントの歪みは、ほとんどすべてのモデルで見られてきた問題でした。

GPT Image 2 はこの点でかなりはっきりした改善を見せています。英語や中国語の文字をより明瞭に扱えるだけでなく、複雑なレイアウト、長めの段落、ある程度の多言語混在にも対応しやすくなっています。つまり、これまで後工程で文字を直していた場面の多くが、生成段階でそのまま完了できる可能性が高くなったわけです。

代表的な用途としては次のようなものがあります。

ポスター
SNS カバー画像
タイトルや説明文付きのプロモーションページ
PPT 用ビジュアル
実際の文言や UI 要素を含む App スクリーンショット

実務フローにおいて、これはかなり重要です。文字が安定して読めるようになると、画像生成は単なる「背景画像づくり」ではなく、販促素材やプロダクト紹介画像まで担えるようになるからです。

2. 写真級のリアリティが明確に向上した

コミュニティの比較を見ると、GPT Image 2 は全体的によりシャープで、質感の描写も細かく、光の整合性も高くなっています。これまで AI っぽさが出やすかった顔、手、輪郭の細部も、今世代ではかなり安定しています。

もちろん、完全に破綻がなくなったわけではありません。ただ、いわゆる「AI っぽさ」はかなり薄くなっています。初見では本物の写真や商業撮影の作例、あるいはゲームのスクリーンショットだと見間違える画像も増えています。

そのため、多くの人の第一印象が「うまく描けている」から「かなり本物っぽい」に変わってきています。

3. 世界知識の統合がより強くなった

これは派手ではないものの、とても実用的な強化です。

GPT Image 2 は、単にパーツや画風を組み合わせるだけでなく、「自分が何を描いているかをわかっている」ような印象があります。元記事で挙げられていた例もわかりやすいです。

腕時計の文字盤の時刻表現がより自然
ブランドの細部やキャラクターの特徴の再現がより正確
Minecraft のようなゲーム画面やソフトウェア UI の構造がより本物らしい

つまり、現実の物体、デジタル UI、ゲーム画面のように、常識や構造理解が必要な内容を扱うときの成功率が上がっています。ユーザーにとっては、単なる高解像度化よりこうした改善のほうが価値を感じやすいはずです。

4. UI とスクリーンショット生成がかなり強い

リーク段階から正式公開まで、GPT Image 2 で特に話題になっていた方向のひとつが、ソフトウェア画面、Web スクリーンショット、App mockup の生成でした。

こうしたタスクが難しかったのは、次の条件を同時に満たす必要があったからです。

文字がはっきり読めること
レイアウトが整っていること
ボタン、カード、ナビゲーションバーなどの要素がきちんと揃うこと
配色や情報階層が実在する製品らしく見えること

今回のモデルは、そのあたりの完成度がかなり高くなっています。プロダクトマネージャー、個人開発者、デザイナーにとっては、提案、デモ、ユーザーテスト用の高忠実度モックアップをより速く作れることを意味します。

5. 局所編集が実用フローに近づいた

元記事をもとにすると、GPT Image 2 はより精密な局所編集に対応しており、毎回画像全体を作り直すのではなく、必要な部分だけを修正できます。

この能力はクリエイティブワークでは非常に重要です。実際のデザイン作業では、「1 枚まるごと作り直す」よりも次のような修正のほうが多いからです。

ボタンを 1 つ変える
一文だけ差し替える
あるオブジェクトの位置を調整する
背景の一部を直す
局所的な要素だけ入れ替える

局所編集が十分安定すれば、AI 画像生成の価値は初回出力だけにとどまりません。反復的な改善サイクルに本格的に組み込めるようになります。

2. GPT Image 2 の使い方

ChatGPT で使う

現在 GPT Image 2 は ChatGPT に統合されており、一般ユーザーも画像生成機能から直接利用できます。

よくある流れは次の通りです。

ChatGPT の Web 版または App を開く
入力欄の + をクリックする
「画像を作成」を選ぶ
プロンプトを入力して送信する
システムが GPT Image 2 を呼び出して結果を返す

元記事では、契約プランによって利用枠が異なり、無料ユーザーと Plus / Pro ユーザーでは生成回数に差があるとも触れられています。具体的な上限は後から変わる可能性があるため、その時点で ChatGPT 上に表示される内容を確認するのがよいでしょう。

API で使う

開発者向けには、OpenAI API 経由で画像生成モデルを呼び出すこともできます。元記事ではモデル名を gpt-image-2 としていますが、実装時には最新の正式名称やパラメータを公式ドキュメントで確認するのが安全です。

記事内で紹介されていた代表的な解像度は次の通りです。

解像度	想定ユースケース
`1024×1024`	汎用の正方形画像、アイコン、SNS 画像
`1536×1024`	横長カバー、スライド、ワイド壁紙
`1024×1536`	縦長ポスター、スマホ壁紙、ストーリー向け画像
`2048×2048`	高精細印刷、大判表示、細密なイラスト

3. 代表的なユースケース

元記事には多くの例がありますが、ここでは特に代表的なものを整理します。

1. App 画面のスクリーンショット

この種のプロンプトは、プロダクトのプロトタイプ、デザインデモ、要件議論に向いています。

典型的には次のような条件を入れます。

iOS などのプラットフォームスタイルを指定する
画面構成を明確に書く
主要なデータカードを列挙する
下部ナビゲーションを指定する
配色やタイポグラフィの方向を説明する
文字の視認性と要素の整列を強調する

この書き方のポイントは、単に見栄えを良くすることではありません。モデルの自由度を減らして、より本物の画面に近い結果を出させることです。

2. EC 商品画像

香水、イヤホン、腕時計、化粧品のような商品画像は、GPT Image 2 が力を発揮しやすい領域です。

理由は、次のような表現が安定してきたからです。

ガラス、金属、液体などの素材感
やわらかい影と反射
商業写真でよくあるライティングの論理
シンプルな背景での高級感ある見せ方
少量のブランド文字

出力が安定すれば、EC 詳細画像、LP のメインビジュアル、SNS 用の商品ビジュアルの試行錯誤コストをかなり下げられます。

3. 文字入りポスター

ポスターは、今回の文字能力をもっともわかりやすく体感できる用途のひとつです。

元記事の例では、夕暮れの都市シルエットを背景に、メインタイトル、日時場所、出演者名を明示し、さらに次の条件を求めています。

文字がはっきり読めること
スペルミスがないこと
中英混在でも安定すること
全体のスタイルが統一されていること

この手の作業は以前なら背景を生成したあとで人手で文字を入れるのが普通でした。もし一度の生成で大部分を終えられるなら、実用価値はかなり大きくなります。

4. ゲームコンセプトアートと「偽スクリーンショット」

これは GPT Image 2 で作られたコンテンツの中でも、SNS で特に拡散されやすいジャンルです。

たとえば三人称視点のゲーム画面、ネオン街、雨上がりの路面反射、被写界深度、粒状感、PS5 実機風といった要素を組み合わせると、ぱっと見でリーク画像だと誤認されやすいビジュアルができます。

拡散という意味では非常に強い一方で、リスク面では、本物らしい偽画像を作るハードルがかなり下がってきたことも示しています。画像の真偽を判断する際には、これまで以上に慎重さが必要です。

5. 写実的な人物像とクリエイティブポートレート

人物画像は、AI の画像能力をもっとも直感的に試せる分野のひとつです。

元記事の例は、自然光、カフェ、逆光の縁取り、ニット、暖色の背景ボケといった組み合わせを中心にしています。その狙いは次の点にあります。

肌の質感が自然であること
髪の細部がきちんと出ること
手の構造が崩れないこと
光の回り方に無理がないこと
全体に露骨な AI 感が出ないこと

これらを安定して満たせてこそ、人物生成が本当に実用段階に入ったと言えます。

6. フードフォト

元記事には、高級レストラン風の豚骨ラーメン写真を生成するための非常に長い英語プロンプトも紹介されています。これは、モデルが十分強くなると、プロンプトが撮影台本のような粒度になっていくことを示しています。

具体的には次のような要素まで細かく指定できます。

料理の構成
食器の材質
スープ表面の艶
チャーシューの脂身と焼き目
半熟卵の状態
背景の被写界深度とボケ
光の方向
レンズの種類と絞り

飲食ブランド、メニュー制作、デリバリーサービスのメイン画像、SNS コンテンツにとって、このレベルの生成はすでに商業フードフォトの代替案にかなり近いところまで来ています。

7. 教育用イラスト

もうひとつ代表的なのが、ラベル付きの科学教育図です。

元記事の例は植物細胞の断面図で、モデルに次の点を同時に求めています。

構造が正しいこと
ラベル位置が正確であること
誘導線が見やすいこと
フォントが統一されていること
配色に階層感があること
教材やスライドに使いやすい全体設計であること

これは GPT Image 2 の価値が、単に「きれいな絵を作る」ことだけでなく、「情報を伝える図を作る」ことにも広がっていると示しています。

4. 一般ユーザーにとって最も現実的な意味

GPT Image 2 が本当に注目に値するのは、単に画質をさらに押し上げたからではありません。AI 画像生成を、娯楽や試作のための道具から、商用利用や納品に近い制作ツールへと一段進めたことにあります。

具体的には次のような変化があります。

文字がようやく信頼しやすくなった
UI やポスターが実在の制作物に近づいた
商業写真風の画像がより使いやすくなった
教育用途や情報図版も作りやすくなった
局所編集によって反復改善に向くようになった

もちろん、これでデザイナー、フォトグラファー、イラストレーターが完全に不要になるわけではありません。実際の商用案件には、審美判断、ブランド管理、著作権への配慮、人による確認が引き続き必要です。

それでも今回の更新から見えてくるのは、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 の利用枠の考え方：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 利用枠の挙動を説明できます。

VS CodeでCodexを使う方法（インストールから効率的な実践まで）

Fri, 20 Mar 2026 00:00:00 +0000

Codex は、コードの作成、バグの修正、プロジェクトの説明、VS Code サイドバーでのコマンドの直接実行に役立ちます。

1. 準備

始める前に、次のことを確認してください。

VS Code は新しい安定バージョンに更新されました。
OpenAi Web サイトには通常どおりアクセスできます
プロジェクトコードはローカルで開かれています (Git リポジトリが推奨されます)。

2. 拡張機能をインストールする

VS Code 拡張機能マーケット (Extensions) をオープンします。
Codex - Codex - OpenAI's coding agent を検索してインストールします。
インストールが完了したら、プロンプトに従ってログイン認証を完了します。

3.コーデックスのサイドバーを開きます

任意の方法で開くことができます。

エディターの右上隅にある Open Codex Sidebar をクリックします。
コマンドパネル (Ctrl + Shift + P) を使用して、Codex を検索して開きます。

Codex を開いた後、現在のワークスペースコンテキストを読み取り、会話状態に入ります。

4. 一般的な使用方法

4.1 コードを解釈させる

プロンプトの単語の例:

`1`	`请解释这个文件的核心逻辑，并指出最可能出错的 3 个地方。`

古いプロジェクトを引き継ぐ場合に、グローバルな理解を迅速に確立するのに適しています。

4.2 機能させる

プロンプトの単語の例:

1
2

在现有 API 里新增一个 /healthz 健康检查接口，
要求返回版本号和数据库连接状态，并补上基础测试。

生成される結果がより安定するように、「入力制約」と「受け入れ基準」を一緒に明確に記述することをお勧めします。

4.3 問題を解決してもらう

プロンプトの単語の例:

1
2

这个接口在并发下偶发 500，请先定位根因，再给出最小改动修复方案，
最后列出回归测试点。

最初に「位置を特定」してから「修復」することで、誤った修正や過度の再構築を減らすことができます。

5. 高品質のプロンプト Word テンプレート

次の構造を直接再利用できます。

背景：这是一个 <技术栈> 项目，当前目标是 <目标>
约束：不改动 <模块/接口>，兼容 <版本/平台>
输出：
1) 修改文件列表
2) 关键代码说明
3) 验证步骤
4) 风险与回滚方案

このテンプレートは、「複数人でのコラボレーション + 大規模プロジェクト」に非常に役立ちます。

6. よくある質問

6.1 無料割り当てについて

ダイアログボックスに「\」と入力し、ステータスを選択します。クォータ、リセット時間などの関連情報が表示されます。

6.2 変更が期待どおりにならない

変更が完了したら、「レビュー」ボタンをチェックして変更の詳細を表示します。満足できない場合は、「元に戻す」ボタンを選択して変更を元に戻します。次のステップでは、要件を複数のステップに分割して個別に実行できます。 git などのコード管理ツールを使用して、小さなステップでコミットを維持し、ロールバックを容易にします。

OpenAI on KnightLiブログ

Cerebras IPO 急騰の背景：ウェハースケール AI チップは Nvidia に挑戦できるのか

Cerebras が作っているのは普通の GPU ではない

なぜ市場は熱狂したのか

OpenAI との協業が期待値を押し上げる

顧客集中は依然として大きなリスク

技術路線の弱点：メモリ容量

Nvidia を置き換えられるのか

まとめ

参考資料

Codex が ChatGPT モバイルからのリモートアクセスに対応、Enterprise ワークスペースで Access Tokens が利用可能に

今回の更新内容

モバイルリモートアクセスが解決する問題

開発者にとっての価値

Access Tokens が解決する問題

普通の API key ではない

安全な初期設定：Remote Control はデフォルトでオフ

利用前に必要な更新

企業での Codex 利用への影響

注意すべき境界

まとめ

Codex の利用上限はなぜ突然リセットされるのか？Usage Limits の履歴と情報源

まず結論

このスクリーンショットが示していること

なぜ Codex のリセットは予告なしに見えるのか

これまでの主なリセットの型

1. 2026 年 2 月：リリース期と一時的な増量

2. 2026 年 3 月：ランダムなリセットと異常消費の議論

3. 2026 年 4 月：成長マイルストーンと有料プランのリセット

4. 2026 年 5 月：障害補償型のリセット

リセットの理由をどう判断するか

情報源の信頼性を分けて見る

まとめ

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

できること

必要条件

制限

接続方法

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

よくある問題

向いている場面

まとめ

参考資料

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

最新の提供範囲

保存されるファイル

新しい会話で使う方法

検索と管理

プラン別容量

単一ファイルの制限

削除とダウンロード

Temporary Chatでは保存されない

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

向いている使い方

まとめ

参考資料

GPT-5.5 Prompt 移行ガイド：古いプロンプトはまず削ってから直す

古い prompt をなぜ書き直す必要があるのか

outcome-first：まず完了条件を定義する

絶対ルールを減らし、判断ルールを書く

retrieval budget を設定する

reasoning effort を最初から上げない

text.verbosity は出力を制御するが、思考を制御するわけではない

preamble と phase：長いタスクを見えるようにする

モデルに自分の作業を検証させる

GPT-5.5 に向いた prompt 骨格

古い prompt を移行する実際の順序

古い prompt 移行チェックリスト

GPT-5.5 prompt 例：旧 vs 新

パラメータの組み合わせ

残すべきルール

誤って削ってはいけないもの

まとめ

参考資料

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

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

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

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

価格と提供状況

開発者にとっての意味