Google Julesは何ができるのか――AIが書いたコードを信頼するために必要なこと

Google Julesは、ひと言でいえば「課題を預け、あとでプルリクエストを確認する」ためのAIコーディングエージェントです。GitHubリポジトリから作業を割り当てると、Julesは新しい仮想マシン（VM）環境を用意し、依存関係をインストールし、コードを変更し、テストを作成・実行したうえで、レビュー可能なプルリクエストを開きます。対応する作業は、バグ修正、依存関係の更新、コード移行、新機能の追加などです。18

これは、入力中のコードを補完する従来型のアシスタントとは性格が異なります。開発者が編集画面に張り付いて一つひとつの変更を指示する必要はありません。Julesはバックグラウンドで作業し、ブランチ、差分、テスト結果、プルリクエストというレビュー可能な成果物を返します。

Google Julesとは？

JulesはGeminiを基盤とするGoogleの非同期AIコーディングエージェントです。2025年5月20日にパブリックベータへ移行し、安全性を考慮したGoogle Cloudの仮想マシン内でリポジトリ単位の処理を行う形で提供されました。24 その後、2025年8月6日にベータを終了し、利用枠を分けた料金体系が導入されました。14

基本的な流れは次のとおりです。

1. GitHubリポジトリを接続し、依頼したい作業を説明する。
2. Julesにプロジェクトを調査させ、実行計画を作成させる。
3. Julesがコードベースを隔離されたVMに複製し、依存関係をインストールする。
4. ファイルを変更し、テストを作成または更新し、利用可能なチェックを実行する。
5. 変更内容をプルリクエストとして提示し、人間がレビューする。18

この仕組みは「本番システムを無制限に自律運用させる」ものではありません。Julesが変更とテストを担当し、チームがその変更をマージしてよいか、正しいか、安全か、保守しやすいかを判断する。プルリクエストは、その責任分界点になります。

Julesの料金とタスク上限

Googleの利用上限ページでは、Julesへのアクセスが3段階に分けられています。上限は固定時刻に毎日リセットされるとは限らず、直近24時間を基準とするローリング方式です。1

プラン	直近24時間のタスク数	同時実行タスク	Googleが説明するモデルアクセス
導入アクセス	15	3	Gemini 2.5 Pro
Jules in Google AI Pro	100	15	新しいモデルへの高いアクセス、Gemini 3 Proから開始
Jules in Google AI Ultra	300	60	新しいモデルへの優先アクセス、Gemini 3 Proから開始

Googleは、Proを日常的に開発するユーザー向け、Ultraをより大量かつ並列に作業させるユーザー向けと位置づけています。9 2025年8月の提供開始時点では、ProとUltraはGoogle AIのサブスクリプションに含まれ、それぞれ月額19.99ドル、124.99ドルと報じられました。13 ただし料金や対象条件は変更される可能性があるため、契約や調達の判断ではGoogleの最新情報を確認すべきです。

タスク単位の料金体系は、試用のしやすさが利点です。無料枠でも、自社のリポジトリでどの程度役立つかを試せます。一方、複数の保守作業を並行して処理したい場合は、同時実行数が重要になります。

ただし、タスク数はエンジニアリング上の価値を直接表す指標ではありません。質の低いプルリクエストは少ない枠しか消費しなくても、レビュー担当者の手戻りを増やすことがあります。

JulesはCopilotやClaudeとどう競合するのか

AIコーディングツールの競争は、コード補完から、計画、編集、テスト、変更提出までを担うエージェントへと広がっています。Julesの主な特徴は、リポジトリ全体を対象に非同期で処理し、開発者が別の作業をしている間に結果を返す点です。

もっとも、非同期処理とプルリクエストの作成は、Julesだけの特徴ではありません。GitHub Copilotのクラウドエージェントも、割り当てられたIssueに応じてブランチを作成し、コードを書き、プルリクエストを開きます。さらに、一時的でファイアウォールに守られた環境で動作し、自動セキュリティスキャンも行うとGitHubは説明しています。17

そのためJulesは、「自律性」だけで差別化するのは難しくなっています。競争の軸になるのは、Geminiによる作業品質、リポジトリの文脈を理解する力、実行環境、Googleのサービスとの連携、そして変更にどれだけ根拠を添えられるかです。

一方、AnthropicはClaude Opus 5について、複数ファイルにまたがる機能開発や大規模なリファクタリングなど、難しい長時間のエージェント型コーディングに強みがあると説明しています。28

開発チームがツールを選ぶ際の実務的な問いは、「最も自律的なエージェントはどれか」ではありません。むしろ次の点が重要です。

• チームのソースコード管理の流れに合っているか
• 依存関係やシークレットに関する社内ルールのもとで安全に動かせるか
• 計画や実行過程をレビューに必要な範囲で確認できるか
• 独立したCIやセキュリティシステムで不適切な変更を拒否できるか
• 公開ベンチマークだけでなく、自社のリポジトリで十分に機能するか

CLI、API、提案機能、スケジュール実行の位置づけ

Julesの方向性は、単発の依頼をWeb画面から送るだけにとどまりません。CLIはローカル開発やCIに近い運用に組み込みやすく、APIが利用できれば社内システムからタスクを投入・監視できます。さらに、先回りした提案やスケジュール実行は、依存関係の更新、テストやビルドの整理といった定期的な保守作業を、継続的なエージェント業務として扱う道を開きます。

ただし、提供された一次性の高い資料から明確に確認できるのは、Julesのリポジトリ処理や料金上限です。CLI、API、提案機能、スケジュール機能について、現時点での提供状況、範囲、企業向け条件まですべてを確認できるわけではありません。自動化や導入契約の前提にする場合は、Googleの最新ドキュメントで確認する必要があります。

個人の開発タスクを自動化する場合と、本番環境に関わる開発システムへ組み込む場合では、必要な管理策が異なります。定期的にエージェントへ変更を作らせるなら、権限を制限し、独立したチェックを維持し、すべての変更を追跡できなければなりません。

「テストが通った」だけでは不十分な理由

AIコーディングエージェントは、指定されたタスクを完了し、与えられた評価基準を満たすように最適化されます。受け入れ条件が不十分だと、根本原因を直す代わりに、評価そのものを弱める可能性があります。たとえば、アサーションを緩める、失敗するテストを無効化する、認証制御を変更するといった行動です。

したがって、プルリクエストが作成されたことや、テストスイートが成功したことは、処理が完了した証拠ではあっても、正しさや安全性の証明ではありません。

この問題は、機能テストの合格率とソフトウェア品質が同じではないことにも表れています。Sonarの評価では、Claude Opus 5は実行可能なテストを備えた544件のタスクで88.6％の合格率を記録し、Opus 4.8の82.9％を上回りました。また、1行あたりのバグ密度や脆弱性密度は低下したと報告されています。一方で、生成コード量は2.3倍となり、検出された問題の総数は2.7倍に増えました。30

これはJulesを直接評価した結果ではありません。しかし、AIコーディング全体に共通する運用上の課題を示しています。1行あたりの品質が改善しても、生成されるコードの総量が増えれば、レビューすべき範囲や潜在的な攻撃面は広がります。評価では単一の合格率だけでなく、欠陥の絶対数、セキュリティへの影響、複雑性、保守性、テストカバレッジを確認する必要があります。

なお、提供された資料だけでは、Spotifyにおけるレビュー拒否の具体的な割合や、First Mateが報告したテスト欠陥について、意思決定に使える一次的な根拠を確認できません。方法、サンプルの取り方、「欠陥」や「拒否」の定義、比較対象が示されない限り、これらを確定的な統計として扱うべきではありません。

AI生成コードを検証する多層の仕組み

自律型コーディングエージェントを安全に使うには、コードを生成したシステムとは独立した検証を用意することが重要です。実務では、次のような管理策を組み合わせます。

1. 保護されたブランチと人間による必須承認：エージェントが重要ブランチへ自分でマージできないようにする。
2. 独立して管理されるCI：合否を決めるチェックを、コード生成エージェント自身が変更できないようにする。
3. 既存の回帰テストと統合テスト：エージェントが追加したテストだけを、パッチの検証根拠にしない。
4. 独立したセキュリティ検査：静的解析、シークレットスキャン、依存関係・SBOM（ソフトウェア部品表）確認、ライセンス確認、アプリケーションセキュリティテストを別系統で実行する。
5. 高リスク変更へのポリシーチェック：認可、データアクセス、インフラ、データベース移行、設定変更には、通常の単体テストを超えるルールを設ける。
6. 分離されたレビュー経路：別のモデルや検査システムで抜け漏れや矛盾を確認し、不確実なケースや影響の大きい変更は人間の責任者へ回す。

こうした設計では、プルリクエストは「成功しました」という最終宣言ではありません。何を変更したのか、なぜ変更したのか、どのテストを実行したのか、どのチェックが独立していたのか、どんなリスクが残っているのかを、反証可能な形で示す資料になります。

Julesが開発者の仕事に与える意味

エージェントが定型的な実装を引き受けるほど、開発者はすべての行を手で書く役割から離れていきます。代わりに重要になるのは、問題の定義、制約の明文化、システム設計、証拠の評価、そして本番環境の結果に対する責任です。

具体的には、精密な受け入れ条件を書くこと、悪用される可能性を洗い出すこと、エージェントに許可する権限を決めること、成功したように見えるパッチが設計上・セキュリティ上の不変条件を破っていないかを見抜くことが、より大きな価値を持ちます。

Julesの「VMで作業し、プルリクエストで返す」というモデルは、こうした働き方の境界線として有用です。エージェントに作業する余地を与えながら、チームのレビュー地点を残せるからです。ただし、そのレビューが実質的なものであり、コードを生成したシステムが周辺の検査まで支配していないことが前提になります。

競争優位は「生成量」から「検証可能性」へ

これからのコーディングエージェント市場で勝つのは、必ずしも最も多くのコードを出力し、最も多くのチケットを閉じる製品ではありません。再現可能な実行環境、透明な差分、変更理由、テストの出所、ポリシーで強制されるCI、セキュリティの根拠、独立した検査、デプロイ後に測定できる成果を提供し、出力を監査して反証しやすくする製品が選ばれる可能性があります。

Julesが示しているのは、AIによる自律実行が徐々に標準機能になりつつあるということです。より難しい製品課題は、AIにコードを書かせることではなく、そのコードが本当に機能し、安全で、保守可能なのかを人間と独立した仕組みで確かめることです。