「最新のAIを足せば開発は速くなる」は半分まちがい ── ツールを半日 実機検証してわかった“使い分け”の現実
Claude Code・Antigravity CLI・Jules を自分の環境で動かし、損得を数字で確かめた一人社長の記録
— 最新ツールを「足す」より、タスクごとに「使い分ける」。半日の実機検証が教えてくれた、導入と活用のあいだにある現実。—
「それ、入れたら爆速になるよ」から、その半日は始まった
経営者仲間の集まりで、ある友人からこう言われました。AI活用に深く精通している、別の事業を営む経営者仲間です。
「Claude Code から Google の Antigravity CLI が繋がるんだよ。設計は Claude Code、コードを書くのは Gemini に振る。これで開発が爆速になる」
正直に言うと、心は動きました。私はふだん、claude.ai で構想を練り、Lovable で土台を生成し、Claude Code で作り込む、という流れで開発しています。私はこれを Flow Coding と呼んでいます。一人で複数のWebアプリを設計し、実装し、運用している身です。そこに「もう一人、手を動かしてくれるAIの作業員」を足せるなら、これほど魅力的な話はありません。
私はこれまで、AI支援で700万行を超えるコードを書いてきました。AI開発ツール Lovable の国内利用では上位1%に入り、「National Treasure」という称号もいただきました。700万行というのは、エンジニア一人の26年分の工数に相当します。それを数ヶ月で形にしてきたのが、私のここ最近の仕事です。だからこそ、開発を速くする道具の話には、人一倍敏感です。
ただ、私には一つだけ、固く決めていることがあります。「便利そう」で飛びつかないこと。 必ず自分の環境で実際に動かし、損得を自分の数字で確かめてから判断する。
なぜそこまで慎重かというと、苦い経験があるからです。私はかつて、外部の開発会社にシステム開発を発注し、約3,000万円を投じました。要件定義に3ヶ月、開発に6ヶ月をかけて出てきたのは、「使えないもの」でした。結局、現場はExcelに戻りました。あのとき痛感したのは、「作ること」がゴールの作り手と、「使えるもの」が欲しい経営者のあいだには、深い溝があるということです。
新しいツールも、まったく同じ構造をしています。「入れること」はゴールではありません。**問いはいつも、「それは、自分の現場で本当に効くのか」**です。というわけで、私は半日まるごと使って、この話をとことん検証しました。この記事は、その記録です。
なお、ここで登場する Google Antigravity は、実在するGoogleのAI開発プラットフォームです。料金プランや対応モデルといった事実は、すべて公式情報（Google Antigravity 公式サイト）と、自分の環境での実測に基づいて書いています。
まず「繋ぐ」だけは、拍子抜けするほど簡単に成功した
最初のステップは、あっさり成功しました。やったことはシンプルです。
ひとつ、Antigravity CLI（コマンド名は agy）を自分のPCにインストールする。ふたつ、Googleアカウントでログインする。みっつ、Claude Code と agy を、MCP という仕組みのブリッジで連結する。よっつ、Claude Code から「この処理を agy に投げて」と指示する。
すると、実際に agy（中身は Gemini というGoogleのAIモデル）が応答を返してきました。疎通テストはあっさり通り、「Claude Code から agy を経由して Gemini に作業を渡し、結果を受け取る」という往復が、確かに成立しました。
普通なら、ここで記事を締めるところです。「導入完了、便利でした」と。実際、世の中の「やってみた」系の情報は、ここで終わっているものが少なくありません。
でも、繋がることと、効くことは、まったく別の話です。本当に効くのかは、自分の実務に当てはめて初めてわかります。そこで私は、素朴な疑問を3つ、実機で順番に潰していきました。
検証1：今ある「議事録の自動化」を、まるごと任せられるか
私は、会議の議事録づくりを自動化しています。会議の音声ファイルを渡すと、AIが文字起こしと要約をして、議事録の形まで仕上げてくれる仕組みです。中身では、Googleの高性能なAIに音声を渡しています。
最初に考えたのは、これでした。「この一式を、まるごと agy に任せられないか。そうすれば、開発の手間も省けるし、AIの利用料も浮くかもしれない」。
投げてみました。結果は、とても示唆に富むものでした。
agy は、実際に文字起こしを「やってのけた」のです。能力そのものは本物でした。ところが、その中身を覗いてみて、私は手が止まりました。agy は自分で音声を聞いていたのではなく、私の既存スクリプトを真似て、有料のAI音声APIを呼ぶプログラムをその場で書き、それを実行していたのです。
つまり、課金される場所はまったく同じでした。コストは1円も下がっていません。むしろ agy 自身が考えて手を動かしたぶん、割高ですらありました。
念のため、条件を変えてもう一度試しました。「外部の有料APIは一切使わず、君自身に組み込まれた力だけで、この音声を読んでほしい」と制約をかけたのです。agy の答えは、潔いものでした。
「不可です。unsupported mime type（音声形式に対応していない）というエラーが出て、自前ではこの音声ファイルを直接読み込めません」
ここで得た学びは、こうです。重い処理を「別のAIに振れば安く済む」わけではない。 私の議事録の仕組みは、すでに最適な場所で動いていて、agy を間に挟んでも得をしませんでした。
そして、もうひとつ。うまくいっている仕組みは、変えない。 これは、3,000万円の失敗が私に刻んだ教訓そのものです。あのときも、「新しく作ること」に意味があるのではなく、「使えるかどうか」がすべてでした。今回も同じです。流行りのツールで、すでに回っているものを「置き換える」のは、たいてい逆効果なのです。
検証2：では、この道具の「本当の得意」はどこにあるのか
向いていないことがわかったので、今度は逆に、「これなら得意なはずだ」というタスクで測ることにしました。
題材にしたのは、私が開発で長年大事にしている“コツ”のひとつ、「1ファイル300行ルール」です。ひとつのファイルが300行を超えたら、肥大化のサインとして分割を検討する。コードを見通しよく保ち、AIにも人間にも読みやすい状態を守るための、私なりの規律です。この“300行チェック”は、私の開発ワークフローでは専用の独立した仕組みとして切り出してあります。今回は、その点検作業を agy に走らせてみました。
進め方は、検証の王道です。先に「正解」を機械的に確定してから、agy に同じ作業をさせ、答え合わせをする。
私が自分で機械的に数えた正解は、対象フォルダのなかに300行を超えるファイルが13個。これが動かしようのない事実です。
agy の結果は、こうでした。13個すべてを発見。行数も全件、私の計測と一致。見落としゼロ、誤検出ゼロ。さらに agy は、「これはマークアップ用のデータファイルだから分割は不要」「これは静的な表示部品だから、むしろ分割しない方が見やすい」と、分割すべきかどうかの判断まで、正しく付けてきました。
しかも今回は、Claude Code 本体の利用枠を一切使わずに完結しました。ここが地味に重要です。
ここで、もう一段ふみこんだ話をします。Claude Code のような対話型のAI開発ツールには、一定時間あたりに使える量の上限、いわゆるレート制限があります。集中して作業していると、この制限に当たって、手が止まることがあります。agy は、それとは別系統の枠で動きます。つまり、Claude Code がレート制限で詰まっているときでも、こうした自己完結した機械作業は agy 側に逃がして、手を止めずに並行で進められるのです。
ここで得た学びは、こうです。agy の価値は「検出」そのものよりも、自己完結した機械的な作業を、Claude Code の枠とは別系統でこなせることにあります。レート制限の「逃がし先」と言ってもいい。ただし、最終的な判断、つまり本当に分割するのか、どう直すのかは、上位のAIや人間が握るのが安全です。下書きは別系統の安いラインで、判断は本丸で。この役割分担が肝でした。
検証3：「数十並列で総点検」のような大技は任せられるか
私はふだん、別の作業で、AIの分身であるサブエージェントを数十個、並列で起動して、製品の全ページを一気に点検・修正させることがあります。もしこれを agy に置き換えられたら、相当に強い武器になります。
ところが、ここで agy は壁に当たりました。agy は、同時に2つまでしか並列で動かせない仕様だったのです。内部の仕組みが競合してしまうためです。数十並列の大技には、構造的に向いていませんでした。
面白かったのは、その後日談です。例の、AIに詳しい経営者仲間が、自分の運用ルールを一枚の表にまとめて見せてくれました。そこには、こう書いてありました。「agy は並列2つまで」。
私が自分の手でぶつかった限界と、その道のヘビーユーザーが実運用で敷いていたルールが、寸分たがわず一致していたのです。さらにその表では、最上位の高性能モデルは「ここぞ」という判断にとっておく、まとまった単純作業のバッチはクラウド型のエージェントである Jules に投げる、大量処理は Gemini 系で量をこなす、というふうに、「タスクごとに、いちばん適した道具へ振り分ける」設計になっていました。私が半日の検証でたどり着いた絵と、見事に同じだったのです。
ここで得た学びは、こうです。道具には、向き・不向きがあります。agy は「小さく自己完結した作業を、別系統で」担当する、レート制限の逃がし先です。一方で、「大規模・並列・本番反映・一貫性」が求められる仕事は、まったく別の道具の土俵でした。私の場合は、Claude Code 自身のサブエージェントの出番です。
ここまでの検証を、一枚の表に整理しておきます。
| 道具 | 動く場所 | 役割 | 得意なこと | 向かないこと |
|---|---|---|---|---|
| Claude Code | 手元 | 司令塔・設計・最終判断 | 質の高い設計、対話しながらの作り込み、数十並列の総点検 | ── |
| Antigravity CLI（agy） | 手元 | 機械作業の逃がし先 | 自己完結した点検・整形を別系統で。Claude Code のレート制限対策 | 音声などの専用処理、数十並列、最終判断 |
| Jules | クラウド | 非同期バッチ | テスト・更新・移行を、PCを閉じていても進める | 対話的な判断、即時性 |
比較してわかるのは、どれが優れているか、ではありません。どれを、どの仕事に充てるかです。
Flow Coding を「使い分け」でアップデートした
検証を踏まえて、私の開発フローはこう進化しました。土台は変えません。claude.ai で構想し、Lovable で土台を生成し、Claude Code で作り込む。この本流はそのままに、下に2本の「手」を生やすイメージです。
ひとつは、ローカルで即時に動く別系統の手として、Antigravity CLI。小さく自己完結した機械作業を、Claude Code 本体の枠を使わずに回す。レート制限の逃がし先です。
もうひとつは、クラウドで非同期に動く手として、Jules。テストや依存関係の更新、コードの移行といった、重いけれど自己完結したバッチを、自分が寝ているあいだにも進めてもらう。
そして、司令塔は Claude Code のまま。質・設計・最終判断は、ここでケチりません。音声処理のように、すでに最適な仕組みが回っているものは、無理に置き換えない。
ポイントは、「最新を全部入りにする」のではなく、役割を決めて棲み分けることです。新しい道具は、万能の置き換えではなく、適材適所の選択肢が一つ増えた、ということ。この感覚を持てるかどうかで、AIの使いこなしは大きく変わります。
これは結局、「AIセミナーは入口」という話だ
ここまで読んで、勘のいい経営者なら気づかれたかもしれません。これは、ツールの話に見えて、実は経営の話です。
私がずっと言い続けていることがあります。AIセミナーは入口。でも、入口で止まっている会社が多すぎる。
「これからはAIだ」「うちもAIを導入しよう」。セミナーや記事で、そう聞いて動き出すこと自体は、すばらしいことです。けれど、そこで止まってしまう会社が、本当に多い。ツールを契約して、アカウントを作って、少し触って、「思ったほどでもなかったな」と放置する。これは、入口に立っただけで、中に入っていない状態です。
今回の私の半日も、構造はまったく同じでした。「Antigravity を繋げば爆速になる」という入口の情報があり、そこで止まれば「便利そう」で終わっていた。でも、実際に自分の現場で動かし、音声は任せられない、コストは下がらない、並列は2つまで、という現実を一つずつ確かめて初めて、「では、どこで使えば効くのか」という活用の地図が描けたのです。
導入と活用は、別物です。導入はお金を払えば誰でもできます。活用は、自分の現場で手を動かし、損得を測り、使い分けを決めて初めて手に入ります。そして、この「使い分けを決める」という工程こそ、多くの会社がすっぽり抜かしてしまう部分なのです。
なぜ、「手を動かす伴走者」が必要なのか
では、その「使い分けを決める」工程を、誰が担うのか。
ここに、私が BANSOU CTO™ というサービスを通じて、経営者にお伝えしたいことの核心があります。
世の中には、技術アドバイザーや、助言だけをくれる外部の専門家がたくさんいます。「AIを使いましょう」「このツールがいいですよ」と教えてくれる。それ自体に価値はあります。けれど、今回の検証で痛感したのは、「どのツールを、どの仕事に充てるか」という判断は、実際に手を動かして検証した人にしか下せないということです。
音声は任せられない。これは、実際に投げてみて、生成されたプログラムの中身まで覗いた人にしかわからない。並列は2つまで。これは、数十並列を走らせようとして壁にぶつかった人にしかわからない。机上の「べき論」では、絶対に出てこない結論です。
私が提供している BANSOU CTO™ は、助言だけのCTOではありません。経営者の隣で、実際に手を動かし、技術を検証し、自社の仕組みとして実装まで持っていく、伴走型のフラクショナルCTOです。正社員のCTOを採用すれば月80万から125万円、採用リスクも背負います。一般的な外部CTOは助言はくれても、実装はしてくれません。手を動かし、内製化まで伴走する。そこが、私がこだわっている一点です。
AIで人を雇う前に、AIで会社の仕組みを作る。そのためには、入口で止まらず、検証し、使い分けを決め、実装する人間が要ります。今回の半日の検証は、まさにその縮図でした。
もうひとつの財産 ── 経営者の「仲間」という存在
最後に、技術とは別の、でも私にとっては同じくらい大切なことを書かせてください。
そもそも今回の検証は、経営者仲間との、何気ない雑談から始まりました。公式ドキュメントを何十時間も読み込む前に、信頼できる仲間の「これ、実際に使ってるよ」という一言があった。実際にお金と時間をかけた人のリアルな一次情報ほど、検証の起点として速くて確かなものはありません。
一人で経営をしていると、視野はどうしても、自分の業界、自分の手元に閉じがちです。情報は入ってくるけれど玉石混交で、何が本当に効くのかは、自分ひとりでは見極めにくい。
経営者は、孤独です。
そんなとき、業種は違っても「同じ経営者」という立場で、本音と実体験をフラットに交換できる仲間がいることの価値は、計り知れません。利害がフラットだからこそ、お世辞でも売り込みでもない本音が聞ける。お互いに事業をやっているからこそ、抽象論ではなく「やってみた結果」を共有できる。異業種だからこそ、自分の業界の常識の外にあるヒントが手に入る。
今回の半日のR&Dも、元をたどれば仲間のひと言がきっかけでした。そして私も、自分が実機で確かめた使い分けの結論を、次に会うときの手土産として持ち帰ります。与え合い、確かめ合う関係が、そこにはあります。
だからこそ私は、経営者にこそ、利害を超えて本音で語り合える仲間が必要だと思っています。孤独になりがちな経営において、それは情報源であり、壁打ち相手であり、ときに自分を一段引き上げてくれる環境そのものです。新しい技術への感度も、こうした場から生まれ、磨かれていきます。良い道具と、良い仲間。どちらも、経営を前に進めてくれる大切な資産です。
おわりに ── あなたの会社は、ツールを「入れて」止まっていないか
AIをめぐる道具は、日進月歩で新しいものが出てきます。だからこそ、「全部入れる」のではなく、「自分の実務で測って、使い分ける」姿勢が、限られたリソースで複数の事業を回す上では、いちばん効くと私は感じています。
そして、その感度やきっかけの多くは、信頼できる仲間との対話から生まれ、その判断は、実際に手を動かす検証からしか得られません。
あなたの会社は、いま、どうでしょうか。新しいツールを契約だけして、入口で止まっていないでしょうか。それとも、自分の現場で動かし、使い分けを決め、活用まで進められているでしょうか。
もし、入口から先に進む手応えが欲しいと感じたなら、それは、伴走者を持つタイミングなのかもしれません。
この記事のポイント
- 最新のAI開発ツールは「足せば速くなる」とは限らない。今回の実機検証では、音声処理は任せられず、コストも下がらず、並列は2つまでという限界が見えた。大事なのは導入そのものではなく、タスクごとの使い分けである。
agy（Antigravity CLI）の本当の価値は「安さ」ではなく、Claude Code のレート制限の逃がし先として、自己完結した機械作業を別系統で回せること。判断は本丸のAIや人間が握る。- 推測ではなく実機検証で決める。動かして初めて見える現実があり、それが活用の地図になる。AI活用に詳しい仲間の運用ルールとも、私の検証結果は一致した。
- 「どのツールを、どの仕事に充てるか」という判断は、手を動かして検証した人にしか下せない。助言だけのCTOではなく、実装まで伴走する BANSOU CTO™ が要るのはそのためだ。
- AIセミナーは入口にすぎない。入口で止まらず、検証し、使い分けを決め、活用まで進めること。そして、それを支える経営者の仲間という財産を持つこと。
伊藤翔太 株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー 代表取締役