複数のAIへの接続を一か所で管理するOSS「GoModel」の仕組みと導入前の注意点

「部署ごとに別々のAIの契約が増えて、誰がどのモデルにいくら使っているのか分からない」「AIエージェントにつなぐ道具も増えてきた。鍵の管理をどこかに集約できないか」——生成AIの利用が社内に広がった企業で、情報システムの担当者が抱えがちな悩みです。その答えとして注目されているのが、アプリとAIの提供元の間に置く中継役（ゲートウェイ）です。ただ、中継役を置けば管理が楽になる、という話で終わりません。本当は、鍵と道具と記録が一か所に集まるぶん、その一か所の守りが会社全体のAI利用の守りになるのです。この記事では、Go言語で書かれた中継役のOSS「GoModel」について、一次情報で確かめられる仕組み、公開済みのセキュリティ勧告、初期設定の注意点、導入前に決めることを整理します。導入や設定の手順は扱いません。

GoModelとは何か。2026年10月時点で確かめられる事実

GoModel は、ENTERPILOT という組織がGitHubで公開している、AIの中継役のOSSです。READMEによると、アプリからの問い合わせを一つの窓口で受け、OpenAI や Anthropic、Google の Gemini、手元で動かす Ollama など多くの提供元へ取り次ぎます。受け付ける形式は OpenAI と Anthropic の二つの形式に合わせてあり、各社の公式の部品をそのまま使い、つなぐ先だけを GoModel に向ければよいと説明されています。

公開の時期と規模も確かめておきます。組織のアカウントは2025年8月12日に、リポジトリは2025年12月5日に作られています。2026年10月21日時点でスターはおよそ1,260、複製（フォーク）は117で、最後の更新は2026年10月20日です。リリースの一覧では、2026年10月20日に0.1.105版が公開されており、数日おきに新しい版が出る活発な開発が続いています。組織が公開しているリポジトリは5つで、運営する会社の名前や所在地は、確認した一次情報には書かれていません。

ライセンスはMITで、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。2026年4月には海外の技術者向け掲示板 Hacker News に作者自らが紹介の投稿をし、217の支持と75の書き込みを集めました。そこでは、作者がこのOSSを使い続けられる形で公開し続けたいとしつつ、将来の約束はできないと答えている場面もあります。

AIの中継役（ゲートウェイ）が求められる理由

社内でAIの利用が広がると、部署ごと、アプリごとに別々の提供元の鍵が配られ、誰がどのモデルをどれだけ使ったのかが追えなくなりがちです。退職者や外部委託先の鍵が残り続ける、上限を決めずに使われて請求が膨らむ、といった問題も起きやすくなります。中継役は、こうした鍵・費用・利用記録の散らばりを一か所に集めるための仕組みです。

アプリは提供元の鍵を持たず、中継役が発行した社内用の鍵だけを持つ形にできれば、提供元の鍵が漏れる経路を減らせます。障害時に別の提供元へ切り替える、同じ問い合わせへの答えを再利用して費用を抑える、といった運用上の利点もあります。GoModel のREADMEも、費用の節約と信頼性の二つを大きな売りにしています。

この分野には、Python で書かれた LiteLLM などの先行する選択肢があります。GoModel のREADMEは自らを LiteLLM と Portkey の代わりになるものと位置づけ、それぞれについて「最近攻撃を受けた」「GitHubでの保守が止まった」と書いています。これらは GoModel 側の主張で、この記事では個別に確かめていません。紹介の投稿では、中継役の配布物を通じた攻撃（供給網の攻撃）への備えが話題になり、Go言語で一つの実行ファイルにまとめる作りは部品の入れ替えに強いという意見が出ています。どの製品であれ、中継役は狙われやすい位置にあるという点は共通です。

仕組み1：一つの窓口で複数のAIの提供元へ取り次ぐ

READMEによると、GoModel が取り次げる提供元は、大手の言語モデルの提供元から、複数の提供元を束ねる中継サービス、クラウド事業者のAIの窓口、手元で動かすモデルの実行環境まで、30近くにのぼります。OpenAI の形式で受け付ける提供元であれば、一覧にないものもつなげるとされています。

取り次ぎの工夫として、READMEは次のような機能を挙げています。よく似た問い合わせへの答えを覚えて再利用する仕組み、障害時に予備の提供元へ自動で切り替える仕組み、決まった名前の「仮のモデル」の裏で複数のモデルに振り分ける仕組み、同じ利用者の一連のやり取りを同じ提供元に送り続ける仕組みです。どの問い合わせがどの提供元に届いたかが、設定しだいで変わるという点は、社内の情報の扱いを考えるうえで押さえておくべきところです。

たとえば、障害時の切り替え先に、社内で認めていない提供元が入っていれば、本来は送ってはいけない情報がそこへ流れる可能性があります。答えの再利用も、別の利用者に以前の答えが返らないよう、区切り方の確認が要ります。便利な機能ほど、情報がどこへ流れ、どこに残るかを先に決めておくことが前提になります。

仕組み2：費用・上限・利用者ごとの使えるモデルの管理

READMEによると、GoModel は問い合わせごとの費用の見積もり、利用の分析、支出の内訳を管理画面で示します。利用者・チーム・鍵ごとに支出の上限を設けたり、問い合わせの回数や量の上限を決めたりすることもできます。利用者が自分の鍵で、残りの予算や上限までの余裕を確かめられる仕組みもあるとされています。

権限の面では、「利用者の階層」という考え方で、鍵・使えるモデル・予算・利用記録を部署やチームの単位で区切れると説明されています。グループ・利用者・鍵ごとに使ってよいモデルの一覧を決め、上の階層の制限が下の階層にも重なってかかる作りです。社内の組織図に沿って、使えるモデルを絞る運用を想定したものと読み取れます。

ただし、こうした制限が効くのは、問い合わせが必ず GoModel を通る場合だけです。社員が提供元の鍵を別に持っていれば、中継役を素通りして使えてしまいます。中継役の導入は、提供元の鍵を中継役だけに持たせ、直接の利用を止める社内の取り決めとセットで考える必要があります。仕組みだけを入れても、抜け道が残れば管理は形だけになります。

仕組み3：MCPの道具群を一つにまとめる窓口

GoModel には、AIの中継だけでなく、MCP（AIエージェントが外部の道具やデータを呼び出すための共通の約束事）の中継役になる機能もあります。公式の説明によると、複数のMCPサーバーを一つの窓口の裏にまとめ、AIエージェントはその窓口一つにつなぐだけで、すべての道具を呼び出せるようになります。

公式の説明では、利用者の階層ごとに見せる道具を絞る、道具の許可と禁止の一覧で見える範囲を小さくする、といった制御ができるとされています。また、その先のMCPサーバーへの接続用の鍵は GoModel が持ち、AIエージェントには見せない作りだと説明されています。道具の呼び出しも利用記録や監査の記録に残り、回数や予算の上限も効くとされています。

この設計は、道具ごとの鍵を各端末に配らずに済むという利点がある一方で、道具を使うための鍵が中継役に集まることも意味します。公式の説明自身も、中継役から社内の住所を含む宛先へ接続できるため、管理の書き込み権限を絞り、外への通信の決まりを設けるよう注意を促しています。後で扱う勧告は、まさにこの窓口に関わるものでした。

監視と記録：ログ・監査の機能をどう見るか

READMEによると、GoModel は監査の記録、問い合わせの記録、管理画面での問い合わせの流れのリアルタイム表示を備え、外部の監視の仕組みへ数値や処理の経過を渡す形式にも対応しています。問い合わせに部署名などの目印を付けて、目印ごとに利用を集計する機能もあります。

記録が一か所に集まるのは、内部の不正や事故の調べに役立ちます。誰が、いつ、どのモデルに、どのくらいの量を問い合わせたかを追えるからです。一方で、問い合わせの中身を記録に残す設定にすれば、その記録自体が機密の塊になる点に注意が要ります。社員が入力した顧客の情報や社内の資料が、中継役の記録の保存先にそのまま残る可能性があるからです。

記録を残す範囲、保存期間、記録を見られる人を、導入の前に決めておくべきです。READMEの説明だけでは、既定でどこまでの中身が記録に残るのかは確かめきれませんでした。確認できる情報が限られる部分は、試験用の環境で、機密を含まない問い合わせを使って実際の記録の中身を人が確かめるのが無難です。

無料のOSS部分と、商用版「GoModel Pro」の境目

READMEによると、GoModel には「GoModel Pro」という商用版があります。中継の仕組み・設定・管理画面は同じで、そこに許諾を受けて使う追加機能が加わる形です。挙げられている追加機能は、問い合わせの文章を縮めて費用を抑える機能、賢い振り分け、社内の認証の仕組みと連携するシングルサインオン（SSO）です。

つまり GoModel は、中心部分をMITライセンスのOSSとして公開し、一部の機能を商用で提供する形（オープンコア）です。費用管理や上限、MCPの中継、監査の記録といった、この記事で扱う機能の多くは、READMEの機能一覧ではOSSの側に並んでいます。管理画面への社員のログインを社内の認証と結びつけたい場合は、商用版が必要になる点は、導入の検討で見落としやすいところです。

比べる観点を、中継役を置かない場合と置く場合で並べます。

観点	提供元へ直接つなぐ	GoModel のような中継役を置く
提供元の鍵の置き場所	各アプリ・各部署に散らばる	中継役に集まる（中継役の守りが重要になる）
費用と上限の管理	提供元ごとに別々に確認	利用者・チーム・鍵ごとに一か所で管理
使えるモデルの制限	契約単位でしか絞れないことが多い	利用者の階層ごとに一覧で絞れる
MCPの道具の鍵	各端末やエージェントに配る	中継役が持ち、エージェントには見せない
攻め手から見た価値	一つ破られても範囲は限られる	一か所で多くの鍵と道具に届きうる
新たに要る運用	少ない	中継役の更新・公開範囲・記録の管理

安全性の評価：注意付きとした根拠

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。GoModel の判定は「注意付き」です。最大の根拠は、2026年8月30日に公開されたセキュリティ勧告です。深刻度は「中程度」で、まとめたMCPの道具の窓口に、条件によっては認証なしで届いてしまう、という内容でした。

勧告ページでは修正版が示されていますが、勧告を受けて改めた点は、リリースの一覧の説明文には明記されていません。どの版で何が直ったかは、勧告ページを正として確かめる必要があります。あわせて、運営元の実績を外から確かめにくいことも注意点です。組織のアカウントは2025年8月に作られ、運営する会社の名前は確認できませんでした。

一方で、ライセンスはMITで条件は明快です。報告窓口を定めた方針の文書もあり、非公開で報告する経路が示されています。勧告が実際に外部の研究者から報告され、公開されたことは、報告の受け付けが機能している表れとも読めます。ただし、精査で他に問題が見つからなかったことは、安全の保証ではありません。中継役は鍵の集まる場所なので、他の道具以上に慎重な確認が要ります。

公開された勧告の中身と、修正版の有無

勧告の要旨は次のとおりです。GoModel の説明書きでは、ある種の「なりすまし」への備えとして、問い合わせの出どころを確かめる仕組みがあるとされていました。勧告によると、その確かめ方が実際には十分に働かず、利用者のブラウザーを踏み台にして、手元で動く GoModel のMCPの窓口に外から届きうるというものです。DNS（ネット上の名前を住所に変換する仕組み）の応答をすり替える手口を前提とした問題で、この記事では手口の詳細は扱いません。

勧告は、初期設定で管理用の鍵が設定されていない場合、MCPの窓口に認証なしで届き、まとめた道具や、その道具が持つ鍵にまで届きうると指摘しています。一方で、管理用の鍵を設定していれば、認証なしでの到達は防げるとも書かれています。勧告の主眼は、説明書きで示した防御が働いていなかった点にあります。

項目	勧告ページで確認できた内容
識別番号	GitHubの勧告番号のみ（CVEの番号は付いていない）
公開日	2026年8月30日
深刻度	中程度（CVSS 第4版で5.8）
影響を受ける版	0.1.52版から0.1.79版
修正された版	0.1.80版
報告者	外部の研究者2名

修正版の有無は、勧告ページで0.1.80版と示されていることを確かめました。リリースの一覧には2026年10月20日の0.1.105版まで並んでいます。ただし、修正の中身をこの記事で検証したわけではありません。自社で使う場合は、勧告ページを確かめ、0.1.80版以降であること、そのうえで最新の版を使っていることを人が確認してください。

初期設定の「鍵なし」で動く点に注意

勧告と並んで押さえたいのが初期設定です。公式の設定の説明では、管理用の鍵の既定値は空で、そのことが「安全でない状態」と明記されています。鍵が空のままだと、管理画面と管理用の窓口も開いた状態になると説明されています。最初の鍵を作るための配慮ですが、その間は誰でも管理の操作ができうる状態です。

READMEの手早い始め方は、配布元のスクリプトを取得してそのまま実行させる形や、コンテナで立ち上げる形で、いずれも管理用の鍵を設定しないまま動き始めます。試しに動かすには手軽ですが、試しに立てた中継役が、そのまま社内の共有の場所で使われ続けることは珍しくありません。勧告も、初期設定で鍵が設定されないことを問題の前提に挙げていました。

社内で検証する場合も、最初から管理用の鍵を設定し、公開する範囲を限った環境で動かすことを決まりにしておくべきです。配布元のスクリプトをそのまま実行させる導入方法は、配布元を全面的に信頼することになるため、社内の導入の手順に照らして、配布物の出どころと版を確かめてから使う形に置き換えることも検討してください。

悪用されうるリスク：鍵と道具が一か所に集まる

中継役が攻め手に狙われうる理由は、そこに価値が集まるからです。GoModel のような中継役には、各社のAIの提供元の鍵、MCPの道具の鍵、社員の問い合わせの記録が集まりえます。一か所を破られれば、それら全部に届く可能性があります。

考えられる被害は、提供元の鍵を盗まれて高額な利用をされる、MCPの道具を通じて社内のデータや仕組みに手を伸ばされる、記録から社内の情報を読み取られる、といったものです。また、公式の説明が注意しているとおり、中継役が社内の住所を含む宛先へ接続できる場合、管理の権限を奪われると、中継役を足がかりに社内の仕組みを探られるおそれもあります。これらは一般論としての推測で、GoModel で実際に被害が起きたという報告は、確認した範囲では見当たりませんでした。

加えて、AIエージェントが中継役を通じて道具を呼ぶ使い方では、エージェントが読んだ文書に紛れ込んだ命令によって、意図しない道具が呼ばれる危険も残ります。中継役で見える道具を絞ることは、この危険を小さくする手段の一つです。中継役は守りを強める道具にもなりますが、それ自体が守るべき対象でもある、という二面性を前提にしてください。

導入を検討するときに確かめること

GoModel を社内の中継役として使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

GoModel を使うかどうかにかかわらず、AIの中継役を置く企業に共通する対策があります。第一に、中継役を最重要の仕組みとして扱うことです。鍵が集まる場所なので、認証の設定、公開範囲の制限、版の更新を、社内の重要なサーバーと同じ水準で管理します。

第二に、提供元の鍵を中継役だけに持たせることです。社員やアプリが提供元の鍵を直接持つ経路を残すと、中継役の制限も記録も素通りされます。第三に、MCPの道具を中継役にまとめる場合は、見せる道具を役割ごとに絞り、書き込みや削除のできる道具は特に限定します。中継役から社内への通信の宛先も、必要な範囲に制限します。

第四に、勧告と更新の見張りを担当者の仕事として決めることです。GoModel のように数日おきに版が出るOSSでは、気づかないうちに古い版が残りがちです。第五に、社内のAI利用の規程に、使ってよい提供元、中継役の管理者、記録の保存期間、見直しの頻度を書き込んでおきます。仕組みと規程の両方がそろって、初めて中継役は守りの役に立ちます。

AIに任せる範囲と、人が決める範囲

中継役には、問い合わせを賢く振り分ける機能や、問い合わせと答えの中身を点検する機能など、判断を自動化する仕組みが増えています。しかし、何を許し、何を止めるかの判断をAIに委ねてはいけません。AIに任せてよいのは、決めた規則の範囲での振り分けや、怪しい利用を拾い上げて知らせるところまでです。

人が決めるのは、つないでよい提供元、使えるモデル、予算の上限、見せる道具、記録の範囲です。自動で振り分けたり止めたりした場合は、なぜそう判断したかの根拠を記録に書かせ、人が確認する範囲を先に決めておくことが大切です。避けたい使い方を挙げます。

• 試しに立てた中継役を、管理用の鍵を空のまま社内の共有の場所で使い続ける
• 勧告が出ていることを知らずに、影響を受ける版のまま使い続ける
• 障害時の切り替え先に、社内で認めていない提供元を入れたままにする
• 書き込みや削除ができるMCPの道具を、すべての利用者に見せる
• 振り分けや遮断の理由を記録せず、AIの判断にそのまま任せる

中継役は、うまく使えば社内のAI利用を見える形にする強い道具です。そのぶん、設定の誤りが会社全体のAI利用に広がることを前提に、人の確認を手順に組み込んでください。

よくある質問：修正版にすれば安心してよいのか

答えは「既知の問題への手当ては済んだが、それだけでは足りない」です。勧告で示された問題は0.1.80版で修正されたとされていますが、中継役には今後も新しい問題が見つかる可能性があります。報告窓口の方針には、どの版を保守の対象にするか、どのくらいの期間で対応するかは書かれていません。版を上げ続ける運用が前提になります。

また、勧告そのものが示すとおり、管理用の鍵を設定していれば認証なしの到達は防げました。つまり、修正版を使うことと、鍵を設定し公開範囲を絞ることは、両方そろえて初めて意味を持つ守りです。どちらか一方に頼らない構成にしてください。

「他の中継役のほうが安全なのか」という問いもありそうです。GoModel のREADMEは他の製品の問題に触れていますが、どの製品にも勧告は出うるもので、製品名だけで安全を判断することはできません。比べるときは、勧告への対応の速さ、報告窓口の有無、初期設定の安全さ、更新の頻度といった観点で、一次情報を確かめるのが確実です。

• GoModel の機能・勧告・設定の既定値・ライセンスは、GitHubのリポジトリ（README・リリースの一覧・勧告ページ・報告窓口の方針）、公式の説明書き、Hacker News の紹介の投稿を2026年10月21日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 勧告の修正版（0.1.80版）は勧告ページの記載によるもので、修正の中身をこの記事で検証したものではありません。既定でどこまでの中身が記録に残るか、運営する会社の名前と所在地は、確認できませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、勧告の問題を突く手口は扱いません

まとめ

GoModel は、複数のAIの提供元への接続を一つの窓口にまとめ、費用・上限・利用者ごとの使えるモデル、さらにMCPの道具まで一か所で管理できるMITライセンスのOSSです。中心部分は無料で、社内の認証と結びつけるシングルサインオンなど一部の機能は商用版で提供されています。

一方で、2026年8月にはMCPの窓口に認証なしで届きうる中程度の勧告が公開され、勧告ページでは0.1.80版で修正されたとされています。初期設定では管理用の鍵が空の「安全でない状態」で動きます。修正版以降を使い、管理用の鍵と公開範囲を先に決め、記録と判断の根拠を人が確かめることが、GoModel のような中継役との現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。