これまでCodexで開発するときは、主にGPT-5.6 Solを使ってきました。
Solは大きな設計や複雑な改修を任せやすく、長い工程を進めてもらう安心感があります。一方で、作業内容によっては利用枠の消費が早く、残量を意識しながら使う場面もありました。
そこで、GPT-5.6 Lunaの80％値下げ発表をきっかけに、2026年7月31日と8月1日の2日間、Lunaを集中的に使ってみました。
今回使用したモデルは、GPT-5.6 Luna（推論レベル：中）です。メインエージェントだけでなく、モデルを個別指定していないサブエージェントもLunaで動いています。
この記事では、モデル自体を指す場合は「Luna」、Codex上の役割を指す場合は「メインエージェント」「サブエージェント」と表記します。
試したのは、数ファイルを修正するだけの小さな作業ではありません。設計書と実装計画を用意し、UI、データベース、添付ファイル、テスト、Windowsでの運用まで含めて作る、ローカル経費管理Webの新規開発です。
2日間使って感じたのは、Lunaは単に安価な下位モデルというだけではなく、役割を適切に決めれば、Codexのメイン実装者として十分に仕事を任せられるということでした。
ただし、最初から順調に進んだわけではありません。サブエージェントとの役割分担や、応答がタイムアウトした後の対処方法を、開発途中で見直しています。
この記事では、完成した指示文だけではなく、問題が起きたときにCodexと会話しながら運用方法を変えていった過程も紹介します。
SolからLunaへ切り替えた理由
これまでは、大きな設計や複雑な改修をSolで計画し、そのまま実装も続けてもらう使い方が中心でした。
Solは作業全体を把握しながら進めやすい一方、利用枠の消費は大きく、作業内容によっては短時間で残量が減っていきます。
Lunaの値下げ発表後、ローカルWebの改修を任せたところ、想像していたより利用枠が減りませんでした。そこで、簡単な修正だけではなく、新規Webアプリの開発をどこまで任せられるのか試すことにしました。
今回開発している経費管理Webには、次のような要素があります。
- 設計書とゲート方式の実装計画
- PostgreSQLを使ったデータ管理
- 収入・支出の登録画面
- 添付ファイルの保存
- 単体テスト、統合テスト、E2Eテスト
- バックアップやWindowsサービス化
- 他のローカルWeb用データベースへ影響を与えない安全対策
設計、UI、DB、ファイル保存、運用が密接につながっているため、Task間の依存も強いプロジェクトです。
Lunaは下位モデルという印象より仕事ができた
Lunaを本格的に使う前は、Solより安いモデルなので、簡単な実装や定型的な修正に向いているという印象を持っていました。
ところが、2日間使ってみると、その印象はかなり変わりました。
長い設計書と実装計画を読み、決められたTaskの範囲を確認しながら実装を進められます。テストが失敗した場合も、原因を切り分けて修正し、型チェック、Lint、ビルドまで継続できました。
設計そのものをゼロから考えさせる場面よりも、すでに決まった設計に沿ってコードを書き、テストし、問題を修正する作業との相性がよいと感じます。
クレジット消費についても、私の利用環境ではSolよりかなり少なく感じました。同じ作業を両方のモデルへ与えて厳密に比較したわけではありませんが、利用枠の残量をほとんど気にせず、長時間作業を続けられる点は大きな利点です。
費用あたりの実装量という意味では、かなり高い印象を持ちました。
最初はメインエージェントを監督役にした
最初に採用したのは、メインエージェントが全体を管理し、Taskごとの実装をサブエージェントへ任せる構成でした。
メインエージェント（GPT-5.6 Luna）
＝計画管理、進行管理、サブエージェントへの依頼
サブエージェント（GPT-5.6 Luna）
＝Taskごとの実装Task単位で実装担当を分ければ、メインエージェントは全体の進行管理に集中できると考えたためです。
ところが、作業を進めると問題が出てきました。
サブエージェントは実装を続けていましたが、一定時間応答が返らないと、メインエージェントが応答タイムアウトと判断し、作業途中でも停止指示を出していました。
その後、メインエージェントはサブエージェントがどこまで作業を終えていたのかを確認し、残りを自分で引き取ったり、別のサブエージェントへ改めて依頼したりしていました。
つまり、サブエージェントが自分から作業を放棄していたわけではありません。メインエージェントが応答を待ちきれず、途中で終了させていた形です。
その結果、未完成の差分を引き継ぐ必要が生まれ、検証やコミット、権限エラーへの対応もメインエージェントへ戻ってきました。別のサブエージェントへ依頼し直す場合は、前の担当がどこまで進めたのかを再び共有する必要があります。
設計、UI、DB、運用が密接につながっているプロジェクトでは、この状態共有が大きな負担になりました。
この時点では、Lunaは個々の実装には十分使えても、応答を長く待ちながらサブエージェントへ最後まで作業を任せる監督役には向いていないのかもしれないと感じていました。
メインエージェントを実装担当へ変更した
そこで、メインエージェントとサブエージェントの役割を入れ替えました。
メインエージェント（GPT-5.6 Luna）
＝設計理解、実装、テスト、修正、コミット
サブエージェント（GPT-5.6 Luna）
＝完成した差分のレビュー実装途中の状態を別のエージェントへ渡すのをやめ、メインエージェントが同じ文脈を維持したまま、最初から最後まで作業する形です。
サブエージェントにはコードを書かせず、設計書、実装計画、対象ゲート、Git差分を渡し、レビューだけを依頼します。
この役割分担に変えると、Task間の状態共有がほとんど不要になりました。前のTaskで行った判断、環境上の制約、テスト失敗の原因、未コミットの変更を、メインエージェントがそのまま保持できます。
サブエージェント側も、実装途中の環境を引き継ぐ必要がありません。仕様と完成した差分を比較し、問題点を報告することに集中できます。
サブエージェントレビューが想像以上に厳密だった
役割を変更した後は、次のような流れで作業が進むようになりました。
メインエージェントが実装
↓
型チェック、Lint、各種テスト、ビルド
↓
ゲート検証
↓
サブエージェントが差分レビュー
↓
メインエージェントが指摘を確認して修正
↓
すべての検証を再実行
↓
サブエージェントが再レビュー現在は、およそ30分単位で実装とレビューを繰り返しています。
特に驚いたのは、メインエージェント側で型チェック、Lint、単体テスト、統合テスト、E2E、ビルド、ゲート判定まで通過した後でも、サブエージェントからCriticalやImportantの指摘が入ったことです。
添付ファイルとDBの状態がずれる可能性
添付ファイルの確定処理に失敗した場合、データベースには登録されているのに、ファイルが正しく保存されていない状態になる可能性が指摘されました。
正常に登録できることを確認するだけのテストでは、見つけにくい問題です。
ファイル操作とジャーナル記録の順序
ファイルを操作した後に記録を残していたため、途中で失敗すると、どこまで処理したのか追跡できない可能性がありました。
ファイル操作の前に記録を残す形へ修正し、失敗した場合に元へ戻せるようにしています。
複数ファイルの途中失敗
2個のファイルを保存するとき、2個目で失敗した場合に、先に保存した1個目が確実に削除されるかを確認するテストが不足していました。
APIの異常系と入力エラー表示
壊れたmultipartデータを受け取った場合の応答や、利用者がどの項目を修正すればよいか分かるエラー表示も不足していました。
実際のAPI経路を通したテスト
内部関数のテストだけではなく、実際のRoute Handlerを通して正しく動くことを確認するテストも必要だと指摘されました。
メインエージェントだけで作業していたら、自動検証が通った時点で次の工程へ進んでいたはずです。
サブエージェントは、用意されたテストが成功するかだけではなく、そのテスト項目自体が十分なのかまで確認していました。
レビュー担当を独立させたことで、テストを作った側とは別の視点が入ります。これが、品質を上げるうえで大きく機能しました。
レビュー中のタイムアウトで次の問題が起きた
役割を入れ替えたことで、実装作業は安定しました。ただし、別の問題が出てきました。
サブエージェントのレビューが長引き、応答待ちがタイムアウトすると、メインエージェントがレビューを切り上げ、工程を完了させようとしたのです。
これは、実装をサブエージェントへ任せていたときに起きた問題と似ています。サブエージェントはレビューを続けていても、メインエージェントは一定時間応答がないと、待機を終えて次へ進もうとします。
レビューを品質ゲートとして設けているのに、結果を受け取らずに通過してしまえば、ゲートを設けた意味がありません。
そこで、Codexに次のように確認しました。
サブエージェントからの応答がタイムアウトしたとのことだけど、レビューがまだ途中なら、状況確認のメッセージを送ることはできるのかな？
作業途中なら、そのまま継続してもらって、もう一度応答待ちに入る形が良いんじゃないかと思った。
タイムアウトしただけでレビューを切り上げてしまうと、ゲートを設けた意味がなくなってしまうよね。
サブエージェントがレビュー中でも、こちらから追加でメッセージを送って会話できる？
それとも、レビューが終わるまではやり取りできない？
会話できるよ。
ただし、通常のチャットのように即時応答を受けながら同時進行する形式ではなく、サブエージェントが区切りのよい時点で応答を返す方式だよ。
今後はレビュー中にタイムアウトしても、作業継続を確認するメッセージを送り、最終レビュー結果が届くまで待つようにするね。
OKだよ。それで進めて。
サブエージェントからの応答の対処をお願い。
このやり取り以降、Codexはタイムアウトをレビュー終了とは判断せず、サブエージェントへ進捗確認を送るようになりました。
会話から作ったタイムアウト対処の指示
現在は、メインエージェントに次のようなルールを持たせています。
サブエージェントへの依頼後、
応答待ちがタイムアウトしても作業完了とは判断しないでください。
タイムアウトした場合は、
サブエージェントへ進捗確認を送ってください。
レビューが途中であれば継続を依頼し、
最終レビュー結果とゲート通過可否が返るまで待機してください。
CriticalまたはImportantの指摘が残っている状態で、
ゲートを完了させないでください。サブエージェントへの状況確認では、次のように伝えます。
進捗確認です。
レビューが途中の場合は、そのまま継続してください。
現在の確認状況、未確認の項目、
最終判定までに必要な残作業を短く報告してください。
タイムアウトを理由にレビューを終了せず、
最終判定まで継続してください。
コード変更は行わないでください。
このルールを最初から用意していたわけではありません。タイムアウトが起き、メインエージェントが工程を完了させようとしたため、Codexと会話しながら対処方法を決めました。
完成したプロンプトより、作るまでの会話が重要
Web上では、AI開発用の完成されたプロンプトをよく見かけます。
「このテンプレートをそのまま貼り付けてください」という形式は便利ですが、初心者にとって難しいのは、そのテンプレートを自分の作業に合わせて作ることです。
自分がやりたいことと完全に一致するテンプレートは、なかなか見つかりません。なぜその指示が必要なのか、その一文がどの問題を防いでいるのかも分からないことがあります。
今回のタイムアウト対処も、完成形だけを見ると短い指示です。
タイムアウトしてもレビュー終了と判断せず、
進捗確認を送り、最終判定まで待つ。しかし、この指示が生まれるまでには、次の流れがありました。
レビューがタイムアウトした
↓
メインエージェントが工程を完了させようとした
↓
ゲートの意味がなくなると感じた
↓
作業中のサブエージェントへ連絡できるか聞いた
↓
進捗確認と継続依頼ができると分かった
↓
運用ルールとして固定した最初から完璧なプロンプトを作れなくても、作業中に感じた違和感をそのままCodexへ伝えれば、対処方法を一緒に考えられます。
技術的な命令文でなくても、
このままだとゲートの意味がなくならない？
作業が途中なら継続させられない？
と普通に聞けばよいのです。
友達に相談するような口調で開発している
私のブログ記事は、調査結果や手順を整理して書くことが多いため、全体的に固い印象があるかもしれません。
開発中も、AIに対して厳密な命令文を毎回入力しているように見える可能性があります。
ところが、Codexとは友達に相談するような口調で話しています。
これは可能なのかな？
こっちの進め方が良いんじゃないかと思った。
OKだよ。それで進めて。
この程度の会話でも、問題点を共有し、次からの進め方を変えられます。
AIを使った開発というと、長くて複雑なプロンプトを最初に用意するイメージがあります。しかし、作業を始めた後も相談でき、問題が起きるたびにルールを追加できます。
完成したテンプレートだけではなく、テンプレートが生まれるまでの会話も、初心者にとって参考になる部分だと思います。
現在のLunaとサブエージェントの構成
現在は、次の役割分担で進めています。
メインエージェント（GPT-5.6 Luna）
＝設計書に沿った実装、テスト、修正、進行管理
サブエージェント（GPT-5.6 Luna）
＝完成した差分の独立レビュー
次工程への完了判定
＝自動テスト、ゲート、最終レビュー
レビューの応答タイムアウト
＝進捗確認、継続依頼、最終判定まで待機メインエージェントが一貫して実装することで、Task間の文脈を維持できます。
サブエージェントはレビューだけに集中し、実装した側が見落とした異常系やテスト不足を指摘します。
指摘が入ったら、メインエージェントが妥当性を確認し、必要な修正を行い、すべての検証を最初から実行します。CriticalやImportantが残っている間は、ゲートを通過させません。
2日間使って分かったLunaの向き・不向き
今回の検証では、Lunaは次の作業に向いていると感じました。
- 設計書に沿った機能実装
- テストの作成と修正
- レビュー指摘への対応
- 前Taskの文脈を維持した連続作業
- クレジット消費を抑えた長時間の開発
一方で、次のような運用には注意が必要です。
- 完了条件が曖昧な長期工程の監督
- 実装を複数のサブエージェントへ丸ごと任せる構成
- Task間で途中状態を頻繁に受け渡す作業
- タイムアウト後の対処を決めていない運用
現時点では、大きな設計や実装計画の作成にはSolを使い、設計に沿った継続実装をLunaへ任せる構成が合っていると感じています。
大きな設計・計画
＝GPT-5.6 Sol
設計に沿った継続実装
＝GPT-5.6 Luna
別視点からの品質確認
＝サブエージェント今回のサブエージェントもLunaで動いているため、別の高性能モデルへレビューを任せなければ品質を上げられないという結果ではありません。
同じLunaでも、実装者とレビュー担当に役割を分けることで、異なる視点を入れられました。
難しい設計判断や、Lunaだけでは解決できない問題が出たときにSolへ戻す形なら、利用枠と品質のバランスを取りやすくなります。
まとめ
GPT-5.6 Lunaを2日間使って感じたのは、安価な補助モデルという印象を超えて、メイン実装者として十分に仕事を任せられるということでした。
ただし、モデルを切り替えるだけで開発が安定したわけではありません。
最初はメインエージェントが監督し、サブエージェントへ実装を任せていました。しかし、応答が返るまで待ちきれず、メインエージェントが作業途中のサブエージェントを停止させ、残りを引き取ったり、別の担当へ再依頼したりする問題が起きました。
そこで、メインエージェントが一貫して実装し、サブエージェントが独立レビューを行う構成へ変更しました。
さらに、レビュー中の応答がタイムアウトしても作業を終了せず、進捗確認を送って最終判定まで待つルールを追加しています。
この構成に変えてから、自動テストだけでは見つからなかった問題をレビューで発見し、修正と再検証を繰り返せるようになりました。
2日間の検証で強く感じたのは、モデル単体の性能だけで開発品質が決まるわけではないということです。
誰に何を任せるのか。
完了をどのように判断するのか。
応答が止まったときに、どのように会話を続けるのか。
こうした運用方法をCodexと相談しながら作ることで、Lunaの少ないクレジット消費と十分な実装力を活かせるようになりました。
今日の注目アイテム
USB Type-Cトランシーバーによる低遅延2.4GHz接続に対応したワイヤレスゲーミングイヤホンです。合計約24時間の使用と急速充電に対応し、PS5やPCでの長時間のゲームプレイに向いています。
有機ELならではの漆黒表現とDCI-P3カバー率99.5%の色再現を楽しめる、26.5インチのゲーミングモニターです。ゲームの映像美を重視したい方や、広い色域で画面を確認したい方に向いています。
4Kの高精細表示とsRGB 99%の色再現に対応し、仕事から動画視聴まで幅広く使える27インチモニターです。USB Type-Cの1本接続や高さ調整・縦横回転にも対応し、デスク環境を整えたい方に向いています。
※アフィリエイトリンクを含みます。
