実際に引き継がれるもの
まずはOpenAIの公式モデルページに記載されているスペックから。 Astraは「1,050,000コンテキストウィンドウ」と「128,000最大出力トークン」を提供し、「2026年4月30日の知識カットオフ」を備えています。OpenAIはこれを「最も困難なエンドツーエンドの作業向けに構築された、最も有能なモデル」と説明しており、「複雑な推論、コーディング、コンピューターユース、研究、ドキュメント作成」に推奨しています。推論は調整可能で、reasoning.effortは「low、medium、high、xhigh、max」をサポートしています。
提供は段階的に行われるため、混在期間を想定してください。 モデルページによると、「GPT-6 Astraは本日、Trusted Accessプログラムの企業向けに展開が開始され、APIおよびPlus、Pro、Business、Enterpriseプランを通じたアクセスは数日中に提供される予定です」とのことです。また、APIのレート制限表では、Freeティアは「サポート対象外（Not supported）」となっています。
これは、人々が過小評価しがちな実用的な理由から重要です。しばらくの間、ある場所ではAstraを実行し、別の場所では別のモデルを実行することになります。一方のモデルの会話履歴内にあるコンテキストは、もう一方のモデルには存在しません。
指示ファイルは完全に引き継がれます。なぜなら、これらはモデル固有のものではなかったからです。 これは朗報であり、その理由を正確に理解しておく価値があります。Codexのドキュメントには「Codexは作業を行う前にAGENTS.mdファイルを読み込む」と記載されており、それが構築する検出チェーン（グローバルファイル、そしてルートから下へのプロジェクトファイル）は、どのモデルが回答するかとは一切関係ありません。Claude CodeのCLAUDE.md、Cursorの.cursor/rules、AmpやWarpのAGENTS.mdでも同様です。
したがって、規約がファイルに記述されている場合、モデルの切り替えにコストはかかりません。しかし、それらが会話の中にある場合、モデルを切り替えるとそれらすべてを失うことになります。
会話履歴は、どのインターフェースでも引き継がれません。 新しいモデルは新しい会話を意味します。APIではこれは明白です。メッセージ配列は自分で構築するため、自分で持ち運ばない限り何も引き継がれません。チャット画面では、インターフェースが継続しているように見える一方で、回答するモデルが変更されているため、この点が分かりにくくなります。
知識カットオフは、どんなウィンドウサイズでも補うことができない部分です。 2026年4月30日。それ以降の4ヶ月間に行われたあなた自身の決定がその後に存在します。これは、私たちが繰り返し立ち返る「なぜ長いコンテキストはメモリではないのか」という区別の最も明確な例です。容量（Capacity）とはモデルが一度に保持できる量であり、メモリ（Memory）とは開始時にそこに何かがあるかどうかです。
コンピューターユースは、「コンテキスト」が指すもの自体を変化させます。 Astraはコンピューターユースをサポートしており、モデルページにはApply patch、Skills、MCP、Tool searchがサポート対象としてリストされています。エージェントがあなたに代わってアプリケーションを操作する場合、関連するコンテキストはコードベースだけではありません。どのシステムへのアクセスが許可されているか、それらの社内での名称は何か、先月のワークアラウンドのうちどれがまだ必要なのか、といった情報です。これらはリポジトリから導き出すことはできず、4月までトレーニングされたモデルの中にも存在しません。
スナップショットは動作を固定するものであり、知識を固定するものではありません。 ドキュメントには「スナップショットを使用すると、モデルの特定のバージョンをロックして、パフォーマンスと動作の一貫性を維持できます」と記載されています。これは再現性には役立ちますが、固定されたバージョンにプロジェクトに関する追加情報が提供されるわけではありません。
手動での移行
ステップ 1：モデルが持っていない4ヶ月分の情報を書き出す
これは移行プロセス全体の中で最も価値のある1時間ですが、ほとんど誰もこの時間を費やしていません。
チームの最近の履歴（5月以降にマージされたプルリクエスト、決定記録、何度もリンクしているSlackスレッドなど）を開き、何が変更されたかを書き出します。すべてを書き出す必要はありません。エージェントが知らなければ間違えるであろう内容だけで十分です。
具体的には、以下の5つのカテゴリに分類される傾向があります。依存関係とフレームワークの移行：何に移行したか、そして極めて重要なこととして、何から移行したか（古いモデルは自信を持って古い方法を提案するため）。非推奨事項：コードベースにはまだ存在するが、拡張してはならないサービス、エンドポイント、社内ライブラリ。4月以降に決定された規約：命名規則の決定、エラーハンドリングのパターン、レビューのルール。所有権の変更：現在、どのチームがどの領域を所有しているか。理由付きの制約：「2つのモバイルクライアントが古いビルドを固定しているため、APIはパスでバージョン管理されている」といった情報は、10行のスタイルガイドよりも価値があります。理由がなければ、エージェントは親切心からそれを削除してしまうからです。
そして、それを永続的な場所に保存します。指示がすでにAGENTS.mdやCLAUDE.mdにある場合は、そこに追記します。ファイルはモデルに依存しないため、この作業は次のモデル切り替え時にも役立ちます。これについては、プロジェクトドキュメントをAIメモリに変換するで詳しく説明しています。
ステップ 2：混在期間中の対応を決め、1つの会話で検証する
段階的なロールアウトの間は、両方のモデルが混在することになります。この期間を乗り切るためには、2つの決定が不可欠です。
第一に、指示レイヤーはモデルごとではなく、1つの場所にまとめて管理することです。古い環境向けに古いファイルを残したまま、Astra用に調整された指示ファイルを作成したくなるかもしれません。しかし、それでは初日から2つのファイルが乖離してしまいます。これこそが、なぜエージェントは指示ファイルを無視するのかの背景にある仕組みです。エージェントがファイルを読めないのではなく、矛盾する複数のコピーのうちの1つを読んでしまっているのです。
第二に、推論エフォートをインターフェースのデフォルトのままにするのではなく、意図的に調整することです。reasoning.effortはlowからmaxまで設定できますが、モデルにコンテキストが不足しているタスクに対して高いエフォートを設定しても、より良い回答は得られません。より徹底的に推論された「間違った回答」が出力されるだけです。まずはコンテキストを提供してください。
そして、一度だけ検証を行います。新しいAstraの会話を開始し、4月以降の決定にのみ依存する正しい回答を求める質問（カットオフ前の知識では確実に間違った回答になる質問）を投げかけます。返ってきた回答を確認してください。もし古い回答が返ってきた場合、指示レイヤーがモデルに届いていません。プルリクエストの段階ではなく、わずか2分でそのことに気づくことができます。
その際、100万トークンが実際にどのようなコストをもたらすかも確認してください。非常に大きなウィンドウがあると、何でも貼り付けたくなりますが、リポジトリ全体を詰め込んだ会話は、重要な10個の事実を含む会話と同じではありません。読み込む情報と得られる結果の関係については、エージェントメモリに保持する情報を減らすで解説しています。
より良い方法：切り替えを「移行作業」にしない
上記の内容はすべて実際の作業であり、厄介なのは、あなたがGPT-5.6のときにも同じことを行い、12月にリリースされるであろう次のモデルでも再び同じことを行うことになる点です。すべてのモデル切り替えがコンテキストの移行作業になってしまうのは、コンテキストが間違った場所（会話の内部や、ツールごとに維持しているファイルの中）に保存されているからです。
代替案は、永続的な情報をその両方の外部に保持することです。モデルが変わっても、プロジェクトに関する事実は変わりません。エージェントが読み取るレイヤーにそれらが存在していれば、モデルの切り替えは本来あるべき姿、つまり単なる「モデルの切り替え」になります。同じ知識ベースに対して別のモデルを向けるだけで、そのモデルは最初から情報を把握した状態でスタートできます。
これにより、知識カットオフの問題も一回限りではなく、永続的に解決されます。2026年4月30日は、長いテキストの貼り付けで取り繕うべき崖ではなくなります。なぜなら、それ以降の4ヶ月間の情報が、モデルがアクセスできる場所に書き込まれているからです。MemoryLakeは3つのステップでセットアップできます。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これはモデル、スナップショット、またはプランのティアに紐付いていません。この特性は、新しいモデルへのアクセスが段階的に展開されている期間において非常に重要です。
ステップ 2：最初のメモリをアップロードする
上記のステップ1のリストから始めます。移行先と移行元、非推奨事項、4月以降に決定された規約、所有権、および理由が紐付いた制約などです。
さらに、コンピューターユースのエージェントが必要とし、推測できない情報（アクセスすべき社内システム、チーム内でのそれらの呼び名、ベンダーが問題を修正していないために依然として存在する手動ステップなど）を追加します。
ステップ 3：AIとエージェントを接続する
Astraをそのストアに向け、他の場所で実行しているものも同じストアに向けます。段階的なロールアウト期間中、これは「単一の真実のソース」を持つか、「乖離していく2つのソース」を持つかの違いになります。これについては、コンテキストを失わずにAIモデルを切り替えるで詳しく説明しています。
実務における変化
最初の変化は、カットオフ日が重要ではなくなることです。すべてのモデルにカットオフ日があり、それらはすべて過去のものです。次のリリースでそのラインが十分に先に進むことを期待するのではなく、自分たちの最近の履歴を書き出すことで、そのギャップを埋めることができます。
2つ目は、大きなウィンドウが「義務」ではなく「能力」になることです。100万トークンを保持できるからといって、自分たちが何者であるかを再認識させるためにそれらを消費する必要はありません。オリエンテーションではなく、タスクそのものをロードしてください。
3つ目は、次の切り替えコストが安くなることです。フロンティアモデルのリリースによってチームが移行を検討するのは、この1年で4回目か5回目です。毎回高いコストを支払い続けているのは、コンテキストが会話の中に存在しているチームです。
GPT-6 Astraへの移行に関するベストプラクティス
- 両方の数字を読み解く。 1,050,000トークンの容量と、2026年4月30日の知識カットオフ。あなたの仕事を変えるのは、2つ目の数字です。
- カットオフ以降の数ヶ月間の情報を書き出す。 移行、非推奨事項、規約、所有権、および理由付きの制約。
- 指示レイヤーは1つに保ち、モデルごとに作成しない。 指示ファイルはもともとモデル固有のものではありません。そのように扱わないでください。
- 混在期間を想定する。 ロールアウトはTrusted Access、API、有料プランを通じて段階的に行われ、APIのFreeティアはサポート対象外となっています。
reasoning.effortを意図的に設定する。 lowからmaxまでは実際の範囲であり、エフォートはコンテキストの代わりにはなりません。- 4月以降の質問で検証する。 カットオフ前の知識では間違った回答になるプロンプトを1つ投げるだけで、コンテキストがモデルに届いているかどうかが分かります。
- スナップショットは知識のためではなく、再現性のために固定する。 固定されたバージョンは一貫した動作をしますが、知識が増えるわけではありません。
- コンピューターユースに固有のコンテキストを提供する。 どのシステムか、社内で何と呼ばれているか、どのワークアラウンドがまだ適用されているか。
結論
Astraの興味深い点は、100万トークンを保持できることではありません。これほど有能なモデルであっても、すべての会話が、あなたのチームが5月に決定したことを知らない状態で始まるという点です。
上手に切り替えるということは、これら2つの問題を切り離すことを意味します。能力はモデルから得られるものであり、それは確かに向上しています。知識はあなたから得られるものであり、切り替えのたびにコストを支払うのを防ぐ唯一の方法は、会話が行われた場所ではなく、モデルが読み取れる場所に知識を保管しておくことです。