この記事の根拠

本記事の根拠は、OpenAIのGPT-6 Astra公式ガイドCodex公式ドキュメントのサブエージェントの解説、そして2026年9月9日にCodex開発チームのメンバーがXに投稿した内容です。投稿は個人の発信で、公式ドキュメントではありません。その区別は本文でも明記します。

結論:強いモデルほど、厚いハーネスが足を引っ張る

ハーネスとは、AGENTS.md・Skills・サブエージェント・Hooksのように、AIを安定して走らせるための仕組みの総称です(全体像はCodexのハーネスとは)。この仕組みの多くは、モデルが指示を守らなかった時代の対策として厚くなってきました

強調を重ねる、同じ注意を3か所に書く、手順を細かく固定する、分担の形まで指定する。以前のモデルには効いたこれらの工夫が、Astraでは逆に働きます。指示に敏感なので余計な一文まで律儀に守り、単独で走れるのに分担を強いられて遅くなるからです。

表は横にスクロールできます →

以前のモデル向けの書き方Astraでの読まれ方
「必ず慎重に。作業前に確認してください」文字どおり守り、確認待ちが増える
「重要」「絶対」を何か所にも重ねるどれが本当の優先事項か分からなくなる
「テストは必ず書く」を一律に置く小さな修正でも検証の範囲が広がる
「常に3体で分担して進める」分けなくてよい仕事まで分け、利用枠を消費する

つまり、いま起きているのはハーネスの賞味期限切れです。足りないから足す局面ではなく、効かなくなった脂肪を落とし、残った1行1行が確実に振る舞いを変える状態にする。それを当社は「薄く筋肉質なハーネス」と呼んでいます。

OpenAI側が言っていることを、出所ごとに整理する

まず事実関係です。「Astraにはサブエージェントが要らない」と一言でまとめられがちですが、公式ドキュメントと開発チームの個人の発信では、言っている強さが違います。混ぜずに並べます。

表は横にスクロールできます →

言われていること出所位置づけ
SkillsやAGENTS.mdの指示に以前より敏感。参照できるファイルの点検を強く推奨GPT-6 Astra公式ガイド公式
期待より委任が少ないことがある。並列化してよい場面は指示で促すGPT-6 Astra公式ガイド公式
サブエージェントは読み取り中心の並列作業向き。書き込みの並列は衝突に注意。1体より多くのトークンを使うCodex公式ドキュメント公式
場当たりなマルチエージェント構成をやめてほしい。利用枠を消費し結果も悪くなる。Astraは大半の仕事を単独でこなせ、司令塔と作業者の構成は不要開発チームメンバーの投稿個人の発信

投稿の原文はCodex開発チームのAhmed Ibrahim氏による2026年9月9日の投稿です。要点は「トレードオフを理解せずに、形だけのマルチエージェント構成を強いるのをやめよう」であって、サブエージェントという機能を否定してはいません。

公式ガイドの側は、むしろ「Astraは既定では委任が控えめなので、並列化したければ指示で促せ」と書いています。2つを合わせると、正確な読み方はこうなります。既定は単独走行。分担は明確に有利な場面だけ、人が意図して指定する。

「指示ファイルを見直せ」は公式、「サブエージェントは控えめに」は開発者の助言

前者は公式ガイドに「強く推奨」と明記されています。後者は開発チームのメンバー個人の発信ですが、公式ドキュメントの「トークン消費が増える」「既定では委任しない」という記述と矛盾しません。当社は両方を採用し、以下の減量手順に落とし込みました

「薄く筋肉質」とは何か — 脂肪の見分け方

薄いとは、毎回読ませる量が少ないこと。筋肉質とは、残した1行1行が実際に振る舞いを変えることです。長さは目的ではなく、削った結果として短くなる。逆に、短くても効かない行ばかりなら筋肉質ではありません。

では何が脂肪か。当社が提案する分類は次の5つです。どれも「以前のモデルには必要だった」ものが多く、削るのに勇気が要ります。だからこそ、基準を先に決めておきます。

  • モデルが自分で分かること — フォルダ構成、使っている言語、ファイルの一覧。コードや資料を読めば分かる情報は、書かなくても同じ結果になる
  • 言い直しと強調の重複 — 同じ注意が別の言葉で3か所にある。Astraには1回で十分で、重複は優先順位を曇らせる
  • もう起きていない失敗への対策 — 半年前のモデルが繰り返した間違いへのルール。今のモデルで再現しないなら役目を終えている
  • 一律の慎重さ — 「必ず確認」「慎重に」「テストを必ず」を場面を限定せずに置いた行。止まる条件と検証の範囲は、限定して書き直す
  • 形だけの分担指示 — 「まず司令塔が計画し、3体に振り分けて」のように、仕事の中身と無関係に構成を固定した行

Claude Code側の公式ドキュメントも同じ方向を示しています。CLAUDE.mdは200行以内を目標に、長いほど遵守率が下がると明記し、コードから導ける内容は削って「落とし穴・理由・既定と違う約束」だけ残すよう案内しています。ツールを問わず、脂肪の定義は共通です。

① AGENTS.mdの減量 — 1行ずつ「無いと何が起きるか」で裁く

AGENTS.mdは毎回読み込まれる憲法です。ここが厚いと、すべての仕事に脂肪が乗ります。減量は1行ずつ「この行が無いと何が起きるか」を問うことから始めます。基本の書き方と32KiBの上限はAGENTS.mdの書き方をご覧ください。

  1. 1A:無いと事故が起きる行 — 公開・送信・削除・課金の前で止まる条件、触ってはいけないファイル、社内規程。残す。ただし機械的に止められるものはHooksへ移す候補
  2. 2B:無いと品質が落ちる行(具体例が言える) — 「ここを守らなかった結果、こう困った」が直近で言える行。残す。言えないならCへ
  3. 3C:無くても同じ結果になる行 — 自分で分かること、重複、過去の対策、一律の慎重さ、形だけの分担。削除候補

この分類は、Astra自身にやらせると速いです。ただし削除の判断は人が下し、まずは提案までで止めます。以下は当社の依頼文の作例です。

AGENTS.mdの減量点検を頼む依頼文の作例。ファイルは変更せず、提案までで止めます
markdown
このプロジェクトで読み込まれるAGENTS.md(グローバルと作業フォルダの両方)を読み、
各行を次の3つに分類してください。

A:無いと事故が起きる行
 (戻せない操作の前で止まる条件・触ってはいけない対象・社内規程)
B:無いと品質が落ちる行
 (守らなかった場合に何が起きるかを具体的に言えるもの)
C:無くても今のあなたなら同じ結果になる行
 (コードや資料を読めば分かること・他の行と重複・一律の「必ず確認」「慎重に」)

出力は行ごとに「原文/分類/理由」の表にしてください。
Cと判断した行は、削除した場合に起きうる問題も1行で添えてください。
Aのうち、スクリプトで機械的に止められるものにはその旨を付けてください。
この段階ではファイルを変更しないでください。

削ってはいけない行

Aに当たる行は、短くしても消さないでください。自律を上げるほど、止める線の明文化が重要になるのはAstraの気の利き方の記事で書いたとおりです。減量の目的は薄くすることではなく、A・Bだけが残った状態を作ることです。

減量後のAGENTS.mdは、多くの場合「止める線」「自律の方針」「このプロジェクト固有の約束」の3節に収まります。手順の詳細が残っていたらSkillsへ、特定フォルダだけの話ならサブフォルダのAGENTS.mdへ逃がします。

② Skillsの減量 — 「置いておくだけなら無害」は通用しない

Skillsは必要なときだけ読まれるので、増えても邪魔にならない。これはSkillsの作り方でも説明した設計思想で、基本は今も正しいです。ただし公式ガイドは、AstraがSkillsの中の指示にも敏感だと明記しています。

影響は2段階で出ます。1つは選ばれる段階で、似た説明文(description)のSkillが2つあると、どちらを使うか迷うか、意図しない方が選ばれます。もう1つは読まれた後で、Skillの中に残った「必ず確認してから」の一文が、AGENTS.mdの自律方針を上書きして作業を止めます。

点検は3つです。①直近1か月で一度も呼ばれていないSkillは、フォルダから外して別の場所に保管します(削除ではなく退避)。②似た仕事を扱うSkillが2つ以上あれば、1つに統合するか、説明文で使い分けを明確にします。

③Skillの本文にある慎重指示は、その手順に固有の理由がないなら削ります。「必ず確認してから」が必要なのは、その手順の中の戻せない操作の直前だけです。場面を限定して書き直せば、Skillの自動実行とAGENTS.mdの自律方針が競合しなくなります。

退避と統合を終えたら、残ったSkillの説明文を並べて読んでください。説明文だけで「どの場面でどれが選ばれるか」が一意に決まるなら筋肉質です。決まらなければ、Skillの数ではなく説明文の書き分けが足りていません。

③ サブエージェント — 既定はオフ、残すのは2用途

ここが今回いちばん判断が変わる部分です。以前のモデルでは「分けたほうが精度が出る」場面が多く、当社の記事でも分担の頼み方を丁寧に解説してきました(サブエージェントと並列実行)。Astraでは、既定を「使わない」に置き直します

理由は3つ、いずれも一次情報にあります。単独で大半の仕事をこなせる(開発チームの発信)。担当ごとにモデルとツールを動かすため、1体より多くのトークンを使う(公式ドキュメント)。そして分担すると、結果を統合する工程と書き込みの衝突という新しい失敗点が増える(同)。

それでも残す価値がある用途は2つです。Codex公式ドキュメントが向いているとする読み取り中心の並列作業と、当社が実運用で置いている公開前チェックの専任担当のような別の文脈で見せる品質チェックです。

表は横にスクロールできます →

残す用途なぜ分担が有利か条件
大量資料の並列調査読む量が多く、中間情報で本題の会話を埋めたくない。調査どうしが独立している各担当は読み取りのみ。結果は要約で受け取る
公開前の品質チェック(QC)書いた本人とは別の文脈で見せるほうが見落としが減る。合格基準を固定できるread-onlyで動かし、指摘はするが書き換えない

表は横にスクロールできます →

やめるもの代わりに
司令塔+作業者の常設構成1体に目的・制約・完成条件を渡す
AGENTS.mdの「常に◯体で分担」分担は依頼文で、その仕事にだけ指定する
同じファイルを複数の担当が編集する並列編集は1体に固定し、調査と検証だけ分ける
数行の修正・短い文章の分担分担しない。統合の手間のほうが大きい

利用枠の観点も無視できません。Codexはエージェント利用枠を消費し、担当が増えた分だけ消費も増えます。「速くなった気がする」だけで常設していた分担は、Astraでは利用枠と品質の両方でコストになります。利用枠の確認方法はCodexの利用制限をご覧ください。

Claude Codeの公式ドキュメントも、判断基準はほぼ同じです。やり取りを繰り返す作業、工程間で文脈を共有する作業、小さな修正、待ち時間が惜しい場面はメインの会話で。サブエージェントは、出力が長い作業と、自己完結して要約で返せる作業に限る、と整理しています。

Hooksだけは減らさない — 削った「お願い」の受け皿

減量の対象から外すのがHooksです。AGENTS.mdから「必ず◯◯しないで」というお願いを削るなら、そのうち機械的に止められるものはHooksへ移します。AIの判断を挟まず必ず走るので、指示が薄くなっても安全の線は薄くなりません。

順番を間違えないでください。先にHooksで受け皿を作り、それからAGENTS.mdの該当行を削る。逆にすると、お願いも強制もない空白の期間が生まれます。設定のしかたはCodexのHooksで解説しています。

減量の進め方 — 2週間で1周する

一気に半分削るのではなく、記録を取りながら2週間で1周させます。当社が研修で勧めている手順は次のとおりです。

  1. 11週目:記録する — 止まった回数と理由、サブエージェントを使った回数、1日の利用枠の消費を、いつもの仕事のまま記録する。減量前の基準値を作る
  2. 2週末:分類する — 上の依頼文でAGENTS.mdをA・B・Cに分類し、Skillsの3点検を行う。Cの行と退避するSkillを一覧にする
  3. 32週目の頭:Hooksを先に置き、Cを削る — 受け皿を作ってから削除。サブエージェントの常設指示も外し、既定を単独走行にする
  4. 42週目:同じ仕事で比べる — 1週目と同じ種類の仕事を回し、止まった回数・利用枠・手直しの時間を並べる

判断基準は「止まる回数が減り、利用枠の消費が減り、成果物の質が落ちていない」の3つがそろうことです。質が落ちた行があれば、それは実はBだった行なので戻します。戻す行が出るのは失敗ではなく、分類の精度が上がった証拠です。

そして減量は一度で終わりません。AGENTS.mdは「同じ指摘を2回したら1行追記」で育つので、放っておけばまた厚くなります。追記のルールと同じ強さで「2週間効かなかった行は削る」を運用に組み込むのが、薄く筋肉質な状態を保つ方法です。

まとめ — 足す時代から、削る時代へ

Astraの登場で変わったのは、モデルの賢さだけではありません。ハーネスの役割が「足りない能力を補う」から「余計な干渉を減らす」へ移ったことが本質です。AGENTS.mdは止める線と自律の方針に絞り、Skillsは説明文で一意に選ばれる数まで減らし、サブエージェントは既定でオフにして2用途だけ残す。

株式会社AI OrchestraのCodex研修・導入伴走支援では、貴社のAGENTS.md・Skills・サブエージェント定義をその場で棚卸しし、何を残し、何をHooksへ移し、何を削るかを一緒に決めます。厚くなったハーネスをそのまま持ち込んでいただければ、減量の1周目を研修の中で回せます。

厚くなったハーネスを減量したい企業様へ。実際のAGENTS.md・Skillsを題材に、削る基準と残す線を組織で決める法人研修・導入伴走支援を提供しています。