2025年のGoogle I/Oで発表された、非同期AIコーディングエージェント「Jules」。
今回、このJulesを使ってAndroidアプリとサーバーサイド(Python)を開発し、Google Playでの公開まで完了させることができました。
結論から言うと、Julesにはいくつかの課題も見られるものの、Googleのベータ版製品であることを考えれば、将来が楽しみなサービスだと感じています。何より、実際にアプリケーションを一つ、サーバーサイドも含めてリリースまでこぎつけられた事実が、そのポテンシャルの高さを示しています。
本記事では、開発したアプリの紹介から、Julesを実際に使ってみて感じた良い点、そして「ここは改善してほしい!」と感じた点まで、率直な感想をまとめます。Julesがどんなものか、気になっている方の参考になれば幸いです。
開発したアプリケーション:「Integrity Check Tool」
まず、今回開発したAndroidアプリについて簡単に紹介します。
「Integrity Check Tool」は、Androidアプリ開発者向けの検証ツールです。Play Integrity APIのような端末の信頼性を検証する機能が、自身の端末や開発中のアプリでどのように動作するかを確認することを目的としています。
※ アプリ名が直接的すぎて他の開発者のツールと区別がつかないので、後日変更する可能性があります。
主な機能
- 端末信頼性検証の確認: 利用しているAndroidデバイスが、GoogleのPlay Integrity APIによってどのように評価されるか、その詳細な結果(デバイスの完全性、アプリのライセンス状況など)を表示します。
- 開発・デバッグ支援: なんらかの端末でPlay Integrity APIに起因する可能性のある不具合が報告された際に、このアプリをインストールして結果を共有してもらうことで、原因の特定や問題の切り分けに役立てることも想定しています。
- 技術理解の促進: 端末の信頼性検証がどのような仕組みで動いているのか、APIから返却される情報が何を意味するのかを理解する一助となります。
このツールは、開発者が自身の開発環境で手軽に検証を行うことを主眼に置いており、プロジェクトはオープンソースとしてGitHubでコードを公開しています。
注意点:
- このアプリはあくまで検証結果を表示するためのものであり、端末のセキュリティを向上させる機能はありません。
- 表示される結果は、お使いのデバイス、OSバージョン、ネットワーク環境などによって異なる場合があります。
開発の背景
開発の直接的なきっかけは、2025年5月20日にPlay Integrity APIの仕様変更が発効したことでした。
Play Integrity APIは、アプリのバックエンドサーバーに組み込まれていることが多く、その動作を正確に検証するには、クライアント(アプリ)とサーバーの両方を含めた一貫した環境が必要になります。
今回の仕様変更に伴い、クラシックAPIリクエストと標準リクエストの両方について、手元で確実かつ手軽に検証できる環境が欲しい、というのが開発の動機でした。
Julesを選んだ理由
Julesのことは、今年のGoogle I/Oに参加したときに知りました。
筆者はこれまで、本格的にAIエージェントを開発に利用したことはありませんでした。 業務で関わっているプロジェクトの多くはセキュリティポリシーの観点から導入が難しく、かといって個人プロジェクトは過去からの積み重ねがあるため、導入に適したものがなかったためです。
その点、今回はまったくの新規アプリ開発であり、開発規模的にもJulesを試すのに最適と考えました。
Julesを使ってみた所感
Julesと実際に開発してみて感じたのは、「完璧な自動コーダー」というよりは 「癖はあるが有能なアシスタント」と協業している 、ということです。
便利な点 (Pros)
✅ タスクベースの開発と役割分担
「この機能を追加して」とタスクを提示すると、Julesは現在のコードベースを解析し、作業をいくつかのステップに分解して提案してくれます。
この「タスクを依頼してお任せできる」スタイルは、日々の開発フローにうまくフィットします。簡単な指示であれば、食事や少しの休憩時間を使ってJulesにお願いできます。一方、Julesが苦手とするような込み入ったエラーが発生すれば、夜などに腰を据えて自分でじっくり対応する、といった役割分担が可能です。
ちなみに、最初はあまり気にせずApprove(承認)していましたが、この提案段階で内容をしっかり確認し、必要に応じて調整することで、最終的に生成されるコードの品質が大きく変わってきます。
さらに、2025年6月27日からは作成したIssueの対応もJulesに依頼できるようになったため、こうした連携がよりスムーズになりました。
Jules now listens to GitHub issues.
— Jules (@julesagent) June 26, 2025
Add the 'jules' label to any issue and your task kicks off automatically
No context switches. Just label and go.
Make sure the Jules GitHub App has access to your repo, then let the magic happen. pic.twitter.com/zYCJdLChue
✅ コードベースの成長に応じた適応
Julesは、コードベースの規模が一定に達したところで、よりコンテキストにあった動作をするようになる、という興味深い傾向が見られました。
たとえば、開発初期にはモジュールのnamespace
がcom.example
になってしまうことがありましたが、プロジェクトの構造が整ってくると、他のモジュールの命名規則を自律的に読み取り、指示しなくても適切なnamespace
を付けてくれるようになりました。
この挙動から、AIエージェントは小規模な新規プロジェクトだけでなく、ある程度成熟したコードベースに導入する方が、その真価を発揮するのかもしれない、と考えさせられました。
✅ マルチ言語、インフラ領域のサポート
今回はAndroid(Kotlin)とサーバーサイド(Python)を同時に開発しましたが、Julesは両方の言語に対応してくれました。 特にサーバーサイドは、エンドポイントと簡単な入出力の型、想定している動作を定義するだけで、大部分の実装を任せることができました。
さらにJulesは、コード記述以外もサポートしてくれました。Google Cloud Runへのデプロイガイドの作成や、GitHub ActionsのCI/CDパイプライン構築も手伝ってくれたりしました。サーバーサイドのプログラムからOpenAPI(Swagger)の定義ファイルを出力して、Swagger UIで動作テストができる状態まで整えるなど、自身の専門外の領域もカバーしてもらえるのは、開発者にとって大きな助けとなります。
改善してほしい点 (Cons)
便利な一方で、まだまだ発展途上だと感じる部分も多くありました。
❌ 日本語入力との相性
これは日本のユーザーにとってかなりクリティカルな問題かもしれません。Julesにタスクを依頼した後、チャット形式で対話できるのですが、PCブラウザだと日本語入力中にEnterキーを押すと、変換の確定ではなくメッセージが送信されてしまいます。
これを回避するためには、一度日本語入力をOFFにしてからEnterを押し、またONにして続きを書く…という手間が必要でした。
不思議なことに、スマートフォンで開くとこの問題は発生しません。しかし、今度はスマートフォンでタスク内容を入力しようとすると、文字が重複して入力されたり、入力カーソルが勝手に文末に移動したりと、別の問題に遭遇しました。
おそらく、Julesの開発チームは日本語のようなIME(Input Method Editor)を必要とする言語の入力システムをまだ十分に考慮できていないのだと思います。ここはぜひ改善してほしいポイントです。
❌ 不要なコメントを生成しがち
Julesが生成・修正したコードには、// Added
や // Changed
, // Removed
といった変更履歴のようなコメントや、削除すべきコードがコメントアウトされているだけということがありました。
AGENTS.md
(コーディングエージェントへの指示ファイル)でルールを記述してもこの挙動は変わらず、こちらの要望をJulesに伝える方法をまだ見つけられていません。
❌ Gitの操作、特にコンフリクト解決ができない
Julesには現在、作業途中でrebase
するようなGit操作を行う能力はないようです。複数のタスクを並行して実行した結果コンフリクトが発生しても、自動で解消はしてくれません。
「現在のmainブランチにrebaseして」とお願いしても、タスクを開始した時点のコードから動かすことができないようで、結局手動でのマージが必要になりました。さらに、手動でマージコミットを作成してもJulesがそれを正しく認識できず、その後のコミットで変更がロールバックされたり、空のコミットが作られたりすることがありました。
この経験から、Julesに並列でタスクを依頼する際は、コンフリクトがなるべく起きないよう、それぞれの作業の影響範囲を考慮した上でタスクを分割・依頼する必要がありました。
❌ Androidのビルドが苦手……?
Androidのビルドプロセス、特にAndroid SDKのセットアップが安定しないことがありました。
たとえば、cd ./android
でディレクトリを移動したにもかかわらず、後続のコマンドで再度同じコマンドを実行しようとしてエラーになる、という事象が頻発しました。Julesの説明では「コマンドごとにカレントディレクトリはリセットされる」とのことでした。しかし、ls
だけ実行してもらうとやはりandroid
ディレクトリにいたり、実際の挙動とは異なっているように見えました。
時にはJules自身もビルドを試みることをせず、「この変更で良いか動作を確認して、問題なければコミットするよ」と言うことさえありました。もちろん、こちらとしてはコミットしてもらわなければ動作確認することが難しいため、少し困ってしまう場面でした。
この課題により、Julesから提出されるコードは、そのままビルドやテストが通るか分からない状態になります。そのため、GitHub側でのCI環境の整備が非常に重要になりますが、幸いそのCI環境の構築もJulesが手伝ってくれます。
Julesから提出されたコードのビルドやテストが通らない場合、エラーメッセージをJulesに伝えると原因の特定と修正を試みてくれます。しかし、その修正が本当に正しいかは、実際にGitHub ActionsなどのCIが実行されるまで分かりません。結果として、修正と検証のサイクルを繰り返すことになり、必然的にGitHub Actionsの使用量は増えていきます。
プライベートリポジトリで開発している場合、この使用量の増加がGitHub Actionsの無料枠を超過し、想定外のコストにつながる可能性があります。実際、筆者もこの開発で予算枠を超過してしまいました。
まとめ
Julesにはいくつかの課題も見られるものの、Googleのベータ版製品であることを考えれば、将来が楽しみなサービスだと感じています。何より、実際にアプリケーションを一つ、サーバーサイドも含めてリリースまでこぎつけられた事実が、そのポテンシャルの高さを示しています。
生成されたコードに「これは自分のコードではないな……」という感覚が残るのは事実ですが、コードを書く楽しみを目的としないのであれば、Julesは目標達成のための強力なツールになり得ると確信しました(そうは言っても、コードを書く楽しみそれ自体は捨てがたいものではありますが)
えーあい使えば8割方は楽できるけど、本当につらいのは残り2割なんですよ。
— ARIYAMA Keiji (@keiji_ariyama) July 1, 2025
今回気になった点については、既にJulesチームにフィードバックとして送信済みです。今後のJulesのアップデートに期待しています。
開発したアプリとソースコード