# Hermes Agentをサーバーで24時間稼働させる方法

> Hermes Agentをサーバーで24時間稼働させる方法：ブラウザーなしのVPSへのインストール、ゲートウェイをシステムサービスとして実行する方法、再起動後の自動起動、linger、Docker。

Source: https://ailoot.ai/blog/ja/hermes-agent-vps-24-7/
Canonical: https://ailoot.ai/blog/ja/hermes-agent-vps-24-7/
Language: ja
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-116
Revision: sha256-1ac962b6062f72f2e532cc5d3ed36fe35f01acc1489d8af235186fd4059b6bbb


ノートパソコンにHermes Agentをインストールすると、こんな疑問が浮かびます。ノートパソコンを閉じている間、誰がTelegramで返信し、朝のまとめを作るのでしょうか。自分のデスクでは、パソコンの電源が入っている間だけエージェントが動きます。ボットを常時オンラインにして、スケジュール済みのタスクを自動で実行するには、エージェントをサーバーに移す必要があります。

ここでは、一般的なLinuxサーバーにHermesをインストールし、ゲートウェイを常時稼働するサービスにして再起動後に自動で起動させる方法と、知らない人がターミナルに入れないようアクセスを制限する方法を説明します。このガイドは公式ドキュメントに基づいています。

Hermesをまだ一度もインストールしていない場合は、まず[このエージェントとは何か、インストール方法](https://ailoot.ai/blog/ja/hermes-agent-install-setup/)を紹介する別の概要ガイドをご覧ください。このガイドでは、すでに自分のマシンで動かしていることを前提に、サーバーへの移行だけを扱います。

Ailootの利用方法については、[ドキュメント](https://ailoot.ai/docs/)をご覧ください。



## Hermes Agentをノートパソコンからサーバーに移す理由

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

自分のパソコンは、そばにいて電源が入っている間だけ動きます。24時間稼働させるにはサーバーが必要です。パソコンの電源が切れていてもTelegramボットが返信し、スケジュール済みのタスクが自動で実行されます。サーバーが必要なのはこの場合だけで、エージェントを普通に使うならノートパソコンで十分です。

</div>

ノートパソコンでは、ふたが開いていて、あなたが近くにいる間だけHermesが動きます。ふたを閉じるとボットは応答しなくなり、朝のまとめも届きません。「メッセンジャーで人に返信し、スケジュールに沿って作業する」ようなタスクには困ります。

サーバーなら事情が違います。休止することがなく、ほかのものにも依存しません。同じHermesをインストールすれば、あなたがいなくても動きます。午前3時にTelegramで返信し、毎朝、指定したトピックのニュースを集め、実行の間もセッションを維持します。

エージェントに継続的なタスクを任せる場合、サーバーへの移行が役立ちます。自分やチームのボット、朝のまとめ、自動返信、定期的なドキュメント作業などが該当します。特定のプロジェクトでHermesを試し、そばで作業するだけなら、まだサーバーは必要ありません。手順がひとつ増えるだけです。

## VPSにHermesをインストールする前に準備するもの

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

必要なのは、SSHで接続できるLinuxサーバー（公式チームは新規インストールしたUbuntuでテストしています）、事前に選んだモデル、そしてサーバーでは通常ブラウザーが不要だという理解です。無人運転でモデルにアクセスするには、Nous Portalが最も便利です。OAuthサインインで認証が自動更新されるため、トークン切れで夜のうちに停止することがありません。

</div>

インストール前に3つのものを準備します。

**サーバー。** 一般的なLinux VPSで十分です。ドキュメントにある第一級のサポート対象はLinuxとWSL2で、最新のUbuntuでテストされています。システムにglibc、systemd、一般的なディレクトリ構成があれば、Hermesは正しくインストールできます。以下の自動起動手順はすべてsystemdに依存します。systemdはUbuntuとDebianに標準で備わっています。

**SSHアクセス。** SSHを使い、ターミナルからサーバーに接続します。マウスは使いません。以下のコマンドはすべて、このSSHセッションで実行します。vibe codingをしていて、まだターミナルに慣れていなくても心配はいりません。コマンドは数個だけで、それぞれをそのままコピーできます。

**選択済みのモデル。** エージェントは自分で考えるのではなく、モデルを呼び出します。無人で動かすサーバーでは、モデルへのアクセスが期限切れにならないことが重要です。最も簡単なのは、`hermes setup --portal`を使ったNous Portalのサブスクリプションです。サインインにはOAuthを使い、トークンは自動更新されます。自分のAPIキーも使えますが、その場合はアカウントに残高があることを確認してください。残高がないヘッドレスエージェントは応答しなくなります。モデルには少なくとも64,000トークンのコンテキストウィンドウが必要です。そうでないとHermesはそのモデルでの起動を拒否します。リストにあるクラウドモデルはすべてこの要件を満たしています。

<div class="aside" data-semantic="callout" role="note" aria-label="注記">

注記

公式ドキュメントには、VPS選びや最低限のリソースについての具体的な数値がないため、ここでも数値は示しません。説明されている運用経験によれば、ボットとスケジュールを備えたゲートウェイなら、控えめなマシンで十分です。重い計算はモデル側で行われ、サーバー自体の負荷はごく小さいためです。最も負荷が大きいのはブラウザーの自動操作ですが、サーバーでは通常不要です（この点は後ほど説明します）。

</div>

## Hermes Agentをサーバーに1つのコマンドでインストールする方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

SSHでサーバーに接続し、サーバーでブラウザーを省くフラグを付けてインストーラーを実行します。curl -fsSL <https://hermes-agent.nousresearch.com/install.sh> \| bash -s -- --skip-browser。その後、ターミナルシェルを再起動し、hermes setup --portalでモデルを選びます。hermes doctorでインストールを確認してください。

</div>

サーバーへのインストールはノートパソコンの場合とほぼ同じですが、違いがひとつあります。サーバーでは通常、エージェントにブラウザーは不要です。ブラウザーの自動操作には大容量のChromiumも必要です。そのため、`--skip-browser`フラグを使います。

1.  ### SSHでサーバーに接続する

    ```bash
    ssh root@your-server-address
    ```

    以降のコマンドはすべて、このセッション内でサーバー上に直接入力します。

2.  ### ブラウザーなしでインストーラーを実行する

    ```bash
    curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser
    ```

    スクリプトは必要な環境をダウンロードし、`hermes`コマンドをインストールします。`--skip-browser`フラグを付けると、ブラウザー自動操作のインストールを省きます。画面のないサーバーでは、容量を使うだけだからです。後からブラウザーが必要になった場合は、別途インストールできます。

3.  ### シェルを再起動してモデルを選ぶ

    ```bash
    source ~/.bashrc
    hermes setup --portal
    ```

    1行目で新しい`PATH`を読み込み、`hermes`コマンドを見つけられるようにします。2行目でNous Portalのサインインが始まります。サインインを確定すると、個別のキーを用意しなくてもエージェントがモデルとサービスを利用できるようになります。

4.  ### インストールを確認する

    ```bash
    hermes doctor
    ```

    このコマンドは、インストール済みのもの、不足しているもの、修正方法を表示します。緑色のマークがあれば、必要なものが揃っています。

ボットとスケジュールを追加する前に、まずサーバー上で直接、会話が問題なくできることを確認してください。`hermes`を実行し、答えを検証できる簡単なタスクを与えます。通常の会話が動作する前に機能を詰め込まないよう、ドキュメントも明示的に勧めています。妥当な助言です。





## Hermesを24時間稼働させる方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

まず`hermes gateway setup`でゲートウェイを設定し、Telegramに接続します。次に、1つのコマンドでゲートウェイをサービスにします。`hermes gateway install`はユーザーサービスをインストールし、`sudo hermes gateway install --system`はサーバーの起動時に立ち上がるシステムサービスをインストールします。ユーザーサービスは`hermes gateway start`、`stop`、`status`で管理します。VPSのシステムサービスは、確認も変更も`--system`と必要な権限を明示します。

</div>

ゲートウェイは、すべてのメッセンジャーとの接続を維持し、セッションを管理し、スケジュール済みタスクを実行する、単一のバックグラウンドHermesプロセスです。24時間稼働の仕組みはすべて、このゲートウェイを中心に動きます。このプロセスが自動で起動し、動作し続けるようにします。

まずゲートウェイを設定し、メッセンジャーに接続します。

```bash
hermes gateway setup
```

セットアップウィザードがプラットフォームの設定を案内し、ボットトークンとアクセスリストの入力を手伝います。Telegramの接続手順（BotFatherでボットを作成し、自分のIDを確認してトークンを入力する方法）は、[メインのインストールガイド](https://ailoot.ai/blog/ja/hermes-agent-install-setup/)で説明しています。ここでは繰り返しません。

次に、よく忘れられる落とし穴があります。単に`hermes gateway`を実行するだけでは、SSHセッションを開いている間しかプロセスは動きません。ターミナルを閉じるとゲートウェイも停止します。連続して稼働させるには、システムの管理下に置く必要があります。そのためのコマンドはひとつです。

```bash
hermes gateway install
```

これでゲートウェイがサービスとしてインストールされます。Linuxではユーザーsystemdサービス、macOSではlaunchdを使います。システムがプロセスを監視し、クラッシュした場合は再起動します。

サーバーでは、もう一方の方法を使うことが多いでしょう。ユーザーのサインイン前に、マシンの起動時に立ち上がるシステムサービスです。

```bash
sudo hermes gateway install --system
```

VPSで必要なのは、まさにこの方法です。サーバーが再起動すると、サービスが自動で起動し、ボットが再びオンラインになります。次の簡単なコマンドで管理できます。

```bash
hermes gateway start     # start
hermes gateway stop      # stop
hermes gateway status    # check status
```

システムサービスの場合は、これらのコマンドに`sudo`と`--system`フラグを加えます。加えないと、起動時に立ち上がるサービスではなく、ユーザーサービスが対象になります。

```bash
sudo hermes gateway start --system
sudo hermes gateway stop --system
sudo hermes gateway status --system
```

## lingerが必要な理由と、設定しない場合に起きること

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

ゲートウェイをユーザーサービス（`--system`なし）としてインストールした場合、SSHを終了するとsystemdが停止し、起動時にも立ち上がりません。`sudo loginctl enable-linger username`という1つのコマンドで解決できます。これでサービスはログインとログアウトから独立して動作します。

</div>

これは最もよくあるつまずきです。サービスをインストールしたのに、夜になるとボットが応答しなくなります。原因はLinuxのユーザーサービスの仕組みにあります。

ユーザーsystemdサービスは、通常、あなたのセッションに紐づいています。SSHで接続するとユーザーマネージャーが起動し、サービスが動きます。ログアウトすると、システムはそのユーザーを非アクティブとみなし、ゲートウェイを含むそのユーザーのサービスを停止します。サーバーへのログインとログアウトを繰り返す運用では、これでは問題です。SSHで接続している間しかボットがオンラインになりません。

lingerモードを使えば解決できます。ユーザーがログインしていないときも、システムがユーザーマネージャーを動作させ続けます。

```bash
sudo loginctl enable-linger username
```

このコマンドを実行すると、ユーザーサービスは単独で動き、ログインを待たずにサーバーの起動時に立ち上がります。lingerを設定しない場合は元の動作に戻ります。SSHを終了するとゲートウェイが停止し、起動時にも立ち上がりません。ドキュメントにも明記されています。

<div class="aside" data-semantic="callout" role="note" aria-label="注意">

注意

これはシステムサービス（`sudo hermes gateway install --system`でインストール）には当てはまりません。システムサービスはすでにマシン全体のレベルで動作し、起動時に立ち上がります。lingerが必要なのはユーザーサービスだけです。どちらかを選んでください。システムサービス、またはlingerを設定したユーザーサービスです。

</div>

## 自動再起動付きでHermesをサーバー上のDockerで実行する方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

Dockerを使う場合、Hermesをコンテナ内で永続的なゲートウェイとして動かせます。docker run -d --name hermes --restart unless-stopped -v ~/.hermes:/opt/data -p 8642:8642 nousresearch/hermes-agent gateway run。--restart unless-stoppedフラグにより、再起動後にコンテナが再び立ち上がります。イメージ内のゲートウェイプロセスも、クラッシュ時に再起動されます。

</div>

Dockerも、エージェントをサーバーで稼働させ続ける方法のひとつです。コンテナに慣れている場合や、エージェントをメインシステムから隔離したい場合に便利です。`docker run ... setup`で一度設定し、その後、コンテナをバックグラウンドで起動します。

```bash
docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run
```

24時間稼働に関わる行の役割は次のとおりです。

- `-d` — コンテナをバックグラウンドで動かし、ターミナルを開いたままにしません。
- `--restart unless-stopped` — サーバーの再起動後やクラッシュ後に、Dockerがコンテナを再び立ち上げます。手動で停止した場合に限り、再起動しません。
- `-v ~/.hermes:/opt/data` — 設定、キー、セッション、メモリをコンテナの外にあるサーバー上に保存するため、コンテナを作り直しても保持されます。

イメージにはもうひとつの保護機構があります。ゲートウェイプロセスはs6スーパーバイザーの管理下で動作します。ゲートウェイがクラッシュすると、コンテナ自体を失わずに数秒以内に再起動します。Dockerが外側からコンテナを動かし続け、s6が内部のプロセスを監視する二重の保護です。

Dockerで運用する場合の違いを覚えておいてください。`hermes update`コマンドでは更新されません。Dockerで更新するには、新しいイメージに置き換えます。最新版をダウンロードし、コンテナを作り直してください。

## すべてが動作し、再起動後も復旧することを確認する方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

systemctlでサービスの状態を確認し、ライブログを見ます。その後、サーバーを再起動して、ボットが自動でオンラインに戻るかを確認します。Hermesのセッションと応答は再起動後も保持され、未完了の応答は復旧後に配信されます。

</div>

ユーザーサービスの場合、状態とログは次のように確認できます。

```bash
hermes gateway status
journalctl --user -u hermes-gateway -f
```

VPSで推奨するシステムサービスは、次の範囲を使います。

```bash
sudo hermes gateway status --system
sudo journalctl -u hermes-gateway -f
```

最初は選んだサービス、次はその範囲のログを確認します。これらのunit名は既定の`~/.hermes`用です。別のHermes homeでは接尾辞が付く場合があるため、statusに出る正確なunit名を使います。システム版のテスト中にユーザーunitを監視しないでください。Hermesのログは`~/.hermes/logs/`に保存され、秘密情報は自動的にマスキングされるため、サポートに送っても安全です。

次にサーバーを再起動し、エージェントが自動で復帰するか確認します。これがサーバーの重要なテストですが、忘れる人がよくいます。

```bash
sudo reboot
```

サーバーに再接続できたらSSHで入り、システム版は`sudo hermes gateway status --system`とシステムjournal、linger付きユーザー版は`hermes gateway status`とユーザーjournalを確認します。その後Telegramでボットへメッセージを送ります。あなたが何もしなくても返信があれば、自動起動は正しく設定されています。これこそが目的です。

会話が失われる心配はありません。Hermesはセッションをディスクに書き込むため、ゲートウェイの再起動後も保持されます。さらに、ゲートウェイが応答を送信中にクラッシュした場合、タスクをもう一度実行するのではなく、復旧後にその応答を配信します。24時間稼働するボットには重要な点です。予期しない再起動があっても、会話は途切れません。

## サーバー上でターミナルにアクセスできるエージェントを保護する方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

主な保護策は3つです。ボットへのアクセスは初期設定で閉じられており（リストに載った人だけに応答します）、危険なコマンドの実行前にエージェントが確認を求め、完全に隔離するにはサーバー上でDockerサンドボックスを使います。サーバーで確認なしモード（YOLO）を有効にしないことをおすすめします。

</div>

サーバー上のエージェントは、あなたの監視なしで動作する、ターミナルにアクセスできるプログラムです。まず次の3つの設定を確認してください。

**ボットアクセスの制限。** 初期設定では、ゲートウェイはアクセスリストに載った人、またはダイレクトメッセージでコードによるリンクを完了した人にだけ応答します。ターミナルにアクセスできるボットには適切な設定です。知らない人がボットにメッセージを送っても、何もできません。アクセスリストには数値IDを使います。たとえばTelegramの場合は次のとおりです。

```bash
TELEGRAM_ALLOWED_USERS=123456789,987654321
```

**危険なコマンドの実行前に確認。** 破壊的な操作をする前に、エージェントは許可を求めます。確認を無効にするYOLOモードがありますが、無人運転するサーバーでは有効にしないことをおすすめします。確認は、知識のないまま取り消せない操作が起きるのを防ぐためにあります。

**完全隔離のためのサンドボックス。** エージェントがサーバーのメインシステムを物理的に見られないようにするには、コマンドをDockerコンテナ内で実行します。

```bash
hermes config set terminal.backend docker
```

これにより、エージェントがターミナルで行うすべての操作が隔離されたサンドボックス内で実行され、稼働中のサーバーには到達できなくなります。エージェントに自律的な操作を任せる場合に、妥当な保護策です。

## ボットが応答しない、またはゲートウェイがクラッシュする場合

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

まずサービスの状態とログを確認してください。原因は多くの場合、ボットトークン、アクセスリスト、またはモデルです。プロセス全体が完全にフリーズした場合は、systemdサービスのウォッチドッグタイマーが、応答の兆候を示さなくなったゲートウェイを再起動します。

</div>

ボットが応答しなくなったら、次の順に確認します。まず導入範囲を確認します。システム版は`sudo hermes gateway status --system`とシステムjournal、ユーザー版は`hermes gateway status`とユーザーjournalを使います。ゲートウェイが動いているのにメッセージが届かない場合、ほぼ必ずプラットフォームの設定に問題があります。ボットトークンが間違っているか、相手がアクセスリストに載っていません。同じHermes homeで`hermes gateway setup`を再実行し、システム版は`hermes gateway status --system`、ユーザー版は`hermes gateway status`で対象を確認します。設定成功だけでは正しいゲートウェイの稼働は証明できません。

モデルが空の応答や不自然な応答を返す場合は、`hermes model`で確認し、プロバイダーとサインイン状態を確かめます。「すべて壊れた」状態から復旧する一般的な手順は、`hermes doctor`、`hermes model`、`hermes setup`の後、システム版は`hermes gateway status --system`、ユーザー版は`hermes gateway status`を確認します。

プロセス全体がクラッシュせずにフリーズする、まれながら厄介なケースについても説明します。systemdサービスにはウォッチドッグタイマーがあります。`~/.hermes/config.yaml`に次の行を追加し、サービスを再インストールします。

```yaml
gateway:
  systemd_watchdog_seconds: 120
```

```bash
# 元の導入と同じHermes homeのVPSシステムサービス
sudo hermes gateway install --system --force
sudo hermes gateway status --system
```

ユーザー版なら、その範囲だけを`hermes gateway install --force`で作り直し、`hermes gateway status`を確認します。1つを選び、1ゲートウェイの修復のために両方を導入しないでください。

これでゲートウェイは定期的にシステムへ「動作中です」と通知し、通知が止まるとsystemdがプロセスを自動で再起動します。これはsystemdを使うLinux上でのみ機能し、プロセスがフリーズした場合に限られます。サーバーとメッセンジャーの間で通常のネットワーク障害が起きた場合には、ウォッチドッグタイマーは影響しません。

## Hermes Agentをサーバーで使う際によくある質問

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

よくある質問への簡単な回答です。VPSが必須か、1台のマシンで複数のボットを動かせるか、サーバーにグラフィカルインターフェースが必要か、エージェントをサーバーに置いたときにスケジュール済みタスクがどうなるかを説明します。

</div>

<div class="section">

### よくある質問

VPSが必要ですか。それとも自分のパソコンでも使えますか？

24時間稼働させるには、常に電源が入っているマシンが必要です。自分のパソコンも使えますが、電源を一度も切らないことが条件です。VPSのほうが便利です。常時稼働し、仕事中か睡眠中かにも左右されません。一般的なLinuxサーバーで十分です。ドキュメントではLinuxが第一級のサポート対象で、新規インストールしたUbuntuでテストされています。

1台のサーバーで複数のボットを動かせますか？

はい。Hermesにはプロファイルがあり、それぞれが独自のサービスを持ちます。`\<profile\> gateway install`のようなコマンドを実行すると、`hermes-gateway-\<profile\>`という名前の別サービスが作成され、それぞれ独立して動きます。プロファイルごとに設定、ボットトークン、メモリが用意されます。

サーバーにモニターやグラフィックス機能は必要ですか？

いいえ。サーバーは画面なしで動作し、ターミナルからSSHで管理します。この種のサーバーで動くエージェントにはブラウザーの自動操作は通常不要なので、`--skip-browser`フラグを付けてインストーラーを実行します。これでグラフィックスが必要な唯一の大容量コンポーネントを省けます。

不在中もスケジュール済みタスクは実行されますか？

はい。それがサーバーに移行する目的です。同じゲートウェイがスケジュール済みタスクを実行します。毎分スケジュールを確認し、実行時刻になるとタスクを実行して、同じチャットに結果を送ります。ゲートウェイはサービスとして24時間動くため、あなたが操作しなくてもスケジュールは自動で実行されます。

更新後やサーバー再起動後もボットは動き続けますか？

はい。設定、セッション、メモリは`~/.hermes`フォルダーに保存され、失われません。再起動後はシステムサービス（または`--restart unless-stopped`付きのDocker）がゲートウェイを自動で起動します。未完了の応答は再起動後に配信され、失われません。ただし、クラッシュ時に応答の送信がすでに途中まで進んでいた場合は、重複の可能性を示す通知とともに、もう一度届くことがあります。

</div>

<div class="section" role="doc-bibliography" aria-label="出典">

### 出典

- [Hermes Agent、インストール](https://hermes-agent.nousresearch.com/docs/getting-started/installation)
- [Hermes Agent、クイックスタート](https://hermes-agent.nousresearch.com/docs/getting-started/quickstart)
- [Hermes Agent、対応プラットフォーム](https://hermes-agent.nousresearch.com/docs/getting-started/platform-support)
- [Hermes Agent、メッセージングゲートウェイ](https://hermes-agent.nousresearch.com/docs/user-guide/messaging)
- [Hermes Agent、Dockerでの実行](https://hermes-agent.nousresearch.com/docs/user-guide/docker)
- [Hermes Agent、スケジュール済みタスク](https://hermes-agent.nousresearch.com/docs/user-guide/features/cron)
- [Hermes Agent、Nous Portal](https://hermes-agent.nousresearch.com/docs/integrations/nous-portal)
- [Hermes Agent、ドキュメント](https://hermes-agent.nousresearch.com/docs/)

</div>







[Ailoot](https://ailoot.ai/)を知ってください。

## Hermes Agentをサーバーで24時間稼働させる方法：よくある質問

### システムサービスを導入したのに、ゲートウェイが停止表示になるのはなぜですか？

範囲を指定しない確認は別のサービスを見る場合があります。システム版はhermes gateway status --systemとシステムのjournal、ユーザー版は通常のstatusとユーザーjournalを使います。Hermes homeも同じに保ってください。

### VPSのシステムサービスにもloginctl lingerは必要ですか？

いいえ。lingerはログアウト後や起動時にも動かすユーザーsystemdサービス用です。システム版は起動時に動きます。導入範囲を1つ選び、再起動後に同じ範囲の状態とボット応答を確認してください。


## Ailoot · 企業とそのプロジェクト群

Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。

企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。

Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。