Abudoriです。話題の絶えないAIエージェント、結局なにすればいいかよくわからん問題がありますよね。 最近では、Googleが圧倒的パワーによって結果的にほとんどの話題の機能を実装してくれると思っている今日この頃です。
AIエージェントは、Devinをはじめ、Codex、Julesがリリースされてきました。 どれも評判が良さそうで使ってみたいのですが、Julesくんが出るまでどれも月額が高く（Devinは安くなって最低30ドル〜そこから従量課金、CodexもChatGPTのPlusプランでは使えず、結構お値段のするProプラン以上です）、手が出ませんでした。Julesくんは通常のGoogleアカウントがあれば使用できるようになります。特に、GoogleWorkSpaceを使っていれば、ほとんどの人が使えるという大盤振る舞いです。
AIエージェントは、便利になった〜イエ〜イ！というレベルではなく、そのソフトウェアエンジニアの処理能力が10倍にも100倍にもする可能性があります。 その気になれば、その人だけでチーム内のソフトウェアエンジニアが足りてしまうようになるかもしれません。まずは開放されたJulesくんを【使い始める】第一歩が大事なように思えます。
この記事では、まずは使い始めることができるところまでやってみようと思います。
スポンサードリンク
Julesくんで何ができる？
JulesくんはGoogleのGimini Pro 2.5で動作するAIエージェントです。基本的にはコードをプロンプトに従って作成し、Githubに反映してくれます。
Julesくんに作業してもらうリポジトリを作って、Github連携をします。すると、指示のプロンプトを出すとそのリポジトリでコードを作って反映してくれます。 Julesくんから、作業内容のまとめが上がってくるので、おおきな問題がなさそうであれば承認し、Githubに反映させます。
基本的には、一つの作業ごとにブランチをきって作業してくれるため、さほど気にすることはないと思います（まったく成果物がないとか、トンチンカンなコードを書き始めていれば否認する感じだと思います）。 Julesくんの第一稿を大まかに承認し、その作業ブランチに移動して、人間がビルドして動作確認をし、多少修正作業をしてコミットしていく、という感じです。 こまかく機能実装をし、多少の修正をいれてマージしまくる、これを繰り返すことでプロジェクトを進めることができそうです。
今までのChatGPTのように、キャンバスに書いてあるコードを毎回ガーーーっと書き換えられて、変更されまくり、こちらがたてばあちらが立たず、あーーーやめてーーーーなんてことがブランチで管理できるので起きないので安心です。
スポンサードリンク
やってみよう
それでは、かんたんなサンプルプログラムを作らせてみましょう。
アカウント連携
まずは自分のGithubと連携が必要です。画面に従って、連携させたいアカウントにJulesを紐付けましょう。 Julesくんは黎明期であらゆるものが学習に使われます。コードを学習に使用しない設定はできますが、プロンプトなどの文字列は問答無用で使われるので、いきなり会社のアカウントに全部直結だ〜はやらず確認してからやりましょう笑。
つくるプログラムを考える
今回は以下のようなプログラムを作ります。サンプルコードレベルですが、このレベルのプログラムをいくつか作って組み合わせれば、それなりにいろんなところで使えそうな便利なプログラムくらいの大きさのプログラムです。
- 3次元点群を読み込む
- PCL（点群処理ライブラリ）で地面と障害物を分離する
- 画面に処理結果を描画する
- 障害物のみの点群を.pcdファイルで出力する
やりたいのは、ロボットの障害物となる点群がほしいので、「障害物抽出機」という名前にしてみましょう。
作業するGithubリポジトリをつくる
まずは、専用のGithubリポジトリを作ります。リポジトリはPublicでもPrivateでもできるはずです。空っぽなリポジトリを作りましょう。
プログラムの構造を考える
次のプログラムの構造を考えます。明確なプロンプトを渡すためには、作者本人が最低限プログラムの構造や動作原理を知っていなければよいプロンプトができません。 ここをやらないと動かないコードを量産し、地球の裏側の大量の電力を無駄にする羽目になります。
Abudoriがこのコードを書くとしたら、次の手順を踏むと想像します。
まずは環境構築。Ubuntu上で動作するとして、PCLをインストールします。また、PCLをincludeしたC++ファイルをコンパイルするためにMakefileを作ります（PCLはライブラリなので、毎回コマンドライン引数で指定するのは面倒ですし、久しぶりに動かそうとしたときに動かないのはかなりしんどいです）。
また、ビルドするディレクトリとソースコードが同じディレクトリにあるとグチャグチャになりそうです。また、点群ファイルをいくつか処理したいと考えると、ビルドやソースコードのところにあっても邪魔そうです。するとルートディレクトリにいくつかディレクトリをあらかじめ作っておくと便利そうです。
また、お試しでJulesくんを使用したところ、Julesくんの手元の環境のビルド済みのファイルまでGithubにアップロードしてきました笑。これは、各自のパソコンごとにコンパイルして作成してできるファイルなのでGithubにアップロードすべきではありません。おそらく、git add *で問答無用に全部あげちゃったみたいです。これは仕組みで防げます。.gitignoreファイルを作って、gitに反映するのを禁止させましょう。
.gitignoreをつくり、buildディレクトリ以下をgitに反映させない
次に動作を考えます。 ここでは、PCLはある程度使ったことがある前提です。Abudoriならこんな機能があればいいな、と思います。
- PLYファイルかPCDファイルをコマンドライン引数で読み込む。
- ファイル形式が間違っていれば形式と読み込み方法を表示してプログラム終了（まちがったまま計算を始めさせない）。
- コンフィグファイルを読み込む。これは決まった位置に保存したconfig.txtに指定する。
- 処理前の点群をPCLViewerで表示する
- 点群をダウンサンプリングする（そのままだと莫大な時間がかかる）。ダウンサンプリングのサイズはコンフィグで指定できるようにする。
- ProgressiveMorphologicalFilter関数を使って地面を判定する。この関数に必要なパラメータはconfig.txtから指定できる。
- 判定した地面をground_cloud変数、地面以外をobstacle_cloud変数に格納する。
- ground_cloudを緑、obstacle_cloudを赤にしてPCLViewerで表示する。
- obstacle_cloudをfiltered_cloud.pcdとしてPCDファイルに出力する。
おおまかにはこの手順であれば、最低限動作すると思います。
プロンプトを考える
プログラム作成にあたって、指示文を考えます。と言っても、上記くらいの情報量があれば今のところ問題なく動作すると思います。また、一度に作業してもらえるプログラムの量や難しさは時代によって異なります。今後、どんどんこの容量は大きくなっていくでしょう。
反対に、“テトリスを作って！”みたいなプロンプトしか作れない人は使いこなすことができず、どんどん差がつくことになると思います。Julesに限らず、プログラミングに限らず、AIエージェントに自分の実現したいことの仕様書を表現したり、指示することができなければ辛い時代になっていくことでしょう（したがって、根本的な母語の言語能力がさまざまな仕事の能力として置き換わっていくでしょう。アホはよりアホになっていくのです…辛い現実が見えてきそうなのでここまで）。なので、具体的な動作を前の節で作りました。PCLを知らなければ、PCLのプログラムをつくるプロンプトを書き上げるのはまだむずかしいのです。的確な指示ができるように構成をねっておきましょう。
今回は以下のようなプロンプトを考えてみました。Markdown形式で入力すると階層構造がわかってより良いです。
# PCLを使った障害物を抽出するプログラムの作成依頼 ## プログラムの概要 * PCDファイルやPLYファイルを読み込んで障害物を抽出して、障害物のみの点群ファイルを出力するプログラムです。 * おもな処理はPCLのProgressiveMorphologicalFilter関数を使って、地面とそれ以外を分離します。 * 分離した点群をビジュアライザで表示し、処理結果をfiltered_cloud.pcdとして出力します。 ## 主な手順 * PCLのインストールスクリプトを作る * PCLのコードをビルドできるMakefileを作る * ソースコードを保管するsrcディレクトリを作る * ビルドしたファイルを保管するbuildディレクトリを作る * 点群ファイルを保管するdataディレクトリを作る * コンフィグを保存するconfigディレクトリを作る。中にconfig/config.txtを入れ、後述のコンフィグを記入する。 * `.gitignore`をつくり、buildディレクトリ以下をgitに反映させない * PLYファイルかPCDファイルをコマンドライン引数で読み込む。 * ファイル形式が間違っていれば形式と読み込み方法を表示してプログラム終了（まちがったまま計算を始めさせない）。 * コンフィグファイルを読み込む。これは決まった位置に保存したconfig.txtに指定する。 * 処理前の点群をPCLViewerで表示する * 点群をダウンサンプリングする（そのままだと莫大な時間がかかる）。ダウンサンプリングのサイズはコンフィグで指定できるようにする。 * ProgressiveMorphologicalFilter関数を使って地面を判定する。この関数に必要なパラメータはconfig.txtから指定できる。 * 判定した地面をground_cloud変数、地面以外をobstacle_cloud変数に格納する。 * ground_cloudを緑、obstacle_cloudを赤にしてPCLViewerで表示する。 * obstacle_cloudをfiltered_cloud.pcdとしてPCDファイルに出力する。 コードの正しさを評価するときにコメントを残してもらえると嬉しいです。日本語で残してください。 ## その他 ユーザがOSSとして利用するためにわかりやすいREADME.mdが必要です。READMEに必要な以下の項目を入れてマークダウン形式で作成してください。日本語で文章を作成してください。 * 概要 * インストール方法（インストールシェルの使い方でOK） * ビルドの方法 * プログラムの使用方法 * その他何かあれば
さらに、以上のプロンプト案を実際に処理するモデルのGemini 2.5 Proのチャットで添削をしました。 ツッコミが入りました。
- 対象とするOSはなにかがない。
- コンフィグファイルの詳細がほしい、具体的なパラメータ名（これがほしいという提案もされたのでそのとおりにした）
- MakefileでもできるがCMakeの以降を考えたほうがいい。CMakeに変更。
- エラーハンドリングは標準出力だけでOKか。
- PCBViewerで視点制御は必要か？（そんな機能あるの？？？）
このツッコミからプロンプトを以下に変更しました。
# PCLを使った障害物を抽出するプログラムの作成依頼 ## プログラムの概要 * PCDファイルやPLYファイルを読み込んで障害物を抽出して、障害物のみの点群ファイルを出力するプログラムです。 * おもな処理はPCLのProgressiveMorphologicalFilter関数を使って、地面とそれ以外を分離します。 * 分離した点群をビジュアライザで表示し、処理結果をfiltered_cloud.pcdとして出力します。 * OSはUbuntu22かUbuntu24を想定します。WindowsやMacOSは想定しません。 ## 主な手順 * PCLのインストールスクリプトを作る。インストールはapt-getのみでOKで、ライブラリをソースビルドする必要はありません。 * PCLを使ったサンプルコードをビルドできるCMakeを作る * ソースコードを保管するsrcディレクトリを作る * ビルドしたファイルを保管するbuildディレクトリを作る * 点群ファイルを保管するdataディレクトリを作る * コンフィグを保存するconfigディレクトリを作る。中にconfig/config.txtを入れ、後述のコンフィグを記入する。 * `.gitignore`をつくり、buildディレクトリ以下をgitに反映させない * PLYファイルかPCDファイルをコマンドライン引数で読み込む。 * ファイル形式が間違っていれば形式と読み込み方法を表示してプログラム終了（まちがったまま計算を始めさせない）。 * コンフィグファイルを読み込む。これは決まった位置に保存したconfig.txtに指定する。 * 処理前の点群をPCLViewerで表示する * 点群をダウンサンプリングする（そのままだと莫大な時間がかかる）。ダウンサンプリングのサイズはコンフィグで指定できるようにする。 * ProgressiveMorphologicalFilter関数を使って地面を判定する。この関数に必要なパラメータはconfig.txtから指定できる。 * 判定した地面をground_cloud変数、地面以外をobstacle_cloud変数に格納する。 * ground_cloudを緑、obstacle_cloudを赤にしてPCLViewerで表示する。 * obstacle_cloudをfiltered_cloud.pcdとしてPCDファイルに出力する。 コードの正しさを評価するときにコメントを残してもらえると嬉しいです。日本語で残してください。 ## config.txt PCLの操作をするときのパラメータを変更するためにコンフィグファイルを作成します。内容は以下のパラメータを想定しています。 \``` # config/config.txt の例 # ProgressiveMorphologicalFilter Parameters max_window_size = 33 slope = 1.0 initial_distance = 0.15 max_distance = 3.0 # Downsampling Parameters voxel_leaf_size = 0.1 \``` ## ドキュメントについて ユーザがOSSとして利用するためにわかりやすいREADME.mdが必要です。READMEに必要な以下の項目を入れてマークダウン形式で作成してください。日本語で文章を作成してください。 * 概要 * インストール方法（インストールシェルの使い方でOK） * ビルドの方法 * プログラムの使用方法 * その他何かあれば ## その他 * エラー処理は標準出力であればOKです。 * PCBViewerは点群が確認できればOKです。リッチなGUIはひつようありません。
それでは、Julesくんにお願いしてみましょう！
Julesくんにお願いしてみる
さっそく、プロンプトをJulesくんに投げてみましょう。先程作成した作業用リポジトリが指定されていることを確認して、プロンプトを入れて計画ボタンを押します。画面はChromeで日本語に翻訳したままでOKです。
すると、JulesくんがGithubからバーチャル環境をつくり、git cloneし、どんな作業になるか計画を始めます。
Julesくんが全体の作業内容を考えるので、中身を確認します。
承認すると、Julesくんが作業を開始してくれます。もう、その場を離れても大丈夫です。私は目を使いすぎたので、散歩をしてきます。
しばらくすると、動作を停止しました。回答を求めています。どうやら、JulesくんはPCL1.8をソースビルドして動かそうとしていたみたいです。その必要がないことを伝えました。
気長に待ちます。おふろに入ってきます。
ダメだったようです。PCLをソースビルドしようとして、用意されていた仮想環境が食い尽くされてしまい、にっちもさっちも行かなくなったようです。
JulesくんやGeminiくんに限らず、LLMほとんどに、すべての文脈を同じだけの重要度で取り扱ってしまう傾向があります。それはこちらが指示した内容ではなく、LLMが自発的に挙げた内容も例外ではなく、重要ではないことも他の要素と同じくらい重要として捉えているように見えます。
このように、LLMに指示を出すときは、的確に、誰が読んでも同じような解釈になるように、一度で、必要十分な量でプロンプトを与えることが重要になります。
先程のプロンプトに以下の内容を追加しました。
# 主な手順 * PCLのインストールスクリプトを作る。インストールはapt-getのみでOKで、ライブラリをソースビルドする必要はありません。
たった1行追加したプロンプトをもう一度、まっさらなJulesくんにお願いしました。
この前に同じ規模のサンプルコードで試しで作ったJulesくんは、9分ほどで処理してくれました。 このときはプロンプトをGeminiくんに添削してもらわなかったので、今回は3倍速になったということになります。的確なプロンプトはとっっっっても大事であることを痛感しました。
右側に作ってくれたコードがCanvas上に表示されているので、確認します。
コードを一読する限り問題がなさそうです。自分が書くよりもキレイなコードで、体系化できていると思います。ちょっとmain文が長い気がするけど良いコードでした。
ここでPublish Githubボタンを押しましょう。ありがとう！Julesくん。先程作った空っぽのGithubに移動します。
スポンサードリンク
コードを修正しよう
Julesくんが作ってくれたコードを確認します。git cloneし、ブランチを切り替えましょう。mainブランチではなく、feat/pcl-obstacle-detectionブランチを作ってくれています。
READMEにあるとおり、ビルド環境を作ります。
mkdir build cd build cmake .. make
一度ビルドエラーが起きたので、内容を共有します。ちゃんと原因を特定して直してコミットしてくれました。
それでは実行してみましょう！
実行すると、まず、入力した点群が表示されます。これは指示通りですね！
続いて、地面判定の処理が走ります。ここでは、config.txtでダウンサンプリングのサイズを0.25mに変更してから実行していました。
想定通りの結果を得ることができました。コンフィグファイルを変更すると、キチンと処理結果を変えることができます。コンフィグファイルを何度も変えて最適な値を探すだけで、必要な機能は作れそうです。このコードからロボットに搭載する処理を追加したり、検討したりすることができます。
スポンサードリンク
マージしよう
かなり高品質なコードを作ることができました。ここで問題があれば、このfeat/pcl-obstacle-detectionブランチに自分で修正してコミットしましょう。 AIと人間が協同でコード開発していることになりますね。
お疲れ様でした！mainブランチにマージされ、実装したコードが安全に適用されました。この例では、mainブランチにしましたが、devブランチにマージして開発を進め、最終的にmainブランチにマージするとよいです。これは個人開発なので、これでOK。
今回作ったリポジトリはこちら
スポンサードリンク
この続きは…
これでコード書く工程をJulesくんに委託して、環境に適用させることができました。このあとは、バグがあれば、同じようにリポジトリをJulesくんに共有し、プロンプトを組み、バグ修正依頼をかけます。 このとき、間違っていないことを確認して、プルリクを繰り返す、これをひたすら繰り返すことでコードが育っていくはずです。
このやりとり、Julesくん一人ではなく、並列で実行させることができます。機能を小さな機能に分けて、一つずつJulesくんに渡していくのです。ひとりで何ヶ月もかけていたプロジェクトが、あれもこれも作らなければならない！をJulesくん並列作戦を繰り出すことで、大幅に早く作ることができます。
今回は【使い始めよう】という文でやってみました。これは今後のプログラミングが大きく変わっていく技術になりそうです。いまは難しくてもどんどんやっていく必要があります。使い始めることが大事なのです…。
Julesくんを使って、もっとロボット開発を加速させていきましょう！
