Claude Code全盛時代、自分の視座と共に歩むエージェントを選ぶ

みんなClaude推しなのに、自分の手元では何かが噛み合わない

開発でAIエージェントを使うとなれば、Claude Code、Cursor、なんならClaude Maxの月額プランを契約するのが、いまや普通の風景になりつつある。手元のSNSも、エンジニア界隈の記事も、だいたい「Claudeが良い」で揃っていて、それは自分自身も否定するつもりはない。実際、性能はいい。

ただ、自分の手元にある趣味のOSSエディタのメンテで何度かエージェントを試しているうちに、何かが噛み合わない感じが出てきた。Claudeが良いのは分かる。性能で選ぶならそれでいい。でも、自分が困っていたのはたぶん「良いモデルを選ぶこと」ではなかった。

性能の比較なら、答えはほぼ決まっている。けれど、自分が気にしていたのは性能じゃなかった——そう薄々気づきはじめた、というのが正直なところだ。

ふつうのエージェント比較は「使う自分」を見ていない

エージェント比較記事を読むと、たいていは優劣の話で並ぶ。コーディング能力、コスト、対応IDE、ベンチマークの順位。最近は「Claude Codeの代替」として紹介されるツールも増えていて、たとえばgstackのように、よく見ると単に同じ仕事を別のモデルで動かすものではなく、コマンドや役割分担や実行環境を通じて、人間とエージェントの関係を組み替えているケースが多い。

こうしたツールが別々に存在している背景——どんな思想で設計されていて、人間に何を求め、何を引き受けるのか——を整理しないまま、機能や使い方の比較だけが流通している。本来語られるべきはツールの使い方ではなく、自分自身を軸にして、それぞれのエージェントをどう使いこなすかのはずなのに、そこにはあまり踏み込まれない。読み終わったあとに残るべき「ツールを使うことで自分にできること」という結論が、まったく見えてこない。

AIによって、こういう「思想や振る舞いの哲学」を読み解くこと自体は、本当はもう難しくないはずだ。同じ依頼を複数のエージェントに投げ比べたり、設計ドキュメントをモデルに読ませて整理してもらえば、それなりの解像度が出せる時代になっている。

それなのに、エージェント論はいまだに「どのモデルが賢いか」「どのモデルが安いか」を中心に回っている。もちろんモデルの影響が大きい場面もあるし、そこを軽く見るつもりはない。ただ、本当は、エージェントの振る舞いはモデルとエージェントの設計思想とプロンプト——この三つが複雑に絡み合いながら立ち上がっている。モデルだけでも、設計思想だけでも、プロンプトだけでも決まらない。

設計思想——どこまでをエージェントが引き受け、どこで人間に戻すのか、どんな関係を前提にして走るのか——も、プロンプトの書き方も、モデルと同じくらい、ときにはそれ以上に効いている。それなのに語られるのはモデルばかりで、残り二つは背景に置かれたまま動かない。

同じモデル、同じプロンプトを渡しても、エージェントごとに振る舞いはまるで違う。自分が手元で同じ仕事を別のエージェントに渡してみたとき、出てきたのは「どっちが優秀か」じゃなくて「どっちが自分とどう組むか」の違いだった。同じプロンプトで、同じリポジトリで、出力の質感がまるっと変わる。性能の差ではなく、振る舞いの哲学が違う。

そう感じてから、エージェント比較を「関係性の比較」として見直したくなった。

同じプロンプトで挙動が分岐したとき

きっかけは、自分がメンテしている好きなRust製のOSSエディタのcrateを、Rust 2024 / Rust 1.85前提に近代化する作業だった。

ある程度ふんわりしたプロンプトを書いて、それをFactory DroidとKilo Code CLIに同じ条件で渡してみた。結果は、

• Kilo Code CLI: 触ったのは Cargo.lock と Cargo.toml 4つの、計5ファイル。バージョン文字列だけを書き換えていた

• Droid: 同じCargo系に加えて、`.rs` ファイルを32本触っていた。新しいコンパイラで出るようになった警告を潰し、ライフタイム明示化や不要キャストの削除まで含めて、ビルド警告ゼロまで持っていっていた

両方とも「正しい」と言える挙動だ。Kiloは自分が明示した範囲の中で止まり、判断は自分（マネージャー側）に戻してくる。Droidは「請負として渡されたなら、警告ゼロまで持っていくのが妥当」と推論して動く。同じプロンプトを、まったく違う哲学で受け取った——という事実だけが残った。

ここで気づいたのは、「どっちが正解か」ではなく、「どちらを選ぶかは、自分がどう関係を作りたいかで決まる」ということだった。

ここで言う「関係」とは、相性や使い分けのことではない。自分がどの立場を取るかによって、エージェントへの渡し方も、エージェントから受け取るものも変わる——そのセットのことを、この記事では関係と呼んでいる。

モデルではなく、ハーネスのほうに性能の核がある

もうひとつ、地味だけど大きかった気づきがある。

DroidはOpusやSonnetだけでなく、GLMのようなopen-weightのモデルでも、自分の用途では問題なく書けた。つまり、Droidの「請負としての強さ」はモデルに紐づいているのではなく、Droidというハーネスの設計のほうに紐づいている。

これに気づくと、「Claudeが良い」という結論の解像度が変わる。Claudeが良いのは事実なんだけど、エージェントの振る舞いを決めているのはモデルだけじゃない。harness engineering（ハーネスをどう組むか）、intent driven development（意図をどう書くか）、spec driven development（仕様をどう詰めるか）——そしてそこに乗る人間側の知見。これらを合わせた関係設計の総体のほうに、性能の核がある。

そう見ると、Claude Maxに月額をぶち込むのが唯一の正解、ということにはならない。モデル選定はそのうちのひとつのレバーに過ぎなくて、他のレバーで補える領域も普通にある。

コードを触らない参謀、という置き方

実は、自分が一番頼っているのはClaude Codeじゃない。

ソースコードをzipで固めて、Claude on Webに渡して、コード環境の外で設計や方針づけの相談をする使い方をしている。コードに踏み込まないからこそ、「やるべきこと」と「やらないこと」を冷静に並べ直せる。コードを触り出した瞬間、人は早く動かしたくなって判断が雑になる——あえて参謀をコード環境の外に置くと、距離が保てる。

実装そのものは、エージェント側に渡す。Kilo Code CLIには「探索余地を残した依頼」を、Droidには「受け入れ基準まで書き切った依頼」を。役割によって渡し方を変える。

3つの経験を、関係の地図として並べてみる

ここまでの3つの手触り——Kiloに止められて、Droidに走り切られて、Claude on Webに参謀として並走してもらった——を一枚に並べると、自分の中ではこういう地図になっていた。

• Claude

  • 役割 = 全体俯瞰、方針策定、技術選定、デバッグ調査

  • 自分の立場 = 経営企画

• Kilo Code CLI

  • 役割 = 役割分担が必要な並行開発、複数モデル運用

  • 自分の立場 = プロダクトマネージャー

• Factory Droid

  • 役割 = ゴールが明確な機能単位の実装、PR作成

  • 自分の立場 = 発注担当

ふつうの比較記事と違うのは、「自分の立場」のカラムが効いていることだ。同じ仕事でも、自分が経営企画の位置にいるのか、PMの位置にいるのか、発注担当の位置にいるのかで、渡せる相手が変わる。性能順位ではなく、自分の立場の選択がまず先にある——そう見ると、エージェント選びは「優秀さ」の話から「ロール設計」の話に移る。

芯と芯の関係

以前、自分の仕事の外周を先に逃がす、という話を書いた。判断や名付けや方向づけといった「自分が引き受けるべき芯」に集中するために、未整理な流入や暗黙の判断基準といった「外周」を先に外へ出しておく、という整理だった。

この発想は、たぶんエージェント側にもそのまま使える。

• 第一層：自分の仕事の外周を逃がして、自分が引き受ける芯を残す

• 第二層：エージェントの仕事の外周も逃がす（harness / intent / spec）ことで、エージェントが引き受ける芯を残す

ふつうのエージェント比較が関係性を捉え損ねるのは、両側の外周を逃がさないまま使うから、なんだと思う。人間側がドカンと未整理な要望を投げ、エージェント側もハーネスや受け入れ基準なしに走り出す。すると、評価軸は「丸ごと投げて何が返ってきたか」だけになって、結論は「賢いモデルが偉い」に収束する。

両側の外周を整えると、はじめて芯と芯の関係が成立する。自分がやりたかったのは、たぶんそれだった。

Claudeを良くできる関係を、自分は作れているのか

エンジニアじゃない人がAIでエンジニアっぽくなる、というのは普通にいいことだと思っている。否定する話じゃない。

ただ、自分のように既にコードを書いてきた人間がそこに合流するなら、「もっと早くもっと多く書く」だけがゴールではない気がしている。シニアの強みはモデル選定でも、書く速度でもなくて、たぶん関係を設計できる側に立てることにある。受け入れ基準を蒸留できる、探索余地を判断できる、参謀をコード環境の外に置く理由が分かっている——そういった、自分とエージェントのあいだに距離と役割を引ける部分。

「Claudeが良いの？」という問いの答えは、自分にとっては「はい」だ。性能はやっぱり強い。ただ、ここまで書いてきて自分の中に残っているのは、もう少し別の問いだ。

Claudeを良くできる関係を、自分は作れているのか？

性能はモデル提供者が伸ばしてくれる。でも関係のほうは、誰も代わりにやってくれない。

まずは、受け入れ基準を一行書くところから

この問いは大きすぎて、毎回いきなり全部設計するのはたぶん無理だ。だから自分はいま、ものすごく小さい一手から始めている。

Droidに渡す前に、受け入れ基準を一行だけ書く。

「警告ゼロまで」「公開APIは変えない」「テストは追加しない」——そのくらいの粒度でいい。これだけで、Droidの請負としての挙動が、自分の意図とぶつかる確率がぐっと下がる。Kiloに渡すときは逆に、「ここまでは決め打ち、ここから先は調べて提案して」と探索の余白を一行残す。受け入れ基準の有無、探索余地の有無——そのたった一行が、関係の入口になる。

Claude Maxに課金して最強のモデルを手に入れる前に、たぶんこの一行が先に来る。

## まだ途中

このメンテはまだ続いていて、次に試したいのは、各エージェントに渡す前段の「外周整理」をテンプレ化できるかどうか、というあたりだ。受け入れ基準の書き方、参謀に渡すコンテキストの圧縮、Kiloに残す探索余地の書き方。これは別の記事で書くつもりでいる。

エージェント比較は、たぶんここから先「どのモデルが賢いか」じゃなくて「どの関係をどう設計するか」の話に重心が移っていく。少なくとも自分の手元では、もうそうなり始めている。