島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

新しいトライとしてAIのためのテスト量産をしてみている

うまくいくかはわからないけれど、AIにコード書かせて人間レビューコストを下げようと思うと、レビューAIが確認するまでの間の作業AIが拠り所になるものは必要だと感じている。特にシステム境界についてモックしがちな性質だから境界の契約違反がかなり厳しくなる。

私はブラウザ含めたE2Eテストモリモリはあまりやりたがらないため、いわゆるインテグレーションテストを増やして対応する方針。例えばフロントエンドからサーバーのAPIをコールするところについて、フロントエンドの呼び出し口からサーバーの処理を呼ぶ箇所までの範囲でモックを使わずに呼び切らせるイメージ。

昨年までのAIと違って、コード自体が呼び出し不能だったりするようなことはほとんどなくなったから、今度はこの境界をうまくやる方向がいいと思っている。また、人間のプロジェクトでやるとコスト過多になりがちな「やれるなら書いたらいい」というものは書かせて良いと判断していて、StoryBookやスナップショットテストも導入してみている。

どうしてもスタックしてしまう仕事

AI エージェントを並列でゴリゴリ稼働させられるから、簡単なタスクのマージは素早くなったんだけれど、今回作っていたような課金機能みたいなところはどうしてもまとまった時間をとって自分が動作チェックをすることが必要で、多分10日近く起きっぱなしになってしまった。その間、ユニットテストとかレビューとかはみっちりさせておいたけれど、やはり実際にやろうとすると色々出てくる。

今日やっとどうにかマージできそうな気配。

MCPまだ死んでない。もしくは新規のWebサービスへの入力をスムーズにさせようと思った時に作るものの話。

最近2つくらいの新規サービスで、AIから機能を操作させたい要望があった。

  • REST API: APIの説明をどうにかしてAIに教えないといけないが、いい方法がなかった。スキルをユーザーが書いたとしても呼び出してもらえるかの不確実性が高い。
  • CLI: サービスのために新たにダウンロードさせるのが憚られた。しかも使い方をどうにかしてAIに教え...
  • MCP: そのツールがあるということを明確にわからせることができて、適切に呼んでくれた。

というわけで自分はどちらもMCPで提供している。

もしかしたら、懐かしの WSDL 的なものが今あったりしたらそういう標準があると素晴らしいのかもしれない。今だとOpenAPIスキーマか?そうかも。でも、今度はそのURLを教えさせるスキルが(と、振り出しに戻ってしまう)。MCP で OpenAPIスキーマのURLのリストを提供したらできるんかな?そういうことかも。いつかやりたくなったら試す。

端的に設計力や、先読み力を考えると codex は強いなぁ、とあらためて思った

Stripeの課金をするところのコードを Claude Code に依頼して書いてもらったんだが、どうも気になる感じになっていたので codex にレビュアーとして入ってもらってやりとりさせてみた。一応レビュー上がったコードが出てきたんだがいろいろとフラグが多くなっていて見通しが悪い。

私の想定ではそこまでいろいろと必要な理解ではなかったので、一度設計しなおそうと思い、別の場所で codex と相談をしたところ、データ構造から見直しが入ってかなり良さそうなデータ構造になった。

受ける印象として前から、単純にコードを扱う力は codexの方が強いと思っていたんだが、思考の深さ、的なところが違うようだ。物事を整理して考えようとする性質が強い感じだろうか。Claude Code はとりあえず書いてからどうにかしようとするので、最終的に散らかってしまったものを整理するプロセスが大きなコストとして出てくる印象。

AgentConsole の Webhook と 内部メッセージ機能

github.com

やりたかった機能を実現できたので記録しておく。

1. GitHubからのWebhookを取れるようになった

とりあえずCIがFailしたこととSuccessしたことは取れるので、今後対応メッセージを増やしていく予定。これによってCIがFailしたことをわざわざ連絡する必要がなくなったので、全自動感がさらに増している。

クライアントワークではGitHubでレビューしてから納得してマージが続くので、これくらいの機能が今は良いと思う。最終的にはSuccessしたらマージするプロンプトを与えてもいい。

2. Worktree間(Session間)でメッセージ送信が可能になった

親になるWorktreeから複数のWorktreeを作らせたとき、完了の通知を受けられないことがしんどかったので、ちゃんと作る必要が出てしまた。結果的に親子かんのメッセージ機能をファイル書き込みで実現する形になっている。

基本的に親子関係があるときに利用しやすい仕組みだが、概念的に同一プロセスにいるどのセッションにも送れる。

今後気になること

あとは以下のあたりが欲しいかな。

  • OSへのログインユーザーごとにWorktreeを管理して、複数ユーザーで使えるサービスにする
  • 今のように刹那的に親子関係を発生させるのではなく、特定の課題解決のためのオーケストレーション
  • (最近意見もらった)Claude update の時に全セッションの開き直しが面倒なので、全部一気にリスタートする

AgentConsole にエージェントからWorktreeを作成する手法を作った

github.com

いつかはやるだろうと思っていたんだが、AgentConsole自身がMCPになって、自分の機能をAgentに使わせる機能を作った。

今実現しているのは新しいWorktreeをプロンプトを与えつつ作成して、そのままワークさせること。どうしても何かの作業中に「これやっておきたい」が発生するのだが、それをIssueにして置いといてしまうとどんどんIssueだけが溜まっていく、という法則に抗いたかった。その場でシュッと新しいWorktreeを作ってエージェントに依頼してしまいたい。

また、これができると既存のIssue一覧をエージェントに吟味させた後「じゃ、全部Worktreeにして仕事始めて」と依頼すると全部をWorktreeでドシドシ作業させられるはず(そういうスクリプトを書くのもありではあるが)。

あとはいわゆるオーケストレーションも考えてはいるのだが、色々あって後に回されている。多分私が望んでいるのは「チームテンプレート」みたいなもので、特定の課題に対応して作られる感じだと思う。例えばFlaky Test撲滅チームは、Flakyチェックするエージェントと、その報告を即直していくエージェントがいて、間にキューになるテキストがある。こういうのじゃないと、サブエージェントに依頼してもらって報告受けといてもらえれば別に良くなって、チーム的な意味は特になくなると思われる。また、モデルを跨げないと大きな価値が生まれない気がするから、提供業者に関わらないエージェントコラボの方針(これは未来にはいらなくなるけど、今は欲しいんだ)。

そう言えば、Honoを利用しているのだけどMCPの機能まで公式ネームスペースで提供されており、進んでるなーと思うなどした。

AI用の作業サーバーを用意する形を模索している

AI に仕事を依頼する形式だと、自分の手元にあるマシンで動作するよりもいわゆるサーバーで動作してくれる方が放置しやすいので、少し前からその形を模索している。うまくできたら社のメンバーに開放して好きに使えるマシンとして利用してもらいたい。

最終イメージとしてはマシンからLinuxのVMを提供して、メンバーにはLinux上にそれぞれのアカウントを提供する形。この形式なら大事な情報は置かれないはずだし、マシンをぶち壊すことはできないので、AIに全権明け渡す使い方がやりやすい。その世界で勝手にサーバーでAIがコードを書いてくれている状態が最も効率良さそうに感じる。

これをやるのに、仮組しているのが Cloudflare の ZeroTrust を使って仮想ネットワークを作る形だが、かなりスムーズに動作する。特定のIPを持ったマシンがいつもアクセスできるような使い勝手になるので、難しいことがなくていい。認証もシッカリしているのでセキュリティの心配も少なく大変コスパが良い。

Linux マシンからのRDPを当初は構築していたのだが、updateしたら繋がらなくなってしまい、今は私1人で直接マシンにアクセスしている。RDPにしたい理由としてはChromeのMCPを使おうとしたときにUIが見えない状態だと困りそうだからだが、これもリモートで何かできるのであれば他の方法もありそうには思う。

github.com

いつものこれだと、ブラウザで動作するので Chromeを使わないならローカルと変わらない操作でAIが扱えた。同様のことをスマホからもできるとわかったので、UIもスマホ向けを提供して移動中でも寝室からでもシュッと操作できる形も見えてきた。

一方で Claude Code の最新機能を使おうとすると tmux や iTerm が前提だったりするので、今後どういう方向で伸ばすのがいいのかちょっと考えてしまっている。

code.claude.com

実は独自にオーケストレーション実装をすることを試みていたが、少し迷う。このペースで性能が上がるなら、複数の異なるモデル・エージェントで組むこともあまりいらないのかもしれない。