AIエージェントの操作に人の承認と記録を求める企業が知っておきたいOSS「OMA」の使いどころ

「AIエージェントに業務を任せたいが、取り返しのつかない操作だけは人が確認してから実行させたい」「監査で、エージェントが何を見て何をしたのかを聞かれたときに答えられる記録が欲しい」——AIエージェントの業務利用を進める情報システム部門や、内部統制を担う部署からよく聞かれる要望です。こうした要望は、エージェントの性能や賢さの話として語られがちです。しかし本当に問われているのは賢さではありません。エージェントの操作のどこで人が止め、何を記録に残し、その記録をどこまで信じてよいかを、仕組みとして先に決めておくことです。この記事では、海外で注目を集めているOSS「OMA（Open Multi-Agent）」を取り上げ、一次情報で確かめられる承認と記録の仕組み、その限界、運営体制の注意点、企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

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

OMA（Open Multi-Agent）は、GitHubで公開されているAIエージェントの実行基盤です。READMEは自らを、エージェント同士の連携を取りまとめ、人の承認の関所を加え、実行の中身を手元で点検できる、自前で運用するTypeScript製の実行基盤だと説明しています。掲げている標語は「組織が所有し、承認し、監査できるエージェント」です。製品やクラウドのサービスではなく、自社のシステムに組み込んで使う部品の集まりという位置づけです。

配布の形を確かめます。リポジトリは2026年3月31日に作られ、READMEには4月1日にMITライセンスで公開したと書かれています。2026年10月22日時点でスターは約7,000、派生は約2,400、最後の更新は10月20日でした。一日あたりのスターの伸びは約34件です。リリースは週に一度ほどの間隔で続いており、最新は10月16日の1.21.3でした。貢献者の一覧によると、運営は中国・深圳の企業であるYuanASIで、中心となる保守担当者の名前も記されています。

READMEは、利用状況を外へ送る仕組みも、提供元が運営する管理用のサーバーも持たないと強調しています。使う鍵もモデルも利用者のもので、海外のクラウドのモデル、手元で動かすモデル、中国の事業者のモデルまで選べるとされています。自前運用の資料には、分析、利用許諾の確認、更新の確認といった外部への通信を一切しないと書かれています。ただしこれは提供元の説明であり、この記事の作成にあたってコードの中身を検証したものではありません。

なぜ「承認と記録」を掲げるエージェント基盤が注目されるのか

AIエージェントは、指示を受けて自分で計画を立て、道具を呼び出し、ファイルを書き換え、外部のサービスに接続します。便利になる一方で、企業が困るのは「何をしたのか後から説明できない」「止めたい操作を止める場所がない」という点です。指示文で「重要な操作の前には確認して」と頼んでも、それは確率で動く仕組みへのお願いにすぎず、確実に止まる保証はありません。

OMAが応えようとしているのは、この二つの問題です。一つは、操作の手前で実行を止め、人の判断を待つこと。もう一つは、モデルに何が渡され、どの道具が呼ばれ、どんな結果が返ったかを記録し、後から点検できるようにすることです。READMEはこれを「承認」「記録」「統制の最低線」の三本柱として示しています。統制を指示文の中ではなく、実行の仕組みの側に置くという考え方です。

もう一つの背景は、自前運用への関心です。外部のサービスにエージェントの実行を預けると、記録がどこに残り、誰が見られるのかを自社で決めにくくなります。READMEは「作った人たちが去っても動かなくなるものはない」と書き、外部の事業者に依存しない形で、エージェントの実行と記録を手元に置くことを打ち出しています。規制や監査の要求が強い業種ほど、この点に関心を持つと考えられます。

人の承認を挟む仕組み：計画・割り当て・道具の呼び出しの手前で止める

承認の資料によると、OMAは記録を保存しながら進む実行を、四つの境目で一時停止させ、承認の依頼を利用者のシステムに返せます。一つ目は、取りまとめ役のエージェントが計画を立て終えた時点です。承認されると、人が見た計画の写しそのものが実行されるとされています。二つ目は、作業の区切りごとの境目で、終わった作業と次に控える作業を示して判断を求めます。

三つ目は、担当が決まった一つの作業をエージェントに渡す直前です。四つ目は、個々の道具の呼び出しです。道具の呼び出しの承認では、道具の名前、モデルが出した入力、検査を通った後の入力、どのエージェントのどの作業か、影響の大きい操作かどうかの印が、確認の対象として示されます。承認されると検査済みの呼び出しが一度だけ実行され、拒否されると「拒否された」という結果がモデルに返り、モデルは次の手番でやり方を変えられます。

この一時停止は、処理を止めたまま待ち続けるのではなく、続きの状態を保存して終わる形です。承認が記録された後に、同じ処理か新しく立ち上げた処理が、保存された状態から再開します。資料によると、再開のときには承認の依頼と保存された計画や呼び出しの中身が一致するかを改めて照らし合わせ、食い違いがあれば、守るべき操作を実行する前に止まるとされています。計画や割り当てを拒否した場合、その実行は拒否として終わり、再開しても結果は変わりません。

承認の記録が守るものと、守らないもの

承認ごとに、依頼の番号と、承認の対象となった中身から計算した指紋のような値（ハッシュ値）が記録されます。承認者は自分が確認した中身の値を添えて判断を記録し、最初に書き込まれた判断だけが有効になります。同じ依頼に重ねて判断を書いたり、食い違う判断を書いたりすると失敗する作りです。人が見た中身と実際に動く中身がずれないようにする工夫だと読めます。

一方で、資料は守らないものもはっきり書いています。承認者の識別名は利用者のシステムが渡した文字列で、OMAはその本人確認をしません。承認者が実際には中身を見ずに値だけを送っても、OMAには見抜けないとされています。承認の期限、担当の付け替え、取り消し、複数人での合議、記録済みの判断の上書きといった仕組みも組み込まれていません。承認の画面、通知、本人確認、権限の管理は、すべて利用者の側の責任と明記されています。

保存の面にも注意点があります。承認の記録には、作業の説明や道具に渡す引数がそのまま保存されるため、機密の情報が含まれうるとされています。中身を伏せ字にする保存の仕組みは、ハッシュ値が変わってしまうため承認とは併用できません。照合の仕組みも暗号の署名ではなく、保存先を書き換えられる人は信頼の内側にいる、と資料は述べています。保存先そのものの権限管理と暗号化、監査が前提になります。同梱の保存の仕組みは、試験用か、一つの処理だけが書き込む用途に限られるとされています。

実行の記録と照合の機能：何を確かめ、何を証明しないか

二本目の柱は、実行の記録です。記録の資料によると、この機能は既定では無効で、使うときに有効にします。記録されるのは、会話に入った発言、モデルに渡す直前の文脈の断片とそのハッシュ値、道具の依頼と結果、文脈の書き換え、計画や作業の状態の移り変わり、共有の記憶への書き込み、承認の依頼と判断などです。資料はその目的を「なぜモデルはこれを見たのか」に答えるためだと説明しています。

記録を後から読み出して照合する機能もあります。番号の重複や逆転がないか、参照の先が正しいか、モデルに渡された断片が記録された出どころから再現できるかを確かめます。結果は、記録が自ら矛盾している「失敗」と、記録の範囲では答えられない「判断できず」に分けて返されます。ただしREADMEは、この照合は記録が一度も書き換えられていないことを証明するものではないと明記しています。

記録の資料はさらに具体的です。前後をつなぐハッシュの鎖も、署名も、書き換えのできない保存先も持たないため、書き込みの権限を持つ人が中身を変えて値を計算し直せば、照合は通ってしまうとされています。照合が見つけるのはOMA自身の記録のずれであって、保存されたファイルへの意図的な改ざんではないということです。また、記録に残る主体はエージェントであって人ではなく、承認の判断以外に人の識別は含まれません。記録の書き込みに失敗しても実行は止まらない作りである点も、監査に使うなら押さえておく必要があります。

統制の最低線：必要な役割と順番を宣言して、満たしたかを確かめる

三本目の柱は、READMEが「統制の最低線」と呼ぶ機能です。道具の設定の資料によると、複数のエージェントで仕事をさせるとき、必ず通さなければならない役割と、その順番を宣言できます。たとえば「作成の役割の後に、必ず別の確認の役割を通す」という形を、エージェントの判断に任せずに組み立てさせる考え方です。宣言が不正なら、どのエージェントも動く前に止まるとされています。

実行が終わると、宣言した役割と順番、独立した確認が実際に記録の上で観察されたかどうかが、「満たした」「満たさない」「対象外」のいずれかで返されます。判定は回答の文章ではなく、実行の構造を表すデータを読むため、出力の中に「確認済み」と書かれていても、それだけでは満たしたことにならないとされています。

注意したいのは、READMEが「実行が成功しても、統制の要件は満たされていない場合がある」と書いている点です。実行の成功を示す値は従来どおり実行時の誤りの有無だけを表し、統制の要件を満たしたかは別の値を見なければ分かりません。実行の形を明示的に上書きすると最低線が外れることもあり、その場合は上書きされた印が付くとされています。「成功」と「統制を満たした」を別のものとして扱う運用にしないと、確認を通っていない成果物がそのまま使われるおそれがあります。

外への通信と道具の権限の絞り方、そしてその外側にあるもの

OMAには、モデルへの接続先を絞る方針の仕組みがあります。通信の方針の資料によると、手元の機械だけに接続を許す形と、指定した接続先だけを許す形の二つがあり、組み込みの接続部品が接続する前に照らし合わせます。下位の方針は上位の方針を狭めることしかできず、方針を守らせられない接続部品は、つながる前に拒否される作りです。誤った方針の書き方も黙って無視されずに誤りになるとされています。

ただし資料は、この仕組みは基盤の側の通信の遮断ではなく、アプリケーションの水準での申告型の統制だと書いています。外部の道具をつなぐMCPの子プロセス、外部のプログラムを動かす実行の形、組み込みのシェルの道具、利用者が足した独自の道具、記録の送り先などは、この方針の外にあるとされています。名前の引き当ての固定や、仲介の強制もしません。資料自身が、確実に封じ込めるには基盤の水準での通信の制御と組み合わせるよう勧めています。

道具の権限は、既定では渡さない作りです。道具の設定の資料によると、組み込みの道具は明示的に許可したエージェントにしか渡りません。一方で、シェルの道具は隔離されておらず、許可されたエージェントは機械の上で任意の命令を実行できるとされています。シェルの命令の危険度を見積もる補助の仕組みも、浅い判定で、見た目を変えた命令はすり抜けうると明記されています。さらに、道具が読んだファイルの中身や命令の出力は、次の手番でモデルの提供元へ送られるため、読み取りの権限も意図して絞る必要があります。

使いどころ：既存の手段と比べて、どこで役に立ちどこで足りないか

OMAの使いどころは、自社でAIエージェントの仕組みを開発・運用する部門が、取り返しのつかない操作の手前に人の判断を挟み、その判断と実行の流れを手元に残したい場面です。たとえば、社内の文書を読んでまとめる作業、コードの変更の確認、問い合わせの下書きなど、最後の操作だけは人が確かめたい業務が当てはまります。一次情報で確認できた範囲をもとに、よく使われる手段と比べます。

見る点	指示文での確認の依頼	外部の実行サービスに任せる	OMA（自前運用）	基盤での隔離
止める場所	モデルの判断しだい	サービスの仕様しだい	計画・割り当て・道具の呼び出しの手前	プロセスが触れる範囲
確実さ	確率に左右される	提供元の作りに依存	決まった境目で一時停止	基盤の設定しだい
記録の置き場所	残りにくい	提供元の側	自社が用意する保存先	基盤の記録
承認者の本人確認	なし	サービスによる	利用者の側で用意	対象外
改ざんへの備え	なし	提供元による	組み込みなし（自社で用意）	基盤の記録の管理しだい

表のとおり、OMAが担うのは「実行の仕組みの中に、人が止める境目と記録の出どころを作る」層です。承認者の本人確認や改ざんへの備えは、自社の認証基盤や保存先の管理で補う必要があります。自前運用の資料も、複数の利用者を分ける仕組み、役割ごとの権限管理、一括の認証、承認の画面、改ざんが分かる監査記録、データベースの保存先、保存時の暗号化は提供していないと書いています。

逆に言えば、すでに社内に認証基盤と記録の保管の仕組みがある企業ほど、OMAの部品を組み合わせやすいと考えられます。何もない状態から入れても、承認と記録の「形」はできますが、誰が承認したかを証明する部分と、記録を守る部分は空いたままです。社内のエージェント開発の部品として使うのか、統制の仕組みそのものとして期待するのかを、最初に分けて考えるのが妥当です。

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

このラインでは、紹介するOSSを公開されている事実だけを基に精査しています。OSSを入手したり動かしたりはしていません。OMAの判定は「注意付き」です。

問題が見当たらなかった点から挙げます。ライセンスはMITで、商用を含めて使えます。配布物の設定には、取り込みのときに自動で動く処理は見当たりませんでした。GitHubのセキュリティ勧告の一覧には、2026年10月22日時点で公開済みの勧告は表示されていません。READMEには、継続的な試験と供給網の監査を行う自動処理の表示が掲げられています。

注意付きとした理由は運営体制です。リポジトリを所有する組織アカウントは2026年4月25日に作られており、3月31日に作られたリポジトリより新しい形です。個人のアカウントなどから移されたとみられますが、移管の経緯は一次情報では確認できませんでした。組織アカウントの公開リポジトリは4件、フォロワーは14件と小さく、意思決定の仕組みや支援の約束についての記述も見当たりません。スターの伸びは一日あたり約34件で、作られたばかりのアカウントにしては注目度が高い部類です。勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

運営体制・更新の速さ・修正済みの脆弱性

運営について確認できたことを整理します。貢献者の一覧では、中国・深圳の企業YuanASIが保守を担うとされ、中心の保守担当者が記されています。脆弱性の報告方針では、報告は公開の課題としてではなく、保守担当者の会社のメールで非公開に受け付け、48時間以内に受け取りを伝え、7日以内に修正か緩和の計画を示すことを目標にしています。支援の対象は最新の版だけとされています。

更新は速く、2026年8月から10月にかけてほぼ毎週リリースが出ています。10月16日の1.21.3のリリースノートには、勧告の番号付きで安全面の修正が記録されています。ファイルを書き込む組み込みの道具が、行き先のない参照のファイルを通じて、エージェントの作業用の場所の外にファイルを作れてしまう問題で、1.5.0から1.21.2までの版が影響を受けるとされています。一方で、リポジトリの勧告の一覧には公開済みの勧告が表示されておらず、記載の場所がそろっていない点は押さえておくべきです。

もう一つは、動作環境の変更予定です。READMEによると、サーバー側で動かすJavaScriptの実行環境のうち古い版の対応は移行のための猶予として残されているだけで、次の大きな版で外され、それは2026年10月31日より前にはならないとされています。最新版だけが支援の対象で、更新が速く、動作環境の切り替えも控えている以上、版を固定して検証し、修正を計画的に取り込む担当を決めることが欠かせません。

悪用されうるリスクと、過信が生む落とし穴

OMAは統制のための実行基盤で、攻撃に使う道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「承認の仕組みがあるから安全」「記録があるから監査に耐える」という安心が、確認されないまま独り歩きすることです。承認者の本人確認も、記録の改ざん対策も組み込まれていないため、その部分を自社で用意しなければ、承認と記録は形だけになります。

次に、承認の範囲の外にある操作です。資料によると、道具の呼び出しで一時停止できるのは、記録を保存しながら進む組み込みのエージェントの実行に限られ、外部のプログラムを動かす実行の形などでは、一時停止を求めると失敗として止まるとされています。また、外への通信の方針はシェルの道具や外部の道具の通信を止めません。ここからは推測ですが、シェルの道具を許可したエージェントが外部から取り込んだ文書の指示に従い、方針の外側で情報を送る筋書きは考えられます。

さらに、記録そのものが狙われる可能性もあります。承認の記録には道具に渡す引数がそのまま残り、実行の記録には会話や文脈の断片が残ります。保存先の権限が甘いと、記録が機密の流出元になりうるほか、書き込める人が記録を書き換えても照合では気づけない、と資料は述べています。記録は守りの材料であると同時に、守るべき対象でもあるのです。なお、OMAが悪用された事例は、2026年10月22日時点で確認した一次情報からは見つけられませんでした。

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

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、OMAが用意する「関所の形」と、自社で埋める「番人と帳簿の守り」を分けて書き出すことです。前者だけを入れて後者を空けたままにすると、承認と記録があるように見えて、実際には誰の判断かも、記録が本物かも示せない状態になります。

企業が取るべき対策

一つ目は、承認と本人確認をつなぐことです。承認の記録に残る承認者の名前は、OMAが確かめない文字列です。社内の認証基盤を通った人だけが判断を記録できるようにし、誰が、いつ、どの中身を見て承認したかを、自社の仕組みで証明できる状態にします。二つ目は、記録の守りです。保存先の権限を最小にし、書き換えのできない保存先や暗号化を組み合わせ、記録の保存期間と点検の担当を決めます。

三つ目は、基盤の水準での隔離です。資料が勧めるとおり、エージェントを動かすプロセスやコンテナの通信を基盤の側で絞り、シェルの道具は必要な場合だけ、承認の関所と組み合わせて渡します。四つ目は、読み取りの権限の絞り込みです。道具が読んだ中身はモデルの提供元へ送られるため、どの情報をどの提供元に渡してよいかを、情報の区分と接続先の一覧で決めておくことが必要です。海外や国内の事業者のモデルを選べる分、接続先の選定は統制の対象になります。

五つ目は、調達のときの確認です。運営する企業と保守担当者、脆弱性の報告窓口と対応の目標、支援の対象となる版、移管の経緯を確かめます。運営体制の情報が乏しい場合は、社内で保守を引き取れるか、別の基盤に移れるかも検討しておきます。MITライセンスでコードが公開されている点は、提供元が去っても自社で保守を続けられる余地として評価できます。

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

OMAは、AIエージェントの実行の途中に人の判断を挟むための仕組みです。言い換えれば、止めるかどうかの最終判断を、AIに委ねないための道具です。どの境目で止めるか、どの操作に誰の承認を求めるか、記録を誰が守り誰が点検するかは、AIにも道具にも委ねず、人が決めて文書に残します。

承認の場面でも、AIに判断させない工夫が要ります。承認の依頼に添える説明をAIに書かせる場合は、その操作が必要な根拠と影響の範囲を書かせ、承認者は説明ではなく実際の中身を確かめてから判断します。統制の最低線で確認の役割を置く場合も、確認の役割のエージェントの出力を鵜呑みにせず、人が確かめる範囲を先に決めます。やってはいけない向き合い方を挙げます。

• 承認の画面を作る手間を省き、承認者の本人確認なしの文字列のまま運用する
• 実行の記録の照合が通ったことを、記録が改ざんされていない証拠として監査で説明する
• 実行の「成功」を見て、統制の最低線を満たしたかを確かめずに成果物を使う
• 外への通信の方針を入れたことで、シェルの道具や外部の道具の通信まで止まったと思い込む
• 承認の依頼に添えたAIの説明だけを読み、実際の計画や引数を見ずに承認する
• 運営体制や移管の経緯を確かめないまま、版を固定せずに最新版を取り込み続ける

裏を返せば、人が決める範囲ははっきりしています。どこで止めるか、誰が承認するか、記録を誰が守るか、方針の外側を誰が受け持つか。この四つが決まっていないまま関所を設けても、統制の厚みは増えません。

よくある質問：OMAを入れればAIエージェントの監査対応は整うのか

答えは「それだけでは足りない」です。OMAは、承認の境目と記録の出どころを実行の仕組みの中に作る部品です。自前運用の資料は、承認の画面、承認者の本人確認、改ざんが分かる監査記録、保存時の暗号化を提供しないと自ら範囲を区切っています。どこまでをOMAに任せ、どこからを自社の認証基盤や保存先で補うかを決めて初めて、監査に耐える仕組みの一部になります。

では入れる意味が薄いのかというと、そうではありません。人が見た計画や引数と実際に動く中身のずれを照らし合わせる工夫、最初の判断だけを有効にする記録、モデルに渡された文脈の出どころをたどれる記録は、事故が起きたときに「エージェントは何を見て、何をしたのか」を説明する材料になります。外部へ利用状況を送らず、手元のモデルだけでも動かせるとされる点は、情報を社外に出しにくい業務での検討材料になります。

「運営が新しい組織だが、使ってよいのか」という問いもありそうです。MITライセンスでコードは公開されていますが、運営体制の情報は乏しく、移管の経緯も確認できませんでした。本番の業務で使う前に、版を固定した検証、修正の取り込みの担当、保守を自社で引き取れるかの見極めを済ませ、まずは影響の小さい業務から試すのが妥当だと考えられます。

• OMAの機能・版・限界は、GitHubのリポジトリとその中の文書、リリースノート、脆弱性の報告方針、貢献者の一覧を2026年10月22日に確かめた範囲に基づきます。更新が速いため、内容は変わる可能性があります
• 外部へ利用状況を送らないこと、判定や照合の仕組みの動きは、提供元の説明です。第三者による検証は、確認した範囲では見つけられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

OMA（Open Multi-Agent）は、AIエージェントの計画、作業の割り当て、道具の呼び出しの手前で実行を止めて人の承認を待ち、承認と実行の記録を手元に残せる、自前運用のTypeScript製の実行基盤です。MITライセンスで公開され、外部へ利用状況を送る仕組みや提供元のサーバーを持たないとされています。必要な役割と順番を宣言して満たしたかを確かめる機能や、モデルへの接続先を絞る方針の仕組みも備えています。

一方で、承認の画面、承認者の本人確認、記録の改ざん対策と暗号化は利用者の責任で、記録の照合は意図的な改ざんを見抜くものではありません。通信の方針はシェルの道具や外部の道具の外にあります。運営の組織アカウントは新しく、運営体制の情報は乏しく、10月には作業用の場所の外にファイルを作れてしまう問題も修正されました。どこで止め、誰が承認し、記録を誰が守り、方針の外側を誰が受け持つかを人が先に決めたうえで、統制の一つの層として使うことが、この基盤の使いどころです。

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