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アプリケーションを作りました¹。

アプリ要件と必要技術

要件は以下の通りです。

ユーザが往路・復路の日付を指定すると、指定両日全便について運航会社、予約変更の可否 (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系のサービスから想像される範疇です。しかし、これを実装プラン駆動で自発的に動かせるのが大きいです。指示されていないのにモックデータ生成のプランから入ったところなど、痒いところに手が届く気の利きようです。

今回の体験は、ある程度は自発的な部下が作業を進めてくれる感じでした。そのスペックはプログラミング歴が不自然に長い理系修士２年（非コンピュータサイエンス系）くらいでしょうか。ただし、５分未満の間隔で小刻みに確認してくるので、ユーザ側のマルチタスク適正が問われる印象を受けます。

自分が‘通ったことがある道’の亜種を作った今回の実践例のように、実装の流れと詰まりどころがパッと想像できる場合、期待されるおもな恩恵は時短効果です。逆に自分が‘通ったことがない道’を模索する場合でも、修士くらいのパフォーマンスでざっくり通れることは大きな強みになりそうです²。研究者的には、論文関連の作業には使えない³が、ネタ探しのためのプロトタイピング (簡単なシミュレーション) や研究成果の社会実装 (アプリケーション作り) には使えるかも、という結論でした。

Enjoy!

航空券キュレーション系のサイトは複数あるが、金額と出発時間の関係が視覚的に捕みづらい... ↩
中身を完全には理解しない想定なので、ミスが致命的になるものではなく、遊び・便利ツールくらいでの利用には限定される。 ↩
研究だとルーティン的に同じ解析をすることはまずなく、初見データに対する外れ値除去だとかデータ分布確認だとかの諸対応は自分でやったほうが早くて高品質。あとtidyverseでデータを捌くのは単純に気持ちがいい。 ↩