Claude CodeとOh My OpenAgentの紹介
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業課の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあよろしくお願いします。
よろしくお願いします。
はい、じゃあ今日は、Claude Codeですね。
ちょっとフェーブルで、前回かなり良かったって言ったけど、停止されちゃって、かなり喪失感を感じている中ですけれども、
とはいえ、Claude Code、実はOpus 4.8になってから、僕結構使ってたんですよ。
世間的には、すごくモクモク垂れまくられてるって感じなんですけど、
最近ちょっと微妙な時もあるけど、とはいえ、僕的には今までのClaudeの中では結構良いなって思っていて、
で、フェーブルが出る直前ぐらいに、めちゃめちゃナーフされた感があったんですよ。
前日かな、みたいな感じがあったんですけれども、とはいえ今Claude Codeをメインに使ってると。
最近ちょっとオープンコードはお休みしてて、ちょっとGLM 5.2が結構話題なんで、
オープンコードでGLM 5.2使おうかなとは思ってるんですけれども、なんでじゃあClaudeCodeを使ってるかってところなんですけど、
阿部ちゃんがね、良いものを作ってくれたんですよね。すごく良いものを。
それが結構思ったよりワークしていて、まずそもそもどういう風に作られてるのかみたいなところとかの話も聞けたらなと思って。
俺一切知らんからさ。
なので、その辺の話ができたらいいのかなって思ってます。
Oh My OpenAgentの仕組みとClaude Codeへの応用
で、じゃあ何ができてるのかっていう話は俺の方からしようかな。このまま流れで。
Claude Codeって普通Claudeを動かすんですけれども、そのサブエージェントとしてコーデックスとかを呼び出せるように。
それはプラグインで普通にあるっていうんですけど、僕たちね、オープンコードを使うときは、
オープンコードにオーマイオープンエージェントっていう、いわゆるオーケストレーションの仕組みっていうのかな。
CCUPOSとかAtlasとか、前回もちょっと話したんですけれども、役割を持ったエージェントを呼び出しながら、
やることに応じてエージェントを切り替えてとか、サブエージェントもレビュー用のエージェントがいたりとか、
計画を立てるためのエージェントがいたりとか、みたいなものを呼び出しながら進めていくっていうことで、
オープンコードの場合はエージェントそれぞれを別のモデルを割り当てて、
より適したモデルを適したエージェントにタスクによって振り分けていくみたいな仕組みを作ることによって、
全部が全部高価なモデルじゃなくても、なかなかいい動きするよね、みたいな。
いい仕組みがあったからこそ、僕たちDeepSeek V4 Proをメインに使いながらも、レビューの指摘であったりとかっていう、
結構クリティカルに効く部分で、GPTモデルを呼び出して、
品質を保ちながらも、早く安く開発を進めるっていうところをやってきた。
その仕組みを、阿部ちゃんがクロードコード上でもできるようにしてくれたっていうのがあって、
簡単に言うとクロードコードで、CCUPOSとかAtlasとかっていう、そういう仕組みを導入されてて、
オラクルとかレビュア用のとかになると、GPTモデルコーデックスがプラグインに呼び出されるみたいな感じの仕組みを。
これが結構うまく動いてて、もともとオープンコードとオーマイオープンエージェントの仕組みで、
OMOって言うけど、オーマイオープンエージェントのこと。
OMOの作者がね、クロードがオープンコード上で使えなくなって、一瞬病んでたやんか。
めちゃくちゃ病んでた。やる気もせいばっかりしてたみたいな。
オーケストレーターとしてクロードモデルが一番優秀で、それを前提としてOMOが作られてたのに、
クロードモデルが一切使えなくなったみたいな、オープンコード上でみたいなのがあって、
そういう経緯もあったから、オーケストレーターはクロードがいいよねっていうような前提があって、
今だとGM5.2もいいよねとか、100万トークンコンテキスト使えるようになったからとかあるけど、
そういう前提があったんで、結構このクロード×GPTのOMO的なオーケストレーションの動きはめちゃくちゃハマっててですね、
感謝してますよ、かなり。
Claude Codeでのオーケストレーション再現の課題と解決策
良かったですね。こんなにハマると思ってなかった。僕もフェイブルが来たタイミングだって、
クロードを久しぶりに使い始めて、やっぱりサブエージェントの呼び出しとか、検証とかをGPTにやらせたいとか、
オープンコードでオーマイオープンエージェントを使ってた時の感じをクロードでどうやったら再現できるのかなって考えた結果、
そのまま引っ張ってきたらいいやっていうので、それこそフェイブルにやらせたんですよ、整理とか。
なので、とりあえずやってみたみたいな感じだったので、そんなにワークするかなってちょっと不安だったんですけど、
僕も結構満足していて、ヤマチャンも満足しているってことは、結構いい作りにはなったのかなって思ってますよね。
うんうんうんうん。そうかもね。
いや、なんかね、ちゃんとOMOの動きをしてる。
良かった。
何だったら安いモデルをずっと使ってたからさ、よりちゃんと動いてくれるから、安心感もありつつっていう感じで。
あとフェイブルだった時は余計ね、例えば作業をフェイブルにやらせたらもったいないよねとかあったと思うから、
そういう意味でも、ちゃんとオーケストレーションしながらいろんなエージェント、モデルを使うっていうのは大事だったと思うんですけど、
それがなくなったとしても結構ワークしてて。
そうだね。
で、実際ちょっと中身のところ聞きたいんだけど、普通にクロードでサブエージェント作ってるみたいな感じってこと?
基本的にはサブエージェントとスラッシュコマンドをうまく組み合わせることで、もともとのオーマイオープンエージェントの仕組みを再現しているっていう感じなんですよ。
で、オーマイオープンエージェントってシシューポスとかアトラスっていうようなオーケストレーターを担うエージェントっていうものと、
それはユーザーがターミナルでオープンコードを実行した時に自由に切り替えれるエージェントなんですけど、
そのオーケストレーターのエージェントが呼び出すサブエージェントっていうのは、リブラリアンっていう調査系だったり、エクスプローラーっていう、これもまた調査系のものだったりするんですけど、
そういうサブエージェントっていうのがそれぞれ、これはユーザーが切り替えられない、オーケストレーターが呼び出すものとして定義されていて、
これをクロードコードで再現しようとすると、まずクロードコードの制約にまず衝突するんですけど、
オーケストレーターのエージェントはクロードコード上で自由に切り替えながら作業できない、セッション内で切り替えながら作業できないっていう制約があって、
例えばクロード--エージェントって起動するときにエージェントを指定すること自体はできるんですけど、それはもうセッションの中でこのエージェントでいくって固定化されてしまうので、
ちょっとそれは使いにくいかなって。僕とかだと大体調査させて、ある程度やりたいタスクについて、
コンテキストがエージェントに対して溜まった時点で、AIに対して溜まった時点で、プロメテウスっていう計画用のエージェントにスイッチして計画を立てさせるとかっていうのをやったりするんですけど、
そういうのがやるとやりにくいなっていうふうに思ってたんで、そこはスラッシュコマンドで、今エージェントはシシューポスとプロメテウスとヘファイストスとアトラスっていうのがあるんですけど、
全部それを独立したスラッシュコマンドで定義してあげて、切り替え可能、コンテキストとして注入できるようにしている感じですね。
それらが呼び出すサブエージェントに関しては、これはクロードコードのデフォルトの機能でサブエージェント定義ができて、
どういうツールを使わせるのか、どういうモデルを使うのかっていうところも含めて設定できるので、
そこはタスクの難易度に応じて軽いモデルとか重たいモデルを振り分けつつ、サブエージェントの定義をしているような感じです。
Codexの呼び出し方法とプラグインの活用
ちなみにコーデックスも呼び出すじゃん。
そうだね。
あれはどちらかというと、シシューポスとかアトラスのプロンプトの中に仕込まれているみたいな感じの、こういうときはコーデックスみたいな。
そうそう。コーデックスを呼びたいタイミングって、結構重要な考察をしてもらったり、検証してもらったりとか、計画の中身が大丈夫かなっていうのを確認してもらう。
オーマイオープンエージェント上でいうところのオラクルとか、そういう肝になるサブエージェントに使わせたいっていうのがあったんですけど、
これ実は最初、コーデックスのプラグインは使ってなくて、MCPで使うように最初してたんですよ。
はいはいはい。
で、MCPをやろうとすると、タイムアウトとか、そもそもうまく呼び出せないみたいな問題に、結構これ昔からそうなんですけどぶち当たって、
やっぱりMCPでクロードからコーデックス呼び出すのはダメだなって感じたんで、実は次、スキルを使ってたんですよ。
クロードからバッシュを叩いて、コーデックスCLIをスキルで呼び出すみたいな方法も結構やってる方もいて、そっちもやってみたんですけど、
次それは結構その中身を全部クロードが読み込んじゃって、このテキストがすごい無駄になってるなっていうところを見てて感じたので、このスキルも運用に乗らないなっていうふうに思って探してたところ、
オープンAIがコーデックスの純正としてクロード用のプラグインを提供していて、これが何がいいって、クロード的にはネイティブでサブエージェント呼んでるんですけど、
サブエージェントとしてコーデックスがCLIで走ってるみたいな感じになるんですよね。
なので、クロード的には割とネイティブで呼び出せて、かつコンテキストもサブエージェントとして呼び出してるんで、最後の結果だけだったり、どうなってるかっていうのもクロード側から聞きに行ったりっていう仕組みもちゃんと整えられていて、
かなり信用性が高いプラグインだったなっていうところがあって、オープンエージェントを模倣したサブエージェントの1個と複数の方をコーデックスに移情するときは、そういうプラグインを使って呼び出してくださいみたいな指示を出しているような感じで。
かなり良い感じよね。
だいぶワークフローとして、クロードコードも元々かなり心持たないなっていう感覚はあったけど、やっぱオープンコードは多分いろんなモデルを変わる変わる使える。
だからよりコスパを良くしようとしたときかなり効く感じだと思うけど、クロードとコーデックスの進み分けで、
ニーアカウントでユーセージがウィークリミットが枯渇しないぐらいの利用の人だったら、クロードとコーデックスのニーアカウントを使いながら回すのが最大パフォーマンスを出す。
だからオーマイオープンエージェントの仕組みがかなり優秀やったんだなっていうふうに。
エージェント分割の考え方とAMPコードの影響
僕も感じるのは、サブエージェントを作ろうとしたときに最初僕やってたのはフロントエンドエンジニアとかデザイナーとかサーバーサイドエンジニアみたいなサブエージェントの分け方をしてたんですけど、
結局それってタスクが微妙に被ったりとか結構サブエージェントの切り方も難しいなとかって思ってることがあったんですけど、
それをどっちかっていうとオーマイオープンエージェントは何をさせるかというか、どういう作業性質を持ってるのかっていう単位でエージェントを切り分けていて、
それをすることで汎用的にどういうタスクでも受け入れできるような器としてあるなっていうふうに感じるんで、
結構オーマイオープンエージェントのサブエージェントとかエージェント自体の切り方っていうのはすごい秀逸だったんだなって感じてたんで、
これがクロードコードとかにも適応できたのが結構嬉しいですよね。
かなりいいよね。確かオーマイオープンエージェント自体も何だったっけ、何かのサービスがあって、それにインスパイアされてるよね。
オーマイなんとかみたいなの?
いや、オーマイなんとかではなくて、どっかに書いてたんやけど、オーマイオープンエージェントのドキュメントに書いてたんですよ。
これだ、AMPコード。AMPコード。AMPコードとクロードコードからかなり影響を受けてるっていうふうにドキュメントのリードミーにも書いてて、
このAMPコードっていうのはオーマイオープンコードプラスオーマイオープンエージェントの組み合わせ、
ユーザーに割とモデル何にするかみたいなのを委ねてるじゃん。
じゃなくて、このAMPコード側でこのモデルはこれみたいな。確かガチっと決めてるって感じ。
だからエージェントモードっていうのはDeep、Smart、Rushみたいなのがあって、
DeepはGPT5.5だしSmartは4.8だしみたいな。
サブエージェントでもOracleとかLibrarianとかReadThreadとかいろいろあんねんけど、
それもどれかっていうのがもうすでに固定化してるらしい、サービス側で。
あーそうなんだ。
そうそうそうそう。っていうのがあって、なかなか面白いなと思って。
だからそれのこの仕組みがすごくいいなってなった上で、そこにインスパイアされて、
オープンコード上でできるものっていうのを作っていくみたいな思想に至ったらしいね。
あーそうなんだね。
だけどなんか面白いのを見つけてしまった。
前オープンエージェントが個人プロジェクトでLLMトークン代として360万を使い果たしました。
あらゆるクールを試し徹底をいじり倒しました。結果オープンコードの勝ちでした。
これを多分なんかやろうとするにあたって何がいいのかみたいな。
まあいろいろあるもんね。
エージェントハーネス。
Pコードみたいな。
Piとかいろいろあるもんね。
そういうのをいろいろ試したんだもんね。
みたいなことが一応背景としてあるんですね。
Oh My OpenAgentの進化と今後の展望
素晴らしい。確かに業務ごとに切っちゃうと汎用性がなくなるもんね。
例えばリファクタリングとかリサーチみたいな。
リサーチぐらいはいいけど。
だけどもうちょっと抽象度を上げて。
だからこそあれなんでしょうね。
はじめアトラスとかCCUポストとかなんで神の名前とかそういうのにしてんだろうって思ってたけど。
カテゴリーで固定化できなかった結果なんでしょうね。
作業カテゴリーじゃ終われないから作らないといけなかったみたいな。
性質で覚えてもらうしかないみたいな。
なんかそうなのかなって。
だからそこが体感として理解した結果、あの命名とかがなんとなく腹落ちするみたいな。
そうだね。
あと最近だとお前オープンエージェントでチームモードが出たりね。
最近って言っても結構早いけど。
まあまあなんかちょっとずつはどんどん進化していって。
あと最近ね、RAZY CODEXか。
出ましたね。
OMO4 CODEXが登場しました。
これも使ってみようかなと思ったんだけど。
結局なんかオーケストレーターはクロードにやらせるとやっぱりなんやかんやいいんだなみたいなのを使ってて。
最近感じていて。
そうなると。
たぶん皆さん聞いてる人の中でもやってる人はいると思うんですけど。
やっぱクロードにオーケストレートさせてCODEXにデビューとか実装を実際にやってもらうみたいな細かいところを作業してもらうみたいなところがあると思うので。
なんか今だとそれこそTMAXを使って、TMAXのスクリプト経由でAI同士がCODEXとクロード同士が会話してもらうって試みをしてる人だったりとか。
MCPとかスキル使ってって人が結構いると思うんですけど。
結構僕の中の発見はやっぱりこのCODEXの純粋なプラグインがかなり使えるっていうところで。
なんかこの座組みは結構、このオーマイオープンエージェントっぽいやり方じゃなかったとしても試してほしいなって思いますね。
あとあれだね、このオーマイオープンエージェントもマルチハーネスエージェントOSっていう形にリファクタリング進行中らしくて。
オープンコードだけじゃなくてCODEXとかPiとか、いろんな複数エージェントハーネスをサポートしようとしてるっぽいね。
なんかしてる。
ノートマップも開かれてる。
これからどうなるんですかね。
すごいなと思って、複数のハーネスをどうやって束ねていくんだろうみたいなのがあんまりイメージは入ってなかったかな。
どうやって進めるのかなみたいな気になってた。
どっちかというとハーネスをまたぐみたいな話じゃなくて、サポートするっていうところなのかなって思った。
だから今回のクロードコードにOMOの仕組みを導入したみたいなと同じの。
そういうのやっていくのか。
っていう意味合いなのかなと思いました。
まとめとリスナーへのメッセージ
そんな感じで、今日はいい仕組みを作ってくれてありがとうございましたということで。
それの共有となりました。
ありがとうございます。
ありがとうございます。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。
今回はですね、クロードコードでオーマイオープンエージェント的なオーケストレーションをやってもらうというところで、
すごく効果実感があったので、そちらについて共有となりました。
ちょっとリポジトリで共有とかそういうのはできないんですけれども、
同じような思想をクロードとかに相談してみてもらって、
仕組みを作るっていうのも一つの手なのかなと思うので、
もしトライしてみようと思った方がいたら挑戦してみてください。
こんな感じでいつもAI駆動開発についてのいろいろな話をしているので、
もしこのポッドキャストが気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。
それではまた次回もお楽しみください。
バイバイ。
