はじめに
ジェネラティブエージェンツの西見です。
今回は（なぜか）Ruby on RailsアプリケーションのDevinへのオンボーディングをしてみたので、その内容について紹介します。
Ruby on RailsアプリケーションをDevinにオンボーディングしようとしたときに困るのは、そもそもDevinにrubyがプリインストールされていないことです。
この問題は、開発環境をDev Containerで構築していれば解決できます。DevinからはDev Container CLI経由でRails環境を操作できるようにしておけば、Devinのワークスペース上に特別なセットアップをする必要がなくなるからです。幸い、Dev Container CLIを動作させるために必要なNode.jsは、最初からDevinのワークスペース上で利用することができます。
一方で、多くのRails開発者はpuma-devを利用したカスタムドメインでの動作確認を行っていると思いますので、Devinのワークスペースでpuma-devを設定し、Devinにエンドツーエンドの動作確認を行ってもらう方法についても紹介します。
Devinとは
DevinはCognition AIが開発した、自律型AIソフトウェアエンジニアを利用するためのサービスです。コードを生成するだけのAIとは異なり、Devinはコードを書くだけでなく、実行し、デバッグし、テストするなど、ソフトウェア開発のプロセス自体を支援します。
DevinのイメージはUbuntu 22.04 (x86_64)ベースで動作しており、PythonやNode.jsはプリインストールされていますが、Rubyはプリインストールされていません。このため、Ruby on Rails環境の構築には追加のセットアップが必要になります。
Dev Containerとは
Dev Containerとは、Docker技術を利用して一貫した開発環境を提供するための仕組みです。Visual Studio CodeのDev Container拡張機能やDevContainer CLIを使用することで、プロジェクトごとに分離された開発環境を構築できます。
最新のRailsではプロジェクト作成時にDev Container設定を生成できるようになっており、Dev Containerを活用した開発が標準的になりつつあります。一方で、そもそもDev Containerを活用していないプロジェクトでは、環境の構築はそれなりに大変です・・・。頑張ってセットアップしましょう！
なぜDev Containerを使うのか
冒頭では依存ライブラリのセットアップに便利、という利点を述べましたが、Dev Containerを利用する理由はDevinのワークスペースの仕様にもあります。
この図から分かる通り、Devinの実行環境はリポジトリ毎にパーティショニングして設定できる訳ではなく、一つのマシンの上に複数リポジトリのディレクトリが作成されているようなつくりになっています。つまり、ワークスペースは複数リポジトリを通じて共用なのです。これはいわば、一人の開発者の開発PCをセットアップしている感覚に近いです。
そういった事情もあって、要素技術の異なる各リポジトリのセットアップ時に、ワークスペース自体に依存ミドルウェアを個別にインストールすることは望ましくありません。例えばプロジェクトによって利用しているImage Magickのバージョンが異なる場合どうするのか？といった競合が発生する可能性があるからです。
このような問題を避けるためにも、Dev Containerを活用するのが有用でしょう。
Dev Container CLIを使う
ただ、Devin自体はDev Containerを用いた開発を自動で行ってくれるわけではありません。
DevinにDev Containerを利用してもらうためには、Dev Container CLIという仕組みから、Dev Containerを利用するよう指示する必要があります。
Dev Container CLIとは、Visual Studio Codeの拡張機能として人気のあるDev Containersの機能をコマンドラインから利用できるようにするツールです。Node.jsベースで実装されており、npmやnpxを通じて簡単に利用できます。
Dev Container CLIを使うと、.devcontainerディレクトリに定義された開発環境の設定に基づいて、コンテナのビルド・起動・コマンド実行などの操作を行えます。これにより、IDE依存なしでDev Containerの機能を活用できるため、CI/CDパイプラインやDevinのようなAIエージェントとの連携に適しています。
Dev Container CLIの利用方法
それではDev Container CLIの具体的な利用方法について見ていきましょう。これらのコマンドはDevinが利用できるようにナレッジやプレイブックで指示を作成しておくべきですが、ビルドについては、あらかじめ環境構築時に実施しておくと、DevinがDev Containerを立ち上げる際にはキャッシュが利用されるため、ACUの節約になります。
1. Dev Containerのビルド（build）
npx devcontainer build --workspace-folder .
このコマンドは、カレントディレクトリの.devcontainer設定を使用してコンテナイメージをビルドします。Devinはこのコマンドを実行することで、Railsアプリケーションに必要な依存関係（Ruby、Rails、その他のGem）を含むコンテナイメージを準備します。
ビルドプロセスはDockerfileやdocker-compose.ymlに基づいて行われるため、プロジェクト固有の依存関係もすべて含まれます。
2. Dev Containerの起動（up）
npx devcontainer up --workspace-folder .
ビルドしたコンテナを起動します。このコマンドにより、コンテナが実行状態になり、その中でRailsアプリケーションを動かす準備が整います。
3. コマンド実行（exec）
コンテナ内でRailsコンソールを実行する例:
npx devcontainer exec --workspace-folder . -- bin/rails console
開発サーバを起動する例:
npx devcontainer exec --workspace-folder . -- bin/dev
モデルのテストを実行する例:
npx devcontainer exec --workspace-folder . --remote-env RAILS_ENV=test -- bundle exec rspec spec/models
これらのコマンドを使用することで、Devinは実際のアプリケーションの動作を確認し、フィードバックを提供できるようになります。--remote-envフラグを使うと、環境変数を設定してコマンドを実行できるため、テスト環境などの切り替えも容易です。
カスタムドメインでの動作確認をDevinができるようにする
多くのRails開発環境では、ローカルでカスタムドメインを使用してアプリケーションをテストすることがあります。特にpuma-devを使ったSSL証明書付きカスタムドメインでの検証は開発段階では重要です。Devinでもこれらのセットアップをして、エンドツーエンドの動作確認を行えるようにしましょう。
puma-devとは
puma-devとは、Puma（Railsの標準Webサーバ）の開発者が作成した、ローカル開発環境でHTTPSとカスタムドメインを簡単に実現するためのツールです。.testや.devなどのTLDを使ったカスタムドメインを設定でき、自動的にSSL証明書を生成・適用します。
puma-devのインストールと設定
Devinのワークスペースにpuma-devをインストールする手順は次の通りです。
1. linuxbrewのパスを設定
echo 'if [ -d "/home/linuxbrew/.linuxbrew/bin" ]; then PATH="/home/linuxbrew/.linuxbrew/bin:$PATH" fi' >> ~/.bash_profile source ~/.bash_profile
※ Devinにはlinuxbrewがプリインストールされています。
2. puma-devのインストール
linuxbrew経由でpuma-devをインストールします。macOS版ではセットアップを全自動で行うスクリプトが提供されていますが、Linux版には提供されていないので、手動で名前解決のためのセットアップを行っていく必要があります。
brew install puma/puma/puma-dev
3. ルートCAの生成と信頼設定
# 一度起動してCAを生成 puma-dev # Ctrl+Cで停止 # CAを信頼 sudo mkdir -p /usr/local/share/ca-certificates sudo cp ~/.puma-dev-ssl/cert.pem /usr/local/share/ca-certificates/puma-dev.crt sudo update-ca-certificates
4. .testドメインの設定
まず、必要なパッケージをインストールします。
sudo apt install libnss-resolve
次に、dev-tld-resolverをセットアップします。これは、.testや.devなどのカスタムドメインをローカルアドレスに解決するためのモジュールです。
git clone https://github.com/puma/dev-tld-resolver.git cd dev-tld-resolver/src make sudo make install sudo ldconfig
続いて、システムの名前解決の仕組みを拡張するために、/etc/nsswitch.confファイルを編集します。
sudo vi /etc/nsswitch.conf
このファイル内で「hosts:」で始まる行を探し、次のように変更します。
変更前の例：
hosts: files resolve [!UNAVAIL=return] dns
変更後：
hosts: files resolve [!UNAVAIL=return] dev_tld dns
この変更により、システムの名前解決プロセスに「dev_tld」モジュールが追加され、.testや.devなどのドメインをローカルIPアドレスに解決できるようになります。このモジュールはDNSよりも先に解決を試みるため、優先的にローカル開発環境にリクエストが送られます。
次に、環境変数の設定を行います。まずユーザーレベルで設定します。
echo 'export DEV_TLD_DOMAINS=test,dev' >> ~/.bash_profile source ~/.bash_profile
さらに、システム全体で設定を有効にするために、/etc/environmentファイルにも同じ設定を追加します。これはシステムサービスやすべてのユーザーに対して設定を適用するために必要です。
sudo bash -c 'echo "DEV_TLD_DOMAINS=test,dev" >> /etc/environment'
この環境変数は、dev-tld-resolverがどのトップレベルドメイン（TLD）を127.0.0.1に解決するかを指定します。ここでは「test」と「dev」を指定していますが、必要に応じて他のドメイン（例：wp, dpl）も追加できます。
正常に名前解決できているかどうかは次のコマンドでテストします。
getent hosts foo.test # => ::1 foo.test
値が返ってきたら成功です。
5. ポート80/443へのバインド権限付与
realbin=$(readlink -f "$(command -v puma-dev)") sudo setcap cap_net_bind_service=+ep "$realbin"
6. systemdで自動起動設定
# /etc/systemd/system/puma-dev.service ファイルを作成 sudo tee /etc/systemd/system/puma-dev.service > /dev/null << 'EOL' [Unit] Description=Local Puma-dev Server After=network.target [Service] User=ubuntu ExecStart=/home/linuxbrew/.linuxbrew/bin/puma-dev -sysbind Restart=on-failure [Install] WantedBy=multi-user.target EOL # 設定の反映と起動 sudo systemctl daemon-reload sudo systemctl enable puma-dev sudo systemctl start puma-dev
ここまで終えると、システム起動時に自動的にpuma-devが起動し、名前解決を行ってくれるようになります。
7. アプリケーションのドメイン設定
最後に、puma-dev自体の設定も行いましょう。次の例は設定例です。
echo 3000 > ~/.puma-dev/rails_app
これにより https://rails_app.test/ でアプリケーションにアクセスできるようになります。Dev Containerで起動したRailsサーバーが3000ポートで稼働していれば、puma-devがそのポートにリクエストを転送し、ブラウザからはHTTPSでアクセスできます。
エンドツーエンドのテスト実行
ここまでの設定が完了したら、DevinにRailsアプリケーションの動作確認を行ってもらうことができます。以下のような指示をDevinに出すことで、アプリケーションの動作確認が可能になります。
このアプリケーションはRuby on Railsで開発されています。動作確認のためには、devcontainerを利用してアプリケーションを実行してください。 1. まずdevcontainerをビルドして起動 2. bin/devコマンドを実行してサーバーを起動 3. ブラウザからhttps://rails_app.test/にアクセスして、トップページが正しく表示されることを確認 4. ユーザー登録機能のテストとして、新規ユーザーを作成してみてください
このような指示により、Devinはdevcontainerを通じてRailsアプリケーションを起動し、ブラウザを使って実際の動作を確認することができます。また、テストの実行や特定の機能の確認なども同様に指示できます。
この流れでプルリクエストに動作確認時のスクリーンショットまで投稿してもらえると良いのですが、DevinがGitHubとの通信のために利用しているghコマンドは、画像のアップロードに対応していません。スクリーンショットが必要な場合は、チャットセッションに画像を貼り付けるよう指示すると良いでしょう。
おわりに
ここまでのセットアップを終えると、Railsアプリケーションのブラウザを通じた動作確認を、Devin自体が行ってくれるようになります。
Railsに限らず、他の要素技術で開発されたアプリケーションについても、Dev Containerを活用することで同様のオンボーディングを行うことができますので、Devinのさらなる活用のためにも、ぜひお試しください。
最後になりますが、ジェネラティブエージェンツでは、あらゆる開発をAIエージェントを活用して高速化する試みを続けています。この記事を読んで、自社でもDevinを活用して開発を高速化したい！と思われた際には、私たちがDevinへのオンボーディングを支援することも可能です。ぜひ、お気軽にご相談ください。
また、この記事を読んで「Devinって結構使えるやつかも！？」と思って頂けたのであれば、ぜひ以下のリンクより登録いただければと思います。
上記のリンクよりユーザー登録を頂けると、100ACU（作業時間1,500分相当）のボーナスが得られます。私も100ACUいただけるので、嬉しいです！
現場からは以上です。
