R言語 Advent Calendar 2025 21日目の記事です。
はじめに
筆者は生成AI自体こそ日常的に使っていますが、この１、２年に現れたVibeコーディングだのMCPだのといったモダンな技術には触れておらず、時代にまったくついていけていません。ちょっと良くないなー、と思っていた頃にちょうどGoogleからAIコーディングツール「Antigravity」が発表されました。
ということで、この記事ではAntigravityからRを操作する流れについて整理し、実践例として簡単なShinyアプリケーションを作成し、所感を言語化しました。
筆者のスペックは、
- バイオ寄り分野での研究利用メインでR歴10年くらい
- データスクレイピング、APIいじり、各種可視化、Shinyはお遊び含め一通り経験あり
- Rstudioユーザ、VSCodeは触れたことなし
- Apple SiliconのMac環境
導入
Antigravityのインストール
公式サイトからインストーラをダウンロードし、インストールします。設定のバリエーションがいくらかありますが、全てデフォルトのままで進めました。
Antigravityの利用にはGoogleアカウントが必要です。Googleアカウント連携が済むと準備完了で、以下のような画面になります。
基本的なフローは以下の通りです。
- 右側のチャットのペインでお願いをする
- AIが整理した作業の流れ (task.md) や実装プラン (implementation_plan.md) が表示される
- 実行 (Proceed) すると、上記プランにそって作業が進められる
- 必要に応じてユーザの承認 (Accept) が要求される
- 報告書 (walkthrough.md) が生成される
バックエンドになる生成AIはいくつかあり、今回使ったのはデフォルトのGemini 3 Pro (High)です。とくに指定をしないと/Users/{USENAME}/.gemini/antigravityでの作業になるようです。
Rとの連携・セットアップ
「インストールされているRとパッケージを使える状態にセットアップして」とお願いすると、よしなに整えてくれました。
タスクが整理され、
必要なExtentionがサジェストされ、
テストコード案が生成されるので、これをAcceptします。
Rstudioと同様に、interactiveなコンソールが表示され、Cmd+Enterで一行ごとの実行が可能です。パッケージを含め、普段づかいのR環境がそのまま使えることが確認できます。
RmarkdownやQuartoファイルからのhtml、pdf等のレンダリングにも対応しています。.rmdのknitはRstudioで慣れ親しんだ Cmd+shift+K でいけますが、.qmdはショートカットが効きませんでした。terminalでquarto rendar file.qmdコマンドを直打ちするか、チャットで「レンダーして」とお願いすればレンダリングできるようです。
実践
一例として、航空券チケット価格比較のためのShinyアプリケーションを作りました1。
アプリ要件と必要技術
要件は以下の通りです。
- ユーザが往路・復路の日付を指定すると、指定両日全便について運航会社、予約変更の可否 (flex/fix)、出発時刻とチケット料金をwebから取得
- 往路・復路の出発時間が縦横軸、合計料金がセル色にマッピングされたヒートマップ風に可視化
- 出発時刻・予約変更の可否でのフィルタリング
- ヒートマップへのマウスオーバ時にツールチップで情報が表示される
これを実現するには、ざっくりと以下のような技術が必要になります。
- 適当なwebサービス、APIからの航空券情報の取得 (rvest, httr)
- 航空券情報の下処理 (tidyverse) と可視化 (plotly)
- インタラクティブなアプリケーション化 (shiny)
実際の流れ
初手プロンプトは以下の通りです。まずは自分の需要に応じて、新千歳起点の羽田往復に限定しています。
新千歳-羽田の航空券のチケットの料金を比較するアプリケーションを作りたい。
往路・復路の日付から、両日の全直行便の出発時間、運航会社、予約後変更の可否、料金をwebから取得する。
往路・復路の出発時間をxy軸、セルカラーを合計料金としたヒートマップ風のプロットを作る。
ヒートマップへのマウスオーバー時にツールチップで詳細情報を表示。
Shinyアプリ化し、出発時間と予約後変更の可否でフィルタリング機能を追加。
それっぽい感じでTaskが作られます。
Implement Data Fetching/Mocking Moduleのところがポイントで、実データ取得ができないことを想定し、仮データ (Mock data) でUIを作るという方針を立てています。とくにこちらからは指定していませんが、気が利いていると感じました。
このTaskに沿ったImplementation planが示されたので、それを実行しました。
仮データを使ったShinyのapp.Rが一発でできたので、runAppしてみたところ以下のような結果でした。UIはほぼイメージ通りでしたが、plotlyのheatmap部がなんだか変です。
なんとなく時刻であるべきx軸・y軸がdatetimeになっているような気がします。ちょっと修正をお願いしましたがぐだぐだだったので、引っ掛からなさそうな「ggplot2で作図し、ggplotly()でplotlyに変換する」というアプローチを採用しました。
おけ、いまいちだから一旦可視化はggplot2にして。ツールチップとかは無視。
想像通り、ggplot2だとすんなり動きます。
チャットのペインにさらっと「geom_pointを使って~」とあるので、geom_tileにしたうえで、plotlyに変換するようお願いします。内容をある程度まで正確に把握するためには目grepが要求されることになります。
おけ、geom_tileにしてからplotlyに変換して。
とくに指定はしませんでしたが、覚えていたようでツールチップも実装してくれました。
見栄えを少し整えました。
changeable/non-changeableは往路復路別に設定できるように。
で、shinydashboradにして見栄えを整えて。
次は航空券の実データを取得する流れになります。
デザインは一旦OK。
APIなりweb検索なりで実際のチケットの情報を取得したい。
プランをいくつか出して。
生成AIでよくある出力、という感じで特筆事項はありません。
オススメされたamadeusというAPIサービスを使う旨をchatペインで伝えておきました。ユーザ登録後にAPIキーを発行し、環境変数として保存します。
Sys.setenv(AMADEUS_CLIENT_ID = "YOUR_KEY", AMADEUS_CLIENT_SECRET = "YOUR_SECRET")
ユーザ登録やらの間に、すでにamadeusAPI用の関数群が整備されており、Shinyアプリケーション用のapp.Rはそれらに対応してamadeusのデータを受け付ける準備を終えています。なので、なにも考えずrunApp()でOKでした。
最終版のアプリケーションは、amadeus APIが使えるならamadeusから、使えないならmockデータからヒートマップを作成します。なぜか発着地点選択もできるようにされています。
雑感
想像よりだいぶ優秀で驚きました。適切な航空券APIを見つけてきたり、ほぼノーエラーでコードを出してくるあたりは既存の生成AI系のサービスから想像される範疇です。しかし、これを実装プラン駆動で自発的に動かせるのが大きいです。指示されていないのにモックデータ生成のプランから入ったところなど、痒いところに手が届く気の利きようです。
今回の体験は、ある程度は自発的な部下が作業を進めてくれる感じでした。そのスペックはプログラミング歴が不自然に長い理系修士２年（非コンピュータサイエンス系）くらいでしょうか。ただし、５分未満の間隔で小刻みに確認してくるので、ユーザ側のマルチタスク適正が問われる印象を受けます。
自分が‘通ったことがある道’の亜種を作った今回の実践例のように、実装の流れと詰まりどころがパッと想像できる場合、期待されるおもな恩恵は時短効果です。逆に自分が‘通ったことがない道’を模索する場合でも、修士くらいのパフォーマンスでざっくり通れることは大きな強みになりそうです2。研究者的には、論文関連の作業には使えない3が、ネタ探しのためのプロトタイピング (簡単なシミュレーション) や研究成果の社会実装 (アプリケーション作り) には使えるかも、という結論でした。