AIに実データベースを触らせるのは怖いので、Junie × DataGripの承認フローを実機で検証した

はじめに

Junie が正式版の発表時に、こんな一文がありました。

Database integration. Junie connects to the databases configured in your IDE through DataGrip and the JetBrains Database plugin, and then it queries your real data and writes, fixes, and validates SQL in the same session that handles your code.

「IDE に設定済みのデータベースに繋いで、実データを照会し、SQL を書く・直す・検証する」とありましたが、

• AI に本物のデータベースを触らせて大丈夫なのか？うっかり DELETE を流されたら？

• DB に繋いだら、中身が外部 LLM に送られるんじゃないのか？

などと思いました。
そこで、今回はテスト用の SQLite DB を作って Junie に読み・書き・スキーマ変更を実機で確認しました。

1. 承認は「データ読み／データ書き／スキーマ読み／スキーマ変更」の4種に分かれている
2. データ読み取りの承認には「そのデータを AI モデルに送信します」と明記される
3. Junie の Brave Mode（承認スキップ）をオンにしても、DataGrip 側の DB 承認は出続けた

以下、順に何を投げて何が出たかを書きます。本番 DB は使っていません。

試した環境

Junie が独自に DB 認証情報を持つわけではありません。DataGrip の Database プラグインに内蔵された MCP サーバー経由で、IDE に登録済みの Data Source を操作する構造です。承認もこの MCP サーバー側で握られています。

• 製品: DataGrip 2026.1（DB データ操作用の MCP 機能はこのバージョンで追加された）
• AI エージェント: Junie（DataGrip の AI Chat 内で選択。モデルは GPT-5.5 / High effort）
• consent（承認）設定の場所: 設定 | ツール | データベース | AI ツール（Settings | Tools | Database | AI Tools）

DataGrip 側の MCP サーバーが公開している DB 操作は、接続設定の取得・スキーマ一覧・オブジェクト参照・実行中クエリ確認・SQL の実行/キャンセル・テーブルプレビュー/CSV 取得など。これらに対して、既定で4種類のユーザー承認が要求されます（スキーマ参照 / データ参照 / スキーマ変更 / データ変更）。

試したこと

1. テスト用DBの作成

今回はテスト用の SQLite DB を用意しました。SQLite なら DataGrip でファイルを新規作成しました。

データソースの作成 → SQLite で作成。接続後、クエリコンソールで顧客2人・注文3件のテスト用データを入れます。

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, email TEXT);
INSERT INTO customers (name, email) VALUES ('Alice','[e-mail]'), ('Bob','[e-mail]');
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);
INSERT INTO orders (customer_id, total) VALUES (1, 1200), (1, 800), (2, 500);

2. まず「読むだけ」を投げてみる

手始めに Junie に聞きました。

junie_test データベースの customers テーブルには何件データがありますか？実際にクエリを実行して答えてください。

すると Junie は database-text-to-sql という内部スキルを読み込んだあと、datagrip/execute_tool を呼び出そうとし、承認ダイアログが出ました。

このステートメントはデータベースのデータを読み取ります。Junie はそのデータを AI モデルに送信します。

中身が外部 LLM に渡ることまで明示して同意を取ってきます。対象 DB・スキーマ・実行しようとしている SQL 全文（SELECT COUNT(*) AS customer_count FROM customers;）も見えます。ここで「許可」を押すと、2件と正しく返ってきました。

Junie が発行した SQL は execute_sql_query --connectionId ... --queryText 'SELECT COUNT(*)...' という形でチャットログに残ります。

3. JOINで集計させる（SQL生成）

次は集計を投げます。

customers と orders を JOIN して、顧客ごとの合計注文額を多い順に出してください。

Junie の回答

SELECT c.name, SUM(o.total) AS total_order_amount
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY total_order_amount DESC;

結果は Alice: 2000 / Bob: 500。（Alice は 1200+800）。

• Allow running MCP?（Yes / No / Always allow "datagrip:execute_tool"）… Junie 側の「MCP ツールを実行して良いか」の承認
• データ読み取りを許可（許可 / 拒否）… DataGrip 側の DB consent

エージェント側とツール側で承認レイヤが分かれている、ということがわかります。

4. データを書き込ませる（データ変更）

読み取りが通ったので、書き込みを投げます。

customers テーブルに、名前 Carol、メール [e-mail] の顧客を追加してください。

ここで出た承認ダイアログは、読み取りのときとはちがう文言がでました。

このステートメントはデータベースのデータを変更します。Junie が、INSERT、UPDATE、DELETE ステートメントを実行したり…このスキーマ内のデータを変更することを許可しますか?

4種 consent が読みと書きで分岐していることが確認できました。

業務導入を考えるうえで安心できたのはここです。「AI には読ませるけど、書き込みは毎回自分が承認する」という運用が設定で成立します。

Junie が自分でSQLのミスを直した

この書き込みテストで、Junie は1回目に失敗しています。

チャットログを見ると、最初の INSERT はこうなっていました。

-- 1回目（失敗）
INSERT INTO customers (name, email) VALUES (Carol, [e-mail]) ...

文字列なのにクォート（'...'）が無い。これは構文エラーで、Junie 自身も

指定した顧客の追加を試みましたが、SQL文の構文エラーにより実行が失敗しました。データベースは書き込み可能な状態でした。

と報告していました。そしてそのまま自動で修正して再実行しました。

-- 2回目（成功）
INSERT INTO customers (name, email)
VALUES ('Carol', '[e-mail]')
RETURNING id, name, email;

これが、冒頭の引用にあった「writes, fixes, and validates」の実物です。

• fixes: クォート漏れのエラーを、実行結果を見て自力で修正
• validates: RETURNING を付けて、追加された行（id=3, Carol）を取り返して検証

「AI が DB を触る」というと万能な自動化を想像していましたが、実際は AI も普通に SQL を間違えます。だからこそ、間違いを実行してしまう前に人間が承認する consent 設計に意味があるとわかりました。

最後に SELECT * FROM customers; で Alice / Bob / Carol の3行を確認して、読み・書き・生成・自己修正の一通りが揃いました。

ソースコードを起点にDBを変更させる

ここまでは DB 単体の操作でした。次はソースコードを読ませて、それをもとに DB を変えられるかを試します。

まず、DB 側にはまだ無い phone フィールドを持つモデルを1つ用意します。

# Customer.py
class Customer:
    id: int
    name: str
    email: str
    phone: str   # customers テーブルにはまだ無いカラム

このプロジェクトの Customer.py クラスのフィールドを確認して、junie_test の customers テーブルに不足しているカラムを追加してください。

と投げまました。

1. Customer.py を読む（コードのフィールドを把握）
2. DB のスキーマを読む。ここで承認が出ました

Junie がデータベーススキーマを読み取ります。Junie がこのスキーマを読み取ることを許可しますか?

1. コードと DB を突き合わせ、差分を説明する

• Customer.py の Customer クラス: id, name, email, phone
• 現在の customers テーブル: id, name, email
• 不足しているカラム: phone
phone は Python 側で str 型なので、SQLite では TEXT として追加します。制約やデフォルト値はコード側に指定がないため、既存行への影響を避けるため nullable のまま追加します。

str だから TEXT、デフォルト指定が無いから既存行を壊さないよう nullable のまま、とコードの型を根拠に SQL を組み立てています。

1. ALTER TABLE customers ADD COLUMN phone TEXT; を実行しようとして、また別の承認がでました

このステートメントはデータベースのスキーマを変更します。Junie が、CREATE、ALTER、DROP ステートメントなどを実行して、このスキーマを変更することを許可しますか?

先ほどのデータ変更（INSERT/UPDATE/DELETE）とはまた文言が違い、こちらはスキーマ変更（CREATE/ALTER/DROP）です。許可後、customers に phone 列が追加されたことを確認しました。

これで4種の承認がすべて出そろった

この一連のテストで、4種の consent が全部、実機で確認できました。

承認の種類	どんな操作で出たか	ダイアログの文言（要約）
データ参照（Data access）	件数照会・JOIN	データを読み取り、AIモデルに送信します
データ変更（Data modification）	Carol を追加	INSERT / UPDATE / DELETE でデータを変更します
スキーマ参照（Schema access）	コードとDBの差分確認	データベーススキーマを読み取ります
スキーマ変更（Schema modification）	phone 列を追加	CREATE / ALTER / DROP でスキーマを変更します

「データを読む」「データを書く」「構造を読む」「構造を変える」が別々の承認になっている。AI にどこまで任せるかを、この粒度で決められます。

Brave Mode をオンにしても DB の承認は出た

Junie には Brave Mode（操作の承認をすべてスキップするモード）があります。

これをオンにして同じ操作を試したところ、

• Allow running MCP?（Junie 側の承認）は出なくなった（自動許可される）
• DataGrip 側の DB データアクセス承認は、Brave Mode をオンにしても出た

うっかり Brave Mode のまま DB に繋いでも、少なくともデータアクセスの同意は残る。
ただし確認したのは DataGrip 2026.1 + SQLite の組み合わせだけです。あわせて、ターミナルやファイル操作は Brave Mode でスルーされるので、DB 以外も考えるとオフが無難です。

まとめ

Junie の DB 連携は、「AI に実データを触らせる」という一見こわい機能を、読み/書きで分かれた4種の承認と、Junie 側・DataGrip 側の2層で囲った作りでした。
データ読み取りの同意画面に「AI モデルに送信します」と明記されるので、外部に何が出るかも承認時点で判断できます。

AI も普通に SQL を間違えてることが見えたので、consent を外す運用は取らないほうがいいというのが今回の実感です。

まずは本番 DB には繋がず、テスト用 DB で試すとこの機能への解像度が上がるはずです。

ナットウシステムからのお知らせ

弊社は JetBrains 製品に関するご質問、ご相談等を受け付けております。弊社のXまたはメールでご連絡ください。

参考資料