OpenHandsを自社環境で動かす判断｜外に出さない代わりの負担

「オープンソースの開発エージェントを自社で動かせば、コードが外に出ないから安全だと聞いた」「クラウド版もあるようだが、わざわざ自社で動かす意味はあるのか」——開発の生産性を上げたい情報システムや開発の責任者から、最近よく出る問いです。OpenHands は、公式の説明によれば、コーディングのエージェントを束ねて動かすオープンソースの基盤で、手元の端末でも自社の基盤でも動かせます。ただ、「自社で動かせば安全」という理解は、半分当たっていて半分ずれています。本当は、外に出さない代わりに、モデルの調達・実行環境・更新・担当者の負担を自社が丸ごと背負うという引き換えです。この記事では、2026年10月時点の公式情報をもとに、自社で動かすことの負担と、クラウド版・商用サービスを含む3つの選択肢を比べて整理します。

OpenHandsとは何か。2026年10月時点の提供のかたち

OpenHands は、公式の配布元によれば、コーディングのエージェントと自動化を束ねる「操作盤」です。2026年10月時点でMITライセンスのオープンソースとして公開され、活発に更新されています。既定では手元の端末で動き、設定によってDocker・仮想マシン・自社の基盤など、別の実行先につなげられます。

エージェントの中身も一つに縛られていません。公式の説明では、OpenHands 自身のエージェントのほかに、他社のコーディングエージェントも、共通の取り決めに対応していれば動かせます。つまりこれは、どのエージェントを、どのモデルで、どこで動かすかを自分で組み合わせるための土台だと捉えると分かりやすくなります。

提供のかたちは一つではありません。オープンソース版のほかに、提供元が運営するクラウド版と、自社の基盤に入れる企業向けの版があります。それぞれで、データの置き場所・使える人数・認証の仕組み・支援の有無が変わります。「OpenHands を使う」と言っても、どの形を選ぶかで負担がまるで違う、というのがこの記事の出発点です。

補足すると、公式の配布元によれば、エージェントは隔離した入れ物の中で動かすことが推奨され、予定や外部からの通知をきっかけに自動で動かす使い方も案内されています。自動で動くようになるほど便利ですが、人が見ていない時間に動く範囲が広がることでもあります。どの形で使うにせよ、自動化の範囲と、人が確認を挟む点を決めておく必要があります。

「自社で動かせば安全」という理解のどこがずれるか

自社環境で動かす最大の魅力は、コードやデータが自社の基盤の外に出ないことです。公式の企業向けの説明でも、自社の基盤・社内・プライベートクラウドで動かし、コードとデータの置き場所を自社が握れる、と書かれています。他社から預かったコードや、秘密保持の対象を扱う現場では、この一点だけで価値があります。

ずれが生じるのは、「動かす場所」と「処理する場所」を同じものと考えたときです。OpenHands 本体を自社で動かしても、文章を生成するモデルを外部のサービスから呼べば、その処理では指示やコードが外へ送られます。公式の説明でも、モデルは自前の鍵で外部の提供元を呼ぶ形が基本で、提供元の例として複数のクラウドのサービスが挙げられています。

つまり「自社で動かす＝何も外に出ない」ではありません。外に出さないことを本当に徹底したいなら、モデルまで自社の中で動かす必要があり、それはそれで別の重い負担を呼びます（後述）。まず決めるべきは、閉じたいのが「コードの保管場所」なのか、「処理のすべて」なのか、という点です。ここが曖昧なまま自社環境を選ぶと、安心の中身がぼやけます。

もう一点、実務でよく見落とされるのが、エージェントが作業の途中で参照する情報です。コードそのものだけでなく、設計の資料や接続の設定、過去のやり取りも、処理のためにモデルへ渡ることがあります。「外に出る」の対象は、思っているより広いのが実際です。何が処理のために送られうるのかを一度洗い出してから、閉じる範囲を決めると、後からの食い違いを防げます。

外に出さない代わりに、自社が背負う4つの負担

自社環境で動かすと決めたとき、外に出さないことと引き換えに自社が引き受ける負担は、大きく4つに分けられます。モデルをどこから呼ぶか、実行環境をどう隔離するか、更新と弱点にどう対応するか、そして担当者が抜けたときにどうするか、です。

どれも、クラウド版なら提供元がある程度引き受けてくれる部分です。自社で動かすとは、便利さや安さの裏にあるこれらの手間を、自社の人が担うと決めることでもあります。順に見ていきます。これらを見ないまま「無料だから自社で」と決めると、後から人手が足りなくなります。

この4つは、どれか一つを見落とすと全体が崩れる関係にあります。モデルを安く呼べても隔離を怠れば事故になり、隔離ができても更新を止めれば弱点が残り、更新を続けられても担当者が抜ければ回らなくなります。4つをまとめて担える体制があるかが、自社環境を選べるかどうかの分かれ目です。

負担1：モデルをどこから呼ぶか——外部モデルなら送信は起きる

最初の負担は、モデルの調達です。OpenHands はモデルを内蔵していません。公式の説明では、自前の鍵で外部の提供元のモデルを呼ぶのが基本の形です。この形を選ぶ限り、コードの保管は自社でも、処理のたびに指示とコードの一部は外部のモデルへ送られます。「外に出さない」は、この部分では成り立ちません。

送信そのものを避けたいなら、手元や自社の中でモデルを動かす選択肢があります。公式の文書も、手元で動かすモデルの使い方を案内しています。ただし、ここには相応の機材が要ります。公式の案内では、量子化した推奨のモデルでも演算装置の記憶容量が24GB以上、一部の機種では統合メモリが64GB以上必要とされ、手元のモデルは機能が限られ、道具の呼び出しが安定しないものがあるとも書かれています。

つまりモデルの調達は、二者択一に近い負担です。外部のモデルを呼べば処理は速く賢い代わりに送信が起きる。自社の中で動かせば送信は避けられる代わりに、機材と、モデルの質の見極めという負担が増える。何を本当に外に出したくないのかを決めてから、どちらの負担を取るかを選ぶことになります。

中間の選び方もあります。機密性の高い処理だけ自社の中のモデルで行い、ふつうの処理は外部の賢いモデルに任せる、という使い分けです。ただし使い分けは、どの処理をどちらに回すかの線引きと、その線が守られているかの点検という、新しい手間を生みます。手軽に始められる話ではないことは、最初に見込んでおいてください。

負担2：実行環境の隔離——エージェントは端末に強く触れる

二つ目は、実行環境の隔離です。コーディングのエージェントは、ファイルを読み書きし、命令を実行し、ネットワークにつながります。公式の配布元も、隔離せずに起動するとエージェントが端末のファイル全体に触れる、と警告しています。これは便利さの源であると同時に、隔離を怠ると、エージェントの行きすぎがそのまま自社の環境に及ぶ危うさでもあります。

公式は、隔離の仕組みとしてコンテナで囲む方式を推奨し、隔離なしで直接動かす方式は危険だと明記しています。どの方式で動かすかを決め、隔離を前提に設定するのは自社の責任です。前の記事で触れた「強い道具をAIに渡すときは囲いの中で」という考え方が、ここでもそのまま効きます。

さらに、外部から触れる形で動かすなら、接続を絞り、鍵で守る手当てが要ります。公式の自社運用の案内も、外からの接続を既定で閉じ、鍵の入力を求める形にするよう求めています。こうした設定を正しく行い、維持するのは、クラウド版では提供元が担っていた部分です。

隔離は一度設定して終わりではありません。新しい版にする、別の道具を足す、使う人を増やす、といった変化のたびに、隔離がまだ効いているかを確かめ直す必要があります。設定が少しずつずれて、気づいたら囲いに穴が空いていた、というのがよくある崩れ方です。隔離の状態を定期的に点検する担当を決めておくことが、地味ですが効きます。

負担3：更新と脆弱性対応——動かし続ける限り続く

三つ目は、更新と弱点への対応です。OpenHands は活発に更新されており、新しい版がひんぱんに出ます。活発な更新は歓迎すべきことですが、自社で動かす側から見ると、新しい版に追随し、弱点が見つかったら塞ぐ作業が、動かし続ける限り終わらないことを意味します。

これは前の記事で触れた「更新が止まった道具は危険」の裏返しです。更新が続く道具は、その更新を自社で取り込み続けて初めて安全が保たれます。入れっぱなしで放置すれば、活発に更新されている道具ほど、古い版と最新版の差が開き、未修正の弱点を抱えることになります。

クラウド版なら、この追随は提供元が行います。自社で動かすとは、更新の確認・検証・適用という運用の輪を、自社の人が回し続けると決めることです。開発エージェント本体だけでなく、動かす土台や周辺の部品も対象になります。誰がこの輪を回すのかを決めないまま始めるのが、最もよくある失敗です。

更新を取り込むときは、いきなり本番に当てないことも大切です。新しい版で動きが変わり、これまでの使い方が崩れることがあるためです。試験用の環境で確かめてから本番に反映する、という手順を定めておくと、更新がかえって事故を呼ぶことを防げます。この手順も、クラウド版なら提供元が引き受けていた部分だ、と意識しておくと負担の大きさが実感できます。

負担4：担当者が抜けたとき——属人化の落とし穴

四つ目は、人の問題です。自社環境の構築と運用は、たいてい一部の詳しい担当者に集まります。その人がいる間は回りますが、その担当者が異動・退職すると、誰も触れない仕組みだけが残るという事態が起きがちです。開発を速くするために入れた道具が、保守できない重荷に変わります。

この属人化は、オープンソースを自社で動かすとき全般に共通する落とし穴です。手順や設定の意図が個人の頭の中にしかないと、引き継ぎのときに崩れます。構築と運用の記録を残し、二人以上が分かる状態にすることが、負担としては地味ですが効きます。

逆に言えば、この4つの負担を自社で担える体制があるなら、自社環境で動かす価値は大きくなります。担える体制がないなら、クラウド版や商用のサービスに負担を預けるほうが、結局は安く速く安全なこともあります。次に、3つの選択肢を同じ物差しで比べます。

属人化を避けるもう一つの手は、設定や手順を文書ではなく、仕組みとして残すことです。環境の作り方を手順書にするだけでなく、同じ環境を誰でも再現できる形にしておくと、担当者が替わっても崩れにくくなります。人の記憶に頼る部分を減らすほど、引き継ぎは楽になるという当たり前のことが、運用を続けられるかどうかを左右します。

3つの選択肢を同じ表で比べる

自社環境で動かす・提供元のクラウド版・商用の自律開発サービスの3つを、コードの行き先・モデルの出どころ・運用の担い手・止め方の4つの軸で並べます。下の表は2026年10月時点の公式情報に基づく一般的な整理で、金額は扱いません。費用は後述のとおり、増え方だけ押さえてください。

軸	自社環境で動かす	提供元のクラウド版	商用の自律開発サービス
コードの行き先	自社の基盤内に保管。モデルを外部で呼べばその処理で送信	提供元のクラウドに保管	サービスの基盤に保管（契約で範囲を確認）
モデルの出どころ	自前の鍵で外部、または自社の中で動かす	自前の鍵、または提供元のモデル	サービスが用意（選べる範囲は契約次第）
運用の担い手	自社（隔離・更新・弱点対応・体制）	提供元が基盤を運用	提供元が運用
止め方	自社でつなぎを切る・鍵を無効にする	契約の停止・鍵の無効化	契約の停止

表から分かるのは、自社環境は自由と引き換えに負担が重く、クラウド版や商用サービスは負担が軽い代わりに外へ預ける範囲が広いという当たり前の構図です。どれが正解ということはなく、何を外に出したくないか、どれだけの運用の手を割けるかで答えが変わります。

費用についても、金額の表は作りませんが、増え方の向きだけ押さえておきます。自社環境はソフトの費用はかからない代わりに、機材と人手の費用が規模とともに増えます。クラウド版や商用サービスは、使う人数や使った量に応じて費用が増えます。安さは見かけの料金ではなく、人手まで含めた総額で比べるのが、後悔しない選び方です。

選択肢1：自社環境で動かす（オープンソース）

自社環境で動かす形は、コードとデータを自社の基盤内に置けるのが強みです。他社から預かったコードを扱う現場や、持ち出しの制限が厳しい業界では、この形が選ばれます。使える人数の制限もなく、モデルの選び方も自由です。

引き換えが、ここまで述べた4つの負担です。自由の大きさは、そのまま運用の重さになります。この形が向くのは、隔離・更新・体制を自社で担える、ある程度の規模と専門性を持つ組織です。小さなチームが「無料だから」と選ぶと、運用で行き詰まりがちです。

「自社で動かす」の中にも幅があります。手元の端末で一人が使う形から、社内の基盤に入れて複数人で使う形まであり、規模が大きくなるほど、認証や使える範囲の管理といった負担が増えます。公式には、企業向けに認証の連携や役割ごとの権限の機能が用意されていますが、それらを使いこなすのも自社の仕事です。どの規模で使うかを決めてから、必要な機能を見積もってください。

もう一つの利点は、将来にわたって提供元の都合に縛られにくいことです。クラウドのサービスは、料金や提供の条件が変わることがあります。自社で動かしていれば、外の事情で急に使えなくなる心配が小さいという安定が得られます。ただしこれも、更新を自社で追い続けられることが前提です。保守を止めた瞬間に、その安定は崩れます。

選択肢2：提供元のクラウド版

提供元が運営するクラウド版は、基盤の運用を提供元に任せられるのが強みです。隔離・更新・弱点対応といった負担を、自社で抱えずに済みます。公式の説明では、エージェントはコンテナで隔離された環境で動き、モデルは自前の鍵でも提供元のものでも使えます。

引き換えは、コードとデータが提供元のクラウドに置かれることです。どこまでが許容できるかは、自社の情報の扱いの基準と、提供元の説明を突き合わせて決めます。持ち出しの制限が緩い情報を扱う現場や、運用に手を割けないチームには、現実的な選択肢になります。

クラウド版でも、認証や利用できる人の範囲は自社で管理します。公式の企業向けの版では、全社の認証の仕組みと連携し、役割ごとに使える範囲を絞る機能が用意されています。誰に開放するか・何を許すかは、クラウド版でも人が決める部分です。運用の土台は預けても、開放の範囲までは預けない、と分けて考えてください。

選択肢3：商用の自律開発サービス

三つ目は、特定の提供元が運営する商用の自律開発サービスを使う形です。開発の一部の工程をまとめて任せる使い方で、運用の負担はほぼ提供元に預けられます。手早く成果を出したいときや、社内に運用の体制がないときに向きます。

引き換えは、仕組みの中身が見えにくく、データの扱いや止め方が契約の条件に左右される点です。何を任せ、何を自社に残すかを契約の段階で確かめる必要があります。自律的な開発サービスと外注の比較という観点は別の記事で扱っていますが、ここでの要点は、運用の負担を預ける代わりに、見える範囲も預けることになる、という点です。

この形を選ぶなら、止め方と、データの取り出し方を契約の段階で確かめておくことが要です。いざ別の方法に移りたくなったとき、これまでの資産を引き上げられるかは、後から決められません。運用を預けることと、抜けられない状態になることは別です。入る前に出口を見ておくのが、商用サービスを使うときの基本と言えます。

どの選択肢でも変わらない線：本番への反映は人が決める

3つの選択肢のどれを選んでも、変わらない線が一つあります。エージェントが出した変更を本番に反映してよいかは、人が決めるという線です。自社で動かすかどうかは、コードの行き先と運用の負担の話であって、AIの提案をそのまま信じてよい話ではありません。

どのリポジトリでエージェントを動かすか、どの変更を取り込むかも、人が決めます。自社環境で動かしているからといって、人の確認を省いてよい理由にはなりません。むしろ、自社の基盤に強く触れる分だけ、取り込み前の確認は丁寧にすべきです。

この「人が決める範囲」は、前の記事で扱った考え方とつながっています。取り消せる作業はAIに任せ、取り消せない操作は人が承認する。本番への反映は、まさに取り消しにくい操作の代表です。開発を速くしたいからこそ、速くしてよい部分と、速さと引き換えにしてはいけない部分を分けておく。この線引きこそが、道具を安心して長く使い続けるための土台になります。

この線は、AI導入の限界を分かっている書き手の基本の姿勢でもあります。開発を速くする道具は、人の判断を置き換える道具ではありません。速くなるのは作業で、責任は人に残ります。

もう一つ共通するのは、エージェントが出した変更に根拠を書かせ、人が採否を決めるという進め方です。なぜその変更にしたのかを説明させ、その説明ごと人が確かめる。こうしておくと、後で問題が起きたときに原因をたどれますし、AIの提案をうのみにする癖もつきにくくなります。自社で動かすかどうかにかかわらず、この進め方は変わりません。

小さく試して見極める手順

どの選択肢が自社に合うかは、机上では決めきれません。小さく試して、負担の実際を測るのが近道です。

• 「無料だから」とだけ考え、運用の4つの負担を見ずに自社環境を選ぶ
• 自社で動かすから安全と考え、外部モデルへの送信や本番への反映の確認を省く
• 隔離せずに直接動かし、本番の資格情報や経路につながったまま試す
• 構築と運用を一人の担当者に任せきりにし、記録を残さない

よくある質問

自社で動かせば、コードは絶対に外に出ませんか

本体を自社で動かしても、文章を生成するモデルを外部のサービスから呼べば、その処理では指示やコードの一部が外へ送られます。送信そのものを避けたいなら、モデルまで自社の中で動かす必要があり、相応の機材と見極めの負担が増えます。閉じたいのがコードの保管か処理全部かを先に決めてください。

無料のオープンソース版が、いちばん安く済みますか

ソフト自体の費用はかかりませんが、隔離・更新・弱点対応・運用の体制という人手の負担がかかります。小さなチームでは、この人手が最も高くつくことがあります。運用に手を割けないなら、クラウド版のほうが結局は安く収まる場合もあります。さらに、外部のモデルを呼ぶ費用は、どの形で動かしても使った量に応じてかかります。ソフトが無料でも、処理そのものの費用は別にかかると見込んでください。

どの選択肢が、うちに合うか分かりません

閉じたい情報の範囲と、運用に割ける人手の二つで決まります。持ち出しの制限が厳しく運用の体制があるなら自社環境、運用に手を割けないならクラウド版や商用サービスが向きます。小さく試して負担を測ってから選ぶのが確実です。

自社環境なら、AIの提案をそのまま取り込んでよいですか

いいえ。動かす場所が自社かどうかと、提案を信じてよいかは別の話です。本番への反映は、どの選択肢でも人が承認します。自社の基盤に強く触れる分、むしろ取り込み前の確認は丁寧にすべきです。

更新を止めて、気に入った版のまま使い続けてもよいですか

おすすめしません。更新が止まった版は、後から見つかった弱点が塞がれないまま残ります。強い権限で動く道具ほど、その弱点が入り口になる危うさが大きくなります。安定して使いたい気持ちは分かりますが、使い続けるなら、更新を取り込み続けることがほぼ前提です。止めるなら、使うのをやめるときだと考えてください。

社内に詳しい担当が一人しかいません。自社環境は避けるべきですか

一人に依存する状態での自社運用は、その人が抜けたときに崩れます。どうしても自社で動かすなら、構築と運用を二人以上が分かる状態にし、環境を再現できる形で残すことが条件です。それが難しいなら、運用を提供元に預けられるクラウド版のほうが、結果的に安全なことが多いです。開発を速くするために入れた道具が、保守できずに放置される重荷に変わっては本末転倒です。担える体制が社内に本当にあるのかどうかから逆算して、無理のない形を選んでください。

• OpenHands の提供のかたち・ライセンス・企業向けの機能・モデルの呼び方・隔離の方式は、公式の配布元と公式ドキュメントを2026年10月14日に確かめた範囲に基づきます。仕様は変わることがあるため、導入前に最新の公式情報を確かめてください
• 手元でモデルを動かすときの機材の目安は、公式ドキュメントの案内に基づく2026年10月時点の値です。推奨のモデルや必要な容量は更新されることがあります
• 商用の自律開発サービスのデータの扱い・止め方は提供元の契約によります。選ぶ前に契約の条件を確かめてください。本番への反映は、どの選択肢でも人が承認します

まとめ

OpenHands を自社環境で動かす判断は、「コードが外に出ない安心」だけでは決められません。本当は、外に出さない代わりに、モデルの調達・実行環境の隔離・更新・担当者の属人化という4つの負担を自社が背負うという引き換えです。しかも本体を自社で動かしても、外部のモデルを呼べばその処理では送信が起きます。

だから最初に決めるのは、閉じたいのがコードの保管か処理のすべてか、そして運用の4つの負担を自社で担えるか、という二点です。自社環境・提供元のクラウド版・商用サービスを、コードの行き先・モデルの出どころ・運用の担い手・止め方で比べ、小さく試して負担を測ってから選んでください。どの選択肢でも、本番への反映は人が決める——この線だけは、動かす場所が変わっても動きません。

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