OpenClaudeとは｜Claude Code派生のマルチLLM対応CLI

ターミナルで動くコーディングエージェントの選択肢は、この 1 年で一気に増えました。Claude Code の操作感はそのまま使いたい、しかしモデルやプロバイダーは自分で選びたい——そう考えたときに候補として挙がる OSS は数十本単位で存在し、どれを評価対象に入れるべきかを決めるだけでも一苦労です。

やっかいなのは、スター数やトレンド掲載といった指標が採用判断の材料になりにくいことです。README を読み込んでも「既存のツールと何が違うのか」「業務で使ってよいのか」は書かれていないことが多く、結局は手を動かして確かめるしかない、という結論になりがちです。

OpenClaude（Gitlawb/openclaude）は、この種のツールの中でも出自がはっきりしている点が特徴です。README が「Claude Code のコードベースを起点としている」と明言しており、この出自が機能面とライセンス面の両方に影響します。ゼロから独自実装された代替 CLI とは、評価すべきポイントが変わってきます。

本記事では、OpenClaude が何をするツールなのか、対応する LLM プロバイダーと初期設定、スマートルーティングやリポジトリマップといった主要機能、類似 OSS との違い、そして導入前に確認しておきたいライセンス上の論点を整理します。

なお、本記事は公開されている README・公式ドキュメント・公式サイト、および GitHub API から取得したリポジトリのメタデータに基づく整理であり、動作検証は行っていません。記述の根拠はすべて一次情報へのリンクとして示します。

OpenClaudeとは｜Claude Codeから派生したコーディングエージェントCLI

OpenClaude は、クラウドとローカル双方のモデルプロバイダーに対応したオープンソースのコーディングエージェント CLI です。README では「OpenClaude is an open-source coding-agent CLI for cloud and local model providers.」と定義されており、OpenAI 互換 API・Gemini・GitHub Models・Codex・Ollama などのバックエンドを、プロンプト・ツール・エージェント・MCP・スラッシュコマンド・ストリーミング出力というひとつのターミナル中心のワークフローで扱えることを掲げています。

リポジトリの description は「runs anywhere. uses anything」という簡潔なもので、OpenClaude 公式サイト では「not a chatbot wrapper or another ide plugin. an agent loop you can watch」と説明されています。チャットボットのラッパーでも IDE プラグインでもなく、観測できるエージェントループである、という位置づけです。

OpenClaudeの基本情報とリポジトリの活動状況

GitHub API から取得した 2026 年 9 月 17 日時点の基本情報は以下のとおりです。

メンテナンス状況を判断する材料として、実測値をそのまま並べておきます。リポジトリの作成は 2026 年 4 月 1 日で、そこから 5 か月強のあいだにタグは v0.30.0（2026 年 8 月 31 日公開）まで進んでいます。直近では v0.27.0・v0.28.0・v0.29.0・v0.29.1・v0.30.0 が短い間隔で連続して公開されており、最終 push は調査日の 2 日前にあたる 2026 年 9 月 15 日です。アーカイブされておらず（archived: false）、GitHub 上はフォークではない独立したリポジトリとして作成されています（fork: false）。

ここで注意しておきたいのが、この「fork: false」という属性と、次に述べる「Claude Code 由来」という出自は矛盾しないという点です。GitHub のフォーク機構を使って作られたリポジトリではない一方で、コードベースの起点が Claude Code であることは開発者自身が README に記載しています。

「Claude Code由来」であることを公式が明言している点

README の Disclaimer には、次の 3 点が明記されています。

• OpenClaude は独立したコミュニティプロジェクトであり、Anthropic との提携・承認・後援の関係にはない
• OpenClaude は Claude Code のコードベースを起点とし、以後マルチプロバイダー対応とオープン利用のために大幅に改変された
• 「Claude」および「Claude Code」は Anthropic PBC の商標である

この「派生である」という事実は、単なる出自の話にとどまりません。のちほど触れるように、ライセンスの構造がそのまま二層になっている理由でもあり、採用判断における最大の論点になります。また、後述の環境変数の名前に CLAUDE_CODE_USE_OPENAI のような接頭辞が残っていることも、ドキュメントから読み取れる出自の痕跡のひとつです。

OpenClaudeが対応するLLMプロバイダーと初期設定

OpenClaude を評価するとき、最初に確認したくなるのは「いま契約している API や手元の環境で動かせるのか」でしょう。README には対応プロバイダーの一覧表が掲載されており、その範囲はかなり広く取られています。

対応プロバイダーの全体像

README の一覧表を性格別に整理すると、おおむね次の 4 区分になります。

このほか Codex / Codex OAuth、Atomic Chat などの経路も用意されています。公式サイトでは「200 以上のモデル」に対応すると表現されていますが、これはプロバイダー数ではなくモデル数の話であり、README の一覧表とは粒度が異なります。

重要なのは、README 自身が「Provider Notes」として制約を明示している点です。挙動はすべてのプロバイダーで同一ではないこと、Anthropic 固有の機能が他プロバイダーには存在しない場合があること、ツールの品質は選択したモデルに大きく依存すること、小さめのローカルモデルは長いマルチステップのツールフローで苦戦しうること、CLI の既定値より出力上限が低いプロバイダーがあることが並んでいます。README は「最良の結果を得るには tool/function calling のサポートが強いモデルを使うこと」と推奨しています。マルチプロバイダー対応という言葉から「どのモデルでも同じように動く」と読み取ってしまうと期待値がずれるため、この注記は先に押さえておく価値があります。

インストールと初期セットアップの流れ

インストールは npm グローバルインストールで、Node.js は >=22.0.0 が必要です。Bun が必要になるのはソースからビルドする場合とローカル開発時のみと README に記載されています。

npm install -g @gitlawb/openclaude@latest

出典: Gitlawb/openclaude README（Quick Start / Install）。npm 上のパッケージは @gitlawb/openclaude として公開されています。Arch Linux 向けにはコミュニティ管理の AUR パッケージも案内されています。インストール後に ripgrep not found が表示された場合は、ripgrep をシステムに導入し、同じターミナルで rg --version が通ることを確認するよう README は指示しています。

起動後のプロバイダー設定は /provider コマンドによるガイド付きセットアップが基本経路で、GitHub Models については /onboard-github が用意されています。環境変数で直接指定する場合の最短手順として、README には次の例が掲載されています。

OpenAI を使う場合（macOS / Linux）:

export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_API_KEY=sk-your-key-here
export OPENAI_MODEL=gpt-4o

openclaude

出典: Gitlawb/openclaude README（Fastest OpenAI setup）

ローカルの Ollama を使う場合（macOS / Linux）:

export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_MODEL=qwen2.5-coder:7b

openclaude

出典: Gitlawb/openclaude README（Fastest local Ollama setup）

Ollama を使う場合、OpenClaude は Ollama ネイティブの chat API を利用し、同一セッションの履歴が OpenAI 互換シムで黙って切り詰められないよう、chat リクエストごとに 32768 トークンのコンテキストウィンドウを要求すると README は説明しています。この値は OPENCLAUDE_OLLAMA_NUM_CTX または OLLAMA_CONTEXT_LENGTH で変更できます。

なお、プロジェクトの .env は自動的には読み込まれません。README は /provider 経由の設定（.openclaude-profile.json に保存される）を推奨しており、環境変数で運用する場合は明示的に export するか、openclaude --provider-env-file .env を使うよう案内しています。

設定ディレクトリがClaude Codeと分離されている点

Claude Code をすでに使っている環境に OpenClaude を入れる場合、設定が衝突しないかは気になるところです。README はこの点を明確に記述しています。

OpenClaude は自身の設定を ~/.openclaude と ~/.openclaude.json に保存し、~/.claude・プロジェクト直下の .claude/ ディレクトリ・CLAUDE_CONFIG_DIR を読みません。新規ユーザーは空の OpenClaude 設定から始められ、Claude Code がインストールされている必要もない、とされています。

過去に .claude パスで OpenClaude を使っていた場合の移行についても、README は手順を限定しています。自分で作成した設定・コマンド・エージェント・スキル・スケジュールタスク等のファイルのみを、対応する .openclaude の場所へ意図的にコピーすること。.claude の一括コピーは行わないこと。そして、Claude Code の資格情報・認証ファイルはコピーしないことが明記されています。プロバイダー認証については、OpenClaude 側のプロバイダーセットアップを実行し直すか、プロバイダー固有の環境変数を export する方法が推奨されています。

Claude Code からの乗り換えや併用を検討する場合、この分離設計は評価上のプラス材料になる一方、「設定を丸ごと持ち込めば動く」という期待は成立しない点に注意が必要です。

OpenClaudeの主要機能｜スマートルーティング・リポジトリマップ・gRPCサーバー

OpenClaude の docs/ 配下には、機能ごとの独立したドキュメントが置かれています。ここでは、他のコーディングエージェント CLI との差分を生みやすい 4 つの機能を、公式ドキュメントの記述をもとに整理します。いずれも「何のために存在し、現状どこまで実装されているか」まで含めて確認しておくと、評価の精度が上がります。

コストを抑えるスマート自動ルーティング

スマート自動ルーティングは、ユーザーの各ターンを「simple」「strong」のいずれかに分類し、設定済みの安価なモデルと高性能なモデルへ振り分けるオプトイン機能です。「ok」「rename this」「what does this do?」といった些細なターンを安いモデルに回す、という発想です。

Smart auto-routing のドキュメント は、この機能がデフォルトでは無効かつ実験的であることを明示しています。分類器はプロンプト長・コードブロックの有無・推論や計画を示すキーワード・セッションの初回ターンかどうかといった高速なヒューリスティックで構成されており、完全な判定ではないとされています。迷ったときは strong 側に倒す設計のため、失敗モードは「安く済ませられたターンで節約できない」であって「重要なターンで黙って品質が落ちる」ことではない、と説明されています。この設計思想は、コスト最適化機能を業務で使う際の安心材料になります。

設定は ~/.openclaude.json に記述します。

{
  "agentModels": {
    "mini": { "model": "gpt-5-mini" },
    "main": { "model": "gpt-5" }
  },
  "smartRouting": {
    "enabled": true,
    "simpleModel": "mini",
    "strongModel": "main"
  }
}

出典: Smart auto-routing（Setup）

閾値調整用に simpleMaxChars / simpleMaxWords が用意されており、実行中は /smartroute コマンドで状態表示・有効化・無効化・各ロールのモデル変更ができます。挙動面では、モデルの選択は 1 ターンにつき 1 回で、ツール呼び出しを含むターン中は固定されること、simple ルートでの transport / server エラー時には strong で 1 回だけリトライすること（中断・認証・権限・bad-request はリトライしない）、組織のモデル allowlist で弾かれたモデルは strong に強制され、strong も不許可ならそのセッションではルーティングが自己無効化されることが記載されています。

コスト面で 1 点だけ注意が必要です。この機能はプロバイダー・ゲートウェイ・アカウントの価格情報を読みません。/cost に表示される節約額は一次リファレンスの価格表に基づく推定であり、実際の請求と一致しない場合があるとドキュメント自身が但し書きを付けています。

PageRankでコードベースを要約するリポジトリマップ

リポジトリマップは、セッション開始時点でモデルにコードベースの構造的な把握を与える機能です。モデルに Grep / Glob / Read でリポジトリを探索させる代わりに、重要なファイルとその主要シグネチャのランキング済み要約から開始させる、という位置づけになっています。

Repo Map のドキュメント によると、処理は次の 5 段階です。

1. ファイル列挙 — git ls-files --cached --others --exclude-standard で追跡ファイルと未追跡かつ無視されていないファイルを列挙する（git リポジトリでない場合はディレクトリ走査にフォールバック）
2. シンボル抽出 — tree-sitter で関数・クラス・型・インターフェースの定義とファイル間参照を抽出する
3. 参照グラフ構築 — ファイル A がファイル B で定義されたシンボルを参照していれば A→B の有向エッジを張る。エッジの重みは参照回数にシンボル名の IDF（逆文書頻度）を掛けた値で、get / set / value のような一般的な名前は寄与が小さくなる
4. PageRank — PageRank で構造的重要度を順位付けする。多くのファイルからインポートされているファイルが上位に来る
5. レンダリング — 上位からファイルパスと定義シグネチャを出力し、トークン予算に達した時点で打ち切る

結果は ~/.openclaude/repomap-cache/ にファイルパス・mtime・サイズをキーとしてキャッシュされ、2 回目以降は変更されたファイルのみ再パースされます。

制約もはっきり書かれています。対応言語は TypeScript（.ts, .tsx）・JavaScript（.js, .jsx, .mjs, .cjs）・Python（.py）のみで、追加の言語文法は将来のリリースで対応予定とされています。またセッションコンテキストへの自動注入は REPO_MAP フィーチャーフラグの背後にあり、デフォルトでは無効です。

REPO_MAP=1 openclaude

出典: Repo Map（Enabling auto-injection）

自動注入時のトークン予算は 1024 トークンで、bare モード（--bare）とリモートセッション（CLAUDE_CODE_REMOTE）ではスキップされます。一方、/repomap スラッシュコマンドはフラグの有無に関係なく常時利用でき、既定のトークン予算は 2048 トークンです。--tokens / --focus / --focus-symbols / --stats / --invalidate といったオプションで、予算の拡張や特定パス・特定シンボルの優先、キャッシュ統計の確認、キャッシュ破棄と再構築ができます。

対象コードベースが TypeScript・JavaScript・Python 中心かどうかで、この機能の価値は大きく変わります。評価時に最初に確認しておきたいポイントです。

エージェント別のモデル割当とステップ上限

Agent Routing のドキュメント では、2 つの機能が説明されています。いずれも設定ファイルとエージェントの frontmatter のみで完結し、コード変更は不要とされています。

ひとつはステップ上限です。カスタムエージェントは frontmatter に maxSteps を正の整数で指定することで、サブエージェントが実行できるツール使用ステップ数に上限を設けられます。上限に達すると OpenClaude は追加のツール呼び出しを止め、完了した作業・発見事項・残タスク・再実行が必要かどうかをまとめた簡潔な最終要約をサブエージェントに求めます。maxSteps を省略した場合や 0 のような不正値を設定した場合は、従来どおり無制限の挙動になります。

---
name: bounded-researcher
description: Use for focused research with bounded tool use
maxSteps: 8
---

You are a focused research agent.

出典: Agent Routing（Agent step limits）

もうひとつがエージェントルーティングです。~/.openclaude/settings.json の agentModels と agentRouting を使い、エージェントごとに異なるプロバイダー・モデルを割り当てられます。コスト最適化や、モデルごとの得意分野に応じた分業が用途として挙げられています。現在のプロバイダーの資格情報を再利用する「モデルのみ」の指定も可能です。組み込みエージェントである Explore / Plan / verification / code-reviewer も型名でルーティング対象にできます（一部はフィーチャーゲートや追加設定が前提）。

運用上の注意として、ドキュメントには settings.json の api_key が平文で保存されるという警告が明記されています。ファイルを非公開に保ち、バージョン管理にコミットしないことが求められています。チームで設定を共有する運用を考えている場合は、この点を設計に織り込む必要があります。

バックグラウンドセッションとヘッドレスgRPCサーバー

長時間かかる非対話のプロンプトを、現在のターミナルから切り離して実行する仕組みも用意されています。

openclaude --bg "fix failing tests"
openclaude --bg --name auth-refactor "refactor auth middleware"
openclaude ps
openclaude logs auth-refactor
openclaude logs auth-refactor -f
openclaude kill auth-refactor

出典: Gitlawb/openclaude README（Background sessions）

README はこの機能の実装範囲を明確に区切っています。バックグラウンドセッションはローカルの子プロセスであり、デーモンやネットワークサービスを起動するものではありません。メタデータとログは通常 ~/.openclaude/bg-sessions/ に保存され、保存先は OPENCLAUDE_CONFIG_DIR で変更できます（CLAUDE_CONFIG_DIR は無視されます）。終了状態は、プロセスが 0 を返した場合は exited、非ゼロまたは終了シグナルを処理した場合は failed、結果を観測できないまま消えた場合は stale、明示的な openclaude kill が成功した場合は killed に分類され、同一プロセスに対しては killed が優先されます。Windows では POSIX のシグナル名を推論しない、という注記もあります。

現時点での制約として、openclaude attach <id-or-name> は一致したセッションを報告して openclaude logs <id> -f を案内するところまでで、ローカルのバックグラウンドセッションに対する完全な端末再アタッチはまだ実装されていない、と README は述べています。

また OpenClaude はヘッドレスな gRPC サービスとしても動作し、双方向ストリーミングで他のアプリケーション・CI/CD・独自 UI に組み込むことを想定しています。クライアントは src/proto/openclaude.proto から生成でき、テスト用の CLI クライアントも同梱されています。CLI を人が叩く以外の使い方を検討している場合、この経路の有無は選定基準になり得ます。

このほか、VS Code 拡張が vscode-extension/openclaude-vscode として同梱されており、起動連携、プロバイダー対応の Control Center、エディタ内チャット、テーマ対応、Microsoft Foundry / Azure OpenAI の設定を起動ターミナルへ注入する機能が説明されています。README には /buddy というピクセルアートの相棒がプロンプト横に常駐する機能も紹介されていますが、こちらは評価軸というより遊び心のある付加機能です。

OpenClaudeと類似OSSの違い｜opencode・Crush・Claude Code Routerとの比較

「Claude Code の代替」という括りには性格の異なるツールが混在しています。ここでは代表的な 4 本と比較します。数値はいずれも 2026 年 9 月 17 日時点で GitHub API から取得したものです。

4つの類似OSSとの比較

この表から読み取れる差分は、大きく 4 つに整理できます。

1. 置き換えるレイヤーが違う — OpenClaude・opencode・Crush は CLI 本体そのものを置き換えます。一方 Claude Code Router は既存の CLI をそのまま使い、リクエストの経路だけを差し替えるコントロールプレーンです。既存環境をどこまで変えるかという点で、導入インパクトが大きく異なります。
2. 出自が違う — OpenClaude だけが「Claude Code のコードベースから派生した」と公表しています。opencode と Crush は独自実装です。派生であることは、操作感の近さという利点と、ライセンスの複雑さというコストを同時にもたらします。
3. ライセンスの構造が違う — opencode と Claude Code Router は単層の MIT で、ライセンスの読み解きはシンプルです。OpenClaude は後述のとおり二層構造で、SPDX も NOASSERTION と判定されています。Crush も SPDX は NOASSERTION です。
4. 実装言語による配布形態が違う — Crush は Go 製のため単一バイナリでの配布が容易です。TypeScript 製の 3 本は Node.js 環境が前提になります。

このほか、ベンダー主導の独自実装という第 3 の類型として QwenLM/qwen-code（Apache-2.0、スター 27,901）もあります。特定ベンダーがモデルとセットで CLI を提供する形で、ライセンスが Apache-2.0 と明快である点が特徴です。

複数の AI コーディングツールを束ねるルーター系の実装については 9router や ccx を、独自実装の代替 CLI については Kimi Code CLI を取り上げていますので、比較の材料にしてください。

「CLI本体を置き換える」か「ルーターを挟む」かという選定軸

上記の差分をそのまま選定軸に置き換えると、判断が進めやすくなります。

• Claude Code の操作感・スラッシュコマンド・エージェント構成をできるだけ保ったまま、モデルだけを広げたい — OpenClaude のような派生系が候補になります。ただしライセンスの読み解きが必要です。
• ライセンスの単純さを優先し、社内説明のコストを下げたい — opencode（MIT）や qwen-code（Apache-2.0）のような、単層ライセンスの独自実装系が候補です。
• 既存の Claude Code 環境はそのまま残し、モデルの向き先だけを切り替えたい — Claude Code Router のようなルーター系が候補になります。CLI の入れ替えを伴わないため、差し戻しも容易です。
• 配布・インストールの単純さを重視する — Go 製で単一バイナリ配布が可能な Crush のような選択肢があります。

どれが優れているかではなく、どの制約を優先するかで答えが変わる構図です。自分のチームにとって動かせない制約はどれかを先に決めると、候補は自然に絞り込めます。

OpenClaudeのライセンスと導入前に確認したい注意点

OpenClaude を評価するうえで、機能よりも先に確認しておきたいのがライセンスです。ここは事実の引用に徹し、法的な助言は行いません。実際の可否判断は必ず自社の法務確認を経てください。

SPDXがNOASSERTIONである理由とLICENSEの二層構造

まず、表示に食い違いがあります。README のバッジは license-MIT を掲げていますが、GitHub API が返す SPDX 識別子は NOASSERTION（GitHub の画面上は "Other"）です。これは、標準的な OSS ライセンスとして自動判定できないことを意味します。

OpenClaude の LICENSE を読むと、理由がわかります。要旨は次のとおりです。

• このリポジトリは Anthropic の Claude Code CLI 由来のコードを含む
• オリジナルの Claude Code のソースはプロプライエタリであり、Copyright (c) Anthropic PBC. All rights reserved. として Anthropic の商用利用規約の対象である
• OpenClaude のコントリビューターによる改変・追加部分のみが、法的に可能な範囲で MIT ライセンスとして提供される
• 派生元のコードは引き続き Anthropic の著作権下にあり、本プロジェクトは Anthropic からプロプライエタリソースを再配布する許諾を得ていない
• 利用者およびコントリビューターは、自身の法的立場を各自で評価すべきである

README の License セクションも「MIT for OpenClaude contributors' modifications; the derived Claude Code remains Anthropic's.」と、この二層構造を短く要約しています。

つまり、OpenClaude を「MIT ライセンスの OSS」と単純化して理解するのは正確ではありません。リポジトリ自身が「再配布の許諾を得ていない」「各自で法的立場を評価せよ」と明記している以上、業務利用や社内配布を検討する場合は、自社の法務確認を前提に置くのが妥当です。個人の学習・検証用途と、組織としての導入では、確認すべき範囲が変わります。

なお本記事執筆時点で、リポジトリはアーカイブされておらず（archived: false）、GitHub 上のフォークでもなく（fork: false）、公開状態（private: false / disabled: false）で維持されています。ライセンスの論点は、リポジトリの活動状況とは切り離して評価する必要があります。

ライセンス以外に確認したい運用上の留意点

ライセンス以外にも、README とドキュメントが自ら明示している留意点がいくつかあります。いずれも隠されているものではなく、公式に書かれている内容です。

• プロバイダー間で挙動は同一ではない — Anthropic 固有の機能が他プロバイダーに存在しない場合があり、ツールの品質は選択したモデルに依存します。小さいローカルモデルは長いマルチステップのツールフローで苦戦しうる、出力上限が CLI の既定値より低いプロバイダーがある、といった注記も README に並んでいます。
• Web 検索のフォールバック経路 — 非 Anthropic 系モデルでは WebSearch が DuckDuckGo 経由で動作します。README はこのフォールバックが検索結果のスクレイピングで動作しており、レート制限・ブロック・DuckDuckGo の利用規約の対象になりうると注記しています。より確実な経路が必要な場合は Firecrawl（FIRECRAWL_API_KEY）を設定するよう案内されています。業務で継続的に使う想定なら、ここは設計判断が必要になります。
• API キーの平文保存 — 前述のとおり、settings.json の api_key は平文で保存されます。ファイルの権限管理とバージョン管理からの除外が前提になります。
• Claude Code からの移行時の資格情報 — README は .claude の一括コピーを避け、Claude Code の資格情報・認証ファイルはコピーしないよう明記しています。移行手順を雑に進めないための注意点です。
• 一部機能が実験的・未実装 — スマートルーティングはデフォルト無効かつ実験的、リポジトリマップの自動注入もフラグでデフォルト無効、バックグラウンドセッションの完全な端末再アタッチは未実装です。これらを前提に導入価値を見積もる必要があります。

OpenClaudeの採用判断チェックリスト

ここまでの内容を、判断の分岐として整理します。

評価対象に入れる価値がありそうなケース

• Claude Code の操作感・スラッシュコマンド・エージェント構成を保ったまま、OpenAI 互換 API やローカルの Ollama を使いたい
• モデルごとのコスト最適化（スマートルーティング、エージェント別のモデル割当）を CLI の中で完結させたい
• gRPC 経由で CI/CD や自社 UI にエージェントループを組み込みたい
• 対象コードベースが TypeScript・JavaScript・Python 中心で、リポジトリマップの恩恵を受けやすい
• VS Code 拡張を含めた一体運用を検討している

慎重な検討が必要なケース

• 業務利用・商用利用にあたり、ライセンスの明確さが要件になる（SPDX は NOASSERTION、Anthropic 非公認、再配布許諾なしと LICENSE が明記）
• 単層の MIT や Apache-2.0 の選択肢でも要件が満たせる（opencode / qwen-code など）
• 既存の Claude Code 環境を維持したまま、モデルの向き先だけを切り替えたい（ルーター系のほうが適します）
• Go 製の単一バイナリ配布が配布要件に含まれる（Crush などが該当します）
• 実験的機能やフィーチャーフラグの管理コストを運用に持ち込みたくない
• 複数プロバイダーで挙動が揃うことを前提にした社内標準化を考えている

次の一歩

判断材料をさらに集める場合は、一次情報を直接確認するのが確実です。機能と制約の全体像は Gitlawb/openclaude のリポジトリ の README、各機能の詳細は docs/ 配下のドキュメント、ライセンスの論点は LICENSE の原文が根拠になります。とくにライセンスについては、要約ではなく原文を法務担当と一緒に読むことをおすすめします。

繰り返しになりますが、本記事は公開ドキュメントとリポジトリのメタデータに基づく整理であり、動作検証は行っていません。実際の応答品質や速度は、選択するモデルと環境に依存します。最終的な採用可否は、自社の要件に照らして判断してください。

関連情報

AI コーディングエージェントの社内導入や、開発ワークフローへの組み込みをご検討の際は、お問い合わせフォーム からご相談いただけます。技術選定の整理段階からのご相談にも対応しています。