生成AIで大注目のOpen InterpreterとAzure CLIを使ってリソースを自動作成してみた

2023年09月28日 09時00分更新

文● FIXER／溝口遥大

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Open Interpreterを使ってAzureにリソースを作成してみた」を再編集したものです。

はじめに

　巷でOpen Interpreterというオープンソースプロジェクトが話題になっています。プロンプトで指示した内容についてプログラムの作成から実行まで行える激アツツールのようです。プログラムが実行できるならAzureCLIを実行できるのでは？と思い検証してみました。

Open Interpreterの公式サイト

事前準備

　AzureCLIの認証用のサービスプリンシパルを作成します。

$ az login -t
$ az account set -s <サブスクリプションのID>
$ az ad sp create-for-rbac --role Contributor --scopes "/subscriptions/<サブスクリプションID>" -n <spの名前>

※訂正とお詫び：初出時、上記コード最終行の末尾「<spの名前>」が消えておりました。現在は修正済みです。（2023/10/02、編集部）

　また、Azure OpenAIのgpt-35-turbo or gpt-4モデルが必要なので作成しておきます。Azure OpenAIの利用申請が済んでない方はこちらのリンクから申請できます。

環境構築

　今回のはDocker + docker-composeを使ってOpen Interpreterを動かしていきます。

ディレクトリ構造

root/
  ├ open-interpreter/
  │    └ Dockerfile
  └ docker-compose.yaml

Dockerfile

　Open Interpreter自体はPythonがあれば動作しますが、今回の検証ではazコマンドを使用するのでAzureCLIのインストールも一緒に行なっています。

FROM python:3.11.5

# Open interpreterのインストール
RUN set -eux; \
    pip install open-interpreter;

# Azure CLIのインストール
RUN set -eux; \
    apt-get update; \
    apt-get install ca-certificates curl apt-transport-https lsb-release gnupg -y; \
    mkdir -p /etc/apt/keyrings; \
    curl -sLS https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | tee /etc/apt/keyrings/microsoft.gpg > /dev/null; \
    chmod go+r /etc/apt/keyrings/microsoft.gpg; \
    AZ_REPO=$(lsb_release -cs); \
    echo "deb [arch=`dpkg --print-architecture` signed-by=/etc/apt/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/azure-cli/ $AZ_REPO main" | tee /etc/apt/sources.list.d/azure-cli.list; \
    apt-get update; \
    apt-get install azure-cli;

docker-compose.yaml

　environmentの部分に、Azure Open AIとサービスプリンシパルの情報を設定します。

version: "3"

services:
  open-interpreter:
    container_name: open-interpreter
    build: ./open-interpreter
    tty: true
    environment:
      AZURE_API_KEY: <AzureOpenAIのAPIキー>
      AZURE_API_BASE: <AzureOpenAIのAPIのURL>
      AZURE_API_VERSION: 2023-07-01-preview
      AZURE_DEPLOYMENT_NAME: <AzureOpenAIにデプロイしたモデル名>
      SP_CLIENT_ID: <事前準備で作成したSPのID>
      SP_CLIENT_SECRET: <事前準備で作成したSPのシークレット>
      SP_TENANT_ID: <事前準備で作成したSPのテナントID>
    volumes:
      - ./open-interpreter/volume:/home/user/volume

　上記ファイルを用意した後、次のコマンドを実行します。

$ docker-compose build
$ docker-compose up -d
$ docker exec -it open-interpreter bash

# アタッチしたコンテナで実行
$ interpreter -y --use-azure

　以下の画像のようになっていれば準備完了です。

リソースグループを作成してもらう

　手始めにAzureリソースの基本であるリソースグループを作成できるか検証します。

AzureCLIを使ってリソースグループを作成してください。必要な情報は適宜聞いてください。

　申し訳ないほど雑にお願いしてみました。するとサブスクリプションID、リソースグループ名、リージョン情報を聞かれたので入力します。

　次にaz loginコマンドを使ってAzureへのログインを求められました。今回はブラウザを経由するログインではなく、サービスプリンシパルを使って認証したかったので、その旨をOpen Interpreterに伝えます。

　必要な情報が揃ったのかリソースグループを作成するコマンドを出力してくれます。気がついた時には自分のサブスクリプションに指定した内容のリソースグループができていました。

App Serviceを作成してもらう

　次はApp Serviceを作成できるか検証します。あいも変わらず雑にお願いしてみます。

先ほど作ったリソースグループにAppServiceを作成してください。AppServicePlanはなるべく安いものでお願いします。

　先ほどと同様にApp Serviceの構築に必要な情報の入力をすると、

1・最も安いApp Serviceプランの検索
2・App Serviceプランの作成
3・App Serviceの作成

という流れで作成してくれました。

アラートを作成してもらう

　最後に作成したApp Serviceに対してアラートを追加できるか検証します。アラートに対する知見がない体でお願いしてみます。

作成してもらったAppServiceにアラートを追加したいです。アラートに対する知見がないのでいい感じに閾値などを設定してください。一旦アラート設定だけで通知の設定は不要です。

　今回はこちらからの入力は求められずに眺めているだけで作成が終わっていました。実際に作成されたアラートは以下の3つで基本的に監視しなければいけないものが揃っていていることが分かります。

・CPU使用率が80%を超えた場合のアラート
・メモリ使用率が80%を超えた場合のアラート
・HTTPエラー率が10%を超えた場合のアラート

　途中、指定するメトリック名が間違っているというエラーが出ていたのですが、App Serviceで利用可能なメトリックを取得してから再度実行するという臨機応変ぶりも見せてくれて、純粋に「やるじゃない」ってなりました。

最後に

　今回の検証から色々なことができそうだなと思いました。かなり雑なプロンプトを渡してもこちらの意図を汲み取って実行してくれるので、より洗練されたプロンプトを渡してあげたら「このリソースに対してXXという監視設定を追加して」や「ある時間のログからエラーの原因を解析して」のような運用作業の効率化に繋げられるのではと密かに期待しています。

　 溝口遥大／FIXER

Webフロントエンドの技術を学んでいます。

■関連サイト

ツイートする

カテゴリートップへ