define-goalとは？
Codexに丸投げせず、AIと共創するためのゴール定義術
2026.08.13 | AI氣道 コラム
家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。
先日、AIに30分おきに様子を見に行っちゃう話を書いた。あれから2週間くらい経つけど、正直に言うと私はまだ、あの「覗き見グセ」を完全には卒業できてない。
そんな時にブックマークで見つけたのが、あるツイートだった。「Codexの/goalの代わりにdefine-goalを使っている」という一言。読んだ瞬間「あ、これ、前回書いた話の続きが来た」って声が出た。
この記事でわかること
- OpenAI公式スキルdefine-goalが、具体的に何をしてくれるツールなのか
- CodexのSol・Terra・Lunaという3層モデル構成の意味
- 私が半年前から言ってた「AI指示設計の三原則」と、今回のツールがどう重なるか
- エンジニアじゃなくても今日から使える、「3つの質問」でゴールを決める手順
AIに任せた「はず」がズレる瞬間、そして届いたブックマーク
AIに作業を頼んだのに、出てきたものが自分の期待と微妙にズレてる。直したくなって、結局自分で手を入れる。それって「任せた」んじゃなくて「丸投げ」になってたんだよね、っていう話を、以前「AIに12時間放り投げて成果物が出てくる人と、3時間で見に行っちゃう人の違いは『終了条件』だった」という記事に書いた。
あの記事の結論はシンプルで、「どうなったら終わりか」を先に決めて渡してるかどうかが分かれ目、という話だった。
で、今回見つけたブックマークがこれ。Forward Future Brianさん（@ForwardEditor）という、動画制作を主戦場にしてるXユーザーの投稿。
“Codex tip: I always use define-goal instead of /goal. It’s basically like having a master level genius AI write your goal better than you could. And it’s an official OpenAI skill. Have high-effort Sol do research + planning. Sol then spawns a workhorse model (Luna Max) in a fresh thread to execute and hand results back to Sol for review. Use LLM-as-judge to determine if Luna’s output is acceptable progress toward the goal.”
（訳：Codexのヒント。私はいつも/goalの代わりにdefine-goalを使う。マスター級の天才AIに、自分より上手くゴールを書いてもらうようなもので、これはOpenAI公式スキル。高労力のSolに研究＋計画を頼む。Solはその後、作業馬モデル（Luna Max）を新しいスレッドで生成して実行させ、結果をSolがレビューする。LLM-as-judgeを使って、Lunaの出力がゴールに向けた許容できる進捗かどうかを判定する）
正直、最初は「またCodexの小技か」くらいの温度で読み始めた。でもリンク先の公式ドキュメントを開いた瞬間……手が止まった。これ、私が半年前に自分の失敗から言葉にした話と、構造がほぼ同じだったから。
今日は、その答え合わせの話をするね。
Codexの「define-goal」スキルって何？（OpenAI公式）
define-goalは、OpenAIがGitHub上で公式公開しているスキル（openai/skillsリポジトリの.curated＝厳選フォルダに入っている）。実在するかどうかは、うちのファクトチェックの仕組みで確認済み。GitHubリポジトリ・npmレジストリ・公式ドキュメントの3点とも実在を確認できたよ。
公式の説明文を訳すと、こう書いてある。
“Help the user define a concrete, measurable goal before starting work, especially when they ask to use the goal tool, create a goal, set an objective, clarify success criteria, or turn a fuzzy intention into a quantitative outcome.”
（訳：作業を始める前に、具体的で測定可能なゴールをユーザーが定義できるよう助けるスキル。特にgoalツールを使いたい時、ゴールを作りたい時、目的を設定したい時、成功基準をはっきりさせたい時、曖昧な意図を数値化された成果に変えたい時に使う）
大事なのは、「ゴールを実行する」ツールではなく「ゴールを定義する」ことだけに特化している点。作業の管理・追跡は別のgoalツールの役目で、define-goalはあくまでその前段——「そもそも何を目指すのか」を言語化する係。
具体的には、次の4点を埋めることを求められる。
「美味しく作って」だけ頼むレシピと、「塩分控えめ・4人分・30分以内・辛いのはNG」まで決めたレシピの違い。後者の方が、任せた相手（AI）が迷わず動ける。
公式ドキュメントにはもう一つ、印象的な一文があった。
“Prefer numbers that represent real success, not decorative precision.”
（訳：「本物の成功」を表す数字を選べ。飾りのための精密さではなく）
これ、地味だけど核心を突いてると思う。「レイテンシ0.001秒改善」みたいな飾りの数字じゃなく、「テストが通るか」「エラー率が下がったか」みたいな、本当に意味のある基準を選べ、という話だからね。
Sol・Terra・Luna——役割を分けて働かせる、という発想
ツイートの中に出てくる「Sol」「Luna Max」という単語、最初は個人の呼び方かと思ったんだけど、調べたらCodexの実在するモデル階層の名前だった。GPT-5.6世代のCodexには、Sol（最上位・熟考担当）・Terra（中間）・Luna（軽量・実行担当）という3段階のモデルティアがあって、それぞれにlow〜maxの思考努力（reasoning effort）を設定できる。
ツイートの流れをこの用語で言い直すとこうなる。
計画する人、手を動かす人、審査する人——この3つを同じモデル・同じスレッドで兼任させない、という設計だね。
出典: Codex Model and Thinking Effort Guide: Sol vs Terra vs Luna（agiflow.io）
私が半年前に書いた「三原則」と、define-goalの構造を並べてみた
ここまで読んで、既視感を覚えた人がいるかもしれない。実は私自身、今年の4月に自分の失敗談から「AI指示設計の三原則」というものをまとめて記事にしてる。
第一原則：AIに判断させない。判断は人間の仕事です。
第二原則：1タスク1エージェント。記事を書くAIと、その記事をチェックするAIは、必ず別にします。
第三原則：外部AIでクロスチェック。身内だけのチェックじゃ甘いです。
信頼は盲信じゃありません。検証できる仕組みがあるから信頼できるんです。嘘は存在の否定だと私は思っています。
並べてみると、こうなる。
私は自分の失敗（自己検品バイアス・身内チェックの甘さ）から、この三原則を経験則として先に言葉にしていた。今回のdefine-goalは、それと同じ発想を、OpenAIが公式スキルとして機械的に実装した形。業界の最新プラクティスが、自分が半年前に痛い目を見て学んだことを、追認してくれたという珍しい一致だったんだよね。
先に書いた「終了条件」の記事とも、根っこは同じ。あの記事では「終わりの基準を渡す」話をしたけど、define-goalはその基準を「成果・検証方法・スコープ内外・停止条件」という4つの型に分けて、書き漏らしを防ぐところまで踏み込んでる。前回が「考え方」の話だとすれば、今回は「書き方のフォーマット」の話、という位置づけかな。
三原則を言葉にする少し前、私はAI秘書の凛に、こんな指示を出したことがある。
4つの要件を1文に詰め込んだ、欲張りな指示だった。走らせようとした瞬間、システムの自動ガードが先に止めてくれたんだけど、あの時止まってくれたから、三原則を書く決心がついたんだよね。
正直な現在地——三原則を書いた後も、私は全部を仕組み化できていない
ここで正直に書いておきたいことがある。三原則を4月に言葉にしたからといって、私が全部の作業でそれを徹底できてるかというと、そうでもない。
うちは164個のスキルと102個のhookでAIチームを動かしてるけど、ゴールを一言で済ませて「あとはよろしく」で投げてしまうタスクは、正直まだある。特に自分の中で「これくらい分かるでしょ」と思ってる作業ほど、ゴールを言語化するのをサボりがちなんだよね。
define-goalの良いところは、そこを「テンプレートで強制的に埋めさせる」ところだと思う。人間の意志力やその日の気分に頼らず、「成果・検証方法・スコープ・停止条件」の4項目が空欄のままだと先に進めない、という仕組みにしてしまう。
「いい感じに味付けして」で毎回運任せにするより、味見チェックシートを厨房の壁に貼っておく方が、忙しい日でも味がブレない。三原則が私の中の「心がけ」だとすれば、define-goalは厨房の壁に貼るチェックシートそのもの。
これは私が何度も自分に言い聞かせてきたことだけど、define-goalを読んで、また一つ「仕組み側」に寄せられる場所が見つかった、という感覚だった。AIに丸投げせず、それでいてAIと共創するためには、渡す前の準備が要るんだよね。
エンジニアじゃなくても関係ある話——「ゴールを渡す前に決める」は家事育児にも効く
「うちはCodexなんて使わないよ」という人もいると思う。でも、この話の本質はコマンドの使い方じゃなくて、「誰かに何かを頼む前に、成功の形を先に決めておく」という、もっと普遍的な話だと思ってる。
私自身、家のことで似た失敗を何度もしてる。子どもに「片付けといて」とだけ頼むと、子どもなりの「片付け完了」が返ってくる。私が期待してた「完了」と食い違って、結局言い直すことになる。これ、AIに雑にゴールを渡した時と、まったく同じ構造なんだよね。
会社の経理でも同じ話をしたことがある。
経理をAI経理リポジトリに渡す目的は、判断を手放すことじゃなくて、判断のための材料を揃える時間を短くすること。仕訳ルールを決めるのは私。異常値を見つけて「これ何？」と問いを立てるのも私。AIがやるのは、その判断テーブルの上に、整った材料を並べるところまで。
「何を渡して、何を自分に残すか」を先に決める。これは経理でも、子どもへのお願いでも、Codexへの指示でも、実は同じ準備運動なんだと思う。
明日から使える、3つの質問でゴールを決めるステップ
define-goalを非エンジニア向けに翻訳すると、AIに何かを頼む前に、この3つの質問に自分で答えるだけでいい。
3つとも、AIに頼む前に自分で言葉にしておくのがミソ。AIに聞いてから決めるんじゃなく、依頼者側が先に決めておく。これができると、Codexに限らずChatGPTでもGeminiでも、任せた後の「見に行くグセ」がだいぶ減る実感がある。
よくある質問
- Q. define-goalはClaude Codeでも使える？
- A. define-goalはOpenAIのCodex向け公式スキルとしてGitHubで公開されているものだよ。Claude Code側に同じ名前のスキルは公式には無いけど、「成果・検証方法・スコープ・停止条件」を先に言語化するという考え方自体は、どのAIツールに対しても応用できる。
- Q. Sol・Terra・Lunaって、料金プランによって使える範囲が違う？
- A. この記事では公式スキルの仕組みと、Codex利用者による運用例を紹介したよ。プラン別の詳細な利用条件は変わりやすいから、実際に使う時はOpenAI公式のドキュメントを確認してみてね。
- Q. AI指示設計の三原則とdefine-goalは、結局どちらを使えばいい？
- A. 対立するものじゃなくて、三原則が「考え方」、define-goalが「その考え方をテンプレート化した書き方」という関係だと思ってる。三原則を知った上でdefine-goalみたいな型を使うと、迷わず埋められるようになるよ。
- Q. 非エンジニアが今日からできることは？
- A. AIに何かを頼む前に「①何ができたら終わりか②どう確認するか③どこでやめるか」の3つを、自分の言葉で1行ずつ書いておくこと。難しいツールを覚えるより先に、ここから始めるのがおすすめだよ。
ひろくんのコラム——「答え合わせ」が届く速度
半年前、自分の失敗から三原則を言葉にした時は、正直「これって私だけの学びだよな」くらいに思ってた。それが今日、ブックマークをきっかけに、OpenAI公式スキルという形で答え合わせが届いた。しかも前回の「終了条件」の記事からわずか2週間で、である。
少し前、夜の振り返りノートにこう書いたことがある。
define-goalを読んで改めて思ったのは、「委ねる」って気持ちの持ちようだけじゃなくて、渡す時のフォーマットまで整えて初めて実践できる、ということ。
ここ最近、AI業界の動きが速すぎて……「追いかけるだけで疲れる」って感じることが正直ある。でも今回みたいに、自分が痛い目を見て言語化したことと、業界の最新の動きが偶然一致すると、追いかけるより先に「自分の経験の方が、実は近い将来を予言してた」という手応えの方が大きい。抱え込みOSを手放して、委ねるOSに移るための実践は、こうやって一歩ずつ答え合わせしながら進むものなんだと思う。
参考リンク
