CodexのAstraにどう頼む？モデル選び・依頼文・完成確認の実践ガイド

Astraに任せる仕事と、この記事でできること

公式情報の確認日：2026年9月26日。対象はCodexを使った小さなWebページの修正です。

Codexに「直して」と頼んだものの、どこまで作業してもらうか迷っていませんか。この記事では、Astraを使う場面と、小さなWebページの修正を頼むための依頼例を紹介します。掲載する依頼例は、架空のプロジェクトを想定して本記事のために作成したものです。

この記事は、小さなWebページの修正をCodexに依頼したい読者向けに書かれています。技術的な用語を覚えることよりも、直したい動作や対象、完成後の確認を明確に伝えることが目的です。例えば、「お問い合わせ画面の送信ボタンが空欄でも動作してしまう問題を修正する」や「FAQページに検索機能を追加する」など、具体的なタスクを例に挙げながら、変更範囲や確認すべきケースを説明します。

例に出てくるファイル名・テスト名・画面名は、自分のプロジェクトに合わせて置き換えてください。変更してほしい動作と、維持したい見た目、公開や外部送信の扱いを伝え、最後に何を確認するかを決めましょう。

Astra・Sol・Lunaと、考える強さを選ぶ

モデルの強さを常に最大にしないといけない？

タスクの複雑度で調整。簡単な作業はLightでもOKです。

Astraは複数のステップやツールを組み合わせた難しい作業に適しています。日常的な業務や複雑なプログラミングにはSol、明確で繰り返し可能なタスクにはLunaがおすすめです。この章では、Astraを選択する際のポイントとCLIでの起動方法を説明します。利用権限やアカウント設定は別途確認が必要です。

Solの用途として公式資料が挙げるのは、複雑なコードの変更、深い調査、仕上がりが重要な文書などです。狭い仕事を任せる場合でも、何ができたら完了かを伝えると、対象を絞りやすくなります。Lunaは、必要な情報を取り出す抽出、種類ごとに分ける分類、形式を変える変換、決めた形での要約など、良い結果の形が分かっている繰り返しの仕事が選択の目安です。

モデルとあわせて、考える強さも選びます。推論の強さでは、HighとExtra Highが、複数の手順や資料を扱う難しい仕事、両立しにくい条件を比較する仕事の候補です。最初から最大に固定するのではなく、慣れた小さな課題の結果を見て調整します。

Astraの選択条件

Astraは、コードやアプリケーション、研究など幅広い分野で連続的な論理的推論と判断力が求められる作業に最適です。例えば、複数のソースから情報を集約して結果を整理するようなタスクでは、Astraが特に効果的です。実行前には、必要な資料やテンプレート、制約条件などを明確に定義しておくことが重要です。Astraは、ユーザーの指示を正確に反映しながら目的を維持する能力を持っています。

CLIでの起動方法

Astraを選択するCLIコマンドは次の通りです：

codex -m gpt-6-astra

CLI対話中は、`/model`コマンドでモデルや推論の強さを変更できます。公式資料はAstraをLightから試すことを勧めています。これは使い始めの選び方の目安です。利用できるモデルは、アカウント、サインイン方法、使う画面、段階的な提供、組織の設定によって異なります。モデル名を書くだけで利用権限が得られるわけではないため、選択肢が見当たらない場合は利用条件を確認してください。

推論の強さの選び方

推論の強さは、考える作業にどれだけ力を配分するかの設定です。公式の出発点は、AstraがLight、SolがMedium、LunaがHigh。AstraのLightは設定ファイルでは`low`に相当し、CLIではLowという表記が使われます。Light／Lowは範囲のはっきりした短い仕事、Mediumはもう少し計画を要する仕事が目安です。さらに計画・分析・確認が必要なら強さを上げる余地があります。

注意点

推論の強さはモデルの世代ごとに異なるため、同じ設定で結果が変わる可能性があります。慣れたタスクは低い設定で試し、結果を見て調整するのが良いでしょう。

以上のように、Astraの選択とCLIの操作方法を理解することで、効率的にタスクを進めることができます。

依頼文は目的・材料・範囲・完成確認から

難しい用語を覚える必要ある？

動作や目的を伝えるほうが重要です。

以下に掲載する例文は、お問い合わせ画面の編集作業を依頼する際の具体的な表現です。各行の意味を平易に解説します。

依頼文は、AIに知りたいこと・作ってほしいもの・変えたい動作を伝える文章です。特別な書式を覚える必要はありません。まず自分の言葉で目的を伝え、返ってきた結果を見て必要な条件を補えます。

作業が大きくなる場合は、判断材料になるファイルや資料、ほしい結果の形、変更しない部分を足しましょう。画面の問題なら画像のどこを見てほしいかも伝えます。新しい情報が必要なら検索と出典の提示を依頼します。手順そのものが重要な場合は順序を指定し、それ以外は調査や比較の進め方に余地を残します。

この例の空欄チェックだけで、あらゆる安全上の問題を解決できるわけではありません。送信処理やサーバー側での確認まで直す必要があれば、その対象も別に伝えます。

お問い合わせ画面の送信ボタンを押すと、何も入力していなくても送信されます。
名前とメールアドレスが空のときは送信せず、入力欄の近くに日本語で理由を表示してください。
対象は contact.html と contact.js です。見た目の色や配置は維持してください。
空欄、正常な入力、送信失敗の各場合を確認し、直す前と後の違いを説明してください。
本番への公開と外部サービスへの実送信はせず、ローカルの確認までで止めてください。

困っている動作を伝える

「送信ボタンを押すと何も入力していなくても送信される」という現状を指摘しています。これは、ユーザーが必要入力項目を省略したまま送信操作を行うと、システムが自動的に処理を進めるという動作を示唆しています。この点を改善する目的が依頼の中心です。

期待する動きを指定する

名前とメールアドレスが空なら送信せず、入力欄の近くに日本語で理由を表示する、という期待する動きを決めています。ここでは実装方法を先に決めず、どの条件で送信を止め、どこに説明を出すかを伝えます。

対象ファイルと変えない部分を決める

対象となるファイル名を指定しています。`contact.html`と`contact.js`は架空の例なので、自分の画面に関係する実際のファイルへ置き換えてください。名前だけで内部の役割を決めつけず、既存の色や配置を維持することも伝えます。

確認するケースと報告内容を指定する

テストケースの範囲を明確化しています。空欄時・正常入力時・送信失敗時の3パターンをカバーし、それぞれの状態でシステムがどのように反応するかを検証する必要があります。変更前の状態と変更後の挙動の差異を説明することで、改善効果を可視化しています。

公開・外部送信の範囲を決める

ローカル環境での確認に限定している点が重要です。「本番」は運用環境、「ローカル」は開発用の作業環境を指します。本番環境への配布や外部サービスとの連携は行わないことで、検証を進めることを示しています。

この例では、目的は空欄送信の防止、材料は対象ファイル、守る条件は見た目と外部送信の扱い、完成確認は空欄・正常入力・送信失敗の各場合です。依頼の結果として、直す前後の違いを説明してもらいます。すべての依頼に同じ形式を強制するものではなく、その作業に必要な項目を選んで使ってください。

初めてのプロジェクトを読むだけで案内してもらう

モデルは実際に判断および生成を担うAIであり、Codexはそれを用いてファイルや開発作業を進める道具として説明される。

初めてプロジェクトを開く際、変更せずに読み込む依頼例を示します。例えば、「このプロジェクトを初めて読みます。まだファイルを変更しないでください」と始めるのが基本です。次に、`README.md`や`package.json`などのファイルを入口として、起動方法と主要な画面の関係を調べるように求めます。 `README.md`は使い方を書く文書、`package.json`はJavaScriptのプロジェクト情報を記録するファイルです。どのプロジェクトにもあるとは限らないため、手元にある入口へ置き換えてください。

読者に説明が必要なファイルは、役割と理由を添えて提示しましょう。起動に追加の契約や秘密情報が必要な場合は、その種類だけを示し、具体的な値は記載しません。最後に、実際に確認した内容と、まだ確認が必要な点を分けてまとめます。

ソースコードを知らない読者でも、操作手順や画面の期待結果、変更しない範囲が伝わるように注意します。難しい用語を使うことは良い依頼の条件ではありません。たとえば、「推論の強さ」はモデルが考える作業にどの程度力を配分するかを示す設定で、コンテキストは判断の根拠となる情報です。差分は変更前後の違い、レビューは問題がないかの点検を意味します。

このように、依頼内容を明確にすることで、読者はプロジェクトの構造や目的を理解しやすくなります。不明点があれば、対応するファイルを追加して質問するのも有効です。

依頼文の例

このプロジェクトを初めて読みます。まだファイルを変更しないでください。
README.md と package.json を入口に、起動方法と主要な画面の関係を調べてください。
私が最初に読むとよいファイルを、役割と理由を添えて説明してください。
起動に追加の契約や秘密情報が必要なら、その種類だけを示し、値の提示を求めないでください。
最後に、実際に確認した内容と、まだ確認が必要な内容を分けてください。

FAQの検索欄を追加してもらう

FAQ本文を変えてもいい？

今回の例では、元の質問と回答は変えないよう指定しています。

FAQページに、ユーザーが入力した単語を含む質問だけを表示する検索機能を追加します。対象ファイルは`faq.html`と`faq.js`で、既存の質問や回答の本文は変更せず、空欄の場合はすべての項目を表示する必要があります。

検索対象は質問の文章です。入力した語がその中に含まれる質問を表示し、質問全体との完全一致には限定しません。一致しない場合は「該当する質問がありません」と表示します。新しい外部ライブラリは追加しない、という条件も伝えます。回答全文の検索や曖昧検索まで、今回の依頼に含めるわけではありません。

実装後は、以下の確認点をチェックしてください：

変更内容は最終段階で明記し、動作確認後は公開せずに担当者に提出してください。

変更前の質問と回答の一覧を残しておくと、表示が動くことに加えて、本文を保ったかも確認できます。別の検索機能を思いついた場合は、今回の変更へ混ぜず、追加案として分けてもらいます。

依頼文の例

FAQページに、入力した語を含む質問だけを表示する検索欄を追加してください。
対象は faq.html と faq.js です。新しい外部ライブラリは追加しないでください。
既存の質問と回答の本文は変えず、入力が空なら全件表示してください。
一致なしの場合は「該当する質問がありません」と表示してください。
空入力、一致あり、一致なしを確認し、変更したファイルと確認結果を最後にまとめてください。
公開はせず、変更内容を私が確認できる状態まで進めてください。

不具合は再現手順と期待する結果を伝える

エラーメッセージが存在する場合、秘密情報を除去した上で必要な範囲のみを添付する必要がある。

ログは必要な範囲だけを選び、秘密情報を取り除いて渡しましょう。

設定画面で通知の有効化を保存しても、ページを再読み込みすると元に戻る不具合があります。この例では、ユーザーが「通知を有効にし保存」した後、再読み込み時に設定が失われる問題を伝えます。

再現手順は以下の通りです：設定画面を開き、通知のスイッチをONにして保存します。その後、ページを再読み込みすることで、設定が無効になることを確認してください。この操作で問題が発生するため、期待する結果は「再読み込み後も通知が有効なまま残る」ことです。

関係ファイルとして、`settings.js`と`settings-api.js`が挙げられます。これらのファイル内で設定データの保持処理が行われている可能性があるため、修正時にはこれらのコードを重点的に確認してください。

確認点は、保存した設定が再読み込み後に維持されているかです。単に成功メッセージを修正しても不具合は解消されません。修正後の報告には、実際に再読み込みを行い、値が残るかを明記する必要があります。また、保存するデータの項目名や既存の値は変更せず、外部への公開は行わないようにしてください。

この例では、「保存しました」と出ることと、再読み込み後に設定が残ることを分けて確かめます。修正後も同じ操作をたどり、期待する結果と一致するかを見てください。

依頼文の例

設定画面で通知を有効にして保存すると「保存しました」と出ますが、再読み込みすると無効に戻ります。
再現手順は、設定画面を開く→通知を有効にする→保存→ページを再読み込み、です。
期待する結果は、再読み込み後も通知が有効なままであることです。
関係しそうなファイルは settings.js と settings-api.js です。
まず原因と修正案を説明し、必要な箇所を直してから同じ手順で確かめてください。
保存するデータの項目名と既存の設定値は維持してください。外部への公開はしないでください。

作業中に範囲を直すときの伝え方

ChatGPTデスクトップアプリでは、Settings > General > Follow-up behaviorで、追加メッセージをどう扱うかの既定動作を選べます。待機中のメッセージは入力欄の上に表示され、編集、並び替え、送信、削除ができます。この設定には、一度だけ別の動作を使うためのショートカットも表示されます。

Codex CLIで作業中にEnterキーを押すと、現在の作業へ追加メッセージを渡します。方向を直したり情報を足したりするときに使います。Tabキーでは、次のターンで処理するメッセージとして待機させます。

作業中の修正依頼では、目的を維持しながら範囲を調整する方法を説明します。最初の指示が完璧でなくても構いません。結果を確認した後、具体的な変更を求めることが重要です。例えば、「追加条件です。今回の対象はFAQページだけにしてください」というように、変更したい範囲と維持したい目的を両方記載します。既存の編集は残し、判断できない差分があればその部分だけ説明する形で依頼してください。 実行中に伝える操作と、次の作業として予約する操作を使い分けます。

Steer（方向修正） と Queue（待ち行列） の違いは、作業の進行に応じて使い分けます。

ChatGPTデスクトップアプリでは、[Settings > General > Follow-up behavior] でどちらかを選択できます。Queueのメッセージは入力欄上部に表示され、編集や削除が可能です。一方、Codex CLIでは、作業中に入力するキーによって動作が変わります。Enterキーで現在のターンに追加（Steer）、Tabキーで次のターンに待機（Queue）します。

例として、FAQページ限定でヘッダー変更を取り消す依頼は、以下のように記述します：

追加条件です。今回の対象はFAQページだけにしてください。
先ほどの「質問を検索できるようにする」という目的は維持し、共通ヘッダーの変更は取り消してください。
既存の私の編集は残してください。判断できない差分があれば、その箇所だけ説明してください。

このように、明確な条件と目的を伝えることで、誤った範囲の変更を防ぎます。

毎回の約束は短いAGENTS.mdにまとめる

誤字の修正の際、修正に必要なドキュメント一式または全リポジトリマップを毎回確認させるのは過剰であり、GPT-6 Astraは変更内容に応じて必要最小限の情報を抽出し、全プロジェクトのレビューを要求されることなく対応できる。

編集前のすべての修正でarchitecture.md、database.md、deployment.mdを確認することは不適切であり、代わりにサービス境界の設定にはarchitecture.md、スキーマ変更にはdatabase.md、デプロイメント準備時にはdeployment.mdを目的に応じて参照するよう指示するべきである。

従来モデルはテスト実行や作業確認のために誘導が必要であったが、GPT-6 Astraはこれらの作業を自動的に実行するため、同じ指示でも無駄なテストが発生する可能性がある。

以前のモデル向けに加えた強い承認指示が、今もそのまま必要か見直しましょう。安全と分かっている作業は許可する範囲を具体的にし、公開や外部送信など、確認してから進めたい操作は境界を残します。モデルに任せることと、権限設定を緩めることは別です。

GPT-5.6 Solが要求を受け取ると長時間継続して作業することに対し、GPT-6 Astraは作業の完了時点をより慎重に判断し、最初の実装を提出してからレビューを求める段階でまだ作業が完了していない場合もあり得る。

開始前に、何ができたら完了かを決めます。実装を動かし、結果を確認し、依頼した変更による失敗を直すところまで求めるなら、その範囲を明示しましょう。「最初の実装を出したらレビューを待つ」という指定は、そこで停止する方向に働きます。その確認の区切りが本当に必要かを考えます。

最初の試行を終えた後も探索を継続したい場合は、探索する内容と停止する条件を明確に指示する必要がある。

CodexはCodex用のホームディレクトリ（デフォルトは~/.codex、CODEX_HOMEを設定していない場合）にAGENTS.override.mdが存在する場合はそれを、存在しない場合はAGENTS.mdを読み込み、このレベルで最初の非空ファイルを採用する。

プロジェクトルート（通常はGitのルート）から現在作業ディレクトリまで、各ディレクトリでAGENTS.override.md、AGENTS.md、およびproject_doc_fallback_filenamesで指定された代替ファイル名を検査し、各ディレクトリで1つのファイルのみを含める。プロジェクトルートが見つからない場合は、現在作業ディレクトリのみを検査する。

Codexはルートから作業ディレクトリへ順に指示を結合します。作業ディレクトリに近いファイルの指示は後に入り、先に読んだ指示より優先されます。

空のファイルは読み飛ばされ、読み込む指示の合計がproject_doc_max_bytesの上限に達すると追加が止まります。既定値は32 KiBです。長い指示がある場合は、どの範囲へどの約束を置くかと、設定された上限の両方を確認します。

docs/screens.mdは例示用のファイル名であり、読者の実際の文書に置き換える必要がある。

存在しない参考文書を作業の前提として設定しないように注意する。

AGENTS.mdは、モデルがリポジトリ内で作業する際の基本的なガイドラインを定義するファイルです。このファイルは定期的に見直す必要がありますが、過剰な詳細や全資料の読み込みは避けて、必要な情報のみを明確に記述することが重要です。以下に、実践的な例とその理由を説明します。

必要な情報を簡潔に記述

「すべての変更で全資料を読む」ようなルールは避け、場面に応じた資料を指定しましょう。例えば、画面の文言を日本語にする、既存の色や配置を維持する、ローカル確認を行うなど、具体的な指示を明示します（例：`docs/screens.md`参照）。こうすることで、モデルは必要最小限の情報を基に作業を進めることができます。

不要な手順を省略

小さな修正には、architecture.mdやdatabase.mdなどの全ドキュメントを読み込む必要はありません。GPT-6 Astraは、必要な部分だけを自動で読み取る能力があります。たとえば、「タイポ修正」のような単純な作業では、事前に複数のドキュメントを読ませるよりも、直接的な指示が効率的です。

テストの自動化と許可範囲

許可するテストは条件を具体的にします。公式ブログには、使い捨てのテストデータを使い、本番へアクセスしないテストについて、依頼による失敗の修正と再確認を都度承認なしで許可する例があります。自分のテストにもその条件が当てはまるかを確認してから使いましょう。すべてのローカルテストが本番へ影響しないという意味ではありません。

共通の指示ファイルの読み込み順

AGENTS.mdの読み込み順は以下の通りです：

指示の合計サイズの既定上限は32KiBです。長い指示が必要なら、上限の設定と、どの階層で必要になる説明かを見直します。

過去の不具合への対応

一度だけの依頼はチャットで記述し、共通ルールは毎回守るべき条件を明記します。過去の注意点を残しておくと、新しい依頼と衝突する可能性があるため、定期的に見直すことが求められます。権限設定や作業範囲の明確化は別途行います。

実際の例

`docs/screens.md`は実際の文書に置き換える必要があります。このように、場面と資料を対応させることで、モデルが正確な指示を受け取りやすくなります。

共通ルールに書く例としては、日本語で説明すること、依頼と無関係な既存編集を残すこと、表示修正で色と配置を維持することが挙げられます。確認した内容を報告してもらい、公開・実データの削除・外部送信は実行前に確認する、といった条件も書けます。画面構成の変更時だけ読む資料を対応させると、毎回すべての文書を読むという指示を避けられます。

共通ルールの文面例

# このプロジェクトでの作業
- 説明と画面の文言は日本語にする。
- 依頼と関係のない既存変更は残す。
- 表示の修正では既存の色と配置を維持する。
- 今回の変更に関係するローカル確認を行い、確認した内容を報告する。
- 公開、実データの削除、外部への送信は実行前に確認する。
- 画面の構成を変えるときは docs/screens.md を参照する。

繰り返す作業だけをスキルにする

スキルとは、繰り返し行う作業手順をまとめたものです。例えば、FAQの質問・回答を更新する際のチェックリストなど、特定の作業に限定して設計します。

自分でスキルを指定するには、ChatGPTでは`@`から選びます。Codex CLIやIDE拡張では`/skills`、または`$`による指定を使います。どの画面を使っているかで操作を分けてください。

説明を伝えて作る場合は、Codexで`$skill-creator`を呼び出せます。作成時には、何をするスキルか、いつ使うか、指示だけにするかスクリプトも含めるかを聞かれます。既定は指示だけです。最初からプログラムを用意する必要はありません。

スキルの発動範囲

Codexは依頼がスキルの説明に合うと判断した場合、自動で選ぶこともあります。説明が短く扱われる場合にも用途が伝わるよう、主な用途と言葉を先頭に置きます。例えば「FAQの質問・回答を追加または変更するときの確認」と書くと、使う場面を絞れます。

スキルの作成方法

1. 手動作成: `SKILL.md`ファイルを含むフォルダを作成し、以下のように記述します。

---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---

Skill instructions for ChatGPT or Codex to follow.

Codexはファイル変更を自動検出し、反映されない場合は再起動が必要です。

2. レコード＆リプレイ: 作業手順を録画し、自動でスキル草案を作成します。手順が複雑な場合や、説明よりも実演の方が効果的であれば、この方法がおすすめです。

FAQの独自例

FAQ更新時のチェックリストを作成する際、スキルの説明文を「文章や画面に関わるときは必ず使う」と広げると、意図しない作業にも対象になるリスクがあります。そのため、用途を「FAQの質問・回答を追加または変更するときの確認」と限定することで、誤った適用を防ぎます。

注意点

設定が反映されないときに見る場所

Codexの設定が期待通りにならないときは、同じ項目を別の場所でも指定していないか確認します。個人の設定は`~/.codex/config.toml`、プロジェクトの設定は`.codex/config.toml`です。IDE拡張から開く場合は、右上の歯車を選び、Codex Settings > Open config.tomlへ進みます。

共通の既定値はconfig.tomlにまとめ、プロファイルには切り替えたい違いを置く、という使い分けができます。クラウド管理やシステムの設定には、プラグインの配布元や既定で有効にするかの指定が含まれる場合もあります。これらの既定値と、requirements.tomlによる組織の強制的な制約は別に考えます。

Codexの設定が期待通りに反映されない場合、以下の順序で設定ファイルや構成レイヤーを確認してください。設定優先度は以下の通りです（高い順）：

1. CLIフラグと`--config`オーバーライド

コマンドラインで直接指定したパラメータが優先されます。どのファイルを直すか決める前に、起動時の指定が残っていないかを見る順序です。

2. プロジェクト構成ファイル（`.codex/config.toml`）

プロジェクトルートから現在の作業ディレクトリへ設定を読み、同じ項目は作業場所に近い指定が優先されます。プロジェクトが信頼されていない場合、この層は読み込まれません。

3. プロファイルファイル（`~/.codex/profile-name.config.toml`）

`--profile profile-name`で指定したプロファイルファイルが上書きします。これは、ユーザー構成と差異のある値を保持するための用途です。

4. ユーザー構成ファイル（`~/.codex/config.toml`）

デフォルトの個人設定が格納されています。

5. クラウドマネージドの`config.toml`デフォルト

サインイン中のワークスペースで配布される場合に適用されます。

6. システム構成ファイル（`/etc/codex/config.toml`）

Unix環境では存在する場合に読み込まれます。

7. ビルトインデフォルト

すべての設定が上記の層に置き換えられない場合の初期値です。

信頼されていないプロジェクトの処理

プロジェクトが信頼されていない場合、`.codex/`層内の構成、hooks、rulesは無視されます。ただし、ユーザー構成とシステム構成は依然としてロードされます。

一時オーバーライドの方法

一度だけ設定を変えるCLIの指定には`-c`または`--config`を使います。設定名や値の書式は、変更したい項目に対応する公式の設定資料で確認してください。

TOMLのクォーティングルールに注意し、必要に応じて`--config`でキー/値を指定してください。

管理端末での制約

組織が`requirements.toml`を通じて承認ポリシーや実行範囲を強制する場合があります。例えば、`approval_policy = "never"`や`sandbox_mode = "danger-full-access"`が禁止されることがあります。このような制約は、管理者が設定した`requirements.toml`に基づいて適用されます。

重要な例外と確認点

設定が反映されない原因を特定する際は、上記の順序で各層を確認し、必要な修正を行ってください。

受け取った変更を確認して、次の依頼へつなぐ

完了って言われたらすぐ公開していい？

今回の依頼例はローカル確認までです。変更内容と確認結果を見てから、公開を別に判断しましょう。

読者が見る点は、目的に対応した変更か、触らない条件を守ったか、実行した確認と結果が示されたか、残る問題が区別されたか。完了文だけでなく、変更されたファイルや画面を見て判断する。

レビューの実施方法とよくあるつまずき

ここでは、変更後の確認を頼むために作った依頼例を使います。確認と修正を分け、まず問題がある箇所を知りたい場合の文面です。

今回の変更だけを確認してください。まだコードは書き換えないでください。
入力が空のとき、一致しないとき、従来の表示を使うときに不具合がないか調べてください。
修正が必要なら、対象の箇所、問題が起きる条件、理由を説明してください。
指摘がなければ、その旨と確認範囲だけを報告してください。

この例では、特定の条件（入力が空、一致しないなど）での動作確認を求めており、修正の必要性を明確に提示しています。

コマンドの使い方と注意点

変更内容を確認するには、`/review`コマンドを使用します。アプリやCLI、IDE拡張でそれぞれ異なる使い方があります：

注意点：`/review`コマンドは、プロジェクトがGitリポジトリ内である必要があります。リポジトリが作成されていない場合は、アプリが自動的に作成を促します。

よくある失敗と対処法

次に頼むことを決める

確認後は、変更内容を反映するか、さらなる調整が必要かを判断します。重要な仕事では、最終確認を依頼し、自分でも結果を再チェックします。これにより、誤った変更や意図せぬ影響を防ぎ、次の依頼にスムーズに移行できます。

次の依頼を決めるためにも、「完了しました」という返答だけで済ませず、目的の動作と変更されたファイルを見比べて行います。触らないよう指定した色や配置、既存の文章が残っているかも確認しましょう。実行した確認の結果と、まだ分からないことが分かれていれば、次に何を頼むか決めやすくなります。

レビュー画面で変更を確定したり外部へ送ったりする操作は、問題の点検とは分けて判断してください。今回の依頼例は、公開する前に人が確認できるところで止める内容です。

モデルの利用可否と、ファイルを変更・公開してよいかの権限も別の話です。考える強さを上げても、資料不足や利用権限の問題が解消するわけではありません。手元のプランや残量、使えるモデルは自分の画面で確認し、まずは対象を絞った依頼から試してみてください。

公式資料を確認する

モデルの選び方：https://learn.chatgpt.com/docs/models Astra向けの指示の整理：https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra 設定の場所と優先順位：https://learn.chatgpt.com/docs/config-file/config-basic