OMX・OMC を Meta-Harness 製品として読まないために

0. シリーズ案内 (18/20)

M1 から M7 まで学習地図を辿ってきた方なら、頭の中にはこんな区切り線ができているはずです。Retrieval Layer、RAG、autoresearch、Meta-Harness。それぞれが何で、どこが研究方向で、どこが製品で、どこが単なるキーワードなのかを分ける練習を一緒にやってきました。

今回の M8 は少し違う角度です。実際に動いているツールを2つ、そのフレームの上に置いてみます。OMX (Oh My Codex) と OMC (Oh My Claude Code)。最近、韓国・日本の開発者 Twitter でよく見かける名前ですね。各種紹介記事で「自己改善 AI エージェント」「autoresearch を実装した製品」「Meta-Harness を搭載」といった表現がくっついて出てきます。

その文章をそのまま信じて導入判断を下すと、期待が裏切られる可能性が高いです。今回やりたいのは一つだけです。これらのツールを学習地図のどの座標に置けば正確なのか を一緒に測ることです。賞賛でもなく、こき下ろしでもありません。寸法をきちんと測る練習です。

---

1. 「OMX が autoresearch を実装した」という記事を正しく読むには

最近、OMX を紹介する記事でよく見る一行があります。

「OMX は autoresearch コマンドを内蔵した、自分で学ぶエージェントだ。」

この文章の前で、実務家は一瞬立ち止まるべきです。なぜなら、ここには 二つのことがさりげなく混ざっている からです。

一つは 名前 です。OMX の CLI コマンドリストの中に autoresearch という名前が実際に掛かっています。これは事実です。

もう一つは 概念 です。M6 で話した autoresearch — エージェントが自分でリサーチ資料を探し、新しい知識を消化して、自分の行動戦略を更新するという研究方向。これは産業界ではまだ「完全に閉じた問題」ではありません。デモは幾つも出てきましたが、実務レベルの検証は薄いです。

上の一行の紹介文は、この二つを同じもののように使っています。「OMX に autoresearch という名前のコマンドがある」と「OMX が autoresearch という研究方向を実務で閉じた」は 全く別の主張 です。前者は表面の名前、後者は実質の達成です。

この違いを感覚的に感じるには、こんな比喩が役立ちます。カフェに行ってメニューに「本場イタリア式エスプレソ」と書いてあるとしましょう。そのカフェに 本物のイタリア人バリスタ がいるかもしれないし、メニュー名だけそうついているだけかもしれません。メニュー名と実際の品質は別の層です。この二つの層を分けて見る習慣が、ツール評価の基本です。

もう一つ。ツールを作る側が名前をそう付けることは 全く悪いことではありません。autoresearch というキーワードは産業の流れの方向を指す言葉で、製品がその方向を狙っているという宣言としては妥当です。問題は、その宣言を 読む側 が宣言と達成を混同したときに生まれます。この記事はその混同を予防するための記事です。

このフレームを敷いておいて、ここからツール自体を分解していきます。

2. OMX を短く分解 — 何を追加しているか

OMX は OpenAI Codex の上に乗せるツールキットです。Codex が実行エンジンだとすると、OMX はそのエンジンの上に作業環境を厚く敷いてくれる層です。

公式 wiki 文書ベースで整理すると、OMX が追加するのは5つの面です。

• setup 面 — omx setup 一つでプロジェクトに .codex/prompts、.codex/skills、.codex/agents、.codex/config.toml、.codex/hooks.json、ルートの AGENTS.md、.gitignore まで一気に敷かれます。Codex がプロジェクトでどんなルールで動くかをファイルで固定するインストーラの役割です。
• state 面 — .omx/ の下にセッション状態、モード、ロック、原子的書き込みログを残します。セッションが切れても「このプロジェクトがいまどの段階にあるか」がディスクに残ります。
• hooks 面 — SessionStart、PreToolUse、PostToolUse、UserPromptSubmit、Stop のような Codex native hook にコマンドを刺しておきます。人が毎回覚えなくてもフックがルールを強制します。
• HUD / doctor / operator surface 面 — omx hud --watch、omx doctor、omx status、omx state list-active。いまこのプロジェクトに何が掛かっているかを運営者が直接読める計器盤が付きます。
• team runtime 面 — omx team ベースの tmux / worktree coordination。複数タスクを並列で回す分業構造が設計されています。

そして、議論の核になる表面がもう一つあります。

• autoresearch 面 — omx autoresearch という CLI コマンドが実際に存在します。名前だけ見ると M6 の「自習エージェント」をすぐ思い浮かべる、あの表面です。

ここで大事な問いが出てきます。この名札の中で実際に何が動いているのか? 次のセクションがその話です。

3. OMX の実際の位置 — runtime overlay、それ以上ではまだない

wiki が OMX について何を判断したかを要約してみます。この部分は 感想ではなく一次検証結果 に基づく話なので、できるだけ原文の表現に近く移しておきます。

wiki の oh-my-codex エンティティと oh-my-codex-runtime-architecture シノプシスを一緒に読むと、こういう判断が出てきます。

first-party で確認されたもの:

• repo clone / dependency install / build が現時点で成功する。
• setup、hooks、HUD、state server、mode-aware runtime、team decomposition 関連の targeted test 33個 が通った。
• clean sandbox で omx setup --scope project --force が実際に .codex/、.omx/、AGENTS.md、hooks、MCP config を生成した。
• 同じ sandbox で omx doctor が 11 passed, 1 warning, 0 failed で閉じて、status / state list-active / hud / reasoning 面も実際に応答した。

ここまでは固いです。「OMX は Codex の上に setup/state/hook オーバーレイを敷く installer + runtime layer だ」 という文章は、README の感想ではなくコードパスとテストを根拠に防御可能な主張です。

逆に まだ検証されていないこと も wiki が明示しています。

• live omx team tmux / worktree runtime の実戦での安定性。
• long-running task での state carry-over の利益が plain Codex に対して反復的に確認されたか。
• いまの shell / auth 環境で omx exec が最後まで閉じるか(今回の検証では 401 Unauthorized で止まりました)。
• same-task side-by-side で OMX lane が manual lane より回復コストを反復的に下げるか。

最後の項目が特に大事です。same-task 比較で決定的に効いた restart aid は OMX 固有 surface ではなく、TASK.md + HANDOFF.md のような explicit local intent capture でした。これは OMX をこき下ろす話ではなく、「小さな bounded task では manual lane と OMX lane の差が思ったより小さい」という観察です。wiki はこうした証拠を根拠に、いま OMX に adopt-partial という判定を下しています。メイン wiki に全面導入ではなく、新規の長期プロジェクトや別の greenfield repo で制限的に再検証する方向が正しい、ということです。

だから「OMX が autoresearch を実装した」に戻ると、こう整理されます。autoresearch という名前の 表面 はあります。その表面が M6 で言った 自習エージェントを実際に閉じた かというと、いまの wiki 根拠では言いにくいです。wiki が確認した OMX の本体は runtime overlay + project-scoped state visibility 側です。この二つは別の層です。

一文で座標を打つとこうです。OMX は Codex セッションを、状態と運用ルールが残る作業システムに変えるオーバーレイだ。 この文章が正しいサイズの文章です。それより一段上に上がった「自己改善 AI」という文章は、現在の証拠の前では一コマ踏み越えていることになります。

4. OMC を短く分解 — 何を追加しているか

同じ作者が Claude Code 側に作った対応レイヤーが OMC です。Claude Code を基本作業面に置いて、その上に運用ルールと分業方法をかぶせる構造です。

公式 wiki ベースで整理すると、OMC が追加する面はこう分かれます。

• インストールと識別 面 — plugin marketplace install 経路 + npm / runtime 経路を一緒に持ちます。ただし注意点が一つあります。repo / brand 名は oh-my-claudecode ですが、実際の npm package identity は oh-my-claude-sisyphus です。インストール文書でこの差を書かないと運用混乱が起きます。
• セッションコマンド 面 — /autopilot、/team、/pipeline、/ralph のような in-session orchestration skill があります。Claude Code 一セッションの中で作業方式を固定する側です。
• 外部チームランタイム 面 — src/cli/team.ts が別の job record、worker identity guard、pane artifact、team state root を持ちます。大事なのは /team と omc team が 同じ名前の一つの機能ではない ということです。一つはセッション内、一つは tmux 中心の外部ランタイム。
• アーティファクト / 記憶 面 — .omc/prompts/ の下に prompt、response、metadata が溜まります。作業の痕跡を再度読み直せるシステム側に近い構造です。
• 運用可視性 面 — HUD、wait、session search、teleport、config のような表面。モデル性能を上げる機能ではなく、人が runtime を扱いやすくする機能たちです。

wiki 検証で確認された事実も付けておきます。

• repo clone / dependency install / build 成功。
• team runtime boundary、team CLI、prompt persistence、artifact convergence 関連 targeted test 26個 通過。
• isolated CLAUDE_CONFIG_DIR に実際にインストール可能で、結果として hooks/、skills/、agents/、hud/omc-hud.mjs、settings.json、CLAUDE.md が config space に生成された。
• settings.json に UserPromptSubmit、SessionStart、PreToolUse、PostToolUse、PostToolUseFailure、Stop hook と statusLine が実際に入った。
• 生成された CLAUDE.md は単なる README ではなく、上位 operating contract の役割だった。

ここまで見ると OMC も 「Claude home / config 表面を再構成するインストールオーバーレイ」 という主張は防御できます。問題はその次の層です。

5. OMC の実際の位置 — orchestration / runtime が強み、self-improvement は弱い

OMC 公式の表面にはこういう文言が掛かっています。3-5x faster、30-50% token savings。初めて見るとそそられますね。でも wiki はこの数字を 独立検証が必要な claim として分類しました。ベンチマーク出典が抜けていたり、テスト条件が明示されていないからです。この数字をそのまま引用して「OMC を使えば3倍速くなる」と移すと、一次証拠なしにマーケティング文言を運ぶことになります。

もう一つの誤読軸が「OMC は Meta-Harness 製品だ」という文章です。M7 で話した Meta-Harness の核心は ハーネスそのものを自動で探索 / 更新 / 最適化 するシステムでした。複数のハーネス候補を回して、成功率を測って、より良く動作したハーネスに入れ替えるループ。これは研究側でもまだ難しい問題です。

OMC がやっていることは、それと 関連はあるけれど同じ層ではありません。OMC は「良いハーネス一式(plugin install + in-session skill + team runtime + prompt persistence + hook set)をプロジェクトに固定して敷いてくれる」側です。ハーネスを 運用 する側に近いです。ハーネスを 探索 する側はまだです。

二つがなぜ区別されるべきかをもう少し解きます。比喩で言うとこうです。Meta-Harness は「メニューそのものを毎日実験して、お客さん満足度が一番高い組み合わせを探すシェフ」です。OMC は「すでに検証されたメニューセットを店ごとに同じ品質で敷いてくれるフランチャイズ本部」に近いです。両方とも外食業の大事な役割ですが、やっていることが違います。前者は実験、後者は標準化です。

OMC の実際の強みを正直に表現するとこうです。

• orchestration layer として強い。 役割分担、段階パイプライン、チームランタイムがコードとテストのレベルで存在する。
• prompt persistence で記憶表面がある。 セッション間のアーティファクト照会が可能な構造。
• config space を再構成する installer として厚い。 CLAUDE.md が単なる説明書ではなく、上位 contract として動く形で敷かれる。

弱い側も正直に書くとこうです。

• live tmux team runtime の実際の運用摩擦は未検証。
• plugin-first インストールが環境ごとにどれくらい滑らかかは未検証。
• base Claude Code に対する反復的な生産性優位は未確認。
• self-improving loop の証拠なし。ハーネス自動探索は現在の表面にない。

一行で座標を打つと、OMC は Claude Code セッション・外部チームランタイム・アーティファクトストレージを一つの運用層に束ねる構造 です。これ以上引っ張って「自己改善 Claude プラグイン」と呼ぶと、現在の wiki 根拠基準では誇張です。

6. 哲学 vs 実務対応物の距離 — 一枚表

学習地図を辿ってきた方は、M6 と M7 で 研究方向 と 実際の製品 を区別する練習をしました。その結果を一枚表に押さえてみます。

概念(学習地図の軸)	位置	対応実務面	対応深さ
autoresearch(研究方向、M6)	エージェントがリサーチを自分で回して知識・戦略を自ら更新するループ。産業界未定。	OMX の autoresearch CLI コマンド	名前レベル。CLI 面はあるが実戦検証は未完。
Meta-Harness(研究方向、M7)	ハーネスそのものを自動探索・最適化するシステム。研究フロンティア。	OMC の orchestration / runtime layer	関連はあるが別の層。ハーネスを固定・配布・運用する層まで。探索・最適化ループではない。
Retrieval Layer(M1) / RAG(M2)	長いコンテキストを外部記憶で補完する構造。	OMX の .omx/ state、OMC の .omc/prompts/	全面的な RAG ではなく、運営者可視性 + セッション間アーティファクト保存側。
Harness(M5)	agent を囲む道具・ルール・ループの外衣。	OMX setup、OMC CLAUDE.md / hooks	直接的に当てはまる。両方ともハーネスをファイルで固定するインストールオーバーレイ。
Agent Ops Stack	base CLI の上に運用環境を乗せる流れ。	OMX + OMC 両方	代表的な実務事例。競争軸が Codex vs Claude Code ではなく、各 CLI の上にどんな運用環境を乗せるか に移った証拠。

この表で一番大事なのは autoresearch 行 と Meta-Harness 行 です。両行とも「対応深さ」が「名前レベル」または「関連はあるが別の層」と書いてあります。このマスの言葉が正確にこのサイズで捉えられていると、実務判断がブレません。

7. なぜこの距離測定が実務者に大事なのか

距離測定がなぜ必要なのか、理由を少し解きます。三つの場面で直接的に差が出ます。

一つ目、製品評価の場面。 チームに導入を検討するときに「自己改善 AI エージェント」を期待して OMX/OMC を敷くと、このツールが 勝手に人の助けなしに知識を更新してハーネスを改善 してくれると期待することになります。実際にはそうではありません。導入後に数週間たってもエージェントが「もっと賢くなる」感覚が来ないと、導入自体に失望します。失望は諦めにつながり、諦めるプロセスで、すでにインストールされた .codex/、.omx/、CLAUDE.md、hooks をどう片付けるかといった運用負債が残ります。最初から「このツールは runtime overlay だ」で期待をセットアップ すれば、こういう失望・諦め・運用負債のサイクルが生まれません。

二つ目、ニュース解釈の場面。 これから「OMX が autoresearch ベンチマークで X 点を出した」「OMC が Meta-Harness を実装した最初の Claude Code wrapper だ」といった文言が出続けるかもしれません。この文言をそのまま信じて記事化 / リツイート / 社内共有をすると、証拠のないマーケティング文言が実務知識のように広がる ことが起きます。wiki が確認した境界の中に留まる習慣があれば、同じ文言を見ても「そのベンチマークはどんなタスクセットで出たのか」「ハーネス自動探索ループが本当に回っているのか」といった問いをすぐ投げられます。これが実務者の防衛線です。

三つ目、導入後の失敗解釈の場面。 OMX/OMC を敷いたけれど期待ほどの効果が出なかったとき、原因をどこに帰すかが分かれます。「自己改善 AI」として読んで導入したなら「このツールは詐欺だ」に帰結しがちです。一方、「runtime overlay」として読んで導入したなら「うちのチームがハーネス自体を十分に磨いていなかったんだ」「workflow overlay が一番効果的な長期作業コンテキストに、うちの作業が合わなかったんだ」といった 正確な振り返り が可能になります。結果が悪くても学びが残ります。

まとめると、距離測定は 期待を管理し、ニュースを濾し、失敗を解釈する 三つの場面で直接お金を節約してくれる実務スキルです。

8. 「じゃあ OMX / OMC は使いものにならないのか?」— いや、強みは明確だ

ここまで「autoresearch でもなく Meta-Harness でもない」を繰り返したので、こういう印象が残るかもしれません。「じゃあこのツールは過剰マーケティングで、使う必要がないってことか?」違います。実際に違う読み方をすると、OMX と OMC の価値は明確で具体的です。視点を変えるだけで良いのです。「自己改善」の代わりに「運用可能な作業面の厚さ」として見る視点 です。

少し解いてみます。

Codex や Claude Code を一ヶ月くらい使った方がよくぶつかる壁があります。

• セッションが切れると、どこまでやったか思い出すのに時間がかかる。
• プロジェクトごとにルールが違うのに、同じ指示を毎回また書く。
• チームメイト二人が同じ repo で回すと、hook や config が互いに上書きする。
• agent がミスした後の復旧コストが大きすぎて、結局人が最初から組み直す。

この四つは「AI がもっと賢くなれば解ける問題」ではありません。「作業環境がもっと厚くなれば解ける問題」 です。そしてこれこそが OMX / OMC が狙う位置です。

具体的には:

• project-scoped state visibility. OMX の .omx/ はセッションが切れても「いまどの段階か」がディスクに残る構造です。HUD で状態がすぐ読めます。再開コストが減ります。同じ文脈で OMC の .omc/prompts/ は過去のセッションがどこで止まったか、どのプロンプトが効いたかを痕跡として残します。
• workflow overlay. OMX の canonical session path (deep-interview → ralplan → ralph / team) や OMC の autopilot / pipeline / ralph / team のような skill は「毎回最初から考えるプロンプト」を減らしてくれます。作業方式自体がファイルで固定されているからです。
• team coordination. 一人で使うツールではなく、チームが同じルールセットで働けるようにする仕掛けがあります。AGENTS.md、CLAUDE.md、hook が repo に埋め込まれると、新メンバーも同じ契約を自動で引き継ぎます。
• operator visibility. omx doctor、omx hud --watch、OMC の status line — いま自分の環境で何が掛かって何が壊れているかを、人がすぐ読めるようにしてくれます。これがないとデバッグが丸ごと人の頭の中に降りてきます。

「自己改善」ではなくこの四つで OMX / OMC の価値を表現すると、期待と実測がかみ合う 導入になります。この視点が核心です。

9. 実務導入判断 — あなたのチームがこれを使うべきか

「視点はわかった、うちのチームが使う価値があるか」という具体的な問いに降りていきます。抽象的な賛否ではなく 五つの問い で測るのが一番速いです。

問い1. いまやっている仕事が「bounded task に分けて manual handoff で回せる」サイズか?

小さな bounded task では TASK.md + HANDOFF.md のような明示的ローカル意図キャプチャだけで大半が解決します。wiki の same-task side-by-side ケースもこれを示しました。OMX / OMC の厚いインストール表面はこの規模では過剰かもしれません。答えが「はい、bounded で短い」なら 当面導入保留 が合理的です。

問い2. 同じプロジェクトで「一週間以上続く multi-session 作業」があるか?

セッションが切れては続く作業が多いほど、state 表面の価値が大きくなります。昨日どこまでやったかを再構成するのに毎回15分かかるなら、一年換算でかなりのコストです。このコストが感じられるなら OMX / OMC を試す価値が出てきます。

問い3. チーム協業が必要で、二人以上が同じ repo で agent を回すか?

一人で使う環境ではインストール表面が薄いほど良く、チーム環境では 共有される契約がファイルで埋め込まれている べきで、そうしないと協業がもたないです。OMX の AGENTS.md + hooks や OMC の CLAUDE.md + settings.json はこの契約を repo に固定してくれます。答えが「はい、チームで回る」なら価値が大きくなります。

問い4. plugin / npm / tmux のようなランタイム環境をチームが実際に扱えるか?

厚いオーバーレイを敷いておくと、それを運用することも新しい責任になります。package identity の混乱(oh-my-claudecode と oh-my-claude-sisyphus)、plugin path と npm path の分離、tmux 環境の準備 — こういうのをチームが扱えないといけません。これを扱う余力のないチームが無理に導入すると、「道具が別の保守コスト」になります。

問い5. うちのチームは「自己改善 AI」を期待しているか、それとも「運用可能な作業面の厚さ」を期待しているか?

これが一番決定的です。前の四つの問いに全部「はい」でも、チームが期待しているのが前者なら導入後の失望が早いです。期待をセットアップするのが先です。この一文を導入前の会議録にそのまま書いておくことをお勧めします。「私たちが買うのは自己改善 AI ではなく、セッション・チーム・状態が残る作業面だ。」

五つの問いを全部通るなら、OMX / OMC のうち チームの base CLI に合う方 を選んで sandbox で一度回してみれば良いです。Codex が base なら OMX、Claude Code が base なら OMC。両方使うチームはほとんどないはずです。二つの base CLI を同時に運用すると、ハーネス軸が二つになって管理コストがぐっと上がります。

10. 期待が誇張されやすい3つのポイント

最後に、現場で一番よく食い違う期待ポイント三つをまとめておきます。この三つだけ先に知っておいても、導入判断のミスが減ります。

(a) 「autoresearch 面がある」=「autoresearch が実装された」と読むミス。

先に1章で敷いたそのミスです。CLI コマンド名に autoresearch があるからといって、エージェントが一人で知識・戦略を更新するループが閉じたという意味ではありません。名前は宣言、実質は証拠 という感覚を保ち続けないといけません。いま動いている実証は state と workflow の表面まで。

(b) 「runtime overlay を敷いた」=「生産性向上が自動保証される」と読むミス。

オーバーレイは 「働く面」を敷いてくれる ものであって、「仕事を代わりにやってくれる」 ものではありません。インストール後に生産性が上がるには、チームがその作業面の上で実際に習慣を変えないといけません。hook が敷かれてもだれも期待を更新しないなら、hook は回るだけで人の頭は前のまま回ります。生産性向上は オーバーレイ × 人の habit change の積です。片方が0なら全体が0です。

(c) 「orchestration layer を提供する」=「Meta-Harness だ」と読むミス。

M7 で話した Meta-Harness の本質は ハーネスを自動で探索し更新するループ です。OMX / OMC が提供する orchestration layer は よく選ばれたハーネス一式を固定して配布 してくれる側です。同じ「ハーネス」という単語が付きますが動詞が違います。前者は evolve、後者は standardize / deploy です。同じ名詞で二つの層を一括りにすると、製品評価が絡まります。

この三つのミスを避けるだけでも、導入判断の精度はかなり上がります。

11. こうしたツールを評価するときに付けるべきチェックリスト

OMX / OMC だけでなく、これからも「Codex の上の何か」「Claude Code の上の何か」「新しい self-improving agent」のような名前でツールが出続けるはずです。毎回同じミスを繰り返さないためにはチェックリストが必要です。wiki の評価軸をそのまま持ってくるとこういう項目です。

• same-task recovery cost. 同じ作業を manual lane とこのツール lane で二回回したとき、セッションが切れた後の再開コストが実際に低くなるか?
• handoff quality. 人 → 人、人 → ツール、ツール → 人 に渡すときにコンテキスト損失が減るか? ログだけ増えるのは handoff quality ではない。
• explicit local intent capture. このツールなしで TASK.md + HANDOFF.md だけでもうまくいく部分はどこまでか? このツールがそこに追加してくれるのは何か?
• operator visibility. いまこのプロジェクトに何が掛かっているか、何が壊れているかを人が 一画面 で読めるか?
• package identity. repo 名 / brand 名 / npm package 名がどこでどう分かれるか? この差をインストール文書が正確に扱っているか?
• claim の出典. 3x faster、50% token savings のような数字がどのタスク、どのモデル、どの条件で測った値か? 出典がなければ数値は0として扱う。
• first-party 検証可能性. 自分でこの repo を clone して install / build / targeted test を回して再現できるか?
• adopt 判定. wiki の観点でこのツールが adopt、adopt-partial、trial、hold、avoid のどこにあるか? adopt-partial ならどの条件で adopt に上がるか?

チェックリストが多く見えますが、実際にはツールを三回くらい評価すると身についてきます。その後は新しいツールを見たとき、自動的にこの問いが頭の中で回ります。この感覚が実務者一人の 一番安い AI 防衛線 です。

12. M9 / M10 予告 — いよいよ自分で答える準備ができた

ここまで辿ってこられた状態なら、M9 と M10 に進む準備がほぼできています。

M9 は 「RAG は死んだのか」 という問いです。Long-context モデルが大きくなるにつれ「RAG は要らない」というツイートが繰り返されていますが、実務ではどこまで正しくて、どこから間違っているかを整理します。ここまで来られた方は Retrieval Layer / RAG / autoresearch をすでに区別できていて、いま学んだ OMX / OMC という 実際のツール基準の runtime overlay 感覚 までお持ちなので、「long-context だけで本当に終わりなのか」という問いに自分の言葉で答えられる状態です。

M10 は 「Meta-Harness は実務的に何か」 です。M7 で概念をつかみ、今回の M8 で「OMC は Meta-Harness ではない」という座標を打ったので、次は実務者の手に掴める Meta-Harness が どんな形で登場する可能性があるのか、そして 今日、実務者が先に準備できる habit は何か を話します。

二つの記事とも、今回の M8 の感覚 — 研究方向と実務表面を同じ単語で一括りにしない 習慣 — の上で回ります。ここまで来られた時間が、次の二つの記事ですぐ効果を発揮します。

---

一行で締め: OMX と OMC は自己改善 AI ではなく、base CLI の上に状態・運用ルール・チーム分業を敷いてくれる runtime overlay です。autoresearch という名前と orchestration layer という表現を、それぞれ M6 の autoresearch、M7 の Meta-Harness と同じものとして読むと、現在の証拠基準では一コマずつ踏み越えます。この距離さえ正しく測れれば、実務判断はブレません。

---

FAQ

Q1. OMX / OMC はいますぐ導入しても良いですか?

条件付きで「はい」です。五つの問い — bounded task がメインではないか、multi-session 作業があるか、チーム協業が必要か、ランタイムを扱えるか、期待を「runtime overlay」にセットアップしたか — に全部「はい」なら、sandbox 検証の後に導入を始めてみる価値があります。一つ二つだけ「はい」なら、TASK.md + HANDOFF.md のような軽量 local intent capture で先に解決するかをまず見てください。wiki 判定は現在 adopt-partial で、この判定は「みんなに無条件で使え」ではなく「特定の条件で制限的に試す価値がある」という意味です。

Q2. 「autoresearch」コマンドが名前だけなら、これから変わる可能性はありますか?

十分あります。repo が更新され続けていて、名前の付いた面の下に実質が埋まっていく可能性もあります。wiki も thesis_last_checked、recheck_trigger のようなフィールドで 再検証時点 を明示しています。ただし「いま時点の証拠」では名前レベルに近い、というのが正確な表現です。6ヶ月後に同じ問いを投げ直す必要があります。私もこのシリーズがまとまる頃に再度チェックして、変動があれば追記するつもりです。

Q3. OMX と OMC のうち一つだけ選ぶなら、何を基準にしますか?

チームが base として使う CLI が決定権です。Codex がメインなら OMX、Claude Code がメインなら OMC。二つの CLI を半々に使うチームは思ったより稀です。そして「両方敷いて比べてみよう」というアプローチはコストが大きいので勧めません。それぞれが敷かれながら config space が二回重なり、チームメンバーごとにどちらをデフォルトで使うか覚えておかないといけなくなります。決定を一方に下して、反対側は学習用に文書だけ読んでおくのが、実務コストが安いです。

---

ニュースレターのご案内

毎週月曜日の朝に、AI・LLM・エージェント関連の実務整理を一通お届けしています。OMX / OMC のようなツールが更新されるとき「今回の変化が学習地図のどの座標を揺らすか」を一緒に測る内容もよく扱います。こうした整理を腰を据えて積み上げていきたい方は、ぜひ ニュースレター登録(無料・30秒) からどうぞ。

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。