ワークフローからスキルベースへの移行の背景
こんにちは、AI駆動開発部の日常へようこそ。 このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、
AI駆動開発のリアルを緩く語り合う番組です。 はい、じゃあよろしくお願いします。
はい、よろしくお願いします。 はい、じゃあちょっと前回、前々回と続いて、Orcaっていうターミナルアプリについて話して、
そのOrcaの設置面を使って、自作アプリで今開発こういうふうにしてます、みたいな話をしたんですけれども、
今回は少し経路が違うというか、どっちかというとAIワークフローとか、エージェントハーネス的な話になるかなというふうに思いますので、よろしくお願いいたします。
はい。
はい、具体的にちょっとどういう話したいかみたいなところなんですけれども、
もともとね、このポッドキャストの編集ワークフローをマストラで作ってたんですよ。
で、それを
ワークフローじゃなくて、スキルベースに変えたっていうのが近いのかな。
どっちかというと、何て言う、ちょっと言葉の定義が難しいんだけど、ハーネスアーキテクチャっていうのが近いのかな。
えー、あ、そうなんだ。
そんな感じに変わったってこと?
そう、なんて言うんだろう、多分ちょっと俺もちゃんと全体像を理解できてるわけじゃないんだけど、
マストラって、マストラも今は多分、スーパーワイザーエージェントが色々動的に考えながらサブエージェントを呼び出したりとかするみたいな、
ハーネスアーキテクチャに変わっていって、変わっていってというかそういう機能も用意されていて、一方でプログラムでどっちかというとワークフローをある程度決定論的に動くワークフローの中で
LLMが判断だけやっていくみたいなものが元々マストラのやつだったかなと思っていて、それをAIワークフローと捉えたときに、
AIワークフローってやるんじゃなくて、ワークフローを組むんじゃなくて、なんかそのハーネスアーキテクチャみたいな感じの、いわゆるクロードコードがスキルを動かしてるみたいな、そういう感じのイメージに近いのかな。
クロードコードもまさにハーネスなんですけど、僕がハーネスアーキテクチャっていう言葉じゃなさそうって感じるのは、クロードコードを作ってるわけじゃない。
クロードコードのレイヤーを作ってるわけじゃなくて、AIワークフローのレイヤーを作ってるわけでもなくて、その間ぐらいのものになる感じがあるんですけど、
だから基本的にはコーデックスCLIとかクロードコードとかオープンコードで、特定のある程度定義されたツールとかワークフローっぽいものとかを動かしながら、
AIが動的にそのツールとかを使いながら、ただスキルを作ったっていうにはちょっとスキルよりはちょっと幅は広そうだな、みたいなぐらいのところをやってるっていう感じなんだけど、
まあ、とりあえずマストラのAIワークフローを辞めましたっていう話ができたらいいかなっていうふうに思っていますっていう感じですかね。
まあでも何とか今聞いて、山ちゃんがワークフローでやってたことと、多分そのAIエージェントハーネスって呼ぶのかどうか悩んでるところについて、ちょっと話せそうな気が今しているので。
決定論的ワークフローの限界とAI進化の恩恵
そもそももともと山ちゃんが今なんでそういう課題を感じていて、そういったものに移動したかっていうところをまずちょっと聞いてみたいかなって。
まず前提として、マストラでワークフローを組んでた時って何をしてたか、なんでそうしたかというと、ディープシークのV4フラッシュとかV4プロとかみたいな、ある程度安いモデルを使いながらも、そこそこ品質の良いワークフローのアウトプットを出せると、
今のこのポッドキャストの編集とかも、ほぼそれでやりきってるっていうぐらいなんで、そこそこの精度出るなみたいな確信があって。なので、クロードとかにやらせよりも、より決定論的に確実なアウトプットが出てくるかつ、格安で済ませれるっていうところが結構いいなって思って。
で、AIワークフローをよく組んでいたんですよね、僕は業務の効率家というんで。けどなんか最近フェーブルとか出てきて、なんか違うなって思い始めて。
で、フェーブルとか出てくると、フェーブルとかってある程度やってくれるわけじゃん。100%のものをやってくれるわけじゃないじゃん。
特に動画編集とかそういうのになると余計なんやけど、やっぱそれをやってもらうためにはいろいろとお膳立てをしないといけないみたいなのがあって。
だし、最終的にはうちの場合はもう本当に外部の企業さんから受注して動画を編集したりとかすることもあるんで、最終的には人間の精査とか微調整とかを経てクライアントに納品するみたいなのがあるので、
そうすると、なんていうんですかね、やっぱある程度人間側の制御面も必要なわけですよね。
人間側の制御面っていうと。
動画で言うと動画ソフトで読み込めるような形で最終的にAIからうちに納品されて、それをプレミアプロとかで取り込んで最終的に制御するみたいな。
それがだからソフトウェアを自分たちで作るじゃなくてもいいと思う。みたいな感じで、人間側が最終的にチェックして微調整して、最終的に納品可能なクオリティーまで上げていくみたいな作業がやっぱ必要だと思ってて。
で、そうした時にワークフローの方が良かったんですけど、フェイブル出てきて、頭が究極的に良くなってくると。
で、そうした時にこの頭が究極的に良くなった可能性を生かしながらも、ある程度人間側の意図した、僕側が意図した通りの成果物を作ってもらうみたいな。
ガチガチに固めてるとどんだけ頭良くてもそのワンステップのアホでもできる作業をやらすんだったらもったいないなって気になってきたよね。
だからAIの進化を予実に感じながらも、その潜在的な可能性を全然享受できてない感覚がワークフローにおいてはね。
ていうのを感じて、なのでワークフローには全てAIが使うためのツールがあるんで、
それをスキルとかうまく内部のプロンプトとかで定義していって、
クロードとかコーデックスとか頭の良いモデルが自由自在に動画編集をできるみたいな。
オーケストレーションに近いのか、オーマイオープンエージェントとかに近いからオーケストレーションレイヤーに近いのかもしれないね。
スキルとしてとかプロンプトとかで定義して、こういう風に動く系。
今ではクローにあったような、AIに実行させるための、
動画編集とかポッドキャスト編集させるためのツール群っていうのは、そこから呼び出してっていう指示を与える。
そうだし、それ用の、例えばそこからこれをするのはこういうサブエージェントとかになってくるから、
オーケストレーションレイヤー、一個の目的を達成するためのオーケストレーションレイヤーみたいなのに近いかもしれない。考え方としては。
あとは専用のエージェントを作ったみたいな感じなのかなって。
確かにそれも一つあるかもしれないね。
共通部品とガイダンスみたいなのを分けて、プログラムでの決定論制御はもうやめて、文字起こしとかしたいときは文字起こし用のツールを使ってみたいな。
あれが同じような感じでやってるかもしれないですけど、
ハイパーフレームみたいな名前の、どっかの動画のAIの企業がやってるOSSのやつかな。
もう結構近いのかなっていうふうに思うんですけど、なんかそういうのにちょっと作り変えましたっていう感じです。
で、これがなかなか良くてですね。
今までってワークフローを組んでるから、コンフィグファイルとか設定してさ、こっちが決定論的に出したいものを、BGMこれとかもそうだし、みたいなのを定義した上で実行するみたいなのが一手間があったんですよ。
クロードコードを立てて、これとこれの音源を収録したやつだから、編集しといてよろしくって終わる。
しかも分かんないことがあったりとか、過去のやつとかクロードだから勝手に見てくれて、過去こんな感じだからタイトルこれでいいかなって聞いてくれたりとかして。
あー確かに。そういうのもできるよね。
そうそうそうそう。だから今までってタイトルは決定して、こっちで決めてて、コマンドを全部コマンドに引数で割り当てて実行してたから、まあなんやかんやちょっと手間だったし、
他の人が使うってなると結構大変だなみたいな感覚があったよね。特に非エンジニアの人が使うってなると結構大変なものだなって思ってたんですけど、
確かに。
これとこれ編集したからお願いするだけで、しかも例えばモデルが足りないとかASRのモデルダウンロードできてないとかでも勝手にダウンロードしてセットアップまでやってくれるみたいな。
はいはい。確かに。
だからチーム内の違う、全然そういうプログラム知識がない人にやってもらったら勝手にやってたから、勝手にできてたから、これだと思って。
いやでもなんか、そのワークフローからヤマちゃんが言ってた、最初はハーネス作ってるんじゃないかみたいな話をしたときに、
ワークフローって結構難しいなっていうのは僕もなんとなくマストラでちょっとしか触ったことないんだけど思って、
これがまず難しいところっていうと、まさにそのモデルの成長があるけど、ワークフローでも固定化されてしまってるから、
その可能性を潰してしまうっていうのはあるなと思って。
あともう一個あるなと思ったのが、ちょっとこれ僕の勘違いだったらごめんなさいなんだけど、
ハーネスアーキテクチャとオーケストレーションレイヤー
ワークフローって確かAIで判断して、ワークフローの分岐を定義するとかもできると思うんだけど、
ライブで決定論的に実行するものを、結構AIを使ってワークフローを構築したりすると、
このワークフローの仕組みの中にスクリプト書いて、その中にコードが入ってしまってるみたいなのがあって、
ワークフローっていう作った一個の中に、もうAIとシステムの決定論的なソフトウェアっていうのが、
もう一個こう、まるっと入ってパッケージ化されてるみたいな感じの感覚があって、
これだと結構動かしにくくなっていくんだなーみたいな。
そうそう動かしづらくなるのよね。
なんか多段で、もちろん多分、何だろう、そのエージェントハーネスというか、
そういう中にダイナミックワークフローみたいなワークフローを、
まあ必殺技のように組み込むみたいなのはあると思うって話は多分前あったと思うんだけど、
けどやっぱベースは違うのかな、みたいな。
ベースはやっぱそのハーネス、一応AIには、なんか元々AIワークフローで組んでたんだけど、
ハーネスアーキテクチャの考えみたいな感じでやってって言ったら通じたから、
ハーネスアーキテクチャっていうのはある程度間違いではないのかなっていう風に思ってるんだけど、
今よくよく考えるとオーケストレーションレイヤーなのかなと思いつつ、
けど正直、そうだな、阿部ちゃんが後でわかるかもって言ってて、
自分で今自己解釈して言っちゃって申し訳ないけど、
結局クロードコードもやってるのはオーケストレーションレイヤーでもあるし、
オープンコードもオーケストレーションレイヤーでもあるし、
ハーネスレイヤーでもあるから、そこってちょっと曖昧なのかな。
ちょっと曖昧ではあるよね。
あと、わかったかもって思ったのが、さっき話したワークフローってAIもいるし、
システムのパッケージもあるしで、
割と混在してたのを分離してシステムはシステムとして、
山ちゃんがやったことってインターフェース化なのかなみたいな風に思ってたんだよね。
動画を処理するとか、ポッドキャスの編集をするっていうのは、
もちろんシステム化とか、あとはコマンドラインを教えれば、
ある程度FFMPEGを使って処理するとかってもちろんできると思うんだけど、
でもその中に山ちゃんがこうしたいみたいな、
いろいろ人間がこうしたいっていうのがあって、
それは本当はワークフローのプログラムの中に、
例えばステップバイステップで処理の順序として書いてあったりしたと思うんだけど、
それをAIがある程度呼び出しやすいようなインターフェースで区切ってあげて、
整理をして、もうワークフローから出したと。
そうするとAIが、AIエージェント、例えばそれこそフェイブルが、
自分でインターフェース化されたツールを見て実行できるようになったから、
これより柔軟性高く、ファイルとか特にタイトルとかは指示しなくても、
タイトルが認識できたら、それをツールに対して指示を出せば、
そのインターフェース化された、CLIなのか何かわかんないけど、
呼び出せば動くっていう状態になったっていうので、
AIとシステムの部分をちゃんと分離して、
結果ちょっとオーケストレーションっぽく動かせるようになったってことなのかなって。
まさにそうだね。ある意味ツールの整備をしたみたいな感じに近くて、
あくまでもそれを選ぶのは、もちろん指示書というかガイダンスはあるんだけど、
スキルベースで見ていくみたいな感じで、
だからリポジトリ自体も分けたんよね。
ビデオプロダクションツールボックスっていうリポジトリにいっぱいツールを束ねていって、
例えばビデオプロダクションポッドキャストとか、ビデオプロダクションクッキングレッスンとか、
ビデオポッドキャストトラベルとか、旅動画用とか、料理動画用とか、ポッドキャスト用とかみたいなので、
完全に関連で言うと4リポジトリあるみたいな感じになるんだけど、
1個のツールボックスを書くとして、他の奴らは自分たちが使いたいようにツールを呼び出しながら、
うまく動画制作っていうのをやっていくみたいな。
これはフェーブルと相談しながら、モノレポでやったほうがいいんじゃないかとか、
いろいろあったんですけど、
一旦このやり方のほうがいいのかなっていうところに落ち着いた感じなんですけど、
これが本当に正解なのかわかんない。
もしかしたらパッケージマネージャーでインストールして使うみたいな、
この先には多分あったりすると思うんですけど。
これがワークフローだと今までは固定化されてたものが、
インターフェースの整理が行われたことによってまさに、
AIがオーケストレーションなのかハーネスなのかっていうのはいろいろあると思うんだけど、
そのツールを認識して自由に呼び出せるようになったから、
ワークフローっていう固定化されない仕組み、仕組みとして固定化されずに、
自由にツールを使って動画編集とかポッドキャスト編集できるようになったっていうのは、
結構いい成功体験というか、
これからもワークフローにすべてを、
今までって僕はワークフローにどんどん束ねていったほうが、
AIをコスパよく使えたりとか、
目を取り除くとかっていうのができるようになっていくのかなって最初の方は思ったんだけど、
最近のこのAIの発展とかを感じると、むしろツールの整備をして、
AIに自律的にやってもらうとか、
そっちの方がいいって感じるようになっていくのかなって思います。
本当にそう思っているんだけど、
AI駆動開発の罠とツールの整備
1個問題がありまして、
AI駆動開発の罠があるんですよね。
AIにこういうことをお願いするとですね、
基本的にプログラム書き方があるんですよ、あいつら。
確かにね。
ワークフローに従うんですよ、あいつら。マジで。
そうだね。
コードを書くことに特化してるっていうか、
訓練されてるっていうところも多分あるし、
あとAIエージェントっていう概念自体をあまりよく知らないっていう、
AI自体がみたいなのがありそうだよね。
そうそうそうそう。
っていうのがあって、
そこが今後フェーブルがいなくなった、
フェーブルはそういう意味では、
オーケストレーションというか、ハーネスアーキテクチャというかをちゃんと理解してて、
それっぽくやってくれるし、
エージェントMDとか整備するときも、
プログラムに寄せちゃいたくなるんだけど、
プロンプトとかレバルとかで、
重要なルールみたいなのとかで、
寄せれて解決できるものはできるだけそれで解決しようみたいなのを書いてくれたり、
分かってんじゃんお前みたいな感じの。
これがね、フェーブルしかうまく開発してくれる感じがないんですよね。
なんでだろうね、カットオフの問題なのか、
単純にやっぱり知能として高いかな、
どっちもありそうだけど。
多分なんかその、
世の中にある情報、
一回そのベストプラクティスとかも色々調べてもらったんだけど、
世の中にある情報が若干多分古くて、
やっぱりできるだけ決定論的に、
プログラムに押し込めるものは押し込めた方がいいよね、
みたいな主張が強くて。
まあそうだよね。
別にそれって確かに正しいんですけど、
だから判断はLLM、
実行はプログラムみたいな、
言い方をしてるのが結構多くて。
けどなんかここの、
またこの判断がっていうところもね、
また難しいところで、
なんか分類とかも決定論でやりたくなっちゃうよね、
AIたちが。
そうだね、なんかステータスをいくつか作って、
勝手にやるみたいな。
判断かな?分類かな?みたいなのが結構、
とかもあったりするんで、
まあなかなかこう、
人間的な感覚を、
持ってるフェーブルとかじゃない?
厳しい。
局所的な最適解を求めがちだからっていうのがありそうだね。
将来こういうケースがありそうだから、
もっと柔軟に作っておきたいんだけど、
みたいなのがないから、
ここはエージェントで不確実性のあるものを対処してもらうとか、
ここは決定論的に突き進めて、
トークン消費しない方が効率的だみたいなのがなくて、
全部言われたことをプログラムにして、
仕様化して落とすもんじゃ。
うんうん。
そうだね。
なんかだから難しいなって思うんですけど、
結構成功体験としては、
もう割といい感じにいったなって思って、
正直僕しか使えないなみたいな感覚だったんですよ。
これまでの。
作った人しか知らんみたいな。
設定項目もめっちゃ多いし。
だし、そこの内部的な意図みたいなのもあるし。
そうだね。
なんかちょっと、
MCPを作ってる感覚と似てるような気もしてくるかなと思ってて。
ある意味フリーMCPとかもそうかなっていう気はするよね。
なんかそんな気がする。
なんか僕も今まで、
例えばなんですけど、最近結構良かったなと思ってるのは、
これはまあ決定論的なワークフローなんですけど、
テストを書いて、テストをする時に、
B2Eテストをするのに、
プレイライトを使ってたりしたんですよ。
プレイライト使ってても、
やっぱりなんかちょっとこう、
アカウント情報が足りてないとかあって、
結構それを再取得したりとか、
なんかいろいろゴニョゴニョしなきゃいけないことが、
やっぱり裏では発生するみたいなのがあって、
ワークフロー化は、
そのB2Eという文脈でのワークフロー化はできてるんですけど、
ちょっと柔軟性足りないから、
なんかそこに対して、
AIが自律判断できるような仕組みがあったらいいなっていうところと、
足りない設定とかもうまくできるようになってくれたらいいなと思って、
実はちょっとCLIを新しく作ったりしたんですよ。
コマンドラインインターフェースって言って、
コマンドラインでコマンドを打てば、
ある程度こういろんな設定ができるみたいな仕組みをしたら、
AIがB2E流しながら詰まったところは、
コマンドラインインターフェースで再設定して、
ログイン情報が足りてないからアカウント作るのは、
なんかわざわざログインのフォームをいろいろゴニョゴニョしなくても、
CLIでアカウントだけ作っとけばすぐパスできるみたいなので、
柔軟にB2Eテストをやってくれるみたいな仕組みを作ることができて、
結構そういうツールを整えてAIが解釈して、
自由に使える場所を与えるのって結構今大事なんだなって。
これがMCPを作ってる感覚とあんま変わらないなみたいなのはあるんですけど、
パラボタメントでツールを作って、
それがAIがちゃんと解釈しやすい、
そして使いやすいっていうところが結構大事だなって。
いやーほんとよね。マジでそう思いますよ。
ボトムアップ開発とAI活用への示唆
なんか難しい、動画とかみたいに複雑なものとかになるときに、
初めからこのハーネスアーキテクチャ前提で、
今のクオリティの文字起こしとかまでできたのかなみたいなところは、
俺のスキル調はちょっと難しいなっていう。
だから結局ワークフローから今の形に落ちるしかできなさそうだったなみたいな印象はあるけど、
出てくる課題が、
動画制作も普段してる人にヒアリングしながらやってるから、
知見があるというよりは、
自己学習しながらやってるっていう前提があったときに、
ぶつかる課題を一個一個目の前に出た壁を、
世界中の情報を調べて、
ベストな条件で、ベストな突破方法なんだろうみたいなのを、
引き続きにやっていくみたいな作り方しか、
一番上からトップダウンで作ってるわけじゃなくて、
ボトムアップ的に出てきた課題をどんどんやっていくみたいなスタイル。
スクラムとかそういう感じのやり方でやってるから、
それとこのハーネスアーキテクチャの作り方って結構難しい、
マージさせるのも難しい考え方だなっていう風に思うよね。
特定のツールを扱いやすいようにしようっていうような、
とかだったら割とそういう感覚でやれるような気がする。
特定のサービスを使いやすいようにするみたいなのと。
ある意味これ、もしかしたら聞いてる人からするとちょっと残念かもしれないですけど、
AIを使ったら魔法のように何でもできるみたいな感覚よりかは、
僕らが感じてる感覚としては、
まずワークフローとかある程度固定化されたものを使って、
ちょっと大変なんですけど、そこを共通をまとめてインターフェース化していくというか、
AIが使いやすいツールに仕上げて、最後をオーケストレーション化するみたいな。
やっぱそういうステップの方が、
僕らも課題とかよくある失敗とかよくある課題みたいなのをちゃんと吸い出しながらも、
AIがより活用できるワークフローというか仕組みを整えられるっていうのは、
こういう遠回りっぽいけど、そういうステップがどうしても必要になるんじゃないかなみたいなのは、
気づきというかとしてあるんじゃないかなと思うんですけどね。
結構AIでガツッとやってもらうみたいなのも、
最初ワンプロンプトで頑張ろうみたいなのがあってもいいと思うんですけど、
なかなかそれだと、意外と遠くなってしまうよっていうのもあるっていう。
知っていただけるといいかなーみたいな、今普通に思った。
うんうんうんうん。
今後の展望とまとめ
いやー、まあまあということで、ちょっとワークフローから脱却してみましたと。
で、意外といい感じなんで、やっぱこっちだな、進むべき方向はみたいなところが見えてきたときに、
今作ってるサービスどういうふうに作っていったらいいんだろうなーみたいなところがまた悩ましい点があるんですけれども、
ちょっとそんな葛藤を抱えながらやっておりますという感じのシェアでした。
今日はこんな感じかな。
はい。
はい、じゃあありがとうございました。
ありがとうございました。
本日もAI駆動開発部の日常をお聞きいただきありがとうございました。いかがでしたでしょうか。
今回はもともとAIワークフローを組んでいってたんですけれども、それを少し素にしたというか、
実際の実行面と制御面を切り分けたみたいな言い方なんですかね、みたいな感じにしたところ、
思った以上にいい感じの成果ができたので、成果が出てきたというところで、ちょっとした共有となりました。
こんな感じでAI駆動開発やったりとか、AIワークフロー、AIを使った効率化みたいなところとかについていつも話しているので、
ぜひこのポッドキャスト気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。
次回もお楽しみください。バイバイ。
![[4] 整理できていないから、いっぱいしゃべる](https://image.listen.style/img/CoazSOVLhcG5dBTuoKdLgMRtBIFBGB7_D8vGzpEgz2M/resize:fill:80:80/aHR0cHM6Ly9pbWFnZS5saXN0ZW4uc3R5bGUvcC8wMW0wN3gyZXFxNDFncHE3a21id3AxNHludC9pbWFnZXMvUjVWZ2JKbDNnNklPVjZzVWU1TGxFSjVJaHlXcjdPaXhUcGdqTzd4cC5wbmc.avif)
