OpenTofuとIncusで、さくらのAI Engineを使うAIエージェント開発環境を作ってみた
はじめに
今回は、OpenTofuとIncusを使用して、さくらのAI Engineを利用するAIエージェント開発環境を作成しました。
AIエージェントを1つの環境で動かすのではなく、次の2つの役割に分けています。
設計担当エージェント
↓
設計成果物を共有ワークスペースへ保存
↓
実装担当エージェント
↓
実装・ビルド・テスト・結果報告
今回の目的は、高度なアプリケーションを作ることではありません。
まずは小さな.NETアプリケーションを題材にして、次の流れが成立するかを確認しました。
- OpenCodeからさくらのAI Engineを利用する
- AIエージェントごとに実行環境を分離する
- 設計担当から実装担当へ成果物を引き継ぐ
- .NETアプリケーションを実装する
- ビルド、テスト、実行まで完了する
使用したリポジトリ
今回使用した構成は、次のGitHubリポジトリで公開しています。
Linux Build Lab検証リポジトリ
Incus AIエージェントチーム実行環境
今回使用した開発依頼とプロンプト
環境構築や実行手順は、
対象ディレクトリのREADME.mdをもとに進めています。
本記事では、細かな構築手順ではなく、実際に2つのAIエージェントへ役割を分けて開発を行った結果を中心に整理します。
今回の構成
今回作成した環境は、次のような構成です。
Ubuntuホスト
├─ OpenTofu
├─ Incus
│
├─ ubuntu2404-sakura-agent-01
│ ├─ 役割：設計
│ ├─ OpenCode
│ └─ さくらのAI Engine接続設定
│
├─ ubuntu2404-sakura-agent-02
│ ├─ 役割：実装・ビルド
│ ├─ OpenCode
│ ├─ さくらのAI Engine接続設定
│ └─ .NET 10 SDK
│
└─ 共有ワークスペース
└─ /home/ubuntu/ai-agent-team
設計担当と実装担当は、別々のUbuntu 24.04コンテナで動作します。
ホスト側の共有ディレクトリは、各コンテナ内から/workspaceとして参照します。
Ubuntuホスト側
/home/ubuntu/ai-agent-team
Incusコンテナ側
/workspace
この共有ワークスペースを使い、
設計担当が作成した成果物を実装担当へ引き継ぎます。
OpenTofuの設定では、コンテナごとに次の内容を変更できるようにしています。
- コンテナ名
- AIエージェントの役割
- 仮想CPU数
- メモリ上限
- .NET 10 SDKを導入するか
将来的には、設計と実装だけでなく、テスト担当やレビュー担当を追加できる構成にしています。
コンテナの作成結果
OpenTofuを実行し、設計担当と実装担当の2台のコンテナを作成できました。
2台とも正常に起動し、それぞれ設計担当・実装担当として利用できる状態になりました。
各コンテナには、役割情報を保存しています。
ubuntu2404-sakura-agent-01
role: design
ubuntu2404-sakura-agent-02
role: build
実装担当のコンテナには.NET 10 SDKを導入し、設計担当には導入していません。
これにより、それぞれの役割に必要な機能だけを持たせる構成にしています。
共有ワークスペースの確認
設計担当と実装担当は、同じ検証ディレクトリを参照します。
/workspace/experiments/
├─ experiment-001/
└─ experiment-002/
検証ディレクトリには、次のような成果物を保存します。
experiment-001/
├─ documents/
├─ prompts/
├─ reports/
├─ src/
├─ tests/
└─ request.md
2台のコンテナから同じディレクトリを参照し、それぞれ書き込みできることを確認しました。
この共有領域が、設計担当から実装担当へ成果物を引き継ぐ場所になります。
今回の開発依頼
今回は、AIエージェント間の役割分担と成果物の引き継ぎを確認するため、小さな.NETアプリケーションを題材にしました。
開発要求と役割別のプロンプトは、次のディレクトリにまとめています。
主な依頼内容は次のとおりです。
- .NET 10のコンソールアプリケーションを作成する
- 標準出力へ
Hello from Linux Build Labを表示する - MSTestによる単体テストを作成する
- Linux環境でビルド、テスト、実行を確認する
- 設計書、ソースコード、テストコード、結果報告書を残す
今回はアプリケーションの複雑さではなく、次の流れが成立するかを確認することを優先しました。
設計担当が要求を読み込む
↓
設計成果物を作成する
↓
共有ワークスペースへ保存する
↓
実装担当が設計成果物を読み込む
↓
実装・ビルド・テストを行う
↓
結果報告書を作成する
設計担当エージェントの実行結果
最初に、設計担当のAIエージェントへ開発要求と設計担当用プロンプトを渡しました。
設計担当には、実装コードを作成せず、設計成果物だけを作成するように指示しています。
実行後、次の成果物が作成されました。
documents/
├─ concept-design.md
├─ basic-specification.md
├─ implementation-plan.md
└─ test-plan.md
reports/
└─ design-result.md
設計担当エージェントが作成した成果物の概要は、次のとおりです。
ソースコードやテストコードは作成せず、設計成果物のみが生成されていることを確認できました。
実装担当エージェントの実行結果
次に、設計担当が作成した成果物を、実装担当のAIエージェントへ引き継ぎました。
実装担当は、.NET 10コンソールアプリケーションとMSTestによる単体テストを作成し、ビルド、テスト、アプリケーション実行まで完了しました。
実装途中で発生したコンパイルエラーについても、原因を確認して修正しています。
これにより、設計担当と実装担当で役割を分けながら、次の一連の流れを実行できることを確認しました。
実際に作成された成果物
設計担当と実装担当のAIエージェントが作成した成果物は、次のディレクトリで公開しています。
設計書、ソースコード、テストコード、結果報告書、ソリューションファイルを収録しています。
bin、obj、実行ログ、状態管理ファイルなどの生成物は除外しています。
利用量
今回、同程度の小さな開発を2回実行しました。
さくらのAI Engineの管理画面では、合計で約60リクエスト使用していました。
そのため、今回の条件では、設計から実装、テスト、報告書作成までの1セットで、約28〜30リクエストを使用したことになります。
1セット
約28〜30リクエスト
月3,000リクエストを単純に30で割ると、約100セット分です。
3,000 ÷ 30 = 100
ただし、これは固定文字列を表示する小規模なアプリケーションでの結果です。
アプリケーションや仕様書が複雑になると、次の値は増えると考えています。
- 読み込むファイル数
- 入力トークン数
- AIエージェントの試行回数
- エラー修正回数
- リクエスト数
- 処理時間
今回の検証では、リクエスト数だけでなく、入力トークン数も比較的大きくなりました。
AIエージェントが作業を進めるたびに、要求、設計書、既存成果物などを読み込むためだと考えています。
月3,000リクエストまでの継続実行については、後日あらためて検証し、本記事へ追記する予定です。
今後の検証
今後は、今回作成した環境を使って、次の内容を確認する予定です。
- 設計担当から実装担当への完全自動連携
- 処理途中で質問が発生した場合の停止と再開
- 状態ファイルによる進捗管理
- 長時間実行時の安定性
- 成果物の再現性
- 月3,000リクエストまでの継続実行
- テスト担当エージェントの追加
- レビュー担当エージェントの追加
- もう少し複雑なアプリケーションでの検証
完全自動化や複数エージェントの運用方法については、運用上のノウハウも含まれるため、公開範囲を分けながら検証を続ける予定です。
おわりに
今回は、OpenTofuとIncusを使用して、さくらのAI Engineを利用するAIエージェント開発環境を作成しました。
作成したアプリケーション自体は、固定文字列を表示する小さなコンソールアプリケーションです。
ただし、今回の目的はアプリケーションの複雑さではありません。
設計する
↓
設計成果物を保存する
↓
別のAIエージェントが引き継ぐ
↓
実装する
↓
ビルドする
↓
テストする
↓
結果を報告する
この一連の流れを、役割ごとに分離したIncusコンテナ上で実行できることを確認しました。
AIエージェントへいきなり複雑な開発を任せるのではなく、まずは人間が結果を判断しやすい小さな課題から始めることで、役割分担、成果物の引き継ぎ、実行環境の構成を確認しやすくなりました。
今回の検証で、AIエージェントを継続的に試せる環境までは作成できました。
今後は、この環境を使いながら、継続実行と自動化を少しずつ進めていきます。