Ryusou Blog

Agents Skillsを多用し、開発ワークフローを組みことはアンチパターンになりうると考えます。

開発のワークフローはプロダクトひいてはその設計に依存すべきであり、AIはそのプロダクト内の設計ないしはガードレールの上で自由に動いてもらうというのがこのブログの主張です。

Skillsでワークフローを組むデメリット

「ワークフローがLLMの推論に依存する」

Skillsを組み合わせた時の実行順序やSkillsの選択や条件分岐など、Skillsが増えるほど問題になります。ソフトウェア設計でいうところのビジネスロジックがLLMに依存した状態になります。

「ワークフローの暗黙化」

AIが何をやっているのかわからなくなります。ただこれを把握する必要はないという考えもあるかもしれません。

再現性や状態遷移の管理がブラックボックス化し、デバッグが困難になります。これはAIの精度向上に合わせてそれを含めて解消されるという考え方もありそうですが、その時にはSkillsなしで再現性高い処理をAIは自走しているようにも思えます。

何をSkillsにすべきか？

AIが得意な探索・推論などです。コードを探索してヘルスチェックをするものなどが適当だと考えています。ただそれもコードの設計が画一的であれば不要になっていく可能性が高いと思っています。

プロダクト側でガードレールを引く

プロダクト設計でガードレールやワークフローを定義することで、その範囲内でAIの得意な探索・推論をさせるのが良いと考えます。

• 統一されたコード設計
• 規約の強さ（Lint, Test, CI・CD）

AIがビジネスロジックや設計をするのではなく、プロダクト側のガードレールを引くことでAIが自由に探索・推論の再現度を高めることが重要で、AIの推論のリトライ回数を増やして自走できる部分が増えるのではと考えています。

コード規約が強目なプログラミング言語、コード設計が統一されているプロジェクト（そんな完全な負債のないプロダクトなど存在し得ないが.....）があれば極論Skillsにあまり力を入れなくもいいのではないか？というのが私の主張であり、Skillsは補助的な役割に留める方が設計として安定するように思います。

「Skillsを増やすより先に、プロダクト側のガードレールを整えるべきではないか。」その前提に立ち、それでも運用上防げないシーンが出てきた時に初めてSkillsを活用していくフェーズだと私は思うのです。