なぜ僕らは、AIコーディングツールを統一しないのか

様々なAIコーディングツールが台頭している昨今、たいていの会社は「うちの標準はこれ」と一本に決めたくなるのではないでしょうか。設定を共有しやすい、教えやすい、管理もしやすい。揃えるのは、合理的ですが、TamaTは、それを行なっていません。

第1回では、田中が自分で作ったAI実装アプリ「izanagi」という"共通の道具"が、どうやって会社全体の案件に効いているかを議論しました。今回はその逆で、社内のエンジニアがどのようにAIモデルを使い分けているかにフィーチャーします。各自がバラバラに選んだ"市販の道具"を、チームとしてどう束ねているのか。道具は散らばっているのに、なぜチームは崩れないのか——田中・増田の二人で、運用と意思決定に関する対談を行いました。

使っているツールが、そもそも違う

増田： まず、お互い、今何を使ってるかを並べてみたいんですけど。たけさん (田中) は最近どんな感じですか。

田中： Claude Code、Cursor、Codex、Grok。最近はまんべんなく使ってる。前はClaude Codeに集中してた時期も、Codexに集中してた時期もあったんだけど、いまは工程で分けてる。UI系はClaude Code、ロジック周りはCodex。プランはClaude Codeで立てて、そのプランレビューをCodexに投げる。実装はCursorで、その実装レビューをまたCodexに、さらにPR上でDevinにもレビューさせる。修正系のタスクはCursorのdebugモード、質問はCodexだね。

増田： 自分も並びは似てて、Claude Code、Cursor、Codex。ただ、どちらかというとClaude Codeメインなんですよ。プランはClaude Code、プランレビューはCodex、実装はそのままClaude Codeでやる。そこにDevinのレビューを足す感じ。あとは、修正やデザインといった簡単なタスクの時はCodexのデスクトップアプリでやったりしますね。質問系は逆にCursorです。

田中： ツール名はだいぶ被ってるのに、どの工程でどれを使うかが違うんだよね。

増田： そうなんです。たけさんは実装をCursorに寄せてるけど、自分は実装もClaude Codeでやってる。修正の担当も逆。同じ単語が並んでても、中身の配置が違うようです。

揃えようとして、揃えていないわけじゃない

増田： この違いって、自然に分かれていきましたよね。

田中： 完全に自然に、だね。誰かが「お前はCodex使え」って決めたわけじゃない。各自が触ってみて、いまの時点でいちばん手戻りが少ないものに落ち着いた。それだけ。増田の場合は？

増田： 自分も同じで、扱いやすさでClaude Codeに寄ってる、という理由なんですよね。個人的にどんなコードの差分が生じるかはウォッチしておきたいので、具体的にコードをプランに出してくれるClaude Codeは使いやすい。
あと細かいところだと、izanagiみたいな自作ワークフローはissue化する手間があって、ローカルで完結する修正系の作業には使わないことが多いです。複雑なブランチ運用が必要な案件だと、自前のワークフローでやることが多くなる。

田中： そこは参画してる案件の違いも効いてるよね。

増田： 大きいと思います。2人が見てる案件の性質が違うから、最適な道具も自然とズレる。同じツールに無理やり合わせる理由が、そもそもなかったんですよね。

違うからこそ、網が広がる

増田： 道具が違うことで、得してるなと思う場面ってあります？

田中： キャッチアップの網が広がること、かな。自分がClaude Codeを使ってない時期でも、増田が新機能を見つけて「/goalってのが来ましたよ」みたいにシェアしてくれる。両方の最新を、2人で手分けして追える感じになる。

増田： 学習の文脈でも効きますよね。コードの書き方を学びたい人にとっては、やり方が一通りしかないより、いろんなやり方が社内にある方がいい。「この人はこう書くのか」が複数あること自体が教材になる。

田中： 結局、ツールの選択って好みに依存する部分が大きいんだよね。だったらエンジニアごとに、その人に合ったやり方になれる方がいい。無理に1つに寄せると、その"合わせるコスト"のほうが高くつく。

増田： もし統一してたら、何を失ってたと思います？

田中： この網だね。1人が1ツールに張り付くと、見えてる範囲がそのツールの中だけになる。2人で別々を追ってるから、片方が落とした知見をもう片方が拾える。そこが消える。

もちろん、痛みもある

増田： 逆に、揃えてないことで困ってる場面もありますよね。

田中： あるね。増田的にはどこがいちばんきつい？

増田： オンボーディングですかね。体制がまだ整っていなくて、スキルが共有しきれてなかったり、属人化してる部分がある。あと地味にきついのが、オリジナルのスキルをClaude Code用とCodex用で二重に用意しないといけないこと。1つ作れば済む話が、ツールが分かれてる分だけ重複するんですよ。

田中： そこは正直これからの課題だね。バラバラであることのコストを、いまはまだ人力で吸収してる段階。

増田： marketplaceのリポジトリは共通なんですけど、frontmatterのフォーマットが違ったりして、いまいち決め手に欠けるんですよね。

では、何を揃えているのか

増田： 道具は自由。でも、これは絶対に揃えてる、というものもありますよね。

田中： フローそのものかな。使うツールは違っても、プラン → プランレビュー → 実装 → 実装レビューっていう流れは2人とも同じ。どのAIでやるかが違うだけで、工程の型は共通。これはやった方がいいと思ってる。

増田： 品質保証も揃えてますよね。

田中： CIレビューで、最低限の品証はツールに関係なく全員に課してる。手元で何を使っていようと、最後にここを通る。ここが揃ってるから、入口の道具がバラついても出口の品質は一定に保てる。

増田： 線引きがはっきりしてるんですよね。揃えるのは「フロー」と「品質のゲート」。揃えないのは「手元の道具」。出口を固定してるから、入口を自由にできる。

知見は、雑談から移る

増田： 違う道具を使ってる2人ですが、知見ってどうやって移してますっけ？

田中： 新しいサービスが出たら、とりあえず触ってみて所感を共有する。「Grok Buildは微妙だったよ」とか、そういう温度感まで含めて流す。場としてはどこが多い？

増田： 半分は雑談ですよね。ランチを食べながら話すことが多い気がします。あとはSlackのAI共有チャンネルで、ぽつぽつ呟くカルチャーがある。気づいたことを各自が垂れ流して、それを拾い合う感じです。

田中： 自分が使ってないツールの話を聞くのって、意味あると思う？

増田： ありますよ。実例で言うと、「Cursor CLIのクオリティが高い」っていう話は、TamaTの中でしかキャッチアップできなかった。自分はメインで使ってなかったけど、社内で流れてきたから知れた。外の情報だけ追ってたら、たぶん拾えてないです。

田中： Cursor CLIを話題にしてる人、SNSにもあまりいないもんね (笑)。新しいのが出たときは、基本「とりあえず触る」側だよね。新顔が来たら、まず誰かが触って、所感をチャンネルに置く。

増田： 揃える対象にするかどうかは、その後で各自の手応えをすり合わせて決める。様子見から入るというより、触ってから判断する、という順番ですね。

どんな人と、このバラバラを回したいか

増田： 新しく入った人は、自分のツールを自由に選べるんですか。

田中： 選べる。むしろ、TamaTにない知見があるなら教えてほしいくらい。自分たちが追えてないツールを持ち込んでくれるなら、それは網がさらに広がるってことだから歓迎だね。受け入れる土台のほうはどう？

増田： 少しずつ整えてます。marketplaceとizanagiは整備済みで、wikiにも知見をまとめてるところ。Devin、Claude Design、Figma Makeあたりも触っていて、社内に積み上げてる最中です。ただ、合わない人もいると思っていて。

田中： というと？

増田： 好みで道具を選べる自由がある分、自分でキャッチアップできない人にはしんどいかもしれない。「正解のツールを1つ教えてください」というスタンスだと、この環境は逆に不親切に見えると思うんですよ。標準が1つ降ってくるわけじゃないので。

田中： 自分で選んで、自分で試して、所感を持ち寄れる人。それが回せる人だよね。指示を待つより、先に触って自発的にチャンネルに何か置いてくれる人と一緒にやりたい。

最後に

増田： 会社が決めた1つの道具を全員に配るほうが、たぶん楽ですよね。

田中： 楽だと思う。それでもそうしないのは、揃えるべきものを「フロー」と「品質」に絞って、道具は各自の裁量に開いてるから。出口を固めてるから、入口を散らせる。散らせるから、2人で追える網が会社の知見になる。

増田： 次に学び合う相手も、別の案件を持ちながら所感を持ち寄れる人だといいですね。

田中： 知見を共有できたり集約させていく体制や仕組みはこちらで整えていくから、ドヤ顔で良い開発フローを紹介してほしいね。使うツールの利用料も、有用であれば会社側からいくらでも支援するし。