II-Agent を自前で動かす前に読む: 構成、設定、向き不向き

II-Agent が埋めようとしているのはどの穴か

README は II-Agent を「open-source AI agent built for real work」と位置づけ、想定読者として solo developer、research team、社内ツールを構築する enterprise の三つを挙げている。ここで扱われる問題は、モデルの推論能力そのものではなく、エージェントを動かすための周辺装置をどう自前で持つかである。README は BYOK（Bring Your Own API Keys）を明示し、コストとモデルプロバイダの制御を利用者側に残すと説明している。つまり、ホスト型エージェントサービスにワークフローと API キーを預けたくない層に向けた道具立てである。機能一覧は Build（モバイルアプリ、Web サイト、絵本、動画・画像生成、ライブ編集、Plan Mode）、Research（Fast / Deep Research、調査ブリーフからの Web サイト生成）、Automate & Integrate（スキル、Gmail・Slack・GitHub・Notion などの連携）、そして Chat、Agent、Documents、Slides の各ドメインに分かれている。単一目的のライブラリではなく、複数の用途を一つのバックエンドに載せた構成だと読める。

バックエンド、フロントエンド、そして三つのミドルウェア

make dev-all が起動するのは次の構成である。Backend は http://localhost:8000、Frontend は http://localhost:1420、PostgreSQL は localhost:5432、Redis は localhost:6379、MinIO は http://localhost:9001（minioadmin/minioadmin）。MinIO は S3 互換ストレージとして説明されている。つまり、エージェントの会話状態や生成物をどこかに保存する必要があり、その保存先をローカルの PostgreSQL と MinIO に寄せた設計である。Redis はポート番号しか記載がないため、何をキューイングしているかは README からは読み取れない。ここは推測せず、実運用前に docker compose の定義を読むべき箇所である。フロントエンドの開発サーバーは 1420 番で起動すると書かれている一方、make frontend-dev の説明では 5173 番と記載されており、両者は一致していない。どちらのポートが正なのかは README からは確定できない。Docker Compose を使う make stack の経路では、ローカルの Python と Node を必要としないと明記されている。

make setup と MODEL_CONFIGS に何を書くか

手順は 4 段階で示されている。git clone の後、make setup を実行すると .env ファイルの生成と依存関係のインストールが行われる。次に LLM の API キーを設定する。方法は二つある。Option A は .env にインライン JSON を書く方法で、README の例は MODEL_CONFIGS='[{"model_id":"claude-sonnet-4-6","provider":"Anthropic","api_key":"sk-ant-...","display_name":"Claude Sonnet 4","is_default":true}]' である。Option B は model_configs.example.yaml を model_configs.yaml にコピーしてキーを埋め、.env に MODEL_CONFIGS_FILE=model_configs.yaml を設定する方法である。最後に make dev-all を実行する。生成される設定ファイルは三つで、.env はデータベース、Redis、ストレージ、認証、LLM キーを担当し、frontend/.env は API URL、Google OAuth、テーマを担当し、model_configs.yaml は LLM モデル定義を担当する。プロバイダは OpenAI（例: gpt-5.4）、Anthropic（例: claude-opus-4-6）、Google（例: gemini-3.1-pro-preview）が表に挙がっており、Anthropic と Google は Vertex AI 経由も選べると書かれている。Vertex AI、Azure、セルフホストモデルの詳細は model_configs.example.yaml を参照せよという指示で、README 本文には展開されていない。

make コマンド群が示す運用の粒度

用意されているコマンドは make help、make dev-all、make infra、make backend-dev、make frontend-dev、make db-migrate、make lint、make format、make test、make stack である。make infra は Postgres、Redis、MinIO のみを起動するので、バックエンドをローカルで走らせながらミドルウェアだけコンテナに置く、という分割が可能である。make db-migrate が独立している点は、スキーマ変更がコードのデプロイと別タイミングで走ることを意味する。make lint と make format はバックエンドとフロントエンドの両方に効くと書かれている。Docker 経路では docker/.stack.env.example を docker/.stack.env にコピーして認証情報を編集し、make stack、make stack-build、make stack-down、make stack-logs を使う。stack-build が存在することは、イメージの再ビルドが日常的な操作として想定されているということで、依存の更新時にビルド時間がそのまま開発サイクルに乗る。

この構成が重すぎる場合と、代わりに何を使うか

II-Agent は PostgreSQL、Redis、MinIO を前提とする。ノート PC で短いスクリプトからエージェントを組みたいだけなら、この三つを常時起動しておく理由は薄い。同じ目的に対して、LangGraph や OpenAI Agents SDK のようなライブラリは、状態管理を SQLite やメモリ、あるいは呼び出し側の任意のストアに委ね、Web UI やオブジェクトストレージを同梱しない。アプローチの差は明確で、II-Agent はアプリケーション一式（フロントエンド、認証、ストレージ、スライドや文書の生成まで）を一つのリポジトリにまとめ、ライブラリ側はエージェントのループとツール呼び出しの抽象だけを提供して残りを利用者に任せる。どちらが優れているという話ではなく、既に自前の Web アプリとストレージを持っているチームにとっては、II-Agent の同梱物の多くが重複になる。逆に、ゼロから管理画面とファイル保存を用意したくない場合、この同梱は作業量を減らす。判断材料は、自前で持っている部品の数である。

ライセンスと更新コストについて確認できること

ライセンスは Apache-2.0 で、README もバッジと本文の両方で 100% open source と明記している。フォークと拡張が想定された許諾条件であり、著作権表示と変更の明示といった同ライセンスの条件に従う必要がある。具体的な義務の解釈は法務の領域なので、ここでは条件の存在を指摘するにとどめる。更新の面では、リポジトリの最終 push が 2026-08-16、リリースは v0.2（2025-06-11）、v0.3（2025-07-07）、v0.4（2025-07-29）と記録されている。v0.x が続いており、API や設定キーの互換性が安定しているという保証は資料からは読み取れない。MODEL_CONFIGS の JSON スキーマや model_configs.yaml の項目名がマイナーリリースで変わる可能性を前提に、設定をバージョン管理下に置き、差分を追う運用が現実的である。make db-migrate が独立コマンドとして存在する以上、アップグレード時にはマイグレーションの実行が別手順として必要になる。

採用前に潰しておくべき確認項目

第一に、frontend のポートが 1420 と 5173 のどちらなのかを make の定義で確認する。README 内で記述が割れている。第二に、Redis が何に使われているかを docker compose の定義とバックエンドの設定キーから確認する。README にはポート番号以外の説明がない。第三に、model_configs.example.yaml を開き、Vertex AI、Azure、セルフホストモデルの各項目が自組織の調達条件に合うかを確認する。README は詳細をこのファイルに委ねている。第四に、make stack でビルドされるイメージが社内プロキシやレジストリ制限の下で取得可能かを試す。Docker が前提条件の第一に挙がっているため、ここが通らなければ他の検討は進まない。第五に、make test がどの範囲を覆っているかを実際に走らせて確認する。テストの内容について README は何も述べていない。

編集部の結論

採用を検討すべきなのは、エージェントの実行基盤を自前のインフラで持ちたい開発者、BYOK でモデル費用を管理したいチーム、そしてフォークして UI やスキルを改変する前提で使える土台を探している組織である。逆に、単発のタスクをブラウザから試したいだけの利用者には、公開されている web app（agent.ii.inc）で足りる可能性が高く、PostgreSQL、Redis、MinIO を抱える構成は過剰になる。判断の前に確認すべきは、make setup が生成する .env と model_configs.yaml の中身、そして make stack でビルドされるイメージが社内のネットワーク制約下で取得できるかどうかである。

公式情報源

1. Intelligent-Internet/ii-agent on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases