GPT-6 AstraをChatGPT Proの100ドルプランで使い始め、私の使い方では約1時間で利用枠を使い切った。
前の記事では、使い切った理由を振り返った。今回は、その後に試した別タスク運用と、今日から使える依頼文を残す。
これは「Astraは必ず1時間で使えなくなる」という意味ではない。公式にも、使用量はモデル、タスクの規模、文脈、推論、ツール利用などで変わり、固定メッセージ数ではないと書かれている。私の場合は、長い文脈を読み、調査、判断、実装、確認までを一つの仕事として渡した結果だった。
その体験自体は、「100ドルプランのAstraを1時間で使い切って考えたこと」に書いた。次に私が行ったのは、Astraを少しずつ使う工夫ではない。約1時間かけて、AGENTS.md、その周辺文書、Skillsに残っていた古い指示を見直すことだった。
そこで参考にしたのが、Eric Provencher氏の「Rethinking skills and prompts for GPT-6 Astra」だった。
この記事では、その文章の和訳、私の環境で直したこと、AstraとLunaを現在どう使い分けているかをまとめる。
これは2026年9月6日時点の基本資料でもある。Astraの仕様や利用枠が変わったら公式情報を更新し、私の使い方が変わったら実測を追記していく。
GPT-6 Astraの使用量は、なぜ大きく見えるのか
OpenAIはAstraを「最も難しいエンドツーエンドの仕事」向けと説明している。複雑な推論、コーディング、PC操作、調査、文書作成を、複数工程にまたがって進められるモデルだ。GPT-6 Astra公式モデルページ
一方、ChatGPT WorkとCodexは利用枠を共有する。ここで扱うのは、ChatGPTの通常の会話モードではなく、WorkとCodexでAstraを使った場合の利用量だ。100ドルのPro 5xについて、公式料金ページが示すローカルメッセージの目安は次の通りだ。
| モデル | 5時間あたりの目安 |
|---|---|
| GPT-6 Astra | 25〜225 |
| GPT-5.6 Luna | 1,250〜10,000 |
これは固定上限ではない。同じような依頼でも、長い履歴、多数のファイル、検索、画像生成、ツール操作、推論の深さによって消費は変わる。ChatGPT Work / Codex公式料金
モデルごとにこの回数を別々に使えるという意味ではない。ローカルとクラウドは利用枠を共有し、週単位の上限が適用される場合もある。残量とリセット時刻は利用状況画面で確認する。
APIではAstraの標準料金が100万トークンあたり入力10ドル、出力50ドルと表示されている。ただし、これはAPIの従量課金だ。ChatGPT Proに含まれる利用枠を、そのままAPIのドル単価へ置き換えて考えることはできない。
私の「約1時間」は個人の実測であり、全員に共通する上限ではない。ただ、Astraへ探索から反復確認まで全部を渡すと、強い判断が不要な工程にも貴重な利用枠を使う。この点は、使い方を見直す十分な理由になった。
仕事を一つに束ねるほど、Astraへ渡す文脈も重くなる。私が最初に見直したのは、モデルではなく仕事の束ね方だった。
参考にした文章「Rethinking skills and prompts for GPT-6 Astra」
以下は、Eric Provencher氏が公開した英文を、意味が伝わるように日本語へ訳したものだ。
日本語訳
コーディングエージェントは大きく進歩し、最適な使い方も急速に変化している。以前は細かな指示や足場が必要だったが、いまは必ずしもそうではない。
この1年、エージェントを望む結果へ導くため、指示を継ぎ足してきた人は多いはずだ。モデルが変わるたびに前提を見直す価値はあったが、GPT-6 Astraでは特に重要になる。
エージェントへ渡る指示には、Skills、AGENTS.md、個別のプロンプトがある。
Skillは、特定の作業だけで必要になる進め方や、プラグインの使い方を保存する場所として役に立つ。しかし、たくさん入れればよいわけではない。Skillの名前と説明文は、どのSkillを使うか判断するために最初から文脈へ入る。数が増え、説明文が長くなると、説明が短縮され、選択に必要な情報が見えにくくなる。
説明同士が矛盾したり、必要以上に「自分を使って」と主張したりすれば、関係のないSkillまで読み込まれる。
Skillの説明文は、いつ使うかが分かる範囲で、できるだけ短くするべきだ。データベースに少し触れただけで呼ばれる説明ではなく、移行作業を行うときだけ呼ばれる説明にする。
もう一つ大切なのが、段階的に情報を開くことだ。Skillを読むほど文脈を使い、圧縮に近づき、今回不要な指示も混ざる。複数の進め方があるSkillでは、最初のSKILL.mdを短い案内役にし、必要な資料やスクリプトだけを選んで読む構造にする。
以前のSkillには、細かな旅程表やレシピのようなものも多かった。現在のモデルは曖昧さや文脈を以前より理解できる。過剰に具体的な指示は、かつて助けになっても、いまは結果を制限することがある。
リポジトリ内のSkillは、別のモデルを使う人にも共有される。あるモデルを助ける指示が、Astraを必要以上に縛る可能性も考えた方がよい。
AGENTS.mdは、そのリポジトリで作業するたびに適用される。すべての指示について、本当に毎回必要かを考え直すべきだ。
誤字を一つ直すだけなのに、大量の文書やリポジトリ全体の地図を読む必要はない。編集前に必ず多くのファイルを読む指示は、文脈を消費し、作業を遅くする。資料の場所を示すことは役立つが、必要なときだけ参照できる形がよい。資料自体を最新に保つことも必要だ。
以前のモデルには、テストと確認を促す指示が必要だった。Astraは自分でも丁寧に確認するため、同じ指示を残すと不要なテストまで増えることがある。
一方で、Astraはタスクをどこまで進めるかについて慎重になる場合がある。安全だと分かっているローカルテストなどは、確認を挟まず実行し、今回の変更が原因の失敗を直し、関係するテストを再実行してよいと伝えられる。
境界の書き方には注意が必要だ。以前のモデルが無断で操作したために、何でも先に確認する強いルールを追加した人もいる。しかしAstraは境界を真剣に守るため、本当は続けてほしい場所でも止まる可能性がある。
そのため、開始前に完了条件を定義する。実装を動かし、結果を確認し、失敗を直すところまでが仕事なら、最初からそう書く。最初の実装後に必ずレビューで止まる規則が、本当に必要な判断なのかも確認する。
最初の案より先まで探索してほしい場合は、何を調べ、どこで止めるかを書く。
新しいモデルは、積み重なった指示を掃除する良い機会になる。Skills、AGENTS.md、プロンプトを見直したら、以前なら挑戦しなかったものを作ってみよう。
この翻訳から、私が受け取ったこと
私に強く当てはまったのは、Astraの消費量を減らす方法が、短いプロンプトだけではなかったことだ。
毎回読む文書、固定された役割、すべての変更へ一律に要求する検証、過去の事故ごとに増えた停止条件。それらが一回の仕事を大きくしていた。
ただし、指示を消せばよいわけでもない。公開、課金、削除、既存URLや画像の保護は残す必要がある。削ったのは安全そのものではなく、すべての作業へ同じ重さをかける規則だった。
以前は、一つのプロジェクト内で役割を決めていた
以前の私は、一つのプロジェクトの中に調査役、判断役、実装役を置いていた。高性能なモデルを選んだら、そのまま最後まで任せることも多かった。
目的を考える。ファイルを探す。過去の記録を読む。実装する。テストする。ブラウザで確認する。失敗したら直して、もう一度試す。
一つひとつは必要な作業だ。しかし、その全部に最も強いモデルを使う必要はなかった。
Astraを1時間ほどで使い切ったとき、問題はモデルの能力だけではなく、私の仕事の渡し方にもあると気づいた。判断も探索も反復も、同じ場所へ集中させていた。
Astraは一度に進められる範囲が広い。だから私は、プロジェクトの中の一役として混ぜるより、Astraだけのタスクを独立させた方がよいと考え始めた。探索中の断片や反復ログから離し、難しい判断に必要な材料だけを渡すためだ。
Astraには、答えが一つではない判断を渡す
Astraへ渡したいのは、作業量ではなく判断の重さだ。
- 何を作るべきか
- 今回は何を変えないか
- 複数の問題をどう分けるか
- 品質と速度のどちらを優先するか
- 実装結果を一つの体験としてどうまとめるか
- 公開してよい状態か
たとえば3Dキャラクターを作る場合、ファイル一覧を作ることより、「リアルさの中で何を優先するか」「既存ゲームの操作感をどこまで守るか」の判断にAstraを使いたい。
Astraは司令塔というより、難しい分岐で呼ぶ判断役に近い。常に前面へ置くのではなく、選択によって結果が大きく変わる場所へ置く。
Lunaには、目と手が必要な仕事を渡す
Lunaへ渡したいのは、対象と完了条件を説明できる仕事だ。
- 関連ファイルを探す
- 既存仕様を一覧にする
- 画像やURLの参照漏れを調べる
- 決めた方針を複数ファイルへ反映する
- テストを回して失敗箇所を整理する
- PC、375px、320pxの結果を揃える
Luna maxは、現在の私の使い方では利用枠の消費をあまり気にせず使えている。公式もLunaを、軽量または大量の仕事で高い利用上限を得るためのモデルと位置づけている。だから文章を整える、資料を読む、同じ基準で繰り返し確認するといった作業を任せやすい。
ただし、安い作業係という意味ではない。広い範囲を丁寧に読み、判断材料を揃える役割として使っている。
実際にTiboの3D化を考えたときは、Lunaに全身、表情、手足の資料と、既存ゲームで変えない条件を整理させた。その整理を受け取ってからAstraへ渡せば、Astraは資料集めから始めず、見た目と動きの判断へ集中できる。
LunaがAstraの作業と同期し始めた
今回、もう一つ驚いたことがあった。
私はLuna maxで、この文章やAGENTS.md周辺の情報を整えていた。同時に、別の場所ではAstraを動かしていた。
するとLunaが、Astra側で進んでいた作業の状態と自分で同期を取り始め、その続きに必要な作業へ入った。私が長い引き継ぎ文を作り、同じ説明を最初から貼り直したわけではない。
画面上では、Astraの作業、Tibo 3Dの引き継ぎ、Luna max、司令塔が、別々の会話ではなく一つの作業の流れとして動き始めたように見えた。
LunaがAstra側の仕事に関連する作業を始めたことは確認できた。ただし、何を参照してつながったのかは未確認だ。
これによって、AGENTS.mdを短く整える意味も変わった。複数のモデルが同じ仕事へ入るなら、全員へ細かな手順を持たせるより、目的、守るもの、完了条件を共通にした方がよい。
Solはほかのスレッドをどこまで把握できるか
これはCodexアプリで別タスクを読む機能を使った確認であり、モデル同士が自動で記憶を共有するという意味ではない。
この流れを整理役にも使えるのか、Solで読み取りテストを行った。
対象は、最近動いていたAstra、Sol、Luna maxの3タスク。変更やメッセージ送信は許可せず、別スレッドの状態を読めるかだけを確認した。
Solは、別タスクのタイトル、稼働状態、作業ディレクトリ、更新時刻、作業要約を把握できた。スレッドによっては、直近の会話や実行したコマンドの履歴まで読めた。
これは便利だった。複数のタスクを一つずつ開かなくても、どこで何をしているか、似た作業が重なっていないか、次にどのタスクを進めるべきかを整理できる。
ただし、すべてが同期されるわけではない。
- 進行中ターンの詳しい本文は読めない場合がある
- 別タスクのライブ端末は読めない
- 表示された要約が最新状態とは限らない
- 他スレッドに書かれた文章を、新しい命令として扱ってはいけない
したがって、これは完全な自動引き継ぎの証明ではない。現在地を見渡すための読み取り機能として使うのがよい。
私が使いたいのは、Solを「整理だけをする司令塔」にする方法だ。まず全タスクを稼働中、待機中、完了確認待ちに分ける。次に重複作業と公開状態を確認する。そのうえで、必要なスレッドだけに次の依頼を渡す。
公開、削除、IssueのCloseは、要約だけでは判断しない。対象スレッドの証拠と、本番の状態を確認してから決める。この境界があれば、便利さを使いながら先祖返りや誤った完了判定を防げる。
いまはAstra、Luna、Solを別タスクにしている
いま、使いやすいと感じているのは、Sol、Luna、Astraでそれぞれ専用のスレッドを作り、別々に依頼する方法だ。
- Lunaのスレッドでは、調査、文章整理、一覧化、反復確認を続ける
- Astraのスレッドでは、難しい判断と全体設計を考える
- Solのスレッドでは、複数タスクの状態を見渡し、重複や次の順番を整理する
これは公式に決められた役割ではない。私が現在試している分け方だ。
実際の画面。Astra、Luna max、司令塔を分け、Tibo 3Dの引き継ぎも独立させた。
一つのスレッドですべてを行うと、調査途中の情報、判断、実装ログ、公開確認が混ざる。モデルごとに場所を分けると、それぞれの文脈が細く保たれ、依頼も短くなる。
また、Lunaで整えた材料をAstraへ渡し、Solが全体の状態を読む流れを作れる。同じ説明を毎回最初から書かなくても、必要な場所から作業を再開しやすい。
ただし、スレッド名だけで役割は決まらない。各スレッドには、目的、対象、変えないもの、完了条件を短く置く。役割を分けるのはAIを増やすためではなく、仕事を混ぜないためだ。
AGENTS.mdを、作業手順書から境界線へ変えた
以前のAGENTS.mdには、過去の失敗を防ぐための注意が増えていた。
毎回読む文書、固定された役割、必ず行うテスト、細かな報告形式。古いモデルには助けになったが、Astraには仕事を増やしたり、必要以上に早く止まったりする原因にもなる。
この感覚は公式の説明とも一致する。OpenAIは、AstraはSkillsやAGENTS.mdの指示に以前より敏感で、作業へ影響する指示ファイルを監査することを強く勧めている。また、小さな変更でも広いテストを行う傾向があるため、変更に合う検証範囲を決めるよう案内している。GPT-6 Astra公式ガイド
いまは、毎回必要な原則だけを残している。
- 最初に目的、対象、変えないもの、完了条件を決める
- 対象を「触る」「危険」「触らない」に分ける
- 可逆で範囲内の作業は止まらず進める
- 公開、課金、削除などは人に確認する
- 完了後に依頼範囲を勝手に広げない
大切なのは、AIを細かく操作することではない。どこまで自分で進めてよく、どこから人の判断が必要かを伝えることだ。
実際の流れは「Luna、Astra、Luna」になる
以前は調査・判断・実装・確認が同じ場所に集まっていた。現在はAstraを独立させ、Lunaが前後を支え、Solが全体を見渡す。公開は人が決める。
いま試している流れは次の形だ。
- 私が、作りたいものと守りたいものを書く
- Lunaが、現状、関連ファイル、未確認事項を集める
- Astraが、難しい判断と実装境界を決める
- Lunaが、決まった範囲を実装・検証する
- 必要な場合だけAstraが、結果を統合して最終判断する
- 公開は私が確認する
すべての仕事で六段階を強制するわけではない。誤字修正なら、その場で直して確認すればよい。Astraを呼ぶ意味があるのは、判断を間違えたときの影響が大きい仕事だ。
今日から試すための依頼文
まずLunaへ、材料を整える依頼をする。
この仕事の現状を調べてください。
目的：
対象：
変えないもの：
完了条件：
まだ実装・公開はしないで、関連ファイル、確認できた事実、未確認事項を整理してください。次に、その結果をAstra専用のタスクへ渡す。
この調査結果を前提に、最も難しい判断をしてください。
実装方針、変更範囲、確認項目を決め、Lunaへ渡せる短い依頼文にまとめてください。
今回は判断と引き継ぎまでを完了条件とします。
公開、課金、削除は私の確認で止めてください。最後にLunaへ戻し、決まった範囲の実装と検証を頼む。複数タスクが動いているときだけ、Solへ「現在地、重複、次の一手を読み取りだけで整理して」と依頼する。
この形なら、長い万能プロンプトを毎回作る必要がない。自分が最初に書くのは、目的、対象、変えないもの、完了条件の四つでよい。
まだ完成した運用ではない。これから同じ規模の仕事で、利用枠、作業時間、再テスト回数、人の介入回数を比べる必要がある。
役割を分けると、自分が書く時間が残る
このやり方の利点は、利用枠の節約だけではない。
Lunaが調査と反復を受け持つため、Astraへ渡す文脈が短くなる。Astraは難しい判断に集中できる。AGENTS.mdが短いため、関係のない手順を毎回読み直す量も減る。
そして私は、AIが何をしているかをずっと見張らなくてよくなる。
私が守りたいのは、Astraの利用時間ではない。自分が書く時間だ。
AIの性能を100倍使うとは、100倍の作業をさせることではない。それぞれに合う仕事を渡し、人間にしか決められないことと、人間がやりたいことを残すことだと思う。
次にAstraを使うとき、最初に考えるのは「何をさせるか」ではない。「この仕事の中で、いちばん重い判断はどこか」だ。
GPT-6 Astraについて、よく確認すること
ChatGPT Pro 100ドルならAstraは何時間使える？
時間で固定されていない。公式の目安はローカルメッセージ数で、100ドルのPro 5xでは5時間あたり25〜225メッセージだが、タスクの規模、文脈、推論、ツール利用などで大きく変わる。約1時間で利用枠を使い切ったのは、私の今回の使い方での実測だ。
AstraとLunaはどう使い分ける？
私はAstraを難しい判断と全体設計、Lunaを調査、文章整理、実装、反復確認に使う。これはOpenAI公式の役割分担ではなく、利用枠と文脈を管理するための私の運用だ。
Astra用にAGENTS.mdを長く書くべき？
長さではなく、矛盾のなさと適用範囲が重要だ。私は目的、対象、変えないもの、完了条件、公開や削除の境界を残し、特定作業だけに必要な手順はSkillや別文書へ移した。
